u/WasteAcanthaceae4938

Ok so multi cloud management at our place has quietly turned into aws rules, gcp rules and azure vibes. Dev teams own more infra now, and every day we get a pile of PRs with new queues, random IAM in prod, an extra db in gcp and an EKS tweak in aws... all technically fine, zero architectural context.

The bigger problem is we now have three different ideas of what governed infra is supposed to look like. how are you deciding what gets standardized across clouds and what stays provider specific?

We’re evaluating Terraform Cloud alternatives because we want stronger day-to-day workflows around IaC governance and configuration drift, not simply a different place to run plans and applies. The goal is better visibility into meaningful drift, clearer ownership of remediation, policy controls that do not block every team, and reliable auditability across multiple cloud accounts and environments.

One concern is that “drift detection” often becomes a noisy stream of changes that nobody owns. We need a workable process for deciding whether a change should be reverted, codified in Terraform, or intentionally accepted, along with a way to track that decision through to resolution.

For platform teams that switched away from Terraform Cloud, what did you replace it with, and did it improve governance in real operational workflows or mainly add another control plane?

New Gartner category from the 2025 Hype Cycle: Cloud Application Infrastructure Recovery Solutions. Core idea, treat infra as rebuildable code, not data to restore.

Firefly was named a sample vendor. Feels like a genuinely new problem space rather than repackaged DR.

Anyone actually running a CAIRS-style tool, or is everyone still on backup plus manual rebuild runbooks?

cybersecurity keeps attackers out. cyber resilience assumes they'll get in anyway and focuses on staying operational and recovering fast. NIST's version: "anticipate, withstand, recover from, and adapt to" adverse conditions.

That's the textbook definition, what does it actually look like for your team day to day, beyond "we have a DR plan"?

Compliance is asking for proof we can recover cloud infra within a defined timeframe. "We have backups" apparently isn't going to cut it.
What actually satisfies an auditor here, documented RTO/RPO per workload, a tested rebuild log, something else? Anyone been through a DORA or NIS2 audit recently who can share what held up

After auditing dozens of Terraform environments across enterprise teams, I keep seeing the same drift patterns causing the same incidents. Here's the straightforward approach that actually works.

Detection starts with terraform plan -refresh-only. Run it daily at minimum. In CI/CD, add a drift check that alerts on any differences. For larger environments, continuous scanning is worth the effort – catching drift within minutes beats discovering it during an outage.

Fixing depends on what you find. Manual console changes get adopted via terraform import. Deleted resources get removed from state with terraform state rm. Configuration mismatches need either code updates or a terraform apply -refresh-only to force the cloud back to spec – but that last one requires understanding what you're overriding.

Prevention is where mature teams focus. IAM policies that block manual changes to tagged resources. Lifecycle rules like prevent_destroy on critical assets. Clear tagging conventions so everyone knows what's managed. And most importantly, an audit trail that tells you who changed what and why.

The teams that handle drift well don't just react to it. They build detection into their workflows, establish clear remediation playbooks, and continuously tighten guardrails based on what they learn from past incidents. What patterns have you seen across your teams?

We are reviewing our IaC platform and looking beyond Terraform Cloud and Spacelift.

Orchestration is important, but from an SRE perspective, we are also trying to improve visibility and recovery. Some resources exist outside Terraform, and configuration drift means Git does not always represent the live environment correctly.

The features that matter most to us are:

1. Terraform and OpenTofu orchestration

2. Detection of managed, unmanaged and drifted resources

3. Automatic IaC generation for existing infrastructure

4. Policy enforcement and approval controls

5. Infrastructure history and rollback

6. Recovery into a clean account or region

Useful integrations without maintaining more custom automation

Which alternatives have worked well for your team? I am interested in production experience with drift remediation and recovery testing, not just deployment workflows.

In my last role, we ended up multi cloud mostly by accident, major workloads on AWS, a big legacy system on Azure, some experiments on GCP, and a handful of SaaS platforms that each came with their own identity and billing surface, another provider in every way that mattered. Nobody planned a unified strategy, it just evolved that way. I have since talked to teams who went multi cloud on purpose, picking providers deliberately for specific managed services, so this is not only an accidental sprawl story, though many of what we learned came from cleaning up the accidental version.

We had to figure out which bits were in the right place for real reasons, like latency or compliance requirements and which were just historical accidents. We tried to get identity and backups into something resembling a common pattern, while accepting that each provider has its own quirks. Terraform helped once we agreed on conventions.

The other key piece was visibility: tooling that showed us what was under IaC across every provider we ran and what wasn't, plus a read on cost and risk for each. Without that, multi cloud felt like we were flying blind.

For anyone who is intentionally or unintentionally multi cloud: have you found a way to make it feel like a strategy instead of entropy or is it one control plane stacked on another?