Verify and troubleshoot AWS PrivateLink

Endpoint connection is Available

aws ec2 describe-vpc-endpoint-connections \
  --region <service-region> \
  --filters Name=service-id,Values=<your-service-id> \
  --query "VpcEndpointConnections[].[VpcEndpointId,VpcEndpointOwner,VpcEndpointState]" \
  --output table

Expect one row with owner 992382537093 (Revyl) and state available.

Targets are healthy in every zone

aws elbv2 describe-target-health \
  --target-group-arn <your-target-group-arn> \
  --query "TargetHealthDescriptions[].[Target.Id,Target.AvailabilityZone,TargetHealth.State]" \
  --output table

Every target should be healthy. With cross-zone load balancing on, one healthy target is enough for all zones.

Traffic is arriving at the NLB

In CloudWatch, under the AWS/NetworkELB namespace, watch NewFlowCount and ActiveFlowCount for your NLB while Revyl runs a check. On an NLB that only serves Revyl, a rise during the check means the PrivateLink leg works. On a shared NLB, your other clients keep these metrics busy, so they prove nothing about Revyl. Confirm Revyl's request in your target access logs at the time of the check instead. If your targets can parse it, proxy protocol v2 on the target group also works: its header carries the VPC endpoint ID. Targets that cannot parse proxy protocol reject every connection once it is on.

TCP_Target_Reset_Count or TCP_ELB_Reset_Count spikes point at your targets or listener.

A real job succeeds

Ask Revyl to run the connectivity check again, then run a build or test that depends on the private service. Successful dependency resolution or API calls confirm DNS, routing, and TLS all line up.