Cut AWS Bills by 50–75% with EC2 and RDS Parking
Source: Dev.to
Best practices for reducing AWS compute spend
Abstract
Cloud compute spend is one of the most visible and controllable components of AWS infrastructure costs, yet many organizations still pay for idle resources. Development, testing, UAT, QA, sandbox, and demo environments often run 24/7 out of convenience, even though they are only needed during business hours. Automatically stopping (“parking”) resources such as Amazon EC2 and Amazon RDS during off‑hours is a straightforward AWS cost‑optimization technique that can drive 50‑75 % savings with zero changes to applications or developer workflows.
This post explains why parking matters, presents consolidated cost data, covers EC2 and RDS applicability, outlines a simple architecture pattern, and highlights when parking yields maximum value—especially when non‑production environments can be shut down during weekday off‑hours and all day on weekends.
Why Parking Compute Matters?
Idle compute is one of the most common sources of wasted cloud spend. By default, Amazon EC2 and Amazon RDS run 24 × 7 unless explicitly stopped, so organizations frequently pay for runtime they do not need. AWS reference architectures for development environments show that scheduling compute for weekday usage can reduce runtime from 168 hours/week to ~45 hours/week, yielding roughly ~70 % savings on compute.
Idle compute typically exists in:
- Low environments (Dev / QA / UAT / Stage)
- Demo, sandbox, and training environments
Business reality: non‑production environments rarely need 24 × 7 uptime, making them ideal candidates for parking.
Cost Impact of Parking
To illustrate the impact, consider two common resource types: EC2 and RDS.
EC2 Example
| Metric | Always‑On | Parked (Mon–Fri, 9 am–6 pm) |
|---|---|---|
| Hours/week | 168 | ~45 |
| Monthly Cost | $61.85 | $16.55 |
| Savings | — | ~73 % |
Key context
- Instance:
c5.large - On‑demand price: ~ $0.085 /hr (US regions – exact pricing varies by region)
RDS Example
Amazon RDS can also be parked (start/stop) for several engines including PostgreSQL, MySQL, and MariaDB.
Note: RDS auto‑restarts after 7 days if left stopped (source).
| Metric | Always‑On | Parked (Mon–Fri, 9 am–6 pm) |
|---|---|---|
| Monthly Compute | $48.71 | $13.25 |
| Storage | Unchanged | Unchanged |
| Savings | — | ~73 % (compute) |
Key context
- Instance:
db.t3.medium - On‑demand price: ~ $0.067 /hr (US regions – exact pricing varies by region)
Small Stack Example
| Resource | Always‑On | Parked |
|---|---|---|
EC2 (10 × c5.large) | ~$618.50 | ~$165.50 |
RDS Compute (3 × db.t3.medium) | ~$146.13 | ~$39.75 |
| RDS Storage (3 ×) | ~$30.00 | ~$30.00 |
| Total | $794.63 | $235.25 |
- Monthly Savings: ~$559.38 (~70 %)
- Annual Savings: ~$6,700 / year
Scaled across 3–5 environments, parking can deliver tens of thousands per year with minimal engineering effort!
Where Parking Makes Sense
Parking delivers the most value when environments are:
- Non‑Production – Dev / QA / UAT / Stage / Demo / Sandbox
- Business‑Hours Driven – Teams working 08:00–19:00, Mon–Fri (no weekend activity)
Many organizations also have multiple non‑production environments per microservice, multiplying waste if left running 24 × 7.
Architecture Pattern
At a high level, the solution uses AWS scheduling and resource tagging to automatically stop and start non‑production compute resources without manual intervention.
The typical pattern
- Amazon EventBridge defines cron‑based schedules for start/stop windows.
- EventBridge invokes an AWS Lambda during those windows.
- Lambda uses tags (e.g.,
Parking=Enabled,Env=Dev|QA|Stage) to identify resources. - Lambda stops EC2 and RDS during off‑hours and starts them for business hours.
No instance IDs or manual lists — the system is fully tag‑driven.
This keeps participation flexible: teams opt‑in via tags, and resources automatically turn on and off according to defined schedules.
Conclusion
Parking AWS compute resources such as Amazon EC2 and Amazon RDS during off‑hours is one of the simplest and highest‑impact AWS cost‑optimization techniques available. It delivers 50–75 % savings by eliminating idle compute spend, especially across non‑production environments that only need to be available during weekday business hours. Using scheduled triggers, tagging, and lightweight Lambda automation, organizations can achieve substantial cost reductions with minimal engineering effort.
Automation can be implemented with minimal operational overhead and without affecting developer productivity or application performance. If you already use Terraform, CI/CD, or internal platforms, integrate tag‑based parking to make cost efficiency an always‑on capability across your engineering organization.