Twee AWS-rekeninge, een netwerk op die perseel: watter pad?
Gedeelde Transit Gateway, twee onafhanklike VPN's of een smal proxy: kies volgens eienaarskap en die omvang van die skade, nie volgens watter roete vandag die maklikste is om by te voeg nie.
Die ooglopende raamwerk is peering teenoor VPN, en dit is die verkeerde raamwerk. 'n Gepende VPC kan nie sy buurman se VPN-verbinding vir roetering van rand tot rand leen nie, so daardie opsie was nooit op die tafel nie, maak nie saak wat 'n roetetabel voorstel nie. Waartussen jy eintlik kies, is 'n gedeelde netwerkhub, twee onafhanklike VPN-paaie en 'n smal toepassingstoegang. Elkeen beantwoord 'n ander vraag oor wie die roetering besit.
Drie opsies en die een wat nie 'n opsie is nie
Begin deur die peering-idee te skrap en vergelyk dan wat oorbly op eienaarskap eerder as op diagram-eenvoud. Die tabel hieronder is die besluit in saamgeperste vorm.
| 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 |
As rekening A bereikbaarheid na 'n hele netwerk op die perseel nodig het, is die proxy-ry die verkeerde vorm. As rekening A een API nodig het, is die eerste twee rye meer netwerk as wat die vereiste vra.
Wanneer die gedeelde Transit Gateway wen
'n Transit Gateway koppel elke VPC en die VPN as afsonderlike netwerke, en kruisrekening-deling laat die VPC-eienaars die hub gebruik sonder om rekeninge te smelt. Dit is die aantrekkingskrag: een plek waar die plaaslike adresvoorvoegsels die AWS-netwerke ontmoet, en een plek om te beredeneer watter aanhegsel watter roete leer.
Om alles aan te heg beteken nie dat alles toegelaat word nie. Assosiasie en propagasie bepaal watter aanhegsel watter roetetabel gebruik, so twee VPC-voorvoegsels kan elk 'n diens op die perseel bereik terwyl hul onderlinge toegang deur die hub se ontwerp uitgesluit bly. Die perseel-kant het steeds terugroetes vir die AWS-voorvoegsels nodig, en dit is 'n tweede span se veranderingsticket.
Die koste is organisatories sowel as finansieel. Die hub-eienaar beheer roeteringsverhoudings waarvan ander spanne afhanklik is, so 'n verandering in een aanhegsel kan verkeer vir 'n diens verskuif waarvan die hub-eienaar nog nooit gehoor het nie. Aanhegsel-ure en dataverwerking tel op met elke netwerk wat jy aanheg, en daarom groei hubs gewoonlik vinniger as die span wat hulle bestuur.
Wanneer afsonderlike VPN's of 'n smal proxy wen
Twee onafhanklike VPN's pas by 'n klein ontplooiing met werklike operasionele grense: elke rekening verander sy eie tonnels, en nie een kan die ander breek deur 'n roetetabel te wysig nie. Die beperkings lê aan die perseel-kant. Die eweknie-poort het kapasiteit vir die bykomende tonnels nodig, die adresplanne mag nie oorvleuel nie, en twee konfigurasies wat dieselfde voorvoegsels adverteer, het 'n doelbewuste voorkeur nodig eerder as hoop.
'n Proxy is die nouste koppelvlak. As rekening A een databasis of een API in rekening B nodig het, gee 'n beperkte tussenganger jou 'n gedefinieerde toegang met sy eie storie vir verifikasie, logboeke en beskikbaarheid. Dit is ook die opsie wat die maklikste misbruik word: 'n tussenganger wat na elke private bestemming deurstuur, het 'n onbeperkte aflos met ekstra stappe geword, en dit sal nie soos deursigtige VPC-tot-perseel-vervoer vir enigiets anders optree nie.
Die VPC-peering-beperkings is die moeite werd om te lees voor enige van dit, want hulle verduidelik waarom die vierde idee aanhou terugkom en waarom dit nie kan werk nie.
Kies die kleinste koppelvlak wat die vereiste bevredig
Orden die vrae: het A 'n netwerk, 'n stel netwerke of een diens nodig? Wil die perseel-span een pad of verskeie? Wie mag roetering vir die ander span se verkeer verander? Die eerste antwoord wat die kleinste koppelvlak oplewer, is die argitektuur, en alles daarna is implementering.
Teken die antwoord op saam met die voorvoegselplan, die roete-eienaarskap, die tonnel- of aanhegsel-inventaris en die foutmodus wat elke kant verwag. Wanneer iemand later vra waarom rekening A nie bloot rekening B se VPN kan gebruik nie, is daardie rekord die antwoord, en dit spaar jou daarvan om dieselfde drie opsies by die volgende projek weer te beredeneer.