# Zonal shift in ARC
Amazon Application Recovery Controller (ARC) *zonal shift* allows you to shift traffic for a supported resource away from an impaired Availability Zone (AZ) in an AWS Region to healthy AZs in the same Region. Shifting your resource's traffic away from an impaired AZ reduces the duration and severity of impact caused by power outages, or hardware or software issues in an AZ, and helps to mitigate issues and quickly recover your application. You might choose to shift traffic, for example, because a bad deployment is causing latency issues, or because the Availability Zone is impaired.
You must opt-in resources in order to use zonal shift. For more information, refer to [Supported resources](arc-zonal-shift.resource-types.md).
Before you start a zonal shift, you must prescale your application and ensure that you have sufficient capacity to shift traffic away from an Availability Zone. After prescaling, you can choose the Availability Zone to shift away from and the resource to shift traffic away for, and then start the zonal shift. You can cancel the shift at any time to have traffic begin returning to the original Availability Zone. For more information, see [Best practices for zonal shifts in ARC](route53-arc-best-practices.zonal-shifts.md)
All zonal shifts are temporary mitigations. You set an initial expiration when you start a zonal shift, from one minute up to three days (72 hours), which you can extend, if you need to continue the traffic shift.
In specific scenarios, zonal shift does not shift traffic away from the AZ. For more information, see [Supported resources](arc-zonal-shift.resource-types.md).
# How a zonal shift works
When you start a zonal shift for a supported resource, traffic for the resource is moved away from the Availability Zone (AZ) that you've specified. ARC's supported resources provide integrations that mark the specified AZ as unhealthy, which results in a traffic shifting away from the impaired AZ.
**Traffic begins to shift** - When you start a zonal shift in ARC, you might not see traffic move out of the Availability Zone immediately. It can take a short time for existing, in-progress connections in the Availability Zone to complete, depending on client behavior and connection reuse. DNS settings and other factors including existing connections can complete in just a few minutes, but they may take longer. For more information, see [Ensuring that traffic shifts finish quickly](route53-arc-best-practices.zonal-shifts.md#arc-zonal-shift.existing-connections).
**Traffic shift ends** - When a zonal shift expires or you cancel it, ARC takes steps to stop shifting traffic and reverses the process for starting a traffic shift. Now, the recovered AZ is recognized as available for the resource and traffic resumes flowing to the AZ.
You must set all zonal shifts to expire when you start the shifts. You can initially set a zonal shift to expire in a maximum of three days (72 hours). However, you can update a zonal shift to set a new expiration at any time. You can also cancel a zonal shift before it expires, if you're ready to restore traffic to the Availability Zone.
**When traffic does not shift away** - In specific scenarios, a zonal shift does not shift traffic from the Availability Zone. For example, say you start a zonal shift for a load balancer when the load balancer target groups in the AZs don't have any instances, or if all of the instances are unhealthy. In this scenario, the load balancer is in a fail open state and starting a zonal shift does not shift away traffic.
Before you start a zonal shift for a resource, make sure that all the conditions for a successful zonal shift are met. AWS resources handle zonal shifts differently. For more information about zonal shift support, see [Supported resources](arc-zonal-shift.resource-types.md).
# AWS Region availability for zonal shift
For detailed information about Regional support and service endpoints for Amazon Application Recovery Controller (ARC), see [Amazon Application Recovery Controller (ARC) endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/r53arc.html) in the *Amazon Web Services General Reference*.
Zonal shift and zonal autoshift are currently available in the AWS Regions listed here. Zonal shift and zonal autoshift also available in the China Regions, that is, China (Beijing) Region and China (Ningxia) Region. Resources that use Amazon Application Recovery Controller (ARC) may have additional considerations. For more information, refer to [Supported resources](arc-zonal-shift.resource-types.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/r53recovery/latest/dg/introduction-regions-zonal.html)
# Zonal shift components
The following diagram illustrates an example of a zonal shift shifting traffic away from an Availability Zone in an AWS Region. Checks that are built into zonal shift prevent you from starting another zonal shift for a resource when it already has an active shift.
![\[Diagram of a zonal shift with three Availability Zones\]](http://docs.aws.amazon.com/r53recovery/latest/dg/images/ZonalShiftDiagramRev2023.png)
The following are components of the zonal shift capability in ARC.
**Zonal shift**
You start a zonal shift for a managed resource in your AWS account to temporarily move traffic away from an Availability Zone in an AWS Region, to healthy AZs in the Region, to quickly recover from an issue in one AZ. For more information on supported resources for zonal shift, refer to [Supported resources](arc-zonal-shift.resource-types.md).
**Built-in safety checks**
Checks that are 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, 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 [Zonal autoshift in ARC](arc-zonal-autoshift.md) and [Outcomes for practice runs](arc-zonal-autoshift.how-it-works.precedence.md#ZAShiftPrecedence).
**Resource identifier**
The identifier for a resource to include in a zonal shift. The identifier is the Amazon Resource Name (ARN) for the resource.
For a zonal shift, you can only choose resources in your account for an AWS service that is supported by ARC. For more information on supported resources for zonal shift, refer to [Supported resources](arc-zonal-shift.resource-types.md).
**Managed resource**
Some AWS resources must manually opt-in to zonal shift, and others are automatically enabled. For more information on supported resources for zonal shift, refer to [Supported resources](arc-zonal-shift.resource-types.md).
**Resource name**
The name of a resource in ARC that you can specify for a zonal shift.
**Status (zonal shift status)**
A status for a zonal shift. The `Status` for a zonal shift can have one of the following values:
+ **ACTIVE**: The zonal shift is started and active.
+ **EXPIRED**: The zonal shift has expired (the expiry time was exceeded).
+ **CANCELED**: The zonal shift was canceled.
**Applied status**
An applied status indicates whether a shift is in effect for a resource. The shift that has the status `APPLIED` determines the Availability Zone where application traffic has been shifted away for a resource, and when that shift ends.
**Shift type**
Defines the zonal shift type. The `shiftType` can have the following values:
+ **ZONAL\$1SHIFT**
+ **ZONAL\$1AUTOSHIFT**
+ **PRACTICE\$1RUN**
+ **FIS\$1EXPERIMENT**
**Expiry time (expiration time)**
The expiry time (expiration time) for a zonal shift. Zonal shifts are temporary. For a zonal shift, you can initially set a zonal shift to be active for up to three days (72 hours).
When you start a zonal shift, you specify how long you want it to be active, which ARC converts to an expiry time (expiration time). You can cancel a zonal shift, for example, if you're ready to restore traffic to the Availability Zone. Or you can extend a customer-initiated zonal shift by updating it to specify another length of time to expire in.
You can cancel zonal shift practice runs that are part of zonal autoshift.
# Data and control planes for zonal shift
As you plan for failover and disaster recovery, consider how resilient your failover mechanisms are. We recommend that you make sure that the mechanisms that you depend on during failover are highly available, so that you can use them when you need them in a disaster scenario. Typically, you should use data plane functions for your mechanisms whenever you can, for the greatest reliability and fault tolerance. With that in mind, it's important to understand how the functionality of a service is divided between control planes and data planes, and when you can rely on an expectation of extreme reliability with a service's data plane.
As with most AWS services, the functionality for the zonal shift capability is supported by control planes and data planes. While both of these are built to be reliable, a control plane is optimized for data consistency, while a data plane is optimized for availability. A data plane is designed for resilience so that it can maintain availability even during disruptive events, when a control plane might become unavailable.
In general, a *control plane* enables you to do basic management functions, such as create, update, and delete resources in the service. A *data plane* provides a service's core functionality.
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 shift in ARC
For zonal shift, you can start a zonal shift for supported resources, to recover your application from an issue in an Availability Zone. There is no additional charge for using zonal shift.
For detailed pricing information for ARC and pricing examples, see [ARC Pricing](https://aws.amazon.com/application-recovery-controller/pricing/).
# Best practices for zonal shifts in ARC
We recommend the following best practices for using zonal shifts for multi-AZ recovery in ARC.
**Topics**
+ [Capacity planning and pre-scaling](#ZSBestPracticeCapacityPrescaling)
+ [Limit the time that clients stay connected to your endpoints](#arc-zonal-shift.existing-connections)
+ [Test starting zonal shifts, in advance](#ZSBestPracticeTestShifting)
+ [Ensure that all Availability Zones are healthy and taking traffic](#ZSBestPracticeEnsureHealthyAZs)
+ [Use data plane API operations for disaster recovery](#ZSBestPracticeUseDataPlane)
+ [Move traffic with a zonal shift only temporarily](#ZSBestPracticeMoveTrafficTemp)
**Capacity planning and pre-scaling**
Ensure that you have planned for, and either pre-scaled or can auto-scale, sufficient capacity to accommodate the extra load imposed on Availability Zones when you start a zonal shift. With a recovery-oriented architecture, a typical recommendation is to pre-scale compute capacity to include enough headroom to serve your peak traffic when one of your (typically) three replicas is offline.
When you start a zonal shift for a supported resource and traffic is shifted away from an AZ, the capacity that your application was using to service requests is removed. You must ensure that you have planned for a shift of traffic away from an AZ and can continue to service requests in the remaining AZs.
**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.
**Test starting zonal shifts, in advance**
Regularly test moving traffic away from Availability Zones for your application by starting zonal shifts. Plan for and execute starting zonal shifts, preferably in both test and production environments, as part of regular failover testing for recovering your applications in the event of a disaster. Regular testing is a critical part of ensuring that you're ready for and have the confidence to mitigate issues when an operational event occurs.
**Ensure that all Availability Zones are healthy and taking traffic**
Zonal shifts work by marking a resource, that is, an application replica, as unhealthy in an Availability Zone. This means that it's critical to ensure that the resources in your applications are generally healthy and actively taking traffic in the Availability Zones in a Region. We recommend that you have dashboards to track this, including, for example, Elastic Load Balancing metrics for unhealthy targets and bytesProcessed per Availability Zone.
Consider monitoring the health of your resources from a second, adjacent Region. Advantages of this approach are that it can be more representative of your end users' experience, and it also reduces the risk of both your application and your monitoring being impacted by the same disaster at the same time.
**Use data plane API operations for disaster recovery**
For starting a zonal shift when you need to recover an application quickly, with few dependencies, we recommend using the AWS Command Line Interface or API with zonal shift actions, with pre-stored credentials, if possible. You can also start zonal shifts in the AWS Management Console, for ease of use. But when fast, reliable recovery is critical, data plane operations are a better choice. For more information, see [ Zonal Shift API Reference Guide](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/Welcome.html).
**Move traffic with a zonal shift only temporarily**
A zonal shift moves traffic away from an Availability Zone on a temporary basis, to mitigate an impairment. You should restore the resource for the application to service as soon as you've taken action to correct a problem. This ensures that your overall application is restored to its original fully redundant, resilient state.
# Zonal shift API operations
The following table lists ARC API operations that you can use using zonal shift, which moves traffic away from an Availability Zone for multi-AZ applications. The table also includes links to relevant documentation.
For examples of how to use common zonal shift API operations with the AWS Command Line Interface, see [Examples of using the AWS CLI with zonal shift](getting-started-cli-zonalshift.md).
| Action | Using the ARC console | Using the ARC API |
| --- | --- | --- |
| Start a zonal shift | See [Starting a zonal shift](arc-zonal-shift.start-cancel.md#arc-zonal-shift.start) | See [StartZonalShift](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_StartZonalShift.html) |
| Update a zonal shift | See [Updating or canceling a zonal shift](arc-zonal-shift.start-cancel.md#arc-zonal-shift.update-cancel) | See [UpdateZonalShift](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_UpdateZonalShift.html) |
| List zonal shifts | See [Zonal shift in ARC](arc-zonal-shift.md) | See [ListZonalShifts](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_ListZonalShifts.html) |
| List managed resources | 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 managed resource | See [Supported resources](arc-zonal-shift.resource-types.md) | See [GetManagedResource](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_GetManagedResource.html) |
| Cancel a zonal shift | See [Updating or canceling a zonal shift](arc-zonal-shift.start-cancel.md#arc-zonal-shift.update-cancel) | See [CancelZonalShift](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_CancelZonalShift.html) |
# Examples of using the AWS CLI with zonal shift
This section provides application examples of using zonal shift, using the AWS Command Line Interface to work with the zonal shift 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 shift using the CLI.
Zonal shift in ARC enables you to temporarily move traffic for supported resources away from an Availability Zone so that your application can continue to operate normally with other Availabilty Zones in an AWS Region.
All zonal shifts are temporary and must be set initially to expire within three days. However, you can update a zonal shift later to set a new expiration.
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). For a list of zonal shift API actions and links to more information, see [Zonal shift API operations](actions.zonalshift.md).
## Start zonal shift
You can start a zonal shift with the CLI by using the `start-zonal-shift` command.
```
aws arc-zonal-shift start-zonal-shift \
--resource-identifier arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/Testing/5a19403ecd42dc05 \
--away-from use1-az1 \
--expires-in 10m \
--comment "Shifting traffic away from use1-az1"
```
```
{
"awayFrom": "use1-az1",
"comment": "Shifting traffic away from use1-az1",
"expiryTime": "2024-12-17T21:37:26-08:00",
"resourceIdentifier": "arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/Testing/5a19403ecd42dc05",
"startTime": "2024-12-17T21:27:26-08:00",
"status": "ACTIVE",
"zonalShiftId": "9ac9ec1e-1df1-0755-3dc5-8cf573cd9c38"
}
```
## Get managed resource
You can get information about a managed resource with the CLI by using the `get-managed-resource` command.
```
aws arc-zonal-shift get-managed-resource \
--resource-identifier arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/Testing/5a19403ecd42dc05
```
```
{
"appliedWeights": {
"use1-az1": 0.0,
"use1-az2": 1.0,
"use1-az6": 1.0
},
"arn": "arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/Testing/5a19403ecd42dc05",
"autoshifts": [],
"name": "Testing",
"zonalAutoshiftStatus": "DISABLED",
"zonalShifts": [
{
"appliedStatus": "APPLIED",
"awayFrom": "use1-az1",
"comment": "Shifting traffic away from use1-az1",
"expiryTime": "2024-12-17T21:37:26-08:00",
"resourceIdentifier": "arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/Testing/5a19403ecd42dc05",
"startTime": "2024-12-17T21:27:26-08:00",
"zonalShiftId": "9ac9ec1e-1df1-0755-3dc5-8cf573cd9c38"
"shiftType": "MANUAL"
}
]
}
```
## List managed resources
You can list the managed resources in your account with the CLI by using the `list-managed-resources` command.
```
aws arc-zonal-shift list-managed-resources
```
```
{
"items": [
{
"appliedWeights": {
"use1-az1": 0.0,
"use1-az2": 1.0,
"use1-az6": 1.0
},
"arn": "arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/Testing/5a19403ecd42dc05",
"autoshifts": [],
"availabilityZones": [
"use1-az1",
"use1-az2",
"use1-az6"
],
"name": "Testing",
"practiceRunStatus": "DISABLED",
"zonalAutoshiftStatus": "DISABLED",
"zonalShifts": [
{
"appliedStatus": "APPLIED",
"awayFrom": "use1-az1",
"comment": "Shifting traffic away from use1-az1",
"expiryTime": "2024-12-17T21:37:26-08:00",
"resourceIdentifier": "arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/Testing/5a19403ecd42dc05",
"startTime": "2024-12-17T21:27:26-08:00",
"zonalShiftId": "9ac9ec1e-1df1-0755-3dc5-8cf573cd9c38"
}
]
}
]
}
```
## List zonal shifts
You can list the zonal shifts in your account with the CLI by using the `list-zonal-shifts` command.
```
aws arc-zonal-shift list-zonal-shifts
```
```
{
"items": [
{
"awayFrom": "use1-az1",
"comment": "Shifting traffic away from use1-az1",
"expiryTime": "2024-12-17T21:37:26-08:00",
"resourceIdentifier": "arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/Testing/5a19403ecd42dc05",
"startTime": "2024-12-17T21:27:26-08:00",
"status": "ACTIVE",
"zonalShiftId": "9ac9ec1e-1df1-0755-3dc5-8cf573cd9c38"
}
]
}
```
## Update zonal shift
You can update a zonal shift with the CLI by using the `update-zonal-shift` command.
```
aws arc-zonal-shift update-zonal-shift \
--zonal-shift-id 9ac9ec1e-1df1-0755-3dc5-8cf573cd9c38 \
--expires-in 1h \
--comment "Still shifting traffic away from use1-az1"
```
```
{
"awayFrom": "use1-az1",
"comment": "Still shifting traffic away from use1-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": "ACTIVE",
"zonalShiftId": "9ac9ec1e-1df1-0755-3dc5-8cf573cd9c38"
}
```
## Cancel zonal shift
You can cancel a zonal shift with the CLI by using the `cancel-zonal-shift` command.
```
aws arc-zonal-shift cancel-zonal-shift \
--zonal-shift-id 9ac9ec1e-1df1-0755-3dc5-8cf573cd9c38
```
```
{
"awayFrom": "use1-az1",
"comment": "Still shifting traffic away from use1-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"
}
```
# Supported resources
Amazon Application Recovery Controller (ARC) currently supports enabling the following resources for zonal shift and zonal autoshift:
+ [Amazon EC2 Auto Scaling groups](arc-zonal-shift.resource-types.ec2-auto-scaling-groups.md)
+ [Amazon Elastic Kubernetes Service](arc-zonal-shift.resource-types.eks.md)
+ [Application Load Balancers](arc-zonal-shift.resource-types.app-load-balancers.md) with cross-zone load balancing enabled or disabled
+ [Network Load Balancers](arc-zonal-shift.resource-types.network-load-balancers.md) with cross-zone load balancing enabled or disabled
For specific requirements for Network Load Balancers and Application Load Balancers, see the additional topics in this section.
Review the following conditions for working with zonal shifts, zonal autoshift, and resources in ARC:
+ A resource must be active and fully provisioned to shift traffic for it. Before you start a zonal shift for a resource, check to make sure that it's a managed resource in ARC. For example, view the list of managed resources in the AWS Management Console, or use the `get-managed-resource` operation with the resource's identifier.
+ To start a zonal shift with a resource, it must be deployed in the Availability Zone and AWS Region where you start the shift. Make sure that you start a zonal shift in the same Region that the AZ you want to shift away from is in, and that the resource that you're shifting traffic for is in the same AZ and Region as well.
+ Ensure that you have the correct IAM permissions to use zonal shift with a resource. For more information, see [IAM and permissions for zonal shift](security_iam_service-with-iam-zonal-shift.md).
+ When a Network Load Balancer or Application Load Balancer is in a fail open state, a zonal shift will have no effect. This is expected behavior because zonal shift cannot force an AZ to be unhealthy and then shift traffic to the other AZs in a Region when a load balancer is failing open. For more information, see [Using Route 53 DNS failover for your load balancer](https://docs.aws.amazon.com//elasticloadbalancing/latest/network/load-balancer-target-groups.html#r53-dns-failover) in the *Network Load Balancers User Guide* and [Using Route 53 DNS failover for your load balancer](https://docs.aws.amazon.com//elasticloadbalancing/latest/application/load-balancer-target-groups.html#r53-dns-failover) in the *Application Load Balancers User Guide*.
+ If multiple load balancers are forwarding traffic to the same targets, a zonal shift on a cross-zone enabled load balancer drops target capacity for all load balancers, even if their traffic is not shifted by a zonal shift.
# Amazon EC2 Auto Scaling groups
An Amazon EC2 Auto Scaling group contains a collection of Amazon EC2 instances that are treated as a logical grouping for the purposes of automatic scaling and management. An Auto Scaling group also lets you use Amazon EC2 Auto Scaling features such as health check replacements and scaling policies. Both maintaining the number of instances in an Auto Scaling group and automatic scaling are the core functionality of the Amazon EC2 Auto Scaling service.
## Using zonal shift for Auto Scaling groups
To enable zonal shift, use one of the following methods.
------
#### [ Console ]
**To enable zonal shift on a new group (console)**
1. Follow the instructions in [Create an Auto Scaling group using a launch template](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template) and complete each step in the procedure, up to step 10.
1. On the **Integrate with other services** page, for **ARC zonal shift**, select the checkbox to enable zonal shift.
1. For **Health check behavior**, choose Ignore unhealthy or Replace unhealthy. If set to `replace-unhealthy`, unhealthy instances will be replaced in the Availability Zone with the active zonal shift. If set to `ignore-unhealthy`, unhealthy instances will not be replaced in the Availability Zone with the active zonal shift.
1. Continue with the steps in [Create an Auto Scaling group using a launch template](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template).
------
#### [ AWS CLI ]
**To enable zonal shift on a new group (AWS CLI)**
Add the `--availability-zone-impairment-policy` parameter to the [create-auto-scaling-group](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/create-auto-scaling-group.html) command.
The `--availability-zone-impairment-policy` parameter has two options:
+ **ZonalShiftEnabled** – If set to `true`, Auto Scaling registers the Auto Scaling group with ARC zonal shift and you can [start, update, or cancel a zonal shift](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) on the ARC console. If set to `false`, Auto Scaling deregisters the Auto Scaling group from ARC zonal shift. You must already have zonal shift enabled to set to `false`.
+ **ImpairedZoneHealthCheckBehavior** – If set to `replace-unhealthy`, unhealthy instances will be replaced in the Availability Zone with the active zonal shift. If set to `ignore-unhealthy`, unhealthy instances will not be replaced in the Availability Zone with the active zonal shift.
The following example enables zonal shift on a new Auto Scaling group named `my-asg`.
```
aws autoscaling create-auto-scaling-group \
--launch-template LaunchTemplateName=my-launch-template,Version='1' \
--auto-scaling-group-name my-asg \
--min-size 1 \
--max-size 10 \
--desired-capacity 5 \
--availability-zones us-east-1a us-east-1b us-east-1c \
--availability-zone-impairment-policy '{
"ZonalShiftEnabled": true,
"ImpairedZoneHealthCheckBehavior": IgnoreUnhealthy
}'
```
------
------
#### [ Console ]
**To enable zonal shift on an existing group (console)**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), and choose **Auto Scaling Groups** from the navigation pane.
1. On the navigation bar at the top of the screen, choose the AWS Region that you created your Auto Scaling group in.
1. Select the checkbox next to the Auto Scaling group.
A split pane opens up in the bottom of the page.
1. On the **Integrations** tab, under **ARC zonal shift**, choose **Edit**.
1. Select the checkbox to enable zonal shift.
1. For **Health check behavior**, choose **Ignore unhealthy** or **Replace unhealthy**.
+ If health check behavior is set to ignore unhealthy, unhealthy instances are *not* replaced in the Availability Zone with the active zonal shift.
+ If health check behavior is set to replace unhealthy, unhealthy instances are replaced in the Availability Zone with the active zonal shift.
1. Choose **Update**.
------
#### [ AWS CLI ]
**To enable zonal shift on an existing group (AWS CLI)**
Add the `--availability-zone-impairment-policy` parameter to the [update-auto-scaling-group](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html) command.
The `--availability-zone-impairment-policy` parameter has two options:
+ **ZonalShiftEnabled** – If set to `TRUE`, Auto Scaling registers the Auto Scaling group with ARC zonal shift and you can [start, update, or cancel a zonal shift](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) on the ARC console. If set to `FALSE`, Auto Scaling deregisters the Auto Scaling group from ARC zonal shift. You must already have zonal shift enabled to set it to `FALSE`.
+ **ImpairedZoneHealthCheckBehavior** – If set to `replace-unhealthy`, unhealthy instances will be replaced in the Availability Zone with the active zonal shift. If set to `ignore-unhealthy`, unhealthy instances will not be replaced in the Availability Zone with the active zonal shift.
The following example enables zonal shift on the specified Auto Scaling group.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \
--availability-zone-impairment-policy '{
"ZonalShiftEnabled": true,
"ImpairedZoneHealthCheckBehavior": IgnoreUnhealthy
}'
```
------
To start a zonal shift, see [Starting, updating, or canceling a zonal shift](arc-zonal-shift.start-cancel.md).
## How zonal shift works for Auto Scaling groups
Suppose you have an Auto Scaling group with the following Availability Zones:
+ `us-east-1a`
+ `us-east-1b`
+ `us-east-1c`
You notice failures in `us-east-1a` and start a zonal shift. The following behaviors occur when a zonal shift is started in `us-east-1a`.
+ **Scaling out** – Auto Scaling launches all new capacity requests in the healthy Availability Zones (`us-east-1b` and `us-east-1c`).
+ **Dynamic scaling** – Auto Scaling blocks scaling policies from decreasing desired capacity. Auto Scaling does not block scaling policies from increasing desired capacity.
+ **Instance refresh** – Auto Scaling extends the timeout for any instance refresh process that is delayed during an active zonal shift.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.ec2-auto-scaling-groups.html)
## Best practices for using zonal shift
To maintain high availability for your applications when using zonal shift, we recommend the following best practices.
+ Monitor EventBridge notifications to determine when there is an ongoing availability zone impairment event. For more information, see [Automating Amazon EC2 Auto Scaling with EventBridge](https://docs.aws.amazon.com//autoscaling/ec2/userguide/automating-ec2-auto-scaling-with-eventbridge.html).
+ Use scaling policies with appropriate thresholds to make sure that you have enough capacity to tolerate the loss of an availability zone.
+ Set an instance maintenance policy with a minimum healthy percentage of 100. With this setting, Auto Scaling waits for a new instance to be ready to use before terminating an unhealthy instance.
For prescaled customers, we also recommend the following:
+ Select **Ignore unhealthy** as the health check behavior for the impaired availability zone because you don't need to replace the unhealthy instance during the impairment event.
+ Use zonal autoshift in ARC for your Auto Scaling groups. The zonal autoshift capability in Amazon Application Recovery Controller (ARC) allows AWS to shift traffic for a resource away from an availability zone when AWS detects an impairment in an availability zone. For more information, see [Zonal autoshift in ARC](arc-zonal-autoshift.md).
For customers with cross-zone disabled load balancers, we also recommend:
+ Use **balanced only** for your availability zone distribution.
+ If you are using zonal shift on both your Auto Scaling group and your load balancers, make sure to cancel the zonal shift on your Auto Scaling group first. Then, wait until the capacity is balanced across all availability zones. before you cancel the zonal shift on the load balancer.
+ Because of the possibility of imbalanced capacity when you enable zonal shift and you use a cross-zone disabled load balancer, Auto Scaling has an extra validation. If you are following the best practices, you can acknowledge this possibility by selecting the checkbox in the AWS Management Console or using the `skip-zonal-shift-validation` flag in `CreateAutoScalingGroup`, `UpdateAutoScalingGroup`, or `AttachTrafficSources`.
# Amazon Elastic Kubernetes Service
Amazon EKS provides features that enable you to make your applications more resilient to events such as the degraded health or the impairment of an Availability Zone. When you run your workloads in an Amazon EKS cluster, you can further improve your application environment’s fault tolerance and application recovery by using zonal shift or zonal autoshift.
## Using zonal shift with Amazon Elastic Kubernetes Service
To enable zonal shift, use one of the following methods. For more information, see [Learn about ARC zonal shift](https://docs.aws.amazon.com//eks/latest/userguide/zone-shift-enable.html#zone-shift-enable-steps) in the *Amazon Elastic Kubernetes Service User Guide*.
------
#### [ Console ]
**To enable zonal shift on a new Amazon EKS cluster (Console)**
1. Find the name and Region of the Amazon EKS cluster that you want to register with ARC.
1. Open the Amazon EKS console at [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Select your cluster.
1. On the **Cluster info** page, select the **Overview** tab.
1. Under **Zonal shift**, choose **Manage**.
1. For **EKS Zonal Shift**, choose **Enable** or **Disable**.
------
#### [ AWS CLI ]
**To enable zonal shift on a new Amazon EKS cluster (AWS CLI)**
+ Enter the following command:
```
aws eks create-cluster --name my-eks-cluster --role-arn my-role-arn-to-create-cluster --resources-vpc-config subnetIds=string,string,securityGroupIds=string,string,endpointPublicAccess=boolean,endpointPrivateAccess=boolean,publicAccessCidrs=string,string --zonal-shift-config enabled=true
```
**To enable zonal shift on an existing Amazon EKS cluster (AWS CLI)**
+ Enter the following command:
```
aws eks update-cluster-config --name my-eks-cluster --zonal-shift-config enabled=true
```
------
You can start a zonal shift for an Amazon EKS cluster, or you can allow AWS to do it for you, by enabling zonal autoshift. After your Amazon EKS cluster zonal shift enabled with ARC, you can start a zonal shift or enable zonal autoshift using the ARC Console, the AWS CLI, or the zonal shift and zonal autoshift APIs.
For more information on starting a zonal shift, see [Starting, updating, or canceling a zonal shift](arc-zonal-shift.start-cancel.md).
For more information on enabling Amazon EKS with zonal shift, see [Learn about ARC Zonal Shift in Amazon EKS](https://docs.aws.amazon.com//eks/latest/userguide/zone-shift.html) in the *Amazon Elastic Kubernetes Service User Guide*.
## How zonal shift works for Amazon Elastic Kubernetes Service
During an Amazon EKS zonal shift, the following automatically takes place:
+ All the nodes in the impacted AZ are cordoned. This prevents the Kubernetes Scheduler from scheduling new Pods onto the nodes in the unhealthy AZ.
+ If you’re using [Managed Node Groups](https://docs.aws.amazon.com//eks/latest/userguide/managed-node-groups.html), [Availability Zone rebalancing](https://docs.aws.amazon.com//autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) is suspended, and your Auto Scaling group is updated to ensure that new Amazon EKS data plane nodes are only launched in healthy AZs.
+ The nodes in the unhealthy AZ are not terminated and the Pods are not evicted from these nodes. This is to ensure that when a zonal shift expires or is canceled, your traffic can be safely returned to the AZ that still has full capacity.
+ The EndpointSlice controller finds all the Pod endpoints in the impaired AZ and removes them from the relevant EndpointSlices. This ensures that only Pod endpoints in healthy AZs are targeted to receive network traffic. When a zonal shift is canceled or expires, the EndpointSlice controller updates the EndpointSlices to include the endpoints in the restored AZ.
For more information, see the [AWS Containers blog](https://aws.amazon.com/blogs/containers/amazon-eks-now-supports-amazon-application-recovery-controller/).
# Application Load Balancers
## Using zonal shift for Application Load Balancers
To use Application Load Balancers with zonal shift, you must enable ARC zonal shift integration in the Application Load Balancer attributes. Application Load Balancer supports zonal shift with cross-zone enabled or cross-zone disabled configurations.
Before you enable the ARC integration and start using zonal shift, review the following information:
+ You can start a zonal shift for a specific load balancer only for a single Availability Zone. You can't start a zonal shift for multiple Availability Zones.
+ AWS proactively removes zonal load balancer IP addresses from DNS when multiple infrastructure issues impact services. Always check current Availability Zone capacity before you start a zonal shift.
+ Zonal shift won't work for single-AZ target groups.
+ When an Application Load Balancer is a target of a Network Load Balancer, always start the zonal shift from the Network Load Balancer. If you start a zonal shift from the Application Load Balancer, the Network Load Balancer doesn't recognize the shift and continues to send traffic to the Application Load Balancer.
You can start a zonal shift for a load balancer in the Elastic Load Balancing console (in most AWS Regions) or in the ARC console.
------
#### [ Console ]
**To enable zonal shift on a load balancer (Console)**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. On the **Navigation** page, under **Load balancing**, choose **Load balancers**.
1. Select the Application Load Balancer name.
1. On the **Attributes** tab, **Edit**.
1. Under **Availability Zone routing configuration**, for >ARC zonal shift integration, choose **Enable**.
1. Choose **Save**.
------
#### [ AWS CLI ]
**To enable zonal shift on a load balancer (AWS CLI)**
+ Enter the following command:
```
aws elbv2 modify-load-balancer-attributes --load-balancer-arn my-alb-arn --attributes Key=zonal_shift.config.enabled,Value=true
```
------
For more information on starting a zonal shift, see [Starting, updating, or canceling a zonal shift](arc-zonal-shift.start-cancel.md).
You can use the `keepalive` option to configure how long connections continue. For more information, see [ 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. By default, Application Load Balancers set the HTTP client keepalive duration value to 3600 seconds, or 1 hour. We suggest that you lower the value to be inline with your recovery time goal for your application, for example, 300 seconds. When you choose an HTTP client keepalive duration 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.
## How zonal shift works for Application Load Balancers
When a zonal shift is started on an Application Load Balancer with cross-zone load balancing enabled, all traffic to targets is blocked in the Availability Zone that is impacted, and the zonal shift removes the zonal IP address from DNS.
For more information, see [Integrations for your Application Load Balancer](https://docs.aws.amazon.com//elasticloadbalancing/latest/application/load-balancer-integrations.html#zonal-shift) in the *Application Load Balancer User Guide*.
# Network Load Balancers
## Using zonal shift for Network Load Balancers
To use Network Load Balancers with zonal shift, you must enable ARC zonal shift integration in the Network Load Balancer attributes. Network Load Balancer supports zonal shift with cross-zone enabled or cross-zone disabled configurations.
You can choose which resources to opt-in to use zonal shift and zonal autoshift, and when you would like to fail away from an impaired Availability Zone. Both internet-facing and internal Network Load Balancers are supported.
To enable zonal shift for your cross-zone enabled Network Load Balancer, all target groups attached to the load balancer must meet the following requirements.
+ Cross-zone load balancing must be enabled, or set to `use_load_balancer_configuration`.
+ For more information on target group cross-zone load balancing, see [Cross-zone load balancing for target groups](https://docs.aws.amazon.com//elasticloadbalancing/latest/network/edit-target-group-attributes.html#target-group-cross-zone).
+ Target group protocol must be TCP or TLS.
+ For more information on Network Load Balancer target group protocols, see [Routing configuration](https://docs.aws.amazon.com//elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-routing-configuration).
+ Connection termination for unhealthy targets must be disabled.
+ For more information on target group connection termination, see [Connection termination for unhealthy targets](https://docs.aws.amazon.com//elasticloadbalancing/latest/network/edit-target-group-attributes.html#unhealthy-target-connection-termination).
+ Target group must not have any Application Load Balancers as targets.
+ For more information on Application Load Balancers as targets, see [Use Application Load Balancers as targets of a Network Load Balancer](https://docs.aws.amazon.com//elasticloadbalancing/latest/network/application-load-balancer-target.html).
You can start a zonal shift for a Network Load Balancer by using the AWS CLI, the AWS Management Console, or the Elastic Load Balancing widget. When an Application Load Balancer is the target of a Network Load Balancer, you must start the zonal shift from the Network Load Balancer. If you start the zonal shift from the Application Load Balancer, the Network Load Balancer will not stop sending traffic to the Application Load Balancer and its targets.
------
#### [ Console ]
**To enable zonal shift on a load balancer (Console)**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. On the **Navigation** page, under **Load balancing**, choose **Load balancers**.
1. Select the Network Load Balancer name.
1. On the **Attributes** tab, choose **Edit**.
1. Under **Availability Zone routing configuration**, for **ARC zonal shift integration**, choose **Enable**.
1. Choose **Save**.
------
#### [ AWS CLI ]
**To enable zonal shift on a load balancer (AWS CLI)**
+ Enter the following command:
```
aws elbv2 modify-load-balancer-attributes --load-balancer-arn my-nlb-arn --attributes Key=zonal_shift.config.enabled,Value=true
```
------
For more information about starting a zonal shift, see [Starting, updating, or canceling a zonal shift](arc-zonal-shift.start-cancel.md).
## How zonal shift works for Network Load Balancers
ARC creates a health check failure for the registered Network Load Balancer so that the Network Load Balancer node in the impaired AZ is removed from the DNS when you start a zonal shift. The Network Load Balancer disables the targets in the impacted zone so that they stop receiving traffic, and Elastic Load Balancing treats these targets as disabled targets for zonal shift. Targets in the disabled state continue receiving health checks. When the targets are healthy and the zonal shift expires (or is canceled), routing to targets in the previously impaired zone resumes.
During zonal shift on Network Load Balancers with cross-zone load balancing enabled, the zonal load balancer IP addresses are removed from DNS. Existing connections to targets in the impaired Availability Zone persist until they organically close, while new connections are no longer routed to targets in the impaired Availability Zone.
For more information see [Zonal Shift for your Network Load Balancer](https://docs.aws.amazon.com//elasticloadbalancing/latest/network/zonal-shift.html) in the *Network Load Balancer User Guide*.
# Starting, updating, or canceling a zonal shift
This section provides procedures for working with zonal shifts, including starting a zonal shift and canceling a zonal shift.
## Starting a zonal shift
The steps in this section explain how to start a customer-initiated zonal shift on the Amazon Application Recovery Controller (ARC) console. To work with zonal shift programmatically, see the [ Zonal Shift API Reference Guide](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/Welcome.html).
In addition to starting a zonal shift in ARC, you can also start a zonal shift for a load balancer in the Elastic Load Balancing console (in supported Regions). For more information, see [Zonal shift](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/zonal-shift.html) in the Elastic Load Balancing User Guide.
## To start a zonal shift
1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/home#/dashboard](https://console.aws.amazon.com/route53recovery/home#/dashboard).
1. Under **Multi-AZ**, choose **Zonal shift**.
1. On the **Zonal shift** page, choose **Start zonal shift**.
1. Select the Availability Zone that you want to shift traffic away from.
1. Select a supported resource from the **Resources** table to shift traffic away for.
1. For **Set zonal shift expiration**, choose or enter an expiration for the zonal shift. A zonal shift can set to be active initially for 1 minute or up to three days (72 hours).
All zonal shifts are temporary. You must set an expiration, but you can update active shifts later to set a new expiration period of up to three days.
1. Enter a comment. You can update the zonal shift later to edit the comment, if you like.
1. Select the checkbox to acknowledge that starting a zonal shift will reduce available capacity for your application by shifting traffic away from the Availability Zone.
1. Choose **Start**.
## Updating or canceling a zonal shift
The steps in this section explain how to update a zonal shift that you initiate, or cancel a zonal shift, on the Amazon Application Recovery Controller (ARC) console. To work with zonal shift programmatically, see the [ Zonal Shift API Reference Guide](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/Welcome.html).
You can update a zonal shift to set a new expiration, or edit or replace the comment for the zonal shift. You can cancel a zonal shift any time before it expires.
You can cancel zonal shifts that you initiate, or zonal shifts that AWS starts for a resource for a practice run for zonal autoshift. To learn more about practice shifts in zonal autoshift, see [How zonal autoshift and practice runs work](arc-zonal-autoshift.how-it-works.md).
## To update a zonal shift
1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/home#/dashboard](https://console.aws.amazon.com/route53recovery/home#/dashboard).
1. Under **Multi-AZ**, choose **Zonal shift**.
1. Select a zonal shift that you want to update, and then choose **Update zonal shift**.
1. For **Set zonal shift expiration**, optionally select or enter an expiration.
1. For **Comment**, optionally edit the existing comment or enter a new comment.
1. Choose **Update**.
## To cancel a zonal shift
1. Open the ARC console at [https://console.aws.amazon.com/route53recovery/home#/dashboard](https://console.aws.amazon.com/route53recovery/home#/dashboard).
1. Under **Multi-AZ**, choose **Zonal shift**.
1. Select a zonal shift that you want to cancel, and then choose **Cancel zonal shift**.
1. On the confirmation modal dialog, choose **Confirm**.
# Logging and monitoring for zonal shift in Amazon Application Recovery Controller (ARC)
You can use AWS CloudTrail for monitoring zonal shift in Amazon Application Recovery Controller (ARC), to analyze patterns and help troubleshoot issues.
**Topics**
+ [Logging zonal shift API calls using AWS CloudTrail](cloudtrail-zonal-shift.md)
# Logging zonal shift API calls using AWS CloudTrail
Zonal shift 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 shift information in CloudTrail
CloudTrail is enabled on your AWS account when you create the account. When activity occurs in ARC for zonal shift, 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 shift 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 shift 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 shift.
```
{
"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"
}
}
```
The following example shows a CloudTrail log entry that demonstrates the `StartZonalShift` action with a conflict exception for zonal shift.
```
{
"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:10:38Z",
"eventSource": "arc-zonal-shift.amazonaws.com",
"eventName": "StartZonalShift",
"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",
"errorCode": "ConflictException",
"errorMessage": "There's already an active zonal shift for that resource identifier: 'arn:aws:testservice:us-west-2:077059137270:testResource/456apples'. Active zonal shift: 'bac23b74-176e-c073-de8f-484ca508910f'",
"requestParameters": {
"resourceIdentifier": "arn:aws:testservice:us-west-2:077059137270:testResource/456apples",
"awayFrom": "usw2-az1",
"expiresIn": "2m",
"comment": "HIDDEN_FOR_SECURITY_REASONS"
},
"responseElements": null,
"requestID": "OP4OYXZ54HUPMIPGWH_EXAMPLE",
"eventID": "0bca6660-e999-43a5-9008-EXAMPLE",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333"
"eventCategory": "Management"
}
}
```
# Identity and Access Management for zonal shift 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 shift works with IAM](security_iam_service-with-iam-zs.md)
+ [Permissions for zonal shift](security_iam_service-with-iam-zonal-shift.md)
+ [Identity-based policy examples](security_iam_id-based-policy-examples-zonal.md)
# How zonal shift works with IAM
Before you use IAM to manage access to zonal shift in Amazon Application Recovery Controller (ARC), learn what IAM features are available to use with zonal shift.
**IAM features you can use with zonal shift**
| IAM feature | Zonal shift support |
| --- | --- |
| [Identity-based policies](#security_iam_service-with-iam-id-based-policies) | Yes |
| [Resource-based policies](#security_iam_service-with-iam-resource-based-policies) | No |
| [Policy actions](#security_iam_service-with-iam-id-based-policies-actions) | Yes |
| [Policy resources](#security_iam_service-with-iam-id-based-policies-resources) | Yes |
| [Policy condition keys](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Yes |
| [ACLs](#security_iam_service-with-iam-acls) | No |
| [ABAC (tags in policies)](#security_iam_service-with-iam-tags) | Partial |
| [Temporary credentials](#security_iam_service-with-iam-roles-tempcreds) | Yes |
| [Principal permissions](#security_iam_service-with-iam-principal-permissions) | Yes |
| [Service roles](#security_iam_service-with-iam-roles-service) | No |
| [Service-linked roles](#security_iam_service-with-iam-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 zonal shift
**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 shift, 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 shift 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 shift, see [Identity-based policy examples for zonal shift in ARC](security_iam_id-based-policy-examples-zonal.md).
## Policy resources for zonal shift
**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 shift, see [Identity-based policy examples for zonal shift in ARC](security_iam_id-based-policy-examples-zonal.md).
## Policy condition keys for zonal shift
**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 zonal shift condition keys, 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 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_amazonroute53recoverycontrols.html#amazonroute53applicationrecoverycontroller-zonalshift-actions-as-permissions)
+ [ Resource types defined by Amazon Route 53 - Zonal Shift](https://docs.aws.amazon.com//service-authorization/latest/reference/list_amazonroute53applicationrecoverycontroller-zonalshift.html#amazonroute53applicationrecoverycontroller-zonalshift-resources-for-iam-policies)
To view examples of ARC identity-based policies for zonal shift, see [Identity-based policy examples for zonal shift in ARC](security_iam_id-based-policy-examples-zonal.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*.
ARC includes the following partial support for ABAC:
+ Zonal shift 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.
Zonal shift does not use service-linked roles.
# IAM and permissions for zonal shift
This section provides additional information about how permissions work for the zonal shift feature in Amazon Application Recovery Controller (ARC), especially if you work with the feature from another AWS service, such as Elastic Load Balancing. To learn about how ARC features works with IAM and permissions in general, review the information in the overview topic, [Identity and Access Management for zonal shift in ARC](security-iam-zonalshift.md).
Zonal shift supports Application Load Balancers, Network Load Balancers, Amazon EC2 Auto Scaling groups, and Amazon EKS. You can use IAM condition keys to scope an IAM permission policy to these resources. The following is an example policy using a condition key with multiple resources of different types:
```
{
"Condition": {
"StringLike": {
"arc-zonal-shift:ResourceIdentifier": [
"arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/net/*",
"arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/*",
"arn:aws:eks:us-east-1:123456789012:cluster/*"
]
}
},
"Action": [
"arc-zonal-shift:StartZonalShift"
],
"Resource": "*",
"Effect": "Allow"
}
```
For more information, see [Supported resources](arc-zonal-shift.resource-types.md).
In addition to the permissions outlined in the IAM overview topic, the following applies to zonal shift for IAM and permissions:
+ Make sure that you have the required permissions for working with zonal shift in ARC. For more information, see [zonal shift console access](security_iam_id-based-policy-examples-zonal.md#security_iam_id-based-policy-examples-console-zonal) and [zonal shift operations access](security_iam_id-based-policy-examples-zonal.md#security_iam_id-based-policy-examples-api-zonal).
+ You do not need to add additional Elastic Load Balancing permissions with IAM to work with zonal shifts for managed load balancer resources in your account in ARC.
+ An AWS managed policy that provides full access for Elastic Load Balancing includes permissions for working with zonal shifts. If you use AWS managed policies for Elastic Load Balancing access, you do not need additional permissions in IAM for zonal shift to start zonal shifts for load balancers or work with in the Elastic Load Balancing console. For more information, see [AWS managed policies for Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/managed-policies.html).
# Identity-based policy examples for zonal shift 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 shift console access](#security_iam_id-based-policy-examples-console-zonal)
+ [Example: Zonal shift API actions](#security_iam_id-based-policy-examples-api-zonal)
## 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 shift 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 give users full access to use zonal shift 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"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:DescribeAvailabilityZones",
"Resource": "*"
}
]
}
```
------
## Example: Zonal shift API actions
The zonal shift API temporarily moves traffic away from an Availability Zone to recover an application.
To ensure that a user can use zonal shift API actions, attach a policy that corresponds to the API operations that the user needs to work with, such as the following:
------
#### [ 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"
],
"Resource": "*"
}
]
}
```
------