Amazon Auroraは単なる「高性能なRDS」ではなく、ストレージの冗長化がアーキテクチャの根幹に組み込まれたデータベースサービスです。3つのAZにわたって6コピーのデータを自動的に保持するクラスターボリュームの仕組みを理解していないと、フェイルオーバーが発生した際に「なぜエンドポイントが切り替わったのか」「接続を復旧させるには何をすればいいのか」の判断ができません。
この記事では、AWS CLI v2(ap-northeast-1 東京リージョン)を使ってAmazon AuroraをマルチAZ構成で設計する実践手順と、フェイルオーバーの動作確認方法を解説します。さらに、複数リージョンにまたがる冗長化を実現するGlobal Databaseの設計まで、一連の流れをコマンドの実行例付きで説明します。
この記事のポイント
・Auroraはクラスターボリュームを3AZ×6コピーで共有し単一障害に強い
・aws rds create-db-clusterでマルチAZクラスターを作成できる
・failover-db-clusterで手動フェイルオーバーをテストする
・Global Databaseでリージョン障害に備えRPO約1秒を設計できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜAuroraのクラスター設計が通常のRDSと根本的に異なるのか
通常のRDS Multi-AZ構成は、プライマリインスタンスとスタンバイインスタンスが同期レプリケーションでデータを複製します。フェイルオーバー時はスタンバイがプライマリに昇格しますが、データの再同期が必要なためフェイルオーバー完了まで1分~2分かかることがあります。Auroraの設計思想は根本的に異なります。ライター(プライマリ)インスタンスとリーダー(レプリカ)インスタンスは、いずれも同一の「クラスターボリューム」を共有します。このクラスターボリュームは3つのアベイラビリティーゾーン(AZ)に6コピー分散して保持されており、インスタンスが別AZに移っても「データをコピーし直す」必要がありません。
この違いが、フェイルオーバー時間に直接表れます。通常のRDS Multi-AZでは60秒~120秒かかることがある一方、Auroraのフェイルオーバーは一般的に30秒以内で完了します。ストレージ層の冗長性がインスタンス層から切り離されているため、リーダーインスタンスはほぼ即座にライターとして動き始められます。
・RDS Multi-AZ: ストレージのコピーがインスタンスに紐付く。フェイルオーバー時はスタンバイへのデータ同期完了を待つ
・Aurora: ストレージはクラスターボリュームとして独立。インスタンス障害があってもデータは別インスタンスからそのまま参照できる
Auroraクラスターの基本アーキテクチャを理解する
1. ライターとリーダーインスタンスの役割分担
Auroraクラスターには「ライターインスタンス(プライマリ)」が1つと、最大15台の「リーダーインスタンス(レプリカ)」を配置できます。ライターは読み書き両方の処理を担当します。リーダーは読み取り専用で、SELECT処理をオフロードすることで書き込みエンドポイントへの負荷を下げる役割を持ちます。フェイルオーバーが発生すると、リーダーインスタンスのうちの1つが自動的にライターに昇格します。この昇格はフェイルオーバー優先度(0が最高優先度、15が最低優先度)の設定に従います。同じ優先度のインスタンスが複数ある場合は、インスタンスサイズが大きいものが選ばれます。
2. クラスターボリュームが3AZに自動分散される仕組み
クラスターボリュームは自動的に3つのAZ(例: ap-northeast-1a, 1c, 1d)に6コピーが書き込まれます。Auroraは以下の障害許容性を持ちます。・書き込み処理: 6コピーのうち4コピーへの書き込み成功で完了とみなす(2コピーまでの障害を許容)
・読み取り処理: 6コピーのうち3コピーへのアクセス成功で完了とみなす(3コピーまでの障害を許容)
・AZ障害: 1つのAZ全体が落ちても、残り2つのAZで書き込み・読み取りを継続できる
AZまたはインスタンスで障害が発生すると、Auroraは自動的に損失したコピーをバックグラウンドで再建します。この修復処理はクラスターボリューム内で完結するため、アプリケーション層には影響を与えません。
3. Auroraエンドポイントの種類と使い分け
Auroraには用途別に複数のエンドポイントが用意されています。接続先を誤るとフェイルオーバー後に接続できなくなるため、エンドポイントの役割を正確に理解することが重要です。・クラスターエンドポイント(ライターエンドポイント): 常に現在のライターインスタンスを指す。書き込みを含む処理はここに接続する
・リーダーエンドポイント: リーダーインスタンス間でロードバランシングを行う。SELECT専用の読み取り処理に使う
・インスタンスエンドポイント: 特定のインスタンスに直接接続する。診断・デバッグ目的に限定して使用する
アプリケーションの接続先は必ずクラスターエンドポイント(書き込み用)またはリーダーエンドポイント(読み取り用)を使います。インスタンスエンドポイントに書き込み接続を向けると、フェイルオーバー後に自動切替が効かなくなります。
エンドポイントは内部的にDNSで解決されます。クラスターエンドポイントのDNS名(例: my-cluster.cluster-xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com)は変わりませんが、その名前が指すIPアドレスがフェイルオーバー時に自動で書き換わります。EC2インスタンスからの名前解決の仕組みについては、Linux DNS 設定の基本も参考にしてください。
マルチAZ構成でAuroraクラスターを設計する実践手順
ここでは「ライター1台(ap-northeast-1a)+リーダー1台(ap-northeast-1c)」のマルチAZクラスターを構築します。VPCとサブネットは事前に作成済みの前提で進めます。1. DBサブネットグループを作成する
Auroraクラスターには、複数のAZにまたがるDBサブネットグループが必要です。少なくとも2つの異なるAZのサブネットを含める必要があります。# AZをまたぐDBサブネットグループを作成する aws rds create-db-subnet-group --db-subnet-group-name aurora-subnet-group --db-subnet-group-description "Aurora multi-AZ subnet group" --subnet-ids subnet-0aaa111222333444a subnet-0bbb555666777888b # 実行例の出力(抜粋) # { # "DBSubnetGroup": { # "DBSubnetGroupName": "aurora-subnet-group", # "DBSubnetGroupStatus": "Complete", # "Subnets": [ # { "SubnetAvailabilityZone": { "Name": "ap-northeast-1a" } }, # { "SubnetAvailabilityZone": { "Name": "ap-northeast-1c" } } # ] # } # }
2. Auroraクラスターを作成する(aws rds create-db-cluster)
クラスターの作成時点では、インスタンスはまだ含まれません。エンジン・認証情報・サブネットグループ・セキュリティグループを設定します。# Auroraクラスターを作成する(Aurora MySQL 8.0互換) aws rds create-db-cluster --db-cluster-identifier my-aurora-cluster --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.07.1 --master-username adminuser --master-user-password "YourStrongPassw0rd!" --db-subnet-group-name aurora-subnet-group --vpc-security-group-ids sg-0abc123def456789a --backup-retention-period 7 --preferred-backup-window "18:00-19:00" --preferred-maintenance-window "sun:20:00-sun:21:00" --storage-encrypted --region ap-northeast-1
--storage-encryptedは本番環境では必ず指定します。暗号化はクラスター作成後には変更できません。--backup-retention-period 7は7日分のバックアップを自動保持する設定です(最大35日まで指定可)。3. ライターインスタンスを追加する
クラスターを作成したら、ライターとなるプライマリインスタンスを追加します。# ライターインスタンスをap-northeast-1aに配置する aws rds create-db-instance --db-instance-identifier my-aurora-writer --db-instance-class db.r6g.large --engine aurora-mysql --db-cluster-identifier my-aurora-cluster --availability-zone ap-northeast-1a --no-auto-minor-version-upgrade # インスタンスの状態を確認する aws rds describe-db-instances --db-instance-identifier my-aurora-writer --query "DBInstances[0].[DBInstanceStatus,AvailabilityZone,Endpoint.Address]" --output text # 出力例(インスタンスが利用可能になった状態) # available ap-northeast-1a my-aurora-cluster.cluster-xxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
DBInstanceStatusがavailableになるまで待ちます。4. リーダーインスタンスを別AZに追加する
フェイルオーバーを有効に機能させるには、ライターとは異なるAZにリーダーインスタンスを配置します。--promotion-tierの値が小さいほど、フェイルオーバー時に優先的にライターへ昇格します。# リーダーインスタンスをap-northeast-1cに配置する(フェイルオーバー優先度: 最高) aws rds create-db-instance --db-instance-identifier my-aurora-reader --db-instance-class db.r6g.large --engine aurora-mysql --db-cluster-identifier my-aurora-cluster --availability-zone ap-northeast-1c --promotion-tier 0 --no-auto-minor-version-upgrade # クラスターの状態を確認する(ライター・リーダーのエンドポイントを取得) aws rds describe-db-clusters --db-cluster-identifier my-aurora-cluster --query "DBClusters[0].{Status:Status,WriterEndpoint:Endpoint,ReaderEndpoint:ReaderEndpoint}" --output json # 実際の出力例 # { # "Status": "available", # "WriterEndpoint": "my-aurora-cluster.cluster-xxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com", # "ReaderEndpoint": "my-aurora-cluster.cluster-ro-xxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com" # } # メンバー一覧でライター・リーダーを確認する aws rds describe-db-clusters --db-cluster-identifier my-aurora-cluster --query "DBClusters[0].DBClusterMembers[*].{ID:DBInstanceIdentifier,Writer:IsClusterWriter,Tier:PromotionTier}" --output table # 出力例 # ----------------------------------------------- # | DescribeDBClusters | # +----------------------+--------+--------------+ # | ID | Tier | Writer | # +----------------------+--------+--------------+ # | my-aurora-writer | 1 | True | # | my-aurora-reader | 0 | False | # +----------------------+--------+--------------+
my-aurora-readerのTierが0(最高優先度)になっているため、フェイルオーバー時はこのインスタンスが最初にライターに昇格します。Auroraの設計とフェイルオーバーをハンズオンで体系的に習得したい方は、AWSマスターセミナー上級編も合わせてご確認ください。現役エンジニアが設計判断の根拠も含めてハンズオンで解説しています。
フェイルオーバーの動作を確認・テストする
1. エンドポイントの切替と自動昇格の仕組み
フェイルオーバーが発生すると、Auroraは以下の順序で処理を進めます。・ステップ1: ライターインスタンスの障害をAuroraが検知する(通常10秒~30秒以内)
・ステップ2: フェイルオーバー優先度が最も高いリーダーインスタンスをライターに昇格させる
・ステップ3: クラスターエンドポイントのDNSが新しいライターを指すように更新される
・ステップ4: アプリケーションが次の接続試行時に新ライターへ接続される
アプリケーション側では、接続プールの設定でフェイルオーバーに対応したDNS TTLの短い値(5秒程度)を設定することが重要です。多くのMySQLクライアントライブラリはデフォルトのDNS TTLが長く設定されており、これが原因でフェイルオーバー後も古いIPアドレスを掴み続けることがあります。JDBCを使う場合は
networkaddress.cache.ttl=5を設定します。2. フェイルオーバーを手動でテストする(aws rds failover-db-cluster)
本番投入前に手動フェイルオーバーをテストしておくことを強く推奨します。「設計上フェイルオーバーできるはず」と「実際にアプリケーションが自動復旧する」は別の話です。# フェイルオーバーを手動でトリガーする(my-aurora-readerをライターに昇格させる) aws rds failover-db-cluster --db-cluster-identifier my-aurora-cluster --target-db-instance-identifier my-aurora-reader # フェイルオーバーのイベントを確認する(直近60分のイベントを取得) aws rds describe-events --source-identifier my-aurora-cluster --source-type db-cluster --duration 60 --query "Events[*].[Message,Date]" --output table # 実際の出力例(フェイルオーバー完了時) # ------------------------------------------------------------------- # | DescribeEvents | # +-----------------------------------------------+------------------+ # | Started cross AZ failover to DB instance: | | # | my-aurora-reader | 2026-08-15T14:00 | # | Completed failover to DB instance: | | # | my-aurora-reader | 2026-08-15T14:00 | # +-----------------------------------------------+------------------+
describe-db-clustersでIsClusterWriter: trueがmy-aurora-readerの方に付いていることを確認します。3. CloudWatchアラームでフェイルオーバーを検知する
フェイルオーバーはEventBridgeにイベントを発行します。SNSトピックと組み合わせることで、フェイルオーバー発生時にメール通知を受け取れます。# EventBridgeルールでAuroraフェイルオーバー完了イベントを捕捉する aws events put-rule --name aurora-failover-alert --event-pattern '{ "source": ["aws.rds"], "detail-type": ["RDS DB Cluster Event"], "detail": { "EventID": ["RDS-EVENT-0073"] } }' --state ENABLED # SNS Topicをターゲットに設定する(事前にTopicとサブスクリプションが必要) aws events put-targets --rule aurora-failover-alert --targets Id=1,Arn=arn:aws:sns:ap-northeast-1:123456789012:ops-alert-topic
ss -tnでTCP接続状態を確認しながら、フェイルオーバー前後の接続切替タイミングを観察することができます。Aurora Global Databaseでマルチリージョン冗長化を実現する
Auroraのマルチ AZ設計はAZ障害への対策です。リージョン全体が影響を受ける大規模障害に備えるには、Global Databaseを使ったマルチリージョン設計が必要になります。1. Global Databaseの構成とRPO/RTO設計
Global Databaseは「プライマリリージョン」のクラスターと、最大5つの「セカンダリリージョン」のクラスターで構成されます。プライマリからセカンダリへのレプリケーションは専用の低遅延インフラを使っており、通常は1秒未満の遅延(RPO ~1秒)で同期されます。・RPO(目標復旧時点): ~1秒(専用レプリケーションインフラによる低遅延同期)
・RTO(目標復旧時間): 1分未満(Managed Planned Failoverの場合)
・対応リージョン数: 最大5リージョンのセカンダリを設定可能
ただし、RTO「1分未満」にはアプリケーション側の接続先切替時間は含まれません。Route 53のフェイルオーバールーティングポリシーと組み合わせて、DNS切替を自動化する設計が必要です。
2. Global Databaseの作成と昇格手順
既存のAuroraクラスターからGlobal Databaseを作成します。# 既存クラスターをソースにGlobal Databaseを作成する(プライマリリージョンで実行) aws rds create-global-cluster --global-cluster-identifier my-global-aurora --source-db-cluster-identifier arn:aws:rds:ap-northeast-1:123456789012:cluster:my-aurora-cluster --engine aurora-mysql # セカンダリリージョン(us-east-1)にクラスターを追加する # ※us-east-1で実行する aws rds create-db-cluster --db-cluster-identifier my-aurora-cluster-us --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.07.1 --db-subnet-group-name aurora-subnet-group-us --vpc-security-group-ids sg-0xyz999aaa --global-cluster-identifier my-global-aurora --region us-east-1 # セカンダリクラスターにリーダーインスタンスを追加する(us-east-1で実行) aws rds create-db-instance --db-instance-identifier my-aurora-reader-us --db-instance-class db.r6g.large --engine aurora-mysql --db-cluster-identifier my-aurora-cluster-us --region us-east-1
3. セカンダリリージョンへの昇格手順
計画的な切替(メンテナンスや地域移転)にはfailover-global-clusterを使います。プライマリリージョンが完全に停止している場合は、セカンダリをGlobal Databaseから切り離す「アンプランドフェイルオーバー」を実行します。# Managed Planned Failover(計画的なリージョン切替) # プライマリが正常な状態での計画的切替に使用する aws rds failover-global-cluster --global-cluster-identifier my-global-aurora --target-db-cluster-identifier arn:aws:rds:us-east-1:123456789012:cluster:my-aurora-cluster-us --region ap-northeast-1 # プライマリリージョンが完全停止した場合のアンプランドフェイルオーバー # セカンダリをGlobal Databaseから切り離してスタンドアローンクラスターとして昇格させる aws rds remove-from-global-cluster --db-cluster-identifier arn:aws:rds:us-east-1:123456789012:cluster:my-aurora-cluster-us --global-cluster-identifier my-global-aurora --region us-east-1
remove-from-global-clusterはセカンダリを完全に切り離すため、元のGlobal Databaseへの再接続は新たに設定し直す必要があります。障害でなく計画的な切替の場合はfailover-global-clusterを使います。トラブルシューティング|よくある接続エラーと対処法
フェイルオーバー後に「Communications link failure」が繰り返し発生する
フェイルオーバー後にアプリケーション側でこのエラーが続く場合、古い接続プールを掴み続けている可能性があります。確認すべきポイントは以下の通りです。・接続先URLがインスタンスエンドポイントではなくクラスターエンドポイントになっているか確認する
・アプリケーションのDNS TTL設定を確認する(JDBCなら
networkaddress.cache.ttl=5を追記する)・接続プールの
testOnBorrowまたはvalidationQuery設定で死んだ接続を除去しているか確認する「Too many connections」エラーが発生する
Auroraのmax_connectionsはインスタンスクラスに依存します。db.r6g.largeのデフォルトは約2,000接続です。フェイルオーバー時に旧ライターへの接続が残留したまま、新ライターへの接続が集中することがあります。# 現在の接続数を確認する(MySQL接続後にSQLを実行) SHOW STATUS LIKE 'Threads_connected'; # Auroraのmax_connectionsを調整するパラメータグループの変更 aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name my-aurora-params --parameters ParameterName=max_connections,ParameterValue=5000,ApplyMethod=pending-reboot
フェイルオーバーが30秒を超えて完了しない
--promotion-tierが正しく設定されているか確認します。値が高い(例: tier=15)リーダーしか存在しない場合でも昇格対象にはなりますが、最適な昇格候補を決定するための判定処理が入ります。フェイルオーバー速度を重視する場合は、ライターと同じインスタンスサイズのリーダーをtier=0で少なくとも1台配置することが推奨設計です。本記事のまとめ
Amazon AuroraのマルチAZクラスター設計とGlobal Databaseのポイントをまとめます。| やりたいこと | コマンド |
|---|---|
| DBサブネットグループを作成する | aws rds create-db-subnet-group --db-subnet-group-name 名前 --subnet-ids サブネットA サブネットB |
| Auroraクラスターを作成する | aws rds create-db-cluster --db-cluster-identifier 名前 --engine aurora-mysql --master-username ユーザー --db-subnet-group-name グループ名 |
| ライター・リーダーインスタンスを追加する | aws rds create-db-instance --db-instance-identifier 名前 --db-cluster-identifier クラスター名 --availability-zone AZ名 --promotion-tier 数値 |
| フェイルオーバーを手動でテストする | aws rds failover-db-cluster --db-cluster-identifier クラスター名 --target-db-instance-identifier ターゲット名 |
| クラスターの状態とエンドポイントを確認する | aws rds describe-db-clusters --db-cluster-identifier クラスター名 --query DBClusters[0] |
| Global Databaseを作成する | aws rds create-global-cluster --global-cluster-identifier 名前 --source-db-cluster-identifier クラスターARN |
| 計画的なリージョン切替を行う | aws rds failover-global-cluster --global-cluster-identifier 名前 --target-db-cluster-identifier ターゲットARN |
Auroraの設計は、AWSの「冗長設計の型」を知っていれば迷わない
フェイルオーバーの仕組みは調べれば分かります。でも「なぜリーダーのプロモーション優先度をこう設定するのか」「アプリケーション側のDNS TTL設定を見落とすとどうなるのか」を現場で説明できますか?
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、AWSを含む現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:AWS ALBとNLBの使い分け設計|aws elbv2コマンドでマルチAZ構成を実装する方法
- この記事の属するカテゴリ:AWS(Amazon Linux)へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます