.png)
Join Hassan Khajeh Hosseini, CEO of Infracost, and Andrew Hay, env0's Director of Customer Success, for a 30-minute lightning talk exploring the synergy between Infrastructure as Code (IaC) and FinOps.
Through real-world examples and a live demo, they demonstrate how IaC shifts FinOps left, decentralizes infrastructure provisioning, and enables self-service with built-in guardrails. They also examine why infrastructure drifts persist, even with streamlined launch processes.
Transcript
Hassan Khajeh-Hosseini:
All right. Let's get started. Hey, everyone, welcome in. As I said, no slides—just me and Andrew. We'll do a quick introduction as well.
So, hey, everyone, I’m Hassan. I’m one of the founders of Infracost. I’ve been working in Cloud Cost Management and FinOps for around 13–14 years now. This one thing that we’ve done differently with previous startups, and now with this one, is this “shift left.” That’s something we’ll talk about today. I’m very excited to be here—let’s keep it short and sweet. Andrew, over to you!
Andrew Way:
Hello, everyone. My name is Andrew, and I’m the Director of Sales Engineering here at env0. Just real quickly, env0 is an Infrastructure as Code (IaC) management solution. I’ve been in the DevOps space for the past six years—previously more on application CI/CD. For the past three and a half years at env0, I’ve been focusing on Infrastructure as Code CI/CD. I’ve also been working in DevTools sales for over ten years and originally started as a developer. Pleasure to meet everyone here—I’m excited to have this conversation with you all.
Hassan Khajeh-Hosseini:
Awesome. Andrew, what are you seeing in terms of IaC adoption? How widely is it adopted?
Andrew Way:
Great question. So, we just came back from KubeCon. At our booth, we asked everyone who stopped by, “Do you use Terraform?” and 90% of people said, “Yes.” That’s a strong indicator that IaC adoption is widespread.
The cloud is becoming code, and people need repeatable ways to manage cloud infrastructure. That’s why IaC adoption is growing. On top of that, even on-prem resources are now being deployed using IaC, enabling hybrid cloud setups.
When they developed Terraform, the creators purposely avoided being opinionated on the approach. While this helped Terraform gain popularity, it has also led to a lot of variability. Everyone does things their own way, and managing those differences can be tricky. That’s where tools like env0 help—by providing a way to manage and streamline how Terraform and IaC are used across teams.
Hassan Khajeh-Hosseini:
Gotcha. Yeah. Okay. So like, essentially what you’re saying is, the Infrastructure as Code is being widely adopted. I guess it enables self-service. So anyone can launch whatever they need, whenever they need. A good decentralization of that.
Andrew Way:
Right. But that starts creating other issues. If everyone is creating resources, how do you ensure governance? For example, how do you know what has been created? How do you coordinate deployments across distributed teams?
Another challenge is drift. Drift can happen in many ways. Traditionally, it’s when code gets deployed, but someone updates the resource directly in the cloud. Now, the code and the actual infrastructure don’t match. As developers, we traditionally think of code as the “source of truth,” but with drift, the cloud state can differ from the code.
Drift can also occur in other ways. For example, let’s say you deploy an EC2 instance and use a data source to pull the latest AMI. Over time, that AMI changes as new releases or security patches are issued. Even though the code hasn’t changed, the infrastructure has drifted. Tools like env0 can schedule drift detection to help catch and manage these changes.
Hassan Khajeh-Hosseini:
Chris raised an interesting question about pipeline-driven IaC deployments. Isn’t that a better way to prevent drift?
Andrew Way:
Absolutely. A pipeline-driven Terraform deployment approach is better for managing infrastructure. We’ve seen customers build pipelines to deploy IaC effectively. But even with pipelines, if you don’t schedule regular drift detection scans, drift can still happen. It’s important to have both robust pipelines and automated checks to catch drift before it becomes an issue.
Hassan Khajeh-Hosseini:
Got it. And drift can occur in other ways too, right? For example, with data sources or updates that don’t go through the pipeline?
Andrew Way:
Exactly. The thing is, code is declarative, but not deterministic. So for example, if you are pulling in a data source like the latest AMI, your code itself hasn’t changed, but the AMI has changed, and that causes quote-unquote drift.
Hassan Khajeh-Hosseini:
Ah, I see. And this is where tools like env0 can help with drift detection?
Andrew Way:
Yeah, exactly. Drift detection essentially runs a plan, and you can compare what’s out there versus what the code says. This is key for maintaining alignment between your infrastructure and your IaC.
Hassan Khajeh-Hosseini:
I have another question. Are you seeing more adoption of Crossplane, and how does that compare to Terraform?
Andrew Way:
Crossplane is very useful for customers who are highly invested in Kubernetes. If your development team is already well-versed in Kubernetes, Crossplane is a great way to enable self-service for application teams to access AWS or other cloud infrastructure. However, there’s a chicken-and-egg problem—someone still needs to deploy the Kubernetes cluster that hosts Crossplane, though that’s usually a one-time cost.
Hassan Khajeh-Hosseini:
I’ve seen some Crossplane usage too. It’s still early days—I don’t hear about it all the time, but it does pop up occasionally. Timothy, good to see you! You brought up incident management earlier. Drift often comes up there, right?
Andrew Way:
Yes, definitely. Not all drift is accidental—sometimes it’s intentional, like during an incident where someone bypasses normal processes to make a quick fix. That’s where governance and visibility become essential.
Let’s shift gears. One of the big topics here is the intersection of IaC and FinOps. What’s the link between cloud costs and IaC?
Hassan Khajeh-Hosseini:
That’s a good question. The way I like to explain it is by simplifying cloud costs into a formula: usage multiplied by price. The usage component is fully engineering-driven—what services do I use, and how much do I use them? This includes the architecture, the resources deployed, and so on.
Then there’s the price component—this is essentially the list price you pay to cloud providers like AWS, Azure, or GCP. You can optimize the price by buying reservations, using EDP discounts, or negotiating rates. But that’s more of a financial decision handled by a central finance or FinOps team, with less impact on engineers directly.
On the engineering side, the usage piece is the most important. Here’s the issue: engineers, who are essentially the buyers of infrastructure, are rarely told upfront how much their deployments cost. There’s no “checkout screen,” so they deploy what they need without visibility into the cost impact. This leads to broken budgets and a disconnect between engineering and finance teams.
That’s where “shift left” comes in. By integrating cost estimates into the IaC workflow—tools like Infracost—we give engineers visibility at the pull request stage. For example, engineers deploying a non-production environment might see that they’re using a Multi-AZ setup unnecessarily. By catching these things early, they can make cost-effective decisions upfront and avoid rework later.
Andrew Way:
Nice. Now, there’s a question in the chat.
Hassan Khajeh-Hosseini:
Yeah, I love it.
Andrew Way:
It’s from Timothy, about tracking usage costs. So right now, you’re showing a lot of estimated costs, but I’m curious from your perspective—does Infracost do anything for actual usage tracking?
Hassan Khajeh-Hosseini:
Yeah, great question. So, we’ve actually split them out. We have something called a usage file, where you can say, “When you’re estimating something and you don’t know what the usage is going to be, use this usage as the basis for estimation.”
A lot of the time, engineers are estimating things like data transfer, and by the time you’re looking at those data transfer costs, it’s probably too late to change. But it’s super helpful for the engineer to start learning how data transfer costs impact the overall cost of the application.
So, we split these components out—we show the pricing parameters and allow you to bring in the usage data through the usage file. There’s more we can build out in this area, but right now, it’s a useful way to help engineers focus on the things they can actually change at the pull request stage. That’s where it’s really helpful for them.
Hassan Khajeh-Hosseini:
But, none of this works if there’s drift. For example, if you’re not using IaC and someone just goes into the dashboard, clicks a button, and launches what they need, there’s no way to interject that process.
I remember when we first talked about env0’s Cloud Compass feature—I found that super interesting. Andrew, could you explain more about that and how it helps with drift?
Andrew Way:
Yeah, absolutely. Let me show you what env0 can do for you today.
In our dashboard, we track all deployments made within env0. Whether you’re using Terraform, Pulumi, or something else—we support it. We can turn on a scheduling job to regularly run a plan and detect if there’s been any drift.
For example, I can see that I have 251 environments deployed, and 17% of them have drifted. I’ll drill into one specific deployment here—an EC2 instance. On the deployments tab, we can see drift detection running on a schedule. It’s found three changes: three removals and two modifications.
This ties back to what I mentioned earlier about code being declarative but not deterministic. The code hasn’t changed, but the AMI used has been updated because it’s pulling in the latest version. This creates “drift,” even though no one intentionally changed the code.
Andrew Way:
We also have the Cloud Compass feature. This allows us to scan AWS and Azure accounts and see how resources were created—whether through Infrastructure as Code, the API, or via “clickops.”
For example, I can see here that 97% of my resources were created using IaC, but there are still a few created through the API or manually. Let’s say I have some IAM policies created through clickops. From here, I can take an action—like generating IaC code for these resources. If I select OpenTofu, it generates the import blocks for me, making it easy to transition those resources into Infrastructure as Code.
This is just one way env0 helps manage drift.
Andrew Way:
But we’re taking it further. In the coming weeks, we’ll be introducing a new feature called “Drift Lane.”
Hassan Khajeh-Hosseini:
Oh, I like the sound of that!
Andrew Way:
It’s pretty cool. Drift Lane will let you see who caused the drift. For example, you’ll be able to identify the API key used or the user who logged into the cloud console and made a manual change. This level of visibility is something we’re excited to release soon.
Hassan Khajeh-Hosseini:
That’s fantastic. I think it’s going to be really helpful, especially in reducing direct access and bringing everything under IaC management.
Andrew Way:
Absolutely. And it’s not about blaming engineers—it’s about understanding why drift happens. Often, engineers are just trying to work around a blocker in the CI/CD pipeline. If we address those blockers, we can prevent drift from occurring in the first place.
Hassan Khajeh-Hosseini:
Totally agree. Shall we take some more questions?
Andrew Way:
Yes, let’s do that.
Hassan Khajeh-Hosseini:
All right, let’s look at the next question.
Andrew Way:
This one’s about tracking actual costs. It’s a follow-up from Timothy. Maybe I’ll quickly show how env0 integrates with Infracost.
For example, here’s a deployment where we’re showing the estimated cost of resources with Infracost built into env0. But what’s unique about env0 is that we can also track actual usage.
Here, you can see the actual spend—$6.34 in this case. Over time, if something changes, such as the instance size, the actual cost updates, and we can track that spend as it evolves. We summarize this over the entire project, so teams can see both estimated and actual costs side by side.
Hassan Khajeh-Hosseini:
That’s awesome!
Andrew Way:
It’s super helpful, especially for tracking consumption-based resources.
Hassan Khajeh-Hosseini:
Orlando just asked a good question about generating Terraform code for resources created manually. Does env0 actually generate the code?
Andrew Way:
Yes, it does. We just demonstrated that. When you scan your cloud accounts with Cloud Compass, it identifies resources created manually or through the API. From there, you can generate IaC code for those resources and integrate it into your workflows.
Hassan Khajeh-Hosseini:
That’s such a powerful feature. I love that.
Hassan Khajeh-Hosseini:
Now, someone else asked if Infracost can generate the usage file automatically.
Hassan Khajeh-Hosseini:
Yes, it can. When you first run it on a project, it generates a baseline usage file based on the resources it identifies. You can manage this centrally in Infracost Cloud or at the repository level with different usage files for different projects.
Hassan Khajeh-Hosseini:
This makes it really easy to standardize cost estimates across multiple teams and projects.
Andrew Way:
Let’s take one more question.
Hassan Khajeh-Hosseini:
Sure. This one is about specific examples of how IaC can help reduce cloud costs and improve FinOps.
Hassan Khajeh-Hosseini:
A great example comes from engineers deploying resources to non-production environments. They might unknowingly use a 16xl instance—something designed for production. When you flag this during a pull request, they can fix it before deployment.
I remember an early customer of Infracost catching this exact issue. The engineers themselves pushed for the change, realizing they didn’t need identical resources in production and non-production. The savings were massive.
Hassan Khajeh-Hosseini:
Another example is right-sizing resources. Once engineers start seeing costs at the code level, they develop a “cost muscle” and begin making better decisions from the start. For instance, switching from older generation instance types like GP2 to GP3 can save 20–30%.
Hassan Khajeh-Hosseini:
We also help teams avoid costly mistakes, like using unsupported resources. For example, AWS has an extended support fee for older instance types, which could increase costs by 200%. If engineers know this upfront, they can choose newer, supported types instead.
Andrew Way:
That’s a great point. And I’ll add that it’s not just using IaC that reduces costs—it’s using IaC in combination with tools like Infracost and env0. These tools provide visibility and actionable insights, enabling engineers to make cost-effective decisions.
Andrew Way:
At env0, we also track usage by tagging resources. By querying the billing APIs, we can provide detailed cost breakdowns across projects and environments.
Hassan Khajeh-Hosseini:
Makes sense. Andrew, quick question—env0 can detect and fix drift, and even generate IaC code. Would you recommend automating the remediation process entirely?
Andrew Way:
Not yet. Automating drift remediation fully can be risky, especially when intentional drift happens, like during incidents where engineers bypass IaC to make quick fixes.
For example, if an automated process overwrote a manual fix, it could recreate the issue that engineers were trying to resolve in the first place.
However, env0 does allow you to schedule automatic redeployments. This essentially force-pushes the desired state defined in code back into the cloud. But for critical resources, we recommend introducing approval workflows to ensure any changes are deliberate and safe.
Andrew Way:
There’s a lot more to this, and we’ve written a detailed blog post on automated drift detection and remediation with env0. I’d be happy to share that link after this session.
Hassan Khajeh-Hosseini:
Very cool. Andrew, do you have a few more minutes to go through additional questions?
Andrew Way:
Absolutely.
Hassan Khajeh-Hosseini:
All right. Mike asked if Infracost has two components—the pull request integration and a central dashboard for FinOps teams.
Hassan Khajeh-Hosseini:
Yes, exactly. The pull request integration gives engineers immediate feedback on cost impacts. Meanwhile, the central dashboard in Infracost Cloud allows FinOps teams to set budgets, policies, and guardrails. For example, you can block pull requests that exceed a certain cost threshold or trigger approval workflows.
Andrew Way:
That’s a great example of bridging the gap between engineering and FinOps teams.
Hassan Khajeh-Hosseini:
Thanks! All right, let’s take one last question before wrapping up.
Andrew Way:
Sounds good.
Hassan Khajeh-Hosseini:
Okay, we have a question from Orlando about reducing cloud costs through specific IaC practices. Andrew, do you want to share any examples?
Andrew Way:
Sure. One common example is scheduling resource usage. Let’s say you have development environments that are only needed during business hours. By using IaC to define schedules, you can automatically shut down resources when they’re not needed—nights, weekends, and so on. This can lead to significant cost savings.
Another example involves optimizing storage classes. Often, resources default to premium storage types, even when they aren’t necessary. IaC enables teams to set policies and automate storage class selection to ensure the right balance between performance and cost.
Hassan Khajeh-Hosseini:
Exactly. And tying it back to Infracost, once you show engineers the impact of their choices—like, “Hey, switching from one instance type to another will save X dollars”—they start to internalize these best practices.
Andrew Way:
Right, it’s all about building that cost-awareness muscle within the engineering workflow.
Hassan Khajeh-Hosseini:
Okay, Andrew, let’s shift focus to env0’s roadmap. You mentioned some exciting features earlier—can you expand on that?
Andrew Way:
Absolutely. As you’ve seen with Cloud Compass, we’re helping customers gain visibility into their resources—how they’re created, whether they’re drifted, and so on. We’re building on this with new insights to help teams better understand and manage their infrastructure.
For example, we’re introducing features to identify dangling resources—things like unattached disks or unused IP addresses. These are common sources of waste, and we’re making it easier to identify and clean them up.
We’re also enhancing our drift detection capabilities, focusing on making the remediation process smoother and more intelligent.
Hassan Khajeh-Hosseini:
That sounds fantastic. For Infracost, our focus remains on closing the gap between engineering and FinOps teams. This includes deeper integrations and making cost insights even more actionable—shifting left wherever possible.
Hassan Khajeh-Hosseini:
And, of course, if you’re attending this webinar and have ideas or requests for features, feel free to reach out to us. We’re always listening to the community.
Andrew Way:
Same here. If you’re using env0 or considering it, let us know what you’d like to see. We’re constantly evolving based on customer feedback.
Hassan Khajeh-Hosseini:
I think that wraps things up nicely. Andrew, thank you so much for joining me today. This was a great discussion.
Andrew Way:
Thank you, Hassan. And thanks to everyone who attended.
Hassan Khajeh-Hosseini:
All right, take care, everyone. See you next time!
Andrew Way:
Bye!
Join Hassan Khajeh Hosseini, CEO of Infracost, and Andrew Hay, env0's Director of Customer Success, for a 30-minute lightning talk exploring the synergy between Infrastructure as Code (IaC) and FinOps.
Through real-world examples and a live demo, they demonstrate how IaC shifts FinOps left, decentralizes infrastructure provisioning, and enables self-service with built-in guardrails. They also examine why infrastructure drifts persist, even with streamlined launch processes.
Transcript
Hassan Khajeh-Hosseini:
All right. Let's get started. Hey, everyone, welcome in. As I said, no slides—just me and Andrew. We'll do a quick introduction as well.
So, hey, everyone, I’m Hassan. I’m one of the founders of Infracost. I’ve been working in Cloud Cost Management and FinOps for around 13–14 years now. This one thing that we’ve done differently with previous startups, and now with this one, is this “shift left.” That’s something we’ll talk about today. I’m very excited to be here—let’s keep it short and sweet. Andrew, over to you!
Andrew Way:
Hello, everyone. My name is Andrew, and I’m the Director of Sales Engineering here at env0. Just real quickly, env0 is an Infrastructure as Code (IaC) management solution. I’ve been in the DevOps space for the past six years—previously more on application CI/CD. For the past three and a half years at env0, I’ve been focusing on Infrastructure as Code CI/CD. I’ve also been working in DevTools sales for over ten years and originally started as a developer. Pleasure to meet everyone here—I’m excited to have this conversation with you all.
Hassan Khajeh-Hosseini:
Awesome. Andrew, what are you seeing in terms of IaC adoption? How widely is it adopted?
Andrew Way:
Great question. So, we just came back from KubeCon. At our booth, we asked everyone who stopped by, “Do you use Terraform?” and 90% of people said, “Yes.” That’s a strong indicator that IaC adoption is widespread.
The cloud is becoming code, and people need repeatable ways to manage cloud infrastructure. That’s why IaC adoption is growing. On top of that, even on-prem resources are now being deployed using IaC, enabling hybrid cloud setups.
When they developed Terraform, the creators purposely avoided being opinionated on the approach. While this helped Terraform gain popularity, it has also led to a lot of variability. Everyone does things their own way, and managing those differences can be tricky. That’s where tools like env0 help—by providing a way to manage and streamline how Terraform and IaC are used across teams.
Hassan Khajeh-Hosseini:
Gotcha. Yeah. Okay. So like, essentially what you’re saying is, the Infrastructure as Code is being widely adopted. I guess it enables self-service. So anyone can launch whatever they need, whenever they need. A good decentralization of that.
Andrew Way:
Right. But that starts creating other issues. If everyone is creating resources, how do you ensure governance? For example, how do you know what has been created? How do you coordinate deployments across distributed teams?
Another challenge is drift. Drift can happen in many ways. Traditionally, it’s when code gets deployed, but someone updates the resource directly in the cloud. Now, the code and the actual infrastructure don’t match. As developers, we traditionally think of code as the “source of truth,” but with drift, the cloud state can differ from the code.
Drift can also occur in other ways. For example, let’s say you deploy an EC2 instance and use a data source to pull the latest AMI. Over time, that AMI changes as new releases or security patches are issued. Even though the code hasn’t changed, the infrastructure has drifted. Tools like env0 can schedule drift detection to help catch and manage these changes.
Hassan Khajeh-Hosseini:
Chris raised an interesting question about pipeline-driven IaC deployments. Isn’t that a better way to prevent drift?
Andrew Way:
Absolutely. A pipeline-driven Terraform deployment approach is better for managing infrastructure. We’ve seen customers build pipelines to deploy IaC effectively. But even with pipelines, if you don’t schedule regular drift detection scans, drift can still happen. It’s important to have both robust pipelines and automated checks to catch drift before it becomes an issue.
Hassan Khajeh-Hosseini:
Got it. And drift can occur in other ways too, right? For example, with data sources or updates that don’t go through the pipeline?
Andrew Way:
Exactly. The thing is, code is declarative, but not deterministic. So for example, if you are pulling in a data source like the latest AMI, your code itself hasn’t changed, but the AMI has changed, and that causes quote-unquote drift.
Hassan Khajeh-Hosseini:
Ah, I see. And this is where tools like env0 can help with drift detection?
Andrew Way:
Yeah, exactly. Drift detection essentially runs a plan, and you can compare what’s out there versus what the code says. This is key for maintaining alignment between your infrastructure and your IaC.
Hassan Khajeh-Hosseini:
I have another question. Are you seeing more adoption of Crossplane, and how does that compare to Terraform?
Andrew Way:
Crossplane is very useful for customers who are highly invested in Kubernetes. If your development team is already well-versed in Kubernetes, Crossplane is a great way to enable self-service for application teams to access AWS or other cloud infrastructure. However, there’s a chicken-and-egg problem—someone still needs to deploy the Kubernetes cluster that hosts Crossplane, though that’s usually a one-time cost.
Hassan Khajeh-Hosseini:
I’ve seen some Crossplane usage too. It’s still early days—I don’t hear about it all the time, but it does pop up occasionally. Timothy, good to see you! You brought up incident management earlier. Drift often comes up there, right?
Andrew Way:
Yes, definitely. Not all drift is accidental—sometimes it’s intentional, like during an incident where someone bypasses normal processes to make a quick fix. That’s where governance and visibility become essential.
Let’s shift gears. One of the big topics here is the intersection of IaC and FinOps. What’s the link between cloud costs and IaC?
Hassan Khajeh-Hosseini:
That’s a good question. The way I like to explain it is by simplifying cloud costs into a formula: usage multiplied by price. The usage component is fully engineering-driven—what services do I use, and how much do I use them? This includes the architecture, the resources deployed, and so on.
Then there’s the price component—this is essentially the list price you pay to cloud providers like AWS, Azure, or GCP. You can optimize the price by buying reservations, using EDP discounts, or negotiating rates. But that’s more of a financial decision handled by a central finance or FinOps team, with less impact on engineers directly.
On the engineering side, the usage piece is the most important. Here’s the issue: engineers, who are essentially the buyers of infrastructure, are rarely told upfront how much their deployments cost. There’s no “checkout screen,” so they deploy what they need without visibility into the cost impact. This leads to broken budgets and a disconnect between engineering and finance teams.
That’s where “shift left” comes in. By integrating cost estimates into the IaC workflow—tools like Infracost—we give engineers visibility at the pull request stage. For example, engineers deploying a non-production environment might see that they’re using a Multi-AZ setup unnecessarily. By catching these things early, they can make cost-effective decisions upfront and avoid rework later.
Andrew Way:
Nice. Now, there’s a question in the chat.
Hassan Khajeh-Hosseini:
Yeah, I love it.
Andrew Way:
It’s from Timothy, about tracking usage costs. So right now, you’re showing a lot of estimated costs, but I’m curious from your perspective—does Infracost do anything for actual usage tracking?
Hassan Khajeh-Hosseini:
Yeah, great question. So, we’ve actually split them out. We have something called a usage file, where you can say, “When you’re estimating something and you don’t know what the usage is going to be, use this usage as the basis for estimation.”
A lot of the time, engineers are estimating things like data transfer, and by the time you’re looking at those data transfer costs, it’s probably too late to change. But it’s super helpful for the engineer to start learning how data transfer costs impact the overall cost of the application.
So, we split these components out—we show the pricing parameters and allow you to bring in the usage data through the usage file. There’s more we can build out in this area, but right now, it’s a useful way to help engineers focus on the things they can actually change at the pull request stage. That’s where it’s really helpful for them.
Hassan Khajeh-Hosseini:
But, none of this works if there’s drift. For example, if you’re not using IaC and someone just goes into the dashboard, clicks a button, and launches what they need, there’s no way to interject that process.
I remember when we first talked about env0’s Cloud Compass feature—I found that super interesting. Andrew, could you explain more about that and how it helps with drift?
Andrew Way:
Yeah, absolutely. Let me show you what env0 can do for you today.
In our dashboard, we track all deployments made within env0. Whether you’re using Terraform, Pulumi, or something else—we support it. We can turn on a scheduling job to regularly run a plan and detect if there’s been any drift.
For example, I can see that I have 251 environments deployed, and 17% of them have drifted. I’ll drill into one specific deployment here—an EC2 instance. On the deployments tab, we can see drift detection running on a schedule. It’s found three changes: three removals and two modifications.
This ties back to what I mentioned earlier about code being declarative but not deterministic. The code hasn’t changed, but the AMI used has been updated because it’s pulling in the latest version. This creates “drift,” even though no one intentionally changed the code.
Andrew Way:
We also have the Cloud Compass feature. This allows us to scan AWS and Azure accounts and see how resources were created—whether through Infrastructure as Code, the API, or via “clickops.”
For example, I can see here that 97% of my resources were created using IaC, but there are still a few created through the API or manually. Let’s say I have some IAM policies created through clickops. From here, I can take an action—like generating IaC code for these resources. If I select OpenTofu, it generates the import blocks for me, making it easy to transition those resources into Infrastructure as Code.
This is just one way env0 helps manage drift.
Andrew Way:
But we’re taking it further. In the coming weeks, we’ll be introducing a new feature called “Drift Lane.”
Hassan Khajeh-Hosseini:
Oh, I like the sound of that!
Andrew Way:
It’s pretty cool. Drift Lane will let you see who caused the drift. For example, you’ll be able to identify the API key used or the user who logged into the cloud console and made a manual change. This level of visibility is something we’re excited to release soon.
Hassan Khajeh-Hosseini:
That’s fantastic. I think it’s going to be really helpful, especially in reducing direct access and bringing everything under IaC management.
Andrew Way:
Absolutely. And it’s not about blaming engineers—it’s about understanding why drift happens. Often, engineers are just trying to work around a blocker in the CI/CD pipeline. If we address those blockers, we can prevent drift from occurring in the first place.
Hassan Khajeh-Hosseini:
Totally agree. Shall we take some more questions?
Andrew Way:
Yes, let’s do that.
Hassan Khajeh-Hosseini:
All right, let’s look at the next question.
Andrew Way:
This one’s about tracking actual costs. It’s a follow-up from Timothy. Maybe I’ll quickly show how env0 integrates with Infracost.
For example, here’s a deployment where we’re showing the estimated cost of resources with Infracost built into env0. But what’s unique about env0 is that we can also track actual usage.
Here, you can see the actual spend—$6.34 in this case. Over time, if something changes, such as the instance size, the actual cost updates, and we can track that spend as it evolves. We summarize this over the entire project, so teams can see both estimated and actual costs side by side.
Hassan Khajeh-Hosseini:
That’s awesome!
Andrew Way:
It’s super helpful, especially for tracking consumption-based resources.
Hassan Khajeh-Hosseini:
Orlando just asked a good question about generating Terraform code for resources created manually. Does env0 actually generate the code?
Andrew Way:
Yes, it does. We just demonstrated that. When you scan your cloud accounts with Cloud Compass, it identifies resources created manually or through the API. From there, you can generate IaC code for those resources and integrate it into your workflows.
Hassan Khajeh-Hosseini:
That’s such a powerful feature. I love that.
Hassan Khajeh-Hosseini:
Now, someone else asked if Infracost can generate the usage file automatically.
Hassan Khajeh-Hosseini:
Yes, it can. When you first run it on a project, it generates a baseline usage file based on the resources it identifies. You can manage this centrally in Infracost Cloud or at the repository level with different usage files for different projects.
Hassan Khajeh-Hosseini:
This makes it really easy to standardize cost estimates across multiple teams and projects.
Andrew Way:
Let’s take one more question.
Hassan Khajeh-Hosseini:
Sure. This one is about specific examples of how IaC can help reduce cloud costs and improve FinOps.
Hassan Khajeh-Hosseini:
A great example comes from engineers deploying resources to non-production environments. They might unknowingly use a 16xl instance—something designed for production. When you flag this during a pull request, they can fix it before deployment.
I remember an early customer of Infracost catching this exact issue. The engineers themselves pushed for the change, realizing they didn’t need identical resources in production and non-production. The savings were massive.
Hassan Khajeh-Hosseini:
Another example is right-sizing resources. Once engineers start seeing costs at the code level, they develop a “cost muscle” and begin making better decisions from the start. For instance, switching from older generation instance types like GP2 to GP3 can save 20–30%.
Hassan Khajeh-Hosseini:
We also help teams avoid costly mistakes, like using unsupported resources. For example, AWS has an extended support fee for older instance types, which could increase costs by 200%. If engineers know this upfront, they can choose newer, supported types instead.
Andrew Way:
That’s a great point. And I’ll add that it’s not just using IaC that reduces costs—it’s using IaC in combination with tools like Infracost and env0. These tools provide visibility and actionable insights, enabling engineers to make cost-effective decisions.
Andrew Way:
At env0, we also track usage by tagging resources. By querying the billing APIs, we can provide detailed cost breakdowns across projects and environments.
Hassan Khajeh-Hosseini:
Makes sense. Andrew, quick question—env0 can detect and fix drift, and even generate IaC code. Would you recommend automating the remediation process entirely?
Andrew Way:
Not yet. Automating drift remediation fully can be risky, especially when intentional drift happens, like during incidents where engineers bypass IaC to make quick fixes.
For example, if an automated process overwrote a manual fix, it could recreate the issue that engineers were trying to resolve in the first place.
However, env0 does allow you to schedule automatic redeployments. This essentially force-pushes the desired state defined in code back into the cloud. But for critical resources, we recommend introducing approval workflows to ensure any changes are deliberate and safe.
Andrew Way:
There’s a lot more to this, and we’ve written a detailed blog post on automated drift detection and remediation with env0. I’d be happy to share that link after this session.
Hassan Khajeh-Hosseini:
Very cool. Andrew, do you have a few more minutes to go through additional questions?
Andrew Way:
Absolutely.
Hassan Khajeh-Hosseini:
All right. Mike asked if Infracost has two components—the pull request integration and a central dashboard for FinOps teams.
Hassan Khajeh-Hosseini:
Yes, exactly. The pull request integration gives engineers immediate feedback on cost impacts. Meanwhile, the central dashboard in Infracost Cloud allows FinOps teams to set budgets, policies, and guardrails. For example, you can block pull requests that exceed a certain cost threshold or trigger approval workflows.
Andrew Way:
That’s a great example of bridging the gap between engineering and FinOps teams.
Hassan Khajeh-Hosseini:
Thanks! All right, let’s take one last question before wrapping up.
Andrew Way:
Sounds good.
Hassan Khajeh-Hosseini:
Okay, we have a question from Orlando about reducing cloud costs through specific IaC practices. Andrew, do you want to share any examples?
Andrew Way:
Sure. One common example is scheduling resource usage. Let’s say you have development environments that are only needed during business hours. By using IaC to define schedules, you can automatically shut down resources when they’re not needed—nights, weekends, and so on. This can lead to significant cost savings.
Another example involves optimizing storage classes. Often, resources default to premium storage types, even when they aren’t necessary. IaC enables teams to set policies and automate storage class selection to ensure the right balance between performance and cost.
Hassan Khajeh-Hosseini:
Exactly. And tying it back to Infracost, once you show engineers the impact of their choices—like, “Hey, switching from one instance type to another will save X dollars”—they start to internalize these best practices.
Andrew Way:
Right, it’s all about building that cost-awareness muscle within the engineering workflow.
Hassan Khajeh-Hosseini:
Okay, Andrew, let’s shift focus to env0’s roadmap. You mentioned some exciting features earlier—can you expand on that?
Andrew Way:
Absolutely. As you’ve seen with Cloud Compass, we’re helping customers gain visibility into their resources—how they’re created, whether they’re drifted, and so on. We’re building on this with new insights to help teams better understand and manage their infrastructure.
For example, we’re introducing features to identify dangling resources—things like unattached disks or unused IP addresses. These are common sources of waste, and we’re making it easier to identify and clean them up.
We’re also enhancing our drift detection capabilities, focusing on making the remediation process smoother and more intelligent.
Hassan Khajeh-Hosseini:
That sounds fantastic. For Infracost, our focus remains on closing the gap between engineering and FinOps teams. This includes deeper integrations and making cost insights even more actionable—shifting left wherever possible.
Hassan Khajeh-Hosseini:
And, of course, if you’re attending this webinar and have ideas or requests for features, feel free to reach out to us. We’re always listening to the community.
Andrew Way:
Same here. If you’re using env0 or considering it, let us know what you’d like to see. We’re constantly evolving based on customer feedback.
Hassan Khajeh-Hosseini:
I think that wraps things up nicely. Andrew, thank you so much for joining me today. This was a great discussion.
Andrew Way:
Thank you, Hassan. And thanks to everyone who attended.
Hassan Khajeh-Hosseini:
All right, take care, everyone. See you next time!
Andrew Way:
Bye!
.png)
