How to Cut AWS ECS Fargate Costs by 65%
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.
- ·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
Fargate bills $0.04048/vCPU-hr and $0.00444/GB-hr — a 0.5 vCPU + 1 GB task costs ~$25/mo; across 12 environments with 8 services each, that compounds to $1,730/mo.
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:
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. For a full breakdown of what each line item costs across regions and capacity types, see AWS Fargate pricing: real costs vs the docs.
The 24/7 problem — what you're paying for
Non-prod ECS environments run 168 hours a week, but your team works roughly 55 of them — the remaining 113 hours are idle compute you are billed for anyway.
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 2026 report puts average cloud waste at 29% 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.
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 is the single largest cost lever for ECS Fargate teams — and it costs nothing to implement.”
— Fortem fleet data, 100+ ECS environments
Stop non-prod ECS services outside business hours by setting desired count to 0 via EventBridge — this alone cuts dev and staging spend by 60-70% at zero implementation cost.
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. The ECS environment scheduling guide walks through the EventBridge rules and Fortem configuration in detail.
Method 2 — Right-sizing vCPU and memory (10–20% additional)
Most ECS Fargate dev tasks run at 15-30% of their allocated vCPU and memory; dropping a task from 1 vCPU to 0.5 vCPU cuts its compute cost by 50% with no config risk.
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.
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 provides ~70% discount off On-Demand by running tasks on spare AWS capacity that can be reclaimed with a two-minute warning — ideal for dev and CI/CD workloads.
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 fleet has environments nobody owns anymore — feature-branch setups that outlasted the ticket, each quietly billing $200-400/month with zero traffic for months.
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.
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 keep billing.
Putting it together — $1,730 → $380/month
Applying scheduling, right-sizing, and Fargate Spot cumulatively to 12 environments at standard ECS Fargate on-demand rates takes a $1,730/mo bill to $380/mo — a 78% reduction.
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.
Fortem schedules your ECS Fargate environments on a per-timezone calendar and shows every orphaned or overprovisioned service in your fleet — so the 78% reduction in this post becomes a 30-minute setup, not a multi-sprint project.
Book a 20-min call →Common questions
The numbers in this post are estimates. Run the Fleet Audit against your actual ECS fleet and get your real figure in 15 minutes.
If you read this, you might also want to know
How much can I save with Fargate Spot vs On-Demand?
Fargate Spot gives ~70% discount off On-Demand. For a 0.5 vCPU + 1 GB task: about $25/mo On-Demand vs roughly $7.50/mo Spot. Across 10 dev environments with 8 services each: $2,000/mo vs $600/mo. Spot is the biggest cost lever for non-production.
Does right-sizing require redeploying my service?
Yes — changing task CPU/memory requires a new task definition revision and a service update. The deployment is a rolling update (ECS default) — no downtime if you have enough running tasks. Right-sizing is safe during business hours.
What's the fastest way to find overprovisioned services?
CloudWatch Container Insights — CPU and Memory Utilization. Look at p95 over a 2-week period. If p95 is below 30% of your task allocation, you're overprovisioned. The Container Insights dashboard shows this at a glance.
See what your fleet would save
Run the calculator in 30 seconds, then book 20 minutes to go through it together with a Fortem engineer.
Response within 4 hours, weekdays.