クラウドネットワーク デフォルトルート
クラウドネットワークにおける2つの主要なルーティングパターン
はじめに
パブリッククラウドのプライベートネットワークにおけるデフォルトルートの設計についての考察。
ハイブリッドクラウド環境におけるインターネット向けの通信経路には、大きく分けて2つのパターンが存在します。
パターン1：オンプレミス集中型（ヘアピン型）
クラウド上の仮想ネットワークからの通信（インターネット向けを含む全て）を、一旦オンプレミスのネットワークに引き込んでから、オンプレミスのインターネット回線やファイアウォールを経由して外部に出ていく構成です。
この場合、クラウド側のデフォルトルート(0.0.0.0/0)は、オンプレミスに接続するためのゲートウェイ（VPNゲートウェイやDirect Connect/ExpressRouteのゲートウェイなど）に向けられます。
[Cloud VM] -> [VPN/専用線GW] -> [オンプレミスFW] -> [インターネット]パターン2：クラウドネイティブ・ハイブリッド型（分割型）
インターネット向けの通信はクラウドのネットワーク内で完結させ、オンプレミスとの通信のみを専用線やVPN経由で行う構成です。
この場合、デフォルトルート(0.0.0.0/0)はクラウドのインターネットゲートウェイに向け、オンプレミスのネットワークセグメント（例：10.0.0.0/8）宛のルートを、オンプレミス接続用のゲートウェイに個別で設定します。
[Cloud VM] --(0.0.0.0/0)--> [クラウドのInternet GW] -> [インターネット]
|
--(10.0.0.0/8)--> [VPN/専用線GW] -> [オンプレミス]パターン2（分割型）が推奨される理由
パターン1にもメリットはありますが、多くの点でパターン2が優れています。
| 項目 | パターン1：オンプレミス集中型 | パターン2：クラウドネイティブ型（推奨） |
|---|---|---|
| パフォーマンス | 悪い。 インターネット通信がオンプレミスを経由するため、無駄な往復（ヘアピン）が発生し遅延が増大する。 | 良い。 クラウドからインターネットへ最短経路で通信するため、低遅延。 |
| 帯域 | ボトルネックになりやすい。 オンプレミス接続回線の帯域を、インターネット通信とオンプレミス通信で共有するため、逼迫しやすい。 | 広帯域・スケーラブル。 クラウドの広大なバックボーンを利用でき、帯域の心配が少ない。 |
| コスト | 高くなる傾向。 クラウドからオンプレミスへのデータ転送量（Egress）と、オンプレミスのインターネット回線コストの両方がかかる。 | 最適化しやすい。 クラウドから直接インターネットへのデータ転送コストのみで済むことが多い。 |
| 可用性・耐障害性 | 低い。 オンプレミス接続回線やオンプレミスFWが単一障害点となり、ここが故障するとクラウドのインターネット通信も不通になる。 | 高い。 オンプレミス回線が故障しても、クラウド側のインターネット通信には影響がない。 |
| セキュリティ | 管理が集中。 既存のオンプレミスセキュリティ機器（FW, Proxy, IDS/IPS）を流用でき、ポリシー適用を一元化しやすい。（これが選択される最大の理由） | 分散管理が必要。 クラウドネイティブのセキュリティ機能（セキュリティグループ, ネットワークFW等）の活用が必須。管理が分散するが、クラウドに最適化された保護が可能。 |
| 運用 | 従来の運用モデルを踏襲しやすい。 | クラウドネイティブな運用スキルや考え方が必要。 |
このように、パフォーマンス、コスト、可用性の観点から、パターン2が圧倒的に有利です。
パターン1が選択される主な理由は、既存のセキュリティ投資やコンプライアンス要件により、全ての通信をオンプレミスの監査ポイントを通過させなければならない、という組織的な制約がある場合に限られます。
各クラウドサービスにおける「正解」の実装
各クラウドでも、パターン2（分割型）を前提としたサービスや機能が提供されています。
AWS (Amazon Web Services)
- コンポーネント:
- VPCルートテーブル
- インターネットゲートウェイ(IGW)
- 仮想プライベートゲートウェイ(VGW) or トランジットゲートウェイ(TGW)
- 設定方法:
- VPCにインターネットゲートウェイ(IGW)をアタッチします。
- サブネットのルートテーブルで、送信先 0.0.0.0/0 のターゲットを IGW に設定します。
- オンプレミス接続に VGW や TGW を使用し、同じルートテーブルで、オンプレミスのCIDR（例: 10.0.0.0/8）のターゲットを VGW/TGW に設定します。
考察:
AWSの最も標準的な構成です。セキュリティを強化したい場合は、IGWへのルートを持つサブネットを「パブリックサブネット」、持たないサブネットを「プライベートサブネット」とし、NATゲートウェイを経由させる構成が一般的です。
Microsoft Azure
- コンポーネント:
- 仮想ネットワーク(VNet), ルートテーブル(UDR: User Defined Route), 仮想ネットワークゲートウェイ
- 設定方法:
- AzureはデフォルトでVNet内のリソースがインターネットにアクセスできます（暗黙的なルート）。
- より明示的に制御するためにルートテーブルを作成し、サブネットに適用します。
- ルートテーブルに、アドレスプレフィックス 0.0.0.0/0 の「次ホップの種類」を インターネット に設定したルートを追加します。
- オンプレミス接続用の仮想ネットワークゲートウェイを作成し、ルートテーブルにオンプレミスのCIDR（例: 10.0.0.0/8）の「次ホップの種類」を 仮想ネットワークゲートウェイ に設定したルートを追加します。
考察:
AzureではUDRを使うことで、トラフィックフローを柔軟に制御できます。セキュリティ強化のために、次ホップをAzure Firewallに設定し、そこで通信を検査する「ハブ＆スポーク」構成もベストプラクティスとされています。
Google Cloud
- コンポーネント:
- VPCネットワーク
- ルート
- Cloud VPN / Cloud Interconnect
- 設定方法:
- Google CloudのVPCは、デフォルトでデフォルトインターネットゲートウェイへのルート（宛先: 0.0.0.0/0, ネクストホップ: デフォルトインターネットゲートウェイ）を持っています。
- Cloud VPN や Cloud Interconnect を設定すると、オンプレミスのCIDRへのルートがBGP経由で動的に、または静的に追加されます。
- 結果として、インターネット向けとオンプレミス向けのルートが自動的に共存する形になります。
考察:
GCPはグローバルVPCという特徴があり、ルーティングもシンプルに構成できます。ファイアウォールルールと組み合わせることで、きめ細やかなアクセス制御を実現します。
OCI (Oracle Cloud Infrastructure)
- コンポーネント:
- VCN (仮想クラウド・ネットワーク)
- ルート表
- インターネット・ゲートウェイ
- DRG (動的ルーティング・ゲートウェイ)
- 設定方法:
- VCNにインターネット・ゲートウェイを作成し、アタッチします。
- サブネットのルート表に、宛先CIDRブロック 0.0.0.0/0 のターゲットとしてインターネット・ゲートウェイを指定したルールを追加します。
- オンプレミス接続用の DRG をVCNにアタッチし、同じルート表に、オンプレミスのCIDR（例: 10.0.0.0/8）のターゲットとして DRG を指定したルールを追加します。
考察:
OCIも他のクラウドと同様のコンポーネントで構成します。DRGはハブ＆スポーク構成の中心としても機能し、スケーラブルなネットワーク設計が可能です。
まとめ
どの主要パブリッククラウドにおいても、デフォルトルート(0.0.0.0/0)はクラウドが提供するインターネット接続機能（IGWなど）に向け、オンプレミスや他のネットワークへの通信はより具体的な静的/動的ルートで専用のゲートウェイ（VGW, DRGなど）に向ける「分割型」のアーキテクチャが、技術的な正解であり、推奨されるベストプラクティスです。
「通信を全てオンプレミスに向ける」という構成は、過渡的な構成、あるいは非常に強いセキュリティ統制要件がある場合の例外的な構成と捉えるのが良いでしょう。クラウドのメリットを最大限に引き出すためには、ぜひ「分割型」の構成を基本として設計を進めることをお勧めします。
ショップ リンク – SHOP LINK –
コメントを残す コメントをキャンセル