Skip to content

AWS 2026-08-13

Read original ↗

Recovery strategies to meet data residency requirements

Summary

AWS frames residency-aware disaster recovery as a choice among three boundaries, selected jointly with regulators after setting recovery objectives. A cryptographic boundary keeps encrypted copies in a compatible foreign Region but prevents decryption until an approved policy change; a data boundary keeps data physically in-country on AWS Outposts while accepting a separate parent-Region control plane; and a strict local autonomy boundary keeps both data and recovery control local through on-premises infrastructure or a separate-cloud lifeboat. The post's key systems insight is that locality of ciphertext, plaintext access, data plane, and control plane are distinct guarantees that must not be conflated. (Source: sources/2026-08-13-aws-recovery-strategies-to-meet-data-residency-requirements)

Key takeaways

  1. Treat residency as a recovery-design constraint, not merely a storage-placement rule. The acceptable recovery topology depends on whether rules constrain only the data, decryption capability, physical location, or the operational control plane. Countries with multiple Regions, or the EU where policy permits intra-EU recovery, can use conventional multi-Region designs; a one-Region jurisdiction needs an explicit alternative. (Source: sources/2026-08-13-aws-recovery-strategies-to-meet-data-residency-requirements)

  2. A cryptographic boundary can preserve recovery speed without granting recovery-Region plaintext access. S3 CRR or AWS Backup cross-Region copy replicates encrypted data; KMS key policies can deny Decrypt in the recovery Region until an explicitly authorized recovery decision. This is the lowest-complexity option only when regulators accept encrypted data residing in the partner country. (Source: sources/2026-08-13-aws-recovery-strategies-to-meet-data-residency-requirements)

  3. Make key-policy release a distinct, tightly governed recovery step. The post suggests MFA-separated approval, IdP-issued IAM session tags, named principals, and condition keys for the right to change decryption access. These controls separate possession of approval authority from routine operator credentials. (Source: sources/2026-08-13-aws-recovery-strategies-to-meet-data-residency-requirements)

  4. Outposts provides an in-country data plane but not disconnected autonomy. A data-boundary design can replicate S3 data with DataSync or databases with MySQL binlog/PostgreSQL logical replication to an Outposts pilot-light environment. Its control plane remains in its parent Region, so that Region should differ from the primary and connectivity back to it must be highly available. (Source: sources/2026-08-13-aws-recovery-strategies-to-meet-data-residency-requirements)

  5. Strict local autonomy moves both backup data and recovery operations outside the primary cloud Region. On-premises recovery must be able to encrypt, decrypt, restore, and run workloads without depending on the primary Region. The alternative multi-cloud lifeboat intentionally offers only critical functions and accepts eventually consistent data rather than attempting a transparent full-platform replica. (Source: sources/2026-08-13-aws-recovery-strategies-to-meet-data-residency-requirements)

  6. A lifeboat reduces correlated failure by being different. AWS cites Monzo's separate-cloud stand-in for card payments, transfers, and balances: it shares neither code nor infrastructure with the primary microservices estate. The deliberate degraded experience is the trade for independent availability. (Source: sources/2026-08-13-aws-recovery-strategies-to-meet-data-residency-requirements)

  7. Recovery evidence must be continuously produced. Tests need to validate backup integrity and consistency, launch recovered compute and databases, and run synthetic traffic. Synthetic non-residency data can test procedures when production-data decryption is disallowed, but cannot prove recovery of the actual critical data. (Source: sources/2026-08-13-aws-recovery-strategies-to-meet-data-residency-requirements)

Architectural decision matrix

Strategy Data location during standby Recovery control plane Recovery posture Principal trade-off
patterns/cryptographic-boundary-recovery Compatible foreign Region, encrypted AWS multi-Region S3 CRR or AWS Backup copy Fastest and simplest, but ciphertext leaves the country
patterns/data-boundary-recovery In-country Outposts / approved facility Different parent AWS Region Backup or pilot light Local data plane, but depends on parent-Region connectivity/control plane
patterns/strict-local-autonomy-recovery In-country on-premises or approved second cloud Local or second-cloud Backup restore or limited stand-in Strongest locality/autonomy, greatest operational burden

Systems and mechanisms extracted

  • AWS KMS — customer-controlled encryption keys and key policies establish the cryptographic gate; multi-Region keys can use the same key material for client-side-encrypted replicated S3 backups.
  • Amazon S3 — S3 Cross-Region Replication is the object-data movement primitive under the cryptographic-boundary option.
  • AWS Backup — provides a cross-Region-copy alternative for protected AWS resources.
  • AWS Outposts — hosts in-country EC2, RDS, and S3 resources under the data-boundary option; data access is local, while provisioning remains parent-Region control-plane mediated.
  • AWS DataSync — copies S3 backup data between the primary Region and approved on-premises/Outposts storage.
  • Amazon RDS — database replication examples are MySQL binlog and PostgreSQL logical replication, rather than an implied managed cross-Region primitive.

Operational guidance

  • Choose a parent Region for Outposts that is different from the primary Region, so a primary-Region event does not also remove the ability to launch recovery resources.
  • Do not treat Outposts as a disconnected site: it requires highly available network connectivity to its parent Region and supports only a subset of Regional services.
  • Define the conditions and authorities for key-policy change before an incident; an encrypted copy that cannot be authorized for decryption does not satisfy the required RTO.
  • Test both data consistency and the complete recovered request path. Test frequency should track environment change rate, not an arbitrary quarterly schedule.

Caveats

  • This is a prescriptive architecture framework, not a measured production retrospective: it publishes no universal RPO, RTO, cost, replication-lag, or availability figures.
  • Encryption is a compensating control only where regulators accept encrypted copy placement; it does not make a residency requirement disappear.
  • An Outposts design locates data-plane resources locally but does not locate the service control plane locally.
  • A lifeboat is purposely non-transparent and eventually consistent. It should not be marketed internally as an active-active replica.
  • The post warns that an in-country multi-cloud design may still fail to protect against a simultaneous disruption affecting all major providers in that geography.

Source

Last updated · 622 distilled / 1,953 read