SAA 08 高可用性・DR・移行(バックアップ・DR戦略・監視)

更新日: 2026-10-25

← SAA_07_疎結合と分析(SQS・SNS・EventBridge・Kinesis・Athena) / 次 → SAA_09_コスト最適化(料金モデル・コスト管理)

高可用性の定番構成

図を表示しています…

              Route 53
                 │
            CloudFront(静的ファイルは S3 から)
                 │
               ALB(複数 AZ)
          ┌──────┴──────┐
   AZ-a: EC2(ASG)   AZ-c: EC2(ASG)
          │              │
   ElastiCache(セッション・キャッシュ)
          │
   RDS マルチAZ / Aurora(+ リードレプリカ)

ポイント:単一障害点(1か所落ちると全部止まる場所)をなくす。

サーバーはステートレスにする(セッションやアップロードファイルを EC2 に持たない → ElastiCache・DynamoDB・S3・EFS へ)
どの層も2つ以上の AZ
非同期にできる処理は SQS で切り離す

RPO と RTO

 最後のバックアップ      障害発生           復旧完了
 ──────●──────────────────✕──────────────────●──────▶ 時間
       ├── RPO ──────────┤├──── RTO ─────────┤
      (どれだけデータを失うか)(どれだけ止まるか)

RPO(目標復旧時点):何分前までのデータに戻れればよいか
RTO(目標復旧時間):何分で復旧すればよいか
どちらも短くするほど高くつく

DR 戦略(4段階)

戦略	平常時の DR 側	RPO / RTO	コスト
バックアップと復元	バックアップだけ(S3・スナップショット)	時間単位	最安
パイロットライト	DB だけ複製して動かす。サーバーは止めておく(AMI だけ)	数十分	安い
ウォームスタンバイ	小さい規模で全部動いている → 障害時にスケールアップ	分単位	中
マルチサイト(アクティブ/アクティブ)	本番と同じ規模で両方動く	ほぼゼロ	最高

図を表示しています…

→ 問題文の RPO/RTO と「コストを最小に」の両方を満たす一番安いものを選ぶ。

DR で使う機能

AMI・EBS スナップショット・RDS スナップショットのリージョン間コピー
S3 クロスリージョンレプリケーション
Aurora Global Database、DynamoDB グローバルテーブル
Route 53 フェイルオーバールーティング + ヘルスチェック
AWS Elastic Disaster Recovery(DRS):サーバーを継続的に複製し、数分で別リージョンに立ち上げ
AWS Backup:EC2・EBS・RDS・DynamoDB・EFS などのバックアップを一元管理、ポリシーでスケジュール、別リージョン・別アカウントへコピー、Vault Lock で削除防止

移行(オンプレ → AWS)

移行の 7R(よく出るのは上の4つ)

戦略	意味
リホスト(リフト&シフト)	そのまま EC2 に移す。一番早い
リプラットフォーム	少しだけ変える(DB を RDS に、など)
リファクタリング	クラウド向けに作り直す(サーバーレス化など)
リパーチェス	SaaS に乗り換える
リロケート / リタイア / リテイン	VMware ごと移す / 廃止 / そのまま残す

移行のサービス

サービス	用途
Application Migration Service(MGN)	サーバーをそのまま EC2 に移す(リホスト)
DMS + SCT	データベースの移行
DataSync / Snowball Edge / Transfer Family	データの移行(→ SAA_05_ストレージ(S3・EBS・EFS・FSx))
Migration Hub / Application Discovery Service	移行の計画・オンプレのサーバー情報の収集

監視・運用

サービス	何を見るか	キーワード
CloudWatch メトリクス	CPU・ネットワークなどの数値	「CPU が 80% を超えたら」
CloudWatch アラーム	しきい値で通知(SNS)・Auto Scaling・EC2 の自動復旧	—
CloudWatch Logs	アプリ・OS のログ(エージェントで送る)	「ログを一元管理」
CloudWatch エージェント	メモリ・ディスク使用率など OS 内部の値	「メモリ使用率を監視」
CloudTrail	誰が・いつ・どの API を呼んだか	「操作の監査」「誰が削除したか」
AWS Config	リソースの設定の履歴と、ルール違反の検出	「S3 が公開されていないか常にチェック」「設定変更の履歴」
X-Ray	分散トレーシング	「マイクロサービスのどこが遅いか」
Systems Manager	EC2 の一括パッチ、コマンド実行、Session Manager(SSH 不要で接続)	「多数のサーバーにパッチ」
CloudFormation	インフラをコード(テンプレート)で作る。StackSets で複数アカウント・リージョンに展開	「同じ環境を何度も作る」
Trusted Advisor	コスト・セキュリティ・性能のおすすめを提示	—
Health Dashboard	AWS 側の障害・メンテナンス情報	—

→ CloudTrail = 操作の記録(誰が)、Config = 設定の状態(どうなっているか)、CloudWatch = 性能の数値とログ。この3つの区別は毎回出る。

確認ポイント

単一障害点をなくすための構成を描ける
RPO と RTO を説明できる
DR 戦略4つをコストと復旧時間の順で並べられる
AWS Backup で何ができるか言える
CloudWatch・CloudTrail・Config の違いを言える