Availability Zone (AZ) Migration & Instance Upgrade Guide

Note: In this document, the term “specified zone” refers to the zone that you will be migrating from.

Identifying Instances Running in an AZ

You can start by identifying if an account is allowlisted to use specific AZ. To do so, you can run “aws ec2 describe-availability-zones” CLI from each account. If that specific AZ shows up in the response, then the account is allowlisted to run instances in that AZ.

Then, from the CLI you can run aws ec2 describe-availability-zones --region "region-name" to find the ZoneName that maps to the specific ZoneId. Any instances running on an AZ that matches this ZoneName will be an instance that needs to be migrated and/or upgraded. See Availability Zone Ids for your AWS resources for more information.

You can also use the AWS management Console to display your running instances and check which instances that you are running in that AZ.

Upgrading and Migrating EC2 Instances

To upgrade EC2 instances to the latest generation instance types, check the “Considerations for compatible instance types” section in the following document: Change the instance type.

If you want a recommendation for an instance type that is best able to handle your existing workload, you can also use AWS Compute Optimizer. For more information, see Get recommendations for an instance type.

Once you identify the latest generation instance type and the new AZ to migrate to, you can launch new instance in the new AZ (configure new AZ in the new instance settings) as described in the “Change the instance type by launching a new instance” in the following document: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html

Migrating EBS

For your EBS volumes that are not currently attached to your EC2 instances, you can migrate them into a different availability zone (AZ) via EBS snapshots. You can take EBS snapshots of these volumes, and create new EBS volumes from the snapshots in your desired AZ. After that, you can delete the original EBS volumes, and the snapshots if you no longer need them to be the backups.

Migrating NAT Gateway

A NAT Gateway is built with redundancy in an availability zone and should typically be used by resources in the same availability zone. Once you have migrated all your resources to another availability zone from specified AZ, you should also spin up a new NAT Gateway in the same availability zone as the resources and route your traffic to this new NAT Gateway. You can then delete the NAT Gateway in AZ you are migrating out of.

Please note that if you want to use the same NAT IP address as the one in AZ you are migrating out of, then you will need to delete the NAT Gateway in the AZ first to release the EIP and then use the same EIP while creating the NAT Gateway in another AZ.

Upgrading and Migrating ElastiCache:

We recommend creating a new cluster (https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Clusters.Create.html) or adding a node to your existing cluster in a different Availability Zone (https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Clusters.AddNode.html).

If you are using Previous Generation Nodes, we recommend updating to Latest Generation Nodes (https://aws.amazon.com/elasticache/previous-generation/).

ELB Migration Guide

This guide explains how to safely move your Elastic Load Balancers (ELBs) out of a single EC2 Availability Zone (AZ) without causing impact to your workload. There are 4 types of ELBs - Classic (CLB), Application (ALB), Network (NLB), Gateway Load Balancer (GWLB). The process varies between load balancer type, and below you can find sections for Classic (CLB) and Application (ALB).

You can use the aws ec2 describe-availability-zones --region "region-name" command in the AWS CLI to generate AZ ID information. Be sure to replace "region-name" with the name of your AWS region.

Example output of AWS CLI, note that the ZoneName may differ for your each account, while the physical ZoneId will be the same.

 aws ec2 describe-availability-zones --zone-ids --region ap-northeast-1
 {
     "AvailabilityZones": [
         {
             "State": "available",
             "OptInStatus": "opt-in-not-required",
             "Messages": [],
             "RegionName": "ap-northeast-1",
             "ZoneName": "ap-northeast-1a",
             "ZoneId": "xxxxxxx",
             "GroupName": "ap-northeast-1",
             "NetworkBorderGroup": "ap-northeast-1",
             "ZoneType": "availability-zone"
         }
     ]
 }

Classic Load Balancer

Documentation link: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-manage-subnets.html#remove-subnet

Note: Please ensure all remaining AZs have enough capacity to compensate for the targets that will be removed from the specified zone before making any changes to the load balancer’s configuration. To migrate out of one Availability Zone replacing it with another using the AWS console

1. Open the AWS EC2 console at https://console.aws.amazon.com/ec2/.
2. On the navigation pane, under Load Balancing, choose Load Balancers.
3. Choose the name of the load balancer to open its detail page.
4. On the Network mapping tab, choose Edit subnets.
5. On the Edit subnets page, in the Network mapping section, select an appropriate subnet in another available Availability Zone.
6. When you are finished, choose Save changes.
7. Review the Target Instances tab and wait +15 minutes for the targets you registered in the new AZ to be marked as healthy and receive traffic.
8. Click Edit subnets again, and deselect the Availability Zone you are migrating out of, to remove it and its associated subnet.
9. Choose Save changes.

To migrate out of one Availability Zone replacing it with another using the AWS CLI

First use the attach-load-balancer-to-subnets command to select a new AZ to move to:

aws elb attach-load-balancer-to-subnets --load-balancer-name my-loadbalancer --subnets subnet-33333333

The response lists the current configured Availability Zones for the load balancer. For example:

{
    "Subnets": [
        "subnet-11111111",
        "subnet-22222222",
        "subnet-33333333"
    ]
}

Review the Target Instances tab and wait +15 minutes for the targets you registered in the new AZ to be marked as healthy and receive traffic.

Then use the detach-load-balancer-from-subnets command to finally remove the AZ you are migrating away from:

aws elb detach-load-balancer-from-subnets --load-balancer-name my-loadbalancer --subnets subnet-11111111

The response lists the remaining Availability Zones for the load balancer. For example:

{
    "Subnets": [
        "subnet-22222222",
        "subnet-33333333"
    ]
}

Application Load Balancer

Documentation link: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html

Note: Please ensure all remaining AZs have enough capacity to compensate for the targets that will be removed from the specified zone before making any changes to the load balancer’s configuration.

To migrate out of one Availability Zone replacing it with another using the AWS console

1. Open the AWS EC2 console at https://console.aws.amazon.com/ec2/.
2. On the navigation pane, under Load Balancing, choose Load Balancers.
3. Choose the name of the load balancer to open its detail page.
4. On the Network mapping tab, choose Edit subnets.
5. On the Edit subnets page, in the Network mapping section, select an appropriate subnet in another available Availability Zone.
6. When you are finished, choose Save changes.
7. Review the Target Instances tab and wait +15 minutes for the targets you registered in the new AZ to be marked as healthy and receive traffic.
8. Click Edit subnets again, and deselect the Availability Zone you are migrating out of, to remove it and its associated subnet.
9. Choose Save changes.

To update Availability Zones using the AWS CLI

Use the set-subnetscommand by omitting the subnet located in the required AZ. Please note that if your ALB was deployed in only two subnets you will need to specify a second subnet in your CLI command. You must specify subnets from at least two AZs.

aws elbv2 set-subnets --load-balancer-arn arn:aws:elasticloadbalancing:us-west-2:123456789012:loadbalancer/app/my-load-balancer/abcd123456789012 --subnets subnet-11111111 subnet-22222222

RDS Migration Guide

To migrate your instance, follow the steps for the respective engine & configuration:

• OSS Engines SAZ Options:
  • Read Replica Option
    1. Create Read Replica in another AZ, 2. Once Read Replica is synchronized, promote Read Replica to Primary, 3. Rename old Primary and new Read Replica 4. Delete the old primary 5. Remove the specific AZ from any DB Subnet Group https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create
  • SAZ to MAZ Conversion Option
    1. Convert to MAZ, 2. Force Failover to Standby, 3. Revert back to SAZ 4. Remove the specific AZ from any DB Subnet Group Note: this will have a write latency impact to database instance. DBs with large storage and with heavy workloads may observe a latency impact for several hours. https://aws.amazon.com/blogs/database/best-practices-for-converting-a-single-az-amazon-rds-instance-to-a-multi-az-instance/
  • Snapshot Option (Least Preferable)
    1. Create snapshot, 2. Restore from Snapshot in new AZ, 3. Rename endpoints 4. Remove the specific AZ from any DB Subnet Group https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html
• OSS Engines MAZ Options:
  • If Primary instance is in specified zone:
    1. Force a Failover to Standby, 2. Convert to SAZ, 3. Remove the specific AZ from any DB Subnet Group, 4. Convert back to MAZ Note: this will have a write latency impact to database instance. DBs with large storage and with heavy workloads may observe a latency impact for several hours. https://aws.amazon.com/blogs/database/best-practices-for-converting-a-single-az-amazon-rds-instance-to-a-multi-az-instance/
  • If Standby instance is in specified zone:
    1. Convert to SAZ, 2. Remove the specific AZ from any DB Subnet Group, 3. Convert back to MAZ
• Commercial Engines SAZ:
  • SAZ to MAZ Conversion Option
    1. Convert to MAZ, 2. Force Failover to Standby, 3. Revert back to SAZ, 4. Remove the specific AZ from any DB Subnet Group https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html#Concepts.MultiAZ.Migrating
• Commercial Engines MAZ:
  • If Primary instance is in the specified zone:
    1. Force a Failover to Standby, 2. Convert to SAZ, 3. Remove the specific AZ from any DB Subnet Group, 4. Convert back to MAZ https://aws.amazon.com/blogs/database/best-practices-for-converting-a-single-az-amazon-rds-instance-to-a-multi-az-instance/
  • If Standby instance is in the specified:
    1. Convert to SAZ, 2. Remove the specific AZ from any DB Subnet Group, 3. Convert back to MAZ

Instances can be upgraded to newer generations through the console, API, or CLI. See Modifying an Amazon RDS Instance for detailed instructions on each method. It is important to note that some Instance Types have minimum engine version requirements for various engines. For detailed information on supported Instance Types by Engine see Supported DB engines for DB instance classes