The new VPC for our WordPress application is almost ready. The only thing that is missing is migrating WordPress itself to the new VPC.

To do so, we’ll recreate the launch template to launch WordPress into the new VPC. In this lesson, we’ll also learn how to perform multiple steps at once using a bash script and variables to store intermediate results.

Why recreate the launch template?

First of all, why do we even need to recreate the launch template?

The only thing that changed is the VPC and its security groups. Even though we referenced the security groups by name in the launch template, this only works for the default VPC, not for custom VPCs. This is a slightly annoying limitation of AWS and its handling of VPCs.

> Remember: You can only refer to security groups by name within the default VPC, not in custom VPCs.

Therefore, we need to recreate the launch template and add the security group IDs of the new VPC to it. We also need to specify a subnet from the new VPC to make sure that our WordPress instance will be launched in the correct VPC.

Steps to recreate the launch template

To recreate the launch template, we need to perform the following steps:

  1. Gather all information we used in the original launch template—AMI ID and EC2 user data.
  2. Get the IDs of the new security groups: ssh-access and https-access.
  3. Get the ID of the subnet-public-a to launch the WordPress instance into it.
  4. Add some extra information through tags to make it easier to identify the resources we create with this launch template.
  5. Recreate the launch template.

Step 1: Get AMI ID and EC2 user data

The first step is easy because we can easily extract the AMI ID and the EC2 user data from the current launch template. We can reference our current launch template by its name: custom-wordpress. We can then store the AMI ID and the EC2 user data in the environment variables AMI_ID and USERDATA.

The command to extract the AMI ID is the following:

Get hands-on with 1400+ tech skills courses.