Do You Need an Internal Developer Platform for AWS ECS?
Originally published at https://fortem.dev/blog/internal-developer-platform-ecs
93% of top teams use an IDP. But ECS teams need an operational layer — not a full platform. 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. A framework below maps your situation to what you need.
TL;DR
- 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):
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. 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.
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 platform engineering for ECS at 10+ environments.
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.
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
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.
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. 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.
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)
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:
✗
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
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.
DIYHumanitecPortFortem
License cost$0$2,199–5,499/mo$30–40/seat/mo$790/mo Starter
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. See the full Fortem vs Humanitec comparison for a deeper look at fit and ECS support.
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.
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
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.
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.
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.
Map your fleet in 5 min: fortem.dev/audit
Top comments (0)