Facebook
Instagram

AZ-300-Prep-Guide: Azure Networking – Application Gateway

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

Microsoft Documentation

Overview

  • Basic Information
    • It’s an application delivery controller with application level load balancing capabilities for web traffic 
      • Because it is application level, we can manage traffic beyond source/destination IP (Layer 3) and source/destination port (Layer 4) E.g. based on the path of the traffic
      • It’s ONLY for Web traffic and not other protocols
      • It enables us to manage traffic to our web applications.
    • It offers highly available and scalable service, which is fully managed by Azure.
      • Azure Application Gateway is an Application Delivery Controller (ADC) as a service, offering various layer 7 load-balancing capabilities for your applications
Two Tiers/Two Versions
  • Tiers
    • Standard and WAF
  • Versions
    • v1 and v2
  • v1 vs v2
    • v2 currently in public preview as at 09/11/2018 (which means no SLA and not recommended for production)
      • Available in East US 2, US Central, West US2, France Central, West Europe, and South East Asia.
        • Supports autoscaling
        • Supports availability zone redundancy
        • Supports Static VIP (so IP does not change on restart)
        • 5X better SSL offload performance
        • Faster deployment and update time
Features and Functionality
  • Standard
    • SSL offloading
      • Self-Signed certs, CA certs, and wild-card certs are supported. 
      • EV certs are not supported.
      • TLS 1.0, 1.1 and 1.2 are allowed by default but you can configure to deny them
      • SSL 2.0 and 3.0 are disabled by default and not configurable
    • End to end SSL encryption
    • Cookie-based session affinity
      • By using gateway-managed cookies, the Application Gateway can direct subsequent traffic from a user session to the same server for processing
      • important in cases where session state is saved locally on the server for a user session.
    • Redirection
      • Global redirection from one port to another port on the Gateway. This enables HTTP to HTTPS redirection on a site.
      • Path-based redirection. This type of redirection enables HTTP to HTTPS redirection only on a specific site area, for example a shopping cart area denoted by /cart/*.
          • Redirect to an external site.
    • URL path-based routing
    • Multi site hosting
      • Configure up to 20 web sites on the same application gateway instance. Each web site can be directed to its own backend pool
      • Two subdomains of the same parent domain can be hosted on the same application gateway deployment. Examples of using subdomains could include http://blog.contoso.com and http://app.contoso.com 
    • Connection draining
    • Custom error pages
    •  WebSocket and HTTP/2 support
      • Native support for HTTP, HTTPS, HTTP/2, and WebSocket protocols
      • By default, HTTP/2 support is disabled
        • HTTP/2 support can be enabled using Azure PowerShell
        • HTTP/2 protocol support is available to clients connecting to application gateway listeners only. The communication to backend server pools is over HTTP/1.1
  • WAF
    • OWASP top 10
      • Based on rules from the OWASP (Open Web Application Security Project) core rule sets 2.2.9 and 3.0.
      • Protection of web applications from common exploits and vulnerabilities. 
        • SQL injection protection
        • Cross site scripting protection
        • Common Web Attacks Protection such as command injection, HTTP request smuggling, HTTP response splitting, and remote file inclusion attack
        • Protection against HTTP protocol violations
        • Protection against HTTP protocol anomalies such as missing host user-agent and accept headers
        • Prevention against bots, crawlers, and scanners
        • Detection of common application misconfigurations (that is, Apache, IIS, etc.)
    • WAF Configurability (Preview)
      • Control request body evaluation
      • Control request and file sizes
    • WAF Exclusion List (Preview)
      • Exclude request attributes from WAF evaluation
      • Apply to request header/cookies/parameters
  • Standard v2
    • Standard plus the capabilities below
    • Autoscaling
    • Availability zone redundancy
    • Supports Static VIP (so IP does not change on restart)
    • 5X better SSL offload performance
    • Faster deployment and update time
  • WAF v2
    • All of the above
      • Certificate authentication not supported
Scalability
  • 50 application gateways per subscription. Can be increased to 1000.
  • How else does Application Gateway support scalability?
    • The Application Gateway v1 SKU supports scalability by adding multiple instances of the same gateway to share the load.
      • Customer has more responsibility to monitor and add more instances to handle the load if needed.
      • No downtime when doing a manual scale up/down
    • The v2 SKU automatically ensures that new instances are spread across fault domains and update domains. If zone redundancy is chosen, the newest instances are also spread across availability zones to offer zonal failure resiliency.
Availability
  • It is recommended to use a CNAME alias and point it to the DNS address of the application gateway because the VIP can change if the application gateway is stopped and started (the DNS name does no change)
    • Static VIPs can be used for v2
  • How else does Application Gateway support high availability?
    • The Application Gateway v1 SKU supports high availability scenarios when you have two or more instances deployed. Azure distributes these instances across update and fault domains to ensure that all instances do not fail at the same time.
      • The customer has more responsibility to add more than one instance. Microsoft will ensure they are added to the same availability set.
      • No downtime when doing a manual scale up/down
    • The v2 SKU automatically ensures that new instances are spread across fault domains and update domains. If zone redundancy is chosen, the newest instances are also spread across availability zones to offer zonal failure resiliency.
  • There is an availability SLA 
    • For Application Gateway service having two or more medium or larger instances , there is a SLA of 99.95%
    • There is no availability SLA for Application Gateway services with only one instance or with small instances
Performance
  • Application Gateway is currently offered in three sizes: Small, Medium, and Large. Small instance sizes are intended for development and testing scenarios
    • Small has no WAF option. Only Medium and Large.
  • The following table shows an average performance throughput for each application gateway instance with SSL offload enabled:
    • These values are approximate values for an application gateway throughput. The actual throughput depends on various environment details, such as average page size, location of back-end instances, and processing time to serve a page. For exact performance numbers, you should run your own tests.
    • The size can be changed from small to medium OR medium to large with no disruption
Security
  • Securing your security solution
    • NSGs can be used to lock down connectivity but must be done very carefully
      • Exceptions must be put in for incoming traffic on ports 65503-65534 for the Application Gateway v1 SKU and ports 65200 – 65535 for the v2 SKU. This port-range is required for Azure infrastructure communication. They are protected (locked down) by Azure certificates. Without proper certificates, external entities, including the customers of those gateways, will not be able to initiate any changes on those endpoints.
      • Outbound internet connectivity can’t be blocked.
      • Traffic from the AzureLoadBalancer tag must be allowed.
Monitoring and Logging
  • Diagnostic Logs
    • https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-diagnostics
    • Three Logs – Access log, Performance log and Firewall log (descriptions below)
      • Not enabled by default. Must be enabled for collection to start.
      • Can be enabled using the Azure Portal (Diagnostic Logs of the application gateway) or through PowerShell (Set-AzureRmDiagnosticSetting; the resource ID of both the Azure storage account and the application gateway is needed)
      • Can be stored in an Azure storage account, Azure event hub or Azure log analytics
        • Retention Policy
          • Diagnostic logs flow to the customers storage account and customers can set the retention policy based on their preference. Diagnostic logs can also be sent to an Event Hub or Log Analytics. See Application Gateway Diagnostics for more details.
      • Can be viewed and analyzed using Azure Log analytics (visualizations and powerful search capabilities)
        • You can also connect to your storage account and retrieve the JSON log entries for access and performance logs. After you download the JSON files, you can convert them to CSV and view them in Excel, Power BI, or any other data-visualization tool.
        • We have published a Resource Manager template that installs and runs the popular GoAccess log analyzer for Application Gateway Access Logs. GoAccess provides valuable HTTP traffic statistics such as Unique Visitors, Requested Files, Hosts, Operating Systems, Browsers, HTTP Status codes and more. For more details, please see the Readme file in the Resource Manager template folder in GitHub.
  • Three storage options for the logs
    • Storage account
      • Storage accounts are best used for logs when logs are stored for a longer duration and reviewed when needed.
      • The use of storage for access and performance logging incurs service charges.
    • Event hubs
      • Event hubs are a great option for integrating with other security information and event management (SEIM) tools to get alerts on your resources.
    • Log Analytics
      • Log Analytics is best used for general real-time monitoring of your application or looking at trends.
  • ApplicationGatewayAccessLog 
    • For both WAF and Standard SKUs
    • Contains each request submitted to the application gateway frontend. 
      • Each access of Application Gateway is logged in JSON format
    • The data includes the caller’s IP, URL requested, response latency, return code, bytes in and out. 
    • Access log is collected every 300 seconds (5 minutes).
    • This log contains one record per instance of an application gateway
  • ApplicationGatewayPerformanceLog
    • For both WAF and Standard SKUs
    • The performance log captures performance information on per instance basis including total request served, throughput in bytes, total requests served, failed request count, healthy and unhealthy back-end instance count.
    • A performance log is collected every 60 seconds (1 minute).
      • Latency is calculated from the time when the first byte of the HTTP request is received to the time when the last byte of the HTTP response is sent. It’s the sum of the Application Gateway processing time plus the network cost to the back end, plus the time that the back end takes to process the request.
  • ApplicationGatewayFirewallLog
    • For WAF SKUs only
    • The firewall log contains requests that are logged through either detection or prevention mode of an application gateway that is configured with web application firewall.
  • Metrics
    • Metrics are a feature for certain Azure resources where you can view performance counters in the portal. 
      • Azure Portal → Application Gateway → Under Monitoring, click Metrics
      • We can start alert rules based on metrics for a resource. For example, an alert can call a webhook or email an administrator if the throughput of the application gateway is above, below, or at a threshold for a specified period.
        • Azure Portal → Application Gateway → Under Monitoring, click Metrics → Add metric alert → Add rule blade → Fill out conditions
      • For Application Gateway, the following metrics are available:
        • Current Connections
        • Failed Requests
        • Healthy Host Count
          • You can filter on a per backend pool basis to show healthy/unhealthy hosts in a specific backend pool.
        • Response Status
          • The response status code distribution can be further categorized to show responses in 2xx, 3xx, 4xx, and 5xx categories.
        • Throughput
        • Total Requests
        • Unhealthy Host count
          • You can filter on a per backend pool basis to show healthy/unhealthy hosts in a specific backend pool.
  • Verifying the health of the backend pool members
    • You can use the PowerShell cmdlet Get-AzureRmApplicationGatewayBackendHealth or verify health through the portal by visiting Application Gateway Diagnostics
    • If you see a back-end health status of Unknown, ensure that access to the back end is not blocked by an NSG rule, a user-defined route (UDR), or a custom DNS in the virtual network.
Automation
  • Azure ARM
  • Azure PowerShell
  • Azure CLI
  • REST API
Cost
  • Two things are charged
    • The amount of time that the gateway is provisioned and available
    • The amount of data processed by the application gateways.
  • Running cost
    • This is a fixed fee
    • A partial hour is billed as a full hour
    • Is this a per-instance cost?
  • Data processing
    • This is different from egress data. Data transferred out of Azure data centres from the application gateways will still be charged at standard data transfer rates.
    • Graduated cost model which means that costs reduce as you consume more
      • Difficult for this to be a major issue as first 10TB is free for medium size and first 40TB is free for large size
Compliance
    • HIPAA Compliance
      • Encrypt data in transit
        • Enable HTTP to HTTPS redirection
        • Use HTTPS with trusted certificate 
          • EV certificate not supported though. Evaluate if this impacts your compliance
        • Disable weak ciphers and TLS versions
      • Encrypt data at rest
        • For your activity and diagnostic logs, ensure they are stored in storage accounts with encryption enabled
          • Encryption a rest enabled by default
        • Ensure that those storage accounts storing the logs have insecure protocols disabled
        • If integrating with monitoring systems, ensure that 
          • Azure Blob, database, e.t.c
      • Enforcing least privileges
        • Use IAM and RBAC to lock down who can modify the resources and who has access to the logs in the storage accounts (of any monitoring and analysis solution integrated)
      • Auditing
        • Extend retention for activity logs beyond the default 90 days
        • Configure extended retention for the diagnostic logs also
      • Data Backup
      • HA and DR
      • Logging and logs integrity
    • GDPR Compliance
      • Review the GDPR articles
      • Article 32 highlights right to the protection of personal data
        • https://gdpr-info.eu/art-32-gdpr/
        • The controller is responsible for implementing appropriate risk-based technical and organizational measures, including pseudonymization and encryption of personal data, security measures to adequately ensure ongoing confidentiality, integrity, availability, and resilience of systems and services
          • Enabling SSL offload, SSL end-to-end; Disabling TLS 1.0 and 1.1 all come into play but compliance with GDPR is way beyond this
Support/SLA
  • Technical support is provided for all Azure services released to general availability, including the Application Gateway, through Azure Support
    • Cost per subscription starts at £21.62/month.
    • Billing and subscription management support is provided at no cost.
  • There is an availability SLA
    • For Application Gateway service having two or more medium or larger instances, there is a SLA of 99.95%
    • There is no availability SLA for Application Gateway services with only one instance or with small instances.

Subscribe To Our Newsletter

Get updates and learn from the best

More To Explore

Do You Want To Boost Your Business?

drop us a line and keep in touch

Contact Us
Facebook
Instagram