はじめてのAmazon VPC構築レポート(2)_構築編
こんにちは! 株式会社HESの望月です。
今回は、前回の投稿「はじめてのAmazon VPC構築レポート(1)_基礎調査から設計まで」のつづき、「技術合宿2日目」のレポートです。
合宿2日目では、1日目で得た知識を頼りにAmazon VPCの構築にチャレンジします。
- ネットワークの基礎調査 (1日目) ←前回
- Amazon VPCの基礎調査 (1日目) ←前回
- Amazon VPCの構成図を作成 (1日目) ←前回
- Amazon VPCをトライアンドエラーで構築 (2日目) ←本記事の内容
- Amazon VPCの構成図を再度作成 (2日目) ←本記事の内容
構築中はたくさんの問題に直面しましたが、試行錯誤の末、最後にはAmazon VPC上にAPサーバーを稼働させることができました。
本記事では、成功手順だけでなく失敗談も含めて共有します。これからVPC構築に挑む方の参考になれば幸いです！
1. 前回の投稿(合宿1日目)の振り返り
まずは、前回の投稿の振り返りです。
私は会社の技術合宿に参加し、初めてAmazon VPCの構築に挑戦することになりました。
合宿の最終目標は以下の3点でした。
合宿1日目では、ネットワークやAmazon VPCの基礎調査を実施しました。
その成果が以下の「VPCネットワーク構成図」です。
■ VPCネットワーク構成図 (初稿)
しかし、この構成図（初稿）には足りない部分がありました。
合宿2日目では、この図を基に構築作業を実施しましたが、その過程で多くの壁にぶつかります。
次章より、その試行錯誤の記録をまとめていきます。
2. 構築作業の流れ（合宿2日目）
合宿2日目は、1日目に得た知識を基に以下の手順で構築を進めることにしました。
作業はすべて AWSマネジメントコンソール 上で実施します。
次章から、各工程について「作業内容 → 発生した問題 → 結果」の順に、時系列で詳しく説明していきます。
【構築ステップ】
- Step 1: VPCとサブネットの作成
- Step 2: セキュリティグループの作成
- Step 3: EC2インスタンスの起動
- Step 4: ロードバランサーの作成
- Step 5: EC2へのアクセス確認
- Step 6: アプリケーションの実行環境を構築
3. Step1: VPCとサブネットの作成
● 作業内容
AWSマネジメントコンソールから「VPCを作成」を選択しました。
VPCの設定画面では、VPCだけでなくサブネット等を一括で作成できる「VPCなど」機能を選択しています。
設定値は以下の通りです。
【主な設定】
- 名前: my-vpc
- アベイラビリティーゾーン (AZ) の数: 1
- IPv4 CIDR: 10.0.0.0/16
- パブリックサブネットの数: 1
- パブリックサブネット CIDR ブロック: 10.0.1.0/24
- プライベートサブネットの数: 1
- プライベートサブネット CIDR ブロック: 10.0.2.0/24
● 結果
「VPCを作成」をクリックすると、VPC、サブネット、ルートテーブル、インターネットゲートウェイなどが自動的に作成され、関連付けも完了しました。
4. Step 2: セキュリティグループの作成
● 作業内容
VPCダッシュボードから「セキュリティグループを作成」をクリックし、基本設定を行いました。
【基本設定】
| 項目 | 設定値 |
|---|---|
| セキュリティグループ名 | my-sg |
| VPC | my-vpc(Step 1で作成) |
| インバウンドルール | ※ 以下に別記 |
| アウトバウンドルール | なし |
続いて、インバウンドルール（外部からの接続許可）を設定しました。
この時、SSH接続のソース（接続元）設定にて 「マイIP」 を選択しました。
管理者(自分)からの通信のみを許可するようにしたいためです。
※「マイIP」を選択すると、現在接続しているネットワークのグローバルIPアドレスが自動入力されます。
【インバウンドルールの設定（当初）】
| タイプ | ポート範囲 | ソース | 意図 |
|---|---|---|---|
| カスタムTCP | 80 | 0.0.0.0/0 | HTTPアクセス (Web) |
| カスタムTCP | 8000 | 0.0.0.0/0 | MCPO用 |
| カスタムTCP | 3000 | 0.0.0.0/0 | OpenWebUI用 |
| SSH | 22 | マイIP | 管理者（自分）のみ許可 |
● 発生した問題
Step2以降の作業中に合宿所のWi-Fiが不安定になったため、一時的にネットワークをスマートフォンのテザリングに切り替えたところ、SSH接続ができなくなってしまいました。
● 結果
「セキュリティグループを作成」をクリックし、セキュリティグループが作成されました。
5. Step 3: EC2インスタンスの起動
● 作業内容
AWSマネジメントコンソールで「EC2」サービスから「インスタンスを起動」をクリックし、基本設定を行いました。
| 項目 | 設定値 |
|---|---|
| 名前 | my-app |
| AMI | Ubuntu Server 24.04 LTS (HVM),SSD Volume Type |
| インスタンスタイプ |
t3.xlarge
|
| キーペア | 新しいキーペアを作成 |
| ネットワーク設定/VPC | my-vpc |
| ネットワーク設定/サブネット | 作成したプライベートサブネット |
| ネットワーク設定/パブリックIPの自動割り当て | 無効化 |
| ネットワーク設定/ファイアウォール | 作成したセキュリティグループ(my-sg) |
| ストレージ | 30 GiB gp3ボリューム |
● 結果
「インスタンスを起動」をクリックし、EC2インスタンスが作成されました。
6. Step 4: ロードバランサーの作成
● 作業内容
EC2ダッシュボードから「ロードバランサーの作成」を選択しました。
当初はWebアプリに最適な ALB (Application Load Balancer) を作成する予定でしたが、後述の問題により作成できず、 NLB (Network Load Balancer) を採用しました。
【ロードバランサー設定 (NLB)】
| 項目 | 設定値 |
|---|---|
| ロードバランサータイプ |
NLB
|
| ロードバランサ名 | my-lb |
| スキーム | インターネット向け |
| VPC | my-vpc |
| アベイラビリティーゾーンとサブネット | パブリックサブネットがあるAZ / パブリックサブネット |
【リスナーとターゲットグループの設定】
各ポートへの通信を、対応するターゲットグループ（EC2）へ転送する設定を行いました。
| ターゲットグループ名 | プロトコル | ポート |
|---|---|---|
| my-dify-tg | TCP | 80 |
| my-mcpo-tg | TCP | 8000 |
| my-owui-tg | TCP | 3000 |
| my-ssh-tg | TCP | 22 |
● 発生した問題
ALBの作成画面を進めたところ、「サブネットの選択」にてエラーとなり、作成を完了できませんでした。
7. Step 5: EC2へのアクセス確認
● 作業内容
Step 4で作成したNLBを経由して、WebアクセスとSSH接続の確認を行いました。
- SSH接続: ターミナルからNLBの「DNS名」を指定しキーペアでSSH接続。
- webサーバーのインストール SSHにてWebサーバー(Nginx)をインストールする。
- Webアクセス: ブラウザにNLBの「DNS名」を入力してアクセス。
● 結果
無事にSSH接続が成功し、Nginxの初期ページが表示されました。
ここではエラーは発生しませんでしたが、設計段階で私が抱いていた 「プライベートサブネットへの正しいアクセス方法」 について、調査した内容をまとめます。
8. Step 6: アプリケーションの実行環境を構築
● 作業内容
EC2にSSH接続し、アプリケーションの実行環境を構築しました。
具体的には、Docker Engineをインストールし、以下の3つのアプリケーションコンテナを起動しました。
- Dify: LLMアプリ開発プラットフォーム
- OpenWebUI: 大規模言語モデルのWeb UI
- MCPO: OpenWebUIのMCP機能拡張
各アプリケーションの構築は、以下の公式ドキュメントを参照して実施しました。
- Docker: Ubuntu | Docker Docs
- Dify: Deploy with Docker Compose - Dify Docs
- OpenWebUI: Quick Start | Open WebUI
- MCPO: MCP Support | Open WebUI
● 発生した問題
Dockerのインストールが完了し、OpenWebUI のコンテナを起動した瞬間、以下2つのトラブルが発生しました。
1. コンテナ起動中にSSHが強制切断される
OpenWebUIのコンテナを起動(docker run ...)した数秒後、ターミナルの反応がなくなり、SSH接続が強制的に切断されました。
その後、何度接続を試みてもタイムアウトしてしまいました。
2. シリアルコンソールへのログイン失敗
- でSSHが強制切断されたため、調査のために「EC2シリアルコンソール」からの接続を試みましたが、ログインパスワードが分からず、完全に締め出されてしまいました。
● 結果
インスタンスタイプの変更後、すべてのアプリケーション（Dify, OpenWebUI, MCPO）が正常に起動しました。
ブラウザからNLBのDNS名にポートを指定してアクセスし、各アプリケーションの画面が表示されることを確認しました。
9. 最終的なVPCネットワーク構成図
数々のトライアンドエラーを経て、最終的に構築された環境のネットワーク構成図を再度作成しました。
初稿（1日目時点）と比較して、実際の構築作業で得られた知見（NLBの採用、Docker構成の具体化など）を反映させています。
■ VPCネットワーク構成図 (最終版)
● 初稿からの主な変更点・改善点
構築時のトラブルシューティングを通じて、以下の3点を修正・詳細化しました。
1. ロードバランサーの変更 (ALB → NLB)
初稿ではL7ロードバランサの「ALB」を想定していましたが、シングルAZ構成でも作成可能なL4ロードバランサ「NLB」に変更しました。
2. EC2内部構造（コンテナ通信）の可視化
EC2インスタンス内部の各アプリケーションコンテナの通信フローを描き足しました。
3. IPアドレスと通信経路の明記
各サブネットのCIDRや、想定されるIPアドレス、通信の方向（矢印）を具体的に記載しました。
10. まとめ
本記事では、技術合宿2日目の「Amazon VPC構築」における試行錯誤（トライアンドエラー）の記録をまとめました。
今回の合宿では、「Amazon VPC上にAPサーバーを構築し、稼働させる」 というメインゴールを達成することができました。
しかし数々の問題に直面したことで、新たな課題が見つかりました。
- ネットワークの根本的な理解が足りていない
- PCからサーバーまでの通信シーケンス
- IPアドレスの仕組み
- 本番環境を想定した設計ができていない
- AZの冗長化
- ロードバランサによる適切な負荷分散
- 正しいヘルスチェックの設計
- 踏み台サーバを利用したセキュアな構成
2日間の技術合宿のレポートは、今回で終了です。
しかし、上記の課題を克服するために、合宿後に追加調査を実施しました。
次回は、その追加調査の内容をまとめた記事を投稿したいと思います。
最後までお読みいただき、ありがとうございました！
参考
記事作成にあたり、以下サイトの情報を参考にさせていただきました。
Discussion