Merge pull request #304713 from johndowns/reliability-bastion-edits

Reliability guide - Azure Bastion - Edits

Author: Stacyrch140

…astion/bastion-instance-zone-traffic.png …astion/bastion-instance-zone-traffic.pngarticles/reliability/media/bastion/bastion-instance-zone-traffic.png renamed to articles/reliability/media/reliability-bastion/bastion-instance-zone-traffic.png articles/reliability/media/bastion/bastion-instance-zone-traffic.png renamed to articles/reliability/media/reliability-bastion/bastion-instance-zone-traffic.png

@@ -6,7 +6,7 @@ ms.author: anaharris
 ms.topic: reliability-article
 ms.custom: subject-reliability, references_regions
 ms.service: azure-bastion
-ms.date: 04/04/2025
+ms.date: 10/09/2025
 ---
 
 # Reliability in Azure Bastion
@@ -16,14 +16,25 @@ This article describes reliability support in Azure Bastion and how to use [avai
 [!INCLUDE [Shared responsibility description](includes/reliability-shared-responsibility-include.md)]
 
 > [!IMPORTANT]
-> Zone redundancy features for Azure Bastion resources are currently in preview.
+> Availability zone support for Azure Bastion is currently in preview.
 > See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) 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 [enable zone redundancy](#availability-zone-support) if your Azure Bastion resources are in a supported region.
+For production deployments, you should:
+
+- Use the Basic SKU or higher.
+- [Enable zone redundancy](#availability-zone-support) 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](/azure/bastion/configuration-settings#subnet).
+
+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
 
@@ -35,25 +46,24 @@ If transient faults affect your virtual machine or Azure Bastion host, clients u
 
 [!INCLUDE [AZ support description](includes/reliability-availability-zone-description-include.md)]
 
-Azure Bastion supports availability zones in both zonal and zone-redundant configurations:
+Azure Bastion supports availability zones in both zone-redundant and zonal configurations:
 
-- *Zonal:* You can select a single availability zone for an Azure Bastion resource.
+- *Zone-redundant:* A zone-redundant bastion host achieves resiliency and reliability by spreading its instances across multiple [availability zones](../reliability/availability-zones-overview.md). 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:
+   
+    :::image type="content" source="media/reliability-bastion/bastion-instances-zones.png" alt-text="Diagram that shows Azure Bastion with three instances distributed across three availability zones to illustrate zone-redundant deployment." border="false":::
 
-   > [!NOTE]
-   > Pinning to a single zone doesn’t increase resiliency. To improve resiliency, you need to either use a zone-redundant configuration or explicitly deploy resources into multiple zones.
+    If you specify more availability zones than you have instances, Azure Bastion spreads instances across as many zones as it can.
 
-- *Zone-redundant:* Enabling zone redundancy for an Azure Bastion resource spreads your instances across multiple [availability zones](../reliability/availability-zones-overview.md). When you spread resources across availability zones, you can achieve resiliency and reliability for your production workloads.
-    
-    The following diagram shows a zone-redundant Azure Bastion resource, with its instances spread across three zones:
-    
-    :::image type="content" source="media/bastion/bastion-instances-zones.png" alt-text="Diagram that shows Azure Bastion with three instances distributed across three availability zones to illustrate zone-redundant deployment." border="false":::
+- *Zonal:* A zonal bastion host and all its instances are in a single availability zone that you select.
 
-    > [!NOTE]
-    > If you specify more availability zones than you have instances, Azure Bastion spreads instances across as many zones as it can. If an availability zone is unavailable, the instance in the faulty zone is replaced with another instance in a healthy zone.
+   > [!IMPORTANT]
+   > Pinning to a single availability zone is only recommended when [cross-zone latency](./availability-zones-overview.md#inter-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 Azure Bastion resources can be deployed into the following regions:
+Zonal and zone-redundant bastion hosts can be deployed into the following regions:
 
 | Americas | Europe | Middle East | Africa | Asia Pacific |
 |---|---|---|---|---|
@@ -67,47 +77,63 @@ Zonal and zone-redundant Azure Bastion resources can be deployed into the follow
 
 ### Requirements
 
-- To configure Azure Bastion resources to be zonal or zone redundant, you must deploy with the Basic, Standard, or Premium SKUs.
+- 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 zone redundancy for Azure Bastion.
+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](https://azure.microsoft.com/pricing/details/azure-bastion/).
 
 ### Configure availability zone support
 
-- **New resources:** When you deploy a new Azure Bastion resource in a [region that supports availability zones](#regions-supported), you select the specific zones that you want to deploy to. For zone redundancy, you must select multiple zones.
+- **Deploy a new bastion host with availability zone support:** When you deploy a new bastion host in a [region that supports availability zones](#regions-supported), you select the specific zones that you want to deploy to.
+
+    For zone redundancy, you must select multiple zones.
 
     [!INCLUDE [Availability zone numbering](./includes/reliability-availability-zone-numbering-include.md)]
 
-- **Existing resources:** It's not possible to change the availability zone configuration of an existing Azure Bastion resource. Instead, you need to create an Azure Bastion resource with the new configuration and delete the old one.
+- **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 Azure Bastion resources are configured for availability zone support and all availability zones are operational.
+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:
 
     <!-- Art Library Source# ConceptArt-0-000-015- -->
-    :::image type="content" source="./media/bastion/bastion-instance-zone-traffic.png" alt-text="Diagram that shows Azure Bastion with three instances. A user request goes to an Azure Bastion instance in zone 2 and is sent to a VM in zone 1." border="false":::
+    :::image type="content" source="./media/reliability-bastion/bastion-instance-zone-traffic.png" alt-text="Diagram that shows Azure Bastion with three instances. A user request goes to an Azure Bastion instance in zone 2 and is sent to a VM in zone 1." border="false":::
 
-   >[!TIP]
-   >In most scenarios, the amount of cross-zone latency isn't significant. However, if you have unusually stringent latency requirements 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.
+   > [!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 an Azure Bastion resource is configured for availability zone support and there's an availability zone outage.
+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](/azure/service-health/resource-health-overview) to monitor for the health of your bastion host. You can also use [Azure Service Health](/azure/service-health/overview) 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](/azure/service-health/alerts-activity-log-service-notifications-portal) and [Create and configure Resource Health alerts](/azure/service-health/resource-health-alert-arm-template-guide).
+
 - **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 virtual machine you're connecting to isn't in the affected availability zone, the virtual machine continues to be accessible. See [Reliability in virtual machines: Zone down experience](./reliability-virtual-machines.md#zone-down-experience) for more information on the VM zone down experience.
+    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](./reliability-virtual-machines.md#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.
 
@@ -117,13 +143,13 @@ When the availability zone recovers, Azure Bastion automatically restores instan
 
 ### Test for zone failures
 
-The Azure Bastion platform manages traffic routing, failover, and failback for zone-redundant Azure Bastion resources. Because this feature is fully managed, you don't need to initiate anything or validate availability zone failure processes.
+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 Azure Bastion resource is also unavailable.
+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 Azure Bastion resource is unavailable, you won't be able to use your Azure Bastion resource. 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.
+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.