DynamoDB IAM policy constraints and STS credential expiry symptoms

A multi-tenant architecture utilizes IAM roles and temporary STS credentials to access DynamoDB tables. The design goal is least-privilege access, restricting actions like GetItem, PutItem, and Query to specific table and index ARNs using Signature Version 4 authentication.

There is uncertainty regarding the boundary between infrastructure-level security and application logic. While dynamodb:LeadingKeys can provide partition-key scoping for tenant isolation, the level of support for these condition keys varies across different API actions, potentially creating inconsistencies between a constrained GetItem call and a Query operation.

Additionally, long-running processes using temporary credentials may encounter authorization failures. It is necessary to distinguish between errors caused by expired security tokens and those caused by genuine policy denials or clock skew, as both can manifest as access failures at the client level.

Technical Questions

• How can expired STS token failures be reliably distinguished from AccessDeniedException events using CloudTrail data-plane logs?
• At what point of policy complexity does tenant isolation shift from being viable via IAM condition keys to requiring application-level authorization?
• What is the recommended method to verify that a least-privilege policy consistently constrains Query and Scan actions as intended?