# 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*.