【AWS_26】ハンズオンの検証_EC2、RDS、ELB、WordPress、AMIなどを作成・設定する
AWSのハンズオンを参考に検証してみたいと思います。
詳細まで手順や解説があるのでとても勉強になりそうです。
ざっくりの説明となりますが、EC2でWordpress、RDSでデータベースを設定し、負荷分散（ELB：Elastic Load Balancing）配下で動作させるようにします。
さらに可用性を高めるためにEC2の自動スケーリング、RDSのフェールオーバーを設定します。
以下がその流れになります。流れに沿って進めていきたいと思います。
設定する値は、ハンズオンとまったく同じ値を設定して検証しています。
・リージョン・言語選択
・VPC の作成
・Amazon EC2 の作成
・Amazon RDS の作成
・ELB の作成
・WordPress の初期設定
・AMI の作成
・2つ目の EC2 インスタンスの作成
・2つ目の EC 2インスタンスを ELB に登録
・RDS インスタンスのマルチ AZ 配置化
・EC2 インスタンスを1つ停止させ、全体の可用性の確認
・RDS インスタンスのフェイルオーバーを行い、全体の可用性を確認
・作成したリソースの削除
以下が全体構成図となります。
目次
- 1 リージョン・言語の選択
- 2 VPC の作成
- 3 Amazon EC2 の作成
- 4 Amazon RDS の作成
- 5 ELB の作成
- 6 WordPress の初期設定
- 7 AMI の作成
- 8 2つ目の EC2 インスタンスの作成
- 9 2つ目の EC 2インスタンスを ELB に登録
- 10 RDS インスタンスのマルチ AZ 配置化
- 11 EC2 インスタンスを1つ停止させ、全体の可用性の確認
- 12 RDS インスタンスのフェイルオーバーを行い、全体の可用性を確認
- 13 リソースの削除
- 14 EC2 インスタンスの削除
- 15 AMI の登録解除
- 16 EBS スナップショットの削除
- 17 ELB の削除
- 18 VPC の削除
- 19 まとめ
リージョン・言語の選択
リージョンを「アジアパシフィック（東京） 」へ変更します。手順は以下を参照ください。
【AWS_19】現在のリージョンを変更する
言語を選択します。歯車アイコン > すべてのユーザー設定を表示 > ローカリゼーションとデフォルトのリージョンの編集をクリック > ローカリゼーションでデフォルトでは「ブラウザのデフォルト」が選択されていると思います。日本語でない場合は「日本語」を選択して「設定を保存」します。
VPC の作成
1つのVPCとその中に4つのサブネットを作成します。
VPC や サブネットの IP CIDR や サブネット名などは図の通りに作成します。
VPCの作成
東京 リージョンになっていることを確認し、検索ボックスに VPC と入力、VPC をクリックします。
遷移した画面で「VPCを作成」をクリックします。
作成するリソースは、「VPCなど」を選択します。
名前タグの自動生成の欄に handson-ユーザ名 と入力します。例) handson-user1。自動作成のチェックは入れたままにします。
IPv4 CIDR ブロック は、デフォルトままの 10.0.0.0/16 とします。
その他の項目は、デフォルトのままにします。
アベイラビリティゾーン(AZ)の数が 2 になっていることを確認します。
「AZのカスタマイズ」をクリックして、アベイラビリティゾーン選択が以下になっていることを確認します。
第 1 アベイラビリティゾーンが ap-northeast-1a
第 2 アベイラビリティゾーンが ap-northeast-1c
パブリックサブネットの数が 2 になっていることを確認します。
プライベートサブネット数が 2 になっていることを確認します。
「サブネット CIDR ブロックをカスタマイズ」をクリックして以下を入力します。
1番目のサブネットの CIDR ブロックのap-northeast-1aを 10.0.1.0/24 に変更
2番目のサブネットの CIDR ブロックのap-northeast-1cを 10.0.2.0/24 に変更
3番名のサブネットの CIDR ブロックのap-northeast-1aを 10.0.3.0/24 に変更
4番目のサブネットの CIDR ブロックのap-northeast-1cを 10.0.4.0/24 に変更
NAT ゲートウェイは なし を選択します。
VPC エンドポイントは なし を選択します。
DNS オプションはデフォルトのまま(チェックが入ったまま）にします。
追加のタグもデフォルトのままにします。
「VPC を作成」をクリックして、VPCを作成します。
少し待つと、VPC の作成が完了します。
「VPCを表示」 をクリックして、作成した VPC を確認します。
「インターネットゲートウェイ」は、この時点で作成されていました。
VPCが作成されました。
サブネットの名前変更
自動作成された サブネットの名前を変更します。名前の変更は必須ではありませんが、自動作成されるリソース名は見にくいため、ハンズオンに習い変更します。
左側から「サブネット」をクリックします。
handson-user1-subnet-public1-ap-northeast-1a を一覧から探して、右側の編集アイコン（鉛筆）をクリックします。
名前を パブリックサブネット-1a に変更し、「保存」をクリックします。
変更されました。
同じ要領で以下のように変更します。
※パブリック、プライベート、1a、1cを間違えないよう設定します。
正しく名前変更ができているか確認します。
Amazon EC2 の作成
サンプル Web アプリケーションとして、WordPress を利用します。
WordPress がインストールされた EC2 インスタンスを パブリックサブネット-1a 上に 1つ 作成します。
デフォルトのホスト管理設定の構成
今回は、SSHを使用せず、AWS Systems Manager Session Manager を使用して、EC2 インスタンス へ接続します。
事前準備として、EC2 インスタンスに対しデフォルトで AWS Systems Manager を有効にするための設定を行います。
以下の情報を参考に設定してください。
EC2 インスタンスの作成
EC2 インスタンスは、Amazon Linux 2023 で作成します。
WordPress がインストールされた EC2 インスタンスを パブリックサブネット-1a 上に 1つ 作成します。
検索ボックスに ec2 と入力し、表示された EC2 をクリックして、EC2 管理ページに移動します。
「インスタンスを起動」をクリックします。 （この画面が表示されていない場合は、左側から EC2 ダッシュボードをクリックしてください）
名前とタグ に webserver#1-ユーザ名 (例: webserver#1-user1 ) と入力します。
EC2 インスタンスの OS は Amazon Linux 2023 を使用します。 赤枠の3箇所、全てデフォルトの値を使用します
デフォルトの t2.micro インスタンスを選択します。
「キーペア名」に キーペアなしで続行 を選択します。
EC2 インスタンスを、パブリックサブネット-1a 上に作成するため、ネットワーク設定とファイアーウォール(セキュリティグループ)の設定を行います。
「ネットワーク設定」の右にある 「編集」 をクリックします。
「VPC」で 作成した VPC を選択 (例: handson-user1)します。
「サブネット」で パブリックサブネット-1a を選択します。
「パブリック IP の自動割り当て」で 有効化 を選択します。
「ファイアウォール (セキュリティグループ)」で セキュリティグループを作成 を選択します。
「セキュリティグループ名」「説明」ともに web-ユーザ名 (例: web-user1) と入力します。
「インバウンドセキュリティグループのルール」で、すでに表示されている セキュリティグループルール 1 を変更していきます。
「タイプ」を ssh から HTTP に変更します。
「ソースタイプ」を 任意の場所 から 自分のIP に変更します。そして、「ソース」に 自分のグローバルIPアドレスが表示されていることを確認 (図で マスキングされている部分)します。
「高度なネットワーク設定」は、なにも変更せず（デフォルトのまま）します。
「ストレージ設定」は、デフォルト のまま（ 8 GiB / gp3 ルートボリューム）にします。
EC2 インスタンスの初回起動時に自動で後述のスクリプトを実行し、WordPress の自動インストールを行います。
「高度な詳細」をクリックして展開し、「ユーザーデータ」 までスクロールします。（一番下にあります）
以下のコードをコピーします。
#!/bin/bash
dnf update -y
dnf install -y httpd wget php-fpm php-mysqli php-json php php-devel mariadb105
wget http://ja.wordpress.org/latest-ja.tar.gz -P /tmp/
tar zxvf /tmp/latest-ja.tar.gz -C /tmp
cp -r /tmp/wordpress/* /var/www/html/
chown apache:apache -R /var/www/html
systemctl enable httpd.service
systemctl start httpd.service
コピーしたスクリプトを「ユーザーデータ」のテキストボックスに貼り付けます。
「ユーザーデータは既に base64 エンコードされています」のチェックは外したままにします。
入力した項目に間違いないことを確認し「いンスタンスを起動」をクリックします。
「成功」 と表示され、EC2 インスタンスが作成できました。
「すべてのインスタンスを表示」をクリックすると作成したインスタンスの詳細情報が確認できます。
作成したインスタンスが表示(図の場合 webserver#1-user1)されるので、名前の横のチェックボックスにチェックを入れます。
画面下の詳細タブをクリックすると設定情報が表示されます。
「プライベートIPv4アドレス」は、自動で設定されていました。
後ほど利用しますので「パブリックIPv4アドレス」を控えておきます。
セキュリティタブをクリックし、設定どおりであるか確認します。
WordPress のインストール確認
先ほど作成した EC2 インストール上に、WordPress が正常にインストールされていることを確認します。
前手順で確認した「パブリックIPv4アドレス」を別ブラウザや別タブへ入力します。
セキュリティで保護された接続・・・が表示された場合は「サイトに進む」を押して先に進みます。
WordPressの初期設定画面が表示されることを確認します。
この時点では初期設定画面が表示されればOKなのでブラウザをこのまま閉じます。
Amazon RDS の作成
WordPress が使用するデータベースとして Amazon RDS for MySQL インスタンスを プライベートサブネット-1a 上に シングル AZ 配置 で作成します。
DB 用セキュリティグループの作成
RDS DB インスタンス作成前に、まず、DB 用のセキュリティグループ(ファイアウォール)を作成します。
検索ボックスで ec2 と入力し、表示された EC2 をクリックします。
左側一覧から「セキュリティグループ」をクリックします。
「セキュリティグループを作成」をクリックします。
セキュリティグループ名に db-ユーザ名と入力します。（例：db-user1）
説明に「RDS for MySQL」と入力します。
ハンズオン用に作成した「VPC」を選択 （例: handson-user1）します。
インバウンドルールの「ルールの追加」をクリックします。
カスタムTCP を「MYSQL/Aurora」に変更します。
リソースタイプをプルダウンから「カスタム」に変更します。
ソース「web」と入力し、セキュリティグループの候補を表示させます。
EC2 インスタンス作成時に作成したセキュリティグループを選択します。（例：web-user1）
アウトバウンドルールやタグはデフォルトのまま、画面下の「セキュリティグループを作成」をクリックします。
セキュリティグループ作成後に以下の画面が表示されます。
以上で、RDS（DB）用のセキュリティグループの作成は終了です。
DB サブネットグループの作成
RDS 作成の事前準備として、DB サブネットグループを作成します。
DB サブネットグループ は、データベースを作成するサブネット群となります。 異なるアベイラビリティゾーンで最低2つのサブネットから構成されている必要があります。 EC2 インスタンスでは、作成時にサブネットを直接指定しましたが、RDS では、サブネットではなく、DB サブネットグループを作成時に指定する必要があります。 作成済みの2つのプライベートサブネット(1aと1c)を使って、DB サブネットグループを作成します。
検索ボックスで rds を入力し、表示された 「Aurora and RDS」 をクリックします。
左側のペインから 「サブネットグループ」 をクリックします。
「DB サブネットグループを作成」 をクリックします。
名前に db-subnet-ユーザ名と入力します。（例：db-subnet-user1）
説明に 「RDS for MySQL」 と入力します。
ハンズオン用に作成した VPC を選択します。（例：handson-user1）
アベイラビリティゾーンの選択で
「ap-northeast-1a」から 10.0.3.0/24のサブネットにチェックします。
「ap-northeast-1c」から 10.0.3.0/24のサブネットにチェックします。
作成 をクリックします。
下図のように db-subnet-ユーザ名 というサブネットグループが作成されたことを確認します。（例：db-subnet-user1）
以上で、DB サブネットグループの作成は終了です。次に、RDS DB インスタンスを作成していきます。
Amazon RDS の作成
WordPress が使用するデータベースとして Amazon RDS for MySQL インスタンスを プライベートサブネット-1a 上に シングル AZ 配置 で作成します。
Amazon RDS for MySQL DB インスタンスの作成します。
ここでは、シングル AZ 配置で作成します。
左ペインから 「データベース」 をクリックします。
「データベースの作成」 をクリックします。
「標準作成」 を選択します。
エンジンのタイプから 「MySQL」 を選択します。
エンジンバージョンは デフォルトで選択されているバージョン のままにします。
「RDS 延長サポートの有効化」はデフォルトのまま（チェックなし）にします。
テンプレートを 「無料利用枠」 にします。
その次の、「可用性と耐久性」 はデフォルトのままにします。
DB インスタンス識別子(DBインスタンスの名前)に 「rds-user1」 と入力します。
マスターユーザー名に 「admin」 と入力します。
認証情報管理で 「セルフマネージド」 を選択します。
マスターユーザー(admin) のパスワードを入力します。
※入力したパスワードを控えておきます
DB インスタンスサイズ / ストレージ の設定は、デフォルトのままとします。
コンピューティングリソースは、「EC2 コンピューティングリソースに接続しない」 を選択します。
ネットワークタイプは、「IPv4」を選択します。
VPC に 自分のVPC を選択します。 （例：handson-user1）
サブネットグループに、さきほど作成した自分のDBサブネットグループ db-subnet-user1 (db-subnet-ユーザ名)を選択します。
パブリックアクセスは 「なし」 にします。
VPC セキュリティグループは 「既存の選択」 を選択します。
既存のセキュリティグループのプルダウンから、さきほど作成した 「db-user1」 のセキュリティグループを選択します。
セキュリティグループに db-user1 と default の2つセキュリティグループが選択されている場合は、 defaultを削除します。
アベイラビリティーゾーンは 「ap-northeast-1a」 を選択します。
「RDS Proxy を作成」のチェックは外したまま(デフォルトのまま)にします。
認証機関 は、デフォルトのままにします。
追加の接続設定は デフォルトのまま(3306) にします。
タグ はデフォルトのままにします。
データベース認証は、デフォルトのまま(パスワード認証) にします。
モニタリングも、デフォルトのまま(拡張モニタリングのチェックが外れた状態)にします。
「追加設定」をクリックして展開します。最初のデータベース名に 「wordpress」 と入力します。（入力し忘れると、RDSの再作成が必要になるので、入力し忘れないように注意してください）
「自動バックアップを有効化にします」の チェックを外して 、自動バックアップを無効にします。
「暗号を有効化」の チェックを外して、暗号化を無効にします。
上記以外の項目は、デフォルトにままにします
「データベースの作成」 をクリックし、DB インスタンスを作成します
「推奨アドオン」というページが表示された場合は、「閉じる」を選択して、次の手順に進みます。
DB インスタンスの作成には 5分程度かかります。作成中は ステータスが 「作成中」となり、完了すると「利用可能」となります。
作成した DB インスタンスの詳細を確認するため、DB識別子の rds-user1 (rds-ユーザ名) をクリックします。
後で使用するのでDBの接続先である エンドポイント をメモします。アベイラビリティゾーンが ap-northeast-1a になっていることを確認、VPC が 自分の VPC になっていることを確認します。（例：handson-user）
以上で、データベース(RDS DB インスタンス) の作成は完了です。
ELB の作成
ロードバランサー（ELB：Elastic Load Balancing）を作成し、作成済みの EC2 インスタンス（WordPress）をロードバランサー配下に登録します。
ここでは L7 ロードバランサーである ALB (Application Load Balancer)を使用します。
ターゲットグループの作成
最初にELB ターゲットグループ（ロードバランサーに登録する EC2 インスタンスグループ）を作成します。
ターゲットグループは、AWSのロードバランサーにおいて、リクエストの振り分け先となるサーバー（EC2インスタンスなど）をまとめて管理する機能です。
検索ボックスでec2を入力し、表示されたEC2をクリックします。
左ペインから 「ターゲットグループ」 をクリックします。
「ターゲットグループの作成」をクリックします。
ターゲットタイプの選択 から 「インスタンス」 を選択します。
ターゲットグループ名 に target-ユーザ名（例：target-user1）と入力します。
プロトコルは「HTTP」、ポートは「80」にします。
IP アドレスタイプは 「IPv4」 を選択します。
VPC に 自分のVPC を選択します。 （例：hadson-user1）
プロトコルバージョンは、デフォルトのまま（HTTP1）にします。
WordPress が HTTP ステータスコード 200 を返すように、ヘルスチェックパスを変更します。
ヘルスチェックパス に 「/wp-includes/images/blank.gif」をコピー&ペーストで入力します。
ヘルスチェックプロトコル 、 ヘルスチェックの詳細設定、タグ はデフォルトのままにします。
「次へ」 をクリックします。
ターゲットグループに登録する EC2 インスタンスを指定します。
作成済みの EC2 インスタンスをチェック （例：webserver#1-user1 ）します。
「保留中として以下を含める」 をクリックします。
ターゲットに EC2 インスタンス（webserver#1-user1）が表示されていることを確認します。
「ターゲットグループの作成」をクリックします。
targer-ユーザ名（例：target-user1）という ターゲットグループが作成されていることを確認します。
以上で、ターゲットグループが作成されました。
ELB用セキュリティグループの作成
次に、ELB 用のセキュリティグループを作成します。
その後、EC2 インスタンス用のセキュリティグループを修正して、ELB から EC2 インスタンス（wordpress）にアクセスできるようにします。
自分のグローバルIPからのみ HTTP を許可するELB用のセキュリティグループを作成します。
左ペインから 「セキュリティグループ」 をクリックします。
「セキュリティグループを作成」をクリックします。
セキュリティグループ名、説明 共に elb-ユーザ名（例：elb-user1）と入力します。
「VPC」で 今回作成したハンズオン用 VPC を選択します。（例：handson-user1）
インバウンドルール で 「ルールを追加」をクリックします。
「タイプ」を 「カスタム TCP」 から 「HTTP」 に変更します。
「ソース」を カスタム から マイIP に変更して、「ソース」に 自分のグローバルIPが表示されていることを確認します。
それ以外はデフォルトのままにして、「セキュリティグループを作成」をクリックします。
これで、ELB 用のセキュリティグループが作成されました。
ルールは、自分のPublic IP アドレスからの HTTP アクセスを許可する設定になっています。
EC2インスタンス用セキュリティグループの修正
次に、WordPress 用のセキュリティグループ(web-user1)を修正して、ELB から EC2 インスタンスへ接続できるようにします。
左側ペインから セキュリティグループ をクリックします。
検索ボックスに web-ユーザ名（例：web-user1）と入力します。
表示されたセキュリティグループ（例：web-user1）をクリックします。
ELB から EC2 インスタンスへ接続できるように、セキュリティグループの設定を変更します。
画面中部あたりの 「インバウンドルール」タブ をクリックします。
「インバウンドのルールを編集」 をクリックします。
「ルールの追加」 をクリックします。
「タイプ」を カスタム TCP から HTTP に変更します。
「ソース」を カスタム に変更します。
その横の検索ボックスから ELB 用セキュリティグループ elb-ユーザ名（例：elb-user1）を選択します。
「ルールを保存」 をクリックします。
WordPress用のセキュリティグループ（web-user1）へELB から EC2 インスタンスへ接続できるように設定が追加されました。
以上でセキュリティグループの設定と修正は完了です。
ELB の作成
ロードバランサー(ELB)を作成し、作成済みの EC2 インスタンス(WordPress) をロードバランサー配下に登録します。
ELBを既に開いている EC2 管理ページから作成します。
左ペインから 「ロードバランサー」をクリックします。
「ロードバランサーの作成」をクリックします。
Application Load Balancer を選択し作成 をクリックします。
ロードバランサー名に elb-ユーザ名を入力します。（例：elb-user1）
スキーム、IPアドレスタイプはデフォルト値のままにします。
ロードバランサーを、既に作成済みの 2つのパブリックサブネット(1aと1c) に配置します。
VPCに 自分の VPC を選択します。
IPプールは、デフォルトのまま（チェック無し）にします。
ap-northeast-1a のチェックを入れて パブリックサブネット-1a を選択します。
ap-northeast-1c のチェックを入れて パブリックサブネット-1c を選択します。
ロードバランサーのセキュリティグループを設定します。ここでは、前回の手順で作成した elb-user1 を使用します。
セキュリティグループ から 作成した ELB 用セキュリティグループ elb-user1 を選択します。
default という名前のセキュリティグループが選択されている場合は、×印をクリックして選択を解除して、elb-user1のみが選択されているように変更します。
リスナー（ELBの待ち受けプロトコルとポート）とターゲットグループの設定を行います
プロトコル、ポートはデフォルトのままにします。
デフォルトアクション へ事前に作成したターゲットグループ（例：target-user1） を選択します。
リスナータグやロードバランサータグもデフォルトのまま(何も変更しない）にします。
サービスの統合で最適化は、デフォルトのまま（チェックはしない）にします。
設定の確認を行い、「ロードバランサーの作成」をクリックします。
画面上部にロードバランサーが正常に作成されましたと表示されればOKです。
ELB の DNS 名をコピーして、忘れないようにメモ帳に保存します。
ELB 配下に EC2 インスタンスが正常に登録されているか確認します。
「リスナーとルール」タブを選択します。
デフォルトアクションの target-user1 (target-ユーザ名)をクリックして、ターゲットグループの詳細ページに遷移します。
ヘルスチェックに成功している、つまり、ロードバランサーを通じて EC2 インスタンスにアクセスできる状態になっていることを確認します。
「ターゲット」タブを選択します。
ヘルスステータスが 「healthy」 になっていることを確認します。
これで、作成した ELB が正常に機能していることが確認できました。
WordPress の初期設定
作成したELB(ロードバランサー) 経由で EC2 インスタンスへアクセスして、WordPress の初期設定を行います。
新しくブラウザ、もしくはタブを立ち上げます。
ELB 作成時にメモした ELB の DNS 名 を立ち上げたブラウザに入力して、ELB 経由で WordPress にアクセスします。
httpsではなく、httpでアクセスします。私の場合は、以下のようになります。
http://elb-user1-1705250014.ap-northeast-1.elb.amazonaws.com
「サイトは安全ではありません」が表示された場合は、「サイトへ移動」をクリックします。
WordPress の初期設定画面が表示されました。「さあ、始めましょう」 をクリックして設定していきます。
WordPressのDB設定
作成済みの RDS データベースの情報を入力して、WordPress を設定していきます。
データベース名に wordpress (全て小文字)と入力します。（※デフォルトでは入力されていないので必ず自身で入力してください）
ユーザ名に 「admin」と入力します。
作成した RDS の admin パスワードを入力します。（※RDS 作成時にメモしたパスワードを使用）
データベースのホスト名に RDS エンドポイントを入力します。（※RDS 作成時にメモしたエンドポイントを使用）
テーブル接頭辞はデフォルト(wp_)のままとします。
送信をクリックします。
入力した情報が正しければインスタンス実行画面に遷移しますので「インストール実行」をクリックします。
任意のブログのタイトルを入力します。
管理者ユーザ名を入力します。
ブログの管理者パスワードを設定します。
自身のメールアドレスを入力します。
検索エンジンでの表示に チェックをつけます。
WordPress をインストールをクリックします。
成功しましたと表示されるので、ログインをクリックします。
ブログの管理者ユーザ名を入力します。
ブログの管理者パスワードを入力します。
ログインをクリックします。
WordPress の管理者画面が表示されます。
WordPress 管理画面からブログ名「AWS検証」をクリック、「サイトを表示」をクリックし、ブログが表示されることを確認します。
EC2 インスタンスのアクセスログを確認
EC2 インスタンス一覧ページにアクセスします。
アクセスしたいインスタンスを選択します。（例：webserver#1-user1）
接続 をクリックします。
「セッションマネージャー」 タブをクリックします。
「接続」 をクリックします。
以下のコマンドを、EC2 インスタンス上で実行します。
Apache（httpd）のアクセスログを確認することができます。
ELB の定期的なヘルスチェックが実行されたり、WordPress でページをリロードするたびに EC2 インスタンスへのアクセスが発生していることを確認できます。
sudo tail -f /var/log/httpd/access_log
右上の「終了」をクリックするかブラウザのタブを閉じることでセッションは終了します。
AMI の作成
作成した EC2 インスタンスから Amazon Machine Image (AMI) を取得し、 EC2 インスタンスを複製する準備を行います。
今回は、作成済みの webserver#1-ユーザ名 (例： webserver#1-user1) を元に AMI を作成します。
この AMI には WordPress や RDS への接続情報が含まれており、この AMI をもとに 2 つ目の EC2 インスタンスを作成します。
AMI（イメージ）の作成
検索ボックスでec2を入力し、表示されたEC2をクリックします。
左ペインから 「インスタンス」 をクリックします。
websever#1-ユーザ名の EC2 インスタンスを見つけて、チェックを入れます。（例：webserver#1-user1）
右上の アクション > イメージとテンプレート > イメージを作成 をクリックします。
イメージ名に wordpress-ユーザ名 と入力します。（例：wordpress-user1）
新規タグを追加をクリックして「キー」に Name、「値」にwordpress-ユーザ名と入力します。（例：wordpress-user1）
その他の項目はデフォルトのまま イメージを作成をクリックします。
AMI 作成時に EC2 インスタンスの再起動が発生します。
上図の「再起動しない」の「有効化」にチェックを入れることで、再起動せずに AMI を取得することも可能です。
左ペインから AMI をクリックし、AMI 一覧を表示します。
作成した AMI 名（例： wordpress-user1）のステータス が 「保留中」 になっていること確認します。
AMI の作成が完了する（下図のように ステータスが 利用可能 になる) まで、数分待ちます。
2つ目の EC2 インスタンスの作成
さきほど作成した AMI を利用して、2 つ目の EC2 インスタンスを作成します。
WordPress のインストールや設定は既に完了済みの AMI を利用しているため、WordPress などのインストール作業は不要です。
AMI から EC2 インスタンスを作成
検索ボックスでec2を入力し、表示されたEC2をクリックします。
左ペインから 「AMI」 をクリックします。
作成した AMI のチェックボックスにチェックをいれます。（例：wordpress-user1）
「AMI からインスタンスを起動」をクリックします。
名前に webserver#2-ユーザ名（例：webserver#2-user1）と入力します。2つ目の EC2 インスタンスのため webserver#2 としています。
アプリケーションおよび OS イメージ (Amazon マシンイメージ)とインスタンスタイプは、どちらもデフォルトのままにします。
「カタログからの AMI」タブの「名前」に「wordpress-user1」が設定されていることを確認します。
インスタンスタイプは、「t2.micro」 が選択されていることを確認します。
SSHキーペア(SSHでのログイン)は使用しないので、「キーペア名」に キーペアなしで続行 を選択します。
2つ目の EC2 インスタンスは、パブリックサブネット-1c 上に作成するため、その設定を行っていきます。
「ネットワーク設定」の右にある 編集 をクリックします。
「VPC」で 今回作成したハンズオン用 VPC を選択します。（例：handson-user1）
「サブネット」で パブリックサブネット-1c を選択します。
「パブリック IP の自動割り当て」で 有効化 を選択します。
「ファイアーウォール(セキュリティグループ)」で 既存のセキュリティグループを選択する を選択します。
「共通のセキュリティグループ」から web-user1 を選択します。
他の設定は、全てデフォルトのままにします。
「概要」から インスタンスを起動 をクリックして、インスタンスを起動します。
作成した EC2 インスタンスの詳細を確認していきます。すべてのインスタンスを表示をクリックし、作成したインスタンスの詳細を確認します。
インスタンス作成完了には数分かかります。
表示されない場合は、更新アイコンをクリックします。
「初期化しています」となっていたら、しばらく待ちます。
作成したインスタンスが表示(図の場合 webserver#2-user1)されるので、チェックボックスにチェックを入れます。
画面下の「詳細」タブをクリックし、設定通りになっていることを確認します。
・パブリック IPv4 アドレスが割り当てられている
・インスタンスタイプが t2.micro になっている
・VPC ID が、今回作成した VPC になっている
・サブネット IDが、パブリックサブネット-1c になっている
AMI を利用して、2 つ目の EC2 インスタンスを作成しました。
2つ目の EC 2インスタンスを ELB に登録
作成した 2 つ目の EC2 インスタンスを ELB に登録することで
ELB には 2つの EC2 インスタンスが登録されているため、Webレイヤー(EC2 インスタンス) は負荷分散かつ冗長構成になります。
ターゲットグループの選択
検索ボックスでec2を入力し、表示されたEC2をクリックします。
左ペインからターゲットグループを選択します。
作成したターゲットグループ target-ユーザ名（例：target-user1）をクリックして、ターゲットグループの詳細ページに遷移します。
「ターゲットタブ」をクリックすると、1 つ目の EC2 インスタンス webserver#1-user1 が登録されていることが確認できます。
「ターゲットの登録」をクリックし、2 つ目の EC2 インスタンスを登録します。
作成した 2つ目の EC2 インスタンスをチェックします。（例：webserver#2-user1）
「保留中として以下を含める」をクリックします。
ターゲットに 2 つ目の EC2 インスタンス（webserver#2-user1）が表示されていることを確認します。
確認できたら、保留中のターゲットの登録をクリックします。
「保留中のターゲットのみ登録しますか？」が表示された場合は、「次へ」をクリックします。
追加した EC2 インスタンスのヘルスステータスが initial から healthy に変わるまで待ちます。
healthy に変わると、2 つ目の EC2 インスタンスが ELB に正常に登録されています。
2 つ目の EC2 インスタンスが ELB に登録され、負荷分散かつ冗長構成になりました。
RDS インスタンスのマルチ AZ 配置化
RDS インスタンスをシングル AZ から マルチ AZ 配置に変更し、DB レイヤーについても、可用性を高める構成にします。
画面上部の検索ボックスに rds と入力し、表示された Aurora and RDS をクリックして、Aurora and RDS の管理ページに移動します。 左ペインの 「データベース」 をクリック、rds-user1 の左側にチェックを入れます。 画面右上の アクション > マルチ AZ 配置への変換 を順にクリックします。
どのタイミングでマルチ AZ 配置への変更を行うかについて、「すぐに適用」 を選択し、マルチ AZ に変換 をクリックします。
画面上部に DB インスタンスをマルチ AZ DB インスタンスデプロイに変更する と表示され、ステータスが 「変更中」 になっていることを確認します。
「変更中」 にならない場合は、リロードボタンを押して、何度かステータスの更新を行ってください。
ステータスが 「利用可能」 になれば、マルチ AZ 配置が完了しています。
画面のように、表示された項目を右にスクロールすると、マルチAZ : あり になっていることを確認できます。
以上で、DB インスタンスのマルチ AZ 配置 への変更は完了です。
ここまでで構築、設定はすべて完了となります。
次に、EC2 インスタンス(Web レイヤー) と RDS インスタンス (DB レイヤー) の可用性について、それぞれ確認していきます。
EC2 インスタンスを1つ停止させ、全体の可用性の確認
意図的に EC2 インスタンスを1つ停止させ、その状態でも、WordPress のブログが問題なく見れることを確認します。
負荷分散されているかログを確認
EC2 インスタンスを1つ停止させる前にELB配下で負荷分散されているか確認しておきます。
2台のEC2インスタンスへログインし、以下コマンドを実行後、Wordpressサイトを何度か表示させてみます。
赤枠のログのとおり、アクセスログが出力されて負荷分散されていることが確認できます。
sudo tail -f /var/log/httpd/access_log
EC2インスタンスの停止
検索ボックスでec2を入力し、表示されたEC2をクリックします。
左側のペインから インスタンス をクリックします。
webserver#1-ユーザ名 インスタンスをチェックします。（例：webserver#1-user1）
画面右上の インスタンスの状態 > インスタンスを停止をクリックします。
「停止インスタンス」ウィンドウが表示された場合は、「停止」をクリックします。
webserver#1-user1が停止しました。
ELBから見たEC2インスタンスの状態を確認
左ペインから ターゲットグループ を選択します。
作成したターゲットグループをクリックし (例: target-user1)、詳細ページへ遷移します。
ターゲット タブをクリックします。
停止したインスタンスが unused になっていること、つまり、ELB から外れていることを確認します。
ブログの確認
ELB の DNS名 を別ブラウザ or 別タブに入力します。
EC2 インスタンスが 1 つ停止した状態でも、ブログが問題なく表示されることを確認します。
また、EC2インスタンスのアクセスログにもログが出力されることを確認します。
これで、EC2 インスタンスが 1 つ停止した状態でも、ブログが問題なく表示されることが確認できました。
停止したEC2インスタンスを起動する
左ペインから インスタンスをクリックします。
停止している webserver#1-ユーザ名 インスタンスをチェックします。（例：webserver#1-user1）
画面右上の インスタンスの状態 > インスタンスを開始をクリックします。
インスタンスの状態が 停止済み から 実行中 に変わりました。
ELBから見たEC2インスタンスの状態を確認
左ペインから ターゲットグループ を選択します。
作成したターゲットグループをクリックし (例: target-user1)、詳細ページへ遷移します。
ターゲット タブをクリックします。
開始したインスタンスが healthy になっていること、つまり、ELB へ組み込まれたことを確認します。
RDS インスタンスのフェイルオーバーを行い、全体の可用性を確認
RDS インスタンスのフェイルオーバーを手動で行います。 フェイルオーバーの動作の確認、そして、フェイルオーバー後も WordPress ブログが問題なく見れることを確認します。
フェイルオーバーの実行
検索ボックスで rds と入力し、表示される Aurora and RDS をクリックします。
左側のペインから データベース をクリックします。
自分のインスタンス(例: rds-user1) の左側にチェックします。
アクション > 再起動 をクリックします。
フェイルオーバーで再起動しますか にチェックを入れて、「確認」をクリックします。
フェイルオーバーのチェックが入っていないと、フェイルオーバーしないまま再起動（DBの停止）が発生するため、ご注意ください。
ステータスが 再起動中 (フェイルオーバー中) になっていることを確認します。（利用可能 になればフェイルオーバー完了です）
フェイルオーバー中は、RDS に接続できないため、ブログにアクセスしても応答がありませんでした。
フェイルオーバー後にブログに再度アクセスして、ブログが問題なく見れることを確認します。
RDS DBインスタンスの詳細を確認
DB インスタンスの詳細を確認するため、DB識別子の rds-user1 (rds-ユーザ名) をクリックします。
ログとイベント タブをクリックします。
最近のイベント から フェイルオーバーのイベント が実際に発生したことを確認します。
例えば Multi-AZ instance failover completed がフェイルオーバーが完了したイベントログです。
しばらくすると「リージョンとAZ」 もフェイルオーバー先の ap-northeast-1c と表示が変更されます。
RDS インスタンスのフェイルオーバーを手動で行い、フェイルオーバー後も、ブログが問題なく見れることを確認しました。
リソースの削除
AWSのハンズオンで作成したリソースを削除していきます。
RDS インスタンスを削除
検索ボックスで rds を入力し、表示された RDS をクリックします。
左ペインのデータベース をクリックします。
今回作成した DB インスタンスを選択します。（例：rds-user1）
アクション > 削除 をクリックします。
「最終スナップショットを作成」のチェックをはずします。
「私は、インスタンスの削除後・・・了承します」のチェックを入れます。
「delete me」 と入力します。
「削除」 をクリックします。
削除が終わるまで、数分かかります。
RDS インスタンスが削除されたことを確認します。
DB サブネットグループの削除
左ペインからサブネットグループをクリックします。
今回作成した DB サブネットグループを選択します。（例：db-subnet-user1）
削除 をクリックします。
削除した DB サブネットグループが一覧から消えていることを確認します。
RDS スナップショットが存在しないことを確認
左ペインからスナップショットをクリックします。
手動のタブ をクリックし、本ハンズオンでスナップショットが手動で作成されていないことを念のため、確認します。
システムのタブをクリックし、本ハンズオンでスナップショットが自動で作成されていないことを念のため、確認します。
以上で、RDS インスタンスの削除は完了です。
EC2 インスタンスの削除
検索ボックスでec2を入力し、表示されたEC2をクリックします。
左ペインからインスタンス をクリックします。
今回作成した全ての EC2 インスタンスを選択します。（例：webserver#1-user1 と webserver#2-user2）
インスタンスの状態 > インスタンスを終了（削除）をクリックします。
終了（削除）をクリックします。
インスタンスの状態 が 終了済み になれば削除完了です。
AMI の登録解除
検索ボックスでec2を入力し、表示されたEC2をクリックします。
左ペインからAMI をクリックします。
今回作成した AMI を選択します。（例：wordpress-user1）
アクション > AMI を登録解除 をクリックします。
確認画面で「関連付けられたスナップショットの削除」にチェックを入れて、「AMI を登録解除」をクリックします。
削除した AMI が一覧から消えていることを確認します。
EBS スナップショットの削除
AMI を取得すると、EBS スナップショットも自動取得されるため、ここでは EBS スナップショットの削除を行います。
おそらくAMIを削除する際、「関連付けられたスナップショット」にチェックを入れれば削除されると思われます。
検索ボックスでec2を入力し、表示されたEC2をクリックします。
左ペインからスナップショットをクリックします。
スナップショットが存在しないことを確認します。
ELB の削除
ELB の削除
検索ボックスでec2を入力し、表示されたEC2をクリックします。
左ペインからロードバランサーをクリックします。
今回作成した ELB を選択します。（例：elb-user1）
アクション > ロードバランサーの削除 をクリックします。
確認 と入力し、削除をクリックします。
削除した ELB が一覧から消えていることを確認します。
ターゲットグループの削除
検索ボックスでec2を入力し、表示されたEC2をクリックします。
左ペインからターゲットグループをクリックします。
今回作成したターゲットグループを選択します。（例：target-user1）
アクション > 削除 をクリックします。
「削除」をクリックします。
削除したターゲットグループが一覧から消えていることを確認します。
VPC の削除
以下の VPC リソースは、料金は発生しないそうです。
そのため、そのまま残しておくことも可能です。
削除する場合は、以下を参照してください。
検索ボックスでvpcを入力し、表示されたVPCをクリックします。
お使いのVPC をクリックします。
自分の VPC を選択します。（例：handson-user1）
アクション > VPC の削除 をクリックします。
削除 と入力します。
削除 をクリックします。
削除完了後に、自分の VPC が一覧から消えていることを確認します。
※インターネットゲートウェイ、サブネット、セキュリティグループなども同時に削除されます。
まとめ
だいぶ長くなりましたがAWSのハンズオンを参照しながら検証することができました。EC2、VPC以外は机上の勉強だけでしたのでとても勉強になりました。まだまだ設定値の意味が理解できてない箇所もありますが、引き続き勉強を続けたいと思います。
ハンズオンには他にAuto Scaling、WAFの検証もありましたのでそちらも検証してみました。また検証結果もブログにしたいと思います。
以下、他の記事をまとめた一覧です。AWSもまとめています。
