Most zero-trust content reads like a diagram: boxes, arrows, and a promise that "nothing trusts anything." In real life, you are trying to ship changes without breaking production, keep data from wandering, and still let teams work.

So here’s the operator’s version. It’s less philosophy, more muscle memory. It’s the set of defaults, controls, and checks that make Azure networking boring in the best way.

Before you pick a service, ask three questions. If you cannot answer them, you do not have a design yet.

·        Who is the caller, really? (identity and device posture, not just an IP)

·        Where is the path allowed to go? (segmentation, routing, DNS, and egress control)

·        How will you prove it later? (logs, alerts, and evidence you can hand to security)

Zero trust does not mean "no network." It means you treat every path as a decision point, and you make that decision explicit, logged, and repeatable.

These are the same principles you already know. The translation is what matters when you are building and running the platform.

Most outages and most findings come from mixing planes. Your network design gets simpler when you separate them:

·        Identity plane: who can request access and how they prove who they are (Entra ID, MFA, PIM).

·        Network plane: where packets are allowed to go (subnets, NSGs, UDRs, firewalls, DNS).

·        Data plane: what the workload can touch once it is on the network (private endpoints, secrets, RBAC, app auth).

A clean platform has strong boundaries between these planes and guardrails that stop one team from accidentally changing another plane.

Almost every Azure network conversation collapses into four flows. Design these intentionally, then reuse the pattern.

·        Inbound to apps: users, partners, APIs, and edge traffic.

·        East-west: service-to-service inside Azure and hybrid.

·        Outbound to internet: updates, repos, SaaS dependencies, telemetry.

·        Private PaaS access: databases, storage, Key Vault, and anything you do not want on public endpoints.

If you run a multi-subscription Azure estate, these defaults are the fastest way to get predictable outcomes.

This baseline is intentionally boring. You can add fancy later. The goal is to stop accidental exposure and make routing predictable.

Private Link is one of the best zero-trust tools in Azure because it shrinks your blast radius. It also creates the most operator pain when DNS is not treated as a first-class dependency.

·        Treat DNS as part of the deployment. If a private endpoint goes live before private DNS is correct, the rollout will look random.

·        Pick a pattern for Private DNS zone ownership. The central platform team owns zones, and app teams request links.

·        Watch for split-brain: the same name resolving to public in one VNET and private in another.

·        Document the "escape hatch". Some services still need public access for certain scenarios. If you allow it, log it, and timebox it.

When someone says "Private Link is down," they are usually describing DNS. The packet path might be fine. The name is wrong.

·        Test name resolution from the workload subnet, not from your laptop.

·        Confirm the FQDN resolves to the private endpoint IP for the VNET that owns the workload.

·        If you have on-prem clients, validate your forwarders and conditional forwarding rules.

·        Log DNS changes the same way you log route changes. Small changes here cause big outages.

This is where theory meets production. If outbound is wide open, a compromised workload can still exfiltrate data. Egress control is also where you can break builds fast, so treat it like a product.

·        Central egress for production: forced tunneling through a firewall or NVA, with allowlists and logging.

·        Scoped egress for non-prod: smaller controls, but still block known bad patterns and stop surprise public exposure.

·        Start with visibility. Turn on logs and measure the top outbound destinations before you block anything.

·        Build allowlists from evidence, not from guesses. Then prune.

·        Plan for Azure platform dependencies and your own CI/CD dependencies. If your firewall blocks your runners, you will hate life.

·        Remember SNAT and ephemeral port limits. NAT gateways and firewalls can bottleneck in weird ways under load.

NSGs are necessary. They are not enough on their own. Routing decides where traffic can go. If you only think in NSG terms, you will eventually ship an accidental path.

·        Segment by trust zone, not by org chart. Put internet-facing components, app tiers, and data tiers in distinct subnets or VNETs.

·        Use UDRs to force traffic through inspection points where it matters.

·        Use service tags for Azure services when it is appropriate, but do not treat them as a magic shield.

·        Keep it repeatable. If every subscription has different subnet names and rules, you will not be able to automate guardrails.

SSH and RDP are not the enemy. Uncontrolled SSH and RDP are. The fix is not "more firewall rules". The fix is an access workflow tied to identity.

·        Prefer Bastion for interactive access when it fits your environment.

·        If you need jump hosts, keep them in a management subnet with tight egress and no lateral access by default.

·        Use time-bound access. PIM and JIT patterns reduce standing privilege.

·        Log the workflow. If you cannot answer "who accessed what," you are still in hope-based security.

Zero trust fails in the gaps: change control, ownership, and troubleshooting. Here are the operator loops that keep it real.

·        Make network changes boring: version them, review them, deploy them the same way every time.

·        Treat routing and DNS as high-risk changes. Test in canary subscriptions or canary spokes first.

·        Have a rollback plan that is actually executable, not a sentence in a ticket.

·        Define a minimum evidence set: firewall logs, flow logs (where needed), private endpoint inventory, and policy compliance reports.

·        Alert on the basics: new public IPs, new NSG allow-any rules, new route tables, private DNS zone changes.

·        Make evidence self-service. Security should not have to DM you for screenshots during an audit week.

Most network incidents are not mysterious. They are just layered. Debug from cheapest to most expensive.

1.      DNS: does the name resolve to the expected IP from the right place?

2.      Routing: does the subnet have the route you think it has? Any forced tunneling or asymmetric path?

3.      Policy and RBAC: did a guardrail block or override something silently?

4.      NSG: is the flow allowed in both directions where stateful rules matter?

5.      Inspection point: firewall/NVA logs. Is it dropped, allowed, or rewritten?

6.      App layer: once the network is clean, check certificates, auth, and service configuration.

·        Private endpoint works in one VNET, fails in another: private DNS zone not linked, or split-brain resolution.

·        Hybrid clients cannot reach private endpoints: missing DNS forwarding, or on-prem route does not know the Azure private range.

·        Outbound suddenly blocked after a firewall change: allowlist built from guesses, not logs.

·        Random timeouts under load: SNAT/port exhaustion on NAT/firewall, or a bottlenecked inspection tier.

·        Teams bypass the platform with "temporary" public exposure: missing policy guardrails, no exception workflow, or no consequences.

Firewalls, NAT, logging, and data transfer costs are real. Zero trust still wins, but only if you run it like a product.

·        Right-size inspection tiers and scale them with demand.

·        Decide where flow logs are worth it. Turn them on where they reduce risk or speed incident response.

·        Track private endpoint sprawl. They are cheap compared to breaches, but they still multiply.

·        Measure data egress and cross-region flows. Most "surprise" network costs come from someone moving data the long way.

·        Inventory public exposure: public IPs, public PaaS endpoints, and open inbound rules.

·        Pick your egress stance for production: open, logged, or controlled. Then start moving one workload at a time.

·        Standardize Private DNS zone ownership and linking.

·        Turn on the minimum logs and build three alerts: new public IP, new allow-any NSG rule, and new route table.

·        Write the exception workflow: who approves, how long it lasts, and how you remove it.

Zero-trust networking in Azure is not one feature. It is a set of habits: private by default, identity-driven access, controlled egress, and evidence you can stand behind. If you build those habits into your landing zone, your day-to-day gets calmer, and your security posture stops depending on heroics.

If you’re in the middle of rolling this out, I’d love to hear what part is giving you the most grief right now: private endpoints, egress, hybrid DNS, or the exception process?