Cross-Account S3 Access Patterns

Cross-account S3 access allows a user or service in one AWS account (the 'requesting account') to access an S3 bucket owned by a different AWS account (the 'owning account'). This is a fundamental capability for multi-account architectures, where data is often centralized in a logging or data lake account and consumed by multiple workload accounts.

By default, all S3 resources are private to the owning account. To grant access to another account, you must explicitly configure permissions. AWS evaluates access using a combination of resource-based policies (bucket policies, ACLs, access point policies) and identity-based policies (IAM user/role policies). For cross-account access to succeed, both the resource-based policy AND the identity-based policy must grant the request. This is a key exam point: there is no 'implicit allow' across accounts.

When a user in Account A makes a request to an S3 bucket in Account B, AWS performs an authorization decision using the following logic:

- Identity-based policies attached to the principal in Account A (IAM user/role policy) - Resource-based policies on the bucket in Account B (bucket policy, ACL, or access point policy) - Service control policies (SCPs) in AWS Organizations, if applicable - Session policies if using role assumption 3. The decision is based on the following rules:

This two-way allow requirement is the most important concept for the exam. It differs from same-account access, where only one policy (identity or resource) needs to allow.

Bucket Policies: Resource-based policies attached directly to an S3 bucket. They can grant access to principals in other accounts by specifying the principal's AWS account ID or full ARN. Bucket policies are the recommended method for cross-account access because they are centralized, support conditions, and work with IAM roles.

IAM Roles: An IAM role in the requesting account with a trust policy that allows the bucket owner account to assume the role? No — actually, the role is assumed by users in the requesting account, but the bucket policy in the owning account must grant access to that role ARN. The trust policy of the role must allow the users in the requesting account to assume it. Then, when a user assumes the role, they get temporary credentials that are used to access the bucket. The bucket policy must explicitly allow the role ARN.

IAM User Policies: Alternatively, you can attach a policy to an IAM user in the requesting account (not recommended for production). The bucket policy then grants access to the user ARN or the entire account. This is less flexible because it requires managing individual users.

Access Control Lists (ACLs): Legacy method. ACLs are sub-resources of objects and buckets. They can grant access to other AWS accounts (by account ID) but not to specific IAM users/roles within that account. ACLs are less granular and harder to audit. AWS recommends using bucket policies instead. By default, ACLs are disabled on new buckets (S3 Object Ownership setting). The exam may test that ACLs are deprecated but still supported.

Access Points: A newer feature that simplifies managing access for large-scale data sharing. Each access point has its own policy and network controls. You can create an access point in the owning account and grant cross-account access via the access point policy. The requesting account then uses the access point ARN instead of the bucket ARN. Access points enforce a separate policy evaluation.

Service Control Policies (SCPs): If both accounts are in the same AWS Organization, SCPs can restrict cross-account access. An SCP that denies s3:PutObject to all principals would override any allow in bucket policies. The exam may include SCPs as a potential blocker.

Method 1: Bucket Policy with IAM Role (Recommended)

Example bucket policy in Account B:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_A:role/CrossAccountRole"
      },
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::bucket-b/*",
        "arn:aws:s3:::bucket-b"
      ]
    }
  ]
}

Example IAM policy attached to the role in Account A:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::bucket-b/*",
        "arn:aws:s3:::bucket-b"
      ]
    }
  ]
}

Method 2: Bucket Policy Granting Access to Entire Account

In the bucket policy, specify the principal as the entire requesting account:

"Principal": {
  "AWS": "arn:aws:iam::ACCOUNT_A:root"
}

This allows any IAM user/role in Account A that also has an IAM policy allowing the action. This is simpler but less secure because it grants access to all principals in Account A.

Method 3: Using Access Points

Access points can also enforce a VPC origin, which is useful for restricting access to a specific VPC.

You can use the AWS CLI to test cross-account access. First, assume the role in Account A:

aws sts assume-role --role-arn "arn:aws:iam::ACCOUNT_A:role/CrossAccountRole" --role-session-name test

Then use the returned credentials to access the bucket:

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws s3 ls s3://bucket-b/

If access is denied, check CloudTrail logs for the reason. Common errors include missing bucket policy, incorrect principal ARN, or SCP restrictions.

AWS Organizations: If accounts are in the same organization, you can use SCPs to restrict cross-account access. For example, an SCP can deny s3:PutObject to any bucket in a specific account unless the request comes from a specific VPC.

VPC Endpoints: You can use gateway endpoints or interface endpoints to access S3 privately. For cross-account access, the bucket policy must allow the VPC endpoint or the principal's VPC. You can also use access points with VPC origin.

CloudTrail: All S3 API calls are logged. For cross-account access, the source IP will be from the requesting account's VPC or internet, and the user identity will be the assumed role ARN.

AWS KMS: If the bucket is encrypted with a customer-managed KMS key (CMK) in Account B, the requesting account's role must also have kms:Decrypt permission on that key. The key policy must grant access to the role ARN. This is a common exam trap: forgetting KMS permissions.

Enterprise Scenario 1: Centralized Logging

A large enterprise has a central logging account that stores S3 access logs, CloudTrail logs, and VPC Flow Logs from hundreds of workload accounts. The workload accounts need read-only access to their own log prefixes. The solution uses a bucket policy in the logging account that grants access to each workload account's IAM role. For example, the bucket policy has multiple statements, each with a Principal pointing to a specific role ARN in a workload account. The role in each workload account has an IAM policy allowing s3:GetObject and s3:ListBucket on the logging bucket. The bucket policy also uses condition keys like 'aws:SourceAccount' to restrict access to the correct account, preventing a workload account from accessing another account's logs. In production, this setup handles millions of objects daily. A common misconfiguration is forgetting to update the bucket policy when a new workload account is added, causing access failures. To avoid this, the team uses Infrastructure as Code (e.g., Terraform) to manage the bucket policy dynamically.

Enterprise Scenario 2: Data Lake Sharing

A data analytics company has a data lake in Account A that is consumed by multiple business units in separate AWS accounts. Each business unit has its own IAM role. The bucket policy in Account A grants s3:GetObject and s3:ListBucket to each role. To simplify management, the company uses S3 access points. They create an access point per business unit, each with its own policy that grants access to that unit's role. The access points also enforce VPC origin, ensuring that traffic stays within the corporate network. This setup allows fine-grained access control and network isolation. In production, the access points handle thousands of requests per second. A performance consideration is that access points add a small latency overhead, but it is negligible for most workloads. The biggest issue is misconfigured access point policies that accidentally grant broader access than intended, leading to data leaks. Regular audits using IAM Access Analyzer help detect overly permissive policies.

Enterprise Scenario 3: Cross-Account Backup

A company uses a separate backup account to store backups from production accounts. The production account has an IAM role that allows s3:PutObject to the backup bucket. The backup bucket policy grants access to the production role. The production account's backup scripts assume the role and upload backup files. A common problem is that the backup role's trust policy must allow the backup service (e.g., AWS Backup) to assume it, which requires a specific service principal. Additionally, if the backup bucket uses S3 Object Lock for compliance, the role needs s3:PutObjectLegalHold permission. Misconfiguring the trust policy or forgetting the Object Lock permissions can cause backup failures. The team tests the configuration using the AWS CLI with the assume-role command before deploying to production.