To AWS-konti, ét lokalt netværk: hvilken vej?
Delt Transit Gateway, to uafhængige VPN'er eller én smal proxy: vælg efter ejerskab og skadesradius, ikke efter hvilken rute der er nemmest at tilføje i dag.
Den oplagte ramme er peering kontra VPN, og det er den forkerte ramme. En peered VPC kan ikke låne naboens VPN-forbindelse til ruting fra kant til kant, så den mulighed var aldrig på bordet, uanset hvad en rutetabel antyder. Det, du reelt vælger mellem, er et delt netværkshub, to uafhængige VPN-veje og en smal applikationsindgang. Hver af dem besvarer et forskelligt spørgsmål om, hvem der ejer rutingen.
Tre muligheder og den, der ikke er en mulighed
Begynd med at slette peering-ideen, og sammenlign derefter det, der er tilbage, ud fra ejerskab i stedet for diagramenkelhed. Tabellen nedenfor er beslutningen i komprimeret 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 skal kunne nå et helt lokalt netværk, er proxy-rækken den forkerte form. Hvis konto A skal bruge én API, er de to første rækker mere netværk, end kravet bad om.
Når det delte Transit Gateway vinder
Et Transit Gateway tilknytter hver VPC og VPN'en som separate netværk, og deling på tværs af konti lader VPC-ejerne bruge hubben uden at slå konti sammen. Det er tiltrækningen: ét sted, hvor de lokale præfikser møder AWS-netværkene, og ét sted at ræsonnere om, hvilken vedhæftning der lærer hvilken rute.
At vedhæfte alt betyder ikke at tillade alt. Tilknytning og udbredelse afgør, hvilken vedhæftning der bruger hvilken rutetabel, så to VPC-præfikser hver kan nå en lokal tjeneste, mens deres gensidige adgang forbliver udelukket af hubbens design. Den lokale side har stadig brug for returruter til AWS-præfikserne, og det er en ændring for et andet team.
Omkostningen er organisatorisk såvel som økonomisk. Hubbens ejer styrer ruterelationer, som andre teams er afhængige af, så en ændring i én vedhæftning kan flytte trafik for en tjeneste, som hubbens ejer aldrig har hørt om. Vedhæftningstimer og databehandling løber op med hvert netværk, du vedhæfter, og derfor vokser hubber ofte hurtigere end det team, der driver dem.
Når separate VPN'er eller en smal proxy vinder
To uafhængige VPN'er passer til en lille udrulning med reelle driftsgrænser: hver konto ændrer sine egne tunneller, og ingen af dem kan ødelægge den anden ved at redigere en rutetabel. Grænserne ligger på den lokale side. Peer-gatewayen har brug for kapacitet til de ekstra tunneller, adresseplanerne må ikke overlappe, og to konfigurationer, der annoncerer de samme præfikser, har brug for en bevidst præference i stedet for håb.
En proxy er den smalleste grænseflade. Hvis konto A skal bruge én database eller én API i konto B, giver en afgrænset mellemled en defineret indgang med sin egen historie for godkendelse, logning og tilgængelighed. Det er også den mulighed, der lettest misbruges: et mellemled, der videresender til enhver privat destination, er blevet et ureguleret relæ med ekstra trin, og det vil ikke opføre sig som gennemstrømning fra VPC til lokalt netværk for noget andet.
Det kan betale sig at læse VPC-peering-begrænsningerne før noget af dette, fordi de forklarer, hvorfor den fjerde idé bliver ved med at dukke op, og hvorfor den ikke kan virke.
Vælg den smalleste grænseflade, der opfylder kravet
Sæt spørgsmålene i rækkefølge: har A brug for et netværk, et sæt netværk eller én tjeneste? Vil det lokale team have én vej eller flere? Hvem må ændre ruting for det andet teams trafik? Det første svar, der giver den smalleste grænseflade, er arkitekturen, og alt derefter er implementering.
Skriv svaret ned sammen med præfiksplanen, ruteejerskabet, tunnel- eller vedhæftningsinventaret og den fejltilstand, hver side forventer. Når nogen senere spørger, hvorfor konto A ikke bare kan bruge konto B's VPN, er den registrering svaret, og den sparer dig for at genoptage de samme tre muligheder på det næste projekt.