Amazon DynamoDB Security: IAM Access, Encryption, Logging and Recovery Explained

Amazon DynamoDB has no database logins, no network listener you manage and no admin console of its own: every read and write is an AWS API call, so whoever holds the right IAM credential holds the data. That shifts DynamoDB security away from passwords and firewalls and towards IAM policy design, fine-grained conditions, key management, CloudTrail data events and recovery settings that teams often switch on too late. This guide is for cloud engineers, application developers and security teams who build on DynamoDB. It covers how identity-based and resource-based policies combine, item-level access with condition keys, the roles and credentials that applications use, encryption choices, logging and detection, and a baseline you can apply table by table. General database principles are in the Database Security Guide.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.

Key takeaways

• IAM is the database access layer. Grant table and index access to roles with least-privilege actions and resource ARNs; avoid dynamodb:* on *.
• Item-level control is possible but has traps. dynamodb:LeadingKeys limits users to their own partition, yet Scan is not constrained by it unless you add a Null condition, and attribute limits need Select and ReturnValues limits too.
• Data events are off by default. CloudTrail logs table management automatically but not GetItem, Query, Scan or PutItem; enable data events with advanced event selectors for sensitive tables.
• Encryption at rest is always on, but the key choice matters. The default AWS owned key gives no visibility; a customer managed KMS key adds key policy control and CloudTrail records of key use.
• Turn on recovery controls before you need them. Deletion protection, point-in-time recovery (1 to 35 days) and backup plans are what stand between a stolen credential and permanent data loss.

How identity and access work in DynamoDB

Every request is signed with AWS credentials and authorised by IAM. There are no usernames inside DynamoDB. Access is decided by the combination of policies that apply to the caller and the resource.

Fine-grained access with condition keys

DynamoDB supports item and attribute level control through IAM conditions. This is how mobile and web applications that call DynamoDB with federated credentials keep each user to their own data.

• Whole-item writes: AWS advises against allowing PutItem, DeleteItem and BatchWriteItem where you limit attributes, because they replace whole items and can remove attributes the caller cannot see. Use UpdateItem.
• Key attributes: when using dynamodb:Attributes, list the primary key and index key attributes or requests fail.
• Allow lists over deny lists: AWS recommends allow-based policies, which are easier to get right and less brittle as the API changes.
• Global tables: do not apply these conditions to the service principals or service-linked roles used for replication, or replication can break.

Admin roles and privileged access

The dangerous DynamoDB permissions are the ones that change or destroy tables and their recovery settings, not only those that read data.

• Humans read through roles: engineers who need production data should assume a time-bound read role through IAM Identity Center, with data events logged, not hold standing access. See the AWS IAM Identity Center Guide.
• Separate the pipeline from the application: the role that runs CloudFormation or CDK owns table lifecycle; the runtime role only gets item operations. See the AWS IAM Policies and Roles Guide.
• Customer managed keys: when tables use a customer managed KMS key, the key policy becomes a second gate. Key administrators who can disable or schedule deletion of the key can make the table unreadable, so separate key administration from table administration. See the AWS KMS Security Guide.

Integrations, API tokens and service accounts

DynamoDB is almost always accessed by non-human identities: Lambda functions, containers, EC2 instances and federated mobile clients. AWS's own guidance is to use IAM roles with temporary credentials rather than store long-term access keys in applications.

• Compute roles: Lambda execution roles, ECS task roles and EC2 instance profiles each get a policy for the specific tables and actions that workload needs. One role per function or service limits the blast radius. See the AWS Lambda Security Guide.
• No static keys in clients: mobile and browser applications should obtain short-lived credentials (for example from Amazon Cognito identity pools) bound to a LeadingKeys policy, never embedded access keys.
• Long-term keys that do exist: local tools, third-party integrations and legacy jobs with IAM user keys are the highest risk route to bulk Scan and export (T1078.004). Replace them with roles, or scope and rotate them. See the AWS Access Keys Security Guide.
• Cross-account consumers: prefer a resource-based policy naming the exact consuming role, or a role in your account they assume, and review findings from IAM Access Analyzer external access analysers. See the IAM Access Analyzer Guide.
• Streams consumers: DynamoDB Streams carry item changes, often including full images of sensitive records. Treat stream read permissions (GetRecords, GetShardIterator) as data read permissions, and attach resource-based policies to streams where consumers are in other accounts.
• Secrets stored in items: DynamoDB is sometimes used as a cheap token or session store. If you store secrets, tokens or personal data, encrypt the attributes client side with the AWS Database Encryption SDK for DynamoDB, which encrypts and signs selected attributes before they leave the application.

Encryption choices

Encryption at rest covers table data including the primary key, local and global secondary indexes, streams, global tables, backups and DAX clusters. AWS notes that some sort key values marking range boundaries are kept in plaintext in table metadata, and its security best practices warn against sensitive data in primary key or GSI key names or values, because names appear in DescribeTable and values can appear in CloudTrail and other logs. Use generic names such as pk and sk and keep personal data out of keys.

Logging and detection

CloudTrail records control plane events (CreateTable, DeleteTable, UpdateTable, backup and restore calls, UpdateTimeToLive) by default. Data plane events must be enabled on a trail, filtered with advanced event selectors on AWS::DynamoDB::Table or AWS::DynamoDB::Stream. Selecting the table type also logs stream calls unless you exclude them, and filtering out userIdentity.arn values starting with AWSServiceRoleFor removes internal replication noise. TTL deletions are not logged. See the AWS CloudTrail Guide.

AWS also suggests recording DynamoDB resource types in AWS Config, tagging tables (for example Confidentiality and Environment) so controls can target sensitive data, and using DynamoDB Streams with Lambda to react to sensitive item changes. See the AWS Config Guide.

Metrics

• Data event coverage: percentage of tables tagged sensitive that have CloudTrail data events enabled.
• Recovery coverage: tables with PITR, deletion protection and an AWS Backup plan (Security Hub DynamoDB.2, .4 and .6 pass rate).
• Policy breadth: IAM policies granting dynamodb:* or Resource: *, trending to zero.
• Key control: sensitive tables encrypted with a customer managed key.
• Static credentials: IAM user access keys with DynamoDB permissions, and their age.

Hardening baseline

Rollout order

1. Inventory: list tables per account and Region with their key type, PITR, deletion protection, resource policy and classification tag.
2. Protect against loss first: enable deletion protection and PITR on production tables, and add them to a backup plan. These changes do not affect application traffic.
3. Turn on visibility: enable CloudTrail data events for sensitive tables, with advanced selectors to control cost, and the Security Hub DynamoDB controls.
4. Tighten IAM: use IAM Access Analyzer policy generation or last-accessed information to replace broad DynamoDB permissions with table-scoped actions, testing in a non-production account first.
5. Move keys: switch sensitive tables to customer managed keys (the key can be changed on an existing table) after writing the key policy and confirming every consuming role has KMS permissions.
6. Add network conditions carefully: a broad deny on aws:SourceVpce can also block console and pipeline access, so exempt the admin and deployment roles and test in audit first by reviewing CloudTrail for calls that would fail.
7. Roll back IAM and resource policy changes from version history in your infrastructure as code; a deleted table with PITR enabled leaves a system backup (table-name$DeletedTableBackup) retained for 35 days.

Common misconfigurations

• Wildcard application roles: Lambda or container roles with dynamodb:* on all tables, so one injection bug exposes every table in the account.
• LeadingKeys without a Scan guard: a per-user policy that still lets a client Scan the whole table.
• No data events: after a credential leak, the team cannot tell which items were read because only management events were logged.
• PITR off or too short: PITR disabled, or the recovery period reduced, which drops older restore points immediately.
• Personal data in keys: email addresses or national identifiers as partition keys, which then appear in logs and metadata.
• Static keys in front ends: access keys in mobile apps or JavaScript bundles with write access to a table.

Framework mapping

Practitioner checklist

• Give each workload its own role with table-scoped DynamoDB actions; remove dynamodb:* and Resource: *.
• Use LeadingKeys with a Null guard, Select and ReturnValues limits for any client-facing federated access.
• Enable deletion protection, PITR and an AWS Backup plan on every production table.
• Enable CloudTrail data events for sensitive tables and alert on DeleteTable, PITR changes and resource policy changes.
• Use customer managed KMS keys for sensitive tables and separate key administration from table administration.
• Keep personal data and secrets out of primary and index keys; encrypt sensitive attributes client side.
• Replace static access keys with roles and short-lived credentials, especially in mobile and browser clients.
• Review resource-based policies and IAM Access Analyzer external access findings at least monthly.

Standards and references

• AWS: Preventative security best practices for DynamoDB
• AWS: Using IAM policy conditions for fine-grained access control in DynamoDB
• AWS: Using resource-based policies for DynamoDB
• AWS: DynamoDB encryption at rest
• AWS: Logging DynamoDB operations by using AWS CloudTrail
• AWS: Point-in-time recovery for DynamoDB
• AWS: Security Hub CSPM controls for DynamoDB
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Database Security Guide · AWS IAM Policies and Roles Guide · AWS KMS Security Guide · AWS Backup Security Guide