Savings Plans vs Reserved Instances 2026: Cách Chọn Đúng Để Tiết Kiệm 40–72% Chi Phí AWS

Cập nhật: 18 tháng 7, 2026

Savings Plans vs Reserved Instances là hai công cụ cam kết chi phí lớn nhất trên AWS, và câu trả lời ngắn: Compute Savings Plans linh hoạt hơn và phủ cả EC2, Fargate, Lambda ở mức chiết khấu tới 66%, còn Standard Reserved Instances mở khóa mức chiết khấu tối đa 72% nhưng khóa vào một họ instance cụ thể. Tôi đã áp dụng cả hai trên các danh mục AWS trị giá bảy con số, và bài viết này là công thức tôi dùng để trộn chúng: mua sàn cam kết ổn định bằng Savings Plans, gắn Standard RI cho phần workload dự đoán được, và giữ 20–30% ondemand cho biến động.

• Compute Savings Plans tiết kiệm tới 66% và tự động áp dụng cho EC2 mọi họ/vùng, cộng với Fargate và Lambda, không cần đổi khi refactor.
• EC2 Instance Savings Plans và Standard Reserved Instances đều đạt mức chiết khấu 72% nhưng khóa cứng vào một họ instance trong một vùng cụ thể.
• Convertible RI cho phép đổi sang RI khác trong kỳ hạn, đánh đổi bằng mức chiết khấu thấp hơn (~54–66%) và không bán lại được trên RI Marketplace.
• Break-even của 3 năm All Upfront thường rơi vào tháng 15–18; nếu bạn không chắc workload còn tồn tại đến đó, hãy chọn 1 năm hoặc No Upfront.
• Chiến lược đúng: mua sàn 60–70% coverage bằng Compute SP, phần dự đoán được bằng EC2 Instance SP hoặc Standard RI, để 20–30% ondemand hấp thụ biến động.
• Không thể chuyển RI thành Savings Plans; hãy để RI hết hạn rồi mua SP thay thế, đừng mua chồng.

Savings Plans và Reserved Instances khác nhau như thế nào?

Reserved Instances ra đời năm 2009, còn Savings Plans mới xuất hiện năm 2019. Cái sinh sau đơn giản hơn, và thẳng thắn mà nói, AWS đang rõ ràng đẩy khách hàng sang Savings Plans. Cơ chế thanh toán khác nhau ở gốc rễ: RI cam kết bạn sẽ chạy một loại instance cụ thể trong 1 hoặc 3 năm; Savings Plans cam kết bạn sẽ chi ít nhất X USD mỗi giờ cho compute trong 1 hoặc 3 năm. Số tiền cam kết đó có thể áp vào bất kỳ workload EC2, Fargate hoặc Lambda nào bạn chạy. Đây chính là lý do Savings Plans thắng về sự linh hoạt.

Trong thực tế, tôi thấy điều này quan trọng nhất khi kiến trúc thay đổi. Năm ngoái tôi có một khách hàng đã mua 200 Standard RI cho m5.2xlarge, và sáu tháng sau team platform chuyển sang Graviton m7g. RI vẫn tính phí đầy đủ nhưng không còn được sử dụng, tổn thất khoảng 180.000 USD. Nếu họ dùng Compute Savings Plans, cam kết đó sẽ tự động chuyển sang m7g mà không cần thao tác gì. Bài học đau, nhưng đúng là bài học tôi hay kể trong các buổi audit.

Đặc điểm	Compute SP	EC2 Instance SP	Standard RI	Convertible RI
Chiết khấu tối đa	~66%	~72%	~72%	~66%
Kỳ hạn	1 hoặc 3 năm	1 hoặc 3 năm	1 hoặc 3 năm	1 hoặc 3 năm
Đổi họ instance	Tự động	Không	Không	Có (thủ công)
Áp cho Fargate/Lambda	Có	Không	Không	Không
Capacity Reservation	Không	Không	Chỉ Zonal RI	Chỉ Zonal RI
Bán trên RI Marketplace	Không	Không	Có	Không
Chuyển vùng	Được (Regional)	Không	Regional/Zonal	Regional/Zonal

Điểm mấu chốt: nếu bạn không cần Capacity Reservation và không cần bán lại cam kết, Savings Plans gần như luôn thắng RI về mặt vận hành. RI chỉ còn giá trị khi bạn cần khóa cứng năng lực trong một AZ cụ thể (Zonal RI), hoặc khi bạn muốn giữ khả năng thoát cam kết qua Marketplace.

Compute Savings Plans vs EC2 Instance Savings Plans

Hai biến thể Savings Plans trông giống nhau ở tên, nhưng khác nhau về mức chiết khấu và độ cứng. Compute Savings Plans là loại tôi khuyên dùng đầu tiên: cam kết chi tiêu USD/giờ áp vào EC2 bất kỳ họ nào, bất kỳ vùng nào, bất kỳ OS nào, cộng với Fargate và Lambda. Chiết khấu tối đa khoảng 66% cho 3 năm All Upfront. Rủi ro thấp, vì khi workload thay đổi (di chuyển vùng, đổi họ, chuyển sang Fargate), cam kết vẫn được sử dụng.

EC2 Instance Savings Plans cho mức chiết khấu cao hơn (tới 72% cho 3 năm All Upfront) nhưng khóa vào một họ instance cụ thể trong một vùng cụ thể. Ví dụ, nếu bạn mua EC2 Instance SP cho họ m6i tại us-east-1, cam kết đó không áp vào m6a hay r6i, cũng không áp vào m6i tại eu-west-1. Có size flexibility trong họ (một m6i.4xlarge có thể được cam kết áp qua bốn m6i.xlarge), nhưng đó là tất cả.

Trong danh mục thực tế, tôi thường mua EC2 Instance SP cho phần workload đã ổn định hơn 12 tháng (ví dụ một cụm cơ sở dữ liệu chính đã chạy m6i suốt hai năm và không có kế hoạch di dời). Với phần compute biến động, như API scale theo giờ, worker queue, hay môi trường staging, tôi luôn dùng Compute SP. Chênh lệch 6% chiết khấu giữa hai loại không đủ bù rủi ro cam kết sai họ.

Standard Reserved Instance vs Convertible Reserved Instance

Reserved Instances chia hai loại. Standard RI mở khóa mức chiết khấu cao nhất trên AWS (~72% cho 3 năm All Upfront) nhưng đóng băng thuộc tính instance như họ, vùng, OS, tenancy. Bạn có size flexibility trong họ Linux/Unix (một Standard RI m6i.2xlarge có thể tự chia thành hai m6i.xlarge), nhưng không đổi được sang họ khác. Điểm cứu Standard RI là RI Marketplace: bạn có thể bán RI Standard bạn không còn cần cho khách hàng AWS khác, thu hồi một phần chi phí upfront.

Convertible RI đánh đổi mức chiết khấu (chỉ ~54–66% cho 3 năm) lấy quyền đổi thuộc tính. Bạn có thể exchange một Convertible RI m6i.2xlarge Linux sang c6i.4xlarge Linux nếu giá trị đô-la của RI mới bằng hoặc cao hơn. Điều kiện: exchange chứ không phải sell, bạn không lấy lại tiền, chỉ đổi sang RI khác. Convertible RI cũng không bán được trên Marketplace. Chi tiết cơ chế exchange được ghi trong tài liệu Reserved Instances của AWS EC2.

Câu hỏi tôi hay bị hỏi: nếu Convertible RI có thể đổi, tại sao không luôn chọn Convertible thay vì Standard? Câu trả lời là toán. Chênh lệch chiết khấu giữa Standard và Convertible 3 năm All Upfront thường 6–10 điểm phần trăm, tương đương 15.000–30.000 USD trên mỗi 100 instance suốt kỳ hạn. Chỉ chọn Convertible khi bạn có xác suất cao (≥50%) sẽ đổi kiến trúc. Với hầu hết workload đã ổn định, Standard RI cộng với Compute SP linh hoạt bên ngoài là kết hợp hiệu quả hơn.

Break-even: 1 năm vs 3 năm, All Upfront vs No Upfront

Break-even là câu hỏi FinOps quan trọng nhất khi cam kết. Công thức đơn giản: break-even (tháng) = (giá upfront) / (tiết kiệm hằng tháng so với ondemand). Với 3 năm All Upfront Compute SP điển hình (chiết khấu 54% so với ondemand), break-even thường rơi vào tháng 15–18. Nghĩa là nếu bạn thanh lý workload trước tháng 18, bạn lỗ so với ondemand. Nếu chạy đủ 36 tháng, bạn đã cắt ~54% chi phí compute cho phần đó.

1 năm All Upfront có break-even ngắn hơn, thường tháng 6–8, nhưng chiết khấu thấp hơn nhiều (30–40% thay vì 54–66%). Tôi khuyên thế này: 1 năm cho workload mới, chưa chắc kiến trúc; 3 năm cho hệ thống cốt lõi đã tồn tại nhiều năm và không có lý do rõ ràng để dời.

All Upfront vs Partial vs No Upfront: All Upfront cho chiết khấu cao nhất, nhưng chỉ cao hơn No Upfront khoảng 2–3 điểm phần trăm. Nếu chi phí vốn quan trọng (startup, giai đoạn cân bằng dòng tiền), hãy chọn No Upfront. Bạn mất ít chiết khấu và giữ lại tiền mặt. Với công ty lớn có bảng cân đối lành mạnh, All Upfront là lựa chọn tài chính rõ ràng.

# Vi du tinh break-even bang Python
ondemand_hourly = 0.384       # m6i.2xlarge us-east-1 Linux
sp_3yr_all_upfront_hourly = 0.177  # ~54% off
upfront_cost = sp_3yr_all_upfront_hourly * 24 * 365 * 3
monthly_savings = (ondemand_hourly - sp_3yr_all_upfront_hourly) * 24 * 30
break_even_months = upfront_cost / monthly_savings
print(f"Upfront: ${upfront_cost:,.0f}")
print(f"Tiet kiem/thang vs ondemand: ${monthly_savings:,.0f}")
print(f"Break-even: {break_even_months:.1f} thang")
# Upfront: $4,650
# Tiet kiem/thang vs ondemand: $149
# Break-even: 31.2 thang vs 36 thang total -> bien an toan ~5 thang

Coverage và Utilization: hai chỉ số FinOps phải theo dõi

Sau khi mua Savings Plans hoặc Reserved Instances, bạn phải theo dõi hai chỉ số riêng biệt, và đừng nhầm lẫn chúng. Coverage đo phần chi tiêu ondemand tiềm năng đã được cam kết phủ. Ví dụ, 65% coverage nghĩa là 65% giờ EC2 đủ điều kiện đã có cam kết áp vào, còn 35% còn lại đang trả giá ondemand. Utilization đo phần cam kết đã mua thực sự được dùng. 95% utilization nghĩa là 5% cam kết bạn trả nhưng không có workload tiêu thụ, tức tiền vứt đi.

Mục tiêu FinOps của tôi trên mọi danh mục là Coverage 75–85%, Utilization 95%+. Coverage cao hơn 85% là cam kết quá mức, và bạn sẽ thấy utilization giảm ngay khi workload có biến động bình thường. Coverage dưới 60% nghĩa là bạn đang bỏ tiền lên bàn.

Trong Cost Explorer, hai báo cáo cần bookmark là Savings Plans Coverage và Savings Plans Utilization (tương tự cho RI). Kéo về khung 30 ngày và nhóm theo linked account để xem team nào đang under-covered. Với chi tiết hơn, tham khảo Savings Plans reports của AWS Billing, tài liệu chính thức về cách đọc coverage và utilization qua Cost Explorer API.

Savings Plans có bao gồm Fargate và Lambda không?

Có, nhưng chỉ Compute Savings Plans. Đây là một trong những lý do lớn nhất để chọn Compute SP thay vì RI hay EC2 Instance SP. Cam kết USD/giờ của Compute SP tự động áp vào giờ chạy Fargate (ECS và EKS) và giờ tính toán Lambda ở mức chiết khấu tương ứng, khoảng 20% cho Lambda và 50% cho Fargate ở kỳ hạn 3 năm All Upfront.

Điều này quan trọng khi bạn đang chuyển đổi kiến trúc từ EC2 sang containers hoặc serverless. Nếu tôi biết một team đang di dời từ EC2 workers sang Fargate trong 12 tháng tới, tôi không cam kết bằng EC2 Instance SP hay Standard RI (cam kết đó sẽ trở thành gánh nặng khi EC2 giảm xuống). Compute SP cho phép chuyển đổi mượt mà: cùng một khoản cam kết USD/giờ, chỉ đổi loại tài nguyên tiêu thụ.

Về Lambda, cần lưu ý sắc thái. Compute SP chỉ áp vào Lambda duration (thời gian hàm chạy), không áp vào request charges hay chi phí Provisioned Concurrency ở giai đoạn khởi tạo. Với workload Lambda chi phí lớn, tôi khuyến nghị đọc thêm bài tối ưu chi phí serverless 2026 cho AWS Lambda để hiểu Compute SP kết hợp với Power Tuning và ARM ra sao.

Chiến lược commit stack: nên mua bao nhiêu và loại nào

Đây là khuôn mà tôi triển khai trên hầu hết danh mục AWS trên 500.000 USD/tháng. Tôi gọi nó là "commit stack", và nó xếp 4 lớp từ cứng nhất đến linh hoạt nhất:

1. Lớp 1, Sàn ondemand baseline (20–25%): phần chi tiêu không bao giờ cam kết. Đây là bộ đệm cho scale spike, dev/test bùng phát, và các workload có thể ngừng bất kỳ lúc nào.
2. Lớp 2, Compute Savings Plans 3 năm (35–45%): sàn cam kết chính. Chọn khoảng 60% giá trị trung vị 90 ngày làm mức USD/giờ. Đây là lớp lớn nhất vì linh hoạt nhất.
3. Lớp 3, EC2 Instance SP hoặc Standard RI 3 năm (20–30%): cho các workload cực kỳ ổn định, ví dụ cơ sở dữ liệu chính đã chạy m6i hoặc r6i suốt 2+ năm và không có kế hoạch dời.
4. Lớp 4, Zonal RI Capacity Reservation (5–10%): chỉ khi bạn cần khóa cứng năng lực trong một AZ (ví dụ cụm HPC hoặc dịch vụ có SLA nghiêm ngặt về capacity).

Đừng bao giờ mua tất cả cam kết cùng lúc. Tôi rải mua theo tháng: mỗi tháng mua thêm một "lớp mỏng" cam kết mới bằng khoảng 3–5% chi tiêu compute. Cách này gọi là rolling commitment ladder, và nó có hai lợi ích lớn: (1) tận dụng thay đổi giá của AWS khi giới thiệu họ instance mới, và (2) khi mỗi lớp cam kết cũ hết hạn, bạn không có "cliff" phải quyết định 500.000 USD trong một tuần.

Phân tích với Cost Explorer và Compute Optimizer (kèm CLI)

Trước khi mua cam kết, luôn chạy phân tích. AWS Cost Explorer có Savings Plans Recommendations Engine, phân tích 7/30/60 ngày ondemand của bạn và đề xuất mức cam kết USD/giờ. Nhưng công cụ này có thiên vị. Mặc định nó đề xuất 3 năm All Upfront ở coverage cao. Hãy điều chỉnh mục tiêu của bạn xuống thay vì mù quáng mua đề xuất.

Dùng AWS CLI để lấy đề xuất Savings Plans một cách có thể lập trình:

# Lay de xuat Compute Savings Plans 3 nam No Upfront
# dua tren chi tieu 60 ngay qua
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years THREE_YEARS \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --account-scope PAYER \
  --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[0].{HourlyCommit:HourlyCommitmentToPurchase, EstimatedSavings:EstimatedSavingsPercentage, EstimatedMonthlySavings:EstimatedMonthlySavingsAmount, UpfrontCost:UpfrontCost}' \
  --output table

Kết quả cho biết cam kết USD/giờ được đề xuất, tỉ lệ tiết kiệm ước tính, và chi phí upfront. Chạy lệnh này cho cả THREE_YEARS và ONE_YEAR, cả ALL_UPFRONT và NO_UPFRONT, so sánh 4 kịch bản. Với các dashboard chi tiết hơn, bài tự động phát hiện tài nguyên cloud lãng phí đưa ra code Python đọc dữ liệu Cost Explorer nhiều lớp.

Về right-sizing trước cam kết (quan trọng, vì cam kết dựa trên right-size sai sẽ tạo utilization thấp), hãy dùng AWS Compute Optimizer. Compute Optimizer đề xuất thu nhỏ hoặc đổi họ EC2 dựa trên telemetry 14–90 ngày. Chạy quyết định right-size trước; đợi 30 ngày để dữ liệu ổn định; rồi mới mua Savings Plans dựa trên baseline mới.

Các sai lầm phổ biến khi mua RI và Savings Plans

Sau nhiều năm audit các danh mục AWS, đây là 6 sai lầm tôi thấy đi thấy lại. Mỗi cái đều đắt tiền, và mỗi cái đều có thể tránh được.

• Mua RI ngay trước khi refactor kiến trúc. Team platform lên kế hoạch chuyển sang Graviton hoặc Fargate trong 12 tháng, nhưng team FinOps mua Standard RI m6i 3 năm vì "chúng ta đang chi ondemand quá nhiều". Kết quả: hai năm còn lại của RI trở thành lãng phí tuyệt đối.
• Cam kết dựa trên tháng đỉnh, không phải median. Đen Friday, đợt tuyển sinh mùa xuân, mùa thuế. Nếu bạn cam kết dựa trên đỉnh, utilization sẽ tụt xuống 60% trong các tháng thường.
• Chọn Convertible RI "để phòng hờ". Trong 5 năm tôi làm FinOps, tôi thấy chưa tới 30% Convertible RI thực sự được exchange. Chênh lệch chiết khấu 10 điểm gần như luôn là tiền vứt đi.
• Không phân biệt Coverage và Utilization. Manager hỏi "utilization của chúng ta thế nào?" và ai đó trả lời con số coverage. Hai chỉ số này đo hai thứ hoàn toàn khác nhau.
• Mua toàn bộ cam kết trong một lần. Không có rolling ladder nghĩa là 3 năm sau bạn có một "cliff" cam kết phải renew cùng lúc, giữa lúc kiến trúc đã thay đổi.
• Bỏ qua kubernetes workload. Nếu bạn chạy EKS, Karpenter và Cluster Autoscaler có thể dịch chuyển workload liên tục giữa các họ instance. Chỉ Compute SP theo kịp được sự dịch chuyển đó. Xem thêm tối ưu chi phí Kubernetes trên EKS, AKS, GKE để hiểu vì sao commit stack cho EKS phải nghiêng nhiều về Compute SP.

Câu hỏi thường gặp

Savings Plans có tốt hơn Reserved Instances không?

Với hầu hết danh mục AWS hiện đại, có. Compute Savings Plans mang lại 90% giá trị chiết khấu của Standard RI cộng với sự linh hoạt về họ instance, vùng, Fargate và Lambda. RI chỉ vượt trội trong hai trường hợp cụ thể: khi bạn cần Capacity Reservation (chỉ Zonal RI hỗ trợ), hoặc khi bạn muốn giữ khả năng bán lại cam kết qua RI Marketplace.

Tôi có thể chuyển Reserved Instance thành Savings Plan không?

Không. Không có đường dẫn chuyển đổi chính thức từ RI sang Savings Plans. Bạn phải để RI chạy hết kỳ hạn (hoặc bán Standard RI qua RI Marketplace), rồi mua Savings Plans mới. Đừng mua chồng, vì cam kết mới sẽ áp vào giờ ondemand còn lại, không thay thế RI đang chạy.

Nên chọn 1 năm hay 3 năm Savings Plans?

Chọn 3 năm cho baseline workload đã ổn định trên 12 tháng và không có kế hoạch di dời kiến trúc. Chọn 1 năm cho workload mới, cho phần compute biến động, hoặc khi công ty bạn đang trong giai đoạn thay đổi cloud strategy. Chênh lệch chiết khấu giữa 1 năm và 3 năm All Upfront thường khoảng 15–20 điểm phần trăm, đáng giá nếu bạn chắc chắn workload sẽ tồn tại đủ 36 tháng.

Savings Plans có áp dụng cho Fargate và Lambda không?

Có, nhưng chỉ Compute Savings Plans (không phải EC2 Instance Savings Plans). Cam kết USD/giờ tự động áp vào giờ chạy Fargate ở ECS/EKS và Lambda duration ở mức chiết khấu tương ứng, khoảng 50% cho Fargate và 20% cho Lambda ở kỳ hạn 3 năm All Upfront. Lambda request charges và Provisioned Concurrency khởi tạo không được phủ.

Coverage và Utilization của Savings Plans nên là bao nhiêu?

Mục tiêu FinOps là Coverage 75–85% và Utilization 95%+. Coverage đo phần chi tiêu ondemand tiềm năng được cam kết phủ; Utilization đo phần cam kết đã mua thực sự được dùng. Coverage trên 85% là cam kết quá mức và utilization sẽ giảm; Coverage dưới 60% là bỏ tiền lên bàn.