Twee AWS-accounts, één lokaal netwerk: welk pad?

De voor de hand liggende framing is peering versus VPN, en het is de verkeerde framing. Een gepeerde VPC kan de VPN-verbinding van zijn buur niet lenen voor routing van rand tot rand, dus die optie lag nooit op tafel, wat een routetabel ook suggereert. Waar u werkelijk tussen kiest, is een gedeelde netwerkhub, twee onafhankelijke VPN-paden en één smalle applicatietoegang. Elk beantwoordt een andere vraag over wie het routeren bezit.

Drie opties en degene die geen optie is

Begin met het schrappen van het peering-idee en vergelijk daarna wat overblijft op eigendom in plaats van op diagrameenvoud. De tabel hieronder is de beslissing in samengevatte vorm.

Als account A bereikbaarheid naar een heel lokaal netwerk nodig heeft, heeft de proxy-rij de verkeerde vorm. Als account A één API nodig heeft, zijn de eerste twee rijen meer netwerk dan de eis vroeg.

Wanneer de gedeelde Transit Gateway wint

Een Transit Gateway koppelt elke VPC en de VPN als afzonderlijke netwerken, en delen tussen accounts laat de VPC-eigenaren de hub gebruiken zonder accounts samen te voegen. Dat is de aantrekkingskracht: één plek waar de lokale prefixen de AWS-netwerken ontmoeten, en één plek om te beredeneren welke koppeling welke route leert.

Alles koppelen betekent niet alles toestaan. Associatie en propagatie bepalen welke koppeling welke routetabel gebruikt, zodat twee VPC-prefixen elk een lokale dienst kunnen bereiken terwijl hun onderlinge toegang door het ontwerp van de hub uitgesloten blijft. De lokale kant heeft nog steeds retourroutes nodig voor de AWS-prefixen, en dat is een wijziging van een ander team.

De kosten zijn organisatorisch zowel als financieel. De eigenaar van de hub beheert routerelaties waarvan andere teams afhankelijk zijn, dus een wijziging aan één koppeling kan verkeer verplaatsen voor een dienst waarvan de hub-eigenaar nooit heeft gehoord. Koppelingsuren en gegevensverwerking tellen op bij elk netwerk dat u koppelt, en daarom groeien hubs meestal sneller dan het team dat ze beheert.

Wanneer aparte VPN's of een smalle proxy winnen

Twee onafhankelijke VPN's passen bij een kleine uitrol met echte operationele grenzen: elk account wijzigt zijn eigen tunnels, en geen van beide kan de andere breken door een routetabel te bewerken. De grenzen liggen aan de lokale kant. De peergateway heeft capaciteit nodig voor de extra tunnels, de adresplannen mogen niet overlappen, en twee configuraties die dezelfde prefixen adverteren hebben een bewuste voorkeur nodig in plaats van hoop.

Een proxy is de smalste interface. Als account A één database of één API in account B nodig heeft, geeft een afgebakende tussenpartij u een gedefinieerde ingang met zijn eigen verhaal voor authenticatie, logging en beschikbaarheid. Het is ook de optie die het makkelijkst wordt misbruikt: een tussenpartij die naar elke privébestemming doorstuurt, is een onbeperkt relais met extra stappen geworden, en het gedraagt zich voor niets anders als transparant verkeer van VPC naar lokaal netwerk.

Het loont de moeite om de beperkingen van VPC-peering te lezen vóór dit alles, want ze leggen uit waarom het vierde idee steeds terugkomt en waarom het niet kan werken.

Kies de smalste interface die aan de eis voldoet

Orden de vragen: heeft A een netwerk, een reeks netwerken of één dienst nodig? Wil het lokale team één pad of meerdere? Wie mag het routeren voor het verkeer van het andere team wijzigen? Het eerste antwoord dat de smalste interface oplevert, is de architectuur, en alles daarna is implementatie.

Leg het antwoord vast met het prefixplan, het route-eigendom, de inventaris van tunnels of koppelingen en de faalmodus die elke kant verwacht. Wanneer iemand later vraagt waarom account A niet gewoon de VPN van account B kan gebruiken, is die vastlegging het antwoord, en ze bespaart u dezelfde drie opties opnieuw te bediscussiëren in het volgende project.