VPCで通信できない時に最初に見るRoute table　原因トップ5と確認手順

AWS

VPCの疎通不良は、セキュリティグループやNACLが疑われがちです。もちろんそれも大事なのですが、意外と多いのが「そもそも行き先が決まっていない」つまりRoute table起因のトラブルです。Route tableは“通信の道路標識”なので、標識が間違っていれば到達できません。

この記事では、Route tableの基本を短く押さえたうえで、通信できないときの原因トップ5を「どう確認し、どう直すか」まで具体例つきで整理します。SAA-C03を目指す人が混乱しやすい論点に寄せて、暗記ではなく考え方が残る形にします。

SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇

SAA-C03対策｜Udemyのおすすめ講座を見る

Route tableの前提整理

ここを押さえると、原因の当たりが付くようになります。

Route tableは何を決めるのか

Route tableは、サブネットやゲートウェイから出ていく通信に対して「宛先に応じて次にどこへ渡すか」を決めるルールの集合です。サブネットに紐づくRoute tableの内容で、インターネットに行くのか、NATに行くのか、別VPCへ行くのかが決まります。

サブネットは必ずどれか1つのRoute tableを使う

サブネットは、明示的に関連付けされていない場合、VPCのメインRoute tableを使います。「カスタムを作ったのに効いてない」の多くはこの関連付けが原因です。

localルートは基本消せない前提

VPC内通信のためのlocalルートが入っていて、同一VPC CIDR内は基本的にlocalで到達します。ここを誤解すると「VPC内なのに行けないのはRoute tableのせい」と決めつけて迷子になります。

経路は一番具体的なものが選ばれる

Route tableは、宛先に一致するルートが複数ある場合、より具体的な経路が優先されます。これが「設定したはずの0.0.0.0/0が効かない」系の正体になりやすいです。

通信できない原因トップ5

ここからが本題です。どれも現場で“あるある”で、試験でも前提知識として扱われやすいポイントです。

サブネットが想定外のRoute tableに関連付けされている

最初に疑うべき原因です。理由は単純で、正しいルートを書いてもサブネットがそのRoute tableを見ていなければ意味がないからです。

よくあるパターン

  • Publicサブネットのつもりが、メインRoute tableのまま
  • Private用Route tableを作ったが、サブネット関連付けを忘れた
  • 複数AZで片方だけ関連付けが違い、片系だけ疎通不良

確認ポイント

  • 対象サブネットの「Route table」表示で、どのRoute tableが適用されているかを確認
  • 「明示的な関連付け」か「メインを使用」かを見る（ここが落とし穴）

直し方

  • 正しいRoute tableをサブネットに関連付けし直す
  • メインRoute tableに任せる設計なら、メイン側のルートが意図通りかを再点検

デフォルトルートの向き先がない・違う

インターネット疎通で最も多いのがこれです。「0.0.0.0/0が無い」「ターゲットが違う」だけで、外へ出られません。

典型例

  • Publicサブネットなのに0.0.0.0/0 -> igwがない
  • Privateサブネットなのに0.0.0.0/0 -> natがない
  • NAT Gatewayを置いているサブネット自体がPublicになっておらず、NATが外に出られない

整理のコツ

  • Publicサブネット＝「IGWへの経路があるサブネット」
  • Privateサブネット＝「IGWへの経路がないサブネット」
    この判定はRoute tableで決まります。

具体例

  • PrivateサブネットのEC2がyum updateできない
    • EC2のサブネットのRoute tableで0.0.0.0/0 -> nat-xxxxがあるか
    • NAT Gatewayが置かれているサブネットのRoute tableで0.0.0.0/0 -> igw-xxxxがあるか（NATが外に出るため）

戻り経路がなくて片方向になる

「片方向だけ通る」は、Route tableの戻り経路不足がかなり多いです。特に、VPC Peering、Transit Gateway、Site-to-Site VPN/Direct Connectのような“別経路”が絡むと発生しやすいです。

考え方

  • 通信は基本的に往復です
  • 行きのRoute tableだけ整っても、相手側が戻り先を知らないと応答が帰ってきません

具体例

  • VPC-AからVPC-BのEC2へ到達しない
    • VPC-Aのサブネット側に「VPC-B CIDR -> peering/tgw」
    • VPC-B側のサブネットにも「VPC-A CIDR -> peering/tgw」
      片方だけ設定して「繋がらない」となるのが定番です。Route tableは片側だけでは完結しません。

より具体的なルートに負けている

「0.0.0.0/0はあるのに想定と違う方向へ行く」「急に繋がらなくなった」というときは、追加したルートが優先されている可能性があります。

ポイント

  • Route tableは、宛先が重なったときより具体的なプレフィックスが優先されます。
  • さらに、prefix listを使うルートや伝播ルートが絡むと、優先関係の理解が必要になります。

ありがちな事故

  • オンプレ宛の経路を追加したつもりが、社内IPレンジとVPC内のレンジが重なり、意図しない方向へ
  • S3のGateway Endpointを入れたら、S3向け通信だけがIGW/NATではなくEndpointへ流れる（これは正しい動きだが、知らないと混乱する）

切り分け

  • 宛先IPが属するCIDRを確認して、Route table上で“どの行にマッチするか”を手で追う
  • 一番具体的な行から順に見る癖をつける（0.0.0.0/0は最後）

VPC Endpointや経路伝播の理解違い

Endpointや伝播は便利ですが、「勝手に入る」「リージョン依存」などの特性を知らないと沼ります。

S3やDynamoDBのGateway Endpoint

  • Gateway Endpointは、サブネットのRoute tableにサービスのprefix list宛のルートが入ります。
  • そしてその宛先に一致する通信は、0.0.0.0/0がIGWに向いていても、Endpointルートが優先されます。
  • prefix listはリージョン依存なので「別リージョンのS3」は同じ挙動にならない点も混乱ポイントです。

経路伝播と優先度

  • VPNやDirect Connect、Transit Gatewayなどで伝播ルートを使う場合、同一宛先が競合したときの優先関係を押さえる必要があります。
  • 「伝播が入ってるから大丈夫」ではなく、静的ルートと衝突していないか、より具体的な宛先がないかを確認するのが安全です。

すぐ使える切り分け手順

ここでは、実務でも試験でも使える“順番”を固定します。Route tableが原因かどうかを短時間で判断できます。

まずは通信の種類を決める

  • インターネットに出たいのか
  • 別サブネットや別VPCに行きたいのか
  • S3などAWSサービスに行きたいのか

宛先が違えば、見るべきRoute tableの行もターゲットも変わります。

次にこの順で確認する

  • 対象EC2がいるサブネットはどれか
  • そのサブネットに適用されているRoute tableはどれか
  • 宛先に一致するルートがあるか
  • ターゲットは正しいか（IGW、NAT、TGW、Peering、Endpointなど）
  • 返りの経路は相手側にあるか

この確認は、AWS公式のトラブルシュートでもRoute tableの検証が中心に置かれています。

Route table以外のせいにする前の一言

セキュリティグループやNACLは「道は合っている前提」で初めて効いてきます。Route tableで道が無い状態だと、いくら許可しても届きません。疑う順番として、Route tableを先に見るのは合理的です。

学習の進め方

Route tableは、表を暗記するより「絵にする」と一気に理解が進みます。おすすめは次の流れです。

  • 小さなVPC構成を自分で紙に描く
    • PublicサブネットとPrivateサブネット
    • IGWとNAT
    • それぞれのRoute tableに何が入るか
  • その後、VPC EndpointやPeeringを1つずつ足して、ルートがどう増えるかを観察する

独学で迷いやすい人は、体系的に図解しながら進む教材を1つ持つのが楽です。UdemyにもSAA-C03向けにVPCとネットワークをハンズオン中心に整理してくれる講座が複数あるので、「章立てに沿って手を動かす」用途で使うと相性が良いです。

SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇

SAA-C03対策｜Udemyのおすすめ講座を見る

まとめ

Route tableの疎通不良は、原因がパターン化できます。まずは「サブネットがどのRoute tableを見ているか」を確認し、次に「宛先に一致するルート」と「ターゲットの種類」を点検します。そのうえで、片方向になっていないか、より具体的な経路に負けていないか、Endpointや伝播で想定外の優先関係が発生していないかを追うと、復旧が速くなります。

SAA-C03の学習としても、Route tableは“VPCの読み解き力”そのものです。暗記に寄せるより、構成図とRoute tableをセットで眺めて「この通信はどの行にマッチするか」を言語化できるようにしておくと、関連トピックも一緒に理解しやすくなります。

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