SAA-C03 — AWS Certified Solutions Architect – Associate Cheat Sheet

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 overheadManaged services: Lambda, Fargate, S3, DynamoDB, Aurora, API Gateway, EventBridgeDo not choose EC2 when the requirement says “no servers to manage” unless control/customization is required.
Multi-AZ resilienceALB/NLB across AZs, Auto Scaling group, RDS Multi-AZ, EFS, S3, DynamoDBRead replicas improve read scale; they are not the same as automatic Multi-AZ failover.
Global low-latency web deliveryCloudFront, Route 53 latency/geolocation routing, Global AcceleratorCloudFront caches HTTP(S) content; Global Accelerator improves global routing for TCP/UDP without caching.
Decoupling componentsSQS, SNS, EventBridge, Step FunctionsSQS is pull queueing; SNS is push pub/sub; EventBridge is event routing and SaaS integration.
Object storageAmazon S3Do not choose EBS or EFS for internet-scale object storage.
Shared POSIX file systemAmazon EFS for Linux, FSx for Windows File Server for SMB, FSx for Lustre for high-performance computeEBS attaches to one AZ and is block storage, not shared file storage by default.
Relational transactionsAmazon RDS or AuroraDynamoDB is not relational and does not support joins like an RDBMS.
Massive key-value scaleDynamoDBDAX is for read caching; Global Tables are for multi-Region active-active.
Private access to AWS servicesVPC endpointsGateway endpoints are for S3/DynamoDB; interface endpoints use AWS PrivateLink.
Centralized multi-account governanceAWS Organizations, SCPs, Control Tower, IAM Identity CenterSCPs set maximum permissions; they do not grant permissions by themselves.
Audit API activityAWS CloudTrailCloudWatch monitors metrics/logs; AWS Config tracks resource configuration and compliance.
Threat detectionGuardDuty, Inspector, Macie, Security HubGuardDuty detects threats; Inspector assesses vulnerabilities; Macie discovers sensitive data in S3.
Backup and restoreAWS Backup, service snapshots, lifecycle policies, cross-Region copies where neededSnapshots are not a substitute for application-level DR design when strict RTO/RPO is required.

Service Selection Matrix

Compute and Application Hosting

Service / featureBest fitAvoid / consider alternativeExam cues
EC2Full OS control, custom agents, legacy apps, specialized networking/storageIf “serverless,” “no infrastructure management,” or event-drivenAMIs, instance families, user data, Auto Scaling, placement groups
Auto Scaling groupHorizontal scaling and self-healing EC2 fleetsNot for scaling RDS directlyUse across multiple AZs; combine with ELB health checks
Elastic Load BalancingDistribute traffic and improve availabilityNot a database failover mechanismChoose ALB, NLB, GWLB based on protocol and use case
LambdaEvent-driven, short-running, stateless functionsLong-running processes, persistent local state, specialized OS controlIntegrates with API Gateway, S3, SQS, EventBridge, Step Functions
ECS on EC2Containers with EC2 controlIf you want no host management, use FargateGood for containerized apps needing cluster-level control
ECS on FargateServerless containersIf custom host configuration is requiredTask-level sizing, no EC2 host management
EKSKubernetes workloadsIf Kubernetes is not required, ECS is usually simplerManaged control plane; worker nodes can be EC2 or Fargate
Elastic BeanstalkSimple PaaS deployment for web appsIf you need fine-grained architecture controlProvisions underlying resources such as EC2, ELB, Auto Scaling
App RunnerSimple container/web app deployment from source or imageComplex networking or custom orchestration needsLow-ops web service hosting
AWS BatchBatch jobs, queues, compute environmentsInteractive request/response workloadsGood for scheduled or queued compute-heavy jobs
LightsailSimple VPS-style workloadsEnterprise-scale, complex VPC, advanced AWS architectureUsually not the SAA answer for scalable production designs
Notes and examples

Load Balancer Selection

Load balancerLayer / protocolsChoose whenCommon trap
Application Load BalancerLayer 7 HTTP/HTTPS/gRPCPath-based routing, host-based routing, HTTP headers, containers, WebSocketsNot for static IP requirement by itself
Network Load BalancerLayer 4 TCP/UDP/TLSExtreme performance, static IP support, preserve source IP, non-HTTP protocolsDoes not perform advanced HTTP routing
Gateway Load BalancerLayer 3 transparent appliance insertionDeploy firewalls, IDS/IPS, network appliancesNot a general web app load balancer
Classic Load BalancerLegacyExisting older architecturesPrefer ALB or NLB for new designs

EC2 Purchasing and Capacity

OptionUse whenKey point
On-DemandUnpredictable, short-term, no commitmentHighest flexibility
Savings PlansSteady compute usageFlexible discount model based on committed spend
Reserved InstancesPredictable instance usageCapacity/discount characteristics vary by type
Spot InstancesFault-tolerant, interruptible workloadsDesign for interruption; use mixed instance policies
Dedicated HostsLicense-bound workloads, host-level visibilityUseful for compliance or software licensing constraints
Dedicated InstancesPhysical isolation at instance levelLess host-level control than Dedicated Hosts
Capacity ReservationsNeed capacity assurance in an AZCapacity assurance does not automatically reduce cost

Storage Reference

Storage Service Selection

RequirementChooseWhy
Durable object storage, static assets, data lakeS3Object storage, lifecycle policies, replication, event notifications
Block storage for EC2EBSPersistent block volumes in an AZ
Temporary high-performance local diskInstance storeEphemeral storage tied to instance lifecycle
Shared Linux file systemEFSManaged NFS, multi-AZ regional file system
Windows SMB file sharesFSx for Windows File ServerManaged Windows-native file storage
High-performance file system for HPC/MLFSx for LustreHigh-throughput file processing, integrates with S3
NetApp ONTAP-compatible featuresFSx for NetApp ONTAPEnterprise file workloads, snapshots, multiprotocol access
Long-term archival object storageS3 Glacier storage classesArchive cost optimization with retrieval tradeoffs
On-premises file gateway to cloud-backed storageAWS Storage GatewayHybrid access to AWS-backed storage
Notes and examples

Amazon S3 Quick Decisions

FeatureUse forNotes
VersioningProtect against overwrite/deleteOften paired with lifecycle and replication
Lifecycle policiesMove/expire objects by age or prefix/tagCommon cost-optimization answer
S3 Intelligent-TieringUnknown or changing access patternsOptimizes tiering without manual class selection
S3 Standard-IAInfrequently accessed but rapid retrieval neededHas retrieval cost considerations
S3 One Zone-IARe-creatable infrequently accessed dataLower resilience than multi-AZ storage classes
S3 Glacier Instant RetrievalArchive data needing immediate accessHigher access speed than deeper archive classes
S3 Glacier Flexible Retrieval / Deep ArchiveLong-term archiveRetrieval time and access frequency matter
Cross-Region ReplicationRegion-level resilience, compliance, lower-latency readsRequires versioning; plan KMS permissions if encrypted
Same-Region ReplicationSame-Region copies, log aggregation, account separationNot a Region-level DR solution
S3 Object LockWORM retention and legal hold patternsRequires careful bucket/versioning design
S3 Transfer AccelerationFaster long-distance uploads to S3Uses AWS edge network
S3 presigned URLsTemporary object accessAccess limited by signing credentials and expiration
S3 access pointsManage access at scale for shared bucketsUseful for different apps/teams needing distinct policies

EBS, EFS, and Instance Store

ChoicePersistenceScopeBest forTrap
EBSPersistentAZEC2 boot/data volumes, databases on EC2Volume is AZ-scoped; snapshots support restore/copy workflows
EFSPersistentRegional, multi-AZShared Linux file storageNot block storage; use NFS-compatible clients
Instance storeEphemeralInstance hardwareCaches, scratch data, temporary buffersData lost on stop/terminate or hardware failure events
FSxPersistentService-dependentSpecialized file workloadsChoose the FSx family based on protocol/application

S3 high-yield concepts

FeatureWhat to know
BucketRegional container for objects. Bucket names are globally unique.
ObjectData plus metadata, addressed by key.
VersioningPreserves multiple versions and helps recover from accidental deletion/overwrite.
Lifecycle policiesMove or expire objects based on age/rules to optimize cost.
ReplicationCopy objects across buckets, often cross-Region or same-Region.
S3 Object LockWrite-once-read-many retention use cases.
Block Public AccessImportant guardrail against accidental public exposure.
Bucket policyResource-based access policy for bucket/object permissions.
Presigned URLTime-limited access to a private object.
Transfer AccelerationFaster long-distance uploads using edge locations.
Event notificationsTrigger workflows via Lambda, SQS, or SNS.

S3 storage class selection

Storage classBest fit
S3 StandardFrequently accessed data
S3 Intelligent-TieringUnknown or changing access patterns
S3 Standard-IAInfrequently accessed data needing rapid access
S3 One Zone-IAInfrequently accessed, re-creatable data stored in one AZ
S3 Glacier Instant RetrievalArchive data needing immediate retrieval
S3 Glacier Flexible RetrievalArchive data with flexible retrieval time
S3 Glacier Deep ArchiveLowest-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

StorageScopeBest fit
EBSBlock storage for EC2 in one AZBoot volumes, databases on EC2, low-latency block storage
EFSManaged NFS file system across AZsShared Linux file storage for multiple instances
FSx for Windows File ServerManaged Windows file sharesSMB, Windows workloads, Active Directory integration
FSx for LustreHigh-performance file systemHPC, analytics, ML, fast processing of large datasets
Instance storeTemporary local storageEphemeral 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

RequirementChooseWhyWatch for
Managed relational databaseRDSMySQL, PostgreSQL, MariaDB, Oracle, SQL Server optionsYou still choose instance/storage/scaling patterns
Higher-performance managed relational, cloud-nativeAuroraCompatible with MySQL/PostgreSQL, managed replication/storageAurora Replicas help read scale and availability
Serverless relational scalingAurora ServerlessVariable or intermittent relational workloadsConfirm relational requirement; otherwise DynamoDB may fit
Multi-AZ relational failoverRDS Multi-AZ or Aurora HA designAvailability and automatic failoverNot primarily for read scaling
Read-heavy relational workloadRead replicasOffload readsReplication lag can occur; not synchronous failover by default
Key-value or document access at massive scaleDynamoDBServerless NoSQL, predictable access patternsModel access patterns first; avoid relational joins
Microsecond read cache for DynamoDBDAXRead-heavy DynamoDB workloadsDAX is not a general cache for RDS
In-memory cache/session storeElastiCacheRedis OSS or Memcached-compatible cachingCache invalidation and persistence differ by engine
Data warehouse / BI analyticsRedshiftColumnar analytics and SQL over large datasetsNot for OLTP transactional workloads
Search and log analyticsOpenSearch ServiceFull-text search, observability analyticsNot a primary relational database
Graph relationshipsNeptuneHighly connected dataChoose only when graph queries are central
Time-series dataTimestreamMetrics, IoT, time-series workloadsNot a general-purpose OLTP database
MongoDB-compatible managed databaseDocumentDBDocument workloads needing MongoDB compatibilityCheck compatibility requirements conceptually
Ledger / immutable journalQLDBVerifiable transaction logNot a general blockchain network
Notes and examples

RDS and Aurora Exam Traps

ConceptCorrect distinction
Multi-AZHigh availability/failover across AZs; standby is not normally used for application reads in traditional RDS Multi-AZ designs.
Read replicaRead scaling and some DR patterns; asynchronous replication; can be promoted.
Automated backupsPoint-in-time restore capability within configured retention; separate from manual snapshots.
Manual snapshotUser-managed backup artifact; persists until deleted.
Storage autoscalingHandles storage growth; does not replace compute scaling decisions.
Aurora cluster endpointWriter endpoint for primary instance.
Aurora reader endpointLoad-balances read connections across replicas.
Aurora Global DatabaseCross-Region read scaling and DR pattern for Aurora workloads.

DynamoDB Cheat Sheet

FeatureUse whenNotes
Partition keyDirect key-value lookupsGood key design prevents hot partitions
Sort keyRange queries and item collectionsEnables composite primary key patterns
Global secondary indexQuery by alternative partition/sort keySeparate throughput/capacity considerations depending on mode
Local secondary indexAlternate sort key with same partition keyDefined at table creation
On-demand capacityUnpredictable or spiky trafficSimpler capacity management
Provisioned capacityPredictable trafficCan use auto scaling
DynamoDB StreamsReact to item-level changesOften paired with Lambda
TTLExpire items automaticallyExpiration is not guaranteed to be immediate
Global TablesMulti-Region active-active table replicationConflict handling and application design matter
TransactionsACID operations across itemsUseful when multi-item consistency is required
DAXRead-through cacheBest for read-heavy, eventually consistent access patterns

Networking and Connectivity

VPC Building Blocks

ComponentPurposeExam notes
VPCIsolated virtual networkCIDR planning matters; avoid overlap for peering/VPN/TGW
Public subnetSubnet with route to internet gatewayPublic IP plus route enables inbound internet path
Private subnetNo direct route to internet gatewayOutbound internet usually through NAT for IPv4
Internet gatewayVPC internet connectivityHorizontally scaled AWS-managed gateway
NAT gatewayOutbound IPv4 internet from private subnetsPlace per-AZ for AZ resilience; route private subnets appropriately
Egress-only internet gatewayOutbound-only IPv6IPv6 does not use NAT in the same way
Route tableDetermines traffic pathMost specific route wins
Security groupStateful instance/ENI firewallAllows only; return traffic automatically allowed
Network ACLStateless subnet firewallAllow and deny; inbound and outbound rules evaluated separately
VPC Flow LogsNetwork metadata logsUseful for traffic troubleshooting, not packet payload capture
Notes and examples

Security Group vs NACL

FeatureSecurity groupNetwork ACL
ScopeENI/instance levelSubnet level
StateStatefulStateless
RulesAllow rules onlyAllow and deny rules
Return trafficAutomatically allowedMust be explicitly allowed
EvaluationAll rules consideredOrdered by rule number
Common useApplication access controlBroad subnet guardrails or explicit deny patterns

VPC Endpoint Selection

Endpoint typeSupportsChoose when
Gateway endpointS3, DynamoDBPrivate access from VPC without internet/NAT for these services
Interface endpointMany AWS services and partner/private servicesPrivateLink-powered ENI with private IPs
Gateway Load Balancer endpointNetwork appliancesTransparent traffic inspection through GWLB
Endpoint policyAccess control at endpointRestrict which principals/actions/resources can use endpoint

Hybrid and Multi-VPC Connectivity

RequirementChooseNotes
Simple private connection between two VPCsVPC peeringNon-transitive; CIDRs cannot overlap
Many VPCs/accounts needing hub-and-spoke routingTransit GatewayCentralized routing at scale
Private service exposure without VPC peeringAWS PrivateLinkProvider exposes endpoint service; consumer uses interface endpoint
Encrypted connection over internet to on-premisesSite-to-Site VPNFaster to deploy than dedicated private connectivity
Dedicated private connectivityAWS Direct ConnectOften paired with VPN for encryption/backup patterns
Client remote access to VPCAWS Client VPNUser-to-VPC VPN access
Central DNS resolution hybridRoute 53 Resolver endpointsInbound/outbound DNS between VPC and on-premises

Edge and DNS

Service / featureChoose forKey distinction
Route 53 simple routingSingle targetNo advanced routing logic
Route 53 weighted routingControlled traffic splitBlue/green, canary, gradual migrations
Route 53 latency routingLowest-latency RegionBased on user location and latency measurements
Route 53 failover routingActive-passive DNS failoverUses health checks
Route 53 geolocation routingRoute by user geographyCompliance/localization patterns
Route 53 geoproximity routingRoute based on location with biasRequires traffic flow concepts
CloudFrontCache HTTP(S), edge delivery, TLS, WAF integrationContent distribution and origin protection
Global AcceleratorStatic anycast IPs, global routing for TCP/UDPNo content caching
AWS WAFLayer 7 web filteringAttach to CloudFront, ALB, API Gateway, AppSync where supported
AWS ShieldDDoS protectionStandard protection is automatic; advanced protection is for higher-level needs

Application Integration and Messaging

ServicePatternChoose whenTrap
SQS StandardQueue, at-least-once deliveryDecouple producers/consumers, maximize throughputOrder is best-effort; duplicates possible
SQS FIFOOrdered queueStrict ordering and deduplication are requiredThroughput and design differ from Standard
SQS dead-letter queueFailure isolationCapture messages after repeated processing failuresDLQ does not fix root cause; monitor it
SNSPub/sub push notificationsFanout to many subscribersSubscribers receive pushed messages; not a pull queue
EventBridgeEvent bus/routingSaaS/AWS/app events, rules, event-driven architecturesMore routing semantics than SNS
Step FunctionsWorkflow orchestrationMulti-step processes, retries, branching, human/task integrationBetter than custom retry-state code in Lambda
Kinesis Data StreamsReal-time streaming ingestionCustom consumers, ordered shard processingConsumer app manages stream processing
Kinesis Data FirehoseDelivery streamLoad streaming data to S3, Redshift, OpenSearch, third-party targetsLess custom consumer control than Data Streams
Amazon MQManaged message brokerNeed ActiveMQ/RabbitMQ compatibilityPrefer SQS/SNS for cloud-native decoupling
API GatewayManaged API front doorAuth, throttling, usage plans, Lambda/private integrationsALB may be simpler for HTTP routing to containers/EC2
AppSyncGraphQL APIsReal-time/mobile GraphQL patternsNot a generic REST API gateway
Notes and examples

Messaging and event services

ServiceBest fit
SQS Standard queueDecouple producers/consumers with high throughput and at-least-once delivery
SQS FIFO queueOrdered processing and exactly-once processing behavior within FIFO design constraints
SNSPub/sub fanout to subscribers
EventBridgeEvent bus, SaaS/AWS service events, routing by event patterns
Kinesis Data StreamsReal-time streaming data ingestion and custom consumers
Kinesis Data FirehoseLoad streaming data into destinations like S3, Redshift, OpenSearch, or third-party services
Step FunctionsOrchestrate workflows and stateful business processes
Amazon MQManaged message broker for protocols/apps needing broker compatibility

SQS review points

FeatureMeaning
Visibility timeoutTime a message is hidden after a consumer receives it. Set long enough for processing.
Dead-letter queueCaptures messages that fail repeatedly.
Long pollingReduces empty responses and cost.
Delay queue/message timerPostpones message availability.
FIFO queueOrdering and deduplication use cases.

Common trap: If one message must be delivered to many subscribers, use SNS fanout, not a single SQS queue with multiple competing consumers.

Security, Identity, and Governance

IAM Policy Evaluation Essentials

ControlWhat it doesExam distinction
Identity-based policyGrants permissions to IAM users/groups/rolesAttached to identity
Resource-based policyGrants access on a resourceCommon for S3, KMS, SQS, SNS, Lambda
IAM roleTemporary credentials assumed by trusted principalBest for EC2/Lambda/service access; avoid long-term keys
Trust policyDefines who can assume a roleDoes not define what the role can do after assumption
Permissions boundaryMaximum permissions for an identityDoes not grant permissions
SCPMaximum permissions for accounts/OUs in AWS OrganizationsDoes not grant permissions; affects member accounts
Session policyLimits temporary session permissionsFurther restricts role session
Explicit denyOverrides allowsKey policy evaluation rule
ABACAttribute/tag-based access controlUseful for scalable team/project access
Notes and examples

Security Service Selection

NeedChooseWhy
API activity auditCloudTrailManagement events, data events where enabled
Resource configuration history/complianceAWS ConfigTracks configuration changes and rules
Threat detectionGuardDutyAnalyzes logs/signals for suspicious activity
Vulnerability assessmentInspectorEC2, container image, and Lambda vulnerability findings where supported
Sensitive data discovery in S3MacieIdentifies and classifies sensitive data
Security findings aggregationSecurity HubCentral view mapped to standards
Investigation and behavior analysisDetectiveHelps analyze relationships behind findings
Web request filteringAWS WAFSQL injection/XSS rules, IP sets, rate-based rules
DDoS protectionAWS ShieldProtects against DDoS; advanced tier for enhanced protections
Central firewall policyFirewall ManagerMulti-account security policy management
Network firewallingAWS Network FirewallManaged network traffic filtering
Certificate provisioningACMPublic/private TLS certificates for supported integrations
Key managementKMSManaged keys, envelope encryption, audit integration
Dedicated HSM controlCloudHSMSingle-tenant hardware security modules
Secrets rotationSecrets ManagerSecrets storage with rotation support
Parameter/config storageSystems Manager Parameter StoreConfig values and simple secure strings
Workforce federationIAM Identity CenterCentralized access to AWS accounts/apps
App user identityCognitoUser pools and identity pools for applications

Encryption and Key Management

ScenarioPreferred pattern
Encrypt S3 with AWS-managed simplicitySSE-S3
Need KMS audit/control/key policiesSSE-KMS
Client controls encryption before uploadClient-side encryption
Database encryption at restEnable service-native KMS integration
TLS for public endpointACM certificate on ALB, CloudFront, API Gateway, etc.
Rotate database credentialsSecrets Manager rotation where supported
Cross-account KMS useKey policy plus IAM permission; both sides must allow

Minimal Policy Pattern Examples

Deny non-TLS access to an S3 bucket:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::example-bucket",
    "arn:aws:s3:::example-bucket/*"
  ],
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

Role trust policy concept for an AWS service assuming a role:

{
  "Effect": "Allow",
  "Principal": {
    "Service": "ec2.amazonaws.com"
  },
  "Action": "sts:AssumeRole"
}

IAM essentials

ConceptReview point
IAM userLong-term identity; avoid for applications when roles are possible.
IAM groupCollection of users; permissions management for users.
IAM roleAssumable identity with temporary credentials; preferred for AWS services.
IAM policyJSON permissions document.
Identity-based policyAttached to users, groups, or roles.
Resource-based policyAttached to resources such as S3 buckets, KMS keys, SQS queues, or Lambda functions.
STSProvides temporary security credentials.
Least privilegeGrant only required actions on required resources.
MFAStronger authentication, especially for privileged access.

Common trap: Applications running on EC2 should usually use an IAM role attached to the instance profile, not stored access keys.

AWS Organizations controls

FeatureUse
AWS OrganizationsCentral account management
Organizational unitsGroup accounts by function, environment, or governance boundary
Service control policiesSet maximum available permissions for accounts/OUs
Consolidated billingCentralized billing across accounts

Trap: An SCP does not grant permissions. It only limits what can be granted by identity/resource policies.

KMS and secrets

NeedService or feature
Managed encryption keysAWS KMS
Customer-managed key policies and rotation controlKMS customer managed keys
Store and rotate database credentialsAWS Secrets Manager
Store configuration parameters and simple secretsSystems Manager Parameter Store
Encrypt S3 objectsSSE-S3, SSE-KMS, or client-side encryption depending on requirements
Encrypt EBS volumesEBS encryption using KMS
Encrypt RDSRDS encryption using KMS, generally chosen at creation or via snapshot workflows

Logging and detection

ServiceUse
CloudTrailAPI activity and account governance audit trail
CloudWatchMetrics, logs, alarms, dashboards
AWS ConfigResource configuration history, compliance rules
GuardDutyThreat detection using logs and behavior analysis
Security HubCentral security findings and posture management
InspectorVulnerability management for supported workloads
MacieSensitive data discovery in S3
IAM Access AnalyzerAnalyze external access and policy findings

Trap: CloudWatch is not the same as CloudTrail. CloudWatch monitors metrics/logs; CloudTrail records API activity.

Resilience, High Availability, and Disaster Recovery

Resilience Pattern Selection

RequirementArchitecture pattern
Survive instance failureAuto Scaling group, ELB health checks, stateless app design
Survive AZ failureMulti-AZ subnets, load balancer across AZs, replicated data tier
Survive Region failureMulti-Region DR: backup/restore, pilot light, warm standby, or active-active
Stateless web tierStore session state outside instances: DynamoDB, ElastiCache, external identity/session store
Relational HARDS Multi-AZ, Aurora replicas/cluster design
Global read performanceCloudFront, DynamoDB Global Tables, Aurora Global Database, multi-Region read replicas where appropriate
Async task resilienceSQS with DLQ, idempotent consumers, retries with backoff
Workflow resilienceStep Functions retries/catches/timeouts
Object durability and recoveryS3 versioning, replication, Object Lock, lifecycle policies
Notes and examples

DR Strategy Comparison

StrategyCostRTO/RPO postureUse when
Backup and restoreLowestSlowest recoveryNon-critical workloads, cost-sensitive DR
Pilot lightLow to moderateFaster than restoreCore infrastructure replicated; scale up during disaster
Warm standbyModerateFaster recoveryScaled-down full environment always running
Active-activeHighestFastest failoverMission-critical global workloads needing continuous service

Common Availability Traps

TrapCorrect 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 optimalOften better
Self-managed MySQL on EC2RDS or Aurora
EC2 fleet for event functionsLambda
EC2-hosted queue/broker without needSQS, SNS, EventBridge, or Amazon MQ depending on requirement
Manual scalingAuto Scaling or serverless scaling

Trap 2: Confusing HA with scalability

Design goalMeaning
High availabilitySurvive failure and remain accessible
ScalabilityHandle increased load
ElasticityAutomatically scale up/down
DurabilityPreserve 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:

ScenarioLikely service
Streaming click events for custom consumersKinesis Data Streams
Deliver streaming data into S3Kinesis Data Firehose
Pub/sub application notificationSNS
Event routing between applicationsEventBridge
Queue-based background processingSQS

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 typeCommon service
User sessionsElastiCache, DynamoDB, application-managed external store
Uploaded filesS3
Shared application filesEFS or FSx
Relational dataRDS or Aurora
Key-value dataDynamoDB

Monitoring, Logging, and Operations

NeedChooseNotes
Metrics and alarmsCloudWatch Metrics and AlarmsCPU, latency, errors, custom metrics
Application/system logsCloudWatch LogsCentral log storage, metric filters, insights queries
Event routing from AWS servicesEventBridgeFormer CloudWatch Events patterns now generally EventBridge
Distributed tracingX-RayTrace requests across services
API auditCloudTrailWho did what, when, from where
Configuration complianceAWS ConfigRules, conformance packs, change history
Network traffic metadataVPC Flow LogsENI/subnet/VPC-level flow records
Load balancer request logsELB access logsRequest-level traffic analysis
S3 object-level access auditCloudTrail data events, S3 server access logs where appropriateKnow difference from management events
Patch/config managementSystems ManagerRun Command, Patch Manager, Session Manager, Inventory
No-SSH instance accessSystems Manager Session ManagerAvoids opening inbound SSH when configured properly
Infrastructure as codeCloudFormation, CDKRepeatable deployments and drift management
Notes and examples

Monitoring, operations, and governance

ServiceHigh-yield use
CloudWatch AlarmsAlert or trigger actions based on metrics
CloudWatch LogsCentralize application/system logs
CloudWatch Logs InsightsQuery logs
X-RayTrace distributed applications
Systems ManagerPatch, run commands, manage inventory, Session Manager access
AWS BackupCentral backup policies across supported services
Trusted AdvisorRecommendations across cost, security, fault tolerance, performance, and service limits
Service QuotasView/request quota increases
Health DashboardAWS service events and account-specific health
Control TowerMulti-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

RequirementService / patternNotes
Database migration with minimal downtimeAWS DMSHomogeneous or heterogeneous migrations; use SCT for schema conversion where needed
Schema conversionAWS Schema Conversion ToolHelps convert database schemas between engines
Online file/data transferDataSyncMoves data between on-premises, AWS storage services, and edge locations
Large offline/edge data movementAWS Snow FamilyPhysical devices for migration, edge compute, disconnected environments
SFTP/FTPS/FTP managed transferAWS Transfer FamilyManaged file transfer backed by S3 or EFS
Hybrid storage cache/gatewayStorage GatewayFile, volume, and tape gateway patterns
App discovery for migrationAWS Application Discovery ServiceInventory and dependency data
Migration trackingAWS Migration HubCentral migration progress visibility
VMware workloads in AWSVMware Cloud on AWSRehost VMware-based environments
Mainframe modernizationAWS Mainframe ModernizationSpecialized modernization use cases

Cost Optimization Reference

AreaHigh-yield choices
Compute purchasingMatch steady usage to Savings Plans/Reserved Instances; use Spot for fault-tolerant work; use On-Demand for flexibility.
EC2 sizingUse Auto Scaling, Compute Optimizer, metrics, and right-sizing.
StorageS3 lifecycle policies, Intelligent-Tiering for unknown access, delete unused EBS volumes/snapshots, choose correct EBS type.
Data transferKeep chatty components in same AZ when appropriate, use CloudFront for cacheable content, understand NAT/data processing implications conceptually.
DatabasesUse read replicas/caching for read pressure, right-size instances, use Aurora/DynamoDB scaling features when suitable.
ServerlessGood for variable workloads; monitor duration, memory, requests, and downstream costs.
GovernanceAWS Budgets, Cost Explorer, cost allocation tags, Organizations consolidated billing, CUR for detailed reporting.
Trusted AdvisorCost, security, fault tolerance, performance, and service quota checks depending on support plan features.
Notes and examples

Cost levers

AreaReview actions
ComputeRight-size instances, use Auto Scaling, Savings Plans/Reserved Instances for steady usage, Spot for interruptible workloads
StorageChoose correct S3 storage class, lifecycle old data, delete unused EBS volumes/snapshots
DatabasesSelect appropriate engine, use read replicas only when needed, scale capacity to workload
NetworkingWatch NAT Gateway data processing, cross-AZ traffic, data transfer out, and unnecessary public paths
MonitoringSet budgets, alarms, and cost allocation tags
ArchitecturePrefer managed/serverless where it reduces idle capacity and operations

Cost tools

ToolUse
AWS BudgetsTrack spend or usage against thresholds
Cost ExplorerAnalyze historical cost and usage
Cost and Usage ReportsDetailed billing data for analysis
Compute OptimizerRightsizing recommendations for supported resources
Pricing CalculatorEstimate 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 questionLikely 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

TrapBetter exam answer
Choosing EC2 for every workloadPrefer managed/serverless when the requirement values low operations.
Confusing horizontal and vertical scalingHorizontal adds instances/tasks; vertical changes instance size.
Assuming Multi-AZ means multi-RegionAZs are inside a Region; Region failure needs multi-Region design.
Using NACLs as primary app securitySecurity groups are usually primary workload firewalls; NACLs are subnet-level guardrails.
Opening SSH/RDP to the internetPrefer Session Manager, bastion with restrictions, VPN, or private access patterns.
Storing credentials in code/user dataUse IAM roles, Secrets Manager, Parameter Store.
Using NAT gateway for private access to S3/DynamoDBGateway endpoints can avoid public internet/NAT for S3/DynamoDB access.
Using CloudTrail for performance metricsUse CloudWatch for metrics/logs; CloudTrail for API audit.
Using Config for threat detectionUse GuardDuty for threat detection; Config for resource compliance/history.
Using S3 as a mounted POSIX file systemUse EFS/FSx for file semantics; S3 is object storage.
Using EBS for multi-instance shared storageUse EFS/FSx unless the scenario specifically supports a clustered block design.
Treating SQS as synchronous messagingSQS is asynchronous pull-based decoupling.
Ignoring idempotencyRetries and at-least-once delivery require idempotent processing.
Picking active-active DR for all systemsMatch 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 servicesChoosing EC2 because it is familiar
“Highly available across AZs”Multi-AZ design, managed HA, load balancingSingle EC2 instance, single NAT gateway, single DB instance
“Decouple components”SQS, SNS, EventBridge, KinesisDirect synchronous calls between services
“Cost-effective for variable traffic”Auto Scaling, serverless, Spot where appropriateOverprovisioned always-on instances
“Static website or static assets”S3 plus CloudFrontEC2 web servers for static content
“Shared file system for Linux EC2”Amazon EFSEBS attached to multiple instances generally not the right default
“Object storage, massive scale”Amazon S3EFS or EBS for object-style data
“Relational database with minimal admin”Amazon RDS or AuroraSelf-managed database on EC2
“NoSQL key-value, single-digit millisecond access”DynamoDBRDS when no relational features are needed
“Real-time streaming ingestion”Kinesis Data Streams / Firehose / MSKSQS for ordered streaming analytics
“Hybrid private connectivity”Site-to-Site VPN, Direct Connect, Transit GatewayPublic internet without stated acceptability
“Global low-latency content delivery”CloudFrontMulti-Region EC2 without caching

Core architecture principles

Availability, durability, and fault tolerance

ConceptSAA-C03 review
AvailabilityCan users access the system when needed? Use Multi-AZ, load balancing, Auto Scaling, health checks, and failover.
DurabilityIs data preserved after hardware or service failures? Use S3, backups, replication, snapshots, and managed database durability features.
Fault toleranceCan the workload keep running after component failure? Design without single points of failure.
Disaster recoveryHow quickly and how much data can be recovered? Understand backup/restore, pilot light, warm standby, and multi-site active-active at a conceptual level.
ElasticityCan 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.

AreaAWS responsibilityCustomer responsibility
Physical data centersFacilities, hardware, physical controlsSelect Regions/AZs as needed
Managed services infrastructureUnderlying hosts and service platformConfigure access, encryption, networking, logging
EC2Physical host, hypervisorOS patching, security groups, IAM, app security
S3Storage infrastructureBucket policies, public access settings, encryption choices, lifecycle
RDSManaged database platformDB 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

FeatureWhat to remember
VPCIsolated virtual network in a Region.
SubnetLives in one Availability Zone. Public/private depends on routing, not the name.
Public subnetRoute table sends internet-bound traffic to an Internet Gateway.
Private subnetNo direct route to Internet Gateway for inbound internet access.
Internet GatewayAllows public internet connectivity for resources with public IPs and proper routing.
NAT GatewayLets private subnet resources initiate outbound internet traffic. Managed and preferred over NAT instances for most exam scenarios.
Route tableControls where network traffic is directed.
Security groupStateful instance-level or ENI-level firewall. Allows rules only.
Network ACLStateless subnet-level firewall. Allows and denies rules.
VPC endpointPrivate access to supported AWS services without using public internet paths.
Notes and examples

Security groups vs network ACLs

Decision pointSecurity groupNetwork ACL
ScopeENI/resource levelSubnet level
StateStatefulStateless
Rule typeAllow onlyAllow and deny
Return trafficAutomatically allowedMust be explicitly allowed
Common useControl instance or load balancer trafficBroad 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

WorkloadTypical placement
Public load balancerPublic subnets across multiple AZs
EC2 application serversPrivate subnets behind a load balancer
RDS databasePrivate subnets in a DB subnet group
NAT GatewayPublic subnet, with private subnets routing outbound internet traffic through it
Bastion host, if usedPublic subnet, tightly restricted inbound access

VPC connectivity options

NeedGood AWS option
Connect VPCs one-to-oneVPC peering
Connect many VPCs and on-premises networks centrallyTransit Gateway
Private connection from on-premises to AWSDirect Connect
Encrypted tunnel over internetSite-to-Site VPN
Private access to AWS services from VPCVPC endpoints
Private service exposure across VPCs/accountsAWS PrivateLink
Hybrid DNS resolutionRoute 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

ServiceUse when…
Route 53You need DNS, health checks, routing policies, domain registration, or failover routing.
CloudFrontYou need global content delivery, caching, TLS at the edge, signed URLs/cookies, or lower latency for static/dynamic content.
Global AcceleratorYou need static anycast IPs and optimized routing to regional endpoints, often for non-HTTP or latency-sensitive apps.
AWS WAFYou need web-layer filtering, managed rules, IP sets, or protection against common web exploits.
ShieldYou need DDoS protection capabilities.

Route 53 routing policy quick table

Routing policyBest fit
SimpleBasic DNS response, no special routing logic
WeightedSplit traffic by percentage, such as blue/green or A/B
Latency-basedSend users to the Region with lowest latency
FailoverActive-passive failover using health checks
GeolocationRoute based on user location
GeoproximityRoute by geographic proximity, optionally with bias
Multivalue answerReturn multiple healthy records

Compute and load balancing

EC2 purchasing and capacity

OptionBest fitWatch for
On-DemandShort-term, unpredictable workloadsHigher cost than commitment models
Reserved InstancesSteady EC2 usage with commitmentLess flexible than On-Demand
Savings PlansFlexible commitment-based savingsApplies depending on plan type and usage
Spot InstancesFault-tolerant, interruptible workloadsCan be interrupted; not ideal for critical single-instance apps
Dedicated HostsCompliance or licensing requiring physical host visibility/controlHigher cost and management overhead
Capacity ReservationsNeed capacity assurance in a specific AZDoes not automatically reduce cost unless combined appropriately
Notes and examples

Auto Scaling

FeatureReview point
Launch templatePreferred modern way to define EC2 configuration for Auto Scaling.
Desired capacityTarget number of instances.
Minimum/maximumBounds for scaling.
Scaling policyAdds/removes capacity based on metrics or schedules.
Health checksAuto Scaling can replace unhealthy instances.
Multi-AZUse 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 balancerLayerUse when…
Application Load BalancerLayer 7HTTP/HTTPS routing, host/path rules, containers, WebSockets, target groups
Network Load BalancerLayer 4Very high performance TCP/UDP/TLS, static IP needs, low latency
Gateway Load BalancerLayer 3/4 appliance insertionDeploying third-party virtual appliances like firewalls
Classic Load BalancerLegacyUsually not the preferred answer for new architectures

Containers and serverless compute

ServiceBest fit
LambdaEvent-driven serverless functions, short-lived tasks, minimal infrastructure management
ECSManaged container orchestration on AWS
EKSKubernetes workloads on AWS
FargateServerless compute engine for containers; no EC2 management
Elastic BeanstalkPlatform management for applications with less infrastructure control
App RunnerSimple managed container/web app deployment
BatchBatch jobs, queues, and compute environments

Decision rule: If the question emphasizes “run containers without managing servers,” look for Fargate. If it emphasizes “Kubernetes,” look for EKS.

Databases and caching

Relational database choices

ServiceBest fit
Amazon RDSManaged relational databases such as MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server
Amazon AuroraAWS-designed relational database compatible with MySQL/PostgreSQL, often chosen for performance, scaling, and managed HA
RDS Multi-AZHigh availability and automatic failover
RDS read replicaRead scaling and, in some cases, cross-Region read/disaster recovery patterns
Aurora ReplicasRead scaling and failover targets within Aurora clusters
RDS ProxyConnection pooling for applications, especially Lambda-heavy relational workloads
Notes and examples

Trap: Multi-AZ is for availability/failover, not read scaling in the usual SAA-C03 decision pattern. Read replicas are for read scaling.

NoSQL and purpose-built databases

ServiceBest fit
DynamoDBServerless key-value/document database, high-scale low-latency access
DynamoDB global tablesMulti-Region active-active access patterns
DynamoDB DAXIn-memory cache for DynamoDB read acceleration
ElastiCache for Redis/MemcachedIn-memory caching, session stores, low-latency reads
MemoryDB for RedisDurable Redis-compatible in-memory database
RedshiftData warehousing and analytics
OpenSearch ServiceSearch, log analytics, full-text queries
NeptuneGraph database
DocumentDBMongoDB-compatible document workloads
TimestreamTime series data
KeyspacesApache Cassandra-compatible workloads
QLDBLedger database with immutable transaction log

Database decision rules

RequirementLikely answer
SQL, joins, transactions, managed operationsRDS or Aurora
Need relational HA across AZsRDS Multi-AZ or Aurora
Scale reads for relational workloadRead replicas
Key-value access at massive scaleDynamoDB
Microsecond caching layerElastiCache
Data warehouse reportingRedshift
Search across logs/documentsOpenSearch Service
Graph relationshipsNeptune
Immutable verifiable ledgerQLDB

Reliability and disaster recovery patterns

High-availability patterns

RequirementArchitecture pattern
Web app highly available across AZsALB across public subnets, EC2 Auto Scaling across private subnets
Managed relational DB failoverRDS Multi-AZ or Aurora
Stateless application tierStore sessions externally, use Auto Scaling
Static content high availabilityS3 with CloudFront
Queue-based workload resilienceSQS plus Auto Scaling consumers and DLQ
Global failoverRoute 53 health checks and failover routing, or appropriate multi-Region design
Notes and examples

Disaster recovery approaches

PatternReview meaning
Backup and restoreLowest cost, slower recovery
Pilot lightMinimal critical core running, scale up during disaster
Warm standbyScaled-down full environment ready to expand
Multi-site active-activeMultiple 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

NeedAWS service
Database migration with minimal downtimeAWS Database Migration Service
Convert database schema between enginesAWS Schema Conversion Tool
Transfer large datasets onlineAWS DataSync
SFTP/FTPS/FTP managed endpointsAWS Transfer Family
Offline bulk data transferAWS Snow Family
Hybrid storage integrationAWS Storage Gateway
Discover on-premises inventoryAWS Application Discovery Service
Rehost servers to AWSAWS Application Migration Service
Central backup managementAWS Backup

Storage Gateway types

TypeUse
File GatewayFile interface to S3-backed storage
Volume GatewayBlock storage with cached or stored volume patterns
Tape GatewayVirtual tape replacement for backup workflows

High-yield service comparison tables

S3 vs EBS vs EFS

RequirementChoose
Store images, backups, logs, static assetsS3
Boot volume for EC2EBS
Block storage for database on EC2EBS
Shared POSIX file system across Linux EC2 instancesEFS
Long-term archiveS3 Glacier storage classes
Temporary scratch data tied to an instanceInstance store
Notes and examples

ALB vs NLB vs CloudFront

RequirementChoose
Path-based or host-based HTTP routingALB
TCP/UDP, extreme performance, static IP supportNLB
Global caching and edge deliveryCloudFront
Web application firewall at edge or ALBAWS WAF with CloudFront or ALB
Fixed global entry IPs with regional endpointsGlobal Accelerator

SQS vs SNS vs EventBridge vs Kinesis

RequirementChoose
Buffer work between producers and consumersSQS
Fanout notifications to multiple subscribersSNS
Event routing from AWS/SaaS/custom appsEventBridge
Ordered high-volume streaming analyticsKinesis Data Streams
Load streaming data into S3/Redshift/OpenSearchKinesis Data Firehose
Coordinate multi-step workflowStep Functions

RDS Multi-AZ vs read replica

RequirementChoose
Automatic failover for relational DBMulti-AZ
Scale read trafficRead replica
Cross-Region read localityCross-Region read replica where supported
Improve write scalingUsually not read replicas; consider architecture/database choice
Reduce admin for connection stormsRDS Proxy

Fast final-review checklist

Before answering an SAA-C03 scenario question, ask:

  1. What is the primary requirement? Cost, availability, security, performance, or operational simplicity?
  2. Is the workload stateful or stateless?
  3. Does it need relational features, key-value scale, file storage, object storage, or block storage?
  4. Is traffic synchronous, queued, pub/sub, event-driven, or streaming?
  5. Is the architecture single-AZ, Multi-AZ, or Multi-Region?
  6. Does the question require private connectivity or public access?
  7. Can a managed or serverless service reduce operational overhead?
  8. Are there hidden cost drivers such as idle capacity, cross-AZ transfer, NAT processing, or overprovisioned storage?
  9. Does the proposed answer satisfy every stated constraint, not just one?
  10. Does any answer add unnecessary complexity?

Put the review into practice