Bạn đang bối rối về các mô hình định giá AWS? Đừng bỏ qua bài viết này!

Amazon Web Services (AWS) là nền tảng đám mây hàng đầu thế giới, với hơn 1 triệu người dùng trên 190 quốc gia. Cung cấp nhiều loại dịch vụ đám mây, phục vụ cho hầu hết mọi khối lượng công việc có thể có, bao gồm bảo mật mạng, máy chủ ảo, cơ sở dữ liệu, xử lý dữ liệu lớn, lưu trữ đối tượng, AI/ML, v.v. AWS cung cấp tất cả các tài nguyên CNTT theo mô hình giá On-demand,  thanh toán linh hoạt theo nhu cầu sử dụng.

Kể từ năm 2021, AWS cung cấp trung tâm dữ liệu ảo trải dài trên 25 khu vực (sắp tới sẽ có thêm nhiều địa điểm) đang chạy hơn 200 sản phẩm và dịch vụ.

Hầu hết các công ty nhận thấy điện toán đám mây AWS hấp dẫn vì ba lý do chính: quy mô và dung lượng không giới hạn, khả năng chi trả linh hoạt, và dễ sử dụng. Khách hàng chỉ cần chi trả cho thời gian và công suất mà họ đang sử dụng. Điều này tạo ra sự khác biệt lớn cho vốn và chi phí CNTT cần có để hoạt động của một công ty. Capex được loại bỏ do tất cả các tài nguyên được cung cấp bởi AWS. Mặt khác, Opex được thu nhỏ vì chỉ dựa trên nhu cầu sử dụng. Loại bỏ thời gian chờ đợi để đạt được điểm hòa vốn hoặc thu lại chi phí ban đầu.

Tuy nhiên, khi nói đến việc quản lý các cơ sở hạ tầng CNTT lớn, đa dạng trên AWS. Ngay cả nhóm vận hành có năng lực nhất cũng sẽ gặp khó khăn nếu không có chiến lược quản lý chi phí. Các ứng dụng ngày nay thường sử dụng nhiều dịch vụ khác nhau. Điều này đương nhiên tạo ra một số phức tạp trong việc thanh toán (và phí thường cao một cách đáng ngạc nhiên).

Trong bài viết này, chúng tôi sẽ giới thiệu các phương pháp tiết kiệm chi phí đám mây khi lập kế hoạch cơ sở hạ tầng.

Những thách thức tài chính của Điện toán đám mây AWS

AWS tuy là nhà cung cấp dịch vụ đám mây chiếm ưu thế nhất. Nhưng nó cũng đi kèm với một số hạn chế, đặc biệt là khi nói đến chi tiêu trên đám mây. Cả các doanh nghiệp lớn và nhỏ đều bối rối trước sự phức tạp của cấu trúc định giá AWS.

Dưới đây là một số thách thức liên quan đến tài chính mà các tổ chức thường đối mặt trên AWS:

Thay đổi cấu trúc định giá

Dịch vụ máy chủ ảo AWS (EC2) có sẵn hơn 40 loại phiên bản. Mỗi nhóm có ít nhất 12 loại phiên bản cụ thể, với số lượng nhiều hơn được thêm vào mỗi tháng. Mỗi loại có một thẻ giá khác nhau và chúng khác nhau giữa các khu vực. Và giá loại phiên bản cũ sẽ giảm mỗi khi loại phiên bản mới xuất hiện.

Thay đổi kiến ​​trúc

Khi kiến ​​trúc ứng dụng thay đổi theo thời gian, các tổ chức thường áp dụng các dịch vụ và tính năng AWS mới, ảnh hưởng đến quy mô cơ sở hạ tầng đám mây của bạn. Một microservice mới được thêm vào có thể liên quan đến việc tạo một nút cho một cụm Kubernetes. Hoặc có thể thực hiện các thay đổi đối với Cổng API AWS. Không thể (hoặc không dễ dàng) dự đoán các thay đổi nếu nhu cầu liên tục thay đổi.

Khó đoán trước

Để làm cho các dịch vụ quan trọng có tính khả dụng cao. Khách hàng AWS thường sử dụng các tính năng mở rộng nguyên bản. Như tự động tăng và giảm các phiên bản nhằm đáp ứng nhu cầu thay đổi. Mặc dù điều này nghe có vẻ thuận tiện. Nhưng khi bạn chạy với On-demand, thì việc vận hành theo cách này về lâu dài sẽ khá tốn kém. Khách hàng của AWS thường gặp khó khăn trong việc dự đoán trong việc môi trường sẽ đáp ứng như thế nào khi tăng hoặc giảm quy mô để đáp ứng nhu cầu lưu lượng truy cập.

Có những yếu tố khác góp phần làm khó khăn thêm. Khi các công ty di chuyển ngày càng nhiều khối lượng công việc lên đám mây. Mà không có sự giám sát về kế hoạch và ngân sách phù hợp. Một số trường hợp như:

  • Nhập người dùng mới với một lượng lớn dữ liệu do người dùng tạo.
  • Triển khai tính năng mới cần nhiều sức mạnh xử lý và máy chủ hơn.
  • Tái cấu trúc ứng dụng, dẫn đến việc sử dụng các dịch vụ bổ sung.
  • Nhu cầu về tính khả dụng cao, yêu cầu chuyển đổi sang các dịch vụ được quản lý, bản sao đọc hoặc nhiều AZ.

Các nhóm vận hành và tài chính cố gắng giảm chi phí đám mây bằng cách mua trước Reserved Instances (RIs), Spot Instances hoặc Savings Plans (SP). Mặc dù các tùy chọn này cung cấp chiết khấu về giá. Nhưng những chiết khấu đó lại không phù hợp với nhu cầu thực tế. Do đó, liên tục bán, mua và áp dụng các kế hoạch giảm giá trở thành một công việc phức tạp. Và thường các quản trị viên AWS sẽ nhận thua cuộc, khi họ nhận ra điều cần thiết hơn là một giải pháp tự động theo thời gian thực.

Các mô hình định giá AWS khác nhau

Để giúp khách hàng chọn một chiến lược giá tối ưu, AWS cung cấp bốn mô hình định giá cho các tài nguyên của mình. Đặc biệt cho các tài nguyên máy tính và cơ sở dữ liệu. Các mô hình định giá này áp dụng cho:

  • EC2
  • Cơ sở dữ liệu RDS 
  • Cụm Redshift
  • EMR
  • Lambda

On-Demand

Đây là mô hình giá mặc định cho các phiên bản AWS. Với mô hình này, khách hàng thanh toán theo phút hoặc theo giờ. Và không phải trả trước cho việc sử dụng. Lợi thế của On-Demand là linh hoạt và không cần cam kết dài hạn cũng như không phải trả trước dưới bất kỳ hình thức nào.

Hạn chế ở đây cũng là do tính linh hoạt này, đây là lựa chọn đắt tiền nhất. Nếu không có kế hoạch và ngân sách phù hợp. Việc mở rộng ứng dụng chỉ với On-Demand sẽ có tác động rất lớn đến hóa đơn hàng tháng.

Ví dụ: chạy Linux EC2 m5.xlarge với 4 vCPU và RAM 16GB ở khu vực us-east-1 region 24×7. Giả sử, phiên bản sử dụng dung lượng SSD 200GB dành cho mục đích chung, với hai lần snapshot hàng ngày, mỗi snapshot có 3GB thay đổi dữ liệu. Không có dữ liệu đến từ Internet, nhưng sẽ có dữ liệu đến từ các phiên bản khác ở vùng khác hoặc cùng khu vực. Phiên bản sẽ gửi dữ liệu ước tính 4GB đến một phiên bản khác trong cùng khu vực và 4 GB dữ liệu đến các phiên bản khác ở các khu vực khác nhau.

Sử dụng công cụ tính định giá AWS, giá hàng tháng (kể từ tháng 7 năm 2021) lên đến $174,81 đô la Mỹ.

Giữ nguyên các yêu cầu về cấu hình và khối lượng công việc, mua Phiên bản Reserved Instance với cam kết một năm và không phải trả trước sẽ làm giảm hóa đơn hàng tháng xuống còn 122,98 đô la.

Với mức chênh lệch 51,83 đô la mỗi tháng, dễ dàng hiểu tại sao các Phiên bản On-Demand không tốt cho khả năng mở rộng, ROI hoặc thậm chí cho việc sử dụng lâu dài.

Tuy nhiên, nó thực sự tốt nếu có một tỷ lệ nhỏ có sẵn các Phiên bản On-Demand. Như một số trường hợp dưới đây:

  • Khối lượng công việc tiền sản xuất — tức là những khối lượng được sử dụng trong quá trình phát triển, thử nghiệm hoặc triển khai thử nghiệm (PoC)
  • Khi dùng thử AWS lần đầu tiên

Nó cũng hữu ích đối với trường hợp sử dụng không yêu cầu sử dụng lâu dài. Một số khối lượng công việc có thể chỉ theo mùa — chẳng hạn như doanh số bán hàng cuối năm hoặc Giáng sinh. Không đáng để mua các phiên bản cam kết dài hạn cho các khối lượng công việc theo mùa này chỉ để cung cấp quá mức cho chúng khi nhu cầu giảm dần. Trong trường hợp này, sử dụng các Phiên bản On-Demand trong khoảng thời gian cao điểm sẽ tiết kiệm chi phí sau này.

Spot Instances

Do sự khổng lồ và quy mô của cơ sở hạ tầng, AWS sẽ luôn có một số tài nguyên chưa được sử dụng. Để giảm chi phí bảo trì cho các tài nguyên không sử dụng này, AWS đã giới thiệu Spot Instances.

Hãy nghĩ về Spot Instances giống như một hãng hàng không cung cấp mức giá chiết khấu cho các ghế trống trên chuyến bay. Vì đây là dung lượng còn lại, khách hàng có thể mua các dung lượng này với mức tiết kiệm lên đến 90% so với giá On-Demand. Tuy nhiên có một lời cảnh báo. Khi một khách hàng AWS trả phí khác cần dung lượng tài nguyên và sẵn sàng thanh toán On-Demand. Spot Instances sẽ bị chấm dứt và tài nguyên được đưa qua cho khách hàng kia. Tuy nhiên, có một tùy chọn ngủ đông (vì vậy bất kỳ quá trình xử lý nào cũng có thể bắt đầu lại khi tài nguyên có sẵn trở lại) và một cảnh báo hai phút.

Spot Instances hầu như chỉ giới hạn ở các hoạt động ngắn. Và không phù hợp với khối lượng công việc chạy lâu dài. Trên hết, những trường hợp này không nằm trong AWS SLA. Cam kết của Amazon đảm bảo tính khả dụng của các dịch vụ cho từng khu vực AWS với Tỷ lệ phần trăm thời gian hoạt động hàng tháng ít nhất là 99,99%. Do đó, ngay cả khi bạn giữ Spot Instances, AWS không có bất kỳ trách nhiệm nào để đảm bảo thời gian hoạt động của nó.

Xét về rủi ro, Spot Instances không được coi là một lựa chọn khả thi cho các ứng dụng quan trọng. Bản chất không chịu lỗi và không linh hoạt của Spot sẽ cần một số hỗ trợ khi sử dụng cho mục đích sản xuất như:

  • Dự đoán chính xác về trường hợp ngừng hoạt động. Và đặt giá thầu kịp thời trên thị trường Spot.
  • Tự động xử lý các phiên bản bị lấy lại. Để giải quyết tình trạng mất dữ liệu và thu thập bất kỳ thông tin trạng thái nào.
  • Việc khởi chạy lại đúng số lượng phiên bản trong một thời gian để duy trì cùng mức hiệu suất và SLA.
  • Cấu hình cân bằng tải tự động.

Khi người dùng sẵn sàng chấp nhận rủi ro như điều kiện trên. Có một số khối lượng công việc có thể được coi là “Ứng viên” cho mức giá này:

  • CI/CD pipeline. Ở đây, mất một phiên bản có nghĩa là phải chạy lại bất kỳ dòng công việc chưa hoàn thành nào sau khi có một phiên bản khác 
  • Khối lượng công việc phi sản xuất không cần thời gian hoạt động liên tục
  • Khối lượng công việc mà dữ liệu bị mất có thể nhanh chóng được phục hồi
  • Khối lượng công việc được chứa trong container trong đó thỉnh thoảng có thể cần thêm các nút bổ sung.

Một cách khác, Spot Instances có thể tiết kiệm chi phí là khi chúng được sử dụng cùng với các mô hình định giá theo cam kết cụ thể khác. Chẳng hạn như tình huống này

Giả sử một ứng dụng đặt vé du lịch chạy trên hai phiên bản EC2. Trong các mùa cao điểm trong năm, nhóm điều chỉnh quy mô tự động đưa ra thêm hai phiên bản khi lưu lượng tăng. Khách hàng đã mua bốn Reserved Instances. Hai trong số đó được đính kèm với các phiên bản hiện tại. Phần còn lại được gắn vào các nút khác. Trong các mùa cao điểm, hai RI được tách ra khỏi các nút khác và gắn vào hai nút phụ của ứng dụng du lịch.

Khi công ty phát triển, đôi khi ngay cả bốn nút cũng không thể đáp ứng lưu lượng vào thời kỳ cao điểm. Nếu không có kế hoạch xác định về các đỉnh này, công ty có thể không muốn đầu tư vào nhiều RI hơn. Thay vào đó, họ có thể chọn một Spot Instances khi sự tăng đột biến không thể đoán trước xảy ra. Bằng cách đó, nó không chỉ cho phép ứng dụng hoạt động với cùng mức hiệu suất mà còn tiết kiệm chi phí.

Reserved Instances

Reserved Instances (RI) tương tự như mô hình đặt giá On-Demand mặc định. Ngoại trừ việc khách hàng “đặt trước” một cấu hình nhất định trong “thời hạn” từ 1 đến 3 năm. Là một phần của đặt phòng, khách hàng trả một khoản phí trả trước. Khoản thanh toán trả trước này có thể là:

  • Tổng chi phí chạy phiên bản trong khoảng thời gian đã chọn (trả trước đầy đủ).
  • Một phần chi phí chạy phiên bản trong khoảng thời gian đã chọn (trả trước một phần).
  • Không có chi phí chạy phiên bản trong khoảng thời gian đã chọn (không phải trả trước).
  • Khách hàng có thể tiết kiệm tới 72% chi phí AWS, tùy thuộc vào số tiền họ trả trước, thời hạn thanh toán (1 hoặc 3 năm) và loại RI có sẵn. Nói một cách dễ hiểu, bạn trả trước càng nhiều và cam kết càng dài thì bạn càng tiết kiệm được nhiều.

Có ba loại RI khác nhau: Reserved Instances tiêu chuẩn, Reserved Instances có thể chuyển đổi (có chiết khấu nhỏ hơn, nhưng linh hoạt hơn) và Reserved Instances theo lịch trình. Mỗi loại có một trường hợp sử dụng tốt nhất để xem xét:

  • Tiêu chuẩn: Hệ thống ở trạng thái ổn định sẽ chạy trong thời gian dài.
  • Theo lịch trình: Các hệ thống sẽ chạy trong thời gian dài với khối lượng công việc và cao điểm nhất định đã được dự đoán.
  • Có thể chuyển đổi: Hệ thống chạy trong thời gian dài, nhưng có thể thay đổi theo nhu cầu và phân bổ hơi khác so với bình thường.

Bây giờ, một điều cần lưu ý là RI không bị ràng buộc với bất kỳ trường hợp cụ thể nào. Chúng hoạt động giống như giấy phép mua hàng hơn. Nói cách khác, bạn có thể sử dụng RI của mình trên một số trường hợp. Sau đó quyết định loại bỏ các trường hợp đó khỏi RI và áp dụng RI cho một nhóm trường hợp đủ điều kiện khác. Trong khi RIs tiết kiệm rất nhiều tiền cho người dùng, chúng có những cạm bẫy. Tính linh hoạt của việc có thể chuyển đổi sang một loại phiên bản khác có thể gây nhầm lẫn. Hơn nữa, khi đã mua, khách hàng sẽ phải trả tiền cho dung lượng dự trữ bất kể việc sử dụng (hoặc thiếu). Nhiều tổ chức chuyển sang sử dụng RI để tiết kiệm tiền. Nhưng không phải lúc nào cũng dễ dàng quản lý chúng theo cách thủ công để đạt được lợi ích định giá tốt nhất.

Nhận thấy rằng nhiều khách hàng đang gặp khó khăn với các RI chưa sử dụng của họ. AWS đã giới thiệu “ Chợ “ Reserved Instances cho AWS. Đây là nơi các tổ chức có thể liệt kê các RI không sử dụng của họ để các công ty khác mua. Với “ Chợ “ RI, các công ty không phải mua cam kết thời hạn 1 hoặc 3 năm đầy đủ. RI có thời hạn còn lại lên đến 1 tháng mới đủ điều kiện để bán. 

Savings Plans

Được giới thiệu vào năm 2019, AWS Savings Plans là một giải pháp thay thế cho Reserved Instances. Với Savings Plans, thay vì cam kết thời hạn thanh toán và hình thức thanh toán. Khách hàng cam kết chi tiêu số tiền tối thiểu mỗi giờ trong một hoặc ba năm tiếp theo. Đổi lại, AWS tính phí theo giờ giảm đáng kể trong thời hạn. Ngoài ra, Savings Plans có thể áp dụng cho các tài nguyên như EC2, Fargate hoặc Lambda. Điều này cho phép sự linh hoạt trong việc chọn loại phiên bản tốt nhất để nhận chiết khấu về giá.

Hiện có hai loại Savings Plans được cung cấp:

  • Compute: Những hệ thống này phù hợp nhất cho các hệ thống phát triển nhanh. Và có thể cần một bộ dịch vụ khác ngoài EC2 và các họ phiên bản khác nhau trong tương lai. Chi phí cao hơn nhưng cũng linh hoạt hơn. Compute Savings Plans có thể được áp dụng cho các EC2, dịch vụ Fargate hoặc Lambda. Điều này mở rộng trên bất kỳ phiên bản, kích thước, vùng AWS, hệ điều hành. Khoản tiết kiệm có thể lên đến 66%.
  • EC2: Như tên gọi, nó chỉ áp dụng cho EC2 và chỉ áp dụng cho một loại cụ thể trong một khu vực cụ thể. Cần lưu ý rằng điều này không phụ thuộc vào vùng khả dụng, trên mọi kích thước phiên bản, hệ điều hành hoặc thời gian thuê. Điều này phù hợp nhất cho khối lượng công việc lớn nhưng có thể dự đoán được. EC2 SP bị hạn chế hơn, nhưng tiết kiệm nhiều hơn (lên đến 72%).

Nhược điểm của SP là hiện chỉ có sẵn cho EC2 Compute, Fargate và Lambda. Có nghĩa là bạn vẫn cần một cách tiếp cận khác để tiết kiệm chi phí RDS, EMR hoặc Redshift. Một thiếu sót khác là RI có thị trường để bán các phiên bản không sử dụng. Trong khi SP thì không. Điều đó có nghĩa là khách hàng bị hạn chế chi tiêu số tiền tối thiểu trong khoảng thời gian đã chọn. Do đó, lạm dụng SP có thể gây ra tăng đột biến lớn về chi phí. Cuối cùng, mua các Savings Plans cần lập kế hoạch cẩn thận hơn khi so sánh với các mô hình định giá thay thế.

Có nhiều lý do để sử dụng hybrid như giảm chi phí, nâng cao hiệu quả, v.v. Nhưng chỉ vì hybrid đi kèm với một loạt lợi ích không có nghĩa là nó không có thách thức.

Đối với người mới bắt đầu, bảo mật đám mây lai thật sự phức tạp. Bằng cách thêm đám mây công cộng vào hỗn hợp, bảo mật của bạn hiện được chỉ đạo bởi các API. Và do đó, các nhà phát triển thay vì hoạt động sẽ chịu trách nhiệm về việc triển khai nó. Đây có thể là một khoảng cách lớn về kỹ năng đối với nhiều người không quen với những nhiệm vụ này. Hơn nữa, khi dữ liệu được truyền giữa các đám mây khác nhau, nó rất dễ bị tấn công bởi các tác nhân độc hại. Mã hóa mạnh mẽ có thể giúp đảm bảo dữ liệu của bạn được bảo vệ khi nó di chuyển giữa các đám mây khác nhau.

Quản trị và tuân thủ cũng là những thách thức đối với những người bắt đầu với các đám mây lai. Vì chúng được xử lý khác nhau và được quản lý bởi các nhóm khác nhau. Tùy thuộc vào việc bạn đang làm việc tại cơ sở, riêng tư hay trên các đám mây công cộng. Khi nhóm của bạn thiếu kinh nghiệm xử lý sẽ bị yêu cầu thực hiện khóa đào tạo cần thiết.

Tóm lại

Điện toán đám mây với AWS đòi hỏi một mức độ chuẩn bị và lập kế hoạch nhất định. Biết được loại tài nguyên nào bạn cần để chạy khối lượng công việc của mình. Và ước tính kiểu sử dụng tốt nhất có thể sẽ giúp bạn đi một chặng đường dài hướng tới việc tối ưu hóa chi tiêu trên đám mây của mình. Ngoài ra, nhu cầu ứng dụng của bạn càng đơn giản thì càng rẻ trên AWS. Vì vậy bạn có thể muốn tái kiến ​​trúc các ứng dụng nguyên khối lớn thành các dịch vụ độc lập, nhỏ hơn hoạt động cùng nhau.

Không có một giải pháp phù hợp với tất cả cho mọi tình huống. Mỗi trường hợp sử dụng sẽ có các yêu cầu riêng. Sự kết hợp tốt giữa các kế hoạch định giá có thể mang lại kết quả tốt hơn trong hầu hết các trường hợp.

Ví dụ: bạn có thể sử dụng kết hợp Reserved Instances và Savings Plans để trang trải phần lớn khối lượng công việc sản xuất liên tục của mình. Và sau đó lấp đầy khoảng trống còn lại bằng cách sử dụng Phiên bản On-Demand. Và Spot instances bằng cách sử dụng các quan sát tự động và tính toán giá cả.

Nói thì dễ hơn làm. Việc phát triển một hệ thống như vậy để quản lý hiệu quả các phiên bản, kế hoạch và thanh toán của bạn là khá phức tạp. Và nó chắc chắn sẽ tốn rất nhiều thời gian của các kỹ sư. Mà có thể được dành tốt hơn cho việc phát triển các tính năng mới cho ứng dụng cho doanh nghiệp.

Đừng lo lắng, Renovisor cung cấp một nền tảng tự động để quản lý RI của bạn mà không cần nỗ lực kỹ thuật. Sử dụng dữ liệu thời gian thực, Renovisor sử dụng AI để tự động mua và bán các giao dịch sinh lợi nhất trên thị trường RI. Dẫn đến tăng tiết kiệm và dự đoán ngân sách tốt hơn. Với Renovisor, bạn có thể tận dụng thế mạnh của đám mây AWS mà không cần lo lắng về những thách thức liên quan đến giá cả.

Liên hệ ngay với những chuyên gia đám mây của chúng tôi để tìm hiểu cách bạn có thể tự động hóa trải nghiệm đám mây của mình. Và để cắt giảm hơn 50% chi phí.