title: "System Design với AI: Cách dùng AI phác thảo sơ đồ AWS/GCP (EC2, Fargate, Transit Gateway)"
series: "AI-Native Solutions Architect: Từ Coder đến Kiến trúc sư AI"
season: "Season 2 — AI-Augmented Architecture & System Design"
order: 11
audience: "Software Engineer hướng tới Solutions Architect"
reading_time: "14 phút"
tags: ["system-design", "aws", "architecture", "ec2", "fargate", "transit-gateway", "ai-native", "solutions-architect"]

System Design với AI: Cách dùng AI phác thảo sơ đồ AWS/GCP (EC2, Fargate, Transit Gateway)

Bạn được giao thiết kế backend cho một hệ thống mới — không phải thêm feature vào hệ thống có sẵn, mà bắt đầu từ một trang giấy trắng. Traffic dự kiến tăng vọt vào một số thời điểm trong năm, ngân sách hạ tầng có giới hạn, và deadline để trình bày kiến trúc sơ bộ là cuối tuần này. Bạn mở một file trắng, viết "API Gateway → Load Balancer →..." rồi dừng lại. Compute chạy trên gì? Database nào chịu được spike gấp 10 lần baseline mà không sập? Network giữa các VPC nếu hệ thống cần tách theo môi trường hoặc theo team thì sao? Mỗi câu hỏi mở ra ba câu hỏi khác, và bạn nhận ra brainstorm một mình dễ bỏ sót — không phải vì thiếu kiến thức, mà vì không đủ thời gian để tự phản biện mọi phương án trong đầu.

Đây là điểm khác biệt căn bản giữa "viết code" và "thiết kế kiến trúc": code sai có thể sửa trong một PR, kiến trúc sai — chọn nhầm compute model, thiếu chiến lược network ngay từ đầu, bỏ sót yêu cầu về độ sẵn sàng — thường chỉ lộ ra sau vài tháng vận hành, lúc chi phí sửa đã tăng gấp nhiều lần. Brainstorm kiến trúc một mình chậm và dễ sót vì bộ nhớ làm việc của con người có giới hạn: bạn nhớ tốt phần mình quen thuộc (ví dụ EC2 vì đã dùng nhiều), nhưng dễ quên phần ít khi động tới (networking giữa nhiều VPC, security group rules, chiến lược scale ngoài auto-scaling cơ bản).

Season 1 của series này là về việc dùng AI để viết code nhanh hơn, đúng hơn. Season 2 bắt đầu từ đây: dùng AI như một đối tác brainstorm kiến trúc — không phải để AI quyết định thay bạn, mà để AI mở rộng không gian phương án nhanh hơn bạn tự làm một mình, rồi bạn dùng kinh nghiệm Solutions Architect để phản biện và cắt gọt. Bài này dùng một ví dụ cụ thể — backend đặt phòng khách sạn có traffic tăng đột biến theo mùa — để minh hoạ toàn bộ quy trình đó trên AWS.

Vấn đề

Ba nguyên nhân khiến brainstorm kiến trúc một mình chậm và dễ sót, nếu không có công cụ hỗ trợ đúng cách:

1. Không gian phương án quá lớn để duyệt hết trong đầu. Chỉ riêng câu hỏi "compute chạy trên gì" đã có ít nhất năm phương án hợp lý trên AWS (EC2 self-managed, EC2 Auto Scaling Group, ECS trên EC2, Fargate, Lambda), mỗi phương án có trade-off khác nhau về chi phí vận hành, tốc độ scale, và độ phức tạp khi debug. Nhân với các quyết định khác (database, caching, network topology, CDN, disaster recovery) thì tổng số tổ hợp phương án lớn tới mức một kỹ sư đơn lẻ, trong một buổi brainstorm, không thể liệt kê hết — chưa nói tới so sánh trade-off của từng tổ hợp.

2. Kiến thức về networking (VPC, Transit Gateway, security group) thường không phải sở trường của người quen viết code ứng dụng. Một backend engineer giỏi có thể thiết kế domain model, viết business logic sạch, tối ưu query — nhưng ít khi phải tự tay thiết kế multi-VPC topology hay quyết định khi nào cần Transit Gateway thay vì VPC Peering đơn giản. Đây chính xác là phần dễ bị bỏ sót nhất trong bản phác thảo đầu tiên, vì nó nằm ngoài vùng kinh nghiệm hàng ngày.

3. Brainstorm một mình thiếu vai trò phản biện. Khi tự thiết kế, bạn dễ chốt phương án đầu tiên nghe hợp lý rồi đi tiếp, vì không có ai hỏi ngược "vì sao chọn cái này mà không phải cái kia". Một kiến trúc sư kinh nghiệm khi làm việc nhóm luôn có đồng nghiệp phản biện trong buổi design review — nhưng không phải lúc nào cũng có sẵn người đó đúng lúc bạn cần, đặc biệt ở giai đoạn phác thảo sơ bộ trước khi đưa ra review chính thức.

AI không giải quyết được vấn đề thứ 3 một cách hoàn chỉnh — AI không có trách nhiệm nghề nghiệp (accountability) với hệ thống bạn build, không chịu hậu quả nếu kiến trúc sai. Nhưng AI giải quyết tốt vấn đề 1 và 2: liệt kê nhanh không gian phương án, nhắc các thành phần networking/security dễ bị quên, và — quan trọng nhất trong bài này — đóng vai trò để BẠN luyện tư duy phản biện bằng cách hỏi ngược lại AI, thay vì chấp nhận đề xuất đầu tiên.

Kỹ thuật cốt lõi

Quy trình dùng AI brainstorm kiến trúc có ba bước, và bước 3 là bước hay bị bỏ qua nhất trong thực tế:

flowchart TD
    A["1. Cung cấp yêu cầu phi chức năng cụ thể<br/>(traffic, ngân sách, độ sẵn sàng, ràng buộc)"] --> B["2. AI đề xuất kiến trúc tham khảo<br/>(danh sách thành phần + vai trò)"]
    B --> C["3. Phản biện & tinh chỉnh cùng AI<br/>(hỏi ngược, yêu cầu phương án thay thế, ép so sánh trade-off)"]
    C --> D{"Đủ vững chưa?"}
    D -- "Chưa — còn điểm mơ hồ" --> C
    D -- "Rồi" --> E["Kiến trúc phác thảo<br/>đưa vào design review với người"]

    style A fill:#59c,stroke:#333,stroke-width:1px
    style B fill:#5a5,stroke:#333,stroke-width:1px
    style C fill:#c93,stroke:#333,stroke-width:1px
    style E fill:#c55,stroke:#333,stroke-width:1px

Bước 1 — Yêu cầu phi chức năng (Non-Functional Requirements, NFR) cụ thể là đầu vào quan trọng nhất. Đây là điểm khác biệt lớn nhất giữa hỏi AI kiến trúc "cho một hệ thống booking khách sạn" (mơ hồ, AI sẽ tự đoán và đoán sai) so với hỏi kèm số liệu cụ thể: traffic baseline và traffic đỉnh (peak/baseline ratio), ngân sách hạ tầng hàng tháng, RTO/RPO (Recovery Time Objective/Recovery Point Objective) nếu có yêu cầu, và các ràng buộc tổ chức (ví dụ: bắt buộc multi-VPC vì compliance, hoặc team ops nhỏ nên ưu tiên managed service). Càng cụ thể, AI càng ít phải đoán, và output càng sát với bài toán thật thay vì một kiến trúc "textbook" chung chung.

Bước 2 — Kiến trúc AI đề xuất là điểm khởi đầu, không phải kết luận. AI có xu hướng đề xuất kiến trúc "đầy đủ tính năng" — dùng nhiều managed service, có multi-AZ, có auto-scaling, có caching layer — vì đó là câu trả lời "an toàn" thống kê từ dữ liệu huấn luyện, không phải câu trả lời tối ưu cho ngân sách và quy mô cụ thể của bạn.

Bước 3 — Phản biện là bước quyết định giá trị của cả quy trình. Không hỏi AI một lần rồi copy nguyên bản đề xuất vào tài liệu thiết kế. Thay vào đó, chủ động hỏi ngược: "Tại sao chọn Fargate thay vì EC2 Auto Scaling Group ở đây?", "Nếu ngân sách giảm 40% thì kiến trúc đổi thế nào?", "Có cần Transit Gateway hay VPC Peering đơn giản là đủ với 2 VPC?". Đây là kỹ năng tương đương "Advanced Prompting" đã nói ở Bài 3 (Chain-of-Thought), áp dụng vào ngữ cảnh kiến trúc: ép AI giải thích lý do (reasoning) thay vì chỉ đưa kết luận, để bạn có cơ sở đánh giá thay vì chỉ có một danh sách thành phần không rõ vì sao.

Thực hành

Prompt mẫu: phác thảo kiến trúc AWS cho backend booking khách sạn

Dưới đây là prompt nguyên văn — copy dùng được ngay, điền lại số liệu theo hệ thống thật của bạn ở phần [NFR]:

Bạn là Solutions Architect có kinh nghiệm thiết kế hệ thống trên AWS.
Tôi cần phác thảo kiến trúc backend cho một hệ thống đặt phòng khách sạn
(hotel booking), với các yêu cầu phi chức năng sau:

TRAFFIC:
- Baseline: ~500 request/giây vào giờ thấp điểm trong năm
- Đỉnh mùa cao điểm (hè, lễ Tết): gấp 8-10 lần baseline, kéo dài 2-3 tuần liên tục
- Traffic tăng dần trong vài ngày trước đỉnh mùa (không phải spike tức thời như flash sale)

NGÂN SÁCH:
- Compute + network: tối đa 4,000 USD/tháng ở baseline
- Chấp nhận tăng chi phí trong giai đoạn cao điểm, miễn không vượt 12,000 USD/tháng

ĐỘ SẴN SÀNG:
- Uptime mục tiêu 99.9% (không cần 99.99% — hệ thống không phải hạ tầng
  an toàn tính mạng)
- Chấp nhận downtime ngắn (vài phút) khi deploy, không chấp nhận downtime
  khi traffic tăng đột biến theo mùa

RÀNG BUỘC TỔ CHỨC:
- Team vận hành gồm 3 backend engineer, không có DevOps chuyên trách
  → ưu tiên managed service, hạn chế thứ phải tự quản lý (patch OS, tự
    scale cluster thủ công)
- Hệ thống cần tách biệt network giữa môi trường production và một hệ thống
  reporting/analytics nội bộ (VPC riêng), nhưng vẫn cần đọc dữ liệu booking
  gần real-time từ production sang analytics

YÊU CẦU:
1. Đề xuất kiến trúc compute cụ thể (so sánh EC2 Auto Scaling Group vs
   ECS Fargate vs Lambda cho use case này, chọn một phương án và giải thích
   vì sao loại hai phương án còn lại).
2. Đề xuất chiến lược kết nối network giữa VPC production và VPC
   analytics (so sánh VPC Peering vs Transit Gateway, chọn một và giải
   thích ngưỡng khi nào nên đổi sang phương án còn lại).
3. Đề xuất chiến lược scale cho giai đoạn cao điểm theo mùa (không phải
   traffic đột biến tức thời) — có cần pre-warm hay scheduled scaling
   không, hay auto-scaling reactive là đủ.
4. Liệt kê rõ các thành phần networking/security dễ bị bỏ sót trong bản
   phác thảo đầu tiên (security group, NAT Gateway, VPC endpoint...).
5. Trình bày kết quả dưới dạng bảng: Thành phần | Vai trò | Lý do chọn.

Sau khi bạn đề xuất xong, tôi sẽ hỏi phản biện thêm — đừng coi đề xuất
đầu tiên là kết luận cuối cùng.

Bảng tóm tắt kiến trúc đề xuất (ví dụ output đã được biên tập)

Sau vòng hỏi-đáp đầu tiên với AI theo prompt trên, kiến trúc tham khảo có thể trông như sau (đây là ví dụ minh hoạ hình dạng câu trả lời hợp lý, không phải kết luận đúng cho mọi trường hợp — vẫn cần phản biện ở bước tiếp theo):

Thành phần	Vai trò	Lý do chọn
Application Load Balancer (ALB)	Phân phối traffic vào tầng compute, terminate TLS, route theo path (`/api/booking`, `/api/search`...)	Managed, tích hợp sẵn health check và auto-scaling trigger, không cần tự quản lý load balancer
ECS trên Fargate	Chạy container backend (booking service, search service), scale theo CPU/memory hoặc request count	Team không có DevOps chuyên trách — Fargate loại bỏ việc tự vá lỗi OS, quản lý EC2 instance, capacity planning thủ công so với EC2 Auto Scaling Group; phù hợp traffic tăng dần theo mùa (không cần tốc độ scale-to-zero cực nhanh của Lambda, và workload có state kết nối lâu dài hơn phù hợp container hơn function)
EC2 (Reserved Instances) cho một số service ổn định, ít biến động	Chạy các service nền tải trọng dự đoán được (ví dụ worker xử lý email xác nhận đặt phòng)	Traffic của các service này không biến động theo mùa như booking chính — dùng Reserved Instance rẻ hơn Fargate on-demand cho tải trọng ổn định, tận dụng đúng chỗ mỗi loại compute mạnh nhất
RDS Multi-AZ (PostgreSQL)	Lưu dữ liệu booking, phòng, khách hàng — nguồn sự thật (source of truth)	Multi-AZ đáp ứng yêu cầu 99.9% uptime với failover tự động, managed service giảm gánh nặng vận hành cho team nhỏ
ElastiCache (Redis)	Cache kết quả tìm phòng, trạng thái phòng trống theo ngày, giảm tải truy vấn RDS khi traffic đỉnh mùa	Đọc (search phòng trống) chiếm phần lớn traffic ở cao điểm — cache đúng chỗ giảm tải RDS nhiều hơn là tăng compute
Application Auto Scaling (scheduled + target tracking)	Tăng số task Fargate trước khi vào mùa cao điểm theo lịch đã biết trước, kết hợp auto-scaling phản ứng theo CPU/traffic thực tế	Traffic cao điểm tăng dần trong vài ngày (không phải spike tức thời) — kết hợp scheduled scaling (biết trước lịch cao điểm mùa hè/Tết) với target-tracking scaling tránh độ trễ cold-start nếu chỉ dựa auto-scaling reactive
Transit Gateway	Kết nối VPC production với VPC analytics, cho phép mở rộng thêm VPC khác trong tương lai (ví dụ VPC riêng cho staging, cho một hệ thống đối tác) mà không phải thiết lập peering riêng từng cặp	Với 2 VPC, VPC Peering đơn giản và rẻ hơn — nhưng ràng buộc tổ chức nói rõ có nhu cầu mở rộng (thêm hệ thống reporting/analytics, khả năng thêm VPC khác sau này); Transit Gateway đáng chi phí thêm khi số VPC dự kiến ≥ 3, tránh phải thiết lập lại toàn bộ network khi mở rộng
VPC Endpoint (Gateway/Interface) cho S3, RDS Data API	Cho phép service trong VPC production truy cập S3 (lưu ảnh phòng, hoá đơn PDF) và các AWS service khác mà không đi qua Internet Gateway/NAT	Giảm chi phí NAT Gateway data transfer, giảm bề mặt tấn công vì traffic không ra Internet công cộng
NAT Gateway	Cho phép service trong private subnet gọi ra ngoài (ví dụ gọi payment gateway bên thứ ba)	Bắt buộc nếu compute đặt trong private subnet (khuyến nghị bảo mật chuẩn) — đây là thành phần dễ quên nhất khi phác thảo lần đầu, và cũng là nguồn chi phí ẩn hay bị bỏ sót khi ước tính ngân sách
Security Group (theo tầng)	Giới hạn traffic: ALB → ECS chỉ mở port ứng dụng, ECS → RDS chỉ mở port DB, không có rule mở rộng "allow all"	Nguyên tắc least privilege ở tầng network — thành phần dễ bị làm sơ sài nhất ("mở hết cho nhanh rồi siết sau") nếu không có ai nhắc lại lúc phác thảo

Ví dụ câu hỏi phản biện tiếp theo (Bước 3 trong quy trình)

Sau khi có bảng trên, đây là dạng câu hỏi nên hỏi tiếp — không chấp nhận nguyên bản:

1. Bạn chọn Transit Gateway thay vì VPC Peering — nhưng hiện tại tôi chỉ
   có đúng 2 VPC (production, analytics), chưa có kế hoạch cụ thể thêm VPC
   thứ ba trong 12 tháng tới. Với chi phí Transit Gateway tính theo giờ +
   theo GB data processed, so với VPC Peering miễn phí (chỉ trả data
   transfer), chênh lệch chi phí ước tính là bao nhiêu ở traffic của tôi?
   Có đáng trả thêm cho "khả năng mở rộng trong tương lai" không, hay tôi
   nên dùng Peering trước và migrate sang Transit Gateway khi thực sự có
   VPC thứ ba?

2. Bạn đề xuất RDS Multi-AZ — nhưng với uptime mục tiêu chỉ 99.9%
   (không phải 99.99%), liệu Single-AZ với read replica có đủ, rẻ hơn
   đáng kể, và tôi có thể tự thêm Multi-AZ sau nếu cần không?

3. Giả sử ngân sách baseline phải giảm còn 2,500 USD/tháng thay vì 4,000 —
   kiến trúc nào là thứ đầu tiên bạn sẽ cắt hoặc thay bằng phương án rẻ hơn,
   và đánh đổi cụ thể là gì?

Việc ép AI trả lời câu hỏi số 3 — cắt giảm theo ngân sách thấp hơn — thường lộ ra rằng một phần kiến trúc ban đầu là "nice-to-have" chứ không phải bắt buộc, đúng bản chất của bước phản biện.

Cạm bẫy thường gặp

1. Chấp nhận kiến trúc AI đề xuất mà không tự kiểm chứng chi phí thực tế. AI ước tính chi phí dựa trên hiểu biết chung về giá dịch vụ, không phải giá thực tế tại thời điểm bạn triển khai (giá AWS thay đổi theo thời gian, theo region, theo commitment discount bạn có sẵn). Luôn đối chiếu con số AI đưa ra với AWS Pricing Calculator hoặc Cost Explorer thực tế của tài khoản bạn trước khi đưa vào tài liệu trình bày cho stakeholder — một con số sai trong slide trình bày ngân sách là lỗi khó chữa hơn nhiều so với một dòng code sai.

2. Chấp nhận kiến trúc "đẹp trên giấy" nhưng over-engineered so với quy mô thực tế. AI có xu hướng đề xuất đầy đủ best practice — Multi-AZ mọi nơi, Transit Gateway ngay từ đầu, multi-region failover — vì đó là câu trả lời an toàn về mặt thống kê, không phải câu trả lời tối ưu cho một hệ thống mới với 3 kỹ sư vận hành và traffic vài trăm request/giây. Bảng ví dụ ở trên minh hoạ đúng cạm bẫy này: Transit Gateway hợp lý nếu có kế hoạch mở rộng thật, nhưng là chi phí và độ phức tạp thừa nếu chỉ có 2 VPC và không có kế hoạch thêm VPC nào trong ngắn hạn. Luôn hỏi ngược "cái này có cần ngay bây giờ không, hay có thể thêm sau khi thực sự cần" cho từng thành phần managed service đắt tiền.

3. Dùng nguyên bản đề xuất đầu tiên làm tài liệu thiết kế chính thức, bỏ qua bước phản biện. Đây là cạm bẫy về quy trình, không phải kỹ thuật: khi deadline gấp, dễ copy-paste output AI vào slide và gọi đó là "kiến trúc đã thiết kế". Bảng Thành phần/Vai trò/Lý do chọn chỉ có giá trị nếu cột "Lý do chọn" phản ánh việc bạn đã thực sự cân nhắc phương án thay thế (đã hỏi AI so sánh, đã tự đọc docs xác nhận), không phải copy nguyên văn giải thích của AI mà chưa kiểm chứng logic có đúng với ràng buộc thật của hệ thống bạn hay không.

🧭 Góc nhìn Solutions Architect
Nếu bỏ hoàn toàn bước phản biện (Bước 3), điều gì phân biệt bạn với một người chỉ copy kiến trúc mẫu từ một blog AWS bất kỳ? Với mỗi thành phần trong bảng kiến trúc AI đề xuất, bạn có thể tự giải thích lý do chọn nó bằng ngôn ngữ của riêng mình cho một đồng nghiệp khác không nghe qua AI hay không — nếu không, đó là dấu hiệu bạn chưa thực sự hiểu kiến trúc, chỉ đang chuyển tiếp lời AI nói.

🔗 Bài viết liên quan

Advanced Prompting: Chain-of-Thought & ReAct — kỹ thuật ép AI giải thích lý do (reasoning) thay vì chỉ đưa kết luận, nền tảng cho bước phản biện kiến trúc ở bài này.
Cost Optimization with AI — đào sâu hơn cách kiểm chứng và tối ưu chi phí cho kiến trúc đã phác thảo, tiếp nối trực tiếp cạm bẫy số 1 ở bài này.

Bài trước: Custom AI Tools: Build CLI nhỏ bằng Python gọi LLM API · Bài tiếp theo: Microservices & AI: Domain, Service, Interface