Skip to main content
emnode / learn
Compliance Low severity

AWS Security Hub · EC2

EC2.17: Instances with multiple ENIs can bridge network boundaries

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub EC2.17 check?

EC2.17 fails any EC2 instance whose NetworkInterfaces array has more than one ENI attached. The check is binary and intent-blind — it evaluates describe-instances every 12 hours and flags any instance with a second network interface, whatever the reason.

Why does EC2.17 matter?

The point of subnets and security groups is network segmentation, and a multi-ENI instance straddles segments: one process in the OS can read and write traffic on both networks, silently bypassing whatever isolation the VPC design intended. Most multi-ENI setups are historical hacks — NAT-instance patterns, inter-subnet bridges, MAC-pinned licensing — that modern AWS has cleaner answers for.

How do I fix EC2.17?

  1. Inventory every multi-ENI instance per region and classify what the second ENI is actually doing.
  2. Pick the right replacement: NAT Gateway for NAT-instance patterns, route tables or Transit Gateway for inter-subnet bridges, secondary private IPs on one ENI for virtual hosting, ENA-Express for bandwidth.
  3. Stand up the replacement first, repoint routing or config, then detach the secondary ENI in a maintenance window.
  4. Exempt genuine cases (Palo Alto, FortiGate firewalls, some HPC fabrics) with a documented Security Hub suppression.

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.17 a false positive?

Software firewalls, certain HPC cluster fabrics, and a few licensing arrangements legitimately require multiple ENIs. The control cannot tell these apart from an accidental second interface, so those instances need an explicit, documented exemption.

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.17 →
Part of the learning path Tighten your databases

More EC2 controls

  • 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