Tối ưu chi phí trên AWS giúp doanh nghiệp tiết kiệm đến 80% ngân sách hạ tầng mà vẫn đảm bảo hiệu suất hoạt động. Khám phá ngay các chiến lược thực tế như dùng Spot Instances, Savings Plans, Graviton, S3 Intelligent-Tiering và tự động hóa xóa tài nguyên không sử dụng để kiểm soát chi phí hiệu quả nhất trên AWS.
1. Cách ước tính chi phí trên AWS
1.1. Các công cụ ước tính chi phí trên AWS
1.1.1. AWS Pricing Calculator
AWS Pricing Calculator hỗ trợ hầu hết dịch vụ AWS (EC2, RDS, S3, Lambda,...) lập kế hoạch chi phí hoặc lập ngân sách dự án. Có thể xuất file PDF/CSV để báo giá.
1.1.2. Cost Explorer (cho người đã có tài khoản)
+ Dùng để xem thực tế chi phí đã phát sinh
+ Có thể phân tích theo dịch vụ, tag, region, account, ngày/tháng
+ Tự động cảnh báo vượt ngưỡng chi tiêu
1.2. Các yếu tố ảnh hưởng đến chi phí
1.2.1. Loại dịch vụ
| Dịch vụ | Đơn vị tính phổ biến | Ghi chú |
|---|---|---|
| EC2 | $/giờ hoặc $/giây | Tính theo loại máy, thời lượng |
| Lambda | $/GB-second + số request | Miễn phí 1 triệu request đầu |
| S3 | $/GB/tháng + $/request + data out | Lưu ý truy cập và truyền ra ngoài |
| RDS | $/giờ + lưu trữ + backup | Càng cao cấu hình càng đắt |
| CloudFront | $/GB dữ liệu truyền ra | Tính theo region người dùng cuối |
1.2.2. Vùng (region) sử dụng
+ Giá ở Singapore, Tokyo thường đắt hơn N. Virginia (us-east-1)
+ Luôn chọn region gần khách hàng nhưng cân đối với chi phí
1.2.3. Loại giá
| Loại giá | Tiết kiệm được | Áp dụng khi... |
|---|---|---|
| On-demand (trả theo giờ) | ❌ Không | Dễ dùng, nhưng đắt |
| Reserved Instances | ✅ ~70% | Cam kết 1-3 năm |
| Spot Instances | ✅ ✅ ~90% | Giá rẻ nhưng có thể bị thu hồi |
| Savings Plans | ✅ ~66% | Cam kết sử dụng compute, linh hoạt dịch vụ |
1.2.4. Truyền dữ liệu
+ Inbound (vào AWS): Miễn phí
+ Outbound (ra Internet): Tính phí $0.09–$0.12/GB tùy vùng
+ Giữa các AZ / region khác nhau: Có phí
+ Nội bộ cùng AZ bằng private IP: Miễn phí
+ Dưới đây là danh sách các cách truyền dữ liệu miễn phí trên AWS, được chia theo từng loại kịch bản:
+ Truyền dữ liệu vào AWS từ Internet (Inbound): Tất cả dữ liệu từ ngoài (Internet) vào AWS đều miễn phí ở tất cả các dịch vụ.
| Tình huống | Miễn phí? | Ghi chú |
|---|---|---|
| Người dùng tải file lên Amazon S3 qua website | ✅ | Miễn phí inbound |
| Người dùng POST dữ liệu vào API Gateway, ALB, EC2, Lambda | ✅ | Miễn phí |
| Thiết bị IoT gửi dữ liệu tới IoT Core | ✅ | Miễn phí |
| Gửi dữ liệu từ máy chủ bên ngoài vào Amazon RDS thông qua public IP | ✅ | Miễn phí |
| Upload dữ liệu qua AWS CLI, S3 SDK từ máy local → S3 | ✅ | Miễn phí |
| Kết nối WebSocket từ client vào EC2 hoặc API Gateway | ✅ | Miễn phí |
+ Truyền nội bộ giữa dịch vụ trong cùng Availability Zone (AZ): Truyền dữ liệu trong cùng AZ và dùng private IP thì thường miễn phí nếu:
+ Sử dụng Private IP
+ Hai tài nguyên nằm trong cùng AZ và cùng Region
+ Không đi qua Internet hoặc NAT Gateway
+ Dữ liệu truyền nội bộ phải đảm bảo:
+ Kiểm tra IP đang dùng: EC2 dùng private IP (172.x, 10.x, 192.168.x)
+ Kiểm tra route tables: Route phải đi qua local, không qua Internet Gateway (IGW) hoặc NAT
+ Dùng VPC Endpoint cho S3/DynamoDB: Dùng Gateway Endpoint để không mất phí
| Tình huống | Miễn phí? | Ghi chú |
|---|---|---|
| EC2 → RDS cùng AZ qua private IP | ✅ | Không đi qua internet |
| EC2 → S3 (nếu dùng VPC Endpoint) | ✅ | Dùng S3 Gateway Endpoint |
| Lambda → DynamoDB trong cùng VPC | ✅ | Không đi qua public network |
| EC2 ↔ EC2 trong cùng AZ và subnet | ✅ | Dùng private IP |
+ Dùng VPC Endpoint (Gateway hoặc Interface): Dùng Gateway Endpoint cho S3 & DynamoDB là cách miễn phí truyền dữ liệu hoàn toàn trong VPC.
| Loại Endpoint | Dịch vụ áp dụng | Miễn phí truyền? | Ghi chú |
|---|---|---|---|
| Gateway Endpoint | S3, DynamoDB | ✅ | Không tính phí |
| Interface Endpoint | Dịch vụ khác (API, NLB) | ❌ $0.01/GB | Dùng cho PrivateLink |
+ CloudFront → S3 (Origin fetch): Tận dụng CloudFront vừa giảm tải vừa không mất phí truyền dữ liệu từ S3.
| Tình huống | Miễn phí? | Ghi chú |
|---|---|---|
| CloudFront fetch dữ liệu từ S3 origin | ✅ | Miễn phí nếu ở cùng region |
+ Một số kết nối nội bộ của AWS
| Tình huống | Miễn phí? | Ghi chú |
|---|---|---|
| Lambda → DynamoDB/S3 trong cùng region | ✅ | Miễn phí nếu không qua Internet |
| S3 Replication nội vùng (S3 → S3 trong cùng region) | ✅ | Miễn phí replication nội vùng |
+ Data transfer out ≤ 1 GB/tháng: AWS tặng 1 GB miễn phí truyền dữ liệu ra Internet mỗi tháng ở hầu hết dịch vụ.
2. Dùng đúng loại EC2 instanceDưới đây là phân loại EC2 instance tuỳ theo từng mục đích sử dụng:
| Nhóm Instance | Ký hiệu | Mô tả | Ví dụ sử dụng | Chi phí |
|---|---|---|---|---|
| General Purpose | t, m |
Cân bằng CPU–RAM | Web, App server, dịch vụ nội bộ | Rẻ và linh hoạt |
| Compute Optimized | c |
CPU mạnh | Video encoding, gaming server, API heavy | Cao hơn t |
| Memory Optimized | r, x, z |
RAM nhiều | In-memory DB, phân tích dữ liệu | Cao |
| Storage Optimized | i, d, h |
IOPS cao, local SSD | NoSQL DB, Big Data, Hadoop | Cao |
| Accelerated Computing | p, g, inf, trn |
GPU, ML/AI, HPC | AI training/inference, rendering | Rất cao |
Để dùng loại EC2 instance sao cho siêu tiết kiệm nhất, cần kết hợp chiến lược lựa chọn instance phù hợp theo workload, mô hình thanh toán, và kiến trúc phần cứng
| Workload | Instance Tiết Kiệm Nhất | Lý do |
|---|---|---|
| Web app, API, Backend nhẹ | t4g.micro → t4g.medium |
Graviton, burstable, giá thấp |
| Batch, render, CI/CD, ML | c6g, m7g, hoặc Spot |
Graviton + hiệu năng cao |
| DB nhỏ, Redis, Kafka nhẹ | m6g, r6g, t4g |
Graviton + memory tối ưu |
| GPU nhẹ (AI inferencing) | g5g.xlarge, inf2 |
Giá rẻ hơn dòng p3, p4 |
| Static site, CDN Edge | CloudFront + S3 | Không cần EC2 |
Ưu tiên dùng Graviton (ARM) để tiết kiệm ~20–40% chi phí so với cùng loại dùng Intel hoặc AMD
| Dòng Graviton | Mục tiêu |
|---|---|
t4g |
General purpose, chi phí thấp |
m6g, m7g |
Balanced CPU/Mem |
c6g, c7g |
Compute-intensive |
r6g, r7g |
Memory-intensive |
g5g |
GPU cho ARM |
Nếu đang chạy web app hoặc service backend mà không phụ thuộc thư viện x86 đặc thù, hãy ưu tiên Graviton:
+ Graviton = ARM architecture (aarch64)
+ EC2 Graviton không dùng kiến trúc x86_64 (Intel/AMD)
+ Các file nhị phân/x86 library không tương thích.
+ Nếu app không hỗ trợ ARM, thì sẽ không chạy được trên Graviton, trừ khi:
| Giải quyết | Mô tả |
|---|---|
| 🔄 Biên dịch lại cho ARM (nếu có source code) | gcc, go, cargo, dotnet, v.v. |
| 🐳 Dùng Docker multi-arch | Build với --platform linux/arm64 |
| ⚙️ Tìm bản ARM chính thức | Rất nhiều phần mềm mở đã hỗ trợ |
| ❌ Nếu không thể → dùng EC2 x86 như t3, m5, c6i,... | Không chuyển Graviton được |
Dùng Graviton giúp tiết kiệm 20–40%, thậm chí nhiều hơn nếu kết hợp với:
+ Spot instance: Là loại EC2 instance rẻ nhất mà bạn có thể mua trên AWS. AWS sử dụng mô hình đấu giá công suất nhàn rỗi – nghĩa là: Thuê lại máy chủ EC2 mà AWS đang không dùng tới. Mặc dù giá rẻ hơn đến 90% so với On-Demand nhưng có thể bị AWS thu hồi bất kỳ lúc nào khi họ cần máy cho khách hàng khác (On-Demand user). Phù hợp với các workload tạm thời, xử lý song song, không yêu cầu uptime cao.
Ví dụ 1: Có job xử lý ảnh mất 30 phút/job. Xem xét triển khai 100 Spot EC2 instance chạy song song → tiết kiệm 90% chi phí, nếu 1–2 instance bị thu hồi thì retry lại job đó.
Ví dụ 2: Spot rất phù hợp để scale-out hệ thống Big Data. Dùng Spot cho các worker node; On-Demand cho các master node / coordinator; Auto Scaling Group có mix cả Spot và On-Demand (80% Spot, 20% On-Demand hoặc 70% Spot, 30% On-Demand)
+ Auto Scaling
+ Savings Plan
3. Savings Plans hoặc Reserved Instances
Savings Plans và Reserved Instances (RI) là hai phương pháp tối ưu chi phí dài hạn trên AWS — có thể giảm tới 72% chi phí so với On-Demand. Nhưng mỗi loại phù hợp cho tình huống khác nhau.
Savings Plans – nên dùng nếu có workload linh hoạt (VD: đổi instance type, vùng, scaling theo giờ). Có 2 loại chính:
| Loại | Mô tả | Tiết kiệm |
|---|---|---|
| Compute Savings Plans | Cam kết chi tiêu $/giờ cho compute (EC2, Fargate, Lambda). Rất linh hoạt. | ~66% |
| EC2 Instance Savings Plans | Cam kết EC2 theo family (VD: m6g, t4g) và region, nhưng có thể thay đổi size, OS, AZ |
~72% |
Reserved Instances (RI) – nên dùng nếu có workload rất cố định, ít thay đổi trong 1–3 năm (VD: app nội bộ, server backend, license cố định)
| Loại | Mô tả | Tiết kiệm |
|---|---|---|
| Standard RI | Cố định instance type, AZ, OS, tenancy | Up to 72% |
| Convertible RI | Đổi loại instance được (phải cùng giá trị) | ~54% |
+ Luôn dùng gp3 thay vì gp2 để giảm chi phí mà vẫn đảm bảo hiệu năng.
| Loại Volume | Mô tả | Dùng cho |
|---|---|---|
gp3 |
SSD hiệu năng cao, giá rẻ hơn gp2 ~20%, tách IOPS/Throughput khỏi dung lượng |
Dùng mặc định cho mọi workload |
io2 / io2 Block Express |
SSD cao cấp, IOPS rất cao, độ bền 99.999% | Database (OLTP, SAP HANA, Oracle...) |
st1 |
HDD hiệu năng cao, tính theo throughput | Dữ liệu lớn, log, Big Data |
sc1 |
HDD giá rẻ, hiệu năng thấp | Dữ liệu ít truy cập (archival, backup) |
gp3 tách biệt dung lượng với hiệu năng: Tối đa 16 000 IOPS và 1 000 MB/s throughput. Ta có thể dùng ổ nhỏ (ví dụ 100GB) nhưng vẫn tăng IOPS lên 3 000 hoặc hơn. Cấu hình này sẽ tiết kiệm nếu workload cần IOPS nhưng không cần nhiều GB.
Chỉ dùng io2 / io2 Block Express chỉ khi thực sự cần vì chi phí cao. Phù hợp cho Database cao cấp như Oracle RAC, SAP, SQL Server Enterprise,... và yêu cầu IOPS cực cao >16 000. Nếu không cần IOPS cao, luôn ưu tiên gp3.
+ Gắn tag AutoDelete để tự động xóa volume khi EC2 (Spot hoặc On-Demand) terminate.
+ Xóa snapshot cũ không dùng nữa.
5. Dọn dẹp các tài nguyên không dùng, còn tồn đọng, gây tốn phí trên AWS
Một số loại tài nguyên “Zombie” thường gặp trên AWS
| Loại tài nguyên | Cách dọn dẹp tối ưu |
|---|---|
| EC2 Stopped lâu | Terminate nếu không dùng |
| EBS volume không gắn | Xóa thủ công hoặc tự động (script, Lambda) |
| Elastic IP không gắn | Release |
| Snapshots cũ | Xóa theo lifecycle hoặc script tự động |
| Load Balancers không dùng | Xóa bỏ |
| Security Groups trống | Xóa |
| S3 bucket không dùng | Xóa hoặc archive dữ liệu |
| Lambda không dùng | Xóa hoặc disable |
| IAM Roles không dùng | Xóa để bảo mật và sạch |
Một số thiết lập để giám sát tài nguyên hệ thống:
+ Sử dụng AWS Trusted Advisor
+ Dùng AWS Config và AWS Config Rules
+ Thiết lập tagging chuẩn và quản lý tài nguyên
+ Tạo quy trình bảo trì định kỳ
6. S3 Lifecycle & Storage Classes
Tối ưu chi phí Amazon S3 bằng Lifecycle Rule và Storage Classes là một trong những cách tiết kiệm đơn giản nhưng cực kỳ hiệu quả, đặc biệt nếu bạn lưu trữ nhiều file tĩnh, log, backup, media,...
+ Storage Classes (Lớp lưu trữ)
| Lớp lưu trữ | Mô tả | Giá (so với S3 Standard) | Use case |
|---|---|---|---|
S3 Standard |
Truy cập thường xuyên, độ trễ thấp | 💰💰💰 (cao nhất) | Website, app, API, file truy cập nhiều |
S3 Intelligent-Tiering |
Tự động phân tầng truy cập | 💰💰 (rẻ hơn Standard) | Dữ liệu có thể biến động về tần suất truy cập |
S3 Standard-IA |
Infrequent Access – truy cập ít, cần nhanh | 💰 (rẻ) | Backup, dữ liệu đọc 1 vài lần/tháng |
S3 One Zone-IA |
Giống IA nhưng lưu tại 1 AZ (nguy cơ mất dữ liệu cao hơn) | 💰 (rẻ nhất IA) | Dữ liệu không quan trọng, dễ phục hồi |
S3 Glacier Instant Retrieval |
Truy cập ngay, dành cho lưu trữ dài hạn | 💰 (thấp) | Log archive, dữ liệu đọc ít nhưng cần nhanh |
S3 Glacier Flexible Retrieval |
Lưu trữ lâu dài, truy cập trong vài phút–giờ | 💰💰 (rất rẻ) | Dữ liệu cần giữ lâu năm, không truy cập thường xuyên |
S3 Glacier Deep Archive |
Rất lâu, truy cập chậm (vài giờ), rẻ nhất | 💰 (rẻ nhất) | Lưu trữ backup, hồ sơ pháp lý, archive 7–10 năm |
- Có thể dùng S3 Intelligent-Tiering để tự động chuyển dữ liệu ít truy cập sang lớp lưu trữ rẻ hơn.
- Xem xét lớp S3 Glacier / Deep Archive cho dữ liệu lưu trữ lâu dài.
- Bật S3 lifecycle policy: Tự chuyển file cũ → Glacier / xóa file log sau X ngày.
- Có thể kết hợp với CloudFront để cache file thường xuyên, giảm số lần đọc từ S3. Trường hợp sử dụng S3 Intelligent-Tiering, khi CloudFront giảm lượng truy cập đáng kể vào S3, các file có thể chuyển xuống lớp IA hoặc Glacier, giúp tiết kiệm chi phí lưu trữ.
7. AWS Cost Explorer + Budgets
8. Lambda – tối ưu chi phí serverless
8.1. Tối ưu thời gian thực thi và bộ nhớ
- Chi phí Lambda = Thời gian chạy x RAM cấp phát
- Dùng công cụ AWS Lambda Power Tuning để tìm điểm tối ưu RAM và thời gian xử lý (nhiều RAM hơn có thể xử lý nhanh hơn → tổng chi phí thấp hơn).
8.2. Loại bỏ Cold Start (tốn thời gian → tốn tiền)
Cold start xảy ra khi Lambda không hoạt động trong một thời gian dài.
Giải pháp:
+ Dùng Provisioned Concurrency nếu cần latency thấp & predictable (tốn thêm phí nhỏ, nhưng tiết kiệm hơn với chức năng cần phản hồi nhanh).
+ Hoặc giữ warm bằng CloudWatch Scheduled Event (gọi Lambda mỗi 5–10 phút).
8.3. Chia nhỏ hàm Lambda (Function Granularity)
Tránh viết một Lambda “đa năng” → tải lớn, tốn RAM.
Tách ra thành các hàm nhỏ với logic rõ ràng → tiết kiệm tài nguyên và debug dễ hơn.
8.4. Tối ưu kích thước package (deployment package size)
Gói code càng nhỏ thì cold start càng nhanh (→ tiết kiệm chi phí thời gian chạy).
Dùng:
+ Tree-shaking (với Node.js/Webpack).
+ Import cụ thể module (lodash.pick() thay vì import * as _ from 'lodash').
+ Loại bỏ dependency không dùng.
+ Dùng Lambda Layers nếu có thư viện chia sẻ.
8.5. Dùng đúng ngôn ngữ runtime
Các ngôn ngữ khác nhau có cold start và performance khác nhau:
| Ngôn ngữ | Cold Start (ms) | Thời gian chạy trung bình | Ghi chú |
|---|---|---|---|
| Node.js | 🟢 Rất thấp (50–150ms) | 🟢 Nhanh | Thích hợp với API, real-time |
| Python | 🟢 Rất thấp (60–170ms) | 🟢 Nhanh | Phù hợp xử lý dữ liệu, ML |
| Go | 🟢 Thấp (70–180ms) | 🟢 Rất nhanh | Hiệu năng cao, dùng ít RAM |
| Java | 🔴 Cao (300ms–1s) | 🟢 Rất nhanh | Cần Provisioned Concurrency nếu cần phản hồi nhanh |
| .NET Core | 🔴 Cao (400ms–1.2s) | 🟢 Rất nhanh | Như Java, tốt cho task nặng |
| Ruby | 🟡 Trung bình (200–500ms) | 🟡 Trung bình | Ít phổ biến hơn |
| Custom Runtime (Rust, C++) | 🟡 Tùy cách viết | 🟢 Rất nhanh | Có thể tối ưu sâu, phức tạp hơn |
8.6. Theo dõi và tối ưu bằng CloudWatch + X-Ray
Bật AWS X-Ray để theo dõi thời gian chạy cụ thể.
Dùng CloudWatch Logs để:
+ Kiểm tra các đoạn mã nào gây trễ.
+ Phân tích lượng request theo thời gian → scale hợp lý.
8.7. Batch và Async xử lý nếu phù hợp
Nếu xử lý 1 000 request riêng lẻ → 1.000 lần charge.
Thay vì đó, dùng SQS batch, hoặc event batch (S3, Kinesis, DynamoDB stream) để gom request → xử lý ít lần hơn.
8.8. Giới hạn thời gian Timeout
Mặc định có thể lên tới 15 phút → nếu code bị treo vẫn bị tính phí.
Đặt timeout ngắn nhất có thể cho từng hàm (ví dụ: 5s, 10s).
8.9. Chỉ cấp quyền cần thiết (IAM) → tránh tác vụ ngoài ý muốn
Một số service AWS bị tính phí khi Lambda gọi (ví dụ: DynamoDB, Step Functions).
Cấp quyền càng cụ thể thì càng dễ kiểm soát chi phí nếu có bug/phá hoại.
8.10. Kết hợp Lambda với các dịch vụ tiết kiệm chi phí hơn
Việc kết hợp AWS Lambda với các dịch vụ khác là một cách cực kỳ hiệu quả để tối ưu chi phí, vì Lambda không phù hợp cho mọi trường hợp, đặc biệt là các tác vụ lâu, nhiều trạng thái, hoặc cần scale lớn.
| Lambda + Dịch vụ kết hợp | Mục đích | Lý do tiết kiệm |
|---|---|---|
| Step Functions | Workflow nhiều bước | Thay vì viết một Lambda lớn chạy 10 phút (tốn tiền), chia nhỏ thành các Lambda nhỏ chạy 5–10 giây. |
| SQS / SNS | Giao tiếp async, batch | Giảm số lần gọi Lambda đồng thời (concurrent), gom batch xử lý. |
| EventBridge | Lập lịch / routing sự kiện | Miễn phí mức cao |
| DynamoDB | Cơ sở dữ liệu NoSQL | On-demand, free tier |
| S3 + CloudFront | Phân phối nội dung tĩnh | Truy cập nội dung tĩnh qua CloudFront rẻ hơn gọi Lambda để render. |
| API Gateway HTTP API | API nhẹ, đơn giản | API Gateway HTTP API rẻ hơn REST API Gateway tới 70% chi phí request. |
| Lambda@Edge + CloudFront | Xử lý tại biên CDN | Xử lý logic tại Edge location gần user → giảm số lần gọi về Lambda chính. |
