How Can We Help?
AWS Solutions Architect Associate Diploma Cheat Sheet
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