Quân HuỳnhBài này nói về phần rất quan trọng là cách thiết kế networking cho nhiều tài khoản AWS khác nhau. Khi ta sử dụng AWS thì đa số các tài nguyên ta tạo đều nằm trong một Amazon Virtual Private Cloud (VPC), đây là phần cơ bản nhất khi ta làm việc với network trên AWS. Một số câu hỏi quan trọng ta cần trả lời khi thiết kế network cho nhiều tài khoản AWS khác nhau là: Chọn VPC CIRD Block như thế nào? Nên tạo VPC ở trên một tài khoản hay tạo nhiều VPC ở các tài khoản khác nhau? Thiết kế VPC và Subnet ra sao? Làm thế nào để kết nối nhiều VPC với nhau?
/w=3840,quality=90,fit=scale-down)
Chọn VPC CIRD Block
Đây là mục rất quan trọng, nếu chọn sai thì ta rất cực về sau. AWS khuyến nghị ta tạo CIDR Blocks 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)
AWS VPC hỗ trợ block trong khoảng /16 (65,536 IP addresses) và /28 (16 IP addresses), ví dụ: 10.1.0.0/16, 172.30.0.0/16. Một số lưu ý khi chọn CIDR Blocks là tránh bị đụng với một vài AWS Services, ví dụ như AWS Cloud9 hoặc Amazon SageMaker thường dùng block 172.17.0.0/16.
Tiếp theo là ta cần xem xét trước CIDR Blocks của hạ tầng on-prem, toàn bộ ngân hàng đều có hạ tầng on-prem và khi ta triển khai các dịch vụ mới lên Cloud thì việc kết nối giữa on-prem và Cloud là việc chắc chắn phải làm. AWS có dịch vụ Direct Connect để kết nối hạ tầng on-prem và Cloud, và muốn kết nối được bằng Direct Connect thì bắt buộc CIDR Blocks của on-prem và Cloud phải khác nhau. Do đó khi lựa CIDR Blocks cho VPC ta phải tránh trùng với CIDR Blocks của on-prem.
Tiếp theo là chọn khoảng hợp lý, ví dụ ta cần tạo VPC để triển khai khoảng 3 cái AWS Application Load Balancer, mỗi ALB có 3 IP, 3 thằng là 9 IP thì ta không cần phải tạo CIDR Blocks tới /16 (65,536 IP addresses). Nhưng cũng đừng tạo quá nhỏ, ví dụ /26 chỉ có khoảng 60 IP dùng được mà ta cần triển khai hệ thống Microservices lên tới hàng trăm IP thì /26 không chứa nổi. Phần bên dưới mình sẽ hướng dẫn tùy vào mục đích của VPC ta có thể nhắm được số lượng IP phù hợp.
VPC trên nhiều tài khoản AWS
Với AWS thì VPC là tài nguyên gắn liền với một tài khoản, có nghĩa là khi ta tạo VPC thì chỉ có một tài khoản sử dụng được VPC đó, vậy với môi trường ta cần giao tiếp VPC giữa các tài khoản khác nhau ta cần làm thế nào? Lấy ví dụ các tài khoản nonprod ở bài AWS Account Management:
- networking-nonprod
- workload-nonprod
- operation-nonprod
- observability-nonprod
- data-nonprod
Ta có hai cách sau để thiết kế VPC trên nhiều tài khoản AWS:
- Tạo tất cả VPC ở tài khoản networking-nonprod và dùng VPC Sharing để chia sẻ VPC cho các tài khoản khác
- Tạo VPC riêng trên từng tài khoản
Với cách đầu tiên ta tạo toàn bộ VPC cần thiết ở tài khoản networking-nonprod.
/w=3840,quality=90,fit=scale-down)
Sau đó dùng VPC Sharing để chia sẻ VPC với các tài khoản khác.
Cách thứ hai ta tạo riêng VPC trên từng tài khoản, không cần tạo toàn bộ trên tài khoản networking-nonprod.
/w=3840,quality=90,fit=scale-down)
Với cách này, từng tài khoản sẽ tự quản lý VPC riêng của mình. Cả hai cách đều có ưu và nhược điểm riêng.
Đối với cách đầu tiên, chúng ta dễ dàng quản lý mọi thứ trên tài khoản networking, từ VPC đến route table, NAT, Transit Gateway. Các tài khoản khác chỉ cần sử dụng VPC được chia sẻ. Tuy nhiên, nhược điểm là chỉ có thể chia sẻ với các tài khoản cùng AWS Organization. Nếu chúng ta cần chuyển các tài khoản không phải networking-nonprod qua Organization khác để dùng ưu đãi credit của tài khoản mới, việc tách Organization sẽ rất khó khăn vì toàn bộ tài nguyên đều nằm trong VPC của networking-nonprod. Trong trường hợp Organization khác đã có tài khoản networking, có thể chúng ta phải tạo lại tài nguyên.
Cách thứ hai giúp chúng ta dễ dàng tách Organization vì mỗi tài khoản đều có VPC riêng. Chúng ta chỉ cần rời Organization cũ và tham gia Organization mới. Tuy nhiên, việc cấu hình network và route sẽ khó khăn hơn vì phải chuyển đổi giữa các tài khoản khác nhau. Tùy thuộc vào trường hợp mà chúng ta chọn cách phù hợp. Bên mình sử dụng Terraform để tạo hạ tầng nên việc cấu hình rất dễ dàng, do đó hạ tầng Vikki dùng cách hai.
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.
/w=3840,quality=90,fit=scale-down)
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.
/w=3840,quality=90,fit=scale-down)
Đố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 và Subnet cho các tài khoản còn lại
Các tài khoản còn lại có thể thiết kế VPC đơn giản với tên VPC tương ứng với từng tài khoản hoặc tùy thuộc vào chức năng của nó. Ví dụ, tài khoản observability môi trường prod có thể tạo 3 VPC là Monitoring VPC, Logging VPC và Tracing VPC. Còn môi trường nonprod thì đơn giản hóa bằng cách tạo một VPC tên là Observability VPC với subnet tương ứng cho từng chức năng.
/w=3840,quality=90,fit=scale-down)
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.
/w=3840,quality=90,fit=scale-down)
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 ở bài này: Centralized outbound routing to the internet.
Bài tiếp theo mình sẽ nói về EKS for Multi AWS Accounts.
Điểm hẹn ngân hàng số Vikki by HDBank
Loạt bài viết ngắn chia sẻ về kiến trúc hạ tầng của hệ thống ngân hàng trên Cloud (AWS). Đây chỉ là những kiến thức mình học được thông qua sản phẩm NGÂN HÀNG SỐ VIKKI của bên mình, nên kiến trúc có thể phù hợp và không phù hợp với doanh nghiệp của các bạn.
- AWS Account Management
- Provisioning Infrastructure for Multi AWS Accounts
- Networking for Multi AWS Accounts
- Kubernetes for Multi AWS Accounts: Kubernetes Infrastructure for Scale
- Kubernetes for Multi AWS Accounts: Kubernetes Cross Cluster Communication
- Chaos Engineering
- On-call
- Core Banking on Cloud
- Security Consider