【AWSハンズオン実践】スケーラブルウェブサイト構築編

1. ハンズオン内容

ℹ️ハンズオンでは各リソースを段階的に作成していきます
ℹ️Cloud9はVSCodeとPowerShellで代用
ℹ️画像はAWS公式ページより引用

• CloudFormationによる自動化はこちら
• Terraformによる自動化は準備中

前提条件＆注意事項

• 一部課金が発生します（数十円程度）。終了後は必ず削除しましょう。このハンズオンはec2が多いので注意です
• 親ページ見てない人は見てね
• UIの操作はルートアカウントを使っています。

2. （Step1）環境作成

※画像はハンズオンより引用

2.1 （Step1）環境作成

VPCなどを一括で作成します。EC2とRDSは含まれません。

• VPC > お使いの VPC > VPC を作成

画面名：VPC を作成

大項目	中項目	選択肢	予備欄／備考
画面名：VPC の設定	🔴作成するリソース	⬜VPC のみ ✅VPC など
	名前タグの自動生成	✅自動生成
	🔴	handson-user1
	IPv4 CIDR ブロック	10.0.0.0/16
	IPv6 CIDR ブロック	✅IPv6 CIDR ブロックなし ⬜Amazon 提供の IPv6 CIDR ブロック
	テナンシー	✅デフォルト ⬜専有
	アベイラビリティゾーン (AZ) の数	⬜1 ✅2 ⬜3
	AZ のカスタマイズ	第 1 アベイラビリティーゾーン	✅ap-northeast-1a ...
		第 2 アベイラビリティーゾーン	✅ap-northeast-1c ...
	パブリックサブネットの数	⬜0 ✅2
	プライベートサブネットの数	⬜0 ✅2 ⬜4
	サブネット CIDR ブロックをカスタマイズ	🔴ap-northeast-1a のパブリックサブネット CIDR ブロック	10.0.0.0/24
		🔴ap-northeast-1c のパブリックサブネット CIDR ブロック	10.0.1.0/24
		🔴ap-northeast-1a のプライベートサブネット CIDR ブロック	10.0.2.0/24
		🔴ap-northeast-1c のプライベートサブネット CIDR ブロック	10.0.3.0/24
	NAT ゲートウェイ ($)	✅なし ⬜1 AZ 内 ⬜AZ ごとに 1
	🔴VPC エンドポイント	✅なし ⬜S3 ゲートウェイ
	DNS オプション	✅DNS ホスト名を有効化 ✅DNS 解決を有効化
	追加のタグ

3. （Step2）EC2作成

※画像はハンズオンより引用

3.1 （Step2）EC2用セキュリティグループ作成

• EC2 > セキュリティグループ > セキュリティグループを作成

画面名：セキュリティグループを作成

大項目	中項目	選択肢	予備欄／備考
基本的な詳細	🔴セキュリティグループ名	web-user1
	🔴説明	web-user1	必須です
	🔴VPC	handson-user1
インバウンドルール１	🔴タイプ	SSH
	プロトコル	TCP
	ポート範囲	22
	🔴ソース	0.0.0.0/0	可能なら制限した方がよい
	説明 - オプション
インバウンドルール２	🔴タイプ	HTTP
	プロトコル	TCP
	ポート範囲	80
	🔴ソース	0.0.0.0/0	可能なら制限した方がよい
	説明 - オプション
アウトバウンドルール
タグ - オプション

3.2 （Step2）EC2作成

ユーザデータはそのままでは古くて動かないので修正しています。

• EC2 > インスタンス > インスタンスを起動

インスタンスを起動

大項目	中項目	選択肢	予備欄／備考
名前とタグ	🔴名前	web-server#1-use1
アプリケーションおよび OS イメージ (Amazon マシンイメージ)	Amazon マシンイメージ (AMI)	Amazon Linux 2023
	アーキテクチャ	64 ビット (x86)
インスタンスタイプ	インスタンスタイプ	t3.micro
キーペア (ログイン)	キーペア名 - 必須	キーペアなしで続行
ネットワーク設定	🔴VPC - 必須	handson-user1	編集ボタンクリックすると入力画面が切り替わります
	🔴サブネット	✅ public-1a ⬜ ...
	🔴パブリック IP の自動割り当て	✅ 有効化 ⬜無効化
	🔴ファイアウォール (セキュリティグループ)	⬜ セキュリティグループを作成 ✅ 既存のセキュリティグループを選択する
	🔴共通のセキュリティグループ	✅ web-user1 ⬜ ...
	高度なネットワーク設定		項目多数により省略
ストレージを設定		1 x 8 GiB gp3 ルートボリューム, 3000 IOPS, 暗号化なし
高度な詳細	ドメイン結合ディレクトリ		値は省略
	IAM インスタンスプロフィール
	ホスト名のタイプ		値は省略
	DNS ホスト名		値は省略
	インスタンスの自動復旧		値は省略
	シャットダウン動作		値は省略
	停止 - 休止動作		値は省略
	終了保護		値は省略
	停止保護		値は省略
	CloudWatch モニタリングの詳細		値は省略
	クレジット仕様		値は省略
	プレイスメントグループ		値は省略
	EBS 最適化インスタンス		値は省略
	インスタンス帯域幅設定		値は省略
	購入オプション		値は省略
	キャパシティーの予約		値は省略
	テナンシー		値は省略
	RAM ディスク ID		値は省略
	カーネル ID		値は省略
	Nitro Enclave		値は省略
	ライセンス設定		値は省略
	CPU オプション		値は省略
	アクセス可能なメタデータ		値は省略
	メタデータ IPv6 エンドポイント		値は省略
	メタデータのバージョン		値は省略
	メタデータレスポンスのホップ制限		値は省略
	メタデータのタグを許可		値は省略
	🔴ユーザーデータ - オプション		下記に記載します
		⬜ ユーザーデータは既に base64 エンコードされています

ユーザデータ、そのまま張り付ける。sudoはなくても動くはず

#!/bin/bash
set -euo pipefail

# システム更新
sudo dnf -y update

# Apache, PHP, 必須拡張, MariaDBクライアント
sudo dnf -y install httpd php php-mbstring php-xml php-mysqlnd mariadb105

# WordPress ダウンロード
curl -L https://ja.wordpress.org/latest-ja.tar.gz -o /tmp/latest-ja.tar.gz

# 展開
tar xzf /tmp/latest-ja.tar.gz -C /tmp

# 配置（既存index.htmlがあれば削除）
sudo rm -f /var/www/html/index.html
sudo rsync -a /tmp/wordpress/ /var/www/html/

# 所有権変更
sudo chown -R apache:apache /var/www/html

# Apache 起動と自動起動設定
sudo systemctl enable --now httpd

# 動作確認用のバージョン表示
php -v
mysql --version

動作確認

http://パブリックIPにアクセスし、WordPressの画面が表示されればOK

4. （Step3）RDSの作成

※画像はハンズオンより引用

4.1 （Step3）RDS用セキュリティグループの作成

• EC2 > セキュリティグループ > セキュリティグループを作成

画面名：セキュリティグループを作成

大項目	中項目	選択肢	予備欄／備考
基本的な詳細	🔴セキュリティグループ名	db-user1
	🔴説明	RDS For MySQL	必須です
	🔴VPC	handson-user1
インバウンドルール１	🔴タイプ	MYSQL/Aurora
	プロトコル	TCP
	ポート範囲	3306
	🔴ソース	web-user1	実際はセキュリティグループのID（sg-XXXXX）です
	説明 - オプション
アウトバウンドルール
タグ - オプション

4.2 （Step3）RDSサブネットグループ作成

• Aurora and RDS > サブネットグループ > DB サブネットグループを作成

DB サブネットグループを作成

大項目	中項目	選択肢	予備欄／備考
サブネットグループの詳細	🔴名前	db-subnet-user1
	🔴説明	RDS For MySQL	必須
	🔴VPC	✅ handson-user1 ⬜ ...	実際にはVPCIDと思われる（vpc-XXX）
サブネットを追加	🔴アベイラビリティーゾーン	✅ap-northeast-1a ✅ap-northeast-1c
	サブネット	🔴ap-northeast-1a	private-1a
		🔴ap-northeast-1c	private-1c

4.3 （Step3）RDSの作成

大項目	中項目	選択肢	予備欄／備考
データベース作成方法を選択		✅標準作成 ⬜簡単に作成
エンジンのオプション	🔴エンジンのタイプ	⬜ Aurora (MySQL Compatible) ⬜ Aurora (PostgreSQL Compatible) ✅ MySQL ⬜ PostgreSQL ⬜ MariaDB ⬜ Oracle ⬜ Microsoft SQL Server ⬜ IBM Db2
	エディション	✅MySQL Community
	フィルターの表示	⬜Babelfish for PostgreSQL 機能をサポートするバージョンのみを表示
		⬜Aurora Limitless Database をサポートするバージョンのみを表示
	エンジンバージョン	✅（デフォルトで選択されているバージョンでOK）
		⬜RDS 延長サポートの有効化
テンプレート	🔴	⬜本番稼働用 ⬜開発/テスト ✅無料利用枠
可用性と耐久性	デプロイオプション	⬜マルチ AZ DB クラスターデプロイ (3 インスタンス) ⬜マルチ AZ DB インスタンスデプロイ (2 インスタンス) ✅シングル AZ DB インスタンスデプロイ (1 インスタンス)
設定	🔴DB クラスター識別子	rds-user1
認証情報の設定	マスターユーザー名	admin
	認証情報管理	⬜AWS Secrets Manager で管理 - 最も安全 ✅セルフマネージド
		⬜パスワードを自動生成
	🔴マスターパスワード	adminadmin
	🔴マスターパスワードを確認	adminadmin
インスタンスの設定	DB インスタンスクラス	⬜Amazon RDS Optimized Writes をサポートするインスタンスクラスを表示
		⬜以前の世代のクラスを含める
		⬜標準クラス (m クラスを含む) ⬜メモリ最適化クラス (r クラスを含む) ✅バースト可能クラス (t クラスを含む)
		✅db.t4g.micro	（デフォルト選択されているクラスでOK）
ストレージ	ストレージタイプ	✅汎用SSD（gp2）	（デフォルト選択されているストレージでOK）
	ストレージ割り当て	20
	追加のストレージ設定	ストレージの自動スケーリング	✅ストレージの自動スケーリングを有効にする
		最大ストレージしきい値	1000
接続	コンピューティングリソース	✅EC2 コンピューティングリソースに接続しない ⬜EC2 コンピューティングリソースに接続
	ネットワークタイプ	✅IPv4 ⬜デュアルスタックモード
	🔴Virtual Private Cloud (VPC)	✅handson-user1	実際にはVPCIDと思われる（vpc-XXX）
	🔴DB サブネットグループ	✅db-subnet-user1
	パブリックアクセス	⬜あり ✅なし
	🔴VPC セキュリティグループ (ファイアウォール)	✅既存の選択 ⬜新規作成
	🔴既存の VPC セキュリティグループ	✅db-user1	実際はセキュリティグループのID（sg-XXXXX）です
	🔴アベイラビリティーゾーン	✅ap-northeast-1a ⬜ap-northeast-1c
	RDS Proxy	⬜RDS Proxy を作成
	認証機関 - 任意	✅rds-ca-rsa2048-g1 (デフォルト)	（デフォルトで選択されているものでOK）
追加設定	データベースポート	3306
タグ - オプション
データベース認証	データベース認証オプション	✅パスワード認証 ⬜パスワードと IAM データベース認証 ⬜パスワードと Kerberos 認証
モニタリング		⬜データベースインサイト - アドバンスト ✅データベースインサイト - スタンダード
	Performance Insights	⬜Performance Insights を有効化
	保持期間	7日
その他のモニタリング設定	拡張モニタリング	⬜拡張モニタリングの有効化
	ログのエクスポート	⬜監査ログ ⬜エラーログ ⬜全般ログ ⬜iam-db-auth-error ログ ⬜スロークエリログ
追加設定	データベースの選択肢	🔴最初のデータベース名	wordpress
		DB パラメータグループ	✅default.mysql8.0
		オプショングループ	✅default:mysql-8-0
	バックアップ	🔴	⬜自動バックアップを有効にします
		バックアップ保持期間	7
		バックアップウィンドウ	⬜ウィンドウを選択 ✅指定なし
			✅スナップショットにタグをコピー
			⬜別の AWS リージョンでレプリケーションを有効化
			✅暗号を有効化
		AWS KMS キー	✅(default) aws/rds
	メンテナンス		✅マイナーバージョン自動アップグレードの有効化
		メンテナンスウィンドウ	⬜ウィンドウを選択 ✅指定なし
			✅削除保護の有効化

ここまで到達できればEC2とRDSは連携可能状態である

5. （Step4）ロードバランサーの作成

※画像はハンズオンより引用

5.1 （Step4）ロードバランサー用セキュリティグループの作成

• EC2 > セキュリティグループ > セキュリティグループを作成

画面名：セキュリティグループを作成

大項目	中項目	選択肢	予備欄／備考
基本的な詳細	🔴セキュリティグループ名	elb-user1
	🔴説明	elb-user1	必須です
	🔴VPC	handson-user1
インバウンドルール１	🔴タイプ	http
	プロトコル	TCP
	ポート範囲	80
	🔴ソース	0.0.0.0/0	す
	説明 - オプション
アウトバウンドルール	タイプ	全てのトラフィック
	プロトコル	すべて
	ポート範囲	すべて
	送信先	0.0.0.0/0
	説明 - オプション
タグ - オプション

5.2 （Step4）ターゲットグループの作成

• EC2 > ターゲットグループ > ターゲットグループの作成

画面名：グループの詳細の指定

大項目	中項目	選択肢	予備欄／備考
基本的な設定	ターゲットタイプの選択	✅インスタンス ⬜IP アドレス ⬜Lambda 関数 ⬜Application Load Balancer
	🔴ターゲットグループ名	target-user1
	プロトコル	✅HTTP ⬜HTTPS ⬜TCP ⬜TLS ⬜UDP ⬜TCP_UDP ⬜GENEVE
	ポート	80
	IP アドレスタイプ	✅IPv4 ⬜IPv6
	🔴VPC	✅handson-user1	実際にはVPCIDと思われる（vpc-XXX）
	プロトコルバージョン	✅HTTP1 ⬜HTTP2 ⬜gRPC
ヘルスチェック	ヘルスチェックプロトコル	✅HTTP ⬜HTTPS
	🔴ヘルスチェックパス	/wp-includes/images/blank.gif
	ヘルスチェックの詳細設定	ヘルスチェックポート	✅トラフィックポート ⬜上書き
		正常のしきい値	5
		非正常のしきい値	2
		タイムアウト	5
		間隔	30
		成功コード	200
タグ - 省略可能

画面名：ターゲットを登録

大項目	中項目	選択肢	予備欄／備考
🔴使用可能なインスタンス		✅web-server#1-use1

5.3 （Step4）ロードバランサーの作成

• EC2 > ロードバランサー > Application Load Balancer を作成

Application Load Balancer を作成

大項目	中項目	選択肢	予備欄／備考
ロードバランサータイプ	🔴	✅Application Load Balancer ⬜Network Load Balancer ⬜Gateway Load Balancer
基本的な設定	🔴ロードバランサー名	elb-user1
	スキーム	✅インターネット向け ⬜内部
	ロードバランサーの IP アドレスタイプ	✅IPv4 ⬜Dualstack
ネットワークマッピング	🔴VPC	✅handson-user1	実際にはVPCIDと思われる（vpc-XXX）
	IP プール
	🔴アベイラビリティーゾーンとサブネット	✅ap-northeast-1a (apne1-az4) ✅ap-northeast-1c (apne1-az1)	実際にはPublicのSubnetIDと思われる（subnet-XXX）
セキュリティグループ	🔴セキュリティグループ	elb-user1	実際はセキュリティグループのID（sg-XXXXX）です
リスナーとルーティング	リスナーHTTP:80	プロトコル	HTTP
		ポート	80
		🔴デフォルトアクション	✅target-user1
		リスナータグ - 省略可能
ロードバランサー タグ - 省略可能
サービスの統合で最適化 - 省略可能	AWS Web Application Firewall (WAF)	⬜アプリケーション層のセキュリティ保護 – ターゲットの前
	AWS Global Accelerator	⬜複数のリージョンにグローバル負荷分散を適用

動作確認

http://ロードバランサーのDNS名にアクセスし、WordPressの画面が表示され、ログインできればOK。画面表示だけだと、DB接続できてなくても可能。

6. （Step5）EC2の冗長化

※画像はハンズオンより引用

6.1 （Step5）（イメージの作成）AMIの作成

• EC2 > インスタンス > web-server#1-use1に☑️ > アクション > イメージとテンプレート > イメージを作成

画面名：イメージを作成

大項目	中項目	選択肢	予備欄／備考
イメージの詳細	🔴イメージ名	wordpress-user1
	イメージの説明 - オプション
		✅インスタンスを再起動	既存のEC2が再起動することになります
インスタンスボリューム		（省略）	デフォルトのままでOK

6.2 （Step5）2台目のEC2作成

※画像はハンズオンより引用

• EC2 > インスタンス > インスタンスを起動

画面名：インスタンスを起動

大項目	中項目	選択肢	予備欄／備考
名前とタグ	🔴名前	web-server#2-use1
アプリケーションおよび OS イメージ (Amazon マシンイメージ)	🔴Amazon マシンイメージ (AMI)	wordpress-user1
インスタンスタイプ	インスタンスタイプ	t3.micro
キーペア (ログイン)	キーペア名 - 必須	キーペアなしで続行
ネットワーク設定	🔴VPC - 必須	handson-user1	編集ボタンクリックすると入力画面が切り替わります
	🔴サブネット	✅public-1c
	🔴パブリック IP の自動割り当て	✅有効化 ⬜無効化
	🔴ファイアウォール (セキュリティグループ)	⬜セキュリティグループを作成 ✅既存のセキュリティグループを選択する
	🔴共通のセキュリティグループ	✅web-user1
	高度なネットワーク設定		項目多数により省略
ストレージを設定		1 x 8 GiB gp3 ルートボリューム, 3000 IOPS, 暗号化なし
高度な詳細	ドメイン結合ディレクトリ		値は省略
	IAM インスタンスプロフィール
	ホスト名のタイプ		値は省略
	DNS ホスト名		値は省略
	インスタンスの自動復旧		値は省略
	シャットダウン動作		値は省略
	停止 - 休止動作		値は省略
	終了保護		値は省略
	停止保護		値は省略
	CloudWatch モニタリングの詳細		値は省略
	クレジット仕様		値は省略
	プレイスメントグループ		値は省略
	EBS 最適化インスタンス		値は省略
	インスタンス帯域幅設定		値は省略
	購入オプション		値は省略
	キャパシティーの予約		値は省略
	テナンシー		値は省略
	RAM ディスク ID		値は省略
	カーネル ID		値は省略
	Nitro Enclave		値は省略
	ライセンス設定		値は省略
	CPU オプション		値は省略
	アクセス可能なメタデータ		値は省略
	メタデータ IPv6 エンドポイント		値は省略
	メタデータのバージョン		値は省略
	メタデータレスポンスのホップ制限		値は省略
	メタデータのタグを許可		値は省略
	ユーザーデータ - オプション		1台目はここで設定しましたが、イメージ作成時に設定が取り込まれているので不要になります
		⬜ユーザーデータは既に base64 エンコードされています

動作確認
作成したインスタンスのVPCがhandson-user1、サブネットがpublic-1cであればOK

6.2 （Step5）EC2をELB（ターゲットグループ）に追加

※画像はハンズオンより引用

• EC2 > ターゲットグループ > target-user1 > ターゲットを登録

大項目	中項目	選択肢	予備欄／備考
🔴使用可能なインスタンス		✅web-server#2-use1	チェック入れる

動作確認
ターゲットグループにweb-server#1-use1、web-server#2-use1が登録されており、ヘルスチェックがHealthyであること

6. （Step6）RDSのマルチインスタンス化

※画像はハンズオンより引用

6.1 （Step6）RDSのマルチインスタンス化

• Aurora and RDS > データベース > DB インスタンスを変更: rds-user1

変更する項目だけ記載します。またデータベース新規作成時にも同項目があるらしいですが、見つけれることはできませんでした。

大項目	中項目	選択肢	予備欄／備考
可用性と耐久性	🔴マルチ AZ 配置	✅スタンバイインスタンスを作成する (本稼働環境向けに推奨) ⬜スタンバイインスタンスを作成しないでください	新規作成時にこの項目が見当たらない
変更のスケジュール	🔴	⬜次回の定期メンテナンス期間中に適用 ✅すぐに適用

動作確認
データベースのステータスが変更中→利用可能、マルチAZの項目がありに変わること

6.2 （Step6）EC2インスタンスを１つ停止させ、全体の可用性を確認

※画像はハンズオンより引用

ここはEC2の冗長化の動作確認です。インスタンスが切り替わってもwordpressの画面がみれるかどうかがポイントです。

1. http://ロードバランサーのDNS名にアクセスし、WordPressの画面が表示されればOK
2. インスタンスweb-server#1-user1を停止する。
3. http://ロードバランサーのDNS名にアクセスし、WordPressの画面が表示されればOK
4. 1. インスタンスweb-server#1-user1を起動する。
5. http://ロードバランサーのDNS名にアクセスし、WordPressの画面が表示されればOK

6.3 （Step6）RDSフェールオーバーを行い、全体の可用性を確認

※画像はハンズオンより引用

ここはRDSのマルチインスタンス化の動作確認です。データベースが切り替わってもwordpressの画面がみれるかどうかがポイントです。

RDSを再起動することによって、フェールオーバーを発生させることができます。フェールオーバーさせる前にRDSのリージョンを確認することをお勧めします。

• Aurora and RDS > データベース > rds-user1にチェック > アクション > 再起動

  ✅フェイルオーバーで再起動しますか?

動作確認

1. データベースのステータスが再起動中→利用可能に変わること
2. http://ロードバランサーのDNS名にアクセスし、WordPressの画面が表示されればOK
3. リージョンがap-northeast-1cまたはap-northeast-1aに変わっていることも確認する。フェールオーバするたびに変わります。

削除

1. データベースの削除rds-user1　（スナップショットは取りません）
2. DBサブネットグループ削除db-subnet-user1
3. インスタンス2台を削除web-server#1-user1,web-server#2-user1
4. AMIの登録解除wordpress-user1 (関連付けられたスナップショットの削除もする)
5. ロードバランサーの削除elb-user1
6. ターゲットグループの削除target-user1
7. VPC削除handson-user1　< ここでセキュリティグループも削除されます >

さいごに

感想です

• 基本の構成ではあるが、こんな簡単な構成はないんだろうなと思うのであった。
• このハンズオンを全て手動でやるのはしんどいです
• DBの設定項目が多すぎる。Auroraだとさらに増えるのかもしれない。
• Auroraを学習した方がいいのではないかと思ったが、MYSQLより数倍コストが高いようだ