Enabling Cross-Account Access

In this example, Account A uses a bucket policy to grant Account B full access to Account A's Amazon S3 bucket. Then, Account B creates an IAM user policy to delegate access to Account A's bucket to one of the users under Account B.

Account A's bucket policy might look like the following policy. In this example, Account A's Amazon S3 bucket is named mybucket, and Account B's account number is 1111-2222-3333. Account A uses Amazon S3 to implement this policy.

{
   "Statement" : {
      "Effect":"Allow",
      "Sid":"AccountBAccess1",
      "Principal" : {
          "AWS":"111122223333"
      },
      "Action":"s3:*",
      "Resource":"arn:aws:s3:::mybucket/*"
   }
   }

Note

Alternatively, Account A could use Amazon S3 Access Control Lists (ACLs) to grant Account B access to an Amazon S3 bucket or a single object within a bucket. In this case, the only thing that would change is how Account A grants access to Account B. Account B would still use a policy to delegate access to a user under Account B, as described in the second part of this example. For more information about controlling access on Amazon S3 buckets and objects, go to Access Control in the Amazon Simple Storage Service Developer Guide.

The next example shows the IAM user (or group) policy that Account B might create to delegate read access to a user under Account B. In this policy, the Action element is explicitly defined to allow only List actions, and the Resource element of this policy matches the Resource for the bucket policy implemented by Account A.

Account B implements this policy by using IAM to attach it to the appropriate user (or group) under Account B.

{
   "Statement":{
      "Effect":"Allow",
      "Action":"s3:List*",
      "Resource":"arn:aws:s3:::mybucket/*"
   }
}

In this example, Account A has an Amazon SQS queue and Account A uses a queue policy to grant queue access to Account B. Then, Account B uses an IAM user policy to delegate access to a user under Account B.

The following example queue policy gives Account B SendMessage and ReceiveMessage permission for Account A's queue named 1234-5678-9012/queue1, but only between noon and 3:00 p.m. on November 30, 2011. Account B's account number is 1111-2222-3333. Account A uses Amazon SQS to implement this policy.

{
   "Statement":{
      "Effect": "Allow",
      "Action": ["sqs:SendMessage","sqs:ReceiveMessage"],
      "Principal": {
        "AWS": "111122223333"
      }
      "Resource": "arn:aws:sqs:*:/123456789012:queue1",
      "Condition": {
        "DateGreaterThan": {
          "aws:CurrentTime": "2011-11-30T12:00Z"
        }
        "DateLessThan": {
          "aws:CurrentTime": "2011-11-30T15:00Z"
        },
      },
   }
}

Account B's policy delegating access to a user under Account B might look like the following example. Account B uses IAM to attach this policy to a user (or group).

{
   "Statement":{
     "Effect":"Allow",
     "Action":"sqs:*",
     "Resource":"arn:aws:sqs:*:/123456789012:queue1"
   }
}

In the preceding IAM user policy example, Account B uses a wildcard to grant its user access to Account A's queue. But, because Account B can delegate access only to the extent that Account B has been granted access, Account B's user can access the queue only between noon and 3:00 p.m. on November 30, 2011, and the user can only perform SendMessage and ReceiveMessage actions, as defined in Account A's Amazon SQS queue policy.

By default, other AWS accounts and their users cannot access your AWS account resources. But, when you use a policy to explicitly deny an AWS account access to your resources, the deny propagates to the users under that account regardless of whether the users have existing policies granting them access. This means that an AWS account cannot delegate access to another account's resources if the other account has explicitly denied access to the user's parent account.

For example, Account A writes a bucket policy on Account A's Amazon S3 bucket that explicitly denies Account B access to Account A's bucket. But Account B writes an IAM user policy that grants a user under Account B access to Account A's bucket. The explicit deny applied to Account A's Amazon S3 bucket propagates to the users under Account B and overrides the IAM user policy granting access to the user under Account B. (For detailed information how permissions are evaluated, see Evaluation Logic.)

Account A's bucket policy might look like the following policy. In this example, Account A's Amazon S3 bucket is named mybucket, and Account B's account number is 1111-2222-3333. Account A uses Amazon S3 to implement this policy.

{
   "Statement" : {
      "Effect":"Deny",
      "Sid":"AccountBDeny",
      "Principal" : {
          "AWS":"111122223333"
      },
      "Action":"s3:*",
      "Resource":"arn:aws:s3:::mybucket/*"
   }
}

Account B implements the following IAM user policy by using IAM to attach it to the a user under Account B.

{
   "Statement":{
      "Effect":"Allow",
      "Action":"s3:*",
      "Resource":"arn:aws:s3:::mybucket/*"
   }
}

Because Account A's bucket policy explicitly denies Account B access to mybucket, the deny propagates to the user under Account B, and Account B's IAM user policy granting Account B's user access to Account A's bucket has no effect. The user cannot access Account A's bucket.