プレイブック

カスタムスクリプトなしで、失敗したECS Fargateデプロイメントの自動ロールバックを行う。

→ECSサービスでロールバックを伴うECSデプロイメントサーキットブレーカーを有効にする。

理由: 新しいタスクが安定しない場合に自動的にロールバックするネイティブなECS機能です。カスタムのCodeBuildポーリングや複雑なCodeDeployのセットアップと比較して、運用上のオーバーヘッドが最小限です。

リファレンス↗

プライマリリージョンにデプロイし、自動テストで検証した後、他のリージョンに並行してデプロイする。

→シーケンシャルステージを持つ単一のCodePipelineを使用する: (1) リージョンAにデプロイ、(2) 検証を実行するCodeBuildテストステージ、(3) リージョンBとCに並行デプロイするステージ。

理由: CodeBuildは自動化されたプログラムによるゲートとして機能します。単一のパイプラインは、Step Functionsで複数のパイプラインをオーケストレーションするよりもシンプルです。

CodeDeployのライフサイクルフック内の長時間実行される検証スクリプトが、時期尚早のデプロイ成功を引き起こす。

→`AppSpec.yml`ファイル内の特定のライフサイクルフックスクリプトの`timeout`プロパティを増やす。

理由: タイムアウトはデプロイグループレベルではなく、AppSpecファイルでフックごとに設定されます。これにより、検証スクリプトが完了するのに十分な時間が確保されます。

実行ごとに依存関係とイメージレイヤーを再ダウンロードすることによって引き起こされる、遅いCodeBuild Dockerイメージビルドを高速化する。

→CodeBuildプロジェクト設定で`LOCAL_DOCKER_LAYER_CACHE`を有効にし、依存関係ディレクトリ（例: `.m2`、`node_modules`）用にS3キャッシュを設定する。

理由: 遅さの原因となる両方の問題を直接解決します。Dockerレイヤーキャッシュは変更されていないイメージレイヤーを再利用し、S3キャッシングはダウンロード済みのアプリケーション依存関係を再利用します。

自動化されたメトリクス駆動のロールバックを伴うLambda関数のカナリアデプロイメントを実装する。

→`DeploymentPreference`（例: タイプ`Canary10Percent5Minutes`）付きのAWS SAMを使用する。`Errors`メトリクスにCloudWatchアラームをロールバックトリガーとして追加する。

理由: SAMはLambda用のCodeDeployとネイティブに統合されており、カスタムスクリプトなしでエイリアスのトラフィックシフト、監視、ロールバックを自動化します。

リファレンス↗

Account AのCodePipelineがAccount Bにリソースをデプロイできるように、IAMを設定する。

→パイプラインロール（Account A）がアクションロール（Account B）を引き受ける。Bのアクションロールはパイプラインロールを信頼し、デプロイ権限を持つ。AのS3アーティファクトバケットとKMSキーは、Bのアクションロールへのアクセスを許可するリソースポリシーを持つ必要がある。

理由: これは、標準的でセキュアなクロスアカウントアクセスパターンです。アクションにはロールの引き受けを、データアクセスにはリソースベースのポリシーを使用します。

EKS向けのGitOpsワークフローを実装し、クラスターの状態がGitリポジトリと自動的かつ継続的に同期されるようにする。

→EKSクラスターにGitOpsコントローラー（例: Flux、ArgoCD）をデプロイする。Gitリポジトリを監視し、変更を適用/同期するように設定する。

理由: これは標準的な「プルベース」のGitOpsパターンです。クラスター内のコントローラーが継続的な同期とドリフト検出を処理し、これがGitOpsの核心的な原則です。

中央のツールアカウントのCodeBuildプロジェクトが、個別のワークロードアカウントのEKSクラスターにKubernetesマニフェストをデプロイできるようにする。

→各ワークロードアカウントで、CodeBuildロールによって信頼されるクロスアカウントIAMロールを作成する。この新しいロールをEKSクラスターの`aws-auth` ConfigMap内のKubernetes RBACグループにマッピングする。CodeBuildスクリプトは`kubectl`を実行する前にそのロールを引き受ける。

理由: これは、クロスアカウントEKSアクセスの標準的でセキュアなパターンです。この目的のために専用の信頼されたロールを作成することで、最小特権の原則に従います。

複雑なRDS PostgreSQLまたはMySQLスキーマ移行を、ゼロまたはほぼゼロのダウンタイムで実行する。

→Amazon RDS Blue/Green Deployments機能を使用する。同期されたステージング（グリーン）環境を作成し、それにスキーマ変更を適用し、その後スイッチオーバーして本番環境に昇格させる。

理由: これは、安全でゼロダウンタイムのRDS更新のために特別に構築されたマネージドサービスです。クローニング、同期、および組み込みのガードレール付きの高速（1分未満）スイッチオーバーを処理します。

シングルページアプリケーション (SPA) の新しいバージョンをS3/CloudFrontにデプロイし、最小限のキャッシュ無効化コストでユーザーがすぐに新しいバージョンを受け取るようにする。

→アセットファイル名にコンテンツベースのハッシュを使用する（例: `app.a1b2c3d4.js`）。新しいアセットをデプロイした後、CloudFrontディストリビューション内の`index.html`ファイルのみを無効化する。

理由: ハッシュ化されたファイル名は一意であるため、CloudFrontはそれらを新しいオブジェクトとして扱い、オリジンから取得してキャッシュをバイパスします。単一のエントリポイントファイル（`index.html`）のみが無効化を必要とし、これはワイルドカード（`/*`）無効化よりも大幅に安価です。

パイプライン自身の定義が変更されたときに自動的に自身を更新する、AWS CDKアプリケーション用のCI/CDパイプラインを実装する。

→CDK Pipelinesコンストラクト（`pipelines.CodePipeline`）を使用する。このコンストラクトは、デフォルトで`SelfMutate`ステージを含むパイプラインを作成する。

理由: CDK Pipelinesは、このパターンのために特別に構築された高レベルのコンストラクトです。`SelfMutate`ステージにより、アプリケーションの変更をデプロイする前に、パイプラインが常にコードからの最新の定義を反映していることが保証されます。

下位互換性のあるデータベーススキーマ変更（例: 新しい列の追加）を必要とする新しいアプリケーションバージョンを、ゼロダウンタイムでデプロイする。

→拡張および縮小（または並行変更）パターンを実装する。まず、追加的で下位互換性のあるデータベーススキーマ変更をデプロイする。次に、新しいスキーマを使用する新しいアプリケーションバージョンをデプロイする。古いアプリケーションバージョンと新しいアプリケーションバージョンの両方が、更新されたデータベースと共存できる。

理由: このパターンはデータベースとアプリケーションのデプロイメントを分離し、データベースの状態が常に古いアプリケーションバージョンと新しいアプリケーションバージョンの両方と互換性があることを保証することで、ゼロダウンタイムでのロールアウトを可能にします。

特定のユーザーセグメントに新機能を段階的にリリースし、A/Bテストを使用してビジネスメトリクス（例: コンバージョン率）への影響を測定する。

→Amazon CloudWatch Evidentlyを使用する。複数のバリエーションを持つ機能、ロールアウト率を制御するローンチ、および定義されたメトリクスへの統計的影響を測定する実験を作成する。

理由: Evidentlyは、機能フラグとA/B実験のために特別に構築されたサービスであり、ロールアウトメカニズムだけでなく、影響を測定するための統計分析エンジンも提供します。

AWS Organizations全体で、EC2インスタンス起動時にすべてのインスタンスに必須タグを適用する。

→リクエストに必要なタグキーが存在しない限り`ec2:RunInstances`を拒否するサービスコントロールポリシー (SCP) を使用する。

理由: コンプライアンスに準拠しないリソースの作成をブロックする予防的なコントロールです。すべてのAWSアカウントに適用され、ローカルのIAMポリシーによって上書きすることはできません。

リファレンス↗

複数のアカウントのアプリケーションで使用されるシークレット（例: DB認証情報）を、ダウンタイムなしで管理およびローテーションする。

→自動ローテーションが有効なAWS Secrets Managerを使用する。シークレットに対するリソースベースのポリシーを使用してクロスアカウントアクセスを許可する。

理由: Secrets Managerはゼロダウンタイムのローテーション戦略（ユーザー交代）をサポートし、セキュアなネイティブのクロスアカウント共有を提供します。

Control Tower Account Factory経由で作成された新しいアカウントに、ベースラインセキュリティリソースを自動的にデプロイする。

→EventBridgeを介したControl Towerのライフサイクルイベント`CreateManagedAccount`を使用して、CloudFormation StackSetをデプロイするLambda関数をトリガーする。または、Customizations for AWS Control Tower (CfCT) を使用する。

理由: イベント駆動型自動化は、アカウント作成後の手動介入なしにControl Towerのベースラインを拡張するための標準的でスケーラブルなパターンです。

インターネットアクセスがないプライベートサブネット内のEC2インスタンスへのSSM Session Managerアクセスを有効にする。

→VPC内に`ssm`、`ssmmessages`、`ec2messages`サービス用のVPCインターフェースエンドポイント（PrivateLinkを利用）を作成する。

理由: VPCエンドポイントにより、SSMエージェントはAWSネットワーク内でサービスと完全に通信でき、NATやインターネットゲートウェイを必要としない最もセキュアなアクセスパターンを提供します。

ログを長期保存で集中管理し、管理者によっても削除や変更ができないように保護する。

→コンプライアンスモードのS3 Object Lockを備えたS3バケットにログを保存する。CloudTrailログファイルの整合性検証を有効にする。

理由: Object Lock（コンプライアンスモード）は、ルートアカウントでさえもバイパスできないWORM保護を提供します。ログファイルの整合性検証は、配信後の改ざんに対する暗号化チェックを提供します。

開発者に、完全なAWSサービス権限を付与することなく、事前承認されたインフラストラクチャパターンをプロビジョニングするセルフサービスの方法を提供する。

→AWS Service Catalogを使用する。承認された製品（CloudFormationテンプレートで定義）のポートフォリオを作成する。ローンチ制約を使用して、プラットフォームチームによって管理される特権IAMロールを使用してService Catalogがリソースをプロビジョニングするようにする。

理由: Service Catalogは、キュレーションされたITサービスのカタログを作成するために特別に構築されたAWSサービスです。ローンチ制約は、開発者が基盤となる権限自体を持たずに複雑なインフラストラクチャをプロビジョニングできるようにする主要なガバナンス機能です。

ECSタスクとして実行される異なるマイクロサービスに、各サービスが自身のシークレットのみにアクセスできるように、一意のシークレットを安全に提供する。

→各サービス用に個別のAWS Secrets Managerシークレットを作成する。ECSタスク定義で、コンテナ定義の`secrets`プロパティにシークレットARNを参照する。タスク実行IAMロールポリシーを、そのサービスの特定のシークレットARNに対する`secretsmanager:GetSecretValue`のみを許可するようにスコープする。

理由: これにより、シークレット自体、IAMポリシー、ECSタスク定義という複数のレイヤーで最小特権の原則が強制されます。シークレットはランタイム時に安全に注入されます。

GitHub Actionsワークフローが、長期的な認証情報を保存せずにAWSに安全にアクセスできるようにする。

→GitHub用のIAM OIDC IDプロバイダーを設定する。フェデレーテッドプリンシパルを特定のGitHub組織、リポジトリ、ブランチに制限する信頼ポリシーを持つIAMロールを作成する。OIDCを使用して`aws-actions/configure-aws-credentials`アクションでロールを引き受ける。

理由: OIDCフェデレーションは最も安全な方法であり、特定のワークフロー実行にスコープされた短期的な認証情報を提供し、長期的な認証情報の露出のリスクを排除します。

AWS Organizations全体で全てのIAMポリシーを継続的に監視し、外部エンティティと共有されているリソースを特定してアラートを受け取る。

→組織を信頼ゾーンとして定義し、組織レベルでIAM Access Analyzerを有効にする。EventBridgeを使用して新しい検出結果をキャプチャし、通知をトリガーする。

理由: IAM Access Analyzerは、外部共有リソースを自動推論で見つけるために特別に構築されています。組織レベルで実行することで、カスタムスクリプトなしで継続的かつ集中化されたビューが提供されます。

モノリシックまたはネストされたスタックアーキテクチャで、失敗したCloudFormation更新の被害範囲を軽減する。

→クロススタック参照 (CloudFormation Exports/Fn::ImportValue) を使用して、アーキテクチャを独立したスタックに分解する。

理由: 1つのスタック (例: データベース) での障害が、正常に更新された他のスタック (例: ネットワーキング) のロールバックを引き起こすことはなく、障害ドメインを分離します。

本番環境と非本番環境で異なるスケジュールを持つクロスアカウントのパッチ適用を集中管理する。

→カスタムパッチベースライン、各環境ごとの個別のメンテナンスウィンドウ、および集中型コンプライアンスレポート用のSystems Manager Explorerを備えたAWS Systems Manager Patch Managerを使用する。

理由: カスタムパッチ定義、メンテナンスウィンドウによる柔軟なスケジュール設定、Explorerによるクロスアカウントの可視性など、すべての要件をネイティブでサポートします。

CloudFormation StackSetの更新を実行する前に、すべてのターゲットアカウントにわたるインフラストラクチャの変更をプレビューする。

→実行前に、StackSet操作用のCloudFormation変更セットを作成してレビューする。

理由: 変更セットは、更新が実行する正確なリソース変更（追加、変更、削除）をプレビューするためのネイティブなCloudFormationメカニズムです。

CloudFormationがスタック作成を続行する前に、EC2インスタンスのUserDataスクリプトが正常に完了するのを待つようにする。

→EC2インスタンスリソースに`ResourceSignal`を含む`CreationPolicy`を追加する。UserDataから正常完了時に`cfn-signal`ヘルパースクリプトを呼び出す。

理由: これは、リソース上の設定スクリプトと連携するためのネイティブなCloudFormationメカニズムです。タイムアウト内にシグナルが送信されない場合、スタックのロールバックが自動的にトリガーされます。

手動で行われた帯域外の変更により、デプロイされたリソースがCloudFormationテンプレートの定義と異なる場合に検出する。

→定期的にスタックに対してCloudFormationドリフト検出を実行する。継続的な検出には、`cloudformation-stack-drift-detection-check` AWS Configルールを使用する。

理由: ドリフト検出は、スタックのテンプレートとリソースの実際の状態を比較するためのネイティブ機能です。Configルールを使用することで、このチェックが自動化されます。

ステートフルなリソース（例: S3バケットやRDSデータベース）を、CloudFormationスタック操作による偶発的な削除や置き換えから保護する。

→リソースに`DeletionPolicy: Retain`（RDSの場合は`Snapshot`）を設定する。スタックで`TerminationProtection`を有効にする。重要なリソースに対する`Update:Replace`および`Update:Delete`アクションを拒否する`StackPolicy`を適用する。

理由: 多層防御を提供します。Termination Protectionはスタックの削除を防ぎ、DeletionPolicyはスタックが削除されてもリソースを保持し、Stack Policyは破壊的な更新を防ぎます。

複雑な自己管理型IAMロールモデルから、AWS Organizations向けのよりシンプルな権限モデルにCloudFormation StackSetを移行する。

→StackSetを更新して、サービスマネージド権限を使用する。

理由: サービスマネージド権限はOrganizationsの信頼されたアクセスを活用し、各ターゲットアカウントでIAMロールを作成および管理する必要がなくなります。また、ターゲットOUに追加された新しいアカウントへの自動デプロイも可能になります。

CloudFormationカスタムリソースが、Lambda関数の15分タイムアウトよりも長くかかるタスクを管理する必要がある。

→カスタムリソースのLambda関数からAWS Step Functionsステートマシンをトリガーする。ステートマシンはWaitステートまたはタスクトークンパターンを使用して長時間実行タスクを処理し、CloudFormationのS3署名付きURLに応答を送信する。

理由: Step Functionsは、長時間実行される多段階ワークフローをオーケストレーションするように設計されており、CloudFormationとの統合を維持しながらLambdaのタイムアウト制限を効果的に回避します。

開発者がリソースをどのように定義しているかに関わらず、AWS CDKアプリケーション全体でポリシー（例: すべてのS3バケットはバージョニングを持つ必要がある）を一元的に適用する。

→`IAspect`インターフェースを実装するCDKアスペクトを作成する。アスペクトはアプリケーションツリー内のすべてのコンストラクトを巡回し、すべてのS3バケットコンストラクトを見つけ、必要な設定を適用するか、不足している場合は検証エラーを追加する。

理由: アスペクトは、個々のコンストラクトを変更することなく、横断的関心を適用し、コードとしてのポリシー検証を一元的に実装するための公式なCDKパターンです。

SSMメンテナンスウィンドウ経由のパッチ適用などの自動化された操作が、特定の変動する期間（例: 四半期ごとの財務ブラックアウト）に実行されるのを防ぐ。

→SSM Change Calendarを使用して、ブラックアウト期間を「クローズ」としてマークするイベントを定義する。Change Calendarをメンテナンスウィンドウに関連付ける。

理由: Change Calendarは自動化のゲートとして機能します。メンテナンスウィンドウのスケジュールを手動で変更することなく、「クローズ」期間中の実行を自動的にブロックし、動的なブラックアウト期間の管理に非常に効率的です。

EC2インスタンス群全体で、カスタムソフトウェアパッケージ（例: 監視エージェント）のインストールとバージョニングを一元的に管理する。

→SSM Distributorを使用してソフトウェアをパッケージ化する。SSM State Managerを使用して、Distributorパッケージをすべてのターゲットインスタンスに適用する関連付けを作成する。

理由: Distributorはパッケージのライフサイクル（バージョンを含む）を管理します。State Managerは、望ましい状態（例: 「エージェントバージョン1.2がインストールされている」）が継続的に強制され、ドリフトを自動的に修復し、新しいインスタンスを設定することを保証します。

Auroraデータベースとアプリケーション層のリージョン間での、低RPO（1分未満）およびRTO（5分未満）の災害復旧。

→サブ秒のデータベースレプリケーションにはAurora Global Databaseを使用する。アプリケーション層には、desired capacityを0に設定したAuto Scalingグループを持つ「ウォームスタンバイ」を使用し、フェイルオーバー時に自動化によってスケールアップする。

理由: Aurora Global Databaseはサブ秒のRPOと1分未満のRTOを提供します。ウォームスタンバイのアプリケーション層は、高速なRTOを満たしつつコスト効率が良いです。

ブートストラップ/初期化に時間がかかるインスタンスのAuto Scalingグループのスケールアウト時間を短縮する。

→依存関係がインストールされた「ゴールデンAMI」を事前に作成する。Auto Scalingグループにウォームプールを設定して、インスタンスを事前初期化された状態に保つ。

理由: ゴールデンAMIはブートストラップ時間を最小限に抑えます。ウォームプールは起動時間（開始と起動の違い）を最小限に抑えます。これらを組み合わせることで、新しいインスタンスがトラフィックを処理できるようになるまでの時間を劇的に短縮します。

ECSサービスがタスク数をスケールアップするが、基盤となるEC2クラスターのキャパシティが不足しているため、新しいタスクを配置できない。

→キャパシティプロバイダーをEC2 Auto ScalingグループとECSクラスターに関連付けて、ECS Cluster Auto Scalingを有効にする。

理由: キャパシティプロバイダーは、ECSサービスのスケーリングをEC2インスタンスのスケーリングに連携させます。クラスターリソースの不足によりタスクの配置に失敗した場合、キャパシティプロバイダーがEC2 ASGを自動的にスケールアウトします。

SQSキュー内のメッセージ数に基づいて、EC2ワーカーインスタンスのフリートを動的にスケーリングする。

→カスタムメトリクス`ApproximateNumberOfMessagesVisible` / `GroupInServiceInstances`（インスタンスあたりのバックログ）に基づいたターゲット追跡Auto Scalingポリシーを使用する。

理由: これはSQSベースのスケーリングに推奨されるパターンです。目標時間内にバックログを処理するのに十分なワーカーを維持し、キューの深さに応じて効率的にスケーリングします。

ステートフルアプリケーションのEBSボリュームについて、クラッシュコンシステントだけでなく、アプリケーションコンシステントなスナップショットを作成する。

→バックアッププランと共にAWS Backupを使用する。プラン内で、Systems Manager Run Commandを使用して、スナップショット前スクリプトを実行し、アプリケーションを静止させる（またはWindowsの場合はVSSを有効にする）。

理由: AWS Backupはプロセス全体をオーケストレーションします。スナップショット前にアプリケーションを静止させる（I/Oバッファをディスクにフラッシュする）ことで、データの整合性とリカバリ可能なアプリケーションの状態が保証されます。

ターゲットサービス（例: Lambda）が一時的に利用不能になったりスロットリングされたりしても、EventBridgeルールからの重要なイベントが失われないようにする。

→EventBridgeルールターゲットで、リトライポリシー（例: 最大24時間）とSQSキューを使用したデッドレターキュー（DLQ）を設定する。

理由: リトライポリシーは一時的な障害を自動的に処理します。DLQは最後のセーフティネットとして機能し、すべてのリトライを使い果たしたイベントをキャプチャして後で再処理できるようにすることで、データ損失を防ぎます。

特定のログパターンに基づいてリアルタイムアラートをトリガーし、通知にコンテキスト情報（例: 周囲のログ行）を含める。

→CloudWatch Logsサブスクリプションフィルターを使用して、一致するログイベントをLambda関数にストリームする。Lambda関数は詳細な通知（例: SNSまたはChime）をフォーマットして送信する。

理由: サブスクリプションフィルターはリアルタイムのイベントストリーミングを提供します。Lambdaは、単純なメトリクスフィルターではできない、コンテキストを抽出およびフォーマットするためのカスタムロジックを可能にします。

分散型のマイクロサービスベースアプリケーションにおけるレイテンシーのボトルネックを特定する。

→エントリポイント（例: API Gateway、ALB）とコンピューティング（例: Lambda、ECS）でAWS X-Rayトレースを有効にする。ダウンストリーム呼び出しにはX-Ray SDKを使用する。サービスマップとトレースを分析する。

理由: X-Rayは、分散トレーシングのために特別に構築されたAWSサービスです。サービスマップは呼び出しチェーンを視覚化し、高レイテンシーとエラー率のサービスを強調表示します。

マルチティアアプリケーションの統合された健全性を表す単一の高レベルアラームを作成し、アラートノイズを削減する。

→各ティア（例: ALB 5xxレート、アプリCPU、RDS接続）ごとに個別のCloudWatchアラームを作成する。次に、ORロジックを使用してCloudWatch複合アラームでそれらを組み合わせる。

理由: 複合アラームは、複数の基礎となるアラームの状態に基づいて単一の論理アラームを作成することで、アラートノイズを削減するように設計されています。

ペタバイト規模のログを複雑なSQLクエリ（結合を含む）で分析し、コスト効率の高い方法で数年間保持する。

→Kinesis Data Firehose経由でログをAmazon S3にストリームする。AWS Glueでデータをカタログ化する。Amazon Athenaでクエリを実行する。S3ライフサイクルポリシーを使用して、データを長期保存のためにGlacier/Deep Archiveに移行する。

理由: これは標準的なサーバーレスデータレイクアーキテクチャです。AthenaはS3データ上で強力なSQL機能を提供し、S3/Glacierは最もコスト効率の高い長期ストレージを提供します。

予測可能な周期的パターン（例: 日次/週次スパイク）を持つメトリクスを監視し、パターンからの真の逸脱に対してのみアラームをトリガーする。

→メトリクスにCloudWatch Anomaly Detectionを設定する。メトリクス値がモデルの予期される範囲外になったときにトリガーされるアラームを作成する。

理由: Anomaly Detectionは機械学習を使用してメトリクスの通常のパターンを学習し、サイクルに適応する動的な閾値帯を作成します。これにより、予測可能なスパイクによる誤検知が減少し、信号対雑音比が向上します。

サードパーティツールをインストールおよび管理することなく、EKSまたはECS上のワークロードのコンテナレベルCPU、メモリ、ディスク、ネットワークメトリクスに関する包括的な可視性を得る。

→EKS/ECSクラスターのAmazon CloudWatch Container Insightsを有効にする。

理由: Container Insightsは、コンテナ化されたワークロードの詳細なパフォーマンスメトリクスを自動的に収集、集約、可視化するフルマネージドサービスであり、最小限の運用オーバーヘッドで深い可視性を提供します。

エンドユーザーの視点から、インターネットに面したアプリケーションの可用性とパフォーマンスを監視し、ISPレベルおよび地理的なネットワーク問題を特定する。

→アプリケーションに対してAmazon CloudWatch Internet Monitorを有効にする。

理由: Internet MonitorはAWSグローバルネットワークデータを活用し、エンドユーザーに影響を与えるインターネットの状況を可視化することで、AWS環境外の問題診断を支援します。

ウェブアプリケーションの実際のユーザー体験を、ページロード時間、JavaScriptエラー、その他のクライアントサイドのパフォーマンスメトリクスを収集することで測定する。

→CloudWatch RUM (Real User Monitoring) JavaScriptスニペットをウェブアプリケーションに統合する。

理由: RUMは、ユーザーのブラウザから直接クライアントサイドのパフォーマンスとエラーデータを収集するマネージドサービスであり、合成テストなしで実際のユーザー体験に関する真の洞察を提供します。

高解像度とディメンションを持つカスタムアプリケーションメトリクスをAWS Lambda関数から出力する際に、直接CloudWatch API呼び出しのレイテンシーとコストを追加しないようにする。

→CloudWatch Embedded Metric Format (EMF) を使用し、特別に構造化されたJSONを標準出力に書き込む。クライアントライブラリでこれを簡素化できる。

理由: CloudWatch Logsは、EMFログエントリからメトリクスを自動的かつ非同期的に抽出し、Lambda関数に追加のレイテンシーを発生させず、PutMetricData API呼び出しを回避することでコストを削減します。

AWS Configによって検出された暗号化されていないEBSボリュームを自動的に修復し、プロセス中にデータの整合性を確保する。

→Systems Manager Automationドキュメントを使用してAWS Configの自動修復機能を使用する。このランブックはインスタンスを停止し、ボリュームの暗号化されたコピーを作成し、ボリュームを交換してインスタンスを再起動する。

理由: SSM Automationは、堅牢で多段階の監査可能なワークフローを提供します。暗号化されたコピーを作成する前に、インスタンスを停止してデータ整合性のあるスナップショットを確保することが重要です。

本番環境への影響を防ぐため、自動停止条件付きで制御されたカオスエンジニアリング実験（例: ネットワークレイテンシーの注入）を実行する。

→実験テンプレート付きのAWS Fault Injection Simulator (FIS) を使用する。主要なアプリケーションメトリクスを監視するCloudWatchアラームに基づいて停止条件を定義する。

理由: FISはカオスエンジニアリングのために特別に構築されたAWSサービスであり、安全ガードレール（停止条件）と制御された障害注入アクションのカタログを提供します。

失敗した更新中にリソースが削除または変更されたため、CloudFormationスタックが`UPDATE_ROLLBACK_FAILED`状態のままになり、クリーンなロールバックが妨げられている。

→`ContinueUpdateRollback` APIアクションを使用し、`ResourcesToSkip`パラメーターに問題のあるリソースの論理IDを指定する。

理由: これは、CloudFormationに管理できなくなったリソースを無視するように指示することで、ロールバックを強制的に完了させ、スタックを安定した状態に戻すための標準的な復旧手順です。

ルートアカウントログイン、IAMポリシー変更、セキュリティグループ変更など、重要なセキュリティイベント発生から数分以内に通知を受け取る。

→特定のCloudTrail管理イベントパターンに一致するAmazon EventBridgeルールを作成し、通知のためにそれらをSNSトピックにルーティングする。

理由: EventBridgeはCloudTrail管理イベントをほぼリアルタイムで受信し、ポーリングやログベースの方法と比較して、イベント駆動型セキュリティアラートのレイテンシーを最小限に抑えます。

高トラフィックのLambda関数がスロットリングされ、スケール時にRDSデータベース接続も使い果たしている。

→Lambdaの同時実行制限の引き上げをリクエストする。Lambda関数とRDSデータベースの間にAmazon RDS Proxyを実装する。

理由: 同時実行数の増加はスロットリングを解決します。RDS Proxyは、データベース接続をプールして再利用することで、多数の一時的な接続によってデータベースが過負荷になるのを防ぐため、サーバーレスアプリケーションに不可欠です。

リージョン間の自動DNSフェイルオーバーを実装し、失敗したリージョンに対する自動復旧ランブックをトリガーする。

→関連するヘルスチェックとともにRoute 53フェイルオーバールーティングを使用する。Route 53ヘルスチェックの状態変更イベントをキャプチャし、Systems Manager AutomationランブックをトリガーするEventBridgeルールを作成する。

理由: このアーキテクチャは、自動トラフィックフェイルオーバー（Route 53）とイベント駆動型自動インシデント対応（EventBridge + SSM Automation）を組み合わせることで、完全な回復性パターンを実現します。

RDSデータベースのストレージ不足によるアプリケーション障害を防ぐ。

→最大ストレージ閾値を設定してRDS Storage Autoscalingを有効にする。副次的な制御として、`FreeStorageSpace`メトリクスにCloudWatchアラームを作成する。

理由: Storage Autoscalingは、割り当てられたストレージを自動的に増加させるプロアクティブなマネージド機能です。CloudWatchアラームは、監視とアラートのためのセーフティネットを提供します。

コンシューマの一時的なバグにより誤って処理されたイベントのバッチを再処理する必要がある。

→事前にイベントバスにEventBridgeアーカイブを設定する。バグ修正後、インシデントの特定の時間枠からイベントを再送信するためのリプレイを作成する。

理由: アーカイブとリプレイは、履歴イベントの保存と再処理のためのネイティブなEventBridge機能であり、一時的な処理障害からの復旧に不可欠です。

重大なアラームが発報されたときに、インシデントの作成、オンコールチームのエンゲージメント、チャットチャネルの開設、修復ランブックの実行など、インシデント対応プロセス全体を自動化する。

→すべてのエンゲージメントおよび修復ステップを定義するSSM Incident Manager応答プランを作成する。CloudWatchアラームがこの応答プランをアクションとしてトリガーするように設定する。

理由: 応答プランは、インシデント対応のすべての側面をオーケストレーションするための単一の統合された設定を提供し、手作業を削減し、一貫した手順を保証します。