Proactive controls
These controls are referred to as proactive because they check your resources – before the resources are deployed – to determine whether the new resources will comply with the controls that are activated in your environment.
Proactive controls are optional controls implemented with AWS CloudFormation hooks and hooks managed by AWS Control Tower. Proactive controls fall into four main Categories.
In the AWS Control Tower console, you can view the controls in groups according to their assigned categories, which are:
-
Control objectives: Specific purposes for implementing controls in your environment.
-
Frameworks: Industry-standard compliance frameworks.
-
Services: The AWS services that the control may govern.
Groups: Groups of controls designed to help you meet a specific policy standard.
In this reference guide, the proactive controls are categorized according to their associated AWS services.
Behavior of proactive controls
Proactive controls check resources whenever those resources are created or updated by
means of AWS CloudFormation stack operations. Specifically, these proactive controls are implemented as
preCreate
and preUpdate
hook handlers. As a consequence,
these controls may not affect requests that are made directly to services through the AWS
console, through AWS APIs, or through other means such as AWS SDKs, or other
Infrastructure-as-Code (IaC) tools. For more information about when preCreate
and preUpdate
hooks operate, see AWS CloudFormation
hooks.
Limitation of hooks managed by AWS CloudFormation
Proactive controls evaluate strings passed into the AWS CloudFormation hook within the
targetNames
property. Secure strings and secrets are not resolved
before they are sent to the hook, which prevents the proactive control from evaluating
the string. For more information about how the targetNames
are passed to
hooks, see AWS CloudFormation Hooks
structure overview.
When you follow an example template to set up a test for a proactive control in your environment, be aware that the template is created to test one specific control only. Other controls may not receive a PASS rating for that template. This behavior is expected. We recommend that you test proactive controls individually before you enable them in your environment.
Topics
- Amazon API Gateway controls
- AWS Certificate Manager controls
- AWS AppSync controls
- Amazon Athena controls
- Amazon CloudFront controls
- AWS CloudTrail controls
- Amazon CloudWatch controls
- AWS CodeBuild controls
- AWS Database Migration Service (AWS DMS) controls
- Amazon DocumentDB controls
- Amazon DynamoDB controls
- DynamoDB Accelerator controls
- AWS Elastic Beanstalk controls
- Amazon Elastic Compute Cloud (Amazon EC2) controls
- Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling controls
- Amazon ElastiCache controls
- Amazon Elastic Container Registry controls
- Amazon Elastic Container Service controls
- Amazon Elastic File System controls
- Amazon Elastic Kubernetes Service (EKS) controls
- Elastic Load Balancing controls
- Amazon Elastic Map Reduce (Amazon EMR) controls
- AWS Glue controls
- Amazon GuardDuty controls
- AWS Identity and Access Management (IAM) controls
- AWS Key Management Service (AWS KMS) controls
- Amazon Kinesis controls
- AWS Lambda controls
- Amazon MQ controls
- Amazon Managed Streaming for Apache Kafka (Amazon MSK) controls
- Amazon Neptune controls
- AWS Network Firewall controls
- Amazon OpenSearch controls
- Amazon Relational Database Service (Amazon RDS) controls
- Amazon Redshift controls
- Amazon Simple Storage Service (Amazon S3) controls
- Amazon SageMaker controls
- Amazon Simple Queue Service (Amazon SQS) controls
- AWS Step Functions controls
- AWS WAF regional controls
- AWS WAF controls
- AWS WAFV2 controls