Support cross-account for clusters in Route 53 ARC - Amazon Route 53 Application Recovery Controller

Support cross-account for clusters in Route 53 ARC

Amazon Route 53 Application Recovery Controller integrates with AWS Resource Access Manager to enable resource sharing. AWS RAM is a service that enables you to share resources with other AWS accounts or through AWS Organizations. For Route 53 ARC, you can share the cluster resource.

With AWS RAM, you share resources that you own by creating a resource share. A resource share specifies the resources to share, and the participants to share them with. Participants can include:

  • Specific AWS accounts inside or outside of owner's organization in AWS Organizations

  • An organizational unit inside its organization in AWS Organizations

  • Its entire organization in AWS Organizations

For more information about AWS RAM, see the AWS RAM User Guide.

By using AWS Resource Access Manager to share cluster resources across accounts in Route 53 ARC, you can use one cluster to host control panels and routing controls owned by several different AWS accounts. When you opt to share a cluster, other AWS accounts that you specify can use the cluster to host their own control panels and routing controls, allowing more control and flexibility over routing capabilities across different teams.

AWS RAM is a service that helps AWS customers to securely share resources across AWS accounts. With AWS RAM, you can share resources within an organization or organizational units (OUs) in AWS Organizations, by using IAM roles and users. AWS RAM is a centralized and controlled way to share a cluster.

When you share a cluster, you can reduce the number of total clusters that your organization requires. With a shared cluster, you can allocate the total cost of running the cluster across different teams, to maximize the benefits of Route 53 ARC with lower cost. (Creating resources that are hosted in a cluster does not have additional costs, for the owner or for participants.) Sharing clusters across accounts can also ease the process of onboarding multiple applications to Route 53 ARC, especially if you have a large number of applications distributed across several accounts and operations teams.

To get started with cross-account sharing in Route 53 ARC, you create a resource share in AWS RAM. The resource share specifies participants who are authorized to share the cluster that your account owns. Then, participants can create resources, such as control panels and routing controls, in the cluster, by using the AWS Management Console or by running Route 53 ARC API operations using the AWS Command Line Interface or AWS SDKs.

This topic explains how to share resources that you own, and how to use resources that are shared with you.

Prerequisites for sharing clusters

  • To share a cluster, you must own it in your AWS account. This means that the resource must be allocated or provisioned in your account. You cannot share a cluster that has been shared with you.

  • To share a cluster with your organization or an organizational unit in AWS Organizations, you must enable sharing with AWS Organizations. For more information, see Enable sharing with AWS Organizations in the AWS RAM User Guide.

Sharing a cluster

When you share a cluster that you own, the participants that you specify to share the cluster can create and host their own Route 53 ARC resources in the cluster.

To share a cluster, you must add it to a resource share. A resource share is an AWS RAM resource that lets you share your resources across AWS accounts. A resource share specifies the resources to share, and the participants they're shared with. To share a cluster you can create a new resource share or add the resource to an existing resource share. To create a new resource share, you can use the AWS RAM console, or use AWS RAM API operations with the AWS Command Line Interface or AWS SDKs.

If you are part of an organization in AWS Organizations and sharing within your organization is enabled, participants in your organization are automatically granted access to the shared cluster. Otherwise, participants receive an invitation to join the resource share and are granted access to the shared cluster after accepting the invitation.

You can share a cluster that you own by using the AWS RAM console, or by using AWS RAM API operations with the AWS CLI or SDKs.

To share a cluster that you own by using the AWS RAM console

See Creating a resource share in the AWS RAM User Guide.

To share a cluster that you own by using the AWS CLI

Use the create-resource-share command.

Unsharing a shared cluster

When you unshare a cluster, the following applies to participants and owners:

  • Current participant resources continue to exist in the unshared cluster.

  • Participants can continue to update routing control states in the unshared cluster, to manage routing for application failover.

  • Participants can no longer create new resources in the unshared cluster.

  • If participants still have resources in an unshared cluster, the owner cannot delete the shared cluster.

To unshare a shared cluster that you own, remove it from the resource share. You can do this by using the AWS RAM console or by using AWS RAM API operations with the AWS CLI or SDKs.

To unshare a shared cluster that you own using the AWS RAM console

See Updating a resource share in the AWS RAM User Guide.

To unshare a shared cluster that you own using the AWS CLI

Use the disassociate-resource-share command.

Identifying a shared cluster

Owners and participants can identify shared clusters by viewing information in AWS RAM. They can also get information about shared resources by using the Route 53 ARC console and AWS CLI.

In general, to learn more about the resources that you've shared or that have been shared with you, see the information in the AWS Resource Access Manager User Guide:

As an owner, you can determine if you're sharing a cluster by viewing information in the AWS Management Console or by using the AWS Command Line Interface with Route 53 ARC API operations.

To identify if a cluster that you own is shared by using the console

In the AWS Management Console, on the details page for a cluster, see the Cluster sharing status.

To identify if a cluster that you own is shared by using the AWS CLI

Use the get-resource-policy command. If there is a resource policy for a cluster, the command returns information about the policy.

As a participant, when a cluster is shared with you, you typically must accept the share. In addition, the Owner field for the cluster contains the account of the cluster owner.

Responsibilities and permissions for shared clusters

Permissions for owners

When you share a cluster that you own with other AWS accounts, participants who are permitted to use the cluster can create control panels, routing controls, and other resources in the cluster.

As a cluster owner, you are responsible for creating, managing, and deleting clusters. You can't modify or delete resources created by participants, such as routing controls and safety rules. For example, you can't update a routing control created by a participant to change the routing control state.

However, you can view the details for routing controls that are created by participants in a cluster that you own. For example, you can view routing control states by calling a Route 53 ARC routing control API operation, using the AWS Command Line Interface or AWS SDKs.

If you need to modify resources create by participants, they can set up a role in IAM with permission to access the resources, and add your account to the role.

Permissions for participants

In general, participants can create and use control panels, routing controls, safety rules, and health checks that they create in a cluster that is shared with them. They can only view, modify, or delete cluster resources in the shared cluster if they own the resources. For example, participants can create and delete safety rules for control panels that they have created.

The following restrictions apply for participants:

  • Participants cannot view, modify, or delete control panels created by other accounts using a shared cluster.

  • Participants cannot view, create, or modify routing controls, including routing control states, for resources created in a shared cluster by other accounts.

  • Participants cannot create, modify, or view safety rules created by other accounts in a shared cluster.

  • Participants cannot add resources in the default control panel in a shared cluster because it belongs to the cluster owner.

As noted, participants cannot create routing controls in the default control panel for a shared cluster, because the cluster owner owns the default control panel. However, the cluster owner can create a cross-account IAM role that provides permission to access the default control panel for the cluster. Then, the owner can grant a participant permissions to assume the role, so that the participant can access the default control panel to use it however the owner has specified through the role's permissions.

Billing costs

The owner of a cluster in Route 53 ARC is billed for costs associated with the cluster. There are no additional costs, for cluster owners or for participants, for creating resources hosted in a cluster.

For detailed pricing information and examples, see Amazon Route 53 Application Recovery Controller Pricing and scroll down to Amazon Route 53 Application Recovery Controller.

Quotas

All resources created in a shared cluster—including resources created by all participants with access to the shared cluster—count toward quotas in effect for the cluster and other resources, such as routing controls. If accounts that share the cluster resource have a higher quota than the cluster owner's quotas, the cluster owner's quotas takes precedence over the quotas for the accounts that are sharing.

To better understand how this works, see the following examples. To illustrate how quotas work with resource sharing, for these examples, let's say that the cluster owner is Owner and an account that the cluster has been shared with is Participant.

Control panels quota

Quotas are enforced for Owner's total control panels per cluster.

For example, say Owner has a quota of 50 for the number of control panels per cluster, and has 13 control panels in the cluster. Now, say that Participant has the quota set to 150. In this scenario, Participant can only create up to 37 control panels (that is, 50-13) in the shared cluster.

In addition, if other accounts that share the cluster also create control panels, those also all count toward the cluster overall quota of 50 control panels.

Routing control quotas

Routing controls have multiple quotas: a quota per control panel, a quota per cluster, and a quota per safety rule. Owner's quotas take precedence for all of these quotas.

For example, say Owner has a quota of 300 for the number of routing controls per cluster, and already has 300 routing controls in the cluster. Now, say that Participant has this quota set to 500. In this scenario, Participant cannot create any new routing controls in the shared cluster.

Safety rules quotas

Quotas are enforced for Owner's safety rules per control panel quota.

For example, say Owner has a quota of 20 for the number of safety rules per control panel and Participant has this quota set to 80. In this scenario, because Owner's lower limit takes precedence, Participant can only create up to 20 safety rules in a control panel in the shared cluster.

For a list of routing control quotas, see Quotas for routing control.