Running EC2 instances absent from the SSM fleet inventory
What does ZopNight detect here?
AWS Systems Manager provides patching, session-based shell access without port 22, and inventory tracking at no extra charge for EC2. ZopNight asks the SSM control plane which instances it manages, then flags running instances missing from that inventory. The rule fires only on a confirmed absence, never when the check itself failed.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-154 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | ec2_ssm_managed.go |
Where it applies
Why an unmanaged instance is a liability
An instance outside Systems Manager is one you patch by hand, reach over SSH with long-lived keys, and inventory on a spreadsheet. Bringing it under SSM adds nothing to the AWS bill and replaces all three: Patch Manager for updates, Session Manager for shell access without opening port 22, Fleet Manager for inventory. In most fleets the unmanaged stragglers are the oldest boxes, which are also the ones most in need of patching.
Where the answer comes from
The signal is control-plane truth, not a guess from tags. Discovery calls Systems
Manager’s inventory API (the ssm:DescribeInstanceInformation read) and treats
presence in that inventory as managed. Each running instance is then stamped managed
or not, and the rule fires only on an explicit not-managed. If the SSM query itself
failed (throttled, denied), no stamp is written and the rule abstains, because “we
could not ask” is not the same as “the instance is missing”.
Reproduce the comparison
aws ssm describe-instance-information \ --query 'InstanceInformationList[].InstanceId' --output textaws ec2 describe-instances \ --filters Name=instance-state-name,Values=running \ --query 'Reservations[].Instances[].InstanceId' --output textAny ID in the second list but not the first is this finding.
The three usual causes
- No instance profile. The instance role lacks the AmazonSSMManagedInstanceCore policy. Most common by far.
- No agent. The SSM Agent is pre-installed on Amazon Linux and recent Ubuntu AMIs, but custom or old images may lack it.
- No network path. Private subnets need a NAT route or SSM VPC endpoints for the agent to phone home.
Work through them in that order; each fix becomes visible in Fleet Manager within minutes.
What the finding does not claim
No dollar value is attached: Session Manager, Patch Manager and inventory carry no additional charge for EC2 instances. Stopped instances are out of scope, since a stopped box cannot report to SSM anyway. And the rule says nothing about whether patching is actually current on the managed ones: presence in the inventory is the whole signal.