🎯 Connecting Networks — ربط الشبكات
نادراً ما تعمل التطبيقات السحابية في عزلة؛ فغالباً ما تحتاج إلى الاتصال بشبكات أخرى سواء داخل AWS أو في مراكز البيانات المحلية. يركز هذا المقال على ربط شبكات VPC باستخدام VPC Peering و Transit Gateway، بالإضافة إلى ربط الشبكات المحلية عبر Site-to-Site VPN و Direct Connect.
1️⃣ Connecting Networks in AWS — ربط الشبكات في AWS
الاختيار بين هذه الخدمات يعتمد على عدد VPCs المراد ربطها، عرض النطاق المطلوب، ومدى حاجتك للعزل والأمان.
- VPC Peering: ربط مباشر بين VPCs — بسيط لكن لا يتوسع جيداً مع كثرة VPCs.
- AWS Transit Gateway: محور مركزي يربط آلاف VPCs والشبكات المحلية — الحل المثالي للمؤسسات الكبيرة.
- VPC Endpoints & PrivateLink: ربط VPC بخدمات AWS أو خدمات الطرف الثالث عبر الشبكة الداخلية دون المرور بالإنترنت.
- Site-to-Site VPN: ربط مركز بياناتك المحلي بـ AWS عبر نفق VPN مشفر على الإنترنت العام.
- AWS Direct Connect: اتصال خاص مخصص بينك وبين AWS عبر شريك اتصالات — أعلى أداء وأقل زمن وصول.
- AWS Client VPN: وصول آمن للمستخدمين الأفراد إلى موارد AWS من أي مكان.
تستخدم Transit Gateway كمحور مركزي يربط كل VPCs الخمسة معاً.
تربط Transit Gateway بمراكز البيانات عبر Direct Connect بسرعة 10 جيجابت.
تربط أيضاً عبر Site-to-Site VPN كمسار احتياطي إذا تعطل Direct Connect.
النتيجة: أي مثيل في أي VPC يمكنه التواصل مع أي خادم محلي — والعكس — عبر شبكة موحدة وآمنة ومُدارة مركزياً.
- VPC Peering يربط VPCs باتصال مباشر 1:1 — بسيط لكن لا يتوسع جيداً.
- Transit Gateway محور مركزي يربط آلاف VPCs والشبكات المحلية.
- تصميم multi-VPC مع TGW يبسّط الإدارة ويقلل التعقيد.
- اختيار طريقة الربط يعتمد على عدد VPCs ومتطلبات الأداء.
VPC Peering مثل طريق مباشر بين مدينتين فقط — بسيط لكن لا يصلح لربط 10 مدن (ستحتاج 45 طريقاً).
Transit Gateway مثل دوار مروري ضخم: كل مدينة تتصل بالدوار مرة واحدة، ومنه تصل إلى أي مدينة أخرى — عدد الوصلات = عدد المدن فقط.
Site-to-Site VPN مثل نفق جبلي يربط مدينتك المحلية بعالم AWS — آمن لكنه يمر عبر تضاريس وعرة (الإنترنت العام).
Direct Connect مثل قطار فائق السرعة على سكة حديدية خاصة: الأسرع والأكثر موثوقية، لكنه الأغلى ثمناً.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| VPC Peering | تناظر VPC | اتصال مباشر 1:1 بين VPCs عبر شبكة AWS الداخلية. |
| Transit Gateway | بوابة العبور | محور مركزي يربط آلاف VPCs والشبكات المحلية معاً. |
| Transitive Routing | التوجيه المتعدي | قدرة الحزم على المرور عبر شبكة وسيطة للوصول لشبكة ثالثة. |
| CIDR Overlap | تداخل CIDR | لا يمكن توصيل VPCs ذات نطاقات عناوين متداخلة. |
| Direct Connect | الاتصال المباشر | اتصال خاص مخصص بينك وبين AWS عبر شريك اتصالات. |
1️⃣ VPC Peering — ربط VPCs
الاتصال يعتمد على بنية AWS التحتية الداخلية — لا يمر عبر الإنترنت العام ولا يستخدم بوابة أو VPN أو جهاز شبكة منفصل.
- اتصال 1:1 بين VPCs — إذا أردت ربط 3 VPCs، تحتاج 3 اتصالات Peering (وليس اتصالاً واحداً يربط الكل).
- لا يدعم التوجيه المتعدي (transitive routing): إذا كانت VPC A مرتبطة بـ B وB مرتبطة بـ C، لا يمكن لـ A التواصل مع C عبر B.
- يمكن أن يكون بين VPCs في نفس الحساب أو حسابات مختلفة، وفي نفس المنطقة أو مناطق مختلفة (cross-region).
- نطاقات CIDR يجب ألا تتداخل بين الـ VPCs المتصلة — وإلا لن يعرف الموجه إلى أين يرسل الحزمة.
- التواصل مشفر تلقائياً عبر البنية التحتية لـ AWS ولا يمر بالإنترنت العام.
تنشئ VPC Peering بينهما وتضيف مسارات في جداول التوجيه لكلا الطرفين.
الآن خوادم المراقبة في VPC الخدمات يمكنها الوصول إلى مثيلات التطبيقات في VPC التطبيقات عبر عناوينها الخاصة.
لا حاجة لبوابات NAT أو عناوين عامة — كل التواصل داخلي وآمن.
2️⃣ VPC Peering Limitations — قيود VPC Peering
بدون مسارات التوجيه، الاتصال موجود لكن الحزم لا تعرف كيف تصل إلى الطرف الآخر.
- الخطوة 1: أرسل طلب Peering من VPC المصدر إلى VPC الهدف (تحتاج معرف VPC الهدف ورقم الحساب إذا كان في حساب آخر).
- الخطوة 2: مالك VPC الهدف يقبل الطلب — الطلب يبقى معلقاً حتى القبول.
- الخطوة 3: أضف مسارات في جداول التوجيه في كلا VPCs: VPC A تضيف مساراً: CIDR_VPC_B → pcx-xxxx. VPC B تضيف مساراً: CIDR_VPC_A → pcx-xxxx.
- الخطوة 4 (اختياري): عدّل Security Groups للسماح بالاتصال من نطاق CIDR للـ VPC الآخر.
فريق التطبيقات (VPC A: 10.0.0.0/16) وفريق البيانات (VPC B: 10.1.0.0/16) يريدان تبادل البيانات.
يرسل فريق البيانات طلب Peering إلى حساب فريق التطبيقات.
يوافق فريق التطبيقات على الطلب — يُنشأ الاتصال.
كلا الفريقين يضيف مسارات التوجيه — فجأة، تطبيقات الفريق الأول يمكنها الكتابة مباشرة إلى قاعدة بيانات الفريق الثاني عبر اتصال خاص وآمن دون المرور بالإنترنت.
مثالي لربط عدد قليل من VPCs (2-5) عندما تحتاج اتصالاً بسيطاً وسريعاً.
لكن مع نمو عدد VPCs، يصبح Peering غير عملي (تحتاج اتصالاً لكل زوج — مع 10 VPCs تحتاج 45 اتصالاً!).
الحل الأفضل للمؤسسات: استخدم Transit Gateway.
1️⃣ تداخل CIDR: لا يمكن ربط VPCs ذات نطاقات عناوين IP متداخلة — يجب أن يكون لكل VPC نطاق CIDR فريد.
2️⃣ لا وصول لبوابات NAT أو Internet Gateway في VPC الأخرى: لا يمكن لمثيل في VPC A استخدام NAT Gateway أو Internet Gateway موجودة في VPC B للوصول إلى الإنترنت — كل VPC تحتاج بواباتها الخاصة.
3️⃣ المالك فقط يمكنه القبول: طلب VPC Peering بين حسابات مختلفة يجب أن يقبله مالك VPC الهدف — لا يمكن لجهة خارجية تفعيل الاتصال.
- VPC Peering هو اتصال مباشر 1:1 بين VPCs عبر شبكة AWS الداخلية.
- لا يدعم التوجيه المتعدي (transitive peering) — A مع B و B مع C لا يعني A مع C.
- يتطلب إضافة مسارات في جداول التوجيه لكلا الطرفين.
- مثالي لربط عدد قليل من VPCs — للربط على نطاق واسع استخدم Transit Gateway.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| VPC Peering | تناظر VPC | اتصال شبكي مباشر 1:1 بين VPCs عبر شبكة AWS الداخلية. |
| Cross-Account Peering | تناظر عبر الحسابات | اتصال Peering بين VPCs في حسابات AWS مختلفة. |
| Cross-Region Peering | تناظر عبر المناطق | اتصال Peering بين VPCs في مناطق AWS مختلفة. |
| Transitive Routing | التوجيه المتعدي | VPC Peering لا يدعمه — A متصلة بـ B و B بـ C لا يعني اتصال A بـ C. |
| CIDR Overlap | تداخل CIDR | لا يمكن إنشاء Peering بين VPCs ذات نطاقات عناوين متداخلة. |
1️⃣ AWS Transit Gateway — بوابة العبور
بدلاً من شبكة معقدة من اتصالات Peering الثنائية، كل VPC تتصل بـ Transit Gateway مرة واحدة فقط، وهو يتولى توجيه الحركة بين جميع الأطراف.
- قابلية التوسع: يربط حتى 5,000 VPC وآلاف اتصالات VPN من خلال محور واحد.
- التوجيه المركزي: جداول توجيه داخل Transit Gateway تتحكم بمن يمكنه التواصل مع من — VPC A ترى VPC B لكن لا ترى VPC C مثلاً.
- التوجيه المتعدي (Transitive): على عكس Peering، Transit Gateway يدعم التوجيه عبر أطراف متعددة — A → TGW → B → TGW → C ممكن.
- التكامل: يتصل بـ VPCs عبر attachments، وبالشبكات المحلية عبر VPN attachments، وبـ Direct Connect عبر Direct Connect Gateway.
- مشاركة عبر الحسابات: يمكن مشاركة Transit Gateway مع حسابات AWS الأخرى عبر AWS Resource Access Manager (RAM).
4 حسابات: إنتاج، تطوير، أمان، خدمات مشتركة — كل حساب له VPC واحدة على الأقل.
حساب الشبكات المركزي يستضيف Transit Gateway واحداً.
كل VPC في كل حساب تتصل بـ Transit Gateway عبر attachment مرة واحدة فقط.
جدول التوجيه في TGW مُهيأ بحيث: VPC الإنتاج ترى VPC الخدمات فقط، VPC التطوير ترى VPC الخدمات فقط، VPC الأمان ترى الجميع (للمراقبة).
النتيجة: تحكم مركزي كامل في التواصل بين البيئات دون تعقيد Peering.
2️⃣ Transit Gateway Route Tables — جداول توجيه TGW
يمكنك إنشاء جداول توجيه متعددة لإنشاء تجزئة شبكية (network segmentation) — بعض VPCs ترى بعضها والبعض الآخر لا يرى.
- نشر المسار (Route Propagation): يمكن لـ VPC نشر مساراتها تلقائياً إلى جداول توجيه TGW — لا حاجة لإضافة مسارات يدوية.
- المسارات الثابتة (Static Routes): تضيف مسارات يدوية عندما تحتاج تحكماً دقيقاً.
- جداول توجيه متعددة: أنشئ جدول توجيه لبيئة الإنتاج وآخر لبيئة التطوير — VPCs مرتبطة بجداول مختلفة لا ترى بعضها.
- الربط (Association): كل attachment يُربط بجدول توجيه واحد — المسارات في هذا الجدول تحدد إلى أين تذهب حزم attachment.
TGW بجدولي توجيه: جدول الإنتاج يحتوي على مسارات VPCs الإنتاج وVPN لمركز البيانات.
جدول الاختبار يحتوي على مسارات VPCs الاختبار فقط.
VPCs الإنتاج مرتبطة بجدول الإنتاج — لا ترى VPCs الاختبار.
VPCs الاختبار مرتبطة بجدول الاختبار — لا ترى VPCs الإنتاج.
النتيجة: عزل كامل بين البيئات مع استخدام TGW واحد فقط.
3️⃣ Advanced TGW Routing — أنماط التوجيه المتقدمة
هذه الإمكانيات المتقدمة تحول Transit Gateway من مجرد محور توجيه بسيط إلى منصة شبكات متكاملة للمؤسسات.
- التوجيه المركزي للحركة الخارجة (Centralized Outbound Routing): تصميم VPC مخصصة للخروج (Egress VPC) تحتوي على بوابات NAT تتعامل مع كل حركة الإنترنت من جميع VPCs الأخرى. VPC 1 توجه 0.0.0.0/0 → TGW. VPC الخروج توجه 0.0.0.0/0 → Internet Gateway. الفوائد: مراقبة وأمان مركزيان لحركة الإنترنت، توفير في التكلفة (عدد أقل من بوابات NAT)، وصول مركزي للخدمات المشتركة. للتكرار: شغّل NAT Gateway واحدة في كل منطقة توفر داخل VPC الخروج.
- تناظر Transit Gateway (TGW Peering): ربط Transit Gateways عبر المناطق والحسابات المختلفة. يستخدم جداول توجيه TGW للتحكم بالاتصال بين المناطق. يتيح بناء شبكة عالمية موحدة تمتد عبر عدة مناطق AWS دون الحاجة إلى اتصالات معقدة ونفقات إضافية على الإنترنت.
- سجلات تدفق TGW (TGW Flow Logs): التقاط معلومات حول حركة IP المتجهة من وإلى Transit Gateway — مشابهة لـ VPC Flow Logs لكن على مستوى المحور المركزي. تُنشر إلى S3 أو CloudWatch Logs للمراقبة المستمرة واستكشاف الأخطاء وإصلاحها وتحليل أنماط الحركة بين جميع الشبكات المتصلة.
بدلاً من نشر NAT Gateway في كل VPC (8 بوابات × ~32$ شهرياً لكل منطقة توفر = 256$ شهرياً على الأقل)، تنشئ VPC خروج واحدة (Egress VPC) بها NAT Gateway واحدة في كل AZ.
تُهيئ كل VPC إنتاجية مسار 0.0.0.0/0 متجهاً إلى Transit Gateway بدلاً من NAT Gateway المحلية.
VPC الخروج تستقبل هذه الحركة عبر TGW وتوجهها إلى NAT Gateway ثم Internet Gateway.
فريق الأمان يُركّز أدوات الفحص والمراقبة على VPC الخروج فقط — نقطة تفتيش واحدة بدلاً من 8.
النتيجة: حركة إنترنت جميع VPCs تمر عبر نقطة واحدة — مراقبة وتفتيش مركزيان + توفير أكثر من 200$ شهرياً من تكلفة بوابات NAT غير الضرورية.
تنشئ TGW Peering بين Transit Gateway أوروبا وTransit Gateway أمريكا.
تُهيئ جداول توجيه TGW في كلا الطرفين للسماح بمرور الحركة بين VPCs عبر المنطقتين — مع إمكانية تقييد مسارات محددة فقط.
النتيجة: تطبيق يعمل في VPC بلندن يمكنه التواصل مباشرة مع قاعدة بيانات في VPC بفرجينيا عبر اتصال خاص على بنية AWS التحتية — لا حاجة لبوابات إنترنت أو تشفير منفصل بين المناطق، وكأن الجميع في شبكة واحدة عالمية.
TGW Flow Logs تكشف: أي VPC ترسل أكبر حجم بيانات؟ هل هناك حركة مرفوضة تشير لمشكلة توجيه؟ هل هناك أنماط حركة غير متوقعة قد تشير لمحاولة اختراق؟
بدون Flow Logs أنت أعمى عن حركة البيانات داخل شبكتك — فهي أداة لا غنى عنها للمراقبة واستكشاف الأخطاء والامتثال التنظيمي.
4️⃣ TGW vs VPC Peering — Transit Gateway مقابل VPC Peering
| المعيار | VPC Peering | Transit Gateway |
|---|---|---|
| التوسع | حتى ~125 اتصالاً لكل VPC (حد نظري مرتفع لكنه يصبح معقداً بسرعة) | حتى 5,000 VPC |
| التوجيه المتعدي | غير مدعوم | مدعوم |
| عدد الوصلات | اتصال لكل زوج — مع N VPCs: (N*(N-1))/2 | اتصال واحد لكل VPC — مع N VPCs: N |
| التكلفة | مجاني لنقل البيانات داخل نفس AZ | رسوم شهرية لكل attachment + رسوم لكل جيجابايت |
| Jitter/Zمن الوصول | أقل — اتصال مباشر | أعلى بقليل — يمر عبر محور مركزي |
| الإدارة | لامركزية (كل اتصال مستقل) | مركزية (كل شيء من مكان واحد) |
| مناسب لـ | عدد قليل من VPCs | المؤسسات الكبيرة ومتعددة الحسابات |
1️⃣ قابلية التوسع: يربط حتى 5,000 VPC وآلاف اتصالات VPN عبر محور واحد — نمو غير محدود.
2️⃣ التوجيه المتعدي: يدعم مرور الحزم عبر شبكات وسيطة (A → TGW → B → TGW → C) — على عكس VPC Peering.
3️⃣ الإدارة المركزية: جداول توجيه TGW تتحكم بجميع الاتصالات من مكان واحد — لا حاجة لإدارة عشرات اتصالات Peering المنفصلة.
4️⃣ تحسين التكلفة: على الرغم من وجود رسوم شهرية، إلا أن التوفير الإداري وتجنب تعقيد Peering يجعله أرخص على المدى الطويل.
5️⃣ المشاركة عبر الحسابات: يمكن مشاركة TGW مع حسابات AWS الأخرى عبر AWS RAM — مثالي لبيئات multi-account.
- TGW محور مركزي يربط آلاف VPCs والشبكات المحلية عبر attachment واحد لكل شبكة.
- يدعم التوجيه المتعدي — A ← TGW ← B ← TGW ← C ممكن.
- جداول توجيه TGW توفّر تحكماً مركزياً وعزل البيئات.
- TGW Peering يربط Transit Gateways عبر المناطق لشبكة عالمية موحدة.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| TGW Attachment | مرفق TGW | اتصال بين VPC أو VPN أو Direct Connect و Transit Gateway. |
| TGW Route Table | جدول توجيه TGW | يتحكم بمسارات الحركة بين المرفقات المختلفة داخل TGW. |
| TGW Peering | تناظر TGW | ربط Transit Gateways عبر المناطق لبناء شبكة عالمية موحدة. |
| Route Propagation | نشر المسار | نشر تلقائي لمسارات VPC إلى جداول توجيه TGW دون إضافة يدوية. |
| Centralized Outbound | التوجيه المركزي للخروج | توجيه حركة جميع VPCs للإنترنت عبر Egress VPC واحدة للتحكم المركزي. |
1️⃣ VPC Endpoints and PrivateLink — نقاط نهاية VPC والرابط الخاص
بدلاً من توجيه الطلبات إلى نقاط النهاية العامة لخدمات AWS عبر NAT Gateway والإنترنت، تتصل مباشرة عبر واجهة داخلية في VPC.
- Gateway Endpoint: يستهدف S3 وDynamoDB فقط — يُضاف كمسار في جدول التوجيه (وليس كواجهة شبكة). مجاني ولا يستخدم NAT Gateway. يعمل عبر إضافة بادئة (prefix list) كهدف في جدول التوجيه.
- Interface Endpoint: يستهدف معظم خدمات AWS الأخرى (والخدمات الخاصة عبر PrivateLink) — ينشئ واجهة شبكة (ENI) بعنوان IP خاص في شبكتك الفرعية. يتكلف رسوماً شهرية + لكل جيجابايت.
للـ S3 وDynamoDB: ينشئ Gateway Endpoints — مسار في جدول التوجيه فقط، لا تكلفة إضافية، والطلبات تذهب عبر شبكة AWS الداخلية.
لـ CloudWatch Logs: لا يدعم Gateway Endpoint، فينشئ Interface Endpoint — واجهة شبكة بعنوان IP 10.0.10.50 في الشبكة الفرعية للتطبيق.
النتيجة: كل تواصل التطبيق مع خدمات AWS يتم عبر الشبكة الداخلية — لا حاجة لـ NAT Gateway لهذه الخدمات، أمان أعلى، وتكلفة أقل.
2️⃣ AWS PrivateLink — الرابط الخاص
الخدمة تُعرض من VPC المزود عبر Network Load Balancer أمام الخدمة، والعميل ينشئ Interface Endpoint في VPC خاصته للاتصال بها.
- جهة المزود: ينشئ خدمة VPC Endpoint Service ويربطها بـ Network Load Balancer أمام تطبيقه — الخدمة تُعرض عبر البنية الداخلية لـ AWS.
- جهة العميل: ينشئ Interface Endpoint في VPC خاصته ويحدد اسم خدمة المزود — يُنشأ اتصال خاص بينهما.
- العميل يدفع رسوم Interface Endpoint فقط — المزود يدفع رسوم NLB.
- مثالي لأسواق SaaS: شركات البرمجيات تقدم خدماتها لعملاء AWS عبر اتصال خاص وآمن.
بدلاً من تعريض API للإنترنت العام وجعل العملاء يتصلون عبر HTTPS العام، تستخدم PrivateLink.
تنشئ NLB أمام خدمة API في VPC خاصتها، وخدمة VPC Endpoint Service مرتبطة بـ NLB.
عملاؤها في حساباتهم الخاصة ينشئون Interface Endpoints تشير إلى اسم خدمتها.
النتيجة: خدمة API متاحة للعملاء عبر اتصال خاص داخل شبكة AWS — لا تمر عبر الإنترنت، ولا تحتاج VPC Peering أو عناوين IP عامة.
استخدم Gateway Endpoint لـ S3 وDynamoDB فقط — مجاني وأبسط.
استخدم Interface Endpoint لباقي خدمات AWS — يتكلف لكنه يوفر أماناً كاملاً ويقلل استخدام NAT Gateway.
تذكر: Interface Endpoint يدعم سياسات VPC Endpoint — يمكنك تقييد أي عمليات API مسموحة عبر الـ Endpoint لزيادة الأمان.
- AWS PrivateLink يتيح اتصالاً خاصاً بين VPC وخدمات AWS دون المرور بالإنترنت.
- Interface Endpoints تنشئ ENI بعنوان IP خاص لمعظم خدمات AWS.
- Gateway Endpoints لـ S3 و DynamoDB فقط — مجانية وتُضاف كمسار توجيه.
- Endpoint Policies تتحكم في عمليات API المسموحة عبر الـ Endpoint.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Gateway Endpoint | نقطة نهاية البوابة | مسار توجيه للاتصال بـ S3 وDynamoDB عبر شبكة AWS الداخلية — مجاني. |
| Interface Endpoint | نقطة نهاية الواجهة | واجهة شبكة ENI للاتصال بمعظم خدمات AWS والخدمات الخاصة عبر PrivateLink. |
| AWS PrivateLink | الرابط الخاص | تقنية لعرض واستهلاك الخدمات عبر VPC Endpoints دون المرور بالإنترنت العام. |
| Endpoint Service | خدمة نقطة النهاية | خدمة ينشئها المزود لتعريض تطبيقه للعملاء عبر PrivateLink. |
| ENI | واجهة الشبكة المرنة | بطاقة شبكة افتراضية تُنشأ في الشبكة الفرعية لربط الموارد بالشبكة. |
| Endpoint Policy | سياسة نقطة النهاية | سياسة IAM لتقييد عمليات API المسموحة عبر VPC Endpoint. |
1️⃣ Site-to-Site VPN — VPN موقع لموقع
يستخدم بروتوكول IPsec لتشفير البيانات، ويتكون من نفقين (للتكرار) بين Virtual Private Gateway (في AWS) وجهاز البوابة المحلي (Customer Gateway).
- Virtual Private Gateway (VGW): جهاز افتراضي على جانب AWS — يرتبط بـ VPC واحدة ويكون طرف النفقين.
- Customer Gateway (CGW): تمثيل منطقي لجهاز البوابة في مركز بياناتك — تحدده بعنوان IP العام لجهازك المحلي.
- VPN Connection: الاتصال الذي يربط VGW بـ CGW — ينشئ نفقين تلقائياً للتكرار والموثوقية.
- عرض النطاق الأقصى: 1.25 جيجابت في الثانية لكل نفق — يمكن تجميع عدة اتصالات VPN لسعة أعلى.
خلال ساعة واحدة: تنشئ VPC وVirtual Private Gateway، تسجل Customer Gateway بعنوان IP العام لجهاز البوابة المحلي، وتنشئ VPN Connection.
بعد إعداد التوجيه على الطرفين، جميع الخوادم المحلية وخوادم AWS تتواصل عبر نفقين مشفرين عبر الإنترنت.
التكلفة: حوالي 36 دولاراً شهرياً لكل اتصال VPN + رسوم نقل البيانات — حل مثالي للمرحلة الانتقالية.
2️⃣ AWS Direct Connect — الاتصال المباشر
مثالي لأحمال العمل الحساسة لزمن الوصول، نقل كميات ضخمة من البيانات، والمتطلبات التنظيمية التي تمنع مرور البيانات عبر الإنترنت العام.
- سرعات من 50 ميجابت إلى 100 جيجابت في الثانية — أعلى بكثير من VPN.
- زمن وصول منخفض وثابت (عادة أقل من 5 ميلي ثانية إضافية) — مثالي لتطبيقات التداول المالي والألعاب.
- لا يمر بالإنترنت العام — مثالي للصناعات المنظمة (البنوك، الصحة، الحكومة).
- رسوم البيانات الخارجة أقل بنسبة 30-50% مقارنة بالإنترنت — توفير كبير لنقل البيانات الضخمة.
- الإعداد يستغرق أسابيع (وليس دقائق مثل VPN) بسبب التنسيق مع شركاء الاتصالات.
تستخدم Direct Connect بسرعة 10 جيجابت عبر شريك اتصالات محلي.
زمن الوصول: 3 ميلي ثانية ثابتة — مثالي لتطبيقات التداول الحساسة.
تكلفة نقل البيانات: 0.02 دولار لكل جيجابايت (مقابل 0.05 دولار عبر الإنترنت) — توفير 4,500 دولار شهرياً.
كخطة احتياط: تحتفظ باتصال Site-to-Site VPN احتياطي يُفعل تلقائياً إذا تعطل Direct Connect.
3️⃣ Direct Connect Details — تفاصيل الاتصال المباشر
هذه التفاصيل تحدد كيفية تصميم اتصالك المباشر ومدى مرونته وتكامله مع باقي شبكتك السحابية.
- الاتصال المخصص (Dedicated Connection): كابل ألياف ضوئية إيثرنت مادي مخصص لك حصراً — يُطلب مباشرة من AWS. يوفر عرض نطاق 1 أو 10 أو 100 جيجابت في الثانية. يستغرق التنفيذ أسابيع بسبب التمديدات المادية والتنسيق مع مزودي الخدمة.
- الاتصال المستضاف (Hosted Connection): يُوفر عبر شريك Direct Connect معتمد — اتصال مشترك لكن بعرض نطاق مضمون. يتيح زيادات مرنة في عرض النطاق (من 50 ميجابت إلى 10 جيجابت). أسرع في الإعداد لأن الشريك يدير البنية المادية.
- الواجهة الافتراضية العامة (Public VIF): للوصول إلى خدمات AWS العامة مثل S3 وDynamoDB من مركز بياناتك المحلي عبر Direct Connect — دون المرور بالإنترنت. لا تتيح الوصول المباشر إلى VPC.
- الواجهة الافتراضية الخاصة (Private VIF): للوصول إلى VPC واحدة عبر Virtual Private Gateway. تُستخدم عند الحاجة لربط Direct Connect بـ VPC محددة فقط.
- الواجهة الافتراضية العابرة (Transit VIF): للوصول إلى عدة VPCs عبر Transit Gateway. تتصل بـ Direct Connect Gateway الذي يرتبط بـ Transit Gateway عبر Direct Connect Attachment. الخيار الأحدث والأكثر مرونة — يبسط التوجيه بين البيئة المحلية وجميع VPCs المتصلة بـ TGW.
بدلاً من إنشاء Private VIF لكل VPC على حدة (عملية مرهقة)، تنشئ Direct Connect Gateway واحداً وتربطه بـ Transit Gateway عبر Direct Connect Attachment.
تنشئ Transit Virtual Interface (Transit VIF) على اتصال Direct Connect الفعلي — تتصل من موقع Direct Connect إلى Direct Connect Gateway.
النتيجة: كل VPCs الخمسة المتصلة بـ Transit Gateway ترى مركز البيانات المحلي عبر Direct Connect تلقائياً — توجيه مبسط بين المحلي وجميع VPCs دون تعقيد إضافي.
تنشئ اتصال Direct Connect أساسي بسرعة 1 جيجابت عبر موقع Direct Connect أول في مدينة الرياض.
تنشئ اتصال Direct Connect ثاني بسرعة 1 جيجابت عبر موقع Direct Connect آخر في مدينة جدة (لتكرار الموقع الجغرافي).
تنشئ أيضاً اتصال Site-to-Site VPN احتياطي عبر الإنترنت العام — متصل بنفس Virtual Private Gateway.
تُهيئ BGP على جميع الاتصالات الثلاثة بأولويات مختلفة: Direct Connect الأساسي له أعلى أولوية، Direct Connect الثاني يليه، وVPN له أدنى أولوية.
إذا تعطل موقع Direct Connect الأول، يتحول التوجيه تلقائياً إلى الموقع الثاني خلال ثوانٍ. وإذا تعطل كلا الموقعين (سيناريو نادر)، يتحول إلى VPN الاحتياطي تلقائياً — مرونة كاملة بدون تدخل يدوي.
4️⃣ AWS VPN CloudHub — مركز VPN السحابي
مثالي للمؤسسات التي لديها عدة فروع أو مكاتب وتريد ربطها معاً ومع AWS عبر اتصالات VPN دون الحاجة لخطوط اتصال مباشرة بين الفروع.
- يستخدم Virtual Private Gateway واحداً كمحور (hub) تتصل به عدة بوابات عملاء (Customer Gateways) تمثل المواقع المختلفة.
- كل موقع محلي له Customer Gateway خاص به ويستخدم رقم ASN فريد في بروتوكول BGP — هذا ضروري لتمييز المواقع عن بعضها في جداول التوجيه.
- كل موقع بعيد يُعلن عن نطاق عناوينه (CIDR) عبر BGP — يمكن لكل موقع إرسال واستقبال البيانات من المواقع الأخرى عبر محور AWS.
- شرط أساسي: نطاقات عناوين IP للمواقع المختلفة يجب ألا تتداخل — وإلا لن يعرف الموجه إلى أين يرسل الحزم (نفس مشكلة CIDR overlap في VPC Peering).
تنشئ Virtual Private Gateway واحداً في AWS وتُنشئ 4 اتصالات Site-to-Site VPN — اتصال لكل فرع مع Customer Gateway خاص به ورقم BGP ASN فريد لكل فرع.
تُهيئ BGP على كل اتصال: كل فرع يُعلن عن نطاق عناوينه ويستقبل مسارات الفروع الأخرى.
النتيجة: فرع الرياض يمكنه التواصل مباشرة مع فرع جدة عبر نفق VPN يمر عبر AWS — لا حاجة لخطوط MPLS مكلفة بين الفروع. وكذلك كل فرع يصل إلى موارد AWS في VPC المرتبطة بـ Virtual Private Gateway — كل ذلك عبر محور واحد.
5️⃣ VPN Acceleration with Global Accelerator — تسريع VPN
هذا يقلل زمن الوصول ويحسن أداء الاتصال — خاصة للمواقع البعيدة جغرافياً عن منطقة AWS المستهدفة.
- يستخدم Global Accelerator لتوجيه حركة VPN من الشبكة المحلية إلى أقرب موقع حافة (Edge Location) لـ AWS — بدلاً من توجيهها مباشرة إلى منطقة AWS البعيدة عبر الإنترنت العام بالكامل.
- بعد وصول الحركة إلى موقع الحافة، تنتقل عبر البنية التحتية الأساسية لـ AWS (AWS Global Backbone) — شبكة ألياف ضوئية خاصة عالية الأداء — بدلاً من استكمال المسار عبر الإنترنت العام المزدحم والمتغير الأداء.
- مدعوم فقط لاتصالات VPN المرتبطة بـ Transit Gateway — لا يعمل هذا التسريع مع Virtual Private Gateway (VGW) التقليدي. تحتاج إلى ترقية بنيتك لاستخدام TGW للاستفادة من هذه الميزة.
6️⃣ VPN vs Direct Connect — مقارنة VPN وDirect Connect
| المعيار | Site-to-Site VPN | Direct Connect |
|---|---|---|
| سرعة الإعداد | دقائق إلى ساعات | أسابيع (تنسيق مع شركاء) |
| عرض النطاق | حتى 1.25 جيجابت/ثانية (للنفق الواحد) | 50 ميجابت – 100 جيجابت/ثانية |
| زمن الوصول | متغير (يعتمد على الإنترنت) | ثابت ومنخفض |
| التشفير | IPsec مدمج | لا يوجد تشفير افتراضي (أضف IPsec فوقه إذا أردت) |
| المسار | عبر الإنترنت العام | اتصال خاص مخصص |
| التكلفة | منخفضة (~36$/شهرياً لكل اتصال) | مرتفعة (آلاف الدولارات شهرياً حسب السرعة) |
| مناسب لـ | المشاريع الصغيرة والمتوسطة، الاتصالات الاحتياطية، الإعداد السريع | المؤسسات الكبيرة، البيانات الضخمة، التطبيقات الحساسة |
7️⃣ AWS Client VPN — VPN للعميل
على عكس Site-to-Site VPN الذي يربط شبكتين، Client VPN يربط جهاز مستخدم فردي بـ VPC.
- المصادقة عبر Active Directory، الشهادات (certificates)، أو SAML مع مزود هوية.
- يدعم تقسيم الأنفاق (split tunneling): فقط البيانات المتجهة لـ AWS تمر عبر VPN، وباقي الإنترنت يخرج مباشرة.
- يتوسع تلقائياً لآلاف المستخدمين المتزامنين — لا حاجة لإدارة خوادم VPN.
- يدفع المستخدمون مقابل كل اتصال نشط بالساعة.
تنشئ Client VPN endpoint مرتبطاً بـ Active Directory للمصادقة.
المطورون يثبتون برنامج OpenVPN ويستوردون ملف الإعدادات مرة واحدة.
الآن كل مطور يتصل بشبكة VPC من منزله بأمان — يصل إلى بيئات التطوير وخوادم Git وقواعد البيانات وكأنه جالس في المكتب.
- Site-to-Site VPN ينشئ نفقاً مشفراً بين VPC ومركز البيانات المحلي — سريع واقتصادي.
- AWS Direct Connect اتصال خاص مخصص بسرعات تصل إلى 100 جيجابت — أداء ثابت.
- VPN CloudHub يربط فروعاً متعددة عبر محور VPN واحد مع BGP.
- Client VPN يربط المستخدمين الأفراد بموارد AWS عبر OpenVPN.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Virtual Private Gateway | البوابة الافتراضية الخاصة | جهاز افتراضي على جانب AWS لإنهاء اتصالات VPN. |
| Customer Gateway | بوابة العميل | تمثيل منطقي لجهاز البوابة المحلي للعميل. |
| Site-to-Site VPN | VPN موقع لموقع | نفق مشفر عبر الإنترنت بين VPC ومركز البيانات المحلي. |
| Direct Connect | الاتصال المباشر | اتصال خاص مخصص بينك وبين AWS عبر شريك اتصالات. |
| BGP | بروتوكول البوابة الحدودية | بروتوكول توجيه ديناميكي للتبديل التلقائي عند الفشل. |
1️⃣ Hybrid Architecture Design — تصميم معماري هجين متكامل
أفضل الممارسات: استخدم Direct Connect كمسار أساسي (أداء عالٍ) وSite-to-Site VPN كمسار احتياطي (موثوقية) — متصلين معاً عبر Transit Gateway.
- Transit Gateway كمحور مركزي يربط كل VPCs.
- Direct Connect Gateway لربط Direct Connect بـ Transit Gateway (وبالتالي كل VPCs).
- Site-to-Site VPN كاتصال احتياطي متصل أيضاً بـ Transit Gateway.
- بروتوكول BGP للتوجيه الديناميكي بين البيئات — اكتشاف تلقائي للفشل والتحويل.
كل مصنع متصل بـ Direct Connect 1 جيجابت كمسار أساسي.
كل مصنع لديه أيضاً Site-to-Site VPN احتياطي.
الجميع متصل بـ Transit Gateway واحد في حساب الشبكات المركزي.
BGP يدير التوجيه: إذا تعطل Direct Connect، يتحول تلقائياً إلى VPN خلال 30 ثانية.
النتيجة: شبكة عالمية موحدة تجمع 3 مواقع محلية + 10 بيئات سحابية بموثوقية 99.99%.
- البنية الهجينة تجمع الموارد المحلية والسحابية لمرونة وكفاءة أعلى.
- Direct Connect كمسار أساسي مع VPN احتياطي يضمن استمرارية الاتصال.
- Transit Gateway و Direct Connect Gateway يوحّدان الربط بين البيئات.
- تصميم Well-Architected يضمن الأمان والموثوقية والتكلفة المثلى.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| VPC Peering | تناظر VPC | اتصال شبكي مباشر 1:1 بين VPCs عبر شبكة AWS الداخلية. |
| Transit Gateway | بوابة العبور | محور مركزي لربط آلاف VPCs والشبكات المحلية معاً. |
| Gateway Endpoint | نقطة نهاية البوابة | مسار في جدول التوجيه للاتصال بـ S3 وDynamoDB عبر شبكة AWS الداخلية. |
| Interface Endpoint | نقطة نهاية الواجهة | واجهة شبكة (ENI) للاتصال بمعظم خدمات AWS عبر PrivateLink. |
| AWS PrivateLink | الرابط الخاص | تقنية لعرض واستهلاك الخدمات عبر VPC Endpoints دون المرور بالإنترنت. |
| Virtual Private Gateway | البوابة الافتراضية الخاصة | جهاز افتراضي على جانب AWS لإنهاء اتصالات VPN. |
| Customer Gateway | بوابة العميل | تمثيل منطقي لجهاز البوابة المحلي في مركز بيانات العميل. |
| Direct Connect | الاتصال المباشر | اتصال خاص مخصص بين مركز بياناتك وAWS عبر شريك اتصالات. |
1️⃣ Foundation: Connectivity Topology — الأساسات: تخطيط طوبولوجيا الربط
الركيزة الأولى لـ Well-Architected تبدأ بتخطيط واضح لطوبولوجيا الشبكة يشمل نموذج المسؤولية المشتركة (shared responsibility model) واختيار نمط الربط المناسب (hub-and-spoke مقابل full mesh).
- استخدم نمط hub-and-spoke مع Transit Gateway للربط المركزي بين عدد كبير من VPCs — يقلل عدد الاتصالات من n*(n-1)/2 إلى n فقط.
- خصص حساب AWS منفصل للشبكة (network account) يدير Transit Gateway وDirect Connect وVPN مركزياً.
- استخدم AWS Organizations وResource Access Manager (RAM) لمشاركة موارد الشبكة بين الحسابات.
- خطط لنمو الشبكة: اترك مساحة عناوين CIDR كافية للحسابات والـ VPCs المستقبلية.
تستخدم حساب شبكة مركزي مع Transit Gateway يربط جميع الحسابات بنمط hub-and-spoke.
بدلاً من 105 اتصالات فردية (15*14/2)، تحتاج فقط 15 اتصالاً عبر TGW، مما يبسط الإدارة ويخفض التكلفة.
2️⃣ Securing Connectivity Infrastructure — حماية البنية التحتية للاتصالات
تطبيق ركيزة Security على اتصالات الشبكة يتطلب التحكم في الحركة عبر جميع الطبقات (control traffic at all layers) واعتماد نموذج zero trust حتى للاتصالات الداخلية.
- استخدم جداول توجيه Transit Gateway المتعددة لعزل الحركة بين مجموعات VPCs المختلفة (بيئة إنتاج لا ترى بيئة تطوير).
- طبق Network Access Control Lists (NACLs) وSecurity Groups على جميع نقاط الدخول والخروج.
- استخدم AWS Network Firewall لفحص الحركة بين VPCs وكشف التهديدات على مستوى الشبكة.
- فعّل VPC Flow Logs على جميع الواجهات لمراقبة وتحليل حركة الشبكة.
- استخدم Gateway Load Balancer مع أجهزة أمان افتراضية لفحص الحركة قبل وصولها للتطبيقات.
جدول توجيه 1: يربط VPC الإنتاج فقط بـ VPC الخدمات المشتركة. جدول توجيه 2: يربط VPC التطوير فقط بـ VPC الاختبار. AWS Network Firewall يفحص كل الحركة بين الجدولين ويمنع أي اتصال بين الإنتاج والتطوير.
النتيجة: عزل كامل مع استمرارية الخدمات المشتركة.
3️⃣ Data Protection in Transit — حماية البيانات أثناء النقل
ركيزة Security - Data Protection تتطلب تشفير جميع البيانات أثناء النقل باستخدام بروتوكولات آمنة مثل TLS 1.3 للتطبيقات وIPsec لاتصالات VPN.
- استخدم TLS 1.3 كحد أدنى لتشفير الاتصالات بين التطبيقات — يوفر أماناً أعلى وأداء أسرع من الإصدارات السابقة.
- فعّل AWS Certificate Manager (ACM) لإدارة شهادات TLS/SSL وتجديدها تلقائياً.
- استخدم IPsec لتشفير اتصالات Site-to-Site VPN بين البيئة المحلية وAWS.
- فعّل MACsec (تشفير طبقة الربط) مع AWS Direct Connect لتأمين البيانات على المستوى المادي.
- استخدم VPC Endpoints مع PrivateLink للحفاظ على البيانات داخل شبكة AWS وعدم تعريضها للإنترنت.
تستخدم Direct Connect مع MACsec لتشفير الطبقة المادية، وSite-to-Site VPN كنسخة احتياطية مع IPsec.
التطبيقات على AWS تتواصل عبر PrivateLink مع TLS 1.3.
جميع البيانات تبقى مشفرة طوال رحلتها — من المستشفى إلى السحابة إلى التطبيق.
4️⃣ Choosing the Right Connectivity — اختيار بنية الاتصال المناسبة
ركيزة Performance Efficiency تتطلب اختيار تقنية الربط بناءً على متطلبات عرض النطاق وزمن الانتقال والموثوقية والتكلفة.
- داخل AWS: VPC Peering للاتصالات البسيطة (حتى 125 اتصالاً)، Transit Gateway للربط المركزي المعقد (آلاف الـ VPCs).
- الوصول للخدمات: VPC Endpoints (Gateway) لـ S3 وDynamoDB (مجاني)، Interface Endpoints (PrivateLink) لباقي الخدمات.
- ربط المواقع: Site-to-Site VPN للاحتياجات المؤقتة أو الميزانية المحدودة، Direct Connect للبيانات الضخمة والمستمرة (حتى 100 Gbps).
- الموثوقية: استخدم Direct Connect مع VPN احتياطي لضمان استمرارية الاتصال.
تختار Direct Connect بسعة 10 Gbps للنقل الأساسي مع Site-to-Site VPN احتياطي بسعة 1 Gbps.
عند انقطاع Direct Connect (نادراً)، يتحول التوجيه تلقائياً إلى VPN عبر BGP، مما يضمن استمرار نقل المحتوى دون تأخير.
5️⃣ Cost Optimization for Connectivity — تحسين تكلفة اتصالات الشبكة
ركيزة Cost Optimization تركز على اختيار تقنية الربط المناسبة لكل حالة استخدام والتخطيط لتكاليف نقل البيانات عبر المناطق.
- استخدم Transit Gateway بدلاً من شبكة متداخلة من VPC Peering — يقلل التعقيد والتكلفة الإدارية على المدى الطويل.
- فعّل VPC Endpoints (Gateway) لـ S3 وDynamoDB لتجنب تكاليف NAT Gateway لنقل البيانات.
- خطط لتكاليف نقل البيانات عبر المناطق (cross-Region data transfer) — استخدم VPC Peering داخل نفس المنطقة لتجنب هذه التكلفة.
- قارن تكلفة Direct Connect مقابل VPN بناءً على حجم البيانات الشهري — Direct Connect يصبح أرخص عند نقل أكثر من 10 تيرابايت شهرياً.
- استخدم AWS Cloud WAN لإدارة شبكة عالمية موحدة مع سياسة شبكة مركزية — يوفر جهد الإدارة اليدوية.
بدلاً من إدارة شبكة معقدة من VPC Peering (1225 اتصالاً محتملاً)، تستخدم AWS Cloud WAN مع Transit Gateway مركزي.
Cloud WAN يطبق سياسة شبكة واحدة على جميع المناطق، مما يخفض وقت إدارة الشبكة من 20 ساعة أسبوعياً إلى ساعتين فقط.
- استخدم Hub-and-Spoke مع Transit Gateway للتوسع المنظم وتقليل التعقيد.
- طبق Zero Trust مع Network Firewall وVPC Flow Logs لمراقبة كل الاتصالات.
- شفر جميع البيانات أثناء النقل: TLS 1.3 للتطبيقات، IPsec لـ VPN، MACsec لـ Direct Connect.
- اختر Direct Connect للبيانات الضخمة، VPN للاحتياجات المؤقتة، PrivateLink للوصول الآمن للخدمات.
- VPC Endpoints (Gateway) يوفران تكلفة NAT Gateway للوصول إلى S3 وDynamoDB.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Hub-and-spoke | المحور والأطراف | نمط شبكي يربط جميع العقد عبر نقطة مركزية بدلاً من ربطها مباشرة ببعضها. |
| MACsec | تشفير طبقة الربط | بروتوكول أمان يشفر البيانات على مستوى الطبقة الثانية (Layer 2) من الشبكة. |
| BGP | بروتوكول البوابة الحدودية | بروتوكول التوجيه الديناميكي المستخدم بين AWS وشبكتك المحلية لإدارة المسارات. |
| Cloud WAN | الشبكة الواسعة السحابية | خدمة AWS لإدارة شبكة عالمية موحدة عبر مناطق وحسابات متعددة بسياسة مركزية. |
| RAM | مدير الوصول للموارد | خدمة AWS لمشاركة الموارد (مثل TGW وSubnets) بين حسابات متعددة. |
🚀 الخاتمة
في هذه الوحدة تعلمنا أن ربط الشبكات هو المهارة التي تحول مجموعة VPCs معزولة إلى بنية سحابية موحدة.
استكشفنا VPC Peering للاتصالات المباشرة البسيطة بين عدد قليل من VPCs، وAWS Transit Gateway كمحور مركزي يربط آلاف الشبكات بإدارة موحدة.
تعلمنا الفرق الجوهري بينهما: Peering لا يدعم التوجيه المتعدي ويتطلب اتصالاً لكل زوج، بينما TGW يدعم التوجيه المتعدي ويتطلب اتصالاً واحداً فقط لكل شبكة.
تعمقنا في VPC Endpoints: Gateway Endpoint لـ S3/DynamoDB (مجاني)، وInterface Endpoint لباقي الخدمات عبر AWS PrivateLink، مما يسمح بالاتصال بخدمات AWS دون المرور بالإنترنت.
تعرفنا على خيارات الربط بالبيئات المحلية: Site-to-Site VPN السريع والاقتصادي، وDirect Connect عالي الأداء والموثوقية، وClient VPN لاتصال المستخدمين الأفراد.
استعرضنا أفضل ممارسات البنى الهجينة: Direct Connect كمسار أساسي + VPN احتياطي مع BGP للتبديل التلقائي، متصلين معاً عبر Transit Gateway.
وأخيراً، طبقنا ركائز Well-Architected على استراتيجية ربط الشبكات لضمان الأمان والموثوقية والتكلفة المثلى.
تذكر: الشبكة هي الجهاز العصبي لبنيتك السحابية — صمم اتصالاتها بعناية.
