Two VPCs in the same AWS Region have a VPC peering connection, but instances in one still cannot reach instances in the other. What has to be in place before a peering connection actually carries traffic?

## What a peering connection actually is A VPC peering connection is a networking link between exactly two VPCs, created inside the AWS network fabric rather than over the internet. There is no appliance, no gateway object in the data path, no bandwidth tier to pick and no hourly charge for the connection itself — you pay only for data transfer. Because there is no device, there is also nothing that "turns it on": the connection is a permission plus a routing target, and until you use that target nothing changes. ## Step 1 — request and accept One side creates the request (`CreateVpcPeeringConnection`), naming its own VPC and the peer VPC, which may be in another account or another Region. The connection sits in `pending-acceptance` until the owner of the other VPC accepts it. That acceptance is the authorization boundary: nobody can wire their VPC into yours unilaterally. In a single account you can request and accept in the same breath, which is why single-account examples make people think acceptance is the whole job. The request fails outright if the two VPCs' CIDR blocks overlap — including any secondary CIDRs. There is no NAT in peering, so overlapping address space has no answer; the fix is renumbering or a different pattern entirely, such as exposing a single service privately instead of joining whole networks. ## Step 2 — routes on both sides An accepted peering connection moves no packets by itself. In VPC A's route tables you add: ``` destination 10.1.0.0/16 -> target pcx-0123456789abcdef0 ``` and in VPC B's route tables the mirror image pointing at A's CIDR. "Both sides" is the part that trips people up, and its failure mode is distinctive: the SYN reaches the peer instance, the peer's reply hits a route table with no entry for the source range, and the caller sees a hang rather than a refusal. Remember also that a route table is attached to specific subnets — if only the subnets in one AZ use the route table you edited, only instances there can talk. ## Step 3 — security groups and NACLs Peered traffic is ordinary VPC traffic and is filtered normally. The inbound rule on the destination instance's security group has to allow the source range or, better, the source security group. Inside a single Region — including across accounts — a security group rule can reference a security group **in the peer VPC by ID**, which keeps you out of CIDR bookkeeping. Inter-Region peering does not support that reference, so there you fall back to CIDR-based rules. ## The DNS detail By default an instance in A resolving a private hostname belonging to B gets the public address, or nothing. Each side of the peering connection has a DNS-resolution option (`AllowDnsResolutionFromRemoteVpc`) that, when enabled, lets queries from the peer resolve to private IPs. The VPC itself must also have DNS support and DNS hostnames enabled. ## What peering deliberately does not do - It is not transitive: peering A–B and B–C does not let A reach C. - It does not give you the peer's internet path. You cannot route through a peering connection to reach the peer VPC's internet gateway, NAT gateway, VPN or Direct Connect connection, or its gateway endpoints. AWS calls this the edge-to-edge routing restriction. - It is not a trust boundary you can forget about: once routes exist, reachability is governed only by your security groups and NACLs. ## Checking it quickly The fastest triage order mirrors the setup order — is the connection `active`, does each side have a route for the other's CIDR in the route table associated with the right subnets, and do the security groups allow the port. VPC Reachability Analyzer will walk that path for you and name the hop that drops the packet, and flow logs will show `REJECT` when a security group or NACL is the culprit. ## What interviewers listen for They want to hear "routes on both sides" unprompted, and they want you to treat the accepted connection as necessary but not sufficient. Naming the overlapping-CIDR constraint and the peer-security-group reference marks you as someone who has actually built one.