「障害が起きたら復旧できるはず」という設計上の想定は、実際に障害を起こしてみるまで検証されていません。この考え方を体系化したのがカオスエンジニアリングであり、 AWSではこれをAWS Fault Injection Service (FIS) で実現します。

SAA レベル：基礎概念

カオスエンジニアリングの基本思想

システムに意図的に障害（インスタンス停止、レイテンシ注入、ネットワーク断等）を注入し、実際にシステムが設計通りに耐性を発揮するかを検証する手法
「障害は起きる」という前提に立ち、本番相当の環境で事前に弱点を発見する

SAA 試験のポイント

カオスエンジニアリングは、闇雲に障害を起こすものではなく、仮説（「このインスタンスが停止しても、Auto Scalingにより自動復旧するはず」）を立てて、それを検証する科学的なアプローチです。この基本思想の理解がSAAで問われることがあります。

AWS FISの基本要素

実験テンプレート: どのリソースに、どのようなアクション（停止、CPU負荷注入等）を、どれくらいの時間実行するかを定義
停止条件 (Stop Condition): CloudWatchアラームと連携し、想定以上の悪影響が出た場合に実験を自動停止する安全装置

SAP レベル：高度な設計シナリオ

実験テンプレート設計のベストプラクティス

SAP 試験のポイント

SAPレベルでは、いきなり本番環境の広範囲に障害を注入するのではなく、影響範囲を最小限に絞ったスコープ（特定のAZの一部インスタンスのみ等）から始め、段階的に対象範囲を広げていく実験設計が問われます。また、実験対象には必ずタグでフィルタリングし、意図しないリソースへの影響を防ぐ設計が必須です。

停止条件による安全策

SAP 試験のポイント

本番環境で障害注入実験を行う際、想定以上にビジネスへ悪影響が出た場合に、実験を即座に中断する仕組み（停止条件）が必須です。「エラー率が5%を超えたら実験を自動停止する」といったCloudWatchアラームと連携した安全装置なしに本番実験を行うことは、SAP試験ではリスクの高いアンチパターンとして扱われます。

設計上の落とし穴

「本番環境でカオスエンジニアリングを行うこと自体が危険」という判断で、開発環境だけでの検証に留めるのも不十分です。開発環境と本番環境ではトラフィックパターンやスケールが異なるため、真の耐性検証には、適切な安全策（停止条件、限定的なスコープ、事前のステークホルダーへの通知）を伴った本番環境での実験が必要というのがSAPレベルの認識です。

代表的な実験シナリオ

シナリオ	検証したいこと
AZ全体の障害シミュレーション	マルチAZ構成が実際にフェイルオーバーするか
APIレイテンシの注入	サーキットブレーカー・タイムアウト設定が機能するか
DBへの接続障害	アプリケーションが適切にリトライ・縮退運転するか

Game Day（実践訓練）への組み込み

FISによる障害注入実験を、チーム全体で参加するGame Dayという定期訓練イベントに組み込むことで、技術的な検証だけでなく、インシデント対応の運用プロセス（誰が何を確認し、どう意思決定するか）も同時に鍛えることができる

まとめ

SAA: カオスエンジニアリングの基本思想、FISの実験テンプレートと停止条件の役割を理解する。
SAP: 段階的にスコープを広げる実験設計、停止条件による安全な本番実験、Game Dayとの組み合わせによる運用プロセスの検証ができる。

次は レジリエンス強化のリファクタリングを見ていきましょう。