How Do You Find and Kill Orphaned ECS Environments Before They Drain Your Budget?

The real cost of a dead environment

One orphaned Fargate environment with zero running tasks costs $48–65/month: ALB $16.43 + NAT Gateway $32.40 + CloudWatch log storage. No compute, but the infrastructure meter runs.

The ALB base rate is $0.0225/hr (verified June 2026) — $16.43/month whether or not a single request passes through it. NAT Gateway is $0.045/hr (verified June 2026) — $32.40/month per AZ. If your environment spans two AZs, that's $64.80/month just in NAT Gateway overhead.

At 5 forgotten environments, that's $3,900/year in pure infrastructure waste. No compute. No traffic. No one using it.

The number teams miss when auditing is also the fixed overhead per environment that persists regardless of task count. An environment costs money from the moment you create the ALB and NAT Gateway — not from the moment tasks start running.

What to check before you delete

Before deleting any environment, verify three things: no scheduled job points at it, no CI/CD pipeline references the cluster name, and the ALB isn't shared between multiple services.

EventBridge scheduled rules. Nightly jobs, weekly reports, scheduled ECS tasks — all reference a cluster and service by name. Check for rules targeting your environment before deleting:

aws events list-rules --query 'Rules[*].[Name,ScheduleExpression,State]' --output table
# Then for each relevant rule:
aws events list-targets-by-rule --rule <rule-name> --query 'Targets[*].EcsParameters'

Terraform state. If the environment was created with Terraform, its state file still references the service, cluster, ALB, and target group. Deleting resources manually without running terraform destroy first will leave Terraform in a broken state on the next plan. Either run terraform destroy -target per resource or remove the state entries manually with terraform state rm.

Shared ALBs. Some teams route multiple environments through a single ALB using listener rules and host-based routing. Check whether your ALB has multiple listener rules before deleting it:

aws elbv2 describe-listeners --load-balancer-arn <alb-arn> \
  --query 'Listeners[*].ListenerArn' --output text \
| xargs -I{} aws elbv2 describe-rules --listener-arn {} \
  --query 'Rules[*].[Priority,Conditions[0].Values[0]]' --output table

If only one rule exists (the default forward rule), the ALB is dedicated to this environment and safe to delete. Multiple rules mean other services depend on it — remove only the rules and target groups belonging to the orphaned service, leave the ALB intact.

Also check the CloudTrail audit log to see who last touched the environment — and when. An environment last modified 8 months ago by a developer who left the company is safe to kill. One touched last week by a CI/CD pipeline is not.

How to prevent orphans from accumulating

Tag every environment at creation with owner, created-by, and ttl. A weekly Lambda that flags services where TTL has passed costs $0 to run and surfaces every stale environment before it accumulates 6 months of charges.

Tagging convention. Apply these tags to every ECS service, ALB, target group, and NAT Gateway at creation time. Without consistent tags, the audit script above has no way to determine ownership or expected lifetime:

# Terraform example — tag every resource at creation
locals {
  env_tags = {
    owner      = "platform-team"
    created-by = "terraform"
    env-type   = "staging"          # feature | staging | prod
    ttl        = "2026-09-01"       # ISO date — when this env expires
    service    = "payments-v2"
  }
}

resource "aws_ecs_service" "this" {
  # ...
  tags = local.env_tags
}

resource "aws_lb" "this" {
  # ...
  tags = local.env_tags
}

Weekly janitor Lambda. An EventBridge rule triggers a Lambda every Monday. The Lambda lists all ECS services, checks the ttl tag against today's date, and posts a Slack message for every service that's past its TTL or has been at desiredCount=0 for more than 7 days. No auto-deletion — just surfacing. The team decides what to kill.

Fortem does this automatically: the dashboard shows per-environment cost, flags services that have been at zero desired count for more than N days, and lets you kill them from the UI without touching the AWS console. For teams managing 20+ environments, the manual audit above gets expensive in engineer time quickly.