Why Platform Versions Exist
Fargate is a managed service, which means AWS periodically upgrades the underlying infrastructure. Rather than forcing a breaking change on all customers simultaneously, AWS uses Platform Versions (PV) — versioned snapshots of the Fargate runtime environment. You pin your Task Definition to a specific PV, and AWS guarantees that environment remains stable until you explicitly upgrade.
Think of it like Node.js LTS versions: you choose when to move from Node 16 to Node 18, and each version has a defined set of capabilities and behaviors.
Platform Version 1.3 (Legacy — Avoid)
PV 1.3 was built on the standard Docker Engine and has several hard limitations that make it unsuitable for modern workloads:
- Split storage: 10 GB allocated for Docker image layers, 4 GB for bind mounts. These pools are separate and non-interchangeable. A large image (say, 8 GB) leaves almost no room for runtime data.
- No EFS support: You cannot mount an Elastic File System volume. Persistent shared storage is not possible.
- Limited observability: Task Metadata endpoint is version 3, which exposes less runtime information. CloudWatch Container Insights cannot collect network-level metrics.
- Docker Engine overhead: The Docker daemon is heavier than containerd and introduces additional latency in container startup.
Unless you are maintaining a legacy workload that cannot be migrated, there is no reason to use PV 1.3 today.
Platform Version 1.4 (The Modern Standard)
PV 1.4 was a ground-up architectural rewrite. Key changes:
Runtime: Replaced Docker Engine with containerd — the same lightweight runtime used by Kubernetes. Containerd has a smaller attack surface, lower memory overhead, and faster image pull times.
Storage — Ephemeral:
The split filesystem is gone. PV 1.4 provides a single unified 20 GB ephemeral volume by default. This volume is shared between the container image layers and any runtime writes. You can expand this up to 200 GB by setting ephemeralStorage.sizeInGiB in your Task Definition. This storage is local to the task and is destroyed when the task stops.
Storage — Persistent:
PV 1.4 introduced native Amazon EFS integration. You can mount an EFS file system into your Fargate task, giving you persistent, shared storage that survives task restarts and can be accessed by multiple tasks simultaneously.
Networking:
The Task Metadata endpoint upgrades to version 4, which exposes detailed network statistics (bytes received, bytes transmitted, packet counts) directly to the container via a local HTTP endpoint at 169.254.170.2. This enables CloudWatch Container Insights to collect network metrics that were invisible in PV 1.3.
// Example: Configuring PV 1.4 with expanded ephemeral storage in a Task Definition
{
"family": "video-processor",
"requiresCompatibilities": ["FARGATE"],
"networkMode": "awsvpc",
"cpu": "4096",
"memory": "8192",
"runtimePlatform": {
"operatingSystemFamily": "LINUX"
},
"ephemeralStorage": {
"sizeInGiB": 100
},
"containerDefinitions": [
{
"name": "processor",
"image": "my-account.dkr.ecr.us-east-1.amazonaws.com/video-processor:latest",
"essential": true
}
]
}
Rule of Thumb: Always specify LATEST or explicitly 1.4 in your ECS Service or Task Run configuration. In EKS on Fargate, the platform version is managed automatically by AWS and maps to the Kubernetes version — you don't set it manually.