స్పష్టమైన చట్రం peering vs VPN, మరియు అది తప్పు చట్రం. పీర్ చేయబడిన VPC తన పొరుగువారి VPN కనెక్షన్ను అంచు నుండి అంచు వరకు రూటింగ్ కోసం అప్పుగా తీసుకోలేదు, కాబట్టి రూట్ పట్టిక ఏమి సూచించినా ఆ ఎంపిక ఎప్పుడూ మేజా మీద లేదు. మీరు వాస్తవానికి భాగస్వామ్య నెట్వర్క్ హబ్, రెండు స్వతంత్ర VPN మార్గాలు మరియు ఒక సన్నని అప్లికేషన్ ప్రవేశద్వారం మధ్య ఎంచుకుంటారు. ప్రతిదీ రూటింగ్ యాజమాన్యం ఎవరిది అనే వేరే ప్రశ్నకు సమాధానం ఇస్తుంది.

మూడు ఎంపికలు మరియు ఎంపిక కానిది

peering ఆలోచనను తుడిచివేసి ప్రారంభించండి, తర్వాత మిగిలిన దానిని రేఖాచిత్రం సరళత ఆధారంగా కాకుండా యాజమాన్యం ఆధారంగా పోల్చండి. క్రింది పట్టిక సంక్షిప్త రూపంలో నిర్ణయం.

OptionWho owns the pathMain cost
Shared transit gatewayHub owner, used by both VPC ownersShared blast radius, attachment and data-processing charges
Separate VPNs per accountEach account independentlyPeer capacity, duplicated tunnels, overlapping prefixes to coordinate
Application proxyThe account that hosts the intermediaryNew auth, logging and availability surface, and only one service

ఖాతా A మొత్తం స్థానిక నెట్వర్క్కు చేరుకోవాల్సి ఉంటే, ప్రాక్సీ వరుస తప్పు ఆకారంలో ఉంది. ఖాతా A కు ఒక API అవసరమైతే, మొదటి రెండు వరుసలు అవసరం అడిగిన దానికంటే ఎక్కువ నెట్వర్క్.

భాగస్వామ్య Transit Gateway ఎప్పుడు గెలుస్తుంది

Transit Gateway ప్రతి VPC మరియు VPNని వేర్వేరు నెట్వర్క్లుగా కలుపుతుంది, మరియు ఖాతాల మధ్య భాగస్వామ్యం VPC యజమానులను ఖాతాలను విలీనం చేయకుండా హబ్ను ఉపయోగించడానికి అనుమతిస్తుంది. అదే ఆకర్షణ: స్థానిక ప్రిఫిక్స్లు AWS నెట్వర్క్లను కలిసే ఒక ప్రదేశం, ఏ అటాచ్మెంట్ ఏ మార్గాన్ని నేర్చుకుంటుందో ఆలోచించడానికి ఒక ప్రదేశం.

అన్నింటినీ కలపడం అన్నింటికీ అనుమతి ఇవ్వడం కాదు. అసోసియేషన్ మరియు ప్రచారం ఏ అటాచ్మెంట్ ఏ రూట్ పట్టికను ఉపయోగిస్తుందో నిర్ణయిస్తాయి, కాబట్టి రెండు VPC ప్రిఫిక్స్లు ఒక్కొక్కటి స్థానిక సేవను చేరుకోగలవు, అయితే వాటి పరస్పర ప్రవేశం హబ్ రూపకల్పన ద్వారా బయట ఉంటుంది. స్థానిక వైపు ఇప్పటికీ AWS ప్రిఫిక్స్లకు తిరిగి వెళ్లే మార్గాలు అవసరం, మరియు అది మరొక బృందం మార్పు టికెట్.

ఖర్చు ఆర్థికంగానే సంస్థాగతంగా కూడా ఉంటుంది. హబ్ యజమాని ఇతర బృందాలు ఆధారపడే రూటింగ్ సంబంధాలను నియంత్రిస్తాడు, కాబట్టి ఒక అటాచ్మెంట్లో మార్పు హబ్ యజమాని ఎప్పుడూ వినని సేవ ట్రాఫిక్ను కదిలించగలదు. అటాచ్మెంట్ గంటలు మరియు డేటా ప్రాసెసింగ్ మీరు కలిపే ప్రతి నెట్వర్క్తో చేరుతాయి, అందుకే హబ్లు వాటిని నడిపే బృందం కంటే వేగంగా పెరుగుతాయి.

వేర్వేరు VPNలు లేదా సన్నని ప్రాక్సీ ఎప్పుడు గెలుస్తాయి

రెండు స్వతంత్ర VPNలు నిజమైన కార్యాచరణ సరిహద్దులతో కూడిన చిన్న విస్తరణకు సరిపోతాయి: ప్రతి ఖాతా తన సొంత సొరంగాలను మారుస్తుంది, ఏదీ రూట్ పట్టికను సవరించి మరొకదాన్ని పాడు చేయలేదు. పరిమితులు స్థానిక వైపున ఉన్నాయి. పీర్ గేట్వేకు అదనపు సొరంగాలకు సామర్థ్యం అవసరం, చిరునామా ప్రణాళికలు అతివ్యాప్తి చెందకూడదు, మరియు అదే ప్రిఫిక్స్లను ప్రకటించే రెండు కాన్ఫిగరేషన్లకు ఆశ కంటే ఉద్దేశపూర్వక ప్రాధాన్యత అవసరం.

ప్రాక్సీ అత్యంత సన్నని ఇంటర్ఫేస్. ఖాతా A కు ఖాతా B లో ఒక డేటాబేస్ లేదా ఒక API అవసరమైతే, పరిమిత మధ్యవర్తి మీకు దాని సొంత ప్రామాణీకరణ, లాగింగ్ మరియు లభ్యత కథతో నిర్వచించిన ప్రవేశాన్ని ఇస్తుంది. ఇది అత్యంత దుర్వినియోగానికి గురయ్యే ఎంపిక కూడా: ప్రతి ప్రైవేట్ గమ్యానికి ఫార్వర్డ్ చేసే మధ్యవర్తి అదనపు దశలతో అపరిమిత రిలేగా మారింది, మరియు మరేదైనా కోసం ఇది VPC నుండి స్థానిక నెట్వర్క్కు పారదర్శక మార్గంలా ప్రవర్తించదు.

ఇవన్నీ ముందు VPC peering పరిమితులను చదవడం విలువైనది, ఎందుకంటే నాల్గవ ఆలోచన ఎందుకు పదే పదే తిరిగి వస్తుంది మరియు ఎందుకు పని చేయలేదు అని అవి వివరిస్తాయి.

అవసరాన్ని తీర్చే అత్యంత సన్నని ఇంటర్ఫేస్ను ఎంచుకోండి

ప్రశ్నలను క్రమబద్ధీకరించండి: A కు ఒక నెట్వర్క్, నెట్వర్క్ల సమూహం లేదా ఒక సేవ అవసరమా? స్థానిక బృందం ఒక మార్గం కావాలా లేదా అనేకం? మరొక బృందం ట్రాఫిక్ కోసం రూటింగ్ ఎవరు మార్చగలరు? అత్యంత సన్నని ఇంటర్ఫేస్ను ఉత్పత్తి చేసే మొదటి సమాధానం నిర్మాణం, మరియు తర్వాత అంతా అమలు.

సమాధానాన్ని ప్రిఫిక్స్ ప్రణాళిక, మార్గాల యాజమాన్యం, సొరంగాలు లేదా అటాచ్మెంట్ల జాబితా మరియు ప్రతి వైపు ఆశించే వైఫల్య విధానంతో నమోదు చేయండి. తర్వాత ఎవరైనా ఖాతా A సరళంగా ఖాతా B VPNని ఎందుకు ఉపయోగించలేరు అని అడిగితే, ఆ నమోదే సమాధానం, మరియు తదుపరి ప్రాజెక్ట్లో అదే మూడు ఎంపికలపై మళ్లీ వాదించడాన్ని ఇది నివారిస్తుంది.

సంబంధిత వ్యాసాలు