Global tables FAQ

This section provides answers to frequently asked questions about DynamoDB global tables.

What is the pricing for global tables?

• A write operation in 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.

• rWCUs and rWRUs include the cost of the streaming infrastructure needed to manage the replication. As such, they are priced 50 percent higher than WCUs and WRUs. Cross-Region data transfer fees apply.

• rWCU and rWRU charges are incurred in every Region where the item is written directly or written through replication.

• Writing to a global secondary index (GSI) is considered a local write operation and uses regular write units.

• There is no reserved capacity available for rWCUs at this time. Purchasing reserved capacity for WCUs might still be beneficial for tables where GSIs consume write units.

• When you add a new Region to a global table, DynamoDB bootstraps the new Region automatically and charges you as if it were a table restore, based on the GB size of the table. It also charges cross-Region data transfer fees.

Which Regions do global tables support?

Global tables support all AWS Regions.

How are GSIs handled with global tables?

In global tables (current, version 2019), when you create a GSI in one Region, it’s automatically created in other participating Regions and automatically backfilled.

How do I stop the 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 Amazon DynamoDB Streams interact with global tables?

Each global table produces an independent stream based on all its write operations, 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 an AWS Lambda event filter to call the Lambda function only for write operations in the local Region. This helps with insert and update operations, but not delete operations.

How do global tables handle transactions?

Transactional operations provide atomicity, consistency, isolation, 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 (DAX) cache?

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 back up 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 AWS 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 by using AWS 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, keep them as standalone tables initially, and add Regions later, if necessary.

• 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: 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. For more information, see the AWS GitHub repository amazon-dynamodb-table-to-global-table-cdk.

• Cross-account replication is not supported at this time.