Migrating stacks from Amazon EC2-Classic to a VPC - AWS OpsWorks

Migrating stacks from Amazon EC2-Classic to a VPC

Important

The AWS OpsWorks Stacks service reached end of life on May 26, 2024 and has been disabled for both new and existing customers. We strongly recommend customers migrate their workloads to other solutions as soon as possible. If you have questions about migration, reach out to the AWS Support Team on AWS re:Post or through AWS Premium Support.

This topic describes how to migrate an AWS OpsWorks Stacks stack from the Amazon EC2 Classic network platform to an Amazon Virtual Private Cloud (Amazon VPC) network.

If you created your AWS account before 2013-12-04, you might have support for EC2-Classic in some AWS Regions. Some Amazon EC2 resources and features, such as enhanced networking and newer instance types, require a virtual private cloud (VPC). Some resources can be shared between EC2-Classic and a VPC, while some can't. To avoid disruptions to your service, we recommend that you migrate your AWS OpsWorks Stacks stacks to a VPC.

Prerequisites

Before you begin, you must have a VPC that meets AWS OpsWorks Stacks configuration requirements. To configure private subnets in your VPC for AWS OpsWorks Stacks, see Running a Stack in a VPC in this guide. You can create a custom VPC by using the Amazon VPC management console. For more information, see Amazon VPC console wizard configurations and VPCs and subnets in the Amazon Virtual Private Cloud User Guide.

To continue with migration, you'll need the VPC ID and the subnet ID that you want to use.

Migrate an AWS OpsWorks Stacks stack to a VPC

First, clone an existing EC2-Classic stack by using the AWS OpsWorks Stacks console or API. Then, move the existing stack's resources to the new stack. Start the new instances in the cloned stack, and deploy apps. Verify that the new stack is working. Finally, delete the EC2-Classic resources from the EC2-Classic stack, and then delete the old stack.

  1. Clone your existing EC2-Classic stack into your VPC. Cloning the stack copies stack settings, layers, apps, users, and user permissions to the new stack. For more information about how to clone a stack, see Clone a Stack in this guide.

    You can also clone a stack by using the AWS OpsWorks Stacks API. When you clone a stack by using the AWS CLI or AWS SDKs, set the value of the VpcId parameter to the ID of the VPC that you created in Prerequisites. For more information, see CloneStack in the AWS OpsWorks Stacks API Reference.

  2. Create new instances in the layers of the cloned stack. Be sure to specify the ID of the subnet you created in Prerequisites. For more information about how to create instances in a stack, see Adding an Instance to a Layer in this guide.

  3. Migrate your classic resources, such as EC2 security groups, Elastic Load Balancing load balancers, and Elastic IP addresses to your VPC, and then associate them with the cloned stack. For more information, see Migrate your resources to a VPC in the Amazon EC2 User Guide.

  4. Register Amazon EBS volumes and Amazon RDS instances with the cloned stack. For more information about registering resources with a stack, see Registering Resources with a Stack in this guide.

    Amazon EBS volumes aren't associated with a VPC, and you can use them across instances in both EC2-Classic stacks and stacks in a VPC. You can register Amazon RDS instances in EC2-Classic with both EC2-Classic stacks and stacks in a VPC.

  5. Start instances in the cloned stack, and then move a small percentage of your workloads to the cloned stack. For example, move a small percentage of traffic to the Elastic Load Balancing load balancers in the cloned stack. If you are using Amazon Route 53, see Routing traffic to an ELB load balancer in the Amazon Route 53 Developer Guide.

    Route only a small percentage of traffic until you are sure that the new stack is functional and supports your applications. Let the new stack work with a small percentage of traffic for a trial period, such as a week. After you verify that the new stack is working, route remaining traffic to the stack.

  6. After you are sure the cloned stack is working, move the remainder of your production traffic or workloads to the cloned stack. You can now stop instances in the EC2-Classic stack. We recommend that you keep the old stack available for several weeks, so you can move workloads back to the old stack if any issues occur with the new stack in the weeks after the migration.

  7. When the new stack has been working for several weeks, delete instances in the EC2-Classic stack. For more information about how to delete instances, see Deleting AWS OpsWorks Stacks Instances in this guide.

    Important

    Do not use the Amazon EC2 console or API to stop or delete AWS OpsWorks instances.

  8. Delete apps in the EC2-Classic stack. For more information about how to delete apps, see To delete the app from the stack in this guide.

  9. Delete the EC2-Classic stack. For more information about how to delete a stack, see Delete a Stack in this guide.

See also