AWS Crash Day

One continuous story: you deploy on one server, it grows, and each growth pain introduces the next service. This story is the Cloud Compute domain.

One server — EC2

EC2 (Elastic Compute Cloud) rents you a virtual machine (an instance). To launch one you pick an AMI (Amazon Machine Image — the disk image it boots from; snapshot your configured box into a custom AMI to stamp out clones), an instance type, and optional user data (a first-boot script).

Disks

• EBS (Elastic Block Store) — the durable network-attached disk. One AZ (Availability Zone), one instance at a time. Types: gp3 (default SSD), io2 (high IOPS — input/output operations per second), st1 (cheap HDD). Back up with snapshots.
• Instance store — physically attached scratch disk, wiped on stop. Temp/cache only.
• EFS (Elastic File System) — a managed NFS (network file system) share, mountable by many instances at once.

Paying for EC2 — heavily tested

• On-Demand — by the second, no commitment, priciest. Spiky/unknown/short-term.
• Reserved / Savings Plans — 1–3 yr commitment, up to ~72% off. Steady 24/7 workloads.
• Spot — spare capacity, up to ~90% off, 2-minute reclaim warning. Only interruptible restartable work: batch, CI, stateless workers. Never databases.
• Dedicated Hosts — whole physical server, licensing/compliance. Rarely the answer.

Overloaded — scale out, not up

Vertical scaling (bigger box) has a ceiling, needs restarts, and stays a single point of failure. The cloud answer is horizontal: many small identical instances, which needs two pieces:

• ALB (Application Load Balancer) — HTTP-aware (layer 7): routes by path/hostname, terminates TLS. Default for web apps.
• NLB (Network Load Balancer) — raw TCP/UDP (layer 4): extreme throughput, static IP. Those three phrases in a question — non-HTTP protocol, millions of req/s, fixed IP — mean NLB.
• Both run health checks and stop routing to dead targets.
• Auto Scaling Group (ASG) — takes a launch template + min/desired/max. Adds/removes instances via target tracking ("keep CPU at 50%" — the usual right answer) or scheduled scaling (predictable 9am spikes), replaces unhealthy instances, spreads across AZs.

Containers

Push images to ECR (Elastic Container Registry), run via an orchestrator: ECS (Elastic Container Service — AWS's own, simpler; the default when there's no Kubernetes history) or EKS (Elastic Kubernetes Service — managed Kubernetes; pick it when the team already knows Kubernetes or needs portability). Separately choose the compute underneath: EC2 nodes you manage, or Fargate — serverless containers, no nodes to see. Fargate is not an orchestrator; it's the machine-less layer under ECS or EKS.

Lambda

Lambda runs a single function per event (HTTP via API Gateway, file landing in S3, queue message, cron). Scales from zero automatically; you pay per millisecond — nothing when idle. The catches (tested): 15-minute max runtime, 128MB–10GB memory (CPU scales with it), cold starts add first-hit latency.

S3 — object storage

S3 (Simple Storage Service) stores objects in buckets, addressed by key over HTTP — no filesystem, no mounting. Eleven-nines durable, effectively infinite, cheap. Default answer for: static site assets, backups, logs, data lakes, user uploads.

• Storage classes trade price vs access: Standard → Standard-IA (Infrequent Access) → Glacier tiers (archive; retrieval minutes–hours). Lifecycle policies move objects automatically ("after 90 days → Glacier").
• Buckets are private by default and should stay that way — serve via CloudFront.

VPC — your private network

A VPC (Virtual Private Cloud) is your isolated network in a region. Inside it, subnets, each pinned to one AZ:

• Public subnet — routes to the Internet Gateway; holds load balancers, bastion hosts.
• Private subnet — no internet route; app servers and databases live here. For outbound-only internet (OS updates, external APIs), traffic exits via a NAT (Network Address Translation) Gateway in a public subnet. Nothing outside can initiate inward.

Standard layout: public subnets hold the ALB; private subnets hold app instances + database; two of each across two AZs.

Recognize by name: VPC endpoints (reach S3/AWS services privately, no internet path), VPC peering / Transit Gateway (connect VPCs), Direct Connect (dedicated physical fiber from a data center), Site-to-Site VPN (encrypted tunnel over the internet).

DNS and CDN

• Route 53 — managed DNS (Domain Name System). Routing policies: weighted (10% to the new version — gradual rollout), latency (nearest region), failover (health-checked primary → standby; cheap DR), geolocation (EU users → EU stack; compliance).
• CloudFront — the CDN (content delivery network): caches at hundreds of edge locations, pulls from an origin (S3 or ALB). Also fronts APIs, does TLS at the edge.

Relational — RDS and Aurora

RDS (Relational Database Service) = managed relational databases (PostgreSQL, MySQL, …): AWS handles provisioning, patching, backups, point-in-time restore; you get an endpoint. Running your own DB on EC2 is almost never the right exam answer.

Aurora — AWS's own MySQL/Postgres-compatible engine: ~3–5× faster, storage auto-grows, 6-way replicated across 3 AZs, up to 15 read replicas, plus Aurora Serverless (scales capacity up/down, even to zero). "Best performance/availability for relational on AWS" → Aurora.

NoSQL — DynamoDB

DynamoDB — fully managed, serverless key-value/document store: single-digit-ms lookups at any scale, pay-per-request option, global tables (multi-region active-active), TTL (time-to-live) expiry, streams (change feed → triggers Lambdas). Its cache DAX (DynamoDB Accelerator) drops reads to microseconds.

Caching — ElastiCache

ElastiCache = managed Redis/Memcached. Two exam patterns:

• DB overwhelmed by repeated identical reads → cache-aside in front. Cheaper than scaling the DB.
• Session storage — sessions in Redis instead of instance memory, making instances stateless so the Auto Scaling Group can kill/add freely. (DynamoDB also works.)

The three-tier web app — asked verbatim

• Presentation tier — CloudFront + S3 (static single-page app), or web servers.
• Application (logic) tier — ALB + EC2 ASG, or containers, or API Gateway + Lambda.
• Data tier — RDS/Aurora (Multi-AZ), DynamoDB, ElastiCache in front.

Know the tier names and the AWS implementation of each — it's both a direct question and the template for scenarios.

The serverless API — AWS's favorite pattern

API Gateway → Lambda → DynamoDB. API Gateway is the managed HTTP front door (routing, throttling, auth, caching); each route triggers a Lambda; state lives in DynamoDB. Scales to zero, pay per request, no servers. "Startup, unpredictable traffic, minimal ops, lowest idle cost" → this stack. User sign-up/login for it → Cognito.

Messaging — decoupling (heavily tested)

Service A calls B synchronously; B dies; A dies too. The fix is async messaging — choosing the right tool is the question:

• SQS (Simple Queue Service) — work queue: each message processed by exactly one worker. Absorbs bursts, tolerates consumer downtime, auto-retries, parks poison messages in a dead-letter queue (DLQ). Standard (huge throughput, at-least-once) vs FIFO (first-in-first-out — strict order, exactly-once, slower). Triggers: decouple, buffer, burst, protect downstream.
• SNS (Simple Notification Service) — pub/sub broadcast: one message pushed to every subscriber. Fan-out: SNS topic → multiple SQS queues so invoicing, shipping, analytics each get their own copy. Triggers: notify many, one event → several services.
• EventBridge — event bus with routing rules matching on content ("source = orders AND amount > 1000") + cron schedules. Triggers: event-driven architecture, routing by content, scheduled jobs.
• Step Functions — workflow orchestration: state machine chaining Lambdas with sequencing, branching, retries, human-approval pauses. Trigger: multi-step process with error handling.
• Kinesis — real-time streaming of high-volume continuous data (clickstreams, telemetry). Triggers: real-time, streaming, analytics pipeline.

Shipping code — CI/CD

Recognize the names: CodePipeline (orchestrates) · CodeBuild (builds/tests) · CodeDeploy (rolls out). GitHub plugs into all.

• Rolling / in-place — replace in batches. No extra infra; reduced capacity mid-deploy, slow rollback.
• Blue/green — full parallel environment, flip all traffic at once. Instant cutover and instant rollback; costs 2× during deploy.
• Canary — 5% to the new version, watch error metrics, shift gradually. Best blast-radius control; needs weighted routing + monitoring.

Infrastructure as Code (IaC): CloudFormation — declare the whole stack in YAML, created/updated as a unit. CDK (Cloud Development Kit) — same thing written in Python/TypeScript. "Reproducible environments / avoid click-ops" → IaC.

Security & observability plumbing

• Code gets AWS access via IAM (Identity and Access Management) roles. Never keys in code. Least privilege.
• Secrets → Secrets Manager (rotation built in), fetched at runtime. Config → SSM (Systems Manager) Parameter Store.
• Encryption: KMS (Key Management Service) manages keys; S3/EBS/RDS encrypt at rest with a checkbox; TLS in transit.
• CloudWatch — metrics, logs, alarms, dashboards.
• CloudTrail — audit log of every API call ("who deleted that bucket?").
• X-Ray — distributed tracing across API Gateway → Lambda → DynamoDB.

• Three tiers of a web app: presentation, application (logic), data.
• TCP (Transmission Control Protocol) vs UDP (User Datagram Protocol): TCP = connection-oriented, reliable, ordered, slower — web/APIs/SSH/databases. UDP = connectionless, no delivery guarantee, fast — DNS, live video/audio, gaming.

• RPO (Recovery Point Objective) — max acceptable data loss, measured backward from the disaster. RTO (Recovery Time Objective) — max acceptable downtime until restored. Mnemonic: Point = data point you restore to; Time = downtime.
• DR (disaster recovery) strategies, cheapest/slowest → priciest/fastest: backup & restore → pilot light (data replicated, infra off) → warm standby (small live copy) → multi-site active/active.
• High availability (brief automated failover — Multi-AZ) vs fault tolerance (zero interruption — stronger, costlier) vs disaster recovery (recover from region-scale loss).
• Scaling: vertical = bigger machine; horizontal = more machines (the cloud way — needs LB + stateless instances).

AWS multiple choice has a house style. Given four plausible options:

• 1. Most managed wins. RDS beats Postgres-on-EC2; Fargate beats self-managed nodes; Lambda beats an idle server — unless the question plants a reason (needs OS control, >15-min runtime, existing Kubernetes).
• 2. Availability question → multi-AZ + load balancer + auto scaling. Multi-region only if it literally says disaster recovery / region failure.
• 3. Burst / overload / decouple → put SQS in the middle.
• 4. Security → IAM role, least privilege, encrypt, private subnet. Hardcoded keys or "make it public" is auto-wrong.
• 5. The qualifier decides between two valid answers. "MOST cost-effective" → Spot, S3 classes, caching. "LEAST operational overhead" → most managed/serverless. "HIGHEST availability" → more AZs/regions, cost be damned.
• 6. Two options are usually nonsense — eliminate them first, then apply rules 1–5 to the pair that remains.
• 7. 20 min ÷ ~15 questions ≈ 80 seconds each: answer, flag, move on. Never sink 5 minutes into one question.