دراسة حالة: لماذا أستخدم البنية التحتية السحابية لـ AWS لمنتجاتي

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

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

متطلبات

كان لدى العميل متطلبان رئيسيان يجب أن يلبيهما الحل المقترح:

1. حماية
2. قابلية التوسع

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

نظرة عامة على مفاهيم أمان AWS

تتمثل إحدى الفوائد الرئيسية لإعداد بنية AWS Cloud الأساسية الخاصة بك في العزل الكامل للشبكة والتحكم الكامل في السحابة الخاصة بك. هذا هو السبب الرئيسي لاختيار مسار البنية التحتية كخدمة (IaaS) ، بدلاً من تشغيل بيئات النظام الأساسي كخدمة (PaaS) الأبسط إلى حد ما ، والتي توفر إعدادات أمان افتراضية قوية ولكنها تفتقر إلى التحكم الكامل والدقيق الذي تحصل عليه من خلال إعداد السحابة الخاصة بك مع AWS.

على الرغم من أن LEVELS كان منتجًا صغيرًا عندما اتصلوا بـ Toptal لخدمات AWS الاستشارية ، فقد كانوا على استعداد للالتزام بـ AWS وعرفوا أنهم يريدون أمانًا متطورًا مع بنيتهم ​​التحتية ، لأنهم قلقون للغاية بشأن بيانات المستخدم وخصوصيته. علاوة على ذلك ، فهم يخططون لدعم معالجة بطاقات الائتمان في المستقبل ، لذلك كانوا يعلمون أنهم سيحتاجون إلى ضمان الامتثال PCI-DSS في مرحلة ما.

السحابة الافتراضية الخاصة (VPC)

يبدأ الأمان على AWS بإنشاء Amazon Virtual Private Cloud (VPC) الخاصة بك - وهي شبكة افتراضية مخصصة تستضيف موارد AWS الخاصة بك ومعزولة منطقيًا عن الشبكات الافتراضية الأخرى في سحابة AWS. يحصل VPC على نطاق عناوين IP الخاص به ، والشبكات الفرعية القابلة للتكوين بالكامل ، وجداول التوجيه ، وقوائم التحكم في الوصول إلى الشبكة ، ومجموعات الأمان (جدار الحماية بشكل فعال).

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

وبالتالي ، استقرنا على بيئة الإنتاج باعتبارها VPC واحدة ، مع بيئات التطوير والاختبار وضمان الجودة مثل VPC آخر.

الوصول إلى العزل على مستوى VPC

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

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

نموذج أمان متجر الأصول

يتم تخزين الأصول في تخزين كائن Amazon Simple Storage Service (S3) . البنية التحتية للتخزين S3 مستقلة تمامًا عن VPCs ونموذج الأمان الخاص بها مختلف. يتم تنظيم التخزين في حاويات S3 منفصلة لكل بيئة و / أو فئات من الأصول ، مما يحمي كل مجموعة بحقوق الوصول المناسبة.

باستخدام LEVELS ، تم تحديد عدة فئات من الأصول: تحميلات المستخدم ، والمحتوى المنتج من LEVELS (مقاطع فيديو ترويجية ومحتوى مشابه) ، وأصول تطبيقات الويب وواجهة المستخدم (كود JS ، والرموز ، والخطوط) ، وتكوين التطبيقات والبنية التحتية ، وحزم النشر من جانب الخادم.

كل من هؤلاء يحصل على دلو S3 منفصل.

إدارة أسرار التطبيق

مع AWS ، يوجد متجر معلمات AWS Systems Manager مشفر أو AWS Secrets Manager ، وهي خدمات ذات قيمة رئيسية مُدارة مصممة للحفاظ على أمان الأسرار (يمكنك معرفة المزيد في Linux Academy و 1Strategy).

تدير AWS مفاتيح التشفير الأساسية وتعالج التشفير / فك التشفير. يمكن للأسرار نفسها قراءة وكتابة سياسات الأذونات المطبقة بناءً على بادئات المفاتيح ، لكل من البنية التحتية والمستخدمين (الخوادم والمطورين ، على التوالي).

وصول خادم SSH

لا يجب على الإطلاق الوصول إلى SSH إلى الخوادم في بيئة مؤتمتة بالكامل وغير قابلة للتغيير. يمكن استخراج السجلات وإرسالها إلى خدمات تسجيل مخصصة ، كما يتم تفريغ المراقبة إلى خدمة مراقبة مخصصة. ومع ذلك ، قد تكون هناك حاجة للوصول إلى SSH من حين لآخر لفحص التكوين وتصحيح الأخطاء.

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

الوصول إلى قاعدة البيانات

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

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

نظرة عامة على مفاهيم قابلية التوسع في AWS

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

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

يسمح تفريغ كل ذلك بفريق عمليات أصغر ، مما يعوض إلى حد ما التكلفة الأعلى للخدمات المدارة للنظام الأساسي. كان فريق LEVELS سعيدًا باختيار هذا المسار حيثما أمكن ذلك.

Amazon Elastic Compute Cloud (EC2)

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

يجب أن يكون توفير مثيلات EC2 مؤتمت بالكامل. يتم تحقيق الأتمتة من خلال AMIs المخصصة لفئات مختلفة من الخوادم ، ومجموعات القياس التلقائي التي تهتم بتشغيل أساطيل الخوادم الديناميكية من خلال الاحتفاظ بالعدد المناسب من مثيلات الخوادم قيد التشغيل في الأسطول وفقًا لحركة المرور الحالية.

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

Amazon Relational Database Service (RDS)

كان الفريق يعمل بالفعل على Amazon RDS لـ MySQL ، ولكن لم يتم بعد تطوير النسخة الاحتياطية المناسبة ، والتسامح مع الأخطاء ، واستراتيجية الأمان. في التكرار الأول ، تمت ترقية طبعة قاعدة البيانات إلى مجموعة ثنائية المثيل في كل VPC ، تم تكوينها كنسخة رئيسية ونسخة متماثلة للقراءة ، مما يدعم تجاوز الفشل التلقائي.

في التكرار التالي ، مع توفر محرك MySQL الإصدار 5.7 ، حصلت البنية التحتية على ترقية لخدمة Amazon Aurora MySQL . على الرغم من إدارته بالكامل ، لا يُعد Aurora حلاً يتم تغييره تلقائيًا. إنه يوفر قياسًا تلقائيًا للتخزين ، وتجنب مشكلة تخطيط السعة. لكن لا يزال مهندس الحلول بحاجة إلى اختيار حجم مثيل الحوسبة.

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

يتيح عرض Aurora Serverless الجديد مستوى معينًا من التحجيم التلقائي لموارد الحوسبة أيضًا ، وهي ميزة تستحق البحث عنها بالتأكيد في المستقبل.

خدمات AWS المُدارة

بصرف النظر عن هذين المكونين ، يستفيد باقي النظام من آليات القياس التلقائي لخدمات AWS المُدارة بالكامل. هذه هي Elastic Load Balancing (ELB) ، و Amazon Simple Queue Service (SQS) ، وتخزين العناصر Amazon S3 ، ووظائف AWS Lambda ، وخدمة Amazon Simple Notification Service (SNS) ، حيث لا يحتاج المهندس المعماري إلى جهد خاص في التوسع.

متغير مقابل البنية التحتية الثابتة

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

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

يمكن العثور على المزيد حول البنية التحتية المتغيرة مقابل البنية التحتية الثابتة في مدونة HashiCorp.

نظرة عامة على العمارة

من الناحية الفنية ، يعد LEVELS تطبيقًا للجوال وتطبيقًا للويب مزودًا بخلفية REST API وبعض خدمات الخلفية - وهو تطبيق نموذجي في الوقت الحاضر. فيما يتعلق بذلك ، تم اقتراح وتشكيل البنية التحتية التالية:

عزل الشبكة الافتراضية - Amazon VPC

يصور الرسم التخطيطي هيكل بيئة واحدة في VPC الخاص به. تتبع البيئات الأخرى نفس الهيكل (وجود Application Load Balancer (ALB) ومجموعة Amazon Aurora مشتركة بين البيئات غير الإنتاجية في VPC الخاصة بهم ، لكن إعداد الشبكة هو نفسه تمامًا).

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

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

الحوسبة

تدير LEVELS واجهة برمجة تطبيقات REST تقليدية مع بعض العاملين في الخلفية لمنطق التطبيق الذي يحدث في الخلفية. يعمل كلاهما كأساطيل ديناميكية من مثيلات EC2 العادية ، مؤتمتة بالكامل من خلال مجموعات القياس التلقائي. تُستخدم خدمة Amazon SQS المُدارة لتوزيع مهام الخلفية (الوظائف) ، وتجنب الحاجة إلى تشغيل خادم MQ الخاص بك وصيانته وتوسيع نطاقه.

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

موازنة الحمل والتحجيم التلقائي والتسامح مع الخطأ

يمكن تحقيق موازنة التحميل يدويًا من خلال Nginx أو HAProxy ، لكن اختيار Amazon Elastic Load Balancing (ELB) يضيف فائدة وجود بنية تحتية لموازنة الحمل قابلة للتطوير بشكل جوهري ومتاحة بشكل كبير ومتحمل للأخطاء.

يتم استخدام نكهة Application Load Balancer (ALB) الخاصة بـ ELB ، مما يجعل استخدام توجيه طبقة HTTP متاحًا في موازن التحميل. يتم تسجيل المثيلات الجديدة المضافة إلى الأسطول تلقائيًا مع ALB من خلال آليات منصة AWS. يراقب ALB أيضًا توفر الطبعات في جميع الأوقات. لديه القدرة على إلغاء التسجيل وإنهاء الحالات غير الصحية ، مما يؤدي إلى تشغيل القياس التلقائي لاستبدالها بأخرى جديدة. من خلال هذا التفاعل بين الاثنين ، يتحقق الإصلاح التلقائي لأسطول EC2.

مخزن بيانات التطبيق

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

يمكن أيضًا استخدام النسخ المتماثلة المقروءة ، كما يوحي اسمها ، لتوزيع تحميل كتلة قاعدة البيانات لعمليات قراءة البيانات.

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

تخزين الأصول وتقديمها

تقبل LEVELS المحتوى الذي تم تحميله من قبل المستخدمين والذي يحتاج إلى تخزين. تخزين كائن Amazon S3 هو ، كما هو متوقع تمامًا ، الخدمة التي ستتولى هذه المهمة. هناك أيضًا أصول تطبيق (عناصر واجهة المستخدم - صور ، أيقونات ، خطوط) يجب إتاحتها لتطبيق العميل ، حتى يتم تخزينها في S3 أيضًا. يوفر S3 نسخًا احتياطية تلقائية للبيانات التي تم تحميلها من خلال النسخ المتماثل لوحدات التخزين الداخلية ، ويوفر متانة البيانات افتراضيًا.

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

أخيرًا ، يعد تطبيق الويب الذي يعمل على المستعرض أيضًا مجموعة من الأصول الثابتة - حيث تقوم البنية الأساسية لبناء التكامل المستمر بتجميع كود JavaScript وتخزين كل بنية في S3 أيضًا.

بمجرد تخزين جميع هذه الأصول بأمان في S3 ، يمكن تقديمها مباشرة ، حيث توفر S3 واجهة HTTP عامة ، أو من خلال Amazon CloudFront CDN. تجعل CloudFront الأصول موزعة جغرافيًا ، مما يقلل وقت الاستجابة للمستخدمين النهائيين ، كما يُمكّن دعم HTTPS لخدمة الأصول الثابتة.

توفير البنية التحتية وإدارتها

يعد توفير البنية الأساسية لـ AWS مزيجًا من الشبكات والموارد والخدمات المُدارة من AWS وموارد حوسبة EC2 المجردة. خدمات AWS المُدارة مُدارة بشكل جيد. ليس هناك الكثير لنفعله معهم باستثناء توفير وتطبيق الأمان المناسب ، بينما مع موارد حوسبة EC2 ، نحتاج إلى الاهتمام بالتهيئة والأتمتة بأنفسنا.

الأدوات

تجعل وحدة تحكم AWS المستندة إلى الويب من إدارة البنية الأساسية لـ AWS "الشبيهة بالطوب الليجو" أي شيء غير تافهة ، وكأي عمل يدوي ، تكون عرضة للخطأ. لهذا السبب فإن استخدام أداة مخصصة لأتمتة هذا العمل أمر مطلوب للغاية.

إحدى هذه الأدوات هي AWS CloudFormation ، التي طورتها وصيانتها AWS. واحد آخر هو Terraform الخاص بـ HashiCorp - وهو خيار أكثر مرونة قليلاً من خلال تقديم مزودي منصات متعددة ، ولكنه مثير للاهتمام هنا بشكل أساسي بسبب فلسفة نهج البنية التحتية الثابتة لـ Terraform. تمشيا مع الطريقة التي يتم بها تشغيل البنية التحتية لـ LEVELS ، تبين أن Terraform ، جنبًا إلى جنب مع Packer لتوفير صور AMI الأساسية ، مناسب تمامًا.

توثيق البنية التحتية

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

افكار اخيرة

تعد البنية التحتية السحابية لـ AWS حلاً قابلاً للتطوير قادرًا على استيعاب نمو المنتجات في المستقبل بشكل تلقائي. بعد ما يقرب من عامين ، تمكنت من الحفاظ على انخفاض تكاليف التشغيل ، بالاعتماد على التشغيل الآلي السحابي دون وجود فريق عمليات أنظمة مخصص يعمل على مدار الساعة طوال أيام الأسبوع.

فيما يتعلق بالأمان ، تحتفظ سحابة AWS بجميع البيانات وجميع الموارد داخل شبكة خاصة داخل نفس السحابة. لا توجد بيانات سرية مطلوبة أبدًا للسفر عبر الشبكة العامة. يُمنح الوصول الخارجي بأذونات دقيقة دقيقة لأنظمة الدعم الموثوقة (CI / CD أو المراقبة الخارجية أو التنبيه) ، مما يحد من نطاق الوصول فقط إلى الموارد المطلوبة لدورها في النظام بأكمله.

تم تصميم هذا النظام وإعداده بشكل صحيح ، وهو مرن ومرن وآمن وجاهز للإجابة على جميع المتطلبات المستقبلية فيما يتعلق بتوسيع نطاق نمو المنتج أو تنفيذ أمان متقدم مثل امتثال PCI-DSS.

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

مزيد من القراءة على مدونة Toptal Engineering:

• قم بواجبك: 7 نصائح لاختبار المهندس المعماري للحلول المعتمدة من AWS
• Terraform مقابل CloudFormation: الدليل النهائي
• تسجيل SSH وإدارة الجلسة باستخدام AWS SSM
• العمل مع دعم TypeScript و Jest: برنامج تعليمي لـ AWS SAM