Inbound and outbound IP addresses in Azure App Service

Azure App Service is a multitenant service, except for App Service Environments. Apps that aren't in an App Service environment (not in the Isolated tier) share network infrastructure with other apps. As a result, the inbound and outbound IP addresses of an app can be different, and can even change in certain situations.

App Service Environments use dedicated network infrastructures, so apps running in an App Service environment get static, dedicated IP addresses both for inbound and outbound connections.

How IP addresses work in App Service

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. 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), the App Service plan is the deployment unit itself, so the virtual IP addresses are dedicated to it as a result.

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.

When inbound IP changes

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:

• Delete an app and recreate it in a different resource group (deployment unit might change).
• Delete the last app in a resource group and region combination and recreate it (deployment unit might change).
• Delete an existing IP-based TLS binding, such as during certificate renewal (see Renew certificate).

Find the inbound IP

Run the following command in a local terminal:

nslookup <app-name>.azurewebsites.net

Get a static inbound IP

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

When outbound IPs change

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.

The set of outbound IP addresses for your app changes when you perform one of the following actions:

• Delete an app and recreate it in a different resource group (deployment unit might change).
• Delete the last app in a resource group and region combination and recreate it (deployment unit might change).
• 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).

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.

The set of all possible outbound IP addresses can increase over time if App Service adds new pricing tiers or options to existing App Service deployments. For example, if App Service adds the PremiumV3 tier to an existing App Service deployment, then the set of all possible outbound IP addresses increases. Similarly, if App Service adds new Pmv3 options to a deployment that already supports the PremiumV3 tier, then the set of all possible outbound IP addresses increases. Adding IP addresses to a deployment has no immediate effect since the outbound IP addresses for running applications don't change when a new pricing tier or option is added to an App Service deployment. However, if applications switch to a new pricing tier or option that wasn't previously available, then new outbound addresses are used and customers need to update downstream firewall rules and IP address restrictions.

Find outbound IPs

To find the outbound IP addresses currently used by your app in the Azure portal, select Properties in your app's left-hand navigation. They're listed in the Outbound IP Addresses field.

You can find the same information by running the following command in the Cloud Shell.

az webapp show --resource-group <group_name> --name <app_name> --query outboundIpAddresses --output tsv

(Get-AzWebApp -ResourceGroup <group_name> -name <app_name>).OutboundIpAddresses

To find all possible outbound IP addresses for your app, regardless of pricing tiers, select Properties in your app's left-hand navigation. They're listed in the Additional Outbound IP Addresses field.

You can find the same information by running the following command in the Cloud Shell.

az webapp show --resource-group <group_name> --name <app_name> --query possibleOutboundIpAddresses --output tsv

(Get-AzWebApp -ResourceGroup <group_name> -name <app_name>).PossibleOutboundIpAddresses

For function apps, see Function app outbound IP addresses.

Get a static outbound IP

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 is available on Basic, Standard, Premium, PremiumV2, and PremiumV3 App Service plans. To learn more about this setup, see NAT gateway integration.

IP Address properties in Azure portal

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.

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.

Service tag

By using the AppService service tag, you can define network access for the Azure App Service service without specifying individual IP addresses. The service tag is a group of IP address prefixes that you use to minimize the complexity of creating security rules. When you use service tags, Azure automatically updates the IP addresses as they change for the service. However, the service tag isn't a security control mechanism. The service tag is merely a list of IP addresses.

The AppService service tag includes only the inbound IP addresses of multitenant apps. Inbound IP addresses from apps deployed in isolated (App Service Environment) and apps using IP-based TLS bindings aren't included. Further all outbound IP addresses used in both multitenant and isolated aren't included in the tag.

The tag can be used to allow outbound traffic in a Network security group (NSG) to apps. If the app is using IP-based TLS or the app is deployed in isolated mode, you must use the dedicated IP address instead. As the tag only includes inbound IP addresses, the tag can't be used in access restrictions to limit access to an app from other apps in App Service.

Inbound IPv6 support

Azure App Service supports IPv6 for inbound traffic on all Basic, Standard, and Premium SKUs, as well as Functions Consumption, Functions Elastic Premium, and Logic Apps Standard plans. Apps can receive traffic over both IPv4 and IPv6 protocols, providing compatibility with modern networks and clients that require IPv6 connectivity.

Prerequisites

To use IPv6 inbound traffic, you need:

• An IPv6 address that accepts incoming traffic
• A DNS record that returns an IPv6 (AAAA) record
• A client that can send and receive IPv6 traffic

How IPv6 addressing works

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.

You can configure the IP mode behavior using the IPMode property:

• IPv4 (default): DNS returns IPv4 address only
• IPv6: DNS returns IPv6 address only
• IPv4AndIPv6: DNS returns both IPv4 and IPv6 addresses

IPMode is a DNS-only feature. Every App Service site can receive requests via both IPv4 and IPv6 endpoints—regardless of the configured IpMode. IpMode only influences how DNS resolves the endpoint, so it affects clients that rely on DNS resolution (which should be most clients), but it doesn't restrict which protocol endpoints can be reached.

Configure IPv6 support

# Configure IPv6 only
az resource update --name <app-name> --set properties.ipMode="IPv6" -g <resource-group-name> --resource-type "Microsoft.Web/sites"

# To update a slot, you need to provide the resource ID of the slot
az resource update --ids '/subscriptions/<sub-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Web/sites/<app-name>/slots/<slot-name>' --set properties.ipMode='IPv6'

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "variables": {
      "appName": "APP-SERVICE-NAME",
      "appIPMode": "IPv6",
      "appServicePlanName": "PLAN-NAME",
      "location": "[resourceGroup().location]"
  },
  "resources": [
    {
        "name": "[variables('appName')]",
        "type": "Microsoft.Web/sites",
        "apiVersion": "2021-03-01",
        "location": "[variables('location')]",
        "dependsOn": [
            "[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]"
        ],
        "properties": {
          "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]",
          "httpsOnly": true,
          "ipMode": "[variables('appIPMode')]"
        }
    }
  ]
}

Test IPv6 connectivity

To test IPv6 connectivity to your app, use the following curl command:

curl -6 https://<app-name>.azurewebsites.net

Custom domains and IPv6

When using custom domains, you can configure DNS records to support IPv6:

• IPv6 only: Add an AAAA record pointing to your app's IPv6 address. Clients must support IPv6.
• Dual-stack: Add both A (IPv4) and AAAA (IPv6) records, or use a CNAME record to the default hostname, which inherits the IPMode behavior.

Next steps

• Learn how to restrict inbound traffic by source IP addresses.
• Learn more about service tags.