こんにちは、あだちです。
2026年6月13日に、「JAWS-UG 茨城 #14 Direct Connectハンズオン ＠飯田橋」に参加してきました。
会場はアジアクエスト株式会社 本社で、AWSJ の菊地さんによる AWS Direct Connect ハンズオンです。イベントページにも書かれている通り、今回は AWSJ からハンズオン用のAWS環境を提供していただける形でした。
Direct Connect は、AWS のネットワークの勉強をしていると何度も出てきます。私も AWS Certified Advanced Networking - Specialty、いわゆる ANS は持っています。なので、用語としては何度も見ていて、マネジメントコンソールの設定画面を眺めたこともあります。
ただ、実際に Direct Connect で専用線をつなぐ、というのは個人で簡単にできるものではありません。私の場合も、これまでは「知識としてはなんとなく理解しているけど、実際の構成や作業の流れと結びついていない」という状態でした。
今回は自分の会社が会場スポンサーだったこともあり、これは Direct Connect を触るチャンスだなと思って参加しました。
この記事は、Direct Connect の網羅的な解説ではありません。
ハンズオンでやったことをなぞりつつ、自分が初めて知ったこと、まだ理解できていないこと、触ってみて感じたことを書いていきます。
自分の前提
先に、自分の前提を書いておきます。
- AWS Certified Advanced Networking - Specialty を持っている
- ネットワークの勉強はしている
- ただし、実務で Direct Connect を使った経験はない
- Direct Connect の用語や概念はなんとなく知っている
- ただし、構成図や実際の作業と結びつけるのは弱い
資格を持っていると、なんとなく「わかっている」気持ちになりやすいです。
しかし Direct Connect に関しては、正直に言うと、画面を見たことがあるだけに近かったです。
- オンプレミスから AWS に専用線でつなぐ
- Direct Connect Gateway がある
- Private VIF や Transit VIF がある
- BGP で経路交換する
単語としては知っているけれど、それが実際にどういう順番で設定されて、どこで疎通確認して、どこが難しいのか。そこまではあまりイメージできていませんでした。
なので今回のハンズオンは、自分と同じように「AWS のネットワーク資格は持っている、または勉強中だけど、Direct Connect は触ったことがない」という人にはかなり近い話になると思います。
当日やったこと
当日実施したハンズオンはこちらです。
AWS Direct Connect ハンズオン
手順を全部ここに書くと Workshop の再掲になってしまうので、流れだけざっくり書きます。今回 VPC や EC2 などを作業したリージョンは東京リージョン、ap-northeast-1 でした。
- Direct Connect の概要確認
- 仮想インターフェイス、VIF の割り当て状況確認
- VGW の作成と VPC へのアタッチ
- ルートテーブルにオンプレミス向けルートを追加
- Direct Connect Gateway（以下DXGW） の作成
- DXGW と 仮想プライベートゲートウェイ（以下VGW） の関連付け
- 仮想インターフェイス（以下VIF）の承諾
- Cisco CSR へのオンプレミス側設定
- BGP ピアや ping による疎通確認
- CloudWatch メトリクスの確認
- 追加 VPC への接続確認
- オプションとして Transit Gateway への経路変更
ハンズオンの全体構成は、Workshop に載っている図が一番わかりやすいです。
引用: AWS Direct Connect ハンズオン Workshop
この図を見て、あらためて「Direct Connect は AWS とオンプレミス環境を直接なんとなくつなぐもの、ではなくて、Direct Connect ロケーションや Connection、VIF を分けて考えるものなんだな」と思いました。
VIF の状態をコンソールで見るところも、資格勉強の知識とは印象が違いました。
引用: AWS Direct Connect ハンズオン Workshop
ここでいう Connection は物理接続で、VIF はその Connection を通して AWS リソースにアクセスするための論理インターフェイスです。
自分はこのあたり、資格勉強では単語として覚えていたのですが、実際にコンソールで VIF の状態を見たり、承諾したり、BGP ピアの状態を見たりすると、だいぶ見え方が変わりました。
触ってみて初めて知ったこと
まず初めて知ったこと、触ってみてようやく腹落ちしたことがいくつかありました。
1つ目は、Direct Connect を考えるときに Direct Connect ロケーションと繋いでいることをちゃんと意識する必要があることです。
試験のときは覚えていたはずです。
しかし、試験からしばらく時間が経っていて、頭の中ではどこか「オンプレミスと AWS を専用線でつなぐサービス」ぐらいに戻っていました。
実際には、オンプレミス側から Direct Connect ロケーションまでの接続があり、その先に AWS 側のリソースがあります。さらにその中に Connection があり、VIF があり、DXGW や VGW がある。言葉で書くと当たり前なのですが、手を動かすまで、そこまで分解して考えられていなかったです。
2つ目は AS 番号です。
オンプレミス側と Direct Connect Gateway では AS 番号が異なる必要がある。
一方で、Direct Connect Gateway と AWS 側の VGW は同じでもよい。
このあたりは、聞いたときに少し意外でした。
「同じでいいんだ」と思ったし、AWS の内部でうまく処理される、という説明を聞いて、まだ自分の理解は浅いなとも思いました。
3つ目は、ルーティングには順序があるということです。
これも勉強としては知っているはずです。
でも、ハンズオンの中で ping が通らない状態をあえて確認してから、ルート伝播を有効化し、ルートテーブルに経路が入って、ようやく ping が通るのを見ると、だいぶ印象が違いました。
特に「静的なルートは伝播されたルートより優先順位が高い」というあたりは、知識として読むのと、今この ping が通らない理由として見るのとでは、やっぱり違います。
- 最長プレフィックス (例: 10.10.2.15/32 は 10.10.2.0/24 よりも優先されます)
- 静的ルート (VPC ピアリングやインターネットゲートウェイ接続など)
- プレフィックスリストルート
- 伝播されたルート
a. Direct Connect BGP ルート (動的ルート)
b. VPN 静的ルート
c. VPN BGP ルート (動的ルート) (仮想プライベートゲートウェイなど)
AWS ドキュメント：「ルーティングの優先度の仕組み」
4つ目は、AWS Direct Connect のコンソールに「AWS Interconnect - マルチクラウド」があることです。
これは単純に「そんな項目あるんだ」と思いました。まだちゃんと調べられていないので、ここでは深掘りしませんが、AWS と他クラウドをパブリックインターネットなしで繋ぐ「Direct Connect のクラウド版」という認識です。後日触ってみようと思います。
5つ目は、冗長構成の組み方です。
今回のハンズオンでは、2つの仮想インターフェイスを同じ Direct Connect Gateway に関連付けることで、オンプレミスから AWS クラウド間の冗長化を確保する構成が出てきました。
ただ、ここは「VIF を2つにすれば冗長化は終わり」と雑に理解すると危なそうです。AWS のドキュメントを見ると、Direct Connect の冗長性モデルでは複数の接続や複数ロケーションを使う話が出てきますし、Direct Connect Gateway 自体もデータパス外で動く分散された BGP ルートリフレクターとして設計されていて、単一障害点にならないように作られている、と説明されています。
このあたりは、資格勉強では図として見たことがあるはずなのですが、正直まだ自分の言葉では説明しきれません。VIF、Connection、ロケーション、Direct Connect Gateway のどこで何を冗長化しているのかは、もう少しちゃんと復習したいです。
参考:
一番実感したこと
今回いちばん強く感じたのは、専用線をつないでいるにも関わらず、AWS Direct Connect のセットアップはかなり早い、ということでした。
もちろん、これはハンズオンです。
手順も環境もかなり整備されていました。参加者が作業できるように、AWS アカウントや疑似オンプレミス環境、VGW なども準備されていました。
なので、これをそのまま実務の Direct Connect 導入と同じだとは言えません。
それでも、説明と休憩を除くと、疎通確認までは体感で1時間程度でした。VGW を作って、DXGW を作って、VIF を承諾して、Cisco CSR に設定を入れて、ping が通るところまで見られました。
正直、ネットワークに関する知識もあやふやな部分がありましたが、それでも手順に沿って進めると構築できました。
当日は、ネットワークを専門に仕事にしている人ばかりではありませんでした。大半の人はルートテーブルぐらいは触ったことがあっても、Direct Connect は触ったことがない、という状態でした。それでも、ほとんど脱落せずに疎通まで行けていたのは印象に残っています。
これがもし全部オンプレミスで、物理機器を用意して、回線を引いて、現地作業も含めてやるとなると、何ヶ月という時間が必要になるはずです。そのための人材や交通、調整にもかなりお金がかかると思います。
そう考えると、クラウド側で作れる部分の速さや、検証環境として触れる手軽さは、やっぱりクラウドのメリットだと思いました。
ping が通らない状態を一度見るのがよかった
ハンズオンの中でよかったのは、最初から全部通る状態にするのではなく、一度 ping が失敗する状態を見るところです。
Workshop では、bastion EC2 インスタンスから training-server-1 に ping を実行し、最初は疎通できない状態を確認します。そのあと、足りない設定を追加して、疎通できることを確認します。
引用すると、Workshop ではこのような流れです。
これまでの作業では、疎通が出来ない状態です。一度、pingを失敗している状態を確認後、設定を追加することで疎通できることを確認します。
引用: AWS Direct Connect ハンズオン Workshop
最初から成功してしまうと、たぶん「手順通りにやったら通った」で終わっていたと思います。今回は一度失敗してから、構成図を見て、どこの VPC からどこの VPC に向かっているのかを確認して、ルートテーブルを見ました。
ネットワークの勉強をしていると、どうしても「経路を広告する」「BGP で学習する」みたいな言葉だけが先に来ます。でも今回は、どこの経路が足りなくて、なぜ失敗していて、設定を足すと何が変わるのかを構成図と照らし合わせて見られたのがよかったです。
また、CloudWatch で疎通確認ができた点も視覚的に分かりやすかったです。
まだ十分に理解できていないこと
一方で、まだ十分に理解できていないこともあります。
むしろ、ここを残すためにブログを書いています。
まず Local Preference です。
Local Preference とは何者で、どうやって使うのか。
たぶん、ルーティングの優先順位を制御するためのものなのだと思います。ただ、試験のときは覚えていたかもしれないけど、今はもう自分の言葉でちゃんと説明できない状態です。
Workshop の後半には、トラフィックエンジニアリングや Transit Gateway への経路変更の章があります。そこでは Local Preference を 200 にしたり、50 にしたりして経路を切り替える手順が出てきます。
でも、自分の理解としてはまだ「値を変えると経路の優先が変わるらしい」ぐらいです。
これをどの場面で使うのか、組み合わせを変えるとどうなるのかの理解はできていません。
次に Transit Gateway です。
AWS Transit Gateway を使う場合の設定方法は、まだ十分に理解できていません。
VPC 同士を接続したいときに Transit Gateway を使う、というところまでは理解しています。一方で、Direct Connect Gateway だけでも Virtual Private Gateway を 20 個まで関連付けられる、という制限もあります。
では、20 個を超えるような VPC 構成がどれくらいあるのか。仮にあったとして、それが Transit Gateway を使う要件なのか。それとも別の理由で Transit Gateway を使うのか。自分の理解としては、このあたりがまだはっきりしていません。
本ハンズオンのアカウントは72時間使えるので、家に帰ってTransit Gatewayの設定をしたり調べたりしました。
以下の記事がこのテーマについて分かりやすかったです。
「Transit Gatewayを使わなければならない場面を改めて考えてみる というタイトルで登壇しました」
もう1つ気になっているのは、実際に初めて Direct Connect を導入する場合に何が大変なのか、です。
今回は手順と環境が完璧に整備されていました。だから、ほとんど労力がかからず進められた面があります。
でも、実際に初めて Direct Connect を使うとしたら、きっと別の難しさがあるはずです。
たとえば、自社の拠点からどの Direct Connect ロケーションへつなぐのか。誰が回線を手配するのか。オンプレミス側ルーターの設定は誰が持つのか。BGP の経路をどこまで AWS に広告して、AWS から受け取った経路をどこまで社内に流すのか。冗長化したあと、片系を落として本当に切り替わるかをどう確認するのか。
こう書くと当たり前のことばかりですが、ハンズオンではそのあたりが全部整理された状態で出てきます。そこが実務との差なんだろうなと思いました。
今回触れたことで「簡単だった」と言いたいわけではありません。
むしろ、整ったハンズオン環境で触れたからこそ、実務ではこの裏にもっといろいろあるんだろうな、と思いました。
Direct Connect は実務で使わないから関係ない、と思っていた
Direct Connect なんて実務で使わないし、資格のためにしか勉強しない。
そう思っている人は、たぶんけっこういると思います。
自分も、少しそういう感覚がありました。
普段 AWS のネットワークを触っていても、VPC、Subnet、Route Table、Security Group あたりに比べると、Direct Connect は距離があります。小さな検証環境や個人開発で使うものでもありません。
なので、どうしても「知識として覚えるサービス」になりやすい。
今回触ってみて、使わないサービスだから学ばなくていい、とはあまり思わなくなりました。よかったのは、Direct Connect を「試験に出るサービス」としてではなく、VPC のルートテーブルや BGP の状態とつなげて頭に入ったことです。
正直、Direct Connect を明日から実務で使うわけではないです。
それでも、AWS のネットワークを勉強している人なら、一度触ってみる価値はあると思いました。
ただし、ハンズオンの Workshop 自体は、誰かに Direct Connect ロケーションまでの専用線を引いてもらわなければいけないので、1人で完全に再現するのは難しいと思います。今回のように環境が用意されている機会があれば、ぜひ参加してみてください！
これから復習する資料
今回の内容を復習するなら、自分はまずこのあたりを見直します。
- AWS Direct Connect 公式ページ
- AWS Direct Connect ドキュメント
- AWS Black Belt 2025 AWS Direct Connect
- AWS Direct Connect 概要〜これだけはおさえておきたいこと〜【AWS Black Belt】
- AWS Direct Connectと愉快なGWたちをおさらいする会
特に Local Preference と Transit Gateway は、もう一度見直したいです。
今の自分だと、まだ「なんとなくわかる」から抜け切れていません。
おわりに
Direct Connect が完全にわかった、という話ではありません。
むしろ、ようやく入口に立てた感じがあります。
ただ、資格勉強で見ていた言葉が、構成図とコンソールと ping の結果につながったのは大きかったです。
ANS を持っていても、触っていないものは触っていない。
そこは変にごまかさずに、今回のハンズオンで少し前に進めた、ぐらいの感覚です。
JAWS-UG 茨城、AWSJさま、会場の皆さま、ありがとうございました。