resilience-program-design について
組織全体のレジリエンスプログラムを設計するための計画レベルの指針を提供します。ビジネス上の重要度に応じたポリシー、目標、活動頻度、安全基準の策定を支援します。
主な機能
- 01ビジネス重要度に応じたポリシー階層化
- 02可用性と復旧目標の設定
- 03レジリエンス活動の頻度計画
- 04最小権限と認証情報の基準策定
- 05本番環境の障害注入とレポートアクセスの管理
活用シーン
- 01重要度別のサービス向けポリシー策定
- 02年間のレジリエンス演習とレビューの計画
- 03レジリエンス自動化のセキュリティ要件策定
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ aws/ agent-toolkit-for-aws --skill resilience-program-designインストール後、Claude Code で/resilience-program-designを入力して読み込まれたか確認します。
詳細
レジリエンスプログラムの設計
概要
組織のレジリエンスプログラムに関する計画レベルのガイダンスです。ポリシーを階層別に構成する方法と、レジリエンス活動を実施する頻度を説明します。
組織全体のレジリエンスポリシーを構成する
サービスごとにポリシーを作成するのではなく、階層型のポリシーモデルを推奨します。ビジネス上の重要度に基づいてサービスを分類し、それに応じてポリシーの目標を設定します。
- 可用性 SLO — 重要度が高いほど引き上げます。API は固定された SLO 値のみを受け付け、それ以外の値は拒否します。そのため、ハードコードされた一覧に頼るのではなく、有効な値を API/ドキュメントで確認してください(例:
aws resiliencehubv2 create-policy helpまたは Resilience Hub のドキュメント)。例としては、99.9/99.95/99.99などの値が考えられます。 - RTO/RPO — 重要度が高いほど短縮します(重要なサービスは一桁の分、重要度が低いサービスは数時間)。
- DR アプローチ — 重要度に合わせて選択します(重要度が高いほど積極的なアプローチ)。API の DR アプローチの列挙型から値を選び、有効な値の範囲を API/ドキュメントで確認してください(例:
aws resiliencehubv2 create-policy help)。例としては、ACTIVE_ACTIVE…BACKUP_AND_RESTOREがあります。
例(参考例です。推奨する前に、実際の列挙値を API で確認してください):決済/認証 → 99.99 +一桁の分の RTO + ACTIVE_ACTIVE、社内ツール → 99.9 +数十分の RTO + WARM_STANDBY、開発/テスト → 99.9 +数時間の RTO + BACKUP_AND_RESTORE。
矛盾するポリシー(例:最大の SLO 99.99 と BACKUP_AND_RESTORE の組み合わせ、またはマルチリージョンの RTO がマルチ AZ の RTO より短い設定)を避けるよう注意を促してください。
レジリエンス活動を実施する頻度(実施周期)
レジリエンス活動の実施頻度を尋ねられた場合は、次の最低限の実施周期を推奨してください。
- 継続的: ARC ゾーン自動シフトの演習実行(自動化)
- 毎週: Resilience Hub の検出結果ダッシュボードを確認
- 毎月: FIS 実験を実施(単一サービスのフォールトインジェクションテスト)
- 四半期ごと: サービス横断の GameDay
- イベント発生時: 本番インシデントの発生後、および大規模デプロイの前後
セキュリティに関する考慮事項
プログラムレベルのガイダンスです。策定する標準にセキュリティを組み込んでください。
- 最小権限を標準化する: テンプレートとポリシーで、すべてのレジリエンス用ロール(Resilience Hub 呼び出し、FIS 実行、ARC オペレーター)に最小権限を適用し、リソースをスコープ指定するよう求めてください。また、信頼ポリシーに
aws:SourceArn/aws:SourceAccount条件キーを設定し、混乱した代理人によるアクセスを防止してください。 - 有効期間の短い認証情報を義務付ける: すべてのレジリエンス自動化では、有効期間の短い認証情報を使って IAM ロールとして認証するよう、プログラム標準として義務付けてください(ロールの引き受け、AWS SSO、インスタンスプロファイルなど)。長期間有効なアクセスキーを持つ IAM ユーザーは決して使用しないでください。これらのロールは、特権を伴い、破壊的な操作につながる可能性があるためです。
- 暗号化を義務付ける: レポート/状態バケットの SSE-KMS を各階層のベースラインに含め、通信時の暗号化(TLS)も強制してください。たとえば、バケットポリシーに
aws:SecureTransportが false の場合に拒否する条件を設定し、API アクセスを HTTPS のみにします。 - 本番環境の FIS を管理する: プログラムの実施周期の一環として、本番環境でのフォールトインジェクションに対する承認/変更管理のゲートを定義してください。
- レジリエンスの出力情報へのアクセスを制限する: 評価結果、FIS ログ、GameDay レポートには、機密性の高いアーキテクチャの詳細(リソース ARN、IP アドレス、障害モード)が含まれる場合があります。これらへのアクセスを承認された担当者に限定することを、プログラム標準に含めてください。
- 参考資料: これらの標準を実施する際の参考として、チームに AWS Well-Architected Security Pillar、FIS Security Best Practices、IAM Best Practices を案内してください。
コメント
Markdown 対応