AWS Architecture Patterns for SAP-C02 (2026)
The AWS Certified Solutions Architect – Professional exam goes far beyond asking you to identify individual services. It presents complex, cross‑domain scenarios where you must select, combine, and justify architectural patterns that solve enterprise business problems. This guide introduces the major architecture patterns you need to recognise, compare, and apply in the exam. It focuses on why a pattern exists, when to use it, and the trade‑offs that shape design decisions—the exact thinking required of a Professional Solutions Architect.
Architecture patterns are reusable, proven solutions to recurring design problems. They bridge the gap between knowing what an AWS service does and knowing how to build an enterprise‑grade system that balances all six pillars of the AWS Well‑Architected Framework.
What Is an AWS Architecture Pattern?
An architecture pattern is a general, repeatable solution to a common architectural problem within a given context. In AWS, patterns describe how to combine services like VPCs, IAM, EC2, and S3 into a coherent design that addresses specific business or technical requirements.
- Definition – A blueprint for structuring cloud resources that solves a well‑understood design challenge.
- Benefits – Patterns accelerate design decisions, reduce risk, and provide a common vocabulary for architects. They embody best practices distilled from thousands of real‑world implementations.
- Enterprise use cases – Enterprises use patterns to standardise governance (multi‑account architecture), extend on‑premises networks (hybrid cloud), and ensure business continuity (disaster recovery).
- Relationship with AWS Well‑Architected Framework – Every pattern is evaluated against the six pillars: operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability. A pattern might optimise for reliability while accepting higher cost—the architect’s job is to match that trade‑off to the business need.
Core Architecture Patterns
The following patterns are the most frequently referenced and evaluated in SAP‑C02. The table below gives a snapshot; the subsequent sections explore each in depth.
| Pattern | Primary Goal | Common AWS Services | Exam Importance |
|---|---|---|---|
| Multi‑Account Architecture | Governance, billing isolation, security | Organizations, IAM Identity Center, SCPs, Control Tower | Very High |
| Landing Zone | Pre‑configured, secure multi‑account foundation | Control Tower, Custom automation, AWS Config, CloudTrail | High |
| Hybrid Cloud | Extend on‑premises to AWS, integrate identity & network | Direct Connect, VPN, Transit Gateway, Storage Gateway, Directory Service | Very High |
| Multi‑Region Architecture | Global resilience, low‑latency user access | Route 53, Global Accelerator, S3 Cross‑Region Replication, Aurora Global Database | High |
| High Availability | Keep workloads running despite component failures | Multi‑AZ, Auto Scaling, Elastic Load Balancing | Very High |
| Disaster Recovery | Recover from regional or large‑scale outages | Backup, Pilot Light, Warm Standby, Multi‑Site Active‑Active | High |
| Event‑Driven Architecture | Decouple components, react to events asynchronously | EventBridge, SNS, SQS, Lambda, Step Functions | High |
| Microservices | Decompose applications into independent, scalable services | ECS/EKS, API Gateway, Lambda, DynamoDB | Medium |
| Serverless | Eliminate server management, scale automatically | Lambda, API Gateway, DynamoDB, S3, EventBridge | Medium |
| Data Lake | Ingest and store vast amounts of raw data for analytics | S3, Glue, Lake Formation, Athena, EMR | Medium |
| Analytics Platform | Process and visualise data at scale | Kinesis, Glue, EMR, Redshift, QuickSight | Medium |
| Secure Enterprise Network | Defense‑in‑depth, centralized inspection, least‑privilege network access | VPC, Transit Gateway, Network Firewall, WAF, Shield, PrivateLink | High |
| Cost‑Optimised Architecture | Minimise waste, match cost to usage | Savings Plans, Spot, Auto Scaling, S3 Lifecycle, Compute Optimizer | Medium |
Multi‑Account Architecture
A multi‑account strategy is the foundation of enterprise governance. Instead of a single account containing all workloads, you spread resources across multiple accounts grouped into organisational units (OUs). This provides natural billing separation, security boundaries, and blast‑radius containment.
- AWS Organizations – Manage all accounts centrally. Apply service control policies (SCPs) at the OU or account level to set permission guardrails (e.g., deny the ability to disable CloudTrail).
- IAM Identity Center – Provide single sign‑on for workforce identities. Users assume permission sets that map to IAM roles in member accounts, eliminating the need for long‑term access keys.
- Centralised logging and monitoring – Consolidate CloudTrail logs and AWS Config data into a dedicated logging account. Use Security Hub and GuardDuty with a delegated administrator for centralised threat detection.
- Shared networking – Use AWS Resource Access Manager to share Transit Gateways, subnets, or PrivateLink endpoints with other accounts, reducing cost and simplifying management.
When to use: Any organisation with more than a handful of workloads, teams, or environments. The exam frequently tests your ability to design a multi‑account structure that balances security, cost, and operational efficiency.
Hybrid Cloud Architecture
Most enterprises do not start in the cloud; they extend existing data centres. Hybrid architecture connects on‑premises environments with AWS, enabling a unified network, identity, and operational model.
- Network connectivity – Use AWS Direct Connect for dedicated, high‑bandwidth, low‑latency links, or Site‑to‑Site VPN for encrypted internet‑based tunnels. A common pattern combines both: Direct Connect as primary, VPN as backup, terminated on a Transit Gateway.
- Identity federation – Integrate on‑premises Active Directory with IAM Identity Center or use AD Connector to extend existing credentials to AWS.
- Storage integration – Storage Gateway provides file, volume, and tape gateways that make S3, EBS snapshots, and Glacier appear as local storage. DataSync automates large data transfers between on‑premises and AWS.
- Unified DNS – Use Route 53 Resolver endpoints and forwarding rules so that resources in both environments can resolve each other’s DNS names.
When to use: Migration projects, burst‑to‑cloud scenarios, compliance requirements that keep certain data on‑premises, or existing investments in data centre infrastructure.
Multi‑Region Architecture
Designing for multiple AWS Regions addresses two primary goals: disaster recovery (covered in the next section) and global application performance.
- Active‑Active – All regions serve production traffic simultaneously. Requires careful data replication (DynamoDB Global Tables, Aurora Global Database) and global traffic management (Route 53 latency‑based routing, Global Accelerator). Provides the lowest latency and highest availability but is the most complex and expensive pattern.
- Active‑Passive – One primary region handles traffic; a secondary region stands by for failover. Data is replicated asynchronously. Route 53 failover routing or Global Accelerator health checks redirect traffic when needed. Simpler than active‑active but introduces failover latency and potential data loss (RPO > 0).
- Global Accelerator – Provides two static anycast IPs that route users to the nearest healthy endpoint over the AWS global network, improving latency without requiring DNS changes.
Trade‑offs: Active‑active minimises latency and provides zero‑downtime failover but increases cost and data synchronisation complexity. Active‑passive is cheaper but requires manual or automated failover procedures that must be thoroughly tested.
High Availability & Disaster Recovery
These two patterns are related but distinct. High availability (HA) protects against component failures within a region; disaster recovery (DR) protects against regional failures.
High availability uses:
- Multi‑AZ deployments – EC2 instances in an Auto Scaling group across multiple AZs behind an Elastic Load Balancer; RDS Multi‑AZ; Aurora multi‑AZ replication.
- Automatic failover – Health checks from ELB and Route 53 remove unhealthy targets. Aurora automatically promotes a read replica in the event of a primary failure.
Disaster recovery strategies vary by business requirement:
| Strategy | RTO | RPO | Complexity | Cost | Use Case |
|---|---|---|---|---|---|
| Backup & Restore | Hours | Hours | Low | Lowest | Non‑critical workloads |
| Pilot Light | 10s of minutes | Minutes | Medium | Low‑Medium | Core infrastructure always running; scale up during failover |
| Warm Standby | Minutes | Seconds | High | Medium‑High | Business‑critical applications needing rapid recovery |
| Multi‑Site Active‑Active | Near zero | Near zero | Very High | High | Mission‑critical systems requiring zero downtime |
Architect insight: The exam often asks you to select the most cost‑effective DR strategy that meets specific RTO/RPO targets. You must know the relative costs and characteristics of each strategy without second‑guessing.
Event‑Driven Architecture
Event‑driven architectures decouple producers and consumers, allowing components to scale independently and react to state changes asynchronously.
- EventBridge – Serverless event bus that routes events from AWS services, custom applications, and SaaS providers to targets like Lambda, Step Functions, SQS, and Kinesis. Use rules and event patterns to filter and transform events.
- SNS – Pub/sub messaging for fan‑out to multiple subscribers (email, SMS, Lambda, SQS, HTTP).
- SQS – Durable, pull‑based message queues. Standard queues offer high throughput; FIFO queues guarantee ordering. Combine with dead‑letter queues to handle failed messages.
- Step Functions – Visual workflow orchestration. Coordinate multiple Lambda functions, handle errors, and run long‑running processes with built‑in retry and timeout logic.
Exam relevance: SAP‑C02 scenarios frequently present a monolithic application and ask you to decouple it. Expect to choose the right combination of EventBridge, SQS, and Step Functions based on message ordering, latency, and retry requirements.
Serverless Architecture
Serverless architectures shift operational responsibilities to AWS, enabling you to focus on business logic. They scale automatically with demand and charge only for actual usage.
- Lambda – Execute code without provisioning servers. Use for stateless, event‑triggered processing. Combine with API Gateway to build RESTful APIs.
- API Gateway – Fully managed API management. Supports REST and WebSocket APIs, integrates with Lambda, and includes features like throttling, caching, and authorisation.
- DynamoDB – Serverless NoSQL database with single‑digit‑millisecond performance and on‑demand capacity mode.
- S3 – Serverless object storage. Use as a durable event source for Lambda (S3 event notifications) or as a static website host with CloudFront.
Limitations: Serverless introduces cold starts, execution timeouts (15 minutes for Lambda), and potential cost surprises at high, consistent throughput. The exam might ask you to choose between serverless and container‑based solutions for a given workload—evaluate based on predictability, latency requirements, and operational maturity.
Enterprise Security Architecture
Security architecture spans all patterns and is a constant thread through the exam.
- IAM – Enforce least privilege with fine‑grained policies. Use roles for cross‑account access and avoid long‑term credentials. Permission boundaries and SCPs create guardrails that limit what even administrators can do.
- KMS – Centralise encryption key management. Use customer‑managed keys for sensitive data and enable automatic key rotation.
- Networking security – Implement defense in depth: WAF at the edge, security groups at the instance, NACLs at the subnet, VPC Flow Logs for traffic analysis. Use PrivateLink to keep traffic off the internet.
- Threat detection – GuardDuty analyses DNS, VPC Flow Logs, and CloudTrail for anomalies. Security Hub aggregates findings and checks compliance against standards like CIS Benchmarks.
- Centralised governance – Use AWS Organizations to delegate security administration to a security account, with CloudTrail and Config aggregated there. Apply SCPs to deny risky actions (e.g., stopping CloudTrail, deleting KMS keys).
Exam insight: Security is never a standalone question—it weaves through every scenario. Expect to design IAM policies, choose encryption options, and recommend network controls within the context of broader business requirements.
Cost Optimization Architecture
Cost‑optimised architectures deliver the required performance and resilience at the lowest appropriate cost. This pattern is less about a specific service topology and more about applying financial discipline across all other patterns.
- Reserved capacity – Purchase Reserved Instances or Savings Plans for steady‑state workloads. Use Compute Savings Plans for flexibility across instance families and regions.
- Spot Instances – Leverage spare EC2 capacity for fault‑tolerant, interruptible tasks (batch processing, CI/CD, stateless web servers). Use Spot Fleet with multiple instance types to increase resilience.
- Auto Scaling – Scale out during peaks, scale in during troughs. Use scheduled scaling for predictable patterns and dynamic scaling for reactive responses.
- Storage tiering – Implement S3 Lifecycle policies to transition data to cheaper storage classes (S3 Intelligent‑Tiering, Glacier) based on access patterns. Delete old snapshots and unattached EBS volumes.
- Right‑sizing – Continuously analyse with Compute Optimizer and Trusted Advisor, and migrate to smaller instance families when possible.
Pattern integration: Cost optimization is not a standalone pattern but a lens applied to every other pattern. For example, a multi‑region active‑active architecture must justify its cost relative to a warm‑standby approach. The exam will test your ability to select the most cost‑effective solution that still meets all functional and non‑functional requirements.
Pattern Selection Matrix
Use this matrix to compare patterns across critical dimensions. It will help you quickly evaluate trade‑offs during scenario analysis.
| Pattern | Scalability | Availability | Complexity | Cost | Typical Workloads |
|---|---|---|---|---|---|
| Multi‑Account | High (organisational) | High (isolated blast radius) | Medium | Medium | Enterprise workloads, SaaS, regulated industries |
| Hybrid Cloud | Medium (bandwidth‑limited) | Medium (redundant links) | High | High (Direct Connect, data transfer) | Gradual migration, burst‑to‑cloud, legacy integration |
| Multi‑Region Active‑Active | Very High | Very High | Very High | Very High | Global consumer apps, real‑time gaming |
| High Availability (Multi‑AZ) | High | Very High (within region) | Medium | Medium | Most production web applications and databases |
| Disaster Recovery (Warm Standby) | Medium | High (regional failover) | High | High | Business‑critical enterprise apps |
| Event‑Driven | Very High (decoupled) | High (asynchronous) | Medium | Medium (pay‑per‑use) | Order processing, workflows, IoT |
| Serverless | Very High (automatic) | High (managed) | Low‑Medium | Low‑Medium (pay‑per‑use) | Microservices, APIs, data processing |
| Enterprise Security | N/A (cross‑cutting) | Very High (defense in depth) | High | Medium‑High | All enterprise architectures |
| Cost‑Optimised | Varies | Varies | Medium | Optimised | All architectures with financial constraints |
How SAP‑C02 Tests Architecture Patterns
SAP‑C02 questions rarely ask “What is a multi‑account architecture?” Instead, they embed patterns in realistic enterprise scenarios. You will be presented with a narrative describing a company’s current state, pain points, and future goals, and then asked to choose the most appropriate architecture or to identify the next step in a migration plan.
Typical scenario categories include:
- Enterprise migration – Choosing between rehost, replatform, or refactor; selecting the right migration tools; designing hybrid connectivity during the transition.
- Multi‑account governance – Restructuring a flat account structure into OUs with SCPs; implementing centralised logging and security.
- Global application deployment – Reducing latency for worldwide users; designing active‑active or active‑passive global topologies.
- Secure enterprise networking – Isolating sensitive workloads with PrivateLink; implementing network inspection with Gateway Load Balancer; protecting against DDoS with Shield and WAF.
- Business continuity – Selecting the DR strategy that meets a given RTO/RPO at the lowest cost; testing failover automation.
- Cost‑optimised redesign – Identifying waste in an existing architecture; recommending Spot Instances, Savings Plans, or storage tiering.
How to prepare: For each pattern, practice mapping a business requirement to the pattern name, then list the key AWS services and design considerations. Then, in the SAP‑C02 Scenarios, you will apply that skill in integrated, multi‑domain exercises.
Recommended Learning Path
Build your pattern recognition skill in this order, which progresses from foundational resilience patterns to advanced enterprise integration.
- High Availability – The most fundamental pattern; many others build on multi‑AZ concepts.
- Disaster Recovery – Extends HA to regional resilience; introduces RTO/RPO trade‑offs that recur throughout the exam.
- Multi‑Account Architecture – Establishes the enterprise governance foundation that all other patterns must fit into.
- Hybrid Cloud – Connects on‑premises and cloud; essential for migration and real‑world enterprise environments.
- Multi‑Region Architecture – Deepens DR and adds global performance considerations.
- Event‑Driven Architecture – Decouples components and introduces asynchronous patterns used in modern designs.
- Serverless Architecture – Covers the operational‑free execution model that often appears as a cost‑effective alternative.
- Enterprise Security Architecture – Cross‑cutting; best studied after you understand the patterns it protects.
- Cost‑Optimised Architecture – Applied last as a lens to refine all previous patterns.
Continue Learning
- SAP‑C02 Certification Guide – Start here if you haven’t reviewed the full exam framework.
- SAP‑C02 Domains – Understand how these patterns map to official exam domains.
- SAP‑C02 Services – Deepen your knowledge of the individual AWS services that make up each pattern.
- SAP‑C02 Scenarios – Apply these patterns in realistic, exam‑style case studies.
- SAP‑C02 Resources – Study guides, checklists, and official AWS references.
For detailed implementation guides, architecture decision records, and in‑depth technical walkthroughs of these patterns, continue your learning on CloudComputingDevPro.
Key Takeaways
- Architecture patterns are the language of the SAP‑C02 exam. You will be evaluated on your ability to select and combine the right patterns for complex business scenarios.
- Prioritise Multi‑Account, Hybrid, Multi‑Region, HA/DR, and Event‑Driven patterns—they appear most frequently and form the backbone of many exam questions.
- Architecture thinking is about trade‑offs: cost vs. resilience, simplicity vs. security, speed vs. control. Every pattern has a side you are sacrificing; know what it is.
- Use the Pattern Selection Matrix to practice quick comparison and justification of architectural choices.
- Integrate these patterns with the official exam domains and test your application skills with the SAP‑C02 Scenarios on CloudCertPro.