Backup, Replication, and Service Quotas
Key Takeaways
- AWS Backup organization policies attach to the organization or OUs, merge by backup plan name, and require vaults and IAM roles to already exist in member accounts. Delegated administrator accounts can manage policies and monitor jobs but cannot register other delegated admins or override management-account resource opt-in the way the management account can.
- AWS Backup Vault Lock has governance mode (removable with IAM) and compliance mode (immutable after a grace period of at least three days). Logically air-gapped vaults include a compliance-mode vault lock and can be shared with AWS RAM.
- Multi-AZ is synchronous in-Region HA (RDS Multi-AZ instance failover typically 60–120 seconds; Multi-AZ clusters typically under 35 seconds). Cross-Region replication is a different design: Aurora Global Database, RDS replicas, S3 CRR, EFS replication, FSx-native replication, and EBS snapshot copies.
- S3 Replication Time Control is an SLA to replicate 99.99 percent of new objects within 15 minutes. EFS documents a 15-minute RPO for most file systems after initial sync, with longer times possible for extremely large or chatty file systems.
- Service Quotas are usually per Region. Increases are requested before disaster because AWS states they are not immediate and can take a couple of days. ARC readiness check can watch quotas but is not the failover API.
Backups, replicas, and limits are three different controls
Quick Answer: AWS Backup is the organization-wide backup plan plane: vaults, vault lock, optional logically air-gapped vaults, and AWS Organizations backup policies. Multi-AZ is in-Region high availability. Cross-Region replication is how you get a live (or nearly live) copy in another Region. Service Quotas cap both. A disaster-recovery Region that cannot launch Amazon EC2 or Amazon RDS instances because nobody requested a quota increase will miss RTO even if snapshots exist.
SAP-C02 mixes these on purpose. A stem that says “ransomware deleted objects” wants versioning, vault lock, or air-gapped copies—not a second Aurora writer. A stem that says “AZ impairment” wants Multi-AZ or zonal shift. A stem that says “the DR drill failed with a quota error” wants Service Quotas requested days earlier.
AWS Backup at organization scale (Task 1.3)
Enable backup policies and cross-account monitoring from the management account. Delegated administrator member accounts (AWS Backup documents up to five) can manage backup policies and watch cross-account jobs after you also delegate policy management in Organizations and attach AWSBackupOrganizationAdminAccess. They cannot register other delegated admins or enable cross-account management. For plans created by Organizations policies, resource opt-in in the management account overrides member-account opt-in for that plan.
Policies select resources by type or tags, not by individual resource Amazon Resource Names (ARNs). Each member account still needs at least one backup vault or logically air-gapped vault and an AWS Identity and Access Management (IAM) role. Policies that point at missing vault names fail at execution time. Inheritance example from AWS Backup docs: organization policy A keeps daily backups 7 days; Finance organizational unit (OU) policy B overrides lifecycle to 30 days; accounts under Finance receive the merged plan; everyone else keeps policy A. Merging applies when plans share the same name.
Vaults are Regional, named per account. Access policies on the vault add a resource-based layer beyond IAM. AWS Backup Vault Lock:
| Mode | Who can remove the lock | Grace period | After lock is final |
|---|---|---|---|
| Governance | Principals with the right IAM permissions | None (no ChangeableForDays) | Lock can still be removed by those principals |
| Compliance | Nobody, including AWS, once grace ends and recovery points exist | At least 3 days (72 hours), set with ChangeableForDays | Vault configuration is immutable; recovery points cannot be deleted until their lifecycle ends |
Compliance mode is the WORM-style control for privileged-user deletion. Do not set retention to “always” and then lock: those recovery points cannot be deleted later and you pay forever. Governance mode is the “only backup admins can mutate this vault” control.
Logically air-gapped vaults come with a compliance-mode vault lock, encryption with an AWS owned key by default (customer managed AWS Key Management Service (KMS) key optional), and sharing through AWS Resource Access Manager (AWS RAM) (or multi-party approval where you use it) so another account can restore without a brittle copy job. AWS now allows a logically air-gapped vault as a primary backup target in plans and organization policies, but that primary path is documented as same account and same Region; cross-Region protection still uses copy jobs into an air-gapped vault in the destination Region. Some resource types (AWS lists examples such as EFS and S3 as fully managed) can write directly; others (examples: EC2, EBS, FSx) create a temporary recovery point in a standard vault, copy, then delete the temporary point.
Cross-account copy is a separate Organizations setting. Use it so a compromised workload account cannot be the only place backups live.
Multi-AZ versus Multi-Region (do not conflate)
| Data store | In-Region HA (Multi-AZ / built-in) | Cross-Region DR copy | Notes you can cite |
|---|---|---|---|
| Amazon RDS Multi-AZ instance | Synchronous standby in a second AZ; standby does not serve reads | Manual snapshot copy, automated backup replication, or a read replica in another Region (asynchronous) | Failover typically 60–120 seconds; large transactions can extend it |
| Amazon RDS Multi-AZ cluster | Writer plus two readable standbys in three AZs | Same as other RDS engines: replicas or snapshot copy | Failover typically under 35 seconds |
| Amazon Aurora | Cluster volume replicated across three AZs; replicas in-Region | Aurora Global Database: dedicated replication, typical RPO in seconds; AWS says RTO can be on the order of minutes. Switchover (planned) waits for sync, RPO 0. Failover (unplanned) can lose seconds of unreplicated writes | |
| Amazon S3 | Objects stored across AZs in the Region by design | CRR or same-Region replication (SRR); S3 Replication Time Control (S3 RTC) SLA: 99.99% of new objects within 15 minutes; Batch Replication for existing objects | Versioning plus replica delete-marker choices protect against malicious deletes |
| Amazon EBS | Volume lives in one AZ; snapshots are Regional | Copy snapshot to another Region (first copy to a Region is full; later copies can be incremental if documented conditions hold). Limit of 20 concurrent copy requests per destination | Recurring copies via AWS Backup or Data Lifecycle Manager, not hope |
| Amazon Elastic File System (Amazon EFS) | Regional file system spanning AZs (depending on class) | EFS replication to another Region or account | After initial sync, AWS documents RPO of 15 minutes for most file systems; very large or frequently changing trees can exceed 15 minutes |
| Amazon FSx | Multi-AZ deployment types where offered | FSx for NetApp ONTAP: volume SnapMirror (asynchronous; schedules as frequent as every 5 minutes; SVMDR and synchronous SnapMirror not supported). FSx for OpenZFS: on-demand snapshot replication, including cross-account via RAM. FSx for Windows File Server: no native cross-Region file replication; use AWS Backup copies and/or AWS DataSync | Pick the engine’s native tool; do not assume every FSx family has SnapMirror |
RDS Multi-AZ is the first reliability upgrade for an existing Single-AZ database (Task 3.4). It does not place a copy in eu-west-1. Cross-Region read replicas are asynchronous; promoting them is DR, with replica lag as RPO. Aurora Global Database is the managed global option: unplanned failover does not wait to drain replication (non-zero RPO); planned switchover is the zero-data-loss regional rotation tool.
S3 two-way replication with replica modification sync is what you pair with S3 Multi-Region Access Point failover so metadata (object lock, tags, ACLs) does not diverge. RTC is how you give compliance a 15-minute SLA on new objects; it is not Batch Replication.
Service quotas and increase strategy
Service Quotas (formerly “limits”) are the maximum counts and rates in an account, usually per Region. Some are global and are requested from a specific home Region (commonly US East (N. Virginia)). Each quota is adjustable or not. AWS states that Support may approve, deny, or partially approve, that increases are not immediate, and that it might take a couple of days to take effect. Request from the Service Quotas console, RequestServiceQuotaIncrease, or a Support case only if the service is not in Service Quotas.
Examples that bite DR drills:
- Default 40 DB instances per Region, shared among RDS, Aurora, Neptune, and DocumentDB (adjustable).
- Read replicas per primary default 15; AWS states this cannot be adjusted for Aurora.
- Manual DB snapshots default 100 per Region (adjustable).
- EBS concurrent snapshot copies to a destination: 20.
- On-Demand vCPU, Elastic IP, and load-balancer counts in the recovery Region at zero extra headroom.
Quota strategy for SAP-C02:
- Inventory every Region that might run production after failover.
- Request adjustable increases before go-live and before the first game day—not during the outage.
- Automate visibility (CloudWatch, Service Quotas alarms, ARC readiness check). Readiness check is the early-warning system, not the button you press to fail over.
- Treat non-adjustable quotas as architecture constraints (split clusters, more accounts, different engine).
- Organizations: a new member account starts at defaults. Account Factory without a quota baseline recreates the failure in every new workload account.
Payments plus quota exhaustion
Authorization runs Aurora Multi-AZ in us-east-1 and an Aurora global secondary in us-east-2 (minutes RPO). Settlement files use S3 CRR with RTC. A Regional game day promotes us-east-2 and scales the API Auto Scaling group. Launch fails: vCPU quota is still the default. Snapshots, global databases, and Route 53 were never the bottleneck. The miss is Task 3.4 / 1.3 operational resilience: quotas are part of RTO. Raise them, retest, and keep readiness checks on the replica’s instance class counts.
New solutions (Task 2.2) should include quota requests in the launch checklist next to KMS keys and VPC endpoints. Existing solutions (Task 3.4) should run a table-top plus a real scale-out in the DR Region before advertising a warm-standby RTO.
An AWS Organizations management account applies a backup policy that takes daily backups and retains them for 7 days across the organization. The Finance OU must retain the same daily backups for 30 days. Vaults and IAM roles already exist in every member account. How should AWS Backup organization policies implement this?
A warm-standby disaster-recovery drill in eu-west-1 fails when Auto Scaling cannot launch Amazon EC2 instances due to quota exhaustion, even though Amazon Aurora Global Database promotion succeeds. What should the architect have done before advertising an RTO of minutes?
Authorization data needs an RPO of minutes across AWS Regions. Large object dumps can tolerate about 15 minutes if an SLA exists. Both workloads already use Multi-AZ where the service offers it. Which additional design matches current AWS replication features?