Cloud Service
Azure ExpressRoute Direct
接続プロバイダーを介さず Microsoft のグローバルネットワークへ直接つなぎ、大容量ポートと物理層の専有を確保。大規模なデータ移行や規制要件に応える ExpressRoute Direct。
- 1.プロバイダーを経由せず Microsoft のエッジに物理ポートで直接接続する ExpressRoute の形態。
- 2.大容量ポートを専有し、その容量内で複数回線を切り出せるため大規模・規制要件に向く。
- 3.MACsec によるレイヤー2暗号化に対応し、AWS の Direct Connect 専有接続に近い位置づけ。
解決する課題
通常の ExpressRoute は接続プロバイダーが用意する回線を介して Microsoft とつなぎますが、超大容量や物理層の専有、独自の暗号化要件が求められる場面ではこの形態が制約になります。ExpressRoute Direct は、ユーザーが Microsoft の Enterprise Edge(MSEE)に対して物理ポートのペアを直接確保し、その上に複数の ExpressRoute 回線を切り出せるようにします。
- プロバイダーを介さず自前の物理ポートで Microsoft に直結し、超大容量と一貫した品質を確保したい
- 1 つのポート容量から複数の回線を自分で切り出して部門やワークロードへ割り当てたい
- 金融や政府など物理層の専有や MACsec 暗号化が求められる規制要件に対応したい
主要概念と用語
- ExpressRoute Direct: 接続プロバイダーを介さず、Microsoft のグローバルネットワークの物理ポートへ直接接続する ExpressRoute の上位形態
- Direct ポートペア: 冗長性のために割り当てられる物理ポートのペア。Active/Active で運用し、片方の障害でも通信を維持する
- ポート帯域(ポートペアの容量): 確保する物理ポートの総容量。高速プランと低速プランの系列があり、用途に応じて選ぶ
- 回線(Circuit): ポート容量の中から切り出す論理的な ExpressRoute 接続。1 つの Direct ポートペアに複数の回線を作成できる
- オーバープロビジョニング: 切り出す回線帯域の合計を、物理ポート容量より大きく設定できる考え方。瞬間的なバーストを許容しつつ複数回線を収容する
- MACsec: ポートと顧客機器の間のレイヤー2リンクを暗号化する仕組み。ExpressRoute Direct のポートで構成できる
- MSEE(Microsoft Enterprise Edge): Microsoft 側で BGP を終端するエッジルータ群。こことユーザー機器が直接対向する
- Letter of Authorization(LOA): データセンターで物理クロスコネクトを敷設するための認可書類。Direct のポート開通時に用いる
仕様・制限・クォータ
- ポートは必ず冗長なペアで提供され、両系で BGP を確立する Active/Active 構成が前提
- ポート容量には高速系列と低速系列があり、それぞれ選べる帯域の刻みが異なる
- 1 つのポートペアから作成できる回線数や、回線帯域の合計には上限があり、オーバープロビジョニングの範囲も定義されている
- 通常の ExpressRoute より上位の回線帯域を1回線あたりで選択できる
- 物理クロスコネクトの敷設には LOA とデータセンター事業者側の作業が必要で、開通までにリードタイムを見込む
- MACsec はポート単位の設定で、回線ごとではなく物理リンクに対して適用される
必要帯域が中規模までで、回線を素早く開通したいならプロバイダー型の ExpressRoute が手軽です。ExpressRoute Direct は、超大容量・物理層の専有・MACsec・複数回線の自己分割といった要件が明確なときに選ぶ形態だと考えてください。
内部の仕組み
ExpressRoute Direct でも、Microsoft との相互接続はレイヤー3の BGP ルーティングで成立します。違いは物理層にあり、ユーザーは MSEE のポートに対して自分の機器から直接クロスコネクトを敷設します。プロバイダーの装置が経路上に介在しないぶん、容量と物理構成を自分で管理できます。
- ポートペアの両系でリンクを上げ、それぞれで BGP セッションを張って Active/Active の冗長を確保する
- 確保したポート容量の中で回線を作成し、各回線にプライベートピアリングや Microsoft ピアリングを構成する
- MACsec を有効化すると、ポートと対向機器の間のフレームがレイヤー2で暗号化される。これは BGP より下位の物理リンク保護である
- データ経路は通常 ExpressRoute Gateway を経由するが、FastPath を併用すればゲートウェイをバイパスして遅延を抑えられる
MACsec が暗号化するのはユーザー機器と Microsoft ポートの間のレイヤー2リンクだけです。Microsoft 網内やエンドツーエンドの暗号化を保証するものではないため、アプリケーション層やトランスポート層の暗号化(TLS や IPsec)は別途設計してください。
設計パターン / ベストプラクティス
- 回線の論理分割: 1 つの大容量ポートペアから部門・環境・ワークロード単位で回線を切り出し、課金や経路を分離する
- 冗長の確保: ポートペアの両系を必ず使い切り、可能なら複数のピアリングロケーションでロケーション冗長も検討する
- オーバープロビジョニングの活用: 各回線のピーク利用が重ならない前提で帯域合計をポート容量より大きく設計し、利用率を高める
- MACsec の適用範囲を明確化: リンク暗号化が必要な規制要件と、上位層の暗号化要件を切り分けて二重に担保する
- FastPath の併用: 低遅延が重要なワークロードではゲートウェイのボトルネックを避ける
運用・監視
- ポートおよび回線のトラフィック(入出力ビット/秒、ドロップ、エラー)を継続監視し、オーバープロビジョニング時の輻輳を早期に検知する
- BGP セッションの状態と広告経路数を確認し、経路フラップや上限超過を見張る
- MACsec の状態(キー交換の成立、リンクの保護状態)を監視対象に含める
- Connection Monitor / Network Watcher でオンプレと Azure 間の到達性・遅延・パケットロスを計測する
- 計画メンテナンスは冗長ポートのうち片系ずつ実施される前提で、平時から両系が BGP 確立済みかを確認しておく
コスト
| 要素 | 課金 | ポイント |
|---|---|---|
| Direct ポートペア | 確保した物理ポート容量に対する月額 | 回線を作らなくてもポート確保で課金される |
| 回線(切り出し) | 回線の課金モデルと帯域による | 1ポートから複数回線でも各回線が対象 |
| 送信データ | 従量モデルでは送信量に課金 | 定額モデルなら送信は実質含まれる |
| ExpressRoute Gateway | ゲートウェイの稼働時間 | SKU により単価が異なり常時課金 |
| クロスコネクト | データセンター事業者へ別建て | 物理敷設の費用は Azure 課金とは別 |
ExpressRoute Direct はポートを確保した時点で容量分の課金が始まります。回線をまだ作っていなくても費用が発生するため、必要帯域を満たせるなら回線数や利用率を高めて投資を回収しやすくする設計が重要です。
セキュリティ
- 物理ポートを専有するため、プロバイダー共用環境に比べ物理層の分離が強い
- MACsec でユーザー機器と Microsoft ポート間のレイヤー2リンクを暗号化し、規制要件に対応する
- MACsec はリンク区間限定のため、機密データにはIPsec や TLS を上位で重ねてエンドツーエンドを担保する
- Microsoft ピアリングで広告する経路は最小化し、不要な PaaS エンドポイントへの到達を避ける
- ルートフィルタや NSG・Azure Firewall を併用し、専用線越しの横展開を制限する
物理専有と MACsec があるから上位の暗号化やセグメンテーションを省略する、という判断は危険です。MACsec はリンク区間しか守らず、Microsoft 網内やアプリ間の機密性は別問題です。最小権限・ネットワーク分離・上位層の暗号化を併せて設計しましょう。
関連サービス・比較
| 観点 | ExpressRoute Direct | ExpressRoute(プロバイダー型) |
|---|---|---|
| 接続経路 | Microsoft ポートへ直接接続 | 接続プロバイダー経由で接続 |
| 物理層 | ポートを専有 | プロバイダー環境を共用しがち |
| 回線の切り出し | 1ポートから複数回線を自分で分割 | 原則プロバイダーが回線を提供 |
| 回線帯域 | より上位の帯域を選べる | 中規模までが中心 |
| MACsec 暗号化 | ポートで構成可能 | 原則対象外 |
| 開通の手軽さ | 物理敷設が必要で時間を要する | 比較的早く開通しやすい |
| 向くケース | 超大容量・規制・複数回線分割 | 中規模・素早い開通 |
ハンズオン / CLI例
# リソースグループを作成
az group create --name demo-rg --location japaneast
# ExpressRoute Direct のポートを作成(ロケーション・帯域・カプセル化を指定)
az network express-route port create \
--resource-group demo-rg \
--name demo-erdirect \
--location japaneast \
--peering-location "Tokyo" \
--bandwidth 100 \
--encapsulation Dot1Q
# 作成したポートの状態と LOA 用の情報を確認
az network express-route port show \
--resource-group demo-rg \
--name demo-erdirect \
--query "{state: provisioningState, bandwidth: bandwidthInGbps, links: links[].adminState}"
# ポート容量から ExpressRoute 回線を切り出す
az network express-route create \
--resource-group demo-rg \
--name demo-circuit \
--location japaneast \
--express-route-port demo-erdirect \
--bandwidth 5 \
--sku-family MeteredData \
--sku-tier Standard
Azure Service
Azure ExpressRoute Directを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
ネットワーキング
比較で見る軸
クラウド: Azure / カテゴリ: ネットワーキング / 難易度: intermediate
導入後に効く点
大容量ポートを専有し、その容量内で複数回線を切り出せるため大規模・規制要件に向く。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- Azure
- カテゴリ
- ネットワーキング
- 難易度
- intermediate
- 関連資格
- —
- 設計柱
- performance / security / reliability / cost
判断チェックリスト
- 自社の用途が「ネットワーキング / performance」に近いか確認する。
- 強みである「プロバイダーを経由せず Microsoft のエッジに物理ポートで直接接続する ExpressRoute の形態。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。