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

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

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

概要説明

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

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

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

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

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

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

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

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

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

まずは前提知識として、メインルートテーブルとカスタムルートテーブルの違いをおさらいしましょう。

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

  • 作成のタイミング：VPC作成時に自動で作成され削除不可のルートテーブル
  • 削除：削除することが出来ない（VPCを削除するまで存在し続ける）
  • 関連付け設定：新規サブネット作成時に明示的なルートテーブルが設定されていない場合、デフォルトで設定されるルートテーブル

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

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

  • 作成のタイミング：ユーザが別途任意のタイミングで作成するルートテーブル
  • 削除：不要になればいつでも削除が可能
  • 関連付け設定：サブネットに明示的に関連付け設定を行いルート設定を行い、初めてそのサブネットの通信ルールとして利用可能

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

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

なぜメインルートテーブルにグローバル宛のパブリック通信（Internet Gatewayへのルート：0.0.0.0/0 など）を設定したらダメなのでしょうか。

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

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

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

【NGパターンの設定例】メインルートテーブルでのパブリック通信許可

  • 送信先： 0.0.0.0/0 ターゲット： igw-xxxxxx (インターネットゲートウェイ)
  • 送信先： 10.0.0.0/16 ターゲット： local

この設定が適用されたサブネットは、インターネットと通信可能な「パブリックサブネット」になってしまいます。
もしテスト用だからとセキュリティグループの設定を緩く設定し、すべてのIPからのSSHアクセスを許可やDBへ接続可能などしていた場合、誰でもインターネット経由でそのデータベースやサーバーにアクセスできる状態が完成してしまいます。

AWS Well-Architected Frameworkの「セキュリティの柱」では、意図しないアクセスの予防と最小特権の原則が強く推奨されています。

メインルートテーブルにパブリックルートを持たせることは、設定漏れや考慮不足などのミスが重大なセキュリティインシデントに直結します。
ひとつのミスが発生しても多層的に防げる状況を作る設計が理想です。

【OKパターンの設定例】ローカル通信のみを許可

  • 送信先： 10.0.0.0/16 ターゲット： local
  • デフォルトルート (0.0.0.0/0) は設定しない

NGパターンのリスクを防ぐためのベストプラクティスが、「メインルートテーブルにはローカル通信のみを許可」するという設定です。

この設計方針の根底にあるのは「フェイルセーフ（Fail-safe）」という考え方です。
フェイルセーフとは、誤操作やシステム障害が発生した場合でも、常に安全な方向へシステムを制御するという設計思想です。

もしメインルートテーブルがローカル通信のみに制限されていれば、先ほどのように「サブネットを作成したけれど、ルートテーブルを紐づけ忘れた」というミスが発生してもインターネットへ抜けるルートが存在しません。in/out共にVPC内のローカル通信で完結し、外部からの予期しないアクセスを遮断することができます。安心！安全！な設計は大切ですね。

メインルートテーブルは「ローカル通信のみ」とし、必要な通信ルートは全てカスタムルートテーブルを作成して明示的に紐づけるという運用設計をしておくと幸せになれるかもしれません。

なお、現在はVPC作成時の設計で問題なし

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

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

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

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

余談：さらに安全性を高めるための運用・監視プラクティス

設計時のルールを決めるだけでなく、運用フェーズにおいても「メインルートテーブルが安全に保たれているか」を継続的に担保する仕組みの導入もあります。

AWS Configのマネージドルールの活用

AWS Configを利用すると、リソースの設定変更を継続的に評価・監視できます。
今回のケースでは、vpc-main-route-table-no-igw というマネージドルールを有効化することで、誤った設定に気付くことが可能です。

万が一誰かがメインルートテーブルにInternet Gatewayへのルートを追加した場合、即座に「非準拠（Non-compliant）」として検知し、アラートを上げることが可能になります。

IaC (Infrastructure as Code) の導入

手動でのポチポチ作業はミスの元です。
AWSもベストプラクティスとして「インフラストラクチャのコード化（IaC）」を推奨しています。

TerraformやAWS CloudFormation、AWS CDKといったIaCツールを使用してインフラレイヤーもコード管理していくようにしましょう。

IaCを利用すれば、「サブネット作成リソースブロックには、必ずカスタムルートテーブルの関連付けブロックをセットで記述する」といったテンプレート化が可能になり、作業ミスや設計漏れなどを低減することに繋がります。

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