Regions
© 2025 Sonrai Security. All rights reserved.
Overview
Regions can be subject to cloud-wide control block that removes the ability for any cloud activity/usage within one or more regions (i.e. ca-central-1, etc.). This control is commonly used by many organizations that want to limit cloud sprawl and focus their teams on the regions in which they operate.
Identity exemptions DO NOT APPLY for any scope for services within a disabled region.
Regions can be disabled using either the AWS console or the Cloud Permissions Firewall.
Best practice: Manually audit regions before disabling to ensure there are no active/enabled resources, as you will not be able to modify/manage them once disabled!
Examples
- Example 1: When Outsiders Become Insiders
- Example 2: When Insiders Cause Problems
Example 1: When Outsiders Become Insiders
One day, a sophisticated attacker discovered that a business had several AWS regions enabled but not actively managed. Sensing an opportunity, the attacker began probing these unused regions for vulnerabilities. In one of these regions, the attacker found an old, unpatched service that had been inadvertently deployed during a testing phase and was never decommissioned!
Exploiting the outdated service, the attacker gained a foothold in the AWS environment through the unused region's resources. With this initial access, the attacker began exploring the company's global cloud infrastructure. They found that some of the IAM (Identity and Access Management) policies applied globally, allowing them to escalate their privileges and access resources in the active regions.
Once inside, the attacker managed to access sensitive customer data, including personal information and purchase histories (PII!). They exfiltrated this data and modified several logs and configurations to make detection/forensic timeline mapping more difficult.
Example 2: When Insiders Cause Problems
The development team at a company had recently experimented with various AWS regions for testing purposes. Some regions were enabled temporarily for specific projects but were never properly decommissioned after the projects ended. These unused regions remained active, though largely forgotten by the team.
One day, a developer was tasked with deploying a major update to the company's platform. This update included significant enhancements designed to improve data processing speed and introduce new features requested by several high-profile clients.
When selecting the target region in which to deploy these updates, the developer accidentally chose one of the unused regions rather than the primary production region! This resulted in confusion and delay for the production release for customers, additional costs to spin up brand new workloads in the unused region, etc.
Region Statuses
Key terms and concepts for each possible status you may encounter in the Regions card:
All accounts/identities [at any scope] are allowed to use this region
(i.e. you have not disabled this region [at any scope] through either the AWS console or Sonrai's Cloud Permissions Firewall yet)
This region is disabled for all accounts/identities
(i.e the service cannot be used at all, even by exempted identities)
Some accounts/identities [in scope] are allowed to use the region
Example: There are 2 AWS accounts involved and these combined enabled/disabled Region statuses contribute to the determination of "Partially Enabled" in the Cloud Permissions Firewall:
account1 region is enabled in AWS
Enabled in the Sonrai Cloud Permissions Firewall account2 region is disabled in AWSSome accounts/identities [in scope] are NOT allowed to use the region
Example: There are 2 AWS accounts involved and these enabled/disabled Region statuses contribute to the determination of "Partially Disabled" in the Cloud Permissions Firewall:
account1 region is enabled in AWS Enabled in the Sonrai Cloud Permissions Firewall account2 region is enabled in AWS Disabled in the Sonrai Cloud Permissions FirewallAny status with "(pending)" indicates there are entries within the Pending Changes page to review/action
Disabling Regions
At your chosen scope (Org/OU/Account), click to review the available regions map/list:
Once a region is selected, click within the region row and in the resulting confirmation window:
This will send your changes to the Pending Changes page to be reviewed and further actioned/deployed:
In this scenario with the Organization scope selected, the status of the region will change to "Disabled (pending)", then "Disabled" (once all Pending Changes are deployed to your cloud).
See our Pending Changes documentation for more information!
Enabling Regions
If a region is enable within the AWS console, you can keep it enabled (or re-enable it) with the Cloud Permissions Firewall, as needed.
If a region is disabled within the AWS console, you will NOT be able to enable it using the Cloud Permissions Firewall.
Regions FAQ
Will I need to manually audit and disable new regions introduced by AWS?
No! New regions are disabled by default by AWS & therefore Cloud Permissions Firewall.
What do regions with the lock symbol mean?
Regions with a lock icon are considered core AWS regions and cannot be disabled at any scope.
- US West (Oregon)
- US East (N. Virginia)