Cloud Costs, AWS
Your production environment is optimized. Your dev and staging environments are bleeding.
I kept thinking “we have heard this cost visibility, cloud tagging and attribution story one too many times.” For me, the game changing moment was when Aran began talking about reducing risk, proactive planning, and creating a secondary marketplace.
Cloud waste in non-production environments is one of the most underappreciated cost problems in engineering organizations. It's not glamorous. It doesn't show up in a single alarming line. item. But for most companies running active development and staging environments on AWS or Azure, non-production waste easily accounts for 20–40% of total cloud spend, .and most of it is invisible until someone actually looks.
The challenge isn't identifying that the problem exists. It's fixing it without creating friction for the engineers who depend on those environments every day. The moment a cost initiative starts slowing down development velocity, it loses the room.
This guide covers how to cut cloud waste across dev, staging, and production environments systematically, without becoming the team that turns off someone's environment at the wrong moment.
Development and staging environments share a few characteristics that make them disproportionately expensive relative to their actual usage:
They run around the clock, even when no one is using them. A dev environment that stood up on Monday for a sprint often runs continuously through the weekend, accumulating on-demand charges for 168 hours even if it was only actively used for 40.
They're often over-provisioned. Engineers standing up dev environments tend to mirror production specs "just to be safe." A production database running on an r6g.4xlarge doesn't need a dev replica running on the same instance,. but that's often what gets provisioned.
They proliferate without governance. Dev environments get created quickly and deleted slowly, if at all. Stale environments from completed features, abandoned experiments, or departed employees accumulate silently.
They're rarely committed. Because dev and staging are perceived as "temporary," they almost always run on on-demand pricing, even when they're actually semi-permanent fixtures that have been running for months. Insured Commitments are purpose-built for exactly this scenario.
The mistake most teams make is applying a single optimization playbook across all environments. Dev, staging, and production have different usage patterns and need different solutions.
The primary waste driver in dev is idle time. Development workloads are active during working hours and idle the rest of the time, yet most dev environments run 24/7 on full on-demand pricing.
What to do:
Schedule automatic start/stop for dev environments based on working hours. A dev environment that runs 10 hours a day instead of 24 reduces that environment's compute cost by 58% overnight. No architecture changes required.
Enforce rightsizing from the start. Dev environments do not need production-equivalent specs for most workloads. Define organizational standards for dev instance sizes and enforce them at provisioning time, not after the fact.
Implement environment expiration policies. Any dev environment that hasn't been actively used in N days (30 is a common threshold) should trigger an automated notification — and if not renewed, an automated shutdown. This eliminates the long tail of forgotten environments.
Archera's Advanced Reporting gives your engineering and FinOps teams visibility into usage by environment, team, and application, making it easy to identify idle dev resources and quantify the savings opportunity.
Staging sits between dev and production in both usage patterns and optimization complexity. Staging environments typically need to be available during business hours, but they don't need to run continuously at full production scale.
What to do:
Use smaller instance families for staging where full production parity isn't required. For load testing and performance validation, you do need production-equivalent environments, but not for routine QA, integration testing, or feature validation.
Apply scheduling where the testing cadence allows. If your staging environment is used for CI/CD pipeline runs, you may be able to size it down or schedule it around your actual pipeline schedule rather than running continuously.
Consider using Insured Commitments for semi-permanent staging environments. If a staging environment has been running consistently for more than 60 days, it's no longer truly ephemeral, it's a semi-permanent workload that should be committed. Archera's Insured Commitments let you access committed pricing on staging environments with terms as short as 30 days, so you get the discount without the lock-in risk if you need to spin that environment down.
Not sure which of your staging workloads are committable? Archera's free platform helps you identify coverage gaps and model the savings of committing non-production environments.
Production is where the real commitment opportunity lives. Production workloads are stable, predictable, and almost always under-committed relative to what's achievable.
What to do:
Maximize commitment coverage on stable production workloads. For any production service that has been running at consistent utilization for 60+ days, the case for a committed pricing instrument is strong.
For production workloads that are less predictable (newer services, seasonally variable traffic, workloads tied to business events) Archera's Insured Commitments provide a way to access committed pricing without taking on the full term risk.
Implement continuous utilization monitoring. Commitment coverage is not static. New services launch, old ones get deprecated, traffic patterns shift. Production commitment portfolios need to be reviewed and adjusted continuously, not annually.
Archera's platform automates this entire lifecycle across all your production accounts and regions.
Book a demo to see it in action →
Tagging is non-negotiable. You cannot optimize what you cannot see. Every resource across every environment needs consistent tags for environment type, team, application, and cost center. Enforce tagging at provisioning time, not retroactively.
Give teams visibility into their own costs. Cost accountability is most effective when the teams generating the costs can see them in real time. Showback reports that surface per-team and per-environment costs to engineering managers create natural incentives for optimization without requiring top-down mandates, a core principle of any mature FinOps practice.
Don't conflate optimization with restriction. The goal is to eliminate waste, not to reduce the resources teams need to do their jobs. Optimization policies should be designed around automation and sensible defaults, not bureaucratic gatekeeping.
Track unit economics, not just absolute spend. As your product grows, your cloud spend will grow with it. The right metric isn't "did cloud spend go up?" — it's "did cost-per-customer or cost-per-feature go up?" Archera's Advanced Reporting helps teams track exactly these unit economics, giving engineering and finance a shared language for evaluating cloud efficiency.
Ready to give every stakeholder a unified view of your cloud costs by environment, team, and product? Explore Archera Advanced Reporting →
If you're not sure where to start, the highest-leverage first step is visibility: understanding where your cloud spend is actually going across dev, staging, and production, by team and by application.
Archera's free platform connects to your AWS and Azure accounts and gives you that visibility immediately; including utilization data, coverage gaps, and the savings potential of better commitment coverage across all your environments. No infrastructure changes, no percentage-of-savings fees.
Start cutting waste without slowing down your team. Get started with Archera for free →
Or talk to our team about your specific environment setup: Book a demo →
