Amazon ECS Fargate vs. EC2: How to Choose a Capacity Model
Published on · Updated on
Reframed the choice around ECS capacity providers, corrected scaling and task-feature claims, and updated billing and purchase options.
For Amazon ECS, choose Fargate when you want AWS to manage the compute capacity for each task; choose EC2 when your tasks need instance-level control or features such as GPUs. Either option can scale the number of service tasks. With EC2, you also plan and operate the instance fleet, although an Auto Scaling group capacity provider can manage much of its scaling.
This guide compares Fargate with customer-managed EC2 capacity for ECS. ECS also offers Amazon ECS Managed Instances, a separate EC2-based capacity option where AWS manages more of the instance operations.
Fargate and EC2 at a glance
| Decision area | Fargate | Customer-managed EC2 |
|---|---|---|
| Compute operations | AWS manages the infrastructure that runs each task. | You select, configure, patch, and maintain the ECS container instances. |
| Task scaling | ECS service auto scaling changes the desired task count; Fargate supplies task capacity. | ECS service auto scaling changes the desired task count. An EC2 capacity provider can also scale its Auto Scaling group. |
| Host and placement control | Task-level CPU and memory choices from supported configurations; no host access or EC2 placement rules. | Choose instance types and operating system, and configure host-level settings and task placement. |
| Special hardware | GPU task requirements are not supported. | ECS can place GPU tasks on supported EC2 GPU instances. |
| Billing basis | Task vCPU, memory, operating system, architecture, and extra ephemeral storage; other services are billed separately. | EC2 instances and associated resources, including capacity that is running but not filled by tasks. |
| Typical fit | Teams prioritizing less host work and task-sized capacity. | Teams needing host or hardware control, or willing to manage a fleet to improve workload fit and utilization. |
There is no universal cost winner. Compare the same application workload, required availability, task sizes, idle capacity, data transfer, storage, and operating effort before committing to either model.
Amazon ECS on AWS Fargate
Fargate is a serverless compute engine for Amazon ECS. You define each task's CPU and memory in the task definition, and AWS provisions the infrastructure that runs it. You still manage the application, task definition, IAM permissions, VPC networking, logs, and service scaling.
When Fargate fits
- You want to run ECS tasks without provisioning or maintaining EC2 hosts.
- Your workload fits Fargate's supported CPU and memory combinations and platform features.
- Task-level capacity is convenient for services that change size or for standalone and scheduled tasks.
- You prefer AWS-managed compute isolation and do not need access to the host operating system.
Fargate supports Linux on x86-64 and Arm64, as well as specified Windows Server versions on x86-64. It is not limited to Linux. Check AWS's current Fargate task-definition requirements for valid CPU and memory combinations and platform details.
Fargate constraints
Fargate supports a defined set of task configurations. ECS tasks on Fargate always use awsvpc networking and do not support GPU requirements, privileged containers, host networking, task placement constraints, or the daemon service scheduling strategy. If your workload depends on one of those features or on host-level agents or configuration, check the task-definition limits before choosing Fargate.
Task count does not automatically change just because Fargate is serverless. To add or remove ECS service tasks in response to demand, configure ECS service auto scaling through Application Auto Scaling. The same service-level scaling feature works with EC2 capacity.
Amazon ECS tasks on EC2
With EC2 capacity, tasks run on EC2 container instances registered to your ECS cluster. Your team controls the instance types, AMIs, host configuration, and fleet lifecycle. You are responsible for maintaining and securing the container instances and ECS agent. AWS documents this responsibility in its guide to EC2 container instances for ECS.
What EC2 adds
- Hardware and host choice: Select instance families and operating systems that match CPU, memory, storage, network, or GPU requirements.
- Placement control: Use task placement strategies and constraints to distribute or pack tasks and target eligible instances.
- More task-definition options: EC2 supports features that Fargate excludes, including GPU requirements, privileged containers, host networking, and daemon services, subject to ECS and instance requirements.
- Pricing options: Compare On-Demand with Spot, and consider Savings Plans or eligible Reserved Instances for covered EC2 usage.
For GPU tasks, AWS documents supported instance types and setup in its ECS GPU task guide. For custom placement, see how ECS places tasks.
EC2 operating responsibilities
EC2 gives you more control, but the team must keep enough compatible instances available and handle host updates, security, monitoring, and replacement. An ECS Auto Scaling group capacity provider can add instances when tasks need capacity and scale the group in when capacity is underused. Its managed scaling behavior reduces fleet-sizing work; it does not transfer host maintenance to AWS.
Security and isolation
Each Fargate task runs in an isolated, hardware-virtualized environment, and AWS manages and patches its compute infrastructure. On EC2, multiple tasks can share an instance's operating system and kernel, so your team manages host security. In either model, you manage task IAM permissions, application security, network rules, and data protection. ECS supports task-level security groups with awsvpc networking on both Fargate and EC2; see AWS's shared-responsibility guidance and network security guidance.
Launch types and capacity providers
ECS still supports the EC2 and FARGATE launch types. AWS recommends using launch type compatibility in a task definition to state where it can run, then using a capacity provider strategy to select capacity for tasks and services. The built-in Fargate providers are FARGATE and FARGATE_SPOT; EC2 capacity providers are associated with Auto Scaling groups. Read AWS's launch type and capacity provider comparison before configuring a new service.
Fargate Spot uses spare Fargate capacity for interruption-tolerant Linux tasks and can interrupt tasks with a two-minute warning, as described in AWS's Fargate capacity-provider guide. An EC2 Spot capacity provider is a separate option with EC2 instance capacity and its own interruption behavior. Neither Spot option is appropriate for tasks that cannot tolerate interruption.
Scaling and task placement
Fixed launch-time claims such as “Fargate starts in 30 seconds” or “EC2 takes three minutes” do not apply to every task. Image size, initialization, platform, capacity availability, and configuration affect startup. Measure startup for the actual service if it is a decision factor.
For both compute choices, ECS service auto scaling adjusts the service's desired task count based on a metric and policy you configure. With Fargate, you do not operate an instance fleet. With an EC2 Auto Scaling group capacity provider, ECS can also manage scaling of the instance group so it has capacity for tasks. EC2 exposes placement strategies and constraints; Fargate chooses placement across accessible Availability Zones without those custom placement controls.
Cost comparison
Fargate charges for the task vCPU, memory, operating system, CPU architecture, and any configured extra ephemeral storage, for the time the task runs. Billing is per second with a one-minute minimum for Linux and a five-minute minimum for Windows. The charge starts when the task begins downloading its image. Review the current AWS Fargate pricing details for the supported configuration and current regional rates.
With EC2, you pay for each running instance, whether all of its CPU and memory are occupied by ECS tasks or not, plus relevant storage, networking, and other service charges. On-Demand EC2 has a 60-second minimum and then per-second billing for many operating systems; check the current EC2 On-Demand billing rules. Instance packing and a stable workload can make EC2 economics attractive, while unused capacity and host operations add to its total cost. Measure utilization instead of assuming a break-even point.
Compute Savings Plans can apply to both EC2 and Fargate usage. EC2 also has EC2 Instance Savings Plans and Reserved Instances; Fargate does not use Reserved Instances. Fargate Spot is another option for interruptible Linux ECS tasks. Compare eligible purchase options against expected usage in the current AWS Savings Plans guidance.
Which compute model should you choose?
Consider EC2 capacity when
- The task needs GPUs, custom host settings, host-based agents, daemon services, or placement controls unavailable on Fargate.
- You need to select particular instance families or tune the fleet for specific hardware and storage needs.
- Your workload uses enough steady capacity that instance utilization and purchase options merit operating the fleet.
- Your team can own host patching, security, capacity planning, and ECS agent maintenance.
Consider Fargate when
- You want ECS to run tasks without your team maintaining EC2 hosts.
- Tasks fit Fargate's supported configurations and do not need host-specific features.
- You value task-sized compute for variable demand, short-lived tasks, or services with different resource needs.
- You want AWS to manage the infrastructure isolation and patching for task compute.
For either choice, estimate the full monthly bill with the same workload pattern, include task or instance idle time, and test service performance at expected peaks. Track service CPU and memory before and after the decision; our guide to ECS Fargate metrics in CloudWatch explains the service metrics and task-level detail available. If you choose EC2, our EC2 right-sizing guide covers workload-based capacity and cost measurement.