أساسيات السحابة: خدمات AWS الأساسية

EC2: الأنواع والصور والدورة الحياتية

18 دقيقة الدرس 3 من 30

EC2: الأنواع والصور والدورة الحياتية

Amazon EC2 (Elastic Compute Cloud) هو العمود الفقري للحوسبة في AWS. كل عقدة في مجموعة الحاويات، وكل عداء CI، وكل قاعدة بيانات تُدار ذاتيًا، وكل تطبيق قديم تهاجره إلى السحابة — سيصبح في النهاية instance على EC2. إتقان نموذج الـ instance بعمق، لا مجرد "اختر t3.medium واتصل بـ SSH" — هو ما يميز المهندسين الذين يطفئون الحرائق عن أولئك الذين يبنون أنظمة لا تشتعل أصلًا.

أنواع الـ Instance: اختيار النسبة الصحيحة بين CPU والذاكرة

تتبع أنواع EC2 convention في التسمية: العائلة + الجيل + الحجم، مع لواحق اختيارية للقدرات. مثال: m7g.2xlarge = عائلة General Purpose (m)، الجيل السابع، معالج Graviton3 ARM (g)، حجم 2xlarge (8 vCPU / 32 GiB RAM).

General Purpose (m, t) — توازن بين CPU والذاكرة. m7i/m7g للأعباء الإنتاجية؛ t4g/t3 للبيئات التطويرية والاختبارية ذات الاستخدام المتقطع. عائلة t تستخدم "رصيد CPU" — جذابة للتكلفة لكنها قاتل صامت للخدمات الإنتاجية الحساسة للزمن عند نفاد الرصيد.
Compute Optimized (c) — CPU عالي مع ذاكرة أقل بالنسبة للنواة. c7g/c7i للترميز وخوادم الألعاب وعمليات بناء CI والخدمات المصغرة كثيفة المعالجة.
Memory Optimized (r, x, u) — ذاكرة RAM عالية. r7g لقواعد البيانات في الذاكرة (Redis) وأكوام JVM الكبيرة وElasticsearch.
Storage Optimized (i, d, h) — NVMe SSD محلي بـ IOPS وإنتاجية عالية جدًا. i4i لوسطاء Kafka وCassandra وOLTP ذات الإنتاجية العالية حيث يكون زمن استجابة EBS عائقًا.
Accelerated Computing (p, g, inf, trn) — GPU وشرائح مخصصة. p4de لتدريب ML؛ g5 للاستدلال والرسوميات؛ inf2/trn1 لرقاقات Inferentia/Trainium بتكلفة أقل لكل عملية استدلال مقارنة بـ GPU.

على نطاق المؤسسات الكبرى، توفر الـ instances المبنية على Graviton (m7g، c7g، r7g) أداءً أفضل بنحو 40% مقابل الـ x86 لمعظم أعباء العمل السحابية الأصيلة. ابدأ بترحيل الحاويات والخدمات المتوافقة مع ARM — المكاسب فورية والتعقيد التشغيلي ضئيل.

Amazon Machine Images (AMIs)

AMI هو لقطة غير قابلة للتعديل، مرتبطة بمنطقة محددة، تشمل جذر القرص وأذونات الإطلاق وتعيينات أجهزة التخزين. كل إطلاق instance يستند إلى AMI واحد بالضبط. هناك ثلاثة مصادر للـ AMIs:

مُدارة من AWS — Amazon Linux 2023 (AL2023)، Ubuntu، Windows Server، وغيرها. AL2023 هو الأساس الموصى به للمشاريع الجديدة: يأتي بحزم أحدث، وSELinux مفعّل افتراضيًا، ودورة دعم واضحة.
AWS Marketplace — صور تجارية محصّنة مسبقًا (معايير CIS، أجهزة أمان). تخضع لرسوم ترخيص برامج إضافية فوق تكلفة EC2.
مخصصة (Golden AMI) — أرتيفاكت مؤسستك. يُبنى باستخدام Packer أو EC2 Image Builder، ويتضمن وكلاءك (CloudWatch، SSM، Datadog) وخطوط أمانك وتبعياتك المثبتة مسبقًا. هذا هو معيار الإنتاج في كل شركة جادة.

مسار Golden AMI: يُحصّن Packer/Image Builder صورة أساسية وينتج AMI ثابتة وذات إصدارات تُستخدم عبر مجموعات ASG وعقد EKS وأسطول CI.

User Data: الإعداد الأولي بدون SSH

User Data هو سكريبت bash (أو YAML لـ cloud-init) يُشغّله EC2 كـ root عند أول إقلاع، قبل بدء تطبيقك. إنه الجسر بين AMI الذهبي والـ instance المُشغّل بالكامل. الـ AMI الجيد يُقلّل User Data ليقتصر على الإعداد الخاص بالبيئة فقط — سحب الأسرار، كتابة ملفات البيئة، تشغيل وحدة systemd للتطبيق. User Data الذي يثبت الحزم من الصفر عند كل إقلاع هو علامة على ضعف مسار بناء AMI.

#!/bin/bash
# User data بسيط للإنتاج — الـ Golden AMI يحتوي على الوكلاء مثبتة مسبقًا
set -euo pipefail

REGION="us-east-1"
ENV="production"

# سحب الإعداد من SSM Parameter Store (لا credentials مطلوبة — تأتي من دور الـ instance)
DB_URL=$(aws ssm get-parameter \
  --name "/myapp/${ENV}/db_url" \
  --with-decryption \
  --query Parameter.Value \
  --output text \
  --region "${REGION}")

# كتابة ملف البيئة المستخدم من قبل وحدة systemd (EnvironmentFile=)
mkdir -p /etc/myapp
cat > /etc/myapp/env <<ENVEOF
DB_URL=${DB_URL}
ENVIRONMENT=${ENV}
REGION=${REGION}
ENVEOF
chmod 600 /etc/myapp/env

# الـ binary مخبوز في الـ AMI مسبقًا — فعّله وشغّله فقط
systemctl enable --now myapp

# إشعار lifecycle hook بأن الإقلاع نجح
INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
aws autoscaling complete-lifecycle-action \
  --lifecycle-action-result CONTINUE \
  --instance-id "${INSTANCE_ID}" \
  --lifecycle-hook-name "instance-launching" \
  --auto-scaling-group-name "${ASG_NAME:-unknown}" \
  --region "${REGION}" 2>&1 || true

User Data يعمل فقط عند أول إقلاع للـ instance الجديد. إذا أوقفت instance وأعدت تشغيله (وهو مختلف عن إعادة التشغيل/reboot)، فإنه يحصل على مضيف فيزيائي جديد لكن User Data لا يُعاد تنفيذه افتراضيًا. إذا كانت منطقتك البرمجية تحتاج إلى إعادة تنفيذ، استخدم cloud-init بتردد always أو وثيقة SSM Run Command.

دورة حياة الـ Instance

تمر EC2 instances عبر آلة حالات محددة جيدًا. كل انتقال في الحالة له تداعيات على الفوترة والعمليات تهم بشكل كبير على نطاق واسع:

pending — الـ instance قيد التهيئة. يبدأ الفوترة لاحقًا.
running — الـ instance يعمل. الفوترة نشطة بالثانية (Linux) أو بالساعة (Windows).
stopping / stopped — الـ instance متوقف. قرص EBS الجذر وجميع الأقراص المُرفقة تبقى موجودة. تدفع مقابل تخزين EBS فقط وليس الحوسبة. الـ instance يحتفظ بـ ID وعنوان IP الخاص والـ Elastic IP المرتبط.
shutting-down / terminated — الـ instance يُحذف نهائيًا. افتراضيًا، قرص EBS الجذر يُحذف أيضًا (DeleteOnTermination=true). الأقراص الإضافية المُرفقة لا تُحذف افتراضيًا — احذر من تكاليف EBS اليتيمة.
rebooting — إعادة تشغيل على مستوى نظام التشغيل. لا يغير المضيف الفيزيائي ولا يبدأ دورة فوترة جديدة.

آلة حالات دورة حياة EC2: pending وrunning هما حالات حوسبة مُفوترة؛ stopped يحتفظ بـ EBS؛ terminated لا رجعة منه.

نماذج الشراء

طريقة دفعك لسعة EC2 بالغة الأهمية مثل ما تشغّله عليها. ثلاثة نماذج تسود أعباء الإنتاج:

On-Demand — ادفع بالثانية بلا التزام. مناسب للأعباء غير المتوقعة أو قصيرة الأمد والأعباء الجديدة التي لا يُعرف نمط استخدامها بعد.
Reserved Instances / Savings Plans — التزم بسنة أو ثلاث سنوات مقابل خصومات 30–72%. Compute Savings Plans هو التفضيل الحديث — تُطبَّق تلقائيًا على أي عائلة EC2 أو منطقة أو نظام تشغيل. سعتك الثابتة يجب دائمًا أن تكون مغطاة بـ Savings Plan.
Spot Instances — مزايدة على سعة EC2 غير المستخدمة بخصم يصل إلى 90%. AWS يمكنه استردادها بإشعار دقيقتين. مناسبة للإنتاج في الأعباء عديمة الحالة والمتحملة للأعطال: عُدّاء CI/CD ودُفعات تدريب ML وأسطول الـ rendering. لا تستخدم Spot لـ Stateful Singletons أبدًا.

خطأ إنتاجي شائع: ASG مُهيأ بنوع Spot instance واحد ومنطقة توافر (AZ) واحدة. عندما تسترد AWS تلك الموارد — وستفعل — تختفي الطاقة الكاملة دفعة واحدة. دائمًا هيئ ASG خاصة بـ Spot باستراتيجية capacity-optimized، وثلاثة عائلات instances على الأقل، واثنتين من AZs على الأقل. استخدم Mixed Instances Policy لدمج قاعدة On-Demand مع فائض Spot.

Instance Metadata Service (IMDS)

كل EC2 instance يمتلك نقطة نهاية HTTP محلية على 169.254.169.254 تقدم بياناته الوصفية: معرّف الـ instance، المنطقة، AZ، بيانات اعتماد دور IAM، User Data، وأكثر. التطبيقات التي تعمل على EC2 تستخدمها للتعرف على ذاتها بدون أي إعداد خارجي. استخدم دائمًا IMDSv2 (المحمي بـ token) في الإنتاج — IMDSv1 قابل للاستغلال عبر SSRF وهو السبب الجذري لعدة تسريبات بيانات اعتماد سحابية ضخمة.

# IMDSv2 — استخدم دائمًا التدفق المبني على token
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# استعلام عن هوية الـ instance
INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: ${TOKEN}" \
  http://169.254.169.254/latest/meta-data/instance-id)

AZ=$(curl -s -H "X-aws-ec2-metadata-token: ${TOKEN}" \
  http://169.254.169.254/latest/meta-data/placement/availability-zone)

INSTANCE_TYPE=$(curl -s -H "X-aws-ec2-metadata-token: ${TOKEN}" \
  http://169.254.169.254/latest/meta-data/instance-type)

echo "Instance ${INSTANCE_ID} | Type ${INSTANCE_TYPE} | AZ ${AZ}"

# فرض IMDSv2 عند الإطلاق (افعل هذا في Launch Template)
# aws ec2 modify-instance-metadata-options \
#   --instance-id i-0abc123 \
#   --http-tokens required \
#   --http-endpoint enabled

فرض IMDSv2 على مستوى المؤسسة باستخدام قاعدة AWS Config (ec2-imdsv2-check) وحجب IMDSv1 على مستوى Launch Template بضبط HttpTokens: required. إذا كنت تشغّل EKS، اضبط أيضًا HttpPutResponseHopLimit: 2 حتى تعمل استدعاءات IMDS من مستوى الـ pod بشكل صحيح عبر نقطة تبديل شبكة الحاوية.