carloscastilla - Fotolia
Enterprises often overlook IP address issues during workload migrations from a local data center to the public cloud.
Your cloud provider and the activity of your cloud instance typically limit IP address ranges and availability, so the address that your workload uses in the public cloud is usually different than what you use on premises -- and often dynamic.
For example, when you migrate an in-house service, such as a web server, to a public cloud, like Amazon Web Services, you'd ideally want the in-house service's IP address to move with the migration and for the public cloud instance to adopt that address. But this simply doesn't happen. Instead, public cloud providers possess a limited pool of internal and external IP addresses, such as virtual IP addresses for services and instances, that are applied to workloads. Users cannot simply force an on-premises IP address to route properly to a cloud provider.
Adding to IP address issues is the fact that providers typically assign them dynamically. Once an instance stops, the cloud IP address can change when the workload restarts. All of this is even more troublesome when other workloads need access to the newly moved workload. For example, if that newly moved workload is a database or another back-end system that other workloads need, those other services are now unavailable because they can no longer locate the moved service at its new IP address.
However, there are several tactics to help ease this transition and avoid major IP address issues.
First, public cloud users typically have some level of control over the IP address assigned to their instances. For example, some customer-facing services, such as a web server, require a static IP address, and cloud providers usually make a provision for static IP assignments to ensure the address won't change as the instance reboots. Even though the resulting address is unlikely to match your original on-premises IP address, you can at least pick an IP address and know that it won't change throughout the lifetime of the instance.
Second, after you choose the new cloud IP address for the newly moved workload, update the public domain name system (DNS) to the new address. A short time-to-live designation in the update request ensures that the update migrates across the internet quickly. Once you update the public DNS entries, subsequent references to the service points to the public cloud provider.
Explore new options for Azure migration tools
Steps to choose the best public cloud instance type
Cost containment, governance the next big cloud challenges