Look at the virtual machines (VMs) supplied by pretty much any cloud vendor (HP Cloud, Joyent, Rackspace), and you will see IPv4 addresses that look like this: 10.1.2.3. These endless pools of addresses starting with 10 are called private address spaces. All the big ISPs, telecoms companies decided to sidestep the IPv6 upgrade by using the private IPv4 address space workaround.

It’s been nearly two years since World IPv6 Launch Day (June 6, 2012), but IPv6 doesn’t seem to have made much of a dent on the cloud world. IPv6 addresses can be found — look at the interface of your new AWS EC2 VM, and you will see something that looks like this: fe80::2000:aff:fea7:f7c (read my IPv6 post for a breakdown of what that means).

IPv4 addresses are a scarce resource, so it seems a little crazy that all the big cloud vendors would prefer this protocol over IPv6, but they do. It’s worth knowing the difference between a private IPv4 address and a public IPv4 address.

How AWS assigns public and private addresses

Private IP addresses have been around for nearly two decades. The private address space workaround (the origin of all these 10 addresses) appeared in the 1990s, a few years before the upgrade to IPv6 idea. The IPv4 private space includes a few address ranges (network admins will know 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 well), but it’s the 10 range that is the most common in the cloud.

AWS reserves two addresses for a new EC2 machine. One IPv4 address is public and looks like this: 54.195.26.239. Internet clients can use the public address to get to the services you offer; you can’t see it because it is hidden in the murky depths of Amazon’s networking. The other address is plumbed into the machine and is private and looks like this: 10.234.190.190. This address will only work within the Amazon network; 10 addresses are not allowed on the internet.

A Network Address Translation (NAT) service sticks the two addresses together. Special translator computers sit at the edge of the Amazon network, rewriting the addresses of an endless stream of packets.

AWS creates a DNS name to go with each IP address like this: ec2-54-195-26-239.eu-west-1.compute.amazonaws.com. Put the whole lot together, and you get a list like this.

  • Public IP address: 54.195.26.239
  • Public DNS name: ec2-54-195-26-239.eu-west-1.compute.amazonaws.com
  • Private IP address: 10.234.190.190
  • Private DNS name: ip-10-234-190-190.eu-west-1.compute.internal

AWS uses dynamic names and addresses

When an IPv4 address is required for a new VM instance, an IP address is moved from Amazon’s big pool of spares and assigned to the new VM. When the machine is destroyed, the IP address goes back in the pool. But that’s not the only time you lose this address — when you stop and start an EC2 machine, all its names and addresses change.

It’s a dynamic system (i.e., addresses are subject to change), as opposed to a static system (i.e., you can rely on it remaining the same). If you are running a customer service using a dynamic public IP address, this is annoying behaviour. How can clients send messages to you if your address keeps changing?

Dynamic is a problem; AWS EIP is the answer.

There are several solutions. You can:

  • manually keep letting everyone know what the new address is, or
  • use an automatic dynamic DNS service to regularly change the address, or
  • rent a static IP address service from AWS.

Yes, Amazon does supply static IP addresses, and each one is called EIP (Elastic IP address). An EIP is a static public IPv4 address that you get to keep (for a price). AWS give you the self-service tools to obtain a new EIP, associate the EIP with any of your private IP addresses, and change your configuration as often as you want.

Some AWS commands for administering EIPs

Reserve a new EIP.

nick:~ $ ec2-allocate-address
ADDRESS 54.195.251.218 standard
nick:~ $

Remind yourself of the new address.

nick:~ $ ec2-describe-addresses
ADDRESS 54.195.251.218 standard
nick:~ $

You can also find your new EIP in the Network & Security section of the AWS management console.

Find the DNS name that matches this EIP.

nick:~ $ nslookup 54.195.251.218
Server: 10.0.1.1
Address: 10.0.1.1#53

Non-authoritative answer:
218.251.195.54.in-addr.arpa name = ec2-54-195-251-218.eu-west-1.compute.amazonaws.com.

Authoritative answers can be found from:

nick:~ $

Delete the new address.

nick:~ $ ec2-release-address 54.195.251.218
ADDRESS 54.195.251.218
nick:~ $

Associate with a VM.

nick:~ $ ec2-associate-address -i i-7febb93e 54.195.251.218
ADDRESS 54.195.251.218 i-7febb93e
nick:~ $

SSH will complain after you change the VM’s public address

If you use SSH, you will find the SSH command you have been using no longer works. The old public name (i.e., the one that looks something like ec2-54-5-6-7.eu-west-1.compute.amazonaws.com) has been replaced. The private name (ip-10-1-2-3.eu-west-1.compute.internal) does not change.

Here’s the procedure for using SSH to get back to your old VM with its new addresses. I’m using an ubuntu image in this example.

1. Copy the new public address.

2. Check the new public name.

nick:~ $ host 54.195.244.177
177.244.195.54.in-addr.arpa domain name pointer ec2-54-195-244-177.eu-west-1.compute.amazonaws.com.
nick:~ $

3. Use SSH with the new public name.

nick:~ $ ssh -i my-private.key ubuntu@ec2-54-195-244-177.eu-west-1.compute.amazonaws.com
The authenticity of host 'ec2-54-195-244-177.eu-west-1.compute.amazonaws.com (54.195.244.177)' can't be established.
RSA key fingerprint is 81:e4:00:0a:63:d2:c1:bc:05:a3:48:6d:df:2a:24:1a.
Are you sure you want to continue connecting (yes/no)?

4. Check the fingerprint has not changed. The public name has changed, but that fingerprint tells me I am still using the same machine.

5. Check the private name.

ubuntu@ip-10-34-241-176:~$ host ip-10-34-241-176
ip-10-34-241-176.eu-west-1.compute.internal has address 10.34.241.176
ubuntu@ip-10-34-241-176:~$

6. Log out.

We are stuck with 10 addresses. Maybe forever.

It’s worth getting used to this public/private split of IPv4 addresses. It may seem like using 10 addresses adds an extra layer of complexity whose only value is keeping network engineers in a job, but that complexity can’t be avoided.

This public/private workaround is going nowhere soon. Despite the technical sense of matching the near-infinite IPv6 address space with the near-infinite capacity of cloud computing, that’s not the way it worked out. Only the force of national government orders can get the big organizations to change, and that is unlikely to happen.