Study Canvas

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.

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.

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.

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.

"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.

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 = 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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

"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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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 = 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 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.

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 = 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).

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.

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.

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.

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.

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 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.

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 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.

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).

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.

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".

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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 = 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.

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.

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.

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.

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.