# Inactive VPC Peering Connection

> Peering connections in a dead terminal state (rejected by the accepter, expired after the 7-day acceptance window, or failed) hold no route and cost nothing, but their leftover records and stale route-table entries mislead anyone reading the network. ZopNight flags them for cleanup with an explicit $0 saving.

Source: https://zop.dev/integrations/aws/recommendations/inactive-vpc-peering-connection
Updated: 2026-08-19

---

## Dead connection records lie about your topology

A peering connection that was rejected or timed out is not connectivity. It is the fossil of
an attempt. But it still appears in listings, still gets counted when someone audits "what
can reach what", and any route-table entries created optimistically before acceptance now
point at a connection that will never carry a packet. The cleanup value is legibility: a
network whose object list matches its actual topology is one you can reason about during an
incident.

## Why the saving is genuinely zero

VPC peering [has no hourly charge](https://aws.amazon.com/vpc/pricing/); cost only arises as data transfer across an *active*
peering. A dead-state peering moves no data, so its cost is structurally $0 and deleting it
recovers $0. ZopNight files this as advisory rather than laundering it through a cost
category: the action is real (delete the record, remove stale routes), the dollar is
honestly nothing.

## What discovery considers "inactive"

The discoverer marks a peering inactive only for dead terminal states: rejected, expired,
failed. Active peerings and transitional states (pending acceptance, provisioning) never
fire; a connection mid-handshake is someone's work in progress, not debris. When the state
flag is absent the rule stays silent rather than guessing.

## List the debris directly

```bash
aws ec2 describe-vpc-peering-connections \
  --filters Name=status-code,Values=rejected,expired,failed \
  --query 'VpcPeeringConnections[].[VpcPeeringConnectionId,Status.Code,RequesterVpcInfo.VpcId,AccepterVpcInfo.VpcId]' \
  --output table
```

## Read the failure before deleting it

A rejected peering is also a message: the owner of the accepter VPC said no, or nobody
noticed the request during its 7-day acceptance window. If the connectivity is still wanted,
the fix is a fresh request (peering IDs cannot be revived) plus whatever conversation the
rejection implies, and overlapping CIDRs are the classic silent reason. If it is not wanted,
delete the connection and sweep both sides' route tables for entries referencing it, because
those stale routes are the part that eventually bites: they blackhole traffic if the same
CIDR is later reused by a different peer.