Managed VMs: Service Description¶
This page describes what the Managed VM service offers, how changes are made and where the boundaries are. The other pages of this section go into the details: Request and change, Operating system, Backup and restore, Updates and patching and Cost optimisation.
Optional offering, set per platform
The service is an optional building block, delivered by the platform team under an agreement (Operating models). Support hours, response times, contacts and fees are part of that agreement and are not in this documentation. Where this page names a default (an image, a window, a retention period), it is the usual value of the module. Your platform can differ.
In short¶
Workload teams run managed, compliant and monitored virtual machines in Azure without needing infrastructure expertise. The platform team builds and maintains the VMs as infrastructure as code with Terraform. The configuration of the VMs of one spoke and one environment is kept apart from every other spoke and environment. The VMs live in a spoke of the platform, connected to the hub (What you get).
No managed VM has a public IP address. All SSH and RDP access goes through Azure Bastion, with sign-in through Entra ID (Connect to virtual machines).
What is offered¶
| Area | Included |
|---|---|
| Compute | Managed VMs per VM configuration. The number of instances, the size and the operating system are set per configuration. Windows Server 2019, 2022 and 2025. Ubuntu 20.04, 22.04 and 24.04. Red Hat Enterprise Linux 8, 9 and 10. Or a custom image from the Azure Marketplace. Older versions fall out of support at the vendor. See Operating system for the images that your version supports. |
| Access | Azure Bastion with Entra ID login. Serial Console for administrators. No public endpoints. |
| Identity | Two Entra ID groups per VM configuration (users and administrators). Optionally two access packages with owner approval and a regular access review. Owners assign access (Managed VMs). |
| Patching | Azure Update Manager with maintenance configurations that a tag selects. The default maintenance window of a VM configuration is Monday 03:00 to 05:00, and you can change it per configuration (Updates and patching). |
| Backup | A Recovery Services vault for full VM backups, optionally the Backup Vault for frequent operational disk backups (Backup and restore). |
| Security | Microsoft Defender for Servers, access through Entra ID groups, encryption at host and Azure Disk Encryption as options, a Key Vault per deployment for the local administrator credentials. |
| Monitoring | Availability of the VM, free space on the OS and data disks, update compliance, and Change Tracking and Inventory in Log Analytics (Monitoring). |
| Cost | Auto-shutdown by tag, reservation advice, disk review (Cost optimisation). |
How changes are made¶
All changes go through the configuration repository as a pull request, and a ticket is the change record (Request and change).
- The change is a pull request. You can ask the platform team to make it (a request form), or prepare it yourself if your platform allows (Prepare a Managed VM pull request).
- The validation pipeline of the pull request must pass before a review. It scans the code for security findings, validates the Terraform and plans the change.
- The platform team reviews and approves, and deploys through the pipeline.
- The platform team informs you, and closes the ticket.
Manual changes in the Azure portal to resources that are managed by Terraform are not allowed: the next deployment undoes them.
The usual standard changes:
- add a VM configuration to a spoke, or a whole new deployment for a new spoke;
- change the OS version or the size of a VM;
- change the number of instances;
- switch an optional feature on or off;
- change the owners of a VM configuration.
What the platform team and the workload team own¶
The split is in Managed Virtual Machines: Responsibilities. In short, the platform team owns the module, the baseline, the patch schedule and tooling, and the backup vault. You own everything inside the operating system, the application, the data and the users, and you request the changes.
Boundaries¶
| Not part of the service | Why |
|---|---|
| Configuration inside the operating system: partitions, mounted disks, services, software, antivirus, users and hardening | The module and the platform team stop at the boundary of the OS. |
| The application, its data and its users | They belong to the workload. |
| A public IP address for a VM | Not by default. Only where the platform allows it and you ask for it explicitly. |
| VMs that are changed in the portal | Everything is code. A manual change is reverted. |
| Servers outside Azure | They need Azure Arc (Azure Arc), and it depends on the platform whether that is offered. |
| Business-critical patching decisions, such as testing the application after an update | Your team decides the window and the priority, and checks that the application works. |
Compare the variants of a spoke if you need more than virtual machines: with a managed spoke, the platform team also builds and operates the other Azure resources of the workload (Managed spokes).
Asset tracking¶
Every managed VM is described in Terraform and tagged by the module with the configuration it came from and with its owners, so a running VM can always be traced back to its definition. Change Tracking and Inventory adds the software inventory inside the machine, when you switch it on. Use the tags and the inventory for your own asset overview (Naming and tags).
Reporting¶
The platform team can report per workload, for example once a month, on: monitoring of the VMs, the state of the backups and the state of security updates and patching. Ask for the report, its form and where it is published. A check list for the operators is in Managed VM module: regular check.
Service levels and fees¶
Availability of support, response and resolution targets, the fee and the reporting are part of the agreement with your
platform team. Use the support route of your platform (Support, <support channel>).