Audit every Client VPN endpoint across all regions and read ConnectionLogOptions.Enabled. Create or reuse a dedicated CloudWatch Logs group such as /aws/clientvpn/ and set an explicit retention policy. Run modify-client-vpn-endpoint with --connection-log-options Enabled=true,CloudwatchLogGroup= for each flagged endpoint; the change is non-disruptive. Bake ConnectionLogOptions into the Terraform/CloudFormation/CDK module so new endpoints ship with logging on.

Compliance Medium severity

AWS Security Hub · EC2

EC2.51: Client VPN endpoints should log connections

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub EC2.51 check?

EC2.51 fails any Client VPN endpoint whose ConnectionLogOptions.Enabled flag is false (the default when you create an endpoint and skip the logging settings). It is change-triggered, backed by the AWS Config rule ec2-client-vpn-connection-log-enabled, so a fix clears the finding almost immediately.

Why does EC2.51 matter?

A Client VPN endpoint is a remote-access door from the internet into your VPCs. Connection logging records who connected, when, from which source IP, and when they disconnected: the audit trail you need to answer "who was on the VPN when the breach happened?" Without it, that question has no answer, and NIST 800-53, NIST 800-171, and PCI DSS all treat remote-access logging as table stakes.

How do I fix EC2.51?

Audit every Client VPN endpoint across all regions and read ConnectionLogOptions.Enabled.
Create or reuse a dedicated CloudWatch Logs group such as /aws/clientvpn/<purpose> and set an explicit retention policy.
Run modify-client-vpn-endpoint with --connection-log-options Enabled=true,CloudwatchLogGroup=<group> for each flagged endpoint; the change is non-disruptive.
Bake ConnectionLogOptions into the Terraform/CloudFormation/CDK module so new endpoints ship with logging on.

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

Connection logging is distinct from VPC flow logs: it records session-level access events, not packet-level flow. Satisfying EC2.51 does not satisfy any flow-logging control, and having flow logs on the associated subnets does not satisfy EC2.51.

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.51 →

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