دوه AWS حسابونه، یو ځایي شبکه: کومه لاره؟
شریک Transit Gateway، دوه خپلواک VPNونه یا یو تنګ پراکسي: د نن ورځې تر ټولو اسانه لارې پر ځای د مالکیت او اغیزې پر بنسټ انتخاب وکړئ۔
ښکاره چوکاټ peering د VPN په وړاندې دی، او دا غلط چوکاټ دی۔ پییر شوی VPC نشي کولی د خپل ګاونډي VPN اړیکه د څنډې څخه تر څنډې رونې لپاره پور واخلي، نو هغه انتخاب هیڅکله پر میز نه و، هر څه چې د لارې جدول وړاندیز کوي۔ هغه څه چې تاسو واقعاً ترمنځ یې انتخاب کوئ، یو شریک شبکه مرکز، دوه خپلواک VPN لارې او یو تنګ اپلیکیشن ننوتل دي۔ هر یو د دې په اړه بل پوښتنې ته ځواب وایي چې د لارې مالک څوک دی۔
درې انتخابونه او هغه چې انتخاب نه دی
د peering فکر له منځه وړلو سره پیل کړئ، بیا پاتې برخه د انځور سادګۍ پر ځای د مالکیت پر بنسټ پرتله کړئ۔ لاندې جدول په لنډه بڼه پریکړه ده۔
| 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 |
که حساب 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 وکاروي، هغه ثبت ځواب دی، او تاسو له دې څخه ژغوري چې په راتلونکي پروژه کې همدغه درې انتخابونه بیا بحث کړئ۔