Securing Backups Across AWS, Azure, and Google Cloud

Cloud backup security across the three dominant hyperscale platforms — Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) — encompasses encryption standards, identity controls, replication architecture, and regulatory compliance obligations that differ materially by provider. The stakes are significant: a compromised or unrecoverable backup is not merely a technical failure but a regulatory exposure event under frameworks including HIPAA, PCI DSS v4.0, and the FTC Safeguards Rule (16 CFR Part 314). This page maps the service landscape, structural mechanics, classification boundaries, and known tensions in multi-cloud and single-cloud backup security across all three providers.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps
• Reference table or matrix

Definition and scope

Cloud backup security refers to the technical controls, identity and access policies, encryption configurations, and operational procedures that protect backup data stored in or replicated through AWS, Azure, or GCP from unauthorized access, modification, deletion, and unrecoverable loss. The scope is distinct from general cloud security: backup environments introduce specific attack surfaces, including backup agent credentials, snapshot replication pipelines, vault access policies, and restore-path integrity.

The three hyperscale providers each maintain native backup services — AWS Backup, Azure Backup, and Google Cloud Backup and DR — with provider-specific control planes, encryption key management systems, and IAM (Identity and Access Management) architectures. Security professionals operating across all three must reconcile divergent terminology, policy models, and audit log formats.

Regulatory scope is not optional. The HHS Office for Civil Rights has issued guidance on cloud computing under HIPAA (HHS Cloud Computing Guidance), requiring covered entities and business associates to implement technical safeguards for backup data containing protected health information (PHI). The FTC Safeguards Rule (16 CFR Part 314), revised with a compliance date of June 2023, requires covered financial institutions to implement encrypted, access-controlled backup procedures. NIST Special Publication 800-53, Revision 5 (NIST SP 800-53 Rev. 5) provides the foundational control catalog — including control families CP (Contingency Planning) and SC (System and Communications Protection) — most commonly mapped to cloud backup implementations in federal and regulated commercial environments.

The cloud backup providers on this domain reflect providers operating within this regulatory landscape, with coverage spanning all three major hyperscale environments.

Core mechanics or structure

Backup security across AWS, Azure, and GCP operates through four interlocking technical layers:

1. Encryption at rest and in transit. All three providers support AES-256 encryption at rest by default for backup storage. AWS Backup integrates with AWS Key Management Service (KMS), allowing customer-managed keys (CMKs) that restrict decryption to specific IAM principals. Azure Backup supports Azure Key Vault-managed keys with double encryption (platform-managed key plus customer-managed key). Google Cloud Backup and DR integrates with Cloud KMS and supports CMEK (Customer-Managed Encryption Keys) across backup vaults. In transit, TLS 1.2 is the enforced minimum across all three platforms' backup APIs, with TLS 1.3 available on GCP and AWS endpoints.

2. Identity and access management. AWS uses IAM policies, resource-based vault access policies, and AWS Organizations service control policies (SCPs) to govern backup operations. Azure relies on Role-Based Access Control (RBAC) with built-in roles such as Backup Contributor and Backup Operator, enforced at the Recovery Services vault level. GCP uses IAM roles (roles/backupdr.admin, roles/backupdr.viewer) applied at the project or resource level. Each provider supports conditional access — requiring multi-factor authentication (MFA) or specific network origins before backup operations are permitted.

3. Immutability and retention lock. AWS Backup Vault Lock (AWS Backup Vault Lock documentation) implements WORM (Write Once, Read Many) controls compliant with SEC Rule 17a-4(f) for financial records retention. Azure Backup supports immutable vaults with locked policies that prevent early deletion. GCP Backup and DR supports backup plan policies with enforced minimum retention periods. Immutability is the primary technical defense against ransomware-driven backup deletion.

4. Audit logging and monitoring. AWS CloudTrail records all AWS Backup API calls. Azure Monitor and Azure Activity Logs capture vault-level operations. GCP Cloud Audit Logs record all Backup and DR administrative and data-access events. NIST SP 800-92 (NIST SP 800-92) provides the federal baseline for log management applicable to all three environments.

Causal relationships or drivers

Three primary forces drive the hardening of backup security controls across these platforms:

Ransomware targeting backup infrastructure. Ransomware operators have shifted tactics from encrypting primary data to targeting and deleting backup repositories before triggering primary-data encryption — a pattern documented by the Cybersecurity and Infrastructure Security Agency (CISA) in Alert AA23-061A. Compromised cloud credentials provide access to snapshot deletion APIs, making IAM misconfiguration the proximate cause of backup destruction in the majority of documented cloud ransomware incidents.

Regulatory expansion. Mandatory baseline controls have extended to backup infrastructure through multiple regulatory vectors. PCI DSS v4.0, published by the PCI Security Standards Council in March 2022, explicitly requires that backup media containing cardholder data be subject to the same encryption, access control, and audit requirements as production systems. The HIPAA Security Rule's addressable implementation specification for data backup (45 CFR § 164.308(a)(7)) has been interpreted by HHS to require encryption when backup data is stored in cloud environments outside a covered entity's direct physical control.

Multi-cloud adoption increasing attack surface. Organizations operating workloads across AWS, Azure, and GCP simultaneously face IAM fragmentation: credentials and roles from one provider do not extend to another, creating 3 distinct control planes that must be independently hardened, monitored, and audited.

Classification boundaries

Cloud backup security deployments across these three providers fall into four structural categories:

Provider-native backup uses AWS Backup, Azure Backup, or Google Cloud Backup and DR exclusively within a single cloud environment. Security controls are bounded to what the provider's tooling exposes, and the blast radius of a compromised account is limited to that provider's environment.

Cross-cloud backup replicates data from one hyperscale environment to a separate provider — for example, AWS workloads backed up to GCP Cloud Storage. This architecture eliminates single-provider failure as a risk, but introduces inter-cloud data transfer costs and encryption key management complexity across 2 independent IAM systems.

Hybrid cloud backup extends on-premises infrastructure into a cloud backup tier, typically via AWS Storage Gateway, Azure Backup Server, or Google Cloud's Transfer Appliance. Security controls span both the on-premises network segment and the cloud vault, requiring coherent key management and network access controls across the boundary.

Third-party backup orchestration layers independent software vendors (ISVs) — such as Veeam, Commvault, or Druva — across one or more cloud providers. These architectures introduce a fourth identity plane (the ISV's own authentication system) and require verification that the vendor's security posture aligns with the regulatory requirements applicable to the underlying data. The addresses how this site classifies and lists providers operating in these categories.

Tradeoffs and tensions

Key management control vs. operational complexity. Customer-managed encryption keys (CMKs) on all three platforms provide maximum control over data confidentiality — if the key is deleted, the backup is cryptographically unrecoverable. This is a security property and an operational risk simultaneously. Organizations that lose CMKs due to accidental key vault deletion or misconfigured key rotation policies cannot recover their backups regardless of data integrity. AWS KMS, Azure Key Vault, and Google Cloud KMS each provide key deletion protection windows (7–30 days configurable on AWS, configurable on Azure, 24-hour scheduled destruction on GCP by default), but these must be explicitly configured.

Immutability vs. data subject rights. WORM-locked backup vaults prevent deletion for the configured retention period — a direct tension with the CCPA's right to deletion (California Civil Code § 1798.105) and similar provisions in state privacy statutes. Organizations must design retention windows that satisfy security immutability requirements without creating irrecoverable conflicts with legal deletion obligations.

Cross-region replication vs. data residency. Replicating backups across AWS regions, Azure geographies, or GCP zones improves recovery time objectives (RTOs) but may violate data residency requirements under the EU General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679) or sector-specific rules restricting certain health and financial data to domestic infrastructure.

Centralized monitoring vs. provider-specific tooling. A single SIEM platform receiving CloudTrail, Azure Activity Logs, and GCP Cloud Audit Logs provides unified visibility but requires normalization of 3 distinct log schemas. Provider-native monitoring tools offer deeper integration but fragment the security operations workflow.

Common misconceptions

Misconception: Provider encryption defaults are sufficient for regulatory compliance.
All three providers encrypt backup data at rest by default using platform-managed keys. However, platform-managed keys mean the provider — not the customer — controls decryption. Under HIPAA's technical safeguard requirements and PCI DSS v4.0 Requirement 3.5, organizations are expected to implement controls that restrict access to encryption keys to authorized personnel. Default provider encryption does not satisfy this requirement for regulated data without supplemental key management configuration.

Misconception: Enabling backup is equivalent to securing backup.
Activating AWS Backup, Azure Backup, or Google Cloud Backup and DR without configuring vault access policies, immutability, and CMKs creates backup repositories that are both accessible to any compromised credential in the account and deletable by those same credentials. CISA's cloud security guidance (CISA Cloud Security Best Practices) identifies misconfigured backup permissions as a persistent top-tier risk.

Misconception: Cross-cloud backup eliminates ransomware risk.
Replicating from AWS to GCP provides redundancy against provider-level failures, but if the replication is controlled by a credential set that spans both environments, a compromised credential can delete backup data in both locations. Air-gapped replication — where destination credentials are not accessible from the source environment — is the required architecture for ransomware-resistant cross-cloud backup.

Misconception: MFA on the root or primary account is sufficient.
Backup APIs are typically invoked by service accounts and automation roles that do not use interactive MFA. Requiring MFA only on human logins leaves the service account surface — which is the attack path most commonly exploited in cloud backup deletion incidents — unprotected. AWS supports MFA Delete for S3-based backup targets; equivalent controls must be explicitly configured for vault-level operations.

Checklist or steps

The following is a structured control verification sequence for cloud backup security across AWS, Azure, and GCP, organized by layer. This sequence reflects the control requirements described in NIST SP 800-53 Rev. 5 (CP-9, SC-28, AC-3, AU-2) and applicable provider documentation.

Encryption and key management
- Verify that backup vaults on all 3 providers are configured with customer-managed keys (CMKs), not platform-managed defaults, for regulated data categories
- Confirm CMK key rotation is enabled (AWS KMS: annual automatic rotation available; Azure Key Vault: configurable rotation policy; GCP Cloud KMS: rotation period set per key)
- Confirm key deletion protection windows are set to the maximum configurable period on each provider
- Verify TLS enforcement on all backup API endpoints and agent communications

Identity and access control
- Audit IAM roles and policies scoped to backup operations — remove any wildcard (*) actions on vault or snapshot resources
- Verify that service accounts used for backup automation hold least-privilege roles (no administrative permissions beyond required backup read/write operations)
- Confirm that backup vault deletion and policy modification require elevated authorization separate from standard backup operation roles
- Review cross-account and cross-project access grants; remove stale or undocumented trust relationships

Immutability and retention
- Enable AWS Backup Vault Lock, Azure immutable vault policies, or GCP backup plan minimum retention enforcement on all vaults holding regulated data
- Verify that retention lock policies are in compliance mode (not governance mode) where deletion prevention is required by regulation
- Document retention periods against applicable regulatory minimums (HIPAA: minimum 6 years for certain records under 45 CFR § 164.316(b)(2); PCI DSS v4.0: 12-month minimum audit log retention)

Monitoring and audit
- Confirm CloudTrail (AWS), Azure Monitor (Azure), and Cloud Audit Logs (GCP) are capturing backup API events and shipping to a SIEM or centralized log store outside the production backup account
- Set alerts for backup job failures, vault policy modifications, CMK access anomalies, and backup deletion events
- Review audit logs quarterly for unauthorized access attempts or policy drift

The how-to-use-this-cloud-backup-resource page describes how the providers on this domain are organized by provider and control category.

Reference table or matrix

Provider Feature Comparison: Core Backup Security Controls

Sources: AWS Backup documentation, Azure Backup documentation, Google Cloud Backup and DR documentation