AWS SAA-C03 Study Canvas

Numbers to Memorize

Hard numbers the exam actually tests

Limit / Value	Number	Why it matters
S3 writes per prefix	3,500 `PUT/COPY/POST/DELETE` /sec	Split by prefix to scale linearly
S3 reads per prefix	5,500 `GET/HEAD` /sec	Each prefix gets its own budget
SQS FIFO default	300 API ops/sec	Batch 10 msgs → 3,000 msgs/sec
Lambda concurrency (account/region)	1,000 (soft)	Raise via AWS Support ticket
Lambda max execution	15 minutes	Longer → ECS Fargate
Lambda Layers size	250 MB unzipped	Too small for big datasets → EFS
S3 bucket policy max size	20 KB NEW	Hit it → use S3 Access Points instead
Aurora read replicas	up to 15 NEW	RDS caps at 5; Aurora shares one storage layer across 3 AZs
Spot interruption warning	2 minutes NEW	Spot savings up to 90% — only for fault-tolerant work
RI / Savings Plans discount	up to 72% NEW	1–3 yr commitment on steady 24/7 baseline
Global Accelerator static IPs	2 Anycast IPs NEW	Layer 4 failover over the AWS backbone
KMS automatic key rotation	yearly NEW	New backing material; old data still decrypts
S3 Standard min duration	0 days	Cheapest for <30-day data
S3 Standard-IA / One Zone-IA min	30 days	Early delete = full 30-day charge
S3 Glacier Instant Retrieval min	90 days	Plus retrieval fees
Glacier Deep Archive retrieval	3–12 hours	Fails any "millisecond" requirement
Multipart upload recommended above	100 MB	Required above 5 GB
Kinesis Data Streams retention	24 hrs → 365 days	Replay; SQS deletes on process
S3 Standard-IA availability	99.9% (vs 99.99% Standard)	Retry logic covers the gap
Storage cost per GB	S3 ≈ $0.023 · EFS ≈ $0.30	EBS bills provisioned, not used

Exam Trigger PhrasesNEW SECTION

Read the keyword, pick the service

Most SAA questions are decided by one phrase. Learn the phrase → answer mapping and you stop re-deriving architecture under time pressure.

If the question says…	The answer is almost always…
"least operational overhead" / "no servers to manage"	A managed/serverless option — Lambda, Fargate, Aurora Serverless, Config managed rule
"route based on URL / path / host header"	ALB (Layer 7)
"static IP" / "millions of requests" / "TCP or UDP"	NLB (Layer 4) — or Global Accelerator if it's global
"protect against common web exploits / SQL injection"	AWS WAF on ALB, CloudFront or API Gateway (never on an NLB)
"fault-tolerant" / "withstand server failures" / "batch"	Spot (Spot Fleet if instance types vary)
"steady state 24/7 for 1–3 years"	Reserved Instances / Savings Plans
"strictly in order" / "exactly once"	SQS FIFO (or Kinesis, ordered per shard)
"multiple independent consumers" / "replay the data"	Kinesis Data Streams
"existing AMQP / JMS / MQTT app, minimal code change"	Amazon MQ
"millisecond retrieval" mentioned	Kills Glacier Flexible / Deep Archive instantly
"accessed twice a year" / known access pattern	S3 Standard-IA (not Intelligent-Tiering — you pay monitoring for nothing)
"WORM / cannot be deleted / regulatory retention"	S3 Object Lock in Compliance mode
"accidental deletion"	Versioning + MFA Delete (not Object Lock)
"audit who used the encryption key"	SSE-KMS (SSE-S3 has no CloudTrail key logs)
"expose one service, not the whole VPC"	PrivateLink / Interface endpoint
"cheapest private connectivity between accounts, same Region"	VPC sharing with AWS RAM
"hundreds of VPCs" / "hub and spoke"	Transit Gateway (+ a Shared Services VPC)
"encrypted AND dedicated bandwidth to on-prem"	Direct Connect + IPsec VPN over it
"prevent developers escalating their own privileges"	IAM permissions boundary (users/roles only)
"restrict by country"	CloudFront geo-restriction, or Route 53 geolocation
"needs a Windows file share / DFS / SMB"	FSx for Windows File Server
"HPC, EDA, ML, parallel file system"	FSx for Lustre linked to S3
"no ML expertise"	A managed AI service (Comprehend, Rekognition, Textract) — never SageMaker training

Compute & Auto Scaling

ASG Maintenance: Standby vs Suspend ReplaceUnhealthy

Patching an in-service instance? Put it in Standby (instance-level) or suspend ReplaceUnhealthy (group-level) so the ASG doesn't kill it.

Standby: instance leaves InService, auto-detached from the LB, health checks paused. Exit standby → auto re-registers.
Suspend ReplaceUnhealthy: instance stays in the pool, gets marked Unhealthy, but termination is forbidden. After patching: set Healthy manually + Resume.
Standby = surgical, no user errors. Suspend = affects the whole group.

ASG Default Termination PolicyNEW

Scale-in order: AZ balance → allocation strategy → Launch Configuration before Launch Template → oldest config/template → closest to the next billing hour.

1. Pick the AZ with the most unprotected instances (keeps zones balanced).
2. Terminate instances on Launch Configurations before those on Launch Templates.
3. Then the oldest launch configuration / oldest launch template.
4. Tie-break: the instance closest to its next billing hour.
Use instance protection or a custom termination policy when a specific box must survive.

AZ Rebalancing vs Unhealthy Replacement

Rebalancing = Launch BEFORE Terminate. Unhealthy replacement = Terminate BEFORE Launch.

Rebalancing triggers on uneven AZ distribution; launch-first preserves capacity.
Health-check failure (ALB or EC2) → terminate first, then launch replacement.

Multi-AZ Cost Formula: why 3 AZs beat 2NEW

To keep N instances alive through one AZ failure: 2 AZs costs 2N instances, 3 AZs costs 1.5N. Spreading wider is cheaper, not more expensive.

Need 4 survivors, 2 AZs: 4 per AZ → 8 total (lose one AZ, 4 remain).
Need 4 survivors, 3 AZs: 2 per AZ → 6 total (lose one AZ, 4 remain).
The spare capacity you must over-provision shrinks as AZ count grows.
AWS best practice: ≥3 AZs for HA workloads — lowest cost and highest availability.

Multi-AZ ASG + ALB + WAFNEW

"Highly available, scalable, protected from web exploits" → Multi-AZ ASG + ALB + AWS WAF. WAF needs a Layer 7 endpoint.

WAF attaches to: ALB, CloudFront, API Gateway, App Runner, Global Accelerator.
WAF cannot attach to: an NLB, an ASG, or a bare EC2 instance.
The ASG gives elasticity and self-healing; the ALB gives the WAF something to sit on.

Scheduled Scaling Actions

Predictable recurring spikes → Scheduled Actions setting desired capacity, so capacity is ready before demand hits.

Predictable / cron-like → Scheduled Scaling.
Unpredictable → Target Tracking or Simple Scaling (reactive, always lags).
Adjust desired capacity, not min/max locking.

ALB vs NLB & Auto Scaling×3 duplicate notes

ALB = Layer 7 content-based routing. NLB = Layer 4 raw TCP/UDP/TLS performance. ASG is not a load balancer.

ALB: routes HTTP/HTTPS on headers, paths, hostnames.
NLB: no HTTP awareness; static IP, ultra-low latency, extreme throughput.
ASG + Multi-AZ: self-healing across zones — availability, not traffic distribution.
Question says "route based on URL/path/content" → ALB, every time.

EC2 Instance HibernateNEW

App takes forever to warm up in memory? Hibernate flushes RAM to the encrypted EBS root volume and reloads it on start.

Mechanism: RAM contents written to the encrypted root EBS volume (root must be encrypted).
Resume: RAM reloaded, processes restored, instance ID retained, data volumes reattached — no cold bootstrap.
vs User Data: user data re-runs setup on every boot; hibernation preserves the already-warm state.

EC2 Boot Volume Types

HDD volumes (st1, sc1) cannot be boot/root volumes.

Bootable: SSD EBS — gp2, gp3, io1, io2 — plus Instance Store.
Not bootable: Throughput Optimized HDD st1, Cold HDD sc1.

Placement GroupsGAP

Three shapes: Cluster = lowest latency, Spread = maximum isolation, Partition = big distributed systems.

Cluster: one AZ, packed tight — HPC, tightly coupled, 10/25/100 Gbps between nodes. Whole rack is a single failure domain.
Spread: each instance on distinct hardware, max 7 per AZ — small critical fleets.
Partition: groups of racks with separate power/network — HDFS, Cassandra, Kafka.
Exam trigger: "low network latency, high throughput between instances" → Cluster.

Cross-Region AMI Copy

Copying an AMI to Region B automatically copies the backing EBS snapshot too.

Region B ends with: 1 AMI (from copy) + 1 Snapshot (auto-generated) + any instances you launch.

Q5 — Flash Sale Timeouts (EC2 + Aurora)

Decouple writes with SQS + ASG workers, and add RDS Proxy for connection pooling.

SQS queue: publish purchase events, ASG of workers polls asynchronously → absorbs write spikes.
RDS Proxy: reuses/pools DB connections, prevents connection-exhaustion timeouts.
Wrong: cross-region read replicas — replicas are read-only and need re-engineering.

API Gateway, Lambda & ECS Fargate

Long-running containers with minimal ops → ECS on Fargate, not self-managed EKS nodes or EKS Anywhere.

API Gateway + Lambda: lightweight REST, short-lived requests.
Task exceeds Lambda's 15-min limit → Fargate.
Anti-pattern: EC2 worker nodes / on-prem EKS Anywhere when "low operational overhead" is stated.

Lambda Concurrency: Reserved vs ProvisionedGAP

Reserved caps and guarantees a slice of the account quota. Provisioned keeps environments warm to kill cold starts. They solve different problems.

Reserved concurrency: carves N of the 1,000 account limit for one function — also throttles it at N, protecting downstream DBs.
Provisioned concurrency: pre-initialised execution environments; costs money while idle; the answer to "latency-sensitive" / "cold start".
Account quota exhausted → request an increase; buffering with SQS smooths the spike but doesn't raise the ceiling.

Cost & PurchasingNEW SECTION

EC2 Purchasing Strategy: baseline vs spikesNEW

Split the workload: baseline on RIs / Savings Plans (up to 72% off), spikes on Spot + On-Demand through an ASG.

Reserved Instances / Savings Plans: predictable, steady-state, 24/7 over 1–3 years.
On-Demand: short-term, unpredictable, cannot tolerate interruption.
Spot: stateless, batch, fault-tolerant — reclaimed on 2 minutes' notice.
Launch templates let one ASG mix On-Demand + Spot across instance types and AZs.

Worked example — 100 instancesNEW

70 always-on + 30 delay-tolerant batch → 70 Reserved Instances + 30 Spot Instances.

Count the always-on machines → that's your RI/Savings Plan number.
Anything described as batch, delay-tolerant or interruptible → Spot.
Buying RIs for the batch tier is the classic wrong answer (you pay 24/7 for 2h/day of work).

Spot Instances vs Spot FleetNEW

"Withstand server failures" is the Spot keyword. Varied instance types/sizes → Spot Fleet, which maintains target capacity for you.

Spot Instances: single instance-type request; AWS reclaims with a 2-minute warning and does not auto-replace at pool level.
Spot Fleet: target capacity across heterogeneous types/sizes, strategies like lowestPrice, auto-provisions replacements.
Scenario pattern: "runs ~2 hours a month" rules out RIs and Savings Plans; "various sizes / variable vCPU" picks Spot Fleet over plain Spot.
Spot = up to 90% off, only for work that can be interrupted without corruption.

Savings Plans vs Reserved InstancesGAP

Compute Savings Plans are the flexible default; Standard RIs are the cheapest but the most rigid.

Compute SP: $/hour commitment, applies across EC2 family, Region, OS, plus Fargate and Lambda. Most flexible.
EC2 Instance SP: locked to a family in a Region; deeper discount.
Standard RI: deepest discount, can be sold on the Marketplace; Convertible RI can be exchanged for another family.
Both bill whether or not you use them — commit only to the true baseline.

Which cost tool?GAP

Cost Explorer analyses the past, Budgets alerts on the future, Compute Optimizer right-sizes, Cost Allocation Tags attribute spend.

Cost Explorer: visualise and forecast 12 months of spend by service/tag.
AWS Budgets: threshold alerts (cost, usage, RI/SP coverage) via SNS — the "notify me before we overspend" answer.
Compute Optimizer: ML right-sizing recommendations for EC2, ASGs, EBS, Lambda.
Trusted Advisor: broad checks — idle resources, service quotas, security gaps.

Storage Cost Model: S3 vs EFS vs EBS

EBS bills provisioned size; S3 and EFS bill only what you actually store.

EBS: block storage, $/GB allocated per month.
EFS: managed NFS, ≈$0.30/GB stored.
S3 Standard: ≈$0.023/GB stored.
Small files in big volumes: S3 < EFS < EBS.

Amazon S3

Lifecycle Transitions — the Waterfall

Lifecycle rules only flow downward in cost and redundancy. You can never go back up.

Invalid: anything → S3 Standard.
Invalid: One Zone-IA → Standard-IA or Intelligent-Tiering.
Valid: Standard → anything.
Valid: Standard-IA → Intelligent-Tiering, One Zone-IA, Glacier/Deep Archive.
Valid: Intelligent-Tiering → One Zone-IA, Glacier/Deep Archive.

Short-Lived Data → S3 Standard

Data living <30 days and read often is cheapest on S3 Standard — IA/Glacier bill 30/90-day minimums plus retrieval.

Standard: 0-day minimum. Standard-IA / One Zone-IA: 30 days. Glacier Instant: 90 days.
Classic trap: "temporary processing files" → do not pick IA.

Q29 — Accessed Twice a Year

S3 Standard-IA: infrequent access, still millisecond retrieval, lower storage cost.

Standard: overpriced for 2 reads/year.
Intelligent-Tiering: extra per-object monitoring fee; pointless when access pattern is already known.
Deep Archive: 3–12 hr retrieval fails millisecond requirement.
Step Functions retry logic covers IA's 99.9% availability.

Object Lock & Retention Rules×2 duplicate notes

Object Lock applies per object version; explicit retention always overrides bucket defaults.

Explicit: a fixed Retain Until Date on the version.
Bucket default: a duration (days/years), computed at upload time.
Different versions of the same key can have different modes and periods.
Requires Versioning enabled.

Deletion Protection ≠ Object Lock

For accidental deletion use Versioning + MFA Delete. Object Lock is for WORM compliance, not operational safety.

Versioning: writes a delete marker, keeps prior versions.
MFA Delete: second factor required to permanently delete a version.
Object Lock: too rigid — blocks all deletion in the window, causes surprise storage costs.

Encryption & Audit Logging

SSE-KMS with the AWS-managed key (aws/s3): zero key management, full CloudTrail key-usage audit trail.

"No manual/customer-provided keys" → rules out SSE-C and client-side encryption.
"Must audit key usage" → rules out SSE-S3 (no CloudTrail key logs).
SSE-KMS with a CMK also works but adds key-creation overhead.

SSE options + KMS key rotationNEW

Compliance wants audit logs and automatic rotation with low overhead → SSE-KMS. Rotation generates new backing material yearly while old data still decrypts.

SSE-S3: on by default, fully managed — but no CloudTrail key-usage logs.
SSE-KMS: key policies, automatic annual rotation, full CloudTrail trail of encrypt/decrypt events.
SSE-C: you supply the key on every request — highest operational overhead.
Rotation: new cryptographic material, same key ID; previously encrypted objects stay readable.

S3 Access Points — scoped prefix accessNEW

Shared dataset, many teams? Give each one an S3 Access Point scoped to its prefix instead of growing one monolithic bucket policy.

Bucket policies max out at 20 KB — access points sidestep the ceiling and simplify per-team administration.
Each access point has its own name, policy and network origin (VPC-only if you want).
Anti-patterns: Macie for access control (it's PII discovery), IAM users for applications (use roles), hardcoding every object ARN into one policy.

Cross-Account Object OwnershipNEW

An object uploaded from another account is owned by the uploader — the bucket owner gets no implicit read access. Bites Redshift UNLOAD jobs.

Fix A: the writer assumes a cross-account IAM role in the bucket owner's account and writes as them.
Fix B: set Object Ownership / bucket-owner-enforced so the bucket owner owns everything written to it.
Redshift pattern: create a role in the bucket account, let the Redshift cluster role assume it, then UNLOAD with those credentials.

Prefix Scaling

Hitting 3,500 writes/sec? Partition into customer-specific prefixes — each prefix gets its own full quota.

Limits are per prefix: 3,500 write, 5,500 read requests/sec.
Uploading everything to bucket root = one prefix = one bottleneck.
s3://bucket/customer-ID/file → scales linearly to tens of thousands/sec.

Transfer Acceleration Billing

Inbound data to S3 is free, and you only pay S3TA fees when it actually made the transfer faster.

S3 ingress from internet: $0.
No measurable speedup → no S3TA charge. Risk-free to try.

Q14 — Slow Overseas Uploads (pick two)

S3 Transfer Acceleration + Multipart Upload.

S3TA: routes via CloudFront edge locations onto the AWS private backbone.
Multipart: parallel parts (recommended >100 MB); a failed part is retried alone.
Direct Connect: months to provision, overkill.
Site-to-Site VPN: public internet, no acceleration.
Global Accelerator: for ALB/NLB/EC2 endpoints, not S3 uploads.

S3 Replication — CRR & SRRGAP

Replication needs versioning on both buckets and is not retroactive — existing objects need S3 Batch Replication.

CRR: cross-Region — compliance, latency, DR. SRR: same-Region — log aggregation, prod→test.
Asynchronous; add Replication Time Control (RTC) for a 15-minute SLA.
Delete markers are not replicated by default; replication is not chained (A→B→C needs explicit rules).
Works cross-account, and can change storage class and ownership on the way.

File & Block Storage (EFS / FSx)

EFS Performance & Throughput ModesNEW

Two independent dials: performance mode = IOPS/parallelism, throughput mode = MiB/s. Don't confuse them in an answer.

General Purpose: default, lowest per-operation latency — web servers, CMS, latency-sensitive file serving.
Max I/O: higher aggregate IOPS and massive parallelism (big data, media processing) at slightly higher metadata latency.
Bursting throughput: scales with how much you've stored. Provisioned throughput: fixed MiB/s regardless of size.
Real-world footnote: AWS now steers new file systems to General Purpose + Elastic throughput; Max I/O still appears in exam questions.

EFS Cross-Region Access

Mount an EFS file system from another region over inter-region VPC peering (or Transit Gateway) — no data duplication.

EFS is a regional service but reachable cross-region via network connections.
Avoids S3 sync jobs, RDS migrations, and manual multi-region copies.

Q24 — Cross-Account EFS from Lambda

EFS resource policy + mount target in a shared/peered VPC + mount via an EFS access point.

S3 + DataSync: lag, duplication, higher cost.
API Gateway proxy: latency, payload limits, extra compute bill.
Lambda Layers: capped at 250 MB unzipped.

On-Prem NFS → EFS with DataSyncNEW

Scheduled, native on-prem NFS → EFS replication = AWS DataSync + Interface VPC endpoints over a Private VIF. No staging bucket in the middle.

DataSync: automates and schedules NFS/SMB ↔ EFS/S3/FSx transfers with encryption and validation.
Private VIF: on-prem → private VPC resources via VGW / DX Gateway.
Public VIF: on-prem → public AWS service endpoints (S3, DynamoDB) without the public internet.
Transit VIF: on-prem → a Transit Gateway.

Q23 — Microsoft DFS Support

Native Microsoft DFS requirement → Amazon FSx for Windows File Server (SMB).

Organizes massive shares into a single folder namespace.
Managed Microsoft AD: directory service, not a file system.
FSx for Lustre: HPC/ML, no DFS.
SQL Server: relational DB, not a file system.

EDA / HPC Storage → FSx for Lustre

Parallel, distributed, sub-millisecond hot data + cheap cold tier → FSx for Lustre linked to S3.

Massive throughput for EDA, HPC, ML workloads.
Native S3 integration: pull in for processing, write back to S3 as the cold tier.
Do not pick EMR as a raw parallel file system.

Storage Gateway — which flavour?GAP

Hybrid, ongoing access to cloud storage from on-prem. Pick by the protocol in the question.

File Gateway: NFS/SMB mount backed by S3 objects — file shares, backups landing in S3.
Volume Gateway: iSCSI block volumes. Cached = hot data local, full copy in S3. Stored = full copy local, async backup to S3.
Tape Gateway: virtual tape library for existing backup software → Glacier.
One-off bulk move instead of ongoing access? That's Snowball or DataSync, not Storage Gateway.

Moving bulk data: Snow vs DataSync vs Transfer FamilyGAP

Decide on bandwidth and repetition: no/low bandwidth and one-off → Snow; network exists and it repeats → DataSync; partners speak SFTP → Transfer Family.

Snowball Edge: tens of TB to PBs shipped physically; Snowmobile for exabyte-scale.
DataSync: online, scheduled, incremental, validated — NFS/SMB/HDFS/object → S3, EFS, FSx.
Transfer Family: managed SFTP/FTPS/FTP front door onto S3 or EFS for external partners.
DMS: databases only (with SCT for a dialect change).

Databases & Caching

Q25 — SQL Server → Aurora PostgreSQL (pick two)

Babelfish for Aurora PostgreSQL + AWS SCT with AWS DMS.

Babelfish: Aurora PostgreSQL speaks T-SQL and the SQL Server wire protocol → near-zero app changes.
SCT: converts schema and code objects. DMS: moves the data with minimal downtime.
Custom endpoints: Aurora endpoints don't emulate SQL Server without Babelfish.
AWS Glue: ETL, not SQL dialect translation.
Aurora Global Database: cross-region DR/latency, not dialect compatibility.

Lift SQL Server to RDS Multi-AZ + KMSNEW

Sensitive relational workload, strict compliance, minimal management → RDS for SQL Server, Multi-AZ, KMS-encrypted.

You get automated patching and backups, built-in Multi-AZ failover, and native KMS integration.
EC2-hosted SQL Server: IaaS — you own patching, backups, HA. Wrong when "minimal overhead" is stated.
S3 / Timestream: you lose relational features and transactions.

Encrypting an existing RDS instanceNEW

You cannot encrypt an existing unencrypted RDS instance in place. The pattern is snapshot → copy snapshot with KMS → restore → cut over → delete the old one.

Step 1: take a snapshot of the unencrypted DB.
Step 2: copy the snapshot, enabling KMS encryption on the copy.
Step 3: restore a new DB instance from the encrypted snapshot; repoint the app; terminate the original.
Same idea for unencrypted EBS volumes — snapshot, encrypted copy, restore.

Multi-AZ vs Read Replicas

Multi-AZ = synchronous, HA/failover, ≥2 AZs in one region. Read Replicas = asynchronous, scaling reads.

Multi-AZ standby serves no traffic — it exists for automatic failover.
Read replicas can be same-AZ, cross-AZ, or cross-region — and are read-only.
"Offload reporting queries" → replica. "Survive an AZ outage" → Multi-AZ.

Read Scaling: which endpoint?NEW

Read throughput problem → add a read replica and point the app at the read endpoint. The Multi-AZ standby can never help.

RDS read replica: dedicated read endpoint, offloads the primary. The app must be changed to use it.
Multi-AZ standby: synchronous failover target only — accepts no reads or writes.
Aurora reader endpoint: automatically load-balances connections across all available Aurora replicas — no app-side balancing.

Aurora vs RDS: backups & dev copiesNEW

Need a dev copy of prod without slowing prod down → Aurora continuous backups + fast database cloning.

Backup overhead: Aurora's distributed storage backs up continuously with zero I/O impact. Single-AZ RDS suspends I/O during a snapshot; Multi-AZ RDS offloads it to the standby (SQL Server still briefly pauses).
Cloning: Aurora fast clone is copy-on-write — instant, no upfront storage cost. RDS needs a full snapshot restore.
Not usable as a dev DB: the RDS Multi-AZ standby (passive) and read replicas (read-only).
Scale: Aurora supports up to 15 auto-scaling replicas over one storage layer spanning 3 AZs.

Aurora Global Database vs cross-Region replicaGAP

Aurora Global Database = sub-second cross-Region replication, ~1 min RTO promotion. A plain cross-Region read replica is slower and manual.

One primary Region writes; up to five secondary Regions serve low-latency local reads.
Storage-level replication, typically <1 s lag — the answer for "global app, regional DR, RPO seconds".
Aurora Serverless v2: scales capacity in fine-grained increments for spiky or unpredictable load.
DynamoDB equivalent: global tables (active-active multi-Region).

DynamoDB essentialsGAP

Serverless key-value, single-digit ms. Know capacity modes, index types, streams and TTL — they're the four things questions hinge on.

On-demand: unpredictable/spiky, pay per request. Provisioned + auto scaling: predictable and cheaper.
GSI: different partition key, added any time. LSI: same partition key, different sort key, only at table creation.
Streams: change data capture → Lambda for event-driven work and cross-service fan-out.
TTL: free automatic expiry of old items. DAX: microsecond cached reads. Global tables: multi-Region active-active.

In-Memory Stores & DAX

Live leaderboards need sub-millisecond reads → ElastiCache for Redis or DynamoDB + DAX.

Redis: sub-ms; native Sorted Sets are purpose-built for leaderboards.
DAX: in-memory write-through cache in front of DynamoDB → microsecond reads.
DynamoDB alone: SSD-backed, single-digit ms.
Aurora / Neptune: relational and graph — not caches.

Networking & Content Delivery

Cheapest multi-account private comms → VPC sharingNEW

Same Region, one AWS Organization, EC2 in several accounts must talk privately at the lowest cost → share subnets with AWS RAM.

VPC sharing (RAM): zero inter-VPC overhead — it's ordinary intra-VPC routing, so no per-GB or per-hour networking fee.
Transit Gateway: hourly attachment fee per VPC + data processing.
VPC Peering: data transfer charges and a full mesh to build and maintain.
PrivateLink: hourly endpoint fee + per-GB processing.

Shared Services VPC + Transit GatewayNEW

Hub-and-spoke with TGW? Put the common dependencies in one Shared Services VPC instead of duplicating them in every spoke.

Centralise: Directory Services, interface endpoints/PrivateLink, monitoring, security appliances. Spokes reach them over TGW routes.
Why: interface endpoints bill per hour per VPC — replicating them across dozens of spokes is pure waste.
Direct Connect: solves on-prem connectivity, not inter-VPC consolidation.
Full-mesh peering: no transitive routing, N² connections. Transit VPC: legacy EC2 VPN appliances.

Peering vs Transit Gateway vs PrivateLink

Exposing one service? Use PrivateLink — peering and TGW hand over the whole VPC.

Peering / TGW: full Layer-3 access across the entire VPC → violates least privilege for a single resource.
PrivateLink: Interface VPC Endpoint exposing exactly one service (e.g. RDS behind an NLB).
Peering and TGW are mutually exclusive for the same VPC pair.
TGW is the hub-and-spoke answer once you have many VPCs.

Gateway vs Interface VPC EndpointsNEW

Gateway endpoint = a route-table entry, S3 and DynamoDB only, free. Interface endpoint = an ENI in your subnet, almost every service, billed hourly + per GB.

Gateway: cannot be reached from on-premises over Direct Connect or VPN.
Interface (PrivateLink): reachable from on-prem over a Private VIF — the way to hit AWS APIs privately from the data centre.
VPC peering connects VPC↔VPC only; no edge-to-edge/transitive routing from on-prem through a peer.
Exam cue: "private access to S3 from on-premises" → interface endpoint (or a Public VIF), never a gateway endpoint.

Direct Connect + VPN

Requirement says both dedicated low-latency and end-to-end encryption → Direct Connect + IPsec VPN.

Direct Connect: dedicated, consistent bandwidth, low latency — unencrypted by default.
Site-to-Site VPN: IPsec encrypted — but rides the public internet.
Combined: private dedicated path plus IPsec.
A VPN backup over the internet is also the cheap DR answer for a single DX link.

Global AcceleratorNEW

Global Layer 4 acceleration with 2 static Anycast IPs and near-instant regional failover, over the AWS backbone. Not a CDN.

vs CloudFront: CloudFront is a Layer 7 HTTP CDN that caches. Global Accelerator proxies TCP/UDP with no caching — gaming, VoIP, IoT, non-HTTP.
vs Route 53 latency routing: DNS just hands back an IP, then traffic crosses the public internet. GA enters the AWS network at the nearest edge immediately.
Endpoints: ALB, NLB, EC2, Elastic IPs. Static IPs survive endpoint changes — handy for firewall allowlists.

Geo-Restriction & Route 53 Policies

Block by country at the edge (CloudFront Georestriction) or at DNS (Route 53 Geolocation).

CloudFront Georestriction: country allow/deny list at edge locations.
Route 53 Geolocation: route or deny DNS answers by user origin.
Other Route 53 policies: Latency (lowest lag), Weighted (% split), Failover (health-check DR), Geoproximity (bias by distance), Multivalue (healthy answers, poor man's LB).

Q10 — CloudFront with an On-Prem Origin

Dynamic backend must stay on-premises but Asia is slow → CloudFront with a custom origin pointing at the on-prem servers.

CloudFront accepts any publicly reachable HTTP server as a custom origin.
Caches static content globally; routes dynamic requests over the AWS private backbone.
S3 + CRR: static websites only.
Route 53 geo-proximity alone: DNS can't shorten physical distance without a CDN.

Security Groups vs NACLsGAP

SG = stateful, instance level, allow-only. NACL = stateless, subnet level, allow and deny, evaluated in rule order.

Stateful: an SG that allows inbound automatically permits the reply — no outbound rule needed.
Stateless: a NACL needs an explicit rule for the return traffic, usually on ephemeral ports 1024–65535.
Only NACLs can deny — so "block a specific malicious IP" is always a NACL answer.
SGs can reference other SGs — the clean way to say "only the web tier may reach the DB tier".

NAT Gateway vs NAT Instance vs Egress-Only IGWGAP

Private subnets reaching the internet outbound only: managed NAT Gateway in a public subnet, one per AZ for HA.

NAT Gateway: managed, 5 Gbps baseline scaling automatically to 100 Gbps, AZ-scoped — a single NAT GW is an AZ-level single point of failure.
NAT instance: legacy EC2 you patch and scale yourself; can act as a bastion, needs source/dest check disabled.
Egress-only IGW: the IPv6 equivalent of a NAT Gateway.
Cost trap: heavy S3 traffic through a NAT GW is billed per GB — a free S3 gateway endpoint removes it.

Messaging & Streaming

Kinesis vs SQS — the Decision Rule

Multiple independent consumers or replay → Kinesis. Simple decoupling → SQS.

Multiple parallel readers of the same stream → Kinesis Data Streams.
Replay / lookback (24 hrs–365 days retention) → Kinesis. SQS deletes on processing.
Zero-code load into S3/Redshift/OpenSearch/Splunk → Kinesis Data Firehose.
Simple queuing + microservice decoupling → SQS + Lambda.

EventBridge vs SNS vs SQSGAP

SQS queues work for one consumer group. SNS fans out the same message. EventBridge routes events by content to many targets, with schemas and SaaS sources.

SNS → SQS fan-out: the classic pattern — each subscriber gets its own durable queue and drains at its own pace.
EventBridge: content-based rules, schema registry, 20+ AWS event sources, third-party SaaS, and scheduled rules (cron replacement).
DLQ: attach one to SQS and to Lambda/EventBridge targets to catch poison messages.
Step Functions: for multi-step workflows with retries, branching and human approval — orchestration, not messaging.

Amazon MQ vs SQS/SNSNEW

Migrating an app that speaks AMQP, MQTT, JMS or STOMP with minimal code change → Amazon MQ (managed ActiveMQ / RabbitMQ).

SQS/SNS use proprietary AWS APIs — adopting them means rewriting the messaging layer.
Amazon MQ keeps the industry-standard protocols, so it's a lift-and-shift.
Same question's compute half: EKS on Fargate — managed Kubernetes control plane plus serverless pods, no worker nodes to patch.
Pattern: "minimal refactoring + operational efficiency" → managed services that speak open standards.

SQS FIFO Throughput & Batching

FIFO defaults to 300 API ops/sec. Batch up to 10 messages per call to multiply it.

Batch 2 → 600 msg/sec · Batch 4 → 1,200 msg/sec · Batch 10 → 3,000 msg/sec.
Need 1,000 msg/sec in strict order? Batch 4 is enough.

Q16 — SNS → Lambda Throttling×2 duplicate notes

100 → 5,000 req/sec spike drops notifications because Lambda hit the 1,000 concurrent execution account quota. Fix: request a limit increase from AWS Support.

Serverless still has soft regional quotas — "it auto-scales" is not unlimited.
You cannot "provision more servers" for SNS or Lambda.
SNS itself scales fine; the bottleneck is downstream Lambda.
Best practice: insert SQS (SNS → SQS → Lambda) to buffer the spike and let Lambda drain at a safe pace — but SQS alone doesn't raise the ceiling.

SQS + Lambda + DynamoDB Ingestion

Fully serverless ingestion = SQS → Lambda → DynamoDB.

SQS standard queues absorb variable volume with no capacity limit.
Lambda polls in batches, zero server management.
Firehose cannot write to DynamoDB — only S3, Redshift, OpenSearch (and Splunk).
EC2: provisioned IaaS — instant anti-pattern when "serverless" is required.

Kinesis + Lambda + DynamoDB (Game Scores)

Ordered, spiky real-time score updates → Kinesis Data Streams → Lambda → DynamoDB.

Kinesis preserves record order within a shard.
Lambda scales to spikes with no patching or servers.
DynamoDB: managed NoSQL, single-digit ms leaderboard storage.
SQS Standard: no ordering guarantee. EC2 fleets: heavy ops overhead.

Kinesis Data Analytics (Managed Apache Flink)

Serverless real-time stream transformation and analysis — now Amazon Managed Service for Apache Flink.

Live metrics: rolling averages, CTR, active users for dashboards.
Streaming ETL: filter/enrich/reformat before landing in S3, Redshift, OpenSearch.
Real-time alerts: anomalies, fraud, IoT thresholds.
Stateful processing and windowing in Java, Python, Scala, or SQL. Ingests from KDS, MSK, API Gateway.

Analytics & ML

Amazon EMR

Managed big-data platform for Spark, Hadoop, Hive, Presto at scale — not a parallel file system.

Primary (Master): coordinates the cluster.
Core: runs tasks and hosts HDFS data.
Task: compute only — ideal for Spot Instances.
EMRFS: read/write straight to S3, decoupling compute from storage.
Exam tip: big-data analytics/ML frameworks → EMR. High-performance parallel FS → FSx for Lustre.

Serverless Analytics Pipeline

Glue → Redshift Serverless → Redshift ML for serverless ETL + MPP warehouse + SQL-only ML.

Glue: serverless clean/transform/load from the S3 data lake.
Redshift Serverless: MPP analytical queries, no cluster management.
Redshift ML: train and infer with native SQL — no Python.
EMR: infrastructure management. RDS: OLTP, no MPP. Athena ML: no dedicated warehouse tier.

Glue DataBrew — Code-Free Data Prep

Visual, collaborative prep with lineage and column profiling → AWS Glue DataBrew.

Point-and-click filtering, date normalization, aggregation — no code.
Recipes: versioned, auditable, shareable transformation steps.
Profiling: automatic column stats, cardinality, data types.
Glue Studio: developer-oriented, generates Spark, no column profiling.
Athena: SQL, not visual, no profiling. AppFlow: SaaS transfer, not ETL prep.

Comprehend Custom Entity Recognition

Extract custom entities from text with no ML expertise → Amazon Comprehend, not SageMaker.

Pipeline: S3 Event → Lambda → Comprehend → DynamoDB.
Serverless, code-free entity extraction.
Anti-patterns: training custom SageMaker models when a managed NLP service suffices; Lookout for Vision for text.

Security, Identity & Monitoring

IAM Permissions BoundaryNEW

Let developers attach their own policies without letting them escalate: a permissions boundary sets the ceiling. Effective permissions = identity policy ∩ boundary.

Scope: IAM users and roles only — never groups.
Use case: delegated administration — devs manage their own policies inside a hard maximum.
SCPs: account/OU-wide guardrails via Organizations, not per-user delegation.
A plain IAM policy: useless as a ceiling if the user can attach more policies.

Which policy type?GAP

Five layers show up in answers: SCP → permissions boundary → identity policy → resource policy → session policy. Deny always wins.

SCP (Organizations): maximum permissions for a whole account/OU. Never grants — only limits.
Permissions boundary: maximum for one user/role.
Identity policy: what the principal may do. Resource policy: who may touch the resource (S3 bucket policy, KMS key policy, SQS, Lambda, API Gateway).
Cross-account access needs both sides: the resource policy allows, and the caller's identity policy allows.

API Gateway Resource Policy & IP FilteringNEW

Restrict an API by caller IP with an API Gateway resource policy using aws:SourceIp. Security groups don't apply here.

API Gateway is managed and lives outside your VPC subnets — you cannot attach a security group to it.
Resource policies are JSON attached to the API: filter by IP range, AWS account, or VPC endpoint.
Condition keys: IpAddress and NotIpAddress on aws:SourceIp.
Need managed rule sets, rate limiting or SQLi/XSS protection instead? That's AWS WAF on the stage.

ALB Authentication with CognitoNEW

Add login to an EC2 app with minimal development → an ALB listener rule that authenticates against a Cognito User Pool (or any OIDC IdP).

The ALB does the OIDC dance before forwarding to targets — no auth code in the app.
User Pools: the directory — sign-up, sign-in, token issuance.
Identity Pools: exchange a token for temporary AWS IAM credentials.
CloudFront: would need custom Lambda@Edge — more development, more ops.

IAM Best Practices

MFA everywhere, CloudTrail on, least privilege, individual credentials, roles for EC2.

Enable MFA for all privileged users (virtual or hardware token).
CloudTrail logs every IAM action — required for auditing.
Least privilege: only the permissions the task needs.
Never share credentials — one identity per person.
IAM Roles for EC2 — never hardcode access keys on instances.

Multi-Account AD Federation

AD Connector + IAM Identity Center = lowest-overhead federation of on-prem AD across AWS Organizations.

AD Connector: directory proxy — no domain controllers in the cloud.
IAM Identity Center: group-based Permission Sets across all accounts.
Anti-pattern: self-hosted IdP on EC2, or AWS Managed AD, when a proxy suffices.

Amazon Security LakeNEW

Centralise security logs from many accounts with the least development effort → Amazon Security Lake, normalising into OCSF in your S3 bucket.

Automatically pulls CloudTrail, GuardDuty, VPC Flow Logs, Route 53 logs and third-party sources.
Normalises to the Open Cybersecurity Schema Framework — no custom ETL to write or maintain.
Lake Formation + Glue: generic data lake, you still write the standardisation scripts.
Custom Lambda ingestion: high maintenance. Athena + QuickSight over scattered buckets: queries fragments, no aggregation or common schema.

ACM Certificate Expiration MonitoringNEW

ACM auto-renews only ACM-issued certs. For imported third-party certs, watch them with the AWS Config managed rule acm-certificate-expiration-check + SNS.

Auto-renewal: free and automatic for ACM-issued certs while DNS/email validation stays valid.
Imported certs: ACM will never renew them — expiry tracking and re-import are on you.
Least maintenance: the Config managed rule evaluates all current and future certs against a threshold (e.g. 30 days) and notifies via SNS on non-compliance.
Alternative: alarm on ACM's DaysToExpiry CloudWatch metric — more setup, less central.

Real-Time API Error Alerts

CloudTrail → CloudWatch Logs → Metric Filter → Alarm → SNS.

Metric filter matches the error pattern; alarm fires SNS in near real time.
CloudTrail → Kinesis: not supported — CloudTrail exports to S3 or CloudWatch Logs only.
Athena + QuickSight: historical reporting, not alerting.
Trusted Advisor: service quotas, not unauthorized API calls.

CloudTrail vs CloudWatch vs ConfigGAP

CloudTrail = who did what (API audit). CloudWatch = how it's performing (metrics, logs, alarms). Config = what it looks like and whether that's allowed (state + compliance).

Config: resource configuration history, drift, managed compliance rules with auto-remediation.
CloudWatch: metrics, dashboards, alarms, Logs Insights.
Trusted Advisor: account-level checks — cost, quotas, security, fault tolerance.
Question mentions "compliance rule" or "was this resource ever misconfigured" → Config, every time.

CloudWatch agent: memory & diskGAP

EC2's default metrics do not include memory or disk-space usage — you must install the CloudWatch agent to get them.

Default metrics come from the hypervisor: CPU, network, disk I/O, status checks.
Memory used, swap, free disk space, and OS/application logs all need the unified agent.
Give the instance an IAM role with CloudWatchAgentServerPolicy; deploy the agent with Systems Manager.

GuardDuty vs Inspector vs Macie vs Security HubGAP

Four different questions: is something attacking me, am I vulnerable, is sensitive data exposed, how am I doing overall.

GuardDuty: threat detection from CloudTrail, VPC Flow Logs and DNS logs — crypto-mining, recon, compromised credentials.
Inspector: vulnerability scanning of EC2, container images in ECR, and Lambda (CVEs, unintended network exposure).
Macie: discovers and classifies sensitive data / PII in S3.
Security Hub: aggregates findings and scores against standards (CIS, PCI). Detective: investigates the root cause of a finding.

Resilience & Disaster RecoveryNEW SECTION

The four DR strategies — cost vs RTO/RPO

RTO = how long you may be down. RPO = how much data you may lose. The four strategies climb both cost and speed together.

Strategy	What's running in DR	RTO / RPO	Picked when the question says…
Backup & Restore	Nothing — backups in S3 / AWS Backup, replicated cross-Region	Hours / hours	"lowest cost", "can tolerate downtime"
Pilot Light	Data replicated live; core servers exist but are switched off	Tens of minutes	"minimal cost but faster than restoring backups"
Warm Standby	A scaled-down but running copy of the full stack	Minutes	"scale up quickly", "always running, smaller"
Multi-Site / Active-Active	Full production capacity in both Regions	Near zero / near zero	"no downtime", "zero data loss", cost not mentioned

Route 53 failover routing + health checks is the DNS half of every one of these.
Aurora Global Database / DynamoDB global tables give the seconds-level RPO.

AWS BackupGAP

One place to define backup policy across services and accounts — the "centrally manage and audit backups" answer.

Covers EBS, EFS, FSx, RDS, Aurora, DynamoDB, Storage Gateway and more.
Backup plans: schedule, lifecycle to cold storage, retention, cross-Region and cross-account copy.
Vault Lock: WORM protection so backups can't be deleted early — the compliance answer.
Beats hand-rolled Lambda + snapshot scripts whenever "operational overhead" appears.

Health checks & graceful failureGAP

Availability answers almost always combine Multi-AZ + a load balancer health check + an ASG. Add Route 53 health checks for cross-Region.

ELB health check on the ASG (rather than the EC2 status check) catches an app that's up but broken.
Connection draining / deregistration delay lets in-flight requests finish before an instance leaves.
Lifecycle hooks pause launch/terminate so you can bootstrap or drain state.
Stateless tiers + externalised session state (ElastiCache/DynamoDB) are what make any of this work.

Cards marked NEW came from notes added since this canvas was last built. Cards marked GAP cover exam-blueprint topics your notes hadn’t reached yet — treat those as the study list, not as revision.