Implementing Continuous Compliance with AWS Config and AWS Audit Manager: Part 1


Table of Contents
- Introduction
- Use Case
- Architecture Overview
- How AWS Audit Manager Integrates with AWS Config
- Process Overview: Enabling Continuous Compliance in AWS
- Conclusion
- Next Steps
- About the Author
Introduction
As enterprises migrate workloads to the cloud, security and compliance become increasingly complex. Ensuring continuous adherence to internal policies and external regulatory standards like PCI-DSS, HIPAA, or ISO 27001 requires robust visibility, enforcement, and automation.
This blog post walks you through implementing continuous compliance in AWS using AWS Config, AWS Config Rules, Auto Remediation, AWS Audit Manager, and CloudWatch Dashboards. By the end, you’ll have an automated pipeline that detects non-compliant resources, remediates them, tracks trends over time, and simplifies audit readiness.
Use Case
Let’s say your organization has the following requirements:
- All S3 buckets must block public access
- EC2 instances must be of approved instance types only
- Root account must have MFA enabled
- RDS databases must not be publicly accessible
- Periodic audit reports are needed for ISO 27001 compliance
We’ll demonstrate how to enforce and automate checks for these using AWS Config and Audit Manager.
Architecture Overview
The continuous compliance workflow is built around an automated pipeline leveraging core AWS services. Here’s how each component fits into the process:
- Resource Creation or Modification: Any change in AWS infrastructure (like creating an EC2 instance or modifying an S3 bucket) is automatically tracked.
- AWS Config Evaluation: AWS Config continuously records resource configurations and evaluates them against predefined rules. These rules enforce organizational policies such as blocking public S3 buckets or ensuring MFA is enabled for root users.
- Config Rules Trigger: When a resource configuration is detected, it is evaluated by AWS Config Rules (both managed and custom). If the configuration is compliant, it’s logged as such. If not, the system flags the resource as NON_COMPLIANT.
- Automated Remediation (via AWS Systems Manager or Lambda): For non-compliant resources, automated remediation actions are triggered. These use AWS Systems Manager (SSM) automation documents or Lambda functions to correct the issues without manual intervention.
- Compliance Insights in Amazon CloudWatch: All evaluation results and remediation statuses are logged and visualized through Amazon CloudWatch Dashboards. These dashboards provide real-time visibility into compliance posture across services and accounts.
- Audit Reporting via AWS Audit Manager: To meet regulatory and internal audit requirements, AWS Audit Manager continuously collects evidence from AWS Config and related services. It compiles audit-ready reports aligned with standards like ISO 27001, HIPAA, and PCI-DSS.
This flow ensures an end-to-end automated compliance and governance mechanism — from detection and remediation to monitoring and audit readiness — with minimal manual oversight.
Please find architecture diagram as below:

How AWS Audit Manager Integrates with AWS Config
Audit Manager Pulls Evidence from AWS Config
Audit Manager has prebuilt and custom frameworks that define which AWS services to collect evidence from.
- When you enable a framework (e.g., AWS Default Framework or ISO 27001), Audit Manager creates control sets.
- For controls that depend on AWS Config (such as “S3 buckets should block public access”), Audit Manager uses AWS Config as an evidence source.
Example: If s3-bucket-public-read-prohibited
rule is enabled in Config, Audit Manager pulls its compliance evaluations as evidence for relevant controls.
Controls Use Config Rule Compliance Status
When a control in Audit Manager is mapped to a Config rule, it:
- Automatically tracks whether resources are compliant or not.
- Pulls the last compliance evaluation (via AWS Config’s API).
- Generates reports/audit-ready evidence from these evaluations.
No Manual Wiring Needed
The integration is native. Once you:
- Enable AWS Config
- Enable Audit Manager
- Choose a framework (like ISO, NIST, or custom),
…Audit Manager automatically links to the Config rules it needs.
Process Overview: Enabling Continuous Compliance in AWS
Step 1: Enable AWS Config
- Go to the AWS Console → AWS Config
- Click “Set up” (first time setup)
- Choose to record all resources in all regions
- Set up a dedicated S3 bucket for Config logs
- Enable AWS Config Recorder and Delivery Channel
Tip: Enable in all regions to avoid compliance gaps across regional resources
Step 2: Add AWS Managed Config Rules
Navigate to AWS Config > Rules > Add Rule and add the following managed rules as well as custom rules:
Rule Name | Description | Type |
s3-bucket-public-read-prohibited | Ensures S3 buckets block public read | Managed |
ec2-instance-type-check | EC2 only uses approved instance types | Custom (see below) |
root-account-mfa-enabled | Root user must have MFA enabled | Managed |
rds-instance-public-access-check | RDS should not be publicly accessible | Managed |
Step 3: Add Custom Config Rule
For custom rules (like approved EC2 types), we’ll use AWS Lambda and a custom rule trigger.
Example: EC2 Type Enforcement
Create the Lambda Function
- Go to the AWS Lambda console.
- Click Create function → choose Author from scratch.
- Set:
- Function name:
checkApprovedEC2InstanceTypes
- Runtime: Python 3.9
- Role: Choose or create a role with AWSConfigRulesExecutionRole permissions
- Function name:
- Click Create function.
- Use the following sample Python code:
import boto3, json
def lambda_handler(event, context):
config = boto3.client('config')
invoking_event = json.loads(event['invokingEvent'])
configuration_item = invoking_event['configurationItem']
instance_id = configuration_item['resourceId']
instance_type = configuration_item['configuration']['instanceType']
allowed_types = ['t3.micro', 't3.small']
compliance_type = 'COMPLIANT' if instance_type in allowed_types else 'NON_COMPLIANT'
config.put_evaluations(
Evaluations=[
{
'ComplianceResourceType': configuration_item['resourceType'],
'ComplianceResourceId': instance_id,
'ComplianceType': compliance_type,
'OrderingTimestamp': configuration_item['configurationItemCaptureTime']
},
],
ResultToken=event['resultToken']
)
Add Permissions
Ensure the Lambda function has the following IAM policy permissions:
config:PutEvaluations
logs:*
(for debugging)ec2:DescribeInstances
(if needed)
Attach the AWSConfigRulesExecutionRole
managed policy or equivalent.
Create Custom AWS Config Rule
- Go to AWS Config → Rules → Click Add rule.
- Choose Add custom rule.
- Enter:
- Name:
approved-ec2-instance-types
- Trigger type: Configuration changes
- Scope of changes: EC2:Instance
- Name:
- Specify the Lambda function ARN created earlier.
- Set evaluation frequency if required (optional).
- Save.
Step 4: Setup Automatic Remediation with SSM or Lambda
- Go to AWS Config > Rules > Remediation
- Choose the rule (e.g., s3-bucket-public-read-prohibited)
- Select Remediation action:
- Action: AWSConfigRemediation-ConfigureS3PublicAccessBlock (or create custom)
Below are the screenshots to assist you with the setup:


Step 5: Configure AWS Audit Manager
- Go to AWS Audit Manager
- Choose Frameworks > Create Assessment
- Select a standard (e.g., ISO 27001, HIPAA, or custom)
- Add control sets and AWS Config as a data source
- Select relevant accounts, services, and define the scope
- Launch assessment – Audit Manager now collects evidence automatically (like rule compliance logs, resource snapshots, etc.)
Audit Manager continuously gathers data, reducing manual evidence gathering during audits.
Step 6: Create a Compliance Dashboard (CloudWatch)
Why?
Dashboards make compliance visual, actionable, and easy to monitor. Once AWS Config is enabled, it automatically sends some standard metrics to CloudWatch under the namespace: AWS/Config. These include:
Metric Name | Description | Dimensions |
---|---|---|
ComplianceChangeCount | Number of compliance state changes (e.g., from COMPLIANT to NON_COMPLIANT) | RuleName, ConfigRuleArn, ResourceType |
EvaluationResultCount | Number of evaluation results reported by rules | ComplianceType, ConfigRuleArn |
NonCompliantResourceCount | Number of non-compliant resources per rule | RuleName, ResourceType, ConfigRuleArn |
ConfigRuleEvaluations | Number of times a rule evaluated a resource | ConfigRuleArn |
Here’s what you can confidently show based on AWS Config’s built-in metrics:
Widget | Metric Source | Visualization |
---|---|---|
Total compliant vs non-compliant | EvaluationResultCount | Pie chart |
Compliance trend over time | ComplianceChangeCount | Line graph (time series) |
Top 5 non-compliant rules | NonCompliantResourceCount | Horizontal bar chart |
Rule evaluation frequency | ConfigRuleEvaluations | Bar chart |
Below are the screenshot of CloudWatch dashboard for your reference(wait for some datapoints in metrics):


Conclusion
Implementing continuous compliance using AWS Config, Audit Manager, and related services offers a scalable, automated way to maintain security and meet regulatory requirements. With real-time checks, auto-remediation, audit-ready reporting, and visual dashboards, your cloud environment becomes easier to govern and more resilient to misconfigurations.
Next Steps
To extend this setup, consider integrating with other AWS security services such as AWS Security Hub, AWS GuardDuty, and AWS Detective for deeper threat visibility, correlation of findings, and a unified security posture across your AWS accounts.
About the Author
Deepali Sonune is a DevOps engineer with 12+ years of industry experience. She has been developing high-performance DevOps solutions with stringent security and governance requirements in AWS for 9+ years. She also works with developers and IT to oversee code releases, combining an understanding of both engineering and programming.