お世話になっております。
クラウド事業部の錦織です。
これまで実際にAWSを使う機会はほとんどありませんでしたが、今回設計・構築する機会を頂き学ぶことができました。
本ブログでは、その経験をもとに学んだことを記載していきます。※なお、本記事で紹介する構築方法はあくまで一例です。実際の環境や目的に応じて構築をお願いいたします。
構築の目的
高可用性を備えたAWS構成を設計・構築できるようになることを目指しました。
構成図概要
VPCとサブネット構築
対象画面：AWS Management Console > サービス > VPC > 左メニュー「VPC」>「VPCを作成」
操作手順
・「VPCとその他のリソースを作成」を選択
・ 名前 myapp を入力
・ IPv4 CIDR を 10.0.0.0/16 に設定
・ IPv6 CIDR は「なし」
・ テナンシーは「デフォルト」
・ サブネット数はパブリックサブネット2、プライベートサブネット4
・ サブネット CIDR ブロックは手動カスタマイズ
・ DNS ホスト名・DNS 解決オプションは両方「有効」
・ 「VPC を作成」ボタンをクリック
構成まとめ
・プロジェクト名：myapp
・IPv4 CIDR：10.0.0.0/16
・AZ：ap-northeast-3a / ap-northeast-3b
・サブネット構成：パブリック2、プライベート4
NATゲートウェイ構築手順
目的
プライベートサブネットのEC2インスタンスからインターネットへの通信を可能にする。NATゲートウェイを構築し、冗長化・可用性を確保します。
1. NATゲートウェイの作成
- AWSコンソール → VPCダッシュボード → NATゲートウェイ → [作成]
- 名前：例）
myapp-natgw-az1 - サブネット：public1（パブリックサブネット）
- 接続タイプ：
パブリック - Elastic IP：新規割り当て or 既存を選択
- 名前：例）
- 「NATゲートウェイを作成」をクリック
- （任意）Name タグを
myapp-natgw-az1に変更
2. 冗長化（複数AZ配置）
- 手順1を別AZ（例：public2）で繰り返す
- 名前例：
myapp-natgw-az2
- 名前例：
3. プライベートサブネットのルート設定
- VPCダッシュボード → ルートテーブル
- プライベートサブネット1のルートテーブルを選択：
- ルート設定を追加
- 宛先：
0.0.0.0/0 - ターゲット：作成した NATゲートウェイ (
myapp-natgw-az1) - 保存
- プライベートサブネット2でも同様の手順で、AZ2用 NATゲートウェイを指定
セキュリティグループ構築手順
目的
ALB、EC2、RDS、EFSの各構成要素間で必要な通信を制御しつつ、管理しやすい環境を構築します。
ALB 用 SG（インターネット向け）
- SG 名：
myapp-alb-sg - インバウンド
- HTTP（ポート 80）：
0.0.0.0/0 - HTTPS（ポート 443）：
0.0.0.0/0
- HTTP（ポート 80）：
- アウトバウンド：全許可（
0.0.0.0/0）
EC2 用 SG（ALB 経由通信）
- SG 名：
myapp-ec2-sg - インバウンド
- HTTP（ポート 80）：
myapp-alb-sg
- HTTP（ポート 80）：
- アウトバウンド：全許可（
0.0.0.0/0）
RDS 用 SG（EC2 から DB 接続）
- SG 名：
rds-security-myapp-sg - インバウンド
- MySQL（ポート 3306）：
myapp-ec2-sg
- MySQL（ポート 3306）：
- アウトバウンド：全許可（
0.0.0.0/0） - 説明：EC2 → RDS（データベースアクセス）
EFS 用 SG（EC2 からファイル共有）
- SG 名：
myapp-efs-sg - インバウンド
- NFS（ポート 2049）：
myapp-ec2-sg
- NFS（ポート 2049）：
- アウトバウンド：全許可（
0.0.0.0/0） - 説明：EC2 → EFS（共有ストレージ）
RDSの作成
目的
RDS の高可用性と耐障害性を確保するため、適切にサブネットグループを作成し、マルチAZ構成
1. サブネットグループの作成
- 画面操作：VPC 左メニュー → サブネットグループ → [サブネットグループを作成]
- 名前：
rds-subnet-myapp - 説明：
RDS用サブネットグループ - VPC：
myapp-vpc - アベイラビリティゾーン：VPC作成時と同じ 2つを選択
- サブネット：
protect1,protect2（別 AZ 配置）
- 名前：
- [サブネットグループを作成] をクリック
2. RDS インスタンスの作成
- 画面操作：RDS 左メニュー → データベース → [データベースを作成]
- テンプレート：
無料利用枠 - エンジン：
MySQL - DB 識別子：
rds-myapp - ユーザー名：任意
- インスタンスサイズ：デフォルト
- マルチAZ：後ほど有効化予定
- VPC：
myapp-vpc - サブネットグループ：
rds-subnet-myapp - セキュリティグループ：
rds-security-myapp-sg - パブリックアクセス：
なし - アベイラビリティゾーン：プライマリ AZ を選択（例：
ap-northeast-1a） - 追加設定：データベース名：
app - 自動バックアップ：
無効 - [データベースを作成] をクリック
- テンプレート：
3. マルチAZ構成の有効化
- 作成された RDS インスタンスを選択
- [変更] をクリック
- 可用性と耐久性：
マルチAZ配置のスタンバイインスタンスを作成するにチェック - スタンバイ AZ：例）
ap-northeast-1c
- 可用性と耐久性：
- [変更の適用] → [DBインスタンスを変更]
- ステータスが「変更中」から「利用可能」に変わる
EFS ファイルシステムの作成手順
目的
EC2 インスタンス間でのファイル共有を実現する為、EFSを構築。
-
EFS コンソールを開く
- AWS マネジメントコンソールにサインインし、EFSを開きます。
-
ファイルシステムの作成
- 左メニューから「ファイルシステム」を選択し、「ファイルシステムを作成」をクリックします。
-
設定のカスタマイズ
-
「カスタマイズ」を選択し、以下の設定を行います：
- 名前：
myapp-efs - VPC：
myapp-vpc - タイプ：
リージョン（Regional） - 自動バックアップ：
無効
- 名前：
-
-
ネットワーク設定
- マウントターゲット：
private1サブネットprivate2サブネット
- セキュリティグループ：
myapp-efs-sg（EFS 用に事前作成したセキュリティグループを指定） - ファイルシステムポリシー：不要（研修用途のため設定しません）
- マウントターゲット：
-
確認と作成
- 設定内容を確認し、「作成」をクリックします。
IAM ロールの作成手順
目的
EC2 インスタンスに必要な IAM ロールを作成し、SSM、RDS、CloudWatch エージェント用の権限を付与します。これにより、インスタンスからの RDS 接続、CloudWatch へのメトリクス送信、SSM を利用した管理が可能となります。
1. EC2 用 IAM ロールの作成
-
IAM コンソールを開く
- AWS マネジメントコンソールにサインインし、IAMを開きます。
-
ロールの作成
- 左メニューから「ロール」を選択し、「ロールを作成」をクリックします。
-
信頼されたエンティティの設定
- 「信頼されたエンティティの種類」で「AWS サービス」を選択し、「EC2」を選択します。
-
ポリシーのアタッチ
- 以下のポリシーを選択します：
AmazonSSMManagedInstanceCoreCloudWatchAgentServerPolicySecretsManagerReadWrite（RDS 接続用）
- 以下のポリシーを選択します：
-
ロールの設定
- ロール名：
myapp-ssm-rds-cloudwatch-role - 名前タグ：
myapp-ssm-role
- ロール名：
-
ロールの作成
- 設定内容を確認し、「ロールを作成」をクリックします。
EC2 インスタンスの作成手順
-
EC2 ダッシュボードを開く
- AWS マネジメントコンソールにサインインし、EC2を開きます。
-
インスタンスの起動
- 左メニューから「インスタンス」を選択し、「インスタンスを起動」をクリックします。
-
インスタンスの設定
- 名前タグ：
myapp-ec2-1（またはmyapp-ec2-2） - AMI：
Amazon Linux 2023（64-bit, x86） - インスタンスタイプ：
t2.microまたはt3（無料利用枠を使用） - キーペア：なし（SSM を使用）
- ネットワーク設定：
- VPC：
myapp-vpc - サブネット：
myapp-vpc-subnet-private1-ap-northeast-3a（またはmyapp-vpc-subnet-private2-ap-northeast-3c） - パブリック IP：無効
- VPC：
- セキュリティグループ：
ec2-security-myapp
- 名前タグ：
-
IAM ロールのアタッチ
- 「IAM ロールの設定」で、先ほど作成したロール
myapp-ssm-rds-cloudwatch-roleを選択します。
- 「IAM ロールの設定」で、先ほど作成したロール
-
ユーザーデータの設定
任意のスクリプトを設定 -
インスタンスの起動
- 設定内容を確認し、「インスタンスを起動」をクリックします。
SSM接続設定
VPCエンドポイント作成（SSM用）
- VPCコンソール → 左メニュー「エンドポイント」 → 「エンドポイントを作成」
- サービスを選択
- com.amazonaws.ap-northeast-3.ssm
- com.amazonaws.ap-northeast-3.ssmmessages
- com.amazonaws.ap-northeast-3.ec2messages
- 名前タグ：myapp-ssm-vpce
- DNS有効にする
- VPC：myapp-vpc
- サブネット：private1, private2
- セキュリティグループ：myapp-ssm-sg
- 注意：S3エンドポイント作成不要
- 各エンドポイントを作成
EC2にロールをアタッチ
- EC2コンソール → 対象インスタンスを選択
- 「アクション」 > 「セキュリティ」 > 「IAMロールを変更」
- ロールに myapp-ssm-role を選択し更新
ALB（Application Load Balancer）作成手順
ターゲットグループの作成
- インスタンスを選択
- ターゲットグループ名：alb-target-myapp
- プロトコル・ポート：HTTP:80
- VPC：myapp-vpc
- ヘルスチェックパス：/index.html
- インスタンス：EC2を2台とも選択して登録（保留中にして含める）
ALBの作成
-
AWSコンソール → EC2ダッシュボード
-
左メニュー「ロードバランサー」→「ロードバランサーを作成」
-
設定内容：
- タイプ：Application Load Balancer
- 名前：myapp-alb
- スキーム：インターネット向け
- VPC：myapp-vpc
- マッピング：public1, public2
- セキュリティグループ：alb-myapp（※デフォルトSGは削除）
- リスナー：HTTP（80）
- ターゲットグループ：alb-target-myapp（上で作成したものを選択）
-
**ALB作成
⏳ プロビジョニングに時間がかかることがあります。
Route 53設定：ドメイン解決 & ACM検証
新規でレコードを作成する場合：
-
Route 53 ホストゾーンを開く（既存のゾーンを使用）
-
[レコードを作成] をクリック
- レコード名：myapp
- タイプ：A – IPv4
- ルーティング：シンプルルーティング
- エイリアス：ON
- エイリアス先：
• Application and Classic Load Balancer
• リージョン：大阪（ap-northeast-3）
• 対象：作成したロードバランサー（例：myapp-alb）
-
[作成] をクリック
数分〜数十分でドメイン名でアクセス可能に。
既にRoute 53でレコードが存在する場合：
- レコード編集 → ルーティング先を「今回作成したALB」に変更
- 保存して完了
ACM証明書作成 & HTTPSリスナー設定手順
【ACM証明書の発行（ALB用）】
目的：ALBでHTTPS通信を可能にする証明書を発行する
画面：ACM → [証明書をリクエスト]
操作手順：
- AWS Certificate Managerを開き、「証明書をリクエスト」
- サブドメインを入力
- 検証方法：DNS検証を選択（推奨）
- キータイプ：RSA を選択
- 証明書作成後、ACM画面中央のリンクからRoute53にDNSレコード（CNAME）を追加
- Route53にCNAMEレコードが追加されたことを確認
【ALBでHTTPSリスナー追加】
目的：HTTPSアクセスをALBで受け付ける
画面：EC2 → ロードバランサー → 対象のALB → [リスナーとルール]
操作手順：
- 「リスナーの追加」をクリック
- プロトコル：HTTPS
- ポート：443
- ターゲットグループ：alb-target を選択（既存のターゲットグループ）
- 証明書：ACMで作成したSSL証明書を選択
- （任意）リスナータグを追加
- 「追加作成」をクリック
最後にセキュリティグループの確認
- ALBのセキュリティグループにHTTPS（ポート443）のインバウンドルールを追加
HTTPアクセスのHTTPSリダイレクト設定手順
目的：HTTPアクセスをHTTPSへリダイレクトする
【操作手順】
- EC2コンソール → 対象のロードバランサー（ALB）を選択
- 「リスナーとルール」タブから http（ポート80）を選択し、「ルールを編集」
- アクションで「URL にリダイレクト」を選択
- リダイレクト先 URL に
https://:443を指定 - ステータスコードは「301（恒久的リダイレクト）」を選択
- [保存] をクリック
【セキュリティグループの確認】
- ALB にアタッチされた SG に以下が含まれていることを確認：
- ポート 80（HTTP）
- ポート 443（HTTPS）
ALBアクセスログ保存設定手順（S3バケット作成）
【目的】
ALBのアクセスログをS3に保存する
【S3バケット作成】
- AWSコンソール → S3 → 「バケットを作成」
- 以下を設定：
- バケット名：myapp-alb-logs
- リージョン：ap-northeast-1
- オブジェクト所有者：ACL無効
- パブリックアクセス：すべてブロック
- 注意：バケット名はグローバルで一意であること
- 「バケットを作成」をクリック
【バケットポリシーの変更】
バケット作成後：
- 対象バケットを選択 → 「アクセス許可」タブ → 「バケットポリシーを編集」
- バケットポリシーの貼り付け
SNS設定手順
【目的】
EC2とALBの監視を行い、異常時にメール通知する
■ SNSトピックの作成
画面：SNS → 左メニュー「トピック」 → [トピックを作成]
- 名前：myapp-sns-topic
- タイプ：標準
- サブスクリプション：メール、通知先アドレスを入力
- 名前タグ：myapp-sns-topic
- 「トピックを作成」→「サブスクリプションを作成」
- 確認メールを開いて「confirm」リンクをクリック
CloudWatch エージェント設定（※メモリ監視用）
【インストール & 設定】
対象EC2でagentのインストールを実行。
・監視対象を含んだJSONを設定。
【IAMロール設定】
- CloudWatchAgentServerPolicy を EC2 にアタッチする
CloudWatch アラーム作成手順
📍 画面操作手順：
CloudWatch > 左メニュー「アラーム」 > 「アラームを作成」
━━━━━━━━━━━━━━━━━━━━━━━
① EC2 CPUアラーム（myapp-ec2-1, myapp-ec2-2）
━━━━━━━━━━━━━━━━━━━━━━━
・メトリクス：EC2 > Per-Instance Metrics > CPUUtilization
・条件：CPU使用率が 80%以上、90%以上
・通知：myapp-sns-topic
・タグ名：
- myapp-cpu-alarm-80
- myapp-cpu-alarm-90
━━━━━━━━━━━━━━━━━━━━━━━
② EC2 メモリアラーム（CloudWatch Agent 必須）
━━━━━━━━━━━━━━━━━━━━━━━
・メトリクス：CWAgent > mem_used_percent
・条件：メモリ使用率が 80%以上、90%以上
・通知：myapp-sns-topic
・タグ名：
- myapp-mem-alarm-80
- myapp-mem-alarm-90
━━━━━━━━━━━━━━━━━━━━━━━
③ ALB HealthyHostCount アラーム
━━━━━━━━━━━━━━━━━━━━━━━
・メトリクス：ApplicationELB > HealthyHostCount
・条件：ターゲット数の減少を検知し通知
・通知：myapp-sns-topic
・タグ名：
- myapp-alb-health-alarm
振り返り
実際に手を動かして構築を進めると分からない部分やエラーに何度も直面し、試行錯誤の連続となりました。こうした過程を通じて、理解してから手を動かすことの重要性に気づかされました。
短期間の取り組みではありましたが、内容は非常に充実しており良い経験でした。まだまだ未熟ではありますが、手を動かして学び続ける姿勢を忘れず成長していきたいと考えています。
今後ともどうぞよろしくお願いいたします。