AWSでBCP対策を組むとき、最初に決めるのは「どのサービスを使うか」ではなく「どの単位の障害に備えるか」です。1つのアベイラビリティゾーン（AZ）が止まる、東京リージョン全体が使えない、ランサムウェアや誤操作でデータそのものが壊れる、拠点からAWSへの回線が切れる。この4つは守り方がまったく違い、マルチAZ構成は1つ目にしか効きません。
この記事では、AWS Well-Architected フレームワーク、DRホワイトペーパー、AWSの障害事後報告を根拠に、障害の単位ごとの構成、DR戦略の選び方と費用、大阪リージョンの制約、切り替え当日に失敗しない設計、着手の順番を整理します。Route 53のフェイルオーバー設定やバックアップの削除防止など、そのまま使える設定例も載せました。サービスの提供状況や料金は2026年10月時点の公式情報で確かめた値です。
まとめ：AWSのBCP対策で決める順番と最初に押さえる5つの要件
- AWSが責任を持つのは基盤の回復力までで、どのAZ・リージョンに置き、どう復旧するかは利用者の責任です。DR計画は会社のBCPの一部として作ります。
- AZ障害には、残存AZで処理を継続できる容量と切り替え設定を備えたマルチAZ構成を使います。国内でリージョン障害に備える場合は東京と大阪の2リージョン構成、ランサムウェアや誤削除には別アカウントへのバックアップと削除防止（AWS Backup Vault Lock）が必要です。
- DR戦略はバックアップ＆リストア、パイロットライト、ウォームスタンバイ、マルチサイト・アクティブ/アクティブの4つ。業務ごとのRTO・RPOを両方満たす戦略の中から費用を比べて選び、必要以上に厳しい戦略は採りません。
- 切り替え手順は、DNSレコードの書き換えや新規インスタンスの起動に頼らない形にします。どちらもコントロールプレーンの操作で、障害時に動かないことがあります。
- 大阪リージョンは東京より使えるサービスが少なく、Amazon ConnectやAmazon WorkSpacesは提供されていません。復旧先で動くかを構成ごとに確かめます。
- 着手は「業務の棚卸し → 障害単位への割り当て → 戦略選定 → 復旧先の整備 → 初回訓練」の5段階。訓練で測った切り替え時間が、手順書と予算を見直す根拠になります。
AWSの責任範囲とBCP・DR計画の切り分け：共有責任モデルで見る利用者の作業
AWSのDRホワイトペーパーは、回復力を「AWSと利用者の共有責任」と定義しています。AWSが負うのはクラウドの回復力（ハードウェア、ネットワーク、施設）で、利用者が負うのはクラウドにおける回復力です。たとえばAmazon EC2を複数のAZに配置するのは利用者の作業で、データのバックアップ・バージョニング・複製の方針も利用者の責任と明記されています。
地震については、AWSが「日本の災害対策関連情報」で、国内データセンターに免震装置を採用し日本の震災に関する規格に準拠させていると説明しています。ただしこれは建物の話で、単一AZのEC2が止まらない保証ではありません。
同じホワイトペーパーは、DR計画は独立した文書ではなく会社のBCPの一部であるべきだとも書いています。地震で商品を配送できなければ、ECサイトだけ数分で復旧しても事業は止まったままだからです。業務ごとの目標復旧時間（RTO）を先にBCP側で決め、そのうえでIT側の構成を選ぶ、という順番になります。BCPそのものの決め方はBCPの意味とRTO・RLOの決め方、情報システム部門の範囲はIT-BCPと通常BCPの違いで扱っています。
重要度の低い業務について、ホワイトペーパーは「DRをまったく持たないことも妥当な戦略になりうる」と明言しています。全システムをマルチリージョンにするのは、費用の面でもBCPの考え方の面でも誤りです。
障害の単位ごとの備え：AZ・リージョン・データ破損・回線の4つで変わる構成
4つの障害単位と、それぞれに効く対策を先に一覧にしておきます。上の行の対策は下の行の障害を防げない、という関係に注意してください。
| 障害の単位 | 効く対策 | その対策で防げないもの |
|---|---|---|
| AZ障害 | マルチAZ・ゾーンシフト | リージョン障害・データ破損 |
| リージョン障害 | 東京と大阪の2リージョン | 複製されたデータ破損 |
| ランサムウェア・誤削除 | 別アカウント＋Vault Lock | 復旧までの停止時間 |
| 回線障害 | Direct Connect＋VPNの2経路 | AWS側の障害 |
AZ障害：マルチAZ構成とEC2のSLA99.99%が成り立つ前提条件
Amazon EC2のSLAは2本立てです。単一インスタンスの稼働率は月間99.5%、同じリージョンの2つ以上のAZにまたがって配置したEC2は99.99%が対象になります（Amazon Compute SLA、2022年5月25日更新）。99.99%を名乗れるのはマルチAZに置いたときだけです。各サービスの稼働率はAWSのSLA一覧に、冗長化と二重化の違いや構成の種類は冗長化の種類と設計判断にまとめています。
東京リージョンでは2019年8月23日、1つのAZで空調設備の管理システムが故障し、オーバーヒートでEC2サーバーの一部が停止しました（日本時間12時36分発生、15時21分に冷却装置が復旧、18時30分までに大部分が回復）。事後報告によると、一部のハードウェアはそのまま退役になっています。さらに、Application Load BalancerをAWS WAFやスティッキーセッションと組み合わせていた一部の利用者では、複数AZで動かしていたアプリケーションにもエラーが出ました。マルチAZにしても、負荷分散の設定次第で単一AZの障害が波及しうるということです。
AZ障害の切り離しには、Amazon Application Recovery Controller（ARC）のゾーンシフトが使えます。対応リソースのトラフィックを、障害の出たAZから同じリージョンの健全なAZへ一時的に移す機能です。ARCの機能と料金の全体像はAmazon Application Recovery Controller（ARC）の解説、AZの割り当てや東京リージョン固有の注意点はAWS東京リージョン（ap-northeast-1）の解説を参照してください。
リージョン障害：東京と大阪の2リージョン構成と大阪で使えないサービス
リージョン全体が使えない事態への備えには、別リージョンへの複製が必要です。国内にデータを置く要件がある場合、復旧先の候補は大阪リージョン（ap-northeast-3）になります。大阪は2021年3月1日に、それまでのローカルリージョンから標準のリージョンへ拡張され、現在は3つのAZを持ちます（東京は4つ。AWSのリージョンとアベイラビリティーゾーンで確認できます）。
注意したいのは、大阪で使えるサービスが東京より少ない点です。AWSのリージョン別サービス一覧が参照しているデータ（2026年10月時点でも最新は2025年11月13日版のJSON）を集計すると、東京の189サービスに対して大阪は150サービスでした。東京にあって大阪に無いもののうち、BCPに直接関わるのは次のサービスです。
- Amazon Connect（コンタクトセンター）とAmazon WorkSpaces（仮想デスクトップ）。災害時の電話窓口や在宅勤務の基盤を東京で組んでいる場合、大阪では同じ構成を作れません。
- Amazon MemoryDB、AWS App Runner、Amazon Lightsail。これらで動くアプリケーションは、大阪では別サービスへの置き換えが前提になります。
- AWS Resilience Hub。評価ツールなので東京側で使えば足ります。
一方、AWS Backup、AWS Elastic Disaster Recovery、ARC、AWS Fault Injection Service、Amazon Aurora、Amazon DynamoDB、AWS Direct Connectは大阪でも提供されています。表は随時更新されるため、構成を決める前にAWS CLIで公開パラメータを引いて確かめてください。次のコマンドは、指定したサービス（例はElastic Disaster Recovery）を提供しているリージョンの一覧を返します。
aws ssm get-parameters-by-path \
--path /aws/service/global-infrastructure/services/drs/regions \
--region ap-northeast-1 \
--query 'Parameters[].Value'問い合わせ先は東京を指定します（このパスは大阪では照会できません）。結果に ap-northeast-3 があれば大阪で使えます。drs を connect などに替えれば、ほかのサービスも調べられます。
ランサムウェア・誤削除：複製では戻せないデータ破損とVault Lockの設定
Well-Architected の信頼性の柱（REL13-BP02）は、継続的なデータ複製はある種の災害からは守るが、データの破損や破壊からは守れない場合がある、と書いています。暗号化されたファイルや誤って消したテーブルは、そのまま大阪にも複製されるからです。バージョニングやポイントインタイムリカバリを併用し、復旧先でもバックアップを取る必要があります。
攻撃者が管理者権限を奪った場合に備えるなら、AWS Backup Vault Lock を使います。ガバナンスモードは十分なIAM権限を持つ利用者なら解除できます。コンプライアンスモードは、最低72時間（3日）の猶予期間が過ぎると、復旧点が残っている間は利用者もAWSもロック設定を変更・削除できず、通常の削除操作では保持期間が満了するまでバックアップを消せません。裏返しとして、保持期間を「常時」にした復旧点を入れると費用が払い続けになる、とAWSのドキュメントは注意しています。例外はアカウントの閉鎖で、閉鎖後90日以内に再開しなければ、Vault Lockがあってもボールトの中身は削除されます。
コンプライアンスモードのロックは、--changeable-for-days（猶予日数）を付けて設定します。この引数を省くとガバナンスモードになる、という切り分けです。次の例は、大阪のバックアップ用ボールトに、猶予3日・最短7日・最長35日の保持を設定します。
aws backup put-backup-vault-lock-configuration \
--backup-vault-name dr-vault-osaka \
--changeable-for-days 3 \
--min-retention-days 7 \
--max-retention-days 35 \
--region ap-northeast-3猶予期間の3日間は設定を取り消せるので、その間にバックアッププランの保持日数が最短・最長の範囲に収まっているかを確かめます。範囲外の保持期間を指定したバックアップジョブは失敗するため、ロック後に既存プランの見直しが必要になる場合があります。
さらに一段強い選択肢が、論理的にエアギャップされたボールト（logically air-gapped vault）です。コンプライアンスモードのVault Lockが最初から有効で、マルチパーティー承認と組み合わせると、ボールトを持つアカウントに入れなくなっても、閉鎖後の一定期間は別のアカウントから復元できます。AWS Backupの基本操作はAWS Backupの対応サービスと復元手順、バックアップ方式の選び方はシステムバックアップの方式の選び方、復旧の実例は佐賀大学のランサムウェア被害と業務再開で扱っています。
回線障害：Direct Connectを単一経路にせずインターネットVPNを予備にする
オンプレミスの拠点からAWSを使っている場合、AWS側が無事でも回線が切れれば業務は止まります。2021年9月2日には、東京リージョン向けのAWS Direct Connectで、日本時間7時30分ごろから接続の問題とパケットロスが発生し、13時42分に解消しました。事後報告によると、一部の利用者がDirect Connectのバックアップとして使っていたAWS VPN接続や、リージョンへのインターネット接続、他リージョンへのDirect Connectは影響を受けていません。Direct Connectだけに頼らず、インターネットVPNを予備経路にする方法があります。採否を決める材料は、必要な帯域と遅延、既存インターネット回線の余力、機器と運用の費用の3つです。構築手順はDirect Connectの構築手順にあります。
4つのDR戦略とAWSでの実装：RTO・RPOの目安と復旧先で常時動かすもの
リージョンをまたぐDR戦略について、Well-Architected REL13-BP02は4つの選択肢とRPO・RTOの目安を示しています。下に行くほど費用と複雑さが増え、RTO・RPOは短くなります。
| 戦略 | RPOの目安 | RTOの目安 | 復旧先で常時動かすもの | 主なAWSサービス |
|---|---|---|---|---|
| バックアップ＆リストア | 数時間 | 24時間以内 | バックアップのみ | AWS Backup、S3レプリケーション |
| パイロットライト | 数分 | 数十分 | データベース・ストレージ | Aurora Global DB、AMIコピー |
| ウォームスタンバイ | 数秒 | 数分 | 縮小した本番一式 | Auto Scaling、Route 53 |
| マルチサイト・アクティブ/アクティブ | ほぼゼロ | ゼロに近づけられる | 本番と同規模の一式 | DynamoDB グローバルテーブル、ARC |
REL13-BP02は「必要以上に厳しい戦略を実装するのは避けるべきだ」とも書いています。マルチサイトでは、2つのリージョンで同じレコードに書き込んだときの競合を避けるか処理する仕組みが必要です。業務ごとのRTOとRPOを両方満たす戦略の中から、構築・運用の費用を比べて選びます。社内システムでも、許容できるデータ損失が小さければ数時間おきのバックアップでは要件を満たせません。DR計画全体の作り方とRPO・RTOの考え方はDR対策の構成4パターンとDR計画の作り方で解説しています。
Elastic Disaster Recoveryのパイロットライト型復旧と月額
パイロットライトかウォームスタンバイで迷う場合、AWS Elastic Disaster Recovery（DRS）が候補になります。REL13-BP02の説明では、継続的なデータ保護でRPOを秒単位、RTOを分単位（DRSのドキュメントでは通常5〜20分。差はOSの起動時間で、Linuxは平均5分、Windowsは平均20分ほどで起動する）にしつつ、復旧先に置くのはデータ複製に必要なリソースだけなので、費用はパイロットライト並みに抑えられます。料金は複製元サーバー1台あたり1時間0.028米ドル（2026年10月時点。30日で約20米ドル）で、テスト起動や復旧時の起動、ポイントインタイムリカバリが含まれます。これとは別に、継続的な複製とテスト・復旧に使うEC2、EBSボリューム、スナップショットなどの料金がかかり、構成によってデータ転送料も発生します。
DRS本体の料金だけを台数で掛けると、次の規模感になります。複製用のEC2やEBSは構成で大きく変わるため、表には含めていません。
| 複製元サーバーの台数 | DRS利用料（30日） | 別途かかるもの |
|---|---|---|
| 1台 | 約20米ドル | 複製用EC2・EBS・転送料 |
| 10台 | 約202米ドル | 複製用EC2・EBS・転送料 |
| 30台 | 約605米ドル | 複製用EC2・EBS・転送料 |
DRSはAWS上のサーバーだけでなく、オンプレミスのサーバーも複製元にできます。自社のサーバールームにある業務システムをそのまま大阪や東京のリージョンへ複製し、被災時だけAWS上で起動する、という使い方ができるため、クラウド移行が済んでいない企業のBCPにも向きます。ただし秒単位のRPOが成り立つのは、複製元からAWSへの回線帯域がディスクへの書き込み速度を上回っている間だけです。ドキュメントの例では、毎秒10MBずつ書き込むサーバーが10台あれば、少なくとも毎秒100MBの帯域が必要になります。基盤をクラウドとオンプレミスのどちらに置くか自体の判断はBCP対策はクラウドとオンプレミスどちらに置くかで整理しています。
切り替えで失敗しない設計：コントロールプレーン依存と復旧先の起動容量
復旧手順のコントロールプレーン依存の削減とRoute 53フェイルオーバー設定
AWSのサービスは、リソースを作成・変更・削除する管理用API（コントロールプレーン）と、日々のトラフィックを処理する部分（データプレーン）に分かれています。REL11-BP04は、復旧時にはコントロールプレーンの操作を最小限にし、データプレーンの操作で切り替えるよう求めています。避けるべきパターンの最初に挙がっているのが「DNSレコードの変更でトラフィックを振り替えること」です。
理由はAmazon Route 53の構造にあります。DNSの問い合わせに答え、ヘルスチェックを評価するデータプレーンは、世界中に分散した構成です。Route 53のSLAはホストゾーンの月間稼働率100%を対象にしています。一方、レコードを作成・変更する管理APIとコンソールは米国東部（バージニア北部、us-east-1）の1リージョンにあり、SLAの対象外です。東京から大阪へ逃げる手順なのに、手順の途中でバージニアのAPIを呼んでいる、という依存が生まれます。
同じ構造はIAM、AWS Organizations、Amazon CloudFrontにもあります。AWSのホワイトペーパー「AWS Fault Isolation Boundaries」によると、これらのコントロールプレーンの所在もus-east-1です。障害当日にIAMロールを新しく作る、Route 53のレコードを書き換える、といった操作が手順書に入っていたら、平常時のうちに済ませておく作業に移します。具体的には次の置き換えです。
- Route 53のレコード変更 → 事前に作ったフェイルオーバーレコードとヘルスチェック、またはARCのルーティングコントロール（データプレーンのAPIで切り替える）
- 障害時のAuto Scalingによる台数追加 → 復旧先に必要台数を事前に起動しておく
- 障害時のIAMロール・ロードバランサー・DynamoDBテーブルの作成 → すべて平常時に作成し、訓練で使っておく
1つ目の「事前に作ったフェイルオーバーレコード」は、平常時に次の2つを登録しておくだけで動きます。東京側のヘルスチェックが失敗すると、Route 53のデータプレーンが自動で大阪側のレコードを返すので、障害当日に管理APIを呼ぶ必要がありません（DNSフェイルオーバーの設定）。まず東京側のエンドポイントにヘルスチェックを作ります。
aws route53 create-health-check \
--caller-reference tokyo-app-2026-10 \
--health-check-config Type=HTTPS,FullyQualifiedDomainName=tokyo.example.com,ResourcePath=/health,RequestInterval=30,FailureThreshold=3返ってきたヘルスチェックIDを主レコードに付け、東京を PRIMARY、大阪を SECONDARY として登録します。IPアドレスは説明用の値です。
{
"Comment": "東京を主、大阪を副にするフェイルオーバーレコード",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"SetIdentifier": "tokyo-primary",
"Failover": "PRIMARY",
"TTL": 60,
"HealthCheckId": "11111111-2222-3333-4444-555555555555",
"ResourceRecords": [{ "Value": "203.0.113.10" }]
}
},
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"SetIdentifier": "osaka-secondary",
"Failover": "SECONDARY",
"TTL": 60,
"ResourceRecords": [{ "Value": "198.51.100.20" }]
}
}
]
}aws route53 change-resource-record-sets \
--hosted-zone-id Z0123456789EXAMPLE \
--change-batch file://failover.jsonこの2つのコマンドはどちらもコントロールプレーンの操作なので、平常時に流して訓練で切り替わることを確かめておきます。TTLを60秒にしているのは、切り替え後に古い応答がキャッシュに残る時間を短くするためです。Route 53のレコード設計やCLIでの構築全体はAmazon Route 53のルーティング設計と構築手順で解説しています。
復旧先の起動容量とサービスクォータの事前確保：us-east-1障害の教訓
コントロールプレーンへの依存が実際に効いた例が、2025年10月19日から20日（米国太平洋夏時間）のus-east-1の障害です。原因はDynamoDBのDNS管理システムの潜在的な不具合で、リージョンのエンドポイントに空のDNSレコードが設定されました。AWSの事後報告によると、障害前から動いていたEC2インスタンスは期間中ずっと正常でしたが、新しいインスタンスの起動は2時25分から10時36分まで失敗し、「request limit exceeded」か「insufficient capacity」のエラーが返りました。
この報告から読み取れるのは、動いているものは止まらず、これから起動するものが起動できなかった、ということです。障害が起きてから復旧先でEC2を起動するパイロットライトは、まさにこの「起動」に依存しています。新規起動の失敗を許容できない業務では、必要な処理容量を復旧先で事前に起動しておきます（ウォームスタンバイ）。EC2のオンデマンドキャパシティ予約は容量不足への備えにはなりますが、予約枠へインスタンスを起動する操作自体はAPI呼び出しなので、事前起動と同じ扱いにはできません。予約は使わなくても料金がかかる点にも注意します。
Service Quotas（サービスの上限値）にはリージョン単位のものがあります。東京で上限緩和を申請していても、大阪は既定値のままです。インスタンス数やEBSボリューム、Elastic IPの上限を、本番と同規模に起動する前提で大阪側でも引き上げておきます。
リージョン単位のリソースと復旧先への複製準備：AMI・KMS・シークレット
リージョンをまたいで自動では複製されないものが、切り替え当日に見つかることがあります。AMI、KMSキー（マルチリージョンキーを含む）、Secrets Managerのシークレット、ECRのコンテナイメージ、ACMの証明書は、いずれもリージョン単位のリソースです。AMIのコピー、ECRのクロスリージョンレプリケーション、KMSのマルチリージョンキー、Secrets Managerのレプリカといった仕組みで平常時から大阪へ置いておき、構成はCloudFormationやTerraformで両リージョンに同じものを作れるようにします。IaCの導入判断はIaCの仕組みと導入判断にまとめています。
AWSでBCP対策を始める5段階：業務の棚卸しから初回の切り替え訓練まで
ここまでの要素を、着手の順番に並べ直します。最初から全業務をマルチリージョンにしようとすると費用と運用の両方で破綻するため、業務単位で小さく始め、訓練の実測値で次の手を決めます。
段階1と2：業務ごとのRTO・RPOの決定と障害の単位への割り当て
段階1では、AWS上で動くシステムを業務単位で書き出し、BCP側で決めたRTO・RPOを1行ずつ付けます。数字が決まらない業務は、止まったときに1時間あたり何が失われるか（受注、請求、問い合わせ対応）から逆算するのが手早い方法です。段階2では、各業務がAZ・リージョン・データ破損・回線のどの障害で止まるかを、前述の4つの単位で割り当てます。ここで「データ破損にだけ備えればよい業務」が見つかると、リージョン複製をせずにバックアップとVault Lockで済ませられます。
段階3と4：DR戦略の選定と復旧先リージョンのサービス・クォータ整備
段階3では、4つのDR戦略のうちRTO・RPOを満たすものを業務ごとに選びます。段階4では、選んだ戦略に合わせて大阪側を整えます。作業の中身は、提供サービスの確認（前述のCLI）、Service Quotasの引き上げ、AMI・KMSキー・シークレット・コンテナイメージの複製、Route 53フェイルオーバーレコードの登録、IaCでの両リージョン同時構築です。ここまでを平常時に終えて初めて、切り替え手順からコントロールプレーンの操作を外せます。
段階5：初回の切り替え訓練で測ったRTOを手順書と予算に戻す
段階5では、検証環境かDRSのドリルで初回の切り替えを実施し、かかった時間と詰まった操作を記録します。目標RTOに届かなければ、戦略を1段上げるか（パイロットライトからウォームスタンバイへ）、手順を自動化するかの二択です。どちらにするかは費用の差で決め、その結果を翌年度の予算と手順書に反映させます。
訓練と見直し：DRSのドリル・FISの障害注入・Resilience Hubの使い分け
内閣府の事業継続ガイドライン（令和5年3月）は、教育・訓練を年次で行うだけでなく、人事異動や体制変更のときにも実施し、目標と達成度の評価方法をあらかじめ決めておくよう求めています。AWSの構成についても、手順書を書いただけで切り替えが成功する保証はありません。
- DRSのドリル：複製元のサーバーを止めずに、復旧先でインスタンスを起動する訓練ができます。起動にかかった時間は、RTOを見積もるときの実測値として使えます。
- AWS Fault Injection Service（FIS）：EC2の停止やAZ単位の障害を実際に発生させる障害注入のサービスです。実環境のリソースに実際の操作を行うため、AWSは本番の前に検証環境で実施するよう強く推奨しています。
- AWS Resilience Hub：アプリケーションごとに回復力の目標（RTO・RPO）を定め、現在の構成がそれを満たすかを評価し、Well-Architected に基づく改善案を出します。前述のとおり大阪では提供されていないので、東京側で実行します。
訓練で確かめるべきなのは、切り替えにかかった時間だけではありません。手順書の各操作がコントロールプレーンとデータプレーンのどちらに当たるかを、1行ずつ確認します。ここで見つかったコントロールプレーンの操作が、障害当日に止まる可能性のある手順です。
AWSでのBCP対策が効かない場面と、構築を外部に任せるかの判断基準
AWS側の構成を固めても、次の条件に当てはまるとBCPとして機能しません。
- 業務の止まる原因がITの外にある：工場の生産ライン、物流、店舗、出社が必要な対面業務。DRホワイトペーパーの配送の例のとおり、システムだけ復旧しても業務は再開しません。
- 拠点からAWSへの経路が1本しかない：Direct Connectが1回線だけ、インターネット回線が1社だけといった構成では、リージョンを2つ持っても社員が使えません。
- SaaSに業務の中心がある：Microsoft 365やSalesforceのデータ保護は各SaaSとの責任分界で決まり、AWS側の構成では守れません。
- 手順を回せる人がいない：マルチリージョン構成には、切り替えを判断・実行できる担当者と定期的な訓練が必要です。訓練の頻度は業務要件に応じて定め、構成や担当者の変更時にも実施します。体制が組めないなら、バックアップ＆リストアとDRSのように自動化の比重が大きい構成から始める方が現実的です。
サーバー単位の対策はサーバーのBCP対策とRTO・RPOの決め方にあります。
構築を社内で進めるか外部へ任せるかは、3つの条件で判断できます。復旧先リージョンをIaCで同じ構成に作れる人がいるか、切り替え訓練を年1回以上回す工数を確保できるか、障害時に切り替えを判断する権限者が決まっているか。どれか1つでも欠けるなら、設計とIaCでの構築、訓練手順書の作成までを外部に依頼し、運用だけを社内で引き取る形が現実的です。一創ではインフラ構築（AWS・Google Cloud・Azure）として、こうしたマルチAZ・マルチリージョン構成の設計と構築の相談を受け付けています。逆に、ウォームスタンバイ以上の構成をすでに社内で運用していて訓練も回っているなら、外部に任せる理由は薄くなります。
よくある質問
AWSでBCP対策を検討する担当者から寄せられやすい質問に、ここまでの内容を前提に答えます。
マルチAZ構成にしておけばBCP対策として十分ですか？
AZ単位の障害には有効ですが、リージョン全体の障害や、ランサムウェア・誤削除によるデータ破損は防げません。データを別AZへ複製する構成では、誤削除や破損も複製先へ反映される場合があります。業務のRTO・RPOに応じて、別リージョンへの複製と削除できないバックアップを組み合わせます。
AWSのパイロットライトとウォームスタンバイの違いは何ですか？
パイロットライトはデータベースなどデータの複製に必要な部分だけを復旧先で動かし、アプリケーションサーバーは切り替え時に起動します。ウォームスタンバイは縮小した規模の本番環境一式を常時動かしているため、切り替えてすぐに処理を受けられます。AWSの目安ではパイロットライトがRTO数十分、ウォームスタンバイがRTO数分です。
東京と大阪のリージョンを両方使えば同時に止まる心配はありませんか？
東京と大阪はそれぞれ独立したリージョンとして設計されていますが、切り替え手順がus-east-1にあるRoute 53やIAMの管理APIに依存していると、その部分が別の障害点になります。また大阪ではAmazon ConnectやAmazon WorkSpacesなど一部のサービスが提供されていないため、東京と同じ構成を作れるかを事前に確認する必要があります。
AWS Backupでランサムウェア対策になりますか？
バックアップを別アカウントへコピーし、AWS Backup Vault Lockをコンプライアンスモードで設定すれば、猶予期間（最低72時間）の経過後は、管理者権限を奪われても通常の削除操作ではバックアップを消せなくなります。同じアカウントの通常のボールトに置いただけでは、権限を持つ攻撃者に消される可能性があります。
オンプレミスのサーバーをAWSで災害対策できますか？
AWS Elastic Disaster Recoveryを使うと、オンプレミスのサーバーをAWSのリージョンへ継続的に複製し、被災時にAWS上で起動できます。平常時に復旧先で動かすのは複製用の最小限のリソースだけなので、DRサイトを自前で持つ構成に比べて維持費を抑えられる場合があります。比較にはDRSの利用料に加え、複製・訓練・復旧で使うAWSリソースと回線の費用を含めてください。複製元のサーバーを止めずに起動訓練もできます。
関連記事
- DR対策とは？構成4パターンのRPO・RTO目安とDR計画の作り方
- BCP対策はクラウドとオンプレミスどちらに置くか｜責任分界とSLAで決める判断基準
- BCPとは？事業継続計画の意味と防災計画との違い、RTO・RLOの決め方
- AWS東京リージョン（ap-northeast-1）とは｜AZ構成と指定方法・大阪との使い分け
- AWS Backupとは？対応サービス・料金・バックアッププラン作成と復元手順を解説
- Amazon Application Recovery Controller（ARC）とは？機能・料金・Route 53 ARCとの違いを解説
- Amazon Route 53とは：DNS・ドメイン登録・ルーティング設計とAWS CLI構築手順を実装者目線で解説
