Compute

AWS sells compute in four shapes, and almost every workload maps cleanly onto one of them. This section covers all four.

EC2 is a virtual server: you choose an instance type, an image and a network, and you are responsible for the operating system upwards. Reach for it when you need a specific kernel, a licensed operating system, GPU or FPGA hardware, or a long-lived machine that other things connect to. EC2 is also the substrate the other three run on, so its concepts — instance families, purchase options, Auto Scaling groups, placement groups — turn up everywhere else.

Containers cover Amazon ECS, Amazon EKS, AWS Fargate and Amazon ECR. This is the default for a long-running service you own the image for. The choice inside the section is really two choices: which orchestrator (ECS if you are staying on AWS, EKS if you need Kubernetes), and which capacity model (EC2 instances you manage, or Fargate, where AWS runs the host).

Lambda runs a function per event, scales to zero, and bills per millisecond. It suits glue code, event handlers and spiky request/response work that finishes inside the timeout. It is the wrong tool for anything with a long warm-up, sustained high throughput at predictable volume, or a hard requirement on the host.

AWS Batch queues containerised jobs and provisions capacity to drain the queue. Use it for work that is measured in job runs rather than uptime — rendering, simulation, ETL, model training — especially where Spot capacity makes the economics work.

If you are choosing for the first time: start with the managed end of the spectrum and move towards more control only when a concrete requirement forces you. Lambda and Fargate cost more per unit of compute and less per unit of engineer.