1. はじめに
AWS とオンプレミス／他クラウド環境を接続する際、
Site-to-Site VPN は代表的な接続方式の一つです。
AWS Site-to-Site VPN は標準で：
- 1接続あたり2本のトンネルを提供
- BGPによる動的ルーティング対応
- トンネル単位での冗長設計
といった高可用設計を前提としています。
図:AWS標準的な Site-to-Stite VPN 接続構成のイメージ
しかし、対向環境が Kyndryl Cloud Uplift（旧Skytap、以下KCU） の場合、
AWSの設計思想をそのまま適用できるとは限りません。
本記事では、
AWS Site-to-Site VPN を前提に、
KCU 側の制約下でどこまで冗長構成を設計できるのか
を実検証ベースで整理しました。
本検証の結論としては、
KCU VPNGW の制約下では AWS標準のActive-Active冗長は成立しないが、
設計パターンによって可用性の担保方法は複数存在します。
2. 前提（スコープ）
- AWS側：Site-to-Site VPN（VGW終端）
- ルーティング方式：Static
- KCU側：KCU VPN Gateway（VPNGW）
※ 本記事は 2026年2月時点の公式ドキュメント仕様に基づきます。
3. KCU VPNGW の前提仕様（重要）
AWSと接続する上で、KCU側には以下の制約があります。
3.1. Static Routing のみサポート
- BGP非対応
- 経路自動交換不可
- 経路優先制御機能なし
- 経路制御による自動フェイルオーバー機能なし
3.2. Remote peer IPは1つのみ設定可能
- 設定画面上、Remote peer IP(対向のPeer ip address)は1つしか登録できない
- 複数トンネル同時指定不可
KCU VPNGW 設定画面（Remote peer IP）
3.3. Remote Subnets はVPNGW単位で静的定義
公式ドキュメントに「1アカウントあたり最大10 VPN接続可能」との記載あり
ただし、
- 他VPNGWと経路共有なし
- 同一のRemote Subnets(対向CIDR)を複数VPNGWへ同時設定不可
実際に同一CIDRを別VPNGWへ設定したところエラーとなりました。
エビデンス：CIDR重複設定時エラー画面
例）
KCU VPNGW#1（VPN01）で設定済みの Remote Subnet（10.20.0.0/16）を、
別の KCU VPNGW（VPN02）にも同様に設定した際のエラー画面
AWSとKCUをVPNで接続する際の設計上の整理
以上より、
- AWSの2トンネル冗長を同時活用することはできない
- 同一宛先を両系Active構成で保持することはできない
という設計上の制約があります。
そのため本記事では、Static前提環境において
切替時にどのような挙動となるかを検証し、可用性設計上の判断材料を整理します。
KCUサポートへの確認では、
VPN Gateway サービスは内部的に冗長構成で実装されているとの回答を得ています。
ただし、詳細なアーキテクチャは公開されていないため、可用性特性の評価は公開情報およびSLAに基づき判断する必要があります。
4. 単一VPN(Static)構成の検証
まずは単一VPN構成。
図：単一VPN構成図(検証環境)
4.1 構成概要
AWS 側：
- Site-to-Site VPN
- Customer Gateway（CGW）×1
- VPN Connection（Static）
KCU 側：
- VPNGW ×1
AWS 側の VPN Connection は内部的に 2 本のトンネルを持ちますが、
KCU VPNGW の仕様上、Remote peer IP を 1 つしか設定できないため、
本構成では 実質 1 本のトンネルのみを使用する構成となります。
4.2 検証結果(通常時）
- AWS EC2 ⇔ KCU VM Ping疎通 :OK
- Tunnel Status：UP
- ルート設定：正常
以下の経路図のように、接続自体は問題なくEnd-to-Endの疎通が成立しました。
図:通常時の通信経路図
エビデンス：Ping結果
エビデンス：AWS Tunnel Status(Tunnel 1=Up / Tunnel 2 = Down)
エビデンス：AWS ルートテーブル
エビデンス：KCU VPN 設定（Enable + Remote Subnet）
4.3. 単一VPN構成の設計上の留意点
本構成では、可用性評価の観点から以下を考慮する必要があります。
- AWSトンネル障害 / メンテナンス
- 途中経路障害
- ブラックホール（トンネルUPだが通信不可）
本構成だと自動フェールオーバーが出来ない
点に注意が必要です。
4.4 手動切替検証(Tuunel#2への変更）
前章では、単一VPN構成における設計上の留意点として、
- Static構成では自動フェイルオーバーが存在しないこと
- トンネル状態と実通信の健全性が一致しない可能性があること
を整理しました。
本章ではその続きとして、
利用中トンネル（Tunnel#1）からTunnel#2へ手動切替した場合の実挙動
を確認します。
目的は冗長構成の提示ではなく、
単一VPN構成において、実際にどの程度の操作で復旧できるのか
を把握することです。
4.4.1. 想定シナリオ
以下の状況を想定します。
- AWSより利用中トンネルのメンテナンス通知があった場合
- Tunnel#1 が Down した場合
- トンネルは Up だが通信できない（ブラックホール状態）
単一VPN構成では自動切替は行われないため、
KCU VPNGW の Remote peer IP の設定 を Tunnel#2 に変更することで復旧を試みます。
図:手動切替後の通信経路イメージ
4.4.2. 切替手順（KCU側のみ）
切替操作は KCU側のみで完結 します。
- KCU VPNGW を一時 Disable
- Remote peer IP を Tunnel#2 の Public IP に変更
- KCU VPNGW を Enable
- AWS側トンネル状態を確認
※ AWS側ルートテーブルの変更は不要
※ VPN Connection設定変更も不要
4.4.3. 切替時の挙動
実検証では、以下の挙動を確認しました。
- 手順3の設定変更後、1分程度で Tunnel#2 が UP
- その後、AWS EC2 ⇔ KCU VM の疎通が再開
- AWSルートテーブルの変更は発生しない
切替に伴い一時的な通信断は発生しますが、
操作箇所は限定的であり、手順は比較的シンプルでした。
エビデンス：切替後Ping再開確認
エビデンス：AWS Tunnel Status((Tunnel 1=Down / Tunnel 2 = Up)
4.5 単一VPN構成の設計整理
✔ 単一VPNでも復旧は可能
✔ 操作はKCU側のみ
⚠ 自動ではない（瞬断あり）
本構成は、
「手動復旧が可能なStatic構成」
であることを確認する検証となりました。
5. Azure VPN Gateway中継による構成の検証
ここまでの検証により、単一VPN構成では
- AWSの2トンネルを同時活用できない
- 自動フェイルオーバーは機能しない
- 手動切替が前提となる
ことを確認しました。
一方で、KCU（Kyndryl Cloud Uplift）は、Microsoft Azure のIaaS / PaaS（1st Partyサービス）を基盤として、その上に設計・運用・サポート機能を組み合わせて提供される3rd Partyサービスです。
このため、Azureの各種コンポーネントを標準的に活用でき、高い親和性と一貫性のある構成が可能となります。
Azureネットワーク基盤を活用することで、
- Azure内部での安定したルーティング経路の利用
- BGPによる動的ルーティングの活用
- クラウド間接続のハブ構成の実現
といった設計の選択肢が考えられます。
そこで次の設計パターンとして、
AWSの2トンネル冗長を活かしつつ、KCUのStatic制約と両立する構成
を検証しました。
本アプローチでは、Azure VPN Gateway をルーティングハブとして利用します。
5.1 構成方針
今回の検証環境構成は以下の通りです。
図:Azure VPN Gateway中継構成図
- AWS ⇔ Azure VPN Gateway：BGP接続
- Azure ⇔ KCU VPNGW：Static接続
つまり、
- AWS側はBGPによる動的冗長を利用
- KCU側は従来通りStatic接続
- Azureが中継ハブとしてAWSとKCU間のルーティングを担う
というハイブリッド構成となります。
5.2 検証目的
本検証の目的は以下の通りです。
- AWSの2トンネル＋BGP構成がAzure経由で成立するか
- Azureを中継したEnd-to-End通信が可能か
- Static区間（Azure ⇔ KCU）を含んでもルーティングが成立するか
単なる疎通確認ではなく、
単一VPN構成の制約を補完する設計パターンとなり得るか
を確認することを目的とします。
5.3 検証結果
✔ E2E疎通確認
AWS EC2 から KCU VM への Ping が成功。
Azure VPN Gateway を経由した通信が成立しました。
✔ Azure側ルートテーブル確認
Azure VPN Gateway の有効ルートに、
- AWS VPC CIDR (10.20.0.0/16)
- KCU 側 CIDR (10.150.0.0/16)
の双方が存在することを確認しました。
Azureが中継点として正しくルーティングしていることが確認できます。
KCU側CIDERがIBgpで受け取ってるように見えますが表示上の問題のようで、
KCU VPNGWとのルーティング接続はStatic設定となっています。
✔ AWS側ルートテーブル確認
AWS側ルートテーブルにおいて、
- KCU側ネットワークがVPN経由で到達可能
であることを確認しました。
5.4 Azure VPN Gateway中継構成の設計上の整理
本構成により、
- AWS側はBGPによる2トンネル冗長を活用可能
- Azureがルーティングハブとして機能
- KCU側はStatic制約のまま接続可能
- Azure VPN GatewayをActive-Standby構成で払い出すことで、対向（KCU）から見た固定IPを1つに集約可能
- Azure側でインスタンス障害や計画メンテナンスが発生しても、自動フェイルオーバーによりKCU側での手動切替は不要
という設計が成立することを確認しました。
単一VPNでKCUとAWSを直接接続する場合、
障害・メンテナンス時には対向IPの切替など運用対応が必要となります。
一方、本構成ではAzure側で冗長性を吸収できるため、
運用負荷を抑えつつ可用性を向上させる構成といえます。
※ フェイルオーバー時には短時間の通信断が発生する可能性があります。
※ Active-Active構成を選択した場合はPublic IPが複数となるため、固定IP集約を目的とする場合は構成選択に注意が必要です。
6. まとめ
AWS Site-to-Site VPN は本来、
- 2トンネル構成
- BGPによる動的冗長
を前提としたサービスです。
しかし KCU VPNGW の仕様上、
- Remote peer IP は1つのみ
- Static接続のみ対応
という制約があります。
本記事では、これらの制約下で
- 単一VPN構成における手動切替の挙動
- Azure VPN Gateway中継によるハイブリッド構成
を検証しました。
単一VPN構成
- 手動切替により復旧可能
- 構成はシンプル
- 可用性は運用に依存
Azure中継構成
- AWS側のBGP冗長を活用可能
- 設計自由度が向上
- 構成は複雑化
可用性は「構成」だけでは決まらない。
要件・SLA・リージョン設計を含めた 全体設計によって決まります。
より高可用性を求める場合は、
- AWS Direct Connect
- KCU PNC（Private Network Connect）
といった専用線+BGPという選択肢も検討対象となります。
さいごに
本記事は、KCU VPNGWの制約下における
AWS Site-to-Site VPN設計の一例を整理したものです。
今後仕様変更や新たな設計パターンが確認できた場合は、
随時アップデートしていきます。
同様の構成を検討されている方の参考になれば幸いです。