Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Terms and concepts for Amazon RAM

The following concepts help explain how you can use Amazon Resource Access Manager (Amazon RAM) to share your resources.

Resource share

You share resources using Amazon RAM by creating a resource share. A resource share has the following three elements:

After you use Amazon RAM to create a resource share, the principals specified in the resource share can be granted access to the share's resources.

Sharing account

The sharing account contains the resource that is shared and in which the Amazon RAM administrator creates the Amazon resource share by using Amazon RAM.

An Amazon RAM administrator is an IAM principal who has permissions to create and configure resource shares in the Amazon Web Services account. Because Amazon RAM works by attaching a resource-based policy to the resources in a resource share, the Amazon RAM administrator also must have permissions to call the PutResourcePolicy operation in the Amazon Web Service for each resource type included in a resource share.

Consuming principals

The consuming account is the Amazon Web Services account to which a resource is shared. The resource share can specify an entire account as the principal, or for some resource types, individual roles or users in the account. For information about which resource types support this type of sharing, see Shareable Amazon resources and view the Can share with IAM roles & users column.

Amazon RAM also supports service principals as consumers of resource shares. For information about which resource types support this type of sharing, see Shareable Amazon resources and view the Can share with service principals column.

The principals in the consuming account can perform only those actions allowed by both of the following permissions:

Amazon RAM supports the following IAM principal types as consumers of resource shares:

Resource-based policy

Resource-based policies are JSON text documents that implement the IAM policy language. Unlike identity-based policies that you attach to the principal, such as an IAM role or user, you attach resource-based policies to the resource. Amazon RAM authors resource-based policies on your behalf based on the information you provide for your resource share. You must specify a Principal policy element that determines who can access the resource. For more information, see Identity-based policies and resource-based policies in the IAM User Guide.

The resource-based policies generated by Amazon RAM are evaluated along with all other IAM policy types. This includes any IAM identity-based policies attached to the principals who are attempting to access the resource, and service control policies (SCPs) for Amazon Organizations that might apply to the Amazon Web Services account. Resource-based policies generated by Amazon RAM participate in the same policy evaluation logic as all other IAM policies. For complete details of policy evaluation and how to determine the resulting permissions, see Policy evaluation logic in the IAM User Guide.

Amazon RAM provides a simple and secure resource sharing experience by providing easy-to-use abstraction resource-based policies.

For those resource types that support resource-based policies, Amazon RAM automatically constructs and manages the resource-based policies for you. For a given resource, Amazon RAM builds the resource-based policy by combining the information from all of the resource shares that include that resource. For example, consider an Amazon SageMaker pipeline that you share by using Amazon RAM and include in two different resource shares. You could use one resource share to provide read-only access to your entire organization. You could then use the other resource share to grant only SageMaker execution permissions to a single account. Amazon RAM automatically combines those two different sets of permissions into a single resource policy with multiple statements. It then attaches the combined resource-based policy to the pipeline resource. You can view this underlying resource policy by calling the GetResourcePolicy operation. Amazon Web Services then use that resource-based policy to authorize any principal who attempts to perform an action on the shared resource.

Although you can manually create the resource-based policies and attach them to your resources by calling PutResourcePolicy, we recommend that you use Amazon RAM because it provides the following advantages:

By using Amazon RAM, you can even share some resource types that don’t support resource-based policies yet. For such resource types, Amazon RAM automatically generates a resource-based policy as a representation of the actual permissions. Users can view this representation by calling GetResourcePolicy. This includes the following resource types:

Examples of Amazon RAM generated resource-based policies

If you share an EC2 Image Builder image resource with an individual account, Amazon RAM generates a policy that looks like the following example and attaches it to any image resources that are included in the resource share.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws-cn:iam::123456789012:root"},
            "Action": [
                "imagebuilder:GetImage",
                "imagebuilder:ListImages",
            ],
            "Resource": "arn:aws-cn:imagebuilder:cn-north-1:123456789012:image/testimage/1.0.0/44"
        }
    ]
}

If you share an EC2 Image Builder image resource with an IAM role or user in a different Amazon Web Services account, Amazon RAM generates a policy that looks like the following example and attaches it to any image resources that are included in the resource share.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws-cn:iam::123456789012:role/MySampleRole"
      },
      "Action": [
          "imagebuilder:GetImage",
          "imagebuilder:ListImages",
      ],
      "Resource": "arn:aws-cn:imagebuilder:cn-north-1:123456789012:image/testimage/1.0.0/44"
    }
  ]
}

If you share an EC2 Image Builder image resource with all of the accounts in an organization or with the accounts an OU, Amazon RAM generates a policy that looks like the following example and attaches it to any image resources that are included in the resource share.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "imagebuilder:GetImage",
                "imagebuilder:ListImages",
            ],
            "Resource": "arn:aws-cn:imagebuilder:cn-north-1:123456789012:image/testimage/1.0.0/44"
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "o-123456789"
                }
            }
        }
    ]
}

Implications of using "Principal": "*" in a resource-based policy

When you include "Principal": "*" in a resource-based policy, the policy grants access to all IAM principals in the account that contains the resource, subject to any restrictions imposed by a Condition element, if it exists. Explicit Deny statements in any policy that applies to the calling principal overrides the permissions granted by this policy. However, an implicit Deny (meaning the lack of an explicit Allow) in any applicable identity policies, permissions boundary policies, or session policies does not result in a Deny to the principals granted access to an action by such a resource-based policy.

If this behavior isn’t desirable for your scenario, then you can limit this behavior by adding an explicit Deny statement to an identity policy, permissions boundary, or session policy that affects the relevant roles and users.

Managed permissions

Managed permissions define what actions principals can perform under which conditions on supported resource types in a resource share. When you create a resource share, you must specify which managed permission to use for each resource type included in the resource share. A managed permission lists the set of actions and conditions that principals can perform with the resource shared using Amazon RAM.

You can attach only one managed permission for each resource type in a resource share. You can't create a resource share in which some resources of a certain type use one managed permission and other resources of the same type use a different managed permission. To do that, you would need to create two different resource shares and split the resources among them, giving each set a different managed permission. There are two different types of managed permissions:

Amazon RAM takes managed permissions as an input to author the resource-based policies for the resources you share.

Managed permission version

Any change to a managed permission is represented as a new version of that managed permission. The new version is the default for all new resource shares. Each managed permission always has one version designated as the default version. When you or Amazon creates a new managed permission version, you must explicitly update the managed permission for each existing resource share. You can evaluate the changes before you apply them to your resource share in this step. All new resource shares will automatically use the new version of the managed permission for the corresponding resource type.

When you create or update a resource share, you can attach only the default version of the specified managed permission. For more information, see Updating Amazon managed permissions to a newer version.