[AWS Series - Bài 3] Public, Private & Hybrid Cloud - Giấu kín hệ thống của bạn trước "giông bão" Internet

Chào anh em, ở bài trước chúng ta đã chọn được "loại nhà" (IaaS, PaaS, SaaS) để chứa code của mình. Hôm nay, chúng ta sẽ bàn về việc đặt ngôi nhà đó ở đâu. Bạn muốn xây nhà mặt tiền phố lớn (dễ buôn bán nhưng đầy rẫy trộm cắp), hay xây một pháo đài biệt lập trong rừng sâu?

Trong kiến trúc Cloud và thiết kế hệ thống, chúng ta gọi đó là các mô hình triển khai: Public, Private và Hybrid Cloud. Lựa chọn sai mô hình, hệ thống của bạn không chỉ tốn tiền vô ích mà còn có nguy cơ phơi trần toàn bộ Database chứa thông tin nhạy cảm ra ngoài Internet.

1. Public Cloud (Đám mây công cộng) - Mảnh đất nhộn nhịp, đa cực

Bản chất: Bạn thuê tài nguyên trên cùng một hạ tầng vật lý với hàng ngàn, hàng vạn khách hàng khác của AWS. Nó giống như bạn thuê một căn hộ trong một chung cư khổng lồ. Các căn hộ được cách ly với nhau bằng "tường ảo" (Virtualization), nhưng vẫn chung móng, chung thang máy.

Góc nhìn Backend & Kiến trúc:

Hầu hết các dịch vụ chúng ta hay xài trên AWS đều mang hơi hướng Public (như S3, API Gateway, CloudFront).

• Ưu điểm: Cực kỳ rẻ, không giới hạn tài nguyên. Đợt Sale 11/11 traffic x100 lần? Không sao, auto-scaling gọi thêm hàng chục con EC2 trong chớp mắt.
• Nỗi đau (Trade-off): Rủi ro bảo mật (Security). Nếu bạn đặt một con server chứa Node.js hoặc Golang API ra Public Cloud mà quên không config Security Group (Tường lửa) đàng hoàng, ai cũng có thể ping hoặc scan port server của bạn. Thêm nữa là hiện tượng "Noisy Neighbor" (Hàng xóm ồn ào) - dù hiếm, nhưng thi thoảng server vật lý chạy EC2 của bạn bị một gã hàng xóm nào đó vắt kiệt tài nguyên, khiến app của bạn bị chậm lây.

2. Private Cloud (Đám mây riêng) - "Lãnh địa cấm" của Backend

Bản chất: Hạ tầng điện toán được dành riêng cho một tổ chức duy nhất. Nó có thể là một phòng máy chủ đặt tại công ty bạn (On-premise), hoặc bạn thuê hẳn máy chủ vật lý riêng biệt của AWS (Dedicated Hosts).

Góc nhìn Backend & Kiến trúc: Trong thực tế phát triển trên AWS, "Private" thường được anh em backend hiểu là Private Subnet bên trong mạng ảo VPC (Virtual Private Cloud). Đây là nơi trú ngụ của những thứ "cốt tủy" tuyệt đối không được phép nhìn thấy ánh sáng Internet.

Ví dụ: Bạn có một cụm Database PostgreSQL, một Cluster Redis để cache, và vài con Microservices nội bộ chuyên tính toán logic lõi (như xử lý giao dịch thanh toán). Những thứ này phải được ném vào Private Cloud/Private Subnet. Chúng không có Public IP. Hacker bên ngoài Internet dù có biết IP cũng không thể mò tới được.

Code Demo (Tư duy Infrastructure as Code):

Thay vì click chuột mỏi tay trên giao diện AWS, dân chơi hệ thống sẽ dùng script để định nghĩa một mạng Private. Dưới đây là cách dùng AWS CLI để tạo một subnet mà mọi kết nối từ bên ngoài Internet đều bị chặn đứng:

# 1. Tạo một Subnet trong VPC (Không gán Public IP tự động)
aws ec2 create-subnet \
    --vpc-id vpc-0123456789abcdef0 \
    --cidr-block 10.0.1.0/24 \
    --availability-zone ap-southeast-1a \
    --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=Database-Private-Subnet}]'

# 2. Ngăn chặn tự động cấp phát Public IP cho mọi EC2 nằm trong Subnet này
aws ec2 modify-subnet-attribute \
    --subnet-id subnet-0abc12345def67890 \
    --no-map-public-ip-on-launch

Hành động nhỏ, ý nghĩa lớn: Bất kỳ con Database hay Service nào khởi tạo trong 10.0.1.0/24 sẽ an toàn tuyệt đối trước các đợt rà quét từ Internet.

3. Hybrid Cloud (Đám mây lai) - Sự thỏa hiệp hoàn hảo

Bản chất: Sự kết hợp giữa Public Cloud và Private Cloud. Giống như bạn có một cửa hàng mặt tiền để đón khách (Public), nhưng kho tiền và xưởng sản xuất thì đặt ở một hầm ngầm bí mật (Private), hai bên kết nối với nhau bằng một đường hầm riêng.

Góc nhìn Backend & Kiến trúc:

Đây là kiến trúc thực tế nhất của các tập đoàn lớn hoặc các hệ thống E-commerce. Tại sao không cho tất cả lên AWS Public luôn? Vì những lý do như:

1. Luật pháp & Compliance: Dữ liệu người dùng, thông tin thẻ tín dụng bắt buộc phải lưu ở máy chủ vật lý đặt tại quốc gia sở tại.
2. Hệ thống Legacy: Công ty có một con ERP hoặc máy chủ Mainframe "cổ đại" chạy từ chục năm trước, không thể đập đi xây lại trên Cloud được.

Luồng hoạt động thực tế:

1. User dùng app, gửi request mua hàng đến API chạy trên Public Cloud (AWS EC2/EKS) để tận dụng sức mạnh xử lý lượng lớn kết nối (Auto Scaling, Load Balancing).
2. Khi cần thanh toán hoặc tra cứu tồn kho, Backend API trên AWS sẽ định tuyến request qua một đường ống bảo mật (như AWS Direct Connect hoặc Site-to-Site VPN) đi thẳng về con Database nằm ở Private Cloud (On-premise) của công ty.

Tạm kết

Tóm lại, nếu hệ thống của bạn là một pháo đài:

• Public Cloud: Là tường thành, cổng chính và lính gác (Web server, API Gateway). Đứng ra chịu sào đón khách và đỡ đạn (DDoS).
• Private Cloud: Là cung điện bên trong, nơi vua chúa (Database, Core Logic) làm việc an toàn, cách ly hoàn toàn với bên ngoài.
• Hybrid Cloud: Là cây cầu treo bọc thép nối giữa cung điện và thế giới bên ngoài.

Tuy nhiên, nãy giờ chúng ta nhắc rất nhiều đến khái niệm tạo "tường ảo", chia "phân khu", chặn IP... Trên AWS, tất cả những phép màu mạng mẽo đó được thực hiện bởi một dịch vụ quyền lực nhất, trái tim của mọi kiến trúc Cloud.