Viết bởi Shiva Vaidyanathan & Omkar Nyalpelly – 21/04/2025
Chuyên mục: Best Practices, DevOps, Networking & Content Delivery

Tóm tắt nhanh: API AWS Cloud Control cung cấp giao diện CRUD-L thống nhất để quản lý tài nguyên mạng (Transit Gateway, Network Firewall…) qua nhiều tài khoản và vùng AWS. Bài viết hướng dẫn quy trình triển khai theo từng bước và so sánh chi tiết với CloudFormation, CDK và Terraform.

Mục lục

• Key Concepts
• Kiến trúc & kịch bản thực tế
• Các khối xây dựng chính (5 Building Blocks)
• So sánh với CloudFormation/CDK/Terraform
• Điều kiện tiên quyết
• Triển khai từng bước (Step-by-Step)
• Thiết kế & tư duy triển khai (Thought Process)
• Best practices & vận hành
• FAQ
• Kết luận
• Về tác giả

Key Concepts

• AWS Cloud Control API: Giao diện nhất quán, không phụ thuộc ngôn ngữ cho CRUD-L với tài nguyên AWS; cập nhật nhanh khi AWS có tính năng mới, giảm phụ thuộc vào cú pháp/SDK của từng dịch vụ.
• CRUD-L: Create, Read, Update, Delete, List — giúp đọc trạng thái và cập nhật gia tăng, hữu ích cho hạ tầng mạng thay đổi liên tục (route, rule, attachment…).
• Transit Gateway: Trung tâm kết nối liên vùng/liên VPC.
• AWS Network Firewall: Kiểm tra/kiểm soát lưu lượng giữa workload và ứng dụng nội bộ; có thể cập nhật rule động qua Cloud Control.
• Multi-Account, Multi-Region: Giả định vai trò IAM, chia sẻ tài nguyên qua RAM, duy trì cách ly nhưng vẫn kết nối an toàn.
• CI/CD: Tự động hoá cung cấp & cập nhật mạng với CodePipeline, CodeBuild, S3 artifacts, DynamoDB.

Kiến trúc & kịch bản thực tế

Workload hoạt động trên hai vùng (us-east-1, us-west-2), ứng dụng nội bộ nằm ở tài khoản dịch vụ chung. Tất cả giao tiếp đi qua Transit Gateway và được kiểm tra bởi Network Firewall trước khi tới/ra workload. Kiến trúc này phù hợp khi bạn cần kết nối tập trung, kiểm tra lưu lượng nhất quán, và quản trị xuyên nhiều tài khoản/vùng.

Hình 1 (mô tả): Cloud Control API đơn giản hóa việc phát triển & triển khai kịch bản mạng trên đa tài khoản/vùng; các building blocks được đánh số (1) Kết nối tập trung, (2) Kiểm tra lưu lượng, (3) Đa tài khoản, (4) Cập nhật động, (5) Tự động hóa CI/CD.

Các khối xây dựng chính (5 Building Blocks)

1. Kết nối tập trung (Transit Gateway Hub)
   Cung cấp Transit Gateway và các attachments qua một giao diện CRUD-L thống nhất (create_resource cho từng tài nguyên), giảm học tập công cụ IaC riêng lẻ.
2. Kiểm tra lưu lượng (Network Firewall)
   Định tuyến toàn bộ lưu lượng qua Network Firewall; cập nhật rule động bằng update_resource mà không phải redeploy toàn bộ stack trong đa số trường hợp.
3. Thiết lập đa tài khoản
   Giả định vai trò (assume role) để triển khai an toàn sang các tài khoản thành viên; chia sẻ tài nguyên bằng AWS::RAM::ResourceShare.
4. Cập nhật động
   Đọc trạng thái hiện tại (read/list) → suy ra những gì cần thay đổi (route/attachment/rule) → update gia tăng. Hiển thị lỗi rõ ràng qua get_resource_request_status.
5. Tự động hóa CI/CD
   Đưa Cloud Control vào pipeline (CodePipeline/CodeBuild) để cung cấp, cập nhật, xoá tài nguyên một cách khai báo và có thể lặp lại.

Bảng tổng hợp (Bảng 1): tóm lược 5 building blocks và vai trò Cloud Control trong từng khối.

So sánh với CloudFormation, CDK, Terraform (điểm nhấn)

Dưới đây là điểm nhấn từ các Bảng 2–6 trong tài liệu gốc. Bạn có thể chuyển thành bảng Gutenberg nếu muốn.

(A) Kết nối tập trung – Transit Gateway

• Cloud Control: Giao diện nhất quán cho TGW và attachments (CRUD chuẩn hoá), vẫn gọi riêng từng tài nguyên nhưng tránh lệ thuộc cú pháp từng công cụ.
• CloudFormation / CDK / Terraform: Cần mẫu/hàm/lớp/mô-đun riêng, quy tắc cú pháp nghiêm ngặt, dễ phát sinh phụ thuộc.

(B) Kiểm tra lưu lượng – Network Firewall

• Cloud Control: Cập nhật rule động qua update_resource, hỗ trợ đa vùng linh hoạt (tái dùng YAML/param).
• Cfn/CDK/Terraform: Thường phải redeploy stack hoặc điều chỉnh code/trạng thái phức tạp.

(C) Đa tài khoản

• Cloud Control: Giả định vai trò mượt mà, chia sẻ tài nguyên qua RAM theo cách khai báo.
• Cfn/CDK/Terraform: Cần StackSets, SDK logic, hoặc cấu hình provider nhiều khối — tăng độ phức tạp.

(D) Cập nhật động

• Cloud Control: Hiển thị lỗi rõ ràng qua get_resource_request_status; cập nhật gia tăng; quản lý trạng thái khai báo.
• Cfn/CDK/Terraform: Cập nhật thường chậm (đợi đặc tả/SDK/provider), quản lý phụ thuộc/tệp trạng thái thủ công.

(E) Tự động hoá CI/CD

• Cloud Control: Giao diện duy nhất cho tất cả giai đoạn, tái sử dụng YAML, phản hồi lỗi rõ ràng kích hoạt retry/rollback.
• CDK/Cfn/Terraform: Cần kịch bản/logic bổ sung theo giai đoạn; quản lý trạng thái phức tạp.

Điều kiện tiên quyết

1. Người dùng IAM trong tài khoản triển khai mạng (được gắn policy có quyền IAM, S3, CodePipeline, CodeBuild, DynamoDB) + tạo Access key cho CLI.
2. Cài AWS CLI và cấu hình aws configure với Access/Secret key của user trên.
3. Cài Git trên máy cục bộ.

Triển khai từng bước (Step-by-Step)

Bước 1 — Sao chép & thiết lập kho Git

git clone https://github.com/aws-samples/sample-network-deployment-using-aws-cloud-control.git
cd sample-network-deployment-using-aws-cloud-control
git remote remove origin
git remote add origin <your-new-repo-url>
git push -u origin <default-branch-name>

Bước 2 — Tạo IAM Roles

• CodePipelineRole (tài khoản triển khai): dùng bởi CodePipeline/CodeBuild để assume role sang tài khoản thành viên.

aws cloudcontrol create-resource \
  --type-name "AWS::IAM::Role" \
  --desired-state file://codepipeline_role.json \
  --region us-east-1 \
  --profile <deployment-account-profile>

• MemberAccountRole (mỗi tài khoản thành viên): role đích để CodePipelineRole giả định khi triển khai tài nguyên.

Bước 3 — Tạo CodeBuild Project

aws codebuild create-project \
  --name "MultiAccountCloudControlBuild" \
  --description "CodeBuild project for deploying AWS resources." \
  --source type=CODEPIPELINE \
  --artifacts type=CODEPIPELINE \
  --environment type=LINUX_CONTAINER,image=aws/codebuild/standard:5.0,computeType=BUILD_GENERAL1_SMALL \
  --service-role "arn:aws:iam::deployment-account-id:role/CodePipelineRole" \
  --region us-east-1 \
  --profile <deployment-account-profile>

Bước 4 — Tạo S3 artifact bucket

aws s3api create-bucket --bucket YourS3BucketName --region us-east-1 --profile <deployment-account-profile>
aws s3api put-bucket-versioning --bucket YourS3BucketName --versioning-configuration Status=Enabled --region us-east-1 --profile <deployment-account-profile>

Bước 5 — Tạo CodePipeline (sử dụng Cloud Control)

• Cập nhật codepipeline.json: RoleArn (role vừa tạo), ArtifactStore (bucket S3), cấu hình Git (nhánh kích hoạt build, ví dụ cloud-control-branch).
• Tạo pipeline & kiểm tra trạng thái:

aws cloudcontrol create-resource --type-name "AWS::CodePipeline::Pipeline" --desired-state file://codepipeline.json --profile <deployment-account-profile>
aws cloudcontrol get-resource-request-status --request-token "RequestToken"

Bước 6 — Tạo DynamoDB table (lưu trạng thái/metadata triển khai)

aws cloudcontrol create-resource \
  --type-name "AWS::DynamoDB::Table" \
  --desired-state file://dynamodb_table.json \
  --region us-east-1 \
  --profile <deployment-account-profile>

Bước 7 — Cập nhật config YAML & kích hoạt pipeline

• Sửa các thông số trong thư mục scripts/ (Account IDs, VPC CIDR, Subnet CIDR, conventions…).
• Commit đẩy lên nhánh nguồn của CodePipeline → CodeBuild chạy buildspec gọi script triển khai theo các YAML.
• Tham khảo readme.md để biết cách scripts đọc YAML và gọi Cloud Control.

Mẹo kiểm thử: bắt đầu với 1 vùng/1 tài khoản thành viên, quan sát các request-token qua get-resource-request-status, sau đó mở rộng dần phạm vi.

Thiết kế & tư duy triển khai (Thought Process)

• Chọn Cloud Control thay vì thuần Cfn/CDK/Terraform: bạn có giao diện thống nhất, cập nhật nhanh khi AWS ra tính năng mới, và luồng phản hồi lỗi rõ ràng — giảm chi phí nhận thức & công nợ kỹ thuật.
• Tách concerns: quản trị đa tài khoản qua IAM AssumeRole + RAM ResourceShare; cấu hình mạng (TGW, Firewall) tách rời logic ứng dụng, để pipeline mạng có nhịp thay đổi độc lập.
• Cập nhật gia tăng: dùng read/list để nắm trạng thái đang chạy → chỉ update phần chênh lệch (route, rule, attachment).
• Quan sát & khôi phục: tận dụng get_resource_request_status trong pipeline để tự động retry/rollback theo kịch bản.

Best practices & vận hành

• Chuẩn hóa YAML: gom cấu hình theo domain (tuyến TGW, policy Firewall, mapping tài khoản/vùng) để dễ tái sử dụng & review.
• Tách pipeline: mạng (infra-network) riêng với ứng dụng; hạn chế blast radius khi thay đổi rule/tuyến.
• Kiểm soát thay đổi: PR + review với checklist (ảnh hưởng route, scope rule, tỉ lệ fail-open/close) trước khi merge nhánh kích hoạt pipeline.
• Đa vùng có chủ đích: dùng biến/param cho region-specific để tránh copy-paste cấu hình.
• Giám sát & nhật ký: log trạng thái resource request; quy ước gắn thẻ (tags) nhất quán để truy vết.

FAQ

Hỏi: Cloud Control có thay thế hoàn toàn CloudFormation/CDK/Terraform?
Đáp: Không nhất thiết. Điểm mạnh của Cloud Control là giao diện thống nhất và cập nhật nhanh; bạn có thể kết hợp các công cụ (ví dụ: giữ app IaC ở CDK, còn mạng động ở Cloud Control).

Hỏi: Cập nhật rule Network Firewall có cần redeploy stack?
Đáp: Đa phần chỉ cần update_resource; tuy có trường hợp phức tạp vẫn cần một số cấu hình bổ sung.

Hỏi: Đa tài khoản có khó không?
Đáp: Cloud Control tích hợp IAM AssumeRole & RAM giúp khai báo rõ ràng; các công cụ khác thường phải cấu hình thêm (StackSets, provider blocks…).

Hỏi: Làm sao tự động hóa rollback?
Đáp: Dựa vào trạng thái request (get_resource_request_status) trong pipeline để kích hoạt retry/rollback có điều kiện.

Kết luận

AWS Cloud Control API cung cấp CRUD-L nhất quán, nhận biết trạng thái theo thời gian thực, đơn giản hóa quản lý đa tài khoản/đa vùng, và tích hợp CI/CD mượt mà — đặc biệt hiệu quả cho mạng đám mây phức tạp. So với cách tiếp cận IaC truyền thống, Cloud Control giúp tăng tốc triển khai, giảm lỗi vận hành, và dễ mở rộng theo nhu cầu doanh nghiệp.

Về tác giả

• Shiva Vaidyanathan – Principal Cloud Architect, AWS. MS CS – Rutgers; MS EE – NYU; tập trung đơn giản hóa mạng đám mây với công nghệ GenAI.
• Omkar Nyalpelly – Chuyên gia kiến trúc mạng & tự động hóa, AWS Professional Services; kinh nghiệm sâu về Landing Zone & DevOps.

Phụ lục A — Mẫu so sánh rút gọn (tham khảo dán vào Table block)

Kết nối tập trung (Bảng 2 – điểm nhấn)

Kiểm tra lưu lượng (Bảng 3 – điểm nhấn)

Đa tài khoản (Bảng 4 – điểm nhấn)

Cập nhật động (Bảng 5 – điểm nhấn)

Tự động hoá (Bảng 6 – điểm nhấn)