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 install specific software or drivers on the operating system, 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. 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 virtual machine is not a single resource: creating one also creates or uses several supporting resources, each with its own job. If a resource is missing, the VM either cannot boot or cannot talk to anything.

The key distinction is between private and public addressing. Every VM gets a private IP address through its network interface, and that is all it needs to communicate with other resources in the same virtual network. A public IP address is added only when the VM itself must be reachable from the internet, so leaving it out keeps a back-end VM reachable only from inside the network (or from networks connected to it). An NSG does not provide connectivity; it filters it. Other resources — a load balancer or an availability set, for example — are added only when you run a group of VMs, not for a single machine.

A container packages an application together with its code, settings, and dependencies into a single image 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. The important difference from a VM is what is virtualized: a virtual machine boots its own complete guest operating system, while containers share the host operating system kernel and package only the app and its dependencies. That is why containers are lighter, start in seconds, and pack more densely onto the same hardware — and why you manage the app and its image rather than an operating system.

Azure offers two main services for containers. Azure Container Instances is the simplest way to run a single container (or a small group of containers) quickly, without managing any servers — good for a small job or a straightforward workload. It bills for the time the container runs, and it has no built-in event trigger: you start it yourself (or from another service), and it keeps billing until it stops. That makes it different from a pay-per-execution serverless function, which Azure starts only when an event fires. Azure Kubernetes Service (AKS) 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 AKS. In short: containers are about portability and efficiency, Container Instances is the quick single-container option, and AKS 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. On the consumption-based (serverless) hosting plans 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. An HTTP trigger lets a function answer web requests, so Functions can expose a small API, but hosting a full website together with its API is the job of App Service.

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 offers several virtual machine options beyond a single VM, and each solves a different problem. A Virtual Machine Scale Set runs a group of identical virtual machines that automatically increase or decrease in number based on demand or a schedule — this is autoscaling. When traffic rises, the scale set adds VMs; when it falls, it removes them, so capacity matches need without manual work. A scale set is often paired with Azure Load Balancer, but the two do different jobs: the scale set changes how many VMs exist, while a load balancer only spreads incoming traffic across the VMs that already exist. A load balancer alone never adds a VM.

An availability set keeps a group of VMs running through hardware problems and maintenance inside one datacenter. It places the VMs across two kinds of grouping:

• Fault domains — groups of hardware that share a power source and network switch, like a server rack. Spreading VMs across fault domains means one rack failure cannot take them all down.
• Update domains — groups that Azure reboots one at a time during planned maintenance, so some VMs keep running while others are updated.

An availability set does not scale the number of VMs, and it does not protect against the loss of a whole datacenter or region: it works within one datacenter. Protecting against a datacenter failure uses availability zones, and recovering from a regional outage uses a second region — both covered in the lesson on Azure's core architectural components. In short, scale sets answer "how many VMs do I need right now?", while availability sets answer "how do I keep my VMs up when hardware fails or is patched?"

For example, an online store might put its web servers in a scale set behind a load balancer, so extra VMs appear automatically during a sale and disappear when the rush ends.

Azure Virtual Desktop is a desktop and app virtualization service that runs Windows desktops and applications on VMs in Azure and delivers them to users on almost any device — Windows and Mac computers, tablets, phones, or a web browser. It is a VM option for people rather than for servers: the user's Windows environment runs in Azure, not on their device. Microsoft manages the service's infrastructure (the connection broker, gateway, and web access), while you choose the session-host VMs and the apps on them. Typical uses are remote and hybrid staff, contractors on personal devices, and keeping company data in Azure rather than on laptops.

Session hosts are grouped into host pools, and the pool type decides how users share VMs:

• Pooled host pools let many users share session hosts. With Windows Enterprise multi-session, several users sign in to the same Windows VM at the same time, so a few VMs can serve many workers who use the same apps.
• Personal host pools give each user their own dedicated VM.

Two neighbours are easy to confuse with it. Windows 365 is a separate service that gives users a Cloud PC with a fixed per-user price; it never lets several users sign in to one VM at the same time, which is what AVD's multi-session pooled hosts do. Azure Bastion gives administrators secure RDP or SSH access to VMs through the Azure portal; it is a management tool, not a way to give end users a desktop.

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 deploy your application and Azure runs it for you — patching, load balancing, and scaling are handled by the platform. You can deploy either your code in a supported language or a custom container image, on Windows or Linux, so App Service is also a managed way to run a containerized web app.

The trade-off is control: App Service gives you no operating-system access, so you cannot install drivers or other software on the server itself. That leaves three application hosting options, chosen by how much you want to manage:

For example, a small team that wants to publish a company website and its customer-facing API can deploy both to App Service and let Azure keep the servers patched and available, rather than building and maintaining their own virtual machines.

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

You divide a VNet's address range into subnets. 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, such as network security groups, to each. A subnet belongs to exactly one VNet; it cannot stretch across two.

Virtual network peering connects two VNets so their resources communicate as if they were on the same network, with traffic carried privately over Microsoft's backbone rather than the public internet. Peering needs no gateway, and it works between VNets in the same region or in different regions (global peering). Two behaviours matter:

• Peering is not transitive. If VNet A is peered with B, and B with C, A still cannot reach C. To connect A and C, peer them directly.
• Gateway transit is a different thing. It lets a peered VNet use another VNet's VPN or ExpressRoute gateway to reach on-premises networks. It does not make peering transitive between VNets.

The gateway-based alternative to peering is a VNet-to-VNet VPN connection, which links two VNets through VPN gateways with an encrypted tunnel. It needs a gateway in each VNet, so peering is the simpler and usually faster choice when you just want two VNets to talk.

Azure DNS is a hosting service for DNS domains: it holds your DNS zones and the records in them (such as www or mail) on Azure's global name servers, so names resolve to the right addresses. Because it is an Azure service, you manage the records with the same Azure credentials, access control, and billing as your other resources.

Azure DNS does not register or sell domain names. You buy the domain from a domain registrar, then delegate it to Azure DNS by changing the name-server records at the registrar to the Azure DNS name servers shown for your zone. The domain stays registered with the registrar; only its records are hosted in Azure.

A private DNS zone is linked to one or more VNets and resolves only there, so internal names stay internal. You can use both together: a public zone for customer-facing names and a private zone for internal ones.

When you need to connect your own datacenter, offices, or users to Azure, you have two main choices. Azure VPN Gateway sends encrypted traffic between an Azure virtual network and other locations over the public internet. It supports three connection types:

• Site-to-site — links a whole on-premises network to Azure through a VPN device (such as a VPN-capable router) at that site.
• Point-to-site — links individual devices, such as remote workers' laptops, to the VNet. No VPN device is needed at their location; each device runs a VPN client.
• VNet-to-VNet — links two Azure virtual networks through their gateways with an encrypted tunnel.

The 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 connect offices and remote users for everyday use.

Azure ExpressRoute instead gives you a private connection between your network and Azure, provided through a connectivity provider (or a direct port at a Microsoft peering location), that does not go over the public internet at all. Because the path is private and dedicated, ExpressRoute offers more consistent latency and performance and higher reliability, which suits large organizations moving a lot of data or with strict requirements. It costs more and takes longer to set up than a VPN.

The two are often combined: each location chooses by the bandwidth, consistency, and privacy it needs and what that is worth paying for. A VPN can also act as a backup path for an ExpressRoute circuit.

An endpoint is the network address at which a service is reached. A public endpoint is an internet-routable address: by default, many Azure platform services — such as a storage account or a database — are reached at a public endpoint, which you can restrict with firewall rules but which is still a public address. A private endpoint is a network interface with a private IP address from your own virtual network, connected to a specific service through Azure Private Link. Clients then reach the service at that private address, and the traffic stays on Microsoft's network.

Because a private endpoint is just an address in your VNet, anything that can reach the VNet privately can use it — peered VNets, and on-premises networks connected over VPN Gateway or ExpressRoute. Two details trip people up:

• A private endpoint does not close the public endpoint. To refuse connections from the internet, you must also disable the service's public network access.
• Name resolution must point at the private IP. A private DNS zone maps the service's name to the private endpoint, so clients keep using the usual name.

A service endpoint is the near-twin. It lets a subnet reach a service over the Azure backbone and lets the service allow only that subnet, but the service keeps its public IP address and gets no address in your VNet.