AWS Hands-on

AWSでLAMP環境を構築して
ブログを公開する

EC2（Web＋PHP）と RDS（MySQL）を分離した実務寄りの構成で、WordPress ブログを一から立ち上げます。マネジメントコンソールの画面操作を中心に、参加者と一緒に手を動かしながら進められる構成です。

所要時間 60〜90分 リージョン 東京 (ap-northeast-1) レベル 初級〜中級 最終更新 2026年8月

構成図 ─ 今日つくるもの

LAMP は Linux ／ Apache ／ MySQL ／ PHP の頭文字です。今回はこのうち M（MySQL）だけを EC2 から切り出して RDS に置く のがポイント。「Web サーバーとデータベースを分ける」という、実務で最初に覚える設計を体感します。

この構成にした理由

EC2 1台に全部載せる方が簡単ですが、それだと「なぜクラウドを使うのか」が伝わりません。 DB を RDS に外出しすると、Web サーバーを壊してもデータは残る／バックアップは AWS 任せ／後から Web だけスケールできる という利点をその場で見せられます。STEP 9 でそれを実演します。

パラメータ一覧（先に決めておく値）

ハンズオン中に迷わないよう、命名と値を先に固定しておきます。参加者にはこの表だけ配っておくとスムーズです。

項目	値	備考
リージョン	`ap-northeast-1`（東京）	右上のリージョン表示を必ず全員で揃える
VPC 名 / CIDR	`lamp-handson-vpc` / `10.0.0.0/16`	ウィザードで一括作成
パブリックサブネット	`10.0.0.0/20`（1a）, `10.0.16.0/20`（1c）	EC2 は 1a 側に配置
プライベートサブネット	`10.0.128.0/20`（1a）, `10.0.144.0/20`（1c）	RDS 用。2AZ 必須
Web 用 SG	`lamp-web-sg`	インバウンド HTTP 80 ← `0.0.0.0/0`
DB 用 SG	`lamp-db-sg`	インバウンド MySQL 3306 ← `lamp-web-sg`
EC2 名 / タイプ	`lamp-web-01` / `t3.micro`	AMI: Amazon Linux 2023、ストレージ 8GiB gp3
IAM ロール	`lamp-ssm-role`	`AmazonSSMManagedInstanceCore` をアタッチ
RDS 識別子 / クラス	`lamp-blog-db` / `db.t4g.micro`	エンジン MySQL 8.4 系（LTS）
RDS マスターユーザー	`admin`	パスワードは各自で決めてメモ（記号 `/ @ " 空白` は使用不可）
DB サブネットグループ	`lamp-db-subnet-group`	プライベートサブネット 2 つを選択
アプリ用 DB / ユーザー	DB `wordpress` / ユーザー `wpuser`	STEP 6 で SQL から作成

MySQL のバージョン選択は 8.4 で

RDS for MySQL 8.0 は 2026年7月31日で標準サポートが終了しました。 今から 8.0 を選ぶと自動的に有償の「延長サポート」対象になり、想定外の課金が発生します。ハンズオンでは必ず MySQL 8.4.x（LTS） を選んでください。ここは参加者にも強調すべき実務的な注意点です。

タイムテーブル（90分想定）

時間	内容	進め方
0:00–0:08	導入・構成図の説明・費用の注意	スライド／この資料の冒頭を投影
0:08–0:13	STEP 0 予算アラートの設定	全員で。事故防止の儀式
0:13–0:23	STEP 1–2 VPC・セキュリティグループ	画面共有しながら一緒に
0:23–0:33	STEP 3 EC2 起動	起動待ちの間に STEP 4 へ
0:33–0:45	STEP 4 RDS 作成待ち時間あり	作成完了まで 5〜10分。ここで質疑応答
0:45–0:58	STEP 5 Apache + PHP のセットアップ	コマンドをコピペ
0:58–1:06	STEP 6 RDS 接続確認・DB 作成	「繋がった！」の山場
1:06–1:16	STEP 7–8 WordPress 設置・記事投稿	各自のブログが公開される
1:16–1:24	STEP 9 見せ場デモ	EC2 を再起動してもデータが残る実演
1:24–1:30	後片付け・まとめ	削除まで必ずやりきる

時間を 45 分に圧縮したい場合

STEP 1 の VPC 作成をデフォルト VPC の利用に置き換え、STEP 5〜7 を付録 A のユーザーデータ（起動時自動セットアップ）に差し替えてください。その場合でも STEP 2（SG）と STEP 4（RDS）は手動で見せることをおすすめします。ここが一番学びのあるパートです。

1. 事前準備

参加者に事前にやってきてもらうこと

AWS アカウントを作成済み（クレジットカード登録・本人確認まで完了していること。当日その場で作ると 15〜30 分溶けます）
IAM ユーザーまたは IAM Identity Center でサインインできる（ルートユーザーでの作業は避ける）
ブラウザは Chrome / Edge / Firefox の最新版。ポップアップブロックは無効に
マネジメントコンソールの言語を「日本語」に設定（左下の言語切り替え）
この手順書を手元で開ける状態にしておく（コピペを多用します）

発表者側の準備

前日に自分で通しリハーサルを 1 回。RDS の作成待ち時間を実測しておく
投影用に ブラウザのズームを 125〜150% に。コンソールの文字は想像以上に小さい
RDS 作成待ちの間に話す小ネタを 2〜3 個用意（5. 発表者向けメモに台本あり）
完成済みの環境をもう 1 セット作っておく（デモが詰まったときの保険）
当日の会場 Wi-Fi で AWS コンソールが開けるか確認

費用の話 ── 最初に必ず伝える

2025年7月15日以降に作成された AWS アカウントは、従来の「12ヶ月無料利用枠」ではなく サインアップ時 100 USD ＋特定アクティビティ完了で最大 100 USD の追加クレジット（合計最大 200 USD） を、 6ヶ月間 または使い切るまで利用する新しいプラン体系になっています。「無料プラン」を選んでいる場合、クレジットが尽きるか 6ヶ月が経過するとアカウントは自動的に閉鎖されます。

当日のアナウンス例

「今日つくるリソースは、消し忘れると 月あたり数千円規模 の課金になります。最後の後片付けまで必ず一緒にやりきってください。心配な方は STEP 0 の予算アラートを必ず設定しましょう。」

リソース	課金の考え方	止め方 / 消し方
EC2 `t3.micro`	起動している時間で課金。停止すれば計算リソース分は止まる	停止 → 最終的に「インスタンスを終了」
EBS 8GiB gp3	EC2 を停止してもディスク容量分は課金され続ける	インスタンス終了時に一緒に削除される設定を確認
RDS `db.t4g.micro`	稼働時間＋ストレージ。今回いちばん高い	削除（スナップショットも消す）
RDS 自動バックアップ	DB サイズを超えた分に課金。保持 0〜1日にしておけば実質ゼロ	DB 削除で消える
Elastic IP	今回は使わない。確保したまま未使用だと課金	使ったら必ず解放
データ転送（アウト）	ハンズオン規模なら誤差レベル	―

※ 具体的な金額は時期・リージョン・プランで変わります。正確な見積もりは AWS Pricing Calculator で当日の値を出して見せると説得力が上がります。

ハンズオン本編

予算アラートを設定する

AWS Budgets ・事故を防ぐお守り

約 5 分

本題の前に、まずブレーキを付けます。「使いすぎたら通知が来る」状態にしてから触り始めるのは、クラウドを扱う上での基本作法です。

操作手順

コンソール右上のアカウント名 → 請求とコスト管理 を開く
左メニューの予算 → 予算を作成
テンプレートで 「月次コスト予算」 を選択
予算名 lamp-handson-budget、予算額 10 USD（ハンズオン用なので小さめで十分）
メールアドレスに自分のアドレスを入力 → 予算を作成

補足

デフォルトで「実績が予算の 85% / 100% に達したとき」と「予測が 100% を超えるとき」に通知されます。請求データの反映には数時間〜1日かかるため、アラートは事後通知であって課金を止めるものではない 点は必ず伝えてください。

予算を作成し、確認メールが届いた
画面右上のリージョンが東京になっていることを全員で確認した

VPC を作る

ネットワークの土台を 1 画面で一括作成

約 6 分

VPC ＝ AWS の中に確保する自分専用のネットワーク。今回は「VPC など」ウィザードを使い、VPC・サブネット・ルートテーブル・インターネットゲートウェイをまとめて作ります。

操作手順

サービス検索で VPC → VPC を作成
作成するリソース：VPC など を選択（← ここ重要。「VPC のみ」だと手作業が増えます）
以下のとおり設定します

設定項目	値
名前タグの自動生成	`lamp-handson`
IPv4 CIDR ブロック	`10.0.0.0/16`
IPv6 CIDR ブロック	なし
テナンシー	デフォルト
アベイラビリティーゾーンの数	2
パブリックサブネットの数	2
プライベートサブネットの数	2
NAT ゲートウェイ	なし課金注意
VPC エンドポイント	なし
DNS ホスト名を有効化 / DNS 解決を有効化	両方オン

右側の プレビュー図 で、パブリック 2・プライベート 2 の構成になっていることを参加者と一緒に確認
VPC を作成 をクリック（完了まで 30 秒ほど）

NAT ゲートウェイは必ず「なし」に

NAT ゲートウェイは存在するだけで時間課金が発生し、消し忘れが最も多い「うっかり課金」の代表格です。今回はプライベートサブネットにインターネットへ出る必要のあるリソースを置かないため不要です。

説明のポイント

「パブリックサブネット＝インターネットゲートウェイへのルートがある部屋」「プライベートサブネット＝ない部屋」という違いを、作成後の ルートテーブル 画面を開いて実際に 0.0.0.0/0 → igw-xxxx の行があるか／ないかを見せると一発で伝わります。

VPC が作成され、サブネットが 4 つできている
パブリック側のルートテーブルに 0.0.0.0/0 → igw- がある
プライベート側のルートテーブルには local しかない

セキュリティグループを 2 つ作る

「Web は世界に開く／DB は Web にだけ開く」を形にする

約 6 分

ハンズオンで一番セキュリティの学びがあるパートです。先に SG を作ってから EC2・RDS を作る と、後戻りがなくスムーズです。

2-1. Web 用セキュリティグループ

VPC コンソール左メニュー → セキュリティグループ → セキュリティグループを作成
名前：lamp-web-sg ／説明：Allow HTTP from internet
VPC：lamp-handson-vpc を選択（デフォルト VPC のままにしないよう注意）
インバウンドルールを追加：

タイプ	プロトコル/ポート	ソース	説明
HTTP	TCP / 80	`0.0.0.0/0`	ブログを一般公開するため

アウトバウンドはデフォルト（すべて許可）のままで OK。SSH（22）は開けません。

なぜ SSH を開けないのか

今回は AWS Systems Manager Session Manager でブラウザからシェルに入ります。これなら インバウンドポートを 1 つも開けずに、鍵ファイルの管理もなしでサーバーに入れます。「22番を全開にしない」のは実務でまず指摘されるポイントなので、ここは強調ポイントです。

2-2. DB 用セキュリティグループ

同じく セキュリティグループを作成
名前：lamp-db-sg ／説明：Allow MySQL from web tier ／ VPC：lamp-handson-vpc
インバウンドルールを追加：

タイプ	プロトコル/ポート	ソース	説明
MYSQL/Aurora	TCP / 3306	カスタム → `lamp-web-sg`	Web サーバーからのみ許可

ここが今日いちばんの「なるほど」ポイント

ソースに IP アドレスではなく セキュリティグループそのもの を指定できます。これを「SG 参照」と呼びます。
効果：EC2 の IP が変わっても、EC2 を増やしても、ルールを直す必要がない。 「lamp-web-sg が付いているサーバーなら誰でも通す」という役割ベースのファイアウォールになります。参加者に「IP を書く方式と比べて何が嬉しい？」と問いかけると場が動きます。

lamp-web-sg を作成（80 ← 0.0.0.0/0）
lamp-db-sg を作成（3306 ← lamp-web-sg）
どちらも VPC が lamp-handson-vpc になっている

EC2 インスタンスを起動する

LAMP の「L」＝ Linux サーバーを用意

約 10 分

3-1. Session Manager 用の IAM ロールを作る

EC2 にブラウザから入るための権限を先に用意します。1 分で終わります。

サービス検索で IAM → ロール → ロールを作成
信頼されたエンティティ：AWS のサービス → ユースケース：EC2 → 次へ
許可ポリシーの検索窓に AmazonSSMManagedInstanceCore と入力してチェック → 次へ
ロール名：lamp-ssm-role → ロールを作成

3-2. インスタンスを起動

サービス検索で EC2 → インスタンスを起動

設定項目	値
名前	`lamp-web-01`
AMI	Amazon Linux 2023 AMI（64ビット x86）
インスタンスタイプ	`t3.micro`
キーペア	キーペアなしで続行（Session Manager を使うため）
VPC	`lamp-handson-vpc`
サブネット	パブリックサブネット ap-northeast-1a（`10.0.0.0/20`）
パブリック IP の自動割り当て	有効化忘れがち
ファイアウォール	既存のセキュリティグループを選択 → `lamp-web-sg`
ストレージ	8 GiB / gp3（デフォルトのまま）
高度な詳細 → IAM インスタンスプロファイル	`lamp-ssm-role`

右側の概要で内容を確認して インスタンスを起動
「インスタンスの状態：実行中」「ステータスチェック：2/2 に合格」になるまで 1〜2 分待つ

つまずきポイント

「パブリック IP の自動割り当て」を有効化し忘れる のが最頻出ミスです。これを忘れるとブログが外から見えないだけでなく、Session Manager でも接続できません（インターネット経由で SSM に到達できないため）。起動後に気づいた場合は、インスタンスを終了して作り直すのがいちばん早いです。

時短のコツ

EC2 の起動待ちに入ったら、すぐ STEP 4 の RDS 作成に進んでください。 RDS の作成には 5〜10 分かかるので、先に走らせておくと全体で 10 分近く短縮できます。

IAM ロール lamp-ssm-role を作成した
EC2 が「実行中」になり、パブリック IPv4 アドレスが表示されている
パブリック IPv4 DNS をメモした（後でブログの URL になります）

RDS で MySQL を作る

LAMP の「M」を EC2 の外に出す

約 12 分（うち待ち 5〜10分）

4-1. DB サブネットグループを作る

サービス検索で RDS → 左メニュー サブネットグループ → DB サブネットグループを作成
名前：lamp-db-subnet-group ／説明：private subnets for handson
VPC：lamp-handson-vpc
アベイラビリティーゾーン：ap-northeast-1a と ap-northeast-1c の両方
サブネット：プライベートサブネット 2 つ（10.0.128.0/20 と 10.0.144.0/20）を選択
作成

なぜ 2 つ必要？

RDS は「いつでも別の AZ に切り替えられる状態」を前提に設計されているため、最低 2 つの AZ のサブネットを要求します。今回は Single-AZ 構成ですが、将来 Multi-AZ にするときにそのまま使えます。ここで 選ぶサブネットを間違えると（＝パブリックを選ぶと）DB が外から見える構成になってしまう ので、慎重に。

4-2. データベースを作成

左メニュー データベース → データベースの作成
作成方法：標準作成

セクション	設定項目	値
エンジン	エンジンのタイプ	MySQL
エンジン	エンジンバージョン	MySQL 8.4.x（8.4 系の最新）8.0 は選ばない
テンプレート	―	無料利用枠（表示されない場合は開発/テスト）
可用性と耐久性	デプロイオプション	単一 DB インスタンス（Multi-AZ にしない）
設定	DB インスタンス識別子	`lamp-blog-db`
設定	マスターユーザー名	`admin`
設定	認証情報管理	セルフマネージド → パスワードを自分で入力
インスタンス設定	DB インスタンスクラス	バースト可能クラス → `db.t4g.micro`
ストレージ	ストレージタイプ / 容量	gp3 / 20 GiB
ストレージ	ストレージ自動スケーリング	無効（チェックを外す）
接続	コンピューティングリソース	EC2 コンピューティングリソースに接続しない
接続	VPC	`lamp-handson-vpc`
接続	DB サブネットグループ	`lamp-db-subnet-group`
接続	パブリックアクセス	なし重要
接続	VPC セキュリティグループ	既存の選択 → `lamp-db-sg`（default は外す）
モニタリング	拡張モニタリング / Performance Insights	両方オフ（費用と時間の節約）
追加設定	最初のデータベース名	空欄のまま（STEP 6 で SQL から作ります）
追加設定	自動バックアップ / 保持期間	有効 / 1 日
追加設定	マイナーバージョン自動アップグレード	有効
追加設定	削除保護	無効（後片付けしやすくするため）

画面下部の 概算月間コスト に必ず目を通す（参加者にも見せる）
データベースの作成 をクリック
ステータスが 作成中 → 利用可能 になるまで 5〜10 分 待つ

待ち時間の使い方

ここで 5〜10 分空きます。RDS の一覧画面を開いたまま、「設定」タブを見せながら 「エンドポイントとは何か」「自動バックアップとスナップショットの違い」「Multi-AZ にすると何が起きるか」を話すと、待ち時間が講義パートに変わります。台本は 5. 発表者向けメモにあります。

DB サブネットグループをプライベートサブネット 2 つで作成した
エンジンバージョンが 8.4 系 になっている
パブリックアクセスが「なし」、SG が lamp-db-sg のみ
ステータスが「利用可能」になった
エンドポイント（lamp-blog-db.xxxxx.ap-northeast-1.rds.amazonaws.com）をコピーしてメモした

Apache と PHP をセットアップする

LAMP の「A」と「P」

約 13 分

5-1. EC2 にブラウザから入る

EC2 コンソール → インスタンス一覧 → lamp-web-01 を選択 → 接続
セッションマネージャー タブを選択 → 接続
黒いターミナルがブラウザ内に開けば成功

「接続」ボタンが押せない場合

IAM ロールがアタッチされてから SSM に登録されるまで 1〜3 分 かかります。少し待って画面を再読み込みしてください。それでもダメなら、インスタンスの「セキュリティ」タブで IAM ロールが付いているか、パブリック IP があるかを確認します。

接続直後は ssm-user というユーザーです。作業しやすいよう ec2-user に切り替えます。

bash ─ ユーザー切り替えと動作確認

sudo su - ec2-user
whoami          # → ec2-user と表示されれば OK
cat /etc/os-release | head -2

5-2. パッケージを更新して LAMP のミドルウェアを入れる

Amazon Linux 2023 では PHP がバージョン付きパッケージ（php8.4 のような名前）で提供されています。まず何が入るか確認してからインストールするのが安全です。

bash ─ 利用可能な PHP を確認

sudo dnf update -y
dnf list available "php8.*" | head -40

bash ─ Apache・PHP 8.4・MySQL クライアントをインストール

sudo dnf install -y \
  httpd \
  mariadb105 \
  php8.4 php8.4-fpm php8.4-mysqlnd php8.4-gd \
  php8.4-mbstring php8.4-xml php8.4-intl php8.4-opcache

パッケージが見つからないと言われたら

リポジトリの更新状況によっては php8.4-* の一部が無い場合があります。その場合は php8.4 を php8.3 に読み替えてください（WordPress 7.x の推奨は PHP 8.3 以上なので 8.3 でも動作します）。個別の拡張が無い場合は、その拡張だけコマンドから外して実行すれば問題ありません。

bash ─ サービスを起動して自動起動を有効化

sudo systemctl enable --now httpd php-fpm
systemctl is-active httpd php-fpm    # → active が 2 行
php -v                               # → PHP 8.4.x
mysql --version                      # → クライアントが入っていることを確認

5-3. ここでいったんブラウザで確認見せ場

EC2 の パブリック IPv4 DNS をブラウザで開きます（必ず http://。https では繋がりません）。

Apache のテストページが表示されれば、L と A が動いた ということです。ここで一度「見えた！」を作ると場が温まります。

bash ─ PHP の動作確認ページを作る（確認後すぐ消します）

echo "<?php phpinfo(); ?>" | sudo tee /var/www/html/info.php > /dev/null

http://<パブリックDNS>/info.php を開いて PHP の情報画面が出れば P も動作。確認できたら必ず消します。

bash ─ phpinfo は情報漏洩になるので必ず削除

sudo rm -f /var/www/html/info.php

説明のポイント

phpinfo() はサーバーの構成情報を丸ごと晒します。動作確認には便利ですが、本番に置きっぱなしにするのは典型的な脆弱性です。「便利なものほど消し忘れが怖い」という話をここで挟むと印象に残ります。

Session Manager で EC2 に接続できた
httpd と php-fpm が active
ブラウザで Apache のテストページが見えた
phpinfo が表示され、確認後に削除した

RDS に接続してデータベースを作る

EC2 と RDS が繋がる瞬間

約 8 分

6-1. まず疎通確認

いきなりログインせず、ポートが開いているかから確認すると、トラブル時の切り分けが速くなります。

bash ─ RDS エンドポイントを変数に入れておく

# ↓ 自分の RDS エンドポイントに書き換えてください
RDS_HOST="lamp-blog-db.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com"

# 名前解決できるか（VPC 内部のプライベート IP が返れば正常）
getent hosts "$RDS_HOST"

# 3306 に到達できるか
timeout 5 bash -c "</dev/tcp/$RDS_HOST/3306" && echo "OK: 3306 に到達" || echo "NG: 到達できません"

「NG」と出たときのチェック順

① lamp-db-sg のインバウンドに 3306 ← lamp-web-sg があるか
② RDS の VPC セキュリティグループが lamp-db-sg になっているか（default のままではないか）
③ RDS のステータスが「利用可能」か
④ EC2 に lamp-web-sg が付いているか

6-2. MySQL にログインして DB とユーザーを作る

bash ─ RDS にログイン（RDS 作成時のマスターパスワードを入力）

mysql -h "$RDS_HOST" -u admin -p

SQL ─ WordPress 用のデータベースとユーザーを作成

SELECT VERSION();

CREATE DATABASE wordpress
  DEFAULT CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

-- ↓ 'ここに強いパスワード' は自分で決めた値に書き換えてください
CREATE USER 'wpuser'@'%' IDENTIFIED BY 'ここに強いパスワード';

GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'%';
FLUSH PRIVILEGES;

SHOW DATABASES;
EXIT;

説明のポイント ①：@'%' って何？

MySQL のユーザーは「ユーザー名＋どこから来たか」のセットで管理されます。% は「任意のホストから」の意味。一見ゆるく見えますが、ネットワーク的には既にセキュリティグループで Web サーバーからしか到達できないので実質的に絞られています。「多層防御（ネットワーク層とアプリ層の両方で守る）」の話に繋げられます。

説明のポイント ②：文字コードは utf8mb4

utf8mb4 にしないと絵文字（4バイト文字）が保存できません。日本語ブログでは実害が出る定番の落とし穴です。「昔の utf8 は実は 3バイトまでの中途半端なやつだった」という小ネタは受けがいいです。

MySQL 8.4 の認証方式について

MySQL 8.4 では旧来の mysql_native_password がデフォルト無効になり、caching_sha2_password が標準です。 PHP 8.4 の mysqlnd ドライバはこれに対応しているため、追加設定なしで WordPress から接続できます。（古い PHP や古いクライアントで「認証プラグインが読み込めない」エラーが出る、という話の背景がこれです。）

3306 への到達確認が OK
MySQL にログインできた（SELECT VERSION(); が 8.4.x）
データベース wordpress とユーザー wpuser を作成した

WordPress を配置する

ダウンロード → 設定 → 権限

約 8 分

7-1. ダウンロードして配置

bash ─ 日本語版 WordPress を取得して DocumentRoot へ

cd /tmp
curl -fsSL -O https://ja.wordpress.org/latest-ja.tar.gz
tar xzf latest-ja.tar.gz

sudo cp -r /tmp/wordpress/. /var/www/html/
ls /var/www/html/ | head # wp-admin, wp-content, wp-includes などが見えれば OK

7-2. wp-config.php を作る

bash ─ サンプルから設定ファイルを作成

cd /var/www/html
sudo cp wp-config-sample.php wp-config.php

DB 接続情報を書き込みます。手で編集してもいいですが、ハンズオンでは sed で一括置換すると事故が減ります。

bash ─ 接続情報を流し込む（3行の値を自分の環境に合わせて書き換え）

DB_NAME="wordpress"
DB_USER="wpuser"
DB_PASS="ここに STEP 6 で決めたパスワード"

# STEP 6 から続けて同じセッションなら RDS_HOST は設定済み。
# 接続し直した場合は、下の行のコメントを外して再設定してください。
# RDS_HOST="lamp-blog-db.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com"

sudo sed -i \
  -e "s/database_name_here/${DB_NAME}/" \
  -e "s/username_here/${DB_USER}/" \
  -e "s/password_here/${DB_PASS}/" \
  -e "s/localhost/${RDS_HOST}/" \
  /var/www/html/wp-config.php

# 確認（パスワード行が見えるので投影中は注意）
sudo grep -E "DB_(NAME|USER|HOST)" /var/www/html/wp-config.php

パスワードに / や & が入っている場合

sed の置換文字列として解釈されて壊れます。vi /var/www/html/wp-config.php で手編集するか、パスワードを英数字とハイフン・アンダースコアだけで作り直してください。RDS のパスワードを決める段階で記号を控えめにしておくのが確実です。

ここが今日の主役の 1 行

define('DB_HOST', 'localhost'); だったところが RDS のエンドポイントに変わりました。
「LAMP の M だけが別のサーバーに移った」という今日のテーマが、この 1 行に集約されています。投影して指差しながら説明する価値があります。

7-3. セキュリティキー（Salt）を設定

ログインセッションの暗号化に使うランダム文字列です。サンプルのままだと危険なので必ず設定します。

bash ─ 公式 API から Salt を取得して差し込む

# 生成された値を確認
curl -s https://api.wordpress.org/secret-key/1.1/salt/

# サンプルの Salt 行を削除して、生成した値を挿入する
SALT=$(curl -s https://api.wordpress.org/secret-key/1.1/salt/)
sudo sed -i "/AUTH_KEY\|SECURE_AUTH_KEY\|LOGGED_IN_KEY\|NONCE_KEY\|AUTH_SALT\|SECURE_AUTH_SALT\|LOGGED_IN_SALT\|NONCE_SALT/d" /var/www/html/wp-config.php
echo "$SALT" | sudo tee -a /var/www/html/wp-config.php > /dev/null

7-4. Apache の設定と権限

bash ─ .htaccess を有効にする（パーマリンク設定に必要）

sudo sed -i '/<Directory "\/var\/www\/html">/,/<\/Directory>/ s/AllowOverride None/AllowOverride All/' /etc/httpd/conf/httpd.conf

# 変更されたか確認
sudo grep -A4 '<Directory "/var/www/html">' /etc/httpd/conf/httpd.conf

bash ─ 所有者とパーミッションを整える

sudo chown -R apache:apache /var/www
sudo find /var/www -type d -exec chmod 2775 {} \;
sudo find /var/www -type f -exec chmod 0644 {} \;

sudo systemctl restart httpd php-fpm
systemctl is-active httpd php-fpm

説明のポイント：なぜ 2775 ？

先頭の 2 は setgid。これを付けておくと、そのディレクトリ配下に新しく作られたファイルが自動的に apache グループを引き継ぎます。WordPress がプラグインやメディアを書き込んだあとも権限が崩れにくくなる、という実務的な工夫です。

WordPress のファイルが /var/www/html/ に配置された
wp-config.php の DB_HOST が RDS エンドポイントになっている
Salt を設定した
AllowOverride All に変更し、httpd を再起動した

ブログを公開する

ブラウザから初期設定 → 記事投稿

約 8 分

ブラウザで http://<EC2 のパブリック IPv4 DNS>/ を開く
WordPress のインストール画面が出たら以下を入力
- サイトのタイトル：AWS ハンズオンブログ（何でも可）
- ユーザー名：wpadmin など（admin は避ける：総当たり攻撃の定番）
- パスワード：自動生成されたものを必ずコピーして保存
- メールアドレス：自分のもの
WordPress をインストール → ログイン
ダッシュボードから 投稿 → 新規追加 で記事を 1 本書いて公開
サイトを表示して、記事が見えることを確認

ここまでで完成

参加者それぞれのブログ URL をチャットに貼ってもらうと、一気に達成感のある場になります。「みんな別々のサーバーで、別々の DB を使って、同じ手順から違うブログができた」という実感が生まれます。

忘れず伝えること：この状態は「まだ本番ではない」

① HTTPS ではない — ログインパスワードが平文で流れます。WordPress 7.x は全インストールで HTTPS を必須要件として案内しています。
② IP アドレスが固定されていない — EC2 を停止・起動するとパブリック IP が変わり、URL も変わります。
③ 冗長化されていない — EC2 も RDS も 1 台構成です。
これらを解決する道筋は 4. 次のステップにまとめてあります。

WordPress の初期設定が完了した
記事を 1 本公開して、サイト上で見えた

見せ場デモ ── なぜ DB を分けたのか

3 分でできる「おおっ」となる実演

約 8 分

デモ A：Web サーバーを再起動してもデータは消えない

EC2 コンソールで lamp-web-01 を選択 → インスタンスの状態 → インスタンスを再起動
1〜2 分待ってからブログを再読み込み
記事がそのまま表示される

言うべきこと：「記事の本文は EC2 の中には一切ありません。RDS の中にあります。だから Web サーバーが再起動しても、極端な話 Web サーバーを作り直しても、記事は無事です。」

より強いインパクトを狙うなら

EC2 を 停止 → 起動 するとパブリック IP が変わり、WordPress が旧 URL を保持しているため画面が崩れます。これは「なぜ Elastic IP や ALB、独自ドメインが必要なのか」を痛感させる非常に良い教材ですが、復旧に時間がかかるので時間に余裕があるときだけにしてください。

デモ B：DB は外部から見えないことを確認する

手元の PC（AWS の外）から RDS エンドポイントに繋がらないことを見せます。

bash ─ ローカル PC のターミナルで実行（失敗するのが正解）

nslookup lamp-blog-db.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
# → 名前解決できない、またはプライベート IP が返る = 外からは到達不能

言うべきこと：「データベースはインターネットから存在すら見えません。到達できるのは、あの緑のサブネットにいる Web サーバーだけです。」

デモ C：スナップショットを取ってみる任意

RDS コンソール → lamp-blog-db → アクション → スナップショットの取得
名前：lamp-blog-db-handson → スナップショットを取得

言うべきこと：「バックアップの取得がボタン 1 つ。自前で MySQL を運用していたら、mysqldump の cron を書いて、保存先を用意して、リストア手順を書いて……という作業が必要でした。これがマネージドサービスの価値です。」

スナップショットも課金対象

手動スナップショットは DB を削除しても残り続けます。後片付けで必ず削除してください。

デモ A：EC2 再起動後も記事が残っていることを確認した
デモ B：外部から RDS に到達できないことを見せた

2. トラブルシューティング

ハンズオンで実際によく出る順に並べています。当日はこの表だけ別ウィンドウで開いておくと安心です。

症状	よくある原因	確認・対処
ブラウザでサイトが開かない（タイムアウト）	SG で 80 が開いていない／パブリック IP がない／`https://` でアクセスしている	`lamp-web-sg` のインバウンドに HTTP 80 ← 0.0.0.0/0 があるか。URL が `http://` か。ブラウザが自動で https に変えていないか（シークレットウィンドウで試す）
「接続が拒否されました」	httpd が起動していない	`sudo systemctl status httpd` → 落ちていれば `sudo journalctl -u httpd -n 50` でログ確認
Session Manager の「接続」ボタンが灰色	IAM ロール未アタッチ／SSM 登録待ち／パブリック IP なし	インスタンスの「セキュリティ」タブで IAM ロールを確認。付けた直後なら 2〜3 分待って再読み込み
「データベース接続確立エラー」	DB_HOST / DB_USER / DB_PASSWORD の誤り、または SG	`mysql -h "$RDS_HOST" -u wpuser -p wordpress` をシェルから直接試す。ここで繋がるなら `wp-config.php` の値が原因
3306 に到達しない	`lamp-db-sg` のソースが `lamp-web-sg` になっていない／RDS に default SG が付いたまま	RDS の「接続とセキュリティ」タブで VPC セキュリティグループを確認。`default` が付いていたら `lamp-db-sg` のみに変更
RDS のエンドポイントが名前解決できない	VPC の DNS ホスト名／DNS 解決が無効	VPC の「アクション → VPC 設定を編集」で両方を有効化
PHP のコードがそのままブラウザに表示される	PHP が Apache に紐付いていない／php-fpm が停止	`sudo systemctl restart httpd php-fpm`。それでもダメなら `php8.4-fpm` がインストールされているか確認
`dnf` で php8.4-* が見つからない	リポジトリのバージョン差	`dnf list available "php8.*"` で実在するものを確認し、`php8.3` 系に読み替える
画像アップロードやプラグイン導入で権限エラー	所有者が `apache` になっていない	STEP 7-4 の `chown`／`chmod` をもう一度実行
パーマリンクを変えたら記事が 404	`AllowOverride None` のまま	STEP 7-4 の httpd.conf 修正を実施し `sudo systemctl restart httpd`
EC2 を停止・起動したら画面が崩れた	パブリック IP が変わり、DB 内の旧 URL と不一致	WP-CLI で URL を一括置換： `curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar` `sudo -u apache php wp-cli.phar search-replace '旧URL' '新URL' --path=/var/www/html --skip-columns=guid`
RDS の作成が終わらない	通常 5〜10 分。それ以上は稀	「ログとイベント」タブでイベントを確認。焦らず待つ。時間が惜しければ講義パートを挟む

3. 後片付け ── 必ずやりきる

削除は「作った逆順」で

依存関係があるため、この順番で消さないとエラーになります。ハンズオンの時間内に、全員でここまでやりきってください。 「あとで各自で」にすると、必ず消し忘れる人が出ます。

① RDS の手動スナップショットを削除 — RDS → スナップショット → 手動 → 該当を選んで削除
② RDS インスタンスを削除 — lamp-blog-db → アクション → 削除。
「最終スナップショットを作成」のチェックを外す／「自動バックアップを保持」も外す／確認欄に delete me と入力
③ EC2 インスタンスを終了 — lamp-web-01 → インスタンスの状態 → インスタンスを終了（「停止」ではなく「終了」）。EBS も一緒に削除されます
④ DB サブネットグループを削除 — RDS → サブネットグループ → lamp-db-subnet-group を削除
⑤ セキュリティグループを削除 — 先に lamp-db-sg、次に lamp-web-sg（参照関係があるため順番が重要）
⑥ VPC を削除 — VPC → lamp-handson-vpc → アクション → VPC を削除。サブネット・ルートテーブル・IGW も一緒に消えます
⑦ IAM ロールを削除 任意 — lamp-ssm-role（無料なので残しても課金なし）
⑧ Elastic IP の確認 — EC2 → Elastic IP。未割り当てのものがあれば必ず解放
⑨ 翌日、請求ダッシュボードを確認 — 想定外の課金がないかチェック。予算アラートは残しておくと安心

VPC が消せないと言われたら

VPC 内にまだ何か残っています。エラーメッセージに依存リソースが表示されるので、それを先に消してください。よくあるのは「終了中の EC2 が残っている」「ENI（ネットワークインターフェース）が残っている」の 2 パターンです。数分待つと消えることが多いです。

4. 次のステップ ── この構成をどう本番に近づけるか

ハンズオンの締めで「今日つくったものの先」を示すと、参加者の学習が続きます。難易度順に並べています。

① 独自ドメイン＋ HTTPS 化

Route 53 でドメインを取得し、ALB ＋ ACM（証明書は無料）で HTTPS 終端。 IP アドレス直打ちから卒業し、パスワードが平文で流れる問題も解消します。最優先で足すべき要素。

② RDS の Multi-AZ 化

チェックボックス 1 つで別 AZ に待機系が立ち、障害時に自動フェイルオーバー。今日プライベートサブネットを 2 つ作っておいた理由がここで回収されます。コストは約 2 倍になる点も併せて。

③ 画像を S3 ＋ CloudFront へ

メディアファイルを EC2 のディスクから S3 に逃がすと、EC2 が「使い捨て可能」になります。 CloudFront を前に置けば表示も高速化。プラグインで実現できます。

④ Auto Scaling ＋ ALB で冗長化

Web 層を複数台に。③ を先にやっておかないと「サーバーによって画像が見えたり見えなかったり」する問題が起きます。順番に意味があることを説明する好例です。

⑤ 認証情報を Secrets Manager へ

今日は wp-config.php にパスワードを直書きしました。本番では Secrets Manager や Parameter Store に置き、自動ローテーションさせます。

⑥ 今日の手順をコード化（IaC）

CloudFormation や Terraform で書けば、今日の 90 分が 5 分で再現できます。「手作業でやったからこそコード化の価値が分かる」という締め方は非常に効果的です。

5. 発表者向けメモ

導入のつかみ（2 分）

導入トーク例

「LAMP という言葉、聞いたことある方どれくらいいますか？ Linux・Apache・MySQL・PHP の頭文字で、Web サービスを動かす一番オーソドックスな組み合わせです。世界の Web サイトの相当な割合が、今もこの構成で動いています。」

「今日はこれを AWS の上に建てます。ただし、ひとつだけ普通と違うことをします。M の MySQL だけ、サーバーの外に出します。」

「なぜそんなことをするのか。それが今日のいちばんのテーマです。最後にちゃんと体感してもらいます。」

RDS 作成待ちの 5〜10 分をどう埋めるか

この待ち時間の設計が、ハンズオンの質を左右します。以下から場の反応を見て 2〜3 個。

ネタ ①：エンドポイントという概念

「RDS には IP アドレスではなく名前でアクセスします。なぜか。障害が起きて別のサーバーに切り替わっても、名前は変わらないからです。アプリ側は何も知らずに済む。これがマネージドサービスの設計思想です。」

ネタ ②：自動バックアップとスナップショットの違い

「自動バックアップは保持期間を過ぎると自動で消えます。手動スナップショットは自分で消すまで永遠に残ります——そして課金され続けます。実務で『昔の担当者が取ったスナップショットが数年分溜まっていた』という話は本当によくあります。」

ネタ ③：なぜ MySQL 8.0 を選ばないのか

「バージョン選択で 8.0 を選んだ人はいませんか？実は 8.0 は 2026年7月末で標準サポートが終わっていて、今から使うと自動的に有償の延長サポート扱いになります。『とりあえず慣れたバージョン』を選ぶと課金される——クラウドではよくある落とし穴です。」

ネタ ④：セキュリティグループの SG 参照（復習）

「さっき DB のファイアウォールで、IP アドレスではなくセキュリティグループそのものを指定しましたよね。あれは『この名札を付けたサーバーなら通す』という指定です。サーバーが 1 台から 10 台に増えても、ルールは 1 行のままでいい。」

締めの一言（1 分）

クロージング例

「今日、皆さんはサーバーを 1 台立てて、データベースを別に用意して、その 2 つをネットワークで安全に繋ぎました。これは 15 年前なら、機材を発注して届くまで数週間かかっていた作業です。」

「そして今から、その全部を 5 分で消します。使った分だけ払って、いらなくなったら消す。これがクラウドの本質です。」

「ここから先は、HTTPS を付けるのか、サーバーを 2 台にするのか、それとも今日の手順を全部コードに書き起こすのか。次に何をやりたいか、ぜひ考えてみてください。」

進行上の注意

リージョンの確認は毎ステップ声に出す。気づかずバージニア北部で作っていて「リソースが見つからない」は最頻出事故です
パスワードを投影しない。RDS のパスワード入力時と wp-config.php 表示時は、画面共有を一時停止するか値を伏せる
置いていかれた人を拾う仕組みを。各 STEP の最後に「できた人は反応ください」と確認するか、サポート役をもう 1 人立てる
完成環境のバックアップを用意。自分の環境が詰まったら即座にそちらへ切り替えて、原因究明は後回しに
後片付けの時間を必ず確保。押したときに削るのは STEP 9 のデモであって、後片付けではありません

付録 A. 時短用ユーザーデータ

EC2 起動時の「高度な詳細 → ユーザーデータ」に貼り付けると、STEP 5 と STEP 7 の大部分が自動で完了します。 45 分の短縮版で使う想定です。フル版では手作業のほうが学びが大きいので、この付録は使わないことをおすすめします。

EC2 ユーザーデータ ─ 起動時に Apache + PHP + WordPress を自動セットアップ

#!/bin/bash
set -xe

dnf update -y
dnf install -y httpd mariadb105 \
  php8.4 php8.4-fpm php8.4-mysqlnd php8.4-gd \
  php8.4-mbstring php8.4-xml php8.4-intl php8.4-opcache

systemctl enable --now httpd php-fpm

# WordPress を取得して配置
cd /tmp
curl -fsSL -O https://ja.wordpress.org/latest-ja.tar.gz
tar xzf latest-ja.tar.gz
cp -r /tmp/wordpress/. /var/www/html/
cp /var/www/html/wp-config-sample.php /var/www/html/wp-config.php

# Salt を設定
SALT=$(curl -s https://api.wordpress.org/secret-key/1.1/salt/)
sed -i "/AUTH_KEY\|SECURE_AUTH_KEY\|LOGGED_IN_KEY\|NONCE_KEY\|AUTH_SALT\|SECURE_AUTH_SALT\|LOGGED_IN_SALT\|NONCE_SALT/d" /var/www/html/wp-config.php
echo "$SALT" >> /var/www/html/wp-config.php

# .htaccess を有効化
sed -i '/<Directory "\/var\/www\/html">/,/<\/Directory>/ s/AllowOverride None/AllowOverride All/' /etc/httpd/conf/httpd.conf

# 権限
chown -R apache:apache /var/www
find /var/www -type d -exec chmod 2775 {} \;
find /var/www -type f -exec chmod 0644 {} \;

systemctl restart httpd php-fpm

ユーザーデータ使用時の残作業

DB 接続情報（DB_NAME / DB_USER / DB_PASSWORD / DB_HOST）は RDS 作成後にしか分からないため、 STEP 6 と STEP 7-2 は手動で実施してください。ログは /var/log/cloud-init-output.log で確認できます。

付録 B. AWS CLI 版（参考・自分のリハーサル用）

本編はコンソール操作ですが、リハーサルや環境の作り直しにはこちらが速いです。実行前に aws configure でリージョンを ap-northeast-1 に。

bash ─ VPC・サブネット・IGW を作る

VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=lamp-handson-vpc}]' \
  --query 'Vpc.VpcId' --output text)

aws ec2 modify-vpc-attribute --vpc-id "$VPC_ID" --enable-dns-hostnames
aws ec2 modify-vpc-attribute --vpc-id "$VPC_ID" --enable-dns-support

PUB_A=$(aws ec2 create-subnet --vpc-id "$VPC_ID" --cidr-block 10.0.0.0/20 \
  --availability-zone ap-northeast-1a --query 'Subnet.SubnetId' --output text)
PUB_C=$(aws ec2 create-subnet --vpc-id "$VPC_ID" --cidr-block 10.0.16.0/20 \
  --availability-zone ap-northeast-1c --query 'Subnet.SubnetId' --output text)
PRI_A=$(aws ec2 create-subnet --vpc-id "$VPC_ID" --cidr-block 10.0.128.0/20 \
  --availability-zone ap-northeast-1a --query 'Subnet.SubnetId' --output text)
PRI_C=$(aws ec2 create-subnet --vpc-id "$VPC_ID" --cidr-block 10.0.144.0/20 \
  --availability-zone ap-northeast-1c --query 'Subnet.SubnetId' --output text)

IGW_ID=$(aws ec2 create-internet-gateway --query 'InternetGateway.InternetGatewayId' --output text)
aws ec2 attach-internet-gateway --vpc-id "$VPC_ID" --internet-gateway-id "$IGW_ID"

RTB_ID=$(aws ec2 create-route-table --vpc-id "$VPC_ID" --query 'RouteTable.RouteTableId' --output text)
aws ec2 create-route --route-table-id "$RTB_ID" --destination-cidr-block 0.0.0.0/0 --gateway-id "$IGW_ID"
aws ec2 associate-route-table --route-table-id "$RTB_ID" --subnet-id "$PUB_A"
aws ec2 associate-route-table --route-table-id "$RTB_ID" --subnet-id "$PUB_C"
aws ec2 modify-subnet-attribute --subnet-id "$PUB_A" --map-public-ip-on-launch

bash ─ セキュリティグループ 2 つ

WEB_SG=$(aws ec2 create-security-group --group-name lamp-web-sg \
  --description "Allow HTTP from internet" --vpc-id "$VPC_ID" --query 'GroupId' --output text)
aws ec2 authorize-security-group-ingress --group-id "$WEB_SG" \
  --protocol tcp --port 80 --cidr 0.0.0.0/0

DB_SG=$(aws ec2 create-security-group --group-name lamp-db-sg \
  --description "Allow MySQL from web tier" --vpc-id "$VPC_ID" --query 'GroupId' --output text)
aws ec2 authorize-security-group-ingress --group-id "$DB_SG" \
  --protocol tcp --port 3306 --source-group "$WEB_SG"

bash ─ RDS（MySQL 8.4）

aws rds create-db-subnet-group \
  --db-subnet-group-name lamp-db-subnet-group \
  --db-subnet-group-description "private subnets for handson" \
  --subnet-ids "$PRI_A" "$PRI_C"

# 利用可能な 8.4 系のバージョンを確認
aws rds describe-db-engine-versions --engine mysql \
  --query 'DBEngineVersions[?starts_with(EngineVersion,`8.4`)].EngineVersion' --output text

aws rds create-db-instance \
  --db-instance-identifier lamp-blog-db \
  --db-instance-class db.t4g.micro \
  --engine mysql \
  --engine-version 8.4.9 \
  --master-username admin \
  --master-user-password 'ここに強いパスワード' \
  --allocated-storage 20 \
  --storage-type gp3 \
  --db-subnet-group-name lamp-db-subnet-group \
  --vpc-security-group-ids "$DB_SG" \
  --no-publicly-accessible \
  --backup-retention-period 1 \
  --no-multi-az \
  --no-deletion-protection

bash ─ EC2（IAM ロールは事前に作成しておく）

AMI_ID=$(aws ssm get-parameters \
  --names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query 'Parameters[0].Value' --output text)

aws ec2 run-instances \
  --image-id "$AMI_ID" \
  --instance-type t3.micro \
  --subnet-id "$PUB_A" \
  --security-group-ids "$WEB_SG" \
  --associate-public-ip-address \
  --iam-instance-profile Name=lamp-ssm-role \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=lamp-web-01}]'

bash ─ 後片付け（逆順）

aws rds delete-db-instance --db-instance-identifier lamp-blog-db \
  --skip-final-snapshot --delete-automated-backups
aws ec2 terminate-instances --instance-ids "$INSTANCE_ID"
# 削除完了を待ってから
aws rds delete-db-subnet-group --db-subnet-group-name lamp-db-subnet-group
aws ec2 delete-security-group --group-id "$DB_SG"
aws ec2 delete-security-group --group-id "$WEB_SG"
# サブネット・ルートテーブル・IGW・VPC の順に削除

付録 C. 想定 Q&A

質問	答え方
EC2 1台に MySQL も入れちゃダメなんですか？	ダメではありません。学習用や個人ブログなら十分実用的です。ただ、サーバーを作り直すたびにデータの移行が必要になり、バックアップも自分で仕組みを作る必要があります。「あとで困る形」を最初から避けるのが今日の構成です。
RDS は高くないですか？	高いです。EC2 に MySQL を入れるより確実にお金がかかります。その代わりバックアップ・パッチ適用・障害時の切り替えを AWS が肩代わりします。「エンジニアの時間」と「サーバー代」のどちらが高いかという判断になります。
Lightsail じゃダメなんですか？	WordPress を動かすだけなら Lightsail や Amplify のほうが速くて安いです。今日 EC2 と RDS を使うのは、VPC・サブネット・セキュリティグループという AWS の土台を理解するためです。土台が分かると、他のサービスの理解も速くなります。
なぜ Nginx ではなく Apache？	LAMP の A が Apache だからです。実務では Nginx も多く使われます。`.htaccess` が使えるぶん WordPress との相性は Apache のほうが良い、というのが今日 Apache を選んだ実務的な理由です。
SSH で入らないんですか？	今日は Session Manager を使います。22番ポートを開けず、鍵ファイルも管理せずに済みます。「サーバーに入る＝SSH」という常識は、AWS では少し変わってきています。
本番でこの構成をそのまま使えますか？	使えません。最低でも HTTPS 化と、EC2 の IP 固定（ALB か Elastic IP）が必要です。次のステップに道筋をまとめてあります。
間違って高額請求が来たら？	まず該当リソースを止めて、AWS Support に「Billing」カテゴリで問い合わせてください。初回かつ学習目的の明らかな事故であれば、返金対応がなされたケースもあります（保証はされません）。だからこそ STEP 0 の予算アラートが大事です。
手順をコードにできますか？	できます。CloudFormation か Terraform で書けば、今日の 90 分が数分で再現できます。手でやったからこそ、コードが何をしているか読めるようになります。

構成図 ─ 今日つくるもの

パラメータ一覧（先に決めておく値）

タイムテーブル（90分想定）

1. 事前準備

参加者に事前にやってきてもらうこと

発表者側の準備

費用の話 ── 最初に必ず伝える

ハンズオン本編

予算アラートを設定する

操作手順

VPC を作る

操作手順

セキュリティグループを 2 つ作る

2-1. Web 用セキュリティグループ

2-2. DB 用セキュリティグループ

EC2 インスタンスを起動する

3-1. Session Manager 用の IAM ロールを作る

3-2. インスタンスを起動

RDS で MySQL を作る

4-1. DB サブネットグループを作る

4-2. データベースを作成

Apache と PHP をセットアップする

5-1. EC2 にブラウザから入る

5-2. パッケージを更新して LAMP のミドルウェアを入れる

5-3. ここでいったんブラウザで確認 見せ場

RDS に接続してデータベースを作る

6-1. まず疎通確認

6-2. MySQL にログインして DB とユーザーを作る

WordPress を配置する

7-1. ダウンロードして配置

7-2. wp-config.php を作る

7-3. セキュリティキー（Salt）を設定

7-4. Apache の設定と権限

ブログを公開する

見せ場デモ ── なぜ DB を分けたのか

デモ A：Web サーバーを再起動してもデータは消えない

デモ B：DB は外部から見えないことを確認する

デモ C：スナップショットを取ってみる 任意

2. トラブルシューティング

3. 後片付け ── 必ずやりきる

4. 次のステップ ── この構成をどう本番に近づけるか

① 独自ドメイン ＋ HTTPS 化

② RDS の Multi-AZ 化

③ 画像を S3 ＋ CloudFront へ

④ Auto Scaling ＋ ALB で冗長化

⑤ 認証情報を Secrets Manager へ

⑥ 今日の手順をコード化（IaC）

5. 発表者向けメモ

導入のつかみ（2 分）

RDS 作成待ちの 5〜10 分をどう埋めるか

締めの一言（1 分）

進行上の注意

付録 A. 時短用ユーザーデータ

付録 B. AWS CLI 版（参考・自分のリハーサル用）

付録 C. 想定 Q&A

5-3. ここでいったんブラウザで確認見せ場

デモ C：スナップショットを取ってみる任意

① 独自ドメイン＋ HTTPS 化