Build for Less: A Mindset for Cost-Efficient Cloud Engineering

Editor's Note: This blog is adapted from a talk by Aditya Prakash, Senior DevOps Engineer at Geekyants. In this session, he unpacks the mindset shift required to build cost-aware cloud systems—not by slashing budgets, but by embracing smart architectural choices, scalable design principles, and a culture of shared financial responsibility. Drawing from real-world consulting experience, Aditya explains that effective cloud co

Hi, I am Aditya Prakash. I work as a Senior DevOps Engineer at Geekyants, and over the past few years, I have seen how the cloud, despite its incredible potential, can quickly become a financial burden when not managed mindfully. This talk is not about quick fixes, promotional coupons, or clever billing tricks. It is about something more foundational—a cultural mindset shift toward building with cost awareness at the core of engineering.

Coming from a consulting background, I often find that cloud costs are not just a technical consideration; they are a conversation starter with clients. It determines conversions, renewals, and long-term partnerships. When a business starts receiving unexpectedly high cloud bills, something in the process has broken. Maybe cost analysis was never a part of the design process. Maybe stakeholders were focused entirely on feature delivery. Or perhaps fear and uncertainty led to overprovisioned infrastructure. 

Either way, this is a recurring challenge across the board. According to Flexera’s 2020 State of the Cloud Report, the top challenge enterprises face today is managing cloud spend. And that is where this mindset needs to evolve. In my experience, cost awareness needs to be treated as a feature, just like performance, uptime, or latency.

Let me make this clear from the beginning—cutting costs is not the same as engineering for efficiency. For instance, if your cloud alert tells you that your RDS instance is eating up your budget, reducing its size may reduce the bill, but it will also slow down performance and degrade user experience. That is not a solution. That is a compromise.

Instead, we must embed cost thinking into the process, right from architecture planning to deployment and iteration.

When people start learning cloud infrastructure—VPCs, EC2s, load balancers—they often rush to implement autoscaling. It sounds impressive. But autoscaling, without understanding the underlying need, can amplify waste.

I tend to break scaling strategies into three buckets:

1. No scaling at all.
2. Predictive manual scaling.
3. Autoscaling with guardrails.

For example, I have worked with clients building MVPs—simple backend setups with seasonal or limited user traffic. Their first instinct is to demand autoscaling. But when I ask why, the answer often reveals fear rather than actual need. Sometimes, no scaling is the right call.

In other cases, predictive manual scaling based on expected traffic patterns works better. Autoscaling should only come into play when you have tested your application’s performance under pressure. Tools like K6 or Artillery can help load-test an app and identify when and where to scale. With data, autoscaling becomes strategic. Without it, it becomes reactive and expensive.

A poorly written application will consume as many resources as you throw at it. No amount of scaling will mask an inefficient codebase. Fixing code is always cheaper than scaling infrastructure.

I recall one project where bad queries, including missing indexes, redundant joins, and poor pagination, required 200 servers just to stay operational. That translated to a monthly burn of over ₹20 lakh. When we stepped back, reviewed the query logic, and optimised for CPU and memory efficiency, the server count dropped to 120. That was an ₹8 lakh monthly saving, just from one optimisation sprint.

So, before investing more money in infrastructure, take a thorough look at the code. It might be the most cost-efficient decision you make.

Yes, observability is critical. But throwing in distributed tracing, verbose logging, and full-stack APM tools without a plan can drain your budget faster than you expect. Logs cost money, especially if you store them for long durations or collect everything by default.

If observability is implemented mindlessly, it can quickly become overkill. Implement it where it matters. Understand what metrics you need. Retain logs smartly. And always weigh value against cost.

One of the best practices I follow as a consultant is asking deliberate, thoughtful questions. What kind of load is expected? What are the traffic patterns? Are users coming from a few time zones, or is the usage global? Does the application need horizontal scaling, or can vertical scaling handle it?

Sometimes, I recommend starting with K3S clusters on EC2 instead of jumping directly to managed Kubernetes. The cost difference can be substantial. A K3S setup might run at $300–$350 per month, compared to $800 or more for a managed solution. That money can be better spent on understanding and fixing bottlenecks early.

When we design infrastructure with these questions in mind, we earn the client’s trust and build systems that scale sustainably.

Cloud cost is not the DevOps team’s problem alone. It is not only for the finance team to worry about either. It is a shared responsibility across:

• Developers: must write cost-conscious code and be aware of its impact.
• DevOps and SREs: Who must provision infrastructure based on real requirements, not assumptions.
  Architects: Who shape databases, service layers, and data flow.
• Product Managers: Who balance feature velocity with cost and performance trade-offs.
• Finance Teams: Who decides where to invest and where to optimise.

Each of these roles influences the final bill. Each decision, from a JOIN clause to a dashboard feature, affects spend.

I believe that if cost discussions are part of every sprint, just like velocity or QA, they will eventually shape culture. When teams regularly ask, “What is the cost implication of this decision?”, they not only build more responsibly, they also unlock greater performance, stability, and user satisfaction.

Cloud cost is not just about saving money. It is about delivering value, sustainably and strategically.

For those already thinking this way, I hope this adds more tools to your belt. And for those who are not, perhaps this is a nudge to begin.