CONCEPT Cited by 1 source
Cross-VPC private connectivity¶
Cross-VPC private connectivity is the problem of giving an external system — another VPC, another account, another cloud, or an external SaaS — access to a resource that lives inside a private subnet of a customer VPC, without making the resource reachable from the public internet.
Why it's hard¶
Resources in a private VPC subnet have IP addresses drawn from the VPC's CIDR block. Those IPs are not routable from outside the VPC. Four standard answers:
- AWS Direct Connect — dedicated private circuit from the customer's network into the VPC. Expensive; long procurement; appropriate for persistent high-bandwidth links.
- VPN (IPsec / WireGuard) — software tunnel; faster to deploy than Direct Connect; bandwidth/latency constrained by the tunnel.
- VPC Peering / PrivateLink / Transit Gateway — works when the "external" system is another VPC in the same or connected AWS account. Does not solve the "external SaaS" case.
- Public ingress with defense-in-depth — expose a narrow public surface (single load balancer on static IPs) with layered security groups, and NAT the traffic internally to the private resource.
Option 4 is the pragmatic answer when the external caller is a managed SaaS that cannot peer into the customer VPC, and the customer doesn't want the expense of Direct Connect or the bandwidth constraints of VPN.
The NLB + NAT-router composition¶
The canonical option-4 architecture is:
- Public subnet NLB with static Elastic IPs — stable ingress addresses the external SaaS allowlists. See concepts/static-ip-allowlisting.
- Security-group chain — NLB allows the SaaS's CIDR only; NAT routers allow the NLB's SG only; private resource allows the routers' SG only. No tier is reachable from the broader internet.
- EC2 NAT routers in public subnets as NLB targets —
iptablesNAT rules forward traffic to the private-subnet target, with the NAT router insulating the external-facing IP from backend changes (e.g. Aurora failover). - Private-subnet target (database, internal service) reachable only via the NAT tier.
This composition is canonicalised as patterns/nat-router-for-static-ip-ingress.
Seen in¶
- sources/2026-04-21-aws-oldcastle-infor-aurora-quicksight-real-time-analytics — Oldcastle's ingress pattern from Infor Cloud ERP (external SaaS) to Aurora PostgreSQL (private VPC): "Because Infor can't reach our private VPC directly, we use Elastic Load Balancing (ELB) to distribute traffic and provide secure database access."