Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your applications. It can be used as an internal application load balancer or as an internet-facing application load balancer (How an application gateway works | Microsoft Learn).
With the recent announce of “Private Application Gateway” you can deploy the Application Gateway without a frontend IP configuration referencing a public IP enabling further control over traffic routing and internet egress.
On the other hand, when you create private endpoints for Azure PaaS services (i.e., Azure Functions, Azure Key Vault, Event Hubs, etc.…) the associated FQDN for each service is a public name.
Some of our customers, especially in the FSI sector, use Proxies to route all internet bound traffic, and in such architectures all requests to private endpoints from their networks are routed through the proxy and therefore never reach the private IP of the associated PaaS service.
As a solution you can use Azure Application Gateway, to map custom domain names for your PaaS services, enabling your internal customers and solutions to access your services.
This reference architecture details several configurations to consider when using Azure Application Gateway to map custom domain names to Azure Private Endpoint enabled PaaS services.
A reference implementation of this architecture is available on GitHub.
Architecture
The following diagram shows how the Contoso organization uses Azure Application Gateway as core component for their custom domain name solution:
Workflow
This request flow proceeds as follows:
- Before a client sends a request from the contoso network to the private endpoint enabled PaaS service, it resolves the custom domain name by using the Domain Name System (DNS) server.
- The DNS server returns the Application Gateway’s private IP address to the client.
- The application gateway accepts the incoming traffic through a specific listener configured with the IP address, protocol, and port number.
- The request is then routed to the private endpoint enabled PaaS service which is configured as a backend using the service private link FQDN
- Application Gateway resolves the private link FQDN using the DNS server which in turns forwards the query to Azure DNS.
- Application Gateway sends the traffic to the correct private IP.
Components
This architecture uses the following Azure components:
Azure Application Gateway with or without web application firewall (WAF) is at the core of this solution, exposing HTTP(S) or TCP endpoints and routing traffic to the Private Endpoint enabled PaaS Services.
Azure Virtual Networks are isolated and highly secure environments for running virtual machines (VMs) and applications. This reference architecture uses a peered hub-spoke virtual network topology. The hub virtual network holds the Azure firewall and the custom DNS server and the Custom DNS Zones. The spoke virtual network holds the Application Gateway subnet and the PaaS services subnets.
Azure Private Link allocates specific private IP addresses to access Azure PaaS services through Private Endpoints from within the Application Gateway.
Azure Firewall is a network security service that protects all the Azure Virtual Network resources. The firewall allows only approved services and fully qualified domain names (FQDNs) as egress traffic.
Azure Key Vault stores and manages certificates used by the Application Gateway and secrets used by Contoso’s developers.
Azure Private DNS used to resolve private endpoint domains and the constoso.corp domain.
Azure Functions serverless application.
Azure Event Hubs a modern big data streaming platform and event ingestion service
Azure Cosmos DB fully managed and serverless distributed database
Azure Storage Microsoft's cloud storage solution for modern data storage scenarios
Azure Container Instances serverless containers
Azure VPN Gateway service that uses a specific type of virtual network gateway to send encrypted traffic between an Azure virtual network and on-premises locations over the public Internet.
Azure Managed Identity Managed identities eliminate the need for developers to manage credentials, certificates, and keys used to secure communication between services.
Scenario details
The example Contoso Azure Application Gateway: Private Endpoint Custom Name Solution Reference Architecture and ... shown in the preceding diagram implements the architectural components and practices discussed in this article.
In this example, Contoso, Inc., a fictitious company, have a series of services running on-premises network which connect to private endpoint protected Azure PaaS services. When an on-premises service sends a request to a PaaS service it does so by using a private FQDN (i.e. func.contoso.corp), the custom domain name is resolved by Contoso’s DNS servers to the private IP of the Application Gateway. The Application Gateway then sends the request to the correct PaaS service and the traffic flow completes.
Potential use cases
This custom domain name architecture may prove useful for solutions deployed in the financial services and insurance industry.
Considerations
These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that can be used to improve the quality of a workload.
For more information, see Microsoft Azure Well-Architected Framework.
Scalability
Consider that Application Gateway and WAF can be configured to scale in two modes:
- Autoscaling - With autoscaling enabled, the Application Gateway and WAF v2 SKUs scale out or in based on application traffic requirements. This mode offers better elasticity to your application and eliminates the need to guess the application gateway size or instance count.
- Manual - You can also choose Manual mode where the gateway won't autoscale. In this mode, if there's more traffic than what Application Gateway or WAF can handle, it could result in traffic loss.
Manageability
Consider the following points when planning for manageability:
- Manage the Azure Application Gateway infrastructure via an automated deployment pipeline. The reference implementation for this architecture provides a series of Terraform configuration files that you can reference when building your pipeline.
Security
Consider the following points when planning for security:
- For a full private solution, deploy the Application Gateway without any Public IP associated.
- Ensure that secrets and credentials are stored in secure locations such as Azure Key Vault, instead of embedding them into code or configuration files.
- For more check: Azure security baseline for Application Gateway | Microsoft Learn
Cost optimization
- Azure Application Gateway autoscaling allows you to save cost by not requiring the gateway to run at peak-provisioned capacity for expected maximum traffic load. See Scaling and Zone-redundant Application Gateway v2 | Microsoft Learn
- To estimate the cost of the required resources, see the Application Gateway calculator.
Deploy this scenario
In order to deploy this scenario, you can use Terraform by running the following command:
terraform init
terraform apply
Check the Deployment
Once the solution is deployed, you can download the tests results (TestResults.trx) with the following commands:
resultsShareKey=$(terraform output -raw results_share_key)
resultsShareName=$(terraform output -raw results_share_name)
resultsAccountName=$(terraform output -raw results_account_name)
resultsFile=$(terraform output -raw results_file)
az storage file download --account-key $resultsShareKey --account-name $resultsAccountName --share-name $resultsShareName --path $resultsFile
The results file should look like the following:
Checking Container Logs
To check the container logs with Azure CLI run the fallowing command:
$resourceGroup=$(terraform output -raw resource_group)
$containerGroup=$(terraform output -raw contaner_group_name)
$containerName=$(terraform output -raw container_name)
az container logs --resource-group $resourceGroup --name $containerGroup --container-name $containerName
Please refer to the Terraform Modules for more information.