Microsoft AZ-700: Configure Azure Application Gateway

Reading Time: 5 minutes

Notes from MS Learn AZ-700 Module 4: Load balance non-HTTP(S) traffic in Azure – Unit 4: Configure Azure Application Gateway

App Gateway has components combining to route requests to pool and verify server health. (Image taken from MS Learn

  • Frontend configuration
    • App Gateway can have
      • Public IP
      • Private IP
      • Both
  • Backend configuration
    • Backend pool used to route requests to backend servers
    • Create empty backend pool and then add backend targets later is possible
    • Targets include
      • NICs
      • Public IP’s
      • Private IP’s
      • VM Scale Sets
  • Configure Health Probes
    • Azure App Gateway by default monitors back-end pool resources
    • Automatically removes unhealthy resources from pool
    • Continuous monitoring of unhealthy and adds them back when return to healthy
    • By default, probes same port defined in back-end HTTP settings
    • Custom probe can be configured with custom port
    • Source IP addr depends on backend pool
      • If server addr is public, source is app gateways frontend public IP
      • If server addr is private, source is app gateway subnet private IP address space
  • Default health probe
    • App gateway has default health probe if custom probes no configured
    • Monitoring via HTTP GET to IP or FQDN configured in back-end pool
    • Default is configured for HTTPS
    • Example
      • App gateway set to use backend receiving HTTP on port 80
      • Default is every 30 seconds with a 30 second timeout
      • HTTP looking for response code 200-399
      • If fails for a server in pool forwarding stopped to server
      • Requests restart when successful response
    • Default health probe settings (Table below from MS Learn)
      • Probe property Value Description Probe URL <protocol>://127.0.0.1:<port>/ The protocol and port are inherited from the backend HTTP settings to which the probe is associated Interval 30 The amount of time in seconds to wait before the next health probe is sent. Time-out 30 The amount of time in seconds the application gateway waits for a probe response before marking the probe as unhealthy. If a probe returns as healthy, the corresponding backend is immediately marked as healthy. Unhealthy threshold 3 Governs how many probes to send in case there’s a failure of the regular health probe. In the v2 SKU, the health probes wait the probe interval before checking again. The back-end server is marked unreachable after the consecutive probe failure count reaches the unhealthy threshold.
    • Probe intervals
      • All App Gateway probes to backend independent of each other
      • Same probe config applies to each App Gateway instance
      • If multiple. Listeners, each probes backend independently
  • Custom health probe
    • Custom probes provide more granular health monitoring
    • Custom Probes
      • Custom hostname
      • URL path
      • Probe interval
      • Number of failed responses before unhealthy
    • Settings (Table below from MS Learn)
      • Probe property Description Name Name of the probe. This name is used to identify and refer to the probe in back-end HTTP settings. Protocol Protocol used to send the probe. This property must match with the protocol defined in the back-end HTTP settings. Host Host name to send the probe. Path Relative path of the probe. A valid path starts with ‘/.’ Port If defined, this property is used as the destination port. Otherwise, it uses the same port as the HTTP settings that it’s associated to. This property is only available in the v2 SKU. Interval Probe interval in seconds. This value is the time interval between two consecutive probes Time-out Probe time-out in seconds. If a valid response isn’t received within this time-out period, the probe is marked as failed. Unhealthy threshold Probe retry count. The back-end server is marked down after the consecutive probe failure count reaches the unhealthy threshold.
  • Probe matching
    • Default: an HTTP(S) response code between 200-399 is healthy
    • Custom probes support two matching criteria to optionally modify default sense of “healthy”
      • HTTP response status code
        • Probe matching for user specified http code or range.
        • Comma-separated status codes or ranges supported
      • HTTP body match
        • Probe matching looking at HTTP body response matching user specified string
        • Looks only for presence of user specified string in body, not a full regular expression match.
    • Match criteria can be specified using New-AzApplicationGatewayProbeHealthResponseMatch cmdlet
  • Configure listeners
    • Logical entity checking for incoming requests using port, protocol, host, IP Addr
    • When configured must enter values that match inbound request values on gateway
    • When creating App Gateway in portal you also create default listener by choosing the protocol and port
    • Choose whether or not HTTP2 is enabled
    • Can edit default listener (appGatewayHttpListener) or create new
  • Listener Types
    • Basic
      • All requests accepted and sent to back-end
    • Multi-site
      • Requests sent to different back-ends based on host header/host name
      • Must specify a host name that matches incoming request
  • Order of processing listenters
    • V1 SKU
      • Requests matched in order of rules and type of listener
    • V2 SKU
      • Multi-site processed before basic
  • Front-end IP address
    • Choose IP planned to associate with listener
    • Listener listens requests on this IP
  • Front-end port
    • Choose port (new or existing)
    • Any value from allowed range
    • Can be used for public or. Private facing listeners
  • Protocol
    • HTTP
      • Traffic between client/app gw unencrypted
    • HTTPS
      • TLS term or end-to-end TLS encryption
      • TLS terminates at app gw
      • Traffic between client and app gw encrypted
      • If end-to-end TLS desired – choose HTTPS and configure back-end HTTP setting
    • Configuring TLS term and end-to-end TLS encryption
      • Must add certificate to listener so gw can derive symmetric key
      • Symmetric key used to encrypt and decrypt gw traffic
      • GW certificate must be in Personal Information Exchange (PFX) format
        • Allows export of private key for gw to use for encrypt/decrypt
  • Redirection Overview
    • App Gateway can redirect traffic
    • GW has generic redirection allowing for received traffic on one listener to send to another or external site
    • Simplifies app config and optimize resource useage
    • Types
      • 301 Perm redirect
      • 302 Found
      • 303 See Other
      • 307 Temp redirect
    • Capabilities
      • Global Redirection
        • From one. Listener to another on GW.
        • Enables HTTP to HTTPS on a site
      • Path-based Redirection
        • Enables HTTP to HTTPS only on specific site area
      • Redirect to external site
        • Requires new redirect config object
        • This specifies the target listener or external site
        • Element also supports options for appending URI path and query to redirected URL
        • Attached to source listener via new rule
  • App Gateway request routing rules
    • Request Routing Rule is key component of App GW as it determines how traffic is routed on the listener
    • Rule binds listener, backend pool, and backend HTTP settings
    • Accepted request, routing rule forwards it to backend or redirects
    • If forwarded – routing rule defines which pool to send to
    • Also determines if headers need to be rewritten
    • One listener to one rule
    • Types
      • Basic
        • All request associated to listener forwarded to backend using associated HTTP setting
      • Path-based
        • Allows routing request on listener to specific backend based on URL
        • If path of URL matches pattern it is routed per rule
        • Applies to path pattern only for URL path not parameters
        • If URL path does not match route to default backend and HTTP settings
  • HTTP settings
    • App GW routes to backend using port number, protocol, and other detailed settings
    • Port and Proto used in HTTP settings determine whether traffic between app gw and backend encrypted or not
    • Additional Uses
      • Determine whether user session kept on same server using cookie-based session affinity
      • Gracefully remove backend members using connection draining
      • Associate custom probe for backend monitoring
      • Set request timeout interval
      • Override host name and path
      • Provide one-select ease to specify settings for backend
Share this article:

Matt Ouellette

Matt Ouellette is a certified information technology professional residing in Southwest Michigan. His technology findings and advice can be found on his PacketPilot blog. Mr. Ouellette spent 4 years as an I.T. Technician before stepping into a Network Engineer role at Bronson Health Group. Since completing his Associates Degree in Network Administration Matt has taken a head on approach to career enrichment through obtaining credentials such as CCNP, CCNA Voice, MCSA: Server 2008, and VCP5. This passion for continued learning allows him to deliver up to date quality technical solutions.

Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-configure-azure-application-gateway/

Leave a Reply

Your email address will not be published.