「AWSの請求額が毎月じわじわ増えている」「そもそも何にいくら払っているのか分からない」——この状態は珍しくありません。AWSは使った分だけ課金される仕組みのため、使っていないのに残っているリソースが静かに費用を積み上げます。本記事では、まず見るべき請求項目と、費用が高くなる典型的な7つの原因、削減の実務手順を解説します。
まず見るべきは「Cost Explorer のサービス別内訳」
削減の第一歩は犯人探しです。AWSマネジメントコンソールの Cost Explorer を開き、次の2つの切り口で直近3か月を見てください。
- サービス別 — 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 の購入 | 中（後述） |
ポイントはリスクの低い順に着手することです。未使用リソースの削除と夜間停止だけでも、全体の1〜2割程度の削減につながるケースはよくあります。
RI・Savings Plansは「最後」に検討する
リザーブドインスタンス（RI）やSavings Plansは、1〜3年の利用継続を約束する代わりに割引を受ける仕組みで、うまく使えば大きな削減になります。ただし注意点があります。
- サイズ見直しの前に買わない — 過剰スペックのまま長期契約すると、無駄を固定化することになります。必ずステップ4・5の後に検討します
- 全量をカバーしようとしない — 常時稼働が確実なベース部分だけを対象にし、変動分はオンデマンドのまま残すのが安全です
- 構成変更の予定を確認する — 1年以内にコンテナ化や構成刷新の計画があるなら、柔軟性の高いSavings Plansを選ぶか、購入自体を見送る判断もあります
再発を防ぐ仕組み｜予算アラートとタグ付け
一度削減しても、対策なしでは数か月で元に戻ります。再発防止として効果が高いのは次の2つです。
- AWS Budgetsでの予算アラート — 月額の予算を設定し、実績や予測が一定割合（例：80%・100%）を超えたらメール通知させます。設定は数分で終わり、追加費用もほぼかかりません。「請求書が届いて初めて気づく」状態を防ぐ最低限の保険です
- リソースへのタグ付けルール — 「プロジェクト名」「環境（本番/開発）」「作成者」のタグを必須にしておくと、Cost Explorerでタグ別に集計でき、「誰も持ち主が分からないリソース」の発生を防げます。既存リソースへの後付けは大変なので、ルールだけでも早めに決めておく価値があります
加えて、月に一度15分だけ「サービス別内訳を前月と見比べる」時間を定例化すると、異常な増加に早く気づけます。
まとめ｜削減は一度きりではなく「見える化の習慣」
AWSの費用削減は、一度の大掃除よりも「毎月サービス別内訳を眺める習慣」のほうが効きます。無駄は必ず再発するからです。シャノンではAWS環境の構築・運用を請け負っており、コスト診断では請求データの分析から削減施策の実施、その後の継続的なモニタリングまで対応しています。「請求額の内訳がそもそも分からない」という段階からでもご相談いただけます。