我的用例： 我有一个由Elastic Load Balancer提供服务的Web应用程序，该应用程序位于1个EC2实例的前面。 该体系结构旨在模拟蓝/绿部署流程，这意味着当我需要更新代码并切换ELB所指向的代码时，将打开第二个实例。
假设实例A具有我的应用程序的当前版本，我的ELB正在将流量路由到该实例，因为它是唯一可用的实例。我想将更新推送到我的应用程序，因此我在 Instance-B 上部署了新版本的应用程序（打开instance-B并部署了新版本的代码）。同时，访问我的应用程序的任何用户仍将被路由到Instance-A并为其创建会话，直到我进行切换为止。
一旦部署了 Instance-B 并提供了更新的代码，我如何确保ELB仅在 Instance-B <上发送新流量 / em>，并将旧流量（以前的用户及其会话）保留在 instanceA 上，直到我从负载均衡器注销后者为止？
希望这很有道理，我知道这种架构设计不是Blue / Green Deployment的正确实现。但是由于我的应用程序的规模和预算，我想限制我正在使用的实例数。
谢谢您的帮助。
答案 0 :(得分：1)
好吧，如果您使用的是经典ELB，则需要创建ELB的粘性策略，您可以在此处https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
中找到详细说明如果您使用的是ALB或应用程序负载平衡器，则几乎相同，但粘性策略已超出目标组https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions
如果要改善蓝/绿部署策略，最好使用Route53进行切换，并且成本非常低
我希望这对您有帮助