Specifying Triggers for AWS Config Rules

1. Triggered by Configuration Changes

This is the most common and immediate type of trigger. It operates on an event-driven basis.

• How it Works: The Config rule is automatically evaluated whenever a resource within its defined scope is created, updated, or deleted. AWS Config records the configuration change and immediately initiates the rule evaluation for that specific resource.

• Defining the Scope: To avoid unnecessary evaluations, you can precisely define the rule's scope. The trigger can be limited to:

  • One or more specific resource types (e.g., AWS::EC2::Instance, AWS::S3::Bucket).

  • A specific resource, identified by its resource ID.

  • Resources that have a specific tag key and value.

• When to Use It:

  • Continuous Compliance: This is the best choice when you need near-real-time feedback on your compliance status.

  • High-Priority Rules: For critical security or operational policies where you must be notified of a violation immediately. For example, a rule that checks for overly permissive security group rules or publicly accessible S3 buckets should be triggered by configuration changes.

  • Preventing Misconfigurations: To quickly catch when a resource is deployed that does not adhere to company policy (e.g., an unencrypted EBS volume is created).

2. Periodic Trigger

This trigger type runs the compliance evaluation on a scheduled basis, regardless of whether any configuration changes have occurred.

• How it Works: The Config rule is evaluated at a frequency that you choose. The available frequencies are 1, 3, 6, 12, or 24 hours.

• When to Use It:

  • Periodic Auditing: When you only need a regular "snapshot" of compliance for certain resources, rather than immediate, event-driven checks. For example, a daily check to ensure all IAM users have Multi-Factor Authentication (MFA) enabled.

  • Cost Management: If you have an environment with a very high volume of resource changes (creates, updates, deletes), a periodic trigger can be more cost-effective. Since you are charged per rule evaluation, running a check once every 24 hours will be cheaper than running it hundreds of times a day in response to changes.

  • Checks for Inactivity: For rules that check for something that hasn't happened, such as ensuring access keys are rotated regularly. A periodic check is the only way to evaluate this kind of policy.

How to Configure Triggers

When you create an AWS Config rule in the AWS Management Console, you will be prompted to specify the trigger type.

• For AWS Managed Rules: The trigger type is often pre-defined by the rule's logic and cannot be changed. For example, the iam-user-mfa-enabled rule is periodic by nature, while the ec2-instance-no-public-ip rule is triggered by configuration changes.

• For Custom Rules: When you create your own custom rule (using an AWS Lambda function), you have the flexibility to choose whether it is triggered by configuration changes or periodically, and you can define the scope or schedule accordingly.

By understanding and correctly applying these two trigger types, you can build a robust and cost-effective compliance framework with AWS Config that is tailored to the specific needs of your organization.