Microsoft Azure Availability Zones are separate physical locations within an Azure region, each with one or more datacenters that have independent power, cooling, and networking. The physical separation of availability zones within a region limits the effect of zone failures on applications and data. The reference architecture presented in this article demonstrates best practices for a zonal deployment—a deployment that uses Availability Zones to increase application availability. A zonal deployment is appropriate for many kinds of applications.
This approach is used in high availability scenarios where resiliency is very important. With HA architecture there's a balance between high resiliency, low latency, and cost. This architecture uses redundant resources spread across zones to provide high resiliency. Traffic can be routed between zones to minimize the impact of a zone failure. If a zone does fail, resources in other zones absorb the traffic until the failed zone recovers. This provides a high level of resiliency.
This architecture provides an efficient use of resources, because most of the resources are actively used. All resources, other than the passive SQL Server, are used in handling requests. The passive SQL Server becomes active only if the active SQL Server fails.
The zone-redundant Azure Application Gateway and zone-redundant load balancer distribute the traffic to the available resources.
A zone-redundant Application Gateway routes traffic to VMs within the web tier. A zone-redundant load balancer routes traffic from the VMs in the web tier to the active SQL Server. In case of a zone failure, the Application Gateway routes to VMs in other available zones. Routing across zones has higher latency than routing within the zone.
If the active SQL Server becomes unavailable, either due to a zone failure or local failure, a passive SQL Server becomes the active SQL Server. The zone-redundant load balancer detects the failover to the newly active SQL Server, and routes traffic to it.
The following illustrates a failure of Zone 1.
The Application Gateway is zone-redundant. It isn't affected by the failure of Zone 1, and uses health probes to determine the available VMs. With Zone 1 unavailable, it routes traffic only to the remaining two zones. The zone-redundant load balancer is also unaffected by the failure of Zone 1, and uses health probes to determine the location of the active SQL Server. In this example, the load balancer detects that the active SQL Server is in Zone 3 and routes traffic to it.
Spreading resources across Availability Zones also protects an application from planned maintenance. When VMs are distributed across three Availability Zones they are, in effect, spread across three update domains. The Azure platform recognizes this distribution across update domains to ensure that VMs in different zones aren't updated at the same time.
By replicating VMs across Availability Zones, you can protect your applications and data from a zone failure. This is how Azure meets the industry-best 99.99% VM uptime service-level agreement (SLA)
Solution Components
General
Resource groups Resource groups are used to group Azure resources so they can be managed by lifetime, owner, or other criteria.
Azure Availability Zones Availability Zones are separate physical locations within an Azure region, each with one or more datacenters that have independent power, cooling, and networking. By placing VMs across zones, the application becomes resilient to failures within a zone.
Networking and load balancing
Virtual network and subnets
Every Azure VM is deployed into a virtual network that can be segmented into subnets, one subnet for each tier.
Application Gateway
Azure Application Gateway is a layer 7 load balancer. In this architecture, a zone-redundant Application Gateway routes HTTP requests to the web front end. Application Gateway also provides a Web Application Firewall (WAF) that protects the application from common exploits and vulnerabilities. The v2 SKU of Application Gateway supports cross-zone redundancy. A single Application Gateway deployment can run multiple gateway instances. For production workloads, run at least two.
Azure Load Balancer
Azure Load Balancer is a layer 4 load balancer. In this architecture, a zone-redundant Azure Standard Load Balancer directs network traffic from the web tier to SQL Server. Because a zone-redundant load balancer isn't pinned to a specific zone, the application continues to distribute the network traffic in case of a zone failure. A zone-redundant load balancer is used to provide availability in the case the active SQL Server becomes unavailable. The Standard SKU of Azure Load Balancer supports cross-zone redundancy.
Network Security Groups (NSGs)
A Network Security Group is used to restrict network traffic within the virtual network. In this architecture, the web tier only accepts traffic from the public IP endpoint. Also, the database tier does not accept traffic from any subnet other than the web-tier subnet.
DDoS protection
The Azure platform provides protection against distributed denial of service (DDoS) attacks. For additional protection, we recommend using Azure DDoS Protection Standard, which has enhanced DDoS mitigation features.
Azure Bastion
Azure Bastion provides secure and seamless Remote Desktop Protocol (RDP) and Secure Shell (SSH) access to the VMs within the virtual network. This provides access while limiting the exposed public IP addresses of the VMs within the virtual network. Azure Bastion provides a cost-effective alternative to a provisioned VM to provide access to all VMs within the same virtual network.
Microsoft SQL Server
SQL Server Always On availability groups. A SQL Server Always On availability group provides high availability at the data tier by enabling replication and failover. It uses Windows Server Failover Cluster (WSFC) technology for failover.
Cloud Witness. A failover cluster requires that more than half of its nodes are running, a condition known as having quorum. If the cluster has just two nodes, a network partition could cause each node to think it's the primary node. In that case, you need a witness to break ties and establish quorum. A witness is a resource such as a shared disk that can act as a tie breaker to establish quorum. Cloud Witness is a type of witness that uses Azure Blob Storage. The Azure Blob Storage must use Zone Redundant Storage (ZRS) to be unaffected by a zone failure.
Network Security Groups
Use NSG rules to restrict traffic between tiers. In this architecture, only the web tier can communicate directly with the database tier. To enforce this rule, the database tier should block all incoming traffic except for the web-tier subnet.
Deny all inbound traffic from the virtual network. (Use the VIRTUAL_NETWORK tag in the rule.)
Allow inbound traffic from the web-tier subnet.
Allow inbound traffic from the database-tier subnet itself. This rule allows communication between the database VMs, which is needed for database replication and failover.
Create rules 2 – 3 with higher priority than the first rule, so they override it.
SQL Server Always On availability groups
We recommend Always On availability groups for Microsoft SQL Server high availability. Other tiers connect to the database through an availability group listener. The listener enables a SQL client to connect without knowing the name of the physical instance of SQL Server. VMs that access the database must be joined to the domain. The client (in this case, another tier) uses DNS to resolve the listener's virtual network name into IP addresses.
Configure the SQL Server Always On availability group as follows :
Create a Windows Server Failover Clustering (WSFC) cluster, a SQL Server Always On availability group, and a primary replica.
Create an internal load balancer with a static private IP address.
Create an availability group listener and map the listener's DNS name to the IP address of an internal load balancer.
Create a load balancer rule for the SQL Server listening port (TCP port 1433 by default). The load balancer rule must enable floating IP, also called Direct Server Return. This causes the VM to reply directly to the client, which enables a direct connection to the primary replica.
Security considerations
Virtual networks are a traffic isolation boundary in Azure. By default, VMs in one virtual network can't communicate directly with VMs in a different virtual network. However, you can explicitly connect virtual networks by using virtual network peering.
Traffic restriction
Use Network Security Groups (NSGs) to restrict traffic to and from the internet.
DMZ
Consider adding a network virtual appliance (NVA) to create a DMZ between the internet and the Azure virtual network. NVA is a generic term for a virtual appliance that can perform network-related tasks, such as firewall, packet inspection, auditing, and custom routing.
Encryption
Encrypt sensitive data at rest and use Azure Key Vault to manage the database encryption keys. Key Vault can store encryption keys in hardware security modules (HSMs). It's also recommended to store application secrets, such as database connection strings, in Key Vault.
DDoS protection
The Azure platform provides basic DDoS protection by default. This basic protection is targeted at protecting the Azure infrastructure. Although basic DDoS protection is automatically enabled, we recommend using Azure DDoS Protection Standard. Standard protection uses adaptive tuning, based on your application's network traffic patterns, to detect threats. This allows it to apply mitigations against DDoS attacks that might go unnoticed by the infrastructure-wide DDoS policies. Standard protection also provides alerting, telemetry, and analytics through Azure Monitor.
Cost considerations
Here are some other considerations
Virtual Machine Scale Sets
Virtual Machine Scale Sets are available on all Windows VM sizes. You're charged only for the Azure VMs that you deploy, and for any additional underlying infrastructure resources consumed, such as storage and networking. There are no incremental charges for the Virtual Machine Scale Sets service.
SQL Server
If you choose Azure SQL DBaaS, you can reduce costs because you don't need to configure an Always On availability group and domain controller machines. There are several deployment options starting from single database up to managed instance, or elastic pools.
Azure Load Balancer
You're charged only for the number of configured load-balancing and outbound rules. Inbound NAT rules are free. There's no hourly charge for the Standard Load Balancer when no rules are configured.
Application Gateway
The Application Gateway should be provisioned with the v2 SKU and can span multiple Availability Zones. With the v2 SKU, the pricing model is driven by consumption and has two components: Hourly fixed price and a consumption-based cost.