AWS Config enables continuous cloud governance by monitoring resource compliance, automating remediation, and enforcing preventative controls with Service Control Policies (SCPs). This proactive lifecycle helps organisations reduce risk, streamline operations, and maintain security without slowing down delivery.
Table of Contents
As cloud environments scale, so too does the challenge of managing configuration drift, security risks, and compliance obligations. In the ever-changing AWS environment, traditional manual controls aren’t enough to ensure your infrastructure remains compliant and secure. This can lead to challenges managing things like continuous auditing, compliance, security analysis, incident response, troubleshooting, change management, etc.
Enter AWS Config, a powerful service that continuously monitors resource configurations in your AWS Organization, evaluates them against compliance baselines and enables automated responses to violations.
In this blog, I’ll explore how AWS Config supports a holistic lifecycle approach to governance: from monitoring, to remediation, to prevention. Monitor to continuously identify compliance issues. Configure auto-remediation to remedy these identified issues without human intervention. Finally, make use of Service Control Policies (SCPs) to prevent these compliance issues going forward. When orchestrated together in this manner, AWS Config can facilitate a continuous uplift of your organisation’s compliance procedures through a unified lifecycle approach.
Why AWS Config?
At its core, AWS Config:
- Records configuration changes of AWS resources
- Evaluates those changes against defined compliance rules
- Notifies when a resource becomes non-compliant
- Facilitates centralised visibility and automated remediation
This turns your organisation’s configuration management from a reactive task into a proactive system of record and enforcement. When applied appropriately, AWS Config can act as the backbone of a continuous governance and compliance lifecycle.
In this blog, I discuss using AWS Config for both monitoring and auto-remediation of non-compliant resources, which, in turn, informs continuous uplift of preventative controls to avoid non-compliance in the first place. But to begin, it’s essential to identify where non-compliance occurs.
Further reading: AWS Config can be costly if not managed correctly. Our Understanding and optimising AWS Config costs blog can help you keep costs under control!
Using AWS Config identify existing compliance issues
Hence, the first step toward control is visibility.
With AWS Config, you can define a set of managed or custom rules that enforce your organisation’s security, operational, and compliance requirements. These rules continuously assess resources and flag any that deviate from policy.
For example, AWS Config policies can:
- Ensure S3 buckets are encrypted
- Confirm CloudTrail is enabled and logging
- Detect public access on security groups
When a violation occurs, AWS Config can immediately notify your team using Amazon EventBridge coupled with Amazon SNS, enabling near real-time awareness of compliance issues. This is especially powerful if your organisation exists in a fast-moving environment where a misconfiguration can become a breach in minutes.
Say, for example, a configuration change has led to a security group allowing open access to an SSH port on an EC2 instance that has elevated privileges in our organisation’s production environment – possibly even to a database. We now risk a malicious actor breaching production data via attacks on this open SSH port. AWS Config can notify us that this has occurred, and we can respond immediately to fix the security group and mitigate this risk. Additionally, if we were monitoring Config in our pre-production environments, we likely would have picked it up before it even made it to production.
We can achieve this monitoring with an architecture that makes use of Config events, EventBridge, and SNS to alert a Slack channel of AWS Config non-compliance events to ensure consistent monitoring, similar to the architecture outlined here:
How it works:
- Child Accounts run AWS Config rules and record configuration changes.
- EventBridge is used to forward non-compliant AWS Config notifications to a centralised SNS topic in the Audit account.
- In the Audit Account:
- An AWS Lambda function is triggered via Config notifications channelled through SNS.
- The Lambda processes the finding and sends an alert to a Slack channel.
This architecture ensures:
- Central visibility across all accounts
- Real-time alerting and compliance tracking for early alerting and intervention
Fix compliance issues at scale with AWS Config
Detecting a problem is only half the battle. The next step is fixing it. Given the size of many AWS Organizations, ideally fixes should be automated to avoid the manual burden of repetitive fixes across tens, hundreds, or thousands of instances
AWS Config can facilitate this through auto-remediation integrated with AWS Systems Manager (SSM). You can attach automation documents to Config rules that, when violated, trigger corrective actions automatically.
For instance:
- Re-enable encryption on an S3 bucket
- Remove a wide-open CIDR block from a security group
- Terminate unapproved EC2 instance types
Auto-remediation closes the loop, dramatically reducing the mean time to resolution and removing repetitive tasks from your operations teams. This can be accomplished at scale by configuring auto-remediation via Cloudformation StackSets and deploying across your AWS Organization.
Here’s an example Cloudformation StackSet template that makes use of SSM Runbooks to remediate Config findings automatically:
AWSTemplateFormatVersion: '2010-09-09'
Description: >
CloudFormation template to be deployed via StackSets for configuring AWS Config
to auto remediate <ADD YOUR RULE DESCRIPTION>
Resources:
# AWS Config Rule
ConfigRule:
Type: 'AWS::Config::ConfigRule'
Properties:
ConfigRuleName: <ADD THE CONFIG RULE NAME>
Description: '<YOUR DESCRIPTION>'
Scope:
ComplianceResourceTypes:
- 'AWS::EC2::SecurityGroup'
Source:
Owner: AWS
SourceIdentifier: <CONFIG RULE SOURCE IDENTIFIER>
# Remediation Configuration
RemediationConfiguration:
Type: 'AWS::Config::RemediationConfiguration'
Properties:
ConfigRuleName: !Ref ConfigRule
Automatic: true
MaximumAutomaticAttempts: 5 #minutes
RetryAttemptSeconds: 50 #seconds
TargetType: SSM_DOCUMENT
TargetId: <AWS SSM CONFIG REMEDIATION RUNBOOK ID>
Parameters:
AutomationAssumeRole:
StaticValue:
Values:
- !GetAtt AutomationRole.Arn
GroupId:
ResourceValue:
Value: RESOURCE_ID
ExecutionControls:
SsmControls:
ConcurrentExecutionRatePercentage: 10
ErrorPercentage: 10
# IAM Role for AWS Config
ConfigRole:
Type: 'AWS::IAM::Role'
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: config.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWS_ConfigRole
Policies:
- PolicyName: ConfigRemediation
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- 'ssm:StartAutomationExecution'
Resource: '*'
# IAM Role for Systems Manager Automation
AutomationRole:
Type: 'AWS::IAM::Role'
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: ssm.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AmazonSSMAutomationRole
Policies:
- PolicyName: AutoRemediateConfig
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- <SSM REQUIRED ACTIONS>
Resource: '*'
Outputs:
ConfigRuleArn:
Description: ARN of the created Config Rule
Value: !GetAtt ConfigRule.Arn
AutomationRoleArn:
Description: ARN of the created Automation Role
Value: !GetAtt AutomationRole.Arn
We’ve found this to be an incredibly effective tool at removing the manual burden of remedying misconfigurations. For example, we’ve used auto-remediation to control ingress/egress rules for default security groups.
When a new default security group is created AWS automatically assigns open ingress/egress rules to it, even though this goes against AWS’s own recommendations. Using AWS Config with auto-remediation enables AWS Config to identify when a default security group has been created and remove the automatically created rules so that the default security group does not allow any traffic – bringing it in line with the AWS recommendations. This is identified and resolved without any user intervention and ensures compliance across our AWS Organization, even with new default security groups being constantly created.
Mitigate compliance issues with Service Control Policies (SCPs)
While monitoring and remediation are essential, the most robust security posture is achieved when misconfigurations are prevented altogether.
Once a misconfiguration has been identified and remedied, the next step is to ensure that it does not occur again. As we continue to monitor and surface new compliance issues, we can make use of Service Control Policies (SCPs) at the AWS Organization level to enforce account level guardrails to restrict actions that would bring about non-compliance in the first place.
Example preventative measures that SCPs can enforce are:
- Denying creation of unencrypted resources
- Blocking use of specific EC2 instance types
- Preventing modification of CloudTrail settings
SCPs harden your organisation’s security posture and ensure good practices from the very first deployment. This, coupled with a shift-left mentality, assists to develop a culture of compliance from the earliest parts of the resource lifecycle.
Paired with AWS Config, this creates a layered compliance model: prevent what you can, monitor everything else, and remediate quickly when needed.
In one example, we used this model to prevent issues with unencrypted EBS volumes. We had identified that EBS volumes were continuing to be created without encryption enabled. While we’d resolved the existing unencrypted volumes, had we stopped there this issue would have raised its head again. Instead, we enforced an SCP so that unencrypted EBS volumes could not be created. This removed the need to even think about this compliance issue in the future, as the SCP would deny any attempts to create an unencrypted EBS volume going forward.
A unified Cloud Governance model: Monitor → Remediate → Prevent
AWS Config shines brightest when used as part of a continuous governance lifecycle:
- Monitor: Continuously evaluate AWS resources against compliance rules and notify on violations
- Remediate: Where possible, automate the remedying of misconfigurations using SSM automation
- Prevent: Use SCPs to block non-compliant changes from ever being deployed
Continual monitoring surfaces compliance issues. Newly identified compliance issues lead us to taking remediation actions. Once we’ve remedied the compliance issues, we refine our preventative policies to prevent non-compliance going forward. This approach enforces a continual feedback loop that enables us to constantly uplift our compliance procedures – surfacing our compliance issues, remedying them, preventing them from happening again, back to monitoring for new issues.
This unified approach gives you:
- Faster resolution of misconfigurations
- Reduced risk exposure windows
- Continual feedback and uplift of compliance controls
- Responsiveness to AWS environment changes
By adopting this proactive lifecycle, your organisation can identify, remove, and control compliance issues continuously, without impacting agility – enabling your organisation to move faster with confidence!
Start leveraging AWS Config to build a proactive governance lifecycle across your AWS environment. If you need support implementing monitoring, remediation, or preventative controls at scale, get in touch with our team here —we’re here to help.
Matthew O’Neill is a Co-Ops Engineer with 5 years–experience in the technology sector. Having previously worked as a Software Engineer, Matthew brings experience across the technology & development lifecycle to the Co-Ops practice at Cevo.
