Migrate AWS Elastic Beanstalk from t1.micro to t2.micro

red health errorI wanted to convert my AWS Elastic Beanstalk instance from using t1.micro to t2.micro since the t2.micro instances cost less and are now the recommended way to use Elastic Beanstalk. However, if you simply just change the instance type to t2.micro, the instance environment will change to a red error state and you will get the following error message:
error details

Launching a new EC2 instance. Status Reason: The specified instance type can only be used in a VPC. A subnet ID or network interface ID is required to carry out the request. Launching EC2 instance failed.

Overcoming this error and switching to t2.micro is not difficult, but it also is not obvious how to do it. The following instructions show how. These instructions assume that you are starting with your instance as a t1.micro that is in a "green" working state.

Reason for the problem

Simply changing the instance from t1.micro to t2.micro in the instance’s configuration page does not work because t1.micro and t2.micro use different hosting backends that are incompatible with each other. The t1.micro instance uses "paravirtual", while t2.micro uses "hvm". Part of moving to t2.micro means that we’ll need to create and configure a Virtual Private Cloud (VPC), which is the major part that is not obvious how to do, but is not all that complicated once you know how to do it.

Create a DB snapshot

If your Elastic Beanstalk instance has an RDS (database) associated with it, then first you will need to manually create a snapshot of the database. This snapshot will be used to restore the database into the new t2.micro instance that will be created.

  1. click configurationGo to your Elastic Beanstalk environment instance and click on "Configuration"
  2. config RDSUnder the "Data Tier" section, click on the gear icon under the RDS instance. Make a note of the Endpoint name, since this will help you make sure you are taking a snapshot of the correct RDS instance.
  3. go to RDS consoleIn the next window, under the "Connectivity Information" section, click on "View in RDS Console" next to the DB endpoint name.
  4. RDS consoleAfter the RDS console page loads, select the RDS instance name that matches the DB endpoint from the previous pages, then click on "Instance Actions" and select "Take DB Snapshot".
  5. take snapshotWhen prompted for it, give the snapshot a name that you will recognize, like "t1-to-t2-migration" and click "Take Snapshot".
  6. creating snapshotWait until the snapshot has finished being created. You’ll see the status change to "available" and progress show 100%.

Start launching a new Elastic Beanstalk environment

Important note: You will need to launch the new Elastic Beanstalk environment from the same region as your old environment (e.g., "US East (N. Virginia)", "US West (Oregon)", etc.).

  1. launch newGo back to the Elastic Beanstalk application home page, click "Actions" and select "Launch New Environment".
  2. When prompted for the environment type, select the appropriate configuration that matches your old environment and then click "Next". In my case, that is a "Web Server" environment with a PHP configuration and a single instance.
  3. app versionIt will then ask you for the application version to use. This represents the pushed git version that you want to use, and you should select the last one you published to your old environment so that it will be duplicated to this new environment. The latest version of your old environment is probably already selected if you only have one environment in that Elastic Beanstalk application. Then click "Next".
  4. env nameEnter a name for this instance, such as the same name as your old one, but with "-t2" appended to it. Then click "Next".
  5. resourcesThis next step is important! When prompted with the "Additional Resources" page, you must select "Create this environment inside a VPC" if you want to use t2.micro. You must also select "Create an RDS DB Instance with this environment" if your environment has an RDS instance automatically associated with. Then click "Next".
  6. config detailsOn the "Configuration Details" page, select "t2.micro" for the instance type, the same EC2 key pair that was used with the old t1.micro environment and your email address. Click "Next".
  7. On the "Environment Tags" page, do not change anything, just click "Next".
  8. RDS configOn the "RDS Configuration" page, we will now select the database snapshot that was created in the previous section. For "Snapshot", select the snapshot you created. Select the exact same DB engine, Instance class, Allocated storage, Username, Password, etc. that you used for your old environment’s RDS instance. Then click "Next".
  9. no VPC yetNow you will get to the "VPC Configuration" page. Leave this browser window as-is, and open up a new browser window. In the new browser window, continue with the next section for creating and configuring a VPC.

Create and configure a VPC

  1. start VPC wizardIn the list of AWS services, click on "VPC". Then click on the button "Start VPC Wizard"
  2. select single subnetKeep the default option "VPC with a Single Public Subnet" and click "Select".
  3. subnet configFor the subnet configuration, use the default values for IP CIDR block, Public subnet, Availability Zone, Subnet name, etc. The only field you should need to change is the VPC name, give it a name that makes sense, like the name of your Elastic Beanstalk environment name with "-vpc" appended. Then click "Create VPC".
  4. select subnetsYou now need to create multiple subnets for the VPC you created. These subnets are what the different resources associated with your t2.micro instance will use. If your new Elastic Beanstalk instance is only using a single availablility zone, then you only need to create 2 subnets. However, you should create 4 subnets anyway, so that in the future you can easily change your t2.micro instace to use multiple availability zones. Start by clicking "Subnets" in the left-hand column.
  5. create subnetYou will see that one subnet has already been created (named something like "Public subnet", so we only need to create three more. Take note of what Availability Zone this existing subnet uses. Of the three subnets you are going to create, one of them should be the same as this one, and the other two should match each other with a different zone. Click "Create Subnet". Give it a name similar to the existing one, such as "Public subnet 2". From the VPC drop-down menu, select the VPC that you just created. Change the Availability Zone to one of the options listed, instead of using "No Preference" — for the first one you should select the same availability zone as the "Public subnet" that already exists. For the CIDR block, use the same CIDR that the original subnet uses, except increment the 3rd number by one. For example, if the original subnet uses, then set this new one to Then click "Yes, Create".
  6. four subnetsCreate two more subnets (for a total of four), this time using a different availability zone than was used for the first two, but these last two should both be set so they match each other. Give them names like "Public subnet 3" and "Public subnet 4". Increment the CIDR blocks like you did before, now using something like and When you are all done, you will see four subnets, each with a different CIDR, where two subnets share one availability zone and the other two subnets share a different availability zone.
  7. route tablesNow you need to update the route tables so that the original VPC route table includes the subnets you just created. While still looking at your list of subnets, take note of the Route Table name that the first subnet uses (it will probably be a different Route Table name than what the other three subnets use). Then click on "Route Tables" in the left-hand column and click on the Route Table with the same name/ID as what you just took note of. Then in the bottom section of the window, select the "Subnet Associations" tab and click the "Edit" button.
  8. save routesPut a checkmark in the three "Associate" checkboxes for the subnets you created. Then click "Save".

Finish launching the Elastic Beanstalk environment you previously started

  1. Now that you have finished creating the VPC, go back to the window where you started creating a new Elastic Beanstalk environment. You should be at the "VPC Covnfiguration" page where you left off. Next to the VPC drop-down menu, click "Refresh", and your new VPC should appear in the list. Select the VPC that you created.
  2. vpc config singlezonevpc config multizoneA table will appear asking you to select subnets for EC2 and RDS (and ELB if you are creating a multi-zone availability environment). Corresponding to the availability zones and subnets we created for the VPC, you will see 2 availability zones that each have 2 subnets. For each availability zone, choose RDS for one subnet and EC2 for the other subnet. If you are doing a multi-zone environment and have to make ELB selections, then choose ELB for the subnets that do not have EC2 selected. Then click "Next".
  3. The last page is provided to review all the settings you have selected. Click "Launch".
  4. Wait until your new environment has started and is in a "green" state. This will probably take a really long time (more than 10 minutes), since it is going to now make a copy of the database snapshot you created, and then immediately create a new automatic snapshot of the new database. Even though it is green, it will not work yet until you do two remaining things: (1) update your application to point to the new database endpoint instead of the old one, and (2) update your git environment to point to the new Elastic Beanstalk environment, commit your changes and aws.push the application to the new environment.
  5. Go to the source code for your application. Change all references to the old RDS database endpoint to the new database endpoint that you created. If your application is WordPress, then you only need to change the defined DB_HOST value to the new database endpoint in the wp-config.php file. Note that the endpoint here should not include the port number (e.g., 3306).
  6. In your source code environment, go into the file ".elasticbeanstalk/config" and change all references from the old Elastic Beanstalk environment name to the new environment name. Example of change:
  7. Finally, push your changes to your Elastic Beanstalk instance. Do this in the way you normally do (e.g., adding the changes to your local repo, committing them, and then "aws.push"). When you push the changes, they will now get pushed to your new environment, and the updates to the database endpoint means that it should now be able to retrieve the data from the new database.
  8. live linkOnce you have pushed and the new environment has successfully started, it should now be fully functional. From your new Elastic Beanstalk environment’s dashboard page, click on the link near its name that will take you to the live site.
  9. cname aliasIf you are satisfied that everything works as you want it to then you can now update your DNS records so that the appropriate CNAME records for your domain name will point to your new *.elasticbeanstalk.com address (the live address from the previous step).
    swap URLsOr, if you prefer to not change the CNAME records, you can use the "Swap URLs" feature from the Elastic Beanstalk application dashboard. Note that using the "Swap URLs" feature only swaps the URLs, and not the environment names, so you should leave the ".elasticbeanstalk/config" file with the new environment’s name in it.

2 thoughts on “Migrate AWS Elastic Beanstalk from t1.micro to t2.micro”

    1. Actually, as described in my post, that doesn’t work…

      Simply changing the instance from t1.micro to t2.micro in the instance’s configuration page does not work because t1.micro and t2.micro use different hosting backends that are incompatible with each other. The t1.micro instance uses “paravirtual”, while t2.micro uses “hvm”.

      If you try doing what you mention, you’ll see that it doesn’t work. Unless perhaps Amazon has updated their services to support that transition now. But there are some pretty fundamental differences between t1.micro and t2.micro that have prohibited this transition directly in the past.

Comments are closed.