# Global tables version 2017.11.29 (Legacy) **Important** This documentation is for version 2017.11.29 (Legacy) of global tables, which should be avoided for new global tables. Customers should use [Global Tables version 2019.11.21 (Current)](GlobalTables.md) when possible, as it provides greater flexibility, higher efficiency and consumes less write capacity than 2017.11.29 (Legacy). To determine which version you are using, see [Determining the version of a global table](V2globaltables_versions.md#globaltables.DetermineVersion). To update existing global tables from version 2017.11.29 (Legacy) to version 2019.11.21 (Current), see [DynamoDB global tables versions](V2globaltables_versions.md). **Topics** + [ # Global tables: How it works ](globaltables_HowItWorks.md) + [ # Best practices and requirements for managing global tables ](globaltables_reqs_bestpractices.md) + [ # Creating a global table (Version 2017.11.29) ](globaltables.tutorial.md) + [ # Monitoring global tables ](globaltables_monitoring.md) + [ # Using IAM with global tables ](gt_IAM.md) # Global tables: How it works How it works **Important** This documentation is for version 2017.11.29 (Legacy) of global tables, which should be avoided for new global tables. Customers should use [Global Tables version 2019.11.21 (Current)](GlobalTables.md) when possible, as it provides greater flexibility, higher efficiency and consumes less write capacity than 2017.11.29 (Legacy). To determine which version you are using, see [Determining the version of a global table](V2globaltables_versions.md#globaltables.DetermineVersion). To update existing global tables from version 2017.11.29 (Legacy) to version 2019.11.21 (Current), see [DynamoDB global tables versions](V2globaltables_versions.md). The following sections help you understand the concepts and behavior of global tables in Amazon DynamoDB. ## Global table concepts for Version 2017.11.29 (Legacy) Global table concepts for Version 2017.11.29 (Legacy) A *global table* is a collection of one or more replica tables, all owned by a single AWS account. A *replica table* (or *replica*, for short) is a single DynamoDB table that functions as a part of a global table. Each replica stores the same set of data items. Any given global table can only have one replica table per AWS Region. The following is a conceptual overview of how a global table is created. 1. Create an ordinary DynamoDB table, with DynamoDB Streams enabled, in an AWS Region. 1. Repeat step 1 for every other Region where you want to replicate your data. 1. Define a DynamoDB global table based on the tables that you have created. The AWS Management Console automates these tasks, so you can create a global table more quickly and easily. For more information, see [Creating a global table (Version 2017.11.29)](globaltables.tutorial.md). The resulting DynamoDB global table consists of multiple replica tables, one per Region, that DynamoDB treats as a single unit. Every replica has the same table name and the same primary key schema. When an application writes data to a replica table in one Region, DynamoDB automatically propagates the write to the other replica tables in the other AWS Regions. **Important** To keep your table data in sync, global tables automatically create the following attributes for every item: `aws:rep:deleting` `aws:rep:updatetime` `aws:rep:updateregion` Do not modify these attributes or create attributes with the same name. You can add replica tables to the global table so that it can be available in additional Regions. (To do this, the global table must be empty. In other words, none of the replica tables can have any data in them.) You can also remove a replica table from a global table. If you do this, the table is completely disassociated from the global table. This newly independent table no longer interacts with the global table, and data is no longer propagated to or from the global table. **Warning** Be aware that removing a replica isn't an atomic process. To ensure consistent behavior and known state, you may want to consider diverting your application write traffic away from the replica to be removed ahead of time. After removing it, wait until all replica Region endpoints show the replica as disassociated before making any further writes to it as its own isolated regional table. ## Common tasks Common tasks for global tables work as follows. You can delete a global table’s replica table the same as a regular table. This will stop replication to that Region and delete the table copy kept in that Region. You cannot sever the replication and have copies of the table exist as independent entities. **Note** You won’t be able to delete a source table until at least 24 hours after it’s used to initiate a new Region. If you try to delete it too soon you will receive an error. Conflicts can arise if applications update the same item in different Regions at about the same time. To help ensure eventual consistency, DynamoDB global tables use a “last writer wins” method to reconcile between concurrent updates. All the replicas will agree on the latest update and converge toward a state in which they all have identical data. **Note** There are several ways to avoid conflicts, including: Using an IAM policy to only allow writes to the table in one Region. Using an IAM policy to route users to only one Region and keeping the other as an idle standby, or alternately routing odd users to one Region and even users to another Region. Avoiding the use of non-idempotent updates such as Bookmark = Bookmark \$1 1, in favor of static updates such as Bookmark=25. ## Monitoring global tables You can use CloudWatch to observe the metric `ReplicationLatency`. This metric tracks the elapsed time between when an updated item appears in the DynamoDB stream for one replica table, and when that item appears in another replica in the global table. `ReplicationLatency` is expressed in milliseconds and is emitted for every source-Region and destination-Region pair. This is the only CloudWatch metric provided by Global Tables v2. The latencies you will observe depend on the distance between your chosen Regions, as well as other variables. Latencies in the 0.5 to 2.5 second range for Regions can be common within the same geographic area. ## Time To Live (TTL) You can use Time To Live (TTL) to specify an attribute name whose value indicates the time of expiration for the item. This value is specified as a number in seconds since the start of the Unix epoch. With global tables legacy version, the TTL deletes are not automatically replicated across other replicas. When an item is deleted via a TTL rule, that work is performed without consuming Write Units. Be aware that if the source and target table have very low Provisioned write capacity, this may cause throttling as the TTL deletes require write capacity. ## Streams and transactions with global tables Each global table produces an independent stream based on all its writes, regardless of the origination point for those writes. You can choose to consume this DynamoDB stream in one Region or in all Regions independently. If you want processed local writes but not replicated writes, you can add your own region attribute to each item. Then you can use a Lambda event filter to invoke only the Lambda for writes in the local Region. Transactional operations provide ACID (Atomicity, Consistency, Isolation, and Durability) guarantees ONLY within the Region where the write is originally made. Transactions aren't 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 may observe partially completed transactions in US West (Oregon) Region as changes are replicated. Changes will only be replicated to other Regions once they have been committed in the source Region. **Note** Global tables “write around” DynamoDB Accelerator by updating DynamoDB directly. As a result DAX will not be aware it is holding stale data. The DAX cache will only be refreshed when the cache’s TTL expires. Tags on global tables do not automatically propagate. ## Read and write throughput Global tables manage read and write throughput in the following ways. + The write capacity must be the same on all table instances across Regions. + With Version 2019.11.21 (Current, if the table is set to support auto scaling or is in on-demand mode then the write capacity is automatically kept in sync. The current amount of write capacity provisioned in each Region will rise and fall independently within those synchronized auto scaling settings. If the table is placed in on-demand mode, that mode will sync to the other replicas. + Read capacity can differ between Regions because reads may not be equal. When adding a global replica to a table, the capacity of the source Region is propagated. After creation you can adjust the read capacity for one replica, and this new setting isn't transferred to the other side. ## Consistency and conflict resolution Any changes made to any item in any replica table are replicated to all the other replicas within the same global table. In a global table, a newly written item is usually propagated to all replica tables within seconds. With a global table, each replica table stores the same set of data items. DynamoDB does not support partial replication of only some of the items. An application can read and write data to any replica table. DynamoDB supports eventually consistent reads across Regions, but does not support strongly consistent reads across Regions. If your application only uses eventually consistent reads and only issues reads against one AWS Region, it will work without any modification. However, if your application requires strongly consistent reads then it must perform all the strongly consistent reads and writes in the same Region. Otherwise, if you write to one Region and read from another Region then the read response might include stale data that doesn't reflect the results of recently completed writes in the other Region. Conflicts can arise if applications update the same item in different Regions at about the same time. To help ensure eventual consistency, DynamoDB global tables use a *last writer wins* reconciliation between concurrent updates, in which DynamoDB makes a best effort to determine the last writer. With this conflict resolution mechanism, all the replicas will agree on the latest update and converge toward a state in which they all have identical data. ## Availability and durability If a single AWS Region becomes isolated or degraded, your application can redirect to a different Region and perform reads and writes against a different replica table. You can apply custom business logic to determine when to redirect requests to other Regions. If a Region becomes isolated or degraded, DynamoDB keeps track of any writes that have been performed but have not yet been propagated to all of the replica tables. When the Region comes back online, DynamoDB resumes propagating any pending writes from that Region to the replica tables in other Regions. It also resumes propagating writes from other replica tables to the Region that is now back online. All previously successful writes will be propagated eventually no matter how long the Region is isolated. # Best practices and requirements for managing global tables Best Practices and Requirements **Important** This documentation is for version 2017.11.29 (Legacy) of global tables, which should be avoided for new global tables. Customers should use [Global Tables version 2019.11.21 (Current)](GlobalTables.md) when possible, as it provides greater flexibility, higher efficiency and consumes less write capacity than 2017.11.29 (Legacy). To determine which version you are using, see [Determining the version of a global table](V2globaltables_versions.md#globaltables.DetermineVersion). To update existing global tables from version 2017.11.29 (Legacy) to version 2019.11.21 (Current), see [DynamoDB global tables versions](V2globaltables_versions.md). Using Amazon DynamoDB global tables, you can replicate your table data across AWS Regions. It is important that the replica tables and secondary indexes in your global table have identical write capacity settings to ensure proper replication of data. **Topics** + [ ## Global tables version ](#globaltables_version.tables) + [ ## Requirements for adding a new replica table ](#globaltables_reqs_bestpractices.requirements) + [ ## Best practices and requirements for managing capacity ](#globaltables_reqs_bestpractices.tables) ## Global tables version There are two versions of DynamoDB global tables available: [Global Tables version 2019.11.21 (Current)](GlobalTables.md) and [Global tables version 2017.11.29 (Legacy)](globaltables.V1.md). Customers should use Global Tables version 2019.11.21 (Current) when possible, as it provides greater flexibility, higher efficiency and consumes less write capacity than 2017.11.29 (Legacy). To determine which version you are using, see [Determining the version of a global table](V2globaltables_versions.md#globaltables.DetermineVersion). To update existing global tables from Version 2017.11.29 (Legacy) to Version 2019.11.21 (Current), see [Upgrading global tables](V2globaltables_versions.md#upgrading-to-current-version). ## Requirements for adding a new replica table If you want to add a new replica table to a global table, each of the following conditions must be true: + The table must have the same partition key as all of the other replicas. + The table must have the same write capacity management settings specified. + The table must have the same name as all of the other replicas. + The table must have DynamoDB Streams enabled, with the stream containing both the new and the old images of the item. + None of the new or existing replica tables in the global table can contain any data. If global secondary indexes are specified, the following conditions must also be met: + The global secondary indexes must have the same name. + The global secondary indexes must have the same partition key and sort key (if present). **Important** Write capacity settings should be set consistently across all of your global tables’ replica tables and matching secondary indexes. To update write capacity settings for your global table, we strongly recommend using the DynamoDB console or the `UpdateGlobalTableSettings` API operation. `UpdateGlobalTableSettings` applies changes to write capacity settings to all replica tables and matching secondary indexes in a global table automatically. If you use the `UpdateTable`, `RegisterScalableTarget`, or `PutScalingPolicy` operations, you should apply the change to each replica table and matching secondary index individually. For more information, see [UpdateGlobalTableSettings](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateGlobalTableSettings.html) in the [Amazon DynamoDB API Reference](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/). We strongly recommend that you enable auto scaling to manage provisioned write capacity settings. If you prefer to manage write capacity settings manually, you should provision equal replicated write capacity units to all of your replica tables. Also provision equal replicated write capacity units to matching secondary indexes across your global table. You must also have appropriate AWS Identity and Access Management (IAM) permissions. For more information, see [Using IAM with global tables](gt_IAM.md). ## Best practices and requirements for managing capacity Consider the following when managing capacity settings for replica tables in DynamoDB. ### Using DynamoDB auto scaling Using DynamoDB auto scaling is the recommended way to manage throughput capacity settings for replica tables that use the provisioned mode. DynamoDB auto scaling automatically adjusts read capacity units (RCUs) and write capacity units (WCUs) for each replica table based upon your actual application workload. For more information, see [Managing throughput capacity automatically with DynamoDB auto scaling](AutoScaling.md). If you create your replica tables using the AWS Management Console, auto scaling is enabled by default for each replica table, with default auto scaling settings for managing read capacity units and write capacity units. Changes to auto scaling settings for a replica table or secondary index made through the DynamoDB console or using the `UpdateGlobalTableSettings` call are applied to all of the replica tables and matching secondary indexes in the global table automatically. These changes overwrite any existing auto scaling settings. This ensures that provisioned write capacity settings are consistent across the replica tables and secondary indexes in your global table. If you use the `UpdateTable`, `RegisterScalableTarget`, or `PutScalingPolicy` calls, you should apply the change to each replica table and matching secondary index individually. **Note** If auto scaling doesn't satisfy your application's capacity changes (unpredictable workload), or if you don't want to configure its settings (target settings for minimum, maximum, or utilization threshold), you can use on-demand mode to manage capacity for your global tables. For more information, see [On-demand mode](capacity-mode.md#capacity-mode-on-demand). If you enable on-demand mode on a global table, your consumption of replicated write request units (rWCUs) will be consistent with how rWCUs are provisioned. For example, if you perform 10 writes to a local table that is replicated in two additional Regions, you will consume 60 write request units (10 \$1 10 \$1 10 = 30; 30 x 2 = 60). The consumed 60 write request units include the extra write consumed by global tables Version 2017.11.29 (Legacy) to update the `aws:rep:deleting`, `aws:rep:updatetime`, and `aws:rep:updateregion` attributes. ### Managing capacity manually If you decide not to use DynamoDB auto scaling, you must manually set the read capacity and write capacity settings on each replica table and secondary index. The provisioned replicated write capacity units (rWCUs) on every replica table should be set to the total number of rWCUs needed for application writes across all Regions multiplied by two. This accommodates application writes that occur in the local Region and replicated application writes coming from other Regions. For example, suppose that you expect 5 writes per second to your replica table in Ohio and 5 writes per second to your replica table in N. Virginia. In this case, you should provision 20 rWCUs to each replica table (5 \$1 5 = 10; 10 x 2 = 20). To update write capacity settings for your global table, we strongly recommend using the DynamoDB console or the `UpdateGlobalTableSettings` API operation. `UpdateGlobalTableSettings` applies changes to write capacity settings to all replica tables and matching secondary indexes in a global table automatically. If you use the `UpdateTable`, `RegisterScalableTarget`, or `PutScalingPolicy` operations, you should apply the change to each replica table and matching secondary index individually. For more information, see [Amazon DynamoDB API Reference](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/). **Note** To update the settings (`UpdateGlobalTableSettings`) for a global table in DynamoDB, you must have the `dynamodb:UpdateGlobalTable`, `dynamodb:DescribeLimits`, `application-autoscaling:DeleteScalingPolicy`, and `application-autoscaling:DeregisterScalableTarget` permissions. For more information, see [Using IAM with global tables](gt_IAM.md). # Creating a global table (Version 2017.11.29) **Important** This documentation is for version 2017.11.29 (Legacy) of global tables, which should be avoided for new global tables. Customers should use [Global Tables version 2019.11.21 (Current)](GlobalTables.md) when possible, as it provides greater flexibility, higher efficiency and consumes less write capacity than 2017.11.29 (Legacy). To determine which version you are using, see [Determining the version of a global table](V2globaltables_versions.md#globaltables.DetermineVersion). To update existing global tables from version 2017.11.29 (Legacy) to version 2019.11.21 (Current), see [DynamoDB global tables versions](V2globaltables_versions.md). This section describes how to create a global table using the Amazon DynamoDB console or the AWS Command Line Interface (AWS CLI). **Topics** + [ ## Creating a global table (console) ](#creategt_console) + [ ## Creating a global table (AWS CLI) ](#creategt_cli) ## Creating a global table (console) Follow these steps to create a global table using the console. The following example creates a global table with replica tables in United States and Europe. 1. Open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/home](https://console.aws.amazon.com/dynamodb/home). For this example, choose the us-east-2 (US East Ohio) Region. 1. In the navigation pane on the left side of the console, choose **Tables**. 1. Choose **Create Table**. For **Table name**, enter **Music**. For **Primary key** enter **Artist**. Choose **Add sort key**, and enter **SongTitle**. (**Artist** and **SongTitle** should both be strings.) To create the table, choose **Create**. This table serves as the first replica table in a new global table. It is the prototype for other replica tables that you add later. 1. Choose the **Global Tables** tab, and then choose **Create a Version 2017.11.29 (Legacy) replica**. ![\[Console screenshot showing the Create a Version 2017.11.29 (Legacy) replica button.\]](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/images/GlobalTables-old.png) 1. From the **Available replication Regions** dropdown, choose **US West (Oregon)**. The console checks to ensure that a table with the same name doesn't exist in the selected Region. If a table with the same name does exist, you must delete the existing table before you can create a new replica table in that Region. 1. Choose **Create Replica**. This starts the table creation process in US West (Oregon);. The **Global Table** tab for the selected table (and for any other replica tables) shows that the table has been replicated in multiple Regions. 1. Now add another Region so that your global table is replicated and synchronized across the United States and Europe. To do this, repeat step 5, but this time, specify **Europe (Frankfurt)** instead of **US West (Oregon)**. 1. You should still be using the AWS Management Console in the US East (Ohio) Region. Select **Items** in the left navigation menu, select the **Music** table, then choose **Create Item**. 1. For **Artist**, enter **item\$11**. 1. For **SongTitle**, enter **Song Value 1**. 1. To write the item, choose **Create item**. 1. After a short time, the item is replicated across all three Regions of your global table. To verify this, in the console, on the Region selector in the upper-right corner, choose **Europe (Frankfurt)**. The `Music` table in Europe (Frankfurt) should contain the new item. 1. Repeat step 9 and choose **US West (Oregon)** to verify replication in that region. ## Creating a global table (AWS CLI) Follow these steps to create a global table `Music` using the AWS CLI. The following example creates a global table, with replica tables in the United States and in Europe. 1. Create a new table (`Music`) in US East (Ohio), with DynamoDB Streams enabled (`NEW_AND_OLD_IMAGES`). ``` aws dynamodb create-table \ --table-name Music \ --attribute-definitions \ AttributeName=Artist,AttributeType=S \ AttributeName=SongTitle,AttributeType=S \ --key-schema \ AttributeName=Artist,KeyType=HASH \ AttributeName=SongTitle,KeyType=RANGE \ --provisioned-throughput \ ReadCapacityUnits=10,WriteCapacityUnits=5 \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ --region us-east-2 ``` 1. Create an identical `Music` table in US East (N. Virginia). ``` aws dynamodb create-table \ --table-name Music \ --attribute-definitions \ AttributeName=Artist,AttributeType=S \ AttributeName=SongTitle,AttributeType=S \ --key-schema \ AttributeName=Artist,KeyType=HASH \ AttributeName=SongTitle,KeyType=RANGE \ --provisioned-throughput \ ReadCapacityUnits=10,WriteCapacityUnits=5 \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ --region us-east-1 ``` 1. Create a global table (`Music`) consisting of replica tables in the `us-east-2` and `us-east-1` Regions. ``` aws dynamodb create-global-table \ --global-table-name Music \ --replication-group RegionName=us-east-2 RegionName=us-east-1 \ --region us-east-2 ``` **Note** The global table name (`Music`) must match the name of each of the replica tables (`Music`). For more information, see [Best practices for global tables](globaltables-bestpractices.md). 1. Create another table in Europe (Ireland), with the same settings as those you created in step 1 and step 2. ``` aws dynamodb create-table \ --table-name Music \ --attribute-definitions \ AttributeName=Artist,AttributeType=S \ AttributeName=SongTitle,AttributeType=S \ --key-schema \ AttributeName=Artist,KeyType=HASH \ AttributeName=SongTitle,KeyType=RANGE \ --provisioned-throughput \ ReadCapacityUnits=10,WriteCapacityUnits=5 \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ --region eu-west-1 ``` After doing this step, add the new table to the `Music` global table. ``` aws dynamodb update-global-table \ --global-table-name Music \ --replica-updates 'Create={RegionName=eu-west-1}' \ --region us-east-2 ``` 1. To verify that replication is working, add a new item to the `Music` table in US East (Ohio). ``` aws dynamodb put-item \ --table-name Music \ --item '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \ --region us-east-2 ``` 1. Wait for a few seconds, and then check to see whether the item has been successfully replicated to US East (N. Virginia) and Europe (Ireland). ``` aws dynamodb get-item \ --table-name Music \ --key '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \ --region us-east-1 ``` ``` aws dynamodb get-item \ --table-name Music \ --key '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \ --region eu-west-1 ``` # Monitoring global tables Monitoring global tables **Important** This documentation is for version 2017.11.29 (Legacy) of global tables, which should be avoided for new global tables. Customers should use [Global Tables version 2019.11.21 (Current)](GlobalTables.md) when possible, as it provides greater flexibility, higher efficiency and consumes less write capacity than 2017.11.29 (Legacy). To determine which version you are using, see [Determining the version of a global table](V2globaltables_versions.md#globaltables.DetermineVersion). To update existing global tables from version 2017.11.29 (Legacy) to version 2019.11.21 (Current), see [DynamoDB global tables versions](V2globaltables_versions.md). You can use Amazon CloudWatch to monitor the behavior and performance of a global table. Amazon DynamoDB publishes `ReplicationLatency` and `PendingReplicationCount` metrics for each replica in the global table. + **`ReplicationLatency`**—The elapsed time between when an updated item appears in the DynamoDB stream for one replica table, and when that item appears in another replica in the global table. `ReplicationLatency` is expressed in milliseconds and is emitted for every source- and destination-Region pair. During normal operation, `ReplicationLatency` should be fairly constant. An elevated value for `ReplicationLatency` could indicate that updates from one replica are not propagating to other replica tables in a timely manner. Over time, this could result in other replica tables *falling behind* because they no longer receive updates consistently. In this case, you should verify that the read capacity units (RCUs) and write capacity units (WCUs) are identical for each of the replica tables. In addition, when choosing WCU settings, follow the recommendations in [Global tables versionBest practices and requirements for managing capacity](globaltables_reqs_bestpractices.md#globaltables_reqs_bestpractices.tables). `ReplicationLatency` can increase if an AWS Region becomes degraded and you have a replica table in that Region. In this case, you can temporarily redirect your application's read and write activity to a different AWS Region. + ** `PendingReplicationCount`**—The number of item updates that are written to one replica table, but that have not yet been written to another replica in the global table. `PendingReplicationCount` is expressed in number of items and is emitted for every source- and destination-Region pair. During normal operation, `PendingReplicationCount` should be very low. If `PendingReplicationCount` increases for extended periods, investigate whether your replica tables' provisioned write capacity settings are sufficient for your current workload. `PendingReplicationCount` can increase if an AWS Region becomes degraded and you have a replica table in that Region. In this case, you can temporarily redirect your application's read and write activity to a different AWS Region. For more information, see [DynamoDB Metrics and dimensions](metrics-dimensions.md). # Using IAM with global tables **Important** This documentation is for version 2017.11.29 (Legacy) of global tables, which should be avoided for new global tables. Customers should use [Global Tables version 2019.11.21 (Current)](GlobalTables.md) when possible, as it provides greater flexibility, higher efficiency and consumes less write capacity than 2017.11.29 (Legacy). To determine which version you are using, see [Determining the version of a global table](V2globaltables_versions.md#globaltables.DetermineVersion). To update existing global tables from version 2017.11.29 (Legacy) to version 2019.11.21 (Current), see [DynamoDB global tables versions](V2globaltables_versions.md). When you create a global table for the first time, Amazon DynamoDB automatically creates an AWS Identity and Access Management (IAM) service-linked role for you. This role is named [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/DynamoDBReplicationServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/DynamoDBReplicationServiceRolePolicy), and it allows DynamoDB to manage cross-Region replication for global tables on your behalf. Don't delete this service-linked role. If you do, then all of your global tables will no longer function. For more information about service-linked roles, see [Using service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) in the *IAM User Guide*. To create and maintain global tables in DynamoDB, you must have the `dynamodb:CreateGlobalTable` permission to access each of the following: + The replica table that you want to add. + Each existing replica that's already part of the global table. + The global table itself. To update the settings (`UpdateGlobalTableSettings`) for a global table in DynamoDB, you must have the `dynamodb:UpdateGlobalTable`, `dynamodb:DescribeLimits`, `application-autoscaling:DeleteScalingPolicy`, and `application-autoscaling:DeregisterScalableTarget` permissions. The `application-autoscaling:DeleteScalingPolicy` and `application-autoscaling:DeregisterScalableTarget` permissions are required when updating an existing scaling policy. This is so that the global tables service can remove the old scaling policy before attaching the new policy to the table or secondary index. If you use an IAM policy to manage access to one replica table, you should apply an identical policy to all other replicas within that global table. This practice helps you maintain a consistent permissions model across all of the replica tables. By using identical IAM policies on all replicas in a global table, you can also avoid granting unintended read and write access to your global table data. For example, consider a user who has access to only one replica in a global table. If that user can write to this replica, DynamoDB propagates the write to all of the other replica tables. In effect, the user can (indirectly) write to all of the other replicas in the global table. This scenario can be avoided by using consistent IAM policies on all of the replica tables. ## Example: Allow the CreateGlobalTable action Before you can add a replica to a global table, you must have the `dynamodb:CreateGlobalTable` permission for the global table and for each of its replica tables. The following IAM policy grants permissions to allow the `CreateGlobalTable` action on all tables. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["dynamodb:CreateGlobalTable"], "Resource": "*" } ] } ``` ------ ## Example: Allow the UpdateGlobalTable, DescribeLimits, application-autoscaling:DeleteScalingPolicy, and application-autoscaling:DeregisterScalableTarget actions To update the settings (`UpdateGlobalTableSettings`) for a global table in DynamoDB, you must have the `dynamodb:UpdateGlobalTable`, `dynamodb:DescribeLimits`, `application-autoscaling:DeleteScalingPolicy`, and `application-autoscaling:DeregisterScalableTarget` permissions. The following IAM policy grants permissions to allow the `UpdateGlobalTableSettings` action on all tables. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:UpdateGlobalTable", "dynamodb:DescribeLimits", "application-autoscaling:DeleteScalingPolicy", "application-autoscaling:DeregisterScalableTarget" ], "Resource": "*" } ] } ``` ------ ## Example: Allow the CreateGlobalTable action for a specific global table name with replicas allowed in certain regions only The following IAM policy grants permissions to allow the `CreateGlobalTable` action to create a global table named `Customers` with replicas in two Regions. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "dynamodb:CreateGlobalTable", "Resource": [ "arn:aws:dynamodb::123456789012:global-table/Customers", "arn:aws:dynamodb:us-east-1:123456789012:table/Customers", "arn:aws:dynamodb:us-west-1:123456789012:table/Customers" ] } ] } ``` ------