Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article describes reliability support in Azure Bastion and how to use availability zones and zone redundancy to reduce downtime and improve resiliency for production workloads. It also covers multi-region deployment guidance for disaster recovery.
Reliability is a shared responsibility between you and Microsoft. You can use this guide to determine which reliability options fulfill your specific business objectives and uptime goals.
Important
Availability zone support for Azure Bastion is currently in preview. See the Supplemental Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure features that are in beta, in preview, or otherwise not yet released into general availability.
Azure Bastion is a fully managed platform as a service (PaaS) that you provision to provide high-security connections to virtual machines via a private IP address. It provides seamless RDP/SSH connectivity to your virtual machines directly over TLS from the Azure portal, or via the native SSH or RDP client that's already installed on your local computer. When you connect via Azure Bastion, your virtual machines don't need a public IP address, an agent, or special client software.
Production deployment recommendations
For production deployments, you should:
- Use the Basic SKU or higher.
- Enable zone redundancy if your bastion host is in a supported region.
Reliability architecture overview
When you use Azure Bastion, you must deploy a bastion host to a subnet that meets Azure Bastion's requirements.
A bastion host has a defined number of instances, which are also sometimes called scale units. Each instance represents a single dedicated VM that handles your Bastion connections. The platform automatically manages instance creation, health monitoring, and replacement of unhealthy instances, so you don't see or manage the VMs directly.
The Basic SKU supports exactly two instances. Standard and Premium SKUs support host scaling, where you can configure the number of instances, with a minimum of two instances. When you add more instances, your bastion host can accommodate additional concurrent client connections.
Transient faults
Transient faults are short, intermittent failures in components. They occur frequently in a distributed environment like the cloud, and they're a normal part of operations. Transient faults correct themselves after a short period of time. It's important that your applications can handle transient faults, usually by retrying affected requests.
All cloud-hosted applications should follow the Azure transient fault handling guidance when they communicate with any cloud-hosted APIs, databases, and other components. For more information, see Recommendations for handling transient faults.
If transient faults affect your virtual machine or Azure Bastion host, clients using the secure sockets host (SSH) and Remote Desktop Protocol (RDP) protocols typically retry automatically.
Availability zone support
Availability zones are physically separate groups of datacenters within each Azure region. When one zone fails, services can fail over to one of the remaining zones.
Azure Bastion supports availability zones in both zone-redundant and zonal configurations:
Zone-redundant: A zone-redundant bastion host achieves resiliency and reliability by spreading its instances across multiple availability zones. You select which availability zones you want to use for your bastion host.
The following diagram shows a zone-redundant bastion host, with its instances spread across three zones:
If you specify more availability zones than you have instances, Azure Bastion spreads instances across as many zones as it can.
Zonal: A zonal bastion host and all its instances are in a single availability zone that you select.
Important
Pinning to a single availability zone is only recommended when cross-zone latency is too high for your needs and after you verify that the latency doesn't meet your requirements. By itself, a zonal bastion host doesn't provide resiliency to an availability zone outage. To improve the resiliency of a zonal bastion host, you need to explicitly deploy separate bastion hosts into multiple availability zones and configure traffic routing and failover.
Regions supported
Zonal and zone-redundant bastion hosts can be deployed into the following regions:
Americas | Europe | Middle East | Africa | Asia Pacific |
---|---|---|---|---|
Canada Central | North Europe | Qatar Central | South Africa North | Australia East |
Central US | Sweden Central | Israel Central | Korea Central | |
East US | UK South | |||
East US 2 | West Europe | |||
West US 2 | Norway East | |||
East US 2 EUAP | Italy North | |||
Mexico Central | Spain Central |
Requirements
To configure bastion hosts to be zonal or zone redundant, you must deploy with the Basic, Standard, or Premium SKUs.
Azure Bastion requires a Standard SKU zone-redundant Public IP address.
Cost
There's no additional cost to use availability zone support for Azure Bastion. Charges are based on your bastion host's SKU and the number of instances that it uses. For information, see Azure Bastion pricing.
Configure availability zone support
Deploy a new bastion host with availability zone support: When you deploy a new bastion host in a region that supports availability zones, you select the specific zones that you want to deploy to.
For zone redundancy, you must select multiple zones.
When you select which availability zones to use, you're actually selecting the logical availability zone. If you deploy other workload components in a different Azure subscription, they might use a different logical availability zone number to access the same physical availability zone. For more information, see Physical and logical availability zones.
Existing bastion hosts: It's not possible to change the availability zone configuration of an existing bastion host. Instead, you need to create a bastion host with the new configuration and delete the old one.
Normal operations
This section describes what to expect when bastion hosts are configured for availability zone support and all availability zones are operational.
Traffic routing between zones: When you initiate an SSH or RDP session, it can be routed to an Azure Bastion instance in any of the availability zones you selected.
If you configure zone redundancy on Azure Bastion, a session might be sent to an Azure Bastion instance in an availability zone that's different from the virtual machine you're connecting to. In the following diagram, a request from the user is sent to an Azure Bastion instance in zone 2, although the virtual machine is in zone 1:
Tip
In most scenarios, the amount of cross-zone latency isn't significant. However, if you have unusually stringent latency requirements for your workloads, you should deploy a dedicated single-zone Azure Bastion instance in the virtual machine's availability zone. Keep in mind that this configuration doesn't provide zone redundancy, and we don't recommend it for most customers.
Data replication between zones: Because Azure Bastion doesn't store state, there's no data to replicate between zones.
Zone-down experience
This section describes what to expect when bastion hosts are configured for availability zone support and there's an availability zone outage.
Detection and response: When you use zone redundancy, Azure Bastion detects and responds to failures in an availability zone. You don't need to do anything to initiate an availability zone failover.
For zone-redundant instances, Azure Bastion makes a best-effort attempt to replace any instances that are lost due to a zone outage. However, it isn't guaranteed that instances will be replaced.
Notification: Azure Bastion doesn't notify you when a zone is down. However, you can use Azure Resource Health to monitor for the health of your bastion host. You can also use Azure Service Health to understand the overall health of the Azure Bastion service, including any zone failures.
Set up alerts on these services to receive notifications of zone-level problems. For more information, see Create Service Health alerts in the Azure portal and Create and configure Resource Health alerts.
Active requests: When an availability zone is unavailable, any RDP or SSH connections in progress that use an Azure Bastion instance in the faulty availability zone are terminated and need to be retried.
If the VM you're connecting to isn't in the affected availability zone, it continues to run. For more information on the VM zone-down experience, see Reliability in VMs - Zone down experience.
Expected downtime: The expected downtime depends on the availability zone configuration that your Azure Bastion instance uses.
Zone-redundant: A small amount of downtime might occur while the service recovers operations. This downtime is typically a few seconds.
Zonal: Your instance is unavailable until the availability zone recovers.
Expected data loss: Because Azure Bastion doesn't store state, there's no data loss expected during a zone failure.
Traffic rerouting: When you use zone redundancy, new connections use Azure Bastion instances in the surviving availability zones. Overall, Azure Bastion remains operational.
Zone recovery
When the availability zone recovers, Azure Bastion automatically restores instances in the availability zone, and reroutes traffic between your instances as normal.
Test for zone failures
The Azure Bastion platform manages traffic routing, failover, and failback for zone-redundant bastion hosts. Because this feature is fully managed, you don't need to initiate anything or validate availability zone failure processes.
Multi-region support
Azure Bastion is deployed within virtual networks or peered virtual networks and is associated with an Azure region. Azure Bastion is a single-region service. If the region becomes unavailable, your bastion host is also unavailable.
Azure Bastion supports reaching virtual machines in globally peered virtual networks, but if the region that hosts your bastion host is unavailable, you won't be able to use your bastion host. For higher resiliency, if you deploy your overall solution into multiple regions with separate virtual networks in each region, you should deploy Azure Bastion into each region.
If you have a disaster recovery site in another Azure region, be sure to deploy Azure Bastion into the virtual network in that region.
Service-level agreement
The service-level agreement (SLA) for Azure services describes the expected availability of each service and the conditions that your solution must meet to achieve that availability expectation. For more information, see SLAs for online services.