Chapter 23 · Encryption, CMEK, Network Access, Private Connectivity, and Data Governance
Database Locations, Data Residency, Multi-Region Tradeoffs, Replication, and Governance Requirements
Choose Firestore location and endpoint strategy from latency, availability, residency, processing locality, and governance requirements—and document what cannot be changed later.
1. AtlasMart problem: location is a data-policy decision made before the first document
AtlasMart serves EU and North American customers. Product wants low latency, operations wants multi-region availability, finance wants lower cost, and governance wants a defensible answer to “where is regulated data stored and processed?” The database location is immutable after creation, so “we will move it later if needed” is not a safe plan.
- Differentiate regional and multi-region Firestore placement and their availability/latency tradeoffs.
- Explain replica topology at a high level without treating replication as backup.
- Document immutable location and migration consequences.
- Use regional/multi-regional endpoints where supported to constrain processing locality.
- Turn residency requirements into explicit evidence rather than hard-coded legal claims.
Use the Emulator Suite, a Firebase demo project, or an isolated test project for destructive, security-sensitive, billing-sensitive, migration, backup/restore, or write-heavy exercises unless the lesson explicitly marks managed verification as required. Treat shown output as expected evidence unless it is explicitly identified as captured output, and re-check current Firebase/Google Cloud edition, mode, quota, pricing, and security documentation before production execution.
AtlasMart keeps project ID
demo-atlasmart-firestore, Standard-edition Native
mode, database (default), Node.js 22+, Firebase
CLI 15.30.0, Firebase Admin Node SDK
14.4.0, Firestore emulator
127.0.0.1:8080, Auth emulator
127.0.0.1:9099, and Emulator UI
127.0.0.1:4000. Mandatory work is deterministic
and local. Cloud KMS/CMEK, VPC Service Controls, Private
Google Access, regional endpoints, Cloud Audit Logs, managed
backup/export evidence, and real residency validation require
a real Google Cloud project and are optional controlled
verification steps. The emulator does not emulate KMS key
availability, Google network routing, service perimeters,
regional processing guarantees, or managed audit logs. The
local emulator has no geographic residency semantics. Any
location evidence in the mandatory lab is policy metadata, not
proof of Google Cloud physical placement.
| Term | Meaning in this chapter |
|---|---|
| Client SDK | Mobile/web Firestore path normally authorized with Firebase Authentication and Security Rules; App Check can reduce abuse but does not replace authorization. |
| Server/Admin SDK | Trusted workload path authenticated with Google credentials/IAM; it bypasses Firestore Security Rules and therefore requires application-layer authorization. |
| Standard / Enterprise | Firestore editions with different query/index/pricing capabilities. Governance controls must be checked against the actual edition and interface. |
| Native Core / Pipeline | Enterprise Native can expose familiar Core operations and advanced Pipeline operations. Network/encryption controls protect the database resource; query semantics still differ. |
| MongoDB compatibility |
Enterprise mode exposing a MongoDB-compatible protocol
and firestore.goog endpoint. It is not
MongoDB server software and has distinct
private-connectivity instructions.
|
| CMEK | Customer-managed encryption key in Cloud KMS used by Firestore for server-side encryption at rest. It is not client-side encryption. |
| VPC Service Controls | A Google Cloud data-exfiltration control that places supported managed services/resources behind a service perimeter. It complements rather than replaces IAM/Rules. |
2. Regional vs multi-region is a workload tradeoff, not a security ranking
| Dimension | Regional | Multi-region |
|---|---|---|
| Replication scope | Multiple zones in one region | Multiple regions with read-write replicas and witness topology |
| Availability goal | High regional availability | Higher availability across regional loss |
| Write latency/cost | Often lower when compute/users are nearby | Cross-region replication can add tradeoffs and cost |
| Governance | Single-region geographic boundary | Data replicated across the defined multi-region constituent regions |
| Backup replacement? | No | No |
Current Firestore documentation publishes separate SLA targets for regional and multi-region locations. Treat those as service availability properties, not application RTO/RPO guarantees and not historical recovery.
3. Location is immutable: migration is a new-database program
Once a Firestore database is provisioned, its location setting cannot be changed. If AtlasMart later needs a different residency boundary, the team must create a database in the required location and migrate/cut over. Chapters 20 and 22 provide the migration and recovery disciplines needed for that change: inventory, dual-run, validation, cutover, rollback, and configuration reapplication.
{ "dataset": "customer-orders-eu", "requiredJurisdiction": "policy-defined-EU-boundary", "candidateLocation": "eur3", "latencyEvidence": "measure-from-approved-compute", "availabilityRequirement": "documented-SLO", "processingEndpoint": "multi-regional-if-supported", "crossBorderCopies": ["backup", "export", "analytics"], "approvalOwners": ["product", "security", "privacy", "platform"]}4. Regional endpoints add processing-locality controls for server libraries
The default Native server client endpoint is global and routes the request to the database. Google documents regional and multi-regional endpoints that constrain transmission, storage, and processing to the chosen location. They are supported by server client libraries such as Node.js, Java, Go, Python, PHP, Ruby, and C#; mobile/web SDKs do not support selecting these endpoints.
import { Firestore } from "@google-cloud/firestore";// OPTIONAL real project. Endpoint must match database location.const db = new Firestore({ projectId: "PROJECT_ID", databaseId: "DATABASE_ID", servicePath: "firestore.us-central1.rep.googleapis.com"});console.log("Configured endpoint:", db._settings?.servicePath ?? "inspect client config");Choosing a regional endpoint whose location does not match the database can produce permission errors. Do not treat endpoint strings as latency-tuning knobs; they are locality controls tied to database placement.
5. Residency is larger than the primary database
A defensible data map includes primary Firestore documents, retained backups, managed exports in Cloud Storage, analytics copies, application logs, support exports, client caches, and downstream processors. Chapter 22 showed that recovery assets have their own retention and configuration semantics. A privacy or residency policy that only names the primary Firestore location is incomplete.
| Copy | Owner | Location evidence | Retention/deletion action |
|---|---|---|---|
| Primary Firestore | Platform | Database location metadata | Application deletion + retention policy |
| Scheduled backup | DR owner | Backup resource location | Backup retention schedule / explicit deletion |
| Managed export | Data platform | Cloud Storage bucket location | Bucket lifecycle + object deletion |
| Analytics warehouse | Analytics | Warehouse dataset location | Downstream deletion workflow |
| Logs | SRE/Security | Logging bucket/sink location | Redaction + retention |
6. Failure injection: “multi-region means no backup”
Simulate an operator script that overwrites every
customerEmail field with the wrong value.
Replication faithfully propagates the corruption. The local
drill must show the same wrong value in every simulated replica
view while an immutable recovery fixture retains the prior
value. The lesson is architectural: availability replication
preserves service state; backup/PITR preserves historical state.
7. Mandatory governance exercise: choose location with explicit tradeoffs
Create three decision records for AtlasMart: customer-facing EU orders, internal telemetry, and global product catalog. For each, record user/compute geography, latency target, availability requirement, residency/legal requirement supplied by your organization, backup/export locations, approved endpoint, and migration/exit path. The exercise passes only when a reviewer can explain why each location was chosen without relying on “multi-region is always better.”
Production judgment
Put the database near the workloads and users that need it, but treat location as a cross-functional design decision. Multi-region can maximize availability/durability, while regional placement can reduce write latency/cost and simplify some locality requirements. Legal/compliance conclusions must come from your organization’s policy/legal interpretation; this course provides the technical evidence model, not universal legal advice.
Knowledge check
- Can a Firestore database location be changed in place?
- Does multi-region remove the need for backup/PITR?
- Who can use regional endpoints: server libraries or mobile/web SDKs?
- Why must exports/logs appear in a residency map?
- What should happen if policy later requires a different database location?
Review the answers
1. No.
2. No; logical corruption can replicate.
3. Server libraries support configured regional/multi-regional endpoints; mobile/web do not.
4. They are additional copies with their own locations/retention.
5. Create a new database in the required location and run a tested migration/cutover.
Summary and next step
This lesson established the working contract for Database Locations, Data Residency, Multi-Region Tradeoffs, Replication, and Governance Requirements. Keep its edition/mode assumptions, trust boundary, verification evidence, and operational constraints explicit when reusing the pattern.
Next, continue to PII Classification, Field-Level Design, Logging Redaction, Backups, Exports, and Right-to-Delete Workflows.
Authoritative references
- Firebase: Server-side encryption — Google-managed encryption, CMEK, client-side encryption distinction, and TLS in transit.
- Google Cloud: Firestore Native CMEK — availability behavior, rotation, backup/restore interaction, and limitations.
- Google Cloud: Firestore Native VPC Service Controls — Firestore service perimeter behavior.
- Google Cloud: Firestore locations — regional/multi-region topology and immutable database location.
- Google Cloud: Firestore regional endpoints — server-library data-locality endpoint behavior.
-
Google Cloud: Private Google Access for Firestore with
MongoDB compatibility
—
firestore.googandrestricted.firestore.googprivate routing.