我们最近在将业务从传统机房迁移到云端，此文的目的是为了吐槽业界领先的云解决方案 aws，以表明云不是万能的，也不是没有云就万万不能
elb，即 elastic load balancing，是 AWS 中用来做负载均衡的解决方案，它有如下坑爹之处
1): 只有 TCP，不支持 udp。于是基于 udp 的服务，比如 syslog，dns 便无法使用标准的方法做负载均衡。而当前除了 LVS，基于软件的 UDP 负载均衡也非常少。相比之下，netscaler lb 用起来顺心多了。
2): 一个 elb 端口只能 map 到单个 instance 的一个后端端口。比如ec2 上的服务监听了9001，9002 端口，此时想建立一个 elb，9000 端口指向后端同一 ec2 的这两个端口，对不起，elb 不支持这种做法。graphite 的 carbon relay 正是需要这种做法的服务，它会启动多个python 进程，监听在不同的端口，接受外来数据。由于 elb 的这个限制，我们只能在每个 relay 的服务器上再包装一层 haproxy。
3): elb 不自动重新添加恢复的后端实例。比如 elb 后面有两个 instance，其中一个挂了，elb 自然会将它踢开，但是如果过了一会instance活了，elb 此时默默的啥事不干，此instance在 elb 中 显示依然是 OOS 状态，需要用户手动将此 instance 在 elb 中先解绑，再绑定回去.
1): 使用 json 作为配置语言。为了自动化管理基础架构，我们使用 aws 都是基于 cloudformation 创建 stack，用了许久之后只想说一句话：我选择死亡。手写基于 json 的模板绝对是一个噩梦，cloudformation 语言的复杂性，比如下面的 if 语句，坑爹之处大伙自己体会。
"LoadBalancerNames": {"Fn::If": ["HasELB", [{"Ref": "ElasticLoadBalancer"}], {"Ref": "AWS::NoValue"}]}
2): cloudformation 不会检查资源占有信息。这个问题很严重，很严重，具体情况是这样。假如有一个 eip，被分配给了 ec2 instance，然而一不小心各种原因，这个 eip 在另外一个 cloudformation 的模板中被其他的 instance 使用了，此时使用这个模板创建 stack 的时候，新的 stack 会默默的将 eip 从原来的 ec2 上抢过来，不报任何错误。我们业务上就有这个问题的血的教训，当时那个 eip 是分配给 vpn 使用的，由于疏忽，这个 eip 直接被其他的服务抢走了，导致整个 aws 的业务全部下线。
没有 vpn，没有 route53，没有 lambda， 缺的东西太多了，连 elb 都不支持 session 粘连。而且其 api 还时不时停止响应，总的来说 aws 北京就是个阉割版，谁用谁知道。
最后，此列表还在不断更新中。