حسابان على 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 يحتاج إلى قاعدة بيانات واحدة أو واجهة API واحدة في الحساب B، فإن وسيطًا محدد النطاق يمنحك مدخلًا معرّفًا بقصة المصادقة والتسجيل والتوافر الخاصة به. وهو أيضًا الخيار الأكثر عرضة لسوء الاستخدام: الوسيط الذي يمرر إلى كل وجهة خاصة أصبح مرحّلًا غير مقيد بخطوات إضافية، ولن يتصرف كعبور شفاف من VPC إلى الشبكة المحلية في أي شيء آخر.
يجدر قراءة قيود peering في VPC قبل كل هذا، لأنها تشرح لماذا تعود الفكرة الرابعة دائمًا ولماذا لا يمكن أن تنجح.
اختر أضيق واجهة تلبي المتطلبات
رتّب الأسئلة: هل يحتاج A إلى شبكة أو مجموعة شبكات أو خدمة واحدة؟ هل يريد الفريق المحلي مسارًا واحدًا أم عدة مسارات؟ من يُسمح له بتغيير توجيه حركة الفريق الآخر؟ أول إجابة تنتج أضيق واجهة هي المعمارية، وكل ما بعدها تنفيذ.
سجّل الإجابة مع خطة البادئات، وملكية المسارات، وجرد الأنفاق أو الارتباطات، ونمط الفشل الذي يتوقعه كل جانب. عندما يسأل أحدهم لاحقًا لماذا لا يمكن للحساب A استخدام VPN الخاص بالحساب B ببساطة، فإن ذلك السجل هو الإجابة، وهو يوفر عليك إعادة مناقشة الخيارات الثلاثة نفسها في المشروع التالي.