SAA-C03 Deep Dive: Designing Secure and Resilient AWS Architectures (Domains 1 & 2)
A comprehensive deep dive into SAA-C03 Domains 1 and 2 — covering IAM roles vs policies vs permission boundaries, S3 security patterns, VPC design, KMS encryption, AWS Verified Access, DR strategies with RPO/RTO, Aurora Global Database, Route 53 routing policies, and CloudFormation snippets for exam scenarios.
Domains 1 and 2 of the AWS Solutions Architect Associate (SAA-C03) represent 56% of the exam: Design Secure Architectures (30%) and Design Resilient Architectures (26%). These are not surface-level questions — they present complex multi-service scenarios and require you to choose the architecture that best balances security, resilience, and operational simplicity.
This deep dive covers every concept, service comparison, and architecture pattern you need to answer these questions with confidence. We include decision tables, text-based architecture diagrams, and CloudFormation snippets that reinforce how services connect in real exam scenarios.
- IAM Roles vs Policies vs Permission Boundaries
- S3 Security Patterns
- VPC Security: Security Groups vs NACLs
- KMS Encryption Patterns
- AWS Verified Access and Bedrock VPC Endpoint
- DR Strategies: RPO and RTO Table
- Aurora Global vs DynamoDB Global Tables
- Route 53 Routing Policies
- Capacity Blocks for ML
- CloudFormation Snippets
Domain 1: Design Secure Architectures (30%)
IAM Roles vs Policies vs Permission Boundaries
The SAA-C03 expects you to distinguish between different IAM mechanisms and know when each is appropriate:
| Concept | What It Is | When to Use |
|---|---|---|
| Identity-based Policy | JSON policy attached to a user, group, or role. Grants or denies permissions. | Standard approach: "give this role permission to read from S3" |
| Resource-based Policy | JSON policy attached to a resource (S3 bucket, SQS queue, KMS key). Includes a Principal element. | Cross-account access without assuming a role. "Allow Account B to put objects in this bucket." |
| IAM Role | An identity with temporary credentials. Assumed by users, services, or external identities via sts:AssumeRole. | EC2 instance profiles, Lambda execution roles, cross-account access, federation. |
| Permission Boundary | A managed policy that sets the MAXIMUM permissions a user or role can have. Does not grant permissions — only limits them. | "Allow developers to create IAM roles but limit those roles to only S3 and DynamoDB access." |
| SCP (Service Control Policy) | Organization-level policy that sets maximum permissions for all accounts in an OU. Does not grant permissions. | "Prevent any account in the dev OU from using services outside us-east-1." |
S3 Security Patterns
S3 security questions are among the most common on the SAA-C03. You need to understand multiple layers of access control:
| Mechanism | Scope | Key Point |
|---|---|---|
| Bucket Policy | Resource-based, attached to the bucket | Best for cross-account access, enforcing encryption, IP restrictions. Can allow or deny for specific Principals. |
| S3 Block Public Access | Account-level or bucket-level | Overrides any policy that would make a bucket public. Enable at the account level as a safety net. |
| S3 Object Lock | Object-level immutability | Compliance mode: no one can delete (not even root). Governance mode: users with special permission can delete. Requires versioning. |
| S3 Access Points | Named network endpoints per use case | Simplify access management for shared buckets. Each access point has its own policy and can be restricted to a VPC. |
| S3 Encryption | Object-level encryption at rest | SSE-S3 (default, AWS manages key), SSE-KMS (customer controls key, audit via CloudTrail), SSE-C (customer provides key per request), Client-side (encrypt before upload). |
VPC Security: Security Groups vs NACLs
| Feature | Security Group | Network ACL |
|---|---|---|
| Level | Instance (ENI) level | Subnet level |
| Statefulness | Stateful (return traffic auto-allowed) | Stateless (must allow both inbound and outbound, including ephemeral ports) |
| Rules | Allow rules only | Allow and Deny rules |
| Evaluation | All rules evaluated (most permissive wins) | Rules evaluated in order (first match wins) |
| Default | Deny all inbound, allow all outbound | Allow all inbound and outbound (default NACL) |
| Exam Use Case | "Allow only HTTPS to the web server" | "Block a specific IP address from reaching the subnet" |
KMS Encryption Patterns
KMS questions test your understanding of key types and envelope encryption:
- AWS Managed Keys (aws/service): Created and managed by AWS. Automatic rotation every year. Cannot control key policy. Free to use.
- Customer Managed Keys (CMK): You create, manage, and control the key policy. Can enable/disable rotation. Can grant cross-account access. $1/month + API usage charges.
- Envelope Encryption: KMS generates a data key. The data key encrypts your data. KMS encrypts the data key with your CMK. You store the encrypted data key alongside the encrypted data. This allows encrypting data larger than 4 KB.
AWS Verified Access and Bedrock VPC Endpoint
AWS Verified Access provides secure access to corporate applications without a VPN. It uses trust providers (IAM Identity Center, third-party IdPs) to verify user identity and device posture before granting access. Use it when the exam asks about "zero-trust access to internal applications" or "replacing VPN for application access."
Amazon Bedrock VPC Endpoint: For private access to generative AI foundation models, create an Interface VPC Endpoint for Bedrock. This keeps traffic on the AWS network without traversing the internet — critical for regulated industries. If a question mentions "private access to foundation models" or "Bedrock without internet access," the answer involves a VPC Interface Endpoint (powered by AWS PrivateLink).
Domain 2: Design Resilient Architectures (26%)
Disaster Recovery Strategies
This is one of the most heavily tested topics. Memorize this table:
| Strategy | RPO | RTO | Cost | Description |
|---|---|---|---|---|
| Backup and Restore | Hours | Hours (24h+) | Lowest | Backups stored in S3/Glacier. Restore from scratch during disaster. No running infrastructure in DR region. |
| Pilot Light | Minutes | Tens of minutes | Low | Core infrastructure running (database replica), but app/compute is off. Scale up during failover. |
| Warm Standby | Seconds to minutes | Minutes | Medium | Scaled-down but fully functional copy running in DR region. Scale up to production size during failover. |
| Multi-Site Active/Active | Near zero | Near zero | Highest | Full production in multiple regions simultaneously. Traffic routed via Route 53. Instant failover. |
AWS Elastic Disaster Recovery (DRS): Provides continuous block-level replication of on-premises or cloud servers to AWS. Maintains a lightweight staging area and allows recovery within minutes. Use this when the question mentions "migrating disaster recovery to AWS" or "automated failover for on-premises servers."
Aurora Global Database vs DynamoDB Global Tables
| Feature | Aurora Global Database | DynamoDB Global Tables |
|---|---|---|
| Database Type | Relational (MySQL/PostgreSQL) | NoSQL (key-value/document) |
| Replication | One primary Region (read/write), up to 5 secondary Regions (read-only). Replication lag < 1 second. | Multi-active: read/write in ALL Regions. Last-writer-wins conflict resolution. |
| Failover | Promote secondary Region to primary (typically < 1 minute with managed planned failover). | Automatic — no failover needed because all replicas accept writes. |
| Use Case | Global read latency reduction + DR for relational workloads. | Global active-active applications needing low-latency writes in all Regions. |
S3 Multi-Region Access Points: Provide a single global endpoint that automatically routes S3 requests to the nearest replicated bucket. Combined with S3 Cross-Region Replication, this gives you active-active object storage across Regions. Use this when the exam asks about "global low-latency access to S3 data."
Route 53 Routing Policies
| Policy | Use Case | Health Checks? |
|---|---|---|
| Simple | Single resource, no special routing logic | No |
| Failover | Active-passive DR. Route to secondary if primary fails health check. | Yes (required) |
| Latency | Route to the Region with lowest latency for the user | Optional |
| Weighted | Distribute traffic by percentage (e.g., 90/10 for canary deployments) | Optional |
| Geolocation | Route based on user's geographic location (country/continent). Compliance and content localization. | Optional |
| Geoproximity | Route based on geographic proximity with bias to shift traffic between Regions. Requires Route 53 Traffic Flow. | Optional |
| Multivalue Answer | Returns up to 8 healthy records (simple load balancing at the DNS level) | Yes |
Capacity Blocks for ML
Capacity Blocks for ML let you reserve GPU instances (e.g., P5, P4d) for a defined period (typically days to weeks) for machine learning training jobs. Unlike standard Reserved Instances, Capacity Blocks guarantee capacity in a specific Availability Zone at a future date. Use this when the exam asks about "guaranteed GPU capacity for a training job" or "reserving compute for a time-bound ML workload."
CloudFormation Snippets
The SAA-C03 does not require you to write CloudFormation, but understanding these patterns reinforces how services connect:
VPC Endpoint for S3 (Gateway type):
Resources:
S3GatewayEndpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !Ref MyVPC
ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
VpcEndpointType: Gateway
RouteTableIds:
- !Ref PrivateRouteTable
Interface VPC Endpoint for Bedrock:
Resources:
BedrockEndpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !Ref MyVPC
ServiceName: !Sub com.amazonaws.${AWS::Region}.bedrock-runtime
VpcEndpointType: Interface
SubnetIds:
- !Ref PrivateSubnet1
- !Ref PrivateSubnet2
SecurityGroupIds:
- !Ref EndpointSecurityGroup
PrivateDnsEnabled: true
Aurora Global Database Cluster:
Resources:
GlobalCluster:
Type: AWS::RDS::GlobalCluster
Properties:
GlobalClusterIdentifier: my-global-cluster
Engine: aurora-mysql
EngineVersion: "8.0.mysql_aurora.3.04.0"
StorageEncrypted: true
PrimaryCluster:
Type: AWS::RDS::DBCluster
Properties:
GlobalClusterIdentifier: !Ref GlobalCluster
Engine: aurora-mysql
MasterUsername: admin
MasterUserPassword: !Ref DBPassword
DBSubnetGroupName: !Ref DBSubnetGroup
Comments
No comments yet. Be the first!
Comments are reviewed before publication.