インフラチームがお届けするブログリレーです！既に公開されている記事もありますので、こちらから他のメンバーの投稿もぜひチェックしてみてください！

皆さんAWSのVPCでルートテーブルは使っていますでしょうか。
ルートテーブルの中にも「メインルートテーブル」と「カスタムルートテーブル」が存在します。

今回は「メインルートテーブル」の設定で、パブリック通信を設定しない設計方針のススメとし、記事に起こそうと思います。
ルートテーブルについて知りたい方の参考になれば幸いです。

概要説明

NGパターン：パブリック通信を許可

下図はメインルートテーブルに「パブリック通信」を許可している設定です。

インターネット通信が許可されているため、メインルートテーブルが設定されたサブネットは、インターネット上にデータをアップロード等出来る状態が発生します。

OKパターン：ローカル通信のみ許可

下図はメインルートテーブルに「ローカル通信」のみ許可している設定です。

ローカル通信のみ許可されているため、インターネット上にデータをアップロード等が出来ない状態となります。

※上記はVPC作成時に自動作成した際の設定です。
　自動作成していれば気にしなくて良い箇所なので便利になりましたね。

それでは、なぜメインルートテーブルについてグローバル宛のパブリック通信を設定したらダメなの？という観点について紹介します。

メインルートテーブル / カスタムルートテーブルについて

メインルートテーブルとは

  • VPC作成時に自動で作成され削除不可のルートテーブル
  • 新規サブネット作成時に明示的なルートテーブルが設定されていない場合、デフォルトで設定されるルートテーブル

対象VPC内の各サブネットで、ルートテーブルが関連付けされていなかった場合必ず割り当てられるルートテーブルになります。
ルートテーブルを設定し忘れた際に必ず割り当てられるルートテーブルが「メインルートテーブル」です。

カスタムルートテーブルとは

  • ユーザが別途作成し、削除可能なルートテーブル
  • サブネットに明示的に関連付け設定を行いルート設定を行う必要がある

対象VPC内でサブネットを作成した際に、明示的に設定する必要があります。
NATGatewayはパブリックサブネット、RDSや各種サーバ郡はプライベートサブネットなど、設計者が明示的に区画を分けたい時に利用するものが「カスタムルートテーブル」になります。

設計の意図：セキュリティインシデント予防

なぜメインルートテーブルに「パブリック通信」を設定してはダメなのでしょうか？

それは上述した通り「意図しないアクセスの予防」となります。

  • 設計者がサブネット作成時にカスタムルートテーブルを設定し忘れている
  • それに気づかずセキュリティグループの設定を緩くしている
  • インターネット経由で誰でもアクセス出来る状態となっていた

メインルートテーブルにインターネットアクセスが付与されていなければ、in/out共にローカル通信で終わるため、予期しない通信は防ぐことができます。
そのため、メインルートテーブルにはローカル通信のみとし、必要なルートテーブルは全て「カスタムルートテーブル」とすることが予防措置として有効です。

VPC作成時の設計で問題なし

ちなみにですが、2025/5月時点のVPC作成時に「VPCなど」を選択して自動で各種リソースを作成していれば問題ありません。

自動でルートテーブルを作成し、各サブネットへ関連付けまでしてくれます。

下図のようにメインルートテーブルにはどのサブネットも紐づいておらず、ローカル通信に限定された設定です。

※一昔前はこんな機能はなく、イチから全部自分で設計、構築していたので便利になりました。
　事故も減ってどんどん便利になっていくので利用側としても安心です。

以上、メインルートテーブルにはローカル通信のみにして、予期しない事故を防いでいきましょうという記事でした。
ルートテーブルについてよく分からないという方の記事となっていただければ幸いです。