u/Adventurous_Rope4025

This is mainly for people running Terraform at scale with Spacelift or similar tools. Many of the Spacelift alternatives content I have found is just tool lists: env0, Terraform Cloud or HCP, Scalr, Atlantis, Terrateam, Terramate and so on. That is fine for awareness, but it does not answer the real question for us: if your pain points are drift detection and cloud asset visibility, what should you switch to?

By better drift detection and cloud asset visibility, I mean continuous detection of changes that never went through Terraform, a clear view of what percentage of your estate is codified and visibility into unmanaged resources sitting outside Terraform. I know that last part pushes past what a TACO things like Spacelift is built to do on its own, closer to CSPM territory, so I want to know whether people paired their orchestration things with something else for that piece rather than expecting one way to cover it all. Bonus points if fixes are driven through Git rather than fix it in the console and hope.

If you have left Spacelift, what did you move to, and did it change your story around drift, unmanaged assets and governance or mostly replicate what you had at different pricing?

We have been into a large scale Terraform migration spanning roughly 40 AWS accounts for 18 months. The most difficult challenge has been identifying and bringing under management all the legacy infrastructure that was never captured in Terraform. For example, last month Cost Explorer flagged an OpenSearch cluster in us-east-1 that had been running for two years with no associated ticket, owner, or Terraform state entry. This is not an isolated case, we discover manually provisioned resources spun up during incidents, forgotten workloads in dormant accounts, and other unmanaged infrastructure. We have experimented with CloudTrail auditing and custom scripts to compare Terraform state against live resources, but the results become very noisy when coverage is incomplete across accounts and services.

Question: What things are people using today for discovery of unmanaged resources during large Terraform migrations across AWS and GCP? Have any of you had good results systematically importing existing resources into Terraform state rather than manually recreating or handling them?

We are mid-SOC 2 Type 2 audit cycle and the infrastructure recovery readiness controls are the ones I am least confident about. We have a disaster recovery policy. We have documented RTOs. What we do not have is verifiable, timestamped evidence that our cloud infrastructure can be rebuilt to meet those RTOs in a real failure scenario, which is what the auditors are now asking for. The specific gap is that our CMDB and our IaC state does not represent our live environment. Resources get provisioned outside IaC. Configurations drift. IAM policies get modified manually. So even if we ran a recovery test today and passed, we have no mechanism to verify that our live infrastructure state stays aligned with what we documented as the recovery baseline. The next audit cycle we would be in the same position. DORA in particular is pushing on operational resilience in a way that a static policy document does not satisfy. Regulators want evidence of recovery testing, audit trails of infrastructure changes, and proof that recovery procedures reflect the actual environment, not a snapshot from six months ago. PCI DSS and ISO 27001 are asking similar questions around infrastructure change control and recovery validation. What are eng and compliance teams using to generate continuous, audit-ready evidence of cloud infrastructure recovery readiness that covers the live state of cloud environments rather than just what IaC says should be there?

I want to know if others solved what we could not. Last November a bad load balancer rule change cascaded into about 40% of prod going down. Reverting the rule took 20 minutes. But getting services healthy again meant redeploying a chunk of our environment from Terraform. Our state had drifted from what was live, so things came back subtly wrong. One example, an S3 lifecycle policy someone had tweaked months earlier got wiped in the reapply. It took 13 days before we trusted the environment again. The root cause of the slow recovery was clear in hindsight. Our IaC was not a right representation of our live infrastructure. It was close, but close is not good when we're rebuilding from it under pressure. We spent half the incident just trying to figure out what our own infrastructure which was supposed to look like before we could even start fixing it. Trying to move fast on the fix resulted in even more chaos and multiple drifts that broke some services. I am not confident we have solved the underlying problem. We do more drift checks now but it's still manual and reactive. What are teams using to keep IaC in sync with live cloud infrastructure so that when they need to restore cloud infrastructure after an outage, they're rebuilding from something that represents reality? We have good process and need something that does the work.