AWS Certified Security Specialty
最終確認：2026年5月
SCS-C03 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
Auto Scaling グループ内の侵害の可能性のある EC2 インスタンスを、最小限の中断で調査する必要がある。
ELB ターゲットグループから登録解除し、Auto Scaling グループから削除し、フォレンジックワークステーションからのアクセスを除くすべてのトラフィックを拒否する制限的な「フォレンジック」セキュリティグループを適用する。
理由: これにより、インスタンスがネットワークから隔離され、揮発性の状態（メモリ、実行中のプロセス）がフォレンジック分析のために保存される。すぐに終了すると、証拠が破壊される。
GuardDuty の検出結果によってトリガーされる多段階のインシデント対応ワークフロー（例：スナップショット、隔離、通知）を自動化する。
EventBridge ルールを使用して特定の検出結果をキャプチャし、AWS Step Functions ステートマシンをトリガーする。ステートマシンは、エラー処理とリトライロジックを含むアクションのシーケンスをオーケストレートする。
理由: Step Functions は、多段階ワークフローに対して堅牢なオーケストレーションを提供し、信頼性と状態管理を保証する。これは、単一のモノリシックな Lambda 関数よりも優れている。
サイドカーエージェントをデプロイせずに、実行中の ECS Fargate または EC2 コンテナ内でランタイムの脅威（例：クリプトマイニング、特権昇格）を検出する。
Amazon GuardDuty ECS Runtime Monitoring を有効にする。EC2 の場合、GuardDuty セキュリティエージェントを DaemonSet としてデプロイする。Fargate の場合、自動エージェント設定を使用する。
理由: これにより、アプリケーションタスクを変更することなく、コンテナ内の動作をキャプチャするエージェントレス（Fargate の場合）または集中管理型（EC2 の場合）のランタイム脅威検出が提供される。
公開されている S3 バケットなど、特定の AWS Security Hub の検出結果を自動的に修復する。
特定の検出タイプ（例：`S3.1`）に一致する EventBridge ルールを作成し、Lambda 関数または SSM Automation ドキュメントをトリガーして修復を実行する。
理由: これは、Security Hub の自動応答のためのネイティブなイベント駆動型パターンであり、ほぼリアルタイムのターゲットを絞った修復を提供する。
IAM アクセスキーが公開されてしまった。インシデントを封じ込め、影響範囲を評価する。
1. 公開されたアクセスキーを無効にする。2. アクティブな STS セッションを無効にするために、ユーザー/ロールに deny-all インラインポリシーをアタッチする。3. キーで行われたすべての API 呼び出しについて CloudTrail ログをレビューする。4. 攻撃者によって作成された不正なリソースまたは IAM プリンシパルをすべて削除する。
理由: キーを無効にすることで、将来の使用を停止する。deny-all ポリシーは、キーが無効にされる*前*に作成されたアクティブなセッションを失効させるために重要である。CloudTrail は、損害評価のための監査証跡を提供する。
GuardDuty の脅威検出を、企業固有または業界固有の脅威インテリジェンスフィードで強化する。
悪意のある IP アドレス/CIDR のプレーンテキストファイルを S3 にアップロードする。S3 ファイルを指すように、GuardDuty で新しい脅威インテルセットを作成してアクティブ化する。
理由: これにより、GuardDuty のマネージド脅威インテリジェンスをカスタム IOC で補強し、指定された IP とリソースが通信したときに検出結果を生成できる。
すべてのネットワーク設定を考慮して、特定のポートでインターネットに開かれたネットワークパスを持つ EC2 インスタンスを特定する。
Amazon Inspector を有効にし、そのネットワーク到達性に関する検出結果をレビューする。
理由: Inspector は、IGW からインスタンスへの完全なネットワークパス分析を実行し、セキュリティグループ、NACL、ルートテーブルを評価して実際の到達性を判断する。これは、個々のセキュリティグループルールをチェックするよりも正確である。
セキュリティ検出結果の全体像を調査し、関連するすべてのエンティティと履歴の行動を視覚化する。
Amazon Detective を使用する。エンティティプロファイル（例：EC2 インスタンスや IAM ロールの場合）に移動し、行動グラフと関連する API 呼び出し、ネットワーク接続、GuardDuty 検出結果のタイムラインを表示する。
理由: Detective は、CloudTrail、VPC Flow Logs、GuardDuty からのログを自動的に相関させ、手動でのログ相関と比較して、根本原因調査を大幅に加速するコンテキスト分析を提供する。
コンプライアンス要件を満たすために、監査ログ（例：CloudTrail、VPC Flow Logs）を改ざん防止のクエリ可能な方法で長期保存する。
S3 Object Lock をコンプライアンスモードで有効にした S3 バケットにログを配信する。クエリには Amazon Athena を使用する。
理由: コンプライアンスモードの Object Lock は、ルートユーザーを含む誰による削除や変更も防ぎ、ログの不変性を保証する。Athena は、保存されたログに対してアドホックな SQL クエリ機能を提供する。
AWS Organizations 全体のすべての管理イベントとデータイベントを一元的に収集する。
管理アカウントで CloudTrail Organization Trail を作成する。オブジェクトレベルのデータをキャプチャするには、高度なイベントセレクタを使用して、価値の高いリソースの特定のイベントタイプ（例：S3 PutObject、Lambda Invoke）をログに記録する。
理由: 組織トレイルは、すべてのメンバーアカウントのイベントを自動的にログに記録する。高度なイベントセレクタは、必要なリソースのみを対象とすることで、大量のデータイベントをコスト効率よくログに記録するために重要である。
組織全体から複数年にわたる CloudTrail イベントに対して、複雑な SQL ベースの分析を実行する。
AWS CloudTrail Lake を有効にし、必要な保持期間（最大7年）で組織レベルのイベントデータストアを作成する。組み込みの SQL クエリエディタを使用して分析する。
理由: CloudTrail Lake は、CloudTrail イベントのために特別に構築された、マネージドで不変のデータストアとクエリエンジンを提供し、ログ分析のために S3、Glue、Athena を管理する必要をなくす。
脅威ハンティングやトラブルシューティングのために、VPC 内のリソースによって行われたすべての DNS クエリを監視する。
Route 53 Resolver DNS Query Logging を有効にし、CloudWatch Logs、S3、または Kinesis Data Firehose にログを送信するように設定する。
理由: これにより、VPC 内の DNS 解決アクティビティに対する詳細な可視性が提供され、クエリされたドメイン、ソースインスタンス、および応答がキャプチャされる。これは、DNS ベースの脅威を検出するために不可欠である。
様々な AWS およびサードパーティソースからのセキュリティログを、標準スキーマを使用してデータレイクに一元化し、正規化する。
Amazon Security Lake をデプロイする。これにより、データが自動的に収集され、Open Cybersecurity Schema Framework (OCSF) に正規化され、Parquet 形式で S3 に保存される。
理由: Security Lake は、セキュリティデータレイクの作成と管理を自動化し、正規化のためのカスタム ETL パイプラインを構築する運用上のオーバーヘッドを削減する。
SOC 2、PCI DSS、HIPAA などのフレームワークに対するコンプライアンス監査のために、証拠収集を自動化する。
AWS Audit Manager を使用する。事前構築済みのフレームワークを選択すると、AWS サービス（CloudTrail、Config、Security Hub）から証拠が自動的に収集され、特定のコンプライアンス制御にマッピングされる。
理由: Audit Manager は証拠収集プロセスを自動化し、一元化するため、コンプライアンス監査の準備と実施に必要な手作業を大幅に削減する。
すべての S3 バケット全体で機密データ（PII、PHI、財務データ）を自動的に発見し、分類する。
Amazon Macie を有効にし、自動機密データ検出ジョブを設定する。一般的なデータタイプにはマネージドデータ識別子を使用し、プロプライエタリな形式にはカスタムデータ識別子を作成する。
理由: Macie は、S3 データ分類のためのマネージドでスケーラブルなソリューションを提供する。既知の非機密データ（例：テストデータ）の検出結果を抑制するには、Macie の許可リストを使用する。
S3 バケットに対して、特定のキーを使用した SSE-KMS の要求や HTTP リクエストの拒否など、複数のセキュリティ制御を強制する。
複数の `Deny` ステートメントと条件キー (`aws:SecureTransport: false`、`s3:x-amz-server-side-encryption: "aws:kms"`、`s3:x-amz-server-side-encryption-aws-kms-key-id: "key-arn"`) を使用するバケットポリシーを使用する。
理由: バケットポリシーは、きめ細かなリソースレベルの制御を提供する。Deny ステートメントで複数の条件キーを使用することは、バケットに対する階層的なセキュリティ態勢を強制する標準的な方法である。
すべての新しい EBS ボリュームが、組織全体で特定の顧客管理型 KMS キーで暗号化されるようにする。
各リージョンのアカウント設定で EBS 暗号化をデフォルトで有効にし、CMK を指定する。予防的なガードレールとして、`encrypted` パラメータが `false` の場合に `ec2:CreateVolume` を拒否する SCP を適用する。
理由: デフォルト設定は利便性を提供し、SCP は厳格な強制ガードレールを提供し、EBS の保存データの暗号化に対する多層防御アプローチを構築する。
AWS KMS を使用して、大きな (> 4KB) データオブジェクトを暗号化する。
エンベロープ暗号化を使用する。`KMS:GenerateDataKey` を呼び出して、プレーンテキストデータキーと暗号化されたデータキーを取得する。プレーンテキストキーを使用して、大きなオブジェクトをローカルで暗号化する。暗号化されたオブジェクトと暗号化されたデータキーを一緒に保存する。プレーンテキストキーは破棄する。
理由: KMS Encrypt API には 4KB の制限がある。エンベロープ暗号化は、任意のサイズのデータを暗号化できる一方で、KMS によって小さなデータキーが保護されるため、KMS を介してデータをストリーミングするよりもコストとレイテンシーが削減される。
災害復旧やグローバルなアプリケーションの一貫性のために、複数の AWS リージョンで同じ暗号化キーを使用する。
1つのリージョンで KMS マルチリージョンプライマリキーを作成し、他のリージョンでレプリカキーを作成する。あるリージョンでキーによって暗号化されたデータは、別のリージョンでレプリカを使用して復号化できる。
理由: マルチリージョンキーは同じキーマテリアルとキー ID を共有するため、復号化のためのクロスリージョン API 呼び出しなしでクロスリージョンデータポータビリティが可能になる。
アプリケーションで使用される認証情報（例：データベースパスワード、API キー）を安全に保存し、自動的にローテーションする。
AWS Secrets Manager に認証情報を保存する。カスタムまたは AWS 提供の Lambda ローテーション関数を使用して自動ローテーションを設定する。アプリケーションは IAM ロールを介して実行時にシークレットを取得する。
理由: Secrets Manager は、安全な保存、アクセス制御、監査、自動ローテーションを含むシークレットライフサイクル全体のために特別に構築されたサービスであり、ハードコードされた認証情報や期限切れの認証情報のリスクを軽減する。
ウェブサイト用のパブリック TLS 証明書と、内部マイクロサービス通信 (mTLS) 用のプライベート証明書の両方を管理する。
ELB/CloudFront と統合された無料のパブリック証明書には AWS Certificate Manager (ACM) を使用する。ACM Private CA を使用してプライベート認証局を作成し、内部サービス用のプライベート証明書を発行および管理する。
理由: これにより、パブリック PKI とプライベート PKI が分離され、それぞれのユースケースに適したツールが使用される。ACM はパブリック証明書のライフサイクルを処理し、ACM Private CA は完全にマネージドなプライベート PKI 階層を提供する。
ルートユーザーでさえも削除できないように、固定された保持期間にわたってデータを不変に保存する。
バケットで S3 Object Lock を有効にする。コンプライアンスモードで保持期間を設定する。
理由: コンプライアンスモードは最強の WORM (Write-Once-Read-Many) 制御であり、いかなるユーザーによる削除も防ぐ。ガバナンスモードは、承認されたプリンシパルによってバイパスされる可能性がある。
必須の保持期間中に、バックアップを削除（例：ランサムウェアや認証情報の侵害による）から保護する。
AWS Backup Vault Lock をコンプライアンスモードで、最小保持期間を設定して有効にする。
理由: コンプライアンスモードの Vault Lock は、バックアップボールトを WORM 準拠にし、保持期間が終了する前にルートを含むいかなるユーザーもリカバリポイントを削除することを防ぐ。
データが OS、ハイパーバイザー、または AWS オペレーターに決して公開されないような、高度に機密性の高いデータを処理する。
AWS Nitro Enclaves を使用して、暗号的に隔離されたコンピュート環境を作成する。KMS アテステーションを使用して、検証されたエンクレーブのみがデータを復号化できることを保証する。
理由: Nitro Enclaves は、AWS 上でデータ利用中の最も強力な保護レベルを提供し、ハードウェアレベルのアテステーションを使用して信頼された実行環境を作成する。
AWS の外部にあるオンプレミス HSM に物理的に保存および管理されている暗号化キーで AWS サービスを使用する。
KMS から外部キーマネージャーへの暗号化操作をプロキシする KMS External Key Store (XKS) を設定する。
理由: XKS は、顧客が主権またはコンプライアンス要件を満たすために、AWS の外部でキーマテリアルの制御を維持しながら、KMS 対応の AWS サービスと統合することを可能にする。
組織全体で、予防的および検出的制御を使用して、厳格な「S3 バケットの公開なし」ポリシーを強制する。
管理アカウントから組織レベルで S3 Block Public Access を有効にする。ポリシーが公開アクセスを許可する場合、`s3:PutBucketPolicy` などのアクションを拒否する SCP で補完する。AWS Config を使用してドリフトを検出する。
理由: この多層アプローチは、デフォルトのブロック（組織設定）、誤設定を阻止する予防的なガードレール（SCP）、および継続的な監視のための検出制御（Config）を提供する。
集中型セキュリティアプライアンス（例：AWS Network Firewall）を使用して、すべての VPC 間およびインターネットへのトラフィックを検査する。
専用の検査 VPC を作成する。Transit Gateway を使用してすべての VPC を接続する。TGW ルートテーブルを設定して、すべてのトラフィックを検査 VPC 経由で送信する。対称ルーティングのために TGW アタッチメントでアプライアンスモードを有効にする。
理由: これは、集中型トラフィック検査のための標準的なハブアンドスポークモデルであり、複雑な VPC ピアリングメッシュなしでスケーラビリティと一貫したポリシー適用を提供する。
OWASP Top 10、ボット、アカウント乗っ取り攻撃からウェブアプリケーション（CloudFront/ALB 上）を保護する。
AWS WAF に AWS Managed Rules（例：`AWSManagedRulesCommonRuleSet`）、Bot Control マネージドルールグループ、および Account Takeover Prevention (ATP) マネージドルールグループをアタッチする。
理由: この階層型アプローチは、広範な保護（Common）、自動トラフィック検出（Bot Control）、および専門的なログインエンドポイントセキュリティ（ATP）のために複数のマネージドルールグループを使用する。
SaaS API サービスをインターネットに公開することなく、顧客 VPC から安全かつプライベートなアクセスを提供する。
Network Load Balancer (NLB) をバックエンドとする AWS PrivateLink エンドポイントサービスを作成する。顧客は、サービスにアクセスするために自身の VPC にインターフェース VPC エンドポイントを作成する。
理由: PrivateLink はトラフィックを AWS プライベートバックボーン上に維持し、パブリックインターネットを回避し、複雑な VPC ピアリング、VPN、または IP ホワイトリスティングの必要性を排除する。これは、プライベート SaaS 接続のための標準的でスケーラブルなパターンである。
S3 バケットへのアクセスを、CloudFront ディストリビューション経由でのみコンテンツにアクセスできるように制限する。
CloudFront Origin Access Control (OAC) を使用する。S3 バケットポリシーを更新し、特定のディストリビューション ARN を条件として、CloudFront ディストリビューションのサービスプリンシパルからのアクセスのみを許可するように設定する。
理由: OAC は、レガシーな Origin Access Identity (OAI) よりも優れた、現在推奨されている方法である。SSE-KMS を含むすべての S3 機能に対応し、セキュリティのベストプラクティスに従っている。
SSH/RDP ポートを開いたり、踏み台ホストを管理したりすることなく、プライベートサブネット内の EC2 インスタンスに安全で監査可能なシェルアクセスを提供する。
EC2 インスタンスに SSM Agent をインストールする。アクセスには AWS Systems Manager Session Manager を使用する。IAM ポリシーによってセッションを開始できるユーザーが制御される。セッションアクティビティは CloudWatch Logs と S3 にログとして記録できる。
理由: Session Manager は、暗号化されたトンネルを介して安全なブラウザベースまたは CLI アクセスを提供し、インバウンドポート、踏み台ホスト、SSH キーの必要性を排除し、完全な監査可能性を提供する。
VPC リソースが既知の悪意のあるドメインを解決するのを防ぐために、DNS レベルのフィルタリングを実装する。
Route 53 Resolver DNS Firewall を、マネージドドメインリスト（マルウェア、C2 用）およびカスタムブロックリストで設定する。ファイアウォールルールグループを VPC に関連付ける。
理由: これにより、VPC レベルで集中管理された DNS フィルタリングサービスが提供され、ホストベースのエージェントを必要とせずに、悪意のあるアクティビティを最も早い時点（DNS 解決）でブロックする。
3層ウェブアプリケーションに対して、最小特権のネットワーク制御を実装する。
各層に個別のセキュリティグループを作成する。ALB SG は `0.0.0.0/0` からのインバウンド 443 を許可する。App SG は ALB SG からのインバウンドトラフィックのみを許可する。DB SG は App SG からのデータベースポート上のインバウンドトラフィックのみを許可する。
理由: ソースとしてセキュリティグループ参照を使用することで、動的で IP に依存しないマイクロセグメンテーションが提供され、各層は隣接する承認された層からのみアクセスできるようになる。
EKS で実行されているアプリケーションに、共有ノード IAM ロールを使用せずに、きめ細かな Pod レベルの AWS 権限を付与する。
EKS クラスターで IAM Roles for Service Accounts (IRSA) を有効にする。アプリケーション用の特定の権限を持つ IAM ロールを作成する。アプリケーションの Kubernetes サービスアカウントに IAM ロール ARN をアノテーションとして追加する。
理由: IRSA は、サービスアカウントに基づいて Pod に一時的な認証情報を直接提供し、Pod レベルで最小特権を実装し、過度に許可されたノードロールのセキュリティリスクを排除する。
ユーザーの ID とデバイスのセキュリティ態勢の両方に基づいて、VPN なしで内部ウェブアプリケーションにアクセスを提供する。
AWS Verified Access をデプロイする。企業 IdP をユーザートラストプロバイダーとして、デバイス管理ソリューションをデバイストラストプロバイダーとして統合する。アプリケーションごとのアクセスポリシーを作成する。
理由: Verified Access はゼロトラストアアクセス用に特別に構築されており、各リクエストをユーザーとデバイスの両方のコンテキストを考慮したポリシーに対して評価し、ネットワーク境界セキュリティへの依存を排除する。
開発者が IAM ロールを作成することを許可するが、自身の特権を昇格させる可能性のあるロールの作成を防ぐ。
最大許可権限を定義する許可境界ポリシーを作成する。開発者の IAM ポリシーで、`iam:PermissionsBoundary` 条件キーを介してこの特定の境界をアタッチすることを要求するように `iam:CreateRole` 許可を条件付けする。
理由: 許可境界は、IAM エンティティが持ちうる最大権限を設定する。これにより、開発者が作成するロールが、彼らがアタッチする ID ポリシーに関係なく、境界によって上限が設定されることで特権昇格を防ぐ。
CloudTrail の無効化や共通 S3 バケットの削除など、リスクの高いアクションを、メンバーアカウントのどのユーザー（管理者を含む）も実行できないように防止する。
ルートまたは関連する OU に、制限されたアクション（例：`cloudtrail:StopLogging`、`s3:DeleteBucket`）に対して `Deny` ステートメントを持つサービスコントロールポリシー (SCP) を適用する。
理由: SCP は AWS Organizations における究極のガードレールである。これは、アカウント内のすべてのプリンシパルに対する最大権限を設定し、SCP の明示的な拒否は、アカウント内のどの IAM ポリシーによっても上書きできない。
アプリケーションまたはユーザーに対して、安全で監査可能なクロスアカウントアクセスを提供する。
ターゲットアカウントで、ソースアカウントのプリンシパル ARN を指定する信頼ポリシーを持つ IAM ロールを作成する。ソースアカウントで、プリンシパルにターゲットロールに対する `sts:AssumeRole` 権限を付与する。アプリケーションは STS AssumeRole を使用して一時的な認証情報を取得する。
理由: これはクロスアカウントアクセスの標準パターンである。一時的で短期間の認証情報を使用し、CloudTrail を介して両方のアカウントで完全に監査可能である。
IAM Identity Center を外部 IdP（例：Okta、Azure AD）と統合し、ユーザー/グループのプロビジョニングを自動化する。
IAM Identity Center で外部 IdP を ID ソースとして設定する。SCIM 経由で自動プロビジョニングを有効にして、ユーザーとグループを同期する。同期されたグループにアクセス許可セットを割り当てる。
理由: SCIM (System for Cross-domain Identity Management) は、ID の自動かつほぼリアルタイムの同期を提供し、手動でのユーザー管理を排除し、AWS アクセスが IdP によって制御されることを保証する。
タグに基づいてリソース（例：EC2）へのアクセスを許可する。ここで、プリンシパルは自身のチーム/部署名でタグ付けされたリソースのみを管理できる。
IAM プリンシパル（ユーザー/ロール）とリソース（EC2 インスタンス）の両方に共通のキー（例：`Team`）でタグを付ける。`aws:PrincipalTag/Team` と `aws:ResourceTag/Team` を比較する条件を持つ単一の IAM ポリシーを作成し、アクションを許可する。
理由: 属性ベースのアクセス制御 (ABAC) は、新しいリソースやチームが追加されたときにポリシーを更新する必要がない、スケーラブルな権限モデルを提供する。権限はタグに基づいて動的に決定される。
アカウント B のプリンシパルが、アカウント A にあり、同じくアカウント A の KMS キーで暗号化された S3 オブジェクトを読み取る必要がある。
3つの権限が必要である：1) アカウント A の S3 バケットポリシーは、アカウント B のプリンシパルを許可する必要がある。2) アカウント A の KMS キーポリシーは、アカウント B のプリンシパルに対して `kms:Decrypt` を許可する必要がある。3) アカウント B のプリンシパルには、`s3:GetObject` と `kms:Decrypt` を許可する IAM ポリシーが必要である。
理由: KMS 暗号化データへのアクセスには、データサービス (S3) と暗号化サービス (KMS) の両方からの権限が必要である。KMS キーポリシーはリソースポリシーであり、クロスアカウントアクセスを許可するために重要である。
複数のポリシー（IAM、リソース、SCP、境界）が適用される場合の最終的な許可結果を理解する。
評価ロジックは次のとおりである：いずれかのポリシーで明示的な Deny がある場合、それは常にすべての Allow を上書きする。Deny が存在しない場合、適用可能なポリシーの明示的な Allow がアクセスを許可する。有効な権限は、適用可能なすべてのポリシーの共通部分である。
理由: これは基本的な IAM の概念である。明示的な Deny は最も強力なステートメントであり、明確な「ノー」として機能する。これを理解することは、アクセス問題のトラブルシューティングの鍵となる。
IAM ユーザーまたはロールが、非常に特権の高いロールを AWS サービス（例：EC2）に渡すことで、自身の特権を昇格させるのを防ぐ。
ユーザー/ロールの IAM ポリシーで `iam:PassRole` 権限のスコープを制限する。`Resource` 要素を、エンティティが渡すことを許可されている特定の、最小特権ロール ARN のみに制限する。
理由: ワイルドカード (`"Resource": "*"`) を使用した `iam:PassRole` は、主要な特権昇格リスクである。これを特定の、より低い特権のロールにスコープを制限することは、重要なセキュリティ制御である。
ログイン試行が危険と見なされる場合（例：新しいデバイス、異常な場所）にのみ、ユーザーに MFA を要求する。
Cognito ユーザープールで高度なセキュリティ機能を有効にし、リスクベースの MFA 適用による適応認証を設定する。
理由: これにより、すべてのログインに MFA を要求するよりも優れたユーザーエクスペリエンスが提供され、異常なサインイン試行にのみチャレンジを適用することでセキュリティが強化される。
プライベート PKI を使用するオンプレミスサーバーが、長期の AWS 認証情報なしで AWS サービスにアクセスできるようにする。
IAM Roles Anywhere を設定する。プライベート CA 証明書を使用して信頼アンカーを作成する。証明書を IAM ロールにマッピングするプロファイルを作成する。サーバーは自身の証明書を使用して一時的な AWS 認証情報を取得する。
理由: これにより、既存の PKI を活用して IAM ロールを外部ワークロードに拡張し、オンプレミスでの AWS アクセスキーの管理の必要性をなくす。
CloudFormation テンプレートで定義された非準拠のリソースがプロビジョニングされる*前*に、それらのデプロイを防止する。
AWS Control Tower のプロアクティブコントロールを有効にする。これらは CloudFormation フックを使用して、プロビジョニング前にリソース設定をポリシー（cfn-guard で記述）に対して検証する。
理由: これは、ソースで誤設定を防止する「シフトレフト」制御であり、デプロイ後に検出して修復するよりも効果的である。
