Choosing a Compute Service

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

See the section bibliography for the reference material consulted while preparing these pages.

Commands below target AWS CLI v2 (the 2.37 line, checked 2026-10-01) and use us-east-1 as a placeholder Region; re-verify flags with aws <service> <command> help before relying on them. Service availability statements on this page were checked against the AWS documentation on 2026-10-01 and change over time, so read the AWS service lifecycle page before committing to a service.

AWS offers more ways to run code than any other cloud, and picking the wrong one early usually means a rewrite rather than a configuration change. This page walks through AWS’s own decision guides, summarises the options that do not get a dedicated hands-on page in this section (Lightsail, Elastic Beanstalk, Batch, App Runner) in one paragraph each, and ends with a single comparison table across everything that does. The detailed pages are EC2 and Auto Scaling, ECS and Fargate, Lambda and EKS clusters. The running Bookshelf scenario used throughout the section (a static front end, catalog-api, orders-api and the notifier worker) is placed on these services at the end of the page. The same exercise for Azure is on Azure: Choosing a compute service.

The official decision guides

AWS publishes decision guides that frame the choice by operating model rather than by product. The Choosing an AWS compute service and Choosing an AWS container service guides organise the options into three layers:

Capacity: where the code physically runs. Amazon EC2 instances (you manage the OS), AWS Fargate (serverless capacity for containers, no instances to manage) and AWS Outposts (AWS capacity in your own facility).
Orchestration: what schedules and scales containers on that capacity. Amazon ECS (AWS-native), Amazon EKS (managed Kubernetes) and Red Hat OpenShift Service on AWS.
Vertical solutions: opinionated bundles for people who want less infrastructure. Lambda for functions, plus Lightsail, Batch and App Runner.

The guides stress that the first question is the operating model you want: a serverless model (you hand over a function or an image and AWS runs it) or a Kubernetes model (you keep the Kubernetes API, its ecosystem and the portability it brings, and accept its upgrade cadence). In practice most organisations use both. The decision criteria the guides list are the managed-service and operational overhead you can afford, the workload shape (web, event-driven, batch, streaming), portability, the skills of the team, and how simple the first deployment must be.

The flowchart below condenses those criteria into the options this section documents. It is a starting point, not a substitute for the guides, and every box can legitimately be overridden by an existing team skill or a compliance requirement.

flowchart TD Start["Need to run code on AWS"] FullOS{"Need full OS control, a custom kernel or a lift-and-shift?"} Simple{"Small project that wants flat, predictable pricing and a simple console?"} Batch{"Queued, finite batch jobs that run to completion?"} Event{"Event-driven or short-lived code, scale to zero?"} Container{"Already packaged as a container image?"} K8s{"Need the Kubernetes API, CRDs, operators or portability?"} Fast{"HTTP service, fastest path to a production URL?"} Control{"Need custom networking, deployment strategies or sidecars?"} Start --> FullOS FullOS -- Yes --> EC2["Amazon EC2 and Auto Scaling"] FullOS -- No --> Simple Simple -- Yes --> LS["Amazon Lightsail"] Simple -- No --> Batch Batch -- Yes --> BATCH["AWS Batch"] Batch -- No --> Event Event -- Yes --> LAMBDA["AWS Lambda"] Event -- No --> Container Container -- No --> EB["Elastic Beanstalk or package as a container"] Container -- Yes --> K8s K8s -- Yes --> EKS["Amazon EKS, Auto Mode first"] K8s -- No --> Fast Fast -- Yes --> EXPRESS["ECS Express Mode"] Fast -- No --> Control Control -- Yes --> ECS["ECS on Fargate or ECS Managed Instances"] Control -- No --> EXPRESS

References: Choosing an AWS container service, Choosing an AWS compute service, AWS Decision Guides.

Current status of retired and closing services

Older tutorials and articles still recommend services whose availability has changed. As of 2026-10-01:

AWS App Runner has been closed to new customers since 2026-04-30. Existing customers can keep using it, including creating new services, but AWS does not plan new features. The recommended migration target is Amazon ECS Express Mode (announced 2025-11), which keeps the "image plus two IAM roles" simplicity while giving access to the wider ECS feature set. AWS publishes a migration walkthrough that shifts traffic with Route 53 weighted records. For a new project, start with Express Mode instead.
AWS Copilot CLI, a command-line tool that scaffolded ECS applications, reached end of support on 2026-06-12. Existing Copilot-created CloudFormation stacks keep running, but nothing new is added to the tool. Use ECS Express Mode for the quick start and CloudFormation, CDK or SAM (see Infrastructure as code) for repeatable infrastructure.
AWS Cloud9 (a browser IDE) has been closed to new customers since 2024-07 and CodeCatalyst closed on 2025-11-07; see Developer tools and DevOps for the replacements.
Older guides that deploy containers with CodeDeploy-driven ECS blue/green or on a hand-built EC2 cluster predate ECS built-in blue/green (2025-07) and linear/canary (2025-10) deployments; see ECS deployments, scaling and networking.

References: AWS App Runner availability change, Announcing the end of support for the AWS Copilot CLI, AWS service lifecycle.

Amazon EC2

Amazon EC2 is the IaaS baseline: virtual machines on AWS-managed hardware. You choose an AMI (an image, with Amazon Linux 2023 as the current default; Amazon Linux 2 reached end of support on 2026-06-30), an instance type (family and size, including Arm-based Graviton), storage and a network placement, and you own everything above the hypervisor: patching, runtime, process supervision and scaling. Reach for EC2 when you need OS or kernel control, specialised hardware such as GPUs, licensing tied to a machine image, a lift-and-shift of an existing server, or the lowest unit cost for steady, well-understood workloads. EC2 is also the capacity layer under ECS and EKS when you do not use Fargate. Pricing is per instance-second while running, with Savings Plans and Spot as cost levers. The full hands-on treatment is on EC2 and Auto Scaling.

References: Amazon EC2 documentation, aws ec2 run-instances.

Amazon Lightsail

Amazon Lightsail is a simplified "virtual private server" product: pre-configured instances, container services, managed databases, load balancers, CDN distributions and static IPs behind a small console with bundle-based pricing, where a bundle fixes vCPU, memory, storage and a monthly data-transfer allowance. It suits small sites, prototypes, learning environments and teams that want predictable monthly pricing and little AWS vocabulary. It is deliberately a separate, simpler resource model: Lightsail resources live in a Lightsail-managed network, and connecting them to a full VPC needs VPC peering, so a workload that is likely to grow into IAM-heavy, multi-service architectures is better started on ECS Express Mode or EC2. Lightsail container services run a container image with a fixed scale (a power value and a node count) behind a built-in HTTPS endpoint.

In the AWS Management Console

Open the Lightsail console (search for "Lightsail") and select the Region from the Region selector.
Choose the Containers tab, then Create container service.
Pick a Capacity (power and scale), then choose Set up deployment and enter the image reference (a public image or one pushed with the Lightsail plugin), the container port and the public endpoint container.
Choose Save and deploy and wait for the service state to become Running.

With the AWS CLI

export AWS_REGION=us-east-1

# Create a container service (power and scale fix the capacity and price)
aws lightsail create-container-service \
  --service-name bookshelf-lite \
  --power nano \
  --scale 1 \
  --region $AWS_REGION

# Deploy a public image and expose it through the built-in HTTPS endpoint
aws lightsail create-container-service-deployment \
  --service-name bookshelf-lite \
  --containers '{"web":{"image":"nginx:stable","ports":{"80":"HTTP"}}}' \
  --public-endpoint '{"containerName":"web","containerPort":80}' \
  --region $AWS_REGION

# Read the public URL once the state is RUNNING
aws lightsail get-container-services --service-name bookshelf-lite \
  --query "containerServices[0].[state,url]" --output text --region $AWS_REGION

References: aws lightsail create-container-service, aws lightsail create-container-service-deployment, Lightsail container services.

AWS Elastic Beanstalk

AWS Elastic Beanstalk is the original platform-as-a-service on AWS. You upload an application bundle (a JAR or WAR for Java, a zip for Node.js, Python, .NET and others, or a Docker configuration) and Beanstalk provisions and wires the underlying EC2 instances, Auto Scaling group, load balancer and monitoring, and applies managed platform updates. The resources are ordinary EC2 and Elastic Load Balancing resources in your account, so you keep the ability to tune them, but you also keep the maintenance model of instance-based hosting, and the deployment tooling (the EB CLI, environments, configuration files) is its own dialect. It remains a reasonable choice for an existing application that already deploys this way and for teams that want a Heroku-style flow without containers. For a new containerised service, ECS Express Mode delivers the same "hand over the artifact, get a URL" experience on Fargate, and that is where AWS’s own recommendation for simple container hosting now points. Check the platform support policy before choosing a runtime branch, since platform versions are retired on a schedule.

# With the EB CLI (a separate tool from the AWS CLI, installed with pip or a bundled installer)
eb init bookshelf-beanstalk --platform "Corretto 21" --region us-east-1
eb create bookshelf-beanstalk-env
eb status
eb terminate bookshelf-beanstalk-env

References: The EB CLI, What is AWS Elastic Beanstalk?, aws elasticbeanstalk create-environment.

AWS Batch

AWS Batch runs batch computing workloads, meaning finite jobs that read input, compute and exit, such as rendering, simulations, nightly data processing or machine-learning preparation. You define a job definition (a container image, vCPU and memory), a job queue and a compute environment, and Batch provisions capacity on EC2, Spot or Fargate to drain the queue, scaling down to nothing when it is empty. There is no charge for Batch itself, only for the underlying compute. Choose it over a service-style ECS deployment when work arrives as a queue of independent or dependent jobs with retries and priorities rather than as a continuously running listener; choose Lambda instead when each unit of work fits in a short, event-triggered function.

References: What is AWS Batch?, aws batch submit-job.

AWS App Runner

App Runner was a fully managed service that built or pulled a source or image and ran it behind a load-balanced HTTPS endpoint with automatic scaling and scale-to-zero-like pausing. Its availability status is described above: closed to new customers since 2026-04-30, still operating for existing customers. Do not start new projects on it. Migrating an existing App Runner service means creating an ECS Express Mode service from the same image, adding the custom domain and shifting traffic with Route 53 weighted records, as AWS’s migration guide describes.

References: AWS App Runner availability change.

The container and serverless options in one place

The remaining options each have a hands-on page. A short orientation:

ECS Express Mode: you provide a container image, a task execution role and an infrastructure role, and ECS provisions a Fargate service, an Application Load Balancer (shared across Express services), auto scaling, security groups and an HTTPS URL. Express Mode itself has no extra charge, you pay for the resources it creates. The resources remain ordinary ECS resources that you can adopt and customise later. See ECS and Fargate.
ECS on Fargate: the full ECS model (task definitions, services, load balancers, deployment strategies, Service Connect) with serverless capacity. See ECS and Fargate and ECS deployments, scaling and networking.
ECS on EC2 and ECS Managed Instances: the same ECS model on instances, where Managed Instances lets AWS provision and patch the instances for you while you keep access to instance types Fargate does not offer, such as specific GPU or high-memory families.
Lambda and Lambda Managed Instances: functions billed per request and duration with scale to zero; Managed Instances run Lambda functions on EC2 capacity in your account for steady, high-throughput workloads. See Lambda and Lambda event-driven and serverless apps.
EKS (Auto Mode, managed node groups, Fargate): managed Kubernetes. Auto Mode has AWS manage the nodes, storage and load balancing integration, while managed node groups leave node management with you. See EKS clusters and EKS microservices.

References: Amazon ECS Express Mode overview, Amazon ECS Managed Instances, What is AWS Lambda?, EKS Auto Mode.

Trying the fastest path: ECS Express Mode

The shortest route from an image to a URL on AWS is a single call. The two roles (ecsTaskExecutionRole and ecsInfrastructureRoleForExpressServices) must exist first; creating them is covered step by step on ECS and Fargate.

export AWS_REGION=us-east-1
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

aws ecs create-express-gateway-service \
  --service-name catalog-api \
  --execution-role-arn arn:aws:iam::${ACCOUNT_ID}:role/ecsTaskExecutionRole \
  --infrastructure-role-arn arn:aws:iam::${ACCOUNT_ID}:role/ecsInfrastructureRoleForExpressServices \
  --primary-container '{"image":"'${ACCOUNT_ID}'.dkr.ecr.'${AWS_REGION}'.amazonaws.com/bookshelf/catalog-api:latest","containerPort":8080}' \
  --health-check-path /actuator/health \
  --scaling-target '{"minTaskCount":1,"maxTaskCount":4}' \
  --monitor-resources

References: aws ecs create-express-gateway-service, Create your first Express Mode service.

Comparison table

The table summarises the options on the dimensions the decision guides weigh. "Scale to zero" means the compute bill can fall to zero when there is no traffic; pricing columns describe the billing model only, so check the dated pricing pages linked in the references for numbers.

Option Control Scaling Scale to zero Networking Pricing model Use it when

Option	Control	Scaling	Scale to zero	Networking	Pricing model	Use it when
EC2 and Auto Scaling	Full OS and instance control	Auto Scaling groups with target-tracking, step and scheduled policies	No (an ASG can be set to 0 instances, but you manage it)	Your VPC, security groups, any protocol	Per instance-second, plus EBS, IPv4 and data transfer; Savings Plans and Spot	Legacy or lift-and-shift software, GPUs, OS tuning, steady workloads
Lightsail	Fixed bundles, simplified resource model	Manual (container service scale value)	No	Lightsail network, peering to a VPC	Flat monthly bundle price with an included data-transfer allowance	Small sites, prototypes, learning, predictable bills
Elastic Beanstalk	Managed platform over EC2 with tunable underlying resources	Auto Scaling group managed by the environment	No	Your VPC, load balancer created for the environment	No Beanstalk charge, you pay for the EC2, load balancer and other resources	An existing Beanstalk workload or a simple instance-based web app
ECS Express Mode	Image, port, CPU and memory; resources adoptable later	Target tracking on CPU, memory or request count, between minimum and maximum tasks	No (minimum task count stays running)	Fargate in your VPC behind a shared ALB, HTTPS URL	No Express charge, you pay for Fargate, ALB and other created resources	A new HTTP service and the fastest path to production; App Runner migration target
ECS on Fargate	Task definitions, services, deployment strategies, sidecars	Application Auto Scaling (target tracking, step, scheduled)	No (minimum can be 0 tasks, you scale back up yourself)	`awsvpc` task ENIs, ALB, NLB, Service Connect	Per vCPU-second and GB-second of task runtime, with Fargate Spot and Savings Plans	Containers needing custom networking, multiple containers per task, advanced deployments
ECS on EC2 and Managed Instances	Instance type choice; Managed Instances patched by AWS	Capacity providers scale instances and tasks	No	`awsvpc` or bridge networking, same load balancers	Instance pricing, no extra charge for the ECS control plane (Managed Instances adds a management fee)	GPUs, high memory, dense packing, steady cost-optimised fleets
Lambda	Function code, memory, timeout; no OS access	Automatic per-request concurrency scaling	Yes	Outside a VPC by default, optional VPC attachment	Per request and per GB-second of duration, plus provisioned concurrency if used	Event-driven or spiky workloads, glue code, short HTTP handlers
Lambda Managed Instances	Lambda programming model on EC2 capacity in your account	Scales on instance capacity and multi-concurrency	No	Your VPC	EC2 instance pricing plus a management fee and request charges	High, steady throughput functions that benefit from EC2 pricing options
EKS (Auto Mode)	Kubernetes API, CRDs, operators; AWS manages nodes in Auto Mode	HPA, KEDA, Karpenter-style node provisioning	No (a cluster has a control-plane charge)	VPC CNI pod networking, Gateway API or ingress through the Load Balancer Controller	Control-plane hourly charge plus node compute (Auto Mode adds a management fee); extended-support fees on old versions	Kubernetes skills or portability needs, large multi-team platforms
App Runner (closed to new customers)	Image or source, minimal settings	Automatic by concurrency	Pausing to a provisioned-instance baseline	Managed endpoint, optional VPC connector	Per active and provisioned instance resource-second	Existing services only; migrate to ECS Express Mode

EC2 and Auto Scaling

Full OS and instance control

Auto Scaling groups with target-tracking, step and scheduled policies

No (an ASG can be set to 0 instances, but you manage it)

Your VPC, security groups, any protocol

Per instance-second, plus EBS, IPv4 and data transfer; Savings Plans and Spot

Legacy or lift-and-shift software, GPUs, OS tuning, steady workloads

Lightsail

Fixed bundles, simplified resource model

Manual (container service scale value)

Lightsail network, peering to a VPC

Flat monthly bundle price with an included data-transfer allowance

Small sites, prototypes, learning, predictable bills

Elastic Beanstalk

Managed platform over EC2 with tunable underlying resources

Auto Scaling group managed by the environment

Your VPC, load balancer created for the environment

No Beanstalk charge, you pay for the EC2, load balancer and other resources

An existing Beanstalk workload or a simple instance-based web app

ECS Express Mode

Image, port, CPU and memory; resources adoptable later

Target tracking on CPU, memory or request count, between minimum and maximum tasks

No (minimum task count stays running)

Fargate in your VPC behind a shared ALB, HTTPS URL

No Express charge, you pay for Fargate, ALB and other created resources

A new HTTP service and the fastest path to production; App Runner migration target

ECS on Fargate

Task definitions, services, deployment strategies, sidecars

Application Auto Scaling (target tracking, step, scheduled)

No (minimum can be 0 tasks, you scale back up yourself)

awsvpc task ENIs, ALB, NLB, Service Connect

Per vCPU-second and GB-second of task runtime, with Fargate Spot and Savings Plans

Containers needing custom networking, multiple containers per task, advanced deployments

ECS on EC2 and Managed Instances

Instance type choice; Managed Instances patched by AWS

Capacity providers scale instances and tasks

awsvpc or bridge networking, same load balancers

Instance pricing, no extra charge for the ECS control plane (Managed Instances adds a management fee)

GPUs, high memory, dense packing, steady cost-optimised fleets

Lambda

Function code, memory, timeout; no OS access

Automatic per-request concurrency scaling

Yes

Outside a VPC by default, optional VPC attachment

Per request and per GB-second of duration, plus provisioned concurrency if used

Event-driven or spiky workloads, glue code, short HTTP handlers

Lambda Managed Instances

Lambda programming model on EC2 capacity in your account

Scales on instance capacity and multi-concurrency

Your VPC

EC2 instance pricing plus a management fee and request charges

High, steady throughput functions that benefit from EC2 pricing options

EKS (Auto Mode)

Kubernetes API, CRDs, operators; AWS manages nodes in Auto Mode

HPA, KEDA, Karpenter-style node provisioning

No (a cluster has a control-plane charge)

VPC CNI pod networking, Gateway API or ingress through the Load Balancer Controller

Control-plane hourly charge plus node compute (Auto Mode adds a management fee); extended-support fees on old versions

Kubernetes skills or portability needs, large multi-team platforms

App Runner (closed to new customers)

Image or source, minimal settings

Automatic by concurrency

Pausing to a provisioned-instance baseline

Managed endpoint, optional VPC connector

Per active and provisioned instance resource-second

Existing services only; migrate to ECS Express Mode

References: Amazon ECS pricing, AWS Fargate pricing, AWS Lambda pricing, Amazon EKS pricing, Amazon EC2 pricing, Amazon Lightsail pricing.

Where Bookshelf lands

The Bookshelf services pick different options because their shapes differ:

Service Chosen option Why

Service	Chosen option	Why
Static web front end	S3 behind CloudFront (not compute)	No server needed; see S3 security and static hosting and CloudFront
`catalog-api` (Spring Boot)	ECS Express Mode first, then a full ECS service on Fargate behind ALB `alb-bookshelf`	Container image, HTTP, needs a managed load balancer; graduates to full ECS when it needs custom networking and deployment control
`orders-api`	ECS on Fargate	Same platform as `catalog-api`, so deployment tooling and observability are shared
`notifier`	Lambda triggered by SQS	Spiky, event-driven, idle most of the time, scale to zero
`thumbnailer`	Lambda triggered by S3 events	Short, bursty image processing per upload

Static web front end

S3 behind CloudFront (not compute)

No server needed; see S3 security and static hosting and CloudFront

catalog-api (Spring Boot)

ECS Express Mode first, then a full ECS service on Fargate behind ALB alb-bookshelf

Container image, HTTP, needs a managed load balancer; graduates to full ECS when it needs custom networking and deployment control

orders-api

ECS on Fargate

Same platform as catalog-api, so deployment tooling and observability are shared

notifier

Lambda triggered by SQS

Spiky, event-driven, idle most of the time, scale to zero

thumbnailer

Lambda triggered by S3 events

Short, bursty image processing per upload

A team that already runs Kubernetes would place catalog-api and orders-api on EKS instead; the EKS microservices page includes an ECS versus EKS decision table. Equivalent guidance for running container images on this site’s other material is in Docker orchestration with Swarm and Kubernetes.

Limits, recent changes and outdated guidance

Each option has its own quotas (EC2 vCPU quotas per instance family, Fargate task counts, Lambda concurrency, EKS cluster and node limits) that start low on new accounts and are raised through the Service Quotas console or aws service-quotas request-service-quota-increase. Recent changes that affect the choice: ECS Express Mode (2025-11), ECS built-in blue/green (2025-07) and linear/canary (2025-10), the App Runner closure (2026-04-30), the Copilot CLI end of support (2026-06-12) and Amazon Linux 2 end of support (2026-06-30). Older guides that call App Runner "the simplest way to run containers", build ECS clusters by hand on EC2 or start from Copilot are outdated: the current approach is ECS Express Mode for the simple case and CloudFormation, CDK or SAM for repeatable stacks.

References: Service Quotas User Guide, aws service-quotas request-service-quota-increase.

Clean up

Delete what the examples above created, in dependency order, to stop charges:

# Express Mode service (also removes the resources it created for the service)
aws ecs delete-express-gateway-service --service-arn <service-arn>

# Lightsail container service
aws lightsail delete-container-service --service-name bookshelf-lite

# Elastic Beanstalk environment (from the EB CLI project directory)
eb terminate bookshelf-beanstalk-env

References: aws ecs delete-express-gateway-service, aws lightsail delete-container-service, eb terminate.