Seu Dev Notes

バックアップ・DR・可用性設計の判断基準(RTO/RPO・AWS Backup・RDS/Aurora・Auto Scaling)

一言まとめ

DR は RTO/RPO を満たす最安の戦略(Backup & Restore → Pilot Light → Warm Standby → Multi-site)を選ぶ。消せないバックアップは AWS Backup の Vault Lock、消せない S3 オブジェクトはオブジェクトロック。RDS はマルチ AZ(可用性)とリードレプリカ(読み取り分散)を混同しない。

作成 · 更新 · #aws#disaster-recovery#rds#auto-scaling#soa-c03
目次 7 sections
  1. 01 RTO / RPO と 4 つの DR 戦略
  2. 02 消せないバックアップ、消せないオブジェクト
  3. Glacier の取り出し層と Vault Lock
  4. 03 RDS / Aurora の構成
  5. マルチ AZ とリードレプリカ
  6. マルチ AZ DB インスタンスとマルチ AZ DB クラスター
  7. Aurora の補足
  8. 「クラスター」という語の意味の違い
  9. フェイルオーバー後に特定アプリだけ繋がらない
  10. 04 EC2 / Auto Scaling の可用性
  11. Auto Scaling の標準機能と設定
  12. 配置と保護
  13. 05 データ移行サービスの使い分け
  14. 06 関連
  15. 07 更新履歴

調査時点: 2026-07。

DR(Disaster Recovery)は、災害や重大障害からシステムを復旧するための備え。RTO(Recovery Time Objective)は復旧までに許容する時間、RPO(Recovery Point Objective)はどの時点までのデータを復元できればよいかの目標を指す。

RTO / RPO と 4 つの DR 戦略#

コスト安・復旧遅い順。要件を満たす中で最も安いものを選ぶ。

戦略構成RTO / RPO の目安
Backup and Restoreデータだけを S3 や別リージョンにバックアップし、被災時に CloudFormation でインフラを一から構築数時間〜24 時間
Pilot LightDB だけを待機リージョンに常時同期(Aurora Global Database など)。アプリサーバーは AMI / 起動テンプレートで準備し、被災時に Auto Scaling で起動数十分
Warm Standby待機リージョンでもアプリと LB を最小スペックで常時稼働。被災時にスケールアウト数分
Multi-site(Active/Active)複数リージョンで本番同等をフル稼働。Route 53 で負荷分散ほぼゼロ

Active/Passive の切り替えは Route 53 のフェイルオーバールーティング + ヘルスチェック。詳細は VPC ネットワークと配信。

消せないバックアップ、消せないオブジェクト#

対象が何かで 2 本のレールに分かれる。

対象構成
EBS スナップショット / RDS のバックアップを、コードなしで他リージョンにコピーし、ルートユーザーでも消せなくしたいAWS Backup のバックアッププラン + Backup Vault Lock(コンプライアンスモード)
CloudTrail ログや S3 上のファイルを長期保管し、消せなくしたいS3 オブジェクトロック(コンプライアンスモード) + ライフサイクルルールで Glacier Deep Archive へ移行

オブジェクトロックで削除を禁止したオブジェクトも、ライフサイクルによるストレージクラスの移行は可能(保存場所のランクを下げるだけで破壊ではない)。一方、保持期間内はライフサイクルの削除ルールもブロックされる。

EBS のバックアップを S3 ライフサイクルで扱おうとすると、S3 へ移すカスタムスクリプトが要るので、対象が EBS / RDS なら AWS Backup 側を選ぶ。

その他の保護手段: RDS のポイントインタイム復元(PITR)、S3 / FSx のバージョニング(誤削除・意図しない変更への対策)。

Glacier の取り出し層と Vault Lock#

オプション取り出し時間特徴
Expedited1〜5 分追加コスト。Deep Archive では使えない
Standard3〜5 時間(Deep Archive は 12 時間以内)デフォルト
Bulk5〜12 時間(Deep Archive は 48 時間以内)最安。テラ〜ペタバイト級の復元

Glacier Vault Lock は一度ロックするとルートユーザーでもポリシー変更・削除ができない WORM 状態になる。通常の Vault Access Policy は IAM 権限でいつでも変更できる。

RDS / Aurora の構成#

マルチ AZ とリードレプリカ#

比較マルチ AZ 配置リードレプリカ
目的高可用性・DR読み取りの負荷分散・性能
複製同期非同期(遅延あり)
エンドポイント単一(フェイルオーバー時も変更不要)レプリカごとに固有
昇格自動手動のみ
合図「高可用性」「自動フェイルオーバー」「読み取り遅延の解消」「分析クエリの分離」

マルチ AZ DB インスタンスとマルチ AZ DB クラスター#

構成中身読み取り
マルチ AZ DB インスタンスプライマリ 1 + スタンバイ 1スタンバイは読めない(フェイルオーバー専用)
マルチ AZ DB クラスタープライマリ 1 + リーダー 2(別 AZ)リーダー 2 台で読み取り分散しつつ高速フェイルオーバー

PostgreSQL 互換を保ったまま可用性と読み取り性能の両方が要るなら、RDS のマルチ AZ DB クラスターか、Aurora PostgreSQL + リードレプリカ(最大 15 台。レプリカ自体がフェイルオーバー先になる)。

Aurora の補足#

  • Aurora Serverless v2: 容量(ACU)をミリ秒単位で増減する。週に数回いつ来るか分からないスパイクに、未使用時のコストを抑えつつ即応する用途。マルチ AZ クラスターにはインスタンススペックを数分で動的に変える機能はない
  • Aurora Global Database の切り替え: 両リージョンが健全なら「計画されたフェイルオーバー(Switchover)」で RPO=0。プライマリが崩壊した災害時は「計画外のフェイルオーバー(Failover / AllowDataLoss)」で強制昇格し、復旧後に元のリージョンがセカンダリに戻る
  • RDB をシャーディング(分割)したいときは Aurora PostgreSQL Limitless Database。マルチ AZ クラスターは複製であって分割ではない

「クラスター」という語の意味の違い#

サービスクラスターの意味
RDS / Aurora同じデータを複製・同期する DB インスタンスの集まり(2 階層: クラスター > インスタンス)
ElastiCacheシステム全体の器。クラスター > シャード(データを分割)> ノード(シャード内で複製)
ECS / EKSコンテナを動かす計算資源(ノード)の束

フェイルオーバー後に特定アプリだけ繋がらない#

JVM などアプリ側の DNS キャッシュ TTL が原因。TTL を 30 秒以下にする。30 秒間はメモリのキャッシュを使い、DNS 問い合わせは 30 秒に 1 回なので性能影響は実質ない。AWS の Java SDK ガイドは 5 秒、または networkaddress.cache.ttl=0 を推奨している。コネクションプール(HikariCP など)がある間は DNS を引かず、障害で接続を作り直す瞬間だけ効く。

EC2 / Auto Scaling の可用性#

Auto Scaling の標準機能と設定#

  • AZ 再バランス: 複数 AZ を指定すると、各 AZ のインスタンス数が均等になるよう自動調整する。障害後も平準化に戻す。追加設定は不要。capacity-optimized は Spot の配分戦略で、AZ 均等化とは無関係
  • ヘルスチェックタイプ: デフォルトの EC2 は OS の生存だけを見るので、アプリがフリーズしても Healthy と判定する。ALB 配下で「アプリの不具合を検知して入れ替えたい」なら ELB に変更する
  • ヘルスチェックの猶予期間(Grace Period)は「起動直後の準備中に殺すな」、デフォルトのクールダウンは「スケーリング直後に追加発注するな」。アプリの起動に 3 分かかって無限に入れ替わるなら猶予期間を 5 分にする
  • ライフサイクルフック: EC2_INSTANCE_LAUNCHING で初期化・パッチ・ライセンス認証を待ち、EC2_INSTANCE_TERMINATING でローカルログを S3 / EFS に退避してから終了する
  • 動的スケーリングと予測スケーリングの違い、ヘルスチェックの種類は押さえておく
  • スケーリング開始を 5 分以内にするには詳細モニタリング(1 分)+ 評価期間 3/3。CloudWatch の監視設計

配置と保護#

  • 物理ハードウェアを分散したいならスプレッドプレイスメントグループ。1 AZ あたり最大 7 台なので、10 台なら複数 AZ にまたがらせる
  • 終了保護・停止保護はコンソール / CLI / API からの操作を防ぐが、OS 内の shutdown は防げない。InstanceInitiatedShutdownBehavior が terminate だと、終了保護が有効でも OS 内シャットダウンでインスタンスが削除される
  • 物理ホスト障害からの自動復旧(StatusCheckFailed_System → Recover)は EventBridge と自動修復
  • Spot の中断動作(terminate / stop / hibernate)と 2 分前通知は コスト最適化

データ移行サービスの使い分け#

サービス役割
AWS DataSyncNFS / SMB からオンプレのデータを S3 / EFS / FSx へ大量一括移行・増分同期する
AWS Transfer Family外部の取引先が既存の SFTP / FTPS クライアントを変えずに S3 / EFS へファイルを出し入れする窓口

Snowball Edge は調査時点で新規受付を停止しメンテナンスモードに移行済みと確認した(停止日は 2025-11-07 と記録。最新状況は公式で確認)。代替はオンライン転送(DataSync)やエッジ処理(Outposts / Local Zones)。

関連#

更新履歴#

  • 2026-07-18: 初版(ローカル調査ノート)
  • 2026-10-17: Wiki へ移植、概念ページとして再構成。冒頭に定義を追加

同じトピック — AWS