翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 事業継続計画 (BCP)
<a name="business-continuity-plan-bcp"></a>

 ディザスタリカバリ計画は、組織の*事業継続計画* (BCP) のサブセットである必要があり、スタンドアロンドキュメントであってはなりません。ワークロード*以外の*ビジネスの要素に対する災害の影響のためにワークロードのビジネス目標を達成できない場合、ワークロードを復元するための積極的なディザスタリカバリ目標を維持する意味はありません。例えば、地震により、eCommerce アプリケーションで購入した製品の輸送が妨げられる可能性があります。効果的な DR によってワークロードが機能し続ける場合でも、BCP は輸送ニーズに対応する必要があります。DR 戦略は、ビジネス要件、優先順位、コンテキストに基づいている必要があります。

## ビジネスへの影響分析とリスク評価
<a name="business-impact-analysis-and-risk-assessment"></a>

 *ビジネスへの影響分析*では、ワークロードの中断によるビジネスへの影響を定量化する必要があります。ワークロードを使用できない内部および外部の顧客への影響と、 がビジネスに与える影響を特定する必要があります。この分析は、ワークロードを使用可能にする必要がある速度と、許容できるデータ損失の量を決定するのに役立ちます。ただし、復旧目標は単独で行うべきではないことに注意してください。中断の可能性と復旧コストは、ワークロードにディザスタリカバリを提供することのビジネス価値を知らせるのに役立つ重要な要素です。

 ビジネスへの影響は時間に依存する場合があります。これをディザスタリカバリ計画に組み込むことを検討してください。たとえば、給与システムの中断は、すべての人が支払いを受ける直前にビジネスに非常に大きな影響を与える可能性がありますが、すべての人が既に支払いを受けた直後には影響が少ない可能性があります。

 災害の種類と地理的影響の*リスク評価*とワークロードの技術的実装の概要によって、災害の種類ごとに中断が発生する確率が決まります。

 非常に重要なワークロードでは、ビジネスへの影響を最小限に抑えるために、データレプリケーションと継続的なバックアップを備えたインフラストラクチャを複数のリージョンにデプロイすることを検討してください。重要度の低いワークロードの場合、有効な戦略は、ディザスタリカバリをまったく実施しないことです。また、一部の災害シナリオでは、災害が発生する可能性が低いことに基づいて、情報に基づいた決定としてディザスタリカバリ戦略を設定しないことも有効です。AWS リージョン内のアベイラビリティーゾーンは、すでに意味のある距離で設計されており、ロケーションの慎重な計画を立てています。そのため、最も一般的な災害は、1 つのゾーンにのみ影響し、他のゾーンには影響しません。したがって、AWS リージョン内のマルチ AZ アーキテクチャは、すでにリスク軽減ニーズの多くを満たしている可能性があります。

 ディザスタリカバリオプションのコストは、ビジネスへの影響とリスクを考慮して、ディザスタリカバリ戦略が適切なレベルのビジネス価値を提供するように評価する必要があります。

 この情報はすべて、さまざまな災害シナリオの脅威、リスク、影響、コスト、および関連する復旧オプションを文書化することができます。この情報は、各ワークロードの復旧目標を決定するために使用されます。

## 復旧目標 (RTO と RPO)
<a name="recovery-objectives-rto-and-rpo"></a>

 ディザスタリカバリ (DR) 戦略を作成する場合、組織は最も一般的に目標復旧時間 (RTO) と目標復旧時点 (RPO) を計画します。

![\[復旧目標の関係を示す画像。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/recovery-objectives.png)


*図 3 - 復旧目標*

 **目標復旧時間 (RTO)** は、サービスの中断からサービスの復旧までの最大許容遅延時間です。この目的は、サービスが利用できず、組織によって定義されている場合に許容される時間枠と見なされるものを決定します。

 このホワイトペーパーでは、バックアップと復元、パイロットライト、ウォームスタンバイ、マルチサイトアクティブ/アクティブの 4 つの DR 戦略について説明しています ([「 クラウドのディザスタリカバリオプション](disaster-recovery-options-in-the-cloud.md)」を参照）。次の図では、ビジネスは最大許容 RTO と、サービス復元戦略に支出できる上限を決定しています。ビジネス目標を考慮すると、DR 戦略のパイロットライトまたはウォームスタンバイは、RTO とコストの両方の基準を満たします。

![\[コストと複雑さとサービスの中断期間との関係として目標復旧時間を示すグラフ。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/recovery-time-objective.png)


*図 4 - 目標復旧時間*

 **目標復旧時点 (RPO)** は、最後のデータ復旧時点からの最大許容時間です。この目的は、最後の復旧時点からサービスの中断までの間に許容可能なデータ損失と見なされるものを決定し、組織が定義します。

 次の図では、ビジネスが最大許容 RPO と、データ復旧戦略に支出できる上限を決定しています。4 つの DR 戦略のうち、パイロットライトまたはウォームスタンバイ DR 戦略は、RPO とコストの両方の基準を満たしています。

![\[復旧ポイントの目的を、サービスの中断前のコストと複雑さとデータ損失の関係として示すグラフ。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/recovery-point-objective.png)


*図 5 - 目標復旧時点*

**注記**  
復旧戦略のコストが障害や損失のコストよりも高い場合は、規制要件などのセカンダリドライバーがない限り、復旧オプションを設定しないでください。この評価を行うときは、さまざまなコストの復旧戦略を検討してください。