📖

re:Invent 2025: AWS Storageによるデータ保護とレジリエンス戦略 - 3-2-1-1-0フレームワークと復旧実装

2025/12/03に公開

AWS

reinvent2025sessio

tech

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！

re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください

📖re:Invent 2025: AWS re:Invent 2025 - Data protection and resilience with AWS Storage (STG338)

この動画では、AWS Storageを活用したデータ保護とレジリエンスについて、Danny Johnston、Brian Benscoter、Steve Devosの3名が解説しています。冒頭でMaerskが2017年に受けた壊滅的なサイバー攻撃の事例を紹介し、9分間で49,000台のラップトップと3,500台のサーバーが破壊された実態を説明。データレジリエンスの核心として、高可用性とデータ保護の違い、3-2-1-1-0フレームワーク、マルチゾーン・マルチリージョン戦略を詳述しています。AWS Backup、Elastic Disaster Recovery、論理的エアギャップvaultなど具体的なサービスを用いた実装方法を示し、RPO/RTOの設定、復旧テストの重要性、Sheltered Harbor認証についても言及。最終的に、デジタル絶滅レベルのイベントを想定した包括的な復旧戦略の構築を推奨しています。

※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。

本編

セッション開始：AWS Storageによるデータ保護とレジリエンスの重要性

皆さん、おはようございます。セッションSTG338、AWS Storageによるデータ保護とレジリエンスへようこそ。簡単に自己紹介させていただきますと、私の名前はDanny Johnstonと申します。過去5年間、私はAWSにおいて、グローバル金融サービス業界の大手のお客様がサイバーイベントリカバリープラットフォームとソリューションを構築するお手伝いをしてまいりました。ですので、本日のディスカッションについて大変ワクワクしております。本日はBrianとSteveにご参加いただけることを大変嬉しく思います。

やあ、私はBrian Benscoterです。私はヘルスケアとライフサイエンス分野のPrincipal Solutions Architectですが、クラウドオペレーションとデータ保護にも情熱を持っています。皆さんこんにちは、Steve Devosです。28年間オンプレミスのバックアップソリューションを構築した後、8年前にAWSに入社し、基本的にAWS Backupサービスを構築してまいりました。私はPrincipal Engineerで、本日皆さんとデータ保護について議論できることを楽しみにしています。素晴らしい、ありがとうございます。

それでは、今朝は盛りだくさんのアジェンダをご用意しております。まずプロアクティブディフェンスについてお話しし、なぜ今日の脅威の状況に対応するためにプロアクティブディフェンスを持つことがそれほど重要なのかについてお話しします。データレジリエンスという用語が何を意味するのかについてお話しします。レジリエンスを強化するための方法論と戦略を見ていきます。サイバーイベントリカバリーに対するAWSのアプローチを見て、そしてセッションの最後に具体的な次のステップとアクションでまとめます。

プロアクティブディフェンス：サイバー攻撃の現状と内部脅威のリスク

それでは始めましょう、プロアクティブディフェンスです。外部および内部の脅威から最もミッションクリティカルなデータ資産を保護することがなぜそれほど重要なのか、皆さんに改めてお伝えする必要はないでしょう。さて、これを示す膨大な資料が存在しますが、私が何度も参照する一つのレポートは、SophosによるThe State of Ransomwareです。The State of Ransomware Across Financial Services in 2024というタイトルのレポートで、Sophosは組織の59%が何らかの形のサイバー攻撃を経験したと推定しています。それらの攻撃のほぼ半数が成功しました。

しかし、私が本当に懸念しているのは、組織が身代金を支払った場合でさえ、データの約70から80%しか取り戻すことができなかったということです。FBIやGCHQ、NCCといった私たちのセキュリティ機関は身代金を支払わないことを推奨しているだけでなく、たとえ身代金を支払ったとしても、それは必ずしもすべてのデータ資産の回収を保証するものではないのです。そしてその上に、各インシデントからの復旧コストが現在平均で約150万ドルから160万ドルになっているということを積み重ねていくわけです。しかし、ご存知の通り、復旧コストにはこれらの攻撃によって受けるレピュテーションダメージは含まれていません。

そして、評判の毀損というものを考慮に入れ始めると、そのコストは本当に恐ろしいものになり得ます。実際、Cybersecurity Venturesの推定によると、今年末までに、世界中の全産業におけるサイバー犯罪のコストは約10.5兆ドルに達するとされています。これは、違法薬物取引全体よりもさらに利益が大きいと彼らは主張しています。実際、もしサイバー犯罪が国だとしたら、GDPを指標として使った場合、世界で3番目に大きな国になるだろうと彼らは主張しているんです。ですから、本当に驚くべき、目を見張るような主張や統計がそこにはあるわけです。

しかし、私たちはデータに対する内部的な脅威についても非常に注意深く考慮する必要があります。不満を持った従業員、その他の内部の悪意ある行為者、あるいは重要な資料にアクセスできる善意の従業員でさえ、偶発的なファイルの削除のような人的ミスを通じて、組織の安定性を本当に危険にさらす可能性があるんです。あるいは、約18ヶ月前にオーストラリアのUniSuperで見られたケースのように、偶発的なアカウント削除もあります。そしてその人的ミスは、1,450億ドル相当の年金基金を危険にさらし、それによってオーストラリアの64万人の高齢者の将来の貯蓄と未来を危険にさらしたのです。

AP Moller Maerskのサイバー攻撃事例：デジタル絶滅レベルのイベントから学ぶ教訓

しかし、イギリスの規制当局が「デジタル絶滅レベルのイベント」と呼ぶものを実際に経験するというのはどういうことなのでしょうか？現場での実際のビジネスへの影響はどのようなもので、壊滅的な侵害が発生した場合にビジネスを回復するためにどのようなステップを踏むことができるのでしょうか？私たちは、この分野の業界リーダーである、AP Moller Maerskの元CIOと協力しています。彼は2017年6月にまさにそのような攻撃を経験しました。World Economic Forumは、この攻撃を現在までで最もコストがかかり壊滅的なサイバー攻撃として分類しました。あまりにも重大だったため、他の組織がMaerskの不幸な経験から学べるように、彼らは現在外部向けのケーススタディを公開しています。そして、その経験についてはこの後すぐにお話しします。

しかしその前に、Maerskについて少し背景をお話しします。彼らは巨大な組織です。Maerskは世界の貿易全体の20%を担っています。私たちの目の前に見えるこの船は、彼らの750隻の船団のうちの1隻で、これらの船はそれぞれ驚異的な19,000個のコンテナを運ぶことができます。実際、これらの運搬船の新世代は最大24,000個のコンテナを運ぶことができます。

彼らは世界中で74の港とターミナルを所有・運営しており、すべての港は毎日約5隻のこれらの船を受け入れることが予想されます。つまり、1つの港あたり1日約10万個のコンテナということです。つまり、これは途方もない規模の事業なんです。

さて、ロシアがウクライナに侵攻する5年前、彼らはサイバー兵器でウクライナを攻撃していました。その中で最大のものが2017年6月28日に実行されました。ロシアはウクライナの国税庁プラットフォーム、キエフにあるM.E.Docと呼ばれるシステムとプラットフォームを標的にしました。攻撃の時点でそのプラットフォームを利用していた組織は影響を受け、合計で約3,380の組織が被害に遭いました。しかし、Maerskが他の組織と一線を画しているのは、他の組織が学べるように、自分たちの経験について非常に透明性を持って公開したことです。それでは、その日何が起こったのか、その様子を描いてみたいと思います。

攻撃が発生してから最初の9分以内に、ほとんどの被害はすでに発生していました。ネットワークはダウンしました。オンラインバックアップは完全に破壊され、使用不能になりました。49,000台のラップトップが完全に使い物にならなくなり、3,500台のサーバーが破壊されました。さらに1,200のアプリケーションが破壊され、1,000のアプリケーションにはアクセスできませんでした。なぜなら、アクセスすると再感染につながるからです。

コミュニケーション手段としては、攻撃直後の数時間から数日間は、WhatsAppを使うしかありませんでした。なぜなら、彼らのBlackBerryは完全にワイプされていたからです。実際、オフィスに入ることすらできませんでした。なぜなら、オフィスパスがITシステムと連動していたからです。つまり、特に世界貿易の20%を担っている企業にとっては、非常に悲惨で過酷な状況に置かれたわけです。

さて、次に起こったことは、設計によるものではなく、まさに幸運によるものでした。たまたま、ウクライナでの攻撃の時点で、ナイジェリアでは大規模な嵐により停電が発生していました。あるシステム、x86ボックスが、停電のために攻撃の時点では明らかにオフラインになっていたのです。しかし、それ以上に幸運だったのは、このx86ボックスにActive Directoryのコピーがあったことです。Active Directoryは、Maerskの業務の多くを支える重要なインフラストラクチャサービスです。

そこで、復旧チームがこのシステムを特定するとすぐに、ラゴスからヒースローへの最初の利用可能なフライトのファーストクラスキャビンに、付け加えますが、そのx86ボックスを乗せました。そして、M4モーターウェイを猛スピードでショーファー運転し、英国本社のあるメイデンヘッドまで運び、Active Directoryを使ってネットワークを徐々に再起動し始めました。さて、通常の運用能力に近い状態に戻るまでには何日も何日もかかり、完全に復旧するには何週間も何週間もかかりました。しかし、最終的には彼らはビジネスを回復させることができました。

では、なぜ彼らの経験、なぜこのストーリーが今朝の議論にとってそれほど重要なのでしょうか？それは、データレジリエンスのいくつかの核となる原則に私たちの焦点を当ててくれるからだと思います。まず第一に、オフラインバックアップを持つことの重要性を教えてくれます。本番環境から完全に分離された、今回の場合は幸運によってではなく、できれば設計によって実現されたものです。また、重要なビジネスサービスを本当に理解することの重要性も教えてくれます。今回の場合、それは私たちの多くが使用している重要なインフラサービスであるActive Directoryでした。

規制当局のガイダンスとSheltered Harbor認証：データ保護の標準化への取り組み

そして最後に、たとえあなたが攻撃のターゲットでなくても、攻撃の被害者になり得るという事実を本当に強調しています。ですから、サイバー攻撃の被害に遭うかどうかではなく、いつ遭うかという問題なのです。そして、特にランサムウェアが業界にもたらすシステミックリスクを考えると、世界中の政府や規制当局から多くの指針、規範的なガイダンスが出されているのを目にしてきました。

今から2年前、オーストラリアのDepartment of Home Affairsが、広く報道されたMedibankとOptusのデータ侵害を受けて、ランサムウェアに対する非常に強力な行動計画を発表しました。香港では、その地域で事業を行いたい場合、Association of BanksとMonetary Authoritiesが、いわゆるセキュアな第三次データバックアップを持つことを義務付けています。年初には、多くの注目がヨーロッパとDORA、Digital Operational Resilience Actに集まりました。これは1月17日にヨーロッパで施行されました。これらの条項や規定の多くは、ネットワークの分離とバックアップに関するものです。詳しく知りたい方は、Article 12をご覧ください。

そして私たちは、Bank of EnglandとCMORG、Cross-Market Operational Resilience Groupと呼ばれる組織と非常に密接に協力し、彼らがCHDVsまたはCloud Hosted Data Vaultsと呼ぶものを設計、展開、実装することの意味について取り組みました。彼らはCHDVsを、金融サービスセクター全体のレジリエンスをレベルアップするための重要なメカニズムと見なしています。さて、これから皆さんがデータボルトとCHDVとは何かについて、より技術的な詳細と深さに入っていきます。

しかし非常にシンプルに言うと、CHDVとは、AWS上に構築された独立した復旧環境であり、最も重要なデータ資産のゴールデンコピーをエアギャップされた不変のボルトに保持することで、壊滅的な侵害が発生した場合にビジネスを復旧できるようにするものです。ちょうど昨年の今頃、ニューヨークのウォール街のNYDFSは、ニューヨークでビジネスを続けたい場合、引用しますが、改変と破壊から自由な外部バックアップを持たなければならないと規定しました。

ですので、データ保護に関する多くのガイダンスが存在していると思います。ただ、実際の標準、つまり組織が満たすべき具体的で明確な標準については、あまり見られないというのが正直なところだと思います。そして、標準のポケットのようなものが存在する場合でも、それらの標準を達成するための道筋というものはほとんど見られませんし、ましてや公式な標準認証となると、ほぼ皆無と言っていいでしょう。そして、それこそがSheltered Harborが設立された理由なんです。Sheltered Harborは金融サービスセクター全体におけるオペレーショナルレジリエンスのゴールドスタンダードを設定しており、AWSがSheltered Harborのアライアンスパートナーとなった最初で唯一のクラウドサービスプロバイダーであり、クラウド上でSheltered Harbor認証プラットフォームを持っていることを、私は本当に嬉しく思っています。そして、このことをお客様にお話しすると、ランサムウェアがもたらす課題を克服するための素晴らしいソリューションと信頼性を私たちが持っているということに、本当に自信を持っていただけるんです。

では、データ保護に関して、お客様は他に何が重要だとおっしゃっているでしょうか。まず、スピードが非常に重要だとおっしゃいます。サイバー攻撃に関しては、脅威の窓を最小限に抑えることが本当に重要であり、クラウドソリューションに本来備わっている柔軟性を考えると、オンプレミスよりもクラウドで、はるかに多くのことを、はるかに迅速に達成できるのです。また、絶えず変化する脅威の状況に対応するために、柔軟に曲げたり伸ばしたりできる、アジャイルでモジュラー型のデータ保護プラットフォームを持つことが極めて重要だともおっしゃいます。Marketplaceは、そのモジュラープラットフォームをサポートする重要な要素なんです。

そして最後に、小さく始めて素早くスケールする能力、AWSが提供するユーティリティモデルを活用する能力、そして高額で複雑なオンプレミスインフラへの多額の初期投資、CapEx投資を完全に回避したいとおっしゃいます。そのインフラは、実際には将来的に目的に適しているかどうかわからないものかもしれません。そして、AWSで実現できるデータプラットフォームの最適化能力を持つことが、お客様にとって非常に重要なんです。つまり、スピード、アジリティ、そしてスケールということです。サイバーイベントリカバリーに関しては、私たちのメッセージングとgo-to-marketを本当に磨き上げています。しかし、時には一歩下がって、データレジリエンスという用語で私たちが何を意味しているのかについて話すことも重要だと思います。それでは、Brianに重要なインサイトを共有していただくのを、本当に楽しみにしています。

データレジリエンスの定義：高可用性とデータ保護の違いを理解する

ありがとうございます、Steve。では、いくつかの基本から始めることが重要だと思います。レジリエンシーとは正確には何でしょうか。これは、複数のサービスにわたる部分的または断続的なコンポーネント障害に耐え、最終的には効率的に回復するワークロードの能力のことです。しかし、レジリエンスは一枚岩ではありません。複数の側面とコンポーネントから構成されており、独自のレジリエンス戦略を設計する際には、それらを理解する必要があります。

最初の柱は高可用性です。このように考えてみてください。ネットワークの問題やコンポーネント障害が発生した場合、高可用性とは、アプリケーションを稼働し続けるために、システムがフェイルオーバーする能力のことです。例えば、非常に人気のあるeコマースサイトを運営していて、Black Fridayだとします。ハードウェア障害により、Webサーバーの1台がダウンしましたが、ロードバランサーがこれを検知し、すぐに残りの利用可能な正常なサーバーにトラフィックを振り向け始めます。これが高可用性の実例です。個々のコンポーネントが故障した場合でも、サービスの継続性を維持するための自動フェイルオーバーです。

しかしその例では、お客様は買い物を続けることができ、誰もが探しているものを手に入れることができ、バックグラウンドでの検知もありません。つまり、障害が発生したにもかかわらず、ウェブサイトは継続しているわけです。しかし、フェイルオーバーが必ずしもすべての最終目標というわけではありませんよね。その反対側には、データ保護があります。これはアプリケーションが完全にダウンしてしまい、そのサイトを完全に復旧させなければならない場合です。高可用性が障害を防ぐのに役立つ一方で、より壊滅的な障害から復旧するのがデータ保護であり、これは3つの層で考えることができます。

まず、バックアップとリカバリーです。これらは定期的なスナップショットで、データ破損イベントが発生する前の時点に復元することができます。

前夜のバックアップを使用して誤削除から復元するようなものが、このカテゴリーに該当します。次に、ディザスタリカバリーは、プライマリーロケーションが利用できない場合に、代替サイトへ運用を復元する能力です。最後に、ビジネス継続性があります。これは、これらのイベントの要件を実行するために必要な人、プロセス、そしてコミュニケーションを包含するものです。ここでの重要な違いは、高可用性は秒単位で動作してアプリケーションを稼働し続けるのに対し、データ保護は通常、時間単位で動作しますが、それによって稼働状態に戻すことができるということです。レジリエンス計画戦略では、通常、これら両方が必要になります。

さて、障害には多くの形態があり、障害の発生可能性と影響を理解することが、レジリエンス戦略を推進することになります。最も一般的な障害のタイプは、誰でも推測できると思いますが、人的エラーですよね。誰かが操作ミスをして、余分なゼロを追加したり、アプリケーションデプロイメントのパラメータを誤設定したりすることがあります。もう少し進むと、負荷誘発型のエラーがあります。先ほどのeコマースウェブサイトについて再び考えると、おそらく予想以上のトラフィックがシステムに過負荷をかけて、システムがダウンするといったことです。このような高い発生可能性だが影響の低いイベントには、高可用性タイプのソリューションが求められます。自動フェイルオーバー、ロードバランシング、そしてこれらのイベントに対処するための冗長性を配置します。

しかし、この連続体を横断していくにつれて、アプローチを変える必要があります。ここでは、極端な例として、自然災害、地域的な混乱、そしてDannyが今日冒頭で話したようなサイバーイベントがあります。これらは発生可能性は低いですが、はるかに影響の大きいシナリオです。これらに対しては、データ保護タイプのソリューションが必要です。ここで、ディザスタリカバリー、包括的なバックアップソリューション、そしてビジネス継続性計画がすべて活躍します。つまり、頻繁に発生するが管理可能な混乱を管理するのが高可用性です。データ保護は、まれに発生する壊滅的なものに対応するためにあるのです。

これらのそれぞれへの投資は、最終的にはアプリケーションのビジネス上の重要性に依存することになります。例えば、財務システムやチケッティングシステムをお持ちの場合、稀な障害であっても許容できないため、おそらく両方を同時に設計することになるでしょう。しかし最終的には、これらの投資をどこに行うかを決定するために、メトリクスを整合させることが重要です。よくある管理可能なエラーに対しては、高可用性に多くの投資を行いますが、ビジネスを終わらせる可能性のある稀な壊滅的なイベントに対するデータ保護も軽視しないでください。

責任共有モデルとAWSインフラストラクチャ：リージョンとアベイラビリティーゾーンの役割

AWSでは、セキュリティの文脈で責任共有モデルについて頻繁に話していることを、皆さんもよく耳にされていると思います。他の講演でもこれに触れたことがあると思いますが、レジリエンシーについても責任共有モデルで運用しており、これがこれから議論する皆さんが実装する戦略に直接影響を与えます。つまり、皆さんはクラウド内のレジリエンシーに責任を持ち、一方でAWSはクラウドのレジリエンシーに責任を持つということです。では、これは具体的にどういう意味でしょうか?

AWSはコアインフラストラクチャとそのレジリエンシーを担当しています。リージョン、アベイラビリティーゾーン、エッジロケーションといったものはすべて、コンピュート、ストレージ、ネットワーク、データベースサービスが高可用性で冗長性を持つことを保証するために存在しています。これにより、皆さん自身のレジリエンス戦略を構築するために必要な構成要素が提供されます。しかし、ここに重要な違いがありますよね?例えば、Amazon S3のようなサービスを考えてみてください。私たちはイレブンナインの耐久性があると話していますが、そのオブジェクトを書き込むと、適切に複製され、イレブンナインの耐久性を提供します。しかし、もし私がS3内のそのオブジェクトを破損させた場合、その破損もイレブンナインの耐久性で保持されることになりますよね?

ここで重要なポイントは、データ保護のためにアプリケーションをアーキテクトする責任が皆さんから取り除かれるわけではないということです。責任共有モデルについて再度お話ししますが、私たちは高可用性で冗長性のあるシステムを設計できるエンタープライズグレードのインフラストラクチャを提供しています。しかし、アプリケーションレベルでは、ビジネスアプリケーションに適したレジリエントなパターンを導入することは、最終的には皆さんの責任なのです。

リージョンとアベイラビリティーゾーンが何を意味するのか、簡単に確認しましょう。これらは、これからお話しするすべてのレジリエンス戦略のインフラストラクチャの基盤となるものです。リージョンは地理的に分散した拠点であり、ディザスタリカバリーやデータレジデンシー要件を満たすことを可能にします。

それでは、各リージョン内には複数のアベイラビリティーゾーンがあり、このアベイラビリティーゾーンが分離された障害ドメインとなっていて、さまざまなタイプの高可用性設計を可能にしています。ここでの重要なアーキテクチャ原則は、アベイラビリティーゾーンは相関障害を避けるために十分に分離されているということです。つまり、先ほどマトリックスでお話しした高影響エリアに該当するようなものですね。しかし同時に、同期レプリケーションと自動フェイルオーバーを可能にするために十分近くに配置されているため、高可用性設計に組み込むことができるわけです。これにより、両方の構成要素が得られます。高可用性のためのアベイラビリティーゾーンと、異なる地理的境界をまたいだデータ保護のためのリージョンです。

AWSサービスの分類とRTO・RPOの設定：レジリエンス戦略の基礎

AWSのすべてのサービスは、これらのインフラストラクチャの境界を活用するように設計されていますので、それらがどのように設計されているかを理解することで、皆さんが独自のアプリケーションを設計する際に適切な選択ができるようになります。AWSサービスは、実装しているインフラストラクチャパターンに基づいて3つのタイプに分類できます。最初のタイプはゾーンサービスです。Amazon EBSやAmazon EC2は、その環境内のゾーン、つまりアベイラビリティーゾーン内で個別に動作し、独立して障害が発生します。これにより、きめ細かな制御が可能になります。複数のゾーンにアプリケーションをどのように分散させるかを設計できますが、最終的には、それらのゾーン間でどのようにフェイルオーバーするか、またはトラフィックを誘導するかを定義する責任も皆さんにあります。

次に、Amazon S3やAmazon DynamoDBのようなリージョナルサービスは、この複雑さの多くを抽象化してくれます。つまり、AWSが自動的に複数のアベイラビリティーゾーンにデータを分散し、フェイルオーバーも自動的に処理してくれるのです。例えば、アプリケーションがAmazon S3を使用していて、障害が発生した場合、それはアプリケーションからは見えず、AWSが高可用性を処理してくれているということになります。そして最後にグローバルサービスがあります。これらは分散アーキテクチャを持ち、コントロールプレーンは単一のリージョンにありますが、データプレーンは世界中に広がっています。Amazon Route 53のようなサービスを見ると、世界中の200以上のポイントオブプレゼンスで動作しています。これにより、単一のサービス内で高可用性機能とデータ保護、つまりディザスタリカバリ機能の両方が得られます。

ここでの重要なポイントは、可能な限りリージョナルサービスのようなものを活用することに注力したいということです。そうすれば、高可用性がサービスレベルで自動的に提供されます。そして、それをゾーンサービスと組み合わせることができますが、それらがどのように動作し、データをどのように分散させるかを確実に理解して、アプリケーションがどのように動作すべきかに基づいて、そのアプリケーションの回復性を処理できるようにしてください。グローバルサービスを活用して、追加の高可用性を加え、さらに重要なのは、リージョン間で移動する必要がある場合のディザスタリカバリ機能を追加することです。

重要な注意点として、リージョナルサービスであっても、グローバルな依存関係を持つ場合があるということです。例えば、Amazon S3を見てみると、S3のネーミングサービスはグローバルです。Amazon S3には、US East 1にコントロールプレーンを持つネーミングサービスがありますが、データプレーンはグローバルです。つまり、US East 1が利用できなくなった場合、グローバルに一意な名前が必要なため、新しいバケットを作成できなくなりますが、既存のバケットは引き続き高可用性を保ち、アクティブな状態が維持されます。アプリケーションを設計する際、特にディザスタリカバリ計画を立てる際には、このようなことを考慮してください。

では、可用性や破損イベントに対してどのように準備するかは、そのようなイベントが発生した際の目標に直接関係していますが、予算とも結びついています。そして、これらのイベントが発生した際に答える必要がある質問は、イベント発生後どのくらい早くシステムを再び利用可能にする必要があるか、ということです。これがRecovery Time Objective、つまりRTOです。もう一つの質問は、そのようなイベントの後、どれだけのデータ損失に耐えられるか、ということで、これがRecovery Point Objective、つまりRPOです。

例えば同期レプリケーションのようなものを設定する場合、これは最短の復旧時間を提供してくれますが、データの破損や誤削除に対処する必要がある場合には、あまり多くの機能を提供してくれません。なぜなら、必ずしもその前の時点に戻ることができないからです。一方で、継続的または定期的なバックアップを作成することで、データ破損イベントが発生する前の時点に戻ることができますが、通常、レプリケーションタイプのソリューションよりも時間がかかります。ただし、どこに復旧するかという点では、より柔軟性があります。さて、従来、企業は複数のデータセンターを維持し、重要なデータをあるデータセンターから

4つのレジリエンス戦略：マルチゾーンとマルチリージョンのアプローチ

別のデータセンターにレプリケートし、オフサイトに保存されるバックアップを維持していました。今日、AWSは2つの次元を中心に構成された洗練されたフレームワークを提供しています。1つの次元はゾーン対リージョンのスコープであり、もう1つは復旧対可用性のアプローチです。これからお話しするマトリックスは、これら2つの次元に結び付けることができる4つの異なる戦略を示しています。

最初の1つはマルチゾーン可用性で、これは個々のゾーン障害にもかかわらず、アプリケーションが利用可能な状態を維持することを意味します。これらの設計では、Amazon EBS、Amazon EFS、Amazon FSx、Amazon RDSなどを設定して、複数のゾーン間でデータをレプリケートし、個々のゾーン障害が発生した場合でもデータがアクティブで利用可能な状態にします。これはプロアクティブな可用性アプローチであり、システムが複数のゾーンに分散されているため、個々のゾーン障害を簡単に処理したり、フェイルオーバーしたりできます。しかし、データ破損の場合にはあまり役に立ちません。

次のアプローチはマルチゾーン復旧です。マルチゾーン復旧では、バックアップを使用します。ファイル、ブロック、オブジェクト、データベースストレージシステムのバックアップを取得し、それらを別のアベイラビリティーゾーンにコピーします。そのため、プライマリゾーンの障害が発生した場合、そのデータを代替ゾーンに復元して、破損イベントが発生する前の状態にシステムをオンラインに戻します。

マルチリージョナル可用性は、マルチゾーナルと非常に似ていますが、この場合は、重要なビジネスデータをプライマリリージョンからセカンダリリージョンにレプリケートします。これもまたプロアクティブなアプローチです。なぜなら、複数のシステムを異なる地理的境界に分散配置することで、リージョンの障害が発生した際にセカンダリリージョンにフェイルオーバーし、そのリージョンがオンラインに戻ったらフェイルバックできるからです。繰り返しになりますが、このタイプのソリューションでは、データ破損のようなシナリオに対する保護は行っていません。

四象限の最後は、マルチリージョンリカバリーです。この場合、プライマリリージョンで重要なデータのバックアップを取得し、それらのバックアップをセカンダリリージョンにコピーします。これもリアクティブなアプローチです。しかし、データ破損イベントが発生し、プライマリリージョンへのアクセスに何らかの問題があるという稀なシナリオが発生した場合、セカンダリリージョンでこれらのシステムをその時点に復元することができます。重要なポイントは、通常、これらの四象限のうち一つだけを選んでレジリエンス戦略を実装するわけではないということです。実行しているアプリケーションの種類やそれらのアプリケーションのビジネス上の重要度に合わせて、これらの複数を使用することになります。

マルチゾーン可用性の実装と3-2-1-1-0バックアップフレームワーク

それでは、最初の象限であるマルチゾーナル可用性を見て、典型的な3層アプリケーションで実際にどのように見えるか確認しましょう。ここでは、ゾーナルサービスとリージョナルサービスの組み合わせを活用した、非常に一般的でわかりやすいマルチAZアーキテクチャがあります。NATゲートウェイやロードバランサーなどを使用して、異なるゾーン間のトラフィックを振り分けます。ベストプラクティスとして、まずWebサーバーをロードバランサーの背後に配置しますが、この場合、パフォーマンスのためだけではなく、複数のゾーンにわたって正常なサーバーに振り分ける機能を有効にするためでもあります。

さらに、複数のゾーンにわたってAmazon EC2 Auto Scalingグループを設定したいと思います。単一のゾーン障害が発生した場合、ロードバランサーは正常なWebサーバーへのトラフィックの振り分けを開始し、Auto Scalingグループはそれらのゾーンで追加のリソースを起動して、サービスレベルを維持できるようにします。Amazon AuroraとAmazon RDSは、複数のゾーンにわたってデータをレプリケートし、自動フェイルオーバーをサポートできます。さらに、データベースの読み取りレベルで冗長性が必要な場合は、複数のリードレプリカを追加することもできます。

最後に、アプリケーション内でAmazon S3やAmazon DynamoDBのようなサービスを使用することで、デフォルトでリージョナルレベルでの高可用性が得られます。マルチAZ可用性が、アプリケーションやアベイラビリティゾーンの障害が発生しても稼働し続けることができる方法を見てきましたが、可用性だけでは十分ではありません。このことを皆さんに強調できていることを願います。データ破損イベント、削除、そしてDannyが今日冒頭で話したようなランサムウェアやサイバーイベントから回復するための戦略も必要です。オンプレミスでは、従来の3-2-1バックアップモデルがあり、それは私たちに良く役立ってきました。

クラウドは、その上にさらに柔軟でコスト効率の高い戦略を可能にします。AWSでは、3-2-1-1-0フレームワークと呼ばれる戦略またはフレームワークを提唱しており、これが私たちのデータ保護のゴールドスタンダードです。これが意味するのは、プライマリリソースとは別に3つのデータコピーを持つということです。異なる場所に2つのコピーを持ちます。つまり、クロスアカウントまたはクロスリージョンということです。1つのコピーはローカルリカバリ用で、運用上の問題に対して高速リストアができるようにします。そして1つのコピーは不変で、隔離され、ボールトに保存されており、サイバーイベントやランサムウェアタイプのシナリオから保護します。おそらく見落とされがちですが、最も重要なのは、実際に使用する必要がある場合にゼロエラーでリカバリできることを確認するために、定期的にバックアップをテストする何らかのプロセスを持つことです。

しかし、ここで重要なポイントがあります。すべてのアプリケーションがこのレベルの保護を必要とするわけではありません。実際、複数のコピーを保持することはコスト面で大きな負担になる可能性があるため、最終的には保護プランをビジネスクリティカリティと、アプリケーションの戦略を推進する要件に結び付けたいと考えます。このフレームワークは柔軟なので、1つのコピーがソリューション内で複数の目的を果たすことができます。クロスリージョンコピーは、サイバーリカバリのために不変にすることもできます。ローカルの運用コピーは、Amazon EBSスナップショットやAmazon S3レプリケーションのようなネイティブサービス機能を活用できます。最終的には、保護戦略をビジネスインパクトに合わせたいと考えます。

金融取引システムはミッションクリティカルなので、おそらく3-2-1-1-0が必要でしょうが、月次レポートシステムは1-1-0で十分かもしれません。異なるアプリケーションのRPOとRTOを、最終的に選択する戦略に合わせてください。さて、3-2-1-1-0は、ミッションクリティカルなアプリケーション、つまりビジネスに高度に依存するタイプのアプリケーションのノーススターとして使用してください。しかし最終的には、ビジネスクリティカリティと特定のアプリケーション内のリスク許容度に基づいてアプローチをスケールさせたいと考えます。

さて、私たちが話したデータ保護戦略は、最終的に3つの異なる、または別個のタイプのコピーにマッピングされ、それぞれがリカバリプロセス内で異なるシナリオに対応します。 1つ目は、高速リカバリのためのローカルコピーです。これは元のリソースと同じリージョンにあるコピーなので、リカバリが必要なときに最短のRTOが得られます。これは、発生する典型的な運用上の誤削除のためのもので、先ほどのマトリックスから、より高い可能性だが低いインパクトのタイプの障害シナリオにマッピングされます。さて、ここでのトレードオフは、高速リカバリが得られる一方で、リージョン災害やランサムウェアタイプのイベントの場合にはあまり役に立たないということです。

災害復旧のためのリモートコピーは、これらのより地理的な災害タイプのソリューションを処理することを目的としています。ここでは通常、フェイルオーバーメカニズムを備えた何らかのレプリケーションタイプのソリューションを使用しており、これは低い可能性だが高いインパクトのタイプのリージョン災害を処理することを目的としています。最後に、サイバーリカバリコピーがあります。先ほどのDannyの講演を思い出すと、Maerskは偶然オフラインだったシステムを持っていたことでこれに遭遇しましたよね?同様に、私たちはそれをより計画的な方法で行いたいと考えています。既存の運用システムからエアギャップされた、不変で隔離されたコピーを持ちたいのです。なぜなら、これはランサムウェアシナリオにおける緊急時用のブレークグラスコピーだからです。

これらが定期的にテストされていることを確認する必要があります。そうすることで、実際に復旧できることがわかるからです。なぜなら、これは他のすべての防御が高度な攻撃によって突破された場合の最終的な保護となるからです。この特定の時点に戻れるようにしたいわけです。ここでの重要なポイントは、最終的には各コピーが異なる障害シナリオに対応するようにしたいということです。ローカルコピーは高速な運用復元のためのもので、これらは私たちがITの世界で常に対処してきた一般的なものです。クロスリージョンコピーは、地域的な災害が発生した場合にフェイルオーバーできるようにするためのものです。そしてサイバーリカバリーコピーは、しっかりと保護され、隔離されており、ランサムウェアイベントに対する最後の防衛線として機能します。それでは次にSteveに引き継ぎたいと思います。彼がこれらの多くを実際にどのように実装するかについて、もう少し詳しく説明します。ありがとう、Brian。

レプリケーションとバックアップの実装：AWS Elastic Disaster RecoveryとAWS Backupの活用

それでは、リカバリーコピーの数、タイプ、そして場所を検討する際には、各リソースの重要度と、軽減しようとしているリスクを考慮する必要があります。復旧できる必要があるのか、それとも地域全体の地理的な損失を懸念していて、システム全体を立ち上げて地域内の別のリージョンに移動できる必要があるのか。あるいは同様に、ランサムウェアを懸念していて、アカウントへのアクセスを失った場合、データへの悪意のある破損、あるいはAWS organizationのマスターアカウントの損失の場合に復旧できる必要があるのか、ということです。

他のAWSリージョンへのレプリケーションにより、リージョンの障害が発生した場合に可用性を最大化することができます。このようなイベントが発生した場合に迅速にフェイルオーバーできるようになります。Amazon S3、Amazon EFS、Amazon FSx for ONTAP、Amazon DynamoDB、Amazon RDS、Amazon Auroraを含む多くのAWSサービスは、ネイティブなレプリケーション機能をサポートしています。通常、アプリケーションオーナーは、保存しているデータの関係性や、アプリケーションが構築されている個々のリソースの重要度を理解しているため、レプリケーションをアーキテクチャに組み込みます。

予算とRTOに基づいて、アプリケーションオーナーは、コストを重視するアプリケーションの場合、最小限のインフラストラクチャでレプリカターゲットをセットアップすることを選択するかもしれません。しかし、より重要なアプリケーションの場合は、完全にプロビジョニングされたインスタンスとストレージサービスを用意することで、ホットスタンバイをセットアップするかもしれません。同様に、障害後のフェイルバックとトランザクションのマージを簡素化するために、ターゲットを読み取り専用にすることでウォームスタンバイを作成することもあります。他のレジリエンシーソリューションと同様に、アプリケーションオーナーが定期的にアプリケーションの復旧可能性を検証することが重要です。たとえば、別のリージョンにウォームスタンバイを構成している場合、おそらく年に2回程度、定期的に別のリージョンへのフェイルオーバーを実行してからフェイルバックすることを検討するとよいでしょう。

AWS Elastic Disaster Recovery は、インスタンスベースのワークロードに特化して設計されたレプリケーションサービスです。アプリケーションがどこでホストされているかに関わらず、DRSは選択したAWSリージョンへの自動レプリケーションとリカバリを提供します。DRSを設定するには、まずソースサーバーにAWSレプリケーションエージェントをインストールします。これらのエージェントは、ブロックレベルですべてのディスクアクティビティをキャプチャし、それらを選択したリージョンへ転送、レプリケートする役割を担っています。

さて、これらのエージェントはブロックレベルで各変更をキャプチャし、圧縮と暗号化を行った後に送信します。変更されたブロックのみを送信することで、ネットワーク帯域幅への影響を最小限に抑えています。ターゲットとなるAWSリージョンでは、DRSが軽量なインスタンスをプロビジョニングします。これらは単純に変更をキャプチャし、プライマリサイトからのボリュームの同期コピーを作成するように設計されています。DRSはまた、選択した頻度と保持期間でスナップショットを設定します。

そしてイベントが発生した場合、

DRSは、リカバリの開始を選択したときに、選択したサブネット内に本番インスタンスをプロビジョニングします。選択した時点のスナップショットからボリュームを復元し、それらをプロビジョニングされたインスタンスにアタッチすることで、数分以内にアプリケーションを立ち上げることができます。このアーキテクチャは、継続的なレプリケーションによりほぼゼロに近いRPOを、そして自動化されたリカバリオーケストレーションにより最小限のRTOを提供します。これは、インスタンスベースのリフトアンドシフトアプリケーションに適したソリューションです。リージョンの問題が発生した場合にフェイルオーバーする機能を提供し、データ破損が発生した場合には以前の時点にロールバックすることができます。

それではレプリケーションをサポートするネイティブAWSレプリケーションサービスのいくつかを詳しく見ていきましょう。Amazon S3は、クロスリージョンおよびクロスアカウントレプリケーションを提供しており、配信にはいくつかのオプションがあります。コストに敏感なアプリケーションにはベストエフォート配信を選択できますし、15分以内の配信SLAを提供する時間制御レプリケーションを選択することもできます。FSx ONTAPについては、選択したAWSリージョンへの1対1および1対多のレプリケーションを提供しています。DynamoDB Global Tablesは、AWSリージョン間で継続的なアクティブ-アクティブレプリケーションを提供します。低レイテンシアクセスを必要とするグローバルに分散されたアプリケーションに最適なソリューションですし、自動フェイルオーバーも備えています。

レプリケーションは、データ損失をほとんどまたは全く発生させずに新しいインフラストラクチャへの迅速なフェイルオーバーを可能にしますが、バックアップは意図しないデータ変更が発生する前の時点にアプリケーションを復元することを可能にします。これらの変更は、バグ、ユーザーエラー、またはマルウェアによって引き起こされる可能性があります。多くのAWSサービスは、ネイティブのスナップショットおよびバックアップ機能を提供しています。アプリケーション所有者は、運用タスクのためにこれらの機能に依存しています。例えば、アプリケーション所有者は、データベースにスキーマ更新をデプロイする前にバックアップを作成したり、テストや分析タスクを実行するためにリソースをクローンするためにバックアップを使用したりすることがあります。しかし、そのタスクが完了した後は、通常、それらのバックアップを削除できる必要があります。

しかし、組織や業界からのデータ保護要件に準拠するために、多くの組織はデータ保護チームを作成しています。これらのチームは、AWS Backupを使用してバックアップポリシーを定義およびデプロイします。これらのポリシーは、すべての本番アカウント全体で重要なアプリケーションの定期的または継続的なバックアップを作成します。そして、組織内のAWS委任管理者アカウントから、これらのチームはジョブステータスを監視でき、発生した問題に対処することができます。

権限のないユーザーがバックアップを削除することから保護するために、ロックされたvaultにバックアップを保存することを選択できます。ロックは、その中のバックアップのライフサイクルを削除または変更しようとする試みを防ぎます。さらなる分離のために、論理的なエアギャップvaultにバックアップを保存したり、組織内の分離されたアカウントのロックされたvaultにコピーしたりすることができます。

論理的なエアギャップvaultは、組織内外を問わず、別のアカウントと共有できます。これにより、アプリケーション所有者は、プライマリ本番アカウントに影響を与えることなくテストを実行できるため、テストアカウントとvaultを共有できます。

そのテストアカウントで、復元を実行し、定期的にアプリケーションを再構築できることを証明できます。しかし、このプロセスを自動化するために、AWS Backupで復元テスト計画を構築できます。これらの計画は、選択した頻度で、選択したリソースの最新のバックアップを選択し、自動的に復元を実行します。

リストアが完了すると、イベントで通知されます。通知を受け取ったら、Lambdaスクリプトを実行して、リストアされたものの内容を検証し、データが期待通りであるかを判断できます。その検証結果はAWS Backupに送り返すことができます。

さて、先ほど少しお話しした一元化されたレポートには、リストアジョブのレポートとともに、リストアのステータスと検証結果も含まれます。もう一つ指摘しておきたいのは、AWS Backupによって作成されたバックアップは、AWS BackupのAPI、CLI、またはコンソールを通じてのみ削除できるということです。これにより、データ保護チームが作成したバックアップのライフサイクルを管理し、アプリケーション所有者がプライマリアプリケーションのライフサイクルを管理するという、コントロールの分離を簡単に実現できます。

同様に、ライフサイクルだけでなく、アクセスのコントロールも分離されています。バックアップ管理者は、vaultに配置されたポリシーを通じてバックアップへのアクセスを維持でき、アプリケーション所有者はアプリケーション自体へのアクセスをコントロールできます。データを管理する人々、つまりデータ保護チームの人々自身は、プライマリリソースへの直接アクセス権を持っていません。彼らは単にAWS Backupにロールを渡すアクセス権を持っているだけです。

では、簡単な例を見てみましょう。ここには、Amazon RDS、Amazon EBS（これらはゾーンサービスです）、そしてAmazon EFS（これはリージョナルサービスです）の上に構築されたシンプルなアプリケーションがあります。AWS Backupをバックアッププランを通じて設定することで、これら3つのリソースすべてをバックアップできます。そして、リージョナルな災害を懸念している場合は、これらのバックアップを別のAWSリージョンにコピーすることを検討するかもしれません。

さて、アベイラビリティゾーンが利用できなくなったとしましょう。AWS Backupを使用して、ゾーンサービスであるRDSとEBSをリストアし、新しいコンピュートインスタンスを構築して、リストアしたリソースと影響を受けていないリージョナルなEFSファイルシステムを接続することで、アプリケーションを別のアベイラビリティゾーンにリストアできます。同様に、リージョン全体が自然災害によって破壊された場合、ターゲットリージョンのAWS Backupを使用して3つのリソースすべてをリストアし、再び新しいプロダクションインスタンスを構築して、3つのリソースすべてを接続できます。

Well-Architected Frameworkに基づくデータ保護戦略と論理的エアギャップボールトの設定

Well-Architected Frameworkは、堅牢なクラウドアーキテクチャを構築するための6つの柱を提供しています。私は、私たち3人が話してきた多くのことをまとめて、データ保護の戦略を構築し、定義するお手伝いをしたいと思います。データの重要度はアプリケーションごとに、またアプリケーション内でも異なるため、最初のステップは、アプリケーションオーナーと協力して、彼らが管理するデータを分類することです。

次に、各クラスごとに、懸念しているリスクを軽減するために必要なレプリケーション要件に関する戦略を定義し、組織レベルでバックアップポリシーを構築します。これらのポリシーは、データの意図しない変更後の復旧を行うために必要なバックアップを提供します。

セキュリティの観点から、バックアップへのアクセス管理には、プライマリリソースと同じ厳格さを確保してください。なぜなら、可用性の問題やマルウェアから身を守るために作成するすべてのコピーが、データ流出の別の機会を生み出すからです。アプリケーションオーナーは、おそらくプライマリリソースへのアクセスを管理するためにあらゆる種類のコントロールを設定しているでしょう。データ保護チームとして、バックアップに保持しているデータが漏洩しないように、同じ種類のコントロールを確実に実施する必要があります。

最後に、復旧をテストすることが重要です。アプリケーションオーナーは、特定のリソースを復元できることを示すだけでなく、別のアカウントでアプリケーション全体を復旧する練習をする必要があります。基本的に、プライマリアカウントへのアクセスを失うリスクを軽減しようとしている場合、アプリケーションオーナーは、バックアップが取られていることを確認するだけでなく、別のアカウントで完全なアプリケーションを復旧できることを証明する必要があります。

さて、委任管理アカウントから、データ保護チームがデータ保護ジョブのステータスを監視していることを確認してください。そうすれば、障害が発生した場合に、その障害とそれらのエラーの原因となっている設定の問題に対処できます。また、その一元化された管理アカウントからコンプライアンスレポートを作成することもでき、期待する時間内に重要なリソースのバックアップがあることを確認できます。

では、別の例を見ていきましょう。これもシンプルなEC2ベースのアプリケーションですが、今回はこれまでお話ししてきた様々なことについて、より包括的にお話しします。このシチュエーションでは、ワークロードアカウント内で、AWS Backupを使用した最初のバックアップコピーがあり、それはシンプルなバックアップボールトに保存されています。バックアッププランは、これらのバックアップをセカンダリアカウントにもコピーするように設定できます。このセカンダリアカウントでは、データを論理的エアギャップボールトに保存することで、アカウントへのアクセスを失った場合でも、バックアップへのアクセスを確保できるようになります。

さて、バックアップがコピーされたら、そのイベントをキャプチャして、そのアカウント内でオーケストレーションされたテストや分析を構築することができます。ここでは、もちろん、先ほど申し上げたように、自動リストアテストを使用して、作成したバックアップの復旧可能性を検証し、それを監査人に報告することができます。

さて、3つ目のコピーとして、この基本的なインスタンスベースのアプリケーションには、DRS Elastic Disaster Recoveryの使用を検討してください。DRSは、アプリケーションのボリュームを選択したリージョンにレプリケートし、リージョンの障害やリージョンの災害が発生した場合に、別のリージョンにフェイルオーバーできるようにします。つまり、これら3つのコピーにより、ユーザーによる単純なミス、アカウントを乗っ取って破壊したり組織アカウントを破壊したりするマルウェア攻撃、そしてリージョンの障害からもデータの損失を防ぐことができるのです。

このプレゼンテーションの冒頭で、Dannyが大規模なサイバー攻撃についてお話ししました。ここからは、そのような攻撃から保護するために、論理的エアギャップボールトをどのように設定できるかをご説明します。最初のステップは、リカバリー組織を作成することです。そのリカバリー組織の管理アカウント内で、組織内の信頼できる少数の個人のためのアイデンティティを作成する必要があります。さて、これらのアイデンティティには同じアイデンティティプロバイダーを使用したくありません。なぜなら、リカバリー組織と本番組織の間に共有の依存関係を持たせたくないからです。

これらのアイデンティティを使用して承認チームを作成します。リクエストを正常に承認するために必要な承認数を指定します。その後、その承認チームをワークロードアカウントと共有し、論理的エアギャップボールトに関連付けることができます。そうすれば、災害が発生して所有しているすべてのものへのアクセスを失った場合でも、バックアップへのアクセスは維持されます。新しく作成されたアカウントから、AWS Backupを使用して、そのボールトのARNを使ってその論理的エアギャップボールトへのアクセスをリクエストできます。リクエストは承認チームに転送されます。彼らが投票して承認すれば、ボールトへのアクセスが許可され、アプリケーションを復元できるようになります。

このシステムにより、Dannyが説明したように、本番環境で所有しているすべてのものへのアクセスを失った場合でも、確実に復旧できることが保証されます。それでは、セッションを締めくくってもらうために、Dannyにお返ししたいと思います。ありがとうございました。

まとめ：最悪の事態に備えた重要ビジネスサービスの保護と次のステップ

素晴らしい、ありがとうございます。素晴らしかったです、Steveありがとう。それでは、セッションをまとめていきたいと思いますが、最悪の事態に備えるべきだというのは妥当な考え方だと思います。侵害を想定し、デジタル絶滅レベルのイベントを想定して、そこから逆算して考えていくということです。そして、ビジネスをビジネスたらしめている重要なビジネスサービス、つまりクリティカルなサービスを本当に理解することも重要だと思います。

さて、セッションの冒頭で申し上げたように、私は金融サービス業界で働いており、多くの銀行と話をしています。例えば、典型的な銀行では、ビジネスサービスのリストとインフラストラクチャサービスのリストがあり、おそらくそれぞれ12個程度のミッションクリティカルなものがあるでしょう。決済サービスがありますね。給与計算もかなり重要です。従業員がいなければビジネスは成り立ちませんから。銀行であれば、モバイルバンキング、オンラインバンキング、ATM、現金へのアクセス、残高へのアクセスがあり、大規模なトレーディング部門があれば、Murexのフロントオフィスなどもあるでしょう。

そしてインフラストラクチャ側では、Active Directoryについてはすでにお話ししましたね、Maerskの例を使って。しかし他にもあります。私ならDNSもそこに含めます。メインフレーム環境であれば、LPARがあるでしょう。そして、これらの重要なビジネスサービスを固めたら、テストして、テストして、何度もテストして、エンドツーエンドの復旧を検証する必要があります。そして、それがビジネスプロセスと整合していることを確認してください。

ぜひ、サイバーイベント成熟度評価ワークショップを実施する機会もご利用ください。このセッションの後もしばらくおりますので。さて、私がこのワークショップを実施したお客様は、そこから多大な価値と利益を得ており、事業継続計画や今後の戦略を策定する上で非常に役立っています。また、AWSストレージジャーニー、学習の旅も続けていただければと思います。AWS.training/storageには、さらに多くの情報がございます。

最後になりますが、お時間をいただき本当にありがとうございました。セッションのアンケートフィードバックをいただけますと大変ありがたく存じます。来年もまた戻ってきて、皆様に重要な知見を共有できればと思っております。ですので、ぜひフォームにご記入ください。何よりも、お時間をいただき本当にありがとうございました。今朝のセッションを楽しんでいただけたことを願っておりますし、残りの一日が素晴らしいものになることを願っております。本当にありがとうございました。

※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。