EC2.171: Site-to-site VPN tunnels are not logging

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub EC2.171 check?

EC2.171 fails any Site-to-Site VPN connection where one or both tunnels have LogOptions.CloudWatchLogOptions.LogEnabled set to false. Tunnel logging is opt-in and off by default, so the control fails on essentially every VPN created through the console without it.

Why does EC2.171 matter?

VPN tunnels carry your most sensitive cross-network traffic. Without logging you can tell that a tunnel went down but not why — phase 1 versus phase 2 failure, a pre-shared key mismatch, dead peer detection, a BGP state change. The per-tunnel session events shipped to CloudWatch Logs are the difference between knowing the tunnel dropped and diagnosing it in minutes.

How do I fix EC2.171?

Inventory every VPN connection per region with describe-vpn-connections and flag tunnels where LogEnabled is false.
Create one CloudWatch Logs group per region with a sensible retention (30 days is plenty for sparse VPN events).
Enable logging per tunnel with modify-vpn-tunnel-options — two calls per connection, one per tunnel outside IP.
Pair the logs with a CloudWatch alarm on the TunnelState metric so a flap pages the network team.

Remediation script · bash

# List every Site-to-Site VPN that currently has a tunnel DOWN.
aws ec2 describe-vpn-connections \
  --query 'VpnConnections[?VgwTelemetry[?Status==`DOWN`]].VpnConnectionId' --output text

# Lock a tunnel to IKEv2 only and turn logging on, one tunnel at a time.
aws ec2 modify-vpn-tunnel-options \
  --vpn-connection-id vpn-0a1b2c3d4e5f6a7b8 \
  --vpn-tunnel-outside-ip-address 203.0.113.20 \
  --tunnel-options '{"IKEVersions":[{"Value":"ikev2"}],"StartupAction":"start","LogOptions":{"CloudWatchLogOptions":{"LogEnabled":true,"LogGroupArn":"arn:aws:logs:us-east-1:111122223333:log-group:/aws/vpn/s2s","LogOutputFormat":"json"}}}'

# Turn on connection logging for a Client VPN endpoint.
aws ec2 modify-client-vpn-endpoint \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8 \
  --connection-log-options Enabled=true,CloudwatchLogGroup=/aws/clientvpn/prod-access

# Alarm on tunnel state (0 = down) so the next drop pages on-call, not the next scan.
aws cloudwatch put-metric-alarm --alarm-name vpn-tunnel2-down \
  --namespace AWS/VPN --metric-name TunnelState \
  --dimensions Name=VpnId,Value=vpn-0a1b2c3d4e5f6a7b8 Name=TunnelIpAddress,Value=203.0.113.20 \
  --statistic Minimum --period 300 --evaluation-periods 1 \
  --threshold 1 --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:network-oncall

Full walkthrough (console steps, edge cases and verification) in the lesson Secure Site-to-Site VPN connections.

Is EC2.171 a false positive?

The LogOptions setting lives on the tunnel, not the connection — leaving one of the two tunnels dark keeps the finding open. If you have locked the log group down with an explicit resource policy, you must also allow delivery.logs.amazonaws.com or events fail to land silently.

Full lesson Secure Site-to-Site VPN connections Step-by-step remediation with CLI, code and persona-specific context.

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

Part of the learning path Trim your network spend

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