教科書通りにはいかないAWS構築：現場で学ぶ「引き算の設計」

エンタープライズのシステム構築において、「オンプレミス環境からクラウド上のデータベース（SaaS）へ、インターネットを通さずに安全に接続したい」という要件は非常に多くあります。

今回は、オンプレミスのサーバー（Qlik Replicate等）から、AWSを経由してデータウェアハウス「Snowflake」へセキュアに接続するためのネットワーク構築について、そのアーキテクチャの設計思想と通信の仕組みを中心に解説します。インフラ構築を学び始めた初心者エンジニアの方にも分かりやすくまとめました。

目次

1. アーキテクチャの目的と全体像
2. コアコンポーネントの役割と設計思想
   • ① AWS PrivateLink（Snowflakeへのセキュアな経路）
   • ② Route 53 Resolver Inbound Endpoint（ハイブリッド環境の名前解決）
   • ③ Transit Gateway (TGW)（拡張性とセキュリティを両立するハブ）
3. 【構成図解】通信フローの全体像
4. 現場のリアル①：突然の回線仕様変更と「VGWへのダウングレード」
5. 現場のリアル②：立ちはだかる「DNSの掟」
6. まとめ：インフラエンジニアに求められる「理想を描く力」と「現実と折り合う柔軟性」

1. アーキテクチャの目的と全体像

今回の最大の目的は、「オンプレミスからSnowflakeまでの通信を、完全に閉域網（インターネットに出ない安全な道）で完結させること」です。

これを実現するため、AWSの強固なネットワークサービス群を組み合わせたセキュアかつスケーラブルなアーキテクチャを設計しました。中心となるのは以下の3つのコンポーネントです。

• AWS PrivateLink: SaaSへのプライベートな接続口
• Route 53 Resolver Inbound Endpoint: オンプレミス向けの名前解決インターフェース
• Transit Gateway (TGW): 高度なルーティングを担うネットワークハブ

2. コアコンポーネントの役割と設計思想

① AWS PrivateLink（Snowflakeへのセキュアな経路）

Snowflakeは本来、インターネット経由でアクセスするSaaSです。しかし、「AWS PrivateLink」を利用することで、対象のVPC内に「Snowflakeへ直結するVPCエンドポイント（ENI）」を作成できます。
これにより、データはパブリックインターネットに出ることなく、AWSのバックボーンネットワークのみを経由して極めて安全にSnowflake環境へ到達します。

② Route 53 Resolver Inbound Endpoint（ハイブリッド環境の名前解決）

オンプレミスからPrivateLink経由でアクセスするには、Snowflakeのドメイン（例: privatelink.snowflake.app）を、VPCエンドポイントのプライベートIPアドレスに変換する必要があります。
そこでVPC内に「Inbound Endpoint」を配置し、オンプレミス側のDNSサーバーから「このドメインのIPを教えて」というクエリをAWS側へフォワード（転送）できる構成としました。

③ Transit Gateway (TGW)（拡張性とセキュリティを両立するハブ）

オンプレミスとAWSを結ぶ専用線（Direct Connect）と、VPCを繋ぐ心臓部としてTGWを採用しました。
最大の設計のこだわりは、「VPC用」と「オンプレミス（DX）用」でTGWのルートテーブルを完全に分離したことです。行きと帰りの通信経路を厳密に制御し、「意図しないネットワーク同士が勝手に繋がってしまう」というセキュリティリスクを根本から防ぐ、非常に品質の高い構成を目指しました。

3. 【構成図解】通信フローの全体像

このアーキテクチャにおけるオンプレミスからSnowflakeまでの具体的な通信の流れは以下の通りです。

1. 名前解決（オンプレミス）
   オンプレミスのサーバーが privatelink.snowflake.app のアクセス要求を出す。オンプレミスのDNSサーバーは、AWS上の Route 53 Resolver Inbound Endpoint へ問い合わせを転送し、VPCエンドポイントのプライベートIPアドレスを取得する。
2. データ送信（ハイブリッド通信）
   サーバーは取得したIPアドレス宛てにデータを送信する。通信は Direct Connect（Transit VIF） という太い専用線を通り、AWSの Transit Gateway (TGW) に到達する。
3. ルーティング（AWSコアネットワーク）
   TGWの厳密に分離されたルートテーブルによって、通信は安全に対象のVPCへとルーティングされる。
4. Snowflakeへの到達（AWS内バックボーン）
   VPC内に配置された VPCエンドポイント（AWS PrivateLink） が通信を受け取り、AWSの閉域網を通って直接Snowflakeへデータを送り届ける。

以上が、エンタープライズのシステム構築において推奨されるベストプラクティスに基づいた「理想の設計」です。

4. 現場のリアル①：突然の回線仕様変更と「VGWへのダウングレード」

アーキテクチャ設計は完璧でも、実際のプロジェクト進行中には想定外の事態が起こります。

TGWに接続するためには「Transit VIF」という回線が必要なのですが、他社（回線提供側）の申請ミスにより、1対1接続専用の「Private VIF」で開通してしまいました。Private VIFはTGWに接続できません。
物理的な回線の再申請には数週間から1ヶ月の時間がかかるため、プロジェクトの納期に致命的な遅れが生じます。

そこで下した決断が、「回線に合わせて、アーキテクチャをリフォームする」という方針転換でした。

Private VIFを受け入れるため、心臓部のネットワークリソースをTGWから「Virtual Private Gateway (VGW)」に変更しました。これにより、アーキテクチャ全体が「ハブ＆スポーク」から「ポイントツーポイント」へと変化します。

具体的には、TGWという最新の交通ハブを介して複数のネットワークを繋ぐ当初の理想構成を断念し、開通済みの回線仕様に合わせてオンプレミスとVPCを1対1で直結する構成に切り替えました。この判断は、将来の拡張性や高度なルーティング機能を一部諦める代わりに、プロジェクトの納期という絶対的な制約を守るための現実的な最適解でした。

• TGW（当初の予定）： 複数のネットワークを高度に制御できる最新のインターチェンジ。
• VGW（変更後）： 1つのVPCに直接繋ぐための専用ドア。シンプルだが将来の拡張性には劣る。

TGWでこだわっていた「複数ルートテーブルの分離」といった高度な制御はできなくなりましたが、VPCのルートテーブルで直接経路を制御するシンプルな構成にコードを書き直し、なんとか回線との辻褄を合わせることに成功しました。

5. 現場のリアル②：立ちはだかる「DNSの掟」

無事にネットワークが繋がっても、オンプレミス側のDNSサーバーに「Snowflake宛の通信はAWSに聞いてね」という転送（フォワード）設定を入れてもらう必要があります。しかし、DNS管理部門からは以下のような理由で設定を渋られるという壁にもぶつかりました。

「 privatelink.snowflake.app のような広い範囲のドメインを全てAWSに転送する設定は、将来他のシステムに影響が出るかもしれないから入れたくない」

これも現場のリアルです。技術的に可能であっても、全社のインフラを司る部門から運用責任やリスク管理の観点でストップがかかることは多々あります。最悪の場合、DNSサーバーを使わず、対象のサーバー（Qlik）の hosts ファイルに直接IPアドレスを書き込むという、泥臭い（しかし確実な）回避策も視野に入れてプロジェクトは進んでいます。

6. まとめ：インフラエンジニアに求められる「理想を描く力」と「現実と折り合う柔軟性」

今回の構築プロジェクトを振り返ると、クラウドインフラを設計・構築するエンジニアにとって重要な2つの視点が浮き彫りになります。

1. ベストプラクティスを理解し「理想の設計」を描く技術力
TGWを用いたルート分離やAWS PrivateLinkの活用など、セキュリティとスケーラビリティを両立したアーキテクチャをゼロから設計できる力は、エンジニアの根幹です。AWSの各コンポーネントが「どのような仕組みで通信を制御しているか」を論理的に理解しているからこそ、要件を満たす最適解を導き出すことができます。

2. 制約の中で最適解を見つける「引き算の設計（ダウングレード）」の柔軟性
実際の現場では、他部門のルール、組織のサイロ化、他社のミス、そして絶対的な「納期」といったビジネス上の制約が必ず存在します。今回、TGWからVGWへの変更を決断できたのは、「TGWでなくても要件は満たせる」という代替案の引き出しがあったためです。
ベストプラクティス（理想）を知っているからこそ、安全に機能を削ぎ落とす（現実への適応）ことができるのではないかと思います。

技術的な正論を振りかざしてプロジェクトを停滞させるのではなく、論理的な裏付けを持ちながら「今の状況における最善手」を打ち出せること。それこそが、エンタープライズ環境で価値を発揮するクラウドエンジニアの真の腕の見せ所だと言えるでしょう。