What Does AWS Fargate Actually Cost Per Environment?
Originally published at https://fortem.dev/blog/aws-fargate-pricing-real-costs
AWS says $0.04048/vCPU-hr. Here's what a real environment costs — ALB, NAT Gateway, CloudWatch, data transfer — and why 30 environments bleed $1,500+/mo in fixed overhead nobody budgets for.
Guide
AWS pricing pages tell you $0.04048 per vCPU-hour and $0.004445 per GB-hour. That's just the compute — the number you plug into a spreadsheet and call it a day. What they don't surface is the fixed overhead every ECS environment carries before a single task starts: the Application Load Balancer charging hourly whether traffic hits it or not, the NAT Gateway billing per hour per availability zone, the CloudWatch logs accumulating through idle weekends. This guide breaks down every line item — compute and overhead — with real math for 10, 30, and 50 environment fleets.
TL;DR
- Per-environment compute (8 services, 0.5 vCPU + 1 GB): $144/mo 24/7, $43/mo on business hours. That's the number everyone calculates.
- Fixed overhead per environment: ~$90/mo for ALB, CloudWatch, data transfer, and NAT Gateway share — this charges 24/7 with or without running tasks.
- At 30 environments: $1,440/mo in overhead alone — $17,280/year for infrastructure serving zero traffic at 3am.
- AWS ALB limits (100 rules, 50 certificates, 100 target groups) constrain shared-ALB strategies — you need to know these before you design your fleet.
- Fargate Spot drops dev compute by 68% ($0.01291/vCPU-hr). Combined with scheduling and right-sizing, a $5,735 fleet drops to ~$1,350/mo.
Ready to use — copy this today
ECS service definition with Fargate Spot, cost allocation tags, and a CloudWatch billing alarm. Drop this into your Terraform stack and every environment gets tagged, tracked, and billed at Spot rates.
# ECS service — Fargate Spot with cost allocation tags
resource "aws_ecs_service" "app" {
name = "${var.name}"
cluster = aws_ecs_cluster.main.arn
task_definition = aws_ecs_task_definition.app.arn
desired_count = var.desired_count
# Use the capacity provider strategy block, not launch_type
capacity_provider_strategy {
capacity_provider = "FARGATE_SPOT"
base = 0
weight = 100
}
propagate_tags = "SERVICE"
tags = {
Environment = var.environment
Team = var.team
ManagedBy = "terraform"
CostCenter = var.cost_center
}
}
# Enable cost allocation tags — activate in AWS Billing Console first
resource "aws_ecs_tag" "cost_allocation" {
resource_arn = aws_ecs_service.app.id
key = "Environment"
value = var.environment
}
# CloudWatch billing alarm — fires if daily spend exceeds threshold
resource "aws_cloudwatch_metric_alarm" "billing_alert" {
alarm_name = "${var.environment}-billing-alert"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = "1"
metric_name = "EstimatedCharges"
namespace = "AWS/Billing"
period = "86400"
statistic = "Maximum"
threshold = var.daily_cost_threshold
alarm_description = "Daily AWS spend for ${var.environment} exceeded threshold"
alarm_actions = [aws_sns_topic.billing_alerts.arn]
dimensions = {
Environment = var.environment
}
}
Requires: Terraform 1.x, AWS provider ≥5.0, FARGATE_SPOT capacity provider added to your ECS cluster. Cost allocation tags need 24–48 hours to propagate in Cost Explorer.
The compute costs — the number you know
AWS Fargate pricing in US East (N. Virginia) for Linux/x86 on-demand, verified May 2026:
“AWS Fargate charges $0.04048 per vCPU-hour and $0.004445 per GB-hour for Linux/x86 on-demand pricing.”
— AWS Fargate Pricing, verified May 2026
That's the headline number. Now here's what it means for a real service — a typical API with 0.5 vCPU and 1 GB of memory:
Per-service compute cost:
0.5 × $0.04048 + 1 × $0.004445 = $0.024685/hr
× 730 hrs/month (AWS billing standard) = $18.02/service/month
× 8 services/environment = $144.16/environment/month
Business hours (50 hrs/wk = 29.8%): $42.96/environment/month
$144/mo
$43/mo
24/7 — always on
168 hrs/week
Business hours
50 hrs/week · Mon–Fri 9am–7pm
Monthly compute cost per environment (8 services)−70% savings
KEY INSIGHT: A single environment at $144/mo compute isn't alarming. It's the multiplication: 30 environments at $144 = $4,325/month in compute. Business hours drops that to $1,288. But neither number includes fixed overhead — which is where the real surprise hides.
This is just the compute math. For the full optimization playbook — scheduling, right-sizing, Spot, and finding orphaned environments — the ECS Fargate cost optimization guide walks through all four methods with cumulative savings at each step.
The fixed overhead — the number nobody talks about
Every ECS environment carries resources that bill by the hour — 24/7, 365 days a year — regardless of whether any tasks are running. Even a fully stopped, scheduled-off environment costs money. Here's the full line-item breakdown:
Application Load Balancer — $22/mo per environment
The ALB base rate is $0.0225/hr per AWS ALB pricing (verified May 2026). That's $16.43/month just for existing. Add Load Balancer Capacity Units (LCU) at $0.008/LCU-hr — a dev environment with minimal traffic uses roughly 1 LCU, adding $5.84. Total: ~$22.27/month per ALB.
Can you share one ALB across environments? Yes — host-based routing lets you route dev.example.com and qa.example.com through the same ALB. But you hit AWS limitsfast: 100 routing rules per listener, 50 TLS certificates. At 8 services × 12 environments = 96 rules, you're near the ceiling. At 50 environments with custom domains, you hit the certificate limit.
NAT Gateway — $65.70/mo per VPC (shared across environments)
NAT Gateway costs $0.045/hr per AZ, per AWS VPC pricing (verified May 2026). In a production-grade HA setup across 2 availability zones, that's $65.70/month before any data flows through it. The catch: NAT Gateway is a per-VPC resource — one NAT Gateway serves every environment in that VPC.
On top of the hourly charge, NAT Gateway bills $0.045 per GB of data processed. A dev environment pulling Docker images, installing packages, and making outbound API calls processes roughly 30–50 GB/month. At 30 environments in one VPC processing 1,200 GB total: that's an additional $54/month in data processing charges.
NAT Gateway cost breakdown, 30 envs in single VPC (2 AZ HA):
Hourly: 2 AZs × $0.045 × 730 hrs = $65.70/mo
Data: 30 envs × 40 GB × $0.045 = $54.00/mo
Per-environment share: $3.99/mo
CloudWatch — $5–8/mo per environment
CloudWatch charges $0.50 per GB ingested and $0.03 per GB-month stored. A moderately active dev environment generating 5–10 GB of logs per month costs $2.50–5.00 in ingestion and pennies in storage. Add ECS container insights at $0.01/metric-hour and you're at $5–8/month per environment — more if you log at debug level.
Data transfer — $10–20/mo per environment
Inter-AZ traffic within the same region: $0.01/GB each direction. A microservice that talks to its database (RDS in another AZ) and other services generates traffic that's hard to trace but easy to accumulate. Internet egress adds more — $0.09/GB for the first 10 TB. A typical dev environment: $10–20/month in data transfer charges.
The extras — Route 53, KMS, Secrets Manager
Route 53 hosted zone: $0.50/month. KMS keys: $1/month each, pro-rated. Secrets Manager: $0.40/secret/month — with 5–10 env-specific secrets, that's $2–4/month per environment. Parameter Store API calls: negligible under standard API limits ($0.05 per 10,000 calls). Total extras: ~$3/month per environment.
KEY INSIGHT: Scheduling stops ECS tasks — it does not stop the ALB. It does not stop CloudWatch ingestion. It does not stop data transfer between services that are still running elsewhere in the VPC. Fixed overhead is the floor your AWS bill can never go below, and it scales linearly with every environment you add.
AWS limits that shape your architecture
Before you decide whether to share an ALB or provision one per environment, you need to know the limits. Most of these are hit silently — AWS doesn't email you when you're at 95 rules out of 100. Your deployment fails and you spend an hour diagnosing a quota you didn't know existed.
| AWS Resource | Limit | What it means for your fleet |
|---|---|---|
| ALB — rules per listener | 100 | Shared ALB across >10 envs hits rule ceiling; each env with 8 services needs 8 rules |
| ALB — certificates | 50 | Per-environment TLS with custom domains caps at ~50 envs per ALB |
| ALB — target groups | 100 | One TG per service → 8 services × 12 envs = 96, near ceiling at 12 envs |
| ECS — services per cluster | 5,000 | Not a practical bottleneck before other limits fire |
| Fargate — vCPU account quota | 4,096 | 4,096 vCPU units ÷ 0.5 vCPU per task = 8,192 simultaneous tasks. At 50 envs × 8 svcs = 400 tasks, well below ceiling |
| NAT GW — per AZ per VPC | 5 | Per-VPC limit. Throughput capped at 45 Gbps; unlikely bottleneck for dev/staging |
Limits verified May 2026 via AWS Service Quotas documentation. Most are soft limits — request increases via AWS Support.
The ALB is the binding constraint.At 100 rules per listener, a shared ALB serving N environments with 8 services each caps out at 12 environments. At 50 TLS certificates, per-environment custom domains cap at 50. These limits are soft — AWS Support will raise them — but they're the reason most teams default to one ALB per environment and accept the ~$22/month charge.
A practical strategy:shared ALBs for non-production environments (dev, qa, demo) where URL format is predictable, and dedicated ALBs for staging and production where isolation matters. At 30 environments — 24 non-prod, 4 staging, 2 prod — that's 1 shared ALB for dev ($22) + 4 staging ALBs ($88) + 2 prod ALBs ($44) = $154/month in ALB costs instead of $660. The shared ALB's 100-rule limit would require 24 envs × 8 services = 192 rules, so you'd need 2 shared ALBs for dev (still cheaper than 24 dedicated ones).
KEY INSIGHT: AWS limits aren't random — the ALB limits in particular define the ceiling on how many environments can share infrastructure. Know them before you hit them. AWS won't warn you.
What 10, 30, and 50 environments actually cost
Same assumptions throughout: 8 services per environment, 0.5 vCPU + 1 GB each, us-east-1 on-demand pricing, single VPC with 2-AZ NAT Gateway HA. Business hours: 50 hours/week, Mon–Fri 9am–7pm.
| Environments | Compute (24/7) | Compute (Biz hrs) | Fixed overhead | Total (24/7) | Total (Biz hrs) |
|---|---|---|---|---|---|
| 10 | $1,442 | $429 | $500 | $1,942 | $929 |
| 30 | $4,325 | $1,287 | $1,410 | $5,735 | $2,697 |
| 50 | $7,208 | $2,145 | $2,280 | $9,488 | $4,425 |
Assumes 8 services/env, 0.5 vCPU + 1 GB per service, us-east-1 on-demand pricing. Business hours: 50 hrs/week (Mon–Fri 9am–7pm). Overhead: ~$90/env scaled down for larger fleets (shared NAT GW across VPC).
At 30 environments, the gap between compute and overhead tells the story: scheduling drops compute from $4,325 to $1,287 — a $3,038 savings. But overhead barely moves, from $1,410 to $1,410. The $1,410 floor stays whether tasks are running or not.
Here's that same data broken down by resource category — showing exactly where the overhead comes from as your fleet grows:
| Fleet | ALBs | NAT GW | CloudWatch | Data xfer | Misc | Total |
|---|---|---|---|---|---|---|
| 3 envs | $66 | $72 | $21 | $36 | $9 | $204 |
| 10 envs | $220 | $84 | $70 | $120 | $30 | $524 |
| 30 envs | $660 | $120 | $210 | $360 | $90 | $1,440 |
| 50 envs | $1,100 | $160 | $350 | $600 | $150 | $2,360 |
All values monthly. NAT GW includes hourly ($0.045/hr × 2 AZs × 730 hrs = $65.70/mo) + data processing ($0.045/GB at 40 GB/env). Single VPC, US East. Misc = Route 53 + KMS + Parameter Store.
$3,615/mo· $43,380/yr
30 environments: $5,735/mo (24/7) → $2,697/mo (business hours + optimized ALBs). Compute savings from scheduling. Overhead savings from shared ALBs, VPC endpoints, and log retention policies.
At 50 environments, the total 24/7 bill is nearly $9,500/month — $114,000/year. More than half of that is compute, but $2,360/month is overhead that doesn't go away with scheduling. That's the baseline the business commits to before the first developer writes a line of code in any environment.
Fargate Spot — dev environments at 68% off
Fargate Spot runs tasks on spare AWS capacity. The discount is significant — and for dev environments, the tradeoff is usually negligible:
Fargate Spot vs On-Demand (Linux/x86, US East):
On-Demand: $0.04048/vCPU-hr + $0.004445/GB-hr
Spot: $0.01291/vCPU-hr + $0.001417/GB-hr
Savings: −68% on compute
For a 0.5 vCPU + 1 GB service, Spot drops the hourly rate from $0.024685 to $0.007872. Per month: $5.75 instead of $18.02. Across 30 dev environments (240 services): $1,380/month instead of $4,325. Combined with business-hours scheduling (50 hrs/week), Spot dev environments drop to $411/month in compute.
The tradeoff: AWS can reclaim Spot capacity with a 2-minute warning. ECS handles this cleanly — it drains connections, sends SIGTERM, and the capacity provider strategy falls back to on-demand if Spot capacity is unavailable.
KEY INSIGHT: A dev environment on Spot + business-hours scheduling (50 hrs/week) costs ~$5.75/service/month instead of $18.02 — a 68% Spot discount layered on top of 70% scheduling savings. For 30 environments (240 services), that's $411/month instead of $4,325. The fixed overhead is still the floor — $1,410/month of ALBs, CloudWatch, and NAT Gateway — but your compute bill drops to near-zero.
Right for Spot: dev environments, CI/CD test runners, batch jobs, any workload that restarts cleanly.
Wrong for Spot:production, staging used for customer demos, anything with a guaranteed uptime requirement. The capacity provider strategy lets you split — 80% Spot / 20% On-Demand — so capacity interruptions don't cause downtime.
Combining Spot with business-hours scheduling compounds the savings — but scheduling has edge cases around timezones, holidays, and ad-hoc overrides. The complete ECS environment scheduling guide covers per-timezone configuration, the EventBridge approach, and the one-click override pattern developers actually need.
Strategies to reduce fixed overhead
Unlike compute, overhead doesn't disappear with scheduling. These strategies target the infrastructure that bills by the hour:
Strategy 1: Shared ALBs with host-based routing
Group 10–12 non-production environments behind one ALB using host-based routing (dev.app.com → target group A, qa.app.com → target group B). Saves $22 × (N − 1) per month. Align to the 100-rule limit. Use wildcard certificates (*.dev.example.com) to stay under the 50-certificate limit. If your services are all on the same domain with path-based routing, the 100-rule ceiling rises to 100 services (not environments).
Strategy 2: VPC endpoints bypass NAT Gateway
Create VPC endpoints for S3, DynamoDB, ECR (both API and Docker registry), CloudWatch Logs, and Secrets Manager. Each endpoint costs $0.01/hr ($7.30/month) but eliminates NAT Gateway data processing charges for those AWS services. If 60% of your NAT Gateway traffic goes to AWS services (ECR pulls, CloudWatch pushes, S3), a $7.30 VPC endpoint saves $32/month in NAT data charges. Gateway endpoints (S3, DynamoDB) are free — interface endpoints cost but still net out cheaper for high-traffic environments.
Strategy 3: CloudWatch log retention and sampling
Set log group retention to 30 days for development environments, 90 days for staging, and 365 days for production. A dev environment generating 10 GB/month with indefinite retention costs $3.60/year in storage alone. At 30 environments, that's $108/year for logs nobody will ever read. Short retention also reduces the storage footprint, but the real savings come from reducing ingestion — set your dev services to INFO level, not DEBUG.
Strategy 4: Consolidate VPCs
Each VPC with 2-AZ NAT Gateway HA costs a baseline $65.70/month. If your team manages 3 VPCs (dev, staging, prod), that's $197/month just for NAT Gateways. Consolidating non-production into a single VPC (with appropriate security groups and network ACLs for isolation) cuts that to $65.70/month. The tradeoff is blast radius — but for non-prod workloads, it's usually acceptable.
Summary: dedicated vs optimized overhead
| Strategy | Dedicated (1 ALB/env) | Optimized |
|---|---|---|
| ALBs (30 envs) | $660 | $176 |
| NAT GW (1 VPC, 2 AZ) | $65.70 | $65.70 |
| NAT GW data (30 envs × 40 GB) | $54 | $18 |
| VPC endpoints (ECR, CW, S3, DDB) | $0 | $73 |
| CloudWatch (30 envs) | $210 | $140 |
| Data transfer (30 envs) | $360 | $360 |
| Total overhead (30 envs) | $1,350 | $833 |
Optimized: 3 shared ALBs (12 envs each), VPC endpoints for AWS services (cuts NAT data by 67%), CloudWatch log retention policies, consolidated VPC. All values monthly.
Fargate vs EC2 — when each makes sense
Every cost conversation about Fargate eventually arrives at the comparison with EC2. The answer depends on utilization:
“At high, steady utilization, EC2 is cheaper — reserved instances cut 30–50%. At bursty, sporadic utilization (dev environments, batch jobs), Fargate wins on both cost and ops burden. The breakeven is roughly 60% average utilization.”
— Analysis based on Fargate on-demand pricing vs EC2 t3.small with 1-year RI, May 2026
A t3.small Reserved Instance (2 vCPU, 2 GB) costs ~$11.60/month with a 1-year all-upfront RI. A comparable Fargate service (1 vCPU, 2 GB) running 24/7 costs $0.04048 + 2 × $0.004445 = $0.04937/hr = $36.04/month. EC2 wins on raw cost at steady state.
But that math changes completely when you factor in scheduling. The same Fargate service on business hours (50 hrs/week) costs $10.74/month — cheaper than the EC2 RI — and you never touch an AMI, a kernel patch, or an ASG configuration.
| Aspect | Fargate | ECS on EC2 |
|---|---|---|
| Instance management | None | You manage AMIs, patching, scaling |
| Per-second billing | Yes — from task start | Per-hour (or per-second for some AMIs) |
| Cost at steady 80% util | Higher — no reserved pricing | Lower — Savings Plans cut 30–50% |
| Cost at bursty/sporadic | Lower — pay only when used | Higher — instances idle between bursts |
| Cold start | 30–90s | 3–5 min (instance launch) |
| Spot discount | ~68% (Fargate Spot) | 60–90% (EC2 Spot) |
| Scaling granularity | Per-task (0.25 vCPU increments) | Per-instance (whole VM) |
| Breakeven point | Wins below ~60% avg utilization | Wins above ~60% avg utilization |
For dev and staging environments specifically: Fargate + Spot + scheduling is the optimal combination. EC2 instances sitting idle during off-hours waste more money because instance-hours are coarser than task-seconds. The base overhead (ALB, NAT GW, CloudWatch) is the same either way.
If you read this, you might also want to know
What if I use ECS on EC2 instead of Fargate for dev environments?
The scheduling logic is the same — stop/start via ASG desired capacity. The cost math changes: EC2 instances bill per instance-hour regardless of utilization. A t3.small at $0.0208/hr (on-demand) running 730 hours = $15.18/mo. On business hours: $4.52/mo. But you now own AMI patching, kernel updates, OS-level monitoring, and instance capacity planning. For dev environments where ops burden should be minimal, Fargate's per-task model is almost always the right call — even if EC2 looks cheaper on the hourly rate.
Can I eliminate the NAT Gateway cost entirely?
If your tasks only communicate with AWS services reachable via VPC endpoints (S3, DynamoDB, ECR, CloudWatch Logs, Secrets Manager, SSM, KMS, STS), you can. But if any task pulls a public Docker image, hits a third-party API, installs packages from the internet, or sends outbound webhooks, you need either a NAT Gateway or a NAT instance. NAT instances (t3.nano, ~$3.80/mo) are a cheaper alternative to NAT Gateway but come with their own maintenance burden: you manage the instance, its auto-scaling, and its bandwidth limits (~5 Gbps vs NAT Gateway's 45 Gbps).
How do I calculate this for my specific fleet?
Start with a list of every environment and every service. Pull actual CloudWatch utilization data (CPU, memory) over the last 30 days — not the provisioned values. Identify services that never exceed 30% CPU (candidates for halving vCPU). Pull your AWS bill and filter by region, then by service (ELB, NATGateway, CloudWatch, DataTransfer). Tag everything — without cost allocation tags, you cannot attribute overhead to specific environments. Then plug the numbers into the same formula: per-service compute = (vCPU × $0.04048 + GB × $0.004445) × active_hours + overhead_share. The Fortem ECS cost calculator (fortem.dev/ecs-cost-calculator) does this automatically with your real fleet data.
Common questions
Does scheduling stop the fixed overhead too?
No — scheduling only stops ECS task compute. Your Application Load Balancer ($0.0225/hr), NAT Gateway ($0.045/hr per AZ), CloudWatch log ingestion, and data transfer keep billing 24/7. If your environment has an ALB, that ALB costs ~$22/mo regardless of whether tasks are running behind it. Scheduling cuts compute cost — fixed overhead needs different strategies.
Can I use Fargate Spot for staging environments?
Yes — Fargate Spot gives a ~68% discount ($0.01291/vCPU-hr vs $0.04048 on-demand). The trade-off: AWS can reclaim capacity with a 2-minute notice. For staging used for automated tests, Spot is perfectly fine. If staging hosts customer demos or needs reliable uptime during business hours, use on-demand for those specific services.
How do NAT Gateway costs scale with data transfer?
NAT Gateway charges two ways: $0.045/hr per AZ (fixed, ~$33/mo per AZ) plus $0.045/GB data processed. A dev environment pulling Docker images and packages through NAT can easily process 30–50 GB/mo, adding $1.35–2.25/mo in data charges per env. At 30 environments, NAT data processing alone can hit $40–70/mo — on top of the hourly charge.
What's cheaper — one ALB per environment or one shared ALB?
A shared ALB is materially cheaper. One ALB costs ~$22/mo vs $22 × N for dedicated ALBs. But you hit AWS limits: 100 rules per listener, 50 certificates, 100 target groups. At ~8 services × N environments, you exhaust the 100-rule limit around 10–12 environments. If your URLs follow a predictable pattern (e.g., dev.example.com, qa.example.com), host-based routing works. If you need per-environment TLS with custom domains, the certificate limit constrains you to ~50 environments per shared ALB.
How accurate is AWS Cost Explorer for per-environment tracking?
Cost Explorer is accurate to the billing line-item but useless for environment attribution unless you tag resources. Without cost allocation tags on your ECS services, ALBs, and other resources, Cost Explorer shows a single lump sum for Fargate compute across all environments. You need to activate cost allocation tags in the Billing console, tag every resource with an Environment key, and wait 24–48 hours for tags to propagate. Even then, some charges (data transfer, NAT Gateway processing) don't support tags — they appear as aggregate line items.
### See what each of your environments actually costs We'll break down your actu
See your real per-env cost: fortem.dev/ecs-cost-calculator
Top comments (0)