マルチクラウド環境の拡大に伴い、AWS、Azure、GCP、およびオンプレミスデータセンター間を静的ルーティングや個別のIPSec VPNで相互接続する従来の手法は、運用限界を迎えています。ノード数やVPC/VNetの増加に伴うルート情報の肥大化、手動設定によるヒューマンエラー、障害発生時のフェイルオーバー遅延は、システムの可用性を著しく低下させます。本稿では、AWS Transit Gateway（TGW）を中心としたハブ＆スポークトポロジに、動的BGP（Border Gateway Protocol）ルーティングと専用線（Direct Connect、ExpressRoute）を統合し、耐障害性とスケーラビリティを両立するマルチクラウドネットワークアーキテクチャを設計・検証します。
1. マルチクラウドネットワークにおける課題と解決策
A. ネットワーク管理の複雑化
- 課題: クラウドフットプリントの拡大に伴い、AWSの多数のVPCやAzureのVNetにおける個別のルートテーブル管理が断片化します。この「ルーティングのスパゲッティ化」は、中央集中型のポリシー適用やセキュリティ監査、障害発生時の平均復旧時間（MTTR）の長期化を招きます。
- 解決策: ハブ＆スポーク型ネットワークトポロジの導入。AWS Transit Gatewayなどの集中型トランジットハブを活用することで、ルーティングロジックを統合し、クロスプラットフォーム間のトラフィック制御を一元化します。
B. 動的BGPルーティングとトランジットゲートウェイの統合
- 課題: 静的ルーティングではリンク障害に動的に適応できず、トラフィックの迂回に手動介入が必要となり、重大なダウンタイムが発生します。
- 解決策: 動的BGPルーティングとトランジットゲートウェイの統合。BGPにより、マルチクラウド境界を越えたリアルタイムのルート伝播と経路選択が可能になります。AWS TGW、Azure ExpressRoute Gateway、GCP Cloud Router間でBGPセッションを確立することで、最適な経路を動的に学習し、自動パス冗長化と高速なフェイルオーバーを実現します。
C. 専用線接続（Cross-Cloud Direct Connect）の活用
- 課題: パブリックインターネット経由のVPN接続は、インターネットの混雑、パケットロス、ジッター、およびセキュリティ上の脆弱性の影響を受けやすくなります。
- 解決策: コロケーション施設（Equinix、Megaportなど）を介してAWS Direct Connect、Azure ExpressRoute、GCP Dedicated Interconnectを相互にブリッジし、パブリックインターネットを完全にバイパスします。これにより、広帯域（1 Gbps〜100 Gbps）、低遅延、および高いデータプライバシーを確保します。
2. 比較分析: 従来構成（AS-IS） vs. 次世代構成（TO-BE）
| 比較項目 | 従来の静的ルーティング＆VPN（AS-IS） | 現代的なマルチクラウド設計（TO-BE） |
|---|---|---|
| ネットワークトポロジ | 複雑なフルメッシュ接続（VPC間/VNet間）。ノード数増加に伴い管理コストが指数関数的に増大。 | AWS Transit Gateway等のクラウドネイティブハブを中心としたシンプルなハブ＆スポーク構成。 |
| ルーティングの柔軟性 | 静的ルートテーブルの手動更新が必要。リンク障害時の切り替えに遅延が発生。 | 動的BGPルーティングによるリアルタイムの経路計算、ルート伝播、および自動フェイルオーバー。 |
| 帯域幅と通信安定性 | パブリックインターネット経由のIPSec VPNに依存。トラフィック急増時にパケットロスや遅延が発生。 | 専用プライベート回線（Direct Connect / ExpressRoute）により、インターネットをバイパスした安定帯域を確保。 |
| 拡張性（スケーラビリティ） | 新規リージョンやクラウドの追加時に、ネットワークトポロジとセキュリティグループの再設計が必要。 | モジュラー設計。既存のトランジットハブに新しいVPC/VNetをアタッチするだけで、既存通信に影響を与えず拡張可能。 |
3. 技術仕様と実装構成例
オンプレミスまたはコロケーションルータ（FRRouting: FRR）において、AWS Transit GatewayおよびAzure ExpressRouteと動的BGPピアリングを確立するための本番環境仕様の設定例です。
! FRRouting Configuration for Multi-Cloud BGP Peering
router bgp 65001
bgp router-id 192.168.1.1
no bgp default ipv4-unicast
coalesce-time 1000
!
! AWS Transit Gateway Peers
neighbor 169.254.100.1 remote-as 64512
neighbor 169.254.100.1 description AWS-TGW-Primary
neighbor 169.254.100.5 remote-as 64512
neighbor 169.254.100.5 description AWS-TGW-Secondary
!
! Azure ExpressRoute Gateway Peer
neighbor 10.0.0.2 remote-as 12076
neighbor 10.0.0.2 description Azure-ExpressRoute-Gateway
!
address-family ipv4 unicast
network 10.100.0.0/16
!
neighbor 169.254.100.1 activate
neighbor 169.254.100.1 route-map AWS-IN in
neighbor 169.254.100.1 route-map AWS-OUT out
!
neighbor 169.254.100.5 activate
neighbor 169.254.100.5 route-map AWS-IN in
neighbor 169.254.100.5 route-map AWS-OUT out
!
neighbor 10.0.0.2 activate
neighbor 10.0.0.2 route-map AZURE-IN in
neighbor 10.0.0.2 route-map AZURE-OUT out
exit-address-family
!
ip prefix-list LOCAL-SUBNETS permit 10.100.0.0/16
ip prefix-list AWS-ALLOWED-IN permit 172.16.0.0/12 ge 12 le 24
ip prefix-list AZURE-ALLOWED-IN permit 10.200.0.0/16 ge 16 le 24
!
route-map AWS-OUT permit 10
match ip address prefix-list LOCAL-SUBNETS
!
route-map AWS-IN permit 10
match ip address prefix-list AWS-ALLOWED-IN
!
route-map AZURE-OUT permit 10
match ip address prefix-list LOCAL-SUBNETS
set as-path prepend 65001 65001
!
route-map AZURE-IN permit 10
match ip address prefix-list AZURE-ALLOWED-IN
!
4. Troubleshooting
A. BGP ASNの競合と重複
- 事象: マルチクラウド環境でプライベートASN（64512〜65534）を設計する際、異なるクラウドプロバイダーやオンプレミス拠点で同一のASNを重複して割り当ててしまうと、BGPのループ防止機能（AS-Pathによるループ検知）によりルートが拒否され、通信断が発生します。
- 対策: 💡 クラウドおよびオンプレミス全体を網羅する一元的なASN管理台帳を作成し、重複を排除します。AWS TGW（デフォルト: 64512）とオンプレミス（例: 65001）で明確にASNを分離します。
B. ルートリークとルーティングループ
- 事象: AWSから学習したルートを、フィルタリングなしにそのままAzureに再広告（Advertise）してしまうと、クラウド間で意図しないトランジットトラフィックが発生し、回線帯域の逼迫やルーティングループを引き起こします。
- 対策: ⚠️ 境界ルータにおいて、プレフィックスリスト（
prefix-list）およびルートマップ（route-map）を厳格に適用します。自組織が所有するローカルプレフィックスのみを広告し、他クラウドから学習したルートは再広告しないようインバウンド・アウトバウンド双方でフィルタリングを徹底します。
C. 非対称ルーティング（Asymmetric Routing）
- 事象: 送信トラフィックがAWS Direct Connect経由で送信され、返りのトラフィックがAzure ExpressRouteを経由するような非対称ルーティングが発生すると、ステートフルファイアウォールによってパケットが破棄されます。
- 対策: 🛠️ BGPの
AS-Path Prependingを使用して、バックアップ経路のASパス長を意図的に引き伸ばし、優先経路（プライマリパス）を明示的に制御します。また、必要に応じてLocal Preferenceを調整し、送信トラフィックの経路を固定します。
5. 運用検証コマンドとステータス確認
設計した動的BGPルーティングが正常に機能しているか、以下の検証コマンドを用いてステータスを確認します。
BGPネイバー接続状態の確認
# show ip bgp summary
IPv4 Unicast Summary:
BGP router identifier 192.168.1.1, local AS number 65001 vrf default
BGP table version 4
RIB entries 7, using 1344 bytes
Peers 3, using 61 KiB
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt
169.254.100.1 4 64512 1420 1425 0 0 0 23:14:05 5 1
169.254.100.5 4 64512 1418 1422 0 0 0 23:12:10 5 1
10.0.0.2 4 12076 980 985 0 0 0 08:45:12 8 1
学習したBGPルートの確認
# show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP,
B - BGP, O - OSPF, IA - OSPF inter area,
V - VPNv4, NHRP - Next Hop Resolution Protocol
B>* 172.16.0.0/16 [20/0] via 169.254.100.1, eth1, weight 1, 23:14:10
* via 169.254.100.5, eth2, weight 1, 23:12:15
B>* 10.200.0.0/16 [20/0] via 10.0.0.2, eth3, weight 1, 08:45:17
経路追跡による対称性の確認
$ traceroute 172.16.10.100
traceroute to 172.16.10.100 (172.16.10.100), 30 hops max, 60 byte packets
1 192.168.1.254 (192.168.1.254) 0.421 ms 0.388 ms 0.352 ms
2 169.254.100.1 (169.254.100.1) 2.114 ms 2.085 ms 2.051 ms
3 172.16.10.100 (172.16.10.100) 3.452 ms 3.411 ms 3.389 ms
6. Operational Notes
マルチクラウドにおける動的ルーティングの導入は、単に接続性を確保するだけでなく、運用の簡素化と障害復旧の自動化を実現するための基盤です。BGPキープアライブタイマーやホールドタイムの最適化（例: BFD（Bidirectional Forwarding Detection）の併用）を行うことで、物理リンク障害発生時にミリ秒単位での高速フェイルオーバーが可能になります。プレフィックスフィルタリングの標準化とASパス制御を徹底し、予測可能で堅牢なマルチクラウドネットワークを維持することが、インフラ全体の信頼性を担保する鍵となります。