Amazon Web Services Tips
No Title[an error occurred while processing this directive]
Reference: Cisco: Internetworking Basics
Amazon Web Services (AWS) provides the ability to associate (map) a static IP address with a running EC2 instance through the use of an Elastic IP addresses. An Elastic IP address is a static IP address which you can allocate and assign to any one of your running EC2 instances either through the AWS Management Console or using the Amazon EC2 API Tools. By default, your account is limited to 5 Elastic IP addresses per region and only one Elastic IP address can be assigned to an instance. On a normal startup, every instance will come with a private IP address and a dynamic Internet routable public IP address. When an Elastic IP address is associated with an instance, it replaces the dynamic public IP address. Because an Elastic IP address is associated with your account and not permanently with a particular instance, you are able to quickly and efficiently mask instance or Availability Zone failures by associating the Elastic IP address to any surviving instance under your account. Associating an Elastic IP address to an instance is a manual process that can take several minutes from when you instruct Amazon to associate the IP address to fully propagating through their system of network devices.
With all of this flexibility and ease of use, there is one feature to be cognitive of. When an instance is stopped and then restarted, the Elastic IP no longer gets associated with the instance. When the instance is started again, the default action is to assign another dynamic IP address (and new hostname) to the public IP address from DHCP instead of the previously associated Elastic IP address.
In this guide, I present one approach that can be used to automatically associate an Elastic IP with an instance on startup using an EC2 startup script and user data. The example in this guide will be performed on an Amazon EBS-backed instance running CentOS 6. In addition to associating the Elastic IP address, I will also be setting the hostname.
Throughout this guide and in practice, keep in mind that an Elastic IP address is free of charge while it is associated with a running instance. However, if an Elastic IP address is allocated and is not associated with an instance, the cost is $0.01/hr at the time of this writing. The reason for this charge, as Amazon states, is because public (IPV4) internet addresses are a scarce resource and they want to encourage users to efficiently use Elastic IP addresses by imposing a small hourly fee if an Elastic IP address is allocated but not assigned to an instance. In theory, Amazon believes by imposing a small hourly fee that users will not hog unused public IP addresses that could be dynamically allocated to other users.
Perform the following prerequisites on the target EC2 instance.
Install the Amazon EC2 Tools on the target instance. The EC2 startup script (discussed later in this guide) will make use of the Amazon EC2 API Tools to associate the Elastic IP address with a target instance.
The EC2 startup script used in this guide will need access to your X.509 Certificate. Make certain that your X.509 Certificate (private key file and certificate file) are copied to the appropriate directory on the target instance.
If you have not already done so, allocate a new Elastic IP address for your account using either the AWS Management Console or the Amazon EC2 API Tools. Before allocating a new address, always check AWS for any Elastic IP addresses that may be allocated already. In this example, I am starting fresh with no previously allocated Elastic IP addresses.
When you launch an instance, you can specify user data that will be passed in and queried by the instance to provide special configuration information for the instance during startup.
User data can be retrieved by a user or from a script from the EC2 user-data field on the metadata server (169.254.169.254) using curl.
In this example, I will be providing an Elastic IP address and static hostname in the user-data field for an instance which will be retrieved by a startup script (/etc/init.d/ec2-elastic-ip) to replace the dynamically created public IP address and hostname for the instance when launched.
Note that the user-supplied data in the user-data field is treated as opaque data; meaning that requests for user data is returned as-is (content type application/x-octetstream). It will be the responsibility of our script to interpret the returned data correctly.
Initially, I thought it would make the most sense to use tags to pass in the Elastic IP address and hostname as metadata instead of user data given its key=value nature. At the time of this writing, however, I learned that instance metadata does not contain tag information through the metadata API. (See Metadata Categories for the list of metadata categories)
Once you have an Elastic IP address, the first step is to shutdown the target EC2 instance if it is running. To change the user-data field for an instance, the instance needs to be stopped.
With the instance stopped, modify the user-data field for the instance. The user data will be available through instance metadata when the instance starts.
After configuring user data for the target EC2 instance, start it back up.
Once the EC2 instance is started, log in and do a quick check to verify the user data was passed in.
On the target EC2 instance, create a startup script that will retrieve the Elastic IP address and hostname from the metadata server (169.254.169.254) using curl. The Elastic IP address and hostname will be available in the user-data field that was configured and passed in to the instance in the previous step.
In addition to changing the Elastic IP address, I will also be changing the hostname for the machine in the startup script. You can change the hostname on the instance using the Linux hostname command and in the case of an Amazon EBS-backed instance running RHEL/CentOS/Oracle Linux, making the change persistent by updating the /etc/sysconfig/network network configuration file.
Create the following startup script on the target EC2 instance and update the runlevel information for the new system service.
Update the runlevel information for the new system service.
Once the startup script is in place and you have verified that the user data is being passed to the instance, restart the target EC2 instance.
At this point, it should be noted that associating an Elastic IP address or changing the hostname of the target EC2 instance will not effect your DNS in any way. Update your DNS by creating or modifying an A-record for the EC2 instance by supplying the static IP address and hostname so that the instance is accessible by other computers. Note that changing the hostname of the instance in the EC2 startup script only effects the "internal" hostname. Test your DNS using ping.
When the instance starts up, it should now be accessible using its associated Elastic IP address.
Jeffrey Hunter is an Oracle Certified Professional, Java Development Certified Professional, Author, and an Oracle ACE. Jeff currently works as a Senior Database Administrator for The DBA Zone, Inc. located in Pittsburgh, Pennsylvania. His work includes advanced performance tuning, Java and PL/SQL programming, developing high availability solutions, capacity planning, database security, and physical / logical database design in a UNIX / Linux server environment. Jeff's other interests include mathematical encryption theory, tutoring advanced mathematics, programming language processors (compilers and interpreters) in Java and C, LDAP, writing web-based database administration tools, and of course Linux. He has been a Sr. Database Administrator and Software Engineer for over 20 years and maintains his own website site at: http://www.iDevelopment.info. Jeff graduated from Stanislaus State University in Turlock, California, with a Bachelor's degree in Computer Science and Mathematics.
Copyright (c) 1998-2017 Jeffrey M. Hunter. All rights reserved.
All articles, scripts and material located at the Internet address of http://www.idevelopment.info is the copyright of Jeffrey M. Hunter and is protected under copyright laws of the United States. This document may not be hosted on any other site without my express, prior, written permission. Application to host any of the material elsewhere can be made by contacting me at email@example.com.
I have made every effort and taken great care in making sure that the material included on my web site is technically accurate, but I disclaim any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on it. I will in no case be liable for any monetary damages arising from such loss, damage or destruction.
Last modified on
Friday, 28-Sep-2012 20:09:59 EDT
Page Count: 446