Use a custom policy limited to the specific DynamoDB tables, indexes, and read actions the application needs. AmazonDynamoDBReadOnlyAccess is usually wider than necessary for production access, especially for multi-table environments. Restrict it to exact resources, then verify that requests fail safely when a table is not in scope.
Why least privilege matters for DynamoDB read access
For DynamoDB, the real question is not whether a policy can read data, but whether it can read only the data path the application actually uses. A broad read-only managed policy is convenient, but it often grants access across more tables, indexes, and account resources than a single workload needs. Least privilege keeps the blast radius small if the credentials are misused or copied elsewhere.
That distinction matters because DynamoDB permissions are usually consumed by application roles, automation, or service identities that can be reused quietly once issued. The tighter the resource scope, the less room there is for accidental data exposure, cross-environment reads, or privilege creep as the application grows.
When you are deciding scope, treat the policy as part of the application contract. If the app only reads one table and one index, the policy should name only those resources and only the read actions that are actually required, rather than inheriting a generic read set that may be valid in many other contexts.
What a least-privilege DynamoDB policy should contain
A good replacement for the managed read-only policy is a customer-managed policy built around exact DynamoDB table ARNs and, where needed, the specific index ARNs that the workload queries. That is the practical way to reduce unnecessary access while preserving the read paths the application depends on. Use the narrowest resource list that still allows the application to function, and avoid granting access to tables that are only convenient during testing or troubleshooting.
For teams that want a broader IAM reference point, the policy design should follow the same logic explained in the AWS IAM Policies and Roles Guide: define the resource scope first, then evaluate whether the action set is still minimal. In practice, that means keeping the policy readable enough that another engineer can tell which tables are in bounds without reverse-engineering a long list of wildcard permissions.
If the workload depends on multiple tables, split access by function rather than bundling everything into one reusable read policy. That makes it easier to spot when a new table is added without review, and it makes any later access review much more meaningful because the scope maps back to a business function rather than a generic environment role.
How to validate that the policy is really least privilege
The strongest test is behavioral, not theoretical. After you tighten the policy, verify that the application can still read the intended tables and that requests to anything outside scope fail safely. That is the point where you confirm the policy is doing useful work rather than just looking narrower on paper.
It is also worth using the same discipline that applies to IAM and IGA Basics: access should be reviewed against actual usage, not against a hope that the application may need broader access later. If the application team cannot explain why a table or index is included, that access usually deserves a second look.
For operational governance, the policy should be owned by the team that understands the workload’s read path, not by a platform team working from a template. The most common failure mode is policy sprawl, where each new feature quietly inherits broad read permissions because no one wants to break production during deployment.
Risk and Threat Considerations
Broad read access increases exposure if the role is stolen, reused, or attached to a different workload. In multi-table environments, the problem is not just excess permissions in the abstract, but the possibility that one compromised application credential can read data from tables the original app never needed.
Failure mechanism: A managed read-only policy grants more DynamoDB scope than the workload requires, so a compromised or misapplied role can query additional tables or indexes without triggering an obvious authorization failure.
Impact: Sensitive records, tenant data, or operational metadata can be exposed beyond the intended application boundary, and later forensic review becomes harder because the credential was legitimately allowed to read more than it should have.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | DynamoDB read scope should be minimized to only needed resources and actions. |
| Recommendation — Limit DynamoDB access to the minimum tables, indexes, and read actions required. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about narrowing permitted access to data resources. |
| Recommendation — Define and enforce explicit access rules for each DynamoDB resource. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Least-privilege replacement policies are an access control management task. |
| Recommendation — Review and right-size identity access to DynamoDB data paths. | ||
Practitioner Guidance
What to verify: Confirm the exact tables and indexes the application touches in production, then compare that list to the policy document line by line. If you cannot explain why a resource is included, remove it and retest.
Decision rule: If the workload reads from a bounded set of DynamoDB resources, use a customer-managed policy with explicit resource ARNs and only the required read actions. If the application team needs broader access for debugging, treat that as a temporary exception, not the default policy.
Practitioner takeaway: Least privilege for DynamoDB is proven by scope and failure testing, not by the label on the AWS managed policy.
Related resources from NHI Mgmt Group
- What should be used instead of the AWS AmazonBedrockLimitedAccess managed policy for least privilege?
- What should be used instead of the AWS AmazonDynamoDBFullAccess managed policy for least privilege?
- What should be used instead of the AWS AmazonBedrockReadOnly managed policy for least privilege?
- What should be used instead of the AWS AmazonEKSVPCResourceController managed policy for least privilege?