SaaS ట్రాఫిక్‌ను సరైన కస్టమర్ VPNకి ఎలా రూట్ చేయాలి
ఒకదానిపై ఒకటి అతివ్యాప్తి చెందే కస్టమర్ సబ్‌నెట్‌లు పంచుకున్న రూటింగ్‌ను విచ్ఛిన్నం చేస్తాయి. ఐసొలేషన్ మోడల్‌ను ఎంచుకోండి, ప్రతి పనిని ధృవీకరించిన టెనెంట్‌కు కట్టండి మరియు ప్రారంభానికి ముందు టెనెంట్ల మధ్య మార్గాలను పరీక్షించండి.
ఒక SaaS ప్లాట్‌ఫారమ్ పన్నెండు కస్టమర్ నెట్‌వర్క్‌లకు కనెక్ట్ అవుతుంది, ఆ కస్టమర్‌లలో ఇద్దరు తమ ప్రాథమిక డేటాబేస్ కోసం 10.20.0.10 ఉపయోగిస్తారు. పనిలో ఆ చిరునామాను స్వీకరించే వర్కర్‌కు పని ఏ డేటాబేస్‌ను సూచిస్తుందో తెలుసుకోవడానికి మార్గం లేదు, పంచుకున్న రూటింగ్ పట్టిక ప్రిఫిక్స్ సూచించే సొరంగానికి దాన్ని సంతోషంగా పంపుతుంది. పరిష్కారం ఎక్కువ సొరంగాలు కాదు; పరిష్కారం టెనెంట్ గుర్తింపు మార్గంలో ఎక్కడ ప్రవేశిస్తుంది మరియు చిరునామా ప్రణాళికకు ఏ ఐసొలేషన్ మోడల్ అవసరమో నిర్ణయించడం. మూడు షరతులు ఈ ఎంపికను నిర్ణయిస్తాయి: కస్టమర్ ప్రిఫిక్స్‌లు అతివ్యాప్తి చెందుతాయా, పొరపాటు ఎంత దూరం వ్యాపించగలదు, మరియు కనెక్టర్‌ను ఎవరు నిర్వహిస్తారు.
రెండు కస్టమర్ డేటాబేస్‌లు, ఒక గమ్య చిరునామా
IP చిరునామా ఒక స్థానం, గుర్తింపు కాదు. అభ్యర్థన సర్వర్ ధృవీకరించిన టెనెంట్‌ను మోసుకెళ్లాలి, గమ్యం పరిష్కరించబడే ముందు ఆ టెనెంట్ నెట్‌వర్క్ సందర్భాన్ని ఎంచుకోవాలి.
అలా జరగనప్పుడు, వైఫల్యం నిశ్శబ్దంగా ఉంటుంది. కనెక్షన్ విజయవంతమవుతుంది, క్వెరీ నడుస్తుంది, మరియు రూటింగ్ పట్టికలో 10.20.0.10 కోసం ఒకే నమోదు ఉన్నందున సమాధానం తప్పు కస్టమర్ డేటాబేస్ నుండి వస్తుంది. DNS దీన్ని మరింత దిగజార్చుతుంది: టెనెంట్ A సందర్భంలో పరిష్కరించబడిన క్యాష్ చేసిన పేరును టెనెంట్ B కోసం నడుస్తున్న పని తిరిగి ఉపయోగించవచ్చు. ప్యాకెట్‌లో ఏదీ రెండింటినీ వేరు చేయదు, కాబట్టి ఏ పునఃప్రయత్న తర్కం దీన్ని సరిచేయదు.
మొదట ఐసొలేషన్ మోడల్‌ను నిర్ణయించండి
ఉత్పత్తులను పోల్చే ముందు మూడు షరతులను రాయండి. అతివ్యాప్తి ఒక చిరునామా స్థలాన్ని పంచుకోవచ్చా అని నిర్ణయిస్తుంది; ప్రభావ వ్యాసార్థం రూటింగ్ పొరపాటు సపోర్ట్ టికెట్ లేదా ఉల్లంఘన అని నిర్ణయిస్తుంది; కార్యాచరణ యాజమాన్యం ప్రతి టెనెంట్‌కు కనెక్టర్ సమూహాన్ని నిర్వహించగలరా అని నిర్ణయిస్తుంది.
| 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 |
ప్రిఫిక్స్‌లు భిన్నంగా ఉంటే మరియు విధానం నియంత్రిత హబ్‌ను అనుమతిస్తే, ప్రతి టెనెంట్‌కు రూటింగ్ పట్టికలతో ఒక Transit Gateway సాధ్యమవుతుంది. అటాచ్‌మెంట్ అసోసియేషన్ ఆ అటాచ్‌మెంట్ నుండి వచ్చే ట్రాఫిక్ కోసం ఉపయోగించే రూటింగ్ పట్టికను ఎంచుకుంటుంది, ప్రచారం పట్టికలో ఏ మార్గాలు కనిపిస్తాయో ఎంచుకుంటుంది. తన పట్టికతో మాత్రమే అనుబంధించబడి తన ప్రిఫిక్స్‌లను మాత్రమే ప్రచారం చేసే టెనెంట్ అటాచ్‌మెంట్ హబ్‌ను చేరుకుంటుంది, మరెక్కడా చేరుకోదు. అది రూటింగ్ నిర్ణయం, ఎవరూ పంచుకున్న పట్టికకు డిఫాల్ట్ మార్గాన్ని జోడించనంత వరకు అది సరిగ్గా ఉంటుంది.
ప్రిఫిక్స్‌లు అతివ్యాప్తి చెందితే, రూటింగ్ మాత్రమే వాటిని వేరు చేయలేదు. మీకు ప్రతి టెనెంట్‌కు ప్రత్యేక నెట్‌వర్క్ సందర్భం లేదా ప్రతి కస్టమర్ స్థలానికి స్పష్టమైన అర్థం ఇచ్చే అనువాద ప్రణాళిక అవసరం.
Transit Gateway ఐసొలేషన్ నిజంగా అర్థం ఏమిటి
అసోసియేషన్ మరియు ప్రచారం రెండు ముఖ్యమైన నియంత్రణలు, వాటిని గందరగోళపరచడం సులభం. అసోసియేషన్ ఈ అటాచ్‌మెంట్ ప్యాకెట్ ఏ పట్టికలో వెతకబడుతుందో సమాధానమిస్తుంది; ప్రచారం ఏ పట్టికలు ఈ అటాచ్‌మెంట్ మార్గాలను నేర్చుకుంటాయో సమాధానమిస్తుంది. ఐసొలేషన్ రెండింటినీ టెనెంట్-నిర్దిష్టంగా చేయడం ద్వారా వస్తుంది, ఎక్కువ అటాచ్‌మెంట్‌లు సృష్టించడం ద్వారా కాదు.
డిఫాల్ట్ అందరూ-అందరికీ సెటప్ సౌకర్యంగా ఉంటుంది మరియు అది ఐసొలేషన్ కాదు. ప్రత్యేక రూటింగ్ పట్టికలు కనెక్టివిటీని పరిమితం చేస్తాయి, కానీ ఒకే రూటింగ్ సందర్భంలో ఒక మార్పులేని గమ్య చిరునామాకు రెండు అర్థాలను ఇవ్వవు. అప్లికేషన్ టెనెంట్‌ను తెలుసుకునే ముందు 10.20.0.10ను పరిష్కరిస్తే, రూటింగ్ పొర అవసరమైన సమాచారాన్ని ఇప్పటికే కోల్పోయింది.
AWS 2026 అక్టోబర్ 23న Transit Gateway మరియు Cloud WAN కోసం అటాచ్‌మెంట్-స్థాయి 1:1 NATని జోడించింది, ఇది మద్దతు ఉన్న అటాచ్‌మెంట్‌లకు అతివ్యాప్తి సమాధానాన్ని మారుస్తుంది. Transit Gateway NAT పత్రం హోస్ట్ బిట్‌లను సంరక్షిస్తూ స్థిరమైన, స్థితిలేని, సమాన-ప్రిఫిక్స్ IPv4 మ్యాపింగ్‌లను వివరిస్తుంది. దాని చుట్టూ రూపకల్పన చేసే ముందు మద్దతు ఉన్న అటాచ్‌మెంట్ రకాలు మరియు ప్రాంతీయ పరిమితులను తనిఖీ చేయండి.
పనిని ధృవీకరించిన టెనెంట్‌కు కట్టండి
ప్రతి పని సర్వర్ ధృవీకరించిన టెనెంట్ గుర్తింపును మోసుకెళ్లాలి, ఆ గుర్తింపు నిర్వాహకుడి యాజమాన్యంలోని కనెక్షన్ రికార్డును ఎంచుకోవాలి. రికార్డు ఆమోదించిన నెట్‌వర్క్ సందర్భం, సేవా చిరునామా, ఆధారాల సూచన మరియు అక్కడ అనుమతించిన కార్యకలాపాలను పేర్కొంటుంది. నమ్మదగని అభ్యర్థన ఎప్పుడూ తన స్వంత VPN గుర్తింపుదారు, గేట్‌వే లేదా ప్రైవేట్ లక్ష్యాన్ని అందించకూడదు, ఎందుకంటే చెల్లుబాటు అయ్యే లాగిన్ ప్రతి కనెక్ట్ చేయబడిన కస్టమర్ చిరునామా స్థలాన్ని పరిశోధించడానికి అనుమతి కాదు.
వేరుచేసిన కనెక్టర్‌ల డిజైన్‌లో, టెనెంట్ A పని A-నిర్దిష్ట కనెక్టర్‌కు వెళ్తుంది, అది A యొక్క VPCలో నడుస్తుంది మరియు A యొక్క ఆమోదించిన వనరులను మాత్రమే చేరుకోగలదు. ఒకే హోస్ట్‌పై వేరు కంటైనర్‌లు ఆ విభజనను తామే సృష్టించవు; నెట్‌వర్క్ పేరు స్థలాలు, మార్గాలు మరియు నిష్క్రమణ విధానం దాన్ని అమలు చేయాలి. కనెక్టర్‌కు టెనెంట్-పరిమిత ఆధారాలు మరియు క్యూలు కూడా అవసరం, ఎందుకంటే ప్రైవేట్ మార్గం పంచుకున్న రహస్యాన్ని లేదా పంచుకున్న పని అంశాన్ని పరిమితం చేయదు. హోస్ట్‌కు బదులుగా టెనెంట్‌కు నెట్‌వర్క్ సందర్భం మరియు ఆధారాలు ఎంపిక చేయబడితే పూల్ చేసిన అప్లికేషన్ వర్కర్‌లు మంచివి.
ఆరోగ్య తనిఖీలు టెనెంట్ మరియు దశను పేర్కొనాలి: సొరంగం స్థాపించబడింది, మార్గం ఉంది మరియు నిజమైన సేవా అభ్యర్థన విజయవంతమైంది మూడు వేర్వేరు సంకేతాలు. నడుస్తున్న సొరంగాల మొత్తం సంఖ్య కనెక్టర్ పాడైన ఆ ఒక్క కస్టమర్‌ను దాచుతుంది.
విఫలం కావాల్సిన మార్గాలను పరీక్షించండి
ప్రారంభానికి ముందు మూడు పరీక్షలు నడపండి. అనుమతించిన A కార్యకలాపం విజయవంతం కావాలి, అనుమతించిన B కార్యకలాపం విజయవంతం కావాలి, ఉద్దేశపూర్వకంగా B కనెక్టర్ లేదా దాని అనువదించిన ఉపనామం వైపు మళ్లించిన A పని మూసివేసిన విధంగా విఫలం కావాలి. ఆపై ఒక సొరంగాన్ని విచ్ఛిన్నం చేసి, పని ఆ టెనెంట్‌కు మాత్రమే విఫలమవుతుందని, మరో కస్టమర్ యొక్క అదే-సంఖ్య సబ్‌నెట్‌కు పడకుండా నిర్ధారించండి. పునరుద్ధరణ కూడా పరీక్షించాలి, ఎందుకంటే పాత మార్గం లేదా క్యాష్ చేసిన ఆధారాలు అంతరాయం కంటే ఎక్కువ కాలం నిలవవచ్చు.
ఆర్కిటెక్చర్ వేరుచేసిన కనెక్టర్‌లతో పూల్ చేసిన వర్కర్‌లు లేదా పూర్తిగా వేరు చేయబడిన టెనెంట్ వనరులు కావచ్చు. మార్పులేని విషయం ఒకటే: ధృవీకరించిన టెనెంట్ సందర్భం మార్గాన్ని మరియు ఆధారాలను ఎంచుకుంటుంది, ఏ మార్గ మార్పు కూడా టెనెంట్ల మధ్య అప్లికేషన్ అనుమతిని ఎప్పుడూ ఇవ్వదు.