DEV Community: Matt

Why Can't You See Per-Environment AWS Costs?

Matt — Mon, 08 Jun 2026 09:00:46 +0000

Why Can't You See Per-Environment AWS Costs?

Originally published at https://fortem.dev/blog/ecs-fargate-cost-visibility
Cost Explorer shows the total. Tags cover Fargate but miss the $90/mo per environment of ALB, NAT, and CloudWatch overhead. Here's why per-env cost is structurally hard on ECS Fargate — and what works.

What Cost Explorer actually shows you

AWS Cost Explorer is a billing tool, not an environment tool. It groups your charges by service, tag, linked account, and region. It does not know what an "environment" is. That concept lives in your head and in your Terraform code — not in the AWS data model.

When you open Cost Explorer and try to answer the per-environment question, here's what you actually get:

Total spend by service— "$4,200/mo in Fargate compute, $890 in data transfer, $660 in CloudWatch." Useful, but it's not an environment number.
By cost allocation tag— only if you've activated the tag in the Billing console AND tagged every resource. Even then, you get rows for each unique tag value, not grouped environments.
By linked account — useful for multi-account setups, but most teams run multiple environments in a single account.

The "staging environment" you have in your head is a logical bundle: 3-15 Fargate services + an ALB + target groups + a NAT Gateway + CloudWatch log groups + an ECR repo + Secrets Manager entries + an S3 bucket or two. Cost Explorer sees 10-20 unrelated line items. None of them say "staging."

The real Fargate pricing breakdown gets you the components. It doesn't get you the per-environment grouping. That's the gap.

Why per-environment cost is hard on ECS Fargate specifically

Per-environment cost is a problem on any AWS service. On ECS Fargate it's particularly bad because an environment is a bundle of services, not a single resource. And the bundle crosses the boundaries of how AWS models tagging.

Here's what tag coverage looks like for a typical 8-service staging environment:

Fargate tasks (8 services) — tag follows the ECS service. Works if you tagged the cluster.
ALB (1) — usually tagged at cluster level. Sometimes missed.
Target groups (8) — tag propagates from the ALB, not always consistent.
NAT Gateway (1-2) — lives at the VPC level. No env tag possible.
CloudWatch log groups (8-10) — tagged separately, often forgotten.
ECR repositories (3-5) — created by ECS, sometimes tagged, sometimes not.
Secrets Manager entries (5-10) — often tagged, sometimes managed at account level.

Even with a perfect tagging convention, the NAT Gateway line item is ungroupable. CloudWatch log groups might be. ECR is hit-or-miss. So your "staging" tag covers maybe 60% of the actual cost of running staging.

KEY INSIGHT: An ECS environment is a bundle of services you provision together, not a single resource. AWS pricing is per-resource. The mismatch is the root of the per-environment cost problem.

The $90/mo/env blind spot: shared overhead tags can't see

Here's the number that should be in every platform engineer's head: every ECS environment carries ~$90/mo of fixed overhead that is never captured in a tag-based report. The full breakdown is in our real Fargate pricing post; the short version:

Application Load Balancer: ~$22/mo base + LCU charges. Required for any HTTP service that needs a stable URL.
NAT Gateway: ~$33/mo per AZ (~$66/mo at 2 AZs for HA). Charges for outbound traffic from private subnets.
CloudWatch logs: $0.50/GB ingest + $0.03/GB-mo storage. Most staging envs process 20-50 GB/mo.
Secrets Manager + ECR + SSM:~$5-10/mo combined per env. Usually small, but tags don't always propagate.

The $90 is real and unavoidable.It bills whether your tasks are running or stopped. It bills on Saturday at 3am when nobody's looking. For 20 environments, that's $1,800/mo — $21,600/yr — sitting in your bill, untagged, unattributable to any single environment.

This is the number that the CFO question is really asking about. When she says "what does staging cost," she's not asking about Fargate tasks. She's asking about the full bundle. The tag-based approach gives her an answer that's missing 30-40% of the real number.

Why cost allocation tags fail in practice

Cost allocation tags are AWS's official answer to the per-resource attribution problem. They work in theory. In practice, they fail in five predictable ways.

1. Tags must be activated separately

The Environment tag on your ECS services does not show up in Cost Explorer until you activate it in the Billing console. This is a separate, one-time-per-tag step. Most teams forget. Even AWS's own documentation notes it takes up to 24 hours for tags to appear after activation.

2. Tags only work from the moment of activation

No backfill. If you activated your Environment tag on June 1, your May cost data has no environment breakdown. AWS does not compute historical attribution from newly-activated tags.

3. Inconsistencies split data silently

Env=Prod and env=prodare two different tag values in AWS's view. Environment=staging and Environment=staging-1 are two different tag values. A team that evolves its naming convention ends up with three rows of "staging" in Cost Explorer, none of which are the full picture.

4. Shared services can't be tagged per-env

A NAT Gateway is a property of a VPC, not of an environment. A CloudWatch Logs group is per-service, not per-env. ECR repos are often shared across envs. These costs are real and per-env-influenced, but no tag will ever attribute them to a specific environment.

5. Multi-account setups compound the problem

If staging runs in account A and prod runs in account B, you can't aggregate them in a single Cost Explorer view without enabling Cross-Account Cost Allocation. Even when enabled, you get a per-account view — not a per-environment view if both accounts host multiple envs.

As CloudZero's own tagging analysis puts it: "Tagging fails in shared or multi-tenant environments." The fact that CloudZero (a competitor to Fortem in some ways) writes this so plainly is telling.

What actually works: a hybrid model

The answer is not "tag harder." It's stop trying to make one mechanism solve a multi-mechanism problem. Here's the hybrid model that actually produces a usable per-environment number.

Layer 1: Tags for Fargate compute (the easy 60%)

Cost allocation tags work fine for Fargate tasks. Activate the tag, apply it consistently, and you get per-env Fargate cost. This is roughly 60% of the total per-env cost on a typical fleet.

Layer 2: A fixed overhead model for shared services (the missing 30%)

For the $90/mo/env of NAT + ALB + CW that tags can't see, allocate by a simple model: each environment gets $X fixed overhead + $Y per Fargate service running in it. The exact numbers depend on your architecture (one shared ALB vs many; one VPC NAT vs per-env NAT), but the model is straightforward and doesn't require any AWS-side changes.

Layer 3: Read-time calculation for real-time answers (the remaining 10%)

Cost Explorer data lags 24 hours. For some questions — "what did that scheduling change save us this week" — you need real-time. A read-time calculation reads your ECS task definitions, sums vCPU × $0.04048 and GB × $0.004445, and multiplies by hours running. It's how Fortem's AI skill computes the per-environment number on the fly. You can also do it with a 10-line bash script — see the next section.

None of the three layers is sufficient alone. Together, they give you a per-environment cost number that holds up to the CFO question.

The DIY version (10-line script)

If you have fewer than 10 environments and you just need a one-time per-env cost number, this bash script does the Fargate-only calculation. It reads every ECS task in every cluster, looks up vCPU and memory from the task definition, multiplies by Fargate pricing, and prints a table.

It does not include ALB, NAT, or CloudWatch — those are the "blind spot" already covered above. Add your $90/env fixed overhead to the result for a rough total.

#!/usr/bin/env bash
# Requires: aws cli, jq, bc. Pricing: us-east-1 Linux/x86 on-demand (May 2026).

set -euo pipefail
VCPU_RATE=0.04048   # $/vCPU-hour
MEM_RATE=0.004445   # $/GB-hour
HOURS=730           # hours per month

for cluster in $(aws ecs list-clusters --query 'clusterArns[]' --output text); do
  name=$(basename "$cluster")
  cost=0
  for task in $(aws ecs list-tasks --cluster "$cluster" --query 'taskArns[]' --output text); do
    td=$(aws ecs describe-tasks --cluster "$cluster" --tasks "$task" \
      --query 'tasks[0].taskDefinitionArn' --output text)
    cpu_mem=$(aws ecs describe-task-definition --task-definition "$td" \
      --query 'taskDefinition.{cpu:cpu,memory:memory}' --output text)
    cpu_units=$(echo "$cpu_mem" | awk '{print $1}')
    mem_mib=$(echo "$cpu_mem" | awk '{print $2}')
    vcpu=$(echo "scale=4; $cpu_units / 1024" | bc)
    gb=$(echo "scale=4; $mem_mib / 1024" | bc)
    rate=$(echo "scale=4; $vcpu * $VCPU_RATE + $gb * $MEM_RATE" | bc)
    cost=$(echo "scale=2; $cost + $rate * $HOURS" | bc)
  done
  printf "%-40s $%s/mo\n" "$name" "$cost"
done

Run it. Get a table. Add $90/env for the overhead you can't see. That's your per-environment number. It works for fleets up to ~10 envs.

When to graduate from DIY

The bash script is honest and useful for small fleets. It starts to hurt when:

You have 15+ environments and the script takes 20+ minutes to run
You need real-time cost (the script is a snapshot, not continuous)
You have Fargate Spot in some envs and on-demand in others (Spot needs separate calculation)
You need to track cost over time, not just right now
Multi-account fleets need aggregation

At that point, you need a system that runs continuously, not a script. Fortem is one option (it does the same calculation as the script, but continuously, with Fargate Spot handled, with multi-account support, and with a real UI). Vantage and CloudZero are others (different approaches — they focus on total AWS spend and add tags, where Fortem starts from the ECS environment and computes what tags can't see).

Whichever you pick, the question you should be asking is: _does it answer the CFO question in 5 seconds, or do I have to export a CSV and explain the methodology first?_If the latter, the tool isn't doing the job.

Questions you probably have next

Not product FAQ. The things you actually wonder about after reading.

Does AWS Cost Categories solve the per-environment problem?

Partially. Cost Categories let you group resources by tag combinations and account structure into named buckets (like "Production" or "All-Staging"). They work on top of tags — so they don't fix the untaggable shared services. Useful, but not a full replacement for the hybrid model.

Can I backfill tags to see historical per-environment cost?

No. AWS does not backfill cost allocation tags. If you activated your Environment tag on June 1, your May bill has no per-env breakdown — even if every resource had the tag. The data is gone. Activate early, before you actually need the answer.

How do I split NAT Gateway cost across environments that share a VPC?

You can't, not perfectly. Best approximations: (1) by GB data processed per env, if you have VPC Flow Logs and can attribute traffic; (2) evenly, by number of envs sharing the VPC. Neither is exact, but both are better than ignoring the cost. The fixed-overhead model (Layer 2 above) sidesteps this by treating shared services as a single per-env allocation, not as something to split.

What's the difference between Cost Categories and Cost Allocation Tags?

Cost allocation tags are resource-level labels you apply to individual resources. Cost Categories are higher-level groupings that combine tag values and account structure into named buckets. Tags are the raw input; Categories are derived views. Both depend on the underlying tag discipline.

Common questions

Specific to Fortem and the DIY approach.

Does Fortem replace AWS Cost Explorer?

No. Fortem reads your AWS account and computes per-environment cost in real time from Fargate pricing, ECS task definitions, and running task counts. It doesn't ingest your Cost & Usage Reports. Cost Explorer remains the source of truth for total AWS spend and historical billing data. Fortem answers the question Cost Explorer can't: what does each environment cost right now, and how does that change when you turn environments on and off?

How long does it take to set up per-environment cost reporting?

Reading your fleet and computing cost from Fargate pricing takes about 5 minutes via Fortem's AI skill (download .md, run in your AI agent, get the report). Manual DIY with the bash script in this article takes 30 minutes if you have AWS CLI configured. Full Fortem onboarding with continuous cost tracking is 7 business days — but the first fleet report is instant.

Can I export per-environment cost to a spreadsheet?

Yes. Fortem's discovery report is a self-contained HTML file you can open in any browser — copy the table into Sheets or Excel. The YAML file is also importable. Cost Explorer data is exportable to CSV. The bash script in this article outputs to the terminal, but piping to column -t -s $'\t' gives a paste-ready table.

Does Fortem work without any cost allocation tags?

Yes. Fortem reads cluster names, service names, and task definitions — not tags. It parses naming conventions like use1-prod-main and staging-cluster-1 to infer stages. Tagging helps with edge cases (orphaned resources, unusual names), but a clean naming convention is enough for most fleets.

Map your fleet in 5 min: fortem.dev/audit

How to Clone an ECS Environment Without Rewriting Terraform?

Matt — Sun, 07 Jun 2026 21:09:24 +0000

How to Clone an ECS Environment Without Rewriting Terraform?

Originally published at https://fortem.dev/blog/ecs-environment-clone
Cloning 15 ECS services, an ALB, RDS, and SSM params is a 12-step manual process. Terraform workspaces break at 10+ services. Here's the template approach — and a working Terraform module.

What "clone an environment" actually means

The phrase "clone this environment" lands on you from three different directions, each with its own urgency:

Compliance audit: "We need an isolated clone of EU production to test the GDPR flows." Need it by Friday. Cannot share production data.
New engineer onboarding:"Can you spin up a copy of staging so the new hire can break things in private?" Need it today. Prefer it by lunch.
QA isolation:"QA needs a clone of staging, but with the test Stripe key and a read-only RDS replica." Need it now and three more times this week.

In each case, "clone" does not mean copy one ECS service. It means copy the ensemble: 12-18 services, an Application Load Balancer with listener rules, target groups, RDS instances (or snapshots), SSM parameter paths, ECR repos, NAT Gateway routing, CloudWatch log groups, Secrets Manager entries. 15 things, each with its own copy strategy, no orchestration layer between them.

AWS has aws ecs copy-service — but it copies ONE service. Not the ALB. Not the RDS. Not the SSM params. The rest is a bundle of heterogeneous services that you hold in your head. No tool knows what belongs together except you and your Terraform.

KEY INSIGHT: An ECS environment is a bundle of services you deploy together, not a single resource. Copying a service copies one brick. Cloning a building means replicating the wiring, plumbing, and foundation too — and those live in different AWS namespaces.

The manual approach — 12 steps, 4 hours

Here's the full walkthrough. Real steps, real commands. This is what happens every time a clone request hits your Slack. The times are from doing this 20+ times.

Step 1. Copy Terraform, find-replace env names (15-20 minutes)

Open your Terraform repo. Copy the environment root module. Find environment = "production" in terraform.tfvars — change to "clone-gdpr". Then go through 8 files and change every reference to the old env name.

Step 2. Register cloned task definitions (10 minutes)

For each of the 15 services: aws ecs describe-task-definition on the source,aws ecs register-task-definitionwith a new family name. The family must include the clone env name so you don't accidentally deploy to production.

Step 3. Create the ECS cluster (2 minutes)

aws ecs create-cluster --cluster-name clone-gdpr. Trivial.

Step 4. Create 15 services (20-25 minutes)

For each service: aws ecs create-service with the cloned task def, target group ARN, subnets, security group, and service discovery namespace. If you get the VPC config wrong, the service launches in the wrong network. If you get the IAM role wrong, it launches and fails 10 minutes later.

Step 5. Copy ALB listener rules (25-30 minutes — hardest part)

The ALB has listener rules that route traffic by host header: production.api.example.com. The clone needs clone-gdpr.api.example.com. You need to:

Add a certificate for the new subdomain in ACM (20 min for DNS validation)
Create host-based routing rules for each service
Point each rule at the cloned target group
Verify priority ordering (rules are evaluated top-to-bottom; a wrong priority blocks traffic)

Steps 6-8. RDS, SSM params, Secrets Manager (20-30 minutes)

RDS: restore a snapshot or create a new instance with the same config. SSM: copy all /production/* params to /clone-gdpr/*. This is the step everyone forgets on the first attempt — the cloned services start but the ECS tasks can't read their config. They fail silently and report "running" for 5 minutes before cycling.

Steps 9-11. ECR, log groups, testing (15-20 minutes)

Update ECR repo policy if you use per-env repos. Create CloudWatch log groups for each service (ECS auto-creates them, but you want the right retention policy). Test: does service A connect to the right RDS? Does service B hit the right ElastiCache? Does the Stripe webhook fire in test mode, not production? The answer to one of these is usually "no" on the first try.

Step 12. Document the clone (10 minutes)

Write the env name, purpose, and expiry date in the team wiki. 50/50 chance this actually happens. Three months later, CTO asks "what's clone-gdpr?" and nobody remembers.

Total: 4-8 hours depending on how many things break, whether ACM decides to take 45 minutes to validate DNS, and how many SSM params you forget on the first pass.

Terraform workspaces — when they work, when they break

Terraform workspaces are the official answer for "same infrastructure, different instances." Each workspace has its own state file. When you run terraform apply, it provisions resources with the workspace name embedded in resource tags.

Workspaces work when:

All your services are identical across environments (same task definitions, same desired counts)
You use a single VPC for non-production
You don't have external services (MongoDB Atlas, Vercel, Firebase) with environment-specific connection strings

Workspaces break when:

You have 10+ services with different configurations per env.A staging service might run 2 replicas on 0.5 vCPU. A production clone of the same service runs 4 replicas on 2 vCPU. Workspaces reuse the same Terraform code, so you're writing conditional logic inside locals blocks — which defeats the purpose.
You have 20+ environments. Terraform has a hard limit of 20 workspaces per configuration. A team with 15 environments and 5 compliance clones is at the limit.
RDS cloning isn't a Terraform operation.It's an AWS operation that happens outside of Terraform's lifecycle. You run it separately, then update your Terraform variables to point at the clone. The orchestration gap is still there.

For the full picture of what Terraform handles well for ECS and what it doesn't, the Terraform-specific guide walks through the gaps in detail. Cloning is where the orchestration gap is most visible.

The template approach — 30 seconds, no Terraform

A template defines the environment once — services, configs, dependencies, env vars, secrets references, external service connections. Cloning from a template means: pick the source env → give it a name → pick a region → done.

Under the hood, the template engine calls 6 ECS APIs, copies task definitions, maps SSM parameter paths, sets up ALB listener rules, creates service connections, and points everything at the right resources. These are the same 12 manual steps from section 2. The difference is none of them are manual.

AWS Proton was supposed to be this — AWS's environment templating service. Proton let you define a CloudFormation template for an environment and deploy instances of it. It was the right idea: define once, clone as many times as you need.

Proton is deprecated October 7, 2026. The migration timeline is public. For teams with 15+ ECS environments and regular cloning needs, Fortem fills the gap — Proton's template engine, rebuilt for ECS Fargate specifically, without the CloudFormation layer.

KEY INSIGHT: The template approach works because it understands what an "environment" is — a bundle of services deployed together. The manual approach doesn't know this. You, the platform engineer, hold the bundle in your head. The script doesn't. When you clone an environment for the 30th time, the error rate converges to a function of how tired you are.

Ready-to-use: parameterized Terraform module

If you want a DIY approach that's better than fully manual but doesn't require a template engine, here's a parameterized Terraform module. It clones an ECS service — for the full env, run it 15 times with different service names.

# for a full environment clone.
# Usage: module "clone_service" { source = "./ecs-service" env = "clone-gdpr" ... }

variable "env"              { type = string }
variable "service_name"     { type = string }
variable "cluster_name"     { type = string }
variable "task_family"      { type = string }
variable "subnets"          { type = list(string) }
variable "security_groups"  { type = list(string) }
variable "container_image"  { type = string }
variable "vpc_id"           { type = string }
variable "alb_listener_arn" { type = string }

resource "aws_ecs_service" "service" {
  name            = "${var.env}-${var.service_name}"
  cluster         = var.cluster_name
  task_definition = aws_ecs_task_definition.task.arn
  desired_count   = 1
  launch_type     = "FARGATE"
  network_configuration {
    subnets          = var.subnets
    security_groups  = var.security_groups
    assign_public_ip = false
  }
}

resource "aws_ecs_task_definition" "task" {
  family                   = "${var.env}-${var.task_family}"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu    = "256"
  memory = "512"
  container_definitions = jsonencode([{
    name  = var.service_name
    image = var.container_image
    environment = [
      { name = "ENV_PREFIX", value = var.env },
      { name = "SSM_PATH",   value = "/${var.env}/${var.service_name}/" }
    ]
  }])
}

# ALB target group per service, host-based routing by env
resource "aws_lb_target_group" "tg" {
  name        = "${var.env}-${var.service_name}"
  port        = 80
  protocol    = "HTTP"
  vpc_id      = var.vpc_id
  target_type = "ip"
}

resource "aws_lb_listener_rule" "rule" {
  listener_arn = var.alb_listener_arn
  priority     = length(var.subnets) + index(var.subnets, element(var.subnets, 0)) + 30
  action { target_group_arn = aws_lb_target_group.tg.arn; type = "forward" }
  condition { host_header { values = ["${var.env}.${var.service_name}.example.com"] } }
}

This module works for standard ECS services. It requires you to parameterize your infrastructure — essentially, building a template engine by hand. For 3 services, this is clean. For 15 services, each with different vCPU/memory configs and different env vars, you end up with 15 copies of this module, each with its own values — and you've rebuilt Proton by accident.

When to stop cloning manually

At 5 environments:manual cloning is ~20 hours/year of copy-paste. The SSM params step is the bottleneck. You're still faster than setting up a template engine.

At 10 environments:manual cloning is ~40 hours/year. Terraform workspaces are hitting the 20-workspace limit. You're spending a work week per year on something a machine should do. The parameterized module above makes sense here.

At 20+ environments:you need a template engine. The module approach has become 15 near-identical copies of the same thing, each with slightly different values. You've rebuilt what Fortem ships, minus the UI, the RBAC, and the audit log of who cloned what and when.

When compliance is involved:stop immediately. A single forgotten SSM parameter — a single service pointing at production DB instead of the cloned DB — means a failed audit. Not an extra hour. A failed audit. Template engines don't forget SSM params. Human beings do.

Questions you probably have next

Not product FAQ. The things you actually wonder about after reading.

Can I clone between AWS accounts?

Yes, but it's not a single operation. Cross-account cloning requires copying ECR images across accounts (using cross-account pull permissions), restoring RDS snapshots into the target account, and copying SSM parameters manually. A template engine with cross-account IAM roles (like Fortem on the Scale plan) does it in one operation. Manually, it's 8-12 hours.

Does the clone include RDS data, or just the schema?

RDS cloning is a snapshot operation — it includes data. For GDPR compliance testing, you need the data to validate masking and access controls. For developer sandboxes, an empty schema is often enough. Template engines can do both (restore a snapshot OR create an empty instance with the same config). The manual Terraform module above creates an empty instance.

What about MongoDB Atlas / Vercel — can I clone external services too?

External services (Atlas, Firebase, Vercel, Cloudflare) have their own cloning APIs. No cloud templating engine can touch them directly — they're outside AWS. The Fortem approach stores the external service connection details as parameters and points the cloned services at them automatically. The actual clone of the Atlas cluster or Vercel project is separate.

How is cloning different from a Blue/Green deployment?

Blue/Green is deploying a NEW version of an EXISTING service alongside the old version — same env, different code. Cloning is copying an ENTIRE environment — different env, same infrastructure pattern. Blue/Green is about deployment safety. Cloning is about environment replication. The tools are different, the lifecycle is different. Don't confuse them.

Common questions

Does Fortem clone RDS instances?

Fortem clones ECS Fargate services and orchestrates the surrounding infrastructure (ALB rules, target groups, SSM parameter paths, Secrets Manager references, CloudWatch log groups). RDS cloning is a separate operation — you'd restore a snapshot or use pg_dump. Fortem handles the connection strings and env vars that point the cloned services at the right database instance.

How long does a clone take in Fortem?

The clone itself takes 30-60 seconds. Fortem copies task definitions, creates new ECS services with the same config, duplicates ALB listener rules with host-based routing for the new env name, maps SSM parameter paths, and sets IAM roles. RDS snapshots take longer (10-30 minutes depending on size) but are started by Fortem and completed by AWS.

Can I clone into a different AWS region?

Yes. Fortem's template engine supports region-aware parameters. The task definitions are region-agnostic. Services are created in the target region. RDS snapshots need to be copied to the target region first (Fortem initiates the copy). Cross-account cloning is also supported on the Scale and Enterprise plans.

What permissions does cloning need?

Fortem needs the same 6 read-only ECS permissions for discovery, plus ecs:RegisterTaskDefinition, ecs:CreateService, elasticloadbalancing:CreateRule, ssm:PutParameter, ecs:UpdateService, and iam:PassRole to create the cloned services. All scoped to the target environment's resources by IAM condition keys. The exact policy is published on the security page.

Map your fleet in 5 min: fortem.dev/audit

Fortem vs Cortex: Which Tool Actually Operates Your ECS Fleet?

Matt — Thu, 04 Jun 2026 20:48:53 +0000

Fortem vs Cortex: Which Tool Actually Operates Your ECS Fleet?

Originally published at https://fortem.dev/blog/fortem-vs-cortex
Cortex and Fortem solve different problems. Cortex is an Engineering Operations Platform for org-wide visibility. Fortem operates your ECS Fargate fleet specifically. Here's which one you need — and when to use both.

Versus

Cortex and Fortem solve different problems, even though both get called “engineering platforms.” Cortex gives you visibility across your whole stack — service catalog, scorecards, AI-driven insights. Fortem operates your ECS Fargate fleet specifically — scheduling, dev self-service, cost attribution. They're not direct competitors. Here's which one you actually need — and when the answer is “both.”

TL;DR

Cortex is a general Engineering Operations Platform — 50+ integrations, org-wide service catalog, AI-driven insights
Fortem is an ECS Fargate operations layer — scheduling, fleet visibility, dev self-service, cost, AI diagnostics
Cortex is the right tool when you have 20+ services across multiple runtimes; Fortem when you have 10+ ECS Fargate environments
Cortex pricing is sales-led (no public price); Fortem has self-serve tiers from $799/mo with 7-day onboarding
At 200+ engineers with mixed runtimes, many teams use both — Cortex for visibility, Fortem for ECS ops

What Cortex actually is

Cortex calls itself an “Engineering Operations Platform” — Y Combinator-backed, SOC 2 Type 2 and ISO 27001 certified. The product is organized around three pillars: Catalog (centralize service ownership, dependencies, and metadata across all your tools), Scorecard (production-readiness scoring and operational metrics across teams), and Workflows (golden paths, migrations, and self-service actions).

The integrations list tells the story: 50+ tools supported — GitHub, PagerDuty, Datadog, Jira, AWS, GCP, Kubernetes, Backstage, and more. ECS Fargate is one of dozens. The product is designed to sit at the center of a multi-runtime engineering org and give engineering leaders a single pane of glass.

The customer list backs this up — Affirm, Canva, O'Reilly, Skyscanner, Xero, Bumble, Tripadvisor, Outreach, BigCommerce, Rapid7, Let's Get Checked, H&R Block, Archer. Most are 500+ person companies with mixed runtimes. Cortex's target persona is an engineering leader — a VP Eng or Director of Platform — who needs to see and improve the org, not the platform engineer who needs to operate ECS.

Their tagline: “Code is no longer the bottleneck. Everything else is.” The bet is that in an AI-accelerated world, the operational layer — ownership, reliability, standards — becomes the limiting factor. Cortex sells the tooling to fix that.

What Fortem actually is

Fortem is an ECS Fargate operations layer. It connects to your AWS account via read-only IAM, sees your existing ECS clusters, and adds the operational layer that's missing: per-environment scheduling, fleet-wide visibility, developer self-service for restart/redeploy/logs, cost attribution per environment, and AI diagnostics when tasks fail.

Fortem doesn't provision infrastructure. It doesn't manage your CI/CD pipelines. It doesn't deploy code. It reads what you already have on ECS, adds operations on top, and gets out of the way. The typical onboarding is: grant IAM access, point Fortem at your clusters, set your schedules. No Terraform rewrite, no pipeline migration, no multi-month evaluation.

The target persona is a platform engineer at a 30–200 person SaaS running 10+ ECS Fargate environments — someone who is the bottleneck for their team's dev/staging workflows and needs operational control over their specific runtime, not a tool to manage org-wide engineering metrics.

The decision matrix — which one do you need?

The honest answer is that for most teams, it's not Cortex _or_Fortem — it's one of four scenarios, and only two of them are “pick one.”

Which tool do you need?

20+ services across ECS, K8s, Lambda

Persona: VP Eng / Director

Pain: "Can't see what teams are doing"

→ Cortex

Org-wide visibility > per-runtime depth

15+ ECS Fargate environments

Persona: Platform engineer

Pain: "Platform team is a bottleneck"

→ Fortem

ECS-specific ops beats broad catalog

50+ services, mostly ECS, need both

Persona: Eng leader + platform team

Pain: "Both org visibility AND ECS control"

→ Both

Different layers, complementary — not competing

Starting from scratch, no platform team, ≤10 services

Persona: Small team, no eng leadership yet

Pain: "Need basic tooling"

→ Neither

Try Backstage or humanitec first — both tools are overkill at this size

The answer is rarely "X vs Y" — it's "what's the dominant problem you're trying to solve."

KEY INSIGHT: The mistake most comparison articles make is treating Cortex and Fortem as direct competitors. They aren't. They solve different problems at different layers. Picking one over the other is a category error — the real question is “which problem is more painful for us right now?”

What Cortex does that Fortem doesn't

None of this is operational ECS management — it's org-level engineering visibility, which is Cortex's category.

Service catalog across all tools. Cortex pulls ownership and metadata from GitHub, PagerDuty, Datadog, Jira, AWS, GCP, Kubernetes, Backstage, and 40+ more. Fortem sees ECS only.
Scorecards and maturity scoring. Production-readiness grading per service per team. Trendlines over time. Compliance with internal standards. Fortem has no equivalent.
Org-wide engineering metrics. DORA metrics, MTTR across teams, deployment frequency, ownership gaps. These are Cortex's bread and butter.
Migrations. Cortex has a dedicated “Backstage migration helper” and “Break up with Backstage” content. They help teams move from spreadsheets, homegrown tools, or failed Backstage implementations.
Compliance and audit features. SOC 2 and ISO 27001 reporting, audit logs for org-level reviews. Cortex is positioned for compliance teams and eng leaders doing org-wide audits.
AI for code review and AI adoption tracking. Cortex AI Assistant, AI Impact product, Context Graph. These target the AI-coding-tool proliferation problem — measuring whether Cursor/Copilot adoption is actually moving the needle.

What Fortem does that Cortex doesn't

Cortex is a catalog. Fortem is an operator. This is the gap most teams hit when they evaluate Cortex and realize it doesn't actually do anything to their environments — it just tells them about them.

For more on what Fortem covers day-to-day, see our guide to running ECS Fargate at fleet scale.

Per-environment scheduling. Stop dev at 7pm, start at 9am. Different schedules per env, per timezone, per holiday calendar. See the full guide. Cortex doesn't operate environments — it has no scheduling concept.
Real-time ECS fleet cost attribution. Per environment, per service, per task — the actual AWS bill, not a stitched-together estimate. Cortex's integrations surface AWS data but with lag and less granularity.
Environment cloning across AWS accounts. Spin up a new dev or QA env from a known-good template, in a different account, with the right IAM, secrets, and service config. Cortex's catalog knows about services; it doesn't provision them.
Developer self-service for ECS actions. Restart, redeploy, view logs — all from a Slack command or a web UI, with RBAC scoped to the developer's own environments. No ticket to the platform team. Cortex Workflows can do this in Cortex's UI; Fortem runs these in the platform team's existing tools.
ECS-specific AI diagnostics. When a task fails, Fortem reads CloudWatch, walks the task definition, checks IAM, and proposes a fix in 8 seconds. State only changes on your click. Cortex's AI is for org-level questions; Fortem's is for “why is this task failing right now.”
Works with your existing Terraform. No migration. No state modification. No HCL parsing. Fortem reads the result of terraform apply and operates on top.

Pricing and onboarding

Cortex:custom pricing, sales-led, no public number. Expect enterprise pricing — multi-month evaluation cycles are normal. You'll talk to a sales rep, go through procurement, do a 3-6 month rollout. That's fine for an enterprise org that's already decided; it's brutal for a 50-person SaaS that needs something this quarter.

Fortem: self-serve tiers, Starter $799/mo (up to 20 environments), Scale $2,499/mo (up to 80 environments), Enterprise custom. Managed onboarding in 7 business days. No procurement cycle unless you want Enterprise.

KEY INSIGHT: For most ECS-first teams under 200 engineers, the procurement-cycle difference matters more than the feature comparison. You can be live with Fortem before Cortex has scheduled your first demo call. That's not a feature — it's a constraint on your planning horizon.

When to use both

The honest answer for large orgs: Cortex and Fortem are complementary, not competing. They sit at different layers.

Cortex's role: cross-team visibility, scorecards, migrations, compliance reporting, AI adoption tracking. The catalog of every service, the maturity scoring, the org-wide engineering metrics. The thing your eng leader wants to see at the all-hands.

Fortem's role: ECS-specific operations. Scheduling, dev self-service, cost attribution per env, AI diagnostics, fleet visibility for the platform team. The thing the platform engineer uses daily to keep the ECS fleet running.

They don't overlap. Cortex sees your services; Fortem operates your ECS environments. Some teams have Cortex surface Fortem-managed environments as a service in the catalog — read-only, no coupling required, both tools do their job.

Side-by-side at a glance

All claims verified June 2026. Cortex pricing is not public.

Aspect	Cortex	Fortem
Focus	Engineering org visibility	ECS Fargate operations
Service catalog	Yes (all tools)	ECS only
Scorecards / maturity	Yes	No
Environment scheduling	No	Yes
ECS cost attribution	Limited (via integrations)	Native
Developer self-service	Via Workflows	RBAC-scoped ECS restart/redeploy
AI for code / AI ops	Yes (Cortex AI Assistant)	Yes (ECS diagnostics)
Pricing	Custom, sales-led	Self-serve from $799/mo
Onboarding	Multi-month	7 business days
Runtime support	All (multi-runtime)	ECS Fargate only
Open source alternative	Backstage	—

Common questions

Can Cortex replace Fortem for ECS teams?

Partially. Cortex gives you a service catalog, scorecards, and org-wide engineering metrics. It does not give you per-environment scheduling, ECS-specific cost attribution, or developer self-service for restart/redeploy/logs. For ECS teams under 50 engineers, Fortem covers more of what you actually need day-to-day. For orgs with 200+ engineers across multiple runtimes, Cortex covers what Fortem doesn't.

Does Cortex support ECS Fargate scheduling like Fortem?

No. Cortex is a catalog and insights platform — it surfaces information about your services but doesn't directly operate them. Per-environment scheduling (start dev at 9am, stop at 7pm) is a Fortem feature. Cortex could integrate with Fortem to surface scheduling data, but it doesn't replace it.

How long does Cortex take to roll out vs Fortem?

Cortex is sales-led with custom pricing — typical evaluation cycles are 3-6 months including procurement. Fortem has self-serve tiers starting at $799/mo with managed onboarding in 7 business days. For teams that need something working this quarter, this difference matters more than feature comparison.

Do I need Cortex if I already have Backstage?

If your Backstage instance is maintained and adoption is real, you probably don't. Cortex explicitly positions against Backstage with a 'Break up with Backstage' migration offer — meaning teams who tried Backstage but found adoption low are Cortex's target. If your Backstage is alive and used, the calculus is different. If it's a ghost town, Cortex or Fortem (for ECS-only) are worth evaluating.

Is there overlap between Cortex's Workflows and Fortem's self-service?

Some overlap, but the targets differ. Cortex Workflows run inside Cortex's UI for migrations, service creation, and standards enforcement across all tools. Fortem's self-service runs in your platform engineer's existing tools (Slack, web) for ECS-specific actions like restart, redeploy, and log access. They're complementary, not competing. Many teams run both — Cortex for org-wide golden paths, Fortem for ECS-specific operational actions.

What if my stack is mostly ECS but I have one or two K8s clusters?

Fortem today is ECS-only. If K8s is a small fraction of your stack (1-2 clusters out of 20+ ECS environments), you probably want Fortem for the ECS majority plus K8s tooling from somewhere else. If K8s is growing fast and will become equal-to-ECS, Cortex's multi-runtime approach is a better long-term fit. The decision is really about 'how much of my world is ECS in 12 months' — if 80%+, Fortem wins; if 50/50 and shifting, Cortex wins.

If you read this, you might also want to know

If I'm comparing Cortex, shouldn't I also look at Backstage?

Yes — if your team has the appetite to run an OSS platform, Backstage is the most flexible option. Cortex explicitly positions against Backstage (they have a 'Break up with Backstage' page). The calculus: Backstage is free but requires significant platform engineering to operate. Cortex is paid but managed. Fortem is paid and managed but ECS-specific. If you want a Backstage comparison, see our future guide — this article is focused on Cortex and Fortem.

How do I convince my eng leadership that we need Cortex (or Fortem) at all?

Run a one-week audit: count how many environments exist, who's responsible for each, and how the platform team spends their time. If the answer is 'we have 30 envs and the platform team spends 60% of their time on restarts and access requests' — Fortem ROI is obvious. If the answer is 'we don't know what teams are doing or whether our services are ready' — Cortex ROI is obvious. The tool choice follows from the audit, not the other way around.

Does Fortem integrate with Cortex?

Not directly today, but the integration is straightforward — Fortem exposes its fleet state via API, Cortex can ingest any HTTP source. A team running both typically surfaces Fortem-managed environments as services in the Cortex catalog (read-only) so the eng leader sees a single pane. We're not actively building a Cortex plugin right now, but if that's the blocker for your evaluation, talk to us — small customer requests move fast on the roadmap.

### Comparing Cortex, Fortem, and Backstage for your stack? 20 minutes with a Fo

All ECS comparisons: fortem.dev/versus

How to Cut AWS Costs Without Reserved Instances

Matt — Thu, 04 Jun 2026 14:00:39 +0000

How to Cut AWS Costs Without Reserved Instances

Originally published at https://fortem.dev/blog/reduce-aws-costs-without-ri
RIs and Savings Plans are table stakes — they change how you pay, not what runs. Here are 5 methods that cut your actual AWS consumption, ranked by impact: scheduling, right-sizing, Spot, auto-stop, and killing orphans.

Guide

You've already set up Reserved Instances and Savings Plans. You checked the boxes the FinOps team sent over. Your AWS bill is still too high — and it keeps climbing. That's because RIs and Savings Plans change how you pay for compute. They don't change how much compute you actually consume. If your dev and staging environments run 24/7 while your team works 40 hours a week, no pricing model optimization will fix that. Here are five things that will.

TL;DR

RIs and Savings Plans change your pricing model — not your consumption. They're table stakes. Get them first, then keep reading.
Scheduling non-prod environments to business hours alone cuts compute spend by 60–70% — 3× the impact of a typical RI on non-prod workloads.
Right-sizing overprovisioned services costs $0 to implement and saves 10–30% immediately. Check p95 CloudWatch metrics before changing a single line of Terraform.
Fargate Spot drops compute costs ~70% for fault-tolerant workloads. Combined with scheduling, dev environments cost near-zero.
Most teams have 5–15% of environments that nobody owns. Finding and deleting 3 orphaned environments recovers $500–2,000/month.

Reserved Instances are table stakes — what's next?

If you don't have RIs or Savings Plans set up: stop reading. Go to the AWS Savings Plans console and commit to a 1-year plan for your production workloads. It's a 30–50% discount on list price for zero engineering effort. This is the lowest-hanging fruit in AWS cost optimization. Do it first.

Now here's the problem RIs don't solve: they change the price per unit, but not the number of units you consume. Your dev environments still run 168 hours a week. Your staging environment still sits idle at 3am on Sunday. Your three orphaned environments from last year's migration still bill by the second.

KEY INSIGHT: On a $10,000/month AWS bill where 70% is non-production compute: a 40% RI discount saves $2,800/month. Scheduling those same non-production environments to business hours saves $4,900/month. RI addresses the pricing model. Scheduling addresses the consumption.

$10,000/mo bill breakdown:

Non-production compute (70%): $7,000/mo

RI savings on non-prod (40%): −$2,800/mo

Scheduling savings (70% of compute hrs): −$4,900/mo

Scheduling captures 1.75× more savings than RIs on non-prod — and you can do both

Method 1: Schedule environments (60–70% savings)

There are 168 hours in a week. Your team works roughly 50 of them (Mon–Fri 9am–7pm). The other 118 hours — nights, weekends, holidays — your non-production ECS services sit idle, billing by the second. Scheduling means stopping them during off-hours and restarting them at the start of the workday.

“AWS Fargate charges $0.04048 per vCPU-hour and $0.004445 per GB-hour for Linux/x86 on-demand pricing. Every hour a dev environment runs at 3am, every minute a staging cluster spins through the weekend — that's billing against this rate.”

— AWS Fargate Pricing, verified May 2026

What to schedule:dev environments, QA, demo environments, training sandboxes, branch preview environments. Anything that doesn't need to be available at 3am on Sunday.

What NOT to schedule: production, customer-facing staging, on-call sandboxes that need 24/7 availability. Use per-environment configuration — not a single global schedule.

$1,730/mo

$515/mo

24/7 — always on

168 hrs/week

Business hours

50 hrs/week · Mon–Fri 9am–7pm

Monthly cost — 12 environments, 8 services each−70% savings

KEY INSIGHT: Scheduling costs $0 to implement — it's purely an operational change. No Terraform modifications. No new resources. Just stopping services when nobody is using them. For most teams with 10+ non-prod environments, scheduling is the single largest savings lever by a wide margin.

Implementation: tag every non-production environment, then run a scheduler (EventBridge + Lambda, or a third-party tool) that sets desired counts to 0 during off-hours and back to N at the start of the workday. Per-timezone configuration matters — your EU team starts 6 hours before your US team.

Method 2: Right-size your services (10–30% savings)

When someone first deployed that dev API service, they picked 1 vCPU and 2 GB. It made sense at the time. Six months later, the service processes one request per minute during business hours and sits idle every other second. It's paying for capacity it never uses.

How to find overprovisioned services: go to CloudWatch Container Insights → your ECS cluster → CPU Utilization and Memory Utilization per service. Look at the p95 over the last 14 days — not the average. A service with p95 CPU at 87 units on a 1024-unit allocation is using 8.5% of its provisioned capacity.

KEY INSIGHT: A common pattern: task definition requests 1024 CPU units. CloudWatch p95 over 14 days shows 87 CPU units. That service is paying for 12× more CPU than it actually needs. Right-size the task definition to 256 (p95 87 × 3 = 261 ≈ 256) and you cut its Fargate cost by 75%.

Right-sizing rule: p95 × 3, round to nearest Fargate increment

1 vCPU (1024) → p95 = 87 → 87 × 3 = 261 → right-size to 256 = −75% cost

0.5 vCPU (512) → p95 = 120 → 120 × 3 = 360 → keep at 512 = already right-sized

2 GB memory → p95 = 310 MB → 310 × 3 = 930 MB → right-size to 1 GB = −50% cost

Risk: traffic spikes can overwhelm a right-sized service. Mitigate with ECS Service Auto Scaling — set a target tracking policy on CPU utilization at 70%. The service starts small, scales up when needed, scales down at night. Right-sizing without autoscaling is gambling. Right-sizing with autoscaling is engineering.

Method 3: Fargate Spot (up to 70% discount)

Fargate Spot runs tasks on spare AWS capacity at roughly 70% off on-demand pricing, per AWS Fargate pricing (verified May 2026). The tradeoff: AWS can reclaim that capacity with a 2-minute warning. ECS handles the drain and restart cleanly — your task gets SIGTERM, 30 seconds to drain connections, then the replacement task starts on either new Spot capacity or falls back to On-Demand.

Fargate Spot vs On-Demand (0.5 vCPU + 1 GB, Linux/x86):

On-Demand: $0.024685/hr → $18.02/service/mo

Spot: $0.007872/hr → $5.75/service/mo

−68% per service

Good for Spot: CI/CD test runners, batch jobs, dev environments for individual engineers, any workload that restarts cleanly.

Bad for Spot:production, customer-facing staging, anything with an SLA. Use the capacity provider strategy to split — 80% Spot / 20% On-Demand — and interruptions don't cause downtime, just a brief shift to on-demand.

KEY INSIGHT: Spot combined with scheduling creates a compound effect: a dev service on business hours (29.8% of the week) running on Spot (32% of on-demand price) costs just 9.5% of the original 24/7 on-demand cost. A $18.02/month service drops to $1.71/month. That's not a typo.

Method 4: Auto-stop idle environments

This is different from scheduling. Scheduling is predictable — environments stop and start on a fixed calendar. Auto-stop targets environments that _should_be in use but aren't. An environment that hasn't seen a deployment in 10 days, has zero active connections, and generates no application logs — it's probably abandoned, even if someone forgot to tell you.

Implementation:monitor CloudTrail for ECS service updates (deployments) and CloudWatch Logs for application activity. If an environment has zero deploy events and zero log activity for a configurable threshold — say 6 consecutive days — automatically set its ECS service desired counts to 0. Send a Slack notification: “use1-dev-experiment stopped — idle 6 days. One-click restart here.”

KEY INSIGHT: The organizational question is harder than the technical implementation: who decides what “idle” means? 3 days? 7 days? 14 days? Define the policy with your team leads, document it, and give developers a 24-hour warning before auto-stop kicks in. The technical part is a Lambda function. The organizational part is a Slack thread.

Best practice: start conservative. 14-day idle threshold, 48-hour warning. Measure how many environments get auto-stopped and how many get immediately restarted. Tighten the threshold over time as the team builds trust in the process.

Method 5: Kill orphaned environments

While auto-stop handles the recently-idle, this method handles the permanently-abandoned. Every team that's been running ECS for more than a year has environments that nobody claims. They were spun up for a migration, a hackathon, a departed engineer's experiment. Nobody deploys to them. Nobody knows who owns them. They just bill — quietly, every month.

“Most teams we work with find 5–15% of their environments are completely abandoned — no deploys in 6+ months, no identifiable owner, no access logs. Three orphaned environments at $170/month each = $6,120/year of compute serving zero requests.”

— Fortem fleet audit of 100+ ECS environments across 12 teams, 2026

Audit approach: pull the last deployment timestamp per environment. Cross-reference with the team directory (who owns what?). Environments with no deploy in 30+ days and no active team owner go on a review list. The platform team reviews the list, confirms abandonment, and deletes the infrastructure.

KEY INSIGHT: Finding orphaned environments is a one-time audit that costs $0 and takes an afternoon. The savings compound every month. For a team with 50+ environments, the most common outcome is 2–5 orphans worth $500–$2,000/month. That's $6,000–$24,000/year — from a one-time afternoon of work.

Comparing the 5 methods

Stack these in order. Start with the highest-impact, lowest-effort method and work down. Don't try to implement all five at once — that's how cost optimization projects die in committee. Do method 1 this week. Method 2 next week. See the savings compound.

Method	Impact	Effort	Risk	What it means
1. Scheduling	60–70%	Low	None	Dev/staging envs stop outside business hours (50 hrs/wk instead of 168). Zero Terraform changes.
2. Right-sizing	10–30%	Medium	Low	Drop task CPU/memory to p95 + 50% headroom. One-time TF change per service.
3. Fargate Spot	Up to 70%	Low	Medium	Switch capacity provider to FARGATE_SPOT. 2-min interruption notice from AWS.
4. Auto-stop idle	Variable	Medium	Low	Stop any env not deployed to or accessed in 6+ days. CloudTrail + Lambda.
5. Kill orphans	$500–2,000/mo	Low	None	Find envs with no owner and no deploys in 30+ days. Delete them.

$5,765/mo· $69,180/yr

Combined impact on a $10,000/mo fleet: RI (−$2,800) + Scheduling (−$4,900) + Right-sizing (−$1,050 on remaining) + Spot on eligible dev envs (−$815). Total: $10,000 → $4,235/mo. 57% reduction without touching a single Reserved Instance.

The specific numbers depend on your fleet composition. A team with 80% non-prod compute will see scheduling dominate. A team where everything runs at steady utilization will see right-sizing and Spot carry the weight. The framework is the same regardless: reduce consumption first, then optimize the pricing model on what remains.

Common questions

Do I need to change my Terraform to implement any of this?

Not for scheduling or auto-stop — those are operational concerns handled outside Terraform. Right-sizing requires updating task definition files. Spot requires changing capacity provider strategy in your ECS service definition. Killing orphans requires no Terraform changes. Most teams start with scheduling (zero Terraform impact) and right-sizing (the small Terraform change with the second-largest impact).

What happens to databases when an environment is scheduled off?

ECS scheduling stops and starts compute tasks — it does not touch RDS, ElastiCache, or any other stateful services. Your databases keep running and billing. If you want to stop databases too, you need separate scheduling for each service type. Most teams leave databases running 24/7 and only schedule compute — the cost difference is usually worth the operational simplicity.

Is Fargate Spot safe for staging environments?

It depends on what staging is used for. If staging runs automated tests and can tolerate a 2-minute interruption, Spot is fine. If staging hosts customer demos or is expected to be reliably available during business hours, use On-Demand for those specific services. The capacity provider strategy lets you split — 80% Spot / 20% On-Demand — so interruptions don't cause downtime.

How do I find which environments are idling?

Pull the last task run timestamp from CloudWatch Logs Insights — any service with no log events in the last 14 days is a candidate. Cross-reference with your deployment records (last deploy date). Environments with no deploys in 30+ days and no active owner are safe to stop. Fortem surfaces last deploy time, last access time, and owner for every environment — turning a 2-hour audit into a 2-minute filter.

### Stop optimizing the pricing model. Start optimizing what runs. Fortem automa

See your real cost: fortem.dev/ecs-cost-calculator

Fortem vs Flightcontrol: ECS Fleet Management vs Single-App PaaS

Matt — Thu, 04 Jun 2026 14:00:00 +0000

Which ECS Platform Should You Choose: Fortem or Flightcontrol?

Originally published at https://fortem.dev/blog/fortem-vs-flightcontrol
Flightcontrol is the right tool for 1–3 apps on AWS. Here's exactly where it stops making sense — and where the pricing math breaks.

Versus

Flightcontrol and Fortem solve different problems. One of them is the wrong tool for you — and figuring out which one depends on how many environments you run, not which features look better in a comparison table. This article explains what each product actually does, where the pricing math breaks, and how to tell which side of the line you're on.

TL;DR

Flightcontrol is a PaaS for deploying apps to your AWS account — excellent for 1–3 services.
Per-service pricing ($30/service on Business) breaks at 10+ environments.
Flightcontrol has no environment scheduling, no fleet visibility, no developer self-service.
Fortem is not a deployment tool — it's a fleet operations layer for teams already on ECS.
At 20 environments × 8 services, Flightcontrol Business costs $4,897/mo vs Fortem plan at $2,499/mo flat.

What Flightcontrol actually is (and what it's not)

Flightcontrol is a managed PaaS that deploys your applications to your own AWS account. ECS, Lambda, static sites, RDS — they handle the infrastructure so your team doesn't have to. The value proposition is simplicity: connect your GitHub repo, define your services, and Flightcontrol manages the AWS complexity.

It works well for exactly what it was designed for. A startup with 2–3 applications and a small engineering team that doesn't want a dedicated platform engineer gets a lot of value from Flightcontrol. Fast setup, good support, and AWS without the AWS complexity.

What it doesn't market itself as, and isn't designed for: managing a fleet of 20+ environments across multiple teams, scheduling dev environments to stop at night, giving developers self-service access to restart their own environment without Slack messages, or showing you fleet-wide cost and activity data in one screen.

The pricing math at scale

Flightcontrol charges per service, not per environment. This is the right model for small deployments — you pay for what you use. It becomes the wrong model at fleet scale.

Flightcontrol pricing (verified May 2026):

Starter: $97/mo, 5 services included + $20/service overage

Business: $397/mo, 10 services included + $30/service overage

The math at 20 environments × 8 services = 160 billable services:

Starter: $97 + 155 × $20 = $3,197/mo

Business: $397 + 150 × $30 = $4,897/mo

Fortem plan: $2,499/mo flat for up to 80 environments

Monthly cost — Flightcontrol Business vs Fortem

$547

$2,499

5 envs

$2,197

$2,499

10 envs

$4,897

$2,499

20 envs

$11,297

$2,499

50 envs

Flightcontrol Business

Fortem plan ($2,499 flat)

Crossover: ~7 environments

KEY INSIGHT: At 7 environments × 8 services = 56 services, Flightcontrol Business ($397 + 46 × $30 = $1,777/mo) and Fortem plan ($2,499/mo) are roughly equivalent. Above that breakpoint, Fortem is cheaper. Below it, Flightcontrol is.

For more on managing the ECS cost side of this equation, see How to Cut AWS ECS Fargate Costs by 65%.

What Flightcontrol doesn't do (and says so)

Flightcontrol's product is honest about its scope. The gaps below aren't criticisms — they're category differences.

No environment scheduling. Environments run 24/7. There's no built-in way to stop all services in a dev environment at 7pm and restart them at 9am. If you want this, you'd build it yourself with EventBridge.
No fleet-wide visibility. If you have 15 environments across 3 teams, there's no single screen showing you all of them — their status, last deploy, activity, cost attribution, who owns them.
No developer self-service. When a developer's environment gets stuck, there's no “restart my environment” button. They file a ticket or message the platform team.
No environment cloning. Spinning up a new dev or QA environment from a known-good template requires manual work, not a UI action.

When Flightcontrol is the right choice

≤3 applications, ≤5 services each — you're well within the pricing model where it works in your favor.
Moving off Heroku or Railway to AWS — Flightcontrol is the path of least resistance. You get AWS's infrastructure without AWS's complexity overhead.
Team without a dedicated platform engineer — the managed deployment model saves real time and eliminates a category of infrastructure decisions.
You need deployment management more than fleet management — your primary problem is getting code to AWS, not operating environments once they're running.

If this is you, use Flightcontrol. Their product is well-designed for this use case, their support is responsive, and the setup time is genuinely low.

When Fortem is the right choice

10+ environments across your fleet — dev, staging, QA, demo, per-team, per-feature. At this scale, per-service pricing breaks and fleet visibility becomes operationally necessary.
Dev/staging environments running 24/7 with no after-hours demand — see the cost breakdown on what that actually costs before you decide it's too small to fix.
Developers filing tickets to restart their own environment — that friction compounds. Every restart request is 15–30 minutes of a platform engineer's time that should be self-service.
You're already running your own Terraform and don't want a tool that manages your infrastructure — Fortem connects to your existing ECS clusters without taking over provisioning.
You need fleet visibility: all environments, their status, cost, owners, and last deploys in one view — something you currently piece together from CloudWatch, Cost Explorer, and Slack threads.

KEY INSIGHT: Fortem is not a deployment tool. It sits on top of your existing ECS infrastructure — your Terraform, your CI/CD pipelines, your task definitions. If you're evaluating whether to replace deployments, that's a different question.

Migration path from Flightcontrol to Fortem

Two paths depending on what you want to change.

Path 1 — Run both in parallel

Flightcontrol continues handling deployments. Fortem connects to the same ECS clusters and handles fleet operations — scheduling, visibility, self-service restarts. No migration of deployment pipelines needed. This is the lower-risk path for teams that are happy with Flightcontrol's deployment experience but need fleet management on top of it.

Path 2 — Full migration

Move deployment pipelines from Flightcontrol to GitHub Actions or your existing CI/CD. Fortem handles fleet operations.

Week 1: Connect Fortem to your clusters via IAM

Weeks 2–4: Migrate deployment pipelines from Flightcontrol

Weeks 4–6: Parallel operation before fully deprecating Flightcontrol

Fortem onboarding doesn't require changes to task definitions, ECS cluster config, or Terraform. It reads your existing infrastructure.

Common questions

Does Fortem replace Flightcontrol's deployment pipelines?

No. Fortem is a fleet operations layer — it manages running environments (scheduling, visibility, self-service, cost tracking) but does not deploy code or manage build pipelines. Many teams run Flightcontrol for deployments and Fortem for fleet ops simultaneously. If you eventually want to replace Flightcontrol's deployment pipelines, that's a separate decision typically involving GitHub Actions or AWS CodePipeline.

Can I connect Fortem to environments that Flightcontrol currently manages?

Yes. Fortem connects to your ECS clusters directly via your AWS account. It doesn't care how those clusters were provisioned — Flightcontrol, Terraform, manual console setup. As long as the ECS cluster exists, Fortem can read and manage it.

What's the pricing break-even between Flightcontrol Business and Fortem?

At 8 services per environment, the break-even is around 7 environments. Below that, Flightcontrol Business ($397/mo base) is cheaper. Above it, Fortem plan ($2,499/mo flat for up to 80 environments) is cheaper. At 20 environments, Flightcontrol Business comes to $4,897/mo versus Fortem's $2,499/mo.

Does Fortem handle deployments — pushing new container images to ECS?

No. Fortem manages environment state — starting, stopping, scheduling, fleet visibility — but image builds and deployments happen in your CI/CD pipeline (GitHub Actions, CircleCI, AWS CodePipeline). Fortem sees the results of deployments (service status, running task count, last deploy time) but doesn't initiate them.

Do I need to rewrite any infrastructure to add Fortem?

No. Fortem reads your existing ECS cluster configuration and connects via your AWS account credentials. No changes to task definitions, Terraform, or CloudFormation. The typical onboarding is: grant IAM access, point Fortem at your clusters, set your schedules.

If you read this, you might also want to know

What if I have both 1-app side projects AND a 30-env production fleet?

You might use both. Flightcontrol for the 1–3 app side projects where simplicity wins, Fortem for the main fleet where per-service pricing breaks. They don't compete — they address different scales. The cost question is whether the ops overhead of two tools is worth the savings.

Can I run Fortem alongside my existing Terraform CI/CD?

Yes. Fortem reads AWS resources after Terraform provisions them — no HCL parsing, no repo access, no state modifications. Your terraform apply still provisions infrastructure. Fortem adds the operations layer on top without touching your pipeline.

How do I calculate whether per-environment or per-service pricing is cheaper for my fleet?

Count your services, multiply by the overage rate, and compare to the flat rate. Example: 30 envs × 8 services = 240 services. On Flightcontrol Business: $397 + (240–10) × $30 = $7,297/mo. On the Fortem plan: $2,499/mo flat. The crossover is at roughly 7 services per environment.

### Running 10+ ECS environments? Talk to a Fortem engineer. We'll go through yo

All ECS comparisons: fortem.dev/versus

AWS Copilot is Deprecated: Alternatives for ECS Fargate Teams

Matt — Thu, 04 Jun 2026 13:59:58 +0000

AWS Copilot is Deprecated: Alternatives for ECS Fargate Teams

Originally published at https://fortem.dev/blog/fortem-vs-aws-copilot
AWS Copilot CLI reaches end-of-support June 12, 2026. Your ECS services keep running — but here's what breaks, what to do next, and how to migrate.

Timely

AWS Copilot CLI reaches end-of-support on June 12, 2026. If your team uses it to deploy ECS Fargate services, here's what that actually means for you — what breaks, what doesn't, and what the migration paths look like.

TL;DR

AWS Copilot CLI is end-of-support June 12, 2026 — no security patches or updates after that date
Your existing ECS services keep running — Copilot provisions them but doesn't run them
Copilot was a deployment CLI, never a fleet management tool
Two paths forward: migrate to raw Terraform + CI/CD, or add Fortem for fleet operations
AWS is deprecating both Copilot (June 12) and Proton (Oct 7) — they're exiting managed ECS tooling

What AWS Copilot was (and wasn't)

AWS Copilot is an open-source CLI that simplified deploying containerized applications on ECS Fargate. You defined your workloads in a manifest file — Load Balanced Web Service, Backend Service, Scheduled Job — and Copilot generated the CloudFormation, set up the ECS cluster, configured the load balancer, and handled deployments. For a team that wanted to get on Fargate without writing raw CloudFormation, it was genuinely useful.

What it didn't do: manage a fleet of environments. There was no way to see all your environments in one view, schedule dev environments to stop at night, give developers self-service access, track costs per environment, or clone an environment for QA. Copilot solved deployment. Fleet operations were always out of scope.

It was also free — open source, no subscription, you paid only your AWS bill.

What breaks on June 12, 2026

No new CLI releases. No bug fixes, no feature updates. The binary you have is the last version.
No security patches. If a vulnerability is found in the Copilot CLI after June 12, it won't be patched.
No AWS support. Open a support ticket referencing Copilot and you'll be redirected to community forums.
Copilot commands may drift. Copilot calls AWS APIs. As those APIs evolve, Copilot commands that worked today may fail without notice.

What doesn't break: your ECS services. Copilot creates ECS clusters, services, and task definitions — but those resources live in your AWS account. They'll keep running after Copilot is gone. The risk is operational: you lose the ability to redeploy, update, or troubleshoot using Copilot commands.

KEY INSIGHT: The infrastructure Copilot provisioned belongs to your AWS account, not to AWS Copilot. Your services won't go down on June 13. What you lose is the workflow for managing them going forward.

AWS is exiting managed ECS tooling

Copilot isn't an isolated case. AWS Proton deprecation (October 7, 2026) — a managed service for deploying multi-service applications — is also on the calendar. Two managed ECS developer tools, deprecated within months of each other.

The pattern is consistent with how AWS thinks about their platform: invest in primitives (ECS, Fargate, CloudFormation, EventBridge) and let third-party tooling handle the developer experience layer. AWS isn't going to maintain a fleet management UI for you. That's not their business.

For teams that relied on Copilot, this means the durable path is either raw infrastructure primitives (Terraform, CDK) or a third-party tool with a vendor committed to ECS Fargate long-term — not another AWS managed tool that might be deprecated in 18 months.

Migration option 1 — Terraform + CI/CD

The DIY path: take the CloudFormation that Copilot generated and convert it to Terraform modules. Replace Copilot deployments with GitHub Actions workflows or AWS CodePipeline.

What you gain: full control, no tool dependency, infrastructure you understand completely.
What you lose: the convenience layer Copilot provided — copilot deploy, copilot svc logs, copilot env init.

Right for: teams with a strong Terraform culture, fewer than 10 environments, and a platform engineer who has time for the migration.

Rough timeline: 2–4 weeks to migrate a typical 3–5 service app. Most of the time is spent understanding what Copilot generated and translating it into Terraform idioms.

For a deeper guide on the Terraform path, see Managing ECS Fargate environments with Terraform (coming soon).

Migration option 2 — Fortem

Fortem connects to your existing ECS clusters — whether Copilot provisioned them or not. No rewrite of infrastructure required. You grant IAM access, Fortem reads your clusters, and you're operational in 7 business days.

What Fortem adds that Copilot never had:

Environment scheduling— stop dev environments at 7pm, restart at 9am, cut idle compute costs 60–70%
Fleet visibility— all environments across accounts and regions in one view
Developer self-service— restart services, view logs, flush state without AWS Console access
Environment cloning— spin up QA copies from a known-good template

What Fortem doesn't do: Copilot's deployment workflow. Image builds and copilot deploy equivalents stay in GitHub Actions or CodePipeline. Fortem is the fleet operations layer, not the deployment pipeline.

Right for: teams with 10+ environments that need fleet management, not just a deployment CLI replacement.

Feature	AWS Copilot	Fortem
ECS deployment	✓ via copilot deploy	Via your CI/CD pipeline
Environment scheduling	✗ Not supported	✓ Built-in
Fleet visibility	✗ Not supported	✓ All envs in one view
Developer self-service	✗ Not supported	✓ Built-in
Environment cloning	✗ Not supported	✓ Built-in
Cost attribution per env	✗ Not supported	✓ Built-in
Tool cost	Free (open source)	$799–$2,499/mo
Maintenance status	Deprecated June 12, 2026	Actively maintained

Common questions

What happens to my ECS services when Copilot support ends?

Nothing, immediately. Your ECS clusters, services, and task definitions live in your AWS account — they don't depend on the Copilot binary to keep running. What you lose is the ability to use Copilot commands to redeploy, update, or debug going forward. The services run; the tooling to manage them is what becomes unsupported.

Can I continue using Copilot after June 12, 2026?

Technically yes — the binary still works until AWS APIs it relies on change. But you'll be running unsupported software with no security patches and no bug fixes. For most teams, the risk grows over time rather than appearing on day one. Plan to migrate within 30–60 days of the EOL date.

How do I export my Copilot app configuration to Terraform?

Copilot stores its generated CloudFormation in your AWS account. Run aws cloudformation get-template --stack-name [your-copilot-stack] to retrieve the templates, then use a tool like cf2tf to convert them to Terraform HCL. Expect manual cleanup — the generated Terraform won't be idiomatic but it will be functional.

Does Fortem replace what Copilot did for deployments?

No. Fortem is a fleet operations layer — it manages running ECS environments (scheduling, visibility, self-service, cost tracking) but doesn't handle image builds or deployments. Replace Copilot's deployment workflow with GitHub Actions or AWS CodePipeline. Fortem handles what comes after: operating the environments those deployments run in.

Why is AWS deprecating both Copilot and Proton within months of each other?

AWS's long-term strategy focuses on infrastructure primitives — ECS, Fargate, CloudFormation, EventBridge — not on managed developer experience tooling. Both Copilot and Proton were attempts to build convenience layers on top of those primitives. The deprecations signal that AWS expects the developer experience layer to come from third-party tools, not from AWS itself.

### Migrating off Copilot? We've helped teams move from Copilot to Terraform + F

All ECS comparisons: fortem.dev/versus

It's Friday at 6pm. Your Developer Can't Restart Staging Without You.

Matt — Thu, 04 Jun 2026 13:59:20 +0000

It's Friday at 6pm. Your Developer Can't Restart Staging Without You

Originally published at https://fortem.dev/blog/ecs-staging-self-service
Platform engineers become the single point of failure for staging ops when developers have no safe, scoped way to act. Here's how to fix it with ECS environment RBAC.

The 6pm Slack message

It's Friday, 6:47pm. You're at dinner. Your phone buzzes.

Jamie6:47 PM

hey — staging is down, orders-api won't start. i have a smoke test to finish before the monday deploy. can you take a look?

You open the AWS Console on your phone. Fargate console on mobile is a special kind of awful — tiny text, nested dropdowns, a task definition ARN you have to scroll sideways to read. You find the service, stop the broken task, wait for it to restart. The new task fails to start too. You check the CloudWatch logs. Missing environment variable. You update the task definition, force a new deployment. Fifteen minutes. By the time the service is healthy, dinner is cold and you've lost the conversation.

Monday, Jamie finishes the smoke test in 20 minutes and the deploy goes out fine.

Jamie didn't need you to debug a config issue. Jamie needed to restart a service. The entire incident was a permission problem — and it happens on most teams with 10+ environments, at least twice a week.

Why this keeps happening

AWS IAM doesn't have environment-scoped permissions for ECS. You can grant someone ecs:UpdateService— but that's access to every ECS service in the account, including production. You can try to scope it by resource ARN, but when your environments have 15 services each, maintaining those policies manually becomes its own full-time job.

So most platform engineers made the only rational decision available to them: they kept the keys and became the gatekeeper. Developers file a Slack request, platform engineer handles it, developers wait.

The platform engineer didn't choose to be a deployment gatekeeper. They became one because the alternative — handing over AWS Console access — was genuinely risky. The right answer is a permission layer that doesn't exist in native AWS.

The cost is invisible because it's spread across the week in small increments. A Slack ping here, a 15-minute console task there. But count the interruptions in a month: 3–8 per week for a mid-sized team. Each one breaks a flow state that takes 20 minutes to rebuild. Each Friday or weekend message is unpaid on-call work for a non-incident.

The 5 ops that cause 80% of interruptions

Most platform engineers, when they audit their staging-ops interruptions, find the same five actions accounting for nearly all of them:

1.

Restart a crashed or stuck service. A task died, maybe due to a failed health check or OOM. The developer knows it — they just can't restart it.
2.

Redeploy the latest image. A new build was pushed to ECR. The developer wants to pick it up in staging without waiting for the next CI run to trigger a deployment.
3.

Read logs. The service is behaving strangely. The developer needs to tail CloudWatch — not navigate five levels of AWS console to get there.
4.

Flush a Redis cache. Bad data got written. A key needs to be cleared so the service reads fresh state. One operation, one line of code if they had access.
5.

Run a one-off task. A database migration, a data backfill, a cleanup script. Not a deployment — a single-run task against staging data.

None of these require infrastructure knowledge. None of them should require a platform engineer.

Why raw AWS Console access is the wrong answer

The obvious first instinct is: just give them limited AWS access. Create a developer IAM role with read and restart permissions.

In practice, this goes wrong in predictable ways:

IAM doesn't scope ECS permissions by environment — it scopes by account, region, and ARN. A policy that allows restarting staging services also allows restarting production services in the same account.
ARN-scoped policies break every time a service is renamed, a new environment is added, or an account is restructured. Someone has to maintain them.
AWS Console access gives visibility into things developers shouldn't see: secret ARNs, network config, IAM role names. Not a security catastrophe, but not ideal.
There's no audit trail per action. CloudTrail tells you which IAM user ran which API call — but not why, from what context, or what the environment state was before and after.

The right answer isn't broader AWS access — it's a permission layer that understands environments.

How Fortem solves it

Fortem's self-service layer gives each developer a scoped view of environments they own. You assign ownership in the dashboard — takes about 15 minutes for a typical team. From that point, developers log in via SSO and see only their environments.

Within their assigned environments, here's exactly what they can and cannot do:

Action	Can do?	Notes
Restart a service	✓ Yes	Scoped to assigned environments only
Redeploy to latest image	✓ Yes	Uses the image already in the task definition
View / tail CloudWatch logs	✓ Yes	Real-time and historical
Flush Redis keys (pattern-matched)	✓ Yes	Pattern input required — no wildcard delete
Run one-off ECS tasks	✓ Yes	From pre-approved task definitions only
Pause / resume environment schedule	✓ Yes	Operator permission required
Touch any production resource	✗ No	Prod is a separate environment class; disabled by default
Access AWS credentials or secrets	✗ No	Fortem never exposes secrets to the UI
Modify task definitions or IAM roles	✗ No	Infrastructure config is platform-team only
See environments not assigned to them	✗ No	Environment scope is enforced server-side

The key point is the last four rows. Production is off. AWS credentials are off. Infrastructure config is off. The scope boundary is enforced server-side — it's not just UI hiding.

No IAM changes required on your end. Fortem uses a cross-account role with the minimum permissions needed to perform ECS operations. Your developers authenticate via SSO — they never interact with AWS directly.

Before and after

Situation	Before	After
Staging service crashes Friday at 6pm	Developer Slacks platform team. Waits 2–14 hrs for someone to restart it.	Developer clicks Restart in Fortem. Service is up in 40 seconds.
New engineer needs to read staging logs	IAM ticket to security team. 1–3 business days. Maybe AWS Console access.	Platform engineer assigns log-viewer role in Fortem. Done in 2 minutes.
QA needs to flush Redis cache to test a bug	Blocked. Can't flush Redis without console access. Creates a ticket.	QA flushes specific key pattern in Fortem without touching AWS.
Developer wants to redeploy their branch to staging	Asks platform engineer. Gets queued. Usually done same day, sometimes tomorrow.	Developer triggers redeploy from Fortem. 3 clicks.
SOC 2 auditor asks who restarted staging last Tuesday	CloudTrail search, cross-reference IAM user, 2 hours of work.	Filter by environment and date in Fortem audit log. 30 seconds.

The most common feedback from platform engineers after turning on self-service: the first week felt like they gave something up. The second week, they realized the thing they gave up was being woken up on Friday night.

What gets logged

Every action through Fortem creates an audit entry: who, what environment, what action, what time, what the service state was before and after.

Audit log — staging / orders-api

Fri May 17 18:52  jamie@acme.co         Service restart         staging   HEALTHY after 38s
Fri May 17 16:30  sam@acme.co           Redeploy (latest)       qa-eu     Deployed sha:a3f2b1
Thu May 16 09:14  kai@acme.co           Redis flush             staging   Pattern: session:\* — 4 keys deleted

When your SOC 2 auditor asks who restarted staging last Tuesday, this is the answer — filtered and exported in under 30 seconds. You don't need to cross-reference CloudTrail against IAM users against a timezone conversion.

Audit retention is configurable: 90 days on the Fortem plan, 365 days on Enterprise.

Map your fleet in 5 min: fortem.dev/ai-onboarding

ECS Multi-Environment Strategy: What Breaks at 10 That Worked Fine at 3

Matt — Thu, 04 Jun 2026 13:59:17 +0000

What Breaks When You Scale Past 10 ECS Environments?

Originally published at https://fortem.dev/blog/ecs-multi-environment-strategy
Naming conventions, cluster structure, and the five AWS limits that surface when environments scale past 10. Written by platform engineers running 100+ ECS environments.

Three ECS environments are manageable with AWS-native tooling and reasonable discipline. Ten environments expose every naming shortcut, every IAM approximation, and every missing inventory tool. This guide covers what actually changes — and what to get right before you hit the wall.

The overhead nobody puts in the spreadsheet

When engineers estimate ECS environment costs, they calculate compute: vCPU hours, memory hours, maybe RDS. What they miss is the fixed overhead that exists before a single container runs.

Every environment needs its own ALB, NAT Gateway (ideally in each AZ for HA), and CloudWatch log groups. These costs are flat — they don't scale with usage, they don't go away when you stop tasks at night, and they don't appear on the compute line in Cost Explorer.

ResourceMonthly costNotes — Application Load Balancer: $22/mo$0.0225/hr base + $0.008/LCU-hr

NAT Gateway (2 AZs)~$66/mo$0.045/hr × 2 AZs + $0.045/GB data

CloudWatch log retention$3–15/moDepends on log volume + retention days

SSM parameters, ECR storage$1–5/moUsually negligible, adds up at scale

Total fixed overhead$85–100/moBefore first task runs

At 3 environments, that's ~$300/month in overhead — noticeable but manageable. At 10 environments it's $850–1,000/monthbefore a single task runs. At 20 environments it's a $1,700–2,000/month line item that doesn't appear anywhere obvious.

What you can actually do about it

Share the ALB across non-prod environments using host-based routing rules (one ALB, multiple environments via different hostnames). This eliminates per-environment ALB cost for dev/staging. NAT Gateway is harder to share cleanly — teams that care about NAT cost switch non-prod environments to public subnet placement with no NAT. Slightly less secure, meaningfully cheaper. Prod always gets its own ALB and NAT.

Naming: the one convention that rules everything

At 3 environments you can get away with ad-hoc names. At 10 you can't — because every AWS resource name is a billing dimension, an IAM scope, and a CloudWatch filter. Inconsistent names mean you can't attribute cost, can't write scoped IAM policies, and can't build dashboards without a lookup table.

The convention that works at fleet scale encodes three things in every resource name: region, account (or account group), and environment name. In this order:

{region_short}-{account}-{envname}

# Examples
use1-prod-main         # us-east-1, prod account, primary production env
use1-prod-stg1         # us-east-1, prod account, staging env
usw2-dev-dev1          # us-west-2, dev account, first dev env
usw2-dev-qa1           # us-west-2, dev account, QA env
usw2-dev-demo          # us-west-2, dev account, demo env

This prefix becomes the root of every resource name in that environment. One Terraform local generates everything:

locals {
  # e.g. "use1-prod-main" or "usw2-dev-qa1"
  env_prefix = "${var.region_short}-${var.account}-${var.envname}"
}

# ECS cluster
resource "aws_ecs_cluster" "main" {
  name = local.env_prefix
  # → "use1-prod-main"
}

# ECS service (env already in cluster name — service is just the component)
resource "aws_ecs_service" "api" {
  name    = "api"
  cluster = aws_ecs_cluster.main.id
}

# Task definition family (global per account — must carry full prefix)
resource "aws_ecs_task_definition" "api" {
  family = "${local.env_prefix}-api-td"
  # → "use1-prod-main-api-td"
}

# SSM paths (hierarchy enables per-service IAM scoping)
resource "aws_ssm_parameter" "db_host" {
  name = "/${local.env_prefix}/api/DB_HOST"
  # → "/use1-prod-main/api/DB_HOST"
}

# IAM roles (global per account — carry full prefix)
resource "aws_iam_role" "task_role" {
  name = "${local.env_prefix}-api-task-role"
  # → "use1-prod-main-api-task-role"
}

# CloudWatch log group
resource "aws_cloudwatch_log_group" "api" {
  name              = "/ecs/${local.env_prefix}-api"
  retention_in_days = var.log_retention_days
  # → "/ecs/use1-prod-main-api"
}

Why SSM paths matter specifically: the hierarchy /use1-prod-main/api/* lets you write a single IAM policy statement that gives the API task access to exactly its own secrets — nothing else:

{
  "Effect": "Allow",
  "Action": ["ssm:GetParameter", "ssm:GetParameters"],
  "Resource": "arn:aws:ssm:us-east-1:123456789012:parameter/use1-prod-main/api/*"
}

Flat SSM names (USE1-PROD-MAIN-API-DB_HOST) lose this entirely. You end up with a wildcard Resource: "*" or a list of 40 individual parameter ARNs. One team's migration from flat to hierarchical SSM naming took two weeks and three deployment freezes.

ResourcePatternExample

ECS Cluster{env_prefix}use1-prod-main

ECS Service{service}api (inside cluster)

Task Def Family{env_prefix}-{service}-tduse1-prod-main-api-td

SSM Path/{env_prefix}/{service}/{PARAM}/use1-prod-main/api/DB_HOST

IAM Task Role{env_prefix}-{service}-task-roleuse1-prod-main-api-task-role

Log Group/ecs/{env_prefix}-{service}/ecs/use1-prod-main-api

Target Group{service}-{envname}-tgapi-main-tg ⚠ 32 chars

Service Connect NS{envname}.localmain.local

The 32-character ALB target group limit

This is the hardest constraint in the naming stack. A target group named use1-prod-main-payments-api-tg is 30 characters — just inside the limit. Add a longer service name and you blow it. The fix: drop the region and account from target group names (they're already implied by the ALB, which lives in one region and one account), and use only envname + service + tg. Plan your abbreviation table before your first service, not after your fifteenth.

Enforce naming in Terraform with a variable validation block — reject envnames that don't match your pattern before any resource gets created:

variable "envname" {
  type = string
  validation {
    condition     = can(regex("^[a-z][a-z0-9]{1,7}$", var.envname))
    error_message = "envname must be 2–8 lowercase alphanumeric chars (e.g. main, dev1, qa2)"
  }
}

Cluster structure at 10+ environments

With the {region}-{account}-{envname} scheme, the cluster structure decision is already mostly made: each envname gets its own ECS cluster. The cluster name is the environment identifier. Everything else in that environment — services, task definitions, log groups, IAM roles — inherits from it.

The practical question is how to organize these clusters across AWS accounts:

One AWS account per environment groupRecommended

Prod environments in one account, all non-prod in another. This is the most common pattern at 30–200 person companies. It keeps prod IAM boundaries hard, separates Fargate vCPU quota pools, and makes Cost Explorer attribution clean.

use1-prod-mainuse1-prod-stg1usw2-prod-main← prod account

usw2-dev-dev1usw2-dev-qa1usw2-dev-demousw2-dev-data1← dev account

Single account, all environments

All clusters in one AWS account. Simpler to start, but Fargate quota is shared — a dev load test can exhaust the regional quota and prevent prod from scaling. Works fine at 3 environments; becomes a risk at 10+.

use1-prod-mainuse1-dev-dev1use1-dev-qa1use1-dev-stg1← single account

ECS clusters are free. The cost of having more clusters is management overhead, not AWS billing. At 10+ environments that overhead is real — which is the case for using tooling that treats the environment as the unit of management, not individual services.

Five problems that appear at 10 environments

These don't show up at 3 environments. They all show up, roughly simultaneously, somewhere between environment 8 and environment 12.

Fargate quota exhaustion in prodquota

Fargate vCPU quota is per-region, per-account. Dev and prod share the same pool if they share an account. A developer running load tests against a dev environment can exhaust the regional Fargate quota and prevent production from scaling up during a traffic spike. AWS has no native mechanism to reserve quota for production — the only fix is account separation.

ENI exhaustion before compute limitsnetworking

Every Fargate task in awsvpc mode (the only Fargate mode) gets its own ENI. A fleet of 10 environments × 8 services × 2 tasks each = 160 ENIs. Default regional ENI limits can become a hard ceiling before you hit any compute limit. File a support ticket to raise the limit before you need it — AWS processes these routinely but not instantly.

IAM role proliferationIAM

The correct pattern — one task execution role + one task role per service per environment — generates 2 × N services × M environments IAM roles. At 10 services and 4 environments that's 80 IAM roles. The temptation is to share roles across environments to reduce the number. Don't. Sharing means a misconfigured dev task can access prod secrets. Generate roles programmatically from your Terraform module; the number stops being a problem when you stop counting them manually.

Cloud Map namespace limitservice discovery

AWS Cloud Map limits a single namespace to 100 ECS services. If you use ECS Service Connect and point multiple clusters at the same namespace (e.g., prod.local), you'll hit this ceiling sooner than expected. At 10 environments × 10 services = 100 services in one namespace — exactly at the limit. This is a hard limit and cannot be increased. Fix: per-cluster namespaces. Each envname gets its own: main.local, stg1.local, dev1.local.

ALB listener rule ceilingload balancing

An ALB supports 100 listener rules per listener by default. If you share one ALB across non-prod environments using host-based routing (recommended for cost), you'll have roughly N environments × M services rules. At 8 environments × 12 services = 96 rules — right at the limit. The adjustable workaround (multiple listeners, multiple ALBs) adds cost and complexity. The simpler fix is dedicated listener rules per environment namespace rather than per service.

The environment inventory problem

At 3 environments everyone knows what's running. At 10, someone asks "is anyone still using usw2-dev-data1?" and nobody knows for certain.

There is no AWS-native tool that shows you all environments, their owners, their running task counts, their last deployment time, and their monthly cost in one view. What teams actually do — and why each falls short:

AWS Cost Explorer with tags✓Cost attribution if tagging is consistent✗No real-time status, no task counts, 24-hour lag on cost data

ECS console, cluster by cluster✓Real-time task counts✗No cost, no ownership, no cross-account view

Slack channel where people announce environments✓Ownership context✗Immediately out of date, no automation, ignored

Spreadsheet / wiki page✓Good intentions✗Stale within a week, nobody updates it after incidents

AWS's ECS Split Cost Allocation Data (launched 2023) partially closes the cost visibility gap — it attributes Fargate spend per task using aws:ecs:clusterName and aws:ecs:serviceName system tags as billing dimensions. This works well — but only if your cluster and service names are consistent. Which is why naming comes first.

The real cost of invisible environments

Orphaned environments — ones nobody is actively using but nobody has turned off — are the most expensive line in any ECS bill. At $85–100/month fixed overhead plus compute, a forgotten environment running 24/7 costs $200–400/month. Teams with 10+ environments typically have 1–3 orphaned environments at any given time. The inventory problem isn't just inconvenient — it's expensive.

Scheduling at fleet scale

Non-prod environments run 168 hours a week. Your team works ~55. Scheduling environments offline outside business hours cuts compute cost by 60–70%— for most teams it's the single largest ECS cost lever available.

The problem: AWS-native scheduling operates at the service level. To schedule one environment with 8 services, you need 16 Auto Scaling actions (stop + start per service). At 10 environments that's 160 actions to create, maintain, and update when schedules change.

EnvironmentsServices eachAuto Scaling actionsSchedule change cost

38488 updates

1081608–16 updates

201040010–20 updates

There are three additional problems that emerge specifically at fleet scale:

✗

Timezone complexity

EU teams want environments down at 18:00 CET. US East wants 20:00 EST. US West wants 20:00 PST. Each requires separate cron expressions that account for DST. At 10+ environments with multiple team timezones, maintaining these expressions is a part-time job.

✗

No developer overrides

A developer working late on a deadline wants to keep their environment up past the scheduled stop time. With AWS-native scheduling, that requires either platform engineer access or IAM permissions broad enough to be a security concern. The friction means developers stop requesting overrides — and start asking to remove scheduling entirely.

✗

Silent failed starts

The scheduled start fires. Lambda runs. Desired count updates. But a service fails to start — image pull error, IAM issue, resource limit. The cron job succeeded; the environment didn't come up. AWS doesn't surface this. You need separate health checking or developers start their morning debugging an environment that's half-running.

What teams actually end up doing

Teams start with EventBridge + Lambda at 3–5 environments. By 10 environments they're maintaining a scheduling codebase. By 15–20 environments, the maintenance burden outweighs the savings — and environments quietly go back to running 24/7. The savings disappear not because scheduling doesn't work, but because the tooling to maintain it at scale doesn't exist in AWS natively.

See what 10+ envs really cost: fortem.dev/ecs-cost-calculator

Managing ECS Fargate with Terraform: What Works and What Doesn't

Matt — Thu, 04 Jun 2026 13:58:39 +0000

Managing ECS Fargate with Terraform: What Works and What Doesn't

Originally published at https://fortem.dev/blog/ecs-fargate-terraform
Terraform is the right tool for provisioning ECS Fargate infrastructure. But at 10+ environments, state sprawl and the operations gap catch every team. Here's what to build, what to buy, and the patterns that scale.

Guide

TL;DR

Terraform is the correct tool for provisioning ECS Fargate infrastructure — this article won't try to replace it.
Module-per-environment works for ≤10 environments; past that, Terragrunt or a layered directory structure become necessary.
A consistent tagging strategy (Environment, ManagedBy, Product, ManagedWith, Component) solves cost attribution and makes automation possible at any scale.
At 50+ environments, you'll write 1,500+ lines of custom code for scheduling, cloning, and self-service — or you can accept that Terraform needs an operations partner.
Fortem reads your Terraform-provisioned resources and adds the ops layer: scheduling, cloning, fleet visibility, and developer self-service — without touching your HCL.

What Terraform does well for ECS Fargate

Terraform is the right tool for provisioning ECS Fargate infrastructure. It's declarative — you describe the desired state, and Terraform makes it happen. You get task definitions, ECS services, IAM roles, security groups, load balancers, and VPC configuration all in one place, versioned in git.

What matters more than the HCL syntax is the workflow it enables. Infrastructure changes go through the same PR process as application code. Your CI pipeline runs terraform plan on every pull request. A senior engineer reviews the diff before merge. If something goes wrong, you roll back by applying the previous commit. This is the gold standard for infrastructure management, and nothing in this article suggests replacing it.

Here's a realistic module definition for an ECS environment — the basic building block your team is probably using or something close to it:

module "dev_ecs" {
  source = "./modules/ecs-environment"

  environment = "dev"
  region      = "us-east-1"

  vpc_cidr        = "10.1.0.0/16"
  public_subnets  = ["10.1.1.0/24", "10.1.2.0/24"]
  private_subnets = ["10.1.10.0/24", "10.1.11.0/24"]

  services = {
    api = {
      cpu    = 512
      memory = 1024
      image  = "123456789012.dkr.ecr.us-east-1.amazonaws.com/api:latest"
      port   = 3000
      env_vars = {
        LOG_LEVEL = "debug"
      }
    }
    worker = {
      cpu    = 1024
      memory = 2048
      image  = "123456789012.dkr.ecr.us-east-1.amazonaws.com/worker:latest"
    }
  }

  rds_instance_class = "db.t3.micro"
  redis_node_type    = "cache.t3.micro"

  tags = {
    Environment = "dev"
    Team        = "backend"
    ManagedBy   = "terraform"
  }
}

This is clean, reviewable, and reproducible. One module call = one fully provisioned environment with networking, compute, and data stores. For a single environment or a handful, this is the right pattern.

Terraform patterns that actually scale

Teams adopt one of three patterns as they grow. There's also a fourth — Terraform workspaces per environment — but the community has largely moved past it. Workspaces aren't true state isolation, the naming is fragile (apply to the wrong workspace and you provision dev where staging should be), and HashiCorp themselves recommend against using them for environment separation. We'll skip it.

Pattern 1: Module per environment

A separate directory for each environment, each calling the same shared module with different variables.

terraform/
├── modules/
│   └── ecs-environment/     # shared module
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
├── dev/
│   └── main.tf             # module "dev_ecs" { ... }
├── staging/
│   └── main.tf             # module "staging_ecs" { ... }
├── qa/
│   └── main.tf
├── demo/
│   └── main.tf
└── prod/
    └── main.tf

Pros:dead simple. Anyone on the team can open a directory and understand what's deployed. No hidden state, no Terraform workspace tricks. CI can run plan/apply independently per environment — you can deploy dev without touching staging.

Cons: every new environment means copying a 15-line directory. At 30 environments, you have 30 almost-identical main.tf files. If you add a required variable to the shared module, you update 30 files. Teams outgrow this around 10–15 environments.

Pattern 2: Terragrunt + shared modules

Terragrunt wraps Terraform, keeping configurations DRY while maintaining separate state per environment. Each environment directory contains only a terragrunt.hcl file with environment-specific values — the module source points to a shared Git ref.

# terragrunt.hcl in environments/dev/
terraform {
  source = "git::git@github.com:acme/terraform-modules.git
            //ecs-environment?ref=v2.3.0"
}

inputs = {
  environment = "dev"
  vpc_cidr    = "10.1.0.0/16"
  services    = { api = { cpu = 512, memory = 1024 } }
}

remote_state {
  backend = "s3"
  config  = {
    bucket = "acme-terraform-state"
    key    = "ecs/dev/terraform.tfstate"
  }
}

Pros: explicit dependencies, multi-account-friendly, strong state isolation. Each environment has its own S3 state key — corruption stays contained. Pin modules to versioned Git tags for reproducible deploys.

Cons: another tool to learn and maintain. Your team now needs to understand both Terraform and Terragrunt. Debugging failures means tracing through two layers of indirection. Not worth it below 15 environments — the overhead outweighs the benefit.

Pattern 3: Layered (accounts → regions → environments)

The repo mirrors your cloud topology. Shared infrastructure lives at higher layers and cascades down. Each environment is a directory with subdirectories per resource type — datastores, ECS services, secrets — so a single environment change is a single terraform apply in one directory, not a full fleet-wide plan.

terraform/
├── deployment/
│   ├── accounts/
│   │   ├── dev/
│   │   │   ├── global/              # account-wide: IAM, S3, route53
│   │   │   └── regions/
│   │   │       ├── us-east-1/
│   │   │       │   ├── network/     # VPC, subnets, security groups
│   │   │       │   ├── shared/      # ECR, CloudTrail, ECS events
│   │   │       │   └── wenvs/       # environments
│   │   │       │       ├── api-dev/
│   │   │       │       │   ├── datastores/   # RDS, ElastiCache
│   │   │       │       │   ├── ecs/          # task defs, services
│   │   │       │       │   ├── secrets/      # Secrets Manager
│   │   │       │       │   └── services/     # SQS, SNS, Lambda
│   │   │       │       └── api-qa/
│   │   │       │           └── ...same layers
│   │   │       └── eu-west-2/
│   │   │           └── ...same structure
│   │   └── prod/
│   │       └── ...same structure
│   └── variables/
│       ├── accounts/{dev,prod}/     # per-account tfvars
│       └── global/                  # org-wide tfvars
└── lib/                             # shared Terraform modules

Pros:each layer owns its resources and nothing else. terraform apply runs against a single directory — a security group change doesn't trigger a plan across 60 environments. Adding a new environment copies a directory and overrides variables. The structure is self-documenting: anyone on the team can navigate the repo and understand the fleet topology without opening a diagram.

Cons:the repo itself is the configuration mechanism — there's no single file that describes what exists. New team members need to learn the directory tree. Some duplication between nearly-identical environments unless you lean on shared variables and modules. Best for 20+ environments where operational benefit of isolated state outweighs the duplication cost.

Approach	Scale limit	State isolation	Best for
Module per env	~10 envs	Strong (per-directory)	Getting started; small fleet
Terragrunt	15–50 envs	Strong (per-env key)	Multi-account; explicit deps
Layered	50+ envs	Strong (per-layer, per-env)	Fleet scale; multi-region
Workspaces	~5 envs	Weak (shared backend)	Not recommended

KEY INSIGHT: There's no universally correct pattern. A team of two managing 8 environments doesn't need Terragrunt. A team of eight managing 60 environments across three AWS accounts probably does. Pick the simplest structure your team can maintain at your current scale — you can refactor later when you need to.

The tagging strategy that makes everything easier

Before scaling past 10 environments, the single highest-leverage thing you can do is standardize your tags. Tags feed AWS Cost Explorer, automation scripts, and every operations tool in the chain. If your tags are inconsistent, every downstream system that uses them produces wrong answers.

The simplest way to enforce tags is through the Terraform provider itself — apply them once at the provider level and every resource inherits them automatically:

provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = {
      Environment = "dev"
      ManagedBy   = "platform-team"
      Product     = "acme-saas"
      ManagedWith = "terraform"
    }
  }
}

Tags set here cascade to every resource — ECS services, RDS instances, ALBs, security groups. No per-resource duplication. Override individual resources only when a specific resource genuinely needs a different value.

Here's the minimal set that pays for itself the first time you open a bill:

Tag	Example	Purpose
Environment	dev, staging, qa, prod	Cost grouping; scheduling policy
ManagedBy	platform-team, backend	Who owns it; who to ping
Product	acme-saas, acme-ml	Bill attribution per product
ManagedWith	terraform, pulumi, cdk	IaC tool; filters what to automate
Component	ecs, rds, elasticache	AWS service type; per-service filtering

With these tags, Cost Explorer can answer any question: spend per environment, per team, per product, per AWS service. Without them, you get one aggregate compute number and a spreadsheet nobody maintains.

The naming convention matters too. A predictable pattern like {region}-{account}-{env} — e.g. use1-dev-qa1, usw2-prod-main — is both human-readable and machine-parseable. You can grep it in logs, script it in bash, and join it with billing data. The convention itself doesn't matter as much as the consistency: pick one and automate enforcement.

Terraform provisions.

An operations layer manages.

Terraform — provision

ECS services & task definitions
IAM roles & policies
VPC, subnets, security groups
ALB, target groups, listeners
RDS, ElastiCache, S3

→

adds

Operations layer — manage

Start/stop on a schedule
Clone to any region or account
One-screen fleet visibility
Developer self-service (RBAC)
Cost attribution per environment
AI diagnostics & anomaly detection

Where Terraform starts to break down at scale

Around 15–20 environments, teams hit the same walls. Not because Terraform is bad — because it was designed for provisioning, not operations. The distinction matters.

State sprawl

An ECS environment with VPC, subnets, security groups, ALB, target groups, ECS services, task definitions, IAM roles, RDS, and ElastiCache clocks in at about 30 resources. At 50 environments, that's 1,500 resources in state. A terraform plan across the full fleet takes 4+ minutes. Partial applies become necessary, and state drifts out of sync with reality.

The operations gap

Terraform provisions environments. It doesn't operate them. Every team eventually hits these six gaps and starts building:

Start/stop environments on a schedule — Write your own Lambda + EventBridge + CloudWatch cron, per environment, per timezone. Maintain it. Debug it when the Lambda silently fails.
Clone an environment — Write a new module call, copy all variable values, remember which 3 things are different between the source and the clone. Hope you didn't miss an env var.
Developer self-service — Build a web UI, or accept that developers will open PRs to the infra repo for restarts. Either way, you're now maintaining application code that isn't your product.
Cost per environment — Tag everything consistently. Wait 24 hours for Cost Explorer to update. Export to CSV. Build a spreadsheet. Repeat monthly.
Orphan detection — Write Cost Explorer queries, cross-reference with your Terraform state, and hope the tags on the orphaned resources are correct. They probably aren't — that's why the environment got orphaned.

KEY INSIGHT: None of this is Terraform's fault. It's not what Terraform is for. The same way you wouldn't use Terraform to monitor application health or send Slack alerts, you shouldn't expect it to operate a fleet of running environments. You need a separate operations layer — built or bought.

What the operations layer needs to do

If you're going to build the operations layer yourself — or evaluate something that provides it — here's the concrete list of what it needs to handle. This is the specification for the layer that sits above Terraform, reads the resources it provisions, and manages what happens after terraform apply finishes.

Environment scheduling. Start and stop environments on a configurable schedule — per environment, per timezone, per team. Dev environments run Mon–Fri 9am–7pm. QA runs Mon–Fri 8am–8pm. Production ignores the scheduler. The system must handle the edge cases: what happens when someone manually starts a scheduled-off environment on a Saturday — does it auto-stop after the override period?

Environment cloning. Take any environment and create a copy in a different region or account, with variable overrides. Not a new Terraform module — a one-click operation that copies networking, compute, data stores, and external service config, then deploys. QA needs an isolated copy of EU production to test a compliance flow. That should be a 30-second operation, not a day of writing HCL.

Fleet visibility.One screen showing every environment: status (running/scheduled/stopped), region, services count, current monthly cost, CI/CD pipeline state, and last activity timestamp. No AWS Console tab switching. No ssh-ing into a box to find out what's running there.

Developer self-service. Developers can restart their environments, redeploy services, and view logs — for environments they own. They cannot touch production. They cannot see secrets. They cannot change infrastructure. This requires RBAC scoped to the environment level, not the AWS account level.

Cost attribution and savings tracking.Cost per environment, cost per team, total fleet savings from scheduling. Not an estimate — actual numbers from AWS billing data, updated daily. When the CTO asks “what are we spending on staging this quarter?” you answer in under 30 seconds.

How Fortem works with your existing Terraform

Fortem is the operations layer described above. It reads the resources Terraform provisions — ECS services, task definitions, IAM roles, RDS instances — through AWS tags and naming conventions. No HCL parsing. No access to your Terraform repository. No state modifications.

You run terraform apply. Fortem detects the new or changed resources, and the environment appears in the fleet view with its services, cost breakdown, and scheduling status. You didn't register anything — the tags your Terraform already applies are how Fortem discovers what exists.

Scheduling is opt-in: add a tag like schedule = "business-hours" to an environment, and Fortem stops it outside working hours and starts it before the workday begins. Remove the tag, scheduling stops. Your Terraform state was never involved.

Uninstall Fortem and everything keeps running. Your terraform apply still works. Your infrastructure was never dependent on the operations layer — it was just reading it. Full IAM model on the security page.

Common questions

Does Fortem modify my Terraform state?

No. Fortem reads the resources Terraform provisions — it never writes to your state, pushes to your repo, or modifies HCL. Your infrastructure runs exactly the same whether Fortem is connected or not.

Can I still use terraform apply to change infrastructure when using Fortem?

Yes. terraform apply and terraform destroy work exactly as before. Fortem detects the changes and updates its view automatically. You don't need to notify Fortem of infrastructure changes — it picks them up via tags and naming conventions.

Does Fortem need access to my Terraform repository?

No. Fortem never touches your Terraform repo or state files. It connects to your AWS account through a cross-account IAM role and reads resources directly — the same resources your Terraform provisions.

What happens to Fortem if I destroy an environment with Terraform?

Fortem detects the resources are gone and removes the environment from its dashboard. No stuck state, no sync errors. One environment disappearing doesn't affect anything else in the Fortem fleet view.

How does Fortem handle environments provisioned by Terragrunt or Pulumi instead of vanilla Terraform?

The same way — through tags and naming conventions. Fortem doesn't care which tool provisioned the resources.

### See what the operations layer looks like for your Terraform-provisioned flee

See your fleet cost: fortem.dev/ecs-cost-calculator

How to Cut AWS ECS Fargate Costs by 60–70%

Matt — Thu, 04 Jun 2026 13:58:37 +0000

How to Cut AWS ECS Fargate Costs by 60–70%

Originally published at https://fortem.dev/blog/ecs-fargate-cost-optimization
Your ECS Fargate dev and staging environments run 168 hours a week. Your team works 40. Here's the math on what that costs — and four methods to fix it.

Guide

Your ECS Fargate bill is higher than it needs to be. The AWS documentation will tell you to buy Savings Plans and right-size your instances. That's not wrong — but it misses the biggest lever by a wide margin. This guide covers four methods, starting with the one that cuts 60–70% before you touch a single task definition.

TL;DR

Dev/staging environments run 168 hrs/week. Your team works ~40. You're paying for the other 128.
Scheduling environments to stop during off-hours cuts dev/staging spend by 60–70% — no infrastructure changes.
Right-sizing vCPU and memory adds another 10–20% on top.
Fargate Spot gives 40–70% discount on interruption-tolerant workloads.
Real example: 12 environments, $1,730/mo → $380/mo. 78% reduction. $16,200/yr saved.

Where the money goes — Fargate pricing breakdown

AWS Fargate charges for two resources per task: $0.04048 per vCPU-hour and $0.004445 per GB-hour (us-east-1, Linux/x86, on-demand), per the AWS Fargate pricing page (verified May 2026).

A single service running 0.5 vCPU and 1 GB costs:

0.5 × $0.04048 + 1 × $0.004445 = $0.024685/hr

× 730 hrs/month = $18.02/service/month

× 8 services/environment = $144/environment/month

× 12 environments = $1,730/month

That's for a conservative fleet — 12 environments, 8 services each, half a vCPU per service. Most teams have more. The math compounds: it's not any single expensive environment causing the bill. It's 12 small ones, each billing quietly around the clock.

The 24/7 problem — what you're actually paying for

There are 168 hours in a week. A typical engineering team works 40–50 of them. The rest — nights, weekends, holidays — those 12 dev and staging environments are sitting idle, billing AWS by the second.

The Flexera State of the Cloud 2025 report puts average cloud waste at 32% across organizations. For ECS Fargate development fleets, the number is higher — because dev environments are structurally different from production. Nobody's on-call for them at 3am, but they're running anyway.

$1,730/mo

$515/mo

24/7 (always on)

168 hrs/week

Business hours only

50 hrs/week · Mon–Fri 9am–7pm

Monthly AWS Fargate cost — 12 environments−70% savings

KEY INSIGHT: The biggest Fargate cost driver for most teams isn't their largest environment. It's the 12 small ones running overnight and on weekends — each individually invisible, collectively expensive.

Business-hours scheduling (Mon–Fri 9am–7pm = 50 hrs/week) reduces active compute time to 50 ÷ 168 = 29.8% of the 24/7 baseline. On our 12-environment example: $1,730 → $515/month. Before touching a single task definition.

Method 1 — Environment scheduling (60–70% reduction)

Scheduling means stopping all ECS services in an environment during off-hours and restarting them at the start of the workday. The environment is unavailable overnight and on weekends — which is fine for anything that isn't on-call.

“Mon–Fri 9am–7pm = 50 hours/week = 29.8% of baseline cost. Weekend default: off. One-click override for ad-hoc work.”

— Fortem scheduling model, per-environment, per-timezone

Two implementation paths:

AWS EventBridge Scheduler— native, no extra cost. Write a Lambda or Step Functions rule per environment that sets each ECS service's desired count to 0 (stop) or N (start). Requires code per environment; gets tedious past 10–15 environments.
Fortem — set a schedule per environment in the UI. Fortem stops and starts all services atomically, handles per-timezone configuration, and lets developers request one-click overrides for ad-hoc work without touching the schedule.

Per-timezone matters:your EU team's workday starts 6 hours before your US team's. A single UTC schedule shuts down environments while one team is still working. Configure schedules per team, not globally.

Method 2 — Right-sizing vCPU and memory (10–20% additional)

Most development services are over-provisioned. When a service was first deployed, someone picked a reasonable allocation — 1 vCPU, 2 GB — and never revisited it. In production, that allocation might be justified. In a dev environment processing one request per minute from a developer doing manual testing, it's paying for four times what's needed.

How to check: CloudWatch → ECS → your cluster → CPU and Memory Utilization per service. Look at the 7-day average. A service averaging under 30% CPU utilization on 1 vCPU can be safely dropped to 0.5 vCPU for dev. Under 15%: try 0.25 vCPU.

Savings per environment: 1 vCPU → 0.5 vCPU, per service

Before: 1 × $0.04048 × 730 hrs = $29.55/service/mo

After: 0.5 × $0.04048 × 730 hrs = $14.78/service/mo

8 services × $14.78 saved = $118 saved/environment/mo

Apply right-sizing only to dev and staging. Keep separate task definition files for dev and prod so changes don't drift. Never right-size production without load testing under realistic traffic.

Method 3 — Fargate Spot for non-production (40–70% discount)

Fargate Spot runs tasks on spare AWS capacity at roughly a 70% discount versus on-demand, per AWS Fargate pricing. The tradeoff: AWS can interrupt your tasks with a 2-minute warning when that capacity is reclaimed.

For many dev workloads, a 2-minute interruption is completely tolerable — especially combined with scheduling that already stops environments overnight.

Right for Spot: CI/CD test runners, batch jobs, dev environments for individual engineers, any workload that restarts cleanly.

Wrong for Spot: staging used for customer demos, environments with stateful in-memory state, anything with a guaranteed uptime requirement during business hours.

To enable: update your capacity provider strategy to FARGATE_SPOT. You can split — 80% Spot / 20% On-Demand — to maintain capacity during interruptions.

Method 4 — Kill orphaned environments

Every team has them. An environment was spun up for a feature branch three quarters ago. The engineer who owned it left. The project was deprioritized. The environment is still running, billing $200–$400/month, and nobody has noticed because it doesn't appear in any deployment dashboard.

How to find them: pull the last task run timestamp from CloudWatch Logs Insights — any service with no log events in the last 30 days is a candidate. Cross-reference with your deployment records. No deploy in 60+ days and no active owner: safe to stop.

KEY INSIGHT: In a fleet of 20+ environments, most teams find 2–3 orphaned environments when they look seriously. At $300/month each, that's $900/month — $10,800/year — for compute serving exactly zero requests.

Fortem surfaces last deploy time, last access time, and environment owner for every environment in your fleet. Orphan identification goes from a 2-hour CloudWatch archaeology project to a 2-minute filter. Without tooling, most teams never do this audit — the environments just keep billing.

Putting it together — $1,730 → $380/month

Same fleet throughout: 12 environments, 8 services each, 0.5 vCPU, 1 GB, AWS us-east-1 on-demand rates. Each method applied cumulatively.

Step by step:

Baseline (24/7): $1,730/mo

+ Business-hours scheduling (29.8% of baseline): $515/mo −70%

+ Right-sizing (0.5→0.25 vCPU on 8 dev envs): ~$440/mo −15%

+ Fargate Spot on 4 eligible environments: ~$380/mo −14%

Total: $380/mo · 78% reduction · $16,200/yr saved

This is conservative — zero orphaned environments assumed, lowest Fargate size, Spot applied to only 4 of 12 environments. Larger fleets, bigger services, and multiple AWS accounts scale these numbers proportionally.

The Fortem ROI calculator lets you plug in your actual fleet size — number of environments, services, vCPU, memory — and see the number for your specific bill.

Common questions

Does stopping ECS environments lose any data?

No. Stopping an ECS service terminates the running tasks — it does not delete your databases, volumes, or any persistent state. RDS, ElastiCache, and S3 are unaffected. The environment is exactly as you left it when it starts back up.

How long does an ECS environment take to start up after scheduling?

Typically 60–120 seconds for most ECS Fargate services. Cold start time depends on your image size and application startup logic. Teams that care about fast restarts keep images small and use health check grace periods appropriately.

Can I schedule only some services within an environment?

Yes, but it's usually not worth the complexity. Scheduling an entire environment atomically (all services together) avoids dependency issues — if you stop only some services, others may fail waiting for dependencies. Start with full-environment scheduling.

Is Fargate Spot safe for staging environments?

It depends on what staging is used for. If staging is purely for automated test runs and can tolerate a 2-minute interruption, Spot is fine. If staging hosts customer demos or is expected to be reliably available during business hours, use On-Demand for those environments.

How do I find out which of my environments are costing the most?

AWS Cost Explorer with resource-level cost allocation tags gives you per-service cost breakdowns. You need to tag your ECS services with Environment and Team tags first. Without tags, Cost Explorer shows compute costs in aggregate with no way to attribute them.

### See what your fleet would save Run the calculator in 30 seconds, then book 2

See your fleet cost: fortem.dev/ecs-cost-calculator

ECS Fargate Best Practices: Running a Fleet of 10+ Environments Without the Pain

Matt — Thu, 04 Jun 2026 13:57:42 +0000

ECS Fargate Best Practices: 10+ Environments Without the Pain

Originally published at https://fortem.dev/blog/ecs-fargate-best-practices
Seven ECS Fargate best practices for teams running 10+ environments. Fix hidden costs, Terraform state sprawl, Fargate quota sharing, and scheduling before they break your fleet.

Guide

Most ECS Fargate best practices guides tell you what to do. This one tells you what breaks between environment 5 and environment 20 — and gives you the exact fix for each. The numbers come from AWS published pricing, service quotas, and patterns we've seen managing fleets at scale. If you're running fewer than 5 environments, most of this won't matter yet. Bookmark it.

TL;DR

Name everything consistently from day one; retrofitting naming across 10+ environments takes weeks.
Fixed overhead is $85–100/mo per environment before a single container runs — at 50 envs that's $4,250–5,000/mo invisible spend.
Schedule dev/staging off-hours first. It cuts compute cost 60–70% and requires zero infrastructure changes.
Set CloudWatch log retention before ingestion hits 15 TB/mo and you get a $7,500 bill.
Isolate Terraform state per environment before the 25 MB threshold makes plans take 30+ minutes.

Start with naming and account structure

At 3 environments you can get away with ad-hoc names. At 10 you can't — because every AWS resource name is simultaneously a billing dimension, an IAM scope, and a CloudWatch filter. Inconsistent names mean you can't attribute cost, can't write scoped IAM policies, and can't build dashboards without a lookup table.

The convention that scales: {region_short}-{account}-{envname}. Applied to every resource from day one. One Terraform local generates every downstream resource name — ECS cluster, task definition, SSM parameter path, IAM role, CloudWatch log group — all from one source.

Ready to use — copy this today

locals {
  env_prefix = "${var.region_short}-${var.account}-${var.envname}"
}

resource "aws_ecs_cluster" "main" {
  name = local.env_prefix  # → "use1-prod-main"
}

resource "aws_ecs_task_definition" "api" {
  family = "${local.env_prefix}-api-td"
  # → "use1-prod-main-api-td"
}

resource "aws_ssm_parameter" "db_host" {
  name = "/${local.env_prefix}/api/DB_HOST"
  # → "/use1-prod-main/api/DB_HOST"
}

resource "aws_iam_role" "task_role" {
  name = "${local.env_prefix}-api-task-role"
  # → "use1-prod-main-api-task-role"
}

resource "aws_cloudwatch_log_group" "api" {
  name = "/ecs/${local.env_prefix}-api"
  retention_in_days = var.log_retention_days
}

Map naming to account structure. The most common pattern that works at 10+ environments: one AWS account for production, one for all non-prod. This separates Fargate vCPU quota pools, hardens IAM boundaries, and makes Cost Explorer attribution clean.

One constraint your naming convention must handle: ALB target group names are capped at 32 characters, and each ALB has a hard limit of 100 target groups. At 20 environments with 6 services each, you're at 120 target groups — past the limit. This forces per-environment ALBs sooner than you think, which increases your fixed overhead. A short naming prefix (use1-prod-api — 12 chars) leaves room for the target group suffix.

For the full naming pattern table, including the 32-character target group constraint and per-resource examples, see the dedicated section on consistent naming conventions for ECS environments.

Know your fixed overhead per environment

When engineers estimate ECS costs, they calculate compute: vCPU hours, memory hours, maybe RDS. What they miss is the fixed overhead that exists before a single container runs.

Every environment needs its own ALB and NAT Gateway. These costs are flat — they don't scale with usage, they don't go away when you stop tasks at night, and they don't appear on the compute line in Cost Explorer.

ResourceMonthly costNotes — Application Load Balancer: $22/mo$0.0225/hr base + $0.008/LCU-hr

NAT Gateway (2 AZs)~$66/mo$0.045/hr × 2 + $0.045/GB data

CloudWatch log basics$3–15/moDepends on log volume + retention

SSM, ECR, other$1–5/moSmall but additive at scale

Total fixed overhead$85–100/moBefore first task runs

At 10 environments, that's $850–1,000/mo invisible spend. At 50 environments, it's $4,250–5,000/mo before a single task runs.

KEY INSIGHT: NAT Gateway is the single most expensive fixed line item in any ECS environment — and the easiest to eliminate for non-prod. Teams that care about NAT cost switch non-prod environments to public subnet placement with strict security group rules and Network ACLs instead of private subnets with a NAT. This is meaningfully cheaper but does reduce your network boundary — regulated environments (PCI, HIPAA) and prod should keep the NAT. Evaluate your compliance posture before cutting this corner.

One more lever: VPC Endpoints. If your containers only need to reach AWS services (S3, ECR, CloudWatch, SSM), a VPC Endpoint costs ~$7.20/mo per endpoint — roughly 1/5th of one NAT Gateway. For ECR pulls and CloudWatch pushes, Gateway Endpoints (S3, DynamoDB) are free. Combined with the public-subnet approach above, this is the cheapest path to eliminating NAT entirely for non-prod. Strategy: use VPC Endpoints for AWS dependencies and public subnets for outbound internet, and you drop NAT from non-prod without sacrificing functionality.

We broke down the full per-environment cost — including ALB, NAT Gateway, CloudWatch, and data transfer — in our guide to how much an ECS environment actually costs.

Schedule dev/staging before the bill bleeds

Your environments run 168 hours a week. Your team works 40–55. Scheduling alone cuts compute cost by 60–70%— for most teams it's the single largest ECS cost lever available, and it requires zero code changes. The spread: 70% savings on a strict 40-hour Mon–Fri schedule, 60–65% on a 55-hour week. The exact number depends on your team's working hours, but either way it's the fastest path to a lower AWS bill.

EnvironmentsServices eachAuto Scaling actionsSchedule change cost

38488 updates

1081608–16 updates

201040010–20 updates

$1,730/mo

$515/mo

12 envs, 24/7

$1,730/mo

12 envs, business hours schedule (55 hrs/week)

$515/mo

Monthly AWS Fargate cost−70% savings

What teams actually do

Teams start with EventBridge + Lambda at 3–5 environments and it works beautifully. By 10 environments they're maintaining a scheduling codebase with a full test suite. By 15–20 environments, the maintenance burden outweighs the savings — and environments quietly drift back to 24/7. The economics of scheduling are sound; the tooling to maintain it at scale is the bottleneck.

For a deep dive on the AWS-native approach and a comparison with environment-level scheduling, read the complete guide to ECS environment scheduling.

Isolate Terraform state before it isolates you

A single Terraform state file containing all environments starts fast. At 25–50 MB, plans take 30+ minutes. At the HCP Terraform hard limit of ~100 MB (from base64 encoding), Terraform stops working entirely.

The blast radius is worse than the speed problem: one module bug in a shared state file can take down every environment in a single apply. A typo in a variable that propagates to 10 environments creates 10 simultaneous incidents.

The fix is per-environment state, applied independently. One folder per environment, each with its own S3 backend. No shared state files, no workspaces, no extra tooling — just directories you can see and reason about:

Folder-per-environment pattern

# Directory structure — one folder per environment, independent state
# terraform/environments/
#   prod/
#     backend.tf        → prod's own S3 backend (separate state file)
#     main.tf           → calls the shared module
#     terraform.tfvars
#   staging/
#     backend.tf        → staging's own S3 backend
#     main.tf
#     terraform.tfvars
#   dev-01/
#     ...

# environments/prod/backend.tf — each environment has its own state
terraform {
  backend "s3" {
    bucket         = "tfstate-org"
    key            = "envs/prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

# environments/prod/main.tf — thin, calls the shared module
module "environment" {
  source = "../../modules/ecs-environment"

  env_name   = "prod"
  account_id = "111111111111"
  # Plans run independently, blast radius is one environment
}

Each environments/<name>/ folder is self-contained: its own backend, its own tfvars, its own plan/apply lifecycle. You can see the entire fleet structure by looking at the directory tree — no jumping between files to trace configuration inheritance. Adding an environment means copying one folder and changing three lines. This is the pattern teams converge on after workspaces stop scaling, and it works with vanilla Terraform — no extra tooling required.

How to know when to split — check your state file size:

terraform state pull | wc -c

Under 5 MB — fine. 10–25 MB — start planning the migration. Over 25 MB — plans take 30+ minutes and locking contention becomes noticeable. The 3-minute plan threshold is also a strong signal: if a plan against one environment takes longer than 3 minutes, your state file is too large regardless of its byte count.

Practical guidance: teams managing 10+ environments should move to per-environment state before hitting 25 MB, not after. The migration is mechanical — extract each environment into its own directory, run one init per directory, and verify with a plan. It takes an afternoon and prevents a week of incidents. For the full implementation guide, see managing ECS Fargate with Terraform: what works and what doesn't.

Set CloudWatch retention on day one

The default CloudWatch log group setting is “never expire.” Teams routinely forget to change this. At $0.50/GB ingested, a fleet of 50 containers writing 5 GB/day generates $75/mo in ingestion costs alone — before storage, before metrics.

CloudWatch Logs at scale

50 containers × 5 GB/day: 7,500 GB/mo × $0.50/GB = $3,750/mo

Double the fleet to 100 containers: 15 TB/mo = $7,500/mo. We've seen this.

Add Container Insights: $0.21/hr per cluster

The fix: set retention_in_daysin Terraform. 30 days for dev/staging, 90 for prod. Never “never expire.”

resource "aws_cloudwatch_log_group" "api" {
  name              = "/ecs/${local.env_prefix}-${var.service_name}"
  retention_in_days = var.env_type == "prod" ? 90 : 30

  # Optional: switch non-prod to Infrequent Access — 50% cheaper storage
  # for logs read less than once a week
  log_group_class = var.env_type == "prod" ? "STANDARD" : "INFREQUENT_ACCESS"
}

Also: SSM parameters at $0.05/parameter/month creep unnoticed. At 10 environments × 8 services × 5 parameters each = 400 parameters = $20/mo. Small, but nobody accounts for it.

KEY INSIGHT: We've seen teams discover a $7,500/mo CloudWatch bill six months after launching their 15th environment. The Terraform was deployed with default retention, and nobody looked at the CloudWatch line in Cost Explorer until the CFO asked. Set retention in your module defaults. It costs nothing to set and thousands to miss.

CloudWatch is one piece of the ECS cost puzzle. For the full picture — Fargate compute, data transfer, load balancing, and the 65% savings playbook — see how to cut AWS ECS Fargate costs by 65%.

Use Fargate Spot where it belongs

Fargate Spot offers a 68% discount over on-demand: $0.01291/vCPU-hr vs $0.04048. The trade-off is a 2-minute interruption notice when AWS reclaims capacity, per the AWS Fargate pricing page (verified May 2026).

“Fargate Spot runs tasks on spare AWS EC2 capacity at up to a 70% discount compared to Fargate On-Demand. If AWS needs the capacity back, your running tasks will be given a two-minute warning and then stopped.”

— AWS Fargate Pricing, verified May 2026

Real interruption rates: large instance families see under 5% interruption; common instance types see 5–15%.

Best practice: use a capacity provider strategy with a 70/30 or 80/20 Spot/On-Demand split. Spot for CI/CD runners, staging, automated tests, and non-interactive batch jobs. On-Demand for production, customer-facing staging, and demo environments.

To enable: create a capacity provider strategy that includes both FARGATE_SPOT and FARGATE with a weighted base. AWS distributes tasks proportionally. The base weight (first number) is the minimum On-Demand count; the weight determines the split for additional tasks.

Capacity provider strategy with weighted split

# Define capacity providers for the ECS cluster
resource "aws_ecs_cluster_capacity_providers" "main" {
  cluster_name = aws_ecs_cluster.main.name

  capacity_providers = ["FARGATE", "FARGATE_SPOT"]

  default_capacity_provider_strategy {
    capacity_provider = "FARGATE_SPOT"
    weight            = 1
    base              = 0  # 0 On-Demand tasks minimum for non-prod
  }

  default_capacity_provider_strategy {
    capacity_provider = "FARGATE"
    weight            = 0  # Use On-Demand only when Spot unavailable
  }
}

# Per-service: adjust weights based on workload criticality
# Prod services use base=2 + more FARGATE weight
# Non-prod services use base=0 + FARGATE_SPOT only

One operational note: Fargate Spot provides a 2-minute SIGTERM window before SIGKILL. Your containers must handle graceful shutdown within this window — drain connections, flush buffers, checkpoint state. If your app takes 3+ minutes to shut down, Spot tasks will be force-killed mid-flight. For CI/CD runners and stateless workers this is fine; for anything with in-flight state, On-Demand is the safer choice. For more on Spot savings strategy, see how to cut ECS Fargate costs by 65%.

Split your Fargate quota before dev takes down prod

Fargate vCPU quota is per-region, per-account. If dev and prod share an account, they share the same quota pool. A developer running load tests against a dev environment can exhaust the regional Fargate quota — and production can't scale up during a traffic spike.

AWS has no native mechanism to reserve quota for production. The default Fargate On-Demand vCPU quota is 6 vCPUs per region (soft limit, increaseable to 10,000+ via support ticket). Dev and prod compete for the same pool.

KEY INSIGHT: Fargate quota sharing is invisible until it bites you. You won't know it happened until prod fails to scale during an incident. At that point, the fix takes hours — filing a support ticket and waiting for the quota increase to propagate. Account-level separation (prod in one account, non-prod in another) eliminates this class of incident.

The fix: separate accounts for prod vs non-prod. If that's not immediately feasible, monitor quota utilization proactively. Go to Service Quotas → AWS Fargate → Running On-Demand Fargate vCPUs in the AWS Console. Set a CloudWatch alarm at 70% utilization so you have time to react before hitting the limit. Quota increase requests can take 24–72 hours — at 70% you have days of runway; at 95% you have hours.

Two more constraints that hit at fleet scale: (1) Fargate launch rate — 20 tasks/second sustained in older regions, 5/second in newer ones. If your scheduler tries to start 100 tasks across 10 environments simultaneously, you'll hit the throttle. Add jitter to scheduled starts. (2) ECS API throttle — 10 burst requests/second, 1 sustained. Scripts that poll DescribeServices across 50 services will get rate-limited. Add exponential backoff and batch calls.

The ECS multi-environment strategy guide covers account structure patterns in detail, including when to split further and how to set up cross-account IAM for Fortem-style tooling.

Common questions

How do I track per-environment costs in AWS?

Enable cost allocation tags in the Billing console and consistently tag every resource with an environment key. AWS Cost Explorer can then filter and group by environment. For real-time cost, use ECS Split Cost Allocation Data which attributes Fargate spend per task using system tags.

Should I use one ECS cluster or one per environment?

One cluster per environment is the right default. It keeps IAM boundaries clean, makes Cost Explorer filtering simple, and prevents quota sharing between environments. Shared clusters only make sense if you have strict naming discipline and no compliance requirements for isolation.

What's the fastest way to start saving on ECS Fargate costs?

Schedule non-prod environments to run only during business hours. This cuts compute spend by 60-70% without changing any code. Next: set CloudWatch log retention to 30 days for dev/staging. Third: use Fargate Spot for CI/CD runners and staging workloads.

How do I prevent developers from leaving environments running 24/7?

Automated scheduling with developer override. Set a default schedule (e.g. Mon-Fri 9am-7pm) and let developers extend via Slack command or a simple self-service UI. AWS-native requires maintaining EventBridge rules per service; at 10+ environments this becomes a maintenance burden.

Does Fortem replace Terraform?

No. Fortem manages your running ECS environments — scheduling, monitoring, cloning — but does not replace your IaC tooling. Your Terraform continues to define infrastructure. Fortem operates on top of what Terraform builds.

### See what your fleet would save Run the calculator in 30 seconds, then book 2

See your fleet cost: fortem.dev/ecs-cost-calculator

ECS Environment Scheduling: The Complete Guide

Matt — Thu, 04 Jun 2026 13:57:41 +0000

How Do You Stop Paying for Idle ECS Environments?

Originally published at https://fortem.dev/blog/ecs-environment-scheduling
Stop paying for ECS dev and staging compute when nobody's using it. Every scheduling approach — AWS-native options, trade-offs, and what teams at fleet scale actually do.

Your dev and staging ECS environments run 168 hours a week. Your team works 40. The other 128 hours are pure waste. This guide covers every approach to scheduling ECS environments — from AWS-native options you can set up today to what actually works when you're managing 20+ environments across multiple accounts.

The math: what you're actually paying

A typical dev environment on ECS Fargate — 8 services, 0.5 vCPU and 1GB memory each — costs around $144/monthrunning 24/7. That's $1,728/year for one environment that your developers use 50 hours a week at most.

ScheduleHours/weekHours/monthMonthly cost

24/7 (current)168730$144

Mon–Fri 9am–7pm50217$43

Mon–Fri 8am–8pm60260$51

Mon–Sun 8am–10pm98425$84

Switching one 8-service environment from 24/7 to business hours saves $101/month. At 10 environments that's $1,010/month — $12,120/year — without changing a single line of application code.

How ECS scheduling works

ECS doesn't have a native "scheduled environment" concept. What you're actually doing is setting the desired count of each ECS service to 0 on a schedule (stop) and back to its normal value on another schedule (start).

When desired count hits 0, ECS drains existing tasks and stops billing for vCPU and memory. Your service definition, load balancer, security groups, and networking remain intact. The environment is "off" — not deleted. Starting it is setting desired count back to 1 (or whatever your normal value is).

Key principle — You pay for running tasks, not for service definitions. Desired count = 0 means no tasks running means no Fargate billing. The service configuration costs nothing — only the compute does.

Ready to use — copy this today

This EventBridge + Lambda setup stops and starts an ECS service on a schedule. Replace the cluster name, service name, and region — it works today with zero additional tools.

pythonCopy

import boto3, os

ecs = boto3.client("ecs")
CLUSTER = os.environ["CLUSTER_NAME"]
SERVICE = os.environ["SERVICE_NAME"]

def set_desired_count(count: int):
    ecs.update_service(
        cluster=CLUSTER,
        service=SERVICE,
        desiredCount=count,
    )
    print(f"Set {SERVICE} desired count to {count}")

def handler(event, context):
    action = event.get("action", "stop")  # "stop" or "start"
    count = 0 if action == "stop" else int(os.environ.get("NORMAL_COUNT", "2"))
    set_desired_count(count)

Deploy this as a Lambda, then create two EventBridge Scheduler rules — one that invokes it with { "action": "stop" } on weekdays at 7PM, another with { "action": "start" } at 9AM Mon–Fri. Total cost: zero beyond the Lambda invocations.

Option 1: Application Auto Scaling scheduled actions

Best for: 1–3 environments, simple schedules

Application Auto Scaling supports scheduled scaling actions on ECS services. You define a cron expression and a min/max/desired capacity. AWS handles the rest — no Lambda, no EventBridge rules to manage.

Register your ECS service as a scalable target, then create two scheduled actions — one to stop (desired = 0) and one to start (desired = your normal count):

# Register the service as a scalable target
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 0 \
  --max-capacity 3

# Stop at 7pm UTC (Mon–Fri)
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name stop-evenings \
  --schedule "cron(0 19 ? * MON-FRI *)" \
  --scalable-target-action MinCapacity=0,MaxCapacity=0

# Start at 8am UTC (Mon–Fri)
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name start-mornings \
  --schedule "cron(0 8 ? * MON-FRI *)" \
  --scalable-target-action MinCapacity=1,MaxCapacity=3

Limitations

• One command per service — 8 services × 2 actions = 16 CLI calls per environment
• No concept of "environment" — you schedule individual services
• Schedule changes require updating each service individually
• No visibility into scheduled state across services or environments

Option 2: EventBridge Scheduler + Lambda

Best for: multiple environments, custom logic, per-timezone schedules

EventBridge Scheduler triggers a Lambda function on a cron schedule. The Lambda iterates over all services in an environment (identified by a tag) and sets their desired count. This is the most flexible AWS-native approach — you can handle timezones, environment grouping, and custom logic.

The Lambda function itself is straightforward — iterate over tagged services and update desired count:

pythonCopy

import boto3

ecs = boto3.client('ecs')

def handler(event, context):
    desired_count = event['desired_count']  # 0 to stop, 1 to start
    cluster = event['cluster']
    env_tag = event['environment']          # e.g. "staging"

    # List all services in the cluster
    paginator = ecs.get_paginator('list_services')
    for page in paginator.paginate(cluster=cluster):
        for arn in page['serviceArns']:
            # Describe to get tags
            svc = ecs.describe_services(
                cluster=cluster,
                services=[arn],
                include=['TAGS']
            )['services'][0]

            tags = {t['key']: t['value'] for t in svc.get('tags', [])}

            if tags.get('Environment') == env_tag:
                current = svc['desiredCount']
                if desired_count == 0:
                    # Store current count before stopping
                    ecs.tag_resource(
                        resourceArn=arn,
                        tags=[{'key': 'ScheduledDesiredCount',
                               'value': str(current)}]
                    )
                    ecs.update_service(
                        cluster=cluster,
                        service=arn,
                        desiredCount=0
                    )
                else:
                    # Restore previous count
                    restore = int(tags.get('ScheduledDesiredCount', '1'))
                    ecs.update_service(
                        cluster=cluster,
                        service=arn,
                        desiredCount=restore
                    )

Then create two EventBridge Scheduler rules — one for stop, one for start — each passing the appropriate desired_count in the input.

What this doesn't solve

• No UI — schedule changes require code or CLI changes
• Per-timezone logic gets complex fast (US-east vs EU-west teams)
• Error handling and alerting on failed starts is your problem
• At 10+ environments, you're maintaining a scheduling system, not using one

Option 3: Terraform-managed schedules

Best for: teams with strong Terraform discipline and few environments

You can manage scheduled scaling actions directly in Terraform using the aws_appautoscaling_scheduled_action resource. This keeps scheduling configuration version-controlled alongside your infrastructure.

resource "aws_appautoscaling_target" "ecs_target" {
  service_namespace  = "ecs"
  resource_id        = "service/${var.cluster_name}/${var.service_name}"
  scalable_dimension = "ecs:service:DesiredCount"
  min_capacity       = 0
  max_capacity       = var.max_capacity
}

resource "aws_appautoscaling_scheduled_action" "stop" {
  name               = "${var.service_name}-stop"
  service_namespace  = "ecs"
  resource_id        = aws_appautoscaling_target.ecs_target.resource_id
  scalable_dimension = aws_appautoscaling_target.ecs_target.scalable_dimension
  schedule           = "cron(0 19 ? * MON-FRI *)"

  scalable_target_action {
    min_capacity = 0
    max_capacity = 0
  }
}

resource "aws_appautoscaling_scheduled_action" "start" {
  name               = "${var.service_name}-start"
  service_namespace  = "ecs"
  resource_id        = aws_appautoscaling_target.ecs_target.resource_id
  scalable_dimension = aws_appautoscaling_target.ecs_target.scalable_dimension
  schedule           = "cron(0 8 ? * MON-FRI *)"

  scalable_target_action {
    min_capacity = var.desired_count
    max_capacity = var.max_capacity
  }
}

Clean and auditable — but it still operates at the service level. Changing a schedule for an environment with 8 services means updating 8 Terraform resources and running apply. For teams where schedules change rarely, this is fine. For teams where developers want to adjust their own environment hours, it becomes a bottleneck.

What breaks at fleet scale

Every approach above works at 1–3 environments. Here's what teams discover when they try to scale it to 15–50 environments across multiple AWS accounts:

✗

Per-service configuration doesn't scale

At 20 environments × 8 services, you have 160 individual Auto Scaling targets to manage. A schedule change for one environment touches 8 resources. A timezone change for one team requires finding and updating those 8 resources across potentially multiple accounts.

✗

No environment-level visibility

None of the AWS-native approaches give you a view of 'which environments are running, which are scheduled, and what their current cost is.' You're looking at individual services in CloudWatch and Cost Explorer, not environments as units.

✗

Timezone complexity multiplies

EU teams want environments to stop at 18:00 CET. US East teams want 19:00 EST. US West teams want 19:00 PST. Each requires separate cron expressions — and those expressions need to account for DST. A single Lambda managing this across 20 environments becomes a meaningful maintenance burden.

✗

Developer self-service breaks down

Developers want to override their environment schedule occasionally — stay late on a sprint, work a weekend. In every AWS-native approach, that override requires console access or a platform engineer intervention. The friction is high enough that teams just leave environments running 24/7 to avoid the hassle.

✗

Failed starts are silent

If an ECS service fails to start after a scheduled start (image pull error, IAM issue, resource limits), the EventBridge rule fires, Lambda runs, desired count updates — but nobody knows the environment didn't come up. You need separate health checking and alerting to catch this.

The pattern we see

Teams start with EventBridge + Lambda at 3 environments. By 10 environments they're spending 2–4 hours a month maintaining the scheduling system. By 20 environments they've either given up and gone back to 24/7, or a platform engineer owns a growing codebase that does nothing except stop and start ECS services on a schedule.

What to track

Regardless of which approach you use, these are the metrics worth monitoring:

Baseline vs. actual spend per environment

Tag all ECS services with Environment and use Cost Explorer with resource-level tags. Baseline = what you'd pay at 24/7. Actual = what you paid. The delta is your scheduling savings.

Schedule adherence

CloudWatch metric: ECS service DesiredCount. If an environment should be at 0 from 19:00–08:00 but DesiredCount is 1, your schedule isn't firing. Set an alarm on non-zero DesiredCount during expected off-hours.

Start latency

Time from scheduled start to all services healthy. ECS RunningTaskCount = DesiredCount AND target group healthy host count = DesiredCount. Anything over 3 minutes warrants investigation.

Failed starts

ECS StoppedTaskCount increasing after a scheduled start usually means image pull errors or resource exhaustion. CloudWatch alarm on StoppedTaskCount > 0 for environments in scheduled-start window.

See your scheduling savings: fortem.dev/ecs-cost-calculator