AWS料金が思ったより高い：原因の調べ方とコスト最適化の優先順位
AWSの請求書を開いたら、先月より明らかに金額が増えている。上司や経営層に「なぜ増えたんですか」と聞かれても、どこを見れば内訳が分かるのか分からない——という状況に覚えがある人は少なくないはずです。かといって「削ってください」と言われた通りに何かを止めて、それが原因でサービスが落ちたら責任は自分に来る。これでは怖くて迂闊に手を出せません。
この記事は、まず「何が高くなっているのか」を自分の目で特定する手順、AWSでよく起きる想定外コストの典型パターン、そして壊すリスクが低いものから順に手を付ける優先順位を整理します。具体的な料金額は変動するため、金額そのものは公式ページ・Cost Explorerで都度確認する前提で読んでください。
TL;DR
- 原因究明はAWS Cost Explorerでサービス別・使用タイプ別に内訳を見ることから始める。タグ別に見たい場合は事前にコスト配分タグの有効化が必要（有効化後の利用分からしか反映されない）
- 想定外コストの典型は、NAT Gatewayの時間課金＋データ処理料金、データ転送（Egress・クロスAZ）、未使用のEBSボリューム／スナップショット、パブリックIPv4アドレスの時間課金（2024年2月以降、未アタッチのElastic IPに限らず課金対象が拡大）の4つ
- 対策は「①今すぐ止められる無駄を止める→②使用量が安定してから予約割引を検討する→③根本的なアーキテクチャを見直す」の順で進めると、壊すリスクを抑えながら効果を出しやすい
まず「何が高いか」をCost Explorerで特定する
金額の増加に気づいたら、感覚や思い込みで犯人を決め打ちしない方が安全です。AWS Cost Explorerは過去の利用実績を可視化する公式ツールで、まずここから内訳を追います。
サービス別・使用タイプ別に見る
Cost Explorerのダッシュボードで期間を指定し、「グループ化の条件」をサービス別に切り替えると、EC2・S3・データ転送などどのサービスが費用を押し上げているかが一覧できます。さらに「使用タイプ（Usage Type）」でグループ化すると、同じEC2でもインスタンス利用料なのか、EBSストレージなのか、データ転送料なのかまで分解できます。NAT Gatewayの費用増加は、サービス別だけだと「VPC」や「EC2-Other」といった分類に埋もれて見えにくいことがあるため、使用タイプまで掘るのがポイントです。
前月・前年同月との比較や、月次の「予測（Forecast）」機能も併用すると、単発の急増なのか、恒常的に増え続けているのかの判断材料になります。
タグ別に見る（事前設定が必要）
プロジェクト別・環境別（本番/検証）にコストを追いたい場合は、リソースに付けたタグをCost Explorerで使えるようにする必要があります。ただしタグは自動的には反映されず、AWS Billing and Cost Managementコンソールの「コスト配分タグ」で該当タグを有効化する作業が要ります。しかも有効化した時点より前の利用分には遡って適用されないため、「タグを付けたのに集計に出てこない」という状況になりがちです。集計させたい軸があるなら、早めに有効化しておくことが前提になります。
「何を見ればいいか分からない」段階への対処
内訳の見方自体が分からず、どこから手を付ければいいか迷う場合は、まず直近1〜2ヶ月分をサービス別に並べて、上位3〜4項目だけを確認するところから始めると全体像がつかみやすくなります。全部を一度に理解しようとせず、金額が大きい順に潰していくだけで、原因の大半は説明できることが多いです。
なお、Cost ExplorerでリソースID単位まで細かく見る「リソースレベル粒度」は追加料金が発生する有料オプションのため、まずは無料範囲のサービス別・タグ別の内訳で十分に原因を絞り込めるか試すのが順序として妥当です。
想定外コストの典型パターン
内訳を見たときに「なぜこんなに」となりやすい代表例を整理します。いずれも実在する課金の仕組みであり、使い方次第で気づかないうちに積み上がります。
| パターン | 課金の仕組み | 気づきにくい理由 |
|---|---|---|
| NAT Gateway | 稼働している時間に対する時間課金＋NAT Gatewayを通過したデータ量に対する処理料金（方向・送信元を問わず発生） | プライベートサブネットのインスタンスがOSアップデート等で外部通信するだけでも積み上がる。開発環境を消し忘れると丸ごと無駄になる |
| データ転送料（Egress・クロスAZ） | インターネットへの送信データ量に応じた従量課金。同一リージョン内でもアベイラビリティゾーンをまたぐ通信は双方向で課金対象になりうる | 「同じAWS内だから無料」という思い込みが根強い。動画・大容量ファイル配信や、複数AZにまたがる構成で顕在化しやすい |
| 未使用のEBSボリューム・スナップショット | インスタンスから切り離された（アタッチされていない）ボリュームも、削除しない限りGB単位の保管料が発生し続ける。スナップショットも同様 | インスタンスを削除してもEBSボリュームやスナップショットは自動では消えない場合がある。検証環境で特に溜まりやすい |
| パブリックIPv4アドレスの時間課金 | 2024年2月以降、稼働中インスタンスに紐づくものも含め、パブリックIPv4アドレス全般に時間単位の課金が発生する仕組みに変更された。未アタッチのElastic IPは従来から課金対象 | 「動いているインスタンスに付いているIPは無料」という以前の認識のまま放置されているケースがある |
上記はいずれも公式の課金体系として実在する仕組みですが、単価そのものはリージョンや時期によって変わるため、現在の料金はAWS公式のVPC料金ページ・EC2料金ページで必ず確認してください。
対策の優先順位：壊さずに削る順番
原因が見えたら、次は「どこから手を付けるか」です。優先順位を間違えると、削った結果サービスが止まって余計に評価を落とすことになりかねません。次の順で進めるのが、リスクを抑えながら効果を出しやすい進め方です。
① まず、今すぐ止められる無駄を止める
- 未アタッチのElastic IP、稼働していないインスタンスに紐づくパブリックIPv4アドレスを解放する
- どのインスタンスにもアタッチされていないEBSボリューム、不要になった古いスナップショットを削除する（削除前にバックアップ方針と照らして本当に不要か確認）
- 使っていない検証環境のNAT Gatewayを削除する、または開発環境は夜間・週末に停止するスケジュールを組む
- Trusted Advisorのコスト最適化チェック（低使用率のEC2・未アタッチEIP・未使用EBS等）が使える契約であれば、そこでも同様の項目を確認する。ただしコスト最適化系の詳細チェックはBusiness/Enterpriseサポートプラン以上が前提になる点は事前に確認が必要
この段階は「動いていないもの・使われていないものを消す」だけなので、稼働中のサービスに影響を与えるリスクが低く、着手のハードルも低いのが利点です。
② 使用量が安定してから予約割引を検討する
無駄を削ったあと、残った使用量が「毎月ほぼ一定」と言える状態になってから検討するのがSavings Plansやリザーブドインスタンス（RI）です。先に無駄を削らずに予約から入ると、実際には不要だった分まで前払いで固定してしまうリスクがあります。
- Savings Plansは時間あたりの利用金額単位でコミットする方式で、インスタンスファミリーやリージョンをまたいでも柔軟に割引が適用されやすい
- リザーブドインスタンスは特定のインスタンスタイプ・リージョンに対する予約で、条件が合えば割引率は高いが柔軟性は下がる
どちらも1年・3年単位のコミットが前提になるため、使用量の予測に自信が持てる範囲から始めるのが無難です。
③ アーキテクチャそのものを見直す
ここまでで解決しない、あるいは効果が頭打ちになった場合は、構成自体の見直しに進みます。
- S3など特定サービスへの通信をNAT Gateway経由ではなくVPCエンドポイント経由に変更し、NAT Gatewayのデータ処理料金を回避する
- 静的コンテンツの配信をCloudFront経由にして、オリジンからの直接転送を減らす
- AWS Compute Optimizer（無料）でEC2・EBS・Lambdaのサイジング推奨を確認し、過剰スペックを是正する
この段階は設計変更を伴うため、検証環境での動作確認とロールバック手順を用意したうえで進める前提になります。
まとめ
AWSの請求額が想定より高いときは、まずCost Explorerでサービス別・使用タイプ別に内訳を見て「何が高いのか」を特定するところから始めます。タグ別に見たい場合は事前の有効化が必要という点、NAT Gateway・データ転送料・未使用のEBSボリューム・パブリックIPv4アドレスの時間課金といった典型パターンが実在の課金の仕組みとして存在する点を押さえておくと、原因の見当がつけやすくなります。
対策は「①今すぐ止められる無駄を止める→②使用量が安定してから予約割引を検討する→③アーキテクチャを見直す」の順に進めることで、稼働中のサービスを壊すリスクを抑えながら費用を圧縮できます。現在の料金・仕様は変動するため、実際の数値判断は必ずAWS公式の料金ページ・Cost Explorerの実データで確認してください。