Dvi AWS paskyros, vienas vietinis tinklas: kuriuo keliu?
Bendras Transit Gateway, du nepriklausomi VPN arba vienas siauras proxy: rinkitės pagal nuosavybę ir poveikio mastą, o ne pagal tai, kurį maršrutą šiandien lengviausia pridėti.
Akivaizdi formuluotė yra peering prieš VPN, ir tai yra neteisinga formuluotė. Susietos VPC negali pasiskolinti kaimynės VPN ryšio maršrutizavimui nuo krašto iki krašto, todėl ši galimybė niekada nebuvo svarstoma, kad ir ką siūlytų maršrutų lentelė. Iš tikrųjų renkatės tarp bendro tinklo hubo, dviejų nepriklausomų VPN kelių ir siauro programos įėjimo. Kiekvienas atsako į skirtingą klausimą apie tai, kam priklauso maršrutizavimas.
Trys variantai ir tas, kuris nėra variantas
Pradėkite ištrindami peering idėją, tada palyginkite tai, kas liko, pagal nuosavybę, o ne pagal diagramos paprastumą. Toliau pateikta lentelė yra sprendimas suspausta forma.
| 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 |
Jei paskyrai A reikia pasiekti visą vietinį tinklą, proxy eilutė yra netinkamos formos. Jei paskyrai A reikia vieno API, pirmos dvi eilutės yra daugiau tinklo, nei prašo reikalavimas.
Kada laimi bendras Transit Gateway
Transit Gateway prijungia kiekvieną VPC ir VPN kaip atskirus tinklus, o bendrinimas tarp paskyrų leidžia VPC savininkams naudotis hubu nesujungiant paskyrų. Tai ir traukia: viena vieta, kur vietiniai prefiksai susitinka su AWS tinklais, ir viena vieta pagalvoti, kuri jungtis išmoksta kurį maršrutą.
Prijungti viską nereiškia leisti viską. Asociacija ir propagacija nusprendžia, kuri jungtis naudoja kurią maršrutų lentelę, todėl du VPC prefiksai gali kiekvienas pasiekti vietinę paslaugą, o jų tarpusavio prieiga lieka neįtraukta dėl hubo dizaino. Vietinei pusei vis dar reikia grįžtamųjų maršrutų AWS prefiksams, ir tai yra kitos komandos pakeitimo užklausa.
Kaina yra tiek organizacinė, tiek finansinė. Hubo savininkas valdo maršrutizavimo ryšius, nuo kurių priklauso kitos komandos, todėl vienos jungties pakeitimas gali perkelti paslaugos, apie kurią hubo savininkas niekada negirdėjo, srautą. Jungties valandos ir duomenų apdorojimas susideda su kiekvienu prijungtu tinklu, todėl hubai paprastai auga greičiau nei juos valdanti komanda.
Kada laimi atskiri VPN arba siauras proxy
Du nepriklausomi VPN tinka nedideliam diegimui su tikromis operacinėmis ribomis: kiekviena paskyra keičia savo tunelius, ir nė viena negali sugadinti kitos redaguodama maršrutų lentelę. Ribos yra vietinėje pusėje. Poriniam šliuzui reikia talpos papildomiems tuneliams, adresų planai neturi persidengti, o dvi konfigūracijos, skelbiančios tuos pačius prefiksus, turi turėti sąmoningą pirmenybę, o ne viltį.
Proxy yra siauriausia sąsaja. Jei paskyrai A reikia vienos duomenų bazės arba vieno API paskyroje B, apribotas tarpininkas suteikia apibrėžtą įėjimą su savo autentifikavimo, registravimo ir prieinamumo istorija. Tai ir labiausiai piktnaudžiavimui linkusi parinktis: tarpininkas, persiunčiantis į kiekvieną privatų tikslą, tapo neribotu rele su papildomais žingsniais, ir jis neveiks kaip skaidrus perdavimas iš VPC į vietinį tinklą niekam kitam.
Verta perskaityti VPC peering apribojimus prieš visa tai, nes jie paaiškina, kodėl ketvirtoji idėja vis grįžta ir kodėl ji negali veikti.
Pasirinkite siauriausią sąsają, kuri atitinka reikalavimą
Surikiuokite klausimus: ar A reikia tinklo, tinklų rinkinio ar vienos paslaugos? Ar vietinei komandai reikia vieno kelio, ar kelių? Kas turi teisę keisti kitos komandos srauto maršrutizavimą? Pirmasis atsakymas, kuris duoda siauriausią sąsają, yra architektūra, o visa kita yra įgyvendinimas.
Užrašykite atsakymą su prefiksų planu, maršrutų nuosavybe, tunelių ar jungčių inventoriumi ir gedimo režimu, kurio laukia kiekviena pusė. Kai kas nors vėliau paklaus, kodėl paskyra A negali tiesiog naudoti paskyros B VPN, tas įrašas bus atsakymas, ir jis sutaupys jums laiko vėl svarstant tuos pačius tris variantus kitame projekte.