Ngày 2: 6 lợi ích của Cloud theo cách AWS hỏi trong đề thi

Mục tiêu bài học

Nối một nhu cầu kinh doanh với đúng lợi ích cloud thay vì học thuộc sáu câu rời rạc.

Bài giảng chi tiết

Bài toán thực tế

Một đội vận hành phải mua dư máy chủ cho đợt flash sale, nhưng sau đó phần lớn công suất bị bỏ trống. Nếu mua thiếu, hệ thống sập; nếu mua thừa, chi phí bị khóa trong phần cứng. Bài toán là nhận diện đúng lợi ích cloud đang giải quyết, không trả lời chung chung rằng “cloud rẻ hơn”.

Đừng học nội dung này như một danh sách tên dịch vụ. Hãy đi theo chuỗi: requirement → khái niệm → quyết định → bằng chứng. Một câu trả lời tốt phải nói được vì sao lựa chọn phù hợp, phương án gần nhất bị loại ở đâu, và kiểm tra nào chứng minh lựa chọn đó hoạt động.

Khái niệm được giải thích theo scenario

1. Trade CapEx for OpEx: chuyển khoản đầu tư phần cứng trả trước thành chi phí biến đổi theo mức sử dụng.
2. Economies of scale: provider gom nhu cầu lớn để giảm chi phí trên mỗi đơn vị; không đồng nghĩa mọi workload luôn rẻ hơn.
3. Stop guessing capacity: cấp phát và điều chỉnh công suất theo nhu cầu thay vì dự đoán cực đại từ đầu.
4. Increase speed and agility: tạo môi trường và thử nghiệm nhanh hơn, rút ngắn time-to-market.
5. Stop spending money running data centers và Go global in minutes: giảm gánh nặng vận hành vật lý và mở rộng phạm vi triển khai nhanh.

Ví dụ khi gặp một scenario mới, hãy thay các từ khóa trong đề bằng một hệ thống cụ thể: ai là người dùng, dữ liệu đi qua đâu, thành phần nào có thể lỗi, quyền nào cần có và điều gì phải được quan sát. Cách làm này giúp phân biệt các đáp án gần đúng thay vì chọn theo trí nhớ tên service.

flowchart LR
  A[Scenario / requirement] --> B[Concept and boundary]
  B --> C[Service or control choice]
  C --> D[Evidence and trade-off]
  D --> E[Failure variant]

Khái niệm cốt lõi

Sáu lợi ích là trade CapEx for OpEx, economies of scale, stop guessing capacity, increase speed and agility, stop spending money running data centers và go global in minutes. “Giảm chi phí” chưa đủ cụ thể: phải đọc xem đề nói về chi phí trả trước, quy mô, công suất, tốc độ hay phạm vi toàn cầu.

Ví dụ giảng viên: phân loại một quyết định cloud

Một công ty bán vé có 3 loại nhu cầu trong cùng một tháng:

Hãy tách hai câu hỏi thường bị trộn. Economies of scale giải thích vì sao provider lớn có thể có chi phí đơn vị thấp hơn nhờ quy mô mua sắm và vận hành. Elasticity giải thích vì sao một workload có thể tăng rồi giảm tài nguyên theo traffic. Một hệ thống có thể hưởng lợi từ cả hai, nhưng hai khái niệm không thay thế nhau.

Khi đề nói “không muốn trả tiền cho capacity nhàn rỗi”, đừng nhảy ngay tới “cloud luôn rẻ”. Hãy viết đủ chuỗi nguyên nhân: nhu cầu biến động → capacity cần co giãn → không phải mua cực đại từ đầu → giảm vốn bị khóa → vẫn cần giới hạn, monitoring và review hóa đơn.

Thực hành có kiểm soát

Viết sáu scenario ngắn, mỗi scenario chỉ chứa một tín hiệu, rồi tự gắn nhãn. Sau đó giải thích vì sao “stop guessing capacity” là lợi ích kinh doanh còn elasticity là đặc tính kỹ thuật hỗ trợ lợi ích đó.

Expected state và recovery

Trước khi thực hành, ghi rõ target/account/region, trạng thái hiện tại và output mong đợi. Sau thao tác, kiểm chứng bằng trạng thái thực tế hoặc command phù hợp; nếu kết quả sai, giữ lại evidence, quay về thay đổi nhỏ nhất và cleanup đúng owner. Không coi exit code 0 hoặc thông báo “success” là bằng chứng duy nhất.

1. Phân loại đúng cả 6 scenario mà không dùng nhãn “giảm chi phí” cho mọi trường hợp.
2. Giải thích được sự khác nhau giữa economies of scale và elasticity bằng một ví dụ riêng.
3. Với scenario triển khai toàn cầu, nêu được latency/data residency là yếu tố cần kiểm tra thêm, không chỉ nói “go global”.
4. Tự tạo một scenario gây nhầm giữa CapEx/OpEx và giải thích vì sao một đáp án là sai.
5. Kiểm tra lại các con số giá hoặc số lần giảm giá bằng nguồn AWS hiện hành trước khi dùng trong tài liệu.

Bẫy đề thi và cách tự kiểm tra

Cloud không đảm bảo mọi workload luôn rẻ hơn on-premises. “Lowest total cost” còn phụ thuộc kiến trúc, usage và kỷ luật quản lý chi phí.