Skip to content
Infralign Infralign Infralign docs

The audit

What the audit covers

Six detection types, sized and prioritised by a senior Azure architect, then reviewed with your team.

The audit combines a working session with a written report of Azure savings opportunities. Every finding carries six decision fields.

The audit lifecycle, free and with no commitment. A single cyan Infralign band, marked read-only and not a rules engine, spans a time axis of nightly, week one, and after the session, and holds three cards. First, a card with a cost-breakdown ring: step 1, read nightly, read-only, step 2, six detection types, tagged automated. Second, a card tagged done by a person: step 3, findings sized and prioritised, step 4, a working session with your team. That second card is the expert-led half of the audit. Third, in green, a document card: step 5, the prioritised report, tagged what you leave with. A strip beneath lists the six fields every finding carries: euro impact, evidence, owner, effort, risk, next action. The audit lifecycle, free and with no commitment. A single cyan Infralign band, marked read-only and not a rules engine, spans a time axis of nightly, week one, and after the session, and holds three cards. First, a card with a cost-breakdown ring: step 1, read nightly, read-only, step 2, six detection types, tagged automated. Second, a card tagged done by a person: step 3, findings sized and prioritised, step 4, a working session with your team. That second card is the expert-led half of the audit. Third, in green, a document card: step 5, the prioritised report, tagged what you leave with. A strip beneath lists the six fields every finding carries: euro impact, evidence, owner, effort, risk, next action.
Figure 1: Detection is automated. The audit itself is expert-led: a senior architect sizes and prioritises every finding before it reaches your report.

Audit sequence

Section titled “Audit sequence”
StepOwnerObservable outcome
1. Read the sources nightlyInfralignThe Data Ops dashboard shows current source dates.
2. Detect six finding typesInfralignCandidate findings carry evidence from your estate.
3. Size and prioritiseSenior Azure architectEach candidate has an impact estimate and priority.
4. Review the candidatesYour team and the architectEach finding has an owner and agreed next action.
5. Finalise the reportInfralignYou receive the prioritised written report.

What the audit surfaces

Section titled “What the audit surfaces”

Step 2 of figure 1 covers six detection types.

CategorySignalThreshold€ basis
Idle VMs30-day rolling p95 CPU, with an idle-day countp95 CPU under 5%The spend the idle VMs carry
Rightsizing30-day p95 CPU utilisation, with a confidence level per candidateNoneThe saving on each shutdown or resize candidate
Reservations and Savings PlansCommitment coverage per pool60% coverage targetEligible spend not covered by a commitment
Orphaned disksManaged disks with no attached VM, still billingNoneWhat those disks still charge
Log optimisationOver-provisioned logging and retention that can be trimmed without losing signalNoneThe logging spend the trim releases
Azure Hybrid Benefit (AHB) licensingEligible Windows and SQL workloads not yet claiming the benefitNoneThe licensing saving the benefit delivers

How the evidence is built

Section titled “How the evidence is built”

A rightsizing finding based only on billing data is a guess. The audit combines Advisor with three operational signals:

  • 30-day p95 CPU from Azure Monitor
  • idle-day counts
  • inventory from Azure Resource Graph

An architect checks each candidate against actual spend, architecture, and policy. Advisor is an input, not the output.

That review is step 3 in figure 1.

What you need to provide

Section titled “What you need to provide”
  1. Keep Azure connected through both required roles.
  2. Bring the owners of your largest cost lines to the working session.

Done when each prioritised finding has an owner and next action.

Clean tags are not required: billing and resource metadata are enough, and extra context improves ownership attribution.

What the audit is not

Section titled “What the audit is not”

The audit is not a penetration test, general architecture review, or compliance assessment. It is a cost audit with architecture context.