Asset Management¶
How the platform team keeps track of what it manages: what an asset is, where the truth about it lives, how it is tagged, and how to produce an overview of the active assets at any moment. The same approach works in both operating models.
Scope¶
All Azure resources the platform team manages: the hub, the spoke baselines, and optional offerings such as the managed virtual machines. Resources that a workload team deploys itself are the workload team's assets (Responsibilities).
Strategy: two sources of truth that must agree¶
| Source | Holds | Answers |
|---|---|---|
| The Git repository with the infrastructure as code (code and configuration repositories) | The intended state | What should exist, why, since when, and who approved it |
| Azure itself | The actual state | What exists right now |
Everything the platform manages is deployed from code. There is no separate asset database to keep in step by hand: the
deployment that creates a resource is the artefact that records it. A spreadsheet drifts. A repository plus a live query
cannot, because a difference between the two is itself the finding (drift, found by the weekly
Plan run in the maintenance calendar).
For spokes, the spoke drift detection pipeline does this check per spoke file and stores a report.
For resources under Terraform management, manual changes in the Azure portal are not allowed. The repository is the single source of truth, and a change that did not go through it is a deviation (Incident management).
This gives three properties:
| Property | Meaning |
|---|---|
| Versioned | Every asset and every property, including tags, has a commit history: when it was added, changed or removed, and in which pull request |
| Reproducible | The environment can be rebuilt from the repository |
| Reviewed | An asset enters the estate through a pull request with a second reviewer (Pull request review), not through an ad-hoc click |
Keep the documentation of an asset in the same repository as its code, so that description and definition change in the same pull request.
Tagging¶
Tags identify and group resources beyond their resource ID: the environment, the owner, the application or the cost owner.
The tag set is agreed per organisation, because it has to match its cost allocation and ownership model. What is standard is how tags are handled:
- Tags are defined in the infrastructure as code repository, never applied by hand. Hub tags: Hub tags. Spoke tags: the
tagsof the spoke JSON. - A change to a tag or the tag set is a pull request like any other change, so it is reviewed and traceable.
- Because tags are set at deployment, every resource deployed through the pipeline carries them. A resource without them was not deployed through your process.
- Tags are used for querying: cost attribution, filtering a dashboard to one application or environment, and scoping an impact analysis when a vulnerability or an incident touches a class of resources.
- If you want tags to be enforced, not only applied, use Azure Policy (Policy assignments, Governance assessment).
Platform tags on managed virtual machines¶
If your platform offers the managed VM module, it adds tags of its own to the resource group of every VM configuration set, so a resource can be traced to the configuration that created it. Example from one version of the module:
| Tag | Identifies |
|---|---|
source |
The deployment the resources come from |
vm_configuration |
The VM configuration set |
environment |
The environment of the set |
os_type |
Windows or Linux |
vm_size |
The VM SKU |
public_ip |
Whether a public IP is attached |
shutdown_schedule_hours |
The shutdown schedule |
owner1, owner2, ... |
The configuration owners, one tag each |
The tags the customer defines are applied to the VM resources next to them. Check the tags your module version writes before you rely on this table.
Asset detail inside the machine¶
Tags and Azure Resource Graph describe the Azure resource. For virtual machines you also need to know what is on the machine. With the managed VM module this is covered by Change Tracking and Inventory: a VM extension plus a data collection rule that sends to the Log Analytics workspace. It tracks installed software, files, registry keys and services or daemons on Windows and Linux, so the software inventory is queryable and its history can be rebuilt. Update Manager adds the patch state of each VM, so update compliance is part of the asset record.
Query and report¶
| Means | Use |
|---|---|
| Azure Resource Graph | Produce an inventory of the active resources, filtered on any tag, on demand rather than maintained in advance. Queries: Asset queries |
| Dashboards | A dashboard tool such as Grafana, with the Azure Monitor data source, gives one place to see active resources and their health, with drill-down to the portal (Monitoring) |
| Monthly health check | A dated series of reports, so you see trends and not only a snapshot (Monthly health check) |
| Cost tooling | Cost scans report on the same resources from the consumption side, which shows over- and under-used assets (Cost and reservations). For central reporting over all subscriptions, see the billing export |
Connect assets to the systems that run the service¶
| System | Link |
|---|---|
| Work tracking (Azure DevOps or GitHub) | Every change to an asset is a work item and a pull request, so the history of an asset is linked to the reason it changed |
| On-call and incident tool | Alerts on a resource reach the people on duty (How alerting works) |
| Customer ticketing tool | Where the customer runs its own tool, synchronise the work items so assets and changes are visible there too |
Lifecycle¶
| Stage | What happens to the asset record |
|---|---|
| Onboarding | The environment is described in code and deployed. Assets exist in the repository from the first commit |
| Change | A pull request. The commit history is the audit trail |
| Monthly review | Reported in the monthly health check and reviewed with the customer |
| Offboarding | Removed in the reverse order of onboarding, covering the subscription, Entra ID objects and any cost tooling (Delete a spoke) |
Roles and control¶
| Role | Responsibility |
|---|---|
| Solution or service owner | The asset model: what is deployed, how it is tagged, how it is reported |
| Customer lead or service owner on the customer side | The tag set, and its fit with the customer's cost model |
| Platform engineers | Deploy and change assets through code and pull requests |
| Activity | Frequency |
|---|---|
| Peer review of every change to an asset or its tags | Per change |
| Monthly health report | Monthly |
| Cost scan or assessment, to reconcile consumption with the deployed estate | A few times a year, based on spend |
| Review of the estate with the customer | Monthly, in the tactical meeting (Meetings) |