خدمات AWS للمطورين: نافذة DVA-C02 الأخيرة قبل DVA-C03 | كبسولات حوسبية احترافية

ملخص للقاء AWS Egypt User Group عبر الإنترنت، الذي عُقد يوم الاثنين 28 سبتمبر 2026، الساعة 10:00 مساءً بتوقيت القاهرة (GMT+3) عبر Google Meet. قُدّمت الجلسة بالعربية مع استخدام المصطلحات التقنية الإنجليزية، وهذه المقالة تكيّف محتواها للنشر على OneKC.pro. يمكنك مشاهدة تسجيل لهذا الجتماع على يوتيوب من خلال هذا الرابط.  نستعرض خريطة مصنّفة لخدمات AWS التي يستخدمها المطورون، وثماني معماريات تطبيقات تتدرج من البسيط إلى الأكثر تعقيدًا، وأهم ما ينبغي معرفته قبل تحديث امتحان AWS Certified Developer – Associate.

مرحبا بكم فى كبسولات الحوسبة السحابية من ألف محترف سحابي حيث نقدم مقدمة مبسطة للخدمات الرئيسية لأيه دبليو اس (AWS).

لماذا هذه الكبسولات؟

سوف تساعدك هذه الكبسولات من “ألف محترف حوسبي” على التعرف على العديد من الخدمات و المكونات السحابية المقدمة من AWS.

أولًا: لماذا نحتاج إلى هذه الخريطة؟ ولماذا الآن؟

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

اتخذت الجلسة نهجًا مختلفًا، وارتكزت على فكرة تكررت طوال العرض:

هذه خريطة، وليست دليلًا تفصيليًا لكل خدمة.

وترتبط هذه الخريطة أيضًا بموعد مهم: يجري تحديث امتحان AWS Certified Developer – Associate. ووفقًا لإعلان AWS لشهر سبتمبر 2026، فإن المواعيد المعلنة هي:

المصدر: إعلان AWS للتدريب والشهادات – سبتمبر 2026. راجع أيضًا صفحة شهادة AWS Certified Developer – Associate قبل الحجز.

ننظر إلى الموضوع من زاويتين متكاملتين: الجانب العملي – ماذا نبني، وما الخدمات التي نحتاجها؟ وجانب الامتحان — ما الذي يتوقع من المرشح أن يتعرّف عليه؟ والتداخل بين الجانبين أكبر مما قد يبدو، وهذا ما يجعل خريطة خدمات AWS للمطورين مفيدة للتعلّم والاستعداد للشهادة معًا.

ثانيًا: الامتحان في قسم واحد

قبل استعراض معماريات التطبيقات، إليك نظرة سريعة على الشهادة:

• موقع الشهادة ضمن مسار AWS: تشمل الشهادات مستوى Foundational، مثل Cloud Practitioner وAI Practitioner، ومستوى Associate، مثل Solutions Architect وDeveloper وMachine Learning وData Engineer وCloudOps Engineer، ثم مستوى Professional، مثل Solutions Architect وDevOps Engineer، بالإضافة إلى شهادات Specialty مثل Security وAdvanced Networking. تركّز هذه المقالة على Developer Associate.
• صيغة DVA-C02: مدة الامتحان 130 دقيقة، ويضم 65 سؤالًا من نوع الاختيار من متعدد أو اختيار أكثر من إجابة، وفق صفحة الشهادة الحالية الخاصة بـ DVA-C02.
• التداخل مع DevOps: تقدير المتحدث أن هناك تداخلًا يقارب 40% بين موضوعات Developer Associate وDevOps Engineer. هذا تقدير شخصي تقريبي، وليس رقمًا رسميًا من AWS. لكنه يوضح أن الاستعداد لأحد المسارين قد يساعد في الآخر.
• مجالات DVA-C02 وأوزانها: Development with AWS Services (32%)، وSecurity (26%)، وDeployment (24%)، وTroubleshooting and Optimization (18%).
• ما الذي يتغير في DVA-C03؟ وفق إعلان AWS، يتضمن التحديث أدوات التطوير بمساعدة الذكاء الاصطناعي عبر المجالات الأربعة، ومهمة جديدة مرتبطة بأمن الذكاء الاصطناعي، وبناء صور الحاويات ونشرها باستخدام ECR وECS وEKS وFargate. كما يشير الإعلان إلى خدمات وأدوات جديدة ضمن النطاق، منها Amazon Bedrock وAmazon Bedrock AgentCore وAmazon Q وKiro وAmazon Data Firehose وAWS PrivateLink. تظل المجالات الأربعة موجودة، لكن أوزانها تتغير إلى: Development with AWS Services (30%)، وSecurity (26%)، وTesting and Deployment (22%)، وTroubleshooting and Optimization (22%). يُنصح بمراجعة دليل الامتحان الرسمي عند صدوره للتأكد من التفاصيل والنطاق الكامل.
• وقت إضافي للمتقدمين الذين يؤدون الامتحان باللغة الإنجليزية: تتيح AWS تسهيلًا يُعرف باسم ESL +30 minutes، أي 30 دقيقة إضافية للامتحانات المقدّمة باللغة الإنجليزية، وفق تعليمات تسهيلات الامتحانات من AWS. يجب طلب هذا التسهيل من حساب AWS Certification قبل التسجيل لأول امتحان.

ثالثًا: خدمات AWS للمطورين، مصنّفة حسب الفئة

صُنّفت خدمات AWS للمطورين التي تناولتها الجلسة ضمن ثماني فئات، مع الاهتمام بحالة دورة حياة كل خدمة؛ فالمادة التعليمية المسجّلة قبل عامين قد لا تعكس وضع AWS الحالي.

كيف نقرأ حالات دورة حياة الخدمة؟

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

• Maintenance: قد لا تتمكن من بدء استخدام جديد للخدمة، بينما يستطيع العملاء الحاليون الاستمرار في استخدامها. وتواصل AWS تشغيلها ودعمها من دون إضافة وظائف جديدة.
• Sunset: ينبغي للعملاء الحاليين التخطيط للانتقال إلى البدائل الموصى بها. وغالبًا ما تكون هناك فترة انتقالية قبل أن تتوقف AWS عن تشغيل الخدمة ودعمها.
• Full shutdown: المرحلة النهائية التي تُزال فيها الخدمة بالكامل من محفظة AWS ولا تعود متاحة أو مدعومة.

وهذه أمثلة على حالة بعض أدوات المطورين كما هي منشورة في مراجع AWS حتى أكتوبر 2026. تبقى صفحة AWS للخدمات الموجودة في وضع الصيانة المرجع الذي ينبغي التحقق منه قبل اتخاذ قرار تقني:

وهناك موعد آخر يستحق الانتباه عند بدء مشروع WordPress على Lightsail: اعتبارًا من 19 نوفمبر 2026، لن يعود بالإمكان اختيار مخطط WordPress الأقدم المعبأ بواسطة Bitnami لإنشاء مثيل جديد. تستمر المثيلات الحالية في العمل، ويمكن إنشاء مثيلات جديدة من snapshots موجودة؛ أما البناء الجديد فاستخدم له مخطط WordPress الذي توفره Lightsail مباشرةً.

رابعًا: سلّم المعماريات

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

وإذا كنت تريد استكشاف جانب التطوير بمساعدة الذكاء الاصطناعي، فراجع أيضًا ملخص الجلسة السابقة عن التطوير القائم على المواصفات باستخدام Kiro.

المستوى 1: WordPress ببساطة

Lightsail. يوفّر Lightsail طريقة مبسّطة للتعامل مع البنية الحاسوبية الأساسية. اختر مخطط WordPress أو LAMP، وستحصل على الخادم وPHP وMySQL ضمن إعداد واحد وتسعير واضح نسبيًا.

أما تنفيذ الفكرة نفسها باستخدام EC2 مباشرةً فيعني إنشاء المثيل، وضبط الوصول عبر SSH، وتثبيت مكونات التطبيق، ثم إدارة هذه المكونات بنفسك. يمكن الوصول إلى النتيجة نفسها، لكن مستوى المسؤولية والجهد مختلف.

المستوى 2: WordPress على نطاق أكبر

Route 53 وCloudFront وEC2 وRDS، مع S3 للوسائط عند الحاجة.

عندما تصبح الحاجة إلى تحكم أكبر وحركة مرور أعلى أهم من مجرد تشغيل الموقع، تبدأ المعمارية في الانقسام إلى مكونات: Route 53 لإدارة توجيه النطاق، وCloudFront للتخزين المؤقت عند الحافة، وEC2 لتشغيل WordPress، وRDS لتوفير قاعدة بيانات مُدارة مثل MySQL أو PostgreSQL بصورة منفصلة عن خادم التطبيق.

يساعد توزيع المكونات على منطقتين أو ثلاث من Availability Zones في تحسين القدرة على تحمّل الأعطال، بشرط إعداد مكونات التطبيق وقاعدة البيانات فعلًا للتكرار والتحويل التلقائي عند الفشل. الفكرة ليست حفظ أسماء أربع خدمات، بل فهم كيف تقود المتطلبات إلى اختيارها.

المستوى 3: واجهة أمامية فقط

هناك مساران يستحقان المعرفة:

• المسار المُدار – Amplify Hosting: اربط مستودع Git لمشروع React أو Vue أو Next.js، وسيقوم Amplify بالبناء والنشر وإنشاء معاينات للفروع وتقديم الموقع عبر CDN. إذا كنت تستخدم Vercel أو Netlify، فقد يكون Amplify نقطة بداية مناسبة لتجربة استضافة الواجهة على AWS؛ لكن الخدمات ليست متطابقة في كل التفاصيل.
• المسار الذي تديره بنفسك – S3 وCloudFront: يخزّن S3 ملفات الموقع الثابتة، ويقدمها CloudFront للمستخدمين، ويوفر AWS Certificate Manager (ACM) الشهادة اللازمة لإنهاء اتصال TLS على CloudFront. ويمكن توجيه النطاق إلى التوزيعة باستخدام Route 53.

المستوى 4: واجهة أمامية مع API وهوية للمستخدم

API Gateway وLambda وDynamoDB.

تستقبل API Gateway الطلبات، وتشغّل Lambda منطق المعالجة، وتخزّن DynamoDB البيانات. هذا نمط شائع لبناء تطبيقات Serverless، ويوضح كيف تعمل خدمات AWS للمطورين معًا بدلًا من دراستها منفصلة. تدعم Lambda عدة بيئات تشغيل، منها Node.js لتطبيقات JavaScript وTypeScript وPython وغيرها. ومن المهم فهم حدود الطلبات وسلوك throttling قبل مواجهة مشكلات الأداء في بيئة الإنتاج.

ثم يظهر متطلب جديد: «نحتاج إلى حسابات للمستخدمين». يمكن إضافة Cognito دون إعادة تصميم التطبيق بالكامل. يتولى Cognito تسجيل المستخدمين ودخولهم وإصدار الرموز، ويرسل الواجهة الأمامية الرمز مع الطلبات، وتتحقق API Gateway منه عبر Authorizer، بحيث لا تصل إلى Lambda إلا الطلبات التي اجتازت التحقق المطلوب.

ويمكن لـ Cognito أيضًا التكامل مع مزودي هوية خارجيين مثل Google وFacebook. وبدلًا من كتابة نظام المصادقة من الصفر، يمكن الاستفادة من خدمة مُدارة ومكتبات SDK المناسبة لـ JavaScript وTypeScript.

المستوى 5: Monolith

ALB وEC2 مع Auto Scaling وRDS.

في هذه المعمارية، يوجد تطبيق واحد قابل للنشر، مع Load Balancer يوزّع حركة المرور على خوادم متشابهة وقاعدة بيانات مشتركة. وتظل هذه معمارية صالحة تمامًا؛ فلا يحتاج كل تطبيق إلى Serverless أو Microservices.

تناولنا أيضًا الأنواع الثلاثة من Load Balancers:

• Application Load Balancer: لتوجيه حركة HTTP/HTTPS وفق خصائص الطلب.
• Network Load Balancer: لحالات تتطلب أداءً عاليًا على مستوى TCP/UDP.
• Gateway Load Balancer: لإدخال أجهزة أو خدمات الشبكة الافتراضية في مسار حركة المرور.

المستوى 6: Microservices

ALB ثم ECS أو Fargate.

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

يتولى ECS تشغيل الحاويات، إما على مثيلات تديرها بنفسك أو باستخدام Fargate لتقليل مسؤولية إدارة الخوادم. وإذا كانت Kubernetes جزءًا أساسيًا من بيئة المؤسسة، فإن EKS خيار آخر. وتضيف خطة DVA-C03 المعلنة موضوع بناء صور الحاويات باستخدام ECR ونشرها باستخدام ECS وEKS وFargate إلى نطاق الامتحان.

المستوى 7: Event-driven architecture

هنا يتغير نمط التواصل من الطلب والاستجابة المتزامنين (synchronous request/response) إلى المعالجة غير المتزامنة والمكونات المنفصلة (asynchronous, decoupled processing). ولكل من الخدمات الثلاث التالية دور مختلف:

• SQS: طابور رسائل يخزّن العمل مؤقتًا حتى يتمكن المستهلك من معالجته بالسرعة المناسبة.
• SNS: نمط Pub/Sub يتيح توزيع رسالة واحدة على عدة مشتركين.
• EventBridge: ناقل أحداث يوجّه الأحداث وفق قواعد، بما في ذلك عبر خدمات وحسابات مختلفة.

مثلًا، عندما تنشر خدمة الطلبات حدثًا، يمكن لخدمتي المخزون والشحن التعامل معه بصورة مستقلة، من دون أن تحتاج خدمة الطلبات إلى معرفة تفاصيلهما. ويساعد هذا الفصل على بناء أنظمة أكثر مرونة، مع ضرورة التفكير في أنماط مثل إعادة المحاولة (retries) وقواطع الدائرة (circuit breakers).

المستوى 8: من Commit إلى Production

CodeBuild وCodePipeline وCodeDeploy.

قد يكون مصدر الشيفرة CodeCommit أو GitHub، ويتولى CodeBuild البناء والاختبارات، ويربط CodePipeline المراحل المختلفة، بينما ينفذ CodeDeploy عملية النشر إلى EC2 أو Lambda أو ECS. ويمكن أن تجمع خطوط CI/CD الواقعية بين أدوات AWS وأدوات أخرى مثل GitHub Actions وJenkins؛ فلا يلزم أن تعتمد كل مراحل خط النشر على منتج واحد.

تناولنا أيضًا إضافتين تشغيليتين:

• Feature flags: تتيح AWS AppConfig — أو أداة مفتوحة المصدر مثل Flagsmith، وهي ليست خدمة من AWS — تفعيل ميزات أو تعطيلها دون الحاجة إلى نشر إصدار جديد في كل مرة. ومن الأمثلة تعطيل ميزة محادثة تسبب مشكلة أو طرح الوضع الداكن تدريجيًا.
• المراقبة: يوفر CloudWatch السجلات والمقاييس والتنبيهات، ويساعد X-Ray على تتبع الطلب عبر الخدمات، بينما يمكن استخدام أدوات خارجية أو مفتوحة المصدر مثل GlitchTip لتتبّع الأخطاء. GlitchTip ليست خدمة AWS.

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

موضوع إضافي يستحق المراجعة: سياسات التوجيه في Route 53

ظهرت Route 53 في أكثر من موضع في الجلسة، وتستحق سياسات التوجيه الخاصة بها أن تُعرف بالاسم. تناول العرض خمس سياسات، بينما يشرح المقال السابق عن سياسات التوجيه في Route 53 السياسات السبع بمزيد من التفصيل، بما فيها Failover وGeoproximity.

• Simple: سجل واحد وإجابة واحدة.
• Weighted: توزيع الحركة بين نقاط النهاية باستخدام أوزان نسبية؛ مثل تحويل جزء صغير من الحركة تدريجيًا إلى إصدار جديد. الأوزان قيم نسبية، ولا يلزم أن يكون مجموعها 100.
• Latency-based: توجيه المستخدم إلى المنطقة (Region) التي يُتوقع أن تقدم أقل زمن استجابة له.
• Geolocation: التوجيه استنادًا إلى الموقع الجغرافي للمستخدم.
• Multivalue answer: إرجاع عدة سجلات سليمة في استعلام DNS واحد.

خامسًا: نصائح للاستعداد للامتحان

هذه خلاصة النصائح العملية التي طُرحت خلال الجلسة:

1. فكّر في السيناريو، لا في أسماء الخدمات فقط. ابدأ بسؤال: ما الذي يحتاجه التطبيق؟ وعندها تصبح خريطة خدمات AWS للمطورين مجموعة إجابات عملية لا قائمة أسماء للحفظ. فاختيار الخدمة يأتي استجابةً لمتطلب محدد، وحفظ الأسماء دون فهم أسباب استخدامها لا يكفي.
2. افهم مفردات الاعتمادية. راجع تصميم الأنظمة القادرة على تحمّل الأعطال، ومعالجة الأخطاء في Lambda، وإعادة المحاولة، وCircuit Breakers، والفرق بين التواصل المتزامن والأنماط المعتمدة على الأحداث.
3. راجع سياسات Route 53 وأنواع Load Balancers. فهي موضوعات صغيرة نسبيًا لكنها تظهر في سيناريوهات تصميم المعمارية.
4. ابدأ بالمصادر الرسمية. يوضح دليل الامتحان والأسئلة النموذجية المرتبطة بصفحة AWS Certified Developer – Associate نطاق الموضوعات. بعد ذلك، تدرب على الامتحانات التجريبية.
5. أنشئ الحسابات مبكرًا. أنشئ حسابًا مجانيًا على AWS Skill Builder وحسابًا على منصة التدريب والشهادات من AWS؛ فستحتاج إلى حساب الشهادات لحجز الامتحان وطلب تسهيل ESL.
6. حدّد خطتك الزمنية. إذا كنت مستعدًا، فتحقق من موعد انتهاء DVA-C02 قبل الحجز. أما إذا كنت في بداية الاستعداد، فأنشئ خطة مركزة وفق دليل الامتحان الرسمي بدل محاولة دراسة كل خدمة في AWS.
7. إذا لم تكن الإنجليزية لغتك الأولى، فتحقق من تسهيل ESL +30 minutes. اطلبه قبل التسجيل للامتحان، وفق تعليمات AWS الحالية.

سادسًا: ما التالي؟

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

1. Serverless
2. أدوات المطورين وCI/CD
3. قواعد البيانات
4. الحاويات وMicroservices

سابعًا: الخلاصة

• تمنحك الخريطة المصنّفة لـ خدمات AWS للمطورين صورة أوضح من استعراض الخدمات واحدةً تلو الأخرى، خصوصًا أن حالة دورة حياة الخدمة مهمة بقدر أهمية وظيفتها.
• الخدمات نتيجة للمتطلبات. ابدأ بسؤال «ما الذي يحتاجه التطبيق؟»، ثم اختر الخدمات التي تحقق تلك المتطلبات.
• الانتقال من Monolith إلى Microservices ثم Event-driven architecture ليس مجرد تغيير في عدد الخدمات؛ بل هو أيضًا انتقال في طريقة التفكير من التواصل المتزامن إلى المعالجة غير المتزامنة.
• يتغير امتحان Developer Associate، لذا راجع أحدث المعلومات الرسمية بشأن DVA-C02 وDVA-C03 قبل وضع خطة الدراسة أو حجز الامتحان.

للمزيد من الأمثلة العملية، راجع مقال الواجهة الأمامية والخلفية بدون خادم باستخدام 8 خدمات من AWS على OneKC.pro. ستضاف وصلة النسخة الإنجليزية الأصلية بعد نشرها.

إذا اعجبتكم هذه الكبسولة، اشتركوا في القائمة البريدية لتصلكم المقالات الجديدة.

تابعونا على وسائل التواصل الاجتماعي لمزيد من المحتوى التقني.