Support cross-account for clusters in Route 53 ARC
Amazon Route 53 Application Recovery Controller integrates with Amazon Resource Access Manager to enable resource sharing. Amazon RAM is a service that enables you to share resources with other Amazon Web Services accounts or through Amazon Organizations. For Route 53 ARC, you can share the cluster resource.
With Amazon 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 Amazon Web Services accounts inside or outside of owner's organization in Amazon Organizations
-
An organizational unit inside its organization in Amazon Organizations
-
Its entire organization in Amazon Organizations
For more information about Amazon RAM, see the Amazon RAM User Guide.
By using Amazon 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 Amazon Web Services accounts. When you opt to share a cluster, other Amazon Web Services 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.
Amazon RAM is a service that helps Amazon customers to securely share resources across Amazon Web Services accounts. With Amazon RAM, you can share resources within an organization or organizational units (OUs) in Amazon Organizations, by using IAM roles and users. Amazon 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 Amazon 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 Amazon Web Services Management Console or by running Route 53 ARC API operations using the Amazon Command Line Interface or Amazon SDKs.
This topic explains how to share resources that you own, and how to use resources that are shared with you.
Contents
Prerequisites for sharing clusters
-
To share a cluster, you must own it in your Amazon Web Services 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 Amazon Organizations, you must enable sharing with Amazon Organizations. For more information, see Enable sharing with Amazon Organizations in the Amazon 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
Amazon RAM resource that lets you share your resources across Amazon Web Services 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
Amazon RAM console
If you are part of an organization in Amazon 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 Amazon RAM console, or by using Amazon RAM API operations with the Amazon CLI or SDKs.
To share a cluster that you own by using the Amazon RAM console
See Creating a resource share in the Amazon RAM User Guide.
To share a cluster that you own by using the Amazon 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 Amazon RAM console or by using Amazon RAM API operations with the Amazon CLI or SDKs.
To unshare a shared cluster that you own using the Amazon RAM console
See Updating a resource share in the Amazon RAM User Guide.
To unshare a shared cluster that you own using the Amazon CLI
Use the disassociate-resource-share command.
Identifying a shared cluster
Owners and participants can identify shared clusters by viewing information in Amazon RAM. They can also get information about shared resources by using the Route 53 ARC console and Amazon 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 Amazon Resource Access Manager User Guide:
As an owner, you can view all resources that you are sharing with others by using Amazon RAM. For more information, see Viewing your shared resources in Amazon RAM.
As a participant, you can view all resources shared with you by using Amazon RAM. For more information, see Viewing your shared resources in Amazon RAM.
As an owner, you can determine if you're sharing a cluster by viewing information in the Amazon Web Services Management Console or by using the Amazon 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 Amazon Web Services 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 Amazon 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 Amazon Web Services 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 Amazon Command Line Interface or Amazon 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
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.