Platform Engineering for ECS Teams: What It Actually Means at 10+ Environments

The operations gap — what Terraform can't do

Terraform provisions ECS infrastructure. It has no concept of "stop this environment at 7pm" or "show me which environments are idle right now." That gap widens with every new environment.

This isn't a criticism of Terraform. IaC is the right tool for provisioning. The problem is that provisioning is only half of the job. Once an environment exists, someone has to operate it — and Terraform has no primitives for that.

Here's what the operations gap looks like concretely at 10+ ECS environments:

The state sprawl problem compounds all of this. At 50 environments, you're looking at roughly 1,500 Terraform resources. A terraform plan across the full fleet takes 4+ minutes. Adding a new environment requires updating a checklist of steps, not running a single command.

None of this is Terraform's fault. These are operations problems. Terraform was never designed to solve them.

Three things every ECS platform team needs

Environment scheduling, developer self-service with scoped access, and fleet visibility with cost attribution. Everything else is optional until you've solved these three.

Build vs buy — the honest breakdown

Building scheduling and self-service yourself works at 3 environments. At 15 it's a maintenance burden. At 30 it's a second product your platform team maintains instead of ships.

The build path is real and reasonable at small scale. Lambda + EventBridge for scheduling, custom IAM policies per developer, CloudWatch dashboards per environment — doable, well-understood, free. Total engineering cost: 2–4 weeks to build, plus ongoing maintenance.

The maintenance cost is what gets teams. At 20 environments, you have 20 separate scheduling stacks. Adding a new environment means a 30-minute checklist. Changing the schedule logic means 20 updates. A developer joins — you update 20 sets of IAM policies. A developer leaves — same thing. Each of these tasks is small. Collectively, across 20 environments, they fill the platform team's week.

Here's what the build path looks like for one environment — a business-hours schedule that stops ECS services at 8pm and starts them at 8am:

# Stop all services in dev environment at 8pm Mon–Fri
resource "aws_cloudwatch_event_rule" "stop_dev" {
  name                = "stop-dev-environment"
  schedule_expression = "cron(0 20 ? * MON-FRI *)"
}

resource "aws_cloudwatch_event_target" "stop_dev" {
  rule = aws_cloudwatch_event_rule.stop_dev.name
  arn  = aws_lambda_function.ecs_scaler.arn
  input = jsonencode({
    cluster     = "dev"
    action      = "stop"
    environment = "dev"
  })
}

# Start all services at 8am Mon–Fri
resource "aws_cloudwatch_event_rule" "start_dev" {
  name                = "start-dev-environment"
  schedule_expression = "cron(0 8 ? * MON-FRI *)"
}

resource "aws_cloudwatch_event_target" "start_dev" {
  rule = aws_cloudwatch_event_rule.start_dev.name
  arn  = aws_lambda_function.ecs_scaler.arn
  input = jsonencode({
    cluster     = "dev"
    action      = "start"
    environment = "dev"
  })
}

# Plus: the Lambda function, its IAM role, the permission to invoke it,
# and the logic to iterate over every service in the cluster.
# Multiply everything above by the number of environments you have.

That's ~50 lines of Terraform for one environment. At 20 environments, you have 20 copies of this — each with its own EventBridge rules, Lambda permissions, and IAM roles. When you want to change the stop time from 8pm to 7pm, you update 20 files. When you add a new environment, you copy-paste and rename. This is the maintenance burden that accumulates.

The decision rule is simple: if you have fewer than 5 environments, build. The DIY approach is fast, cheap, and fits the problem. If you have 10+ environments and your platform team is spending meaningful time on operational maintenance instead of platform infrastructure, the math shifts.

Do you need a full IDP?

A Backstage portal or Humanitec-style platform orchestrator solves developer-experience problems across a whole org. Most ECS teams at 10–50 environments have an operations problem, not a portal problem.

A full Internal Developer Platform — Backstage, Port, Humanitec, Cortex — is the right answer when you have 50+ engineers across multiple platforms (AWS, GCP, Azure, Kubernetes), a dedicated platform team of 5+, and a mandate to standardize how all of engineering provisions and deploys. That's a real problem and these are real solutions.

For a team of 30–150 people running primarily ECS Fargate with 1–3 platform engineers, an IDP is almost certainly overkill. The build cost alone — Backstage requires weeks of customization before it reflects your actual stack — is disproportionate to the problem. Developers aren't asking for a software catalog. They're asking to restart their own staging environment without opening a Slack ticket.

One tool worth flagging: AWS Proton was positioned as a platform engineering layer for ECS teams. AWS shut it down to new customers in October 2025. If you were evaluating Proton, it's off the table. See the AWS Proton deprecation guide for migration options.

The middle ground that covers 90% of ECS platform engineering needs at 10–50 environments: a lightweight operational layer (scheduling + self-service + fleet visibility) on top of Terraform + your existing CI/CD pipeline. No new abstraction layers. No proprietary config formats. No 6-month implementation.

Questions this raises

• →How do I convince my CTO we need a platform team?
• →What's the difference between platform engineering and DevOps?
• →When should an ECS team actually build a developer portal?

FAQ