DynamoDB access control: IAM, resource policies and ABAC
Written by Rafal Wilinski
Last updated: October 23rd, 2026
DynamoDB authorizes API requests with IAM policies, including policies attached to identities and resource-based policies attached to tables or streams. You can restrict actions, tables, index access, partition-key values and requested attributes. Tag-based access control also supports tables, their indexes and streams; it controls resource access, while item-level restrictions use DynamoDB condition keys.
Authentication is separate from authorization
DynamoDB uses signed API requests rather than a database username and password. The AWS SDK signs requests using credentials from its configured credential provider. Prefer temporary credentials: an execution role for Lambda, an instance role for EC2, and IAM Identity Center or an assumed role for developers.
An IAM role is not a policy or a group of database users. Its trust policy controls who can assume it, and its permissions determine what the resulting session can do. Do not use root credentials in an application. Long-lived IAM user keys need lifecycle management and should not be embedded in source code or distributed to workloads that can use roles.
A local credential helper can manage sessions, but it does not bypass IAM. First confirm the identity and Region used by the actual process. Testing successfully with an administrator's CLI profile says nothing about whether a deployed function's role is authorized.
Which policy controls which resource?
| Policy or control | Where it lives | Purpose |
|---|---|---|
| Identity-based policy | User, group or role | Grants an identity actions on named resources |
| Table resource policy | DynamoDB table | Grants named principals access, including access to listed indexes |
| Stream resource policy | DynamoDB stream | Controls access to that stream separately |
| ABAC condition | IAM policy condition | Matches resource tags to allowed values or principal tags |
| VPC endpoint policy | Gateway or interface endpoint | Restricts requests traveling through that endpoint |
| Organization policy or permissions boundary | Organization or identity boundary | Limits permissions otherwise available |
For same-account requests, identity and resource policies participate in IAM's evaluation rules; it is not always necessary to duplicate an allow in both. Cross-account access requires permission on both sides. Explicit denies and applicable organization controls still matter. An endpoint policy is an extra boundary, not an independent credential or a substitute for IAM authorization.
A read-only DynamoDB policy
This example allows table discovery and read access to Orders and its indexes. Replace the account, Region and table names before using it.
ListTables exposes names across the account and Region, so omit that statement if the application already knows its table. Scan permits reading the entire allowed resource and consumes read capacity; remove it when the workload only needs key-based reads. Use a named index ARN instead of index/* when only one index is required.
A table ARN does not automatically cover every child resource. Index ARNs and stream ARNs have different suffixes. Check the DynamoDB action and resource reference for each API, including actions that require Resource: "*".
Give Lambda and EC2 access through roles
For Lambda, open the function's configuration, find its execution role and add a scoped permissions policy to that role. Changing the role's trust policy alone does not grant table access. The Lambda permissions guide includes a complete Terraform setup and SDK v3 handler.
For EC2, attach an instance profile containing an appropriate IAM role. The SDK retrieves temporary credentials through its provider chain. Avoid placing an administrator's credentials in ~/.aws on the instance: those can take precedence over the intended role and make permission tests misleading.
Serverless Framework example
The current provider-level IAM structure uses provider.iam.role.statements. This configuration grants reads from one existing table to functions using that shared role:
The handler and table must exist for deployment. A shared provider role means all functions using it inherit the permission; split roles when functions have different responsibilities. See the Serverless IAM documentation for function-specific role configuration.
Resource-based policies and cross-account access
Attach a policy to the table when another account's role needs direct access. This example grants only GetItem to the named role:
Save it as orders-resource-policy.json, then attach it with AWS CLI v2:
The caller role in the other account also needs an identity policy permitting GetItem on this ARN. In its API call, pass the full table ARN as TableName. Granting a role access in a resource policy does not make it assume a role in the table's account.
A table policy can include the table's index ARNs when granting index operations. Streams have their own policies, attached to existing streams. Recreating a stream creates a different resource, so review its policy and consumers. Resource-policy cross-account access does not work with the AWS managed encryption key; plan supported key access before sharing a table. AWS lists these resource-policy considerations.
Item-level access with dynamodb:LeadingKeys
dynamodb:LeadingKeys checks partition-key values. It does not refer to the first letters of the attribute name, and it does not provide arbitrary filtering by a non-key tenant field. Design keys so that the authorization boundary can be expressed in the partition key.
For a dedicated tenant role, this policy permits reads and queries only under TENANT#123 in a table with partition key pk:
Use ForAllValues for the multivalued condition key, and validate that the context key is present. Do not add Scan as a fallback: it does not support this partition-key condition. Also check every index access path. An index that groups orders by status across tenants needs its own authorization analysis before it is exposed to tenant readers.
If a single Lambda role handles every tenant, IAM sees that same role on each request. Authenticate users and enforce tenant boundaries in application code, or deliberately issue appropriately scoped sessions. A client-provided tenant ID is not trusted identity evidence.
Attribute-level restrictions with Attributes and Select
A policy can limit the attributes a request accesses. For example, a game leaderboard may expose UserId, GameTitle and TopScore while excluding email addresses. Use dynamodb:Attributes with an allowlist that includes required table and index keys, and constrain dynamodb:Select to SPECIFIC_ATTRIBUTES for applicable reads.
This condition fragment illustrates the combination for a read-only statement:
The client must request the allowed projection; IAM is not an automatic redaction layer that silently removes forbidden fields from an unrestricted request. Test omitted projections, index queries and attempts to request disallowed fields. For write policies, also review dynamodb:ReturnValues, because a permitted update must not return hidden attributes. PutItem replaces the whole item, so it is unsuitable when a writer may update only selected fields. Use the complete AWS fine-grained policy examples for the actions you expose.
ABAC: control resources with tags
DynamoDB supports attribute-based access control for tables and indexes. Indexes inherit the table's tags. For example, a read policy can require aws:ResourceTag/Environment to equal staging, or match a project tag on a resource to a trusted principal tag. Use the aws: tag condition keys, not an invented dynamodb:ResourceTag condition.
Resource tags are different from item attributes. ABAC can select an entire team's tables; LeadingKeys can restrict partitions inside a shared table. Neither substitutes for the other. Protect TagResource, UntagResource and the ability to set session tags, or a caller might change the attributes used to authorize itself.
Most accounts have table ABAC enabled by default; check account and Region settings before depending on it. Streams also support ABAC, but stream tags are separate from table tags and existing customers must check the Streams opt-in setting. A restored table needs its tags reapplied before tag-based permissions behave as intended. See ABAC configuration.
Endpoint policies and operational checks
Use a VPC endpoint policy to limit which principals, actions and resources can use that network path. It does not block access through every other path unless your identity or resource policies enforce that additional requirement. Test console access, service integrations and recovery tooling before applying an endpoint-only deny.
Keep deployment permissions separate from runtime permissions. Enable CloudTrail data events explicitly when you need an audit record of item reads and writes; management event history alone is not a complete data-access log. For the broader controls, including default encryption and recovery, use the security checklist.
Permissions for Dynobase
Dynobase uses the credentials from your configured AWS connection. Start with the read-only operations above for browsing, and add PutItem, UpdateItem, DeleteItem or BatchWriteItem only when users need those operations. PartiQL and administrative features need their corresponding permissions too; a single read/write label cannot capture every feature's requirements.
For example, table management includes tags, indexes and resource policies, which require additional administrative actions. Keep a separate role for those tasks instead of granting every desktop user broad administration. UI settings are useful workflow aids, but IAM remains the permission boundary.
Frequently Asked Questions
Does DynamoDB support resource-based policies?
What does dynamodb:LeadingKeys mean?
Does DynamoDB support row-level security?
Can IAM hide individual attributes?
Does DynamoDB support ABAC?
Dynobase is a Professional GUI Client for DynamoDB
Start your 7-day free trial today