AWS is putting a date on something a lot of platform teams felt coming: the AWS Copilot CLI will reach end of support on June 12, 2026. The project stays open source on GitHub, but AWS says it will stop shipping new features and security updates. The practical implication is less about “Copilot disappears tomorrow” and more about risk management: Copilot’s value was that it turned a pile of infrastructure into a repeatable workflow. Losing vendor-backed maintenance turns that workflow into technical debt that grows every month.
If your org uses Copilot as the “easy button” for ECS Fargate/App Runner deployments, you now have to make a decision: adopt what Copilot already built, move to ECS Express Mode, or move to AWS CDK Layer 3 (L3) constructs. AWS’s own guidance frames those three as the lowest-friction options. The nuance is that each option changes a different part of the contract between application teams and the platform.
What Copilot really provided (and what you’ll miss when it’s frozen)
Copilot was never “just a CLI.” It was an opinionated product surface: service types, a manifest format, environment scaffolding, and a predictable mapping to CloudFormation stacks. For many teams, Copilot wasn’t the ultimate IaC solution; it was a boundary. App teams stayed productive inside the boundary (service definitions, env vars, secrets, scaling), while platform teams could still reason about the underlying AWS resources when something went sideways.
The end-of-support announcement forces a re-evaluation of that boundary. When a tool no longer gets security updates, you’re effectively committing to one of two stances:
- Freeze and own it: you keep using Copilot as-is and accept you now own upgrades, security posture, and any ecosystem drift.
- Transition the boundary: you migrate the workflow to a supported layer and redefine what “application teams manage” vs. what “the platform manages.”
Migration option 1: “Adopt” Copilot’s CloudFormation (least change, most responsibility)
AWS points out that Copilot generates standard CloudFormation templates and stacks. That’s both reassuring and dangerous. Reassuring, because you’re not trapped in a proprietary, unreadable state. Dangerous, because “standard CloudFormation” doesn’t automatically mean “standard operational model.” Copilot’s templates encoded conventions (naming, parameterization, shared environment resources, ALB sharing, service discovery patterns) that you’ll need to preserve if you want to keep the same outcomes.
Adopting the stacks is a good fit if:
- You have a stable set of services and you mostly need maintenance changes (image updates, autoscaling tweaks, minor networking adjustments).
- You already have CloudFormation expertise and a disciplined change-management pipeline.
- You’re comfortable accepting that Copilot’s abstractions may not keep pace with newer AWS features.
What to do next if you choose this path: inventory your Copilot-managed stacks, map them to ownership, and decide how you’ll test changes. The key is to treat the templates as production IaC, not “generated output.” Once Copilot is frozen, any upgrades to underlying AWS behavior become your problem.
Migration option 2: ECS Express Mode (a new opinionated surface)
AWS also recommends ECS Express Mode as the fastest path from container to production, with AWS making a bunch of infrastructure decisions “automatically with sensible defaults.” It’s easiest to think of Express Mode as a replacement for Copilot’s workflow, not its templates. It’s designed for teams that want to ship services with minimal bespoke infrastructure design, while still getting production basics like load balancing, TLS termination, and scaling.
The tradeoff is subtle: you may gain simplicity, but you’re adopting a new abstraction. Copilot’s abstraction was “service patterns + manifest.” Express Mode’s abstraction is “service created with a reduced set of knobs and a strong default story.” If your services are typical web APIs, that’s good news. If you relied on Copilot’s ability to layer customizations via CloudFormation add-ons, you’ll need to validate how those customizations translate.
A sane strategy here is to pilot Express Mode on a non-critical service with real traffic, then answer three questions before you commit:
- Observability parity: do you get logs/metrics/tracing in the right places without special casing?
- Networking constraints: do your VPC and security-group requirements fit the defaults, or do you need exceptions?
- Day-2 operations: what’s the rollback story, and can incident responders trace from symptom → resource → config quickly?
Migration option 3: CDK L3 constructs (more power, more platform work)
CDK is the “grown-up” choice AWS highlights for teams that want fine-grained control and infrastructure-as-code in a general-purpose language. The important thing is to understand what you’re trading away: Copilot’s uniform developer workflow. If you move to CDK, you’re not just changing tooling; you’re potentially changing your org’s operating model. Who writes the CDK? Who approves changes? How do service teams request a new pattern without blocking on the platform group?
CDK can still preserve a Copilot-like experience if you invest in internal L3 constructs or templates that encode your standards. Without that, CDK adoption often turns into “every team invents their own infrastructure,” which is exactly what Copilot helped you avoid.
If you go the CDK route, consider a phased plan:
- Phase 1: mirror one Copilot service in CDK, aiming for functional parity.
- Phase 2: standardize by extracting internal constructs (e.g., “CompanyWebService,” “CompanyWorkerService”) with guardrails.
- Phase 3: migrate the rest of the fleet, prioritizing services that need new capabilities Copilot won’t deliver anymore.
How platform teams should think about the next 90 days
This is a timing problem more than a technical one. June 12 is a clear deadline, but migrations don’t happen on calendar dates. The fastest way to get stuck is to treat this as a pure “replace Copilot” project. The better framing is: what deployment interface do we want to support long-term? Then choose the migration path that gets you there with the least risk.
A practical checklist:
- Classify your Copilot usage: how many services, what service types (web/worker/scheduled jobs), what customizations (addons, custom domains, service discovery).
- Pick a default path: most orgs should pick one “standard migration route” and keep exceptions rare.
- Design the new contract: what app teams own (configs, environment variables, scaling) vs. what the platform owns (networking, TLS, IAM boundaries, logging/tracing backends).
- Build a migration playbook: steps, validation, rollback, and an incident-response appendix.
Copilot’s end-of-support is a forcing function, but it’s also an opportunity. If you do it right, you come out with fewer bespoke templates, clearer ownership, and a deployment interface that can evolve with the AWS container platform rather than lag behind it.