مقایسه AWS، Azure و Google Cloud؛ انتخاب مبتنی بر PoC

اگر برای انتخاب ابر فقط سه ستون «AWS، Azure و Google Cloud» بسازید و نام سرویس‌ها را کنار هم بگذارید، احتمالاً تصمیم گرانی می‌گیرید. سؤال درست این نیست که کدام برند در جهان «بهترین» است؛ سؤال این است که کدام پلتفرم برای Workload مشخص شما، با تیم، قرارداد، بودجه، ریسک و مسیر خروج واقعی‌تان مناسب‌تر است. پاسخ حرفه‌ای از یک ماتریس نیاز شروع می‌شود، با Proof of Concept یکسان ادامه پیدا می‌کند و با شواهد هزینه، تاب‌آوری، امنیت و عملیات به پایان می‌رسد.

این راهنما مقایسه AWS، Azure و Google Cloud را از سطح فهرست محصولات بالاتر می‌برد. قرار است قبل از هر تعهد بلندمدت بدانید چه چیزی را اندازه بگیرید، چه هزینه‌هایی در Calculator دیده نمی‌شوند، SLA را چگونه به معماری ترجمه کنید، Multi-cloud چه زمانی ارزش دارد و یک کسب‌وکار ایرانی پیش از هر طراحی فنی چه Gateهای قراردادی و عملیاتی را باید بگذراند.

پاسخ کوتاه: کدام Cloud Provider بهتر است؟

هیچ برنده مطلقی وجود ندارد. AWS، Azure و Google Cloud هر سه می‌توانند یک سامانه Production را میزبانی کنند؛ تفاوت واقعی در Fit با Workload، Availability سرویس در Region منتخب، مدل هزینه قرارداد شما، Identity موجود، تجربه تیم، نیاز داده و AI، کیفیت Support قابل‌خرید و هزینه Exit آشکار می‌شود.

این جدول Shortlist می‌سازد، نه حکم خرید. نام برند باید آخرین متغیر تصمیم باشد، نه اولین متغیر.

مقایسه AWS، Azure و Google Cloud از چه چیزی منحرف می‌شود؟

سه خطای رایج، تصمیم را از واقعیت دور می‌کنند:

• سهم بازار به‌جای Fit: سهم بازار درباره اندازه فروشنده است، نه Latency کاربر شما، مهارت تیم یا هزینه هر سفارش.
• قیمت یک VM به‌جای TCO: Compute فقط یکی از سطرهای Bill است؛ Egress، Log، Snapshot، IP، NAT، Support، License و نیروی انسانی می‌توانند نتیجه را عوض کنند.
• Feature checklist به‌جای سناریو: وجود یک Feature با قابل‌استفاده‌بودن آن در Region، Tier، Quota و قرارداد شما یکی نیست.

هر سه فروشنده Framework معماری خود را دارند. AWS Well-Architected شش Pillar، Azure Well-Architected پنج Pillar و Google Cloud Well-Architected مجموعه‌ای از Pillarها و Perspectiveها ارائه می‌کنند. وجه مشترک مهم آن‌ها این است: Reliability، Security، Performance، Cost و Operations را هم‌زمان و با Trade-off بسنجید.

ابتدا واحد تصمیم را تعریف کنید: Company یا Workload؟

«ابر شرکت» واحد تصمیم مبهمی است. واحد قابل‌ارزیابی، Workload است: مجموعه‌ای از Application، Data، Dependency، تیم، جریان کاربر و هدف کسب‌وکار که یک Outcome مشخص می‌سازد. ممکن است ERP، فروشگاه، Data warehouse و سرویس AI یک شرکت پاسخ یکسانی نگیرند.

برای هر Workload یک Owner، تاریخ تصمیم و تاریخ بازبینی بگذارید. تصمیم ابری دائمی نیست؛ قیمت، Region، Team و Product lifecycle تغییر می‌کنند.

Gate صفر: آیا اصلاً می‌توانید این سرویس را قانونی و پایدار بخرید؟

برای تیم ایرانی، Eligibility یک پاورقی نیست؛ Gate صفر معماری است. پیش از ساخت Account یا انتقال داده، قرارداد جاری، کشور و هویت طرف قرارداد، روش پرداخت، Export control، Sanctions، End user و End use، دسترسی Support و امکان دریافت Invoice را با مشاور حقوقی و مالی واجدصلاحیت بررسی کنید. از هویت، نشانی یا Payment جعلی و دورزدن محدودیت فنی استفاده نکنید؛ چنین پایه‌ای هم ریسک حقوقی دارد و هم می‌تواند به Suspension و از‌دست‌رفتن دسترسی منجر شود.

اسناد رسمی نیز استفاده را به قوانین و شرایط جاری گره می‌زنند: مرکز اسناد حقوقی AWS Agreement و Service Terms را مرجع می‌داند؛ پرسش‌های صادرات Microsoft محدودیت مقصد، کاربر و End use را مطرح می‌کند؛ و شرایط Google Cloud استفاده ناقض Export Control Laws و برخی فعالیت‌ها را ممنوع و امکان Suspension/Termination طبق قانون را بیان می‌کند. این مقاله مشاوره حقوقی نیست و Availability امروز را تضمین نمی‌کند.

مرز IaaS، PaaS، Serverless و SaaS را روشن کنید

دو سرویس با نام مشابه ممکن است مسئولیت عملیاتی متفاوتی تحمیل کنند. در IaaS تیم شما OS، Patch، Runtime و Application را بیشتر اداره می‌کند؛ در PaaS و Serverless بخشی از این مسئولیت به Provider منتقل می‌شود، اما Data، Identity، Application logic، Configuration و Governance همچنان با شماست.

برای هر گزینه یک Responsibility matrix واقعی بنویسید. راهنمای Shared Responsibility در AWS، مدل مسئولیت مشترک Azure و Shared Responsibility/Shared Fate در Google Cloud همگی یادآوری می‌کنند که رفتن به Cloud، مسئولیت Data و Access شما را حذف نمی‌کند.

ماتریس معادل سرویس‌ها؛ فقط برای Orientation

نام‌ها را برای جهت‌یابی کنار هم بگذارید، نه برای نتیجه‌گیری. Semantics، SLA، Quota، Network، IAM و Billing هر خانه متفاوت است.

اگر تیم شما به Kubernetes فکر می‌کند، آن را مترادف Portability نگیرید. Container image قابل‌حمل‌تر است، اما Load balancer، IAM، Secret، Storage، Observability و Database معمولاً Provider-specific می‌مانند.

معیار اول: Region، Latency و مسیر واقعی کاربر

تعداد Region جهانی به‌تنهایی معیار خوبی نیست. باید Regionهایی را مقایسه کنید که از نظر Eligibility، سرویس موردنیاز، Data residency، قیمت، Quota و Latency برای شما قابل‌استفاده‌اند. سپس از شبکه‌های واقعی کاربران و Operators تست کنید.

برای مخاطب چندمنطقه‌ای، طراحی CDN، SEO و معماری چندمنطقه‌ای را از Provider compute جدا ارزیابی کنید؛ برای سایت عمدتاً ایرانی نیز PoC شبکه CDN در ایران باید روی ISP و اپراتور واقعی انجام شود.

معیار دوم: Compute را با شکل بار مقایسه کنید

«قیمت هر vCPU» بدون شکل بار ناقص است. Workload ممکن است Steady، Bursty، Batch، GPU-bound، Memory-bound یا Latency-sensitive باشد. برای مقایسه، یک Profile واحد بسازید:

• CPU، Memory و Local/Network storage در صدک ۵۰، ۹۵ و Peak؛
• Concurrency و زمان پردازش هر Request/Job؛
• Startup time، Scale-out lag و Graceful shutdown؛
• Architecture پردازنده و سازگاری Dependency؛
• نسبت Base load به Burst و امکان Interruptible/Spot؛
• Licenseهای وابسته به Core، Socket یا OS.

معیار سوم: Data، Database و هزینه مهاجرت

Database معمولاً بیش از Compute Lock-in می‌سازد. سازگاری SQL یا API به‌تنهایی کافی نیست؛ Extension، Collation، CDC، Backup format، PITR، Replica، Consistency، Transaction limit و Operational tooling را بسنجید.

برای Data warehouse و AI، فقط Benchmark query را نسنجید. Ingestion، Transformation، Governance، Catalog، Lineage، Egress به ابزار BI، Skill تیم و هزینه Idle/Scan نیز در TCO هستند.

معیار چهارم: Reliability؛ SLA فروشنده با SLO شما یکی نیست

SLA یک تعهد قراردادی با شرط و Remedy مشخص است؛ SLO هدف داخلی تجربه کاربر است. یک SLA بالا تضمین نمی‌کند سامانه شما همان Availability را داشته باشد. Architecture، Quota، Dependency، Deployment و خطای انسانی می‌توانند SLO را بشکنند.

برای هر نامزد، همان Failureها را تزریق کنید: حذف Instance، قطع Zone، Throttle API، Expire credential، Corrupt config، Latency دیتابیس و شکست Dependency. طراحی Observability، SLO و Alert و طرح Disaster Recovery و Restore باید قبل از Production آماده باشند، نه بعد از اولین Incident.

معیار پنجم: Security را از Logo و Certification استنتاج نکنید

هر سه Provider کنترل‌ها و Compliance programهای گسترده دارند، اما امنیت Workload نتیجه Configuration شماست. Comparison باید از Threat model و Control objective شروع شود.

امنیت API و Webhook، MFA حساب‌های کنترل‌کننده و جداسازی Break-glass باید در هر سه PoC یکسان آزموده شوند. «Provider امن است» پاسخ Security review نیست.

معیار ششم: Landing Zone و Governance

یک Demo در Account شخصی به شما نمی‌گوید Production چگونه اداره می‌شود. Landing zone حداقل باید Hierarchy، Billing، Identity federation، Log مرکزی، Network baseline، Policy، Key/Secret، Backup و Break-glass را تعریف کند.

معیار هفتم: Developer Experience و سرعت Delivery

کاتالوگ بزرگ اگر Lead time را کم نکند، ارزش عملی ندارد. تیم باید Golden path داشته باشد: Repository تا محیط آزمایشی، Secret، Database، Telemetry، Policy و Rollback با حداقل تصمیم دستی.

Pipeline باید Build once، Artifact immutable، Approval مبتنی بر Risk، Progressive delivery و Rollback اثبات‌شده داشته باشد. راهنمای CI/CD امن و Progressive Delivery این Contract را مستقل از Provider شرح می‌دهد.

معیار هشتم: قیمت واقعی؛ از Bill of Materials تا Unit Economics

هیچ Provider همیشه ارزان‌تر نیست. قیمت تابع Region، SKU، ساعت، Discount، Contract، Architecture و Usage است. سه Calculator رسمی برای نقطه شروع‌اند: AWS Pricing Calculator، Azure Pricing Calculator و Google Cloud Pricing Calculator. Calculator پیش‌بینی است؛ Bill واقعی و Usage telemetry داور نهایی‌اند.

هزینه‌هایی که باید در TCO بیایند

فرمول تصمیم را بر هزینه کسب‌وکار بنا کنید:

Monthly TCO = Provider bill
 software licenses
 support and partner fees
 engineering and on-call toil
 security/compliance operations
 expected incident loss
 amortized migration and exit cost

بعد آن را به واحد کسب‌وکار تبدیل کنید:

Cost per successful order = Monthly workload TCO / successful paid orders
Cost per active tenant = Monthly workload TCO / active paying tenants
Cost per million events = Monthly pipeline TCO / processed valid events × 1,000,000

این Unit metric اجازه می‌دهد رشد، بهینه‌سازی و معماری را با Outcome مقایسه کنید؛ کاهش Bill همراه با افت نرخ سفارش موفق، صرفه‌جویی نیست.

On-demand، Commitment و Spot را قاطی نکنید

برای Comparison منصفانه سه سناریو بسازید: On-demand بدون تعهد، تعهد محافظه‌کارانه برای Base load و معماری بهینه‌شده پس از مشاهده Usage. Commitment را قبل از Rightsizing نخرید.

بودجه را Guardrail کنید، نه فقط Dashboard

Tag ناقص، Log بی‌حد، Snapshot بی‌Owner و Environment فراموش‌شده با گزارش ماهانه اصلاح نمی‌شوند. Cost control باید در Provisioning و عملیات باشد.

• هر Resource: Workload، Environment، Owner، Cost center و Expiry؛
• Budget و Forecast در سطح قابل‌اقدام، نه فقط حساب کل؛
• هشدار Anomaly با Runbook و Owner؛
• Quota برای جلوگیری از انفجار ناخواسته؛
• Policy برای Log retention، Snapshot و SKU پرهزینه؛
• Showback/Chargeback بر اساس Unit economics؛
• Review دوره‌ای Commitment، Egress و Idle.

AWS چه زمانی Fit اولیه بهتری دارد؟

AWS را در Shortlist جلوتر بگذارید وقتی Workloadهای بسیار متنوع، الگوهای تخصصی، اکوسیستم بزرگ Partner یا نیاز به ترکیب‌های متعدد Managed service دارید و تیم می‌تواند Complexity را با Landing zone و Golden path مهار کند.

No-fit موقت: اگر تیم کوچک بدون Platform owner است و تنوع سرویس به انتخاب‌های بی‌قاعده تبدیل می‌شود، مزیت کاتالوگ می‌تواند Toil بسازد.

Azure چه زمانی Fit اولیه بهتری دارد؟

Azure را جلوتر بگذارید وقتی Identity، Endpoint، Windows/SQL، قرارداد سازمانی یا عملیات موجود شما واقعاً بر اکوسیستم Microsoft بنا شده و Integration می‌تواند Lead time یا هزینه License را کاهش دهد.

No-fit موقت: اگر «ما Microsoft داریم» تنها دلیل است اما Workload Linux/Open-source، قرارداد تخفیف‌دار یا تیم Azure ندارید، Integration فرضی را امتیاز ندهید.

Google Cloud چه زمانی Fit اولیه بهتری دارد؟

Google Cloud را جلوتر بگذارید وقتی Data/Analytics، Managed Kubernetes، شبکه یا سرویس‌های داده خاص آن با Requirement شما هم‌راستا هستند و Skill، Support، Region و هزینه همان الگو در PoC تأیید می‌شود.

No-fit موقت: اگر Capability اصلی فقط در Region نامناسب موجود است یا مسیر Contract/Support/Skill حل نشده، جذابیت محصول به‌تنهایی کافی نیست.

AI و Data نباید میان‌بُر انتخاب Provider شوند

هر سه Provider پلتفرم‌های AI/ML و مدل‌های مدیریت‌شده دارند. مقایسه را بر Model catalog متغیر بنا نکنید. این Contract را بسنجید:

Portability را به لایه‌ها بشکنید

Portability صفر یا یک نیست. برای هر لایه درجه وابستگی ثبت کنید:

برای سرویس حیاتی، Exit contract شامل Format، Tool، Bandwidth، RTO خروج، Consistency، هزینه، Owner و آخرین تست است. قرار نیست همه‌چیز Portable باشد؛ قرار است Lock-in آگاهانه، قیمت‌گذاری‌شده و قابل‌مدیریت باشد.

Multi-cloud چه زمانی تصمیم خوبی است؟

Multi-cloud یعنی استفاده هدفمند از بیش از یک Provider؛ به معنی Deploy یکسان هر سرویس روی سه ابر نیست. مزیت احتمالی باید از هزینه هماهنگی بیشتر باشد.

Active-active میان دو Cloud برای بیشتر تیم‌ها بسیار پرهزینه است: Identity، Network، Data consistency، Deployment، Observability، Security و On-call دوگانه می‌شوند. اغلب یک Primary cloud، Backup قابل‌بازیابی مستقل، فرمت‌های باز و Exit rehearsal از «همه‌چیز روی همه‌جا» سالم‌تر است.

Hybrid Cloud با Multi-cloud یکی نیست

Hybrid یعنی Workload میان محیط On-premises/Colocation/Edge و Public cloud تقسیم می‌شود. Multi-cloud یعنی بیش از یک Public provider. یک معماری می‌تواند هر دو باشد، اما Driver و Failure mode متفاوت‌اند.

ماتریس تصمیم وزنی بسازید

وزن‌ها را قبل از دیدن Demo فروشنده تصویب کنید تا نتیجه را به علاقه قبلی تنظیم نکنید. امتیاز بدون Evidence صفر است.

Weighted score = Σ (criterion score from 0..5 × approved weight)

Rule:
- no evidence = 0
- failed mandatory gate = disqualified
- difference under 5% = treat as tie; prefer simpler operating model

Scorecard باید Assumption، Source، Date، Owner و Confidence داشته باشد. عدد بدون Provenance، فقط ظاهر دقت است.

PoC منصفانه: یک Workload، یک Harness، سه نامزد

PoC باید تصمیم را کاهش ریسک دهد، نه اینکه یک Demo زیبا تولید کند. همان Dataset، Traffic، SLO، Security control و Failure را روی گزینه‌ها اجرا کنید.

Contract آزمون

Exit criteria برای PoC

• همه Mandatory gateها Pass شده‌اند؛
• SLO در بار و Failure تعریف‌شده رعایت شده است؛
• هزینه به Unit metric تبدیل شده و فاصله Estimate/Bill توضیح دارد؛
• یک اپراتور غیر از سازنده توانسته Deploy، Debug و Restore کند؛
• ریسک‌های باقیمانده Owner، Deadline و Acceptance دارند؛
• Decision record شامل گزینه ردشده و دلیل رد است.

نمونه تصمیم برای یک فروشگاه ایرانی

فرض کنید فروشگاه ماهانه یک میلیون Session، کمپین‌های ۸برابری، PostgreSQL، صف سفارش، Object storage و تیم کوچک دارد. کاربران عمدتاً داخل ایران‌اند و قرارداد خرید بین‌المللی باید جداگانه تأیید شود.

شرایط ایران: سناریوهای Failure را صریح کنید

برای تیم ایرانی، معماری فقط در برابر خرابی سرور نیست؛ باید اختلال مسیر شبکه، دسترسی Operator، Payment، Partner، Support، تغییر Contract و Currency را نیز مدل کند. هدف دورزدن قاعده نیست؛ هدف این است که سامانه روی فرض نادرست ساخته نشود.

Backup بدون دسترسی قابل‌استفاده نیست. حداقل Metadata بازیابی، Artifact، IaC، Secret recovery، Data export و DNS control را با Ownership روشن و طبق قرارداد نگه دارید. هیچ کنترل فنی جایگزین Eligibility قانونی نیست.

Build، Buy یا Managed service؟

خرید Managed service هزینه Operator را کم می‌کند اما Control surface و Exit cost را تغییر می‌دهد. تصمیم را با مجموع هزینه و ریسک بگیرید.

قانون ساده: چیزی را Self-manage کنید که Differentiator کسب‌وکار است، Constraint خاص دارد یا تیم واقعاً توان عملیات آن را دارد. «کنترل بیشتر» بدون On-call، Patch و Restore فقط مسئولیت بیشتر است.

RACI انتخاب و مهاجرت Cloud

چهار Runbook که قبل از Production لازم‌اند

۱. افزایش ناگهانی Bill

1. Anomaly را به Workload/Resource/SKU/Region نسبت دهید.
2. Attack، Loop، Leak، Scale و Price change را تفکیک کنید.
3. Guardrail کم‌ریسک مثل scale cap یا log sampling را اجرا کنید.
4. اثر بر SLO را پایش و Root cause را ثبت کنید.

۲. اختلال Region یا Zone

1. Blast radius و Provider status را با telemetry خودتان تطبیق دهید.
2. Change freeze و Incident command فعال شود.
3. Failover فقط طبق شرط و ظرفیت آزموده انجام شود.
4. پس از بازیابی، Data reconciliation و failback کنترل‌شده اجرا شود.

۳. Compromise هویت مدیریت

1. Credential را Revoke و Sessionها را invalidate کنید.
2. Break-glass با کنترل دو نفره فعال شود.
3. Audit log مستقل حفظ و Scope تغییرات مشخص شود.
4. Key/Secret rotation و restore configuration انجام شود.

۴. خروج اضطراری کنترل‌شده

1. Legal trigger، data priority و target مجاز تأیید شود.
2. Export snapshot/stream با checksum و manifest اجرا شود.
3. Dual run، validation و cutover بر اساس RTO انجام شود.
4. Access، key، DNS، commitment و retained data decommission شوند.

برنامه ۹۰روزه انتخاب AWS، Azure یا Google Cloud

چک‌لیست نهایی انتخاب Cloud Provider

• Workload و Outcome به‌جای «کل شرکت» تعریف شده‌اند.
• Eligibility، Contract، Payment، Support و Access قبل از Design تأیید شده‌اند.
• Region × Service × Tier × Quota با سند جاری بررسی شده است.
• Latency از مسیر واقعی کاربران و اپراتورها اندازه‌گیری شده است.
• Responsibility matrix برای IaaS/PaaS/Managed service وجود دارد.
• RTO/RPO، SLA شرطی، SLO و Error budget تفکیک شده‌اند.
• Threat model، IAM، MFA، Log، Key و Incident drill اجرا شده‌اند.
• TCO شامل Egress، Log، Support، License، Toil، DR و Exit است.
• PoC یکسان و قابل‌تکرار برای Shortlist انجام شده است.
• Cost per business unit با Bill واقعی محاسبه شده است.
• Lock-in هر لایه آگاهانه و Exit contract آزموده است.
• Multi-cloud فقط برای Driver مستند و پس از محاسبه Complexity انتخاب شده است.
• Decision record، RACI، Runbook و تاریخ بازبینی وجود دارند.

جمع‌بندی

AWS، Azure و Google Cloud را با شعار، سهم بازار یا قیمت یک VM انتخاب نکنید. یک Workload واقعی را تعریف کنید، Gateهای حقوقی و عملیاتی را بگذرانید، Requirementها را وزن دهید، همان بار و Failure را در PoC اجرا کنید و هزینه را به Outcome کسب‌وکار تبدیل کنید. ممکن است AWS برای یک Workload، Azure برای Workload دوم و Google Cloud برای سومی Fit باشد؛ ممکن است نیز ساده‌ترین معماری روی یک Provider از Multi-cloud کم‌ریسک‌تر باشد.

تصمیم خوب تصمیمی نیست که نام محبوب‌تری دارد؛ تصمیمی است که Assumptionهایش ثبت، Trade-offهایش پذیرفته، SLO و Cost آن اندازه‌گیری و مسیر بازیابی و خروجش پیش از بحران آزموده شده است.

پرسش‌های متداول

آیا AWS از Azure و Google Cloud بهتر است؟

به‌طور مطلق خیر. AWS می‌تواند برای تنوع Workload و اکوسیستم گسترده Shortlist مناسبی باشد، اما Fit نهایی به Region، تیم، قرارداد، TCO، Security، SLO و PoC شما بستگی دارد. همان معیارها ممکن است Azure یا Google Cloud را برای Workload دیگری جلو بیندازند.

کدام سرویس ابری ارزان‌تر است؟

هیچ پاسخ عمومی پایداری وجود ندارد. Region، SKU، Usage، Egress، Log، Support، License، Discount و Commitment نتیجه را تغییر می‌دهند. هر سه Calculator رسمی را با یک Bill of Materials واحد پر کنید و سپس Estimate را با Bill یک PoC واقعی و Cost per business outcome تطبیق دهید.

برای استارتاپ AWS بهتر است یا Azure یا Google Cloud؟

برای استارتاپ، سرعت Delivery، Skill موجود، Managed service، Support قابل‌دسترسی و Burn rate معمولاً مهم‌تر از اندازه کاتالوگ است. دو نامزد را Shortlist کنید و با یک مسیر حیاتی، Budget محدود، Restore test و Exit criteria مقایسه کنید.

آیا Multi-cloud از Vendor lock-in جلوگیری می‌کند؟

نه به‌صورت خودکار. Multi-cloud می‌تواند Dependencyها را پخش کند، اما IAM، Network، Data، Observability و Skill دوگانه می‌سازد. Lock-in را لایه‌به‌لایه اندازه بگیرید، فرمت باز و Exit rehearsal داشته باشید و فقط برای Driver مستند به Multi-cloud بروید.

کسب‌وکار ایرانی پیش از انتخاب Public cloud چه چیزی را بررسی کند؟

ابتدا Eligibility قراردادی و قانونی، هویت طرف قرارداد، Payment، Support، Region، مسیر دسترسی تیم و امکان Exit را با متخصصان واجدصلاحیت بررسی کند. سپس Latency شبکه واقعی، نوسان ارز، Backup/Restore و سناریوی تغییر Terms یا دسترسی را وارد PoC و Runbook کند؛ راهکار نباید بر اطلاعات جعلی یا دورزدن محدودیت بنا شود.