Cloud Backup with IaC: Resiliency over Restore Risk
Cloud backups built with a single click fail in emergency situations due to the missing restore path.
A backup no one can restore is not a backup. That is exactly what happens to many DACH organisations that have assembled their cloud backup over the years through portal clicks: when disaster strikes, the documented recovery path is missing and recovery time explodes. Infrastructure-as-Code and FinOps discipline turn this around. They make backup and disaster recovery repeatable, auditable, and defensible when it counts.
Key Takeaways
- Backup is a resilience question, not a storage question: What matters is not whether data is being copied, but whether it can be restored within the agreed recovery time (RTO) and with acceptable data loss (RPO).
- IaC makes recovery repeatable: Backup policies, vaults, and restore paths described as Terraform or Bicep code can be versioned, tested, and rebuilt in a second region within minutes. Manual portal clicks cannot.
- FinOps separates protection from waste: Clean storage tiers, lifecycle rules, and deleted zombie snapshots noticeably reduce backup costs without compromising protection. Optimising here frees up budget for genuine resilience.
Related:Cloud Repatriation: When Bringing Workloads Back Makes Financial Sense / Kubernetes as the AI Default OS: Clusters as a Compliance Question
What Is Infrastructure-as-Code in the Backup Context?
What is Infrastructure-as-Code (IaC)? IaC describes infrastructure as versioned code rather than click-based configuration. Backup vaults, retention rules, encryption, replication targets, and the recovery environment are defined in files such as Terraform HCL, AWS CloudFormation, or Azure Bicep. A toolchain then builds those resources reproducibly from those files. What previously lived as tribal knowledge in individual admins’ heads becomes auditable code.
For backup and disaster recovery, this distinction is existential. A backup job set up manually in the traditional way does not document itself. If the responsible colleague is unavailable, or an entire region goes down, the blueprint is gone. With IaC, the blueprint lives in the Git repository. A second region or a fresh account can be spun up from it in minutes, complete with identical policies and identical encryption settings.
The major hyperscalers provide the building blocks. In AWS, the Backup service bundles vaults, plans, and cross-region copies that are defined as Terraform resources. Azure covers the same ground via Recovery Services Vaults and Backup Vaults, expressible in Bicep. Google Cloud works with the Backup and DR Service plus snapshot schedules. The common thread: the core backup resources and policies of these platforms can largely be described as code, including the restore configuration.
The 3-2-1 rule still holds – just read differently
The old backup rule of thumb remains the benchmark: three copies of the data, on two different media types, one of them offsite. In the cloud, this means separate storage classes, separate regions, and ideally a second provider or immutable storage outside the production account. Tape and hard drives are now little more than a historical illustration of the underlying principle.
The most important modern addition is immutability. Object Lock in AWS S3, immutable vaults in Azure, and retention locks in Google Cloud Storage prevent a compromised account or a ransomware attack from deleting the backups themselves. This is no longer a convenience feature. It is the basic prerequisite for a backup to exist at all after an attack. Anyone serious about backup writes this lock directly into the IaC code so it cannot be accidentally disabled.
| Protection Layer | AWS | Azure | Google Cloud |
|---|---|---|---|
| Central Backup Service | AWS Backup | Azure Backup / Recovery Services Vault | Backup and DR Service |
| Immutable Storage | Backup Vault Lock / S3 Object Lock | Immutable Vault | Bucket Lock |
| Cross-Region Copy | Cross-Region Copy | Geo-redundant Vault | Cross-Region Backup |
| IaC Definition | Terraform / CloudFormation | Bicep / Terraform | Terraform / Config Connector |
Source: Vendor documentation from AWS, Microsoft Azure, and Google Cloud, as of June 2026.
Restore tests are the real insurance policy
Backups usually run reliably. The risk sits on the other side: recovery. Many of the unpleasant surprises emerge during restoration, because the restore path has never been rehearsed under realistic conditions. Wrong sequencing of dependent services, missing network configuration in the failover region, expired keys in the key management system – none of this surfaces until you actually practice it.
This is where IaC pays double dividends. Because the entire target environment exists as code, a full recovery test can be run automatically in an isolated account without touching production. Such a test run produces two hard metrics: the actual measured recovery time and the real data loss up to the last consistent state. These figures belong in the service-level agreement – not the wishful numbers from the concept paper.
In practice, that means building recovery drills into the pipeline. Monthly or quarterly, restore the most critical systems from backup into a sandbox, measure the time, and log deviations into the backlog. Disaster recovery thus shifts from a one-time assumption to a continuously measured property of the system.
Where FinOps Funds Resilience
Backup costs have an uncomfortable habit of growing quietly. Snapshots nobody needs anymore sit for years in expensive hot-tier storage. Retention periods are set generously because, when in doubt, no one wants to reduce them. Cross-region copies run for non-critical data that never needed them in the first place. FinOps brings these expenses under control without weakening protection.
What Burns Budget
- Orphaned snapshots with no owner and no lifecycle rule
- All data in hot-tier storage, including rarely accessed long-term archives
- Blanket long retention for non-critical systems
What Carries Resilience
- Storage tiering based on recovery urgency
- Retention tied to RTO and compliance requirements, not gut instinct
- Immutable copies for the data sets that genuinely matter
The decisive lever is linking both disciplines. When retention periods and storage classes live in the same IaC code as the backup policy, every cost decision simultaneously becomes a documented resilience decision. Shorter retention for non-critical log data then becomes a transparent trade-off against a defined protection requirement rather than a blind cost-cutting move. That is how FinOps funds resilience where it counts, instead of applying blanket cuts across the board.
Tagging is the prerequisite. Only once every backup record carries owner, criticality, and retention class as metadata can costs be allocated to their source and zombie data be identified at all. That tagging belongs in IaC code as well, so it does not get lost the next time someone intervenes manually.
A Pragmatic Starting Point for DACH Teams
Getting there does not require a grand initiative. A sensible first step is to secure the most critical data first. In practice: rebuild the existing backup configuration of the most important production systems as IaC, check it into Git, and from that point on change it only through code. This delivers documentation, versioning, and reproducibility in a single move.
The second step adds immutable storage for exactly those systems, followed by a first automated restore test in a sandbox account. Only then does it make sense to look at costs: lifecycle rules for old snapshots, tiering for rarely accessed data, tagging as a mandatory field. In that sequence, resilience comes first and optimization follows without undermining protection.
For regulated industries across the DACH region, proof of compliance is an additional requirement. Versioned IaC code combined with documented restore tests delivers precisely the evidence auditors and regulators want to see: who protected what, when, and that recovery demonstrably works. That proof is often the strongest argument for tackling the effort in the first place.
Frequently Asked Questions
Does cloud backup replace a dedicated disaster recovery strategy?
No. Cloud backup secures data; disaster recovery describes the full restart of services, networks, and dependencies. A backup is one building block of a DR strategy, not a substitute for it. Only tested restore paths turn backups into reliable recovery.
What does the 3-2-1 rule mean in practice for the cloud?
Three copies of your data, on two separate storage types, with one stored offsite. In the cloud, that translates to separate storage classes, separate regions, and ideally an immutable copy outside the production account that can withstand a ransomware deletion attempt.
Why does Infrastructure-as-Code pay off specifically for backups?
Because the recovery path becomes documented, versioned, and reproducible. From versioned code, a second region or a fresh account can be rebuilt identically within minutes. Manually configured backups don’t document themselves – and in a real emergency, a missing blueprint is often what causes them to fail.
How often should restore tests run?
For your most critical systems, a monthly or quarterly automated restore into a sandbox environment is recommended, with recovery time measured. Only a real test run shows whether the promised RTO and RPO figures hold up. Untested restore paths are among the most common causes of prolonged outages.
Does FinOps optimization reduce backup protection?
Not when it’s tied to criticality. FinOps removes orphaned snapshots, moves rarely accessed data to cheaper tiers, and aligns retention periods with defined protection requirements. The critical, immutable copies remain untouched. The result: freed-up budget that flows into genuine resilience.
Cover image source: Pexels / Jakub Zerdzicki (px:19825057)
Image source: AI-generated (Juli 2026)
