سایت استاتیک یا داینامیک؛ TCO، نگهداری و انتخاب

یک شرکت خدماتی سایت «استاتیک و تقریباً رایگان» می‌سازد. شش ماه بعد، برای هر اصلاح تعرفه باید Pull request بدهد، فرم فروش به سرویس ثالث وابسته است، Build به‌خاطر یک Dependency متوقف می‌شود و تیم مالی هزینه CDN، Search، Form، نیروی فنی و ارز را در یک بودجه نمی‌بیند. رقیب همان شرکت WordPress دارد؛ هزینه Hosting و Update بیشتری می‌دهد، اما کارشناس محتوا در چند دقیقه صفحه را اصلاح می‌کند. هیچ‌کدام ذاتاً ارزان‌تر نیستند؛ مرز هزینه را Workload و Operating model تعیین می‌کند.

مقایسه درست سایت استاتیک و داینامیک با قیمت Host شروع نمی‌شود. باید هزینه کل مالکیت یا TCO را در یک افق زمانی، برای Build، تغییر محتوا، API/Database، Security، Reliability، Performance، Support، Incident و Exit بسنجید. این راهنما یک مدل قابل‌محاسبه برای کسب‌وکار ایرانی ارائه می‌کند و از عددهای ثابت و جدول قیمت زودمنقضی پرهیز دارد.

خلاصه اجرایی: پاسخ کوتاه چیست؟

• Static delivery برای محتوای عمومی کم‌تغییر، Build قابل‌اعتماد و نیاز کم به State می‌تواند هزینه Infra و عملیات Runtime را کاهش دهد.
• Dynamic platform برای انتشار پرتکرار، چند Editor، Workflow، Search، Account، Transaction و Integration ممکن است هزینه تغییر را بسیار کمتر کند.
• سایت استاتیک می‌تواند JavaScript، Headless CMS، Form، Search و Function داینامیک داشته باشد؛ پس «بدون Backend» نیست.
• سایت داینامیک می‌تواند Page cache، CDN و Pre-render داشته باشد؛ پس برای هر درخواست الزاماً Database query نمی‌زند.
• امنیت، سرعت و SEO ویژگی خروجی و عملیات‌اند، نه جایزه خودکار یک Architecture label.
• برای بسیاری از محصولات، Hybrid کم‌ریسک‌تر است: صفحات عمومی Static/Pre-render و جریان‌های Account/Order/API داینامیک.

مرز Intent با راهنماهای هزینه و پلتفرم

این مقاله مالک مقایسه TCO نگهداری بر اساس Render/Operating model است. برای ساخت سقف بودجه و Reserve به راهنمای بودجه طراحی سایت و برای Cost register کامل به هزینه‌های پنهان طراحی و نگهداری سایت مراجعه کنید. انتخاب WordPress در برابر Custom، Ownership و Vertical slice نیز در مقایسه وردپرس و طراحی اختصاصی بررسی شده است. این مرزبندی از Cannibalization میان «قیمت پروژه»، «بودجه»، «هزینه پنهان» و «Static vs Dynamic» جلوگیری می‌کند.

Static و Dynamic دقیقاً به چه معنا هستند؟

Static delivery یعنی HTML صفحه پیش از درخواست کاربر ساخته یا به‌صورت Artifact آماده روی Origin/CDN نگه‌داری می‌شود. Source می‌تواند Markdown، Repository، CMS یا Database زمان Build باشد. Dynamic rendering یعنی بخشی از پاسخ بر اساس Request، User، State یا داده جاری در Runtime تولید می‌شود.

این دو محور صفر و یک نیستند. گزینه‌های رایج عبارت‌اند از:

• HTML/CSS دستی و فایل ثابت؛
• Static Site Generator با Build و Deploy؛
• Pre-render همراه Headless CMS؛
• Incremental/Deferred regeneration؛
• Server-side rendering با Cache؛
• Client-side rendering روی API؛
• CMS سنتی با Full-page cache و CDN؛
• Hybrid route-by-route یا island architecture.

بنابراین ابتدا Render path و Data path را رسم کنید؛ سپس درباره هزینه حرف بزنید.

چه چیزهایی در برچسب Static پنهان می‌مانند؟

صفحه می‌تواند Static باشد اما Newsletter، فرم، Search، Comment، Analytics، Personalization، Login یا Checkout را از سرویس ثالث بگیرد. در این حالت Runtime سرور خودتان کوچک شده، ولی هزینه و Risk به Vendor/API/Client منتقل شده است. Build pipeline، Package registry، Secret، Domain، DNS، CDN، Repository و حساب Deploy نیز بخشی از Production هستند.

یک فایل HTML بدون Dependency واقعاً ساده است؛ یک Jamstack متشکل از Framework، صدها Package، Headless CMS، Edge function و پنج SaaS لزوماً ساده یا ارزان نیست.

چه چیزهایی در برچسب Dynamic پنهان می‌مانند؟

Dynamic می‌تواند WordPress، Laravel، Django، Node.js، Commerce SaaS یا سرویس Custom باشد. همه آن‌ها Cost profile یکسان ندارند. Managed service بخشی از Patch/Backup/Scaling را به Provider منتقل می‌کند؛ Self-managed stack همان کارها را به تیم شما می‌دهد. Full-page cache می‌تواند بیشتر Traffic عمومی را بدون اجرای Application پاسخ دهد، اما Admin، Checkout و Account همچنان Runtime state دارند.

مقایسه «فایل استاتیک» با «فروشگاه داینامیک» مقایسه هم‌سطح نیست. Requirement و Outcome باید یکسان باشد.

قرارداد Workload؛ ورودی واقعی محاسبه هزینه

این قرارداد را برای سه سناریوی رشد—Low/Base/High—پر کنید. بدون آن، «Hosting ارزان‌تر» می‌تواند به انتخابی با هزینه تغییر و Incident بسیار بیشتر منجر شود.

فرمول TCO؛ همه هزینه‌ها را در یک مرز بیاورید

TCO(36m) = Initial build and migration
         + Hosting, CDN and usage
         + CMS, API and third-party subscriptions
         + Content and engineering labor
         + Security, observability and support
         + Backup, recovery and incident cost
         + Expected risk loss
         + Change and opportunity cost
         + Exit and migration reserve
         - residual/reusable value

راهنمای رسمی AWS Well-Architected Cost Optimization بر مالکیت هزینه، آگاهی از Usage، تحلیل همه اجزای Workload، مدل‌سازی و بازبینی مستمر تأکید می‌کند. این اصول مستقل از Provider هستند. TCO را ماهانه Actual-vs-Forecast کنید؛ برآورد روز خرید کافی نیست.

هزینه را به خروجی کسب‌وکار نسبت دهید

هزینه ماهانه بدون Denominator مقایسه ناقصی می‌سازد. بسته به سایت، یکی از Unitهای زیر را انتخاب کنید:

• هزینه هر صفحه تأییدشده و منتشرشده؛
• هزینه هر تغییر Content با SLA مشخص؛
• هزینه هر هزار Pageview سالم؛
• هزینه هر Lead معتبر؛
• هزینه هر Order پرداخت و Reconcile‌شده؛
• هزینه هر Active account؛
• هزینه هر دقیقه Availability در Flow حیاتی.

Cost per published page =
  (editorial labor + build/deploy + QA + allocated platform cost)
  / approved pages published

Static ممکن است Cost per request پایین و Cost per editorial change بالا داشته باشد. Dynamic می‌تواند برعکس باشد. تصمیم باید به Bottleneck کسب‌وکار وصل شود.

هزینه ساخت اولیه و Migration

در Static ساده، Template و Deployment می‌تواند کم‌هزینه باشد؛ اما Component library، CMS preview، Redirect map، Search index، Form pipeline و Automation هزینه ساخت دارند. در Dynamic، نصب CMS ارزان است ولی Data model، Role، Workflow، Plugin governance، Integration و Performance hardening می‌توانند Scope را افزایش دهند.

Migration را جدا بودجه‌بندی کنید: Content inventory، URL/redirect، Metadata، Media/alt، Author/date، Form submission، User، Order، Revision، Analytics continuity و DNS/cutover. «کپی صفحه‌ها» کل مهاجرت نیست.

هزینه مدیریت محتوا؛ Edit-to-Publish را اندازه بگیرید

ادعای «Static برای هر تغییر به Developer نیاز دارد» فقط برای بعضی پیاده‌سازی‌ها درست است. Git-based editor، Headless CMS یا Visual editor می‌تواند انتشار را غیرفنی کند، اما Setup، Preview، Schema، Build و Training هزینه دارند. CMS داینامیک هم اگر Workflow پیچیده، Plugin کند یا Preview نامطمئن داشته باشد، ویرایش ارزان نیست.

Hosting ارزان فقط یک سطر است

Static asset معمولاً با Object storage/CDN و Origin ساده قابل سرو است و Idle compute ندارد. اما Bill می‌تواند شامل Bandwidth/Egress، Build minutes، Function invocation، Image transformation، Log، Preview environment، Domain/DNS و Support باشد. Plan رایگان نیز Quota، AUP، Commercial eligibility، Suspension و Exit دارد.

Dynamic هزینه Compute/Database/Storage/Backup و گاهی License دارد، اما Managed hosting ممکن است Patch، Cache، WAF، Support و Restore را تجمیع کند. برای انتخاب Workload/SLO و آزمایش Provider از راهنمای موقعیت دیتاسنتر، Hosting و CDN استفاده کنید.

Usage curve؛ Average ارزان و Peak گران را جدا کنید

سه Curve بسازید: Baseline، Campaign peak و Failure/retry. Static delivery در Burst عمومی معمولاً ساده‌تر Scale می‌شود؛ اما API فرم، Search یا Image service ممکن است Bottleneck شود. Dynamic با Cache و Autoscaling قابل Scale است، ولی Cache miss، Bot، Cron، Queue و Database connection باید مدل شوند.

برای هر Meter مقدار، نرخ، Free allowance، سقف، Alert، Owner و رفتار پس از عبور را ثبت کنید. قیمت Provider را با تاریخ و Currency Snapshot کنید و در متن Evergreen عدد ثابت قرار ندهید.

Third-partyها؛ Backend حذف نشده، توزیع شده است

Form SaaS، Search، Comment، Auth، Analytics و Function هرکدام Data flow، SLA، Quota، Subprocessor، Price change و Exit می‌آورند. هزینه Subscription را با هزینه Integration، Failure handling، Export و Replacement جمع کنید.

اگر Form provider قطع شد، آیا Submission در Client queue می‌شود؟ آیا User پیام درست می‌بیند؟ آیا Backfill و Reconciliation دارید؟ یک Static front-end با ده Vendor می‌تواند Operations پیچیده‌تری از یک Monolith مدیریت‌شده داشته باشد.

امنیت سایت استاتیک نزدیک صفر نیست

نبود Database و Server runtime عمومی، برخی مسیرهای حمله مثل SQL injection در همان Origin را حذف می‌کند؛ این مزیت واقعی است. اما Domain/DNS takeover، Repository compromise، CI secret، Dependency آلوده، XSS در JavaScript، Third-party script، Form/API abuse، CDN misconfiguration و Account takeover باقی می‌مانند.

OWASP Top ۱۰:۲۰۲۵ درباره Software Supply Chain Failures ریسک Dependency، Build system و Distribution infrastructure را صریح می‌داند. Static site دارای Framework و CI/CD از Patch و Inventory بی‌نیاز نیست. امنیت کمترِ Runtime به‌معنای هزینه امنیت صفر نیست.

امنیت سایت داینامیک؛ Surface بیشتر، کنترل قابل‌طراحی

Admin، Authentication، Database، Plugin/Theme، File upload، API و Server runtime Surface را افزایش می‌دهند. هزینه شامل Inventory، Patch SLA، Least privilege، MFA، WAF/rate limit، Backup، Log، scan، incident response و Vendor review است. Popular بودن WordPress نه دلیل ناامنی قطعی است و نه مجوز نصب بی‌حاکمیت افزونه.

مستند رسمی WordPress Upgrading Update و Backup پیش از Upgrade را بخشی از عملیات می‌داند. Update موفق نیز باید در Staging/Production با Smoke test و Rollback قابل اثبات باشد.

Build pipeline هم Production است

در SSG، اگر Runner، Package registry یا CMS webhook خراب شود، سایت موجود شاید آنلاین بماند اما تغییر فوری منتشر نمی‌شود. این Availability محتواست. Branch protection، pinned dependency، lockfile، artifact digest، secretless/OIDC، review، SBOM، build reproducibility و rollback artifact هزینه دارند.

برای طراحی این مسیر به راهنمای CI/CD امن مراجعه کنید. Pipeline مشترک چند سایت ممکن است هزینه واحد را کم کند؛ Pipeline سفارشی برای یک سایت کوچک می‌تواند TCO را بالا ببرد.

Backup، Restore و Version؛ سه مفهوم متفاوت

Git history نسخه Source است، نه Backup کامل Production. Media، CMS content، Form submission، Search index source، Environment config، DNS، Secret reference و Provider settings ممکن است بیرون Repository باشند. Artifact قبلی Rollback سریع می‌دهد، اما داده جدید را بازیابی نمی‌کند.

در Dynamic، Database و Uploadها State حیاتی‌اند؛ Backup بدون Restore test فقط یک ادعاست. راهنمای رسمی Backup وردپرس فایل و Database را هر دو در Scope می‌گذارد. برای RPO/RTO، Drill و Runbook کامل از راهنمای بازیابی فاجعه سایت استفاده کنید.

RTO و RPO؛ هزینه Reliability از اهمیت داده می‌آید

RTO حداکثر زمان قابل‌قبول تا بازیابی خدمت و RPO حداکثر فاصله قابل‌قبول از آخرین Recovery point است. صفحه معرفی کم‌تغییر شاید با Redeploy Artifact در چند دقیقه برگردد؛ فروشگاه با Order جدید به Point-in-time recovery و Reconciliation نیاز دارد.

راهنمای رسمی AWS برای تعریف RTO/RPO آن‌ها را بر اساس Impact کسب‌وکار برای هر Workload می‌خواهد. هزینه Backup و Redundancy را با Target تعیین کنید، نه با برچسب Static/Dynamic.

Observability و Support؛ هزینه سکوت را حساب کنید

Static page ممکن است ۲۰۰ بدهد ولی Form، Search یا Analytics شکسته باشد. Dynamic page ممکن است Cache hit سریع و Checkout fail داشته باشد. Monitoring باید User journey و Dependency را بسنجد: DNS/TLS، status، content marker، build freshness، form submission، API latency/error، payment callback، queue و business outcome.

هزینه Log/Metric/Synthetic/RUM، On-call، Ticket و Runbook را وارد TCO کنید. مقاله Observability و مانیتورینگ سایت انتخاب SLI/SLO و Alert قابل‌اقدام را پوشش می‌دهد.

Performance؛ Static همیشه سریع و Dynamic همیشه کند نیست

Static delivery می‌تواند TTFB و Cacheability خوبی داشته باشد، اما Bundle بزرگ JavaScript، تصویر بی‌ابعاد، Font، Third-party و Client rendering همچنان LCP/INP/CLS را خراب می‌کنند. Dynamic با HTML server-rendered، Full-page cache، Object cache، Query optimization و CDN می‌تواند سریع باشد؛ Cache miss و Personalized route باید جدا سنجیده شوند.

مقایسه را روی Route و Journey هم‌سطح، Device/Network ایرانی و RUM انجام دهید. «CDN دارد» یا «Database ندارد» شاهد Performance نیست.

SEO؛ Google به Label معماری امتیاز نمی‌دهد

الزامات فنی رسمی Google Search بر دسترسی Googlebot، پاسخ HTTP ۲۰۰ و محتوای Indexable تأکید دارد؛ Platform خاصی را ترجیح نمی‌دهد و Indexing را تضمین نمی‌کند. هر دو معماری باید Title، Canonical، robots، Sitemap، Structured data، Internal links و Status درست تولید کنند.

Static migration می‌تواند با URL/Redirect اشتباه Traffic را از دست بدهد. Dynamic CMS نیز می‌تواند Duplicate archive، Parameter URL، Canonical اشتباه یا Render ناقص بسازد. SEO خروجی قابل Crawl/Test است، نه استدلال خرید.

نیروی انسانی و Bus factor

Static مدرن ممکن است Git، Node، Framework، CI/CD و Cloud config بخواهد؛ Dynamic ممکن است CMS administration، PHP/Database، Plugin ecosystem و Operations بخواهد. «نیروی WordPress همیشه ارزان‌تر» یا «Frontend specialist همیشه گران‌تر» گزاره پایدار نیست. Rate را از بازار و Availability واقعی تیم خودتان بگیرید.

هزینه Onboarding، Documentation، Code review، Support coverage، Vendor dependency و Bus factor را اضافه کنید. سیستمی که فقط یک Freelancer می‌تواند Deploy کند، Hosting ارزان اما Risk گران دارد.

بدهی فنی و هزینه تغییر

در Static، Pluginهای Build، Framework upgrade، Template duplication و CMS schema می‌توانند Debt بسازند. در Dynamic، Plugin sprawl، Theme override، Database schema و Patch delay Debt می‌سازند. Debt را با «قدیمی بودن» یکی نکنید؛ هزینه/ریسک انتخاب امروز برای تغییر آینده است.

Interest را با Change lead time، Defect، Upgrade effort، Security exposure و Incident بسنجید. برای Register و تصمیم Pay/Contain/Accept به راهنمای مدیریت بدهی فنی مراجعه کنید.

Vendor lock-in و Exit reserve

Static ممکن است به Build platform، proprietary image API، edge function یا CMS schema قفل شود. Dynamic می‌تواند به Plugin، Theme builder، managed database و custom shortcode قفل شود. خروجی HTML قابل دانلود به‌تنهایی Portability نیست.

Exit package را تعریف کنید: Source، Content، Media/original، Metadata، URL/redirect map، User/Order/Form data، Schema، Design token، Environment inventory، Domain/DNS/account ownership، License، build/deploy docs و deletion evidence. یک Export/Restore rehearsal کوچک پیش از قرارداد انجام دهید و Reserve مهاجرت را در TCO بگذارید.

ریسک ایران؛ ارز، Eligibility و مسیر شبکه

برای سرویس خارجی، Country eligibility، Terms، پرداخت، Currency، renewal، Support، data location، Export و Suspension را با تاریخ بررسی کنید. این راهنما هیچ مسیر دورزدن محدودیت یا ثبت اطلاعات نادرست پیشنهاد نمی‌کند. اگر Service برای Entity/کشور شما در دسترس نیست، گزینه مجاز دیگری انتخاب کنید.

سناریوی نرخ ارز Low/Base/High، ذخیره تمدید، Provider جایگزین، Domain/DNS مستقل و Export دوره‌ای داشته باشید. برای کاربران داخل ایران، Latency و Availability را از چند ISP/اپراتور بسنجید. سرویس داخلی نیز باید SLA، Security، Backup، Export و Exit را با Evidence پاسخ دهد؛ «داخلی» یا «خارجی» به‌تنهایی کیفیت نیست.

ماتریس Fit؛ به‌جای انتخاب برنده مطلق

Hard gateها را قبل از امتیاز وزنی اعمال کنید: Data/transaction correctness، Editor SLA، Legal/eligibility، RTO/RPO و Export. گزینه‌ای که Gate حیاتی را رد می‌کند با Hosting ارزان برنده نمی‌شود.

سه سناریوی واقعی برای کسب‌وکار ایرانی

برای شرکت B2B، تفاوت هزینه Hosting شاید کوچک‌تر از هزینه ویرایش و Form failure باشد. برای رسانه، Build صف‌دار یا Preview بد می‌تواند مزیت CDN را خنثی کند. برای فروشگاه، Transaction correctness و Recovery معمولاً Gate هستند؛ تبدیل Checkout به چند API پراکنده فقط برای «استاتیک بودن» ارزش نیست.

PoC باید Failure را هم آزمایش کند

یک Vertical slice هم‌سطح در دو Candidate بسازید: صفحه، ویرایش Content، Preview، Publish، Form/Integration، Analytics، SEO و Restore. سپس Failureها را تزریق کنید:

• Build dependency یا CMS webhook قطع؛
• API/Form provider timeout و Duplicate retry؛
• Cache stale و Purge fail؛
• Editor اشتباه و Rollback؛
• Database/Artifact حذف و Restore؛
• Traffic peak و Quota exceed؛
• Export و Import به مقصد خنثی.

زمان انسان، Success rate، RTO/RPO، هزینه مصرف و کیفیت خروجی را ثبت کنید. Demo فقط Happy path است؛ PoC تصمیم باید Failure و Exit را نشان دهد.

Scorecard پس از Hard gate

Weighted score = Σ(weight × evidence score × confidence)

Evidence score: 0 failed, 1 weak, 2 partial, 3 passed
Confidence: 0.5 claim, 0.8 test, 1.0 production evidence

وزن‌های نمونه: Content operations ۲۰، Functional fit ۲۰، Reliability ۱۵، Security ۱۵، ۳۶-month TCO ۱۵، Performance/SEO/Accessibility ۱۰ و Exit ۵. وزن را از Strategy خودتان بگیرید. Score بالا نباید Hard gate ردشده را پنهان کند.

Roadmap نودروزه تصمیم و اجرا

روز ۱ تا ۳۰: Workload، Cost boundary و Baseline

• Actor/Content/State/Integration/Traffic/SLO/Risk/Exit را ثبت کنید.
• Actual cost و زمان انسان سیستم فعلی را Baseline کنید.
• سه Candidate هم‌سطح و Hard gateها را تعریف کنید.
• قیمت/Terms/Eligibility را با تاریخ Snapshot کنید.

روز ۳۱ تا ۶۰: Vertical slice و Failure PoC

• Edit-to-publish، Form/transaction، SEO output و Monitoring را بسازید.
• Build/API/Cache/Restore/Export failureها را آزمایش کنید.
• TCO Low/Base/High و Cost per outcome را محاسبه کنید.
• Evidence score و Confidence را مستقل ثبت کنید.

روز ۶۱ تا ۹۰: Contract، Migration و Review

• گزینه عبورکرده از Gate را با SLA، Data و Exit contract نهایی کنید.
• Migration، Redirect، Cutover، Rollback و Hypercare را تمرین کنید.
• Budget/Usage alert، Cost owner و Review ماهانه بسازید.
• Trigger بازنگری معماری را مشخص کنید: Cadence، State، cost یا SLO.

چک‌لیست تصمیم نهایی

• Static/Dynamic بر اساس Render و Data path تعریف شده، نه نام Vendor.
• Candidateها Requirement و Outcome یکسان دارند.
• Content cadence، Editor، Preview و Publish SLA اندازه‌گیری شده‌اند.
• Hosting، CDN، Build، Function، API، SaaS، Log و Support در مرز هزینه‌اند.
• Labor داخلی و Opportunity cost حذف نشده‌اند.
• Dependency، Repository، CI/CD، Admin و Third-party در Threat model هستند.
• Backup set، RTO/RPO و Restore test تعریف شده‌اند.
• Performance و SEO با خروجی/RUM سنجیده شده‌اند.
• Low/Base/High usage و FX سناریو دارند.
• Terms/Eligibility بدون دورزدن راستی‌آزمایی شده‌اند.
• Export/Import و Exit reserve در TCO آمده‌اند.
• PoC شامل Failure، Rollback و شواهد Production-like است.

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

آیا سایت استاتیک همیشه هزینه نگهداری کمتری دارد؟

خیر. ممکن است Infra ارزان‌تر باشد اما ویرایش محتوا، Build pipeline، CMS، Search/Form SaaS، نیروی متخصص و Exit هزینه بیشتری بسازند. فقط TCO هم‌Scope و Cost per outcome پاسخ معتبر می‌دهد.

آیا WordPress یک سایت داینامیک است؟

WordPress در Source/Administration و بسیاری از Routeها Dynamic است، اما خروجی عمومی می‌تواند با Page cache/CDN مانند Artifact آماده سرو شود. برای بعضی معماری‌ها WordPress Headless نیز Source محتوا و یک SSG خروجی Static می‌سازد.

آیا امنیت سایت استاتیک تقریباً بدون هزینه است؟

خیر. سطح حمله Runtime می‌تواند کوچک‌تر باشد، اما Domain/DNS، Repository، CI/CD، Dependency، JavaScript، Third-party، Form/API، Access و Monitoring همچنان کنترل می‌خواهند. هزینه امنیت ممکن است کمتر شود، نه صفر.

سایت استاتیک برای SEO بهتر است یا داینامیک؟

هیچ‌کدام صرفاً به‌دلیل معماری امتیاز قطعی ندارند. Google باید پاسخ ۲۰۰، محتوای Indexable و دسترسی Crawl بگیرد؛ Title، Canonical، Redirect، Structured data، Internal link، Performance و کیفیت محتوا در هر دو باید درست باشند.

هزینه نگهداری سایت در ایران را چگونه برآورد کنیم؟

Workload و Unitهای مصرف را ثبت، قیمت‌ها را با تاریخ Snapshot، هزینه ریالی/ارزی را Low/Base/High، Labor داخلی و Incident/Exit را اضافه و Eligibility/Support/Export را بررسی کنید. مبلغ ثابت عمومی بدون Scope، Traffic، Cadence و SLO قابل اتکا نیست.

جمع‌بندی: ارزان‌ترین Architecture آنی نیست که Host کمتری دارد

سایت استاتیک می‌تواند Runtime ساده، Cacheپذیر و مقاومی بسازد؛ سایت داینامیک می‌تواند Content operations، State و Integration را با هزینه تغییر کمتر اداره کند. هر دو می‌توانند با انتخاب بد، Vendorهای زیاد، Debt، Backup اثبات‌نشده یا مهارت تک‌نفره گران شوند.

ابتدا Workload و Cost boundary را روشن کنید، سپس TCO و Cost per outcome را در سه سناریو بسنجید. Hard gateهای Content، Transaction، Reliability، Security و Exit را پیش از Score قرار دهید و با Vertical slice شامل Failure تصمیم بگیرید. هدف انتخاب برچسب نیست؛ ساخت Operating modelی است که تیم بتواند آن را منتشر، پایش، بازیابی و در صورت لزوم ترک کند.