How to Block EC2 Launches in Unauthorized Regions Across an Organization?

Why the Answer Is Correct

A service control policy in AWS Organizations is the only option that applies a preventive guardrail from one central place. A deny statement for ec2:RunInstances with an aws:RequestedRegion condition blocks the API call before any instance exists, so there is nothing to detect or clean up. Attaching the SCP at the organization root means every OU and member account inherits it, including accounts created later, so no per-account IAM work is needed. It also constrains every IAM principal in member accounts, including role sessions and the account root user, which is what "anyone in the company" implies. The only principal outside SCP enforcement is the organization's management account, which should not host workloads and is a caveat no other option solves better.

Why the Other Options Are Wrong

Option A is detective and reactive: CloudTrail plus EventBridge plus Lambda terminates instances only after RunInstances has already succeeded, leaving a window where unauthorized capacity runs and billing accrues. It also requires maintaining rules and functions in every unauthorized Region, which is heavy operational overhead. Option B attaches a Region-conditioned managed IAM policy to all groups in each account; that is per-account, per-principal work, must be repeated for every new account or group, and does not restrict the account root user. Option C uses a permissions boundary on all IAM users, but boundaries are attached per principal, do not automatically cover roles or the root user, and again require updates in every account. Only D prevents the action centrally and scales without manual upkeep.

Community Comment Notes

Bad_Mat's comment captures the deciding logic: SCPs "apply guardrails across multiple accounts in an organization" from a single central place, so a root-level attachment covers current and future accounts without manual updates. The comment also emphasizes that the block is preventative because unauthorized actions are denied outright rather than terminated after launch, which is exactly the gap in option A. No other commenter disputes this conclusion, and the reasoning aligns with AWS Organizations documentation.