Amazon Elastic IP - Inter Region Migration Best Practices

Elastic IP (EIP) addresses are static IP addresses designed for Amazon Cloud infrastructure. Elastic IP addresses allow you to mask an Amazon EC2 instance or Amazon availability zone failures by programmatically remapping your public IP addresses to any EC2 instance associated with your account. Rather than waiting on a technician to reconfigure or replace your faulty EC2's, or waiting for DNS to propagate to all of your customers, EIP enables you to design applications with high availability in AWS infrastructure.
Though Amazon Elastic IP’s are associated with your account, they operate in Amazon EC2 regional scope meaning Elastic IP’s cannot be migrated or reused between AWS regions. This is normal because you cannot use the IP address assigned by your USA Hosting provider inside Singapore DC; you can only access it from internet if it is public facing. This applies to EIPs in Amazon EC2 regions as well. Let us explore some best practices and tips for migrating applications using Elastic IP’s between regions:

• Elastic IP are usually associated to EC2’s in the Front facing tiers like Web Servers, Load Balancers (Nginx, HAProxy) and Firewalls (Checkpoint, Sophos) and inturn are pointed in DNS. When you are migrating the traffic to different Amazon EC2 region, then these Elastic IP’s cannot be migrated instead your DNS entries need to re pointed to new set of EIP associated in the target region.
• Some practices that need to be followed during the migration of this scenario are:
• Update your time-to-live (TTL) value on your DNS that is pointing to the Elastic IP address with a suitable number such as 300 seconds or less for the DNS cache to expire. This way re association can be faster.This number can be increased to normal TTL values post the migration.
• If you use sophisticated Managed DNS providers like Ultra DNS, DynDNS etc you can pre-configure the ElasticIP’s of the target region LB or Firewall in their DNS entries and direct the traffic to target region within 30 seconds in event of DR scenarios or migration.
• In both the scenarios it is recommended to keep the TTL at suitable level for your use case, Since you will be charged based on number DNS requests by some DNS providers, any decrease in DNS TTL could result in an increase in number of DNS requests, increase load on your current DNS service, and increase your bill from your DNS service provider.
• Sometimes Elastic IP’s are associated to common services like Zookeeper, Chef Server, Nagios Monitoring Server, Discovery service EC2’s etc.  Since these common services need to be accessed from other EC2’s in several tiers of the application stack they need to be either associated with Elastic IP or internal DNS names for easy discovery. Some recommended practices that need to be followed during the migration of these scenarios are:
• It is recommended to use DNS host names instead of EIP for most of the internal node communications. You can discover common services using the DNS names instead of EIP. This way during migration or in event of DR you need not change configuration files and properties of all calling nodes with target EIP's.
• In case EIP is used for these services, it is recommended prior to migration from source region, you should ensure that all inter node communication using EIP’s are identified for remapping to EIP’s of the target region. This has to be done in CloudFormation templates, scripts, security groups,configuration files and all assets which are pointing to Source EIP.