Azure environment report

Tenant

corp.example — d4f2c9a1-3b8e-4f6a-9c2d-7e5b1a8f0c3e

Subscriptions

7 — workloads · research · teaching · identity · sandbox · management · legacy

Regions

Canada Central · Canada East · East US

Identity

Entra ID + managed domain services, fully synced

Connectivity

Hub-and-spoke — 5 spoke VNets peered to the hub · IPsec to the on-premises campus via the NVA

Report generated

From live Azure Resource Manager state, read-only

The topology as it actually runs — the intended paths and the ones that grew around them. Diagrams in the full report are kept alongside the document and updated with it, not drawn once for a kickoff deck.

The hub VNet carries the shared services, the inspection path, and the exposure story; five spoke VNets peer into it. The full report walks every VNet — these are the hub's subnets:

workload-subnet

10.30.0.0/24 — Web, SQL, and one domain controller · UDR next-hops the NVA

identity-subnet

10.30.1.0/24 — Managed domain services and the second DC · UDR next-hops the NVA

nva-subnet

10.30.254.0/27 — The firewall appliance, dual NIC

GatewaySubnet

10.30.255.0/27 — Provisioned, empty — the planned VPN gateway was never built (CON-3)

BastionSubnet

10.30.255.64/26 — Provisioned, empty — which is why public-IP RDP persists (CON-3)

Fifty-seven machines inventoried across the estate, each with its spec, network path, and exposure. The four that define the exposure story:

• web-01

  Ubuntu 22.04 · D2s_v5

  10.30.0.5 · 443, published through the NVA

• sql-01

  Windows Server 2022 · E4s_v5

  10.30.0.6 · Internal only, reached from web tier

• dc-01

  Windows Server 2022 · D2s_v5

  Exposed

  10.30.0.4 + public IP attached · Public RDP, bypassing the NVA — CON-2

• dc-02

  Windows Server 2022 · D2s_v5

  10.30.1.4 · Internal only

All 48 groups are inventoried in the full report — where each lives and what it is actually for. The six that shape the findings, including the one nobody remembered creating:

• canada

  workloads-rg

  Primary group — VMs, VNet, NICs, NSGs, public IPs, storage, route tables

• canada

  edge-nva-rg

  Firewall appliance VM, its NICs, public IP, and boot-diagnostics storage

• canada

  identity-rg

  Managed domain services, domain-controller VMs, identity subnet

• east

  cloud-mgmt-rg

  Cloud management — activity-log alerts and action groups

• canada

  monitoring-rg

  Log Analytics workspace, data-collection endpoints and rules

• canada

  legacy-poc-rg

  Remnants of old proofs-of-concept — orphaned disks and unused load balancers (CON-5)

The judgment layer: what is actively risky, what should change, and what is already right. Each item names the evidence in the full report.

• CON-1

  The workload NSG allows all traffic through the firewall’s public IP

  Fail

  The NVA’s outer NSG permits inbound on every port ("all ports open — NSG allows *"), relying on the appliance alone to filter. One appliance misconfiguration exposes every workload behind it; the NSG should enforce the same policy as a second layer.

• CON-2

  Domain controllers and web workloads carry public IPs

  Fail

  Eleven VMs across three subscriptions — including a domain controller — have public IPs attached directly to their NICs, bypassing the NVA path entirely. Management access happens over exposed RDP rather than through Bastion.

• CON-3

  The Bastion and Gateway subnets are provisioned but empty

  Advisory

  Subnets reserved for Bastion and a VPN gateway exist with no resources in them — the secure-access path was planned but never built, which is why public-IP RDP persists.

• CON-4

  User-defined routes send traffic to the NVA — with exceptions

  Advisory

  The hub route tables next-hop through the appliance, but nine spoke subnets have no route table attached, so their egress bypasses inspection and goes straight to the internet.

• CON-5

  Orphaned proof-of-concept resources still billing

  Advisory

  Legacy resource groups hold seventeen unattached managed disks, four unused load balancers, and an abandoned App Service plan from old proofs-of-concept — cost without function, and unpatched surface nobody owns.

• CON-6

  Central logging exists and is wired correctly

  Pass

  A Log Analytics workspace with data-collection rules covers the VMs, and activity-log alerts route to an action group. The visibility foundation is in place — enforcement is what’s missing.

The full report continues into per-resource detail — every NSG rule, route table, disk, and peering — and ends with the ranked list of what to fix first. It is the Discovery output of a Cloud Foundation Build — the documented current state that every later decision gets measured against. You can stop here and keep the truth, or continue into the build.

More sample deliverables →