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.