apointoo.
Request access
HIPAA

AWS and Google Cloud Region Choices for US EU Brazil

cmsapointoo··6 min read

AWS and Google Cloud region choices should be made from the tenant’s workload, service availability, contract, latency, backup, support, and transfer requirements. A region map is a starting inventory, not a promise that every service, key, log, subprocessor, or support action stays there. Recheck volatile provider pages on the draft and launch dates.

For US, EU, and Brazil workloads, assign an immutable home region, select only verified services, and keep records separate from global routing metadata. Compare one-region and multi-region designs using the same evidence categories. A region can reduce movement while adding replication and support complexity.

What a useful region map contains

A useful map names the provider, service, region identifier, workload, data class, replication, support path, contract, and review date. Do not list only compute regions. A cloud application may use a runtime, database, object store, queue, key manager, logging service, monitoring service, build system, and backup product with different location behavior.

Map column Question Why it matters
Service Which exact product holds or processes data? Eligibility and feature scope
Region Where does the service run? Residency and latency
Replication Where are copies created? Availability and transfers
Support Which countries can access? Remote access risk
Contract Which agreement covers it? Role and obligation evidence
Review date When was the fact checked? Volatility control

AWS publishes a HIPAA eligible services reference, but it does not make every account or deployment eligible by itself. Google Cloud publishes location pages for individual services, and Firestore location behavior can differ from Cloud Run. Check the exact service and feature.

How to compare US, EU, and Brazil homes

Choose a home region from tenant requirements. US may simplify a US customer’s contract and support expectations. EU may support an EU residency policy and local latency. São Paulo may support a Brazil local-processing default. None of these statements answers remote support, backup, or transfer mechanisms by itself.

Home zone Primary decision Questions left open
US US records and operational locality Overseas support, backup, and state privacy
EU EU record location Third-country access and Chapter V mechanism
Brazil Brazil local default ANPD transfer mechanism and foreign support

Use HIPAA US data residency, GDPR EU health data residency, and São Paulo home region as the related decision paths. Keep their legal analysis separate; do not present one jurisdiction’s rule as another’s.

Why service-level availability matters

A region may exist for the provider but not for the service or feature you need. Verify runtime, database, storage, queue, keys, backups, logging, monitoring, and deployment tooling independently. Record the source title and retrieval date. If a feature is in preview, excluded from an agreement, or subject to a later migration, mark that volatility plainly.

Compare service behavior as well as location:

  • Can the database location be changed after creation?
  • Does a managed service replicate across a paired region?
  • Where are backups and point-in-time recovery copies held?
  • Can support or incident personnel access data from another country?
  • Are encryption keys regional, global, or customer-controlled?
  • Do logs contain request content or only metadata?

A region map should list the answer and the evidence. Unknown is a valid state that blocks a residency promise until resolved.

DynamoDB global tables and home-region policy

AWS documentation describes DynamoDB global tables as a multi-region, multi-active capability that replicates table items to selected regions. That behavior can conflict with a policy that assigns one home region to protected records. Do not use global tables for a single-home-region workload without a deliberate legal, contract, and architecture decision.

Separate ordinary regional tables may be a better fit when each tenant’s records must remain in one zone. The tradeoff is operational complexity: application routing, migrations, cross-region reporting, backups, and recovery must be designed explicitly. Availability does not justify unreviewed replication.

The same principle applies to any provider. “Global” can mean global control plane, global replication, or global support. Ask which one applies.

Cost and latency without false precision

Region choice can change request latency, service price, egress, backup cost, and operational effort. Treat any estimate as a planning range with an as-of date. Provider prices and regional multipliers change, and a small workload may be dominated by fixed services such as load balancing, logging, keys, or backups.

Estimate input Label Recheck trigger
Compute and database Planning estimate Volume or service change
Backup and egress Planning estimate New region or restore path
Latency Measured observation Customer geography or routing change
Eligibility and contract Current source claim Provider terms change

Do not choose a lower-cost region if it violates the tenant’s approved residency or contract. Conversely, do not add regions merely because they sound safer. Measure the recovery and support requirement first.

Tenant approval checklist

Before selecting AWS or Google Cloud regions, document the tenant’s home zone, data classes, availability objective, support countries, legal mechanism, service list, and backup policy. Security should validate the provider configuration and negative region tests. Procurement and counsel should review agreement and transfer scope.

  1. Service-by-service region map completed.
  2. Provider eligibility and BAA or DPA scope checked.
  3. Backups, keys, logs, queues, and support included.
  4. Global replication behavior understood.
  5. Costs labeled as estimates with an as-of date.
  6. Region move and restore process tested.
  7. Customer wording limited to evidence.
  8. Recheck owner and stop condition assigned.

When the map is incomplete, do not call the deployment regional or compliant. Finish the evidence first.

FAQ

What is the first verification step for AWS and Google Cloud regions?

List each exact service and verify its current location, replication, support, and contract behavior. A provider-wide region list is not sufficient.

Which source or configuration detail could change this answer?

Service launches, region availability, global replication, backup defaults, pricing, provider contracts, and support routing can change the map. Recheck on material changes.

What must be approved before a production claim or outbound action?

The tenant home zone, service list, replication policy, backup and key scope, transfer mechanism, cost assumptions, and customer wording should be approved by the relevant owners.

References

Related articles