AWS Config Rules can automatically check your AWS resource configurations against desired configurations, essentially acting as an automated auditor for your cloud environment.
Let’s see how this looks in practice. Imagine you want to ensure all your S3 buckets are not publicly accessible.
First, you’d define an AWS Config Rule. You can use a managed rule, like S3_BUCKET_PUBLIC_READ_PROHIBITED, or write your own custom rule using Lambda.
Here’s a snippet of what a custom rule definition might look like in CloudFormation:
MyS3PublicAccessRule:
Type: AWS::Config::ConfigRule
Properties:
ConfigRuleName: "Ensure-S3-Buckets-Not-Publicly-Readable"
Description: "Checks if S3 buckets are configured to prevent public read access."
Scope:
ComplianceResourceTypes:
- AWS::S3::Bucket
Source:
Owner: CUSTOM_LAMBDA
SourceIdentifier: !GetAtt MyConfigLambdaFunction.Arn
SourceDetails:
- EventSource: aws.config
MessageType: CONFIG_REMEDIATION
When AWS Config detects a change to an S3 bucket, it invokes your Lambda function. The Lambda function receives an event payload containing details about the resource change. It then checks the bucket’s access control list (ACL) and bucket policy.
If it finds a configuration that allows public read access (e.g., a PublicRead ACL or a bucket policy granting s3:GetObject to Principal: "*" ), it reports the resource as non-compliant. If the configuration is secure, it reports it as compliant.
AWS Config uses a "desired state" model. You define what "compliant" looks like, and Config continuously evaluates your resources against that definition. This is powerful because it shifts compliance from a periodic, manual task to a continuous, automated process.
The core problem this solves is the drift between your intended security posture and your actual deployed resources. Manual checks are prone to human error and are time-consuming, making it easy for misconfigurations to slip through. Config Rules provide a persistent safety net.
Internally, AWS Config records configuration snapshots of your resources. When a rule is evaluated, Config queries these recorded snapshots and applies the rule’s logic. For custom rules, this evaluation triggers a Lambda function. The rule logic in Lambda typically involves examining the resource configuration details provided in the event, often by making API calls to services like S3 to get the latest configuration state.
The key levers you control are the rule definitions themselves. For managed rules, you select from a catalog of pre-built compliance checks. For custom rules, you have complete control over the logic executed by your Lambda function, allowing you to enforce highly specific or complex compliance requirements. You also define the Scope of the rule, specifying which resource types it applies to and whether it’s evaluated on all resources or a subset.
A common misconception is that AWS Config Rules only detect non-compliance. However, when combined with AWS Config Remediation, you can automatically fix many non-compliant configurations. For instance, you could set up a remediation action that automatically removes public read access from an S3 bucket when a Config Rule flags it as non-compliant. This is configured via AWS::Config::RemediationConfiguration resources.
The next concept you’ll likely explore is how to integrate AWS Config with your CI/CD pipelines to prevent non-compliant resources from being deployed in the first place.