Hoe jou SaaS-ferkear nei de krekte klant-VPN
Oerlaapjende klantsubnetten brekke dielde routing. Kies in isolaasjemodel, bûn elke taak oan in ferifiearre hierder, en test krús-hierder-paden foar de lansearring.
In SaaS-platfoarm ferbynt him mei in dosyn klantnetwurken, en twa fan dy klanten brûke beide 10.20.0.10 foar har primêre databank. In worker dy't dat adres yn in taak krijt, hat gjin manier om te witten hokker databank de taak bedoelt, en in dielde routingtabel sil it mar wat graach nei de tunnel stjoere dêr't it foarheaksel nei wiist. De oplossing is net mear tunnels; it is beslute wêr't hierderidentiteit it paad ynkomt en hokker isolaasjemodel it adresplan nedich hat. Trije betingsten beslisje de kar: oft klantfoarheaksels oerlaapje, hoe fier in flater ferspriede kin, en wa't de connector betsjinnet.
Twa klantdatabanken, ien bestimmingsadres
In IP-adres is in lokaasje, gjin identiteit. It fersyk moat in hierder drage dy't de tsjinner ferifiearre hat, en dy hierder moat de netwurkkontekst kieze foardat de bestimming oplost wurdt.
As dat net bart, is de flater stil. De ferbining slagget, de query rint, en it antwurd komt út 'e databank fan 'e ferkearde klant, om't de routingtabel ien ynfier hie foar 10.20.0.10. DNS makket it slimmer: in kachearre namme dy't yn 'e kontekst fan hierder A oplost is, kin wer brûkt wurde troch in taak dy't foar hierder B rint. Neat yn it pakket ûnderskiedt de beide, dus gjin retry-logika reparearret it.
Beslis earst oer it isolaasjemodel
Skriuw de trije betingsten op foardat jo produkten fergelykje. Oerlaap beslisset oft ien adresromte hielendal dield wurde kin; de blast-radius beslisset oft in routingflater in stypkaart of in ynbreuk is; operasjoneel eigendom beslisset oft jo in connectorfloat per hierder betsjinje kinne.
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
As foarheaksels ferskille en it belied in kontrolearre hub tasteat, is ien Transit Gateway mei routingtabellen per hierder te dwaan. De oanhing-assoasjaasje kiest de routingtabel dy't brûkt wurdt foar ferkear dat fan dy oanhing ynkomt, en de propagaasje kiest hokker rûtes yn in tabel ferskine. In hierder-oanhing dy't allinnich oan syn eigen tabel keppele is en allinnich syn eigen foarheaksels propagearret, berikt de hub en neat oars. Dat is in routingbeslissing, en it bliuwt allinnich korrekt salang't nimmen in standertrûte oan 'e dielde tabel taheakket.
As foarheaksels oerlaapje, kin routing allinnich se net skiede. Jo hawwe of in aparte netwurkkontekst per hierder nedich, of in oersetplan dat de romte fan elke klant in ûndûbelsinnige betsjutting jout.
Wat Transit Gateway-isolaasje eins betsjut
Assoasjaasje en propagaasje binne de twa knoppen dy't fan belang binne, en se wurde maklik trochinoar helle. Assoasjaasje antwurdet yn hokker tabel in pakket fan dizze oanhing socht wurdt; propagaasje antwurdet hokker tabellen de rûtes fan dizze oanhing leare. Isolaasje komt fan it beiden hierder-spesifyk meitsjen, net fan it meitsjen fan mear oanhingen.
In standert all-to-all-opset is handich en is gjin isolaasje. Aparte routingtabellen beheine de ferbinings, mar se jouwe ien ûnferoare bestimmingsadres net twa betsjuttings binnen deselde routingkontekst. As de applikaasje 10.20.0.10 oplost foardat it de hierder ken, hat de routinglaach de ynformaasje dy't it nedich hie al ferlern.
AWS foege op 23 oktober 2026 oanhing-nivo 1:1 NAT ta foar Transit Gateway en Cloud WAN, wat it oerlaap-antwurd foar stipe oanhingen feroaret. De Transit Gateway NAT-dokumintaasje beskriuwt statyske, tastânleaze IPv4-mappings mei lyk foarheaksel en bewarre hostbits. Kontrolearje stipe oanhingtypen en regionale beheiningen foardat jo dêromhinne ûntwerpe.
Byn de taak oan in ferifiearre hierder
Elke taak moat in troch de tsjinner ferifiearre hierderidentiteit drage, en dy identiteit moat in troch de administrateur beheard ferbiningsrecord kieze. It record neamt de goedkarde netwurkkontekst, it tsjinstadres, de referinsje nei de credentials en de operaasjes dy't dêr tastean binne. In net-betrouber fersyk mei nea syn eigen VPN-identifikaasje, gateway of privee doel leverje, om't in jildige oanmelding gjin tastimming is om de adresromte fan elke ferbûne klant te ûndersykjen.
Yn in ûntwerp mei isolearre connectors giet it wurk fan hierder A nei in A-spesifike connector dy't yn 'e VPC fan A rint en allinnich de goedkarde boarnen fan A berikke kin. Aparte konteners op ien host meitsje dy skieding net fansels; de netwurk-nammeromten, rûtes en egress-belied moatte it ymplementearje. De connector hat ek hierder-beheinde credentials en wachtrijen nedich, om't in privee rûte in dield geheim of in dield wurkitem net beheint. Bondelje applikaasje-workers binne goed salang't de netwurkkontekst en credentials per hierder keazen wurde, net per host.
Sûnenschecken moatte de hierder en de faze neame: tunnel oprjochte, rûte oanwêzich en in echt tsjinstfersyk slagge binne trije ferskillende sinjalen. In gearfoege oantal tunnels dat oan is, sil de iene klant ferbergje waans connector brutsen is.
Test de paden dy't mislearje moatte
Fier trije tests út foar de lansearring. In tastiene A-operaasje moat slagje, in tastiene B-operaasje moat slagje, en in A-taak dy't bewust rjochte is op 'e connector fan B of syn oersette alias moat sletten mislearje. Breek dan ien tunnel en befêstigje dat de taak allinnich foar dy hierder mislearret, sûnder werom te fallen op it subnet mei itselde nûmer fan in oare klant. Restauraasje moat ek test wurde, om't in ferâldere rûte of kachearre credentials de útfal oerlibje kinne.
De arsjitektuer kin bondelje workers mei isolearre connectors wêze, of hielendal skieden hierderboarnen. De invariant is itselde: ferifiearre hierderkontekst kiest de rûte en de credentials, en gjin rûteferoaring jout ea applikaasje-tastimming tusken hierders.