「AWSの
まず見るべきは「Cost Explorer のサービス別内訳」
削減の
- サービス別 — EC2・RDS・
データ転送・NAT Gateway など、 どの サービスが 上位を 占めているか。 多くの 場合、 上位3サービスで 全体の 7〜8割を 占めます - 月次推移 — 増え続けている
項目は どれか。 一定額で 横ばいの 項目は 固定費化した リソース、 右肩上がりの 項目は データ量や アクセスに 連動する 費用です
この
費用が高くなる7つの典型原因
- 使っていない
EBSボリューム・Elastic IP — インスタンスを削除しても EBSや EIPは 残り、 課金され続けます。 「available」 状態の EBSと、 どこにも 関連 付いていない EIPは 真っ先に 確認すべき 項目です - 過剰スペックの
インスタンス — CPU使用率が常時10%未満の EC2や RDSは 1〜2サイズ下げられる 可能性が 高いです。 CloudWatchで 直近1か月の 使用率を 見て 判断します - NAT Gatewayの
転送料 — NAT Gatewayは時間課金に 加えて 処理データ量にも 課金されます。 プライベートサブネットから S3へ 大量アクセスしている 構成では、 VPCエンドポイント経由に 変えるだけで 転送料を 大きく 削れます - 旧世代インスタンスの
継続利用 — 同等性能の新世代 （例：t2→t3以降、 m4→m5以降）へ 変更するだけで 単価が 下がる ケースが 多く あります - スナップショット・AMIの
堆積 —自動バックアップの 世代管理を していないと、 数年分の スナップショットが 溜まります。 保持世代数を 決めて 古い ものを 整理します - 開発・検証環境の
24時間稼働 — 業務時間しか使わない 環境を 夜間・ 休日も 動かしている ケース。 平日日中のみの 稼働に すれば、 稼働時間は 約1/3に なります - S3の
ストレージクラス未設定 — アクセス頻度が下がった データが 標準クラスの まま 残っている 状態です。 ライフサイクルルールで 低頻度アクセスや アーカイブ系の クラスへ 自動移行させます
削減を進める実務ステップ
| ステップ | やる | リスク |
|---|---|---|
| 1. 棚卸し | Cost Explorerと | なし |
| 2. 未使用リソースの | 未接続EBS/EIP・古い | 低 |
| 3. 稼働時間の | 開発環境の | 低 |
| 4. サイズ・世代の | 使用率の | 中 |
| 5. 構成の | VPCエンドポイント・S3ライフサイクル等 | 中 |
| 6. 長期割引の | RI / Savings Plans の | 中 |
着手はリスクの
RI・Savings Plansは「最後」に検討する
リザーブドインスタンス
- サイズ見直しの
前に — 過剰スペックの買わない まま 長期契約すると、 無駄を 固定化する ことになります。 必ずステップ4・5の 後に 検討します - 全量を
カバーしようとしない — 常時稼働が確実な ベース部分だけを 対象にし、 変動分は オンデマンドの まま 残すのが 安全です - 構成変更の
予定を — 1年以内に確認する コンテナ化や 構成刷新の 計画が あるなら、 柔軟性の 高い Savings Plansを 選ぶか、 購入自体を 見送る 判断も あります
再発を防ぐ仕組み｜予算アラートとタグ付け
一度
- AWS Budgetsでの
予算アラート — 月額の予算を 設定し、 実績や 予測が 一定割合 （例：80%・100%）を 超えたら メール通知させます。 設定は 数分で 終わり、 追加費用も ほぼかかりません。 「請求書が 届いて 初めて 気づく」状態を 防ぐ 最低限の 保険です - リソースへの
タグ付けルール —「プロジェクト名」 「環境 （本番/開発）」 「作成者」の タグを 必須に しておくと、 Cost Explorerで タグ別に 集計でき、 「誰も 持ち主が 分からない リソース」の 発生を 防げます。 既存リソースへの 後付けは 大変なので、 ルールだけでも 早めに 決めて おく 価値が あります
加えて、
まとめ｜削減は一度きりではなく「見える化の習慣」
AWSの