DynamoDB integrates with IAM to control access to both the service and the data in the tables. There will be two types of access for DynamoDB granted to our IAM users:

• Administrative access: IAM users or roles with permissions to create and modify DynamoDB tables
• Data access: IAM users or roles with specific permissions to read, write, update, or delete items in one specific table

When designing your application, you can therefore give the code the ability to provision its own tables; this is very useful when your application works in cycles.

For example, an application that records sessions could be trusted to automatically create a new sessions table at the start of the day, and remove the old sessions table from the previous day. This would keep the DynamoDB table lean and clean as there would never be any session data more than 24 hours old in the table.

The same approach can be used for a sales application that records sales metrics each month. The application could be trusted to create a new table every month with the production capacity units, but maintain the old tables for analytics. Every month it would reduce the previous monthly table's capacity units to whatever would be required for analytics to run.

On the other hand, some applications need only strict access to certain data in a particular DynamoDB table. For example, we can create a role and attach it to a federated identity for a mobile application that uses DynamoDB as a backend catalog. We could very well lock down the application to only that one particular table by adding a deny rule on anything other than the table, to prevent any leaks of data through a potential misconfiguration of the application or AWS security.

To achieve this, we could implement a policy that looks like this:

{
 "Version": "2012-10-17",
 "Statement":[{
 "Effect":"Allow",
 "Action":["dynamodb:*","s3:*"],
 "Resource":["arn:aws:dynamodb:us-east-1:111222333444:table/catalogue"]
 },
 {
 "Effect":"Deny",
 "Action":["dynamodb:*","s3:*"],
 "NotResource":["arn:aws:dynamodb:us-east- 1:111222333444:table/catalogue"] 
 },
 ]
 }

The Allow effect specifies a specific DynamoDB table and the Deny effect specifies anything that is NOT the specific DynamoDB table. This means that, even if any misconfiguration, breach, or fault in the application happens, access to any other table in DynamoDB is explicitly denied and takes precedence over any other allow.

When applying permissions to a DynamoDB table, we should of course always remember the best practice of least privilege when defining permissions, and the practice of using a role for our applications and users.