Azure Support Plans Compared: Severity Levels, Response Times and What to Buy

It is 9:40 on a Tuesday and checkout is throwing errors. You have restarted the app, checked your logs, and ruled out your code — the failure is inside an Azure service you do not operate. So you go to open a support case, and discover, at the worst possible moment, that your subscription is on the free Basic support plan, which includes no technical support at all. There is no engineer to call. That realisation is what this article exists to prevent. Azure support plans are the contracts that decide whether a Microsoft engineer will help with a broken service, how fast they promise to respond, and how much that costs per month — and almost nobody reads them until they are already in an incident.

The confusing part is that “support” on Azure is two things wearing one word. Every customer, even on a free trial, gets billing and subscription support plus the entire self-help layer — docs, Azure Advisor, Service Health, the status page, the Q&A forums. What the paid plans add is technical support: the right to open a case about a misbehaving service and have an engineer work it under a published response-time commitment. The lever that turns a slow response into a fast one is the severity level you assign — and the maximum severity you are allowed to choose is itself capped by the plan you bought.

By the end you will know what each plan includes, how Severity A/B/C map to the response commitments behind them, and — the question that matters — which plan to buy for a personal learning subscription, a pre-revenue startup, and a production system that loses money when it is down. We lead with the mental models, lay the plans and severities out as scannable grids, walk a ticket from “Help + support” to resolution, and finish with a USD/INR cost comparison.

What problem this solves

The problem is not “Azure is broken.” It is the gap between needing expert help and being able to get it — and discovering, mid-incident, that the gap is hours long because of a plan choice someone made (or never made) months ago. What breaks without the right plan is response time: on Basic your only escalation for a genuine Azure-side fault is the Q&A forums and Microsoft’s own remediation via Service Health — fine for a hobby project, unacceptable when a Severity A outage costs ₹50,000 an hour. Buying wrong hurts both ways: a production team stuck on Basic when a managed service misbehaves, or a solo learner paying for Professional Direct they will never use. This bites every team moving from “playing with Azure” to “running something other people depend on” — and the fix is to match the plan to what an outage actually costs.

The whole field in one frame — every category of “support” on Azure, whether it costs money, and what it does:

The last row is the one that matters — everything above it you already have, free, forever. The plans in this article exist to buy that last row, and the response speed attached to it.

Learning objectives

By the end of this article you can:

• Distinguish billing/subscription support (free for everyone) from technical support (paid plans only), and explain why a free Azure account still cannot open a technical case.
• Name the four main Azure support plans — Basic, Developer, Standard, Professional Direct — and state what each includes and roughly costs per month.
• Explain Microsoft’s Severity A / B / C model: what business impact each represents, the response-time commitment behind each, and which severities each plan lets you raise.
• Pick the right plan for three concrete situations: a personal learning subscription, a pre-revenue startup, and a revenue-bearing production workload.
• Open a technical support case from the portal — choosing the right severity, contact method and the az CLI path — and know what information to attach so the first response is useful.
• Reason about the cost trade-off, in both USD and INR, between a fixed monthly support fee and the cost of an hour of unsupported downtime.
• Avoid the common traps: assuming free-tier support, over-buying Professional Direct, mis-rating severity, and confusing an SLA credit with a support response commitment.

Prerequisites & where this fits

You should have an Azure account and understand the platform’s basic shape: a tenant (your Microsoft Entra ID directory), one or more subscriptions (the billing and access boundary), and resources in resource groups. If those words are fuzzy, read Azure Subscriptions Explained: Types, Billing Boundaries and When to Create a New One and Azure Resource Hierarchy Explained: Subscriptions, Resource Groups and Resources first — support plans attach at the subscription/account layer. No operations experience is assumed; finding Help + support and running a Cloud Shell command is enough.

This sits in the Operations & Cost track, upstream of incident response. It pairs with Azure Monitor and Application Insights: Full-Stack Observability — observability tells you what is wrong and whether it is your code or Azure’s, and the plan decides who helps once it’s Azure’s. On cost, the monthly fee is a line item like any other, covered in Azure Free Account, Credits and Spending Caps: Start Learning Without a Surprise Bill for learners and Azure FinOps and Cost Management: Controlling Cloud Spend at Scale for teams.

One scope note: support plans are a different contract from service-level agreements (uptime targets with bill credits). Both get loosely called “SLA”; this article is about support plans, with the distinction drawn explicitly later.

Core concepts

Four mental models make every comparison in this article obvious.

Support is two products under one word. The first, self-help and billing/subscription support, is free with every account (the rows above). The second, technical support, is the paid one — a case about a malfunctioning service, worked by an engineer under a published response commitment. The plans you buy unlock and accelerate the second.

The severity level sets the clock. You choose a severity — A (critical), B (moderate), or C (minimal) — stating business impact. Microsoft attaches a response-time commitment to each, and it gets faster as your plan gets more expensive: the same Severity A case gets a quicker first response on Professional Direct than on Developer. Severity is the dial; the plan decides how responsive the dial is.

“Response time” is time to first response, not time to fix. The most misunderstood number here. The commitment is the initial response time — how quickly an engineer makes contact and begins working — not that your problem is resolved by then. Read every number here as “time until someone qualified starts helping.”

The maximum severity you can raise is capped by your plan. You cannot mark every case Severity A to jump the queue — lower plans cap the severity you may choose, and a learner-grade plan cannot raise the critical severity at all. A plan choice is implicitly a choice about the worst incident you can escalate fast.

The vocabulary in one table

Before the comparison grids, the moving parts side by side (the glossary repeats these for end-of-article lookup):

Hold those four models — two products, severity sets the clock, response ≠ resolution, severity capped by plan — and the rest is filling in the numbers.

The four Azure support plans

Azure offers a small, stable ladder of plans; exact prices vary by region and currency and shift over time, so treat the figures as order-of-magnitude and confirm the live price before buying. The four that matter for almost everyone:

A few clarifications the table cannot carry on its own:

Basic is not “no support” — it is “no technical support.” You still get the self-help stack, can still open billing/subscription cases, and are covered by Azure’s handling of platform outages via Service Health. What you cannot do is open a “Service X is misbehaving for my workload” case — usually fine for a learning subscription.

Developer is the “building, not yet live” plan — the cheapest tier that unlocks technical cases, with deliberate trade-offs: business hours only, email/portal contact, and no critical severity, because Microsoft assumes Developer workloads are not production.

Standard is the default for anything in production. It adds 24×7 coverage, phone as well as email, and — the reason it exists — a roughly one-hour initial response on Severity A, putting an engineer on a 3 a.m. break within the hour.

Professional Direct (ProDirect) is Standard plus a relationship — faster critical response, proactive guidance, and ProDirect delivery (pooled engineer guidance, operations reviews, advisory webinars). It targets larger or business-critical estates; for a single small workload it is usually overkill.

What each plan includes, feature by feature

The price table answers “how much”; this one answers “what do I get”:

A clean staircase: everyone gets the top five rows; Developer adds case access (business-hours, no critical); Standard makes it 24×7, phone-reachable, one-hour-critical; ProDirect layers proactive delivery on top.

Above Professional Direct sits Unified Support — a negotiated enterprise agreement priced as a percentage of overall Microsoft spend, covering Azure and the rest of the Microsoft estate (Microsoft 365, Dynamics, on-prem) with named contacts and fastest engagement. Out of scope here; if your org has it, your Azure technical-support entitlement flows from it, not the per-subscription plans above.

Severity levels and what “response time” really means

The severity model is the other half — it governs how fast, within a plan, a case is answered. Microsoft uses three severities, defined by business impact, not by how annoyed you are:

The crucial pairing is severity with plan: the same severity is answered faster on a costlier plan, and lower plans forbid the higher severities. The grid below shows the approximate initial-response commitments — treat them as the right shape and confirm current numbers on the Azure support page, as Microsoft tunes them:

Two things to read off this grid: Developer has no Severity A row (so it cannot serve critical production response at any speed — why production teams go to Standard), and the numbers shrink left-to-right, so paying more buys a faster clock for the same severity. Every cell is an initial-response commitment.

“Response” means engagement, not resolution

Because the plan governs only how fast help starts, your real time-to-resolution on a Severity A is shaped as much by what you bring. Four things move it: the quality of the case you file (logs, timestamps and resource IDs let the engineer act on the first contact; “it’s broken” forces a round-trip); your responsiveness (the clock stalls if you go dark after filing); severity accuracy (over-rating clogs your own queue, under-rating delays the response you were entitled to); and the correct contact method (a phone-reachable Sev A gets a call — email-only may miss the fast engagement at 2 a.m.).

Severity is not the same as SLA — keep the two contracts separate

Procurement and incident conversations constantly mix these up — two different contracts both loosely called “SLA”:

A service credit is a partial rebate of what you paid for the unavailable service — it never refunds your business losses, and is unrelated to how fast support answers. When someone says “we need a better SLA,” ask which one they mean.

How to open a support case (and choose the right severity)

Knowing the plans is theory; opening a clean case under pressure is the skill. On any plan that includes technical support, the path is the same.

Portal path. Help + support (the ? menu or search bar) → Create a support request, then walk four steps:

For billing, subscription or quota issues you choose those issue types in step 1 instead of “Technical” — and they work on every plan, including Basic. Only the Technical type requires a paid plan.

Opening and inspecting cases from the CLI

You can also drive cases from the az CLI’s support extension — handy for scripting and runbooks. List existing tickets, then create one with the same fields the portal asks for:

# One-time: add the support extension
az extension add --name support

# List your existing tickets (most recent first)
az support tickets list \
  --query "[].{name:name, severity:severity, status:status, title:title}" -o table

# Create a technical case (severity = minimal | moderate | critical → C/B/A)
az support tickets create \
  --ticket-name "checkout-5xx-$(date +%Y%m%d%H%M)" \
  --title "Production checkout returning 5xx from App Service" \
  --description "Checkout failing since 09:32 IST; restart and our logs rule out app code." \
  --severity "critical" \
  --contact-first-name "Vinod" --contact-last-name "H" \
  --contact-method "phone" --contact-email "oncall@example.com" \
  --contact-phone-number "+91-00000-00000" --contact-country "IN" \
  --contact-language "en-US" --contact-timezone "India Standard Time" \
  --problem-classification "<classification-id>"

The --problem-classification ID identifies “this service + this category of problem”; discover it via az support services list and az support services problem-classifications list. The API rejects critical if your plan does not permit it — the CLI surfacing the per-plan severity cap. (Support cases are operational actions, not declarative resources, so there is no Bicep “support ticket” — what belongs in IaC is the surrounding Service Health alerts and action groups that page the right people when Azure reports a platform problem.)

What to attach so the first response is useful

The fastest path through any case is a first message an engineer can act on without asking for basics. Attach: exact timestamps (with time zone) the problem started, the resource ID(s) involved, what you already ruled out (your code, a restart, a recent deploy), error strings / status codes / correlation IDs, your Service Health result, and a one-line business-impact statement. Each removes a round-trip the engineer would otherwise burn on first contact.

Architecture at a glance

There is no system diagram here because support is a process and a set of contracts, not a deployed architecture — but picturing three concentric rings around your workload tells you where a problem goes. The innermost ring is yours: your logs, metrics and Application Insights, where you confirm the failure is real and decide whether it is your code or Azure’s. Most incidents are resolved here without touching support, and skipping this ring is the most common reason a case stalls (“we can’t reproduce; what are your logs showing?”).

The middle ring is free Azure self-service, passed through next regardless of plan. Service Health answers the most valuable triage question — “is this a known Azure platform incident affecting my region/service, or just me?” If it already shows an outage you may not need a case at all; Microsoft is on it. Azure Advisor, the forums and docs live here too. This ring costs nothing and is identical on Basic and Professional Direct.

The outermost ring is paid technical support, reached only once the inner two confirm the failure is real, on Azure’s side, and not an already-tracked incident. This ring your plan gates: closed for technical cases on Basic, business-hours/lower-severity on Developer, 24×7 up to Severity A on Standard and ProDirect. The plan does not change the path inner → middle → outer — only whether, and how fast, the last ring is open. Choosing it deliberately means that on the night the inner rings prove it is Azure’s fault, the outer ring is already open at the speed you need, not a locked door you discover at 09:40 on a Tuesday.

Real-world scenario

Northwind Retail runs a mid-sized e-commerce site on Azure: App Service storefront, Azure SQL, Cache for Redis, a payment integration. Annual online revenue is about ₹40 crore — roughly ₹46,000 per hour of trading on an average day, far more during their twice-yearly sales. For eighteen months they ran on the free Basic plan, because at migration a junior engineer saw “Basic — included” and reasonably assumed it covered support the way the free compute tier covered compute.

The reckoning came during a Friday-evening sale. Checkout started returning intermittent 5xx errors. The on-call engineer did the right first-ring work — confirmed in Application Insights the failures were real, restarted the app, ruled out their own code and recent deploy (the errors correlated with Azure SQL timeouts), and saw Service Health show no platform incident for their region. So this looked workload-specific and Azure-side. They went to Help + support, chose Technical, and hit the wall: on Basic the technical case option was unavailable. No engineer to summon, only the public forum and waiting.

They lost roughly two hours of degraded checkout at peak before mitigating it themselves by scaling the database tier on a hunch — about ₹1.8 lakh of impaired revenue, plus a sale-day reputational stumble. The next Monday the decision took five minutes: move production to Standard (~$100, ~₹8,500/month). A single two-hour incident had cost more than eighteen years of Standard’s fee — and Standard would have put an engineer on a Severity A case within the hour, 24×7, by phone.

The sequel proves the point. Four months later an Azure-side regional storage latency issue nibbled at their cart service during the next sale. This time the engineer filed a clean Severity A in three minutes — timestamps, resource IDs, the App Insights correlation, a “ruled out our code” note, and a phone contact attached. An engineer called back inside the hour, tied it to a developing regional issue Microsoft was already investigating, and gave a concrete mitigation. Same class of incident, a completely different night. Northwind kept Standard for production and put Developer (~$29) on their sandbox so the dev team could ask service questions without touching the production plan.

Advantages and disadvantages

A paid plan is a recurring cost bought against an unpredictable risk — the trade-off, two columns:

The advantages dominate the instant a workload carries revenue or reliability obligations to other people — the fee is trivially small against a single bad incident, and Standard is almost always correct. The disadvantages dominate for learning and non-production work, where nothing is lost to a slow answer. The expensive mistake is misjudging which world you are in: a production team clinging to Basic to save ₹8,500/month, or a hobbyist talked into ProDirect by a checklist. Match the plan to what an hour of downtime actually costs you.

Hands-on lab

Free and safe: you inspect your support entitlement and the free self-service tooling, and dry-run the case flow without submitting a paid case.

1. See which support plan your account holds. In the portal, Help + support shows it at the top. From the CLI, get the subscription context:

# The subscription and its state (context for what support is available)
az account show --query "{name:name, id:id, state:state}" -o table

2. Confirm Service Health — the free triage you’ll use first in any incident:

# Recent Service/Resource Health issues for the subscription
az rest --method get \
  --url "https://management.azure.com/subscriptions/$(az account show --query id -o tsv)/providers/Microsoft.ResourceHealth/events?api-version=2022-10-01&\$filter=properties/eventType eq 'ServiceIssue'" \
  --query "value[].{title:properties.title, status:properties.status, impact:properties.impactStartTime}" -o table

Nothing returned is good — no active service issues right now.

3. List the services and problem categories you could file under (read-only, works even on Basic):

az extension add --name support 2>/dev/null
az support services list --query "value[].{service:properties.displayName, id:name}" -o table | head -30

4. Find a service’s problem classification (the ID you’d pass to --problem-classification):

SERVICE_ID="<paste-a-service-id-from-step-3>"
az support services problem-classifications list \
  --service-name "$SERVICE_ID" \
  --query "value[].{problem:properties.displayName, id:name}" -o table | head -20

5. Walk the portal wizard without submitting. Help + support → Create a support request, choose Technical, pick a service, advance to step 2, then close instead of creating — you’ve now seen where severity and contact method are chosen.

6. Right-size in your head. Compare your workload’s cost-of-an-hour-down to ~₹8,500/month for Standard. If one hour down costs more than a month of Standard — true for almost any revenue workload — Standard is justified.

Teardown. Nothing to tear down — every step was read-only or a dry run. Optionally az extension remove --name support.

Common mistakes & troubleshooting

Support-plan pain is rarely a “bug” — it’s a wrong assumption surfacing at the worst moment. The common failure modes, as symptom → root cause → how to confirm → fix:

The meta-lesson: most “support failures” are expectation or preparation failures. Two minutes of inner-ring work (logs, Service Health, a clear impact statement) and an accurate severity turn a frustrating case into a fast one — on the same plan.

Best practices

Crisp, production-grade rules for getting support right before you need it:

• Set the plan to the workload’s risk, per subscription. Production → at least Standard; non-production/sandbox → Basic or Developer. Never run production on Basic.
• Buy support before the incident, not during. The five-minute upgrade you’d otherwise do mid-outage costs you the outage. Decide it on a calm Monday.
• Wire Service Health alerts + action groups now. Get paged on platform incidents automatically, so you often know it’s Azure’s fault before you’d have opened a case. Free, and lives in your observability setup.
• Pre-build a case template with the fields you always attach — timestamps, resource IDs, “what we ruled out,” impact line — so a 2 a.m. Sev A is fill-in-the-blanks.
• Rate severity honestly. Reserve A for production-down-no-workaround; over-rating clutters your own queue, under-rating forfeits the fast response you paid for.
• Use phone contact for Severity A. A 24×7 critical case should reach you by phone; email-only defeats the point at 3 a.m.
• Do the inner-ring work first. Confirm the failure is real and Azure-side before filing — it shortens every case and is often where you fix it yourself.
• Right-size up and down as you grow. Promote a sandbox to Standard when it goes live; drop ProDirect if the estate that justified it shrank.
• Don’t confuse SLA credits with support. Support = response speed; SLA = uptime target + bill credit, claimed through billing, not the technical case.
• Keep contact details current. A correct on-call email/phone and time zone routes the response to a human who’s actually awake.

Security notes

Support touches sensitive operational data, so a few least-privilege rules apply.

Limit who can open and manage cases with RBAC. The built-in Support Request Contributor role lets a principal create and manage cases without broader access to your resources — assign it to your on-call group rather than handing them Owner just to file a ticket:

# Grant only the ability to manage support requests, nothing more
az role assignment create \
  --assignee "<oncall-group-object-id>" \
  --role "Support Request Contributor" \
  --scope "/subscriptions/$(az account show --query id -o tsv)"

Redact secrets from case attachments. Diagnostics are invaluable, but strip connection strings, keys, tokens, passwords and full PII before attaching logs. Share resource IDs, correlation IDs, timestamps and error codes — never credentials. The case thread should never carry a live secret.

Verify who is contacting you. Confirm anyone claiming to be “Azure support” is responding within the case you opened in the portal. Treat unsolicited “support” calls or emails referencing your incident with suspicion, and never share credentials or one-time codes.

Keep the contact identity tidy. The technical/security/billing contacts on the account should be monitored team aliases, not one person who may leave — stale contact info means a critical-incident callback or security notice reaches no one.

Cost & sizing

The decision reduces to one comparison: a predictable monthly fee versus the unpredictable cost of an hour of unsupported downtime. Approximate figures (at ~₹85/$; confirm live prices and FX before committing):

What drives the “right” number is not the fee — all four are small next to real incidents — but the cost of an hour down:

Two sizing notes that catch people out. Support is billed per account/subscription, so you need not put ProDirect everywhere — many teams run Standard on production and Basic/Developer on dev and sandbox, paying the premium only where it protects revenue. And the figures are order-of-magnitude: Microsoft adjusts support pricing over time, so price the live plan and convert at your real FX rate before signing off the budget. Net: assume ₹0 for learning, ~₹8,500/month as the realistic floor for a production workload, and ProDirect only when the estate’s size and criticality — not one app — justify it.

Interview & exam questions

These map to AZ-900 (Azure Fundamentals), which explicitly covers support plans, and to operations/FinOps discussions in AZ-104 and AZ-305.

1. Difference between billing support and technical support on Azure? Billing/subscription support (invoices, quotas, account issues) is free for every customer including the free tier. Technical support — a case about a malfunctioning service, worked by an engineer under a response commitment — requires a paid plan. Basic can do the former, not the latter.

2. Name the four main plans and the headline thing each adds. Basic (free; self-help + billing support, no technical cases); Developer (technical cases, business hours, email, lowest severities); Standard (24×7, phone, ~1-hour Sev A — the production default); Professional Direct (Standard plus faster critical response and proactive delivery).

3. What do Severity A, B and C mean? They rate business impact: A = critical, significant production loss with no workaround; B = moderate, impaired but functioning; C = minimal, a question or low-priority issue. Severity selects which response commitment applies.

4. Does “1-hour Severity A response” mean the problem is fixed in an hour? No — it is the initial response commitment; an engineer engages within about an hour. Resolution depends on the problem. The plan governs how fast help starts, not how long it takes.

5. Which plan for a personal learning subscription, and why? Basic. It is free and includes all the self-help you need; there is no revenue or reliability obligation to justify paying for technical-case access, and a slow answer costs nothing.

6. A startup going live with a revenue app — minimum sensible plan? Standard: the cheapest plan with 24×7, phone, and ~1-hour Sev A. Developer cannot raise Severity A at all, so it is insufficient for production.

7. Why not mark every case Severity A for the fastest response? Lower plans cap the severity you may choose (Developer can’t raise A), and over-rating erodes trust and clutters your own queue. Severity should reflect genuine impact so the fast response is there when truly warranted.

8. Support response-time commitment vs service-level agreement (SLA)? A response commitment (plan + severity) is how fast an engineer engages a case you open. An SLA is the uptime % Azure targets for a service; missing it earns a service credit (a rebate of that service’s charge), not a refund of your losses.

9. What free Azure tool tells you whether an issue is a platform-wide outage? Azure Service Health (with Resource Health) — it shows service issues, maintenance and advisories for your subscriptions/regions, answering “is it Azure or me?” and often saving a case for an incident Microsoft already handles.

10. Let on-call open cases without giving broad access — how? Assign the built-in Support Request Contributor RBAC role: it permits creating and managing cases without Contributor/Owner access to resources.

Quick check

1. True or false: a free Azure account can open a technical support case about a malfunctioning service.
2. Which is the cheapest plan that offers 24×7 support, phone contact, and a ~1-hour Severity A response?
3. Does “initial response time” promise that your problem is resolved within that time?
4. Which free Azure tool answers “is this a platform-wide outage or just me?”
5. A service credit under an SLA refunds your business losses — true or false?

Answers

1. False. A free/Basic account gets billing and subscription support plus all self-help, but technical cases require a paid plan (Developer, Standard, or Professional Direct).
2. Standard. Developer is cheaper but is business-hours/email-only and cannot raise Severity A; Standard is the cheapest 24×7 + phone + ~1-hour-Sev-A plan.
3. No. It’s the time until an engineer engages and starts working the case — not time to fix. Resolution depends on the problem.
4. Azure Service Health (with Resource Health) — it shows service issues, maintenance and advisories affecting your subscriptions and regions.
5. False. A service credit is a partial rebate of what you paid for that unavailable service, capped and tied to the missed SLA — it never refunds your downstream business losses.

Glossary

• Support plan — The contract setting your technical-support entitlement and response speed (Basic, Developer, Standard, Professional Direct).
• Technical support — The paid right to open a case about a malfunctioning service and have an engineer work it under a response commitment.
• Billing & subscription support — Free help with invoices, quotas, and account/access issues; available on every plan including Basic.
• Severity (A/B/C) — The business-impact rating assigned to a case (critical / moderate / minimal); it selects the response-time commitment that applies.
• Initial response time — The commitment for how fast an engineer first engages a case (e.g. ~1 hour for Sev A on Standard). Not a resolution time.
• Service Health — Azure’s free service showing platform outages, maintenance and advisories affecting your subscriptions and regions.
• SLA (service-level agreement) — The uptime % Azure targets for a service; a separate contract from support response time.
• Service credit — A partial rebate of a service’s charge when its SLA is missed; not a refund of your business losses, and unrelated to support response.
• Professional Direct (ProDirect) — The premium per-subscription plan adding faster critical response and proactive, account-level delivery on top of Standard.
• Unified Support — A negotiated enterprise agreement covering Azure and the wider Microsoft estate, priced as a percentage of Microsoft spend.
• Support Request Contributor — A built-in RBAC role permitting creation and management of support cases without broader resource access.
• Problem classification — The service-plus-category identifier that routes a technical case to the right engineering queue (the CLI’s --problem-classification).

Next steps

• Azure Subscriptions Explained: Types, Billing Boundaries and When to Create a New One — the layer support plans attach at.
• Azure Monitor and Application Insights: Full-Stack Observability — the inner-ring tooling that confirms a failure and whether it’s your code or Azure’s.
• Troubleshooting Azure App Service: 502/503 Errors, Cold Starts & Restart Loops — a worked example of the self-diagnosis you do before a case.
• Azure FinOps and Cost Management: Controlling Cloud Spend at Scale — fold the monthly support fee into a managed cost model.
• Azure Free Account, Credits and Spending Caps: Start Learning Without a Surprise Bill — for learners on Basic, how to stay free while you experiment.