AWSへの接続方式を見直すなかで、「今のインターネット経由のVPNのままで問題ないのか」「専用線であるAWS Direct Connectに切り替えるべきか」と迷う場面は少なくありません。本番系のハイブリッド接続や大容量データ転送、レイテンシの安定化を背景に、閉域接続の要件を整理し直したいと考える情シス・インフラ担当者の方も多いのではないでしょうか。

本記事では、AWS Direct Connectの概要、AWS Site-to-Site VPNとの違い、料金、接続方式、冗長化、導入プロセスまでを体系的に整理します。自社に向くケース・向かないケースを結論から示し、社内説明やベンダー比較に使える判断軸をお届けします。

まず結論｜AWS Direct Connectが向くケース・向かないケース

最初に結論からお伝えします。AWS Direct Connectは「すべての企業に必要な専用線」ではありません。要件によっては、AWS Site-to-Site VPNで十分なケースも多くあります。まずは自社がどちらに近いかを判断してください。

Direct Connectが向くケース

以下に複数当てはまる場合、Direct Connectの検討価値が高まります。

• 月あたり数TB以上の大容量データ転送が定常的に発生する
• 業務システムやデータベース連携で、低遅延と安定した品質（可用性・レイテンシ）が求められる
• 金融・医療・公共など、インターネットを経由しない閉域接続が要件となる
• オンプレミス資産を残しながら、ハイブリッド構成を全社標準にしたい

これらは、インターネット経由のVPNでは品質が保証しにくい領域です。専用線である閉域接続が効いてきます。

VPN（AWS Site-to-Site VPN）で十分なケース

一方、次のような場合はAWS Site-to-Site VPNで十分に運用できます。

• 転送データ量が小さく、多少の遅延やゆらぎを許容できる
• 短期間・小規模での接続、あるいは検証・PoC段階である
• できるだけ初期費用を抑え、短納期で接続を立ち上げたい

VPNはインターネット回線があれば数十分〜数時間で構築でき、回線手配も不要です。まずはVPNで始め、要件が固まった段階でDirect Connectへ移行する進め方も現実的です。

この記事で分かること（前半＝判断／後半＝設計）

本記事は、前半と後半で役割を分けています。

• 前半（この結論〜要件整理まで）：Direct Connectを「採用すべきか」を判断するための情報です。概要、VPNとの違い、ユースケース、料金、要件整理を扱います。
• 後半（設計〜導入プロセス）：採用が固まった方が「どう設計・構築するか」を検討するための情報です。VIFやゲートウェイ、冗長化、導入手順を扱います。

まず採用可否を知りたい方は、前半だけでも判断材料がそろう構成です。

AWS Direct Connectとは何か

AWS Direct Connectは、自社の拠点やデータセンターとAWSを、インターネットを経由せずに専用線でつなぐ接続サービスです。通信がインターネットを通らないため、帯域が安定し、可用性・レイテンシの面でも予測しやすくなります。

基本の仕組み（ロケーション・接続方式・仮想インターフェイス）

Direct Connectは、大きく3つの要素で成り立ちます。

• ロケーション：AWSと物理的に接続できる相互接続ポイント（データセンター）です。国内外に多数あり、自社拠点から近い、あるいは通信事業者経由で届くロケーションを選びます。
• 接続方式：物理ポートの提供形態で、専用接続（Dedicated Connection）とホスト接続（Hosted Connection）があります。
• 仮想インターフェイス（VIF）：1本の物理接続の上に作る論理的な通信路です。VIFの種別によって、つなげる先（VPCかAWSのパブリックサービスか）が変わります。

なお、ロケーション内でAWS側の機器と自社側の回線を物理的につなぐ配線を、クロスコネクトと呼びます。

専用接続（Dedicated Connection）とホスト接続（Hosted Connection）の違い

接続方式は、自社の規模や運用体制に応じて選びます。

項目	専用接続（Dedicated Connection）	ホスト接続（Hosted Connection）
契約先	AWSと直接契約	Direct Connectパートナー経由
帯域の目安	1Gbps / 10Gbps / 100Gbps	50Mbps〜10Gbpsなど柔軟
向くケース	大容量・自社で回線を管理したい	小〜中容量・短納期で始めたい
調達の手間	回線手配・設計を自社主導	パートナーが多くを代行

小さく早く始めたい場合はホスト接続、大容量かつ自社主導で管理したい場合は専用接続が基本的な選び分けです。

できること／できないこと

Direct Connectで「できること」と「できないこと（注意点）」を整理します。

• できること：VPCへの閉域接続、S3などパブリックサービスへの安定接続、複数リージョン・複数VPCへの集約接続、VPNと組み合わせた冗長構成。
• できないこと・注意点：Direct Connectの物理接続そのものは、既定では通信が暗号化されません。暗号化が必要な場合は後述のMACsecやIPsecを組み合わせます。また、1本だけの接続では回線障害時に通信が止まるため、冗長化は別途設計が必要です。

「専用線だから安全・冗長」と思い込まず、暗号化と冗長化は設計項目として扱う点が重要です。

つなげる先の選択肢（VPC向け／パブリックサービス向け）

Direct Connectでつなげる先は、大きく2種類です。

• VPC向け：自社の仮想ネットワーク（VPC）内のシステムへ、閉域で接続します。
• パブリックサービス向け：S3やその他のAWSパブリックサービスへ、インターネットを経由せず安定的に接続します。

どちらに接続するかは、後述するVIFの種別（Private VIF / Public VIF / Transit VIF）で決まります。

VPN接続（AWS Site-to-Site VPN）との違い

Direct Connect採用を判断するうえで、最も比較されるのがAWS Site-to-Site VPNです。両者の違いを4つの観点で整理します。

通信経路の違い（インターネット経由と閉域接続）

最大の違いは通信経路です。AWS Site-to-Site VPNはインターネットを経由します。一方、Direct Connectはインターネットを通らない閉域接続です。この違いが、以下の性能やセキュリティの差につながります。

性能・可用性・レイテンシの比較

VPNはインターネットの混雑や経路変動の影響を受けるため、帯域やレイテンシが変動しやすい特性があります。Direct Connectは専用の経路を使うため、帯域が安定し、レイテンシのゆらぎも抑えられます。可用性・レイテンシを重視する本番系ワークロードほど、この差が効いてきます。

暗号化の違い（DX単体とIPsec VPN）

AWS Site-to-Site VPNは、通信がIPsecで暗号化されます。対してDirect Connect単体では、既定で通信は暗号化されません。閉域である点は安心材料ですが、暗号化要件がある場合は、Direct Connect上でIPsecを併用するか、対応環境でMACsecを利用します。

どちらを選ぶかの判断軸

以下の比較表を、社内説明のたたき台としてご活用ください。

比較軸	Direct Connect	AWS Site-to-Site VPN
通信経路	閉域接続（専用）	インターネット経由
帯域・品質	安定・大容量に強い	変動あり・小〜中容量向き
レイテンシ	低く安定	変動しやすい
暗号化	既定なし（MACsec/IPsec併用）	IPsecで標準暗号化
導入スピード	回線手配で数週間〜	数時間〜で構築可能
初期コスト	高め	低い

安定・大容量・低遅延ならDirect Connect、手軽さ・短納期・低コストならVPN、が基本の判断軸です。

Direct Connectを検討すべきユースケース

ここでは、実務で多いユースケースに絞って整理します。

大容量データ転送がある場合

データ分析基盤へのデータ連携、バックアップやDR、映像・設計データの転送など、大容量データ転送が定常的に発生する場合、インターネット経由では時間もコストも読みにくくなります。Direct Connectの安定帯域は、こうした転送の予測可能性を高めます。

低遅延・安定した品質が必要な場合

基幹システムとオンプレミスの連携、リアルタイム性が求められる業務、データベースの同期などでは、レイテンシのゆらぎが業務影響に直結します。閉域接続による安定品質は、こうしたワークロードの信頼性を支えます。

ハイブリッド構成を標準にしたい場合（オンプレ資産を残す前提を含む）

オンプレミスの資産を段階的に活かしながらAWS活用を進める企業では、拠点とクラウドを安定してつなぐ土台が必要です。一般的な導入例では、ハイブリッド接続を全社標準として整備することで、部門ごとに個別最適化されていた接続方式が統一され、運用の切り分けや監視が容易になったと報告されています。これは定量化しにくい領域ですが、運用工数の削減という形で効果が現れやすいポイントです。

料金の考え方と費用対効果

Direct Connectの料金は「AWSに払う費用」と「AWS以外に払う費用」に分けて考えると整理しやすくなります。ここを分けずに見積もると、社内説明で費用の全体像を見誤りがちです。

AWSにかかる料金（ポート時間・データ転送料）

AWSに支払う料金は、主に次の2つです。

• ポート時間：Direct Connectのポートを確保している時間に応じた料金です。帯域（例：1Gbps、10Gbps）と接続方式によって単価が変わります。
• データ転送料：AWSからインターネット等へ送出するデータ量（アウトバウンド）に応じた料金です。Direct Connect経由の転送は、通常のインターネット経由より割安な単価が設定されています。

AWS以外の費用（回線費・パートナー費・クロスコネクト）

見落とされやすいのが、AWS以外にかかる費用です。

• 通信事業者への回線費（ロケーションまでの回線手配にかかる費用）
• Direct Connectパートナーへの費用（ホスト接続やマネージド運用を利用する場合）
• ロケーション内のクロスコネクト費用

これらはAWSの請求には含まれません。総コストで比較しないと、費用対効果を正しく評価できない点に注意が必要です。

VPNとのコスト比較で見るべき点

VPNとの料金比較では、単純な月額だけでなく、次の観点を含めて判断します。

• 転送データ量が増えたときのデータ転送料の伸び方
• 品質改善による業務価値（遅延削減・障害減少の効果）
• 冗長化を含めた場合の総額

費用対効果が出やすい条件

一般に、転送データ量が大きいほど、またレイテンシ・可用性が業務価値に直結するほど、Direct Connectの費用対効果は出やすくなります。逆に、小容量・低頻度・品質要件が緩い場合は、VPNの方が費用対効果に優れることが多い、と言えます。

導入すべきか判断するための要件整理

「採用すべきか」を決めるには、次の4点を整理しておくと、稟議やベンダー比較がスムーズになります。ここは採用の是非を決めるための軸であり、採用後の進め方は後半で扱います。

必要な帯域の見積もり方

現在のトラフィックのピーク値と平均値を把握し、将来の増加を見込んで帯域を見積もります。過大な帯域は無駄なコストに、過小な帯域は品質低下につながるため、実測データを起点にするのが確実です。

SLA・可用性目標・障害の許容度

どの程度の可用性（SLA）を目標とするか、障害時にどれだけの停止を許容できるかを定めます。この目標が、後述する冗長化の設計レベルを決めます。

運用体制と責任分界

Direct Connectは、AWS・通信事業者・パートナー・自社が関与する多者構成になりがちです。どこまでを誰が持つかという責任分界を、契約前に明確にしておくことが重要です。障害時の切り分けや問い合わせ先の混乱を防げます。

稟議・社内説明で整理しておく観点

社内説明では、次の観点をまとめておくと通りやすくなります。

• なぜVPNではなくDirect Connectなのか（品質・容量・閉域要件）
• 総コスト（AWS料金＋回線費＋パートナー費）
• 可用性目標と冗長化方針
• 導入スケジュールと責任分界

自社に向くか、まず相談してみませんか？ 「うちのトラフィック量ならVPNとDirect Connectのどちらが妥当か」「総コストの目安を知りたい」といった段階のご相談も歓迎です。要件整理のたたき台づくりから、テクノプロがお手伝いします。

接続構成と冗長化・セキュリティの設計｜詳しく検討する方向け

ここからは、Direct Connectを具体的に設計する段階の論点です。用語が増えますが、それぞれ「何を決めるための選択肢か」を意識すると整理しやすくなります。

接続の種類と経路の考え方

仮想インターフェイス（VIF）は、つなげる先によって3種類を使い分けます。

• Private VIF：単一のVPCへ閉域で接続する場合に使います。
• Public VIF：S3などAWSのパブリックサービスへ、インターネットを経由せず接続する場合に使います。
• Transit VIF：後述のTransit Gatewayと連携し、複数VPCへまとめて接続する場合に使います。

経路の指定には、BGPというルーティングの仕組みを使います。BGPは、どのネットワーク宛ての通信をどの経路に流すかを、経路情報（プレフィックス）の交換で自動的に決める仕組みです。オンプレミスとAWSの双方でBGPを設定し、経路を制御します。

拠点とVPCのつなぎ方（VGW／DXGW／TGW）とマルチアカウント設計

拠点とVPCをどうつなぐかは、規模に応じて3つのゲートウェイから選びます。

ゲートウェイ	主な役割	向くケース
Virtual Private Gateway（VGW）	単一VPCへの接続点	VPCが少なくシンプルな構成
Direct Connect Gateway（DXGW）	複数リージョン・複数VPCへ集約	リージョンをまたぐ接続
Transit Gateway（TGW）	多数のVPC・拠点を中央集約	マルチアカウント・大規模

VPCが増える、あるいは複数アカウントで運用するマルチアカウント構成では、TGWで中央集約する設計が管理性の面で有利です。小規模でVPCが1つならVGWで十分です。

冗長化と可用性を高める考え方

Direct Connectは1本だけだと単一障害点になります。可用性を高めるには冗長化が欠かせません。

• ロケーション分散・回線分散：複数のロケーションや異なる回線経路で接続し、片方が障害でも通信を継続します。
• 機器冗長：自社側のルーターなどを冗長化し、機器故障時にフェイルオーバーします。
• VPNバックアップ：Direct Connectを主回線、VPNを予備とする構成です。低コストで一定の冗長性を確保できますが、切替時は帯域・品質がVPN相当に落ちる点に注意が必要です。常時同等の品質を求める本番系では、Direct Connectの二重化が適します。

AWSは冗長構成の推奨レベルを整理したAWS Direct Connect Resiliency Toolkitを提供しています。目標とする可用性に応じて推奨構成を確認できるため、設計の出発点として有用です。

暗号化要件がある場合の選択肢2つ

暗号化要件がある場合の選択肢は主に2つです。

• MACsec：対応するロケーション・接続で、物理レイヤーに近い層で高速に暗号化します。
• IPsec：Direct Connect上にVPNを重ね、IPsecで暗号化します。

監視は、Amazon CloudWatchで接続状態やトラフィックのメトリクスを取得します。しきい値超過時のアラート設定や、ログを用いた障害の切り分けにより、運用時の可視性を確保します。

導入プロセスと進め方

採用が固まったら、実際の進め方です。ここでは実行手順に絞ります（帯域・SLA・責任分界の判断は前半の要件整理を参照してください）。

要件定義から回線手配・開通までの流れ

まず要件を定義し、接続するロケーションを選定します。次に通信事業者への回線手配を行い、クロスコネクトを設定して物理接続を開通させます。回線手配には数週間〜数か月かかることもあるため、スケジュールには余裕を見ておきます。

パートナー選定で確認すべきこと

Direct Connectパートナーを利用する場合、次の点を確認します。

• 対応ロケーションと提供可能な帯域
• ホスト接続・マネージド運用の範囲
• 障害時のサポート体制と責任分界
• 冗長構成やVPNバックアップへの対応可否

進め方・見積りのご相談はこちら ロケーション選定や回線手配、パートナーの比較は、初めてだと判断に迷いやすい領域です。テクノプロは要件整理から設計・構築、パートナー調整までを一貫して支援します。具体的な見積りやスケジュール感のご相談も承ります。

設計・構築で必要になる情報

構築段階では、次の情報を事前にそろえておくとスムーズです。

• ASN（自社のBGP用の番号）
• BGPの設定情報と交換する経路（プレフィックス）
• 使用するIPアドレス範囲
• VLANの割り当て

テスト計画と移行計画

開通後は、疎通確認、経路の切替テスト、冗長化のフェイルオーバー確認を行います。本番移行では、既存のVPNからの切替手順や切り戻し手順を用意し、業務影響を最小化する計画を立てます。

よくある質問

Q.Direct Connectだけでインターネット接続はできるか

A.Public VIFを使えばAWSのパブリックサービスへは閉域で接続できますが、一般的なインターネット接続の代替にはなりません。インターネットへの出口が必要な場合は、別途その経路を用意します。

Q.小規模でも導入する価値があるケースはあるか

A.あります。データ量が小さくても、閉域接続が要件（金融・医療・公共など）である場合や、レイテンシの安定が業務価値に直結する場合は、小規模でも検討価値があります。この場合はホスト接続（Hosted Connection）で小さく始める選択が現実的です。

Q.障害時はどこから切り分けるべきか

A.まずCloudWatchのメトリクスやログで、どの区間で異常が起きているかを確認します。そのうえで、責任分界に沿って自社・パートナー・通信事業者・AWSの担当範囲を切り分けます。事前に責任分界と連絡先を明確にしておくことが、復旧時間の短縮につながります。

あわせて読みたい関連トピック

• オンプレからクラウドへの移行｜メリットや注意点、7つの手法と手順
• AWS Client VPN導入判断ガイド｜費用・設計・運用のポイント
• AWS PrivateLinkとは？向き不向きと使い分けをわかりやすく解説

---

まとめ

AWS Direct Connectは、インターネットを経由しない閉域接続により、大容量・低遅延・高い可用性を求める場面で力を発揮する接続方式です。一方で、小容量・短納期・低コストを優先する場合は、AWS Site-to-Site VPNで十分なケースも多くあります。

採用可否は、必要帯域・SLA・暗号化要件・総コスト・責任分界を整理したうえで、VPNとの比較軸に照らして判断することが重要です。採用が固まったら、VIFやVGW／DXGW／TGWの選定、冗長化とセキュリティ、導入プロセスへと段階的に設計を進めていきます。

次のアクションとして、まずは自社のトラフィック量と品質要件を棚卸しし、VPNとDirect Connectのどちらが妥当かを比較してみてください。要件整理から設計・構築、パートナー調整までを一貫してご支援できます。自社に適した構成の判断や見積りでお困りの際は、ぜひテクノプロにご相談ください。

【CV導線③】AWS接続の見直し、まずはご相談ください Direct Connectが自社に向くかの判断から、設計・構築・運用までワンストップで対応します。現状の課題整理や概算見積りのご相談も歓迎です。お気軽にお問い合わせください。