Amazon ECS with AWS Fargate Now Supports 32 vCPU Compute Configurations
A practical guide to AWS Fargate's new 32 vCPU support — covering real-world use cases, step-by-step configuration, cost optimization strategies, and when EC2 is still the better choice.
Introduction
On June 5, 2026, AWS announced that Amazon ECS with AWS Fargate now supports a new compute configuration: 32 vCPU tasks.
Until now, Fargate task sizes had an upper limit, and teams running large-scale AI inference, ETL pipelines, or HPC (high-performance computing) workloads often had no choice but to fall back to the EC2 launch type. That meant giving up the operational benefits of serverless just to get enough compute and memory headroom. This update directly addresses that trade-off.
This article walks through what changed, where the new configuration fits, how to set it up, how to think about cost, and when EC2 is still the better choice. It's written for infrastructure engineers and SREs running ECS or Fargate in production, but should also be useful for engineering managers evaluating compute options.
What Changed
If you've ever tried to run a compute-intensive workload on ECS, you've probably hit the wall of "I want to use Fargate, but I don't have enough vCPU." Here's exactly what this update changes.
| Item | Before | After |
|---|---|---|
| Maximum vCPU | 16 vCPU | 32 vCPU |
| Maximum memory | 120 GiB | 244 GiB (choose from 60, 120, or 244 GiB) |
| Supported architectures | x86 / ARM (Linux) | Unchanged (x86 and ARM both supported) |
| Supported capacity providers | Fargate / Fargate Spot | Unchanged (32 vCPU available on both) |
| Supported Regions | All commercial Regions / AWS GovCloud (US) | Unchanged |
The Previous Limitation
Fargate task sizes have grown incrementally over the years, but until this update, the ceiling was 16 vCPU and a maximum of 120 GiB of memory. That's plenty for most general-purpose workloads, but a few common scenarios consistently ran into it:
- CPU-based inference for large language models (LLMs), where the memory footprint of the model alone could exceed the task size limit
- Distributed processing frameworks like Apache Spark or Apache Flink, where teams wanted to run a single, larger task rather than splitting work across many smaller ones
- Genomics pipelines and similar scientific computing workloads that need a large burst of CPU and memory for a short period of time
Teams that hit this ceiling were left with two options: add complexity by spreading the workload across multiple tasks, or move to the EC2 launch type.
How 32 vCPU Support Solves This
With this update, 32 vCPU is now a valid task size on Fargate. Memory can be set to 60 GiB, 120 GiB, or 244 GiB, and the new configuration is available on both x86 and ARM (AWS Graviton).
Setting it up is straightforward: specify
32768 as the cpu value in your task definition (equivalent to 32 vCPU), and choose one of 60 GiB, 120 GiB, or 244 GiB for memory. Your existing deployment workflow — console, CLI, or infrastructure as code — works without modification. The only prerequisite is Linux platform version 1.4.0 or later. We'll walk through the exact configuration later in this article.Where This Update Fits In
This isn't the first time Fargate's compute limits have been expanded. Back in September 2022, AWS raised the ceiling from 4 vCPU / 30 GiB to 16 vCPU / 120 GiB — roughly a 4x increase. The 32 vCPU update continues that same trajectory.
Use Cases
Let's look at four concrete scenarios where 32 vCPU tasks make a difference.
CPU-Based AI Inference
Since the generative AI boom, there's been growing demand for running LLM inference on CPU rather than GPU. CPU inference engines like
llama.cpp, and applications built around RAG (retrieval-augmented generation) pipelines, don't necessarily require a GPU at all. What they do require is memory — loading even a moderately sized model into memory can easily require tens of gigabytes.With 32 vCPU and up to 244 GiB of memory, you can serve reasonably large models with high throughput, entirely serverless, without provisioning a GPU instance. Combine this with task-count scaling based on request volume, and the inference layer stays operationally simple.
Large-Scale Data Processing and ETL
Frameworks like Apache Spark and Apache Flink are designed around distributing work across many nodes. But when the dataset isn't enormous, or when you need a job to finish quickly, running it as a single, large task is often simpler and faster than standing up a distributed cluster.
This kind of workload used to bump into Fargate's task size limits. With 32 vCPU, you can run large data transformation and aggregation jobs as a single task. Once the job finishes, the task — and its resources — are released automatically.
HPC and Scientific Computing
Genomics pipelines (using tools like GATK) and simulation workloads are classic examples of HPC: they need a large burst of CPU and memory, but only occasionally. Previously, this meant relying on high-spec EC2 instances or on-premises compute.
That "idle most of the time, resource-hungry when running" pattern is a natural fit for serverless, pay-as-you-go pricing. With 32 vCPU support, you can provision large amounts of compute on demand, run the job, and release the resources immediately afterward — without managing any infrastructure.
Massively Parallel Processing and Batch Jobs
CPU-bound parallel workloads — large-scale web crawling, bulk file compression, or format conversion across many files — also benefit from the larger task size.
Previously, scaling this kind of work meant splitting it across many smaller tasks running in parallel. With more vCPU available per task, you can complete the same amount of work with fewer tasks, reducing the coordination overhead (inter-task communication, result aggregation) that comes with distributed execution.
Implementation
Adopting 32 vCPU tasks is a matter of changing resource values in your existing task definition. No new parameters or syntax are introduced.
Prerequisites
| Item | Value |
|---|---|
| cpu value | 32768 (32 vCPU) |
| memory value | One of 61440 (60 GiB), 122880 (120 GiB), or 249856 (244 GiB) |
| Linux platform version | 1.4.0 or later |
| Supported capacity providers | FARGATE / FARGATE_SPOT |
| Supported architectures | X86_64 / ARM64 |
Note that, unlike the lower vCPU tiers, memory at 32 vCPU isn't a free-form range — you must pick one of the three fixed values.
Configuring the Task Definition
Set
cpu and memory in your task definition as follows.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
{
"family": "large-workload-task",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "32768",
"memory": "61440",
"executionRoleArn": "arn:aws:iam::<your-account-id>:role/ecsTaskExecutionRole",
"runtimePlatform": {
"cpuArchitecture": "X86_64",
"operatingSystemFamily": "LINUX"
},
"containerDefinitions": [
{
"name": "app",
"image": "<your-image-uri>",
"essential": true,
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/large-workload-task",
"awslogs-region": "<your-region>",
"awslogs-stream-prefix": "ecs"
}
}
}
]
}
To run on AWS Graviton, change
cpuArchitecture to ARM64. Make sure your container image actually supports ARM64 — a multi-architecture image is the safest bet here.Deploying with the AWS CLI
Save the task definition as a JSON file and register it with
register-task-definition, the same way you always have.1
2
aws ecs register-task-definition \
--cli-input-json file://task-definition.json
The deployment flow itself doesn't change — you can roll out the new task definition revision with a standard
update-service call.Deploying with IaC (Terraform Example)
If you manage infrastructure with Terraform, the change is just as minimal.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
resource "aws_ecs_task_definition" "large_workload" {
family = "large-workload-task"
network_mode = "awsvpc"
requires_compatibilities = ["FARGATE"]
cpu = 32768
memory = 61440
execution_role_arn = aws_iam_role.ecs_task_execution.arn
runtime_platform {
cpu_architecture = "X86_64"
operating_system_family = "LINUX"
}
container_definitions = jsonencode([
{
name = "app"
image = "<your-image-uri>"
essential = true
}
])
}
Things to Watch Out For
If your service pins an older Linux platform version (for example,
1.3.0), update it to 1.4.0 or later. Note that platform version isn't part of the task definition itself — it's specified when you call RunTask or create/update a service. If you try to deploy a 32 vCPU task definition to a service still pinned to an older platform version, the error will surface at that point, not when you register the task definition.Also keep in mind that 32 vCPU tasks cost proportionally more. It's worth pairing this rollout with the cost optimization approaches covered next.
Cost Optimization
A 32 vCPU / up to 244 GiB configuration comes with a correspondingly larger price tag. Here's how to keep costs under control when adopting it.
Combining with Fargate Spot
Fargate Spot offers up to a 70% discount over standard Fargate pricing. Since this update makes 32 vCPU available on both Fargate and Fargate Spot, interruption-tolerant workloads can take advantage of that discount immediately.
This is a strong fit for batch jobs, ETL pipelines, and retryable AI inference tasks — anything that can be safely restarted if interrupted. It's not a good fit for always-on services or latency-sensitive workloads where interruptions would directly affect users, so choose based on the nature of the workload.
Running on Graviton (ARM)
AWS states that running Fargate tasks on Graviton-based ARM architecture delivers up to 40% better price-performance at roughly 20% lower cost compared to x86. Since the 32 vCPU configuration supports both architectures, you get this benefit simply by setting
cpuArchitecture to ARM64 — as long as your container image supports it.Be aware that base images without ARM64 support, or applications that depend on x86-specific native libraries, may not run as-is. Build a multi-architecture image ahead of time, or validate the migration in a test environment first.
Applying a Compute Savings Plan
If you run Fargate continuously, a Compute Savings Plan is worth considering — committing to one or three years of usage gets you up to 50% off Fargate costs. Importantly, existing Compute Savings Plans apply automatically to 32 vCPU usage. There's no need to set up a new commitment or change your existing plan to take advantage of the discount.
Combination Strategy
The right combination depends on the nature of the workload.
| Workload characteristics | Recommended combination |
|---|---|
| Interruption-tolerant batch jobs / ETL | Fargate Spot + Graviton |
| Always-on production services | Compute Savings Plan + Graviton |
| Testing / occasional load testing | Fargate Spot (on-demand, one-off runs) |
Graviton (ARM) is a viable option whenever your application supports it, regardless of which other strategy you choose. Use Fargate Spot for workloads that can tolerate interruption, and a Compute Savings Plan for workloads that need to run continuously — that distinction is a good starting point for deciding which to use.
EC2 vs. Fargate: When to Choose Which
32 vCPU support expands what Fargate can handle, but it doesn't make Fargate a universal replacement for the EC2 launch type. Here's when EC2 is still the right call.
When You Still Need EC2
If your workload needs more than 32 vCPU, EC2 is still required. The EC2 launch type supports task CPU values from 0.25 vCPU up to 192 vCPU — 32 vCPU is a Fargate-specific ceiling, not a platform-wide one.
GPU workloads also require EC2. Fargate container definitions don't support the
gpu parameter, so any machine learning training or inference workload that needs a GPU has to run on a GPU-enabled EC2 instance type.The same applies if you need privileged containers or direct access to host devices. Fargate doesn't support the
privileged parameter, which grants root-equivalent access to the host, or the devices parameter, which exposes host devices directly to a container. Additional Linux capabilities like CAP_SYS_ADMIN and CAP_NET_ADMIN are also restricted to prevent privilege escalation. If your workload needs to interact with kernel modules or do anything else at the host level, EC2 is the appropriate launch type.Finally, if you need to tune for a specific instance type's characteristics — high network bandwidth, local NVMe storage, a particular CPU generation — EC2 gives you that flexibility directly.
When Fargate Is the Right Choice
On the other hand, Fargate (including the 32 vCPU configuration) is a good fit when your resource needs fit within 32 vCPU / 244 GiB and you want to avoid managing servers, when workloads run infrequently or in bursts and you don't want to pay for idle instances, or when you simply want to minimize the operational overhead of patching and scaling infrastructure.
A Quick Comparison
| Dimension | Fargate (32 vCPU configuration) | EC2 launch type |
|---|---|---|
| Maximum vCPU | 32 vCPU | 192 vCPU |
| GPU support | Not supported | Supported (GPU instances) |
| Privileged containers | Not supported | Supported |
| Direct host device access | Not supported | Supported |
| Instance management | Not required (serverless) | Required (patching, scaling, etc.) |
| Launch flexibility | Tasks start and stop independently | Requires an instance to be running |
In most cases, two questions are enough to decide: does 32 vCPU cover your resource needs, and do you need GPU or privileged mode?
Best Practices
A few things worth keeping in mind once you're running 32 vCPU tasks in production.
Choosing a Memory Tier (60 / 120 / 244 GiB)
Unlike the lower vCPU tiers, 32 vCPU doesn't let you pick memory freely within a range — you choose from three fixed values: 60 GiB, 120 GiB, or 244 GiB. Because you can't fine-tune the amount, this choice has a direct impact on cost.
As a rough guide: choose 60 GiB for CPU-bound workloads with relatively modest memory needs, such as video transcoding or lightweight batch jobs. Choose 120 GiB for workloads that need a more balanced mix of CPU and memory, such as mid-sized data processing. Choose 244 GiB when memory is the bottleneck — for example, CPU inference for a large LLM loaded entirely into memory, or analytics workloads that need an entire dataset resident in memory.
Because the options are fixed, you'll sometimes end up over-provisioning — needing, say, 80 GiB but having to choose 120 GiB. Monitor actual utilization and adjust as needed to avoid paying for memory you don't use.
Monitoring with Container Insights
Whether your CPU and memory choices are actually appropriate often only becomes clear once the workload is running in production. Enable Container Insights to track task-level resource utilization over time. If memory usage consistently sits near the ceiling of your chosen tier, consider moving up a tier; if there's significant headroom, consider stepping down to reduce cost.
Combining with Auto Scaling
32 vCPU gives you a way to scale up — running a single, larger task — but it doesn't replace scaling out to handle variable traffic. For workloads with fluctuating request volume or load, continue to pair 32 vCPU tasks with Service Auto Scaling, adjusting the number of tasks dynamically as needed. Relying too heavily on a single large task also increases the blast radius if that task fails.
Conclusion
With support for 32 vCPU and up to 244 GiB of memory, Amazon ECS with AWS Fargate can now handle a much wider range of AI inference, large-scale data processing, and HPC workloads without leaving the serverless model. Existing cost optimization tools — Fargate Spot, Graviton, and Compute Savings Plans — all carry over to this new configuration. That said, EC2 is still the right choice for workloads that exceed 32 vCPU, or that need GPU access or privileged containers.
If your team has workloads currently running on EC2 specifically because they outgrew Fargate's previous limits, it's worth checking whether they now fit within 32 vCPU and 244 GiB and revisiting whether they could move back to Fargate. Since the change is limited to the
cpu and memory values in your task definition, testing it out is low-effort.References
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article