Day 2 - Backup: AWS Backup & Cross-Region Copy — Legal Origins of WORM, Vault Lock Irreversibility, Multi-Account Backup Governance

In the 1990s, a major Wall Street brokerage came under SEC investigation for allegedly deleting customer emails. This incident created SEC Rule 17a-4(f), mandating "WORM (Write Once Read Many)" storage—once recorded, no one can erase or modify. What once required optical disks or special tape, AWS implemented via Backup Vault Lock's Compliance mode—activate it and even AWS's root user cannot delete backups.

In SAP-C02, backup isn't just "turn on snapshots." Pro perspective is a governance problem: enforce backup policies centrally across dozens or hundreds of accounts scattered in different places, proving the irreversibility and isolation regulators demand. Today we decompose WORM's legal roots, Vault Lock's two modes' irreversibility difference, and multi-account backup governance via AWS Organizations to tool level.

AWS Backup — Consolidate Scattered Backups Into One Policy

Before AWS Backup, each service had its backup method. EBS used DLM (Data Lifecycle Manager) snapshots, RDS used automatic backup settings, DynamoDB used separate on-demand backups—each managed independently. As accounts grew to dozens, "which resources are backed up?" became unknowable. AWS Backup unifies this fragmentation with a central policy engine.

Service coverage is broad—EBS, EC2 (AMI), RDS, Aurora, DynamoDB, EFS, FSx, S3, DocumentDB, Neptune, Storage Gateway, Redshift, Timestream, SAP HANA on EC2. Tag-based resource selection auto-includes "all resources tagged Environment=prod" in one Plan; new resources auto-backup if tagged right.

💡 Related Theory: AWS Backup design follows declarative policy paradigm. Not imperative "backup this resource" but declaring desired state: "all resources with this tag should backup daily, retain 35 days, and replicate to another region"—the system maintains that state. Same philosophy as Kubernetes desired-state reconciliation or Terraform's declarative IaC. Strength: new resources auto-enroll in policy—imperative backup requires manual enabling per new resource, but tag-based declarative policy structurally prevents omission. In exams, "new resources auto-included in backup policy" signals tag-based selection.

🔍 Deeper Dive: AWS Backup and service-native backups coexist. RDS offers native automatic backup (up to 35 days) and PITR without AWS Backup; EBS can manage snapshots via DLM alone. When use AWS Backup? When needing cross-service central policy, multi-account governance, Vault Lock WORM, Cross-Account Copy. Single service/account suffices with native backup, but "enforce consistent policy across entire Organization and prove compliance" needs AWS Backup. Exams frequently test this boundary—"dozens of accounts' EBS, RDS, DDB unified policy" signals AWS Backup.

Vault Lock — Two Levels of Irreversibility

Even existing backups won't protect if someone (malicious insider, ransomware, accident) can delete them. Vault Lock locks backups in a Vault with policy, preventing deletion and modification. The difference between two modes is exam-critical.

Key is Compliance mode's irreversibility. Compliance Lock has changeable-for-days grace period; during it, settings can adjust/cancel, but once grace expires and lock confirms, absolutely no one—not AWS headquarters root, not support—can delete backups or reduce retention. This immutability itself becomes regulatory compliance evidence.

💡 Related Theory: Vault Lock Compliance's "even root can't change" design applies immutability and separation of privilege principles from security engineering to extremes. Normally root can do anything, but WORM requires blocking even root—else stolen root accounts or insider misuse could vaporize backups. This is core ransomware defense: even if ransomware steals admin powers, Compliance-locked backups remain untouchable—recovery without paying ransom becomes possible. Identical philosophy applies to S3 Object Lock Compliance mode.

📚 Case Study: The 2021 Colonial Pipeline ransomware incident—America's largest pipeline operator eventually paid ~$4.4M ransom in Bitcoin (part FBI recovered). Had all backups been isolated on immutable, unchangeable storage, recovery without ransom was possible. Post-incident, immutable backup (WORM) elevated from "nice to have" to "ransomware-era essential." AWS Backup Vault Lock Compliance + Cross-Account Copy combination is this scenario's answer architecture—backup stored in separate account (unreachable if workload account breached) immutably. In exams, "ransomware defense, even insiders can't delete" signals Compliance Lock + Cross-Account.

⚠️ Pitfall: Don't lump Governance and Compliance as "both prevent deletion." Governance mode lets admins with proper IAM permissions override locks and delete—prevents accidental deletion but not malicious admin or stolen credentials. True regulatory WORM (nobody can change) is Compliance mode only. In exams, "regulatory compliance, root can't change, 7-year retention" is Compliance; "accident prevention, admin can exceptionally release" is Governance—clear distinction.

Cross-Region & Cross-Account Copy — Isolation Is Core

If backups live in same region or account, region-wide failure or account breach means backup disappears too. AWS Backup's Copy Action in Backup Plan auto-replicates Recovery Points to other regions or accounts' Vaults.

• Cross-Region Copy: Guard against region-wide failure. Need KMS key permissions on both sides.
• Cross-Account Copy: Store in dedicated backup account separate from workload. Workload account breach leaves backup safe.

🔍 Deeper Dive: Most common Cross-Account Copy failure point: KMS key permissions. Backups encrypt with Vault's KMS key; target account's Vault's KMS key policy must explicitly grant source account permissions to decrypt and copy. Target Vault's access policy (resource-based) must also allow source account's copy. Miss any link in this permission chain and copy silently fails. In exams, "Copy fails" scenario's answer almost always is "add permissions to KMS key policy or Vault access policy." Not simple IAM user permissions but resource-based policies (KMS key policy, Vault policy)—key pitfall.

Multi-Account Governance — Organizations Backup Policy

Forcing dozens/hundreds of accounts to follow identical backup standards via manual per-account setup is impossible. AWS Organizations Backup Policy solves this. Management account (or delegated admin) defines Backup Policy, attaches to OU (Organizational Unit)—all accounts below inherit that backup policy.

[Management Account / Delegated Admin]
        │ Define and attach Backup Policy
        ▼
   [Root → OU: Production]
        ├── [App Account 1] EBS, RDS, DDB ──┐
        ├── [App Account 2] EBS, RDS, DDB ──┤ Each account auto-inherits Plan
        └── [App Account N] ...             │
                                            ▼ Cross-Account Copy
                          [Backup Account (isolated)]
                                            │ Cross-Region Copy
                                            ▼
                          [DR Region Vault + Compliance Lock]

💡 Related Theory: Organizations Backup Policy sits on same policy inheritance mechanism as SCP (Service Control Policy). Where SCP pushes "what you cannot do (permission boundary)" down OU hierarchy, Backup Policy pushes "what you must backup (operational standard)" same way. Both inherit/combine from parent OU—following centralized control + distributed execution pattern for multi-account governance. With Control Tower Landing Zone, auto-deploy this backup policy as guardrail. In exams, "enforce backup standard across hundreds of accounts at once" signals Organizations Backup Policy.

🔍 Deeper Dive: Backup Audit Manager validates whether backups actually execute per policy. Define controls (rules) like "all prod resources: daily backup + 35-day retention + Cross-Region copy," then Audit Manager audits actual backup status against these controls, auto-identifying non-compliant resources (missing backup, insufficient retention, missing copy) and generating reports. Violations integrate into Security Hub for central alerting. Complete closed loop: "policy define (Backup Policy) → execute (Backup Plan) → validate (Audit Manager) → alert (Security Hub)." In exams, "auto-evaluate backups per policy, identify non-compliance" is Backup Audit Manager direct answer.

Service-Specific Backup/Recovery Option Differences

Same "backup" differs by service in PITR support and retention limits. Exams often ask these numbers directly.

⚠️ Pitfall: S3 backup/protection differs from other services. S3 has native mechanisms first: Versioning (version management), CRR (Cross-Region Replication), Object Lock (WORM)—AWS Backup S3 support added recently. "S3 objects in WORM" is S3 Object Lock Compliance mode, not AWS Backup. "Async replicate S3 data to another region" is CRR, not AWS Backup. In exams, when S3 appears, recall S3 native features (Versioning, CRR, Object Lock) first, then AWS Backup.

Summary

AWS Backup consolidates service/account-fragmented backups into tag-based declarative policy central governance engine. Vault Lock offers two irreversibility levels; Governance allows release by authorized admin, but Compliance: root cannot change—true WORM (SEC 17a-4, FINRA, HIPAA compliance). Cross-Region/Account Copy isolates backups against region failure, ransomware, account breach. Organizations Backup Policy enforces standards across hundreds of accounts; Backup Audit Manager validates compliance.

SAP exam frequent mappings: (1) "Unified backup policy across services, accounts" → AWS Backup, (2) "root can't change, regulatory 7-year retention" → Vault Lock Compliance, (3) "accident prevention, admin can release" → Vault Lock Governance, (4) "ransomware, account breach backup isolation" → Cross-Account Copy + Compliance Lock, (5) "force backup standard across hundreds of accounts" → Organizations Backup Policy, (6) "auto-evaluate backup policy compliance, identify non-compliance" → Backup Audit Manager, (7) "S3 object WORM" → S3 Object Lock, (8) "Cross-Account Copy fails" → KMS key policy, Vault access policy permissions. Next day digs beyond backup/restore into actively validating resilience (Resilience Hub, FIS, DRS).

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

Under regulation (SEC Rule 17a-4), a financial firm must retain transaction backups for 7 years so that no one — not even the AWS root user — can delete or modify them. What is the most appropriate configuration?

• ABackup Vault Governance Lock
• BBackup Vault Compliance Lock
• CS3 Glacier Deep Archive
• DRDS automated backups for 35 days + Manual Snapshot

Question 2

In an Organization of 200 accounts, a company wants to enforce, across all accounts at once, that every production account follows the same backup policy (daily backups, 35-day retention, Cross-Region copy). What is the most efficient method?

• AEach account administrator creates a Backup Plan manually
• BDefine an AWS Organizations Backup Policy and attach it to the Production OU
• CTrigger backups with a Lambda in each account
• DCheck for missing backups with Trusted Advisor

Question 3

A company wants to protect its backups so they remain recoverable even if a workload account is taken over by ransomware. What is the most robust architecture?

• AOnly a Cross-Region Copy within the same account
• BCross-Account Copy the backups to a separate backup account and apply Compliance Lock to the destination Vault
• CTurn on S3 Versioning
• DApply a Governance Lock

Question 4

A team set up AWS Backup Cross-Account Copy, but the copy keeps failing. What is the most likely cause and solution?

• AGrant the IAM user AdministratorAccess
• BAdd the source account's permissions to the destination account Vault's KMS key policy and Vault access policy
• CChange the cron schedule of the Backup Plan
• DChange the source Region to us-east-1

Question 5

An organization wants to automatically verify that "all prod resources are backed up daily, retained for 35 days, and copied Cross-Region" and to identify noncompliant resources. What is the most appropriate tool?

• ATrusted Advisor
• BBackup Audit Manager
• CAWS Config manual rules
• DCloudTrail

Question 6

A company wants all newly created EBS and RDS resources to be included in the backup policy automatically, without human intervention. What is the most appropriate approach?

• AAn administrator manually adds each new resource to the Backup Plan
• BUse tag-based resource selection in the Backup Plan (for example, Environment=prod)
• CConfigure each service's native backup individually
• DSpecify the backup explicitly in CloudFormation every time