We are evaluating to use Elastic IP on all of our ec2 instances, and we compare to the use of public EC2 hostname and Route53 (with a very short TTL to the public EC2 hostname & dynamic update DNS during instance boot).

We found out the use the EIP has no real value in fact, e.g.

  1. We can only use up to 5 EIP per region
  2. All the traffic thru EIP is counted as internet traffic, but for instance public hostname, when connecting from the internal network, it will be using internal IP which save us bandwdith/money
  3. You will also need to re-attach EIP after server stop/start, which is the same as re-attaching DNS for ec2 instance when the public hostname is changed.

Are there any important points I am missing?

  1. Amazon will happily lift this limit for you. In my experience, this only takes a few hours to go through.
  2. Correct, you should never use an EIP for internal EC2-to-EC2 traffic.
  3. Not if you use VPC (which you absolutely should if you're ever going to use more than a single standalone server). This also helps with point #2, as the internal IPs stay static through restarts/stops.
| improve this answer | |
  • The DNS name for elastic IP addresses will resolve to the internal IP address when the resolve request originates from the same EC2 network/region as the elastic IP. So this means, as long as you use the DNS entry, it will resolve to the internal IP where possible. See alestic.com/2009/06/ec2-elastic-ip-internal – Matt Houser Jul 16 '13 at 19:56
  • @MattHouser Sure, but that's not an IP, that's DNS. – ceejayoz Jul 16 '13 at 20:06
  • Exactly. It will resolve to the preferred internal IP address. That's the benefit of using the DNS name of the elastic IP address: externally it will resolve to the Public IP, internally it will resolve to the Internal IP. So have a Route53 A record point to the public IP address. But on your internal systems, refer to the instance by it's elastic IP DNS name (ec2-xxx-xxx-xxx-xxx...) and you'll get the cost-efficient internal IP. – Matt Houser Jul 16 '13 at 21:24

You have most of it. 3. is not quite correct as the EIP will still be associated with a stopped instance - it's only when you terminate the instance that the EIP will be released. You will also be charged a small fee for every hour an EIP is allocated but not assigned to an instance, so keep that in mind.

EIPs are designed for instances that don't live very long but yet you need a constant endpoint - such as computing database data and the like. This is because you can freely attach/detach them from instances in the same region (so, it can act as a failover).

Note that you will be charged Internet traffic if you use your public EC2 IP address (hostname resolves internally, so it'll work. Thanks ceejayoz) to connect between instances. Every instance has a private (10.x) address for inter-instance communication.

| improve this answer | |
  • 1
    "Note that you will be charged Internet traffic if you use your public EC2 hostname to connect between instances. Every instance has a private (10.x) address for inter-instance communication." This is wrong. The public hostname resolves to the 10.* IP within EC2's network. – ceejayoz Jul 16 '13 at 15:21
  • If you use the actual IP, then you will be charged. Sorry I wasn't more clear. – Nathan C Jul 16 '13 at 15:23
  1. The 5 address limit is a soft limit. If you need more, contact Amazon support and they'll give you more.
  2. If you use the actual IP address of your Elastic IP address, then yes, it will count as external traffic when done instance-to-instance. However, if you use the DNS name of your elastic IP address, then (where possible), it will resolve to the internal IP address of your instance. This way, it won't cost you money for traffic. See http://alestic.com/2009/06/ec2-elastic-ip-internal
  3. Elastic IP addresses need to be re-attached to classic EC2 instances, but this can be solved by using a start-up script. VPC instances will retain your elastic IP address through stops and restarts.
| improve this answer | |

I think the one point that hasn't been mentioned so far is that there are systems (like network access controls) that don't accept domain names in their configuration and require an IP address.

IMO that's the most important use case for EIPs: when you need to provide a service that needs to be registered somewhere with an IP address, and you need to be able to provide a failover switch for that service.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.