12 DynamoDB security practices for production

DynamoDB security combines IAM authorization, encryption, network controls, auditing and recoverable backups. Table data is encrypted at rest automatically, and AWS SDKs use HTTPS by default. Your main responsibilities are deciding who may access which data, detecting misuse, protecting keys and backups, and proving that the application can recover from destructive changes.

Know what AWS manages and what you configure

AWS operates the DynamoDB infrastructure. You control application identities, authorization rules, data handling and recovery configuration. AWS service compliance does not automatically make an application compliant: its data classification, access decisions and operating procedures still need to meet the organization's requirements. The DynamoDB security documentation explains this shared responsibility and links to current compliance scope.

For an initial review, inventory production tables, replicas, indexes, streams, caches and backups. Identify their owners, the roles that can read them, the roles that can modify them and the identities that can change their security settings. A table with restricted item reads can still be exposed through a broad export permission or an accessible backup.

Common security mistakes to correct first

Twelve practical controls

1. Use temporary credentials for people and applications

Use IAM Identity Center or an approved role-assumption workflow for human access. Give workloads service roles, such as a Lambda execution role or EC2 instance role. Keep deployment identities separate from runtime identities, and restrict who can pass or assume privileged roles.

Do not put AWS access keys in application source, container images or copied environment files. Removing a key from a repository does not revoke it; credential response must address the actual identity. For human administration, use MFA and an access process appropriate to the account's risk.

2. Grant only the actions and resources the workload needs

List the application's real operations. Reading an order by its key needs GetItem; it does not require Scan, DeleteTable or permission to create exports. Scope the policy to the intended table, include index ARNs only when needed, and review broad patterns that automatically cover future tables.

Treat permissions to change policies, tags, encryption or backups as administrative. The replacement full-access managed policy, AmazonDynamoDBFullAccess_v2, is still broad access even though it is narrower than the deprecated original. Use the Lambda permission examples to build an application role instead.

3. Design item and attribute authorization explicitly

DynamoDB can enforce partition-key restrictions through dynamodb:LeadingKeys and attribute restrictions through supported IAM conditions. This is often described as row-level or column-level security, but it is based on API authorization and key design, not SQL row policies.

Cognito and federation can supply identities for scoped sessions, but Cognito is not required. A shared backend role does not become a different IAM identity for each user request. Test that one tenant cannot fetch another tenant's key, query an alternate index or request a forbidden attribute. The access-control guide covers those boundaries.

4. Review resource policies, tags and cross-account grants

Inspect both identity policies and the policies on tables and streams. Resource-based policies can intentionally grant another account access, so review the principal, action and resource rather than assuming “outside the account” always means denied. Use IAM Access Analyzer findings to investigate external access.

Use meaningful tags such as Environment, Owner and Project. ABAC can authorize access based on these tags, which makes tag-changing permissions security-sensitive. Streams have separate tags; table tagging alone is not a complete Streams policy. Define how restored tables receive their required tags before applications use them.

5. Choose the right encryption-key ownership

Every DynamoDB table is encrypted at rest. Keep the AWS owned default when it meets the requirement; choose an AWS managed or customer managed key when you need the corresponding auditability or lifecycle controls. A customer managed key is not automatically safer if nobody maintains its policy or recovery dependencies.

Monitor key disablement, deletion scheduling and policy changes. Check retained backups before retiring a key. Review DAX separately because it has cluster encryption settings and does not use a customer managed cluster key. The encryption guide separates table encryption, TLS and client-side protection.

6. Preserve TLS and evaluate client-side encryption

The normal SDK and CLI connection uses HTTPS. Keep certificate verification enabled, including behind corporate proxies and when using private endpoints. Fix trust-store or endpoint configuration problems rather than disabling verification.

Use the AWS Database Encryption SDK for DynamoDB when protected values need to remain ciphertext inside the database. This changes application serialization, querying and migration requirements. Inventory every reader and writer before deployment; an operational script that bypasses the encryption layer can produce records the main application cannot safely process.

7. Use the network path your architecture requires

A gateway endpoint provides private DynamoDB access from the associated VPC route tables without a NAT path. Interface endpoints provide PrivateLink connectivity for cases such as on-premises clients. Streams use separate interface endpoints. Security groups apply to interface endpoint network interfaces and DAX clusters, not directly to DynamoDB tables.

Endpoint policies restrict traffic through that endpoint. They do not automatically prevent the same principal from reaching a public service endpoint elsewhere. Review identity and resource policies if endpoint-only access is a requirement, and preserve intended service integrations. See the VPC endpoint guide for setup and troubleshooting.

8. Audit API access with CloudTrail

Record management activity such as table changes, backup deletion and policy updates. If item reads and writes must be audited, configure DynamoDB data events explicitly. Do not assume that the management event history already records every GetItem or PutItem.

Choose event selectors and retention that fit the investigation requirements and expected volume. Protect the audit destination from the same application identities whose activity it records. Test a known action and confirm the expected identity and resource appear in the logs. AWS documents the distinction in DynamoDB CloudTrail logging.

9. Use Streams for change-driven detection

Streams can feed checks for suspicious item changes, unexpected deletes or changes to sensitive state. They are useful for reacting to data changes and building an archive, but they are not a complete identity audit or a permanent backup.

Make consumers idempotent, handle failed records and monitor processing delay. A detector that silently falls behind can miss the point when its evidence is no longer available. Protect the consumer's destination and permissions too; forwarding sensitive item images can create another data store that needs equivalent controls.

10. Detect configuration drift and assign an owner

Use AWS Config and security checks to detect departures from approved settings. Suitable checks include PITR, backup-plan coverage, deletion protection and DAX encryption. Security Hub's DynamoDB controls map these concerns to specific evaluations.

Send actionable findings to an owner, with the resource, expected setting and remediation path. Do not call every change an incident, and do not let a compliance dashboard substitute for fixing a failed control. Keep intended settings in infrastructure as code and review drift after emergency changes.

11. Protect against accidental and malicious deletion

Enable table deletion protection for production resources. Restrict who can disable it and who can delete backups, change backup retention or remove encryption keys. Deletion protection blocks table deletion, but it does not stop DeleteItem, destructive batch writes or an authorized administrator from first changing the protection setting.

For global tables, review each replica's settings instead of assuming every protective setting propagates. Separate backup administration from the application role so a compromised writer cannot also destroy recovery points.

12. Maintain and test historical recovery

Enable PITR where recovery from a recent bad write is required, and use retained backups for longer history and account or Region isolation. Define an acceptable recovery point and recovery time for each application, then measure a restore exercise against them.

A successful restore creates data in a new table; the application still needs permissions, routing, settings and validation. Include tags, TTL, streams, alarms, scaling and backup configuration in the runbook. The disaster recovery guide connects those checks to PITR, AWS Backup and global tables.

What evidence should a security review produce?

A useful review ends with testable evidence: a successful permitted request, a denied cross-tenant request, an audit event, a detected configuration change and a verified recovery exercise. Record who owns unresolved findings and when they will be checked again.

Start with the controls that prevent the largest avoidable exposure in your deployment. For a shared SaaS table, tenant authorization and broad read grants may dominate. For an operations account, backup deletion and key administration may be more consequential. Keep this overview as the checklist and the linked guides as implementation references.