Dva účty AWS, jedna místní síť: kterou cestou?
Sdílený Transit Gateway, dvě nezávislé VPN nebo jeden úzký proxy: vybírejte podle vlastnictví a rozsahu dopadů, ne podle toho, která trasa se dnes přidává nejsnáze.
Zjevné zarámování je peering versus VPN, a to je špatné zarámování. Propojená VPC si nemůže vypůjčit VPN připojení souseda pro směrování od okraje k okraji, takže tato možnost nikdy nebyla ve hře, ať už směrovací tabulka naznačuje cokoli. Ve skutečnosti volíte mezi sdíleným síťovým hubem, dvěma nezávislými cestami VPN a úzkým vstupem pro aplikaci. Každá odpovídá na jinou otázku o tom, kdo vlastní směrování.
Tři možnosti a ta, která možností není
Začněte tím, že myšlenku peeringu škrtnete, a pak porovnejte, co zbývá, podle vlastnictví, ne podle jednoduchosti diagramu. Tabulka níže je rozhodnutí ve zhuštěné podobě.
| 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 |
Pokud účet A potřebuje dosáhnout na celou místní síť, řádek s proxy má špatný tvar. Pokud účet A potřebuje jedno API, první dva řádky jsou více sítě, než požadavek žádá.
Kdy vyhrává sdílený Transit Gateway
Transit Gateway připojuje každou VPC a VPN jako samostatné sítě, a sdílení mezi účty umožňuje vlastníkům VPC používat hub bez slučování účtů. To je přitažlivost: jedno místo, kde se místní prefixy potkávají se sítěmi AWS, a jedno místo pro úvahu o tom, které připojení se učí kterou trasu.
Připojit všechno neznamená povolit všechno. Asociace a propagace určují, které připojení používá kterou směrovací tabulku, takže dva prefixy VPC mohou každý dosáhnout na místní službu, zatímco jejich vzájemný přístup zůstává designem hubu vyloučen. Místní strana stále potřebuje zpětné trasy pro prefixy AWS, a to je změna pro jiný tým.
Náklad je organizační stejně jako finanční. Vlastník hubu řídí směrovací vztahy, na kterých závisí jiné týmy, takže změna jednoho připojení může přesunout provoz služby, o které vlastník hubu nikdy neslyšel. Hodiny připojení a zpracování dat se sčítají s každou sítí, kterou připojíte, a proto huby obvykle rostou rychleji než tým, který je provozuje.
Kdy vyhrávají samostatné VPN nebo úzký proxy
Dvě nezávislé VPN se hodí k malému nasazení se skutečnými provozními hranicemi: každý účet mění své tunely a ani jeden nemůže rozbít druhý úpravou směrovací tabulky. Limity jsou na místní straně. Partnerská brána potřebuje kapacitu pro další tunely, plány adres se nesmí překrývat a dvě konfigurace inzerující stejné prefixy potřebují záměrnou preferenci, ne naději.
Proxy je nejužší rozhraní. Pokud účet A potřebuje jednu databázi nebo jedno API v účtu B, omezený prostředník vám dá definovaný vstup s vlastním příběhem autentizace, protokolování a dostupnosti. Je to také možnost nejnáchylnější ke zneužití: prostředník, který předává na každé privátní místo určení, se stal neomezeným relé s kroky navíc a nebude se chovat jako průhledný přenos z VPC do místní sítě pro nic jiného.
Omezení peeringu VPC stojí za přečtení ještě před tímto vším, protože vysvětlují, proč se čtvrtý nápad stále vrací a proč nemůže fungovat.
Zvolte nejužší rozhraní, které splní požadavek
Seřaďte otázky: potřebuje A síť, soustavu sítí, nebo jedinou službu? Chce místní tým jednu cestu, nebo několik? Kdo smí měnit směrování pro provoz jiného týmu? První odpověď, která vytvoří nejužší rozhraní, je architektura, a vše po ní je implementace.
Zaznamenejte odpověď s plánem prefixů, vlastnictvím tras, inventářem tunelů nebo připojení a režimem selhání, který každá strana očekává. Když se někdo později zeptá, proč účet A nemůže jednoduše použít VPN účtu B, ten záznam je odpověď, a ušetří vám opakované řešení stejných tří možností u dalšího projektu.