Tips and Tricks While Migrating From AWS EC2-Classic to VPC

IT infrastructure is the backbone in every business. If you consider a business operating in the Software-as-a-Service (SaaS) area, then the infrastructure becomes the single most important part of your operations. Businesses need to use the best tools available to be able to deliver the best possible results. New software and network components not only deliver better results, but they also provide better security. Amazon’s VPC is one such example. Upgrading is always desirable, but this comes with its own set of challenges. One must consider the architecture design, cost implications and avoid downtime under any circumstance. It is important to understand the reasons and entire process of the upgrade before taking the plunge. 

Reasons to migrate to VPC:

• Better Security: VPC provides advanced security features such as more flexible security groups and access control lists to enable better filtering of traffic. Instances launched in EC2 have a public IP by default whereas instances launched in a non-default VPC do not have a public IP by default.
• Availability of better instance types: Many of the advanced instance types are only available in VPC and not in EC2. These new instances are also cheaper than the old instances of the same configuration.

• Simplify IP whitelisting for clients: Several companies only accept traffic from whitelisted IP’s. With EC2 Classic, each instance needs an elastic IP of its own. This requires the client to whitelist many IPs. Along with the IPs in use, if any buffer IPs are added in for future use, they accrue charges by the hour. That will add to the total cost. With the VPC, everything can be run through NAT gateways and assigned a single Elastic IP. Instances can be added below the NAT and there is no need to provision additional Elastic IP’s. 
• Availability of Application Load Balancer: Application Load Balancer is a more sophisticated ELB than the Classic Load Balancer. However, this is available only in a VPC.

Migration strategy:

• Piecemeal approach: Migration should be performed one component at a time. Move one component of the infrastructure to the VPC in the staging environment. After thorough testing, it can be moved to the VPC in the production environment. Ensure all the services / servers which connect to this component are working correctly after the move.
• ClassicLink: To achieve a piecemeal migration, there is a particularly important tool which is required. ClassicLink enables communication between EC2-Classic instances and instances which are launched in the VPC. This allows migration of one component at a time while ensuring that the components which have moved into the VPC can communicate with components which are still in Classic.
• Application servers or Data Servers: Which should be migrated first? Migration of the database is the most difficult task. Hence it is advisable to migrate that first. This needs to be done without any downtime. In our case we were using MongoDB, which allowed setting up a read replica in the VPC and then slowly moving the rest of the replica set with zero downtime. If your database does not support this, you could start with your application servers. You could also start moving non-critical services to gain some confidence and get a hang of the migration process.

Database Migration

This portion is primarily for those who are using MongoDB as their database provider. 

• Setup a subnet in the VPC for the mongo instances. Allow incoming connections to this subnet from classic linked instances.
• Start a read replica in the VPC in this subnet. Allow the syncing of data to this secondary machine.
• Once the data sync is successful, in a similar manner you could move one more machine into the VPC and then the arbiter node.
• Once most of your replica set has been moved into the VPC, you could promote one of the instances in the VPC to be the primary.
• Finish the migration, by moving the rest of the machines in a similar manner.

NAT instance vs Nat Gateway:

In a VPC, instances which are in the private subnet are totally cut off from the outside world. While they cannot be reached from the Internet, they cannot even access the Internet. This means that, if your application is sending some web-hooks to the outside world, they would not be able to do so. This is where NAT instances come in. A NAT instance forwards the traffic from instances present in the private subnet to the internet/AWS services and sends back the response from the server back to the instance.

AWS provides two options for NATting: NAT instances and NAT Gateways. NAT instances are basically self-managed EC2 instances with specially configured routing tables. NAT Gateways are fully managed by AWS. 

What should be used, a NAT instance or NAT Gateway?

• If you do not have a lot of outbound traffic and if this traffic is not overly critical, you could make do with NAT instances. However, you would need to manage fail-over between instances yourself. Economically, NAT instances are way cheaper than NAT Gateways.
• If you do not want the headache of managing the NAT instances, you should surely go for the NAT Gateway. But be prepared to shell out more in your AWS bill.
• An AWS article compares the two in more detail 

Cost-saving strategies:

• VPC Endpoints: Along with communicating with the Internet, your instances which are in the private subnet also might need to talk to AWS services like CloudFront, SQS, SNS etc. A NAT Gateway should be used for this. However, the traffic needs to leave the Amazon network which has a cost associated with it. With a VPC Endpoint setup, the traffic does not leave the Amazon network and is much cheaper.
• Newer instance types: VPC offers new instance types which are more efficient and cheaper.

Migration of any system needs a methodical approach. Only once the overall outcome is beneficial should the business opt for a new infrastructure. In case of the VPC it provides better security and instance types. The application load balancer is an added benefit with the VPC which is not available with the EC2 Classic. Last but not the least, whitelisting IPs is easier and cost effective with the VPC. Similarly, the instance types available with VPC are more efficient and cheaper than the EC2 Classic. There are few reasons why businesses cannot immediately transition to VPC, but they must make it their top priority to do so.