Thiết kế này đặt toàn bộ hệ thống trong một region và không có một kết nối cross-region nào. Sẽ có 2 VPC đó là:

  • Production VPC
  • Management VPC

VPC_architecture

Chúng được kết nối với nhau thông qua VPC Peering. Và lớp mạng được chọn lựa để tránh đụng độ với các lớp mạng ở VPC khác (khi có nhu cầu peering giữa các region, AWS đã hỗ trợ peering giữa các region, trước đây phải tạo kết nối VPN, tham khảo thêm về AWS Inter-Region Latency) hoặc đụng độ với các lớp mạng nội bộ ở cty.

Với region us-east-1 có tổng cộng 6 availability zone là us-east-1a ,us-east-1b, us-east-1c, us-east-1d, us-east-1e, us-east-1f. Ta có thể sử dụng cả 6 zone hoặc sử dụng 3 zone để đảm bảo vấn đề rủi ro khi hạ tầng tại một DC bị hư hỏng (mỗi availability zone có địa chỉ vật lý khác nhau nhưng có thể chung một bang, tỉnh, thành phố).

Ví dụ ở đây ta chọn lớp mạng 10.20.0.0/16 cho VPC production, chia làm tổng cộng 9 subnet (mỗi 3 subnet sẽ nằm ở một availability zone), với:

  • 3 subnet public, với outboud traffic sẽ được route thông qua Intenet Gateway (IG). Tất cả các dịch vụ trong lớp mạng này đều là ELB hoặc EC2 có Elastic IP hoặc một NAT gateway.
  • 6 subnet còn lại là private subnet, muốn đi ra internet buộc phải đi thông qua NAT gateway được đặt ở public subnet và không có kết nối inbound trực tiếp vào bất kì server, dịch vụ nào trong các subnet này.
    • 3 subnet đầu là private subnet dành cho các dịch vụ tầng web (HTTP protocol, Websocket) ví dụ như web, api, worker, report … Các dịch vụ ở tầng này vẫn có nhu cầu kết nối ra bên ngoài khi thanh toán, chứng thực qua bên thứ 3 (facebook, google …) hoặc gửi email.
    • 3 subnet còn lại là private subnet dành cho persistence store như: database (RDBMS, NoSQL), cache cluster, queue cluster, search cluster, mail replay …

Về NAT gateway, ta có thể thiết kế theo 2 trường phái:

  • Chỉ sử dụng một NAT gateway cho tất cả các private subnet (bản thân NAT gateway đã có sẵn tính failover tương tự như ELB).
  • Mỗi cặp subnet ở mỗi AZ sẽ có một NAT gateway riêng, ta có 3 AZs thì sẽ có 3 NAT gateway tương ứng.

Ưu nhược điểm của 2 trường phái này dựa vào cách tính chi phí của AWS với NAT gateway:

  • Chi phí dựa trên giờ sử dụng.
  • Chi phí dựa trên data processing mà NAT gateway xử lý.
  • Một trường hợp đặc biệt nữa là nếu EC2 route ra internet mà qua một NAT gateway khác AZ sẽ bị tính phí.

Nên nếu có nhu cầu gửi traffic ra internet nhiều từ EC2 nằm trong private subnet (via NAT gateway) thì nên sử dụng nhiều NAT gateway tương ứng với từng AZ, còn nếu gửi ít thì có nhiều NAT gateway quá sẽ tốn kém cho chi phí giờ sử dụng [1].

Ngoài ra, nếu EC2 giao tiếp với các dịch vụ của AWS nhiều (ví dụ các tính năng upload/download dữ liệu trên S3) thì có thể cân nhắc sử dụng VPC Endpoint. Bản thân EC2 khi kết nối tới S3 sẽ là một kết nối internet như cách kết nối tới các dịch vụ khác bên ngoài hệ thống AWS. Chuyện này vừa tăng latency + chi phí về data transfer. Khi sử dụng VPC endpoint thì từ EC2 -> S3 sẽ là kết nối thông qua private address (đi nội bộ) giúp giảm chi phí và giảm latency kết nối.

Với VPC dành cho management sẽ đặt các dịch vụ dùng cho quản trị hệ thống như các hệ thống CI/CD, monitoring, logging, bastion, VPN … Thông qua kết nối VPC peering, ta có thể route request từ VPC này tới Production VPC. Ta cũng có thể tổ chức VPC management tương tự với 3 layer như Production VPC nếu muốn. Với VPC này, ta có thể cho phép DevOps engineer có thể kết nối thông qua VPN hoặc whitelist là static IP của công ty (như một jump box).

Mỗi layer sẽ có một security group hoạt động như một network firewall để cho phép/chặn các kết nối không cần thiết.

Theo tài liệu của AWS về Security trong VPC thì:

  • Security Group: hoạt động như một host-firewall gắn với một EC instance để control traffic In/Out tại instance level.
  • Network ACL: hoạt động như một network-firewall, gắn với subnets, controll traffic In/Out tại subnet level.

Các máy chủ nằm trong Prod VPC chỉ có thể truy cập SSH được từ management VPC (mở port 22 từ VPC này) và người quản trị buộc phải truy cập vào management VPC trước khi muốn truy cập vào hệ thống production (ssh hoặc quay VPN).

Trong Prod VPC:

  • Public subnet chỉ mở 80/443.
  • Private subnet dành cho web app, chỉ mở port 80.
  • Private subnet persistence store chỉ mở các port liên quan ví dụ MySQL - 3306/3307, ES - 9200/9300, Redis - 6371/6372, memcached - 11211/11212, MongoDB - 27017/30000, Postgres - 5432, Kafka/Zookeeper - 9092/2181.

Có thể thiết kế các security group như sau:

  • sg_prod_<project>_mgnt: Gắn vào tất cả các EC2 instance bên prod VPC, mở port 22 từ mgnt VPC.
  • sg_prod_<project>_lb: Gắn vào các EC2 instance nằm ở tầng public, mở port 80/443.
  • sg_prod_<project>_app: Gắn vào EC2 instance nằm ở tầng ứng dụng, subnet private, mở port 80.
  • sg_prod_<project>_data: Gắn vào các EC2 instance nằm ở tầng data, persistence store subnet, mở các port theo dịch vụ như ở trên.

Với Network ACL sẽ thiết kế như sau:

  • nacl_prod_<project>_public: Cho phép nhận inbound traffic từ bất kỳ đâu.
  • nacl_prod_<project>_app: Chỉ nhận traffic inbound từ duy nhất public subnet
  • nacl_prod_<project>_data: Chỉ nhận traffic inboud từ duy nhất app subnet (không nhận traffic từ public subnet)

BONUS 1: Việc thiết kế hệ thống … thực ra phụ thuộc vào ứng dụng đang phát triển, yêu cầu về security, tốc độ phát triển … Có một phiên bản đơn giản hơn của architecture trên đó là bỏ đi Management VPC và kết nối Peering. Thay vào đó ta sẽ đặt ssh-bastion, vpn service ở public layer, các dịch vụ devops khác có thể đặt trong các subnet tương ứng như các dịch vụ phục vụ cho user. Có những công ty làm về cổng thanh toán, ví điện tử, các cty có đội ngũ security riêng (ISO team) thì yêu cầu về security có thể cao hơn, họ kiểm soát cả các kết nối outbound (ra đâu, ra từ port nào, network interface nào, địa chỉ nguồn/đích ra sao), điều đó là dễ hiểu nhưng đồng thời sẽ có nhiều issue liên quan tới việc mở thiếu cổng, debug khó hơn, thời gian deploy lâu hơn …

BONUS 2: Thiết kế hệ thống mạng như vầy thực ra không hề mới (nếu bạn đã học qua CCNA/CCNP), từ khi bạn xây dựng các hệ thống physical thì các lý thuyết này cũng đã tồn tại rồi (không tin hỏi thử mấy bạn làm network engineer xem). Điểm khác biệt là với một hệ thống physical ta sẽ cần một số thiết bị mạng như sau:

  • Switch layer 3 hoạt động với 2 chức năng chính như router và chuyển mạch (switching) giữa các VLAN (VLAN là lớp mạng ảo, tương tự như Zone ở trên).
  • Switch layer 2 để chia mạng thành nhiều VLAN nhỏ, nhưng do hoạt động ở layer 2 lên các máy chủ trong một VLAN sẽ không thể giao tiếp được với nhau, nên như ở trên ta có switch layer 3.
  • Hardware Firewall hoạt động như một network firewall, kiểm soát truy cập giữa các VLAN, subnet.
  • Một thiết bị VPN chuyên dụng hoặc sử dụng hardware fw ở trên nếu có hỗ trợ.

Bài viết tham khảo mô hình dùng Mgnt VPC và kết nối VPC peering ở bài viết A Reference VPC Architecture của tác giả Ben Whaley từ DevOps checklist Gruntwork.

Một phiên bản khác tương tự từ https://www.boltops.com như sau:

boltops-example-architecture