【入門編】 AWS NATゲートウェイのアイドルタイムアウト値（350秒）とキープアライブ制御 – クラウド＆コンテナネットワーク実践ガイド

はい、承知いたしました。AWS NATゲートウェイのアイドルタイムアウトとTCP Keep-Aliveについて、初心者の方にも分かりやすく、実務で役立つようなブログ記事を作成します。パケットがどのように流れていくのか、身近な例えを交えながら、丁寧に解説していきますね。

—

AWS NATゲートウェイ、350秒の壁を越えろ！ ～アイドルタイムアウトとKeep-Aliveの賢い付き合い方～

皆さん、こんにちは！ AWSやKubernetesのネットワークの世界へようこそ。今回は、クラウドインフラを支える縁の下の力持ち、NATゲートウェイのお話です。特に、プライベートサブネットからインターネットへ通信する際に避けて通れない「アイドルタイムアウト」という仕様と、その対策としての「TCP Keep-Alive」について、初心者の方にも「なるほど！」と思っていただけるように、じっくり紐解いていきましょう。

そもそもNATゲートウェイって何者？ ～インターネットへの「翻訳屋さん」～

まず、NATゲートウェイの役割を、身近な例で考えてみましょう。

皆さんのご自宅に、インターネットに接続できるWi-Fiルーターがありますよね。このルーターは、家の中のたくさんのデバイス（スマホ、PC、タブレットなど）が、それぞれ異なるプライベートIPアドレスを持っているのに、インターネット上では一つのグローバルIPアドレスを使って通信できるように、「IPアドレスの翻訳」をしてくれています。

AWSのNATゲートウェイも、これと似たような役割を担っています。

  • プライベートサブネット: VPC（Virtual Private Cloud）という、AWS上に構築されたプライベートなネットワーク空間の中に、インターネットから直接アクセスできないように隔離された領域があります。ここに配置されたEC2インスタンス（仮想サーバー）などは、インターネットへ直接通信できません。
  • パブリックサブネット: 一方、インターネットからアクセス可能な、いわゆる「表舞台」に置かれた領域です。
  • NATゲートウェイ: このプライベートサブネットにあるインスタンスがインターネットへ通信したいときに、NATゲートウェイが「橋渡し役」になります。プライベートIPアドレスを、NATゲートウェイが持つグローバルIPアドレスに「翻訳」して、インターネットへ送り出してくれるんです。まるで、海外とのやり取りで通訳さんがいてくれるようなイメージですね！

このNATゲートウェイのおかげで、プライベートサブネットにあるサーバーは、セキュリティを保ちつつ、OSのアップデートや外部APIの利用といった、インターネットへのアクセスが必要な処理を安全に行うことができるのです。

突然の「切断」にご注意！ ～NATゲートウェイの350秒ルール～

さて、このNATゲートウェイ、とっても便利なんですが、一つだけちょっとだけ注意しておきたい仕様があります。それが、「アイドルタイムアウト」です。

NATゲートウェイは、通信が行われていない状態が一定時間続くと、その通信の「コネクション情報」を忘れてしまいます。この「一定時間」というのが、デフォルトで350秒（約6分弱）なんです。

これは、NATゲートウェイが内部で管理している、どのプライベートIPアドレスがどのグローバルIPアドレスと通信しているか、といった情報（コネクションテーブル）を、ずっと持ち続けるのはメモリの無駄遣いになってしまうためです。使われていない通信は、一定時間で「お片付け」しちゃう、というわけですね。

郵便配達員さんの「一時停止」に例えると…

想像してみてください。郵便配達員さんが、あなたの家と、近所のAさんの家、Bさんの家を順番に回っているとします。

  • 配達員さんは、Aさんの家に今日配達した荷物と、次にBさんの家に運ぶ荷物のリストを持っています。
  • もし、Aさんの家でしばらく荷物の受け取りやサインがなく、配達員さんが「あれ？Aさんの家、今は何も用事ないのかな？」と思ったら、配達員さんはAさんの家のためのリストを一旦片付けて、他の配達に集中するかもしれません。
  • 後でまたAさんの家に用事ができたら、その都度新しくリストを作って配達します。

NATゲートウェイもこれに似ています。通信がない状態が350秒続くと、「この通信、もう使われていないかな？」と判断して、そのコネクション情報を一時的に破棄してしまうのです。

なぜ350秒で切断されると困るの？

「え、6分くらいなら別に困らないんじゃない？」と思われるかもしれません。しかし、これが意外と厄介なケースがあるんです。

例えば、

  • Webサーバーとデータベースサーバーが、長時間のバッチ処理やレポーティングなどで通信している場合。
  • WebSocketなどの、リアルタイム通信を維持するアプリケーション。
  • 一部の長時間のAPIリクエスト。

このような、通信が途切れることはないけれど、頻繁に「パケットのやり取り」が発生するわけではないような通信で、この350秒ルールが影響することがあります。

具体的には、350秒の間に、NATゲートウェイがコネクション情報を破棄してしまい、その後、本来は継続されるはずだった通信が、新しいコネクションとして再確立されようとして、予期せぬエラーやセッションの切断を引き起こしてしまうのです。

解決策は「Keep-Alive」！ ～「まだ使ってますよ～！」の合図～

では、この350秒の壁をどうやって乗り越えれば良いのでしょうか？ そこで登場するのが、TCP Keep-Aliveという仕組みです。

これは、TCP（Transmission Control Protocol）という通信プロトコルが持っている機能で、通信相手に対して、定期的に「まだこの通信は生きていますよ」という小さな信号（パケット）を送り続けることができるものです。

先ほどの郵便配達員さんの例で言うと、配達員さんがAさんの家の前を通りかかるたびに、「Aさん、元気ですかー？荷物はありませんかー？」と声をかけるようなイメージです。この声かけがあることで、配達員さんは「Aさんの家は、まだ配達の対象なんだな」と認識し続け、リストを片付けずに済みます。

TCP Keep-Aliveを設定することで、NATゲートウェイのアイドルタイムアウト（350秒）よりも短い間隔で、アプリケーションから小さなパケットが送られるようになります。これにより、NATゲートウェイは「このコネクションはまだアクティブなんだな」と判断し、コネクション情報を破棄せずに維持してくれるようになります。

TCP Keep-Aliveの設定方法：OSレベルでの調整

TCP Keep-Aliveは、主にOSのネットワーク設定で調整できます。Linuxの場合、/etc/sysctl.conf という設定ファイルを編集するのが一般的です。

/etc/sysctl.conf の設定例

# TCP Keep-Aliveの設定
# tcp_keepalive_time: アイドル状態が続いた場合に、Keep-Aliveプローブ（信号）を送信し始めるまでの時間（秒）
# デフォルトは7200秒（2時間）ですが、NATゲートウェイのタイムアウト（350秒）を考慮して短めに設定します。
# ここでは、NATゲートウェイのタイムアウトよりも短い、120秒（2分）に設定してみましょう。
net.ipv4.tcp_keepalive_time = 120

# tcp_keepalive_intvl: Keep-Aliveプローブを送信してから、応答がない場合に次のプローブを送信するまでの間隔（秒）
# デフォルトは75秒です。
net.ipv4.tcp_keepalive_intvl = 60

# tcp_keepalive_probes: 応答がないKeep-Aliveプローブを何回送信したら、接続を終了するか（試行回数）
# デフォルトは9回です。
# (120秒 + 60秒 * 9回 = 18分。これで接続が切れる計算になります)
net.ipv4.tcp_keepalive_probes = 9

【解説】

  • net.ipv4.tcp_keepalive_time: これが一番重要です。この値（例では120秒）は、通信が「アイドル状態」になってから、最初にKeep-Aliveの信号を送り始めるまでの時間です。NATゲートウェイの350秒よりも短い値に設定することで、NATゲートウェイがコネクション情報を破棄する前に、Keep-Alive信号が送られるようになります。
  • net.ipv4.tcp_keepalive_intvl: 最初のKeep-Alive信号を送ってから、相手からの応答がない場合に、次に信号を送るまでの間隔です。
  • net.ipv4.tcp_keepalive_probes: 相手からの応答が全くない場合に、何回まで「まだ生きてる？」と信号を送り続けるかの回数です。この回数分、応答がなければ「もうダメだ」と判断して接続が切断されます。

設定の適用方法

1. 設定ファイルの編集:

sudo vi /etc/sysctl.conf

上記の内容を追記または修正します。

2. 設定の反映:
編集後、以下のコマンドで設定をOSに適用します。

sudo sysctl -p

【注意点】

  • この設定は、そのインスタンス（サーバー）全体に適用されます。特定のアプリケーションだけではなく、OSレベルでTCP接続のKeep-Aliveの挙動が変わるので、他のアプリケーションへの影響がないか、事前にテスト環境で十分確認してくださいね。
  • tcp_keepalive_time の値は、NATゲートウェイのアイドルタイムアウト値（350秒）よりも短い値を設定するのが基本ですが、短すぎると不要な通信が増える可能性もあります。アプリケーションの通信パターンや、NATゲートウェイのアイドルタイムアウト値（AWSのドキュメントでは350秒とされていますが、将来的に変更される可能性もゼロではありません）を考慮して、適切な値を見つけることが重要です。

アプリケーションレベルでのKeep-Alive

OSレベルでの設定以外にも、アプリケーション側でHTTPヘッダーのConnection: keep-aliveや、アプリケーション独自のKeep-Aliveメカニズムを実装することで、コネクションを維持する方法もあります。ただし、これはアプリケーションの実装に依存するため、ここではOSレベルでの調整に焦点を当てました。

まとめ：NATゲートウェイと上手に付き合おう！

今回は、AWS NATゲートウェイの「350秒アイドルタイムアウト」という仕様と、その対策としての「TCP Keep-Alive」について解説しました。

  • NATゲートウェイは、プライベートサブネットからインターネットへの通信を安全に行うための「翻訳屋さん」です。
  • デフォルトで350秒間通信がないと、コネクション情報を破棄してしまう「アイドルタイムアウト」仕様があります。
  • この仕様により、長時間の通信や、頻繁なパケット交換を伴わない通信で、セッションが切断されることがあります。
  • TCP Keep-Aliveを設定することで、NATゲートウェイがコネクション情報を維持し、セッション切断を防ぐことができます。
  • OSレベルでは、/etc/sysctl.conf のnet.ipv4.tcp_keepalive_timeなどを調整することで設定可能です。

インフラやネットワークの設定は、時に「なぜこうなっているんだろう？」と疑問に思うことも多いかと思います。でも、今回のように、身近な例えで考えてみたり、一つずつ仕組みを紐解いていけば、きっと理解が深まるはずです。

この知識が、皆さんのAWSでのインフラ構築やトラブルシューティングの一助となれば幸いです。また次回のブログでお会いしましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました