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. A framework below maps your situation to what you need.
- 0193% of top-performing teams use an IDP — only 1.88% 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?
“93% of top-performing teams use an IDP — only 1.88% of low performers do.”
— Humanitec DevOps Benchmarking Study, 2023
An IDP is the tooling a platform team binds together for developer self-service — five planes: control, delivery, resource, monitoring, security. A portal alone is not an IDP.
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. 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
ECS eliminates the Kubernetes infrastructure tax — AWS manages the control plane, Fargate eliminates nodes. The ECS gap is operations: scheduling, cost visibility, self-service.
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.
What ECS doesn't give you — and what the ECS Fargate best practicesmake painfully clear — is 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?
Under 5 ECS environments: skip the IDP. At 5–15: an operational layer (scheduling, cost, self-service) gives the best ROI. At 15+ with multiple teams: a full platform pays off.
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
ECS teams need four things: fleet-wide scheduling, per-environment cost visibility, developer self-service with RBAC, and one-click environment cloning — not a full K8s-style IDP.
If you scored 5–8 in the framework, the four capabilities below 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. The limits of AWS-native scheduling (EventBridge + Lambda) become clear at scale — 160 Auto Scaling actions to create, per-environment timezone handling, and silent failed starts that nobody catches until Monday morning. A purpose-built approach to ECS environment scheduling handles this fleet-wide.
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)
Skip service catalogs, infrastructure orchestrators, scorecard dashboards, and multi-cloud abstraction layers — those solve Kubernetes problems ECS teams do not have.
IDP vendors bundle features for Kubernetes complexity. If you're on ECS, you can skip most of them. Four things worth saying 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
DIY platform costs $150–400k/yr in FTE time. Humanitec runs $2,199–5,499/mo but carries K8s overhead. For ECS the right buy is an operational layer — cheaper and faster to deploy.
If you decide you need an operational layer or a full platform, the next question is: build it or buy it? The math below factors 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. The real cost of ECS Fargate visibility comes from the tooling gap between what AWS provides and what your team needs per environment.
When an IDP is overkill for ECS
If you run fewer than 5 environments, fewer than 10 engineers, or only 1–3 services, an IDP adds overhead that outweighs the benefit — Terraform and manual ops is the right call.
Platform engineering is real — but not every team needs a platform. The scenarios below show where you should invest your engineering time elsewhere:
Fortem is the operational layer purpose-built for ECS Fargate — fleet-wide scheduling, per-environment cost visibility, developer self-service, and one-click environment cloning. It connects to your existing AWS infrastructure in 7 days, no Terraform migration required.
Book a 20-min call →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.