Zrejmé zarámovanie je peering verzus VPN, a to je nesprávne zarámovanie. Prepájaná VPC si nemôže požičať VPN pripojenie suseda na smerovanie od okraja k okraju, takže táto možnosť nikdy nebola v hre, nech už smerovacia tabuľka naznačuje čokoľvek. V skutočnosti vyberáte medzi zdieľaným sieťovým hubom, dvoma nezávislými cestami VPN a úzkym vstupom pre aplikáciu. Každá odpovedá na inú otázku o tom, kto vlastní smerovanie.

Tri možnosti a tá, ktorá možnosťou nie je

Začnite tým, že myšlienku peeringu vyškrtnete, a potom porovnajte, čo zostáva, podľa vlastníctva, nie podľa jednoduchosti diagramu. Tabuľka nižšie je rozhodnutie v zhustenej podobe.

OptionWho owns the pathMain cost
Shared transit gatewayHub owner, used by both VPC ownersShared blast radius, attachment and data-processing charges
Separate VPNs per accountEach account independentlyPeer capacity, duplicated tunnels, overlapping prefixes to coordinate
Application proxyThe account that hosts the intermediaryNew auth, logging and availability surface, and only one service

Ak účet A potrebuje dosiahnuť celú miestnu sieť, riadok s proxy má nesprávny tvar. Ak účet A potrebuje jedno API, prvé dva riadky sú viac siete, než požiadavka žiada.

Kedy vyhráva zdieľaný Transit Gateway

Transit Gateway pripája každú VPC a VPN ako samostatné siete, a zdieľanie medzi účtami umožňuje vlastníkom VPC používať hub bez zlučovania účtov. To je príťažlivosť: jedno miesto, kde sa miestne prefixy stretávajú so sieťami AWS, a jedno miesto na úvahu o tom, ktoré pripojenie sa učí ktorú trasu.

Pripojiť všetko neznamená povoliť všetko. Asociácia a propagácia určujú, ktoré pripojenie používa ktorú smerovaciu tabuľku, takže dva prefixy VPC môžu každý dosiahnuť miestnu službu, zatiaľ čo ich vzájomný prístup zostáva vylúčený dizajnom hubu. Miestna strana stále potrebuje spätné trasy pre prefixy AWS, a to je zmena pre iný tím.

Náklad je organizačný rovnako ako finančný. Vlastník hubu riadi smerovacie vzťahy, na ktorých závisia iné tímy, takže zmena jedného pripojenia môže presunúť prevádzku služby, o ktorej vlastník hubu nikdy nepočul. Hodiny pripojenia a spracovanie dát sa sčítavajú s každou sieťou, ktorú pripojíte, a preto huby zvyčajne rastú rýchlejšie než tím, ktorý ich prevádzkuje.

Kedy vyhrávajú samostatné VPN alebo úzky proxy

Dve nezávislé VPN sa hodia k malému nasadeniu so skutočnými prevádzkovými hranicami: každý účet mení svoje vlastné tunely a ani jeden nemôže pokaziť druhý úpravou smerovacej tabuľky. Limity sú na miestnej strane. Partnerská brána potrebuje kapacitu pre ďalšie tunely, plány adries sa nesmú prekrývať a dve konfigurácie inzerujúce rovnaké prefixy potrebujú zámernú preferenciu, nie nádej.

Proxy je najúžšie rozhranie. Ak účet A potrebuje jednu databázu alebo jedno API v účte B, ohraničený sprostredkovateľ vám dá definovaný vstup s vlastným príbehom overovania, protokolovania a dostupnosti. Je to aj možnosť najnáchylnejšia na zneužitie: sprostredkovateľ, ktorý preposiela do každého súkromného cieľa, sa stal neobmedzeným relé s krokmi navyše a nebude sa správať ako priehľadný prenos z VPC do miestnej siete pre nič iné.

Obmedzenia peeringu VPC stoja za prečítanie ešte pred týmto všetkým, pretože vysvetľujú, prečo sa štvrtý nápad stále vracia a prečo nemôže fungovať.

Vyberte najúžšie rozhranie, ktoré spĺňa požiadavku

Zoraďte otázky: potrebuje A sieť, sústavu sietí alebo jedinú službu? Chce miestny tím jednu cestu alebo viacero? Kto smie meniť smerovanie prevádzky iného tímu? Prvá odpoveď, ktorá vytvorí najúžšie rozhranie, je architektúra, a všetko po nej je implementácia.

Zaznamenajte odpoveď s plánom prefixov, vlastníctvom trás, inventárom tunelov alebo pripojení a režimom zlyhania, ktorý každá strana očakáva. Keď sa niekto neskôr spýta, prečo účet A nemôže jednoducho použiť VPN účtu B, ten záznam je odpoveď a ušetrí vám opakované riešenie rovnakých troch možností pri ďalšom projekte.

Súvisiace články