To AWS-kontoar, eitt lokalt nettverk: kva veg?
Delt Transit Gateway, to uavhengige VPN-ar eller éin smal proxy: vel etter eigarskap og omfanget av skaden, ikkje etter kva rute som er lettast å leggje til i dag.
Den openberre ramma er peering mot VPN, og det er den gale ramma. Ein peera VPC kan ikkje låne VPN-tilkoplinga til naboen for rutting frå kant til kant, så det alternativet var aldri på bordet, kva ei rutetabell enn føreslår. Det du faktisk vel mellom, er ein delt nettverkshub, to uavhengige VPN-vegar og éin smal applikasjonsinngang. Kvar av dei svarar på eit anna spørsmål om kven som eig ruttinga.
Tre alternativ og det som ikkje er eit alternativ
Byrja med å slette peering-ideen, og samanlikn deretter det som står att etter eigarskap i staden for diagramsemje. Tabellen nedanfor er avgjerda 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 |
Viss konto A treng å nå eit heilt lokalt nettverk, er proxy-raden feil form. Viss konto A treng éin API, er dei to første radene meir nettverk enn kravet bad om.
Når den delte Transit Gateway vinn
Ein Transit Gateway knyter kvar VPC og VPN-en som separate nettverk, og deling på tvers av kontoar lèt VPC-eigarane bruke huben utan å slå saman kontoar. Det er appellen: ein stad der dei lokale prefiksa møter AWS-nettverka, og ein stad å resonnere om kva vedlegg som lærer kva rute.
Å knyte til alt tyder ikkje å tillate alt. Assosiasjon og propagasjon avgjer kva vedlegg som brukar kva rutetabell, så to VPC-prefiks kan kvar nå ei lokal teneste medan den gjensidige tilgangen deira held seg utanfor av designet til huben. Den lokale sida treng framleis returruter for AWS-prefiksa, og det er ei endring for eit anna team.
Kostnaden er organisatorisk så vel som økonomisk. Eigaren av huben styrer ruterelasjonar som andre team er avhengige av, så ei endring i eitt vedlegg kan flytte trafikk for ei teneste som eigaren av huben aldri har høyrt om. Vedleggstimar og databehandling summerer seg med kvart nettverk du knyter til, og difor veks hubar ofte fortare enn teamet som driv dei.
Når separate VPN-ar eller ein smal proxy vinn
To uavhengige VPN-ar passar til ein liten utrulling med reelle driftsgrenser: kvar konto endrar sine eigne tunnelar, og ingen av dei kan øydeleggje den andre ved å redigere ein rutetabell. Grensene ligg på den lokale sida. Peer-gatewayen treng kapasitet for dei ekstra tunnelane, adresseplanane må ikkje overlappe, og to konfigurasjonar som annonserer dei same prefiksa treng ei medviten preferanse i staden for håp.
Ein proxy er det smalaste grensesnittet. Viss konto A treng éin database eller éin API i konto B, gjev ein avgrensa mellomledd ein definert inngang med si eiga historie for autentisering, logging og tilgjenge. Det er òg alternativet som lettast vert misbrukt: ein mellomledd som videresender til kvar privat destinasjon har vorte eit uregulert relé med ekstra trinn, og det vil ikkje oppføre seg som gjennomsynleg overføring frå VPC til lokalt nettverk for noko anna.
Det er verdt å lese VPC-peering-avgrensingane før noko av dette, fordi dei forklarer kvifor den fjerde ideen stadig kjem attende og kvifor han ikkje kan fungere.
Vel det smalaste grensesnittet som oppfyller kravet
Set spørsmåla i rekkjefølgje: treng A eitt nettverk, eit sett med nettverk eller éi teneste? Vil det lokale teamet ha éin veg eller fleire? Kven har lov til å endre ruttinga for trafikken til det andre teamet? Det første svaret som gjev det smalaste grensesnittet, er arkitekturen, og alt etterpå er implementering.
Skriv ned svaret saman med prefiksplanen, ruteeigarskapet, tunnel- eller vedleggsinventaret og feiltilstanden kvar side ventar. Når nokon seinare spør kvifor konto A ikkje berre kan bruke VPN-en til konto B, er den registreringa svaret, og ho sparer deg for å diskutere dei same tre alternativa på nytt i neste prosjekt.