#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

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 Cloud mà mình đang quản lý.

Lúc này, hạ tầng cloud của chúng ta đã ổn, các services chạy ngon, không lỗi, team hài lòng, nhưng khi cuối tháng bạn nhìn hoá đơn thì ôi thôi, tại sao chỉ dùng có một vài dịch vụ, mà tiền phải trả lại vài ngàn đô. Dù là công ti 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, xem xét kỹ lưỡng. Chi phí cloud cũng vậy, nếu mà bạn kiểm soát tốt, cloud là một công cụ tuyệt vời, nếu không, tiền trong ví hàng tháng cứ mất dần mà không hiểu vì sao.

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

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 phải trả tiền cho những thứ không tạo ra gía trị. Những gì mình đã làm:

• Các bucket s3 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 vì nó không cần thiết.
• ECR, nơi lưu trữ các image docker, xoá hết các image không còn được dùng nữa (cái này mình làm đã giảm gần 100% chi phí so với trước), mình chỉ giữ lại 10 đến 12 cái 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ứ một instance EC2 nào …

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

Rõ ràng, bạn chỉ làm việc trong 8 tiếng, và sau đó là không dùng đến nữa. Nếu bạn vẫn tiếp tục để dịch vụ chạy, bạn phải trả tiền

Ví dụ như các services cho các môi trường ngoài production, chúng ta có thể stop từ 20h đến 7h sáng hôm sau.

• ECS: thiết lập số lượng service desired = 0
• RDS: stop và start vào sáng hôm sau
• EC2 instance: stop, start, hoặc giảm auto scaling về 0

Những cái này làm rất dễ, chỉ cần kết hợp bộ đôi Lambda + Event Bridge, scheduled giờ để nó tự tắt giúp mình dịch vụ chứ không phải lên bấm bằng tay đâu nhé, mọi thứ hoàn toàn tự động.

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

Cái này thì rõ ràng dành cho các object s3 rồi, thiết lập lifecycle cho bucket sẽ khiến bạn tiết kiệm kha khá chi phí nhé. Có rất nhiều dữ liệu là hot-data (dữ liệu được truy cập thường xuyên) thì để vào phần standard chẳng hạn, còn cold-data hoặc backup cho log thì chuyển vào Glacier. Các hướng dẫn thiết lập vòng đời cho object trên s3 mọi người có thể tìm trên mạng hoặc hỏi AI.

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

Hỏi hệ thống còn có thể tối ưu được không

Đây là tư duy mình dùng trong hầu hết các task, không chỉ là với aws. Mình là một dev backend, nhiều khi làm xong task rồi nhưng vẫn thấy code không ưng ý, hoặc một hàm được đặt tên không hợp lý, code vẫn chưa đảm bảo SOLID hoặc không thể tái sử dụng, là mình sẽ nghĩ ngay refacto lại cho gọn gàng, dễ nhìn hoặc tối ưu hơn.

Riêng về tối ưu chi phí với aws, câu hỏi này còn diễn ra thường xuyên hơn. Khi bạn deploy một hệ thống, điển hình như trên EC2, hay ECS, EKS hoặc RDS, nhiều khi bạn cấp phát tài nguyên quá mức cần thiết (cho an toàn), bạn vẫn phải trả tiền cho toàn bộ hạ tầng mà bạn đã cấp phát.

Ví dụ, khi mình làm việc cùng ECS Fargate, lúc đầu mình chọn cấu hình cho một payment-service là 4vCPU, 8GB RAM chẳng hạn, sau khi service đi vào hoạt động, thấy mức CPUUtilization và MemoryUtilization chỉ ở mức 10%, 20% thì mình sẽ giảm cấu hình Fargate xuống một nửa, sau đó xem mức sử dụng là bao nhiêu, tầm loanh quanh 50 đến 70% là hợp lý.

Chính vì thế, khi làm việc với bất kỳ hệ thống hay công việc nào, câu hỏi nên đặt ra trong đầu luôn là: hệ thống, công việc này còn có thể tối ưu được không. Nhiều khi tối ưu ở đây không chỉ là chi phí, mà còn là hiệu năng, khả năng mở rộng, hay clean code.

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 các best practice, bạn có thể đọc trong documentation, hoặc có thể hỏi ngay trong Amazon Q, nó sẽ trả lời giúp bạn. Một vài thứ mình đã làm theo như:

• S3 Gateway Endpoints: Thêm cái này cho hạ tầng của bạn, cái này không thừa đâu, traffic với S3 sẽ đi trong mạng nội bộ của AWS, không phải đi ra ngoài, bạn không phải trả tiền và VPC Gateway Endpojnt thì miễn phí (transfert data hoặc không tính phí theo giờ, ngon quá). Không phải loại Interface Endpoint nhé, trừ khi bạn thực sự cần vì cái này mất phí.
• ECS Fargate nên convert sang sử dụng nền tảng ARM thay vì x86_64, chi phí sẽ rẻ hơn mà chạy cũng ngon hơn (tiêu chí ngon bổ rẻ )
• Sử dụng Reserved Instance cho các instances EC2 hoặc RDS, cái này thì rõ ràng rồi
• Hạn chế bật public IP vì từ 2024, AWS bắt đầu thu phí do nguồn cung hạn hẹp. Sử dụng giao tiếp nội bộ trong cùng một private subnet, vừa an toàn lại rẻ, không cần phải đi ra ngoài làm gì
• Free tier, cái này hay nhé, mấy cái lambda, SNS, SQS, CloudWatch của mình toàn trong Free tier, không phải trả tiền mấy
• Theo dõi thường xuyên Bill AWS và thiết lập Budget cho AWS, tránh việc xử lý xảy ra quá muộn. Một khi phát hiện có một dịch vụ giá tăng cao bất thường, phải tìm hiểu rõ nguyên nhân tại sao. Nói chung cứ khoảng 2, 3 ngày bạn nên check Cost Explorer 1 lần cho chắc.
• Nếu ứng dụng của bạn sử dụng RDS Cluster, mà có phần đọc ghi nhiều, dẫn tới chi phí I/O cao (> 25% tổng bill của RDS), nên cân nhắc chuyển qua AWS có storage type I/O Optimized, khi đó, chi phí storage đắt hơn 30% nhưng chi phí I/O = 0

Nói chung vẫn còn rất nhiều cách để tiết kiệm chi phí cho AWS nữa. Cái quan trọng nhất vẫn là bạn phải hiểu dịch vụ và giá tiền của dịch vụ. Trước khi sử dụng dịch vụ, bạn nên xem cách tính giá của dịch vụ trước rồi phân tích cho kỹ, nhiều khi đâm đầu vào rồi khi có bill mới hỏi tại sao lại đắt như thế.

Kết

Với những gì mình đã làm bên trên, hoá đơn AWS đã giảm 40% so với thời điểm trước. Hài lòng vì mọi thứ vẫn chạy ổn, nhất là với những doanh nghiệp vừa và nhỏ, khi 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.