Region Locking On AWS

Fig.1. AWS Regions

AWS originally enabled all new AWS Regions by default, which enabled your users to create resources in any Region. Now, when AWS adds a Region, the new Region is disabled by default. If you want your users to be able to create resources in a new Region, you enable the Region.

If your company requires users to create resources in a specific AWS region, you can now add a new condition to the IAM policies you attach to your IAM principal (user or role) to enforce this for all AWS services. In this post, I review conditions in policies, introduce the new condition, and review a policy example to demonstrate how you can control access across multiple AWS services to a specific region.

Restrict access to AWS resources based on Region, IP, or VPC

Lets take a problem statement like shown below:

You are setting up your initial AWS organization, you need to ensure that
teams are only able to deploy resources into North America regions for data sovereignty and limiting the blast radius in the case of a breach.

AWS: Allows enabling and disabling AWS Regions

Easier way to control access to AWS regions using IAM policies | Amazon Web Services

NOTE: AWS Control tower guardrails provide controls to enable data residency protection. This control disallows access to unlisted operations in global and regional services outside of the specified Regions. That includes all Regions where AWS Control Tower is not available, as well as all Regions not selected for governance in the Landing zone settings page. Actions are allowed as usual in Regions with Governed status.

This is an elective control with preventive guidance. It is the primary control associated with the Region deny action.

Controls that enhance data residency protection

If you’re using terraform, please take a look at the example configuration:

Create a locals.tf file and copy the following contents.

locals {
service_exemptions = [
"a4b:*",
"acm:*",
"aws-marketplace-management:*",
"aws-marketplace:*",
"aws-portal:*",
"awsbillingconsole:*",
"budgets:*",
"ce:*",
"chime:*",
"cloudfront:*",
"config:*",
"cur:*",
"directconnect:*",
"ec2:DescribeRegions",
"ec2:DescribeTransitGateways",
"ec2:DescribeVpnGateways",
"fms:*",
"globalaccelerator:*",
"health:*",
"iam:*",
"importexport:*",
"kms:*",
"mobileanalytics:*",
"networkmanager:*",
"organizations:*",
"pricing:*",
"route53:*",
"route53domains:*",
"s3:GetAccountPublic*",
"s3:ListAllMyBuckets",
"s3:PutAccountPublic*",
"shield:*",
"sts:*",
"support:*",
"trustedadvisor:*",
"waf-regional:*",
"waf:*",
"wafv2:*",
"wellarchitected:*"
]
}

data "aws_organizations_organization" "this" {}
resource "aws_organizations_policy_attachment" "root" {
   policy_id = aws_organizations_policy.top_level_region_lock.id
   target_id = data.aws_organizations_organization.this.roots[0].id
}
resource "aws_organizations_policy" "top_level_region_lock" {
   name = "region-lock"
   content = data.aws_iam_policy_document.region_lock_policy.json
}
data "aws_iam_policy_document" "region_lock_policy" {
statement {
   effect = "Deny"
   not_actions = local.service_exemptions
   resources = ["*"]
   condition {
     test = "StringNotEquals"
     values = var.allowed_regions
     variable = "aws:RequestedRegion"
  }
 }
}

To implement region locking on AWS, you need to use Service Control
Policies, or SCPs. They can be applied at any point of your organization
hierarchy, be that at the Organization Root, as per the solution, or against an Organizational Unit or individual Account.

You will have noticed in the previous terraform solution that there are a long list of API calls that are exempted from the lock.

This is due to one of the two following reasons.
1. The service is global in nature, and therefore needs to be exempted,
such as Web Application Firewall

2. The service has a hard requirement on a particular region, such as
CloudFront

To dive a bit further into the hard requirement on a particular region, for
certain AWS services, the control plane for that service exists only in one
region. In the case of CloudFront, as noted, the certificate to be used for
TLS must be in us-east-1. Unfortunately the only way to find these is to
read the service documentation.

Important things to keep in mind when enabling and disabling AWS Regions:

1. Enabling a Region is free
2. Alongside, SCPs, You can use IAM permissions to control access to Regions
3. Disabling a Region disables access to resources in the Region
4. Disabling a Region isn’t always immediately visible
5. Charges for active resources continue if you disable a Region
6. Enabling a Region takes a few minutes for most accounts

Specifying which AWS Regions your account can use

To summarize,

1. Certain resources require us-east-1 to function, so you need to
   maintain a service exception list
2. You can also add conditions to allow certain users, often security
   personnel to subvert the region locking when needed
3. IAM principals acting from outside your organization are not affected by SCPs.

If you liked this story ~ clap, follow :)