Lesson 1: The AWS Compute Map on One Page

Why start with a map

When someone says "we'll put it on AWS", that still leaves at least fifteen places the code could run. Most wrong compute choices aren't really wrong. They happen because nobody laid out the options first. In this level you lay out the options.

Think of it as a ladder of who does the work. At the bottom you rent a bare virtual machine and run everything above the hypervisor yourself. At the top you hand AWS a function or a container image and it runs the rest. Each step up gives AWS more of the work and gives you less control.

The map, grouped by hosting model

Gotcha: Fargate is not a separate orchestrator. It's a serverless capacity option that runs under ECS or EKS. In a design review, "ECS or Fargate?" is a mismatched question. The real one is "ECS on EC2 or ECS on Fargate?"

Walkthrough: map your own account

Before you choose something new, see what is already running. Each service has its own CLI namespace. This read-only sweep is safe in any account:

REGION=eu-west-1   # run the sweep once per Region you use

# Virtual machines
aws ec2 describe-instances --region $REGION \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name]' --output table
aws lightsail get-instances --region $REGION --query 'instances[].name'

# Containers
aws ecs list-clusters --region $REGION     # ECS clusters, EC2 or Fargate capacity
aws eks list-clusters --region $REGION     # Kubernetes control planes

# Serverless and platforms
aws lambda list-functions --region $REGION --query 'Functions[].FunctionName'
aws elasticbeanstalk describe-environments --region $REGION \
  --query 'Environments[].[EnvironmentName,SolutionStackName]'
aws apprunner list-services --region $REGION   # works only if the account already uses App Runner

# Batch and HPC
aws batch describe-compute-environments --region $REGION \
  --query 'computeEnvironments[].[computeEnvironmentName,type]'
aws pcs list-clusters --region $REGION     # AWS Parallel Computing Service

Typical output from a mid-sized team:

|  i-0a12...  |  m7g.large   |  running  |
|  i-0b34...  |  c7i.2xlarge |  stopped  |
"clusterArns": ["arn:aws:ecs:eu-west-1:1111:cluster/web"]
"clusters": []
["thumbnailer", "nightly-report"]

Read it like a map. Here you have a few VMs, one ECS cluster, no Kubernetes and two Lambda functions. That already tells you which skills the team has, and team skills count in every choice later on.

Using AWS's own decision guidance

AWS publishes a decision guide called Choosing an AWS compute service (last updated 17 February 2025). It covers EC2, Spot, Auto Scaling, Batch, Elastic Beanstalk, ECS, ECS Anywhere, EKS, EKS Anywhere, Fargate, Lambda, Local Zones, Dedicated Local Zones, Outposts, Wavelength and Savings Plans. You can boil it down into a quick triage that gets you to two or three candidates:

1. Does it run on demand, in short bursts, triggered by events?      -> Lambda (maybe Fargate)
2. Is it already a container, or will it be?
     team knows Kubernetes or needs its ecosystem  -> EKS (Auto Mode if you don't want to run nodes)
     otherwise                                     -> ECS (Express Mode for a simple web app/API)
3. Is it a queue of jobs that finish?               -> AWS Batch
   A tightly coupled Slurm/MPI workload?            -> PCS or ParallelCluster
4. Does it need full OS control, special licensing or hardware? -> EC2 (+ Auto Scaling)
5. Must it run on-premises or close to users?       -> Outposts / Local Zones / Wavelength
6. Is it a VMware estate you want to move unchanged? -> Amazon EVS

Worked example: a Python API that resizes images, already in a Dockerfile, with spiky daytime traffic. The questions point to ECS on Fargate and Lambda (container image), with EKS as an outside chance only if the platform team runs Kubernetes already. That gives three candidates, and later levels show how to score them.

Trade-off: the decision guide sorts by what kind of service something is. It does not check your quotas, Region availability or cost. Use it to narrow the field, not to make the final call.

Names, old and new

Old docs, Terraform modules and job adverts still use old names:

• Amazon EC2 Container Service is today's Elastic Container Service. The ECS name in AWS billing data changed in February 2021.
• CfnCluster became AWS ParallelCluster at version 2.0.0. The CLI changed from cfncluster to pcluster.
• AWS PCS (August 2024) is a different product from ParallelCluster. PCS is a managed service. ParallelCluster is an open-source tool that builds a cluster you then run yourself.
• EKS Auto Mode (December 2024) and ECS Express Mode (November 2025) are modes of existing services, not new services.
• Amazon EVS became generally available in August 2025. It is not the older, separately sold VMware Cloud on AWS.

Closed to new customers: AWS App Runner stopped accepting new customers on 30 April 2026. Existing customers can still create services, and AWS keeps up security and availability, but no new features are planned. AWS points migrating users to ECS Express Mode. If a blog post recommends App Runner, check whether your account can still use it.

Best practice: before you shortlist anything, look it up on AWS's service availability updates page. In June 2026 AWS moved several services into maintenance at once.

Key takeaways

• Sort AWS compute into seven hosting models. Each step up the ladder moves more of the operating work from you to AWS.
• Fargate is a capacity option under ECS or EKS, not a third orchestrator.
• Use AWS's Choosing an AWS compute service guide to get down to two or three candidates. Quotas, Regions and cost come later.
• PCS (managed) and ParallelCluster (self-run tool, formerly CfnCluster) are different products.
• App Runner has been closed to new customers since 30 April 2026. Its recommended successor is ECS Express Mode.