好的，我从来没有用自己的SmugMug级别构建流量的AWS负载平衡解决方案，但是仅考虑理论和AWS服务，就会想到一些想法。
最初的问题缺少一些会影响负载均衡设计的东西：
- 粘性会议吗？最好不要使用粘性会话，而应让所有负载均衡器（LB）使用轮询（RR）或随机后端选择。RR或随机后端选择非常简单，可扩展，并且可以在所有情况下均等地分配负载。
- 是否使用SSL？是否使用SSL，以及使用的请求百分比，通常都会对负载平衡设计产生影响。通常最好尽早终止SSL，以简化证书处理并使SSL CPU负载远离Web应用程序服务器。
我是从如何保持负载平衡层本身的高度可用性的角度来回答的。保留应用程序服务器HA只是通过L7负载平衡器中内置的运行状况检查来完成。
好的，有两个可行的想法：
1）“ AWS方式”：
- 最顶层的第一层在L4（TCP / IP）模式下使用ELB。
- 第二层，将EC2实例与您选择的L7负载均衡器（nginx，HAProxy，Apache等）一起使用。
优点/想法： L7负载平衡器可以是相当简单的EC2 AMI，所有这些都从同一AMI克隆并使用相同的配置。因此，Amazon的工具可以满足所有HA需求： ELB监视L7负载平衡器。如果L7 LB死亡或无响应，则ELB和Cloudwatch会自动产生一个新实例，并将其带入ELB池。
2）“具有监视方式的DNS轮询：”
- 使用基本的DNS轮询可以在两个IP地址上获得粗粒度的负载分配。假设您为网站发布了3个IP地址。
- 这3个IP中的每一个都是绑定到EC2实例的AWS弹性IP地址（EIA），具有您选择的L7负载均衡器。
- 如果EC2 L7 LB死了，则兼容的用户代理（浏览器）应仅使用其他IP之一。
- 设置一个外部监视服务器。监视3个EIP中的每一个。如果没有响应，请使用AWS的命令行工具和一些脚本将EIP移至另一个EC2实例。
好处/想法：如果一个用户没有响应，则符合要求的用户代理应自动切换到另一个IP地址。因此，在发生故障的情况下，应该只影响您的用户的1/3，并且这些用户中的大多数都不会注意到任何东西，因为他们的UA会静默地故障转移到另一个IP。而且您的外部监视盒会注意到EIP没有响应，并在几分钟之内纠正了这种情况。
3）对高可用性服务器对的DNS RR：
基本上，这是Don自己对一对服务器之间的简单心跳的建议，但对于多个IP地址却简化了。
- 使用DNS RR，发布服务的多个IP地址。按照上面的示例，我们假设您发布了3个IP。
- 这些IP中的每一个都连接到一对 EC2服务器，因此总共有6个EC2实例。
- 这些对中的每对都使用Heartbeat或另一个HA解决方案以及AWS工具，以在主动/被动配置中保持1个IP地址处于活动状态。
- 每个EC2实例都安装了您选择的L7负载均衡器。
优势/想法：在AWS的完全虚拟化环境中，就L4服务和故障转移模式进行推理实际上并不那么容易。通过简化为一对仅保留1个IP地址的相同服务器，就可以简化推理和测试的过程。
结论：同样，我实际上还没有在生产中尝试任何一种方法。仅凭我的直觉，选择L4模式下的ELB以及作为L7 LB的自我管理型EC2实例的选择似乎最符合AWS平台的精神，并且亚马逊极有可能在此后进行投资和扩展。这可能是我的首选。