Controlling Access to Amazon DynamoDB Resources

In this example, we create a policy that lets the group use any operation on any of the AWS Account's tables.

{
   "Statement":[{
      "Effect":"Allow",
      "Action":"dynamodb:*",
      "Resource":"*"
      }
   ]
}

In this example, we create a policy that lets the group use only the GetItem and BatchGetItem operations with any of the AWS Account's tables.

{
   "Statement":[{
      "Effect":"Allow",
      "Action":["dynamodb:GetItem","dynamodb:BatchGetItem"],
      "Resource":"*"
      }
   ]
}

In this example, we create a policy that lets the recipient use the PutItem, UpdateItem and DeleteItem actions with a table named "books_table", which is owned by AWS Account number 123456789.

{
   "Statement":[{
      "Effect":"Allow",
      "Action":["dynamodb:PutItem",​"dynamodb:UpdateItem",​"dynamodb:DeleteItem"],
      "Resource":"arn:aws:dynamodb:us-west-2:123456789:table/books_table"
      }
   ]
}

IAM Roles provide a way to share a table with another AWS Account. For details on creating a Role and granting access to another AWS Account, see Roles in the IAM documentation.

In this example, we create an IAM Role for the partner, and create a policy for the Role that gives access to all the operations except those that edit data; essentially, they have read-only access. Attach the following policy to the IAM Role:

{
   "Statement":[{
         "Effect":"Allow",
         "Action":["dynamodb:ListTables", "dynamodb:DescribeTable", "dynamodb:GetItem", "dynamodb:BatchGetItem",
             "dynamodb:Query", "dynamodb:Scan"],
         "Resource":"*"
      }
   ]
}

Suppose you maintain separate production and test environments where each environment maintains its own version of a table named ProductCatalog . If you create these tables from the same AWS account, testing work might affect the production environment, because, for example, the limits on concurrent create and delete operations are set at the AWS account level. As a result, each operation in the test environment reduces the number of operations that are available in your production environment. There is also a risk that the code in your test environment might accidentally access tables in the production environment. To prevent these issues, you might consider creating separate AWS accounts for the production and testing.

Suppose further that you have two developers, Bob and Alice, who are testing the ProductCatalog table. Instead of creating a separate AWS account for every developer, your developers can share the same test account. You might create a copy of the same table for each developer, such as Bob_ProductCatalog and Alice_ProductCatalog . In this case, you can create IAM users Bob and Alice in the AWS account that you created for the test environment. You can then allow these users to perform DynamoDB actions on to the tables that they own. You have the following policy options to grant the user permissions:

Note that, instead of identifying a specific table as a resource, you could use a wild card (*) to grant permissions on all tables whose name is prefixed with the name of the IAM user who is logged making the request.

"Resource":"arn:aws:dynamodb:us-west-2:123456789:table/${aws:username}_*"

You may want to limit access of one of your Users to a specific table and its indexes.

In this example, we create an IAM User and create a policy for the User that gives access to all operations on the table named "books_table" and all of its indexes. To test this policy in your own environment, you will need to replace the example account ID "123456789" with your AWS account ID.

{
   "Statement":[{
         "Effect":"Allow",
         "Action":["dynamodb:*"],
         "Resource": ["arn:aws:dynamodb:us-west-2:123456789:table/books_table", 
                      "arn:aws:dynamodb:us-west-2:123456789:table/books_table/index/*"]
      }
   ]
}