DEV Community: Ronak Sharma

AWS EC2 Cost Optimization: 12 Ways Enterprises Can Reduce Compute Spend

Ronak Sharma — Tue, 11 Aug 2026 05:25:49 +0000

EC2 is usually the single largest line item on an enterprise AWS bill, and it's also usually the least examined, because it's treated as a fixed cost of doing business rather than a genuinely optimizable one. That's backwards. Compute is one of the most flexible categories of cloud spend that exists it just requires someone to actually treat it that way instead of provisioning once and leaving it alone indefinitely.

We consistently find 25-40% in achievable EC2 savings during enterprise cost reviews, and it's rarely one dramatic fix. It's usually a combination of the twelve things below, each contributing something real, none of them individually requiring a major re-architecture.

Rightsize Based on Actual Utilization, Not Original Assumptions

The most common and most consequential mistake is running instances sized for a peak or a worst-case scenario that either never fully materialized or only happens rarely. CloudWatch utilization data CPU, memory, network over a meaningful window will tell you honestly whether an instance is actually using the capacity it's paying for. We routinely find production instances running at 15-20% average utilization, sized years earlier for a load that either changed or was overestimated from the start. Rightsizing to match actual usage, with reasonable headroom rather than the original defensive buffer, is consistently the single largest lever available.

Use Savings Plans and Reserved Instances for Predictable Workloads

On-demand pricing is the most expensive way to run anything with genuinely steady, predictable usage. Savings Plans and Reserved Instances offer substantial discounts often 40-60% in exchange for a usage commitment. The mistake isn't avoiding these entirely; it's either ignoring them for workloads that are clearly steady-state, or over-committing based on projected growth that doesn't materialize on schedule. Match commitment level to genuinely predictable baseline usage, and layer on-demand or Spot on top for the variable portion.

Use Spot Instances for Fault-Tolerant Workloads

Spot Instances offer discounts up to 90% off on-demand pricing, in exchange for the possibility AWS can reclaim the instance with short notice. For workloads that can tolerate interruption batch processing, CI/CD pipelines, stateless services behind proper auto-scaling, big data processing this is a substantial, underused lever. The barrier is usually architectural rather than financial: workloads need to be designed for interruption tolerance from the start. Retrofitting that tolerance into an existing workload is real engineering effort, but for high-volume, interruption-tolerant use cases, the savings justify it.

Implement Auto Scaling Properly, Not Just Nominally

A lot of enterprises have auto-scaling configured technically but not tuned meaningfully scaling thresholds set conservatively enough that the group rarely actually scales down, which defeats much of the point. Properly tuned auto-scaling, with realistic thresholds based on actual traffic patterns rather than defensive padding, means paying for capacity that matches real-time demand instead of provisioning for peak and running that peak capacity around the clock regardless of actual load.

Schedule Non-Production Environments to Shut Down Outside Business Hours

Development, staging, and test environments frequently run 24/7 when they're genuinely only used during business hours, sometimes only a few days a week depending on team cadence. Automated start/stop scheduling genuinely enforced, not just configured once and forgotten can cut costs for these environments by 60-70%, since a typical business-hours-only schedule covers a fraction of the week compared to continuous operation. This is one of the lowest-risk optimizations on this list, because it touches nothing in production.

Eliminate Idle and Orphaned Instances

Every enterprise account accumulates instances that are technically running and passing health checks while providing no actual business value abandoned proof-of-concepts, services replaced by something else but never formally decommissioned, environments spun up for a project that's since wrapped. These don't show up as an obvious problem in standard monitoring, because monitoring typically confirms an instance is healthy, not that it's still needed. Regular review specifically targeting genuine utilization, not just uptime, is the only way this category gets caught consistently.

Consolidate Workloads Onto Fewer, Better-Utilized Instances

Running many small, lightly-utilized instances is frequently less efficient than running fewer, properly-sized instances handling consolidated workloads. This isn't universally true some workloads genuinely need isolation for security or reliability reasons but where consolidation is architecturally reasonable, it reduces both the per-instance overhead cost and the operational overhead of managing a larger fleet of individually underutilized resources.

Use Graviton (ARM-Based) Instances Where Workloads Support Them

AWS's Graviton processors offer meaningfully better price-performance than comparable x86 instances for workloads that support ARM architecture commonly 20-40% better price-performance depending on the specific workload. Migration requires testing for compatibility, since not every application or dependency supports ARM cleanly out of the box, but for workloads that do many modern web applications, containerized services, and data processing workloads this is a substantial, often underexplored lever that doesn't require any change in usage pattern, just a change in instance family.

Review and Optimize EBS Volumes Attached to EC2 Instances

Storage attached to compute is easy to overlook in a conversation focused on the compute cost itself, but oversized or unnecessarily high-performance EBS volumes add up. Reviewing actual IOPS and throughput requirements against what's currently provisioned frequently reveals volumes sized for a performance tier the workload never actually needed, or general-purpose volumes that could be moved to a cheaper tier without any noticeable performance impact for that specific workload.

Turn Off or Rightsize Instances Behind Deprecated Applications

This sounds obvious and gets missed constantly at real scale. When an application gets replaced or deprecated, the instances behind it don't always get decommissioned in the same project sometimes because of lingering uncertainty about dependencies, sometimes just because nobody assigned that specific cleanup task to anyone. A deliberate decommissioning step, tied directly to any application replacement or migration project, closes this gap far more reliably than hoping someone remembers to circle back afterward.

Use Compute Optimizer and Cost Explorer Actively, Not Passively

AWS provides genuinely useful native tooling for this entire category Compute Optimizer generates specific rightsizing recommendations based on actual usage patterns, and Cost Explorer surfaces spend trends and anomalies. The tooling exists at most enterprises already, included in the platform, and goes unused not because it's hard to access but because nobody's specifically assigned to review its output on a defined schedule. Recommendations sitting unread in a console provide exactly zero value regardless of how accurate they are.

Build Genuine Cost Accountability Into Engineering Culture

This is the least technical item on the list and arguably the most important one, because it's what makes the other eleven sustainable rather than a one-time cleanup project that quietly reverses itself over the following year. When engineering teams have visibility into what their specific services actually cost, and some real accountability for that cost as part of how their work gets evaluated, optimization becomes an ongoing practice woven into normal decisions rather than a periodic audit imposed from outside by someone else. Teams that can see their own cost impact directly tend to make better provisioning decisions on their own, without needing to be told to, simply because the information and the incentive are both actually present at decision time.

Why This List Works Better as a Combination Than Any Single Item

None of these twelve, taken individually, is likely to transform an enterprise's compute spend on its own. Rightsizing alone might save 15%. Scheduling non-production environments alone might save another meaningful chunk specific to that portion of the environment. Layered together rightsizing, proper commitment-based pricing, scheduled non-production shutdown, Spot where it fits, Graviton where compatible, genuine ongoing accountability the combined effect is what actually produces enterprise-scale savings, and it's why one-off cost-cutting projects tend to underperform compared to building several of these into standing practice simultaneously.

The Actual Point

EC2 cost optimization isn't really a technical problem at most enterprises. The technical solutions here are well understood and not particularly exotic nothing on this list requires cutting-edge tooling or a research project to implement. What's usually missing is ownership: someone specifically responsible for treating compute spend as an ongoing, actively managed variable rather than a fixed cost nobody revisits once the initial provisioning decision gets made.

The organizations getting real value out of this aren't running more sophisticated optimization than everyone else. They're just actually doing, consistently and on a real schedule, what most of this list describes instead of treating it as a project that gets attention once and then quietly stops mattering again the moment the immediate budget pressure that prompted it passes.

Unused AWS Resources: The Silent Driver Behind Expensive Cloud Bills

Ronak Sharma — Mon, 10 Aug 2026 16:33:27 +0000

Ask most engineering leaders whether they know exactly what's running in their AWS account, and you'll get a confident yes. Ask them to actually prove it list every resource currently provisioned and what business purpose each one serves and the confidence usually drops fast. That gap between "I know what's running" and "I can actually account for what's running" is where unused resources live, and it's a bigger gap than almost anyone expects until they're forced to close it.

Here's the specific claim I want to make, because it's narrower than the general "cloud waste" conversation: unused resources aren't a symptom of bad engineering. They're a completely predictable byproduct of how engineering actually works provisioning is fast and cheap to do, decommissioning is slow and nobody's specifically accountable for it, and that asymmetry guarantees accumulation over time regardless of how disciplined a team is. This isn't a story about carelessness. It's a story about incentives, and until the incentives change, the accumulation doesn't stop on its own.

*Provisioning Is a Decision. Decommissioning Is an Afterthought. *

This asymmetry is the actual root cause, and it's worth sitting with because it explains why this problem shows up at literally every company we've worked with, regardless of engineering quality. When someone needs a resource, there's a clear trigger, a clear owner, and usually urgency behind it a feature needs to ship, a test needs an environment, a migration needs somewhere to land. Provisioning gets done because something specific depends on it happening now, and that dependency creates natural accountability. Someone requested it. Someone's waiting on it. It gets built.

Decommissioning has none of that. Nothing urgent depends on deleting a resource nobody's using that's precisely the problem, the absence of urgency is what makes it invisible. There's rarely a clear individual owner responsible for going back and cleaning up once the original need has passed, and "I'll clean that up later" is a promise made constantly and kept rarely, not because anyone's careless but because "later" never arrives with the same forcing function that "now" had. The sprint ends, the project ships, the engineer moves to the next priority, and the resource just continues. Nobody made an active decision to keep paying for it. It simply never received an active decision to stop.

*EBS Volumes: The Classic, Underestimated Case *

When an EC2 instance terminates, its attached EBS volumes don't automatically disappear unless specifically configured to do so, and that configuration detail gets missed constantly, especially in environments where instances get created and destroyed frequently as part of normal development or testing cycles.

The volume just sits there afterward, fully billed, holding data nobody's actively using, waiting indefinitely for someone to either reattach it to something or explicitly delete it neither of which tends to happen without a specific reason prompting it. We've seen accounts with genuinely hundreds of unattached volumes accumulated over a few years of normal operation, representing thousands of dollars a month in storage costs for data that, in a lot of cases, nobody could even confidently identify anymore once we started asking what was actually on each one. In more than one audit, the honest answer from the team was "we're not sure, better safe than sorry" which is a reasonable instinct applied to the wrong problem, since the actual risk of deleting an unidentified volume is usually much lower than the cost of indefinitely storing one nobody can account for.
**
Idle Compute: Running Doesn't Mean Working
**
An EC2 instance that's technically running and passing health checks isn't the same thing as an instance that's actually doing useful work. Plenty of instances sit at genuinely minimal utilization a development environment nobody's touched in months, a proof-of-concept that proved its point and then just kept running afterward, a service that got replaced by something else but never formally decommissioned because nothing broke when the old one kept running alongside the new one.

These don't show up as an obvious problem in any monitoring dashboard, because the instance is healthy by every metric that typically gets watched it's just not delivering any actual value while it runs. Regular review of genuine utilization, not just uptime or health status, is the only way this category gets caught, and it requires someone specifically asking "is this still needed" rather than just confirming "is this still working," which are very different questions that most monitoring tools only answer the second one of. A dashboard full of green checkmarks tells you nothing broke. It tells you nothing about whether anything mattered.

*RDS Instances Left Running Past Their Purpose
*
Database instances are particularly prone to this pattern, because there's a real, legitimate hesitation around deleting anything that might contain data someone eventually needs. That hesitation is reasonable in isolation. In aggregate, it means RDS instances from completed projects, deprecated applications, or one-off analysis work tend to linger far longer than the actual data inside them justifies, because "better safe than sorry" has no natural expiration date attached to it.

The fix isn't "delete cautiously and hope." It's assigning genuine expiration reviews to non-production database instances specifically a defined checkpoint where someone actively confirms continued need, rather than assuming continued need by default simply because nobody's raised an objection. Silence isn't the same thing as confirmation, and treating it that way is exactly how these instances end up running for years past their actual usefulness. A quarterly checkpoint that requires an active "yes, still needed, here's why" answer catches this reliably. A policy that only reacts to someone flagging a problem doesn't, because nobody's incentivized to flag a problem that's just quietly costing money in the background rather than actively breaking anything.

*Load Balancers Pointing at Nothing
*
This is a specific, easy-to-verify case worth calling out directly: load balancers configured to route traffic to backend targets that no longer exist. The load balancer itself keeps running and keeps billing, technically operational, routing traffic toward a target group that's effectively empty, because whatever it was originally built to serve got migrated, deprecated, or replaced without anyone circling back to the load balancer sitting in front of it.

These are genuinely straightforward to identify check target group health and actual backend membership and they're consistently missed anyway, mostly because nobody's specifically responsible for auditing load balancer configuration on any regular cadence. It's not a hard problem to solve. It's a genuinely unowned one, and unowned problems don't get solved just because they're technically easy to fix once someone finally looks.

Unused Elastic File System and Storage Allocations

EFS and similar storage services often get provisioned generously upfront, sized for anticipated need rather than actual current need, and then never revisited once real usage patterns become clear months later. Storage that's allocated but substantially underutilized represents ongoing cost for capacity that isn't actually serving its intended purpose, sitting there because downsizing storage feels like more operational risk and effort than it's usually worth to anyone's individual priorities in a given sprint.

Periodic review against actual usage not the original provisioning estimate made before real usage data existed surfaces this reliably, but only if someone's actually doing that review on a defined schedule rather than treating initial sizing as a permanent, correct decision that doesn't need revisiting. The original estimate wasn't wrong when it was made. It's just rarely updated once reality diverges from it.

Why Standard Monitoring Doesn't Catch This

Here's the part that explains why this problem persists even at companies with genuinely solid monitoring practices: most monitoring is built to answer "is this working correctly," not "is this still needed." Those are fundamentally different questions, and a resource can score perfectly on the first one while being a complete waste on the second, indefinitely, without a single alert ever firing to flag it.

Cost anomaly detection tools help with sudden spikes a resource that jumped from $50 to $500 a month gets flagged reasonably well by most tooling available today. They're structurally much worse at catching quiet, steady accumulation a resource that's been costing $50 a month, unchanged, unnoticed, for two straight years. Nothing about that pattern trips a typical anomaly threshold, because nothing about it is anomalous. It's just persistently, invisibly wasteful, which is a different failure mode than the one most cost monitoring is actually built to catch. And because it's not anomalous, it doesn't compete for attention against the things that are actively alarming it just sits there, patiently, month after month, until someone happens to go looking specifically for it.

What Actually Closes the Gap

Given that the root cause is a structural asymmetry between provisioning and decommissioning, the fix has to address that asymmetry directly, not just add another monitoring dashboard on top of the same broken incentive structure:

Tagging requirements enforced at resource creation, including an owner and an intended lifespan where that's knowable at provisioning time, not retrofitted later once ownership's already unclear

Scheduled reviews with actual teeth a defined cadence where resources get confirmed as still-needed or explicitly decommissioned, rather than defaulting to "keep running" by inertia because nobody raised a specific objection

Automated identification of genuinely idle resources, flagged based on real utilization data rather than uptime or health status alone, since those measure the wrong question

Clear individual ownership for decommissioning, not just for provisioning if nobody's specifically accountable for cleanup, cleanup reliably doesn't happen at any meaningful scale, regardless of how good everyone's intentions are

None of these are complicated to implement individually. What's hard is sustaining them, because none of them have the natural urgency that provisioning has. That's exactly why they need to be built into process rather than left to individual initiative initiative is precisely the thing that reliably runs out once the immediate pressure that would have sustained it is gone.

The Actual Point

Unused resources aren't evidence that an engineering team is careless. They're the predictable, structural result of provisioning being easy and urgent while decommissioning is hard and optional and that asymmetry exists at every company running real infrastructure, not just the ones with weak practices.

The organizations actually controlling this cost aren't the ones with perfect engineering discipline. They're the ones who built a genuine process for closing that gap, instead of just hoping good intentions would close it on their own, which reliably, everywhere we've seen it tried they don't.