Tối ưu chi phí – tối đa lợi nhuận luôn là kim chỉ nam của doanh nghiệp, và phòng Công Nghệ Thông Tin ngày nay được ví như “xương sống” của tổ chức, nhưng không đồng nghĩa với việc: các CTO được thoải mái vung tay mua sắm hard-ware & tuyển dụng ồ ạt! Mà tinh thần tiết kiệm chi tiêu nhưng vẫn giữ được tính ổn định của hệ thống, càng trở thành tiêu chuẩn của ngành – và “Điện Toán Đám Mây” với các chức năng ưu việt như: high availability, durability, global infrastructure, cost optimize,…. được xem như lời giải tốt nhất cho bài toán đầu tư công nghệ trong các tập đoàn mà còn cả start-up và công ty SME.
Yêu cầu của khách hàng
Thông thường, “hành trình lên Mây” được nhen nhóm bởi nhu cầu của team tech và chỉ thật sự bắt đầu khi thỏa các điều kiện về giá của team Finance. Vì vậy, tính minh bạch, sự rõ ràng, chi tiết về giá của từng dịch vụ, là những yêu cầu thiết yếu của một bảng báo giá tiêu chuẩn.
Nào hãy cùng nhau xem qua ví dụ về cách tính giá dựa trên nhu cầu & kiến trúc mà khách hàng đề xuất.
Đầu tiên, khách hàng sẽ gửi đến chúng ta hiện trạng hệ thống và yêu cầu khi lên cloud:
Hình 1: Yêu cầu từ khách hàng
Kiến trúc hệ thống
Từ yêu câu trên, chúng ta tiến hành vẽ kiến trúc và lập bảng báo giá chi tiết.
Hình 2: Kiến trúc hệ thống
Báo giá chi tiết
Hình 3: Báo giá chi tiết
Link đối chiếu giá từ Web chính thức của AWS:
- On-Demand: https://calculator.aws/#/estimate?id=242e58dc33fe2cf6f48f980e472e24ac0587a0ec
- RI 1 Year: https://calculator.aws/#/estimate?id=2d11a6b1200bc380bba1c913aa2305d9ecb6226f
Các bạn có thể đọc thêm về bài (AWS – EC2 purchasing options) để hiểu thêm về RI với chi phí 1 năm.
Lợi ích
Giai đoạn thuyết trình để thuyết phục khách hàng đồng ý với giải pháp sẽ dựa vào 2 yếu tố trên. Nhờ vào bảng vẽ kiến trúc, khách hàng dễ dàng hình dung được các yêu cầu của họ, khi lên AWS sẽ có hình hài ra sao, service đặt trong các layer nào, đường kết nối từ local lên cloud bảo mật ra sao, dùng dịch vụ gì cho hoạt động monitoring và migration,….
Bên cạnh đó, bảng báo giá giúp khách hàng ước lượng được chi phí khi lên cloud, triển khai các service cụ thể, và nếu họ có nhu cầu optimize cost thì sẽ tối ưu ở service nào (Vd: giảm instance type của EC2 xuống – trong giai đoạn chạy thử nghiệm, tạm thời dừng sử dụng tính năng multi az cho RDS)
Lưu ý
Khi triển khai cho một số khách hàng, khách có xu hướng “saving cost” hơn là áp dụng best practice ! ví dụ, đặt 2 EC2 và 1 RDS trong cùng 1 AZ để tránh phát sinh phí “data transfer”, không triển khai RDS trên multi AZ – hạn chế phát sinh cost cho 2 RDS (dù cost data transfer giữa Primary & Standby là free).
https://calculator.aws/#/ là một tool rất hay để người dùng có thể lường trước các hoạt động sẽ phát sinh phí trong quá trình sử dụng dịch vụ. Các service trong AWS sẽ có một số giới hạn nhưng không được synchronous đầy đủ trên tool calculator! và thấy các lỗi này hiếm gặp! Tuy nhiên, anh em nên đối chiếu giữa official document và tool trước khi propose một kiến trúc “Khủng” cho khách hàng: Vd: RDS – SQL Server Standard Edition chỉ hỗ trợ đến 24core, mà khách hàng cần RDS 32 core (db.r5.8xlarge) nhưng tool calulator vẫn cho chọn Standard edition, vậy trong thực tế khi triển khai cần Enterprise Edition (Con này chạy tầm 4 tỷ/năm).
Mong rằng, một số chia sẻ trên sẽ giúp các bạn tối ưu được chi phí khi sử dụng EC2 trên AWS
