Compute Selection Mental Model

Goal

Part 04 turns AWS responsibilities into practical service-selection decisions. Compute is a good place to start because every workload needs somewhere to run, but not every workload should run in the same way.

This section gives you the decision frame before we compare EC2, containers, and Lambda. The goal is not to memorize a hierarchy of "old" and "modern" services. The goal is to match each workload to the operating model it can safely live with.

The Short Version

The quick question is:

Which AWS compute service should we use?

The better architecture question is:

What kind of work is this, and who should own the runtime, scaling, deployment, and failure behavior?

Compute selection is workload placement plus operating ownership. You are deciding where code runs, but you are also deciding who owns patching, scaling, runtime dependencies, deployment safety, identity, networking, observability, and cost control.

AWS gives you several compute styles:

Compute Style	Plain-Language Meaning	Good Fit
Virtual machines	You run code on cloud servers with strong control over the OS and runtime.	Legacy apps, custom agents, special licensing, long-running services, migration compatibility.
Containers	You package the app and dependencies into images, then run them on a container platform.	APIs, services, workers, portable packaging, repeatable deployment, microservices, platform standardization.
Serverless functions	You run small units of code in response to events without managing servers.	Event processing, automation, API handlers, file processing, glue logic, bursty workloads with clear boundaries.
Managed platform entry points	You let managed services handle the front door or surrounding platform responsibility.	API front doors, traffic management, authorization, throttling, monitoring, versioning.

Do not worry if the service names feel dense at first. In this chapter, EC2, ECS, Fargate, EKS, Lambda, and API Gateway are vocabulary for different operating models.

The Compute Decision Filters

Use this mental model:

Workload shape
  -> control and compatibility needs
  -> packaging and deployment model
  -> scaling and reliability behavior
  -> team operating model
  -> AWS compute choice

Start with workload shape. Is the code an always-on API, a scheduled job, a background worker, an event processor, a batch task, a legacy application, or a short-lived function? A public API with steady traffic behaves differently from a nightly report. A file-processing task behaves differently from a stateful application server.

Then ask how much control the team needs. Some workloads need OS-level access, special drivers, custom monitoring agents, or licensing arrangements. Some only need a stable runtime and a way to receive traffic. Some are small units of logic that can run when an event arrives.

Next, ask how the team packages and deploys change. A team with strong container practices may benefit from a container platform. A team moving a legacy application may need EC2 first. A team building event-driven processing may be faster with Lambda, but only if the event contract and failure behavior are clear.

Finally, ask how the workload scales and fails. Does it need a warm fleet? Can it start on demand? Is traffic steady, spiky, or scheduled? Can duplicate work be tolerated? What happens when a downstream service is slow?

Service Names After Responsibilities

Once the responsibility is clear, service names become useful:

Question	What It Often Points Toward
Do we need VM-level control or migration compatibility?	EC2, usually with Auto Scaling and load balancing.
Do we want container packaging with AWS-native orchestration?	ECS, often with Fargate when the team does not want to manage EC2 capacity.
Do we need Kubernetes APIs, tooling, or ecosystem compatibility?	EKS, with careful attention to Kubernetes operating skill.
Is this a clear event-driven unit of work?	Lambda, with event sources, permissions, retries, idempotency, and observability.
Do we need a managed API front door?	API Gateway, often in front of Lambda, containers, or other backends.

This table is a starting point, not a final design. The actual answer still depends on networking, identity, data access, deployment pipeline, logging, cost model, and team capability.

Example: One Application, Several Compute Answers

Imagine a customer-facing application with five components:

A web front end.
A public API.
A background order processor.
An image-processing task.
A legacy reporting component that depends on a specific OS configuration.

It would be tempting to ask for one compute service for the whole application. A better architecture answer separates the workload shapes.

The legacy reporting component may start on EC2 because compatibility matters more than abstraction. The public API may move to containers because the team wants repeatable packaging, horizontal scaling, and controlled deployments. The image-processing task may fit Lambda because it runs when a file arrives and has a clear input and output. The background order processor may be a container worker or Lambda function depending on processing time, dependency shape, throughput, and retry behavior.

The point is not to make the design complicated. The point is to avoid forcing unlike workloads into one operating model.

Common Mistakes

Asking "Which service should we use?" before describing the workload shape.
Treating containers as the automatic modernization target.
Treating serverless as a way to avoid design decisions.
Choosing the most abstract option before checking limits, event contracts, observability, and team skill.
Keeping everything on EC2 because it feels familiar, even when the team is ready for a simpler operating model.

If Someone Asks You

How do you choose between EC2, containers, and serverless?

A good answer is:

I start with workload shape and operating ownership. If the workload needs OS-level control, special compatibility, or a migration bridge, EC2 may be the right starting point. If the team wants repeatable packaging and service-style deployment, containers with ECS, Fargate, or EKS may fit. If the work is event-driven, stateless, and bounded, Lambda can reduce server management. I would not choose one runtime for the whole system until I understand scaling, deployment, failure handling, observability, cost, and team skill.

What You Should Remember

Choose compute by workload shape, ownership, and change pattern.

Questions to Check Your Understanding

What workload traits make VM-level control useful?
What workload traits make event-driven compute attractive?
Why might one system use more than one AWS compute model?