You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -4,7 +4,7 @@ description: Learn how inbound and outbound IP addresses are used in Azure App S
4
4
author: msangapu-msft
5
5
ms.author: msangapu
6
6
ms.topic: article
7
-
ms.date: 03/10/2025
7
+
ms.date: 07/16/2025
8
8
ms.update-cycle: 1095-days
9
9
ms.custom:
10
10
- UpdateFrequency3
@@ -19,42 +19,42 @@ ms.custom:
19
19
20
20
## How IP addresses work in App Service
21
21
22
-
An App Service app runs in an App Service plan, and App Service plans are deployed into one of the deployment units in the Azure infrastructure (internally called a webspace). Each deployment unit is assigned a set of virtual IP addresses, which includes one public inbound IP address and a set of [outbound IP addresses](#find-outbound-ips). All App Service plans in the same deployment unit, and app instances that run in them, share the same set of virtual IP addresses. For an App Service Environment (an App Service plan in [Isolated tier](https://azure.microsoft.com/pricing/details/app-service/)), the App Service plan is the deployment unit itself, so the virtual IP addresses are dedicated to it as a result.
22
+
An App Service app runs in an App Service plan, and App Service plans are deployed into one of the deployment units in the Azure infrastructure (internally called a webspace). Each deployment unit is assigned to a set of virtual IP addresses, which includes one public inbound IP address and a set of [outbound IP addresses](#find-outbound-ips). All App Service plans in the same deployment unit, and app instances that run in them, share the same set of virtual IP addresses. For an App Service Environment (an App Service plan in [Isolated tier](https://azure.microsoft.com/pricing/details/app-service/)), the App Service plan is the deployment unit itself, so the virtual IP addresses are dedicated to it as a result.
23
23
24
24
Because you're not allowed to move an App Service plan between deployment units, the virtual IP addresses assigned to your app usually remain the same, but there are exceptions.
25
25
26
26
> [!NOTE]
27
-
> The Premium V4 tier does not provide a stable set of outbound IP addresses. This behavior is intentional. Although applications running on the Premium V4 tier can make outbound calls to internet-facing endpoints, the App Service platform does not provide a stable set of outbound IP addresses for the Premium V4 tier. This is a change in behavior from previous App Service pricing tiers. The portal will show "Dynamic" for outbound IP addresses and additional outbound IP addresses information for applications using Premium V4. ARM and CLI calls will return empty strings for the values of *outboundIpAddresses* and *possibleOutboundIpAddresses*. If applications running on Premium V4 require a stable outbound IP address(es), developers will need to use a solution like [Azure NAT Gateway](overview-nat-gateway-integration.md) to get a predictable IP address for outbound internet-facing traffic.
27
+
> The Premium V4 tier doesn't provide a stable set of outbound IP addresses. This behavior is intentional. Although applications running on the Premium V4 tier can make outbound calls to internet-facing endpoints, the App Service platform doesn't provide a stable set of outbound IP addresses for the Premium V4 tier. This behavior is a change in behavior from previous App Service pricing tiers. The portal shows "Dynamic" for outbound IP addresses and additional outbound IP addresses information for applications using Premium V4. Azure Resource Manager (ARM) and CLI calls return empty strings for the values of *outboundIpAddresses* and *possibleOutboundIpAddresses*. If applications running on Premium V4 require a stable outbound IP address or addresses, developers need to use a solution like [Azure NAT Gateway](overview-nat-gateway-integration.md) to get a predictable IP address for outbound internet-facing traffic.
28
28
29
29
## When inbound IP changes
30
30
31
-
Regardless of the number of scaled-out instances, each app has a single inbound IP address. The inbound IP address may change when you perform one of the following actions:
31
+
Regardless of the number of scaled-out instances, each app has a single inbound IP address. The inbound IP address might change when you perform one of the following actions:
32
32
33
-
- Delete an app and recreate it in a different resource group (deployment unit may change).
34
-
- Delete the last app in a resource group _and_ region combination and recreate it (deployment unit may change).
33
+
- Delete an app and recreate it in a different resource group (deployment unit might change).
34
+
- Delete the last app in a resource group _and_ region combination and recreate it (deployment unit might change).
35
35
- Delete an existing IP-based TLS binding, such as during certificate renewal (see [Renew certificate](configure-ssl-certificate.md#renew-an-expiring-certificate)).
36
36
37
37
## Find the inbound IP
38
38
39
-
Just run the following command in a local terminal:
39
+
Run the following command in a local terminal:
40
40
41
41
```bash
42
42
nslookup <app-name>.azurewebsites.net
43
43
```
44
44
45
45
## Get a static inbound IP
46
46
47
-
Sometimes you might want a dedicated, static IP address for your app. To get a static inbound IP address, you need to [secure a custom DNS name with an IP-based certificate binding](./configure-ssl-bindings.md). If you don't actually need TLS functionality to secure your app, you can even upload a self-signed certificate for this binding. In an IP-based TLS binding, the certificate is bound to the IP address itself, so App Service creates a static IP address to make it happen.
47
+
Sometimes you might want a dedicated, static IP address for your app. To get a static inbound IP address, you need to [secure a custom DNS name with an IP-based certificate binding](./configure-ssl-bindings.md). If you don't actually need TLS functionality to secure your app, you can even upload a self-signed certificate for this binding. In an IP-based TLS binding, the certificate is bound to the IP address itself, so App Service creates a static IP address to make it happen.
48
48
49
49
## When outbound IPs change
50
50
51
51
Regardless of the number of scaled-out instances, each app has a set number of outbound IP addresses at any given time. Any outbound connection from the App Service app, such as to a back-end database, uses one of the outbound IP addresses as the origin IP address. The IP address to use is selected randomly at runtime, so your back-end service must open its firewall to all the outbound IP addresses for your app.
52
52
53
53
The set of outbound IP addresses for your app changes when you perform one of the following actions:
54
54
55
-
- Delete an app and recreate it in a different resource group (deployment unit may change).
56
-
- Delete the last app in a resource group _and_ region combination and recreate it (deployment unit may change).
57
-
- Scale your app between the lower tiers (**Basic**, **Standard**, and **Premium**), the **PremiumV2** tier, the **PremiumV3** tier, and the **Pmv3** options within the **PremiumV3** tier (IP addresses may be added to or subtracted from the set).
55
+
- Delete an app and recreate it in a different resource group (deployment unit might change).
56
+
- Delete the last app in a resource group _and_ region combination and recreate it (deployment unit might change).
57
+
- Scale your app between the lower tiers (**Basic**, **Standard**, and **Premium**), the **PremiumV2** tier, the **PremiumV3** tier, and the **Pmv3** options within the **PremiumV3** tier (IP addresses might be added to or subtracted from the set).
58
58
59
59
You can find the set of all possible outbound IP addresses your app can use, regardless of pricing tiers, by looking for the `possibleOutboundIpAddresses` property or in the **Additional Outbound IP Addresses** field in the **Properties** page in the Azure portal. See [Find outbound IPs](#find-outbound-ips).
60
60
@@ -90,13 +90,13 @@ For function apps, see [Function app outbound IP addresses](/azure/azure-functio
90
90
91
91
## Get a static outbound IP
92
92
93
-
You can control the IP address of outbound traffic from your app by using virtual network integration together with a virtual network NAT gateway to direct traffic through a static public IP address. [Virtual network integration](./overview-vnet-integration.md) is available on **Basic**, **Standard**, **Premium**, **PremiumV2**, and **PremiumV3** App Service plans. To learn more about this setup, see [NAT gateway integration](./networking/nat-gateway-integration.md).
93
+
You can control the IP address of outbound traffic from your app by using virtual network integration and a virtual network NAT gateway to direct traffic through a static public IP address. [Virtual network integration](./overview-vnet-integration.md) is available on **Basic**, **Standard**, **Premium**, **PremiumV2**, and **PremiumV3** App Service plans. To learn more about this setup, see [NAT gateway integration](./networking/nat-gateway-integration.md).
94
94
95
95
## IP Address properties in Azure portal
96
96
97
-
IP Addresses appear in multiple places in Azure portal. The properties page will show you the raw output from `inboundIpAddress`, `possibleInboundIpAddresses`, `outboundIpAddresses`, and `possibleOutboundIpAddresses`. The overview page will also show the same values, but not include the **Possible Inbound IP Addresses**.
97
+
IP Addresses appear in multiple places in Azure portal. The properties page shows you the raw output from `inboundIpAddress`, `possibleInboundIpAddresses`, `outboundIpAddresses`, and `possibleOutboundIpAddresses`. The overview page also shows the same values, but not include the **Possible Inbound IP Addresses**.
98
98
99
-
Networking overview shows the combination of **Inbound IP Address** and any private endpoint IP addresses in the **Inbound addresses** field. If public network access is disabled, the public IP address won't be shown. The **Outbound addresses** field has a combined list of **(Possible) Outbound IP Addresses**, and if the app is virtual network integrated and is routing all traffic, and the subnet has a NAT gateway attached, the field will also include the IP addresses from the NAT gateway.
99
+
Networking overview shows the combination of **Inbound IP Address** and any private endpoint IP addresses in the **Inbound addresses** field. If public network access is disabled, the public IP address isn't shown. The **Outbound addresses** field has a combined list of **(Possible) Outbound IP Addresses**, and if the app is virtual network integrated and is routing all traffic, and the subnet has a NAT gateway attached, the field also includes the IP addresses from the NAT gateway.
100
100
101
101
:::image type="content" source="./media/overview-inbound-outbound-ips/networking-overview.png" alt-text="Screenshot that shows how IP addresses are shown in the networking overview page.":::
102
102
@@ -111,6 +111,114 @@ The tag can be used to allow outbound traffic in a Network security group (NSG)
111
111
> [!NOTE]
112
112
> Service tag helps you define network access, but it shouldn't be considered as a replacement for proper network security measures as it doesn't provide granular control over individual IP addresses.
113
113
114
+
## Inbound IPv6 support (public preview)
115
+
116
+
Azure App Service supports IPv6 for inbound traffic. Apps can receive traffic over both IPv4 and IPv6 protocols, providing compatibility with modern networks and clients that require IPv6 connectivity.
117
+
118
+
> [!NOTE]
119
+
> Inbound IPv6 support is in public preview. Outbound IPv6 support is in public preview just for Windows apps. For more information on outbound IPv6 support, see [Announcing App Service Outbound IPv6 Support in Public Preview](https://techcommunity.microsoft.com/blog/appsonazureblog/announcing-app-service-outbound-ipv6-support-in-public-preview/4423368). All outbound connections from your Linux apps still use IPv4.
120
+
121
+
### Prerequisites
122
+
123
+
To use IPv6 inbound traffic, you need:
124
+
125
+
- An IPv6 address that accepts incoming traffic
126
+
- A DNS record that returns an IPv6 (AAAA) record
127
+
- A client that can send and receive IPv6 traffic
128
+
129
+
> [!IMPORTANT]
130
+
> Many local networks and development environments only support IPv4, which might affect your ability to test IPv6 connectivity from your local machine.
131
+
132
+
### How IPv6 addressing works
133
+
134
+
All App Service deployment units include IPv6 addresses, enabling your app to receive traffic on both IPv4 and IPv6 addresses. For backward compatibility, the DNS response for the default hostname (`<app-name>.azurewebsites.net`) returns only the IPv4 address by default.
135
+
136
+
You can configure the IP mode behavior using the `IPMode` property:
137
+
138
+
-**IPv4** (default): DNS returns IPv4 address only
139
+
-**IPv6**: DNS returns IPv6 address only
140
+
-**IPv4AndIPv6**: DNS returns both IPv4 and IPv6 addresses
141
+
142
+
### Configure IPv6 support
143
+
144
+
# [Azure portal](#tab/azure-portal)
145
+
146
+
To update an app to return IPv6 DNS records in the Azure portal, go to the **Configuration** page for the App Service app and set the **Inbound IP mode** property.
147
+
148
+
:::image type="content" source="./media/overview-inbound-outbound-ips/ip-mode-configuration.png" alt-text="Screenshot that shows how the inbound IP mode is set in the App Service configuration page.":::
149
+
150
+
# [Azure CLI](#tab/azure-cli)
151
+
152
+
To update an app to return IPv6 DNS records in the Azure CLI, run the following command.
Copy file name to clipboardExpand all lines: articles/app-service/overview.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -35,7 +35,7 @@ Whether you're a student, a small business, a startup, or an enterprise, App Ser
35
35
-**Command-line friendly**: Deploy using command line tools you already use, such as Maven, Gradle, Azure Developer CLI, Azure CLI, and Azure PowerShell.
36
36
-**Scalability**: Automatically scale your applications based on demand.
37
37
-**Global reach**: Deploy your apps in data centers around the world.
38
-
-**Application templates**: Choose from an extensive list of application templates in the [Azure Marketplace](https://azure.microsoft.com/marketplace/), such as WordPress, Joomla, and Drupal.
38
+
-**Application templates**: Choose from an extensive list of application templates in the [Azure Marketplace](https://azure.microsoft.com/marketplace/), such as WordPress, Joomla, Django , Node.js and Drupal.
39
39
-**Social sign-in support**: Turn-key social sign-in with [Google](configure-authentication-provider-google.md), [Facebook](configure-authentication-provider-facebook.md), [X](configure-authentication-provider-twitter.md), and [Microsoft accounts](configure-authentication-provider-microsoft.md).
40
40
41
41
### Enterprises
@@ -51,4 +51,4 @@ For information about which Azure compute services best fit your scenario, see [
51
51
52
52
## Next Steps
53
53
54
-
-[Getting started with Azure App Service](getting-started.md)
54
+
-[Getting started with Azure App Service](getting-started.md)
# Customer intent: As a cloud administrator, I want to connect multiple Azure VMware Solution Generation 2 private clouds using Virtual Network peering, so that I can ensure efficient communication and optimize performance across my cloud infrastructure.
In this article, you learn how to connect a Azure VMware Solution Generation 2 (Gen 2) private cloud to other Gen 2 private clouds.
16
+
In this article, you learn how to connect an Azure VMware Solution Generation 2 (Gen 2) private cloud to other Gen 2 private clouds.
17
17
18
18
## Prerequisite
19
19
20
20
Have multiple Azure VMware Solution Gen 2 private clouds deployed successfully.
21
21
22
-
## Connect multiple Azure VMware Solution Gen 2
22
+
## Use Virtual Network peering to connect multiple private clouds
23
23
24
-
Private clouds deployed in different Azure Virtual Networks can be connected using Virtual Network peering. The Virtual Network peering provides the best possible throughput and latency between Azure VMware Solution private clouds in the same region. For more information about how to do Azure Virtual Network peering, see [Create, change, or delete a Virtual Network peering](/azure/virtual-network/virtual-network-peering-overview).
24
+
You can connect private clouds deployed in different Azure Virtual Networks using virtual network peering. The virtual network peering provides the best possible throughput and latency between Azure VMware Solution private clouds in the same region. For more information about how to do Azure Virtual Network peering, see [Create, change, or delete a Virtual Network peering](/azure/virtual-network/virtual-network-peering-overview).
25
25
26
26
Depending on the location of the private cloud, you may require local Virtual Network peering or a global Virtual Network peering.
27
27
28
-
:::image type="content" source="./media/native-connectivity/native-connect-multiple-solutions-on-premises.png" alt-text="Diagram of an multiple Azure VMware Solution Gen 2 private clouds connected together." lightbox="media/native-connectivity/native-connect-multiple-solutions-on-premises.png":::
28
+
:::image type="content" source="./media/native-connectivity/native-connect-multiple-solutions-on-premises.png" alt-text="Diagram of multiple Azure VMware Solution Gen 2 private clouds connected together." lightbox="media/native-connectivity/native-connect-multiple-solutions-on-premises.png":::
29
29
30
30
## Related topics
31
31
-[Connectivity to an Azure Virtual Network](native-network-connectivity.md)
0 commit comments