AWS Certified Solutions Architect — Associate · SAA-C03

Design Secure
Architectures

Domain 1 — Comprehensive Study Guide
Task Statements 1.1 · 1.2 · 1.3 · 1.4

📋 30% of Exam Score — Highest-Weight Domain
Domain 1 Overview

What You Need to Know

Task 1.1 — Secure Access
  • IAM users, roles, groups, policies
  • AWS Organizations & SCPs
  • Federation & SSO
  • MFA & least-privilege
  • Cross-account access
Task 1.2 — Secure Workloads
  • Security groups & NACLs
  • VPC design patterns
  • WAF, Shield, Firewall Manager
  • Bastion hosts vs. SSM Session Manager
  • Inspector, GuardDuty, Macie
Task 1.3 — Data Security
  • Encryption at rest & in transit
  • KMS, ACM, CloudHSM
  • S3 encryption options
  • Secrets Manager vs. Parameter Store
  • S3 bucket policies & ACLs
Task 1.4 — Resilient Architectures
  • Multi-AZ vs. Multi-Region
  • RTO vs. RPO strategies
  • Backup & DR patterns
  • Fault tolerance vs. high availability
  • Route 53 routing policies
1.1

Secure Access to AWS Resources

IAM Fundamentals · Organizations · Federation · Least Privilege · Cross-Account

Task 1.1 — IAM

IAM Core Concepts

Users · Groups · Roles · Policies
IAM User A permanent identity for a person or application. Has long-term credentials (password + access keys). Avoid for applications — use roles instead.
IAM Group A collection of IAM users. Policies attached to a group apply to all members. Simplifies permission management at scale. Groups cannot assume roles.
IAM Role A temporary identity assumed by a trusted principal (user, service, account). Issues short-lived STS credentials. Preferred for EC2 instances, Lambda, and cross-account access.
IAM Policy JSON document defining Allow/Deny actions on resources. Identity-based policies attach to users/groups/roles. Resource-based policies attach directly to resources (e.g., S3 bucket policy).
Roles are evaluated at runtime — no permanent credentials stored. Prefer roles over users for EC2 and Lambda. A Deny in any policy always overrides an Allow.
Task 1.1 — IAM Policies

Policy Types & Evaluation Logic

Identity-based · Resource-based · Permission Boundaries · SCPs
Policy Type Attached To Controls Exam Trigger
Identity-based User / Group / Role What the principal can do "Grant an EC2 role S3 access"
Resource-based S3, SQS, KMS, etc. Who can access this resource "Allow cross-account S3 access"
Permission Boundary IAM User / Role Maximum permissions ceiling "Dev can create roles but not exceed admin"
SCP (Org Policy) AWS Account / OU Maximum permissions for entire account "Prevent all accounts from disabling CloudTrail"
Session Policy AssumeRole call Scopes permissions for session only "Limit what federated user can do"
Effective permissions = intersection of identity policy AND resource policy (if cross-account, both must allow). SCPs restrict but never grant permissions.
Task 1.1 — Organizations

AWS Organizations & SCPs

Multi-account governance at scale
Organization Structure
  • Management Account: Root account — creates Org, owns billing
  • Organizational Units (OUs): Logical groupings (e.g., Prod, Dev, Security)
  • Member Accounts: Isolated AWS accounts per team/environment
  • Root: Top of hierarchy — SCPs here apply everywhere
Key Features
  • Consolidated billing across all accounts
  • SCPs control what member accounts can do
  • AWS Control Tower automates landing zones
  • Enables cross-account IAM roles
  • Tag policies enforce tagging standards
SCP Rules to Know
  • SCPs do NOT apply to the management account
  • SCPs do NOT grant permissions — they restrict them
  • Deny at OU level blocks all accounts in that OU
  • FullAWSAccess is the default SCP (allow all)
  • SCPs affect even the root user in member accounts
Use SCPs to prevent member accounts from leaving the org, disabling GuardDuty, or using unapproved regions.
Task 1.1 — Federation

Identity Federation & AWS IAM Identity Center

Letting external identities access AWS
SAML 2.0 Federation
  • Corporate directory (Active Directory) → AWS
  • Uses STS AssumeRoleWithSAML
  • Up to 12-hour session tokens
  • Good for existing enterprise IdPs
Web Identity Federation
  • Social IdPs: Cognito, Google, Facebook
  • STS AssumeRoleWithWebIdentity
  • Cognito preferred for mobile apps
  • Cognito Identity Pools → temporary AWS creds
IAM Identity Center (SSO)
  • Single sign-on across all AWS accounts
  • Integrates with AD, Okta, Azure AD
  • Manages permission sets per account
  • Recommended for multi-account orgs
IAM Identity Center (formerly SSO) is the modern recommended approach for multi-account human access. Use Cognito for end-user app authentication. Never create IAM users for each employee in an enterprise.
1.2

Secure Workloads & Applications

VPC Security · Edge Protection · Threat Detection · Bastion vs. SSM

Task 1.2 — VPC Security

Security Groups vs. NACLs

Two layers of network access control
Feature Security Group Network ACL
ScopeInstance (ENI) levelSubnet level
StatefulnessStateful — return traffic auto-allowedStateless — must explicitly allow inbound + outbound
Allow / DenyAllow rules onlyAllow AND Deny rules
Rule evaluationAll rules evaluated togetherRules evaluated in numbered order (lowest first)
Default behaviorDeny all inbound, allow all outboundAllow all (default NACL)
Best useFine-grained instance protectionSubnet-level IP block lists (Deny bad IPs)
NACLs are stateless — if you allow inbound port 443, you MUST also allow outbound ephemeral ports (1024–65535). Security groups handle return traffic automatically.
Task 1.2 — VPC Design

Secure VPC Architecture Patterns

Public / Private / Isolated subnet tiers
Subnet Types
  • Public: Route to IGW; holds ALB, NAT GW, Bastion
  • Private: Route via NAT GW; holds EC2, ECS, Lambda
  • Isolated: No internet route; databases only
Key Components
  • Internet Gateway (IGW) — public internet
  • NAT Gateway — private → outbound only
  • VPC Endpoints — private AWS API access
  • VPC Peering / Transit Gateway — VPC-to-VPC
  • PrivateLink — cross-VPC service exposure
Exam Scenarios
  • "EC2 needs internet but not a public IP" → NAT Gateway in public subnet
  • "Lambda accesses RDS privately" → VPC-attached Lambda in private subnet, same VPC as RDS
  • "EC2 accesses S3 without internet" → VPC Gateway Endpoint for S3
  • "Centrally route traffic across 50 VPCs" → Transit Gateway (not VPC Peering — it doesn't scale)
  • "Share services across accounts privately" → PrivateLink / VPC Endpoint Services
Task 1.2 — Edge Protection

WAF · Shield · CloudFront · Firewall Manager

Protecting applications at the edge
AWS WAF Web Application Firewall. Filters HTTP/S traffic with rules (IP sets, rate limiting, SQL injection, XSS). Attaches to CloudFront, ALB, API Gateway, AppSync.
AWS Shield Standard Automatic DDoS protection for all AWS customers at no cost. Protects against Layer 3/4 attacks (volumetric, protocol).
AWS Shield Advanced Enhanced DDoS protection with 24/7 DDoS Response Team (DRT), real-time metrics, Layer 7 attack detection, and cost protection. ~$3,000/month.
AWS Firewall Manager Centrally manage WAF rules, Shield Advanced, and Security Groups across all accounts in an AWS Organization. Ensures consistent security posture.
WAF + CloudFront = the primary pattern for blocking Layer 7 attacks (SQL injection, XSS). Shield Advanced is for organizations needing DDoS financial protection and expert support.
Task 1.2 — Threat Detection

Security Monitoring Services

GuardDuty · Inspector · Macie · Security Hub
Amazon GuardDuty
  • Intelligent threat detection using ML
  • Analyzes CloudTrail, VPC Flow Logs, DNS logs
  • Detects: compromised instances, crypto mining, unusual API calls, port scanning
  • Agentless — no software to install
  • Finding types: Recon, Trojan, UnauthorizedAccess
Amazon Inspector
  • Automated vulnerability assessment
  • Scans EC2 instances and container images (ECR)
  • Checks OS vulnerabilities (CVEs), network exposure
  • Requires SSM Agent on EC2 instances
  • Continuous scanning (not just on-demand)
Amazon Macie
  • Discovers and protects sensitive data in S3
  • Uses ML to identify PII, financial data, credentials
  • Alerts on misconfigured S3 buckets (public access)
  • Generates findings for data compliance (GDPR, HIPAA)
AWS Security Hub
  • Centralizes findings from GuardDuty, Inspector, Macie
  • Provides security score and compliance checks
  • Integrates with AWS Config and third-party tools
  • Single pane of glass for security posture
Task 1.2 — Secure Access

Bastion Hosts vs. AWS Systems Manager Session Manager

Securely accessing EC2 instances in private subnets
Bastion Host (Legacy)
  • EC2 instance in public subnet acting as SSH jump server
  • Requires open inbound port 22 (SSH) or 3389 (RDP)
  • Must manage host OS, patching, and key rotation
  • Single point of failure if not made highly available
  • Logs SSH sessions separately — not native to CloudTrail
SSM Session Manager (Preferred)
  • No open ports required — no Security Group changes
  • No SSH keys to manage or rotate
  • Sessions logged to CloudTrail + S3/CloudWatch
  • Works for instances in private subnets with no internet
  • Requires SSM Agent + IAM role on the instance
  • Port forwarding and tunneling supported
Exam answer is almost always SSM Session Manager when the question mentions "no open ports," "eliminate bastion hosts," or "audit all session activity." Bastion hosts are operationally expensive and pose security risks.
1.3

Appropriate Data Security Controls

Encryption at Rest & Transit · KMS · Secrets Manager · S3 Security

Task 1.3 — Encryption

AWS Encryption Services

KMS · CloudHSM · ACM
AWS KMS Managed key service. Creates and controls Customer Master Keys (CMKs). Integrates natively with S3, EBS, RDS, DynamoDB, Lambda, and more. AWS-managed or customer-managed keys. FIPS 140-2 Level 2 validated.
AWS CloudHSM Dedicated Hardware Security Module in your VPC. You have exclusive control of keys — AWS cannot access them. FIPS 140-2 Level 3. Required for strict regulatory compliance. More expensive; you manage the HSM cluster.
AWS Certificate Manager (ACM) Provision, manage, and deploy SSL/TLS certificates. Free public certificates. Auto-renews. Integrates with ALB, CloudFront, API Gateway. Private CA option available. Protects data in transit.
KMS = managed, shared hardware, multi-tenant. CloudHSM = dedicated hardware, single-tenant, you own the keys. Choose CloudHSM when compliance requires exclusive key custody (FIPS Level 3).
Task 1.3 — S3 Security

S3 Encryption Options

Choosing the right server-side encryption mode
Type Key Management Use When Compliance
SSE-S3 AWS manages all keys (AES-256) Default — low overhead, no key management Basic
SSE-KMS KMS Customer Managed Key Audit key usage, fine-grained access, CloudTrail logs Moderate–High
SSE-C You supply the key per request You own and rotate keys outside AWS High — Full key control
CSE (Client-side) Encrypted before upload Data never unencrypted inside AWS Highest
S3 Access Controls
  • Bucket Policy: JSON policy on the bucket (resource-based)
  • S3 Block Public Access: Account/bucket override for public ACLs
  • ACLs: Legacy — prefer bucket policies
  • S3 Access Points: Granular per-application access policies
S3 Security Best Practices
  • Enable Block Public Access at account level
  • Enforce HTTPS-only via bucket policy (aws:SecureTransport)
  • Enable S3 Object Lock for WORM compliance
  • Use S3 Versioning to protect against accidental deletes
Task 1.3 — Secrets

Secrets Manager vs. Parameter Store

Managing application credentials and configuration securely
Feature Secrets Manager Systems Manager Parameter Store
Primary useDatabase credentials, API keys, OAuth tokensConfiguration values, feature flags, non-secret params
Automatic rotation✅ Built-in rotation with Lambda❌ Manual (can build rotation)
Cost~$0.40/secret/monthFree (Standard); $0.05/10k API calls (Advanced)
Secret sizeUp to 65KBUp to 8KB (Standard) / 8KB (Advanced)
KMS encryptionAlways encrypted with KMSSecureString tier uses KMS; String is plaintext
Cross-account✅ Resource-based policyLimited (use with care)
"Database password that must rotate automatically every 30 days" → Secrets Manager. "Application config values with some sensitive fields" → Parameter Store SecureString (cost-effective). Never hardcode credentials in code or EC2 user data.
1.4

Design Resilient Architectures

Multi-AZ · Multi-Region · RTO/RPO · Disaster Recovery · Route 53

Task 1.4 — Resilience

High Availability vs. Fault Tolerance

RTO · RPO · Multi-AZ · Multi-Region
Key Definitions
  • RTO — Recovery Time Objective: How long can you be down? (time to recover)
  • RPO — Recovery Point Objective: How much data can you lose? (time since last backup)
  • HA — System recovers quickly but may have brief downtime (failover)
  • FT — System continues operating without interruption (no downtime)
  • Multi-AZ — Protects against AZ failure (same region)
  • Multi-Region — Protects against region failure (global)
DR Strategy Spectrum
  • Backup & Restore — Lowest cost, highest RTO (hours). S3 backups, AMIs.
  • Pilot Light — Core systems running (DB replicated). Scale up on disaster.
  • Warm Standby — Scaled-down version always running. Faster failover.
  • Multi-Site Active/Active — Full capacity in both regions. Near-zero RTO/RPO. Highest cost.
Lower RTO/RPO = higher cost. Match the DR strategy to the business requirement. "Minutes RTO" = Warm Standby or Active/Active. "Zero RPO" = synchronous replication (Multi-AZ RDS).
Task 1.4 — Route 53

Route 53 Routing Policies

Directing traffic for availability and performance
Policy How It Works Use Case
SimpleSingle record, returns all values randomlySingle resource, no health checks
WeightedDistribute % of traffic across endpointsA/B testing, blue/green deployments, gradual migrations
LatencyRoutes to lowest-latency AWS regionGlobal apps — minimize user-perceived latency
FailoverPrimary → Secondary on health check failureActive-passive DR; automatic failover
GeolocationRoutes based on user's geographic locationGDPR compliance, content localization
GeoproximityRoutes by location with bias adjustmentShift traffic weight between regions
Multivalue AnswerReturns up to 8 healthy records randomlyClient-side load balancing with health checks
Failover requires health checks. Weighted with 0 weight = remove from rotation without deleting the record. Latency-based ≠ Geolocation — latency routes to lowest-latency AWS region, not nearest geography.
Task 1.4 — AWS Services

Resilience Patterns by Service

Multi-AZ & Multi-Region configurations
EC2 & Auto Scaling
  • Spread instances across ≥2 AZs
  • ALB distributes across AZs
  • ASG replaces unhealthy instances automatically
  • Placement Groups: Spread = HA; Cluster = performance
RDS
  • Multi-AZ: Synchronous standby, automatic failover ~1-2 min
  • Read Replicas: Async, for read scaling or cross-region DR
  • RDS Proxy: Reduces connection overhead during failover
  • Aurora: 6-way replication across 3 AZs by default
S3
  • 11 nines durability — data stored across ≥3 AZs
  • Versioning: Protect against accidental deletes
  • Cross-Region Replication (CRR): Multi-region DR
  • S3 Replication Time Control: 15-min RPO SLA
DynamoDB
  • Multi-AZ by default (3 AZs)
  • Global Tables: Multi-Region Active/Active
  • PITR (Point-in-time recovery): Up to 35 days
  • On-demand backups: Manual snapshots
ElastiCache
  • Redis: Multi-AZ with automatic failover
  • Redis Global Datastore: Multi-Region replication
  • Cluster Mode: Shard data across nodes
Common Patterns
  • "Always available" = Multi-AZ
  • "Survive region failure" = Multi-Region
  • "Lowest RPO for RDS" = Multi-AZ (sync replication)
  • "Read scaling + cross-region DR" = Read Replica
Quick Review

Exam Checklist — Domain 1

Can you answer these?
Task 1.1 — Secure Access
  • Difference between IAM users, groups, roles, policies
  • When to use permission boundaries vs. SCPs
  • How cross-account role assumption works
  • IAM Identity Center vs. SAML federation vs. Cognito
  • Why roles are preferred over access keys for services
Task 1.2 — Secure Workloads
  • Security groups (stateful) vs. NACLs (stateless)
  • When to use WAF vs. Shield vs. Shield Advanced
  • GuardDuty vs. Inspector vs. Macie use cases
  • SSM Session Manager vs. Bastion host trade-offs
  • VPC Endpoint types (Gateway vs. Interface)
Task 1.3 — Data Security
  • KMS vs. CloudHSM (shared vs. dedicated, Level 2 vs. Level 3)
  • S3 encryption: SSE-S3 vs. SSE-KMS vs. SSE-C vs. CSE
  • Secrets Manager (auto-rotation) vs. Parameter Store (config)
  • Enforce HTTPS on S3 with aws:SecureTransport
  • S3 Object Lock: compliance WORM storage
Task 1.4 — Resilience
  • RTO vs. RPO definitions and DR strategy spectrum
  • RDS Multi-AZ (sync/HA) vs. Read Replicas (async/scaling)
  • Route 53 Failover vs. Latency vs. Geolocation policies
  • DynamoDB Global Tables for Multi-Region Active/Active
  • S3 Cross-Region Replication requires versioning enabled
Quick Reference

Service → Task Quick Map

Identity & Access
  • IAM → users, roles, policies
  • Organizations → multi-account SCPs
  • IAM Identity Center → enterprise SSO
  • Cognito → app user auth + temp AWS creds
  • STS → temporary security credentials
Network Security
  • Security Groups → instance firewall (stateful)
  • NACLs → subnet firewall (stateless)
  • WAF → Layer 7 filtering
  • Shield → DDoS protection
  • Firewall Manager → centralized rule mgmt
Threat Detection
  • GuardDuty → runtime threat detection
  • Inspector → vulnerability scanning
  • Macie → S3 PII discovery
  • Security Hub → centralized findings
  • CloudTrail → API audit log
Encryption & Secrets
  • KMS → managed encryption keys
  • CloudHSM → dedicated HSM / Level 3
  • ACM → SSL/TLS certificates
  • Secrets Manager → rotating credentials
  • Parameter Store → config + SecureString
Resilience
  • Route 53 → DNS routing + failover
  • ALB + ASG → AZ-level HA
  • RDS Multi-AZ → sync DB replication
  • Aurora Global DB → cross-region DB
  • DynamoDB Global Tables → multi-region
Access & Monitoring
  • SSM Session Manager → no-port EC2 access
  • VPC Endpoints → private AWS API access
  • AWS Config → resource config compliance
  • CloudWatch → metrics, logs, alarms
  • S3 Object Lock → WORM compliance

Domain 1 Complete

You're ready for Domain 1

30% of SAA-C03 · Design Secure Architectures
Good luck on the exam!

1.1 — Secure Access 1.2 — Secure Workloads 1.3 — Data Security 1.4 — Resilient Architectures