EC2 Across Availability Zones: Check Routing Before a VPN

Before installing VPN software between two EC2 instances, answer one question: are they in the same VPC? If they are, the private path already exists and a cross-zone placement does not change that. Most of the work in this situation is confirming which route table each subnet actually uses, and then finding out whether the failure was ever a routing problem at all. A tunnel is usually the wrong answer to this particular question.

Check 1: same VPC or different VPCs

A VPC is regional and spans Availability Zones, while each subnet belongs to exactly one zone. Two instances in different zones of one VPC are still inside the same private routing domain.

Different VPCs never gain a private route because they share a region or a zone label. That case needs a supported connection and its own route and permission work, which is a separate decision.

Check 2: what the subnet route tables say

Write the layout down with real values. A VPC at 10.60.0.0/16 with subnets 10.60.1.0/24 and 10.60.2.0/24 gives instances 10.60.1.10 and 10.60.2.20 a path through the VPC's local route.

Then inspect the tables associated with both subnets rather than the one you found first. A more specific inspection or appliance route can override the baseline, and the local route's target can itself be replaced in newer configurations. A local route visible somewhere in the console does not prove both workloads use it.

Use the private addresses and names the VPC actually assigns. A private address does not have to start with 10, and inventing one from memory is how a working environment gets misdiagnosed.

Check 3: routing or authorization

Routing only gets the packet to the target's network interface. The target security group still needs to admit the source and the service, the source's egress rules have to allow the request, and any network ACL has to permit both directions because ACLs are stateless.

Beyond that sit the guest firewall, the listener binding and the application's own identity. Each can refuse a request that routing delivered perfectly.

Acceptance has to be the real application operation. A successful ping does not grant application access or prove a TLS name and credential are correct, and a blocked ping does not establish that every private service is down.

Check 4: is a separate connection actually required

A VPN can still belong in the design, but for a stated reason: connecting this VPC to an office, admitting laptops, or meeting an overlay requirement. That reason is different from ordinary same-VPC communication.

Also remember what the VPC is not. It is not an extension of a household Ethernet segment. An application that depends on broadcast discovery has a separate requirement to evaluate. That is a design gap rather than a routing bug.

Check 5: the encryption question

A private address and an allow rule say nothing about cryptographic protection at the application layer. If the data needs end-to-end protection, that comes from the protocol and identity model the service actually supports.

Keep network-layer and application-layer claims separate in the design note, because merging them is how a review ends up asserting protection nobody implemented.

What to record

Record both subnet ids, the route table associated with each, the security group references and the application operation you tested. That is four facts, and they settle most future arguments about this path.

Zone placement alone never tells you to add a VPN, and it never explains why a private request failed.