Recent AWS Customer Success Stories & Videos

More AWS Customer Success Stories...

« Just Three More Days to Enter the AWS Start-Up Challenge | Main | Servers for Nothing, Bits for Free »


TrackBack URL for this entry:

Listed below are links to weblogs that reference Keeping Customers Happy - Another New Elastic Load Balancer Feature:


Feed You can follow this conversation by subscribing to the comment feed for this post.


Amazing! I just requested this feature a few days ago and someone suggested I setup https to forward to port 8080. Well I did and that worked fine but I'm very impressed with how quickly you added this feature! Great job guys!

Jesper Mortensen

What you have implemented here today is the industry-standard way of preserving HTTPS protocol information. Every load balancer with SSL termination can do this, and almost every customer needs this.

Quote: "I am happy to ... that we were able to turn this request around very quickly" and "team that can turn on a dime". That language irks me a little. _Not_ having this working in the first release of SSL termination on ELB was a design blunder; you're fixing something that should have worked when SSL termination on ELB was introduced.

OK, so it's fixed now, and SSL termination via ELB is usable now. That's good news.


w00t! We'll be converting to ELB and using this feature soon!

Eric Hammond


Wow that's fast. I only asked that like 10 days ago : )
Now if you also let us win the startup challenge, I could probably hook us up with some Best Friends Forever bracelets. Just saying.


How about adding ports to ELB? Port 25 for load-balancing inbound mail would be pretty useful.


update to anyone reading my prior comment: the AWS team updated ELB to allow for arbitrary ports a few revs ago. last time I checked it was HTTP ports only, but no longer!


when can we have the ability to update the ports for an existing ELB? similar to what we can do to 'Security Groups'.


How do you know that the X-Forwarded-Proto and X-Forwarded-Port headers are coming from your ELB and not some other client/server with malicious intent?

Because there is no way to setup a security group that only allows traffic from an ELB (because there is no fixed IP for an ELB), you have to open up all IPS (or 10.X.X.X) on your instances behind the ELB.

So someone could easily inject those headers to "trick" your web server into thinking the request was coming from an HTTPS request when it was not...

Is there a workaround/solution for this scenario? Feature request: I'd REALLY like to setup a security group that blocks all HTTP/HTTPS traffic except that coming directly from my ELB (drastically cuts down on DOS/DDOS attacks...). I understand why this feature is slow to come as it will be difficult to implement.


While I'm asking for features :)...

Can you also entertain the idea of exposing the fact you can add an instance to multiple load balancers in the AWS console GUI for ELB?

You can do it via command line tools/api - would be nice if it was exposed in the GUI (today it only allows you to select instances that are not already associated with an ELB).

Reason this multi ELB association is needed is cuz an ELB can only accept one ssl certificate. If you have instances that serve multiple domain names (each with their own ssl cert) - you need to make 1 ELB per cert, and point each ELB to the instances.

Another way to solve the problem (and save customers money) would be to allow an ELB to handle multiple certs...


Hi Jeff

What port are you talking about: the client-side TCP port, or the server-side TCP port?

Jeff Barr

DingDong - The server-side port of the original request.

The comments to this entry are closed.

Featured Events

The AWS Report

Brought to You By

Jeff Barr (@jeffbarr):

Jinesh Varia (@jinman):

Email Subscription

Enter your email address:

Delivered by FeedBurner

April 2014

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30