Tối Ưu Chi Phí RDS Aurora 2026 (Gravito…

Cập nhật: 15 tháng 8, 2026

Tối ưu chi phí AWS RDS và Aurora trong 2026 thường cắt được 30–60% hóa đơn database mà không phải viết lại một dòng code, nhờ kết hợp Graviton4 (r8g/m8g), Reserved Instances 1–3 năm, Database Savings Plans, chuyển kho lưu trữ Aurora giữa Standard và I/O-Optimized theo tỉ lệ IOPS/GB, và right-sizing bằng AWS Compute Optimizer. Trong thực tế mà tôi triển khai cho khách hàng, ba đòn bẩy đầu chiếm phần lớn khoản tiết kiệm; phần còn lại đến từ việc dọn snapshot, xóa Multi-AZ không cần thiết và chặn instance T-family chạy Unlimited mode âm thầm.

Reserved Instances cho Aurora tiết kiệm tới 45% (1 năm) và 66% (3 năm). Đây là đòn bẩy đơn lẻ mạnh nhất cho tải production ổn định.
Database Savings Plans (ra mắt tại re:Invent 2025) tiết kiệm đến 35%, áp dụng liên engine/family/region. Chọn khi bạn có mix RDS, Aurora, DynamoDB, ElastiCache.
Chuyển từ x86 (r6i, r7i) sang Graviton4 (r8g, m8g) cho MySQL/PostgreSQL/MariaDB thường cắt 20–40% chi phí compute; migration là đổi instance class trong maintenance window, không đổi engine.
Aurora I/O-Optimized rẻ hơn Aurora Standard khi chi phí I/O vượt 25% tổng bill Aurora. Công thức hoà vốn có trong bài.
Instance T3/T4g mặc định chạy Unlimited mode: CPU credit tính 0,09 USD/vCPU-hour và không được Reserved Instance bao phủ, cần chặn hoặc chuyển sang Standard mode.
AWS Compute Optimizer với Enhanced Infrastructure Metrics (93 ngày) đưa ra khuyến nghị right-sizing đáng tin hơn so với 14 ngày mặc định.

Vì sao hóa đơn RDS/Aurora phình nhanh (và ai đang ăn tiền)

Trong hầu hết account tôi audit năm 2026, RDS và Aurora chiếm 18–35% tổng bill AWS, đứng thứ hai sau EC2 và ngang ngửa với S3 + Data Transfer. Điều đáng nói là 40–60% khoản đó thường là lãng phí có thể cắt trong 2–4 tuần mà không phải đụng vào application code.

Có năm "kẻ ăn tiền" thường gặp:

Instance x86 đời cũ (r5, m5, r6i) chạy PostgreSQL/MySQL trong khi Graviton3/4 tương đương rẻ hơn 20–40% với hiệu năng cao hơn.
Aurora Standard cho workload I/O nặng. Nếu I/O chiếm hơn 25% bill Aurora thì Aurora I/O-Optimized rẻ hơn ròng.
Multi-AZ trên môi trường dev/staging. Nhân đôi chi phí instance chỉ để đảm bảo uptime cho môi trường không production.
Aurora Serverless v2 với minimum ACU quá cao. Mỗi 0,5 ACU idle tốn khoảng 43 USD/tháng ở us-east-1; đặt min = 8 ACU trên cluster ít traffic đồng nghĩa 700 USD "cháy" mỗi tháng.
Snapshot cũ tích tụ nhiều năm. Snapshot tính theo GB-tháng ở giá gần bằng storage gốc; tôi từng thấy team giữ 12.000 snapshot legacy trị giá hơn 4.000 USD/tháng.

Trước khi tối ưu, bạn phải nhìn rõ ai đang tiêu tiền. Đó là lý do bước đầu tiên luôn là bóc tách bill, chứ không phải nhấn "Change instance class" theo lời khuyên chung chung.

Bóc tách bill RDS trong 30 phút với Cost Explorer + CUR

Cost Explorer đủ dùng cho 90% team. Filter Service = Relational Database Service, group by Usage Type, thêm dimension Instance Type, và bạn sẽ thấy ngay ba khoản chính: InstanceUsage (giờ chạy DB instance), StorageUsage (GB-tháng), IOUsage (Aurora Standard chỉ). Với Aurora, thêm filter Operation contains "aurora" để tách khỏi RDS classic.

Nếu bill lớn hơn 30.000 USD/tháng, bạn cần Cost and Usage Report (CUR 2.0) đổ vào Athena. Đây là truy vấn tôi mở đầu mỗi audit, nó gom chi phí theo cluster identifier để bạn thấy cluster nào ngốn nhất:

-- Top 20 cluster RDS/Aurora theo chi phí trong 30 ngày qua
SELECT
    line_item_resource_id                                 AS cluster_arn,
    product_instance_type                                 AS instance_type,
    SUM(line_item_unblended_cost)                         AS cost_usd,
    SUM(CASE WHEN line_item_usage_type LIKE '%InstanceUsage%'
             THEN line_item_unblended_cost END)           AS instance_cost,
    SUM(CASE WHEN line_item_usage_type LIKE '%Storage%'
             THEN line_item_unblended_cost END)           AS storage_cost,
    SUM(CASE WHEN line_item_usage_type LIKE '%IOUsage%'
             THEN line_item_unblended_cost END)           AS io_cost
FROM   cur_v2.aws_cur
WHERE  product_service_code IN ('AmazonRDS')
  AND  line_item_usage_start_date >= date_add('day', -30, current_date)
GROUP  BY line_item_resource_id, product_instance_type
ORDER  BY cost_usd DESC
LIMIT  20;

Kết quả cho bạn biết ngay: cluster nào cần Reserved Instance, cluster nào I/O cost cao hơn instance cost (ứng viên I/O-Optimized), cluster nào chạy đời x86 cũ (ứng viên Graviton). Đó là nền tảng phân bổ chi phí theo team và môi trường mà tôi luôn dựng trước khi khuyến nghị commitment.

Chuyển sang Graviton4 (r8g, m8g): cắt 20–40% không đổi kiến trúc

Graviton4 là ARM64 của AWS, đời thứ tư. RDS hỗ trợ đầy đủ trên MySQL, PostgreSQL, MariaDB (Aurora và RDS classic) qua các class db.r8g, db.m8g và bản memory-cao db.x8g. So với db.r6i tương đương, r8g rẻ hơn khoảng 10–20% giá on-demand và thường cho throughput cao hơn 20–40% với query PostgreSQL và MySQL nhờ băng thông memory tăng.

Migration cực đơn giản: ModifyDBInstance, chọn class mới, áp dụng trong maintenance window. Không đổi engine, không migrate data, không đổi driver. Downtime cho Multi-AZ là khoảng 60–120 giây khi failover. Đây là script tôi hay dùng để lên danh sách ứng viên trong một region:

#!/usr/bin/env bash
# list-graviton-candidates.sh: tìm RDS/Aurora còn chạy x86 và đề xuất class Graviton4
set -euo pipefail
REGION="${1:-us-east-1}"

aws rds describe-db-instances --region "$REGION" \
  --query 'DBInstances[?starts_with(DBInstanceClass, `db.r6`) ||
                       starts_with(DBInstanceClass, `db.m6`) ||
                       starts_with(DBInstanceClass, `db.r7i`) ||
                       starts_with(DBInstanceClass, `db.m7i`)].
           {ID:DBInstanceIdentifier, Class:DBInstanceClass, Engine:Engine, MultiAZ:MultiAZ}' \
  --output table \
  | tee graviton-candidates.txt

echo
echo "Đề xuất: đổi tiền tố r6i/r7i -> r8g và m6i/m7i -> m8g."
echo "Ví dụ: db.r6i.2xlarge -> db.r8g.2xlarge"

Ba cảnh báo trong thực tế: (1) Oracle và SQL Server chưa hỗ trợ Graviton, chỉ có MySQL, PostgreSQL, MariaDB. (2) Nếu bạn dùng extension PostgreSQL biên dịch riêng (pg_partman fork nội bộ, extension C++ tự viết), cần build lại cho ARM64. (3) Reserved Instance mua cho r6i không auto-convert sang r8g. Bạn phải bán RI cũ trên Marketplace hoặc để hết hạn trước khi mua mới cho r8g.

Reserved Instances vs Database Savings Plans: chọn cái nào cho Aurora?

Từ re:Invent 2025, AWS ra mắt Database Savings Plans, cam kết theo $/giờ, áp dụng liên service (Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS), liên family, liên region. Điều này thay đổi tính toán RI vs SP mà tôi đã viết trong bài Savings Plans vs Reserved Instances 2026. Với database, khuyến nghị của tôi giờ là:

Tiêu chí	Reserved Instances (RDS/Aurora)	Database Savings Plans
Chiết khấu tối đa	45% (1 năm), 66% (3 năm)	35% (chỉ 1 năm)
Áp dụng cho	Một engine, một family, size-flexible trong family	Mọi database service, mọi family, mọi region
Đổi family (r6i → r8g)	Không tự áp dụng, phải bán/mua lại	Áp dụng ngay, không cần thao tác
Đổi engine (MySQL → PostgreSQL)	Không áp dụng	Áp dụng
Phù hợp cho	Baseline production ổn định, cam kết 3 năm	Portfolio database đa dạng, đang di trú Graviton hoặc chuyển engine
Rủi ro dư cam kết	Cao, buộc chặt vào family cụ thể	Thấp, trải rộng nhiều service

Chiến lược tôi khuyến nghị: phủ layer. Cam kết RI 3 năm cho baseline production ổn định nhất (thường là 60–70% tải trung bình 90 ngày), rồi phủ Database Savings Plans 1 năm cho phần biến động còn lại và cho các cluster đang có kế hoạch migrate Graviton. Đừng bao giờ commit 100% tải. Luôn để 15–25% chạy on-demand để hấp thụ tăng trưởng và refactor.

Ví dụ cụ thể tôi tính cho một khách hàng SaaS spend 45.000 USD/tháng cho Aurora: baseline ổn định là 28.000 USD/tháng (62%). Phủ 3-year RI No Upfront cho phần đó cắt được 55% = 15.400 USD/tháng. Phần còn lại 17.000 USD phủ Database SP 1-year cắt 30% = 5.100 USD/tháng. Tổng tiết kiệm 20.500 USD/tháng, tức 45,5% bill Aurora, không đụng gì đến code. Xem thêm AWS Cost Management blog để có case study công khai.

Aurora Standard hay I/O-Optimized? Công thức tính điểm hoà vốn

Aurora có hai mô hình lưu trữ. Standard tính 0,10 USD/GB-tháng cộng 0,20 USD/triệu I/O request. I/O-Optimized tính 0,225 USD/GB-tháng, không tính I/O request, và giảm 20% giá compute. Với workload OLTP nặng I/O, I/O-Optimized thường rẻ hơn 20–40% ròng.

Công thức hoà vốn (đơn giản hoá):

# chi_phi_standard  = storage_gb * 0.10 + io_million * 0.20 + compute_hours * price_std
# chi_phi_io_opt    = storage_gb * 0.225 + compute_hours * price_std * 0.80
#
# Điểm hoà vốn: khi (io_million * 0.20) / total_bill > 25%,
# I/O-Optimized rẻ hơn hoặc bằng Standard.

def should_switch_to_io_optimized(storage_gb, io_million, compute_hours, price_std_hour):
    cost_std = storage_gb * 0.10 + io_million * 0.20 + compute_hours * price_std_hour
    cost_io  = storage_gb * 0.225 + compute_hours * price_std_hour * 0.80
    io_share = (io_million * 0.20) / cost_std if cost_std else 0
    return {
        "std_monthly": round(cost_std, 2),
        "io_monthly":  round(cost_io, 2),
        "io_share_pct": round(io_share * 100, 1),
        "recommend": "I/O-Optimized" if cost_io < cost_std else "Standard",
        "monthly_savings": round(cost_std - cost_io, 2),
    }

# Ví dụ: cluster r6g.2xlarge, 500 GB, 800 triệu I/O/tháng, 720 giờ, giá 0.928 USD/giờ
print(should_switch_to_io_optimized(500, 800, 720, 0.928))
# {'std_monthly': 878.16, 'io_monthly': 646.66, 'io_share_pct': 18.2,
#  'recommend': 'I/O-Optimized', 'monthly_savings': 231.5}

Cluster nào có I/O share > 25% chắc chắn nên chuyển. Cluster ở khoảng 15–25% là vùng xám, nhưng thường vẫn có lợi vì compute cũng giảm 20%. Cluster < 10% I/O share (đọc chủ yếu từ buffer pool, ghi ít) nên giữ Standard.

Right-sizing RDS với AWS Compute Optimizer

AWS Compute Optimizer đã hỗ trợ RDS từ 2024 và trong 2026 hoạt động với cả Aurora. Enable ở org level qua Cost Optimization Hub (miễn phí), sau đó tool phân tích CloudWatch metrics và đề xuất downsize/upsize cụ thể. Điểm mấu chốt tôi luôn bật: Enhanced Infrastructure Metrics. Nó kéo dài cửa sổ phân tích từ 14 ngày lên 93 ngày, quan trọng cho workload có chu kỳ tuần/tháng (batch cuối tháng, sale campaign, backup nightly).

Enable qua CLI cho một account:

aws compute-optimizer put-recommendation-preferences \
  --resource-type RdsDBInstance \
  --scope 'name=AccountId,value=123456789012' \
  --enhanced-infrastructure-metrics Active

Sau 14 ngày cửa sổ đủ dữ liệu, kéo khuyến nghị và ưu tiên theo tiết kiệm:

aws compute-optimizer get-rds-database-recommendations \
  --query 'rdsDBRecommendations[?finding==`Overprovisioned`].
           {DB:resourceArn,
            Current:currentDBInstanceClass,
            Suggested:instanceRecommendationOptions[0].dbInstanceClass,
            SavingsUSD:instanceRecommendationOptions[0].savingsOpportunity.
                       estimatedMonthlySavings.value}' \
  --output table

Ba nguyên tắc để không phá production khi làm theo khuyến nghị Compute Optimizer, đúc kết từ những lần tôi bị "cắn" trước đây:

Đừng right-size dựa trên trung bình CPU 30 ngày. DB chạy trung bình 15% CPU có thể bursty 90% trong 15 phút chốt tháng. Xem p95 và p99, không phải trung bình.
Chú ý memory pressure ngầm. Compute Optimizer không thấy buffer cache hit ratio của PostgreSQL. Nếu giảm memory làm cache hit tụt từ 99% xuống 92%, latency tăng 3–5 lần dù CPU vẫn thấp.
Downsize từng bước. r6g.4xlarge → r6g.2xlarge trước, quan sát 2 tuần, rồi mới cân nhắc r6g.xlarge. Nhảy 2 bậc một lần là tự bắn vào chân.

Xem thêm tài liệu chính thức Compute Optimizer cho RDS để biết chi tiết metric mà tool phân tích và giới hạn hiện tại.

Aurora Serverless v2: khi nào dùng, bẫy gì cần tránh

Aurora Serverless v2 tính theo Aurora Capacity Unit (ACU) mỗi giây, tăng giảm mượt từ min tới max mà bạn set. Trong 2024 AWS đã hạ minimum ACU về 0 (auto-pause sau 5 phút không có kết nối), khiến serverless v2 trở nên hấp dẫn thật sự cho môi trường dev/staging và multi-tenant SaaS.

Khi nào nên dùng Serverless v2:

Dev/staging/preview environment: set min = 0, max = 2 ACU. Cluster ngủ ngoài giờ làm việc, tiết kiệm 70–90%.
Multi-tenant SaaS với hàng chục tới hàng trăm cluster nhỏ, phần lớn idle.
Workload spiky khó dự đoán: chat bot, batch cuối tháng, sự kiện marketing.

Khi nào không nên dùng:

OLTP production ổn định: provisioned + RI luôn rẻ hơn 30–50%.
Cluster có sustained load > 8 ACU 24/7: điểm hoà vốn với r6g.large + RI thường quanh 6–8 ACU.
Analytics query dài (> 5 phút): Serverless v2 không auto-scale trong query đang chạy, dễ timeout hoặc chi phí tăng vọt.

Dọn snapshot, Multi-AZ dư và IP không dùng

Đây là phần "housekeeping" thường bị bỏ quên nhưng dễ cắt 5–15% bill trong một buổi chiều. Bốn công việc tôi luôn chạy trong tuần đầu audit:

1. Snapshot cũ quá 90 ngày. Snapshot manual không có TTL, chúng tích tụ vĩnh viễn cho tới khi ai đó xóa. Snapshot tính giá gần bằng storage gốc. Truy vấn kèm CLI:

aws rds describe-db-snapshots --snapshot-type manual \
  --query 'DBSnapshots[?SnapshotCreateTime<=`2026-05-15`].
           {ID:DBSnapshotIdentifier, Size:AllocatedStorage, Created:SnapshotCreateTime}' \
  --output table

Xuất ra spreadsheet, đánh dấu snapshot cần giữ cho compliance (thường 7 ngày cho PITR đã đủ pháp lý ở đa số ngành), xóa phần còn lại. Với một khách hàng gần đây, tôi dọn 12.400 snapshot legacy tổng 42 TB, tiết kiệm 4.100 USD/tháng.

2. Multi-AZ trên môi trường không production. Multi-AZ nhân đôi chi phí instance. Trên dev/staging thường không cần. RTO 30 phút là đủ, khôi phục từ snapshot rẻ hơn nhiều. Áp dụng theo môi trường qua tag env=prod.

3. Read replica không traffic. Query DatabaseConnections và ReadIOPS của replica trong 30 ngày; nếu < 100 kết nối/ngày và < 10 IOPS trung bình thì candidate xóa. Nhiều team tạo replica cho báo cáo cũ đã tắt từ lâu nhưng quên xóa.

4. Elastic IP và storage của DB đã tắt. RDS instance đã stop vẫn tính storage; sau 7 ngày AWS auto-start lại. Bài Tự Động Phát Hiện Và Dọn Dẹp Tài Nguyên Cloud Lãng Phí có script Lambda tôi dùng để scan hàng tuần.

Chặn T-family Unlimited mode: thủ phạm bill 4 con số bất ngờ

Instance db.t3, db.t4g có baseline CPU thấp và hoạt động theo credit. Mặc định RDS bật Unlimited mode: nếu CPU vượt baseline lâu quá số credit tích luỹ, AWS tính thêm 0,09 USD/vCPU-hour. Khoản này không được Reserved Instance bao phủ, không có cap, và không hiện trong Cost Explorer với usage type dễ đoán, mà nằm ở CPUCredits.

Trong một audit gần đây, tôi thấy một cluster db.t4g.medium (2 vCPU) chạy Unlimited mode với average CPU 45% suốt tháng. Baseline t4g.medium là 20%. Chi phí "surprise": 2 vCPU × (45% − 20%) × 720h × 0,09 USD = 32 USD/tháng cho một instance nhỏ, nhưng nhân với 60 replica trong đội hình = 1.920 USD/tháng cho một dòng bill không ai biết là gì.

Hai cách chặn:

# Cách 1: Đổi sang Standard mode, vượt credit thì throttle, không tính thêm phí
aws rds modify-db-instance \
  --db-instance-identifier my-app-db \
  --cpu-credits standard \
  --apply-immediately

# Cách 2: Đổi hẳn sang class không burstable
aws rds modify-db-instance \
  --db-instance-identifier my-app-db \
  --db-instance-class db.m7g.large \
  --apply-immediately

Nếu CPU sustained > baseline thì luôn rẻ hơn khi đổi sang class m/r không burstable. Bạn tránh được cả tính phí bất ngờ lẫn throttle. Nguyên tắc của tôi: T-family chỉ cho dev/staging và cluster thật sự spiky (chạy 5 phút mỗi giờ). Production sustained thì luôn m7g hoặc r8g.

Xem thêm thông báo chính thức về Reserved Instances cho r8g/m8g để biết availability và pricing hiện hành cho region của bạn.

Câu hỏi thường gặp

Aurora có rẻ hơn RDS MySQL/PostgreSQL không?

Không, on-demand Aurora đắt hơn RDS classic khoảng 20% cho cùng instance size vì storage layer khác biệt. Nhưng Aurora thường rẻ hơn tổng cộng vì storage tự tăng theo dữ liệu (không cần overprovision), backup miễn phí tới size cluster, và Aurora I/O-Optimized cắt chi phí cho workload I/O nặng. Với workload đọc nhiều và cần HA, Aurora thường thắng.

Chuyển sang Graviton cho RDS có cần thay đổi ứng dụng không?

Không, với MySQL, PostgreSQL, MariaDB thì engine chạy native trên ARM64, driver JDBC/psycopg2/mysql-connector không cần đổi. Điều duy nhất cần kiểm tra là PostgreSQL extension biên dịch riêng (như pg_partman fork nội bộ hoặc extension C++ tự viết). Bạn phải build lại cho ARM64. Oracle và SQL Server chưa hỗ trợ Graviton.

Database Savings Plans có tốt hơn Reserved Instances không?

Tùy trường hợp. Reserved Instances cho chiết khấu sâu hơn (tới 66% với 3 năm) nhưng khoá bạn vào một engine và family. Database Savings Plans chiết khấu tối đa 35% nhưng áp dụng liên service (RDS, Aurora, DynamoDB, ElastiCache...) và liên family. Chiến lược phổ biến nhất là kết hợp: RI cho baseline production ổn định, SP cho phần biến động và các cluster đang di trú.

Khi nào nên chuyển từ Aurora Standard sang I/O-Optimized?

Khi chi phí I/O request chiếm hơn 25% tổng bill Aurora của cluster (tính riêng cho từng cluster, không phải toàn account). Bạn có thể tính chính xác bằng công thức trong bài. Lưu ý AWS giới hạn chuyển đổi giữa hai mô hình một lần mỗi 30 ngày, nên hãy dùng dữ liệu 90 ngày và test staging trước khi thao tác trên production.

AWS Compute Optimizer cho RDS có miễn phí không?

Có, hoàn toàn miễn phí. Bạn cần enable Compute Optimizer ở org level (khuyến nghị) và bật Cost Optimization Hub để khuyến nghị hiển thị cả tiết kiệm sau chiết khấu RI/SP. Bật thêm Enhanced Infrastructure Metrics (cũng miễn phí) để có cửa sổ phân tích 93 ngày thay vì 14 ngày mặc định.