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
When applying resource-based policies to replicas, ensure that you don't deny any
of the permissions defined in the AWSServiceRoleForDynamoDBReplication
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 theREPLICATION_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.