Mục tiêu bài học
Luyện chọn dịch vụ theo capability và chọn pricing model theo workload.
Bài giảng chi tiết
Bài toán thực tế
Một workload có thể chạy bằng nhiều dịch vụ, nhưng chỉ một lựa chọn đáp ứng đúng storage model, access pattern, availability và cost constraint. Bài ôn tập kiểm tra khả năng loại đáp án gần đúng.
Đừ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
- Object/block/file và relational/NoSQL là các phân loại trước khi chọn service.
- HA, read scaling, backup/DR và cost commitment giải quyết các mục tiêu khác nhau.
- EC2/Lambda/container, S3/EBS/EFS, RDS/DynamoDB và VPC/CloudFront/Route 53 cần được nối theo capability.
- “Lowest cost” không được bỏ qua reliability, security hoặc operational requirement.
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
Compute: EC2 cho VM control, Lambda cho function/event, container service cho orchestration. Storage: S3 object, EBS block, EFS file, Snow offline transfer. Database: RDS/Aurora relational, DynamoDB key-value/document. Network: VPC, Route 53, CloudFront. Cost: On-Demand linh hoạt, commitment cho usage ổn định, Spot cho interruptible.
Ví dụ giảng viên: phân loại một quyết định cloud
Trước service name, hãy trả lời capability: object/block/file, relational/key-value, synchronous/event, stable/interruptible, single-AZ/Multi-AZ. Sau đó mới chọn service và ghi một near miss. Nếu near miss không thể bị loại bằng requirement cụ thể, decision chưa đủ rõ.
Thực hành có kiểm soát
Chọn service cho 12 nhu cầu; mỗi câu ghi “vì sao không dùng lựa chọn gần nhất”. Đọc object/block/file, relational/NoSQL, HA/read scaling và interruptible trước khi chọn.
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.
- Chọn đúng service cho ít nhất 10/12 scenario.
- Giải thích được vì sao lựa chọn gần nhất bị loại.
- Phân biệt HA với scaling và commitment.
- Tạo được một gap list theo capability, không chỉ theo tên service.
Bẫy đề thi và cách tự kiểm tra
Không nhầm service name với capability. HA, scaling và cost commitment là ba câu hỏi khác nhau dù đôi khi cùng xuất hiện trong một scenario.