Skip to main content
This guide demonstrates how to detect a non-compliant security group (an inbound SSH rule open to the internet) with AWS Config and automatically remediate it using an AWS Systems Manager Automation runbook. The walkthrough uses the AWS Management Console, but includes helpful tips and CLI examples for automation and verification. Overview of the workflow
  1. Create a security group with an intentionally insecure inbound SSH rule (source 0.0.0.0/0).
  2. Enable the AWS Config recorder so it captures resource configuration.
  3. Add the managed AWS Config rule restricted-ssh and scope it to the created security group.
  4. Configure an automatic remediation action using the SSM Automation runbook AWS-DisablePublicAccessForSecurityGroup.
  5. Provide an automation role with the required SSM Automation and EC2 permissions.
  6. Re-evaluate the rule to trigger remediation and verify the inbound SSH rule is removed and the security group becomes compliant.
Quick reference (example values) Resources and further reading Step 1 — Create an insecure security group
  • Open the EC2 console in the region you will use (the demo uses us-east-2).
  • Create a new security group (for example, config-sg).
  • Add an inbound SSH rule (TCP port 22) with source 0.0.0.0/0 so SSH is allowed from anywhere. This is intentionally insecure for demonstration purposes.
A screenshot of the AWS EC2 "Create security group" console showing the Inbound rules section. It displays an SSH (TCP port 22) rule with the source set to 0.0.0.0/0 (Anywhere-IPv4).
Warning: Exposing SSH to 0.0.0.0/0 allows anyone on the internet to attempt connections to hosts using this security group. Use this configuration only in a controlled lab environment. After creating the security group, keep the security group details page open — you will need the Security Group ID in a later step. Step 2 — Note the region and Security Group ID
  • Confirm the region shown in the console (example: Ohio, us-east-2).
  • Copy the created Security Group ID (for example, sg-07a079928389d2f42) for later use in the AWS Config rule and remediation parameters.
Screenshot of the AWS EC2 console showing a security group named ConfigSG (ID sg-07a079928389d2f42). A region selector overlay is open with Ohio (us-east-2) highlighted.
Step 3 — Ensure AWS Config recorder is enabled
  • Open AWS Config in the same region (us-east-2).
  • Under Settings, verify that the Recorder is enabled and that a Delivery Channel exists. AWS Config must be recording configuration changes for evaluation and remediation to work.
Ensure both the Recorder is ON and a Delivery Channel is configured so recorded configuration snapshots and notifications can be delivered. If the recorder was OFF when you created the security group, recreate or modify the security group after enabling the recorder so Config captures the resource state.
Step 4 — Add the managed AWS Config rule (Restricted SSH)
  • In AWS Config, navigate to Rules → Add rule.
  • Search for restricted and choose the managed rule restricted-ssh (may appear as “Restricted SSH” or restricted-ssh).
  • Give the rule a descriptive name such as ssh-security-restriction-operation. Leave other defaults unless you require a different scope or evaluation frequency.
A screenshot of the AWS Config "Add rule" page showing a rule named "ssh-security-restriction-operation" with a description stating it checks security groups to disallow unrestricted incoming SSH traffic.
Step 5 — Scope the rule to the specific security group
  • In the rule configuration Resources section, set the resource type to AWS::EC2::SecurityGroup.
  • Paste the Security Group ID you copied (e.g., sg-07a079928389d2f42) into the Resource Identifier field so the rule evaluates only that specific security group.
  • Keep the evaluation frequency at the default (e.g., 24 hours) or choose on-change if you need near real-time checks. Save the rule.
A screenshot of the AWS EC2 console showing details for a security group named "ConfigSG" (sg-07a079928389d2f42), including its owner, VPC ID and counts for inbound/outbound rules. The lower area shows tabs like Inbound rules, Outbound rules, Sharing and VPC associations.
A screenshot of the AWS Config "Add rule" page showing an AWS EC2 SecurityGroup selected with a resource identifier (sg-07a079928389d2f42) and the frequency set to 24 hours. The Parameters section is visible below.
Step 6 — Re-evaluate the rule to detect non-compliance
  • From AWS Config → Rules, select the rule you created.
  • Choose Actions → Re-evaluate to force an immediate evaluation.
  • After a short time the rule should evaluate the security group and mark it as NON-COMPLIANT because of the 0.0.0.0/0 SSH rule.
Tip: You can trigger a re-evaluation from the AWS CLI: aws configservice start-config-rules-evaluation --config-rule-names ssh-security-restriction-operation Step 7 — Configure automatic remediation
  • In the rule details, choose Actions → Manage remediation and select Automatic remediation.
  • For the remediation action, choose the Systems Manager Automation runbook AWS-DisablePublicAccessForSecurityGroup. This built-in runbook removes public access entries such as 0.0.0.0/0 from the specified security group.
  • In the Parameters section, set GroupId to the Security Group ID (for example, sg-07a079928389d2f42).
  • Provide an Automation assume role (the IAM role that SSM Automation will assume to make the changes). You will create this role in the next step.
A screenshot of the AWS Config "Manage remediation" page with a search box and a dropdown listing built-in remediation actions (e.g., AWS-DeleteEbsVolumeSnapshots, AWS-DeleteCloudFormationStack). The browser top bar shows the CloudWithDjango-Org AWS account in the web console.
Step 8 — Create an automation role (IAM)
  • In the IAM console, create a role for the AWS service Systems Manager. Choose the Systems Manager / Automation use case when creating the role.
  • Attach the AWS-managed policy AmazonSSMAutomationRole to provide baseline SSM Automation permissions.
  • For this demo, attach AmazonEC2FullAccess so the runbook can modify security groups. In production, replace this with a least-privilege policy that allows only the specific EC2 actions needed to modify security group rules.
  • Name the role clearly (for example, config-automatic-remediation-role) and create it.
  • Copy the role ARN and paste it into the remediation action’s Automation assume role field, then save the remediation configuration.
The demo uses AmazonEC2FullAccess for simplicity. In production, create and attach a narrowly scoped policy that grants only the required EC2 actions (for example, ec2:RevokeSecurityGroupIngress, ec2:AuthorizeSecurityGroupIngress) to follow the principle of least privilege.
After saving, the remediation action will be attached to the rule.
Screenshot of the AWS Config console showing the "ssh-security-restriction-operation" rule with a green success banner that it was updated. The page shows a Remediation action panel and the left navigation (Dashboard, Rules, Resources, Aggregators).
Step 9 — Trigger remediation and monitor Systems Manager Automation
  • With remediation configured, go back to the rule and choose Actions → Re-evaluate to re-run the compliance check.
  • If the security group is NON-COMPLIANT, AWS Config will start the Systems Manager Automation execution using the runbook AWS-DisablePublicAccessForSecurityGroup and the role you provided.
  • Open Systems Manager → Automation to view the execution history and details. The runbook execution should show as successful once it completes.
When the runbook finishes successfully, it removes public inbound rule(s) from the security group. The Automation execution history will show the execution ID and success details. Step 10 — Verify that the security group was remediated
  • Refresh the security group Inbound rules tab in the EC2 console. The public SSH rule (0.0.0.0/0 on port 22) should be removed — the security group may show no inbound rules or at least no unrestricted SSH rule.
  • Re-evaluate the Config rule one more time (Actions → Re-evaluate). After the automation completes, the rule should report the security group as COMPLIANT.
A screenshot of the AWS EC2 console showing a Security Group details page on the "Inbound rules" tab. It shows "No security group rules found" with options to "Edit inbound rules" and "Manage tags."
Conclusion You have configured AWS Config to detect an insecure security group and automatically remediate it with a Systems Manager Automation runbook. This end-to-end example shows how Config rules, remediation actions, and SSM Automation can be combined to automatically enforce and remediate security posture. Further reading and links

Watch Video