SAA-C03

IAM Core Concepts:

• Users — Individual identities with long-term credentials (access keys, passwords). Avoid using the root account for daily tasks
• Groups — Collections of users with shared permissions. Users inherit all policies attached to their groups
• Roles — Temporary credentials assumed by users, services, or applications. Preferred over access keys for cross-account and service access
• Policies — JSON documents defining permissions (Effect, Action, Resource, Condition). Attached to users, groups, or roles
• Identity-based policies — Attached to IAM identities (users, groups, roles). Define what actions are allowed or denied
• Resource-based policies — Attached to resources (S3 buckets, SQS queues, KMS keys). Define who can access the resource and what actions are allowed
• Permission boundaries — Set maximum permissions an IAM entity can have. Used to delegate admin without granting full access
• SCPs (Service Control Policies) — Applied at the AWS Organizations level to restrict permissions across all accounts in an OU. Do not grant permissions, only restrict

IAM Policy Evaluation Logic:

• Step 1: All requests start as implicitly denied
• Step 2: Evaluate all applicable policies (identity-based, resource-based, SCPs, permission boundaries)
• Step 3: An explicit DENY in any policy always wins and overrides any ALLOW
• Step 4: If an explicit ALLOW exists and no explicit DENY, the request is allowed
• Step 5: If no explicit ALLOW is found, the request remains implicitly denied

Key rule: Explicit DENY > Explicit ALLOW > Implicit DENY. Always apply least privilege.

VPC Security Layers:

Security Groups vs NACLs:

VPC Connectivity Options:

• Internet Gateway (IGW) — Enables internet access for public subnets. One per VPC, horizontally scaled
• NAT Gateway — Allows private subnet instances to access the internet for outbound traffic only. Managed, highly available in a single AZ. Deploy one per AZ for HA
• NAT Instance — Self-managed EC2 instance for NAT. Must disable source/destination check. Less preferred than NAT Gateway
• VPC Peering — Private connectivity between two VPCs (same or cross-account/Region). Non-transitive: A↔B and B↔C does not mean A↔C
• Transit Gateway — Hub-and-spoke model for connecting multiple VPCs and on-premises networks. Transitive routing, supports thousands of connections
• VPC Endpoints (Gateway) — Free, route-table entry for S3 and DynamoDB. Keeps traffic within AWS network
• VPC Endpoints (Interface / PrivateLink) — ENI-based private connection to AWS services or your own services. Uses private IP, costs per hour + data
• VPN (Site-to-Site) — Encrypted tunnel over the internet from on-premises to VPC via Virtual Private Gateway. Quick to set up, limited to ~1.25 Gbps per tunnel
• Direct Connect — Dedicated private connection from on-premises to AWS. 1 Gbps or 10 Gbps, consistent latency, not encrypted by default (add VPN for encryption)
• Direct Connect Gateway — Connects Direct Connect to multiple VPCs across Regions

Tip: For hybrid connectivity questions, Direct Connect provides consistent performance but takes weeks to provision. VPN is faster to set up and can serve as a backup while DC is provisioned.

Encryption at Rest:

Encryption in Transit:

• HTTPS / TLS — Use ACM (AWS Certificate Manager) for free SSL/TLS certificates on ALB, CloudFront, API Gateway
• VPN — IPSec encryption for Site-to-Site VPN connections
• Direct Connect + VPN — Layer VPN on top of Direct Connect for encrypted private connectivity
• RDS / Aurora — Force SSL connections via rds.force_ssl parameter or require_secure_transport
• S3 — Enforce HTTPS via bucket policy condition: aws:SecureTransport = true

KMS Key Types:

Key rule: Use customer-managed CMKs when you need key rotation control, cross-account access, or CloudTrail audit logging of key usage.

AWS Secrets & Parameter Management:

Security Services Overview:

• AWS GuardDuty — Intelligent threat detection using ML. Analyzes CloudTrail, VPC Flow Logs, and DNS logs for anomalies
• AWS Inspector — Automated vulnerability scanning for EC2 instances, container images in ECR, and Lambda functions
• AWS Macie — ML-powered service to discover, classify, and protect sensitive data (PII) in S3 buckets
• AWS Security Hub — Centralized security findings dashboard aggregating from GuardDuty, Inspector, Macie, Firewall Manager, and third-party tools
• AWS Config — Track resource configuration changes over time. Config Rules evaluate compliance. Remediation via SSM Automation
• AWS CloudTrail — Logs all API calls across your AWS account. Management events (free), Data events (charged). Stored in S3
• AWS Organizations — Centrally manage multiple accounts. Use SCPs to restrict services/actions across OUs
• AWS Control Tower — Automated multi-account governance with guardrails (preventive SCPs + detective Config Rules)

Cognito: User Pools vs Identity Pools:

Common pattern: User authenticates via User Pool → token exchanged via Identity Pool → temporary AWS credentials → access AWS resources directly.

High Availability Patterns:

• Multi-AZ — Deploy resources across multiple Availability Zones within a Region for fault tolerance. If one AZ fails, traffic shifts to healthy AZs
• Multi-Region — Deploy across multiple AWS Regions for disaster recovery and global reach. Higher cost and complexity but protects against regional failures
• Active-Active — All Regions/AZs serve traffic simultaneously. Lowest RTO/RPO but most complex and expensive
• Active-Passive — Primary Region handles traffic; standby Region takes over during failover. Lower cost but higher RTO

Disaster Recovery Strategies:

Tip: The exam often asks you to choose the DR strategy that meets RTO/RPO requirements at the lowest cost. Know the trade-offs.

Elastic Load Balancing (ELB):

Auto Scaling Key Concepts:

• Launch Template — Defines AMI, instance type, key pair, security groups, and user data for new instances. Preferred over Launch Configuration (legacy)
• Desired / Min / Max capacity — Desired is the target count; ASG maintains it. Min and Max set the scaling boundaries
• Target Tracking — Automatically adjusts capacity to maintain a target metric (e.g., CPU at 50%). Simplest and most common scaling policy
• Step Scaling — Scale by different amounts based on alarm threshold severity (e.g., +1 at 60% CPU, +3 at 80% CPU)
• Simple Scaling — Add or remove a fixed number of instances when an alarm triggers. Has a cooldown period. Least flexible option
• Scheduled Scaling — Scale based on predictable time-based patterns (e.g., scale up at 9 AM, down at 6 PM)
• Predictive Scaling — Uses ML to forecast traffic and pre-provisions capacity ahead of demand. Best for cyclical patterns
• Cooldown period — Default 300 seconds. Prevents rapid scale-in/out oscillation. Shorter cooldown for fast-changing workloads
• Health checks — EC2 (default), ELB (recommended), or custom. Unhealthy instances are terminated and replaced
• Lifecycle hooks — Pause instances during launch or termination for custom actions (e.g., install software, drain connections)

Route 53 Routing Policies:

RDS High Availability & Read Scaling:

• Multi-AZ deployment — Synchronous standby replica in another AZ. Automatic failover (1–2 minutes). For HA, not read scaling
• Read Replicas — Asynchronous replication. Up to 15 for Aurora, 5 for other engines. For read scaling. Can be cross-Region
• Aurora Multi-AZ — 6 copies of data across 3 AZs. Writer + up to 15 Aurora Replicas. Failover in under 30 seconds
• Aurora Global Database — Cross-Region replication with <1 second lag. Up to 5 secondary Regions. RPO of 1 second, RTO under 1 minute
• RDS Proxy — Fully managed connection pooling. Reduces database connection overhead, improves failover time by 66%. Ideal for Lambda + RDS
• Automated backups — Point-in-time recovery within retention period (1–35 days). Stored in S3. Transaction logs backed up every 5 minutes
• Manual snapshots — User-initiated, persist beyond retention period. Can be shared cross-account or copied cross-Region

S3 Durability & Availability:

SQS for Decoupling & Resilience:

• Loose coupling — SQS between components ensures producers and consumers operate independently. If a consumer fails, messages remain in the queue
• Scaling pattern — ASG scales consumers based on ApproximateNumberOfMessagesVisible CloudWatch metric
• Dead Letter Queue (DLQ) — Messages that fail processing after maxReceiveCount attempts are moved to a DLQ for investigation
• Visibility Timeout — Prevents other consumers from processing the same message while one consumer is working on it (default 30s, max 12 hours)
• Fan-out with SNS — Publish to an SNS topic that fans out to multiple SQS queues for parallel processing by different services

Architecture pattern: ALB → ASG (producers) → SQS → ASG (consumers) → Database. This decouples the tiers and allows independent scaling.

AWS Backup:

• Centralized backup — Manage and automate backups for EBS, RDS, DynamoDB, EFS, FSx, EC2, Aurora, S3, and more from a single service
• Backup plans — Define frequency, retention, and lifecycle rules (transition to cold storage)
• Cross-Region backup — Copy backups to another Region for DR compliance
• Cross-account backup — Share backups with other AWS accounts via AWS Organizations
• Vault Lock — WORM (Write Once Read Many) compliance policy. Prevents backup deletion for regulatory compliance

EC2 Instance Families:

Naming: m5.xlarge = family (m), generation (5), size (xlarge). “g” suffix = Graviton (ARM), “a” suffix = AMD.

EC2 Placement Groups:

EBS Volume Types:

Key rule: gp3 is the default choice. Use io2/io1 for databases needing >16,000 IOPS. Use st1/sc1 for sequential, throughput-heavy workloads.

Storage: EBS vs EFS vs FSx vs Instance Store:

Amazon CloudFront:

• Edge locations — 400+ points of presence globally. Content cached at the edge for low-latency delivery
• Origins — S3 bucket, ALB, EC2 instance, API Gateway, or any HTTP endpoint. Use Origin Access Control (OAC) for S3
• Origin Access Control (OAC) — Restricts S3 bucket access to CloudFront only. Replacement for legacy Origin Access Identity (OAI)
• Cache behaviors — Match URL path patterns to different origins. Configure TTL, headers, query strings, and cookies
• Lambda@Edge — Run Lambda functions at edge locations on CloudFront events (viewer request/response, origin request/response)
• CloudFront Functions — Lightweight JavaScript functions for viewer request/response. 1/6th the cost of Lambda@Edge, sub-millisecond execution
• Field-level encryption — Encrypt specific form fields at the edge, only decryptable by your application
• Signed URLs / Signed Cookies — Restrict access to content. Use signed URLs for individual files, signed cookies for multiple files
• Geo-restriction — Whitelist or blacklist countries from accessing your content

Global Accelerator vs CloudFront:

ElastiCache: Redis vs Memcached:

Default choice: Redis for most scenarios. Choose Memcached only if you need multi-threaded performance and do not need persistence or replication.

Database Selection Guide:

Serverless Architecture:

• Lambda — Event-driven compute. 15 min max, 10 GB memory, 1,000 concurrent (default). Pay per invocation + duration
• API Gateway — REST/HTTP/WebSocket API front door. Throttling, caching, authentication, request validation
• DynamoDB — Serverless NoSQL. On-demand or provisioned. Global Tables for multi-Region active-active
• S3 — Object storage with event notifications to Lambda, SQS, SNS, or EventBridge
• Step Functions — Orchestrate multiple Lambda functions and AWS services in workflows. Standard (1 year) or Express (5 min)
• EventBridge — Serverless event bus for event-driven architectures. Rules route events to 100+ targets
• Aurora Serverless v2 — Auto-scales capacity in fine-grained increments based on application demand. Scales to zero when idle
• Fargate — Serverless containers for ECS and EKS. No EC2 management, pay per vCPU and memory used

Tip: When the exam says “least operational overhead” or “minimize management,” serverless services (Lambda, DynamoDB, Fargate, Aurora Serverless) are usually the correct answer.

EC2 Pricing Models:

Spot Instance Strategies:

• Spot Fleet — Request a collection of Spot and optionally On-Demand instances. Strategies: lowestPrice, diversified, capacityOptimized
• Capacity-optimized allocation — Launches instances from the pool with the most available capacity. Reduces interruption probability
• Diversified strategy — Spread across multiple instance types and AZs. Best for workloads needing availability
• Spot interruption handling — 2-minute warning via instance metadata. Design for graceful shutdown, checkpoint progress
• Mixed instances in ASG — Combine Spot and On-Demand in a single Auto Scaling Group. Set percentage split and instance diversity

Key rule: Never use Spot for stateful, critical, or database workloads. Always use for batch, analytics, CI/CD, and containerized stateless applications.

S3 Storage Classes & Cost Optimization:

S3 Lifecycle Policies:

• Transition actions — Move objects between storage classes based on age (e.g., Standard → Standard-IA after 30 days → Glacier after 90 days)
• Expiration actions — Automatically delete objects after a specified number of days
• Waterfall rule — Can only transition to a lower-cost class (Standard → IA → Glacier). Cannot go backwards
• Minimum duration — Objects must stay in a class for the minimum duration before transitioning (30 days for IA, 90 days for Glacier)
• S3 Intelligent-Tiering — Automatically moves objects between Frequent, Infrequent, and Archive tiers based on access patterns. No retrieval fees
• S3 Analytics — Analyze access patterns to determine when to transition objects to IA. Provides recommendations

Data Transfer Costs:

• Inbound data — Free (internet to AWS)
• Same AZ — Free (using private IP)
• Cross-AZ (same Region) — $0.01/GB each way. Use private IPs to reduce cost
• Cross-Region — $0.02/GB. Minimize with caching, compression, or regional architecture
• Internet outbound — Tiered pricing starting ~$0.09/GB. Use CloudFront to reduce costs (lower data transfer rates)
• VPC Endpoints (Gateway) — Free for S3 and DynamoDB traffic. Keeps traffic within AWS network
• VPC Endpoints (Interface) — Per-hour + per-GB charges. Still cheaper than NAT Gateway for high-volume traffic
• NAT Gateway — $0.045/hour + $0.045/GB processed. Major cost driver; minimize by using VPC Endpoints for AWS services

Tip: NAT Gateway data processing charges are a common cost trap. Use S3 and DynamoDB Gateway Endpoints (free) and Interface Endpoints to reduce NAT Gateway costs.

Compute Cost Optimization:

• Right-sizing — Use AWS Compute Optimizer to identify underutilized instances. Downsize or change family based on recommendations
• Graviton instances — ARM-based processors offering up to 40% better price-performance than x86 equivalents
• Auto Scaling — Scale down during low-demand periods. Use target tracking to maintain optimal utilization
• Lambda — Pay per invocation and duration. Cost-effective for infrequent or short-running tasks vs running EC2 24/7
• Fargate vs EC2 for containers — Fargate has no idle capacity cost, EC2 is cheaper for steady high utilization. Use Fargate Spot for additional savings
• Scheduled start/stop — Use AWS Instance Scheduler or Lambda to stop dev/test instances during nights and weekends

Database Cost Optimization:

• Aurora Serverless v2 — Scales to zero, pay per ACU-second. Best for intermittent or unpredictable database workloads
• DynamoDB On-Demand — Pay-per-request, no capacity planning. Use for unpredictable traffic instead of over-provisioning
• DynamoDB Reserved Capacity — Commit to RCU/WCU for 1 or 3 years for up to 77% savings on provisioned mode
• RDS Reserved Instances — 1 or 3-year commitment for steady-state databases. Up to 72% discount
• Read Replicas — Offload reads from primary to cheaper read replicas instead of scaling up the primary instance
• ElastiCache — Cache frequently read data to reduce database load and RDS/Aurora costs

Cost Management Tools:

Tip: The exam loves questions about choosing the right pricing model. Remember: Spot for fault-tolerant batch, Reserved/Savings Plans for steady-state, On-Demand for short-term unpredictable.

Compute Services:

Database Comparison:

Storage Comparison:

Messaging & Integration:

VPC Connectivity Comparison:

Migration Services:

Container Orchestration:

Decision rule: Use ECS for simplicity and AWS-native workloads. Use EKS if you need Kubernetes compatibility or multi-cloud portability. Use Fargate launch type to eliminate instance management overhead.

Analytics Services Quick Reference:

Data lake pattern: S3 (storage) → Glue Crawler (catalog) → Athena (ad-hoc SQL) or Redshift Spectrum (BI) or EMR (big data processing).