Amazon Auroraのクラスター設計とフェイルオーバー|マルチAZ構成とGlobal Databaseで高可用性を実現する方法

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)AWS(Amazon Linux) > Amazon Auroraのクラスター設計とフェイルオーバー|マルチAZ構成とGlobal Databaseで高可用性を実現する方法
「Auroraを使えばフェイルオーバーが自動でできると聞いたが、実際にどう設計すればいいかわからない」「通常のRDS Multi-AZとどう違うのか、使い分けの判断基準を教えてほしい」という声を、セミナーの受講生からよく受けます。

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秒を設計できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

なぜ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

インスタンスの作成には数分かかります。DBInstanceStatusavailableになるまで待ちます。

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-readerTierが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 | # +-----------------------------------------------+------------------+

開始から完了まで通常は20秒~30秒で収まります。フェイルオーバー後はdescribe-db-clustersIsClusterWriter: truemy-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

EC2インスタンスからAuroraエンドポイントへのポート到達性確認には、Linux ポート確認の全コマンドを参考にしてください。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の設計で最も重要な原則は「インスタンスがなくなってもデータは残る」という考え方です。クラスターボリュームがストレージ層の冗長性を担保しているため、フェイルオーバーはデータのコピーを待たずにインスタンスを切り替えるだけで完了します。この特性を活かすには、アプリケーションの接続先を必ずクラスターエンドポイントに向け、DNSキャッシュのTTLを短く設定しておくことが前提条件です。マルチリージョン冗長化が必要な場合はGlobal Databaseを追加することで、RPO約1秒という高いデータ保護水準を達成できます。

Auroraの設計は、AWSの「冗長設計の型」を知っていれば迷わない

フェイルオーバーの仕組みは調べれば分かります。でも「なぜリーダーのプロモーション優先度をこう設定するのか」「アプリケーション側のDNS TTL設定を見落とすとどうなるのか」を現場で説明できますか?
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、AWSを含む現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。