Expand Fargate Ephemeral Storage Beyond the 20GB Default (2026)

Fargate tasks can use more than the default 20GB of ephemeral storage, and it’s surprisingly easy to configure.

Let’s see it in action. Imagine you have a containerized application that processes large files and needs more than 20GB to temporarily store these files during processing. Without increasing the default, your task might fail with a disk full error.

Here’s a simple Fargate task definition snippet demonstrating how to request more ephemeral storage:

{
  "family": "my-app-task",
  "networkMode": "awsvpc",
  "requiresCompatibilities": [
    "FARGATE"
  ],
  "cpu": "1024",
  "memory": "2048",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "my-processing-container",
      "image": "my-repo/my-processing-image:latest",
      "essential": true,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-app",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      },
      "environment": [],
      "mountPoints": [],
      "volumesFrom": []
    }
  ],
  "ephemeralStorage": {
    "sizeInGiB": 50
  }
}

Notice the "ephemeralStorage": { "sizeInGiB": 50 } block. This is where you explicitly tell Fargate to allocate 50 GiB of ephemeral storage to this task, overriding the default 20 GiB. When Fargate launches this task, it will provision a 50 GiB overlayfs for your containers.

The problem this solves is straightforward: many applications, especially those dealing with data processing, caching, or temporary file manipulation, can quickly exceed the default 20 GiB of ephemeral storage provided by Fargate. This leads to application errors, task failures, and potential data loss if not handled. By allowing you to configure this storage size, Fargate provides the flexibility to match your application’s needs without resorting to more complex storage solutions for temporary data.

Internally, Fargate uses an overlayfs for ephemeral storage. When you define ephemeralStorage.sizeInGiB, Fargate provisions a block device of that size and mounts it as the root filesystem for the containers within the task. This means all containers within a task share this ephemeral storage pool. Any files written to / or any path within the container that isn’t a mounted volume will consume this storage.

The exact levers you control are within the task definition itself. You can set ephemeralStorage.sizeInGiB to any value between 20 (the default) and 221 GiB (the maximum supported). The cpu and memory parameters of the task definition also influence the maximum ephemeral storage you can request. For example, a task with 1 CPU and 2GB of memory can request up to 221 GiB, while a task with 4 CPU and 16GB of memory is limited to 100 GiB. Always consult the AWS Fargate documentation for the most up-to-date CPU/memory to ephemeral storage limits.

The surprising part about Fargate ephemeral storage is how it’s managed at the task level and not at the container level. All containers within a single Fargate task share the same ephemeral storage allocation. This means a runaway process in one container can easily consume the storage intended for another, potentially leading to unexpected task failures. It’s crucial to monitor your application’s storage usage and configure your task definitions to accommodate the aggregate needs of all containers, plus a buffer, to prevent such cross-container impact.

The next thing you’ll likely encounter is managing the lifecycle of data within this ephemeral storage, especially for stateful applications.