AWS Summit Japan 2025 に見る Resilience at AWS

アマゾンウェブサービスジャパン合同会社パートナーソリューションアーキテクトの石倉です。2025 年 6 月 25 、26 日に AWS Summit Japan が開催され、2 日間で 160 以上のセッションと 270 以上のブース展示が行われました。その中には、高い信頼性要件に対し工夫を凝らしながら耐障害性の高いワークロードを構築したお客様事例セッションもありました。また、AWS セッションや AWS Village のブース展示においても、レジリエンスに関するトピックを多数お届けしていました。本ブログでは、AWS Summit Japan 2025 よりレジリエンスに関するセッション、ブースの内容をサマリーでご紹介します。

事例セッションより

ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略～勘定系移行までの道のり～

ソニー銀行様

ソニー銀行様では、ビジネスアジリティの飛躍的な向上を目指し、長期的な視点でクラウドシフト戦略を推進されており、2025 年 5 月新勘定系システムをクラウドネイティブなアーキテクチャにて AWS 稼働をスタートしました。稼働にあたり、大阪リージョンを活用したマルチリージョン構成にすることにより、基幹システムで求められる高い可用性を実現した事をご説明いただきました。移行時のサポートしてAWS エンタープライズサポート、AWS Countdown Premium ティアを活用頂き万全の体制にて移行を完遂した事もご説明頂きました。

国内金融業界初： AWS 上での勘定系システム移行の成功と次世代バンキングの展望

SBI Security Solutions様

SBI Security Solutions 様は AWS 上で稼働する銀行勘定系システム「次世代バンキングシステム」のサービスを開始し、2024 年に福島銀行で本番稼働を開始し、2025 年には島根銀行を 2 行目として稼働を予定しています。マルチ AZ・マルチリージョンで構成されており、AZ 障害は 1 分で自動回復、リージョン障害は 1 時間で切り替えを可能にしています。レジリエンシーを高めるためには CI/CD パイプラインの実装やリージョン切り替えのワークフロー整備といった「定型運用作業の自動化」と、オブザーバビリティを活用した「人の判断の迅速化」が重要と述べています。またこれには AWS からサポートを迅速化させるサービスである AWS Incident Detection and Response (IDR) の採用も大きな要因となっています。今後は AI Ops などを活用し、非定型作業の自動化も推進していくそうです。

AWS セッションより

基調講演：ビルダーと描く新たな価値創造

代表執⾏役員社⻑⽩幡晶彦がホストを務め、 AWS のグローバルリーダーによる戦略的なビジョンや先進的な取り組みをされているゲストの声とともに、 AWS を活⽤してイノベーションを進めるビルダーのみなさまへのメッセージをお届けしました。その中でも日本の高い水準にも対応できるレジリエンスを実現する Amazon Connect Global Resiliency （以下、ACGR）の日本での申し込み受付開始を発表しました。(注：2025 年 6 月 30 日に日本での一般提供を開始しました)
ACGR は Amazon Connect の機能で、 AWS アジアパシフィック（東京）リージョンで Amazon Connect インスタンスをご利用されているお客様が、AWS アジアパシフィック（大阪）リージョンのインスタンスに設定を同期し、フェイルオーバーできるようになりました。これによって、お客様は地域的な災害や障害が発生した場合のダウンタイムを最小限に抑えることが可能になります。また、データを日本国内に保持しながら、コンタクトセンターの可用性を高めることができます。

公共機関におけるクラウドレジリエンス～障害からより早く回復するシステムの作り方～

AWS シニアパートナーソリューションアーキテクト讃岐和広より、レジリエンスライフサイクルフレームワークを活用したシステムの回復力強化について解説するセッションをお届けしました。デジタル社会の実現に向け変化を続ける環境において、従来の「障害を防ぐ」アプローチには限界があり、「障害が起きてもすぐ回復する」レジリエンスなアプローチへの意識変革が重要であることを強調しました。レジリエンスライフサイクルフレームワークの 5 つのステージ（目標設定、設計と実装、評価とテスト、運用、対応と学習）について、まず目標設定では SLO や RTO / RPO の目標値を定めることが重要であり、例えば地方公共団体情報システム非機能要件の標準【第1.1版】では RTO 12 時間以内、RPO 1 営業日前、サービス稼働率 99.5 % といった具体的な目標値が定められていることを紹介しました。また、ミッションクリティカルな重要業務では「静的安定性」の確保が重要であり、障害時でもシステムが変更を加えることなく通常通り動作し続けるよう、あらかじめ十分なキャパシティを確保しておくことを解説しました。

サービス停止を防ぐ AWS 活用術: コンテナワークロードにおける高可用性設計の実践

AWS シニアソリューションアーキテクト堀内保大より、コンテナワークロードにおける高可用性設計を解説するセッションをお届けしました。「Everything fails, all the time」という Werner Vogels の言葉の通り、障害は必ず発生することを前提として、いかに高速に復旧させるかが重要なポイントです。セッションでは、高可用性設計の 2 つの柱として「耐障害性」と「障害分離」を詳しく解説しました。耐障害性では、マルチ AZ 冗長化による配置戦略や、ヘルスチェック・サーキットブレーカー・リトライといった通信の信頼性確保について説明。障害分離では、トラフィックを AZ 内に閉じる AZ 独立性の設計と、Amazon Application Recovery Controller を活用した AZ 退避の仕組みを紹介しました。また、完全な停止ではなく散発的・部分的な劣化が発生するグレー障害についても触れ、外形監視による SLO 監視と静的安定性を考慮した AZ 退避の重要性を説明しています。Amazon EKS や Amazon ECS での実装例も交えながら、具体的な障害シナリオを通じてアーキテクチャがどのように機能するのかを確認できる、コンテナ環境における実践的な高可用性設計パターンを学べる内容となっています。

AWS におけるグレー障害の検出と対策

AWS ソリューションアーキテクト安藤麻衣より、見落としがちなグレー障害の検出と対策について解説するセッションをお届けしました。グレー障害は完全なシステム停止ではないものの、一部のユーザーにのみサービス品質の低下をもたらす検出困難な障害で、システム全体では正常に見えるが顧客側では問題が発生している状態を指します。従来のヘルスチェックでは検知できない小さなエラーに対し、Amazon CloudWatch の Contributor Insights を活用することで、特定のユーザーやインスタンスで発生するレイテンシー問題などを特定する方法を紹介しました。さらに複合アラームを使って AZ レベルでの障害を精密に検知する具体例を紹介しています。対応策では Amazon Application Recovery Controller のゾーンシフト機能を使った Availability Zone の切り離しを中心に解説。問題のあるAZを一時的に切り離すことでシステム全体の健全性を保つ手法です。この実現にはAZ独立性（AZI）の考慮が重要で、異なる AZ 間の不要な通信を防ぎ AZ 内でリソース利用を完結させる設計についても言及しています。最後に AWS Fault Injection Service を使った事前の障害訓練や、組織全体でレジリエンス文化を醸成することの重要性を強調しました。

設計から運用まで~ AWS サポートを徹底活用して重要システムを安定稼働させよう

AWS シニアクラウドサポートエンジニア古野俊広より、重要システムの安定運用とレジリエンス向上を支援する AWS サポートサービスについて解説するセッションをお届けしました。システム障害による損失の大きさと、耐障害性の高いアーキテクチャ構築やマイグレーション時の課題を背景に、AWS が提供する包括的なサポートサービスを紹介しました。AWS Countdown Premium（AWS CDP）では、設計段階からローンチ後まで専門チームが継続的にサポートを提供します。アーキテクチャレビュー、設定項目の確認、負荷試験時のメトリクス分析など、サポートエンジニアが実際のリソース設定を直接チェックし、移行フェーズでの迅速な情報共有とエスカレーション支援も行います。AWS Incident Detection and Response（AWS IDR）では、24 時間 365 日体制でシステム監視を行い、障害発生時には 5 分以内に専門エンジニアが対応を開始します。IDR は SBI セキュリティ・ソリューションズ様にご利用いただき、日本語サポートにより迅速な対処を実現できています。AWS Support Automation Workflows（AWS SAW）は、よくある技術的問題に対する自動化されたトラブルシューティングを提供し、障害復旧時間の短縮を実現します。

アーキテクチャ道場 2025 – 実践編！

AWS ソリューションアーキテクトがモダナイゼーションとレジリエンスの 2 つのお題に対して、実際のお客様事例をもとにアーキテクチャを紹介します。その中で SBI Security Solutions 様における銀行の勘定系システム全体のレジリエンスを考えるお題があり、勘定系システムに求められる高い信頼性の基準を満たしつつ、業界特有の通信方式（セッション維持や固定 IP 接続など）という制約にどう対応するかが解説されています。実装方針としては、ノードや AZ 障害にはマルチ AZ のアクティブ/アクティブ構成で、リージョン障害にはアクティブ/パッシブの構成を採用されています。また、中継センターが外部との接続方式を緩衝するよう設置することで、弾力性のあるクラウドの特性を活かしてシステム全体のレジリエンスを高められていました。切り替え時にはヒューマンインザループを採用しつつ、判断を行うフローを自動化したり、判断を待たずにできる準備を並行で走らせるなどの工夫があり、業界問わず参考になる例と思います。

AWS ブース展示より

ブース：レジリエンスブース＆大阪リージョンブース

レジリエンス・大阪リージョンブース資料はこちらからダウンロード頂けます。

レジリエンスブース

レジリエンス関連プラクティス ( コントロールプレーン / データプレーンの特性、静的安定性等) 、関連の AWS サービス、AZ 障害に備えるための手法、ディザスタリカバリ (DR) に対応する為の戦略をご案内しました。AZ 障害に対応するための手法として Amazon Aplication Recovery Controller のデモを実施しました。ディザスタリカバリ (DR) 戦略については、RPO / RTO に応じた戦略とそれに紐づく具体的なアーキテクチャ説明を中心にご案内いたしました。

大阪リージョン・たこ焼きブース

大阪といえば、たこ焼き。たこ焼きがいつでも注文できるデモアプリを展示いたしました。デモアプリは、東京＆大阪マルチリージョンによるアクティブアクティブ構成で、災害耐性の向上、RTO / RPO の短縮、そして低レイテンシーを実現しています。AWS Fault Injection Service による障害注入実験、Amazon CloudWatch Application Signals、Amazon Managed Grafana によるマルチリージョンオブザーバビリティにより、リージョン障害がおきてもアプリの正常稼働を確認できるデモを実施しました。

大阪リージョン・データセンターブース

大阪リージョンの有用性をテーマに、データセンターの災害対策についてご紹介しました。大阪リージョンデータセンターの災害対策として、津波による浸水被害を受けない設計、「免震構造」により、震度６弱の揺れでは影響を受けない設計であることをご案内しました。免震構造の模型展示も行いました。

金融ブース：進化する金融 × レジリエンス（ゼロダウンタイムを実現するフェイルオーバー/金融システムを守るサイバーレジリエンス）

金融ブースの概要資料はこちらからダウンロード頂けます。

こちらのブースでは、金融システムのミッションクリティカル要件とサイバーレジリエンス強化について、マルチリージョン構成による可用性確保や回復力評価など、具体的な実装方法をデモで紹介していました。勘定系システムを例に、Aurora DSQL をマルチリージョンで構成し、障害発生時においてもサービスのゼロダウンタイムを実現する構成や、マイクロサービスを採用した顧客接点ようモバイルアプリを例にした障害状況に応じた挙動の振る舞いを意識したアーキテクチャパターンをご紹介しました。サイバーレジリエンス強化については、クラウドとオンプレ環境両方におけるバックアップデータ保護やフォレンジック環境の構築、および復旧フローについて具体的な実装例とともにご紹介しました。主に、AWS Backup や Amazon S3 を用いたVault Lock の機能でバックアップデータを保護しつつ、Logically air-gapped vault でリージョンや AWS アカウントを跨いだデータ隔離を行うことで攻撃者からのバックアップデータ侵害を防ぐアーキテクチャとしています。

Chaos Kitty で楽しくインシデント対応の基本を学ぼう！

Chaos Kitty は、AWS のアーキテクチャを物理的に表現し、インシデント対応の体験学習ができるソリューションです。Web 3 層の Web アプリケーションに異常を注入し、異常を修正するまでのタイムを競うことで、ゲーム感覚でインシデント対応の体験が行うことができます。今までの Chaos Kitty は IoT 機器での操作を前提としており、実際に皆様の環境でお試しいただくにはハードルが高いところがありました。今回はアーキテクチャを一部改修し、AWS CDK を活用した IaC 化を行うことで IoT 機器なしでも簡単にデプロイ可能となりました。さらに Amazon CloudWatch Application Signals を使った標準的なダッシュボードを使い、サービスとして重要な指標を取得して可視化できるようにしています。また、生成 AI を利用した障害分析効率化を図る AIOps を体感いただくために、AWS Japan の Solutions Architect が開発した障害分析ソリューション Failure Analysis Assistant (FA2) との連携も可能になっています。

まとめ

障害へのアプローチとして、障害は起こる事を前提し、早く復旧するためのアプローチ（レジリエンス、回復力）を検討頂く事が重要です。今回の Summit では、このプラクティスを踏襲、実践するためのヒントが多く確認できる内容となっておりました。特に勘定系といったミッションクリティカルなシステムの AWS 稼働事例、復旧を短縮するための AWS サービス、サポートサービスの活用が確認できる内容になっておりました。これからミッションクリティカルなシステムや高い可用性要件が求められるシステムのクラウド移行を検討頂いている皆様に少しでも参考になれば幸いです。

著者
石倉徹
パートナー技術統括本部シニアパートナーソリューションアーキテクト

安藤麻衣
ストラテジックインダストリー技術本部通信第三ソリューション部ソリューションアーキテクト

河角修
フィナンシャルサービスインダストリー技術本部銀行ソリューション部ソリューションアーキテクト

Amazon Web Services ブログ