从 Aurora Serverless v2 Scale-to-Zero、DynamoDB 预置 vs 按需、gp3 存储迁移到 Cosmos DB Autoscale 与 Cloud SQL CUD，实测把云数据库月账单砍掉 35%–60% 的实战方案。
更新日期：2026年9月16日
云数据库成本优化的关键，是按实际负载模式选对定价模型。突发型工作负载适合 Aurora Serverless v2 或 DynamoDB 按需（On-Demand），稳定型基线负载则用 RDS 预留实例（RI）叠加 gp3 存储，全球多写场景交给 Cosmos DB 自动缩放的 RU/s 上限。到了 2026 年，AWS RDS、Azure SQL、GCP Cloud SQL 都已支持更细粒度的计费单位（Aurora ACU 步进细化到 0.5，Cosmos DB 自动缩放最小单位降到 100 RU/s），配合右调（Right-sizing）、快照生命周期与只读副本策略，典型企业能把云数据库月账单砍掉 35%–60%。这篇实战指南会拆开五大主流托管数据库的省钱杠杆，附上可以直接跑的 CLI 与 IaC 代码。
动手优化之前，得先看懂账单。托管数据库服务（RDS、Aurora、DynamoDB、Cosmos DB、Cloud SQL）通常把成本拆成四块：计算容量（vCPU/内存或 ACU/RU/s）、存储容量（gp3、Premium SSD、Standard/SSD）、IOPS 与吞吐量（在 gp3、io2 或高性能层单独计费），还有数据传输（跨 AZ 复制、跨区域读副本、公网出口）。多数企业只盯着第一项，却把后三项漏掉了。说实话，IOPS 与快照往往占 25% 以上账单。
2026 年有个关键变化。AWS 在 AWS What's New 频道宣布 RDS 与 Aurora 全面支持 Graviton4（R8g、M8g 系列），单实例性价比比 Intel R7i 提升约 40%。Azure 也推出了 Cobalt 100 系列 ARM 计算，Cloud SQL 支持了 T2A 与 C4A。把老实例迁到 ARM，是当前性价比最高的一步单动作优化。
说个我自己踩过的坑：上一个电商项目里第一次直接切生产，结果 P99 延迟涨了 3 倍。后来发现是老驱动版本对 ARM 的连接池行为不一致。所以生产切换，一定要先在 Staging 跑至少 24 小时。
RDS 与 Aurora 的省钱路径完全不同。RDS 走的是"预留实例 + gp3 存储 + Multi-AZ 谨慎使用"；Aurora 则围绕"Serverless v2 + I/O-Optimized 存储层 + Aurora Global Database 按需读扩展"。到 2026 年，Aurora Serverless v2 新增了 Scale-to-Zero 能力：闲置超过 5 分钟就缩容到 0 ACU，只按存储与 I/O 计费。这个特性对开发、预发、CI 数据库特别友好。
下面是把现有 RDS gp2 卷迁移到 gp3 的一键脚本（不中断服务）。
# 1. 查询当前 gp2 卷的 IOPS 与吞吐基线
aws cloudwatch get-metric-statistics \
--namespace AWS/RDS \
--metric-name ReadIOPS \
--dimensions Name=DBInstanceIdentifier,Value=prod-orders-01 \
--start-time 2026-09-01T00:00:00Z \
--end-time 2026-09-15T00:00:00Z \
--period 3600 \
--statistics Maximum p95
# 2. 应用 gp3 变更（IOPS 3000 免费基线，超出按 $0.005/IOPS/月）
aws rds modify-db-instance \
--db-instance-identifier prod-orders-01 \
--storage-type gp3 \
--iops 4000 \
--storage-throughput 250 \
--apply-immediately
# 3. 观察切换进度（约 30 分钟，无停机）
aws rds describe-db-instances \
--db-instance-identifier prod-orders-01 \
--query 'DBInstances[0].[StorageType,Iops,StorageThroughput,DBInstanceStatus]'
Aurora 这边，2026 年推荐用 Aurora I/O-Optimized 集群配置。存储与实例成本略高（约 30%），但 I/O 完全免费。经验法则：如果 I/O 成本占集群账单 25% 以上，切到 I/O-Optimized 一定省钱。切换命令：
aws rds modify-db-cluster \
--db-cluster-identifier prod-cluster \
--storage-type aurora-iopt1 \
--apply-immediately
如果你正在评估要不要用 Reserved Instances 锁定 RDS 费用，可以看看我们的AWS Savings Plans 与 Reserved Instances 完整对比。RDS RI 仍然是折扣最深的选择（3 年全预付高达 69%），而 EC2 类工作负载通常用 Compute Savings Plans 更灵活。
DynamoDB 按需（On-Demand）比预置容量 + Auto Scaling 平均贵 6 倍。这是 AWS 官方定价页公开的比率。按需的优势是零管理、瞬间弹性扩容，适合突发或未知流量。判断标准其实很简单：如果表的 P95/P50 请求比小于 4（即峰值不超过均值的 4 倍），预置模式加自动伸缩就是明确赢家；反之按需更划算。
下面用 Python + boto3 计算一张表 30 天的 P95/P50 比。
import boto3
from datetime import datetime, timedelta
import numpy as np
cw = boto3.client('cloudwatch', region_name='us-east-1')
end = datetime.utcnow()
start = end - timedelta(days=30)
resp = cw.get_metric_statistics(
Namespace='AWS/DynamoDB',
MetricName='ConsumedReadCapacityUnits',
Dimensions=[{'Name': 'TableName', 'Value': 'orders'}],
StartTime=start,
EndTime=end,
Period=300, # 5 分钟粒度
Statistics=['Sum']
)
values = [d['Sum'] / 300 for d in resp['Datapoints']] # 转 RCU/s
p50, p95 = np.percentile(values, [50, 95])
print(f"P50={p50:.0f} RCU/s, P95={p95:.0f} RCU/s, ratio={p95/p50:.1f}x")
# ratio < 4 → 预置 + 自动伸缩；ratio ≥ 4 → 按需
如果选预置模式，务必把自动伸缩的目标利用率配成 70%（默认 70% 是甜蜜点，太低浪费容量，太高突发流量会被节流）。用 Terraform 定义：
resource "aws_appautoscaling_target" "dynamodb_read" {
max_capacity = 4000
min_capacity = 20
resource_id = "table/orders"
scalable_dimension = "dynamodb:table:ReadCapacityUnits"
service_namespace = "dynamodb"
}
resource "aws_appautoscaling_policy" "dynamodb_read_policy" {
name = "dynamodb-read-target-70"
policy_type = "TargetTrackingScaling"
resource_id = aws_appautoscaling_target.dynamodb_read.resource_id
scalable_dimension = aws_appautoscaling_target.dynamodb_read.scalable_dimension
service_namespace = aws_appautoscaling_target.dynamodb_read.service_namespace
target_tracking_scaling_policy_configuration {
predefined_metric_specification {
predefined_metric_type = "DynamoDBReadCapacityUtilization"
}
target_value = 70
scale_in_cooldown = 60
scale_out_cooldown = 60
}
}
Cosmos DB 的成本几乎完全由 RU/s（请求单元/秒）决定。三种定价模式：Provisioned（手动预置）、Autoscale（自动缩放，10%–100% 弹性）、Serverless（按次计费）。2026 年官方推荐的默认选项是 Autoscale，它按每小时最大消耗的 RU/s 计费（起价为设定上限的 10%），比 Provisioned 便宜 40%–70%，前提是你的峰谷比大于 1.5x。
用 Azure CLI 把已有集合切到 Autoscale，并设置合理上限：
# 查询过去 7 天消耗的 P95 RU/s，作为 Autoscale 上限参考
az monitor metrics list \
--resource /subscriptions/<sub>/resourceGroups/rg-prod/providers/Microsoft.DocumentDB/databaseAccounts/cosmos-orders \
--metric TotalRequestUnits \
--interval PT1H \
--start-time 2026-09-08T00:00:00Z \
--aggregation Maximum
# 切换到 Autoscale（上限 4000 RU/s，最低会按 400 RU/s 计费）
az cosmosdb sql container throughput migrate \
--account-name cosmos-orders \
--resource-group rg-prod \
--database-name shop \
--name orders \
--throughput-type autoscale
az cosmosdb sql container throughput update \
--account-name cosmos-orders \
--resource-group rg-prod \
--database-name shop \
--name orders \
--max-throughput 4000
Azure SQL 数据库的核心杠杆，是 Azure Hybrid Benefit + 3 年预留容量组合。如果你已经有本地 SQL Server 授权，Hybrid Benefit 可以减免高达 55% 的 vCore 成本，叠加预留能到 82% 总折扣。此外，vCore 通用型 Gen5 迁到 Standard-series（Cobalt 100 ARM）在 2026 年成本再降 15%。
GCP Cloud SQL（支持 MySQL、PostgreSQL、SQL Server）的成本优化围绕四点展开：承诺使用折扣（CUD）、Enterprise Plus 版本的性能弹性、只读副本策略，以及 Cloud SQL Insights 的自动索引建议。2026 年 GCP 更新了 Cloud SQL 3 年期 CUD，最高提供 52% vCPU + 内存折扣，而且没有实例族锁定。也就是说，迁移到新一代机器不会让承诺失效。
用 gcloud 创建承诺购买（覆盖某地区的所有 Cloud SQL 计算容量）：
gcloud beta billing accounts commitments create \
--billing-account=01ABCD-234567-EF8901 \
--plan=THIRTY_SIX_MONTH \
--region=us-central1 \
--resources=vcpu=8,memory=32GB \
--service=sql
Spanner 这边，2026 年的省钱新玩法是 Granular Instance Sizing：处理单元（PU）粒度从 100 降到 25，起步成本从每月约 $65 降到 $16 左右，让小规模应用也能承受 Spanner 的强一致性。此外 Spanner 现在原生支持 PostgreSQL 方言，迁移成本大幅下降。
如果你的负载横跨多个云厂商，参考我们的多云 Spot 实例对比指南可以搭配数据库预留优化：无状态计算层放到 Spot、有状态数据库层用 RI/CUD，实现整体最低 TCO。
快照和自动备份，是最容易被低估的成本项。RDS 自动备份保留期从默认 7 天延长到 35 天，看起来只是配置项一改，实际上会让备份存储量翻 5 倍。原因是增量快照包含所有变更块。对于写密集数据库（订单表、日志表），35 天保留可能让备份存储成本超过实例本身。
推荐的分层备份策略：
用 AWS Backup 生命周期规则一键实施：
{
"BackupPlanName": "rds-tiered-retention",
"Rules": [{
"RuleName": "daily-hot-7d",
"TargetBackupVaultName": "Default",
"ScheduleExpression": "cron(0 5 ? * * *)",
"Lifecycle": {
"DeleteAfterDays": 7
}
}, {
"RuleName": "monthly-cold-1y",
"TargetBackupVaultName": "Default",
"ScheduleExpression": "cron(0 5 1 * ? *)",
"Lifecycle": {
"MoveToColdStorageAfterDays": 30,
"DeleteAfterDays": 365
}
}]
}
右调是持续动作，不是一次性优化。我通常建议每月执行一次数据库右调工作流：
如果你已经在用 AWS Compute Optimizer，2026 年它已经扩展到 RDS，覆盖 MySQL、PostgreSQL 引擎的实例推荐。详情看我们的AWS Compute Optimizer 实战指南。对 Aurora，可以拿官方 Aurora PostgreSQL 调优白皮书当作规范化的检查清单。
手动优化不可持续。健康的 FinOps 团队会把数据库成本纳入自动化告警与预算门禁：
Environment、Team、CostCenter 标签。通过 SCP（AWS）、Azure Policy、GCP Organization Policy 拒绝未打标签的创建请求下面是一个 Lambda 示例，每周扫描 7 天无连接的 RDS 实例并发通知：
import boto3, json, urllib.request, os
from datetime import datetime, timedelta
def lambda_handler(event, context):
rds = boto3.client('rds')
cw = boto3.client('cloudwatch')
idle = []
for db in rds.describe_db_instances()['DBInstances']:
end = datetime.utcnow()
start = end - timedelta(days=7)
r = cw.get_metric_statistics(
Namespace='AWS/RDS',
MetricName='DatabaseConnections',
Dimensions=[{'Name': 'DBInstanceIdentifier', 'Value': db['DBInstanceIdentifier']}],
StartTime=start, EndTime=end,
Period=86400, Statistics=['Maximum']
)
max_conn = max((d['Maximum'] for d in r['Datapoints']), default=0)
if max_conn == 0:
idle.append(db['DBInstanceIdentifier'])
if idle:
payload = {'text': f'*闲置 RDS 实例（7 天无连接）*\n' + '\n'.join(f'• {n}' for n in idle)}
req = urllib.request.Request(
os.environ['SLACK_WEBHOOK'],
data=json.dumps(payload).encode(),
headers={'Content-Type': 'application/json'}
)
urllib.request.urlopen(req)
return {'idle_count': len(idle)}
要把数据库成本可视化到组织维度，再叠加云成本标签与成本分摊策略，才能真正回答"哪个团队/产品/客户占了多少数据库账单"这个 FinOps 核心问题。
要看负载模式。对于突发或间歇性负载（比如日间高峰、测试环境），Aurora Serverless v2 借助 Scale-to-Zero 与 0.5 ACU 步进能省 40%–70%；但对 7×24 稳定负载，同规格 Aurora Provisioned + 3 年 RI 比 Serverless v2 便宜约 20%。经验值：日均利用率低于 50% 选 Serverless，50% 以上选 Provisioned。
关键看 P95/P50 请求比。比值小于 4x，预置加自动伸缩（目标利用率 70%）平均便宜 6 倍；比值大于 4x 或流量完全不可预测，选按需。切换后每 24 小时只能改一次，切换前务必先跑 30 天指标验证。
在 2026 年，gp3 几乎总是更便宜。每 GB 单价低约 20%，而且免费提供 3000 IOPS 与 125 MB/s 吞吐基线（gp2 需要按 GB 提供比例 IOPS）。只有当卷小于 400 GB 且 IOPS 需求大于 12000 时，gp3 才可能比 gp2 贵。默认全部迁 gp3。
把 Autoscale 最大 RU/s 设为过去 30 天 P95 消耗的 1.1–1.3 倍。计费按每小时实际消耗的最大值收取，最低只收 max 的 10%，比手动 Provisioned 平均省 40%–70%。如果使用量长期贴近上限，可以考虑降级到手动 Provisioned + 承诺容量。
推荐分层：自动备份 7 天（应对误删）、月度手动快照转 Cold Storage 保留 1 年（应对合规审计）、Glacier Deep Archive 保留 7 年（长期归档）。避免默认 35 天自动备份，它会让写密集库的备份成本超过实例本身。
对于托管数据库服务（RDS、Aurora、ElastiCache）完全无需改代码。引擎是 AWS 提供的 ARM 编译版本，SQL 协议与客户端驱动完全一致。只需在控制台切换实例族并做一次故障切换即可，性价比通常提升 40%。
深入对比 AWS EC2 Spot、Azure Spot VMs、GCP Spot VMs 三家云的中断窗口、竞价机制与 Kubernetes 集成路径，含 Karpenter 配置、跨云 FOCUS 1.2 归因 SQL 与真实成本节省案例。
AWS Compute Optimizer 是完全免费的 ML 分析服务，为 EC2、EBS、Lambda、ASG、Fargate、RDS 输出右调建议。本文基于 200+ 生产账户实战，讲透启用、建议解读、Graviton4 迁移、Enhanced Metrics 决策与自动化落地流水线，帮你 30 天平均省 25-40% 云成本。
把Snowflake、BigQuery、Redshift的年度账单砍掉40-70%？三管齐下：Snowflake虚拟仓库激进auto-suspend、BigQuery Editions槽预留、Redshift RA3或Serverless。附2026最新定价机制、告警规则、右调SQL与FinOps治理清单，含多个真实客户案例总结。