The complete Hygiara product, free while we build with our first customers.
No card required. We’ll give notice before paid plans.
Use this practical review path to collect Azure evidence, identify architecture risks, and turn each observation into a decision with an owner and affected scope.
Architecture review evidence
Ready
Review Focus
Question to answer
Start with the checks most likely to affect the business outcomes and workloads in scope. The checklist is a review path, not a requirement to include every possible observation in the final report.
Open a check to see the evidence to collect, the failure pattern to look for, and the decision the review should produce.
Evidence should identify a resource, configuration, query result, missing signal, or stated limitation. Screenshots without scope and raw inventories without interpretation are not findings.
A useful finding connects the evidence to business impact, ownership, the relevant Well-Architected pillar, and a practical remediation direction.
Include landing zone or governance issues when they directly affect the workloads being reviewed. Use a dedicated landing zone assessment when the primary question concerns the shared Azure platform foundation.
Reviewer Notes
Document the applications, environments, subscriptions, owners, dependencies, regions, and exclusions.
Attach the minimum evidence needed to prove scope, impact, and remediation ownership.
Make every finding actionable as a fix, accepted risk, investigation, or redesign decision.
Review Checks
Use the checks as a review path, not a raw inventory. Start with the checks most likely to affect architecture risk, then open each item to see the evidence to collect, the failure pattern to look for, and the decision the review should produce.
How to read this section
Collect the Azure evidence first.
Compare it with the expected operating model.
Decide whether to fix, accept, investigate, or redesign.
Open a check when you need the evidence and decision criteria.
8 of 16 checks shown first
Query Examples
Use these only as a starting point for evidence collection.
1 example
Find reliability posture gaps on stateful resources
Reliability review needs evidence that stateful services can survive failure and be restored within business expectations.
This proves
Which stateful resources exist, where they run, and whether basic zone or redundancy signals are visible.
It does not prove
Whether failover is tested, RTO/RPO is acceptable, dependencies are redundant, or backups can be restored.
Hygiara adds
Hygiara links reliability evidence to WAF findings so reviewers can explain resilience risk instead of just listing deployed services.
Resources
| where type in~ (
'microsoft.compute/virtualmachines',
'microsoft.sql/servers/databases',
'microsoft.dbforpostgresql/flexibleservers',
'microsoft.storage/storageaccounts'
)
| extend zones = tostring(zones)
| extend redundancy = tostring(sku.name)
| project subscriptionId, resourceGroup, type, name, location, zones, redundancy, id
| order by subscriptionId, type, nameHow to read it
Use this as the starting point for resilience questions: what fails with the resource, how is state recovered, and what dependency still creates a single point of failure?
Query Examples
Use these only as a starting point for evidence collection.
1 example
Find reliability posture gaps on stateful resources
Reliability review needs evidence that stateful services can survive failure and be restored within business expectations.
This proves
Which stateful resources exist, where they run, and whether basic zone or redundancy signals are visible.
It does not prove
Whether failover is tested, RTO/RPO is acceptable, dependencies are redundant, or backups can be restored.
Hygiara adds
Hygiara links reliability evidence to WAF findings so reviewers can explain resilience risk instead of just listing deployed services.
Resources
| where type in~ (
'microsoft.compute/virtualmachines',
'microsoft.sql/servers/databases',
'microsoft.dbforpostgresql/flexibleservers',
'microsoft.storage/storageaccounts'
)
| extend zones = tostring(zones)
| extend redundancy = tostring(sku.name)
| project subscriptionId, resourceGroup, type, name, location, zones, redundancy, id
| order by subscriptionId, type, nameHow to read it
Use this as the starting point for resilience questions: what fails with the resource, how is state recovered, and what dependency still creates a single point of failure?
Query Examples
Use these only as a starting point for evidence collection.
1 example
Find reliability posture gaps on stateful resources
Reliability review needs evidence that stateful services can survive failure and be restored within business expectations.
This proves
Which stateful resources exist, where they run, and whether basic zone or redundancy signals are visible.
It does not prove
Whether failover is tested, RTO/RPO is acceptable, dependencies are redundant, or backups can be restored.
Hygiara adds
Hygiara links reliability evidence to WAF findings so reviewers can explain resilience risk instead of just listing deployed services.
Resources
| where type in~ (
'microsoft.compute/virtualmachines',
'microsoft.sql/servers/databases',
'microsoft.dbforpostgresql/flexibleservers',
'microsoft.storage/storageaccounts'
)
| extend zones = tostring(zones)
| extend redundancy = tostring(sku.name)
| project subscriptionId, resourceGroup, type, name, location, zones, redundancy, id
| order by subscriptionId, type, nameHow to read it
Use this as the starting point for resilience questions: what fails with the resource, how is state recovered, and what dependency still creates a single point of failure?
Query Examples
Use these only as a starting point for evidence collection.
1 example
Check diagnostic settings on critical resource types
Look for critical services that have no diagnostic setting resource attached. Missing diagnostics usually means weak incident evidence.
This proves
Which critical services appear to lack a directly attached diagnostic setting.
It does not prove
Whether logging is handled through a non-standard deployment pattern, inherited tooling, or another evidence source.
Hygiara adds
Hygiara turns diagnostic gaps into review findings with affected resource scope, service type, and operational impact.
let critical = Resources
| where type in~ (
'microsoft.keyvault/vaults',
'microsoft.storage/storageaccounts',
'microsoft.sql/servers',
'microsoft.network/applicationgateways',
'microsoft.containerservice/managedclusters'
)
| project resourceId = tolower(id), subscriptionId, resourceGroup, type, name;
let diagnostics = Resources
| where type =~ 'microsoft.insights/diagnosticsettings'
| extend targetId = tolower(tostring(properties.scope))
| project targetId;
critical
| join kind=leftanti diagnostics on $left.resourceId == $right.targetId
| order by subscriptionId, type, nameHow to read it
Treat this as a triage list. Some services may send logs through another pattern, but every critical production service should have an explainable audit trail.
Query Examples
Use these only as a starting point for evidence collection.
1 example
Check diagnostic settings on critical resource types
Look for critical services that have no diagnostic setting resource attached. Missing diagnostics usually means weak incident evidence.
This proves
Which critical services appear to lack a directly attached diagnostic setting.
It does not prove
Whether logging is handled through a non-standard deployment pattern, inherited tooling, or another evidence source.
Hygiara adds
Hygiara turns diagnostic gaps into review findings with affected resource scope, service type, and operational impact.
let critical = Resources
| where type in~ (
'microsoft.keyvault/vaults',
'microsoft.storage/storageaccounts',
'microsoft.sql/servers',
'microsoft.network/applicationgateways',
'microsoft.containerservice/managedclusters'
)
| project resourceId = tolower(id), subscriptionId, resourceGroup, type, name;
let diagnostics = Resources
| where type =~ 'microsoft.insights/diagnosticsettings'
| extend targetId = tolower(tostring(properties.scope))
| project targetId;
critical
| join kind=leftanti diagnostics on $left.resourceId == $right.targetId
| order by subscriptionId, type, nameHow to read it
Treat this as a triage list. Some services may send logs through another pattern, but every critical production service should have an explainable audit trail.
Query Examples
Use these only as a starting point for evidence collection.
1 example
Find public endpoints that need an architecture decision
Start with public IPs and public-facing PaaS configuration, then decide whether each exposure is intentional, temporary, or unmanaged drift.
This proves
Which public-facing resources exist and where they sit.
It does not prove
Whether exposure is approved, protected by another control, production-facing, temporary, or an accepted exception.
Hygiara adds
Hygiara keeps the affected resources attached to the finding and helps group repeated exposure into an architecture or governance pattern.
Resources
| where type in~ (
'microsoft.network/publicipaddresses',
'microsoft.network/loadbalancers',
'microsoft.network/applicationgateways',
'microsoft.web/sites',
'microsoft.storage/storageaccounts',
'microsoft.keyvault/vaults'
)
| extend publicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend ipAddress = tostring(properties.ipAddress)
| extend sku = tostring(sku.name)
| project subscriptionId, resourceGroup, type, name, location, sku, publicNetworkAccess, ipAddress, id
| order by subscriptionId, type, nameHow to read it
Do not automatically mark every result as a failure. Use it to start the exposure review: what is public, why is it public, who owns it, and what control should protect it.
Query Examples
Use these only as a starting point for evidence collection.
1 example
Find public endpoints that need an architecture decision
Start with public IPs and public-facing PaaS configuration, then decide whether each exposure is intentional, temporary, or unmanaged drift.
This proves
Which public-facing resources exist and where they sit.
It does not prove
Whether exposure is approved, protected by another control, production-facing, temporary, or an accepted exception.
Hygiara adds
Hygiara keeps the affected resources attached to the finding and helps group repeated exposure into an architecture or governance pattern.
Resources
| where type in~ (
'microsoft.network/publicipaddresses',
'microsoft.network/loadbalancers',
'microsoft.network/applicationgateways',
'microsoft.web/sites',
'microsoft.storage/storageaccounts',
'microsoft.keyvault/vaults'
)
| extend publicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend ipAddress = tostring(properties.ipAddress)
| extend sku = tostring(sku.name)
| project subscriptionId, resourceGroup, type, name, location, sku, publicNetworkAccess, ipAddress, id
| order by subscriptionId, type, nameHow to read it
Do not automatically mark every result as a failure. Use it to start the exposure review: what is public, why is it public, who owns it, and what control should protect it.
Use these when the primary path shows a related risk or the review scope needs a deeper pass.
Query Examples
Use these only as a starting point for evidence collection.
1 example
Find public endpoints that need an architecture decision
Start with public IPs and public-facing PaaS configuration, then decide whether each exposure is intentional, temporary, or unmanaged drift.
This proves
Which public-facing resources exist and where they sit.
It does not prove
Whether exposure is approved, protected by another control, production-facing, temporary, or an accepted exception.
Hygiara adds
Hygiara keeps the affected resources attached to the finding and helps group repeated exposure into an architecture or governance pattern.
Resources
| where type in~ (
'microsoft.network/publicipaddresses',
'microsoft.network/loadbalancers',
'microsoft.network/applicationgateways',
'microsoft.web/sites',
'microsoft.storage/storageaccounts',
'microsoft.keyvault/vaults'
)
| extend publicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend ipAddress = tostring(properties.ipAddress)
| extend sku = tostring(sku.name)
| project subscriptionId, resourceGroup, type, name, location, sku, publicNetworkAccess, ipAddress, id
| order by subscriptionId, type, nameHow to read it
Do not automatically mark every result as a failure. Use it to start the exposure review: what is public, why is it public, who owns it, and what control should protect it.
Query Examples
Use these only as a starting point for evidence collection.
1 example
Find oversized or idle compute candidates
Architecture review should test whether compute choices match service demand and lifecycle ownership.
This proves
Which virtual machines exist and which SKU size each one uses.
It does not prove
Actual CPU, memory, disk, or application demand. Use monitoring data before recommending a resize.
Hygiara adds
Hygiara turns capacity and lifecycle candidates into cost and performance findings with ownership context.
Resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend vmSize = tostring(properties.hardwareProfile.vmSize)
| project subscriptionId, resourceGroup, name, location, vmSize, id
| order by subscriptionId, resourceGroup, nameHow to read it
Do not treat size alone as waste. Combine SKU, utilization, schedule, owner, and business purpose before writing a cost or performance finding.
Query Examples
Use these only as a starting point for evidence collection.
1 example
Find oversized or idle compute candidates
Architecture review should test whether compute choices match service demand and lifecycle ownership.
This proves
Which virtual machines exist and which SKU size each one uses.
It does not prove
Actual CPU, memory, disk, or application demand. Use monitoring data before recommending a resize.
Hygiara adds
Hygiara turns capacity and lifecycle candidates into cost and performance findings with ownership context.
Resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend vmSize = tostring(properties.hardwareProfile.vmSize)
| project subscriptionId, resourceGroup, name, location, vmSize, id
| order by subscriptionId, resourceGroup, nameHow to read it
Do not treat size alone as waste. Combine SKU, utilization, schedule, owner, and business purpose before writing a cost or performance finding.
Query Examples
Use these only as a starting point for evidence collection.
1 example
Find oversized or idle compute candidates
Architecture review should test whether compute choices match service demand and lifecycle ownership.
This proves
Which virtual machines exist and which SKU size each one uses.
It does not prove
Actual CPU, memory, disk, or application demand. Use monitoring data before recommending a resize.
Hygiara adds
Hygiara turns capacity and lifecycle candidates into cost and performance findings with ownership context.
Resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend vmSize = tostring(properties.hardwareProfile.vmSize)
| project subscriptionId, resourceGroup, name, location, vmSize, id
| order by subscriptionId, resourceGroup, nameHow to read it
Do not treat size alone as waste. Combine SKU, utilization, schedule, owner, and business purpose before writing a cost or performance finding.
Query Examples
Use these only as a starting point for evidence collection.
1 example
Check diagnostic settings on critical resource types
Look for critical services that have no diagnostic setting resource attached. Missing diagnostics usually means weak incident evidence.
This proves
Which critical services appear to lack a directly attached diagnostic setting.
It does not prove
Whether logging is handled through a non-standard deployment pattern, inherited tooling, or another evidence source.
Hygiara adds
Hygiara turns diagnostic gaps into review findings with affected resource scope, service type, and operational impact.
let critical = Resources
| where type in~ (
'microsoft.keyvault/vaults',
'microsoft.storage/storageaccounts',
'microsoft.sql/servers',
'microsoft.network/applicationgateways',
'microsoft.containerservice/managedclusters'
)
| project resourceId = tolower(id), subscriptionId, resourceGroup, type, name;
let diagnostics = Resources
| where type =~ 'microsoft.insights/diagnosticsettings'
| extend targetId = tolower(tostring(properties.scope))
| project targetId;
critical
| join kind=leftanti diagnostics on $left.resourceId == $right.targetId
| order by subscriptionId, type, nameHow to read it
Treat this as a triage list. Some services may send logs through another pattern, but every critical production service should have an explainable audit trail.
Microsoft Learn Sources
Microsoft Learn defines the Well-Architected pillars and design checklists used to structure this review path.
Hygiara can collect the evidence behind this checklist, keep affected resources attached to findings, and generate the reviewed output as a stakeholder-ready report.
Frequently Asked Questions
It should cover the agreed Azure scope, critical dependencies, recovery design, backup and restore evidence, public exposure, identity and secrets, diagnostics, alerting, cost ownership, scaling, and the five Microsoft Well-Architected pillars.
No. Use the checklist to collect and assess evidence, then report the findings that are material to the agreed scope and business outcomes.
Repeat reviews on a defined cadence and after major releases, migrations, incidents, regulated workload onboarding, or material changes to the Azure environment.
Hygiara automates Azure evidence collection and finding generation while leaving materiality, accepted risk, and remediation order with the reviewer.
Related Azure Resources
Azure Architecture Review
Review the Azure services, subscriptions, and applications that matter against the Microsoft Well-Architected Framework. Start with real Azure evidence, find where risk is concentrated, and leave the team with decisions they can act on.
Azure Landing Zone Review
Review whether the Azure platform is ready to host workloads consistently. Check the management group model, subscription roles, identity and access, connectivity, policy inheritance, diagnostics, security baseline, cost ownership, and workload onboarding path.
Turn read-only Azure evidence into structured findings and a stakeholder-ready report.