Amazon SAA-C03: 高可用性、耐障害性、災害復旧 — 学習ガイド

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

こちらの一部です： AWS SAA-C03 — 完全学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

マルチAZデプロイメントとレプリケーション

マルチAZアーキテクチャは、単一のデータセンターまたはアベイラビリティゾーンの障害に対応するものであり、それ以上のものではありません。この区別は、高可用性設計において最も誤解されがちな点です。マルチAZデプロイメントは、1つのリージョン内でのAZの損失には耐えられますが、リージョン全体の停止、リージョンサービスの障害、またはリソースの偶発的な削除（その削除が即座にスタンバイにレプリケートされる場合）には耐えられません。レプリケーションは、不正なデータ（論理的な破損、スキーマの間違い、ランサムウェアによる書き込みなど）を忠実に伝播します。これが、レプリケーションとバックアップが互いに補完するものであり、代用するものではない理由です。

Amazon RDSの場合、マルチAZは異なるAZに同期的なスタンバイレプリカをプロビジョニングします。書き込みは、確認応答の前に両方のインスタンスでコミットされるため、RPOは実質的にゼロとなり、自動フェイルオーバー中のRTOは通常60〜120秒です。従来のマルチAZインスタンスデプロイメントでは、スタンバイは読み取り不可であり、純粋に耐久性とフェイルオーバーのために存在します。マルチAZクラスターデプロイメント（2つの読み取り可能なスタンバイ）は、フェイルオーバー時間をさらに短縮し、ある程度の読み取りスケーリングを提供しますが、依然として1つのリージョン内に限定されます。

読み取りスケーリングのためには、リードレプリカを追加します。リードレプリカは非同期レプリケーションを使用し、レポート作成、分析、ダッシュボードのクエリをオフロードするために存在します。リードレプリカをHAフェイルオーバーメカニズムとして扱うことは、3つの点で間違っています。レプリケーションは非同期であること（昇格時にデータ損失が発生する）、昇格は手動またはスクリプト化されていること（自動ではない）、そしてプライマリエンドポイントは維持されないことです。増大するワークロードが新たな複雑さを伴わずに読み取りキャパシティの増強を必要とする場合は、リードレプリカを追加します。要件がデータ損失ゼロの自動フェイルオーバーである場合は、マルチAZを使用します。リレーショナルエンジンでリージョン障害を乗り越えるRPO/RTOが求められる場合、Aurora Global Databaseは1秒未満のクロスリージョンレプリケーションラグと1分未満のマネージドフェイルオーバーRTOを提供します。

Amazon ElastiCacheも、レプリケーショングループで同じパターンに従います。マルチAZが有効なRedisレプリケーショングループは、複数のAZにわたってプライマリと1つ以上のレプリカを維持します。プライマリに障害が発生した場合、ElastiCacheはレプリカを昇格させ、プライマリエンドポイントを更新します。水平方向のスケーリングのために、Redis（クラスターモード有効）はデータをシャードに分割し、各シャードはそれ自身のレプリケーショングループとなります。対照的に、Memcachedはレプリケーションを行いません。ノードの損失は、そのパーティションのデータ損失を意味します。

Amazon FSxは、FSx for Windows File ServerとFSx for ONTAP向けにマルチAZデプロイメントタイプを提供し、優先ファイルサーバーとスタンバイファイルサーバー間の同期レプリケーションを使用します。FSx for Lustreは一般的にシングルAZ（スクラッチまたは永続）です。Lustreの耐久性は、AZレプリケーションからではなく、S3データリポジトリの関連付けによって実現されます。

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

RDSの自動バックアップとポイントインタイムリカバリ

RDSの自動バックアップは、日次スナップショットと5分ごとのトランザクションログのS3への継続的なアップロードを組み合わせることで、1〜35日の保持期間内の任意の秒への**ポイントインタイムリカバリ（PITR）**を可能にします。RPOが2時間であれば、RDSのネイティブバックアップで既にカバーされています。追加のスナップショットスケジューリングは不要であり、クロスリージョンコピー、クロスアカウント分離、またはRDSスナップショットコピーが提供する以上のVault Lockセマンティクスが必要でない限り、その上にAWS Backupを重ねるのは冗長です。デフォルトの自動バックアップは、多くの場合、控えめなRPO要件に対する最も安価で正しい答えです。

一元管理プレーンとしてのAWS Backup

AWS Backupは、EBS、EC2（AMIとして）、RDS、Aurora、DynamoDB、EFS、FSx、Storage Gateway、S3など、多岐にわたるサービスのバックアップをポリシー主導で管理するコントロールプレーンです。サービス固有のスナップショットロジックをスクリプト化する代わりに、頻度、バックアップウィンドウ、開始/完了ウィンドウ、コールドストレージへのライフサイクル移行、保持期間、および保存先ボールトを記述するルールをグループ化したバックアッププランを定義します。リソースは、タグまたはARNによるリソースの割り当てを通じて登録されるため、Backup=Dailyのようなタグ付け規則が、カバレッジを管理する運用上の契約となります。数百のEC2インスタンス群に対しては、インスタンスごとのスケジュールを作成するのではなく、タグを適用してAWS Backupに列挙させるタグベースの選択が、最も労力の少ないアプローチです。

バックアップボールトは、リカバリポイントが格納されるKMSで暗号化されたコンテナです。アクセスは、ボールトのリソースポリシーによって制御されます。

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

クロスリージョンおよびクロスアカウントコピー

CopyActionsブロックは、クロスリージョンDRコピーのためのメカニズムです。AWS Backupはスナップショットのコピーを処理し、送信先リージョンのKMSキーで再暗号化し（送信先ボールトはそのリージョンのキーを参照する必要があります）、独立したライフサイクルを適用します。EBSおよびRDSのスナップショットは、デフォルトでソースリージョンに保存されます。リージョン全体が障害に見舞われた場合、スナップショットも同様に影響を受けます。リージョンの回復力に言及する規制上またはビジネス上の要件には、AWS Backupのコピーアクション、RDS自動スナップショットのクロスリージョンコピー、またはクロスリージョンの宛先を持つDLMポリシーなど、明示的なクロスリージョンコピーのステップを含める必要があります。

クロスアカウントコピーの場合、AWS OrganizationsはAWS Backupの管理者アカウントを委任します。ソースボールトのポリシーは宛先アカウントを許可し、宛先ボールトはソースからのコピーを許可します。これはDRを集中管理するための費用対効果の高い方法です。1つの管理アカウントが多くのワークロードアカウントからのリカバリポイントを保持し、どちらのリージョンにもリストアできます。EC2の場合、AMIをセカンドリージョンにコピーし、スナップショットを共有することで、ウォームなインフラストラクチャなしでそこにインスタンスを起動できます。暗号化されたスナップショットではCMKの共有が必要です。宛先アカウントまたはリージョンにはkms:CreateGrantとキーへのアクセス権が必要です。これを怠ると、クロスアカウントのリストアがサイレントに失敗する原因となります。

24時間のRPOは、毎日自動化されたスナップショットをクロスリージョンにコピーすることで安価に満たせます。これは、クロスリージョンのリードレプリカやウォームスタンバイのクラスターよりもはるかに低コストです。RPOがスナップショットの頻度で実現できる値を下回る場合にのみ、継続的なレプリケーションに切り替えるべきです。

AMIのライフサイクルとEC2のバックアップ

EC2のバックアップを自動化するメカニズムには、Data Lifecycle Manager (DLM) と AWS Backup の2つがあります。DLMはAWS Backupより前から存在し、ポリシー駆動でEBSスナップショットやAMIをスケジュール通りに作成し、クロスリージョンおよびクロスアカウントでのコピーアクションを実行します。AWS Backupはこれを包含し、さらに中央集権的なポリシー、Vault Lock、および複数サービスにまたがるスコープを追加します。他のサービスで既にAWS Backupを実行している場合はAWS Backupを優先的に使用し、Vault機能が不要な純粋なEBS/AMIのシナリオではDLMを使用します。

Auto Scalingグループの背後にある、永続的なローカルデータを持たないステートレスなウェブ層の場合、実行中のEC2インスタンスをバックアップするのは無駄です。正しいアプローチは、(EC2 Image BuilderやCIパイプライン経由で) 強化されたAMIを焼き付け、それを起動テンプレートで参照し、インスタンスの置換はASGに任せることです。バックアップの労力は、ネイティブの自動バックアップがRPOを満たすステートフルな階層に集中させます。

不変性: Vault LockとObject Lock

アカウント内の通常のスナップショットは、適切なIAM権限を持つ誰でも削除できます。スナップショットだけでは不変性の要件を満たしません。規制要件 (SEC 17a-4, FINRA, HIPAA, GDPR) では、管理者でさえ回避できないWORM (Write-Once-Read-Many) 保持が頻繁に要求されます。2つのAWSメカニズムがこれを実現します。

AWS Backup Vault Lock は、バックアップボールトにWORMを強制します。

コンプライアンスモードでは、クーリングオフ期間が経過すると、ルートアカウントを含むいかなるユーザーも、保持期間を短縮したり、有効期限前に復旧ポイントを削除したり、ロック自体を解除したりすることはできません。これにより、内部関係者による削除と、アカウントを完全に侵害したランサムウェア攻撃者の両方を防ぐことができます。

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock は、ガバナンスモード (特権ユーザーが s3:BypassGovernanceRetention で上書き可能) またはコンプライアンスモード (ルートを含む誰もが保持期間の短縮や削除が不可) で、オブジェクトレベルのWORMを提供します。リーガルホールドは保持期間とは独立しています。Object Lockはバージョニングを必要とし、完全な保護のためにはバケット作成時に有効にする必要があります。

フェイルオーバーリージョン用のキャパシティ予約

大規模なイベント発生日にフェイルオーバーリージョンでEC2キャパシティが利用可能であると想定するDR計画は、計画とは言えません。あるリージョンが障害を起こすと、誰もが同時にフェイルオーバーするため、インスタンスタイプ (特に大規模、GPU、または特殊な形状のもの) は枯渇する可能性があります。ターゲットリージョンでのオンデマンドキャパシティ予約 (ODCR) は、特定のインスタンスタイプ、プラットフォーム、AZのキャパシティを保証し、使用されているかどうかに関わらず課金されます。コストを相殺するためにSavings Planと組み合わせます。長期的なGPU/MLのコミットメントにはキャパシティブロックが適用され、ファミリーの柔軟性が必要な場合はキャパシティ予約フリートが複数のインスタンスファミリーをカバーします。原則として、ビジネスがDRリージョンで保証されたコンピューティングを必要とする場合は、それを予約すべきです。ベストエフォート型のオンデマンドの可用性に依存してはいけません。

DR戦略の選択

AWSは4つのDR階層を標準化しており、それぞれコストと復旧のトレードオフが異なります。

正しい階層は、アーキテクチャの好みではなく、ビジネスのRPOとRTOによって決定されます。24時間のRPOは、日次のクロスリージョンスナップショットコピー (バックアップ & リストア) を許容します。秒単位のRPOは、継続的なレプリケーション (クロスリージョンリードレプリカ、Auroraグローバルデータベース、DynamoDBグローバルテーブル、またはS3クロスリージョンレプリケーション) を要求します。予算に関係なく、夜間のスナップショットで5分のRPOを達成しようとすることは、アーキテクチャ的に不可能です。逆に、すべてのワークロードでデフォルトでアクティブ/アクティブを選択するのはコストのアンチパターンです。それには、グローバルに一貫性のあるデータ (DynamoDBグローバルテーブルまたは書き込み転送を伴うAuroraグローバル)、フルスケールでの重複したコンピューティング、およびRoute 53やGlobal Acceleratorによる複雑なトラフィックステアリングが必要になります。定められたRPO/RTOを満たす最も安価なパターンを選択してください。2時間のRPOの場合、通常はバックアップ & リストアかパイロットライトで十分であり、ウォームスタンバイは過剰設計です。

削除保護と多層的な安全策

レジリエンスとは、単に「バックアップがあるか」ということではなく、「単一のアクター、ミス、または攻撃によってそれらを消去されうるか」ということです。多層的な制御により、ワンクリックでの大惨事を防ぎます。

• RDS: DeletionProtectionを有効にし、削除時に最終スナップショットの作成を要求します。
• EC2: 重要なインスタンスでDisableApiTerminationとDisableApiStopを有効にします。
• DynamoDB: 削除保護とポイントインタイムリカバリを有効にします。
• S3: バージョニング + MFA削除 + Object Lockによる不変性。
• CloudFormation: ステートフルなリソースにDeletionPolicy: Retainを設定し、スタックの終了保護を有効にします。
• IAM SCP: ブレークグラスロール以外ではbackup:DeleteRecoveryPoint、backup:DeleteBackupVault、rds:DeleteDBInstance、ec2:DeleteSnapshotを拒否します。

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

これらをコンプライアンスモードのVault Lockと組み合わせることで、多層防御が実現します。侵害された管理者認証情報でさえ、最終防衛ラインである復旧ポイントを破壊することはできません。

よくある落とし穴

Multi-AZをDRとして扱うこと。 RDS Multi-AZ、ElastiCache Multi-AZ、FSx Multi-AZはすべて単一リージョン内に存在します。リージョン規模のAPI障害、誤ったテーブル削除、スキーマ移行の適用ミスは、両方のノードに影響を与えます。「別のリージョン」、「リージョン障害」、または「クロスリージョンRPO」に言及する要件では、クロスリージョンレプリケーションまたはコピーが必須です。Multi-AZだけでは要件を満たせません。

リードレプリカとHAを混同すること。 リードレプリカは非同期であり、昇格は手動で行い、エンドポイントも変更されます。これらは読み取り性能のスケーリングを解決するものであり、自動フェイルオーバーのためではありません。

スナップショットがコンプライアンス要件を満たすと仮定すること。 Vault Lock（コンプライアンスモード）やObject Lockが設定されていないスナップショットは、適切なIAM権限を持つ任意のプリンシパルやルートアカウントによって削除可能です。WORM規制における保持要件では、ロックされたクーリングオフ期間が経過した、明示的な不変性設定が必要です。

リージョン規模のRPOに対してローカルスナップショットのみを使用すること。 EBSとRDSのスナップショットは、デフォルトでソースリージョンに保存されます。リージョンレベルの耐障害性を確保するには、明示的なクロスリージョンコピーアクションが必要です。

テスト済みのリストアや予約済みキャパシティのないバックアップ。 一度もリストアしたことのないスナップショットは仮説であり、バックアップではありません。リストア訓練を行うことで、IAMロールの欠落、移行先リージョンやアカウントでのKMSキーへのアクセス問題、利用不可能なインスタンスタイプなどが明らかになります。重要なワークロードに対してキャパシティ予約がなければ、全員が同時にフェイルオーバーした際にDRリージョンに必要なインスタンスタイプが不足する可能性があり、RTOは無限大になります。

active-activeへの過剰な設計。 グローバルなコンピューティングの複製、グローバルに一貫性のあるデータレプリケーション、複雑なトラフィックステアリングは高コストです。RPO/RTOがそれを正当化しない場合、パイロットライトやウォームスタンバイが適切なアーキテクチャです。

ステートレス層のバックアップ。 ASGの背後にある一時的なウェブサーバーのスナップショットを取得することは、コストの無駄遣いであり、復旧を複雑にします。AMIを作成し、それを起動テンプレートで参照し、バックアップへの投資はステートフルなデータに集中させるべきです。

← 管理、運用、可観測性、コスト · すべてのドメイン

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →