Running EC2 instances that AWS Systems Manager does not manage
What does ZopNight detect here?
ZopNight flags a running EC2 instance that is absent from the Systems Manager inventory returned by `ssm:DescribeInstanceInformation`. An unmanaged instance cannot be patched, inventoried or reached through Session Manager or Run Command, which pushes teams back to SSH keys and manual patching. The usual causes are a missing SSM Agent, instance role permissions or network path.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-154 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | not in Systems Manager inventory |
| Source | ZopNight |
| Permissions used | ec2:DescribeInstances · ssm:DescribeInstanceInformation |
Where it applies
What an instance outside Systems Manager misses
Systems Manager is how most AWS fleets are patched, inventoried and accessed without opening SSH. It only works on managed nodes: instances where the SSM Agent is running, has permissions, and can reach the service. An instance outside that list does not get Patch Manager baselines, does not show up in inventory, and cannot be reached with Session Manager, so someone keeps a key pair and a port 22 rule around for it.
Comparing EC2 instances with the managed node list
List what Systems Manager can see, with each node’s heartbeat status:
aws ssm describe-instance-information \ --query 'InstanceInformationList[].[InstanceId,PingStatus,AgentVersion]' --output tablePingStatus is Online, ConnectionLost or Inactive. Any running instance ID from
aws ec2 describe-instances --filters Name=instance-state-name,Values=running that is missing here is
unmanaged.
How managed status is decided
ZopNight asks Systems Manager for its managed instance list and treats an instance as managed when it appears there; it does not guess from tags or installed software. The rule fires when the instance is running and that lookup explicitly says it is not managed.
Instances the rule skips
Stopped instances are skipped. If the managed status was not collected for an instance, it is treated as unknown and no finding is raised.
Operational risk, no saving
The finding reports $0. The exposure is patch drift and standing SSH access, both of which tend to surface during audits or incidents rather than on a bill.
Bringing the instance under management
- Make sure the SSM Agent is installed and running. AWS preinstalls it on AMIs such as Amazon Linux 2 and Amazon Linux 2023, but warns that a preinstalled agent may not be running.
- Grant permissions: attach the
AmazonSSMManagedInstanceCorepolicy to the instance profile role, or turn on Default Host Management Configuration for the Region. - Give the instance a network path: interface VPC endpoints for Systems Manager, or outbound HTTPS
to the
ssm,ssmmessagesandec2messagesendpoints, per the VPC endpoint guide. - Confirm the instance appears as a managed node in Fleet Manager with
PingStatusOnline.