profile

AWS for the Real World

Every layer AWS built on ECS is dying

Published about 1 month ago • 3 min read
AWS FOR THE REAL WORLD
⏱️
Reading time: 10 minutes
🎯
Main Learning: Every convenience layer AWS built on ECS is dead or dying, while ECS itself has not changed since 2014. Build on the primitive, and make the layer above it prove itself first.
📝

Hey Reader 👋🏽

Getting started with an AWS service often feels more complicated than it should.

  • Four concepts must be understood before a single container runs.
  • A VPC is required before a single request.

So, the fancy CLI that promises to do all of it for you is tempting.

One thing we learned the hard way: learn the primitives once and skip the convenience layer.

I (Sandro) learned that with the first thing I ever built on AWS. A mobile app called Deposur (here is an ​old tweet ​I've found). It was a full-stack mobile app to track your investments like ETFs or stocks.

I used the Amplify v1 CLI for that. It worked great. Amplify generated the whole GraphQL API and DynamoDB schema for me. The issue back then was that there was no way to get out of it.

It was very opinionated about things. If you had an issue with a CloudFormation deployment or with some generated path, you were mostly stuck.

Newer Amplify versions are much better about that now.

I'd still only use the main services! Especially with AI. It is so easy to get in-depth explanations of what each service configuration is doing.

Learn it once, apply it forever.

That is what today's deep dive is about. Tobi keeps a list of every layer AWS built on top of ECS. Most of it is dead or dying.

Sponsored
Trigger.dev chat.agent  •  Open Source

One conversation, one durable task.

I have built the same AI chat feature three times now. LangChain, Strands, plain Vercel AI SDK. The orchestrator changes, the plumbing never does: API Gateway with streaming, Lambda, DynamoDB for conversation state, OTEL into CloudWatch for the traces. It works, but it is annoying.

AI chat on plain AWS: six things to wire up. Trigger.dev chat.agent: one durable task per conversation.

chat.agent moves that plumbing into one durable task per conversation. Every message is stored on the server, the client only sends the new one. Responses stream straight into the normal useChat hook. A tool that needs a human answer pauses the agent until it arrives. And every turn is a span, so you open a session in the dashboard and read what happened.

It is 100% open source. Read the code, self-host it, try it without asking anyone. The next chat feature I build, I will give it a try.

Give chat.agent a try →

Sponsored by Trigger.dev. The words are Sandro's own.

Build on ECS primitives, not convenience layers

📚 This Week's Deep Dive

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

ECS CLI, archived after ten years. Fargate CLI, archived. Copilot CLI, end of life since June. AWS Proton, end of life in October. App Runner, in maintenance mode since April: no new features, no new customers. We called App Runner "the easy way to run your containers" back in 2023. That framing has not aged well.

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 task definitions and services underneath. Strip the wrapper away and the primitives were there the whole time.

ECS launched in 2014. Its core API has not changed since. Fargate added a capacity mode in 2017, not a new API. Tobi has services on it running since 2019 that he has not touched once. Zero drama.

So why does the primitive survive while everything on top of it gets cut? Team size is not the difference, ECS has a team too. And two wrappers, Elastic Beanstalk and Lightsail, are still running a decade on. Any theory of why convenience layers die has to explain those two.

The article covers the pattern behind the graveyard, the two questions that separate a safe wrapper from a risky one (Terraform and CDK are wrappers too, and Tobi uses both), and where ECS Express Mode, AWS's newest attempt at the same idea, lands on that line.

That's it for this issue.

If you take one thing away: when something on AWS promises to make a service easier, check what sits underneath it first. Build on that. Let the layer above it prove it survives before anything production-critical depends on it.

And if you are still running on Copilot or Proton: the task definitions and services are still there. You are closer to plain ECS than it feels.

See you in the next one!

Sandro & Tobi

AWS for the Real World

by Tobi & Sandro

We teach AWS for the real world - not for certifications. Join more than 10,500 developers learning how to build real-world applications on AWS.

Read more from AWS for the Real World

⏱️ Reading time: 15 minutes 🎯 Main Learning: A public container on AWS for $7 a month, with no VPC to own. 📝 Blog Post 🤝 Sponsored by AWS. What we built, what it cost and what we think of it are our own. Hey Reader 👋🏽 Your first container on ECS comes with homework: a VPC, subnets in two Availability Zones, a load balancer, security groups, a certificate and a task role. Express Mode creates most of it for you now (App Runner's successor, so ECS abstraction number three), but it all lands in...

5 days ago • 2 min read

AWS FOR THE REAL WORLD ⏱️ Reading time: 6 minutes 🎯 Main Learning: You cannot skip a level of AWS observability. Structured logs come first, then the AI agent that reads them for you. 📝 Blog Post 📂 Claude Code agent (free gist) 🎬 Watch on YouTube Hey Reader 👋🏽 This week I'm bringing back one of our most-read posts: the 3 levels of AWS observability. A lot of you joined after it went out in May, and the topic fits this week perfectly. Because the real question isn't "do I have logs?" anymore....

18 days ago • 2 min read

⏱️ Reading time: 21 minutes 🎯 Main Learning: Same CloudFront logs: 12.5s through Kinesis, S3, Glue and Athena, about 1s through Tinybird's managed ClickHouse. 📝 Blog Post Hey Reader 👋🏽 We've been running Plausible for the analytics on awsfundamentals.com. Good software, no complaints. We still wanted the data to be ours: our retention, our schema, nobody's script in the visitor's browser. So we built the dashboard ourselves. Twice, on two different backends, fed by the same CloudFront logs....

about 2 months ago • 1 min read