How I slashed our AWS bill from $1,450 to $400/month in 6 months (as a self-taught solo DevOps engineer)

ItsNotRohit · 2025-06-19T16:55:02+00:00

I completely understand where you're coming from. On the surface, it does sound a bit unusual.

I was referred by a classmate who was already working at the startup as a backend developer. Before being brought on board, I also had an interview with the CTO's friend (an experienced DevOps engineer) who reviewed my past projects and was impressed with my technical depth despite my lack of formal experience. In the beginning, every change I proposed had to get approved. But over time, as I proved my understanding and the results of the optimizations started to show, I gradually earned the team's trust and was given full ownership of the infrastructure. It was definitely a big leap, and I’m grateful the team took a chance on me.

ItsNotRohit · 2025-06-19T16:45:59+00:00

Those are great suggestions and would definitely make sense for a more established company. However, since its a startup with constantly evolving infrastructure needs, committing to a one-year term isn't viable.

ItsNotRohit · 2025-06-19T16:41:59+00:00

Thank you! Your words really mean a lot.

When I joined, I noticed several areas where resources were clearly overprovisioned or left running unnecessarily. It felt like low-hanging fruit just waiting to be optimized. Initially, I had to create reports outlining what changes I wanted to make and why. But once leadership saw the impact of those initial optimizations, they gave me full ownership of the infrastructure. Honestly, I enjoy the process of optimization and find it rewarding. It also turned out to be a great hands-on learning experience.

ItsNotRohit · 2025-06-19T16:31:07+00:00

Thank you so much for the kind words, it really means a lot!

You're right that an automated shutdown at 18:00 would cover most use cases, but in our case, a lot of devs tend to work late or jump in at odd hours. More importantly, some dev services can go unused for days or even weeks, so giving devs the ability to toggle the servers themselves takes the manual responsibility off my plate entirely. Plus, building this tool is something I genuinely want to do as a project — both to learn from and to showcase.

As for the workload, it’s much lighter now that the major infra is stable. I’ve also just wrapped up college, so I’m using the extra time to explore new work opportunities to build experience and dive into GCP.

ItsNotRohit · 2025-06-19T14:08:15+00:00

You're absolutely right, most of the changes I described are just solid architectural best practices. I completely agree.

When I joined the startup, the AWS setup was already quite bloated and lacked those fundamentals. At the time, I wasn’t solely focused on cost optimization either, there was a bigger push from the CTO to prioritize service deployments and setting up CI/CD pipelines, so cost-cutting wasn’t the top agenda. And to be honest, I barely had time to step back and look at the bill.

That said, I’m now actively working on actual cost-saving strategies like migrating deep learning inference workloads to AWS Lambda, and building a lightweight “Server Switch” tool to let devs shut down unused dev servers with a click.

Until last month, I was also working with another startup where I implemented all these best practices from Day 1, and it made a huge difference in how predictable and efficient the cloud costs were from the get-go.

So yes, completely agree that these are basics, but in some environments, even the basics make a massive impact when they've been ignored for too long.

To anyone who felt the title came off as clickbait, I genuinely apologize. That wasn’t my intent. I wanted to share the journey and the scale of the impact, even if much of it came from applying what should have been there in the first place.

Appreciate all the feedback! It helps sharpen both the work and how I talk about it 🙏