Cross-region VPC peering connections left in a rejected, expired or failed state
What does ZopNight detect here?
ZopNight flags a cross-region VPC peering connection whose status from `ec2:DescribeVpcPeeringConnections` is a dead state such as `rejected`, `expired` or `failed`. A dead connection carries no charge, so the finding is a $0 hygiene advisory: remove the routes that still point to it, since AWS does not allow deleting a connection in those states.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-163 |
| Category | advisory |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | peering not active |
| Source | ZopNight |
| Permissions used | ec2:DescribeVpcPeeringConnections · ec2:DescribeRouteTables |
Where it applies
Why dead peering connections are worth tidying
A VPC peering connection goes through a lifecycle: pending-acceptance, provisioning, active,
and several end states. The peering lifecycle page
describes requests that expire after 7 days if nobody accepts them, requests the accepter rejects, and
requests that fail. According to the
peering pricing page, there
is no charge to create a connection; data transfer is what costs money. A connection that never became
active moves no data, so it bills nothing, but it leaves confusing entries behind, and route tables
that reference it send traffic nowhere.
Finding inactive peering connections
Filter by status code in each Region you peer from:
aws ec2 describe-vpc-peering-connections \ --filters Name=status-code,Values=rejected,expired,failed \ --query 'VpcPeeringConnections[].[VpcPeeringConnectionId,Status.Code,RequesterVpcInfo.Region,AccepterVpcInfo.Region]' \ --output tableThen look for routes that still target a connection:
aws ec2 describe-route-tables \ --filters Name=route.vpc-peering-connection-id,Values=pcx-0123456789abcdef0 \ --query 'RouteTables[].RouteTableId'The inactive-state test
The rule reads whether ZopNight’s inventory marks the peering connection as inactive, meaning it
reached a dead state such as rejected, expired or failed rather than active. There is no metric
and no time window; the state alone decides it. The console link in the finding opens the Region the
connection was requested from.
Same-region peerings are out of scope
ZopNight only collects peering connections that cross Regions, because it uses them to draw cross-region links in its network view. An inactive peering between two VPCs in the same Region is therefore never flagged by this rule. Use the CLI filter above in each Region to catch those.
Nothing to save, something to tidy
The finding is fixed at $0 per month. Its value is fewer stale objects and no black-hole routes, not a lower bill.
Cleaning up after a dead peering connection
- Confirm whether the request was rejected or simply expired, and whether the two VPCs still need connectivity. If they do, create a fresh request instead.
- Delete stale routes that target the connection in both VPCs’ route tables.
- Do not try to delete the connection itself. AWS does not allow deleting a connection in the failed or rejected state, and no action can be taken on an expired one; AWS removes it from view on its own, after 2 hours for a failed request and after up to 2 days for expired or rejected ones.