شبكات AWS والهوية

أساسيات الشبكة الافتراضية الخاصة (VPC)

18 دقيقة الدرس 1 من 28

أساسيات الشبكة الافتراضية الخاصة (VPC)

الشبكة الافتراضية الخاصة (VPC) هي قسمك المعزول منطقيًا داخل السحابة الخاصة بـ AWS. تخيّلها كمركز بيانات خاص بك داخل AWS — أنت من يتحكم تمامًا في نطاقات عناوين IP والشبكات الفرعية والتوجيه وضوابط الوصول. كل نسخة EC2 وقاعدة بيانات RDS ودالة Lambda داخل VPC وعُقدة EKS تعيش داخل شبكة VPC. الحصول على تصميم الـ VPC صحيحًا من البداية هو أحد أكثر القرارات تأثيرًا في أي حِمل عمل على AWS؛ إعادة تصميم الشبكة بعد النشر تكون مؤلمة على نطاق واسع.

لماذا توجد الـ VPCs

قبل ظهور الـ VPCs (حقبة EC2-Classic)، كانت جميع النسخ تشترك في شبكة مسطحة تديرها AWS. كان بإمكان أي نسخة الوصول إلى أي أخرى. جاءت الـ VPCs عام 2009 وأصبحت الإعداد الافتراضي عام 2013، لتمنحك عزل الشبكة على مستوى البنية التحتية — لا مجرد قواعد مجموعات الأمان. مواردك تكون غير قابلة للوصول بشكل افتراضي؛ وأنت من يصرّح بحركة المرور صراحةً في كلا الاتجاهين.

في شركات كأمازون وجوجل وميتا، تفرض فرق الشبكات قيودًا صارمة على نطاق الضرر المحتمل (blast radius): أي خطأ في الإعداد أو اختراق في بيئة ما يجب ألا ينتشر إلى بيئة أخرى. عزل الـ VPC هو طبقة التطبيق الأولى لهذا المبدأ.

التخطيط لنطاق CIDR — القرار الذي يمتد عبر الزمن

لكل VPC كتلة CIDR أساسية — نطاق من عناوين IP الخاصة معبّر عنه بترميز CIDR. بمجرد تعيينه، لا يمكنك تصغيره؛ يمكنك فقط إضافة كتل CIDR ثانوية (حتى 4 إضافية، بحد أدنى /28 وأقصى /16 لكل منها). اختر نطاقًا صغيرًا جدًا وستنفد منك عناوين IP تحت الضغط. اختر نطاقًا بلا تخطيط وستصطدم بتعارضات تجعل اتصالات VPC Peering وTransit Gateway وشبكة VPN المحلية مستحيلة.

نطاقات RFC 1918 الخاصة المتاحة لـ VPCs:
10.0.0.0/8 — نحو 16.7 مليون عنوان (أكبر مساحة متاحة)
172.16.0.0/12 — نحو مليون عنوان
192.168.0.0/16 — نحو 65,000 عنوان (صغير جدًا للإنتاج)

استراتيجية CIDR العملية في بيئات AWS متعددة الحسابات

في منظمة حقيقية تدير AWS Organizations بعشرات الحسابات، تحتاج إلى خطة عناوين IP شاملة. نمط شائع يُستخدم على نطاق واسع:

خصّص شبكة فائقة /8 أو /10 للمنظمة بأكملها من مساحة العناوين الخاصة.
قسّمها حسب البيئة: 10.0.0.0/12 للإنتاج، 10.16.0.0/12 للاختبار، 10.32.0.0/12 للتطوير.
قسّمها أكثر حسب المنطقة: داخل الإنتاج، 10.0.0.0/14 لـ us-east-1، و10.4.0.0/14 لـ eu-west-1.
كل VPC يحصل على /16 من كتلة منطقته — 65,536 عنوانًا، كافٍ لمعظم أحمال العمل.
الشبكات الفرعية تُنحت من CIDR الـ VPC كشرائح /24 (254 عنوانًا صالحًا للاستخدام) أو /22 (1,022 عنوانًا).

AWS تحجز 5 عناوين IP في كل شبكة فرعية — الأربعة الأولى والأخيرة. الـ /24 يمنحك 256 − 5 = 251 عنوانًا صالحًا، وليس 254. الـ /28 (أصغر شبكة فرعية مسموح بها) يمنح 11 عنوانًا فقط. دائمًا حجّم الشبكات الفرعية أكبر مما تتوقع حاجتك الحالية؛ مجمّعات عُقد EKS يمكن أن تستنفد الـ /24 بسرعة.

الـ VPC الافتراضي مقابل الـ VPC المخصص

تنشئ AWS VPC افتراضيًا في كل منطقة لكل حساب. يستخدم 172.31.0.0/16 وينشئ شبكة فرعية /20 في كل منطقة توفر مع تفعيل التعيين التلقائي لعناوين IP العامة. هذا الإعداد متساهل عن قصد للتجريب — لا للإنتاج.

مشكلات الـ VPC الافتراضي في بيئات الإنتاج:

النسخ التي تُطلق دون اختيار شبكة فرعية محددة تذهب إلى الـ VPC الافتراضي وتحصل على عناوين IP عامة تلقائيًا — خطر تعرّض خطير عرضي.
نطاق 172.31.0.0/16 يتعارض كثيرًا مع شبكات VPN المؤسسية والشبكات المحلية.
لا هيكل شبكة فرعية دقيق — لا فصل بين الطبقات العامة وتطبيق الإنتاج وطبقة البيانات.
سياسات التحكم في الخدمات (SCP) في كثير من الشركات تحظر الآن استخدام الـ VPC الافتراضي كليًا.

لا تُشغّل أحمال عمل الإنتاج أبدًا في الـ VPC الافتراضي. تضمّنت كثير من اختراقات بيانات AWS الجسيمة بين 2017-2020 نسخًا أُطلقت عرضًا في الـ VPC الافتراضي مع مجموعة أمان متساهلة. تحذف معظم المؤسسات الواعية بالأمن الـ VPC الافتراضي عند إنشاء الحساب عبر أتمتة (قاعدة AWS Config + Lambda للمعالجة، أو CloudFormation StackSet).

إنشاء VPC مخصص — CLI وTerraform

إنشاء VPC عبر AWS CLI أمر مباشر. هنا تُنشئ VPC وتضع علامات عليه وتفعّل دعم DNS (مطلوب للمناطق المستضافة الخاصة وEKS):

# إنشاء VPC بنطاق CIDR /16
aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=prod-us-east-1},{Key=Env,Value=production}]' \
  --region us-east-1

# تفعيل أسماء المضيف DNS (مطلوب لمناطق Route 53 الخاصة وEKS)
aws ec2 modify-vpc-attribute \
  --vpc-id vpc-0abc123def456789 \
  --enable-dns-hostnames

# تفعيل حل DNS
aws ec2 modify-vpc-attribute \
  --vpc-id vpc-0abc123def456789 \
  --enable-dns-support

في الإنتاج، يجب إدارة الـ VPCs باستخدام Terraform أو AWS CloudFormation وليس CLI، حتى يكون الإعداد تحت إدارة الإصدارات وقابلًا للتدقيق والتكرار. كتلة Terraform بسيطة للـ VPC تبدو هكذا:

# terraform/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name        = "prod-us-east-1"
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

# استرجاع معرّف الـ VPC للموارد اللاحقة
output "vpc_id" {
  value = aws_vpc.main.id
}

output "vpc_cidr" {
  value = aws_vpc.main.cidr_block
}

تشريح الـ VPC: ما الذي يسكن داخله

الـ VPC حاوية تضم عدة بُنى مترابطة — جميعها ستضبطها في الدروس اللاحقة. على المستوى الأعلى، كل VPC إنتاجي يتضمن:

الشبكات الفرعية (Subnets) — أقسام من CIDR موزّعة عبر مناطق التوفر (الدرس 2)
جداول التوجيه (Route Tables) — قواعد توجيه لكل شبكة فرعية توجّه الحركة نحو البوابات (الدرس 2)
بوابة الإنترنت (IGW) — المنفذ إلى الإنترنت العام للشبكات الفرعية العامة (الدرس 2)
بوابة NAT — وصول إنترنت للخروج فقط للشبكات الفرعية الخاصة (الدرس 2)
مجموعات الأمان (Security Groups) — قواعد جدار حماية ذو حالة مرفقة بواجهات الشبكة (الدرس 3)
قوائم التحكم في الوصول للشبكة (NACLs) — قواعد جدار حماية عديمة الحالة على مستوى الشبكة الفرعية (الدرس 3)

مخطط بنية الـ VPC

VPC مخصص يمتد عبر منطقتي توفر، مع شبكات فرعية عامة وخاصة في كل منطقة وبوابة إنترنت عند الحدود.

اعتبارات الإنتاج الرئيسية

انشر دائمًا عبر منطقتي توفر على الأقل — عطل منطقة توفر واحدة يجب ألا يوقف خدمتك.
افصل الطبقات في شبكات فرعية منفصلة — عامة (موازنات التحميل)، خاصة (التطبيق)، بيانات (RDS، ElastiCache). هذا يمنحك تحكمًا دقيقًا في التوجيه وNACL.
احجز مساحة عناوين — اترك على الأقل /24 واحدة لكل منطقة توفر لكل طبقة غير مخصصة للخدمات المستقبلية. نفاد عناوين IP في VPC نشط هو ترحيل بالغ الصعوبة.
ضع علامات على كل شيء — علامات Name وEnv وTeam وCostCenter على كل VPC وشبكة فرعية. AWS Cost Explorer ومجموعات الموارد وأدوات الامتثال تعتمد على هذه العلامات.
فعّل VPC Flow Logs من اليوم الأول — تُرسل إلى CloudWatch Logs أو S3، وهي ضرورية للتحقيق الأمني وتشخيص أخطاء الشبكة (الدرس 9). تفعيلها بعد وقوع الحادثة يكون متأخرًا جدًا.

وثّق تخصيص CIDR في سجل مركزي — جدول DynamoDB بسيط أو صفحة Confluence أو أداة مثل NetBox. عندما تمتلك منظمتك أكثر من 50 حسابًا و200 VPC، تعارض نطاقات CIDR غير الموثقة سيعيق اتصال VPC Peering في أسوأ وقت ممكن.