AWS Overview

 البنية التحتية العالمية لشركة AWS

1. المناطق الجغرافية (AWS Regions)

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

• المكونات: تضم كل منطقة 3 مناطق توافر (Availability Zones) على الأقل لضمان استمرارية العمل وعزل الأعطال (بعض المناطق الحديثة قد تبدأ بأقل، لكن المعيار القياسي هو 3 فما فوق).

• الاتصال: ترتبط المناطق بشبكة عالمية خاصة بـ AWS ومزودي خدمات الإنترنت (ISPs)، مما يقلل زمن الاستجابة (Latency) مقارنة بالإنترنت العام.

• آلية العمل والتحكم:

  • المناطق التي تم إطلاقها بعد 20 مارس 2019 (مثل البحرين وهونغ كونغ) تكون معطلة افتراضياً ويجب تفعيلها يدوياً.

  • هناك مناطق مخصصة ومقيدة للامتثال الحكومي والتنظيمي مثل (AWS GovCloud US).

  • المناطق معزولة تماماً عن بعضها لحصر الأعطال، ولا يتم نسخ البيانات تلقائياً بين المناطق؛ لذا تقع على عاتق المستخدم مسؤولية اختيار المنطقة وإعداد النسخ الاحتياطي بين المناطق إذا تطلب الأمر.

• معايير اختيار المنطقة المناسبة:

  1. زمن الاستجابة (Latency): اختيار المنطقة الأقرب للمستخدمين لسرعة الوصول.

  2. التكلفة: تختلف أسعار الخدمات من منطقة إلى أخرى.

  3. الامتثال والتشريعات (Compliance): مطابقة القوانين المحلية لتخزين البيانات.

  4. توفر الخدمات: لا تتوفر جميع خدمات AWS في كل المناطق بالتساوي.

2. مناطق التوافر (Availability Zones - AZs)

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

• الخصائص:

  • مصممة لتكون معزولة عن الأعطال (كهرباء، مياه، شبكات) التي قد تصيب المناطق الأخرى.

  • ترتبط مناطق التوافر داخل المنطقة نفسها عبر شبكات خاصة فائقة السرعة ومنخفضة زمن الاستجابة.

  • تنصح AWS دائماً بتوزيع وتشغيل التطبيقات على أكثر من منطقة توافر لضمان المرونة ومقاومة الأعطال.

• ملاحظة هامة للاختبار (SAA Exam Tip): الرموز الحرفية لمناطق التوافر (مثل us-east-1a أو us-east-1b) يتم تعيينها عشوائياً لكل حساب AWS بشكل مختلف؛ أي أن المنطقة us-east-1a في حسابك قد لا تعني نفس مركز البيانات الفيزيائي لنفس الرمز في حساب مستخدم آخر، وذلك لتوزيع الأحمال بشكل عادل.

3. المناطق المحلية (AWS Local Zones)

• التعريف: هي امتداد للبنية التحتية لـ AWS تضع الخدمات (مثل الحوسبة والتخزين وقواعد البيانات) في مواقع قريبة جداً من المناطق السكنية أو المراكز التجارية الكبرى التي لا تتوفر فيها منطقة جغرافية كاملة (Region).

• الهدف: توفير زمن استجابة فائق السرعة (أقل من 10 أجزاء من الثانية) للتطبيقات الحساسة للوقت مثل: الألعاب عبر الإنترنت، صناعة المحتوى الإعلامي، وتطبيقات التعلم الآلي.

• الربط: تتكامل مع خدمات مثل EC2 و VPC و EBS وتتصل بالمنطقة الأم عبر شبكة آمنة وعالية السرعة.

💡 مقارنة هامة للاختبار (الفرق بين امتدادات البنية التحتية):

• Local Zones: لتقليل زمن الاستجابة في المدن الكبرى التي تفتقر لمنطقة كاملة (مثل مدينة لوس أنجلوس).

• Wavelength Zones: لدمج خدمات الحوسبة لـ AWS داخل شبكات الاتصالات 5G لخدمة الهواتف والأجهزة المحمولة.

• AWS Outposts: كابينة أجهزة (Rack) مدارة بالكامل من AWS يتم تركيبها داخل مركز البيانات الخاص بالعميل (On-premises) لتوفير نفس بيئة عمل AWS محلياً.

4. مراكز البيانات (AWS Data Centers)

• هي المنشآت الحقيقية التي تحتوي على الخوادم ووحدات التخزين حيث تُحفظ البيانات وتُعالج.

• لا يمكن للمستخدم اختيار مركز بيانات محدد بعينه، بل تدار بالكامل عبر أنظمة AWS الذكية.

• يتم تصميمها باعتماد نظام التكرار الوظيفي (N+1) لضمان توزيع الأحمال تلقائياً وإعادة توجيه حركة البيانات فوراً في حال حدوث عطل في أي منشأة دون توقف الخدمة.

• تستخدم AWS أجهزة شبكات مخصصة ومصممة داخلياً من عدة مصنعين لتلبية متطلباتها الصارمة.

5. نقاط التواجد والذاكرة المخبئية (Edge Locations & Regional Edge Caches)

• تُعرف بنقاط التواجد لـ AWS (Points of Presence - PoPs).

• تقع هذه النقاط على أطراف الشبكة العالمية لـ AWS، وتعمل كـ "ذاكرة مخبئية" لحفظ البيانات الأكثر طلباً بالقرب من المستخدمين، مما يسهم بشكل كبير في تقليل زمن استجابة الشبكة (Latency) وتسريع وصول المحتوى للعملاء حول العالم.

التوافرية (Availability)

تشير التوافرية العالية (High availability) في AWS إلى قدرة النظام أو التطبيق على البقاء متاحاً وقيد التشغيل بأقل فترة توقف ممكنة (Downtime)، حتى في حالة حدوث أعطال أو اضطرابات. وتحقق AWS التوافرية العالية من خلال عدة آليات:

• مناطق توافر متعددة (Multiple Availability Zones - AZs): تنقسم مناطق AWS الجغرافية إلى مناطق توافر معزولة، وهي عبارة عن مراكز بيانات منفصلة. ومن خلال توزيع الموارد عبر مناطق توافر متعددة، يمكن للتطبيقات الاستمرار في العمل حتى لو تعطلت إحدى هذه المناطق.

• موازنة الأحمال (Load Balancing): تعمل أدوات موازنة الأحمال المرنة من AWS (Elastic Load Balancers) على توزيع حركة المرور عبر الحالات (Instances) السليمة في مناطق توافر متعددة، مما يضمن استمرار التوافر أثناء الأعطال أو الارتفاعات المفاجئة في حركة المرور.

• التحجيم التلقائي (Auto Scaling): تقوم خدمة (AWS Auto Scaling) بضبط عدد الحالات (Instances) تلقائياً بناءً على حجم الطلب، مما يحافظ على الأداء والتوافرية.

• مقاومة الأعطال (Fault Tolerance): تم تصميم خدمات مثل Amazon S3 و RDS و DynamoDB بميزة مقاومة الأعطال المدمجة، مما يضمن توافر البيانات وموثوقيتها.

تساهم هذه الميزات مجتمعة في تقليل فترات التوقف عن العمل وتضمن بقاء النظام متاحاً وسهل الوصول إليه تحت مختلف الظروف.

نقاط التواجد لـ AWS (AWS Edge Locations)

نقاط التواجد (Edge locations) في AWS هي مراكز بيانات موزعة عالمياً تعمل كنقاط نهاية (Endpoints) لخدمات AWS، وتُستخدم بشكل أساسي لتوصيل المحتوى وتخزينه مؤقتاً (Caching). وهي جزء من شبكة توصيل المحتوى (CDN) التابعة لـ AWS والمعروفة باسم Amazon CloudFront، وتم تصميمها لتقليل زمن الاستجابة (Latency) عبر تقريب المحتوى من المستخدمين.

تشمل الأغراض الرئيسية لنقاط التواجد ما يلي:

• توصيل المحتوى (Content Delivery): تقوم نقاط التواجد بتخزين نسخ مؤقتة من المحتوى الثابت والديناميكي (مثل صفحات الويب، ومقاطع الفيديو، والصور) لتقليل أوقات التحميل للمستخدمين.

• تقليل زمن الاستجابة (Reduced Latency): من خلال تقديم المحتوى من أقرب نقطة تواجد للموقع الجغرافي للمستخدم، يتم تقليل الوقت الذي تستغرقه البيانات للانتقال، مما يحسن الأداء.

• الانتشار العالمي (Global Reach): تمتلك AWS العديد من نقاط التواجد حول العالم، مما يتيح للتطبيقات تقديم المحتوى بسرعة للمستخدمين في مناطق مختلفة.

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

تتكون نقاط الحضور (PoPs) من أكثر من 600 نقطة تواجد (Edge location) وأكثر من 13 ذاكرة مخبئية إقليمية متوسطة المستوى (Regional mid-tier caches). وتعد نقاط الحضور (PoPs) هذه هي الوجهة الأولى لطلبات خدمة CloudFront.

💡 نصيحة لاختبار SAA: يتم استخدام نقاط التواجد (Edge locations) بواسطة خدمات: CloudFront، و Route 53، و AWS Global Accelerator. تذكر جيداً أي خدمة تستخدم أي جزء من الشبكة، فهذا الموضوع يتكرر كثيراً في الأسئلة القائمة على السيناريوهات.

الذاكرة المخبئية الإقليمية (Regional edge caches)

تمتلك CloudFront أيضاً ذاكرات مخبئية إقليمية (Regional edge caches) تجلب المزيد من المحتوى الخاص بك ليكون أقرب إلى المشاهدين، حتى عندما لا يكون هذا المحتوى شائعاً أو مطلوباً بدرجة كافية للبقاء في نقاط التواجد (PoPs)، وذلك للمساعدة في تحسين أداء هذا المحتوى.

تُستخدم الذاكرة المخبئية الإقليمية افتراضياً مع CloudFront. ويتم اللجوء إليها عندما يكون لديك محتوى لا يتم الوصول إليه بشكل متكرر ليبقى مخزناً في نقاط التواجد العادية؛ حيث تقوم الذاكرة المخبئية الإقليمية باستيعاب هذا المحتوى وتوفير بديل بدلاً من جلب المحتوى من الخادم الأصلي (Origin server) في كل مرة.

إطار AWS Well-Architected Framework

يُعد إطار AWS Well-Architected Framework دليلاً لتقييم معماريات السحابة بشكل منتظم، كما يقدّم إرشادات لتطبيق التصاميم المناسبة. يوضّح هذا الإطار مجموعة من الأسئلة الأساسية وأفضل الممارسات التي تساعدك على تحديد ما إذا كانت معمارية معيّنة متوافقة مع أفضل ممارسات السحابة. وقد طوّرت AWS هذا الإطار بعد تحليل آلاف معماريات العملاء على منصتها.

يتكوّن إطار AWS Well-Architected Framework من ست ركائز:

1. التميّز التشغيلي
2. الأمان
3. الموثوقية
4. كفاءة الأداء
5. تحسين التكلفة
6. الاستدامة

نصيحة لاختبار SAA:
جميع الركائز الست قد تظهر في اختبار SAA-C03. يركّز الاختبار غالبًا على الأمان، والموثوقية، وتحسين التكلفة، وعادةً تأتي الأسئلة على شكل سيناريوهات تطلب تحديد القرار التصميمي الذي يخالف أو يدعم ركيزة معيّنة.
عندما ترى سيناريو يصف فشلًا أو انقطاعًا، فكّر في الموثوقية.
عندما ترى خدمات غير مستخدمة أو موارد مخصّصة بأكثر من الحاجة، فكّر في تحسين التكلفة.
وعندما ترى بيانات مكشوفة من دون تشفير، فكّر في الأمان.

---

1. التميّز التشغيلي — Operational Excellence

القدرة على:

• تشغيل ومراقبة الأنظمة التي تقدّم قيمة للأعمال.
• التحسين المستمر للعمليات والإجراءات الداعمة.
• استخدام البنية التحتية ككود IaC لتعريف وتحديث جميع أجزاء عبء العمل.

الموضوعات الأساسية:

• إدارة التغييرات وأتمتتها.
• الاستجابة للأحداث.
• الاستجابة للتغيير.

تركّز ركيزة التميّز التشغيلي على القدرة على تشغيل الأنظمة بكفاءة والحصول على رؤى واضحة حول عملياتها من أجل تقديم قيمة للأعمال. كما تؤكد على التحسين المستمر للعمليات والإجراءات الداعمة.

عند تصميم عبء عمل من منظور تشغيلي، من المهم التفكير في كيفية نشره وتحديثه وإدارته. طبّق ممارسات هندسية تركّز على تقليل العيوب وتمكين الإصلاحات السريعة والآمنة. احرص على قابلية الملاحظة Observability من خلال تضمين التسجيلات Logging، وأدوات القياس Instrumentation، والمقاييس التجارية والتقنية، حتى تتمكّن من فهم ما يحدث داخل المعمارية.

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

نصيحة لاختبار SAA:
خدمات التميّز التشغيلي التي يجب معرفتها:

• CloudWatch: للمراقبة والتنبيهات.
• CloudFormation / CDK: للبنية التحتية ككود IaC.
• AWS Systems Manager: للـ runbooks الآلية وإدارة التصحيحات.
• AWS X-Ray: للتتبّع الموزّع Distributed Tracing.

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

---

2. الأمان — Security

القدرة على:

• تطبيق أساس قوي للهوية.
• الحفاظ على إمكانية التتبّع.
• تطبيق الأمان على جميع الطبقات.
• تنفيذ استراتيجيات تقييم المخاطر والتخفيف منها.

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

لإنشاء وضع أمني قوي لمعمارية النظام، من الضروري تطبيق أساس قوي للهوية، وضمان إمكانية التتبّع، وتطبيق إجراءات الأمان عبر جميع الطبقات، وأتمتة أفضل الممارسات الأمنية، وحماية البيانات أثناء انتقالها In Transit وأثناء تخزينها At Rest. يساعد الالتزام بهذه المبادئ الأمنية على الاستعداد الفعّال للأحداث الأمنية المحتملة.

نصيحة لاختبار SAA:
خدمات الأمان التي يجب معرفتها للاختبار:

• IAM: مبدأ أقل صلاحية، الأدوار، السياسات.
• AWS KMS: إدارة مفاتيح التشفير.
• CloudTrail: تسجيل التدقيق، وهو المفتاح لفكرة “الحفاظ على إمكانية التتبّع”.
• GuardDuty: الكشف الذكي عن التهديدات.
• Security Hub: تجميع النتائج الأمنية.
• AWS WAF: جدار حماية تطبيقات الويب.

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

---

3. الموثوقية — Reliability

قدرة النظام على:

• التعافي من فشل البنية التحتية أو الخدمات.
• الحصول ديناميكيًا على موارد حوسبة لتلبية الطلب.
• تقليل الاضطرابات أو التخفيف من أثرها.

تركّز ركيزة الموثوقية على قدرة النظام على التعافي من اضطرابات البنية التحتية أو الخدمات، والتوسّع الديناميكي في موارد الحوسبة لتلبية الطلب. كما تغطي قدرة النظام على تقليل أثر الاضطرابات مثل أخطاء الإعدادات أو مشكلات الشبكة المؤقتة.

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

نصيحة لاختبار SAA:
الموثوقية تعني غالبًا معمارية Multi-AZ.

الخدمات الأساسية:

• RDS Multi-AZ: تجاوز فشل تلقائي لقواعد البيانات.
• Elastic Load Balancer: توزيع حركة المرور على المثيلات السليمة.
• Auto Scaling Groups: استبدال المثيلات غير السليمة.
• Route 53 Health Checks: تجاوز الفشل على مستوى DNS.
• S3: متانة تصل إلى 11 تسعة من خلال التخزين المتكرر.

إذا سأل السيناريو عن “النجاة من فشل مركز بيانات” أو “التعافي التلقائي”، فغالبًا تتضمن الإجابة ELB + ASG + نشر Multi-AZ.

---

4. كفاءة الأداء — Performance Efficiency

القدرة على:

• اختيار الموارد الفعّالة والحفاظ عليها.
• إتاحة التقنيات المتقدمة للجميع.
• استخدام مبدأ الفهم العميق لطريقة عمل النظام Mechanical Sympathy.
• الحفاظ على الكفاءة مع تغيّر الطلب وتطوّر التقنيات.

عند التركيز على الأداء، يكون الهدف هو تعظيم كفاءة استخدام موارد الحوسبة مع الحفاظ على هذه الكفاءة عندما يتغير الطلب.

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

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

نصيحة لاختبار SAA:
كفاءة الأداء تعني اختيار المورد المناسب، وليس الأقوى دائمًا.

نقاط القرار الأساسية:

• عائلات مثيلات EC2:
  • عائلة C المحسّنة للحوسبة.
  • عائلة R المحسّنة للذاكرة.
  • عائلة I المحسّنة للتخزين.
• ElastiCache لتخفيف قراءات قاعدة البيانات المتكررة.
• CloudFront لتقديم المحتوى بزمن استجابة منخفض.
• RDS Read Replicas لتوسيع أحمال العمل كثيفة القراءة.

إذا قال السيناريو إن الأداء يتدهور تحت ضغط عمليات القراءة، فكّر في Read Replicas أو التخزين المؤقت Caching، وليس في استخدام مثيلات أكبر مباشرةً.

---

5. تحسين التكلفة — Cost Optimization

القدرة على:

• قياس الكفاءة.
• اعتماد نموذج الاستهلاك المناسب.
• إزالة التكاليف غير الضرورية.
• التفكير في استخدام الخدمات المُدارة.

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

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

نصيحة لاختبار SAA:
يجب معرفة نماذج تسعير EC2 جيدًا، لأنها من أكثر الموضوعات تكرارًا في الاختبار:

• On-Demand:
  لا يتطلب التزامًا، لكنه بالسعر الكامل. مناسب للأحمال القصيرة أو غير المتوقعة.
• Reserved Instances / Savings Plans:
  التزام لمدة سنة أو ثلاث سنوات، مع توفير قد يصل إلى 72%. مناسب للأحمال المستقرة ذات الاستخدام الأساسي المستمر.
• Spot Instances:
  توفير قد يصل إلى 90%، لكنها قد تتوقف أو تُسترد من AWS. مناسبة لأحمال العمل المتحمّلة للأعطال، مثل المعالجة الدفعية أو التطبيقات عديمة الحالة Stateless.

نمط خاطئ شائع: استخدام On-Demand لقاعدة بيانات إنتاج تعمل 24/7 بدلًا من استخدام Reserved Instances.

يجب أيضًا معرفة:

• AWS Cost Explorer: عرض وتحليل الإنفاق.
• AWS Budgets: إعداد التنبيهات على الميزانية.
• Compute Optimizer: توصيات لتحسين حجم الموارد Right-Sizing.

---

6. الاستدامة — Sustainability

على ماذا تركّز الاستدامة؟

• تحديد أهداف الاستدامة.
• اختيار عتاد وبرمجيات فعّالة.
• تعظيم الاستفادة من الموارد.
• تقليل التأثيرات اللاحقة أو غير المباشرة.

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

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

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

تغطية هذه الركيزة في الاختبار حاليًا أخف من غيرها، لكن توقّع أسئلة سيناريو حول:

• ضبط حجم الموارد بشكل مناسب لتقليل السعة المهدرة.
• تفضيل الخدمات المُدارة أو عديمة الخوادم Serverless، لأن العبء التشغيلي الأقل يعني غالبًا طاقة أقل.
• استخدام مثيلات Graviton / ARM-based instances لأنها تقدّم أداءً أفضل لكل واط.

توفر أداة AWS Customer Carbon Footprint Tool بيانات الانبعاثات لكل حساب.

استخدام أداة AWS WA

أداة AWS Well-Architected Tool، والمعروفة اختصارًا باسم WA Tool، هي أداة ذاتية الخدمة متوفرة داخل AWS Management Console تساعدك على تصميم بُنى سحابية آمنة، عالية الأداء، مرنة، وفعّالة.

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

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

نصيحة لاختبار SAA:
أداة WA Tool مجانية، وذاتية الخدمة، ويتم الوصول إليها من خلال AWS Management Console. تقوم الأداة بإنشاء تقرير يُسمى مراجعة حمل العمل (Workload Review)، يوضح المشكلات عالية الخطورة HRIs والمشكلات متوسطة الخطورة MRIs، مع خطوات المعالجة.

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

أفضل الممارسات لبناء الحلول على AWS

(Best Practices for Building Solutions on AWS)

الموازنات التصميمية (Design trade-offs)

عند تصميم أي حل برمجـي، تعد الموازنات (Trade-offs) أمرًا أساسيًا لتحسين الأداء، والتكلفة، والكفاءة. قد تضحي أحيانًا باتساق البيانات (Consistency) أو ديمومتها (Durability) مقابل كسب السرعة، أو قد تفضل النشر السريع (Faster deployment) على حساب خفض التكاليف.

ومع ذلك، يمكن لهذه الموازنات أن تزيد من التعقيد والنفقات؛ لذا يجب أن تستند القرارات إلى بيانات تجريبية واقعية، مثل اختبارات التحمل (Load testing) والقياس المرجعي (Benchmarking).

من الضروري تقييم مدى تأثير الخيارات التصميمية على كل من العملاء وكفاءة بيئة العمل (Workload). يغطي هذا القسم أفضل ممارسات AWS لتصميم الحلول والأخطاء الشائعة (Anti-patterns) التي يجب تجنبها.

تطبيق القابلية للتوسع (Implementing scalability)

احرص على أن تكون بنيتك التحتية قادرة على التعامل مع التغيرات في حجم الطلب.

تعد القابلية للتوسع (Scalability) أمرًا بالغ الأهمية عند تشغيل بيئات العمل على AWS، مما يضمن تلبية البنية التحتية للطلب بشكل استباقي. يساعد تطبيق التوسع في كل طبقة من طبقات النظام على منع مشكلات السعة قبل أن تصبح حرجة. يمكن لخدمة Amazon CloudWatch مراقبة حمل النظام وتحفيز خدمة Amazon EC2 Auto Scaling، والتي تقوم بإطلاق مثيلات (Instances) جديدة قبل تنفاد السعة بالكامل، مما يحافظ على تجربة مستخدم سلسة.

تضمن المرونة (Elasticity) أيضًا إنهاء المثيلات غير الضرورية عند انخفاض الطلب، مما يقلل التكاليف. ومن دون الأتمتة، يمكن أن يؤدي التوسع اليدوي إلى توقف النظام عن العمل (Downtime)، حيث تستغرق المثيلات الجديدة وقتًا لتبدأ العمل، مما يؤثر سلبًا على المستخدمين.

💡 نصيحة لامتحان SAA: تعرف على الأنواع الثلاثة لسياسات التوسع التلقائي (Auto Scaling policies):

1. Target Tracking (تتبع الهدف): الأبسط، حيث تحافظ على مؤشر معين (مثل تشغيل المعالج بنسبة 60%).

2. Step Scaling (التوسع المتدرج): الاستجابة للعتبات والمؤشرات على خطوات متتالية فإذا ارتفع المعالج ل 70% يضيف خادم واحد اما اذا ارتفع الي 95% فيضيف 4 خوادم دفعه واحدة دون انتظار.

3. Scheduled Scaling (التوسع المجدول): لأنماط حركة المرور المتوقعة مسبقًا. تعتبر سياسة Target Tracking هي الخيار الافتراضي الموصى به.

أتمتة بيئتك (Automating your environment)

قم بأتمتة عمليات توفير الموارد (Provisioning)، إنهائها، وتكوين إعداداتها.

توفر AWS أدوات مراقبة وأتمتة مدمجة لمساعدة البنية التحتية على الاستجابة السريعة للتغيرات. وبدون هذه الأدوات، يجب اكتشاف الأعطال وحلها يدويًا، مما يزيد من وقت التوقف عن العمل. تقوم خدمات Amazon CloudWatch و EC2 Auto Scaling بأتمتة اكتشاف الأعطال، واستبدال الموارد غير السليمة، وإرسال إشعارات عند حدوث تغييرات في الموارد.

على سبيل المثال، إذا تعطل خادم التطبيق، تكتشف خدمة CloudWatch هذا الفشل، وتطلق خادمًا جديدًا، وتهيئ إعداداته، وتخطر المسؤول مع تسجيل التغيير لتتبعه.

استخدام البنية التحتية ككود (Using IaC)

• قم بتوفير بنيتك التحتية للحوسبة باستخدام الكود بدلاً من العمليات اليدوية.

• انشر بيئات متطابقة ومكررة بسرعة عالية.

• قلل أخطاء التكوين الناتجة عن الإعداد اليدوي.

• انشر التغييرات بشكل متسق عبر جميع مجموعات الموارد (Stacks).

تتولى "البنية التحتية ككود" (Infrastructure as Code - IaC) أتمتة نشر البنية التحتية، مما يقلل الجهد اليدوي والأخطاء. وهي تمكنك من النشر السريع لبيئات متطابقة باستخدام القوالب (Templates)، مما يقضي على المهام المتكررة. تقلل IaC من أخطاء التكوين عبر توحيد الإعدادات والسماح بالتراجع السريع (Rollbacks) إلى الإصدارات المستقرة في حال ظهور مشكلات. بالإضافة إلى ذلك، يمكن نشر التغييرات بشكل متسق عبر جميع المجموعات عن طريق تحديث قالب واحد، مما يضمن اتساق عمليات النشر.

خيارات الـ IaC المتاحة على AWS:

• AWS CloudFormation: أداة أصلية من AWS، تستخدم قوالب JSON/YAML، وتدعم StackSets لعمليات النشر متعددة الحسابات والمناطق.

• AWS CDK (Cloud Development Kit): تتيح تعريف البنية التحتية باستخدام لغات برمجة مثل Python أو TypeScript أو Java، ثم تحويلها (Compile) إلى CloudFormation.

• Terraform: أداة IaC متعددة السحاب (Multi-cloud)، وتستخدم على نطاق واسع في بيئات الإنتاج الفعلية.

💡 نصيحة لامتحان SAA: يركز الامتحان بشكل أساسي على CloudFormation. اعلم أن خاصية StackSets تسمح لك بنشر نفس المجموعات (Stack) عبر حسابات ومناطق (Regions) متعددة في عملية واحدة. هذا هو الجواب النموذجي لأي سؤال يتعلق بالحوكمة متعددة الحسابات (Multi-account governance).

التعامل مع الموارد كأشياء يمكن الاستغناء عنها (Treating resources as disposable)

يعني هذا المفهوم إدارة البنية التحتية كبرمجيات وليس كأجهزة مادية (Hardware). بدلاً من الإفراط في توفير موارد مادية مكلفة، يتيح هذا النهج التوسع، والترقية، والإدارة السلسة من خلال استبدال المثيلات (Instances) بسرعة عند الحاجة. وهو ما يعزز المرونة، وكفاءة التكلفة، والاستجابة لمتطلبات السعة المتغيرة.

💡 نصيحة لامتحان SAA: تتطلب الموارد القابلة للاستغناء تصميم تطبيقات "عديمة الحالة" (Stateless application design)، أي يجب ألا تخزن المثيلات أي شيء محليًا لا يمكن إعادة إنشائه. مكان البيانات وحفظ الحالة (State) يكون في الخدمات المدارة:

• جلسات المستخدمين (User sessions) ← تحال إلى ElastiCache (Redis).

• الملفات المرفوعة (Uploaded files) ← تحال إلى S3.

• بيانات التطبيق (Application data) ← تحال إلى RDS أو DynamoDB. إذا كان من الممكن إنهاء مثيل وتشغيل آخر مكانه دون فقدان أي بيانات، فأنت بذلك قد طبقت هذا المفهوم بنجاح. تذكر أن مجموعات التوسع التلقائي (Auto Scaling Groups) لا تعمل بشكل موثوق إلا عندما تكون المثيلات عديمة الحالة (Stateless).

استخدام مكونات ضعيفة الترابط (Using loosely coupled components)

صمم بنية تحتية بمكونات مستقلة عن بعضها البعض.

يعزز الترابط الضعيف (Loose coupling) من موثوقية النظام وقابليته للتوسع باستخدام الحلول المدارة مثل موازنات الحمل (Load balancers) وطوابير الرسائل (Message queues) كوسيط بين طبقات النظام. بخلاف البنى التحتية التقليدية شديدة الترابط (Tightly integrated)، حيث يمكن للفشل في مكون واحد أن يعطل النظام بأكمله، يتيح الترابط الضعيف التوسع المستقل ومعالجة الأعطال تلقائيًا.

على سبيل المثال، تقوم خدمة موازنة الحمل المرنة (Elastic Load Balancing - ELB) بتوزيع حركة المرور بين الخوادم السليمة، مما يضمن استمرار الإتاحة حتى في حال فشل أحد الخوادم.

تصميم الخدمات لا الخوادم (Designing services, not servers)

يعني هذا اختيار الحلول المدارة (Managed) والعديمة الخوادم (Serverless) بدلاً من مثيلات EC2 التقليدية عندما يكون ذلك مناسبًا. في حين توفر EC2 المرونة، فإن خدمات AWS المدارة مثل Lambda، وSQS، وDynamoDB، وELB تقدم إمكانات أفضل للتوسع، والأداء، وكفاءة التكلفة من خلال إلغاء الحاجة إلى إدارة الخوادم. إن اختيار الحل المناسب بناءً على احتياجات العمل يساهم في تبسيط العمليات وتقليل المصاريف الإدارية الزائدة (Overhead).

💡 نصيحة لامتحان SAA: المقارنة الأكثر اختبارًا في قرار "الخدمات لا الخوادم" هي Lambda مقابل EC2.

• فضل Lambda عندما تكون بيئة العمل قائمة على الأحداث (Event-driven)، وقصيرة المدة (أقل من 15 دقيقة)، وحركة المرور فيها غير متوقعة أو متذبذبة الحجم (Spiky).

• فضل EC2 عندما تحتاج إلى عمليات مستمرة (Persistent processes)، أو بيئات تشغيل مخصصة (Custom runtimes)، أو مهام تستغرق وقتًا طويلاً.

• بالنسبة لقواعد البيانات: يفضل RDS على إدارة خادم MySQL بنفسك فوق EC2 (حيث يوفر RDS نسخًا احتياطيًا مؤتمتًا، وتثبيت التحديثات، وخاصية Multi-AZ، ونسخ القراءة المتطابقة جاهزة دون عناء).

اختيار حل قاعدة البيانات المناسب (Choosing the right database solution)

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

• احتياجات القراءة والكتابة (Read and write needs).

• إجمالي متطلبات التخزين (Total storage requirements).

• الحجم النموذجي للكائنات (Objects) وطبيعة الوصول إليها.

• متطلبات ديمومة واستمرار البيانات (Durability requirements).

• متطلبات زمن الاستجابة (Latency requirements).

• الحد الأقصى للمستخدمين المتزامنين المراد دعمهم.

• طبيعة الاستعلامات (Queries).

• القوة المطلوبة لقيود سلامة البيانات (Integrity controls).

💡 نصيحة لامتحان SAA: يعد اختيار قواعد البيانات من أكثر المواضيع تكرارًا في امتحان SAA-C03. دليل القرار السريع:

• RDS / Aurora ← للبيانات 관계ية (Relational / SQL)، مهارة مدارة، نسخ احتياطي مؤتمت، وفشل تلقائي بديل. خدمة Aurora أسرع بمقدار يصل إلى 5 مرات من خادم MySQL القياسي.

• DynamoDB ← قاعدة بيانات (Key-value / Document)، توفر زمن استجابة يقاس بأجزاء من الملي ثانية عند أي نطاق، وهي بدون خوادم بالكامل (Serverless).

• Redshift ← للتحليلات ومستودعات البيانات (بيئات عمل OLAP، وليست OLTP).

• ElastiCache (Redis or Memcached) ← ذاكرة تخزين مؤقت في الذاكرة (In-memory caching) لتخفيف ضغط القراءة عن قواعد البيانات الأساسية.

• Neptune ← قاعدة بيانات رسومية (Graph database) للشبكات الاجتماعية، كشف الاحتيال، ومحركات التوصية.

• DocumentDB ← قاعدة بيانات مستندات متوافقة مع MongoDB.

• خطأ شائع (Anti-pattern): استخدام قاعدة بيانات علاقاتية (Relational) لبيئة عمل لا تحتاج سوى لعمليات بحث بسيطة (Key-value) بمعدل ضخم — هنا ستكون DynamoDB أرخص وأسرع.

تجنب نقاط الفشل الفردية (Avoiding single points of failure)

يضمن القضاء على نقاط الفشل الفردية (Single points of failure) مرونة النظام ومنع توقفه نتيجة لتعطل أحد المكونات. وبدلاً من تكرار كل شيء يدويًا، يمكن للتوسع المؤتمت أو الخدمات المدارة استبدال المكونات الفاشلة عند الحاجة.

على سبيل المثال، إذا تعطل خادم قاعدة بيانات واحد، فستفشل خوادم التطبيقات المتصلة به أيضًا. الحل هو نسخ البيانات إلى قاعدة بيانات احتياطية جاهزة (Standby database)، مما يتيح الانتقال السلس عند الفشل (Seamless failover). يتوافق هذا مع مبدأ الموارد القابلة للاستغناء، مما يسمح للتطبيقات بالتكيف مع التغيرات في الأجهزة المادية.

💡 نصيحة لامتحان SAA: تعرف على مستويات المرونة الثلاثة ضد الأعطال التي يختبرها الامتحان:

1. Multi-AZ (مناطق توفر متعددة): إتاحة عالية (High availability) داخل منطقة جغرافية واحدة؛ وفشل تلقائي بديل (Automatic failover). تستخدم لقواعد بيانات الإنتاج (RDS Multi-AZ)، ودمج خوادم موازنة الحمل (ELB) مع مجموعات التوسع (ASG) الممتدة عبر منطقتي توفر أو أكثر.

2. Read Replicas (نسخ القراءة المتطابقة): لتوسيع نطاق الأداء في بيئات العمل كثيفة القراءة؛ وهي ليست آلية للفشل التلقائي البديل (تتطلب ترقية يدويًا لتصبح قاعدة البيانات الأساسية).

3. Multi-Region (مناطق جغرافية متعددة): للتعافي من الكوارث (Disaster recovery) عبر مناطق جغرافية متباعدة؛ تكلفة وتعقيد أعلى. تستخدم عندما تكون متطلبات RPO/RTO صارمة جدًا أو عندما تتطلب الامتثال القانوني فصلاً جغرافيًا. خطأ شائع (Anti-pattern): تشغيل مثيل RDS واحد بدون خاصية Multi-AZ في بيئة إنتاج فعلية.

تحسين التكلفة (Optimizing for cost)

استفد من مرونة AWS لزيادة كفاءة التكلفة لديك. اسأل نفسك دائمًا:

• هل مواردي بالحجم والنوع المناسبين للمهمة؟ (Right-sizing)

• ما هي المؤشرات التي يجب علي مراقبتها؟

• كيف يمكنني إيقاف تشغيل الموارد غير المستخدمة؟

• كم مرة سأحتاج إلى استخدام هذا المورد؟

• هل يمكنني استبدال أي من خوادمي بخدمات مدارة؟

💡 نصيحة لامتحان SAA: أدوات تحسين التكلفة، مرتبة من الأكثر إلى الأقل تكرارًا في الامتحان:

• Spot Instances (المثيلات الفورية): توفير يصل إلى 90%؛ تستخدم لبيئات العمل على الدفعات (Batch workloads) عديمة الحالة والتي تتحمل الأخطاء (يمكن لـ AWS استردادها بإشعار مدته دقيقتان).

• Reserved Instances / Savings Plans (المثيلات المحجوزة / خطط التوفير): التزام لمدة سنة أو 3 سنوات؛ وهي الأفضل لبيئات العمل المستقرة والمستمرة (Baseline). خطط التوفير تعد أكثر مرونة (تطبق عبر عائلات المثيلات والمناطق).

• Right-sizing (تحديد الحجم المناسب): تقوم أداة AWS Compute Optimizer بتحليل مؤشرات CloudWatch والتوصية بنوع المثيل الأمثل. كما يقوم Trusted Advisor بالإشارة إلى الموارد غير المستغلة كفاية.

• S3 Intelligent-Tiering: تقوم بنقل الكائنات تلقائيًا بين طبقات التخزين بناءً على أنماط الوصول؛ وهي مثالية عندما لا يمكنك توقع تكرار الوصول للبيانات.

• جدولة الإيقاف والتشغيل: إيقاف بيئات العمل غير الخاصة بالإنتاج (مثل بيئات التطوير والاختبار) وفق جدول زمني باستخدام AWS Instance Scheduler أو Lambda.

استخدام ذاكرة التخزين المؤقت (Using caching)

قلل من عمليات استرداد البيانات المتكررة، مما يحسن الأداء والتكلفة.

يعزز التخزين المؤقت (Caching) الأداء ويقلل من حمل الشبكة عن طريق تخزين البيانات التي يتم الوصول إليها بشكل متكرر مؤقتًا في مكان أقرب إلى المستخدمين. وهذا يقلل من الحاجة إلى جلب البيانات من وحدات التخزين الرئيسية الأبطأ. في AWS، تقوم خدمة Amazon CloudFront بتخزين المحتوى مؤقتًا من Amazon S3، وتحتفظ بنسخ منه في مواقع الأطراف (Edge locations). يسترد الطلب الأول البيانات من S3، ولكن الطلبات اللاحقة تخدم مباشرة من CloudFront، مما يقلل زمن الاستجابة وتكاليف نقل البيانات.

💡 نصيحة لامتحان SAA: تعرف على طبقات التخزين المؤقت لديك:

• CloudFront: للمحتوى الثابت والديناميكي عند أطراف الشبكة (Edge).

• ElastiCache (Redis): لبيانات الجلسات ونتائج استعلامات قاعدة البيانات.

• DAX (DynamoDB Accelerator): لتسريع عمليات القراءة من DynamoDB. إذا ذكر السؤال تقليل الحمل على قاعدة البيانات أو تقليل زمن استجابة القراءة، فإن التخزين المؤقت (Caching) هو الإجابة.

تأمين بنيتك التحتية بالكامل (Securing your entire infrastructure)

اجعل الأمن مدمجًا في كل طبقة من طبقات بنيتك التحتية.

• استخدم الخدمات المدارة.

• سجل عمليات الوصول إلى الموارد (Log access).

• عزل أجزاء من بنيتك التحتية.

• شفر البيانات أثناء النقل (In transit) وفي حالة السكون (At rest).

• طبق التحكم في الوصول بشكل دقيق، باستخدام مبدأ الامتيازات الأقل (Principle of least privilege).

• استخدم المصادقة متعددة العوامل (MFA).

• أتمت عمليات النشر الخاصة بك للحفاظ على اتساق المعايير الأمنية.

يتجاوز الأمن مجرد حماية المحيط الخارجي؛ بل يشمل أيضًا تأمين البيئات والمكونات الفردية. تتحكم مجموعات أمن Amazon EC2 (Security Groups) في حركة المرور الواردة والصادرة عبر تحديد المنافذ والمصادر المسموح بها. يساعد هذا في عزل المثيلات، مما يقلل من خطر انتشار التهديدات الأمنية. يجب تطبيق تدابير أمنية مماثلة عبر جميع خدمات AWS.

💡 نصيحة لامتحان SAA: تعرف على الفرق بين مجموعات الأمن Security Groups (مراعية للحالة Stateful، تعمل على مستوى المثيل، وقواعد سماح فقط Allow rules) وجداول التحكم في الوصول للشبكة NACLs (غير مراعية للحالة Stateless، تعمل على مستوى الشبكة الفرعية Subnet، وتحتوي قواعد سماح ومنع Allow and Deny rules). مجموعات الأمن هي الإجابة الأكثر شيوعًا في الامتحان للتحكم في الوصول على مستوى المثيل.

ملخص (Summary)

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

• طبق القابلية للتوسع.

• أتمت بيئتك.

• تعامل مع الموارد كأشياء يمكن الاستغناء عنها.

• استخدم مكونات ضعيفة الترابط.

• صمم الخدمات لا الخوادم.

• اختر حل قاعدة البيانات المناسب.

• تجنب نقاط الفشل الفردية.

• حسن التكلفة وحجم الموارد.

• استخدم ذاكرة التخزين المؤقت.

• أمن بنيتك التحتية بالكامل.