apointoo.
Request access
HIPAA

Why DynamoDB Global Tables Can Break Data Residency

cmsapointoo··8 min read

Short answer: DynamoDB Global Tables can conflict with a tenant home-region policy because the feature replicates table data across selected AWS regions. As of 2026-08-15, AWS documents the replication model and eligible-service scope, while the European Commission describes the safeguards needed for international data transfers. A replicated table is therefore a residency decision, not only an availability feature.

AWS service fit and regional boundary

Global Tables is appropriate only when every selected replica location is approved for every item. AWS’s Global Tables Core Concepts documentation describes multi-region replication behavior. That is the technical fact. It does not say that a global table satisfies a customer’s data-residency promise. The AWS HIPAA Eligible Services Reference likewise supports service eligibility, not a tenant-specific location decision.

Define a residency policy before selecting replication. A tenant may have a home region for protected records, files, keys, backups, logs, queues, and workers. If one table replicates all items to the United States, European Union, and Brazil, every tenant’s record follows the table’s replication topology unless the design proves a narrower mechanism. A label on the item does not undo a copy already made in another region.

Separate availability from residency. Multi-region recovery can be valuable, but the approved recovery geography may be inside one jurisdiction or require a contract and transfer mechanism. Document whether the requirement is strict storage, remote access, support location, disaster recovery, or all four. Do not use an availability setting to satisfy a residency requirement without checking the actual data path.

Question Global Tables effect Review evidence
Where is the item stored? In each selected replica region Table topology and region inventory
Who can access it? Regional services and operator roles IAM, support, and audit review
Where is recovery? Backup and restore may add locations Restore plan and test result
What law applies? Depends on people, entities, and transfers Counsel-approved transfer map

For a non-global alternative, read DynamoDB tenant partitioning. For broader cloud boundaries, use cloud shared responsibility for HIPAA and immutable tenant home zones.

Request, data, key, and identity path

Route tenants to region-specific data stores from server-side policy. Resolve tenant membership and immutable home region before a protected write. Use a regional table or database selected by trusted configuration, not by a browser parameter or client-supplied region. Keep the control plane limited to opaque tenant ID, home zone, deployment state, and billing references.

Do not place patient names, email addresses, phone numbers, service or treatment details, or hashed contact identifiers into a cross-region analytics path. An approved generic conversion record can carry only a generic event name, event time, currency, and value when counsel and the tenant approve the exact use. A click or booking reference can still create sensitive context, so treat it as a contract question rather than assuming it is harmless.

control plane: tenant ID -> immutable home region
                         |
          +--------------+--------------+
          v              v              v
       US table       EU table       Brazil table
       US keys        EU keys        Brazil keys
       US logs        EU logs        Brazil logs
       US backups     EU backups     Brazil backups

The diagram shows separate regional stores, not automatic compliance. A background job, administrator, support engineer, or backup process can still create a cross-region path. Log every exception and deny any unapproved replication or export. If a tenant moves regions, treat it as a controlled migration with approval, deletion verification, and contract review.

Queue, audit, backup, and failure handling

Residency failures usually appear in secondary systems. Test queues, dead letters, audit logs, metrics, traces, exports, backups, restore targets, key replicas, and support tickets. A table may be regional while its operational log is global. An API may route correctly while a retry queue sends the event to a default region.

Create synthetic tenants in each approved zone and verify that records, files, logs, backups, and keys remain in that zone. Attempt a wrong-region write, a replay from another region, a global table change, and a support export. The expected result should be denial or a visible approval gate. Inspect the actual provider configuration rather than relying on a naming convention.

The European Commission’s international-transfer rules are relevant whenever data or access crosses the European Economic Area boundary. They do not turn a region list into a conclusion. Map the exporter, importer, purpose, data, remote access, contract, transfer mechanism, and safeguards. HIPAA and GDPR can overlap, but one does not replace the other.

Backups need a residency decision too. A backup vault, cross-account copy, immutable archive, or restore test may create another location. Document approved geography, encryption key location, operator access, retention, and deletion. A restore test should verify both record recovery and location policy before any data is read.

Cost and proof gate

Global replication exchanges some recovery simplicity for replica cost and review scope. AWS pricing and service behavior can change, so estimate replicas, writes, storage, indexes, backups, data transfer, logs, and operational review at the current date. Do not call global replication cheaper just because one table is easier to deploy.

Compare three designs explicitly: one global table, separate regional tables, and separate account or project boundaries. For each, list recovery time, recovery geography, tenant onboarding, query complexity, support access, data deletion, and evidence burden. A lower infrastructure estimate can be the wrong product choice if it contradicts a contractually promised home region.

  • Make home region immutable before the first protected write.
  • Disable global replication unless every replica is approved for every tenant.
  • Keep logs, backups, keys, queues, and files in the same policy boundary.
  • Use region-specific roles and endpoints where supported.
  • Recalculate provider prices and recheck legal transfer assumptions before launch.

Residency proof checklist

A residency claim needs observed location evidence. Use synthetic records and an isolated environment.

  1. Assign one synthetic tenant to each approved region.
  2. Write and read through the normal application path.
  3. Inspect table, file, key, queue, log, backup, and restore locations.
  4. Attempt a browser-selected region and a wrong-region service call.
  5. Attempt export, support access, and recovery from an unapproved location.
  6. Review Global Tables settings and organization policies after deployment changes.
  7. Obtain counsel approval for GDPR or other cross-border transfers before production.

If one system remains globally replicated, state that limitation and stop the residency claim. Use the bounded regional design until the customer approves a different topology.

Make the residency promise operational. The onboarding record should name the tenant home zone, approved recovery zones, support countries, vendor access, and deletion owner. The deployment pipeline should reject a table or backup configuration that does not match those values. The application should reject a tenant move performed through an ordinary update. A planned move can then use a separate export, import, review, and deletion workflow.

Do not confuse low traffic with low transfer risk. One replicated item can create a cross-region copy regardless of request volume. The same applies to logs, traces, queue messages, snapshots, and support exports. Inventory the copies and identify the person or role that can read them. If the provider changes replication behavior or region availability, reopen the location decision.

A useful approval record states the allowed regions, the prohibited regions, the purpose of any recovery copy, the transfer mechanism where needed, and the test that observed the configuration. It also states what is not covered. This is more useful than a generic statement that a global table is resilient.

Document a region matrix for every tenant class. Include primary store, backup store, key, log sink, queue, support location, disaster recovery location, and approved transfer mechanism. If two tenants have different policies, do not place them in one global table unless the replication contract is approved for both. A shared topology turns one tenant’s decision into every tenant’s data path.

Availability claims should name their recovery boundary. A regional table can use backups and restore inside an approved geography. A global table may reduce some recovery steps while creating replicas that need their own review. Test the actual recovery method and measure the data loss and operator access it creates.

Refresh this matrix when AWS adds a region, changes replication behavior, or changes pricing. Recheck contracts when a customer enters a new jurisdiction. Keep the conclusion about this table and tenant set, not about Global Tables in the abstract.

Frequently asked questions

Does HIPAA require US-only storage?

Not as a universal architecture rule. A customer still needs a risk analysis, agreements, safeguards, and a location policy. Other jurisdictions or contracts may impose additional transfer or residency requirements.

Why can Global Tables break residency?

Because selected replicas receive table data in multiple regions. If a tenant’s policy permits only one home region, global replication creates an unapproved copy unless the design proves otherwise.

Can an item attribute limit replication?

An item attribute can describe intended scope, but it does not undo a replication topology. Use separate regional stores or another proven boundary when records have different approved locations.

What should counsel review?

Counsel should review tenant role, BAA and DPA chain, transfer mechanism, remote support access, backup geography, deletion, and any advertising or analytics use. Engineering should provide observed configuration and test evidence.

References

Related articles