AWS Builder Center

Builder Center

Compliance with AWS Config: Detection, Remediation, and Verification

Compliance with AWS Config: Detection, Remediation, and Verification

The lab focused on using AWS Config to monitor resources, evaluate them against security rules, identify noncompliant resources, and automatically remediate those issues using AWS Systems Manager Automation. The exercise covered EC2 and Amazon S3 security controls and provided a practical example of how compliance automation can become part of a cloud security architecture.

Cloud security is not only about configuring resources securely once. In a real environment, resources change constantly. New EC2 instances can be launched, S3 configurations can be modified, and security controls can gradually drift away from organizational requirements.
This creates an important question:
How do you continuously identify resources that are no longer compliant and automatically correct them?
I explored this problem in an AWS Builder Lab titled “Automate Infrastructure Compliance with AWS Config.”
The lab focused on using AWS Config to monitor resources, evaluate them against security rules, identify noncompliant resources, and automatically remediate those issues using AWS Systems Manager Automation.
The exercise covered EC2 and Amazon S3 security controls and provided a practical example of how compliance automation can become part of a cloud security architecture.

Understanding the Compliance Problem

The scenario was based on an organization called AnyCompany that was responsible for securing application infrastructure.
There were several requirements:
  • EC2 instances must not have public IP addresses.
  • S3 buckets must not allow public read access.
  • S3 buckets must have versioning enabled.
  • A specific bucket containing high-security application data must also have access logging enabled.
These requirements sound straightforward when written as policies.
The challenge is enforcing them continuously.
For example, an administrator could verify today that an EC2 instance has no public IP address. But what happens when another instance is launched tomorrow? Or when an S3 bucket configuration changes?
This is where AWS Config becomes useful.
Instead of relying entirely on manual reviews, AWS Config continuously records resource configurations and evaluates them against defined compliance rules.

Setting Up AWS Config

The first stage was setting up AWS Config.
The lab used the 1-click setup option, which configured AWS Config using AWS-recommended settings.
The setup included recording all AWS resource types, using the service-linked role AWSServiceRoleForConfig, and creating an S3 bucket to store configuration history and snapshots.
After setup, the AWS Config dashboard initially showed no compliance rules because no rules had been created yet.
This highlighted an important distinction:
Recording infrastructure is not the same as evaluating infrastructure.
AWS Config needs rules to determine whether the recorded configuration satisfies a particular security or compliance requirement.

Discovering Resources with AWS Config

Once AWS Config was running, I explored the Resource Inventory.
The inventory contained different AWS resources, including:
  • VPCs
  • Subnets
  • Route tables
  • EC2 instances
  • S3 buckets
I filtered the inventory to examine EC2 instances and found two instances.
I then filtered for S3 buckets and identified the lab resources that would be used for the compliance checks.
Two important buckets were:
  • versioned-bucket-*
  • versioned-logged-bucket-*
The naming distinction was important because each bucket represented a different security requirement.
The exercise was therefore moving from:
What resources exist?
to:
Are those resources configured according to our security policies?

Creating an EC2 Security Compliance Rule

The first compliance requirement concerned EC2.
The application being developed by AnyCompany contained proprietary information, so EC2 instances needed to remain isolated and could not have public IP addresses.
To enforce this requirement, I created an AWS Config managed rule based on:
ec2-instance-no-public-ip
The rule was named:
isolated-compute-rule
The rule checks whether an EC2 instance has a public IP association.
This is a simple but important cloud security control.
A public IP does not automatically mean that an instance is vulnerable, but unnecessarily exposing a sensitive workload to the public internet increases the attack surface.
Using AWS Config allows this requirement to become an automated compliance check rather than relying solely on manual inspection.

Creating S3 Security Rules

The next part of the lab focused on Amazon S3.
Three different controls were used.

1. Preventing Public Read Access

The first rule was:
s3-bucket-public-read-prohibited
with the configuration name:
s3-block-public-access
The purpose was to ensure that S3 buckets did not allow public read access.
The rule evaluates relevant S3 public-access configuration, including Block Public Access settings, bucket policies, and ACLs.
This is particularly important because an incorrectly configured S3 bucket can unintentionally expose sensitive information.

2. Enforcing S3 Versioning

The second rule was:
s3-bucket-versioning-enabled
with the configuration name:
s3-bucket-versioning-on
Versioning allows multiple versions of objects to be maintained within the same S3 bucket.
From a security and operational perspective, versioning can provide an additional layer of protection when objects are modified or deleted.
In this lab, versioning was required for the bucket containing medium-security application feedback data.

3. Enforcing S3 Access Logging

The third rule was:
s3-bucket-logging-enabled
with the configuration name:
s3-bucket-logging-on
Unlike the versioning rule, this rule was configured to target a specific bucket: the versioned-logged-bucket.
This bucket represented high-security application source code, so it needed both:
  • Versioning
  • Server access logging
S3 access logging provides records of requests made to a bucket and can support security monitoring, auditing, and troubleshooting.

Identifying Noncompliant Resources

After creating the rules, AWS Config evaluated the resources.
The dashboard showed a mixture of compliant and noncompliant resources.
The lab expected three noncompliant rules:
  • isolated-compute-rule
  • s3-bucket-versioning-on
  • s3-bucket-logging-on
The public-read rule was already compliant.
This was an important stage because compliance monitoring is not useful simply because it can detect problems. The next step is understanding which resources violate which controls.
For example, the versioned-logged-bucket was affected by multiple S3 rules.
Its versioning and logging controls were not enabled, so AWS Config marked the resource as noncompliant.
This demonstrated how a single resource can have multiple compliance requirements applied to it.

Moving from Detection to Automated Remediation

Detection is only half of the problem.
If AWS Config tells a security team that a resource is misconfigured, someone still needs to fix it.
The lab therefore introduced automatic remediation.
This was one of the most valuable parts of the exercise because it demonstrated a basic closed-loop security process:
Detect → Evaluate → Remediate → Verify
AWS Config identified the violation, and AWS Systems Manager Automation documents were used to perform the remediation.

Automatically Remediating the EC2 Instance

For the EC2 compliance rule, the remediation action used was:
AWS-TerminateEC2Instance
The resource identifier was:
InstanceId
An AutomationAssumeRole was also configured using the provided AutomationServiceRole.
The logic was straightforward:
If an EC2 instance violates the rule because it has a public IP, AWS Config can trigger an automation action that terminates the instance.
This is a powerful example of automated enforcement.
However, it also demonstrates why automated remediation must be designed carefully.
Termination is a destructive action. In a production environment, organizations would need to consider whether terminating a noncompliant instance is appropriate or whether a less destructive remediation should be used.
For the lab scenario, termination was the intended security response.

Automatically Enabling S3 Versioning

The S3 versioning rule used the Systems Manager Automation document:
AWS-ConfigureS3BucketVersioning
The resource identifier was:
BucketName
The remediation action was configured to use the provided automation role while keeping the remaining default parameters.
The objective was simple:
If an S3 bucket was found to be noncompliant because versioning was disabled, the automation would enable versioning.
This is a good example of a corrective security control because the system can fix a configuration problem without requiring someone to manually open the S3 console.

Automatically Enabling S3 Logging

The final remediation addressed the high-security S3 bucket.
The Systems Manager Automation document was:
AWS-ConfigureS3BucketLogging
The target bucket for log delivery was configured using the provided LogFilesBucket.
The lab also required:
GrantedPermission:
FULL_CONTROL
GranteeType:
Group
GranteeUri:
http://acs.amazonaws.com/groups/s3/LogDelivery
The AutomationAssumeRole was also configured.
The Grantee URI represents the Amazon S3 Log Delivery group that needs permission to write access logs to the target bucket.
This configuration demonstrated that automated remediation can involve more than simply changing one Boolean setting. Some controls require multiple parameters to correctly establish the desired security configuration.

Triggering the Remediation

One subtle but important part of the lab was the need to re-evaluate the rules after configuring remediation.
The existing resources were already marked noncompliant before the remediation actions were configured.
Therefore, simply saving the remediation settings did not automatically cause those existing findings to be remediated.
The rules had to be re-evaluated.
The three rules were manually re-evaluated:
  1. isolated-compute-rule
  2. s3-bucket-versioning-on
  3. s3-bucket-logging-on
After the new evaluations, AWS Config detected the noncompliant resources again and triggered the configured remediation actions.
The lab noted that the remediation process could take approximately 10–15 minutes.
Eventually, the dashboard showed the resources as compliant.

Reviewing the Resource Timeline

AWS Config also provides a resource timeline that records configuration and compliance changes.
After remediation completed, I reviewed the timeline for the versioned-logged-bucket.
The timeline provided visibility into when the resource changed compliance status and when configuration changes were applied.
This is particularly useful from an incident-response and auditing perspective.
Instead of only knowing the current state of a resource, security teams can investigate how that state changed over time.
That historical context can help answer questions such as:
  • When did the resource become noncompliant?
  • When was the configuration changed?
  • When did remediation occur?
  • Did the resource return to a compliant state?

Verifying the Remediation

The final stage was to verify that the automated actions actually changed the resources as expected.
For EC2, the two instances could be inspected.
The instance named Private IP remained running and did not have a public IPv4 address.
The instance named Public IP had been terminated as a result of the EC2 remediation.
The S3 resources could then be inspected.
For versioned-bucket, bucket versioning was now enabled.
For versioned-logged-bucket, both:
  • Bucket versioning
  • Server access logging
were enabled.
The lab also provided another way to verify the automation through AWS Systems Manager Automation, where the automation executions could be reviewed and their status observed.
This created a clear chain of evidence:
AWS Config finding → Systems Manager Automation → Resource change → Compliance restored

The Security Architecture Behind the Lab

The lab demonstrated a simple but effective compliance automation architecture:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
AWS Resources
│
┌───────────┴───────────┐
│ │
EC2 S3
│ │
└───────────┬───────────┘
│
AWS Config
│
Compliance Rules
│
┌──────────┴──────────┐
│ │
Compliant Noncompliant
│
▼
Systems Manager
Automation
│
▼
Resource Remediation
│
▼
AWS Config Re-evaluation
│
▼
Compliant
The important concept is that security is not treated as a one-time configuration task.
It becomes a continuous process.

Connecting AWS Config to Cloud Security

For someone working toward cloud security, this lab connects several important areas.
AWS Config provides the compliance assessment layer.
Systems Manager Automation provides the remediation mechanism.
IAM roles control what the automation is allowed to perform.
Amazon S3 provides the storage resources being protected.
EC2 represents compute infrastructure that needs to be secured.
Together, these services demonstrate a practical implementation of automated cloud governance.
The broader security principle is configuration drift management.
Cloud environments change constantly. A resource that is secure today may become noncompliant later because of a configuration change.
The goal is therefore not simply:
"Configure it securely."
It is:
"Continuously verify that it remains secure."#
This AWS Builder Lab gave me a practical understanding of how AWS Config can be used to move from passive monitoring to automated compliance enforcement.
The workflow was straightforward but powerful:
Define security requirements → create Config rules → identify violations → configure remediation → re-evaluate → verify the changes.
The EC2 example demonstrated automated response to public exposure, while the S3 examples showed how versioning, public-access protection, and logging can be continuously evaluated.
The biggest takeaway for me is that cloud security cannot depend entirely on manual configuration.
As cloud environments become larger and more dynamic, organizations need mechanisms that can continuously detect configuration drift and, where appropriate, automatically correct it.
AWS Config combined with Systems Manager Automation provides a strong foundation for that type of workflow.
In practical cloud security, the goal is not simply to build secure infrastructure.
The goal is to build infrastructure that can continuously prove — and, when appropriate, restore — its compliance with security requirements.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article