What to Check When Reviewing AWS Database Costs

この文書の適用条件

そのまま実行できるコマンド

# 対象: AWS Cost Explorer API（AWS CLI v2）
# 権限: ce:GetCostAndUsage
# 変更作業: なし（参照のみ）
# Production 実行: 可能
aws ce get-cost-and-usage \
  --time-period Start=2026-05-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost UsageQuantity \
  --group-by Type=DIMENSION,Key=SERVICE \
  --output json

# 対象: Amazon EC2 / Amazon EBS（AWS CLI v2）
# 権限: ec2:DescribeVolumes
# 変更作業: なし（参照のみ）
# Production 実行: 可能
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query "Volumes[].{Id:VolumeId,Type:VolumeType,SizeGiB:Size,Iops:Iops,\
Throughput:Throughput,AZ:AvailabilityZone,Created:CreateTime,Name:Tags[?Key=='Name']|[0].Value}" \
  --output table

# 対象: Amazon RDS / Amazon EBS（AWS CLI v2）
# 権限: rds:DescribeDBSnapshots, ec2:DescribeSnapshots
# 変更作業: なし（参照のみ）
# Production 実行: 可能

# 手動作成された RDS スナップショット（自動バックアップは snapshot-type=automated）
aws rds describe-db-snapshots \
  --snapshot-type manual \
  --query "DBSnapshots[].{Id:DBSnapshotIdentifier,Source:DBInstanceIdentifier,\
Created:SnapshotCreateTime,SizeGiB:AllocatedStorage,Engine:Engine}" \
  --output table

# 自アカウント所有の EBS スナップショット（作成日の古い順）
aws ec2 describe-snapshots \
  --owner-ids self \
  --query "sort_by(Snapshots,&StartTime)[].{Id:SnapshotId,Volume:VolumeId,\
Started:StartTime,SizeGiB:VolumeSize,Desc:Description}" \
  --output table

# 対象: Amazon RDS（AWS CLI v2）
# 権限: rds:DescribeDBInstances
# 変更作業: なし（参照のみ）
# Production 実行: 可能
aws rds describe-db-instances \
  --query "DBInstances[].{Id:DBInstanceIdentifier,Class:DBInstanceClass,\
StorageType:StorageType,AllocatedGiB:AllocatedStorage,Iops:Iops,\
StorageThroughput:StorageThroughput,MultiAZ:MultiAZ,\
BackupRetentionDays:BackupRetentionPeriod,Status:DBInstanceStatus}" \
  --output table

# 対象: Amazon EC2 / Amazon EBS / Amazon RDS（AWS CLI v2）
# 権限: ec2:DeleteVolume, ec2:DeleteSnapshot, rds:DeleteDBSnapshot
# 変更作業: あり（削除操作。実行後に元へ戻すことはできない）
# Production 実行: 一覧の全件確認と所有者承認を得てから、1件ずつ実行すること
#
# 注意: 以下は「一括で流すスクリプト」ではなく、1件ごとに判断した結果を実行する形を想定しています。
#       まず削除候補ボリュームのスナップショットを取り、復旧経路を確保してから削除します。
aws ec2 create-snapshot \
  --volume-id vol-0123456789abcdef0 \
  --description "pre-delete backup of vol-0123456789abcdef0"

# スナップショットの完了を確認したうえで削除する
aws ec2 delete-volume --volume-id vol-0123456789abcdef0

結果の読み方

こういう状況で使います

• The AWS bill keeps climbing, but it's unclear which item grew
• The instance class and storage settings decided at build time have never been reviewed since
• EBS volumes attached to nothing, or snapshots with an unclear purpose, remain
• Dev and test environments run 24/7
• Provisioned IOPS is configured, but whether it's actually being fully used has never been checked
• Reserved Instances or Savings Plans were recommended, but there is no basis to decide

考えられる原因（可能性の高い順）

1. 01

   Still running on the estimates from when it was built

   Instance class and storage provisioning are often decided "with margin" before a service launches. Without a process for reviewing them against actual usage after launch, those original values just stay in place.

2. 02

   Orphaned resources keep getting billed

   An EBS volume left over from deleting an instance, a manual snapshot taken during a migration, or a read replica created for testing and then abandoned — all of these are billed until explicitly deleted. This is the kind of cost that's hard to spot as "unused" from the bill alone.

3. 03

   Storage type is still on an older generation

   gp2's baseline performance is tied to volume size, with bursts drawing on I/O credits. gp3 lets you set baseline performance and throughput independently of capacity. A volume still on gp2 is a candidate for review on both performance-fit and cost. Check current AWS documentation for eligibility and terms.

4. 04

   Provisioned IOPS is not being consumed

   Extra IOPS on io1/io2 or gp3 is billed by the provisioned amount regardless of consumption. If CloudWatch measurements are consistently below the configured value, you are only paying for it.

5. 05

   Non-production is configured the same as production

   It's not unusual for a dev or test environment to have Multi-AZ enabled, the same instance class as production, and to run 24/7. If availability requirements differ from production, the configuration can be separated too.

6. 06

   Data transfer cost is going unnoticed

   When the application and database sit in different AZs, cross-AZ data transfer cost accrues continuously. The per-unit rate is small, but it can add up to a non-negligible amount in a high-traffic configuration.

確認手順

1. 1

   Pull the cost breakdown from Cost Explorer

   参照のみ

   Break it down by service and usage type on a monthly basis, and prioritize by dollar amount. Skipping this step leaves you with no way to prioritize.

2. 2

   Identify stopped and unused instances

   参照のみ

   Cross-check `DBInstanceStatus` from `aws rds describe-db-instances` against instances with a DatabaseConnections count of zero for a long period.

3. 3

   List orphaned resources

   参照のみ

   List EBS volumes in `status=available`, manual snapshots, and unused read replicas, and identify their owners.

4. 4

   Cross-check measured values against provisioned values

   参照のみ

   Compare CloudWatch's CPUUtilization, FreeableMemory, ReadIOPS, and WriteIOPS against the configured instance class and IOPS.

5. 5

   Check backup retention settings

   参照のみ

   Check whether the automated backup retention period is excessive relative to requirements, and how many years of manual snapshots remain.

6. 6

   Check the non-production configuration

   参照のみ

   Check the Multi-AZ setting, instance class, and operating hours of dev/test environments.

7. 7

   Set up monitoring with AWS Budgets

   低

   Set a budget and threshold alert to track the effect of the review going forward. Make this ongoing monitoring rather than a one-time reduction.

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• If cost isn't dropping, check which part of the breakdown isn't moving

  If storage cost or data transfer cost dominates, lowering instance cost won't move the total. Go back to Cost Explorer's breakdown by usage type.

• Check the completeness of tagging

  A resource without a cost-allocation tag can't be attributed to a department or system. Get tagging practice in order as a prerequisite for the inventory.

• Check details with the Cost and Usage Report

  If Cost Explorer's granularity isn't enough, export the Cost and Usage Report (CUR) to S3 and analyze it at the resource level.

• Check dependencies for resources that cannot be deleted

  Check for dependencies such as a snapshot referenced by an AMI, or a volume documented in a recovery runbook.

• Build a mechanism to prevent the same growth from recurring

  Even if one inventory pass brings things down, the same path will cause growth again. Pair mandatory tagging at creation time with a periodic inventory.

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• Want to identify why the AWS bill increased
• Want to know how to lower RDS costs
• Want to find unused EBS volumes or snapshots
• Want to reduce AWS cost for a development environment

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

The difficulty in reviewing cost isn't not knowing what actions to take — it's that the inventory happens only once. Three months after a cleanup, new unused volumes and snapshots pile up again, and a right-sized configuration drifts again as business volume changes. At GIIP, an AI agent periodically detects orphaned resources and checks for gaps between provisioned and measured values across several databases on AWS and Azure and roughly 30 web services, while an irreversible decision such as deletion or a configuration change is approved by a human specialist. The goal is to make inventory an ongoing routine rather than a one-off event.

関連サービス

• クラウドコスト最適化
• 開発・検証・本番環境の構成を確認する
• AWSマネージド運用の範囲を確認する