Compute Selection: EC2, Containers, and Serverless

What This Chapter Is About

Help readers choose where code should run in AWS by matching execution model, operational control, deployment shape, scaling behavior, reliability needs, cost profile, and team skill.

Keep one durable idea in view:

Compute selection is an operating model decision before it is a service decision.

Sections

1. Compute Selection Mental Model

2. EC2 and Auto Scaling When Control Matters

3. Containers with ECS, Fargate, and EKS

4. Serverless and Event-Driven Compute with Lambda

5. Modernizing a Monolith Across Compute Options

How the Chapter Develops

The chapter develops in this order:

1. Start with the compute decision frame: control, packaging, scaling, operations, deployment, portability, and cost.

2. Explain EC2 and Auto Scaling for workloads that need VM-level control or compatibility.

3. Explain containers as a packaging and operations model, including the ECS/Fargate/EKS trade-off.

4. Explain Lambda as event-driven execution with strong boundaries and different constraints.

5. Apply the model to a monolith-modernization scenario where one answer rarely fits every component.

What You Will Be Able to Do

By the end of this chapter, the reader should be able to:

• Compare EC2, ECS/Fargate, EKS, and Lambda without turning the answer into a product list.

• Explain how operational ownership changes across compute choices.

• Match workload shape to deployment, scaling, reliability, and cost needs.

• Describe a practical modernization path for a mixed application.

Key Ideas

• The first question is not "Which compute service is best?" but "What operating model does this workload need?"

• More abstraction usually reduces infrastructure management but increases reliance on platform limits and service-specific design habits.

• Container adoption does not automatically mean Kubernetes.

• Serverless works best when workload boundaries, event contracts, retries, idempotency, and observability are designed.