Tác giả: Franco Abregu và Chris Renzo
Ngày phát hành: 11 FEB 2026
Chuyên mục: Amazon Elastic Container Service, AWS Cloud Development Kit, AWS CodeDeploy, Best Practices, Developer ToolsTháng 3 năm 2026: Bài viết này đã được cập nhật để phản ánh rằng Amazon ECS hiện hỗ trợ các chiến lược triển khai canary và linear một cách tự nhiên kể từ tháng 10 năm 2025. Khuyến nghị đã được cập nhật tương ứng để phản ánh ECS-native là lựa chọn mặc định cho các triển khai mới.
Triển khai blue/green trên Amazon Elastic Container Service (Amazon ECS) từ lâu đã là một mô hình được ưa chuộng để thực hiện các triển khai không gián đoạn. Trong lịch sử, phương pháp được khuyến nghị trong AWS Cloud Development Kit (AWS CDK) là kết nối ECS với AWS CodeDeploy để chuyển đổi lưu lượng truy cập, các hook vòng đời và tích hợp chặt chẽ với AWS CodePipeline.
Vào tháng 7 năm 2025, Amazon ECS đã ra mắt tính năng triển khai blue/green tích hợp sẵn. Điều này cho phép bạn vận hành trực tiếp trong dịch vụ ECS mà không yêu cầu sử dụng Amazon CodeDeploy. Vào tháng 10 năm 2025, Amazon ECS đã nâng cao khả năng này hơn nữa bằng cách bổ sung hỗ trợ cho các chiến lược triển khai canary và linear, đạt được sự tương đương về tính năng với CodeDeploy.
Bài viết này giải thích những thay đổi, cách mô hình blue/green gốc của ECS mới so sánh với CodeDeploy và cách quyết định lựa chọn phương pháp nào trong các dự án CDK của bạn.

Hình 1: Triển khai blue/green của Amazon ECS với AWS CodeDeploy
Tại sao nên sử dụng blue/green trên ECS, và những gì đã được ra mắt vào tháng 7 năm 2025
Trong triển khai blue/green, hai môi trường sản xuất được duy trì: blue, môi trường hiện tại và green, môi trường mới. Chiến lược này cho phép bạn xác thực phiên bản mới của môi trường trước khi nó nhận lưu lượng truy cập sản xuất.
Nhóm dịch vụ ECS đã nhận thấy cơ hội để đơn giản hóa quy trình triển khai bằng cách tạo các hook vòng đời, thời gian chờ (bake time) và khả năng rollback được quản lý trực tiếp trong ECS. Với sự thay đổi này, sự phức tạp của việc điều phối các triển khai blue/green thông qua CodeDeploy được hợp nhất vào một dịch vụ duy nhất. Sự hợp nhất này không chỉ đơn giản hóa pipeline triển khai mà còn giảm số lượng các thành phần di động, giúp việc bảo trì và khắc phục sự cố dễ dàng hơn theo thời gian.
Về mặt khái niệm, blue/green gốc của ECS cung cấp một tập hợp tác vụ thay thế được đăng ký vào một nhóm đích riêng biệt (nhóm đích blue trong hình 2) phía sau listener của Elastic Load Balancing của bạn. Khi bạn chấp thuận chuyển đổi, ECS thực hiện chuyển đổi lưu lượng truy cập sang phiên bản green (nhóm đích green trong hình 2) bằng cách sử dụng chiến lược bạn đã chọn (all-at-once, canary hoặc linear), sau đó giữ cả hai phiên bản trong một khoảng thời gian chờ có thể cấu hình trước khi loại bỏ blue hoặc rollback nếu các cảnh báo hoặc hook thất bại.

Hình 2: Triển khai Blue/Green gốc của Amazon ECS
Hai phương pháp trong CDK: Blue/green gốc của ECS so với Blue/green của CodeDeploy
Với CDK, giờ đây bạn có hai cách để đạt được blue/green trên ECS. Một là phương pháp ECS-native giữ cấu hình triển khai trên module CDK ECS và các tài nguyên bộ cân bằng tải liên quan. Bạn cấu hình các hook vòng đời để gọi các hàm AWS Lambda tại các giai đoạn triển khai cụ thể, bạn đặt thời gian chờ (bake time) và bạn tùy chọn sử dụng một listener kiểm tra hoặc các quy tắc header của Amazon ECS Service Connect để xác thực lưu lượng truy cập đến phiên bản green trước khi chuyển đổi sản xuất. Phương pháp CodeDeploy tạo một ứng dụng CodeDeploy và nhóm triển khai được liên kết với dịch vụ ECS và Application Load Balancer (ALB) của bạn, cho phép bạn chọn các chính sách canary, linear hoặc all-at-once, và thường tích hợp vào AWS CodePipeline để điều phối.
Cả ECS-native và CodeDeploy hiện đều hỗ trợ cả ba chiến lược chuyển đổi lưu lượng truy cập: all-at-once, canary và linear. ECS-native đã ra mắt hỗ trợ cho các triển khai canary và linear vào tháng 10 năm 2025, loại bỏ khoảng cách chức năng từng tồn tại trước đây. Cả hai tùy chọn đều cho phép bạn kiểm soát cách phiên bản mới của bạn được dần dần tiếp xúc với lưu lượng truy cập sản xuất, với tỷ lệ phần trăm bước và thời gian chờ có thể cấu hình giữa các lần chuyển đổi lưu lượng truy cập.
Hiện tại, AWS CDK bao gồm hỗ trợ L2 cho blue/green gốc của ECS để bạn có thể mô hình hóa các cài đặt này trực tiếp mà không cần CloudFormation tùy chỉnh hoặc các escape hatch. Nếu stack của bạn đã sử dụng đường dẫn Deployment Controller Type. CODE_DEPLOY, bạn có thể tiếp tục làm như vậy; các tùy chọn di chuyển tồn tại (được nêu chi tiết sau trong bài viết này).

Hình 3: Chuyển đổi lưu lượng truy cập triển khai blue/green của Amazon CodeDeploy
Hướng dẫn quyết định: lựa chọn phương pháp phù hợp
Sử dụng ECS-native khi:
- Bạn muốn một mô hình đơn giản hơn, tập trung vào dịch vụ với ít thành phần di động hơn
- Bạn muốn quản lý mọi thứ từ ECS mà không cần các dịch vụ bổ sung
- Bạn cần hỗ trợ cho Service Connect, các dịch vụ headless hoặc nhiều nhóm đích
- Bạn muốn các hook vòng đời linh hoạt hơn (không giới hạn 1 giờ như CodeDeploy)
- Bạn đang bắt đầu một dự án mới hoặc triển khai greenfield
- Bạn muốn sự phù hợp tốt hơn với các tính năng Amazon ECS hiện có (circuit breaker, lịch sử triển khai)
Sử dụng CodeDeploy khi:
- Bạn đã có các pipeline phức tạp trong CodePipeline phụ thuộc vào CodeDeploy
- Bạn cần điều phối các triển khai đa dịch vụ trên các dịch vụ, Region và tài khoản trong một bản phát hành duy nhất
- Bạn đã thiết lập các quy trình quản trị và nhật ký kiểm toán xung quanh CodeDeploy
- Bạn đang di chuyển từ một triển khai CodeDeploy hiện có và không có nhu cầu kinh doanh cấp bách để thay đổi
Cách triển khai ECS-native trong CDK
Để sử dụng blue/green gốc của ECS trong CDK, hãy bắt đầu với một dịch vụ Amazon ECS (Fargate hoặc EC2), một Application Load Balancer và hai nhóm đích được ECS quản lý trong quá trình triển khai. Trong định nghĩa dịch vụ của bạn, bạn sẽ chọn loại triển khai blue/green, đặt thời gian chờ (bake time) và đính kèm các hook vòng đời. Các hook có thể chạy các hàm Lambda ở các giai đoạn như trước khi mở rộng quy mô hoặc sau khi chuyển đổi lưu lượng truy cập sản xuất, cho phép bạn chạy các thử nghiệm tổng hợp, làm nóng bộ nhớ cache hoặc kiểm tra dựa trên các kiểm tra bên ngoài. Nếu bạn đang sử dụng Amazon ECS Service Connect, bạn có thể định tuyến lưu lượng truy cập kiểm tra “dark” đến green bằng cách gửi các yêu cầu với một header cụ thể trong giai đoạn trước khi chuyển đổi.
const service = new ecs.FargateService(this, "Service", { cluster, taskDefinition, desiredCount: 3, securityGroups: [serviceSG], vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS, }, deploymentStrategy: ecs.DeploymentStrategy.BLUE_GREEN, bakeTime: Duration.minutes(30), propagateTags: ecs.PropagatedTagSource.SERVICE, deploymentAlarms: { alarmNames: [ this.stackName + "-Http-500-Blue", this.stackName + "-Http-500-Green", "Synthetics-Alarm-trivia-game-" + props.stage, ], behavior: ecs.AlarmBehavior.ROLLBACK_ON_ALARM, }, lifecycleHooks: [ new ecs.DeploymentLifecycleLambdaTarget( preTrafficHook, "PreTrafficHook", { lifecycleStages: [ ecs.DeploymentLifecycleStage.POST_TEST_TRAFFIC_SHIFT, ], } ), ], minHealthyPercent: 100, maxHealthyPercent: 200, });
Đoạn mã: Dịch vụ Amazon ECS với AWS Fargate và AWS CodeDeploy
Kết luận
Triển khai blue/green gốc của ECS hiện là tùy chọn được khuyến nghị cho hầu hết các nhóm và dự án mới. Với sự hỗ trợ đầy đủ cho các triển khai canary và linear cùng với các chiến lược all-at-once, nó cung cấp khả năng chuyển đổi không gián đoạn, các hook vòng đời, thời gian chờ (bake time) và khả năng rollback mà không yêu cầu quản lý các dịch vụ bổ sung.
CodeDeploy vẫn là một tùy chọn hợp lệ cho các khách hàng hiện tại hoặc những người có các phụ thuộc CodePipeline cụ thể và các quy trình quản trị đã được thiết lập, nhưng định hướng của AWS là di chuyển sang ECS-native cho các triển khai mới.
Nâng cấp các triển khai ECS của bạn lên một tầm cao mới bằng cách bật triển khai Blue/Green với chiến lược phù hợp nhất cho trường hợp sử dụng của bạn. Để biết hướng dẫn từng bước di chuyển từ CodeDeploy sang ECS-Native, hãy tham khảo hướng dẫn di chuyển chính thức.
Để biết thêm thông tin về các khả năng triển khai canary và linear mới, hãy xem tài liệu Amazon ECS về triển khai blue/green.
Về tác giả

Franco Abregu
Franco Abregu là Tư vấn viên Chuyển giao Cấp cao – DevOps tại AWS Professional Services có trụ sở tại Argentina. Franco tập trung vào việc chuyển đổi văn hóa DevOps của khách hàng để cải thiện năng suất của nhà phát triển, hoạt động, triển khai và tiêu chuẩn hóa quy trình. Chuyên môn của anh bao gồm CI/CD, Infrastructure as Code, phát triển phần mềm và áp dụng văn hóa DevOps trong tổ chức.

Chris Renzo
là Kiến trúc sư Giải pháp Cấp cao trong tổ chức AWS Defense and Aerospace. Ngoài công việc, anh ấy thích sự cân bằng giữa thời tiết ấm áp và du lịch.