Cheat sheet: AWS SAA-C03 reference for service selection, architecture patterns, security, networking, storage, databases, resilience, and cost tradeoffs.
This Cheat Sheet is independent study support for candidates preparing for the AWS Certified Solutions Architect – Associate (SAA-C03). Use it to make fast architecture decisions: which AWS service fits, which pattern is more resilient, which security control applies, and which exam traps to avoid.
Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Scope and study context
The SAA-C03 exam is not mainly a memorization test. It rewards choosing the AWS service or architecture pattern that best satisfies requirements such as:
High availability and fault tolerance
Security and least privilege
Performance and scalability
Cost optimization
Operational simplicity
Migration constraints
Data durability, retention, and access patterns
This page is IT Mastery review support and is not affiliated with AWS.
High-Yield SAA-C03 Decision Model
If the scenario emphasizes…
Prefer…
Watch for traps
Lowest operational overhead
Managed services: Lambda, Fargate, S3, DynamoDB, Aurora, API Gateway, EventBridge
Do not choose EC2 when the requirement says “no servers to manage” unless control/customization is required.
Multi-AZ resilience
ALB/NLB across AZs, Auto Scaling group, RDS Multi-AZ, EFS, S3, DynamoDB
Read replicas improve read scale; they are not the same as automatic Multi-AZ failover.
Global low-latency web delivery
CloudFront, Route 53 latency/geolocation routing, Global Accelerator
CloudFront caches HTTP(S) content; Global Accelerator improves global routing for TCP/UDP without caching.
Decoupling components
SQS, SNS, EventBridge, Step Functions
SQS is pull queueing; SNS is push pub/sub; EventBridge is event routing and SaaS integration.
Object storage
Amazon S3
Do not choose EBS or EFS for internet-scale object storage.
Shared POSIX file system
Amazon EFS for Linux, FSx for Windows File Server for SMB, FSx for Lustre for high-performance compute
EBS attaches to one AZ and is block storage, not shared file storage by default.
Relational transactions
Amazon RDS or Aurora
DynamoDB is not relational and does not support joins like an RDBMS.
Massive key-value scale
DynamoDB
DAX is for read caching; Global Tables are for multi-Region active-active.
Private access to AWS services
VPC endpoints
Gateway endpoints are for S3/DynamoDB; interface endpoints use AWS PrivateLink.
Centralized multi-account governance
AWS Organizations, SCPs, Control Tower, IAM Identity Center
SCPs set maximum permissions; they do not grant permissions by themselves.
Audit API activity
AWS CloudTrail
CloudWatch monitors metrics/logs; AWS Config tracks resource configuration and compliance.
Threat detection
GuardDuty, Inspector, Macie, Security Hub
GuardDuty detects threats; Inspector assesses vulnerabilities; Macie discovers sensitive data in S3.
Backup and restore
AWS Backup, service snapshots, lifecycle policies, cross-Region copies where needed
Snapshots are not a substitute for application-level DR design when strict RTO/RPO is required.
Service Selection Matrix
Compute and Application Hosting
Service / feature
Best fit
Avoid / consider alternative
Exam cues
EC2
Full OS control, custom agents, legacy apps, specialized networking/storage
If “serverless,” “no infrastructure management,” or event-driven
AMIs, instance families, user data, Auto Scaling, placement groups
Auto Scaling group
Horizontal scaling and self-healing EC2 fleets
Not for scaling RDS directly
Use across multiple AZs; combine with ELB health checks
Elastic Load Balancing
Distribute traffic and improve availability
Not a database failover mechanism
Choose ALB, NLB, GWLB based on protocol and use case
Lambda
Event-driven, short-running, stateless functions
Long-running processes, persistent local state, specialized OS control
Integrates with API Gateway, S3, SQS, EventBridge, Step Functions
ECS on EC2
Containers with EC2 control
If you want no host management, use Fargate
Good for containerized apps needing cluster-level control
ECS on Fargate
Serverless containers
If custom host configuration is required
Task-level sizing, no EC2 host management
EKS
Kubernetes workloads
If Kubernetes is not required, ECS is usually simpler
Managed control plane; worker nodes can be EC2 or Fargate
Elastic Beanstalk
Simple PaaS deployment for web apps
If you need fine-grained architecture control
Provisions underlying resources such as EC2, ELB, Auto Scaling
App Runner
Simple container/web app deployment from source or image
Access limited by signing credentials and expiration
S3 access points
Manage access at scale for shared buckets
Useful for different apps/teams needing distinct policies
EBS, EFS, and Instance Store
Choice
Persistence
Scope
Best for
Trap
EBS
Persistent
AZ
EC2 boot/data volumes, databases on EC2
Volume is AZ-scoped; snapshots support restore/copy workflows
EFS
Persistent
Regional, multi-AZ
Shared Linux file storage
Not block storage; use NFS-compatible clients
Instance store
Ephemeral
Instance hardware
Caches, scratch data, temporary buffers
Data lost on stop/terminate or hardware failure events
FSx
Persistent
Service-dependent
Specialized file workloads
Choose the FSx family based on protocol/application
S3 high-yield concepts
Feature
What to know
Bucket
Regional container for objects. Bucket names are globally unique.
Object
Data plus metadata, addressed by key.
Versioning
Preserves multiple versions and helps recover from accidental deletion/overwrite.
Lifecycle policies
Move or expire objects based on age/rules to optimize cost.
Replication
Copy objects across buckets, often cross-Region or same-Region.
S3 Object Lock
Write-once-read-many retention use cases.
Block Public Access
Important guardrail against accidental public exposure.
Bucket policy
Resource-based access policy for bucket/object permissions.
Presigned URL
Time-limited access to a private object.
Transfer Acceleration
Faster long-distance uploads using edge locations.
Event notifications
Trigger workflows via Lambda, SQS, or SNS.
S3 storage class selection
Storage class
Best fit
S3 Standard
Frequently accessed data
S3 Intelligent-Tiering
Unknown or changing access patterns
S3 Standard-IA
Infrequently accessed data needing rapid access
S3 One Zone-IA
Infrequently accessed, re-creatable data stored in one AZ
S3 Glacier Instant Retrieval
Archive data needing immediate retrieval
S3 Glacier Flexible Retrieval
Archive data with flexible retrieval time
S3 Glacier Deep Archive
Lowest-cost long-term archive with slower retrieval
Common trap: Do not choose One Zone-IA for data that must remain resilient to AZ loss unless the scenario says the data is easily re-created.
EBS, EFS, FSx, and instance store
Storage
Scope
Best fit
EBS
Block storage for EC2 in one AZ
Boot volumes, databases on EC2, low-latency block storage
EFS
Managed NFS file system across AZs
Shared Linux file storage for multiple instances
FSx for Windows File Server
Managed Windows file shares
SMB, Windows workloads, Active Directory integration
FSx for Lustre
High-performance file system
HPC, analytics, ML, fast processing of large datasets
Instance store
Temporary local storage
Ephemeral cache/scratch data; data lost on stop/terminate depending on instance behavior
Trap: EBS volumes are AZ-scoped. If an EC2 instance needs access in another AZ, snapshots can be used to create a new volume there, but EBS is not a regional shared file system.
Storage decision path
flowchart TD
A[Need storage?] --> B{Object, block, or file?}
B -->|Object| C[S3]
B -->|Block for EC2| D[EBS]
B -->|Shared Linux file| E[EFS]
B -->|Windows file share| F[FSx for Windows File Server]
B -->|HPC fast file processing| G[FSx for Lustre]
C --> H{Access pattern known?}
H -->|Frequent| I[S3 Standard]
H -->|Unknown or changing| J[S3 Intelligent-Tiering]
H -->|Archive| K[S3 Glacier classes]
Database and Analytics Selection
Database Decision Table
Requirement
Choose
Why
Watch for
Managed relational database
RDS
MySQL, PostgreSQL, MariaDB, Oracle, SQL Server options
You still choose instance/storage/scaling patterns
Core infrastructure replicated; scale up during disaster
Warm standby
Moderate
Faster recovery
Scaled-down full environment always running
Active-active
Highest
Fastest failover
Mission-critical global workloads needing continuous service
Common Availability Traps
Trap
Correct reasoning
“Use one larger EC2 instance for reliability”
Use multiple instances across AZs behind a load balancer.
“Use read replica for automatic HA”
Use Multi-AZ for automatic relational failover; replicas are mainly for read scale and DR options.
“Put NAT gateway in one AZ for all private subnets”
Works, but creates cross-AZ dependency; prefer AZ-aligned NAT for resilient designs.
“Store sessions on EC2 local disk”
Breaks stateless scaling and replacement; externalize session state.
“Only snapshots meet strict DR”
Strict RTO/RPO may require warm standby or active-active design.
Trap 1: Ignoring “managed” and “least operational overhead”
If two answers work technically, the exam often favors the one with less administration when the scenario requests minimal operations.
Less optimal
Often better
Self-managed MySQL on EC2
RDS or Aurora
EC2 fleet for event functions
Lambda
EC2-hosted queue/broker without need
SQS, SNS, EventBridge, or Amazon MQ depending on requirement
Manual scaling
Auto Scaling or serverless scaling
Trap 2: Confusing HA with scalability
Design goal
Meaning
High availability
Survive failure and remain accessible
Scalability
Handle increased load
Elasticity
Automatically scale up/down
Durability
Preserve data
An Auto Scaling group may improve both availability and scalability, but an RDS read replica mostly improves read scalability, while Multi-AZ improves availability.
Trap 3: Choosing public access when private access is required
If the question asks for private connectivity to AWS services, consider:
VPC gateway endpoints for supported services such as S3 and DynamoDB
VPC interface endpoints powered by PrivateLink for many AWS services
Private subnets with no direct inbound internet route
Direct Connect or VPN for hybrid connectivity
Trap 4: Misreading “real-time”
“Real-time” can point to different services:
Scenario
Likely service
Streaming click events for custom consumers
Kinesis Data Streams
Deliver streaming data into S3
Kinesis Data Firehose
Pub/sub application notification
SNS
Event routing between applications
EventBridge
Queue-based background processing
SQS
Trap 5: Overusing Multi-Region
Multi-Region designs can improve disaster recovery and latency but add cost and complexity. If the question only requires high availability within a Region, Multi-AZ is often enough.
Trap 6: Forgetting state
Stateless compute is easier to scale and replace. Store state in managed external services:
State type
Common service
User sessions
ElastiCache, DynamoDB, application-managed external store
Uploaded files
S3
Shared application files
EFS or FSx
Relational data
RDS or Aurora
Key-value data
DynamoDB
Monitoring, Logging, and Operations
Need
Choose
Notes
Metrics and alarms
CloudWatch Metrics and Alarms
CPU, latency, errors, custom metrics
Application/system logs
CloudWatch Logs
Central log storage, metric filters, insights queries
Event routing from AWS services
EventBridge
Former CloudWatch Events patterns now generally EventBridge
Distributed tracing
X-Ray
Trace requests across services
API audit
CloudTrail
Who did what, when, from where
Configuration compliance
AWS Config
Rules, conformance packs, change history
Network traffic metadata
VPC Flow Logs
ENI/subnet/VPC-level flow records
Load balancer request logs
ELB access logs
Request-level traffic analysis
S3 object-level access audit
CloudTrail data events, S3 server access logs where appropriate
Know difference from management events
Patch/config management
Systems Manager
Run Command, Patch Manager, Session Manager, Inventory
No-SSH instance access
Systems Manager Session Manager
Avoids opening inbound SSH when configured properly
Infrastructure as code
CloudFormation, CDK
Repeatable deployments and drift management
Notes and examples
Monitoring, operations, and governance
Service
High-yield use
CloudWatch Alarms
Alert or trigger actions based on metrics
CloudWatch Logs
Centralize application/system logs
CloudWatch Logs Insights
Query logs
X-Ray
Trace distributed applications
Systems Manager
Patch, run commands, manage inventory, Session Manager access
AWS Backup
Central backup policies across supported services
Trusted Advisor
Recommendations across cost, security, fault tolerance, performance, and service limits
Service Quotas
View/request quota increases
Health Dashboard
AWS service events and account-specific health
Control Tower
Multi-account landing zone governance
Trap: For secure shell access without opening inbound SSH, Systems Manager Session Manager is often a better answer than a bastion host, assuming prerequisites are met.
Migration and Hybrid Architecture
Requirement
Service / pattern
Notes
Database migration with minimal downtime
AWS DMS
Homogeneous or heterogeneous migrations; use SCT for schema conversion where needed
Schema conversion
AWS Schema Conversion Tool
Helps convert database schemas between engines
Online file/data transfer
DataSync
Moves data between on-premises, AWS storage services, and edge locations
Large offline/edge data movement
AWS Snow Family
Physical devices for migration, edge compute, disconnected environments
SFTP/FTPS/FTP managed transfer
AWS Transfer Family
Managed file transfer backed by S3 or EFS
Hybrid storage cache/gateway
Storage Gateway
File, volume, and tape gateway patterns
App discovery for migration
AWS Application Discovery Service
Inventory and dependency data
Migration tracking
AWS Migration Hub
Central migration progress visibility
VMware workloads in AWS
VMware Cloud on AWS
Rehost VMware-based environments
Mainframe modernization
AWS Mainframe Modernization
Specialized modernization use cases
Cost Optimization Reference
Area
High-yield choices
Compute purchasing
Match steady usage to Savings Plans/Reserved Instances; use Spot for fault-tolerant work; use On-Demand for flexibility.
EC2 sizing
Use Auto Scaling, Compute Optimizer, metrics, and right-sizing.
Select appropriate engine, use read replicas only when needed, scale capacity to workload
Networking
Watch NAT Gateway data processing, cross-AZ traffic, data transfer out, and unnecessary public paths
Monitoring
Set budgets, alarms, and cost allocation tags
Architecture
Prefer managed/serverless where it reduces idle capacity and operations
Cost tools
Tool
Use
AWS Budgets
Track spend or usage against thresholds
Cost Explorer
Analyze historical cost and usage
Cost and Usage Reports
Detailed billing data for analysis
Compute Optimizer
Rightsizing recommendations for supported resources
Pricing Calculator
Estimate architecture costs before deployment
Common trap: “Cheapest” is not always “best.” If the scenario requires high availability, durability, or compliance, avoid options that save money by violating stated requirements.
Keyword Decoder for Exam Questions
Keywords in question
Likely answer direction
“Decouple,” “buffer,” “consumer unavailable”
SQS
“Fanout to multiple subscribers”
SNS, often SNS to SQS queues
“Route events from SaaS/AWS services”
EventBridge
“Coordinate multiple steps with retries”
Step Functions
“No servers,” “event-driven function”
Lambda
“Containers without managing instances”
ECS on Fargate
“Kubernetes”
EKS
“Shared file system for Linux EC2 instances”
EFS
“SMB file shares / Windows users”
FSx for Windows File Server
“Static website hosting”
S3 plus CloudFront if edge/cache/TLS/custom domain patterns apply
“Global content cache”
CloudFront
“Static anycast IPs, TCP/UDP acceleration”
Global Accelerator
“Private access to S3 without NAT”
S3 gateway endpoint
“Private access to AWS APIs in VPC”
Interface endpoint
“Central hub for many VPCs”
Transit Gateway
“Non-transitive VPC connection”
VPC peering
“Audit user/API actions”
CloudTrail
“Configuration drift/compliance”
AWS Config
“Detect compromised credentials or suspicious traffic”
GuardDuty
“Find sensitive data in S3”
Macie
“Managed Microsoft AD”
AWS Directory Service
“Temporary AWS credentials”
IAM role / STS
“Maximum permissions guardrail across accounts”
SCP
“Web SQL injection/XSS protection”
AWS WAF
“DDoS protection”
AWS Shield
“Encrypt and control keys”
KMS
“Rotate database password”
Secrets Manager
Common SAA-C03 Architecture Traps
Trap
Better exam answer
Choosing EC2 for every workload
Prefer managed/serverless when the requirement values low operations.
AZs are inside a Region; Region failure needs multi-Region design.
Using NACLs as primary app security
Security groups are usually primary workload firewalls; NACLs are subnet-level guardrails.
Opening SSH/RDP to the internet
Prefer Session Manager, bastion with restrictions, VPN, or private access patterns.
Storing credentials in code/user data
Use IAM roles, Secrets Manager, Parameter Store.
Using NAT gateway for private access to S3/DynamoDB
Gateway endpoints can avoid public internet/NAT for S3/DynamoDB access.
Using CloudTrail for performance metrics
Use CloudWatch for metrics/logs; CloudTrail for API audit.
Using Config for threat detection
Use GuardDuty for threat detection; Config for resource compliance/history.
Using S3 as a mounted POSIX file system
Use EFS/FSx for file semantics; S3 is object storage.
Using EBS for multi-instance shared storage
Use EFS/FSx unless the scenario specifically supports a clustered block design.
Treating SQS as synchronous messaging
SQS is asynchronous pull-based decoupling.
Ignoring idempotency
Retries and at-least-once delivery require idempotent processing.
Picking active-active DR for all systems
Match DR strategy to RTO/RPO and cost constraints.
Last-Minute Review Checklist
Can you choose between ALB, NLB, and GWLB from protocol and routing requirements?
Can you explain public vs private subnet routing, NAT gateway, internet gateway, and VPC endpoints?
Can you distinguish security groups from NACLs without hesitation?
Can you select S3, EBS, EFS, FSx, or instance store from storage semantics?
Can you distinguish RDS Multi-AZ, read replicas, Aurora replicas, and Aurora Global Database?
Can you choose DynamoDB, DAX, ElastiCache, Redshift, OpenSearch, and Neptune by workload type?
Can you pick SQS, SNS, EventBridge, Kinesis, and Step Functions by integration pattern?
Can you identify when IAM roles, resource policies, permission boundaries, and SCPs apply?
Can you map CloudWatch, CloudTrail, Config, GuardDuty, Inspector, Macie, and Security Hub to their jobs?
Can you select backup/restore, pilot light, warm standby, or active-active based on DR requirements?
Can you spot cost-optimization cues without sacrificing required availability or security?
How to think like SAA-C03
Many questions describe a business workload and ask for the best or most cost-effective architecture. The right answer usually follows from the stated constraints.
If the question says…
Think first about…
Common trap
“Least operational overhead”
Managed or serverless services
Choosing EC2 because it is familiar
“Highly available across AZs”
Multi-AZ design, managed HA, load balancing
Single EC2 instance, single NAT gateway, single DB instance
“Decouple components”
SQS, SNS, EventBridge, Kinesis
Direct synchronous calls between services
“Cost-effective for variable traffic”
Auto Scaling, serverless, Spot where appropriate
Overprovisioned always-on instances
“Static website or static assets”
S3 plus CloudFront
EC2 web servers for static content
“Shared file system for Linux EC2”
Amazon EFS
EBS attached to multiple instances generally not the right default
Can users access the system when needed? Use Multi-AZ, load balancing, Auto Scaling, health checks, and failover.
Durability
Is data preserved after hardware or service failures? Use S3, backups, replication, snapshots, and managed database durability features.
Fault tolerance
Can the workload keep running after component failure? Design without single points of failure.
Disaster recovery
How quickly and how much data can be recovered? Understand backup/restore, pilot light, warm standby, and multi-site active-active at a conceptual level.
Elasticity
Can capacity increase and decrease automatically? Use Auto Scaling, serverless services, and managed scaling.
Notes and examples
Shared responsibility model
AWS is responsible for security of the cloud. Customers are responsible for security in the cloud.
Area
AWS responsibility
Customer responsibility
Physical data centers
Facilities, hardware, physical controls
Select Regions/AZs as needed
Managed services infrastructure
Underlying hosts and service platform
Configure access, encryption, networking, logging
EC2
Physical host, hypervisor
OS patching, security groups, IAM, app security
S3
Storage infrastructure
Bucket policies, public access settings, encryption choices, lifecycle
RDS
Managed database platform
DB configuration, user access, backups/retention choices, parameter settings
Exam trap: AWS manages more for serverless and managed services, but customers still configure identity, access, data classification, network exposure, and logging.
Networking and VPC review
VPC fundamentals
Feature
What to remember
VPC
Isolated virtual network in a Region.
Subnet
Lives in one Availability Zone. Public/private depends on routing, not the name.
Public subnet
Route table sends internet-bound traffic to an Internet Gateway.
Private subnet
No direct route to Internet Gateway for inbound internet access.
Internet Gateway
Allows public internet connectivity for resources with public IPs and proper routing.
NAT Gateway
Lets private subnet resources initiate outbound internet traffic. Managed and preferred over NAT instances for most exam scenarios.
Route table
Controls where network traffic is directed.
Security group
Stateful instance-level or ENI-level firewall. Allows rules only.
Network ACL
Stateless subnet-level firewall. Allows and denies rules.
VPC endpoint
Private access to supported AWS services without using public internet paths.
Notes and examples
Security groups vs network ACLs
Decision point
Security group
Network ACL
Scope
ENI/resource level
Subnet level
State
Stateful
Stateless
Rule type
Allow only
Allow and deny
Return traffic
Automatically allowed
Must be explicitly allowed
Common use
Control instance or load balancer traffic
Broad subnet guardrails or explicit deny patterns
Common candidate mistake: Choosing a network ACL when the question asks for normal application access control. Security groups are the default control for instance-level access.
Public, private, and database subnets
Workload
Typical placement
Public load balancer
Public subnets across multiple AZs
EC2 application servers
Private subnets behind a load balancer
RDS database
Private subnets in a DB subnet group
NAT Gateway
Public subnet, with private subnets routing outbound internet traffic through it
Bastion host, if used
Public subnet, tightly restricted inbound access
VPC connectivity options
Need
Good AWS option
Connect VPCs one-to-one
VPC peering
Connect many VPCs and on-premises networks centrally
Transit Gateway
Private connection from on-premises to AWS
Direct Connect
Encrypted tunnel over internet
Site-to-Site VPN
Private access to AWS services from VPC
VPC endpoints
Private service exposure across VPCs/accounts
AWS PrivateLink
Hybrid DNS resolution
Route 53 Resolver endpoints
Trap: VPC peering is not transitive. If VPC A peers with B and B peers with C, A does not automatically reach C through B.
Route 53, CloudFront, and edge networking
Service
Use when…
Route 53
You need DNS, health checks, routing policies, domain registration, or failover routing.
CloudFront
You need global content delivery, caching, TLS at the edge, signed URLs/cookies, or lower latency for static/dynamic content.
Global Accelerator
You need static anycast IPs and optimized routing to regional endpoints, often for non-HTTP or latency-sensitive apps.
AWS WAF
You need web-layer filtering, managed rules, IP sets, or protection against common web exploits.
Shield
You need DDoS protection capabilities.
Route 53 routing policy quick table
Routing policy
Best fit
Simple
Basic DNS response, no special routing logic
Weighted
Split traffic by percentage, such as blue/green or A/B
Latency-based
Send users to the Region with lowest latency
Failover
Active-passive failover using health checks
Geolocation
Route based on user location
Geoproximity
Route by geographic proximity, optionally with bias
Multivalue answer
Return multiple healthy records
Compute and load balancing
EC2 purchasing and capacity
Option
Best fit
Watch for
On-Demand
Short-term, unpredictable workloads
Higher cost than commitment models
Reserved Instances
Steady EC2 usage with commitment
Less flexible than On-Demand
Savings Plans
Flexible commitment-based savings
Applies depending on plan type and usage
Spot Instances
Fault-tolerant, interruptible workloads
Can be interrupted; not ideal for critical single-instance apps
Dedicated Hosts
Compliance or licensing requiring physical host visibility/control
Higher cost and management overhead
Capacity Reservations
Need capacity assurance in a specific AZ
Does not automatically reduce cost unless combined appropriately
Notes and examples
Auto Scaling
Feature
Review point
Launch template
Preferred modern way to define EC2 configuration for Auto Scaling.
Desired capacity
Target number of instances.
Minimum/maximum
Bounds for scaling.
Scaling policy
Adds/removes capacity based on metrics or schedules.
Health checks
Auto Scaling can replace unhealthy instances.
Multi-AZ
Use subnets in multiple AZs for high availability.
Trap: Auto Scaling improves elasticity and availability, but it does not by itself make a stateful application safe. Store state outside instances, such as in RDS, DynamoDB, EFS, S3, or ElastiCache.
Elastic Load Balancing
Load balancer
Layer
Use when…
Application Load Balancer
Layer 7
HTTP/HTTPS routing, host/path rules, containers, WebSockets, target groups
Network Load Balancer
Layer 4
Very high performance TCP/UDP/TLS, static IP needs, low latency
Gateway Load Balancer
Layer 3/4 appliance insertion
Deploying third-party virtual appliances like firewalls
Classic Load Balancer
Legacy
Usually not the preferred answer for new architectures
ALB across public subnets, EC2 Auto Scaling across private subnets
Managed relational DB failover
RDS Multi-AZ or Aurora
Stateless application tier
Store sessions externally, use Auto Scaling
Static content high availability
S3 with CloudFront
Queue-based workload resilience
SQS plus Auto Scaling consumers and DLQ
Global failover
Route 53 health checks and failover routing, or appropriate multi-Region design
Notes and examples
Disaster recovery approaches
Pattern
Review meaning
Backup and restore
Lowest cost, slower recovery
Pilot light
Minimal critical core running, scale up during disaster
Warm standby
Scaled-down full environment ready to expand
Multi-site active-active
Multiple active environments, fastest recovery, highest complexity/cost
Exam decision rule: If the question asks for the lowest cost DR option and can tolerate slower recovery, backup and restore is usually favored. If it asks for very fast recovery, warm standby or active-active may be more appropriate.
Migration, hybrid, and data transfer
Need
AWS service
Database migration with minimal downtime
AWS Database Migration Service
Convert database schema between engines
AWS Schema Conversion Tool
Transfer large datasets online
AWS DataSync
SFTP/FTPS/FTP managed endpoints
AWS Transfer Family
Offline bulk data transfer
AWS Snow Family
Hybrid storage integration
AWS Storage Gateway
Discover on-premises inventory
AWS Application Discovery Service
Rehost servers to AWS
AWS Application Migration Service
Central backup management
AWS Backup
Storage Gateway types
Type
Use
File Gateway
File interface to S3-backed storage
Volume Gateway
Block storage with cached or stored volume patterns
Tape Gateway
Virtual tape replacement for backup workflows
High-yield service comparison tables
S3 vs EBS vs EFS
Requirement
Choose
Store images, backups, logs, static assets
S3
Boot volume for EC2
EBS
Block storage for database on EC2
EBS
Shared POSIX file system across Linux EC2 instances
EFS
Long-term archive
S3 Glacier storage classes
Temporary scratch data tied to an instance
Instance store
Notes and examples
ALB vs NLB vs CloudFront
Requirement
Choose
Path-based or host-based HTTP routing
ALB
TCP/UDP, extreme performance, static IP support
NLB
Global caching and edge delivery
CloudFront
Web application firewall at edge or ALB
AWS WAF with CloudFront or ALB
Fixed global entry IPs with regional endpoints
Global Accelerator
SQS vs SNS vs EventBridge vs Kinesis
Requirement
Choose
Buffer work between producers and consumers
SQS
Fanout notifications to multiple subscribers
SNS
Event routing from AWS/SaaS/custom apps
EventBridge
Ordered high-volume streaming analytics
Kinesis Data Streams
Load streaming data into S3/Redshift/OpenSearch
Kinesis Data Firehose
Coordinate multi-step workflow
Step Functions
RDS Multi-AZ vs read replica
Requirement
Choose
Automatic failover for relational DB
Multi-AZ
Scale read traffic
Read replica
Cross-Region read locality
Cross-Region read replica where supported
Improve write scaling
Usually not read replicas; consider architecture/database choice
Reduce admin for connection storms
RDS Proxy
Fast final-review checklist
Before answering an SAA-C03 scenario question, ask:
What is the primary requirement? Cost, availability, security, performance, or operational simplicity?
Is the workload stateful or stateless?
Does it need relational features, key-value scale, file storage, object storage, or block storage?
Is traffic synchronous, queued, pub/sub, event-driven, or streaming?
Is the architecture single-AZ, Multi-AZ, or Multi-Region?
Does the question require private connectivity or public access?
Can a managed or serverless service reduce operational overhead?
Are there hidden cost drivers such as idle capacity, cross-AZ transfer, NAT processing, or overprovisioned storage?
Does the proposed answer satisfy every stated constraint, not just one?