Application Gateway

application-gateway

application-gateway is the shared-ingress triage command for Azure Application Gateway posture, backend reach, and WAF context.

Use it when you need to know which gateway matters first because it fronts several workloads or exposes weaker edge controls.

What This Command Answers

• Which gateways matter first?
• Which shared ingress tier changes the edge story for several workloads at once?
• Which gateway should you inspect before treating each downstream app like an isolated target?

Run It

azurefox application-gateway --output table

For saved structured output:

azurefox application-gateway --output json

Example Table Output

gateway	exposure	routing	backends	waf	why it matters
agw-shared-edge-01	public=1 (20.30.40.50)	listeners=4; rules=4; path-maps=1	pools=3; targets=5	disabled	Shared public front door with broad backend reach and weak edge protection.
agw-customer-edge-02	public=1 (20.30.40.60); private=1	listeners=3; rules=3; path-maps=1	pools=2; targets=4	policy; detection	Public shared edge with WAF policy attached in Detection mode.

When To Use It

• when Application Gateway may be the shared front door for multiple workloads
• when public ingress, listener breadth, backend reach, or WAF posture matter more than one hostname at a time
• when the shared gateway layer is more important than reviewing downstream apps individually

What To Look For

• public versus internal frontend posture
• listener, rule, and backend-pool breadth
• weak, missing, or disabled WAF posture
• summaries that explain why one gateway matters more than a quieter single-purpose edge object

Why It Matters

Application Gateway can be the shared choke point between the internet and several internal Azure workloads.

A public gateway with weak or missing WAF posture can reduce protection for several apps at once. A gateway with broad listener and backend reach can matter more than any one hostname because it concentrates traffic and routing across multiple services. application-gateway helps you rank that shared ingress tier directly.

What Should Stand Out First

• gateways with public frontends before internal-only gateways
• gateways with broader listener, rule, backend-pool, or backend-target reach
• weaker or missing WAF posture within that shared-ingress group
• summaries that make the shared-ingress consequence obvious

If You See..., Go Next To...

• If you see a gateway with public frontends and weak WAF posture, go next to Network-Effective because it shows how strong the broader reachability story looks after visible network layers are combined.
• If you see listener or backend clues that point to App Service, Functions, or AKS, go next to the matching workload command because it shows the downstream workload posture behind that ingress tier.
• If you need the concrete hostname or IP strings exposed by the gateway path, go next to Endpoints because it shows the visible ingress names tied back to the source assets.

What To Do Next

• Start with the gateway that is both public and broad enough to matter across several workloads.
• Treat weak WAF posture as a prioritization signal for downstream application review, not just a network note.
• Use this command to decide whether the next step belongs in effective reachability, endpoint review, or the downstream workload family behind the gateway.

Boundary

application-gateway is a gateway-first, management-plane-first command.

It should rank the gateways that most deserve review next. It is not a packet tool, certificate store, full rule dump, or deep backend workload inspection surface.