AWS DynamoDB Global Table

This page shows how to write Terraform and CloudFormation for DynamoDB Global Table and write them securely.


Fix issues in your cloud & app configurations

Test for misconfigurations of this resource in your cloud.


Terraform Example (aws_dynamodb_global_table)

Manages DynamoDB Global Tables V1 (version 2017.11.29). These are layered on top of existing DynamoDB Tables.

NOTE: To instead manage DynamoDB Global Tables V2 (version 2019.11.21), use the aws_dynamodb_table resource replica configuration block. Note: There are many restrictions before you can properly create DynamoDB Global Tables in multiple regions. See the AWS DynamoDB Global Table Requirements for more information.


  • arn requiredcomputed - string
  • id optionalcomputed - string
  • name required - string

Example Usage (from GitHub)

resource "aws_dynamodb_global_table" "harryStamper" {
  depends_on = ["aws_dynamodb_table.harryStamper-eu-west-1", "aws_dynamodb_table.harryStamper-eu-central-1"]
  provider   = ""

  name = "harryStamper"

resource "aws_dynamodb_global_table" "myTable" {
  depends_on = [,]
  name = "myTable"
  provider = ""

  replica {

CloudFormation Example (AWS::DynamoDB::GlobalTable)

The AWS::DynamoDB::GlobalTable resource enables you to create and manage a Version 2019.

21 global table. This resource cannot be used to create or manage a Version 2017.

29 global table.

Important You cannot convert a resource of type AWS::DynamoDB::Table into a resource of type AWS::DynamoDB::GlobalTable by changing its type in your template. **Doing so might result in the deletion of your DynamoDB table.

**You should be aware of the following behaviors when working with DynamoDB global tables.

  • The IAM Principal executing the stack operation must have the permissions listed below in all regions where you plan to have a global table replica. The IAM Principal's permissions should not have restrictions based on IP source address. Some global tables operations (for example, adding a replica) are asynchronous, and require that the IAM Principal is valid until they complete. You should not delete the Principal (user or IAM role) until CloudFormation has finished updating your stack.
  • dynamodb:CreateTable + dynamodb:UpdateTable + dynamodb:DeleteTable + dynamodb:DescribeContinuousBackups + dynamodb:DescribeContributorInsights + dynamodb:DescribeTable + dynamodb:DescribeTableReplicaAutoScaling + dynamodb:DescribeTimeToLive + dynamodb:ListTables + dynamodb:UpdateTimeToLive + dynamodb:UpdateContributorInsights + dynamodb:UpdateContinuousBackups + dynamodb:ListTagsOfResource + dynamodb:TagResource + dynamodb:UntagResource + dynamodb:BatchWriteItem + dynamodb:CreateTableReplica + dynamodb:DeleteItem + dynamodb:DeleteTableReplica + dynamodb:DisableKinesisStreamingDestination + dynamodb:EnableKinesisStreamingDestination + dynamodb:GetItem + dynamodb:PutItem + dynamodb:Query + dynamodb:Scan + dynamodb:UpdateItem + dynamodb:DescribeTableReplicaAutoScaling + dynamodb:UpdateTableReplicaAutoScaling + iam:CreateServiceLinkedRole + kms:CreateGrant + kms:DescribeKey + application-autoscaling:DeleteScalingPolicy + application-autoscaling:DeleteScheduledAction + application-autoscaling:DeregisterScalableTarget + application-autoscaling:DescribeScalingPolicies + application-autoscaling:DescribeScalableTargets + application-autoscaling:PutScalingPolicy + application-autoscaling:PutScheduledAction + application-autoscaling:RegisterScalableTarget+ When using provisioned billing mode, CloudFormation will create an auto scaling policy on each of your replicas to control their write capacities. You must configure this policy using the WriteProvisionedThroughputSettings property. CloudFormation will ensure that all replicas have the same write capacity auto scaling property. You cannot directly specify a value for write capacity for a global table.
    • If your table uses provisioned capacity, you must configure auto scaling directly in the AWS::DynamoDB::GlobalTable resource. You should not configure additional auto scaling policies on any of the table replicas or global secondary indexes, either via API or via AWS::ApplicationAutoScaling::ScalableTarget or AWS::ApplicationAutoScaling::ScalingPolicy. Doing so might result in unexpected behavior and is unsupported.

    • In AWS 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 will create/update all replicas as part of a single stack operation. You should not deploy the same AWS::DynamoDB::GlobalTable resource in multiple regions. Doing so will result in errors, and is unsupported. If you deploy your application template in multiple regions, you can use conditions to only create the resource in a single region. Alternatively, you can choose to define your AWS::DynamoDB::GlobalTable resources in a stack separate from your application stack, and make sure it is only deployed to a single region.


Frequently asked questions

What is AWS DynamoDB Global Table?

AWS DynamoDB Global Table is a resource for DynamoDB of Amazon Web Service. Settings can be wrote in Terraform and CloudFormation.

Where can I find the example code for the AWS DynamoDB Global Table?

For Terraform, the leslieonline1/harry-stamper and arthurngatat/Tia-first-copy source code examples are useful. See the Terraform Example section for further details.