Paano i-route ang SaaS traffic sa tamang customer VPN
Sinisira ng magkapatong na customer subnet ang shared routing. Pumili ng isolation model, iugnay ang bawat trabaho sa verified tenant, at subukan ang mga path sa pagitan ng mga tenant bago ilunsad.
Kumokonekta ang isang SaaS platform sa labindalawang customer network, at dalawa sa mga customer na iyon ay parehong gumagamit ng 10.20.0.10 para sa kanilang pangunahing database. Ang isang worker na tumatanggap ng address na iyon sa isang trabaho ay walang paraan para malaman kung aling database ang tinutukoy ng trabaho, at ang isang shared routing table ay masaya itong ipapadala sa tunnel na tinutukoy ng prefix. Ang solusyon ay hindi mas maraming tunnel; ito ay ang pagpapasya kung saan pumapasok ang tenant identity sa path at aling isolation model ang kailangan ng address plan. Tatlong kondisyon ang nagpapasya sa pagpili: kung nagkakapatong ang customer prefix, gaano kalayo maaaring kumalat ang isang pagkakamali, at sino ang nagpapatakbo ng connector.
Dalawang customer database, isang destinasyon address
Ang IP address ay isang lugar, hindi isang pagkakakilanlan. Kailangang dalhin ng request ang tenant na na-verify ng server, at kailangang piliin ng tenant na iyon ang network context bago ma-resolve ang destinasyon.
Kapag hindi ito nangyari, tahimik ang failure. Nagtagumpay ang koneksyon, tumatakbo ang query, at ang sagot ay nagmumula sa database ng maling customer dahil ang routing table ay may isang entry para sa 10.20.0.10. Mas pinapalala ito ng DNS: ang naka-cache na pangalan na na-resolve sa context ng tenant A ay maaaring muling gamitin ng trabahong tumatakbo para sa tenant B. Walang anumang bagay sa packet ang nagtatangi sa dalawa, kaya walang retry logic ang nakakapag-ayos nito.
Pagpasyahan muna ang isolation model
Isulat ang tatlong kondisyon bago ihambing ang mga produkto. Ang overlap ang nagpapasya kung maaaring ibahagi ang isang address space; ang blast radius ang nagpapasya kung ang routing mistake ay support ticket o breach; ang operational ownership ang nagpapasya kung kaya mong magpatakbo ng connector fleet bawat tenant.
| 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 |
Kung magkaiba ang prefix at pinapayagan ng policy ang isang controlled hub, ang isang Transit Gateway na may routing table bawat tenant ay posible. Pinipili ng attachment association ang routing table na ginagamit para sa traffic na pumapasok mula sa attachment na iyon, at pinipili ng propagation kung aling ruta ang lalabas sa isang table. Ang attachment ng tenant na nauugnay lamang sa sarili nitong table at nagpapalaganap lamang ng sarili nitong prefix ay umaabot sa hub at wala nang iba. Ito ay desisyon sa routing, at nananatili lamang itong tama hangga't walang nagdaragdag ng default route sa shared table.
Kung nagkakapatong ang prefix, hindi sila kayang paghiwalayin ng routing lamang. Kailangan mo ng natatanging network context bawat tenant o isang translation plan na nagbibigay ng malinaw na kahulugan sa espasyo ng bawat customer.
Ano talaga ang ibig sabihin ng Transit Gateway isolation
Ang association at propagation ang dalawang kontrol na mahalaga, at madaling pagkamlanin sila. Sinasagot ng association kung aling table hinahanap ang packet mula sa attachment na ito; sinasagot ng propagation kung aling table ang natututo ng ruta ng attachment na ito. Nagmumula ang isolation sa paggawa ng parehong tenant-specific, hindi sa paglikha ng mas maraming attachment.
Ang default na all-to-all setup ay maginhawa at hindi ito isolation. Nililimitahan ng magkahiwalay na routing table ang konektibidad, ngunit hindi nila binibigyan ng dalawang kahulugan ang isang hindi nagbabagong destinasyon address sa loob ng parehong routing context. Kung na-resolve ng application ang 10.20.0.10 bago nito malaman ang tenant, nawala na ng routing layer ang impormasyong kakailanganin nito.
Nagdagdag ang AWS noong Oktubre 23, 2026 ng attachment-level na 1:1 NAT para sa Transit Gateway at Cloud WAN, na nagbabago sa sagot sa overlap para sa mga sinusuportahang attachment. Inilalarawan ng dokumentasyon ng Transit Gateway NAT ang static, stateless, pantay-prefix na IPv4 mapping na pinapanatili ang host bits. Suriin ang mga sinusuportahang uri ng attachment at panrehiyong limitasyon bago magdisenyo sa paligid nito.
Iugnay ang trabaho sa verified tenant
Dapat dalhin ng bawat trabaho ang tenant identity na na-verify ng server, at dapat piliin ng identity na iyon ang connection record na pag-aari ng administrator. Binabanggit ng record ang aprubadong network context, address ng service, reference ng credentials, at mga operasyong pinapayagan doon. Ang hindi pinagkakatiwalaang request ay hindi dapat kailanman magbigay ng sarili nitong VPN identifier, gateway, o pribadong target, dahil ang valid na login ay hindi pahintulot na siyasatin ang address space ng bawat konektadong customer.
Sa disenyong may isolated connector, ang trabaho ng tenant A ay napupunta sa connector na partikular sa A na tumatakbo sa VPC ng A at maaabot lamang ang mga aprubadong resource ng A. Ang magkahiwalay na container sa isang host ay hindi naglikha ng paghihiwalay na iyon nang mag-isa; dapat ipatupad ito ng network namespace, ruta, at egress policy. Kailangan din ng connector ang tenant-scoped na credentials at queue, dahil ang pribadong ruta ay hindi naglilimita sa shared secret o shared work item. Ang pooled application worker ay maayos hangga't pinipili ang network context at credentials bawat tenant, hindi bawat host.
Dapat banggitin ng health check ang tenant at yugto: naitatag na tunnel, naroroon na ruta, at matagumpay na tunay na service request ay tatlong magkaibang signal. Itatago ng pinagsama-samang bilang ng tumatakbong tunnel ang nag-iisang customer na sira ang connector.
Subukan ang mga path na dapat mabigo
Magpatakbo ng tatlong test bago ilunsad. Dapat magtagumpay ang pinapayagang A operation, dapat magtagumpay ang pinapayagang B operation, at ang A job na sadyang nakaturo sa connector ng B o sa isinalin nitong alias ay dapat mabigo nang sarado. Pagkatapos ay sirain ang isang tunnel at kumpirmahing nabibigo ang trabaho para sa tenant na iyon lamang, nang hindi bumabalik sa subnet na may parehong numero ng ibang customer. Dapat subukan din ang restoration, dahil ang lumang ruta o naka-cache na credentials ay maaaring mabuhay nang mas matagal kaysa sa pagkaantala.
Ang arkitektura ay maaaring pooled worker na may isolated connector, o ganap na magkahiwalay na tenant resource. Ang invariant ay pareho: pinipili ng verified tenant context ang ruta at credentials, at walang pagbabago sa ruta ang nagbibigay kailanman ng application permission sa pagitan ng mga tenant.