AWS Well-Architected Framework 入門：信頼性の柱を Amazon RDS のマルチ AZ 配置 + Auto Scaling + ALB でハンズオンを作成・実践してみた

はじめに

こんにちは。クラスメソッドオペレーションズの藤瀨です。

Well-Architected Framework ハンズオンシリーズの第 4 回です。

• 第 1 回 Well-Architected Framework の概要
• 第 2 回 オペレーショナルエクセレンスの柱
• 第 3 回 セキュリティの柱

今回は「信頼性（Reliability）」の柱に基づいて筆者が作成したハンズオンを実践していきます。

この柱が目指すのは、障害から復旧し、期待通りに機能し続けるシステムを作ることです。単一障害点（SPOF）を減らし、障害が発生しても自動的に復旧できるように設計することが、信頼性を高める重要な考え方の 1 つです。

このブログでは以下の 4 点を体験します。

• シングル AZ の RDS をマルチ AZ に変更してフェイルオーバーを起こす
• Auto Scaling + ALB で冗長化した Web サーバー構成を作る
• EC2 インスタンスを終了して Auto Scaling による自動補充を確認する
• RDS の「ログとイベント」タブでフェイルオーバーの記録を確認する

信頼性とは

改めてこの柱の中身を整理しておきます。公式ドキュメントでは、信頼性は「ワークロードが意図した機能を正確かつ一貫して実行し続ける能力」と定義されています。ライフサイクル全体を通じて運用・テストする能力も含まれます。

この柱には 5 つの設計原則があります。

• 障害から自動的に復旧する: KPI を監視し、しきい値を超えたら自動で復旧処理を開始する
• 復旧手順をテストする: 障害を意図的に起こし、復旧手順を検証しておく
• 水平方向にスケールしてワークロード全体の可用性を高める: 1 つの大きなリソースではなく、複数の小さなリソースに分散する
• キャパシティを勘に頼らない: 需要と使用率を監視し、リソースの増減を自動化する
• 自動化を通じて変更を管理する: インフラへの変更は自動化し、変更自体も追跡・レビューできるようにする
  今回のハンズオンでは、この中でも「障害から自動的に復旧する」（Amazon RDS のマルチ AZ DB インスタンス配置によるフェイルオーバー）、「水平方向にスケールしてワークロード全体の可用性を高める」（Auto Scaling + ALB による複数インスタンスへの分散）、「復旧手順をテストする」（フェイルオーバーやインスタンス障害の意図的な発生）という 3 つの観点を中心に体感していきます。

具体的な手順

大まかな手順は以下の通りです。

1. シングル AZ で Amazon RDS DB インスタンスを作成する
2. マルチ AZ 配置に変換してフェイルオーバーを体験する
3. Auto Scaling + ALB で冗長化した Web サーバー構成を作る
4. EC2 インスタンスを終了して Auto Scaling による自動補充を確認する

なお、RDS のフェイルオーバー検証と、Auto Scaling によるインスタンスの自動補充と ALB による正常なインスタンスへのルーティングの検証は、それぞれ独立したハンズオンです。本記事では、Web サーバーから RDS への接続は行いません。

前提条件

このハンズオンを行う前に、以下を確認しておくことをおすすめします。

• 検証用に用意した AWS アカウントで実施し、本番環境では行わないこと
• 本記事の内容および画面表示は、公開直前に実際に確認した時点の AWS マネジメントコンソールの情報に基づくこと（コンソールの UI やテンプレート名は更新される場合があります）
• Amazon RDS をマルチ AZ 配置へ変換する手順②には Paid account plan が必要であること
• Paid account plan へ変更した後は、クレジット残高を超えた利用料金が請求される可能性があること
• 無料利用枠クレジットの残高や有効期限はアカウントの作成時期・条件によって異なるため、コンソール上で事前に確認しておくこと
• ALB、EC2、RDS のストレージ、パブリック IPv4 アドレスなどについて、条件によっては料金が発生する可能性があること
• デフォルト VPC と、2 つ以上の AZ にまたがるサブネットが利用できる環境であること

① シングル AZ で Amazon RDS DB インスタンスを作成する

1. AWS マネジメントコンソール上部の検索ボックスで RDS を検索してクリックします。
2. 左側のナビゲーションペインで「データベース」を選び、「データベースの作成」をクリックします。
3. 「データベースの作成方法」で「フル設定」を選びます。
4. 「エンジンのオプション」でエンジンタイプ（今回は MySQL）とバージョンを選びます。
5. その下の「テンプレート」を選びます。表示されるテンプレートの種類や名称は、アカウントプラン（Free account plan / Paid account plan）やコンソールの更新によって異なる場合があります。Free account plan の場合は「無料利用枠」を選択します。「無料利用枠」を選ぶとデプロイオプション（可用性と耐久性）が「単一の DB インスタンス」に固定され、変更できなくなります。Paid account plan で同じ構成を作る場合は、「開発/テスト」など無料利用枠以外のテンプレートを選び、「可用性と耐久性」欄で「単一の DB インスタンス」を自分で指定してください。
6. 「設定」で DB インスタンス識別子（例: waf-rel-handson-db）を入力します。マスターユーザー名は、MySQL エンジンの場合、デフォルトで admin が入力されています。このハンズオンでは、そのまま使用して問題ありません。任意の名前に変更する場合は、1〜16 文字の英数字またはアンダースコアを使用し、先頭を英字にする必要があります。また、データベースエンジンの予約語は使用できません。
   「認証情報の管理」は「自己管理」を選び、「自動生成」チェックボックスはオフのままにして、「マスターパスワード」欄と「パスワードを確認」欄に、任意のパスワード（8〜41 文字、/・'・"・@・スペースは使用不可）を自分で入力します。

7. 「インスタンスの設定」の DB インスタンスクラスで、コンソール上に「無料利用枠対象」と表示されるインスタンスクラス（db.t3.micro や db.t4g.micro など）を選択します。「ストレージ」には、ハンズオンに必要な最小限の容量として、汎用 SSD 20 GiB 程度を指定します。ストレージの利用量も AWS Free Tier クレジットの消費対象になるため、不要に大きな容量を指定しないようにしてください。
8. 画面下部の「追加設定」を展開し、「最初のデータベース名」に wafreliabilitydb など、後で見て分かる名前を入力します（空欄のままでも作成できますが、指定しておくと接続確認のときにわかりやすくなります）。
9. ここまでで触れていない設定項目は、「無料利用枠」テンプレートのデフォルト値のまま進めて問題ありません。画面下部の［データベースを作成］をクリックします。無料枠の対象になっているかどうかは、コンソール上で「無料利用枠対象」と表示されていることを確認してください。

② マルチ AZ 配置に変換してフェイルオーバーを体験する

1. Paid account plan へ変更したことを確認します。その後、作成した DB インスタンスを選択し、「アクション」→「マルチ AZ 配置への変換」を選択します。確認画面では、このハンズオンではすぐに変換するため「すぐに適用」を選択し、変換を実行します。変換にはプライマリのスナップショット取得やスタンバイ用ボリュームの作成などが伴うため、完了まで時間がかかる場合があります。所要時間はデータ量や環境によって異なるため、具体的な時間を見込まず、DB インスタンスのステータスが「利用可能」に戻ったことを確認してから次に進みます。

2. DB インスタンスの詳細画面を開き、マルチ AZ 配置が「はい」に変わっていることを確認します。
3. 同じ詳細画面で「アクション」→「再起動」をクリックし、表示されるダイアログで「フェイルオーバーで再起動」にチェックを入れてから実行します。
   フェイルオーバーを伴う再起動では、DB インスタンスが一時的に利用できなくなります。フェイルオーバー後も接続先として使用する DB エンドポイントは変わりませんが、DNS レコードの参照先が新しいプライマリ DB インスタンスへ切り替わるため、既存のデータベース接続は再確立する必要があります。
   フェイルオーバーの所要時間は通常 60〜120 秒程度ですが、大規模なトランザクションやリカバリ処理がある場合は、さらに時間がかかる可能性があります。
4. 実行後、DB インスタンスのステータスが「rebooting」に変わり、その後「available」に戻ることを確認します。
5. DB インスタンスの詳細画面で「ログとイベント」タブを開きます。
6. 「最近のイベント」の一覧を確認します。Multi-AZ instance failover started.、Multi-AZ instance failover completed. といった英語のイベントメッセージが、実行時刻とともに時系列で記録されています。
   

③ Auto Scaling + ALB で冗長化した Web サーバー構成を作る

1. 検索ボックスで EC2 を検索してクリックし、左側のナビゲーションペインから「セキュリティグループ」を選び、［セキュリティグループを作成］をクリックします。まず ALB 用のセキュリティグループ（例: waf-rel-handson-alb-sg）を作成します。インバウンドルールのタイプを「HTTP」、ソースは「任意の場所（IPv4）」（0.0.0.0/0）にします。ALB は外部からの通信を直接受け付ける唯一の入り口になるため、ここでインターネットからの HTTP 通信を許可します。
2. 続けてもう 1 つセキュリティグループを作成します。EC2 インスタンス用のセキュリティグループ（例: waf-rel-handson-sg）を作成し、インバウンドルールのタイプを「HTTP」、ソースは「カスタム」を選んで、手順 1 で作成した ALB 用セキュリティグループを指定します。ALB の実体がまだ存在しない段階でも、セキュリティグループ自体は別のセキュリティグループのソースとして指定できます。これにより、EC2 インスタンスへの HTTP アクセスは ALB 経由のみに制限され、インターネットから EC2 インスタンスへ直接到達できなくなります。ALB 用と EC2 用でセキュリティグループを分けて管理するのが基本的な構成です。
3. 左側のナビゲーションペインから「起動テンプレート」を選び、［起動テンプレートを作成］をクリックします。テンプレート名（例: waf-rel-handson-lt）を入力し、「アプリケーションおよび OS イメージ（Amazon マシンイメージ）」から「クイックスタート」タブを選択し、Amazon Linux 2023 を選びます。「インスタンスタイプ」では、コンソール上で「無料利用枠対象」と表示されるインスタンスタイプ（本記事では t3.micro）を選択します。
4. 「キーペア（ログイン）」は、SSH でインスタンスにログインする場合のみ指定します。今回はブラウザからの疎通確認が中心なので、キーペアなしでも進められます。
5. 起動テンプレートの「ネットワーク設定」ではサブネットを指定せず「サブネットの設定なし」のままで進めます（VPC を直接指定する項目がなく、実際の VPC・サブネットは後の Auto Scaling グループ側で指定するため）。セキュリティグループは、手順 2 で作成した EC2 用のものを選択します。
   また、この後のユーザーデータスクリプトが yum install でパッケージを取得するため、起動した EC2 インスタンスにはインターネットへのアウトバウンド通信が必要です。本記事では、インターネットゲートウェイへのデフォルトルートが設定され、パブリック IPv4 アドレスの自動割り当てが有効になっているデフォルト VPC のパブリックサブネットを使用します。プライベートサブネットを使う場合は、NAT Gateway などのアウトバウンド経路を別途用意してください（NAT Gateway には時間料金とデータ処理料金がかかります）。
6. 画面下部の「高度な詳細」を展開し、「ユーザーデータ」欄に以下のスクリプトを貼り付けます。インスタンス起動時に Apache（httpd）をインストールし、自分自身のホスト名を表示するだけの簡易な Web ページを作成する内容です。

#!/bin/bash
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "Hello from $(hostname -f)" > /var/www/html/index.html

7. ［起動テンプレートを作成］をクリックします。

8. 左側のナビゲーションペインから「ロードバランシング」→「ターゲットグループ」を選び、［ターゲットグループを作成］をクリックします。ターゲットグループ名（例: waf-rel-handson-tg）を入力し、ターゲットの種類は「インスタンス」、プロトコルは「HTTP」、ポートは「80」、VPC は手順 2 で EC2 用セキュリティグループを作成した VPC と同じものを指定します。この時点ではターゲット（EC2 インスタンス）を登録する必要はありません。後で Auto Scaling グループの設定から自動的に登録されます。

9. 左側のナビゲーションペインから「ロードバランサー」を選び、［ロードバランサーを作成］→「Application Load Balancer」を選びます。ロードバランサー名（例: waf-rel-handson-alb）を入力し、スキームは「インターネット向け」を選び、「アベイラビリティーゾーンとサブネット」で異なる 2 つ以上の AZ のサブネットを選択します（ALB 自体も複数 AZ にまたがらせるためです）。「セキュリティグループ」では、手順 1 で作成した ALB 用セキュリティグループを選択します。
   

10. 「リスナーとルーティング」で、プロトコル「HTTP」・ポート「80」のリスナーに、手順 8 で作成したターゲットグループを紐づけ、［ロードバランサーを作成］をクリックします。
    

11. 左側のナビゲーションペインから「Auto Scaling グループ」を選び、［Auto Scaling グループを作成］をクリックします。Auto Scaling グループ名（例: waf-rel-handson-asg）を入力し、「起動テンプレート」で手順 3〜7 で作成したテンプレートを選択します。

12. 「ネットワーク」で ALB と同じ VPC を選び、「サブネット」で異なる複数の AZ を選択します（Auto Scaling グループ側も複数 AZ にまたがらせるためです）。
    

13. 「ロードバランシング」の設定で「既存のロードバランサーにアタッチする」を選び、手順 8 で作成したターゲットグループを選択します。あわせて「Elastic Load Balancing のヘルスチェックを有効にする」にもチェックを入れます。これにより、EC2 のステータスチェックだけでなく ALB のヘルスチェックで unhealthy と判定されたインスタンスも、Auto Scaling グループの入れ替え対象になります。
    

14. 「グループサイズ」で、希望する容量・最小のキャパシティ・最大のキャパシティをすべて「2」に設定します。今回はスケーリングポリシーを追加せず、希望する容量として 2 台を維持するように Auto Scaling グループを構成します。

15. 設定内容を確認し、［Auto Scaling グループを作成］をクリックします。

16. 数分待つと、Auto Scaling グループの設定に従って EC2 インスタンスが 2 台起動します。手順 8 で作成したターゲットグループの「ターゲット」タブを開き、この 2 台が「healthy」ステータスとして登録されていることを確認します。あわせて、EC2 の「インスタンス」画面で「アベイラビリティーゾーン」列を確認します。Amazon EC2 Auto Scaling は、選択した AZ 間でインスタンス数が均等になるように配置を試みるため、この構成では通常、2 台が異なる AZ に配置されます。
    

17. ALB の詳細画面で DNS 名（例: xxxx.ap-northeast-1.elb.amazonaws.com のような形式）をコピーし、ブラウザでアクセスします。このハンズオンでは ALB に HTTP（80 番ポート）のリスナーしか作成していないため、アクセス先が https:// になっていると接続できません。ブラウザが自動的に https:// へ補完してしまう場合があるため、アドレスバーが http:// になっているかを確認してください。
    ページを何度か再読み込みすると、Hello from ip-xxx-xxx-xxx-xxx... のように 2 台それぞれのホスト名が表示されます。ただし ALB のデフォルトのルーティングアルゴリズムはラウンドロビンですが、必ず 1 回ごとに交互で表示されるとは限りません。スティッキーセッションが有効な場合や、ヘルスチェックの状態によっては表示が偏ることがあります。

④ EC2 インスタンスを終了して Auto Scaling による自動補充を確認する

この手順では、EC2 インスタンスを手動で終了した際に、Amazon EC2 Auto Scaling が希望する容量を維持するため、代替インスタンスを起動する動作を確認します。

1. 検索ボックスで EC2 を検索してクリックし、左側のナビゲーションペインから「インスタンス」を選びます。Auto Scaling で起動している 2 台のインスタンスのうち、どちらか 1 台にチェックを入れます。

2. 画面右上の［インスタンスの状態］→「インスタンスを終了」を選び、確認ダイアログで［終了］をクリックします。

3. 終了を実行したらすぐに、別のブラウザタブで ALB の DNS 名を開き、ページのリロードを繰り返しておきます。残っているもう 1 台のインスタンスがリクエストを引き続き処理するため、これ以降の手順を進めている間もサイトへのアクセスが継続しやすいことを確認できます（ネットワークやヘルスチェックのタイミングによっては、一時的にアクセスできない瞬間が発生する可能性もあります）。終了したインスタンスが ALB の転送対象から外れてから代替インスタンスが healthy になるまでは、基本的に残っている 1 台のホスト名が表示されます。ただし、ターゲットの登録解除や代替インスタンスの起動タイミング、既存接続やブラウザキャッシュなどの影響により、表示結果が異なる場合があります。

4. 終了したインスタンスのステータスが「shutting-down」から「terminated」に変わることを確認します。

5. 左側のナビゲーションペインから「Auto Scaling グループ」を選び、手順③で作成した Auto Scaling グループを開きます。「アクティビティ」タブで、終了したインスタンスの検出と、代替インスタンスの起動が記録されていることを確認します。これは、Auto Scaling グループが希望する容量「2」を維持するために、代替インスタンスを自動的に起動したことを示しています。
   

6. 「インスタンスの管理」タブを開き、新しく起動されたインスタンスのライフサイクルの状態が「Pending」から「InService」に変わるまで待ちます。数分ほどかかります。

7. ③の手順 8 で作成したターゲットグループの「ターゲット」タブを開き、新しいインスタンスが登録され「healthy」ステータスになっていることを確認します。

8. 手順 3 で開いたブラウザタブでページを複数回再読み込みすると、インスタンスの終了前と同じように 2 台それぞれのホスト名が表示されることを確認します。
   

使用したサービスと料金の考え方

今回使用したサービスの AWS Free Tier の考え方は以下の通りです。

クリーンアップ

検証が終わったら、以下の項目を確認してリソースを片付けてください。

• Auto Scaling グループを削除する（削除を実行すると配下のインスタンスも終了されます。先に最小容量・希望容量を「0」に変更してから削除すると、インスタンスの終了状況を確認しながら片付けられます）
• Application Load Balancer を削除する
• ターゲットグループを削除する
• 起動テンプレートを削除する
• EC2 用・ALB 用に作成したセキュリティグループを削除する
• RDS DB インスタンスを削除する（削除保護が有効になっている場合は先に解除し、最終スナップショットの要否も確認する）
• 削除時に作成した DB スナップショットが不要であれば削除する
• 「AWS Secrets Manager でマスター認証情報を管理」を選択した場合は、あわせてシークレットを削除する

おわりに

このブログでは、RDS のマルチ AZ フェイルオーバーに加えて、EC2 インスタンスを手動で終了し、Auto Scaling グループが希望する容量を維持するために代替インスタンスを自動起動する動作を確認しました。また、その間も ALB が正常なインスタンスにリクエストを振り分けることで、構成の一部に障害が発生した場合もサービスを継続しやすいことを確認しました。

これらは、信頼性の柱の設計原則である「障害から自動的に復旧する」「水平方向にスケールしてワークロード全体の可用性を高める」「復旧手順をテストする」と関連する内容です。

特に、クラウドの大きなメリットの一つであるスケールアウトによる可用性を実際に手を動かして確認できたのは、このハンズオンならではの収穫でした。

引き続き、次回は「パフォーマンス効率」の柱を、S3 + CloudFront でハンズオンする予定です。

最後までお読みいただきありがとうございました！

参考リンク

• Reliability Pillar
• Reliability: Design principles
• Reliability: Definition
• Amazon RDS DB インスタンスの作成
• 本番稼働用、開発/テスト、無料利用枠のテンプレートの違いを比較してみた
• Configuring and managing a Multi-AZ deployment for Amazon RDS
• Amazon RDS の DB インスタンスをマルチ AZ 配置に変換する
• Tutorial: Set up a scaled and load-balanced application
• Attach an Elastic Load Balancing load balancer to your Auto Scaling group
• Choosing an AWS Free Tier plan
• Amazon RDS and AWS Free Tier
• Elastic Load Balancing pricing

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、 IT・AI をフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。
※2026 年 1 月 アノテーション㈱から社名変更しました。