Mục tiêu bài học
Dùng sáu trụ cột như bộ câu hỏi thiết kế, không học chúng như sáu AWS service.
Bài giảng chi tiết
Bài toán thực tế
Một web app đã chạy được nhưng chưa có cách đánh giá toàn diện: quyền quá rộng, chưa test restore, chi phí không đo được và vận hành phụ thuộc thao tác tay. Well-Architected dùng để đặt câu hỏi và ưu tiên cải tiế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
- Operational Excellence tập trung vận hành và cải tiến; Security bảo vệ identity/data; Reliability phục hồi khi lỗi.
- Performance Efficiency chọn tài nguyên phù hợp; Cost Optimization quản lý spend; Sustainability tối ưu hiệu quả tài nguyên.
- Một cải tiến có thể tác động nhiều trụ cột và tạo trade-off.
- Framework không tự chứng minh compliance và không phải danh sách service bắt buộc.
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 trụ cột gồm Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization và Sustainability. Hãy hỏi: vận hành có cải tiến không, quyền có tối thiểu không, hệ thống có phục hồi không, tài nguyên có phù hợp không, chi phí có đo được không và tài nguyên có dùng hiệu quả không.
Ví dụ giảng viên: phân loại một quyết định cloud
Dùng Well-Architected như câu hỏi review: workload đang chạy ra sao, failure mode nào chưa test, ai có quyền, signal nào đo được, chi phí nào không biết và tài nguyên nào lãng phí. Một cải tiến không được gọi là tốt nếu không có evidence hoặc tạo trade-off chưa được ghi.
Ví dụ Multi-AZ tăng reliability nhưng tăng cost; encryption tăng security nhưng cần key lifecycle/permission; caching tăng performance nhưng tạo freshness/invalidation problem. Review tốt luôn ghi risk, control, metric và owner.
Thực hành có kiểm soát
Với web app 3-tier, viết một risk và một cải tiến cho mỗi trụ cột. Ví dụ Reliability: Multi-AZ và restore test; Cost: right-size và budget; Security: role và encryption. Ghi trade-off nếu một cải tiến ảnh hưởng nhiều trụ cột.
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.
- Nêu đúng mục tiêu của cả sáu trụ cột.
- Mỗi trụ cột có một risk và một cải tiến cụ thể.
- Phân biệt Reliability với backup, Security với compliance và Cost với “rẻ nhất”.
- Ghi được trade-off giữa availability, performance và cost.
Bẫy đề thi và cách tự kiểm tra
Least privilege thường là Security; automate operations là Operational Excellence; design for failure là Reliability. Framework giúp đặt câu hỏi, không tự chứng minh compliance.