Azure networking · AZ-104 · AZ-700 · AZ-500

Secure Azure Hub-and-Spoke Infrastructure

A cost-conscious, private-by-default Azure network foundation that translates enterprise networking and infrastructure operations experience into inspectable cloud infrastructure code.

View GitHub Review evidence status

ImplementedModular Bicep, scripts, CI, diagrams, documentation

Locally + CI validatedBuild, lint, parameters, Bash, PowerShell, links, secrets

Evidence pendingAzure deployment, runtime checks, teardown, actual cost

01 · Overview

Business scenario and objectives

The lab models a small organization that needs shared network foundations, isolated application and data areas, private access to Azure Storage, and centralized operational visibility without the standing cost of premium transit services.

Use repeatable, parameterized Infrastructure as Code.
Separate trust boundaries and avoid public management endpoints.
Validate changes before deployment and make cleanup ownership-aware.
Document where a low-cost lab differs from production architecture.

02 · Architecture

Hub, isolated spokes, private PaaS, and monitoring

The SVG is exported from the maintainable Draw.io source in the technical repository and matches merged Bicep on main.

Hub VNet

10.0.0.0/16 with management and shared-services subnets. The hub has no transit appliance, so peering is deliberately non-transitive.

Application spoke

10.10.0.0/16 with workload and private-endpoint subnets, NSGs, ASG identity, route guardrails, and the Blob private endpoint.

Data spoke

10.20.0.0/16 with matching subnet segmentation. There is no direct app-to-data peering or baseline transit path.

03 · Services and security

Controls implemented for the lab

Network controls

Bidirectional hub-to-spoke peering, subnet NSGs, workload ASGs, and route tables that blackhole the other spoke CIDR. The guardrails limit accidental lateral reachability but are not inspected transit.

Private data path

Blob Storage disables public network access and shared-key authorization. A Private Endpoint and privatelink.blob.core.windows.net zone provide the private path and name resolution.

Monitoring

Log Analytics receives Blob audit logs and transaction metrics. Diagnostic storage supports optional VNet flow logs, and an Activity Log alert targets deletion of project resource groups.

Automation safety

Scripts verify—not silently change—the active subscription, run build/validation and ARM what-if, require explicit deployment confirmation, and refuse unsafe cleanup.

04 · Infrastructure as Code

Focused Bicep modules and deployment workflow

The subscription-scope entry point creates three tagged resource groups and composes modules for networking, peering, Private DNS, private storage, monitoring, optional VNet flow logs, and an optional validation VM.

infra/
├── main.bicep
├── environments/lab.bicepparam
└── modules/
    ├── hub-network.bicep
    ├── spoke-network.bicep
    ├── vnet-peering.bicep
    ├── private-dns.bicep
    ├── private-storage.bicep
    ├── monitoring.bicep
    ├── vnet-flow-logs.bicep
    └── test-vm.bicep

05 · Testing and validation

What passed, and what still requires Azure

Area	Status	Evidence
Bicep lint, build, and parameters	Passed	GitHub Actions on merged Azure repository
Bash and PowerShell analysis	Passed	ShellCheck, parser, PSScriptAnalyzer
Links and secret scan	Passed	Lychee and Gitleaks
ARM validation and what-if	Blocked	Requires authenticated Azure context
Peering, DNS, endpoint, diagnostics	Evidence pending	Requires live Azure deployment
Cleanup and actual cost	Evidence pending	Requires deployed project resources

Read the complete testing record

06 · Operations

Troubleshooting, cost, cleanup, and lessons learned

Troubleshooting

The runbook covers subscription mismatches, policy or provider failures, Private DNS resolution, VM Run Command prerequisites, expected spoke isolation, and flow-log dependencies.

Cost considerations

Private Endpoint hours, storage operations, Log Analytics ingestion, and peering data are the baseline cost drivers. Premium networking and always-on compute are excluded.

Cleanup

Cleanup derives exactly three names, verifies canonical tags and resource ownership, removes optional flow logs from NetworkWatcherRG, and requires an exact confirmation phrase.

Lessons learned

Peering does not create transit; monitoring resources need connected data sources; configurable address spaces must keep subnet inputs aligned; safe deletion must fail closed when Azure checks error.

07 · Evidence gallery

Sanitized evidence still to capture

These are labelled placeholders—not screenshots or successful test claims. They will be replaced only after an authorized deployment.

Evidence pending

Resource groups and topology

Three project groups, VNets, subnets, peerings, NSGs, ASGs, and route tables.

Evidence pending

Private access

Storage network restrictions, Private Endpoint approval, DNS A record, and private resolution.

Evidence pending

Monitoring

Diagnostic settings, Log Analytics records, optional flow logs, and the deletion alert.

Evidence pending

Deployment and cleanup

ARM validation, what-if, deployment outputs, live validation, teardown, and final cost.

Technical source of truth

Inspect the complete implementation on GitHub

The repository contains the Bicep modules, parameters, scripts, diagrams, security decisions, deployment guide, tests, troubleshooting, cost limits, and cleanup procedure.

Open Azure repository Back to catalogue