Cloud Backup Best Practices for AWS, Azure, and GCP

One of the most expensive assumptions in cloud computing is that the provider backs up your data. They do not — at least not in the way most people imagine. AWS, Azure, and Google Cloud guarantee the durability and availability of their infrastructure, but protecting your data against accidental deletion, ransomware, misconfiguration, a malicious insider, or a corrupted deployment is your responsibility. A resilient backup strategy is what stands between a bad day and an unrecoverable one. This guide covers the practices that apply across every cloud, then maps them to the native tooling in each of the big three.

The shared responsibility myth

Every major cloud operates a shared responsibility model: the provider secures the cloud, you secure what you put in it. High storage durability (the famous "eleven nines" for object storage) protects against hardware failure — it does not protect against you, or an attacker with your credentials, deleting or encrypting the data. The same applies to SaaS: Microsoft 365 and Google Workspace replicate your data for availability but do not provide the point-in-time recovery most organisations assume, which is why third-party SaaS backup is a category of its own. Treat backup as your job, not the platform's.

The modern 3-2-1-1-0 rule

The classic 3-2-1 rule still holds, extended for the ransomware era:

• 3 copies of your data (production plus two backups).
• 2 different storage types or media.
• 1 copy off-site — in cloud terms, a different region and ideally a different account.
• 1 copy immutable or air-gapped (cannot be altered or deleted during retention).
• 0 errors — every backup is verified and every restore is tested.

Universal best practices

These apply whether you run on AWS, Azure, GCP, or all three.

Make backups immutable

Use write-once-read-many (WORM) immutability so backups cannot be modified or deleted within their retention period — even by an administrator or the root/owner account. This is the single most important defence against ransomware, which increasingly targets the backups themselves before encrypting production.

Encrypt everything and control the keys

Encrypt backups at rest and in transit. Manage keys in a dedicated key-management service (AWS KMS, Azure Key Vault, Google Cloud KMS), and consider customer-managed keys so you control the lifecycle. Guard the keys as carefully as the data — losing them is as bad as losing the backup.

Isolate backups from production

Store backups in a separate, locked-down account/subscription/project with its own access controls, so a compromise of the production environment cannot reach them. Apply least privilege to backup operations and require strong, separated permissions to delete or alter retention. This account isolation is the cloud equivalent of an air gap.

Copy across regions

Keep at least one copy in a different region to survive a regional outage or a localised disaster. Cross-region copies also support geographic compliance and faster recovery in a DR scenario.

Define RPO and RTO, then design to them

Your Recovery Point Objective (how much data you can afford to lose) and Recovery Time Objective (how quickly you must be back) drive backup frequency and method. A database needing near-zero data loss wants continuous/point-in-time recovery; an archive may be fine with weekly snapshots. Match cost to criticality rather than treating everything the same.

Automate with policy

Never rely on manual backups. Use policy- or schedule-driven backups (backup plans, vault policies, snapshot schedules) with tag-based selection so new resources are protected automatically. Manual processes are the ones that get forgotten.

Tier storage to manage cost

Apply lifecycle rules to move older backups to colder, cheaper tiers (S3 Glacier, Azure Archive, Google Cloud Archive/Coldline) and to expire them at end of retention. Backups are a recurring cost; lifecycle management keeps it proportionate.

Test restores — regularly

A backup you have never restored is a hope, not a plan. Schedule restore drills, validate data integrity, and measure actual recovery time against your RTO. Testing is where the "0 errors" in 3-2-1-1-0 is earned.

Monitor, alert, and document

Alert on failed or missed backups, monitor for unexpected deletions, and keep a runbook so anyone on call can execute a recovery under pressure. Silent backup failure is common and only discovered when you need the backup.

Back up configuration, not just data

Protect your infrastructure-as-code, deployment state, secrets, and identity/configuration — not only the application data. Being able to rebuild the environment is part of recovery.

Native backup tooling by provider

Each cloud has a central backup service plus immutability and cross-region features that implement the practices above.

AWS notes

AWS Backup centralises policy-driven backup across services. Backup Vault Lock provides WORM protection — Compliance mode cannot be altered or deleted by anyone, including AWS or the root account, until retention expires, while Governance mode allows change only by users with explicit privileges. Combine it with logically air-gapped vaults, cross-account/cross-Region copies, and S3 Object Lock for object storage.

Azure notes

Azure Backup uses Recovery Services and Backup vaults. Enable immutable vaults (WORM), soft delete to recover from accidental or malicious deletion, and Multi-User Authorization so destructive operations need a second approver. Use geo-redundant storage with cross-region restore, and Azure Site Recovery for full DR orchestration.

Google Cloud notes

Google Cloud Backup and DR Service centralises protection for Compute Engine, databases, and more, with backup vaults that keep recovery points immutable and indelible for their retention. Use Persistent Disk snapshot schedules, Cloud Storage with Bucket Lock retention policies for WORM object storage, and multi-region buckets for geographic resilience.

Designing for ransomware resilience

Assume an attacker who reaches your environment will try to destroy the backups first. The defensible pattern combines four things: immutability (WORM so backups cannot be deleted in retention), isolation (a separate, least-privilege backup account), air-gap-equivalent separation (logically air-gapped or cross-account vaults), and tested restores (so recovery actually works under pressure). The same Zero Trust principles apply to who can touch backups — verify explicitly and grant least privilege. See our Zero Trust Architecture guide for the access model.

Do not forget SaaS and databases

Cloud backup is not only about IaaS. Microsoft 365 and Google Workspace hold critical data that the platform does not back up for point-in-time recovery — assess whether you need dedicated SaaS backup. For databases, prefer native point-in-time recovery (transaction-log/continuous backup) for low RPO. To baseline your Microsoft 365 and identity posture before planning protection, our free x365 audit tool surfaces configuration and exposure without sending tenant data off your device.

Frequently asked questions

Do cloud providers back up my data automatically?

No. Under the shared responsibility model, AWS, Azure, and Google Cloud guarantee the durability and availability of their infrastructure, but protecting your data from accidental deletion, ransomware, misconfiguration, or a malicious insider is your responsibility. High storage durability protects against hardware failure, not against data being deleted or encrypted. The same applies to SaaS such as Microsoft 365 and Google Workspace, which is why dedicated backup is often needed.

What is the 3-2-1-1-0 backup rule?

It is the classic 3-2-1 rule extended for the ransomware era: keep 3 copies of data, on 2 different storage types, with 1 copy off-site (a different region/account), 1 copy immutable or air-gapped, and 0 errors — meaning every backup is verified and every restore is tested.

What are the native backup tools for AWS, Azure, and GCP?

AWS uses AWS Backup with Backup Vault Lock for WORM immutability and S3 Object Lock. Azure uses Azure Backup with Recovery Services and Backup vaults, offering immutable vaults, soft delete, and Multi-User Authorization. Google Cloud uses the Backup and DR Service with immutable backup vaults, plus Persistent Disk snapshots and Cloud Storage Bucket Lock retention for WORM object storage.

How do immutable backups protect against ransomware?

Immutable (WORM) backups cannot be modified or deleted during their retention period, even by an administrator or root/owner account. Because modern ransomware targets and deletes backups before encrypting production, immutability ensures a clean recovery point survives the attack. It is most effective combined with isolation in a separate account and regularly tested restores.

How often should I back up cloud workloads?

Backup frequency follows your Recovery Point Objective — how much data you can afford to lose. Critical databases needing near-zero loss should use continuous or point-in-time recovery; less critical systems may be fine with daily or weekly snapshots. Match backup frequency and retention to the criticality of each workload rather than applying one schedule to everything.

Why do I need to test backup restores?

A backup is only useful if it can be restored. Untested backups can be silently corrupt, incomplete, or take far longer to recover than your Recovery Time Objective allows. Scheduling regular restore drills validates data integrity and confirms your actual recovery time, turning a backup from an assumption into a proven recovery capability.