re:Invent 2025: AWS Backupの新機能とExxonMobil、JPMorgan Chaseのデータ保護戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Protect your data with AWS Backup: overview, use cases and what's new (STG207)
この動画では、AWS BackupのプロダクトマネージャーPalak DesaiとBisman Sethiが、データ保護の重要性と2025年の新機能について解説しています。1,500以上の顧客が3.8エクサバイトのデータを保護しており、20以上のAWSリソースに対応しています。主要な新機能として、論理的にエアギャップされたvaultへの直接コピー、マルチパーティ承認、Amazon GuardDutyによるマルウェアスキャン、S3バックアップのティアリング、Amazon EKSサポートが紹介されました。ExxonMobilのChuck Uwannaは、不変性、オーケストレーション、隔離を原則としたプロアクティブなレジリエンシー戦略を説明し、JPMorgan ChaseのRooshir Patelは、規制要件を満たすためのバックアップとリストアテストの実装について語りました。両社とも、ランサムウェア攻撃への備えとして、エアギャップされた環境での自動化された復旧能力の構築を重視しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
AWS Backupセッションの開始：データ保護の重要性と顧客基盤
皆さん、こんにちは。STG207へようこそ。このセッションは「AWS Backupでデータを保護する：概要、ユースケース、AWS Backupの新機能」です。私はPalak Desaiです。AWS Backupのプロダクト管理を担当しています。一緒に参加しているのはBisman Sethiで、彼女もチームのPMです。また、ExxonMobil Global Services CompanyのChuck Uwannaという尊敬される顧客も参加しており、AWS Backupでの彼のジャーニーについて話してくれます。そしてJPMorgan ChaseのRooshir Patelも、彼らのAWS Backupでのジャーニーについて話してくれます。では始めましょう。今日は素晴らしいアジェンダが待っています。
今日私がカバーする内容という観点から、AWS Backupが重要な理由と、なぜデータを保護すべきなのかについて話していきます。 また、AWS Backupの新機能についても議論します。2025年は多くの重要なローンチがあり、素晴らしい1年でした。それらのローンチについて説明していきます。顧客の皆さんがAWS Backupでどのように進展しているのか、そしてデータ保護が彼らにとって何を意味するのかについて聞きます。ExxonとJPMorgan Chaseの顧客からのジャーニーで締めくくり、その後セッションを終了します。
ちなみに、スライドは最後に掲示しますが、AWS Backupの新機能、データ保護、レジリエンシー、そしてランサムウェア全般に関する多くの素晴らしいセッションがあります。最後にスライドをお見せしますが、ぜひ見てください。できるだけ多くのセッションに参加してください。では始めましょう。 ご存知の通り、データは増え続けています。皆さんのような顧客はデータを使ってビジネスを運営しています。私たちはデータを使ってお客様により良いサービスを提供しています。例えば、ヘルスケア業界からのデータを使って、過去に遡って自分たちの健康がどのように進展しているかを理解しています。財務データを使って、お客様により良いサービスを提供する決定を下しています。一般的に、皆さんのような顧客はデータを使ってビジネスを推進しているので、データには価値があり、データは増え続けています。
その結果、私たちはそのデータを保護したいのです。AWS Backupはそのデータを保護するための機能を提供しています。 簡単な事実をお伝えします。すべての顧客の皆さんに感謝したいです。1,500を超える顧客がいて、増え続けています。この統計は毎年re:Inventで更新しており、3.8エクサバイト分のデータを保護しています。本当にこのサービスに信頼を置いてくれてありがとうございます。
AWS Backupの機能概要：20以上のリソースをカバーする集中型データ保護
私たちが何をしているかという観点から、AWS Backupは集中化されたデータ保護のためのネイティブソリューションです。クラウドに存在するデータを、Amazon EBSやAmazon S3などのすべてのAWSステートフルリソース全体で保護しています。20以上のリソースを保護しています。また、VMware backupsの保護を通じてハイブリッドシナリオにも拡張しており、VMwareサーバーをバックアップすることができます。データ保護という観点からそのカバレッジを持っています。
Double clicking in、つまり私たちが本当にやっていることは何かというと、20以上のリソースにわたってポリシーを通じてデータ保護を一元化し、自動化する完全マネージドサービスを提供しています。 ご覧の通り、スライド全体や各リソースを1つ1つ説明するつもりはありませんが、コンピュート、ブロックストレージ、オブジェクトストレージ、ファイルストレージ、データベース、管理、アプリケーション、そして AWS Backup による VMware と SAP HANA のハイブリッドサポートにわたってカバレッジがあることがわかります。今年スライドに新しいブロックが登場しているのが見えますね、それはコンテナです。今月 re:Invent で AWS Backup の Amazon ECS コンテナサポートをリリースしたことをお知らせできて非常に嬉しいです。そしてそれはお客様からの直接的なリクエストで、AWS Backup はそのお約束を果たしました。詳細なローンチについては後のスライドで説明します。
基本的なデータ保護に加えて、検索とアイテムレベルのリカバリ、ランサムウェア保護のための論理的エアギャップ、リストア テスト、マルウェア スキャン、監査などの機能を提供しています。つまり、バックアップされたデータの上に提供する機能がたくさんあるわけです。 お客様が私たちを利用するユースケースの一部がスライドに載っています。もちろんバックアップから始まります。20以上のリソースとそれ以上に対するクラウドネイティブバックアップを提供しています。今年は Redshift Serverless のサポートを追加しました。Aurora DSQL のサポートを追加しました。そして Amazon EKS のサポートを追加しました。つまり、データをバックアップするリソースの数を拡大しました。バックアップからリカバリするユースケースとしては、ディザスタリカバリーがあります。例えば、ファイルをうっかり削除してしまった場合、リカバリしたければリカバリできます。
地震のような自然災害が発生して、別のリージョンでリカバリする必要がある場合、バックアップからリストアできます。多くのお客様は規制業界で事業を行っているため、バックアップ体制についてのレポートが必要です。Backup Audit Manager に組み込まれた機能により、規制当局と共有できるレポートを提供して、データをどのようにバックアップしているか、何をバックアップしているか、どこに保存されているか、暗号化されているかどうか、保持期間は何かを示すことができます。これらのレポートは特定のニーズに基づいてカスタマイズできます。
最後の重要な柱はランサムウェア リカバリーです。多くのお客様は、ランサムウェア攻撃に直面した場合に私たちが何をするのかを尋ねています。重要な質問は、ランサムウェア イベントからの成功したリカバリーを確保するために、バックアップされたデータからアプリケーションをリカバリーする方法です。論理的エアギャップ ボールトとそのポートフォリオの拡張を通じて、この分野で一連の機能を開発しました。このセッションでカバーします。
2025年の主要ローンチ：新リソース対応とランサムウェア対策の強化
スライドのすべての項目を説明するつもりはありません。かなり包括的なので。スライドを確認する時間を少し差し上げます。ご覧の通り、2025年は非常に忙しく、多くの機能をローンチしました。Redshift、Aurora DSQL、Amazon EKS を含む新しいリソースのサポートを追加しました。また、より長い保持期間のための低コストの階層化ストレージを作成することで、既存のリソースのサポートを強化しました。S3 バックアップについては、RDS バックアップの拡張を行い、この分野で引き続き進展させていきます。
ランサムウェア対策の側面では、Bismanが詳しく説明する予定の注目すべきローンチは、論理的にエアギャップされたヴォルトの機能強化とGuardDutyを経由したマルウェアスキャンの追加に焦点を当てています。私たちはプラットフォームの運用と復元力を向上させるために継続的に取り組んでいきます。パフォーマンス改善に取り組むことで、今年を通じてバックアップがより高速で効率的になっていくのが見えるようになるでしょう。また、可視性に取り組み、新しいリージョンが利用可能になったときにプラットフォームを拡張していきます。
このような背景の中で、皆さんのようなお客様と継続的に協力しているBisman Sethiをお招きして、私たちの主要なローンチについて説明していただきたいと思います。ありがとうございます、Palak。Palakが述べたように、私たちは今年本当に忙しくしてきました。皆さんから継続的に受け取るカスタマーフィードバックを見ることができるのは素晴らしいことですし、そのリクエストに対応できるのはやりがいがあります。私たちの主要なローンチのいくつかと、現在提供している強化された機能について深掘りしていきます。これらはすべて一般提供されており、Palakが述べたように、今後も継続的にこれらを強化していきます。
論理的エアギャップボルトの進化：マルチパーティ承認とGuardDutyマルウェアスキャン
今年の最初の主要なローンチの1つは、論理的にエアギャップされたヴォルトの強化でした。少し背景を説明すると、論理的にエアギャップされたヴォルトは、ランサムウェア対策の柱として昨年ローンチした機能です。論理的にエアギャップされたヴォルトは、エアギャップされた性質を持つヴォルトであり、Amazon所有のアカウントに保存されます。これらのヴォルトはデフォルトでロックされており、コンプライアンスヴォルトロックによって不変性が確保されています。今年は、ランサムウェア対策を強化するために、マルチパーティ承認を追加しました。これは、組織全体でそのヴォルトの共有を承認するか、またはランサムウェアイベント中にリストアが必要な場合に、クォーラム、つまり5人中3人のユーザーの承認が必要な安全な信頼できるグループを作成できることを意味します。
この追加により、論理的にエアギャップされたヴォルトにセキュリティの重要な層を追加し、ランサムウェア対策を強化しました。さらに重要なことに、これにより復旧時間目標がより短くなることが可能になります。なぜなら、組織外での直接リストアが可能になるからです。同様に、直接的なカスタマーフィードバックリクエストに基づいて改善を続けてきました。最初の改善は、論理的にエアギャップされたヴォルトへの直接コピーのサポートです。以前は、バックアップを論理的にエアギャップされたヴォルトに保存するために、本番アカウントにコピーを作成してから、そのバックアップを論理的にエアギャップされたヴォルトにコピーする必要がありました。バックアップの2つのコピーを保持することで強化された機能を提供するために、私たちはそのように設計しましたが、この機能に対して異なるユースケースを念頭に置いていたお客様から直接フィードバックを受け取りました。
現在サポートしているのは、ワークロードアカウントから論理的にエアギャップされたヴォルトへ直接バックアップをバックアップすることです。
これらの追加的なユースケースに対しては、追加のコスト削減策も提供されるため、バックアップコピーを2つ保持する必要がなくなります。2番目の機能は、論理的にエアギャップされたコンテナに対する CMK、つまりカスタマーマネージドキーのサポートを拡張することです。設計上、論理的にエアギャップされたコンテナのデフォルト暗号化は Amazon が所有するキーであり、この背景にある考え方は、ランサムウェアイベントが発生してキーへのアクセスを失った場合でも、エアギャップされたコンテナ内のバックアップを復元できるようにするためです。
しかし、私たちは顧客が異なる要件を持っていることを理解しています。それが内部的なコンプライアンス要件であれ、外部的なものであれ。ですから、この機能により、論理的にエアギャップされたコンテナに保存されているバックアップをカスタマーマネージドキーで暗号化するオプションを提供しています。こちらは、顧客が現在、論理的にエアギャップされたコンテナをどのように実装しているかの典型的なリファレンスアーキテクチャです。 左側の隅には、顧客のワークロードアカウントが表示されており、ここで S3 バケットと EBS ボリュームを標準的な AWS Backup コンテナにバックアップしています。その後、これを論理的にエアギャップされたこのコンテナにコピーして、2番目の保護層と不変性を実現することができます。
下部には、キーコンテナアカウントを別に持つことで、キーへのアクセスを管理するために顧客が行うことがあります。ここで CMK が管理され、この場合、カスタマーマネージドキーを使用して論理的にエアギャップされたコンテナ内のバックアップを暗号化しています。上部には、論理的にエアギャップされたコンテナが2つの異なる目的で共有されている2つの追加アカウントが表示されています。上部のものはフォレンジックスアカウントです。これは、復元テストなど、バックアップに対するフォレンジックスを実行するために、顧客が通常ワークロードを分離したい場所です。
復元テストは、顧客が実際にバックアップを定期的に復元して、データが期待通りに存在することを検証できる別の機能です。バックアップの世界では、バックアップはその復元と同じくらいの価値しかないため、これらの非常に重要なワークロードに対しては、これを推奨しています。下部には、AWS recovery アカウントも表示されており、これはランサムウェアイベントまたはセキュリティの観点から発生する可能性のあるイベントという意味です。論理的にエアギャップされたコンテナにより、そのコンテナを組織またはアカウント全体で共有することができます。
ここで、マルチパーティ承認アクセスを追加しました。この新しいマルチパーティ承認機能により、例えば5人中3人が、論理的にエアギャップされたコンテナのこの共有を検証したことを確認して、クリーンな環境にそれを復元できるようにすることができます。ランサムウェア保護の同じスレッドで、Amazon GuardDuty との統合にも投資しており、バックアップのマルウェアスキャンを行っています。 バックアップはこの不変の方法で保存されていますが、顧客がバックアップがクリーンで復元しても安全であることを確認したいと考えていることも知っています。そのため、Amazon GuardDuty のサポートを追加しました。
ローンチ時点では、EC2、EBS、S3 のバックアップをマルウェアについてスキャンできるようになりました。これは 2 つの方法で実行できます。1 つは定期的なベースで行う方法です。つまり、バックアップ計画とポリシーの一部として、これらのバックアップのスキャンをオプトインできるようになったので、バックアップが取得される際にバックアップのスキャンを実行できます。したがって、異常が検出された場合、すぐに通知を受け取り、積極的に問題をトリアージできます。しかし、これが実現するのは安全なリストアも可能になるということです。
コスト最適化とコンテナ対応：S3バックアップティアリングとAmazon EKSサポート
顧客は最後に既知の良好な状態の時点にリストアできるようにしたいというニーズをよく聞きます。オンデマンドリストア機能を使用すれば、リストアを実行する前に、この場合は新しい一連の原則にリストアでき、オンデマンドリストアを実行してバックアップがクリーンであることを確認してから、そのアカウントに配置できます。ランサムウェア機能に加えて、既存のバックアップ機能のサポートも追加し、継続的に改善しています。このローンチでは、S3 バックアップティアリングにより、60 日以上の長期保持バックアップのコスト最適化を見つける方法が提供されます。
これがどのように機能するかというと、S3 バックアップの場合、バックアップと オブジェクトが 60 日以上保持されている場合、バックアップ内のオブジェクトをより低コストのストレージティアにティアダウンすることを選択できます。要件に基づいて、また、コスト削減の観点からどのような意味があるかに基づいて、これらのオブジェクトをティアダウンしたいタイミングを設定できます。
これが実際にどのように機能するかというと、60 日以上、設定した構成に応じて、1 回限りのオブジェクト遷移料金が請求されます。これはかなり名目的な金額になるはずで、その後、これらのオブジェクトはより低コストのストレージティアを活用します。これがユニークで、いわゆるコールドティアではないという点は、リストアやパフォーマンスに影響がないということです。したがって、これをティアリングオプションと呼んでおり、AWS Backup または他の用途から馴染みのあるコールドストレージのようには機能しません。
最後に、Palak が言及した他の主要なローンチの 1 つについてハイライトしたいのですが、Amazon EKS のサポートを追加しました。サポートする Amazon フットプリントを継続的に拡大していく中で、これは 2 つの理由から本当に興味深いローンチだと思います。1 つは、顧客が EKS をどのように使用しているか、そして Kubernetes の誕生以来、それがどのように移行してきたかというトレンドに従っているということです。今日、多くの顧客がステートレスではなく、ステートフルなワークロードをコンテナで実行しているのを見ています。これが本当にこの保護の必要性を駆動しているものです。
EKS バックアップについて説明すると、つまり皆さんの EKS クラスターの状態をバックアップするということです。Kubernetes オブジェクト、デプロイメント、クラスター上で実行されているすべてのリソース、そしてクラスターに接続されている永続ストレージをバックアップします。ローンチ時に、Amazon EBS、Amazon S3、そしてクラスターに接続されている Amazon EFS のサポートを追加しました。バックアップとして、これらすべてのコンポーネントのバックアップを取得し、複合的なリカバリーポイントを作成します。これにより、ストレージだけを復元することも、クラスター全体を復元することもできるようになります。
EKS に継続的な不変性を確保するために、これを有効にするためのエージェントは必要ありません。つまり、クラスターにタグを追加したり、既存のバックアップ計画に割り当てたりして、追加のリソースと一緒にバックアップできるようになります。このように、AWS Backup が何であるか、そして私たちの大きなローンチについてお見せすることができて嬉しいです。ただし、AWS Backup がどのように役に立っているかについては、実際の顧客から聞くのが一番です。ですから、Chuck をステージに招待して、ExxonMobil での AWS Backup のデプロイ方法と彼らの多くの学習について話してもらいたいと思います。
ExxonMobilの実践事例：プロアクティブ・レジリエンシーによるランサムウェア対策
ありがとうございます。ランサムウェア攻撃は、私たちのデジタル資産が直面する最も危険な脅威です。クラウド上でも、オンプレミスでも、さらには私たちの家でも、です。ランサムウェア攻撃から免れるものは何もありません。しかし、だからこそ私たちはここにいるのです。だからこそ、私たちは皆ここに集まっているのです。ランサムウェア攻撃からデジタル資産を保護するだけでなく、攻撃が実際に発生した場合にそれらの資産を復旧する方法について、戦略、ツール、テクニックを探索するためにです。
そしてそれは重要です。今日これからする会話は極めて重要です。なぜなら、近年ランサムウェア攻撃はグローバル企業を混乱させ、業務を停止させ、データを破損させ、復旧にかかる莫大なコスト超過と評判の損害をもたらしているからです。病院や医療システムもランサムウェア攻撃の対象ではありません。システムがロックされ、データが破損したため、患者を受け入れることができなくなった病院もあります。
Colonial Pipeline がランサムウェア攻撃を受けたとき、それは単なるサイバーセキュリティの問題ではありませんでした。それはアメリカ東部の燃料供給を混乱させるものでした。それは調査を引き起こし、復旧に数百万ドルの費用がかかりました。JBS Foods はシステムとデータの制御を取り戻すために 1100 万ドルを支払いました。
これらは孤立した事象ではありません。これらは広範な国家的影響を及ぼす事業継続性の失敗です。多くの専門家は、ランサムウェア攻撃は「いつ起こるか」の問題であり、「起こるかどうか」ではないと考えています。ほぼ避けられないものなのです。私たちは未来を予測することはできませんし、水晶玉に投資することもしません。ExxonMobil が投資してきたのは、私が「プロアクティブ・レジリエンシー」と呼ぶものです。これは、もし攻撃が実際に私たちのシステムに感染した場合に、迅速で安全な方法で復旧できるようにするための保険のようなものです。私たちは戦略的なサイバー復旧機能に投資しています。単なるバックアップではなく、安全で調整された、オンデマンドで利用可能な隔離環境であり、攻撃が発生した場合に重要なワークロードを復元できるようにするものです。
私の名前は Chuck Uwanna です。ExxonMobil の Strategy and Modernization 部門の Principal Application Architect です。また、私が説明した「プロアクティブ・レジリエンシー」を構築するために、複数の部門の専門家からなるチームをリードしてきました。私たちはそれを AWS で実現しました。そして今日、私はなぜそうしたのか、どのようにしたのか、そして重要な学びをお話しします。 AWS でサイバーセキュリティ機能を再構想するこのプロジェクトに着手したとき、私たちのミッションは明確でした。それは、攻撃が発生した場合に重要なワークロードの安全なパフォーマンスとオンデマンド復旧を実現することであり、私たちはこれをグローバルなフットプリント全体、つまりどこに位置していようとも、すべてのリソースに対して実現したいと考えていました。
私たちは 3 つのコア原則から始めました。1 つ目は不変性です。私たちはバックアップが改ざん防止されることを望みました。バックアップが取得されるたびに上書きされないようにしたいのです。2 つ目はオーケストレーションです。復旧は自動化され、反復可能である必要があります。私たちは手動介入が多く必要になることは望みません。なぜなら、私たちのシステムが攻撃されたとき、迅速に復旧できるようにしたいからです。そして最後に、同じくらい重要なのが隔離です。隔離は重要です。これは非常に重要です。なぜなら、復旧がクリーンで安全な環境で行われることを確保したいからです。誰もが望まないのは、攻撃からの復旧中に別のランサムウェア攻撃を受けることです。
なぜ私たちは AWS を選んだのか？ その背景にはいくつかの理由があります。 私たちは以前、オンプレミスで堅牢なサイバー復旧機能を持っていました。しかし、ご存知の通り、オンプレミスのハードウェアをスケールするのは難しいです。それは困難であり、また費用がかかります。私のような IT プロフェッショナルの大勢が必要になり、復旧演習を成功させるために対応する必要があります。これが 1 つの理由です。もう 1 つの理由は、過去数年間、私たちの会社がミッションクリティカルなビジネスアプリケーションを AWS に移行してきたということです。これらは大規模なデータ要件を持つアプリケーションであり、私たちはオンプレミスのデータセンターを AWS に移行しています。これらの要因により、私たちのサイバー復旧機能を本番システムに隣接して配置することは論理的にも戦略的にも理にかなっていました。
私たちはエアギャップ隔離を持っています。AWS プラットフォームから得られるスケーラビリティとネイティブセキュリティに加えて、不変で、エアギャップされた、隔離されたシステムを活用するという利点があります。また、オンデマンドでスピンアップできる自動化されたエフェメラルシステム環境を使用することもできます。テストするときにこれを行うことができ、実際の攻撃からの復旧時にも行うことができます。エフェメラル環境が私たちにとって重要である理由は、コストを削減できるからです。使用していないときに復旧用のステートフルな環境に対して料金を支払う必要がありません。しかし、これはまた私たちの攻撃面を減らします。なぜなら、悪意のある行為者は存在しないものを攻撃することはできないからです。
では、どうやってこれを実現したのか？要件を満たす、つまり先ほど述べたコア原則である不変性、オーケストレーション、分離という要件をどのように両立させたのか？これらの原則を AWS ソリューションとどのように調和させたのか？こうやってやったんです。少なくともこれは私たちが実現した方法の 50 パーセントです。バックアップとリカバリーの側面、つまり私たちのプロアクティブなレジリエンシー ソリューションを 2 つの部分に分けました。これは確認しやすくするためです。これは先ほど共有されたリファレンス アーキテクチャとそれほど違いません。
私たちは AWS Backup を活用しています。AWS Backup は、ワンスライト、リードメニーを確保するために使用するポリシーを提供します。これらのポリシーを強制し、バックアップを lag vault に不変的に保護することで、必要な分離と不変性を実現しています。ここで、ご覧いただいている図を説明させていただきたいと思います。白いボックスはワークロード組織です。これはエンタープライズ内のあらゆるもの、例えば本番環境の組織などが考えられます。そして、その長方形の内部に見える 3 種類のアカウントがあり、ピンク色のボックスで示されています。
バックアップ デリゲーション アカウント、最も小さいボックスは、この全体のオーケストレーターです。この全体の頭脳です。AWS Backup はポリシーを活用して、私たちが cyber application account と呼ぶもの内でバックアップをオーケストレーションします。これは長方形の上部に見える中程度のサイズのボックスです。ちなみに、cyber application account の内部には、ユースケースに応じて 1 つから複数の cyber application account が存在する可能性があります。私たちのエンタープライズでは、特定の基準に基づいて、私たちが cyber application と呼ぶアプリケーションを特定するための取り組みを行いました。その後、タグ付けメカニズムを活用して、AWS Backup に cyber application account 内のリソースをバックアップし、バックアップ vault に保存するよう指示しています。
ここで一点指摘したいのですが、先ほど共有されたように、AWS が過去数週間でロールアウトした新機能があります。それが direct to lag vault 機能です。これは私たちのエンタープライズにとって本当に効率化の機会です。なぜなら、以前は backup vault にバックアップをステージングしていたからです。それは必須でしたが、私たちにとって何の役にも立っていませんでした。direct to lag vault 機能により、backup vault にバックアップを保存する必要がなくなります。これは効率化になるだけでなく、コストも削減されます。私たちのワークロードについて計算してみたところ、約 7 パーセント削減されます。このステージング ステップを排除するだけで、総コスト回避の 7 パーセントです。ですから、direct to lag vault 機能をロールアウトしてくれた AWS チームに拍手です。
Cyber App Account の中では、アプリケーションをバックアップして、より大きなクリアエアギャップボルトに直接保存することができます。これについて触れたいのですが、それが矩形の下部に見える大きなボックスです。論理的にエアギャップされたボルトは、イミュータブルバックアップの中央リポジトリであり、ここに保存されます。そして 1 つのポリシーのおかげで、それらは上書きされることはありません。私たちは依然として AWS KMS キー、つまり AWS マネージドキーを活用していますが、ありがたいことに、カスタマーマネージドキーが利用可能になり、論理的にエアギャップされたボルトが配置されている Cyber Recovery Backup Account で使用できるようになりました。
このダイアグラムで言及したいもう 1 つのことは、私たちがこのすべての作業と思考プロセスを行っているのは、私たちの大切なもの、つまり光輪のついた小さなもの、バックアップが侵されない、手を付けられない、改ざんされていないことを確認したいからです。成功した復旧の鍵はここにあります。改ざんされていないクリーンなバックアップです。読みやすくするために、前のボックスである Cyber Recovery Backup Account を持ってきました。これにより、論理的にエアギャップされたボルトからリソースを復旧して、新しく作成した Cyber Account に復元する方法を確認できます。
少し前に、エフェメラリティが私たちにとって大きなことだと述べました。ステートフルな環境に対してお金を払いたくないし、それは攻撃面も減らします。ですから AWS Resource Access Manager Share、つまり RAM Share を活用することで、コピーではなく、論理的にエアギャップされたボルトを、復旧しようとしている新しい Cyber Application Account に共有することができます。それが配置されたら、サイバーセキュリティチームが以前に分析して、問題があると判断した復旧ポイントを見つけることができます。この復元プロセスは完全に自動化されています。数分以内に、前のフローでバックアップされた EC2 インスタンス、S3 バケット、EBS ボリューム、それらすべてが再び利用可能になります。すべてが自動化された方法で実現されます。
これが、AWS でプロアクティブなレジリエンス対策を実現する方法です。では、いくつかの重要なポイントについて話したいと思います。今日のこのプレゼンテーションから何も持ち帰らないとしても、攻撃に対する計画を立てるのに最適な時期はそれが起こる前だということを覚えておいてほしいです。レジリエンスは常に反応に優先されるべきです。常にです。ここで私たちが行ったことは、ランサムウェア攻撃からより強く生き残るためにプロアクティブなレジリエンス対策を展開することです。
データが破損しないようにするために、エアギャップボルトに保存されたイミュータブルバックアップを使用しました。復旧中に再び感染したくないので、破損から隔離されたエフェメラルな復旧環境を使用しました。しかし、ここまで話していなかった重要な部分があります。それは自動化された復旧テストです。バックアップを復旧のためにできるだけ頻繁にテストする必要があります。世界が終わったとき、悪いことが起こる可能性があるものはすべて起こります。ですから、エフェメラル環境で復旧を頻繁にテストできれば、バックアップと復旧プロセスへの信頼を高めることができます。
ランサムウェアについて、私は「いつ起こるか」という話で始めました。つまり、ランサムウェア攻撃は避けられないものだということです。だからこそ ExxonMobil では、水晶玉に頼るのではなく、積極的なレジリエンシー対策に頼っています。そして、それが具体的にどのような形なのかをお見せしました。
レジリエンシー対策は保険のようなものです。攻撃が発生したとき、私たちは無防備な状態にはなりません。迅速で安全な復旧のために万全の態勢を整えています。お時間をいただきありがとうございました。re:Invent の残りの時間も楽しんでいただければと思います。
JPMorgan Chaseのジャーニー：規制要件を満たすバックアップとリカバリー戦略
Chuck、ありがとうございます。Chuck が今説明してくれた素晴らしいカスタマー・ジャーニーですね。そして、JPMorgan Chase との素晴らしいカスタマー・ジャーニーと成果がもう一つあります。Rooshir Patel をステージにお招きしたいと思います。
Rooshir、また来てくれてありがとう。私たちは過去 5 年間一緒に仕事をしてきました。JPMorgan Chase の観点からデータ保護とは何か、そしてあなたのチームは何をしているのか教えてください。
基本的には、企業のデータをバックアップし、さらに重要なことに、データを復旧しています。私たちの観点からすると、ここにいくつかのスライドがあって、オフラインで読むこともできますが、もう少しインタラクティブにしようと思いました。私たちはビジネスがデータを復旧できるようにします。レジリエンシーと可用性があることを確保します。私たちが持っているソリューションが柔軟で、スケーラブルであることを確認します。
結局のところ、さっきステージでもおっしゃった通り、バックアップそのものについて誰も本当には気にしていないんです。重要なのはリカバリー能力で、ここ数年、私たちはあなたのチームとあなた自身と一緒にこの点に力を入れてきました。本当に避けたいのは、復旧できないデータを含むバックアップを持つことなんです。災害であれ、人的ミスであれ、ランサムウェアであれ、何が起きても、バックアップしたデータに基づいてアプリケーションをオンラインに戻すことができるようにしたいんです。それがバックアップが提供する保険なんです。
はい、バックアップは非常に重要ですが、復旧可能性も同じくらい重要です。あなたは本当にこのサービスの形成を手伝ってくれました。AWS Backup がどのようにあなたのニーズに対応するために進化してきたのか教えてください。あなたのニーズはどのように進化し、サービスはどのように進化してきたのでしょうか？
5年前、私たちの会話はデータの耐久性についてでした。コピー数についてではなかったんです。私たちは厳しく規制されており、オンプレミスとオフプレミスの両方で、論理的に分離されたエアギャップされたデータのコピーを確保したいんです。ここ10年間、オンプレミスで構築してきたソリューションは、Singapore MAS や香港の HKMA といった最も厳しい規制当局の要件を満たすために構築されています。
あなたとあなたのチームと一緒にやらなければならなかったことの多くは、オンプレミスで構築した同じタイプのガバナンスと同じタイプの構造、そしてインフラストラクチャ関連の機能を、AWS でネイティブに抽象化して構築できるようにすることでした。これが私たちのジャーニーで、オンプレミスとオフプレミスで同じ並行した機能と機能性を持つようにするにはどうするかということです。特にここ1年半、ハイブリッドワークロードに取り組んできた中でのことです。
完璧です。Rooshir が言及した通り、JPMorgan Chase のような銀行が対処しなければならない規制や可視性の要件、コンプライアンスの要件がたくさんあり、私たちが提供する多くのお客様もそうです。分離とレポーティングに関する私たちの要件は、ExxonMobil や JPMorgan Chase のようなお客様からの直接的なフィードバックから本当に出てきたものです。AWS Backup が過去1年間に実施してきた主要なコントロールと、あなたが今、保護戦略の中で影響を与えることができるようになったことについて、もっと詳しく教えてください。
私たちにとっては、バックアップがあることを示す必要があります。実際にバックアップがあることを示す必要があり、そしてそれをテストしたことを示す必要があります。私たちはあなた方と一緒にバックアップ計画とリストア計画を作成しました。私たちは重要なアプリケーションと復旧可能性のほとんどを設定された頻度でテストしています。あなた方は私たちがそれをかなりシームレスな方法で、そしてスケジュール化された方法でも実行できるようにしてくれています。私たちはそれを証拠として記録します。バックアップだけでなく復旧可能性も証拠として記録します。私たちはバックアップに関するテレメトリを提供するので、バックアップが成功したことを確認する能力があります。バックアップがある場合は、設定された頻度でそれを認証することを示します。バックアップがない場合は、バックアップが不要であることを認証することを示します。その上で、私たちは復旧可能性を見ています。ホストをワイプしてゼロから再構築する能力、イミュータブルバックアップから復旧する能力、そして SRDR イベントを実行する能力です。
これらすべてのことについて、私たちはあなたとあなたのチームと一緒に取り組んで、オンプレミスで行うことがオフプレミスで行うことに変わることを確認しました。オンプレミスで私たちに適用されるのと同じコントロールが、オフプレミスで使用しているのと全く同じコントロールです。オンプレミスでこれらのコントロールに一致させて証拠として記録するために何をしようとも、私たちは同じことができることを確認するためにあなた方と一緒に取り組みます。これは新しいワークロードが私たちと一緒に新しいワークロードを立ち上げるにつれて、スパンしています。
私たちは AWS を通じてネイティブにこれらのワークロードをバックアップして復旧できることを確認します。また、リージョンごとにライトアップされている機能があることを確認します。これは新しいリージョンでライブになるにつれて、私たちにとって集中的な取り組みでした。長年にわたって、私たちはクロスアカウントバックアップ、クロスリージョンバックアップ、Backup Vault を見てきました。そしてオンプレミスとオフプレミスで同じレベルのテレメトリを提供できることを確認するために強化したすべてのテレメトリ監視と一緒に。
私たちはまた、保存時の暗号化、転送中の暗号化、ロールベースのアクセス、および一般的なアクセス管理も見てきました。バックアップのライフサイクルを調査し、最小保持期間と最大保持期間を見ています。これらのバックアップに対して設定された時間を持つ運用復旧と、完全に異なるシステムを持つアーカイブをセグメント化しています。私たちはこれら 4 つの異なるタイプの保持期間についてあなた方と一緒に取り組んできました。また、Terraform を通じてタグ付けが存在することを確認する能力についても取り組んできました。タグ付けは正しく機能させるのにかなり時間がかかりましたが、それは私たちに可観測性とテレメトリを提供します。
最近では、あなた方が用意しているアラートと監視を見てきました。CoECD、Commvault、Veritas、NetBackup のようなベンダーを見ると、非常に細かいです。NetBackup には 2,000 のエラーコードがありましたが、あなた方はまだそれを持っていません。長時間実行されるバックアップやバックアップ失敗のような最小限のものがありますが、私たちはオンプレミスで持っているものと一致するようにその細かさを構築しています。
Rooshir が言及したように、私たちは、きめ細かい暗号化とアクセス管理を備えた、彼のようなお客様や皆さんの要件を満たすためにロードマップを強化しています。これらはバックアップ体制の鍵となるものです。バックアップへのアクセスが制限されていることを確認したいですし、適切な監視ツールと適切なバックアップライフサイクルが整っていることを確認したいのです。タグ付けは非常に重要です。なぜなら、バックアップにタグを付けるとすぐにポリシーによって検出されるからです。これが AWS Backup の素晴らしいところです。リソースに適切にタグを付けるだけで、AWS Backup によって検出され、スケール規模でバックアップ管理を実施できるようになります。これは銀行内で実施されてきたことです。
セッションの総括：継続的な進化と顧客フィードバックの重要性
コンプライアンスとガバナンスについても話しました。イミュータビリティを見ると、オンプレミスとオフプレミスで同じことについて話しています。それは、分離されたクレデンシャルバックアップを持つ能力と、バックアップを異なる場所に持つ能力です。私たちはクロスアカウント、クロスリージョンを備えており、Backup Vault も備えていますが、これらすべてが規制当局によって同じものとして見なされています。オンプレミスかオフプレミスかは関係ありません。原則として私たちがオンプレミスで行っていることと同じことを皆さんと一緒に行っていることを継続的に示す必要があります。それは継続的に監査され、規制当局は年ベースで RFI を送ってきます。
全体的な整合性を見ると、5年前は皆さんに「なぜ」について質問されていたと思います。今は「なぜ」についてはあまり質問されず、「どうやってこれを実現できるのか」「主な推進要因は何か」についてもっと質問されていると思います。サービスは確実に進化しています。今年の 2025 年のローンチで見られるように、ますます多くのユースケースとますます多くの要件に対応しています。私たちは非常に多くの新しいローンチを実施してきました。これは直接お客様の影響を受けています。お客様が私たちに何をする必要があるのか、いつそれを行う必要があるのかを教えてくれています。
これで、私たちのセッションを締めくくります。本日ここに来ていただき、時間を割いていただいたすべての皆さんに感謝申し上げたいと思います。簡単なアンケートがありますので、私たちの成果と皆さんが聞きたいことについてお知らせください。AWS Backup 関連の機能に関するセッションがもっとあります。ランサムウェア復旧、コスト最適化、全般的なレジリエンシーについて話しています。たくさんのセッション、チョークトーク、ホワイトボードセッションがあります。ぜひそれらに参加していただき、フィードバックをいただき、来年何を聞きたいのかお知らせください。
本当にありがとうございました。良い一日をお過ごしください。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion