To AWS-kontoer, ett lokalt nettverk: hvilken vei?
Delt Transit Gateway, to uavhengige VPN-er eller én smal proxy: velg etter eierskap og skadens omfang, ikke etter hvilken rute som er lettest å legge til i dag.
Den åpenbare rammen er peering mot VPN, og det er den gale rammen. En peeret VPC kan ikke låne naboens VPN-tilkobling for ruting fra kant til kant, så det alternativet var aldri på bordet, uansett hva en rutetabell foreslår. Det du faktisk velger mellom, er en delt nettverkshub, to uavhengige VPN-veier og én smal applikasjonsinngang. Hver av dem svarer på et annet spørsmål om hvem som eier rutingen.
Tre alternativer og det som ikke er et alternativ
Begynn med å slette peering-ideen, og sammenlign deretter det som gjenstår etter eierskap i stedet for diagramenkelhet. Tabellen nedenfor er beslutningen i komprimert form.
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
Hvis konto A trenger å nå et helt lokalt nettverk, er proxy-raden feil form. Hvis konto A trenger én API, er de to første radene mer nettverk enn kravet ba om.
Når den delte Transit Gateway vinner
En Transit Gateway knytter hver VPC og VPN-en som separate nettverk, og deling på tvers av kontoer lar VPC-eierne bruke huben uten å slå sammen kontoer. Det er appellen: ett sted der de lokale prefiksene møter AWS-nettverkene, og ett sted å resonnere om hvilket vedlegg som lærer hvilken rute.
Å knytte til alt betyr ikke å tillate alt. Assosiasjon og propagasjon avgjør hvilket vedlegg som bruker hvilken rutetabell, så to VPC-prefikser kan hver nå en lokal tjeneste mens deres gjensidige tilgang holdes utenfor av hubens design. Den lokale siden trenger fortsatt returruter for AWS-prefiksene, og det er en endring for et annet team.
Kostnaden er organisatorisk så vel som økonomisk. Hubens eier styrer ruterelasjoner som andre team er avhengige av, så en endring i ett vedlegg kan flytte trafikk for en tjeneste som hubens eier aldri har hørt om. Vedleggstimer og databehandling summerer seg med hvert nettverk du knytter til, og derfor vokser huber ofte raskere enn teamet som driver dem.
Når separate VPN-er eller en smal proxy vinner
To uavhengige VPN-er passer til en liten utrulling med reelle driftsgrenser: hver konto endrer sine egne tunneler, og ingen av dem kan ødelegge den andre ved å redigere en rutetabell. Grensene ligger på den lokale siden. Peer-gatewayen trenger kapasitet for de ekstra tunnelene, adresseplanene må ikke overlappe, og to konfigurasjoner som annonserer de samme prefiksene trenger en bevisst preferanse i stedet for håp.
En proxy er det smaleste grensesnittet. Hvis konto A trenger én database eller én API i konto B, gir en avgrenset mellomledd en definert inngang med sin egen historie for autentisering, logging og tilgjengelighet. Det er også alternativet som lettest misbrukes: en mellomledd som videresender til hver privat destinasjon har blitt et uregulert relé med ekstra trinn, og det vil ikke oppføre seg som transparent overføring fra VPC til lokalt nettverk for noe annet.
Det er verdt å lese VPC-peering-begrensningene før noe av dette, fordi de forklarer hvorfor den fjerde ideen stadig kommer tilbake og hvorfor den ikke kan fungere.
Velg det smaleste grensesnittet som oppfyller kravet
Sett spørsmålene i rekkefølge: trenger A ett nettverk, et sett med nettverk eller én tjeneste? Vil det lokale teamet ha én vei eller flere? Hvem har lov til å endre rutingen for det andre teamets trafikk? Det første svaret som gir det smaleste grensesnittet, er arkitekturen, og alt etterpå er implementering.
Skriv ned svaret sammen med prefiksplanen, ruteeierskapet, tunnel- eller vedleggsinventaret og feiltilstanden hver side forventer. Når noen senere spør hvorfor konto A ikke bare kan bruke konto Bs VPN, er den registreringen svaret, og den sparer deg for å diskutere de samme tre alternativene på nytt i neste prosjekt.