How We Cut AWS Staging Costs by 87% With EventBridge Scheduler
No code changes. No Lambda functions. No complex scripts. Just 4 schedulers and a realization that nobody uses staging at 3am.
Here's a question every engineering team should ask themselves:
"When was the last time someone actually used our staging environment at 2am?"
For us? Never. Not once.
Yet we were paying for it — EC2 running, ECS Fargate tasks spinning, compute burning money — every single hour of every single day, including weekends, holidays, and the 21 hours per day when nobody on our team was even awake.
That's the hidden tax of staging environments. And most teams never fix it because the solution feels complicated.
It isn't.
This is how we cut our staging compute costs by 87.5% — using AWS EventBridge Scheduler, zero Lambda functions, and zero lines of application code.
The Problem: Staging Was Running 24/7 For No Reason
Our staging environment had two resources running around the clock:
- EC2 instance — our staging app server
- ECS Fargate service — our backend API container
Our team actively uses staging for roughly 3 hours a day. That's it.
The math was embarrassing:
Running: 24 hours/day
Used: 3 hours/day
Wasted: 21 hours/day = 87.5% of compute going nowhere
Monthly cost breakdown:
EC2 + ECS Fargate (24x7): ~$19.18/month
EC2 + ECS Fargate (3hr/day): ~$2.40/month
Monthly saving: $16.78
Yearly saving: $201.35
Reduction: 87.5%
$201/year saved on staging compute alone — with 45 minutes of setup and zero application code changes.
Multiply that across dev environments, QA clusters, review apps, and load test environments. The savings compound fast.
The Solution: AWS EventBridge Scheduler
Most engineers reach for Lambda when they need to automate AWS tasks on a schedule. That works — but it means writing code, managing runtimes, setting up CloudWatch Logs, and maintaining a function forever.
EventBridge Scheduler is the better tool here. It lets you call any AWS SDK action directly on a cron schedule — no Lambda, no code, no runtime to maintain.
The mental model is simple:
WHEN → cron expression (with native timezone support)
WHAT → any AWS API call (StartInstances, UpdateService, StopDBInstance...)
WHO → a dedicated IAM role with just enough permissions
That's the entire service. And it's free for the first 14 million invocations per month.
What We Built: 4 Schedulers
We created 4 EventBridge Schedulers targeting our staging resources:
| Scheduler | Fires At | Action |
|---|---|---|
staging-ec2-start |
9:00 PM IST daily | Start staging EC2 instance |
staging-ec2-stop |
12:00 AM IST daily | Stop staging EC2 instance |
staging-ecs-scale-up |
9:00 PM IST daily | ECS service desiredCount to 1 |
staging-ecs-scale-down |
12:00 AM IST daily | ECS service desiredCount to 0 |
Result:
Timeline (IST):
─────────────────────────────────────────────────────
12:00 AM |████████████ OFF (21 hrs) ████████████| 9:00 PM
│
9:00 PM
┌──────────────┐
│ EC2 starts │
│ ECS → 1 task │
└──────┬───────┘
│
┌──────▼───────┐
│ RUNNING │
│ (3 hours) │
└──────┬───────┘
│
12:00 AM
┌──────────────┐
│ EC2 stops │
│ ECS → 0 tasks│
└──────────────┘
Staging wakes up exactly when the team needs it. Goes dark at midnight. Every day. Automatically.
The Architecture
AWS EventBridge Scheduler
│
├── staging-ec2-start ──► 9 PM IST ──► ec2:StartInstances
├── staging-ec2-stop ──► 12 AM IST ──► ec2:StopInstances
├── staging-ecs-scale-up ──► 9 PM IST ──► ecs:UpdateService (count=1)
└── staging-ecs-scale-down──► 12 AM IST ──► ecs:UpdateService (count=0)
│
└── All using: staging-scheduler-role (least privilege IAM)
One dedicated IAM role. Four schedulers. Zero Lambda functions.
EventBridge Scheduler vs Lambda + Cron
| Lambda + EventBridge Rule | EventBridge Scheduler | |
|---|---|---|
| Code to write | ~30 lines per action | Zero |
| Runtime maintenance | Lambda versions, updates | None |
| Timezone handling | Manual UTC math | Built-in |
| Retry on failure | Manual implementation | Built-in |
| Setup time | 20-30 mins per action | 5 mins per action |
| Debugging | CloudWatch Logs setup | Native console |
For simple time-based AWS automation, EventBridge Scheduler removes an entire layer of complexity.
Key Things to Know Before You Implement
The IAM role is the foundation — and where most people get stuck.
EventBridge Scheduler needs a role with the correct trust principal. There's a very common mistake here — getting this one thing wrong means your schedulers silently do nothing. Scope the role permissions to specific resource ARNs only. A staging scheduler role should be physically incapable of touching production.
Cron expressions use UTC by default.
Set the timezone parameter to your team's actual timezone. Forgetting this means your staging shuts down at the wrong time and your team spends 20 minutes debugging before realizing it's a UTC offset issue.
desiredCount: 0 is not the same as deleting the ECS service.
Setting desired count to zero stops all running tasks but preserves the full service definition, task definition, and all configuration. Scale back up to 1 and everything restarts exactly as before — same image, same env vars, same everything.
stopInstances is not terminateInstances.
Stopping preserves the EBS volume and all data. Terminating destroys it permanently. Our schedulers stop — never terminate.
Account for application warm-up time.
EC2 boot + ECS task startup + application initialization can take 3-5 minutes total. Schedule your start 10-15 minutes before your team actually needs it. We start at 8:45 PM for a 9 PM working session.
What Else Can You Schedule?
Once you understand this pattern, every always-on non-production resource is a candidate:
- RDS instances — stop during nights, save $15-50/month per instance
- DocumentDB clusters — same pattern, significant savings
- Auto Scaling Groups — scale to minimum overnight
- Additional ECS services — any non-prod service
- ElastiCache — stop non-prod caches at night
Every resource running at 3am that nobody needs is costing you money right now.
The Results
BEFORE: $19.18/month (24x7 always on)
AFTER: $2.40/month (3hrs/day scheduled)
Saving: $16.78/month
$201.35/year
87.5% reduction
Zero code changes. Zero Lambda functions. Zero new infrastructure.
Four schedulers calling two AWS APIs on a cron. That's it.
Lessons Learned
1. Analyze your actual usage before setting the schedule.
We assumed our team used staging 9 AM to 6 PM. The access logs showed 9 PM to midnight. Data beats assumptions every single time. Check your logs first.
2. EventBridge Scheduler and EventBridge Rules are completely different services.
Scheduler is time-driven. Rules are event-driven. The IAM trust principal, console location, and configuration format are all different. If you Google EventBridge automation and follow a tutorial, make sure it's for Scheduler — not Rules.
3. Separate schedulers per resource type.
EC2 and ECS need different API targets. Keep them as separate schedulers — cleaner, easier to debug, independently adjustable.
4. Weekend-only shutdown pushes savings higher.
If your team doesn't use staging on weekends, a single cron parameter change takes savings from 87.5% to ~94%. Worth knowing.
5. Always have a manual override plan.
Sometimes you need staging at 2am — production incident, urgent hotfix, client demo. Know how to start resources manually in 30 seconds without waiting for the next scheduled start.
Non-Production Cost Checklist
Today:
☐ Identify all always-on non-production EC2 instances
☐ Identify all always-on non-production ECS services
☐ Calculate actual usage hours vs paid running hours
This week:
☐ Set up EventBridge Schedulers for staging resources
☐ Stop non-prod RDS during off-hours
☐ Remove unused Elastic IPs (charged even when unattached)
Next sprint:
☐ Right-size non-prod instances based on actual usage
☐ Audit unused snapshots, AMIs, old EBS volumes
☐ Check for idle NAT Gateways (~$32/month each, easy to forget)
The Bigger Picture
This isn't really about the $201.
It's about the habit.
Every always-on non-production resource is a signal that your team treats cloud infrastructure like physical servers — provision once, leave forever. That habit is slightly expensive at small scale. At growth scale, it becomes a serious line item that nobody owns.
EventBridge Scheduler is the simplest tool to break that habit. Set it up once, forget it, and let AWS enforce the discipline automatically every single night.
Applied across all your non-production environments, teams typically see 40-70% reduction in total non-production AWS spend.
The cost of doing this: 45 minutes.
The cost of not doing this: compounding waste, every month, forever.
Implementing something similar or have a different approach? Drop it in the comments — I read everything.
If this saved you money, share it with someone still paying for an always-on staging environment.
Tags: #AWS #DevOps #CloudCost #ECS #EventBridge #CostOptimization #Fargate #EC2 #FinOps
Top comments (0)