Module 3 · SAA-C03

Compute: EC2, Auto Scaling, Lambda, containers

Choosing EC2 instance types and purchase options, automatic scaling, serverless with Lambda, and containers on ECS / EKS / Fargate.

DomainResilient architectures
DomainHigh-performing architectures
DomainCost-optimized architectures
15 diagrams
10 scenarios
11 services

5-minute essentials

EC2 is a virtual machine where you manage the operating system; Lambda runs functions on events, up to 15 minutes per invocation; Fargate runs containers without you managing servers.Questions often add the constraint "least operational overhead" → lean toward Lambda / Fargate; long-running work, GPUs or a custom OS → EC2.
Instance families: C = compute, R / X = memory, I / D = fast local storage, P / G = GPU, T = burstable, M = general purpose.The exam doesn't ask exact generation names, but it often asks you to pick a family by workload profile (in-memory cache → R, HPC → C, ML training → P).
EC2 purchase options: On-Demand (no commitment), Savings Plans / Reserved (1- or 3-year commitment), Spot (cheapest, can be reclaimed), Dedicated Host (for per-socket / per-core licenses).Steady 24/7 workloads → Savings Plans or Reserved; interruptible workloads (batch, CI) → Spot; BYOL licenses tied to physical servers → Dedicated Host.
Spot gets a 2-minute warning before it is reclaimed (via EventBridge and instance metadata).The application must tolerate interruption: keep state outside (S3, DynamoDB, SQS) and checkpoint work.
Compute Savings Plans apply to EC2, Fargate and Lambda, letting you change family / Region / OS freely; EC2 Instance Savings Plans are cheaper but lock an instance family in one Region.Question asks for "most flexible while still discounted" → Compute Savings Plans.
An Auto Scaling group keeps the instance count between min and max, replaces unhealthy instances and balances across AZs; target tracking is the recommended default policy.It tracks one metric (CPU 50%, requests per target) and adds / removes instances automatically; scheduled scaling for load at known times; predictive scaling for cyclical load.
ALB: layer 7 (HTTP/HTTPS), routes by path / host / header, targets are EC2, IP, Lambda, containers. NLB: layer 4 (TCP/UDP/TLS), ultra-low latency, static IP per AZ. GWLB: inserts third-party security appliances.Need a fixed IP or UDP → NLB; routing /api, /images → ALB.
Placement groups: cluster (same AZ, fastest network), partition (up to 7 partitions per AZ, rack separation for Hadoop / Cassandra), spread (up to 7 instances per AZ, each on its own rack).Low-latency HPC → cluster; a few critical instances that must not fail together → spread.
Lambda: memory 128 MB–10 GB (CPU scales with memory), /tmp up to 10 GB, default 1,000 concurrent executions per Region (can be raised).Need it faster → add memory; cold starts on functions needing consistent response times → provisioned concurrency.
Synchronous Lambda invocations (API Gateway, ALB) return errors to the caller; asynchronous invocations (S3, SNS, EventBridge) retry 2 times automatically, then go to a DLQ / destination.Reading from SQS, Kinesis, DynamoDB Streams is an event source mapping: Lambda polls and pulls records in batches.
ECS and EKS are container orchestrators; Fargate or EC2 is where containers run; ECR is the image registry.Already on Kubernetes and need to move as-is to AWS → EKS; want the simplest option → ECS on Fargate.
Elastic Beanstalk and App Runner provision infrastructure from your code / image; AWS Batch queues and runs batch jobs on EC2 / Spot / Fargate.Question says "dev team not familiar with infrastructure, wants to ship a web app quickly" → Beanstalk / App Runner; "thousands of batch processing jobs" → Batch.
EC2 Hibernate saves RAM to the (encrypted) EBS root volume for fast restart; user data runs a script at launch; an AMI is the template for building identical instances.App starts slowly because it loads a lot into memory → hibernate or a prebuilt AMI (golden AMI).

Diagrams

EC2 instance lifecycle: stop, hibernate, terminate

Instance charges apply only in running (and in stopping when hibernating). While stopped you still pay for EBS volumes and any public IPv4 addresses held. On start the instance usually moves to another host: instance store data is lost and the public IPv4 changes (unless it is an Elastic IP).

Step by step

Launch: pending, then running; billed per second (1-minute minimum) from running.
Reboot: same host, keeps IPs and instance store data, does not start a new billing period.
Stop (EBS-backed instances only): instance charges stop; hibernate saves RAM to the root volume and is still billed while stopping.
Start again: usually a new host, instance store data is lost, the public IPv4 changes unless you use an Elastic IP.
Terminate: billing stops as soon as it is shutting-down; the root volume is deleted by default (DeleteOnTermination).

Auto Scaling group behind an ALB, scaling on CPU

The ALB distributes load to EC2 instances in an Auto Scaling group spanning two AZs. CloudWatch watches CPU; target tracking adds instances when above target and removes them when idle.

Step by step

The ALB distributes requests to healthy instances in the Auto Scaling group (ALB health checks).
Average CPU exceeds 50%: the CloudWatch alarm created by target tracking fires.
The ASG adds an instance (in the AZ with fewer instances); once it passes health checks, the ALB starts sending it requests.

Auto Scaling group mixing On-Demand and Spot

The baseline runs On-Demand; the rest runs Spot across multiple instance families. When Spot is about to be reclaimed, EventBridge receives the 2-minute warning so the instance can be drained and progress saved.

Step by step

The On-Demand baseline keeps minimum service; Spot is diversified across instance families to reduce the risk of simultaneous reclaims.
AWS needs the capacity back: EventBridge receives "EC2 Spot Instance Interruption Warning" 2 minutes ahead.
Unfinished work is returned to the queue; the ASG requests replacement instances automatically.

Three placement group types

Cluster: packs instances close together in one AZ for the fastest network. Partition: separate rack groups (up to 7 per AZ). Spread: each instance on its own rack (up to 7 instances per AZ).

ALB routes by path; NLB for TCP/UDP with static IPs

ALB reads HTTP, so it picks a target group by path. NLB only looks at the TCP/UDP port and keeps a fixed IP in each AZ.

Step by step

ALB: listener rules by path; targets can be containers, EC2, IPs or Lambda.
NLB: layer 4, supports UDP, static IPs (attach Elastic IPs) for customers to whitelist.

Event-driven Lambda

S3 invokes Lambda asynchronously when a new file arrives; Lambda pulls messages from SQS in batches (event source mapping). Messages that exceed the retry count go to the DLQ.

Step by step

Asynchronous invocation: S3 sends the event, Lambda runs, and on error it retries 2 times automatically.
Event source mapping: Lambda polls SQS, receives a batch of messages and deletes them once processed.
Messages that fail processing more than maxReceiveCount times move to the DLQ for review.

Synchronous and asynchronous Lambda invocation

Synchronous: the caller waits for the result and handles errors itself. Asynchronous: Lambda puts the event in an internal queue, retries automatically, then sends it to a destination.

ECS on Fargate behind an ALB

Each Fargate task has its own ENI in a private subnet and its own IAM task role. Images are pulled from ECR; the ALB uses the IP target type.

Step by step

The ECS service keeps the desired number of tasks; Fargate pulls the image from ECR and runs the task, with no servers to manage.
The ALB sends requests directly to each task's IP (awsvpc network mode).
Tasks access S3 with the IAM task role, no access keys needed.

Amazon EKS: control plane managed by AWS

AWS runs and patches the Kubernetes control plane across multiple AZs. Pods run on managed node groups (EC2) or Fargate; Ingress creates an ALB via the AWS Load Balancer Controller.

Step by step

The control plane (AWS-managed, multi-AZ) schedules Pods onto the node group's EC2 nodes or onto Fargate.
The AWS Load Balancer Controller turns an Ingress into an ALB pointing at the Pods.

AWS Batch running batch jobs on Spot

Jobs are submitted to a queue; Batch provisions the compute environment (Spot, multiple instance families), runs the containers, then scales down to 0 when the work is done.

Step by step

EventBridge submits jobs to the Batch queue on a schedule.
Batch launches enough Spot instances for the queue, runs the containers and writes results to S3; when the work is done it scales down to 0.

Lambda: cold start, warm start and how to reduce cold starts

Cold start = create the environment, download the code, start the runtime and run the code outside the handler. Provisioned concurrency keeps initialized environments ready. SnapStart (Java 11+, Python 3.12+, .NET 8+) restores from a snapshot taken after init, but cannot be combined with provisioned concurrency.

Health checks and cross-zone load balancing

ALB always has cross-zone on at the load balancer level (can be turned off per target group); NLB and GWLB have it off by default, in which case each node only distributes to targets in its own AZ. Targets that fail health checks stop receiving requests and get them again once healthy. An Auto Scaling group with ELB health checks enabled also replaces unhealthy instances.

Step by step

Requests reach the ALB; each AZ enabled for the ALB has one load balancer node.
A target that fails consecutive health checks becomes unhealthy: the ALB stops sending it requests.
With cross-zone on, requests are spread evenly across all healthy targets in all AZs, regardless of how many instances each AZ has.

IMDSv2: get a token first, then read metadata

IMDSv2 requires a PUT to get a token (TTL up to 21,600 seconds = 6 hours), then the token is sent with every GET, blocking SSRF attacks through proxies that can only forward GETs. Instances can be set to accept IMDSv2 only. The PUT response has a default hop limit of 1: containers running on the instance need it raised to 2.

Auto Scaling group lifecycle hooks

A lifecycle hook holds an instance in a wait state to run custom actions: install software before taking requests, collect logs or leave a cluster before termination. The instance waits until complete-lifecycle-action is called or the wait times out (default 1 hour, extendable with heartbeats).

Step by step

Scale out: the hook holds the instance in Pending:Wait to run setup scripts; call complete-lifecycle-action or wait for the timeout (default 1 hour).
The instance enters InService and starts receiving requests from the load balancer.
Scale in: the instance is removed from the load balancer and the hook holds it in Terminating:Wait to collect logs and back up data.
When the work is done (or the timeout expires), the instance is terminated.

Choosing a compute service

Exam questions usually lean toward "least operational overhead": prefer Lambda, Fargate, App Runner, Beanstalk; choose EC2 only when you need OS control, special hardware or software that can't run elsewhere.

Step by step

Runs longer than 15 minutes or continuously: not a fit for Lambda.
Already containerized, need custom networking, sidecars, many services: ECS or EKS on Fargate, no servers to manage.
Need OS control, GPUs, legacy software: EC2 in an Auto Scaling group.

Quick comparisons

EC2, Lambda, Fargate

	EC2	Lambda	Fargate (ECS / EKS)
You manage	OS, patching, scaling	Code only	Container image, task CPU / memory
Run time	Unlimited	Up to 15 minutes per invocation	Unlimited
Billing	Per second while running	Per request and duration × memory	Per task vCPU and memory
Best for	Legacy apps, GPU, custom OS, 24/7 workloads	Event processing, small APIs, short tasks	Microservices, long-running containers without managing servers

EC2 purchase options

Option	Commitment	Max discount	Use when
On-Demand	None	—	Short, unpredictable workloads, testing
Compute Savings Plans	1 or 3 years, in USD/hour	Up to 66%	Steady workloads, want to change family / Region / include Fargate, Lambda
EC2 Instance Savings Plans / Reserved Instances	1 or 3 years, per instance family	Up to 72%	Steady workloads, instance family and Region known for sure
Spot	None, can be reclaimed (2-minute warning)	Up to 90%	Batch, CI, image processing, interruptible analytics
Dedicated Host	Hourly or reserved	—	Per-socket / per-core licenses, compliance requiring dedicated physical servers

ALB, NLB, GWLB

	ALB	NLB	GWLB
Layer	7 (HTTP/HTTPS, gRPC, WebSocket)	4 (TCP, UDP, TLS)	3 (IP packets, GENEVE protocol)
Routing	By path, host, header, query	By port	Through virtual appliances (firewall, IDS)
IP	Changes, use the DNS name	Static IP per AZ, can attach Elastic IP	—
Target	EC2, IP, Lambda, container	EC2, IP, ALB	Security appliances
Exam example	Microservices /api, /web	UDP gaming, IP whitelisting, millions of connections	Insert a third-party firewall for all traffic

Placement groups

	Cluster	Partition	Spread
Scope	One AZ	Multiple AZs, up to 7 partitions per AZ	Multiple AZs, up to 7 instances per AZ
Goal	Low latency, high bandwidth between instances	Isolate hardware failures by rack group	Each instance on its own rack
Best for	HPC, parallel computing	HDFS, HBase, Cassandra, Kafka	A few critical instances (primary / standby)

ECS, EKS and where containers run

	ECS	EKS
Orchestration	AWS-native, simple	Standard Kubernetes (control plane managed by AWS)
Runs on	Fargate or EC2	Fargate, managed node group, self-managed node
Pick when	You want simplicity, deep AWS integration	Already on Kubernetes, need portability across environments / K8s tooling
AWS access	Task role (IAM) per task	IAM roles for service accounts / Pod Identity

Exam scenarios

1A web app runs on EC2 behind an ALB; traffic spikes during business hours and drops at night. It needs to scale automatically and keep CPU around 50%.

Show answer

Right: Auto Scaling group across ≥ 2 AZs, attached to the ALB target group, target tracking keeping average CPU at 50%
Target tracking creates CloudWatch alarms automatically and adds / removes instances to stay on target; the ASG replaces unhealthy instances and balances across AZs.

Wrong: Simple scaling policy with a 300-second cooldown
Works, but slow and jerky; AWS recommends target tracking.

Wrong: Scale up to a very large instance size
Scaling up costs money even when idle and is still a single point of failure.

2Every night 2 million images are processed; work can be redone if interrupted; lowest cost is required.

Show answer

Right: AWS Batch (or an Auto Scaling group) using Spot Instances across multiple instance families; work is read from a queue so it can be redone when reclaimed
Spot is up to 90% cheaper; diversifying instance families lowers the chance of simultaneous reclaims; the queue keeps unfinished work.

Wrong: 3-year Reserved Instances
Pays for the whole day while it only runs a few hours at night.

Wrong: On-Demand
Much more expensive than Spot for interruptible workloads.

3A workload runs steadily 24/7 on EC2, but the company plans to gradually move to Fargate and Lambda over the next 3 years.

Show answer

Right: Compute Savings Plans
Commit to USD/hour, applied automatically to EC2, Fargate and Lambda in every Region.

Wrong: EC2 Instance Savings Plans
Locks an instance family in one Region and does not apply to Fargate / Lambda.

Wrong: Spot
A critical 24/7 workload should not be exposed to reclaims.

4An HPC compute cluster needs the lowest possible network latency between nodes.

Show answer

Right: Cluster placement group in one AZ, instances with enhanced networking
The instances sit in the same high-bandwidth network segment.

Wrong: Spread placement group
Places instances on different racks: improves resilience, does not reduce latency.

Wrong: Spread instances across 3 AZs
Latency between AZs is higher than within one AZ.

5A gaming application uses UDP; enterprise customers require fixed load balancer IPs to open their firewalls.

Show answer

Right: Network Load Balancer with an Elastic IP in each AZ
NLB works at layer 4, supports UDP and has a static IP per AZ.

Wrong: Application Load Balancer
ALB does not support UDP and its IPs change.

6A Lambda function processes images when users upload to S3; occasionally it fails and events are lost.

Show answer

Right: Configure an on-failure destination (or DLQ) on SQS / SNS for asynchronous invocations; monitor and reprocess
Asynchronous invocations are retried 2 times; after that the event goes to the destination instead of being lost.

Wrong: Increase the timeout to 15 minutes
Does not handle events that genuinely fail.

7An API on Lambda has inconsistent latency because of cold starts on Monday mornings.

Show answer

Right: Provisioned concurrency (can be scheduled for peak hours)
Keeps a set number of initialized environments ready, so invocations don't hit cold starts.

Wrong: Increase reserved concurrency
Reserved concurrency only reserves / caps capacity; it does not warm execution environments.

8A company has containerized microservices, doesn't want to manage servers or clusters, and needs the least operational overhead.

Show answer

Right: ECS on Fargate, images in ECR, ALB in front
No servers to manage; each task has its own ENI and IAM role.

Wrong: EKS with a self-managed node group
You still patch, scale and manage nodes.

Wrong: Run Docker on self-installed EC2
The most operational overhead.

9There are many Kubernetes manifests and tools on-premises; the goal is to move to AWS while keeping the same deployment approach.

Show answer

Right: Amazon EKS (managed node group or Fargate)
Standard Kubernetes API, control plane managed by AWS.

Wrong: ECS
Requires rewriting as task definitions and dropping Kubernetes tooling.

10A video processing task takes 40 minutes per run.

Show answer

Right: ECS / Fargate task or AWS Batch (triggered by events via EventBridge / Step Functions)
Containers run without a time limit, still with no servers to manage.

Wrong: Lambda
Limited to 15 minutes per invocation.

Quick picks

Where should the code run?

When you need	Use
Short event processing (under 15 minutes), irregular traffic	Lambda · see diagram
Containers, no servers to manage	ECS on Fargate · see diagram
Already using Kubernetes	EKS · see diagram
Need full OS control, GPU, legacy software	EC2 + Auto Scaling group · see diagram
Large volumes of batch jobs, interruptible	AWS Batch on Spot · see diagram
Web app, developers not familiar with infrastructure	Elastic Beanstalk or App Runner · see diagram
HTTP, routing by path / host	Application Load Balancer · see diagram
TCP / UDP, static IP, ultra-low latency	Network Load Balancer · see diagram
Steady workload for years, may move to Fargate / Lambda	Compute Savings Plans
Interruptible workload, cheapest option needed	Spot (diversified instance families) · see diagram
Instances need the lowest network latency between them	Cluster placement group · see diagram

Common pitfalls

Using Lambda for work that runs longer than 15 minutes.
Choosing Reserved / Savings Plans for a workload that runs only a few hours a day: Spot or On-Demand + scaling is cheaper.
Putting critical, non-interruptible workloads on Spot (primary database, user sessions held in RAM).
Confusing reserved concurrency (cap / reservation) with provisioned concurrency (pre-warming, prevents cold starts).
Using ALB for UDP or when the question requires a static IP: that is NLB.
An Auto Scaling group in only one AZ: if the AZ fails, everything is lost.
A spread placement group for HPC that needs low latency (it must be cluster), or placing more than 7 instances per AZ in a spread group.
Storing user sessions on EC2 disk / RAM in an ASG: they are lost when the instance is replaced; move sessions to ElastiCache / DynamoDB.
Thinking Fargate is an orchestrator: Fargate is where things run; ECS / EKS are the orchestrators.
Granting containers AWS permissions with access keys in environment variables instead of a task role / IAM role for the Pod.
Thinking EC2 Instance Savings Plans apply to Lambda / Fargate: only Compute Savings Plans do.

Services in this module

Numbers that change (checked against AWS docs)

Lambda runs up to 15 minutes per invocation (900 seconds); memory 128 MB–10,240 MB; /tmp 512 MB–10,240 MB. checked 2026-10-16 ↗
Lambda defaults to 1,000 concurrent executions per Region (can be raised to tens of thousands). checked 2026-10-16 ↗
Lambda: 6 MB payload for synchronous invocations, 1 MB for asynchronous; zip package 50 MB (zipped) / 250 MB (unzipped), container image up to 10 GB. checked 2026-10-16 ↗
A Spot Instance gets a 2-minute warning before it is stopped / terminated (EventBridge and instance metadata). checked 2026-10-16 ↗
Spot is up to 90% cheaper than On-Demand. checked 2026-10-16 ↗
Compute Savings Plans save up to 66% and apply to EC2, Fargate, Lambda; EC2 Instance Savings Plans save up to 72%; 1- or 3-year terms. checked 2026-10-16 ↗
Partition placement group: up to 7 partitions per AZ; spread placement group: up to 7 running instances per AZ; a cluster placement group sits in one AZ. checked 2026-10-16 ↗
Fargate Spot: tasks are interrupted with a 2-minute warning. checked 2026-10-16 ↗
The default Auto Scaling cooldown is 300 seconds and applies only to simple scaling policies; AWS recommends target tracking. checked 2026-10-16 ↗
Lambda SnapStart supports Java 11+, Python 3.12+, .NET 8+; it cannot be combined with provisioned concurrency. checked 2026-10-19 ↗
ALB always has cross-zone load balancing on at the load balancer level; NLB and GWLB have it off by default. checked 2026-10-19 ↗
IMDSv2: the token is obtained with PUT, TTL up to 21,600 seconds; the PUT response has a default hop limit of 1. checked 2026-10-19 ↗
Auto Scaling group lifecycle hooks: instances wait in Pending:Wait / Terminating:Wait, by default up to 1 hour (extendable with heartbeats). checked 2026-10-19 ↗

Practice this module →