SAA-C03 Syllabus: What AWS Solutions Architects Need to Master

The SAA-C03 exam remains the current AWS Certified Solutions Architect – Associate exam in October 2026. The syllabus is organized around four outcomes rather than a service-by-service catalogue: Design Secure Architectures (30%), Design Resilient Architectures (26%), Design High-Performing Architectures (24%), and Design Cost-Optimized Architectures (20%).

That structure tells candidates how to study. AWS expects you to select architecture based on requirements and trade-offs, not merely identify what EC2, S3, RDS, Lambda, or VPC are. A strong candidate can explain why one design is safer, more resilient, faster, or more economical under the stated constraints.

The syllabus also includes a broad in-scope service list, but not every service deserves equal memorization. Focus first on the architectural decisions that repeatedly connect identity, networks, compute, storage, databases, integration, recovery, monitoring, and cost.

Security is the largest domain for a reason

Start with identity and least privilege, then move into network exposure, encryption, secrets, data access, and security services. Ask who or what needs access, to which resource, from where, and under which conditions.

Understand IAM users, roles, policies, resource policies, organizations, federation, KMS, Secrets Manager, Cognito, WAF, Shield, GuardDuty, and related controls at the level required to choose a design.

Security questions often become easier when you distinguish authentication, authorization, network reachability, and data protection instead of mixing them together.

Security study should use scenarios with competing controls. For example, require private database access from a serverless function while minimizing secret management. That forces identity, networking, and data protection into one decision. SAA-C03 questions often test the intersection rather than a single isolated service.

Resilience begins with failure-domain thinking

High availability and fault tolerance involve different failure and recovery guarantees, so begin with the failure boundary rather than duplication alone. Know what an Availability Zone failure, instance failure, regional failure, dependency failure, or data corruption means for the design. Multi-AZ, multi-region, backups, queues, retries, and health checks solve different problems.

Design degraded modes where appropriate. A service that can queue work or serve cached data may provide better continuity than one that attempts full functionality until every dependency recovers.

Resilience scenarios should identify what happens to state. Replacing stateless compute is easy; databases, queues, files, caches, and session stores determine whether the business process continues. Ask where state lives and how it is replicated, restored, or reconstructed.

Performance depends on workload shape

High-performing architecture includes compute elasticity, storage selection, database design, caching, networking, ingestion, and processing. Begin with latency, throughput, concurrency, access pattern, and peak behavior.

Do not automatically choose larger resources. Managed services, horizontal scaling, caching, asynchronous processing, or a different data model may improve performance more efficiently.

Use metrics to validate assumptions. Architecture should include enough observability to know whether the chosen pattern is meeting its performance goal.

Performance questions benefit from recognizing bottleneck categories: compute saturation, storage latency, database contention, network transfer, serialization, synchronous dependency, or uneven partitioning. The right service choice follows the bottleneck instead of generic claims about speed.

Cost optimization is architecture, not cleanup

FinOps principles connect utilization, allocation, lifecycle, data transfer, and unit economics to service selection. Choose pricing and resource models according to workload stability and flexibility. Savings Plans or reserved capacity can help predictable usage, while serverless or elastic models may fit spiky demand.

Include engineering effort. A self-managed service that saves infrastructure spend may still cost more once patching, availability, backup, and incident work are included.

Cost optimization should account for transfer and operational effort. Cross-AZ traffic, NAT processing, cross-region replication, idle test environments, and long log retention can all surprise teams. A design that is cheap in compute may still have poor unit economics.

Networking should be studied as a packet path

Build confidence with AWS VPC design and learn subnets, route tables, internet and NAT gateways, endpoints, peering, Transit Gateway, Direct Connect, VPN, load balancing, Route 53, CloudFront, and security controls.

Draw traffic from user to application to data store. Identify where the route is chosen, where traffic is filtered, how names resolve, and where TLS terminates.

Networking questions become much easier when you reason from the path rather than remember isolated service definitions.

Networking study should include DNS and service endpoints. Route tables can be correct while name resolution sends traffic somewhere unexpected, and private connectivity can change how names resolve. Trace both the control plane and the packet path.

Storage choices follow access and durability requirements

Know the differences among S3 object storage, EBS block storage, EFS or FSx file storage, and archival tiers. Use access pattern, sharing, latency, throughput, lifecycle, and recovery to choose.

Understand S3 lifecycle, storage classes, replication, versioning, encryption, and access policies well enough to match business requirements.

Backups and replication are not identical. Replication can copy corruption or deletion; independent recovery points protect different failure modes.

Storage selection should include failure and recovery. An object store may provide extreme durability but still need versioning or backup for logical deletion. A block volume may be snapshotted, but the application might require coordinated consistency. Match the protection pattern to the failure.

Database selection is a model decision

RDS and Aurora fit relational workloads; DynamoDB fits key-value/document patterns with different scaling and access assumptions; ElastiCache handles cache use cases; Redshift serves analytics; other services address graph, document, or specialized needs.

Ask whether the workload needs transactions, joins, flexible schema, predictable key access, global distribution, analytics, or caching before selecting a service.

Database performance questions often hinge on read replicas, indexes, caching, partition design, connection behavior, or separating analytical load from transactions.

Database questions often hide scaling direction. Read replicas help read-heavy relational workloads; caching reduces repeated reads; DynamoDB partitioning supports different access patterns; queues can smooth write bursts. Avoid using one database technology to solve every performance symptom.

Migration and integration patterns connect the domains

Choosing among cloud migration strategies—including rehosting, replatforming, and refactoring—changes the integration work a migration requires. Application integration services such as SQS, SNS, EventBridge, Step Functions, API Gateway, and messaging can decouple components, absorb bursts, and improve failure isolation.

Modernizing during migration can add value but also risk. Choose a sequence that meets deadlines and preserves a path to later improvement.

Migration questions should separate the immediate move from the desired end state. A rehost can satisfy a data-center deadline, followed by replatforming or refactoring later. The best answer may prioritize risk reduction today while preserving modernization options.

Identity questions often include cross-account or federated access. Understand when to use roles, IAM Identity Center, resource policies, and organization controls instead of creating long-lived users in every account. The secure design usually minimizes standing credentials and centralizes lifecycle where practical.

Resilience also includes decoupling. Queues, events, retries, and asynchronous workflows can stop a temporary dependency failure from taking down the whole request path. But retries need backoff and idempotency, or they can amplify an outage.

Performance design should include edge and content-delivery choices. CloudFront, Global Accelerator, load balancing, caching, and regional placement solve different latency and availability problems. Select them from traffic behavior rather than treating all global services as interchangeable.

Cost questions may ask for the most economical architecture that still meets the requirement, not the cheapest single service. Compare managed-service premiums with labor, data transfer, storage lifecycle, and required resilience.

Before the exam, redraw several common architectures from memory: highly available web application, event-driven workload, secure private application, analytics pipeline, and hybrid connection. Then critique each one against all four SAA-C03 domains.

Security and cost can conflict when teams over-isolate or duplicate resources without a clear threat model. The exam expects designs that meet security requirements with appropriate complexity, not maximum separation at any price.

Resilience and performance can also conflict. Synchronous replication may improve recovery characteristics while increasing write latency. Caching can improve response time while introducing staleness. Learn to recognize these tensions instead of expecting one option to dominate every domain.

Use the official in-scope service list as a boundary for breadth, then prioritize the services that appear repeatedly in architecture patterns. Deep reasoning about common building blocks is more useful than shallow memorization of every service name.

On the final review, revisit every practice error that came from misreading a requirement. SAA-C03 often gives enough technical information; the difficulty is choosing which constraint controls the architecture.

The strongest candidates keep those trade-offs visible while they eliminate answer choices.

Use official objectives to keep broad architecture study from turning into random service memorization.

Measure readiness by design explanations

Use SAA-C03 readiness evidence to identify weak domains before practicing mixed scenarios. For every answer, state the requirement that made it correct and the requirement that made the nearest distractor wrong. This builds decision skill rather than answer memory.

The syllabus is broad, but the repeated reasoning is manageable: secure the access, tolerate the right failures, meet performance needs, and control cost without adding unnecessary complexity.

Final practice should mix domains and force explanation. After choosing an answer, name the security, resilience, performance, and cost consequences even if the question emphasizes only one. That habit develops the systems thinking expected from a solutions architect.