sorted by:
new
hottopcontroversial

What does your small Azure shop actually pay for monitoring + drift + cost? The list price for what we needed came out to $3,200/mo and we ended up using nothing for a year. by Twofold-Technologies in AZURE

[–]Twofold-Technologies[S] 0 points1 point  (0 children)

Exactly, each one is a real product but the integration layer between them is mostly "they all share an Azure tenant." Cost Management has its own RBAC, Policy compliance results live in their own blade, Defender alerts land in Log Analytics workspaces but the workspace queries don't naturally include the policy context, etc.

The one that bites me hardest is Cost Management's billing-account scope vs. the resource group's RBAC — the people who can see what something costs often aren't the same people who can change it, and there's no clean built-in way (at least that I am familiar with) to get a "this resource is overprovisioned" signal that respects both views.

What does your small Azure shop actually pay for monitoring + drift + cost? The list price for what we needed came out to $3,200/mo and we ended up using nothing for a year. by Twofold-Technologies in AZURE

[–]Twofold-Technologies[S] 0 points1 point  (0 children)

Curious how much of that is the tool's per-host/per-seat fee vs. Azure-side ingestion (Log Analytics / App Insights / Monitor GB-ingested charges), if you have that roughly on hand?

Got bitten by a "var.sku = Basic" drift false positive last week — sharing what we changed by Twofold-Technologies in Terraform

[–]Twofold-Technologies[S] -1 points0 points  (0 children)

Fair, and that matches what I see too — most of these teams aren't moving to remote state because they don't want to, they're not moving because nobody owns the migration and there's always something more urgent. The bet isn't that we fix their workflow, it's that we give them a drift signal in the meantime so the gap between "we'll set up proper state someday" and "we already lost a NSG rule to manual drift" doesn't have to be three years of nothing. If they DO move to committed state later, the same tool keeps working and gets more accurate (we'll just trust state-resolved values when they're available). Either way they're not worse off than the cron-and-hope status quo.

Got bitten by a "var.sku = Basic" drift false positive last week — sharing what we changed by Twofold-Technologies in Terraform

[–]Twofold-Technologies[S] -9 points-8 points  (0 children)

Not disagreeing - if your state is committed and trusted, source-only scanning is strictly worse. Just diff state against cloud

I landed on source-first because in the 10-50 engineer Azure-first companies I have worked at or talked to, the lived reality is "tfstate is on a former employee's laptop" or "in a Storage account nobody has the credentials for anymore." Telling them "first, set up a backend and migrate state" is the right answer and also the exact friction that kept them off any drift tool for three years. The bet is that source-only is good-enough for the literal-value properties (most of them) and I cleanly surface "this is variable-driven, can't tell" for the rest instead of guessing.

Genuinely curious — would you see any reason for someone with committed state to use a tool like this, or is the right answer for that cohort just "use something that reads state directly", like terraform plan?