---
title: "Compute, serverless, and containers"
chapter: "05"
---

# Compute, serverless, and containers

Choose compute by operational responsibility and workload behavior.

## Decision table

| Need | Good starting point | Why |
|---|---|---|
| Full OS control or legacy software | EC2 | maximum control |
| Container orchestration with AWS simplicity | ECS | managed AWS-native scheduler |
| Kubernetes ecosystem or portability need | EKS | managed Kubernetes control plane |
| Containers without managing hosts | Fargate | serverless container capacity |
| Short event-driven code | Lambda | pay per invocation, automatic scaling |
| Simple managed web deployment | App Runner or Elastic Beanstalk | less platform assembly |
| Batch jobs | AWS Batch | scheduling and compute orchestration |

## EC2 architecture

Put replaceable instances in an Auto Scaling group across multiple AZs, behind
an Application or Network Load Balancer. Keep session state outside instances.
Use launch templates, Systems Manager, and immutable images or automated
bootstrap. Choose Savings Plans or Reserved Instances only for predictable
baseline use; let burst capacity remain flexible.

## Lambda architecture

Functions should be small, idempotent where possible, and safe to retry. Control
concurrency, set timeouts, send failed asynchronous events to a destination or
dead-letter queue, and observe duration, errors, throttles, and downstream
pressure.

## Containers

Store images in ECR and scan them. Use ECS when the team wants containers
without Kubernetes complexity. Use EKS when Kubernetes capabilities, ecosystem,
or organizational standards provide real value. Fargate removes worker-node
management but may cost more at steady high utilization.

## Architect rule

Do not select the tool from fashion. Select it from runtime shape, control,
team skill, scaling, compliance, portability, and total operating cost.