How Are Public IP Addresses Assigned to EC2 Instances?
Brien Posey cuts through the confusion associated with allocating IP addresses to EC2 instances on the Amazon cloud, which is done automatically though users can also associate elastic IP addresses with instances.
One of the more confusing aspects of working with AWS EC2 is that of IP address allocations. EC2 instances are automatically assigned a public IP address, and yet Amazon also allows you to associate elastic IP addresses with instances. In this blog post, I will show you why that is.
Let's start out by taking a look at what happens when you create an EC2 instance. If you look at Figure 1, you can see that Step 3 of the instance creation process includes an option to automatically assign a public IP address. This option is configured by default to use the subnet setting, which usually means that the instance will be automatically assigned a public IP address unless you tell AWS not to give it one.
So with that in mind, take a look at Figure 2. This figure shows an EC2 instance that is still in the process of being created. The Instance State is shown as Pending, and the Status Checks column indicates a status of Initializing, thereby signaling that the instance is indeed still in the process of being created. Even so, we can see that a public IP address has been assigned to the instance (18.104.22.168). Keep in mind that I did not actually do anything to assign this IP address to the instance. The instance was created using default options and AWS assigned the public IP address to the instance automatically.
This raises the question of why Amazon automatically associates IP addresses with new instances? The main reason is manageability. Imagine trying to remotely manage a Windows virtual machine instance without being able to establish an RDP session. Even if you were to use PowerShell based management, you would still need a viable IP communications path. The same thing goes for Linux VM instances. The VM would need to have a public IP address if you were to establish an SSH session.
Before I move on, I want to show you one more thing to underscore the fact that the IP addresses that AWS EC2 assigns to virtual machine instances truly are public. If you look at Figure 3, you can see an instance displayed within the EC2 console. For the most part, I created this instance using the default configuration. The only thing special that I did was to add a security group rule (a firewall rule) to allow HTTP traffic over Port 80. I then logged into my newly created Windows instance and installed the Internet Information Services (IIS). As you can see in the figure, I was able to access the server's default web page by entering the instance's IP address into a web browser. This confirms that the instance's automatically assigned IP address truly is public.
So if Amazon assigns public IP addresses to EC2 instances by default, where do elastic IPs fit into the picture? Elastic IPs are useful in situations in which you need to have some measure of control over your IP addresses. To show you what I mean, go back and take a closer look at Figure 2 and Figure 3. Both figures show the same EC2 instance. You can confirm this by comparing the Instance ID across the two figures.
The reason why the IP address is different from one figure to the next is because I stopped and then restarted the instance after taking the screen capture shown in Figure 2. Any time that you stop and restart an EC2 instance, it's IP address changes.
Having an IP address that is constantly changing is fine if you are simply using the IP address as a means of being able to remotely manage the virtual machine instance. However, some production workloads require a static address.
This is where elastic IPs come into play. An elastic IP is a static IPv4 address. When you associate an elastic IP with an instance, that instance retains the same IP address even if it is rebooted. Additionally, elastic IP addresses can be disassociated from one instance and then assigned to another. This can come in handy in workload migration scenarios because you can set up a new server ahead of time, and then perform a cut-over migration simply by moving the elastic IP address from the old server to the new server.
All of this is to say that both the automatically assigned IP addresses and elastic IP addresses are public. The difference between the two is that elastic IP addresses are static, whereas the automatically assigned IP addresses are highly dynamic and are relinquished any time that an instance is powered off.
Brien Posey is a 20-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.