Azure Application Gateway
Create an application gateway with a listener, routing rule, backend pool and HTTP settings, then read it, request its backend health and delete it.
Plan: Free29 of 29 operations implemented across its API1Known difference
A gateway is stored configuration: no HTTP forwarding, TLS termination or WAF inspection was established, and backend health reports Unknown.
Example checked on Vera 1.2.2, 8 November 2026. Each coverage note names its own evidence and date.
Connect
Section titled “Connect”Start Vera as in Get started. Then open Bash in a terminal of its own (on macOS, whose terminal starts zsh, type bash first), go to an empty scratch directory and run this; it needs curl and Python 3. It fetches the emulator's own certificate, so every request checks TLS, and defines arm, which this page's commands use. The bearer token vera-local is a dummy local credential, not your license key.
export VERA_CA_CERT="$PWD/vera-ca.pem"curl --fail --silent --show-error --noproxy '*' --insecure \ https://localhost:8543/_vera/ca.pem --output "$VERA_CA_CERT"curl --fail --silent --show-error --noproxy '*' \ --cacert "$VERA_CA_CERT" https://localhost:8543/_vera/health; echo
export AZ_BASE='https://localhost:8543'export SUB='00000000-0000-0000-0000-000000000001'export TENANT='00000000-0000-0000-0000-0000000000a1'export TOKEN='vera-local'
62 more lines: show the full setup
# arm METHOD /path API_VERSION [body.json]# Prints the response body once any operation it started has finished, or,# if that response had no body, the finished operation's response, such as# a RunCommand result. A finished operation can hold a failed result: read it.arm() ( set -eu method=$1; path=$2; version=$3 work=$(mktemp -d) trap 'rm -rf "$work"' EXIT case "$path" in /*) ;; *) printf 'Expected a relative /path\n' >&2; exit 1;; esac case "$AZ_BASE" in https://localhost:8543|https://127.0.0.1:8543) ;; *) printf 'This recipe requires the local emulator\n' >&2; exit 1;; esac args=(--fail-with-body --silent --show-error --noproxy '*' --max-time 20 --cacert "$VERA_CA_CERT" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json') body=() if [ "$#" -ge 4 ]; then body=(--data-binary "@$4"); fi code=$(curl "${args[@]}" -X "$method" ${body[@]+"${body[@]}"} -D "$work/headers" \ -o "$work/body" -w '%{http_code}' "$AZ_BASE$path?api-version=$version") || { cat "$work/body" >&2; exit 1; } poll_url=$(python3 - "$work/headers" "$AZ_BASE" <<'PY'import sys,urllib.parseheaders={}for line in open(sys.argv[1]): if ':' in line: key,value=line.split(':',1); headers[key.lower()]=value.strip()url=headers.get('azure-asyncoperation') or headers.get('operation-location') or headers.get('location') or ''if url: url=urllib.parse.urljoin(sys.argv[2],url); p=urllib.parse.urlsplit(url) if p.scheme!='https' or p.hostname not in ('localhost','127.0.0.1') or p.port!=8543: raise SystemExit('Refusing a non-local operation URL')print(url)PY ) || exit 1 if [ -n "$poll_url" ] && [ "$method" != GET ] && [ "$method" != HEAD ]; then done_ok=false for attempt in $(seq 1 30); do code=$(curl "${args[@]}" -D "$work/poll-headers" -o "$work/poll-body" -w '%{http_code}' "$poll_url") || { cat "$work/poll-body" >&2; exit 1; } state=$(python3 - "$work/poll-body" "$code" <<'PY'import sys,jsonraw=open(sys.argv[1]).read(); code=int(sys.argv[2]); value=json.loads(raw) if raw.strip() else {}status=str(value.get('status') or value.get('properties',{}).get('provisioningState') or '').lower()if status in ('failed','canceled','cancelled') or value.get('error'): print(raw,file=sys.stderr);raise SystemExit('Operation failed')if status in ('succeeded','completed') or (not status and code in (200,204)): print('done')else: print('pending')PY ) || exit 1 if [ "$state" = done ]; then done_ok=true; break; fi sleep 1 done if [ "$done_ok" != true ]; then printf 'Operation polling timed out\n' >&2; exit 1; fi if [ -s "$work/poll-body" ] && ! grep -q '[^[:space:]]' "$work/body" 2>/dev/null; then cp "$work/poll-body" "$work/body" fi fi cat "$work/body" printf '\n')The health check answers {"cloud": "azure", "generation_status": "generated", "status": "ok"}. Requests go only to the emulator at https://localhost:8543: the helper refuses any other address, including the Azure-looking URLs some responses hold. When you've finished, close the terminal and delete the scratch directory; that removes only these local files, not what you created in the emulator.
Application gateways are Microsoft.Network resources. The example uses API version 2026-03-01 for the gateway and its virtual network, and 2025-04-01 for the resource group, the versions tested with this build. Keep those versions: others weren’t tested.
Example
Section titled “Example”Create a resource group for the example and a virtual network with one subnet, gateway, for the gateway to sit on. arm waits for each change’s operation to finish before it returns.
RG="docs-azure-application-gateway"RGID="/subscriptions/$SUB/resourceGroups/$RG"VNET="$RGID/providers/Microsoft.Network/virtualNetworks/docs-vnet"cat > resource-group.json <<'JSON'{"location": "eastus"}JSONarm PUT "$RGID" 2025-04-01 resource-group.json
cat > vnet.json <<'JSON'{ "location": "eastus", "properties": { "addressSpace": { "addressPrefixes": ["10.20.0.0/16"] }, "subnets": [ { "name": "gateway", "properties": { "addressPrefix": "10.20.1.0/24" } } ] }}JSONarm PUT "$VNET" 2026-03-01 vnet.jsonCreate a Standard_v2 gateway in one request. It has a static private frontend at 10.20.1.10, an HTTP listener on port 80, a backend pool with one server, 10.20.1.20, HTTP settings and a Basic routing rule. The listener and rule refer to the other parts by ID, so the body is written with an unquoted heredoc that fills in $VNET and $GW.
GW="$RGID/providers/Microsoft.Network/applicationGateways/docs-gateway"cat > gateway.json <<JSON{ "location": "eastus", "properties": { "sku": { "name": "Standard_v2", "tier": "Standard_v2", "capacity": 1 }, "gatewayIPConfigurations": [ { "name": "gateway", "properties": { "subnet": { "id": "$VNET/subnets/gateway" } } } ], "frontendIPConfigurations": [ { "name": "front", "properties": { "subnet": { "id": "$VNET/subnets/gateway" }, "privateIPAddress": "10.20.1.10", "privateIPAllocationMethod": "Static" } } ], "frontendPorts": [{ "name": "http", "properties": { "port": 80 } }], "backendAddressPools": [ { "name": "back", "properties": { "backendAddresses": [{ "ipAddress": "10.20.1.20" }] } } ], "backendHttpSettingsCollection": [ { "name": "http", "properties": { "port": 80, "protocol": "Http", "cookieBasedAffinity": "Disabled", "requestTimeout": 20 } } ], "httpListeners": [ { "name": "http", "properties": { "frontendIPConfiguration": { "id": "$GW/frontendIPConfigurations/front" }, "frontendPort": { "id": "$GW/frontendPorts/http" }, "protocol": "Http" } } ], "requestRoutingRules": [ { "name": "http", "properties": { "ruleType": "Basic", "priority": 100, "httpListener": { "id": "$GW/httpListeners/http" }, "backendAddressPool": { "id": "$GW/backendAddressPools/back" }, "backendHttpSettings": { "id": "$GW/backendHttpSettingsCollection/http" } } } ] }}JSONarm PUT "$GW" 2026-03-01 gateway.jsonarm GET "$GW" 2026-03-01The read returns the configuration you sent. These are selected fields:
{ "properties": { "sku": { "name": "Standard_v2", "tier": "Standard_v2", "capacity": 1 }, "backendAddressPools": [ { "name": "back", "properties": { "backendAddresses": [{ "ipAddress": "10.20.1.20" }] } } ], "httpListeners": [{ "name": "http" }], "requestRoutingRules": [ { "name": "http", "properties": { "ruleType": "Basic", "priority": 100 } } ] }}Then ask for the gateway’s backend health:
arm POST "$GW/backendhealth" 2026-03-01The request answers HTTP 202, and arm waits for its operation to finish. When the 202 has no body, arm prints the operation’s result instead. On Vera 1.2.0-rc.3, that result still reported the backend’s health as Unknown. In Vera 1.2.0 preview, it listed the pool’s server, 10.20.1.20, with the message “No backend probe response has been observed by the local service.” No health probe was demonstrated.
To clean up, delete the gateway, then the virtual network. The gateway’s delete answers HTTP 202 and its operation ends with an empty HTTP 200; arm waits for it before the next line runs.
arm DELETE "$GW" 2026-03-01arm DELETE "$VNET" 2026-03-01The resource group stays, because deleting resource groups fails in Vera 1.2.2. A fresh emulator starts without it.
Supported features
Section titled “Supported features”- Standard_v2 gateways with a gateway IP configuration and a static private frontend on one subnet, a frontend port, an HTTP listener, a backend pool, HTTP settings and a Basic routing rule, created in one request, read back and deleted, each change’s operation polled to completion.
- References between parts. The listener refers to the frontend IP configuration and port, and the rule to the listener, pool and HTTP settings, all by ID.
- Backend health requests. The operation completes and lists each backend address, with health
Unknown.
Limitations
Section titled “Limitations”The main limits are below. A few more apply to every service, and the API coverage notes cover smaller differences.
- No requests are forwarded. No HTTP reverse proxying, TLS termination, WAF inspection or autoscaling was demonstrated. A stored listener and rule don’t mean anything answers on the frontend address.
- Backend health reports Unknown. On Vera 1.2.0-rc.3, as in Vera 1.2.0 preview, the backend-health result gave
Unknownfor the backend, and no health probe was demonstrated. Don’t use it to check whether a backend is up. - On-demand backend health sends no probes either.
ApplicationGateways_BackendHealthOnDemandrecords the probe settings in the request but sends no HTTP or TCP probe, and reports server health asUnknown. - One configuration was tested. WAF policies, private-link connections, start and stop, listing, tag updates, SSL options and on-demand backend health weren’t run as examples. The API coverage marks them from a review of Vera 1.2.0’s source, with their limits in the notes.
API coverage
Section titled “API coverage”Every operation of the API on this page, from its pinned public definition, and whether Vera 1.2.0 implements it. Only the API surfaces in this release are listed, and each operation once. Implementation availability was reviewed against the Vera 1.2.0 source on 6 November 2026. Source inspection identifies a local implementation and its known limits; it doesn't mean every operation or API version was tested with a request. Each note names its evidence: a Local observation without a build or date is from Vera 1.2.0 preview, on 5 November 2026, and one from a later build, such as Vera 1.2.0-rc.3 or Vera 1.2.2, names that build and its date. No response was compared with Azure's. What the statuses mean
No resource or operation matches .
Try part of a name, such as ApplicationGatewayPrivateEndpointConnections_Delete, or .
ApplicationGatewayPrivateEndpointConnections
4 of 4 implemented
| Operation | Status | Notes |
|---|---|---|
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
ApplicationGatewayPrivateLinkResources
1 of 1 implemented
| Operation | Status | Notes |
|---|---|---|
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
ApplicationGatewayWafDynamicManifests
1 of 1 implemented
| Operation | Status | Notes |
|---|---|---|
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
ApplicationGatewayWafDynamicManifestsDefault
1 of 1 implemented
| Operation | Status | Notes |
|---|---|---|
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
ApplicationGateways
17 of 17 implemented · 1 known difference
| Operation | Status | Notes |
|---|---|---|
| Application | Implemented | Local observation: Answered HTTP 202. The operation's result listed backend 10.20.1.20 with health Unknown and the message "No backend probe response has been observed by the local service." No health probe or traffic was demonstrated. |
| Application | Known difference | Source inspection: Builds the backend view from configuration but sends no HTTP or TCP probes: server health is Unknown, with a message that no probe response was observed. The on-demand probe settings are recorded, not sent. |
| Application | Implemented | Local observation: A PUT for a Standard_v2 gateway with a static private frontend, an HTTP listener on port 80, a backend pool, HTTP settings and a Basic routing rule answered HTTP 201, and the operation succeeded. |
| Application | Implemented | Local observation: Answered HTTP 202, and the operation ended with an empty HTTP 200. |
| Application | Implemented | Local observation: Answered HTTP 200 with the submitted configuration. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Runs as a local action; an external engine running it isn't established. Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Runs as a local action; an external engine running it isn't established. Local network configuration; packet forwarding and probes aren't established. |
| Application | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
WebApplicationFirewallPolicies
5 of 5 implemented
| Operation | Status | Notes |
|---|---|---|
| Web | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Web | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Web | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Web | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |
| Web | Implemented | Source inspection: Local network configuration; packet forwarding and probes aren't established. |