Amazon SOA-C02: 高可用性、耐障害性、および災害対策 — 学習ガイド

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

この分野では、コンポーネント、サービス、またはリージョン全体に障害が発生した場合でも、可用性と回復性を維持するシステムの設計を扱います。バックアップとスナップショットの戦略、レプリケーションとフェイルオーバーのパターン、そしてビジネス上のRTO（目標復旧時間）とRPO（目標復旧時点）の目標を達成するために必要な運用テストに及びます。運用上の重要性は高く、停止やデータ損失はSLA、収益、コンプライアンスに直接影響します。効果的な設計では、コスト、複雑さ、そして許容可能なデータ損失とダウンタイムのリスクのバランスを取ります。

バックアップ戦略、スナップショット、リテンション

バックアップは自動化され、アプリケーションの状態と整合性が取れており、ポリシーに従って保持される必要があります。AWS Backupを使用して、プラン、リテンション、ライフサイクルルールを一元管理します（バックアッププランとボールトを作成し、リソースIDのARNまたはタグを割り当てます）。EBSボリュームにはData Lifecycle Manager (DLM)を使用してスナップショットをスケジュールします（コンソールまたは

undefined

）。CLIでのスナップショット作成例:

undefined

。RDSでは、自動スナップショットまたは手動DBスナップショットを使用します（

undefined

）。ポイントインタイムリカバリのためにRDSの自動バックアップを有効にし、リテンションSLAを満たすために拡張モニタリングとスナップショット保持を有効にします。

リテンション、不変性、クロスリージョンコピーは重要な決定事項です。

• 短いRPO/RTOには頻繁なスナップショットと短い保持削除ウィンドウが必要ですが、これによりコストが増加します。
• 規制上の不変性のためには、AWS Backup Vault LockまたはS3 Object Lockをリーガルホールドに使用します。
• クロスリージョンでの耐久性のためには、スナップショットをコピーし（

undefined

）、クロスリージョンレプリケーションの前にS3のバージョニングを有効にします。

常にアプリケーションと整合性の取れた状態をキャプチャします。EC2の場合、AWS Systems Manager Run Commandやスクリプトを使用して、スナップショット作成前にファイルシステムをフラッシュ/ロックします。データベースの場合、ポイントインタイム検証のためにエンジンネイティブのスナップショット（RDS/Aurora）または論理バックアップ（mysqldump, pg_dump）が望ましいです。

クロスリージョンレプリケーションとディザスタリカバリのパターン

クロスリージョン戦略は、リージョン障害からの影響範囲（ブラスト半径）を縮小します。S3のクロスリージョンレプリケーション（CRR）には、バージョニング、IAMレプリケーションロール、およびレプリケーション設定が必要です（コンソールまたは

undefined

）。RDSはクロスリージョンリードレプリカ（

undefined

）をサポートし、Aurora Global Databaseは制御されたフェイルオーバーを備えた低遅延のクロスリージョン読み書きアーキテクチャをサポートします。DynamoDB Global Tablesは、リージョン間でデータを非同期にレプリケートし、結果整合性を考慮したマルチリージョンでの読み取りに適しています。

RTO/RPOとコストに基づいてDRパターンを選択します。

• パイロットライト: 重要なデータをセカンダリリージョンにレプリケートします（S3、スナップショット、DBレプリカ）。ただし、稼働インフラは最小限に抑え、IaCテンプレートを介して迅速にスケールアップします。
• ウォームスタンバイ: セカンダリリージョンでより小規模なアクティブフットプリントを持ち、継続的にデータをレプリケートし、自動的にスケールアップできる縮小されたサービスを維持します。
• マルチリージョン アクティブ/アクティブ: 複数のリージョンで完全なスタックを実行し、トラフィックルーティングと競合解決を行います。グローバルレプリケーション（DynamoDB global tables, Aurora Global DB, アプリケーションレベルの競合処理）が必要です。

レプリケーションの整合性を考慮します。同期レプリケーションはRPOを最小化しますが、レイテンシーが増加し、クロスリージョンではサポートされない場合があります。ほとんどのクロスリージョンオプションは非同期であり、現実的なRPOを定義するレプリケーションラグが発生します。

Multi-AZとMulti-Regionアーキテクチャの選択

Multi-AZは、リージョン内での高可用性のためのデフォルトであり、多くのマネージドサービスに対して最小限のRTOで自動フェイルオーバーを提供します。RDS Multi-AZとAuroraはAZ間でストレージをレプリケートし、フェイルオーバーは通常自動で行われ、DNSの切り替えを使用します。EC2の場合、インスタンスをApplication Load BalancerとAuto Scalingグループの背後にある複数のAZに配置し、クロスAZヘルスチェックを使用して、異常なターゲットを検出して置き換えます。

Multi-Regionは、リージョン全体の障害に対する回復力を追加しますが、複雑さ（データレプリケーション、グローバルルーティング、コンプライアンス）が増します。決定基準:

• リージョン内で低レイテンシーの高可用性が必要で、低コストでマネージドの自動フェイルオーバーを望む場合は、Multi-AZを使用します。
• リージョン喪失に対するディザスタリカバリや、グローバルなアクティブ/アクティブ構成によるレイテンシー削減のためには、Multi-Regionを使用します。

設計上の考慮事項:

• DNS TTL: 低いTTL（例: 60秒）は、DNSベースの高速なフェイルオーバーに必要ですが、DNSクエリの負荷を増加させます。
• データの局所性とコンプライアンス: 一部のデータは特定のリージョン内に留まる必要があり、それに応じてレプリケーションと暗号化を設計します。
• コスト vs RTO/RPO: マルチリージョンのアクティブ/アクティブ構成はコストを増加させますが、RTOを最小化します。

フェイルオーバーのメカニズム（Route53ヘルスチェック、自動化）

自動フェイルオーバーは、ヘルスチェック、ルーティングポリシー、オーケストレーションを使用します。Route53は、ヘルスチェックとフェイルオーバー/加重/レイテンシールーティングをサポートしています。Route53のヘルスチェックを設定してエンドポイント（HTTP、TCP、またはCloudWatchアラーム）を監視し、プライマリに障害が発生したときにセカンダリリソースに切り替えるフェイルオーバーレコードセットを構成します。CLI更新例: aws route53 change-resource-record-sets --hosted-zone-id Z123456 --change-batch file://changes.json。DNS以外のアクションのフェイルオーバーをオーケストレーションするには、CloudWatchアラーム（アラームアクションがAWS Lambdaをトリガー）を使用します。

ロードバランサーとAuto Scalingの統合: ALB/NLBのターゲットグループのヘルスチェックは異常なインスタンスを削除し、Auto Scalingはそれらを自動的に置き換えます。データベースのフェイルオーバーには、サービスレベルのメカニズムに依存します。RDS Multi-AZまたはAuroraの自動フェイルオーバー、クロスリージョンでの昇格にはリードレプリカまたはAurora Global DBの制御された昇格を使用します。

2つの運用パターン:

• DNSフェイルオーバー (Route53): 実装は迅速ですが、DNSのTTLとクライアントのキャッシュに依存します。
• コントロールプレーンフェイルオーバー (Lambda/Step Functions + APIコール): 複雑なアプリケーション向けに、昇格、IP/EIPの再割り当て、Route53の更新を予測可能なシーケンスでオーケストレーションします。

RTO/RPOの計画、テスト、検証

RTOは最大許容ダウンタイム、RPOは最大許容データ損失です。各ワークロードに対して測定可能な目標を定義し、アーキテクチャの選択をそれに合わせます。同期レプリケーションはRPOを削減しますが、レイテンシーが増加する可能性があります。非同期レプリケーションはコストを削減しますが、潜在的なデータ損失のウィンドウが拡大します。ビジネスSLAを保持期間とレプリケーション頻度に変換します。RPO = レプリケーションラグ + バックアップ間隔、RTO = 検出時間 + フェイルオーバーオーケストレーション時間 + リカバリ検証時間。

テストは不可欠です。復元手順、DNSフェイルオーバー、アプリケーションの整合性を検証するDR訓練を定期的に実行します。分離されたアカウントまたはVPCに復元することでバックアップを検証します（再構築を自動化するためにCloudFormation/CloudFormation StackSetsまたはTerraformを使用）。テスト中にメトリクス（DNS伝播時間、復旧ポイント、アプリケーションレベルのチェック）を収集し、RTOを削減するために自動化を改善します。

一般的な落とし穴と判断基準

• スナップショットが回復可能性を意味すると仮定すること: 常に別の環境に復元し、アプリケーションの整合性を検証します。スナップショット取得前に、エンジンネイティブのスナップショットを使用するか、アプリケーションを静止させます。
• グローバルなクリティカルワークロードに対してシングルリージョンシステムを設計すること: リージョン障害が顧客に影響を与える場合は、マルチリージョンパターンまたはウォームスタンバイを選択します。データ主権を考慮してください。
• 設計でRTO/RPOを無視すること: ワークロードごとにRTO/RPOを把握し、それに応じてレプリケーション/バックアップを選択します。RPOをレプリケーション頻度に、RTOをオーケストレーションの自動化にマッピングします。
• 迅速なフェイルオーバーを妨げる長いDNS TTL: クリティカルなフェイルオーバーレコードには低いTTLを設定し、安定したルーティングが必要な場合にのみグローバルアクセラレーションを使用します。
• クロスリージョンレプリケーションのためのIAM/権限を無視すること: CRR、スナップショットコピー、バックアップボールトへのアクセスには、正しいロールとリソースポリシーが必要です。レプリケーションのIAMパスをテストします。
• レプリケーションラグとヘルスを監視しないこと: CloudWatchメトリクス（ReplicaLag、CPU、ネットワーク）を計測し、しきい値がRPOの制限に近づいたらアラートを発します。

実践的な問題: ユースケースシナリオ

AcmePaymentsは、us-east-1でPCIスコープのトランザクションAPIを実行しており、リージョン障害時にコアトランザクションデータに対して5分未満のRTOとほぼゼロのRPOを必要としています。

1. 高速なクロスリージョンレプリケーションのために、書き込み可能なプライマリをus-east-1に、セカンダリをeu-west-1に持つAurora Global Databaseを選択し、RTO=5分、RPO≈0と定義します。
2. リージョン内HAのために同期/リージョンごとのMulti-AZを有効にし（Auroraレプリカ + Multi-AZ）、フェイルオーバールーティングのためにヘルスチェックと低いTTL（60秒）を持つRoute53経由でDNSを公開します。
3. 保持期間とボールトロックを備えた追加のイミュータブルなコピーとして、クロスリージョンの自動スナップショットとAWS Backupのボールトコピーを使用します。
4. Step FunctionsとLambdaでフェイルオーバーのプレイブックを自動化し、レプリカの昇格を検証し、Route53レコードを更新し（aws route53 change-resource-record-sets）、スモークテストを実行し、障害が検出された場合はロールバックします。
5. 四半期ごとにDR訓練を計画し、分離されたVPCにバックアップを復元して実際のRTOとRPOを測定し、その後、自動化とスケーリングポリシーを改善します。

論理的根拠: 低レイテンシーのグローバルDB製品（Aurora Global）を、DNSベースのルーティングおよび自動化されたオーケストレーションと組み合わせることで、運用手順を反復可能かつテスト可能に保ちながら、厳しいRTO/RPOを満たします。定期的な検証により、バックアップとレプリカが実際に回復可能であることが保証されます。

← 監視、ロギング、および修復 · すべてのドメイン · デプロイ、プロビジョニング、および自動化 →

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

Amazonを閲覧 →