Azure Compute & Networking Services Explained

Azure compute is any service that runs your code or applications, and Azure gives you several options that differ mainly in how much you manage yourself. At one end are virtual machines: you get a complete computer in the cloud and are responsible for the operating system and software on it, which is the infrastructure-as-a-service model. In the middle are containers, which package an application together with everything it needs so it starts quickly and runs the same way on any host. At the other end are Azure Functions, a serverless option where you supply only small pieces of code and Azure runs them on demand — you never think about servers at all.

The right choice is a trade-off between control and convenience: more control means more responsibility, while more convenience means Azure handles more for you. A useful way to picture it is a sliding scale from a virtual machine (most control, most management) to a function (least management, least control), with containers in between. The sections that follow describe each option, then a table sums up when to reach for which.

An Azure Virtual Machine is a computer you run in the cloud — it has an operating system, memory, and storage, just like a physical server, but Microsoft supplies the underlying hardware. Virtual machines are the classic example of infrastructure as a service: Azure manages the physical host and datacenter, while you manage the operating system, patches, and any software you install. This gives you the most control of any compute option, which makes VMs the right pick when you need to run specific software, use a custom configuration, or move an existing server to the cloud without redesigning it — often called lift and shift.

Because you manage the software, you also carry more responsibility for keeping it updated and secure. A virtual machine needs a few supporting resources to work: a disk for storage, a virtual network and network interface to connect it, and usually a public or private IP address. For example, a team that has an older application built for Windows Server can create a Windows virtual machine in Azure and run the application there almost unchanged. You can create a single VM or many, and you pay for the compute time you use.

A container packages an application together with its code, settings, and dependencies into a single unit that starts fast and runs the same way on any host. Because a container carries everything the app needs, you avoid the it-works-on-my-machine problem and can move the app between environments easily. Containers are more lightweight than virtual machines because many containers share one operating system instead of each running its own, so you can pack more onto the same hardware.

Azure offers two main services for containers. Azure Container Instances is the simplest way to run a single container quickly, without managing any servers — good for a small job or a straightforward workload. Azure Kubernetes Service is for running many containers together at scale; it handles orchestration, meaning it schedules containers across machines, restarts failed ones, and scales them up or down. For example, a business that splits its application into several small services might package each one as a container and run them all on Azure Kubernetes Service. For AZ-900, remember that containers are about portability and efficiency, Azure Container Instances is the quick single-container option, and Azure Kubernetes Service manages containers at scale.

Azure Functions is a serverless compute service: you write a small piece of code that does one job, and Azure runs it only when a trigger fires — such as a file being uploaded, a message arriving, or a timer going off. Serverless means you never provision or manage servers, and Azure automatically scales the function to match demand. Crucially, you pay only when your code runs — this is pay-per-execution — so an idle function costs little or nothing. That makes Functions ideal for short, event-driven tasks like resizing an image after upload, processing form submissions, or running a scheduled cleanup. It is a poor fit for long-running or always-on workloads.

Here is how the three compute types compare:

Read it as a scale of responsibility: a virtual machine gives the most control, a function the least management. For example, choose Functions to run a few seconds of code each time a photo is uploaded, rather than keeping a whole virtual machine running all day.

Azure has several options that help virtual machines stay available and handle changing load. A Virtual Machine Scale Set lets you run a group of identical virtual machines that automatically increase or decrease in number based on demand — this is autoscaling. When traffic rises, the scale set adds more identical VMs; when it falls, it removes them, so you match capacity to need without manual work.

An availability set is a different tool: it spreads a group of virtual machines across separate underlying hardware inside a datacenter so that a hardware fault or planned maintenance does not take all of them down at once, improving reliability. The two solve different problems — scale sets are mainly about scaling to demand, while availability sets are about keeping VMs running through localized failures.

Azure Virtual Desktop is another VM-based service, but for people rather than servers: it delivers a full Windows desktop and apps from Azure that users can reach from anywhere, which is useful for remote or contract staff. For example, an online store might put its web servers in a scale set so extra VMs appear automatically during a sale, then disappear when the rush ends.

Azure App Service is a platform-as-a-service option for hosting web applications, REST APIs, and mobile back ends without managing the underlying servers. Instead of creating a virtual machine, installing a web server, and maintaining the operating system yourself, you hand your application code to App Service and Azure runs it for you — patching, load balancing, and scaling are handled by the platform. This makes App Service a fast way to get a website or API online, and a good example of trading some control for a lot of convenience.

It supports common programming languages and can scale out to handle more traffic, either automatically or on a schedule. Because Azure manages the servers, you spend your time on the application rather than on infrastructure. For example, a small team that wants to publish a company website or a customer-facing API can deploy it straight to Azure App Service and let Azure keep the servers patched and available, rather than building and maintaining their own virtual machines. App Service is often the simplest choice when your goal is simply to host a standard web app or API in the cloud.

An Azure Virtual Network, usually called a VNet, is your own private network inside Azure. It gives your Azure resources — such as virtual machines — a space where they can communicate securely with each other, with the internet when you allow it, and with your own on-premises networks. A VNet works much like a traditional network in your office, but it is defined in software.

You divide a VNet into subnets, which are smaller ranges within the network. Subnets let you organize and separate resources — for example, placing front-end web servers in one subnet and back-end databases in another — so you can apply different rules to each. Virtual network peering connects two VNets so that resources in them can communicate as if they were on the same network, using Microsoft's backbone rather than the public internet. Peering is how you link networks together, for instance joining a VNet in one region to a VNet in another.

Azure DNS is a related service that hosts your domain names in Azure so that names can be translated into the addresses resources use. Together, VNets, subnets, and peering give your cloud resources private, organized connectivity.

When you need to connect your own datacenter or office to Azure, you have two main choices. Azure VPN Gateway creates an encrypted tunnel between your network and an Azure virtual network over the public internet. It is a site-to-site connection: traffic is protected by encryption, but it still travels across the shared internet, so performance can vary. VPN Gateway is a cost-effective way to link an office to Azure for everyday use.

Azure ExpressRoute instead gives you a private, dedicated connection between your network and Azure that does not go over the public internet at all. Because it is private, ExpressRoute offers more consistent performance, higher reliability, and greater security, which suits large organizations moving a lot of data or with strict requirements. Here is the classic comparison:

For example, a small branch office might use a VPN Gateway, while a bank moving large workloads would choose ExpressRoute. The exam trigger to remember: a private dedicated connection not over the internet is ExpressRoute.