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 techtide-azure-private-endpoint-adoption-planner if that skill exists in the repo state the user is working with.
Lean operating rules
- Prefer live Azure or Microsoft evidence first when the active client exposes it; otherwise fall back to official documentation and 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:
- 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.
1---2name: techtide-azure-network-topology-review3description: Use this skill for Azure network architecture review, hub-spoke critique, routing and DNS dependency analysis, shared-services boundary decisions, firewall placement review, and landing-zone connectivity guidance.4---56# Azure Network Topology Review78## Purpose910Review 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.1112This skill is for architecture and review work across:1314- hub-spoke versus alternative connectivity models,15- shared hub services and spoke isolation,16- peering and subscription boundary decisions,17- route ownership and forced-tunneling implications,18- DNS and private name-resolution dependencies,19- centralized versus workload-local firewall, NVA, and private-endpoint patterns,20- platform-team versus workload-team control boundaries.2122## When to use2324Use this skill when the user asks for:2526- an Azure hub-spoke review or critique,27- network topology advice for a landing zone or multi-subscription platform,28- shared-services placement guidance for DNS, egress, ingress, Bastion, or hybrid connectivity,29- routing, peering, UDR, gateway-transit, or forced-tunneling concerns,30- private connectivity architecture review when the main issue is topology and boundary design,31- clarification of who should own which network controls across platform and workload teams.3233Do not use this skill for:3435- packet-level troubleshooting,36- detailed firewall rule authoring,37- step-by-step ExpressRoute implementation runbooks,38- a Private Link placement question where private-endpoint design is the primary issue rather than the overall topology.3940Route private-endpoint-first questions toward `techtide-azure-private-endpoint-adoption-planner` if that skill exists in the repo state the user is working with.4142## Lean operating rules4344- Prefer live Azure or Microsoft evidence first when the active client exposes it; otherwise fall back to official documentation and sanitized user evidence.45- Separate confirmed facts from inference. If state was not queried or shown, say so.46- Challenge broad access, broad scope, destructive changes, and hand-wavy production claims.47- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.4849## References5051Load these only when needed:5253- [MCP and evidence path](references/mcp-and-evidence.md) - use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.54- [Workflow and output contract](references/workflow-and-output.md) - use when executing the full review, applying stress checks, or formatting the final answer.55- [Official sources](references/official-sources.md) - use when you need the detailed Microsoft documentation list or source notes.5657## Response minimum5859Return, at minimum:6061- the scoped target and evidence level,62- the main risks or control gaps,63- the safest next actions,64- the assumptions or blockers that prevent stronger conclusions.
TechTideOhio