はじめに
概要
本資料は、AWS環境での「ルーティング」について分かりやすくまとめた入門資料です。ネットワークがどの経路を通って通信するかを決める仕組みを、図や具体例を交えて解説します。
本資料の目的
- AWSのルーティングの基本を理解してもらうこと
- VPC内での実践的なルート設計の考え方を示すこと
- DNS（Amazon Route 53）による名前解決のルーティングを紹介すること
- SaaS型サービスでのテナントごとの経路設計の注意点を整理すること
想定読者
クラウド初心者〜中級者を想定します。ネットワークの全体像を知りたい方、実運用での設計に役立てたい方に向けています。専門用語は最小限にし、具体例で補足します。
本資料の構成と読み方
全5章で構成します。第2章は概念、第3章はVPCでの設計、第4章はDNS、第5章はSaaS向け戦略です。まず第2章の基礎から読み進めると理解が早まります。各章に実践例を載せますので、ご自身の環境に当てはめて考えてください。
AWSにおけるルーティングの基本概念
はじめに
AWSのルーティングは、ネットワークがどこへパケットを送るかを決める仕組みです。ここでは概念をやさしく説明します。
RIB（ルーティング情報ベース）とFIB（転送情報ベース）
RIBはルートの候補リストを集めて保管します。FIBは実際に転送に使う最終決定版です。例えると、RIBが地図帳でFIBがナビのルートです。FIBがあればパケットは高速に転送できます。
ルートの種類と優先順位
AWSには主に3種類のルートがあります。
– Static Route（手動設定）: 管理者が明示的に作ります。最も優先します。
– Propagated Route（自動伝播）: VPNやDirect Connectなどから自動で伝わります。静的より低く設定されます。
– Dynamic Route（動的学習）: BGPなどで学習するルートです。優先度は最も低いです。
優先順位はStatic > Propagated > Dynamicです。したがって同じ宛先が複数ある場合、上位のルートが選ばれます。
具体例
社内ネットワークへVPNと手動ルートがある場合、手動で設定したStaticが使われます。逆に新しい経路を自動で受け取りたいときはPropagatedやDynamicを使います。
注意点
ルートの重複や優先度を誤ると通信が途切れます。設計時はどの経路を優先するかを明確にしてください。
ルートテーブルとVPC内のルーティング設計
概要
VPC内では複数のルートテーブルを使い分けて通信経路を制御します。メイン（デフォルト）ルートテーブルに加え、サブネットごとにカスタムルートを割り当てることで柔軟に設計できます。
ルートテーブルの種類と使い分け
- メインルートテーブル：VPC全体のデフォルト経路を持ちます。新しいサブネットは特に指定しなければここに属します。
- カスタムルートテーブル：特定サブネットに別の経路（例：オンプレ接続、別VPCの経路）を割り当てます。
- ゲートウェイ関連ルート：インターネットゲートウェイや仮想プライベートゲートウェイ用の経路を設定します。
優先度：ロンゲストマッチ（最長一致）
ルートの選択は宛先のプレフィックス長が長いものを優先します。例えば0.0.0.0/0よりも10.0.1.0/24のルートが優先されます。これを意識して広いルートと狭いルートを混在させます。
サブネット設計の具体例
- パブリックサブネット：0.0.0.0/0をインターネットゲートウェイへ。ELBや公開サーバー用。
- プライベートサブネット：NATゲートウェイ経由でアウトバウンド通信を許可。直接インターネット経路は設定しません。
- VPN/オンプレ接続：仮想プライベートゲートウェイを使い、該当サブネットに専用ルートを割当てます。
ピアリングや経路伝播
VPCピアリングやTransit Gatewayを使う場合、ピア先へ向かうルートを明示的に追加します。自動伝播（propagation）を使うとVPN接続の経路を動的に反映できます。
運用上の注意点
- ルートは冪等性を保ち、変更は段階的に行ってテストしてください。
- ネーミングとタグ付けで管理を楽にします。
- 最小権限で変更を行い、影響範囲を把握した上で適用してください。
設計時は可視化図を作り、どのサブネットがどのルートを参照するかを明確にしてから実装すると安心です。
Amazon Route 53によるDNSルーティング
Route 53とは
Amazon Route 53はドメイン名とIPアドレスを結びつけるDNSサービスです。ホストゾーンを作成してドメインを管理できます。パブリックな名前解決だけでなく、VPC向けのプライベートホストゾーンも作れます。例えば社内システムはプライベートゾーンでのみ名前解決します。
主なルーティングポリシーと使いどころ
- シンプル: 単一のエンドポイント向けです。小規模サイトでまず使います。
- フェイルオーバー: 正常なプライマリが応答しない時にセカンダリへ切り替えます。ヘルスチェックを設定して自動復旧を実現します。
- レイテンシー: ユーザーから見て応答が速いリージョンへ振り分けます。グローバルに分散したサービスで有効です。
- IPベース: クライアントのIPやCIDRに応じて振り分けます。特定ネットワークからのトラフィックだけ別ルートにしたい場合に役立ちます。
実務のポイント
- エイリアスレコードでALBやCloudFrontへ直接向けられます。例えば「www.example.com」をALBに向けるときに便利です。
- フェイルオーバー時はヘルスチェックを必ず設定してください。誤検知で切り替わるのを防げます。
- プライベートホストゾーンをVPCに関連付けると、内部向け名前解決を簡潔に管理できます。
実際の設計では目的に応じてポリシーを組み合わせ、運用しやすさと可用性を両立させることを心掛けてください。
SaaS環境でのテナントルーティング戦略
背景と目的
SaaSでは複数の顧客（テナント）を同じサービスで運用します。目的は「正しいテナントへ確実にトラフィックを届けること」と「運用やセキュリティを簡潔に保つこと」です。具体例として、顧客Aにはa.example.com、顧客Bにはb.example.comを割り当てる方法があります。
ドメイン駆動型ルーティング
サブドメインでテナントを区別します。Route 53のワイルドカードレコード（例: *.example.com）と、ALBのリスナールールで振り分けると運用が楽です。メリットは証明書管理やアクセス制御が分かりやすい点です。短所はサブドメインが増えるとDNSや証明書設定の運用が増えることです。
データ駆動型ルーティング
単一ドメインでHTTPヘッダやURLパラメータを見て振り分けます。例えばリクエストヘッダのX-Tenant-IDやJWT内のテナント情報で判断します。メリットはドメイン数を減らせる点です。短所はアプリ側での判定コードや認証の厳格化が必要になる点です。
運用とセキュリティのポイント
・認証情報は必ず署名や暗号で保護してください。例: JWTの検証。
・ログはテナント単位で分けて保管し、監査を行いやすくします。
・ネットワークの分離が必要なテナントはVPCやサブネットで物理的に分ける検討をしてください。
設計の勧め（例）
小規模やシンプル運用ならドメイン駆動型を推奨します。大規模でサブドメイン運用が難しい場合はデータ駆動型とし、認証・ログ・レート制御を強化してください。どちらを選ぶにしても、テナント識別の一貫性を保つことが最も重要です。
