【AWSハンズオン】予約管理システム用VPC環境を構築してみた – 実践構成とトラブルシュート

はじめに

CloudTechの教材をもとに、疑似的な予約管理システム環境をAWS上に構築した記録です。この記事では、インフラ設計・構築手順・トラブルシュート・動作確認の流れを整理し、後続の学習者や読者にとって役立つ構成を目指しました。
注：本記事はCloudTech教材を参考にしながら、自身で構築・検証した内容をまとめたものです。 教材の図や文章を直接転載せず、著作権に配慮して「実施した作業のみ」を箇条書きで記載しています。

構成概要と設計思想

VPC構成

名前：reservation-vpc
CIDR：10.0.0.0/21

サブネット設計

サブネット	CIDR	用途
`web-subnet-01`	`10.0.0.0/24`	Webサーバ用（外部アクセス）
`api-subnet-01`	`10.1.0.0/24`	APIサーバ用（内部処理）

ルートテーブル構成

web-routetable → 0.0.0.0/0 → Internet Gateway
api-routetable → API内部通信用に制限ルート

インスタンス構成

サーバ名	AMI	用途
`web-server-01`	Amazon Linux 2023	フロント提供
`api-server-01`	Amazon Linux 2023	APIリクエスト処理／DB接続

Webサーバ構築

Amazon Linux 2023 の EC2 インスタンスを起動し、SSHログイン
yum update によるシステム更新
Git のインストール → Webアプリのソースコードを GitHub から取得
Nginx をインストール・起動・自動起動設定
Nginx の設定ファイルを編集し、rootディレクトリを Webアプリの配置先に変更
Webブラウザでアクセス → 「Welcome to nginx!」の表示確認
config.js を編集し、APIサーバのパブリックIPを baseURL に設定
Web画面に「API Test」「Database Test」ボタンが表示されることを確認

APIサーバ構築

Amazon Linux 2023 の EC2 インスタンスを起動し、SSHログイン
Git・Go言語・Nginx をインストール
GitHub から API サーバのソースコードを取得
goserver.service を systemd で作成 → Goアプリの自動起動設定
Nginx をリバースプロキシとして設定（80番ポート → 8080番ポートへ転送）
Nginx 設定ファイルを編集 → proxy_pass などのヘッダー設定を追加
Nginx を再起動し、外部からの HTTP アクセスを確認

セキュリティ設計と制約事項

セキュリティグループではポート80（HTTP）のみ許可
SSHはメンテナンス用として必要最小限のみ許可
トラブル時、「HTTPが許可されていないこと」がアクセス不可の原因だった → セキュリティグループを適切に見直すことで解消

構築時のポイントと工夫

サブネットの「パブリックIPv4自動割り当て」設定が必須であることに注意
EC2作成時にも「自動割り当てパブリックIP」が表示されているかチェック
ルートテーブルにIGWルートが存在するか、サブネットとの紐づけに注意
ENIの設定状態によってもIP割り当てが左右されるため、構成の整合性が重要

動作確認：Webアプリのテスト

アプリ画面に「API Test」「Database Test」ボタンが表示
API Testのクリックで接続成功メッセージを確認

AWS課金対策

対象	対策方法
EC2インスタンス	停止すれば課金されない
EBSボリューム	スナップショット化 or そのまま保持

EC2インスタンスを停止しておくのみで問題ないとの記載がありましたが、
AWS Billing → Cost Explorer で使用状況を日別・サービス別に確認しておきました。
利用料の閾値を設定し、超過でメールが飛ぶように設定済み。

詰まったポイントとリベンジ記録

最初はパブリックIPが付与されず、再構築や設定見直しを繰り返した。セキュリティグループやサブネット設定の理解が曖昧だったが、設計・構成の整合性を意識して一からやり直したことで、動作確認まで辿り着くことができた。

この経験自体が、AWS構築における「可視化」「再現性」「セキュリティ意識」の重要性を教えてくれた。

今後の展望

Terraformによる構成自動化／CloudFormationへの展開も視野に
コスト監視とログ運用の最適化にも取り組みたい