AWS SAA 02 - Introducing Cloud Architecting

🎯 Introducing Cloud Architecting — مقدمة في هندسة السحابة

تأخذك هذه الوحدة في رحلة لفهم أساسيات هندسة الحوسبة السحابية باستخدام Amazon Web Services (AWS). ستتعلم كيف تصمم وتقيّم البنى المعمارية السحابية باستخدام AWS Well-Architected Framework، وتكتشف أفضل الممارسات لبناء حلول على AWS، وتفهم كيفية اتخاذ قرارات مدروسة حول مكان نشر الموارد باستخدام البنية التحتية العالمية لـ AWS.

1️⃣ Cloud Computing and AWS — الحوسبة السحابية و AWS

📖 كيف بدأت قصة AWS؟
حوالي عام 2000، واجهت Amazon تحدياً كبيراً في بناء خدمة تجارة إلكترونية تتيح للبائعين الخارجيين إنشاء متاجرهم الخاصة على منصة أمازون. كانت التطبيقات تُبنى دون تخطيط سليم، وكانت الخدمات متداخلة بشدة ويصعب فصلها، مما جعل التطوير بطيئاً ومعقداً. الحل كان إنشاء مجموعة من واجهات البرمجة (APIs) الموثقة جيداً لتنظيم بيئة التطوير، لكن المشاريع استغرقت شهوراً حتى مع هذا التحسين. في عام 2006، بدأت Amazon ببيع هذه الخدمات داخلياً كخدمات سحابية تحت اسم Amazon Web Services (AWS) بدءاً من Amazon SQS ثم Amazon S3 وAmazon EC2.

📋 التحديات التي واجهتها أمازون:

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

على سبيل المثال شركة ناشئة تريد إطلاق منصة للتجارة الإلكترونية.
بدلاً من بناء كل شيء من الصفر كفعلت أمازون عام 2000 تستخدم الشركة خدمات AWS الجاهزة.
تستضيف موقعها على Amazon S3 وتستخدم Amazon EC2 للخوادم وAmazon RDS لقاعدة البيانات.
ما كان يستغرق شهوراً أصبح ممكناً في أيام بل وساعات.

2️⃣ Cloud Architecture — معمارية السحابة

📖 ما هي معمارية السحابة (Cloud Architecture)؟
هي ممارسة تطبيق خصائص الحوسبة السحابية على حل يستخدم الخدمات والميزات السحابية لتلبية الاحتياجات التقنية وحالات الاستخدام التجارية للمؤسسة. إنشاء حلول تقنية يشبه بناء مبنى فعلي — إذا كان الأساس غير متين فسيسبب مشاكل هيكلية تقوض سلامة المبنى ووظيفته. في هندسة السحابة، يحدد صاحب القرار أهداف العمل والمتطلبات، ثم يصمم مهندس السحابة حلاً يشبه المخطط المعماري للمبنى، ليقوم فريق التسليم بتنفيذ الحل.

مثل بناء منزل — العميل يحدد احتياجاته، المهندس المعماري يرسم المخططات، ثم فريق البناء يحول المخططات إلى مبنى فعلي.
هكذا تعمل معمارية السحابة: صاحب القرار يحدد أهداف العمل، مهندس السحابة يصمم الحل، وفريق التسليم ينفذه.
وجود أنظمة مصممة بشكل متقن (well-architected) يزيد من احتمالية تحقيق مخرجات التقنية لأهداف العمل.

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

3️⃣ Role of a Cloud Architect — دور مهندس السحابة

📖 ما هي مهام مهندس السحابة (Cloud Architect)؟
مهندس السحابة مسؤول عن إدارة بنية الحوسبة السحابية للمؤسسة. يتفاعل مع صانعي القرار لتحديد أهداف العمل والقدرات التي تحتاج تحسيناً، ويضمن التوافق بين مخرجات التقنية وأهداف العمل. يعمل مع فرق التسليم المنفذة للحل لضمان ملاءمة الميزات التقنية، ويمتلك معرفة متعمقة بالمبادئ المعمارية والخدمات المستخدمة.

📋 المسؤوليات الرئيسية:

• التخطيط: وضع استراتيجية تقنية سحابية مع قادة الأعمال وتحليل الحلول لاحتياجات العمل.
• البحث: التحقق من مواصفات الخدمات السحابية ومتطلبات العمل ومراجعة البنى الحالية وتصميم نماذج أولية.
• البناء: تصميم خارطة طريق للتحول مع معالم ومسؤولين وإدارة عملية التبني والترحيل.
• تقديم إرشادات حول معالجة القضايا عالية المخاطر.
• تطبيق AWS Well-Architected Framework في عمله.

على سبيل المثال مهندس سحابة في شركة تأمين كبيرة يلاحظ أن تطبيق المطالبات يعاني من بطء شديد في أوقات الذروة.
يحلل الاحتياجات ويقرر استخدام Amazon EC2 Auto Scaling للتوسع التلقائي وAmazon CloudFront للتخزين المؤقت.
بعد التنفيذ تنخفض مدة معالجة المطالبة من 5 دقائق إلى 30 ثانية وتنخفض التكلفة بنسبة 40%.

✅ خلاصة: هندسة السحابة

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

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Cloud Architecture	معمارية السحابة	ممارسة تطبيق خصائص الحوسبة السحابية على حل يستخدم الخدمات السحابية لتحقيق أهداف العمل.
Cloud Architect	مهندس السحابة	مسؤول عن إدارة بنية الحوسبة السحابية ومواءمة مخرجات التقنية مع أهداف العمل.
Amazon EC2	حوسبة سحابية مرنة	خدمة حوسبة توفر سعات حاسوبية قابلة للتوسع في السحابة.
Amazon S3	خدمة تخزين بسيطة	خدمة تخزين كائني توفر قابلية توسع لا محدودة وأماناً عالياً.
Amazon SQS	خدمة قوائم الرسائل	خدمة قوائم رسائل مدارة بالكامل تتيح فصل المكونات وفك الارتباط.
API	واجهة برمجة التطبيقات	مجموعة تعريفات تسمح للبرامج بالتواصل والتفاعل مع بعضها البعض.
Well-Architected	مصمم بشكل متقن	نظام يتبع أفضل الممارسات المعمارية لتحقيق الأمان والأداء والموثوقية.
Scalability	قابلية التوسع	قدرة النظام على التعامل مع زيادة الطلب بإضافة الموارد بشكل تلقائي.

1️⃣ Pillars of the AWS Well-Architected Framework — ركائز إطار العمل

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

الركائز الست:

• Operational Excellence — التميز التشغيلي
• Security — الأمان
• Reliability — الموثوقية
• Performance Efficiency — كفاءة الأداء
• Cost Optimization — تحسين التكلفة
• Sustainability — الاستدامة

2️⃣ Operational Excellence Pillar — ركيزة التميز التشغيلي

📖 ما هي ركيزة التميز التشغيلي (Operational Excellence)؟
تعالج هذه الركيزة القدرة على تشغيل الأنظمة واكتساب رؤى حول عملياتها لتقديم قيمة تجارية، بالإضافة إلى القدرة على تحسين العمليات والإجراءات الداعمة باستمرار. عند تصميم حمل عمل للتشغيل، يجب أن تكون على دراية بكيفية نشره وتحديثه وتشغيله. قم بتنفيذ ممارسات هندسية تتماشى مع تقليل العيوب والإصلاحات السريعة والآمنة. في AWS، يمكنك عرض حملك بالكامل (التطبيقات والبنية التحتية والسياسات والحوكمة والعمليات) ككود برمجي، مما يتيح تطبيق نفس الانضباط الهندسي على كل عنصر من عناصر بنيتك.

المبادئ الأساسية:

• تشغيل ومراقبة الأنظمة التي تقدم قيمة تجارية.
• تحسين العمليات والإجراءات الداعمة باستمرار.
• عرض حمل العمل بالكامل ككود برمجي (Infrastructure as Code).
• جعل المراقبة ممكنة عبر التسجيل والقياسات الفنية والتجارية.

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

3️⃣ Security Pillar — ركيزة الأمان

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

مبادئ التصميم السبعة:

• تنفيذ أساس هوية قوي (strong identity foundation) بمبدأ الامتياز الأقل.
• الحفاظ على قابلية التتبع (traceability).
• تطبيق الأمان على جميع الطبقات (security at all layers).
• أتمتة أفضل ممارسات الأمان.
• حماية البيانات أثناء النقل والتخزين (data in transit and at rest).
• إبعاد الأشخاص عن البيانات (keep people away from data).
• الاستعداد للأحداث الأمنية (prepare for security events).

🔑 نصيحة أساسية: أساس الهوية القوي يعني البدء بأقل الصلاحيات الممكنة (principle of least privilege) وإضافة المزيد عند الحاجة فقط، وليس العكس.

4️⃣ Reliability Pillar — ركيزة الموثوقية

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

على سبيل المثال تطبيق تجارة إلكترونية يستضيف قاعدة بيانات على خادم واحد فقط.
عندما يتعطل هذا الخادم يتوقف التطبيق بالكامل عن العمل.
الحل هو نشر قاعدة البيانات عبر منطقتي توفر (Availability Zones) مختلفتين مع نسخ احتياطي تلقائي.
عند انقطاع إحدى المنطقتين، تنتقل الحركة تلقائياً إلى المنطقة الأخرى دون توقف.

5️⃣ Performance Efficiency Pillar — ركيزة كفاءة الأداء

📖 ما هي ركيزة كفاءة الأداء (Performance Efficiency)؟
تركز على تعظيم الأداء باستخدام موارد الحوسبة بكفاءة والحفاظ على هذه الكفاءة مع تغير الطلب. من المهم إضفاء الطابع الديمقراطي على التقنيات المتقدمة — في الحالات التي يصعب فيها تنفيذ التكنولوجيا بنفسك، فكر في استخدام مورد خارجي (vendor) ليتولى التعقيد. يشير مصطلح Mechanical Sympathy إلى استخدام أداة أو نظام مع فهم لكيفية عمله بأفضل شكل — استخدم نهج التقنية الذي يتوافق بشكل أفضل مع ما تحاول تحقيقه.

6️⃣ Cost Optimization Pillar — ركيزة تحسين التكلفة

📖 ما هي ركيزة تحسين التكلفة (Cost Optimization)؟
تحسين التكلفة هو متطلب مستمر لأي تصميم معماري جيد. العملية تكرارية ويجب تحسينها طوال فترة الإنتاج. افهم كفاءة بنيتك الحالية بالنسبة لأهدافك لإزالة النفقات غير الضرورية، واعتمد نموذج الاستهلاك المناسب لحالة الاستخدام الخاصة بك حيث تدفع فقط مقابل الموارد التي تستخدمها. فكر في استخدام الخدمات المُدارة (managed services) لأنها تعمل على نطاق سحابي ويمكن أن تقدم تكلفة أقل لكل معاملة أو خدمة.

مثل شركة تشتري سيارة توصيل للبضائع — سواء استخدمت السيارة كل يوم أم بقيت متوقفة في المرآب فإنها تدفع ثمنها كاملاً.
مع AWS يمكنك استئجار السيارة فقط عندما تحتاجها وتدفع مقابل المسافة فقط.
هذا هو الفرق بين النموذج الثابت (fixed expense) والنموذج المتغير (variable expense).

7️⃣ Sustainability Pillar — ركيزة الاستدامة

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

من أهم ممارسات الاستدامة:

• وضع أهداف استدامة (sustainability goals) قابلة للقياس.
• تعظيم الاستفادة من الموارد (maximize utilization).
• اختيار أجهزة وبرامج فعالة (efficient hardware and software).
• تقليل الأثر النهائي (reduce downstream impact) على البيئة والمجتمع.

8️⃣ Using the AWS WA Tool — استخدام أداة AWS للهندسة المتقنة

📖 ما هي أداة AWS Well-Architected Tool؟
هي أداة خدمة ذاتية توفر وصولاً عند الطلب إلى أفضل ممارسات AWS الحالية للمساعدة في بناء بنية تحتية آمنة وعالية الأداء ومرنة وفعالة على AWS. تساعدك الأداة على مراجعة حالة أحمال عملك ومقارنتها بأحدث أفضل الممارسات المعمارية لـ AWS، وهي متاحة في AWS Management Console. تعرّف حمل عملك وتجيب على سلسلة من الأسئلة في مجالات التميز التشغيلي والأمان والموثوقية وكفاءة الأداء وتحسين التكلفة، ثم تقدم الأداة خطة عمل مع إرشادات خطوة بخطوة لتحسين حملك.

🔑 نصيحة أساسية: توفر أداة AWS WA Tool عملية متسقة لمراجعة وقياس بنياتك السحابية. يمكنك استخدام النتائج لتحديد الخطوات التالية للتحسين ودفع القرارات المعمارية وإدخال الاعتبارات المعمارية في عملية حوكمة مؤسستك.

على سبيل المثال شركة لديها تطبيق قديم على خوادم داخلية وتريد الانتقال إلى السحابة.
يستخدم مهندس السحابة أداة AWS WA Tool لتقييم البنية الحالية.
يكتشف أن التطبيق يفتقر إلى التكرار عبر مناطق التوفر وليس لديه خطة تعافي من الكوارث.
تقدم الأداة خطة عمل محددة لتحسين الموثوقية وتقليل مخاطر التوقف.

✅ خلاصة: AWS Well-Architected Framework

• يوفر إطار AWS Well-Architected نهجاً ثابتاً لتقييم البنى المعمارية السحابية.
• يتكون من ست ركائز: التميز التشغيلي، الأمان، الموثوقية، كفاءة الأداء، تحسين التكلفة، والاستدامة.
• ركيزة التميز التشغيلي: تشغيل الأنظمة ومراقبتها وتحسين العمليات باستمرار مع اعتبار البنية التحتية كوداً.
• ركيزة الأمان: حماية المعلومات والأنظمة من خلال أساس هوية قوي وتطبيق الأمان على جميع الطبقات.
• ركيزة الموثوقية: التعافي من الانقطاعات وتلبية الطلب ديناميكياً وتخفيف الاضطرابات.
• ركيزة كفاءة الأداء: استخدام الموارد بكفاءة وإضفاء الطابع الديمقراطي على التقنيات المتقدمة.
• ركيزة تحسين التكلفة: اعتماد نموذج الدفع حسب الاستخدام واستخدام الخدمات المُدارة.
• ركيزة الاستدامة: بناء بنى فعالة تقلل الهدر والطاقة عبر جميع مكونات حمل العمل.
• أداة AWS WA Tool تساعدك على مراجعة أحمال العمل وتقدم خطة عمل للتحسين.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
AWS Well-Architected Framework	إطار AWS للهندسة المتقنة	دليل لتقييم البنى المعمارية السحابية وتقديم إرشادات لأفضل الممارسات.
Operational Excellence	التميز التشغيلي	ركيزة تركز على تشغيل الأنظمة وتحسين العمليات باستمرار.
Security Pillar	ركيزة الأمان	ركيزة تركز على حماية المعلومات والأنظمة عبر أساس هوية قوي وتشفير.
Reliability	الموثوقية	ركيزة تركز على التعافي من الانقطاعات وتلبية الطلب ديناميكياً.
Performance Efficiency	كفاءة الأداء	ركيزة تركز على تعظيم الأداء باستخدام الموارد بكفاءة.
Cost Optimization	تحسين التكلفة	ركيزة تركز على إزالة النفقات غير الضرورية واعتماد نموذج الدفع حسب الاستخدام.
Sustainability	الاستدامة	ركيزة تركز على بناء بنى فعالة تقلل الهدر والأثر البيئي.
AWS WA Tool	أداة الهندسة المتقنة	أداة خدمة ذاتية لتقييم البنى ومقارنتها بأفضل ممارسات AWS.

1️⃣ Design Trade-offs — المفاضلات في التصميم

📖 لماذا تعتبر المفاضلات (Trade-offs) مهمة في التصميم؟
عند تصميم حل، فكر بعناية في المفاضلات لاختيار النهج الأمثل. قد تضحي بالاتساق والمتانة والمساحة مقابل الوقت وزمن الوصول (latency) لتحقيق أداء أعلى، أو قد تفضل سرعة الوصول إلى السوق على التكلفة للميزات الجديدة. يجب أن تستند قرارات التصميم إلى بيانات تجريبية (empirical data)، مثل إجراء اختبارات الحمل لضمان الحصول على فائدة قابلة للقياس في الأداء، أو إجراء اختبارات قياس الأداء (benchmarking) لتحقيق أفضل تكلفة عبر الزمن.

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

2️⃣ Implementing Scalability — تنفيذ قابلية التوسع

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

🔑 نصيحة أساسية: التوسع اليدوي التفاعلي يؤدي إلى توقف التطبيق عن العمل — عندما تصل الخوادم إلى طاقتها الكاملة يُمنع المستخدمون من الوصول إلى التطبيق ويضطر المسؤولون إلى تشغيل خوادم جديدة يدوياً مع تأخير دقائق حتى تصبح جاهزة.

3️⃣ Automating Your Environment — أتمتة بيئتك

📖 لماذا الأتمتة (Automation) ضرورية؟
تقدم AWS أدوات مدمجة للمراقبة والأتمتة في كل طبقة من بنيتك التحتية تقريباً. استفد من هذه الأدوات لضمان استجابة بنيتك التحتية بسرعة للتغييرات. بدون هذه الأدوات، يجب عليك اكتشاف الأعطال يدوياً وإخطار المسؤول الذي يقوم بدوره بتشغيل خادم جديد وتكوينه يدوياً — وهي عملية بطيئة وعرضة للأخطاء.

على سبيل المثال يتعطل خادم تطبيق في منتصف الليل.
Amazon CloudWatch يكتشف العطل تلقائياً ويطلق خادماً بديلاً عبر Auto Scaling.
يُعلم المسؤول عبر إشعار ويُسجل التغيير في نظام إدارة التغيير.
كل هذا يحدث في دقائق دون أي تدخل يدوي ويظل التطبيق متاحاً للمستخدمين.

4️⃣ Using IaC — استخدام البنية التحتية ككود

📖 ما هي البنية التحتية ككود (Infrastructure as Code - IaC)؟
هي أتمتة البنية التحتية لإنشاء البيئات باستخدام كود برمجي بدلاً من العمليات اليدوية. تُمكّنك من نشر بيئات متطابقة بسرعة باستخدام قالب واحد، وتقلل أخطاء التكوين الناتجة عن التدخل البشري، وتنشر التغييرات بشكل متسق على جميع البيئات. إذا حدث خطأ بسبب تحديث الكود، يمكنك العودة بسرعة إلى آخر تكوين مستقر معروف.

فوائد IaC:

• نشر بيئات متطابقة بسرعة (rapidly deploy duplicate environments).
• تقليل أخطاء التكوين الناتجة عن التهيئة اليدوية.
• نشر التغييرات بشكل متسق على جميع البيئات (stacks).
• إمكانية التراجع إلى الإصدارات السابقة بسهولة.

5️⃣ Treating Resources as Disposable — التعامل مع الموارد كشيء قابل للاستبدال

📖 ماذا يعني التعامل مع الموارد كشيء قابل للاستبدال (Disposable Resources)؟
يعني التفكير في بنيتك التحتية كبرنامج وليس كأجهزة مادية. مع الأجهزة المادية، قد تشتري مكونات أكثر من حاجتك استعداداً لذروة الاستخدام، لكن هذا مكلف وغير مرن ويصعب ترقيته بسبب التكاليف الغارقة (sunk cost). بدلاً من ذلك، عندما تتعامل مع الموارد كشيء قابل للاستبدال، يصبح الانتقال بين الخوادم أو الموارد الأخرى أمراً بسيطاً، ويمكنك الاستجابة بسرعة للتغيرات في احتياجات السعة وترقية التطبيقات وإدارة البرامج الأساسية.

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

6️⃣ Using Loosely Coupled Components — استخدام المكونات منخفضة الاقتران

📖 ما هو الاقتران المنخفض (Loosely Coupled)؟
البنى التقليدية تحتوي على سلاسل من الخوادم المترابطة بشدة (tightly coupled)، كل خادم له غرض محدد. المشكلة أن تعطل أي مكون يمكن أن يكون قاتلاً للنظام بأكمله، كما أنه يعيق التوسع. مع الاقتران المنخفض، تستخدم حلولاً مُدارة كوسيط بين طبقات النظام، وهذا الوسيط يعالج تلقائياً الأعطال وتوسع المكونات. حلان رئيسيان لفصل المكونات هما موازنات الأحمال (load balancers) وقوائم الرسائل (message queues).

💡 مقارنة سريعة:

وجه المقارنة	الاقتران المنخفض (Loosely Coupled)	الاقتران المحكم (Tightly Coupled)
تعطل المكونات	يعزل العطل في مكون واحد دون تأثير على الباقي	تعطل أي مكون قد يوقف النظام بأكمله
التوسع	يمكن إضافة أو إزالة خوادم بسهولة	يتطلب ربط كل خادم بجميع الخوادم المتصلة
الإدارة	حلول وسيطة مدارة تعالج الأعطال تلقائياً	إدارة يدوية معقدة وعرضة للأخطاء

على سبيل المثال تطبيق ويب يستخدم Elastic Load Balancing (ELB) بين خوادم الويب وخوادم التطبيق.
عند تعطل أحد خوادم التطبيق، يوجه موازن الأحمال كل الحركة إلى الخادمين الصحيحين تلقائياً.
في المقابل، البنية المترابطة تسبب أخطاء عندما تتعطل خوادم التطبيق وتحاول خوادم الويب الاتصال بها دون جدوى.

7️⃣ Designing Services, Not Servers — تصميم خدمات وليس خوادم

📖 لماذا نصمم خدمات وليس خوادم (Services, Not Servers)؟
على الرغم من أن Amazon EC2 يوفر مرونة هائلة، إلا أنه لا ينبغي أن يكون الحل الأول أو الوحيد لكل احتياج. أحياناً تكون الحاويات (containers) أو الحلول بدون خوادم (serverless) أكثر ملاءمة. مع الحلول المدارة وبدون خوادم من AWS، لا تحتاج إلى توفير وتكوين وإدارة خادم EC2 بالكامل. أمثلة على ذلك: AWS Lambda وAmazon SQS وAmazon DynamoDB وAmazon Cognito.

8️⃣ Choosing the Right Database Solution — اختيار حل قاعدة البيانات المناسب

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

العوامل المؤثرة في الاختيار:

• احتياجات القراءة والكتابة (read and write needs).
• متطلبات التخزين الإجمالية (total storage requirements).
• حجم الكائنات النموذجية وطبيعة الوصول إليها.
• متطلبات المتانة (durability) وزمن الوصول (latency).
• أقصى عدد من المستخدمين المتزامنين (maximum concurrent users).
• طبيعة الاستعلامات (nature of queries) وقوة ضوابط التكامل المطلوبة.

9️⃣ Avoiding Single Points of Failure — تجنب نقاط الفشل الفردية

📖 كيف نتجنب نقاط الفشل الفردية (Single Points of Failure)؟
افترض أن كل شيء سيفشل — ثم صمم بالعكس. هذا لا يعني بالضرورة تكرار كل مكون، فاعتماداً على اتفاقيات مستوى الخدمة (SLAs) يمكنك استخدام حلول آلية تطلق المكونات فقط عند الحاجة أو استخدام خدمة مُدارة تستبدل AWS تلقائياً الأجهزة المعطلة. إذا كان خادما تطبيق متصلين بخادم قاعدة بيانات واحد، فإن هذا الخادم يمثل نقطة فشل فردية — عندما يتعطل، تتعطل خوادم التطبيق أيضاً. الحل الشائع هو إنشاء خادم قاعدة بيانات ثانٍ (احتياطي) وتكرار البيانات بينهما.

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

🔟 Optimizing for Cost — تحسين التكلفة

📖 كيف تحسّن التكلفة في AWS؟
مع الحوسبة السحابية، يمكنك تحويل النفقات الثابتة (fixed expenses) إلى نفقات متغيرة (variable expenses). النفقات الثابتة هي الأموال التي تنفقها لشراء الأصول المادية وصيانتها سواء كانت نشطة أم لا. أما خدمات AWS فتستخدم نموذج تكلفة متغير — تدفع فقط مقابل الخدمات التي تحتاجها طوال مدة استخدامها. أفضل طريقة لبناء بنية تحتية فعالة من حيث التكلفة هي توفير الموارد التي تحتاجها فقط وإيقاف الخدمات عندما لا تكون قيد الاستخدام. تذكر أن تكرار إعداد مركز البيانات التقليدي بخوادم تعمل 24/7 في السحابة قد يكون مكلفاً جداً.

أسئلة تساعدك في تحسين التكلفة:

• هل مواردي بالحجم والنوع المناسبين للمهمة؟
• ما المقاييس التي يجب مراقبتها؟
• كيف أوقف تشغيل الموارد غير المستخدمة؟
• كم مرة سأحتاج استخدام هذا المورد؟
• هل يمكنني استبدال أي من خوادمي بخدمات مُدارة؟

1️⃣1️⃣ Using Caching — استخدام التخزين المؤقت

📖 ما هو التخزين المؤقت (Caching)؟
هي تقنية تخزين البيانات مؤقتاً في موقع وسيط بين الطالب والتخزين الدائم لجعل الطلبات المستقبلية أسرع وتقليل استخدام الشبكة (network throughput). الغرض الأساسي من التخزين المؤقت هو زيادة أداء استرجاع البيانات بتقليل الحاجة للوصول إلى طبقة التخزين البطيئة. تُخدم الطلبات المستقبلية للبيانات المخزنة مؤقتاً بشكل أسرع من الطلبات التي تصل إلى موقع التخزين الأساسي.

على سبيل المثال موقع ويب يستخدم Amazon CloudFront أمام Amazon S3 لتقديم الصور والفيديوهات.
يتم تخزين الملفات في نقاط الحافة (edge locations) القريبة من المستخدمين.
الطلبات الأولى تجلب الملف من S3 وتخزنه في CloudFront بينما تخدم الطلبات التالية من الحافة بزمن وصول وتكلفة أقل بكثير.
بعد الطلب الأول، لم تعد تدفع لنقل الملف من S3.

1️⃣2️⃣ Securing Your Entire Infrastructure — تأمين بنيتك التحتية بالكامل

📖 كيف نؤمن البنية التحتية بالكامل (Securing Your Entire Infrastructure)؟
الأمان لا يقتصر على حماية الحدود الخارجية لبنيتك التحتية — بل يشمل ضمان أن تكون بيئاتك الفردية ومكوناتها مؤمنة من بعضها البعض. في Amazon EC2، يمكنك إنشاء Security Groups لتحديد المنافذ التي يمكنها إرسال واستقبال الحركة ومن أين يمكن أن تأتي هذه الحركة. هذا يقلل احتمالية انتشار تهديد أمني من خادم إلى آخر. يجب اتخاذ احتياطات مماثلة مع الخدمات الأخرى باستخدام الخدمات المُدارة، وتسجيل الوصول إلى الموارد، وعزل أجزاء بنيتك التحتية، وتشفير البيانات أثناء النقل والتخزين، وفرض التحكم في الوصول بمبدأ الامتياز الأقل.

خطوات أساسية:

• استخدام الخدمات المُدارة (managed services).
• تسجيل الوصول إلى الموارد (log access of resources).
• عزل أجزاء البنية التحتية (isolate parts of infrastructure).
• تشفير البيانات أثناء النقل والتخزين (encrypt data in transit and at rest).
• فرض التحكم في الوصول بشكل دقيق بمبدأ الامتياز الأقل.
• استخدام المصادقة متعددة العوامل (MFA).
• أتمتة النشر للحفاظ على اتساق الأمان.

✅ خلاصة: أفضل ممارسات بناء الحلول على AWS

• قيّم المفاضلات في التصميم وابنِ قراراتك على بيانات تجريبية.
• طبّق قابلية التوسع في كل طبقة من البنية التحتية.
• أتمت بيئتك باستخدام أدوات المراقبة المدمجة مثل CloudWatch وAuto Scaling.
• استخدم البنية التحتية ككود (IaC) لنشر بيئات متطابقة وتقليل الأخطاء.
• تعامل مع الموارد كشيء قابل للاستبدال واستجب بسرعة للتغيرات.
• صمم مكونات منخفضة الاقتران باستخدام موازنات الأحمال وقوائم الرسائل.
• صمم خدمات وليس خوادم — استخدم الحاويات والحلول بدون خوادم عند الإمكان.
• اختر حل قاعدة البيانات المناسب بناءً على احتياجات التطبيق وليس العكس.
• تجنب نقاط الفشل الفردية بتكرار المكونات الحيوية واستخدام الخدمات المُدارة.
• حسّن التكلفة بتوفير الموارد المناسبة فقط وإيقاف الخدمات غير المستخدمة.
• استخدم التخزين المؤقت (CloudFront) لتحسين الأداء وخفض التكلفة.
• أمّن بنيتك التحتية بالكامل من كل طبقة باستخدام Security Groups والتشفير والامتياز الأقل.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Scalability	قابلية التوسع	قدرة النظام على التعامل مع زيادة الطلب بإضافة الموارد بشكل تلقائي.
Infrastructure as Code (IaC)	البنية التحتية ككود	أتمتة البنية التحتية باستخدام كود برمجي بدلاً من العمليات اليدوية.
Loosely Coupled	اقتران منخفض	تصميم مكونات مستقلة تتواصل عبر وسيط مما يمنع تأثير الأعطال.
Single Point of Failure	نقطة فشل فردية	مكون واحد يؤدي تعطله إلى توقف النظام بأكمله.
Caching	التخزين المؤقت	تقنية تخزين البيانات في موقع وسيط لتسريع الطلبات المستقبلية.
Elasticity	المرونة	قدرة النظام على التوسع والانكماش تلقائياً حسب الطلب.
CloudFront	شبكة توصيل المحتوى	خدمة CDN توفر محتوى قريباً من المستخدمين عبر نقاط حافة عالمية.
Security Group	مجموعة الأمان	جدار ناري افتراضي يتحكم بحركة المرور إلى ومن الموارد في AWS.

1️⃣ AWS Infrastructure Topics — مواضيع البنية التحتية لـ AWS

📖 ما هي البنية التحتية العالمية لـ AWS؟
هي منصة سحابية آمنة وواسعة وموثوقة تقدم أكثر من 200 خدمة كاملة من مراكز بيانات حول العالم. تمتد البنية التحتية لـ AWS عبر 102 منطقة توفر (Availability Zone) في 32 منطقة جغرافية (Region) حول العالم. عند تصميم البنى، تحتاج إلى تحديد المنطقة المناسبة لنشرها. يجب أن تستند قراراتك إلى متطلبات العمل واحتياجات حمل العمل. على سبيل المثال، إذا كان زمن الوصول المنخفض مطلوباً، ففكر في استخدام نقاط الوجود (Points of Presence - PoPs) أو الخوادم الوسيطة الإقليمية (regional edge caches).

المكونات الرئيسية للبنية التحتية:

• AWS Regions — المناطق الجغرافية
• Availability Zones — مناطق التوفر
• AWS Local Zones — المناطق المحلية
• AWS Data Centers — مراكز البيانات
• AWS Points of Presence (PoPs) — نقاط الوجود

2️⃣ Selecting Regions — اختيار المناطق

📖 كيف نختار منطقة AWS المناسبة؟
المنطقة (Region) هي موقع جغرافي مادي يحتوي على منطقتَي توفر أو أكثر. تتصل المناطق بمزودي خدمة إنترنت متعددين وبشبكة أساسية عالمية خاصة (private global network backbone) توفر زمن وصول أقل وتكلفة أقل عبر المناطق. المناطق التي أُطلقت قبل 20 مارس 2019 مفعلة افتراضياً، بينما المناطق الأحدث (مثل Asia Pacific (Hong Kong) وMiddle East (Bahrain)) معطلة افتراضياً ويجب تفعيلها يدوياً. لتحقيق تحمل الأعطال، المناطق معزولة عن بعضها — الموارد في منطقة لا تُنسخ تلقائياً إلى مناطق أخرى. أنت المسؤول عن نسخ البيانات عبر المناطق إذا كانت احتياجات عملك تتطلب ذلك.

📋 عوامل اختيار المنطقة:

• الامتثال (compliance): متطلبات تخزين البيانات والخصوصية حسب البلد أو الجهة التنظيمية.
• زمن الوصول (latency): اختيار منطقة قريبة من المستخدمين لتقليل زمن الاستجابة.
• توفر الخدمات: بعض الخدمات غير متاحة في جميع المناطق.
• التكلفة: تختلف تكاليف الخدمات بين المناطق.

3️⃣ Selecting Availability Zones — اختيار مناطق التوفر

📖 ما هي مناطق التوفر (Availability Zones)؟
كل منطقة تحتوي على منطقتَي توفر معزولتين أو أكثر. كل منطقة توفر تتكون من مركز بيانات واحد أو أكثر (بعضها يصل إلى 6 مراكز بيانات). لا يمكن أن يكون مركز البيانات جزءاً من منطقتي توفر في نفس الوقت. صُممت كل منطقة توفر كمنطقة فشل مستقلة — منفصلة فيزيائياً في السهل الفيضي المنخفض المخاطر، مع مصدر طاقة غير منقطع ومولدات احتياطية في الموقع، ومغذاة من شبكات كهرباء مختلفة من مرافق مستقلة.

🔑 نصيحة أساسية: أنت المسؤول عن اختيار مناطق التوفر لأنظمتك. يُنصح بتوزيع التطبيقات عبر مناطق توفر متعددة لتظل مرنة (resilient) في معظم حالات الفشل بما في ذلك الكوارث الطبيعية أو أعطال الأنظمة.

4️⃣ Using Local Zones — استخدام المناطق المحلية

📖 ما هي المناطق المحلية (AWS Local Zones)؟
هي نوع من نشر البنية التحتية لـ AWS يضع خدمات الحوسبة والتخزين وقواعد البيانات وخدمات أخرى مختارة أقرب إلى المراكز السكانية والصناعية وتقنية المعلومات الكبيرة حيث لا توجد مناطق (Regions) اليوم. تتيح لك المناطق المحلية تشغيل أجزاء التطبيقات الحساسة لزمن الوصول (latency-sensitive) بالقرب من المستخدمين النهائيين، مما يوفر زمن وصول بأحادي الرقم المللي ثانية (single-digit millisecond latency) لحالات استخدام مثل إنشاء محتوى الوسائط والترفيه والألعاب في الوقت الفعلي ومحاكاة الخزانات.

5️⃣ Role of AWS Data Centers — دور مراكز بيانات AWS

📖 ما هو دور مراكز البيانات (Data Centers)؟
مراكز البيانات هي أساس البنية التحتية لـ AWS. لا يمكنك تحديد مركز بيانات محدد لنشر الموارد — لكنه الموقع الفعلي حيث توجد البيانات وتحدث معالجتها. تدير Amazon مراكز بيانات حديثة وعالية التوفر، كل منها يحتوي عادةً على عشرات الآلاف من الخوادم. جميع مراكز البيانات متصلة بالإنترنت وتخدم العملاء. في حالة الفشل، تنقل العمليات الآلية حركة بيانات العملاء بعيداً عن المنطقة المتأثرة. تُنشر التطبيقات الأساسية بتكوين N+1 مما يعني وجود سعة كافية لموازنة الحركة إلى المواقع المتبقية. تستخدم AWS معدات شبكات مخصصة من مصادر متعددة من مصنعي الأجهزة الأصليين (ODMs) مع حزمة بروتوكولات شبكات مخصصة.

6️⃣ AWS PoPs — نقاط الوجود

📖 ما هي نقاط الوجود (Points of Presence - PoPs)؟
لتوصيل المحتوى للمستخدمين النهائيين بزمن وصول أقل، تستخدم CloudFront شبكة عالمية تضم أكثر من 410 نقطة وجود، تتكون من 400 موقع حافة (edge location) و13 خادماً وسيطاً إقليمياً (regional mid-tier cache). مواقع الحافة تضمن أن المحتوى الشائع يُخدم بسرعة للعملاء. الخوادم الوسيطة الإقليمية تجلب المزيد من محتواك أقرب للعملاء حتى لو لم يكن شائعاً بما يكفي للبقاء في موقع الحافة. هذا يقلل زمن الوصول ويزيد الكفاءة ويكون شفافاً للمستخدم النهائي.

أنواع نقاط الوجود:

• مواقع الحافة (Edge Locations): خوادم قريبة من العملاء تصمم لتقديم الخدمات بأقل زمن وصول ممكن، تدعم خدمات مثل Amazon Route 53 وAWS Global Accelerator وCloudFront.
• الخوادم الوسيطة الإقليمية (Regional Edge Caches): خوادم بين الخادم الأصلي وموقع الحافة، تخزن المحتوى غير المتكرر لتجنب جلبه من الخادم الأصلي في كل مرة.

على سبيل المثال مستخدم في مصر يطلب تحميل صورة من موقع يستخدم CloudFront.
إذا كانت الصورة مخزنة في موقع حافة في الشرق الأوسط، تصل إليه في أجزاء من الثانية.
بدون CloudFront، قد ينتقل الطلب إلى منطقة بعيدة مثل US East (N. Virginia) مما يزيد زمن الوصول.
هذا الفرق في الأداء يحسن تجربة المستخدم بشكل كبير ويزيد رضاه.

💡 مقارنة سريعة:

وجه المقارنة	موقع الحافة (Edge Location)	خادم وسيط إقليمي (Regional Edge Cache)
الموقع	قريب جداً من المستخدمين النهائيين	بين الخادم الأصلي وموقع الحافة
المحتوى	المحتوى الشائع والمتكرر	المحتوى غير المتكرر الذي لا يبقى في الحافة
الوظيفة	تسريع توصيل المحتوى الأكثر طلباً	تقليل الحاجة لجلب المحتوى من الخادم الأصلي
العدد	400 موقع حول العالم	13 موقعاً إقليمياً

✅ خلاصة: البنية التحتية العالمية لـ AWS

• تمتد البنية التحتية لـ AWS عبر 32 منطقة و102 منطقة توفر حول العالم.
• اختيار المنطقة (Region) يعتمد على الامتثال التنظيمي، زمن الوصول، توفر الخدمات، والتكلفة.
• مناطق التوفر (Availability Zones) معزولة فيزيائياً مع طاقة احتياطية وشبكات مستقلة لتحمل الأعطال.
• المناطق المحلية (Local Zones) تضع خدمات AWS بالقرب من المراكز السكانية الكبيرة لتحقيق زمن وصول بأحادي الرقم المللي ثانية.
• مراكز بيانات AWS جميعها متصلة بالإنترنت وتعمل بتكوين N+1 لضمان التوفر عند الفشل.
• نقاط الوجود (PoPs) المكونة من 400 موقع حافة و13 خادماً وسيطاً إقليمياً تُحسّن توصيل المحتوى للمستخدمين.
• أنت المسؤول عن اختيار مناطق التوفر ونسخ البيانات عبر المناطق حسب احتياجات عملك.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
AWS Region	منطقة AWS	موقع جغرافي يحتوي على منطقتَي توفر أو أكثر مع شبكة خاصة عالمية.
Availability Zone (AZ)	منطقة توفر	مركز بيانات مستقل أو أكثر ضمن منطقة، معزول فيزيائياً لتحمل الأعطال.
Local Zone	منطقة محلية	امتداد للمنطقة يضع خدمات AWS قرب المراكز السكانية لزمن وصول منخفض.
Data Center	مركز بيانات	منشأة فعلية تحتوي على خوادم AWS حيث تخزن البيانات وتعالج.
Point of Presence (PoP)	نقطة وجود	موقع حافة أو خادم وسيط إقليمي لتوصيل المحتوى بزمن وصول منخفض.
Edge Location	موقع حافة	موقع قريب من المستخدمين يخزن المحتوى الشائع لخدمته بسرعة.
Regional Edge Cache	خادم وسيط إقليمي	خادم بين الخادم الأصلي والحافة يخزن المحتوى غير المتكرر.
CloudFront	شبكة توصيل المحتوى	خدمة CDN عالمية توفر المحتوى من نقاط حافة قريبة من المستخدمين.

1. A company wants to run its critical workload on AWS and needs to ensure the architecture can recover from infrastructure failures and automatically acquire compute resources to meet demand. Which pillar of the AWS Well-Architected Framework addresses these requirements?

A) Security B) Reliability C) Performance Efficiency D) Cost Optimization

✅ Correct! The Reliability pillar focuses on a workload's ability to recover from infrastructure or service failures, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.

❌ Incorrect. The correct answer is Reliability. The Reliability pillar addresses recovery from failures, dynamic resource acquisition, and mitigation of disruptions — all essential for a critical workload.

2. A solutions architect is designing a highly available application on AWS. The application must remain available even if an entire data center fails. What is the minimum AWS infrastructure deployment that meets this requirement?

A) Deploy resources across multiple edge locations B) Deploy resources across multiple Availability Zones in a single AWS Region C) Deploy all resources in a single Availability Zone D) Deploy resources across multiple AWS Regions

✅ Correct! An Availability Zone (AZ) consists of one or more physically separate data centers. Deploying across multiple AZs within a single Region protects against a full data center failure while maintaining low-latency connectivity between AZs.

❌ Incorrect. The correct answer is deploy resources across multiple Availability Zones. Each AZ is an isolated data center; using multiple AZs provides high availability within a Region without the complexity of multi-Region deployment.

3. According to the AWS Well-Architected Framework, which design principle is described as "making frequent, small, reversible changes" to reduce risk and improve operational outcomes?

A) Design for failure B) Evolve Opposing Standards — implement changes in small increments C) Go global in minutes D) Use serverless architectures

✅ Correct! The Operational Excellence pillar includes the principle of evolving opposing standards by making frequent, small, and reversible changes. This reduces the blast radius of failures and allows teams to learn from each change.

❌ Incorrect. The correct answer is Evolve Opposing Standards — implement changes in small increments (from the Operational Excellence pillar). This principle emphasizes frequent, reversible changes to reduce risk.

4. A company is designing a cloud architecture and wants to reduce environmental impact as part of its sustainability goals. Which pillar of the AWS Well-Architected Framework provides guidance on minimizing energy consumption and maximizing resource efficiency?

A) Operational Excellence B) Security C) Cost Optimization D) Sustainability

✅ Correct! The Sustainability pillar (added in 2021) focuses on minimizing the environmental impact of running cloud workloads. It provides guidance on energy efficiency, resource optimization, and reducing the carbon footprint of AWS architectures.

❌ Incorrect. The correct answer is Sustainability. This is the sixth pillar of the Well-Architected Framework, added to help organizations design environmentally sustainable cloud architectures.

5. An e-commerce application is deployed on a single Amazon EC2 instance in one Availability Zone. The company wants to improve availability by removing single points of failure with minimal changes. What should a solutions architect recommend?

A) Move the application to a larger EC2 instance type B) Deploy EC2 instances across multiple Availability Zones behind an Application Load Balancer C) Create a backup of the EC2 instance using AMIs D) Place the EC2 instance in an Auto Scaling group with a minimum of 1

✅ Correct! Deploying EC2 instances across multiple Availability Zones with an Application Load Balancer eliminates the single point of failure at the instance and AZ level. If one AZ fails, traffic is routed to healthy instances in other AZs.

❌ Incorrect. The correct answer is deploy EC2 instances across multiple Availability Zones behind an ALB. This provides high availability by distributing traffic across instances in separate physical locations.

6. Which of the following is a key benefit of using loose coupling (decoupling) when designing cloud architectures on AWS?

A) Lower network latency between components B) Fault isolation — a failure in one component does not affect other components C) Reduced storage costs D) Simplified security group configuration

✅ Correct! Loose coupling isolates components so that a failure in one does not cascade to others. This is achieved using queues (Amazon SQS), event buses (Amazon EventBridge), and other asynchronous communication patterns.

❌ Incorrect. The correct answer is fault isolation. Decoupled architectures ensure that individual component failures are contained and do not bring down the entire system.

7. A company wants to deploy a web application globally and serve users with the lowest possible latency. The application serves a mix of static content (images, CSS) and dynamic API calls. Which AWS service should the company use to cache static content at edge locations close to users?

A) Amazon CloudFront B) Amazon ElastiCache C) Application Load Balancer D) Amazon Route 53

✅ Correct! Amazon CloudFront is a content delivery network (CDN) that caches content at over 400 edge locations worldwide. It significantly reduces latency for static content while also accelerating dynamic content delivery via the AWS global network.

❌ Incorrect. The correct answer is Amazon CloudFront. CloudFront uses edge locations to cache and serve content with low latency to users around the globe.

8. A solutions architect needs to design an architecture that follows the principle of "design for failure." Which approach best demonstrates this principle?

A) Use a single, highly reliable EC2 instance with premium hardware B) Assume components will fail and build redundancy and automated recovery into the architecture C) Monitor the system and fix failures when they occur D) Purchase a warranty from the hardware vendor

✅ Correct! "Design for failure" means assuming that failures will happen and proactively building redundancy, automated failover, and self-healing mechanisms. This is a core principle of the Reliability pillar in the Well-Architected Framework.

❌ Incorrect. The correct answer is assume components will fail and build redundancy and automated recovery. Designing for failure means expecting and accommodating failures rather than trying to prevent them entirely.

9. What is the primary difference between an AWS Region and an Availability Zone?

A) A Region is a geographic area containing multiple AZs; each AZ is one or more physically isolated data centers within that Region B) A Region provides compute services; an AZ provides storage services C) A Region is a single data center; an AZ is a group of Regions D) There is no difference — the terms are interchangeable

✅ Correct! An AWS Region is a separate geographic area containing multiple (≥2) Availability Zones. Each AZ is one or more physically separated data centers with independent power, cooling, and networking, connected by low-latency fiber.

❌ Incorrect. The correct answer is: A Region is a geographic area containing multiple AZs; each AZ is one or more physically isolated data centers within that Region. This hierarchical structure is the foundation of AWS global infrastructure.

10. A company is adopting the AWS Well-Architected Framework and wants to implement the principle of "infrastructure as code." Which action best demonstrates this practice?

A) Manually creating EC2 instances through the AWS Management Console B) Using AWS CloudFormation or Terraform to define and provision infrastructure through version-controlled template files C) Hiring more system administrators to manage servers D) Writing custom scripts to SSH into servers and configure them

✅ Correct! Infrastructure as code (IaC) manages and provisions cloud resources through machine-readable definition files (e.g., CloudFormation, Terraform). This enables repeatable, consistent, and version-controlled deployments — a key AWS best practice.

❌ Incorrect. The correct answer is using AWS CloudFormation or Terraform to define infrastructure through version-controlled template files. IaC replaces manual processes with automated, repeatable infrastructure management.

🚀 الخاتمة

في هذه الوحدة تعرفنا على أساسيات هندسة الحوسبة السحابية — بدءاً من قصة نشأة AWS عام 2006 كحل لمشاكل التوسع الداخلية في أمازون، وصولاً إلى تعريف معمارية السحابة ودور مهندس السحابة في تصميم الحلول المتوافقة مع أهداف العمل. استعرضنا بالتفصيل إطار AWS Well-Architected Framework وركائزه الست: التميز التشغيلي، الأمان، الموثوقية، كفاءة الأداء، تحسين التكلفة، والاستدامة — مع أفضل الممارسات لكل ركيزة. تعلمنا 12 ممارسة أساسية لبناء الحلول على AWS مثل قابلية التوسع والأتمتة والبنية التحتية ككود والمكونات منخفضة الاقتران وتجنب نقاط الفشل الفردية والتخزين المؤقت. وأخيراً استعرضنا البنية التحتية العالمية لـ AWS من المناطق ومناطق التوفر والمناطق المحلية ومراكز البيانات ونقاط الوجود، وكيفية اتخاذ قرارات مدروسة حول مكان نشر الموارد السحابية.

تعديل المقال