Do You Need an Internal Developer Platform for AWS ECS?
Your VP read about platform engineering. Your team runs ECS Fargate, not Kubernetes. Most IDP content assumes K8s — do the same rules apply? ECS teams have a simpler compute model but the same operational pain: too many environments, no self-service, invisible costs. Here's a framework to decide what you actually need.
- 0193% of top-performing teams use an IDP — only 2% of low performers do (Humanitec 2023 Benchmarking Study)
- 02ECS teams don't need a full IDP — they need an operational layer on top of ECS
- 03If you have <5 environments, you don't need an IDP yet — Terraform + manual ops works fine
- 04The real ROI for ECS teams is in scheduling, cost visibility, and self-service — not service catalogs or scorecards
- 05Portals (Backstage, Port) are the frontend of an IDP, not the IDP itself — building one without ops is like framing a door before you have walls
What is an Internal Developer Platform, really?
An Internal Developer Platform is the sum of all the tools a platform engineering team binds together to pave golden paths for developers. The goal is developer self-service: a developer provisions a database, deploys a service, or checks environment status without filing a ticket and without becoming a cloud infrastructure expert.
A well-designed IDP follows a Platform as a Product approach — the platform team treats developers as customers and continuously improves the platform based on their needs. The five standard planes of an IDP (from the Humanitec reference architecture):
The same study found that only 1.88% of low-performing teams use an IDP. The correlation is impossible to ignore: top performers invest in platforms. But here's the catch — the study, like most IDP content, is Kubernetes-native. ECS teams have a fundamentally different starting point.
Why ECS is different from Kubernetes
Kubernetes IDPs manage control planes, node pools, cluster addons, and cluster-level RBAC — because someone has to. ECS eliminates that entire layer. AWS runs the control plane. Fargate eliminates host management. You don't patch nodes, you don't upgrade cluster versions, you don't manage etcd.
But here's what ECS doesn't give you — and what the cloud native compute landscapemakes painfully clear: an operations layer. ECS gives you compute. It doesn't give you scheduling, cost visibility per environment, developer self-service, or environment cloning. Those are left as an exercise for the reader.
Notice the pattern: K8s complexity is infrastructure complexity. ECS complexity is operations complexity. The tools designed for K8s complexity are the wrong tool for ECS operations.
The decision framework: do you need an IDP?
Answer four questions. Each answer adds points to your score. The total tells you whether you need nothing, an operational layer, or a full platform.
What ECS teams actually need: the operational layer
If you scored 5–8 in the framework, this section is for you. Here are the four capabilities that define an operational layer for ECS — and why each matters.
Non-prod environments run 168 hours/week. Your team works ~55. Scheduling environments offline outside business hours is the single largest cost lever available to ECS teams. AWS-native scheduling (EventBridge + Lambda) works at 3–5 environments but becomes unmaintainable at 10+: 160 Auto Scaling actions to create, per-environment timezone handling, and silent failed starts that nobody catches until Monday morning.
Cost Explorer shows your total AWS bill. It doesn't show what dev1 costs vs. dev2 vs. staging. AWS ECS Split Cost Allocation Data (launched 2023) helps — it attributes Fargate spend per cluster and service using system tags — but only if your naming is consistent and only for compute. It misses the fixed overhead: ALB, NAT Gateway, CloudWatch. An operational layer shows the full cost per environment, updated continuously, not with a 24-hour lag.
Restarting staging. Viewing logs. Checking environment status. These are 30-second tasks that take 3 hours when they require a platform engineer. The fix: scoped, per-environment RBAC that lets developers act on their environments without IAM access to the AWS console. A developer who can restart dev but never touch prod is a developer who doesn't Slack you at 9pm on Friday.
The compliance auditor wants a clone of production. That's 15 services, an ALB, RDS, SSM parameters — a manual process that takes hours and is error-prone. A parameterized clone operation that copies the environment template (service definitions, task sizes, environment variables) to a new environment in one operation turns a multi-hour nightmare into a 5-minute task.
What ECS teams don't need (that K8s IDPs sell)
IDP vendors bundle features for Kubernetes complexity. If you're on ECS, you can skip most of them. Here's what to say no to:
You already know your services if you have fewer than 60. Backstage takes 3–6 months to set up and 1–2 FTEs to maintain. That's $150–400k/year for a catalog of services you already know about. If you need a catalog, wait until you have 50+ services and multiple teams that can't find each other's APIs.
Terraform already provisions your ECS resources. AWS CDK or Pulumi already do if that's your stack. A platform orchestrator that provisions infrastructure is solving a K8s problem — terraform apply is not your bottleneck.
DORA metrics and maturity scores are useful for eng leadership. They're not an operations problem. If you're losing hours to ticket ops and can't see what your environments cost, scorecards don't fix that. They're a layer on top of the ops layer you haven't built yet.
If you're 100% AWS ECS, you don't need a platform that abstracts away the cloud provider. The abstraction layer adds complexity without benefit — you're not switching clouds next quarter. The operational layer should be cloud-native, not cloud-agnostic.
Build vs buy: the real costs
If you decide you need an operational layer or a full platform, the next question is: build it or buy it? Here's the real math, factoring in engineering time — the line item most build-vs-buy analyses leave out.
The DIY path (Backstage + custom plugins + Lambda scheduling + Cost Explorer scripts) looks free on the license line. But at 1–2 FTEs for maintenance — engineers who could be building product features instead of maintaining platform glue — the real cost is $150,000–400,000/year.
On the buy side, Humanitec is the market leader for K8s IDPs. At $2,199–5,499/mo it's cheaper than a dedicated FTE — but it carries Kubernetes overhead into an ECS environment that doesn't have the problem it solves. Port is a developer portal at $30–40/seat/mo that shows you your services but doesn't operate them.
When an IDP is overkill for ECS
Platform engineering is real — but not every team needs a platform. Here are the scenarios where you should invest your engineering time elsewhere:
FAQ
If you read this, you might also want to know
What's the difference between an IDP and a developer portal?
A portal (Backstage, Port, Cortex) is the interface — the Developer Control Plane in IDP terms. It shows you your services, their status, and their dependencies. An IDP includes the portal PLUS the Integration & Delivery Plane — the engine that actually provisions infrastructure, manages deployments, and enforces configuration standards. A portal is a window; an IDP is the building.
Can I use Backstage as my IDP for ECS?
You can use Backstage as the frontend of your platform — but you'll need to build the backend yourself. Backstage has no native ECS integration. You'd need to write custom plugins to surface ECS services, handle scheduling, show costs, and enable self-service actions. Expect 3–6 months of engineering time and ongoing maintenance. Backstage is a great portal; it's not an IDP out of the box.
How long does it take to set up an operational layer for ECS?
If you build it yourself: 2–4 months for scheduling + cost scripts + basic self-service, assuming 1–2 engineers part-time. If you use a purpose-built tool like Fortem: deployment takes ~7 days against your existing AWS infrastructure. The time-to-value difference is the main argument for buying vs. building at ECS scale.
Does Fortem replace Terraform, or work alongside it?
Fortem works alongside Terraform — it's the operations layer on top, not a replacement for IaC. You continue provisioning ECS resources with Terraform (or CDK, or Pulumi). Fortem reads those resources from the AWS API and layers on scheduling, cost visibility, cloning, and self-service. No migration, no lock-in.
See if Fortem fits
your ECS team.
Fortem is the operational layer for ECS — scheduling, cost visibility, environment cloning, and developer self-service. Purpose-built for Fargate, not adapted from Kubernetes. Running against your AWS in 7 days.