【AIエージェント×AWS 実践編】構築手順の提示からトラブルシュートまでの一貫支援

承知しました。手順としては以下で進めます:

1. 現在のAWS環境確認(VPC/サブネット/IGW/NAT/EC2/ALB等)
2. ベストプラクティス確認(WebSearch)
3. 構成図とコンソール手順を作成

まず環境確認を並列実行します。

環境把握完了。VPC web-app-vpc (10.0.0.0/16) 既存、public×2(1a/1c)、private×1(1a)、IGW付き、NAT GWなし。EC2/ALB未作成。

冗長化のためprivate-1cが追加で必要。次にベストプラクティスと最新情報を確認します。

1. 現在のAWS環境

不足要素: ALB はマルチAZ要件のため public×2 で OK ですが、EC2 を冗長化するなら private-1c が未作成。プライベートサブネットからの外部通信路（NAT GW or VPC エンドポイント）も無いため、Nginx パッケージ取得・SSM 接続のいずれかの方法を用意する必要があります。

2. 構成図（推奨ベストプラクティス構成）

                     Internet
                         │
                         ▼
                  ┌──────────────┐
                  │  ALB (HTTP)  │  internet-facing
                  │  web-app-alb │  SG: alb-sg (0.0.0.0/0:80)
                  └──────┬───────┘
            ┌────────────┴────────────┐
            ▼                         ▼
  ┌──────────────────┐      ┌──────────────────┐
  │ public-1a        │      │ public-1c        │ ← ALB配置
  │ 10.0.1.0/24      │      │ 10.0.2.0/24      │
  │ (IGW経由で外向)    │      │                  │
  └──────────────────┘      └──────────────────┘
            │                         │
            │   (VPC内ルーティング)     │
            ▼                         ▼
  ┌──────────────────┐      ┌──────────────────┐
  │ private-1a       │      │ private-1c (新規) │ ← EC2配置
  │ 10.0.10.0/24     │      │ 10.0.11.0/24     │
  │ ┌────────────┐   │      │ ┌────────────┐   │
  │ │ EC2 Nginx  │   │      │ │ EC2 Nginx  │   │
  │ │ t3.micro   │◀──┼──────┼─│ t3.micro   │   │
  │ │ AL2023     │   │      │ │ AL2023     │   │
  │ │ SG: ec2-sg │   │      │ │ SG: ec2-sg │   │
  │ └────────────┘   │      │ └────────────┘   │
  └──────────────────┘      └──────────────────┘
            │                         │
            ▼                         ▼
   ┌─────────────────────────────────────────┐
   │ VPC Interface Endpoints (PrivateLink)   │
   │  ・com.amazonaws.ap-northeast-1.ssm     │
   │  ・com.amazonaws.ap-northeast-1.ssmmessages
   │  ・com.amazonaws.ap-northeast-1.ec2messages
   │ + Gateway Endpoint: S3 (dnf/yum取得用)   │
   └─────────────────────────────────────────┘

  EC2 IAMロール: AmazonSSMManagedInstanceCore (SSM Session Manager接続用)
  踏み台・キーペア・SSH一切不要

セキュリティグループ設計

3. ベストプラクティス採用ポイント

• EC2 はプライベート配置 + ALB はパブリック配置（公式推奨）
• マルチAZ構成（private-1a/1c に EC2 を1台ずつ配置）
• SSM Session Manager 接続でキーペア・踏み台・SSH ポート開放を全廃
• VPC エンドポイント経由で SSM 通信（インターネット非経由）
• SG 参照によるアクセス制御（IP指定でなく ALB-SG 参照）
• ALB ヘルスチェック有効化 (HTTP:80, パス /)
• ALB アクセスログを S3 へ出力（任意、運用観点で推奨）
• 削除保護を ALB に設定（運用フェーズで推奨）

コスト目安（ap-northeast-1, 月額・730h）

NAT Gateway を使う代替案: NAT GW $0.062/h × 2AZ ≒ $90/月 + データ転送料。VPCエンドポイント方式の方がセキュアかつ近コストのためこちらを推奨。シングルAZ運用許容なら NAT GW シングル($45/月) が最安。

クォータ確認

• ALB: アカウントあたり 50（デフォルト、十分）
• VPC エンドポイント: 50/VPC（十分）
• EIP: 5/region（今回未使用）
• t3.micro: vCPU 上限以内

リージョン対応

• ALB / EC2 / SSM / VPC エンドポイント全て ap-northeast-1 対応済み
• AL2023 AMI: ami-0a21a03072be95559 (kernel-6.1, 2026-04-29 リリース)

変更影響範囲

• 既存 VPC web-app-vpc に新規サブネット 1つ追加（既存リソースへの影響なし）
• 既存 default SG は使用せず、新規 SG を作成（既存への影響なし）
• 既存 IGW・パブリック RT は再利用（変更なし）

4. マネジメントコンソール 手動構築手順

手順0: 事前準備

• マネジメントコンソールにサインイン
• 右上リージョンを 東京 (ap-northeast-1) に固定

手順1: プライベートサブネット追加（private-1c）

1. VPC > サブネット > サブネットを作成
2. VPC: web-app-vpc
3. サブネット名: web-app-private-1c
4. AZ: ap-northeast-1c
5. CIDR: 10.0.11.0/24
6. 作成後、ルートテーブル web-app-private-rt に紐付け（サブネット詳細 > ルートテーブル > 関連付けを編集）

手順2: VPCエンドポイント用 SG 作成

1. VPC > セキュリティグループ > 作成
2. 名前: vpce-sg / VPC: web-app-vpc
3. インバウンド: HTTPS(443) Source 10.0.0.0/16

手順3: VPC エンドポイント作成（Interface型 ×3）

1. VPC > エンドポイント > エンドポイントを作成
2. 以下を3回繰り返し作成
   • com.amazonaws.ap-northeast-1.ssm
   • com.amazonaws.ap-northeast-1.ssmmessages
   • com.amazonaws.ap-northeast-1.ec2messages
3. 各エンドポイント共通設定:
   • VPC: web-app-vpc
   • サブネット: web-app-private-1a, web-app-private-1c
   • SG: vpce-sg
   • プライベートDNS: 有効

手順4: VPCエンドポイント作成（Gateway型 S3）

1. サービス: com.amazonaws.ap-northeast-1.s3 (Gateway)
2. VPC: web-app-vpc
3. ルートテーブル: web-app-private-rt を選択
4. ポリシー: フルアクセス（dnf リポジトリ取得用）

手順5: IAM ロール作成（EC2 用 SSM）

1. IAM > ロール > ロールを作成
2. 信頼するエンティティ: AWSサービス > EC2
3. ポリシーアタッチ: AmazonSSMManagedInstanceCore
4. ロール名: web-app-ec2-ssm-role

手順6: セキュリティグループ作成

alb-sg

1. VPC: web-app-vpc / 名前: alb-sg
2. インバウンド: HTTP(80) Source 0.0.0.0/0

ec2-sg

1. VPC: web-app-vpc / 名前: ec2-sg
2. インバウンド: HTTP(80) Source alb-sg（SG参照）

手順7: EC2 起動（2台）

1. EC2 > インスタンス > インスタンスを起動
2. 名前: web-app-nginx-1a
3. AMI: ami-0a21a03072be95559 (Amazon Linux 2023)
4. インスタンスタイプ: t3.micro
5. キーペア: キーペアなしで続行（SSM接続のため）
6. ネットワーク設定:
   • VPC: web-app-vpc
   • サブネット: web-app-private-1a
   • パブリックIP自動割当: 無効
   • SG: ec2-sg
7. ストレージ: gp3 8GiB（暗号化 有効）
8. 高度な詳細:
   • IAMインスタンスプロファイル: web-app-ec2-ssm-role
   • メタデータバージョン: V2のみ (token required)
   • ユーザーデータ:

#!/bin/bash
dnf -y update
dnf -y install nginx
systemctl enable --now nginx
cat <<'EOF' > /usr/share/nginx/html/index.html
<!DOCTYPE html>
<html><head><meta charset="utf-8"><title>web-app</title></head>
<body><h1>Hello from $(hostname)</h1></body></html>
EOF
systemctl restart nginx

9. 起動。同手順を AZ ap-northeast-1c / サブネット web-app-private-1c / 名前 web-app-nginx-1c で繰り返し

手順8: ターゲットグループ作成

1. EC2 > ターゲットグループ > 作成
2. ターゲットタイプ: Instances
3. 名前: web-app-tg
4. プロトコル/ポート: HTTP / 80
5. VPC: web-app-vpc
6. プロトコルバージョン: HTTP1
7. ヘルスチェック:
   • プロトコル: HTTP / パス: /
   • 詳細: 間隔 30秒 / タイムアウト 5秒 / 健全閾値 2 / 異常閾値 2 / 成功コード 200
8. ターゲット登録: EC2 2台（ポート 80）

手順9: ALB 作成

1. EC2 > ロードバランサー > ロードバランサーを作成 > Application Load Balancer
2. 名前: web-app-alb
3. スキーム: インターネット向け
4. IP アドレスタイプ: IPv4
5. VPC: web-app-vpc
6. マッピング: ap-northeast-1a → web-app-public-1a / ap-northeast-1c → web-app-public-1c
7. SG: alb-sg（default SG は外す）
8. リスナー: HTTP:80 → 転送先 web-app-tg
9. （任意）属性で 削除保護を有効化、アクセスログを S3 出力に設定
10. 作成

手順10: 動作確認

1. ALB の DNS 名（web-app-alb-xxxxx.ap-northeast-1.elb.amazonaws.com）にブラウザでアクセス
2. ターゲットグループの Targets タブで両 EC2 が healthy になること
3. リロードを繰り返して Hello from ip-10-0-10-x / ip-10-0-11-x が交互に表示される（ラウンドロビン動作）
4. SSM 接続テスト: EC2 > インスタンス > 接続 > Session Manager で各 EC2 にシェル接続できること

手順11（任意・推奨）

• ACM で証明書発行 → ALB に HTTPS:443 リスナー追加、HTTP→HTTPS リダイレクト
• AWS WAF を ALB にアタッチ（OWASP マネージドルール）
• CloudWatch アラーム設定（UnHealthyHostCount, TargetResponseTime, HTTPCode_ELB_5XX_Count）
• ALB アクセスログを S3 → Athena で分析

注意事項

• 本回答は describe/list/get のみで現状確認 を実施しており、リソースの作成・変更は一切行っていません（CLAUDE.md ルール準拠）
• 手順実施前に必ずコスト・クォータを再確認してください
• 手順実施は本番環境ではなく検証環境からの試行を推奨します

Sources:

• Load balancer subnets and routing – AWS Prescriptive Guidance
• Application Load Balancers – Elastic Load Balancing
• Subnets for your VPC – Amazon Virtual Private Cloud
• Step 6: VPC endpoint for Session Manager – AWS Systems Manager
• Improve EC2 security with VPC endpoints for Systems Manager
• WKLD.06 Use Systems Manager instead of SSH or RDP
• Health checks for Application Load Balancer target groups
• Security groups for your Application Load Balancer
• CloudWatch solution: NGINX workload on Amazon EC2

原因調査結果

ALB の DNS 名へのアクセスで 504 Gateway Timeout が発生する原因を、AWS リソースの状態を確認した結果、以下の問題が判明しました。

確定原因

主因（致命的）: ec2-sg のインバウンドポート設定ミス

• ec2-sg (sg-xxxxxxxxxxxxxxxxx) のインバウンドルール: TCP 8080 from alb-sg
• ターゲットグループ web-app-tg の転送ポート: TCP 80
• EC2 上の Nginx の待ち受けポート: TCP 80

ALB は EC2 のポート 80 へヘルスチェックおよびリクエスト転送を試みますが、ec2-sg がポート 80 を許可していないため、すべての通信がセキュリティグループでブロックされています。結果として ALB 側ではターゲットからの応答がタイムアウトし、504 Gateway Timeout が返却されています。

検出証跡:

describe-target-health の結果
TargetHealth.State:       unhealthy
TargetHealth.Reason:      Target.Timeout
TargetHealth.Description: Request timed out

両ターゲット（i-xxxxxxxxxxxxxxxxx, i-xxxxxxxxxxxxxxxxx）ともに同じ状態です。

副因: ヘルスチェックパスの不整合

• ターゲットグループのヘルスチェックパス: /health
• Nginx のデフォルトドキュメントルート（/usr/share/nginx/html）には /health ファイルが存在しない

主因（SG のポート 80 不許可）を解消しても、ヘルスチェックリクエストが /health に対して 404 を返すため、ターゲットは Target.ResponseCodeMismatch で unhealthy のままとなる見込みです。

復旧手順（マネジメントコンソール）

手順1: ec2-sg のポート修正（主因の解消）

1. VPC コンソール > セキュリティグループ > ec2-sg (sg-xxxxxxxxxxxxxxxxx) を選択
2. インバウンドルール タブ > インバウンドルールを編集
3. 既存ルール（TCP 8080、ソース sg-xxxxxxxxxxxxxxxxx）を 削除
4. ルールを追加 をクリックし、以下を設定
   • タイプ: HTTP
   • プロトコル: TCP
   • ポート範囲: 80
   • ソース: カスタム → sg-xxxxxxxxxxxxxxxxx (alb-sg)
   • 説明: Allow HTTP from ALB
5. ルールを保存

手順2: ヘルスチェック整合化（副因の解消）

以下のいずれかを実施します。方針A を推奨します（ヘルスチェック専用エンドポイントを持つことで、トップページ変更の影響を受けず、軽量応答にできるため）。

方針A: Nginx 側に /health を用意（推奨）

各 EC2 で Session Manager 経由で実行

echo "OK" | sudo tee /usr/share/nginx/html/health
curl -I http://localhost/health   # 200 OK を確認

方針B: ターゲットグループのヘルスチェックパスを変更

1. EC2 コンソール > ターゲットグループ > web-app-tg
2. ヘルスチェック タブ > 編集
3. ヘルスチェックパスを /health から / に変更
4. 変更を保存

手順3: 復旧確認

1. EC2 コンソール > ターゲットグループ > web-app-tg > Targets タブ
2. 両ターゲットの Health status が healthy に遷移することを確認（30秒〜数分かかります）
3. ブラウザで http://web-app-alb-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com/ にアクセス
4. HTTP 200 OK と Nginx の index ページが表示されることを確認
5. 数回リロードし、応答する EC2 のホスト名が交互に切り替わることを確認（ラウンドロビン動作）

根本対策（再発防止）

• 構築時のクロスチェック: ターゲットグループのポートと、ターゲット側 SG の許可ポート、アプリケーションの待ち受けポートの三者一致を必ず確認する
• ヘルスチェック専用パスの実装: Nginx の静的配信または location ディレクティブで /health を明示的に提供する
• CloudWatch アラーム導入: ターゲットグループの UnHealthyHostCount や ALB の HTTPCode_ELB_5XX_Count に対してアラームを設定し、異常検知を自動化する

変更の影響範囲

• 手順1（ec2-sg 修正）: ALB から EC2 への通信のみが影響を受け、他リソースへの影響はありません。ダウンタイムは数秒程度です
• 手順全体: 既存 VPC・ALB・EC2 を再作成せず修正のみで復旧可能。ロールバックは旧 SG ルールに戻すだけで可能