Secure Azure networking baseline: a practical foundation for landing zones • CloudRunbook

TL;DR

Secure networking is about standardization and ownership: pick a topology, decide DNS early, control egress, and make private connectivity predictable. This post gives you a baseline you can actually operate.

Why networking is the landing zone “multiplier”

Networking decisions spread everywhere:

they affect every workload
they determine how private access works
they define where security controls can be enforced
they decide whether troubleshooting is easy or painful

If you standardize networking early, everything downstream is faster:

new subscriptions onboard cleanly
private endpoints work consistently
incident response is predictable
“one team’s decision” doesn’t become “everyone’s outage”

The baseline principles

Standard topology
Pick hub/spoke or vWAN and commit. Snowflake networking kills scale.
DNS has an owner
If private endpoints exist, DNS is not optional and not “later”.
Egress is controlled
Outbound internet access is where a lot of real risk lives.
Inbound is protected
Standardize WAF patterns and reduce direct public exposure.
Segmentation is intentional
Use network boundaries that match your operational model.

Topology choice: hub/spoke vs vWAN (practical guidance)

Hub/spoke (classic)

Good when:

you want a clear central control point
you have a smaller number of regions
your routing model is relatively simple
you want a straightforward mental model

vWAN-based

Good when:

you need global transit and many branches/sites
you want a managed transit fabric
you have complex connectivity (lots of sites, regions, ER/VPN)

If you’re unsure: start with hub/spoke for the baseline, then adopt vWAN when scale or connectivity complexity demands it.

Do not do this

Do not allow each workload team to choose its own network topology. Standardization is the point.

Runbook: Secure networking baseline for landing zones

Decide your reference architecture and document it
Choose:
- Hub/spoke or vWAN
- Regions you will support initially
- How workloads connect to on-prem/partners
- How internet egress works
Write a one-page “network contract”:
- what every workload gets by default
- what is optional
- who owns what
Establish IP plan and naming conventions
This feels boring. It saves you later.
Minimum:
- reserved address space per region
- reserved address space for hubs
- a consistent vNet/subnet naming pattern
Avoid overlapping spaces if you have hybrid or plan future mergers.
DNS: pick an ownership model before private endpoints
If you plan private endpoints, decide DNS now.
Baseline decisions:
- Where DNS zones live (platform subscription is common)
- Who owns zone changes (platform team typically)
- How workloads request new records/zones
- Resolver strategy (Azure DNS Private Resolver or equivalent)
Without this, private endpoints turn into random outages.
Private endpoints baseline (make it repeatable)
Decide:
- when private endpoints are required (for data services, secrets, etc.)
- standard subnets for private endpoints
- DNS zone linking pattern per vNet
- approval process (manual vs automated)
Do not allow “private endpoints sometimes with custom DNS” patterns. That creates support hell.
Egress control: choose your outbound strategy
You need a consistent answer for:
- outbound internet access
- outbound filtering
- logging and alerting
Common patterns:
- NAT Gateway for simple outbound at scale (no filtering)
- Azure Firewall for controlled outbound + filtering + logging
- Proxy-based egress for stricter environments
Pick one baseline. Make exceptions rare and documented.
Inbound protection: standardize exposure patterns
Baseline:
- Prefer managed ingress (Front Door or Application Gateway) for web workloads
- Enable WAF for internet-facing apps
- Avoid direct public IPs on random resources
Your platform should make the secure path the easy path.
Segmentation model (keep it operational)
At minimum:
- separate platform networking from workloads
- separate environments (prod vs non-prod) either by subscription or strong policy boundaries
- use NSGs and ASGs consistently within workload VNets
For higher maturity:
- micro-segmentation and central policy enforcement patterns
Observability: flow logs and firewall logs are not optional
Minimum:
- log egress controls (if using firewall/proxy)
- NSG flow logs where appropriate
- central log destination and retention policy
If you don’t collect flow data, you cannot answer basic incident questions.
Make onboarding predictable for new subscriptions
When a new workload subscription is created, it should inherit:
- a standard connectivity pattern
- a standard DNS resolution approach
- a standard egress approach (or clear rule why not)
- baseline NSG and security policies
Subscription vending should apply these defaults automatically where possible.

Minimal baseline architecture (one-region example)

A simple, scalable baseline looks like:

Platform subscription:
- Hub vNet (shared services)
- Firewall or NAT/proxy egress
- DNS zones and resolvers
- Monitoring/logging resources
Workload subscription(s):
- Spoke VNets per workload or per environment
- Subnets standardized (apps, data, private endpoints)
- Private DNS zone links (managed centrally)
- No direct internet exposure by default

Common pitfalls (that you can avoid)

Pitfall: DNS is treated as an afterthought

Private endpoints without DNS standards cause slow, confusing failures. Decide ownership and patterns early.

Pitfall: no standard egress story

If workloads can egress however they like, you lose control of data exfil paths and create inconsistent troubleshooting.

Pitfall: accidental public exposure

If public IPs are easy to create, they will be created. Use policy guardrails and standard ingress patterns.

Pitfall: too many bespoke exceptions

Every exception becomes operational debt. Track them. Revisit them. Delete them where possible.

Success criteria for secure networking baseline

✓

A single standard topology exists (hub/spoke or vWAN) and is documented.
✓

DNS zones and private resolution have a clear owner and pattern.
✓

Private endpoints work consistently across workload VNets (zone linking is standardized).
✓

Egress is controlled and logged (NAT or firewall/proxy, but consistent).
✓

Inbound exposure uses standard WAF patterns; random public IP creation is restricted.
✓

Flow/security logs are centralized with defined retention.

Final thought

Networking becomes “secure” when the safe path is the default path. Standardize the topology, own DNS, control egress, and the rest of your landing zone becomes easier to run.