ハイブリッド接続 — オンプレとクラウドを安全に繋ぐ

さあ、今日は「ハイブリッド接続」という現実的なテーマです。

大企業の情報システム部長の立場を想像してください。東京に 20 年積み上げたオンプレミスデータセンターがある。AWS のスケーラビリティも必要。ですが「全部 AWS に移行します」と言ったら、経営層から「ネットワークを壊すな」と怒られます。

そこで現実的な課題が出てきます。オンプレミスと AWS を安全に繋ぐこと。それが今日のテーマです。実務では、Direct Connect、VPN、Client VPN、Transit Gateway などを組み合わせて、ハイブリッド環境を構築します。

接続方式の選択 — Direct Connect vs VPN

オンプレミスと AWS を繋ぐ方法は、基本的には 2 つです。Direct Connect と VPN。これを「道路」で考えるとわかりやすいです。

VPN はインターネットを使う一般道路です。コストがほぼゼロで、セットアップも簡単です。ですが IPsec 暗号化が必須で、最大帯域幅は 1.25 Gbps に制限されます。データセンターから大量のデータを流したい場合には不十分です。ただしバックアップ用途なら十分。

Direct Connect は AWS と直結する専用線で、物理的な光ファイバーを引きます。インターネットを経由しない独立したネットワークで、帯域幅も十分です。10 Gbps 接続も可能。ですが工事費がかかり、セットアップに時間がかかります。さらに重要な注意点があります。

Direct Connect は暗号化されません。これは試験に頻出です。高速で高信頼性ですが、通信内容は保護されていません。だからこそ Direct Connect を使う場合は、別途 MACsec（Media Access Control Security）でレイヤー 2 の暗号化を施す必要があります。MACsec は相互認証も可能。パケット改ざんも検知。

実務では「帯域いっぱい使いたい、予算もある」なら Direct Connect を選びます。「安く繋ぎたい、バックアップでいい」なら VPN です。ただし、最も賢い選択は両方同時に使うことです。冗長化により、1 本の接続が切れたら別の接続で通信を継続できます。AWS も推奨する構成です。BGP で動的ルーティング。DX が落ちたら VPN に自動切り替え。

VIF の 3 種類 — パブリック、プライベート、トランジット

Direct Connect の Virtual Interface（VIF）は 3 種類あります。

パブリック VIF。AWS のパブリック API（S3、DynamoDB など）にアクセス。インターネット経由ではなく、DX 経由。パフォーマンス向上。DDoS 攻撃にも強い。BGP で AWS のパブリックプレフィックスを受信。

プライベート VIF。VPC 内のプライベート IP にアクセス。EC2、RDS。DX Gateway 経由で複数 VPC に接続可能。BGP で VPC プレフィックスを受信。

トランジット VIF。Transit Gateway 経由で複数 VPC に接続。より柔軟なルーティング制御。

すべて MACsec で暗号化可能。BGP は認証オプション。プレフィックスフィルタで不正ルート広告をブロック。

クライアント側の接続 — Client VPN

でも、待ってください。今の話は「オンプレのネットワーク」と「AWS」を繋ぐ話。じゃあ、在宅勤務のあなたのノートパソコンは？リモートワーク。Starbucks の WiFi から AWS のプライベートサブネットにアクセスしたい。

これが AWS Client VPN。個別のクライアント（ラップトップ、スマホ）が VPN クライアント経由で VPC に接続する仕組み。

Client VPN の構成をイメージしてください。VPC の中に Client VPN エンドポイントを作る。これは VPN サーバー的な存在。リモートワーカーは、OpenVPN のようなクライアントアプリをインストールして、このエンドポイントに接続。すると、VPC 内のリソースに直接アクセスできる。

認証。3 つある。相互認証（TLS 証明書）。企業向け。Active Directory。既存ドメイン活用。SAML/SSO。クラウドネイティブ。Okta、Azure AD に統合。

スプリットトンネル。設定すれば、VPC へのトラフィックだけ VPN 経由。インターネットアクセスは直接。ユーザー体験向上。セキュリティとのバランス。

授権ルール。グループベースのアクセス制御。「engineers グループは production VPC へのアクセス可」「developers グループは dev VPC のみ」。IAM ポリシーと同じ考え方。

Client VPN — リモートワーカーが VPC に直接接続。認証方式は企業ポリシーで選ぶ。

試験でよくある質問：「リモートワーカーが AWS API を呼ぶときはどうする？」答え：アクセス管理は IAM。VPN で VPC に繋ぐのと、IAM でアクセス権限をチェックするのは別の層。両方必要。VPN でネットワークアクセス。IAM でリソースアクセス。

ネットワーク構成の複雑化 — Transit Gateway

ここからが、本当に現実的な話。

あなたの企業に支社が 3 つある。東京、大阪、シンガポール。それぞれにオンプレのデータセンター。そして、AWS に 3 つの VPC を持ってる（地域ごと）。全部が全部と通信できる必要がある。

さあ、何個の接続が必要ですか？計算してみてください。オンプレ 3 つ × AWS VPC 3 つ = 9 本。さらに、オンプレ同士も通信したい。Direct Connect か VPN で 3 本。AWS VPC 同士も通信したい。VPC ピアリングで… あ、これ複雑になる。管理不可能。

ここで出てくるのが AWS Transit Gateway。これ何か？暗号化が必要なコア接続をすべて 1 つの場所に集約するハブ。高速道路のジャンクション。すべての支店、すべての VPC が、このジャンクションを経由して通信する。

Transit Gateway のメリット： 中央集約 — すべての接続が 1 箇所で管理できる。DX、VPN、VPC アタッチメント。1 つの画面で見える。 スケーラビリティ — VPC や支店が増えても、ハブには繋ぐだけ。VPC ピアリングのメッシュ化の複雑性がない。 セグメンテーション — Transit Gateway Route Table で通信のルーティングを細かく制御できる。

セグメンテーション。これ大事。「東京オンプレと AWS Tokyo は通信 OK。でも東京オンプレとシンガポールの AWS は通信 NG」みたいなルールを作れる。ネットワーク分離。セキュリティの基本。ファイアウォール不要。ルートテーブルだけで実装。

Transit Gateway Route Table は、「どの接続から来たトラフィックを、どこに送るか」を決める。例えば：

Tokyo オンプレ → Tokyo VPC Tokyo オンプレ → Singapore VPC（ルートなし、破棄） Tokyo VPC ⟷ Osaka VPC（ピアリング的に）

こうすることで、ネットワーク境界を明確にする。「必要な通信だけ許可」の原則。ブラックホールルート。許可されないトラフィックは自動で破棄。ファイアウォール要らず。

Transit Gateway — ハイブリッド環境の中央ハブ。セグメンテーションで通信を厳密に制御。ルートテーブルは複数持てる。本番環境用、開発環境用、オンプレミス用。環境ごとの分離。

試験トリック：「Transit Gateway と VPC ピアリング、どっちが安い？」答え：VPC ピアリング。ただし、スケーラビリティなら Transit Gateway。小規模なら VPC ピアリング。大規模なら Transit Gateway。実務では、両方使い分ける。

通信の「見える化」 — VPC Flow Logs と VPC Traffic Mirroring

さあ、ここまで、接続方法を学びました。Direct Connect、VPN、Client VPN、Transit Gateway。

でも、疑問が出てくる。「本当に、正しい通信が流れてる？」「ハッカーが来たら、何が起きた？」「トラブルの時に『接続が無い』の原因は何か」

そこで必要なのが、ログ取得とパケットキャプチャ。

VPC Flow Logs — これは何か？VPC 内のすべてのネットワークインターフェース（ENI）を通過するトラフィックの情報を記録。送信元 IP、宛先 IP、ポート番号、プロトコル、許可/拒否。すべて記録。CloudWatch Logs か S3 に保存。

これで、「なぜ通信が失敗した？」を追跡できる。Security Group か NACL で拒否されたのか。ルートテーブルに該当ルートがないのか。すべて記録されてる。IP が到着したが、セキュリティグループで拒否。記録される。ルートテーブルに無い宛先。ルーティングできず。記録される。

でも、Flow Logs は「要約」に過ぎない。IP、ポート、許可/拒否。でも、「実際のパケットの中身は何か？」を知りたい場合がある。例えば、フォレンジック。セキュリティインシデントが起きたら、実際のデータを検査する必要がある。マルウェアがどこに通信してるのか。パケットペイロードを見ないと判定できない。

ここで出てくるのが VPC Traffic Mirroring。これ何か？本当のパケット（ペイロード含め）をコピーして、別のターゲットに送信する仕組み。

イメージ：高速道路の検問所。本当のトラフィックは VPC 内を行き来する。でも、同時に、そのトラフィックのコピーを、別の場所（例えば、IDS — Intrusion Detection System）に送信。IDS はそのコピーを分析して、「悪いやつが来た」って検出する。本当のトラフィックには影響なし。ただ監視。遅延なし。パフォーマンス低下なし。

フォレンジック VPC を別に構築。そこに Traffic Mirror 対象を配置。tcpdump で全パケットキャプチャ。S3 に保存。改ざん防止。Object Lock で WORM 化。

VPC Flow Logs — トラフィック情報の要約。ゼロトラスト検証の基本。ネットワークトラブル診断。

VPC Traffic Mirroring — フォレンジック・IDS 連携用。本当のパケットをコピー。セキュリティインシデント調査。

試験でよくある間違い：「全部のトラフィックをキャプチャしたいから、VPC Traffic Mirroring を使う」。間違い。大規模環境でパケット全コピーは、ネットワーク負荷が重い。コスト増。まず VPC Flow Logs で「何が起きたか」を把握。おかしい時だけ、Traffic Mirroring で詳細調査。段階的に。

セキュリティグループとNACL — ハイブリッド環境での設定

ここまで、接続方法を学びました。でも、接続できたからって、何でもアクセスできていいわけじゃない。

セキュリティグループ（SG）と NACL。これを、ハイブリッド環境で正しく設定する。

セキュリティグループ — インスタンス単位のファイアウォール。ステートフル。「入りは許可されてるなら、出口も自動で許可」。

NACL — サブネット単位のファイアウォール。ステートレス。「入りも出も、明示的に許可する」。ルール番号で優先度制御。

ハイブリッド環境だと、どうなるか？

例えば、オンプレのファイルサーバー（192.168.1.0/24）から、AWS の EC2（10.0.1.100）に NFS でアクセスしたい。

セキュリティグループでは：

インバウンド：192.168.1.0/24 の TCP ポート 2049 を許可 アウトバウンド：192.168.1.0/24 の TCP ポート 2049 を許可（ステートフルなので自動だが、明示）

NACL では：

インバウンド：192.168.1.0/24 の TCP ポート 2049 を許可 アウトバウンド：192.168.1.0/24 の TCP ポート 1024-65535 を許可（エフェメラルポート）

ステートレスだから、応答トラフィックも明示。これ忘れる人多い。セキュリティグループが許可していても、NACL で拒否されたら通信は来ない。両方チェック必須。

セキュリティグループ — ステートフル。インスタンス単位。 NACL — ステートレス。サブネット単位。応答トラフィックも許可する。

試験対策：「オンプレから VPC へのトラフィックが通らない」という問題が出たら、チェックリスト：

1. Direct Connect か VPN は接続されてるか？（物理レイヤー）
2. ルートテーブルに該当ルートがあるか？（ルーティング）
3. NACL のルールか？（サブネット）
4. セキュリティグループのルールか？（インスタンス）
5. Transit Gateway のルートテーブルか？（TGW 内部）

5 段階全部チェック。ハイブリッド環境は複雑。1 つ見落とすと、通信は来ない。トラブルシューティング時間が膨大になります。

Direct Connect - SLA と信頼性

Direct Connect について、もう 1 つ重要な話。

AWS は Direct Connect に対して、99.99% の可用性 SLA を保証します。「99.99% なら、ほぼ必ず繋がる」と思うかもしれません。でも、これは AWS 側の責任。あなたのオンプレ側は？ISP は？カスタマーゲートウェイは？

実際には、信頼性を高めるために：

1. 2 本の Direct Connect — 異なる AWS のロケーション（例：東京 と 大阪）— 物理的な多重化
2. 2 つの異なる ISP — ネットワークダイバーシティ — キャリアレベルの冗長化
3. VPN バックアップ — Direct Connect が切れたら、自動的に VPN に切り替わる — BGP で実装

これが冗長化。本当のセキュリティと信頼性。DX だけで 99.99% でも、ISP 障害で通信断の話も聞く。エンドツーエンドで 99.999% を目指すならば、複数経路必須。

Direct Connect SLA 99.99% — AWS 側の責任。エンドツーエンドは、ユーザー側の冗長化設計。

BGP を使うメリット。DX が落ちたら、自動的に VPN ルートがアップ。数秒でフェイルオーバー。手作業不要。人的ミスなし。

実務シナリオ — DX 障害時のフェイルオーバー

金曜夜中 11 時。東京のオンプレから AWS へ Direct Connect がつながっている。取引量が多い。1 分の停止が数百万円の損失。

真夜中、DX が物理的に切れた。どこかで光ファイバーが破断。修復に 4 時間かかるという通知。

その瞬間、AWS 側では BGP で VPN ルートがアップ。自動フェイルオーバー。2 秒以内に VPN に切り替わり。1.25 Gbps の帯域制限はあるが、通信は継続。取引も継続。損失は最小限。オンコール体制の人は 5 分で状況を把握し、朝のブリーフィングで報告。

これがハイブリッド環境での冗長化設計の威力。手作業で BGP ルート切り替えることなし。完全自動。信頼性と運用負荷削減。

まとめ — ハイブリッド接続の全体像

さあ、今日学んだこと、まとめます。

Direct Connect — 高速（10 Gbps 可能）、でも暗号化なし。MACsec で暗号化。専用線だから、費用がかかる。BGP で動的ルーティング。東京と大阪に 2 本引いて冗長化。VIF は 3 種類（パブリック、プライベート、トランジット）。

Site-to-Site VPN — インターネット経由。1.25 Gbps まで。IPsec で暗号化（IKEv2 推奨）。安い。Direct Connect のバックアップに最適。CloudHub で複数支店間通信。

Client VPN — リモートワーカー向け。Cognito や AD で認証。SAML/SSO も対応。スプリットトンネル設定で柔軟に。

Transit Gateway — 複数の接続を中央集約。セグメンテーションで通信を制御。ルートテーブルで「この VPC とあの VPC は通信できない」を実装。ブラックホールルート。

VPC Flow Logs — トラフィック要約。検証用。ネットワークトラブルの診断。CloudWatch Logs または S3 に保存。

VPC Traffic Mirroring — パケットキャプチャ。フォレンジック・IDS 連携。セキュリティインシデント発生時の詳細調査。

セキュリティグループ + NACL — 多層防御。両方チェック。ステートフル + ステートレス。

試験で大事なポイント：

Direct Connect は暗号化されていない（MACsec が必須） VPN は 1.25 Gbps 制限がある Transit Gateway のセグメンテーションで通信を厳密に制御 ハイブリッド環境の通信トラブルは 5 段階チェック 冗長化は SLA を高める（AWS 側と自社側の両方） BGP を使った自動フェイルオーバー VPC Flow Logs で問題の「要約」、Traffic Mirroring で「詳細」を分ける

これらを押さえて、試験に挑んでください。

次は、この全体を整理して、試験戦略を学びます。