AWS Fargate Linux Platform Version 1.3 Retirement Before June 30, — when and how should I migrate?
Teams pinned to Fargate Linux platform version 1.3.0 need to decide whether to move to an explicit supported platform version or switch to the `LATEST` alias before AWS ends support on June 30, 2026.
Blockers
- runtime/fargate-linux-platform-1-3-0 — EOL 2026-06-30
- runtime/fargate-linux-platform-1-3-0 — EOL 2026-06-15
- AWS documents a networking behavior change in 1.4.0: all traffic uses a single task ENI and becomes visible in VPC Flow Logs.
- AWS states that, as of 2026-04-09, the LATEST Linux Fargate platform version is 1.4.0.
- Services using LATEST avoid staying pinned to retired 1.3.0; as of 2026-04-09, LATEST is 1.4.0.
Who this is for
- serverless
- low-ops
- cost-sensitive
- enterprise
Candidates
Migrate now to explicit Linux platform version 1.4.0
AWS states that Fargate Linux platform version 1.3.0 will be marked retired on June 15, 2026, and all remaining running 1.3.0 tasks will be terminated on June 30, 2026. AWS also states that the LATEST Linux Fargate platform version is 1.4.0. As of 2026-04-09, the AWS Fargate pricing page prices usage by requested vCPU, memory, operating system, CPU architecture, and storage resources, without listing a separate platform-version surcharge.
When to choose
Use this when you need a controlled migration window and want deterministic behavior across environments before the June 15, 2026 retirement gate. It is the safest choice for regulated or change-managed teams because you can test 1.4.0 explicitly, redeploy on your schedule, and avoid later surprises from the LATEST alias moving again.
Tradeoffs
This removes the retirement risk without introducing future alias drift, but it keeps you responsible for choosing when to adopt later platform-version changes. You also need a rollout plan for redeploying existing services and standalone tasks.
Cautions
AWS documents a networking behavior change in 1.4.0: all traffic uses a single task ENI and becomes visible in VPC Flow Logs. If you use interface VPC endpoints, AWS says you may need ECR `ecr.dkr`, ECR `ecr.api`, S3 gateway, Secrets Manager, or Systems Manager endpoints plus matching security-group rules. If you increase ephemeral storage above the default, storage is a billed pricing dimension.
Move to LATEST after validation and stop pinning 1.3.0
AWS documents that services using the `LATEST` platform version are force-updated when that alias points to a version scheduled for deprecation, while services with an explicit platform version are not. AWS also states that, as of 2026-04-09, the LATEST Linux Fargate platform version is 1.4.0. As of 2026-04-09, the AWS Fargate pricing page prices usage by requested vCPU, memory, operating system, CPU architecture, and storage resources rather than by a separate platform-version rate.
When to choose
Use this when low-ops matters more than strict platform pinning and you are comfortable with AWS moving the LATEST alias to newer revisions or versions later. It is a reasonable choice for small platform teams that want to eliminate repeat migration work after validating their workload on today's LATEST.
Tradeoffs
This cuts operational overhead and avoids staying stuck on a retired explicit pin, but it reduces change control because future LATEST changes are not date-pinned by you. Troubleshooting can also be harder if environments roll forward at different times due to deployment timing.
Cautions
Do not treat `LATEST` as a permanent synonym for 1.4.0; AWS only documents that, as of 2026-04-09, LATEST is 1.4.0. You still need to validate the 1.4.0 networking changes and any VPC endpoint dependencies before switching. Standalone tasks will not automatically move just because services are updated.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "AWS Fargate Linux Platform Version 1.3 Retirement Before June 30, — when and how should I migrate?"