Reliability in Azure Bastion

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.

When you use Azure, reliability is a shared responsibility. Microsoft provides a range of capabilities to support resiliency and recovery. You're responsible for understanding how those capabilities work within all of the services you use, and selecting the capabilities you need to meet your business objectives and uptime goals.

This article describes how to make Azure Bastion resilient to a variety of potential outages and problems, including transient faults, availability zone outages, and region outages. It highlights some key information about the Azure Bastion service level agreement (SLA).

Production deployment recommendations

For production workloads, we recommend that you:

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 Azure 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.

Resilience to 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 bastion host, clients using the secure sockets host (SSH) and Remote Desktop Protocol (RDP) protocols typically retry automatically.

Resilience to availability zone failures

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 resource doesn't provide resiliency to an availability zone outage. To improve the resiliency of a zonal resource, you need to explicitly deploy separate resources into multiple availability zones and configure traffic routing and failover. For more information, see Zonal resources and zone resiliency.

Requirements

• Region support: 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

• SKU: To configure bastion hosts to be zonal or zone redundant, you must deploy with the Basic, Standard, or Premium SKUs.

• Public IP address: 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.

Behavior when all zones are healthy

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 your bastion host, a session might be sent to a 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 bastion host 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.

Behavior during a zone failure

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: Microsoft doesn't automatically notify you when a zone is down. However:

  • You can use Azure Resource Health to monitor for the health of an individual resource, and you can set up Resource Health alerts to notify you of problems.

  • You can use Azure Service Health to understand the overall health of the service, including any zone failures, and you can set up Service Health alerts to notify you of problems.

• 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 bastion host 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 healthy 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.

Resilience to region-wide failures

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.

Related content

• Reliability in Azure