Build on ECS Primitives, Not Convenience Layers

I keep a list of every layer AWS built on top of ECS. Most of it is dead or dying.

There are plenty of good reasons to build on ECS. It's stable, and enough of the internet runs on it that most of the rough edges have already been found by someone else. None of that is a reason to trust everything AWS ships around it in the same way. Every wrapper or managed workflow built on top of ECS is a separate bet with its own odds of survival. This list is what happens when you don't check those odds first.

The ECS Graveyard

Here's the list, in order of when AWS pulled the plug or announced the date.

Sundown dates last checked against AWS's own announcements in September 2026.

None of them touched ECS itself. Each one put a friendlier CLI or console flow in front of containers that kept running on the same ECS primitives underneath. Strip away the wrapper and those task definitions and services were still there the whole time.

Two footnotes on that table. App Runner is in maintenance mode rather than shut down, which means no new features and no new customers, not that it stops running next quarter. We called it the easy way to run your containers back in 2023, and that framing has not aged well. Fargate CLI was an awslabs open-source project instead of a managed service, and AWS archived it all the same.

To be fair, ECS doesn't make that easy going in. Nothing runs until you understand a task, a task definition, a service, and a cluster, and how those four fit together. That's a real entry barrier. But once it's running, it tends to just keep running.

Why Convenience Layers Die

ECS also has a team behind it, so team size isn't really the difference. The difference is how deeply each one is woven into everything else. ECS is a core building block other AWS services build on, other AWS customers depend on directly, and Amazon itself almost certainly runs internally somewhere. It's the kind of service you can't retire even if you wanted to, because too much sits on top of it.

Copilot, Proton, and App Runner were not load-bearing in that sense. They were bets on making ECS, or containers in general, easier for a specific audience. Some of those bets add complexity of their own. Copilot is the clearest example. It brought a deployment model of its own, so you were learning Copilot on top of learning ECS. If a bet doesn't find adoption, AWS doesn't keep funding it out of sentiment. That's not unique to ECS's convenience layers either. Pretty much everything in AWS's catalog that survives has real, ongoing usage behind it. Everything that doesn't tends to end up on a list like this one eventually.

The Wrappers That Are Still Running

Elastic Beanstalk and Lightsail are the two counterexamples I have to account for.

Beanstalk launched in 2011 and you can still deploy to it today. It is a convenience layer over EC2 and ECS in the same way Copilot was, and AWS never pulled it. I have never understood why it is still there. Every time I have looked at it, it was EC2 with extra rules and no clean way back out, and fifteen years later that is still my read.

Lightsail launched in 2016, sits on top of EC2, and is still on the pricing page. It is also the layer in this post that kept getting better. The blueprint list grew well past the old Bitnami defaults, and the Node.js, LAMP, and Ruby on Rails images now enforce IMDSv2 by default. There is even an OpenClaw blueprint that stands up an agent with Bedrock wired in, which is the clearest sign the service is still moving. I run OpenClaw on Lightsail myself from the $7 setup I wrote up, and the video walkthrough builds the same thing. To be clear, this is not a knock on Lightsail. It is a good product with a clear use case, which is one small always-on box at a fixed price where you never think about a VPC. What it does not have is ECS's decade of production exposure behind it, and that gap is the whole point of this post.

So why did those two survive while Copilot and Proton did not? Both settled into serving the customers they already had instead of chasing new ones. Beanstalk still has applications running on it that nobody wants to migrate, and AWS keeps the lights on for them. Lightsail covers a segment AWS has no other product for.

That is the pattern behind the list at the top. Copilot, Proton, App Runner, and ECS Express Mode were all pitched as growth bets, and Beanstalk and Lightsail were not.

ECS Itself: 2014, API Unchanged, Still Running

I've said this before: ECS is boring, and that's a compliment.

I've had services running on it since 2019 that I haven't had to touch once. Zero drama, no surprise outages.

ECS launched in 2014. Its core API has stayed stable since, task definitions and services included.

Fargate, when it arrived in 2017, added a capacity mode, not a new API. You still describe a task definition and a service the same way you did a decade ago.

Everything built on top of that API got cut at some point, whether that was ECS CLI, Fargate CLI, Copilot, Proton, or App Runner. ECS never did. Too much runs directly against it, including other AWS services, for anyone to consider deprecating it. Boring and unchanged isn't a limitation here. It's the reason nothing above it has been able to replace it.

The Rule: Pick Primitives, Skip the Wrapper

A primitive is something other services and third-party tools build against directly, like ECS, EC2, S3, and IAM. A convenience layer is anything whose only job is making a primitive easier to use, whether that's a CLI wrapper or a managed deployment pipeline. If you want the wider map of AWS compute, our compute services guide covers the rest of it.

Two questions decide this, and a wrapper can fail either one.

1. If this got killed tomorrow, could you still run on what's underneath? That one is less obvious than it sounds, because Terraform and CDK are wrappers too and I use both. What separates them is what the wrapper hands back to you. Terraform and CDK produce configuration you own, and you can deploy the same file with or without them. Copilot generated CloudFormation you could read, keep, and apply yourself. ECS Express Mode owns the resources instead of describing them, so there is nothing to walk away with. Ask whether you can leave with the thing the wrapper built, or whether the wrapper is the thing.
2. Is AWS still treating this as a growth bet? That is the test that predicts the layers that actually get cut, and the table at the top is what failing it looks like.

Those two questions split a lot of AWS's catalog cleanly. In each pair below, one side is infrastructure other things depend on, and the other side is a convenience wrapper depending on it.

• ECS versus Copilot or Proton, both of which are end of life
• EC2 versus Lightsail or Elastic Beanstalk, both still running a decade on
• S3 versus Amplify Hosting, which is not going anywhere either

The point is not that everything on the right is about to die, since Beanstalk and Lightsail show the right side can last a decade. It is that the right side is the one you can lose without losing the thing underneath it.

Primitives also keep getting easier to use on their own, without AWS having to ship a new abstraction. The Terraform and CDK providers for ECS stay current because enough people use them to justify the maintenance. Community modules fill in the rest. Hosting a frontend on S3 and CloudFront is the same story, where the CloudFront Hosting Toolkit does the job a managed wrapper would have done and you still own the distribution. That tooling grows around the primitive because the primitive isn't going anywhere, which is exactly the bet a convenience layer can't make about itself. The bill follows the same pattern, since you pay for the primitive and nothing sitting on top of it.

Where This Leaves ECS Express Mode

ECS Express Mode is AWS's newest attempt at the same idea Copilot and Proton were built on: make ECS easier to use without changing ECS. At launch, it looks exactly like every convenience layer that came before it did at launch. There's no way to tell from here whether it survives or joins the list above.

Early opinions are mixed rather than settled, which tracks with how early this still is.

• One review calls it a disappointment, arguing it hides the underlying ECS resources without actually removing the complexity of debugging them when something breaks.
• Another makes a similar point: it drops CloudFormation from the stack in favor of new, opaque abstractions, which cuts against how most other AWS wrapper services are built.

I haven't seen a broad adoption signal yet either way. What I would count as one: Express Mode landing in the Terraform or CDK providers, AWS putting it into Well-Architected guidance, a re:Invent session that is not a launch talk, or customers writing about running it in production a year from now. re:Invent in December is the first checkpoint where any of that could show up, and I'll revisit this post then.

My rule doesn't change because the pitch is new. I'd wait for a real adoption signal, not a launch announcement, before anything production-critical runs on it. Primitives first, convenience layers only once they've been around long enough to prove they're not next on the list.

The Short Version

Almost every convenience layer AWS built on top of ECS is retired or on its way out, and ECS itself has not changed since 2014. That is not an argument against new services, it is an argument for checking what sits underneath them first. Build on the primitive, and make the layer above it prove itself before anything production-critical depends on it.