This post covers what I learned while preparing for AWS_SAA — IAM, EC2, Load Balancing, Auto Scaling, RDS, Route 53, S3, CloudFront, and messaging services. I'm writing this for engineers who already understand infrastructure, so I'm skipping the basics and going straight to what the exam actually tests.

1. IAM — It's About Least Privilege, Not Just Access

IAM sounds simple until the exam starts testing edge cases. Here's what actually matters:

The model: Users → Groups → Policies. Never attach policies directly to individual users — always go through groups. It sounds obvious but exam questions test whether you know to put a user in a group vs attach a policy inline.

Roles over access keys: When an EC2 instance or Lambda function needs to access AWS services, assign an IAM Role — never embed access keys in code or instance configuration. The exam will present scenarios where someone hardcodes credentials and ask you what's wrong.

The security tools:

• IAM Credentials Report (account-level) — lists all users and their credential status
• IAM Access Advisor (user-level) — shows which services a user has accessed, helps trim unused permissions

Exam-critical rules:

• Root account is only for initial AWS account setup. Never use it for daily operations.
• One physical person = one IAM user. No sharing.
• MFA on root and privileged users is non-negotiable in exam scenarios.

The policy structure to memorise:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

Effect, Action, Resource — the exam writes scenarios and you need to read policies and spot what's missing or wrong.

2. EC2 Purchasing Options — Architecture Starts Here

The exam gives you a workload description and asks which purchasing option is correct. Memorise these:

The exam trap: Spot instances are the cheapest but can be interrupted. Any question about a database, stateful app, or anything that can't tolerate interruption → eliminate Spot immediately.

EC2 Hibernate is a frequent exam distractor — it preserves RAM state to EBS so the instance restarts faster. The root EBS volume must be encrypted. Use case: services that take a long time to warm up.

3. EC2 Storage — EBS vs EFS vs Instance Store

Three storage types, three completely different behaviours:

EBS (Elastic Block Store):

• Attached to one EC2 instance at a time (except io1/io2 Multi-Attach)
• Persists when you stop the instance
• AZ-specific — to move across AZs, take a snapshot

EFS (Elastic File System):

• Network file system — can be mounted by hundreds of EC2 instances simultaneously
• Works across multiple AZs
• Auto-scales, you pay for what you use
• Use case: shared content, CMS, web serving across multiple instances

Instance Store:

• Physically attached to the host — highest possible IOPS
• Completely lost when the instance stops or terminates
• Use case: temporary buffers, caches, scratch data only

The exam shortcut:

• "Shared across multiple EC2 instances" → EFS
• "Highest IOPS, temporary data" → Instance Store
• "Persistent, single-instance" → EBS

4. Elastic Load Balancing — Three Types, Different Use Cases

AWS has three load balancer types and the exam tests whether you know which fits which scenario:

Application Load Balancer (ALB) — Layer 7:

• Routes based on URL path (/api → one target group, /web → another)
• Routes based on hostname (api.example.com vs app.example.com)
• Routes based on query strings and headers
• Native support for microservices and containers (ECS integration)
• Best for HTTP/HTTPS applications

Network Load Balancer (NLB) — Layer 4:

• Handles millions of requests per second with ultra-low latency
• Has a static IP per AZ — important for whitelisting
• Supports TCP, UDP, TLS
• Use when you need extreme performance or a fixed IP

Classic Load Balancer (CLB) — Legacy:

• Don't design new architectures with it
• The exam mentions it but the answer is rarely CLB

Exam pattern: The question describes a routing requirement — you pick the load balancer.

• "Route by URL path" → ALB
• "Static IP for firewall rules" → NLB
• "Microservices on ECS" → ALB

5. Auto Scaling Groups — Four Scaling Policies

ASG lets EC2 scale automatically. The exam tests which scaling policy matches which requirement:

Target Tracking: Simplest. "Keep average CPU at 40%." AWS handles everything.

Step Scaling: "Add 2 instances when CPU > 70%. Remove 1 when CPU < 30%." You define the steps.

Scheduled Scaling: "Increase min capacity to 10 every Friday at 5pm." You know the traffic pattern.

Predictive Scaling: Machine learning-based. Analyses historical load and pre-scales before the spike hits. Best for recurring patterns you can't manually schedule.

The cooldown period: After a scaling activity, ASG waits before scaling again (default 300 seconds). The exam tests this — if instances are launching and terminating in a loop, suspect the cooldown is too short.

6. RDS — Read Replicas vs Multi-AZ (Highest Exam Yield)

This is tested in almost every exam. These two features sound similar and are completely different:

Read Replicas:

• Purpose: read scaling — offload SELECT queries from the primary
• Replication: asynchronous — slight lag possible
• Scope: same AZ, cross-AZ, or cross-region
• Network cost: free within same region, charged cross-region
• You connect to them explicitly — your app must be updated to use the replica endpoint

Multi-AZ:

• Purpose: disaster recovery — automatic failover
• Replication: synchronous — always up to date
• Scope: same region, different AZ
• Failover: DNS automatically points to standby — no app change needed
• The standby instance cannot serve read traffic — it exists only for failover

Aurora specifics:

• Up to 15 Read Replicas (vs 5 for standard RDS)
• Replication lag under 10ms
• Aurora Global Database: primary region + up to 10 secondary regions, cross-region replication under 1 second
• Aurora Serverless: auto-scales compute — good for infrequent/unpredictable workloads

ElastiCache — the exam trap: ElastiCache is an in-memory cache (Redis or Memcached). The exam often presents a scenario where an RDS database is under heavy read load — the correct answer is frequently "add ElastiCache" rather than more Read Replicas, because cached data never hits the DB at all.

7. Route 53 Routing Policies — Memorise All Six

Route 53 routing policies are one of the highest-density exam topics. Six policies, each with a distinct use case:

Simple: One record, one resource. No health checks. Use for a single server.

Weighted: Split traffic by percentage. Use for A/B testing or canary deployments. Example: 90% to v1, 10% to v2.

Latency: Routes to the region with the lowest latency for the user. AWS measures latency, not geographic distance.

Failover: Active/passive disaster recovery. Primary gets traffic; secondary gets traffic only if primary fails the health check.

Geolocation: Routes based on the user's actual location (country, continent). Use for content localisation or legal data residency requirements. Different from Latency — it's about location, not speed.

Multivalue Answer: Returns up to 8 healthy records randomly. Not a replacement for a load balancer but adds basic client-side load distribution.

TTL matters: High TTL = less Route 53 traffic, but DNS changes take longer to propagate. Low TTL = faster propagation, more Route 53 queries (costs more). The exam tests this trade-off.

8. S3 — Storage Classes and When to Use Each

S3 has seven storage classes. The exam presents a scenario and asks which class is correct:

Lifecycle Rules: Automatically transition objects between classes based on age. Example: Standard → Standard-IA after 30 days → Glacier after 90 days. The exam tests whether you know which transitions are valid.

S3 Replication:

• CRR (Cross-Region Replication): compliance, lower latency for global users
• SRR (Same-Region Replication): log aggregation, live replication between prod and test

Versioning must be enabled on both source and destination buckets for replication to work.

9. S3 Security — Four Encryption Methods

S3 has four server-side encryption options:

SSE-S3: AWS manages keys entirely. Default for new buckets. Header: x-amz-server-side-encryption: AES256

SSE-KMS: You use AWS KMS. You control the key rotation and audit trail via CloudTrail. Header: x-amz-server-side-encryption: aws:kms

SSE-C: You provide your own key with every request. AWS doesn't store the key. HTTPS required. Use when you must control key material.

Client-Side Encryption: You encrypt before uploading. AWS never sees plaintext. Use for strictest compliance requirements.

Bucket Policies vs IAM Policies:

• Bucket policies are resource-based — they're attached to the bucket
• IAM policies are identity-based — attached to users/roles
• Both can allow or deny access. Explicit DENY anywhere always wins.

The CORS trap: If your JavaScript app at example.com calls an S3 bucket, you must configure CORS on the bucket. The exam describes a browser error and asks what's wrong — the answer is CORS.

10. SQS vs SNS vs Kinesis — Decouple vs Stream

Three services, three different problems:

SQS (Simple Queue Service):

• Consumers pull messages
• Message deleted after consumed
• At-least-once delivery (can get duplicates in Standard queue)
• FIFO queue: exactly-once, ordered, 300 TPS
• Default retention: 4 days, max 14 days
• Use for: decoupling microservices, async processing

SNS (Simple Notification Service):

• Publisher pushes, all subscribers receive
• Messages not persisted — lost if not delivered
• Up to 12.5 million subscribers per topic
• Use for: fanout notifications, triggering multiple downstream actions

Kinesis Data Streams:

• Real-time streaming at high throughput
• Data retained up to 365 days — you can replay
• Ordering guaranteed per shard
• Use for: real-time analytics, log ingestion, clickstream data

The fan-out pattern (exam favourite):
One event → SNS Topic → multiple SQS queues (one per downstream service). This is the go-to pattern when one event needs to trigger multiple independent consumers.

Amazon MQ: When migrating existing on-premises apps that use MQTT, AMQP, or STOMP protocols, use Amazon MQ rather than rewriting for SQS/SNS. The exam presents legacy migration scenarios specifically to test this.

Classic Architecture Patterns — The Mental Model

Every SAA exam scenario is a variation of five building blocks:

1. Stateless app → don't store sessions in EC2 — use ElastiCache (Redis) or DynamoDB
2. Shared file storage → EFS, not EBS (EBS is single-instance)
3. Static content → S3 + CloudFront (never serve static files from EC2)
4. Read-heavy database → RDS Read Replica or ElastiCache in front
5. High-write database → Aurora (faster writes, auto-scales storage)

When you see a complex architecture question, strip it back to these five patterns. The correct answer almost always combines two or three of them.