Last year we picked up a cloud cost review for a Chonburi auto-parts distributor running Odoo 17 on AWS, alongside a separate reporting stack for their sales team. Their monthly bill was $4,800. Three changes — none of them touching a line of application code — brought it down to $2,100. None of those changes were exotic. They were the same three things we find wrong at almost every SME we audit: oversized compute, unmanaged storage and transfer, and a database tier priced for a problem the company didn't have.
Compute Instances: Why Idle Servers Are Bleeding Your Budget
Most SMEs size their servers for the worst day of the year and then never resize them for the other 364. A retailer provisions an m5.2xlarge for a Black Friday spike, and eighteen months later it's still running at 8% CPU utilization in February. AWS's own pricing structure makes this expensive by design: within an instance family, doubling the vCPU and RAM roughly doubles the hourly rate, so a company running one size larger than it needs is paying close to 2x for capacity it isn't using — see [AWS EC2 On-Demand Instance pricing](https://aws.amazon.com/ec2/pricing/on-demand/) for how the tiers scale.
Development and staging environments are worse offenders than production, because nobody treats them with the same discipline. A staging server that only needs to exist during a 10-hour workday is, by default, billed for all 24. Run the arithmetic: an environment active 10 hours a day, five days a week, uses 50 of 168 hours in a week — roughly 30% of what an always-on instance consumes. Scheduling shutdowns outside business hours is the single highest-leverage compute fix we implement, and it requires no architectural change at all.
Then there's the graveyard: stopped instances still attached to Elastic IPs, orphaned EBS volumes nobody deleted after a migration, load balancers pointing at nothing. None of these show up as "running" in a casual glance at the console. All of them show up on the invoice.
For workloads with predictable, sustained usage — a production Odoo database server that runs 24/7/365 without exception — Reserved Instances or Savings Plans can cut the on-demand rate substantially over a one- or three-year commitment. That only pays off if the sizing underneath is already correct. Committing to the wrong instance size for three years just locks in the waste.
Data Storage and Transfer Fees: The Hidden Drain Most Miss
Storage is cheap. Nobody panics about storage. The panic comes three months later when the data transfer line item is larger than compute.
Cloud providers make inbound data transfer free and outbound transfer expensive, which is a rational business model for them and an invisible tax for you. AWS charges $0.09 per GB for the first 10 TB of monthly egress to the internet; the $0.05 rate most people quote only applies once you clear 150 TB in a month, which the overwhelming majority of SMEs never will. For nearly everyone reading this, egress costs a flat $0.09/GB with no volume discount in sight, per [AWS EC2 On-Demand pricing](https://aws.amazon.com/ec2/pricing/on-demand/). A reporting dashboard that pulls large datasets to a browser client all day, every day, adds up fast — and almost nobody budgets for it because it doesn't feel like "infrastructure."
Cross-region replication compounds this. A backup strategy that replicates a production bucket to a second region for disaster recovery is sound practice. It also means every object written gets billed for egress a second time. We've seen SMEs replicating entire media libraries across regions with no lifecycle policy behind them — full-resolution product photos from three years ago, sitting in Standard storage, replicated twice, accessed never.
The fix here is tiering, not deletion. Object storage classes exist precisely for this: [Amazon S3's storage classes](https://aws.amazon.com/s3/storage-classes/) range from Standard (roughly $0.023 per GB-month) down through Infrequent Access to Glacier Deep Archive (under a tenth of a cent per GB-month). A lifecycle rule that moves anything untouched for 90 days into a colder tier costs nothing to set up and pays for itself within a billing cycle for any company with meaningful archival data.
Database Services: When Managed Solutions Cost More Than Expected
Managed database services solve a real problem — patching, failover, automated backups — and SMEs without a dedicated DBA are often right to pay for that. The mistake isn't choosing a managed database. It's choosing the wrong tier of one.
Multi-AZ deployment, which keeps a live standby replica in a second availability zone for automatic failover, roughly doubles the instance cost compared to a single-AZ deployment of the same size — see [Amazon RDS pricing](https://aws.amazon.com/rds/pricing/) for how that premium is structured. That's the right trade for a payment system where an hour of downtime costs real money. It's the wrong trade for an internal reporting database that three people check once a day, where a 20-minute recovery from a nightly snapshot is entirely acceptable.
We've moved clients off a self-managed PostgreSQL instance on a $40-a-month DigitalOcean droplet onto a managed Multi-AZ instance costing over $700 a month — and the workload behind it was an Odoo database serving fourteen internal users. Nobody sat down and decided that trade-off was worth it. It accumulated one "just to be safe" checkbox at a time.
Provisioned IOPS storage is the same story in miniature. It exists for latency-sensitive, high-throughput OLTP workloads — large e-commerce platforms, financial transaction systems. Most Odoo databases under a few hundred concurrent users run comfortably on general-purpose gp3 storage, and the IOPS premium buys nothing measurable. Check actual read/write latency against what you're paying for before assuming faster storage is required.
That's the same shape as the numbers from the Chonburi client at the top of this piece. Of the $2,700 in monthly savings, resizing and scheduling the compute layer accounted for around $1,000; killing an unmanaged cross-region replication job on their reporting stack's media library and tiering three years of untouched product photos saved another $900; the rest came from moving their Odoo database off a Multi-AZ tier it never needed for a warehouse team that size. None of it was clever. It was three checklists, done properly, on a bill nobody had looked at closely in over a year.
Quick Wins: Identifying and Eliminating Waste in Your First Week
None of these require new tooling or a consultant. They require an afternoon and access to the billing console.
- Pull the last 30 days of billing, sorted by service. Whatever the top three line items are, that's where you start — not where your intuition says to start.
- Tag every resource by project, environment, and owner. Untagged resources are the ones nobody remembers creating and nobody's willing to delete.
- Identify instances running below 10% average CPU over two weeks using CloudWatch (or your provider's equivalent) and either downsize or schedule them off-hours.
- Delete unattached EBS volumes, unused Elastic IPs, and snapshots older than 90 days that aren't tied to a retention policy.
- Apply an S3 (or equivalent) lifecycle policy moving objects untouched for 90 days into a colder storage tier.
- Set a billing alert at a threshold that would make someone pick up the phone, not one that gets buried in an inbox filter.
- Review whether any Multi-AZ or high-IOPS database tier actually matches the workload's uptime and latency requirements — in writing, not by assumption.
None of this is free of risk, and it's worth saying plainly. Schedule a shutdown window over a server that's also quietly running a cron job or a nightly backup, and you'll break that job the first night it fires into an instance that isn't there — check what's scheduled before you schedule the shutdown. Downsize an instance because it measured idle during a slow fortnight, and you may find out exactly how much headroom you needed the next time volume actually spikes; downsize with margin, not to the exact line CloudWatch draws. And the audit itself costs something too — a real afternoon from whoever already owns your infrastructure, who is presumably already busy doing something else.
How much you recover depends on how badly things drifted. The Chonburi client cleared 56%, but that included a cross-region replication mistake most SMEs won't have made. Treat that number as a ceiling, not a benchmark — the honest expectation for most companies working through this list is real, immediate savings within the first billing cycle, not a specific percentage we can promise in advance.
Building a Cloud Cost Culture in Your Organization
The audit above fixes this month's bill. It doesn't fix next year's, because waste isn't a one-time event — it's what happens by default when nobody's job is to notice it. This is the entire premise behind FinOps, the discipline of treating cloud spend as a shared operational responsibility between engineering, finance, and leadership rather than a line item finance discovers after the fact. The [FinOps Foundation's framework](https://www.finops.org/framework/) is built around exactly this loop: inform, optimize, operate — visibility first, then action, then a repeated cycle rather than a one-off cleanup.
A dashboard that shows each team or project its own spend, updated weekly, works better than a policy memo ever will. Engineers who can see that their staging environment cost $340 last month will schedule it off overnight without being told to.
Put a recurring 30-minute review on the calendar — monthly is enough for most SMEs — where someone actually looks at the trend line, not just the total. Assign ownership of cost the same way you'd assign ownership of uptime or security. And treat every new deployment decision with a two-minute question attached to it: does this need to run 24/7, does it need Multi-AZ, does it need provisioned IOPS — before it goes live, not eighteen months after.
Flexera's [State of the Cloud report](https://www.flexera.com/state-of-the-cloud) has asked organizations to estimate their own cloud waste every year for over a decade, and the self-reported figure has sat stubbornly around 27–30% for most of that run, regardless of company size or industry. Nobody built that waste on purpose. It just sits there, accumulating one unreviewed checkbox at a time, until somebody's actual job is to go looking for it — and that's the one line item on this whole list that no lifecycle policy or instance resize will fix by itself.
