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