AWS Solutions Architect (Associate) Cheatsheet

Look for the key/s in every exam – know what the question is asking and expecting from you.

Some common exam keywords 

Highly Available = apply Multiple Availability zones

Fault-Tolerant = apply Multiple Availability zones and an application environment replica to provide for fail-over. Application failure in one AZ should automatically start recovery in another AZ/region.

Real-Time Data = this probably means applying Kinesis services

Disaster = Failover to another region

Long Term Storage = means Glacier or Deep Glacier storage

Managed Service = means S3 for data storage, Lambda for computing, Aurora for RDS and DynamoDB in the case of NoSQL databases

Use AWS Network = usually refers to communications between VPCs and AWS services, so you need to implement VPC gateways and endpoints for communication between these services.

EC2 (Elastic Compute Cloud) instances

These are the basic virtual computer building blocks for AWS.

EC2s are built with predefined EC2 images called AMIs (Amazon Machine Images) – eg various Linux distribs, Windows or MacOS.

You can also build EC2s using your own AMIs.

Types of EC2s

On-Demand Instances – cost is fixed price per hour when instance is running.

Pros: High Availability, you pay only for actual use, good for predictable short-term computing tasks.
Cons: may be expensive over longer time periods.

Use-Cases: development, providinng extra capacity in the event of unforeseen computing demand.

Reserved Instances – fixed term usage contract for 1–3 years.

Pros: cheaper than On-Demand, High Availability, suited to reliable long-term computing tasks.
Cons: – pricier if the instance is underutilized over time.
Use-Cases: Webservers, Relational databases, providing core infrastructure with high availability requirements.

Spot Instances – price fluctuates according to overall current market demand. Offered to highest bidder. Tends to be much cheaper than On-Demand or Reserved Instances.

Pros: very low-cost option, good for short-term computing tasks which can be interrupted without serious loss.
Cons: AWS can terminate the instance any time, depending on market price you may need to wait some time until your offer is accepted.

Use-Cases: providing extra computing capacity for unpredictable workloads that can be interrupted. Eg if running a fleet of Reserved instances to house the webservers, then in the event of sudden website demand spikes you can request Spot instances to cover the additional workload.

Dedicated Hosting – for these you reserve a whole hardware server or server rack for your instance/s – in other words, it is not a virtual machine anymore.

Pros: ideal for high-security and isolated computing tasks.
Cons: the most costly EC2 service.
Use-Cases: Enterprise databases that have high-security needs.

Spot-fleets – these are used for combining all the services listed above into a more cost-efficient structure. For example, you could use a set of Reserved instances to cover your core workload, plus a mix of On-Demand and Spot instances to handle workload spikes.

Spot fleets are especially suited for Auto Scaling Groups.

On-Demand: no long-term commitment, fixed price per second. Best for short-term, irregular workloads that shouldnt be interrupted

Reserved: long-term commitment required of 1 to 3 years. Used for high-uptime workloads or basic core-infrastructure

Spot: uses auction-based bidding for unused EC2 resources — very low cost, but workload can be interrupted if your offer falls below market levels

Dedicated Host: a whole rack or server is dedicated to your account, thus no shared hardware involved — best used only for very high-security requirements due to high cost.

Dedicated Instance: instance is physically isolated at host level, but may share hardware with other instances in your AWS account

EC2 Storage

EBS = Elastic Block Storage

EBS – is a virtual file system drive attached to an EC2 instance. Remember you can’t attach the same EBS to multiple instances.

However you can make a snapshot and then attach the snapshot to another instance.

EBS has the following variants:

EBS(GP2) – General Purpose SSD
Pros: provides balanced work performance and is suitable for most applics
Cons: I/O throughput is max. 16,000 IOPS – make sure you remember this figure for the exam
Use-Cases: serve as system boot drive, good for medium-level workloads

EBS(I01, I02) – Provisioned IOPS SSD
Pros: good for low latency and high throughput up to 64,000 IOPS
Cons: is a pricey storage type
Use-Cases: good for relational databases and high-performance computing (HPC)

EBS(ST1) – Throughput Optimized HDD
Pros: is a lower-cost HDD volume good for frequent access, throughput-intensive workloads
Cons: has low IOPS
Use-Cases: good for use as storage for streaming applications and Big Data storage requirements

EBS(SC1) – Cold HDD
Pros: is the cheapest EBS type
Cons: has lower durability and availability
Use-Cases: – providing storage for files that need high throughput and are infrequently accessed.

EBS volumes are located in a single AZ. If you need to provide High Availability and/or Disaster Recovery thren you need to set up a backup process to create regular snapshots and then store them in S3.

EBS is a provisioned storage type. You are charged for the storage capacity you have defined.

If you require network drive storage for your instances, then you need to attach an EFS volume to your instances.

EFS – Elastic File System
EFS operates only with Linux and serves as a network drive that enables data sharing between EC2 instances.
For Windows instances, you must use “Fx for Windows” as the network file system.
EFS is an automatically scalable storage service and you only pay for the storage space you are using, plus data transfer fees.

There are 2 types of EFS:

General Purpose Performance Mode – this is great for low latency, content management, and storage.
Max I/O Performance Mode – this is good for big data and media processing requirements that need high IOPS, but has a trade-off in terms of higher latency.

Finally, Instance Store

Instance Store is temporary high-performance storage with very high IOPS. Instance Store is ideally suited to cache and session storage. However, it is not a durable storage solution. If the instance is terminated, then all data in the instance store is deleted.

Some definitions to memorize for the exam:

User Data – defines the specific commands to be run during the instance boot process, for example to check for software package updates.

Meta data – this describes instance configuration. The meta data can be accessed through SSH by calling this address http://169.254.169.254/latest/meta-data/

Golden AMI – this is a custom instance image, that has all the necessary software and application pre-installed. Ideal for quick recovery and high availability – for the latter you have to copy the desired Golden AMI to different AZs or regions.

Placement Groups – EC2 instances can be grouped together in 3 different configurations:

Cluster = All instances are located in the same hardware rack and have the highest network bandwidth. Great for machine learning and high-performance computing (HPS)

Spread = Instance are distributed across multiple AZ in order to maintain high availability
Partition = The instances are grouped in smaller groups and each group occupies its own hardware rack. It combines the benefits of Cluster placement with High Availability through a spreading approach.

In the exam, you will be tested on different scenarios for the most suitable EC2 configuration. Here are some general tips:

Use EBS(io1/io2) for application with high IOPS requirements (>16,000)
Use User Data to ‘bootstrap’ scripts during instance startup

Do NOT use Spot instances for critical workloads

Strife for High-Availability by using EC2 instances in multiple Availability Zones and regions. You can have your production environment up in running one region, and the backup instances are either in Stop or Hibernate status in a different region. In case your production AZ becomes unavailable, you can switch to your backup instances and keep the production workload running from different region (Later I’ll explain the concept of Elastic Load Balancing and Auto
Scaling on AWS)

Use IAM roles to give permissions to EC2 instance

And last but not least:
DO NOT STORE ANY CREDENTIALS INSIDE THE EC2 INSTANCE

There are better ways to provide secure access by using IAM roles and AWS Secret Manager.

Simple basic setup with Internet – http/s Webserver (EC2) – MySQL Database (RDS)

Webserver has to be located in the public subnet of your VPC, with the MySQL DB instances located in the private subnet.

Security Group for the Webserver will be open for all incoming requests on port 80 (HTTP) and/or 443 for HTTPS to all IP addresses,

The Security Group for the MySQL DB needs only port 3306 open for the Security Group for communication with the Webserver.

Load Balancer and ASG Setup

Internet – ELB – ASG – Webserver (EC2) – MySQL DB (RDS)

This will generally require HA – high availability – plus fault tolerance, together with the correctly configured security requirements.

Re security: you need to locate the ELB in the public subnet and open the HTTP/s ports, and locate Webservers and SQL DB instance in a private subnet.

The difference between the WAF (Web Application Firewall) and AWS Shield:

WAF is used to protect against attacks such as cross-site scripting. AWS Shield is used to protect against DDOS attacks.

Serverless web application:

Internet – API Gateway – Lambda – DynamoDB or/and S3 Storage

Serverless applications tend to be HA since they operate in multiple AZs. 

But you have to add some fault-tolerance to provide for more HA. Generally this involves adding Cloudfront to provide better caching and latency, setting up a Multi-region application for disaster recovery, configuring SQS messaging, and deploying Auto Scaling for DynamoDB.

VPC – Virtual Private Cloud

This is an important area of the exam.

VPC holds all your AWS virtual server infrastructure. Remember that a single VPC can span multiple AZs in a region. But – it can’t span multiple regions. For this you need to use VPC peering to connect VPCs located in different regions.

VPC can contain public and private subnets. They are configured to use specific private IP ranges.

Public subnets are open to the Internet, provided you have installed an IGW or Internet Gateway on your VPC.

Private subnets do not have access to the Internet unless you add a NAT Gateway or NAT Instance in the public subnet and enable traffic from private instances to the NAT Gateway.

Bastion Hosts

Bastion hosts are used to permit secure SSH admin access from the internet into the instances of a private subnet.

Bastion host must be located in a public subnet and the private instance must permit traffic from the Bastion host Security Group on Port 22.

network Access Control Lists (NACLs) = define rules which apply for incoming and outgoing network traffic to/from your subnet.

Remember:

Default NACL config ALLOWS ALL traffic in and out – ie all ports are open,
NACLs can block traffic by explicit Deny, for example you can block specific IPs or IP ranges from accessing your own subnet.

Route Tables = these define network traffic routes in and out of your VPC. Route tables are configured on a subnet basis.

VPC Endpoints = provide access to all AWS services that are not part of the VPC.

Remember there 2 types of Endpoints:

Gateway Endpoint = this enables use of S3 and DynamoDB
Interface Endpoint = this permits use of all other AWS services

CIDR = Classless Inter-Domain Routing.

Know how the CIDR range is defined.

/32 = 1 IP
/31 = 2 IPs
/30 = 4 IPs

and doubles for each step…

remember that the first 5 IPs have to be reserved for the subnet system, so cannot effectively be used, so that means you need at least a /29 CIDR of 8 IPs to do anything!

Some examples:

192.168.10/32 = /32 = IP range for a single IP address 192.168.10.255

192.168.10/31 = /31 = IP range for 2 IP addresses 192.168.10.254 and 192.168.10.255

192.168.10/30 = /30 = IP range for 4 IP addresses 192.168.10.252, 192.168.10.253, 192.168.10.254 and 192.168.10.255

VPC Gateway = allows connectivity to your on-premises network via public internet.

NAT Gateway = enables internet connection from instances located in a private subnet (i.e. often used to facilitate software updates).

NAT Gateway and NAT Instance

Know the difference between NAT Gateway and NAT Instance.

Usually NAT Gateway is preferred as NAT instances have to be managed by the user and don’t allow for auto-scaling.

NAT Gateway by contrast is an AWS managed service which also scales automatically on demand.

For HA or high availability of NAT Gateways where your VPC spans multiple AZs, you need to use individual NAT Gateways located in each AZ.

NAT Gateway & NAT Instance

used to connect to public internet from your private subnet/s

2 different types:

NAT Instance — managed by user with no default auto-scaling, more complex, greater overhead

NAT Gateway — is an AWS Managed Gateway, scalable on demand, less overhead, higher availability vs NAT Instance

VPC peering = peering enables you to establish connections between different VPCs.

Remember that the CIDR-ranges of the connected VPCs must not overlap. And also: VPC peering does NOT work as transitively – ie if you have 3 VPCs (A, B and C) and then set up peering between A and B, and between B and C, the instances located in VPC A cannot communicate with instances in VPC C…. To do this you must also peer VPC A with VPC B.

AWS Transit Gateway = this is a VPC hub that connects multiple VPCs in a web-type network.

In this way you can connect VPCs and your on-premises VPCs and they can all communicate transitively. However – remember also that the CIDR ranges of the VPCs must not overlap. 

Make sure you revise all of these topics for the exam:

AWS AppSync
Aurora Serverless
AWS ParallelCluster
AWS Global Accelerator
AWS DataSync
AWS Directory Service
Amazon FSx
Elastic Fabric Adapter
Elastic Network Adapter
Amazon FSx

VPC or Virtual Private Cloud (VPC) Networking

Remember VPCs can span multiple availability zones within one region (but not multiple regions).

They can contain multiple private and public subnets.

A public subnet contains a route to an internet gateway of IGW.

A private subnet by itself has no internet access.

If required then create a NATGW – NAT Gateway, or else EC2 NAT Instance (the old way – not so recommended by AWS) You can also whitelist traffic to these.

For SSH access from internet to a private subnet resource you need to set up a bastion host on a public subnet.
Then configure your Security Groups and Network Access Control Lists to forward traffic on SSH port 22.

Disaster Recovery

Recovery Objectives

Recovery Time Objective — time needed to bring services back online after a major incident
Recovery Point Objective — the data loss measured in time

Backup and Restore – low cost

Pilot Light – for storing critical systems as a template which you can use to scale out resources in event of a disaster

Warm Standby — a duplicate version of business-critical systems that must always run.

Multi-Site — for multiple locations, has lowest RTO Recovery Time Objective and RPO Recovery Point Objective but inccurs highest cost

Route Tables

These decide how traffic can flow within your VPC

Routes contain a destination and a target, e.g. 0.0.0.0/0 (CIDR Destination) and igw-1234567890. The CIDR block covers all the defined IPv4 addresses of the subnet and points them to the IGW.

a default or aws main route table exists for each newly created subnet

note the main route table can’t be deleted

but you can add, modify, and remove routes in this table

a subnet can only have one single route table

but – the same route table can be attached to multiple subnets

route tables can also be attached to your VPG Virtual Private Gateway or IGW Internet Gateway so you can define how the traffic flowing in and out of your VPC is to be routed.

Your VPC always contains an implicit router to which your route tables are attached to.

Virtual Private Gateway (VPC Gateway)

VPG is required if you want to connect your AWS VPC to an on-premises lan.

Network Access Control List (NACLs)

these operate at the subnet level and are STATELESS
you can use NACLs to define block & allow rules

By default NACLs allow traffic in for all ports in both directions

but – return traffic must be explicitly allowed

Security Groups (SGs)

SGs operate at the EC2 instance level and are STATEFUL
SGs only define ALLOW rules – no deny!

Default SG allows communication of components within the security group, ie allowing all outgoing traffic and blocking all incoming traffic

BUT – return traffic is implicitly allowed – in contrast with NACLs

SGs can be attached or removed from EC2 instances at any time without having to stop or terminate the instance.

the rules for SGs must always specify CIDR ranges and never just a single IP

BUT – if you want to have a dedicated IP, e.g. 10.20.30.40 then you need to define it as a “CIDR range” for just a single IP by setting its subnet mask with  /32 eg 10.20.30.40/32

VPC Endpoints

used for accessing AWS Services which are not part of your VPC

2 different types of VPC endpoint:

Gateway Endpoint — used for DynamoDB and S3
Interface Endpoint — used for all other Services & works via AWS PrivateLink

VPC Peering

This connects different VPCs, including VPCs of other accounts

Very important: CIDR-ranges of the VPCs must not overlap!

VPC Peering connections are not transitive, thus A ← Peering → B ← Peering → C = means no connection between A and C

Transit Gateway
is a hub for VPCs to connect multiple VPCs with each other effectively into one giant VPC (can include on-premises VPC if desired)

Elastic IP Addresses (EIPs)

can be moved from one instance to another within multiple VPCs if within same region

Amazon Machine Image (AMI)

predefined image, e.g. for Linux or Windows

you can create your own AMIs by launching them with an instance, then modifying and saving it as a new custom AMI

AMIs contain one or more EBS snapshots or for instance-store-backed AMIs a template for root volume (ie the OS, an app server, or applications)

contains launch permissions for volumes to attach to the instance upon booting

AMIs can be EBS-backed or Instance Store-backed

Elastic File System (EFS)

is a Network drive

good for sharing data with multiple instances

EFS can also be attached to Lambda functions

Payment modes for EFS:

2 types:

General Purpose Performance Mode — for low latency requirements
Max I/O Performance Mode — best for high IOPS requirements, e.g. big data or media processing workloads; also has higher latency than General Purpose Mode

Elastic Block Storage (EBS)

EBS is a virtual block-based system drive
Important: can’t be used simultaneously for several instances: only one EC2 per time as it is not a network drive

Can make snapshots of EBS 

if EBS volume is the root volume, then by default it gets deleted when EC2 instance is terminated

BUT – non-root volumes do not get terminated when instance is terminated

EBS is created in a SINGLE REGION – is not cross-region

For high availability/disaster recovery you need to take snapshots and save to S3

Pricing for EBS is according to defined storage capacity, not per data volumes transferred

EBS has several types: Know these!

Cold HDD: lowest-cost designed for less-frequently accessed workloads

SC1: up to 250 IOPS (250 MiB/s), with 99.8–99.9% Durability

Throughput Optimised HDD: this is low-cost for frequently accessed workloads

ST1: up to 500 IOPS (500 MiB/s), 99.8–99.9% Durability

General Purpose SSD: mid-balance between price and performance

GP2/GP3: provides up to 16.000 IOPS (250–1000MiB/s) with 99.8–99.9% Durability

Provisioned IOPS (Input/Output Operations Per Second): intended for high performance for mission-critical, low-latency, or high-throughput workloads

IO1/IO2: provides up to 64.000 IOPS (1000MiB/s) with 99.8–99.9% Durability

IO2 Block Express: offers up to 256.000 IOPS (4000MiB/s) and 99.999% Durability

Provisioned IOPS can be attached to multiple EC2s – whereas other types don’t support this

The most convenient way of creating backups is to use the Data Lifecycle Manager for creating automated, regular backups

Instance Store

this is an ephemeral storage which gets deleted at EC2 termination or in the event of hardware failure

So use only for a session or cached data
it has very high IOPS

Storage Gateway

gives on-premises site access to unlimited cloud storage

different Storage types:

Stored — use S3 to backup data, but store locally → you are limited in the amount of space you can allocate

Cached — stores all data on S3 and uses local only for caching

and different Storage Gateway Types:

File Gateway — stores files as objects in S3, using NFS and SMB file protocols
Tape Gateway — virtual tape library for storing backups, using iSCSI protocol
Volume Gateway — using EBS volumes, using the iSCSI protocol; data written to those volumes can be backed up asynchronously to EBS snapshots

Elastic Load Balancing (ELB)

Distributes traffic between computing resources.

ELB has four different types:

Classic (CLB): oldest types, works on both layer 4 and layer 7 — no longer featured on AWS exams

Application (ALB): works on layer 7 and routes content based on the content of the request

Network (NLB): works on layer 4 and routes based on IP data

Gateway (GLB): works on layer 3 and 4 — mostly used in front of firewalls

load balancing enhances fault-tolerance as automatically distributes traffic to healthy targets which can also reside in different availability zones

ELB can be either internet-facing (has public IP, needs a public VPC) or internal-only (private VPC, no public IP, can only route to private IP addresses)

EC2 instances or Fargate tasks can be registered to ELB’s target groups

CloudWatch

basic service free
is a monitoring platform integrated with most AWS services

Log events: messages collected by CloudWatch from other services, always with a timestamp
log groups: a cluster of log messages which are related to a service
log streams: fdeeper level of messages, e.g. for specific Lambda micro-container instance or a Fargate task

CloudWatch collects metrics by default from many services, including Lambda, EC2, ECS etc

X-Ray allows for distributed tracing to show how a single request interacts with other services
Alarms can be used to send mails or SMS messages via SNS on triggering of certain events or to trigger actions eg auto-scaling policies

CloudTrail

Monitors and records account activity across AWS infrastructure.

records events in your AWS account as JSON data
you decide which events are tracked by creating trails
a trail will forward your events to an S3 bucket and/or to a CloudWatch log group

CloudTrail records different types of audit events

Management events: infrastructure management operations, e.g. IAM policy adjustments or VPC subnet creations

Data Events: events that retrieve, delete or modify data within your AWS account, e.g. CRUD operations on DynamoDB or a GET for an object in S3

Insight Events: records anomalies in your API usage of your account based on historical usage patterns
you can also define filter rules to NOT track all events of a certain type, but only a subset.

Access Restrictions

are based on Geo-Location

with Signed URLs — require expiration date & time of the URL plus AWS Security Credentials / Bucket Name containing the objects for creation
they restrict access to specific VPCs

S3 stores objects in buckets, Glacier stores objects in vaults

Object Locks: Retention Modes

Governance Mode

users can’t override or delete the objects unless they have specific required rights granted

you protect objects from being deleted by most users, but you can still grant specific users permission to alter retention settings or delete the object if desired

Compliance Mode

a protected object version cannot be overwritten or deleted by any user, this includes your aws root user
its retention mode cannotbe changed, and the retention period can’t be reduced

Placement Groups

A way of grouping your EC2 instances in a certain way to meet specific needs

Spread: distributes instances across availability zones for high availability

Cluster: places instances in same rack for high network bandwidth

Partition: multiple cluster groups, giving a combination of both the above features. high availability through spreading and high bandwidth through clustering

Route 53

This is the AWS DNS service – fully managed by AWS

Failovers

Active-Active Configuration

where you want all of your resources to be available most or all of the time

If a resource becomes unavailable, then route 53 can detect that it’s unhealthy and will stop including it when responding to queries

Active-Passive Configuration

for when you want a primary resource or group of resources to be available most of the time
– and you want a secondary resource or group of resources to be on standby –
in case all the primary resources become unavailable when responding to queries, Route 53 includes only the healthy primary resources

If all the primary resources are unhealthy, then Route 53 includes only the healthy secondary resources in response to DNS queries

Auto-Scaling Policies

remember – these cannot span over multiple regions

different types of policies are available

Target Tracking Policies

Choose a particular scaling metric plus a target value, e.g. CPU utilization

EC2 Auto Scaling looks after creation of CloudWatch alarms that will trigger the scaling policy to activate

You can define the “warm-up” times for when the target tracking won’t be active – eg if your instances start and the CPU util spikes to 100% then you will not want them to auto-scale just because of this sudden short spike in CPU utilization.

Step and Simple Scaling Policies

these scale based on defined metrics

if thresholds are overstepped for the defined number of periods then AutoScaling Policies will activate

Step scaling policies allow you to define steps according to size of the alarm overstepping:

e.g. Scale-out policy [0,10%] -> 0, (10%, 20%] -> +10%, (20%, null] -> +30% with desired 10 instances

if the metric value changes from 50 (desired value) to 60, then the scale-out policy adds 1 more Instance (ie 10% of your desired 10)

if the metric changes later after the “cool down” of the Scaling Policy, for example to 70 in the metric value, then 3 more Instances will be launched (ie 30% of your desired 10)

the same can also be defined for Scale-in policies

Scaling based on SQS

this scaling is based on a metric of an SQS queue, e.g. ApproximateNumberOfMessagesVisible

Scheduled Scaling

this scales your application instances according to a scheduled time which you set

KMS (Key Management Service)

KMS is a service for creating and managing encryption keys used for securely signing your data.

Encryption of AMIs & EBS Volumes

these can be shared across AWS Account boundary by assigning targeted accounts as users of the master encryption key
and is natively integrated with other services eg SQS, S3, or DynamoDB to encrypt data

Server Side Encryption (SSE)

SSE-S3 (Server Side Encryption managed by S3 for the data and the encryption keys

SSE-C (Server Side Encryption managed by the Customer) here you are responsible for your encryption keys

you can also use different encryption keys for different versions of files within an S3 bucket

Amazon recommends regular the rotation of keys by the customer itself as best practice.

SSE-KMS (Server Side Encryption managed by AWS, KMS, and the customer) – here AWS manages the data key but you are responsible for the customer master key stored in KMS (AWS Key Management Service)

S3 (Simple Storage Service) and Glacier

S3 is a durable object storage which asynchronously replicates your data to all AZs within your region

A bucket is the name for an S3 storage container.

There is no limit on the number of files within a bucket

CloudFront

Edge-computing and delivering content closer to your customer’s locations.

AWS distributes your content to more than 225 edge locations & 13 regional mid-tier caches on six continents and 47 different countries

origins define the sources where a distribution retrieves its content if it’s not cached yet
a single distribution can use multiple origins

caching is determined by a cache policy – AWS managed or custom

Lambda@Edge and CloudFront functions allow general-purpose code to run on edge locations closer to the customer
with geo-restrictions, you can set blocking lists for specific countries

CloudFront supports AWS Web Application Firewall (WAF) to monitor HTTP/s requests and control access to content

Databases

DynamoDB
A fully managed NoSQL database service.

a non-relational database, based on Casandra

comes with two different capacity modes

on-demand: scales acc to number of requests, fee per consumed read or write capacity unit
provisioned: you define how many read/write capacity units required, pay fixed price per month

can use auto-scaling policies together with CloudWatch alarms to scale based on workloads
a (unique) primary key is either built via hash key, or via hash key and range key

Global – can be created at any time – and Local – vreated only when your table is created

Secondary Indexes – allow additional access patterns

can use streams to trigger other services like Lambda on create/update/delete events

Time-to-Live (TTL) attribute allows automatic expiry of items

global tables can span multiple regions and automatically syncs data between them

encryption of tables by default: done either via KMS keys managed by AWS or by the customer directly

RDS Relational Database Service DB

choice of db engine:

MariaDB

SQL Server — this does not support read replicas in a separate region

MySQL

supports Multi-AZ deployment

synchronously replicates data between multiple AZs

offers higher availability with failover support
minimal downtime when scaling

Aurora

is MySQL and PostgreSQL compatible, fully managed and serverless

supports read replicas
point-in-time recovery
continuous backups to S3 & replication across AZs

Lambda

serves as core building block for serverless applications.

integrates natively with different services like SQS or SNS
can run on x86 or ARM/Graviton2 architecture

compute-resources (vCPU) are sized based on memory settings

CloudFormation

The fundamental infrastructure-as-code tool at AWS.

templates are the definition of the infrastructure resources that should be created by CloudFormation and how they are composed
for each template, CloudFormation will create a stack which is a deployable unit and contains all your resources

CloudFormation detects change sets for your stacks at deployment time to calculate what create/update/delete command it needs to run via outputs, you can reference other resources dynamically that may not exist yet

Simple Queue Service (SQS)

A queuing service for creating resilient, event-driven architectures.

another core building block for serverless applications
allows you to run tasks in the background

offers different types of queues

First-In-First-Out (FIFO): executes messages in the order SQS receives them

Standard Queues: higher throughput but no guarantee of the right ordering

Dead-Letter-Queues (DLQs) allows you to handle failures and retries

Retention periods define how long a message stays in your queue until it’s either dropped or re-driven to a DLQ

Simple Notification Service (SNS)

is a managed messaging service for sending notifications to customers or other services.

consumers can subscribe to topics and receive all messages published for this topic
two different types, as for SQS: FIFO and Standard

messages can be archived by sending to Kinesis Data Firehose and from then on to S3 or Redshift

Identity and Access Management (IAM)

The basic security building block for all aws applications

ollow best practices:

never use your root user,
ues dedicated IAM users with enable MFA

different entity types: users, groups, policies, and roles

user: end-user, accessing the console or AWS API

group: a group of users, sharing the same privileges

policy: a defined list of permissions, defined as JSON

role: a set of policies, that can be assumed by a user or AWS service to gain all the policies permissions

by default, all actions are denied – must be explicitly allowed via IAM

an explicit deny always overwrites an allow action