This reference architecture shows a secure hybrid network that extends an on-premises network to Azure. The architecture implements a DMZ, also called a perimeter network, between the on-premises network and an Azure virtual network. All inbound and outbound traffic passes through Azure Firewall.
Architecture
Workflow
The architecture consists of the following aspects:
On-premises network. A private local-area network is implemented in an organization.
Azure virtual network. The virtual network hosts the application and other resources running in Azure.
Gateway. The gateway connects routers in the on-premises network and the virtual network. The gateway is placed in its own subnet.
Azure Firewall. Azure Firewall is a managed firewall as a service. The Firewall instance is placed in its own subnet.
Virtual network routes. Virtual network routes define the flow of IP traffic within the Azure virtual network. In the diagram shown above, there are two user-defined route tables.
o In the gateway subnet, traffic sent to the web-tier subnet (10.0.1.0/24) is routed through the Azure Firewall instance.
o In the web tier subnet, Since there is no route for address space of the VNet itself to point to Azure firewall, web tier instances are able to communicate directly to each other, not via Azure Firewall
Network security groups. Use security groups to restrict network traffic within the virtual network. For example, in the deployment provided with this reference architecture, the web tier subnet allows TCP traffic from the on-premises network and from within the virtual network; the business tier allows traffic from the web tier, and the data tier allows traffic from the business tier.
Bastion. Azure Bastion allows you to log into VMs in the virtual network through SSH or remote desktop protocol (RDP) without exposing the VMs directly to the internet. Use Bastion to manage the VMs in the virtual network.
Use cases
This architecture requires a connection to your on-premises data center, using either a VPN gateway or an ExpressRoute connection. Typical uses for this architecture include:
Hybrid applications where workloads run partly on-premises and partly in Azure.
Infrastructure that requires granular control over traffic entering an Azure virtual network from an on-premises data center.
Applications that must audit outgoing traffic. This is often a regulatory requirement of many commercial systems and can help to prevent public disclosure of private information.
Recommendations
The following recommendations apply to most scenarios. Follow these recommendations unless you have a specific requirement that overrides them.
Access control recommendations
Use Azure role-based access control (Azure RBAC) to manage the resources in your application. Consider creating the following custom roles:
A DevOps role with permissions to administer the infrastructure for the application, deploy the application components and monitor and restart VMs.
A centralized IT administrator role to manage and monitor network resources.
A security IT administrator role to manage secure network resources such as the firewall.
The DevOps and IT administrator roles should not have access to the firewall resources. This should be restricted to the security IT administrator role.
Resource group recommendations
Azure resources such as VMs, virtual networks, and load balancers can be easily managed by grouping them together into resource groups. Assign Azure roles to each resource group to restrict access.
We recommend creating the following resource groups:
A resource group containing the virtual network (excluding the VMs), NSGs, and the gateway resources for connecting to the on-premises network. Assign the centralized IT administrator role to this resource group.
A resource group containing the VMs for the Azure Firewall instance and the user-defined routes for the gateway subnet. Assign the security IT administrator role to this resource group.
Separate resource groups for each application tier that contain the load balancer and VMs. Note that this resource group shouldn't include the subnets for each tier. Assign the DevOps role to this resource group.
Networking recommendations
Add a Destination Network Address Translation (DNAT) rule to Azure Firewall to accept inbound traffic from the internet.
Destination address = Public IP address of the firewall instance.
Translated address = Private IP address within the virtual network.
Consider using Application Gateway or Azure Front Door for SSL termination.
Scalability considerations
For details about the bandwidth limits of VPN Gateway, see Gateway SKUs. For higher bandwidths, consider upgrading to an ExpressRoute gateway. ExpressRoute provides up to 10 Gbps bandwidth with lower latency than a VPN connection.
Availability considerations
If you're using Azure ExpressRoute to provide connectivity between the virtual network and on-premises network, configure a VPN gateway to provide failover if the ExpressRoute connection becomes unavailable.
Cost optimization
Here are cost considerations for the services used in this architecture.
Azure Firewall
In this architecture, Azure Firewall is deployed in the virtual network to control traffic between the gateway's subnet and the subnet in which the application tier runs. In this way Azure Firewall is cost effective because it's used as a shared solution consumed by multiple workloads. Here are the Azure Firewall pricing models:
Fixed-rate per deployment hour.
Data processed per GB to support auto-scaling.
When compared to network virtual appliances (NVAs), with Azure Firewall, you can save up to 30-50%. For more information, see Azure Firewall vs NVA.
Azure Bastion
Azure Bastion securely connects to your virtual machine over RDP and SSH without having the need to configure a public IP on the virtual machine.
Bastion billing is comparable to a basic, low-level virtual machine configured as a jump box. Comparing Bastion to a jump box, Bastion is more cost effective considering Bastion's built-in security features and no extra costs incurred for storage and managing a separate server.
Azure Virtual Network
Azure Virtual Network is free. Every subscription is allowed to create up to 50 virtual networks across all regions. All traffic that occurs within the boundaries of a virtual network is free. So if two VMs that are in the same VNET are talking to each other, then no charges will occur.
Internal load balancer
Basic load balancing between virtual machines that reside in the same virtual network is free.
In this architecture, internal load balancers are used to load balance traffic inside a virtual network.
Commentaires