Compute
The ways to run code and workloads on AWS: virtual machines, serverless functions, batch jobs, and managed capacity.
Amazon EC2
Resizable virtual servers in the cloud — you pick the hardware profile, AWS runs the physical machine.
- You own everything from the OS up (patching, scaling, security config); AWS owns the hypervisor down — the classic shared responsibility split
- Instance families map to workload shape: general purpose (T/M), compute (C), memory (R/X), storage (I/D), accelerated (P/G) — the letter tells you what it's built for
- Purchasing options: On-Demand (no commitment), Reserved/Savings Plans (1 or 3 yr commitment), Spot (spare capacity, interruptible with 2-min warning), Dedicated Host/Instance (single-tenant hardware)
- Security groups are stateful instance-level firewalls (allow rules only); EBS root volumes persist through stop/start, instance store is wiped — it lives on the physical host
Exam triggers
Phrases and scenarios that point here.
- "Full control over the OS", "install custom/legacy software", "lift-and-shift migration" → EC2 over managed services
- Fault-tolerant, interruptible, or flexible-timing workloads at lowest cost → Spot
- Per-socket / per-core BYOL licensing or strict compliance isolation → Dedicated Host (not Dedicated Instance)
- Steady predictable usage → Reserved Instances or Savings Plans; spiky or unknown → On-Demand
Not this service
- Run code on events without managing servers, under 15 minutes → Lambda
- Run containers without choosing or managing instances → Fargate
Use cases
- Lift-and-shift of a legacy app that needs a specific OS version, agent, or kernel module a managed service won't allow
- Web tier in an Auto Scaling group behind a load balancer — instances are cattle, not pets; any one can die and be replaced
- Overnight batch and rendering jobs on Spot, where a 2-minute interruption just means the job re-queues, in exchange for the deepest discount
- Self-managed databases or software with per-core licensing pinned to a Dedicated Host to satisfy the license auditor
- GPU instances (P/G family) spun up for ML training runs, then terminated — paying for hours of hardware instead of owning it
Commonly confused with
Verified against AWS documentation · 2026-08-28
Amazon Lightsail
Simplified VPS offering with predictable flat monthly pricing — compute, storage, and data transfer in one bundle.
- Everything is bundled: instance, SSD storage, static IP, DNS, and a monthly data transfer allowance for one flat price
- Comes with pre-configured blueprints — WordPress, LAMP, Node.js, Windows — launch in minutes, no VPC design required
- Also offers managed databases (MySQL/PostgreSQL), containers, load balancers, and a CDN, all with the same flat-rate model
- Runs on EC2 under the hood; can peer into your default VPC and upgrade to full EC2 via snapshot export when you outgrow it
- Real-world divergence: exam paints Lightsail as small-workload-only, but AWS has since added memory-optimized (up to 512 GB) and compute-optimized (up to 72 vCPU) bundles — answer to exam convention
Exam triggers
Phrases and scenarios that point here.
- "Predictable monthly price", "simple", "low cost", "minimal AWS experience"
- Small business website, blog, or dev/test environment → Lightsail, not EC2
- "Launch a WordPress site quickly without managing infrastructure details"
- User wants a VPS-like experience without learning VPCs, security groups, or EBS
Not this service
- Fine-grained control, Auto Scaling, or Spot pricing → EC2
- Enterprise-grade managed relational database with read replicas across AZs → RDS
Use cases
- A freelancer spinning up client WordPress sites — one flat price per site makes quoting hosting costs trivial
- Dev/test sandboxes where you want a throwaway server this afternoon, not a VPC design meeting
- A small SaaS MVP: Lightsail instance + managed database + load balancer, all readable on one bill
- Migration ramp: start on Lightsail, snapshot and export to EC2 once traffic outgrows the bundles
- Think of it as the fixed-price lunch menu vs EC2's à la carte — less choice, zero bill anxiety
Commonly confused with
Verified against AWS documentation · 2026-08-28
AWS Auto Scaling
Automatically adds and removes capacity so you're running the right number of resources for current demand.
- Three numbers run everything: min, desired, max — the group never drops below min or climbs past max
- Launch template = what to launch; Auto Scaling group = how many and which AZs; scaling policy = when to change
- Failed health check → instance terminated and replaced automatically. This is self-healing, not just scaling
- Four ways to scale: target tracking (metric + target, the default answer), step/simple (alarm thresholds), scheduled (clock), predictive (ML forecast, scales OUT only, needs 24h of data)
- A group spans AZs inside one Region, never across Regions — ASG + ELB across 2–3 AZs is the standard HA answer
- Reality check: launch configurations are legacy. Accounts created on or after Oct 1, 2024 can't create them at all — launch templates only
Exam triggers
Phrases and scenarios that point here.
- "Match capacity to demand", "handle unpredictable traffic", "elasticity", "scale in and out"
- "Always keep N healthy instances" / "replace failed instances automatically" → ASG health checks
- Spike at the same time every day → scheduled scaling; spike that follows a learned pattern → predictive
- "Add more instances" is scaling out (this service); "use a bigger instance" is scaling up (not this service)
- Scaling something that isn't EC2 — DynamoDB capacity, ECS tasks, Aurora replicas → AWS Auto Scaling
Not this service
- Deciding which instance gets the request → ELB (Auto Scaling changes how many, ELB routes to them)
- Right-sizing to a bigger or cheaper instance type → Compute Optimizer
- Capacity that already scales itself with zero config → Lambda, S3, DynamoDB on-demand
Use cases
- Web tier behind an ALB that doubles at 9am and halves at 7pm — target tracking on CPU or request count keeps it honest with nobody watching
- A min=1, max=1 group used purely as a babysitter: if the box dies at 3am, a replacement is up before anyone gets paged
- Batch worker fleet on Spot, scaled on SQS queue depth — workers appear when the queue backs up and vanish when it drains
- Flash sale or exam-results day — scheduled scaling warms capacity 30 minutes ahead, because target tracking reacts too slowly for a wall of traffic arriving in 60 seconds
- Dev and test environments scheduled down to zero overnight and on weekends — the cheapest instance is the one that isn't running
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS Elastic Beanstalk
Platform-as-a-Service that deploys and runs your code on AWS-managed infrastructure you still own and can access.
- Upload code, Beanstalk provisions everything — EC2, ALB, Auto Scaling, monitoring — you keep full access to the underlying resources
- Two environment tiers: web server (handles HTTP) and worker (pulls jobs from an SQS queue)
- Platforms: Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker — one runtime per environment
- Deployment policies: all-at-once, rolling, rolling with additional batch, immutable, traffic splitting; blue/green via CNAME swap between two environments
Exam triggers
Phrases and scenarios that point here.
- "Deploy quickly without managing infrastructure" but still on EC2 (not serverless) → Beanstalk
- "Developers want to focus on code, not provisioning" → Beanstalk
- Zero-downtime deploy with instant rollback → immutable deployment or blue/green CNAME swap
- Migrating a traditional web app to AWS with minimal re-architecture → Beanstalk
Not this service
- Full control over infrastructure as code templates → CloudFormation
- Container orchestration at scale → ECS/EKS
- Event-driven, no servers at all → Lambda
- Deploying to on-premises or hybrid fleets → CodeDeploy
Use cases
- A three-person startup ships a Django app to production in an afternoon — no one on the team has written a CloudFormation template or wants to
- Lift-and-shift of an aging PHP monolith from a rented VPS: same code, but now with a load balancer, auto scaling, and health dashboards for free
- Worker tier chewing through a nightly invoice-generation queue — Beanstalk manages the SQS polling daemon so your code only sees HTTP POSTs
- Blue/green releases for a booking site that can't afford a bad Friday deploy: stand up the new environment, test it, swap CNAMEs, swap back in seconds if it breaks
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS Fargate
Serverless compute engine that runs ECS tasks and EKS pods without you managing any EC2 instances.
- Launch type for ECS and EKS, not a standalone service — you still define tasks/pods, Fargate just removes the host layer
- Task sizes: 0.25 vCPU / 512 MB up to 16 vCPU / 120 GB (Linux); CPU and memory must be a valid pairing
- Every task gets its own ENI (awsvpc mode) and its own isolated kernel — no sharing hosts with other tasks
- 20 GB ephemeral storage included per task, expandable to 200 GB; no GPUs, no privileged containers, no DaemonSets on EKS
Exam triggers
Phrases and scenarios that point here.
- "Run containers without managing servers/clusters/instances" → Fargate
- "Reduce operational overhead" for an ECS or EKS workload → Fargate launch type
- Team doesn't want to patch, scale, or right-size EC2 container hosts → Fargate
- Interrupt-tolerant containers at lowest cost → Fargate Spot (ECS only)
Not this service
- Event-driven code that runs under 15 minutes with no container to manage → Lambda
- Need GPUs, privileged containers, or full control over the host → ECS/EKS on EC2
- The orchestrator itself (services, scheduling, task definitions) → that's ECS or EKS; Fargate is only where they run
Use cases
- Small teams running a web API on ECS who'd rather ship features than babysit an EC2 cluster's AMI patching and capacity math
- Spiky batch jobs — nightly ETL, report crunching — where paying per-second for exactly what runs beats keeping instances warm
- Per-task isolation for multi-tenant or compliance-sensitive workloads, since no two tasks ever share a host kernel
- Fargate Spot for CI runners, queue workers, and anything that shrugs off a two-minute interruption notice
- EKS pods for teams that want Kubernetes semantics but zero node groups to upgrade or drain
Commonly confused with
Verified against AWS documentation · 2026-08-28
AWS Lambda
Serverless compute that runs your code in response to events — no servers to provision or manage.
- Event-driven: code runs only when triggered (S3 upload, API Gateway request, SQS message, schedule) and you pay only while it runs
- Scales automatically per-request — 1 invocation or 10,000 concurrent, no capacity planning
- Stateless between invocations — persist anything you need in S3, DynamoDB, etc.
- Limits: 15-min max timeout (hard), 128 MB–10,240 MB memory, 6 MB sync / 256 KB async payload, 512 MB /tmp (expandable to 10 GB), 1,000 default concurrency (soft)
Exam triggers
Phrases and scenarios that point here.
- "Serverless", "no infrastructure to manage", "pay only for what you use", "event-driven"
- Run code when something happens — file lands in S3, message hits a queue, API is called → Lambda
- Task exceeds 15 minutes → NOT Lambda; use ECS/Fargate, Batch, or Step Functions to break it up
- Unpredictable or spiky traffic where idle EC2 would waste money → Lambda
- Cron-style scheduled jobs without a server → EventBridge Scheduler + Lambda
Not this service
- Long-running (>15 min) or always-on workloads → ECS/Fargate or EC2
- Container orchestration with full control → ECS/EKS
- Multi-step workflow coordination with retries and branching → Step Functions (which calls Lambda)
Use cases
- Thumbnail factory: user uploads a photo to S3, the upload event fires a Lambda that resizes it — no server sitting idle waiting for uploads
- API backends via API Gateway, where each request spins up compute on demand and disappears — ideal when traffic is bursty or unpredictable
- Queue workers: Lambda polls SQS and processes orders/jobs in parallel, scaling with queue depth instead of a fixed worker fleet
- Scheduled housekeeping — nightly report generation, cleaning up expired records, rotating data — via EventBridge Scheduler instead of a cron server
- Real-time stream processing: transform or filter Kinesis/DynamoDB Streams records as they arrive
Commonly confused with
Verified against AWS documentation · 2026-08-28