How to Restrict AWS Regions with SCPs and IAM Policies
Restricting which AWS regions your team can use is one of the most effective guardrails you can set up. It prevents resources from being created in unapproved locations, which matters for data residency requirements, internal governance, and cost control.
What this solves
Without region restrictions, any developer with sufficient IAM permissions can launch resources in any of the 30+ AWS regions worldwide. A test EC2 instance in ap-southeast-2 might seem harmless, but it could write logs, store data, or trigger compliance violations in a region your organization has not approved.
Region restrictions solve this by blocking API calls that target unapproved regions. The three main tools are:
- Service Control Policies (SCPs) are the default recommendation when you use AWS Organizations. SCPs apply to all principals in member accounts and cannot be bypassed from inside the account.
- IAM condition keys are useful when you cannot use SCPs, such as single-account setups without Organizations. They are weaker because IAM admins can remove or modify the policies.
- Service-specific condition keys like
s3:LocationConstraintare needed when a service has region-specific behavior thataws:RequestedRegiondoes not fully cover.
Simple explanation
Region restrictions work like a building access card that only opens certain floors. Your IAM permissions decide what you can do on the floors you reach, but the SCP decides which floors the elevator will take you to in the first place. No matter how powerful your keycard is, the elevator simply will not stop on a restricted floor.
In practice, a region restriction policy says: “Deny any AWS API call where the target region is not in this approved list.” For example, if your company operates only in eu-west-1 and eu-central-1, the policy blocks any attempt to create an EC2 instance, an RDS database, or a Lambda function in us-east-1, ap-northeast-1, or any other region.
How AWS region restrictions actually work
aws:RequestedRegion
The aws:RequestedRegion condition key is the primary tool for region restrictions. It checks which regional API endpoint the request is targeting. When you run aws ec2 describe-instances —region us-west-2, the aws:RequestedRegion value is us-west-2.
A deny policy using StringNotEquals with aws:RequestedRegion blocks all API calls to regions outside your approved list.
aws:RequestedRegion controls which API endpoint the request is sent to. It does not control every cross-region side effect. For example, an S3 replication rule configured in an approved region could replicate objects to a bucket in a different region. The replication is performed by the S3 service itself, not by a user API call, so aws:RequestedRegion does not block it. You need additional controls like S3 bucket policies or replication configuration restrictions to handle these cases.
Why global services need exceptions
Services like IAM, CloudFront, Route 53, AWS Organizations, and AWS Support are global. They do not operate in a specific region. When you call iam:CreateRole, there is no regional endpoint involved, so aws:RequestedRegion has no value in the request context.
Global services are like the building lobby. They exist outside the floor system entirely. If your access card policy says “deny all floors except 3 and 4,” the lobby gets denied too because it is not floor 3 or 4. You need to explicitly exclude the lobby from your floor-based rules. That is exactly what NotAction does for global services.
A blanket deny on all actions with an aws:RequestedRegion condition will block these global services because the condition cannot be satisfied. The fix is to use NotAction to exclude global services from the deny statement so the region restriction only applies to regional services.
Why aws:RequestedRegion is not enough for every service
Some AWS services accept a region as a parameter inside the API request rather than relying solely on the endpoint region. The most common example is S3 bucket creation, but other services with region-specific resource placement may have similar behavior.
aws:RequestedRegion only checks the endpoint. If a service lets you specify a destination region as a request parameter, you need the service-specific condition key to control that parameter.
S3 bucket creation and s3:LocationConstraint
When you create an S3 bucket, you specify the region using the LocationConstraint parameter. The S3 API itself is global, which means aws:RequestedRegion alone does not reliably control where buckets are created.
The s3:LocationConstraint condition key checks the actual region value in the CreateBucket request. Use it alongside aws:RequestedRegion for complete coverage.
Buckets created in us-east-1 have an empty (null) LocationConstraint. If us-east-1 is not an approved region, your deny policy catches this automatically. If it is an approved region, you need to account for the empty value. See the service-specific controls section for a working example.
For more on securing S3, see S3 security best practices.
Best option for most teams: SCPs
If your organization uses AWS Organizations, Service Control Policies are the right choice for region restrictions. SCPs apply to every IAM user, role, and the root user in member accounts. No one inside the account can override them.
SCPs are attached to organizational units (OUs) or individual accounts. When you attach a deny-based region SCP to an OU, every account in that OU is restricted, including accounts added later.
The management account of your organization is always exempt from SCPs. If you rely solely on SCPs for region restrictions, the management account has none. Protect it with strict IAM policies, limited access, and strong monitoring. Do not run production workloads in the management account.
Some AWS services create service-linked roles to perform actions on your behalf. These roles are not restricted by SCPs. For example, if an S3 replication service-linked role needs to write to a bucket in a different region, the SCP will not block it. Review service-linked role behavior for the services you use.
Region restriction SCP with global service exemptions
This is the recommended starting point. It denies all regional service calls outside the approved regions while allowing global services to function normally.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyOutsideApprovedRegions",
"Effect": "Deny",
"NotAction": [
"iam:*",
"organizations:*",
"route53:*",
"cloudfront:*",
"waf:*",
"wafv2:*",
"shield:*",
"sts:*",
"support:*",
"health:*",
"billing:*",
"budgets:*",
"ce:*",
"cur:*",
"globalaccelerator:*",
"importexport:*",
"trustedadvisor:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"eu-west-1",
"eu-central-1"
]
}
}
}
]
}NotAction means “apply this deny to everything except these actions.” The listed services are global and do not have regional endpoints, so they are excluded from the region check. Every other service (EC2, RDS, Lambda, S3, and all other regional services) is denied outside eu-west-1 and eu-central-1.
Replace the region list with your own approved regions. Many organizations include us-east-1 because several AWS features (CloudFront certificate validation, some global resource creation) route through that region even when your workloads are elsewhere.
When IAM policies are enough
If you do not use AWS Organizations, or if you need to restrict specific roles rather than entire accounts, you can add aws:RequestedRegion conditions to IAM policies instead.
IAM policies only apply to the principals they are attached to. Any user with iam:PutUserPolicy, iam:PutRolePolicy, or iam:AttachRolePolicy permissions can modify or remove the restriction. This makes IAM-based region restrictions useful as a guardrail for day-to-day operations, but not suitable as a compliance boundary.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOnlyApprovedRegions",
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateVolume",
"rds:CreateDBInstance",
"lambda:CreateFunction"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": [
"eu-west-1",
"eu-central-1"
]
}
}
}
]
}This allows the listed actions only in the two approved regions. Any attempt to use these actions in another region is implicitly denied.
Use this approach when SCPs are not available, but understand the limitations. For compliance workloads, upgrading to AWS Organizations and SCPs is strongly recommended.
Service-specific location controls
Some services need their own condition keys because aws:RequestedRegion does not fully cover how they handle regions.
Imagine your region restriction is a security checkpoint at the airport gate. aws:RequestedRegion checks which gate you are boarding at. But some services let you buy a ticket at gate A while the plane actually flies to destination B. Service-specific condition keys check the actual destination on your ticket, not just which gate you walked up to.
S3 bucket creation
Use s3:LocationConstraint to control where new S3 buckets are created. This policy denies bucket creation outside your approved regions:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyS3BucketsOutsideApprovedRegions",
"Effect": "Deny",
"Action": "s3:CreateBucket",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"s3:LocationConstraint": [
"eu-west-1",
"eu-central-1"
]
}
}
}
]
}Remember that us-east-1 buckets have an empty LocationConstraint. The policy above already blocks us-east-1 bucket creation because an empty value does not match your approved list. If you need to allow us-east-1, add a separate statement to handle the null case.
Other services to watch
Services like DynamoDB Global Tables, Aurora Global Database, and S3 Cross-Region Replication have their own mechanisms for placing data in specific regions. aws:RequestedRegion controls the API endpoint region, but the service itself may create resources or replicate data across regions. Review each service’s documentation for service-specific condition keys and configuration options.
For a broader approach to enforcing these rules through automation, see policy as code.
SCPs vs IAM policies vs service-specific controls
| SCPs | IAM policies | Service-specific keys | |
|---|---|---|---|
| Best for | Organization-wide enforcement | Single accounts or specific roles | Services with non-standard region handling |
| Enforcement strength | Cannot be bypassed from inside the account | Can be removed by IAM admins | Depends on where the policy is applied (SCP or IAM) |
| Bypass risk | Low (only org admins can change) | High (any IAM admin in the account) | Same as the policy type it is used in |
| Account scope | All principals in member accounts | Only attached principals | Depends on policy type |
| Key limitation | Does not apply to management account or service-linked roles | Can be overridden by anyone with IAM write access | Only covers the specific service |
For most organizations, the right approach is to use SCPs as the primary enforcement layer, supplemented by service-specific condition keys for services like S3 that need them.
How to implement this safely
Region restriction SCPs are powerful. A misconfigured SCP can lock teams out of services they need. Follow these steps to roll out safely.
Attaching an untested SCP to the organization root can break every member account at once. Always test in a sandbox OU with one or two non-production accounts first. Verify all workflows before going wider.
Test in a sandbox OU first. Create a dedicated OU with one or two non-production accounts. Attach the SCP there and test all workflows before going wider. Never attach an untested SCP to the organization root.
Exempt required global services. Use
NotActionto exclude global services. Start with the list in the SCP example above and add any additional global services your organization uses.Think through
us-east-1. Several AWS features depend onus-east-1even if your workloads are elsewhere. CloudFront custom SSL certificates, global WAF rules, and some billing operations useus-east-1. Decide whether to include it in your approved list or exclude specific services.Audit existing resources. Before applying the SCP, use AWS Config or a multi-account inventory tool to find resources in regions you plan to restrict. Existing resources are not removed by the SCP, so you need to clean them up separately.
Validate console and API workflows. After applying the SCP to your sandbox OU, test the AWS Console, CLI, and any CI/CD pipelines. Check that developers can still perform their daily tasks in approved regions.
Roll out gradually. After sandbox testing, apply the SCP to development OUs, then staging, then production. Monitor for access denied errors at each stage before moving to the next.
AWS attaches a default FullAWSAccess SCP to every OU. A deny-based region SCP works alongside it. If you remove FullAWSAccess without replacing it with specific allow statements, all permissions in the affected accounts are denied. Only remove it if you deliberately want to switch from a deny-list to an allow-list SCP strategy and fully understand the consequences.
How to verify and audit region restrictions
After applying a region restriction, verify that it works as expected.
Test with a denied region
Try to create a resource in a region outside your approved list. The call should fail with an access denied error.
# Attempt to launch an instance in a restricted region
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type t3.micro \
--region ap-southeast-2
# Expected output:
# An error occurred (UnauthorizedOperation) when calling
# the RunInstances operation: You are not authorized to
# perform this operation.Use the IAM Policy Simulator
The IAM Policy Simulator lets you test effective permissions for a specific principal, including the effect of SCPs. Simulate API calls in both approved and restricted regions to confirm the SCP is working.
Check CloudTrail for denied calls
AWS CloudTrail logs all API calls, including denied ones. After applying the SCP, search CloudTrail for events with errorCode: AccessDenied in restricted regions. This tells you whether anyone or anything is still trying to use those regions.
# Search CloudTrail for denied calls in a specific region
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances \
--region ap-southeast-2 \
--start-time 2026-03-01 \
--end-time 2026-03-30Audit existing resources
Region restrictions only affect future API calls. Resources that already exist in restricted regions keep running. Use AWS Config, Security Hub, or a custom inventory script to find resources in denied regions and plan their migration or removal.
When to use this
- Regulated workloads. Data residency requirements, regulatory controls, or contractual obligations that specify which regions or countries your data can reside in. This includes privacy regulations, financial industry rules, and healthcare compliance frameworks.
- Internal platform governance. Platform teams that want to standardize on a set of approved regions to simplify networking, monitoring, and incident response.
- Cost and sprawl control. Preventing unused regions from accumulating stray resources like test instances nobody remembers, orphaned volumes, or CloudWatch dashboards from old experiments.
- Multi-account environments. Organizations using AWS Organizations with multiple accounts benefit most because SCPs enforce restrictions across all member accounts consistently.
Do not assume that a regulation like GDPR always requires data to stay in the EU. Requirements vary by data type, processing purpose, and contractual terms. Region restrictions are one control among many. They help enforce approved regions but do not replace a full compliance assessment.
Common mistakes
- Not excluding global services from the region deny. IAM, CloudFront, Route 53, and other global services do not use regional endpoints. A blanket deny with
aws:RequestedRegionblocks them. Always useNotActionto exclude global services. - Blocking
us-east-1without checking dependencies. Several AWS features route throughus-east-1regardless of where your workloads run. CloudFront certificate validation, global WAF rules, and some billing operations all use it. Blocking it entirely can break things you do not expect. - Assuming SCPs protect the management account. SCPs never apply to the management account. If you rely solely on SCPs for region restrictions, the management account has none. Apply separate IAM controls there.
- Forgetting that SCPs do not restrict service-linked roles. Service-linked roles operate on behalf of AWS services and are not restricted by SCPs. A service-linked role can still perform cross-region actions even with a region deny SCP in place.
- Relying only on
aws:RequestedRegionfor S3. S3 bucket creation uses a global API with aLocationConstraintparameter. Without thes3:LocationConstraintcondition key, buckets can be created in restricted regions. - Not auditing existing resources after applying restrictions. SCPs prevent new resources in restricted regions but do not touch existing ones. Audit your accounts and clean up resources in denied regions after applying the policy.
- Using IAM policies as the sole compliance control. IAM conditions can be modified by anyone with IAM write permissions. For compliance requirements, use SCPs which cannot be bypassed by account-level administrators.
- Attaching untested SCPs to the organization root. A misconfigured SCP at the root affects every member account. Always test in a sandbox OU with non-production accounts first. Debugging access denied errors after a bad SCP rollout is much harder than testing beforehand.
- Removing
FullAWSAccesswithout understanding the impact. The defaultFullAWSAccessSCP allows all actions. Removing it without specific allow statements denies all permissions in the affected accounts. Only remove it as part of a deliberate allow-list strategy.
Frequently asked questions
Does aws:RequestedRegion work for global services like IAM?
No. Global services like IAM, CloudFront, Route 53, and AWS Organizations do not operate in a specific region, so the aws:RequestedRegion condition key does not apply to them. If you use a blanket deny with aws:RequestedRegion, these services will be blocked. You must use NotAction to exclude global services from region deny policies.
Do SCPs apply to the management account?
No. SCPs never apply to the management account of the organization. Only member accounts are affected. This means region restrictions enforced through SCPs do not protect the management account. You need separate IAM controls and strict access policies on the management account itself.
Can IAM policies enforce region restrictions by themselves?
Yes, but they are weaker than SCPs. IAM policies only apply to the principals they are attached to. Any user with iam:PutUserPolicy or iam:AttachRolePolicy can modify or remove the restriction. For compliance-grade enforcement, use SCPs through AWS Organizations instead.
Why does S3 bucket creation need s3:LocationConstraint separately?
The aws:RequestedRegion condition key checks which regional API endpoint you called, not what region the resource will actually be created in. S3 bucket creation uses a global API, and the bucket region is specified as a parameter in the request body. To control where buckets are created, you need the s3:LocationConstraint condition key in addition to aws:RequestedRegion.
Do region restrictions remove resources that already exist in denied regions?
No. SCPs and IAM policies only affect future API calls. Existing resources in restricted regions continue to run. After applying a new region restriction, you need to audit your accounts for existing resources in denied regions and remove them manually or with automation.