AWS provides several regions that we can choose to select which physical location where our infrastructure resources will be deployed. In our organization, overall we are using only 2 regions (ap-southeast-1 and us-east-1) out of 16 regions which are currently enabled. Thus, disabling the other 14 regions by completely restricting access to them will introduce several benefits:

Reduce the chance of paying costs of abandoned/forgotten resources.

Zero chance of resources will be provisioned in the regions by mistake, or forgotten after experimentation.

Improve security posture.

Zero chance of compromise in the regions if they are disabled.

Reduce operational overhead to provision security scaffolding resources on each region in all accounts.

Amazon GuardDuty, AWS CloudTrail, and AWS Config are currently required to be provisioned in all regions to ensure compliance with various security frameworks like WAR, CIS, NIST, etc.
Not only for the compliance, but the resources are needed to enable auditing, monitoring, and detection of security issues.
If the regions are disabled, there is no need to deploy the services.

Reduce costs of security scaffolding resources.

If nobody can use the disabled regions, there is no need to monitor and scan those regions for security issues.

Estimated Potential Cost Saving

If the security scaffolding resources are removed from the other 14 regions in all accounts in our organization, it can save our organization up to $4,300/month (based on billing data of the previous six months).

Execution Plan

We are using Service Control Policies (SCP)[1][2][3] to restrict access to the regions. We have tested the SCP on tvlk-tsi-dev account on April 30 and until the present, the SCP is still attached to the account. The plan is to attach the SCP to a shared non-production account first before rolling out globally. The details will be explained in the following section.

Important Dates

The operations will be divided into multiple phases which consist of different target accounts:

18 May 2020: tvlk-dev
13 August 2020: All Sandbox Accounts (tvlk-*-dev)
19 August 2020: All Staging Accounts (tvlk-*-stg)
26 August 2020: All Production Accounts (tvlk-*-prod)
2 September 2020: Special Accounts

tvlk-audit
tvlk-aws-org
tvlk-build
tvlk-domain
tvlk-lab
tvlk-user

9 September 2020: Legacy Accounts

tvlk-data
tvlk-midas
tvlk-prod

What You Should Do

As the resource owner/account administrator, you are responsible for your own resources/accounts. Hence, we will give you time until prior to the important dates mentioned above to do either of these things:

Remove unused resources on all regions (especially if they are located on regions other than ap-southeast-1 and us-east-1)

Once the SCP is applied to your account, nobody will be able to do anything on the disabled regions. Of course, that includes resource deletion actions. As a result, if you fail to do so in time, nobody will be able to delete them and you/your product domain will still be charged for the resources.

We made this guide about how to utilize some existing tools to identify and decommission existing resources: Ways to Identify Existing Resources

If you find lots of CloudFormation Stacks, no need to worry about those. They are scaffolding resources created by us before the accounts were given to you. We will take care of those resources, they will be deleted before the regions are disabled.

Move all your active resources to either ap-southeast-1 or us-east-1 regions

If active resources that you have currently do not reside in either ap-southeast-1 or us-east-1 regions, however, the AWS service is available on either the two regions, you need to move them out of their current region.

Let us know if you cannot do both of those two actions above

Raise your concern through our JIRA portal[4] and tell us the information below:

[psa] All AWS regions except Singapore and N. Virginia will be disabled

[Update]

Background