Cloud Resilience Compare

Lesson 4 of 9 · DURING RECOVERY · 3 min read

Failover or rebuild: two ways cloud infrastructure comes back

Short answer

Cloud infrastructure comes back in one of two ways: you fail over to a copy that was replicated in advance, or you rebuild the environment from a captured snapshot or from code. Failover is usually faster on the day and costs more in between; rebuild is cheaper to hold and needs a reliable capture of everything. Arpio is built around replication and failover; Firefly around snapshots rebuilt as Terraform.

By The Rebuild Desk · Cloud Resilience Compare · Re-checked October 2026

What is failover?

Failover means switching service to a copy that already exists in another location. The copy is kept current by replication. In the AWS whitepaper's terms, pilot light, warm standby and multi-site active/active are all failover strategies: they differ in how much of the copy is running before the incident.

Arpio describes continuous replication of infrastructure and data, with cross-region and cross-account failover on AWS and cross-subscription orchestration on Azure. It publishes RPO targets by tier: as low as 15 minutes in Standard and real-time in Premium.

What is a rebuild?

A rebuild creates the environment again from a record of it: a snapshot of configuration, a set of templates, or both. Backup and restore is the simplest form in the AWS whitepaper.

Firefly describes snapshots of configuration, dependencies, networking and identity, and a restore that generates Terraform code rather than making direct changes. It states an RTO under 1 hour. Its docs note that restoration depends on Terraform provider support, which is the main constraint of the approach.

How do they compare?

  • Speed on the day: failover to a running copy is usually faster than creating resources from scratch. Vendor figures are the only numbers available here and they measure different things: Arpio's are RPOs, Firefly's is an RTO.
  • Cost in between: a replicated copy costs money while it waits; a snapshot mostly costs storage. Arpio notes that it charges no storage fees but cloud provider costs apply.
  • What comes back: a rebuild can return the environment to an earlier point, which matters after a bad change. A replica follows production closely, so it can copy a bad change across before anyone notices.
  • What you keep afterwards: a rebuild that produces Terraform leaves code your team can review. Arpio does not publish infrastructure-as-code output.

Can you use both?

Yes, and many teams do: replication for the few applications that cannot wait, snapshots and rebuild for the rest. Our pairing page sets the two side by side.

Which one fits which incident?

The three incidents in our lead question do not favour the same approach. For an outage, a replicated copy is the quickest way back. For a bad change, a replica may already contain the change, so a rebuild from an earlier snapshot is often the safer route. For a region or account loss, both work if the copy or the snapshot lives outside the failed region or account.

What should you take from this lesson?

Decide per application whether it needs a running copy or a reliable rebuild. The answer usually follows from its recovery time objective and how often it changes.

Sources