【入門編】 ローカルルート(Local Route)の自動生成と削除不可の仕様 – クラウドインフラと仮想化ネットワーク実践ガイド

AWSの「ローカルルート」って何者?VPCの郵便配達員が絶対に守る「絶対ルール」を紐解く

クラウドの世界に足を踏み入れたばかりのエンジニアの皆さん、こんにちは!

AWSでVPC(仮想プライベートクラウド)を作るとき、必ずと言っていいほど目にするのが「ルートテーブル」ですよね。インターネットに出るための 0.0.0.0/0 を設定したり、NATゲートウェイを通したりと、パケットの行き先を指示する重要な司令塔です。

でも、ルートテーブルの設定画面をよーく見ると、「自分たちが設定した覚えがないのに、最初からどっしりと構えているルート」が一つだけあることに気づきませんか?

それが、今回スポットを当てる「ローカルルート(Local Route)」です。

「これ、削除ボタンが押せないし、なんだか怖いから触らないでおこう…」なんて思っていませんか?実はこのローカルルートこそ、VPCという広大な街を支える「最も基本的な郵便配達のルール」なんです。今日は、この不思議な存在の正体を、身近な例え話でスッキリ理解していきましょう!

—

郵便配達で例える「VPC内の通信」

想像してみてください。あなたは「VPC」という名前の広大な巨大マンションの管理人さんです。このマンションには、たくさんの部屋(インスタンス)があります。

ある日、302号室から「405号室に荷物を届けたい!」という依頼が来ました。さて、管理人であるあなたは、どうやって荷物を届けますか?

1. マンション内(VPC内)の配送: 同じマンション内の部屋同士なら、わざわざ一度外の郵便局(インターネットゲートウェイ)を経由する必要なんてないですよね。廊下を通ってすぐ隣の部屋に届ければいいはずです。
2. マンション外(インターネット)への配送: 逆に、マンションの外にあるお店に荷物を送るなら、一旦エントランスの郵便局(インターネットゲートウェイ)に荷物を持っていく必要があります。

このとき、「マンション内の部屋同士なら、外部を通さず直接廊下を通って届ける!」というルールが、まさにAWSにおける「ローカルルート」の役割です。

—

なぜ「削除不可」なのか?

AWSのコンソールでルートテーブルを見ると、VPCに割り当てたIPアドレス範囲(例: 10.0.0.0/16)に対して、ターゲットが local となっている行がありますよね。これがローカルルートです。

「なんで削除できないの?」と不思議に思うかもしれませんが、理由は単純。もしこのルールを消してしまったら、VPC内のサーバー同士が一切会話できなくなるからです。

想像してみてください。マンションの管理人が「廊下を通っての配達は禁止!」と宣言したらどうなるでしょう? 302号室から405号室に荷物を送るために、一度わざわざマンションの外に出て、わざわざ郵便局に行って、またマンションに戻ってくるという、とんでもなく無駄で非効率なことをしなければなりません。

AWSは、皆さんが「うっかりミス」をしてVPC内を分断してしまわないように、この「廊下を通るための基本ルール」だけは絶対に削除できないよう、厳重にロックをかけているのです。

—

現場で役立つ確認コマンド

さて、理屈がわかったところで、実際に自分の環境でこの「絶対ルール」を確認してみましょう。AWS CLIを使えば、この様子が手に取るようにわかります。

まずは、自分のVPC IDを確認してから、特定のルートテーブルを覗いてみましょう。

# ルートテーブルの情報を取得するコマンド
aws ec2 describe-route-tables \
    --route-table-id rtb-xxxxxxxxxxxxxxxxx \
    --query "RouteTables[0].Routes"

このコマンドを打つと、以下のようなJSONデータが返ってきます。

[
  {
    "DestinationCidrBlock": "10.0.0.0/16", // VPCのIP範囲
    "GatewayId": "local"                  // これが「ローカルルート」の証!
  },
  {
    "DestinationCidrBlock": "0.0.0.0/0",
    "GatewayId": "igw-xxxxxxxxxxxxxxxxx"   // こっちはインターネットへ行く道
  }
]

ここで注目してほしいのが "GatewayId": "local" です。これが付いているルートは、VPCが「俺の管轄内だから、外に出さずに俺が直接つないでやるよ!」と宣言している証拠なんです。

—

SREからのワンポイントアドバイス:注意すべき「例外」

基本的には「VPC内ならローカルルートで解決!」で万事OKなのですが、実務でハマりやすい罠が一つあります。

それは、「VPCピアリング」や「Transit Gateway」を使うときです。

  • VPCピアリング: 別のVPCとつなぐ場合、その相手のIPアドレス範囲は「ローカルルート」ではありません。自分で明示的にルートを追加して、「あっちのマンションの住所宛なら、あの橋(ピアリング接続)を通れ!」と教えてあげる必要があります。
  • サブネットの境界: ローカルルートは「VPCというマンション全体」のルールです。サブネット(例えばパブリックサブネットとプライベートサブネット)を分けたからといって、ローカルルートが消えることはありません。だから、同じVPC内であれば、パブリックサブネットのサーバーからプライベートサブネットのデータベースへ、セキュリティグループの許可さえあれば直接通信できるんです。

—

まとめ:ローカルルートは「VPCの心臓部」

いかがでしたか?

「削除不可」と聞くと身構えてしまいますが、それは「このルールがないとVPCがVPCとして機能しなくなる」というAWSからの優しさなんです。

  • ローカルルートは、VPC内の通信を円滑にするための「基本ルール」。
  • 削除できないのは、誤操作によるネットワーク遮断を防ぐため。
  • 外部通信との「交通整理」は、このローカルルートを基準に行われる。

この仕組みを理解しておくと、複雑なネットワークトラブルに直面したときでも、「あ、これはローカルルートの範囲内だから通信できるはずだ」とか、「いや、これは別のVPCだからルートの追加が必要だな」と冷静に判断できるようになります。

ネットワークの道は一歩ずつ。まずはこの「絶対に消えないルール」を味方につけて、クラウドインフラの世界を深く探索していきましょう!それでは、次回の記事もお楽しみに!

コメント

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