Multiple IP Addresses for EC2 Instances | Hacker News Reader

Multiple IP Addresses for EC2 Instances

aws.typepad.com

68 pointsjeffbarr28 comments

Seems like this is only for Virtual Private Cloud (VPC) users, unavailable for us who uses EC2 on public cloud.

You can create your own public cloud on AWS VPC.

This is definitely a useful feature (even more powerful when combined with route53); and $44 a year per IP address isn't too shabby either. I'm curious if this is a way to try to stay ahead of Azure's plans to try to corner hosting with their Web Sites feature (eg http://blog.ntotten.com/2012/06/08/three-more-things-about-w... )...

I read that link and I'm wondering what I'm missing?

This looks like some attempt by Microsoft to compete with low-end shared hosting, right? Amazon has never been in that market, and has never shown any interest in heading that way.

Additionally, it isn't clear why anyone would choose Azure for that if they were building a website from scratch.

The only compelling use-case seems to be people who have a .NET website they need hosting for (.NET hosting doesn't seem as competitive as other environments). Yes, Azure does support other environments, but there isn't anything particularly compelling about Microsoft's offering for anything except .NET. If you add in a reserved instance even the pricing isn't very good.

I wonder if Heroku will lower the prices in SSL now -> https://devcenter.heroku.com/articles/why-does-ip-based-ssl-...

FWIW, They already have: https://addons.heroku.com/ssl (I believe their new offerring just uses ELB under the hood)

Using ELB to achieve this means they are doing SSL termination on the ELB itself which means the request is no longer encrypted within heroku, unless of course they are using another cert for the connection between ELB->dynos.

Not necessarily, you can use an ELB to pass through the TCP connection and terminate at the instances

But if the instances also live on ec2 (which they do in the heroku case), you would still run into the issue of needing separate instances to terminate SSL on for each SSL enabled site (with the 1 IP limit). It would seem much more economical for them to terminate at the ELB level and only pay for an ELB per customer.

I guess alternatively you could leverage the funky port forwarding hack on elb and put each ssl site on a different backend port. but that just seems like a mess.

Gah. When are they going to enable this for public cloud customers?

Likely never. Amazon has made it pretty clear that VPC is where all the new networking features go.

You can create a VPC and then add an Internet Gateway to it, making instances on particular subnet(s) of your VPC accessible from the Internet.

http://docs.amazonwebservices.com/AmazonVPC/latest/UserGuide...

Does this meet your needs?

That is really quite convoluted for what should be a simple process

One issue I have with VPC is that instances don't get public IPs by default like public cloud instances do. Instead you have to attach EIPs, which has extra complexity (esp. taking care to deallocate them if you don't care about persistence), and you're limited to only 5 EIPs by default. I know you can request to increase the limit, but I have no idea what the approval process is like, and it seems completely silly when you can get as many public IPs as you want by launching multiple public cloud instances.

(If you're curious, my architecture requires hosts outside of AWS to connect directly to EC2 instances. Using a NAT box inside VPC would likely introduce a bottleneck. I don't need multiple IPs per instance, but I just wanted to provide some feedback as to why VPC with an Internet Gateway feels inferior to public cloud EC2 for me. Thanks!)

We (AppHarbor) haven't had problem getting additional public IP addresses, just ask.

Getting approved for additional public IP addresses is very easy. We were approved for 10x more IP addresses within 24 hours.

We requested it for public instances years ago. VPC doesn't help.

Why would you not want to use VPC?

The main reason I can think of is the single point of failure in regards to a NAT instance. With the only other alternative being giving EIPs to every host that needs internet access. I would like to see a more robust solution and HA for the NAT instance. Especially if you're doing any kind of heavy proxying, couldnt you max out the NAT instance's uplink at some point? Anyone have ideas?

Use ELB instead of a NAT instance?

My scenario was load testing, to generate 1M outgoing connections we need 17 IP aliases, aliasing doesn't work on EC2, so we had to spawn 17 instances just for this.

I didn't tried elastic IPs for this, not sure it will work for outgoing connections.

i guess this was one of the most requested features of EC2

i've wanted this for years, excellent news

Am I the only one who thinks this would be a lot less complicated without NAT?

Anyone know where I can find the interface/ip limits per instance type?

here: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/in...

Reply on news.ycombinator.com