Du AWS-kontoj, unu loka reto: kiu vojo?
Komuna Transit Gateway, du sendependaj VPN-oj aŭ unu mallarĝa prokura: elektu laŭ posedo kaj amplekso de la efiko, ne laŭ tio, kiu vojo estas plej facile aldonebla hodiaŭ.
La evidenta kadro estas peering kontraŭ VPN, kaj ĝi estas la malĝusta kadro. Pairigita VPC ne povas prunti la VPN-konekton de sia najbaro por enkursigo de rando al rando, do tiu opcio neniam estis sur la tablo, kion ajn sugestas enkursiga tabelo. Tio, inter kio vi efektive elektas, estas komuna reta centro, du sendependaj VPN-vojoj kaj unu mallarĝa aplika enirejo. Ĉiu respondas al malsama demando pri tio, kiu posedas la enkursigon.
Tri opcioj kaj tiu, kiu ne estas opcio
Komencu per forigo de la ideo de peering, poste komparu tion, kio restas, laŭ posedo anstataŭ laŭ simpleco de la diagramo. La suba tabelo estas la decido en kunpremita formo.
| 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 |
Se konto A bezonas atingeblon al tuta loka reto, la vico de la prokura havas la malĝustan formon. Se konto A bezonas unu API, la du unuaj vicoj estas pli da reto ol la postulo petis.
Kiam gajnas la komuna Transit Gateway
Transit Gateway alligas ĉiun VPC kaj la VPN-on kiel apartajn retojn, kaj dividado inter kontoj ebligas al la posedantoj de VPC uzi la centron sen kunfandi kontojn. Tio estas la allogo: unu loko, kie la lokaj prefiksoj renkontas la retojn de AWS, kaj unu loko por pripensi, kiu alligaĵo lernas kiu vojon.
Alligi ĉion ne signifas permesi ĉion. Asocio kaj disvastigo decidas, kiu alligaĵo uzas kiu enkursigan tabelon, do du VPC-prefiksoj povas ĉiu atingi lokan servon dum ilia reciproka aliro restas ekskludita de la dezajno de la centro. La loka flanko ankoraŭ bezonas revenajn vojojn por la prefiksoj de AWS, kaj tio estas ŝanĝo de alia teamo.
La kosto estas organiza same kiel financa. La posedanto de la centro kontrolas enkursigajn rilatojn, de kiuj dependas aliaj teamoj, do ŝanĝo en unu alligaĵo povas movi trafikon por servo, pri kiu la posedanto de la centro neniam aŭdis. Alligaj horoj kaj datumprilaborado sumiĝas kun ĉiu reto, kiun vi alligas, kaj tial centroj kutime kreskas pli rapide ol la teamo, kiu administras ilin.
Kiam gajnas apartaj VPN-oj aŭ mallarĝa prokura
Du sendependaj VPN-oj taŭgas por malgranda deplojo kun realaj operaciaj limoj: ĉiu konto ŝanĝas siajn proprajn tunelojn, kaj neniu povas difekti la alian per redaktado de enkursiga tabelo. La limoj estas ĉe la loka flanko. La para pordego bezonas kapaciton por la pliaj tuneloj, la adresplanoj ne rajtas interkovriĝi, kaj du agordoj, kiuj anoncas la samajn prefiksojn, bezonas intencitan preferon anstataŭ esperon.
Prokura estas la plej mallarĝa interfaco. Se konto A bezonas unu datumbazon aŭ unu API en konto B, limigita peranto donas al vi difinitan enirejon kun sia propra historio de aŭtentigo, protokolado kaj havebleco. Ĝi ankaŭ estas la opcio plej verŝajne misuzota: peranto, kiu plusendas al ĉiu privata celloko, fariĝis senlima relajso kun pliaj paŝoj, kaj ĝi ne kondutos kiel travidebla trafiko de VPC al loka reto por io ajn alia.
Indas legi la limojn de VPC-peering antaŭ ĉio ĉi, ĉar ili klarigas, kial la kvara ideo ĉiam revenas kaj kial ĝi ne povas funkcii.
Elektu la plej mallarĝan interfacon, kiu plenumas la postulon
Ordigi la demandojn: ĉu A bezonas reton, aron da retoj aŭ unu servon? Ĉu la loka teamo volas unu vojon aŭ plurajn? Kiu rajtas ŝanĝi la enkursigon por la trafiko de la alia teamo? La unua respondo, kiu produktas la plej mallarĝan interfacon, estas la arkitekturo, kaj ĉio poste estas efektivigo.
Notu la respondon kun la prefiksa plano, la posedo de la vojoj, la inventaro de tuneloj aŭ alligaĵoj kaj la malsukcesa reĝimo, kiun ĉiu flanko atendas. Kiam iu poste demandas, kial konto A ne povas simple uzi la VPN-on de konto B, tiu rikordo estas la respondo, kaj ĝi ŝparas al vi rediskuti la samajn tri opciojn en la sekva projekto.