セキュリティサービス部 佐竹です。
最近、AWS Direct Connect (DX) において、実務で役立つ興味深いアップデートが2つ発表されましたので、それらをまとめてお届けしたいと思います。
はじめに
「AWS Direct Connect」は AWS 利用者に専用線接続を提供するサービスで、2012年1月12日に日本国内でも提供が開始されています。
DX の専用線接続はそもそも Amazon VPC に直結するものでした。そしてこの VPC サービスが全世界的に提供開始されたのが2011年8月です。ですので、VPC がサービスとして提供されはじめてから、半年程度で VPC に専用線接続ができるようになったわけです。
そのような長い歴史を持つ Direct Connect (DX) ですが、2026年3月末～4月初旬に連続して2つのアップデートがありました。それぞれを以下で紹介していきます。
DX が BGPモニタリング用の CloudWatch メトリクスを追加
2026年3月30日（日本時間では3月31日）発表です。
以下要点を箇条書きします。
- AWS Direct Connect が BGP セッション監視用の3つの新しい CloudWatch メトリクスを提供開始
VirtualInterfaceBgpStatus、VirtualInterfaceBgpPrefixesAccepted、VirtualInterfaceBgpPrefixesAdvertisedの3つのメトリクスが利用可能に- カスタムソリューションや Lambda 関数なしで BGP セッションの監視が可能となるアップデート
このアップデートを学ぶためのこれまでの技術的背景
DX の運用監視には、BGP セッションの監視が重要になってきます。
しかしそのためには、2024年5月末に投稿された以下の AWS 公式ブログに詳しく記載のある実装対応が必要でした。
上記ブログをざっくりまとめると以下のようになります。
- API Call による情報の能動的な取得が必要。具体的には
DescribeVirtualInterfacesAPI を定期的に実行し、仮想インターフェース（VIF）の BGP ピア状態などの詳細情報を手動で取得する必要がある - 自動化は Lambda と EventBridge の組み合わせが推奨される。先の API を、Amazon EventBridge をトリガーとして定期的に Lambda から実行し、監視し続ける
- 取得した BGP 状態の変化やプレフィックス数の閾値超過を判別し、SNS を介してメール等でアラートを飛ばすロジックを個別に実装する必要がある
正直、この実装をして保守するのはなかなかに手間です。
ですが、本アップデートにより、上記仕組みは不要になります。CW メトリクスを確認すれば良いという世界にやっとなりました。
Monitor with Amazon CloudWatch
では追加された3つのメトリクスを掘り下げてみましょう。
公式ドキュメントに追記された内容に基づき、今回追加された3つのメトリクスについてそれぞれ解説します。
VirtualInterfaceBgpStatus：
VIF の BGP ピアリングセッションのステータスを表します。値として1が UP を、0が DOWN を示します。
おそらく、これが最も待ち望まれていたメトリクスでしょう。「値が0になったら CloudWatch Alarm を発報して、SNS や EventBridge 経由で Slack に通知する」という死活監視が可能になります*1。VirtualInterfaceBgpPrefixesAccepted：
オンプレミス側の BGP ピアから受け取った（AWS 側が Accept した）BGP プレフィックスの数です。VirtualInterfaceBgpPrefixesAdvertised：
オンプレミス側の BGP ピアに対して広報した（AWS 側から Advertise した）BGP プレフィックスの数です。
経路数上限「100」による突然死予防
インフラ運用上、特に大きな意味を持つのが VirtualInterfaceBgpPrefixesAccepted です。これは先に記述した「プレフィックス数の閾値超過を判別」を行うメトリクスです。
DX のプライベート VIF やトランジット VIF では、オンプレミスから AWS への広報経路数に「IPv4/IPv6 それぞれ100経路まで」という厳格な上限が存在します。これを超過すると、BGP セッションが強制的に Down 状態に陥り、通信が突然に全遮断されます。
プライベート仮想インターフェイス、またはオンプレミスから AWS へのトランジット仮想インターフェイスでのボーダーゲートウェイプロトコル (BGP) セッションあたりのルート数
BGP セッションで IPv4 と IPv6 にそれぞれ 100 を超えるルートをアドバタイズする場合、BGP セッションはアイドル状態になり BGP セッションが DOWN になります。
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/limits.html)
これまでは、この VIF の経路数があとどれくらいで上限に達するのかを監視し、危険水域でアラートを上げるためには、先述の通り Lambda を作り込むという手間がかかっていました。
しかし今後は、この VirtualInterfaceBgpPrefixesAccepted メトリクスに対して「80」や「90」といった閾値で CloudWatch アラームを仕掛けておくだけで済みます*2。
本アップデートにより、経路溢れによる大事故をシンプルかつ確実に未然に防ぐことができるようになり、さらに Lambda の定期実行によるインターバル遅延の心配もなくなります。
DX の運用監視をはじめるにあたり、まずこれらの CW メトリクスの監視を検討するという方向性が、今後はベストプラクティスの1つとなりそうです。
実際に CW メトリクスの画面を確認してみた
VirtualInterfaceBgpPrefixesAccepted を確認してみました。
グラフから「9」のBGP Prefix が Accepted されていることがわかります。表示は「最大」かつ「1分」に変更しています。
また本メトリクスは、機能が提供開始となった3月末頃から値が取得できており、それ以前の値は欠損しています。
ちなみに、VirtualInterfaceBgpStatus を確認したところ、今月半ばに、リリースよりも古いメトリクスが存在していました。
どうやら、ステータス「Down」になったタイミングだけ VirtualInterfaceBgpStatus が記録されているようでした。参考まで。
参考: AWS Direct Connect adds CloudWatch metrics for BGP monitoring
DX が AWS CloudFormation をサポート開始
News の発表日付は「2026年3月31日」ですが、日本時間では4月2日での発表です。
以下要点を箇条書きします。
- AWS Direct Connect が AWS CloudFormation サポートを開始
- CloudFormation テンプレートで Direct Connect トポロジー全体を定義可能
- 接続、仮想インターフェース、DXGW、Link Aggregation Group、BGP ピアリング設定の自動化を実現
何が嬉しいのか？
CFn を利用する最大のメリットは、やはり「冪等性」でしょう。
といっても、我々のようなクラウドインテグレーターでは、DX の敷設作業はたった1回で終わることが多いと感じます。そのため、マネジメントコンソールから一回やれば終わりである、というようなこともあり、私はこれまで「DX を CFn で実装したい」という気持ちになったことはありませんでした。
つまり我々のような構築を単発で請け負う側の視点ではなく、「DX をサービスとして継続的にプロビジョニングし続けるキャリアやプロバイダ側」においては、特にその冪等性が有効に機能するというアップデートでしょう。
もし定期的に作業として DX 関連リソースを作成しているような場合には、CFn の活用により作業ミスが減らせたり、事前チェックが楽になったりすると思われます。
AWS CloudFormation > Template Reference
- AWS::DirectConnect::Connection
- AWS::DirectConnect::DirectConnectGateway
- AWS::DirectConnect::DirectConnectGatewayAssociation
- AWS::DirectConnect::Lag
- AWS::DirectConnect::PrivateVirtualInterface
- AWS::DirectConnect::PublicVirtualInterface
- AWS::DirectConnect::TransitVirtualInterface
参考: AWS Direct Connect now supports AWS CloudFormation
まとめ
本ブログでは、AWS Direct Connect に関する2つの新しいアップデートについて、その有効性をまとめました。
1つ目の BGP セッション監視用 CloudWatch メトリクスの追加は、Lambda を用いた複雑な監視の仕組みを不要にし、運用保守の負荷を下げる待望のアップデートです*3。特に VirtualInterfaceBgpPrefixesAccepted を用いた経路数上限の監視は、不意の通信断を防ぐために、今後の標準的なベストプラクティスとなっていくでしょう。
2つ目の AWS CloudFormation サポートは、我々のような単発の構築作業においては直接的な恩恵を感じにくいかもしれません。しかし、DX リソースを継続的に提供・管理するプロバイダや回線事業者にとっては、冪等性の担保と作業ミスの削減に直結する重要な機能拡張です。
長らく手動運用や独自スクリプトに頼らざるを得なかった領域が、こうして AWS マネージドな標準機能として整備されていくのは、インフラ運用者として非常に喜ばしい変化だと感じます。
では、またお会いしましょう。
*1:ただ個人的には、DX のメンテナンスのタイミングで落ちてしまったりするので、これを毎回障害として通知するのはノイジーだと感じます
*2:監視＆通知するときはデフォルトの表示である5分平均ではなく、1分かつ最大 (Maximum) にしましょう
*3:なぜ今までこのメトリクスが取れなかったんだ、とすら思わされます
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
