نقاط نهاية VPC وAWS PrivateLink

instance في subnet خاص يرفع 40 TB شهرياً إلى bucket في S3 داخل المنطقة نفسها. وجدول التوجيه يرسل 0.0.0.0/0 إلى NAT gateway، فكل واحد من تلك الجيجابايتات يُحسب عليك برسم معالجة البيانات في الـ NAT gateway وهو في طريقه للخروج. والبيانات لا تلمس الإنترنت العام أصلاً: تخرج عبر internet gateway وتبقى على شبكة AWS طوال الطريق. أنت تدفع لجهاز ترجمة عناوين كي يمرّر حركة بين خدمتين من خدمات AWS.

وهناك مدخل واحد في جدول التوجيه يزيل الـ NAT gateway من ذلك المسار كلياً، ولا يكلّف شيئاً. وهناك نوع ثانٍ من نقاط النهاية يكلّف مالاً ويفعل شيئاً يعجز عنه الأول تماماً. والتفريق بينهما هو معظم هذا الدرس.

لماذا تغادر الحركة الـ VPC أصلاً

خدمات S3 وDynamoDB وCloudWatch وبقية واجهات AWS البرمجية تُطلب عبر نقاط نهاية خدمة عامة: أسماء DNS إقليمية مثل s3.us-east-1.amazonaws.com تُترجم إلى عناوين IP عامة. فالـ instance لديك لا يخاطب شيئاً داخل الـ VPC، فالطرد يحتاج طريقاً للخروج، والـ subnet الخاص بحكم تعريفه لا يملك مساراً إلى internet gateway. ولهذا يوجد الـ NAT gateway.

ونقطة واحدة تستحقّ الدقّة لأنها تغيّر طريقة نقاشك مع فريق الأمان: الحركة إلى خدمة AWS عبر internet gateway لا تغادر شبكة AWS. وAWS تقول ذلك صراحةً. فسبب بناء نقطة نهاية VPC ليس عادةً أن البيانات مكشوفة على الإنترنت. الأسباب أن الـ subnet الخاص لا ينبغي أن يحتاج مساراً للإنترنت أصلاً، وأنك تريد تثبيت الوصول على نقطة نهاية بعينها داخل سياسة، وأن رسم معالجة البيانات في الـ NAT gateway على حركة كبيرة الحجم مال يُنفق على لا شيء.

ونقطة نهاية VPC هي الإصلاح. فهي تصل الـ VPC لديك بخدمة بلا internet gateway ولا جهاز NAT في المسار. ولها شكلان مبنيّان على آليتين مختلفتين.

نقاط نهاية gateway: مسار لا عنوان

نقطة نهاية gateway تخدم خدمتين بالضبط: Amazon S3 وDynamoDB. لا شيء غيرهما. وهي ليست مبنية على PrivateLink، بخلاف كل أنواع نقاط النهاية الأخرى، وهي مجانية.

وحين تنشئ واحدة تختار جداول التوجيه التي ينبغي أن تستخدمها. فتضيف AWS هذا المسار إلى كل جدول اخترته:

وتستطيع النظر إلى ذلك المسار لكنك لا تستطيع تعديله ولا حذفه. ويُزال حين تفكّ ارتباط جدول التوجيه أو تحذف نقطة النهاية. وهذه هي الآلية كاملة: مسار أدقّ يتفوّق على 0.0.0.0/0.

وثلاث نتائج تتبع ذلك مباشرة، وكل واحدة تظهر في أسئلة السيناريو:

الارتباط بجدول التوجيه لا بالـ VPC. فالـ instances في الـ subnets التي ربطت جداول توجيهها تستخدم نقطة النهاية. وinstances في subnets أخرى تبقى على نقطة النهاية العامة للخدمة عبر المسار الذي كانت تسلكه. وبلاغ "بعض الـ instances تعمل وبعضها لا" بشأن الوصول إلى S3 هو عادةً جدول توجيه لم يُربط قطّ.

مطابقة أطول بادئة تحسم كل شيء. فالـ prefix list أدقّ من 0.0.0.0/0، فتذهب حركة S3 داخل المنطقة إلى نقطة النهاية بينما تبقى الحركة إلى أي خدمة أخرى على الـ internet gateway. والـ prefix lists خاصة بكل منطقة، فالحركة إلى S3 في منطقة أخرى تسقط راجعةً إلى الـ internet gateway. وإن أضاف أحدهم مساراً بنطاق عناوين الخدمة نفسه وهدف مختلف، فاز ذلك المسار على مسار نقطة النهاية.

مسار نقطة نهاية واحد لكل خدمة في كل جدول توجيه. فجدول توجيه واحد يستطيع حمل مسار نقطة نهاية لـ S3 ومسار نقطة نهاية لـ DynamoDB، وتستطيع توجيه عدة جداول إلى نقطة النهاية نفسها. لكنك لا تستطيع وضع مسارَي نقطة نهاية لـ S3 في جدول واحد.

والأمان هو ما يفاجئ الناس في نقاط نهاية gateway. فالـ instances لديك تصل إلى الخدمة على عناوينها العامة، فالضوابط التي تنطبق هي التي تصفّي بالعنوان:

# قاعدة خروج في مجموعة الأمان لـ instances تستخدم نقطة نهاية gateway.
# المصدر معرّف prefix list لا نطاق CIDR.
aws ec2 authorize-security-group-egress \
  --group-id sg-0app11111111111111 \
  --ip-permissions IpProtocol=tcp,FromPort=443,ToPort=443,PrefixListIds=[{PrefixListId=pl-63a5400a}]

وقوائم network ACL لا تستطيع الإشارة إلى prefix list، فإن حمل الـ subnet قائمة network ACL مقيّدة وجب أن تقرأ نطاقات CIDR الخدمة من الـ prefix list وتكتبها قواعد. ولا وجود لمجموعة أمان على نقطة نهاية gateway، لأن نقطة نهاية gateway بلا واجهة شبكة تُرفق بها واحدة.

نقاط نهاية interface: عنوان خاص داخل الـ subnet لديك

نقطة نهاية interface كائن مختلف. فلكل subnet تختاره، تنشئ AWS واجهة شبكة لنقطة النهاية في ذلك الـ subnet وتمنحها عنوان IP خاصاً من نطاقه. وتلك الواجهة يديرها الطالب: تراها ولا تديرها، وعنوانها لا يتغيّر طوال عمر نقطة النهاية. وتختار subnet واحداً لكل منطقة توفّر، ولا اثنين في المنطقة نفسها أبداً.

ولأنها واجهة شبكة حقيقية بعنوان خاص حقيقي، تعمل الأشياء التي تتوقّع عملها:

• تحمل مجموعات أمان، وتلك القواعد تتحكّم بمن يجوز له من موارد الـ VPC مخاطبتها. انسَ السماح بالمنفذ 443 دخولاً من مجموعة أمان تطبيقك فيتعلّق كل نداء يصدر من الـ SDK.
• عنوانها قابل للوصول من أي مكان يستطيع التوجيه إلى الـ subnet لديك: VPC متناظر، أو transit gateway، أو Site-to-Site VPN، أو اتصال Direct Connect.
• وهي مدفوعة. تدفع رسماً بالساعة عن نقطة النهاية في كل منطقة توفّر أُنشئت فيها، زائد رسماً لكل GB معالَج.

والوصول إلى الخدمة يجري عبر DNS. فإنشاء نقطة النهاية يمنحك اسماً إقليمياً واسماً لكل منطقة توفّر:

vpce-099deb00b40f00e22.monitoring.us-east-2.vpce.amazonaws.com
vpce-099deb00b40f00e22-us-east-2a.monitoring.us-east-2.vpce.amazonaws.com

ولا أحد يريد إعادة كتابة كل عميل SDK كي يستخدم تلك الأسماء. ولهذا وُجد private DNS. فعّله فتنشئ AWS private hosted zone مخفية تديرها هي، تحوي سجلاً لاسم الخدمة العام المعتاد يشير إلى العناوين الخاصة لواجهات نقطة النهاية لديك. فيصير كودك القائم الذي ينادي monitoring.us-east-2.amazonaws.com واصلاً إلى نقطة النهاية بلا أي تعديل.

ولـ private DNS شرط مسبق صارم يولّد تدفّقاً ثابتاً من التذاكر: يجب أن يحمل الـ VPC خاصيّتي enableDnsSupport وenableDnsHostnames معاً مفعّلتين. وبدونهما يمكن اختيار الخيار ولا يظهر أي أثر. ولأن السجلّ يعيش في private hosted zone يقدّمها Route 53 Resolver، فهو يعمل داخل الـ VPC وحده. والمتّصلون من الشبكة المحلية يستخدمون أسماء DNS الخاصة بنقطة النهاية، وهي تُترجم عامّاً إلى العناوين الخاصة، أو يصلون إلى Route 53 Resolver عبر inbound Resolver endpoint.

والتوفّر يتبع موضع الواجهات. فإن فعّلت منطقة توفّر واحدة، تُرجم الاسم الإقليمي إلى تلك الواجهة الوحيدة للـ VPC كله، بما فيه instances في مناطق أخرى. وهذا يعمل جيداً إلى أن تتعطّل المنطقة التي تحمل الواجهة، فيفقد الـ VPC كله الخدمة. وتوصي AWS بمنطقتي توفّر على الأقلّ لكل نقطة نهاية، ومع أكثر من واجهة سليمة تتناوب بينها بالتدوير.

الحدّ الذي يحسم أغلب الأسئلة

النوعان يبقيان الحركة على شبكة AWS. وهما يختلفان في من يستطيع استخدامهما وفي ما يكلّفان.

والسؤال الوحيد الذي يفصل بينهما في أي سيناريو هو أين يجلس المتّصل. داخل هذا الـ VPC والوجهة S3 أو DynamoDB؟ نقطة نهاية gateway هي الجواب الرخيص. وأي موضع آخر، أو أي خدمة أخرى؟ نقطة نهاية interface.

وهما غير متعارضين، وتوثّق AWS الجمع بينهما نمطاً لخفض التكلفة مع S3: أبقِ نقطة نهاية gateway كي تبقى الحركة الداخلية مجانية، وأضف نقطة نهاية interface كي تصل التطبيقات المحلية إلى S3 خاصةً، ووجّه العملاء المحليين إلى أسماء DNS الخاصة بنقطة النهاية. وتفعل وحدة التحكّم هذا نيابةً عنك بخيار Enable private DNS only for inbound endpoint، وهو يوجّه الاستعلامات الواردة عبر inbound Resolver endpoint وحدها إلى نقطة نهاية interface ويترك الحركة الداخلية على مسار gateway المجاني. واختياره يتطلّب وجود نقطة نهاية gateway في الـ VPC أصلاً، ولا تستطيع حذف تلك النقطة ما دام الخيار مفعّلاً.

سياسات نقاط النهاية: بوابة لا منح

كل نقطة نهاية لخدمة من خدمات AWS تستطيع حمل سياسة نقطة نهاية: سياسة مورد بلغة IAM ترتبط بنقطة النهاية وتقرّر أي principals وأي إجراءات يجوز لها المرور عبرها. وإن لم ترفق واحدة، أرفقت AWS الافتراضية، وهي تسمح بكل شيء:

{
  "Statement": [
    { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" }
  ]
}

والنموذج الذهني الذي يجنّبك المتاعب: سياسة نقطة النهاية مصفاة على الأنبوب، لا مصدر صلاحية. فهي لا تتجاوز ولا تستبدل سياسة قائمة على الهوية ولا سياسة قائمة على المورد. والطلب الذي يعبر نقطة النهاية يحتاج موافقة من سياسة IAM على المتّصل، وموافقة من أي سياسة مورد مثل سياسة bucket في S3، وموافقة من سياسة نقطة النهاية. استبدل الافتراضية بسياسة ضيّقة فتستطيع إنتاج AccessDenied لدور يحمل AmazonS3FullAccess، وهذه بالضبط هي التذكرة المحيّرة التي يولّدها هذا التصميم.

وهناك اقتران مفيد في الاتجاه المعاكس أيضاً. فسياسة نقطة النهاية تحدّ أي buckets يمكن الوصول إليها عبر نقطة النهاية، وسياسة bucket بشرط aws:sourceVpce تحدّ أي نقاط نهاية تستطيع الوصول إلى الـ bucket. استخدم الاثنين فيصير الـ bucket غير قابل للوصول إلا من شبكتك، وتصير شبكتك غير قادرة على الوصول إلا إلى ذلك الـ bucket:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "Access-to-specific-VPCE-only",
    "Principal": "*",
    "Action": "s3:*",
    "Effect": "Deny",
    "Resource": ["arn:aws:s3:::finance-reports", "arn:aws:s3:::finance-reports/*"],
    "Condition": { "StringNotEquals": { "aws:sourceVpce": "vpce-1a2b3c4d" } }
  }]
}

وتفاصيل تعضّ عملياً:

• يجب أن تحوي السياسة عنصر Principal. ولنقاط نهاية gateway يجب أن يكون ذلك العنصر *، وتضيّق الـ principal بشرط aws:PrincipalArn بدلاً منه.
• الحجم الأقصى 20,480 حرفاً بما فيها المسافات.
• ليست كل خدمة في AWS تدعم سياسات نقاط النهاية. وحيث لا تدعمها الخدمة، يُسمح بالوصول الكامل عبر نقطة النهاية ولا يغيّر ما تكتبه شيئاً.
• تستغرق التغييرات دقائق قليلة كي تسري، فاختبار مباشرةً بعد الحفظ قد يضلّلك في أي من الاتجاهين.

PrivateLink لخدمة تملكها أنت

كل ما سبق كان استهلاكاً لخدمة من AWS. وPrivateLink يعمل في الاتجاه الآخر أيضاً: تستطيع نشر خدمة من الـ VPC لديك وترك حسابات أخرى تستهلكها نقطةَ نهاية interface، بلا peering، وبلا مساحة عناوين مشتركة، وبلا مسار بين الـ VPCين.

بصفتك مزوّد الخدمة تضع Network Load Balancer أمام خدمتك، ثم تنشئ إعداد endpoint service يشير إلى ذلك الموازن. وافتراضياً لا يستطيع أحد الاتصال: تضيف أذونات تسمّي principals محدّدة في AWS يُسمح لها بطلب الاتصال. وتولّد AWS اسم خدمة مثل com.amazonaws.vpce.us-east-2.vpce-svc-071afff70666e61e0 تشاركه مع المستهلكين.

وبصفتك المستهلك تنشئ نقطة نهاية interface لاسم الخدمة ذاك. فيصل طلب الاتصال إلى المزوّد، فيقبله أو يرفضه، يدوياً أو تلقائياً. وتصير نقطة النهاية قابلة للاستخدام حين تبلغ حالة available، والحالات الممكنة تستحقّ التعرّف عليها في سؤال استكشاف أخطاء: pendingAcceptance تعني أن المزوّد لم يتصرّف بعد، وrejected تعني أنه رفض، وexpired تعني أن الطلب انتهت مهلته.

وأمران يجعلان هذا النمط يتوسّع حيث يعجز peering. فالـ VPCان لا يتبادلان مسارات أبداً، فـ تداخل نطاقات CIDR لا يهمّ. والاتصال أحادي الاتجاه بحكم البناء: المستهلك يبدأ، والخدمة لا تستطيع فتح اتصالات راجعة عبر نقطة النهاية.

وللتوفّر العالي يفعّل المزوّد موازن الحمل في منطقتي توفّر على الأقلّ، لأن الـ endpoint service متاحة في المناطق المفعّلة على موازن الحمل وحدها. وموازنة الحمل عبر المناطق بديل، بتحفّظ أن عطل منطقة واحدة يُسقط عندها الوصول من المنطقتين، مع رسوم نقل بيانات في EC2.

وإن ربط المزوّد اسم DNS خاصاً بالـ endpoint service وأثبت ملكية النطاق، أمكن المستهلكين الاستمرار على مناداة الخدمة باسمها القائم. وبدون ذلك يعدّل المستهلكون تطبيقاتهم كي تستخدم اسم DNS الخاص بنقطة النهاية.

حين لا يعمل الأمر

تتجمّع أعطال نقاط النهاية في عدد صغير من الأسباب. امشِ عليها بهذا الترتيب:

مجموعة الأمان على واجهة نقطة النهاية. تحصل نقاط نهاية interface على مجموعة الأمان الافتراضية للـ VPC ما لم تختر غيرها، والافتراضية تسمح بالدخول من موارد المجموعة نفسها فقط. فإن كانت instances تطبيقك في مجموعة أمان أخرى، تعلّق كل نداءات نقطة النهاية حتى تضيف قاعدة دخول تسمح بالمنفذ 443 منها.

ping لا يثبت شيئاً. فنقاط نهاية interface لا تردّ على طلبات ICMP echo. وتقول AWS إن الأداة المناسبة nc أو nmap. وإعادة بناء نقطة نهاية سليمة لأن ping فشل عطل حقيقي يمكن تفاديه.

# هل تجيب نقطة النهاية على منفذ الخدمة؟
nc -zv vpce-099deb00b40f00e22.monitoring.us-east-2.vpce.amazonaws.com 443

# إلى ماذا يُترجم اسم الخدمة فعلاً؟
dig +short monitoring.us-east-2.amazonaws.com

فإن أعاد dig عناوين عامة، فـ private DNS إما معطّل وإما أن الـ VPC ينقصه خاصيّتا DNS.

سياسة نقطة النهاية. فـ AccessDenied تنجو من سياسة IAM صحيحة، ولا تحدث إلا للنداءات القادمة من داخل الـ VPC، تشير إلى سياسة نقطة النهاية في كل مرة.

نوع نقطة النهاية الخاطئ. فالمتّصلون من الشبكة المحلية والـ VPCs المتناظرة والمناطق الأخرى لا يستطيعون استخدام نقطة نهاية gateway. وهذا ليس إعداداً تصلحه، بل خاصيّة في الآلية نفسها.

قوائم network ACL. فالحركة بين مواردك وواجهات نقطة النهاية ما زالت تعبر حدّ الـ subnet. والقائمة المقيّدة تحتاج قواعد في الاتجاهين، بما فيها مدى المنافذ العابرة لحركة العودة.

حصص تستحقّ الحفظ

نصائح الاختبار

• "S3 أو DynamoDB، من داخل الـ VPC، بلا تكلفة إضافية" هي نقطة نهاية gateway. وأي خدمة أخرى، أو أي متّصل من خارج الـ VPC، نقطة نهاية interface.
• عبارة "من مركز بياناتنا المحلي" أو "من الـ VPC المتناظر" تستبعد نقاط نهاية gateway كلياً. وهذا أسرع استبعاد في هذا الموضوع.
• نقطة نهاية gateway تعني مدخلاً في جدول التوجيه. ونقطة نهاية interface تعني واجهة ENI بعنوان خاص. وكل فرق آخر يتبع هذه الجملة الواحدة.
• نقاط نهاية interface وحدها تحمل مجموعات أمان. والسؤال عن تقييد أي instances يجوز لها استخدام نقطة نهاية هو سؤال نقطة نهاية interface.
• سياسة نقطة النهاية لا تمنح صلاحية أبداً. وحين يعرض سيناريو AccessDenied رغم سياسة IAM واسعة، ابحث عن سياسة نقطة النهاية أو عن شرط aws:sourceVpce في سياسة الـ bucket.
• private DNS يتطلّب تفعيل DNS hostnames وDNS resolution على الـ VPC. وهذا الجواب كلما قيل "فعّلنا private DNS ولم يتغيّر شيء".
• استضافة خدمتك على PrivateLink تحتاج Network Load Balancer وأذونات principals صريحة. أما نقاط نهاية Gateway Load Balancer فوظيفتها توجيه الحركة إلى أجهزة فحص، وهي مهمّة مختلفة.
• subnet واحد لكل منطقة توفّر لنقطة نهاية interface، ومنطقتان على الأقلّ في الإنتاج وإلا كنت قد بنيت تبعيّة أحادية المنطقة للـ VPC كله.
• نقاط نهاية interface لا تجيب على ping.

القاعدة التي تخرج بها قصيرة: إن كان المتّصل داخل هذا الـ VPC والوجهة S3 أو DynamoDB، فخذ المسار المجاني؛ وإلا فادفع ثمن عنوان خاص. والدرس التالي يبقي الهدف نفسه، أي إبقاء الحركة خاصة، لكنه يغيّر الوجهة من خدمة في AWS إلى شبكة أخرى، فيتوقّف السؤال عن كونه "أي نقطة نهاية" ويصير "كم اتصالاً أنا مستعدّ لإدارته".