Why most Terraform cost estimators guess at Auto Scaling Groups (and why that's a problem)

cloudcosttree — Thu, 13 Aug 2026 14:49:34 +0000

If your Auto Scaling Group uses mixed_instances_policy, no cost tool reading your Terraform can tell you what instance type it's actually running. Not because the tool is bad. Because the information genuinely isn't in your config.

You declare a launch template with a few weighted overrides, say m5.large, m5a.large, and m5n.large, and AWS decides at launch time which one actually gets used based on capacity and price. Your .tf file never says which one wins. It can't, the answer depends on what AWS has available right now, not on anything you declared.

So what do most cost estimators do with this? Usually one of two things: pick the first override and price the whole group as if every instance were that type, or silently show it as free because nothing matched a known shape. Both are wrong in a way that looks right. You get a clean dollar number with no indication that it's a guess.

I built CloudCostTree, and when I hit this case the honest answer was to not show a number at all. A group using mixed_instances_policy renders as unpriced by default, because there's no way to know which override actually got used without asking AWS directly. If you opt into --with-usage, it calls AWS's own API, looks at what's actually running right now, and prices the group as its most common real instance type. Without that, it stays unpriced rather than confidently wrong.

This isn't a one-off. It's the same call in a few other places: a Bedrock model pointing at a custom or fine-tuned version doesn't get resolved and priced, because that resolution isn't something a static config can answer. A multi-variant SageMaker endpoint gets priced against its first declared variant only, since there's no way to know real traffic split from the config alone, and that's disclosed, not hidden.

The pattern I keep coming back to is: if a value can't be confirmed, it's better to say so than to fabricate something plausible. A wrong number that looks confident is worse than a visible gap, because the wrong number gets trusted and the gap gets investigated.

If you're curious what this looks like end to end, I wrote CloudCostTree around this idea, a CLI that reads Terraform, CloudFormation, or Pulumi and prices your infrastructure before you apply it: https://cloudcosttree.com

Happy to talk through edge cases if anyone's hit something similar.

DEV Community: cloudcosttree

Why most Terraform cost estimators guess at Auto Scaling Groups (and why that's a problem)