Lộ trình
Amazon Web ServicesCơ bảnTuần 4: Pricing, Billing & Well-ArchitectedBài 22 / 30

Ngày 22: Billing và pricing models

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
aws-clf-c02ngày 22
hoàn thành22 / 30 bài
Bối cảnh bài học

Chọn On-Demand, Reserved, Savings Plans, Spot hoặc Dedicated Host theo độ ổn định và khả năng chịu gián đoạn.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Chọn On-Demand, Reserved, Savings Plans, Spot hoặc Dedicated Host theo độ ổn định và khả năng chịu gián đoạn.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Học On-Demand, Reserved, Spot Instance pricing
  • Thực hành với AWS Pricing Calculator
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Ba workload có độ ổn định và khả năng chịu gián đoạn khác nhau nhưng team muốn dùng một pricing model cho tất cả. Bài học yêu cầu chọn model theo utilization, commitment và interruption tolerance.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • On-Demand linh hoạt; Reserved/Savings Plans phù hợp usage ổn định có commitment.
  • Spot dùng capacity dư, rẻ hơn nhưng có thể interrupt; workload phải retry/fault-tolerant.
  • Dedicated Host phục vụ visibility/licensing/compliance trên physical host, không mặc định là rẻ nhất.
  • Estimate cost cần usage assumptions; “lowest cost” không được đánh đổi requirement quan trọng.

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

Chọn On-Demand, Reserved, Savings Plans, Spot hoặc Dedicated Host theo độ ổn định và khả năng chịu gián đoạn.

Bài giảng chi tiết

Bài toán thực tế

Ba workload có độ ổn định và khả năng chịu gián đoạn khác nhau nhưng team muốn dùng một pricing model cho tất cả. Bài học yêu cầu chọn model theo utilization, commitment và interruption tolerance.

Đừ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. On-Demand linh hoạt; Reserved/Savings Plans phù hợp usage ổn định có commitment.
  2. Spot dùng capacity dư, rẻ hơn nhưng có thể interrupt; workload phải retry/fault-tolerant.
  3. Dedicated Host phục vụ visibility/licensing/compliance trên physical host, không mặc định là rẻ nhất.
  4. Estimate cost cần usage assumptions; “lowest cost” không được đánh đổi requirement quan trọng.

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

On-Demand linh hoạt, không commitment dài hạn. Reserved Instances phù hợp capacity ổn định. Savings Plans giảm giá theo commitment với độ linh hoạt khác nhau. Spot dùng capacity dư, rẻ hơn nhưng có thể bị interrupt. Dedicated Host dành cho visibility/licensing/compliance trên physical host, không đơn giản là mô hình rẻ nhất.

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

Pricing decision là bài toán risk-adjusted cost. Web traffic biến động cần flexibility; batch có thể retry nên chịu interruption; database production ổn định có thể phù hợp commitment sau khi có usage evidence. Dedicated Host giải quyết licensing/visibility/isolation, không phải shortcut để giảm giá.

Ghi assumptions: hours, region, instance family, utilization, data transfer và storage. Nếu một assumption thay đổi, kết luận cost có đổi không? Đây là phần quan trọng hơn việc nhớ tên discount.

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

Phân loại web traffic không đoán trước, batch có thể retry và database production ổn định. Chọn On-Demand, Spot hoặc commitment, ghi trade-off. Dùng Pricing Calculator để estimate nhưng không coi estimate là hóa đơn cuối.

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. Chọn đúng On-Demand/commitment/Spot cho ba workload.
  2. Giải thích vì sao Spot cần retry/interruption handling.
  3. Phân biệt Dedicated Host với Dedicated Instance/On-Demand.
  4. Ghi rõ assumption trước khi kết luận chi phí thấp nhất.

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

Spot cần workload fault-tolerant. Trước commitment hãy đo usage; cam kết không dùng đủ vẫn là lãng phí. “Lowest cost” luôn cần gắn với requirement.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
aws ec2 describe-spot-price-history --profile study --max-items 5 --output table
Hands-on lab

Thực hành theo scenario

Tạo bảng workload → ổn định/biến động → interruptible → pricing model → trade-off. Dùng Pricing Calculator hoặc dữ liệu giả để tính estimate, ghi rõ assumption và không commit mua thật trong lab.

Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Chọn đúng On-Demand/commitment/Spot cho ba workload.
  • Giải thích vì sao Spot cần retry/interruption handling.
  • Phân biệt Dedicated Host với Dedicated Instance/On-Demand.
  • Ghi rõ assumption trước khi kết luận chi phí thấp nhất.
Transfer to exam / production

Bẫy thường gặp và trade-off

Spot cần workload fault-tolerant. Trước commitment hãy đo usage; cam kết không dùng đủ vẫn là lãng phí. “Lowest cost” luôn cần gắn với requirement.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Batch có thể dừng và chạy lại, mục tiêu là giảm chi phí compute. Lựa chọn nào phù hợp?

Kết thúc bài

Checklist trước khi sang Ngày 2