こんにちは、コカコーラ大好きカジです。re:inforce 2025 Japan TourでAWSニューヨークオフィスに訪問し、その際に、AWSのオペレーショナル・レジリエンス（Operational Resilience）についてセッションを受講しましたので、レポートをお送りします。
オペレーショナル・レジリエンスは、金融機関が不測の事態に備え、重要な業務を継続するための重要な取り組みのこと

セッション概要

オペレーショナル・レジリエンスとは、アプリケーションやプロセスを設計する際に、特定の障害モードを予測し、顧客向けの運用を継続できるように対応し、さらにその経験から学んでレジリエンスプロセスに組み込んでいく方法

このセッションでは、以下の内容が紹介されました

• オペレーショナル・レジリエンスの世界的なトレンド
• 規制の厳しいワークロードにAWSを選ぶ理由
• 「レジリエンス方程式」- AWSと顧客の責任分担モデル
• 継続的なオペレーショナル・レジリエンスのプロセス

特に重要なポイントは、オペレーショナル・レジリエンスは一度実施して終わりではなく、継続的なプロセスであるということ

セッション内容

オペレーショナルレジリエンスのトレンド

過去4〜5年間でオペレーショナル・レジリエンスへの注目が世界的に高まっている。その大きなきっかけとなったのがパンデミックでした。物理的な世界で行われていた多くのプロセスがデジタルに移行する必要があり、デジタルプロセスへの依存度が高まった。

2021年、バーゼル銀行監督委員会がオペレーショナル・レジリエンスの原則を発表し、この分野のトレンドが始まりました。その後、イギリス、EU（デジタルオペレーショナル・レジリエンス法）、日本の金融庁など、世界中でオペレーショナル・レジリエンスに関する規制や議論が広がった
金融庁 バーゼル銀行監督委員会による「オペレーショナル・レジリエンスのための諸原則」及び「健全なオペレーショナル・リスク管理のための諸原則の改訂」の公表について

AWSが規制の厳しいワークロードに選ばれる理由

AWSは10年以上前から業界に特化したアプローチに投資してきました。顧客のビジネスを深く理解するために、各業界の専門家を採用し、クラウド導入の初期段階から成熟段階まで、あらゆるレベルの顧客をサポート

世界中の企業が最も重要なミッションクリティカルなワークロードをAWSに移行特に日本でも多くの企業がミッションクリティカルなワークロードをAWSに移行

規制当局の中には、オンプレミスの2つのデータセンターを維持することがレジリエンスの良いアプローチだと考える傾向がありましたが、現在では多くの規制当局が、クラウドが適切に構成されていれば、自社で2つのデータセンターを所有するよりも高いレジリエンスとセキュリティを提供できることを認識し始めている

レジリエンス方程式：責任共有モデル

オペレーショナル・レジリエンスを適切に実現するためには、AWSが担当する部分と、顧客が自身のアプリケーションとプロセスで実装する部分を理解することが重要。これが「レジリエンス方程式」

特に規制当局と連携する場合、AWS上での構成だけでなく、AWSのストーリーも説明できることが非常に重要

つまり、AWS側のオペレーショナル・レジリエンスと、顧客側で実装するプロセスと構成の両方を含めたエンドツーエンドのストーリーが必要

顧客の責任範囲

1. アーキテクチャの決定

   • どのAWSサービスを選択するか
   • 単一のAWSリージョンで構築するか、複数のリージョンで構築するか

2. ソフトウェア実装

   • AWSにデプロイするコード
   • コードのパッチ適用、更新、リリース方法

3. 運用プラクティスとカルチャー

   • AWS上のアプリケーションを監視するプロセス
   • インシデント対応プロセス
   • オペレーショナル・レジリエンスに焦点を当てた文化の構築

AWSの責任範囲

1. AWSインフラストラクチャ

   • データセンター、サーバー、リージョン、アベイラビリティゾーン

2. AWSサービスの設計

   • EC2のようなサービス（顧客がアベイラビリティゾーンを選択）
   • S3のようなサービス（顧客はリージョンのみ選択し、AWSが情報の配置を担当）

3. AWSサービスチームの運用とカルチャー

   • サービスチームの運用方法
   • オペレーショナル・レジリエンスのためのプロセス

AWSの基盤的レジリエンス

AWSのインフラストラクチャ

AWSは現在、37の地理的リージョンと117のアベイラビリティゾーンを持っている。アベイラビリティゾーンは、冗長なファイバー、冗長な電源を備えた1つ以上のデータセンターで構成されている。各AWSリージョンは最低3つのアベイラビリティゾーンで構成されており、これは他のクラウドサービスプロバイダーとは異なるAWS独自の定義

重要な概念として「障害分離境界」。これは、問題が発生した場合に、その影響を1つのデータセンターか1つのアベイラビリティゾーン、最大でも1つのリージョンに限定するように設計されていることを意味している

AWSのインフラストラクチャとサービスを構築する際には、以下のようなリスクを考慮

1. 環境リスク

   • 洪水や地震などの自然災害
   • リージョンとアベイラビリティゾーンの配置は、特定の環境問題が複数のリージョンに同時に影響を与えないように設計

2. ソフトウェアリスク

   • クラウドの更新は非常に頻繁（1日に何度も）
   • 中央集中型のパイプラインで検証され、インフラ全体に展開される前に確認

3. 物理的リスク

   • ハードウェア障害を想定した設計
   • 自動的に回復または障害から切り替え

4. 悪意のある行為者/サイバーセキュリティリスク

   • サービス拒否攻撃、ボットネット、マルウェアなど
   • インフラストラクチャとセキュリティチームが脅威を特定し軽減

AWSのサイバーセキュリティ能力

AWSのグローバルな規模により、多くの民間企業よりも大規模にサイバーセキュリティの脅威を特定する能力がある

• グローバルインフラストラクチャ全体に約10,000のセンサーを配置
• 毎日7億5,000万件の潜在的な脅威インタラクションを観察
• そのうち4億件が悪意のあるものと判断

この脅威インテリジェンス情報は、GuardDutyなどのAWSサービスに組み込まれ、顧客を保護

脅威の検出だけでなく、脅威の軽減も重要例えば、Cenarisというツールは

• 2023年5月から2024年4月の間に、パブリックS3バケットへの240億回以上のアクセス試行を拒否
• 同期間に、Amazon EC2上の脆弱なサービスを発見しようとする2.6兆回の試行を防止

個人的に感じたこと

• AWSのセキュリティ対策の規模は圧倒的。自社でこのレベルのセキュリティ監視を実現するのは、コスト的にも技術的にも非常に困難。ただし、これはあくまでAWS側の対策であり、自社のセキュリティプログラムや監視は引き続き必要

AWSサービスチームの運用モデル

AWSのオペレーショナル・レジリエンスを理解するためには、サービスチームの運用方法も重要

1. サービス所有権モデル

   • サービスチームはコードを書くだけでなく、インフラストラクチャにデプロイ
   • コードの継続的なメンテナンスも担当
   • サービスに問題が発生した場合は、サービスチームが対応（深夜でも呼び出し対応）

2. ソフトウェアデプロイメント/変更管理

   • CI/CDパイプラインで各変更を自動的に検証
   • デプロイは段階的：単一サーバー → サーバーフリート → 1つのアベイラビリティゾーン → 残りのアベイラビリティゾーン → 全AWSリージョン

3. エラー修正プロセス

   • 問題発生時に原因を分析
   • 同様の問題が他のAWSサービスでも発生する可能性を検討し、予防措置を講じる
   • 学習サイクルを継続的に実施

4. 運用準備レビュー

   • 過去の学習を新しいサービスのプロダクション展開前に適用

クラウドにおけるオペレーショナル・レジリエンス（顧客側の責任）

AWS Well-Architected Framework

AWSのベストプラクティスに従ってアプリケーションを構築しているかを確認するための重要なツールこれは、すべての顧客から学んだ教訓を体系化したもので、デプロイ前や継続的に自己評価。

Well-Architected Frameworkは時間とともに進化するため、数年前に一度実行しただけでは不十分な可能性があり、セキュリティ要素などは、新たな教訓に基づいて更新

このフレームワークは、以下の側面からワークロードを評価

• 運用上の優秀性
• セキュリティ
• 信頼性
• パフォーマンス効率
• コスト最適化
• 持続可能性

オペレーショナル・レジリエンスに最も関連するのは、「運用上の優秀性」と「信頼性」の2つの柱

個人的に感じたこと

• Well-Architected Frameworkは非常に実用的なツール特に新しいプロジェクトを始める際や、既存システムの見直しを行う際に、チェックリストとして活用すると効果的
• 出力される推奨事項は具体的で、エンジニアチームに直接渡せるアクションアイテムになる

レジリエンスライフサイクル

オペレーショナル・レジリエンスは一度きりのものではなく、継続的なプロセスAWSは顧客ベースを分析し、オペレーショナル・レジリエンスをワークロードに組み込むプロセスを理解し、フレームワークとしてまとめた

レジリエンスライフサイクルは以下のステージで構成

1. 目標設定

   • アプリケーションに必要なレジリエンスのレベルを決定（ユースケースによって異なる）

2. 設計と実装

   • アプリケーションのレジリエンスに関する決定
   • 例：単一リージョンにデプロイするか、複数のAWSリージョンにデプロイするか

3. 評価とテスト

   • クラウドの利点：テスト環境でも本番環境と同じハードウェア、同じサービスを使用
   • AWS内の障害分離境界に沿ってテストし、異なるシナリオでアプリケーションがどのように応答するかを確認

4. ワークロードの運用

   • AWSサービス側と自社アプリケーションの両方のモニタリング
   • アプリケーションのライフサイクル全体を通じて障害や中断を監視

5. 対応と学習

   • 問題が発生した場合の原因理解
   • プロセスを更新して同様の問題の再発を防止

このサイクルの出力は

• ポートフォリオ内で最も重要なアプリケーションの優先順位付け
• より良い運用プラクティスの特定
• 過去の失敗から学び、緩和能力を構築

レジリエンスライフサイクルをサポートするAWSサービス

AWSは、レジリエンスライフサイクルの各段階をサポートするサービスを提供

1. 目標設定

   • 主に会議室で行う作業：どのアプリケーションが最もレジリエンスを必要とするかを決定

2. 設計と実装

   • Well-Architected Frameworkを使用して設計決定をサポート

3. 評価とテスト

   • AWS Fault Injection Simulator：アベイラビリティゾーンが利用できない場合など、様々なシナリオでアプリケーションの動作をテスト

4. ワークロードの運用

   • Amazon CloudWatch：ログ機能を提供し、環境内の異常を検出
   • AWS Health Dashboard：AWSリソースの健全性を確認

5. 対応と学習

   • AWS Config：リソースを監視し、望ましい構成から逸脱した場合に検出
   • 警告または自動修復機能で、リソースを希望の状態に戻す

個人的に感じたこと

• AWS Fault Injection Simulatorは特に価値がある。
• 本番環境に影響を与えずに障害シナリオをテストできるため、実践的な障害テストを安全に実施

パートナーエコシステム

オペレーショナル・レジリエンスの取り組みをすべて自社で行うことは可能ですが、多くの顧客はサポートを求めている。AWSには14万以上のパートナーがおり、AWSに関する深い知識を持ち、さまざまな領域をカバーこれらのパートナーの70%は米国外に本社を置いており、オペレーショナル・レジリエンスの取り組みをサポート

リソースと次のステップ

AWSアカウントチームに連絡すれば、レジリエンスアプローチについてサポートを受け、日本や世界中の専門家チームとつながることができる。また、オペレーショナル・レジリエンスに関するより詳細なワークショップも提供

AWSの文化の重要な要素の一つは、学んだことをコミュニティに共有することAWSは定期的にビデオシリーズやホワイトペーパーを更新し、すべての人が学べるようにしている

まとめ

オペレーショナル・レジリエンスは、特に規制の厳しい業界において世界的に注目されているトピックパンデミックを契機に、デジタルプロセスの重要性が高まり、オペレーショナル・レジリエンスへの関心が世界中で高まっている。

オペレーショナル・レジリエンスを適切に実現するためには、「レジリエンス方程式」を理解することが重要これは、AWSが担当する基盤的なレジリエンス（インフラストラクチャ、サービス設計、運用プロセス）と、顧客が担当するクラウド上のレジリエンス（アーキテクチャ決定、ソフトウェア実装、運用プラクティス）の両方を含む。

特に重要なのは、オペレーショナル・レジリエンスは一度きりの取り組みではなく、継続的なプロセスであるということ目標設定、設計と実装、評価とテスト、ワークロードの運用、対応と学習という5つのステージからなるレジリエンスライフサイクルを通じて、継続的に改善していくことが必要

AWSは、Well-Architected FrameworkやFault Injection Simulatorなどのツールを提供し、顧客のオペレーショナル・レジリエンスの取り組みをサポートまた、14万以上のパートナーエコシステムも、顧客のオペレーショナル・レジリエンスの実現を支援

オペレーショナル・レジリエンスは、規制当局の要件を満たすだけでなく、顧客に信頼性の高いサービスを提供するために不可欠な要素AWSと顧客が協力して、共有責任モデルに基づいた強固なオペレーショナル・レジリエンスを構築することが、今後ますます重要。

個人的に感じたこと

• お客様からBCP関連について聞かれた時に、耐障害性ライフサイクルフレームワーク: 耐障害性向上への継続的なアプローチ - AWS 規範ガイダンス の資料について知らなかったので、今後は紹介したいと思います。
• オペレーショナル・レジリエンスは単なる技術的な問題ではなく、組織文化やプロセスも含めた包括的なアプローチが必要と思いました。
• 特に「対応と学習」のフェーズを重視し、障害から学び、継続的に改善していく文化を構築することが重要で、Well-Architected Frameworkを定期的に適用し、新しいベストプラクティスを取り入れることで、レジリエンスを継続的に向上させることができると感じました。