Resource sharing across AWS accounts

Identity and Access Management (IAM) roles can be assumed by users, applications, or services from another AWS account. By creating a role with precise permissions and allowing a trusted external AWS account to assume this role, you provide access to the resources without sharing the actual access keys.

For example, to allow users from Account B to access an S3 bucket in Account A, you would:

1. Create an IAM policy in Account A that defines the necessary permissions on the S3 bucket.
2. Create an IAM role in Account A and attach the policy from step 1.
3. Edit the trust relationship for the IAM role to allow users from Account B to assume the role.
4. Provide the users in Account B with the ability to assume the role, typically by adding permissions to their IAM user policy.

Resource-based Policies

Some AWS services, like S3, support resource-based policies that directly attach permissions policies to the resource itself. For example, an S3 bucket policy can grant read and write permissions to users from a different AWS account directly, without the need to use IAM roles.

Consider this example policy, which could be attached to an S3 bucket in Account A to allow Account B access:

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {“AWS”: “arn:aws:iam::AccountB-ID:root”},
“Action”: [“s3:GetObject”, “s3:PutObject”],
“Resource”: “arn:aws:s3:::bucketname-in-accountA/*”
}
]
}

VPC Peering

AWS Virtual Private Cloud (VPC) allows you to isolate and control your cloud network space. When you need to enable direct network connectivity between VPCs in different AWS accounts, you can establish VPC peering. This allows resources in either VPC to communicate with each other using private IP addresses without routing the traffic through the public internet.

Keep in mind that VPC peering has some limitations:

• Overlapping CIDR blocks are not allowed.
• Transitive peering is not supported natively.
• Limited to certain region pairings depending on service availability and policies.

AWS Resource Access Manager (RAM)

AWS RAM allows you to share AWS resources with any AWS account or through AWS Organizations. Unlike VPC peering, which is for networking resources, RAM can share many types of resources like Subnets, Transit Gateways, and License Configurations.

For example, you can share subnets with other AWS accounts using AWS RAM:

1. The owner of the subnet (Account A) enables sharing with AWS RAM.
2. Account A shares the specified subnet(s) with Account B by creating a resource share.
3. Account B accepts the shared resource, and the subnet appears in their account.

AWS Organizations and Service Control Policies (SCPs)

AWS Organizations helps to manage and govern your environment as you scale with AWS. Using Service Control Policies (SCPs), you can define permissions for member accounts in your organization. SCPs can limit the services, actions, and resources that users and roles in each member account can use.

Consider the following organizing principles when adopting SCPs:

• Policies are not directly attached to user roles or resources.
• SCPs limit permissions in member accounts irrespective of the individual policies in those accounts.
• SCPs are useful for broad strokes governance, like ensuring all member accounts adhere to certain security protocols.

Comparison Table

Each of these sharing methods serves specific scenarios and should be selected based on the architecture requirements and compliance regulations applicable to your resources and workloads. By employing these sharing strategies thoughtfully, organizations can ensure efficient, secure, and compliant use of AWS resources across different AWS accounts.