There are already many articles explaining how to optimize AWS costs. I’ve read quite a few of them, analyzed them, and applied what made sense for my company’s infrastructure.
As I mentioned in a previous article, I was responsible for deploying our backend infrastructure to Amazon Web Services.
At that point everything was working well:
- the code was running smoothly
- the infrastructure was stable
- Everybody was happy
But the monthly AWS bill started giving everyone a headache.
No matter whether a company is big or small, optimizing operational costs is always important. Every expense should be carefully analyzed.
My Approach to Optimizing the Infrastructure
My strategy was actually very simple:
- Clean the trash
- Turn off what you don’t use
- Use less → pay less
- Follow AWS best practices
Nothing fancy.
But these simple actions made a big difference.
Clean the Trash
You’re not mistaken.
In almost every infrastructure, if you don’t regularly clean things up, there will be many unused resources still running, and you’ll keep paying for them.
Some examples from our infrastructure:
Amazon S3 buckets or objects from non-production environments that were no longer needed
Amazon Elastic Container Registry images that were never used anymore
unused Elastic IPs
unattached EBS volumes
For ECR specifically, I deleted all unused Docker images and kept only the 10–12 most recent ones.
This alone reduced almost 100% of the previous ECR cost.
Turn Off What You Don’t Use
Most people work 8 hours a day.
Why should development infrastructure run 24 hours a day?
For example:
Amazon ECS services for staging and development were stopped between 8 PM and 7 AM
Amazon RDS instances for non-production environments were stopped during the same time
CI/CD infrastructure based on EC2 could follow the same idea
And you don’t need to stop them manually.
You can automate everything using:
AWS Lambda
Amazon EventBridge
Just schedule start/stop times and let automation handle it.
Use Less → Pay Less
This principle applies especially well to S3.
You can configure lifecycle policies for buckets to automatically move or delete older objects.
The same idea works for ECR, where lifecycle rules automatically delete old container images so you don’t need to clean them manually.
Follow AWS Recommendations
This one is obvious.
Who am I compared to AWS engineers?
They already publish many best practices, either in the documentation or through tools like Amazon Q.
Some examples I implemented:
Add VPC Endpoints so traffic to S3 stays inside the AWS network.
This avoids unnecessary external traffic costs.Use ARM architecture instead of x86 for ECS Fargate workloads.
It’s cheaper and performs well.Use Reserved Instances for long-running EC2 or RDS resources.
Avoid enabling public IPs whenever possible.
Since 2024, AWS has started charging for them due to limited IPv4 supply.
Internal communication inside private subnets is both safer and cheaper.Take advantage of AWS Free Tier.
Many of our services like Lambda, SNS, SQS, and CloudWatch are still within the free tier.Monitor your AWS bill regularly and configure AWS Budgets.
If you detect an unusual cost spike, investigate immediately.If your application uses RDS clusters with heavy read/write workloads and I/O cost exceeds 25% of the bill, consider switching to I/O-Optimized storage.
Storage becomes about 30% more expensive, but I/O cost drops to zero, which can significantly reduce the total cost.
Understanding Pricing Is the Key
There are many more ways to optimize AWS costs.
But the most important thing is simple:
Understand how each service is priced.
Before using any AWS service, you should check how its pricing model works and analyze it carefully.
Otherwise, you might only realize the real cost when the bill arrives.
And by then… it might be too late.
Conclusion
By applying these simple optimizations, our AWS bill decreased by about 40% compared to before I joined the company.
Everything still runs smoothly.
And especially for startups, cost efficiency should always be a top priority.
After all:
Running well and cheap is better than running well and expensive, right? 🙂
(If you enjoy these kinds of engineering stories, you can subscribe or visit my blog to receive the next ones.)
Connect me on LinkedIn :D
Top comments (0)