VPC peering connections stuck in rejected, expired, or failed states
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-163 |
| Category | advisory |
| Severity | low |
| Metric | none — pure configuration read |
| Source | vpc_peering_unused.go |
Where it applies
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; 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
aws ec2 describe-vpc-peering-connections \ --filters Name=status-code,Values=rejected,expired,failed \ --query 'VpcPeeringConnections[].[VpcPeeringConnectionId,Status.Code,RequesterVpcInfo.VpcId,AccepterVpcInfo.VpcId]' \ --output tableRead 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.