DEV Community: cloudcosttree

Generating least-privilege IAM policies directly from a Terraform/CloudFormation/Pulumi plan (1,486 resource types mapped)

cloudcosttree — Wed, 02 Sep 2026 13:07:00 +0000

Every AWS deployment needs a role with permissions to create/update/delete whatever's in the stack, and most people either reach for AdministratorAccess, because hand-writing the exact least-privilege actions for every resource type is tedious and nobody wants to maintain that by hand as the stack grows.

CloudCostTree has a command for that: cloudcosttree iam reads a Terraform, CloudFormation, or Pulumi plan and generates the real IAM actions a deployment needs, per resource type, without ever calling AWS. It currently maps 1,486 AWS resource types.

[screenshot]

That screenshot is the human-readable text view. Run it with --output json -o policy.json and it produces a ready-to-attach IAM policy document instead of this breakdown.

Where it's honest about its limits: every generated policy currently uses Resource: "*", the Action list is real least-privilege scoped to what each resource type needs, but the Resource element isn't narrowed to the exact ARNs a deployment declares yet. Per-resource ARN scoping is a planned capability, not implemented. Free on both tiers today.

Something that's easy to miss: cost tooling and observability data can feed into the same loop, not two separate concerns

cloudcosttree — Fri, 21 Aug 2026 12:41:05 +0000

CloudCostTree reads your Terraform/CloudFormation/Pulumi and shows a cost tree from static config alone. That's useful before deploy, but static config only tells you what something was provisioned for.

Once it's actually running, the same tool can pull real CloudWatch metrics, CPU utilization, live Spot pricing, through your own read-only AWS credentials, and re-run the same analysis against real telemetry instead of declared instance types. Same report, same command, just backed by observed data instead of assumptions.

Point being, a resource can look perfectly sized on paper and still be sitting at 4% CPU in production. You only catch that gap by closing the loop between what you declared and what you're actually observing.

Something easy to miss when using cost tooling: it's most useful at two separate moments, not just once before a deploy

cloudcosttree — Thu, 20 Aug 2026 12:53:25 +0000

Before deploy: running the analysis against your IaC files up front shows you the full cost breakdown plus savings recommendations, and applies whatever's safe to apply without a human decision, before anything actually gets provisioned.

After deploy: once it's live, re-running the same analysis with real CloudWatch usage data (via your own read-only AWS credentials) refines those recommendations against actual utilization instead of static config assumptions.

The reason this matters for FinOps specifically: static config tells you what something was provisioned for, not what it's costing you in practice. A right-sizing call made purely from declared instance types will miss real idle capacity, and one made purely from live usage misses waste that never should've been provisioned in the first place. Catching both requires checking at both points in the lifecycle, not just once.

(Built this into CloudCostTree, a CLI I've been working on, happy to go into specifics if useful.)

One thing CloudCostTree already handles: a local apply-time policy gate

cloudcosttree — Wed, 19 Aug 2026 12:56:41 +0000

Most teams I talked to don't have a CI/CD pipeline checking cost or governance policy before terraform apply, they just run it locally. That's what guard is for: cloudcosttree guard -- terraform apply.

To be clear, this isn't a simulation, it's your real terraform apply. guard never runs one on its own, it only wraps the exact command you were already going to run, checks the plan against your policies, then applies that same saved plan, so there's no gap between what got checked and what got deployed.

Default behavior is warn-only, it prints violations but still applies. --block opts into actually stopping the apply on a real violation. A false positive blocking a real deploy is worse than one showing up in a report, so blocking is never the default.

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.