AWSのデータベースコストを見直すときに確認する項目

この文書の適用条件

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

# 対象: 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

結果の読み方

こういう状況で使います

• AWSの請求額が増え続けているが、どの項目が増えたのか分からない
• 構築時に決めたインスタンスクラスとストレージ設定を、その後一度も見直していない
• どこにもアタッチされていないEBSボリュームや、目的の分からないスナップショットが残っている
• 開発環境・検証環境が24時間稼働している
• Provisioned IOPSを設定しているが、実際に使い切っているか確認していない
• リザーブドインスタンスやSavings Plansを勧められたが、判断材料がない

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

1. 01

   構築時の見積もりのまま運用されている

   インスタンスクラスとストレージのプロビジョニング量は、多くの場合サービス開始前に「余裕を持って」決められます。稼働後の実測に照らして見直す運用が組まれていないと、その値がそのまま残ります。

2. 02

   孤立したリソースが課金され続けている

   インスタンス削除時に残ったEBSボリューム、移行作業で取った手動スナップショット、検証で作って使わなくなったリードレプリカは、いずれも明示的に削除するまで課金対象です。使っていないことが請求書からは分かりにくい種類の費用です。

3. 03

   ストレージ種別が古い世代のまま

   gp2はボリュームサイズに基線性能が連動し、バーストはI/Oクレジットに依存します。gp3は基線性能とスループットを容量と切り離して設定できます。gp2のまま運用されているボリュームは、性能要件と費用の両面で見直し候補になります。適用可否と条件は現行のAWSドキュメントで確認してください。

4. 04

   Provisioned IOPSが消費されていない

   io1/io2やgp3の追加IOPSは、消費の有無にかかわらずプロビジョニング量で課金されます。CloudWatchの実測が恒常的に設定値を下回っている場合、費用だけが発生しています。

5. 05

   非本番環境が本番と同じ構成になっている

   開発・検証環境でMulti-AZが有効、本番と同じインスタンスクラス、24時間稼働、という構成は珍しくありません。可用性要件が本番と異なるなら、構成も分けられます。

6. 06

   データ転送費用が見えていない

   アプリケーションとデータベースが別AZにある場合、クロスAZのデータ転送費用が継続的に発生します。単価は小さくても、トラフィック量が多い構成では無視できない規模になることがあります。

確認手順

1. 1

   Cost Explorerでコスト内訳を出す

   参照のみ

   サービス別・使用タイプ別に月次で出し、金額の大きい順に着手対象を決めます。ここを飛ばすと施策の優先順位が付きません。

2. 2

   停止中・未使用のインスタンスを洗い出す

   参照のみ

   `aws rds describe-db-instances` の `DBInstanceStatus` と、接続数（DatabaseConnections）が長期間ゼロのインスタンスを突き合わせます。

3. 3

   孤立リソースを一覧化する

   参照のみ

   `status=available` のEBSボリューム、手動スナップショット、使われていないリードレプリカを一覧にし、所有者を確認します。

4. 4

   実測とプロビジョニング値を突き合わせる

   参照のみ

   CloudWatchのCPUUtilization・FreeableMemory・ReadIOPS・WriteIOPSを、設定されたインスタンスクラスとIOPSと比較します。

5. 5

   バックアップ保持設定を確認する

   参照のみ

   自動バックアップ保持日数が要件に対して過大でないか、手動スナップショットが何年分残っているかを確認します。

6. 6

   非本番環境の構成を確認する

   参照のみ

   開発・検証環境のMulti-AZ設定、インスタンスクラス、稼働時間帯を確認します。

7. 7

   AWS Budgetsで監視を設定する

   低

   見直し後の効果を追うため、予算としきい値通知を設定します。単発の削減ではなく継続的な監視にします。

対応方法

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

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

• 費用が減らない場合、内訳のどこが動いていないかを確認する

  インスタンス費用を下げてもストレージ費用やデータ転送費用が支配的なら総額は動きません。Cost Explorerの使用タイプ別内訳に戻ってください。

• タグ付けの網羅性を確認する

  コスト配分タグが付いていないリソースは、どの部署・どのシステムの費用か判別できません。棚卸しの前提としてタグ運用を整えます。

• Cost and Usage Reportで詳細を確認する

  Cost Explorerの粒度で足りない場合、Cost and Usage Report（CUR）をS3に出力し、リソース単位で分析します。

• 削除できないリソースの依存関係を確認する

  スナップショットがAMIから参照されている、ボリュームが復旧手順書に記載されている、といった依存がないかを確認します。

• 同じ増加が再発しない仕組みを作る

  一度の棚卸しで下がっても、同じ経路で再び増えます。作成時のタグ必須化と定期棚卸しをセットにしてください。

この文書の根拠と限界

よくある質問

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

• AWSの請求額が増えた原因を特定したい
• RDSのコストを下げる方法が知りたい
• 使っていないEBSボリュームやスナップショットを見つけたい
• 開発環境のAWS費用を減らしたい

リスク表示の意味

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

GIIPの対応範囲

コスト見直しの難しさは、施策を知らないことではなく、棚卸しが一度きりで終わることにあります。整理した3か月後には新しい未使用ボリュームとスナップショットが積み上がり、right-sizingした構成は業務量の変化で再びずれます。GIIPではAWSとAzure上の複数データベースおよび約30のWebサービスについて、孤立リソースの検出とプロビジョニング値対実測値の乖離チェックをAIエージェントが定期的に実行し、削除や構成変更のように取り返しのつかない判断は人間の専門家が承認する形で運用しています。棚卸しをイベントではなく定常業務にすることが目的です。

関連サービス

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