How Can We Help?

AWS Solutions Architect Associate Diploma Cheat Sheet

You are here:
< All Topics

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


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:


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.



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/31 = /31 = IP range for 2 IP addresses and


192.168.10/30 = /30 = IP range for 4 IP addresses,, and



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. (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. then you need to define it as a “CIDR range” for just a single IP by setting its subnet mask with  /32 eg



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




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





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




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






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





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:




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




supports Multi-AZ deployment


synchronously replicates data between multiple AZs


offers higher availability with failover support
minimal downtime when scaling




is MySQL and PostgreSQL compatible, fully managed and serverless


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




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






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





Table of Contents