Cloud Backup Architecture: Policies, Vaults and Retention Design
Cloud backup architecture is the design of how cloud workloads are backed up: which policies apply to which resources, where copies are stored, how long each copy is kept and how restores are performed. NTSPL designs tag-driven policies, multi-account vault layouts and retention ladders on AWS, Azure and Google Cloud for teams building or rebuilding their backup estate.
Delivered on
In scope
Why Backup Needs an Architecture, Not Just a Schedule
Cloud makes it easy to take backups and hard to keep them coherent. Each team turns on snapshots for its own resources, retention is copied from whatever the first project used, and copies stay in the same account and region as production. Two years later there are five vaults, three schedules for the same database, no cross-region copy for the systems that need one, and a storage bill that grows faster than the data. The deeper issue is that nothing ties a backup policy to a recovery requirement, so new workloads either get no protection or the most expensive tier by default.
NTSPL designs backup as a small set of named tiers, each with a schedule, retention ladder, copy destination and restore method, and binds those tiers to resources through tags or labels enforced by policy. Vaults are laid out by environment and data sensitivity, with a dedicated backup account or subscription holding the cross-account copies. The design is delivered as infrastructure as code with a restore path documented and tested for each workload class.
When to Redesign Your Cloud Backup Layout
Signals you need Cloud Backup Architecture
- You are landing a new cloud estate or a migration wave of 50+ workloads and need protection to be automatic from day one.
- Backup policies differ per team, with three or more schedules and retentions for the same class of data.
- All recovery points sit in the same account, subscription or project as production, with no cross-region copy.
- A backup assessment has produced a fix list that needs a target design rather than one-off patches.
- You are consolidating on-premises backup software into cloud-native services and need to map old jobs to new policies.
When to choose something else
- You only need to know what is wrong with today's backups. Start with the Backup Assessment; design follows its findings.
- Your priority is ransomware resilience of copies you already have. Immutable & Protected Backup focuses on locks, isolation and approval controls.
- SAP HANA landscapes need Backint, log backup and system replication design. Use the SAP Backup & Recovery page in the SAP on Cloud family.
Components of a Cloud Backup Design
Backup tier catalogue
Three to five named tiers, each defining frequency, retention ladder, copy destinations and consistency method (crash, application or database-native).
Tag and policy binding
A mandatory tag or label carries the tier; organisation policies deny or flag untagged production resources and auto-assign protection.
Vault and account topology
Vault layout by environment and sensitivity, plus a central backup account, subscription or project that receives cross-account copies.
Retention ladders and storage tiers
Daily, weekly, monthly and yearly points with lifecycle to cold or archive storage, sized to legal and business need.
Restore paths
Documented restore procedure per workload class: full VM, disk, file-level, database point-in-time, object version and cross-region restore.
Infrastructure as code
Plans, vaults, policies and IAM delivered in Terraform or Bicep with pipeline checks, so backup changes go through review like any other change.
Tag-Driven Backup Topology with a Central Copy Account
Tag-Driven Backup Topology with Central Copy Account
Workloads carry a backup-tier tag that organisation policy binds to a matching backup plan in each workload account. Recovery points are copied to a central backup account in a second Indian region, where retention and lifecycle are enforced independently of production.
Select any component
Tag-Driven Backup Topology with Central Copy Account: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Backup Building Blocks on AWS, Azure and Google Cloud
Organisation-level backup policies attach backup plans to resources by tag across all member accounts; copies go to a vault in a dedicated backup account, usually in Hyderabad for Mumbai workloads.
Azure Policy assigns backup to VMs by tag, with vaults per subscription and landing zone. Cross Region Restore on geo-redundant vaults gives a restore option in the paired region, such as South India for Central India.
Backup plans are applied by label at project or folder level, with backup vaults in a separate backup project; snapshot schedules cover short-term disk protection.
Design Choices for Tiers, Vaults and Retention
How many tiers to define
Three to five. A common set is gold (hourly or 4-hourly, 35 days local, cross-region copy, monthly for seven years), silver (daily, 30 days, cross-region weekly), bronze (daily, 14 days, local only) and none for disposable environments. More than five tiers creates choice paralysis and inconsistent tagging; fewer than three forces critical and trivial data onto the same schedule.
Where to put the copy vault
Use a separate account, subscription or project dedicated to backup, in a different Indian region from production. For Mumbai production on AWS, copy to Hyderabad; on Azure Central India, to South India; on Google Cloud Mumbai, to Delhi. Keep the backup account's admin group disjoint from production admins, and keep its encryption keys in that account.
Application consistency
Crash-consistent snapshots are acceptable for stateless or file servers. Databases need either application-consistent snapshots (VSS on Windows, pre and post scripts on Linux) or, better, the database's native backup or managed PITR. Do not rely on VM snapshots alone for databases larger than 500 GB or with write rates above a few hundred transactions per second.
Retention ladder sizing
Set retention from three inputs: operational restores (most requests are for data under 14 days old), legal minimums for each data class, and DPDP storage limitation for personal data. Move points older than 30-90 days to cold storage, and archive only data that can tolerate retrieval in hours. Price the ladder in INR per TB before approval.
Building the Backup Platform in Five Steps
Tier catalogue and data-class mapping
Workload owners agree tiers and map each application and data class to one, using RPO and retention requirements from any prior assessment.
Account and vault topology
The central backup account, subscription or project is created, vaults and keys are set up, and cross-account trust is configured.
Policy-as-code build
Backup plans, tag policies and copy rules are written in Terraform or Bicep and deployed through the pipeline to non-production first.
Production rollout by wave
Tags are applied to production in waves of 20-50 resources, protection is verified, and legacy jobs are retired only after two clean cycles.
Restore path validation
Each restore path is executed once, including a cross-region restore from the copy vault, and timings are recorded in the runbook.
What you receive
Measures That Show the Backup Design Is Working
| KPI | Typical target |
|---|---|
| Production resources with a valid backup-tier tag | 99%+ within 30 days of rollout |
| Gold and silver tier points copied cross-region | 100%, copy job success 99%+ |
| Backup schedules per data class | Exactly one |
| Backup storage cost per protected TB | Reduced 20-35% versus pre-design baseline |
| Restore path tests passed at handover | All paths, including cross-region |
Design Pitfalls in Cloud Backup and How to Avoid Them
| Risk | How NTSPL prevents it |
|---|---|
| Retiring legacy jobs before new policies are proven | Legacy schedules run in parallel for two full backup cycles, and are removed only after the new recovery point has been restored once. |
| Copy vault shares admins with production | The backup account has its own identity group and break-glass process; production administrators are explicitly excluded and this is checked in pipeline policy. |
| Cross-region copy costs surprise finance | Inter-region transfer and second-region storage are modelled per tier before rollout; bronze tier stays local by design. |
| Owners tag everything gold | Each tier shows its monthly cost per TB in the tag guidance, and gold requires a named business owner's approval recorded in the workload register. |
Cloud-native backup vs third-party backup software on cloud: which should we use?
Use cloud-native backup (AWS Backup, Azure Backup, Google Backup and DR Service) as the default for cloud workloads. It needs no servers, is billed per protected resource and storage, integrates with organisation policy and supports vault locks. Third-party software such as Veeam or Commvault is worth keeping when you protect a large on-premises estate alongside cloud and want one catalogue, need granular application restores the native tool lacks, or have multi-cloud copies to a single target. Avoid running both on the same resource; double protection is the most common source of wasted backup spend.
Key facts: Cloud Backup Architecture
Cloud Backup Architecture in Practice
2 Cloud Backup Architecture scenarios, from Pharmaceutical quality control (LIMS) and K-12 school chain, plus related platform case studies.
Pharma QC lab puts LIMS and instrument data under one validated backup design
School chain moves 42 campus ERPs onto one label-driven backup policy
Multi-specialty hospital cuts HIS recovery time from 2 days to 38 minutes
3PL operator cuts warehouse system recovery time from 2 days to 45 minutes
Cloud Backup Architecture: Frequently Asked Questions
How much effort does a backup architecture engagement take?
For a landing zone with 10-30 accounts or subscriptions and 200-600 resources, plan six to eight weeks and 35-55 consultant days, including infrastructure-as-code build and restore testing. Ongoing cost is mostly storage; NTSPL provides a per-tier INR model so the run cost is known before rollout.
Should backups stay inside India?
For regulated sectors and most personal data, yes. Both production and copy vaults can stay in-country: AWS Mumbai and Hyderabad, Azure Central India, South India, West India and India South Central, Google Cloud Mumbai and Delhi. RBI's payment data storage direction and CERT-In's log retention rule both point to in-country storage.
Do we still need backups if we use multi-zone databases?
Yes. Zone and region replication protect against infrastructure failure, but they replicate deletions, bad updates and encryption by ransomware within seconds. Backups and point-in-time recovery are the only way to go back to a state before the mistake. A replica cannot bring back last Tuesday's data; a backup can.
How do we protect Kubernetes workloads?
Persistent volumes alone are not enough; you also need cluster resources such as deployments, secrets and config. NTSPL uses Backup for GKE, Azure Backup for AKS, or Velero on EKS and wherever portability matters, with the same tier tags applied to namespaces.
Can the same design cover on-premises servers?
Partly. Azure Backup with the MARS agent or Backup Server, AWS Backup for VMware, and Google Backup and DR Service can protect on-premises systems into cloud vaults. The tier catalogue and retention ladders stay the same; only the agent and network path differ.
Who owns backup after the design is delivered?
The platform team owns the policies and vaults; workload owners own the tag on their resources and approve their tier. NTSPL hands over the code, runbooks and reports, and can operate daily backup through a managed service if you prefer.