This is second repost in series that covers various details of migrating services from traditional data center to AWS. You can find this and other post from my personal blog https://carriagereturn.nl/
Problem
I’ve been working on lift-and-shift -migrations from on-premises data center to AWS. In these projects you often find workloads that have been running for a fairly long time with minimal changes and not all “modern IT” practices can not be taken for granted.
One such practice is using DNS to find server IP address. It is not that uncommon to find an application with clients connecting to server with IP address. And when moving the server from data center to AWS VPC, IP address is going to change because typically it is not possible to move the whole network in one big bang and reuse data center CIDRs for AWS VPC.
So how could clients keep connecting to the old IP address, until they have been reconfigured?
Solution
Sometimes an old idea can be repurposed for a new use-case. I was thinking the problem of rerouting the legacy server IP to EC2, when I remembered the post of Thinking outside of the VPC where I described a pattern of using IP address outside of VPC CIDR. The Goal at the time was to implement a virtual IP that could be “assigned” to EC2 instances across multiple subnets and AZs. Could the same technic be used for routing data center IPs to EC2s? It turns out it could!
Here is how to reroute a single IP address from data center network to an EC2 instance in VPC.
In the on-prem router, route the legacy server IP 1.2.3.4/32 to AWS Direct Connect or VPN.
Next is the Transit Gateway attached to target VPC. In the diagram it is drawn on the same account and region as the target VPC but it would work also across AWS accounts and regions. In Transit Gateway route table add a static route for 1.2.3.4/32 to attachment of target VPC.
In VPC Subnet route table add a static route for 1.2.3.4/32 to the new server instance ID.
On EC2 instance OS level, define the secondary IP address 1.2.3.4/32 for the network interface.
Disable EC2 instance Source/Destination Check to so packets to 1.2.3.4/32 can reach it.
Limitations and side effects
Nice side effect of above is that the EC2 instance will answer on both old and new IP address. This means the clients can be reconfigured to new IP address (or maybe even start using DNS) one by one. When all of them are using the new IP address, static routes for legacy IP address can be removed from Transit Gateway and VPC route tables.
Obviously this isn’t the solution for rerouting IPs in large scale. Route tables can easily grow very complex and pretty soon hit the default limit of 50 routes in VPC route table. While the limit can be increased up to 1000 routes, it will have a negative impact on VPC network performance.
If the instance ID will change, static route in the subnet route table must be updated. When using Auto Scaling group of 1 instance, to ensure server will stay running, it will become a bit more complex as code for route table update must be included in server start-up routine. This is also limited to routing to EC2s and ENIs. That is ok for most lift-and-shift workloads, but not suitable for cloud-native architectures.
Top comments (0)