EC2 is a virtual-server compute service that gives developers persistent, configurable Linux and Windows instances for running applications directly on AWS infrastructure.
Choosing the wrong compute service on AWS produces real costs: over-provisioned EC2 instances billing idle hours, Lambda functions hitting the execution ceiling mid-job, or ECS task definitions misconfigured to run stateless workloads on expensive persistent instances. The decision between EC2, Lambda, and ECS shapes deployment complexity, operational overhead, and cost structure for the life of the application.
The Three AWS Compute Primitives
EC2, Lambda, and ECS represent three distinct deployment models that AWS offers for running application workloads, each optimized for a different operational contract between the developer and the platform. EC2 puts the developer in control of a full virtual machine. Lambda abstracts the server entirely, running discrete functions on demand through a serverless computing model. Amazon ECS handles container orchestration, sitting between the two: it manages Docker containers without requiring the developer to administer the underlying OS, but still exposes more runtime control than serverless computing provides.
The AWS Fargate or Lambda decision guide frames these as points on a spectrum from full control to full abstraction, with the right choice depending on workload duration, statefulness, and team familiarity with container tooling.
| Service | Launch model | Abstraction level | Scaling unit | State persistence |
|---|---|---|---|---|
| EC2 | Persistent virtual machine | OS-level (full control) | Instance | Persistent (EBS volumes survive restarts) |
| Lambda | Event-triggered function | Function runtime only | Concurrent invocation | Stateless by default |
| ECS | Managed container task | Container orchestration layer | Task or service | Configurable per launch type |
How EC2 Works
EC2 (Elastic Compute Cloud) is AWS's original virtual-machine service, providing persistent, configurable instances that run continuously until explicitly stopped. The Amazon EC2 User Guide defines it as on-demand scalable computing capacity in the AWS cloud, with full developer control over security groups, networking configuration, and capacity scaling. EC2 organizes instance types into six categories, general purpose, compute optimized, memory optimized, storage optimized, accelerated computing, and high-performance computing, each matched to specific hardware profiles, as documented in the EC2 instance types reference.
Each instance launches from an Amazon Machine Image (AMI), bundling the operating system, pre-installed software, and configuration into a reusable template. Auto scaling groups adjust fleet size based on demand signals, but the deployment model requires managing patching, OS configuration, and network security groups throughout the instance lifecycle.
EC2 fits workloads that need persistent infrastructure:
- Long-running services: web servers, application servers, and background workers that must stay online continuously benefit from the persistent execution environment EC2 provides.
- Stateful databases: relational databases and caches that write to disk require persistent block storage and predictable memory allocations that EC2 delivers via EBS volumes.
- GPU workloads: machine learning training jobs and rendering pipelines require EC2 GPU instance types from the accelerated computing category, not available in Lambda or standard Fargate task configurations.
- Custom OS or kernel requirements: applications that depend on specific kernel modules, custom networking drivers, or non-standard OS configurations must run on a full EC2 instance where the developer controls the AMI.
How AWS Lambda Works
AWS Lambda is a serverless computing service that runs discrete functions in response to event triggers without requiring developers to provision or manage any underlying infrastructure. Each invocation runs inside an isolated execution environment: a sandbox that loads the function's deployment package, initializes the runtime, and executes the handler. The Lambda runtimes documentation describes how Lambda re-uses an existing execution environment from a prior invocation when one is available, avoiding re-initialization costs. When no warm environment exists, Lambda provisions a new one, producing cold start latency that varies by runtime and function package size.
The hard ceiling for any single AWS Lambda invocation is 15 minutes, as documented in the Lambda quotas reference. The Fargate or Lambda decision guide frames Lambda as designed for short-lived, event-driven tasks that complete well within that window. Workloads that exceed 15 minutes must be decomposed into smaller units or moved to ECS or EC2.
Lambda integrates with AWS services as event sources, including S3, API Gateway, DynamoDB Streams, SQS, and EventBridge. Common Lambda use cases:
- API backends: REST and GraphQL handlers built on API Gateway scale to zero when idle and handle traffic spikes without pre-provisioning.
- Data transformation pipelines: S3-triggered functions that parse, enrich, or route records as files land in a bucket fit the event-driven execution model precisely.
- Scheduled jobs: EventBridge-triggered functions replace cron servers for periodic tasks such as report generation, cache warming, or cleanup routines.
- Event-driven integrations: DynamoDB Streams or SQS consumers that react to data changes without polling loops run efficiently as Lambda functions without a dedicated compute layer.
How Amazon ECS Works
ECS (Elastic Container Service) is a container orchestration service that runs, scales, and manages Docker containers across a cluster using either Fargate (serverless) or EC2 launch types. The Amazon ECS recommendation guide describes it as a fully managed container control plane supporting four deployment options: Fargate, EC2, AWS Outposts, and ECS Anywhere for on-premises nodes. Each container runs as part of a task defined by a task definition, which specifies the container image, CPU and memory allocations, and networking mode.
The Fargate launch type removes the need to provision or manage EC2 instances for the container fleet, as the Fargate or Lambda decision guide confirms. Fargate charges per vCPU and per GB of memory consumed by each task per second; current rates appear on the AWS Fargate pricing page. Amazon ECS itself carries no separate control-plane charge: you pay only for the Fargate compute or EC2 instances your tasks consume, as the ECS pricing page confirms.
ECS suits teams whose workloads are already containerized:
- Containerized microservices: independently deployable services each running in their own Docker container with separate resource allocations, health checks, and rolling deployment policies.
- Batch processing: jobs requiring more than 15 minutes of continuous execution that package cleanly as container images and benefit from Fargate's per-task billing.
- Multi-service applications: stacks where multiple containers communicate over a private service mesh; ECS task definitions support sidecar containers for logging agents and service mesh proxies alongside the primary application container.
- Kubernetes migration path: teams evaluating container orchestration before committing to Amazon EKS can adopt container-native deployment patterns on ECS without the Kubernetes control-plane learning curve.
EC2 vs Lambda vs ECS: Head-to-Head Comparison
EC2 gives developers the most infrastructure control; Lambda trades that control for zero server management; ECS sits between them, adding container orchestration without fully abstracting the compute layer. The table below maps each deployment model across seven dimensions that matter most to application teams.
| Dimension | EC2 | Lambda | ECS |
|---|---|---|---|
| Server management | Full: OS patching, security groups, and networking are developer-managed | None: AWS manages all infrastructure; developer ships function code only | Partial: Fargate removes instance management; EC2 launch type retains it |
| Scaling model | Auto scaling groups add or remove instances based on CloudWatch metrics; scale-out measured in minutes | Automatic per-invocation; scales to account concurrency limit within seconds; scales to zero when idle | Service auto scaling adjusts task count; Fargate provisions capacity per task faster than an EC2 ASG |
| Cold-start latency | None after instance is running; initial boot takes minutes on first launch | Present on first invocation or after idle; varies by runtime and function package size (Lambda runtimes); Provisioned Concurrency eliminates it | Container pull and task startup add latency on first run; subsequent starts faster with cached images |
| State persistence | Persistent: EBS volumes and in-memory state survive across requests | Stateless: execution environment is ephemeral; external storage required for any persistent data | Configurable: Fargate tasks are stateless by default; EC2 launch type supports EFS and EBS mounts |
| Maximum execution duration | Unlimited: instances run until explicitly stopped | 15 minutes per invocation (Lambda quotas) | Unlimited: tasks run until stopped or the container process exits |
| Networking flexibility | Full VPC control: custom subnets, security groups, Elastic IPs, ENIs, placement groups | VPC-attached or public endpoint; limited to function-level networking configuration | awsvpc mode assigns each task a dedicated ENI; full VPC integration without EC2-level complexity |
| Pricing model | Per instance-hour by type and size; Reserved and Savings Plan discounts apply to predictable workloads | Per request plus per-GB-second of execution duration; no charge when idle | No ECS control-plane fee (ECS pricing); pay for Fargate vCPU and memory per second (Fargate pricing) or underlying EC2 instances |
Choosing the Right AWS Compute Service
EC2 is the right choice when your application requires persistent processes, custom OS configuration, or GPU-intensive computation that Lambda and ECS cannot provide. Lambda is the right choice for short, event-driven workloads where operational overhead is a hard constraint. ECS is the right choice when the workload runs in Docker containers and needs to outlast Lambda's execution ceiling or maintain persistent connections.
The Fargate or Lambda decision guide provides a structured comparison of both serverless options against workload duration, container portability, and cold start tolerance. For teams building new serverless architectures, the AWS Well-Architected Framework Serverless Applications Lens provides best-practice guidance for architecting serverless applications on AWS.
Three deployment decision scenarios cover most mid-size application teams:
- Persistent stateful services (use EC2)
- Applications that maintain in-memory state, run background workers continuously, or depend on custom kernel configuration belong on EC2. A legacy monolith, a database on a configuration RDS does not support, or an ML inference server requiring a GPU from the accelerated computing instance category are all EC2 workloads. Infrastructure as code (IaC) tooling manages EC2 provisioning at scale; the infrastructure as code tooling comparison covers the tradeoffs between Terraform, Ansible, and CloudFormation for AWS deployments.
- Event-driven functions (use Lambda)
- Workloads triggered by S3 events, API Gateway requests, SQS messages, or EventBridge schedules are Lambda's native domain. The serverless computing model eliminates patching and capacity planning entirely. Lambda's per-invocation billing suits spiky or unpredictable traffic; a continuously running service on Lambda is almost always more expensive than an equivalent EC2 instance. For auto scaling patterns across AWS services, the load balancing vs auto scaling article covers the relevant tradeoffs.
- Containerized microservices (use ECS)
- Teams that ship Docker containers and need container orchestration, sidecar patterns, or execution durations beyond 15 minutes should use Amazon ECS. Fargate removes the EC2 instance fleet management while preserving container portability and full VPC networking. ECS is the lower-overhead path for teams not ready for Kubernetes. For observability tooling once the deployment model is selected, the monitoring your AWS deployments comparison covers APM options that complement native AWS CloudWatch and X-Ray.
Further reading
Frequently Asked Questions
What is the main difference between EC2 and Lambda?
EC2 provides persistent virtual machines that require you to manage the underlying server, while Lambda executes discrete functions in response to events and scales to zero when idle. EC2 suits long-running stateful services; Lambda suits short-lived event-driven workloads where you want to avoid server management entirely. The 15-minute maximum execution duration per Lambda invocation is the most common hard constraint that drives teams toward EC2 or ECS.
When should I use ECS instead of Lambda?
Use ECS when your workload runs in Docker containers, requires more than 15 minutes of continuous execution, or needs persistent connections that Lambda's stateless model cannot maintain. ECS with Fargate removes the need to provision or manage EC2 instances while preserving container portability, making it a middle path between Lambda's full abstraction and EC2's full control.
Does AWS Lambda have cold start latency?
Yes. Lambda creates a new execution environment when no warm environment is available, adding initialization latency that varies by runtime and function package size. Provisioned Concurrency pre-initializes execution environments to substantially reduce this latency at an additional cost. For latency-sensitive APIs, provisioned concurrency or a container-based ECS deployment is usually preferable.
