I've been running an ELB instead of HAProxy for about a month now on a site that gets about 100,000 visits per day, and I've been pretty pleased with the results.
A gotcha though (UPDATE, this issue has been fixed by Amazon AWS, see comments below):
You can't load balance the root of a domain as you have to create a CNAME alias to your load balancer. Once solution is to redirect all traffic from http://mysite.com to http://www.mysite.com.
Apart from that I really can't speak highly enough of the AWS ELB offerings. I'm also using the Cloudwatch monitoring and autoscaling. Oh and don't forget it's cheaper than running a small EC2 instance ($0.025 per hour instead of $0.10).
ELB 对 DNS CNAME 记录间接的依赖对于需要非常快的 Web 服务来说是相当严重的。 在我们的例子中，我们需要非常好的响应时间。 在快速性能测试中，使用 ELB 使 HTTP 请求的平均延迟增加了近 2 倍。这主要是因为 CNAME 查找的 TTL 为零。 因此，所有查找都涉及到两个不同域的名称服务器，因此名称解析速度要慢得多。 （我担心破坏 DNS 中的缓存只是对系统的滥用。）在我们的例子中，ELB 的唯一希望是通过让 Amazon 支持弹性 IP 作为负载均衡器实例的地址来摆脱 CNAME 记录。
ELB's dependence on DNS CNAME record indirection is pretty crippling for web services that need to be very fast. In our case we need to have very good response time. In a quick performance test, the use of an ELB increased the average latency for HTTP requests by a factor of almost 2. This is mainly because the TTL on the CNAME lookup is zero. Thus, all lookups involve hitting name servers for two different domains, so the name resolution is way slower. (I worry that defeating caching in DNS is simply an abuse of the system.) The only hope for ELB in our case would be to get away from CNAME records by having Amazon support an Elastic IP as the address of a load balancer instance.
Another issue is getting the client IP address. For regular HTTP this works fine, as ELB sets the X-FORWARDED-FOR header. But for HTTPS this isn't possible because it is forwarding at the TCP layer. Hopefully some day ELB will have SSL termination.
There are complaints in the Amazon forum about ELB's reliability. I suggest you head over there and search on ELB to form your own opinion on that front.
We wanted to use ELB to load balance web service requests, but we have many external callers, some of which send a 100-Continue HTTP message. Unfortunately ELB does not understand that part of the HTTP protocol, so we're unable to go beyond proof-of-concept until that's addressed.
2013 Update
According to an AWS forum post, HTTP 100-Continue is now supported.
发布评论
评论（5）
我已经在一个每天访问量大约 100,000 次的网站上运行 ELB 而不是 HAProxy 大约一个月了，我对结果非常满意。
但有一个问题（更新，此问题已由 Amazon AWS 修复，请参阅下面的评论）：
http://mysite.com重定向到http://www.mysite.com。除此之外，我对 AWS ELB 产品的评价实在是太高了。 我还使用 Cloudwatch 监控和自动缩放。 哦，不要忘记它比运行小型 EC2 实例便宜（每小时 0.025 美元，而不是0.10 美元）。
I've been running an ELB instead of HAProxy for about a month now on a site that gets about 100,000 visits per day, and I've been pretty pleased with the results.
A gotcha though (UPDATE, this issue has been fixed by Amazon AWS, see comments below):
http://mysite.comtohttp://www.mysite.com.Apart from that I really can't speak highly enough of the AWS ELB offerings. I'm also using the Cloudwatch monitoring and autoscaling. Oh and don't forget it's cheaper than running a small EC2 instance ($0.025 per hour instead of $0.10).
ELB 对 DNS CNAME 记录间接的依赖对于需要非常快的 Web 服务来说是相当严重的。 在我们的例子中，我们需要非常好的响应时间。 在快速性能测试中，使用 ELB 使 HTTP 请求的平均延迟增加了近 2 倍。这主要是因为 CNAME 查找的 TTL 为零。 因此，所有查找都涉及到两个不同域的名称服务器，因此名称解析速度要慢得多。 （我担心破坏 DNS 中的缓存只是对系统的滥用。）在我们的例子中，ELB 的唯一希望是通过让 Amazon 支持弹性 IP 作为负载均衡器实例的地址来摆脱 CNAME 记录。
ELB's dependence on DNS CNAME record indirection is pretty crippling for web services that need to be very fast. In our case we need to have very good response time. In a quick performance test, the use of an ELB increased the average latency for HTTP requests by a factor of almost 2. This is mainly because the TTL on the CNAME lookup is zero. Thus, all lookups involve hitting name servers for two different domains, so the name resolution is way slower. (I worry that defeating caching in DNS is simply an abuse of the system.) The only hope for ELB in our case would be to get away from CNAME records by having Amazon support an Elastic IP as the address of a load balancer instance.
另一个问题是获取客户端 IP 地址。 对于常规 HTTP，这可以正常工作，因为 ELB 设置了 X-FORWARDED-FOR 标头。 但对于 HTTPS 来说这是不可能的，因为它是在 TCP 层转发的。 希望有一天 ELB 能够终止 SSL。
Another issue is getting the client IP address. For regular HTTP this works fine, as ELB sets the X-FORWARDED-FOR header. But for HTTPS this isn't possible because it is forwarding at the TCP layer. Hopefully some day ELB will have SSL termination.
亚马逊论坛上有人抱怨 ELB 的可靠性。 我建议你去那里搜索 ELB，以形成你自己在这方面的看法。
我们想要使用 ELB 来负载平衡 Web 服务请求，但我们有许多外部调用者，其中一些调用者发送 100-Continue HTTP 消息。 不幸的是，ELB 不理解 HTTP 协议的这一部分，因此在解决这个问题之前我们无法超越概念验证。
2013 更新
根据 AWS 论坛帖子，现在支持 HTTP 100-Continue。
https://forums.aws.amazon.com/message.jspa?messageID= 144022
There are complaints in the Amazon forum about ELB's reliability. I suggest you head over there and search on ELB to form your own opinion on that front.
We wanted to use ELB to load balance web service requests, but we have many external callers, some of which send a 100-Continue HTTP message. Unfortunately ELB does not understand that part of the HTTP protocol, so we're unable to go beyond proof-of-concept until that's addressed.
2013 Update
According to an AWS forum post, HTTP 100-Continue is now supported.
https://forums.aws.amazon.com/message.jspa?messageID=144022
对于许多 ELB 用户来说，一个主要问题是它不支持粘性，这对于许多 Web 应用程序来说是一个杀手。
然而，根据 Amazon AWS 开发人员的说法，它应该会在下一个版本中出现。
One main problem for many users with ELB is that it does not support stickyness, which is a killer for many web application.
According to Amazon AWS developers it should however come in the next release.