اہم AWS سروسز

EC2 کا پورا نام Amazon Elastic Compute Cloud ہے، جو قابلِ تبدیلی سائز والی کمپیوٹنگ صلاحیت یعنی ورچوئل سرور (仮想サーバー) فراہم کرتا ہے۔ S3 کا پورا نام Amazon Simple Storage Service ہے، جو کسی بھی مقدار کے ڈیٹا کو آبجیکٹ (オブジェクト) کی صورت میں محفوظ کرتا ہے۔ ان دونوں کو آپس میں الٹ دینا ایک پرانی اور عام غلطی ہے، اس لیے مکمل نام کے الفاظ سے کردار یاد کرنا مفید ہے۔ فنکشن کا کوڈ چلانا Lambda کا کام ہے، اور فائلیں شیئر کرنا EFS کا کام ہے۔

Lambda کے ذریعے آپ سرورز کی پروویژننگ یا انتظام کے بغیر کوڈ چلا سکتے ہیں، اور آپ سے صرف اسی کمپیوٹ ٹائم کا معاوضہ (課金) لیا جاتا ہے جو آپ استعمال کرتے ہیں۔ کوڈ نہ چلنے کے دوران کوئی چارج نہیں لگتا؛ یہی EC2 سے بڑا فرق ہے، جہاں انسٹینس جب تک چلتا رہے لاگت بڑھتی رہتی ہے۔ فنکشنز کی تعداد یا اپ لوڈ کیے گئے کوڈ کا سائز بذاتِ خود بلنگ کی اکائی نہیں ہے۔

سرور لیس (サーバーレス) کا مطلب یہ نہیں کہ کوئی طبعی سرور موجود نہیں؛ اس کا مطلب یہ ہے کہ صارف کو سرورز کی پروویژننگ (プロビジョニング)، کنفیگریشن یا اسکیلنگ نہیں کرنی پڑتی۔ Lambda کے بارے میں کہا جاتا ہے کہ وہ “سرورز کی پروویژننگ یا انتظام کے بغیر کوڈ چلانے” دیتا ہے، اور Fargate کے بارے میں کہا جاتا ہے کہ وہ “سرورز یا کلسٹرز کی پروویژننگ، کنفیگریشن یا اسکیلنگ” کی ضرورت ختم کر دیتا ہے۔ طبعی سرور AWS کی جانب موجود ہوتا ہے، اور OS کی قسم یا پیچ پالیسی کا فیصلہ صارف کا کرنا EC2 جیسی صورت کی خصوصیت ہے۔

Fargate کنٹینرز (コンテナ) کے لیے ایک سرور لیس، استعمال کے مطابق ادائیگی (従量課金) والا کمپیوٹ انجن ہے جو سرورز یا کلسٹرز کی پروویژننگ، کنفیگریشن یا اسکیلنگ کی ضرورت ختم کر دیتا ہے، اور اسے ECS یا EKS کی لانچ ٹائپ (起動タイプ) کے طور پر استعمال کیا جاتا ہے۔ Kubernetes کا منیجڈ آپریشن EKS ہے؛ انسٹینس ٹائپ اور تعداد خود منتخب کرنا EC2 لانچ ٹائپ ہے؛ اور مراحل کو ورک فلو کے طور پر متعین کرنا Step Functions ہے۔

ECS کی گنجائش (キャパシティ) کے بنیادی انتخاب دو ہیں: Fargate، جو سرور لیس ہے اور جس میں بنیادی کمپیوٹ کا انتظام AWS کرتا ہے، اور EC2، جس میں انسٹینس ٹائپ اور تعداد صارف منتخب کرتا اور ان کا انتظام کرتا ہے۔ ان کے علاوہ ECS Managed Instances، اور آن پریمیسز (オンプレミス) کے لیے ECS Anywhere بھی موجود ہیں۔ آپ جو بھی منتخب کریں، کنٹینرز کو رکھنے اور اسکیل کرنے والی سروس ECS ہی ہے؛ فرق صرف یہ ہے کہ بنیادی کمپیوٹ کی دیکھ بھال کون کرتا ہے۔

EKS کا پورا نام Amazon Elastic Kubernetes Service ہے؛ یہ ایک منیجڈ سروس (マネージドサービス) ہے جس کے ذریعے آپ Kubernetes کلسٹر خود انسٹال کیے اور چلائے بغیر AWS پر Kubernetes چلا سکتے ہیں، اور اسے Kubernetes کے مطابق ہونے (Kubernetes 準拠) کی سند حاصل ہے۔ ڈیٹا بیس کے آپریشنز کو خود کار بنانا RDS کا کام ہے، قریب کی جگہ سے مواد پہنچانا CloudFront کا کام ہے، اور ٹریفک تقسیم کرنا Elastic Load Balancing کا کام ہے۔

Lambda کے ذریعے سرور کے انتظام کے بغیر کوڈ چلایا جا سکتا ہے، صرف استعمال شدہ کمپیوٹ ٹائم کا معاوضہ (課金) لیا جاتا ہے، اور نہ چلنے کے دوران کوئی چارج نہیں لگتا۔ اس لیے کبھی کبھار شروع ہونے والی پروسیسنگ کے لیے Lambda فائدہ مند ہے، کیونکہ انتظار کے فارغ وقت میں کوئی لاگت نہیں آتی۔ EC2 انسٹینس یا EKS کلسٹر کو مسلسل چلانے والی ترتیبوں میں اس طویل وقت کی لاگت بھی آتی رہتی ہے جب کوئی پروسیسنگ نہیں ہو رہی ہوتی۔

EC2 کی سرکاری وضاحت یہ ہے کہ یہ کلاؤڈ میں محفوظ اور قابلِ تبدیلی سائز والی کمپیوٹنگ صلاحیت فراہم کرنے والی سروس ہے، جس میں آپ صرف استعمال کے مطابق ادائیگی کرتے ہیں اور کمپیوٹ ریسورس (コンピューティングリソース) پر مکمل کنٹرول رکھتے ہیں۔ صرف چلنے کے وقت کا معاوضہ اور OS کو کبھی نہ چھونا Lambda کی وضاحت ہے، ڈیٹا کو آبجیکٹس کی صورت میں محفوظ کرنا S3 کی، اور ورک فلو کو اسٹیٹس کے طور پر متعین کرنا Step Functions کی۔ اتنے وسیع کنٹرول کے بدلے OS کا انتظام صارف کے ذمے رہتا ہے؛ یہ بات بھی ساتھ یاد رکھنی چاہیے۔

ECS کا پورا نام Amazon Elastic Container Service ہے؛ یہ ایک مکمل منیجڈ کنٹینر آرکیسٹریشن سروس (コンテナオーケストレーションサービス) ہے جو کنٹینرائزڈ ایپلیکیشنز کو ڈیپلائے، منظم اور اسکیل کرنا آسان بناتی ہے۔ Kubernetes کے مطابق کلسٹر فراہم کرنا EKS کا کام ہے، ورچوئل سرور انسٹینسز لانچ کرنا EC2 کا کام ہے، اور ایونٹس کے جواب میں کوڈ چلانا Lambda کا کام ہے۔ ECS اور EKS دونوں کنٹینرز کو یکجا کرتے ہیں، لیکن ان کا فرق اس بات پر ہے کہ Kubernetes استعمال ہوتا ہے یا نہیں۔

EKS ایک منیجڈ سروس ہے جس کے ذریعے آپ Kubernetes کلسٹر خود انسٹال کیے اور چلائے بغیر AWS پر Kubernetes چلا سکتے ہیں، اور اسے Kubernetes کے مطابق ہونے (Kubernetes 準拠) کی سند حاصل ہے۔ دوسری طرف ECS، AWS کی اپنی مکمل منیجڈ کنٹینر آرکیسٹریشن سروس (コンテナオーケストレーションサービス) ہے جو Kubernetes پر انحصار نہیں کرتی۔ دونوں کنٹینرز سنبھالنے والی سروسز ہیں، صرف ورچوئل سرور امیجز تک محدود نہیں۔ لانچ کی جگہ کے طور پر دونوں Fargate بھی استعمال کر سکتے ہیں۔

EBS، EC2 انسٹینسز کے ساتھ استعمال ہونے والا مستقل بلاک اسٹوریج (ブロックストレージ) والیوم ہے، جو ایک Availability Zone (アベイラビリティゾーン) کے اندر خود کار طور پر ریپلیکیٹ ہوتا ہے، اور اصولاً ایک ہی انسٹینس سے منسلک (attach) کر کے استعمال کیا جاتا ہے۔ EFS، Linux ورک لوڈز کے لیے فائل سسٹم (ファイルシステム) ہے جو خود کار طور پر بڑھتا اور گھٹتا ہے اور ہزاروں EC2 انسٹینسز سے بیک وقت مشترکہ رسائی کی سہولت دیتا ہے۔ شیئرنگ EFS کی صلاحیت ہے؛ ایسا نہیں کہ دونوں شیئرنگ کے لیے ہوں، یا دونوں صرف ایک کنکشن کے لیے مخصوص ہوں۔

S3 کا پورا نام Amazon Simple Storage Service ہے؛ یہ بہترین اسکیل ایبلٹی اور دستیابی والا آبجیکٹ اسٹوریج (オブジェクトストレージ) ہے جو کسی بھی مقدار کے ڈیٹا کو ذخیرہ کر سکتا ہے اور اس کی حفاظت کر سکتا ہے۔ بلاک اسٹوریج EBS ہے، Linux کے لیے مشترکہ فائل سسٹم EFS ہے، اور ان میموری کیش ElastiCache ہے۔ ڈیٹا رکھنے کے ان تین طریقوں — آبجیکٹ، بلاک اور فائل — کا فرق AWS اسٹوریج کے انتخاب کا نقطۂ آغاز ہے۔

EFS ایسا فائل اسٹوریج ہے جس کی گنجائش فائلوں کی تعداد کے مطابق خود کار طور پر بڑھتی اور گھٹتی ہے اور جو ہزاروں EC2 انسٹینسز سے بیک وقت مشترکہ رسائی کی سہولت دیتا ہے، اس لیے یہ بہت سے انسٹینسز سے ایک ہی ڈائریکٹری کو بیک وقت ماؤنٹ (マウント) کرنے کے استعمال کے لیے موزوں ہے۔ EBS ایک Availability Zone کے اندر بلاک اسٹوریج ہے جو اصولاً ایک ہی انسٹینس سے منسلک ہوتا ہے، اس لیے ہر انسٹینس کو اپنا الگ حصہ ملتا ہے۔ Glacier Deep Archive آرکائیو کی ایک کلاس ہے جو سست بازیافت کے لیے بنائی گئی ہے، اور ElastiCache فائل سسٹم نہیں بلکہ ان میموری کیش (インメモリキャッシュ) ہے۔

EBS، EC2 انسٹینسز کے لیے مستقل بلاک اسٹوریج ہے، جو ایک Availability Zone (アベイラビリティゾーン) کے اندر خود کار طور پر ریپلیکیٹ (レプリケート) ہوتا ہے اور یکساں، کم لیٹنسی والی کارکردگی فراہم کرتا ہے۔ اس واحد AZ والی خصوصیت کی وجہ سے، اگر AZs کے پار دستیابی درکار ہو تو الگ نظام کی ضرورت پڑتی ہے۔ ریجنز (リージョン) کے پار ریپلیکیٹ کرنا یا ایج لوکیشنز سے ڈیلیور کرنا EBS کا کام نہیں ہے۔

S3 Glacier آرکائیو اسٹوریج کلاسز (ストレージクラス) کا ایک گروپ ہے: فوری بازیافت والے ڈیٹا کے لیے S3 Glacier Instant Retrieval، کم استعمال ہونے والے طویل مدتی ڈیٹا کے لیے S3 Glacier Flexible Retrieval، اور S3 Glacier Deep Archive جو کم ترین لاگت پر چند گھنٹوں میں بازیافت کرتا ہے۔ اس ڈیزائن میں آپ بازیافت کی رفتار اور لاگت کے توازن کی بنیاد پر کلاس منتخب کرتے ہیں، اس لیے بازیافت کا وقت یکساں نہیں ہوتا۔ محفوظ کیے جانے والے ڈیٹا کی قسم پر کوئی پابندی نہیں، اور اسے بلاک اسٹوریج کے طور پر منسلک کر کے استعمال نہیں کیا جاتا۔

S3 آبجیکٹ اسٹوریج (オブジェクトストレージ) ہے، EBS، EC2 سے منسلک ہونے والا بلاک اسٹوریج (ブロックストレージ) ہے، اور EFS، Linux ورک لوڈز کے لیے فائل اسٹوریج (ファイルストレージ) ہے۔ آبجیکٹس کو ایسی چیز سمجھیں جو API کے ذریعے پوری کی پوری اندر باہر کی جاتی ہے، بلاکس کو ایسی چیز جو OS کو ڈسک کی طرح دکھائی دیتی ہے، اور فائلوں کو ایسی چیز جو متعدد ہوسٹس سے ماؤنٹ کر کے شیئر کی جا سکتی ہے — یہ ترتیب ضروریات کی بنیاد پر اعتماد سے انتخاب کرنا آسان بنا دیتی ہے۔

EBS، EC2 انسٹینسز کے ساتھ استعمال ہونے والا مستقل بلاک اسٹوریج (ブロックストレージ) والیوم ہے جو یکساں، کم لیٹنسی والی کارکردگی فراہم کرتا ہے، اس لیے یہ OS یا ڈیٹا بیس کی ڈسک کے طور پر استعمال کے لیے بہت موزوں ہے۔ S3 آبجیکٹ اسٹوریج ہے اور اس میں بکٹ کو بلاک ڈیوائس کے طور پر منسلک نہیں کیا جاتا۔ Glacier آرکائیو کی ایک کلاس ہے جو سست بازیافت کے لیے بنائی گئی ہے، اور CloudFront ڈیلیوری کو تیز کرنے والا CDN ہے۔

S3 ایسا آبجیکٹ اسٹوریج (オブジェクトストレージ) ہے جو کسی بھی مقدار کے ڈیٹا کو ذخیرہ کر سکتا ہے اور اس کی حفاظت کر سکتا ہے، اور اسکیل ایبلٹی (スケーラビリティ)، دستیابی (可用性)، سیکیورٹی اور کارکردگی میں بہترین ہے؛ AWS سرکاری طور پر ویب، موبائل، بیک اپ، آرکائیو، IoT اور بگ ڈیٹا تجزیہ جیسے استعمالات بتاتا ہے۔ OS کو ڈسک کی طرح دکھائی دینا EBS کی خصوصیت ہے، اصولاً ایک ہی انسٹینس کے کنکشن تک محدود ہونا بھی EBS کی خصوصیت ہے، اور ڈیٹا کو میموری میں رکھنا ElastiCache کی خصوصیت ہے۔

EFS ایک سادہ، اسکیل ایبل اور لچکدار (エラスティック) فائل سسٹم ہے جس کی گنجائش فائلیں شامل اور حذف کرنے کے ساتھ خود کار طور پر بڑھتی اور گھٹتی ہے، اس لیے پیشگی گنجائش کی منصوبہ بندی (容量設計) کی ضرورت نہیں رہتی۔ طے شدہ گنجائش کو پہلے سے مقرر کر دینا، یا اسے بڑھانے کے لیے دوبارہ بنانا، بلاک اسٹوریج والی سوچ ہے، اور منسلک انسٹینس کی میموری کا سائز بھی گنجائش طے نہیں کرتا۔ یہی لچک اسے مشترکہ کام کی جگہ کے طور پر استعمال میں آسان بناتی ہے۔

S3 Glacier Deep Archive کم استعمال ہونے والے ڈیٹا کو کم ترین لاگت پر محفوظ کرتا ہے اور بازیافت میں چند گھنٹے لگتے ہیں، اس لیے یہ اس شرط پر پورا اترتا ہے۔ EBS اور EFS بازیافت کی رفتار برقرار رکھنے کے لیے بنائے گئے ہیں اور طویل عرصے تک غیر فعال پڑے ڈیٹا کی جگہ کے طور پر مہنگے پڑتے ہیں۔ ElastiCache ان میموری کیش ہے اور بنیادی طور پر طویل مدتی ذخیرے کا نظام ہی نہیں ہے۔ یہ پہلے سے طے کرنا کہ بازیافت کا کتنا انتظار قابلِ قبول ہے، اسٹوریج کلاس (ストレージクラス) کے انتخاب کی رہنما منطق ہے۔

RDS ایک منیجڈ سروس (マネージドサービス) ہے جو کلاؤڈ میں ریلیشنل ڈیٹا بیس (リレーショナルデータベース) کو سیٹ اپ کرنا، چلانا اور اسکیل کرنا آسان بناتی ہے، اور ہارڈویئر کی پروویژننگ، ڈیٹا بیس سیٹ اپ، پیچ لگانا (パッチ適用) اور بیک اپ جیسے انتظامی کام خود کار بناتی ہے۔ ٹیبلز اور کالمز کا ڈیزائن، انڈیکسز کا فیصلہ، ایپلیکیشن بنانا، اور ڈیٹا کے مواد کی درستی کی توثیق — یہ سب صارف ہی کا کام رہتا ہے۔ منیجڈ کا مطلب آپریشن کا بوجھ سپرد کرنا ہے، ڈیزائن بھی سپرد کر دینا نہیں۔

Aurora منیجڈ ڈیٹا بیس سروس Amazon RDS کا حصہ ہے، اور پروویژننگ، پیچ لگانے، بیک اپ، بحالی اور خرابی کی نشاندہی کے لیے وہی مینجمنٹ کنسول، CLI اور API آپریشنز استعمال کرتا ہے۔ فرق انتظام کی اکائی میں ہے: معیاری RDS انفرادی DB انسٹینسز کا انتظام کرتا ہے، جبکہ Aurora ریپلیکیشن (レプリケーション) کے ذریعے ہم آہنگ رکھے گئے DB سرورز کے پورے کلسٹر (クラスター) کا انتظام کرتا ہے۔ Aurora، MySQL اور PostgreSQL سے مطابقت رکھنے والا ریلیشنل ڈیٹا بیس ہے، کی-ویلیو ڈیٹا بیس (キーバリュー型) نہیں۔

DynamoDB کی-ویلیو اور ڈاکیومنٹ (キーバリュー型とドキュメント型) قسم کا NoSQL ڈیٹا بیس ہے؛ یہ مکمل منیجڈ، ملٹی ریجن ڈیٹا بیس ہے جو کسی بھی پیمانے پر سنگل ڈیجٹ ملی سیکنڈ (1桁ミリ秒) کی کارکردگی فراہم کرتا ہے۔ ڈیٹا ویئرہاؤس (データウェアハウス) Redshift ہے، MySQL اور PostgreSQL سے مطابقت رکھنے والا ریلیشنل ڈیٹا بیس Aurora ہے، اور میموری میں پڑھنا لکھنا ElastiCache کا کام ہے۔

Redshift کلاؤڈ میں ایک مکمل منیجڈ، پیٹا بائٹ پیمانے کی ڈیٹا ویئرہاؤس (データウェアハウス) سروس ہے، جو ڈیٹا سیٹ کے سائز سے قطع نظر موجودہ SQL پر مبنی ٹولز یا BI ایپلیکیشنز سے تیز کوئری کارکردگی فراہم کرتی ہے۔ ElastiCache ان میموری کیش ہے، EFS مشترکہ فائل سسٹم ہے، اور SQS میسج کیو (メッセージのキュー) ہے — ان میں سے کوئی بھی بڑی مقدار کے ڈیٹا کو جمع کرنے اور تجزیہ کرنے کا پلیٹ فارم نہیں ہے۔

ElastiCache ایسی سروس ہے جو کلاؤڈ میں ان میموری کیش (インメモリキャッシュ) کو ڈیپلائے کرنا، چلانا اور اسکیل کرنا آسان بناتی ہے، اور ڈسک پر مبنی ڈیٹا بیس پر انحصار کرنے کے بجائے تیز ان میموری کیش سے معلومات حاصل کر کے ویب ایپلیکیشن کی کارکردگی بہتر بناتی ہے۔ تجزیاتی کوئریز کو تیز کرنا Redshift کا کام ہے، طویل مدتی ذخیرے کی لاگت کم کرنا S3 Glacier کلاسز کا کام ہے، اور ڈائریکٹری شیئر کرنا EFS کا کام ہے۔

Aurora مکمل منیجڈ، MySQL اور PostgreSQL سے مطابقت رکھنے والا ریلیشنل ڈیٹا بیس انجن ہے جس میں اعلیٰ کارکردگی والا، تقسیم شدہ اور مشترکہ اسٹوریج سب سسٹم (分散共有ストレージ) ہے، اور اس کا اسٹوریج ضرورت کے مطابق خود کار طور پر پھیلتا ہے۔ گنجائش پہلے سے طے کر کے اسے دستی طور پر بڑھانے کی ضرورت نہیں۔ ڈیٹا کو کی-ویلیو جوڑوں کی صورت میں محفوظ کرنا DynamoDB ہے، اور بازیافت میں وقت لگنے کے بدلے ذخیرہ سستا رکھنا S3 Glacier کی آرکائیو کلاس ہے۔

Redshift ایک مکمل منیجڈ، پیٹا بائٹ پیمانے کی ڈیٹا ویئرہاؤس (データウェアハウス) سروس ہے جو SQL پر مبنی ٹولز یا BI ایپلیکیشنز سے بڑی مقدار کے ڈیٹا کو جمع کرنے اور تجزیہ کرنے کے لیے بہت موزوں ہے۔ RDS ایسی سروس ہے جو ریلیشنل ڈیٹا بیس (リレーショナルデータベース) کو سیٹ اپ کرنا، چلانا اور اسکیل کرنا آسان بناتی ہے، اور کاروباری نظام کے روزمرہ لین دین کو پڑھنے اور لکھنے کے لیے بہت موزوں ہے۔ دونوں میں SQL سے کوئری کی جاتی ہے جس کی وجہ سے یہ ایک جیسے لگ سکتے ہیں، لیکن ان میں سے کوئی بھی NoSQL نہیں، اور فرق محض ڈیٹا کی مقدار کا نہیں ہے۔

DynamoDB کی-ویلیو اور ڈاکیومنٹ قسم کا NoSQL ڈیٹا بیس ہے جس کی سرکاری وضاحت یہ ہے کہ وہ کسی بھی پیمانے پر سنگل ڈیجٹ ملی سیکنڈ (1桁ミリ秒) کی کارکردگی فراہم کرتا ہے۔ Redshift بڑی مقدار کے ڈیٹا کو جمع کرنے اور تجزیہ کرنے کے لیے موزوں ڈیٹا ویئرہاؤس ہے، RDS ریلیشنل ماڈل (関係モデル) کے تحت پڑھنے اور لکھنے کی سروس ہے، اور EFS فائلیں شیئر کرنے کا اسٹوریج ہے — ان میں سے کوئی بھی بنیادی طور پر اس ضرورت کو ہدف نہیں بناتا۔

RDS کا پورا نام Amazon Relational Database Service ہے؛ یہ ایک منیجڈ سروس (マネージドサービス) ہے جو کلاؤڈ میں ریلیشنل ڈیٹا بیس (リレーショナルデータベース) کو سیٹ اپ کرنا، چلانا اور اسکیل کرنا آسان بناتی ہے۔ ڈیٹا کو کی-ویلیو جوڑوں کی صورت میں محفوظ کرنا DynamoDB ہے، ان میموری کیش ElastiCache ہے، اور بڑی مقدار کے ڈیٹا کو جمع کرنا ڈیٹا ویئرہاؤس Redshift کا کام ہے۔ یاد رہے کہ Aurora ایک انجن ہے جو RDS کے حصے کے طور پر پیش کیا جاتا ہے۔

Aurora، RDS کے حصے کے طور پر پیش کیا جاتا ہے، اور پروویژننگ، پیچ لگانا (パッチ適用)، بیک اپ، بحالی اور خرابی کی نشاندہی (障害検知) سب وہی مینجمنٹ کنسول، CLI اور API آپریشنز استعمال کر کے کیے جا سکتے ہیں۔ الگ مینجمنٹ انسٹینس قائم کرنے کی ضرورت نہیں، اور نہ ہی صارف کو یہ طریقۂ کار خود بنانے کی ضرورت ہے۔ انفرادی DB انسٹینسز کا انتظام کرنے والے معیاری RDS سے فرق یہ ہے کہ Aurora پورے کلسٹر کو انتظام کی اکائی مانتا ہے۔

SQS ایک پوائنٹ ٹو پوائنٹ سروس ہے جو پیغامات کو کیو (キュー) میں رکھتی ہے، اور عام طور پر ایک ہی کنزیومر پولنگ کر کے انہیں نکالتا ہے۔ SNS ایک پب/سب (パブサブ) سروس ہے جس میں پبلشرز ٹاپک (トピック) کو پیغامات بھیجتے ہیں اور وہ بیک وقت متعدد سبسکرائبرز تک پش کیے جاتے ہیں۔ دونوں کو آپس میں الٹ دینا ایک کلاسیکی غلطی ہے، اور ایسا بھی نہیں کہ دونوں ایک ہی طرح ڈیلیور کرتے ہوں۔ سمت کے لحاظ سے یاد رکھنا مفید ہے: کیو وہ جگہ ہے جہاں وصول کنندہ خود جا کر لیتا ہے، اور ٹاپک بھیجنے والا ہے جو آگے دھکیلتا ہے۔

SQS میں معیاری کیوز (標準キュー) اور FIFO کیوز ہوتی ہیں۔ معیاری کیوز at-least-once ڈیلیوری فراہم کرتی ہیں، اس لیے ایک ہی پیغام ایک سے زیادہ بار پہنچ سکتا ہے۔ FIFO کیوز exactly-once پروسیسنگ اور ترتیب کی ضمانت (順序保証) فراہم کرتی ہیں، اس لیے بھیجنے کی ترتیب برقرار رہتی ہے اور ہر پیغام ٹھیک ایک بار پروسیس ہوتا ہے۔ جن ورک فلوز میں ترتیب اور پیغام ضائع ہونے سے بچاؤ اہم ہو، ان میں FIFO کیو کا انتخاب کیا جاتا ہے۔

SNS ٹاپک کو بھیجے گئے پیغام کو بیک وقت متعدد سبسکرائبرز (サブスクライバー) تک پش کرتا ہے، اور SQS کیو کو سبسکرائبر کے طور پر مقرر کیا جا سکتا ہے۔ ایک SNS ٹاپک سے متعدد SQS کیوز تک کی یہ شکل وہ فین آؤٹ پیٹرن (ファンアウトパターン) ہے جسے سرکاری طور پر معیاری طریقے کے طور پر پیش کیا گیا ہے۔ کیو وصول کرنے والا سرا ہے، ڈیلیوری کا ماخذ نہیں، اس لیے سمت کبھی کیو سے ٹاپک کی طرف نہیں جاتی۔

SNS سبسکرائبر (サブスクライバー) کی اقسام کو دو گروپوں میں منظم کیا گیا ہے: A2A، یعنی ایپ سے ایپ کی منزلیں جیسے SQS، Lambda، HTTP(S) اور Data Firehose؛ اور A2P، یعنی ایپ سے انسان کی منزلیں جیسے ای میل، موبائل پش اور SMS۔ یہ ان میں سے کسی ایک تک محدود نہیں، اور نہ ہی یہ صرف EC2 انسٹینسز کو منزل بنانے والا نظام ہے۔ اسی وسعت کی وجہ سے SNS لوگوں کو اطلاع دینے اور ایپلیکیشنز کو جوڑنے دونوں کے لیے استعمال ہوتا ہے۔

Step Functions ایسی سروس ہے جس سے آپ ورک فلوز یعنی اسٹیٹ مشینز (ステートマシン) بنا سکتے ہیں، جس سے تقسیم شدہ ایپلیکیشنز بنانا، عمل کو خود کار بنانا، مائیکرو سروسز کی آرکیسٹریشن، اور ڈیٹا یا مشین لرننگ پائپ لائنز بنانا ممکن ہوتا ہے۔ ہر مرحلے کو state کہا جاتا ہے، اور چلتے ہوئے انسٹینس کو execution کہا جاتا ہے۔ ٹریفک تقسیم کرنا Elastic Load Balancing کا کام ہے، آبجیکٹس محفوظ کرنا S3 کا کام ہے، اور کی-ویلیو جوڑوں کو کیش کرنا ElastiCache کا دائرہ ہے۔

API Gateway کسی بھی پیمانے پر REST، HTTP اور WebSocket APIs بنانے، شائع کرنے، برقرار رکھنے، نگرانی کرنے اور محفوظ بنانے کی سروس ہے، جو EC2 پر چلنے والے ورک لوڈز، Lambda یا کسی بھی ویب ایپلیکیشن جیسے بیک اینڈز تک رسائی کے لیے مرکزی دروازے (フロントドア) کا کام کرتی ہے۔ پروسیسنگ خود چلانا بیک اینڈ کا کام ہے، اکاؤنٹس پر حفاظتی اصول مرکزی طور پر لاگو کرنا AWS Firewall Manager کا کام ہے، اور ایج پر کیش کرنا CloudFront کا کردار ہے۔

EventBridge ایک سرور لیس سروس ہے جو ایونٹس کے ذریعے ایپلیکیشن کے اجزا کو آپس میں جوڑتی ہے، اور ایونٹس کی وصولی، فلٹرنگ، تبدیلی اور ڈیلیوری سنبھالتی ہے۔ ایونٹ بس (イベントバス) ایک راؤٹر ہے جو بہت سے ذرائع (ソース) سے آنے والے ایونٹس کو بہت سے اہداف (ターゲット) تک روٹ کرتا ہے۔ کیو کی وضاحت SQS پر، اسٹیٹ مشین کی Step Functions پر، اور مرکزی دروازے کی API Gateway پر صادق آتی ہے۔

EventBridge Scheduler، cron ایکسپریشنز (cron 式) یا rate ایکسپریشنز کے ذریعے بار بار ہونے والے اور ایک بار کے عمل درآمد کو منظم کرنے کا نظام ہے، اس لیے مقررہ اوقات پر شیڈول شدہ عمل درآمد یہیں سنبھالا جاتا ہے۔ SQS ایک کیو ہے جو پیغامات رکھتی ہے تاکہ وصول کنندہ انہیں نکالے، SNS سبسکرائبرز تک پب/سب ڈیلیوری ہے، اور API Gateway، APIs شائع کرنے اور آگے پہنچانے کی سروس ہے — ان میں سے کوئی بھی وقت کی بنیاد پر عمل درآمد کے لیے نہیں ہے۔

SQS ایک محفوظ، پائیدار اور انتہائی دستیاب ہوسٹڈ کیو سروس ہے جس کے ذریعے آپ تقسیم شدہ سافٹ ویئر سسٹمز اور اجزا کو مربوط کر کے انہیں ایک دوسرے سے الگ (لوز کپلنگ، 疎結合) کر سکتے ہیں۔ وصولی والی طرف کیو میں پیغام ڈالتے ہی جواب دے سکتی ہے، اور بعد کا عمل اپنی رفتار سے اسے نکال کر آگے بڑھ سکتا ہے، اس لیے ایک طرف کی تاخیر دوسری طرف کو آسانی سے نہیں روکتی۔ براہِ راست کال یا ایک ہی پروگرام والی ترتیب میں، بعد کے عمل کی تاخیر وصولی والی طرف کے لیے انتظار کا وقت بن جاتی ہے۔

SNS ٹاپک کو بھیجے گئے پیغام کو بیک وقت متعدد سبسکرائبرز تک پش کرتا ہے، اور SQS کیو کو سبسکرائبر کے طور پر مقرر کیا جا سکتا ہے، اس لیے ایک ایونٹ کو تین عملوں تک پہنچانے کے لیے SNS ٹاپک اور متعدد SQS کیوز والا فین آؤٹ پیٹرن (ファンアウトパターン) درکار ہے۔ اگر تین عمل ایک ہی کیو شیئر کریں تو عام طور پر جیسے ہی ان میں سے کوئی ایک آئٹم نکالتا ہے، باقی اسے وصول نہیں کر سکتے۔ ماخذ کا تین بار بھیجنا، یا وصول کرنے والے عمل کا آگے بھیجنا، اس کا مطلب ہے کہ ہر نئی منزل کے اضافے پر بھیجنے والے کو تبدیل کرنا پڑے گا، اور یہ لوز کپلنگ (疎結合) نہیں ہے۔