The easiest way to save money on your AWS bill sounds pithy when you write it down:
Turn that shit off.
I’m serious! It sounds like I’m telling you something that’s somehow obvious or that you should already know, but there are deceptive layers of nuance to the idea.
To be very clear, I’m absolutely not suggesting that you log into your company’s production AWS account and start turning things off left and right like some sort of overpaid chaos monkey.
But there are tactics you can use to shut off services you don’t need and save money — without buying Savings Plans, signing an AWS contract, or rearchitecting your environment. Let’s dive in and you’ll see what I mean.
1. Put people in charge, not automated tools
From an API basis, it’s effectively impossible to disambiguate between things that should be turned off and things that should be protected at all costs. Those idle instances sitting there doing nothing? Yeah, that’s the DR environment; in the event of an AZ or region wide issue, they’ll be needed quickly at a time when a whole bunch of other folks are going to have similar ideas. You can’t depend on the AWS control plane to provision instances quickly enough, so you’ve gotta pay to have these things sitting idle.
Inversely, a lot of cost management tooling presupposes that what’s in your environment is exactly what should be running. It’ll cheerfully suggest that you buy three-year Savings Plans (or worse, Reserved Instances, because their tooling hasn’t been upgraded to support those in the past two years) for some developer’s test cluster that’s still running six months after they left your company.
There’s an easy way to tell whether something’s in use. Personally, I’m a fan of turning things off and waiting for the screams when I can’t figure out what’s running, but this may prove disastrous. Inevitable chaos isn’t your style? One way that I’ve found to overcome the incredibly obvious problems with just shutting things off is to restrict access to the resource in question. Be sure to get the instance’s IAM role restricted, too! If you can leave an instance up for a week or four without anyone connecting to it and no one raising hell, it’s a reasonable guess that it can be turned off. TAKE A BACKUP FIRST, and then go ahead and terminate it.
I would encourage you to do this gradually and methodically. “Measure twice, cut once,” as the saying goes. If you restrict access to half of production by accident, you’re not going to get much useful data other than exactly how red your executive leadership turn while they’re screaming their heads off.
2. Delete your data, aka another way to say turn that ish off
Backups are important (see above), and far be it for me to suggest that you not have any.
That said, do you really need two full years’ of backups taken every 12 hours for every instance’s EBS root volume? I’m going to theorize that you do not, but you certainly know your environment better than I do. Backing up data you’ll never need to restore at 5¢ per GB/month can add up to tens of thousands of dollars across an environment if you’re not careful.
Similarly, cloning a few petabytes in S3 for every developer environment is great and all, but S3 Object Lambdas are one way to save thousands a month on such exercises. Whether it’ll work for you depends upon what you’re doing with it.
If you have a bunch of data that lives within S3, you can’t go far wrong by using S3 Storage Lens to take a look at just what’s in there and what it’s doing. If there’s data that’s not pulling its weight, turn that … well, you get it.
3. Get rid of the miscellanea clogging the pipes
There are a whole bunch of other desultory detritus from various experiments, failed provisioning runs, abortive attempts at migrating to serverless, and who knows what else.
Individually, these things tend to not cost a lot of money, most of the time. The only real way to be sure is to take a look at your AWS bill in the console and your own constraints. For some folks, spending $2,000 a month on unattached Elastic IP addresses would be a screaming fire in the building that should be fixed IMMEDIATELY. For others, that’s so far down the list that it may as well not exist.
Think of things like CloudWatch Log groups that don’t have expiry configured, versioning enabled for S3 objects that change constantly, multiple CloudTrails configured within the same account, and those cursed Managed NAT Gateways.
In theory, you should understand every line item on your AWS bill: what it means, what resources it represents, and what they’re being used for. Failing that, try to get to some semblance of an idea of what the larger numbers represent. Don’t get stuck rabbit holing here; fixating on the 72¢ a month for a snapshot you can’t quite track down may not be the most efficient use of your energy.
So before you buy Savings Plans, sign an AWS contract, or rearchitect your environment, try these three ways to — say it with me — turn that shit off.
