0

#3 Giảm 40% chi phí AWS cho công ti, mình chỉ dựa vào những tư duy này

Đây là một phần trong series mình chia sẻ về những gì mình đã làm khi xây dựng và vận hành hạ tầng backend trên AWS cho công ty. Không phải là best practice hoàn hảo, cũng không phải kiến thức quá cao siêu. Chỉ đơn giản là những gì mình đã học được, thử nghiệm và áp dụng trong quá trình làm việc hằng ngày. Thực ra đã có rất nhiều bài viết chia sẻ làm thế nào để tối ưu chi phí AWS. Mình cũng đã đọc, phân tích và áp dụng nếu cảm thấy phù hợp cho hạ tầng của công ty.

Như các bạn đã biết ở bài trước, mình được giao nhiệm vụ deploy hạ tầng backend của công ty lên AWS. Lúc này mọi việc đã xong xuôi, code đã chạy ngon, CTO hài lòng, nhưng hoá đơn hàng tháng lại làm mọi người đau đầu.

Dù là công ty lớn hay nhỏ, việc tối ưu chi phí của bất cứ khoản chi nào cũng phải được nghiên cứu và xem xét kỹ lưỡng.

Cách mình tối ưu hạ tầng

Những việc mình làm thực ra khá đơn giản:

  • Dọn dẹp bãi rác
  • Không dùng đến thì tắt đi
  • Dùng ít thì trả tiền ít
  • AWS khuyên gì thì mình làm nấy

Dọn dẹp bãi rác

Bạn không nhầm đâu.

Gần như trong toàn bộ infra, nếu không thường xuyên dọn dẹp, sẽ có một đống thứ không dùng nhưng vẫn tồn tại. Và chúng ta vẫn phải trả tiền cho những thứ không tạo ra giá trị.

Những gì mình đã làm:

  • Các S3 bucket không được dùng, hoặc các object của các môi trường ngoài production phải được dọn dẹp.
  • ECR, nơi lưu trữ các Docker image: xoá hết các image không còn được dùng nữa.
    Việc này giảm gần 100% chi phí ECR so với trước.
    Mình chỉ giữ lại 10 đến 12 images gần nhất.
  • Elastic IP, EBS tồn tại nhưng lại không gán vào bất cứ instance EC2 nào.

Chỉ riêng việc dọn dẹp thôi cũng đã giảm được kha khá chi phí.


Không dùng đến thì tắt đi

Rõ ràng bạn chỉ làm việc trong khoảng 8 tiếng mỗi ngày, và sau đó thì không dùng đến nữa.

Nếu bạn vẫn tiếp tục để dịch vụ chạy, bạn vẫn phải trả tiền 😄

Những gì mình đã làm:

  • ECS cho các môi trường staging, dev: stop từ 20h đến 7h sáng
  • RDS cho staging, dev: tương tự
  • Các dịch vụ CI/CD (EC2 instances) cũng có thể làm tương tự

Những cái này làm rất dễ.

Chỉ cần kết hợp Lambda + EventBridge, đặt scheduled để tự động tắt dịch vụ. Không cần phải lên console bấm tay mỗi ngày.


Dùng ít thì trả tiền ít

Cái này thì khá rõ ràng với S3.

Thiết lập lifecycle policy cho bucket sẽ giúp bạn tiết kiệm khá nhiều chi phí.

Ngoài ra bạn cũng có thể thiết lập lifecycle cho ECR, tự động xoá các image cũ để không phải xoá thủ công nữa.


AWS khuyên gì thì mình làm nấy

Cái này thì siêu đúng.

Mình có là gì so với mấy kỹ sư của AWS. Họ đã đưa ra rất nhiều best practices.

Bạn có thể:

  • đọc trong documentation
  • hoặc hỏi trực tiếp Amazon Q

Một vài thứ mình đã làm theo:

VPC Endpoint

Thêm VPC Endpoint cho hạ tầng của bạn.

Traffic với S3 sẽ đi trong mạng nội bộ của AWS, không đi ra internet.
Bạn không phải trả tiền data transfer và VPC Endpoint cho S3 cũng miễn phí.

Ngon.

ECS Fargate dùng ARM

ECS Fargate nên convert sang nền tảng ARM thay vì x86_64.

Chi phí rẻ hơn mà chạy cũng ngon hơn.
Tiêu chí: ngon – bổ – rẻ 😄

Reserved Instance

Sử dụng Reserved Instance cho:

  • EC2
  • RDS

Cái này thì quá rõ ràng rồi.

Hạn chế Public IP

Từ 2024, AWS bắt đầu thu phí Public IP do nguồn cung hạn hẹp.

Vì vậy nên:

  • hạn chế bật public IP
  • dùng giao tiếp nội bộ trong private subnet

Vừa an toàn hơn, vừa rẻ hơn.

Free Tier

Cái này cũng hay.

Các dịch vụ như:

  • Lambda
  • SNS
  • SQS
  • CloudWatch

của mình gần như toàn nằm trong Free Tier, nên không phải trả tiền.

Theo dõi AWS Bill

Luôn theo dõi AWS Billing và thiết lập AWS Budget.

Nếu một dịch vụ có chi phí tăng bất thường thì phải tìm hiểu nguyên nhân ngay.

Đừng để đến cuối tháng mới phát hiện ra thì hơi muộn.

RDS I/O Optimized

Nếu ứng dụng sử dụng RDS Cluster và có lượng đọc ghi lớn, chi phí I/O có thể chiếm hơn 25% tổng bill của RDS.

Trong trường hợp đó, nên cân nhắc dùng I/O Optimized storage.

  • Chi phí storage tăng khoảng 30%
  • Nhưng chi phí I/O = 0

Nhiều trường hợp tổng bill lại rẻ hơn.


Kết

Thực ra vẫn còn rất nhiều cách để tiết kiệm chi phí AWS.

Nhưng điều quan trọng nhất vẫn là:

Bạn phải hiểu dịch vụ và cách tính giá của nó.

Trước khi sử dụng một dịch vụ AWS, nên đọc kỹ cách tính giá và phân tích trước.

Không khéo lao vào dùng rồi đến lúc có bill mới biết thì hơi muộn.

Với những gì mình đã làm bên trên, hoá đơn AWS đã giảm khoảng 40% so với trước khi mình tới.

Hài lòng vì mọi thứ vẫn chạy ổn.

Nhất là với startup, bài toán chi phí nên được đặt lên ưu tiên hàng đầu.

Mọi thứ chạy ổn mà rẻ còn hơn chạy ổn mà đắt, phải không?


Bài viết này cũng được mình dịch sang tiếng Anh trên blog substack của mình.

Mình viết lại những điều này như một cách để ghi nhớ hành trình làm nghề của mình. Nếu bạn cũng đang làm backend, devops hoặc cloud, hy vọng những chia sẻ này có thể giúp bạn một chút gì đó. Còn nếu có chỗ nào mình hiểu chưa đúng, mình vẫn luôn sẵn sàng học thêm.


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí