Bài 3: Networking trong môi trường Multi AWS

Giới thiệu

Thiết kế networking trong môi trường Multi AWS Accounts là một bước quan trọng và phức tạp khi triển khai hạ tầng ngân hàng trên AWS. Networking không chỉ là nền tảng cho việc vận hành các ứng dụng mà còn ảnh hưởng lớn đến hiệu suất, bảo mật và khả năng mở rộng của hệ thống. Bài viết này sẽ hướng dẫn cách thiết kế và quản lý networking hiệu quả trong môi trường Multi AWS Accounts.

Chọn VPC CIDR Block

CIDR Block xác định phạm vi địa chỉ IP cho VPC và là yếu tố cần được quyết định cẩn thận:

AWS khuyến nghị sử dụng dải địa chỉ theo RFC 1918:

• 10.0.0.0 – 10.255.255.255 (10/8 prefix)
• 172.16.0.0 – 172.31.255.255 (172.16/12 prefix)
• 192.168.0.0 – 192.168.255.255 (192.168/16 prefix)

Một số lưu ý:

• Tránh trùng lặp CIDR với hạ tầng on-prem vì các hệ thống thường cần kết nối thông qua AWS Direct Connect.
• Tránh các block phổ biến mà AWS Services sử dụng (vd: 172.17.0.0/16 cho Amazon SageMaker).
• Đặt CIDR Block phù hợp với quy mô VPC:
  • Không quá lớn (vd: /16 cho ứng dụng nhỏ sẽ lãng phí IP).
  • Không quá nhỏ (vd: /26 không đủ cho hệ thống microservices lớn).

Ví dụ: Một VPC dành cho ứng dụng có 3 Load Balancers (9 IP) và 100 microservices, CIDR Block /22 (1,024 IP) là phù hợp.

VPC trên nhiều tài khoản AWS

Khi triển khai hạ tầng Multi AWS Accounts, ta có hai cách để tổ chức VPC:

Tạo tất cả VPC trên một tài khoản duy nhất

Ta tạo toàn bộ VPC cần thiết ở tài khoản networking-nonprod.

Sau đó dùng VPC Sharing để chia sẻ VPC với các tài khoản khác.

Ưu điểm:

• Dễ quản lý tài nguyên mạng (Route Tables, NAT Gateways, Transit Gateway).
• Tập trung hóa quản lý networking.

Nhược điểm:

• Chỉ áp dụng được trong cùng một AWS Organization.
• Việc tách tài khoản sang Organization khác rất phức tạp.

Tạo VPC riêng trên từng tài khoản

Mỗi tài khoản tự quản lý VPC của mình.

Ưu điểm:

• Linh hoạt khi tách hoặc di chuyển tài khoản.

Nhược điểm:

• Phức tạp hơn trong việc kết nối mạng giữa các VPC.

Lựa chọn: Với sản phẩm ngân hàng số Vikki, đội mình chọn cách tạo VPC riêng trên từng tài khoản để đảm bảo tính linh hoạt khi quản lý tổ chức.

Thiết kế VPC và Subnet cho tài khoản Networking

Về việc thiết kế VPC và Subnet, chúng ta xem xét tính năng của từng tài khoản rồi đặt tên VPC theo tính năng và chia Subnet tương ứng. Ví dụ, ở networking-nonprod, chúng ta cần kiểm soát network đi vào và ra nên tạo hai VPC là nonprod-ingress và nonprod-egress.

Với VPC nonprod-ingress là nơi mạng đi vào hệ thống của chúng ta. Public subnet của nonprod-ingress thường dùng để triển khai AWS Application Load Balancer, Network Load Balancer, AWS API Gateway dạng public, sau đó chúng ta trỏ DNS tới những thành phần này. Private subnet dùng để triển khai các proxy với mục đích điều hướng request qua các VPC khác.

Tất cả mạng gọi ra ngoài internet đều phải đi qua nonprod-egress. Egress subnet thường được triển khai AWS NAT Gateway để điều hướng request ra ngoài internet.

Trường hợp ta cần kết nối tới các hệ thống khác hoặc hạ tầng on-prem, ta tạo thêm một VPC tên là nonprod-integration, sau đó tạo AWS Direct Connect để kết nối với on-prem.

Đối với môi trường production yêu cầu bảo mật cao thì cần tạo một VPC để triển khai các công cụ bảo mật như firewall, WAF và điều hướng toàn bộ request đi vào VPC này trước khi muốn đi đâu, ta có thể đặt tên VPC này là Security VPC.

Thiết kế VPC cho các tài khoản khác

Tài khoản Workload:

• Tạo VPC đơn giản, phục vụ ứng dụng và cơ sở dữ liệu.
• Subnet: Tách biệt các thành phần ứng dụng (App, DB, Cache).

Tài khoản Observability:

• Tách VPC theo chức năng:
  • Monitoring VPC: Giám sát hiệu suất.
  • Logging VPC: Thu thập và lưu trữ log.
  • Tracing VPC: Theo dõi luồng dữ liệu.
• Với môi trường nonprod, có thể đơn giản hóa bằng cách gộp thành một VPC duy nhất: Observability VPC.

Kết nối nhiều VPC với nhau

Cuối cùng là vấn đề rất quan trọng là ta làm thế nào để kết nối toàn bộ VPC lại với nhau? Dùng VPC Peering? Peering chỉ phù hợp khi ta cần kết nối 2 VPC với nhau, còn với nhiều VPC thì ta nên dùng AWS Transit Gateway.

Ta điều hướng toàn bộ request mà không gọi nội bộ trong VPC ra ngoài bằng Transit Gateway. Sau đó, ở Transit Gateway, ta điều hướng request tới VPC khác thông qua Transit Gateway Attachment. Các bạn có thể tìm hiểu kỹ hơn về cách điều hướng ở đây: Centralized outbound routing to the internet.

Kết luận

Thiết kế networking trong môi trường Multi AWS Accounts đòi hỏi sự cân nhắc kỹ lưỡng về cấu trúc CIDR Block, tổ chức VPC và kết nối mạng. Bằng cách áp dụng các công cụ như AWS Transit Gateway và tuân thủ các best practices, bạn có thể xây dựng một hệ thống mạng an toàn, hiệu quả và dễ mở rộng.

Bài tiếp theo, chúng ta sẽ tìm hiểu cách triển khai EKS (Kubernetes) trong môi trường Multi AWS Accounts.

Trích: Quân Huỳnh – Cloud Engineer, Tác giả trang devopsvn.tech