Changes in outbound connection guide

Author: dennispadia

articles/sap/workloads/high-availability-guide-standard-load-balancer-outbound-connections.md

@@ -14,58 +14,80 @@ ms.custom: sfi-image-nochange
 # Customer intent: As a system administrator managing SAP high-availability solutions, I want to configure outbound connectivity options for Azure VMs without exposing them to public endpoints, so that I can ensure compliance with security requirements while maintaining necessary Azure service accessibility.
 ---
 
-# Public endpoint connectivity for Virtual Machines using Azure Standard Load Balancer in SAP high-availability scenarios
+# Outbound connectivity for standalone SAP VMs and SAP VMs behind Azure Standard Load Balancer
 
-The scope of this article is to describe configurations that enable outbound connectivity to public end points. The configurations are mainly in the context of high availability with Pacemaker for SUSE / RHEL.
+> [!IMPORTANT]
+> For new virtual networks created after March 31, 2026, Azure defaults subnets to private, which disables default outbound access. Any VM that must reach public internet or public Microsoft endpoints now needs an explicit outbound method. Existing virtual networks are not changed automatically.
 
-If you're using Pacemaker with Azure fence agent in your high availability solution, then the virtual machines (VMs) must have outbound connectivity to the Azure management API. The article presents several options to enable you to select the option that's best suited for your scenario.
+This document outline different options to configure explicit outbound internet connectivity to reach internet or public endpoint for Azure VMs running SAP workloads. It covers both standalone VMs and VMs placed behind an internal Azure Standard Load Balancer.
 
 ## Overview
 
-When you implement high availability for SAP solutions via clustering, one of the necessary components is [Azure Load Balancer](../../load-balancer/load-balancer-overview.md). Azure offers two load balancer SKUs: Standard and Basic.
+SAP systems deployment on Azure require outbound connectivity to reach internet or public endpoints even when the VMs themselves are not publicly reachable. Common examples include:
 
-Standard Azure load balancer offers some advantages over the Basic load balancer. For instance, Standard works across Azure Availability zones, has better monitoring and logging capabilities for easier troubleshooting, and reduced latency. The "high availability ports" feature covers all ports, making it no longer necessary to list all individual ports.
+- Azure fence agent, requires access to `management.azure.com` and `login.microsoftonline.com` for STONITH operations in pacemaker clusters.
+- [Azure Backup](../../backup/backup-azure-sap-hana-database.md#establish-network-connectivity)
+- [Azure Site Recovery](../../site-recovery/azure-to-azure-about-networking.md#outbound-connectivity-for-urls)
+- Using package repositories for patching the operating system.
+- SAP application data flow may require outbound connectivity to external APIs or partner systems.
 
-There are some important differences between the Basic and the Standard SKU of Azure load balancer. One of them is the handling of outbound traffic to public end point. For full Basic versus Standard SKU load balancer comparison, see [Load Balancer SKU comparison](../../load-balancer/load-balancer-overview.md).
+When VMs are placed in the backend pool of an internal Standard load balancer, there is no outbound connectivity by default. This was always true for Standard SKU load balancers. The March 31, 2026 change extends this principle to all new virtual network, even for standalone VMs without any load balancer.
 
-When VMs without public IP addresses are placed in the backend pool of internal (no public IP address) Standard Azure load balancer, there's no outbound connectivity to public end points, unless extra configuration is performed.
+> [!NOTE]
+> When VMs without public IP addresses are added to the back-end pool of an internal Standard Azure Load Balancer, they lack outbound internet connectivity. Further configuration is needed to enable routing to public endpoints.
+> VMs that have public IP addresses, or that are included in an Azure Load Balancer backend pool with a public IP, already have outbound access to public endpoints.
 
-A VM can establish outbound connectivity to public endpoints if a public IP address is assigned. The same applies when the VM is included in the backend pool of a load balancer with a public IP.
+## Outbound connectivity options
 
-SAP systems often contain sensitive business data. It's rarely acceptable for VMs hosting SAP systems to be accessible via public IP addresses. At the same time, there are scenarios, which would require outbound connectivity from the VM to public end points.
+There are dfiferent ways to configure explicit outbound connectivity for VMs, as illustrated in the flowchart at [How and when default outbound access is provided](../../virtual-network/ip-services/default-outbound-access.md?tabs=portal#how-and-when-default-outbound-access-is-provided). Before selecting an approach, review the capabilities, constraints, and supporting documentation for each option to determine the best fit for your SAP environment, security requirements, and operational model.
 
-Examples of scenarios, requiring access to Azure public end point are:
+# [NAT Gateway](#tab/nat-gateway)
 
-- Azure Fence Agent requires access to **management.azure.com** and **login.microsoftonline.com**
-- [Azure Backup](../../backup/backup-azure-sap-hana-database.md#establish-network-connectivity)
-- [Azure Site Recovery](../../site-recovery/azure-to-azure-about-networking.md#outbound-connectivity-for-urls)
-- Using public repository for patching the operating system
-- The SAP application data flow may require outbound connectivity to public end point
+- [What is Azure NAT Gateway?](../../nat-gateway/nat-overview.md) - Overview of Azure NAT Gateway, its architecture, and key benefits for outbound connectivity.
+- [Tutorial: Create a NAT gateway using the Azure portal](../../nat-gateway/quickstart-create-nat-gateway-v2.md) - Instructions for creating and configuring a NAT gateway resource.
+- [Design virtual networks with NAT gateway](../../nat-gateway/nat-gateway-design.md) - Guidance on planning and designing NAT gateway deployments within your virtual network.
 
-If your SAP deployment doesn’t require outbound connectivity to public end points, you don’t need to implement extra configuration. It's sufficient to create internal standard SKU Azure Load Balancer for your high availability scenario, assuming that there's also no need for inbound connectivity from public end points.
+# [Azure Standard Load Balancer](#tab/azure-standard-lb)
 
-> [!NOTE]
-> When VMs without public IP addresses are added to the back-end pool of an internal Standard Azure Load Balancer, they lack outbound internet connectivity. Further configuration is needed to enable routing to public endpoints.
-> VMs that have public IP addresses, or that are included in an Azure Load Balancer backend pool with a public IP, already have outbound access to public endpoints.
+- [Azure Standard Load Balancer overview](../../load-balancer/load-balancer-overview.md) - Comprehensive overview of Azure Standard Load Balancer, important principles, concepts, and tutorials.
+- [Outbound connections in Azure](../../load-balancer/load-balancer-outbound-connections.md#scenarios) - Scenarios for achieving outbound connectivity in Azure.
+- [Load balancer outbound rules](../../load-balancer/load-balancer-outbound-connections.md#outboundrules) - Concepts of load balancer outbound rules and how to create them for explicit SNAT configuration.
 
-## Prerequisites
+# [Azure Firewall](#tab/azure-firewall)
 
-**Azure Standard Load Balancer**:
+- [What is Azure Firewall?](../../firewall/overview.md) - Overview of Azure Firewall, a cloud-native network security service.
+- [Tutorial: Deploy and configure Azure Firewall using the Azure portal](../../firewall/tutorial-firewall-deploy-portal.md) - Step-by-step instructions for deploying Azure Firewall.
+- [Virtual network traffic routing - User-defined routes](../../virtual-network/virtual-networks-udr-overview.md#user-defined) - How to configure custom routing to direct traffic through a virtual appliance.
+- [Network security groups - Service tags](../../virtual-network/network-security-groups-overview.md#service-tags) - Simplify NSG and firewall rule configuration using service tags.
 
-* [Azure Standard Load Balancer overview](../../load-balancer/load-balancer-overview.md) - Comprehensive overview of Azure Standard Load balancer, important principles, concepts, and tutorials.
-* [Outbound connections in Azure](../../load-balancer/load-balancer-outbound-connections.md#scenarios) - Scenarios on how to achieve outbound connectivity in Azure.
-* [Load balancer outbound rules](../../load-balancer/load-balancer-outbound-connections.md#outboundrules)- Explains the concepts of load balancer outbound rules and how to create outbound rules.
+# [Proxy Server](#tab/proxy-server)
 
-**Azure Firewall**:
+- There are many different proxy options available in the industry. Understand how the proxy is configured in your environment.
 
-* [Azure Firewall Overview](../../firewall/overview.md)- overview of Azure Firewall.
-* [Tutorial: Deploy and configure Azure Firewall](../../firewall/tutorial-firewall-deploy-portal.md) - instructions on how to configure Azure Firewall via Azure portal.
-* [Virtual Networks - User defined rules](../../virtual-network/virtual-networks-udr-overview.md#user-defined) - Azure routing concepts and rules.
-* [Security Groups Service Tags](../../virtual-network/network-security-groups-overview.md#service-tags) - how to simplify your Network Security Groups (NSG) and Firewall configuration with service tags.
+---
 
 ## Achieve outbound connectivity to public end points
 
-# [Option 1](#tab/option-1)
+# [NAT Gateway](#tab/nat-gateway)
+
+Azure NAT Gateway is a fully managed, highly resilient Network Address Translation (NAT) service that provides outbound connectivity for VMs in a subnet. NAT Gateway is configured at the subnet level — once associated with a subnet, it becomes the preferred outbound connectivity method for all resources in that subnet. NAT Gateway takes precedence over other outbound configurations, including load balancer outbound rules and instance-level public IP addresses.
+
+To achieve outbound connectivity to public end points, without allowing inbound connectivity to the VM from a public end point, associate an Azure NAT Gateway with the subnet where the SAP VMs and Standard Load Balancer are deployed. Use [Network Security Groups](../../virtual-network/network-security-groups-overview.md) to control the public end points that are accessible for outbound calls from the VMs.
+
+## Important considerations
+
+- Azure NAT Gateway is a fully managed service with built-in high availability and supports [zonal and zone-redundant deployments](../../nat-gateway/nat-availability-zones.md). No dditional infrastructure or routing configuration is required. Review the key [limitation of Standard v2 Azure NAT Gateway (zone-redundant)](../../nat-gateway/nat-overview.md#key-limitations-of-standardv2-nat-gateway) to ensure that it supports your configuration.
+- NAT Gateway is configured at the subnet level. All VMs in the associated subnet automatically use the NAT Gateway for outbound connectivity. No per-VM configuration is needed.
+- When a NAT Gateway is associated with a subnet, it takes precedence over other explicit outbound methods, including load balancer outbound rules and instance-level public IP addresses for new connections.
+
+## Deployment steps
+
+For step-by-step instructions on creating and configuring an Azure NAT Gateway, see:
+
+- [Quickstart: Create a NAT gateway using the Azure portal](../../nat-gateway/quickstart-create-nat-gateway-portal-v2.md) - Instructions on how to create a NAT gateway resource and associate it with a subnet.
+- [Manage a NAT gateway](../../nat-gateway/manage-nat-gateway-v2.md) - How to add or remove public IP addresses and subnets from an existing NAT Gateway.
+
+# [Azure Standard Load Balancer](#tab/azure-standard-lb)
 
 Create another external Azure Standard Load Balancer for outbound connections to internet.
 
@@ -75,7 +97,7 @@ The configuration would look like:
 
 ![A diagram of control connectivity to public end points with Network Security Groups.](./media/high-availability-guide-standard-load-balancer/high-availability-guide-standard-load-balancer-public.png)
 
-### Important considerations
+## Important considerations
 
 - You can use one extra Public Load Balancer for multiple VMs in the same subnet to achieve outbound connectivity to public end point and optimize cost.
 - Use [Network Security Groups](../../virtual-network/network-security-groups-overview.md) to control which public end points are accessible from the VMs. You can assign the Network Security Group either to the subnet, or to each VM. Where possible, use [Service tags](../../virtual-network/network-security-groups-overview.md#service-tags) to reduce the complexity of the security rules.
@@ -84,7 +106,7 @@ The configuration would look like:
 > [!TIP]
 > Where possible, use [Service tags](../../virtual-network/network-security-groups-overview.md#service-tags) to reduce the complexity of NSG.
 
-### Deployment steps
+## Deployment steps
 
 Create the Load Balancer.
 
@@ -117,7 +139,7 @@ Create the Load Balancer.
 
    For more information on Azure NSG, see [Security Groups](../../virtual-network/network-security-groups-overview.md).
 
-# [Option 2](#tab/option-2)
+# [Azure Firewall](#tab/azure-firewall)
 
 Another option to achieve outbound connectivity to public end points, without allowing inbound connectivity to the VM from public end points, is with Azure Firewall. Azure Firewall is a managed service, with built-in High Availability and it can span multiple Availability Zones.
 
@@ -127,7 +149,7 @@ The architecture would look like:
 
 ![A diagram of an outbound network connection passing through an Azure Firewall.](./media/high-availability-guide-standard-load-balancer/high-availability-guide-standard-load-balancer-firewall.png)
 
-### Important considerations
+## Important considerations
 
 - Azure firewall is cloud native service, with built-in High Availability and it supports zonal deployment.
 - Requires an extra subnet that must be named AzureFirewallSubnet.
@@ -137,7 +159,7 @@ The architecture would look like:
 > [!TIP]
 > Where possible, use [Service tags](../../virtual-network/network-security-groups-overview.md#service-tags) to reduce the complexity of the Azure Firewall rules.
 
-### Deployment steps
+## Deployment steps
 
 The deployment steps assume that you already have your virtual network and subnet defined for your VMs.
 
@@ -185,11 +207,11 @@ Create User Defined Route from the subnet of your VMs to the private IP of **MyA
 1. Next hop address: Enter the private IP address of the firewall you configured: **11.97.1.4**.
 1. Save your information.
 
-# [Option 3](#tab/option-3)
+# [Proxy Server](#tab/proxy-server)
 
 You could use proxy to allow Pacemaker calls to the Azure management API public end point.
 
-### Important considerations
+## Important considerations
 
 - If there's already corporate proxy in place, you could route outbound calls to public end points through it. Outbound calls to public end points go through the corporate control point.
 - Make sure the proxy configuration allows outbound connectivity to Azure management API: `https://management.azure.com` and `https://login.microsoftonline.com`.
@@ -199,15 +221,15 @@ You could use proxy to allow Pacemaker calls to the Azure management API public
 - Depending on the location of the proxy, it may introduce extra latency in the calls from the Azure Fence Agent to the Azure Management API. If your corporate proxy is still on the premises, while your Pacemaker cluster is in Azure, measure latency and consider, if this solution is suitable for you.
 - If there isn’t already highly available corporate proxy in place, we don't recommend this option as the customer would be incurring extra cost and complexity. If you decide to deploy extra proxy solution, to allow outbound connectivity from Pacemaker to Azure Management public API, you need to make sure the proxy is highly available. The latency from the VMs to the proxy is low.
 
-### Pacemaker configuration with Proxy
+## Pacemaker configuration with Proxy
 
 There are many different Proxy options available in the industry. Step-by-step instructions for the proxy deployment are outside of the scope of this document. In the following example, we assume that your proxy is responding to **MyProxyService** and listening to port **MyProxyPort**.
 
 To allow pacemaker to communicate with the Azure management API, perform the following steps on all cluster nodes:
 
 1. Edit the pacemaker configuration file `/etc/sysconfig/pacemaker` and add the following lines (all cluster nodes):
 
-   ```
+   ```bash
    sudo vi /etc/sysconfig/pacemaker
    # Add the following lines
    http_proxy=http://MyProxyService:MyProxyPort
@@ -218,7 +240,7 @@ To allow pacemaker to communicate with the Azure management API, perform the fol
 
    **SUSE**:
 
-   ```
+   ```bash
    # Place the cluster in maintenance mode
    sudo crm configure property maintenance-mode=true
 
@@ -231,7 +253,7 @@ To allow pacemaker to communicate with the Azure management API, perform the fol
 
    **Red Hat**:
 
-   ```
+   ```bash
    # Place the cluster in maintenance mode
    sudo pcs property set maintenance-mode=true