Do You Need an Internal Developer Platform for AWS ECS?
Originally published at https://fortem.dev/blog/internal-developer-platform-ecs
93% of top-performing teams use an IDP. But ECS teams don't need a full platform — they need an operational layer. A decision framework to figure out what you actually need.
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.
TL;DR
- 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):
01
Developer Control Plane
The interface developers interact with — portals, CLI tools, workload specs like Score
02
Integration & Delivery Plane
The orchestrator that builds, configures, and deploys — the engine of the IDP
03
Resource Plane
The actual infrastructure — clusters, databases, DNS, storage
04
Monitoring & Logging Plane
Real-time metrics and logs for apps and infrastructure
05
Security Plane
Secrets management, identity, and access control
KEY INSIGHT: Key insight A developer portal (Backstage, Port) is NOT an IDP. The portal is the frontend — the “developer control plane.” Without the Integration & Delivery Plane behind it, a portal is a service catalog that shows you what's running but can't operate it. That's the difference between a dashboard and a platform.
93%
of top-performing engineering teams use an Internal Developer Platform
Humanitec DevOps Benchmarking Study, 2023
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.
ECS teams
Operations Layer
Scheduling · Cost visibility · Self-service · Cloning
↑
ECS Fargate
Managed compute — AWS runs the control plane
↑
Terraform / CDK
Infrastructure as Code — provisioning
✓ 3 layers · Purpose-built for ECS
Kubernetes IDP approach
Developer Portal
Backstage · Port · Cortex
↑
Platform Orchestrator
Humanitec · Score · Resource Definitions
↑
Kubernetes Control Plane
Node pools · Addons · Cluster RBAC — you manage this
✗ 5+ layers · Designed for K8s complexity
KEY INSIGHT: Key insight ECS removes the Kubernetes tax — you don't pay for a control plane or node management. But ECS doesn't give you an operations layer either. That's the gap that platform engineering needs to fill — differently for ECS than for K8s.
K8s teams needECS teams need
Control plane managementNothing — AWS runs it
Node pool scaling & patchingNothing — Fargate handles it
Cluster-level RBAC + namespacesPer-environment IAM scoping
Multi-cluster orchestrationMulti-environment operations
Service mesh / ingress controllerALB + target group naming (32-char limit!)
Pod security policiesTask execution roles + SSM path hierarchy
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.
How many non-prod ECS environments do you run?
1–45–1415+
How many hours per week do developers spend waiting on ops?
< 2 hrs2–8 hrs8+ hrs
Can you see what each environment costs, right now?
Yes, per-environment
Roughly, via tags
No idea
Can developers restart staging/QA without filing a ticket?
Yes, self-service
Sort of, with IAM hacks
No, ticket required
Your result
You're fine for now
Terraform + manual ops works at your scale. Come back when you hit 10+ environments or your developers start complaining about ticket ops.
How to interpret your result
A score of 0–4 doesn't mean you'll never need a platform — it means you're not at the pain threshold yet. Most ECS teams cross into “operational layer” territory around 10–15 environments. The jump to “full platform” territory usually happens around 40+ services and multiple teams, when coordination overhead becomes the bottleneck.
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.
01
Fleet-wide environment scheduling
60–70%compute cost reduction for non-prod
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.
02
Per-environment cost visibility
$0AWS shows the total, not per-env
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.
03
Developer self-service actions
2–8 hrs/wkdeveloper time spent waiting on ops tickets
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.
04
Environment cloning
12+ stepsmanual process to clone one environment
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:
✗
Service catalogs with plugin ecosystems
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.
✗
Infrastructure orchestration (beyond Terraform)
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.
✗
Scorecards and engineering maturity dashboards
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.
✗
Multi-cloud abstraction layers
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.
The portal trap
The most common platform engineering mistake for ECS teams: building a Backstage portal first, before building the operational layer. You end up with a beautiful UI that shows your services — and doesn't let you schedule them, clone them, or see what they cost. The portal is the front door. Build the house first.
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.
DIYHumanitecPortFortem
License cost$0$2,199–5,499/mo$30–40/seat/moFree for 1 env
Setup time3–6 months2–4 weeks1–4 weeks7 days
Ongoing maintenance1–2 FTEs ($150–200k/yr)0.5 FTE0.5–1 FTENone
ECS-native?You build itK8s-first, ECS via APICatalog only, no ops✓ Purpose-built
Scheduling?Lambda + EventBridgeNoNo✓ Fleet-wide
Cost visibility?Tags + Cost ExplorerNoNo✓ Per-environment
Env cloning?Manual or scriptedYes (via Score)No✓ One click
Prices verified June 2026. Humanitec and Port pricing from official pages.
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.
KEY INSIGHT: Key insight For ECS teams, the right buy decision is an operational layer — not a full IDP. The cost structure (no per-seat pricing, no platform engineering team required) means the ROI threshold is lower: it pays for itself at 5+ environments, not 40+.
When an IDP is overkill for ECS
You don't need an IDP if...Why
< 5 environmentsTerraform + manual ops works fine. The overhead of setting up a platform exceeds the benefit at this scale.
All environments are productionNo dev/staging/sandbox sprawl, no scheduling savings. Your ops surface is small.
< 10 engineersCoordination overhead is low. Everyone knows who owns what. Ticket ops aren't a bottleneck yet.
Full-time platform engineers on staffIf you already have the team and they've built custom tooling, a commercial platform may be redundant — or an accelerator, depending on how much they're maintaining vs. building.
You only have 1–3 servicesECS is simple at this scale. You don't need a fleet management tool for a fleet of 3.
The rule of thumb
Platform overhead pays for itself only after ~15 environments for a full IDP, or after ~5 environments for an operational layer. If you're below those thresholds, invest in better Terraform modules, consistent naming, and good documentation first. You'll know when you've crossed the line — your developers will tell you.
Map your fleet in 5 min: fortem.dev/audit
Top comments (0)