AWS SCPs and Turbot v3

Turbot's current core architecture has been running preventative and corrective controls to protect against deployments and data storage in unapproved regions since v0.25 (2015). Our implementation was designed before AWS Organizations or AWS Service Control Policies existed. We believe it to be best practice that your governance guardrails actively check to make sure resources do not exist in unapproved regions.  This protects against the following scenarios:

  • Finds resources that may have been deployed prior to the implementation of SCPs.
  • Ability to easily manage exceptions for POCs, Joint Ventures, and M&As.
  • Checking to make sure administrators with the ability to create SCP exceptions are not able to circumvent company policy.
  • Ability to programmatically delete default AWS resources in unapproved regions (e.g Default VPCs).

Turbot v3 implements this model and assumes that it will be able to deploy any resources it needs in any region to monitor usage and run enforcements.  For organizations that wish to use SCPs to limit their exposure, exceptions for Turbot V3 IAM roles will need to be made.  If no exceptions are made then Turbot will raise alarms when it can't deploy or update require resources.

Turbot provides a mechanism to reduce the noise of such deployments.  Setting the AWS > Regions policy and the AWS > {Service Name} > Regions policies to only include regions available in the SCP will prevent the vast majority of control errors (but not all) from appearing in the account.

Moving forward, our new v5 architecture fully supports a customer's ability to selectively choose which regions Turbot will deploy resources to and perform checks in.  However, we still believe it to be an enterprise best practice to continue to monitor all regions for activity/resources when using SCPs as part of a mature defense-in-depth strategy.

Was this article helpful?
0 out of 0 found this helpful