セキュリティサービス部 佐竹です。
本日は、2025年11月26日に発表された AWS Compute Optimizer の「Idle resource recommendations for NAT Gateways」について解説します。今回のアップデートにより削除を忘れがちな未使用状態の NAT Gateway を検出可能となりました。
- はじめに
- AWS Compute Optimizer と最近のアップデート
- どのようにして未使用 NAT Gateway と判定されるのか
- Cost Optimization Hub を活用した検出
- 削除前の重要な注意点
- AWS の本アップデートに関連する情報
- まとめ
はじめに
AWS コスト最適化において、稀に話題に上がるリソースの1つが NAT Gateway のコストです。
コスト最適化では、NAT Gateway を必要に応じて、ネットワークアカウントに集約することも考えられます。
上記ブログ「AWS Transit Gateway を用いて NAT Gateway を集約し、コストを最適化するための経路設計」では、そのための情報を当時の Transit Gateway の仕様に則って詳細に解説しました。
さて、と言いましても先にご紹介した NAT Gateway に関するコスト最適化は、ネットワークの通信量に関するコストが主でした。今回は、そもそも「使ってないリソースがあるのではないか」という「ゴミ掃除」を観点にした話です。
NAT Gateway の料金体系と消し忘れについて
NAT Gateway は「時間単位の料金（処理データ量に関わらず発生）」と「データ処理料金」の構造になっており、特に前者の「置いておくだけでかかる固定費」は、例えば東京リージョンでは 0.062 USD/時間の利用料が発生します。2つの AZ で利用する場合、NAT Gateway は単純計算で年間「$0.062 * 2 AZ * 24 * 365 = $1,086.24」の保持費用がかかり*1、思ったよりも高コストになるサービスだったりします。
開発環境や検証環境で「とりあえず作成したまま忘れていた」NAT Gateway が積み重なると、意外と大きな出費になります。特に最近は VPC の構築 UI も改善されており、NAT Gateway までを自動で作成してくれる反面、NAT Gateway の削除忘れも少し増えた印象です。
定期的にコストを棚卸しているお客様は、請求書や Cost Explorer で「NAT Gateway の料金が高いな」と気づいてから手動で対応することもあったかもしれません。
今回のアップデートで Compute Optimizer が自動的に「これ、使ってませんよね？」と教えてくれるようになりました。
AWS Compute Optimizer と最近のアップデート
AWS Compute Optimizer は、リソースの設定と使用率の AWS メトリクスを分析して、適切なサイズのレコメンデーションを提供し、アイドル状態のリソースを特定するサービスとなっています*2。
AWS Compute Optimizer の大きなアップデートとして、先日「AWS Compute Optimizer Automation で EBS の最適化アクションを自動化可能になった」という機能アップデートがあり、ブログを執筆しました。
本アップデートに引き続き、AWS Compute Optimizer に来たアップデートが「未使用の NAT Gateway の推奨」の追加です。
公式ドキュメントにもその旨が追記されていましたので、画面キャプチャと共に以下ご紹介します。
どのようにして未使用 NAT Gateway と判定されるのか
AWS Compute Optimizer は以下の基準を用いて、NAT Gateway が「未使用（Idle）」であるかを判断します。
- 32日間の分析期間
- 過去32日間にわたり、トラフィックアクティビティがないことを確認
- CloudWatch メトリクスの分析
ActiveConnectionCount(アクティブな接続数)PacketsInFromSource(ソースからの受信パケット)PacketsInFromDestination(宛先からの受信パケット)- これらがすべて「ゼロ」であることを確認し、Idle 状態かをチェック
- ルートテーブルの関連付け
- その NAT Gateway が、どの AWS Route Table にも関連付けられていないかを確認します
これら全ての条件を満たしたとき、初めて「未使用」として推奨事項に上がってきます。
注意点として、EBS のアイドル検出と同様に「32日間」という期間が必要です*3。つまり、昨日作成して放置しているものは、すぐには検出されません。
また「どの AWS Route Table にも関連付けられていない」という前提は正直厳しいですね。
Idle criteria
The NAT Gateway is in available state, is not associated with any AWS Route Tables, and has no active connection, no Packets in from both source and destination over the lookback period.
(日本語訳)
NAT Gateway は利用可能な状態であり、どの AWS ルートテーブルにも関連付けられておらず、アクティブな接続がなく、ルックバック期間中に送信元と送信先の両方からのパケットがありません。
マネジメントコンソール上から、VPC と共に NAT Gateway を自動で作ったまま放置しているような場合、ルートテーブルにも紐づいているわけで、それをアイドルとして判定できないのはなかなか判定がシビアに思います。
Cost Optimization Hub を活用した検出
今回のアップデートを受けて、動作確認を兼ねて「自社環境に該当のリソースがあるか？」を確認しようとしました。
しかし、Compute Optimizer の管理コンソールでは、マルチアカウント環境において全アカウントの NAT Gateway を横断的に検索し、未使用のものだけを一覧化するのは手間です。コンソールが AWS アカウント単位でしか閲覧できないため、100 以上のメンバーアカウントがあるような場合に、検索性は悪いと言わざるを得ません。
「もっと手っ取り早く、組織全体から該当リソースを探し出したい」
そんな時に非常に便利なのが、Cost Optimization Hub です。Cost Optimization Hub については以下のブログでもご紹介しました。
Cost Optimization Hub は、Compute Optimizer を含む Savings Plans や Reserved Instances 等の AWS サービスのコスト最適化推奨事項を集約してくれるサービスであり、全アカウント・全リージョンを「串刺し」で検索することが可能です。
実際に検出結果を確認してみる
「Compute Optimizer の新しい機能の検出結果は Cost Optimization Hub にも自動的に連携されるだろう」と見込み、実際に弊社の検証環境を調査してみたところ、今回のアップデートによる検出結果が既に Cost Optimization Hub に連携されていました。
手順は非常にシンプルです。Cost Optimization Hub のダッシュボードからフィルター機能を使用します。
上図のように「Selected resource types」のフィルターから、「NAT gateway」を選択します。これで、組織内のすべての NAT Gateway に関する推奨事項に絞り込むことができます。
検出結果の確認
フィルターを適用した結果、「Savings opportunities」に以下の一覧が表示されました。
ご覧の通り、「Resource type = NatGateway」で絞り込まれており、Top recommended action に "Check if the resource is part of a disaster recovery setup" というメッセージが表示されています。この点については後で補足します。
とまあこのように、Cost Optimization Hub を活用することで、社内検証環境に埋もれていた「未使用の NAT Gateway」を簡単に特定することができました。Compute Optimizer の画面をアカウントごとに切り替えて探すよりも、大規模環境では Cost Optimization Hub を用いた運用の方が圧倒的に効率的です。
削除前の重要な注意点
推奨事項が出たからといって、何も考えずに削除するのは危険です。以下の点を確認してください。
1. 災害対策 (DR) 用のリソースではないか？
Active-Standby 構成や、災害対策用のウォームスタンバイ環境として NAT Gateway を構築している場合、平常時はトラフィックが流れません。
Compute Optimizer (および Cost Optimization Hub) のメッセージにもある通り、DR 用途であれば、この推奨事項は意図的なアイドル状態であるため「無視（Dismiss）」する、あるいは削除しないという判断が必要です。これが先ほどのメッセージ「"Check if the resource is part of a disaster recovery setup"」の意図するところです。
ただ気になるのは、DR 用途であればルートテーブルの設定が入っていると想定されるため、先の「Idle criteria」を満たさない気も少ししますが、この観点での確認が重要であることに変わりはありません。
2. 32日間のルックバック期間の罠
前述の通り、分析期間は32日です。「月に1回だけバッチ処理で使う」といった極めて低頻度な利用の場合、タイミングによっては「未使用」と判定されるリスクが少なからずあります。
削除前には、念のためシステム担当者に「この NAT Gateway は本当に不要か？」を確認するフローを設けることが推奨されます。
AWS の本アップデートに関連する情報
リリースニュース
- AWS Compute Optimizer now supports unused NAT Gateway recommendations
まとめ
本ブログでは、2025年11月26日に発表された AWS Compute Optimizer の新機能「未使用 NAT Gateway の検出」について解説しました。
NAT Gateway は VPC 内でもコストインパクトの大きいリソースの一つです。これが自動的に検出できるようになったことは、FinOps の観点からも非常に嬉しいアップデートと言えます。
マルチアカウント環境においては、Cost Optimization Hub を併用することで、組織全体の「無駄なコストの削減余地」を簡単に探し出せるのですが、この機能にも既に連携済であることの確認が取れました。皆様もぜひ一度、Cost Optimization Hub の画面で未使用の NAT Gateway の検出結果が生成されていないかご確認ください。
ただし、念のためDR 環境などの「意図的なアイドル状態」も検出してしまう可能性がある点には十分ご注意ください。
余談：Regional NAT gateway
NAT Gateway に関連して、先日「Regional NAT gateway」がリリースされました。
弊社石田の記事です。合わせてご覧頂ければ NAT Gateway に関する最新の知見をさらにキャッチアップできるかと存じます。
- Regional NAT gateways for automatic multi-AZ expansion
では、またお会いしましょう。
*1:EIP のコストは除外しています
*2:公式ドキュメント https://docs.aws.amazon.com/ja_jp/compute-optimizer/latest/ug/what-is-compute-optimizer.html
*3:少々長いと感じるという話は別のブログでもしたのですが、32日間という期間がネックになります。作成して数日の消し忘れは検出されません
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
