AWS Site-to-Site VPN：静的ルーティングからBGP動的ルーティングへの無停止移行ガイド

概要

AWS Site-to-Site VPNの静的ルーティングからBGP動的ルーティングへの移行は、既存接続の設定変更では実現できません。新規BGP接続を並行稼働させて段階的にカットオーバーする手順を、実践的な視点で解説します。

目次

1. なぜ既存VPNの設定変更ができないのか
2. BGP動的ルーティング移行のメリット
3. 移行前の前提条件確認
4. 無停止移行の具体的手順
5. 注意点とベストプラクティス
6. 料金への影響
7. 終わりに

1. なぜ既存VPNの設定変更ができないのか

AWS Site-to-Site VPNでは、ルーティングタイプ（静的/動的）は作成時に決定され、後から変更することができません。AWS公式ドキュメント ( https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html ) では『If you select the option to use BGP advertisement, then you cannot specify static routes.』と説明されています。

この制約により、静的ルーティングから動的ルーティングへの移行には、新しいVPN接続を作成して並行稼働させる方式を取る必要があります。たとえるなら、古い橋の構造を変更するのではなく、新しい橋を隣に建設してから徐々に交通を切り替えるようなイメージです。

主な理由

• VPN接続のルーティング方式はVPN接続リソースの基本属性として定義されており、作成後の変更に対応していない
• 静的ルートとBGPでは、経路情報の管理方式が根本的に異なる（手動設定 vs 自動学習）
• トンネルパラメータの一部は変更可能だが、ルーティングタイプは対象外

2. BGP動的ルーティング移行のメリット

BGPへの移行により得られる主なメリットは以下のとおりです。

運用負荷の大幅削減

静的ルーティングでは、オンプレミス拠点で新しいサブネットを追加するたびに、AWSマネジメントコンソールまたはCLIからTransit Gatewayのルートテーブルに静的ルートを手動追加する必要があります。BGPを使用すれば、拠点側のルーターが新しいサブネットをBGP経由で自動的にアドバタイズするため、AWS側での手動操作が不要になります。

経路の自動学習と伝播

Transit GatewayはBGPで受信した経路を自動的に学習し、ルートテーブルに伝播します。この機能により、拠点の増設やネットワーク構成変更時の設定作業が最小限に抑えられます。

高度なトラフィック制御

AWS公式ドキュメント ( https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-site-to-site-vpn.html ) では『With dynamic routing, you can also specify routing priorities, policies, and weights (metrics) in your BGP advertisements and influence the network path between your networks and AWS.』と説明されているように、BGPアトリビュート（AS-PATH、MED、コミュニティなど）を活用して、柔軟なトラフィックエンジニアリングが可能になります。

3. 移行前の前提条件確認

移行を開始する前に、以下の項目を確認してください。

拠点側CPEの対応状況

確認項目	詳細
BGP対応	ルーターがBGPプロトコルをサポートしているか
ASN設定	BGP ASNを割り当て可能か（Transit GatewayのASNと重複しないこと）
ルートベースVPN	ポリシーベースではなくルートベースVPNに対応しているか
IKEバージョン	IKEv2対応が推奨（IKEv1も利用可能だが非推奨）

ASNの選定

• Transit Gatewayには64512-65534の範囲でプライベートASNを割り当てる（デフォルトは64512）
• Customer GatewayにもプライベートASNを割り当てる（Transit GatewayのASNと異なる値）
• 例：Transit Gateway ASN=64512、Customer Gateway ASN=65001

ルーティング設計の確認

現在の静的ルート設定を確認し、BGP移行後にどの経路を広告するかを事前に計画します。特に、オンプレミス側から広告するサブネットの範囲と、AWS側から広告する範囲を明確にしておきます。

4. 無停止移行の具体的手順

ステップ1：新しいCustomer Gatewayの作成

BGP ASNを含むCustomer Gatewayを作成します。既存の静的VPN接続で使用しているCustomer Gatewayを流用することもできますが、BGP ASNが設定されていない場合は新規作成が必要です。

# AWS CLI v2での作成例（ap-northeast-1リージョン）
aws ec2 create-customer-gateway \
  --type ipsec.1 \
  --public-ip 203.0.113.10 \
  --bgp-asn 65001 \
  --region ap-northeast-1

ステップ2：新しいSite-to-Site VPN接続の作成（動的/BGP）

Transit Gateway向けに新しいVPN接続を作成します。ルーティングオプションとして「Dynamic（requires BGP）」を選択します。

# AWS CLI v2での作成例
aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-0a1b2c3d4e5f6g7h8 \
  --transit-gateway-id tgw-0a1b2c3d4e5f6g7h8 \
  --options '{"StaticRoutesOnly":false}' \
  --region ap-northeast-1

VPN接続が作成されると、自動的に2本のIPsecトンネルが構成されます。

ステップ3：CPE側の設定投入

AWSマネジメントコンソールからVPN設定ファイルをダウンロードし、CPE（顧客側VPNルーター）に設定を投入します。

主な設定内容：

• IPsecトンネルパラメータ（Pre-Shared Key、暗号化アルゴリズム、DH Group等）
• BGPピア設定（ローカルASN、リモートASN、ネイバーIPアドレス）
• トンネルインターフェース設定（169.254.x.x/30の範囲）

設定投入後、BGPセッションが確立し、2本のトンネルがともにUP状態になることを確認します。

ステップ4：Transit Gatewayルートテーブルの設定

新しいVPNアタッチメントに対して、経路伝播（Route Propagation）を有効化します。

# 経路伝播の有効化
aws ec2 enable-transit-gateway-route-table-propagation \
  --transit-gateway-route-table-id tgw-rtb-0a1b2c3d4e5f6g7h8 \
  --transit-gateway-attachment-id tgw-attach-0a1b2c3d4e5f6g7h8 \
  --region ap-northeast-1

この設定により、CPE側からBGPで広告された経路がTransit Gatewayのルートテーブルに自動的に伝播されます。VPCアタッチメントが関連付けられているルートテーブルにも経路が反映されることを確認してください。

ステップ5：段階的カットオーバー

ここが移行の核心部分です。無停止で切り替えるために、以下のアプローチを取ります。

テスト段階：より長いプレフィックスでの検証

Transit Gatewayは最長一致ルーティングを採用しているため、CPE側から既存の静的ルートよりも長いプレフィックス（より具体的なサブネット）をBGP広告することで、新しいVPN経路の動作を検証できます。

例：

• 既存静的ルート：172.16.0.0/16
• BGPテスト広告：172.16.1.0/24（より長いプレフィックス）

この状態で、172.16.1.0/24宛ての通信が新しいBGP VPN経由でルーティングされることを確認します。

本番カットオーバー：静的ルートの削除

テストが成功したら、Transit Gatewayルートテーブルから該当する静的ルートを順次削除します。静的ルートが削除されると、BGP経由で学習した経路が有効になります。

# 静的ルートの削除
aws ec2 delete-transit-gateway-route \
  --transit-gateway-route-table-id tgw-rtb-0a1b2c3d4e5f6g7h8 \
  --destination-cidr-block 172.16.0.0/16 \
  --region ap-northeast-1

重要：AWS公式ドキュメント ( https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html ) によると『Statically assigned routes are preferred over BGP advertised routes in cases where identical routes exist in the virtual private gateway.』と説明されているように、同一プレフィックスでは静的ルートがBGPルートより優先されます。そのため、カットオーバー時は静的ルートの削除が必要です。

双方向疎通の確認

• AWS側からオンプレミス側への通信
• オンプレミス側からAWS側への通信
• 2本のトンネルでのフェイルオーバー動作

すべての通信が正常に行われることを確認します。

ステップ6：監視とクリーンアップ

移行後、以下の項目を監視します。

• BGPセッションの安定性（アップタイム、フラップ回数）
• 経路数の一致（期待する経路がすべて伝播されているか）
• トラフィックパターン（想定通りの経路を通っているか）
• トンネルのフェイルオーバー（片側トンネルがダウンした際の切り替わり）

1週間程度安定稼働を確認できたら、旧静的VPN接続とそれに関連するリソースを削除します。

5. 注意点とベストプラクティス

経路優先度の理解

Transit Gatewayの経路評価順序は以下のとおりです（AWS公式ドキュメント ( https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html ) より）：

1. 最長一致プレフィックス
2. アタッチメントタイプ（同一プレフィックスの場合、静的ルート > BGPルート）
3. BGPアトリビュート（AS-PATH長、MED、Local Preference等）

この順序を理解しておくことで、カットオーバー時の挙動を正確に予測できます。

BGP経路数の上限

Transit Gateway VPNアタッチメントには、BGP経路数の上限があります。大量の経路を広告する場合は、サマリゼーション（経路集約）を検討してください。

BGP MD5認証は非サポート

AWS Site-to-Site VPNのBGPセッションでは、MD5認証がサポートされていません。CPE側でBGP MD5認証を要求する設定がある場合は、事前に無効化しておく必要があります。

DPD（Dead Peer Detection）の有効化

IPsecトンネルの安定性を向上させるため、DPDを有効化することを推奨します。AWSのデフォルトDPD設定は10秒です。

CPEがBGP非対応の場合の対処

もしCPEがBGP非対応の場合、以下の選択肢があります。

• BGP対応ルーターへの機器更新
• SD-WANソリューションの採用（Transit Gateway Connectとの組み合わせ）
• アドレス設計の見直しによる静的ルートの集約（暫定対応）

6. 料金への影響

移行期間中は、既存静的VPNと新規BGP VPNの両方が稼働するため、一時的に料金が増加します。

東京リージョン（ap-northeast-1）の料金（2025年1月時点）

項目	料金
Site-to-Site VPN接続	$0.048/時間
Transit Gateway VPNアタッチメント	$0.05/時間
Transit Gatewayデータ処理	$0.02/GB

移行期間中（両VPN稼働時）の追加コスト例：

• 移行作業期間を1週間と想定
• VPN接続料金：$0.048 × 24時間 × 7日 = 約$8.06
• TGWアタッチメント料金：$0.05 × 24時間 × 7日 = 約$8.40
• 合計約$16.46の一時的な追加コスト

なお、料金は変動する可能性があります。最新情報はAWS公式料金ページ ( https://aws.amazon.com/vpn/pricing/ ) をご確認ください。

データ転送料金については、最初の100GBが無料で、以降は$0.09/GB（東京リージョン）が適用されます。

7. 終わりに

AWS Site-to-Site VPNの静的ルーティングからBGP動的ルーティングへの移行は、既存接続の単純な設定変更では実現できませんが、新規BGP接続を並行稼働させる方式により、ほぼ無停止での移行が可能です。

本記事で紹介した手順のポイントは以下のとおりです。

• 新しいBGP対応VPN接続を作成して並行稼働
• より長いプレフィックスでのテスト実施
• 静的ルートを順次削除してBGP経路を有効化
• 十分な監視期間を設けてから旧VPNを削除

BGP移行後は、新拠点追加時のルート設定作業がほぼゼロになり、運用負荷が大幅に軽減されます。特に複数拠点を持つ企業や、拠点の増減が頻繁にある環境では、BGP動的ルーティングの採用により、ネットワーク運用の効率化とヒューマンエラーの削減が期待できます。

次のステップとしては、BGPコミュニティやAS-PATH Prependを活用した高度なトラフィック制御の検討や、ECMP（Equal Cost Multi-Path）による複数VPN接続での帯域拡張なども視野に入れると良いでしょう。

参考文献・参考サイト

• 「AWS Site-to-Site VPN routing options」AWS Documentation, https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html
• 「Static and dynamic routing in AWS Site-to-Site VPN」AWS Documentation, https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-static-dynamic.html
• 「How AWS Transit Gateway works」AWS Documentation, https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html
• 「Create a transit gateway AWS Site-to-Site VPN attachment」AWS Documentation, https://docs.aws.amazon.com/vpn/latest/s2svpn/create-tgw-vpn-attachment.html
• 「AWS Transit Gateway + AWS Site-to-Site VPN」AWS Documentation, https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-transit-gateway-vpn.html
• 「AWS VPN Pricing」AWS, https://aws.amazon.com/vpn/pricing/
• 「Modify the target gateway of an AWS Site-to-Site VPN connection」AWS Documentation, https://docs.aws.amazon.com/vpn/latest/s2svpn/modify-vpn-target.html