Mục tiêu bài học
Chọn mức hỗ trợ theo nhu cầu self-service, technical response, proactive guidance và account management.
Bài giảng chi tiết
Bài toán thực tế
Một developer cá nhân, production team và tổ chức regulated có nhu cầu hỗ trợ khác nhau. Chọn plan chỉ theo tên hoặc giá sẽ không trả lời được severity, response, proactive guidance và account strategy.
Đừ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
- Basic thiên về self-service; các plan trả phí bổ sung technical support/response.
- Business thường hướng tới production cần support 24/7 theo severity; Enterprise có guidance/account capability sâu hơn tùy plan hiện hành.
- Support plan không thay architecture review, IAM, observability hoặc incident ownership.
- Tên, giá và response có thể thay đổi; phải kiểm tra nguồn AWS hiện hành.
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
Basic thiên về self-service, service health và tài nguyên hỗ trợ cơ bản. Các plan trả phí tăng technical support và response. Business phù hợp production cần hỗ trợ 24/7 ở nhiều severity; Enterprise có năng lực guidance/account strategy sâu hơn tùy plan hiện hành. Tên, giá và chi tiết response phải kiểm tra nguồn AWS hiện tại.
Ví dụ giảng viên: phân loại một quyết định cloud
Support plan là quyết định về severity, response và guidance, không phải bảo hiểm thay cho vận hành. Developer học tập có thể cần self-service; production cần technical response; enterprise có thể cần proactive/account guidance. Trước khi mua, tách fact hiện hành khỏi reasoning bền vững và kiểm tra nguồn chính thức.
Failure drill: team chọn plan cao nhất nhưng không có runbook, hoặc kỳ vọng support sửa IAM/application thay mình. Ghi boundary giữa AWS support, customer owner và incident commander.
Thực hành có kiểm soát
Viết requirement của developer cá nhân, production team và enterprise regulated. Chọn plan, ghi lý do, rồi đánh dấu thông tin cần xác nhận trước khi mua: giá, response, TAM/guidance và điều kiện account.
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 plan theo requirement thay vì “plan cao nhất”.
- Nêu được thông tin cần xác nhận trước mua.
- Phân biệt support với remediation/architecture responsibility.
- Đánh dấu các fact có thể thay đổi theo thời điểm.
Bẫy đề thi và cách tự kiểm tra
Support plan không thay incident response, kiến trúc tốt hay IAM. Đừng chọn plan chỉ vì thấy “enterprise”; hãy bám requirement.