Cross-account access connects identities and resources across independently administered cloud accounts. Typical examples include a deployment pipeline updating production infrastructure, a security team inspecting application accounts, and an analytics application reading data owned by another business unit. The objective is to preserve account isolation while granting specific capabilities to identified callers under defined conditions. Network connectivity alone does not provide this authorization, and belonging to the same organization does not automatically establish access.
Two common implementation patterns are assuming a role in the destination account and granting an external principal access through a resource policy. With role assumption, the caller obtains temporary credentials representing a destination-account role. With direct resource access, the caller keeps its existing identity while the resource owner authorizes it. Choose according to the service's policy support, the operations required, and whether centralized destination-account permissions simplify administration.
In AWS, cross-account role assumption normally requires an identity policy in the source account permitting sts:AssumeRole on the target role and a trust policy on that role accepting the caller. The trust policy controls who can assume the role; the role's permissions policies control what the resulting session can do. Trusting an account principal delegates authority to that account's administrators rather than granting every identity in that account automatic access. For example, a development pipeline can assume a production deployment role whose permissions allow updates only to a designated application.
After assumption, requests use the destination role's session, not the original caller's permissions. Session policies can further restrict that session, while applicable permissions boundaries, service control policies, resource control policies, resource policies, and explicit denies can affect authorization. An allow in one policy does not override an applicable explicit deny. Troubleshooting should therefore distinguish a failed AssumeRole request from a successful assumption followed by a denied resource operation.
For direct cross-account resource access, AWS generally requires permission from both the caller's account and the resource-owning account. For example, reading another account's S3 object generally requires an identity-policy allow for the reader and a bucket-policy allow for that principal. If the object is encrypted with a customer managed KMS key, the caller also needs the relevant KMS permissions, and the key policy must permit the cross-account use. Access to the bucket does not implicitly grant access to its encryption key.
Conditions make trust narrower and more practical. Restrict principals, actions, resources, and, where supported, organization membership or principal attributes. Require MFA for appropriate human workflows. For third-party role assumption, an external ID helps prevent confused-deputy attacks, but it is not a secret or a substitute for a trusted principal. For supported AWS service-to-service requests, source-account and source-resource conditions help prevent unintended use of a service principal.
Human users should generally enter through federation and obtain short-lived role sessions. Applications running in AWS should use workload roles rather than embedded access keys. External servers can use IAM Roles Anywhere to obtain temporary credentials using trusted X.509 certificates; a separate cross-account role assumption can then provide destination access when required. IAM paths organize identities and can support policy matching, but paths are not security boundaries. Amazon Verified Permissions addresses application-level authorization decisions; it does not replace IAM trust policies or grant access to AWS resources by itself.
The trade-off is additional policy coordination and operational complexity. Keep grants narrow, record role sessions with attributable names or source identity, inspect CloudTrail events, and use IAM Access Analyzer to identify unintended external access. Test both permitted and denied scenarios, including expired sessions and missing encryption permissions. Removing trust prevents new sessions, but existing temporary credentials may remain usable until expiration unless separately restricted or revoked through supported controls.
Amazon S3