In the dynamic world of cloud infrastructure, security and compliance are paramount. One of the simplest, yet most critical, security mistakes is launching an EC2 instance from an unapproved or vulnerable Amazon Machine Image (AMI).
This not only introduces security risks (like unpatched software or misconfigurations) but also immediately causes compliance drift. The solution? Don’t just detect the drift — automatically terminate it using the power of AWS Config Rules and Systems Manager Automation.
This post walks through a robust, automated pattern to enforce your AMI governance policy in real-time.
The Problem: Unapproved AMIs are a Security Sinkhole
Every AMI used in your environment should be approved, patched, and hardened. When developers or tools bypass these approved golden images and launch instances using random public AMIs (or old, stale custom AMIs), they open the door to threats like:
- Known Vulnerabilities: Older AMIs likely lack critical patches.
- Malware/Backdoors: Unknown public AMIs can be compromised.
- Misconfiguration: Images may not adhere to your organizational security baseline.
Our goal is to create a safety net that catches these non-compliant launches instantly and performs an immediate, decisive action.
Step 1: The Detective Control — AWS Config Rule
The first line of defense is a detective control. Use an AWS Config rule to continuously evaluate every newly launched EC2 instance against a predefined standard.
🔎 The Key Config Rule: approved-amis-by-id
AWS provides managed rules for common checks. The rule used here is the approved-amis-by-id rule
- Define the Standard: You supply the Config rule with a list of approved AMI IDs for your Region (e.g., ami-12345, ami-54321).
- Continuous Evaluation: When a new EC2 instance is launched, the Config service checks the AMI ID against your approved list.
- Flag Non-Compliance: If the instance’s AMI ID is not on the approved list, the Config rule flags the resource’s compliance status as NON_COMPLIANT.
Here, I have mentioned “ami-0fa3fe0fa7920f68e” id as my approved AMI. You can pass your authentic AMI id’s in the parameters section
I launched an EC2 instance with AMI “ami-069e612f612be3a2b”
As expected, the config rule has marked this EC2 instance as non-compliant
Step 2: The Proactive Control — Automated Remediation
Detection alone is not enough; we need enforcement. We use AWS Systems Manager (SSM) Automation as the remediation engine linked directly to our Config rule.
🔨 Linking Config to Systems Manager
When setting up the approved-amis-by-id Config rule, you associate it with an SSM Automation Document. This document defines the steps to take when a resource becomes non-compliant.
- Define the Action: The simplest and most decisive action is aws:terminateinstances.
- Input Parameter: The Config rule provides the Non-Compliant Resource ID (the EC2 instance ID) as an input parameter to the SSM Automation document.
- Execution: Upon receiving the non-compliant signal, the SSM Automation Document executes the termination command against the offending EC2 instance.
Select “Manage Remediation” on the config rule
Choose “Automatic remediation” and optionally modify the values for retry attempts and time window
Many pre-built EC2 actions(SSM documents) are available. For this example, I opted for “Terminate EC2 instances” action. You can decide and choose the appropriate action you want to implement for non-compliant EC2 instances
Next, create a role with “Systems Manager” as the trusted entity and below permissions policy
Pass the ARN of the role created and save the configuration
You can wait for the auto-remediation to kick-in or if you want to test quickly in interest of time, click on “Remediate”
Non-Compliant EC2 instance has been terminated by the automated action
A Note on Time and Security
This automated termination occurs within minutes of the instance being launched and flagged. By immediately removing the non-compliant resource, you:
- Minimize the “blast radius” of a potential security vulnerability.
- Ensure compliance status is instantly restored.
- Provide immediate feedback to the developer or service that launched the non-compliant resource.
Best Practices for Deployment
To make this pattern effective and operationally safe, consider the following:
- Staging/Testing: Deploy this setup in a non-production (e.g., Development) environment in Monitor Mode first to test the detection accuracy before enabling automated remediation.
- Alerting and Notification: Configure Amazon SNS or AWS Chatbot to receive alerts whenever an instance is terminated by this automation. This provides necessary visibility and audit trails.
By pairing AWS Config for detection with Systems Manager for remediation, you move beyond mere auditing and establish a self-healing, compliant infrastructure that enforces security standards without human intervention.
Top comments (1)
I’ve been using SSM for governance as well—one challenge I keep running into is managing the cross-account visibility of these automated findings. Are you centralizing your Config aggregators and SSM automation in a dedicated Security Account, or keeping the logic local to the workload accounts?"