How to Cut AWS Costs Without Reserved Instances
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 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. Five methods address that directly.
- ·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?
“Reserved Instances give you up to 66% off list price for committed usage — but they don't change total consumption. You're still paying for 168 hours per week per environment.”
— AWS Savings Plans documentation
RIs give up to 66% off — but they change the price per unit, not units consumed. Scheduling those same environments saves 1.75× more than RIs on non-prod. Go to the AWS Savings Plans console and commit to a 1-year plan for your production workloads. It's a up to 66% discount on list price for zero engineering effort. This is the lowest-hanging fruit in AWS cost optimization. Do it first.
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.
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.
Method 1: Schedule environments (60–70% savings)
Stopping non-prod environments outside business hours cuts 168 hrs/week to ~50 hrs — a 70% reduction that saves more than any RI, for zero engineering cost. 168 hrs → 55 hrs = 67% reduction. Fargate stops to $0 instantly. EC2: scale ASG to 0. This single change saves more than any RI ever will — and costs $0 to implement.
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.
Scheduling costs $0 to implement — it's purely an operational change. No Terraform modifications. No new resources. Stopping services when nobody is using them is the highest-ROI change most ECS teams can make. 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 for ECS environments (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)
Check CloudWatch Container Insights p95 metrics against allocated CPU/memory — most ECS tasks run at 15–30% allocation, and cutting to p95×3 saves 50–75% on that task. Set task size to p95 + 50% headroom. A 1 vCPU → 0.5 vCPU cut saves 50% on that task — instantly.
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. Teams running many environments often find that ECS Fargate cost visibility gaps make right-sizing harder than it should be — the data exists, but it's spread across too many dashboards.
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 needs. Right-size the task definition to 256 (p95 87 × 3 = 261 ≈ 256) and you cut its Fargate cost by 75%.
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 ~70% off on-demand pricing with a 2-minute interruption notice — ideal for CI/CD, batch, and dev environments. Good for: CI/CD, batch, dev environments. Bad for: production. Combined with scheduling: Spot during business hours, auto-stop outside. The cheapest compute on AWS.
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.
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, only a brief shift to on-demand.
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 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
Environments with no deployments and no log activity for 6+ days are automatically stopped via a CloudTrail + Lambda rule, with a Slack alert for one-click restart. Implement with CloudTrail event monitoring + Lambda. The hard part: defining 'idle'. No deployments? No API calls? No console logins? Pick one and enforce it.
This is different from scheduling. Scheduling is predictable — environments stop and start on a fixed calendar. Auto-stop targets environments that shouldbe 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.”
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
Tag every resource with an owner at provisioning, run a monthly audit against the team directory, and delete any environment with no owner and no deploy in 30+ days. Monthly audit: cross-reference with team directory. Ownerless resources → platform team review. Most teams find 1-3 orphaned environments at $200-400/mo each. Recovery: $500-1,200/mo immediately.
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 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.
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 the five methods by impact-to-effort ratio: scheduling first, then right-sizing, then Spot, then auto-stop, then orphan deletion — implement one per week, not all at once. 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. |
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.
Fortem automates scheduling, idle detection, and orphan identification across every ECS Fargate environment in your fleet — no Terraform changes, no Lambda functions to maintain. Connect your AWS account and the savings surface in under 20 minutes.
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 do I convince finance to approve scheduling instead of RIs?
RIs require 1-3 year commitment. Scheduling costs $0 to implement. Present the math: 10 dev environments at $200/mo each = $2,000/mo. Scheduling at 60% savings = $1,200/mo saved immediately, zero commitment. Finance understands zero-risk savings better than long-term commitments.
Does scheduling affect my production environments?
No — scheduling applies to non-production environments only. Production always runs 24/7. Tag everything tagged environment=dev,staging,qa,demo for schedules. Leave production tags untouched. Most teams realise 60-70% of their ECS bill is non-production.
What's the difference between Savings Plans and Reserved Instances for ECS?
Savings Plans apply to Fargate usage directly — no instance selection needed. RIs apply to specific EC2 instance types for ECS on EC2. Compute Savings Plans give the most flexibility: 1-3 year commit, applies to Fargate, EC2, and Lambda.
Stop optimizing the pricing model. Start optimizing what runs.
Fortem automates all five methods — scheduling, right-sizing recommendations, Spot, idle detection, and orphan identification. 20 minutes. No Terraform changes needed.
Response within 4 hours, weekdays.