Enable Amazon DynamoDB Global Tables for Multi-Region Replication – SAP-C02 Study Guide

Purpose of This Lesson

Amazon DynamoDB Global Tables provide a managed, multi-Region replication model for DynamoDB tables. They allow applications to read from and write to local replicas in different AWS Regions while DynamoDB asynchronously synchronizes changes between those replicas.

This exercise demonstrates how to add a replica to an existing DynamoDB table, verify bidirectional replication, and clean up the resources afterward.

Key Concepts

DynamoDB Global Tables

A Global Table is a collection of synchronized DynamoDB table replicas deployed across multiple AWS Regions. Each replica contains the same table data and can serve application traffic locally.

Typical use cases include:

• Low-latency access for globally distributed users
• Multi-Region active-active application architectures
• Improved resilience against a Regional failure
• Disaster recovery with a writable secondary Region
• Localized reads and writes without routing every request to one Region

Global Tables replication is asynchronous. A successful write in one Region is replicated to the other participating Regions rather than being synchronously committed everywhere before the client receives a response.

DynamoDB Streams Integration

Global Tables require DynamoDB Streams. When Global Tables are enabled through the console, DynamoDB automatically enables streams with both:

• NEW_IMAGE: the item after the change
• OLD_IMAGE: the item before the change

The stream records provide the change information needed for cross-Region replication. Applications should not treat this implementation detail as a substitute for designing their own event-processing workflow; Global Tables manage replication automatically.

Regional Replicas

Adding a Region creates a replica of the existing table. The replica inherits the table’s data and participates in ongoing replication.

Important points:

• The replica is created in a specific AWS Region.
• The table must finish provisioning before it is fully usable.
• Existing items are copied to the new replica.
• Subsequent writes are replicated between participating Regions.
• Each replica can accept local reads and writes.

Bidirectional Synchronization

After the replica becomes active, a write made in one Region should eventually appear in the other Region. For example:

1. Create an item in the us-east-1 replica.
2. Create a different item in the us-west-1 replica.
3. Scan or query each replica after replication has completed.
4. Confirm that both items are visible in both Regions.

Replication is not necessarily instantaneous. A short delay is normal, so an immediate read after a remote write may not yet show the change.

Provisioning and Cleanup States

Creating a Global Table replica can take several minutes. During this operation, the table may appear in an Updating state.

Deletion may also be temporarily unavailable while the table is updating. If a delete operation fails, wait until the table returns to an appropriate active state and retry. Clean up every replica separately when the exercise or environment is complete.

Exam-Relevant Takeaways

• DynamoDB Global Tables are used for multi-Region, active-active replication of DynamoDB data.
• Global Tables support local reads and writes in each participating Region.
• Replication between Regions is asynchronous, so applications must account for replication delay.
• Global Tables use DynamoDB Streams; enabling Global Tables can automatically configure the required stream settings.
• A Global Table must have a replica in each Region where the application needs local database access.
• Adding a replica copies existing data and then continues replicating future changes.
• Global Tables improve availability and geographic latency, but they introduce multi-Region data consistency and conflict considerations.
• A table being in an Updating state can prevent administrative operations such as deletion.

Architecture Decision Guide

Requirement	Recommended approach	Reasoning
Single-Region NoSQL workload	Standard DynamoDB table	Avoids the cost and operational considerations of additional replicas
Global users need low-latency writes	DynamoDB Global Tables	Users can write to a nearby Regional replica
Read-only geographic expansion	DynamoDB Global Tables or a purpose-built replication design	Choose based on whether the secondary Regions must accept writes
Multi-Region disaster recovery with a writable recovery Region	DynamoDB Global Tables	Provides maintained replicas rather than relying only on backup restoration
Strongly consistent cross-Region transactions	Do not assume Global Tables provide this	Cross-Region replication is asynchronous and does not provide global synchronous transactions
One Region owns all writes	Single-writer design with regional read replicas or another replication pattern	Reduces write-conflict complexity when active-active writes are unnecessary
Application requires a change event stream	Enable and configure DynamoDB Streams separately as needed	Global Table replication should not automatically be assumed to satisfy application event-processing requirements

Common Exam Traps

• Assuming replication is synchronous: A successful write in one Region does not mean that every replica has already applied it.
• Confusing Global Tables with backups: Global Tables provide live replicated table replicas, not point-in-time backups or long-term retention.
• Assuming one Region is enough: A Global Table only provides multi-Region behavior after replicas are added in the required Regions.
• Ignoring write conflicts: If the same item is updated in multiple Regions around the same time, the application must tolerate the service’s conflict-resolution behavior and eventual convergence.
• Expecting immediate visibility: A scan immediately after a remote write may not show the item yet.
• Forgetting cost and capacity implications: Additional replicas add storage, write, and replication-related costs. Capacity and throughput planning must cover each participating Region.
• Treating Global Tables as a cross-Region transaction mechanism: They are not a replacement for a globally synchronous transactional database.
• Deleting only one replica: Resource cleanup requires accounting for every Regional table replica.

Real-World Engineer Notes

• Place application compute close to the DynamoDB replica it normally accesses to minimize latency.
• Use a clear routing strategy so clients generally write to the intended local or home Region.
• Define how the application behaves when a Region is unavailable and traffic is redirected elsewhere.
• Test replication delay and failover behavior instead of assuming immediate convergence.
• Design item keys and update patterns to reduce the likelihood of concurrent writes to the same item from different Regions.
• Monitor replication health, application errors, throttling, and capacity in every Region.
• Consider whether the application needs strongly consistent reads. Multi-Region designs often require accepting eventual consistency across Regions.
• Remove test replicas and tables after a lab to avoid ongoing DynamoDB charges.

Quick Reference Summary

• Service: Amazon DynamoDB Global Tables
• Purpose: Managed multi-Region replication for DynamoDB
• Replication direction: Bidirectional between participating replicas
• Write model: Local writes are supported in each replica
• Consistency across Regions: Asynchronous replication and eventual convergence
• Required integration: DynamoDB Streams, configured with old and new item images for replication
• Provisioning: Replica creation can take several minutes
• Operational caution: Updating status may temporarily block deletion or other changes
• Primary benefits: Geographic low latency, multi-Region availability, and active-active access
• Primary tradeoffs: Additional cost, replication delay, and conflict-management complexity

Flashcards

1. Q: What AWS feature provides managed multi-Region replication for DynamoDB tables?

A: DynamoDB Global Tables.

1. Q: Can applications write to more than one DynamoDB Global Table replica?

A: Yes. Global Tables support writes in participating Regional replicas.

1. Q: Is Global Tables replication synchronous across Regions?

A: No. Replication is asynchronous, so cross-Region changes may take time to appear.

1. Q: What DynamoDB feature is required by Global Tables for change capture?

A: DynamoDB Streams.

1. Q: Which stream images are enabled for Global Tables replication in this exercise?

A: Both NEW_IMAGE and OLD_IMAGE.

1. Q: What happens when a replica is added to an existing table?

A: Existing data is copied to the new Region, followed by ongoing replication of changes.

1. Q: What is a major reason to use Global Tables for a global application?

A: To provide low-latency local database access and multi-Region resilience.

1. Q: Does Global Tables provide a backup strategy?

A: No. It provides live replicas; backups and point-in-time recovery address different requirements.

1. Q: Why might an item not appear immediately in another Region?

A: Cross-Region replication is asynchronous and may have propagation delay.

1. Q: What should you do if table deletion fails while a Global Table is updating?

A: Wait until the table reaches an appropriate active state, then retry the deletion.

Practice Questions

Question 1

A company operates an application in North America, Europe, and Asia. Users must be able to read and write customer preferences with low latency in each geography. The company wants a managed DynamoDB solution that supports Regional writes and replicates changes between Regions. Which option best meets the requirement?

A. DynamoDB Streams with a Lambda function that copies records to separate tables
B. DynamoDB Global Tables with replicas in the required Regions
C. DynamoDB point-in-time recovery restored into each Region
D. An Amazon S3 bucket containing exported DynamoDB data

Correct answer: B

Explanation: DynamoDB Global Tables provide managed multi-Region replicas that support local reads and writes with asynchronous replication. Streams plus custom Lambda replication would add unnecessary implementation and operational complexity.

Question 2

An application writes an item to a DynamoDB Global Table in us-east-1 and immediately reads the same item from the eu-west-1 replica. The item is not returned. What is the most likely explanation?

A. Global Tables replicas are read-only outside the primary Region
B. DynamoDB Global Tables require a manual export before replication
C. Cross-Region replication is asynchronous and has not completed
D. DynamoDB Streams only replicate deleted items

Correct answer: C

Explanation: Global Tables support writes in participating Regions, but replication between Regions is asynchronous. A short delay can occur before the remote replica reflects the write.

Question 3

A solutions architect enables Global Tables for an existing DynamoDB table. The console indicates that DynamoDB Streams will be enabled with old and new item images. Why is this configuration relevant?

A. It enables cross-Region change capture used by Global Tables replication
B. It converts DynamoDB into a strongly consistent global database
C. It creates a backup that can be restored in any Region
D. It prevents all concurrent writes to the same item

Correct answer: A

Explanation: DynamoDB Streams capture item changes, including the old and new images required for the replication workflow. Streams do not make the database globally strongly consistent, create backups, or eliminate write conflicts.

Question 4

An engineer adds a replica to a DynamoDB Global Table and attempts to delete the table immediately. The delete operation fails because the table is still being updated. What should the engineer do?

A. Disable DynamoDB Streams and force deletion
B. Wait for the table to return to an active state and retry
C. Delete the table only from the original Region
D. Restore the table from a backup before deleting it

Correct answer: B

Explanation: Replica creation and synchronization can leave the table in an updating state. Administrative operations may be temporarily restricted until the update completes.