#14. Don't optimize costs—prevent them altogether: Shift left.

I've been thinking deeply about the FinOps cycle and its inform, optimize, and operate phases. What struck me is how common it has become for people to build up costs first and optimize later, instead of simply preventing unnecessary costs from the start! It reminds me of how people are often pushed to take fancy blood sugar medication while eating whatever they want, rather than following a healthier diet to prevent diabetes in the first place. This "healthy diet" in cloud usage is called shifting left, and that's what I want to talk about today.

TL;DR

• Shifting left is all about controlling the cost of cloud infrastructure before deploying it
• To successfully implement shifting left, automation and Infrastructure as Code (IaC) must be in place.
• Shifting left should be complemented with governance to ensure prevention of future cloud waste.

What is Shifting Left?

In its simplest form, shifting left happens when cloud engineers evaluate costs before deploying resources. They should examine available options and make cost-conscious decisions about which resources to deploy.

When this cycle is followed routinely and automated, it makes the optimization phase less painful and prevents considerable work later.

How to Shift Left?

Sure, we could manually use a cloud price calculator to check the cost of each resource before deployment. But who has time for that? The key to shifting left is embracing one of FinOps' core principles: automation!

First and foremost, **cloud infrastructure should only be deployed as code (IaC)** (e.g., using Terraform). With IaC as your default practice, you eliminate concerns about incorrect resource deployment since everything can be automated, monitored, and governed.

Better yet, tools like Infracost and Adaptive6 ( partially open-source) help automate this process. These tools calculate your infrastructure costs and suggest simple changes to reduce expenses. Take AWS block storage, for example—switching from GP2 to GP3 offers better efficiency at a lower cost. Yet GP2 instances persist because they're often the default setting, or because engineers copy outdated code snippets online. Without tools to warn you in advance, you risk deploying more expensive, less efficient resources.

Complete the Cycle by Governing the Cloud Resources

Does this mean we rely solely on engineers to choose and deploy the most cost-effective resources? Not at all! This is where cloud governance through policy completes the cycle (learn more in this article and its follow-up).

When a resource proves to be cost-effective and aligns with an application's business value, it should become the default choice in your governance policy. This ensures the recommendation applies to all similar applications across your organization.

Summary

Don't fall into the trap of deploying infrastructure first, then allocating costs just to optimize later. Prevent unnecessary costs from the start by shifting left.

Shifting left requires engineers to use Infrastructure as Code (IaC) and leverage automation tools to select the most cost-effective resources before deployment.

Thanks for reading! Share if you found it helpful. Have questions or suggestions for future topics? We'd love to hear from you!