How Cohesity Data Cloud uses your Terraform Self-Managed state to rebuild cloud apps after an attack

If a disruption hits your cloud estate—say a destructive cyberattack, rogue agent action, or even a military strike—rebuilding your applications, correctly and fast, is what counts. At Cohesity, we believe you should rebuild from the infrastructure-as-code (IaC) you already trust. That’s how you make recovery predictable.

If your team runs Terraform Self-Managed, your cloud infrastructure provisioning is already disciplined. Every VPC, subnet, security group, IAM role, and workload is defined in code, reviewed in a pull request, and versioned in a repo. You know exactly what your environment is supposed to look like.

Recovering your cloud environments after a disruptive event, unlike provisioning, is much tougher to wrangle. When an attack takes an application down, infrastructure teams usually reconstruct the environment by hand. Or you use a tool that reverse-engineers IaC from your live environment. But you're recovering from a drifted, possibly already-compromised state and trusting the tool to have captured every resource and dependency. Both options are error-prone and take far too long.

At Cohesity, we saw an opportunity to accelerate the rebuild of your cloud apps by using Terraform Self-Managed. You already trust this tool to provision your cloud environment. Shouldn’t you use it to rebuild your apps, during the one event where you need it most?

You already provision as code. Now you can recover as code.

Cohesity Data Cloud added cloud rebuild earlier this year to close that gap. HashiCorp has validated it for use alongside Terraform Self-Managed. It recovers cloud applications from your own Terraform—the same IaC you provision with.

Why teams that use Terraform Self-Managed will love cloud rebuild

HashiCorp reviewed how cloud rebuild uses Terraform. The design shines in two places that matter.

First, IaC is treated as the single source of truth. The workload objects associated with application are discovered using IaC code and state, foundational concepts of the Terraform workflow. This enables automation discovery of the application's workload objects (for the purpose of protection) after its deployed using IaC.

Second, how recovery reconciles state. Cloud rebuild applies your original Terraform unchanged and reconciles state per the workload objects recovered by Cohesity Data Cloud.

How it works

Here is what happens from protection through recovery.

Discovery builds a manifest: First, cloud rebuild runs discovery from an Automation Host, a system you manage with access to your IaC source. You point it at your IaC repo and clone the repository to a working directory on that host. Because the host is yours, your Git credentials stay with you: they're never collected over the network or stored by the service. You then define the application by giving cloud rebuild the path to the relevant Terraform file or modules. Cloud rebuild processes the Terraform files and discovers the resources the application is built from. For the stateful resources—the ones that hold data—it checks whether each is already covered by a backup policy in Cohesity Data Cloud and flags any that aren't so you can bring them under protection.

Cloud rebuild also captures the processed IaC as a timestamped manifest. That manifest becomes your recovery point: the exact infrastructure definition at a known moment, ready to rebuild from. You choose how often it's captured, so your recovery points stay as current as your application.

The manifest is a single JSON document, the application manifest. It is the source of truth the recovery workflow uses to put the application back together.

Protect and version: Next, cloud rebuild backs up your Terraform configuration and state as point-in-time versions over time, alongside the workloads those files define. During recovery, you pick the version you want to rebuild from.

Recovery by Blueprint

This is where it comes together. You don't recover only data or only Infrastructure—you recover the entire application.

To set up recovery, you create a Blueprint within Cohesity Data Cloud and select the application as its configuration. Running the Blueprint recovers the whole application in one motion, and it recovers it in order: the same sequence your Terraform modules used to define the app is the sequence cloud rebuild follows to bring it back. Infrastructure comes up in the right dependency order, and data lands on it as it does.

Before anything is restored, there's a review step. You select the manifest recovery point—the infrastructure definition recovery point you want to return to—and the clean workload recovery points for the application's data. Nothing recovers until you've confirmed the points you're recovering from, so you're always rebuilding to a known-good state, not a guess.

And because recovery follows your own module structure, your original Terraform runs unchanged. The application comes back the way you defined it—in the order you defined it.

One recovery point based on telemetry

One final highlight. Infrastructure and workload data are backed up on separate schedules. During recovery, cloud rebuild intelligently reconciles these snapshots together into a single, clean recovery point for the application. Users can also customize and choose different recovery points based on their investigation of the disruption.

Recover with your code, not a generated copy of it

There are competing approaches to rebuilding your cloud applications after a cyberattack. Our approach is unique because of the source of truth we rebuild from.

Cohesity Data Cloud rebuilds from your Terraform—the modules your team already reviewed, approved, and versioned. Other tools rebuild from a model they generate themselves.

For a platform team, the difference becomes clear on the day you must recover quickly. When the rebuild runs on your own code, change control stays intact—recovery is not a side door around the review process you enforce everywhere else. You rebuild to the known-good state your code defines, not to a live snapshot of production that may already carry drift, a misconfiguration, or the attacker's changes from the hours before capture. And there is no vendor-generated recovery model to reverse-engineer and take on faith while the business is down.

Take the next step

With cloud rebuild in Cohesity Data Cloud, you can:

• Recover cloud applications from your own validated Terraform, full-stack, and point-in-time.
• Keep recovery inside change control, rebuilding to a known-good state instead of a possibly-compromised snapshot.
• Validate and scan in an isolated clean room before you cut over to production.
• Rely on a method HashiCorp has validated for Terraform Self-Managed.

Ready to see it? Request a free trial and run a rebuild against your own Terraform or read the product documentation (customers only).