DynamoDB global tables security - Amazon DynamoDB
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).

DynamoDB global tables security

Global tables replicas are DynamoDB tables, so you use the same methods for controlling access to replicas that you do for single-Region tables, including Amazon Identity and Access Management (IAM) identity policies and resource-based policies.

How global tables use Amazon IAM

Replication service-linked role

When you create a global table for the first time, Amazon DynamoDB automatically creates an Amazon Identity and Access Management (IAM) service-linked role (SLR). The SLR is named AWSServiceRoleForDynamoDBReplication, and it allows DynamoDB to manage cross-Region replication for global tables on your behalf.

When applying resource-based policies to replicas, ensure that you don't deny any of the permissions defined in the AWSServiceRoleForDynamoDBReplication policy to the SLR principal, as this will interrupt replication. If you deny required SLR permissions, replication to and from affected replicas will stop, and the replica table status will change to REPLICATION_NOT_AUTHORIZED.

  • If a replica in a global table configured for multi-Region eventual consistency (MREC) remains in the REPLICATION_NOT_AUTHORIZED state for more than 20 hours, the replica is irreversibly converted to a single-Region DynamoDB table.

  • Global table replicas configured for multi-Region strong consistency (MRSC) return an AccessDeniedException for write and strongly consistent read operations. If a replica in a MRSC global table remains in the REPLICATION_NOT_AUTHORIZED state for more than seven days, the replica becomes permanently inaccessible, and write and strongly consistent read operations will continue to fail with an error. Some management operations like replica deletion will succeed.

Auto scaling service-linked role

When you configure a global table for provisioned capacity mode, you must also configure auto scaling for the global table. DynamoDB auto scaling uses the Amazon Application Auto Scaling Service to dynamically adjust provisioned throughput capacity on your global table replicas. The Application Auto Scaling service creates a service-linked role (SLR) named AWSServiceRoleForApplicationAutoScaling_DynamoDBTable to manage provisioned table capacity and create CloudWatch alarms. When applying resource-based policies to replicas, ensure that you don't deny any of the permissions defined in the AWSServiceRoleForApplicationAutoScaling_DynamoDBTable policy to the Application Auto Scaling Service SLR principal, as this will interrupt auto scaling functionality.

For more information about service-linked roles, see Using service-linked roles in the IAM User Guide.

Required permissions for global tables

To create a replica, you must have the following permission on the table or replica to which you are adding new replicas:

  • dynamodb:UpdateTable

To create a replica, you must have the following permissions in each Region where a new replica will be created:

  • dynamodb:CreateTable

  • dynamodb:CreateTableReplica

To create a witness, you must have the following permission in the Region where a new witness will be created:

  • dynamodb:CreateGlobalTableWitness

To delete a replica, you must have the following permissions on the replica:

  • dynamodb:DeleteTable

  • dynamodb:DeleteTableReplica

To delete a witness, you must have the following permissions on the witness:

  • dynamodb:DeleteGlobalTableWitness

To update a replica auto scaling policy with the UpdateTableReplicaAutoScaling API, you must have the following permissions in all Regions containing replicas:

  • application-autoscaling:DeleteScalingPolicy

  • application-autoscaling:DeleteScheduledAction

  • application-autoscaling:DeregisterScalableTarget

  • application-autoscaling:DescribeScalableTargets

  • application-autoscaling:DescribeScalingActivities

  • application-autoscaling:DescribeScalingPolicies

  • application-autoscaling:DescribeScheduledActions

  • application-autoscaling:PutScalingPolicy

  • application-autoscaling:PutScheduledAction

  • application-autoscaling:RegisterScalableTarget

To update Time to Live settings with the UpdateTimeToLive API, you must have the following permission on all replicas:

  • dynamodb:UpdateTimeToLive

Example IAM policies

Example: Manage a global table

The following IAM policy grants permissions to create and delete global table replicas and witnesses for the "users" table in three Regions:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowManagingUsersGlobalTable", "Effect": "Allow", "Action": [ "dynamodb:CreateTable", "dynamodb:CreateTableReplica", "dynamodb:CreateGlobalTableWitness", "dynamodb:DeleteTable", "dynamodb:DeleteTableReplica", "dynamodb:DeleteGlobalTableWitness", "dynamodb:UpdateTable", "dynamodb:UpdateTimeToLive" ], "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/users", "arn:aws:dynamodb:us-east-2:123456789012:table/users", "arn:aws:dynamodb:us-west-2:123456789012:table/users" ] } ] }

Example: Exclude required SLR permissions from wildcard deny policies

An IAM policy with the following condition does not impact required permissions to the DynamoDB replication SLR and Amazon Auto Scaling SLR. This condition can be added to otherwise broadly restrictive policies to avoid unintentionally interrupting replication or auto scaling:

"Condition": { "StringNotEquals": { "aws:PrincipalArn": [ "arn:aws:iam::YOUR_ACCOUNT_ID:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication", "arn:aws:iam::YOUR_ACCOUNT_ID:role/aws-service-role/dynamodb.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_DynamoDBTable" ] } }

How global tables use Amazon KMS

Like all DynamoDB tables, global tables replicas always encrypt data at rest using encryption keys stored in Amazon Key Management Service (Amazon KMS).

All replicas in a global table must be configured with the same type of KMS key (Amazon owned key, Amazon managed key, or Customer managed key).

Important

DynamoDB requires access to the replica's encryption key to delete a replica. If you want to disable or delete a customer managed key used to encrypt a replica because you are deleting the replica, you should first delete the replica, wait for the table status on one of the remaining replicas to change to ACTIVE, then disable or delete the key.

For a global table configured for multi-Region eventual consistency (MREC), if you disable or revoke DynamoDB's access to a customer managed key used to encrypt a replica, replication to and from the replica will stop and the replica status will change to INACCESSIBLE_ENCRYPTION_CREDENTIALS. If a replica in a MREC global table remains in the INACCESSIBLE_ENCRYPTION_CREDENTIALS state for more than 20 hours, the replica is irreversibly converted to a single-Region DynamoDB table.

For a global table configured for multi-Region strong consistency (MRSC), if you disable or revoke DynamoDB's access to a customer managed key used to encrypt a replica, replication to and from the replica will stop, attempts to perform write or strongly consistent reads to the replica will return an error, and the replica status will change to INACCESSIBLE_ENCRYPTION_CREDENTIALS. If a replica in a MRSC global table remains in the INACCESSIBLE_ENCRYPTION_CREDENTIALS state for more than seven days, depending on the specific permissions revoked the replica will be archived or become permanently inaccessible.