کلاؤڈ کے تصورات اور مشترکہ ذمہ داری

کلاؤڈ کمپیوٹنگ ایک ایسا طریقۂ استعمال ہے جس میں IT وسائل کی ملکیت نہیں لی جاتی بلکہ انہیں صرف ضرورت کے وقت، ضرورت کی مقدار میں کرائے پر لیا جاتا ہے اور استعمال کے مطابق ادائیگی کی جاتی ہے۔ درخواست سے لے کر استعمال شروع ہونے تک کا وقت مختصر ہوتا ہے، اور وسائل واپس کرتے ہی بلنگ بھی رک جاتی ہے۔ تنصیب سے پہلے مطلوبہ مقدار طے کر کے آلات خریدنا، اور بجلی و ایئر کنڈیشننگ تک کا انتظام خود کرنا، دونوں آن پریمیسز (オンプレミス) کے طریقے ہیں، اور چونکہ مقدار پہلے سے طے کرنی پڑتی ہے اس لیے اوور پروویژننگ (過剰プロビジョニング) یا گنجائش کی کمی پیدا ہو جاتی ہے۔ یہ وضاحت کہ معاہدے کی مدت کے دوران مقدار تبدیل نہیں ہو سکتی، کلاؤڈ کے اس بنیادی اصول کے برعکس ہے کہ مقدار بعد میں بڑھائی یا گھٹائی جا سکتی ہے۔

Pay-as-you-go (従量課金) وہ اصول ہے جس میں نہ کوئی پیشگی ادائیگی ہوتی ہے نہ طویل مدتی عہد (コミットメント)، اور صرف اتنی ادائیگی کی جاتی ہے جتنا حقیقت میں استعمال کیا گیا۔ چونکہ آپ پیش گوئی کے بجائے حقیقی طلب کے مطابق اسکیل کر سکتے ہیں، اس لیے اوور پروویژننگ کا خطرہ کم ہوتا ہے۔ ایک مقررہ مدت کے لیے استعمال کی سطح کا عہد کرنے کے بدلے فی یونٹ قیمت کم ہونا Save when you commit ہے؛ استعمال بڑھنے کے ساتھ فی یونٹ قیمت کم ہونا Pay less by using more ہے؛ اور اضافی چارجز کے بغیر مقررہ ماہانہ رقم میں یکجا کرنا Flat rate ہے — یہ سب مختلف اصولوں کی طرف اشارہ کرتے ہیں۔

Pay less by using more (使うほど安くなる) وہ اصول ہے جس کے تحت S3 اور ڈیٹا ٹرانسفر جیسی چیزوں پر درجہ وار قیمتوں کا ڈھانچہ (段階的な料金体系) لاگو ہوتا ہے، تاکہ استعمال بڑھنے کے ساتھ فی GB قیمت کم ہوتی جائے۔ ایک مقررہ مدت کے لیے استعمال کی سطح کا عہد کرنے کے بدلے فی یونٹ قیمت کم کرنا Save when you commit ہے، جس کی مثال Savings Plans ہیں۔ ہر بار صرف حقیقی استعمال کی ادائیگی کرنا Pay-as-you-go ہے، اور اضافی چارجز کے بغیر مقررہ ماہانہ رقم میں یکجا کرنا Flat rate ہے۔ چاروں اصولوں کے مقاصد مختلف ہیں، اس لیے یہ ایک دوسرے کی نفی نہیں کرتے بلکہ مل کر استعمال کیے جاتے ہیں۔

Save when you commit (コミットして節約) وہ اصول ہے جس میں، Savings Plans کی طرح، 1 سال یا 3 سال کی مدت کے لیے ایک مخصوص استعمال کی سطح کا عہد کرنے کے بدلے کمپیوٹ یا مشین لرننگ سروسز کی قیمتوں میں رعایت دی جاتی ہے۔ ماہانہ رقم مقرر کر کے اضافی چارجز سے بچنا، جس میں منتقلی کا کوئی نظام نہیں، Flat rate ہے۔ درجہ وار ڈھانچہ جس میں استعمال بڑھنے کے ساتھ فی یونٹ قیمت کم ہو، Pay less by using more ہے۔ کسی عہد کے بغیر کسی بھی وقت روک سکنا Pay-as-you-go کی خصوصیت ہے، جو عہد پر مبنی اس اصول کے بالکل برعکس بنیاد رکھتا ہے۔

اگست 2026 تک، امتحانی رہنما کتابچوں (試験ガイド) کی سرکاری فہرست میں Foundational سطح پر دو سرٹیفکیشنز رکھے گئے ہیں: AWS Certified Cloud Practitioner (CLF-C02) اور AWS Certified AI Practitioner (AIF-C01)۔ Developer - Associate (DVA-C02) اور Data Engineer - Associate (DEA-C01) دونوں Associate سطح کے ہیں، اور Advanced Networking - Specialty (ANS-C01) سطح Specialty کا ہے۔ جن سرٹیفکیشنز کے نام کے آخر میں سطح کا نام ہو، ان کے لیے یہ ایک مفید اشارہ ہے، لیکن Cloud Practitioner اور AI Practitioner کے ساتھ سطح کا نام نہیں لگا، اس لیے یاد رکھیں کہ یہی دو Foundational ہیں۔

CLF-C02، AWS Certified Cloud Practitioner کا امتحانی کوڈ (試験コード) ہے۔ CLF کا مطلب Cloud Practitioner ہے، اور آخر میں C02 نظرِ ثانی کی نسل (ورژن) کو ظاہر کرتا ہے۔ AWS Certified AI Practitioner کا کوڈ AIF-C01 ہے، AWS Certified Developer - Associate کا DVA-C02، اور AWS Certified Data Engineer - Associate کا DEA-C01۔ سرٹیفکیشنز کے نام کبھی کبھار بدل دیے جاتے ہیں، لیکن امتحانی کوڈ نظرِ ثانی ہونے تک نہیں بدلتا، اس لیے یہ جانچنے کا قابلِ اعتماد طریقہ کہ مطالعے کا مواد موجودہ ہے یا نہیں، کوڈ کو چیک کرنا ہے۔

AWS Certified Solutions Architect - Professional کا امتحانی کوڈ (試験コード) SAP-C02 ہے۔ SAA-C03 اسی Solutions Architect شعبے کی Associate سطح ہے، SOA-C03، CloudOps Engineer - Associate ہے، اور SCS-C03، Security - Specialty ہے۔ پہلے تین حروف ملتے جلتے ہیں اور الجھن پیدا کر سکتے ہیں، لیکن یہ یاد رکھنا مددگار ہے کہ SAA کا تعلق Associate سے اور SAP کا Professional سے ہے۔

CLF-C02 کی Exam Guide میں Cloud Concepts کا حصہ 24 فیصد، Security and Compliance کا 30 فیصد، Cloud Technology and Services کا 34 فیصد، اور Billing, Pricing, and Support کا 12 فیصد مقرر ہے۔ لہٰذا سب سے بڑا Cloud Technology and Services ہے اور سب سے چھوٹا Billing, Pricing, and Support۔ چونکہ یہ ابتدائی سطح کا سرٹیفکیشن ہے، اس لیے یہ گمان ہو سکتا ہے کہ تصورات کو سب سے زیادہ وزن ملتا ہوگا، لیکن درحقیقت سروسز کے علم کو جانچنے والا ڈومین (ドメイン) سب سے بڑا ہے، اور اس کے بعد سیکیورٹی کا نمبر آتا ہے۔ مطالعے کے وقت کی تقسیم بھی اسی تناسب کے مطابق کرنی چاہیے۔

SAA-C03 کی Exam Guide میں Design Secure Architectures کا حصہ 30 فیصد، Design Resilient Architectures کا 26 فیصد، Design High-Performing Architectures کا 24 فیصد، اور Design Cost-Optimized Architectures کا 20 فیصد مقرر ہے۔ سب سے بڑا حصہ محفوظ آرکیٹیکچر کے ڈیزائن کا ہے۔ چاروں ڈومینز کے نام آسانی سے یاد رکھنے کے لیے انہیں Well-Architected کے ستونوں (柱) سے جوڑ لیں؛ اس سے پتا چلتا ہے کہ ان کی ترتیب سیکیورٹی، قابلِ اعتمادیت، کارکردگی کی استعداد اور لاگت کی بہتری ہے۔

آپریشنز پر مرکوز Associate سرٹیفکیشن کا نام SysOps Administrator سے بدل کر CloudOps Engineer کر دیا گیا، اور اس کا امتحانی کوڈ (試験コード) بھی SOA-C02 سے بدل کر SOA-C03 ہو گیا۔ پرانے کوڈ کا امتحان دینے کا آخری دن 29 ستمبر 2025 تھا، اور نیا کوڈ 30 ستمبر 2025 سے شروع ہوا۔ Data Engineer - Associate اور Machine Learning Engineer - Associate آپریشنز کے شعبے کے جانشین نہیں ہیں؛ یہ بالترتیب ڈیٹا اور ML کے شعبوں میں نئے قائم کیے گئے الگ سرٹیفکیشنز ہیں۔ DevOps Engineer - Professional پہلے سے موجود Professional سطح کا سرٹیفکیشن ہے اور اس کی سطح بھی مختلف ہے۔

AWS اپنی ذمہ داری کو سرکاری طور پر "Security of the Cloud" کہتا ہے، اور اس کی تعریف یوں کرتا ہے: AWS Cloud میں پیش کی جانے والی تمام سروسز کو چلانے والے انفراسٹرکچر کا تحفظ — یعنی ہارڈویئر، سافٹ ویئر، نیٹ ورکنگ اور سہولیات (施設)۔ کسی انسٹینس پر انسٹال کی گئی ایپلیکیشن کی کمزوریوں کا تدارک EC2 منتخب کرنے کی صورت میں صارف (利用者) کی ذمہ داری ہے۔ ڈیٹا انکرپشن کے آپشنز کا انتخاب اور IAM کے ذریعے اجازتیں دینا، خواہ کوئی بھی سروس منتخب کی جائے، صارف ہی کے کام رہتے ہیں، اور دونوں "Security in the Cloud" کی طرف آتے ہیں۔

AWS واضح طور پر کہتا ہے کہ "صارف کی ذمہ داری اس بات سے طے ہوگی کہ صارف کون سی AWS Cloud سروسز منتخب کرتا ہے"۔ اس کا مطلب یہ ہے کہ اپنی سیکیورٹی ذمہ داری کے حصے کے طور پر صارف کو کتنا کنفیگریشن کا کام کرنا ہوگا، یہ منتخب کردہ سروس کے مطابق بدلتا ہے۔ سپورٹ پلان (サポートプラン) یہ طے کرتا ہے کہ تکنیکی مدد کیسے ملے گی، اور یہ ذمہ داری کی حد کو نہیں ہلاتا۔ Region اور Availability Zone کا تعلق جگہ کے تعین سے ہے، اور استعمال کی مدت یا خرچ کا تعلق بلنگ سے — ان میں سے کوئی بھی ذمہ داری کی وسعت طے نہیں کرتا۔

AWS سرکاری طور پر کہتا ہے کہ EC2 جیسی سروسز میں، جن میں کنفیگریشن درکار ہوتی ہے، صارف "گیسٹ آپریٹنگ سسٹم (اپ ڈیٹس اور سیکیورٹی پیچز سمیت)، انسٹینسز پر انسٹال کیے گئے کسی بھی ایپلیکیشن سافٹ ویئر یا یوٹیلیٹیز، اور سیکیورٹی گروپس کی کنفیگریشن" کا انتظام کرتا ہے۔ لہٰذا OS پر پیچز لگانا (パッチの適用) صارف کی ذمہ داری ہے۔ EC2 میں AWS جو کچھ چلاتا ہے وہ صرف فزیکل انفراسٹرکچر اور ورچوئلائزیشن کی تہہ تک ہے، انسٹینس کے اندر کا OS اس میں شامل نہیں۔ سپورٹ پلان تکنیکی مدد حاصل کرنے کا معاہدہ ہے اور اس سے ذمہ داری کا مقام منتقل نہیں ہوتا۔

تجریدی یا مینیجڈ (マネージド) سروسز کے بارے میں AWS کہتا ہے کہ "AWS انفراسٹرکچر کی تہہ، آپریٹنگ سسٹم اور پلیٹ فارمز چلاتا ہے، اور صارفین ڈیٹا محفوظ کرنے اور حاصل کرنے کے لیے اینڈ پوائنٹس تک رسائی حاصل کرتے ہیں"۔ صارف کے ذمے جو باقی رہتا ہے وہ اپنے ڈیٹا کا انتظام (انکرپشن کے آپشنز سمیت)، اثاثوں کی درجہ بندی، اور IAM ٹولز کے ذریعے مناسب اجازتوں کا اطلاق ہے۔ صارف نہ OS کی اپ ڈیٹس کرتا ہے نہ پلیٹ فارم چلاتا ہے، لیکن ڈیٹا کی درجہ بندی اور اجازتوں کی ترتیبات، سروس کوئی بھی ہو، کبھی صارف کے ہاتھ سے نہیں نکلتیں۔

مشترکہ ذمہ داری کے ماڈل (責任共有モデル) کی حد مقرر نہیں ہے؛ یہ منتخب کردہ سروس کے مطابق بدلتی ہے۔ EC2 جیسی سروس میں، جہاں گیسٹ OS کا انتظام صارف کرتا ہے، پیچنگ صارف کی ذمہ داری ہے، لیکن S3 یا DynamoDB جیسی سروس میں، جہاں AWS، OS اور پلیٹ فارم تک سب کچھ چلاتا ہے، یہ AWS کی ذمہ داری بن جاتی ہے۔ لہٰذا نہ "ہمیشہ AWS" درست ہے نہ "ہمیشہ صارف"۔ Region جگہ کا انتخاب ہے اور اس سے ذمہ داری کی تقسیم نہیں بدلتی۔ یہ ایک نکتہ ذہن میں رکھیں تو کسی نئی سروس کے لیے بھی صرف یہ سوچ کر حد کا اندازہ لگا سکتے ہیں کہ وہ EC2 کی طرف جھکی ہوئی ہے یا S3 کی طرف۔

سہولیات کو AWS Cloud سروسز چلانے والے انفراسٹرکچر کے حصے کے طور پر واضح طور پر "Security of the Cloud" کے تحت درج کیا گیا ہے، اس لیے کوئی بھی سروس استعمال ہو، یہ ہمیشہ AWS کی ذمہ داری ہیں۔ صارفین اس دائرے کا خود آڈٹ نہیں کر سکتے اور نہ سہولیات میں داخل ہو کر معائنہ کر سکتے ہیں؛ اس کے بجائے وہ AWS کی شائع کردہ تیسرے فریق کی سرٹیفکیشنز (第三者認証) اور آڈٹ رپورٹس کے ذریعے اس کی تصدیق کرتے ہیں۔ یہ تین کنٹرول کی درجہ بندیوں میں سے Inherited Controls (継承されるコントロール) نامی زمرے سے مطابقت رکھتا ہے — یعنی وہ حصہ جو صارفین مکمل طور پر AWS سے وراثت میں لیتے ہیں۔ منتخب کردہ سروس کے مطابق جو چیز بدلتی ہے وہ OS اور مڈل ویئر کی تہہ ہے، فزیکل تہہ نہیں۔

AWS واضح طور پر کہتا ہے کہ اپنے ڈیٹا کا انتظام (انکرپشن کے آپشنز سمیت)، اثاثوں کی درجہ بندی، اور IAM ٹولز کے ذریعے مناسب اجازتوں کا اطلاق، تجریدی سروسز استعمال کرتے وقت بھی صارف ہی کے ذمے رہتے ہیں۔ چونکہ یہ منتخب کردہ سروس سے قطع نظر کبھی صارف سے الگ نہیں ہوتے، اس لیے حد کہاں ہے یہ سوچتے وقت یہ ایک مقررہ نقطے (固定点) کا کام دیتے ہیں۔ فزیکل سرور کی تبدیلی اور بیک بون نیٹ ورک کا تحفظ سہولیات اور ہارڈویئر کے معاملات ہیں، اور ہمیشہ AWS کی طرف ہوتے ہیں۔ مینیجڈ سروس کا بنیادی OS، AWS چلاتا ہے، اس لیے اس پر پیچز لگانا صارف کا کام نہیں۔

Inherited Controls (継承されるコントロール) کی سرکاری تعریف یہ ہے کہ یہ وہ کنٹرولز ہیں جو صارف مکمل طور پر AWS سے وراثت میں لیتا ہے، اور فزیکل اور ماحولیاتی کنٹرولز اسی زمرے میں آتے ہیں۔ جو کنٹرولز انفراسٹرکچر کی تہہ اور صارف کی تہہ دونوں پر الگ الگ لاگو ہوتے ہیں وہ Shared Controls ہیں، اور جو مکمل طور پر صارف کی ذمہ داری ہیں، جیسے سروس اور زون کی سیکیورٹی، وہ Customer Specific Controls ہیں۔ وراثت ایک ہی سمت میں، AWS سے صارف کی طرف، بہتی ہے؛ یہ ایسا تعلق نہیں جس میں AWS صارف کی اپنی ترتیبات کو آگے بڑھائے۔

AWS، Shared Controls (共有コントロール) کی تین مثالیں دیتا ہے: Patch Management (پیچ کا انتظام)، Configuration Management (کنفیگریشن کا انتظام)، اور Awareness & Training (آگاہی اور تربیت)۔ ان میں مشترک بات یہ ہے کہ ایک ہی سرگرمی انفراسٹرکچر کی تہہ اور صارف کی تہہ دونوں پر متوازی طور پر انجام دی جاتی ہے — مثلاً پیچ کے انتظام میں AWS اپنے انفراسٹرکچر پر پیچز لگاتا ہے جبکہ صارف الگ سے گیسٹ OS اور ایپلیکیشنز پر انہیں لگاتا ہے۔ داخلے/اخراج کے کنٹرول، بجلی کی متبادل فراہمی، اور ہارڈویئر کی خریداری اور تلفی فزیکل اور ماحولیاتی کنٹرولز ہیں، جو صارف AWS سے وراثت میں لیتا ہے۔ سروس اور زون کی سیکیورٹی Customer Specific Controls کی مثال ہے۔

DynamoDB ایک تجریدی سروس ہے، اس لیے AWS انفراسٹرکچر کی تہہ، OS اور پلیٹ فارم تک سب کچھ چلاتا ہے۔ گیسٹ OS کی پیچنگ (ゲストOSのパッチ適用)، جو EC2 میں صارف سنبھالتا تھا، منتقلی کے بعد AWS کا کام بن جاتی ہے۔ دوسری طرف، ڈیٹا کی درجہ بندی، انکرپشن کے آپشنز کا انتخاب، اور IAM کے ذریعے اجازتیں دینا، خواہ کوئی بھی سروس منتخب کی جائے، صارف ہی کے پاس رہتے ہیں۔ فزیکل سہولت کا تحفظ پہلے ہی ہمیشہ AWS کی ذمہ داری ہے، اس لیے منتقلی سے یہ کبھی صارف کو منتقل نہیں ہوتا۔ اسے یوں ترتیب دینا مددگار ہے: جو بدلتا ہے وہ OS/پلیٹ فارم کی تہہ ہے، اور جو نہیں بدلتا وہ ڈیٹا اور اجازتیں ہیں۔

موجودہ ستون چھ ہیں: آپریشنل برتری، سیکیورٹی، قابلِ اعتمادیت، کارکردگی کی استعداد، لاگت کی بہتری اور پائیداری۔ پائیداری (持続可能性) کو 2021 میں چھٹے ستون کے طور پر شامل کیا گیا، اس لیے اس کے بغیر صرف پانچ ستونوں کی فہرست اضافے سے پہلے کی پرانی معلومات کی عکاسی کرتی ہے۔ باہمی مطابقت (Interoperability) اور منتقلی پذیری (Portability) فریم ورک کے ستونوں میں شامل نہیں؛ دونوں میں سے کوئی بھی سرکاری فہرست میں موجود نہیں۔ جس وضاحت میں ستونوں کی تعداد پرانی ہو، اس میں سروسز کے نام یا امتحانی کوڈز بھی پرانے ہونے کا امکان ہے، اس لیے یہ اس بات کی علامت بن سکتی ہے کہ مطالعے کا کوئی مواد کتنا تازہ ہے۔

آپریشنل برتری (運用上の優秀性) وہ ستون ہے جو سسٹمز کو چلانے اور ان کی نگرانی، اور عمل اور طریقۂ کار میں مسلسل بہتری پر توجہ دیتا ہے۔ اس میں ڈیپلائمنٹ کو خودکار بنانا، کسی واقعے کے بعد کے جائزوں کی بنیاد پر طریقۂ کار کو اپ ڈیٹ کرنا، اور تبدیلیاں چھوٹے اور بار بار کے مراحل میں کرنا شامل ہے۔ معلومات اور سسٹمز کا تحفظ سیکیورٹی ہے؛ وسائل کی تقسیم کو بہتر بنانا اور وسائل کی اقسام کا انتخاب کارکردگی کی استعداد ہے؛ اور فضول خرچ کو ختم کرنا اور وسائل کو مناسب سائز دینا لاگت کی بہتری ہے — یہ سب مختلف ستونوں کی طرف اشارہ کرتے ہیں۔

سیکیورٹی کا ستون معلومات اور سسٹمز کے تحفظ پر توجہ دیتا ہے، جس کا مرکز ڈیٹا کی سالمیت اور رسائی کا کنٹرول ہے۔ انکرپشن اور کم سے کم اختیار (最小権限) پر مبنی رسائی کا کنٹرول براہِ راست اسی کے تحت آتے ہیں۔ غیر استعمال شدہ وسائل کو بند کرنا اور انسٹینسز کو مناسب سائز دینا لاگت کی بہتری ہے؛ ڈیپلائمنٹ کو خودکار بنانا اور واقعات کے جائزوں کے بعد رن بُکس کو اپ ڈیٹ کرنا آپریشنل برتری ہے؛ اور ماحولیاتی اثرات کی پیمائش اور ان میں کمی پائیداری ہے۔ مشترکہ ذمہ داری کے ماڈل (責任共有モデル) میں جو کچھ صارف کی ذمہ داری کے طور پر باقی رہتا ہے، اس کا بیشتر حصہ اسی سیکیورٹی کے ستون میں نمٹایا جاتا ہے۔

قابلِ اعتمادیت (信頼性) وہ ستون ہے جو اس بات پر توجہ دیتا ہے کہ ورک لوڈ اپنا مطلوبہ کام انجام دے اور خرابی سے کتنی جلدی بحال ہو۔ متعدد Availability Zones میں تقسیم، خودکار بحالی، اور بیک اپ اور بحالی کے طریقۂ کار کی تصدیق یہاں آتے ہیں۔ اس کی امتیازی خصوصیت یہ ہے کہ یہ صرف ٹوٹ پھوٹ کو روکنے کا احاطہ نہیں کرتا بلکہ کچھ ٹوٹ جانے کے بعد جلد بحال ہونے کا بھی احاطہ کرتا ہے۔ وسائل کی تقسیم کو بہتر بنانا کارکردگی کی استعداد ہے؛ چلانا، نگرانی، اور طریقۂ کار میں مسلسل بہتری آپریشنل برتری ہے؛ اور ماحولیاتی اثرات کو کم سے کم کرنا پائیداری ہے۔

کارکردگی کی استعداد (パフォーマンス効率) وہ ستون ہے جو IT وسائل کی تقسیم کو بہتر بنانے اور ورک لوڈ کی ضروریات کے مطابق وسائل کی قسم کے انتخاب پر توجہ دیتا ہے۔ کسی ضرورت کو پورا کرنے کے لیے وسائل کی قسم دوبارہ منتخب کرنا براہِ راست اسی کے تحت آتا ہے۔ لاگت کی بہتری بھی ملتی جلتی سرگرمی لگ سکتی ہے، لیکن اس کا مقصد فضول خرچ کو ختم کرنا ہے، جبکہ یہاں محرک لیٹنسی (レイテンシ) کی ضرورت پوری کرنا ہے، اس لیے توجہ کا مرکز مختلف ہے۔ قابلِ اعتمادیت خرابی کے مقابلے کی صلاحیت کو دیکھتا ہے اور آپریشنل برتری طریقۂ کار کی بہتری کو — ان میں سے کوئی بھی یہاں بنیادی توجہ نہیں۔

لاگت کی بہتری (コスト最適化) وہ ستون ہے جو فضول خرچ کو ختم کرنے اور کاروباری ضروریات کے مقابلے میں وسائل کو مناسب سائز دینے پر توجہ دیتا ہے۔ غیر استعمال شدہ وسائل کو بند کرنا، ضرورت سے بڑے انسٹینسز کو درست کرنا، اور مناسب قیمتوں کے ماڈلز کا انتخاب جیسے فیصلے یہاں آتے ہیں۔ اصل نکتہ صرف لاگت کو کم سے کم کرنا نہیں بلکہ یہ پوچھنا ہے کہ کیا خرچ کے برابر قدر حاصل ہو رہی ہے۔ معلومات اور سسٹمز کا تحفظ سیکیورٹی ہے؛ مطلوبہ کام انجام دینا اور بحال ہونا قابلِ اعتمادیت ہے؛ اور ماحولیاتی اثرات کو کم سے کم کرنا پائیداری ہے۔

پائیداری (持続可能性) وہ ستون ہے جو کلاؤڈ ورک لوڈ چلانے کے ماحولیاتی اثرات کو کم سے کم کرنے پر توجہ دیتا ہے۔ یہ سب سے نیا ستون ہے، جسے 2021 میں چھٹے ستون کے طور پر شامل کیا گیا، اور اس کی موجودگی یا عدم موجودگی موجودہ اور پرانے مطالعاتی مواد کے درمیان حدِ فاصل ہے۔ وسائل کی تقسیم کو بہتر بنانا اور وسائل کی اقسام کا انتخاب کارکردگی کی استعداد ہے؛ چلانا، نگرانی اور طریقۂ کار میں مسلسل بہتری آپریشنل برتری ہے؛ اور مطلوبہ کام انجام دینا اور خرابی سے بحال ہونا قابلِ اعتمادیت ہے — یہ سب مختلف ستونوں کی طرف اشارہ کرتے ہیں۔

غائب ستون پائیداری (持続可能性) ہے، یعنی وہ ستون جو کلاؤڈ ورک لوڈ چلانے کے ماحولیاتی اثرات کو کم سے کم کرنے کا احاطہ کرتا ہے۔ چونکہ اسے 2021 میں چھٹے ستون کے طور پر شامل کیا گیا، اس لیے اس سے پہلے لکھے گئے مضامین میں اب بھی صرف پانچ ستون درج ہیں۔ آپریشنل برتری، کارکردگی کی استعداد اور قابلِ اعتمادیت سب اضافے سے پہلے موجود تھے، اس لیے یہ پانچ ستونوں والے مضمون میں بھی نظر آتے ہیں۔ جب کسی مضمون میں ستونوں کی تعداد جیسی بنیادی بات پرانی ہو، تو اس کا باقی مواد بھی پرانا ہونے کا امکان ہوتا ہے۔

موجودہ ستون چھ ہیں: آپریشنل برتری، سیکیورٹی، قابلِ اعتمادیت، کارکردگی کی استعداد، لاگت کی بہتری اور پائیداری، اور باہمی مطابقت (相互運用性) اس فہرست میں شامل نہیں۔ مختلف سسٹمز کا ایک دوسرے سے جڑ سکنا ڈیزائن کا ایک اہم پہلو ہے، لیکن Well-Architected Framework اسے الگ ستون کے طور پر قائم نہیں کرتا۔ لاگت کی بہتری، آپریشنل برتری اور کارکردگی کی استعداد سب چھ ستونوں کے حقیقی ارکان ہیں۔ فریم ورک میں موجود نہ ہونے والی اصطلاح کو ستون سمجھ کر یاد کر لینا جوابات کے انتخاب کو محدود کرتے وقت الجھن کا سبب بنتا ہے۔

فضول خرچ کو ختم کرنا اور کاروباری ضروریات کے مقابلے میں وسائل کو مناسب سائز دینا لاگت کی بہتری (コスト最適化) کی توجہ کا مرکز ہے، قابلِ اعتمادیت (信頼性) کا نہیں۔ قابلِ اعتمادیت وہ ستون ہے جو اس بات پر توجہ دیتا ہے کہ ورک لوڈ اپنا مطلوبہ کام انجام دے اور خرابی سے کتنی جلدی بحال ہو۔ باقی تین جوڑے سرکاری وضاحتوں سے مطابقت رکھتے ہیں۔ چونکہ ستونوں کے نام روزمرہ الفاظ سے ملتے جلتے ہیں، اس لیے صرف تاثر کی بنیاد پر جوڑنے سے غلطیاں ہوتی ہیں؛ انہیں ان کی توجہ کے مرکز کی ایک جملے کی وضاحت کے ساتھ یاد کرنے سے اس قسم کے سوال میں ٹھوکر نہیں لگتی۔

Region (リージョン) دنیا میں وہ فزیکل مقام ہے جہاں AWS کے متعدد Availability Zones ہوتے ہیں۔ Regions کے نام us-east-1 یا ap-northeast-1 جیسے ہوتے ہیں، اور ان کا انتخاب ڈیٹا کے مقام اور قانونی ضوابط کی ضروریات، صارفین سے فاصلے، اور قیمتوں کو دیکھ کر کیا جاتا ہے۔ ایک یا زیادہ الگ الگ ڈیٹا سینٹرز پر مشتمل خرابیوں کو الگ تھلگ رکھنے کی اکائی Availability Zone (アベイラビリティゾーン) کی وضاحت ہے۔ وہ مقام جہاں CloudFront مواد کو کیش کر کے فراہم کرتا ہے ایج لوکیشن (エッジロケーション) ہے، اور ٹیلی کام کیریئر کے نیٹ ورک کے اندر رکھا گیا زون Wavelength Zone ہے۔

Availability Zone (アベイラビリティゾーン) کی تعریف یہ ہے کہ یہ ایک یا زیادہ الگ الگ ڈیٹا سینٹرز پر مشتمل ہوتا ہے، جن میں سے ہر ایک میں بجلی، نیٹ ورکنگ اور کنیکٹیویٹی کا متبادل (redundant) انتظام ہوتا ہے، اور یہ علیحدہ سہولیات میں واقع ہوتے ہیں۔ اہم نکات یہ ہیں کہ یہ کسی ایک ڈیٹا سینٹر کی عمارت کے برابر نہیں بلکہ ایک مجموعہ ہے، اور یہ دوسرے زونز سے الگ عمارت میں ہوتا ہے۔ ایج لوکیشن اور اوریجن کے درمیان کی درمیانی تہہ ریجنل ایج کیش (リージョナルエッジキャッシュ) ہے، اور صارف کے شہر کے قریب ایپلیکیشنز چلانے کی جگہ Local Zones کی وضاحت ہے — دونوں مختلف نظاموں کی طرف اشارہ کرتے ہیں۔

AWS سرکاری طور پر کہتا ہے کہ ہر Region "کم از کم تین، الگ تھلگ، اور فزیکل طور پر علیحدہ Availability Zones (アベイラビリティゾーン)" پر مشتمل ہوتا ہے۔ چونکہ Regions اور زونز کی کل تعداد مسلسل بڑھ رہی ہے، اس لیے یہ کل تعداد یاد کرنے کا فائدہ محدود ہے، لیکن یہ اصول کہ ایک Region میں کم از کم کتنے زون ہوتے ہیں، مستحکم ہے اور اسے براہِ راست ڈیزائن کی بنیاد کے طور پر استعمال کیا جا سکتا ہے۔ ایک ہی سہولت کے اندر واقع ہونا علیحدہ سہولیات میں واقع ہونے کی تعریف سے متصادم ہے۔ زونز ایسی چیز نہیں جن کی صارفین درخواست دے کر تعداد بڑھائیں، اور نہ ہی ہر Region میں صرف ایک زون ہوتا ہے۔

ایج لوکیشنز (エッジロケーション) ڈیٹا سینٹرز کا وہ عالمگیر نیٹ ورک ہیں جہاں سے CloudFront مواد فراہم کرتا ہے۔ درخواستیں سب سے کم لیٹنسی (レイテンシ) والی ایج لوکیشن کی طرف روٹ کی جاتی ہیں، اور وہیں سے فراہمی ہوتی ہے۔ اہم نکتہ یہ ہے کہ یہ دستیابی بڑھانے کے لیے متبادل انتظام کی اکائی نہیں، بلکہ مواد کو صارف کے قریب سے دوبارہ فراہم کرنے کے لیے کیش کا مقام ہے۔ خرابیوں کو الگ تھلگ رکھنا Availability Zone کا کردار ہے، IP ایڈریس رینجز کو تقسیم کرنا سب نیٹ کا کردار ہے، اور کیریئر کی سہولیات کے اندر ایپلیکیشنز چلانا Wavelength Zones کا کردار ہے۔

درخواست سب سے کم لیٹنسی والی ایج لوکیشن (エッジロケーション) کی طرف روٹ کی جاتی ہے، اور اگر مواد پہلے سے وہاں موجود ہو تو فوراً فراہم کر دیا جاتا ہے۔ اگر نہ ہو، تو اسے اوریجن (オリジン) — جیسے S3 بکٹ یا HTTP سرور — سے حاصل کر کے فراہم کیا جاتا ہے، اور ساتھ ہی کیش میں بھی محفوظ کر لیا جاتا ہے۔ اسی لیے بعد کی درخواستیں براہِ راست قریبی مقام سے واپس کی جا سکتی ہیں۔ کیش میں اندراج نہ ہونا نہ ایرر بنتا ہے، نہ صارف کو انتظار میں چھوڑا جاتا ہے۔ کسی Availability Zone کی طرف بھیجنا خرابیوں کو الگ تھلگ رکھنے کا نظام ہے اور مواد کی فراہمی کے عمل سے اس کا کوئی تعلق نہیں۔

ریجنل ایج کیش (リージョナルエッジキャッシュ) ایج لوکیشن اور اوریجن کے درمیان واقع کیش کی ایک تہہ ہے۔ اس کا کام یہ ہے کہ جب مواد ایج پر نہ ملے تو درخواست کو اوریجن تک واپس جانے کی تعداد کم کی جائے۔ Availability Zones کو گروپ کرنے والی انتظامی اکائی Region ہے، اور ٹیلی کام کیریئر کے نیٹ ورک کے اندر رکھے گئے زونز Wavelength Zones ہیں — دونوں مختلف تصورات ہیں۔ صارف کے اپنے آلے پر کیشنگ AWS کا نظام نہیں بلکہ براؤزر یا OS کی خصوصیت ہے۔

Availability Zone (アベイラビリティゾーン) خرابیوں کو الگ تھلگ رکھنے کی ایک اکائی ہے جو علیحدہ سہولت میں واقع ہوتی ہے اور جس میں بجلی اور نیٹ ورکنگ کا متبادل انتظام ہوتا ہے۔ ایک ہی کردار کے وسائل کو متعدد زونز میں رکھنے کا مطلب یہ ہے کہ اگر ایک زون مکمل طور پر بند ہو جائے تب بھی باقی زونز کام جاری رکھ سکتے ہیں۔ یہ Multi-AZ ترتیب (マルチAZ構成) ہے اور دستیابی (可用性) کے ڈیزائن کا نقطۂ آغاز ہے۔ قریب ترین مقام سے فراہمی ایج لوکیشن کا کردار ہے؛ ڈیٹا کا مقام Region کے انتخاب کا ایک عنصر ہے؛ اور استعمال کے عہد کے ذریعے فی یونٹ قیمت کم کرنا قیمتوں کا معاملہ ہے — ان میں سے کوئی بھی زونز میں تقسیم کا محرک نہیں۔

Local Zones ایک ایسا نظام ہے جو ایپلیکیشنز کو آخری صارفین یا ورک لوڈز کے زیادہ قریب AWS انفراسٹرکچر پر چلانے دیتا ہے، اور یہ Region سے دور کے شہروں میں رکھے جاتے ہیں۔ "قریب" سے تعلق رکھنے میں یہ ایج لوکیشنز (エッジロケーション) سے ملتے جلتے ہیں، لیکن فرق یہ ہے کہ یہ مواد کی فراہمی کی کیش بننے کے بجائے خود ایپلیکیشن کو چلاتے ہیں۔ Region کے اندر خرابیوں کو الگ تھلگ رکھنا Availability Zone ہے، صرف فراہمی کا مقام ایج لوکیشن ہے، اور اوریجن کے سامنے درمیانی کیش ریجنل ایج کیش ہے۔

Wavelength Zones وہ زونز ہیں جو ٹیلی کمیونیکیشن کیریئر (通信キャリア) کے نیٹ ورک کے اندر رکھے جاتے ہیں۔ Local Zones کی طرح یہ بھی خود ایپلیکیشن کو صارفین کے قریب چلانے کا نظام ہیں، جو مقصد کے لحاظ سے ایج لوکیشن سے مختلف ہے، جو مواد کی کیش کی فراہمی کا مقام ہے۔ ایج لوکیشن اور اوریجن کے درمیان رکھی جانے والی چیز ریجنل ایج کیش ہے؛ Region کے اندر خرابیوں کو الگ تھلگ رکھنے کی اکائی Availability Zone ہے؛ اور VPC کی IP ایڈریس رینج کو تقسیم کرنا سب نیٹ (サブネット) ہے۔

Availability Zone (アベイラビリティゾーン) علیحدہ سہولت میں واقع خرابیوں کو الگ تھلگ رکھنے کی اکائی ہے، اس لیے پورے زون کے بند ہو جانے کی تیاری کے لیے وسائل کو مختلف زونز میں رکھنا ضروری ہے۔ چونکہ ہر Region کم از کم تین الگ تھلگ زونز پر مشتمل ہوتا ہے، اس لیے ایک ہی Region کے اندر متعدد زونز میں تقسیم ممکن ہے۔ اسی زون کے اندر مزید سرورز شامل کرنا ضرورت پوری نہیں کرتا، کیونکہ اگر وہ زون بند ہو جائے تو سب ایک ساتھ بند ہو جائیں گے۔ CloudFront فراہمی کو تیز کرتا ہے، لیکن اگر اوریجن رک جائے تو متحرک (dynamic) پروسیسنگ جاری نہیں رہ سکتی۔ قیمتوں کا پلان بدلنا لاگت کا معاملہ ہے اور دستیابی (可用性) سے اس کا کوئی تعلق نہیں۔