# Region switch in ARC
You can use Region switch in ARC to orchestrate large-scale, complex recovery tasks for your application resources across AWS accounts, to help ensure business continuity and reduce operational overhead. Region switch provides a centralized and observable solution that you can perform manually, or automate by using Amazon CloudWatch alarm triggers. If an AWS Region becomes impaired, you can execute the plans that you create by using Region switch to fail over or switch your resources to another Region. This ensures that your application can continue to operate, running in a healthy AWS Region.
Region switch is built around the concept of a *plan*, which you design and configure for your specific recovery needs. Each plan includes *workflows* that are made up of steps. Each step runs one or more *execution blocks*, which Region switch runs in parallel or in sequence, to complete an application recovery. Each execution block handles a different task, such as switching over resources or managing traffic redirection for your application. For even more flexibility, you can create parent plans, by adding child plans to an overall parent plan.
Region switch includes the following:
+ Support for active/passive and active/active configurations. You can failover and failback if you have an active/passive multi-Region configurations, or shift-away and return if your application is set up as active/active in multiple Regions.
+ Cross-account support for application resources that you include in your application recovery. You can also share Region switch plans across accounts.
+ Automatic failover or switchover, by triggering plan execution based on Amazon CloudWatch alarms. Or, you can choose to execute a Region switch plan manually.
+ Full-featured dashboards that give you real-time visibility into the recovery process.
+ A data plane in each AWS Region, so that you can execute your Region switch plan without taking a dependency on the Region that you’re deactivating.
Region switch is fully managed by AWS. Using Region switch enables you to benefit from the resilience of a recovery platform that focuses on your application's specific requirements, instead of building and maintaining scripts, and manually gathering data about recoveries.
# About Region switch
With Region switch, you can orchestrate the specific steps to switch the AWS Region that your multi-Region application is running in.
Region switch is built around the concept of a *plan*, which you design and configure for your specific recovery needs. Each plan includes *workflows* that are made up of steps. Each step runs one or more *execution blocks*, which Region switch runs in parallel or in sequence, to complete an application recovery. Each execution block handles a different task, such as switching over resources or managing traffic redirection for your application. For even more flexibility, you can create parent plans, by adding child plans.
Whenever you create, or update, a plan, Region switch performs a plan evaluation, to ensure that there aren't issues with IAM permissions, resource configurations, or running capacity. Region switch runs these evaluations regularly, and generates a warning for any issues that it finds.
Region switch also calculates an actual recovery time value for each plan execution, to help you evaluate if the plan is meeting your objectives. You can view recovery time and other details about plan executions in Region switch dashboards in the AWS Management Console. For more information, see [Region switch dashboards](region-switch.dashboarding-and-reports.md).
To learn more about each of these areas in Region switch, see the following sections.
## Region switch plans
A Region switch plan is the top-level resource in Region switch. You should scope your plan to a specific multi-Region application. A plan enables you to build *workflows* to recover your applications by running a series of Region switch *execution blocks* that activate or deactivate your application and its resources, including cross-account resources, in the AWS Region that you specify.
A plan is made up of one or more workflows, to enable you to activate or deactivate a specific AWS Region. You can configure execution blocks in a workflow to run sequentially, or you can specify that some of the blocks run in parallel.
For a plan that you configure for an active/passive multi-Region approach, you create either one workflow that can be used to activate either of your Regions, or two separate activation workflows, one for each Region. For a plan that you configure for an active/active approach, you create one workflow to activate your Regions and one workflow to deactivate your Regions.
AWS Regions are geographic locations worldwide where AWS clusters data centers. Each Region is designed to be completely isolated from the other Regions, providing fault tolerance and stability. When you use Region switch, you need to consider which Regions your application is deployed in and which Regions you want to use for recovery.
Region switch supports recovery between any two AWS Regions where the service is available. When you configure a Region switch plan, you specify the Regions that your application is deployed in and the recovery approach that you want to use: active/passive or active/active.
For example, you might have an active/passive multi-Region approach with us-east-1 as the primary Region and us-west-2 as the standby Region. To recover your application from an operational issue that impacts the application in us-east-1, you could execute your Region switch plan to activate us-west-2. This would result in the application switching from resources in us-east-1 to resources in us-west-2.
Region switch plans run using the permissions associated with the IAM role that you specify when you create the plan.
You can create multiple plans, one for each of your multi-Region applications, and then orchestrate recovery across these plans in your required order by creating a *parent plan*. A parent plan is a plan that uses the Region switch plan execution blocks as steps. The hierarchy of plans is limited to two levels (parent and child), but you can include multiple child plans under the same parent plan.
## Workflows and execution blocks
After you create a Region switch plan, you must add one or more workflows to the plan, to define the steps you want the plan to perform for your application recovery. For each workflow, you add steps that contain execution blocks. Each execution block performs a specific recovery action, such as scaling up resources or updating routing controls to reroute traffic. Steps organize these execution blocks and control whether they run in parallel or in sequence. By creating parent plans, you can also orchestrate the order in which multiple applications recover into the Region that you're activating.
You organize execution blocks into steps within a workflow. Each step can contain one or more execution blocks that run in parallel, and you arrange steps to run sequentially in your workflow. Also, depending on the resource, you can have the option to run an execution block with graceful (planned) or ungraceful (unplanned) execution.
+ Graceful execution: A planned execution workflow. When your environment is healthy, you can use the graceful workflow to run all steps for an orderly plan execution.
+ Ungraceful execution: An unplanned execution. The ungraceful workflow mode uses only the necessary steps and actions. This mode either changes the behavior of the execution blocks in a workflow or skips specific execution blocks.
+ Post-recovery execution: A workflow that runs after a successful recovery to prepare for future regional events. Post-recovery executions can create read replicas, run custom logic via Lambda functions, add manual approval gates, and embed child plans for complex orchestration. These executions require both Regions to be healthy and run in the Region that was previously impaired.
Finally, you can also configure cross-account resources for an execution block. First, you must configure permissions, by following the guidance in [Cross-account support in Region switch](cross-account-resources-rs.md). After you've set up the required IAM roles, then you can add cross-acount resources in the execution blocks in your plan workflows. To add cross-account resources, when you add a step, you specify a target IAM role that has permissions to the resource of other AWS accounts. You also must specify the external ID that you provided in the trust policy for the cross-account role. For details about creating the required IAM roles, see [Cross-account resource permissions](security_iam_region_switch_cross_account.md).
To learn more about workflows, see [Create Region switch plan workflows](working-with-rs-workflows.md). For details about each type of execution block, including configuration steps, how it works, and what is evaluated as part of plan evaluation, see [Add execution blocks](working-with-rs-execution-blocks.md).
## Plan evaluation
Plan evaluation is an automated process that Region switch runs when a plan is created or updated, and then every 30 minutes after that, during steady state. The evaluation process verifies several critical aspects of plan configuration and resource configurations. The evaluations include verifying IAM permissions, resource configurations, and running capacity.
If Region switch finds an issue that might prevent a successful plan execution, it generates a plan evaluation warning, which is highlighted on the plan details page in the console. You can also consume plan evaluation warnings with Amazon EventBridge, or you can view warnings by using the Region switch API. For more information about the Plan Evaluation API, see [GetPlanEvaluationStatus](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_GetPlanEvaluationStatus.html) in the *Region Switch API Reference Guide* for Amazon Application Recovery Controller (ARC).
You can see details and suggested remediation for issues that plan evaluation surfaces in the **Plan evaluation** tab on the plan details page. We recommend that you also test application recovery by executing your Region switch plan, and that you don't rely solely on Region switch plan evaluation to test that your recovery plan will work as you expect it to.
## Automatic plan execution reports
Region switch can automatically generate comprehensive PDF reports for plan executions to help you meet regulatory compliance requirements. These reports provide evidence of your disaster recovery tests and actual recovery events, including detailed execution timelines, plan configurations, and resource states.
When you configure automatic report generation for a plan, Region switch creates a PDF report after each plan execution completes and delivers it to an Amazon S3 bucket that you specify. Reports are typically available within 30 minutes of execution completion. S3 storage costs apply.
Each report includes:
+ Executive summary with service overview and report creation date
+ Plan configuration details as they existed at execution time
+ Detailed execution timeline with steps, affected resources, and statuses
+ Plan warnings that were present when the execution started
+ Amazon CloudWatch alarm states and alarm history for associated alarms
+ For parent plans, configuration and execution details of child plans
+ Glossary of terms and concepts
To enable automatic report generation, you configure a report output destination when you create or update a plan. You must also ensure that your plan's execution IAM role has the necessary permissions to write reports to your Amazon S3 bucket and access the resources needed to generate the report content. For more information about required permissions, see [Automatic plan execution reports permissions](security_iam_region_switch_reports.md).
You can view the status of report generation and download completed reports from the plan execution details page in the console. If report generation encounters errors, such as insufficient permissions or misconfigured Amazon S3 buckets, Region switch provides error details to help you troubleshoot the issue.
Plan evaluation continuously validates your report configuration, including verifying that the execution role has the required IAM permissions. If Region switch detects configuration issues that would prevent successful report generation, it generates warnings that you can view on the plan details page.
## Regional alarms and actual recovery time
Region switch calculates an *actual recovery time* value for each plan execution, which you can view after a plan execution. Actual recovery time is shown on the plan execution details page, so that you can compare the actual time to the recovery time objective you specified when you created the plan.
Actual recovery time is calculated as the total of the time is takes for a plan execution to complete, and any additional time that elapses before specific Amazon CloudWatch alarms that you configure return to a green state.
To support calculating an accurate actual recovery time for plan execution, you must configure Regional Amazon CloudWatch alarms for a Region switch plan that provide a signal about the health of your application in each Region. When a plan is executed, Region switch uses these application health alarms to determine when your application is healthy again. Then, Region switch calculates actual recovery time based on the time it takes for your plan to execute added to the time it takes for your application to return to healthy, based on the application health alarms that you configure.
Before you add CloudWatch alarms to a Region switch plan, make sure that you have the correct IAM policy in place. For more information, see [CloudWatch alarms for application health permissions](security_iam_region_switch_cloudwatch.md).
# AWS Regions
Region switch is available in all commercial AWS Regions, as well as AWS GovCloud (US) Regions.
For detailed information about Regional support and service endpoints for Amazon Application Recovery Controller (ARC), see [Amazon Application Recovery Controller (ARC) endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/arc.html) in the *Amazon Web Services General Reference*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/r53recovery/latest/dg/aws-regions-rs.html)
# Region switch components
The following are components of, and concepts about, the Region switch feature in Amazon Application Recovery Controller (ARC).
**Plan**
A plan is the fundamental recovery process for your application. You create a plan by building one or more workflows with execution blocks to be run in sequence or in parallel. Then, when there is a Regional impairment, you execute the plan to complete a recovery for your application by shifting the application to run in a healthy Region.
**Child plan**
A child plan is a self-contained plan that can be run from within a parent plan, to coordinate more complex application recovery scenarios. You can nest Region switch plans one level.
**Workflow**
A Region switch plan includes one or more workflows. A workflow is made up of steps that contain execution blocks, which you specify to be run in parallel or in sequence, to complete the activation or deactivation of a Region as part of a recovery plan. For a plan that you configure to have an active/passive approach, you create either one workflow that can be used to activate either of your Regions, or separate activation workflows, one for each Region. For a plan that you configure for an active/active approach, you create one workflow to activate your Regions and one workflow to deactivate your Regions.
**Execution block**
You add steps to your Region switch plan workflows containing an execution block. Execution blocks allow you to specify the recovery for multiple applications or resources into an activating Region. When you add a step to a workflow, you can add it in sequence with other steps, or in parallel with one or more other steps.
**Graceful and ungraceful configurations**
You can choose to run specific execution blocks with graceful (planned) or ungraceful (unplanned) execution. When your environment is healthy, you can use the graceful workflow to run all steps for an orderly plan execution. The ungraceful workflow mode uses only the necessary steps and actions. When you run a plan in ungraceful mode, it either changes the behavior of execution blocks in a workflow or skips specific execution blocks, depending on the type of execution block.
Specific types of execution blocks have different behavior when they run ungracefully. Details about these differences are described in the section that includes details about each type of execution block. For more information, see [Add execution blocks](working-with-rs-execution-blocks.md).
**Active/active and active/passive configurations**
There are two main approaches to creating a resilient configuration for an application across multiple Regions: active/passive and active/active. Region switch supports application recovery for both of these approaches.
With an active/passive configuration, you deploy two replicas of your application in two different Regions, with customer traffic only going to one Region.
With an active/active configuration, you deploy two replicas to two different Regions, but both replicas are processing work or receiving traffic.
**Plan execution**
When a Region switch plan executes, it implements recovery for an application when a Region becomes impaired by activating a healthy Region for your application and traffic it's receiving. With an active/active configuration, you also run a plan execution to deactivate the impaired Region.
**Application health alarms**
Application health alarms are CloudWatch alarms that you specify for a plan to indicate the health of your application in each Region. Region switch uses application health alarms to help determine the actual recovery time after you switch Regions to implement recovery.
**Triggers**
You can use triggers in Region switch to automate application recovery. When you create a trigger, you specify one or more Amazon CloudWatch alarms and define which alarm conditions (such as "red" or "green") should initiate plan execution. When the specified conditions are met, Region switch automatically executes the plan. Triggers are distinct from application health alarms: triggers start plan execution, while application health alarms help Region switch calculate actual recovery time after a plan completes.
**Post-recovery workflow**
A post-recovery workflow is an optional workflow that runs after a successful recovery to prepare for future regional events. These workflows require both Regions to be healthy and run in the Region that was previously impaired. Post-recovery executions reference the recovery execution ID of the most recent recovery execution.
Post-recovery workflows support the following execution blocks:
+ RDS Create Cross-Region Replica
+ Custom Action Lambda
+ Manual Approval
+ Region Switch Plan
**Dashboards**
Region switch includes dashboards where you can track details about plan executions in real time.
# Data and control planes for Region switch
As you plan for failover and disaster recovery, consider how resilient your failover mechanisms are. We recommend that you make sure that the mechanisms that you depend on during failover are highly available, so that you can use them when you need them in a disaster scenario. Typically, you should use data plane functions for your mechanisms whenever you can, for the greatest reliability and fault tolerance. With that in mind, it's important to understand how the functionality of a service is divided between control planes and data planes, and when you can rely on an expectation of extreme reliability with a service's data plane.
As with many AWS services, the functionality for the Region switch capability is supported by a control plane and data planes. While both types built to be reliable, a control plane is optimized for data consistency, while a data plane is optimized for availability. A data plane is designed for resilience so that it can maintain availability even during disruptive events, when a control plane might become unavailable.
In general, a *control plane* enables you to do basic management functions, such as create, update, and delete resources in the service. A *data plane* provides a service's core functionality. Because of this, we recommend that you use data plane operations when availability is important, for example, when you need to get information about a Region switch plan during an outage.
For Region switch, the control planes and data planes are divided as follows:
+ The control plane for Region switch is located in US East (N. Virginia) Region (us-east-1), AWS GovCloud (US-West) Region (us-gov-west-1) and is meant to only be used for service management, that is, creating and updating plans, not for recovery, that is, executing plans. *The Region switch configuration control plane API operations are not highly available.*
+ Region switch has independent data planes in each AWS Region. You should use the data plane for recovery actions, that is, for executing Region switch plans. For a list of the data plane operations, see [Region switch API operations](actions.region-switch.md). *These Region switch data plane operations are highly available.*
Region switch provides an independent console in each AWS Region, which calls data plane API operations for recovery tasks, so you can use the console in the Region that you're activating to execute plans for application recovery. For more information about key considerations when you prepare for and complete a recovery operation with Region switch, see [Best practices for Region switch in ARC](best-practices.region-switch.md).
For more information about data planes, control planes, and how AWS builds services to meet high availability targets, see the [Static stability using Availability Zones paper](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) in the Amazon Builders' Library.
# Tagging for ARC Region switch;
Tags are words or phrases (meta data) that you use to identify and organize your AWS resources. You can add multiple tags to each resource, and each tag includes a key and a value that you define. For example, the key might be environment and the value might be production. You can search and filter your resources based on the tags you add.
You can tag the following resource in Region switch in ARC:
+ Plans
Tagging in ARC is available only through the API, for example, by using the AWS CLI.
The following are examples of tagging in Region switch by using the AWS CLI.
`aws arc-region-switch --region us-east-1 create-plan --plan-name example-plan --tags Region=IAD,Stage=Prod`
For more information, see [TagResource](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_TagResource.html) in the *Region Switch API Reference Guide* for Amazon Application Recovery Controller (ARC).
# Pricing for Region switch in ARC
You pay a fixed monthly cost per Region switch plan that you configure.
For detailed pricing information for ARC and pricing examples, see [ARC Pricing](https://aws.amazon.com/application-recovery-controller/pricing/).
# Best practices for Region switch in ARC
We recommend the following best practices for recovery and failover preparedness with Region switch in Amazon Application Recovery Controller (ARC).
**Topics**
+ [Keep purpose-built, long-lived AWS credentials secure and always accessible](#RSBestPracticeCredentials)
+ [Choose lower TTL values for DNS records involved in failover](#RSBestPracticeLowerTTL)
+ [Reserve required capacity for critical applications](#RSBestPracticeCapacity)
+ [Use the extremely reliable data plane API operations to list and get information about Region switch plans](#RSBestPracticeUseDataPlane)
+ [Test failover with ARC](#RSBestPracticeTestFailover)
**Keep purpose-built, long-lived AWS credentials secure and always accessible**
In a disaster recovery (DR) scenario, keep system dependencies to a minimum by using a simple approach to accessing AWS and performing recovery tasks. Create [ IAM long-lived credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html) specifically for DR tasks, and keep the credentials securely in an on-premises physical safe or a virtual vault, to access when needed. With IAM, you can centrally manage security credentials, such as access keys, and permissions for access to AWS resources. For non-DR tasks, we recommend that you continue to use federated access, using AWS services such as [AWS Single Sign-On](https://aws.amazon.com/single-sign-on/).
**Choose lower TTL values for DNS records involved in failover**
For DNS records that you might need to change as part of your failover mechanism, especially records that are health checked, using lower TTL values is appropriate. Setting a TTL of 60 or 120 seconds is a common choice for this scenario.
The DNS TTL (time to live) setting tells DNS resolvers how long to cache a record before requesting a new one. When you choose a TTL, you make a trade-off between latency and reliability, and responsiveness to change. With a shorter TTL on a record, DNS resolvers notice updates to the record more quickly because the TTL specifies that they must query more frequently.
For more information, see *Choosing TTL values for DNS records* in [Best practices for Amazon Route 53 DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html).
**Reserve required capacity for critical applications**
Region switch includes execution block types that help scale compute resources as part of recovery. If you use these execution blocks in a plan, Region switch does not guarantee that the desired compute capacity with be attained. If you have a critical application and need to guarantee access to capacity, we recommend that you reserve the capacity.
There are strategies that you can follow to reserve compute capacity in a secondary Region while also limiting cost. To learn more, see [ Pilot light with reserved capacity: How to optimize DR cost using On-Demand Capacity Reservations](https://aws.amazon.com/blogs/architecture/pilot-light-with-reserved-capacity-how-to-optimize-dr-cost-using-on-demand-capacity-reservations/).
**Use the extremely reliable data plane API operations to list and get information about Region switch plans**
Use data plane API operations to work with and execute your Region switch plan during an event. For a list of Region switch data plane operations, see [Region switch API operations](actions.region-switch.md).
The Region switch console in each Region uses data plane operations for executing Region switch plans. You can also call data plane API operations by using the AWS CLI or by running code that you write using one of the AWS SDKs. ARC offers extreme reliability with the API in the data plane.
**Test application recovery with ARC**
Test application recovery regularly with ARC Region switch, to activate a secondary application stack in another AWS Region, or to switch over an active-active configuration by running a Region switch plan to deactivate one of the Regions.
It's important to make sure that the Region switch plans that you've created are aligned with the correct resources in your stack, and that everything works as you expect it to. You should test this after you set up Region switch for your environment, and continue to test periodically, so that you validate that your recovery processes work correctly. Do this testing regularly, before you experience a failure situation, to help avoid downtime for your users.
**ARC Region switch DNS failover versus Route 53 Accelerated recovery**
Accelerated recovery provides a target RTO of 60-minutes for APIs used to update your public hosted zone records that are enabled for this capability. If you need to maintain control over your RTO and not wait for AWS to complete recovery of the APIs needed, you should use ARC Routing control or ARC Region switch Route 53 health check execution block.
# Tutorial: Create an active/passive Region switch plan
This tutorial guides you through creating an active/passive Region switch plan for an application running in us-east-1 and recovering into us-west-2. The example includes Amazon EC2 instances for compute, Amazon Aurora Global Database for storage, and Amazon Route 53 for DNS.
In this tutorial, you'll complete the following steps:
+ Create a Region switch plan
+ Build the plan's workflows and execution blocks
+ Build an EC2 Auto Scaling group execution block
+ Build two manual approval execution blocks
+ Build two custom action Lambda execution blocks
+ Build an Amazon Aurora Global Database execution block
+ Build an ARC routing control block
+ Execute the Region switch plan
## Prerequisites
Before you begin this tutorial, verify that you have the following prerequisites in both Regions:
+ IAM roles with appropriate permissions
+ EC2 Auto Scaling groups
+ Lambda functions for maintenance page and fencing
+ Aurora Global Database
+ ARC routing controls
## Step 1: Create the Region switch plan
1. From the Region switch console, choose **Create Region switch plan**.
1. Provide the following details:
+ **Primary Region**: Choose us-east-1
+ **Standby Region**: Choose us-west-2
+ **Desired recovery time objective (RTO)** (optional)
+ **IAM role**: Enter the plan execution IAM role. This IAM role allows Region switch to call AWS services during execution.
1. Choose **Create**.
(Optional) Add resources from different AWS accounts to your Region switch plan:
1. Create the cross-account role:
+ In the account hosting the resource, create an IAM role.
+ Add permissions for the specific resources that the plan will access.
+ Add a trust policy that allows the execution role to assume the new role.
+ Enter and take note of an external ID that you will use as a shared secret.
1. Configure the resource in your plan:
+ When you add the resource to your plan, specify two additional fields:
+ **crossAccountRole**: The ARN of the role that you created in step 1
+ **externalId**: The external ID that you entered in step 1
Example configuration for an EC2 Auto Scaling execution block accessing resources in account 987654321:
```
{
"executionBlock": "EC2AutoScaling",
"name": "ASG",
"crossAccountRole": "arn:aws:iam::987654321:role/RegionSwitchCrossAccountRole",
"externalId": "unique-external-id-123",
"autoScalingGroupArn": "arn:aws:autoscaling:us-west-2:987654321:autoScalingGroup:*:autoScalingGroupName/CrossAccountASG"
}
```
Required permissions:
+ The execution role must have sts:AssumeRole permission for the cross-account role.
+ The cross-account role must have permissions only for the specific resources being accessed.
+ The cross-account role's trust policy must include:
+ The execution role's account as a trusted entity.
+ The external ID condition.
+ For more information on configuring a cross-account role, see [Cross-account resource permissions](security_iam_region_switch_cross_account.md).
Before executing the plan, Region switch will verify the following:
+ The execution role can assume the cross-account role.
+ The cross-account role has the required permissions.
+ The external ID matches the trust policy.
## Step 2: Build the plan's workflows and execution blocks
1. From the Region switch plan details page, choose **Build workflows**.
1. Select **Build the same activation workflow for all Regions**.
1. Enter a Region activation workflow description (optional). This will be used to easily identify the workflow when executing the plan.
1. Choose **Save and continue**.
### Add EC2 Auto Scaling execution block
For more information about this execution block, see [Amazon EC2 Auto Scaling group execution block](ec2-auto-scaling-block.md).
1. Choose **Add a step**, and then select **Run in sequence**.
1. Select the **EC2 Auto Scaling execution block**, and then choose **Add and edit**. This block will allow you to start increasing capacity in the passive Region.
1. In the right panel, configure the block:
+ **Step name**: Enter "Scale"
+ **Step description** (optional)
+ **Auto Scaling group ARN for us-east-1**: The ARN of your ASG in us-east-1
+ **Auto Scaling group ARN for us-west-2**: The ARN of your ASG in us-west-2
+ **Percent to match the source Region's capacity**: Enter 100
+ **Capacity monitoring approach**: Leave as "Most recent"
+ **Timeout** (optional)
For information about the required IAM permissions for this execution block, see [EC2 Auto Scaling execution block sample policy](security_iam_region_switch_ec2_autoscaling.md).
1. Choose **Save step**.
### Add manual approval execution block
For more information about this execution block, see [Manual approval execution block](manual-approval-block.md).
1. Choose **Add a step**.
1. Select the **Manual approval execution block** and add it to the design window. This block allows for human verification before proceeding.
1. In the right panel, configure the block:
+ **Step name**: Enter "Manual approval before setup"
+ **Step description** (optional)
+ **IAM approval role**: The role a user must assume in order to approve the execution
+ **Timeout** (optional). After timeout, execution pauses and you can choose to retry, skip, or cancel.
For information about the required IAM permissions for this execution block, see [Manual approval execution block sample policy](security_iam_region_switch_manual_approval.md).
1. Choose **Save step**.
### Add custom action Lambda execution block for maintenance page
For more information about this execution block, see [Custom action Lambda execution block](custom-action-lambda-block.md).
1. Choose **Add a step**.
1. Select the **Custom action Lambda execution block**, and then choose **Add and edit**. This block publishes a maintenance page in the Region that is activating.
1. In the right panel, configure the block:
+ **Step name**: Enter "Display maintenance page"
+ **Step description** (optional)
+ **Lambda ARN for activating us-east-1**: The ARN of the maintenance page Lambda function deployed in us-east-1
+ **Lambda ARN for activating us-west-2**: The ARN of the maintenance page Lambda function deployed in us-west-2
+ **Region to run the Lambda function**: Choose **Run in activating Region**
+ **Timeout** (optional)
+ **Retry interval** (optional)
For information about the required IAM permissions for this execution block, see [Custom action Lambda execution block sample policy](security_iam_region_switch_lambda.md).
1. Choose **Save step**.
### Add Aurora Global Database execution block
For more information about this execution block, see [Amazon Aurora Global Database execution block](aurora-global-database-block.md).
1. Choose **Add a step**.
1. Select the **Aurora Global Database execution block**, and then choose **Add and edit**. This block triggers an Aurora global database switchover (no data loss). For more information, see [Using switchover or failover for Aurora Global Database](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html) in the *Aurora User Guide*.
1. In the right panel, configure the block:
+ **Step name**: Enter **Aurora switchover**
+ **Step description** (optional)
+ **Aurora global database identifier**: The name of the Aurora cluster
+ **Cluster ARN used for activating us-east-1**: The Aurora cluster ARN in us-east-1
+ **Cluster ARN used for activating us-west-2**: The Aurora cluster ARN in us-west-2
+ **Select the option for Aurora database**: Choose **Switchover**
+ **Timeout** (optional)
For information about the required IAM permissions for this execution block, see [Aurora Global Database execution block sample policy](security_iam_region_switch_aurora.md).
1. Choose **Save step**.
### Add ARC routing control execution block
For more information about this execution block, see [ARC routing control execution block](arc-routing-controls-block.md).
1. Choose **Add a step**.
1. Select **ARC routing control execution block**, and then choose **Add and edit**. This block performs a DNS failover to shift traffic to the passive Region.
1. In the right panel, configure the block:
+ **Step name**: Enter **Toggle DNS**
+ **Step description** (optional)
+ **Routing controls used in activating us-east-1**: Choose **Add routing controls**
+ **Timeout**: Enter a timeout value.
1. Choose **Add routing control**:
+ **Routing control ARN**: The ARN of the routing control that controls us-east-1
+ **Routing control state**: Choose **On**
1. Choose **Add routing control** again:
+ **Routing control ARN**: The ARN of the routing control that controls us-west-2
+ **Routing control state**: Choose **Off**
1. Choose **Save**.
1. **Routing controls used in activating us-west-2**: Choose **Add routing controls**
1. Choose **Add routing control**:
+ **Routing control ARN**: The ARN of the routing control that controls us-west-2
+ **Routing control state**: Choose **On**
1. Choose **Add routing control** again:
+ **Routing control ARN**: The ARN of the routing control that controls us-east-1
+ **Routing control state**: Choose **Off**
1. Choose **Save**.
1. Choose **Save step**.
For information about the required IAM permissions for this execution block, see [ARC routing controls execution block sample policy](security_iam_region_switch_arc_routing.md).
1. Choose **Save**.
## Step 3: Execute the plan
1. On the Region switch plan details page, in the top right, choose **Execute**.
1. Enter the execution details:
+ Select the Region to activate.
+ Select the plan execution mode.
+ (Optional) View the execution steps.
+ Acknowledge the plan execution.
1. Choose **Start**.
1. You can view detailed steps as the plan executes on the execution details page. You can see each step in the plan execution, including start time, end time, resource ARN, and log messages.
When the impaired Region has recovered, you can execute the plan again (changing the parameters that you provide) to activate the original Region, to switch back your application operations to the original primary Region.
# Tutorial: Configure plan execution report autogeneration
This tutorial guides you through configuring plan execution report autogeneration for a Region switch plan. Reports provide comprehensive PDF documentation of plan executions for compliance purposes.
In this tutorial, you'll complete the following steps:
+ Create an Amazon S3 bucket for report storage
+ Enable report autogeneration on a Region switch plan
+ Execute the plan and download the report
## Prerequisites
Before you begin this tutorial, verify that you have the following:
+ An existing Region switch plan with configured workflows
+ Permissions to create Amazon S3 buckets
+ Your plan's execution IAM role configured with the required permissions. For more information, see [Automatic plan execution reports permissions](security_iam_region_switch_reports.md).
## Step 1: Create an Amazon S3 bucket for reports
1. Open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Choose **Create bucket**.
1. Provide the following details:
+ **Bucket name**: Enter a unique name, such as `my-region-switch-reports`
+ **Block Public Access settings**: Keep all public access blocked (recommended)
+ **Bucket Versioning**: Enable versioning (optional but recommended)
+ **Default encryption**: Select the encryption. If using SSM-KMS, the planExecutionRole needs kms:Encrypt and kms:GenerateDataKey permissions on the s3 bucket's default CMK
1. Choose **Create bucket**.
1. Note the bucket name for use in the next step.
## Step 2: Enable report autogeneration on your plan
1. Open the Region switch console at [https://console.aws.amazon.com/route53recovery/regionswitch/home](https://console.aws.amazon.com/route53recovery/regionswitch/home).
1. Select the plan you want to configure reports for.
1. Choose **In the navigation bar, go to Actions and select Edit plan details**.
1. In the **Report settings** section, provide the following:
+ Select **Enable report autogeneration**
+ **Amazon S3 URI:** Select or enter the bucket S3 URI you created in Step 1
+ **Account ID that owns bucket:** Enter the bucket owner account ID
1. Choose **Save**.
1. Wait for plan evaluation to complete. If there are any configuration issues, warnings will appear on the plan details page.
## Step 3: Execute the plan and download the report
1. On the plan details page, choose **Execute**.
1. Complete the plan execution as normal, selecting the Region to activate and execution mode.
1. After the plan execution completes, navigate to the execution details page.
1. In the **Plan execution report** section, monitor the report generation status. Report generation typically completes within 30 minutes of execution completion.
1. When the report status shows **Completed**, choose **Download plan execution report** to download the PDF.
1. Alternatively, navigate to your Amazon S3 bucket to access the report directly. Reports are stored with the following naming pattern: `ExecutionReport-${planVersion.ownerAccountId}-${planName}-${execution.regionTo}-${event.executionId}-${dateStr}.pdf`
The generated report includes:
+ Executive summary with service overview and report creation date
+ Plan configuration details as they existed at execution time
+ Detailed execution timeline with steps, affected resources, and statuses
+ Plan warnings that were present when the execution started
+ Amazon CloudWatch alarm states and alarm history for associated alarms
+ For parent plans, configuration and execution details of child plans
+ Glossary of terms and concepts
## Troubleshooting
If report generation fails, check the following:
+ **Permission errors**: Verify that the execution role has the correct IAM permissions. For more information, see [Automatic plan execution reports permissions](security_iam_region_switch_reports.md). Check the plan evaluation warnings for specific permission issues.
+ **Amazon S3 bucket access**: Ensure the Amazon S3 bucket exists and is accessible from the Region where the plan is configured. Verify that bucket policies don't block access from the execution role.
+ **Bucket encryption**: If using customer-managed KMS keys for bucket encryption, ensure the execution role has permissions to use the KMS key.
For additional help, view detailed error messages on the execution details page or contact AWS Support.
# Tutorial: Execute an RDS post-recovery workflow
This tutorial guides you through executing a post-recovery workflow after a successful RDS failover. This post-recovery execution restores redundancy by re-establishing cross-Region replication for the RDS database, ensuring your RDS database is prepared for future regional events.
In this tutorial, you'll complete the following steps:
+ Verify prerequisites for post-recovery execution
+ Create a post-recovery workflow with RDS Create Cross-Region Replica execution block
+ Execute the post-recovery workflow
## Prerequisites
Before you begin this tutorial, verify that you have the following:
+ A Region switch active/passive plan with an activate workflow that includes an RDS Promote Read Replica execution block
+ A successful activate execution that promoted a read replica in the other Region
+ Both Regions are healthy and accessible
+ The execution ID from the most recent recovery execution
## Step 1: Create a post-recovery workflow
1. From the Region switch console choose the plan, choose **Edit workflows**, select **Config**, check **Include post recovery workflow in the plan** and save.
1. In the Edit workflows page, Select the **Select a workflow to add steps** drop down and choose **Post-recovery**.
1. Choose **Add a step**.
1. Select the **Amazon RDS create cross Region replica execution block**.
1. In the right panel, configure the block:
+ **Step name**: Enter "Create cross-Region read replica"
+ **Step description** (optional)
+ **RDS DB instance ARN for primary Region**: The ARN of the database in primary Region, should be the same as the promote read replica step
+ **RDS DB instance ARN for secondary Region**: The ARN of the promoted database in secondary, should be the same as the promote read replica step
+ **Timeout** (optional): Enter a timeout value, such as 90 minutes
For information about the required IAM permissions for this execution block, see [Amazon RDS execution block sample policy](security_iam_region_switch_rds.md).
1. Choose **Save step**.
1. Choose **Save workflow**.
## Step 2: Execute the post-recovery workflow
1. On the Region switch plan details page, in the top right, choose **Execute post-recovery**.
1. Enter the execution details:
+ **Recovery execution ID**: Enter the execution ID of the most recent recovery execution. This field is used to identify the Region that is active currently.
+ **Region to execute in**: Select the inactive Region which is not receiving any application traffic. This is the Region where a read replica will be created.
1. Review the execution steps and acknowledge the execution.
1. Choose **Start Execution**.
1. Monitor the execution progress on the execution details page. The RDS Create Cross-Region Replica execution block will rename your old primary instance and create a new read replica in the previously impaired Region.
After the post-recovery execution completes successfully, your application will have cross-Region replication re-established, and you'll be prepared for future regional events. You can verify if the new read replica was created by checking the RDS console in the target Region. The old primary will be renamed and tagged with *renamedByRegionSwitch*.
**Important**
Region switch validates that the recovery execution ID matches the last known execution for the plan. If the execution ID is invalid or is not ID of the last known recovery execution, the post-recovery execution will not run.
# Region switch API operations
The following table lists ARC operations that you can use for Region switch, with links to relevant documentation.
| Action | Using the ARC console | Using the ARC API | Data plane API |
| --- | --- | --- | --- |
| Approve or deny a plan execution step | See [Manual approval execution block](manual-approval-block.md) | See [ApprovePlanExecutionStep](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ApprovePlanExecutionStep.html) | Yes |
| Cancel a plan execution | See [Create a Region switch plan](working-with-rs-create-plan.md) | See [CancelPlanExecution](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_CancelPlanExecution.html) | Yes |
| Create a plan | See [Create a Region switch plan](working-with-rs-create-plan.md) | See [CreatePlan](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_CreatePlan.html) | No |
| Delete a plan | See [Working with Region switch](working-with-rs.md) | See [DeletePlan](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_DeletePlan.html) | No |
| Get a plan | See [Working with Region switch](working-with-rs.md) | See [GetPlan](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_GetPlan.html) | No |
| Get plan evaluation status | See [Plan evaluation](region-switch-plans.md#region-switch-plans.plan-evaluation) | See [GetPlanEvaluationStatus](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_GetPlanEvaluationStatus.html) | Yes |
| Get a plan execution | See [Region switch dashboards](region-switch.dashboarding-and-reports.md) | See [GetPlanExecution](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_GetPlanExecution.html) | Yes |
| Get a plan in Region | See [Working with Region switch](working-with-rs.md) | See [GetPlanInRegion](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_GetPlanInRegion.html) | Yes |
| List plan execution events | See [Execute a Region switch plan to recover an application](plan-execution-rs.md) | See [ListPlanExecutionEvents](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListPlanExecutionEvents.html) | Yes |
| List plan executions | See [Execute a Region switch plan to recover an application](plan-execution-rs.md) | See [ListPlanExecutions](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListPlanExecutions.html) | Yes |
| List plans | See [Working with Region switch](working-with-rs.md) | See [ListPlans](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListPlans.html) | No |
| List plans in Region | See [Working with Region switch](working-with-rs.md) | See [ListPlansInRegion](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListPlansInRegion.html) | Yes |
| List Route 53 health checks for a plan | See [Amazon Route 53 health check execution block](route53-health-check-block.md) | See [ListRoute53HealthChecksForPlan](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListRoute53HealthChecks.html) | No |
| List Route 53 health checks for a plan in Region | See [Amazon Route 53 health check execution block](route53-health-check-block.md) | See [ListRoute53HealthChecksForPlanInRegion](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListRoute53HealthChecksInRegion.html) | Yes |
| List tags for a resource | See [Tagging for ARC Region switch;](tagging.region-switch.md) | See [ListTagsForResource](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListTagsForResource.html) | No |
| Start a plan execution | See [Execute a Region switch plan to recover an application](plan-execution-rs.md) | See [StartPlanExecution](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_StartPlanExecution.html) | Yes |
| Tag a resource | See [Create a Region switch plan](working-with-rs-create-plan.md) | See [TagResource](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_TagResource.html) | No |
| Remove tags from a resource | See [Tagging for ARC Region switch;](tagging.region-switch.md) | See [UntagResource](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_UntagResource.html) | No |
| Update a plan | See [Create a Region switch plan](working-with-rs-create-plan.md) | See [UpdatePlan](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_UpdatePlan.html) | No |
| Update a plan execution | See [Create a Region switch plan](working-with-rs-create-plan.md) | See [UpdatePlanExecution](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_UpdatePlanExecution.html) | Yes |
| Update a plan execution step | See [Create a Region switch plan](working-with-rs-create-plan.md) | See [UpdatePlanExecutionStep](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_UpdatePlanExecutionStep.html) | Yes |
# Working with Region switch
This section provides step-by-step instructions for working with Region switch plans, which you can use to recover multi-Region applications. Region switch enables you to create plans for both active/passive and active/active recovery approaches.
To create a recovery plan for your application, you do the following:
1. Create a Region switch plan. A plan is a structure with certain attributes, such as the specific AWS Regions that your application runs in. Each plan includes one or more *workflows*.
Optionally, you can create several plans, and nest those *child plans* within an overall recovery plan.
1. Create a workflow for the plan. You can’t execute a plan without creating a workflow first.
1. In the workflow, add one or more steps that are each an *execution block*.
For example, you could add a step to scale up EC2 Auto Scaling groups in a destination Region.
1. After you add steps to your workflow, additional steps might be required, such as configuring health checks in Amazon Route 53. Each execution block section includes the configuration information that you need. For more information, see [Add execution blocks](working-with-rs-execution-blocks.md).
1. To recover your application when it's running in an impaired AWS Region, execute the plan.
You can track the progress of a plan execution by viewing information in the global dashboard or a Regional dashboard.
The following sections provide detailed information and steps for creating a plan and workflows, and adding execution block steps in your workflows.
**Topics**
+ [Create a plan](working-with-rs-create-plan.md)
+ [Create workflows](working-with-rs-workflows.md)
+ [Add execution blocks](working-with-rs-execution-blocks.md)
+ [Create child plans](working-with-rs-child-plan.md)
+ [Create triggers](working-with-rs-triggers.md)
+ [Execute a plan](plan-execution-rs.md)
The procedures in this section illustrate how to work with plans, workflows, execution blocks, and triggers by using the AWS Management Console. To work with Region switch API operations instead, see [Region switch API operations](actions.region-switch.md).
# Create a Region switch plan
You can create two different kinds of plans in Region switch: an active/active plan or an active/passive plan. When you create a plan, specify the type that applies to how you want to manage failover.
+ An *active/passive* approach deploys two application replicas into two Regions, with traffic routed to the active Region only. You can activate the replica in the passive Region by executing the Region switch plan.
+ An *active/active* approach deploys two application replicas into two Regions, and both replicas are processing work or receiving traffic.
# To create a Region switch plan
1. From the Region switch console, choose **Create Region switch plan** with active/passive approach.
1. Provide the following details:
+ **Plan name** - Enter a descriptive name for your plan.
+ **Multi-Region approach** - Select **Active/passive** or **Active/active**. This approach means two application replicas are deployed into two Regions, with traffic routed into the active Region only. You can activate the replica in the passive Region by executing the Region switch plan.
+ Choose **active/passive** if you have deployed two application replicas into two Regions, with traffic routed to the active Region only. Then, you can activate the replica in the passive Region by executing the Region switch plan that specifies *Active/passive*.
+ Choose **Active/active** if you have deployed two application replicas into two Regions, and both replicas are processing work or receiving traffic.
+ **Primary and standby Regions** or **Regions** - Select the primary and standby Regions for your application. For an active/active deployment, select the Regions where the replicas are deployed.
+ **Recovery time objective (RTO)** - Enter your desired RTO. Region switch uses this to provide insight into how long Region switch plan executions take to complete in comparison to your desired RTO.
+ **IAM role** - Provide an IAM role for Region switch to use to execute the plan. For more information about permissions, see [Identity and Access Management for Region switch in ARC](security-iam-region-switch.md).
+ **Amazon CloudWatch alarm** - Provide an application health alarm that you've created with Amazon CloudWatch, to indicate the health of your application in each Region. Region switch uses these application health alarms to help determine the actual recovery time after you switch Regions to implement recovery.
Before you add CloudWatch alarms to a Region switch plan, make sure that you have the correct IAM policy in place. For more information, see [CloudWatch alarms for application health permissions](security_iam_region_switch_cloudwatch.md).
+ **Automatic report generation** - Optionally, enable automatic report generation for plan executions. When enabled, Region switch generates a comprehensive PDF report after each plan execution completes and delivers it to an Amazon S3 bucket that you specify. Provide the Amazon S3 URI and the account ID that owns the bucket.
Before enabling automatic report generation for plans, make sure that you have the correct IAM policy in place. For more information about report generation and required permissions, see [Automatic plan execution reports](region-switch-plans.md#region-switch-plans.plan-execution-reports).
+ **Tags** - Optionally, add one or more tags to your plan.
# Create Region switch plan workflows
After you create a Region switch plan, you need to define and create workflows that specify the recovery process for your application. For each plan, you define one or more workflows that complete recovery for your application. In each workflow, you add steps that include *execution blocks* that define each action you want Region switch to perform for your application recovery.
The number of workflows that you create depends on your application deployment scenario and your preferences for managing recovery. For example:
+ If your Region switch plan is for an active/active application deployment, you also need to create a deactivation workflow. This means that for or active/active deployments, you'll have a minimum of two workflows: an activation workflow and a deactivation workflow.
+ If your Region switch plan is for an active/passive application deployment, you have a primary and a secondary Region. If you choose to have separate activation workflows for each Region, you'll create two workflows: one for each Region.
# To create Region switch plan workflows
1. In the Region switch plan that you created, choose **Build workflows**.
1. Select one of the following workflow options:
+ **Build the same activation workflow for all Regions** - Enables you to use the same activation workflow across Regions.
+ **Build workflows separately for each Region** - Builds an individual activation workflow for each Region.
1. Optionally, provide a description for each workflow.
1. Define the workflow required to recover your application. In your workflow, you add *execution blocks* to define the steps that you want Region switch to perform for your recovery. Each execution block defines actions, such as application traffic rerouting or database recovery in an activating Region, and supports resources in another AWS account. You can opt to have execution blocks run in parallel or sequentially. For detailed information about the specific execution blocks that you can add to workflows, see [Add execution blocks](working-with-rs-execution-blocks.md).
1. Depending on the workflow option that you selected, do the following:
+ If you selected **Build the same activation workflow for all Regions**, one activation workflow is required.
+ If you selected **Build workflows separately for each Region**, two activation workflows are required.
For active/active plans, you must define both an activation workflow and a deactivation workflow.
# Add execution blocks
You add steps to workflows in your Region switch plan, to perform the individual steps to complete failover or switchover for your application. For details about the functionality and behavior of each type of execution block, see the following descriptions.
Region switch runs a plan evaluation immediately after you create a plan or update it, and then every 30 minutes during steady state. Region switch stores information about plan evaluation in all the Regions where your plan is configured. Each execution block section here includes information about what is evaluated when Region switch runs plan evaluation.
Region switch includes execution block types that help scale compute resources as part of recovery. If you use these execution blocks in a plan, be aware that Region switch does not guarantee that the desired compute capacity with be attained. If you have a critical application and need to guarantee access to capacity, we recommend that you reserve the capacity. There are strategies that you can follow to reserve compute capacity in a secondary Region while also limiting cost. To learn more, see [ Pilot light with reserved capacity: How to optimize DR cost using On-Demand Capacity Reservations](https://aws.amazon.com/blogs/architecture/pilot-light-with-reserved-capacity-how-to-optimize-dr-cost-using-on-demand-capacity-reservations/).
Region switch supports the following execution blocks.
****
| Execution block | Function | Ungraceful configuration |
| --- | --- | --- |
| [ARC Region switch plan execution block](region-switch-plan-block.md) | Orchestrate recovery for multiple applications in one execution by specifying child plans to execute. | Start child plans with their ungraceful configurations. |
| [Amazon EC2 Auto Scaling group execution block](ec2-auto-scaling-block.md) | Scale EC2 compute resources that are in an Auto Scaling group as part of your plan execution. | Specify the minimum percentage of compute capacity that should be matched in the Region that you're activating. |
| [Amazon EKS resource scaling execution block](eks-resource-scaling-block.md) | Scale Amazon EKS cluster pods as part of your plan execution. | N/A |
| [Amazon ECS service scaling execution block](ecs-service-scaling-block.md) | Scale Amazon ECS service tasks as part of your plan execution. | N/A |
| [ARC routing control execution block](arc-routing-controls-block.md) | Add a step to change the state of one or more ARC routing controls, to redirect your application traffic to a target AWS Region. | N/A |
| [Amazon Aurora Global Database execution block](aurora-global-database-block.md) | Perform a recovery workflow for an Aurora global database. | Perform an Aurora global databases failover (can potentially cause data loss). |
| [Amazon DocumentDB Global Cluster execution block](documentdb-global-cluster-block.md) | Perform a recovery workflow for a Amazon DocumentDB global cluster. | Perform a Amazon DocumentDB global cluster failover (can potentially cause data loss). |
| [Amazon RDS Promote Read Replica execution block](rds-promote-read-replica-block.md) | Promote an Amazon RDS read replica to a standalone database instance. | N/A |
| [Amazon RDS Create Cross-Region Replica execution block](rds-create-cross-region-replica-block.md) | Create a cross-Region read replica for an Amazon RDS database instance as part of post-recovery. | N/A |
| [Manual approval execution block](manual-approval-block.md) | Insert an approval step, to require approval or cancellation of an execution before proceeding. | N/A |
| [Custom action Lambda execution block](custom-action-lambda-block.md) | Add a custom step for running a Lambda function, to enable custom actions. | Skip the step. |
| [Amazon Route 53 health check execution block](route53-health-check-block.md) | Specifies the Regions that your application traffic will be redirected to during failover. | N/A |
# ARC Region switch plan execution block
The Region switch plan execution block allows you to orchestrate the order in which multiple applications switch over to the Region that you want to activate, by referencing other, child Region switch plans. Using this parent/child relationship, you can create complex, coordinated recovery processes that manage multiple resources and dependencies across your infrastructure.
## Configuration
When you use the Region switch plan execution block, you select a specific Region switch plan that you want to be executed in the workflow of the plan you're creating.
**Important**
Before you configure the execution block, make sure that you have the correct IAM policy in place. For more information, see [Region switch plan execution block sample policy](security_iam_region_switch_plan_execution.md).
To configure a Region switch plan execution block, enter the following values:
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **Region switch plan: **Select a plan to execute in the workflow for the current plan.
Then, choose **Save step.**
## How it works
Use the Region switch plan execution block to create parent workflows with parent/child relationships. Note that this execution block does not support additional levels of child plans, and limits the number of parent child plans. Child plans must support the same Regions that the parent plan supports, and must have the same recovery approach as the parent plan (that is, active/active or active/passive).
This block supports both graceful and ungraceful execution modes. Ungraceful settings will start child plans with their ungraceful configuration. If Region switch block was executed gracefully, and then switched to ungraceful execution mode, any child plan will also switch to ungraceful execution mode.
## What is evaluated as part of plan evaluation
If you share a plan across accounts, and the plan is no longer shared with the account of the parent plan, Region switch evaluation returns a warning that the plan is not valid.
# Amazon EC2 Auto Scaling group execution block
The EC2 Auto Scaling group execution block allows you to scale EC2 instances as part of your multi-Region recovery process. You can define a percentage of capacity, relative to the Region you're leaving (source and destination).
## Configuration
When you configure the EC2 Auto Scaling group execution block, you enter the EC2 Auto Scaling ARNs for the specific Regions that are associated with your plan. You should enter EC2 Auto Scaling ARNs in each Region that you want to be scaled up during plan execution.
**Important**
Before you configure the execution block, make sure that you have the correct IAM policy in place. For more information, see [EC2 Auto Scaling execution block sample policy](security_iam_region_switch_ec2_autoscaling.md).
To configure a EC2 Auto Scaling group execution block, enter the following values:
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **EC2 Auto Scaling group ARN for *Region*: ** Enter the ARN for the EC2 Auto Scaling group in each Region for your plan.
1. **Percentage to match the activated Region's capacity: ** Enter the desired percentage of the number of running instances in the Auto Scaling group to match for the activated Region.
1. **Capacity monitoring approach: **Select one of the following approaches for monitoring capacity for your EC2 Auto Scaling groups:
+ **Max running capacity sampled over 24 hours**: Choose this option to use the **Desired capacity** value specified in your EC2 Auto Scaling group configuration. This option does not create additional costs, but is potentially less accurate than using the other option, CloudWatch metrics.
In the Region switch API, this option corresponds to specifying `sampledMaxInLast24Hours`.
For more information, see [Set scaling limits for your Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html) in the Amazon EC2 Auto Scaling User Guide.
+ **Max running capacity sampled over 24 hours with CloudWatch**: Choose this option to use metrics specified in Amazon CloudWatch for EC2 Auto Scaling. Using the option can be more accurate, but incurs the additional costs of using CloudWatch metrics.
In the Region switch API, this option corresponds to specifying `autoscalingMaxInLast24Hours`.
To use this option, you must first enable group metrics for your Auto Scaling groups. For more information, see [Enable Auto Scaling group metrics](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-metrics.html#as-enable-group-metrics) in the Amazon EC2 Auto Scaling User Guide.
1. **Timeout: **Enter a timeout value.
Then, choose **Save step.**
## How it works
After you configure an EC2 Auto Scaling execution block, Region switch confirms that there is only one source Auto Scaling group and one destination Auto Scaling group. If there are multiple Auto Scaling groups, the execution block fails during plan evaluation. The target capacity is defined as the number of instances have a state that is set to `InService`. For more information, see [ EC2 Auto Scaling instance lifecycle](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-lifecycle.html).
Based on the value that you specify (when you configure the Auto Scaling execution block) for a matching percentage, Region switch calculates the new desired capacity for the destination Auto Scaling group. The new desired capacity is compared against the destination Auto Scaling group's desired capacity. The formula that Region switch uses to calculate desired capacity is the following: `ceil(percentToMatch * Source Auto Scaling group capacity)`, where ceil() is a function that rounds up any fractional result. If the current desired capacity of the destination Auto Scaling group is greater than or equal to the desired capacity of the new Auto Scaling group that Region switch calculates, the execution block proceeds. Note that Region switch does not scale down Auto Scaling group capacity.
When Region switch executes an Auto Scaling block, Region switch attempts to scale up the target Region Auto Scaling group capacity to match the desired capacity. Then, Region switch waits until the requested Auto Scaling group capacity is fulfilled in the target Region's Auto Scaling group before Region switch proceeds to the next step in the plan.
**Note**
Executing this block modifies the minimum and desired capacity settings of your Auto Scaling groups, which may cause configuration drift if you manage these values through infrastructure-as-code tools or other automation. Ensure your configuration management processes account for these changes to prevent unintended rollbacks.
If you’re using an active/active approach, Region switch uses the other configured Region as the source. That is, if a Region is being deactivated, Region switch uses the other active Region as the source to match for the percent to scale.
This block supports both graceful and ungraceful execution modes. You can configure ungraceful execution by specifying the minimum percentage of compute capacity to be matched in the target Region before Region switch proceeds to the next step in the plan.
## What is evaluated as part of plan evaluation
When Region switch evaluates your plan, Region switch performs several critical checks on your EC2 Auto Scaling group execution block configuration and permissions. Region switch evaluation verifies that Auto Scaling groups are present in both Regions, ensures that they are properly configured and accessible, and notes the number of running instances in each Region. It also confirms that the maximum capacity in the target Region's Auto Scaling group is sufficient to handle the specified percentage match of scale for the required capacity.
Region switch also validates that the plan's IAM role has the correct permissions for Auto Scaling. For more information about the required permissions for Region switch execution blocks, see [Identity-based policy examples for Region switch in ARC](security_iam_id-based-policy-examples-region-switch.md). If any of the checks fail, Region switch returns warning messages, which you can view in the console. Or, you can receive the validation warnings through EventBridge or by using API operations.
# Amazon EKS resource scaling execution block
The EKS resource scaling execution block enables you to scale EKS resources as part of your multi-Region recovery process. When you configure the execution block, you define a percentage of capacity to scale, relative to the capacity in the Region that is being deactivated.
## Configure EKS access entry permissions
Before you can add a step for EKS resource scaling, you must provide Region switch with the necessary permissions to take actions with the Kubernetes resources in your EKS clusters. To provide access for Region switch, you must create an EKS access entry for the IAM role that Region switch uses for plan execution, by using the following Region switch access policy: `arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy`
### Region switch EKS access policy
The following information provides details about the EKS access policy.
**Name:** `AmazonARCRegionSwitchScalingPolicy`
**Policy ARN:** `arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy`
| Kubernetes API groups | Kubernetes resources | Kubernetes verbs (permissions) |
| --- | --- | --- |
| \$1 | \$1/scale | get, update |
| \$1 | \$1/status | get |
| autoscaling | horizontalpodautoscalers | get, patch |
### Create an EKS access entry for Region switch
The following example describes how to create the required access entry and access policy associations so that Region switch can take specific actions for your Kubernetes resources. In this example, the permissions apply to the namespace *my-namespace1* in the EKS cluster *my-cluster* for the IAM role `arn:aws:iam::555555555555:role/my-role`.
When you configure these permissions, make sure that you take these steps for both EKS clusters in your execution block.
**Prerequisite**
Before you get started, change the authentication mode of the cluster to either `API_AND_CONFIG_MAP` or `API`. Changing the authorization mode adds the API for access entries. For more information, see [Change authentication mode to use access entries](https://docs.aws.amazon.com/eks/latest/userguide/setting-up-access-entries.html) in the Amazon EKS User Guide.
**Create the access entry**
The first step is to create the access entry by using an AWS CLI command similar to the following:
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn
arn:aws:iam::555555555555:user/my-user --type STANDARD
```
For more information, see [Create access entries](https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html) in the Amazon EKS User Guide.
**Create the access entry association**
Next, create the association to the Region switch access policy by using an AWS CLI command similar to the following:
```
aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::555555555555:role/my-role \
--access-scope type=namespace,namespaces=my-namespace1 --policy-arn
arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy
```
For more information, see [Associate access policies with access entries](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html) in the Amazon EKS User Guide.
Make sure to repeat these steps with the second EKS cluster in your execution block, in the other Region, to ensure that both clusters can be accessed by Region switch.
## Configuration
**Important**
Before you add an EKS resource scaling step, first, make sure that you have the configured the correct permissions. For more information, see [Configure EKS access entry permissions](#eks-resource-scaling-block-permissions). Also make sure that you have the correct IAM policy in place. For more information, see [Amazon EKS resource scaling execution block sample policy](security_iam_region_switch_eks.md).
Note that Region switch currently supports the following ReplicaSet resources: apps/v1, Deployment, and apps/v1.
For the execution block configuration, enter the following values.
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **Application name: **Enter the name of your EKS application for example, *myApplication*.
1. **Kubernetes resource kind: **Enter the resource kind for the application, for example, *Deployment*.
1. **Resource for *Region*: **For each Region, enter information for the EKS cluster, including the EKS cluster ARN, resource namespace, and so on.
1. **Percentage to match the activated Region's capacity: ** Enter the desired percentage of running pods in the source Region to match in the activated Region.
1. **Capacity monitoring approach: **The only option for capacity monitoring is already selected, **Max running capacity sampled over 24 hours**.
This capacity monitoring approach uses the `ReplicaCount` value for EKS service requests. For more information, see [Learn about ARC zonal shift in Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/zone-shift.html) in the Amazon Elastic Kubernetes Service User Guide.
1. **Timeout: **Enter a timeout value.
Then, choose **Save step.**
## How it works
During a plan execution, Region switch retrieves the sampled maximum number of replicas over the previous 24 hours for the target resource in the Region you're activating. Then, it computes the desired replica count for the destination resource by using the following formula: `ceil(percentToMatch * Source replica count)`
If the destination ready replica count is lower than the desired value, Region switch scales the destination resource replica value to the desired capacity. It waits for the replicas to become ready, leveraging your node auto-scaler to increase node capacity if necessary.
If the optional `hpaName` field is not empty, Region switch patches the HorizontalPodAutoscaler to prevent any automatic scaledown during or after the execution by using the following patch: `{"spec":{"behavior":{"scaleDown":{"selectPolicy":"Disabled"}}}}`
Make sure to configure any drift-correcting tool, such as GitOps tooling, to ignore the replica field for the resources in the patch, as well as the HorizontalPodAutoscaler field.
## What is evaluated as part of plan evaluation
When Region switch evaluates your plan, Region switch performs several checks on your configured EKS execution block and permissions. Region switch verifies that the plan’s IAM role has the correct permissions to describe EKS clusters and list associated Access Entry policies. Region switch also validates that the IAM role is associated to the correct Access Entry policy, so that Region switch has the required permissions to act on the Kubernetes resources. Finally, Region switch confirms that the configured EKS clusters and Kubernetes resources exist.
In addition, Region switch checks that it has successfully collected and stored the necessary monitoring data (Kubernetes replica count) and captures the number of running pods that are required to execute the Region switch plan.
# Amazon ECS service scaling execution block
The ECS service scaling execution block allows you to scale your ECS service in a destination Region as part of your multi-Region recovery process. You can define a percentage of capacity, relative to the Region that Region switch fails over from or deactivates.
## Configuration
To configure the ECS service scaling execution block, enter the following values.
**Important**
Before you configure the execution block, make sure that you have the correct IAM policy in place. For more information, see [Amazon ECS service scaling execution block sample policy](security_iam_region_switch_ecs.md).
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **Resource for *Region*: **For each Region, enter the ECS cluster ARN and the ECS service ARN.
1. **Percentage to match the source Region's task count: ** Enter the desired percentage of running tasks in the source Region to match in the activated Region.
1. **Capacity monitoring approach: **Select one of the following approaches for monitoring capacity for Amazon ECS:
+ **Max running capacity sampled over 24 hours**: Choose this option to use the **running tasks count** value in your Amazon ECS service. This option does not create additional costs, but is potentially less accurate than using the other option, CloudWatch metrics.
In the Region switch API, this option corresponds to specifying `sampledMaxInLast24Hours`.
For more information, see [Automatically scale your Amazon ECS service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) in the Amazon Elastic Container Service Developer Guide.
+ **Max running capacity sampled over 24 hours via container insights**: Choose this option to use Amazon ECS Container Insights metrics. Using the option can be more accurate, but incurs the additional costs of using Container Insights.
In the Region switch API, this option corresponds to specifying `autoscalingMaxInLast24Hours`.
To use this option, you must first enable Container Insights. For more information, see [ Set up Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS-cluster.html#set-container-insights-ECS-cluster) in the Amazon CloudWatch User Guide.
1. **Timeout: **Enter a timeout value.
Then, choose **Save step.**
## How it works
After you configure the execution block in your plan, Region switch confirms that there is only one source ECS service and one destination service. If there are multiple services, Region switch returns a warning for the execution block. Region switch stores this data in all Regions your plan is configured for. The target capacity is defined as the desired count set on your ECS service.
For an active/passive approach, Region switch calculates the new desired capacity for the ECS service in the destination (activating) Region. The new desired capacity is compared against the destination ECS service's desired capacity. The formula that Region switch uses to calculate desired capacity is the following: `ceil(percentToMatch * Source Auto Scaling group capacity)`, where ceil() is a function that rounds up any fractional result. If the current desired count for the destination ECS service is higher than the calculated new desired capacity for the ECS service, the plan execution proceeds. Note that Region switch does not scale down ECS service capacity.
If the ECS service has Application Autoscaling enabled, Region switch updates the minimum capacity in Application Autoscaling, and also updates the desired count in the ECS service.
When Region switch executes an ECS service block, Region switch attempts to scale up the target Region ECS capacity to match the desired capacity. Then, Region switch waits until the requested ECS service capacity is fulfilled in the target Region's ECS service before Region switch proceeds to the next step in the plan. If you like, you can configure the step to complete before fulfillment is complete by setting a timeout limit for how long Region switch waits for capacity fulfillment.
If you’re using an active/active approach, Region switch uses the other configured Region as the source. That is, if a Region is being deactivated, Region switch uses the other active Region as the source to match for the percent to scale.
## What is evaluated as part of plan evaluation
When Region switch evaluates your plan, Region switch performs several checks on your ECS service execution block configuration and permissions. Region switch verifies that ECS services are present in both the source and target Regions, and checks to make sure that the maximum capacity set for the target Region's ECS service is sufficient to handle the specified percentage match of the target Region's capacity. Region switch also validates that the plan's IAM role has the correct permissions for ECS service. For more information about the required permissions for Region switch execution blocks, see [Identity-based policy examples for Region switch in ARC](security_iam_id-based-policy-examples-region-switch.md).
In addition, Region switch checks that the `ResourceMonitor` has successfully collected and stored the necessary monitoring data for the ECS services, and captures a count of the number of running tasks.
If any of the checks fail, Region switch returns warning messages, which you can view in the console. Or, you can receive the validation warnings through EventBridge or by using API operations.
# ARC routing control execution block
If you've configured Amazon Application Recovery Controller (ARC) routing control for your application, you can add a ARC routing control step to redirect application traffic. This step enables you to change the state of one or more ARC routing controls to redirect your application traffic to a destination AWS Region. ARC routing control redirects traffic by using health checks in Amazon Route 53 that are configured with the DNS records associated with the routing controls.
**Important**
Amazon Application Recovery Controller (ARC) routing control is only available in the AWS commercial partition.
## Configuration
To configure a routing control execution block, enter the following values.
**Important**
Before you configure the execution block, make sure that you have the correct IAM policy in place. For more information, see [ARC routing controls execution block sample policy](security_iam_region_switch_arc_routing.md).
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **Desired routing controls: ** For each Region that you want to activate or deactivate, enter the routing control ARN and the initial state for the routing control, On or Off.
1. **Timeout: **Enter a timeout value.
Then, choose **Save step.**
The expected pattern for this execution block is to specify routing controls and initial states that align with how you have set up your application in specific AWS Regions. For example, if you have plan that enables you to activate Region A and Region B for your application, then you might have a routing control for Region A where you set the state to On and a routing control for Region B where you set the state to On.
Then, when you execute the plan and specify that you want to activate Region A, the workflow that includes this execution block updates the specified routing control to On, which directs traffic to Region A.
## How it works
By configuring a ARC routing control execution block, you can reroute application traffic to a destination AWS Region, or, for an active/active approach, stop traffic from being routed to a Region that you're deactivating. If your plan includes multiple workflows, make sure that you provide the same inputs for the DNS records for all routing control execution blocks that you use.
This block does not support ungraceful execution mode.
## What is evaluated as part of plan evaluation
When Region switch evaluates your plan, Region switch performs several checks on your routing controls execution block configuration and permissions. Region switch verifies that the specified routing controls are properly configured and accessible.
Region switch also validates that the plan's IAM role has the required permissions for accessing and updating routing control states. For more information about the required permissions for Region switch execution blocks, see [Identity-based policy examples for Region switch in ARC](security_iam_id-based-policy-examples-region-switch.md).
The correct IAM permissions are essential for the proper functioning of the routing control execution block. If any of these validations fail, Region switch returns warnings that there are issues, and provides specific error messages to help you resolve the permissions or configuration issues. This ensures that your plan has the necessary access to manage and interact with the ARC routing controls during when this step runs during a plan execution.
## Comparing ARC routing controls and Route 53 health check execution blocks
The Amazon Route 53 health check execution block in Region switch provides a lower-cost alternative for DNS-based traffic management. However, this execution block depends on the AWS Region that you're activating, so that Region must be available. This meets the needs of most customers, because they are activating a healthy Region.
ARC routing controls provide highly reliable DNS-based traffic management with a 100% availability SLA. With routing controls, your operations teams can shift traffic between Regions with safety guardrails. Routing controls provide a single-tenant solution with a 100% SLA. A routing control cluster is spread across five Regions and can tolerate two Regions being offline. If you have highly critical applications, consider using routing controls.
Routing controls are not required to use Region switch. You can use Region switch to manage traffic redirection by using Route 53 health check execution blocks without routing controls.
Routing controls add value with Region switch in the following situations:
+ You require the 100% availability SLA for the traffic control mechanism itself.
+ Your organization requires manual operational controls with safety rules for critical applications.
+ You want defense-in-depth so that operations teams can manually override automated traffic routing if needed.
Route 53 health check execution blocks do not depend on the control plane. Health check record changes use the data plane, so they do not require the activating Region to process configuration updates. Route 53 health check execution blocks are sufficient in the following situations:
+ Your application can depend on the AWS Region that you are activating.
+ Automated traffic redirection as part of the recovery workflow meets your requirements.
+ Cost optimization is a priority. Route 53 health check execution blocks have lower cost than routing controls.
Most customers start with Route 53 health check execution blocks as the default traffic routing mechanism and add routing controls only for their most critical applications that require the highest reliability for the traffic management mechanism.
# Amazon Aurora Global Database execution block
The Amazon Aurora Global Database execution block allows you to perform a *failover* or *switchover* recovery workflow for a global database.
+ Failover – Use this approach to recover from an unplanned outage. With this approach, you perform a cross-Region failover to one of the secondary DB clusters in your Aurora global databases. The recovery point objective (RPO) for this approach is typically a non-zero value measured in seconds. The amount of data loss depends on the Aurora global databases replication lag across the AWS Regions at the time of the failure. For more information, see [ Recovering an Amazon Aurora global database from an unplanned outage](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-failover) in the Amazon Aurora User Guide.
+ Switchover – This operation was previously called *managed planned failover*. Use this approach for controlled scenarios, such as operational maintenance and other planned operational procedures where all the Aurora clusters and other services they interact with are in a healthy state. Because this feature synchronizes secondary DB clusters with the primary before making any other changes, RPO is 0 (no data loss). For more information, see [ Performing switchovers for Amazon Aurora global databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover) in the Amazon Aurora User Guide.
## Configuration
To configure an Aurora Global Database execution block, enter the following values.
**Important**
Before you configure the execution block, make sure that you have the correct IAM policy in place. For more information, see [Aurora Global Database execution block sample policy](security_iam_region_switch_aurora.md).
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **Aurora Global Database cluster name: **Enter the identifier for the global database.
1. **Cluster ARN for *Region*: **Enter the cluster ARN to use in each Region in the plan.
1. **Specify the option for Aurora database: **Choose either **Switchover** or **Failover (data loss)**, depending on how you want
1. **Aurora Global Database cluster name: **
1. **Timeout: **Enter a timeout value.
Then, choose **Save step.**
## How it works
By configuring a Aurora Global Databases execution block, you can failover or switchover global databases as part of your application recovery. If you’re using an active/active approach, Region switch uses the other configured Region as the source. That is, if a Region is being deactivated, Region switch uses the other active Region as the source to match for the percent to scale.
This block supports both graceful and ungraceful execution modes. Ungraceful settings perform an Aurora Global Database *failover*, which might cause data loss.
For more information about Aurora Global Database disaster recovery, including failover and switchover, see [ Using switchover or failover in Amazon Aurora global databases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html) in the Amazon Aurora User Guide.
## What is evaluated as part of plan evaluation
When Region switch evaluates your plan, Region switch performs several checks on your Aurora execution block configuration and permissions. Region switch verifies that the following is correct:
+ The Aurora global cluster specified in the configuration exists.
+ There are Aurora DB clusters in both the source and destination Regions.
+ The source and destination DB clusters are in a state that allows Global Database switchover.
+ There are DB instances in both the source and destination clusters
+ The global cluster engine versions for the switchover action are compatible. This includes verifying that the clusters are on the same Major, Minor, and patch versions, with some exceptions that are listed in the Aurora documentation.
Region switch also validates that the plan's IAM role has the required permissions for Aurora failover and switchover. For more information about the required permissions for Region switch execution blocks, see [Identity-based policy examples for Region switch in ARC](security_iam_id-based-policy-examples-region-switch.md).
The correct IAM permissions are essential for the proper functioning of the Aurora execution block. If any of these validations fail, Region switch returns warnings that there are issues, and provides specific error messages to help you resolve the permissions or configuration issues. This ensures that your plan has the necessary access to manage and interact with the Aurora during when this step runs during a plan execution.
# Amazon DocumentDB Global Cluster execution block
The Amazon DocumentDB Global Cluster execution block allows you to perform a *failover* or *switchover* recovery workflow for a global cluster.
+ Failover – Use this approach to recover from an unplanned outage. With this approach, you perform a cross-Region failover to one of the secondary clusters in your Amazon DocumentDB global cluster. The recovery point objective (RPO) for this approach is typically a non-zero value measured in seconds. The amount of data loss depends on the Amazon DocumentDB global cluster replication lag across the AWS Regions at the time of the failure.
+ Switchover – Use this approach for controlled scenarios, such as operational maintenance and other planned operational procedures where all the Amazon DocumentDB clusters are in a healthy state. Because this feature synchronizes secondary clusters with the primary before making any other changes, RPO is 0 (no data loss).
## Configuration
To configure a Amazon DocumentDB Global Cluster execution block, enter the following values.
**Important**
Before you configure the execution block, make sure that you have the correct IAM policy in place. For more information, see [Amazon DocumentDB Global Cluster execution block sample policy](security_iam_region_switch_documentdb.md).
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **Amazon DocumentDB Global Cluster identifier: **Enter the identifier for the global cluster.
1. **Cluster ARN for *Region*: **Enter the cluster ARN to use in each Region in the plan.
1. **Specify the option for Amazon DocumentDB cluster: **Choose either **Switchover** or **Failover (data loss)**.
1. **Timeout: **Enter a timeout value.
Then, choose **Save step.**
## How it works
By configuring a Amazon DocumentDB Global Cluster execution block, you can failover or switchover global clusters as part of your application recovery. If you're using an active/active approach, Region switch uses the other configured Region as the source. That is, if a Region is being deactivated, Region switch uses the other active Region as the source to match for the percent to scale.
This block supports both graceful and ungraceful execution modes. Ungraceful settings perform a Amazon DocumentDB Global Cluster *failover*, which might cause data loss.
During switchover or failover operations, the DNS endpoint that customers use to write will be changed. Customers are responsible for ensuring they are using the correct endpoint after the operation completes.
## What is evaluated as part of plan evaluation
When Region switch evaluates your plan, Region switch performs several checks on your Amazon DocumentDB execution block configuration and permissions. Region switch verifies that the following is correct:
+ The Amazon DocumentDB global cluster specified in the configuration exists.
+ There are Amazon DocumentDB clusters in both the source and destination Regions.
+ The source and destination clusters are in an available state.
+ There are instances in both the source and destination clusters.
+ The global cluster engine versions are compatible.
Region switch also validates that the plan's IAM role has the required permissions for Amazon DocumentDB failover and switchover. For more information about the required permissions for Region switch execution blocks, see [Identity-based policy examples for Region switch in ARC](security_iam_id-based-policy-examples-region-switch.md).
The correct IAM permissions are essential for the proper functioning of the Amazon DocumentDB execution block. If any of these validations fail, Region switch returns warnings that there are issues, and provides specific error messages to help you resolve the permissions or configuration issues. This ensures that your plan has the necessary access to manage and interact with Amazon DocumentDB during when this step runs during a plan execution.
# Amazon RDS Promote Read Replica execution block
The Amazon RDS Promote Read Replica execution block allows you to promote an Amazon RDS read replica to a standalone database instance as part of your multi-Region recovery process. This enables you to failover to a healthy Region by promoting the read replica in that Region to become the new primary database.
## Configuration
To configure an Amazon RDS Promote Read Replica execution block, enter the following values.
**Important**
Before you configure the execution block, make sure that you have the correct IAM policy in place. For more information, see [Amazon RDS execution block sample policy](security_iam_region_switch_rds.md).
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **RDS DB instance ARN for Region: **Enter the database instance ARN for the read replica in each Region in the plan.
1. **Timeout: **Enter a timeout value.
Then, choose **Save step.**
## How it works
By configuring an Amazon RDS Promote Read Replica execution block, you can promote a read replica to a standalone database instance as part of your application recovery. When you execute the plan, Region switch promotes the read replica in the Region that you're activating to become an independent database instance.
**Note**
This block only supports active/passive plans
During promotion, the DNS endpoint that you use to connect to the database will remain the same. However, the promoted instance will no longer replicate from the original primary database. You are responsible for ensuring their application is configured to use the correct endpoint after the operation completes.
After promotion, the promoted instance inherits the following backup settings from the original primary instance:
+ Backup retention period
+ Preferred backup window
## What is evaluated as part of plan evaluation
When Region switch evaluates your plan, Region switch performs several checks on your Amazon RDS execution block configuration and permissions. Region switch verifies that the following is correct:
+ The Amazon RDS database instances specified in the configuration exist.
+ The database instances in the non-primary Regions are read replicas.
+ The read replicas are in an available state.
+ The database instances are properly configured for cross-Region replication.
Region switch also validates that the plan's IAM role has the required permissions for Amazon RDS read replica promotion. For more information about the required permissions for Region switch execution blocks, see [Identity-based policy examples for Region switch in ARC](security_iam_id-based-policy-examples-region-switch.md).
The correct IAM permissions are essential for the proper functioning of the Amazon RDS execution block. If any of these validations fail, Region switch returns warnings that there are issues, and provides specific error messages to help you resolve the permissions or configuration issues. This ensures that your plan has the necessary access to manage and interact with Amazon RDS during when this step runs during a plan execution.
# Amazon RDS Create Cross-Region Replica execution block
The Amazon RDS Create Cross-Region Replica execution block allows you to create a cross-Region read replica for an Amazon RDS database instance as part of your post-recovery process. This execution block is typically used after promoting a read replica to re-establish cross-Region replication, ensuring your application is prepared for future regional events.
## Configuration
To configure an Amazon RDS Create Cross-Region Replica execution block, enter the following values.
**Important**
Before you configure the execution block, make sure that you have the correct IAM policy in place. For more information, see [Amazon RDS execution block sample policy](security_iam_region_switch_rds.md).
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **Source DB instance ARN for Region: **Enter the database instance ARN for the source database in each Region in the plan. The execution block uses the identifier from the Region being activated as the source database for creating the cross-Region read replica.
1. **Replica DB instance ARN: **Enter the instance ARN to use for the new read replica.
1. **Timeout: **Enter a timeout value.
Then, choose **Save step.**
## How it works
By configuring an Amazon RDS Create Cross-Region Replica execution block, you can create a read replica in the other Region as part of your post-recovery process. This execution block is designed to run after a successful failover to re-establish cross-Region replication.
This block can only be added to active/passive plans.
During the execution, the old primary instance will be renamed and tagged with *renamedByRegionSwitch*. Then a new read replica instance will be created with the following settings copied from the old primary:
+ Instance identifier
+ DB parameter groups
+ DB subnet groups
+ KMS key
+ VPC security groups
+ Option groups
+ Multi-AZ configuration
+ Domain authentication secret ARN
**Important**
The renamed primary instance remains running and continues to incur charges. Region switch tags it with *renamedByRegionSwitch* for identification, but does not otherwise modify or delete it. You are responsible for managing the renamed instance, including deciding whether to keep it running, stop it, or delete it based on your operational and cost requirements.
**Note**
This execution block is designed for post-recovery workflows and requires the source Region to be healthy and accessible. It should be used after a successful failover to re-establish cross-Region replication.
## What is evaluated as part of plan evaluation
When Region switch evaluates your plan, Region switch performs several checks on your Amazon RDS execution block configuration and permissions. Region switch verifies that the following is correct:
+ The database instance ARNs in the configuration are valid and properly formatted.
+ The source database instances exist in their respective Regions.
+ The source database instances are in an available state.
Region switch also validates that the plan's IAM role has the required permissions for creating Amazon RDS read replicas. For more information about the required permissions for Region switch execution blocks, see [Identity-based policy examples for Region switch in ARC](security_iam_id-based-policy-examples-region-switch.md).
The correct IAM permissions are essential for the proper functioning of the Amazon RDS execution block. If any of these validations fail, Region switch returns warnings that there are issues, and provides specific error messages to help you resolve the permissions or configuration issues. This ensures that your plan has the necessary access to manage and interact with Amazon RDS during when this step runs during a plan execution.
# Manual approval execution block
The manual approval execution block enables you to insert an approval step that you associate with an IAM role. Users with access to the role can approve or decline the execution of a step, to pause the step until approval is granted, or, potentially, prevent the plan from progressing.
To ensure that manual approval is required during plan execution, you input a manual approval step at a specific location in the workflow, and then configure the IAM role to specify who can approve the step.
## Configuration
To configure a manual approval execution block, enter the following values.
**Important**
Before you configure the execution block, make sure that you have the correct IAM policy in place. For more information, see [Manual approval execution block sample policy](security_iam_region_switch_manual_approval.md).
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **IAM approval role: **Enter the ARN for an IAM role that has permission to manually approve execution continuing for the Region switch plan. The IAM role must be within the account that is the owner of the plan.
1. **Timeout: **Enter a timeout value.
Then, choose **Save step.**
## How it works
By configuring a manual approval execution block, you can require an approval as part of your application recovery. For a manual execution block, Region switch does the following:
+ When Region switch runs a manual execution block, it pauses execution and sets the plan's execution status to pending approval.
+ Anyone who has access to the role defined in the execution block can approve or decline execution of the step.
+ If they approve the step execution, Region switch proceeds with execution the plan. If they decline, Region switch cancels the plan execution.
This block does not support ungraceful execution mode.
## What is evaluated as part of plan evaluation
Region switch does not complete any evaluations for manual approval execution blocks.
# Custom action Lambda execution block
The custom action Lambda execution block enables you to add a customized step to a plan by using a Lambda function.
## Configuration
To configure a Lambda execution block, enter the following values.
**Important**
Before you configure the execution block, make sure that you have the correct IAM policy in place. For more information, see [Custom action Lambda execution block sample policy](security_iam_region_switch_lambda.md).
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **Lambda function ARN to be invoked when activating or deactivating *Region***: Specify the ARN of the Lambda function to run for this step.
1. **Region to run Lambda function: **In the drop-down menu, choose the Region that you want to run the Lambda functions in.
1. **Timeout: **Enter a timeout value.
1. **Retry interval: **Enter a retry interval, to rerun the Lambda function if it does not succeed within this interval.
Then, choose **Save step.**
## How it works
+ When you create a custom action Lambda execution block, you're required to specify two Lambda functions for the step to execute—one in each of the plan's Regions.
+ You can configure which Region you want the Lambda to run in, for example, in the activating Region or in the deactivating Region. However, if you execute in the deactivating Region, you take a dependency on that Region. We do not recommend that you take a dependency on the deactivating Region.
This block supports both graceful and ungraceful execution modes. In ungraceful execution mode, Region switch skips the Lambda execution block step.
## What is evaluated as part of plan evaluation
When Region switch evaluates your plan, Region switch performs several checks on your Lambda execution block configuration and permissions. Region switch verifies that the following is correct:
+ The Lambda functions specified in the configuration exist.
+ The concurrency settings of Lambda functions are not throttled, including verifying the following:
+ Concurrency is not set to 0.
+ At least one concurrent execution is available, or that unreserved concurrency exists.
Region switch performs a dry run of the Lambda function to validate the specified parameters and permissions, without executing the actual function logic. The standard Lambda costs are incurred when you perform a dry run.
Region switch also validates that the plan's IAM role has the required permissions for Lambda execution. For more information about the required permissions for Region switch execution blocks, see [Identity-based policy examples for Region switch in ARC](security_iam_id-based-policy-examples-region-switch.md).
The correct IAM permissions are essential for the proper functioning of the Lambda execution block. If any of these validations fail, Region switch returns warnings that there are issues, and provides specific error messages to help you resolve the permissions or configuration issues. This ensures that your plan has the necessary access to manage and interact with the Lambda during when this step runs during a plan execution.
# Amazon Route 53 health check execution block
The Amazon Route 53 health check execution block enables you to specify the Regions that your application's traffic will be redirected to during failover. The execution block creates Amazon Route 53 health checks, which you then attach to Route 53 DNS records in your account. When you execute your Region switch plan, the Route 53 health check state is updated, and traffic is redirected based on your DNS configuration.
**Important**
The Route 53 hosted zone must be in the same partition as the Region switch plan.
## Configuration
To configure a Route 53 health check execution block, enter the following values.
**Important**
Before you configure the execution block, make sure that you have the correct IAM policy in place. For more information, see [Route 53 health check execution block sample policy](security_iam_region_switch_route53.md).
1. **Step name: **Enter a name.
1. **Step description (optional): **Enter a description of the step.
1. **Hosted zone ID: **The hosted zone Id for your domain and DNS records in Route 53.
1. **Record name: **Enter the record name (domain name) for the records that you use, with the associated health checks, to redirect traffic for your application. Region switch will find the Route 53 record sets for the record name and attempt to map each record set to a Region, based on the Region name inside the **Value** or **Set Identifier** of the record set.
1. **Record set identifiers (optional): **You have the option to manually provide the record set identifiers if Region switch cannot automatically map the record sets to Regions from the record name provided in step 4 after you have created the plan. If plan evaluation returns a warning that indicates that more information is required, update your plan with record set identifiers by including the following for each Region:
+ **Record set identifier: **Enter the **Set identifier** or the **Value/Route traffic to** for the record set.
+ **Region: ** Enter the Region associated with the record set that has the record set identifier information.
1. Choose **Save step.**
1. Configure health checks in Route 53.
Region switch provides a health check ID, for each Region, for each record name within a hosted zone defined in the execution block. Make sure that you configure the health checks for the corresponding record sets in your account in Route 53 so that Region switch can correctly redirect traffic for your application during plan execution. In the **Health checks** tab on the plan details page, you can view the health checks for all execution blocks and Regions.
## How it works
You add a health check step to your Region switch workflow so that you can redirect traffic to a secondary Region, for active/passive configurations, or away from a deactivated Region, for active/active configurations. If you add multiple workflows to your plan, provide the same configuration values for all health check execution blocks that use the same DNS records.
Based on the information that you provide when you configure the execution block, Region switch attempts to determine the correct record set for each Region in your plan. Typically, the hosted zone ID and the record name are enough information to determine the record sets and associated Regions. If not, when Region switch runs its automatic plan evaluation after you create the plan, a warning is returned to let you know that more information is required.
Region switch vends health checks for each Route 53 health check execution block. For plans that use a active/passive recovery approach, the health check for the primary Region starts as healthy, and the health check for the standby Region is initially set to unhealthy. For plans that use the active/active recovery approach, health checks for all Regions start in the healthy state.
To enable Region switch to successfully run this execution block for your plan, you must add the health checks to your DNS records.
For an active/active plan, the execution step works in the following way:
+ When a deactivate workflow runs for a Region, the health check is set to unhealthy, and traffic is no longer directed to the Region.
+ When an activate workflow runs for a Region, the health check is set to healthy, and traffic is routed to the Region.
For an active/passive plan, the execution step works in the following way:
+ When an activate workflow runs for a Region, the health check for that Region is set to healthy, and traffic is routed to the Region. At the same time, the health check for the other Region in the plan is set to unhealthy, and traffic stops being directed to that Region.
## What is evaluated as part of plan evaluation
When Region switch evaluates your plan, Region switch performs several checks on your Route 53 health check execution block configuration and permissions. Region switch verifies that health checks are attached to the DNS records specified in the execution block configuration. That is, Region switch verifies that the DNS records for a specific AWS Region are configured to use health checks for that Region.
## Comparing ARC routing controls and Route 53 health check execution blocks
The Amazon Route 53 health check execution block in Region switch provides a lower-cost alternative for DNS-based traffic management. However, this execution block depends on the AWS Region that you're activating, so that Region must be available. This meets the needs of most customers, because they are activating a healthy Region.
ARC routing controls provide highly reliable DNS-based traffic management with a 100% availability SLA. With routing controls, your operations teams can shift traffic between Regions with safety guardrails. Routing controls provide a single-tenant solution with a 100% SLA. A routing control cluster is spread across five Regions and can tolerate two Regions being offline. If you have highly critical applications, consider using routing controls.
Routing controls are not required to use Region switch. You can use Region switch to manage traffic redirection by using Route 53 health check execution blocks without routing controls.
Routing controls add value with Region switch in the following situations:
+ You require the 100% availability SLA for the traffic control mechanism itself.
+ Your organization requires manual operational controls with safety rules for critical applications.
+ You want defense-in-depth so that operations teams can manually override automated traffic routing if needed.
Route 53 health check execution blocks do not depend on the control plane. Health check record changes use the data plane, so they do not require the activating Region to process configuration updates. Route 53 health check execution blocks are sufficient in the following situations:
+ Your application can depend on the AWS Region that you are activating.
+ Automated traffic redirection as part of the recovery workflow meets your requirements.
+ Cost optimization is a priority. Route 53 health check execution blocks have lower cost than routing controls.
Most customers start with Route 53 health check execution blocks as the default traffic routing mechanism and add routing controls only for their most critical applications that require the highest reliability for the traffic management mechanism.
# Create child plans
To support more complex recovery scenarios, you can create child plans by adding them with Region switch plan execution blocks. The hierarchy is limited to two levels, but one parent plan can include multiple child plans.
**Important**
Before you create a child plan, make sure that you have the correct IAM policy in place. For more information, see [Region switch plan execution block sample policy](security_iam_region_switch_plan_execution.md).
For compatibility, child plans must support all Regions that the parent plan supports. In addition, the recovery approach, active/active or active/passive, must be the same for the parent and child plans.
Keep in mind the following ways in which a child plan respond to changes that you make to a parent plan and to parent plan scenarios.
+ A parent execution block is marked as completed when all child plans and other execution blocks within it are completed.
+ If any step fails in any child plan, the Region switch plan execution block fails in the parent plan.
+ Control actions that are initiated in the parent plan during the Region switch step, such as pause, a graceful or ungraceful switches, or a cancellation, are automatically attempted on the child plan, regardless of the child plan's current step.
+ Skips operations have a special behavior: the parent plan is skipped, but the child plan will still execute.
+ If a child plan is already executing in a Region switch block, to determine if it continues to run, Region switch assesses the child plan's compatibility with the parent plan. If the child plan's configuration matches the parent plan's requirements, Region switch treats the child plan as if it were initiated by the parent plan.
+ The parent plan step will fail if the child plan is running with incompatible configuration parameters, such as the following:
+ The child plan is operating in a different Region
+ The child plan is executing a deactivating operation when Region switch expects it to execute an activating operation
+ If the child plan completes successfully during a time that a parent plan is paused, the parent plan will succeed when the parent plan resumes.
# Create a trigger for a Region switch plan
If you want to automate recovery for your application in Region switch, you can create one or more triggers for your Region switch plan. Triggers automatically start executing a Region switch plan, based on CloudWatch alarm conditions that you choose.
# To create a trigger for a Region switch plan
1. After you create a plan, on the **Plan details** page, select the **Triggers** tab.
1. Choose **Manage triggers**.
1. Select the workflows that you want to automate execution for, and then choose **Add trigger**.
1. Provide a description for the trigger.
1. Select a CloudWatch alarm, and then select up to 10 CloudWatch alarms to create the conditions for the trigger.
When you select more than one condition, all conditions must be met before automated execution of the plan will start.
The trigger starts plan execution when a CloudWatch alarm transitions to meet the conditions for the trigger. When the trigger is added to the plan, if the conditions are already met, the plan does not execute, which prevents unintended failover events.
# Execute a Region switch plan to recover an application
To recover an application when an AWS Region is impaired, you execute a Region switch plan in Amazon Application Recovery Controller (ARC).
+ If your application is deployed with an active/active approach, the workflows in your plan deactivate the Region that is impaired so that your other active Region is appropriately scaled and begins to receive all of your application traffic.
+ If your application is deployed with an active/passive approach, the workflows in your plan deactivate the impaired Region and activate your standby Region, by scaling up your resources there, if needed, and redirecting your application traffic to the standby Region.
To perform application recovery manually, run your Region switch plan by doing the following.
Another option is to trigger an execution automatically with specific Amazon CloudWatch alarms that you specify to start a plan execution. You can specify triggers for plan execution when you create or update a plan. For more information, see [Create a trigger for a Region switch plan](working-with-rs-triggers.md).
# To execute a Region switch plan
1. In the AWS Management Console, navigate to the AWS Region that you want to activate for your application.
1. On the Amazon Application Recovery Controller (ARC) console, choose **Region switch**, and then select the plan that you want to run.
1. Choose **Execute plan**.
1. If your plan includes manual approval steps, approve each step when prompted.
While a plan is executing, you can track its progress on the execution details page, which opens when you choose to execute a plan.
You can also view information about in-progress application recovery on the Region switch dashboards. On the Region switch console, in the left navigation, under **Region switch**, choose one of the following:
+ **Global dashboard**
+ **Executions in *Region name***
Be aware that, if there are impairments in a Region, the global dashboard might not show all your plan data. Because of this, we recommend that you rely only on Regional executions dashboard during operational events. The Regional executions dashboard is more resilient because it uses the local Region switch data plane.
When plan execution is complete, you can see information about the plan execution, and other plans that Region switch has run, on the **Plan details** page in the **Plan execution history** tab.
# Region switch dashboards
Region switch includes a global dashboard that you can use to observe the state of Region switch plans across your organization and Regions. Region switch also has a Regional executions dashboard that displays only plan executions in the Region where you are currently logged in to the AWS Management Console.
Be aware that, if there are impairments in a Region, the global dashboard might not show all your plan data. Because of this, we recommend that you rely only on Regional executions dashboard during operational events. The Regional executions dashboard is more resilient because it uses the local Region switch data plane.
# To open the Region switch global dashboard
1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/home#/dashboard](https://console.aws.amazon.com/route53recovery/home#/dashboard).
1. Under **Region switch**, choose **Global dashboard**.
# To open the Region switch Regional dashboard
1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/home#/dashboard](https://console.aws.amazon.com/route53recovery/home#/dashboard).
1. Under **Region switch**, choose **Regional dashboard**.
# Cross-account support in Region switch
In Region switch, you can add resources from other accounts to your plans. You can also share a Region switch plan with other accounts. For more information, see the following sections.
## Cross-account resources
Region switch allows resources to be hosted in an account that is separate from the account that contains the Region switch plan. When Region switch executes a plan, it assumes the executionRole. If the plan uses resources from an account that is different than the account that hosts the plan, then Region switch uses the executionRole to assume the crossAccountRole to access those resources.
Each resource in the Region switch plan has two optional fields: crossAccountRole and externalId.
+ crossAccountRole: This role allows access to resources in an account that is different than the account that hosts the Region switch plan. The role only needs permissions to act on the resources within its account – it does not need permissions to act on the resources in the account that hosts the Region switch plan.
+ ExternalId: This is the STS external ID from the trust policy of the account that contains the resource that requires action. It is an alphanumeric string that is the shared secret between the two accounts.
## Sharing Region switch plans
Region switch integrates with AWS Resource Access Manager (AWS RAM) to allow you to share plans across AWS accounts. When you share a plan, accounts that you specify can view the plan details, execute the plan, and view the plan's executions, which provides more control and flexibility for recovery capabilities across different teams.
To get started with cross-account sharing in Region switch, you create a resource share in AWS RAM. The resource share specifies participants who are authorized to share the plan that your account owns. Participants can view and execute the shared plan through the console, the CLI, or AWS SDKs.
Important: Your AWS account must own the plans that you want to share. You cannot share a plan that has been shared with you. To share a plan with your organization, or with an organizational unit in AWS Organizations, you must enable sharing with Organizations.
For more information about AWS RAM, see [Support sharing plans across accounts for ARC Region switch](resource-sharing.region-switch.md).
# Support sharing plans across accounts for ARC Region switch
Amazon Application Recovery Controller (ARC) 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 ARC Region switch, you can share the Region switch plan. (To use resources from another account in your plan, you use a crossAccount role. To learn more, see [Cross-account resources](cross-account-resources-rs.md#cross-account-resources-rs-in-plan).)
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](https://docs.aws.amazon.com/ram/latest/userguide/)*.
By using AWS Resource Access Manager to share plans across accounts in ARC, you can use one plan with several different AWS accounts. When you opt to share a plan, other AWS accounts that you specify can execute the plan to perform application recovery.
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 plan.
When you share a plan, you can reduce the number of total plans that your organization requires. With a shared plan, you can allocate the total cost of running the plan across different teams, to maximize the benefits of ARC with lower cost. Sharing plans across accounts can also ease the process of onboarding multiple applications to 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 ARC, you create a *resource share* i n AWS RAM. The resource share specifies *participants* who are authorized to share the plan that your account owns.
This topic explains how to share resources that you own, and how to use resources that are shared with you.
**Topics**
+ [Prerequisites for sharing plans](#sharing-prereqs-rs)
+ [Sharing a plan](#sharing-share-rs)
+ [Unsharing a shared plan](#sharing-unshare-rs)
+ [Identifying a shared plan](#sharing-identify-rs)
+ [Responsibilities and permissions for shared plans](#sharing-perms-rs)
+ [Billing costs](#sharing-billing-rs)
+ [Quotas](#sharing-quotas-rs)
## Prerequisites for sharing plans
+ To share a plan, 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 plan that has been shared with you.
+ To share a plan 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](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) in the *AWS RAM User Guide*.
## Sharing a plan
When you share a plan, the participants that you specify to share the plan can view and, if you grant additional permissions, execute the plan.
To share a plan, 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 plan 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](https://console.aws.amazon.com/ram), 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 plan. Otherwise, participants receive an invitation to join the resource share and are granted access to the shared plan after accepting the invitation.
You can share a plan 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 plan that you own by using the AWS RAM console**
See [ Creating a resource share](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) in the *AWS RAM User Guide*.
**To share a plan that you own by using the AWS CLI**
Use the [create-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/create-resource-share.html) command.
**Granting permissions to share plans**
Sharing plans across accounts requires the following additional permissions for the IAM principal sharing the plan by using AWS RAM:
```
# read and execute plan permissions
"arc-region-switch:GetPlan",
"arc-region-switch:GetPlanInRegion",
"arc-region-switch:GetPlanExecution",
"arc-region-switch:ListPlanExecutionEvents",
"arc-region-switch:ListPlanExecutions",
"arc-region-switch:ListRoute53HealthChecks",
"arc-region-switch:GetPlanEvaluationStatus",
"arc-region-switch:StartPlanExecution",
"arc-region-switch:CancelPlanExecution",
"arc-region-switch:UpdatePlanExecution",
"arc-region-switch:UpdatePlanExecutionStep"
```
The owner who shares the plan must have the following permissions. If you attempt to share a plan through AWS RAM without having these permissions, an error is returned.
```
"arc-region-switch:PutResourcePolicy" # Permission only apis
"arc-region-switch:DeleteResourcePolicy" # Permission only apis
"arc-region-switch:GetResourcePolicy" # Permission only apis
```
For more information about the way that AWS Resource Access Manager uses IAM see [ How AWS Resource Access Manager uses IAM](https://docs.aws.amazon.com/ram/latest/userguide/security-iam-policies.html) in the *AWS RAM User Guide*.
## Unsharing a shared plan
When you unshare a plan, the following applies to participants and owners:
+ Participants can no longer view or execute the unshared plan.
To unshare a shared plan 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 plan that you own using the AWS RAM console**
See [Updating a resource share](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing.html#working-with-sharing-update) in the *AWS RAM User Guide*.
**To unshare a shared plan that you own using the AWS CLI**
Use the [disassociate-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/disassociate-resource-share.html) command.
## Identifying a shared plan
Owners and participants can identify shared plans by viewing information in AWS RAM. They can also get information about shared resources by using the 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 view all resources that you are sharing with others by using AWS RAM. For more information, see [Viewing your shared resources in AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-view-sr.html).
+ As a participant, you can view all resources shared with you by using AWS RAM. For more information, see [Viewing your shared resources in AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-shared-view-sr.html).
As an owner, you can determine if you're sharing a plan by viewing information in the AWS Management Console or by using the AWS Command Line Interface with ARC API operations.
**To identify if a plan that you own is shared by using the console**
In the AWS Management Console, on the details page for a plan, see the **plan sharing status**.
As a participant, when a plan is shared with you, you typically must accept the share so that you can access the plan.
## Responsibilities and permissions for shared plans
### Permissions for owners
Participants can view or execute the plan (if they have the correct permissions).
### Permissions for participants
When you share a plan that you own with other AWS accounts, participants can view or execute the plan (if they have the correct permissions).
When you share a plan by using AWS RAM, a participant has, by default, read-only permissions. To review a list of read-only permissions for Region switch, see [Read-only permissions](security_iam_region_switch_read_only.md). Participants need additional permissions to execute a Region switch plan. Participants who need to execute plans need additional permissions. Be aware that you cannot grant permission to a AWS RAM participant for the following operations:
+ ` ApprovePlanExecutionStep`
+ ` UpdatePlan`
## Billing costs
The owner of a plan in ARC is billed for costs associated with the plan. There are no additional costs, for plan owners or for participants, for creating resources hosted in a plan.
For detailed pricing information and examples, see [Amazon Application Recovery Controller (ARC) Pricing](https://aws.amazon.com/application-recovery-controller/pricing/).
## Quotas
All resources created in a shared plan count toward quotas for the plan owner.
For a list of Region switch plan quotas, see [Quotas for Region switch](quotas.region-switch.md).
# Identity and Access Management for Region switch in ARC
AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use ARC resources. IAM is an AWS service that you can use with no additional charge.
**Topics**
+ [How Region switch works with IAM](security_iam_service-with-iam-region-switch.md)
+ [Identity-based policy examples](security_iam_id-based-policy-examples-region-switch.md)
# How Region switch in ARC works with IAM
Before you use IAM to manage access to ARC, learn what IAM features are available to use with ARC.
Before you use IAM to manage access to Region switch in Amazon Application Recovery Controller (ARC), learn what IAM features are available to use with Region switch.
**IAM features you can use with Region switch in Amazon Application Recovery Controller (ARC)**
| IAM feature | Region switch support |
| --- | --- |
| [Identity-based policies](#security_iam_service-with-iam-region-switch-id-based-policies) | Yes |
| [Resource-based policies](#security_iam_service-with-iam-region-switch-resource-based-policies) | Yes |
| [Policy actions](#security_iam_service-with-iam-region-switch-id-based-policies-actions) | Yes |
| [Policy resources](#security_iam_service-with-iam-region-switch-id-based-policies-resources) | Yes |
| [Policy condition keys](#security_iam_service-with-iam-region-switch-id-based-policies-conditionkeys) | Yes |
| [ACLs](#security_iam_service-with-iam-region-switch-acls) | Yes |
| [ABAC (tags in policies)](#security_iam_service-with-iam-region-switch-tags) | Yes |
| [Temporary credentials](#security_iam_service-with-iam-region-switch-roles-tempcreds) | Yes |
| [Principal permissions](#security_iam_service-with-iam-region-switch-principal-permissions) | Yes |
| [Service roles](#security_iam_service-with-iam-region-switch-roles-service) | No |
| [Service-linked roles](#security_iam_service-with-iam-region-switch-roles-service-linked) | No |
To get a high-level, overall view of how AWS services work with most IAM features, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Identity-based policies for Region switch
**Supports identity-based policies:** Yes
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
To view examples of ARC identity-based policies, see [Identity-based policy examples in Amazon Application Recovery Controller (ARC)](security_iam_id-based-policy-examples.md).
## Resource-based policies within Region switch
**Supports resource-based policies:** Yes
Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM role trust policies and Amazon S3 bucket policies. In services that support resource-based policies, service administrators can use them to control access to a specific resource.
## Policy actions for Region switch
**Supports policy actions:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.
Policy actions in ARC for Region switch use the following prefixes before the action:
```
arc-region-switch
```
To specify multiple actions in a single statement, separate them with commas. For example, the following:
```
"Action": [
"arc-region-switch:action1",
"arc-region-switch:action2"
]
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Describe`, include the following action:
```
"Action": "arc-region-switch:Describe*"
```
To view examples of ARC identity-based policies for Region switch, see [Identity-based policy examples for Region switch in ARC](security_iam_id-based-policy-examples-region-switch.md).
## Policy resources for Region switch
**Supports policy resources:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
To view examples of ARC identity-based policies for Region switch, see [Identity-based policy examples for Region switch in ARC](security_iam_id-based-policy-examples-region-switch.md).
## Policy condition keys for Region switch
**Supports service-specific policy condition keys:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
To view examples of ARC identity-based policies for Region switch, see [Identity-based policy examples for Region switch in ARC](security_iam_id-based-policy-examples-region-switch.md).
## Access control lists (ACLs) in Region switch
**Supports ACLs:** Yes
Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.
## Attribute-based access control (ABAC) with Region switch
**Supports ABAC (tags in policies):** Yes
Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource.
To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys.
If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**.
For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*.
## Using temporary credentials with Region switch
**Supports temporary credentials:** Yes
Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Cross-service principal permissions for Region switch
**Supports forward access sessions (FAS):** Yes
When you use an IAM entity (user or role) to perform actions in AWS, you are considered a principal. Policies grant permissions to a principal. When you use some services, you might perform an action that then triggers another action in a different service. In this case, you must have permissions to perform both actions.
## Service roles for Region switch
**Supports service roles:** No
A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
## Service-linked roles for Region switch
**Supports service-linked roles:** No
A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
For details about creating or managing service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Find a service in the table that includes a `Yes` in the **Service-linked role** column. Choose the **Yes** link to view the service-linked role documentation for that service.
# Identity-based policy examples for Region switch in ARC
By default, users and roles don't have permission to create or modify ARC resources. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies.
To learn how to create an IAM identity-based policy by using these example JSON policy documents, see [Create IAM policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) in the *IAM User Guide*.
For details about actions and resource types defined by ARC, including the format of the ARNs for each of the resource types, see [Actions, resources, and condition keys for Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53recoverycontrols.html) in the *Service Authorization Reference*.
**Topics**
+ [Policy best practices](#security_iam_service-with-iam-policy-best-practices-zonal)
+ [Plan execution role trust policy](security_iam_region_switch_trust_policy.md)
+ [Full access permissions](security_iam_region_switch_full_access.md)
+ [Read-only permissions](security_iam_region_switch_read_only.md)
+ [Execution block permissions](security_iam_region_switch_execution_blocks.md)
+ [CloudWatch alarms for application health permissions](security_iam_region_switch_cloudwatch.md)
+ [Automatic plan execution reports permissions](security_iam_region_switch_reports.md)
+ [Cross-account resource permissions](security_iam_region_switch_cross_account.md)
+ [Complete plan execution role permissions](security_iam_region_switch_complete_policy.md)
## Policy best practices
Identity-based policies determine whether someone can create, access, or delete ARC resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
+ **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
+ **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
+ **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*.
+ **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*.
For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.
# Plan execution role trust policy
This is the trust policy required for the plan's execution role, so that ARC can run a Region switch plan.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "arc-region-switch.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
# Full access permissions
The following IAM policy grants full access for all Region switch APIs:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "arc-region-switch.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"arc-region-switch:CreatePlan",
"arc-region-switch:UpdatePlan",
"arc-region-switch:GetPlan",
"arc-region-switch:ListPlans",
"arc-region-switch:DeletePlan",
"arc-region-switch:GetPlanInRegion",
"arc-region-switch:ListPlansInRegion",
"arc-region-switch:ApprovePlanExecutionStep",
"arc-region-switch:GetPlanEvaluationStatus",
"arc-region-switch:GetPlanExecution",
"arc-region-switch:StartPlanExecution",
"arc-region-switch:CancelPlanExecution",
"arc-region-switch:ListRoute53HealthChecks",
"arc-region-switch:ListRoute53HealthChecksInRegion",
"arc-region-switch:ListPlanExecutions",
"arc-region-switch:ListPlanExecutionEvents",
"arc-region-switch:ListTagsForResource",
"arc-region-switch:TagResource",
"arc-region-switch:UntagResource",
"arc-region-switch:UpdatePlanExecution",
"arc-region-switch:UpdatePlanExecutionStep"
],
"Resource": "*"
}
]
}
```
------
# Read-only permissions
The following IAM policy grants read-only access permissions for Region switch:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"arc-region-switch:GetPlan",
"arc-region-switch:ListPlans",
"arc-region-switch:GetPlanInRegion",
"arc-region-switch:ListPlansInRegion",
"arc-region-switch:GetPlanEvaluationStatus",
"arc-region-switch:GetPlanExecution",
"arc-region-switch:ListRoute53HealthChecks",
"arc-region-switch:ListRoute53HealthChecksInRegion",
"arc-region-switch:ListPlanExecutions",
"arc-region-switch:ListPlanExecutionEvents",
"arc-region-switch:ListTagsForResource"
],
"Resource": "*"
}
]
}
```
------
# Execution block permissions
The following sections provide sample IAM policies that provide the required permissions for specific execution blocks that you add to a Region switch plan.
**Topics**
+ [EC2 Auto Scaling execution block sample policy](security_iam_region_switch_ec2_autoscaling.md)
+ [Amazon EKS resource scaling execution block sample policy](security_iam_region_switch_eks.md)
+ [Amazon ECS service scaling execution block sample policy](security_iam_region_switch_ecs.md)
+ [ARC routing controls execution block sample policy](security_iam_region_switch_arc_routing.md)
+ [Aurora Global Database execution block sample policy](security_iam_region_switch_aurora.md)
+ [Amazon DocumentDB Global Cluster execution block sample policy](security_iam_region_switch_documentdb.md)
+ [Amazon RDS execution block sample policy](security_iam_region_switch_rds.md)
+ [Manual approval execution block sample policy](security_iam_region_switch_manual_approval.md)
+ [Custom action Lambda execution block sample policy](security_iam_region_switch_lambda.md)
+ [Route 53 health check execution block sample policy](security_iam_region_switch_route53.md)
+ [Region switch plan execution block sample policy](security_iam_region_switch_plan_execution.md)
# EC2 Auto Scaling execution block sample policy
The following is a sample policy to attach if you add execution blocks to a Region switch plan for EC2 Auto Scaling groups.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"autoscaling:UpdateAutoScalingGroup"
],
"Resource": [
"arn:aws:autoscaling:us-east-1:123456789012:autoScalingGroup:123d456e-123e-1111-abcd-EXAMPLE22222:autoScalingGroupName/app-asg-primary",
"arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:1234a321-123e-1234-aabb-EXAMPLE33333:autoScalingGroupName/app-asg-secondary"
]
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": "*"
}
]
}
```
------
# Amazon EKS resource scaling execution block sample policy
The following is a sample policy to attach if you add execution blocks to a Region switch plan for Amazon EKS resource scaling.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster"
],
"Resource": [
"arn:aws:eks:us-east-1:123456789012:cluster/app-eks-primary",
"arn:aws:eks:us-west-2:123456789012:cluster/app-eks-secondary"
]
},
{
"Effect": "Allow",
"Action": [
"eks:ListAssociatedAccessPolicies"
],
"Resource": [
"arn:aws:eks:us-east-1:123456789012:access-entry/app-eks-primary/*",
"arn:aws:eks:us-west-2:123456789012:access-entry/app-eks-secondary/*"
]
}
]
}
```
------
Note: In addition to this IAM policy, the plan execution role needs to be added to the Amazon EKS cluster's access entries with the `AmazonArcRegionSwitchScalingPolicy` access policy. For more information, see [Configure EKS access entry permissions](eks-resource-scaling-block.md#eks-resource-scaling-block-permissions).
# Amazon ECS service scaling execution block sample policy
The following is a sample policy to attach if you add execution blocks to a Region switch plan for Amazon ECS service scaling.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:DescribeServices",
"ecs:UpdateService"
],
"Resource": [
"arn:aws:ecs:us-east-1:123456789012:service/app-cluster-primary/app-service",
"arn:aws:ecs:us-west-2:123456789012:service/app-cluster-secondary/app-service"
]
},
{
"Effect": "Allow",
"Action": [
"ecs:DescribeClusters"
],
"Resource": [
"arn:aws:ecs:us-east-1:123456789012:cluster/app-cluster-primary",
"arn:aws:ecs:us-west-2:123456789012:cluster/app-cluster-secondary"
]
},
{
"Effect": "Allow",
"Action": [
"ecs:ListServices"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"application-autoscaling:DescribeScalableTargets",
"application-autoscaling:RegisterScalableTarget"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": "*"
}
]
}
```
------
# ARC routing controls execution block sample policy
Note: The Amazon ARC routing controls execution block requires that any service control policies (SCPs) applied to the plan's execution role allow the access to the following Regions for these services:
+ `route53-recovery-control-config: us-west-2`
+ `route53-recovery-cluster: us-west-2, us-east-1, eu-west-1, ap-southeast-2, ap-northeast-1`
The following is a sample policy to attach if you add execution blocks to a Region switch plan for ARC routing controls.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"route53-recovery-control-config:DescribeControlPanel",
"route53-recovery-control-config:DescribeCluster"
],
"Resource": [
"arn:aws:route53-recovery-control::123456789012:controlpanel/abcd1234abcd1234abcd1234abcd1234",
"arn:aws:route53-recovery-control::123456789012:cluster/4b325d3b-0e28-4dcf-ba4a-EXAMPLE11111"
]
},
{
"Effect": "Allow",
"Action": [
"route53-recovery-cluster:GetRoutingControlState",
"route53-recovery-cluster:UpdateRoutingControlStates"
],
"Resource": [
"arn:aws:route53-recovery-control::123456789012:controlpanel/1234567890abcdef1234567890abcdef/routingcontrol/abcdef1234567890",
"arn:aws:route53-recovery-control::123456789012:controlpanel/1234567890abcdef1234567890abcdef/routingcontrol/1234567890abcdef"
]
}
]
}
```
------
You can retrieve the routing control control panel ID and the cluster ID by using CLI. For more information, see [Set up routing control components](getting-started-cli-routing-config.md).
# Aurora Global Database execution block sample policy
The following is a sample policy to attach if you add execution blocks to a Region switch plan for Aurora databases.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:DescribeGlobalClusters",
"rds:DescribeDBClusters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds:FailoverGlobalCluster",
"rds:SwitchoverGlobalCluster"
],
"Resource": [
"arn:aws:rds::123456789012:global-cluster:app-global-db",
"arn:aws:rds:us-east-1:123456789012:cluster:app-db-primary",
"arn:aws:rds:us-west-2:123456789012:cluster:app-db-secondary"
]
}
]
}
```
------
# Amazon DocumentDB Global Cluster execution block sample policy
The following is a sample policy to attach if you add execution blocks to a Region switch plan for Amazon DocumentDB global clusters.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:DescribeGlobalClusters",
"rds:DescribeDBClusters",
"rds:FailoverGlobalCluster",
"rds:SwitchoverGlobalCluster"
],
"Resource": "*"
}
]
}
```
# Amazon RDS execution block sample policy
The following is a sample policy to attach if you add execution blocks to a Region switch plan for Amazon RDS read replica promotion or cross-Region replica creation.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:DescribeDBInstances",
"rds:PromoteReadReplica",
"rds:CreateDBInstanceReadReplica",
"rds:ModifyDBInstance"
],
"Resource": "*"
}
]
}
```
# Manual approval execution block sample policy
The following is a sample policy to attach if you add execution blocks to a Region switch plan for manual approvals.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"arc-region-switch:ApprovePlanExecutionStep"
],
"Resource": "arn:aws:arc-region-switch::123456789012:plan/sample-plan:0123abc"
}
]
}
```
------
# Custom action Lambda execution block sample policy
The following is a sample policy to attach if you add execution blocks to a Region switch plan for Lambda functions.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:GetFunction",
"lambda:InvokeFunction"
],
"Resource": [
"arn:aws:lambda:us-east-1:123456789012:function:app-recovery-primary",
"arn:aws:lambda:us-west-2:123456789012:function:app-recovery-secondary"
]
}
]
}
```
------
# Route 53 health check execution block sample policy
The following is a sample policy to attach if you add execution blocks to a Region switch plan for Route 53 health checks.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"route53:ListResourceRecordSets"
],
"Resource": [
"arn:aws:route53:::hostedzone/Z1234567890ABCDEFGHIJ"
]
}
]
}
```
------
# Region switch plan execution block sample policy
The following is a sample policy to attach if you add execution blocks to a Region switch plan to run child plans.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"arc-region-switch:StartPlanExecution",
"arc-region-switch:GetPlanExecution",
"arc-region-switch:CancelPlanExecution",
"arc-region-switch:UpdatePlanExecution",
"arc-region-switch:ListPlanExecutions"
],
"Resource": [
"arn:aws:arc-region-switch::123456789012:plan/child-plan-1/abcde1",
"arn:aws:arc-region-switch::123456789012:plan/child-plan-2/fghij2"
]
}
]
}
```
------
# CloudWatch alarms for application health permissions
The following is a sample policy to attach to access CloudWatch alarms for application health, which are used to help determine actual recovery time.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarmHistory",
"cloudwatch:DescribeAlarms"
],
"Resource": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:app-health-primary",
"arn:aws:cloudwatch:us-west-2:123456789012:alarm:app-health-secondary"
]
}
]
}
```
------
# Automatic plan execution reports permissions
The following is a sample policy to attach if you configure automatic report generation for a Region switch plan. This policy includes permissions to write reports to Amazon S3, access CloudWatch alarm data, and retrieve child plan information for parent plans.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your-bucket-name/*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmHistory"
],
"Resource": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:app-health-primary"
"arn:aws:cloudwatch:us-west-2:123456789012:alarm:app-health-secondary"
],
},
{
"Effect": "Allow",
"Action": [
"arc-region-switch:GetPlanExecution",
"arc-region-switch:ListPlanExecutionEvents"
],
"Resource": [
"arn:aws:arc-region-switch:us-east-1:123456789012:plan/child-plan-1/abcde1",
"arn:aws:arc-region-switch:us-west-2:123456789012:plan/child-plan-2/fghij2"
],
}
]
}
```
Note: If you configure a customer managed AWS KMS key for Amazon S3 bucket encryption, you must also add `kms:GenerateDataKey` and `kms:Encrypt` permissions for the key.
# Cross-account resource permissions
If resources are in different accounts, you'll need a cross-account role. The following is a sample trust policy for a cross-account role.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/RegionSwitchExecutionRole"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "UniqueExternalId123"
}
}
}
]
}
```
------
And the following is the permission for the plan execution role to assume this cross-account role:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::987654321098:role/RegionSwitchCrossAccountRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "UniqueExternalId123"
}
}
}
]
}
```
------
# Complete plan execution role permissions
Creating a comprehensive policy that includes permissions for all execution blocks would require a policy that is quite large. In practice, you should only include permissions for the execution blocks that you use in your specific plans.
The following is an example policy that you can use as a starting place for a plan execution role policy. Make sure that you add additional policies that required for specific execution blocks that you include in your plan. Only include the permissions required for the specific execution blocks that you use in your plan, to follow the principle of least privilege
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:SimulatePrincipalPolicy",
"Resource": "arn:aws:iam::123456789012:role/RegionSwitchExecutionRole"
},
{
"Effect": "Allow",
"Action": [
"arc-region-switch:GetPlan",
"arc-region-switch:GetPlanExecution",
"arc-region-switch:ListPlanExecutions"
],
"Resource": "*"
}
]
}
```
------
# Logging and monitoring for Region switch in ARC
You can use Amazon CloudWatch, AWS CloudTrail, and Amazon EventBridge for monitoring Region switch in Amazon Application Recovery Controller (ARC), to get alerts, analyze patterns, and help troubleshoot issues.
**Topics**
+ [Logging Region switch API calls using AWS CloudTrail](cloudtrail-region-switch.md)
+ [Using Region switch in ARC with Amazon EventBridge](eventbridge-region-switch.md)
# Logging Region switch API calls using AWS CloudTrail
Amazon Application Recovery Controller (ARC) Region switch is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in ARC. CloudTrail captures all API calls for ARC as events. The calls captured include calls from the ARC console and code calls to the ARC API operations.
If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for ARC. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**.
Using the information collected by CloudTrail, you can determine the request that was made to ARC, the IP address from which the request was made, who made the request, when it was made, and additional details.
To learn more about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html).
## ARC information in CloudTrail
CloudTrail is enabled on your AWS account when you create the account. When activity occurs in ARC, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Working with CloudTrail Event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
For an ongoing record of events in your AWS account, including events for ARC, create a trail. A *trail* enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following:
+ [Overview for creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail supported services and integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html)
+ [Configuring Amazon SNS notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html)
+ [Receiving CloudTrail log files from multiple Regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail log files from multiple accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
All ARC actions are logged by CloudTrail and are documented in the TBD API REFERENCE LINK. For example, calls to the `TBD`, `TBD` and `TBD` actions generate entries in the CloudTrail log files.
Every event or log entry contains information about who generated the request. The identity information helps you determine the following:
+ Whether the request was made with root or AWS Identity and Access Management (IAM) user credentials.
+ Whether the request was made with temporary security credentials for a role or federated user.
+ Whether the request was made by another AWS service.
For more information, see the [CloudTrail userIdentity element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Viewing Region switch events in event history
CloudTrail lets you view recent events in **Event history**. Most events for Region switch API requests are in the Region where you work with a Region switch plan, for example, where you create a plan or execute a plan. However, some Region switch actions that you run in the ARC console are made using control plan API operations, rather than data plane operations. For control plane operations, you view events in US East (N. Virginia). To learn about which API calls are control plane operations, see [Region switch API operations](actions.region-switch.md).
## Understanding ARC log file entries
A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order.
The following example shows a CloudTrail log entry that demonstrates the `StartPlanExecution` action for Region switch.
```
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:role/admin",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA33L3W36EXAMPLE",
"arn": "arn:aws:iam::111122223333:role/admin",
"accountId": "111122223333",
"userName": "EXAMPLENAME"
},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2025-07-06T17:38:05Z"
}
}
},
"eventTime": "2025-07-06T18:08:03Z",
"eventSource": "arc-region-switch.amazonaws.com",
"eventName": "StartPlanExecution",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.50",
"userAgent": "Boto3/1.17.101 Python/3.8.10 Linux/4.14.231-180.360.amzn2.x86_64 exec-env/AWS_Lambda_python3.8 Botocore/1.20.102",
"requestParameters": {
"planArn": "arn:aws:arc-region-switch::555555555555:plan/CloudTrailIntegTestPlan:bbbbb",
"targetRegion": "us-east-1",
"action": "activate" }
"responseElements": {
"executionId": "us-east-1/dddddddEXAMPLE",
"plan": "arn:aws:arc-region-switch::555555555555:plan/CloudTrailIntegTestPlan:bbbbb",
"planVersion": "1",
"activateRegion": "us-east-1" },
"requestID": "fd42dcf7-6446-41e9-b408-d096example",
"eventID": "4b5c42df-1174-46c8-be99-d67aexample",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "us-east-1.arc.amazon.aws"
}
```
# Using Region switch in ARC with Amazon EventBridge
Using Amazon EventBridge, you can set up event-driven rules that monitor your Region switch resources in Amazon Application Recovery Controller (ARC), and then initiate target actions that use other AWS services. For example, you can set a rule for sending out email notifications by signaling an Amazon SNS topic whenever a Region switch plan completes execution.
You can create rules in Amazon EventBridge to act on the following ARC Region switch events:
+ *Region switch plan execution.* The event specifies that a Region switch plan has been run (executed).
+ *Region switch plan evaluation.* The event specifies that a Region switch plan evaluation has completed.
To capture specific ARC events that you're interested in, define event-specific patterns that EventBridge can use to detect the events. Event patterns have the same structure as the events that they match. The pattern quotes the fields that you want to match and provides the values that you're looking for.
Events are emitted on a best effort basis. They're delivered from ARC to EventBridge in near real-time under normal operational circumstances. However, situations can arise that might delay or prevent delivery of an event.
For information about how EventBridge rules work with event patterns, see [Events and Event Patterns in EventBridge](https://docs.aws.amazon.com//eventbridge/latest/userguide/eventbridge-and-event-patterns.html).
## Monitor a Region switch resource with EventBridge
With EventBridge, you can create rules that define actions to take when ARC emits events for Region switch resources.
To type or copy and paste an event pattern into the EventBridge console, in the console, select to the option **Enter my own** option. To help you determine event patterns that might be useful for you, this topic includes [example Region switch patterns](#arc-eventbridge-examples-region-switch).
**To create a rule for a resource event**
1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. For the AWS Region to create the rule in, choose the Region where you created the plan that you want to monitor events for.
1. Choose **Create rule**.
1. Enter a **Name** for the rule, and, optionally, a description.
1. For **Event bus**, leave the default value, **default**.
1. Choose **Next**.
1. For the **Build event pattern** step, for **Event source**, leave the default value, **AWS events**.
1. Under **Sample event**, choose **Enter my own**.
1. For **Sample events**, type or copy and paste an event pattern. For examples, see the next section.
## Example Region switch patterns
Event patterns have the same structure as the events that they match. The pattern quotes the fields that you want to match and provides the values that you're looking for.
You can copy and paste event patterns from this section into EventBridge to create rules that you can use to monitor ARC actions and resources.
The following event patterns provide examples that you might use in EventBridge for the Region switch capability in ARC.
+ *Select all events from Region switch for PlanExecution*.
```
{
"source": [ "aws.arc-region-switch" ],
"detail-type": [ "ARC Region switch Plan Execution" ]
}
```
+ *Select all events from Region switch for PlanEvaluation*.
```
{
"source": [ "aws.arc-region-switch" ],
"detail-type": [ "ARC Region Switch Plan Evaluation" ]
}
```
The following is an example ARC event for a *Region switch plan execution*:
```
{
"version": "0",
"id": "1111111-bbbb-aaaa-cccc-dddddEXAMPLE", # Random uuid
"detail-type": "ARC Region Switch Plan Execution",
"source": "aws.arc-region-switch",
"account": "111122223333",
"time": "2023-11-16T23:38:14Z",
"region": "us-east-1",
"resources": ["arn:aws:arc-region-switch::111122223333:plan/aaaaaExample"], # planArn
"detail": {
"version": "0.0.1",
"eventType": "ExecutionStarted",
"executionId": "bbbbbbEXAMPLE",
"executionAction": "activating/deactivating {region}",
"idempotencyKey": "1111111-2222-3333-4444-5555555555", # As there is a possibility of dual logging
}
}
```
The following is an example ARC event for a *Region switch plan step level execution*:
```
{
"version": "0",
"id": "1111111-bbbb-aaaa-cccc-dddddEXAMPLE", # Random uuid
"detail-type": "ARC Region Switch Plan Execution",
"source": "aws.arc-region-switch",
"account": "111122223333",
"time": "2023-11-16T23:38:14Z",
"region": "us-east-1",
"resources": ["arn:aws:arc-region-switch::111122223333:plan/aaaaaExample"], # planArn
"detail": {
"version": "0.0.1",
"eventType": "StepStarted",
"executionId": "bbbbbbEXAMPLE",
"executionAction": "activating/deactivating {region}",
"idempotencyKey": "1111111-2222-3333-4444-5555555555", # As there is a possibility of dual logging
"stepDetails" : {
"stepName": "Routing control step",
"resource": ["arn:aws:route53-recovery-control::111122223333:controlpanel/abcdefghiEXAMPLE/routingcontrol/jklmnopqrsEXAMPLE"]
}
}
}
```
The following is an example ARC event for a *Region switch plan evaluation warning*.
For a Region switch plan evaluation, an event is emitted when a warning is returned. If the warning is not cleared, an event is emitted for the warning only once every 24 hours. When the event is cleared, no further events are emitted for that warning.
```
{
"version": "0",
"id": "05d4d2d5-9c76-bfea-72d2-d4614802adb4", # Random uuid
"detail-type": "ARC Region Switch Plan Execution",
"source": "aws.arc-region-switch",
"account": "111122223333",
"time": "2023-11-16T23:38:14Z",
"region": "us-east-1",
"resources": ["arn:aws:arc-region-switch::111122223333:plan/a2b89be4821bfd1d"],
"detail": {
"version": "0.0.1",
"idempotencyKey": "1111111-2222-3333-4444-5555555555",
"metadata": {
"evaluationTime" : "timestamp",
"warning" : "There is a plan evaluation warning for arn:aws:arc-region-switch::111122223333:plan/a2b89be4821bfd1d. Navigate to the Region switch console to resolve."
}
}
}
```
## Specify a CloudWatch log group to use as a target
When you create an EventBridge rule, you must specify the target where events that are matched to the rule are sent. For a list of available targets for EventBridge, see [Targets available in the EventBridge console](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html#eb-console-targets). One of the targets that you can add to an EventBridge rule is an Amazon CloudWatch log group. This section describes the requirements for adding CloudWatch log groups as targets, and provides a procedure for adding a log group when you create a rule.
To add a CloudWatch log group as a target, you can do one of the following:
+ Create a new log group
+ Choose an existing log group
If you specify a new log group using the console when you create a rule, EventBridge automatically creates the log group for you. Make sure that the log group that you use as a target for the EventBridge rule starts with `/aws/events`. If you want to choose an existing log group, be aware that only log groups that start with `/aws/events` appear as options in the drop-down menu. For more information, see [Create a new log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#Create-Log-Group) in the *Amazon CloudWatch User Guide*.
If you create or use a CloudWatch log group to use as a target using CloudWatch operations outside of the console, make sure that you set permissions correctly. If you use the console to add a log group to an EventBridge rule, then the resource-based policy for the log group is updated automatically. But, if you use the AWS Command Line Interface or an AWS SDK to specify a log group, then you must update resource-based policy for the log group. The following example policy illustrates the permissions that you must define in a resource-based policy for the log group:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Effect": "Allow",
"Principal": {
"Service": [
"events.amazonaws.com",
"delivery.logs.amazonaws.com"
]
},
"Resource": "arn:aws:logs:us-east-1:222222222222:log-group:/aws/events/*:*",
"Sid": "TrustEventsToStoreLogEvent"
}
]
}
```
------
You can't configure a resource-based policy for a log group by using the console. To add the required permissions to a resource-based policy, use the CloudWatch [PutResourcePolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutResourcePolicy.html) API operation. Then, you can use the [ describe-resource-policies](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/describe-resource-policies.html) CLI command to check that your policy was applied correctly.
**To create a rule for a resource event and specify a CloudWatch log group target**
1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. Choose the AWS Region that you want to create the rule in.
1. Choose **Create rule** and then enter any information about that rule, such as the event pattern or schedule details.
For more information about creating EventBridge rules for readiness, see [ Monitor a readiness check resource with EventBridge](eventbridge-readiness.md#RCEventBridgeCreateRule).
1. On the **Select target** page, choose **CloudWatch** as your target.
1. Choose a CloudWatch log group from the drop-down menu.
# Quotas for Region switch
Region switch in Amazon Application Recovery Controller (ARC) is subject to the following quotas.
| Entity | Quota |
| --- | --- |
| Number of plans per account | 10 You can [ request a quota increase](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/arc-region-switch/quotas). |
| Number of execution blocks per plan | 100 |
| Number of Region switch plan execution blocks per plan | 25 |
| Number of parallel execution blocks per step | 20 |
| Number of CloudWatch alarms per trigger condition | 10 |
| Number of Route 53 health check execution blocks per plan | 5 |