azure-network-topology-review

Azure Network Topology Review

Purpose

Review Azure network topology with an operator-grade focus on connectivity boundaries, shared-services design, routing and DNS dependencies, and the separation between platform-owned and workload-owned controls.

This skill is for architecture and review work across:

• hub-spoke versus alternative connectivity models,
• shared hub services and spoke isolation,
• peering and subscription boundary decisions,
• route ownership and forced-tunneling implications,
• DNS and private name-resolution dependencies,
• centralized versus workload-local firewall, NVA, and private-endpoint patterns,
• platform-team versus workload-team control boundaries.

When to use

Use this skill when the user asks for:

• an Azure hub-spoke review or critique,
• network topology advice for a landing zone or multi-subscription platform,
• shared-services placement guidance for DNS, egress, ingress, Bastion, or hybrid connectivity,
• routing, peering, UDR, gateway-transit, or forced-tunneling concerns,
• private connectivity architecture review when the main issue is topology and boundary design,
• clarification of who should own which network controls across platform and workload teams.

Do not use this skill for:

• packet-level troubleshooting,
• detailed firewall rule authoring,
• step-by-step ExpressRoute implementation runbooks,
• a Private Link placement question where private-endpoint design is the primary issue rather than the overall topology.

Route private-endpoint-first questions toward azure-private-endpoint-adoption-planner if that skill exists in the repo state the user is working with.

Lean operating rules

• Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when available, then sanitized user evidence.
• Separate confirmed facts from inference. If state was not queried or shown, say so.
• Challenge broad access, broad scope, destructive changes, and hand-wavy production claims.
• Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.

References

Load these only when needed:

• Azure Network Topology Operations — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
• Safety checklist — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
• MCP and evidence path — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
• Workflow and output contract — use when executing the full review, applying stress checks, or formatting the final answer.
• Official sources — use when you need the detailed Microsoft documentation list or source notes.

Response minimum

Return, at minimum:

• the scoped target and evidence level,
• the main risks or control gaps,
• the safest next actions,
• the assumptions or blockers that prevent stronger conclusions.