Azure Cloud Economics: Pricing, TCO, SLAs, Service Lifecycle & Support

The cloud’s most famous promise is “pay only for what you use” — but that single sentence hides almost everything that matters about running on Azure. What exactly are you paying for? When does the meter start? Why did egress cost more than the virtual machine? What does Microsoft actually guarantee in exchange for the money, and what happens when a service falls short? And when something breaks at 2 a.m., who picks up the phone? This lesson answers all of it.

Cloud economics is the pillar that turns a hobbyist into an architect. Anyone can click “Create”; the person who can predict the bill, defend the design on cost, read an SLA correctly, and know which support plan a workload needs is the person organisations actually trust with production. It is also a heavily weighted theme on the AZ-900: Azure Fundamentals exam — the “describe cost management” and “describe SLAs and service lifecycle” domains together account for a meaningful slice of the questions. We go from zero, define every term, and stay grounded in real decisions and real numbers (illustrative INR figures included, because that is the currency you will be budgeting in).

Learning objectives

By the end of this lesson you can:

• Explain the shift from CapEx to OpEx and why the cloud’s cost model changes how organisations budget.
• Compare Azure’s three core pricing models — pay-as-you-go (consumption), reserved, and spot — and say when each one wins.
• Name the five biggest cost drivers (compute, storage, data transfer/egress, region, and tier) and reason about a bill.
• Use the Pricing Calculator and the Total Cost of Ownership (TCO) Calculator for the jobs each is designed for.
• Govern spend with Microsoft Cost Management: cost analysis, budgets, Azure Advisor cost recommendations, and tags.
• Read a service-level agreement (SLA) correctly, calculate a composite SLA for chained services, and explain how availability zones and region pairs raise it.
• Distinguish the stages of the service lifecycle — private preview, public preview, and general availability (GA) — and state precisely what “preview means no SLA” implies.
• Choose between the four Azure support plans (Basic, Developer, Standard, Professional Direct) and use Azure Service Health.

Prerequisites & where this fits

You need only basic IT literacy and a rough idea of what a virtual machine, a database, and storage are — no prior cloud billing experience is assumed, and every financial term is defined the first time it appears. A free Azure account is enough to follow the hands-on lab (the lab itself costs nothing). This is a Foundations lesson in the Azure Zero-to-Hero course and the economics counterpart to the “What is Azure?” lesson: where that one taught you how Azure is organised, this one teaches you how Azure charges you and what it guarantees. It builds the financial vocabulary that every later design lesson quietly assumes.

CapEx vs OpEx: the mental shift

Before a single price, understand the kind of spending the cloud represents, because it reshapes how a whole organisation budgets.

• Capital expenditure (CapEx) is money spent up front to buy assets you own and use for years — servers, storage arrays, the data-centre building, networking hardware. You pay a large lump sum, the asset depreciates on the books over its useful life, and you carry the cost of capacity whether or not you use it. Buying twelve servers because you might need them at Diwali means eleven of them sit idle for most of the year — money already spent, sunk.
• Operational expenditure (OpEx) is money spent on ongoing consumption — you rent capacity and pay as you go, like an electricity bill. There is no asset to own or depreciate; the expense hits the period in which you used the service.

Azure converts most IT spending from CapEx into OpEx. The practical consequences are the heart of the cloud business case:

The instinct to build early: in the cloud, elasticity has financial value. The ability to give capacity back is worth as much as the ability to add it, because every idle resource is now a line item you could simply switch off.

The three pricing models

Almost every Azure charge resolves to one of three pricing models. Knowing which one fits a workload is one of the most valuable cost skills there is.

How to think about each:

• Pay-as-you-go (PAYG), also called consumption-based pricing, is the default: the meter runs only while the resource is in use, billed at fine granularity (per second for VMs, per million executions for Functions, per GB-month for storage). Maximum flexibility, highest unit price. Perfect when you cannot predict demand or the workload is temporary.
• Reserved capacity rewards predictability. Reservations commit you to a specific resource type (for example, a VM size in a region) for one or three years; Azure Savings Plans for compute commit you to a fixed hourly spend across many compute services instead of a specific SKU, trading a little of the discount for far more flexibility. Either way, you are pre-paying for a baseline you know you will run, so Microsoft gives a steep discount. The risk is symmetrical to its reward: an unused reservation is a negative discount — you paid up front and got nothing.
• Spot sells Azure’s unused capacity at a deep discount on the condition that Microsoft can evict your workload (reclaim the machine) when paying customers need the capacity, giving only about 30 seconds’ notice. Brilliant for batch jobs, CI/CD agents, rendering, and big-data processing that can checkpoint and resume; unsuitable for anything that must stay up, such as a production database.

A separate, stackable discount worth naming here is the Azure Hybrid Benefit: if you already own eligible Windows Server or SQL Server licences with Software Assurance, you can apply them to Azure VMs and pay only for the compute, saving a large fraction of the licensing cost. It layers on top of reservations.

What actually drives the bill

When a bill surprises someone, the cause is almost always one of five drivers. Internalise these and you can estimate costs in your head and read an invoice with confidence.

Two of these trip up beginners hardest:

• Egress is the silent driver. Sending data into Azure is free; sending data out — to users on the internet, or between Azure regions — is charged per GB. A multi-region design that copies data between regions, or an API that streams large responses to the internet, can run up egress that dwarfs the compute. (There is normally a small free monthly egress allowance, after which the meter starts.)
• Tier and region multiply everything. The same workload in a premium region on a Premium tier can cost several times what it costs in a cheaper region on a Standard tier. Always ask: do I need this tier, in this region?

A useful estimation instinct: Cost ≈ (what) × (how much) × (how long) × (where) × (which tier) — the resource, its quantity, its run-time, its region, and its service level. Get those five right and your estimate is usually within a sensible margin.

The two calculators: Pricing vs TCO

Microsoft gives you two free, login-free web calculators, and a common exam (and real-life) mistake is reaching for the wrong one. They answer different questions.

The distinction in one line: the Pricing Calculator prices a future Azure design; the TCO Calculator compares your existing on-premises costs against the equivalent on Azure to justify a move. If a question asks “estimate the monthly cost of a planned set of Azure VMs,” that is the Pricing Calculator. If it asks “show leadership the savings of migrating our data centre,” that is the TCO Calculator.

Governing spend: Microsoft Cost Management

Estimating cost before you build is half the job; controlling it after you build is the other half. Microsoft Cost Management is Azure’s free, built-in toolset for monitoring, allocating, and optimising spend. Its four pillars:

Each tool, a little deeper:

• Cost analysis is your dashboard. It shows month-to-date spend, a forecast to month-end, and lets you group and filter — by service to find the biggest consumers, by resource group to see per-application cost, or by tag to see per-team cost. This is where investigations start.
• Budgets are the safety net. A budget does not automatically stop spending — it is an alerting mechanism. You set a monetary (or usage) limit and choose alert thresholds; when actual or forecast spend crosses them, Azure emails the owners (and can trigger an action group to run automation, such as a notification or a Logic App). Crucial exam point: a budget warns; it does not by itself cap or shut anything down.
• Azure Advisor is a free service that continuously analyses your resources across five pillars — Cost, Security, Reliability, Operational Excellence, and Performance — and produces concrete recommendations. Its Cost recommendations are gold: shut down or right-size underused VMs, buy reservations for steady workloads, and remove orphaned resources like unattached managed disks and idle public IPs.
• Tags are the connective tissue of cost governance. Because every cost record can carry a resource’s tags, a consistent tagging scheme (owner, environment, cost centre, project) lets you split one big invoice into per-team, per-project, or per-environment views — the basis of showback (showing each team its cost) and chargeback (actually billing it back). Tags are inherited by convention, not automatically, so enforce them with Azure Policy.

Service-level agreements (SLAs)

An SLA is Microsoft’s formal, contractual promise about a service’s availability — the percentage of time it will be up in a given period — and the service credit (a partial refund) you can claim if it misses. SLAs are expressed as a percentage of uptime, and the difference between two percentages that look close is dramatic once you translate it into allowed downtime.

Read this table once and the stakes are obvious: moving from 99.9% to 99.99% shrinks tolerated downtime from nearly 9 hours a year to under an hour. That extra “nine” is exactly what availability zones buy you.

Composite SLA: chaining services multiplies risk

Here is the single most important — and most commonly tested — SLA concept. When your application depends on several services in series (a request must pass through all of them to succeed), the overall SLA is not the lowest one. You multiply the individual SLAs, because any component failing breaks the request. This product is the composite (or compound) SLA.

Composite SLA = SLA₁ × SLA₂ × SLA₃ × …

A worked example. Suppose a web request flows through App Service (99.95%) → Azure SQL Database (99.99%) → Azure Storage (99.9%), each as a hard dependency:

0.9995 × 0.9999 × 0.999 = 0.99840  →  about 99.84%

The composite SLA (~99.84%) is lower than the weakest single component (99.9%), because the small risks compound. The more services you chain in series, the lower the combined promise — a sobering reason to keep critical paths short.

The opposite move is redundancy in parallel: deploy two independent copies of a component so the request succeeds if either works. Parallel redundancy raises availability (the chance both fail at once is the product of their tiny failure probabilities), which is precisely why we add zones and regions. The maths is the inverse: combined failure = failure₁ × failure₂, so two 99.9% instances in parallel approach 99.9999%.

How availability zones and region pairs raise the SLA

• Availability zones (AZs) are physically separate datacentres within one region, each with independent power, cooling, and networking. Spreading a workload across zones means a single datacentre failure no longer takes you down — which is why zone-redundant deployments earn the 99.99% tier where a single instance would only get 99.9%. Zones lift you one “nine” without leaving the region (so latency stays low and there is no cross-region egress).
• Region pairs are two regions in the same geography that Microsoft pairs for disaster recovery — they are updated at different times and Microsoft prioritises restoring at least one of the pair after a broad outage. Replicating across a region pair protects you from a whole-region failure (a natural disaster, say) — protection that zones alone cannot give — and underpins multi-region “five nines” designs. The trade-off is added complexity, latency, and cross-region egress cost.

The ladder to remember: single instance → 99.9%; availability set / multiple instances → 99.95%; availability zones → 99.99%; multi-region → toward 99.999%. Each rung adds resilience, and cost.

The service lifecycle: preview vs GA

Not every Azure feature is production-ready, and the service lifecycle tells you how finished a thing is. There are three stages.

The phrase “preview means no SLA” is exam-critical and has a precise meaning: while a service is in preview (private or public), Microsoft makes no availability guarantee and you cannot claim service credits if it goes down or misbehaves. Preview features may also change their API, change their pricing, or be withdrawn entirely before GA. The rule of thumb: explore in preview, depend in GA. Use previews to learn and to plan, but build production systems on GA services so you are covered by an SLA and full support. (Microsoft also publishes retirement notices when a service is being deprecated — the other end of the lifecycle — typically with a year or more of notice.)

Azure support plans

When something goes wrong, the support plan on your subscription decides how fast Microsoft will help and how much hand-holding you get. There are four (excluding the bespoke enterprise agreements). They are cumulative: each tier adds to the one below.

What actually changes as you climb the tiers:

• Basic is free on every subscription and is purely self-service: documentation, community forums, the Azure status page, Azure Service Health, and Azure Advisor. You can raise billing and subscription-management requests, but not paid technical support cases. Most learners and hobbyists live here.
• Developer adds the ability to open technical support cases, answered during business hours, for non-production environments — the right plan while you build and experiment but before you go live.
• Standard is the usual choice once you run production: 24×7 technical support with around a one-hour response target for critical, production-down issues, by phone and email.
• Professional Direct is for business-critical estates: everything in Standard plus faster, prioritised response and proactive guidance from Microsoft (architecture reviews, best-practice advice, an escalation point). For the very largest customers there are tailored Unified Support agreements above this.

A clean way to remember the decision: learning → Basic; dev/test → Developer; production → Standard; business-critical → Professional Direct.

Azure Service Health

Independent of your support plan, Azure Service Health is a free, personalised dashboard of the health of the Azure services you use. It surfaces three things: Service issues (active Azure outages affecting your resources right now), Planned maintenance (upcoming work that may affect you), and Health advisories (changes and deprecations that need your attention). You can set alerts on it so you are notified the moment an issue touches a region or service you depend on. Do not confuse it with the Azure status page (the global status of all Azure, for everyone) or with Resource Health (the health of one specific resource instance). Service Health is the personalised middle layer — and your first stop when “is it me or is it Azure?”.

The diagram ties the pillars together: the pricing models and cost drivers feed the calculators and Cost Management on the spend side, while the SLA ladder, service lifecycle, and support plans form the value-and-assurance side of the same coin.

Hands-on lab

You will explore the real cost and health tooling in your own subscription — entirely within the free tier, creating no billable resources. All you need is a free Azure account and Azure Cloud Shell (the browser-based terminal in the portal). Everything below is read-only or trivially reversible.

Step 1 — Open Cloud Shell. In the Azure portal, click the terminal icon (>_) in the top bar and choose Bash. Cloud Shell is free; you are only billed for the small backing storage if you opt into it (a few rupees a month — you can decline and use an ephemeral session).

Step 2 — Inspect your subscription and current spend context.

# Confirm which subscription you are in
az account show --output table

# List the resource providers — these are the catalogues of services you *could* be billed for
az provider list --query "[?registrationState=='Registered'].namespace" --output table | head

Expected output: a table with your subscription name/ID and a list of registered providers (e.g. Microsoft.Compute, Microsoft.Storage). This is the surface area of what can generate cost.

Step 3 — Create a budget with an alert (this is free; a budget is metadata, not a billable resource). Replace <SUBSCRIPTION_ID> with the ID from Step 2.

# Set a ₹500 monthly budget that alerts the account owner at 80% and 100%
az consumption budget create \
  --budget-name "learn-monthly-cap" \
  --amount 500 \
  --category Cost \
  --time-grain Monthly \
  --start-date 2026-06-01 \
  --end-date 2027-06-01 \
  --resource-group "$(az group list --query '[0].name' -o tsv)" 2>/dev/null \
  && echo "Budget created" || echo "If this errors, create the budget in Portal → Cost Management → Budgets (the CLI surface varies by environment)"

Expected output: Budget created (or the fallback hint). Either way, now open Portal → Cost Management → Budgets to see it: this is the safety net that warns you before spend runs away. Note that it only alerts — it does not stop anything.

Step 4 — Read Azure Advisor’s cost recommendations (free, read-only).

# List any cost-saving recommendations Advisor has for your subscription
az advisor recommendation list --category Cost --output table 2>/dev/null \
  || echo "No cost recommendations yet (expected on a brand-new/empty subscription)"

Expected output: a (possibly empty) table. On an empty learner subscription there may be nothing yet; on a real subscription you would see “right-size VM”, “delete unattached disk”, etc.

Step 5 — Check Service Health from the portal. Go to Portal → Service Health → Service issues. You will see any active Azure incidents affecting your services and regions. Click Health alerts to see how you would wire up notifications. This is read-only.

Validation. You have (a) confirmed your billing scope, (b) created a budget you can see under Cost Management, © queried Advisor for savings, and (d) viewed Service Health — the four spend-and-assurance tools from this lesson, in your own account.

Cleanup. Delete the budget so nothing lingers:

az consumption budget delete --budget-name "learn-monthly-cap" \
  --resource-group "$(az group list --query '[0].name' -o tsv)" 2>/dev/null \
  || echo "If created in the portal, delete it under Cost Management → Budgets"

Cost note. This entire lab is free. Budgets, Advisor, Cost analysis, and Service Health are all no-cost features. If you opted into Cloud Shell’s persistent storage, that is roughly ₹5–₹15/month for the small file share — delete the backing storage account if you do not want even that.

Common mistakes & troubleshooting

Best practices

• Right-size before you reserve. Tune the resource to the real workload first; only then buy a reservation or savings plan for the steady baseline, so you commit to the correct size.
• Tag everything from day one with a consistent scheme (owner, environment, cost centre, project) and enforce it with Azure Policy so cost is allocatable from the start.
• Set budgets on every subscription with alerts at 50/80/100% — the cheapest insurance against a runaway bill.
• Review Azure Advisor cost recommendations on a cadence (monthly): kill idle VMs, delete orphaned disks and IPs, and act on reservation suggestions.
• Match the pricing model to the workload shape: spiky → PAYG, steady → reserved/savings plan, interruptible → spot.
• Design the critical path short. Fewer in-series dependencies means a higher composite SLA; add redundancy (zones, then regions) only where the SLA demands it, because each rung adds cost.
• Estimate egress explicitly in any multi-region or internet-facing design — it is the cost everyone forgets.

Security notes

• Cost data is sensitive. Spend patterns reveal architecture, scale, and business activity. Restrict who can view billing and Cost Management with RBAC (e.g. the Billing Reader / Cost Management Reader roles) rather than handing out broad access.
• Budget alerts as a security signal. A sudden, unexplained spend spike can be the first sign of a compromise — crypto-mining on hijacked VMs, or data being exfiltrated (which shows up as an egress spike). Treat unexpected budget alerts as a potential incident, not just a finance issue.
• Don’t trade the SLA for a quiet life. Resist disabling redundancy (zones, backups, geo-replication) purely to cut cost on a workload whose availability and recovery requirements actually demand it — the saving is illusory if an outage costs more than the redundancy.
• Mind preview governance. Preview features may not have completed the same security and compliance review as GA services; keep them out of regulated production paths.

Interview & exam questions

1. What is the difference between CapEx and OpEx, and how does the cloud change the balance? CapEx is up-front spend on owned assets that depreciate; OpEx is ongoing pay-as-you-go consumption. The cloud converts most IT spend from CapEx to OpEx, removing up-front cost and over-provisioning risk and making elasticity financially valuable.
2. Name Azure’s three pricing models and when you’d use each. Pay-as-you-go (consumption) for spiky/unpredictable/short-lived workloads; reservations or savings plans for steady 24×7 baselines (commit 1–3 years for up to ~72% off); spot for interruptible, fault-tolerant batch work (up to ~90% off, but can be evicted).
3. What’s the difference between a Reservation and a Savings Plan? A reservation commits to a specific resource (e.g. a VM size in a region); a savings plan commits to a fixed hourly compute spend across services — more flexible, slightly smaller discount. Use a savings plan when the workload’s exact SKU may change.
4. A web app calls App Service (99.95%) → SQL DB (99.99%) → Storage (99.9%) in series. What’s the composite SLA? Multiply them: 0.9995 × 0.9999 × 0.999 ≈ 99.84% — lower than the weakest component, because in-series risks compound.
5. How do availability zones and region pairs each raise availability, and how do they differ? Zones are separate datacentres within a region (lift a single instance from 99.9% to 99.99%, protecting against a datacentre failure with no cross-region latency). Region pairs are two regions for disaster recovery (protect against a whole-region outage; add latency and egress cost).
6. Which calculator do you use to justify a data-centre migration, and which to size a new Azure app? TCO Calculator compares your existing on-prem costs to Azure (the migration business case); Pricing Calculator estimates the cost of a planned Azure design.
7. Does an Azure budget stop you from overspending? No. A budget alerts at thresholds (and can trigger an action group); it does not cap or shut down resources by itself. To actually prevent spend, use automation, quotas, or policy.
8. What does “preview means no SLA” mean in practice? While a service is in private or public preview, Microsoft gives no availability guarantee and no service credits; the feature may change or be withdrawn. Use previews for evaluation only; run production on GA services.
9. Which support plan would you put on a production workload, and which is free? Basic is free on every subscription (self-service only, no paid technical support). Production typically needs Standard (24×7, ~1-hour critical response). Business-critical estates use Professional Direct.
10. What’s the difference between Azure Service Health, the Azure status page, and Resource Health? The status page is the global status of all Azure; Service Health is personalised to the services and regions you use; Resource Health is the health of one specific resource instance.
11. Why is data egress a notorious cost driver? Inbound data is free, but outbound data (to the internet or across regions) is metered per GB after a small allowance — multi-region replication and chatty internet APIs can run egress that exceeds the compute cost.
12. How do tags help with cost? Tags (key/value labels) attach to resources and flow into cost records, letting you slice spend by team, project, or environment for showback/chargeback. Enforce a consistent scheme with Azure Policy.

Quick check

1. Spreading a workload across availability zones typically raises its SLA from 99.9% to which tier?
2. True or false: an Azure budget automatically shuts down resources when you hit 100%.
3. You have a steady production database running 24×7 for the next three years. Which pricing model is cheapest?
4. Which calculator builds the business case for migrating an on-premises data centre to Azure?
5. Three services chained in series have SLAs of 99.9%, 99.95% and 99.99%. Is the composite SLA higher or lower than 99.9%?

Answers

1. 99.99% (“four nines”) — zone redundancy is what earns that extra nine.
2. False. A budget only alerts (and can trigger automation via an action group); it does not stop spending on its own.
3. A reservation (1- or 3-year) — or a savings plan — because the baseline is predictable and steady; commitment buys a large discount.
4. The Total Cost of Ownership (TCO) Calculator, which compares current on-prem costs against the Azure equivalent.
5. Lower — in-series SLAs multiply (0.999 × 0.9995 × 0.9999 ≈ 99.84%), so the composite drops below the weakest component.

Exercise

Using only free tools, produce a one-page “cloud economics brief” for a hypothetical app — a small internet-facing web app (one App Service) plus one Azure SQL Database, expected to run 24×7 in your nearest region, with modest internet traffic:

1. Estimate the monthly Azure cost in the Pricing Calculator (pick Basic/Standard tiers; include a rough egress figure). Note the total in INR.
2. Compute the composite SLA for the App Service → SQL chain (multiply the two services’ SLAs) and write down the tolerated downtime per month it implies.
3. Propose one resilience upgrade (e.g. zone redundancy) and state how it changes the SLA and roughly the cost.
4. Pick the right support plan for this app once it’s in production, and justify it in one sentence.
5. List two cost-control measures you’d put in place on day one (e.g. a budget with alerts; a tagging scheme).

This mirrors exactly what an architect is asked to produce before a project is approved.

Certification mapping

This lesson maps directly to AZ-900: Microsoft Azure Fundamentals, primarily the domains:

• Describe cost management in Azure — factors affecting cost (compute, storage, egress, region, tier), the Pricing Calculator vs the TCO Calculator, and Microsoft Cost Management (cost analysis, budgets, tags), plus Azure Advisor cost recommendations.
• Describe features and tools for managing and deploying Azure resources — Azure Advisor and Service Health.
• Describe Azure cost, SLAs, and service lifecycles — purpose of SLAs, how to read uptime percentages, composite SLA calculation, factors that affect an SLA (zones, region pairs), and the preview vs GA service lifecycle.

CapEx/OpEx and the cloud economic benefits also appear in the “describe cloud concepts” domain. Mastering this material covers a substantial, high-frequency portion of the AZ-900 question pool.

Glossary

• CapEx (capital expenditure) — up-front spend on owned assets that depreciate over years.
• OpEx (operational expenditure) — ongoing pay-as-you-go spend on consumed services.
• Pay-as-you-go (PAYG) / consumption pricing — billed per unit actually used, no commitment, highest unit price.
• Reservation — 1- or 3-year commitment to a specific resource for a steep discount.
• Savings Plan — 1- or 3-year commitment to a fixed hourly compute spend across services; more flexible than a reservation.
• Spot pricing — deeply discounted spare capacity that Azure can evict on short notice.
• Azure Hybrid Benefit — applying owned Windows/SQL Server licences to cut Azure compute cost.
• Egress — outbound data transfer (to the internet or across regions), which is metered; ingress is free.
• Pricing Calculator — estimates the cost of a planned Azure design.
• TCO Calculator — compares existing on-premises costs to the Azure equivalent.
• Microsoft Cost Management — built-in tooling for cost analysis, budgets, and allocation.
• Budget — a spend threshold that alerts (it does not cap) when crossed.
• Tag — a key/value label on a resource used for cost allocation and governance.
• Azure Advisor — free service giving cost, security, reliability, operational, and performance recommendations.
• SLA (service-level agreement) — Microsoft’s contractual uptime promise, with service credits if missed.
• Composite (compound) SLA — the product of the SLAs of services chained in series.
• Availability zone — a physically separate datacentre within a region.
• Region pair — two regions in a geography paired for disaster recovery.
• Service credit — a partial refund granted when an SLA is missed.
• Preview (private/public) — a pre-GA service stage with no SLA and limited support.
• General availability (GA) — the stable, fully supported, SLA-backed stage.
• Support plan — the tier (Basic/Developer/Standard/Professional Direct) setting your support speed and scope.
• Azure Service Health — personalised dashboard of Azure issues, maintenance, and advisories affecting your resources.

Next steps

Now that you can reason about cost and SLAs, ground them in the physical platform they describe. Continue to Azure Global Infrastructure: Geographies, Regions, Availability Zones, Fault & Update Domains, which makes the availability concepts in this lesson concrete — exactly how zones, region pairs, fault domains, and update domains deliver the SLA ladder you just learned to calculate. From there, the commitment-strategy and FinOps lessons go deeper on squeezing the bill once you are running real workloads.