Amazon ECS（Elastic Container Service）现已支持内置蓝/绿部署功能，旨在简化和保障容器化应用的发布流程。此功能无需用户构建自定义部署工具，即可实现更安全、更一致的应用版本更新。通过同时运行新旧两个环境（绿/蓝），并在充分测试新环境后将流量安全切换，该服务还提供了即时回滚能力。用户还可以通过部署生命周期钩子（如 Lambda 函数）来自动化验证流程，确保在新版本部署前进行充分的测试，从而在出现问题时能够快速回滚，最大限度地减少对终端用户的影响。此功能在所有商用 AWS 区域均可用，且不收取额外费用。

📦 **内置蓝/绿部署简化流程**：Amazon ECS 集成了蓝/绿部署能力，允许用户在不构建额外工具的情况下，安全高效地更新容器化应用。新版本（绿）在旧版本（蓝）并行运行时进行部署，待测试验证后，流量从蓝环境平滑切换至绿环境，显著提升了部署的稳定性和速度。

✅ **自动化验证与即时回滚**：通过部署生命周期钩子，用户可以集成 Lambda 函数等服务，在流量切换的关键阶段执行自动化测试，如合成流量测试或 API 调用。一旦测试失败，ECS 会自动回滚到稳定的蓝版本，确保了高可用性，避免了对终端用户的影响。

⚖️ **流量管理与回滚机制**：蓝/绿部署策略允许在部署过程中精确控制流量的分配，从测试流量到生产流量的逐步切换。当验证阶段失败时，ECS 能够近乎瞬时地将流量从绿环境回滚到蓝环境，且由于蓝环境持续运行，用户无需承担传统的部署停机时间。

⚙️ **可配置性与灵活性**：用户可以通过 ECS 控制台、AWS CLI 或基础设施即代码工具来配置蓝/绿部署。此外，部署生命周期钩子的引入，如“测试流量转移后”（Post test traffic shift），为精细化控制部署流程提供了灵活性，允许在触发生产流量前进行独立的验证。

💰 **成本效益与可用性**：此蓝/绿部署功能包含在 Amazon ECS 服务中，不产生额外费用，用户仅需支付使用的计算资源费用。该功能已在所有商用 AWS 区域推出，为全球用户提供了便捷的部署解决方案。

<table id="amazon-polly-audio-table"><tbody><tr><td id="amazon-polly-audio-tab"><p></p></td></tr></tbody></table><p>While containers have revolutionized how development teams package and deploy applications, these teams have had to carefully monitor releases and build custom tooling to mitigate deployment risks, which slows down shipping velocity. At scale, development teams spend valuable cycles building and maintaining undifferentiated deployment tools instead of innovating for their business.</p><p>Starting today, you can use the built-in blue/green deployment capability in <a href="https://aws.amazon.com/ecs/?trk=c4ea046f-18ad-4d23-a1ac-cdd1267f942c&amp;amp;sc_channel=el&quot;&gt;Amazon Elastic Container Service (Amazon ECS)</a> to make your application deployments safer and more consistent. This new capability eliminates the need to build custom deployment tooling while giving you the confidence to ship software updates more frequently with rollback capability.</p><p>Here’s how you can enable the built-in blue/green deployment capability in the <a href="https://console.aws.amazon.com/ecs/v2?trk=c4ea046f-18ad-4d23-a1ac-cdd1267f942c&amp;amp;sc_channel=el&quot;&gt;Amazon ECS</a> console.</p><p><img class="aligncenter size-full wp-image-97584 c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/06/29/2025-news-ecsbg-0.png&quot; alt="" width="2946" height="1242" /></p><p>You create a new “green” application environment while your existing “blue” environment continues to serve live traffic. After monitoring and testing the green environment thoroughly, you route the live traffic from blue to green. With this capability, Amazon ECS now provides built-in functionality that makes containerized application deployments safer and more reliable.</p><p>Below is a diagram illustrating how blue/green deployment works by shifting application traffic from the blue environment to the green environment. You can learn more at the <a href="https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-blue-green.html?trk=c4ea046f-18ad-4d23-a1ac-cdd1267f942c&amp;amp;sc_channel=el&quot;&gt;Amazon ECS blue/green service deployments workflow</a> page.</p><p><img class="aligncenter size-full wp-image-98094 c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/07/10/2025-news-ecsbg-rev-1.png&quot; alt="" width="1011" height="653" /></p><p>Amazon ECS orchestrates this entire workflow while providing event hooks to validate new versions using synthetic traffic before routing production traffic. You can validate new software versions in production environments before exposing them to end users and roll back near-instantaneously if issues arise. Because this functionality is built directly into Amazon ECS, you can add these safeguards by simply updating your configuration without building any custom tooling.</p><p><strong>Getting started<br /></strong>Let me walk you through a demonstration that showcases how to configure and use blue/green deployments for an ECS service. Before that, there are a few setup steps that I need to complete, including configuring <a href="https://aws.amazon.com/iam/&quot;&gt;AWS Identity and Access Management</a> (IAM) roles, which you can find on the <a href="https://docs.aws.amazon.com/AmazonECS/latest/developerguide/blue-green-deployment-implementation.html?trk=c4ea046f-18ad-4d23-a1ac-cdd1267f942c&amp;amp;sc_channel=el&quot;&gt;Required resources for Amazon ECS blue/green deployments</a> Documentation page.</p><p>For this demonstration, I want to deploy a new version of my application using the blue/green strategy to minimize risk. First, I need to configure my ECS service to use blue/green deployments. I can do this through the ECS console, <a href="https://aws.amazon.com/cli/&quot;&gt;AWS Command Line Interface</a> (AWS CLI), or using infrastructure as code.</p><p>Using the Amazon ECS console, I create a new service and configure it as usual:</p><p><img class="aligncenter size-full wp-image-97585 c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/06/29/2025-news-ecsbg-1.png&quot; alt="" width="2952" height="2527" /></p><p>In the Deployment Options section, I choose <strong>ECS</strong> as the <strong>Deployment controller type</strong>, then <strong>Blue/green</strong> as the <strong>Deployment strategy</strong>. <strong>Bake time</strong> is the time after the production traffic has shifted to green, when instant rollback to blue is available. When the bake time expires, blue tasks are removed.</p><p><img class="aligncenter size-full wp-image-97586 c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/06/29/2025-news-ecsbg-2.png&quot; alt="" width="2946" height="781" /></p><p>We’re also introducing deployment lifecycle hooks. These are event-driven mechanisms you can use to augment the deployment workflow. I can select which <a href="https://aws.amazon.com/pm/lambda/?trk=c4ea046f-18ad-4d23-a1ac-cdd1267f942c&amp;amp;sc_channel=el&quot;&gt;AWS Lambda</a> function I’d like to use as a deployment lifecycle hook. The Lambda function can perform the required business logic, but it must return a hook status.</p><p>Amazon ECS supports the following lifecycle hooks during blue/green deployments. You can learn more about each stage on the <a href="https://docs.aws.amazon.com/AmazonECS/latest/developerguide/blue-green-deployment-how-it-works.html#blue-green-deployment-stages?trk=c4ea046f-18ad-4d23-a1ac-cdd1267f942c&amp;amp;sc_channel=el&quot;&gt;Deployment lifecycle stages</a> page.</p><ul><li>Pre scale up</li><li>Post scale up</li><li>Production traffic shift</li><li>Test traffic shift</li><li>Post production traffic shift</li><li>Post test traffic shift</li></ul><p>For my application, I want to test when the test traffic shift is complete and the green service handles all of the test traffic. Since there’s no end-user traffic, a rollback at this stage will have no impact on users. This makes <strong>Post test traffic shift</strong> suitable for my use case as I can test it first with my Lambda function.</p><p><img class="aligncenter wp-image-98095 size-full c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/07/10/2025-news-ecsbg-rev-2.png&quot; alt="" width="1328" height="689" /></p><p>Switching context for a moment, let’s focus on the Lambda function that I use to validate the deployment before allowing it to proceed. In my Lambda function as a deployment lifecycle hook, I can perform any business logic, such as synthetic testing, calling another API, or querying metrics.</p><p>Within the Lambda function, I must return a <code>hookStatus</code>. A <code>hookStatus</code> can be <code>SUCCESSFUL</code>, which will move the process to the next step. If the status is <code>FAILED</code>, it rolls back to the blue deployment. If it’s <code>IN_PROGRESS</code>, then Amazon ECS retries the Lambda function in 30 seconds.</p><p>In the following example, I set up my validation with a Lambda function that performs file upload as part of a test suite for my application.</p><pre class="lang-python">import jsonimport urllib3import loggingimport base64import os# Configure logginglogger = logging.getLogger()logger.setLevel(logging.DEBUG)# Initialize HTTP clienthttp = urllib3.PoolManager()def lambda_handler(event, context): """ Validation hook that tests the green environment with file upload """ logger.info(f"Event: {json.dumps(event)}") logger.info(f"Context: {context}") try: # In a real scenario, you would construct the test endpoint URL test_endpoint = os.getenv("APP_URL") # Create a test file for upload test_file_content = "This is a test file for deployment validation" test_file_data = test_file_content.encode('utf-8') # Prepare multipart form data for file upload fields = { 'file': ('test.txt', test_file_data, 'text/plain'), 'description': 'Deployment validation test file' } # Send POST request with file upload to /process endpoint response = http.request( 'POST', test_endpoint, fields=fields, timeout=30 ) logger.info(f"POST /process response status: {response.status}") # Check if response has OK status code (200-299 range) if 200 &lt;= response.status &lt; 300: logger.info("File upload test passed - received OK status code") return { "hookStatus": "SUCCEEDED" } else: logger.error(f"File upload test failed - status code: {response.status}") return { "hookStatus": "FAILED" } except Exception as error: logger.error(f"File upload test failed: {str(error)}") return { "hookStatus": "FAILED" }</pre><p>When the deployment reaches the lifecycle stage that is associated with the hook, Amazon ECS automatically invokes my Lambda function with deployment context. My validation function can run comprehensive tests against the green revision—checking application health, running integration tests, or validating performance metrics. The function then signals back to ECS whether to proceed or abort the deployment.</p><p>As I chose the blue/green deployment strategy, I also need to configure the load balancers and/or Amazon ECS Service Connect. In the <strong>Load balancing</strong> section, I select my <strong>Application Load Balancer</strong>.</p><p><img class="aligncenter size-full wp-image-97588 c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/06/29/2025-news-ecsbg-4.png&quot; alt="" width="2464" height="1948" /></p><p>In the <strong>Listener</strong> section, I use an existing listener on port 80 and select two <strong>Target groups</strong>.</p><p><img class="aligncenter size-full wp-image-97589 c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/06/29/2025-news-ecsbg-5.png&quot; alt="" width="2952" height="1314" /></p><p>Happy with this configuration, I create the service and wait for ECS to provision my new service.</p><p><img class="aligncenter size-full wp-image-97590 c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/06/29/2025-news-ecsbg-6.png&quot; alt="" width="2948" height="1817" /></p><p><strong>Testing blue/green deployments<br /></strong>Now, it’s time to test my blue/green deployments. For this test, Amazon ECS will trigger my Lambda function after the test traffic shift is completed. My Lambda function will return <code>FAILED</code> in this case as it performs file upload to my application, but my application doesn’t have this capability.</p><p>I update my service and check <strong>Force new deployment</strong>, knowing the blue/green deployment capability will roll back if it detects a failure. I select this option because I haven’t modified the task definition but still need to trigger a new deployment.</p><p><img class="aligncenter wp-image-98098 size-full c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/07/10/2025-news-ecsbg-rev-3.png&quot; alt="" width="1311" height="779" /></p><p>At this stage, I have both blue and green environments running, with the green revision handling all the test traffic. Meanwhile, based on <a href="https://aws.amazon.com/cloudwatch/?trk=c4ea046f-18ad-4d23-a1ac-cdd1267f942c&amp;amp;sc_channel=el&quot;&gt;Amazon CloudWatch</a> Logs of my Lambda function, I also see that the deployment lifecycle hooks work as expected and emit the following payload:</p><pre class="lang-json">[INFO] 2025-07-10T13:15:39.018Z 67d9b03e-12da-4fab-920d-9887d264308e Event: { "executionDetails": { "testTrafficWeights": {}, "productionTrafficWeights": {}, "serviceArn": "arn:aws:ecs:us-west-2:123:service/EcsBlueGreenCluster/nginxBGservice", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123:service-revision/EcsBlueGreenCluster/nginxBGservice/9386398427419951854" }, "executionId": "a635edb5-a66b-4f44-bf3f-fcee4b3641a5", "lifecycleStage": "POST_TEST_TRAFFIC_SHIFT", "resourceArn": "arn:aws:ecs:us-west-2:123:service-deployment/EcsBlueGreenCluster/nginxBGservice/TFX5sH9q9XDboDTOv0rIt"}</pre><p>As expected, my AWS Lambda function returns <code>FAILED</code> as <code>hookStatus</code> because it failed to perform the test.</p><pre class="lang-json">[ERROR] 2025-07-10T13:18:43.392Z 67d9b03e-12da-4fab-920d-9887d264308e File upload test failed: HTTPConnectionPool(host='xyz.us-west-2.elb.amazonaws.com', port=80): Max retries exceeded with url: / (Caused by ConnectTimeoutError(&lt;urllib3.connection.HTTPConnection object at 0x7f8036273a80&gt;, 'Connection to xyz.us-west-2.elb.amazonaws.com timed out. (connect timeout=30)'))</pre><p>Because the validation wasn’t completed successfully, Amazon ECS tries to roll back to the blue version, which is the previous working deployment version. I can monitor this process through ECS events in the <strong>Events</strong> section, which provides detailed visibility into the deployment progress.</p><p><img class="aligncenter wp-image-98100 size-full c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/07/10/2025-news-ecsbg-rev-5.png&quot; alt="" width="1806" height="762" /></p><p>Amazon ECS successfully rolls back the deployment to the previous working version. The rollback happens near-instantaneously because the blue revision remains running and ready to receive production traffic. There is no end-user impact during this process, as production traffic never shifted to the new application version—ECS simply rolled back test traffic to the original stable version. This eliminates the typical deployment downtime associated with traditional rolling deployments.</p><p><img class="aligncenter wp-image-98101 size-full c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/07/10/2025-news-ecsbg-rev-7.png&quot; alt="" width="1920" height="793" /></p><p>I can also see the rollback status in the <strong>Last deployment</strong> section.</p><p><img class="aligncenter size-full wp-image-98102 c6" src="https://d2908q01vomqb2.cloudfront.net/da4b9237bacccdf19c0760cab7aec4a8359010b0/2025/07/10/2025-news-ecsbg-rev-8.png&quot; alt="" width="1920" height="782" /></p><p>Throughout my testing, I observed that the blue/green deployment strategy provides consistent and predictable behavior. Furthermore, the deployment lifecycle hooks provide more flexibility to control the behavior of the deployment. Each service revision maintains immutable configuration including task definition, load balancer settings, and Service Connect configuration. This means that rollbacks restore exactly the same environment that was previously running.</p><p><strong>Additional things to know<br /></strong>Here are a couple of things to note:</p><ul><li><strong>Pricing</strong> – The blue/green deployment capability is included with Amazon ECS at no additional charge. You pay only for the compute resources used during the deployment process.</li><li><strong>Availability</strong> – This capability is available in all commercial AWS Regions.</li></ul><p>Get started with blue/green deployments by updating your Amazon ECS service configuration in the <a href="https://console.aws.amazon.com/ecs/?trk=c4ea046f-18ad-4d23-a1ac-cdd1267f942c&amp;amp;sc_channel=el&quot;&gt;Amazon ECS console</a>.</p><p>Happy deploying!<br />— <a href="https://www.linkedin.com/in/donnieprakoso&quot;&gt;Donnie&lt;/a&gt;&lt;/p&gt;