Cloud bills rarely jump. They creep. Most of the growth comes from servers nobody switched off, machines sized up "to be safe", and charges nobody owns. Here are five fixes, and you don't need an engineer to start any of them.
Why does the bill creep?
Because a cloud server is a meter that runs until someone turns it off. That is the deal: no big upfront purchase, and you pay for what you use. AWS's own cost guidance puts it first among its design principles: pay only for the computing resources you consume.
The catch is that "what you use" includes everything you forgot. The test server from last year's project. The extra-large database someone picked during a busy week. Backups of a disk that no longer exists.
None of it is anyone's job to notice. The developer has moved on, the invoice goes to accounts, and accounts can't tell a busy server from an idle one. So the bill grows a little each month, and everyone assumes that is normal.
The five fixes below go from easiest to most involved. Start with the first.
1. What can you switch off?
More than you would think, starting with test servers. Your team uses test and staging servers during office hours, about 40 hours a week. Left on, they run all 168. AWS's Well-Architected Framework says stopping them outside working hours can cut their cost by about 75%.
Then look for things that cost money while doing nothing:
- Servers from finished projects that nobody remembers starting.
- Storage disks no longer attached to any server.
- Old backups and snapshots kept "just in case", years after the case passed.
- Reserved public IP addresses that point at nothing.
Ask whoever set things up to list every running resource and who uses it. Anything without an owner is a candidate to switch off. Take a backup first if anyone hesitates.
2. Are your servers bigger than the job?
Often, yes. Servers get picked big "to be safe": before a launch, during a busy week, or because nobody knew what traffic to expect. Then nobody shrinks them.
Check how busy each server actually is. AWS shows this in CloudWatch, and AWS Compute Optimizer suggests smaller sizes where they would fit. A server that rarely passes a fifth of its capacity is a strong candidate for a smaller size.
AWS's sustainability guidance says two servers each running at 30% are less efficient than one server at 60%. Your bill works the same way, because you pay for each server whether it is busy or idle.
Rather than sizing for the worst day, let the system grow on busy days and shrink afterwards. That is what auto scaling does: more servers at the peak, fewer at night.
3. Are you paying full price for steady work?
Probably, because full price is the default. Many businesses pay AWS's on-demand price for everything, simply because nobody chose otherwise. There are cheaper ways to pay, and each suits a different kind of work.
| How you pay | Discount AWS lists, against on-demand | Best for |
|---|---|---|
| On-demand | None | New, short or unpredictable work |
| Savings Plans or Reserved Instances | Up to 72% | Servers that run all day, every day, committed for 1 or 3 years |
| Spot | Up to 90% | Work that can stop and restart: batch jobs, image processing, test runs |
Spot is cheap because it uses AWS's spare capacity, which AWS can take back at short notice. Never run your shop's checkout on it.
One rule matters more than the discount: commit only after fixes 1 and 2, and after watching a month or two of usage. Otherwise you sign up for three years of paying for waste. A commitment is lock-in you choose on purpose, which is fine, as long as you know the size of it. Our post on keeping the right to leave covers how to judge that.
4. How much data is leaving the cloud?
More than most owners realise, and every gigabyte of it is billed. Sending data into AWS is free. Sending it out to the internet is billed by the gigabyte after the first 100 GB a month. AWS's framework gives data transfer a section of its own, with practices for measuring it and for choosing services that reduce it.
Where to look:
- Images, videos and downloads. Serve them through a content delivery network such as Amazon CloudFront, so visitors get them from a nearby copy.
- Photo sizes. A 4 MB phone photo on a product page is paid for every time someone opens that page. Compress images before uploading them.
- Servers that talk to each other. Keep your app and its database in the same AWS region.
- The trend. In AWS Cost Explorer, check the data-transfer line. If it grows faster than your visitors do, something is sending more than it should.
5. Who owns each cost?
Someone should, by name. The first four fixes wear off if nobody keeps watching. AWS's framework calls the answer attributing expenditure: every cost should belong to a named person or project, so someone notices when it grows.
Three habits keep it in place:
- Label everything. Tag each resource with a project and an owner when it is created. Untagged resources are the first place to look for waste.
- Set a budget alert. AWS Budgets can email you when spending passes a limit you choose, or is on course to. Set it a little above a normal month.
- Look once a month, for 15 minutes. Open Cost Explorer, compare with last month, and ask the owner of anything that grew.
That last habit takes under an hour a quarter, and it catches creep while it is still small.
Who is this for?
Businesses running their own apps or software on AWS. If you are still planning the move, start by moving one app first. If your business runs on a website built with Quantum Accord, there is no cloud bill to watch: hosting is included with every paid site, with no monthly hosting bill.
Cost is half of running AWS well. The other half is keeping it secure, and our free 30-point AWS security check takes about half an hour and gives you a fix list ordered by risk.