AWS SAA-C03 Solutions Architect Associate guide for secure, resilient, high-performing, and cost-optimized AWS architecture decisions across compute, storage, database, networking, identity, and integration patterns.
This guide is for candidates preparing for AWS Certified Solutions Architect - Associate (SAA-C03) and for readers who need a stronger review of AWS design trade-offs. The exam is not a service flash-card test. It is a decision test: choose the right storage, networking, database, compute, resiliency, security, and cost pattern under an explicit constraint such as latency, operational effort, failure tolerance, compliance, or budget.
SAA-C03 stays in the solutions-architect lane. AWS expects you to design solutions based on the AWS Well-Architected Framework, not administer day-two operations, write application code, or run detailed data-science workflows. Strong answers usually balance more than one pillar: the secure answer still has to be resilient, the high-performing answer still has to be cost-aware, and the low-cost answer still has to satisfy the requirement.
Gateway endpoint: Route-table-based private path from a VPC to Amazon S3 or DynamoDB.
NAT gateway: Managed outbound path that lets private subnets reach the internet or public service endpoints.
ALB / NLB: Application Load Balancer versus Network Load Balancer, which usually means Layer 7 routing versus Layer 4 traffic handling.
As of May 17, 2026, AWS’s current SAA-C03 exam guide states:
AWS’s current exam guide breaks SAA-C03 into four weighted domains:
This guide follows that structure directly.
| Official domain | Weight | What this guide emphasizes |
|---|---|---|
| 1. Design Secure Architectures | 30% | IAM, resource policies, identity federation, private access, network controls, encryption, key management, data protection, and secure workload boundaries. |
| 2. Design Resilient Architectures | 26% | Multi-AZ design, loose coupling, scaling, recovery, failover, backups, fault tolerance, and managed-service resilience patterns. |
| 3. Design High-Performing Architectures | 24% | Compute fit, database selection, storage classes, network latency, caching, data ingestion, scaling behavior, and performance trade-offs. |
| 4. Design Cost-Optimized Architectures | 20% | Right sizing, purchase options, storage lifecycle, database cost fit, network transfer cost, serverless fit, and operational effort. |
AWS lists technologies and concepts such as compute, networking, storage, databases, management/governance, migration, analytics, security, serverless, containers, AWS global infrastructure, AWS managed services, the Well-Architected Framework, and disaster recovery. Keep the study boundary there: this is architecture selection and trade-off reasoning, not deep service administration.
Most SAA-C03 stems can be worked through this loop.
flowchart LR
R["Requirement and constraint"] --> S["Security boundary"]
S --> A["Availability and failure model"]
A --> P["Performance and scale pattern"]
P --> C["Cost and operational effort"]
C --> V["Validate weakest pillar and eliminate distractors"]
V --> R
The exam rarely asks for the most powerful service in isolation. It asks for the smallest architecture that satisfies the named constraint without weakening another pillar that the stem makes mandatory.
flowchart LR
S["Study Plan"] --> D["Domain chapters"]
D --> L["Lesson pages"]
L --> C["Cheat Sheet and Glossary"]
C --> M["Mixed mocks and miss-log review"]
M --> R["Resources for final scope check"]
What to notice:
Use one of these paths:
| Scenario pressure | Strong SAA-C03 reasoning |
|---|---|
| Private workloads need AWS service access | Compare gateway endpoints, interface endpoints, NAT gateway, public endpoints, endpoint policies, and route-table behavior. |
| The app must survive an AZ failure | Check Multi-AZ placement, load balancing, stateless tiers, replicated data stores, health checks, and failover behavior. |
| Reads are slow but writes are acceptable | Compare cache, read replica, index/key design, database engine fit, and consistency requirement before replacing the whole data tier. |
| Global users need low latency | Separate CloudFront caching, Global Accelerator, Route 53 routing, Regional placement, and origin behavior. |
| Cost must drop without breaking requirements | Right size, change purchase model, lifecycle data, reduce NAT/cross-AZ/egress paths, and prefer managed/serverless fit where appropriate. |
| A security control blocks the design | Check IAM, resource policy, KMS key policy, security group, NACL, endpoint policy, and private route separately. |
| Trap | Better exam posture |
|---|---|
| Choosing the newest or biggest service | Choose the service that satisfies the stated constraint with the least operational burden. |
| Treating Multi-AZ and read replicas as interchangeable | Multi-AZ is primarily availability; read replicas are primarily read scale and sometimes DR support. |
| Using NAT for private AWS service access by habit | Prefer gateway or interface endpoints when private service access, policy control, or NAT cost reduction is the requirement. |
| Choosing CloudFront for every global scenario | Use CloudFront for cacheable HTTP/HTTPS content; use Global Accelerator for static Anycast IPs and non-cache acceleration. |
| Fixing performance with more compute only | Check caching, data model, database access pattern, network path, storage performance, and scaling policy first. |
| Optimizing cost by removing a required control | Keep security, availability, and compliance requirements intact while reducing waste. |
These are the same decisions that keep reappearing in different clothing:
Use the appendices as support layers rather than substitutes for the main guide:
If you only have time for one final pass before mocks, spend it on Secure Architectures and Resilient Architectures first. Those two domains carry the most weight and also influence how many performance and cost questions are solved.