Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Cloud Contracts Now Meter Your IaC Drift Detection Runs
Transcript
- Lucas: If you manage infrastructure with Terraform or CloudFormation, you know drift detection is one of those things you set up once and forget about. It runs in the background, checks if your actual cloud resources match your config files, and alerts you if something changed outside of IaC. Luna: Right — it's a compliance and security essential. But I'm guessing that's about to get more expensive? Lucas: Exactly. Over the past few months, both AWS and HashiCorp have quietly updated their pricing models to meter drift detection runs. AWS started charging per drift scan on CloudFormation stacks back in April, and Terraform Cloud's latest pricing tier now includes drift detection as a metered feature. Luna: So a tool that was essentially free or bundled into a flat license is now a consumption-based cost. How much are we talking? Lucas: Let me give you a concrete example. I talked to a fintech company that runs about 500 CloudFormation stacks across three environments. They enabled automated drift checks every hour for pci dss compliance. Under the old model, that was included in their Enterprise Support plan. Now AWS charges $0.03 per drift scan per stack. That's 500 stacks times 24 scans a day — 12,000 scans a day — times $0.03, times 30 days. That's $10,800 a month just for CloudFormation drift detection. Luna: Wait — $10,800 just to check if anything drifted? That's insane. Lucas: It's a massive increase from zero. And Terraform Cloud's model is different but equally impactful. Their new Business tier includes 10,000 drift detection runs per month, then charges $0.001 per additional run. For a team running 50 workspaces with hourly checks, that's about 36,000 runs a month. So they're paying for 26,000 extra runs at $26 a month — not huge, but if you scale to 200 workspaces, you're looking at over $100 a month extra. Luna: Okay, so the per-unit cost seems low for Terraform, but the volume adds up. And I imagine the real pain is the unpredictability — you don't know how many drift scans you'll trigger until you get the bill. Lucas: That's exactly right. And it's worse because drift detection isn't something you actively think about. You set it up once, it runs silently, and suddenly it's a line item on your monthly cloud bill. The fintech company I mentioned didn't catch it until three months in. They had racked up over $32,000 in extra costs before someone noticed the anomaly in their cost explorer. Luna: So what's the move? Do you just turn off drift detection and hope nothing changes? Lucas: That's one option, but not a great one if you operate in a regulated industry. Better approach: audit your current drift detection frequency. Most teams default to hourly because it's easy. But if you're not deploying changes every hour, you probably don't need hourly scans. Drop it to every six hours or once a day. That single change reduces the fintech company's cost from $10,800 to $1,800 a month. Luna: Right — you're aligning the scan frequency with your actual deployment cadence. If you only push changes twice a day, why scan every hour? Lucas: Exactly. Another tactic: use event-driven drift detection instead of scheduled scans. Both AWS Config and Terraform Cloud can trigger a drift check when a resource is modified via the console or API. That way you only pay for scans when something actually changes, not on a fixed schedule. Luna: But that assumes you can detect changes in real time. If someone makes a manual change through the console, you'll catch it immediately. But what about changes that happen outside your control, like auto-scaling or automated backups? Lucas: Good point. Auto-scaling groups and RDS automated backups do change resources, but those are expected. You can exclude certain resource types from drift detection or use a more lenient scan frequency for those. The key is to be intentional about what you monitor and how often. Luna: So the lesson here is: treat drift detection like any other cloud consumption cost. Monitor it, set budgets, and review your scan strategy regularly. Lucas: Exactly. And I'd add one more thing: negotiate your contract. If you're a large customer, ask your cloud provider to include a certain number of drift scans in your committed spend. AWS is willing to negotiate on these metered services if you have leverage. Luna: That's a good reminder — everything in cloud contracts is negotiable if you ask. Lucas: Right. So to summarize: cloud providers are increasingly metering previously free operational tools. Drift detection is the latest example. The fix is to reduce scan frequency, use event-driven triggers, and include it in your cost governance framework. Luna: And if this episode saved you from a surprise bill, that's exactly the kind of practical value we try to deliver every week. The reason we can keep doing that without ads or sponsors is listener support. If you found today useful, you can buy us a coffee at buy me a coffee dot com slash fexingo. Lucas: Yeah, it really does help us stay independent and focused on the details that matter. So thanks to anyone who chips in. Luna: Alright, back to the numbers. One final thought: as these metering models spread, we're likely to see similar changes for other IaC features like plan caching and state file reads. We covered those in earlier episodes, but drift detection is the one catching teams off guard right now. Lucas: Agreed. Keep an eye on your bill, and don't let silent services become silent cost drivers. That's it for today — we'll be back tomorrow with another angle on cloud economics.