# Zonal autoshift in ARC With zonal autoshift, you authorize AWS to shift away resource traffic for an application from an Availability Zone (AZ) during events, on your behalf, to help reduce time to recovery. AWS starts an autoshift when internal telemetry indicates that there is an Availability Zone impairment that could potentially impact customers. When AWS starts an autoshift, application traffic to resources that you've configured for zonal autoshift starts shifting away from the Availability Zone. Be aware that ARC does not inspect the health of individual resources. AWS starts an autoshift when AWS telemetry detects that there is an Availability Zone impairment that could potentially impact customers. In some cases, traffic might be shifted away for resources that are not experiencing impact. With zonal autoshift, you also authorize AWS to shift away resource traffic for an application from an Availability Zone, on your behalf, for regular practice runs. Practice runs are required for zonal autoshift. The zonal shifts that ARC starts for practice runs help you to ensure that shifting away traffic from an Availability Zone during an autoshift is safe for your application. Practice runs regularly test that your application can operate normally without one Availability Zone by starting zonal shifts that shift traffic for a resource away from an Availability Zone. Practice runs take place weekly, and provide an outcome—such as `SUCCEEDED` or `FAILED`—to help you understand if the application operates as expected. **Important** Before you configure practice runs or enable zonal autoshift, we strongly recommend that you pre-scale your application resource capacity in all Availability Zones in the Region where your application resources are deployed. You should not rely on scaling on demand when an autoshift or practice run starts. Zonal autoshift, including practice runs, works independently, and does not wait for auto scaling actions to complete. Relying on auto scaling, instead of pre-scaling, can result in it taking longer for your application to recover. If you use auto scaling to handle regular cycles of traffic, we strongly recommend that you configure the minimum capacity of your auto scaling to continue operating normally with the loss of an Availability Zone. If you plan to enable zonal autoshift or configure practice runs, after you pre-scale your application resource capacity, test that your application can operate normally without one Availability Zone. To test this, start a zonal shift to move traffic for a resource away from an Availability Zone. After you enable zonal autoshift, we recommend that you verify, by starting and evaluating an on-demand practice run zonal shift, that your application can continue operating normally with traffic shifted away from an Availability Zone. Then, the regular practice runs that ARC performs help you to confirm, on an ongoing basis, that you have enough capacity for an autoshift. To ensure that your tests with zonal shift are effective, it's important to validate that traffic drains as expected from the AZ you shift away from. For example, both Application Load Balancers and Network Load Balancers provide per AZ metrics in Amazon CloudWatch that you can use to monitor this. Depending on how long a service and clients reuse connections, traffic might continue to the AZ that you have shifted away from for longer than you expect. To learn more, see [Limit the time that clients stay connected to your endpoints](arc-zonal-autoshift.considerations.md#ZAConsiderationsCurrentConnections). You can enable zonal autoshift, for a supported resource, in the ARC console. Or, in the Amazon EC2 console, you have the option to enable zonal autoshift for a specific load balancer resource. To learn more about enabling zonal autoshift with Elastic Load Balancing, see [Zonal shift](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/zonal-shift.html) in the Elastic Load Balancing User Guide. Autoshifts and practice run zonal shifts are temporary. With autoshifts, when the affected Availability Zone recovers, AWS stops shifting traffic for resources away from the Availability Zone. Application traffic for customers returns to all Availability Zones in the Region. With a practice run, traffic is shifted away from an Availability Zone for a single resource for about 30 minutes, and then shifted back to all Availability Zones in the Region. You can configure Amazon EventBridge notifications to alert you about autoshifts and practice runs. For more information, see [Using zonal autoshift with Amazon EventBridge](eventbridge-zonal-autoshift.md). # How zonal autoshift and practice runs work The zonal autoshift capability in Amazon Application Recovery Controller (ARC) allows AWS to shift traffic for a resource away from an Availability Zone, on your behalf, when AWS determines that there's an impairment that could potentially affect customers in the Availability Zone. Zonal autoshift is designed for a resource that is pre-scaled in all Availability Zones in an AWS Region, so that an application can operate normally with the loss of one Availability Zone. With zonal autoshift, you are required to configure practice runs, where ARC regularly shifts traffic for the resource away from one Availability Zone. ARC schedules practice runs about weekly for each resource that has a practice run configuration associated with it. Practice runs for each resource are scheduled independently. For each practice run, ARC records an outcome. If a practice run is interrupted by a blocking condition, the practice run outcome is not marked as successful. For more information about practice run outcomes, see [Outcomes for practice runs](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes). You can configure Amazon EventBridge notifications to send you information about autoshifts and practice runs. For more information, see [Using zonal autoshift with Amazon EventBridge](eventbridge-zonal-autoshift.md). **Topics** + [About zonal autoshift](arc-zonal-autoshift.how-it-works.about.md) + [When AWS starts and stops autoshifts](arc-zonal-autoshift.how-it-works.start-stop-auto.md) + [When ARC schedules, starts, and ends practice runs](arc-zonal-autoshift.how-it-works.scheduled-practice-runs.md) + [Capacity checks for practice runs](arc-zonal-autoshift.how-it-works.capacity-check.md) + [Notification for practice runs and autoshifts](arc-zonal-autoshift.how-it-works.notifications.md) + [Precedence for zonal shifts](arc-zonal-autoshift.how-it-works.precedence.md) + [Stopping an active autoshift or practice run](arc-zonal-autoshift.how-it-works.stop-shift.md) + [How traffic is shifted away](arc-zonal-autoshift.how-it-works.how-traffic-shifted.md) + [Alarms for practice runs](arc-zonal-autoshift.how-it-works.alarms.md) + [Blocked windows and allowed windows (in UTC)](arc-zonal-autoshift.how-it-works.blocked-windows.md) # About zonal autoshift Zonal autoshift is a capability where AWS shifts application resource traffic away from an Availability Zone, on your behalf. AWS starts an autoshift when internal telemetry indicates that there is an Availability Zone impairment that could potentially impact customers. The internal telemetry incorporates metrics from several sources, including the AWS network, and the Amazon EC2 and Elastic Load Balancing services. You must manually enable zonal autoshift for supported AWS resources. When you deploy and run AWS applications on load balancers in multiple (typically three) AZs in a Region, and you pre-scale to support static stability, AWS can quickly recover customer applications in an AZ by shifting traffic away with an autoshift. By shifting away resource traffic to other AZs in the Region, AWS can reduce the duration and severity of potential impact caused by power outages, hardware or software issues in an AZ, or other impairments. The resources supported by ARC provide integrations that mark the specified AZ as unhealthy, which results in traffic being shifted away from the impaired AZ. When you enable zonal autoshift for a resource, you must also configure a practice run for the resource. AWS performs practice runs about weekly, for 30 minutes, to help you make sure that you have enough capacity to run your application without one of the Availability Zones in the Region. As with zonal shift, there are a few specific scenarios where zonal autoshift does not shift traffic away from the AZ. For example, if the load balancer target groups in the AZs don't have any instances, or if all of the instances are unhealthy, then the load balancer is in a fail open state and you can't shift away one of the AZs. To learn more about zonal autoshift, see [Zonal autoshift in ARC](arc-zonal-autoshift.md). # When AWS starts and stops autoshifts When you enable zonal autoshift for a resource, you authorize AWS to shift away resource traffic for an application from an Availability Zone during events, on your behalf, to help reduce time to recovery. To achieve this, zonal autoshift uses AWS telemetry to detect, as early as possible, that there is an Availability Zone impairment that could potentially impact customers. When AWS starts an autoshift, traffic to configured resources immediately starts shifting away from the impaired Availability Zone that could potentially impact customers. Zonal autoshift is a capability designed for customers who have pre-scaled their application resources for all Availability Zones in an AWS Region. You should not rely on scaling on demand when an autoshift or practice run starts. AWS ends an autoshift when it determines that the Availability Zone has recovered. # When ARC schedules, starts, and ends practice runs ARC schedules a practice run for a resource weekly, for about 30 minutes. ARC schedules, starts, and manages practice runs for each resource independently. ARC does not batch together practice runs for resources in the same account. You can also start on-demand practice runs yourself, to help verify that your setup is safe for a zonal autoshift event. When a practice run continues for the expected duration, without interruption, it is marked with an outcome of `SUCCESSFUL`. There are several other possible outcomes: `FAILED`, `INTERRUPTED`, `CAPACITY_CHECK_FAILED` and `PENDING`. Outcome values and descriptions are included in the [Outcomes for practice runs](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes) section. There are some scenarios when ARC interrupts a practice run and ends it. For example, if an autoshift starts during a practice run, ARC interrupts the practice run and ends it. As another example, say that the resource has an adverse response to a practice run and causes an alarm that you've specified to monitor the practice run to go into an `ALARM` state. In this scenario, ARC also interrupts the practice run and ends it. In addition, there are several scenarios when ARC does not start a schedule practice run for a resource. In response to interrupted and blocked practice runs for a resource, ARC does the following: + If a practice run for a resource is interrupted while it's in progress, ARC considers the weekly practice run to be over, and schedules a new practice run for the resource for the next week. The weekly practice outcome is `INTERRUPTED` in this scenario, not `FAILED`. The practice run outcome set to `FAILED` only when the outcome alarm that monitors the practice run goes into an `ALARM` state during the practice run. + If there is a blocking constraint when a practice run for a resource is scheduled to be started, ARC does not start the practice run. ARC continues regular monitoring, to determine if there are still one or more blocking constraints. When there aren't any blocking constraints, ARC starts the practice run for the resource. The following are examples of blocking constraints that stop ARC from starting, or continuing, a practice run for a resource: + ARC does not start or continue practice runs when there is an AWS Fault Injection Service experiment in progress. If an AWS FIS event is active when ARC has scheduled a practice run to start, ARC does not start the practice run. ARC monitors throughout practice runs for blocking constraints, including an AWS FIS event. If an AWS FIS event starts while a practice run is active, ARC ends the practice run and doesn't attempt to start another one until the next regularly scheduled practice run for the resource. + If there is a current AWS event in a Region, ARC does not start practice runs for resources, and ends active practice runs, in the Region. When the practice run finishes without being interrupted, ARC schedules the next practice run in a week, as usual. If a practice run isn't started because of a blocking constraint, such as a AWS FIS experiment or a blocked time window that you've specified, ARC continues to attempt to start a practice run until the practice run can be started. # Capacity checks for practice runs When a practice run starts, to temporarily move traffic away from an Availability Zone, ARC runs a check to verify that you have enough capacity in other Availability Zones to safely move traffic away from the AZ. If there isn't sufficient capacity available, the traffic shift for the practice run is not started and the practice run ends. In addition, ARC runs a capacity check for load balancer resources when a zonal autoshift completes, before ARC ends the traffic shift started by the autoshift. If the capacity check fails when the autoshift ends, traffic is not shifted back to the Availability Zone that it was moved away from. Checks for balanced capacity are only completed for load balancers and Auto Scaling groups. For a load balancer resource, capacity checks validate that healthy hosts associated with the load balancer are distributed across Availability Zones. Specifically, capacity checks make sure that the number of healthy hosts across all Availability Zones where the resource is registered are balanced. For capacity checks, balanced means that the healthy capacity for each Availability Zone is in parity with the other zones, within a small variance. Note that capacity checks are not applied to load balancers with target groups of type Lambda nor to Application Load Balancers, because those targets are not configured zonally. Capacity checks are also completed for Auto Scaling groups. For an Auto Scaling group, capacity checks validate that the total healthy zonal capacity of an Auto Scaling group–that is, the number of total healthy hosts across all the Availability Zones–meet the desired capacity set for that Auto Scaling group. **When a capacity check fails** When a capacity check finds that available capacity isn't balanced for a resource, the outcome for the practice run is `CAPACITY_CHECK_FAILED`. To learn more about why a capacity check has failed, see the comment field for the `ZonalShiftSummary`. To find the comment field for your practice run zonal shift, do the following: 1. Using the AWS CLI, list the zonal shifts for the resource that you specified in the practice run using the [ListZonalShifts](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_ListZonalShifts.html) API operation. FOr example, to return the zonal shifts, you can run a command similar to the following: ``` aws arc-zonal-shift start-practice-run --resource-identifier="arn:aws:elasticloadbalancing:Region:111122223333:ExampleALB123456890" ``` 1. Review the array of `ZonalShiftSummary` objects returned to find the zonal shift for the practice run that failed due to capacity checks. 1. For the applicable zonal shift, review the information in the `Comment` field. # Notification for practice runs and autoshifts You can choose to be notified about practice runs and autoshifts for your resource by setting up Amazon EventBridge notifications. You can set up EventBridge notifications even when you haven't enabled zonal autoshift for any resources, known as *autoshift observer notification*. With autoshift observer notification, you are notified about all autoshifts that ARC starts when an Availability Zone is potentially impaired. Note that you must configure this option in each AWS Region that you want to receive notifications about. To see the steps for enabling autoshift observer notification, see [Enabling or disabling autoshift observer notification](arc-zonal-autoshift.enable-autoshift-observer.md). To learn more about notification options and how to configure them in EventBridge, see [Using zonal autoshift with Amazon EventBridge](eventbridge-zonal-autoshift.md). # Precedence for zonal shifts There can be no more than one applied zonal shift at a given time. That is, only one practice run zonal shift, customer-initiated zonal shift, autoshift, or AWS FIS experiment for the resource. When a second zonal shift is started, ARC follows a precedence to determine which zonal shift type is in effect for a resource. The general principle for precedence is that zonal shifts that you start as a customer take precedence over other shift types. However, be aware that a currently-running AWS-initiated practice run prevents you from starting an on-demand practice run. To illustrate precedence in ARC, the following is how precedence works for example scenarios: | Zonal shift type applied | Zonal shift type initiated | Result | | --- | --- | --- | | AWS FIS experiment | Practice run | The practice run will fail to start, as the AWS FIS experiment takes precedence. | | AWS FIS experiment | Manual zonal shift | The AWS FIS experiment will be canceled, and the manual zonal shift will be applied. | | AWS FIS experiment | Zonal autoshift | The AWS FIS experiment will be canceled, and the zonal autoshift will be applied. | | AWS FIS experiment | AWS FIS experiment | The initiated AWS FIS experiment will fail to start because there is an existing experiment running that triggered the AWS FIS autoshift action. | | Practice run | Manual zonal shift | The practice run will be canceled and the outcome set to INTERRUPTED, and the zonal shift will be applied. | | Practice run | AWS FIS experiment | The practice run will be canceled and the outcome set to INTERRUPTED, and the AWS FIS experiment will be applied. | | Practice run | Zonal autoshift | The practice run will be canceled and the outcome set to INTERRUPTED, and the zonal autoshift will be applied. | | Manual zonal shift | Practice run | The practice run will fail to start. | | Manual zonal shift | AWS FIS experiment | The AWS FIS experiment will fail to start, or fail if it's already in progress. | | Manual zonal shift | Zonal autoshift | The zonal autoshift will be ACTIVE but not APPLIED on the resource. The manual zonal shift takes precedence. | | Zonal autoshift | AWS FIS experiment | The AWS FIS experiment will fail to start, or will fail if it's in progress. | | Zonal autoshift | Manual zonal shift | The zonal autoshift will be ACTIVE but not APPLIED on the resource. The manual zonal shift takes precedence. | | Zonal autoshift | Practice run | The practice run will fail to start, as the zonal autoshift takes precedence. | The traffic shift that is currently in effect for the resource has an applied zonal shift status set to `APPLIED`. Only one shift is set to `APPLIED` at any time. Other shifts that are in progress are set to `NOT_APPLIED`, but remain with `ACTIVE` status. # Stopping an active autoshift or practice run for a resource To stop an in-progress autoshift for a resource you must cancel the zonal shift. Regular practice runs still take place for the resource, on the same schedule. If you want to stop practice runs in addition to disabling autoshifts, you must delete the practice run configuration associated with the resource. When you delete a practice run configuration, AWS stops performing practice runs that shift traffic for the resource away from an Availability Zone each week. In addition, because zonal autoshift requires practice runs, when you delete a practice run configuration using the ARC console, this action also disables zonal autoshift for the resource. However, note that if you use the zonal autoshift API to delete a practice run, you must first disable zonal autoshift for the resource. For more information, see [Canceling a zonal autoshift](arc-zonal-autoshift.canceling-an-autoshift.md) and [Enabling and working with zonal autoshift](arc-zonal-autoshift.start-cancel.md). # How traffic is shifted away For autoshifts and for practice run zonal shifts, traffic is shifted away from an Availability Zone using the same mechanism that ARC uses for customer-initiated zonal shifts. An unhealthy health check results in Amazon Route 53 withdrawing the corresponding IP addresses for the resource from DNS, so that traffic is redirected from the Availability Zone. New connections are now routed to other Availability Zones in the AWS Region instead. With an autoshift, when an Availability Zone recovers and AWS decides to end the autoshift, ARC reverses the health check process, requesting the Route 53 health checks to be reverted. Then, the original zonal IP addresses are restored and, if the health checks continue to be healthy, the Availability Zone is included in the application's routing again. It's important to be aware that autoshifts are not based on health checks that monitor the underlying health of load balancers or applications. ARC uses health checks to move traffic away from Availability Zones, by requesting health checks to be set to unhealthy, and then restores health checks to normal again when it ends an autoshift or zonal shift. # Alarms for practice runs You can specify two types of CloudWatch alarms for practice runs in zonal autoshift: outcome alarms and blocking alarms. **Outcome alarms (required)** For the first type of alarm, the *outcome alarm*, at least one alarm is required to be specified. You should configure outcome alarms to monitor the health of your application when traffic is shifted away from an Availability Zone during each 30-minute practice run. For a practice run to be effective, specify as outcome alarms at least one CloudWatch alarm that meets both of the following criteria: The alarm monitors metrics for the resource, or for your application AND The alarm responds with an `ALARM` state when your application is adversely affected by the loss of one Availability Zone. For more information, see the **Alarms that you specify for practice runs** section in [Best practices when you configure zonal autoshift](arc-zonal-autoshift.considerations.md). Outcome alarms also provide information for the *practice run outcome* that ARC reports for each practice run. If an outcome alarm enters an `ALARM` state, ARC ends the practice run and returns a practice run outcome of `FAILED`. If the practice run completes the 30 minute test period and none of the outcome alarms that you've specified enters an `ALARM` state, the outcome returned is `SUCCEEDED`. A list of all outcome values, with descriptions, is provided in the [Outcomes for practice runs](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes) section. **Blocking alarms (optional)** Optionally, you can specify a second type of alarm, the *blocking alarm*. Blocking alarms block practice runs from starting, or continuing, when one or more of the alarms is in an `ALARM` state. Blocking alarms block practice run traffic shifts from being started—and stop any practice runs in progress—when at least one of the alarms is in an `ALARM` state. For example, in a large architecture with multiple microservices, when one microservice is experiencing a problem, you typically want to stop all other changes in the application environment, which would including blocking practice runs. You can add a blocking alarm in ARC to accomplish this. # Blocked windows and allowed windows (in UTC) You have the option to *block* or *allow* practice runs for specific calendar dates, or for specific time windows, that is, days and times, specified in UTC. For example, if you have an application update scheduled to launch on May 1, 2024, and you don't want practice runs to shift traffic away at that time, you could set a blocked date for `2024-05-01`. Or, say you run business report summaries three days a week. For this scenario, you could set the following recurring days and times as blocked windows, for example, in UTC: `MON-20:30-21:30 WED-20:30-21:30 FRI-20:30-21:30`. Alternatively, you might decide that Wednesdays and Fridays from noon to 5:00 are the best times for ARC to start practice runs, to test your setup. For this scenario, you could set the following recurring days and times as allowed windows, for example, in UTC: `WED-12:00-17:00 FRI-12:00-17:00`. # AWS Region availability for zonal autoshift Zonal shift and zonal autoshift are currently available in the commercial AWS Regions, as well as the China Regions, that is, China (Beijing) Region and China (Ningxia) Region. Resources that use Amazon Application Recovery Controller (ARC) can include additional considerations. For more information, see [Supported resources](arc-zonal-shift.resource-types.md). For a list of Regions and detailed information about Regional support and service endpoints for ARC, see [Amazon Application Recovery Controller (ARC) endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/r53arc.html) in the *Amazon Web Services General Reference*. # Zonal autoshift components The following diagram illustrates an example of an autoshift shifting traffic away from an Availability Zone. AWS starts an autoshift when internal telemetry indicates that there is an Availability Zone impairment that could potentially impact customers. ![\[Diagram of an autoshift with three Availability Zones\]](http://docs.aws.amazon.com/r53recovery/latest/dg/images/ZonalAutoshiftDiagram.png) The following are components of the zonal autoshift capabilities in ARC. **Zonal autoshifts** Zonal autoshift shifts traffic away for a resource, without requiring you to take any action. Zonal autoshift is a capability in ARC where AWS starts an autoshift when internal telemetry indicates that there is an Availability Zone impairment that could potentially impact customers. Be aware that, in some cases, resources might be shifted away that are not experiencing impact. **Practice runs** When you enable zonal autoshift for a resource, you must also configure zonal autoshift *practice runs* for the resource. AWS performs a zonal shift for practice runs about weekly, for about 30 minutes. You can also schedule practice runs on-demand. Practice runs make sure that your application can run normally with the loss of one Availability Zone. In a practice run, AWS shifts traffic for a resource away from one Availability Zone with a zonal shift, and then shifts traffic back when the practice run ends. **Practice run configurations** With a practice run configuration, you can define the time frames (blocked or allowed windows)for when ARC can start a practice run for a resource with zonal autoshift. You also define the CloudWatch alarms for an AWS practice run. You can edit a practice run configuration at any time, to add or change blocked or allowed windows, or to update the alarms for the practice run. To enable zonal autoshift, you must have a practice run configuration in place for a resource. You can delete a practice run, but first, you must disable zonal autoshift. **Practice run alarms** When you configure practice runs, you specify CloudWatch alarms (that you first create in CloudWatch), based on your resource and application requirements. The alarms that you specify can block a practice run from starting, or can stop a practice run in progress, if your application is adversely affected by the practice run. If an alarm that you specify goes into an `ALARM` state, ARC ends the zonal shift for the practice run, so that traffic for the resource is no longer shifted away from the Availability Zone. There are two types of alarms that you specify for practice runs: *outcome* alarms, to monitor the health of your resource and application during the practice run, and *blocking* alarms, which you can configure to prevent practice runs from starting, or to stop an in-progress practice run. At least one outcome alarm is required; blocking alarms are optional. **Practice run outcomes** ARC reports an outcome for each practice run. The following are the possible practice run outcomes: + **PENDING:** The zonal shift for the practice run is active (in progress). There's no outcome to return yet. + **SUCCEEDED:** The outcome alarm did not enter an `ALARM` state during the practice run, and the practice run completed the full 30 minute test period. + **INTERRUPTED:** The practice run ended for a reason that was not the outcome alarm entering an `ALARM` state. A practice run can be interrupted for a variety of reasons. For example, a practice run that ends because the blocking alarm specified for the practice run entered an `ALARM` state has an outcome of `INTERRUPTED`. For more information about reasons for an `INTERRUPTED` outcome, see [Outcomes for practice runs](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes). + **FAILED:** The outcome alarm entered an `ALARM` state during the practice run. + **CAPACITY\$1CHECK\$1FAILED:** The check for balanced capacity across Availability Zones for your load balancing and Auto Scaling group resources failed. **Built-in safety rules** Safety rules built into ARC prevent more than one traffic shift for a resource from being in effect at a time. That is, only one customer-initiated zonal shift, practice run zonal shift (initiated by AWS or by a customer), or autoshift for the resource can be actively shifting traffic away from an Availability Zone. For example, if you start a zonal shift for a resource when it is currently shifted away with autoshift, your zonal shift takes precedence. For more information, see [Precedence for zonal shifts](arc-zonal-autoshift.how-it-works.precedence.md#ZAShiftPrecedence). **Resource identifier** The identifier for a resource to enable zonal autoshift for, which is the Amazon Resource Name (ARN) for the resource. You can only enable zonal autoshift for resources in your account that are in an AWS service that is supported by ARC. **Managed resource** Application Load Balancers register resources automatically with ARC for zonal autoshift. You must manually opt-in other resources for zonal autoshift. **Resource name** The name of a managed resource in ARC. **Applied status** An applied status indicates whether a traffic shift is in effect for a resource. When you configure zonal autoshift, a resource can have more than one active traffic shift—that is, a practice run zonal shift, customer-initiated zonal shift, or autoshift. However, only one is *applied*, that is, is in effect for the resource at a time. The shift that has the status `APPLIED` determines the Availability Zone where application traffic has been shifted away for a resource, and when that traffic shift ends. **Shift type** Defines the zonal shift type. Zonal shifts can have one of the following types: + **ZONAL\$1SHIFT** + **ZONAL\$1AUTOSHIFT** + **PRACTICE\$1RUN** + **FIS\$1EXPERIMENT** # Data and control planes for zonal autoshift 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. 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. 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. # Pricing for zonal autoshift in ARC For zonal autoshift, AWS shifts traffic away from an Availability Zone on your behalf for supported resources when AWS determines that there is a potential issue that can adversely affect customer applications. There is no additional charge for enabling zonal autoshift. For detailed pricing information for ARC and pricing examples, see [ARC Pricing](https://aws.amazon.com/application-recovery-controller/pricing/). # Best practices when you configure zonal autoshift Be aware of the following best practices and considerations when you enable zonal autoshift in Amazon Application Recovery Controller (ARC). Zonal autoshift includes two types of traffic shifts: autoshifts and practice run zonal shifts. + With an *autoshift*, AWS helps reduce your time to recovery by shifting away application resource traffic from an Availability Zone during events, on your behalf. + With *practice runs*, ARC starts a zonal shift on your behalf or you start a zonal shift practice run. The AWS practice run zonal shift shifts traffic away from an Availability Zone for a resource, and back again, on a weekly cadence. Practice runs help you to make sure that you have scaled up sufficient capacity for Availability Zones in a Region for your application to tolerate the loss of one Availability Zone. There are several best practices and considerations to keep in mind with autoshifts and practice runs. Review the following topics before you enable zonal autoshift or configure practice runs for a resource. **Topics** + [Limit the time that clients stay connected to your endpoints](#ZAConsiderationsCurrentConnections) + [Prescale your resource capacity and test shifting traffic](#ZAConsiderationsCapacityPrescaling) + [Be aware of resource types and restrictions](#ZAConsiderationsResourceRequirements) + [Specify alarms for practice runs](#ZAConsiderationsPracticeRunAlarms) + [Evaluate outcomes for practice runs](#ZAConsiderationsPracticeRunOutcomes) **Limit the time that clients stay connected to your endpoints** When Amazon Application Recovery Controller (ARC) shifts traffic away from an impairment, for example, by using zonal shift or zonal autoshift, the mechanism that ARC uses to move your application traffic is a DNS update. A DNS update causes all new connections to be directed away from the impaired location. However, clients with pre-existing open connections might continue to make requests against the impaired location until the clients reconnect. To ensure a quick recovery, we recommend that you limit the amount of time clients stay connected to your endpoints. If you use an Application Load Balancer, you can use the `keepalive` option to configure how long connections continue. We suggest that you lower the `keepalive` value to be inline with your recovery time goal for your application, for example, 300 seconds. When you choose a `keepalive` time, consider that this value is a trade off between reconnecting more frequently in general, which can affect latency, and more quickly moving all clients away from an impaired AZ or Region. For more information about setting the `keepalive` option for Application Load Balancer, see the [ HTTP client keepalive duration](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#http-client-keep-alive-duration) in the Application Load Balancer User Guide. **Prescale your resource capacity and test shifting traffic** When AWS shifts traffic away from one Availability Zone for a zonal shift or an autoshift, it's important that the remaining Availability Zones can service the increased request rates for your resource. This pattern is known as *static stability*. For more information, see the [ Static stability using Availability Zones whitepaper](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) in the Amazon Builder’s Library. For example, if your application requires 30 instances to serve its clients, you should provision 15 instances across three Availability Zones, for a total of 45 instances. By doing this, when AWS shifts traffic away from one Availability Zone—with an autoshift or during a practice run—AWS can still serve your application’s clients with the remaining total of 30 instances, across two Availability Zones. The zonal autoshift capability in ARC helps you to quickly recover from AWS events in an Availability Zone when you have an application with resources that are pre-scaled to work normally with the loss of one Availability Zone. Before you enable zonal autoshift for a resource, scale your resource capacity in all configured Availability Zones in an AWS Region. Then, start zonal shifts for the resource, to test that your application still runs normally when traffic is shifted away from an Availability Zone. After you test with zonal shifts, then enable zonal autoshift and configure practice runs for application resources. Run your own on-demand practice runs to help ensure that your configuration is scaled properly. Regular practice runs with zonal autoshift help you to make sure—on an ongoing basis—that your capacity is still scaled appropriately. With sufficient capacity across Availability Zones, your application can continue to serve clients, without interruption, during an autoshift. For more information about starting a zonal shift for a resource, see [Zonal shift in ARC](arc-zonal-shift.md). **Be aware of resource types and restrictions** Zonal autoshift supports shifting traffic out of an Availability Zone for all resources that are supported by zonal shift. In a few specific resource scenarios, zonal autoshift does not shift traffic from an Availability Zone for an autoshift. For example, if the load balancer target groups in the Availability Zones don't have any instances, or if all of the instances are unhealthy, then the load balancer is in a fail open state. If AWS starts an autoshift for a load balancer in this scenario, an autoshift does not change which Availability Zones the load balancer uses because the load balancer is already in a fail open state. This is expected behavior. Autoshift cannot cause one Availability Zone to be unhealthy and shift traffic to the other Availability Zones in an AWS Region if all Availability Zones are failing open (unhealthy). To see details about supported resources, including all of the requirements and exceptions to be aware of, see [Supported resources](arc-zonal-shift.resource-types.md). **Specify alarms for practice runs** You must configure at least one type of alarm (an outcome alarm) for practice runs with zonal autoshift. Optionally, you can also configure a second type of alarm (blocking alarms). When you consider the CloudWatch alarms that you configure for practice runs for your resource, keep in mind the following: + You're required to configure at least one outcome alarm for a practice run configuration. For outcome alarms, we recommend that you configure CloudWatch alarms to go into an `ALARM` state when metrics for the resource, or your application, indicate that shifting traffic away from the Availability Zone adversely impacts performance. For example, you can determine a threshold for request rates for your resource, and then configure an alarm to go into an `ALARM` state when the threshold is exceeded. You are responsible for configuring appropriate alarms that cause AWS to end the practice run and return a `FAILED` outcome. + We recommend that you follow the [AWS Well Architected Framework](https://docs.aws.amazon.com/wellarchitected/2022-03-31/framework/perf_monitor_instances_post_launch_establish_kpi.html), which advises you to implement key performance indicators (KPIs) as CloudWatch alarms. If you do so, you can use these alarms to create a composite alarm to use as a safety trigger, to prevent practice runs from starting if they might cause your application to miss a KPI. When the alarm is no longer in an `ALARM` state, ARC starts practice runs the next time a practice run is scheduled for the resource. + For practice run blocking alarms, if you choose to configure one (or more), you might choose to track specific metrics that you use to indicate that you don't want an AWS practice run to start—for example, when an alarm indicates that there is an ongoing incident. + For practice run alarms, you specify the Amazon Resource Name (ARN) for each alarm, so you must first configure the alarm in Amazon CloudWatch. The CloudWatch alarms that you specify can be composite alarms, to enable you to include several metrics and checks for your application and resource that can trigger the alarm to go into an `ALARM` state. Or, you can configure separate alarms, and then specify more than one alarm of each type for your practice run configuration. For more information, see [Combining alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) in the Amazon CloudWatch User Guide. + Make sure that the CloudWatch alarms that you specify for practice runs are in the same Region as the resource that you're configuring a practice run for. **Evaluate outcomes for practice runs** ARC reports an outcome for each practice run. After a practice run, evaluate the outcome, and determine if you need to take action. For example, you might need to scale capacity or adjust the configuration for an alarm. The following are the possible practice run outcomes: + **SUCCEEDED:** No outcome alarms entered an `ALARM` state during the practice run, and the practice run completed the full 30 minute test period. + **FAILED: ** At least one outcome alarm entered an `ALARM` state during the practice run. + **INTERRUPTED: ** The practice run ended for a reason that was not the outcome alarm entering an `ALARM` state. A practice run can be interrupted for a variety of reasons, including the following: + Practice run was ended because AWS started an autoshift in the AWS Region or there was an alarm condition in the Region. + Practice run was ended because the practice run configuration was deleted for the resource. + Practice run was ended because a customer-initiated zonal shift was started for the resource in the Availability Zone that the practice run zonal shift was shifting traffic away from. + Practice run was ended because a CloudWatch alarm that was specified for the practice run configuration could no longer be accessed. + Practice run was ended because a blocking alarm specified for the practice run entered an `ALARM` state. + Practice run was ended for an unknown reason. + Practice run was ended because a zonal autoshift with precedence was initiated. See [Precedence for zonal shifts](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.how-it-works.html#ZAShiftPrecedence). + **CAPACITY\$1CHECK\$1FAILED:** The check for balanced capacity across Availability Zones for your load balancing and Auto Scaling group resources failed. + **PENDING:** The practice run is active (in progress). There's no outcome to return yet. # Zonal autoshift API operations The following table lists ARC API operations that you can use with zonal autoshift. For examples of using zonal autoshift API operations with the AWS CLI, see . For examples of how to use common zonal autoshift API operations with the AWS Command Line Interface, see [Examples of using the AWS CLI with zonal autoshift](getting-started-cli-zonal-autoshift.md). | Action | Using the ARC console | Using the ARC API | | --- | --- | --- | | Create a practice run configuration | See [Enabling or disabling zonal autoshift](arc-zonal-autoshift.start-cancel.md#arc-zonal-autoshift.configure) | See [CreatePracticeRunConfiguration](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_CreatePracticeRunConfiguration.html) | | Delete a practice run configuration | See [Configuring, editing, or deleting a practice run configuration](arc-zonal-autoshift.edit-delete-practice-run.md) | See [DeletePracticeRunConfiguration](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_DeletePracticeRunConfiguration.html) | | List autoshifts | See [Zonal autoshift in ARC](arc-zonal-shift.md) | See [ListAutoshifts](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_ListAutoshifts.html) | | List resources for zonal autoshift | See [Supported resources](arc-zonal-shift.resource-types.md) | See [ListManagedResources](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_ListManagedResources.html) | | Get resources for zonal autoshift | See [Supported resources](arc-zonal-shift.resource-types.md) | See [GetManagedResource](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_GetManagedResource.html) | | Edit a practice run configuration | See [Configuring, editing, or deleting a practice run configuration](arc-zonal-autoshift.edit-delete-practice-run.md) | See [UpdatePracticeRunConfiguration](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_UpdatePracticeRunConfiguration.html) | | Enable or disable zonal autoshift | See [Enabling or disabling zonal autoshift](arc-zonal-autoshift.start-cancel.md#arc-zonal-autoshift.configure) | See [UpdateZonalAutoshiftConfiguration](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_UpdateZonalAutoshiftConfiguration.html) | | Enable or disable autoshift observer notification | See [Enabling and working with zonal autoshift](arc-zonal-autoshift.start-cancel.md) | See [UpdateAutoshiftObserverNotificationStatus](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_UpdateAutoshiftObserverNotificationStatus.html) | | Start a practice run | See [Starting a practice run zonal shift](arc-zonal-autoshift.start-cancel.md) | See [StartPracticeRun](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_StartPracticeRun.html) | | Cancel a practice run | See [Canceling a practice run zonal shift](arc-zonal-autoshift.start-cancel.md) | See [CancelPracticeRun](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_CancelPracticeRun.html) | # Examples of using the AWS CLI with zonal autoshift This section walks through simple application examples of working with zonal autoshift, using the AWS Command Line Interface to work with the zonal autoshift capability in Amazon Application Recovery Controller (ARC) using API operations. The examples are intended to help you develop a basic understanding of how to work with zonal autoshift using the CLI. Zonal autoshift is a capability in ARC. With zonal autoshift, you authorize AWS to shift away supported application resource traffic from an Availability Zone during events, on your behalf, to help reduce your time to recovery. For more information about resources that you can use with zonal autoshift, see [Supported resources](arc-zonal-shift.resource-types.md). Zonal autoshift includes practice runs, which also shift traffic away from Availability Zones, to help verify that autoshifts are safe for your application. For a list of zonal autoshift API actions and links to more information, see [Zonal autoshift API operations](actions.zonalautoshift.md). For more information about using the AWS CLI, see the [AWS CLI Command Reference](https://docs.aws.amazon.com/cli/latest/reference/arc-zonal-shift/index.html). **Topics** + [Create a practice run configuration](getting-started-cli-update-zonal_autoshift.create-practice-run.md) + [Enable or disable autoshifts](getting-started-cli-zonal-autoshift.update-autoshift.md) + [Start an on-demand practice run](getting-started-cli-zonal-autoshift.start-practice-run.md) + [Cancel an in-progress practice run](getting-started-cli-zonal-autoshift.cancel-practice-run.md) + [Cancel an in-progress autoshift](getting-started-cli-zonal-autoshift.cancel-autoshift.md) + [Edit a practice run configuration](getting-started-cli-zonal_autoshift.edit-practice-run-config.md) + [Delete a practice run configuration](getting-started-cli-zonal-autoshift.delete-practice-run-config.md) # Create a practice run configuration Before you can enable zonal autoshift for a resource, you must create a practice run configuration for the resource, to choose options for the required practice runs. You create a practice run configuration for a resource with the CLI by using the `create-practice-run-configuration` command. Note the following when you create a practice run configuration for a resource: + The only supported alarm type at this time is `CLOUDWATCH`. + You must use alarms that are in the same AWS Region that your resource is deployed in. + Specifying an outcome alarm is required. Specifying a blocking alarm is optional. + Specifying blocked or allowed dates or windows is optional. You create a practice run configuration with the CLI by using the `create-practice-run-configuration` command. For example, to create a practice run configuration for a resource, use a command like the following: ``` aws arc-zonal-shift create-practice-run-configuration \ --resource-identifier="arn:aws:elasticloadbalancing:Region:111122223333:ExampleALB123456890" \ --outcome-alarms type=CLOUDWATCH,alarmIdentifier=arn:aws:cloudwatch:Region:111122223333:alarm:Region-MyAppHealthAlarm \ --blocking-alarms type=CLOUDWATCH,alarmIdentifier=arn:aws:cloudwatch:Region:111122223333:alarm:Region-BlockWhenALARM \ --blocked-dates 2023-12-01 --blocked-windows Mon:10:00-Mon:10:30 ``` ``` { "arn": "arn:aws:elasticloadbalancing:us-west-2:111122223333:ExampleALB123456890", "name": "zonal-shift-elb" "zonalAutoshiftStatus": "DISABLED", "practiceRunConfiguration": { "blockingAlarms": [ { "type": "CLOUDWATCH", "alarmIdentifier": "arn:aws:cloudwatch:us-west-2:111122223333:alarm:us-west-2-BlockWhenALARM" } ] "outcomeAlarms": [ { "type": "CLOUDWATCH", "alarmIdentifier": "arn:aws:cloudwatch:us-west-2:111122223333:alarm:us-west-2-MyAppHealthAlarm" } ], "blockedWindows": [ "Mon:10:00-Mon:10:30" ], "blockedDates": [ "2023-12-01" ] } ``` # Enable or disable autoshifts You enable or disable autoshifts for a resource by updating the zonal autoshift status with the CLI. To change the zonal autoshift status, use the `update-zonal-autoshift-configuration` command. For example, to enable autoshifts for a resource, use a command like the following: ``` aws arc-zonal-shift update-zonal-autoshift-configuration \ --resource-identifier="arn:aws:elasticloadbalancing:Region:111122223333:ExampleALB123456890" \ --zonal-autoshift-status="ENABLED" ``` ``` { "resourceIdentifier": "arn:aws:elasticloadbalancing:us-west-2:111122223333:ExampleALB123456890", "zonalAutoshiftStatus": "ENABLED" } ``` # Start an on-demand practice run You can start an on-demand practice run zonal shift with the CLI by using the `start-practice-run` command. For example, to start a practice run for a resource, use a command like the following: ``` aws arc-zonal-shift start-practice-run --resource-identifier="arn:aws:elasticloadbalancing:Region:111122223333:ExampleALB123456890" \ "awayFrom": "usw2-az1", ``` ``` { "awayFrom": "usw2-az1", "comment": "Practice run started. Shifting traffic away from Availability Zone usw2-az1.", } ``` # Cancel an in-progress practice run You can cancel an in-progress practice run with the CLI by using the `cancel-practice-run` command. For example, to cancel a practice run for a resource, use a command like the following: ``` aws arc-zonal-shift cancel-practice-run \ --zonal-shift-id="="arn:aws:testservice::111122223333:ExampleALB123456890" ``` ``` { "zonalShiftId": "2222222-3333-444-1111", "resourceIdentifier": "arn:aws:testservice::111122223333:ExampleALB123456890", "awayFrom": "usw2-az1", "expiryTime": 2024-11-15T10:35:42+00:00, "startTime": 2024-11-15T09:35:42+00:00, "status": "CANCELED", "comment": "Practice run canceled" } ``` # Cancel an in-progress autoshift You can cancel an in-progress autoshift with the CLI by canceling the zonal autoshift for the resource. To cancel a zonal autoshift, use the `cancel-zonal-shift command`. ``` aws arc-zonal-shift cancel-zonal-shift --zonal-shift-id 9ac9ec1e-1df1-0755-3dc5-8cf573cd9c38 ``` ``` { "awayFrom": "usw2-az1", "comment": "Zonal autoshift started. Shifting traffic away from Availability Zone usw2-az1.", "expiryTime": "2024-12-17T22:29:38-08:00", "resourceIdentifier": "arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/Testing/5a19403ecd42dc05", "startTime": "2024-12-17T21:27:26-08:00", "status": "CANCELED", "zonalShiftId": "9ac9ec1e-1df1-0755-3dc5-8cf573cd9c38" } ``` # Edit a practice run configuration You can edit a practice run configuration for a resource with the CLI to update different configuration options, such as changing the alarms for practice runs or updating the blocked dates or blocked windows, when ARC won't start practice runs. To edit a practice run configuration, use the `update-practice-run-configuration` command. Note the following when you edit a practice run configuration for a resource: + The only supported alarm type at this time is `CLOUDWATCH`. + You must use alarms that are in the same AWS Region that your resource is deployed in. + Specifying an outcome alarm is required. Specifying a blocking alarm is optional. + Specifying blocked dates or blocked windows is optional. + The blocked dates or blocked windows that you specify replace any existing values. For example, to edit a practice run configuration for a resource to specify a new blocked date, use a command like the following: ``` aws arc-zonal-shift update-practice-run-configuration \ --resource-identifier="arn:aws:elasticloadbalancing:Region:111122223333:ExampleALB123456890" \ --blocked-dates 2024-03-01 ``` ``` { "arn": "arn:aws:elasticloadbalancing:us-west-2:111122223333:ExampleALB123456890", "name": "zonal-shift-elb" "zonalAutoshiftStatus": "DISABLED", "practiceRunConfiguration": { "blockingAlarms": [ { "type": "CLOUDWATCH", "alarmIdentifier": "arn:aws:cloudwatch:us-west-2:111122223333:alarm:us-west-2-BlockWhenALARM" } ] "outcomeAlarms": [ { "type": "CLOUDWATCH", "alarmIdentifier": "arn:aws:cloudwatch:us-west-2:111122223333:alarm:us-west-2-MyAppHealthAlarm" } ], "blockedWindows": [ "Mon:10:00-Mon:10:30" ], "blockedDates": [ "2024-03-01" ] } ``` # Delete a practice run configuration You can delete a practice run configuration for a resource, but you must first disable zonal autoshift for the resource. A resource is required to have a practice run configuration to have zonal autoshift enabled. Regular practice runs help you to make sure that your application can run normally without one Availability Zone. To delete a practice run configuration by using the CLI, first, disable zonal autoshift, if needed by using the `update-zonal-autoshift` command. Then, to delete the practice run configuration, use the `delete-practice-run-configuration` command. First, disable zonal autoshift for the resource, using a command like the following: ``` aws arc-zonal-shift update-zonal-autoshift-configuration \ --resource-identifier="arn:aws:elasticloadbalancing:Region:111122223333:ExampleALB123456890" \ --zonal-autoshift-status="DISABLED" ``` ``` { "resourceIdentifier": "arn:aws:elasticloadbalancing:us-west-2:111122223333:ExampleALB123456890", "zonalAutoshiftStatus": "DISABLED" } ``` Then, delete the practice run configuration, using a command like the following: ``` aws arc-zonal-shift delete-practice-run-configuration \ --resource-identifier="arn:aws:elasticloadbalancing:Region:111122223333:ExampleALB123456890" ``` ``` { "arn": "arn:aws:elasticloadbalancing:us-west-2:111122223333:ExampleALB123456890", "name": "TestResource", "zonalAutoshiftStatus": "DISABLED" } ``` # Enabling and working with zonal autoshift This section provides procedures for working with zonal autoshifts in Amazon Application Recovery Controller (ARC). After you enable zonal autoshift, you can make changes to practice run configurations, start an on-demand practice run, cancel an in-progress shift, including practice runs, or enable autoshift observer notifications. ## Enabling or disabling zonal autoshift The steps here explain how to enable or disable zonal autoshift on the Amazon Application Recovery Controller (ARC) console. To work with zonal autoshift programmatically, see the [ Zonal Shift and Zonal Autoshift API Reference Guide](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/Welcome.html). When zonal autoshift is enabled, you authorize AWS to shift away application resource traffic from an Availability Zone during events, on your behalf, to help reduce your time to recovery. ## To enable or disable zonal autoshift 1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/zonalshift/home#/autoshift](https://console.aws.amazon.com/route53recovery/zonalshift/home#/autoshift). 1. Under **Resource zonal autoshift configurations**, choose a resource. 1. In the **Actions** menu, choose **Enable zonal autoshift**, then follow the steps to complete the update. If the resource doesn't have a practice run configuration, **Enable zonal autoshift** is not available. To configure a practice run configuration and enable zonal autoshift, choose ** Configure zonal autoshift**. **Topics** + [Enabling or disabling zonal autoshift](#arc-zonal-autoshift.configure) + [Configuring, editing, or deleting a practice run configuration](arc-zonal-autoshift.edit-delete-practice-run.md) + [Canceling a zonal autoshift](arc-zonal-autoshift.canceling-an-autoshift.md) + [Starting a practice run zonal shift](arc-zonal-autoshift.start-practice-run.md) + [Canceling a practice run zonal shift](arc-zonal-autoshift.cancel-practice-run.md) + [Enabling or disabling autoshift observer notification](arc-zonal-autoshift.enable-autoshift-observer.md) # Configuring, editing, or deleting a practice run configuration The steps in this section explain how to edit or delete a practice run configuration on the Amazon Application Recovery Controller (ARC) console. To work with zonal autoshift programmatically, including changes to practice run configurations, see the [Zonal Shift and Zonal Autoshift API Reference Guide](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/Welcome.html). If you delete a practice run configuration in the console, zonal autoshift is disabled. Before you can delete a practice run configuration with an API operation, you must disable zonal autoshift. You can configure a practice run without enabling zonal autoshift. However, for zonal autoshift to be enabled for a resource, you are required to have a practice run configured for the resource. # To configure a practice run 1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/zonalshift/home#/autoshift](https://console.aws.amazon.com/route53recovery/zonalshift/home#/autoshift). 1. Choose **Configure zonal autoshift**. 1. Choose a resource to configure for zonal autoshift. 1. Choose to disable zonal autoshift if you don't want AWS to start an autoshift for a resource when there's an AWS event. You can continue with the wizard to configure a practice run configuration without enabling autoshifts, if you choose. 1. Choose options for practice runs for the resource. For alarms, you can do the following: + (Required) Specify at least one outcome alarm to monitor practice runs for this resource. + (Optional) Specify one or more blocking alarms for practice runs for this resource. For more information, see the **Alarms that you specify for practice runs** section in [Best practices when you configure zonal autoshift](arc-zonal-autoshift.considerations.md). 1. Optionally, specify blocked windows or allowed windows, to block ARC from starting practice runs or allow ARC to start practice runs for this resource. All dates and times are in UTC. 1. Select the check box to confirm that you have read the acknowledgement note. 1. Choose **Create**. # To edit a practice run configuration 1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/zonalshift/home#/autoshift](https://console.aws.amazon.com/route53recovery/zonalshift/home#/autoshift). 1. Under **Resource zonal autoshift configurations**, choose a resource. 1. In the **Actions** menu, choose **Edit practice run configuration**. 1. Make changes to the practice run configuration, to do one or more of the following: + For alarms, you can do the following: + For blocking alarms, you can add one or more alarms or delete alarms. + For outcome alarms, you can add one or more alarms or delete alarms. At least one outcome alarm is required, so you can't delete all of the outcome alarms in a configuration. + For blocked windows and allowed windows, you can add new dates or days and times, or you can remove or update existing dates or days and times. All dates and times are in UTC. 1. Choose **Save**. # To delete a practice run configuration 1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/zonalshift/home#/autoshift](https://console.aws.amazon.com/route53recovery/zonalshift/home#/autoshift). 1. Under **Resource zonal autoshift configurations**, choose a resource. 1. In the **Actions** menu, choose **Delete practice run configuration**. 1. On the confirmation modal dialog, type `Delete`, and then choose **Delete**. Note that deleting a practice run configuration in the console also disables zonal autoshift for the resource. Zonal autoshift requires a practice run to be configured for the resource. # Canceling a zonal autoshift To stop an in-progress zonal autoshift for a resource, you must cancel the zonal autoshift. # To stop an in-progress zonal autoshift 1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/zonalshift/home#/](https://console.aws.amazon.com/route53recovery/zonalshift/home#/). 1. Select a zonal autoshift that you want to cancel, and then choose **Cancel zonal shift**. 1. On the confirmation modal dialog, choose **Confirm**. # Starting a practice run zonal shift The steps in this section explain how to start an on-demand practice run zonal shift on the ARC console. To work with zonal shift and zonal autoshift programmatically, see the [ Zonal Shift and Zonal Autoshift API Reference Guide](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/Welcome.html). You can start a practice run zonal shift after you configure zonal autoshift and create a practice run configuration. # To start a practice run zonal shift 1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/zonalshift/home#/](https://console.aws.amazon.com/route53recovery/zonalshift/home#/). 1. Under **Zonal autoshift resources**, browse to an individual resource that has zonal autoshift configured. 1. On the **Resource overview** page, choose **Start practice run**. 1. Select an Availability Zone, and then enter a comment for your practice run. The practice run will shift traffic away from the Availability Zone that you selected. 1. Choose **Start**. # Canceling a practice run zonal shift The steps in this section explain how to cancel a zonal shift on the ARC console. To work with zonal shift and zonal autoshift programmatically, see the [ Zonal Shift and Zonal Autoshift API Reference Guide](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/Welcome.html). You can cancel zonal shifts or practice runs that you initiate yourself. You can also cancel zonal shifts that AWS starts for a resource for a practice run for zonal autoshift. # To cancel a practice run zonal shift 1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/zonalshift/home#/](https://console.aws.amazon.com/route53recovery/zonalshift/home#/). 1. Select a practice run zonal shift that you want to cancel, and then choose **Cancel zonal shift** or **Cancel practice run**. 1. On the confirmation modal dialog, choose **Confirm**. # Enabling or disabling autoshift observer notification You can configure zonal autoshift to notify you, through Amazon EventBridge, whenever AWS starts an autoshift to shift traffic away from a potentially impaired Availability Zone. You must configure this option in each AWS Region that you want to receive notifications about. You do not have to configure any specific resources with zonal autoshift to enable these separate notifications. For more information, see [Using zonal autoshift with Amazon EventBridge](eventbridge-zonal-autoshift.md). The steps in this section explain how to enable autoshift observer notification by using the Amazon Application Recovery Controller (ARC) console. To work with zonal autoshift programmatically, see the [ Zonal Shift and Zonal Autoshift API Reference Guide](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/Welcome.html). # To enable or disable autoshift observer notification 1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/zonalshift/home#/](https://console.aws.amazon.com/route53recovery/zonalshift/home#/). 1. Under **Getting started**, choose **Enable autoshift observer notification**. 1. In the confirmation dialog box, choose **Enable observer notification**. # Testing zonal autoshift with AWS FIS You can use AWS Fault Injection Service to set up and run experiments that help you simulate real-world conditions, such as the [AZ Availability: Power Interruption scenario](https://docs.aws.amazon.com//fis/latest/userguide/az-availability-scenario.html), that will demonstrate what happens when AWS starts a zonal autoshift on your autoshift-enabled resources during a potentially widespread AZ impairment. The start `aws:arc:start-zonal-autoshift` recovery action allows you to demonstrate how AWS will automatically shifts traffic, for zonal autoshift enabled resources, away from a potentially impaired AZ and reroute them to healthy AZs in the same AWS Region during the execution of the AZ availability scenario. For example, you can use the AWS FIS scenario library to simulate an AZ impairment that was caused by a power interruption. In this experiment, five minutes after the AZ power interruption begins, the recovery action `aws:arc:start-zonal-autoshift` automatically shifts resource traffic away from the specified AZ. The traffic is shifted for the remaining 25 minutes of the power interruption, to demonstrate how autoshift would be triggered when there is potentially widespread AZ impairment. When the experiment completes, the traffic shift ends and traffic begins flowing to all AZs again. This process demonstrates a complete recovery from a power event that impacts an AZ. ## How experiments differ from zonal autoshift practice runs AWS FIS experiments differ from zonal autoshift practice runs in that, during practice runs, ARC shifts traffic for your resource away from one AZ as part of a normal process to ensure that your application can tolerate the loss of an AZ. However, during an AWS FIS experiment, AWS FIS demonstrates how an AZ impairment and an autoshift would be triggered for your autoshift-enabled resources on your behalf, and then cancels the autoshift when the impairment has been resolved. You cannot update an AWS FIS-initiated zonal shift while it is running. In addition, if you cancel a zonal shift outside of AWS FIS, the AWS FIS experiment ends. ## AWS FIS expiration-based safety mechanism AWS FIS manages the zonal shift using the [StartZonalShift](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_StartZonalShift.html), [UpdateZonalShift](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_UpdateZonalShift.html), and [CancelZonalShift](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_CancelZonalShift.html) API operations, with the `expiresIn` field for these requests set to 1 minute as a safety mechanism. This enables AWS FIS to quickly roll back the zonal shift if there are unexpected events, such as network outages or system issues. In the ARC console, the expiration time field will display AWS FIS-managed, and the actual expected expiration is determined by the duration specified in the zonal shift action. For more information on practice runs, see [How zonal autoshift and practice runs work](https://docs.aws.amazon.com//r53recovery/latest/dg/arc-zonal-autoshift.how-it-works.html) There can be no more than one applied zonal shift at a given time. That is, only one practice run zonal shift, customer-initiated zonal shift, autoshift, or AWS FIS experiment for the resource. When a second zonal shift is started, ARC follows a precedence to determine which zonal shift type is in effect for a resource. For more information on precedence for zonal shifts, see [Precedence for zonal shifts](arc-zonal-autoshift.how-it-works.precedence.md). For more information about AWS FIS recovery actions, refer to the [AWS FIS recovery action](https://docs.aws.amazon.com//fis/latest/userguide/fis-actions-reference.html#fis-actions-recovery.html) in the *AWS Fault Injection Service User Guide*. # Logging and monitoring for zonal autoshift in Amazon Application Recovery Controller (ARC) You can use AWS CloudTrail and Amazon EventBridge for monitoring zonal autoshift in Amazon Application Recovery Controller (ARC), to analyze patterns and help troubleshoot issues. **Topics** + [Logging zonal autoshift API calls using AWS CloudTrail](cloudtrail-zonal-autoshift.md) + [Using zonal autoshift with Amazon EventBridge](eventbridge-zonal-autoshift.md) # Logging zonal autoshift API calls using AWS CloudTrail Zonal autoshift for ARC 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 zonal shift as events. The calls captured include calls from the ARC console and code calls to the ARC API operations for zonal shift. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for zonal shift. 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 for zonal shift, 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). ## Zonal autoshift information in CloudTrail CloudTrail is enabled on your AWS account when you create the account. When activity occurs in ARC for zonal autoshift, 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 zonal autoshift in 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 [Routing Control API Reference Guide for Amazon Application Recovery Controller](https://docs.aws.amazon.com/routing-control/latest/APIReference/). For example, calls to the `StartZonalShift` and `ListManagedResources` 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 ARC events in event history CloudTrail lets you view recent events in **Event history**. For more information, see [Working with CloudTrail Event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) in the *AWS CloudTrail User Guide*. ## Understanding zonal autoshift 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 `ListManagedResources` action for zonal autoshift. ``` { "eventVersion": "1.08", "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" }, "webIdFederationData": {}, "attributes": { "creationDate": "2022-11-14T16:01:51Z", "mfaAuthenticated": "false" } } }, "eventTime": "2022-11-14T16:14:41Z", "eventSource": "arc-zonal-shift.amazonaws.com", "eventName": "ListManagedResources", "awsRegion": "us-west-2", "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": null, "responseElements": null, "requestID": "VGXG4ZUE7UZTVCMTJGIAF_EXAMPLE", "eventID": "4b5c42df-1174-46c8-be99-d67_EXAMPLE", "readOnly": true, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111122223333" "eventCategory": "Management" } } ``` # Using zonal autoshift with Amazon EventBridge Using Amazon EventBridge, you can set up event-driven rules that monitor your zonal autoshift resources and 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 when a practice run starts for zonal autoshift. You can create rules in Amazon EventBridge to act on zonal autoshift. An event for zonal autoshift specifies status information about practice runs or autoshifts, for example, when a practice run is started. You can configure zonal autoshift to notify you about zonal autoshift events for resources that you enable for the service. You can also choose, in addition to or instead of other notifications, to enable autoshift observer notification, which provides a notification event whenever AWS starts an autoshift for a potentially impaired Availability Zone. Autoshift observer notification is separate from notifications that you receive when the traffic for resources that you have enabled for zonal autoshift is shifted away from an Availability Zone. You don't need to configure any resources with zonal autoshift to enable autoshift observer notification. For more information, see [Enabling and working with zonal autoshift](arc-zonal-autoshift.start-cancel.md). To capture specific zonal autoshift 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 zonal autoshift resource with EventBridge With EventBridge, you can create rules that define actions to take when ARC emits events for its resources. For example, you can create a rule that sends an email message when a practice run starts for zonal autoshift. To type or copy and paste an event pattern into the EventBridge console, select to the option to use **Enter my own** option in the console. To help you determine event patterns that might be useful for you, this topic includes examples of both [zonal autoshift event-matching patterns ](#ZAEventBridgePatterns) and [zonal autoshift events](#ZAEventBridgeEventSamples) that you can use. **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. Choose the AWS Region that you want to create the rule in, that is the Region that you're interested in watching 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. ## Example zonal autoshift event 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 zonal autoshift actions and resources. When you create event patterns for zonal autoshift events, you can specify any of the following for the `detail-type`: + `Autoshift In Progress` + `Autoshift Completed` + `Practice Run Started` + `Practice Run Succeeded` + `Practice Run Interrupted` + `Practice Run Failed` + `FIS Experiment Autoshift In Progress` + `FIS Experiment Autoshift Completed` + `FIS Experiment Autoshift Canceled` + `Manual Shift Started` + `Manual Shift Updated` + `Manual Shift Canceled` When a practice run is interrupted, for more information about what caused the interruption, see the `additionalFailureInfo` field. You can choose to monitor all AWS autoshifts by enabling *autoshift observer notifications*. After you enable autoshift observer notification, to receive the notifications, choose to be notified for the zonal autoshift detail type `Autoshift In Progress`. To see the steps for enabling autoshift observer notification, see [Enabling and working with zonal autoshift](arc-zonal-autoshift.start-cancel.md). For examples, see the [Example zonal autoshift events](#ZAEventBridgeEventSamples) section. + *Select all events from zonal autoshift where an autoshift has started.* Note the following: + If you have autoshift observer notification enabled, ARC returns all autoshift events. + If you do not have autoshift observer notification enabled, ARC returns autoshift events only when a resource that you have configured for zonal autoshift is included in an autoshift. ``` { "source": [ "aws.arc-zonal-shift" ], "detail-type": [ "Autoshift In Progress" ] } ``` + *Select all events from zonal autoshift where a practice run has started*. ``` { "source": [ "aws.arc-zonal-shift" ], "detail-type": [ "Practice Run Started" ] } ``` + *Select all events from zonal autoshift where a practice run has failed*. ``` { "source": [ "aws.arc-zonal-shift" ], "detail-type": [ "Practice Run Failed" ] } ``` ## Example zonal autoshift events This section includes example events for *zonal autoshift* actions. The following is an example event for the `Autoshift In Progress` action, when 1) autoshift observer notification is *enabled* and 2) you have not configured a resource with zonal autoshift that is included in an autoshift: ``` { "version": "0", "id": "05d4d2d5-9c76-bfea-72d2-d4614802adb4", "detail-type": "Autoshift In Progress", "source": "aws.arc-zonal-shift", "account": "111122223333", "time": "2023-11-16T23:38:14Z", "region": "us-east-1", "resources": [], "detail": { "version": "0.0.1", "data": "", "metadata": { "awayFrom": "use1-az2", "notes":"AWS has started an autoshift for an impaired Availability Zone. This notification is separate from autoshift notifications for resources, if any, that you have configured for zonal autoshift. For details, see the Developer Guide." } } } ``` The following is an example event for the `Autoshift In Progress` action, when 1) autoshift observer notification is *disabled* and 2) you have configured a resource with zonal autoshift that is included in an autoshift: ``` { "version": "0", "id": "05d4d2d5-9c76-bfea-72d2-d4614802adb4", "detail-type": "Autoshift In Progress", "source": "aws.arc-zonal-shift", "account": "111122223333", "time": "2023-11-16T23:38:14Z", "region": "us-east-1", "resources": [ "TEST-EXAMPLE-2023-11-16-23-28-11-5" ], "detail": { "version": "0.0.1", "data": "", "metadata": { "awayFrom": "use1-az2", "notes":"" } } } ``` The following is an example event for the `Practice Run Interrupted` action: ``` { "version": "0", "id": "05d4d2d5-9c76-bfea-72d2-d4614802adb4", "detail-type": "Practice Run Interrupted", "source": "aws.arc-zonal-shift", "account": "111122223333", "time": "2023-11-16T23:38:14Z", "region": "us-east-1", "resources": [ "TEST-EXAMPLE-2023-11-16-23-28-11-5" ], "detail": { "version": "0.0.1", "data": { "additionalFailureInfo": "Practice run interrupted. The blocking alarm entered ALARM state." }, "metadata": { "awayFrom": "use1-az2" } } } ``` The following is an example event for the `FIS Experiment Autoshift In Progress` action: ``` { "version": "0", "id": "05d4d2d5-9c76-bfea-72d2-d4614802adb4", "detail-type": "FIS Experiment Autoshift In Progress", "source": "aws.arc-zonal-shift", "account": "111122223333", "time": "2023-11-16T23:38:14Z", "region": "us-east-1", "resources": [ "TEST-EXAMPLE-2023-11-16-23-28-11-5" ], "detail": { "version": "0.0.1", "data": "", "metadata": { "awayFrom": "use1-az2", "notes":"" } } } ``` The following is an example event for the `Manual Shift Started` action. It is emitted when the `StartZonalShift` API is called on a resource: ``` { "version": "0", "id": "05d4d2d5-9c76-bfea-72d2-d4614802adb4", "detail-type": "Manual Shift Started", "source": "aws.arc-zonal-shift", "account": "111122223333", "time": "2023-11-16T23:38:14Z", "region": "us-east-1", "resources": [ "TEST-EXAMPLE-2023-11-16-23-28-11-5" ], "detail": { "version": "0.0.1", "data": "", "metadata": { "awayFrom": "use1-az2", "notes":"" } } } ``` ## 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 ARC, see the sections earlier in this topic. 1. On the **Select target** page, choose **CloudWatch** as your target. 1. Choose a CloudWatch log group from the drop-down menu. # Identity and Access Management for zonal autoshift 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 zonal autoshift works with IAM](security_iam_service-with-iam-zonalautoshift.md) + [Identity-based policy examples](security_iam_id-based-policy-examples-zonalautoshift.md) + [Service-linked role](using-service-linked-roles-zonal-autoshift.md) + [AWS managed policies](security-iam-awsmanpol-zonal-autoshift.md) # How zonal autoshift in ARC works with IAM Before you use IAM to manage access to zonal autoshift in Amazon Application Recovery Controller (ARC), learn what IAM features are available to use with zonal autoshift. **IAM features that you can use with zonal autoshift in ARC** | IAM feature | Zonal autoshift support | | --- | --- | | [Identity-based policies](#security_iam_service-with-iam-zonalautoshift-id-based-policies) | Yes | | [Resource-based policies](#security_iam_service-with-iam-zonalautoshift-resource-based-policies) | No | | [Policy actions](#security_iam_service-with-iam-zonalautoshift-id-based-policies-actions) | Yes | | [Policy resources](#security_iam_service-with-iam-zonalautoshift-id-based-policies-resources) | Yes | | [Policy condition keys](#security_iam_service-with-iam-zonalautoshift-id-based-policies-conditionkeys) | Yes | | [ACLs](#security_iam_service-with-iam-zonalautoshift-acls) | No | | [ABAC (tags in policies)](#security_iam_service-with-iam-zonalautoshift-tags) | Partial | | [Temporary credentials](#security_iam_service-with-iam-zonalautoshift-roles-tempcreds) | Yes | | [Principal permissions](#security_iam_service-with-iam-zonalautoshift-principal-permissions) | Yes | | [Service roles](#security_iam_service-with-iam-zonalautoshift-roles-service) | No | | [Service-linked roles](#security_iam_service-with-iam-zonalautoshift-roles-service-linked) | Yes | 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 ARC **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 ARC **Supports resource-based policies:** No 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 ARC **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. To see a list of ARC actions for zonal autoshift, see [ Actions defined by Amazon Route 53 Zonal Shift](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53recoverycontrols.html#amazonroute53applicationrecoverycontroller-zonalshift-actions-as-permissions) in the *Service Authorization Reference*. Policy actions in ARC for zonal autoshift use the following prefixes before the action: ``` arc-zonal-shift ``` To specify multiple actions in a single statement, separate them with commas. For example, the following: ``` "Action": [ "arc-zonal-shift:action1", "arc-zonal-shift: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-zonal-shift:Describe*" ``` To view examples of ARC identity-based policies for zonal autoshift, see [Identity-based policy examples for zonal autoshift in ARC](security_iam_id-based-policy-examples-zonalautoshift.md). ## Policy resources for zonal autoshift in ARC **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 see a list of resource types and their ARNs, and the actions that you can specify with the ARN of each resource, see the following topic in the *Service Authorization Reference*: + [ Actions defined by Amazon Route 53 - Zonal Shift](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53recoverycontrols.html#amazonroute53applicationrecoverycontroller-zonalshift-actions-as-permissions) To see the actions and resources that you can use with a condition key, see the following topic in the *Service Authorization Reference*: + [ Condition keys defined by Amazon Route 53 - Zonal Shift](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53recoverycontrols.html#amazonroute53applicationrecoverycontroller-zonalshift-policy-keys) To view examples of ARC identity-based policies for zonal autoshift, see [Identity-based policy examples for zonal autoshift in ARC](security_iam_id-based-policy-examples-zonalautoshift.md). ## Policy condition keys for zonal autoshift in ARC **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 see a list of ARC condition keys for zonal autoshift, see the following topics in the *Service Authorization Reference*: + [ Condition keys for Amazon Route 53 Zonal Shift](https://docs.aws.amazon.com//service-authorization/latest/reference/list_amazonroute53applicationrecoverycontroller-zonalshift.html#amazonroute53applicationrecoverycontroller-zonalshift-policy-keys) To see the actions and resources that you can use with a condition key, see the following topics in the *Service Authorization Reference*: + [ Actions defined by Amazon Route 53 Zonal Shift](https://docs.aws.amazon.com//service-authorization/latest/reference/list_amazonroute53applicationrecoverycontroller-zonalshift.html#amazonroute53applicationrecoverycontroller-zonalshift-actions-as-permissions) To view examples of ARC identity-based policies for zonal autoshift, see [Identity-based policy examples for zonal autoshift in ARC](security_iam_id-based-policy-examples-zonalautoshift.md). ## Access control lists (ACLs) in ARC **Supports ACLs:** No 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 ARC **Supports ABAC (tags in policies):** Partial 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*. Zonal autoshift in ARC includes the following partial support for ABAC: + Zonal autoshift supports ABAC for managed resources that are registered in ARC for zonal shift. For more information about ABAC for Network Load Balancer and Application Load Balancer managed resources, see [ ABAC with Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/security_iam_service-with-iam.html#security_iam_service-with-iam-tags) in the Elastic Load Balancing User Guide. ## Using temporary credentials with ARC **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 ARC **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. To see whether an action requires additional dependent actions in a policy, see the following topic in the *Service Authorization Reference*: + [ Amazon Route 53 Zonal Shift](https://docs.aws.amazon.com//service-authorization/latest/reference/list_amazonroute53applicationrecoverycontroller-zonalshift.html) ## Service roles for ARC **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 ARC **Supports service-linked roles:** Yes 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 ARC service-linked roles, see [Using the service-linked role for zonal autoshift in ARC](using-service-linked-roles-zonal-autoshift.md). 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 zonal autoshift 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) + [Example: Zonal autoshift console access](#security_iam_id-based-policy-examples-console-zonalautoshift) + [Examples: ARC API actions](#security_iam_id-based-policy-examples-api-zonalautoshift) ## 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*. ## Example: Zonal autoshift console access To access the Amazon Application Recovery Controller (ARC) console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the ARC resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy. You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that they're trying to perform. To perform some tasks, users must have permission to create the service-linked role that is associated with zonal autoshift in ARC. To learn more, see [Using the service-linked role for zonal autoshift in ARC](using-service-linked-roles-zonal-autoshift.md). To give users full access to use zonal autoshift in the AWS Management Console, attach a policy like the following to the user: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "arc-zonal-shift:ListManagedResources", "arc-zonal-shift:GetManagedResource", "arc-zonal-shift:ListZonalShifts", "arc-zonal-shift:StartZonalShift", "arc-zonal-shift:UpdateZonalShift", "arc-zonal-shift:CancelZonalShift", "arc-zonal-shift:CreatePracticeRunConfiguration", "arc-zonal-shift:DeletePracticeRunConfiguration", "arc-zonal-shift:ListAutoshifts", "arc-zonal-shift:UpdatePracticeRunConfiguration", "arc-zonal-shift:UpdateZonalAutoshiftConfiguration" ], "Resource": "*" }, { "Effect": "Allow", "Action": "ec2:DescribeAvailabilityZones", "Resource": "*" }, { "Effect": "Allow", "Action": "cloudwatch:DescribeAlarms", "Resource": "*" } ] } ``` ------ ## Examples: ARC API actions You can use a policy to ensure that a user can use ARC API actions for zonal autoshift to configure zonal autoshift so that AWS shifts away application resource traffic from an Availability Zone, on your behalf, to healthy AZs in the AWS Region, to help reduce your time to recovery during events. To provide these permissions, attach a policy that corresponds to the API operations that the user needs to work with, as described below. To perform some tasks, users must have permissions for the service-linked role that is associated with ARC. Permissions needed to create the service-linked role are included in the following example policy. To learn more, see [Using the service-linked role for zonal autoshift in ARC](using-service-linked-roles-zonal-autoshift.md). To work with API operations for zonal autoshift, attach a policy such as the following to the user: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "arc-zonal-shift:ListManagedResources", "arc-zonal-shift:GetManagedResource", "arc-zonal-shift:ListZonalShifts", "arc-zonal-shift:StartZonalShift", "arc-zonal-shift:UpdateZonalShift", "arc-zonal-shift:CancelZonalShift", "arc-zonal-shift:CreatePracticeRunConfiguration", "arc-zonal-shift:DeletePracticeRunConfiguration", "arc-zonal-shift:ListAutoshifts", "arc-zonal-shift:UpdatePracticeRunConfiguration", "arc-zonal-shift:UpdateZonalAutoshiftConfiguration" ], "Resource": "*" }, { "Effect" : "Allow", "Action" : [ "cloudwatch:DescribeAlarms", "health:DescribeEvents" ], "Resource" : "*" }, { "Effect" : "Allow", "Action" : [ "arc-zonal-shift:CancelZonalShift", "arc-zonal-shift:GetManagedResource", "arc-zonal-shift:StartZonalShift", "arc-zonal-shift:UpdateZonalShift" ], "Resource" : "*" } ] } ``` ------ # Using the service-linked role for zonal autoshift in ARC Zonal autoshift in Amazon Application Recovery Controller uses a AWS Identity and Access Management (IAM)[ service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to a service— in this case, ARC. The service-linked role is predefined by ARC and includes all the permissions that the service requires to call other AWS services on your behalf for specific purposes. A service-linked role makes setting up ARC easier because you don’t have to manually add the necessary permissions. ARC defines the permissions for the service-linked role, and unless defined otherwise, only ARC can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity. You can delete a service-linked role only after first deleting its related resources. This protects your ARC zonal autoshift resources because you can't inadvertently remove permission to access the resources. For information about other services that support 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) and look for the services that have **Yes **in the **Service-linked role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. ## Service-linked role permissions for AWSServiceRoleForZonalAutoshiftPracticeRun ARC uses the service-linked role named **AWSServiceRoleForZonalAutoshiftPracticeRun** to do the following: + Monitor customer-provided Amazon CloudWatch alarms and customer Health Dashboard events for practice runs + Manage practice runs (practice zonal shifts) This section describes the permissions for the service-linked role, and information about creating, editing, and deleting the role. ### Service-linked role permissions for AWSServiceRoleForZonalAutoshiftPracticeRun This service-linked role uses the managed policy `AWSZonalAutoshiftPracticeRunSLRPolicy`. The **AWSServiceRoleForZonalAutoshiftPracticeRun** service-linked role trusts the following service to assume the role: + `practice-run.arc-zonal-shift.amazonaws.com` To view the permissions for this policy, see [AWSZonalAutoshiftPracticeRunSLRPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSZonalAutoshiftPracticeRunSLRPolicy.html) in the *AWS Managed Policy Reference*. You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*. ### Creating the **AWSServiceRoleForZonalAutoshiftPracticeRun** service-linked role for ARC You don't need to manually create the **AWSServiceRoleForZonalAutoshiftPracticeRun** service-linked role. When you create the first practice run configuration in the AWS Management Console, the AWS CLI, or an AWS SDK, ARC creates the service-linked role for you. If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create the first practice run configuration, ARC creates the service-linked role for you again. ### Editing the **AWSServiceRoleForZonalAutoshiftPracticeRun** service-linked role for ARC ARC does not allow you to edit the **AWSServiceRoleForZonalAutoshiftPracticeRun** service-linked role. After you create the service-linked role, you cannot change the name of the role because other entities might reference it. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*. ### Deleting the **AWSServiceRoleForZonalAutoshiftPracticeRun** service-linked role for ARC If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up the resources for a service-linked role before you can manually delete it. After you have disabled autoshift, then you can delete the **AWSServiceRoleForZonalAutoshiftPracticeRun** service-linked role. For more information about the autoshift capability, see [Zonal shift in ARC](arc-zonal-shift.md). **Note** If the ARC service is using the role when you try to delete the resources, then the service role deletion might fail. If that happens, wait for a few minutes and try the again to delete the role. **To manually delete the service-linked role using IAM** Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForZonalAutoshiftPracticeRun service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*. ## Updates to the ARC service-linked role for zonal autoshift For updates to the AWS managed policies for the ARC service-linked roles, see the [AWS managed policies updates table](security-iam-awsmanpol.md#security-iam-awsmanpol-arc-updates) for ARC. You can also subscribe to automatic RSS alerts on the ARC [Document history page](doc-history.md). # AWS managed policies for zonal autoshift in ARC An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. ## AWS managed policy: AWSZonalAutoshiftPracticeRunSLRPolicy You can't attach `AWSZonalAutoshiftPracticeRunSLRPolicy` to your IAM entities. This policy is attached to a service-linked role that allows Amazon Application Recovery Controller (ARC) to do the following for zonal autoshift: + Monitor customer-provided Amazon CloudWatch alarms and customer Health Dashboard events for practice runs + Manage practice runs (practice zonal shifts) + Manage balanced capacity checks for practice runs and autoshifts For more information, see [Using the service-linked role for zonal autoshift in ARC](using-service-linked-roles-zonal-autoshift.md). ## Updates for AWS managed policies for zonal autoshift For details about updates to AWS managed policies for zonal autoshift in ARC since this service began tracking these changes, see [Updates to AWS managed policies for Amazon Application Recovery Controller (ARC)](security-iam-awsmanpol.md#security-iam-awsmanpol-arc-updates). For automatic alerts about changes to this page, subscribe to the RSS feed on the ARC [Document history page](doc-history.md). # Quotas for zonal autoshift Zonal autoshift in Amazon Application Recovery Controller (ARC) is subject to the following quotas. | Entity | Quota | | --- | --- | | Number of outcome alarms per practice run configuration | 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 blocking alarms per practice run configuration | 10 You can [ request a quota increase](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/arc-region-switch/quotas). |