Azure Virtual Machines - Simply Explained

An Azure Virtual machine sounds complicated until you break it into parts. Every VM is built from the same handful of choices how much power it gets, what kind of disk it uses, how it connects to the network, and which system it boots into. You make all of those calls, which is exactly why some people love virtual machines and others stall out. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. By the end of this, you'll look at any Azure VM and know what you're actually paying for. What an Azure VM really is. An Azure Virtual Machine is a computer you rent from Microsoft's Cloud instead of buying and running one yourself. And that single idea explains most of what follows. You don't own a box in a data center. You rent a slice of one and use it like any other machine. Azure runs several kinds of computing that scale up and down with your needs. And the virtual machine is the one you reach for when you want more control over the environment than the other options hand you. Microsoft looks after the physical hardware, the buildings, the power, and the cooling. You never touch a server rack. The trade is simple. You skip the upfront cost of hardware. The noise of a machine humming in a closet, and the panic when a fan dies in the middle of the night. In return, you still set up the operating system, install your own software, and keep everything patched. Nobody does that part for you, and that's the deal you're accepting. This model has a name, and it's worth learning because you'll run into it everywhere. People call it infrastructure as a service or IaaS for short. Microsoft runs the building and you run the machine inside it, which is the whole point of splitting the work this way. Newcomers often assume the cloud takes control away from them. With virtual machines, the opposite is true because you get more control here than almost any other Azure service gives you. What you pay for. That control is the work you take on yourself. Renting a machine works a lot like renting a place to live. You get the space, you can make it your own, and someone else deals with the roof, but the building still sets the ground rules. The machine is yours to shape and it's not yours to keep. That setup is more common than you'd think. A developer spins up a machine to write and test code, then deletes it when the job is done. A growing app adds machines when traffic spikes and shuts them down when it falls. Companies even connect a cloud machine straight into their own network, so it behaves like an extension of the office. There's a reason this model caught on so fast. When demand is unpredictable, renting beats owning because you can match your spending to what you actually use. A project that needs one hundred machines for one week can have them for one week, and then it hands them back. That flexibility is hard to match when the hardware has to sit in a room you pay for all year long. One thing stays constant. No matter how you use it, you still own everything running on top of that machine, from the operating system down to the last line of your code. And that ownership is what people either love or underestimate. So the idea is simple and the work is real. Before you rent anything, it helps to know exactly what you're renting, because a virtual machine isn't one thing. It's a collection of parts, and every one of them has a job. The parts of a virtual machine, a virtual machine, looks like one line on a bill, but it's really several parts working together, and each one has its own job. Once you can name them, the whole service stops feeling mysterious. Start with compute, which is the brain. When you pick a size, you're choosing how many virtual processors the machine gets and how much memory comes with them. That single choice sets how fast the machine can work, and how much it can hold in memory at once. Then there's storage and it lives on managed disks. Azure handles the storage account behind the scenes, so you never manage the plumbing yourself. You pick a disk type based on how fast you need it, and the options climb from standard HDD to standard SSD to premium SSD and on up to premium SSD, V2 and Ultra Disk for the most demanding work. One habit worth copying is to keep your data on a separate disk from the operating system, so if a machine ever fails, you can detach that data disk and attach it to a fresh one. Networking is the third part. Every virtual machine sits inside a virtual network, gets a private address, and can get a public one if you want it reachable from the internet. A network security group acts like a doorman deciding which traffic gets in and which gets turned away. Images are the fourth part. An image is the starting template the machine boots from, and Azure ships plenty of Linux and Windows versions, along with custom images you build yourself. Pick the wrong image and you'll be redoing setup later, so it's worth a minute of thought up front. A pattern runs through that whole list. Each part answers a single question, and together they describe one complete machine. So nobody has to hold the whole thing in their head at once. Sizes are the fifth part, and there where beginners freeze so they get their own section in a moment. What shows up on the bill matters just as much as the parts themselves. Azure charges by the hour based on the size and the operating system of your machine, and for a partial hour, you pay only for the minutes you used. The network card has no separate charge, and a network security group costs nothing either. Local temporary storage is free, but it gets wiped whenever the machine is deallocated. So it's for caches and scratch files, never for anything you need to keep the operating system. Disk does cost money at normal disk rates, and it's usually around one hundred and twenty seven gigabytes. Sometimes you also pay for an operating system license and you can cut that cost if you already own the license. Some sizes throw in fast local storage. As a bonus, those machines carry a D in their name, and the local disk feels genuinely quick because it sits right next to the processor. Use it for caches, buffers, and temporary database files, and remember that it disappears the moment it's deallocated. Because it was never built to hold anything permanent. It also helps to know which parts you can change later. You can resize the machine, swap a disk, and attach or detach storage without rebuilding anything from scratch. The region you chose is the hard one to change because the machine lives where its disks live, so that first decision deserves more care than the rest. A quick word on the operating system image. Since it surprises people, the image decides whether you're running Windows or Linux, and it also sets the starting size of the system disk. Some images start much smaller than the usual size, which is why two machines that look identical can build differently. The bundle matters because the parts fail and bill independently. Compute is the part you can stop paying for when the machine is off, but the disks and other resources attached to it keep their own. Small charges. Miss that, and a machine you thought was switched off can quietly show up on your bill. That list sounds long, and it's long. The trick is that you never face it all at once because you make one choice, then the next, and each decision narrows the field. By the time you reach the last option, most of the work is already done. Picking the right size. Hundreds of sizes sounds like a trap, and it can be if you try to read the whole list. The good news is that the names follow a system, and once you see it, you can safely ignore most of the list as your Azure sorts sizes into six types based on what they're built to do. There's general purpose compute optimized, memory optimized, storage optimized, GPU accelerated and FPGA accelerated, and most everyday work lands in the first three within those types. A handful of families do the heavy lifting at the cheap end since the. A family good for small jobs and quick tests. The B family is the interesting one because it's the only Azure size that runs on a credit system. It. Banks credits while it sits mostly idle, spends them when you need a burst of speed and slows back to its baseline once the credits run out. That makes it a good fit for a web server or a development machine that only works hard now and then. The D family is the general purpose workhorse, balanced between processor and memory, and it's where a lot of production apps and databases live. If your work leans toward processing power with less memory, the F family fits batch jobs and busy application servers. Memory heavy work like large databases and analytics points to the E family instead. And when you need graphics processors for visual work or artificial intelligence, that's the N series. Then there's the name itself, and this is the part that makes the list readable. Let us tell you the family and its features. And the number tells you how many virtual processes you get. If you spot an A in the name that machine runs on AMD chips and a P means it runs on ARM chips. No letter at all means Intel. Choosing comes down to one question, which is what the work actually needs. A website that mostly waits for visitors needs very little. A video render or a simulation needs a lot of processing. A database that holds everything in memory needs room to breathe. Match the machine to the work and the list shrinks fast. The rule of thumb is to start smaller than you think you need and resize later. Because changing a machine's size is a normal supported move. People burn money by guessing big on day one and never coming back down. And the fix is almost always a smaller machine than they first picked. Picture a small team launching a web app. They start on a Burstable B size, watch the numbers for a month and move up to a D size only when the data tells them to. That path costs a fraction of starting big and hoping. One more thing worth knowing is that Azure adds new generations over time, which is why you see a version number like V5 on the end of some names. Newer versions usually bring better performance for the same money, so when two sizes look similar, the higher version is often the better buy. Just remember that some sizes aren't offered in every region, and that's a normal limitation rather than a mistake you made. There's a habit that separates people who spend well from people who spend a lot, and it's a boring one. Watch the machine for a week before you decide it's too slow. Most performance problems aren't solved by a bigger machine. They're solved by finding the one thing that's actually struggling, whether that's memory, disk speed, or raw processing. You can see what a size will cost before you commit, which means you can compare a few options side by side instead of guessing. And that's a lot calmer than picking blind and hoping for the best. So sizing comes down to matching a machine to a job and watching the numbers for a while. But a bigger decision sits underneath all of it, and it's the one that actually costs people money. VM or managed service. The most expensive mistake in this whole topic isn't picking the wrong size. It's building a virtual machine when you never needed one. Azure gives you three broad ways to run things with virtual machines. You manage the machine. A managed platform often called PaaS, runs your app without you ever touching a server, and services like app service and container apps fit here. Serverless, which people call FAS, is the other end where you hand over code and something like Azure Functions runs it for you on demand. The trade across all three is the same. Take more control and you manage more. Hand more off and you touch less, but you also get less to customize. Managing a machine isn't abstract. It means installing updates, watching for security patches, tuning performance, and being the person who gets called when something breaks at night. A managed platform takes most of that off your plate, and in exchange, it decides a lot about how your app runs. Microsoft's own guidance says this plainly virtual machines carry high operational overhead and full infrastructure management, and they suit teams with traditional IT experience. App service carries low overhead and functions, carries very little of it. The practical answer is this if you're moving an existing server exactly as it is, or you need the operating system, custom software, or a graphics processor, a virtual machine is the right call. If you're building a new web app or an API, a managed service usually gets you there faster and costs less to keep running. There are also jobs where a virtual machine is basically the only answer lifting an old server into the cloud without rewriting it. Running software that a platform can't host, and running SAP or Oracle databases all point to virtual machines. So does hosting virtual desktops. One pattern shows up again and again. Teams build on a virtual machine because it feels safe and familiar, then slowly move pieces onto managed services as they get comfortable. There's nothing wrong with that path as long as you know you're on it. The reverse happens to a team, starts on a managed platform, hits a wall, the platform won't let them past, and moves that single workload onto a virtual machine. Both directions are normal and neither one is a failure. You might think the choice is about cost, but it's actually about time a virtual machine can look cheaper on paper and turn out far more expensive in the hours you spend keeping it healthy. While a managed service can cost more each month and hand you back a job you never wanted, none of this makes one option better than another. It just means the choice should follow the job, and the job should never bend to fit the tool. The choice matters. And what decides whether you regret it is the bill, which is exactly where we go next. What it actually costs. Now let's get to the question everyone asks first, which is what this costs and how you keep it from running away from you. The base is pay as you go as your bills. an hourly rate that depends on the machine's size and its operating system, and a partial hour costs only the minutes you actually ran it. Storage is billed separately, so switching a machine off doesn't stop every charge because the disks can keep costing you. From there, you have three dials to turn. The first is the free account. For the first thirty days, you get two hundred dollars in credit, and for a full year, three small burstable machine types are free for up to seven hundred and fifty hours a month. A month only holds about seven hundred and forty four hours, so one small machine can run nonstop and still land inside the free limit. The second dial is commitment reserved VM instances lock in a one year or three year term for a specific machine type and region, and Microsoft lists savings of up to seventy two percent against pay as you go. If you'd rather stay flexible, a savings plan commits to an hourly spend instead of a specific size and saves up to sixty five percent. Treat both as ceilings because your real savings depend on what you run. The third dial is spare capacity. Spot virtual machines run on unused Azure capacity at discounts of up to ninety percent, and the catch is real they can be evicted at any moment. They carry no uptime guarantee, and they aren't offered on the small burstable sizes. Therefore, work that can be interrupted like testing batch jobs and build pipelines. One more lever exists for anyone who already holds Windows Server or SQL server licenses, because you can bring them with you and cut the cost. There's also a habit that quietly saves money every month, and it's simply to delete what you're not using. A test machine left running for a year costs the same as one you actually need, and forgotten disks and old snapshots pile up in exactly the same way. It also helps to keep a close eye on spending, so a surprise at the end of the month doesn't catch you off guard. One word of caution is worth adding here prices move with region and time, so treat every number as a model rather than a fixed price. The dials are what stay the same, and they're worth more than any single figure. Staying up when things break a single machine in a single place is a single point of failure, and Azure hands you a ladder of ways to fix that. Availability zones are physically separate zones inside a region, each with its own power network and cooling, and there are three of them in each supported region. Put two or more machines across two or more zones, and Microsoft guarantees you can reach at least one of them at least ninety nine point nine nine percent of the time. Availability sets are a simpler grouping for redundancy, and Microsoft recommends at least two machines in a set to reach ninety nine point nine five percent guarantee the set itself is free and you only pay for each machine inside it. Scale sets go a step further. They manage a group of load balanced machines that grow and shrink with demand and like availability sets. The set itself costs nothing. The practical takeaway is simple one machine is fine for learning and for work that can pause the moment something needs to stay online. You want more than one copy of it spread across more than one place. And that's the whole idea behind the ladder. Each rung buys you more uptime and costs you more machines, so you climb only as high as the workload actually demands. If an entire region goes down, Azure Site Recovery can replicate your machines to a second region so you can failover when it matters. So a virtual machine is a computer you rent built from parts you choose. And the real skill is knowing when to rent one and how to keep the bill down. If you want the next piece, the series keeps going and there's a full breakdown of managed services waiting for you. Subscribe to M365 FM and we'll keep turning the confusing parts of Microsoft's cloud into plain English.