دو 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 کیوں استعمال نہیں کر سکتا، تو وہی ریکارڈ جواب ہے، اور اگلے منصوبے میں انہی تین آپشنز پر دوبارہ بحث کرنے سے یہ آپ کو بچاتا ہے۔