EC2-Classic is Retiring – Here’s How to Prepare
Update (July 29, 2021) – Added link to the Support Automation Workflow document & clarified link to AWS MGN pricing. Also updated the list of recommended instance types to favor those built on AWS Nitro System.
Let’s go back to the summer of 2006 and the launch of EC2. We started out with one instance type (the venerable m1.small), security groups, and the venerable US East (N. Virginia) Region. The EC2-Classic network model was flat, with public IP addresses that were assigned at launch time.
Our initial customers saw the value right away and started to put EC2 to use in many different ways. We hosted web sites, supported the launch of Justin.TV, and helped Animoto to scale to a then-amazing 3400 instances when their Facebook app went viral.
Some of the early enhancements to EC2 focused on networking. For example, we added Elastic IP addresses in early 2008 so that addresses could be long-lived and associated with different instances over time if necessary. After that we added Auto Scaling, Load Balancing, and CloudWatch to help you to build highly scalable applications.
Early customers wanted to connect their EC2 instances to their corporate networks, exercise additional control over IP address ranges, and to construct more sophisticated network topologies. We launched Amazon Virtual Private Cloud in 2009, and in 2013 we made the VPC model essentially transparent with Virtual Private Clouds for Everyone.
Retiring EC2-Classic
EC2-Classic has served us well, but we’re going to give it a gold watch and a well-deserved sendoff! This post will tell you what you need to know, what you need to do, and when you need to do it.
Before I dive in, rest assured that we are going to make this as smooth and as non-disruptive as possible. We are not planning to disrupt any workloads and we are giving you plenty of lead time so that you can plan, test, and perform your migration. In addition to this blog post, we have tools, documentation, and people that are all designed to help.
Timing
We are already notifying the remaining EC2-Classic customers via their account teams, and will soon start to issue notices in the Personal Health Dashboard. Here are the important dates for your calendar:
- All AWS accounts created after December 4, 2013 are already VPC-only, unless EC2-Classic was enabled as a result of a support request.
- On October 30, 2021 we will disable EC2-Classic in Regions for AWS accounts that have no active EC2-Classic resources in the Region, as listed below. We will also stop selling 1-year and 3-year Reserved Instances for EC2-Classic.
- On August 15, 2022 we expect all migrations to be complete, with no remaining EC2-Classic resources present in any AWS account.
Again, we don’t plan to disrupt any workloads and will do our best to help you to meet these dates.
Affected Resources
In order to fully migrate from EC2-Classic to VPC, you need to find, examine, and migrate all of the following resources:
- Running or stopped EC2 instances.
- Running or stopped RDS database instances.
- Elastic IP addresses – You can use the
move-address-to-vpccommand. - Classic Load Balancers – Migrate Your Classic Load Balancer.
- Redshift clusters – How do I Move my Amazon Redshift Cluster.
- Elastic Beanstalk environments – Migrating Elastic Beanstalk environments from EC2-Classic to a VPC.
- EMR clusters – Configure EMR Networking.
- AWS Data Pipelines pipelines – Launching Resources for Your Pipeline into a VPC.
- ElastiCache clusters – Understanding ElastiCache and Amazon VPCs.
- Reserved Instances – You can modify these as described in the User Guide.
- Spot Requests.
- Capacity Reservations.
In preparation for your migration, be sure to read Migrate from EC2-Classic to a VPC.
You may need to create (or re-create, if you deleted it) the default VPC for your account. To learn how to do this, read Creating a Default VPC.
In some cases you will be able to modify the existing resources; in others you will need to create new and equivalent resources in a VPC.
Finding EC2-Classic Resources
Use the EC2 Classic Resource Finder script to find all of the EC2-Classic resources in your account. You can run this directly in a single AWS account, or you can use the included multi-account-wrapper to run it against each account of an AWS Organization. The Resource Finder visits each AWS Region, looks for specific resources, and generates a set of CSV files. Here’s the first part of the output from my run:
The script takes a few minutes to run. I inspect the list of CSV files to get a sense of how much work I need to do:
And then I take a look inside to learn more:
Turns out that I have some stopped OpsWorks Stacks that I can either migrate or delete:
Migration Tools
Here’s an overview of the migration tools that you can use to migrate your AWS resources:
AWS Application Migration Service (AWS MGN) – Use AWS MGN to migrate your instances and your databases from EC2-Classic to VPC with minimal downtime. This service uses block-level replication and runs on multiple versions of Linux and Windows (read How to Use the New AWS Application Migration Service for Lift-and-Shift Migrations to learn more). The first 90 days of replication are free for each server that you migrate; see the AWS Application Migration Service Pricing page for more information.
Support Automation Workflow – This workflow supports simple, instance-level migration. It converts the source instance to an AMI, creates mirrors of the security groups, and launches new instances in the destination VPC. To learn more about this workflow, read How do I migrate an EC2-Classic instance to a VPC in same Region of same account?
After you have migrated all of the resources within a particular region, you can disable EC2-Classic by creating a support case. You can do this if you want to avoid accidentally creating new EC2-Classic resources in the region, but it is definitely not required.
Disabling EC2-Classic in a region is intended to be a one-way door, but you can contact AWS Support if you run it and then find that you need to re-enable EC2-Classic for a region. Be sure to run the Resource Finder that mentioned earlier and make sure that you have not left any resources behind. These resources will continue to run and to accrue charges even after the account status has been changed.
IP Address Migration – If you are migrating an EC2 instance and any Elastic IP addresses associated with the instance, you can use move-address-to-vpc then attach the Elastic IP to the migrated instance. This will allow you to continue to reference the instance by the original DNS name.
Classic Load Balancers – If you plan to migrate a Classic Load Balancer and need to preserve the original DNS names, please contact AWS Support or your AWS account team.
Updating Instance Types
All of the instance types that are available in EC2-Classic are also available in VPC. However, many newer instance types are available only in VPC, and you may want to consider an update as part of your overall migration plan. Here’s a map to get you started (the * indicates that there are multiple instances with the same name prefix):
| EC2-Classic | VPC |
| M1, T1 | T3, T4 |
| M3 | M5* |
| C1, C3 | C5* |
| CC2 | AWS ParallelCluster |
| CR1, M2, R3 | R4 |
| D2 | D3* |
| HS1 | D3* |
| I2 | I3en |
| G2 | G4 |
Count on Us
My colleagues in AWS Support are ready to help you with your migration to VPC. I am also planning to update this post with additional information and other migration resources as soon as they become available.
— Jeff;
Source: AWS News
