大多数ECS蓝绿部署教程最终都指向同一套技术栈：AWS CodeDeploy、部署组、AppSpec文件、生命周期钩子、加权流量转移、复杂的回滚编排。CodeDeploy确实能用，但我在实际部署中反复遇到一个现实限制——无法让内部团队在正式生产URL上验证新版本，就直接向客户开放。

这成了整个方案的设计动机。我不想要：独立的预发域名、重复的ALB、临时预览环境、"接近生产"的测试。我想要更简单的东西：内部用户先看新版本，客户继续看稳定版本，两者共用同一生产域名，回滚即时，部署保持完全零停机。

打开网易新闻 查看精彩图片

于是我构建了一套Terraform驱动的部署工作流，使用ECS Fargate、应用型负载均衡器（ALB）、ALB监听器优先级、源IP路由和Terraform本身，完全不用CodeDeploy。实际运行后，这套方案成了我许多ECS工作负载的首选。

核心思路很直接：BLUE和GREEN环境跑在同一ALB后面。内部办公网/VPN的IP先路由到GREEN，其他人继续访问BLUE。这意味着QA和内部团队可以在真实生产基础设施上直接验证新版本，再开始公开推广。域名、SSL证书、ALB、认证流程、重定向、网络路径，全部相同。不会出现"预发环境没问题，一上生产就崩"的意外。

很多部署问题只在真实的生产路由路径上才会暴露。举个例子：内部用户打开https://nginx.jayakrishnayadav.cloud，立刻看到GREEN版本；同时，公网用户继续看到BLUE。没有DNS切换，没有重复基础设施，只靠ALB监听器路由。

架构流程是这样的：请求先到应用型负载均衡器，然后分流——内部办公/VPN IP走GREEN目标组，公网用户走BLUE目标组，分别对应ECS GREEN任务和ECS BLUE任务。金丝雀路由规则优先评估，如果请求源IP匹配内部CIDR段，流量进GREEN，其余回落到BLUE。

我把Terraform结构做成模块化，方便跨服务复用。根目录下有main.tf、variables.tf、outputs.tf，env目录放backend.hcl和terraform.tfvars，modules目录包含vpc、iam、alb、ecs-cluster、ecs-blue-green-service等模块，还有scripts目录放zero-downtime-test.sh脚本。

每个ECS服务配套：BLUE ECS服务、GREEN ECS服务、BLUE目标组、GREEN目标组、生产监听器规则、可选的金丝雀监听器规则。整个部署行为取决于ALB监听器优先级，金丝雀规则优先评估，源IP匹配内部CIDR就进GREEN。