wtf( )unctionsystem design, drawn
← all problemsAWS SA ProHard

The spoke that borrowed the hub's circuit

The shared-services VPC holds the circuit to the corporate data centre and the NAT gateways. Four product VPCs are already peered to it and two more are funded this quarter; payments is the fifth, and it was peered the same way everybody else was.

The peering connection is active. Instances in each VPC can reach instances in the other. And the payments service cannot reach a single thing on the corporate network.

Place what actually gets the payments VPC to the corporate network. No second circuit may be ordered — the business has one, and it terminates in the hub.
Components — tap one, then tap a slot on the diagram
!Payments reconciliation runs against a mainframe in the data centre. It has never once connected, and the peering connection has been green the whole time.Peering works, and it works for exactly one thing: traffic between the two VPCs themselves. Every gateway on the far VPC's edge is unreachable from here.

Boundaries, outermost first: Shared services VPC: Shared services (reaches corp fine) Payments VPC: Payments service (reconciles nightly; FAILED: no route to corp) Outside every boundary: Direct Connect GW (outside every VPC), Corporate network (the mainframe), an empty slot for the what the payments VPC attaches to Connections: Corporate network calls Direct Connect GW — one circuit (step 1) Direct Connect GW calls Shared services (step 2) Payments service calls what the payments VPC attaches to (step 3) what the payments VPC attaches to calls Direct Connect GW — transit VIF (step 4) Payments service must NOT reach Corporate network — never across the peering

Payments servicereconciles nightlyno route to corp
Direct Connect GWoutside every VPC
Shared servicesreaches corp fine
Corporate networkthe mainframe