sultanops

التكلفة والتصميم الجيد

2026-11-02T00:00:00Z

مشيت طريق طويل من الجزء الأول. في هذا الجزء الأخير نجاوب سؤالين ينطبقون على كل اللي بنيناه: كم يكلف؟ وهل هو مصمم صح؟ وبعدها نحول كل هذا لملف تقدر تعيد بناءه بأمر واحد.

وين تروح فلوس الشبكة؟

أغلب الناس يخططون للسيرفرات والتخزين، ثم يتفاجأون بنقل البيانات. والأسعار هنا تقريبية لمناطق أمريكا:

البيانات الداخلة إلى AWS مجانية، وداخل المنطقة بعناوين خاصة كمان. وتدفع لما تعبر حد: بين مناطق التوفر، أو بين المناطق، أو إلى الإنترنت.

الاتجاه	السعر التقريبي لكل GB
إلى AWS من الإنترنت	مجاني
داخل منطقة توفر واحدة بعناوين خاصة	مجاني
بين مناطق التوفر	0.01 دولار لكل اتجاه
بين المناطق	من حوالي 0.02 دولار، ويختلف حسب المنطقة
إلى الإنترنت	حوالي 0.09 دولار وينزل مع الكمية، وأول 100 GB في الشهر مجانية

الأرقام الصغيرة تتجمع بسرعة. ست أشياء تقللها:

استخدم العناوين الخاصة داخل الـ VPC بدل العامة، ولاحظ إن كل عنوان IPv4 عام عليه رسوم بالساعة كمان.
حط CloudFront قدام تطبيقك. البيانات من AWS إلى CloudFront مجانية، والخروج عبره أرخص من الخروج المباشر.
أضف Gateway Endpoint لـ S3 وDynamoDB. مجاني، ويوفر عليك رسوم NAT لكل GB.
NAT Gateway لكل منطقة توفر، عشان ما تعبر البيانات بين المناطق توصله.
قرّب الخدمات كثيرة الكلام. بس وازن هذا مع التوفر، لأن التوزيع بين المناطق يستاهل الدفع.
اضغط اللي ترسله، وخزنه مؤقتاً في أقرب مكان تقدر عليه.

وين الكاش؟

كل طبقة توفر الشغل على اللي وراها، فكل ما كان قدام كان أفضل، وشفناها كلها:

الطبقة	الأداة	توفر
الحافة	CloudFront	الرحلة كلها، للمحتوى اللي نفسه للكل
الـ API	كاش API Gateway	الدالة وقاعدة البيانات
التطبيق	ElastiCache	الاستعلامات والحسابات الثقيلة
قاعدة البيانات	DAX أو نسخة قراءة	القراءات من القاعدة الأساسية

أدوات تراقب فاتورتك

الأداة	وش تسوي
Cost Explorer	ترسم صرفك حسب الخدمة والحساب والوسم، وتتوقعه، وتوصي بـ Savings Plans
Budgets	تنبهك لما توصل حد أو يتوقع توصله، والمراقبة مجانية
Cost Anomaly Detection	تستخدم تعلم الآلة لكشف الصرف غير المعتاد، بدون رسوم
Cost Optimization Hub	تجمع توصيات التوفير في مكان واحد: تغيير الأحجام والموارد الخاملة وغيرها
Compute Optimizer	يوصي بالأحجام المناسبة حسب استخدامك الفعلي
Cost and Usage Report	أدق بيانات عن تكلفتك واستخدامك، توصلك كملفات في S3 تحللها. وAWS Data Exports ينشئ تصديرات مثلها بالأعمدة اللي تختارها

وأول خطوة هي الوسوم: بدون وسم env أو team، ما تعرف مين يصرف وش. والوسوم ما توصل لتقارير التكلفة إلا لما تفعّلها كـ Cost Allocation Tags في صفحة الفوترة.

توفير سريع

الإجراء	وين شفناه
صغّر السيرفرات الكبيرة زيادة	الجزء الثالث
التزم بـ Savings Plans، واستخدم Spot للي يتحمل الانقطاع	الجزء الرابع
أوقف سيرفرات التطوير بالليل، مثلاً بـ Instance Scheduler on AWS	هذا الجزء
قواعد دورة الحياة لـ S3	الجزء السادس عشر
حدد مدة حفظ للسجلات	الجزء الخامس والعشرين
احذف الأقراص واللقطات وموزعات الحمل المهملة	الجزء الخامس

إطار Well-Architected

AWS لخصت اللي تعلمته من عملائها في ست ركائز. اعتبرها مراجعة لأي تصميم:

الركيزة	السؤال	غطيناها في
التميز التشغيلي	تقدر تشغله وتحسنه؟	المراقبة والقوالب
الأمان	البيانات والوصول محمية؟	IAM والتشفير
الاعتمادية	ينجو من الأعطال ويتعافى؟	التوسع والتعافي
كفاءة الأداء	تستخدم الموارد المناسبة؟	الكاش واختيار القاعدة
تحسين التكلفة	تدفع على شي ما تحتاجه؟	هذا الجزء
الاستدامة	تقلل استهلاكك وأثره؟	الأحجام المناسبة وGraviton

والركائز تتعارض أحياناً: نسخ أكثر تعني اعتمادية أفضل وتكلفة أعلى. والهدف مو إنك توصل الأقصى في كل شي، بل إنك تختار وأنت فاهم.

AWS Well-Architected Tool: أداة مجانية في الكونسول تسألك عن شغلك وتبين المخاطر.
Trusted Advisor: يفحص حسابك مقابل أفضل الممارسات. في الخطة المجانية تاخذ حدود الخدمات وكم فحص للأمان والتحمل، والباقي يحتاج خطة دعم مدفوعة. ولاحظ إن AWS تغير خطط الدعم، وDeveloper وBusiness تنتهي في 1 يناير 2027 لصالح Business Support+.

CloudFormation: بنيتك في ملف

إلى الآن سوينا كل شي بيدنا أو بالأوامر. طيب لو تقدر توصف كل هذا في ملف؟ AWS CloudFormation يقرأ قالب (Template) ويبني Stack من الموارد بالترتيب الصحيح، و:

قابل للتكرار: نفس البيئة للتطوير والاختبار والإنتاج.
قابل للمراجعة: القالب في Git مثل الكود، وتراجع تغييراته.
تحت السيطرة: Change Set يبين وش بيتغير قبل ما يصير، وDrift Detection يكشف التعديلات اليدوية.
نظيف: حذف الـ Stack يحذف كل اللي فيه، فما يبقى شي يحاسبك.
مجاني: تدفع على الموارد اللي ينشئها فقط.

وInfrastructure Composer يخليك ترسم القالب بالواجهة، وAWS CDK يكتبه بـ Python أو TypeScript. وService Role يخلي المطور ينشر Stack بدون ما يكون عنده صلاحية على الموارد نفسها.

Systems Manager: تشغيل سيرفراتك

AWS Systems Manager يدير أساطيل السيرفرات عبر وكيل، مثبت أصلاً في Amazon Linux، ودور IAM:

الأداة	وش تسوي
Session Manager	طرفية بدون منفذ SSH وبدون مفاتيح، والجلسات تنسجل
Run Command	أمر واحد على ألف سيرفر
Patch Manager	يطبق التحديثات بجدول
Maintenance Windows	يحدد متى يسمح بهذي الأشياء
Automation	مستندات جاهزة لمهام معروفة، مثل معالجة Config

تطبيقات ما تقدر تغيرها

مو كل تطبيق ينكتب من جديد، وغالباً تقدر ترفع موثوقية التطبيق القديم من الخارج، بدون ما تلمس كوده:

المشكلة	الحل
سيرفر واحد ممكن يتعطل	مجموعة Auto Scaling بسيرفر واحد وفحص صحة، أو الاسترجاع التلقائي اللي يرجعه على عتاد جديد بنفس عناوينه
ضغط يرهقه	CloudFront قدامه، لكل اللي ينخزن
اتصالات كثيرة بقاعدة البيانات	RDS Proxy، ويحتاج نقطة وصول جديدة فقط
قاعدة بيانات ممكن تطيح	Multi-AZ، ونقطة الوصول تبقى نفسها
عملاء يسمحون لعناوين ثابتة في جدران الحماية	العنوانين الثابتين في Global Accelerator

خدمات تستاهل تعرفها

آخر مجموعة، وكل وحدة تستاهل سطر:

الخدمة	لوش
SES	إرسال الإيميل، للمعاملات والتسويق، مع حماية سمعتك
AWS Batch	شغل دفعات بأي حجم، على EC2 أو Fargate، بدون حد 15 دقيقة مثل Lambda
AWS Outposts	سيرفرات AWS في مركز بياناتك، لما لازم تبقى البيانات عندك
Amazon AppFlow	نقل البيانات من تطبيقات SaaS مثل Salesforce إلى S3 أو Redshift بدون كود
AWS Amplify	بناء واستضافة تطبيقات الويب والجوال بسرعة
Service Catalog	كتالوج خدمات معتمدة، فالفرق تنشر المسموح فقط
License Manager	يتابع تراخيص البرامج، مثل Oracle وSAP، عبر الحسابات
Device Farm	اختبار التطبيقات على جوالات وأجهزة لوحية حقيقية تستضيفها AWS

ولو قرأت مقالات قديمة، Amazon Pinpoint وصل لنهاية دعمه في 30 أكتوبر 2026. وAWS توجّه لـ SES للإيميل، ولـ AWS End User Messaging للرسائل النصية وإشعارات الجوال. وAWS Proton وصل كمان لنهاية دعمه في 7 أكتوبر 2026، مع إن دليل الاختبار لسا يذكره.

الحوسبة عالية الأداء

لما تحتاج آلاف المعالجات تشتغل مع بعض:

الحاجة	الأدوات
الحوسبة	Placement Group من نوع Cluster، مع Enhanced Networking أو EFA، وSpot لو أمكن
التخزين	FSx for Lustre وInstance Store وS3
التنسيق	AWS Batch أو AWS ParallelCluster
نقل البيانات	Direct Connect أو DataSync

عملي: Stack كامل من ملف، وميزانية بتبقيها

اكتب قالب صغير فيه حاوية وموضوع SNS. من CloudShell:

Bash

cat > stack.yaml <<'EOF'
AWSTemplateFormatVersion: "2010-09-09"
Description: A small stack from the AWS series
Parameters:
  Env:
    Type: String
    Default: dev
Resources:
  Files:
    Type: AWS::S3::Bucket
    Properties:
      VersioningConfiguration:
        Status: Enabled
      Tags:
        - Key: env
          Value: !Ref Env
  Alerts:
    Type: AWS::SNS::Topic
Outputs:
  BucketName:
    Value: !Ref Files
EOF

aws cloudformation deploy --stack-name series-stack --template-file stack.yaml

aws cloudformation describe-stack-resources --stack-name series-stack \
  --query "StackResources[].[LogicalResourceId,ResourceType,ResourceStatus]" \
  --output table

CloudFormation بنى الموردين وسماهم بنفسه. الحين غيّر قيمة وحدة. يحدث اللي تغيّر فقط، بدون ما يلمس الباقي:

Bash

aws cloudformation deploy --stack-name series-stack \
  --template-file stack.yaml --parameter-overrides Env=prod

BUCKET=$(aws cloudformation describe-stacks --stack-name series-stack \
  --query "Stacks[0].Outputs[0].OutputValue" --output text)

aws s3api get-bucket-tagging --bucket $BUCKET \
  --query "TagSet[?Key=='env'].Value" --output text

يطبع prod. الحين أحلى جزء، حذف كل شي بأمر واحد:

Bash

aws cloudformation delete-stack --stack-name series-stack
aws cloudformation wait stack-delete-complete --stack-name series-stack
echo "Everything is gone"

وأخيراً، شي تبقيه: ميزانية 10 دولار في الشهر تنبهك لما يتوقع تتجاوز 80% منها. بدّل الإيميل بإيميلك:

Bash

EMAIL=you@example.com
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)

cat > budget.json <<'EOF'
{
  "BudgetName": "series-monthly",
  "BudgetLimit": {"Amount": "10", "Unit": "USD"},
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}
EOF

cat > notify.json <<EOF
[{
  "Notification": {
    "NotificationType": "FORECASTED",
    "ComparisonOperator": "GREATER_THAN",
    "Threshold": 80,
    "ThresholdType": "PERCENTAGE"
  },
  "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "$EMAIL"}]
}]
EOF

aws budgets create-budget --account-id $ACCOUNT \
  --budget file://budget.json \
  --notifications-with-subscribers file://notify.json

aws budgets describe-budgets --account-id $ACCOUNT \
  --query "Budgets[].[BudgetName,BudgetLimit.Amount,BudgetLimit.Unit]" --output table

لو جاك AccessDenied، ممكن مستخدم IAM حقك يحتاج وصول للفوترة، وهذا يفعّله مستخدم Root من إعدادات الحساب.

الخلاصة

نقل البيانات هو التكلفة المخفية: بين مناطق التوفر، وبين المناطق، وإلى الإنترنت.
Budgets وCost Anomaly Detection ينبهونك قبل الفاتورة.
إطار Well-Architected ست ركائز، والفكرة إنك تختار وأنت فاهم.
CloudFormation يحول بنيتك إلى ملف تراجعه وتحذفه.
Systems Manager يدير سيرفراتك بدون SSH.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 7

سيرفرين EC2 في نفس منطقة التوفر يتبادلون تيرابايتات كل شهر عبر عناوين IP العامة لبعض، والنقل يطلع في الفاتورة. وش أبسط حل؟

اعرض الجواب

الجواب الصحيح: B

البيانات بين السيرفرات في منطقة توفر واحدة مجانية عبر العناوين الخاصة، والزيارات عبر العنوان العام مدفوعة.

A: عبور المناطق مدفوع في كل اتجاه.
C: الـ NAT Gateway يضيف رسم على كل جيجابايت.
D: حجم السيرفر ما يغير تكلفة النقل.

للمراجعة: وين تروح فلوس الشبكة؟ في هذا الجزء، وEC2 On-Demand Instance Pricing في موقع AWS.

السؤال 2 من 7

فريق صغير يبي إيميل لما يتوقع إن صرف AWS هذا الشهر بيتجاوز حده، مو بعد ما توصل الفاتورة. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

الميزانية تقدر تنبه على الصرف المتوقع والصرف الفعلي، والمراقبة نفسها مجانية.

B: هذا يرسم صرفك ويتوقعه، بس لازم أحد يروح يشوفه.
C: هذا يقترح الأحجام المناسبة، وما يرسل تنبيهات صرف.
D: هذا يسجل الإعدادات، مو الصرف.

للمراجعة: أدوات تراقب فاتورتك في هذا الجزء، وManaging your costs with AWS Budgets في وثائق AWS.

السؤال 3 من 7

فريق يبي يراجع تصميم تطبيق واحد مقابل أفضل ممارسات AWS، بالإجابة على أسئلة عنه ورؤية المخاطر. وش يناسب؟

اعرض الجواب

الجواب الصحيح: D

الأداة تسألك عن شغلك وتبين لك المخاطر، وهي مجانية في الكونسول.

A: هذا يفحص اللي تشغله عن الثغرات المعروفة، وما يراجع التصميم.
B: هذا يفحص موارد حسابك لحاله، وما يسأل عن تطبيق معين.
C: هذا يسجل مين نادى وش.

للمراجعة: إطار Well-Architected في هذا الجزء، وAWS Well-Architected Tool FAQs في موقع AWS.

السؤال 4 من 7

فريق يبي نفس البيئة في التطوير والإنتاج من ملف واحد في Git، ويشوف وش بيغيره التحديث قبل ما يصير، ويعرف لو عدّل أحد مورد يدوياً. وش يناسب؟

اعرض الجواب

الجواب الصحيح: C

القالب يبني نفس الـ Stack كل مرة ويبقى في Git. وChange Sets تبين وش بيتغير، وDrift Detection يكشف التعديلات اليدوية.

A: هذا يشغّل أوامر على السيرفرات، وما يوصف البنية.
B: هذا يكرر محتوى السيرفر، مو الشبكة والموارد اللي حوله.
D: هذا يسجل الإعدادات ويحكم عليها، بس ما يبني شي.

للمراجعة: CloudFormation: بنيتك في ملف في هذا الجزء، وUpdate CloudFormation stacks using change sets وDetect unmanaged configuration changes to stacks and resources with drift detection في وثائق AWS.

السؤال 5 من 7

شركة لازم تطبق تحديثات الأمان على 500 سيرفر EC2، في وقت محدد ليلة السبت فقط، وبدون وصول SSH. أي أداتين يناسبون؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: B + E

Patch Manager يطبق التحديثات، وMaintenance Windows يحدد متى يسمح لها تصير.

A: هذا يعطيك طرفية، جلسة وحدة كل مرة.
C: هذا يخزن الإعدادات والأسرار البسيطة.
D: هذا يقترح الأحجام المناسبة حسب استخدامك.

للمراجعة: Systems Manager: تشغيل سيرفراتك في هذا الجزء، وAWS Systems Manager Patch Manager وAWS Systems Manager Maintenance Windows في وثائق AWS.

السؤال 6 من 7

فريق مالية يبي تكلفة كل فريق في ملفات مفصلة يحللها بنفسه. والموارد فيها وسم team، بس الوسم ما يطلع في التقارير. أي خطوتين يناسبون؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: B + E

الوسوم ما توصل لتقارير التكلفة إلا بعد تفعيلها، وCost and Usage Report يوصّل أدق البيانات كملفات في S3.

A: هذا يسجل إعدادات الموارد، مو التكاليف.
C: هذا يقترح الأحجام المناسبة.
D: هذا يسجل العمليات داخل الموارد، مو التكاليف.

للمراجعة: أدوات تراقب فاتورتك في هذا الجزء، وWhat are AWS Cost and Usage Reports? وOrganizing and tracking costs using AWS cost allocation tags في وثائق AWS.

السؤال 7 من 7

تطبيق قديم يشتغل على سيرفر EC2 واحد، وعملاؤه يتصلون بعنوان السيرفر. والكود ما يتغير. ولو تعطل العتاد، لازم يرجع السيرفر لحاله بنفس عناوينه. وش يناسب؟

اعرض الجواب

الجواب الصحيح: C

الاسترجاع يرجع السيرفر على عتاد جديد، بنفس Instance ID وعناوينه الخاصة والعامة وElastic IP.

A: هذا إعادة كتابة، والكود ما يتغير.
B: البديل سيرفر جديد، بعناوين جديدة.
D: لازم ترجعه يدوياً، على سيرفر جديد بعناوين جديدة.

للمراجعة: تطبيقات ما تقدر تغيرها في هذا الجزء، وAutomatic instance recovery في وثائق AWS.

اللي تعلمته

تسعة وعشرين جزء في تسعة أقسام. شوف وش تقدر تسويه الحين:

القسم	الحين تقدر
الأساسيات	تفهم البنية العالمية وتضبط الصلاحيات
الخوادم وتخزينها	تشغل سيرفر، وتختار تسعيره، وتحفظ بياناته
التوفر العالي والتوسّع	تبني تطبيق ينجو من الأعطال ويكبر لحاله
قواعد البيانات	تختار القاعدة المناسبة وتسرعها
الشبكات وتوصيل المحتوى	تصمم شبكة خاصة وتوصل المحتوى حول العالم
التخزين الكائني	تخزن أي شي في S3 بالسعر المناسب وبأمان
التطبيقات الحديثة	تفصل الخدمات، وتشغل الحاويات وبدون خوادم
البيانات والذكاء الاصطناعي	تحلل بياناتك وتضيف الذكاء الاصطناعي لتطبيقك
الأمان والتشغيل	تراقب وتحمي وتتعافى وتضبط تكاليفك

وين تروح من هنا

ابن شي حقيقي. مشروع صغير خاص فيك يعلمك أكثر من أي مقال، حتى لو موقع صغير مع API.
جرّب الاختبار الشامل. يختار لك أسئلة عشوائية من كل الأجزاء، فتعرف وش ثبت عندك ووش تراجعه.
اقرأ الأسئلة الشائعة. صفحة FAQ لكل خدمة ملخص قصير وغني ودقيق.
فكر في شهادة. Solutions Architect Associate تغطي أغلب اللي في هذي السلسلة، والاختبار يقيس كيف تختار بين الخدمات. اقرأ كل سؤال بحثاً عن العبارة اللي تحسم، مثل "أقل تكلفة" أو "أقل جهد تشغيلي"، واستبعد الإجابات الغلط أول. ودليل الاختبار الرسمي يوضح كل المجالات والخدمات.
تابع التغييرات. AWS تتغير بسرعة، وكذا شي في هذي السلسلة تغير وهي تنكتب. راجع الوثائق قبل أي قرار.

شكراً إنك كملت للنهاية، وبالتوفيق في اللي بتبنيه.

التعافي من الكوارث والترحيل

2026-11-02T00:00:00Z

في الجزء السابع نجا تطبيقنا من فقدان منطقة توفر. بس لو الكارثة أكبر: منطقة كاملة طاحت، أو DELETE بالغلط، أو برنامج فدية؟ والنص الثاني من هذا الجزء: لو تطبيقك لسا مو على AWS، وتبي تجيبه؟

RPO وRTO

قبل أي قرار تقني، تحتاج رقمين من أصحاب العمل:

RPO يطالع لورا من الكارثة إلى آخر نسخة سليمة، وRTO يطالع لقدام إلى رجوع الخدمة.

الرقم	السؤال	مثال
RPO (Recovery Point Objective)	كم بيانات نقدر نخسر؟	نسخة كل ساعة تعني خسارة حتى ساعة بيانات
RTO (Recovery Time Objective)	كم نقدر نبقى واقفين؟	حتى أربع ساعات توقف

كل ما صغر الرقمين، ارتفعت التكلفة. فالسؤال مو "وش الأفضل؟"، بل "كم تسوى ساعة التوقف عندنا؟"

أربع استراتيجيات

هذي للتعافي في منطقة ثانية، مرتبة من الأرخص للأغلى. والفرق بينها كم شي شغال هناك قبل الكارثة:

وش شغال في المنطقة الثانية قبل الكارثة: كل ما كان الجاهز أكثر، كان التعافي أسرع والتكلفة أعلى.

الاستراتيجية	RPO تقريبي	RTO تقريبي	تناسب
Backup and Restore	ساعات	حتى 24 ساعة	الأنظمة غير الحرجة
Pilot Light	دقايق	عشرات الدقايق	البيانات الأساسية لازم تكون جاهزة دايماً
Warm Standby	ثواني	دقايق	أنظمة مهمة بميزانية محدودة
Multi-Site (نشط نشط)	قريب من الصفر	قريب من الصفر	لما دقيقة التوقف تكلف ثروة

Backup and Restore: نسخ تنتقل لمنطقة ثانية، وكل شي ينبني منها وقت الكارثة. والقوالب تساعد، زي ما بنشوف في الجزء الجاي.
Pilot Light: البيانات تتنسخ باستمرار، مثل Aurora Global Database أو نسخ S3، والسيرفرات جاهزة بس واقفة.
Warm Standby: نسخة كاملة صغيرة شغالة وتقدر تستقبل على طول، ثم تكبر بـ Auto Scaling.
Multi-Site: المنطقتين يخدمون المستخدمين طول الوقت، مثل Route 53 مع Global Tables.

نصائح تفرق

اختبر تعافيك. النسخة اللي ما رجعتها ولا مرة مجرد أمل. سوّ تدريبات، واستفد من AWS Fault Injection Service عشان تسبب أعطال متعمدة.
أتمت. ابن البيئة من قوالب، لأن وقت الكارثة ما أحد يتذكر الخطوات.
احمِ نسخك من نفسك. حطها في حساب ثاني ومنطقة ثانية، لأن المهاجم اللي يدخل حسابك بيبدأ فيها.
فكر في Elastic Disaster Recovery. AWS DRS ينسخ سيرفراتك باستمرار لتخزين رخيص، ويشغلها بس لما تحتاجها، بـ RPO ثواني وRTO دقايق.
راجع الحصص في منطقة الاحتياط. الحصص لكل منطقة، فالنسخة الصغيرة ممكن توصل حدها وقت ما تحتاج تكبر. ارفعها هناك قبلها من صفحة Service Quotas.

AWS Backup: كل شي في مكان واحد

كل خدمة لها نسخها، بس AWS Backup يديرها مركزياً، لـ EC2 وEBS وS3 وRDS وAurora وDynamoDB وEFS وFSx وغيرها:

الجزء	وش يسوي
Backup Plan	جدول ومدة حفظ، مثل يومي لـ 35 يوم، ثم انتقال لتخزين بارد
Vault	مكان حفظ النسخ، مشفرة بـ KMS
الوسوم	انسخ أي شي عليه `backup=daily`، فالموارد الجديدة تنضم لحالها
النسخ	لمنطقة ثانية أو حساب ثاني، لحماية حقيقية من الكوارث
Vault Lock	يمنع أي أحد، حتى Root في وضع Compliance، من حذف النسخ قبل انتهائها

وVault Lock أقوى دفاع عندك ضد برامج الفدية وضد اللي معه بيانات مدير مسروقة.

ترحيل قواعد البيانات: DMS

AWS DMS (Database Migration Service) ينقل قاعدة البيانات وهي مستخدمة: ينسخ البيانات الموجودة، ثم يستمر يرسل التغييرات (تعرف بـ CDC) لين تكون جاهز تحوّل.

النوع	مثال	الأدوات
نفس المحرك	MySQL على سيرفر إلى RDS for MySQL	DMS لحاله يكفي
محرك مختلف	Oracle إلى Aurora PostgreSQL	DMS Schema Conversion أو SCT لتحويل الجداول والكود أول، ثم DMS للبيانات

والمصادر والوجهات كثيرة، منها قواعد مكتبك وRDS وS3 وDynamoDB وRedshift وOpenSearch. ويقدر يشتغل بـ Multi-AZ مع نسخة احتياطية في منطقة ثانية، أو Serverless عشان ما تحتاج تحدد حجمه.

النقل إلى RDS أو Aurora

لو تنقل MySQL أو PostgreSQL، عندك طرق أبسط:

الطريقة	التوقف	متى
لقطة من RDS إلى Aurora	نعم، وقت النقل	التوقف مقبول
نسخة قراءة Aurora ثم ترقيتها	قصير جداً	من RDS بدون توقف حقيقي
نسخة من S3	نعم	من خارج RDS: Percona XtraBackup لـ MySQL
DMS	قصير جداً	نسخ مستمر من أي مكان

ترحيل السيرفرات ومراكز البيانات

تبي	استخدم
نقل السيرفرات زي ما هي (Lift and Shift)	AWS Transform MGN
استيراد صورة جهاز افتراضي واحد	VM Import/Export
نقل VMware زي ما هو	Amazon Elastic VMware Service، أو VMware Cloud on AWS من Broadcom
مساعدة في تخطيط ترحيل كبير	AWS Transform
نقل الملفات	DataSync
وضع تطبيقات Java أو .NET في حاويات	App2Container

AWS Transform MGN كان اسمه Application Migration Service لين 2026. وكيل على سيرفرك ينسخ أقراصه باستمرار إلى موارد AWS منخفضة التكلفة، وتجرب كم ما تبي، ثم تحوّل في دقايق. وغالباً هو أسرع طريق للخروج من مركز بيانات.

ولو عندك بيانات ضخمة، حسبناها في الجزء الثامن عشر.

عملي: احذف البيانات ورجعها

بنمثل كارثة صغيرة: جدول، ونسخة، وحذف بالغلط، ثم استعادة. من CloudShell، أنشئ الجدول بطلب واحد:

Bash

aws dynamodb create-table --table-name series-orders \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --query TableDescription.TableStatus

aws dynamodb wait table-exists --table-name series-orders

aws dynamodb put-item --table-name series-orders \
  --item '{"id":{"S":"1001"},"total":{"N":"120"}}'

TABLE_ARN=$(aws dynamodb describe-table --table-name series-orders \
  --query Table.TableArn --output text)

AWS Backup يحتاج دور وVault:

Bash

cat > trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "backup.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
EOF

ROLE_ARN=$(aws iam create-role --role-name series-backup-role \
  --assume-role-policy-document file://trust.json \
  --query Role.Arn --output text)

aws iam attach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup
aws iam attach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForRestores

aws backup create-backup-vault --backup-vault-name series-vault \
  --query BackupVaultName --output text

ابدأ النسخ، ثم انتظره. ولو جاك خطأ عن الدور، انتظر كم ثانية وأعد الأمر الأول. وهذا ياخذ عادةً كم دقيقة:

Bash

JOB=$(aws backup start-backup-job --backup-vault-name series-vault \
  --resource-arn $TABLE_ARN --iam-role-arn $ROLE_ARN \
  --query BackupJobId --output text)

while true; do
  STATE=$(aws backup describe-backup-job --backup-job-id $JOB \
    --query State --output text)
  echo $STATE
  case $STATE in COMPLETED|FAILED|ABORTED|EXPIRED) break ;; esac
  sleep 15
done

POINT=$(aws backup describe-backup-job --backup-job-id $JOB \
  --query RecoveryPointArn --output text)

الحين الكارثة. الطلب راح:

Bash

aws dynamodb delete-item --table-name series-orders \
  --key '{"id":{"S":"1001"}}'

aws dynamodb get-item --table-name series-orders \
  --key '{"id":{"S":"1001"}}'

الأمر الثاني ما يطبع شي. استعد النسخة إلى جدول جديد، ولاحظ الوقت اللي تاخذه، لأن هذا هو RTO الحقيقي حقك:

Bash

RESTORE=$(aws backup start-restore-job --recovery-point-arn $POINT \
  --iam-role-arn $ROLE_ARN \
  --metadata targetTableName=series-orders-restored,encryptionType=Default \
  --query RestoreJobId --output text)

while true; do
  STATE=$(aws backup describe-restore-job --restore-job-id $RESTORE \
    --query Status --output text)
  echo $STATE
  case $STATE in COMPLETED|FAILED|ABORTED) break ;; esac
  sleep 15
done

aws dynamodb get-item --table-name series-orders-restored \
  --key '{"id":{"S":"1001"}}' --query Item

الطلب رجع. وأي شي انكتب بعد النسخة ضاع، وهذا هو RPO حقك.

Bash

aws backup delete-recovery-point --backup-vault-name series-vault \
  --recovery-point-arn $POINT
aws backup delete-backup-vault --backup-vault-name series-vault

aws dynamodb delete-table --table-name series-orders \
  --query TableDescription.TableStatus
aws dynamodb delete-table --table-name series-orders-restored \
  --query TableDescription.TableStatus

aws iam detach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup
aws iam detach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForRestores
aws iam delete-role --role-name series-backup-role

الخلاصة

RPO البيانات اللي تخسرها، وRTO وقت توقفك، وأصحاب العمل يحددونهم.
الاستراتيجيات الأربع: النسخ، وPilot Light، وWarm Standby، وMulti-Site، والتكلفة ترتفع كل ما تحسنت.
AWS Backup يدير النسخ مركزياً، وVault Lock يحميها.
DMS ينقل قواعد البيانات وهي شغالة، وAWS Transform MGN ينقل السيرفرات.
اختبر تعافيك، وإلا ما عندك تعافي.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 6

شركة تاخذ نسخة احتياطية من قاعدتها كل ست ساعات، والاسترجاع الكامل ياخذ ساعتين. في أسوأ حالة، كم الـ RPO والـ RTO عندها؟

اعرض الجواب

الجواب الصحيح: D

الـ RPO هو البيانات اللي ممكن تخسرها، وهي حتى الست ساعات من آخر نسخة. والـ RTO هو وقت التوقف، وهو ساعتين الاسترجاع.

A: هذا يبدل الرقمين.
B: الرقمين يقيسون شيئين مختلفين، فما ينجمعون.
C: أي شي انكتب بعد آخر نسخة يضيع، فالـ RPO مو صفر.

للمراجعة: RPO وRTO في هذا الجزء، وBusiness Continuity Plan (BCP) في وثائق AWS.

السؤال 2 من 6

تطبيق لازم يرجع في Region ثانية خلال ساعة ويخسر دقايق من البيانات فقط، بأقل تكلفة تحقق هذا. أي استراتيجية تناسب؟

اعرض الجواب

الجواب الصحيح: B

Pilot Light يبقي البيانات تتنسخ باستمرار والسيرفرات جاهزة بس واقفة، وهذا يرجعك خلال عشرات الدقايق بتكلفة تشغيل قليلة.

A: الاسترجاع ممكن ياخذ حتى 24 ساعة، وبتخسر ساعات من البيانات.
C: هذا يحقق المطلوب كمان، بس بتدفع على نسخة كاملة شغالة طول الوقت.
D: هذا يحققه كمان، بأعلى تكلفة بفارق كبير.

للمراجعة: أربع استراتيجيات في هذا الجزء، وDisaster recovery options in the cloud في وثائق AWS.

السؤال 3 من 6

شركة خايفة من برامج الفدية: مهاجم معه بيانات مدير مسروقة ممكن يحذف نسخها الاحتياطية. أي خطوة تحميها أكثر؟

اعرض الجواب

الجواب الصحيح: A

في وضع Compliance ما أحد يقدر يحذف نسخة قبل انتهائها، ولا حتى المستخدم الجذر.

B: المدير يقدر يغير السياسة ببساطة.
C: النسخ المشفرة لسا ممكن تنحذف.
D: بتعرف عن الحذف، بس النسخ بتكون راحت.

للمراجعة: AWS Backup: كل شي في مكان واحد في هذا الجزء، وAWS Backup Vault Lock في وثائق AWS.

السؤال 4 من 6

شركة تبي تنقل 200 سيرفر من مركز بياناتها إلى AWS زي ما هي، وتختبرها هناك كل ما تبي، وتنتقل خلال دقايق. وش يناسب؟

اعرض الجواب

الجواب الصحيح: C

Agent على كل سيرفر ينسخ أقراصه باستمرار إلى AWS، فتقدر تختبر براحتك، ثم تنتقل خلال دقايق.

A: هذا ينقل قواعد البيانات، مو السيرفرات كاملة.
B: هذا ينقل الملفات.
D: هذا يستورد صور أجهزة افتراضية، بدون نسخ مستمر.

للمراجعة: ترحيل السيرفرات ومراكز البيانات في هذا الجزء، وWhat Is AWS Transform MGN? في وثائق AWS.

السؤال 5 من 6

شركة تنقل قاعدة Oracle مشغولة إلى Aurora PostgreSQL، بتوقف قليل جداً. أي أداتين تحتاج؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: C + E

المحركين مختلفين، فتتحول الجداول والكود أول. ثم DMS ينسخ البيانات ويستمر يرسل التغييرات لين تكون جاهز للانتقال.

A: هذا ينقل السيرفرات زي ما هي، فتبقى القاعدة على Oracle.
B: هذا ينقل الملفات، وما يقدر يبقي قاعدة شغالة متزامنة.
D: نسخ قراءة Aurora تجي من RDS for MySQL أو PostgreSQL، مو من Oracle.

للمراجعة: ترحيل قواعد البيانات: DMS في هذا الجزء، وWhat is AWS Database Migration Service? وConverting database schemas using DMS Schema Conversion في وثائق AWS.

السؤال 6 من 6

في تجربة تعافي، نسخة Warm Standby في منطقة ثانية بدأت تكبر، بس السيرفرات الجديدة فشلت بسبب حد في الحساب أقل هناك من المنطقة الرئيسية. وش يسوي الفريق؟

اعرض الجواب

الجواب الصحيح: A

الحصص لكل منطقة، فمنطقة الاحتياط لازم تكون حدودها كافية لسعة الإنتاج قبل الكارثة. وترفعها من صفحة Service Quotas.

B: هذا يشغّل أقل من كذا، وبيوصل لنفس الحد لما يكبر.
C: هذا يحمي البيانات، وما يغير الحد.
D: الحصص لكل منطقة، فهذا ما يفيد منطقة الاحتياط.

للمراجعة: نصائح تفرق في هذا الجزء، وDisaster recovery options in the cloud وWhat is Service Quotas? في وثائق AWS.

تطبيقك الحين مبني ومحمي وقابل للتعافي. يبقى سؤال أخير: كم يكلف، وهل هو مصمم صح؟ في الجزء التاسع والعشرين نختم السلسلة بالتكلفة والتصميم الجيد.

التشفير والأسرار والحماية من الهجمات

2026-11-02T00:00:00Z

في الجزء السادس والعشرين ضبطنا مين يدخل. هذا الجزء يفترض الأسوأ: قرص ينسرق، أو كلمة مرور تتسرب، أو أحد يهاجم موقعك. وش يحميك وقتها؟

تبي	استخدم
مفاتيح تشفير تتحكم فيها	KMS
إعدادات وأسرار بسيطة	Parameter Store
كلمات مرور تتغير لحالها	Secrets Manager
شهادات HTTPS	ACM
صد هجمات الويب	WAF
تحمل هجمات DDoS	Shield
كشف التهديدات في حسابك	GuardDuty
إيجاد الثغرات في اللي تشغله	Inspector
إيجاد البيانات الحساسة في S3	Macie

AWS KMS: خزنة المفاتيح

شفنا أنواع التشفير في S3. وخلف أغلبها KMS (Key Management Service): المفاتيح تنشأ وتنستخدم داخله وما تطلع منه بدون تشفير، والوصول تحكمه السياسات، وكل استخدام ينسجل في CloudTrail.

التشفير بالمظروف (Envelope Encryption)

KMS ما يشفر ملفاتك الكبيرة بنفسه. يسوي مفتاح بيانات يشفر الملف، ويشفر مفتاح البيانات هذا بمفتاحك الرئيسي:

مفتاح البيانات يشفر الملف، ونسخة مشفرة منه تنحفظ جنب الملف. وKMS بس يقدر يفتح هذي النسخة، فالملف ما له فايدة بدون صلاحية.

فحتى اللي يسرق القرص ياخذ بيانات مشفرة وجنبها مفتاح مشفر. وعشان تفك التشفير، تحتاج صلاحية تطلب من KMS يفتح مفتاح البيانات، وهنا مكان تحكمك.

أنواع المفاتيح

النوع	مين يتحكم فيه	التكلفة الشهرية	التدوير
AWS Owned	AWS، وما تشوفه أبداً	مجاني	من الخدمة
AWS Managed (مثل `aws/ebs`)	AWS، وتقدر تشوفه وتدقق عليه	مجاني	سنوي وما يتغير
Customer Managed	أنت بالكامل	دولار للمفتاح، مع استدعاءات API	اختياري، سنوي افتراضياً، أو من 90 إلى 2,560 يوم

وأغلب المفاتيح متماثلة (Symmetric)، مفتاح واحد للتشفير وفكه وما يطلع من KMS. وفيه أزواج غير متماثلة (Asymmetric)، يطلع منها المفتاح العام، للتوقيع أو لتشفير من أطراف خارج AWS.

وحذف المفتاح ما له رجعة، لأنه يدمر كل شي مشفر به. فـ KMS يفرض فترة انتظار من 7 إلى 30 يوم، تقدر تلغي خلالها. وعشان توقف استخدام المفتاح بالأثناء، عطّله.

سياسات المفاتيح

كل مفتاح KMS له Key Policy، وعلى عكس الموارد الثانية، IAM لحاله ما يكفي بدونها. والسياسة الافتراضية تخلي سياسات IAM في الحساب تعطي الوصول للمفتاح.

وهذا مهم لما تنسخ بيانات مشفرة:

لمنطقة ثانية: المفاتيح خاصة بالمنطقة، فنسخ اللقطة يعيد تشفيرها بمفتاح في منطقة الوجهة.
لحساب ثاني: شارك اللقطة، واسمح لذاك الحساب في سياسة مفتاح Customer Managed. مفاتيح AWS Managed، مثل aws/ebs، ما تنشارك، فاللقطة المشفرة بها لازم تنسخها أول بمفتاحك.

المفاتيح متعددة المناطق

Multi-Region Keys تتشارك نفس مادة المفتاح ومعرفه بين المناطق، فاللي انشفر في منطقة ينفك في ثانية بدون إعادة تشفير. وهي مو لكل شي، لأن AWS توصي بمفاتيح المنطقة الواحدة افتراضياً. وتناسب حالات مثل تشفير حقل من جهة العميل في Global Tables أو Aurora Global.

CloudHSM: عتادك الخاص

في KMS، AWS تدير العتاد اللي يحفظ مفاتيحك. ولو فيه تنظيم يفرض وحدة أمان عتادية مخصصة لك، AWS CloudHSM يعطيك مجموعة HSM لك وحدك ومعتمدة بمعيار FIPS. وAWS تتكفل بالتجهيز والنسخ الاحتياطي، وأنت تتحكم في المفاتيح والمستخدمين بنفسك. فاختره بس لما تحتاجه، لأن مسؤوليتك أكبر من KMS.

وين تحفظ كلمات المرور؟

مو في الكود، ولا في Git. عندك خدمتين:

	Parameter Store	Secrets Manager
يناسب	إعدادات وأسرار بسيطة	أسرار لازم تتغير
التشفير	اختياري بـ KMS عبر `SecureString`	دايماً بـ KMS
التدوير	مو مبني فيه	مبني فيه بدالة Lambda، ومتكامل مع RDS وAurora
نسخ في مناطق ثانية	لا	نعم
السعر	Standard مجاني	0.40 دولار للسر في الشهر، مع استدعاءات API

Parameter Store

أسماؤه تكوّن شجرة، مثل /shop/prod/db-url، فالتطبيق يقدر يجيب مسار كامل، وIAM يقدر يسمح بـ /shop/prod/* فقط.

	Standard	Advanced
أقصى حجم	4 KB	8 KB
العدد في المنطقة	10,000	100,000
سياسات مثل الانتهاء	لا	نعم
السعر	مجاني	0.05 دولار للقيمة في الشهر

Secrets Manager

الفكرة هنا التدوير: كلمة المرور تتغير بجدول تحدده، والدالة تحدثها في قاعدة البيانات كمان. وتطبيقك يطلب القيمة الحالية كل مرة، فما يحس. وشفنا في الجزء الثامن إن RDS يقدر يدير كلمة مروره هنا لك.

ACM: شهادات بدون وجع راس

AWS Certificate Manager يصدر شهادات TLS عامة مجاناً لما تنستخدم مع خدمات مثل موزعات الحمل وCloudFront وAPI Gateway، ويجددها لحاله.

التحقق: أثبت ملكية النطاق عبر DNS، والأفضل مع Route 53، أو عبر الإيميل.
الصلاحية: الشهادات العامة تدوم الحين 198 يوم، حسب قواعد الصناعة الجديدة، والتجديد يصير تلقائياً قبل الانتهاء بحوالي 45 يوم. والفترة بتقصر أكثر في السنين الجاية، وهذا سبب زيادة تخليها للأتمتة.
الشهادات المستوردة: تقدر تستورد شهاداتك، بس ACM ما يجددها، فحط تنبيه على انتهائها.
سيرفراتك: شهادة ACM العادية ما تنثبت على سيرفرك. ولو تحتاج هذا، فيه شهادات قابلة للتصدير برسوم.

صد الهجمات

هذا كيف تقعد طبقات الحماية مع بعض في تصميم معتاد:

الهجمات تنمتص عند الحافة، وSecurity Group لموزع الحمل يقبل من CloudFront فقط، فما أحد يقدر يلتف عليه.

الخدمة	الطبقة	وش تسوي	التكلفة
WAF	التطبيق (7)	قواعد على الطلبات: SQL Injection وXSS والدولة وقوائم IP وحدود المعدل	لكل قاعدة وطلب
Shield Standard	الشبكة (3 و4)	حماية من هجمات DDoS المعروفة	مجاني وتلقائي
Shield Advanced	حتى 7	فريق استجابة متخصص، وحماية التكلفة وقت الهجوم	اشتراك شهري وهو غالي
Firewall Manager	الإدارة	يطبق قواعد WAF وShield وSecurity Groups وغيرها على كل حسابات منظمتك	لكل سياسة

وWAF ينربط بـ CloudFront وALB وAPI Gateway وAppSync، بس مو بموزع NLB. ولو تحتاج IP ثابت مع WAF، حط Global Accelerator قدام موزع الحمل. والقواعد حسب المعدل بسيطة وفعالة: احجب أي عنوان يرسل أكثر من عدد محدد من الطلبات.

تحمل DDoS

الأجزاء السابقة أعطتك أغلب المطلوب:

CloudFront وRoute 53 يمتصون الهجمات عند الحافة، بعيد عن سيرفراتك.
Auto Scaling يكبر لو عدى شي، بس انتبه للتكلفة.
Security Group يسمح لموزع الحمل من CloudFront فقط، فما أحد يتخطاه.
WAF بحدود المعدل وBot Control للهجمات اللي تشبه الطلبات العادية.

حجب عنوان واحد: وين؟

تصميمك	وين تحجب	ليه
EC2 بـ IP عام	Network ACL	Security Groups تسمح فقط، وما تقدر تمنع
موزع حمل	Network ACL على الـ Subnet حقه، أو WAF	السيرفر يشوف موزع الحمل فقط
CloudFront قدامه	WAF على CloudFront، أو القيود الجغرافية	Network ACL ما يفيد، لأن الطلبات توصل من عناوين CloudFront

وللحماية عند حدود الـ VPC، فيه Network Firewall اللي غطيناه في الجزء الرابع عشر.

كشف التهديدات

المنع مو كل شي. تحتاج كمان شي يقول لك لما يكون فيه مشكلة:

الخدمة	السؤال اللي تجاوبه	تشتغل من
GuardDuty	فيه شي مشبوه يصير في حسابي؟	CloudTrail وVPC Flow Logs وسجلات DNS، بدون Agents
Inspector	اللي أشغله فيه ثغرات معروفة؟	سيرفرات EC2 وصور ECR ودوال Lambda
Macie	فيه بيانات حساسة في مكان ما لازم تكون فيه؟	S3
Security Hub	كيف أماني بشكل عام؟	يجمع نتائج الباقين ويرتبها
Detective	ليه صارت هذي النتيجة؟	يجمع السجلات لحاله ويربطها، عشان تلقى السبب الجذري

GuardDuty يكشف أشياء مثل تعدين العملات، أو بيانات دخول مستخدمة من مكان غريب. وأرسل نتائجه عبر EventBridge إلى SNS أو Lambda عشان تتصرف. وتشغيله بضغطة وحدة، فشغله من البداية في أي حساب جاد، وله فترة تجربة مجانية.

مستندات الامتثال: AWS Artifact

مدقق يطلب إثبات إن AWS نفسها ملتزمة بمعايير ISO أو PCI؟ AWS Artifact يعطيك هذي التقارير وقت ما تبي ومجاناً، ومنه كمان تراجع اتفاقياتك مع AWS وتقبلها. وهو يغطي جانب AWS من المسؤولية المشتركة، أما جانبك فإثباته عليك.

عملي: مفتاح وقيمة وسر

من CloudShell، أنشئ مفتاح باسم سهل، وشفر نص:

Bash

KEY_ID=$(aws kms create-key --description "Series demo key" \
  --query KeyMetadata.KeyId --output text)
aws kms create-alias --alias-name alias/series-demo --target-key-id $KEY_ID

CIPHER=$(aws kms encrypt --key-id alias/series-demo \
  --plaintext "my secret note" --cli-binary-format raw-in-base64-out \
  --query CiphertextBlob --output text)

echo $CIPHER

بتشوف نص ما ينقرأ. فك تشفيره. وللمفتاح المتماثل، ما يلزم تحدد أي مفتاح:

Bash

aws kms decrypt --ciphertext-blob "$CIPHER" \
  --query Plaintext --output text | base64 -d; echo

الحين شوف وين التحكم الحقيقي. عطّل المفتاح، وجرب مرة ثانية:

Bash

aws kms disable-key --key-id $KEY_ID

aws kms decrypt --ciphertext-blob "$CIPHER" \
  --query Plaintext --output text

aws kms enable-key --key-id $KEY_ID

بيجيك DisabledException. البيانات ما تغيرت، بس ما لها فايدة بدون المفتاح. الحين احفظ كلمة مرور في Parameter Store، مشفرة بنفس المفتاح، واقرأها مع فك التشفير وبدونه:

Bash

aws ssm put-parameter --name /series/prod/db-password \
  --type SecureString --key-id alias/series-demo --value "S3cret-pass"

aws ssm get-parameter --name /series/prod/db-password \
  --query Parameter.Value --output text

aws ssm get-parameter --name /series/prod/db-password --with-decryption \
  --query Parameter.Value --output text

aws ssm get-parameters-by-path --path /series/prod \
  --query "Parameters[].Name"

وسر في Secrets Manager، بالطريقة اللي يقرأه فيها تطبيقك:

Bash

aws secretsmanager create-secret --name series/api-key \
  --secret-string '{"key":"abc123"}' --query Name --output text

aws secretsmanager get-secret-value --secret-id series/api-key \
  --query SecretString --output text

وأخيراً، وش خلّى كل هذا وراه؟ CloudTrail سجل مين استخدم المفتاح، بس ممكن ياخذ كم دقيقة:

Bash

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=Decrypt \
  --max-results 3 --query "Events[].[EventName,Username,EventTime]" --output table

Bash

aws secretsmanager delete-secret --secret-id series/api-key \
  --force-delete-without-recovery
aws ssm delete-parameter --name /series/prod/db-password
aws kms delete-alias --alias-name alias/series-demo
aws kms schedule-key-deletion --key-id $KEY_ID --pending-window-in-days 7

الخلاصة

KMS يحفظ مفاتيحك، ويستخدم التشفير بالمظروف، ويسجل كل استخدام.
المفاتيح خاصة بالمنطقة، ومفاتيح AWS Managed ما تنشارك بين الحسابات.
Parameter Store للإعدادات، وSecrets Manager للي لازم يتغير.
شهادات ACM مجانية وتتجدد لحالها، وCloudFront يحتاجها في us-east-1.
WAF وShield يصدون الهجمات، وGuardDuty وInspector وMacie يكشفون اللي يعدي.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 7

كلمة مرور قاعدة بيانات تطبيق لازم تتغير كل 30 يوم، في القاعدة وفي المكان اللي يقرأ منه التطبيق، بدون إصدار كود كل مرة. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

Secrets Manager يغير كلمة المرور بجدول ويحدثها في القاعدة كمان. والتطبيق يطلب القيمة الحالية كل مرة، فما يحس.

B: هذا يخزن القيمة مشفرة، بس ما فيه تدوير مبني.
C: هذا يدوّر مفتاح تشفير، مو كلمة مرور قاعدة بيانات.
D: لازم أحد يغيرها يدوي على كل سيرفر.

للمراجعة: Secrets Manager في هذا الجزء، وRotate AWS Secrets Manager secrets في وثائق AWS.

السؤال 2 من 7

فريق يبي يشارك لقطة EBS مشفرة مع حساب ثاني، بس اللقطة مشفرة بمفتاح aws/ebs. وش يسوي؟

اعرض الجواب

الجواب الصحيح: C

مفاتيح AWS Managed ما تنشارك، فلازم ينعاد تشفير اللقطة بمفتاحك أول. وبعدها الحساب الثاني يحتاج وصول للقطة وللمفتاح.

A: مفاتيح AWS Managed ما تنشارك مع حسابات ثانية.
B: اللقطات غير المشفرة بس هي اللي تنشارك للعامة، وهذا بيكشف البيانات لأي أحد.
D: اللقطة المشفرة ما تتحول ببساطة إلى غير مشفرة.

للمراجعة: سياسات المفاتيح في هذا الجزء، وShare an Amazon EBS snapshot with other AWS accounts في وثائق AWS.

السؤال 3 من 7

موقع يشتغل على ALB في فرانكفورت وقدامه CloudFront. والفريق طلب شهادة ACM في فرانكفورت، بس ما يقدر يختارها في CloudFront. وش يسوي؟

اعرض الجواب

الجواب الصحيح: D

CloudFront يحتاج شهادته في us-east-1، وين ما كان تطبيقك. والـ ALB يستمر يستخدم اللي في منطقته.

A: شهادة ACM العادية ما تتصدر.
B: التطبيق يقدر يبقى مكانه، وشهادة CloudFront بس هي اللي لازم تكون هناك.
C: التجديد ما يغير منطقة الشهادة.

للمراجعة: ACM: شهادات بدون وجع راس في هذا الجزء، وRequirements for using SSL/TLS certificates with CloudFront في وثائق AWS.

السؤال 4 من 7

موقع خلف CloudFront، وعنوان واحد يغرقه بالطلبات. وين يحجب الفريق هذا العنوان؟

اعرض الجواب

الجواب الصحيح: B

CloudFront أول من يشوف عنوان الزائر، فالحجب مكانه هناك. وIP Set أو قاعدة حسب المعدل في WAF تسوي المطلوب.

A: الطلبات توصل الشبكة من عناوين CloudFront، فعنوان المهاجم ما يظهر هناك أبداً.
C: مجموعة الأمان تسمح فقط، وما تقدر تمنع.
D: هذي حماية تلقائية من هجمات الشبكة الشائعة، بدون قوائم عناوين خاصة فيك.

للمراجعة: حجب عنوان واحد: وين؟ في هذا الجزء، وUsing AWS WAF with Amazon CloudFront في وثائق AWS.

السؤال 5 من 7

شركة تبي تلقى الثغرات البرمجية المعروفة في سيرفرات EC2 وصور ECR حقتها، وتلقى البيانات الشخصية الموجودة في حاويات S3. أي خدمتين يناسبون؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: A + E

Inspector يفحص اللي تشغله عن الثغرات المعروفة، وMacie يلقى البيانات الحساسة في S3.

B: هذا يكشف النشاط المشبوه في الحساب، مثل استخدام صلاحيات مسروقة.
C: هذا يحمي من هجمات DDoS.
D: هذا يفلتر طلبات الويب.

للمراجعة: كشف التهديدات في هذا الجزء، وWhat is Amazon Inspector? وWhat is Amazon Macie? في وثائق AWS.

السؤال 6 من 7

جهة تنظيمية تطلب إن مفاتيح تشفير بنك تكون في وحدة أمان عتادية له وحده، معتمدة بمعيار FIPS، ويتحكم فيها البنك وحده. وش يناسب؟

اعرض الجواب

الجواب الصحيح: C

CloudHSM يعطيك مجموعة HSM مخصصة لك، وأنت تتحكم في المفاتيح والمستخدمين بنفسك.

A: AWS تدير هذا المفتاح والعتاد، وما تقدر تغير صلاحياته.
B: أنت تتحكم في سياسة هذا المفتاح، بس AWS تدير العتاد اللي وراه.
D: هذا يحفظ أسرار مثل كلمات المرور، وهو مو وحدة عتادية.

للمراجعة: CloudHSM: عتادك الخاص في هذا الجزء، وWhat is AWS CloudHSM? في وثائق AWS.

السؤال 7 من 7

مدقق يطلب من شركة تقرير امتثال PCI الخاص بـ AWS. وفريق الأمان يحتاج يحقق في السبب الجذري لنتيجة من GuardDuty. أي خدمتين يناسبون؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: A + D

Artifact يعطيك تقارير امتثال AWS وقت ما تبي، وDetective يربط السجلات عشان تلقى السبب الجذري للنتيجة.

B: هذا يلقى البيانات الحساسة في S3.
C: هذا يسجل إعدادات مواردك ويحكم عليها، مو امتثال AWS.
E: هذا يدور الثغرات المعروفة في اللي تشغله.

للمراجعة: مستندات الامتثال: AWS Artifact وكشف التهديدات في هذا الجزء، وWhat is AWS Artifact? وWhat is Amazon Detective? في وثائق AWS.

حميت نفسك من الناس. طيب لو طاحت منطقة كاملة، أو لازم تنقل مركز بيانات إلى AWS؟ في الجزء الثامن والعشرين نغطي التعافي من الكوارث والترحيل.

الهوية المتقدمة: Organizations وIdentity Center

2026-11-02T00:00:00Z

في الجزء الثاني كان عندنا حساب واحد وكم مستخدم. الحين تخيل شركة فيها خمسين حساب وخمسمية موظف: إنشاء مستخدم في كل حساب لكل شخص بيكون كابوس، وغلطة وحدة ممكن توصل لكل شي.

هذا الجزء يغطي أدوات هذا الحجم، ويكمل IAM باللي تركناه في البداية.

AWS Organizations

Organizations يجمع عدة حسابات تحت حساب إدارة واحد، مرتبة في وحدات تنظيمية (OUs).

الحسابات تقعد في وحدات تنظيمية تحت جذر واحد، والسياسة المربوطة بوحدة تنطبق على كل الحسابات تحتها.

ليه حسابات كثيرة، مو حساب واحد كبير؟

العزل: غلطة أو اختراق في حساب التطوير ما توصل للإنتاج.
تكاليف واضحة: كل حساب يبين فاتورة فريقه.
الحدود: كل حساب له حصص خدماته.

ووش تكسب من Organizations؟

فاتورة موحدة: فاتورة وحدة، والاستخدام المجمع يوصل لخصومات الكمية أسرع. وSavings Plans وReserved Instances ممكن تتشارك بين الحسابات.
إدارة مركزية: إنشاء حسابات عبر API، وCloudTrail Trail واحد للكل.
السياسات: قواعد تنطبق على مجموعات كاملة من الحسابات.

سياسات المنظمة

السياسة	وش تسوي
SCP	تحدد أقصى ما يقدر يسويه المستخدمين والأدوار في الحساب
RCP	تحدد أقصى ما ينعمل على موارد الحساب
Declarative Policies	تثبت إعدادات أساسية لخدمة عبر الحسابات
Tag Policies	توحد الوسوم، مثل فرض كتابة معينة لـ `CostCenter`

Service Control Policies (SCP)

النقطة الأهم: SCP ما تعطي أي شي. تحدد سقف بس، وكل مستخدم لسا يحتاج صلاحية IAM. هي سقف على المسموح:

لما تنربط بـ OU تنطبق على كل اللي تحتها، ولازم كل مستوى يسمح بالإجراء.
ما تأثر على حساب الإدارة، فلا تشغّل شغلك فيه.
تنطبق على الكل في الحساب العضو، ومعهم Root حق الحساب.

مثلاً هذي الـ SCP تمنع الشغل خارج منطقتين، إلا الخدمات العالمية:

JSON

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "OnlyTwoRegions",
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "route53:*", "cloudfront:*", "support:*"],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["me-central-1", "eu-west-1"] }
    }
  }]
}

الشروط في سياسات IAM

عنصر Condition في السياسة يضيق متى تنطبق الصلاحية. وهذي أشهرها:

الشرط	الاستخدام
`aws:SourceIp`	من شبكة المكتب فقط
`aws:RequestedRegion`	في مناطق محددة فقط
`aws:MultiFactorAuthPresent`	فقط لو سجل الدخول بـ MFA
`aws:ResourceTag` و`aws:PrincipalTag`	لازم وسم المستخدم يطابق وسم المورد
`aws:PrincipalOrgID`	من حسابات منظمتك فقط

والأخير هدية للحاويات المشتركة. بدل ما تعدد خمسين حساب في سياسة الحاوية، سطر واحد يسمح لمنظمتك كلها:

JSON

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::shared-files/*",
  "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-a1b2c3d4e5" } }
}

غلطة S3 الكلاسيكية

إجراءات S3 تشتغل على مستويين، وكل واحد يحتاج ARN خاص فيه:

الإجراء	ينطبق على	ARN
`s3:ListBucket`	الحاوية	`arn:aws:s3:::my-bucket`
`s3:GetObject`	الكائن	`arn:aws:s3:::my-bucket/*`

حط الغلط ويجيك AccessDenied، مهما بدت السياسة صحيحة. وبنجرب هذا في التجربة العملية.

دور أو سياسة مورد؟

عشان تخلي مستخدم في حساب A يوصل لشي في حساب B، عندك طريقين:

	تقمص دور	سياسة مورد
كيف	المستخدم يصير الدور في B	المورد في B يسمح للمستخدم مباشرة
صلاحياته الأصلية	يتركها طول ما هو في الدور	يحتفظ فيها
يناسب	الشغل بالكامل داخل الحساب الثاني	القراءة من جدول في A والكتابة في حاوية في B بنفس الوقت
متاح في	كل الخدمات	اللي تدعمها فقط، مثل S3 وSNS وSQS وLambda

ووراء كل دور تفترضه خدمة AWS STS (Security Token Service). هي اللي تعطي الصلاحيات المؤقتة، وتنتهي لحالها. وبهذي الطريقة يشتغل الوصول بين الحسابات بدون مشاركة مفاتيح طويلة المدى: مستخدم أو خدمة تنادي AssumeRole، وSTS تفحص سياسة الثقة في الدور، وترجع مفاتيح تشتغل فترة محدودة.

حدود الصلاحيات (Permissions Boundaries)

تبي قادة الفرق ينشئون أدوار لخدماتهم، بدون ما يقدرون يعطون أحد أكثر مما لازم. Permissions Boundary يحدد الحد الأقصى لمستخدم أو دور معين، ومثل SCP ما يعطي شي.

والصلاحية الفعلية هي المسموح في سياسة الهوية والحد وSCP مع بعض. وهي طريقة ممتازة للتفويض بأمان.

كيف تقرر AWS؟

كل طلب يمر بهذا التفكير. وهذي نسخة مبسطة:

صورة مبسطة لقرار AWS: أي منع صريح ينهي الموضوع، وكل طبقة تنطبق لازم تسمح بالإجراء.

تذكر ثلاث قواعد: المنع الصريح يكسب دايماً، وأي شي غير مسموح ممنوع، وداخل الحساب الواحد، سياسة المورد تقدر تعطي الوصول لحالها في حالات كثيرة.

IAM Identity Center: دخول واحد

بدل مستخدم في كل حساب، IAM Identity Center يعطي كل موظف دخول واحد وبوابة فيها الحسابات والأدوار المتاحة له، وياخذ بيانات دخول مؤقتة بدون مفاتيح دائمة.

الجزء	وش يسوي
مصدر الهوية	دليله الخاص، أو Active Directory، أو مزود خارجي مثل Okta أو Microsoft Entra ID
Permission Sets	مجموعة سياسات تصير دور في كل حساب تربطها فيه
الربط	"مجموعة المطورين تاخذ Admin على حساب التطوير، وReadOnly على الإنتاج"
التطبيقات	دخول موحد لتطبيقات SAML كمان

وللـ CLI، الأمر aws configure sso يسجل دخولك عبر المتصفح ويعطيك بيانات مؤقتة. وهذي الطريقة الموصى فيها للناس عشان يشتغلون مع AWS هالأيام، بدل مستخدمي IAM بمفاتيح طويلة الأمد.

الدخول من هوية خارجية (Federation)

Federation يعني أشخاص أو أنظمة يدخلون بهوية موجودة خارج AWS وياخذون صلاحيات مؤقتة، بدون إنشاء مستخدم IAM. واختيارك يعتمد على مين يدخل:

مين	استخدم
موظفين على حسابات كثيرة	Identity Center زي ما شرحنا، وهذي توصية AWS
حساب واحد، أو أنظمة مثل GitHub Actions	Identity Provider في IAM عبر SAML 2.0 أو OIDC، مع دور يفترضونه
مستخدمي تطبيقك	Identity Pools في Cognito

Active Directory على AWS

شركات كثيرة تحفظ مستخدميها في Microsoft Active Directory. وAWS Directory Service يربطه بـ AWS:

الخيار	كيف يشتغل	يناسب
Managed Microsoft AD	AD حقيقي مُدار في AWS، ويقدر يثق في حقك	تطبيقات تعتمد على AD وتشتغل على AWS
AD Connector	وسيط يمرر الطلبات لـ AD حقك وما يخزن شي	إبقاء المستخدمين في AD حقك
Simple AD	دليل صغير مبني على Samba	مقفل على العملاء الجدد منذ يوليو 2026

AWS Control Tower

تجهيز كل هذا بيدك ياخذ أسابيع. Control Tower يبني Landing Zone بأفضل الممارسات فوق Organizations، ومعها حسابات السجلات والتدقيق، ويضيف:

Account Factory: إنشاء حسابات جديدة بإعدادات جاهزة.
Controls: وقائية عبر SCP، وكشفية عبر Config، واستباقية تفحص الموارد قبل إنشائها.
لوحة: تبين الملتزم من غيره بنظرة وحدة.

لو تبدأ بيئة حسابات متعددة من الصفر، ابدأ من هنا.

عملي: اختبر السياسات بدون ما تلمس شي

محاكي السياسات يقيّم السياسة بدون ما ينشئ شي أو ينفذ الإجراء، وهذا ممتاز للتعلم. من CloudShell، اكتب سياسة تسمح بـ S3 وEC2، وحد يسمح بـ S3 فقط:

Bash

cat > identity.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:*", "ec2:*"],
    "Resource": "*"
  }]
}
EOF

cat > boundary.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }]
}
EOF

اختبر ثلاث إجراءات بالسياسة لحالها:

Bash

aws iam simulate-custom-policy --policy-input-list file://identity.json \
  --action-names s3:GetObject ec2:RunInstances iam:CreateUser \
  --query "EvaluationResults[].[EvalActionName,EvalDecision]" --output table

S3 وEC2 يطلع لهم allowed، وIAM يطلع له implicitDeny لأن ما فيه شي يسمح به. الحين أضف الحد:

Bash

aws iam simulate-custom-policy --policy-input-list file://identity.json \
  --permissions-boundary-policy-input-list file://boundary.json \
  --action-names s3:GetObject ec2:RunInstances \
  --query "EvaluationResults[].[EvalActionName,EvalDecision]" --output table

EC2 صار implicitDeny، مع إن السياسة تسمح به. الحين شوف إن المنع يكسب دايماً، بإضافة منع صريح لحذف الحاويات:

Bash

cat > deny.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "s3:DeleteBucket",
    "Resource": "*"
  }]
}
EOF

aws iam simulate-custom-policy \
  --policy-input-list file://identity.json file://deny.json \
  --action-names s3:GetObject s3:DeleteBucket \
  --query "EvaluationResults[].[EvalActionName,EvalDecision]" --output table

s3:GetObject يبقى allowed، وs3:DeleteBucket يطلع له explicitDeny، مع إن السياسة الأولى تسمح بـ s3:*. جرب بعدها شرط: الوصول من شبكة المكتب فقط، واختبر من عنوانين:

Bash

cat > office.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "*",
    "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0/24" } }
  }]
}
EOF

for ip in 203.0.113.10 198.51.100.7; do
  aws iam simulate-custom-policy --policy-input-list file://office.json \
    --action-names s3:GetObject \
    --context-entries "ContextKeyName=aws:SourceIp,ContextKeyValues=$ip,ContextKeyType=ip" \
    --query "EvaluationResults[0].EvalDecision" --output text
done

العنوان الأول allowed، والثاني implicitDeny. وأخيراً، غلطة S3 الكلاسيكية، صلاحية عرض مع ARN الكائن:

Bash

cat > list.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::shop/*"
  }]
}
EOF

aws iam simulate-custom-policy --policy-input-list file://list.json \
  --action-names s3:ListBucket --resource-arns arn:aws:s3:::shop \
  --query "EvaluationResults[0].EvalDecision" --output text

يطلع implicitDeny. السياسة تبدو صحيحة، بس الصلاحية تنطبق على الحاوية، مو على اللي فيها. غيّر المورد إلى arn:aws:s3:::shop وجرب مرة ثانية، وبيطلع allowed.

الخلاصة

Organizations يجمع الحسابات تحت فاتورة وحدة، وSCP تحدد سقف وما تعطي شي.
الشروط تضيق الصلاحيات بالشبكة والمنطقة وMFA والوسوم، وaws:PrincipalOrgID يفتح الوصول لمنظمتك فقط.
الدور يخليك تترك صلاحياتك الأصلية، وسياسة المورد تبقيها.
Permissions Boundary يفوض بأمان، والمنع الصريح يكسب دايماً.
Identity Center يعطي دخول واحد ببيانات مؤقتة، وControl Tower يبني كل هذا بأفضل الممارسات.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 7

شركة تبي تتأكد إن ما أحد في حسابات التطوير يقدر يشغّل أي شي خارج Regionين، ولا حتى مدراء هذي الحسابات. وش يناسب؟

اعرض الجواب

الجواب الصحيح: C

الـ SCP تحدد سقف لكل مستخدم ودور في الحسابات اللي تحتها، بما فيهم المستخدم الجذر. وهي ما تعطي شي، فالناس لسا يحتاجون صلاحيات IAM خاصة فيهم.

A: مدراء الحساب يقدرون يغيرونها ببساطة.
B: هذا يحد مستخدم أو دور واحد في كل مرة، والمدير يقدر يشيله.
D: هذا يعلّم الموارد غير ملتزمة، وما يوقف شي.

للمراجعة: Service Control Policies (SCP) في هذا الجزء، وService control policies (SCPs) في وثائق AWS.

السؤال 2 من 7

شركة تبي قادة الفرق ينشئون أدوار لخدماتهم، بدون ما يقدرون يعطون أكثر من وصول S3 وDynamoDB. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

الـ Permissions Boundary يحدد الحد الأقصى لمستخدم أو دور وما يعطي شي بنفسه، فالدور ما يتجاوزه أبداً مهما كانت سياسته.

B: هذا يحد الحساب كامل، والشغل الثاني فيه ممكن يحتاج خدمات ثانية.
C: القاعدة المكتوبة ما توقف أحد.
D: هذي تعطي الناس وصول للحسابات، وما تحد الأدوار اللي ينشئونها.

للمراجعة: حدود الصلاحيات (Permissions Boundaries) في هذا الجزء، وPermissions boundaries for IAM entities في وثائق AWS.

السؤال 3 من 7

شركة عندها 50 حساب و500 موظف، وتحفظ مستخدميها في Microsoft Entra ID. وتبي دخول واحد، بدون مفاتيح طويلة المدى، ووصول مختلف لكل حساب. وش يناسب؟

اعرض الجواب

الجواب الصحيح: D

الموظف يدخل مرة وحدة ويشوف الحسابات والأدوار المتاحة له، بصلاحيات مؤقتة. والـ Permission Set يصير دور في كل حساب تربطه فيه.

A: هذا يعني آلاف المستخدمين والمفاتيح طويلة المدى اللي لازم تديرها.
B: هذا يضيّع مين سوى وش، ويشارك مفاتيح طويلة المدى.
C: هذا يبني Landing Zone وينشئ الحسابات، وما يعطي الناس دخولهم لحاله.

للمراجعة: IAM Identity Center: دخول واحد في هذا الجزء، وManage AWS accounts with permission sets في وثائق AWS.

السؤال 4 من 7

تطبيق في الحساب A لازم يقرأ من جدول DynamoDB في الحساب A ويكتب في حاوية S3 في الحساب B بنفس الوقت، بهوية وحدة. وش يناسب؟

اعرض الجواب

الجواب الصحيح: B

مع سياسة المورد يحتفظ التطبيق بصلاحياته، فيقدر يستخدم الجدول في A والحاوية في B مع بعض.

A: وهو في الدور يتخلى عن صلاحياته الأصلية، فيفقد الجدول في A.
C: الـ SCP ما تعطي شي.
D: الـ Boundary ما يعطي شي.

للمراجعة: دور أو سياسة مورد؟ في هذا الجزء، وCross account resource access in IAM في وثائق AWS.

السؤال 5 من 7

دور لازم يعرض الكائنات في حاوية اسمها reports ويقرأها. أي عبارتين لازم يكونون في سياسته؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: B + D

إجراءات S3 تشتغل على مستويين: العرض على الحاوية، والقراءة على الكائنات، فكل واحد يحتاج ARN خاص فيه.

A: العرض على الحاوية، فهذا الـ ARN يعطي AccessDenied.
C: القراءة على الكائنات، فهذا الـ ARN يعطي AccessDenied.
E: هذا يشتغل، بس يعطي أكثر بكثير من اللازم، وعلى كل الحاويات.

للمراجعة: غلطة S3 الكلاسيكية في هذا الجزء، وGrant read and write access to Amazon S3 bucket objects في وثائق AWS.

السؤال 6 من 7

مهمة ليلية في الحساب A لازم تشتغل بالكامل داخل الحساب B كم دقيقة. وفريق الأمان يمنع المفاتيح طويلة المدى. وش يناسب؟

اعرض الجواب

الجواب الصحيح: D

المهمة تنادي AssumeRole، وSTS تفحص سياسة الثقة في الدور وترجع صلاحيات مؤقتة، فما فيه مفاتيح طويلة المدى تحفظها.

A: هذي المفاتيح طويلة المدى اللي يمنعها الفريق.
B: الأدوار ما تنسخ بين الحسابات، والوصول لسا يحتاج سياسة ثقة.
C: الـ SCP ما تعطي شي.

للمراجعة: دور أو سياسة مورد؟ في هذا الجزء، وTemporary security credentials in IAM في وثائق AWS.

السؤال 7 من 7

مسار GitHub Actions ينشر على حساب AWS واحد، ومفاتيح الوصول محفوظة كأسرار في المستودع. والفريق يبي يوقف حفظ المفاتيح. وش يناسب؟

اعرض الجواب

الجواب الصحيح: B

المسار يثبت هويته بتوكن من GitHub، وياخذ صلاحيات مؤقتة عبر الدور، فما فيه مفاتيح تحفظها.

A: هذا يقصر عمر المفاتيح، ولسا محفوظة.
C: هذا لدخول الأشخاص، مو لأنظمة مثل مسار النشر.
D: هذا لمستخدمي تطبيقك، مو للوصول لحساب AWS.

للمراجعة: الدخول من هوية خارجية (Federation) في هذا الجزء، وIdentity providers and federation into AWS في وثائق AWS.

ضبطت مين يوصل لبياناتك. طيب لو وصل لها أحد بأي طريقة، أو هاجم موقعك من برا؟ في الجزء السابع والعشرين نغطي التشفير والأسرار والحماية من الهجمات.

المراقبة والتدقيق: CloudWatch وCloudTrail وConfig

2026-11-02T00:00:00Z

خلال الأجزاء السابقة بنينا تطبيق بقطع كثيرة. بناؤه هو النص السهل. النص الصعب يجي الساعة ثلاث الفجر: هو واقف؟ من متى؟ ومين غيّر هذاك الإعداد أمس؟

هذا القسم الأخير عن تشغيل اللي بنيته، ويبدأ بثلاث أسئلة، لكل واحد خدمته:

السؤال	الخدمة
هو بخير الحين؟	CloudWatch
مين سوى هذا، ومتى؟	CloudTrail
الإعدادات زي ما لازم، وكيف تغيرت؟	Config

وخدمة رابعة ترد على كل هذا: EventBridge.

مقاييس CloudWatch

المقياس (Metric) رقم ينقاس مع الوقت، مثل استخدام المعالج أو عدد الأخطاء. وأغلب خدمات AWS ترسل مقاييسها لحالها، مجمعة في Namespaces ومميزة بـ Dimensions، مثل رقم السيرفر.

النقطة	التفاصيل
الافتراضي في EC2	كل 5 دقايق، أو كل دقيقة لو شغلت المراقبة التفصيلية
المقاييس الخاصة	ترسل اللي تبي، مثل عدد الطلبات الفاشلة، وبدقة توصل لثانية
السجل التاريخي	بيانات الدقيقة تبقى 15 يوم، وبيانات 5 دقايق 63 يوم، والساعة 455 يوم
Metric Streams	ترسل المقاييس باستمرار عبر Firehose إلى S3 أو أداة مراقبة ثانية

وDashboards تجمع الرسوم اللي تهمك في صفحة وحدة، وتقدر تجمع مقاييس من مناطق وحسابات مختلفة.

سجلات CloudWatch

كل اللي يطبعه تطبيقك ممكن ينزل هنا، مرتب في Log Groups تمثل عادةً تطبيق واحد، وداخلها Log Streams. وLambda وECS وAPI Gateway وVPC Flow Logs وغيرها ترسل سجلاتها مباشرة، وعلى EC2 أو سيرفرات مكتبك تستخدم نفس الـ Agent.

والسجلات تبقى للأبد افتراضياً، وأنت تدفع عليها. حدد مدة حفظ لكل مجموعة، من يوم إلى عشر سنوات.

وLogs Insights يبحث فيها بلغة استعلام بسيطة. هذا يجيب آخر الأخطاء:

Output

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

وعشان ترسل السجلات لمكان ثاني عندك طريقين:

الطريق	التوقيت	يناسب
التصدير إلى S3	شغل دفعات، ومو فوري	أرشفة طويلة ورخيصة
Subscription Filter	شبه فوري	الإرسال إلى Lambda أو Kinesis أو Firehose، مثل OpenSearch

إنذارات CloudWatch

رسم ما يطالعه أحد ما له فايدة. الإنذار (Alarm) يراقب مقياس ويسوي شي لما يتجاوز حد.

الإنذار يراقب مقياس، ولما يتجاوز الحد، ينبه أحد أو يزيد السعة أو يتصرف مع السيرفر.

والإنذار يكون في وحدة من ثلاث حالات: OK أو ALARM أو INSUFFICIENT_DATA. وهذي إضافات مفيدة:

إجراءات EC2: إيقاف أو إعادة تشغيل أو حذف أو استعادة. والاستعادة تنقل السيرفر لعتاد جديد لو تعطل المضيف، مع الحفاظ على عناوين IP والإعدادات.
الإنذارات المركبة: إنذار واحد لـ "معالج مرتفع وأخطاء كثيرة"، وهذا يقلل التنبيهات الكاذبة.
الاختبار: set-alarm-state يحط الإنذار في أي حالة، فتتأكد من مسار التنبيه بدون ما تكسر شي. وبنجربه في التجربة العملية.

رؤى جاهزة

الأداة	وش تبين
Container Insights	مقاييس وسجلات ECS وEKS
Lambda Insights	أداء الدوال، ومعها الذاكرة والبداية الباردة
Contributor Insights	أكبر المساهمين، مثل عناوين IP اللي ترسل أكثر طلبات
Application Insights	تجهز المراقبة لتطبيق كامل وتشير للمشاكل المحتملة

EventBridge: الرد على الأحداث

تقريباً كل شي يصير في AWS هو حدث: سيرفر تغيرت حالته، أو حاوية انشأت، أو إنذار انطلق. EventBridge يستقبل هذي الأحداث على Bus، والقواعد ترسل المطابق منها لهدف.

الأحداث توصل على Bus من أي مكان، والقواعد ترسل كل حدث مطابق للخدمة اللي تعالجه.

الاستخدام	مثال
الرد على تغيير	سيرفر وقف، فنبّه الفريق
جدول زمني	شغّل دالة كل ليلة، وEventBridge Scheduler هو الخدمة لهذا الحين
ربط خدماتك	خدمة الطلبات تنشر حدث، واللي يهمه ياخذه
أحداث الشركاء	أحداث من تطبيقات SaaS على Bus خاص بالشريك

وميزات تستاهل تعرفها: الأرشفة وإعادة الإرسال للأحداث القديمة، وSchema Registry يوصف شكل الأحداث، وسياسات الموارد عشان حساب ثاني يرسل لـ Bus حقك.

ولأغلب الأهداف، مثل Lambda وSQS وSNS، الصلاحية تكون بسياسة مورد على الهدف. ولغيرها، مثل تشغيل مهمة ECS، يستخدم EventBridge دور IAM.

CloudTrail: مين سوى وش

كل استدعاء لـ AWS، من الكونسول أو CLI أو خدمة، يسجله CloudTrail: مين، ووش، ومتى، ومن وين. وهو شغال افتراضياً، وأول مكان تطالعه لما شي يتغير بغموض أو يختفي.

نوع الحدث	وش يغطي	الافتراضي
Management Events	تغييرات الموارد، مثل إنشاء سيرفر أو تعديل سياسة	شغال، و90 يوم مجانية في Event History
Data Events	عمليات داخل الموارد، مثل القراءة من S3 أو استدعاء Lambda	مقفل بسبب كثرتها
Insights Events	نشاط غير معتاد، مثل موجة حذف مفاجئة	مقفل وبتكلفة إضافية

وعشان تحفظها أكثر من 90 يوم، أنشئ Trail يكتب إلى S3، لكل المناطق وحتى المنظمة كلها، وحللها بـ Athena. ولاحظ إن CloudTrail Lake أقفل على العملاء الجدد في 2026، فالـ Trail هو الطريق.

ونمط قوي يجمعه مع EventBridge: أي أحد يحذف جدول، أو دخول بحساب Root، يطلق تنبيه فوري. CloudTrail يسجله، وEventBridge يطابقه، وSNS يبلغك.

AWS Config: إعداداتك مع الوقت

CloudTrail يقول لك مين استدعى وش. Config يقول لك شكل المورد: يسجل إعدادات مواردك وكل تغيير عليها، فتقدر تسأل كيف كان شكل Security Group الثلاثاء الماضي.

وقواعد Config تحكم على هذي الإعدادات:

القواعد: جاهزة، مثل "ما فيه حاويات S3 عامة"، أو خاصة فيك.
المنع: ما يمنع شي. يعلّم المورد إنه غير ملتزم، وبس.
المعالجة: القاعدة تقدر تشغل مستند Systems Manager Automation يصلح المشكلة تلقائياً.
التنبيهات: عبر EventBridge أو SNS.
النطاق والتكلفة: يشتغل لكل منطقة، وتدفع لكل عنصر مسجل ولكل تقييم قاعدة.

X-Ray: تتبع طلب واحد

الطلب في التطبيقات الحديثة ممكن يمر على API وثلاث دوال وقاعدة بيانات. المقاييس تقول إن فيه شي بطيء، وAWS X-Ray يقول وين. يجمع Traces لكل طلب وهو يمر على خدماتك، بما فيها اتصالاته بقواعد البيانات وواجهات API الثانية، ويوريك أي خطوة بطيئة أو تفشل.

أدوات ثانية للمتابعة

الأداة	وش تعرض
AWS Health Dashboard	هل عند AWS نفسها مشكلة تأثر على خدماتك ومواردك، بدون تجهيز وبدون تكلفة
Managed Grafana	لوحات للمقاييس والسجلات والتتبع من عدة مصادر، بأداة Grafana المعروفة
Managed Service for Prometheus	مقاييس الحاويات بأدوات Prometheus مفتوحة المصدر، بدون سيرفرات تشغلها

أيها ومتى؟

خلنا ناخذ موزع حمل واحد:

	مثال
CloudWatch	عدد الطلبات وأخطاء 5xx، ولوحة أو إنذار عليها
CloudTrail	مين غيّر قواعد المستمع، ومتى
Config	Security Group والشهادة الحالية وكيف تغيرت، وهل يلتزم بقواعدك؟

عملي: إنذار يرسل لك إيميل

بنراقب مقياس وهمي للطلبات الفاشلة. من CloudShell، بدّل الإيميل بإيميلك:

Bash

EMAIL=you@example.com

TOPIC_ARN=$(aws sns create-topic --name series-alerts \
  --query TopicArn --output text)

aws sns subscribe --topic-arn $TOPIC_ARN \
  --protocol email --notification-endpoint $EMAIL

افتح إيميلك واضغط Confirm subscription. ثم أنشئ إنذار ينطلق لو فشل أكثر من خمس طلبات في دقيقة:

Bash

aws cloudwatch put-metric-alarm --alarm-name series-failed-orders \
  --namespace Series/Shop --metric-name FailedOrders \
  --statistic Sum --period 60 --evaluation-periods 1 \
  --threshold 5 --comparison-operator GreaterThanThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions $TOPIC_ARN

الحين أرسل قراءة التطبيق، كأن 12 طلب فشلت للتو:

Bash

aws cloudwatch put-metric-data --namespace Series/Shop \
  --metric-name FailedOrders --value 12

انتظر دقيقتين أو ثلاث وشيك على حالة الإنذار. والمفروض يوصلك إيميل بنفس الوقت:

Bash

aws cloudwatch describe-alarms --alarm-names series-failed-orders \
  --query "MetricAlarms[0].[StateValue,StateReason]" --output text

وما تحتاج تكسر شي عشان تختبر مسار التنبيه. جربه لما يرجع الإنذار إلى OK، ويوصلك إيميل ثاني:

Bash

aws cloudwatch set-alarm-state --alarm-name series-failed-orders \
  --state-value ALARM --state-reason "Testing the alert"

وأخيراً، سوّ نفسك محقق. مين أنشأ هذا الإنذار؟ CloudTrail يعرف، بس الأحداث ممكن تاخذ كم دقيقة عشان تظهر:

Bash

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=PutMetricAlarm \
  --max-results 1 \
  --query "Events[0].[EventName,Username,EventTime]" --output text

Bash

aws cloudwatch delete-alarms --alarm-names series-failed-orders
aws sns delete-topic --topic-arn $TOPIC_ARN

الخلاصة

CloudWatch للمقاييس والسجلات والإنذارات، والذاكرة تحتاج الـ Agent.
حدد مدة حفظ لسجلاتك، لأنها تبقى للأبد افتراضياً.
EventBridge يوجه الأحداث للي يعالجها، ويشغّل الأشياء بجدول زمني.
CloudTrail يسجل مين سوى وش، وConfig يسجل الإعدادات ويحكم عليها.
اختبر مسار التنبيه قبل ما تحتاجه.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 7

فريق يبي إنذار لما تتجاوز ذاكرة سيرفرات EC2 حقته 90%، بس ما يلقى مقياس للذاكرة في CloudWatch. وش يسوي؟

اعرض الجواب

الجواب الصحيح: B

المقاييس الافتراضية تجي من خارج السيرفر، فما فيها الذاكرة. والـ Agent يرسلها من داخله، وبعدها تقدر تحط عليها إنذار.

A: هذا يرسل نفس المقاييس بشكل أكثر، والذاكرة لسا مو منها.
C: هذا يسجل مين نادى وش، مو كيف أداء السيرفر.
D: هذا يسجل إعدادات الموارد، مو اللي يصير داخل السيرفر.

للمراجعة: مقاييس CloudWatch في هذا الجزء، وMetrics collected by the CloudWatch agent في وثائق AWS.

السؤال 2 من 7

بدأ عطل بعد ما غيّر أحد مجموعة أمان البارحة بالليل. والفريق يبي يعرف مين سوى التغيير، ومن وين. وين يدور أول؟

اعرض الجواب

الجواب الصحيح: D

CloudTrail يسجل مين نادى وش، ومتى، ومن وين. والأحداث الإدارية مثل هذا تبقى هناك 90 يوم، بدون أي تجهيز.

A: هذي تعرض أرقام مع الوقت، مو مين سوى شي.
B: هذي تعرض الزيارات المقبولة والمرفوضة، مو مين غيّر قاعدة.
C: هذا يبحث في السجلات اللي ترسلها تطبيقاتك، مو الاستدعاءات إلى AWS.

للمراجعة: CloudTrail: مين سوى وش في هذا الجزء، وWorking with CloudTrail event history في وثائق AWS.

السؤال 3 من 7

شركة تبي تنتبه لما تصير أي حاوية S3 عامة، وتصلحها تلقائياً. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

قاعدة Config تحكم على إعدادات كل حاوية وتعلّمها غير ملتزمة، والـ Remediation يقدر يشغّل مستند Systems Manager Automation يصلحها. والقاعدة لحالها ما تمنع شي.

B: الحجم ما يقول شي عن مين يقدر يوصل للحاوية.
C: هذا يكشف النشاط غير العادي، وما يحكم على الإعدادات ولا يصلحها.
D: هذا يبحث في السجلات لما تطلب، وما يصلح شي.

للمراجعة: AWS Config: إعداداتك مع الوقت في هذا الجزء، وRemediating Noncompliant Resources with AWS Config في وثائق AWS.

السؤال 4 من 7

فريق الأمان يبي تنبيه فوري كل ما حذف أحد جدول DynamoDB أو دخل بالمستخدم الجذر. وش يناسب؟

اعرض الجواب

الجواب الصحيح: C

CloudTrail يسجل الاستدعاء، وEventBridge يطابقه، وSNS يخبرك على طول.

A: هذا يلقاها في النهاية، بس ممكن متأخر بأيام.
B: اللوحة اللي ما يطالعها أحد ما تنبه أحد.
D: هذا يحكم على الإعدادات، وما يتفاعل مع حذف جدول أو تسجيل دخول.

للمراجعة: CloudTrail: مين سوى وش في هذا الجزء، وAWS service events delivered via AWS CloudTrail في وثائق AWS.

السؤال 5 من 7

فاتورة CloudWatch Logs عند فريق تكبر لأن السجلات القديمة ما تنحذف أبداً، ونظام ثاني لازم يستلم سطور الأخطاء خلال ثواني. أي تغييرين يناسبون؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: A + D

السجلات تبقى للأبد افتراضياً، فمدة الاحتفاظ تشيل القديمة. والـ Subscription Filter يوصّل السطور المطابقة شبه فوري.

B: هذا شغل دفعي مو فوري، والأصول تبقى وتستمر تكلف.
C: هذا يرسل مقاييس EC2 بشكل أكثر، وما له علاقة بالسجلات.
E: هذا يسجل العمليات داخل الموارد، وما له علاقة بفاتورة سجلاتك ولا سطور الأخطاء.

للمراجعة: سجلات CloudWatch في هذا الجزء، وWorking with log groups and log streams وReal-time processing of log data with subscriptions في وثائق AWS.

السؤال 6 من 7

طلب الدفع يمر على API Gateway وثلاث دوال Lambda وجدول DynamoDB، وأحياناً ياخذ خمس ثواني. ومقاييس كل خدمة لحالها تبدو طبيعية. وش يبين أي خطوة بطيئة؟

اعرض الجواب

الجواب الصحيح: C

X-Ray يتتبع كل طلب عبر خدماتك واتصالاتها، ويوريك أي خطوة بطيئة أو تفشل.

A: هذا يسجل مين نادى أي API، مو كم أخذت كل خطوة من الطلب.
B: هذا يسجل إعدادات الموارد.
D: هذا يعرض أكبر المساهمين، مثل العناوين اللي ترسل أكثر طلبات، مو مسار الطلب.

للمراجعة: X-Ray: تتبع طلب واحد في هذا الجزء، وWhat is AWS X-Ray? في وثائق AWS.

السؤال 7 من 7

الأخطاء زادت فجأة في تطبيق في منطقة وحدة، وما تغير شي من جهة الفريق. ويبون يعرفون بسرعة هل عند AWS نفسها مشكلة تأثر على مواردهم. وين يشوفون؟

اعرض الجواب

الجواب الصحيح: B

يعرض الأحداث اللي تأثر على خدمات AWS ومواردك، بدون تجهيز وبدون تكلفة.

A: هذا يعرض الاستدعاءات في حسابك، وهذي ما تغيرت هنا.
C: هذا يعرض كيف تغيرت إعداداتك، وهذي ما تغيرت هنا.
D: هذا يفحص حسابك مقابل أفضل الممارسات، وما يبلغ عن الأعطال.

للمراجعة: أدوات ثانية للمتابعة في هذا الجزء، وWhat is AWS Health? في وثائق AWS.

الحين تعرف وش يصير في حساب واحد. بس الشركات عندها عشرات الحسابات ومئات الموظفين. في الجزء السادس والعشرين نديرهم بـ Organizations وIdentity Center.

خدمات الذكاء الاصطناعي الجاهزة

2026-11-02T00:00:00Z

في الجزء الثالث والعشرين طلّعنا إجابات من بيانات مرتبة أصلاً. بس كثير من بياناتك مو كذا: صور ومكالمات وفواتير ممسوحة. فهمها كان يحتاج فريق تعلم آلة، واليوم كثير منه استدعاء API واحد.

AWS تقدم ثلاث مستويات، وأغلب الناس يبدأون من فوق:

كل ما نزلت، زاد تحكمك في النموذج، وزادت الخبرة والشغل المطلوب.

تبي	استخدم
فهم الصور والفيديو	Rekognition
تحويل الكلام إلى نص	Transcribe
تحويل النص إلى كلام	Polly
الترجمة	Translate
روبوت محادثة أو نظام هاتف	Lex وConnect
فهم النص: المشاعر والكيانات	Comprehend
استخراج النص والجداول من المستندات	Textract
التوصيات	Personalize
نماذج توليدية على بياناتك	Bedrock
تدريب نموذج خاص فيك	SageMaker AI

الصور: Rekognition

Rekognition يحلل الصور والفيديو بدون أي تدريب منك:

التصنيفات: وش في الصورة، مثل سيارة أو شاطئ أو زحمة.
النص: قراءة الكلمات في الصور، مثل اللوحات.
فلترة المحتوى: يكشف الصور غير المناسبة قبل نشرها، وتقدر تدربه أكثر على أمثلتك.
الوجوه: كشفها ومقارنتها والبحث عنها.

ولاحظ إن ميزتي Streaming Video وBatch Image Content Moderation أقفلت على العملاء الجدد في 30 أبريل 2026. باقي الميزات ما تأثرت، وتقدر تعالج الإطارات أو الدفعات بنفسك عبر واجهة الصور.

الكلام: Transcribe وPolly

Transcribe يحول الكلام إلى نص، من ملف في S3 أو بث مباشر. ويقدر يفرق بين المتحدثين، وتضيف له مفرداتك مثل أسماء المنتجات، ويخفي البيانات الشخصية في اللغات المدعومة.

Polly يسوي العكس، ويحول النص إلى كلام. وتقدر تتحكم في النطق بطريقتين:

القواميس (Lexicons): تعلمه يقرأ AWS كـ "Amazon Web Services".
SSML: وسوم في النص تضيف وقفات أو تأكيد أو حتى همس.

الترجمة: Translate

Amazon Translate يترجم بين 75 لغة، فورياً أو بدفعات من S3. وأضف مصطلحات خاصة عشان تبقى أسماء علامتك ومصطلحاتك كما هي. وربطه مع Polly وTranscribe يعطيك محادثة مترجمة كاملة.

المحادثة: Lex وConnect

Lex يبني روبوتات محادثة كتابية وصوتية. تحدد وش ممكن يبي المستخدم، وهذا Intent، والتفاصيل اللي تحتاجها عشان تنفذه، واسمها Slots.

Connect مركز اتصال في السحابة: أرقام هاتف وطوابير ومسارات وموظفين، بدون أجهزة، وتدفع حسب الاستخدام. ومع بعض ممكن يشتغلون كذا:

عميل يتصل على الرقم في Connect.
يقول "أبي أغير موعدي"، وLex يفهم الطلب ويسأل عن التاريخ.
دالة Lambda تحدث الموعد في نظامك.
ولو تعثر الروبوت، Connect يحول المكالمة لموظف.

النص: Comprehend

Comprehend يقرأ النص ويطلع معناه: اللغة، والمشاعر، والكيانات مثل الأشخاص والأماكن، والعبارات المهمة، والبيانات الشخصية. وتقدر تدربه يصنف فئاتك، مثل نوع تذكرة الدعم.

Comprehend Medical يسوي هذا للنصوص الطبية: الحالات والأدوية والجرعات والفحوصات، ويكشف المعلومات الصحية المحمية.

وميزات Topic Modeling وEvent Detection وPrompt Safety Classification فيه أقفلت على العملاء الجدد في 30 أبريل 2026.

المستندات: Textract

Textract أبعد من قراءة النص في ملف ممسوح: يفهم البنية، فيرجع لك النماذج كأزواج حقل وقيمة، والجداول كصفوف وأعمدة. وله مسارات خاصة للفواتير والإيصالات والهويات.

التوصيات: Personalize

Personalize يبني "ممكن يعجبك كمان" من سلوك مستخدمينك: تعطيه مين شاف أو اشترى وش، وتاخذ API يرجع توصيات فورية، أو دفعات لحملات الإيميل. وما تحتاج تصمم نموذج بنفسك.

البحث في مستنداتك: وماذا عن Kendra؟

ممكن تقرأ عن Amazon Kendra، وهي خدمة بحث ذكي في المستندات الداخلية. وقفت استقبال العملاء الجدد في 30 يوليو 2026، وAWS توجّه لـ Bedrock Knowledge Bases كبديل، وهذا يوصلنا للقسم الجاي.

النماذج التوليدية: Amazon Bedrock

Bedrock يعطيك نماذج أساسية من مزودين كثير، مثل Anthropic وAmazon وMeta وMistral، عبر API واحد وبدون سيرفرات. وتدفع لكل Token، يعني حسب كمية النص الداخل والخارج. وواجهة Converse لها شكل واحد بين النماذج، فتغيير النموذج يعني تغيير قيمة وحدة.

وما عاد تحتاج تفعّل النماذج واحد واحد، لأن الوصول صار يتحكم فيه IAM. والاستثناء نماذج Anthropic، وتحتاج نموذج لمرة وحدة قبل أول استخدام.

Knowledge Bases: إجابات من مستنداتك

النموذج ما يعرف سياسات شركتك. وبدل ما تدربه، تلقى المقاطع المناسبة وتعطيه إياها مع السؤال. هذا اسمه RAG، وKnowledge Bases يتكفل فيه:

الـ Knowledge Base يلقى أقرب المقاطع للسؤال في مستنداتك، والنموذج يجاوب منها بدل ذاكرته.

باقي الأدوات

الأداة	وش تسوي
Guardrails	تمنع المواضيع غير المرغوبة، وتخفي البيانات الشخصية، وتساعد في تقليل الإجابات المختلقة
AgentCore	يشغّل ويدير وكلاء ينفذون إجراءات، مع أي إطار عمل ونموذج
الدفعات والكاش	تقلل تكلفة الشغل الكبير والأوامر المتكررة

وBedrock Agents Classic أقفل على العملاء الجدد لصالح AgentCore، فلا تبدأ فيه لو شفته في مقال قديم.

نموذجك الخاص: SageMaker AI

لما ما يكفي الجاهز، مثل توقع المخاطر من بيانات عندك أنت بس، Amazon SageMaker AI (اسمه القديم SageMaker) يغطي الرحلة: دفاتر العمل، وتجهيز البيانات، والتدريب، ثم نقطة وصول تقدم التوقعات. وJumpStart يعطيك مئات النماذج الجاهزة تبدأ منها.

لا تخلط بينه وبين Amazon SageMaker الجديد، وهو مظلة تجمع البيانات والتحليل والذكاء الاصطناعي في استوديو واحد. وكمان عدة إضافات فيه، مثل Ground Truth وClarify وModel Monitor، أقفلت على العملاء الجدد في منتصف 2026، فتأكد من حالة الميزة قبل ما تعتمد عليها.

Bedrock أو SageMaker AI؟

	Bedrock	SageMaker AI
يبدأ من	نموذج جاهز	بياناتك، أو نموذج تخصصه
الإدارة	بدون سيرفرات	تختار الحوسبة، أو تخصيص بدون سيرفرات
تدفع	لكل Token	غالباً على الحوسبة
الخبرة	المطور يكفي	تعلم الآلة يفيد كثير

ونصيحة AWS نفسها: ابدأ بـ Bedrock مع الأوامر وKnowledge Bases، وانتقل لـ SageMaker AI لما تحتاج تغيّر سلوك النموذج.

وماذا عن العربية؟

لو تطبيقك يخدم متحدثين بالعربية، شيك على هذا أول، لأن الخدمات مو سواء:

الخدمة	دعم العربية
Translate	نعم
Comprehend	نعم، ومعها المشاعر
Transcribe	الخليجية (`ar-AE`) والفصحى (`ar-SA`)، بس إخفاء البيانات الشخصية مو مدعوم لهم
Polly	زينة بالفصحى، وهالة وزيد بالخليجية
Textract	لا: الإنجليزية والفرنسية والألمانية والإيطالية والبرتغالية والإسبانية فقط
Bedrock	حسب النموذج، فجرب نموذجك على نصوصك

ربط الخدمات

القوة الحقيقية في ربطها مع اللي تعلمته. تخيل تسجيلات مكالمات تنزل في S3، وكل خطوة تشغّل اللي بعدها عبر الأحداث أو Step Functions:

كل خدمة تسوي شغلة وحدة وتسلم نتيجتها للي بعدها، بدون أي نموذج تدربه.

وبدون أي تعلم آلة، المدير الحين يقرأ ملخص كل مكالمة ويشوف أيها انتهت بشكل سيئ.

عملي: تعليق يمر على أربع خدمات

بناخذ تعليق عميل، ونحلله، ونترجمه، ونقرأه بصوت، ونرد عليه. وكلها استدعاءات مباشرة بدون أي تجهيز. وهذي الخدمات مو في كل المناطق، فلو قال أمر إنه ما قدر يتصل، أضف له --region us-east-1. من CloudShell:

Bash

REVIEW="The app is great, but delivery was very slow and support never replied."

aws comprehend detect-dominant-language --text "$REVIEW" \
  --query "Languages[0]"

aws comprehend detect-sentiment --language-code en --text "$REVIEW" \
  --query "[Sentiment,SentimentScore]"

aws comprehend detect-key-phrases --language-code en --text "$REVIEW" \
  --query "KeyPhrases[].Text"

بتشوف اللغة، والمشاعر مع درجاتها، والعبارات المهمة. الحين ترجمه للعربية، وتأكد إن Comprehend يفهم الترجمة كمان:

Bash

ARABIC=$(aws translate translate-text --text "$REVIEW" \
  --source-language-code en --target-language-code ar \
  --query TranslatedText --output text)

echo "$ARABIC"

aws comprehend detect-sentiment --language-code ar --text "$ARABIC" \
  --query Sentiment --output text

حوّل الترجمة إلى صوت بـ Polly:

Bash

aws polly synthesize-speech --voice-id Zeina --output-format mp3 \
  --text "$ARABIC" review.mp3

ls -lh review.mp3

عشان تسمعه، من قائمة Actions في CloudShell اختر Download file، واكتب review.mp3.

وأخيراً، اطلب من نموذج على Bedrock يرد على العميل. الأمر الأول يجيب معرف نموذج Amazon Nova Lite منخفض التكلفة في منطقتك. ولو طبع None، أضف --region us-east-1 للأمرين:

Bash

MODEL=$(aws bedrock list-inference-profiles \
  --query "inferenceProfileSummaries[?contains(inferenceProfileId,'nova') && contains(inferenceProfileId,'lite')].inferenceProfileId | [0]" \
  --output text)
echo $MODEL

aws bedrock-runtime converse --model-id $MODEL \
  --messages "[{\"role\":\"user\",\"content\":[{\"text\":\"Reply to this customer in two short sentences: $REVIEW\"}]}]" \
  --query "output.message.content[0].text" --output text

عندك صورة؟ ارفعها من Actions ثم Upload file، واسأل Rekognition وش فيها:

Bash

aws rekognition detect-labels --image-bytes fileb://photo.jpg \
  --max-labels 5 --query "Labels[].[Name,Confidence]" --output table

الخلاصة

ابدأ من الخدمات الجاهزة، ثم Bedrock، وبعدها فقط SageMaker AI.
Rekognition للصور، وTranscribe وPolly للكلام، وTranslate للترجمة، وComprehend للنص.
Textract يقرأ المستندات المنظمة، بس ما يدعم العربية.
Knowledge Bases يجاوب من مستنداتك بدون تدريب نموذج، وهو البديل عن Kendra.
ربط هذي الخدمات بالأحداث هو مكان القيمة الحقيقية.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 5

شركة تأمين يوصلها آلاف نماذج المطالبات الممسوحة بالإنجليزي. وتبي حقول كل نموذج وقيمه وجداوله في قاعدة بياناتها، بدون نموذج تدربه. أي خدمة تناسب؟

اعرض الجواب

الجواب الصحيح: B

Textract يفهم بنية المستند، فيرجع النماذج كأزواج حقل وقيمة، والجداول كصفوف وأعمدة.

A: هذا يقدر يقرأ كلمات في صورة، بس ما يفهم النماذج والجداول.
C: هذا يطلع المعنى من نص موجود عندك، وما يقرأ الملفات الممسوحة.
D: هذا يحول الكلام إلى نص.

للمراجعة: المستندات: Textract في هذا الجزء، وWhat is Amazon Textract? في وثائق AWS.

السؤال 2 من 5

شركة جديدة على AWS تبي مساعد يجاوب أسئلة الموظفين من مستندات سياساتها الداخلية. وما عندها فريق تعلم آلة. وش يناسب؟

اعرض الجواب

الجواب الصحيح: D

Knowledge Bases يلقى المقاطع المناسبة ويعطيها للنموذج مع السؤال، فما فيه شي تدربه.

A: هذا ما عاد يقبل عملاء جدد، وAWS توجّه لـ Knowledge Bases بدله.
B: هذا يحتاج خبرة في تعلم الآلة، والإجابة من المستندات ما تحتاج نموذج مدرب.
C: هذا يبني روبوتات حول نوايا تحددها، وما يجاوب من المستندات لحاله.

للمراجعة: Knowledge Bases: إجابات من مستنداتك في هذا الجزء، وRetrieve data and generate AI responses with Amazon Bedrock Knowledge Bases في وثائق AWS.

السؤال 3 من 5

علماء بيانات في بنك يبون يتوقعون مخاطر القروض من سجلات السداد الخاصة فيه لسنوات، وما فيه خدمة جاهزة تسوي هذا. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

هذا توقع من بيانات ما عند أحد غير البنك، فيحتاج نموذج خاص فيه. وSageMaker AI يغطي تجهيز البيانات والتدريب، ثم تقديم التوقعات من نقطة وصول.

B: هذا يبدأ من نموذج جاهز، وما يدرب نموذج توقع على سجلات البنك.
C: هذا يبني توصيات من سلوك المستخدمين، مثل "ممكن يعجبك كمان".
D: هذا يطلع المعنى من النص، مثل المشاعر والكيانات.

للمراجعة: نموذجك الخاص: SageMaker AI في هذا الجزء، وAmazon Bedrock or Amazon SageMaker AI? في وثائق AWS.

السؤال 4 من 5

مركز اتصال يحفظ تسجيلاته في S3، بالإنجليزي. ومدير يبي يعرف أي مكالمات انتهت بشكل سيئ، بدون أي شغل تعلم آلة. أي سلسلة تناسب؟

اعرض الجواب

الجواب الصحيح: C

Transcribe يحول كل تسجيل إلى نص، وتحليل المشاعر في Comprehend يبين أي مكالمات كانت سلبية.

A: Polly يسوي عكس المطلوب، يحول النص إلى كلام.
B: Rekognition يحلل الصور والفيديو، وTranslate يغير اللغة بس.
D: Textract يقرأ المستندات، وPersonalize يبني توصيات.

للمراجعة: ربط الخدمات في هذا الجزء، وWhat is Amazon Transcribe? وSentiment في وثائق AWS.

السؤال 5 من 5

متجر إلكتروني سعودي يبي يكشف مشاعر تعليقاته العربية مباشرة، ويترجمها للإنجليزي لمكتبه الرئيسي. أي خدمتين يناسبون؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: C + E

Comprehend يدعم العربية، بما فيها المشاعر، وTranslate يتكفل بالترجمة.

A: هذا يقرأ المستندات، وما يدعم العربية.
B: هذا يحول النص إلى صوت، وما يحلله ولا يترجمه.
D: هذا يحلل الصور والفيديو.

للمراجعة: وماذا عن العربية؟ في هذا الجزء، وLanguages supported in Amazon Comprehend وSupported languages and language codes في وثائق AWS.

بهذا نكمل قسم البيانات والذكاء الاصطناعي. تطبيقك صار كبير وفيه أشياء كثيرة شغالة. كيف تعرف إنه بخير، ومين غيّر وش؟ في الجزء الخامس والعشرين نبدأ القسم الأخير، مع المراقبة والتدقيق عبر CloudWatch وCloudTrail وConfig.

تحليل البيانات: Athena وRedshift وGlue

2026-11-02T00:00:00Z

التطبيق اللي خلصنا تصميمه في الجزء الثاني والعشرين يطلع بيانات كثيرة: طلبات وسجلات وأحداث. وبعدين يسألك أحد: "أي مدينة نمت أكثر هالسنة؟"

تقدر تشغّل هذا على قاعدة الإنتاج وتبطئها على عملائك. بس AWS عندها مجموعة خدمات مبنية للتحليل، وهذا الجزء دليل لها.

تبي	استخدم
SQL على ملفات في S3 بدون سيرفرات	Athena
مستودع بيانات لتقارير ثقيلة ومتكررة	Redshift
فهرس لبياناتك وتنظيفها وتحويلها	Glue
صلاحيات على بحيرة بيانات كاملة	Lake Formation
بحث نصي وتحليل سجلات	OpenSearch
شغل كبير بـ Spark أو Hadoop	EMR
لوحات متابعة لفريقك	Quick Sight
تحليل تيار وقت وصوله	Managed Flink
Apache Kafka مُدار	MSK

نوعين من الشغل

الأسئلة اللي يسألها التطبيق تختلف عن الأسئلة اللي يسألها أصحاب القرار:

	تشغيل التطبيق (OLTP)	التحليل (OLAP)
مثال	هات الطلب 1001	مجموع المبيعات لكل مدينة خلال ثلاث سنوات
الصفوف المعنية	قليلة	ملايين
من يسأل	ملايين العملاء	محللين قليلين
الخدمات	RDS وDynamoDB	Athena وRedshift

سر خدمات التحليل إنها تخزن البيانات بالأعمدة. عشان تجمع عمود واحد، ما تحتاج تقرأ الباقي:

عشان تجمع عمود المبلغ، التخزين بالصفوف يمر على كل الحقول، والتخزين بالأعمدة يقرأ هذا العمود وحده.

Amazon Athena: SQL على S3

Athena يخليك تستعلم من ملفات S3 مباشرة بـ SQL. ما فيه شي تشغله: توصف الملفات كجدول، والبيانات تبقى مكانها.

تدفع حوالي 5 دولار لكل TB يتم مسحه، بحد أدنى 10 MB للاستعلام. وإنشاء الجداول والاستعلامات الفاشلة ما تكلف شي. ويناسب الأسئلة العابرة وتحليل السجلات، مثل سجلات موزع الحمل أو S3، وهو كمان اللي توجهك له AWS بعد ما أقفلت S3 Select على العملاء الجدد.

اقرأ أقل، وادفع أقل

بما إن السعر يعتمد على اللي ينقرأ، القراءة الأقل تعني فاتورة أقل وجواب أسرع:

تنسيقات الأعمدة: حوّل الملفات إلى Parquet أو ORC، فالاستعلام يقرأ أعمدته فقط.
التقسيم (Partitions): قسّم البيانات إلى مسارات مثل year=2025/، فالاستعلام يتجاهل الباقي.
الضغط: كل ما صغرت البيانات، قل اللي ينمسح.
ملفات أكبر: آلاف الملفات الصغيرة تبطئ الشغل، فادمجها.

لما تكون البيانات مقسمة بالسنة، استعلام عن 2025 يقرأ مجلد واحد ويتجاهل الباقي، فتدفع على اللي قرأه فقط.

الاستعلامات الموحدة

بياناتك مو كلها في S3؟ Federated Query يخلي Athena يوصل لمصادر ثانية مثل DynamoDB أو RDS، عبر موصل يشتغل كدالة Lambda في حسابك. واستعلام واحد يقدر يربطها مع ملفاتك كمان.

Amazon Redshift: المستودع

لما تصير التقارير ثقيلة ومتكررة، مع ربط جداول كثير ومستخدمين كثير، تحتاج مستودع بيانات. Redshift مبني على PostgreSQL، ويخزن البيانات بالأعمدة، ويقسم الاستعلام على عدة عقد بالتوازي.

	Serverless	Provisioned
تختار	ولا شي، والسعة تضبط نفسها	نوع العقد وعددها
تدفع على	وقت الحوسبة لما تشتغل الاستعلامات	كل عقدة بالساعة
يناسب	حمل متغير أو متقطع	حمل ثابت، أو تحتاج Multi-AZ

إدخال البيانات

الطريقة	متى
`COPY` من S3	الطريقة المعتادة: يحمّل دفعة وحدة وبالتوازي
Data Firehose	تيار ينزل في S3 ثم ينحمل بـ `COPY`
Zero-ETL	نسخ تلقائي من مصادر مثل Aurora وRDS وDynamoDB، بدون بناء مسار
`INSERT` صف صف	تجنبه مع الكميات الكبيرة، لأنه بطيء جداً

نقاط تستاهل تعرفها

Redshift Spectrum: استعلم من ملفات S3 داخل Redshift بدون تحميلها، واربطها مع جداولك.
اللقطات: تلقائية وتزايدية، وتقدر تنسخها لمنطقة ثانية عشان تتعافى من كارثة.
Multi-AZ: متاح في مجموعات RA3 من نوع Provisioned، بعقد في منطقتي توفر خلف نقطة وصول وحدة.

Athena أو Redshift؟

	Athena	Redshift
البيانات في	S3	المستودع، ومعها S3 عبر Spectrum
التجهيز	ولا شي	قليل مع Serverless
تدفع على	البيانات الممسوحة	وقت الحوسبة
يناسب	أسئلة عابرة وسجلات	تقارير ثقيلة ومتكررة ولوحات

ابدأ بـ Athena، وانتقل لـ Redshift لما تصير استعلاماتك متكررة لدرجة تبرر تكلفته.

AWS Glue: تجهيز البيانات

التحليل يفترض إن البيانات نظيفة ومرتبة، وهذا نادر. Glue مجموعة أدوات بدون سيرفرات لهذا الغرض:

الجزء	وش يسوي
Data Catalog	قائمة مركزية بجداولك وأعمدتها، يستخدمها Athena وRedshift Spectrum وEMR
Crawlers	تمسح S3 وتستنتج الأعمدة، ثم تضيفها للفهرس
ETL Jobs	كود Spark يستخرج البيانات ويحولها ويحملها، مثل CSV إلى Parquet
Job Bookmarks	تتذكر اللي تمت معالجته، فما يعيد الشغل الملفات القديمة
DataBrew	ينظف البيانات بالواجهة بدون كود

نمط معروف: ينزل ملف في S3، وحدث يشغّل شغل Glue، ويحوله إلى Parquet في مجلد ثاني. ولاحظ إن Glue Ray Jobs أقفلت على العملاء الجدد في 30 أبريل 2026، بينما شغل Spark مستمر عادي.

وممكن تقرأ عن AWS Data Pipeline، خدمة أقدم لنقل البيانات ومعالجتها بجدول. وهي مقفلة على العملاء الجدد وفي وضع الصيانة، فاستخدم Glue أو Step Functions للشغل الجديد.

Lake Formation: صلاحيات البحيرة

S3 مع ملفات Parquet وفهرس هو اللي يسمونه بحيرة بيانات (Data Lake). ولما تكبر، إدارة الوصول عبر سياسات الحاوية تصير صعبة، لأن S3 يعرف الملفات، مو الأعمدة.

Lake Formation يعطيك مكان واحد تمنح فيه الوصول بقاعدة البيانات والجدول والعمود وحتى الصف: فريق المبيعات يشوف الطلبات بدون أرقام البطاقات مثلاً. وهذي الصلاحيات تنطبق عبر خدمات مثل Athena وRedshift وEMR.

البحث والشغل الكبير واللوحات

OpenSearch

قاعدة البيانات شاطرة في الجلب بالمفتاح. OpenSearch شاطر في البحث بأي كلمة في أي حقل، وفي تحليل السجلات. ويجي كـ مجموعات مُدارة تتحكم في أحجامها، أو Serverless للحمل المتغير.

وغالباً يكون نسخة من بياناتك، مو المصدر. نمطين معروفين:

بحث على جدول: DynamoDB Streams ثم Lambda ثم OpenSearch. تبحث هناك، ثم تجيب العنصر كامل من الجدول.
تحليل السجلات: CloudWatch Logs ثم Firehose ثم OpenSearch.

Amazon EMR

عندك شغل Spark أو Hadoop قائم؟ EMR يشغله، وتقدر تختار تشغيله على EC2 أو EKS أو كـ Serverless. وعلى EC2 فيه ثلاث أنواع من العقد:

العقدة	دورها	خيار الشراء
Primary	تنسق المجموعة	On-Demand أو Reserved
Core	تشغل المهام وتخزن البيانات	On-Demand أو Reserved
Task	تشغل المهام فقط، وهي اختيارية	Spot مثالي لها

Quick Sight

Amazon Quick Sight يبني لوحات متابعة من Athena وRedshift وRDS وS3 وغيرها. كان اسمه QuickSight، ومن أكتوبر 2025 صار جزء من مجموعة أوسع اسمها Amazon Quick، مع إن الـ API لسا يستخدم الاسم القديم.

SPICE: محرك في الذاكرة يخلي اللوحات سريعة، بدون ما يضغط على المصدر مع كل مشاهدة.
Analysis أو Dashboard: تعدل في الـ Analysis، وتنشره كـ Dashboard للقراءة فقط.
أمان الصفوف: كل مدير يشوف بيانات منطقته فقط.

التيارات: Flink وKafka

Kinesis وFirehose يوصلون البيانات. طيب لو تبي تحللها وقت وصولها، مثل كشف نمط مشبوه خلال ثواني؟

Managed Service for Apache Flink (اسمه القديم Kinesis Data Analytics) يشغّل تطبيقات Flink تقرأ من تيار Kinesis أو من MSK، بدون ما تدير المجموعة.

Amazon MSK هو Apache Kafka مُدار، أشهر منصة تيارات في عالم المصادر المفتوحة. ويجي كمجموعات Provisioned بوسطاء Standard أو Express، أو كـ Serverless.

	Kinesis Data Streams	Amazon MSK
ينقسم إلى	Shards	Topics وPartitions
الواجهات	خاصة بـ AWS	Kafka القياسية
حجم السجل	1 MiB افتراضياً، وحتى 10 MiB	1 MB افتراضياً، وقابل للتعديل
اختره لو	تبي أبسط خيار على AWS	عندك تطبيقات وأدوات Kafka

كيف توصل البيانات؟

اختيار طريق الإدخال يبدأ من كم مرة توصل البيانات، وكم حجمها:

البيانات	استخدم
ملفات من سيرفر أو NAS بجدول	DataSync
ملفات من شركاء عبر SFTP	Transfer Family
سجلات صغيرة باستمرار، لأكثر من قارئ	Kinesis Data Streams أو MSK
سجلات صغيرة باستمرار، تنزل في التخزين	Data Firehose
صفوف تتغير في قاعدة بيانات	Zero-ETL أو DMS
مجموعات بيانات من شركات ثانية	AWS Data Exchange، وتشترك فيها من خلاله

وأمّن كل طريق بنفس الأسلوب: أدوار IAM بأقل صلاحية، وتشفير أثناء النقل والتخزين، وطرق خاصة مثل VPC Endpoints بدل الإنترنت العام لما تقدر.

الصورة الكاملة

هذا كيف تجتمع القطع في مسار معتاد:

البيانات تنزل خام في S3، وGlue يحولها إلى Parquet، وAthena يجاوب منها، وQuick Sight يعرض النتيجة. وRedshift ممكن ياخذ مكان Athena في التقارير الثقيلة.

عملي: Parquet يقلل اللي يقرأه الاستعلام

بنولّد ملف فيه 200,000 طلب ونسأله نفس السؤال مرتين. من CloudShell:

Bash

BUCKET=series-data-$RANDOM$RANDOM
aws s3 mb s3://$BUCKET

awk 'BEGIN {
  srand(7)
  split("Riyadh Jeddah Dammam Abha Tabuk", city, " ")
  for (i = 1; i <= 200000; i++)
    printf "%d,%s,%d,%.2f\n", i, city[int(rand()*5)+1], 2024+int(rand()*3), rand()*500
}' > sales.csv

head -3 sales.csv
aws s3 cp sales.csv s3://$BUCKET/raw/sales.csv

هذي الدالة تشغّل استعلام وتنتظره، ثم تطبع حالته والبايتات اللي مسحها ونتيجته:

Bash

run_sql() {
  ID=$(aws athena start-query-execution --query-string "$1" \
    --result-configuration OutputLocation=s3://$BUCKET/results/ \
    --query QueryExecutionId --output text)
  while true; do
    STATE=$(aws athena get-query-execution --query-execution-id $ID \
      --query QueryExecution.Status.State --output text)
    [ "$STATE" = QUEUED ] || [ "$STATE" = RUNNING ] || break
    sleep 1
  done
  aws athena get-query-execution --query-execution-id $ID \
    --query "QueryExecution.[Status.State,Statistics.DataScannedInBytes]" \
    --output text
  aws athena get-query-results --query-execution-id $ID \
    --query "ResultSet.Rows[*].Data[*].VarCharValue" --output text
}

صف الملف كجدول. ما ينتقل شي، والبيانات تبقى في S3:

Bash

run_sql "CREATE DATABASE series_data"

run_sql "CREATE EXTERNAL TABLE series_data.sales_csv (
  order_id INT, city STRING, year INT, amount DOUBLE
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
LOCATION 's3://$BUCKET/raw/'"

اسأل السؤال:

Bash

run_sql "SELECT city, ROUND(SUM(amount)) AS total
FROM series_data.sales_csv WHERE year = 2025
GROUP BY city ORDER BY total DESC"

يطلع لك المجموع لكل مدينة، وأول سطر يبين إن الملف كله انمسح، أكثر من 5 MB بشوي، مع إن السؤال يخص سنة وحدة وعمودين. الحين أنشئ نسخة Parquet مقسمة باستعلام واحد:

Bash

run_sql "CREATE TABLE series_data.sales_parquet WITH (
  format = 'PARQUET',
  external_location = 's3://$BUCKET/parquet/',
  partitioned_by = ARRAY['year']
) AS SELECT order_id, city, amount, year FROM series_data.sales_csv"

aws s3 ls s3://$BUCKET/parquet/

بتشوف مجلد لكل سنة. اسأل نفس السؤال من الجدول الجديد:

Bash

run_sql "SELECT city, ROUND(SUM(amount)) AS total
FROM series_data.sales_parquet WHERE year = 2025
GROUP BY city ORDER BY total DESC"

الأرقام نفسها، بس البايتات الممسوحة جزء صغير من الرقم الأول. وعلى التيرابايتات، هذا الفرق هو فاتورتك.

Bash

run_sql "DROP TABLE series_data.sales_parquet"
run_sql "DROP TABLE series_data.sales_csv"
run_sql "DROP DATABASE series_data"
aws s3 rb s3://$BUCKET --force

الخلاصة

افصل التحليل عن قاعدة الإنتاج، وخزن البيانات بالأعمدة.
Athena يستعلم من S3 بدون سيرفرات، وParquet والتقسيم يقللون تكلفته.
Redshift للتقارير الثقيلة والمتكررة، وServerless بداية سهلة.
Glue يفهرس بياناتك ويحولها، وLake Formation يحدد من يشوف أي عمود.
OpenSearch للبحث، وEMR لشغل Spark، وQuick Sight للوحات، وFlink وMSK للتيارات.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 6

محللو سلسلة متاجر يشغّلون تقارير ثقيلة طول اليوم، فيها ربط جداول كثير على مبيعات سنوات، وعشرات اللوحات تتحدث منها. أي خدمة مبنية لهذا؟

اعرض الجواب

الجواب الصحيح: C

هذا شغل مستودع البيانات. Redshift يخزن البيانات بالأعمدة ويقسم كل استعلام على عدة عقد، فتشتغل التقارير الثقيلة المتكررة بسرعة.

A: هذا يناسب الأسئلة العابرة، ومع هذا العدد من الاستعلامات بتدفع على كل مسح.
B: هذا يخفف عن الإنتاج، بس لسا يخزن بالصفوف وما هو مبني لتحليل بهذا الحجم.
D: هذا للبحث النصي وتحليل السجلات.

للمراجعة: Athena أو Redshift؟ في هذا الجزء، وWhat is Amazon Redshift? في وثائق AWS.

السؤال 2 من 6

شركاء ينزلون ملفات CSV في حاوية S3 كل يوم. وفريق يبي يحولها إلى Parquet بجدول، بدون سيرفرات يشغلها وبدون إعادة معالجة الملفات اللي تحولت. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

مهمة Glue ETL تشغّل Spark بدون سيرفرات تديرها، وJob Bookmarks تتذكر اللي تعالج، فكل تشغيل يتعامل مع الملفات الجديدة فقط.

B: الـ Crawler يستنتج الأعمدة ويحدث الفهرس، وما يحول شي.
C: هذا يقدر يسوي التحويل، بس هو مجموعة لازم تشغلها.
D: هذا ينقل الملفات بين الفئات، وما يغير تنسيقها.

للمراجعة: AWS Glue: تجهيز البيانات في هذا الجزء، وTracking processed data using job bookmarks في وثائق AWS.

السؤال 3 من 6

بحيرة بيانات شركة فيها جدول طلبات في S3، ينستعلم عنه عبر Athena. وفريق المبيعات لازم يشوف الجدول، بس بدون عمود رقم البطاقة. وش يناسب؟

اعرض الجواب

الجواب الصحيح: D

Lake Formation يعطي الوصول لحد العمود والصف، وهذي الصلاحيات تنطبق عبر خدمات مثل Athena.

A: S3 تعرف الملفات، مو الأعمدة اللي داخلها.
B: الـ Crawler يوصف البيانات بس، وما يتحكم في وصول أحد.
C: هذا يعطي الفريق بوابته للحاوية، ولسا يشتغل على مستوى الملفات.

للمراجعة: Lake Formation: صلاحيات البحيرة في هذا الجزء، وData filtering and cell-level security in Lake Formation في وثائق AWS.

السؤال 4 من 6

متجر يحفظ منتجاته في DynamoDB. والعملاء يبون يبحثون عن أي كلمة في اسم المنتج أو وصفه، والجدول لازم يبقى مصدر الحقيقة. وش يناسب؟

اعرض الجواب

الجواب الصحيح: B

OpenSearch يلقى أي كلمة في أي حقل. وStreams وLambda يبقونه محدث، فتبحث هناك، ثم تجيب العنصر كامل من الجدول.

A: الفهرس يلقى العناصر بالمفتاح، مو بأي كلمة داخل نص طويل.
C: هذا يقرأ الجدول كله مع كل بحث، فهو بطيء ومكلف.
D: هذا يسرّع القراءة بالمفتاح، وما يضيف بحث نصي.

للمراجعة: OpenSearch في هذا الجزء، وLoading streaming data into Amazon OpenSearch Service في وثائق AWS.

السؤال 5 من 6

فاتورة Athena عند فريق عالية. واستعلاماته عادةً تقرأ عمودين من شهر واحد، بس كل البيانات في S3 في مجلد كبير من ملفات CSV. أي تغييرين يقللون التكلفة؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: B + E

Athena يحاسب على البيانات اللي يمسحها. وParquet يخلي الاستعلام يقرأ أعمدته فقط، والتقسيم يخليه يتجاهل باقي الشهور.

A: الملفات في هذي الفئة لازم تنسترجع قبل ما تنقرأ.
C: السعر يعتمد على اللي ينقرأ، مو على وقته.
D: هذا يحتفظ بالإصدارات القديمة، وما يغير شي في اللي يقرأه الاستعلام.

للمراجعة: اقرأ أقل، وادفع أقل في هذا الجزء، وUse columnar storage formats وPartition your data في وثائق AWS.

السؤال 6 من 6

فريق تحليل يبي بيانات طقس من مزود تجاري في بحيرة بياناته، تتحدث باشتراك، بدون بناء قناة خاصة. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

Data Exchange هو المكان اللي تلقى فيه مجموعات بيانات الشركات الثانية وتشترك فيها.

B: هذا يستقبل ملفات عبر SFTP وأخواته، والمزود لازم يرسلها لك.
C: هذا يوصف بيانات موجودة عندك، وما يجيب بيانات جديدة.
D: لازم تكتب اللي يغذيه، وهذا الشغل اللي يبي الفريق يتجنبه.

للمراجعة: كيف توصل البيانات؟ في هذا الجزء، وWhat is AWS Data Exchange? في وثائق AWS.

الحين فهمت البيانات اللي عندك. تقدر تطلع منها أكثر، مثل قراءة المستندات وفهم الكلام وتوليد النصوص؟ في الجزء الرابع والعشرين نمر على خدمات الذكاء الاصطناعي الجاهزة في AWS.

تصميم تطبيقات بدون خوادم

2026-11-02T00:00:00Z

في الجزء الحادي والعشرين بنينا API من ثلاث قطع. التطبيق الحقيقي يحتاج أكثر: عملية من عدة خطوات ممكن تفشل في النص، ومستخدمين يسجلون دخول، وأشياء لازم تصير بعد الطلب بدون ما ينتظرها أحد.

هذا الجزء يكمل الصورة بخدمتين زيادة، ثم يطبق كل شي على تصميمين.

Step Functions: سير العمل

الطلب فيه فحص مخزون، ثم تحصيل المبلغ، ثم شحن. تقدر تخلي كل دالة تستدعي اللي بعدها، بس وين تكون إعادة المحاولة؟ وش يصير لو فشل الدفع بعد ما حجزت المخزون؟ ومين يقول لك وين الطلب 1001 الحين؟

Step Functions يطلع هذا المنطق من كودك إلى آلة حالات (State Machine): تعريف للخطوات ووش يصير بعد كل وحدة، وتشوفه كرسم في الكونسول.

سير العمل يعرف ترتيب الخطوات ووين يروح كل فشل، وكل خطوة تبقى صغيرة وبسيطة.

كل خطوة تقدر تستدعي دالة Lambda أو خدمات AWS كثيرة مباشرة، والتعريف يتكفل باللي كنت بتكتبه بيدك:

القدرة	وش تسوي
Retry	تعيد الخطوة الفاشلة، وتنتظر أطول كل مرة
Catch	ترسل الفشل لخطوة تعالجه، مثل استرجاع المبلغ
Choice	تختار المسار حسب البيانات
Parallel وMap	تشغل فروع مع بعض، أو خطوة لكل عنصر في قائمة
Wait	توقف لفترة، أو لموافقة بشرية تاخذ أيام

هذا شكل إعادة محاولة الدفع والتقاط فشله:

JSON

"TakePayment": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": { "FunctionName": "take-payment", "Payload.$": "$" },
  "Retry": [{
    "ErrorEquals": ["States.TaskFailed"],
    "IntervalSeconds": 2,
    "BackoffRate": 2,
    "MaxAttempts": 3
  }],
  "Catch": [{
    "ErrorEquals": ["States.ALL"],
    "Next": "CancelOrder"
  }],
  "Next": "Ship"
}

	Standard	Express
أقصى مدة	سنة	خمس دقايق
التنفيذ	مرة واحدة بالضبط	مرة على الأقل
المحاسبة	لكل انتقال بين الحالات، و4,000 مجانية كل شهر	عدد الطلبات والمدة والذاكرة
يناسب	عمليات طويلة مثل الطلبات والموافقات	أحداث قصيرة ومتكررة جداً

Cognito: مستخدمينك

IAM لفريقك وخدماتك، مو لمليون شخص يستخدمون تطبيقك. Amazon Cognito يعطي تطبيقك مستخدمينه، وله جزئين سهل تخلط بينهم:

	User Pool	Identity Pool
السؤال اللي يجاوبه	من هذا المستخدم؟	وش يقدر يسوي في AWS؟
يعطي	توكن بعد الدخول	مفاتيح AWS مؤقتة
يستخدم لـ	تطبيقك والـ API حقك	وصول مباشر لـ S3 أو DynamoDB

User Pools تتكفل بالتسجيل والدخول، واستعادة كلمة المرور، والتحقق بعدة عوامل، والدخول بحسابات مثل Google أو هوية الشركة. وAPI Gateway وموزع الحمل ALB يقدرون يتحققون من توكناته مباشرة. والمجموعات الجديدة تستخدم خطة Essentials افتراضياً، وفيه كمان Lite الأرخص بميزات أقل، وPlus بحماية متقدمة.

Identity Pools تبدل التوكن بمفاتيح مؤقتة مربوطة بدور IAM، ومتغير في السياسة يحصرها في بيانات المستخدم نفسه. مثلاً كل مستخدم يوصل لمجلده فقط في S3:

JSON

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::recipe-photos/users/${cognito-identity.amazonaws.com:sub}/*"
}

التصميم الأول: تطبيق جوال

خلنا نصمم تطبيق لمشاركة الوصفات: المستخدمين يسجلون دخول، ويكتبون وصفات، ويرفعون صور، والوصفات المشهورة تنقرأ أكثر بكثير مما تنكتب. كل متطلب له قطعته:

المتطلب	الحل
دخول المستخدمين	User Pool في Cognito
API لقراءة الوصفات وكتابتها	API Gateway وLambda وDynamoDB
رفع الصور مباشرة	Identity Pool بمفاتيح مؤقتة إلى S3
قراءات هائلة لنفس الوصفات	DAX قدام الجدول
طلبات متطابقة متكررة	كاش API Gateway في REST API

الـ User Pool يسجل دخول المستخدم ويعطيه توكن. API Gateway يتحقق منه، والـ Identity Pool يبدله بمفاتيح مؤقتة محصورة في مجلد المستخدم.

ليه الصورة تروح مباشرة لـ S3 بدل ما تمر عبر الـ API؟ لأن API Gateway حده 10 MB، ولأنك بتدفع وقت Lambda بس عشان تمرر بايتات. والروابط الموقّعة خيار ثاني ممتاز هنا، لو ما تحتاج Identity Pools.

ولاحظ وين يقع كل كاش: كاش API Gateway يوقف الطلب قبل ما يوصل للدالة، فيناسب الردود اللي ما تختلف من مستخدم لآخر. وDAX يخلي الدالة تشتغل، ويريح الجدول من القراءة.

التصميم الثاني: موقع عالمي

الحين دليل سفر ينقرأ حول العالم: صفحات ثابتة، وAPI صغير، وإيميل ترحيب لما يسجل أحد، وصور مصغرة للصور اللي يرفعها المستخدمين.

CloudFront يقدم الصفحات ويمرر طلبات الـ API. وكل شي بعد الكتابة يصير بالأحداث: مستخدم جديد يشغّل الإيميل، وصورة جديدة تشغّل الصورة المصغرة.

تابعه قطعة قطعة:

الصفحات: حاوية S3 خاصة وقدامها CloudFront مع OAC، فالحاوية تبقى مقفلة والموقع سريع في كل مكان.
الـ API: API Gateway وLambda وDynamoDB، وGlobal Tables تقرب البيانات من المستخدمين في كل منطقة.
إيميل الترحيب: الـ API ما يرسله. المستخدم الجديد ينكتب في الجدول، وDynamoDB Streams يشغّل دالة، وهي ترسل عبر SES. ولو فشل الإيميل، التسجيل ما يتأثر.
الصور المصغرة: صورة تنزل في S3 تشغّل دالة Lambda تكتب نسخة أصغر. وللتعامل مع الموجات أو الوصول لأكثر من خدمة، حط SQS أو SNS بينهم.

ما فيه سيرفر واحد هنا، ولما ما يكون فيه زوار، الفاتورة تقرب من تكلفة التخزين فقط. والفكرة في آخر مسارين وحدة: الطلب يخلص بسرعة، والباقي يصير بالأحداث.

الخدمات المصغرة (Microservices)

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

الأسلوب	الأدوات	يناسب
متزامن	API Gateway أو موزع حمل	تحتاج الجواب الحين، مثل سعر
غير متزامن	SQS وSNS وKinesis ومشغلات Lambda	الشغل ممكن يجي بعدين، مثل فاتورة

وكل خدمة تقدر تختار اللي يناسبها: Lambda للطلبات المتفرقة، وFargate للحمل الثابت، وEC2 للمتطلبات الخاصة. بس لهذا كله ثمن: إطلاقات أكثر، ومراقبة أكثر، وأعطال أصعب في تتبعها بين الخدمات. فلا تبدأ من هنا لتطبيق صغير، وقسّم بس لما تحتاج فعلاً.

ربح رخيص: CloudFront قدام اللي عندك

مو كل تحسين يحتاج إعادة كتابة. تخيل تطبيق على مجموعة Auto Scaling يوزع ملفات تحديث كبيرة. يوم الإطلاق، كل مستخدمينك يحملون بنفس الوقت: السيرفرات تتضاعف، وفاتورة نقل البيانات تقفز.

حط CloudFront قدامه، وما تغير شي ثاني. الملفات ما تتغير، فتناسب الكاش جداً: أغلب الطلبات توقف عند الحافة، والمجموعة بالكاد تكبر، والبيانات الخارجة عبر CloudFront أرخص من الخروج المباشر. شغل دقايق ممكن يرجع لك أكثر من إعادة تصميم.

مبادئ التصميم

المبدأ	ليه
خل المعالجة آمنة لو تكررت	SQS وSNS وLambda غير المتزامنة توصل مرة على الأقل
طابور فشل لكل شي غير متزامن	الفشل الصامت أسوأ أنواع الفشل
دور واحد لكل دالة بأقل صلاحية	ثغرة في وحدة ما تفتح كل شي
دوال صغيرة بشغلة وحدة	أسهل في الاختبار وأسرع في التشغيل
احسب التكلفة	مع حمل كبير وثابت، الحاويات ممكن تطلع أرخص
راقب كل شي	الطلب يمر بخدمات كثيرة، وبنغطي الأدوات في الجزء الخامس والعشرين

وما يلزم تبدأ من الصفر. AWS Serverless Application Repository يخليك تلقى تطبيقات جاهزة بدون سيرفرات، وتضبط كم قيمة، وتنشرها بكم ضغطة.

عملي: ملف يشغّل دالة

في الجزء الخامس عشر وعدنا نطبق أحداث S3. بنسوي مسار الصور المصغرة بتبسيط واحد: بدل مكتبة صور، الدالة تحول ملف نصي إلى حروف كبيرة. والمسار نفسه تماماً. من CloudShell:

Bash

BUCKET=series-events-$RANDOM$RANDOM
aws s3 mb s3://$BUCKET

cat > trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "lambda.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
EOF

ROLE_ARN=$(aws iam create-role --role-name series-events-role \
  --assume-role-policy-document file://trust.json \
  --query Role.Arn --output text)

aws iam attach-role-policy --role-name series-events-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

aws iam put-role-policy --role-name series-events-role \
  --policy-name bucket-access --policy-document "{
    \"Version\": \"2012-10-17\",
    \"Statement\": [{
      \"Effect\": \"Allow\",
      \"Action\": [\"s3:GetObject\", \"s3:PutObject\"],
      \"Resource\": \"arn:aws:s3:::$BUCKET/*\"
    }]
  }"

اكتب الدالة وأنشئها. ولو جاك خطأ عن الدور، انتظر كم ثانية وأعد الأمر:

Bash

cat > app.py <<'EOF'
from urllib.parse import unquote_plus
import boto3

s3 = boto3.client("s3")

def handler(event, context):
    for record in event["Records"]:
        bucket = record["s3"]["bucket"]["name"]
        key = unquote_plus(record["s3"]["object"]["key"])
        body = s3.get_object(Bucket=bucket, Key=key)["Body"].read().decode()
        name = key.split("/")[-1]
        s3.put_object(Bucket=bucket, Key=f"processed/{name}", Body=body.upper())
EOF

zip -q function.zip app.py

FN_ARN=$(aws lambda create-function --function-name series-events \
  --runtime python3.13 --handler app.handler --role $ROLE_ARN \
  --zip-file fileb://function.zip \
  --query FunctionArn --output text)

aws lambda wait function-active-v2 --function-name series-events

اسمح لـ S3 يستدعي الدالة، ثم قل للحاوية ترسل لها أحداث مجلد uploads/ فقط:

Bash

aws lambda add-permission --function-name series-events \
  --statement-id s3-trigger --action lambda:InvokeFunction \
  --principal s3.amazonaws.com --source-arn arn:aws:s3:::$BUCKET \
  --query Statement --output text > /dev/null

cat > notify.json <<EOF
{
  "LambdaFunctionConfigurations": [{
    "LambdaFunctionArn": "$FN_ARN",
    "Events": ["s3:ObjectCreated:*"],
    "Filter": {"Key": {"FilterRules": [{"Name": "prefix", "Value": "uploads/"}]}}
  }]
}
EOF

aws s3api put-bucket-notification-configuration --bucket $BUCKET \
  --notification-configuration file://notify.json

ارفع ملف، وانتظر كم ثانية، ثم اقرأ النتيجة:

Bash

echo "hello from s3" > note.txt
aws s3 cp note.txt s3://$BUCKET/uploads/note.txt

Bash

aws s3 cp s3://$BUCKET/processed/note.txt -

يطبع HELLO FROM S3. رفعت ملف، وكود اشتغل لحاله.

نظّف قبل ما تكمل:

Bash

aws s3 rb s3://$BUCKET --force
aws lambda delete-function --function-name series-events
aws logs delete-log-group --log-group-name /aws/lambda/series-events
aws iam delete-role-policy --role-name series-events-role \
  --policy-name bucket-access
aws iam detach-role-policy --role-name series-events-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
aws iam delete-role --role-name series-events-role

عملي: سير عمل يقرر

بنكتب آلة حالات تطالع مبلغ الطلب: المبلغ السالب يفشل، والكبير يروح للمراجعة، والباقي ينقبل. وتستخدم خطوات داخلية فقط، فتحتاج دور بدون صلاحيات:

Bash

cat > trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "states.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
EOF

FLOW_ROLE=$(aws iam create-role --role-name series-flow-role \
  --assume-role-policy-document file://trust.json \
  --query Role.Arn --output text)

cat > flow.json <<'EOF'
{
  "StartAt": "CheckAmount",
  "States": {
    "CheckAmount": {
      "Type": "Choice",
      "Choices": [
        {"Variable": "$.amount", "NumericLessThanEquals": 0, "Next": "Rejected"},
        {"Variable": "$.amount", "NumericGreaterThan": 1000, "Next": "NeedsReview"}
      ],
      "Default": "Approved"
    },
    "NeedsReview": {"Type": "Pass", "Result": {"status": "review"}, "End": true},
    "Approved": {"Type": "Pass", "Result": {"status": "approved"}, "End": true},
    "Rejected": {"Type": "Fail", "Error": "InvalidAmount", "Cause": "The amount must be positive"}
  }
}
EOF

أنشئها. وهنا برضو، لو جاك خطأ عن الدور، انتظر كم ثانية وأعد الأمر:

Bash

FLOW_ARN=$(aws stepfunctions create-state-machine --name series-order \
  --definition file://flow.json --role-arn $FLOW_ROLE \
  --query stateMachineArn --output text)

شغّلها بثلاث طلبات:

Bash

try_order() {
  RUN=$(aws stepfunctions start-execution --state-machine-arn $FLOW_ARN \
    --input "$1" --query executionArn --output text)
  sleep 2
  aws stepfunctions describe-execution --execution-arn $RUN \
    --query "[status,output]" --output text
}

try_order '{"amount": 250}'
try_order '{"amount": 5000}'
try_order '{"amount": -5}'

بيطلع لك approved، ثم review، ثم FAILED. الحين افتح Step Functions في الكونسول، واختر series-order، ثم أي تنفيذ. بتشوف الرسم والمسار اللي مشى عليه ملوّن، وهذا اللي بتطالعه لما يعلق طلب في الإنتاج.

Bash

aws stepfunctions delete-state-machine --state-machine-arn $FLOW_ARN
aws iam delete-role --role-name series-flow-role

الخلاصة

Step Functions يطلع الخطوات وإعادة المحاولة والفشل من كودك إلى سير عمل تشوفه.
User Pool يجاوب من هو المستخدم، وIdentity Pool يعطيه مفاتيح مؤقتة لـ AWS.
التصميم الجيد يخلص الطلب بسرعة، ويترك الباقي للأحداث.
خل الملفات الكبيرة تروح مباشرة لـ S3، وحط الكاش وين يوقف أكبر قدر من الشغل.
الخدمات المصغرة لها ثمن، فقسّم بس لما تحتاج فعلاً.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 5

الطلب يمر بالمخزون ثم الدفع ثم الشحن. والخطوات الفاشلة لازم تنعاد، وفشل الدفع لازم يطلق استرداد، والطلبات الكبيرة تنتظر موافقة مدير أيام. والفريق يبي يشوف وين وصل كل طلب. وش يناسب؟

اعرض الجواب

الجواب الصحيح: D

سير العمل Standard ممكن يستمر حتى سنة، وتعريفه يحمل إعادة المحاولة والفشل والانتظار، والكونسول يعرض لك مسار كل تنفيذ كرسم.

A: هذا يشتغل خمس دقايق كحد أقصى، فما يقدر ينتظر أيام.
B: إعادة المحاولة ومعالجة الفشل تصير في كودك، وما فيه شي يوريك وين وصل الطلب.
C: هذا يوصّل لكل المشتركين مرة وحدة، بدون ترتيب بين الخطوات.

للمراجعة: Step Functions: سير العمل في هذا الجزء، وChoosing workflow type in Step Functions في وثائق AWS.

السؤال 2 من 5

المستخدمين يدخلون لتطبيق جوال عبر Cognito User Pool. ولازم يرفعون صورهم مباشرة إلى S3، وكل واحد يوصل لمجلده فقط. وش يعطي التطبيق وصول إلى S3؟

اعرض الجواب

الجواب الصحيح: A

الـ Identity Pool يبدل التوكن بمفاتيح مؤقتة مربوطة بدور IAM، والمتغير في السياسة يحصرها في مجلد المستخدم.

B: توكن الـ User Pool يقول مين المستخدم، وهو مو مفاتيح AWS.
C: IAM لفريقك وخدماتك، مو لأعداد ضخمة من مستخدمي التطبيق.
D: أي أحد يقدر يطلع هذي المفاتيح من التطبيق، وبتشتغل على مجلدات الكل.

للمراجعة: Cognito: مستخدمينك في هذا الجزء، وAmazon Cognito identity pools وIAM roles في وثائق AWS.

السؤال 3 من 5

واجهة تسجيل ترسل بريد ترحيب قبل ما ترد. ولما تبطأ خدمة البريد يبطأ التسجيل، ولما تفشل يفشل التسجيل. والمستخدمين الجدد ينكتبون في DynamoDB. وش أفضل تصميم؟

اعرض الجواب

الجواب الصحيح: B

الطلب يخلص أول ما ينكتب المستخدم، والبريد يصير عبر حدث، ففشل البريد ما يأثر على التسجيل.

A: المستخدمين بينتظرون أكثر، والفشل لسا يوصل لهم.
C: هذا يشيل البداية الباردة، والبطء جاي من البريد.
D: إعادة المحاولة داخل الطلب تخلي المستخدمين ينتظرون أكثر.

للمراجعة: التصميم الثاني: موقع عالمي في هذا الجزء، وDynamoDB Streams and AWS Lambda triggers في وثائق AWS.

السؤال 4 من 5

تطبيق على مجموعة Auto Scaling يوزع ملفات تحديث كبيرة. ويوم الإطلاق تكبر المجموعة بقوة وتقفز فاتورة نقل البيانات. وش يعطي أكبر تحسين بأقل تغيير؟

اعرض الجواب

الجواب الصحيح: C

الملفات ما تتغير، فتناسب الكاش جداً. وأغلب الطلبات تنتهي عند الحافة، والمجموعة بالكاد تكبر، والبيانات اللي تطلع عبر CloudFront أرخص من اللي تطلع مباشرة.

A: السيرفرات لسا تخدم كل تحميل، ونفس البيانات لسا تطلع.
B: هذا إعادة كتابة، وحد API Gateway وهو 10 MB صغير على الملفات الكبيرة.
D: هذا يختصر الطريق بس ما يخزن، فكل تحميل لسا يوصل للسيرفرات.

للمراجعة: ربح رخيص: CloudFront قدام اللي عندك في هذا الجزء، وWhat is Amazon CloudFront? في وثائق AWS.

السؤال 5 من 5

موضوع SNS يشغّل دالة Lambda بشكل غير متزامن. وبعض العملاء انخصم منهم مرتين، والأحداث اللي فشلت كثير اختفت بدون أي أثر. أي تغييرين يعالجون هذا؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: A + E

الحدث ممكن يوصل أكثر من مرة، فلازم التكرار ما يضر. وطابور الرسائل الفاشلة يحتفظ باللي فشل عشان تفحصه، بدل ما يضيع بصمت.

B: هذا يسرّع الدالة، والتكرار لسا يوصل.
C: هذا يخفف البداية الباردة، وما له علاقة بأي مشكلة منهم.
D: هذا يبقي البيئات جاهزة، وما له علاقة بأي مشكلة منهم.

للمراجعة: مبادئ التصميم في هذا الجزء، وHow Lambda handles errors and retries with asynchronous invocation وCapturing records of Lambda asynchronous invocations في وثائق AWS.

بهذا نكمل قسم التطبيقات الحديثة. تطبيقك الحين يطلع بيانات كثيرة، بس وش تقول لك؟ في الجزء الثالث والعشرين نبدأ قسم البيانات والذكاء الاصطناعي، ونحلل البيانات بـ Athena وRedshift وGlue.

بدون خوادم: Lambda وAPI Gateway وDynamoDB

2026-11-02T00:00:00Z

في الجزء العشرين تركنا إدارة السيرفرات، بس المهام لسا شغالة طول الوقت، تنتظر زوار يمكن ما يجون. طيب لو كودك يشتغل بس لما يجي طلب، وما تدفع شي غير كذا؟

هذا هو بدون خوادم (Serverless). طبعاً السيرفرات موجودة، بس تجهيزها وتحديثها وتوسيعها ما عاد مشكلتك.

	EC2	Fargate	Lambda
تدير	النظام والتطبيق	الصورة والتطبيق	الكود
تدفع على	وقت التشغيل	وقت التشغيل	كل طلب ومدته
وقت الفراغ	تدفع	تدفع	شبه لا شي
التوسع	أنت تجهزه	أنت تجهزه	لحاله
مدة التشغيل	كيف ما تبي	كيف ما تبي	حتى 15 دقيقة للطلب

AWS Lambda

Lambda تشغّل دالة (Function) تكتبها لما يطلقها حدث. تسوي شغلها، ثم تتوقف.

حدث يشغّل الدالة، تسوي شغلها وتتوقف. وتدفع على وقت تشغيلها فقط.

تدعم Python وNode.js وJava و.NET وRuby مباشرة، وأي لغة ثانية عبر Runtime خاص أو صورة حاوية. وهذي شكل الدالة في Python:

Python

def handler(event, context):
    name = event.get("name", "world")
    return {"message": f"Hello {name}"}

الـ event يحمل تفاصيل اللي صار، وشكله يعتمد على المصدر: حدث S3 فيه الحاوية والمفتاح مثلاً، وحدث API فيه المسار والهيدرز.

كم تكلف؟

تدفع على عدد الطلبات، وعلى المدة مضروبة في الذاكرة بوحدة GB-second. الأسعار هنا لـ x86 في مناطق أمريكا، والمجاني يغطي مليون طلب و400,000 GB-second كل شهر.

مثال: دالة بذاكرة 512 MB تشتغل 200 ملي ثانية، 5 مليون مرة في الشهر:

البند	الحساب	التكلفة
المدة	`5,000,000 x 0.2 s x 0.5 GB = 500,000` GB-second، ناقص 400,000 مجانية	1.67 دولار
الطلبات	5 مليون ناقص مليون مجانية، بـ 0.20 دولار للمليون	0.80 دولار
المجموع		حوالي 2.47 دولار

خمسة مليون طلب بأقل من قيمة قهوة. بس الحساب ممكن ينقلب: مع حمل كبير وثابت، السيرفر أو الحاوية ممكن تطلع أرخص، فاحسبها.

حدود لازم تعرفها

الحد	القيمة
الذاكرة	من 128 MB إلى 10,240 MB، والمعالج يرتفع معها
المدة	15 دقيقة للطلب
التخزين المؤقت	`/tmp` من 512 MB إلى 10 GB
حجم الحزمة	50 MB مضغوطة و250 MB بعد الفك، أو صورة حاوية 10 GB
التزامن	1,000 لكل منطقة افتراضياً، وممكن أقل في الحسابات الجديدة
حجم البيانات	6 MB للاستدعاء المتزامن، و1 MB لغير المتزامن

لو شغلك ياخذ أكثر من 15 دقيقة، قسّمه بـ Step Functions، أو استخدم حاوية.

التزامن (Concurrency)

كل بيئة تشغيل تخدم طلب واحد في نفس الوقت، فـ 100 طلب متزامن تحتاج 100 بيئة. وهذا الرقم هو التزامن، وكل الدوال في المنطقة تتشارك حد واحد. وش يصير لما توصله؟

الاستدعاء المتزامن، مثل من API، يجيه خطأ 429.
الاستدعاء غير المتزامن، مثل من S3، ينحفظ ويعيد المحاولة حتى 6 ساعات، ثم يروح لطابور الفشل أو وجهة الفشل لو حددتها.

والفخ المخفي إن دالة مشغولة وحدة ممكن تاكل الحد كله وتعطل الباقي. Reserved Concurrency يحجز حصة للدالة، وهي سقف لها كمان، فما تنحرم وما تحرم غيرها.

البداية الباردة (Cold Start)

لما يجي طلب وما فيه بيئة جاهزة، Lambda تنشئ وحدة وتحمل كودك أول. هذي البداية الباردة، وممكن تضيف من جزء من الثانية إلى عدة ثواني حسب اللغة وحجم الكود. وبعدها البيئة تبقى فترة وتخدم الطلبات اللي بعدها بسرعة. ووقت التجهيز هذا صار يتحاسب كمان منذ أغسطس 2025.

الأداة	كيف تشتغل	التكلفة
Provisioned Concurrency	تبقي عدد من البيئات جاهز دايماً، فما فيه بداية باردة لها	تدفع عليها طول ما هي جاهزة
SnapStart	تحفظ لقطة بعد التجهيز وتستعيد منها، لـ Java 11 وأحدث وPython 3.12 وأحدث و.NET 8 وأحدث	مجاني لـ Java، وبرسوم لـ Python و.NET

وما تقدر تجمع الاثنين على نفس الدالة. وSnapStart يقلل وقت البداية بس ما يضمن إزالته، فلو تحتاج استجابة سريعة جداً وثابتة، استخدم Provisioned Concurrency.

Lambda داخل VPC

افتراضياً الدالة تشتغل خارج VPC حقك، فتوصل للإنترنت وخدمات AWS العامة، بس ما توصل لـ RDS الخاص حقك. اربطها بـ VPC وتوصل له، مع نقطتين:

تفقد الوصول للإنترنت، إلا لو الـ Subnet يمر عبر NAT Gateway أو تستخدم نقاط اتصال.
ألف بيئة ممكن تفتح ألف اتصال بالقاعدة. وهذا اللي يحله RDS Proxy بإعادة استخدام اتصالات قليلة.

كود عند الحافة

ذكرنا طريقتين لتشغيل كود قصير على CloudFront. وهذا الفرق:

	CloudFront Functions	Lambda@Edge
اللغات	JavaScript	Node.js وPython
المدة	أقل من ملي ثانية	حتى 30 ثانية في أحداث المصدر
الوصول للشبكة	لا	نعم
الأحداث	طلب الزائر والرد عليه	هذي، مع طلب المصدر ورده
تناسب	التحويلات والهيدرز ومفاتيح الكاش	منطق أثقل والاتصال بخدمات ثانية

Amazon DynamoDB

Lambda تتوسع في ثواني لآلاف النسخ، وقاعدة البيانات التقليدية ما تحب هذا. DynamoDB قاعدة مفتاح وقيمة بدون خوادم: ما فيه سيرفرات، ولا اتصالات تديرها، واستجابة بالملي ثانية عند أي حجم، والبيانات منسوخة بين عدة مناطق توفر تلقائياً.

الجداول والعناصر والمفاتيح

الجدول فيه عناصر (Items)، وكل عنصر له حقول (Attributes)، وما يلزم يكون لعنصرين نفس الحقول. وأقصى حجم للعنصر 400 KB. والثابت هو المفتاح الأساسي:

`customer` (مفتاح التقسيم)	`order_id` (مفتاح الترتيب)	`total`	`status`	`coupon`
sara	1001	120	shipped
sara	1002	40	new	SAVE10
omar	1003	75	new

مفتاح التقسيم (Partition Key): يحدد وين ينحفظ العنصر. اختر واحد قيمه كثيرة ومتنوعة عشان يتوزع الحمل.
مفتاح الترتيب (Sort Key): اختياري، ويرتب العناصر اللي لها نفس مفتاح التقسيم، فتقدر تطلب "آخر طلبات سارة".

هذا الفرق الكبير عن القواعد العلائقية: ما فيه Joins، وتجيب العناصر بمفتاحها. فـ ابدأ من استعلاماتك وصمم الجدول عليها. ولو تبي تستعلم بحقل ثاني مثل status، أضف فهرس ثانوي عام (GSI).

أوضاع السعة

الوضع	كيف يشتغل	متى
On-demand	يتوسع لحاله وتدفع لكل طلب	حمل مجهول أو متغير، وابدأ به
Provisioned	تحدد القراءات والكتابات في الثانية، ومعها توسع تلقائي لو تبي	حمل ثابت ومتوقع، ويطلع أرخص

والسعة المحجوزة تنحسب بوحدات. وحدة القراءة (RCU) تعني قراءة وحدة قوية التناسق في الثانية لعنصر حتى 4 KB، أو قراءتين متناسقتين لاحقاً. ووحدة الكتابة (WCU) تعني كتابة وحدة في الثانية لعنصر حتى 1 KB. فقراءة 80 عنصر بحجم 3 KB في الثانية بتناسق قوي تحتاج 80 RCU، وكتابة 100 عنصر بحجم 512 بايت في الثانية تحتاج 100 WCU.

إضافات تستاهل تعرفها

الميزة	وش تسوي
DAX	كاش قدام الجدول، ينزل القراءة من الملي ثانية إلى الميكرو ثانية
Streams	سجل لكل تغيير يبقى 24 ساعة، ويقدر يشغّل Lambda
Global Tables	نسخ في عدة مناطق، وكلها تقبل الكتابة
TTL	يحذف العناصر تلقائياً بعد وقت تحدده، مثل الجلسات القديمة
Point-in-time Recovery	يرجع الجدول لأي ثانية خلال آخر 1 إلى 35 يوم
التكامل مع S3	يصدّر الجدول إلى S3 للتحليل، أو يستورد من S3 إلى جدول جديد

وين يقف DAX مقابل ElastiCache؟ DAX كاش شفاف لـ DynamoDB بدون تغيير يذكر في الكود. وElastiCache أعم، مثل حفظ نتائج محسوبة يديرها تطبيقك بنفسه.

وGlobal Tables متطابقة في النهاية افتراضياً، يعني الكتابة في منطقة توصل الباقي بعد تأخير بسيط. ولو تحتاج القراءة في أي منطقة تشوف آخر كتابة، فيه وضع التطابق القوي، ويحتاج ثلاث مناطق بالضبط وله قيود.

API Gateway: البوابة الأمامية

الدالة ما لها رابط ويب افتراضياً. API Gateway يستقبل الطلب عبر HTTPS ويمرره للدالة، ويتكفل باللي ما تبي تكتبه بنفسك: التحقق من الدخول، والتقييد، والإصدارات وغيرها.

الـ API الكلاسيكي بدون خوادم: كل جزء يتوسع مع الطلبات، وبدون زيارات ما تدفع شي تقريباً.

النوع	يناسب
HTTP API	أغلب الواجهات: أبسط وأرخص، وبحد ثابت 30 ثانية
REST API	ميزات أكثر: كاش ومفاتيح API والتحقق من الطلبات
WebSocket API	اتصالات باتجاهين، مثل الدردشة

وREST API له ثلاث أنواع: Edge-optimized عبر CloudFront لمستخدمين حول العالم، وRegional للمستخدمين القريبين، وPrivate لداخل VPC فقط.

وتقدر تحط خلفه دالة Lambda، أو أي عنوان HTTP، أو خدمة AWS مباشرة. مثلاً يرسل الطلب إلى SQS على طول بدون دالة بينهم. ولنقطة وصول وحدة بسيطة، Lambda عندها كمان Function URLs: رابط HTTPS مباشر للدالة، بدون هذي الإضافات.

مين يقدر يستدعي الـ API؟

الطريقة	تناسب
IAM	خدماتك وتطبيقاتك داخل AWS
Cognito	مستخدمين تطبيقك، وبنشرحه في الجزء الجاي
Lambda Authorizer	منطقك الخاص، مثل توكن من نظام ثاني

تحديد السرعة (Throttling)

API Gateway يحمي اللي وراه بتحديد عدد الطلبات، ويطبق الحدود من الأدق للأعم: لكل عميل، ثم لكل Method، ثم للحساب كامل في المنطقة. وبعد الحد يوصل العميل 429، ويقدر يعيد المحاولة. وفي REST API، Usage Plans مع مفاتيح API تعطي كل عميل سرعته وحصته، وهذا يناسب API تبيعها.

عملي: API شغال

بنبني عداد زيارات صفحات من قطع الرسم الثلاث. وكل شي هنا داخل المجاني لتجربة مثل هذي. من CloudShell، أنشئ الجدول:

Bash

aws dynamodb create-table --table-name series-visits \
  --attribute-definitions AttributeName=page,AttributeType=S \
  --key-schema AttributeName=page,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --query TableDescription.TableStatus

aws dynamodb wait table-exists --table-name series-visits

TABLE_ARN=$(aws dynamodb describe-table --table-name series-visits \
  --query Table.TableArn --output text)

أعط الدالة دور يكتب السجلات ويحدث هذا الجدول فقط:

Bash

cat > trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "lambda.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
EOF

ROLE_ARN=$(aws iam create-role --role-name series-visits-role \
  --assume-role-policy-document file://trust.json \
  --query Role.Arn --output text)

aws iam attach-role-policy --role-name series-visits-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

aws iam put-role-policy --role-name series-visits-role \
  --policy-name table-access --policy-document "{
    \"Version\": \"2012-10-17\",
    \"Statement\": [{
      \"Effect\": \"Allow\",
      \"Action\": \"dynamodb:UpdateItem\",
      \"Resource\": \"$TABLE_ARN\"
    }]
  }"

اكتب الدالة. تزيد واحد على عداد المسار المطلوب، والتحديث بهذي الطريقة آمن حتى مع الطلبات المتزامنة:

Bash

cat > app.py <<'EOF'
import json
import os
import boto3

table = boto3.resource("dynamodb").Table(os.environ["TABLE"])

def handler(event, context):
    page = event.get("rawPath", "/")
    result = table.update_item(
        Key={"page": page},
        UpdateExpression="ADD visits :one",
        ExpressionAttributeValues={":one": 1},
        ReturnValues="UPDATED_NEW",
    )
    visits = int(result["Attributes"]["visits"])
    return {
        "statusCode": 200,
        "headers": {"content-type": "application/json"},
        "body": json.dumps({"page": page, "visits": visits}),
    }
EOF

zip -q function.zip app.py

أنشئ الدالة. الدور الجديد ياخذ كم ثانية عشان يفعّل، فلو جاك خطأ عن الدور، انتظر شوي وأعد الأمر:

Bash

FN_ARN=$(aws lambda create-function --function-name series-visits \
  --runtime python3.13 --handler app.handler --role $ROLE_ARN \
  --zip-file fileb://function.zip \
  --environment "Variables={TABLE=series-visits}" \
  --query FunctionArn --output text)

aws lambda wait function-active-v2 --function-name series-visits

الحين البوابة. هذا الأمر ينشئ HTTP API يرسل كل المسارات للدالة، وبعدها نسمح له يستدعيها:

Bash

API_ID=$(aws apigatewayv2 create-api --name series-visits \
  --protocol-type HTTP --target $FN_ARN \
  --query ApiId --output text)

ACCOUNT=$(aws sts get-caller-identity --query Account --output text)

aws lambda add-permission --function-name series-visits \
  --statement-id api-gateway --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-arn "arn:aws:execute-api:$AWS_REGION:$ACCOUNT:$API_ID/*" \
  --query Statement --output text > /dev/null

URL=$(aws apigatewayv2 get-api --api-id $API_ID \
  --query ApiEndpoint --output text)
echo $URL

جربه. وتقدر تفتح الرابط في متصفحك كمان:

Bash

curl -s $URL/home; echo
curl -s $URL/home; echo
curl -s $URL/about; echo

العداد يزيد: home يوصل 2 وabout عند 1. شوف البيانات في الجدول:

Bash

aws dynamodb scan --table-name series-visits \
  --query "Items[].[page.S,visits.N]" --output table

وأخيراً، شوف البداية الباردة في سجلات الدالة:

Bash

aws logs tail /aws/lambda/series-visits --since 10m | grep REPORT

أول طلب بس فيه حقل Init Duration، وهو وقت تجهيز البيئة، واللي بعده أسرع بكثير. ولو كانت السجلات فاضية، انتظر كم ثانية وحاول مرة ثانية.

Bash

aws apigatewayv2 delete-api --api-id $API_ID
aws lambda delete-function --function-name series-visits
aws dynamodb delete-table --table-name series-visits \
  --query TableDescription.TableStatus
aws logs delete-log-group --log-group-name /aws/lambda/series-visits

aws iam delete-role-policy --role-name series-visits-role \
  --policy-name table-access
aws iam detach-role-policy --role-name series-visits-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
aws iam delete-role --role-name series-visits-role

الخلاصة

Serverless يعني تكتب الكود والبيانات، وتدفع على الاستخدام فقط.
Lambda تشتغل حتى 15 دقيقة، وتدفع لكل طلب ولكل GB-second.
البداية الباردة تخففها بـ Provisioned Concurrency أو SnapStart، وReserved Concurrency يحمي الدوال من بعضها.
DynamoDB تجيب العناصر بالمفتاح، فصمم الجدول على استعلاماتك.
API Gateway البوابة الأمامية، يتكفل بالدخول والتقييد، وابدأ بـ HTTP API.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 6

دالة Lambda مربوطة بـ VPC عشان توصل لقاعدة RDS خاصة. وهذا شغال، بس الحين اتصالاتها بمزود دفع على الإنترنت تنتهي مهلتها. وش يحل هذا؟

اعرض الجواب

الجواب الصحيح: C

لما تنربط الدالة بـ VPC تفقد الوصول للإنترنت، إلا لو كانت شبكتها تمر عبر NAT Gateway.

A: الشبكة العامة ما تعطي الدالة وصول للإنترنت ولا عنوان عام.
B: ما فيه طريق للإنترنت أصلاً، فالوقت الزيادة ما يفيد.
D: هذا يدير اتصالات القاعدة، والمشكلة في طريق الخروج.

للمراجعة: Lambda داخل VPC في هذا الجزء، وEnable internet access for VPC-connected Lambda Event Functions في وثائق AWS.

السؤال 2 من 6

جدول طلبات مفتاح التقسيم فيه customer ومفتاح الترتيب order_id. والفريق يحتاج الحين كل الطلبات اللي status فيها new، بسرعة وبشكل متكرر. وش يسوي؟

اعرض الجواب

الجواب الصحيح: D

الفهرس الثانوي العام يرتب البيانات بمفتاح مختلف، فتقدر تستعلم بـ status مباشرة.

A: هذا يقرأ كل العناصر كل مرة، فيبطأ وتزيد تكلفته كل ما كبر الجدول.
B: DynamoDB ما فيها Joins.
C: هذا يسرّع القراءات اللي تقدر عليها أصلاً، وما يضيف طريقة استعلام جديدة.

للمراجعة: الجداول والعناصر والمفاتيح في هذا الجزء، وUsing Global Secondary Indexes in DynamoDB في وثائق AWS.

السؤال 3 من 6

صفحة منتج تقرأ نفس عناصر DynamoDB ملايين المرات في اليوم. والفريق يبي القراءة تاخذ ميكرو ثانية، بأقل تغيير في الكود. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

DAX كاش قدام الجدول يتوافق مع واجهة DynamoDB، فيحتاج تغييرات بسيطة فقط.

B: هذا ممكن يكون سريع كمان، بس تطبيقك لازم يدير اللي يدخل ويطلع من الكاش.
C: هذا يحط نسخ في عدة Regions، وما ينزل القراءة إلى الميكرو ثانية.
D: هذا سجل بالتغييرات، وما يسرّع القراءة.

للمراجعة: إضافات تستاهل تعرفها في هذا الجزء، وIn-memory acceleration with DynamoDB Accelerator (DAX) في وثائق AWS.

السؤال 4 من 6

شركة تبيع الوصول لواجهة API حقها. وتحتاج مفاتيح API لكل عميل، وتحديد سرعة لكل عميل، وكاش للردود. أي خيار يناسب؟

اعرض الجواب

الجواب الصحيح: B

REST API فيه كل هذا. وHTTP API أبسط وأرخص لأنه يترك هذي الميزات.

A: هذا ما فيه مفاتيح API ولا كاش.
C: هذا للاتصالات باتجاهين، مثل المحادثة.
D: هذا رابط مباشر للدالة، بدون أي من هذي الإضافات.

للمراجعة: API Gateway: البوابة الأمامية في هذا الجزء، وChoose between REST APIs and HTTP APIs في وثائق AWS.

السؤال 5 من 6

دالة تقارير أحياناً تاكل حد التزامن كله في الـ Region، فتبدأ دالة الدفع ترجّع 429. ودالة الدفع لازم كمان ترد باستجابة ثابتة وسريعة جداً. أي إعدادين يناسبون دالة الدفع؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: A + C

Reserved Concurrency يحجز لدالة الدفع حصة ما تاخذها أي دالة ثانية، وProvisioned Concurrency يبقي البيئات جاهزة فما فيه بداية باردة لها.

B: هذا يقلل وقت البداية بدون ما يضمن إزالته، وما ينجمع مع Provisioned Concurrency.
D: هذا يزيد مساحة القرص المؤقت، وما له علاقة بأي مشكلة منهم.
E: المعالج يزيد مع الذاكرة، فهذا يبطئ الردود.

للمراجعة: التزامن (Concurrency) والبداية الباردة (Cold Start) في هذا الجزء، وConfiguring reserved concurrency for an Event Function وConfiguring provisioned concurrency for an Event Function في وثائق AWS.

السؤال 6 من 6

تطبيق يقرأ 50 عنصر في الثانية من جدول DynamoDB بوضع Provisioned. وكل عنصر حجمه 6 KB، والقراءة لازم تكون قوية التناسق. كم وحدة قراءة يحتاج؟

اعرض الجواب

الجواب الصحيح: C

وحدة RCU تغطي قراءة قوية التناسق في الثانية حتى 4 KB، فعنصر 6 KB يحتاج وحدتين. وخمسين قراءة في الثانية تحتاج 100.

A: هذا يحسب القراءة نص وحدة، وما يغطي عنصر 6 KB.
B: هذا يكفي لو كانت نفس القراءات متناسقة لاحقاً.
D: هذا يضرب في حجم العنصر، والوحدات تنحسب لكل 4 KB.

للمراجعة: أوضاع السعة في هذا الجزء، وDynamoDB provisioned capacity mode في وثائق AWS.

عندك الحين قطع البناء. كيف تبني منها تطبيق كامل، فيه مستخدمين وسير عمل طويل وأحداث تمشي بين الخدمات؟ هذا اللي بنغطيه في الجزء الثاني والعشرين.

الحاويات: ECS وFargate وEKS

2026-11-02T00:00:00Z

في الجزء التاسع عشر فصلنا الخدمات عن بعض. بس كل خدمة لسا تحتاج مكان تشتغل فيه، وعلى سيرفر EC2 هذا يعني صورة نظام، وتحديثات، ومكتبات، والجملة المشهورة: "عندي يشتغل".

الحاويات (Containers) تحل هذا: تغلف التطبيق مع كل اللي يحتاجه في حزمة وحدة، ويشتغل بنفس الطريقة على جهازك وفي الإنتاج.

وش هي الحاوية؟

الحاوية عملية معزولة لها ملفاتها ومكتباتها، وتتشارك نظام تشغيل المضيف بدل ما تحمل نظامها.

كل جهاز افتراضي يحمل نظام تشغيل كامل. الحاويات تتشارك نظام المضيف، فهي أخف وتشتغل في ثواني.

	الجهاز الافتراضي	الحاوية
يحتوي	نظام تشغيل كامل والتطبيق	التطبيق ومكتباته
الحجم	جيجابايتات	غالباً ميجابايتات
التشغيل	دقايق	ثواني
العزل	أقوى بنظام مستقل	أخف بنواة مشتركة

الصورة والحاوية والمستودع

ثلاث كلمات بتتكرر عليك:

الصورة (Image): حزمة للقراءة فقط فيها التطبيق ومكتباته، مثل الوصفة.
الحاوية (Container): نسخة شغالة من الصورة. والصورة الوحدة تشتغل كألف حاوية.
المستودع (Registry): مكان تخزين الصور، مثل Docker Hub أو Amazon ECR.

أشهر أداة لبناء الصور هي Docker. تكتب محتوى الصورة في ملف Dockerfile:

dockerfile

FROM nginx:alpine
COPY index.html /usr/share/nginx/html/

ثم تبنيها، وتجربها على جهازك، وترفعها للمستودع:

Bash

docker build -t shop .
docker run -p 8080:80 shop
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/shop

Amazon ECR: بيت صورك

ECR (Elastic Container Registry) مستودع الصور في AWS، وتخزينه على S3 من وراء الكواليس:

مستودعات خاصة: الوصول لها عبر IAM، فالسيرفر أو المهمة تحتاج صلاحية عشان تسحب.
مستودعات عامة: أي أحد يسحب منها، عبر معرض ECR Public.
إضافات: فحص الصور من الثغرات، وإصدارات بالوسوم، وقواعد دورة حياة تحذف الصور القديمة.

Amazon ECS: طريقة AWS لتشغيل الحاويات

ECS (Elastic Container Service) ياخذ صورك ويشغلها، ويبقيها شغالة، ويحطها خلف موزع حمل. هو خدمة AWS الخاصة، وأبسط من Kubernetes، والخدمة نفسها ما عليها رسوم إضافية. تدفع على السعة اللي تشتغل عليها.

أربع مصطلحات تغطي الخدمة كلها:

المصطلح	معناه	يشبه
Cluster	مجموعة منطقية تشتغل فيها المهام	أسطول سيرفراتك
Task Definition	وصفة: الصورة والمعالج والذاكرة والمنافذ والأدوار	قالب التشغيل
Task	حاوية شغالة أو أكثر من هذي الوصفة	السيرفر
Service	يبقي عدد محدد من المهام شغال، ويعوض اللي تفشل	مجموعة Auto Scaling

الـ Service يحافظ على عدد المهام اللي طلبته في مناطق التوفر، وموزع الحمل يوجه الزوار للمهام السليمة.

مين يشغّل الحاويات؟

الحاويات تحتاج سعة حوسبة، وعندك ثلاث خيارات:

الخيار	مين يدير السيرفرات	يناسب
Fargate	AWS بالكامل، وما تشوف أي سيرفر	أغلب التطبيقات، وابدأ به
Managed Instances	AWS تديرها، وأنت تختار أنواع السيرفرات	تحتاج GPU أو سيرفرات معينة بدون إدارتها
EC2	أنت، عبر مجموعة Auto Scaling	تحكم كامل، أو تقليل تكلفة حمل ثابت

مع Fargate تحدد المعالج والذاكرة للمهمة، وتدفع عليها طول ما هي شغالة. وFargate Spot يخفض السعر كثير للمهام اللي تتحمل الانقطاع، بنفس فكرة سيرفرات Spot.

دورين في IAM، والخلط بينهم كلاسيكي

كل مهمة على Fargate ممكن يكون لها دورين، وكل واحد له شغل مختلف:

الدور	مين يستخدمه	مثال
Task Execution Role	ECS نفسه، عشان يجهز المهمة	سحب الصورة من ECR وإرسال السجلات لـ CloudWatch
Task Role	كودك داخل الحاوية	القراءة من S3 أو الكتابة في DynamoDB

لو فشلت المهمة عند التشغيل بخطأ في السحب، شوف Execution Role. ولو جاء كودك AccessDenied وهو شغال، شوف Task Role. وخل لكل خدمة دورها، مو دور واحد مشترك.

الشبكة وتوزيع الحمل

على Fargate كل مهمة تاخذ واجهة شبكة خاصة فيها وIP خاص، فلها Security Group مثل السيرفر. وحط موزع حمل ALB قدام الـ Service، وهو يسجل المهام الجديدة تلقائياً ويشيل الفاشلة. وهذا يناسب أغلب تطبيقات الويب، وتختار NLB للسعة العالية جداً أو عناوين IP الثابتة.

التخزين

قرص الحاوية يروح معها. ولمشاركة الملفات بين المهام، اربط EFS، ويشتغل على Fargate وEC2. وأي شي مهم، خزنه خارج الحاوية في S3 أو قاعدة بيانات.

التوسع

Service Auto Scaling يغيّر عدد المهام حسب متوسط المعالج أو الذاكرة، أو الطلبات لكل مهمة من موزع الحمل، أو جدول زمني. والسياسات هي نفسها اللي شفناها في الجزء السابع.

وعلى Fargate هذا كل اللي تحتاجه. أما مع EC2 فيه طبقة ثانية، لأنك تحتاج سيرفرات تنزل عليها المهام الجديدة. Capacity Provider يربط الـ Service بمجموعة Auto Scaling ويزيد السيرفرات لما تحتاجها المهام.

مو بس خدمات ويب

المهام مو لازم تبقى شغالة دايماً. ثلاث أنماط معروفة:

النمط	كيف يشتغل
رد فعل على حدث	ينزل ملف في S3، وEventBridge يشغّل مهمة Fargate تعالجه، وتوقف لما تخلص
شغل مجدول	EventBridge Scheduler يشغّل مهمة كل ليلة لشغل دفعات
عمّال طابور	Service يسحب من SQS، ويتوسع حسب عدد الرسائل المنتظرة

ECS Express Mode: الطريق المختصر

تبي تطبيق ويب من صورة بدون ما تجهز كل قطعة؟ ECS Express Mode ياخذ صورة ودورين، وينشئ Service على Fargate وموزع حمل وفحوصات صحة وتوسع ورابط. وكلها تبقى في حسابك، فتقدر تعدلها بعدين.

Amazon EKS: Kubernetes

Kubernetes نظام مفتوح المصدر لتشغيل الحاويات، منتشر في كل السحابات ومراكز البيانات. EKS (Elastic Kubernetes Service) يشغّل لك طبقة التحكم فيه عبر عدة مناطق توفر، بـ 0.10 دولار في الساعة لكل Cluster للإصدارات اللي تحت الدعم العادي، فوق تكلفة السعة. والإصدار اللي تجاوز هذي الفترة يكلف 0.60 دولار في الساعة.

المصطلحات تختلف عن ECS: المهمة اسمها Pod، والسيرفر اسمه Node.

خيار الـ Nodes	كيف يشتغل
EKS Auto Mode	AWS تجهز الـ Nodes وتحدثها وتوسعها، وهو اللي توصي فيه AWS مستقبلاً
Managed Node Groups	AWS تنشئ السيرفرات وتحدثها، وأنت تختارها
Self-managed Nodes	أنت تتكفل بكل شي، للمتطلبات الخاصة
Fargate	كل Pod يشتغل معزول بدون Nodes، وهو متاح، بس Auto Mode مفضل عليه

وللتخزين، يستخدم EKS تعريفات CSI لربط EBS أو EFS أو FSx.

ECS أو EKS؟

	ECS	EKS
التعقيد	مفاهيم أقل وتعلم سريع	نظام كبير وفيه الكثير تتعلمه
النقل	AWS فقط	نفس الأدوات تشتغل في أي مكان
المنظومة	تكامل قريب مع AWS	منظومة مفتوحة ضخمة
تكلفة الخدمة نفسها	مجانية	بالساعة لكل Cluster
اختره لو	تبدأ من جديد وشغلك على AWS	فريقك يعرف Kubernetes أو تشتغل على أكثر من سحابة

لو ما فيه شي يدفعك لـ Kubernetes، ابدأ بـ ECS على Fargate.

حاويات على سيرفراتك

تحتاج نفس الأدوات خارج AWS، مثل مركز بياناتك؟

الخيار	وش يسوي
ECS Anywhere	يسجل سيرفراتك أو أجهزتك الافتراضية في مجموعة ECS
EKS Hybrid Nodes	يضيف سيرفراتك كعقد في مجموعة EKS
EKS Anywhere	يشغّل مجموعات Kubernetes على بنيتك، للبيئات المعزولة
EKS Distro	مكونات Kubernetes اللي يقوم عليها EKS، تشغلها وتدعمها بنفسك

عملي: Service يعوض مهمة وقفت

بنشغل صورة Nginx عامة على Fargate، بدون بناء شي. من CloudShell، أنشئ الـ Cluster واكتب الوصفة. والصورة من مستودع عام بدون سجلات ما تحتاج Execution Role:

Bash

aws ecs create-cluster --cluster-name series-cluster \
  --query cluster.status

cat > task.json <<'EOF'
{
  "family": "web",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [{
    "name": "web",
    "image": "public.ecr.aws/nginx/nginx:latest",
    "portMappings": [{"containerPort": 80}],
    "essential": true
  }]
}
EOF

aws ecs register-task-definition --cli-input-json file://task.json \
  --query taskDefinition.family

جهز الشبكة: الـ VPC الافتراضي، وSubnet، وSecurity Group يسمح بالمنفذ 80 من CloudShell حقك فقط:

Bash

VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true \
  --query "Vpcs[0].VpcId" --output text)
SUBNET=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC \
  --query "Subnets[0].SubnetId" --output text)

SG=$(aws ec2 create-security-group --group-name series-web \
  --description "Series web task" --vpc-id $VPC \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $SG \
  --protocol tcp --port 80 \
  --cidr $(curl -s https://checkip.amazonaws.com)/32

NET="awsvpcConfiguration={subnets=[$SUBNET],securityGroups=[$SG],assignPublicIp=ENABLED}"

شغّل مهمة وحدة. لو هذا أول استخدام لك لـ ECS وجاك خطأ عن الدور المرتبط بالخدمة، انتظر شوي وأعد الأمر:

Bash

TASK=$(aws ecs run-task --cluster series-cluster --task-definition web \
  --launch-type FARGATE --network-configuration "$NET" \
  --query "tasks[0].taskArn" --output text)

aws ecs wait tasks-running --cluster series-cluster --tasks $TASK

خذ عنوانها وجربها:

Bash

ENI=$(aws ecs describe-tasks --cluster series-cluster --tasks $TASK \
  --query "tasks[0].attachments[0].details[?name=='networkInterfaceId'].value" \
  --output text)
IP=$(aws ec2 describe-network-interfaces --network-interface-ids $ENI \
  --query "NetworkInterfaces[0].Association.PublicIp" --output text)

curl -s http://$IP | grep -i "<title>"

بتشوف <title>Welcome to nginx!</title>. أول حاوية لك شغالة، بدون أي سيرفر تشوفه. الحين أوقفها، وبتبقى واقفة لأن ما فيه أحد يهتم فيها:

Bash

aws ecs stop-task --cluster series-cluster --task $TASK \
  --query task.lastStatus

أنشئ Service يبقي مهمة وحدة شغالة:

Bash

aws ecs create-service --cluster series-cluster --service-name web \
  --task-definition web --desired-count 1 --launch-type FARGATE \
  --network-configuration "$NET" --query service.status

aws ecs wait services-stable --cluster series-cluster --services web

FIRST=$(aws ecs list-tasks --cluster series-cluster --service-name web \
  --query "taskArns[0]" --output text)
echo $FIRST

aws ecs stop-task --cluster series-cluster --task $FIRST \
  --query task.lastStatus

انتظر دقيقة، ثم اعرض المهام:

Bash

aws ecs list-tasks --cluster series-cluster --service-name web \
  --query taskArns

الرقم تغير. الـ Service لاحظ إن المهمة راحت وشغل غيرها بدون ما تحرك إصبع.

Bash

aws ecs delete-service --cluster series-cluster --service web --force \
  --query service.status
aws ecs wait services-inactive --cluster series-cluster --services web
aws ecs delete-cluster --cluster series-cluster --query cluster.status
aws ecs deregister-task-definition --task-definition web:1 \
  --query taskDefinition.status
aws ec2 delete-security-group --group-id $SG

الخلاصة

الحاوية تغلف التطبيق ومكتباته وتتشارك نظام المضيف، فهي خفيفة وسريعة.
ECR يخزن الصور، وECS يشغلها عبر Task Definition وTask وService.
Fargate يريحك من إدارة السيرفرات، وهو أفضل بداية.
Execution Role لـ ECS، وTask Role لكودك.
EKS لمن يحتاج Kubernetes، وECS Express Mode الطريق المختصر لتطبيق ويب.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 6

مهمة على Fargate تبدأ عادي وتخدم الزيارات، بس لما يكتب كودها في DynamoDB يطلع له AccessDenied. وين يضيف الفريق الصلاحية؟

اعرض الجواب

الجواب الصحيح: D

الـ Task Role لكودك داخل الحاوية. وبداية المهمة العادية تبين إن Execution Role شغال زي ما ينبغي.

A: هذا يستخدمه ECS عشان يجهز المهمة، مثل سحب الصورة وإرسال السجلات.
B: الـ Security Group يتحكم في زيارات الشبكة، وهذا الخطأ عن الصلاحيات.
C: Fargate ما فيه سيرفرات تربط فيها شي، فالـ Instance Profile مو متاح.

للمراجعة: دورين في IAM، والخلط بينهم كلاسيكي في هذا الجزء، وAmazon ECS task IAM role في وثائق AWS.

السؤال 2 من 6

شركة تشغّل تطبيقاتها على Kubernetes في مركز بياناتها وعلى سحابة ثانية. وفريقها يعرف أدوات Kubernetes كويس ويبي يكمل عليها في AWS. وش يناسب؟

اعرض الجواب

الجواب الصحيح: B

EKS يشغّل طبقة التحكم في Kubernetes لك، وأدوات الفريق تستمر تشتغل، هنا وفي غيرها.

A: هذي بداية ممتازة لأغلب التطبيقات، بس هو نظام AWS الخاص، مو Kubernetes.
C: هذا يبني خدمة ويب على ECS من صورة، وهو مو Kubernetes كمان.
D: هذا يشغّل دوال مع الأحداث، وما فيه Kubernetes.

للمراجعة: ECS أو EKS؟ في هذا الجزء، وWhat is Amazon EKS? في وثائق AWS.

السؤال 3 من 6

مهمة دفعية تشتغل في حاوية كل ليلة حوالي ساعتين، وما فيه شي يحتاج يشتغل باقي اليوم. وش يناسب بأقل تكلفة؟

اعرض الجواب

الجواب الصحيح: C

الجدول يبدأ مهمة تتوقف لما تخلص، وعلى Fargate تدفع بس وقت تشغيلها.

A: بتدفع على مهمة 24 ساعة في اليوم، عشان ساعتين شغل.
B: تشغيل Lambda ينتهي عند 15 دقيقة، وهذا أقل بكثير من ساعتين.
D: بتدفع على السيرفر طول الوقت، ولازم تديره كمان.

للمراجعة: مو بس خدمات ويب في هذا الجزء، وUsing Amazon EventBridge Scheduler to schedule Amazon ECS tasks في وثائق AWS.

السؤال 4 من 6

عدة مهام Fargate في Service واحد تحتاج تقرأ وتكتب نفس الملفات المرفوعة، والملفات لازم تبقى لما تتوقف مهمة. وش يربط الفريق؟

اعرض الجواب

الجواب الصحيح: A

EFS نظام ملفات مشترك تقدر المهام تربطه على Fargate وEC2، والملفات تبقى خارج أي مهمة.

B: قرص الحاوية يختفي معها، وما ينشارك مع المهام الثانية.
C: هذا قرص مؤقت على سيرفر، وFargate ما يعطيك سيرفر تربطه فيه.
D: هذا يخزن صور الحاويات، مو ملفات التطبيق.

للمراجعة: التخزين في هذا الجزء، وUse Amazon EFS volumes with Amazon ECS في وثائق AWS.

السؤال 5 من 6

ECS Service يشتغل على سيرفرات EC2 في مجموعة Auto Scaling. ووقت الذروة يحتاج مهام أكثر، وهذي المهام تحتاج سيرفرات تنزل عليها. أي ميزتين يعالجون هذا؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: A + E

Service Auto Scaling يغير عدد المهام، والـ Capacity Provider يضيف سيرفرات لما تحتاجها المهام. وعلى EC2 تحتاج الطبقتين.

B: هذا يخلي ECS يسحب الصور ويرسل السجلات، وما له علاقة بالتوسع.
C: هذا يدور ثغرات في الصور.
D: هذا يوزع الزيارات على المهام الموجودة، وما يضيف مهام.

للمراجعة: التوسع في هذا الجزء، وAutomatically scale your Amazon ECS service وAmazon ECS capacity providers for EC2 workloads في وثائق AWS.

السؤال 6 من 6

شركة تشغّل حاوياتها على ECS في AWS. وبعضها لازم الحين يشتغل على سيرفرات في مصنعها، والفريق يبي يكمل بنفس أدوات ECS. وش يناسب؟

اعرض الجواب

الجواب الصحيح: B

ECS Anywhere يسجل سيرفراتك أو أجهزتك الافتراضية في مجموعة ECS، فيكمل الفريق بأدواته.

A: هذي مكونات Kubernetes تشغلها وتدعمها بنفسك، والفريق يستخدم ECS.
C: هذا يشغّل المهام على سعة AWS بسعر أقل، مو على سيرفراتك.
D: هذا يشتغل في AWS، وما عاد يقبل عملاء جدد.

للمراجعة: حاويات على سيرفراتك في هذا الجزء، وAmazon ECS clusters for external instances في وثائق AWS.

الحاويات لسا تشتغل وتكلف وهي منتظرة. طيب لو كودك يشتغل بس لما يكون فيه شغل، وما تدفع شي غير كذا؟ في الجزء الحادي والعشرين نبني API بـ Lambda وAPI Gateway وDynamoDB.

ربط الخدمات: SQS وSNS وKinesis

2026-11-02T00:00:00Z

إلى الحين أجزاء تطبيقنا تتصل ببعض مباشرة. هذا تمام لين يبدأ العرض وما تلحق خدمة الفواتير، وفجأة العميل يطالع دائرة تحميل بسبب خدمة ما سمع فيها.

هذا القسم عن التطبيقات الحديثة، ويبدأ بالفكرة اللي وراء أغلبها: افصل الخدمات عن بعض، عشان كل وحدة تشتغل بسرعتها، وتعطل وحدة ما يوقف الباقي.

هذي خريطة الجزء:

تبي	استخدم
شغلة ياخذها عامل واحد وما تضيع	SQS
حدث واحد يوصل لأطراف كثيرة بنفس الوقت	SNS
تيار مستمر يقرأه أكثر من طرف ويعيد قراءته	Kinesis Data Streams
تيار ينزل في S3 أو غيره بدون كتابة كود	Data Firehose
تطبيق قائم مبني على RabbitMQ أو ActiveMQ	Amazon MQ

ليه تفصل الخدمات؟

لما تتصل الخدمات ببعض مباشرة، خدمة بطيئة وحدة تعطل العميل. الطابور يخلي كل طرف يشتغل بسرعته.

الاتصال المباشر يعني الطرفين لازم يكونون شغالين وسريعين في نفس اللحظة. ولما تحط طابور بينهم تكسب ثلاث أشياء:

العطل يبقى في مكانه. لو وقفت خدمة الفواتير، الرسائل تنتظر في الطابور لين ترجع.
الضغط ينمتص. ألف طلب في دقيقة ما توصل لقاعدة البيانات دفعة وحدة.
كل طرف يتوسع لحاله. تزيد عمّال الفواتير بدون ما تلمس المتجر.

SQS: الطابور

SQS (Simple Queue Service) طابور مُدار بالكامل بدون سيرفرات تديرها. المنتج يرسل الرسائل، وتنتظر في الطابور، والمستهلك يسحبها ويشتغل عليها ثم يحذفها.

انتبه للاتجاه: المستهلكين هم اللي يطلبون الرسائل من الطابور، والطابور ما يدفعها لأحد.

الخاصية	القيمة
السعة	بدون حد عملي في الطابور العادي
حجم الرسالة	حتى 1 MiB
مدة الحفظ	4 أيام افتراضياً، من دقيقة إلى 14 يوم
التوصيل	مرة على الأقل، فممكن تجيك الرسالة مرتين
الترتيب	أفضل محاولة، وغير مضمون

آخر نقطتين تأثر على كودك. بما إن الرسالة ممكن توصل مرتين، خل معالجتها مرتين ما تضر. رقم طلب تتأكد منه قبل الخصم يكفي.

وأي شي أكبر من رسالة، خزّن الملف في S3 وأرسل مساره في الرسالة.

مهلة الإخفاء (Visibility Timeout)

وش يمنع مستهلكين ياخذون نفس الرسالة؟ لما يستلمها واحد، يخفيها SQS عن الباقين لفترة اسمها Visibility Timeout. ولازم المستهلك يحذفها قبل ما تخلص الفترة.

الرسالة المستلمة تنخفي بس ما تنحذف. لو ما حذفها المستهلك قبل نهاية المهلة، ترجع تظهر لمستهلك ثاني.

هذي الآلية هي اللي تحميك من ضياع الشغل: لو طاح السيرفر في نص المعالجة، الرسالة ترجع لحالها.

اختر الفترة حسب وقت معالجتك. هي 30 ثانية افتراضياً، وتوصل إلى 12 ساعة:

قصيرة زيادة: الرسالة ترجع تظهر وهي لسا تحت المعالجة، فتنعالج مرتين.
طويلة زيادة: لو فشل مستهلك، الرسالة تنتظر طويل قبل ما أحد يعيد المحاولة.

ولو شغلة أخذت وقت أطول من المعتاد، المستهلك يقدر يمدد الفترة لهذي الرسالة بـ ChangeMessageVisibility.

الانتظار الطويل (Long Polling)

افتراضياً، لما تسأل طابور فاضي يرجع لك رد فاضي فوراً، فمستهلكينك يملون فاتورتك بطلبات ما لها داعي. مع Long Polling الطلب ينتظر حتى 20 ثانية لين تجي رسالة. يعني طلبات أقل، وتكلفة أقل، ووصول أسرع، فشغّله دايماً.

طابور الرسائل الفاشلة (DLQ)

طيب ورسالة تفشل كل مرة بسبب خطأ في الكود أو بيانات غلط؟ بترجع للأبد. اربط Dead-Letter Queue: بعد عدد محاولات تحدده، الرسالة تنتقل له، فتفحصها بدون ما تعطل شي. وبعد ما تصلح المشكلة، تقدر تعيدها للطابور الأصلي بـ Redrive.

وخل مدة الحفظ في طابور الرسائل الفاشلة أطول من الأصلي، عشان ما تنتهي الرسائل قبل ما تشوفها.

طوابير FIFO

لما يكون الترتيب مهم، مثل عمليات على نفس الحساب، استخدم طابور FIFO. ولازم اسمه ينتهي بـ .fifo.

	العادي	FIFO
الترتيب	غير مضمون	مضمون داخل مجموعة الرسائل
التكرار	ممكن	ينحذف خلال نافذة 5 دقايق
السعة	بدون حد عملي	300 رسالة في الثانية، أو 3,000 مع الدفعات

الترتيب يكون داخل مجموعة الرسائل (Message Group)، فلو خليت مجموعة لكل عميل، رسائل العملاء المختلفين تنعالج بالتوازي. ولو احتجت سعة أكبر، وضع السعة العالية يرفع الحد كثير، والرقم يختلف حسب المنطقة.

التوسع مع الطابور

نمط كلاسيكي: مجموعة Auto Scaling من العمّال تكبر وتصغر حسب طول الطابور. مقياس ApproximateNumberOfMessagesVisible يقول لك كم رسالة تنتظر، فلما يطول الطابور يزيد العمّال.

وهذا يحمي قاعدة بياناتك كمان. بدل ما تضرب موجة طلبات RDS مباشرة، تدخل في طابور، والعمّال يكتبونها بسرعة تتحملها القاعدة. وهذا يناسب الشغل اللي ما يحتاج جواب فوري فقط، فالعميل يوصله "استلمنا طلبك"، مو "اكتمل طلبك".

الأمان

الرسائل مشفرة أثناء النقل بـ HTTPS، وفي التخزين بـ SSE-SQS افتراضياً أو بمفتاح KMS خاص فيك. ومين يوصل للطابور تحدده سياسات IAM، مع سياسة وصول على الطابور نفسه، وتحتاجها لحسابات ثانية أو لخدمات مثل SNS وS3 عشان ترسل له. وبنكتب وحدة في التجربة العملية.

الطابور يناسب شغلة يسويها طرف واحد. بس لما يطلب عميل، خدمات الشحن والفواتير والتحليل كلها تبي تدري. وما تبي تطبيقك يعرف كل وحدة فيها، ويتغير كل ما أضفت وحدة.

SNS (Simple Notification Service) يشتغل بـ النشر والاشتراك: تطبيقك ينشر رسالة وحدة في موضوع (Topic)، وSNS يوصلها لكل المشتركين فوراً. والموضوع العادي يتحمل حتى 12.5 مليون اشتراك.

نوع المشترك	مثال
SQS	خدمة تعالج بسرعتها
Lambda	دالة صغيرة تشتغل مع كل رسالة
HTTP أو HTTPS	رابط Webhook في نظام ثاني
Data Firehose	تخزين كل رسالة في S3
إيميل وSMS وإشعارات الجوال	تنبيه الناس مباشرة

وعلى عكس الطابور، SNS ما يخزن الرسائل. لو كان مشترك واقف يعيد المحاولة لفترة، بس هو مو مكان تنتظر فيه الرسائل.

وحجم الرسالة 256 KiB افتراضياً، وتقدر ترفعه على الموضوع إلى 1 MiB، بس هذا يحصره في 100 اشتراك ولمشتركي SQS وLambda وFirehose فقط.

أهم نمط هنا يجمع الخدمتين: SNS ينشر الرسالة، وطابور لكل خدمة يحفظها لين تكون الخدمة جاهزة.

التطبيق ينشر مرة وحدة، وSNS ينسخ الرسالة لكل طابور، وكل خدمة تقرأ من طابورها. والفلتر يرسل الطلبات المادية فقط للشحن.

ليه هذا الجمع؟

ما يضيع شي: لو وقفت خدمة الشحن، رسائلها تنتظر في طابورها.
كل خدمة لها سرعتها، ومحاولاتها، وطابور رسائلها الفاشلة.
إضافة خدمة سهلة: طابور جديد يشترك في الموضوع، بدون تغيير الناشر.

ونفس الشي مع أحداث S3: S3 ما يقبل قاعدتين ببادئات متداخلة لنفس نوع الحدث. فعشان توصل لأكثر من وجهة، أرسل الحدث لموضوع SNS واحد ووزعه من هناك.

فلترة الرسائل

افتراضياً كل مشترك يستلم كل شي. سياسة الفلترة على الاشتراك تخلي طابور الشحن يستلم اللي يخصه فقط:

JSON

{ "type": ["physical"] }

الرسائل اللي type فيها digital ما توصله، وما تدفع على معالجتها.

مواضيع FIFO

عشان الترتيب في الـ Fan-out، SNS عنده مواضيع FIFO، وأسماؤها تنتهي بـ .fifo برضو، مع ترتيب وحذف للتكرار مثل طوابير FIFO. ومحدودة بـ 100 اشتراك للموضوع، وتناسب حالات مثل إرسال نفس تسلسل التحديثات لأكثر من طابور.

Kinesis Data Streams: تيار يبقى

تخيل مليون حساس يرسلون قراءات كل ثانية، وثلاث أطراف تبي تقرأها: واحد للتنبيهات الفورية، وواحد للوحات المتابعة، وواحد للأرشفة. الطابور ما يناسب هنا، لأن الرسالة تروح بعد معالجتها.

Kinesis Data Streams تيار: السجلات تبقى فيه طول مدة الحفظ سواء انقرأت أو لا، وكل مستهلك يقرأ من موضعه، فيقدر يرجع ويعيد القراءة.

المنتجين يكتبون في الـ Shards، والسجلات بنفس المفتاح تبقى مرتبة داخل Shard واحد، وأكثر من مستهلك يقرأ نفس البيانات، كل واحد من موضعه.

Shards: التيار ينقسم إلى أجزاء. في السعة المحددة، كل واحد ياخذ 1 MB في الثانية كتابة و2 MB في الثانية قراءة.
مفتاح التقسيم: يحدد أي Shard يروح له السجل. السجلات بنفس المفتاح تبقى مرتبة، فرقم الحساس مفتاح ممتاز.
مدة الحفظ: 24 ساعة افتراضياً، وتوصل إلى 365 يوم.
حجم السجل: 1 MiB افتراضياً، وتقدر ترفعه إلى 10 MiB لكل تيار.

أوضاع السعة

الوضع	كيف يشتغل	متى
On-demand	يبدأ بـ 4 MB في الثانية كتابة ويتوسع لحاله، وتدفع على البيانات	حمل مجهول أو متغير، وابدأ به
Provisioned	تحدد عدد الـ Shards وتدفع على كل واحد بالساعة	حمل ثابت ومعروف، وممكن يكون أرخص

وسقف On-demand يختلف حسب المنطقة: حتى 10 GB في الثانية كتابة في أكبر المناطق، و200 MB في الثانية في غيرها.

وللفيديو خدمة خاصة: Kinesis Video Streams تستقبل فيديو مباشر من أجهزة مثل الكاميرات، وتحفظه، وتخليك تشاهده أو تعالجه، مباشرة أو بعدين.

Data Firehose: للتخزين بدون كود

كثير من الأحيان كل اللي تبيه إن التيار ينزل في مكان. Amazon Data Firehose (اسمه القديم Kinesis Data Firehose) ياخذ البيانات، ويجمعها، ويوصلها بدون كود ولا سيرفرات:

المصادر: تطبيقك مباشرة، أو تيار Kinesis، أو غيرها مثل SNS وCloudWatch Logs.
المعالجة: يقدر يحوّل السجلات بدالة Lambda لو تبي، ويحولها إلى Parquet.
الوجهات: S3 وRedshift وOpenSearch وSnowflake وجداول Apache Iceberg، أو رابط HTTP.
التجميع: يجمع البيانات لين توصل حجم أو مدة، مثل 5 MiB أو 5 دقايق لـ S3، واللي يجي أول يطلق التوصيل. فهو يناسب التحميل شبه الفوري، مو رد الفعل اللحظي.

	Kinesis Data Streams	Data Firehose
الغرض	تيار يقرأه مستهلكينك	أنبوب يوصل للتخزين
المستهلكين	أنت تكتبهم	الوجهة جاهزة
إعادة القراءة	نعم، خلال مدة الحفظ	لا
التوقيت	فوري	حسب التجميع اللي تحدده

أيها أختار؟

	SQS	SNS	Kinesis Data Streams
الطريقة	المستهلك يسحب	يدفع للمشتركين	المستهلك يسحب
من يقرأ الرسالة	واحد، ثم تنحذف	كل المشتركين	الكل، خلال مدة الحفظ
تنحفظ؟	حتى 14 يوم	لا	حتى 365 يوم
الترتيب	مع FIFO	مع FIFO	داخل الـ Shard
الاستخدام المعتاد	شغل في الخلفية	إشعارات وFan-out	تحليل وسجلات وبيانات متدفقة

قاعدة سريعة: شغلة؟ SQS. حدث يهم كثيرين؟ SNS. تيار بيانات يقرأه كثيرين ويعيدون قراءته؟ Kinesis.

وفيه كمان EventBridge يوزع الأحداث بقواعد من خدمات AWS وتطبيقات ثانية، وبنشرحه في الجزء الخامس والعشرين.

Amazon MQ: للي موجود أصلاً

SQS وSNS خدمات AWS الخاصة بواجهاتها الخاصة. لو تنقل تطبيق مبني على بروتوكولات مفتوحة مثل AMQP أو MQTT أو STOMP، ما تبي تعيد كتابته. Amazon MQ يشغّل لك وسيط معروف كخدمة مُدارة، بمحركين:

المحرك	التوفر العالي
ActiveMQ	وسيطين في منطقتي توفر، نشط واحتياطي، بتخزين مشترك على EFS
RabbitMQ	مجموعة من ثلاث عقد في مناطق توفر مختلفة، خلف نقطة وصول وحدة

ولاحظ إنه يشتغل على وسطاء تختار حجمهم، فما يتوسع بلا حدود مثل SQS وSNS. وللتطبيق الجديد، ابدأ بهذيك الخدمتين.

عملي: Fan-out مع فلتر

بنبني تصميم الرسم بطابورين. من CloudShell، أنشئ الموضوع والطوابير:

Bash

TOPIC_ARN=$(aws sns create-topic --name orders \
  --query TopicArn --output text)

SHIP_URL=$(aws sqs create-queue --queue-name shipping \
  --query QueueUrl --output text)
BILL_URL=$(aws sqs create-queue --queue-name billing \
  --query QueueUrl --output text)

SHIP_ARN=$(aws sqs get-queue-attributes --queue-url $SHIP_URL \
  --attribute-names QueueArn --query Attributes.QueueArn --output text)
BILL_ARN=$(aws sqs get-queue-attributes --queue-url $BILL_URL \
  --attribute-names QueueArn --query Attributes.QueueArn --output text)

الطوابير خاصة، فاسمح لهذا الموضوع فقط يرسل لها:

Bash

allow_topic() {
  POLICY=$(jq -nc --arg q "$2" --arg t "$TOPIC_ARN" '{
    Version: "2012-10-17",
    Statement: [{
      Effect: "Allow",
      Principal: {Service: "sns.amazonaws.com"},
      Action: "sqs:SendMessage",
      Resource: $q,
      Condition: {ArnEquals: {"aws:SourceArn": $t}}
    }]
  }')
  aws sqs set-queue-attributes --queue-url "$1" \
    --attributes "$(jq -nc --arg p "$POLICY" '{Policy: $p}')"
}

allow_topic $SHIP_URL $SHIP_ARN
allow_topic $BILL_URL $BILL_ARN

اشترك بالطوابير في الموضوع: الفواتير تاخذ كل شي، والشحن ياخذ الطلبات المادية فقط:

Bash

aws sns subscribe --topic-arn $TOPIC_ARN \
  --protocol sqs --notification-endpoint $BILL_ARN \
  --attributes RawMessageDelivery=true

aws sns subscribe --topic-arn $TOPIC_ARN \
  --protocol sqs --notification-endpoint $SHIP_ARN \
  --attributes '{"RawMessageDelivery":"true","FilterPolicy":"{\"type\":[\"physical\"]}"}'

انشر طلبين، واحد مادي وواحد رقمي:

Bash

aws sns publish --topic-arn $TOPIC_ARN --message "order 1: a book" \
  --message-attributes '{"type":{"DataType":"String","StringValue":"physical"}}'

aws sns publish --topic-arn $TOPIC_ARN --message "order 2: an e-book" \
  --message-attributes '{"type":{"DataType":"String","StringValue":"digital"}}'

عطه كم ثانية، ثم عد الرسائل في كل طابور:

Bash

for url in $BILL_URL $SHIP_URL; do
  aws sqs get-queue-attributes --queue-url $url \
    --attribute-names ApproximateNumberOfMessages \
    --query Attributes.ApproximateNumberOfMessages --output text
done

بتشوف 2 للفواتير و1 للشحن، يعني الفلتر اشتغل. الحين جرب مهلة الإخفاء. استلم رسالة الشحن، ثم حاول مرة ثانية على طول:

Bash

aws sqs receive-message --queue-url $SHIP_URL --wait-time-seconds 5 \
  --query "Messages[0].Body" --output text

aws sqs receive-message --queue-url $SHIP_URL --wait-time-seconds 5 \
  --query "Messages[0].Body" --output text

الأول يطبع order 1: a book، والثاني ينتظر خمس ثواني ويطبع None، لأن الرسالة مخفية. وما حذفناها، فانتظر 30 ثانية واستلمها مرة ثانية، وهالمرة احذفها عشان ينتهي الشغل:

Bash

HANDLE=$(aws sqs receive-message --queue-url $SHIP_URL --wait-time-seconds 20 \
  --query "Messages[0].ReceiptHandle" --output text)

aws sqs delete-message --queue-url $SHIP_URL --receipt-handle "$HANDLE"

الحين الرسالة راحت نهائياً.

Bash

aws sns delete-topic --topic-arn $TOPIC_ARN
aws sqs delete-queue --queue-url $SHIP_URL
aws sqs delete-queue --queue-url $BILL_URL

الخلاصة

فصل الخدمات يحصر الأعطال، ويمتص الضغط، ويخلي كل طرف يتوسع لحاله.
SQS طابور: الرسالة تروح لمستهلك واحد، ولازم يحذفها قبل نهاية مهلة الإخفاء.
أضف دايماً Long Polling وDLQ، وخل المعالجة آمنة لو تكررت.
SNS يوصل رسالة وحدة للكل، وFan-out مع SQS يضمن ما تفوت أحد.
Kinesis Data Streams يحفظ البيانات لأكثر من قارئ يعيد قراءتها، وFirehose يوصلها للتخزين بدون كود.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 6

صفحة الطلبات في موقع تذاكر تكتب مباشرة على RDS. ولما تنفتح تذاكر حفلة كبيرة، تنضغط القاعدة وتفشل الطلبات. والعملاء يتقبلون رسالة "استلمنا طلبك"، والتأكيد يوصل بعد دقيقة. وش يمتص الضغط؟

اعرض الجواب

الجواب الصحيح: B

الطابور يحفظ الطلبات، والعمال يكتبونها بسرعة تتحملها القاعدة. وهذا يناسب الحالة لأن العميل ما يحتاج الجواب النهائي فوراً.

A: نسخ القراءة تخدم القراءة، والضغط هنا من الكتابة.
C: SNS يوصّل فوراً وما يحفظ الرسائل، فالضغط بيوصل كله مرة وحدة.
D: النسخة الاحتياطية ما تاخذ أي حمل، فيبقى الضغط.

للمراجعة: التوسع مع الطابور في هذا الجزء، وWhat is Amazon Simple Queue Service? في وثائق AWS.

السؤال 2 من 6

عامل ياخذ حوالي دقيقتين لإنتاج كل فاتورة، ومهلة الإخفاء في الطابور لسا على قيمتها الافتراضية. والعملاء يوصلهم نفس الفاتورة كم مرة. وش يغيّر الفريق؟

اعرض الجواب

الجواب الصحيح: A

بعد 30 ثانية ترجع الرسالة تظهر والعامل الأول لسا شغال عليها، فياخذها عامل ثاني كمان. ولازم تكون المهلة أطول من وقت الشغل.

B: هذا يقلل الردود الفاضية، وما يغير متى ترجع الرسالة.
C: هذا يلقط الرسائل اللي تفشل دايماً، وهذي تنجح وتتكرر.
D: العمال الزيادة بس ياخذون الرسائل اللي ترجع بشكل أسرع.

للمراجعة: مهلة الإخفاء (Visibility Timeout) في هذا الجزء، وAmazon SQS visibility timeout في وثائق AWS.

السؤال 3 من 6

لما ينعمل طلب، خدمات الشحن والفوترة والتحليل كلها تحتاج تعرف. وأي واحدة منها ممكن تتعطل ساعات، وإضافة خدمة جديدة ما لازم تغير الناشر. وش يناسب؟

اعرض الجواب

الجواب الصحيح: D

SNS يوصّل الرسالة الوحدة لكل مشترك، وطابور كل خدمة يحفظها لين تكون الخدمة جاهزة. والخدمة الجديدة بس تشترك بطابور جديد.

A: كل رسالة تروح لمستهلك واحد، فباقي الخدمات تفوتها.
B: الناشر لازم يتغير مع كل خدمة جديدة.
C: SNS يعيد المحاولة فترة بس وما يحفظ الرسائل، فالعطل الطويل ممكن يضيعها.

للمراجعة: Fan-out: SNS مع SQS في هذا الجزء، وWhat is Amazon SNS? في وثائق AWS.

السؤال 4 من 6

حساسات مزرعة رياح ترسل قراءات كل ثانية. وثلاث تطبيقات منفصلة تقرأ نفس البيانات مباشرة، وبعد إصلاح خطأ لازم واحد منها يعيد قراءة آخر ثلاثة أيام. أي خيار يناسب؟

اعرض الجواب

الجواب الصحيح: C

السجلات تبقى في التيار طول مدة الاحتفاظ سواء انقرأت أو لا، وكل مستهلك يقرأ من موقعه، فيقدر واحد يرجع ورا بدون ما يأثر على الباقي. والمدة الافتراضية 24 ساعة فقط.

A: الرسالة تروح لمستهلك واحد، وتروح لما تنحذف.
B: SNS ما يحفظ الرسائل، فما فيه شي تعيد قراءته.
D: هذا يجمّع البيانات ويوصلها للتخزين، فما يعطي قراءة فورية ولا إعادة قراءة.

للمراجعة: Kinesis Data Streams: تيار يبقى في هذا الجزء، وChange the data retention period في وثائق AWS.

السؤال 5 من 6

بنك يعالج المعاملات عبر طابور. وداخل كل حساب لازم تمشي بالترتيب مع إزالة التكرار، والحسابات المختلفة لازم تتعالج بالتوازي. أي خيارين يناسبون؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: B + D

طابور FIFO يحافظ على الترتيب داخل مجموعة الرسائل ويزيل التكرار خلال 5 دقايق، ومجموعة لكل حساب تخلي الحسابات المختلفة تمشي بالتوازي.

A: هذا ما يضمن الترتيب، والرسالة ممكن توصل مرتين.
C: هذا يحط كل المعاملات في صف واحد، فما يمشي شي بالتوازي.
E: هذا يعطي العمال وقت أكثر، وما يأثر على الترتيب.

للمراجعة: طوابير FIFO في هذا الجزء، وFIFO queue delivery logic in Amazon SQS في وثائق AWS.

السؤال 6 من 6

مصنع يبي يرسل فيديو مباشر من كاميرات المراقبة إلى AWS، ويحفظه، ويحلله بعدين. أي خدمة مبنية لهذا؟

اعرض الجواب

الجواب الصحيح: D

تستقبل فيديو مباشر من الأجهزة، وتحفظه، وتخليك تشاهده أو تعالجه، مباشرة أو بعدين.

A: هذا يوصّل السجلات للتخزين، وما هو مبني لفيديو مباشر من الأجهزة.
B: الرسالة تحمل حتى 1 MiB، وهذا ما يناسب الفيديو.
C: هذا يدفع رسائل قصيرة للمشتركين، وما يحفظ شي.

للمراجعة: Kinesis Data Streams: تيار يبقى في هذا الجزء، وWhat is Amazon Kinesis Video Streams? في وثائق AWS.

الخدمات الحين مفصولة، بس وين يشتغل الكود نفسه؟ إلى الآن جوابنا سيرفر EC2 بكل إعداداته. في الجزء العشرين نغلف التطبيقات في حاويات ونشغلها بـ ECS وFargate وEKS.

خدمات تخزين ونقل إضافية

2026-11-02T00:00:00Z

في الأجزاء السابقة غطينا S3 بالتفصيل. بس فيه حالات ما يحلها: تطبيق Windows يحتاج مجلد مشترك، أو خوادم في مكتبك تبي توصل للسحابة، أو شريك يرسل ملفاته عبر SFTP، أو بيانات ضخمة تحتاج تنقلها.

هذي خريطة الجزء:

تبي	استخدم
نظام ملفات Windows أو أداء عالي جداً	Amazon FSx
خوادم مكتبك توصل لتخزين السحابة	Storage Gateway
نقل ومزامنة بيانات كبيرة بشكل مجدول	DataSync
شركاء يرفعون ملفات عبر SFTP	Transfer Family
نقل كميات هائلة فعلياً	Data Transfer Terminal

Amazon FSx: أنظمة ملفات جاهزة

شفنا EFS لنظام ملفات Linux مشترك. FSx يشغّل لك أنظمة ملفات معروفة كخدمة مُدارة، فما تحتاج تديرها بنفسك:

النوع	البروتوكول	يناسب
FSx for Windows	SMB	تطبيقات Windows ومجلدات مشتركة، ومربوط بـ Active Directory
FSx for Lustre	Lustre	الحوسبة العالية وتدريب النماذج، ويتكامل مع S3، ولأجهزة Linux فقط
FSx for NetApp ONTAP	NFS وSMB وiSCSI	نقل أنظمة NetApp، وأنظمة تشغيل مختلفة على نفس البيانات
FSx for OpenZFS	NFS	أحمال Linux، ونقل أنظمة ZFS، ولقطات ونسخ فورية

واختيار FSx for Lustre فيه خيارين: Scratch رخيص وسريع لبيانات مؤقتة، بس البيانات ما لها نسخ، فلو تعطل قرص تضيع. وPersistent لبيانات طويلة المدى مع نسخ داخل منطقة التوفر.

Storage Gateway: مكتبك والسحابة

عندك خوادم في مكتبك وتبي تستفيد من السحابة، بدون تغيير التطبيقات؟ Storage Gateway برنامج تشغّله عندك كجهاز افتراضي، ويقدم تخزين عادي لتطبيقاتك، وبياناته فعلياً في AWS، مع كاش محلي للملفات الأخيرة.

التطبيقات في مكتبك تشوف تخزين عادي عبر Gateway، وهو يحفظ البيانات في S3 أو لقطات EBS أو Glacier.

النوع	تشوفه تطبيقاتك كـ	وين البيانات	مثال
S3 File Gateway	مجلد NFS أو SMB	كائنات في S3	مجلدات مشتركة ونسخ احتياطية للملفات
Volume Gateway	قرص iSCSI	S3 مع لقطات EBS	أقراص لخوادم قائمة، بكاش أو نسخة كاملة محلية
Tape Gateway	مكتبة أشرطة افتراضية	S3 ثم Glacier	برامج نسخ احتياطي تعتمد على الأشرطة

وفيه نوع رابع اسمه FSx File Gateway ما عاد متاح للعملاء الجدد، وAWS تنصح بالاتصال بـ FSx مباشرة.

نقل البيانات

DataSync

DataSync ينقل ويزامن بيانات كبيرة بشكل مجدول:

من وين وإلى وين: من خوادم NFS أو SMB أو HDFS أو تخزين كائني، إلى S3 أو EFS أو FSx، وبين خدمات AWS نفسها.
وكيل: تحتاج تشغّل وكيل (Agent) عندك للنقل من مكتبك، وما تحتاجه بين خدمات AWS.
ينقل اللي تغيّر فقط في كل تشغيل، ويحافظ على الصلاحيات والتواريخ، ويتحقق من سلامة البيانات.

Transfer Family

عندك شركاء أو أنظمة قديمة ترسل ملفات عبر SFTP أو FTPS أو FTP أو AS2، وما تبي تدير سيرفر لها؟ Transfer Family يعطيك نقطة استقبال مُدارة، والملفات تروح لـ S3 أو EFS. والمستخدمين من داخله، أو Active Directory، أو نظام هوية خاص فيك.

ولاحظ إن FTP غير مشفّر، فما يتوفر إلا داخل VPC. وتدفع بالساعة على كل نقطة، حتى بدون استخدام.

لما تكون البيانات أضخم من الإنترنت

قبل ما تختار طريقة النقل، احسب. هذي المدة النظرية بسرعة الخط كاملة، والواقع أبطأ:

الحجم	100 ميجابت	1 جيجابت	10 جيجابت
1 TB	22 ساعة	ساعتين	13 دقيقة
10 TB	9 أيام	22 ساعة	ساعتين
100 TB	93 يوم	9 أيام	22 ساعة
1 PB	سنتين ونص	93 يوم	9 أيام

عندك هذي الخيارات للكميات الكبيرة:

DataSync لو خطك يتحمل، مع مزامنة مستمرة.
Direct Connect لو النقل كبير ومستمر، وشرحناه في الجزء الرابع عشر.
Data Transfer Terminal: مواقع فعلية تجيبها بأجهزة تخزينك، وتوصلها بشبكة AWS بسرعة عالية.

مقارنة خدمات التخزين

الخدمة	النوع	تناسب
S3	كائني	ملفات وصور ونسخ احتياطية ومواقع ثابتة
S3 Glacier	كائني للأرشيف	بيانات نادراً ما تنطلب
EBS	قرص شبكي	قرص لسيرفر واحد وقواعد بيانات
Instance Store	قرص محلي مؤقت	أعلى سرعة لبيانات مؤقتة
EFS	ملفات لـ Linux	مجلد مشترك بين عدة سيرفرات
FSx for Windows	ملفات SMB	مجلدات مشتركة لتطبيقات Windows
FSx for Lustre	ملفات عالية الأداء	الحوسبة العالية وتدريب النماذج
FSx for ONTAP	ملفات بعدة بروتوكولات	نقل أنظمة NetApp
FSx for OpenZFS	ملفات NFS	أحمال Linux ونقل أنظمة ZFS
Storage Gateway	جسر	مكتبك يوصل لتخزين السحابة
DataSync	نقل	مزامنة مجدولة
Transfer Family	نقل	استقبال ملفات عبر SFTP وأخواته

عملي: مزامنة مع DataSync

بننقل ملفات بين حاويتين، وهذا ما يحتاج وكيل. من CloudShell، جهّز حاويتين وملفات:

Bash

SRC=series-src-$RANDOM$RANDOM
DST=series-dst-$RANDOM$RANDOM

aws s3 mb s3://$SRC
aws s3 mb s3://$DST

for i in 1 2 3; do
  echo "file $i" > file$i.txt
  aws s3 cp file$i.txt s3://$SRC/
done

echo "source: $SRC  destination: $DST"

افتح DataSync في الكونسول، واضغط Create task:

المصدر: أنشئ موقع جديد من نوع S3، وحدد حاوية series-src-...، واختر إنشاء دور IAM تلقائياً.
الوجهة: نفس الشي مع حاوية series-dst-....
الإعدادات: سمّ المهمة series-sync، واختر Enhanced لو ظهر لك خيار الوضع، وخل الباقي على حاله.
التشغيل: أنشئ المهمة، ثم اضغط Start.

لما تنتهي، تأكد من الوجهة:

Bash

aws s3 ls s3://$DST/

الحين أضف ملف واحد، وشغّل المهمة مرة ثانية:

Bash

echo "file 4" > file4.txt
aws s3 cp file4.txt s3://$SRC/

في صفحة التشغيل الجديد بتلقى ملف واحد انتقل، لأن DataSync ينقل اللي تغيّر فقط. وهذا اللي يفرق عن النسخ الكامل في كل مرة.

Bash

aws s3 rb s3://$SRC --force
aws s3 rb s3://$DST --force

الخلاصة

FSx أنظمة ملفات جاهزة: Windows وLustre وONTAP وOpenZFS.
Storage Gateway يخلي مكتبك يشوف السحابة كتخزين عادي.
DataSync للمزامنة المجدولة، وTransfer Family لاستقبال SFTP.
احسب مدة النقل قبل ما تقرر، وSnowball ما عاد متاح للجدد.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 5

شركة تنقل تطبيق Windows يحفظ ملفاته في مجلد SMB مشترك، والمستخدمين يدخلون عبر Active Directory. وتبي خدمة مُدارة بدون سيرفرات ملفات تشغلها. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

هذا يعطي تطبيقات Windows مجلد SMB حقيقي مرتبط بـ Active Directory، وAWS تشغله لك.

B: EFS نظام ملفات مشترك لـ Linux، عبر NFS.
C: هذا للحوسبة عالية الأداء، ويشتغل مع أجهزة Linux فقط.
D: S3 توصل له عبر API، وهو مو مجلد يفتحه التطبيق عبر SMB.

للمراجعة: Amazon FSx: أنظمة ملفات جاهزة في هذا الجزء، وWhat is FSx for Windows File Server? في وثائق AWS.

السؤال 2 من 5

فريق بحث يشغّل محاكاة ثلاثة أيام على مجموعة أجهزة Linux. تقرأ مدخلاتها من S3، وتحتاج سرعة نقل عالية جداً، وتحفظ نتائجها في S3، فلو تعطل نظام الملفات يعني بس إعادة تشغيل. أي خيار أقل تكلفة؟

اعرض الجواب

الجواب الصحيح: C

Lustre مبني لهذي السرعة ومتكامل مع S3، وScratch الخيار الرخيص للبيانات المؤقتة، لأن ما فيه شي هنا يعتمد على بقاء البيانات بعد العطل.

A: هذا لمجلدات SMB، مو لمجموعات Linux عالية الأداء.
B: هذا يناسب البيانات طويلة المدى، وبتدفع على نسخ ما يحتاجها الفريق.
D: هذا مجلد مشترك عام، وما هو مبني لهذا المستوى من الأداء.

للمراجعة: Amazon FSx: أنظمة ملفات جاهزة في هذا الجزء، وDeployment and storage class options for FSx for Lustre file systems في وثائق AWS.

السؤال 3 من 5

برنامج النسخ الاحتياطي في مستشفى يكتب على أشرطة فعلية، والموظفين ملّوا من تخزينها وشحنها. والمستشفى يبي النسخ في AWS، بدون تغيير برنامج النسخ. وش يناسب؟

اعرض الجواب

الجواب الصحيح: B

هذا يعرض مكتبة أشرطة افتراضية لبرنامج النسخ، والبيانات تروح لـ S3 ثم Glacier.

A: هذا يعرض للتطبيقات مجلد NFS أو SMB، وهذا البرنامج يكتب على أشرطة.
C: هذا يعرض للسيرفرات قرص iSCSI، مو مكتبة أشرطة.
D: هذا يستقبل ملفات عبر بروتوكولات مثل SFTP، وبرنامج الأشرطة ما يستخدمها.

للمراجعة: Storage Gateway: مكتبك والسحابة في هذا الجزء، وWhat is Tape Gateway? في وثائق AWS.

السؤال 4 من 5

عميل جديد في AWS عنده 100 تيرابايت على أجهزة تخزين خاصة فيه، ولازم توصل S3 خلال أسبوعين. وخطه الوحيد سرعته 100 ميجابت. وش يناسب؟

اعرض الجواب

الجواب الصحيح: D

الفريق ياخذ أجهزة تخزينه لموقع فعلي من AWS فيه اتصال عالي السرعة، ويرفع من هناك، فما يعود الخط البطيء مشكلة.

A: بالسرعة الكاملة، 100 تيرابايت على هذا الخط تاخذ حوالي 93 يوم.
B: هذا مقفل على العملاء الجدد.
C: تجهيزه ياخذ أسابيع وأحياناً أشهر، فممكن يفوت الموعد.

للمراجعة: لما تكون البيانات أضخم من الإنترنت في هذا الجزء، وWhat is Data Transfer Terminal? في وثائق AWS.

السؤال 5 من 5

شركة تترك مركز بياناتها. وسيرفر NFS حقها بحجم 30 تيرابايت لازم ينسخ إلى AWS ويبقى متزامن لين الانتقال، وشركاؤها يرسلون ملفات يومية عبر SFTP وما يقدرون يغيرون طريقتهم. أي خدمتين تناسب؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: B + E

DataSync ينسخ بيانات NFS، وفي كل تشغيل بعدها ينقل اللي تغيّر فقط. وTransfer Family يعطي الشركاء نقطة SFTP مُدارة، وملفاتهم تروح لـ S3 أو EFS.

A: هذا لبرامج النسخ الاحتياطي اللي تكتب على أشرطة.
C: هذا نظام ملفات عالي الأداء، وما ينقل البيانات من مركز البيانات.
D: هذا يعرض قرص iSCSI لسيرفرات الموقع، والشركة تترك موقعها.

للمراجعة: DataSync وTransfer Family في هذا الجزء، وHow AWS DataSync works وWhat is AWS Transfer Family? في وثائق AWS.

بهذا نكمل قسم التخزين. عندك الحين تطبيق قوي بقاعدة بيانات وشبكة وتخزين، بس كل أجزائه مربوطة ببعض مباشرة. في الجزء التاسع عشر نبدأ قسم التطبيقات الحديثة، ونفصل بينها بـ SQS وSNS وKinesis.

S3: الأمان والتشفير

2026-11-02T00:00:00Z

في الجزء الخامس عشر عرفنا إن كل شي خاص افتراضياً، وإن Block Public Access يحميك من الفتح بالغلط. هذا الجزء يكمل الطبقات الباقية: التشفير، ومشاركة الملفات بأمان، وحماية البيانات حتى من مسؤولي الحساب نفسهم.

التشفير المخزّن

عندك سؤالين: وين يصير التشفير؟ ومين يمسك المفتاح؟

في SSE تشفّر S3 الملف بعد وصوله، وفي التشفير عند العميل ما تشوف S3 الملف بدون تشفير أبداً.

النوع	مين يمسك المفتاح	متى تختاره
SSE-S3	S3 بالكامل	الافتراضي لكل كائن جديد، ويكفي لأغلب الحالات
SSE-KMS	KMS، وتتحكم أنت في صلاحياته	تبي سجل بكل استخدام للمفتاح، وتحكم أدق
DSSE-KMS	KMS، بطبقتين تشفير	متطلبات تنظيمية تفرض طبقتين
SSE-C	أنت، وترسله مع كل طلب	مقفل افتراضياً في الحاويات الجديدة منذ أبريل 2026
عند العميل	أنت بالكامل	ما تبي AWS تشوف البيانات أبداً

انتبه مع SSE-KMS

كل قراءة أو كتابة تنادي KMS، وKMS له حد لعدد الطلبات في الثانية حسب الـ Region. فلو عندك ضغط عالي، فعّل S3 Bucket Keys: مفتاح وسيط على مستوى الحاوية يقلل طلبات KMS بنسبة كبيرة، ومعها التكلفة.

ولازم من يقرأ الكائن يكون عنده صلاحية على S3 وعلى مفتاح KMS معاً. وهذا سبب مشهور لخطأ AccessDenied رغم إن سياسة S3 صحيحة.

التشفير أثناء النقل

S3 تقبل HTTP وHTTPS. وعشان تفرض HTTPS، ارفض أي طلب غير مشفّر عبر الشرط aws:SecureTransport:

JSON

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::my-bucket",
      "arn:aws:s3:::my-bucket/*"
    ],
    "Condition": { "Bool": { "aws:SecureTransport": "false" } }
  }]
}

وبنفس الطريقة تقدر تفرض نوع تشفير معين على كل رفع. والسياسة تُقيَّم قبل التشفير الافتراضي، فلو رفضت الطلب ما يوصل له أصلاً.

مشاركة ملف خاص: الروابط الموقّعة

تبي عميل يحمّل فاتورته، بدون ما تفتح الحاوية ولا تعطيه حساب؟ Pre-signed URL رابط فيه توقيع وله مدة صلاحية:

يحمل صلاحيات اللي وقّعه، فلو هو ما يقدر يقرأ الملف، الرابط ما يشتغل.
ينفع للتحميل والرفع، مثل رفع صورة من المتصفح مباشرة لـ S3 بدون المرور بسيرفرك.
مدته محدودة، ولو وقّعته بدور مؤقت ينتهي مع انتهاء الجلسة.

CORS: لما يمنعك المتصفح

CORS حماية في المتصفح، مو في S3. الأصل (Origin) هو البروتوكول والنطاق والمنفذ. فلو صفحة على https://app.example.com طلبت ملف من https://my-bucket.s3.amazonaws.com، فالمتصفح يعتبرهم أصلين مختلفين، ويسأل الحاوية: تسمحين؟

لو طلع عندك خطأ CORS في المتصفح، أضف الإعدادات للحاوية:

JSON

[{
  "AllowedOrigins": ["https://app.example.com"],
  "AllowedMethods": ["GET", "PUT"],
  "AllowedHeaders": ["*"],
  "MaxAgeSeconds": 3000
}]

الحماية من الحذف

حتى الصلاحيات الصحيحة ما تحميك من خطأ، أو حساب مخترق، أو برامج الفدية. عندك ثلاث طبقات:

الأداة	وش تسوي	ملاحظات
MFA Delete	تطلب رمز MFA لحذف إصدار نهائياً أو إيقاف الإصدارات	يفعّله المستخدم الجذر فقط، عبر الأوامر
Object Lock	يمنع حذف أو تعديل الإصدار لمدة	لازم الإصدارات مفعّلة
Glacier Vault Lock	يقفل سياسة مخزن Glacier القديم للأبد	للمخازن القديمة، وObject Lock أفضل لأي شي جديد

أوضاع Object Lock

الوضع	مين يقدر يحذف قبل نهاية المدة
Governance	مستخدمين عندهم صلاحية خاصة فقط
Compliance	ما أحد، ولا حتى المستخدم الجذر

وفيه كمان Legal Hold: قفل بدون مدة محددة، يبقى لين تشيله، ومفيد للقضايا القانونية.

السجلات والمراقبة

Access Logs: تسجّل كل طلب في حاوية ثانية. لا تخليها نفس الحاوية، لأن كل سجل يولّد سجل جديد، فتكبر بلا نهاية وتكبر الفاتورة.
CloudTrail: يسجّل عمليات الإدارة، وعمليات البيانات لو فعّلتها، وبنشرحه في الجزء الخامس والعشرين.

Access Points: لكل فريق بوابته

لو عندك حاوية كبيرة يستخدمها فرق كثيرة، Bucket Policy تصير طويلة وخطرة. Access Points تعطي كل فريق بوابة باسمها وسياستها:

بوابة finance تسمح لفريق المالية على finance/* فقط.
بوابة sales تسمح لفريق المبيعات على sales/* فقط.
وتقدر تخلي بوابة تقبل من داخل VPC واحدة فقط.

عملي: تشفير ورابط موقّع وفرض HTTPS

بنكمل بنفس الحاوية في BUCKET. ارفع ملف وشوف تشفيره الافتراضي، ثم ارفع واحد بـ KMS:

Bash

echo "secret invoice" > invoice.txt
aws s3 cp invoice.txt s3://$BUCKET/invoice.txt

aws s3api head-object --bucket $BUCKET --key invoice.txt \
  --query ServerSideEncryption

aws s3 cp invoice.txt s3://$BUCKET/invoice-kms.txt --sse aws:kms

aws s3api head-object --bucket $BUCKET --key invoice-kms.txt \
  --query "[ServerSideEncryption,SSEKMSKeyId]"

الأول AES256 يعني SSE-S3، والثاني aws:kms مع معرّف المفتاح.

الحين سوّ رابط موقّع مدته 60 ثانية، وجرّبه:

Bash

URL=$(aws s3 presign s3://$BUCKET/invoice.txt --expires-in 60)

curl -s "$URL"

يطبع محتوى الملف، مع إن الحاوية خاصة. انتظر دقيقة وأعد نفس أمر curl، وبيرجع AccessDenied مع رسالة إن الطلب منتهي.

والآن افرض HTTPS على الحاوية:

Bash

aws s3api put-bucket-policy --bucket $BUCKET --policy '{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyHttp",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": ["arn:aws:s3:::'$BUCKET'", "arn:aws:s3:::'$BUCKET'/*"],
    "Condition": {"Bool": {"aws:SecureTransport": "false"}}
  }]
}'

URL=$(aws s3 presign s3://$BUCKET/invoice.txt --expires-in 300)

curl -s -o /dev/null -w "https: %{http_code}\n" "$URL"
curl -s -o /dev/null -w "http: %{http_code}\n" "${URL/https:/http:}"

نفس الرابط يرجع 200 مع HTTPS و403 مع HTTP.

الخلاصة

كل كائن جديد مشفّر بـ SSE-S3 تلقائياً، واختر SSE-KMS لو تبي تحكم وسجل، مع Bucket Keys.
افرض HTTPS بشرط aws:SecureTransport.
الروابط الموقّعة تشارك ملف خاص مؤقتاً بدون فتح الحاوية.
CORS من المتصفح، وتحله بإعدادات الحاوية.
Object Lock يحميك من الحذف، حتى من الجذر في وضع Compliance.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 5

دور عنده صلاحية s3:GetObject على حاوية. ويقدر يقرأ الكائنات المشفرة بـ SSE-S3، بس يطلع له AccessDenied مع المشفرة بـ SSE-KMS ومفتاح Customer managed. وش الناقص؟

اعرض الجواب

الجواب الصحيح: B

قراءة كائن SSE-KMS تحتاج صلاحية على S3 وعلى مفتاح KMS معاً، وعشان كذا يطلع هذا الخطأ حتى لو سياسة S3 صحيحة.

A: هذي تقلل طلبات KMS والتكلفة، وما تعطي أي صلاحية.
C: CORS قاعدة في المتصفح، وما لها علاقة بصلاحيات دور.
D: هذا يفرض HTTPS، وهو يمنع مو يسمح.

للمراجعة: انتبه مع SSE-KMS في هذا الجزء، وUsing server-side encryption with AWS KMS keys في وثائق AWS.

السؤال 2 من 5

متجر إلكتروني يبي كل عميل يحمّل فاتورته من حاوية خاصة، برابط يوقف بعد 15 دقيقة. والعملاء ما عندهم حسابات AWS. وش يناسب؟

اعرض الجواب

الجواب الصحيح: D

الـ Pre-signed URL فيه توقيع ومدة صلاحية، ويشتغل بصلاحيات اللي وقّعه، فتبقى الحاوية خاصة.

A: بهذي الطريقة أي أحد يقدر يقرأ أي فاتورة، في أي وقت.
B: إنشاء مستخدمين للعملاء وإدارتهم شغل ثقيل، وما له داعي.
C: هذا إذن في المتصفح بين المواقع، وما يفتح الملفات الخاصة لأحد.

للمراجعة: مشاركة ملف خاص: الروابط الموقّعة في هذا الجزء، وDownload and upload objects with presigned URLs في وثائق AWS.

السؤال 3 من 5

صفحة على https://app.example.com تحمّل JSON من حاوية عبر JavaScript. والمتصفح يعرض خطأ CORS، بينما نفس الطلب من curl ينجح. وش يسوي الفريق؟

اعرض الجواب

الجواب الصحيح: A

CORS حماية في المتصفح. المتصفح يسأل الحاوية هل هذا الأصل مسموح، وcurl ما يسأل، وعشان كذا المتصفح وحده اللي اعترض.

B: الطلب ينجح من curl، فالوصول مو هو المشكلة.
C: التشفير ما له علاقة بالأصول اللي يقبلها المتصفح.
D: هذا يحتفظ بالإصدارات القديمة، وما يغير شي يفحصه المتصفح.

للمراجعة: CORS: لما يمنعك المتصفح في هذا الجزء، وUsing cross-origin resource sharing (CORS) في وثائق AWS.

السؤال 4 من 5

بنك لازم يحتفظ بسجلاته سبع سنين، بطريقة ما يقدر أحد يحذفها خلالها، ولا حتى المستخدم الجذر. وش يناسب؟

اعرض الجواب

الجواب الصحيح: C

في وضع Compliance، ما أحد يقدر يحذف إصدار مقفل أو يكتب فوقه لين تنتهي مدته، ولا حتى المستخدم الجذر، والمدة ما تنقص.

A: هذا يطلب رمز MFA بس، فالمستخدم الجذر اللي معه الجهاز يقدر يحذف.
B: المستخدمين اللي عندهم صلاحية خاصة يقدرون يحذفون في هذا الوضع.
D: اللي عنده صلاحيات كافية يقدر يغير السياسة ببساطة.

للمراجعة: أوضاع Object Lock في هذا الجزء، وLocking objects with Object Lock في وثائق AWS.

السؤال 5 من 5

تدقيق يطلب شرطين على حاوية: ما تقبل الطلبات إلا عبر HTTPS، ويكون فيه سجل بكل استخدام لمفتاح التشفير. أي تغييرين يحققون هذا؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: C + E

السياسة ترفض أي طلب غير مشفر، ومع SSE-KMS تقدر تدقق استخدام المفتاح في CloudTrail.

A: هذا يمنع الوصول العام، وما ينظر إلى HTTP أو HTTPS.
B: هنا S3 تمسك المفتاح بالكامل، فما يطلع لك سجل بكل استخدام.
D: هذا يحمي من الحذف، وما يحقق أي شرط منهم.

للمراجعة: التشفير المخزّن والتشفير أثناء النقل في هذا الجزء، وSecurity best practices for Amazon S3 وUsing server-side encryption with AWS KMS keys في وثائق AWS.

S3 مو الخيار الوحيد. لو عندك نظام Windows، أو مكتب يبي يوصل لتخزين السحابة، أو ملايين الملفات تبي تنقلها؟ في الجزء الثامن عشر نغطي خدمات التخزين والنقل الباقية.

S3: فئات التخزين ودورة الحياة

2026-11-02T00:00:00Z

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

فئات التخزين تعطيك هذا الخيار: كل ما قل الوصول للملف، قل سعر تخزينه، وزادت تكلفة أو مدة استرجاعه.

المتانة والتوفر

مصطلحين لازم تفرق بينهم:

المتانة (Durability): هل بيضيع الملف؟ 99.999999999% لكل الفئات، مع ملاحظة إن الفئات بمنطقة توفر واحدة تضيع بياناتها لو تدمرت المنطقة.
التوفر (Availability): هل تقدر توصل له الحين؟ يختلف من فئة لفئة، مثلاً 99.99% لـ Standard.

الفئات

الفئة	تناسب	الاسترجاع	أقل مدة	السعر التقريبي
Standard	بيانات تنطلب كثير	فوري	ما فيه	0.023
Intelligent-Tiering	نمط وصول غير معروف	فوري في الطبقات التلقائية	ما فيه	حسب الطبقة
Standard-IA	مرة في الشهر تقريباً	فوري، مع رسم استرجاع	30 يوم	0.0125
One Zone-IA	بيانات تقدر تعيد إنشاءها	فوري، مع رسم	30 يوم	0.01
Glacier Instant Retrieval	مرة في ثلاثة أشهر	فوري، مع رسم أعلى	90 يوم	0.004
Glacier Flexible Retrieval	مرة أو مرتين في السنة	من دقايق إلى ساعات	90 يوم	0.0036
Glacier Deep Archive	أقل من مرة في السنة	من 12 إلى 48 ساعة	180 يوم	0.00099

الأسعار بالدولار لكل جيجابايت في الشهر، تقريبية لمناطق أمريكا، فراجع صفحة الأسعار لمنطقتك.

وكل هذي الفئات تحفظ البيانات في ثلاث مناطق توفر أو أكثر، إلا One Zone-IA. وعندك كمان S3 Express One Zone: أداء عالي جداً بزمن استجابة أقل من 10 ملي ثانية، في منطقة توفر واحدة، بحاوية من نوع خاص، وسعره أعلى. يناسب التحليل وتدريب النماذج اللي تحتاج سرعة كبيرة.

Intelligent-Tiering: لو ما تعرف

لو ما تدري كم بينطلب الملف، هذي الفئة تنقله لحالها حسب الاستخدام:

الطبقة	متى	الاسترجاع
Frequent Access	البداية	فوري
Infrequent Access	بعد 30 يوم بدون وصول	فوري
Archive Instant Access	بعد 90 يوم بدون وصول	فوري
Archive Access	اختيارية، من 90 يوم	ساعات
Deep Archive Access	اختيارية، من 180 يوم	حتى 12 ساعة

تدفع رسم مراقبة بسيط لكل كائن، وما فيه رسوم استرجاع، ولو انطلب الملف يرجع للطبقة الأولى.

Glacier Flexible و Deep Archive: طلب قبل القراءة

في هذي الفئات ما تقدر تقرأ الملف مباشرة، لازم تطلب استرجاعه أول، وتختار السرعة:

الفئة	Expedited	Standard	Bulk
Flexible Retrieval	1 إلى 5 دقايق	3 إلى 5 ساعات	5 إلى 12 ساعة
Deep Archive	ما فيه	12 ساعة	48 ساعة

دورة الحياة (Lifecycle)

ما تحتاج تنقل الملفات بيدك. قواعد Lifecycle تسوي هذا تلقائياً حسب عمر الملف. مثلاً سجلات تطبيق:

قاعدة واحدة تنقل الملف عبر الفئات مع تقدم عمره، ثم تحذفه بعد سبع سنين.

والقاعدة فيها نوعين من الإجراءات، وتطبقها على بادئة أو وسم محدد:

الإجراء	أمثلة
Transition	انقل الملف لفئة أرخص بعد عدد أيام
Expiration	احذف الملف بعد مدة، أو الإصدارات القديمة، أو الرفعات اللي ما اكتملت

وأشياء تنتبه لها:

النقل نازل فقط على السلم، وأقل مدة قبل Standard-IA هي 30 يوم.
الملفات الأصغر من 128 KB ما تنتقل افتراضياً، لأن تكلفة نقلها أكبر من توفيرها.
النقل نفسه له رسم لكل ألف كائن، فانتبه للملايين من الملفات الصغيرة.

كيف تعرف وش تختار؟

ما تحتاج تخمن. عندك أدوات تقرأ استخدامك الفعلي:

Storage Class Analysis: تراقب الوصول لبادئة أو حاوية، وتقترح متى تنقل من Standard إلى Standard-IA.
Storage Lens: لوحة على مستوى الحسابات كلها: الأحجام والنمو والحاويات اللي فيها رفعات ناقصة أو بدون تشفير. ولها مقاييس مجانية وأخرى متقدمة مدفوعة.

ولو عندك ملايين الملفات وتبي تسوي شي عليها مرة وحدة، زي تغيير الفئة أو النسخ، S3 Batch Operations تنفذه على قائمة من S3 Inventory، مع تقرير بالنتائج.

وفي المقابل، لو تشارك بيانات ضخمة مع جهة ثانية، Requester Pays تخليهم يدفعون تكلفة الطلبات والتحميل بدالك.

ولو بترفع ملايين الملفات الصغيرة اللي ما تقرأها وحدة وحدة، مثل السجلات، اجمعها في أرشيف واحد أول. كل PUT طلب مدفوع، فرفعة وحدة كبيرة ممكن تكلف أقل بكثير من مليون رفعة صغيرة.

عملي: فئات وقاعدة دورة حياة

بنكمل بالحاوية من الجزء السابق. لو انتهت جلسة CloudShell، حط اسمها في BUCKET من جديد. ارفع ملف في فئة محددة، وشوف الفئة:

Bash

echo "monthly report" > report.txt

aws s3 cp report.txt s3://$BUCKET/reports/report.txt --storage-class STANDARD_IA

aws s3api head-object --bucket $BUCKET --key reports/report.txt \
  --query StorageClass

الحين أضف قاعدة دورة الحياة اللي في الرسم على بادئة logs/:

Bash

aws s3api put-bucket-lifecycle-configuration --bucket $BUCKET \
  --lifecycle-configuration '{
  "Rules": [{
    "ID": "logs-rule",
    "Status": "Enabled",
    "Filter": {"Prefix": "logs/"},
    "Transitions": [
      {"Days": 30, "StorageClass": "STANDARD_IA"},
      {"Days": 90, "StorageClass": "GLACIER"},
      {"Days": 365, "StorageClass": "DEEP_ARCHIVE"}
    ],
    "Expiration": {"Days": 2555},
    "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}
  }]
}'

aws s3api get-bucket-lifecycle-configuration --bucket $BUCKET \
  --query "Rules[0].Transitions" --output table

وهذا الجزء الممتع: ارفع ملف لـ Glacier، وحاول تقراه:

Bash

echo "old invoice" > old.txt
aws s3 cp old.txt s3://$BUCKET/archive/old.txt --storage-class GLACIER

aws s3 cp s3://$BUCKET/archive/old.txt -

بيرجع خطأ InvalidObjectState، لأن الملف محفوظ لكنه ما ينقرأ مباشرة. اطلب استرجاعه:

Bash

aws s3api restore-object --bucket $BUCKET --key archive/old.txt \
  --restore-request '{"Days": 1, "GlacierJobParameters": {"Tier": "Standard"}}'

aws s3api head-object --bucket $BUCKET --key archive/old.txt \
  --query "[StorageClass,Restore]"

بتشوف ongoing-request="true". وبعد 3 إلى 5 ساعات يصير false، ويتوفر نسخة مؤقتة تقراها ليوم واحد.

الخلاصة

كل ما قل الوصول، قل سعر التخزين، وزادت تكلفة الاسترجاع أو مدته.
لو ما تعرف نمط الوصول، Intelligent-Tiering ينقل الملفات لحاله.
انتبه لـ أقل مدة تخزين وأقل حجم محسوب ورسوم الاسترجاع.
Lifecycle تنقل الملفات وتحذفها تلقائياً، وأضف قاعدة للرفعات الناقصة دايماً.
Storage Lens وStorage Class Analysis تقرر بأرقام، مو بالتخمين.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 5

شركة ناشئة تطلق منصة بيانات جديدة. بعض الملفات ممكن تبقى أشهر ما أحد يلمسها وبعدين تنقرأ كثير، وما أحد يقدر يتوقع أيها. وتبي تخفض تكلفة التخزين، بدون رسوم استرجاع وبدون قواعد تديرها. أي فئة تناسب؟

اعرض الجواب

الجواب الصحيح: D

تراقب استخدام كل ملف وتنقله بين الطبقات لحالها، مقابل رسم مراقبة بسيط وبدون رسوم استرجاع.

A: هذي فيها رسم على كل استرجاع، فالملف اللي ينقرأ كثير ممكن تصير تكلفته أعلى.
B: هذي فيها رسم استرجاع كمان، وتحفظ البيانات في منطقة توفر وحدة.
C: الملفات هنا تحتاج استرجاع قبل القراءة، وممكن ياخذ ساعات.

للمراجعة: Intelligent-Tiering: لو ما تعرف في هذا الجزء، وManaging storage costs with Amazon S3 Intelligent-Tiering في وثائق AWS.

السؤال 2 من 5

خدمة فيديو تحتفظ بنسخ منخفضة الدقة من أفلامها، وتقدر تعيد إنتاجها من الأصول في أي وقت. وكل نسخة تنقرأ مرة في الشهر تقريباً، ولازم تفتح فوراً. أي فئة أقل تكلفة وتحقق هذا؟

اعرض الجواب

الجواب الصحيح: B

النسخ ممكن تنعاد، فخسارتها مع منطقة توفر مو كارثة، وما تحتاج تدفع على ثلاث مناطق. والاسترجاع يبقى فوري.

A: هذي تنفع، بس بسعر أعلى على حماية هذي البيانات ما تحتاجها.
C: الاسترجاع هنا ياخذ من 12 إلى 48 ساعة.
D: الملفات هنا تحتاج استرجاع قبل القراءة، ياخذ من دقايق لساعات.

للمراجعة: الفئات في هذا الجزء، وUnderstanding and managing Amazon S3 storage classes في وثائق AWS.

السؤال 3 من 5

سجلات تطبيق شركة لازم تبقى مقروءة فوراً 30 يوم، ثم تتأرشف بسعر رخيص سنة، ثم تنحذف. والفريق ما يبي أي سكربتات يشغلها. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

قاعدة Lifecycle تنقل الملفات لفئة أرخص عند العمر اللي تحدده، وتحذفها بعدين، بدون أي شي تشغله أنت.

B: هذا ينفع، بس هو كود لازم تكتبه وتصونه.
C: هذا يعرض لك أرقام، وما ينقل ولا يحذف شي.
D: هذا يزيد النسخ، وما يأرشف الأصول ولا يحذفها.

للمراجعة: دورة الحياة (Lifecycle) في هذا الجزء، وManaging the lifecycle of objects في وثائق AWS.

السؤال 4 من 5

سكربت مدقق يحاول يقرأ ملف حجمه 20 ميجابايت محفوظ في Glacier Flexible Retrieval، ويطلع له خطأ InvalidObjectState. والمدقق يحتاج الملف خلال 10 دقايق. وش يسوي الفريق؟

اعرض الجواب

الجواب الصحيح: C

في هذي الفئة لازم ينسترجع الملف قبل ما ينقرأ، وExpedited عادةً يجهز ملف بهذا الحجم خلال 1 إلى 5 دقايق.

A: الصلاحية الناقصة ترجّع AccessDenied، مو هذا الخطأ.
B: هذا أرخص خيار، بس ياخذ من 5 إلى 12 ساعة.
D: نقل Lifecycle ينزل مع الدرج بس، وما يرجع أبداً إلى Standard.

للمراجعة: Glacier Flexible و Deep Archive: طلب قبل القراءة في هذا الجزء، وUnderstanding archive retrieval options في وثائق AWS.

السؤال 5 من 5

عشان يوفر، رفع فريق ملايين الصور بحجم 10 كيلوبايت إلى Standard-IA. والتطبيق يقرأها طول اليوم، والفاتورة زادت. أي سببين يفسرون هذا؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: B + C

الصورة بحجم 10 كيلوبايت تنحسب 128 كيلوبايت في هذي الفئة، وسعر التخزين المنخفض ما يفيد إلا مع البيانات اللي نادراً تنقرأ. وبيانات بهذا الصغر وهذا الاستخدام مكانها Standard.

A: رسم المراقبة حق Intelligent-Tiering.
D: سعر الجيجابايت فيها أقل، وعشان كذا تبدو مغرية.
E: تستخدم ثلاث مناطق أو أكثر زي Standard، فالتكلفة الزيادة مو من هنا.

للمراجعة: الفئات في هذا الجزء، وUnderstanding and managing Amazon S3 storage classes في وثائق AWS.

بياناتك الحين في المكان المناسب بالسعر المناسب، بس مين يقدر يوصل لها؟ في الجزء السابع عشر نغطي التشفير والروابط الموقّعة والقفل ضد الحذف.

S3: أساسيات التخزين الكائني

2026-11-02T00:00:00Z

في الجزء الخامس شفنا تخزين مربوط بالسيرفرات. بس الصور والفيديوهات والنسخ الاحتياطية والسجلات ما تحتاج سيرفر أصلاً، تحتاج مكان يحفظها بأمان ويوصلها وقت الطلب، مهما كبر حجمها. هذا S3.

وS3 (Simple Storage Service) من أقدم خدمات AWS وأكثرها استخداماً. ما فيها مساحة تحجزها، وتدفع على اللي تخزنه. وAWS تصممها لمتانة 99.999999999%، يعني احتمال ضياع ملف عندك شبه معدوم.

وتشوفها في كل مكان: نسخ احتياطية، وملفات المستخدمين، ومواقع ثابتة، وسجلات، وبحيرات بيانات للتحليل.

التخزين الكائني مقابل الأقراص

	كتلي (EBS)	ملفات (EFS)	كائني (S3)
يشبه	قرص	مجلد مشترك	مفتاح وملف عبر API
يوصل له	سيرفر واحد عادةً	عدة سيرفرات	أي أحد مسموح له عبر HTTP
تعديل ملف	جزء منه	جزء منه	تستبدل الكائن كامل
الحجم	تحجزه	يكبر لحاله	بلا حد عملي

والنقطة اللي تفرق في التصميم: S3 مو قرص تركّبه وتشغّل منه قاعدة بيانات، بس هو مثالي لأي ملف تقراه أو تكتبه كامل.

الحاويات والكائنات

الحاوية فيها كائنات، وكل كائن له مفتاح وبيانات ومعلومات عنه ووسوم وإصدار.

الحاوية (Bucket):

تعيش في Region واحدة تختارها، مع إن S3 تظهر كخدمة عامة في الكونسول.
اسمها لازم يكون فريد على مستوى كل حسابات AWS، بحروف صغيرة وأرقام وشرطات.

الكائن (Object):

حجمه لين 50 TB.
المفتاح هو مساره الكامل، مثل photos/2026/trip.jpg.
ما فيه مجلدات حقيقية. photos/2026/ جزء من الاسم، والكونسول يعرضه كمجلد فقط.

مين يقدر يوصل؟

كل شي في S3 خاص افتراضياً. ولما يطلب أحد كائن، تجمع AWS كل القواعد: يوصل لو فيه قاعدة تسمح له وما فيه قاعدة تمنعه.

الأداة	ترتبط بـ	تستخدمها لـ
سياسة IAM	المستخدم أو الدور	صلاحيات موظفيك وخدماتك
Bucket Policy	الحاوية	الوصول العام، وحسابات ثانية، وفرض قواعد
Block Public Access	الحاوية أو الحساب	قفل أمان يمنع الوصول العام مهما كانت السياسات

مثال: سيرفر EC2 يقرأ من S3؟ أعطه دور IAM. وحساب ثاني يقرأ؟ Bucket Policy تسمح له. وهذي سياسة تخلي حاوية كاملة عامة للقراءة، وهذا اللي يحتاجه موقع ثابت:

JSON

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-site-bucket/*"
  }]
}

الإصدارات (Versioning)

لما تفعّلها، أي استبدال لكائن ينشئ إصدار جديد بدل ما يمسح القديم:

الكتابة فوق ملف: الإصدار القديم يبقى، وتقدر ترجع له.
الحذف: يضيف علامة حذف (Delete Marker)، والبيانات تبقى. احذف العلامة ويرجع الملف.
الإيقاف: ما يمسح الإصدارات الموجودة.

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

النسخ بين الحاويات (Replication)

S3 تنسخ الكائنات الجديدة تلقائياً لحاوية ثانية، حتى في حساب ثاني. ولازم الإصدارات تكون مفعّلة في الجهتين.

النوع	يناسب
بين Regions (CRR)	التوافق مع الأنظمة، والقرب من المستخدمين، والتعافي من الكوارث
داخل Region (SRR)	جمع السجلات في مكان واحد، أو نسخ الإنتاج لبيئة تجربة

وانتبه: الكائنات القديمة ما تنتقل إلا بـ Batch Replication، والنسخ ما ينتقل عبر سلسلة حاويات، والحذف النهائي لإصدار ما ينسخ، عشان تبقى محمي من الحذف الخبيث.

استضافة موقع ثابت

S3 تقدر تقدم موقع HTML كامل: تفعّل Static website hosting، وتحدد index.html، وتخلي الكائنات عامة بسياسة زي اللي فوق.

بس رابط الموقع هذا يشتغل بـ HTTP فقط. والأفضل في الإنتاج: حاوية خاصة قدامها CloudFront مع OAC، فتحصل HTTPS وسرعة أعلى بدون ما تفتح الحاوية.

التفاعل مع الأحداث

S3 تقدر ترسل إشعار لما يصير شي، مثل رفع صورة. وترسله لـ SQS أو SNS أو Lambda مباشرة، أو لـ EventBridge لو تبي فلترة متقدمة ووجهات أكثر. والمثال المشهور: كل صورة ترتفع، دالة Lambda تسوي لها نسخة مصغرة. وبنطبق هذا في الجزء الثاني والعشرين.

الأداء

S3 تتحمل على الأقل 3,500 كتابة و5,500 قراءة في الثانية لكل بادئة (Prefix)، فتوزيع المفاتيح على عدة بادئات يكبر السعة. وعندك أدوات للملفات الكبيرة والمسافات البعيدة:

الأداة	وش تسوي
Multipart Upload	ترفع الملف أجزاء بالتوازي، ولو فشل جزء تعيده فقط. مفضل فوق 100 MB، ولازم فوق 5 GB
Transfer Acceleration	الرفع يمر بأقرب موقع حافة ثم شبكة AWS، للمسافات البعيدة
Byte-Range Fetches	تحمّل جزء محدد من الملف، فتسرّع التحميل بالتوازي أو تجيب اللي تحتاجه فقط

عملي: الإصدارات تنقذ ملف محذوف

من CloudShell، أنشئ حاوية باسم فريد وارفع صفحة:

Bash

BUCKET=series-files-$RANDOM$RANDOM
aws s3 mb s3://$BUCKET

echo "<h1>Version 1</h1>" > index.html
aws s3 cp index.html s3://$BUCKET/
aws s3 ls s3://$BUCKET/

جرّب توصل للملف من الإنترنت. بيرجع 403، لأن كل شي خاص:

Bash

curl -s -o /dev/null -w "%{http_code}\n" \
  https://$BUCKET.s3.$AWS_REGION.amazonaws.com/index.html

الحين فعّل الإصدارات، واكتب فوق الملف، ثم احذفه:

Bash

aws s3api put-bucket-versioning --bucket $BUCKET \
  --versioning-configuration Status=Enabled

echo "<h1>Version 2</h1>" > index.html
aws s3 cp index.html s3://$BUCKET/

aws s3 rm s3://$BUCKET/index.html
aws s3 ls s3://$BUCKET/

الملف اختفى من القائمة. بس شوف وش صار فعلاً:

Bash

aws s3api list-object-versions --bucket $BUCKET --prefix index.html \
  --query "{Versions:Versions[].[VersionId,IsLatest],Markers:DeleteMarkers[].[VersionId,IsLatest]}"

الإصدارين موجودين، وفوقهم علامة حذف. احذف العلامة ويرجع الملف:

Bash

MARKER=$(aws s3api list-object-versions --bucket $BUCKET --prefix index.html \
  --query "DeleteMarkers[0].VersionId" --output text)

aws s3api delete-object --bucket $BUCKET --key index.html --version-id $MARKER

aws s3 cp s3://$BUCKET/index.html -

بيطبع Version 2. رجع الملف وكأن ما انحذف.

الخلاصة

S3 تخزين كائني بلا حد عملي، وتدفع على اللي تخزنه.
الحاوية في Region واحدة باسم فريد، والمفتاح مسار الكائن الكامل.
كل شي خاص افتراضياً، وخل Block Public Access مفعّل.
الإصدارات تحميك من الحذف والكتابة بالغلط، والنسخ ينقل الكائنات لحاوية ثانية.
لموقع ثابت في الإنتاج: حاوية خاصة مع CloudFront.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 5

وكالة تصميم تحفظ ملفات عملائها في S3. والأسبوع اللي فات حذف موظف ملفات بالغلط، وسكربت كتب فوق ملفات ثانية. والوكالة تبي تقدر ترجّع النوعين من الحين وطالع، بأقل جهد. وش تفعّل؟

اعرض الجواب

الجواب الصحيح: C

مع الإصدارات، الحذف يضيف علامة بس، والكتابة فوق الملف تنشئ إصدار جديد، فتبقى البيانات القديمة وتقدر ترجع لها.

A: هذا يمنع الوصول العام، وما يسوي شي مع الحذف أو الكتابة فوق الملفات.
B: هذا يحتاج الإصدارات أصلاً، ويضيف حاوية ثانية تدفع عليها.
D: هذا يسرّع الرفع للمسافات الطويلة، وما يحتفظ بنسخ قديمة.

للمراجعة: الإصدارات (Versioning) في هذا الجزء، وRetaining multiple versions of objects with S3 Versioning في وثائق AWS.

السؤال 2 من 5

شركة تحفظ موقعها التسويقي في S3. وتبيه يشتغل بـ HTTPS على نطاقها، والحاوية تبقى خاصة. وش يناسب؟

اعرض الجواب

الجواب الصحيح: A

CloudFront يعطيك HTTPS على نطاقك، وOAC يخلي CloudFront وحده يقرأ من الحاوية، فتبقى مقفلة.

B: رابط الموقع يشتغل بـ HTTP فقط، ولازم تكون الحاوية عامة.
C: رابط الموقع يحتاج كائنات عامة، فمع القفل يطلع للزوار 403.
D: هذا يضيف سيرفر تشغله وتحدّثه، لموقع ما يحتاج سيرفر.

للمراجعة: استضافة موقع ثابت في هذا الجزء، وWebsite endpoints في وثائق AWS.

السؤال 3 من 5

استوديو أفلام يرفع ملفات فيديو حجمها 40 جيجابايت إلى S3 عبر اتصال غير مستقر. والرفع يفشل كثير قرب النهاية ويبدأ من جديد. وش يحل هذا؟

اعرض الجواب

الجواب الصحيح: D

Multipart upload يرفع الملف أجزاء بالتوازي، ولو فشل جزء تعيده هو بس. وهو كمان إلزامي لأي ملف فوق 5 جيجابايت.

A: هذي لتحميل جزء من ملف، مو للرفع.
B: هذا يختصر الطريق للمسافات الطويلة، بس الرفع الفاشل لسا يبدأ من جديد.
C: هذا يحتفظ بالإصدارات القديمة، وما يساعد الرفع يكتمل.

للمراجعة: الأداء في هذا الجزء، وUploading and copying objects using multipart upload في وثائق AWS.

السؤال 4 من 5

جهة تنظيمية تطلب من شركة تحتفظ بنسخة من حاوية سجلاتها في Region ثانية، بما فيها الملفات الموجودة حالياً. والإصدارات شغالة في الطرفين. وش تجهز؟

اعرض الجواب

الجواب الصحيح: B

قاعدة النسخ تنسخ الكائنات الجديدة فقط، فالموجودة تحتاج Batch Replication. والاثنين مع بعض يعطونك نسخة كاملة في الـ Region الثانية تبقى محدثة.

A: هذا ينسخ الكائنات اللي انكتبت بعد القاعدة فقط.
C: هذا يبقي النسخة في نفس الـ Region، وهذا ما يحقق المطلوب.
D: قواعد Lifecycle تغير فئة الملف أو تحذفه، وما تنقله بين Regions.

للمراجعة: النسخ بين الحاويات (Replication) في هذا الجزء، وReplicating objects within and across Regions في وثائق AWS.

السؤال 5 من 5

سيرفر EC2 لازم يقرأ من حاوية خاصة، وفريق تحليل في حساب AWS ثاني لازم يقرأ منها كمان. وBlock Public Access لازم يبقى شغال. أي خطوتين تناسب؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: A + D

الدور يعطي السيرفر صلاحيات مؤقتة بدون مفاتيح تحفظها، وسياسة الحاوية هي طريقتك تدخّل فيها حساب ثاني. وما فيهم شي يخلي البيانات عامة.

B: المفاتيح في ملف ممكن تتسرب، والدور يغنيك عنها تماماً.
C: هذا يكشف البيانات للكل، والقفل بيمنعه أصلاً.
E: هذا يزيد نسخ لازم تديرها، والقرص مو طريقة حساب ثاني يقرأ بياناتك.

للمراجعة: مين يقدر يوصل؟ في هذا الجزء، وExample 2: Bucket owner granting cross-account bucket permissions وUse an IAM role to grant permissions to applications running on Amazon EC2 instances في وثائق AWS.

بس هل كل ملف يستاهل نفس السعر؟ ملف ما ينفتح من سنتين لازم ما يكلفك مثل صورة تنطلب كل ثانية. في الجزء السادس عشر نوفر كثير بفئات التخزين ودورة الحياة.

VPC: ربط الشبكات ببعض

2026-11-02T00:00:00Z

في الجزء الثالث عشر بنينا شبكة معزولة. بس التطبيقات الحقيقية نادراً تبقى لحالها: عندك VPC ثانية لفريق ثاني، وسيرفرات تحتاج S3، ومكتب يحتاج يوصل لقاعدة البيانات.

هذي خريطة الجزء، وارجع لها لما تحتار:

تبي	استخدم
شبكتين VPC يتكلمون	VPC Peering
شبكة خاصة توصل لـ S3 أو DynamoDB بدون NAT	Gateway Endpoint
توصل لخدمات AWS ثانية أو خدمة شريك بشكل خاص	Interface Endpoint
مكتبك يوصل لـ AWS بسرعة عبر الإنترنت	Site-to-Site VPN
أجهزة الموظفين توصل للشبكة	Client VPN
خط ثابت وكبير بين مكتبك وAWS	Direct Connect
شبكات ومكاتب كثيرة	Transit Gateway

VPC Peering

Peering يربط شبكتين VPC مباشرة، فكأنهم شبكة وحدة. وتربط حتى بين حسابات مختلفة أو Regions مختلفة. وقواعده:

النطاقات ما تتداخل. هذا اللي نبهناك له في الجزء السابق.
ما ينتقل. لو A مربوطة بـ B، وB مربوطة بـ C، فـ A ما توصل لـ C.
تحتاج طريق في الجهتين. تضيفه في جدول توجيه كل شبكة.

وما له رسم بالساعة، وتدفع فقط على نقل البيانات.

VPC Endpoints: خدمات AWS بدون إنترنت

افتراضياً، طلب سيرفرك الخاص لخدمة S3 يطلع عبر NAT، وتدفع على كل جيجابايت، مع إن الوجهة داخل AWS أصلاً. Endpoints تعطيك طريق خاص ومباشر:

بدل الطريق المدفوع عبر NAT، يوصل السيرفر الخاص إلى S3 عبر Gateway Endpoint المجاني، بدون ما يطلع للإنترنت.

	Gateway Endpoint	Interface Endpoint
الخدمات	S3 وDynamoDB فقط	أغلب خدمات AWS، وخدمات شركاء
كيف يشتغل	طريق في جدول التوجيه	واجهة شبكة بعنوان خاص في شبكتك
التكلفة	مجاني	بالساعة لكل منطقة، ولكل جيجابايت
من مكتبك	ما يوصل	يوصل عبر VPN أو Direct Connect

وInterface Endpoint مبني على PrivateLink، وهو يخليك كمان تقدم خدمتك لشبكات ثانية عبر NLB، بدون Peering وحتى لو نطاقاتهم متداخلة.

ربط مكتبك: Site-to-Site VPN

Site-to-Site VPN يربط شبكة مكتبك بالـ VPC عبر الإنترنت بنفق مشفّر، وتجهزه في وقت قصير. وله ثلاث قطع:

Customer Gateway: يمثل جهازك في المكتب وعنوانه العام.
Virtual Private Gateway: بوابة VPN من جهة AWS، تركّبها على الـ VPC.
VPN Connection: الاتصال نفسه، ويجي بنفقين عشان التوفر.

وبعدها فعّل Route Propagation في جدول التوجيه عشان تعرف الـ VPC طرق المكتب. وكل نفق يعطيك لين 1.25 جيجابت، ولين 5 مع Transit Gateway.

VPN CloudHub: يربط عدة مكاتب ببعض عبر نفس البوابة.
Client VPN: لأجهزة الموظفين بدل المكاتب.

وإذا تبي VPN تتحكم فيه بالكامل على سيرفرك، شوف مقال WireGuard.

Direct Connect: خط خاص

Direct Connect خط فعلي خاص بين مكانك وAWS عبر موقع Direct Connect، فما يمر بالإنترنت العام. فسرعته ثابتة، ونقل البيانات الخارجة أرخص.

Dedicated: منفذ خاص فيك من 1 إلى 400 جيجابت.
Hosted: عن طريق شريك، بسرعات تبدأ أقل بكثير.
Direct Connect Gateway: يوصلك بشبكات VPC في عدة Regions.

انتبه لثلاث نقاط: التجهيز ياخذ أسابيع وأحياناً أشهر، والخط مو مشفّر تلقائياً، فاستخدم MACsec أو VPN فوقه، والخط الواحد نقطة فشل واحدة، فلأهم الأنظمة خل خطين في موقعين، أو VPN احتياطي.

	Site-to-Site VPN	Direct Connect
الطريق	الإنترنت، مشفّر	خط خاص
التجهيز	دقايق أو ساعات	أسابيع أو أشهر
السرعة	1.25 جيجابت للنفق، و5 مع Transit Gateway	من 1 إلى 400 جيجابت
الأداء	يتغير مع الإنترنت	ثابت
التكلفة	قليلة	أعلى في البداية، وأرخص لنقل كبير

Transit Gateway: محور واحد

لما تكثر الشبكات، يصير Peering متعب، لأنه ما ينتقل، فتحتاج وصلة لكل زوج:

خمس شبكات تحتاج عشر وصلات Peering، أو خمس وصلات فقط لمحور Transit Gateway واحد.

Transit Gateway محور مركزي تربط فيه الشبكات، وكل وحدة توصل لغيرها عبره:

يربط كل شي: شبكات VPC، واتصالات VPN، وDirect Connect، وTransit Gateway في Regions ثانية.
جداول توجيه خاصة فيه: تحدد مين يكلم مين، مثلاً تفصل الإنتاج عن التطوير.
بين الحسابات: تشاركه مع حسابات ثانية عبر خدمة RAM.
سرعة VPN أعلى: توزّع الزيارات على عدة أنفاق.

وتدفع بالساعة على كل وصلة، وعلى البيانات. فلشبكتين أو ثلاث، Peering أبسط وأرخص.

تكلفة الشبكة

نقل البيانات أكثر بند يفاجئ الناس. وهذي أسعار تقريبية في مناطق أمريكا، فراجع منطقتك:

الزيارات	التكلفة لكل جيجابايت
داخل لـ AWS	مجاني
داخل نفس منطقة التوفر بعنوان خاص	مجاني
بين مناطق التوفر	حوالي 0.01 دولار في كل اتجاه
بين Regions	حوالي 0.02 دولار
خارج للإنترنت	حوالي 0.09 دولار، ويقل مع الحجم
عبر NAT Gateway	حوالي 0.045 دولار زيادة
S3 عبر Gateway Endpoint	مجاني

وكيف توفر:

استخدم العناوين الخاصة بين السيرفرات، لا العامة.
خل الخدمات اللي تتكلم كثير في نفس منطقة التوفر، لو يسمح تصميم التوفر عندك.
فعّل Gateway Endpoint لـ S3.
قدّم المحتوى عبر CloudFront، لأن النقل من مصدرك إليه مجاني.

طبقات الحماية

الطبقة	الخدمة	تحمي من
الشبكة الفرعية	NACL	عناوين تبي تمنعها
السيرفر	مجموعة الأمان	أي منفذ ومصدر ما سمحت له
تطبيق الويب	WAF	هجمات الويب مثل SQL Injection
الهجمات الكبيرة	Shield	DDoS
الـ VPC كلها	Network Firewall	فحص الزيارات والنطاقات عند الحدود

وعن IPv6: تقدر تضيفه للـ VPC، بس كل عناوينه عامة. فلو تبي السيرفرات تطلع بدون دخول، استخدم Egress-only Internet Gateway، وهو مثل NAT لـ IPv6.

عملي: Endpoint وPeering

بنكمل على شبكة الجزء الثالث عشر، بعد حذف NAT Gateway. فـ private-server ما عنده طريق للإنترنت. والأوامر تستخدم المتغيرات VPC وRT_PRIVATE، ولو انتهت جلسة CloudShell حددها بيدك من صفحة VPC.

Gateway Endpoint

أعطِ private-server دور IAM فيه AmazonS3ReadOnlyAccess، مثل ما شرحنا في الجزء الثاني. وعلى السيرفر جرّب:

Bash

aws s3 ls --cli-connect-timeout 5

ينتهي الوقت بعد عدة محاولات، لأن ما فيه طريق لـ S3. الحين من CloudShell أضف Endpoint:

Bash

aws ec2 create-vpc-endpoint --vpc-id $VPC \
  --service-name com.amazonaws.$AWS_REGION.s3 \
  --route-table-ids $RT_PRIVATE

aws ec2 describe-route-tables --route-table-ids $RT_PRIVATE \
  --query "RouteTables[0].Routes[].[DestinationCidrBlock,DestinationPrefixListId,GatewayId]" \
  --output table

بتشوف طريق جديد يبدأ بـ pl- ويشير لـ vpce-. وأعد أمر aws s3 ls على السيرفر، وبيرجع فوراً بقائمة الحاويات، أو فاضي لو ما عندك حاويات، بدون أي إنترنت.

VPC Peering

الحين نربط هذي الشبكة بالافتراضية، اللي فيها web-1 من الجزء الثالث. هات عنوانه الخاص:

Bash

aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=web-1" "Name=instance-state-name,Values=running" \
  --query "Reservations[0].Instances[0].PrivateIpAddress" --output text

من private-server جرّب curl -m 5 http://WEB-PRIVATE-IP، وبينتهي الوقت. الحين أنشئ الربط واقبله:

Bash

DEFAULT_VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true \
  --query "Vpcs[0].VpcId" --output text)

PEER=$(aws ec2 create-vpc-peering-connection \
  --vpc-id $VPC --peer-vpc-id $DEFAULT_VPC \
  --query VpcPeeringConnection.VpcPeeringConnectionId --output text)

aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id $PEER

الربط وحده ما يكفي، فأضف الطريق في الجهتين:

Bash

aws ec2 create-route --route-table-id $RT_PRIVATE \
  --destination-cidr-block 172.31.0.0/16 --vpc-peering-connection-id $PEER

DEFAULT_RT=$(aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=$DEFAULT_VPC Name=association.main,Values=true \
  --query "RouteTables[0].RouteTableId" --output text)

aws ec2 create-route --route-table-id $DEFAULT_RT \
  --destination-cidr-block 10.0.0.0/16 --vpc-peering-connection-id $PEER

أعد curl من private-server، وبترجع صفحة web-1 عبر العنوان الخاص.

Bash

aws ec2 delete-route --route-table-id $DEFAULT_RT \
  --destination-cidr-block 10.0.0.0/16

aws ec2 delete-vpc-peering-connection --vpc-peering-connection-id $PEER

الخلاصة

Peering لشبكتين، وما ينتقل، وTransit Gateway لما تكثر الشبكات.
Gateway Endpoint مجاني لـ S3 وDynamoDB، وInterface Endpoint لباقي الخدمات.
VPN سريع التجهيز عبر الإنترنت، وDirect Connect خط خاص ياخذ وقت.
نقل البيانات من أكبر المفاجآت في الفاتورة، فخطط له من البداية.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 5

تطبيق لمعالجة الطلبات في شبكة خاصة يكتب كثير على DynamoDB، والفريق لقى إن أغلب فاتورة NAT Gateway جاية من هذي الزيارات. وش يقلل هذي التكلفة بأقل جهد؟

اعرض الجواب

الجواب الصحيح: C

الـ Gateway Endpoint يضيف مسار إلى DynamoDB يتخطى NAT، بدون رسوم إضافية وبدون تغيير في الكود.

A: هذا يكشف سيرفرات لازم تبقى خاصة، والعناوين العامة مدفوعة كمان.
B: DynamoDB مو VPC تقدر تربطها بـ Peering.
D: هذا يربط موقعك أنت بـ AWS، وما له علاقة بالزيارات داخل الـ VPC.

للمراجعة: VPC Endpoints: خدمات AWS بدون إنترنت في هذا الجزء، وGateway endpoints for Amazon DynamoDB في وثائق AWS.

السؤال 2 من 5

فريق مدفوعات يشغّل واجهة API داخلية خلف Network Load Balancer. وأربعين VPC ثانية تحتاج تتصل فيها، وبعض نطاقاتهم تتداخل مع نطاقها، وما لازم يوصلون لأي شي ثاني في شبكتها. وش يناسب؟

اعرض الجواب

الجواب الصحيح: B

مع PrivateLink، كل طرف ياخذ واجهة خاصة في شبكته الفرعية توصل لهذي الخدمة فقط، فما يسبب تداخل النطاقات أي تعارض.

A: Peering ما يشتغل مع النطاقات المتداخلة، ويربط الشبكات بالكامل.
C: الـ Gateway Endpoint لـ S3 وDynamoDB فقط.
D: هذا يحط API داخلية على الإنترنت.

للمراجعة: VPC Endpoints: خدمات AWS بدون إنترنت في هذا الجزء، وAWS PrivateLink في وثائق AWS.

السؤال 3 من 5

شركة صغيرة لازم تربط شبكة مكتبها بـ VPC قبل الأسبوع الجاي. والزيارات قليلة، والميزانية محدودة، والبيانات لازم تكون مشفرة. أي خيار يناسب؟

اعرض الجواب

الجواب الصحيح: A

Site-to-Site VPN يمر عبر الإنترنت في نفق مشفر، وتقدر تجهزه بسرعة وبتكلفة قليلة.

B: تجهيزه ياخذ أسابيع أو أشهر، وتكلفته أعلى في البداية.
C: هذا لأجهزة الموظفين، مو لشبكة مكتب كاملة.
D: هذا يربط شبكات VPC ببعض، وما يوصل لمكتب.

للمراجعة: ربط مكتبك: Site-to-Site VPN في هذا الجزء، وWhat is AWS Site-to-Site VPN? في وثائق AWS.

السؤال 4 من 5

شركة تكبر إلى 30 VPC على عدة حسابات، مع ثلاث مكاتب متصلة بـ VPN. وتبي كل الشبكات تتصل في مكان واحد، مع فصل الإنتاج عن التطوير. وش يناسب بأقل عبء تشغيلي؟

اعرض الجواب

الجواب الصحيح: D

Transit Gateway محور مركزي لشبكات VPC والـ VPN، وجداول توجيهه تحدد مين يتكلم مع مين، وينشارك بين الحسابات عبر RAM.

A: ثلاثين شبكة تحتاج 435 اتصال، كل واحد بمساراته.
B: هذا يربط المكاتب ببعض عبر بوابة وحدة، مو مجموعة شبكات VPC.
C: Peering ما ينتقل، فالباقي ما يوصلون لبعض من خلالها.

للمراجعة: Transit Gateway: محور واحد في هذا الجزء، وWhat is AWS Transit Gateway for Amazon VPC? في وثائق AWS.

السؤال 5 من 5

بنك يوصل لـ AWS عبر خط Direct Connect واحد بسرعة 10 جيجابت. والتدقيق لقى مشكلتين: الخط نقطة فشل واحدة، وبياناته مو مشفرة. أي إجراءين يعالجون هذا؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: A + C

الخط الثاني في موقع ثاني يبقي البنك متصل لو تعطل خط أو موقع كامل. وMACsec أو VPN فوقه يضيف التشفير اللي ما يجي مع الخط افتراضياً.

B: الخط الأسرع لسا خط واحد، ولسا مو مشفر.
D: هذا يوصل لـ S3 وDynamoDB من داخل VPC، وما له علاقة بالخط.
E: هذا لسا خط واحد، والشريك ما يشفره لك.

للمراجعة: Direct Connect: خط خاص في هذا الجزء، وEncryption in AWS Direct Connect وAWS Direct Connect Resiliency Toolkit في وثائق AWS.

بهذا نكمل قسم الشبكات. الآن تعرف طريق الزائر من اسم موقعك لين بياناته، وبقي لنا مكان يتخزن فيه أي شي بأي حجم. هذا موضوع القسم الجاي، ونبدأه في الجزء الخامس عشر مع أساسيات S3.

VPC: شبكتك الخاصة

2026-11-02T00:00:00Z

كل سيرفر شغّلناه في هذي السلسلة كان داخل شبكة ما بنيتها: الـ VPC الافتراضية اللي تنشئها AWS في كل Region. وهي تكفي للتجارب، بس التطبيق الحقيقي يحتاج تصميم تكون فيه قاعدة البيانات مخفية، ولكل طبقة مكانها.

وش هي VPC؟

VPC (Virtual Private Cloud) شبكتك الخاصة داخل Region واحدة. تمتد على كل مناطق التوفر فيها، وما يدخلها أو يطلع منها شي إلا اللي تسمح له. هذا التصميم الشائع:

السيرفرات في شبكات خاصة، وتطلع للإنترنت عبر NAT في الشبكة العامة ثم بوابة الإنترنت، وما أحد يبدأ اتصال بها من الخارج.

نطاقات العناوين: كيف تقرأ CIDR

تكتب نطاق العناوين بصيغة CIDR، مثل 10.0.0.0/16. والرقم بعد الشرطة يقول كم بت ثابت من أصل 32، فكل ما صغر الرقم كبر النطاق:

CIDR	عدد العناوين	استخدام شائع
`/32`	1	عنوان واحد
`/28`	16	أصغر VPC أو شبكة فرعية
`/24`	256	شبكة فرعية
`/16`	65,536	أكبر VPC
`/0`	كل العناوين	`0.0.0.0/0` يعني أي مكان

استخدم النطاقات الخاصة: 10.0.0.0/8 أو 172.16.0.0/12 أو 192.168.0.0/16. والـ VPC الافتراضية تستخدم 172.31.0.0/16.

الشبكات الفرعية (Subnets)

الـ Subnet جزء من نطاق الـ VPC، وأهم شي تعرفه عنها:

تعيش في منطقة توفر واحدة. فعشان التوفر العالي تحتاج شبكات في منطقتين على الأقل.
AWS تحجز 5 عناوين في كل شبكة: أول أربعة وآخر عنوان. فـ /24 يعطيك 251 عنوان مو 256.
"عامة" و"خاصة" مو إعداد. الشبكة تصير عامة لما يكون في جدول توجيهها طريق لبوابة الإنترنت.

جداول التوجيه وبوابة الإنترنت

بوابة الإنترنت (Internet Gateway) تربط الـ VPC بالإنترنت. وجدول التوجيه (Route Table) يحدد وين تروح كل زيارة. فجدول الشبكة العامة يكون كذا:

الوجهة	الهدف	المعنى
`10.0.0.0/16`	`local`	داخل الـ VPC، وهذا موجود دايماً
`0.0.0.0/0`	`igw-...`	أي شي ثاني يروح للإنترنت

وعشان يوصل أحد للسيرفر من الخارج، يحتاج عنوان عام كمان. وتذكر من الجزء الرابع إن كل عناوين IPv4 العامة مدفوعة.

NAT Gateway: طلوع بدون دخول

السيرفر في الشبكة الخاصة يحتاج يطلع أحياناً، مثلاً لتحميل التحديثات، بس ما تبي أحد يدخل عليه. هذا دور NAT Gateway: يجلس في الشبكة العامة، ويطلّع طلبات السيرفرات الخاصة بعنوانه هو، وما يقبل اتصال يبدأ من الخارج.

وجدول الشبكة الخاصة فيه 0.0.0.0/0 يشير لـ nat-... بدل بوابة الإنترنت. وعندك أكثر من شكل:

الشكل	كيف يشتغل
NAT Gateway لمنطقة واحدة	لازم واحد في كل منطقة توفر، وإلا تعطلت الشبكات الخاصة في باقي المناطق لو طاحت منطقته
NAT Gateway إقليمي	أحدث، ويتوسع تلقائياً للمناطق اللي فيها سيرفراتك، ويُحسب لكل منطقة شغّالة
NAT Instance	سيرفر EC2 تديره بنفسك: تدفع على السيرفر بدل كل جيجابايت، وسرعته حسب حجمه، وما له تحويل تلقائي عند العطل، ولازم تطفي فحص Source/Destination. ممكن يكون أرخص للأحمال الصغيرة جداً، بس AWS توصي بـ NAT Gateway

كيف توصل لسيرفر خاص؟

ما له عنوان عام، فكيف تدخل عليه؟

الطريقة	كيف	ملاحظات
Bastion Host	سيرفر عام تدخل منه بـ SSH	قديمة: مفاتيح ومنفذ مفتوح وسيرفر زيادة تأمّنه
EC2 Instance Connect Endpoint	نقطة داخل شبكتك توصلك بالسيرفر بدون عنوان عام	مجانية، وبنستخدمها في التجربة
Session Manager	طرفية عبر خدمة SSM، بدون منفذ 22	يحتاج دور IAM، ويسجّل الجلسات

جدارين حماية: مجموعات الأمان وNACL

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

	مجموعة الأمان	NACL
المستوى	السيرفر	الشبكة الفرعية
القواعد	سماح فقط	سماح ومنع
الحالة	تتذكر الاتصال، فالرد يطلع تلقائياً	ما تتذكر، فلازم تسمح للرد كمان
التقييم	كل القواعد	بالترتيب، وأول قاعدة تنطبق تكفي
الافتراضي	الدخول ممنوع والخروج مسموح	الافتراضية تسمح بالكل، والجديدة تمنع الكل

وبما إن NACL ما تتذكر الاتصال، لازم تسمح لردود السيرفر عبر المنافذ المؤقتة (عادةً 1024-65535)، وهذا يسبب أخطاء كثيرة.

القاعدة العملية: خل NACL الافتراضية على حالها، واشتغل بمجموعات الأمان. واستخدم NACL لو تبي تمنع نطاق عناوين بسرعة، لأن مجموعة الأمان ما تقدر تمنع.

سجلات الزيارات (Flow Logs)

لما ما يوصل طلب وما تعرف ليش، Flow Logs تسجّل بيانات كل اتصال على مستوى VPC أو شبكة أو واجهة، وترسلها لـ CloudWatch Logs أو S3. والسطر يكون كذا:

Output

2 123456789012 eni-0abc 203.0.113.7 10.0.1.5 49152 22 6 5 300 1730000000 1730000060 REJECT OK

يعني: من 203.0.113.7 إلى 10.0.1.5 على المنفذ 22، وانرفض. وكيف تشخّص:

الدخول مرفوض: المشكلة في مجموعة الأمان أو NACL.
الدخول مقبول والخروج مرفوض: المشكلة في NACL، لأن مجموعة الأمان تسمح للرد تلقائياً.

عملي: ابنِ VPC من الصفر

بنبني شبكة فيها عامة وخاصة، ونشوف بأعيننا إن الفرق كله في جدول التوجيه. كل الأوامر من CloudShell. أول شي الشبكة والفروع:

Bash

VPC=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=series-vpc}]' \
  --query Vpc.VpcId --output text)

AZ=$(aws ec2 describe-availability-zones \
  --query "AvailabilityZones[0].ZoneName" --output text)

PUBLIC=$(aws ec2 create-subnet --vpc-id $VPC --cidr-block 10.0.1.0/24 \
  --availability-zone $AZ --query Subnet.SubnetId --output text)

PRIVATE=$(aws ec2 create-subnet --vpc-id $VPC --cidr-block 10.0.11.0/24 \
  --availability-zone $AZ --query Subnet.SubnetId --output text)

الحين بوابة الإنترنت وجدول توجيه للشبكة العامة فقط:

Bash

IGW=$(aws ec2 create-internet-gateway \
  --query InternetGateway.InternetGatewayId --output text)
aws ec2 attach-internet-gateway --vpc-id $VPC --internet-gateway-id $IGW

RT_PUBLIC=$(aws ec2 create-route-table --vpc-id $VPC \
  --query RouteTable.RouteTableId --output text)
aws ec2 create-route --route-table-id $RT_PUBLIC \
  --destination-cidr-block 0.0.0.0/0 --gateway-id $IGW
aws ec2 associate-route-table --route-table-id $RT_PUBLIC --subnet-id $PUBLIC

مجموعة أمان تسمح من داخل الشبكة فقط، ونقطة دخول حتى نوصل للسيرفرات بدون فتح منفذ للعالم:

Bash

SG=$(aws ec2 create-security-group --group-name series-sg \
  --description "SSH and ping from inside the VPC" --vpc-id $VPC \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $SG \
  --protocol tcp --port 22 --cidr 10.0.0.0/16
aws ec2 authorize-security-group-ingress --group-id $SG \
  --protocol icmp --port -1 --cidr 10.0.0.0/16

aws ec2 create-instance-connect-endpoint --subnet-id $PRIVATE \
  --security-group-ids $SG --no-preserve-client-ip

وسيرفر في كل شبكة:

Bash

AMI=$(aws ssm get-parameter \
  --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query Parameter.Value --output text)

aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
  --subnet-id $PUBLIC --security-group-ids $SG --associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=public-server}]'

aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
  --subnet-id $PRIVATE --security-group-ids $SG \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=private-server}]'

انتظر كم دقيقة لين تجهز نقطة الدخول. ثم من EC2 حدد السيرفر، واضغط Connect، وفي EC2 Instance Connect اختر الاتصال عبر نقطة الدخول. وعلى كل سيرفر جرّب:

Bash

curl -m 5 https://checkip.amazonaws.com

public-server: يطبع عنوانه العام.
private-server: ينتهي الوقت بدون جواب، لأن ما عنده طريق للإنترنت.

ومن الخاص جرّب ping على العنوان الخاص للعام، وبيرد لأن طريق local يربطهم.

أضف NAT Gateway

الحين خل الخاص يطلع للإنترنت. وهذي الخطوة مدفوعة بالساعة، فاحذفها بعد التجربة:

Bash

ALLOC=$(aws ec2 allocate-address --domain vpc \
  --query AllocationId --output text)

NAT=$(aws ec2 create-nat-gateway --subnet-id $PUBLIC --allocation-id $ALLOC \
  --query NatGateway.NatGatewayId --output text)
aws ec2 wait nat-gateway-available --nat-gateway-ids $NAT

RT_PRIVATE=$(aws ec2 create-route-table --vpc-id $VPC \
  --query RouteTable.RouteTableId --output text)
aws ec2 create-route --route-table-id $RT_PRIVATE \
  --destination-cidr-block 0.0.0.0/0 --nat-gateway-id $NAT
aws ec2 associate-route-table --route-table-id $RT_PRIVATE --subnet-id $PRIVATE

أعد نفس أمر curl على private-server. هذي المرة يطبع عنوان، وهو عنوان NAT Gateway مو عنوان السيرفر. فالسيرفر طلع للإنترنت، وما زال ما أحد يقدر يبدأ اتصال به.

الخلاصة

VPC شبكتك الخاصة في Region، وتقسمها لشبكات فرعية في مناطق التوفر.
الشبكة عامة لو في جدولها طريق لبوابة الإنترنت، وإلا فهي خاصة.
NAT Gateway يخلي الخاصة تطلع بدون ما أحد يدخل، وانتبه لتكلفته.
مجموعات الأمان تتذكر الاتصال وتسمح فقط، وNACL ما تتذكر وتقدر تمنع.
Flow Logs تقول لك وين انرفض الاتصال.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 6

سيرفر جديد له عنوان عام، ومجموعة الأمان حقته تسمح بـ HTTPS من أي مكان، ومع هذا ما أحد يقدر يوصل له من الإنترنت. والـ VPC مربوط فيها بوابة إنترنت، وجدول توجيه الشبكة الفرعية فيه مسار local فقط. وش الناقص؟

اعرض الجواب

الجواب الصحيح: A

الشبكة الفرعية تصير عامة لما يكون جدول توجيهها يشير لبوابة إنترنت. وبدون هذا المسار، ما فيه طريق للخروج، حتى مع وجود عنوان عام.

B: NAT يخلي السيرفرات الخاصة تطلع، وما يقبل اتصال يبدأ من الخارج.
C: مجموعة الأمان تتذكر الاتصال، فالرد يطلع تلقائياً.
D: Peering يربط شبكتين VPC، وما يعطي طريق للإنترنت.

للمراجعة: جداول التوجيه وبوابة الإنترنت في هذا الجزء، وEnable internet access for a VPC using an internet gateway في وثائق AWS.

السؤال 2 من 6

فريق يخطط لشبكة فرعية لازم تستوعب 30 سيرفر. والعناوين محدودة، فيبي أصغر نطاق يكفي. أي واحد يختار؟

اعرض الجواب

الجواب الصحيح: D

AWS تحجز 5 عناوين في كل شبكة فرعية. و/27 فيه 32، يبقى منها 27، فما يكفي. و/26 فيه 64، يبقى منها 59.

A: أصغر شبكة فرعية تسمح فيها AWS هي /28، فهذا ما ينشأ أصلاً.
B: هذا يبقى منه 11 عنوان بس.
C: هذا يبقى منه 27 عنوان، ناقص ثلاثة عن المطلوب.

للمراجعة: الشبكات الفرعية (Subnets) في هذا الجزء، وSubnet CIDR blocks في وثائق AWS.

السؤال 3 من 6

تطبيق يشتغل في شبكات خاصة على منطقتي توفر، ويتشاركون NAT Gateway لمنطقة واحدة في المنطقة الأولى. ولما تعطلت هذي المنطقة، بقت سيرفرات المنطقة الثانية سليمة، بس انقطع عنها الإنترنت. وش يحل هذا؟

اعرض الجواب

الجواب الصحيح: B

الـ NAT Gateway لمنطقة واحدة يعيش في منطقته، فلو طاحت انقطع كل اللي يعتمدون عليه. ولما يكون فيه واحد في كل منطقة، يبقى العطل في منطقته. وRegional NAT Gateway يعطيك نفس النتيجة تلقائياً.

A: الـ VPC لها بوابة إنترنت وحدة، والشبكات الخاصة ما توجّه لها.
C: العناوين الزيادة ما تطلعه من المنطقة المعطلة.
D: الـ NAT Gateway يجلس في الشبكة العامة، وهذا يقطعه عن الإنترنت.

للمراجعة: NAT Gateway: طلوع بدون دخول في هذا الجزء، وNAT gateway basics في وثائق AWS.

السؤال 4 من 6

عشان يمنع فريق نطاق عناوين مزعج، أنشأ NACL جديدة فيها قاعدة منع لهذا النطاق، وقاعدة سماح دخول للمنفذ 443. والحين ما أحد من الزوار يقدر يفتح الموقع. وFlow Logs تعرض الطلبات ACCEPT والردود REJECT. وش يسوي الفريق؟

اعرض الجواب

الجواب الصحيح: C

NACL ما تتذكر الاتصال، والجديدة تمنع كل شي ما سمحت له، فالردود تحتاج قاعدة خاصة فيها. والدخول المقبول مع الخروج المرفوض يشير مباشرة لـ NACL.

A: مجموعة الأمان تسمح فقط، فما تقبل قاعدة منع.
B: مجموعة الأمان تتذكر الاتصال، فكانت تخلي الرد يطلع من الأساس.
D: هذا يمنع الطلبات كمان.

للمراجعة: جدارين حماية: مجموعات الأمان وNACL وسجلات الزيارات (Flow Logs) في هذا الجزء، وCustom network ACLs for your VPC في وثائق AWS.

السؤال 5 من 6

المهندسين يحتاجون طرفية على سيرفرات في شبكة خاصة. والسيرفرات لازم تبقى بدون عناوين عامة، والفريق ما يبي سيرفر زيادة يحدّثه ويأمّنه. أي خيارين يناسبون؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: C + E

الاثنين يوصلون للسيرفر بدون عنوان عام وبدون سيرفر زيادة تشغله. وSession Manager كمان ما يحتاج منفذ 22، ويسجّل الجلسات.

A: هذا هو السيرفر الزيادة اللي الفريق ما يبيه.
B: الـ NAT Gateway يطلّع الزيارات فقط، وما يقبل اتصال يبدأ من الخارج.
D: هذا يعطي السيرفرات عناوين عامة، وهذا الممنوع بالضبط.

للمراجعة: كيف توصل لسيرفر خاص؟ في هذا الجزء، وSession Manager وEC2 Instance Connect Endpoint في وثائق AWS.

السؤال 6 من 6

فريق جهّز NAT Instance في شبكة عامة ووجّه جدول توجيه الشبكة الخاصة له، ومع هذا السيرفرات الخاصة ما توصل للإنترنت. ومجموعات الأمان تسمح بالزيارات. وش الأرجح إنه نسيه؟

اعرض الجواب

الجواب الصحيح: B

سيرفر EC2 لازم عادةً يكون مصدر زياراته أو وجهتها. والـ NAT Instance يمرر زيارات غيره، فلازم يكون هذا الفحص مطفي.

A: السيرفرات الخاصة تطلع بعنوان الـ NAT Instance، وما تحتاج عناوين خاصة فيها.
C: الشبكة العامة تحتاج مسارها لبوابة الإنترنت فقط، وهذا ما يضيف شي.
D: الـ Gateway Endpoint يوصل لـ S3 وDynamoDB، مو للإنترنت.

للمراجعة: NAT Gateway: طلوع بدون دخول في هذا الجزء، وEnable private resources to communicate outside the VPC في وثائق AWS.

شبكتك الحين جاهزة، بس معزولة. في الجزء الرابع عشر نربطها بشبكات ثانية، وبخدمات AWS، وبمكتبك.

CloudFront وGlobal Accelerator: أقرب لزوارك

2026-11-02T00:00:00Z

في الجزء الحادي عشر صار لموقعك اسم، بس سيرفره لسا في مكان واحد. والزائر البعيد طلبه يعبر قارات وشبكات كثيرة على الإنترنت العام، وكل طلب ياخذ وقت.

عندك خدمتين لهذي المشكلة: CloudFront يحفظ نسخة قريبة من الزائر، وGlobal Accelerator يختصر الطريق نفسه.

CloudFront: نسخة قريبة من كل زائر

CloudFront شبكة توصيل محتوى (CDN). تستخدم مواقع الحافة المنتشرة حول العالم، فأول زائر يطلب ملف يجيبه CloudFront من مصدرك ويحفظه، واللي بعده في نفس المنطقة ياخذه من موقع الحافة مباشرة.

كل زائر يصل لأقرب موقع حافة، وموقع الحافة ما يرجع للمصدر إلا لو ما عنده نسخة صالحة.

ووش تستفيد؟

سرعة أعلى: الجواب من مكان قريب.
ضغط أقل على المصدر: أغلب الطلبات تنتهي عند الحافة.
حماية: تجي مع Shield Standard ضد هجمات DDoS، وتقدر تضيف WAF.
HTTPS مجاني: بشهادة من ACM، وتشغيل TLS عند الحافة.

المصادر (Origins)

المصدر هو المكان الأصلي للمحتوى. وأهم شي إن الزوار ما يتخطون CloudFront ويوصلون له مباشرة:

المصدر	يناسب	كيف تخليه خاص
حاوية S3	مواقع ثابتة وملفات	OAC يخلي CloudFront وحده يقرأ منها
ALB	تطبيقات ديناميكية	VPC Origins يخلي الموزّع في شبكة خاصة
سيرفر EC2	تطبيق على سيرفر	VPC Origins، أو مجموعة أمان تسمح لنطاقات CloudFront فقط
أي سيرفر HTTP	حتى خارج AWS	ترويسة سرية يتحقق منها السيرفر

وبنشرح S3 بالتفصيل في قسم التخزين الكائني.

وش ينخزّن وكم؟

مفتاح الكاش (Cache Key): افتراضياً الرابط. وكل ما أضفت له ترويسات أو كوكيز، قلّت فرص إيجاد نسخة جاهزة، فخله بأقل ما يمكن.
مدة الصلاحية: من ترويسة Cache-Control عند المصدر، أو من إعدادات CloudFront.
السلوكيات (Behaviors): قواعد حسب المسار، مثل /images/* بمدة طويلة و/api/* بدون كاش. فنطاق واحد يخدم المحتوى الثابت والديناميكي.

مسح الكاش

لو غيّرت ملف، النسخة القديمة تبقى لين تنتهي صلاحيتها. وعندك حلين:

Invalidation: تطلب من CloudFront يمسح مسارات، مثل /*. وأول 1000 مسار في الشهر مجانية.
إصدار في اسم الملف: مثل main.css?v=12، فالإصدار الجديد رابط جديد. وهذا الحل الأفضل للملفات الثابتة.

ميزات إضافية

Geo Restriction: تسمح أو تمنع دول معينة، مثل محتوى مرخّص لبلد واحد.
روابط موقّعة (Signed URLs): لمحتوى مدفوع أو خاص، برابط له مدة.
CloudFront Functions وLambda@Edge: كود قصير يشتغل عند الحافة، مثل التحويلات وتعديل الترويسات.

الأسعار

عندك طريقتين، والأسعار ممكن تتغير فراجعها قبل ما تقرر:

حسب الاستخدام: تدفع على البيانات الخارجة والطلبات، ويختلف السعر حسب المنطقة. وكل شهر عندك 1 TB و10 ملايين طلب مجاناً. وPrice Classes تخليك تستثني المناطق الأغلى، مقابل تغطية أقل.
خطط ثابتة: Free وPro وBusiness وPremium بسعر شهري لكل توزيعة بدون مفاجآت، وتشمل خدمات ثانية مثل WAF.

ونقل البيانات من S3 أو ALB إلى CloudFront مجاني.

CloudFront أو نسخ S3 بين Regions؟

	CloudFront	S3 Cross-Region Replication
التغطية	كل مواقع الحافة	الـ Regions اللي تختارها
البيانات	نسخ مؤقتة لين تنتهي صلاحيتها	نسخ كاملة تتحدث باستمرار
يناسب	محتوى ثابت لكل العالم	بيانات متغيرة تبيها قريبة في Regions محددة

Global Accelerator: طريق أسرع

بعض الزيارات ما تنخزّن: لعبة عبر UDP، أو مكالمة صوتية، أو طلب دفع. لازم توصل لتطبيقك نفسه، وعلى الإنترنت العام تمر بشبكات كثيرة وتأخير غير ثابت.

Global Accelerator يدخّل الزائر شبكة AWS الخاصة من أقرب موقع حافة، ويكمل الطريق عليها لين تطبيقك.

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

عنوانين ثابتين عبر Anycast

في الإنترنت العادي (Unicast)، كل عنوان له جهاز واحد. وفي Anycast، عدة أماكن تشارك نفس العنوان، والشبكة توصلك لأقربها.

Global Accelerator يعطيك عنوانين ثابتين من هذا النوع، يشيرون لموزّعات ALB أو NLB أو سيرفرات EC2 أو Elastic IP، حتى في أكثر من Region. وهذا يعطيك:

عناوين ما تتغير: عميلك يقدر يسمح لها في جدار الحماية.
تحويل سريع: يتابع صحة التطبيق وينقل الزيارات، بدون ما تنتظر انتهاء كاش DNS عند الناس.
تحكم في الزيارات: تحدد نسبة كل Region، فتقدر تجرب نسخة جديدة في واحدة منها.
حماية: Shield Standard، وتطبيقك ما ينكشف مباشرة.

وتكلفته رسم ثابت بالساعة مع رسم إضافي على البيانات، فما هو مجاني مثل طبقة CloudFront.

أيهم تختار؟

	CloudFront	Global Accelerator
البروتوكولات	HTTP وHTTPS	أي TCP أو UDP
يخزّن؟	نعم	لا، يوصّل الطلب فقط
العناوين	تتغير، وتستخدم اسم نطاق	عنوانين ثابتين
يناسب	مواقع وصور وفيديو وواجهات API	ألعاب ومكالمات وIoT، أو حاجة لعناوين ثابتة

لو تطبيقك HTTP، ابدأ بـ CloudFront.

الصورة الكاملة حتى الآن

مسار الزائر صار كذا: Route 53 تعطيه العنوان، ثم CloudFront يجاوبه من أقرب موقع لو عنده نسخة، وإلا يوصّل طلبه لـ ALB، وهو يوزّعه على سيرفرات Auto Scaling، اللي تقرأ من ElastiCache وRDS.

عملي: شوف الكاش بعينك

بنحط CloudFront قدام سيرفرك web-1 من الجزء الثالث، لأنه يسمح بـ HTTP من أي مكان. من CloudShell:

Bash

ORIGIN=$(aws ec2 describe-instances \
  --filters "Name=tag:Name,Values=web-1" "Name=instance-state-name,Values=running" \
  --query "Reservations[0].Instances[0].PublicDnsName" --output text)

aws cloudfront create-distribution \
  --origin-domain-name "$ORIGIN" \
  --query "Distribution.[Id,DomainName]" --output table

احفظ المعرّف والاسم من الجدول، وانتظر لين تجهز، وهذا ياخذ كم دقيقة:

Bash

aws cloudfront wait distribution-deployed --id YOUR-DISTRIBUTION-ID

الحين اطلب الصفحة ثلاث مرات، وشوف الترويسات:

Bash

for i in 1 2 3; do
  curl -s -o /dev/null -D - https://YOUR-DOMAIN.cloudfront.net \
    | grep -iE "^(x-cache|age|x-amz-cf-pop)"
  echo
  sleep 2
done

أول طلب يرجع Miss from cloudfront، واللي بعده Hit from cloudfront مع age يزيد. وx-amz-cf-pop يوريك موقع الحافة اللي جاوبك.

الحين غيّر الصفحة على السيرفر من EC2 Instance Connect:

Bash

echo "<h1>New version</h1>" | sudo tee /usr/share/nginx/html/index.html

افتح رابط CloudFront، وبتلقى الصفحة القديمة لأنها لسا في الكاش. امسحها من CloudShell:

Bash

aws cloudfront create-invalidation \
  --distribution-id YOUR-DISTRIBUTION-ID --paths "/*"

بعد لحظات تظهر الصفحة الجديدة.

الخلاصة

CloudFront يحفظ نسخ قريبة من الزوار، فالموقع يسرع والضغط يقل على المصدر.
خل مصدرك خاص عبر OAC أو VPC Origins، عشان ما أحد يتخطى CloudFront.
إصدار في اسم الملف أفضل من مسح الكاش في كل مرة.
Global Accelerator ما يخزّن، بس يوصّل أي TCP أو UDP عبر شبكة AWS بعنوانين ثابتين.
لو تطبيقك HTTP ابدأ بـ CloudFront.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 5

لعبة جماعية ترسل زياراتها عبر UDP لسيرفرات في Regionين. واللاعبين يشتكون من تأخير غير ثابت، وبعض الشركاء ما يقدرون يسمحون في جدران الحماية إلا لعناوين ثابتة. أي خدمة تناسب؟

اعرض الجواب

الجواب الصحيح: B

Global Accelerator يوصّل أي TCP أو UDP عبر شبكة AWS من أقرب موقع حافة، ويعطيك عنوانين ثابتين ينحطون في جدار الحماية.

A: CloudFront يخدم HTTP وHTTPS، مو زيارات UDP حق لعبة.
C: هذا يختار Region بس، فالزيارات لسا تمر بالإنترنت العام، والعناوين مو ثابتة.
D: هذا ينسخ ملفات S3، وما له علاقة بزيارات اللعبة المباشرة.

للمراجعة: Global Accelerator: طريق أسرع في هذا الجزء، وAWS Global Accelerator FAQs في موقع AWS.

السؤال 2 من 5

أكاديمية على الإنترنت تحفظ ملفات دوراتها في S3 وتقدمها عبر CloudFront. والزوار لسا يقدرون يفتحون الملفات مباشرة من رابط الحاوية، ويتخطون CloudFront بالكامل. وش يقفل هذي الثغرة؟

اعرض الجواب

الجواب الصحيح: C

مع OAC، يوقّع CloudFront طلباته إلى S3، وسياسة الحاوية تقبل هذي الطلبات فقط، فتبقى الحاوية مقفلة على الكل.

A: هذا يحدد الدول داخل CloudFront، ورابط الحاوية يبقى مفتوح.
B: هذا يتحكم في اللي يمر عبر CloudFront، ورابط الحاوية يبقى مفتوح.
D: هذا يمسح النسخ من الكاش، وما يغير شي في مين يوصل للحاوية.

للمراجعة: المصادر (Origins) في هذا الجزء، وRestrict access to an Amazon S3 origin في وثائق AWS.

السؤال 3 من 5

نطاق واحد يخدم صور المنتجات تحت /images/* وواجهة API مباشرة تحت /api/*. والصور لازم تبقى في الكاش شهر، وردود الـ API ما تنخزن أبداً. وش أبسط طريقة لهذا في CloudFront؟

اعرض الجواب

الجواب الصحيح: D

الـ Behavior يطبق قواعده الخاصة على نمط مسار، فتوزيعة وحدة على نطاق واحد تقدر تحتفظ بالصور مدة طويلة، وتمرر الـ API مباشرة.

A: هذا يقسم الموقع على نطاقين بدون حاجة.
B: الـ Invalidation ياخذ وقت وما هو مصمم لكل طلب، والمسارات تصير مدفوعة بعد الحصة الشهرية.
C: هذا ما يخزن شي، فما يفيد الصور بشي.

للمراجعة: وش ينخزّن وكم؟ في هذا الجزء، وCache behavior settings في وثائق AWS.

السؤال 4 من 5

فريق يغيّر main.css كم مرة في اليوم. والزوار أحياناً يشوفون التنسيق القديم، والفريق مل من مسح الكاش بعد كل إصدار. وش الحل الأفضل على المدى الطويل؟

اعرض الجواب

الجواب الصحيح: A

الإصدار الجديد يعني رابط جديد، فياخذ الزوار النسخة الجديدة فوراً، بدون انتظار انتهاء القديمة وبدون أي مسح.

B: الزوار بيبقون على النسخة القديمة مدة أطول.
C: هذا يضيّع السرعة، ويرجّع الحمل على المصدر.
D: هذا يزيد نسخ لازم تبقى متطابقة، والقديمة تبقى في الكاش.

للمراجعة: مسح الكاش في هذا الجزء، وUse file versioning to update or remove content في وثائق AWS.

السؤال 5 من 5

موقع أخبار يلاحظ إن أغلب طلبات CloudFront لسا توصل للمصدر، حتى لمقالات نادراً تتغير. ومفتاح الكاش فيه كل الكوكيز والترويسات، والمصدر يرسل Cache-Control: max-age=60. أي تغييرين يزيدون نسبة الطلبات اللي ترد من الحافة؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: B + D

كل قيمة زيادة في المفتاح تقسم الصفحة الوحدة لنسخ كثيرة، والمدة القصيرة ترجّع الطلبات للمصدر بعد وقت قصير. ولما تصلح الاثنين، يلقى زوار أكثر نسخة جاهزة.

A: هذا يفضي الكاش، فتزيد المشكلة.
C: هذا ما يخزن، فالطلبات لسا توصل للمصدر.
E: بيكون لها نفس المفتاح ونفس المدة، فتتكرر نفس المشكلة.

للمراجعة: وش ينخزّن وكم؟ في هذا الجزء، وIncrease the proportion of requests that are served directly from the CloudFront caches في وثائق AWS.

كل هذا يوصّل الزائر لبوابة شبكتك، بس كيف تنبني الشبكة نفسها؟ في الجزء الثالث عشر نفتح VPC ونبني واحدة من الصفر.

DNS وRoute 53: عنوان موقعك

2026-11-02T00:00:00Z

موزّع الحمل في تطبيقنا من الجزء السابع اسمه شي زي web-alb-1234567890.eu-central-1.elb.amazonaws.com. ما أحد بيكتب هذا. الزائر يبي shop.example.com، واللي يربط بينهم هو DNS.

هذا القسم عن طريق الزائر لتطبيقك: الاسم في هذا الجزء، والسرعة في الجزء الجاي، ثم الشبكة الخاصة اللي يعيش فيها كل شي.

كيف يشتغل DNS؟

DNS دليل هاتف الإنترنت: تسأله باسم، ويجاوبك بعنوان. وما فيه سيرفر واحد يعرف كل شي، فالجواب يجي عبر سلسلة:

الـ Resolver يمر على السيرفرات الجذرية ثم سيرفرات ‎.com ثم سيرفرات أسماء النطاق، ويرجع بالعنوان للمتصفح.

متصفحك يسأل الـ Resolver، وهو عادةً من شركة الإنترنت أو خدمة عامة مثل 1.1.1.1.
الـ Resolver يسأل السيرفرات الجذرية، وهي توجّهه لسيرفرات .com.
سيرفرات .com توجّهه لسيرفرات أسماء النطاق.
سيرفرات أسماء النطاق تعطيه الجواب النهائي.
الـ Resolver يرجّع العنوان للمتصفح، ويحتفظ به لمدة TTL، فاللي يسأل بعدك يلقى الجواب فوراً.

وهذي المصطلحات اللي بتمر عليك:

المصطلح	معناه
Domain	`example.com`: الاسم اللي تملكه
Subdomain	`blog.example.com`: اسم تحته
Registrar	الشركة اللي تشتري منها الاسم
Hosted Zone	الحاوية اللي فيها سجلات النطاق
Record	سجل واحد: اسم يشير لقيمة
TTL	كم يقدر الـ Resolver يتذكر الجواب

Route 53

Route 53 خدمة DNS من AWS، واسمها من منفذ DNS رقم 53. وعندها ثلاث مهام: تحفظ سجلات نطاقك وتجاوب عنها، وتسجّل النطاقات، وتراقب صحة تطبيقك وتوجّه الزوار على أساسها. وAWS تلتزم فيها بتوفر 100%.

Hosted Zones

النوع	يجاوب مين	مثال
عامة	أي أحد على الإنترنت	`example.com`
خاصة	داخل شبكات VPC تحددها فقط	`db.series.internal`

كل واحدة تكلف حوالي نص دولار في الشهر، مع مبلغ بسيط على الاستعلامات.

أنواع السجلات

النوع	يشير إلى	مثال
A	عنوان IPv4	`blog.example.com` إلى `192.0.2.10`
AAAA	عنوان IPv6	`blog.example.com` إلى `2001:db8::10`
CNAME	اسم ثاني	`www.example.com` إلى `example.com`
NS	سيرفرات أسماء النطاق	`ns-1.awsdns-01.org`
MX	سيرفرات البريد	`mail.example.com`
TXT	نص حر، مثل إثبات ملكية النطاق	`v=spf1 ...`

CNAME أو Alias؟

عندك مشكلة شائعة: CNAME ما ينفع على النطاق الأساسي example.com، وأنت تبيه يشير لموزّع الحمل. الحل هو Alias، وهو نوع خاص في Route 53:

	CNAME	Alias
يشير إلى	أي اسم	موارد AWS مثل ALB وCloudFront وAPI Gateway
النطاق الأساسي	ما ينفع	ينفع
الاستعلامات	مدفوعة	مجانية لموارد AWS
TTL	تحدده أنت	تحدده Route 53
صحة الهدف	ما يتابعها	يقدر يتابعها

القاعدة بسيطة: لو الهدف على AWS، استخدم Alias. ولاحظ إنه ما يشير لاسم DNS حق سيرفر EC2.

اختيار TTL

مدة طويلة: استعلامات أقل وتكلفة أقل، بس أي تغيير ياخذ وقت عشان ينتشر.
مدة قصيرة: التغيير ينتشر بسرعة، بس الاستعلامات تزيد.

سياسات التوجيه

"التوجيه" هنا ما يعني إن الزيارات تمر عبر Route 53. هي تختار وش الجواب اللي تعطيه فقط، وبعدها يتصل الزائر مباشرة بالعنوان.

السياسة	كيف تجاوب	استخدام شائع
Simple	سجل واحد، وممكن فيه أكثر من قيمة	سيرفر واحد
Weighted	بنسب تحددها	تجربة نسخة جديدة على 10% من الزوار
Latency	الـ Region الأقل تأخير للزائر	تطبيق في أكثر من Region
Failover	الأساسي طالما سليم، وإلا الاحتياطي	التعافي من الكوارث
Geolocation	حسب دولة الزائر أو قارته	لغة أو محتوى حسب البلد
Geoproximity	حسب المسافة، مع تكبير أو تصغير نطاق كل موقع	نقل الزيارات تدريجياً بين المناطق
IP-based	حسب نطاق IP الزائر	شبكات معروفة عندك
Multivalue	لين 8 سجلات سليمة	توزيع بسيط، وما يغني عن موزّع الحمل

فحوصات الصحة

عشان Failover وغيرها تشتغل، لازم Route 53 تعرف مين سليم:

النوع	كيف يفحص
Endpoint	أجهزة فحص حول العالم تطلب عنوانك عبر HTTP أو HTTPS أو TCP
Calculated	يجمع نتائج عدة فحوصات في نتيجة وحدة
CloudWatch Alarm	يعتمد على إنذار، وهذا الحل للموارد الخاصة

وأجهزة الفحص من الإنترنت، فما توصل لسيرفر في شبكة خاصة، ولازم مجموعة الأمان تسمح لنطاقاتها لو تفحص هدف عام.

نطاق مشترى من مكان ثاني

شراء النطاق وإدارة سجلاته شيئين منفصلين. لو اشتريت نطاقك من شركة ثانية وتبي Route 53 تجاوب عنه:

أنشئ Hosted Zone عامة باسم النطاق.
انسخ سيرفرات الأسماء الأربعة من سجل NS فيها.
الصقها في إعدادات النطاق عند الشركة اللي اشتريت منها.

بعد ما ينتشر التغيير، Route 53 تصير هي اللي تجاوب.

ولو عندك شبكة في مكتبك، تقدر تربط DNS حقها مع AWS عبر Resolver Endpoints: الداخلي (Inbound) يخلي شبكتك تسأل عن أسماء AWS الخاصة، والخارجي (Outbound) يخلي AWS تسأل عن أسماء شبكتك. وهذا يحتاج اتصال بين الشبكتين، وهو موضوع الجزء الرابع عشر.

عملي: توجيه بالنسب بدون شراء نطاق

الـ Hosted Zone الخاصة تخليك تجرب كل هذا بدون نطاق حقيقي. وبنستخدم سيرفرك web-1 من الجزء الثالث داخل الشبكة الافتراضية. من CloudShell، أنشئ النطاق الخاص:

Bash

VPC_ID=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true \
  --query "Vpcs[0].VpcId" --output text)

ZONE_ID=$(aws route53 create-hosted-zone --name series.internal \
  --caller-reference "demo-$(date +%s)" \
  --vpc VPCRegion=$AWS_REGION,VPCId=$VPC_ID \
  --query HostedZone.Id --output text)

الحين أضف سجلين لنفس الاسم، 80% للنسخة القديمة و20% للجديدة. والعناوين هنا وهمية، لأن DNS يجاوب فقط وما يتصل بها:

Bash

CHANGES='{"Changes":[
  {"Action":"CREATE","ResourceRecordSet":{"Name":"app.series.internal","Type":"A","TTL":5,
    "SetIdentifier":"old","Weight":80,"ResourceRecords":[{"Value":"10.0.0.80"}]}},
  {"Action":"CREATE","ResourceRecordSet":{"Name":"app.series.internal","Type":"A","TTL":5,
    "SetIdentifier":"new","Weight":20,"ResourceRecords":[{"Value":"10.0.0.20"}]}}
]}'

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" --change-batch "$CHANGES"

ادخل على السيرفر من EC2 Instance Connect، وأرسل 20 سؤال. والتجربة تاخذ دقيقتين لأننا ننتظر انتهاء TTL في كل مرة:

Bash

sudo dnf install -y bind-utils

for i in $(seq 1 20); do
  dig +short app.series.internal
  sleep 6
done | sort | uniq -c

بتشوف توزيع قريب من 16 مقابل 4. جرّب كمان dig +trace aws.amazon.com، وبتشوف السلسلة اللي في الرسم خطوة بخطوة.

ولو عندك نطاق، أضف سجل A من نوع Alias يشير لموزّع الحمل، وصار موقعك باسمك.

Bash

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" --change-batch "${CHANGES//CREATE/DELETE}"

aws route53 delete-hosted-zone --id "$ZONE_ID"

الخلاصة

DNS يحول الاسم لعنوان عبر سلسلة، والجواب ينحفظ لمدة TTL.
Route 53 تحفظ سجلاتك، وHosted Zone ممكن تكون عامة أو خاصة.
لو الهدف على AWS استخدم Alias، وهو ينفع على النطاق الأساسي.
سياسات التوجيه تختار الجواب فقط، والزيارات ما تمر عبرها.
فحوصات الصحة هي اللي تخلي Failover يشتغل.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 5

موقع مخبز يشتغل خلف Application Load Balancer، وصاحبه يبي اللي يكتب النطاق الأساسي example.com يوصل له. وعناوين الموزّع ممكن تتغير في أي وقت. أي سجل يناسب؟

اعرض الجواب

الجواب الصحيح: D

Alias ينفع على النطاق الأساسي، ويتابع عناوين الموزّع المتغيرة بدالك، والاستعلامات عن موارد AWS مثل هذا مجانية.

A: CNAME ما ينفع على النطاق الأساسي.
B: أول ما تتغير العناوين، يصير السجل يشير لمكان غلط.
C: سجل TXT فيه نص حر، والمتصفحات ما تستخدمه عشان تلقى السيرفر.

للمراجعة: CNAME أو Alias؟ في هذا الجزء، وChoosing between alias and non-alias records في وثائق AWS.

السؤال 2 من 5

خدمة بث تشتغل في Regionين، فرانكفورت والبحرين. ورخصتها تشترط إن زوار السعودية ياخذون نسخة البحرين دايماً، حتى لو كانت فرانكفورت أسرع لهم. أي سياسة توجيه تناسب؟

اعرض الجواب

الجواب الصحيح: A

Geolocation يختار حسب مكان الزائر مو حسب السرعة، وهذا اللي يحتاجه شرط الرخصة.

B: هذا يرسل الزائر لأسرع Region، وممكن تكون فرانكفورت.
C: هذا يقسم الزيارات بنسب، مهما كانت دولة الزائر.
D: هذا يرجّع عدة سجلات سليمة، بدون أي اعتبار للدولة.

للمراجعة: سياسات التوجيه في هذا الجزء، وGeolocation routing في وثائق AWS.

السؤال 3 من 5

تطبيق داخلي يستخدم سجل Failover في Hosted Zone خاصة. وسيرفراته الأساسية لها عناوين خاصة فقط، ولازم تبقى كذا. كيف تعرف Route 53 إن الأساسي سليم؟

اعرض الجواب

الجواب الصحيح: C

أجهزة الفحص في Route 53 جاية من الإنترنت، فما توصل لعنوان خاص. أما CloudWatch Alarm فيقدر يراقب مقياس من السيرفرات، وفحص الصحة يتبع الإنذار.

A: أجهزة الفحص برا الشبكة، وما توصل لعنوان خاص.
B: هذا يخالف شرط إن السيرفرات تبقى خاصة.
D: هذا يجمع فحوصات ثانية بس، وهي لسا ما توصل للسيرفرات.

للمراجعة: فحوصات الصحة في هذا الجزء، وConfiguring failover in a private hosted zone في وثائق AWS.

السؤال 4 من 5

شركة ناشئة اشترت نطاقها من شركة ثانية وتبي يبقى التسجيل عندها، بس Route 53 هي اللي ترد على سجلات النطاق. وش لازم تسوي؟

اعرض الجواب

الجواب الصحيح: B

شراء الاسم والرد عليه شيئين منفصلين. وأول ما تضيف الشركة سيرفرات أسماء Route 53، تصير Route 53 هي اللي ترد.

A: النقل اختياري، وما تحتاجه عشان تدير السجلات.
C: الـ Zone الخاصة ترد داخل شبكات VPC تحددها فقط، مو للعامة.
D: هذا يخلي شبكة المكتب تسأل عن الأسماء الخاصة، وما له علاقة بالردود العامة.

للمراجعة: نطاق مشترى من مكان ثاني في هذا الجزء، وMaking Route 53 the DNS service for a domain that's in use في وثائق AWS.

السؤال 5 من 5

فريق يبي يرسل 10% من الزوار لإصدار جديد من تطبيقه، ويرجّع هذي الزيارات خلال دقايق لو صار أي شي. أي خطوتين تناسب؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: A + E

سجلات Weighted تقسم الردود بالنسب اللي تحددها، والـ TTL القصير يعني التغيير يوصل للزوار بسرعة، لأن الـ Resolver يتذكر الجواب هذي المدة فقط.

B: هذا يختار حسب المكان، مو حسب نسبة من الزوار.
C: الـ Resolver بيحتفظ بالجواب القديم لحد يوم، فيصير الرجوع بطيء.
D: سجل Simple ما يعطيك طريقة تحدد فيها النسبة.

للمراجعة: سياسات التوجيه واختيار TTL في هذا الجزء، وWeighted routing في وثائق AWS.

الحين موقعك له اسم، بس سيرفره لسا في مكان واحد، والزائر البعيد ينتظر. في الجزء الثاني عشر نقرّبه منه مع CloudFront وGlobal Accelerator.

أي قاعدة بيانات تختار؟

2026-11-02T00:00:00Z

في الجزء الثامن والتاسع شفنا RDS وAurora وElastiCache. بس لو فتحت قائمة AWS بتلقى أكثر من عشر خدمات قواعد بيانات، وهنا يبدأ الضياع.

السؤال الصحيح مو "وش أفضل قاعدة بيانات؟"، لأن ما فيه جواب واحد. السؤال: وش يناسب هذي البيانات بالذات؟

أسئلة تبدأ بها

قبل ما تفتح أي خدمة، جاوب على هذي الأسئلة:

السؤال	ليش يهم
وش شكل البيانات؟	جداول مترابطة، أو مستندات متغيرة، أو علاقات، أو قراءات عبر الزمن
كيف بتقراها؟	بمفتاح، أو باستعلامات معقدة تربط جداول، أو ببحث في النص، أو بتجميع ملايين الصفوف
كم القراءة مقابل الكتابة؟	الكثير من القراءة يتحل بكاش ونسخ قراءة، والكثير من الكتابة يحتاج تصميم مختلف
كم الحجم وكم النمو؟	جيجابايت عادية أو بيانات تكبر بلا سقف
كم لازم تكون دقيقة؟	تحويل مبلغ يحتاج معاملات صارمة، وعدد الإعجابات يتحمل تأخير
كم تقدر تدير؟	فريق صغير يفضل خدمة تتوسّع لحالها
وش يعرف فريقك؟	معرفة الفريق تختصر عليك أخطاء كثيرة

أنواع قواعد البيانات

النوع	شكل البيانات	خدمة AWS	مثال
علائقية	جداول مترابطة ومعاملات	RDS وAurora	طلبات وحسابات وفواتير
مفتاح وقيمة	قيمة تجيبها بمفتاحها، بحجم ضخم	DynamoDB	سلات شراء وملفات مستخدمين
مستندات	JSON بحقول مختلفة	DocumentDB وDynamoDB	كتالوجات ومحتوى
في الذاكرة	بيانات سريعة	ElastiCache وMemoryDB	كاش وجلسات
أعمدة واسعة	صفوف بأسلوب Cassandra وكتابة عالية	Keyspaces	أنظمة Cassandra قائمة
رسم بياني	روابط بين الأشياء	Neptune	شبكات اجتماعية وكشف احتيال
سلاسل زمنية	قراءات عبر الزمن	Timestream for InfluxDB	حساسات ومقاييس
بحث	نصوص تبحث داخلها	OpenSearch	بحث الموقع والسجلات
تحليلات	تجميع على بيانات ضخمة	Redshift	تقارير الإدارة
ملفات	ملفات بأي شكل	S3 مع Athena	سجلات وأرشيف

علائقية أو NoSQL؟

هذا أول قرار، والفرق الحقيقي في طريقة التفكير:

	علائقية (SQL)	NoSQL
التصميم	تصمم الجداول، ثم تكتب أي استعلام	تحدد الاستعلامات أولاً، ثم تصمم عليها
الاستعلامات	مرنة، مع ربط الجداول	محدودة، وسريعة في المسار اللي صممته
المعاملات	قوية	تختلف من خدمة لخدمة
التوسّع	القراءة سهلة، والكتابة غالباً بسيرفر أكبر	أفقي، بأداء ثابت مع الحجم

خدمات بتمر عليك

DynamoDB: مفتاح وقيمة بدون سيرفرات، وأداء ثابت بأي حجم. بنشرحها في الجزء الحادي والعشرين.
DocumentDB: مستندات متوافقة مع MongoDB، فتناسبك لو تنقل تطبيق MongoDB قائم.
MemoryDB: ذاكرة سريعة مثل Valkey لكن بيانات تدوم، فتقدر تستخدمها كقاعدة أساسية وليس كاش فقط.
Keyspaces: متوافقة مع Apache Cassandra، بدون سيرفرات تديرها.
Neptune: للبيانات اللي قيمتها في العلاقات، زي "أصدقاء أصدقائي اللي اشتروا هذا".
Timestream for InfluxDB: لقراءات الحساسات والمقاييس. والنسخة القديمة LiveAnalytics مقفلة على العملاء الجدد.
OpenSearch: بحث نصي وتحليل سجلات، وعادةً نسخة من بياناتك مو المصدر الأساسي.
Redshift: مستودع بيانات للتقارير الضخمة. بنشرحه في الجزء الثالث والعشرين.

كيف تقرر؟

مر على الأسئلة من فوق لتحت، وأول "نعم" هي نقطة بدايتك:

تبدأ من أعلى، وكل "نعم" تعطيك خدمة تبدأ بها، ولو ما انطبق شي فقاعدة علائقية هي الاختيار الافتراضي.

وهذا دليل بداية مو قانون. التطبيق الواحد عادةً يستخدم أكثر من نوع، وكل نوع بيانات يروح للي يناسبه.

طبقة بيانات تكبر مع تطبيقك

ما تحتاج كل هذا من أول يوم. تخيل متجر إلكتروني يكبر مع الوقت:

الإطلاق: قاعدة RDS واحدة تكفي. ولما تبدأ تستقبل طلبات حقيقية، فعّل Multi-AZ.
الزوار زادوا والقراءة ثقلت: أضف ElastiCache للصفحات الرئيسية والجلسات.
التقارير صارت تبطّئ الموقع: وجّهها لـ نسخة قراءة.
بحث المنتجات ضعيف: أضف OpenSearch وعبّيه من قاعدة البيانات.
الإدارة تبي تحليلات سنوات: انقل البيانات لـ S3 مع Athena أو Redshift.
صار عندك زوار حول العالم: انتقل لـ Aurora Global Database.

كل خطوة جات بعد مشكلة حقيقية قستها، مو قبلها. أي خدمة زايدة تعني تكلفة وتعقيد وشي ثاني ممكن يتعطّل.

أخطاء شائعة

اختيار NoSQL لأنها "تتوسّع": ثم تكتشف إنك تحتاج استعلامات ما صممت لها.
تشغيل التقارير على قاعدة الإنتاج: استعلام واحد ثقيل يبطّئ الموقع كله.
تخزين الملفات داخل قاعدة البيانات: حطها في S3، واحفظ رابطها في القاعدة.
معاملة الكاش كمصدر للحقيقة: لو ضاع، لازم ما يضيع معه شي مهم.
Multi-AZ في بيئة التطوير: تكلفة مضاعفة بدون فايدة غالباً.

الخلاصة

اسأل عن شكل البيانات وطريقة قراءتها قبل اسم الخدمة.
ابدأ علائقية إلا لو عندك سبب واضح لغيرها.
التطبيق الواحد يستخدم أكثر من نوع، وكل بيانات تروح للي يناسبها.
أضف كل خدمة لما تقيس مشكلة حقيقية، مو قبلها.

اختبر نفسك

قبل ما تكمل، جرّب هذي الأسئلة عشان تتأكد إنك فهمت الجزء. كل سؤال موقف عملي، وبعد ما تجاوب يطلع لك الشرح.

السؤال 1 من 5

عيادة تبني نظام حجوزات فيه مواعيد ومرضى ومدفوعات. البيانات مترابطة، والمدفوعات تحتاج معاملات صارمة، والفريق الصغير لسا ما يعرف كل التقارير اللي بيحتاجها. وين يبدأ؟

اعرض الجواب

الجواب الصحيح: B

البيانات المترابطة والمعاملات والاستعلامات اللي ما تقدر تتوقعها كلها تشير لقاعدة علائقية. وهي الخيار المعقول افتراضياً إلا لو فيه سبب واضح.

A: بتصمم حول استعلامات معروفة من البداية، وبيصعب إضافة تقارير جديدة.
C: الكاش مو مصدر الحقيقة، فما ينفع تكون المدفوعات فيه.
D: Neptune يناسب شبكات العلاقات العميقة، مو الجداول المترابطة العادية.

للمراجعة: علائقية أو NoSQL؟ في هذا الجزء، وChoosing an AWS database service في وثائق AWS.

السؤال 2 من 5

تطبيق اجتماعي يبي يقترح "ناس ممكن تعرفهم" بتتبع أصدقاء الأصدقاء عبر عدة خطوات، وبرد سريع. أي خدمة تناسب أكثر؟

اعرض الجواب

الجواب الصحيح: D

القيمة هنا في العلاقات نفسها، وNeptune مبني يمشي عبر أعداد كبيرة منها بزمن استجابة منخفض.

A: ينفع لخطوة أو خطوتين، بس الربط يثقل كل ما زادت الخطوات.
B: تقدر تخزن قوائم جاهزة، بس لسا لازم شي يحسبها.
C: هذا للقراءات عبر الوقت، وما له علاقة بالعلاقات.

للمراجعة: خدمات بتمر عليك في هذا الجزء، وChoosing an AWS database service في وثائق AWS.

السؤال 3 من 5

عشرة آلاف حساس ترسل قراءة حرارة كل دقيقة، والمهندسين يبون متوسط كل ساعة لكل حساس خلال آخر أسبوع. أي خدمة مبنية لهذا؟

اعرض الجواب

الجواب الصحيح: A

هذي قراءات عبر الوقت، وقواعد السلاسل الزمنية مبنية تخزنها وتجمعها.

B: هذا للعلاقات بين الأشياء.
C: هذا لمستندات JSON بحقول مختلفة.
D: هذا أساساً للبحث في النصوص وتحليل السجلات.

للمراجعة: أنواع قواعد البيانات في هذا الجزء، وWhat is Timestream for InfluxDB? في وثائق AWS.

السؤال 4 من 5

شركة تبي تنقل تطبيق MongoDB قائم إلى خدمة مُدارة في AWS بأقل تغيير في الكود. أي خدمة تناسب؟

اعرض الجواب

الجواب الصحيح: C

DocumentDB متوافق مع MongoDB، فنموذج المستندات وكثير من الكود ممكن يبقون زي ما هم.

A: واجهتها ونموذج بياناتها مختلفين، فبينكتب كود الوصول للبيانات من جديد.
B: هذا متوافق مع Cassandra، مو MongoDB.
D: هذا علائقي، فبتحتاج تعيد تصميم المستندات كجداول.

للمراجعة: خدمات بتمر عليك في هذا الجزء، وWhat is Amazon DocumentDB? في وثائق AWS.

السؤال 5 من 5

فريق مبيعات يبي تقارير على طلبات خمس سنوات، يعني مليارات الصفوف، والاستعلامات ما لازم تبطئ قاعدة الإنتاج. أي طريقتين تناسب؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: B + E

الطريقتين يبعدون التحليل الثقيل عن الإنتاج. وRedshift يناسب التقارير الثقيلة المتكررة، وAthena يناسب الأسئلة العابرة بدون سيرفرات تشغلها.

A: استعلام ثقيل واحد ممكن يضر أي شي شغال وقتها، وهي قاعدة علائقية مو مبنية لتحليل بهذا الحجم.
C: الكاش نسخة مؤقتة، وصغير وغالي جداً على بيانات خمس سنوات.
D: النسخة الاحتياطية في Multi-AZ ما ينقرأ منها.

للمراجعة: أخطاء شائعة في هذا الجزء، وWhat is Amazon Athena? في وثائق AWS.

بهذا نكمل قسم قواعد البيانات. تطبيقك الحين يشتغل ويتوسّع، وبياناته في أمان، بس كيف يوصل له الزوار باسم موقعك؟ هذا موضوع القسم الجاي، ونبدأه في الجزء الحادي عشر مع DNS وRoute 53.

sultanops

التكلفة والتصميم الجيد

وين تروح فلوس الشبكة؟ #

وين الكاش؟ #

أدوات تراقب فاتورتك #

توفير سريع #

إطار Well-Architected #

CloudFormation: بنيتك في ملف #

Systems Manager: تشغيل سيرفراتك #

تطبيقات ما تقدر تغيرها #

خدمات تستاهل تعرفها #

الحوسبة عالية الأداء #

عملي: Stack كامل من ملف، وميزانية بتبقيها #

الخلاصة #

اختبر نفسك #

اللي تعلمته #

وين تروح من هنا #

التعافي من الكوارث والترحيل

RPO وRTO #

أربع استراتيجيات #

نصائح تفرق #

AWS Backup: كل شي في مكان واحد #

ترحيل قواعد البيانات: DMS #

النقل إلى RDS أو Aurora #

ترحيل السيرفرات ومراكز البيانات #

عملي: احذف البيانات ورجعها #

الخلاصة #

اختبر نفسك #

التشفير والأسرار والحماية من الهجمات

AWS KMS: خزنة المفاتيح #

التشفير بالمظروف (Envelope Encryption) #

أنواع المفاتيح #

سياسات المفاتيح #

المفاتيح متعددة المناطق #

CloudHSM: عتادك الخاص #

وين تحفظ كلمات المرور؟ #

Parameter Store #

Secrets Manager #

ACM: شهادات بدون وجع راس #

صد الهجمات #

تحمل DDoS #

حجب عنوان واحد: وين؟ #

كشف التهديدات #

مستندات الامتثال: AWS Artifact #

عملي: مفتاح وقيمة وسر #

الخلاصة #

اختبر نفسك #

الهوية المتقدمة: Organizations وIdentity Center

AWS Organizations #

سياسات المنظمة #

Service Control Policies (SCP) #

الشروط في سياسات IAM #

غلطة S3 الكلاسيكية #

دور أو سياسة مورد؟ #

حدود الصلاحيات (Permissions Boundaries) #

كيف تقرر AWS؟ #

IAM Identity Center: دخول واحد #

الدخول من هوية خارجية (Federation) #

Active Directory على AWS #

AWS Control Tower #

عملي: اختبر السياسات بدون ما تلمس شي #

الخلاصة #

اختبر نفسك #

المراقبة والتدقيق: CloudWatch وCloudTrail وConfig

مقاييس CloudWatch #

سجلات CloudWatch #

إنذارات CloudWatch #

رؤى جاهزة #

EventBridge: الرد على الأحداث #

CloudTrail: مين سوى وش #

AWS Config: إعداداتك مع الوقت #

X-Ray: تتبع طلب واحد #

أدوات ثانية للمتابعة #

أيها ومتى؟ #

عملي: إنذار يرسل لك إيميل #

الخلاصة #

اختبر نفسك #

خدمات الذكاء الاصطناعي الجاهزة

الصور: Rekognition #

الكلام: Transcribe وPolly #

وين تروح فلوس الشبكة؟

وين الكاش؟

أدوات تراقب فاتورتك

توفير سريع

إطار Well-Architected

CloudFormation: بنيتك في ملف

Systems Manager: تشغيل سيرفراتك

تطبيقات ما تقدر تغيرها

خدمات تستاهل تعرفها

الحوسبة عالية الأداء

عملي: Stack كامل من ملف، وميزانية بتبقيها

الخلاصة

اختبر نفسك

اللي تعلمته

وين تروح من هنا

RPO وRTO

أربع استراتيجيات

نصائح تفرق

AWS Backup: كل شي في مكان واحد

ترحيل قواعد البيانات: DMS

النقل إلى RDS أو Aurora

ترحيل السيرفرات ومراكز البيانات

عملي: احذف البيانات ورجعها

الخلاصة

اختبر نفسك

AWS KMS: خزنة المفاتيح

التشفير بالمظروف (Envelope Encryption)

أنواع المفاتيح

سياسات المفاتيح

المفاتيح متعددة المناطق

CloudHSM: عتادك الخاص

وين تحفظ كلمات المرور؟

Parameter Store

Secrets Manager

ACM: شهادات بدون وجع راس

صد الهجمات

تحمل DDoS

حجب عنوان واحد: وين؟

كشف التهديدات

مستندات الامتثال: AWS Artifact

عملي: مفتاح وقيمة وسر

الخلاصة

اختبر نفسك

AWS Organizations

سياسات المنظمة

Service Control Policies (SCP)

الشروط في سياسات IAM

غلطة S3 الكلاسيكية

دور أو سياسة مورد؟

حدود الصلاحيات (Permissions Boundaries)

كيف تقرر AWS؟

IAM Identity Center: دخول واحد

الدخول من هوية خارجية (Federation)

Active Directory على AWS

AWS Control Tower

عملي: اختبر السياسات بدون ما تلمس شي

الخلاصة

اختبر نفسك

مقاييس CloudWatch

سجلات CloudWatch

إنذارات CloudWatch

رؤى جاهزة

EventBridge: الرد على الأحداث

CloudTrail: مين سوى وش

AWS Config: إعداداتك مع الوقت

X-Ray: تتبع طلب واحد

أدوات ثانية للمتابعة

أيها ومتى؟

عملي: إنذار يرسل لك إيميل

الخلاصة

اختبر نفسك

الصور: Rekognition

الكلام: Transcribe وPolly

الترجمة: Translate

المحادثة: Lex وConnect

النص: Comprehend

المستندات: Textract

التوصيات: Personalize

البحث في مستنداتك: وماذا عن Kendra؟

النماذج التوليدية: Amazon Bedrock