Before we understand how EC2 networking actually works, it is essential to understand the difference between networks provided by your traditional data centres and public clouds such as AWS. A traditional data centre network generally comprises a number of physical switches and routers that are connected to physical hardware and are responsible for transmitting and forwarding data or packets from one place to another.
The same also applies in the case of cloud computing; however, in place of the hardware, you now have virtual devices such as virtual servers, virtual network cards, virtual switches, and routers. However, the main differentiator between traditional and cloud based networks is that a cloud-based network is heavily filtered. Most public cloud providers, including AWS itself, allow only unicast datagrams over their networks, restricting all broadcast datagrams. Why, you ask? Well, mostly for security purposes and to avoid DDoS attacks, besides other reasons as well. This is an important point to remember, however, as often your applications may require broadcast capabilities over a network to discover some services and in such cases these applications may not necessarily fit on a public cloud. There are ways to get past this limitation; however, that is a different topic altogether. For now, let's take a look at how our EC2 instances are provided with their networks and IP addresses.
To begin with, each instance that you launch in your EC2 environment is provided with two unique IP addresses, called a private and public IP address, respectively. This is the default behavior of an instance and is not under your control by default, unless you are working with a VPC, which we will be discussing in the next chapter. When you first launch an instance, AWS will provide it with a unique private IP address using its own internal DHCP service. You can use this private IP address to communicate with the instances present in the same network; however being a private IP address, you cannot use this network for any communication with the outside (Internet) world. Along with the private IP address, you also get an internal DNS hostname for your instance. The internal or private DNS resembles something like this string, ip-172-31-46-172.us-west-2.compute.internal, and as you can see, it tells us a lot about our instance as well. For example, this particular private DNS hostname resolves a private IP of 172-31-46-172 and also this particular instance is currently deployed in the us-west-2 region. Neat, right! Let's take a look at the following screenshot, which shows example of a private and public IP address:
The same applies to the public IP address as well with the exception that this particular IP address is reachable from the Internet and can be used to communicate with the outside world. AWS maps the public IP address of an instance to its corresponding private IP address using simple NAT and, just like its counterpart, provides it with a public DNS value as well. The public DNS resembles something like this string, ec2-54-149-173-165.us-west-2.compute.amazonaws.com, and as you can see, this also provides us with similar information about the instance's public IP address as well as where the instance has been launched from.
Keeping these basics in mind, there are also a few additional pieces of information that you need to know about your instance's networking. You can control your instance's IP address to a big extent depending on whether they are launched from a standard EC2 environment or in a VPC.
In standard EC2 environment or as AWS calls it, EC2-Classic, you really don't have much control over your instance's networking. Each instance is provided with a single unique private as well as a public IP address and DNS, respectively. These values are released to the general IP pool when your instances are either stopped or terminated. You cannot reuse these IP addresses and DNS values once they are released to the general pool.
On the other hand, a VPC provides much control and flexibility when it comes to your instance's IP addressing. Using a VPC, you can define and run instances from specially created subnets, which can either be isolated (private subnets) or connected to the Internet (public subnets) depending on your requirements. You can additionally provide your instances with more than one private and public IP address as well using a VPC, something we will be looking at with great detail in the coming chapter. Instances in a VPC, however, do not release their private IP addresses back to the general pool when they are stopped.
AWS provides a few easy ways to determine your instance's IP addresses. The simplest by far is using the Description tab from the EC2 dashboard as shown here:
Select any particular running instance from the EC2 dashboard and view the instance's Private DNS, Private IPs, Public DNS, and Public IP. Since my instances are deployed in a VPC by default, you should see an additional row called Secondary private IPs as well. These are the additional private IPs that you can allocate to your instance as per your needs. If you don't see these additional rows, then don't worry! You are probably running your instances from an EC2-Classic account and that's fine for now.
Another way of listing your instance's network information is by using something called instance metadata. Instance metadata is simply data about your instance. Information such as your instance's AMI ID, instance's hostname, block device mapping, network details, and a lot more can be obtained by querying against the instance's metadata.
Tip
To know more about the various instance metadata categories and how to use them, go to http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html.
To determine your instance's IP addresses using instance metadata, simply connect to your running instance and run the following command:
# curl http://169.254.169.254/latest/meta-data/local-ipv4
You should receive your instance's private IP address, as shown in the following screenshot. In case you are wondering what's up with the 169.254.169.254 IP address, we'll try to keep it simple; it is a special-use IP address (also called a link-local address) used by EC2 to distribute metadata to your instances.
Similarly, you can list your instance's public IP address by typing in the following command in your instance:
# curl http://169.254.169.254/latest/meta-data/public-ipv4
You should receive your instance's Public IP address, as shown here:
Feel free to dig around with instance metadata and list down your instance's hostname, instance ID, security groups, and much more.
Okay, so each of your instances receives a public and private IP address and in standard normal circumstances these IP addresses do not persist with the instance when it is powered off. But what if you want to assign a static IP address to your instance? A static IP address that remains associated with your instance even if it is powered off? In that case, you will need to use something called an Elastic IP Address (EIP).
EIPs are nothing but a bunch of static public IP addresses that AWS allocates to your account, not to your instances. Each AWS account can be associated with up to five EIPs; however, you can always request AWS to provide additional ones as per your requirements and needs by filling out a simple request form. Your EIPs will remain associated with your AWS account until you choose to release them explicitly.
The really cool part of an EIP is that it can be reassigned to a different running instance dynamically as and when needed. For example, let's consider our initial use case, hosting a customer's website on AWS. As with all websites, this design calls for a web server and a database server to begin with. Assume that we created and allocated an EIP to the web server instance, as shown in the image here. This EIP can then be mapped to a proper website name, such as all-about-dogs.com, using any DNS service, such as AWS Route 53 and so on.
Now, if the web server instance undergoes any upgrades or maintenance activities, you can simply create a new, similar web server instance and point your EIP to it. Once the scheduled maintenance activity is over, simply swap the EIP back to the previous web server instance. Simple, isn't it! When you add an EIP to your instance, AWS automatically releases that instance's public IP address to the general IP pool. On disassociating the EIP from your instance, AWS will once again provide your instance with a new public IP address from the general IP pool. All this happens really quickly, just a matter of minutes!
How is an EIP charged? Well, for the first EIP that you attach to a running instance, you don't have to pay anything. However, you will need to shell out a minimum of $0.005 per additional EIP for each instance on a per hourly basis.
Let's look at few simple steps using which you can create, associate, and disassociate EIPs using the AWS Management Console!
To create an Elastic IP address using the AWS Management dashboard, first login to the dashboard using your IAM credentials and select the EC2 service option as EIPs are a part of the EC2 services. Next, from the navigation pane, select the Elastic IPs option. This will bring up the Elastic IP management dashboard as shown here. Since this is going to be our first EIP, simply go ahead and select the Allocate New Address option. In the confirmation dialog box, select Yes, Allocate to complete the process.
Your new Elastic IP is now ready to use! Remember, once again, that these Elastic IP addresses are associated with your account and bear additional costs with them, so use them wisely.
Once your EIP has been created, you can go ahead and allocate it to any running instance from your current EC2 scope. Scope here can mean either EC2-Classic or a VPC environment, depending on where your instances are currently deployed. In my case, the instances are all running out of a VPC, so this particular EIP can be associated with any instance currently running within my VPC. How do you tell the scope of an EIP? Well, that's simple! Select the particular EIP and view its details on the EIP management dashboard. You should see a column called Scope stating whether you can deploy this EIP in a VPC or an EC2-Classic environment.
To allocate the EIP, select the EIP, and from the Actions tab, select the option Associate Address, as shown:
You should see the Allocate New Address pop-up dialog box as shown. There are two ways in which you can allocate your EIPs to your instances, either by providing their Instance ID or by providing the instance's Network Interface information. Provide the Instance's ID for now and leave the Network Interface option blank. Optionally, you can even select the Reassociation checkbox if you wish to re-allocate an EIP from one attached instance to a new instance.
You will receive a warning message informing you that associating an EIP to your instance will release the current public IP attached to it. Accept the warning and select the Associate tab to complete the EIP allocation process:
Verify whether the EIP was successfully attached to your instance or not by viewing the status on the Elastic IP management dashboard.
Disassociating an EIP from an instance is an equally important task and can be performed quite easily using the EIP management dashboard. Select the particular EIP from the dashboard and from the Actions tab. Then select the Dissociate Address option. This will pop up a confirmation box detailing the EIP and its associated instance ID information, as shown here. Select Yes, Disassociate to complete the process:
On disassociation, AWS will automatically allocate a free and available public IP address to the instance from its general IP pool. There is no guarantee that your instance will receive the same public IP address as the instance had before the EIP was added as these public IPs are always circulated and assigned on a random basis.
To release the EIP back to the pool, select the EIP from the dashboard. From the Actions tab, select the Release Addresses option. You will be provided with a confirmation box describing the current EIP address. Select Yes, Release to complete the process, as shown:
