Can you really run real workloads in the cloud without paying a cent? That is the promise behind the Microsoft Azure free tier, and the honest answer is: yes, but only if you understand the rules. Azure’s free offer is generous, but it is also easy to misread. People sign up expecting a permanent sandbox and then discover a charge on their card three months later because a virtual machine kept running or a storage account quietly grew. (Cloud) (Cloud computing)
This guide walks through how the free tier is structured, what the limits really mean, where newcomers trip up, and the practical habits that keep a free Azure account genuinely free. Some figures below reflect the offer as it has historically been described, and Microsoft does adjust quantities and terms from time to time, so treat any number as a starting point to confirm on the official offer before you build.
How the Azure free tier is actually structured
Azure does not have one free tier. It has a bundle of separate offers that behave differently, and mixing them up is the single biggest source of confusion.
The bundle has historically contained three distinct parts:
| Part | What it is | How long it lasts |
|---|---|---|
| Initial credit | A starting pot of money (commonly cited around US$200) usable across many services | A limited window, often 30 days |
| 12-month free services | Monthly amounts of popular services such as virtual machines, managed disks, blob storage and bandwidth | The first 12 months after sign-up |
| Always-free services | A set of services with monthly limits that do not expire, such as Azure Functions, App Service on a limited tier, Cosmos DB and Azure DevOps | Ongoing, month by month |
The credit feels like the headline, but it is the least interesting part for anyone learning the platform. It disappears fast if you spin up anything substantial, and once it is gone you are either on pay-as-you-go or locked out by a spending limit. The 12-month services are where most real experimentation happens. The always-free services are what keep a small personal project alive after year one.
There is one more wrinkle worth knowing: the free account has generally been limited to new Azure customers, roughly one per person, with some regional and program variations. If you have ever had a paid Azure subscription tied to your identity, you may not qualify. Students often get a separate route with its own credit and eligibility rules. (Azure Architecture Center: application architecture guide)
What the 12-month services really cover
The 12-month tier is the part that makes Azure feel like a real lab. It has typically included a set number of free hours per month of B-series virtual machines (both Linux and Windows), a slice of managed disk storage, a monthly allowance of blob storage, and some outbound bandwidth.
The phrase “free hours per month” is where people get burned. It does not mean one machine running all month for free. It usually means a fixed pool of hours that a machine of a certain size can consume. Run a bigger size, run two machines, or leave one running around the clock, and you can blow through the pool in days. The meter keeps running whether or not you are logged in.
A practical rule that works in the real world: treat every free VM as a temporary appliance. Start it when you need it, stop and deallocate it when you are done, and check the usage page before you walk away. Deallocating matters specifically. A stopped-but-not-deallocated machine can still consume resources and, depending on configuration, still incur charges for the underlying disk.
Managed disks are the quiet cost. Even a deallocated VM usually keeps its OS disk, and disks are billed separately from compute. If you create a VM, delete it, and forget the disk, you may keep paying for storage that does nothing. The same goes for snapshots and leftover public IP addresses.
The always-free services and their hard ceilings
The always-free tier is the most misunderstood part of the offer, because “free” here means “free up to a limit,” not “unlimited.” These services come with monthly quotas that reset, and once you cross them you either get throttled or start paying.
Azure Functions is the classic example. The free grant covers a certain number of executions and compute time per month, and beyond that the service can stop or bill depending on the plan you chose. The hosting plan you pick changes the rules entirely, so it is worth reading how Azure Functions hosting plans and their execution limits work before you deploy anything that might get traffic.
App Service on the F1 tier is another one. It is genuinely free and genuinely useful for a small site or API, but it comes with CPU and memory ceilings that make it unsuitable for anything demanding. Cosmos DB has a limited free tier with a fixed amount of storage and throughput, and Azure DevOps is free for small teams within user limits. Each of these is a real product with a real cap, not a demo.
The mental model that keeps people out of trouble: an always-free service is a quota, not a guarantee. If your code can scale, and you have not set a ceiling, it will scale into a bill. Configure the limits yourself rather than trusting the defaults.
Spending limits: the safety net you should understand before you need it
New free accounts typically come with a spending limit turned on. In plain terms, it stops charges once your credit is used up, which protects you from an accidental bill. That sounds perfect, and for a learner it mostly is.
The catch is what happens when the limit is hit. Services may be disabled, which can look like an outage if you forget the limit exists. And the limit is not permanent protection: you can remove it to move to pay-as-you-go, and some offer types behave differently. If you plan to keep a project running past your credit, you will eventually have to make a deliberate choice about billing rather than drifting into it. (Blog)
The other safety net is budgeting. Azure’s cost management tooling lets you set budgets and alerts so you get a warning before a surprise, not after. Setting a small budget with an email alert on day one is the single highest-value five minutes you can spend in a new account. It will not stop spending by itself, but it turns a silent leak into a notification.
Common mistakes that turn free into paid
Most “Azure charged me” stories follow the same handful of patterns. None of them require bad luck, just a small oversight.
- Leaving a VM running. The most common cause by far. Set a shutdown schedule and check it works.
- Forgetting attached disks and IPs. Deleting the compute does not always delete the storage or the address.
- Choosing the wrong region or size. Larger sizes and some regions consume free allowances faster.
- Assuming the credit lasts forever. It does not, and the 12-month clock starts at sign-up, not at first use.
- Scaling an always-free service past its cap. Autoscaling with no ceiling is a bill generator.
- Ignoring the usage and cost pages until month-end. By then the damage is done.
A habit that actually works: once a week, open the cost analysis view and sort by resource. Anything you do not recognize is either something you forgot or something you should delete. This takes two minutes and catches nearly everything.
Free tier versus pay-as-you-go: which one fits
The free tier is not a smaller version of a paid account. It is a trial with training wheels, and it is genuinely good at that job. It is a poor fit for anything you need to keep running reliably, because the moment you outgrow a quota you are making decisions under pressure.
| Situation | Free tier fits? | Why |
|---|---|---|
| Learning the portal and basic services | Yes | Low risk, real products, spending limit protection |
| A portfolio site or small API | Yes, within limits | App Service F1 and Functions can carry light traffic |
| A always-on production app | No | Quotas, throttling and the 12-month clock get in the way |
| Data experiments with steady growth | Rarely | Storage and throughput caps arrive sooner than expected |
| Team projects with many users | Depends | User limits on free DevOps and identity features apply |
The honest framing: use the free tier to learn and to prototype, then move to a paid plan when a project earns it. Staying on free indefinitely for something that matters is a recipe for an outage at the worst moment.
Practical setup checklist for a genuinely free account
If the goal is to experiment without paying, the order of operations matters more than any single setting.
- Sign up and note the exact date, because the 12-month clock starts then.
- Set a budget with an alert immediately, before creating any resource.
- Confirm the spending limit is on and understand what happens when it triggers.
- Pick one small project and build only what it needs.
- Schedule automatic shutdown on any VM you create.
- Tag every resource so you can find and delete it later.
- Review cost analysis weekly and delete anything idle.
That last step is the one people skip, and it is the one that matters most. Cloud resources do not clean themselves up.
For readers who want to follow how cloud pricing and platform changes play out over time, the news and blog sections on 9481.org are worth a look, and the cloud category on 9481.org covers broader platform topics that sit alongside Azure’s offer. (News)
Conclusion
The Microsoft Azure free tier is a genuinely useful on-ramp to cloud computing, but it rewards people who read the fine print. The credit is short-lived, the 12-month services are generous but time-boxed, and the always-free services are quotas rather than promises. None of that is a trick. It is just a structure that punishes assumptions and rewards a few simple habits: set a budget, schedule shutdowns, delete what you are not using, and know exactly when your 12 months began.
Treat the free tier as a laboratory, not a permanent home. Learn on it, prototype on it, and when a project deserves to stay online, move it to a paid plan on purpose. Do that, and the free tier delivers exactly what it promises: real cloud experience at zero cost, with no unpleasant surprises on your card.
Frequently asked questions
How long does the Azure free tier last?
It depends on which part you mean. The initial credit is typically usable for a limited window, often around 30 days. The 12-month services run for a year from sign-up. The always-free services do not expire, but they come with monthly limits that reset. Because terms change, confirm the current durations on the official offer before you plan around them.
Is the Azure free tier really free, or will I get charged?
It can be genuinely free if you stay within the limits and keep the spending limit on. Charges usually appear because a resource kept running, a disk was left behind, or an always-free service was allowed to scale past its quota. The free tier is free by default, not by guarantee, so budget alerts and weekly cleanup are what keep it that way.
What happens when my Azure credit runs out?
With a spending limit in place, services may be disabled until you either add payment or remove the limit to move to pay-as-you-go. The account does not vanish, but the workloads stop. If you want to keep a project alive past the credit, plan the switch deliberately rather than discovering it during an outage.
Can I get the Azure free tier more than once?
Generally no. The free account has historically been limited to new Azure customers, roughly one per person, with some regional and program restrictions. If you already have a paid subscription tied to your identity, you may not qualify. Students often have a separate route with its own eligibility rules and credit.
Which services are always free in Azure?
The always-free list has included Azure Functions within an execution grant, App Service on the limited F1 tier, a limited Cosmos DB free tier, and Azure DevOps for small teams. Each has a monthly cap on usage, and exceeding it can mean throttling or billing. The list changes, so check the current free services page rather than relying on older articles.
How do I avoid surprise charges on a free Azure account?
Set a budget with an email alert on day one, confirm the spending limit is active, schedule automatic shutdown for every virtual machine, and delete attached disks and unused public IPs when you remove a machine. Then review cost analysis weekly and sort by resource. Anything idle or unrecognized should be deleted, not left for later.
