AWS Organizations SCP setup to restrict regions

How to ensure that AWS data that must be hosted and accessed in one specific AWS region is protected effectively?

A project I am working on has data that must be hosted in one specific AWS region for regulatory reasons. AWS is a worldwide service and certain elements of it such as the root user, and users set up using Identity and Access Management (IAM) are globally provided and cannot be region restricted. However it is possible to deny access to specific AWS features based on the requested AWS Region using an AWS Organizations service control policy (SCP). IAM provides control over users and roles in individual accounts, and is itself managed by the AWS root user account which should be used sparingly and carefully. AWS Organizations expands that control to the member accounts level by giving you control over what these accounts can do.

Organising your member accounts in AWS into AWS Organisations is good practice and is especially useful for delegating control for budgetary, security, or compliance needs, for example in different departments or separately budgeted development teams, while retaining overall governance through management accounts with responsibility for consolidated billing, security and governance. AWS Organizations is a no-charge feature of AWS, the only cost really is the investment in time in designing and setting it up to match the structure of your organisation.

What I was able to do

• Create an organization and organizational units (OUs) in it
• Create a member account inside an OU
• Enable all policy categories in AWS organizations
• Create service control policies (SCPs) that apply to member accounts in the OU
• Confirm in the AWS Consol that those policies were working correctly

TL:DR — AWS Organisations is a powerful way to provide more granular access to AWS features. It requires the creation of member accounts, which are different to IAM accounts and the root account. Once you set it up it is easy to adjust to meet any future AWS budgetary, security, or compliance needs. And its FREE to use.

Creating an organisation in AWS organizations

Use IAM to give full permissions to AWS Organizations to an administrator account.

• Sign in to AWS as the administrator account and open the AWS Organizations console.
• Choose Create an AWS organization (highlighted in the screenshot at the top of the article) and confirm. AWS creates the AWS organization then refreshes to the AWS accounts page.

  

  
  This is a new AWS organization with your account as its only member. Your account is now the management account of the AWS organization.
• Create an organizational unit by selecting the the Root container, and choosing 'Actions', and then under 'Organizational unit', choose 'Create new'. I created 'UK and then 'London Only' (for my requirement of region restriction) and then chose Create organizational unit for each of them. OUs enable you to group accounts together and administer them as a single unit instead of one at a time to serve whatever purpose you have in mind.
• Now you can add member accounts into these OUs. Just select the checkbox next to an OU and click 'Add an AWS account'. I only have one member account in the screenshot, in the 'London Only' OU.
  
  Warning! — Pay careful attention to the email address because you can’t sign in to this new member account without successfully receiving a password reset email!

  

Enable all policy categories in AWS organizations

AI services opt-out, Backup, Service control and Tag policies in AWS organizations

Policies in AWS Organizations enable you to manage the different features of AWS accounts in your organization. Four categories of policies are available in AWS Organizations, AI services opt-outs, Backups, Service controls and Tags, respectively.

• Artificial Intelligence (AI) services opt-out policies enable you to control whether AWS AI services can store and use your content.
• Backup policies enable you to deploy organization level backup plans to help ensure compliance across your accounts. Using policies helps ensure consistency in how you implement your backup plans.
• Service control policies (SCPs) enable central administration over the permissions available within the accounts in the AWS organization. This helps ensure that accounts stay within any required access control guidelines you may have.
• Tag policies help you standardize tags on all tagged resources across your organization. You can use tag policies to define tag keys and their allowed values.

It seems like good practice to set all four to be 'enabled' and configure them separately.

Set up region control via Service control policies in AWS organizations

Service control policies (SCPs) enable central administration over the permissions available within the accounts in your organization. The default policy FullAWSAccess is attached to the root, all organizational units (OUs) and all accounts.

"It doesn't actually grant the permissions; no SCP does. Instead, it enables administrators in that account to delegate access to those actions by attaching standard AWS Identity and Access Management (IAM) permissions policies to users, roles, or groups in the account."

Example service control policies - AWS Organizations

Set up region control via Service control policies in AWS organizations

One of the first example SCPs in the AWS Organizations user guide is designed to deny access to any operations outside of specified Regions. This is exactly what is required in my project so lets go ahead and implement it.

The policy uses Deny to deny access to all requests for operations that don't target the approved region, eu-west-2 which is London. The NotAction element enables you to list global services whose operations need to be exempted from this restriction. AWS global services have endpoints that are physically hosted by the us-east-1 Region , and must be exempted in this way. With an SCP structured this way, requests made to global services in the us-east-1 Region are allowed if the requested service is included in the NotAction element. Any other requests to services in the us-east-1 Region are denied. Like the example this policy allows for accounts with an administrator role, in this case RoleAllowedOutsideLondon to be exempt. There are some further considerations and the list of elements might change over time, so do check the latest AWS documentation for this example.

AWS SCP Screenshot — DenyAllOutsideLondon

AWS SCP Code — DenyAllOutsideLondon

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideLondon",
            "Effect": "Deny",
            "NotAction": [
                "a4b:*",
                "acm:*",
                "aws-marketplace-management:*",
                "aws-marketplace:*",
                "aws-portal:*",
                "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:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "eu-west-2"
                    ]
                },
                "ArnNotLike": {
                    "aws:PrincipalARN": [
                        "arn:aws:iam::*:role/RoleAllowedOutsideLondon"
                    ]
                }
            }
        }
    ]
}

Attach your AWS Organizations SCP to an OU

There are a few more steps to make the policy work:-

• Paste the policy into the policy editor and click 'Create Policy'.
• Your new policy will now appear on the list!, Open it select 'Targets' and click 'Attach'
  

  

• Choose the target OU (London Only) in the hierarchy and click 'Attach policy' and you should see an alert "successfully attached the policy".

Gain access to the member account through password reset

• The password was set on member account creation and cannot be retrieved so you will need to sign in to AWS Console with the member account you placed in the AWS Organizations OU and reset it. Sign in as if you were a root user using the email of the member account you just created, and go through the process for password recovery.
  

  

  
  Make a note of the password in your password manager :) This is more difficult than it perhaps ought to be and if you made a mistake with the email address for the member account you will have to raise a support issue with AWS to fix it!

Test your AWS Organizations SCP with a member account

• Now you can use the new credentials to sigin in to the AWS Console as the member account for your AWS Organization. To test that our SCP is working, load up EC2 and you should be unable to create or launch an instance because you are in us-east-1.
  

  

• Switch to eu-west-2 and refresh. Now note that you can launch instances in London because the SCP is working as intended!
  

  

• Now I know that member accounts use of AWS is correctly restricted to London. Attempts to create AWS services outside of global services will fail. The AWS Console is a little raw in that you see red API error messages. It works though and that is the main thing. After all AWS Console users aren't really ordinary end-users, so they should be able to understand the error messages mean there is a SCP in place and not a problem with AWS.