Azure's free account is the odd one out among the big-three free compute offers, and the difference is not a detail. Azure has no always-free virtual machine. Oracle and Google both include a VM that runs at no cost indefinitely. Azure's free VM hours are a twelve-month introductory benefit, and on month thirteen the same machine starts billing at pay-as-you-go rates.

That single fact should determine whether you read further. If you want a box that is still free in two years, this is the wrong article — read the Oracle or Google guides instead. If you want a generous first year, Azure's offer is the most generous of the three for that year, and the rest of this article is about using it deliberately.

What this article is: a reading of Microsoft's published free-account terms and VM size documentation, checked on 12 August 2026, with the credit-model arithmetic worked out. What it is not: a review or benchmark. Yangworks does not run workloads on Azure and measured nothing here. Every specification is quoted from Microsoft Learn; everything derived from those numbers is shown as arithmetic; everything else is labelled judgment.

What you actually get

Microsoft's free account page lists the virtual machine benefit as 750 hours each of B1s, B2pts v2 (Arm-based), and B2ats v2 (AMD-based) burstable VMs, under the product heading Azure Virtual Machines for Linux or Windows, in the twelve-month category rather than the always-free one. Alongside it: a $200 credit to spend on Azure services within 30 days.

Read 750 hours each carefully, because it is the most valuable and least understood phrase in the offer. A calendar month has at most 744 hours. So 750 hours funds one instance of that size running continuously, with margin — and the allowance is per size, not pooled. Three sizes, 750 hours each:

B1s        750 h/month   x86    ) all three, concurrently,
B2pts_v2   750 h/month   Arm    ) for twelve months,
B2ats_v2   750 h/month   AMD    ) at no VM-hour cost

Author judgment: this is the strongest thing about the offer and almost nobody uses it. Most people spin up one B1s and leave the other two allowances untouched. If you want a year of running a small three-node setup — a service, a database host, and a build or staging box — or you want to test the same workload on x86, AMD, and Arm side by side, the allowance already covers it.

The sizes, precisely

These are the documented figures, and the memory column is the one that matters.

Size         vCPU   Memory   Base CPU   Processor
B2pts_v2       2     1 GiB      20%     Ampere Altra (Arm64, 3.0 GHz)
B2ats_v2       2     1 GiB      20%     AMD EPYC 7763v (Milan)
B1s            1     1 GiB      10%     Intel (previous-generation Bv1)

Note what the "2 vCPU" sizes are not. B2pts_v2 and B2ats_v2 have two vCPUs and one gibibyte of memory — they are the "t" (tiny-memory) members of their series. If you were planning around "2 core, 2 GB," Azure's free tier does not contain that machine. The next size up, B2pls_v2 at 2 vCPU and 4 GiB, is not in the free offer.

And note what B1s is. Microsoft's documentation places it in the Bv1 series, which carries a standing notice: These virtual machine sizes are a previous generation series. While older VM sizes are supported until further notice, we recommended using newer generations for improved performance and security. Its documented base CPU performance is 10%, against 20% for the v2 sizes, and it banks 6 credits an hour to a 144-credit ceiling, against 24 an hour to 576.

Author judgment: B1s is the size everyone picks, because it is the one they have heard of, and it is the weakest of the three. Same memory, half the baseline CPU, a quarter of the credit ceiling, one vCPU instead of two, and a previous-generation platform. Unless you specifically need an Intel x86 host or Generation 1 VM support, start with B2ats_v2 or B2pts_v2 and treat B1s as the third box rather than the first.

The burst credit model, and what 20% really means

Every size in the free offer is burstable, which means the CPU figure in the table is a ceiling you visit, not a level you occupy. Microsoft describes the mechanism plainly:

The virtual machine accumulates CPU credits when a workload is operating below the base CPU performance threshold and, uses credits when running above the base CPU performance threshold until all of its credits are consumed. Upon consuming all the CPU credits, a Bsv2-series virtual machine is throttled back to its base CPU performance until it accumulates the credits to CPU burst again.

The documented figures for the 2-vCPU free sizes: base CPU performance 20%, initial credits 60, credits banked per hour 24, maximum banked credits 576.

Those numbers are internally consistent and worth converting into time, because the vendor never does. A credit is one vCPU-minute at full speed. Base performance of 20% on a 2-vCPU VM is 0.4 vCPU continuously, which is 0.4 × 60 = 24 vCPU-minutes banked per idle hour — exactly the documented banking rate. The cap of 576 credits is therefore 576 ÷ 24 = 24 hours of accumulation.

Sustained, credits exhausted   0.4 vCPU-equivalent
Full bank (576 credits)        576 vCPU-minutes
  spent on both vCPUs at 100%  288 minutes ≈ 4.8 hours
Time to refill from empty      24 hours of idling

Author judgment: this is a good fit for spiky work and a bad fit for steady work. A build server, a CI runner, or a service with a daily peak banks credits overnight and spends them when needed. Anything that holds CPU above 20% around the clock — a busy database, a transcoder, a chatty gateway under constant load — drains the bank within hours and then runs permanently at 0.4 vCPU, which is slower than the spec sheet suggests and confusing if you did not expect it.

The eligibility rules that disqualify people

Microsoft's footnote is restrictive in three specific ways. The twelve-month benefit is available only to new customers who have not previously had an Azure account or received 12 months of free services — a prior account, including a long-abandoned one, disqualifies you permanently. It is not offered to customers signing up directly for pay-as-you-go in China and India. And there is a step that catches people out: you must move to pay-as-you-go within 30 days to continue receiving 12 months free services.

That last one deserves emphasis. The twelve months of free services are not automatic for the full year just because you signed up. If you let the initial 30-day credit window lapse without converting to pay-as-you-go, you lose the remaining free-services entitlement. Converting is what keeps the benefit alive; it does not by itself start charging you for things inside the free allowances.

What happens at month thirteen

Nothing dramatic, which is the problem. Microsoft's FAQ states that after the free-for-12-months window ends, resources keep running but you'll be billed for them at pay-as-you-go rates.

There is no interruption, no email at the moment of transition that you will necessarily act on, and no change in the console. A VM you forgot about simply becomes a line item.

Do this on day one, not day 360:

1. Set a budget alert at a low threshold (e.g. $1) with
   an email action. This is the safety net.
2. Put the account creation date and "+12 months" in
   your calendar, with the resource group name in the note.
3. Tag every resource you create under the free benefit,
   so a year later you can tell which ones were free.

Storage is billed separately — verify your allowance

Microsoft's own size documentation says it directly, for every B-series page: Disk storage is billed separately from virtual machines. The 750 VM hours cover compute, not the managed disk the VM boots from.

The free account does include a managed-disk allowance among its twelve-month services, but I did not verify the current figure to a standard I am willing to publish, and it has changed over time. Check the current free-services list for the managed disk line before you provision, and size your OS disk to fit it. This is the most likely source of a small unexpected charge in month one, exactly as the disk-type default is on Google Cloud.

What you can realistically run

Reasoning from documented specifications, not measurement. I have not run these workloads on these instances.

One gibibyte is the binding constraint on all three free sizes, and it constrains what you co-locate far more than what you run. New API, a commonly self-hosted LLM gateway, documents its deployment requirements as SQLite with a mounted /data directory or a remote MySQL ≥ 5.7.8 or PostgreSQL ≥ 9.6, under Docker or Docker Compose, and 64-bit only (amd64 / arm64); 32-bit systems are not supported. It publishes no minimum CPU or RAM figure.

Both Arm and AMD free sizes satisfy the architecture requirement, which is worth noting — the Arm allowance is not a second-class option for containerised Go services, and arm64 images are explicitly supported.

Fits well      one compiled service + SQLite, per box
               reverse proxy, tunnel endpoint, bastion
               CI/build runner (bursty: ideal credit fit)
               staging environment for a year

Use the        service on one box, MySQL or PostgreSQL on
three boxes    another, build/staging on the third — rather
               than stacking everything onto one 1 GiB VM

Poor fit       steady CPU above 20% (credit exhaustion)
               anything wanting 2 GB+ RAM on one box
               a permanent home for something you care about
               (it stops being free in twelve months)

A caveat on one popular use case: routing a subscription-based AI CLI through a self-hosted proxy may conflict with that provider's terms of service. That is a licensing question, not a capacity question, and free infrastructure does not change the answer.

How to apply

1. Sign up with an account that has never had Azure before.
   A card is required for verification.
2. Note the 30-day credit window; convert to pay-as-you-go
   inside it to keep the 12-month benefits.
3. Create VMs using B1s, B2pts_v2, or B2ats_v2 by exact
   size name. Neighbouring sizes are not free.
4. Size the OS disk to the free managed-disk allowance.
5. Set a budget alert immediately.
6. Calendar the 12-month expiry with resource names.

Who should not use this

Anyone who has held an Azure account before, since the benefit is one per customer, ever. Anyone in China or India signing up directly for pay-as-you-go. Anyone who needs the machine to still be free in year two — the twelve-month cliff makes this a poor foundation for a long-lived personal service, and a genuinely bad one for client work you will not be actively managing when the year is up. And anyone whose workload holds CPU steadily: the burst credit model is a real constraint, and 0.4 vCPU sustained is what you get after the bank empties.

Author judgment: the honest use of Azure's free account is as a time-boxed resource. A year of three free VMs is a lot of runway for learning, for staging, for a build farm, or for a project you intend to migrate or shut down. Treating it as permanent infrastructure is the mistake the offer invites and does not warn you about.