Merge pull request #304564 from johndowns/reliability-bastion-updates

Reliability Hub - Minor updates

Author: prmerger-automator[bot]

articles/reliability/reliability-ai-search.md

@@ -81,7 +81,7 @@ When an availability zone experiences an outage, your search service continues t
 
 + **Traffic rerouting**: When a zone fails, Azure AI Search detects the failure and routes requests to active replicas in the surviving zones.
 
-### Failback
+### Zone recovery
 
 When the availability zone recovers, Azure AI Search automatically restores normal operations and begins routing traffic to available replicas across all zones, including the recovered zone.
 

articles/reliability/reliability-aks.md

@@ -114,7 +114,11 @@ There's no extra charge to enable availability zone support in AKS. You pay for
 
    AKS also attempts to rebalance the pods across the healthy zones. If you choose to manually scale your node pool in a zone-down scenario, your pods might remain in the *Pending* state when there are no nodes available in the healthy zones. Scaling out in the remaining zones is also subject to the availability of quota and capacity for the VM SKU that you use.
 
-- **Notification:** AKS doesn't notify you when a zone is down. You can use your node or pod health metrics to monitor the health of your nodes and pods.
+- **Notification:** AKS 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 cluster. You can also use [Azure Service Health](/azure/service-health/overview) to understand the overall health of the AKS 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).
+
+   You can also use your node or pod health metrics to monitor the health of your nodes and pods.
 
 - **Active requests:** Any active requests might experience disruptions. Some requests can fail, and latency might increase while your workload fails over to another zone.
 
@@ -126,7 +130,7 @@ There's no extra charge to enable availability zone support in AKS. You pay for
 
 For more information, see [Zone resiliency considerations for AKS](/azure/aks/aks-zone-resiliency).
 
-### Failback
+### Zone recovery
 
 When the availability zone recovers, failback behavior depends on the component:
 

articles/reliability/reliability-api-management.md

@@ -197,9 +197,9 @@ This section describes what to expect when API Management instances are configur
 
     - *Zonal:* For zonal instances, when a zone is unavailable, your instance is unavailable. If you have a secondary instance in another availability zone, you're responsible for rerouting traffic to that secondary instance.
 
-### Failback
+### Zone recovery
 
-The failback behavior depends on the availability zone configuration that your instance uses.
+The zone recovery behavior depends on the availability zone configuration that your instance uses.
 
 - **Automatic and zone-redundant:** For instances that are configured to use automatic availability zone support or are manually configured to use zone redundancy, when the availability zone recovers, API Management automatically restores units in the availability zone and reroutes traffic between your units as normal.
 
@@ -294,7 +294,7 @@ This section describes what to expect when API Management instances are configur
 
 - **Traffic rerouting:** If a region goes offline, API requests are automatically routed around the failed region to the next closest gateway.
 
-### Failback
+### Region recovery
 
 When the primary region recovers, API Management automatically restores units in the region and reroutes traffic between your units.
 

articles/reliability/reliability-app-service-environment.md

@@ -114,7 +114,7 @@ To learn how to create, enable, or disable a new zone-redundant App Service Envi
 
 [!INCLUDE [Zone-down experience description](includes/app-service/reliability-zone-down-experience-include.md)]
 
-### Failback
+### Zone recovery
 
 [!INCLUDE [Failback description](includes/app-service/reliability-failback-include.md)]
 

articles/reliability/reliability-app-service.md

@@ -95,7 +95,7 @@ If you enable availability zones but specify a capacity of less than two, the pl
 
 [!INCLUDE [Zone-down experience description](includes/app-service/reliability-zone-down-experience-include.md)]
 
-### Failback
+### Zone recovery
 
 [!INCLUDE [Failback description](includes/app-service/reliability-failback-include.md)]
 

articles/reliability/reliability-application-gateway-v2.md

@@ -177,9 +177,9 @@ The following section describes what to expect when Application Gateway v2 is co
 
   - *Zonal:* When a zone is unavailable, your gateway is unavailable. If you have a secondary gateway in another availability zone, you're responsible for rerouting traffic to that secondary gateway.
 
-### Failback
+### Zone recovery
 
-The failback behavior depends on the availability zone configuration that your gateway uses:
+The zone recovery behavior depends on the availability zone configuration that your gateway uses:
 
 - *Zone-redundant:* When the affected availability zone recovers, Application Gateway automatically:
 

articles/reliability/reliability-bastion.md

@@ -7,7 +7,6 @@ ms.topic: reliability-article
 ms.custom: subject-reliability, references_regions
 ms.service: azure-bastion
 ms.date: 04/04/2025
-
 ---
 
 # Reliability in Azure Bastion
@@ -79,27 +78,27 @@ There's no additional cost to use zone redundancy for 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.
-
-   >[!IMPORTANT]
-   > You can't change the availability zone setting after you deploy your Azure Bastion resource.
+- **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.
 
-[!INCLUDE [Availability zone numbering](./includes/reliability-availability-zone-numbering-include.md)]
+    [!INCLUDE [Availability zone numbering](./includes/reliability-availability-zone-numbering-include.md)]
 
-**Migration:** 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 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.
 
 ### Normal operations
 
 This section describes what to expect when Azure Bastion resources 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.
+- **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:
+    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/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.
 
-In most scenarios, the small amount of cross-zone latency isn't significant. However, if you have unusually stringent latency requirements for your Azure Bastion workloads, you should deploy a dedicated single-zone Azure Bastion instance in the virtual machine's availability zone. 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
 
@@ -113,13 +112,9 @@ This section describes what to expect when an Azure Bastion resource is configur
 
 - **Traffic rerouting:** When you use zone redundancy, new connections use Azure Bastion instances in the surviving availability zones. Overall, Azure Bastion remains operational.
 
-### Failback
-
-When the availability zone recovers, Azure Bastion:
+### Zone recovery
 
-- Automatically restores instances in the availability zone.
-- Removes any temporary instances created in the other availability zones.
-- Reroutes traffic between your instances as normal.
+When the availability zone recovers, Azure Bastion automatically restores instances in the availability zone, and reroutes traffic between your instances as normal.
 
 ### Testing for zone failures
 
@@ -135,7 +130,7 @@ If you have a disaster recovery site in another Azure region, be sure to deploy
 
 ## Service-level agreement
 
-The service-level agreement (SLA) for Azure Bastion describes the expected availability of the service and the conditions that must be met to achieve that availability expectation. To understand those conditions, it's important that you review the [SLA for Online Services](https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services).
+[!INCLUDE [SLA description](includes/reliability-service-level-agreement-include.md)]
 
 ## Related content
 

articles/reliability/reliability-container-registry.md

@@ -6,7 +6,7 @@ author: chasedmicrosoft
 ms.topic: reliability-article
 ms.custom: subject-reliability
 ms.service: azure-container-registry
-ms.date: 07/23/2025
+ms.date: 08/22/2025
 #Customer intent: As an engineer responsible for business continuity, I want to understand the details of how Azure Container Registry works from a reliability perspective and plan disaster recovery strategies in alignment with the exact processes that Azure services follow during different kinds of situations.
 ---
 
@@ -73,14 +73,18 @@ For client applications that use Container Registry, implement appropriate retry
 
 Zone redundancy protects your container registry against single zone failures by distributing registry data and operations across multiple availability zones within the region. Container image pull and push operations continue to function during zone outages, with automatic failover to healthy zones.
 
-Zone redundancy is enabled by default for all Azure Container Registries in regions that support availability zones, making your resources more resilient automatically and at no additional cost. This enhancement applies to all SKUs including Basic and Standard and has been rolled out to both new and existing registries in supported regions.
+Zone redundancy is enabled by default for all registries in regions that support availability zones, making your resources more resilient automatically and at no additional cost. This enhancement applies to all service tiers, including Basic and Standard, and has been applied to both new and existing registries.
 
->[!IMPORTANT]
->The Azure portal and CLI may not yet reflect the zone redundancy update accurately. The `zoneRedundancy` property in your registry’s configuration might still show as false even though zone redundancy is active for all registries in supported regions. We’re actively updating the portal and API surfaces to reflect this default behavior more transparently. All previously enabled features will continue to function as expected.
+> [!IMPORTANT]
+> The Azure portal and other tooling might not yet reflect the zone redundancy update accurately.
+>
+> The `zoneRedundancy` property in your registry’s configuration might still show as `false`, but zone redundancy is active for all registries in supported regions.
+>
+> We're actively updating the portal and API surfaces to reflect this default behavior more transparently. All previously enabled features continue to function as expected.
 
 ### Region support
 
-Zone-redundant registries can only be deployed into [a region that supports availability zones](./regions-list.md).
+Zone-redundant registries can be deployed into [any region that supports availability zones](./regions-list.md).
 
 ### Considerations
 
@@ -98,7 +102,7 @@ Zone redundancy is included with container registries at no extra cost.
 
     - To migrate your artifacts between registries, you can [create a transfer pipeline](/azure/container-registry/container-registry-transfer-prerequisites). Alternatively, you can [import container images to a container registry](/azure/container-registry/container-registry-import-images).
 
-- If your registry uses [geo-replication](#multi-region-support) in a region that supports Availablity Zones. Your replica will be zone redundant by default. For more information, see [Create a zone-redundant replica in Container Registry](/azure/container-registry/zone-redundancy-replica).  After a geo-replication is created, you can only change the zone redundancy setting by deleting and recreating the replication.
+- If your registry uses [geo-replication](#multi-region-support) in a region that supports availability zones, the replica in that region will be zone-redundant automatically. For more information, see [Create a zone-redundant replica in Container Registry](/azure/container-registry/zone-redundancy-replica). After a geo-replication is created, you can only change the zone redundancy setting by deleting and recreating the replication.
 
 - **Disable zone redundancy.** Zone redundancy can't be disabled. 
 
@@ -122,7 +126,11 @@ When a zone becomes unavailable, Container Registry automatically handles the fa
 
 - **Detection and response:** The Container Registry platform automatically detects failures in an availability zone and initiates a response. The service automatically routes traffic to the remaining healthy zones. No manual intervention is required to initiate a zone failover.
 
-- **Notification:** Zone failure events can be monitored through Azure Service Health and through registry availability metrics in Azure Monitor. Set up alerts on these services to receive notifications about zone-level problems.
+- **Notification**: Azure Container Registry doesn't notify you when a zone is down. However, you can use [Azure Service Health](/azure/service-health/overview) to understand the overall health of the Azure Container Registry service, including any zone failures.
+    
+    Set up alerts 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).
+
+    You can also monitor registry availability metrics in Azure Monitor.
 
 - **Active requests:** When an availability zone is unavailable, any requests in progress that are connected to resources in the faulty availability zone are terminated. They need to be retried.
 
@@ -132,7 +140,7 @@ When a zone becomes unavailable, Container Registry automatically handles the fa
 
 - **Traffic rerouting:** The platform automatically reroutes traffic to healthy zones without requiring you to make any configuration changes.
 
-### Failback
+### Zone recovery
 
 When the affected availability zone recovers, Container Registry automatically distributes operations across all available zones, including the recovered zone. The service rebalances traffic and data distribution without requiring manual intervention or causing service disruption.
 
@@ -206,7 +214,11 @@ When a region becomes unavailable, container operations can continue to use alte
 
 - **Detection and response:** Container Registry monitors the health of each regional replica and is responsible for redirecting traffic to another region.
 
-- **Notification:** Region health can be monitored through Azure Service Health. Set up alerts to receive notifications of region-level problems. You can also monitor registry availability metrics for each regional endpoint to detect problems.
+- **Notification**: Azure Container Registry doesn't notify you when a region is down. However, you can use [Azure Service Health](/azure/service-health/overview) to understand the overall health of the Azure Container Registry service, including any region failures.
+    
+    Set up alerts to receive notifications of region-level problems. For more information, see [Create Service Health alerts in the Azure portal](/azure/service-health/alerts-activity-log-service-notifications-portal).
+
+    You can also monitor registry availability metrics for each regional endpoint in Azure Monitor.
 
 - **Active requests:** Any active requests currently in flight to an unavailable region will fail and must be retried so that they can be directed to a healthy region.
 
@@ -218,7 +230,7 @@ When a region becomes unavailable, container operations can continue to use alte
 
 - **Traffic rerouting:** When a region becomes unavailable, container operations are automatically routed to another replica in a healthy region. Clients don't need to change the endpoint in which they interact with the registry. Microsoft automatically handles routing, failover, and failback.
 
-### Failback
+### Region recovery
 
 When a region recovers, data plane operations automatically resume for that regional endpoint through Traffic Manager routing. The service synchronizes any changes that occur during the outage by using asynchronous replication with eventual consistency.