Your AWS Bill Is a Symptom of Organisational Rot
The on-prem era forced frugality. Procurement took months. Rack space was finite. Engineers had to actually think about resource allocation.
AWS deleted that constraint. Now? Teams treat EC2 instances like insurance policies, provisioning for theoretical traffic spikes that never materialise. The result isn't just wasteful, it's actively dangerous.
The Downtime Death Spiral
Here's the psychology: For execs, downtime is career-ending. One hour of outage in finance can cost millions in missed trades. A botched Black Friday can tank a retail brand's reputation.
So the mandate becomes: handle the volume, no matter the cost.
This creates a perverse incentive structure. The team lead who optimises their AWS spend by 40%? Gets a polite nod. The lead whose service crashes for 20 minutes after rightsizing? Performance review, possibly termination.
When the downside of overprovisioning (slightly higher bills) feels invisible compared to the existential threat of downtime, waste becomes virtue. Nearly a third of cloud spending evaporates on idle or oversized resources. That's roughly $30B annually across the industry.
The kicker? Most companies still can't track which team is responsible for which costs. Without granular cost allocation, every lead provisions the biggest possible bucket and hopes finance doesn't ask questions.
Infrastructure as a Band-Aid for Bad Code
The most dangerous part isn't the waste. It's what overprovisioning hides.
Memory leak in your Java app? Upgrade the instance. Unoptimised database query? Throw more RAM at it. AI-generated code that's bloated and inefficient? Just scale horizontally.
This is the technical equivalent of using a bigger bucket to catch water instead of fixing the leaking pipe.
In the old days, a memory leak would crash your server, forcing a fix. Now it just increases your AWS bill. The pressure to resolve underlying issues vanishes because the infrastructure compensates. Over time, the application becomes a Frankenstein of technical debt, costing far more than the business value it generates.
AI coding assistants have accelerated this. They generate code fast, but rarely efficient code. Developers merge it under deadline pressure, then rely on oversized instances to handle the performance hit. The repository fills with redundant garbage that'll require expensive refactoring later.
The Zombie Apocalypse
Worst case scenario: you're paying for infrastructure you don't even know exists.
Zombie resources are instances, databases, or S3 buckets created for testing or one-off projects, then forgotten. They sit there for years because nobody knows what they do and everyone's afraid to turn them off.
These aren't just waste. They're massive security vulnerabilities.
Zombie instances don't get patched. They run outdated libraries and vulnerable software. For attackers, they're gift-wrapped entry points. Compromise a forgotten test server, use it for lateral movement into production databases.
One study found abandoned S3 buckets that attackers re-registered after companies deleted them but left references in their code. Those buckets received millions of requests from banks and government agencies, all pulling what they thought were trusted config files.
AWS Compute Optimiser Isn't Saving You
AWS Compute Optimiser and similar rightsizing tools promise salvation. They analyse usage patterns, suggest instance type changes, compare Savings Plans versus Reserved Instances.
But here's the thing: tooling doesn't fix culture.
Using the AWS EC2 Pricing Calculator or checking rightsizing recommendations only matters if teams are incentivised to act on them. Most aren't. The EC2 instance size calculator might say you can downsize from an m5.4xlarge to an m5.xlarge, but who's taking that risk?
Downsizing requires 30-90 days of metrics analysis, checking CPU at both average and p95 percentiles, maintaining memory headroom, verifying network ceilings, EBS performance limits, instance store availability, and ENI counts. One miscalculation and you're the person who crashed production.
Even AWS's own guidance recommends changing instance type incrementally, within the same family, during low-risk windows with fast rollback plans. That's not confidence-inspiring.
The Solution Architect Problem
The fix isn't another tool. It's a role: the Solution Architect.
Not a job title you hand out to senior devs as a promotion. An actual architectural function that bridges the CFO's spreadsheet and the developer's keyboard.
This person's job is to:
- Enforce cost allocation at the team level
- Review architecture for efficiency before provisioning
- Identify and terminate zombie resources
- Push back on oversized infrastructure requests
- Champion code optimisation over hardware upgrades
They need authority. Not just advisory power, but the ability to block deployments that violate efficiency standards.
The culture shift required is brutal. Teams that have operated under "provision for worst-case scenarios" for years will resist. Engineers who've built careers on conservative capacity planning will see this as a threat.
But the alternative is watching your AWS bill grow faster than your revenue until you hit the SaaS apocalypse: infrastructure costs outpacing business value.
Ship Better, Not Bigger
The lesson here isn't "optimise your EC2 instances." It's deeper.
Overprovisioning is a symptom. The disease is a culture where:
- Fear of downtime trumps engineering discipline
- Individual incentives misalign with company goals
- Bad code gets masked by good hardware
- Nobody owns the cost of their decisions
Fixing that requires more than AWS rightsizing recommendations. It requires rethinking how you build, who's accountable, and what you actually optimise for.
Because right now? You're not optimising for performance. You're optimising for blame avoidance.
And that's the most expensive architecture decision of all.