ダイレクトコネクト（AWS Direct Connect）は、マネジメントコンソールのウィザードでも申し込めますが、複数の拠点やアカウントへ同じ構成を広げるならAWS CLIで手順を固めておくほうが再現しやすくなります。この記事では、接続の申請、LOA-CFAの取得、Direct Connectゲートウェイと仮想インターフェース（VIF）の作成、BGPの確認、冗長構成の検証、監視までを、AWS CLI 2.37系（2026年10月時点の公式リファレンス表記）のコマンドで順に示します。2026年時点で経路数の上限が「既定100・最大1,000」へ変わった点も、設計に織り込む内容の一つです。専用線とVPNのどちらを選ぶかといった定義や導入判断はAWS Direct Connectとは？専用線接続の仕組み・VPNとの違い・料金と導入判断にまとめてあるため、本記事は構築作業に絞ります。
まとめ｜ダイレクトコネクトをCLIで構築する前に決めておく5つの設計値
コマンドを打つ前に、次の5つを決めておくと手戻りがありません。
- 接続タイプとポート速度：専用接続（1・10・100・400Gbps）か、パートナー経由のホスト接続か
- VIFの種類と接続先：VPCへ直接つなぐプライベートVIFか、Transit GatewayへつなぐトランジットVIFか
- BGPのASN：Direct ConnectゲートウェイとTransit Gatewayで同じ番号を使うと関連付けが失敗する
- プレフィックス割り当て：オンプレミスから広告する経路数は既定100、VIFごとに最大1,000まで増やせる
- 回復性モデル：SLA 99.99%を狙うなら複数ロケーションに分けた接続が前提になる
このうちASNは、DXゲートウェイとTransit Gatewayの関連付けが失敗する原因になるため、拠点ごとの番号の払い出しを最初に決めておきます。経路数は後から増やせますが、DXゲートウェイ全体の上限があるので配分の見通しは先に立てておくと安心です。
ダイレクトコネクト構築の全体像と専用接続・ホスト接続で変わる作業範囲
前提として、AWS CLI v2の導入と認証が済んでいる状態から始めます。CLIの初期設定はAWS CLIの導入と運用｜v2の設定・SSO認証・v1サポート終了への移行手順を参照してください。
AWS側の作業とオンプレミス側・回線事業者側の作業を分ける6工程
ダイレクトコネクトの構築は、AWSのAPIで完結する作業と、物理回線の工事に分かれます。CLIで扱えるのは前者だけです。
- Direct Connectロケーションを選び、接続を申請する（AWS CLI）
- LOA-CFAを取得し、回線事業者やコロケーション事業者へ渡す（AWS CLI＋事業者）
- ロケーション内のクロスコネクトと、自社拠点までの回線を敷設する（事業者）
- Direct Connectゲートウェイを作り、VGWやTransit Gatewayと関連付ける（AWS CLI）
- VIFを作成し、オンプレミスのルーターにBGPを設定する（AWS CLI＋自社ルーター）
- フェイルオーバーテストと監視アラームで運用に入る（AWS CLI）
工期の大半を占めるのは3の物理工事です。そのため1と2を早めに済ませ、工事を待つ間に4以降のコマンドを検証環境で通しておくと、開通後すぐにBGPを上げられます。
専用接続とホスト接続で手順と仮想インターフェース数の上限が変わる点
どちらの接続を使うかで、CLIで打つコマンドとVIFの上限が変わります。Direct Connectのクォータから、設計に効く値を抜き出しました。
| 項目 | 専用接続 | ホスト接続 |
|---|---|---|
| 申請の主体 | 利用者がcreate-connection | パートナーが割り当て |
| VIFの上限 | 合計51（うちトランジット4） | 1 |
| LOA-CFA | 利用者が取得 | パートナー側で処理 |
| MACsec | 10・100・400Gbpsで対応 | 非対応 |
ホスト接続はVIFが1本しか作れません。本番と検証でVIFを分けたい、複数アカウントへホストVIFを配りたいといった要件があるなら、専用接続を選ぶことになります。以降のコマンドは専用接続を前提に書いています。
接続の申請からLOA-CFA取得までをAWS CLIで進める手順とコマンド例
ここからはDirect Connect CLIの公式手順に沿って進めます。リージョンは東京（ap-northeast-1）を例にします。
describe-locationsでロケーションコードを確かめてから接続を申請する
接続の申請にはロケーションコードが必要です。名前で指定することはできないため、先に一覧を取得します。
# 東京リージョンから使えるDirect Connectロケーションの一覧を取得
aws directconnect describe-locations --region ap-northeast-1 \
--query "locations[].[locationCode,locationName]" --output table
# 1Gbpsの専用接続を申請（--location には上で確認したコードを入れる）
aws directconnect create-connection --region ap-northeast-1 \
--location <ロケーションコード> \
--bandwidth 1Gbps \
--connection-name "dx-tokyo-primary"応答のconnectionId（dxcon-で始まる値）を控えてください。直後のconnectionStateはrequestedで、物理回線がつながってavailableになるまでVIFは通信できません。
describe-loaでLOA-CFAをPDF化し回線事業者へ渡すまでの流れ
LOA-CFAは、ロケーション内のどのポートへ回線を引き込むかを示す書類です。describe-loaの応答はBase64で返るため、デコードしてPDFにします。
# Linux・macOS
aws directconnect describe-loa --connection-id dxcon-xxxxxxxx \
--output text --query loaContent | base64 --decode > loa-cfa.pdf
# Windows（certutilでデコードする）
aws directconnect describe-loa --connection-id dxcon-xxxxxxxx --output text --query loaContent > loa-cfa.base64
certutil -decode loa-cfa.base64 loa-cfa.pdfこのPDFを回線事業者かコロケーション事業者へ渡すと、クロスコネクトの工事が始まります。公式手順のWindows例にはコマンド名の誤記（directconneawsct）があるので、そのまま貼り付けると失敗する点に注意してください。
Direct Connectゲートウェイと仮想インターフェースを作成するコマンド
物理工事を待つ間に、DXゲートウェイと関連付けといった論理構成を先に作っておけます。VIFは接続上に作るリソースで、BGPが確立するのは回線がつながってからです。
DXゲートウェイ作成時にAmazon側ASNをTGWと重ねない設定
create-direct-connect-gatewayのリファレンスによると、--amazon-side-asnは64512〜65534か4200000000〜4294967294の範囲で指定でき、省略すると64512になります。Transit Gatewayの既定ASNも64512です。仮想インターフェースの説明ページには、両者が同じASNだと関連付けが失敗すると書かれています。
# Amazon側ASNを明示してDXゲートウェイを作成
aws directconnect create-direct-connect-gateway \
--direct-connect-gateway-name "dxgw-main" \
--amazon-side-asn 64600
# VPCに付けた仮想プライベートゲートウェイ（VGW）を関連付ける
aws directconnect create-direct-connect-gateway-association \
--direct-connect-gateway-id <dxgwのID> \
--gateway-id vgw-xxxxxxxx \
--add-allowed-prefixes-to-direct-connect-gateway cidr=10.10.0.0/16--add-allowed-prefixes-to-direct-connect-gatewayは、オンプレミスへ広告するVPC側のプレフィックスです。関連付けのリファレンスにある通り、VGWとTransit Gatewayのどちらにも同じコマンドを使います。1つのDXゲートウェイに関連付けられるのはVGWが20個、Transit Gatewayが6個までで、どちらも引き上げはできません。
プライベートVIFとトランジットVIFの作成コマンドとMTUの選び方
VPCが数個ならプライベートVIF、Transit Gatewayで多数のVPCを束ねているならトランジットVIFを作ります。どちらもDXゲートウェイを接続先に指定する書き方が、後から接続先を増やしやすい形です。
# プライベートVIF：経路の割り当てを200に増やしておく
aws directconnect create-private-virtual-interface \
--connection-id dxcon-xxxxxxxx \
--new-private-virtual-interface "virtualInterfaceName=vif-private-prod,vlan=101,asn=65010,addressFamily=ipv4,mtu=1500,directConnectGatewayId=<dxgwのID>,prefixPoolAllocatedCountIpv4=200"
# トランジットVIF：ジャンボフレームは8500を指定
aws directconnect create-transit-virtual-interface \
--connection-id dxcon-xxxxxxxx \
--new-transit-virtual-interface "virtualInterfaceName=vif-transit-prod,vlan=201,asn=65010,addressFamily=ipv4,mtu=8500,directConnectGatewayId=<dxgwのID>"IPv4のピアアドレスとauthKeyを省略すると、AWS側で生成されます。MTUは、プライベートVIFが1500か9001、トランジットVIFが1500か8500です。ジャンボフレームへ変えると物理接続側の設定更新が走り、同じ接続上のすべてのVIFが最大30秒途切れると公式ページに書かれています。業務時間中の変更は避けてください。
describe-virtual-interfacesでBGP状態を確認する手順
VIFを作ったら、BGPの状態と自社ルーター向けの設定値を取り出します。
# BGPピアの状態（bgpStatus が up になれば確立）
aws directconnect describe-virtual-interfaces \
--virtual-interface-id dxvif-xxxxxxxx \
--query "virtualInterfaces[].bgpPeers[].[bgpPeerState,bgpStatus,customerAddress,amazonAddress]" \
--output table
# ルーターへ投入する値（VLAN・アドレス・ASN・認証キー）をXMLで取り出す
aws directconnect describe-virtual-interfaces \
--virtual-interface-id dxvif-xxxxxxxx \
--query "virtualInterfaces[*].customerRouterConfig" --output textXMLにはvlan、customer_address、amazon_address、bgp_auth_keyなどが入ります。機種別のコンフィグ例が欲しい場合はコンソールの「ルーター設定のダウンロード」を使います。CLIで返るのは汎用の値だけです。
経路数の上限が既定100から最大1,000へ変わったプレフィックス割り当ての設計
以前は「プライベートVIFで受け付ける経路は100まで」が固定の制約で、超えるとBGPが落ちるため経路集約で逃げるしかありませんでした。この制約と従来の回避策はAWS Direct Connectの100ルート問題｜BGP経路数の上限とセッション断の回避策で扱っています。現在は割り当て数を利用者が決められます。
接続速度で決まるプレフィックスプールとVIFごとの割り当て数の関係
インバウンドプレフィックス制御のドキュメントによると、専用接続ごとに経路数のプールがあり、VIFを作るときにそこから割り当てを取る仕組みです。
| 項目 | 値（IPv4・IPv6それぞれ） |
|---|---|
| プール（1・10Gbps） | 5,000 |
| プール（100Gbps） | 30,000 |
| プール（400Gbps） | 50,000 |
| VIFごとの割り当て | 既定100・最大1,000 |
| DXゲートウェイ合計 | 10,000（IPv4とIPv6の合算） |
パブリックVIFはこの仕組みの対象外で、1,000で固定です。ホスト接続では接続単位のプールは使わず、VIFの割り当てだけを最大1,000まで設定できます。DXゲートウェイ側の合計10,000も見落としやすい上限で、1,000を10本割り当てた時点で使い切ります。
割り当て超過でBGPがidleに落ちる事故を防ぐ経路集約と監視
割り当てより多い経路を広告すると、そのVIFのBGPセッションはidleになり、状態はDOWNと表示されます。割り当ては既存VIFでも後から変更できます。
# 既存VIFのIPv4割り当てを100から300へ増やす
aws directconnect update-virtual-interface-attributes \
--virtual-interface-id dxvif-xxxxxxxx \
--prefix-pool-allocated-count-ipv4 300注意点は2つあります。現在広告している数より小さい値には下げられません。また、VGW経由でVPCのルートテーブルへ伝播する経路はVPC側のクォータにも縛られ、VIFの割り当てを増やしてもその上限は上がりません。割り当てを増やす前に、オンプレミス側で拠点ごとの経路を集約できないかを先に検討してください。実際の受信数は後述のCloudWatchメトリクスVirtualInterfaceBgpPrefixesAcceptedで追えます。
回復性モデルとBGPフェイルオーバーテストで冗長構成を検証する手順
専用線が1本だけだと、工事や機器障害のたびに通信が止まります。冗長化の型と、その型が本当に切り替わるかの検証手順を押さえます。
SLA99.99%と99.9%を分ける回復性モデルとロケーション数の要件
Resiliency Toolkitのドキュメントは、3つの回復性モデルを定義しています。
| モデル | 構成 | SLA |
|---|---|---|
| 最大の回復性 | 複数ロケーション×別機器の接続 | 99.99% |
| 高い回復性 | 2ロケーションに1本ずつ | 99.9% |
| 開発とテスト | 1ロケーション内の別機器 | なし |
開発とテストのモデルは機器障害には耐えますが、ロケーション全体の障害には耐えません。SLAを適用するにはDirect ConnectのSLAに書かれた構成要件をすべて満たす必要があります。基幹系をつなぐなら、最初の発注から2ロケーション以上で見積もるのが前提です。
start-bgp-failover-testで片系を落として切替を確かめる手順
冗長化したつもりでも、ルーター側の経路優先度の設定ミスで切り替わらないことがあります。start-bgp-failover-testを使うと、AWS側からBGPセッションを意図的にDOWNにできます。
# 片系のVIFのBGPを60分間DOWNにする（既定180分・最大4,320分）
aws directconnect start-bgp-failover-test \
--virtual-interface-id dxvif-xxxxxxxx \
--test-duration-in-minutes 60
# 確認が終わったら途中で戻す
aws directconnect stop-bgp-failover-test --virtual-interface-id dxvif-xxxxxxxx
# 過去のテスト結果を確認
aws directconnect list-virtual-interface-test-history --virtual-interface-id dxvif-xxxxxxxxテスト中は、もう片系のVIFに通信が移っているかをオンプレミスからのpingやアプリケーションの疎通で確かめます。切り替わりに何秒かかったかも記録しておくと、障害時の影響を説明する材料になります。
CloudWatchで接続とBGPを監視するアラーム設定と料金の見積もり
開通後に欠かさず用意したいのが、BGPの断を検知するアラームです。あわせて月額の目安も計算しておきます。
BGPセッション断を検知するCloudWatchアラームの作成コマンド
Direct ConnectのCloudWatchメトリクスは既定で5分間隔です。接続の状態はConnectionState、BGPの状態はVirtualInterfaceBgpStatusで、どちらも1がup、0がdownを表します。BGP系のメトリクスにはIpAddressFamilyのディメンションも付くため、まず実際のディメンションを確認してからアラームを作ります。
# 実際に発行されているディメンションの組み合わせを確認
aws cloudwatch list-metrics --namespace AWS/DX --metric-name VirtualInterfaceBgpStatus
# BGPが2回連続でdownならSNSへ通知
aws cloudwatch put-metric-alarm \
--alarm-name "dx-vif-private-prod-bgp-down" \
--namespace AWS/DX --metric-name VirtualInterfaceBgpStatus \
--dimensions Name=ConnectionId,Value=dxcon-xxxxxxxx Name=VirtualInterfaceId,Value=dxvif-xxxxxxxx Name=IpAddressFamily,Value=ipv4 \
--statistic Minimum --period 300 --evaluation-periods 2 \
--threshold 1 --comparison-operator LessThanThreshold \
--treat-missing-data breaching \
--alarm-actions arn:aws:sns:ap-northeast-1:123456789012:dx-alerts--dimensionsはlist-metricsの結果と完全に一致させてください。1つでも違うとアラームはデータを受け取れず、ずっと「データ不足」のままになります。経路数の監視にはVirtualInterfaceBgpPrefixesAcceptedを使い、割り当ての8割を超えたら通知するといった閾値を置きます。
ポート時間とデータ転送アウトから計算する東京リージョンの月額試算
Direct Connectの料金ページにある日本の単価（2026年10月時点）は次の通りです。AWSへ入るデータ転送は全ロケーションで無料です。
| 項目 | 単価（USD） |
|---|---|
| 専用接続 1Gbps | 0.285／時間 |
| 専用接続 10Gbps | 2.142／時間 |
| ホスト接続 1Gbps | 0.314／時間 |
| 東京から日本のロケーションへの転送 | 0.0410／GB |
1Gbpsの専用接続を1か月（730時間）使うとポート料金は208.05ドルです。東京リージョンから月10TB（10,240GB）を送り出すと転送料は419.84ドルで、合計は627.89ドルになります。高い回復性のモデルで2本にすれば、ポート料金はその2倍です。回線事業者の月額料金とロケーションでのクロスコネクト費用はAWSの請求とは別に掛かるため、見積もりでは三者をまとめて比較してください。
ダイレクトコネクトをCLIで自前構築する範囲とパートナーへ任せる判断
最後に、ここまでの手順をどこまで自社で持つかを線引きします。
CLIやIaCで管理すべき構成と、ホスト接続で済ませる小規模構成の線引き
専用接続を2ロケーション以上に持ち、VIFやDXゲートウェイを複数アカウントへ配る構成なら、本記事のコマンドをスクリプトかIaCに落として管理します。手作業のコンソール操作では、ASNや割り当て数の設定値が拠点ごとにずれていくためです。Transit Gatewayを中心に据える場合はAWS Transit Gatewayとは｜仕組み・VPC Peeringとの違い・料金を解説で役割を確認し、アカウントをまたぐ構成はTransit Gatewayクロスアカウント構築手順｜TerraformとRAM共有の手順と組み合わせます。
反対に、拠点が1つでVPCも1〜2個なら、パートナーのホスト接続を使い、VIFの作成とBGPの確認だけを自社で行う形で十分です。回線の手配から冗長構成の設計、監視の作り込みまでをまとめて任せたい場合は、インフラ構築（AWS・Google Cloud・Azure）で要件整理から対応しています。
専用線を敷かずにSite-to-Site VPNで始めるべき条件
転送量が月数百GB程度で、帯域の揺らぎが業務に響かないなら、専用線は見送ってSite-to-Site VPNで始めるべきです。その日のうちに構成でき、ポート料金も回線工事もありません。IKEの設定値やstrongSwanでの接続手順はSite-to-Site VPNとは？3クラウドのIKE既定値とstrongSwan接続手順にあります。ダイレクトコネクトを入れた後も、VPNは片系障害時のバックアップとして残しておく価値があります。他のクラウドと閉域で結ぶのが目的なら、AWS Interconnect – multicloudとは？対応リージョンと料金Tier・Direct Connectとの役割分担も比較に入れてください。
ダイレクトコネクトの構築でよくある質問と開通期間・暗号化・接続上限の確認
ダイレクトコネクトの構築について検索されている質問に、公式ドキュメントの記載をもとに答えます。
ダイレクトコネクトの開通までにどのくらいかかりますか？
AWS側の手続きは、接続の申請からLOA-CFAの取得まで短時間で終わります。期間の大半を占めるのは、ロケーション内のクロスコネクトと自社拠点までの回線敷設という物理工事です。工期は回線事業者と拠点の場所で変わるため、見積もりの段階で事業者に確認してください。工事を待つ間にDXゲートウェイと関連付けを済ませ、ルーターの設定を用意しておくと、開通後の作業はVIFの作成とBGPの確認だけで済みます。
ダイレクトコネクトの通信は暗号化されますか？
専用線は閉域ですが、それだけでは通信内容は暗号化されません。暗号化が要件なら、10・100・400Gbpsの専用接続で使えるMACsecを設定するか、Direct Connectの上にIPsec VPNを張ります。MACsecは追加料金がかからない一方、ホスト接続では使えず、対応するロケーションも限られます。自社ルーターがMACsecに対応しているかも事前に確認が必要です。
1本の接続で複数のVPCやリージョンにつなげますか？
Direct Connectゲートウェイを使えばつなげます。1つのDXゲートウェイには、VGWを20個まで、Transit Gatewayを6個まで関連付けられ、別リージョンのVPCも接続の対象にすることが可能です。VPCがさらに多い場合は、Transit Gatewayで束ねたうえでトランジットVIFを使う構成にします。1本の専用接続に作れるトランジットVIFは4本までです。
BGPの状態はAWS CLIのどのコマンドで確認できますか？
aws directconnect describe-virtual-interfacesの応答にあるbgpPeersのbgpStatusで確認します。upなら確立、downなら未確立か切断です。継続的に見るなら、CloudWatchのVirtualInterfaceBgpStatusメトリクスにアラームを設定します。受け付けている経路数はVirtualInterfaceBgpPrefixesAcceptedで追えます。
ホスト接続でも経路数の上限を100から増やせますか？
増やせます。ホスト接続では接続単位のプールは使われませんが、VIFごとの割り当ては既定の100から最大1,000まで設定が可能です。作成時はprefixPoolAllocatedCountIpv4を指定し、作成後はupdate-virtual-interface-attributesの--prefix-pool-allocated-count-ipv4で変更します。なお、パートナーから受け取るホストVIFは常に既定の100で作られ、割り当ての変更は接続の所有者側で行います。
関連記事
- AWS Direct Connectとは？専用線接続の仕組み・VPNとの違い・料金と導入判断【2026年版】：定義・VPNとの違い・導入判断をまとめた主記事。
- AWS Direct Connectの100ルート問題｜BGP経路数の上限とセッション断の回避策：経路集約による従来の回避策。
- AWS Transit Gatewayとは｜仕組み・VPC Peeringとの違い・料金を解説：トランジットVIFの接続先の仕組み。
- Transit Gatewayクロスアカウント構築手順｜TerraformとRAM共有：複数アカウントへ広げる構成の実装。
- Site-to-Site VPNとは？3クラウドのIKE既定値とstrongSwan接続手順：小規模構成やバックアップ回線の選択肢。
