Två AWS-konton, ett lokalt nätverk: vilken väg?
Delad Transit Gateway, två oberoende VPN:er eller en smal proxy: välj efter ägande och skadans omfattning, inte efter vilken rutt som är lättast att lägga till i dag.
Den uppenbara ramen är peering kontra VPN, och det är den felaktiga ramen. En peerad VPC kan inte låna grannens VPN-anslutning för routning från kant till kant, så det alternativet var aldrig på bordet, oavsett vad en rutttabell föreslår. Det du faktiskt väljer mellan är ett delat nätverksnav, två oberoende VPN-vägar och en smal applikationsingång. Var och en besvarar en annan fråga om vem som äger routningen.
Tre alternativ och det som inte är ett alternativ
Börja med att stryka peering-idén och jämför sedan det som återstår efter ägande i stället för diagramenkelhet. Tabellen nedan är beslutet i komprimerad 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 |
Om konto A behöver nå ett helt lokalt nätverk har proxyraden fel form. Om konto A behöver ett enda API är de två första raderna mer nätverk än kravet bad om.
När den delade Transit Gateway vinner
En Transit Gateway kopplar varje VPC och VPN:en som separata nätverk, och delning mellan konton låter VPC-ägarna använda navet utan att slå ihop konton. Det är lockelsen: en plats där de lokala prefixen möter AWS-nätverken, och en plats att resonera om vilken bilaga som lär sig vilken rutt.
Att koppla allt betyder inte att tillåta allt. Association och spridning avgör vilken bilaga som använder vilken rutttabell, så två VPC-prefix kan var och en nå en lokal tjänst medan deras ömsesidiga åtkomst hålls utanför av navets design. Den lokala sidan behöver fortfarande returrutter för AWS-prefixen, och det är en ändring för ett annat team.
Kostnaden är organisatorisk likaväl som finansiell. Navets ägare styr routingrelationer som andra team är beroende av, så en ändring i en bilaga kan flytta trafik för en tjänst som navets ägare aldrig har hört talas om. Bilagstimmar och databehandling summerar med varje nätverk du kopplar, och därför växer nav ofta snabbare än teamet som driver dem.
När separata VPN:er eller en smal proxy vinner
Två oberoende VPN:er passar en liten driftsättning med verkliga operativa gränser: varje konto ändrar sina egna tunnlar, och ingen av dem kan förstöra den andra genom att redigera en rutttabell. Gränserna ligger på den lokala sidan. Peer-gatewayen behöver kapacitet för de extra tunnlarna, adressplanerna får inte överlappa, och två konfigurationer som annonserar samma prefix behöver en medveten preferens i stället för hopp.
En proxy är det smalaste gränssnittet. Om konto A behöver en databas eller ett API i konto B ger en avgränsad förmedlare en definierad ingång med sin egen historia för autentisering, loggning och tillgänglighet. Det är också alternativet som lättast missbrukas: en förmedlare som vidarebefordrar till varje privat destination har blivit ett oreglerat relä med extra steg, och det kommer inte att bete sig som transparent överföring från VPC till lokalt nätverk för något annat.
Det är värt att läsa VPC-peering-begränsningarna före allt detta, eftersom de förklarar varför den fjärde idén ständigt kommer tillbaka och varför den inte kan fungera.
Välj det smalaste gränssnitt som uppfyller kravet
Ordna frågorna: behöver A ett nätverk, en uppsättning nätverk eller en enda tjänst? Vill det lokala teamet ha en väg eller flera? Vem får ändra routningen för det andra teamets trafik? Det första svaret som ger det smalaste gränssnittet är arkitekturen, och allt därefter är implementering.
Skriv ned svaret tillsammans med prefixplanen, ruttägandet, inventariet över tunnlar eller bilagor och det feltillstånd som varje sida förväntar sig. När någon senare frågar varför konto A inte bara kan använda konto B:s VPN, är den dokumentationen svaret, och den sparar dig från att diskutera samma tre alternativ igen i nästa projekt.