Preparation checklist for DynamoDB global tables and Frequently Asked Questions - Amazon DynamoDB
FAQ
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Preparation checklist for DynamoDB global tables and Frequently Asked Questions

Use the following checklist for decisions and tasks when you deploy global tables.

  • Determine how many and which Regions should participate in the global table.

  • Determine your application’s write mode. For more information, see Write modes with DynamoDB global tables.

  • Plan your Request routing with DynamoDB global tables strategy, based on your write mode.

  • Define your evacuation plan, based on your write mode and routing strategy.

  • Capture metrics on the health, latency, and errors across each Region. For a list of DynamoDB metrics, see the Amazon blog post Monitoring Amazon DynamoDB for Operational Awareness for a list of metrics to observe. You should also use synthetic canaries (artificial requests designed to detect failures, named after the canary in the coal mine), as well as live observation of customer traffic. Not all issues will appear in the DynamoDB metrics.

  • Set alarms for any sustained increase in ReplicationLatency. An increase might indicate an accidental misconfiguration in which the global table has different write settings in different Regions, which leads to failed replicated requests and increased latencies. It could also indicate that there is a Regional disruption. A good example is to generate an alert if the recent average exceeds 180,000 milliseconds. You might also watch for ReplicationLatency dropping to 0, which indicates stalled replication.

  • Assign sufficient maximum read and write settings for each global table.

  • Identify the reasons for evacuating a Region in advance. If the decision involves human judgment, document all considerations. This work should be done carefully in advance, not under stress.

  • Maintain a runbook for every action that must take place when you evacuate a Region. Usually very little work is involved for the global tables, but moving the rest of the stack might be complex.

    Note

    It’s best practice to rely only on data plane operations and not control plane operations because some control plane operations may be degraded during region failures.

    For more information, see the Amazon blog post Build resilient applications with Amazon DynamoDB global tables: Part 4.

  • Test all aspects of the runbook periodically, including Region evacuations. An untested runbook is an unreliable runbook.

  • Consider using Resilience Hub to evaluate the resilience of your entire application (including global tables). It provides a comprehensive view of your overall application portfolio resilience status through its dashboard.

  • Consider using ARC readiness checks to evaluate the current configuration of your application and track any deviances from best practices.

  • When writing a health check for use with Route 53 or Global Accelerator, it’s not sufficient to just ping that the DynamoDB endpoint is up. That doesn’t cover the many failure modes such as IAM configuration errors, code deployment problems, failure in the stack outside DynamoDB, higher than average read or write latencies, and so on. It’s best to perform a set of calls that exercise a full database flow.

Frequently Asked Questions (FAQ) for deploying global tables

What are some useful principles for overall usage of DynamoDB global tables?

DynamoDB global tables has very few control knobs yet still requires a number of considerations. You must determine your write mode, routing model, and evacuation processes. You must instrument your application across every Region and be ready to adjust your routing or perform an evacuation to maintain global health. The reward is having a globally distributed data set with low-latency reads and writes and a 99.999% service level agreement.

What is the pricing for global tables?

A write to a traditional DynamoDB table is priced in Write Capacity Units (WCUs, for provisioned tables) or Write Request Units (WRUs, for on-demand tables). If you write a 5 KB item it incurs a charge of 5 units. A write to a global table is priced in Replicated Write Capacity Units (rWCUs, for provisioned tables) or Replicated Write Request Units (rWRUs, for on-demand tables).

The rWCUs and rWRUs include the cost of the streaming infrastructure needed to manage the replication.

Replicated Write Unit charges are incurred in every Region where the item is directly written or replicate written.

Writing to a Global Secondary Index (GSI) is considered a local write and uses regular Write Units.

There is no Reserved Capacity available for rWCUs at this time. Purchasing Reserved Capacity may still be beneficial for tables with GSIs consuming write units.

The initial bootstrap when adding a new Region to a global table is charged like a restore per GB of data restored, plus cross-Region data transfer fees.

Which Regions does global tables support?

Global Tables version 2019.11.21 (Current) is available in all Regions.

How are GSIs handled with global tables?

In Global Tables version 2019.11.21 (Current), when you create a GSI in one Region it’s automatically created in other participating Regions and automatically backfilled.

How do I stop replication of a global table?

You can delete a replica table the same way you would delete any other table. Deleting the global table stops replication to that Region and deletes the table copy kept in that Region. However, you cannot stop replication while keeping copies of the table as independent entities, nor can you pause replication.

How do DynamoDB Streams interact with global tables?

Each global table produces an independent stream based on all its writes, wherever they started from. You can choose to consume the DynamoDB stream in one Region or in all Regions (independently). If you want to process local but not replicated write operations, you can add your own Region attribute to each item to identify the writing Region. You can then use a Lambda event filter to call the Lambda function only for write operations in the local Region. This helps with insert and update operations, but unfortunately not delete operations.

How do global tables handle transactions?

Transactional operations provide atomicity, consistency, isolation, and durability (ACID) guarantees only within the Region where the write operation originally occurred. Transactions are not supported across Regions in global tables. For example, if you have a global table with replicas in the US East (Ohio) and US West (Oregon) Regions and perform a TransactWriteItems operation in the US East (Ohio) Region, you might observe partially completed transactions in the US West (Oregon) Region as changes are replicated. Changes are replicated to other Regions only after they have been committed in the source Region.

How do global tables interact with the DynamoDB Accelerator cache (DAX)?

Global tables bypass DAX by updating DynamoDB directly, so DAX isn’t aware that it’s holding stale data. The DAX cache is refreshed only when the cache’s TTL expires.

Do tags on tables propagate?

No, tags do not automatically propagate.

Should I backup tables in all Regions or just one?

The answer depends on the purpose of the backup. If you want to ensure data durability, DynamoDB already provides that safeguard. The service ensures durability. If you want to keep a snapshot for historical records (for example, to meet regulatory requirements), backing up in one Region should suffice. You can copy the backup to additional Regions by using Amazon Backup. If you want to recover erroneously deleted or modified data, use DynamoDB point-in-time recovery (PITR) in one Region.

How do I deploy global tables using Amazon CloudFormation?

CloudFormation represents a DynamoDB table and a global table as two separate resources: AWS::DynamoDB::Table and AWS::DynamoDB::GlobalTable. One approach is to create all tables that can potentially be global by using the GlobalTable construct. You can then keep them as standalone tables initially, and add Regions later if needed.

In CloudFormation, each global table is controlled by a single stack, in a single Region, regardless of the number of replicas. When you deploy your template, CloudFormation creates and updates all replicas as part of a single stack operation. You should not deploy the same AWS::DynamoDB::GlobalTable resource in multiple Regions. This will result in errors and is unsupported. If you deploy your application template in multiple Regions, you can use conditions to create the AWS::DynamoDB::GlobalTable resource in a single Region. Alternatively, you can choose to define your AWS::DynamoDB::GlobalTable resources in a stack that’s separate from your application stack, and make sure that it’s deployed to a single Region.

If you have a regular table and you want to convert it to a global table while keeping it managed by CloudFormation then set the deletion policy to Retain, remove the table from the stack, convert the table to a global table in the console, and then import the global table as a new resource to the stack.

Cross-account replication is not supported at this time.