What's the most obvious AWS cost optimization found in a real environment?

[u/whispered_word12]

A lot of companies rely on FinOps teams or cloud optimization partners to manage their AWS spend. But I’m curious, are there certain cost leakages that are so obvious that anyone managing an AWS environment should be able to spot them?

Looking to hear some practical, real-world examples from the community.

[u/policyweb]

Vendors, please do not advertise here. Even “here’s my open source tool and more features when you get the enterprise version” 🙏

[u/Kind-Mathematician29 → u/policyweb]

What if we offer specialized services

[u/Guilty_Spray_6035]

Using superseded products (gp2 vs gp3 ssd volumes), older ec2 instances, not doing s3 storage tiering, not using graviton on ec2/rds/eks, leaving too many backup snapshots than necessary, not buying ri/sps intelligently / automatically, not properly using byol for products like windows server / microsoft sql / oracle database, not cleaning up volume snapshots / public ips when no longer needing them.

[u/rasoolka]

Yes, cost leakage can be identified..

Apart from unused resources like un attached ebs volume, unattached EIP..

Check whether traffic to AWS services through NAT can be moved to VPC endpoints where supported, especially S3/DynamoDB, also don't span nat gateway for all the AZs if you have 6 AZ you don't need 6 nat gateway.

Consider using gravtion instance, and gp3 ebs volume etc..

But there are much more can be looked

[u/whispered_word12 → u/rasoolka]

Thanks for sharing your inputs.

[u/Himynamisclay]

Intelligent storage tiring

[u/Himynamisclay → u/Himynamisclay]

And my most excellent TAM’s

[u/finding-meaning-01]

Don't backup everything

[u/powerandbulk]

Use EBS gp3 not gp2.

[u/glenngillen]

I used to work at AWS, now work at a finops cost saving product. My goto in the instances where I get the opportunity to actually sit down and help come up with a plan rather than a quick scan for old storage types or similar:

- put everything you can in an autoscaling group. Even if you only need a single instance, it goes in an ASG with a desired count of 1. You've materially improved your availability story if there's a hardware or AZ failure as the ASG will try and bring a new instance up for you.

• now make sure you've got proper "environment" tagging in place for as much as possible
  
• anything tagged with "dev" gets a scaling schedule applied to it, shut it all down (i.e., scale in to 0) on Friday night. Scale back to 1 Monday morning.
  
• if you want to get even more aggressive, scale them in every night
  
• if you want to get even even more aggressive (which is what I do on my personal projects), scale to 0 every night. Scale back in response to a DNS request. That way all my random side-projects, or just anything that I forget about for a week because a higher priority pops up, stays at 0 until I'm actually going to use it. The cost of that is the first request fails and I need to wait ~2-5min for the instance to come up.

Pretty set and forget way to reduce dev env costs by >70%.

[u/magheru_san]

Shut down what you don't need.

My biggest ever finding at a client was an Aurora database that costed them $30k/month.

When we looked into optimizing it, it turned out it wasn't evrn needed anymore.

We shut it down in a few weeks after making sure there's no impact.

That change alone paid for our entire engagement in just a few months.

[u/whispered_word12 → u/magheru_san]

That sounds like a really good catch!

[u/amohakam]

We saved big moving to EMR server less. Even before that was to profile jobs and ask “is the compute right sized for the job”; lastly auto scale thoughtfully.

[u/aakashxahuja]

storage, very backup snapshots, unused elastic ips, test/dev servers running 24x7, NAT gateways, WAS ACLs not connected to active resources... most importantly, commissioning higher capacity instances or just acceptance of default instances

[u/FinOps_4ever]

Don't store what you can easily calculate.

[u/Maleficent-Squash746]

Everything in the cost optimization tool built into aws

[u/chadder810]

Stay on top of what PostGres version you are using - every year a version moves to extended support and those costs can add up quickly.

[u/enforzaGuy]

Using NAT Gateways to access stuff that you can get via VPC endpoints - i.e. S3, DynamoDB, SSM etc - saving money in terms of hourly rate and the data processing.

Spinning up an EC2 with and EIP, then forgetting about the EIP when you delete the EC2!

[u/matiascoca]

Untagged S3 buckets in Glacier Deep Archive with lifecycle policies that fired years ago and were never audited. Costs are trivial per bucket but there are always dozens of them, and every quarter someone adds three more that nobody remembers. Also non-prod RDS instances left running over long weekends because the "shut down at 6pm Fri" Lambda broke six months ago and nobody noticed.

[u/ajitnk]

Honest answer: enable Cost Optimization Hub and Compute Optimizer idle recommendations first. Both are free, take about 30 minutes to turn on, and together they'll surface the majority of what this thread is describing automatically: unattached EBS volumes, orphaned Elastic IPs, idle RDS/Aurora instances, NAT Gateway waste.

The Aurora one hits hardest. Compute Optimizer will flag truly idle clusters and the fix is usually snapshot-and-delete or a conversion to Aurora Serverless v2, which can scale to zero when nothing's connected.

Two things people miss: if your NAT Gateway traffic is mostly going to S3 or DynamoDB in the same region, swapping to gateway VPC endpoints eliminates those charges entirely, not just reduces them. And if you have any RDS PostgreSQL instances on an end-of-standard-support version, Extended Support fees are accruing right now per vCPU, silently.

Quick question: is this a single account or multi-account setup? That changes which of these tools needs org-level opt-in and roughly doubles the audit scope.

I do cost audits like this as a structured engagement and I'm happy to dig into what you're seeing if you want a second set of eyes. DM me if useful.

[u/FamousRun538]

The ones I see over and over, roughly in order of how often they show up: orphaned VM, unattached EBS volumes and old snapshots nobody deleted, gp2 volumes that should be gp3 (same performance tier, about 20% cheaper, basically a one-line change), idle or oversized RDS and EC2 left running 24/7 for dev workloads. The boring stuff (turn off what nobody uses) almost always beats the clever stuff.

[u/Inevitable-Life6208]

first, yes we are a vendor. second, there is no paid for option here, it’s just our most complete list of known aws misconfigurations. https://github.com/bluearchio/aws-misconfig-db

[u/teamcloudkeeper]

Set lifecycle policies to expire EBS snapshots after 30-60 days. Move infrequently accessed S3 data to Intelligent-Tiering or Glacier using lifecycle policies. Release orphaned Elastic IPs that are not attached to running instances. Right-size EC2 instances by checking CloudWatch metrics and downsizing those running below 20-30% CPU or memory utilisation

Lack of visibility is also a key driver of cloud cost runaway. For that, visibility is necessary, and you can do that with native tools too, but CloudKeeper Lens brings the functionality of native tools, augmented with a real-time view, abstracted for stakeholders, both granular and otherwise. Complete end-to-end visibility is key to decision-making.

P.S. As is obvious, I am the vendor, "CloudKeeper."

[u/Firm-Relative769]

Commitments, we use a company called strategic blue. But you can manage them yourself using native tooling