Find VPCs with managed instances (describe-instance-information) but no SSM endpoints via describe-vpc-endpoints filtered on the trio's service names. Create all three endpoints in every AZ the VPC spans, so instances do not pay inter-AZ transfer reaching a single-AZ endpoint. Lock down the endpoint security group to allow 443 from the VPC CIDR only, and attach a scoped endpoint policy. Verify with describe-instance-information that managed instances stay connected, then bake the trio into the VPC IaC module.

Compliance Medium severity

AWS Security Hub · EC2

EC2.57: VPC is missing a Systems Manager endpoint

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub EC2.57 check?

EC2.57 fails any VPC that contains SSM-managed instances but does not expose interface endpoints for the Systems Manager trio: ssm, ssmmessages, and ec2messages. Creating all three is what AWS recommends and what the control expects, since the SSM agent uses each for a different function (though note that since SSM Agent 3.3.40.0 the agent prefers ssmmessages over ec2messages whenever it is available).

Why does EC2.57 matter?

Session Manager replaces SSH, Patch Manager replaces cron-driven updates, and Inventory replaces hand-rolled CMDB scripts, all driven by the agent phoning home. If any of the three endpoints is unreachable, parts of SSM silently break: sessions fail to connect, patch baselines do not apply, instances show "Connection lost." The alternative, routing SSM traffic through NAT to the internet, is both a cost hit and a security regression.

How do I fix EC2.57?

Find VPCs with managed instances (describe-instance-information) but no SSM endpoints via describe-vpc-endpoints filtered on the trio's service names.
Create all three endpoints in every AZ the VPC spans, so instances do not pay inter-AZ transfer reaching a single-AZ endpoint.
Lock down the endpoint security group to allow 443 from the VPC CIDR only, and attach a scoped endpoint policy.
Verify with describe-instance-information that managed instances stay connected, then bake the trio into the VPC IaC module.

Remediation script · bash

# Move the highest-impact case first: an RDS instance in a public subnet group.
aws rds create-db-subnet-group \
  --db-subnet-group-name prod-db-subnets-private \
  --db-subnet-group-description "Private subnets only - no IGW route" \
  --subnet-ids subnet-0aa11bb22cc33dd44 subnet-0ee55ff66aa77bb88

aws rds modify-db-instance \
  --db-instance-identifier prod-payments-db \
  --db-subnet-group-name prod-db-subnets-private \
  --apply-immediately

# Provide a private path before moving compute, so it can still reach AWS services.
# A free S3 gateway endpoint, or a narrow interface endpoint instead of a NAT gateway.
aws ec2 create-vpc-endpoint --vpc-id vpc-0a1b2c3d \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.us-east-1.ssm \
  --subnet-ids subnet-0aa11 subnet-0bb22 \
  --security-group-ids sg-0ccfn33 --private-dns-enabled

# Force Redshift bulk traffic through the VPC (confirm an S3 gateway endpoint exists first).
aws redshift modify-cluster \
  --cluster-identifier analytics-prod --enhanced-vpc-routing

Full walkthrough (console steps, edge cases and verification) in the lesson Move resources into private networks (VPC isolation).

Is EC2.57 a false positive?

The SSM agent is hard-coded to reach ssm/ssmmessages/ec2messages.<region>.amazonaws.com; there is no URL override. Enabling only one or two of the trio can pass a partial check while leaving Session Manager or Patch Manager broken, so provision all three with Private DNS on for the configuration AWS recommends. (Since SSM Agent 3.3.40.0 the agent prefers ssmmessages over ec2messages when it is available, so newer agents may keep working without the separate ec2messages endpoint, but the full trio is still the documented best practice.)

Full lesson Move resources into private networks (VPC isolation) Step-by-step remediation with CLI, code and persona-specific context.

AWS documentation for EC2 controls ↗ Check your own account for EC2.57 →

Part of the learning path Tighten your databases

EC2.1 An EBS snapshot is publicly restorable by any account
EC2.2 Default security groups still allow traffic
EC2.3 Attached EBS volumes are not encrypted at rest
EC2.4 Long-stopped instances are abandoned attack surface
EC2.6 No VPC flow logs, so there is no network audit trail
EC2.7 New EBS volumes are not encrypted by default
EC2.8 IMDSv1 lets an SSRF steal instance credentials
EC2.9 Instances are directly reachable on public IPv4
EC2.10 EC2 API traffic leaves the VPC over the internet
EC2.13 SSH (port 22) is open to the entire internet
EC2.14 RDP (port 3389) is open to the entire internet
EC2.15 Subnets auto-assign public IPs to new instances