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
Copy file name to clipboardExpand all lines: articles/app-service/overview-inbound-outbound-ips.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
@@ -46,9 +46,9 @@ Run the following command in a local terminal:
46
46
nslookup <app-name>.azurewebsites.net
47
47
```
48
48
49
-
## Get a static inbound IP
49
+
## Get a dedicated inbound IP
50
50
51
-
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.
51
+
Sometimes you might want a dedicated, static IP address for your app. The default shared inbound IP address is static, but this configuration allows a dedicated inbound IP address unique to your site. To get a dedicated 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.
Copy file name to clipboardExpand all lines: articles/azure-vmware/native-auto-peering-sync.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,6 +37,7 @@ Ensures that virtual machines hosted in Azure VMware Solution can securely and c
37
37
## Prerequisite
38
38
39
39
- Ensure the "Microsoft.BareMetal" resource provider is registered.
40
+
- When updating an Automated Peering Sync setting, the user needs [Role Based Access Control Administrator](/role-based-access-control/built-in-roles/privileged.md) access on the remote virtual network.
Copy file name to clipboardExpand all lines: articles/azure-vmware/native-dns-forward-lookup-zone.md
+25-4Lines changed: 25 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,10 +26,31 @@ Azure VMware Solution allows you to configure DNS forward lookup zones in two wa
26
26
27
27
If you need these names to be resolvable outside of the Virtual Network (for example, in an on-premises environment), you must configure either an **Azure DNS Private Resolver** or deploy your own DNS server within the same Virtual Network as your Azure VMware Solution private cloud. The DNS server must then use the **Azure DNS service (168.63.129.16)** as a forwarder to resolve the private cloud FQDNs.
28
28
29
-
DNS forward lookup zone can be configured at the time of creation or changed after the private cloud is created. The following diagram shows the configuration page for the DNS forward lookup zone.
29
+
DNS forward lookup zone can be configured at the time of creation or changed after the private cloud is created. The following diagram shows the configuration page for the DNS forward lookup zone.
30
30
31
31
:::image type="content" source="./media/native-connectivity/native-connect-dns-lookup.png" alt-text="Diagram showing an Azure VMware Solution Gen 2 DNS forward lookup." lightbox="media/native-connectivity/native-connect-dns-lookup.png":::
32
32
33
+
## Using Public DNS Resolution with Azure VMware Solution Gen 2
34
+
35
+
Azure VMware Solution Gen 2 allows you to use public Domain Name System (DNS) resolution for fully qualified domain names such as the VMware vCenter Server or NSX Manager public endpoints. Public DNS resolution enables you to resolve these names to their corresponding public IP addresses.
36
+
37
+
### How Public DNS Resolution Works
38
+
39
+
Public DNS records resolve successfully from any location with internet access, including:
40
+
- Virtual machines inside the private cloud
41
+
- On-premises networks
42
+
- External networks
43
+
44
+
If you are testing name resolution from a workload segment inside Azure VMware Solution, ensure that internet access is enabled for that segment. Without outbound internet access, DNS resolution to public DNS servers will not succeed.
45
+
46
+
### Verifying DNS Resolution
47
+
48
+
To verify that public DNS resolution is working:
49
+
1. Open a terminal or command prompt from any machine with internet access.
50
+
2. Run the following command:"nslookup vc123.eastus.avs.azure.com".
51
+
52
+
If DNS resolution is successful, the command returns a public IP address. If the command does not return an IP address, then either the DNS zone is private or the DNS server being used cannot reach the internet.
53
+
33
54
## Configure private DNS for your Azure VMware Solution Generation 2 private cloud
34
55
35
56
If you select the Private DNS option, the private cloud will be resolvable from the Virtual Network where the private cloud is provisioned. This is done by linking the private DNS zone to your Virtual Network. If you need to enable this zone to be resolvable outside of this Virtual Network, such as in your on-premises environment, you need to configure an Azure DNS Private Resolver, or deploy your own DNS server in your Virtual Network. Private DNS will use the Azure DNS Service (168.63.129.16) to resolve your private cloud FQDNs. This section explains configuring an Azure DNS Private Resolver.
@@ -79,17 +100,17 @@ After deploying the Azure DNS Private Resolver, you must create a forward lookup
79
100
80
101
To configure the forward lookup zone:
81
102
82
-
1.**Identify the DNS zone name** for your private cloud. The zone is typically derived from the Fully Qualified Domain Name (FQDN) of the vCenter Server. For example, if the vCenter Server URL is `https://vc123.avs.contoso.com`, the DNS zone name is `avs.contoso.com` (everything after `vc123`).
103
+
1.**Identify the DNS zone name** for your private cloud. The zone is typically derived from the Fully Qualified Domain Name (FQDN) of the vCenter Server. For example, if the vCenter Server URL is `https://vc123.avs.com`, the DNS zone name is `avs.com` (everything after `vc123`).
83
104
84
105
2.**Create a forward lookup zone** in your DNS solution (either your on-premises DNS server or a DNS server you deployed in the Azure Virtual Network of the private cloud). Use the DNS zone name identified above.
85
106
86
107
3.**Configure a forwarder** in that lookup zone. Point the zone to the IP address of the inbound endpoint of the Azure DNS Private Resolver that you deployed in the Virtual Network of the private cloud. This ensures that any DNS queries for private cloud FQDNs are forwarded to the Azure DNS Private Resolver.
87
108
88
109
**Example**:
89
110
90
-
vCenter Server URL: `https://vc123.avs.contoso.com`
111
+
vCenter Server URL: `https://vc123.avs.com`
91
112
92
-
Forward lookup zone to create: `avs.contoso.com`
113
+
Forward lookup zone to create: `avs.com`
93
114
94
115
Forwarder target: IP address of your Azure DNS Private Resolver inbound endpoint
Copy file name to clipboardExpand all lines: articles/azure-vmware/native-introduction.md
+5-4Lines changed: 5 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ ms.author: jacobjaygbay
13
13
---
14
14
# Introduction to Azure VMware Solution Generation 2 Private Clouds
15
15
16
-
Azure VMware Solution Generation 2 (Gen 2) private clouds can now be deployed inside an Azure Virtual Network, conforming Azure VMware Solution to Azure networking standards. This architecture simplifies networking architecture, enhances data transfer speeds, reduces latency for workloads, and improves performance when accessing other Azure services. Users can now deploy Azure VMware Solution private clouds with the AV64 SKU directly, eliminating the need for a minimum of 3-host AV36, AV36P, AV48, or AV52 seed cluster. A minimum 3-host AV64 cluster is still required. The same Azure VMware Solution limits apply as described in [Scale clusters in a Private Cloud](tutorial-scale-private-cloud.md).
16
+
Azure VMware Solution Generation 2 (Gen 2) private clouds can now be deployed inside an Azure Virtual Network, conforming Azure VMware Solution to Azure networking standards. This architecture simplifies networking architecture, enhances data transfer speeds, reduces latency for workloads, and improves performance when accessing other Azure services. Users can now deploy Azure VMware Solution private clouds with the AV64 SKU directly. The same Azure VMware Solution limits apply as described in [Scale clusters in a Private Cloud](tutorial-scale-private-cloud.md).
17
17
18
18
:::image type="content" source="./media/native-connectivity/azure-virtual-network-connectivity.png" alt-text="Diagram showing an Azure VMware Solution Gen 2 Virtual Network connectivity." lightbox="media/native-connectivity/azure-virtual-network-connectivity.png":::
19
19
@@ -54,17 +54,18 @@ Gen 2 private clouds are supported on the following SKU type:
54
54
55
55
Gen 2 is available in the following Azure public regions.
56
56
57
+
- Australia East
57
58
- East US
58
59
- Canada Central
59
60
- Canada East
61
+
- Central US
60
62
- North Europe
61
63
- Norway East
62
-
64
+
- Switzerland North
63
65
- UK West
64
-
65
66
- West US 2
66
67
67
-
Beyond these regions, SLAs are region specific. Contact your Microsoft account team or Microsoft Support to confirm coverage.
68
+
There may other regions that have Gen 2 available. Contact your Microsoft account team or Microsoft Support to confirm coverage in other regions.
Copy file name to clipboardExpand all lines: articles/azure-vmware/native-network-design-consideration.md
+23-9Lines changed: 23 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,36 +15,50 @@ ms.custom:
15
15
This article outlines key design considerations for Azure VMware Solution Generation 2 (Gen 2) private clouds. It explains the capabilities this generation brings to VMware-based private cloud environments, enabling access for your applications from both on-premises infrastructure and Azure-based resources. There are several considerations to review before you set up your Azure VMware Solution Gen 2 private cloud. This article provides solutions for use cases that you might encounter when you're using the private cloud type.
16
16
17
17
> [!Note]
18
-
> Generation 2 is available in specific Azure public regions. SLAs are region specific. Contact your Microsoft account team or Microsoft Support to confirm coverage.
18
+
> Generation 2 is available in specific Azure public regions. Contact your Microsoft account team or Microsoft Support to confirm coverage.
19
19
20
20
## Limitations
21
21
22
22
The following functionality is limited during this time. These limitations will be lifted in the future:
23
23
24
24
1. You cannot delete your **Resource Group**, which contains your private cloud. You must delete the private cloud first before deleting the resource group.
25
25
2. You can only deploy **1 private cloud per Azure virtual network**.
26
-
3. You can only create **1 private cloud per Resource Group**. Multiple private clouds in a single Resource Group are not supported.
26
+
1. You can only create **1 private cloud per Resource Group**. Multiple private clouds in a single Resource Group are not supported.
27
+
27
28
4. Your private cloud and virtual network for your private cloud must be in the ***same*** Resource Group.
28
29
5. You cannot ***move*** your private cloud from one Resource Group to another after the private cloud is created.
29
30
6. You cannot ***move*** your private cloud from one tenant to another after the private cloud is created.
30
-
7.**Service Endpoints** direct connectivity from Azure VMware Solution workloads isn't supported.
31
-
8. Only host-level mounts of Azure NetApp Files are supported. **Mounting directly from Azure VMware Solution virtual machines** is not supported.
31
+
1.**Service Endpoints** direct connectivity from Azure VMware Solution workloads isn't supported.
32
32
9.**vCloud Director** using Private Endpoints is supported. However, vCloud Director using Public Endpoints isn't supported.
33
33
10.**vSAN Stretched Clusters** isn't supported.
34
34
11.**Public IP down to the VMware NSX Microsoft Edge** for configuring internet will not be supported. You can find what internet options are supported in [Internet connectivity options](native-internet-connectivity-design-considerations.md).
35
35
12. During **unplanned maintenance** – like a host hardware failure – on any of the first four hosts in your SDDC, you may experience a temporary North-South network connectivity disruption for some workloads, lasting up to 30 seconds. North-South connectivity refers to traffic between your AVS VMware workloads and external endpoints beyond the NSX-T Tier-0 (T0) Edge—such as Azure services or on-premises environments.
36
36
13.**Network Security Groups** associated with the private cloud host virtual network must be created in the ***same*** resource group as the private cloud and its virtual network.
37
-
14.**Cross-resource group references** from customer virtual networks to the Azure VMware Solution virtual network are not supported by default. This includes resource types such as: User-defined routes (UDRs), DDoS Protection Plans, and other linked networking resources. If a customer virtual network is associated with one of these references that resides in a different resource group than the Azure VMware Solution virtual network, network programming (such as NSX segment propagation) may fail. To avoid issues, customers must ensure that the Azure VMware Solution virtual network isn't linked to resources in a different resource group and detach such resources (for example, DDoS Protection Plans) from the virtual network before proceeding.
38
-
- To maintain your cross-resource group reference, create a role assignment from your cross-resource group and give the “AzS VIS Prod App” the "AVS on Fleet VIS Role". The role assignment allows you to use reference and have your reference correctly applied for your Azure VMware Solution private cloud.
37
+
14.**Cross-resource group and cross-subscription references** from customer virtual networks to the Azure VMware Solution virtual network are not supported by default. This includes resource types such as: User-defined routes (UDRs), DDoS Protection Plans, and other linked networking resources. If a customer virtual network is associated with one of these references that resides in a different resource group or subscription than the Azure VMware Solution virtual network, network programming (such as NSX segment propagation) may fail. To avoid issues, customers must ensure that the Azure VMware Solution virtual network isn't linked to resources in a different resource group or subscription and detach such resources (for example, DDoS Protection Plans) from the virtual network before proceeding.
38
+
- To maintain your cross-resource group reference, create a role assignment from your cross-resource group or subscription and give the “AzS VIS Prod App” the "AVS on Fleet VIS Role". The role assignment allows you to use reference and have your reference correctly applied for your Azure VMware Solution private cloud.
39
39
15. Gen 2 private cloud **deployments may fail if Azure policies that enforce strict rules for Network Security Groups or route tables (for example, specific naming conventions)**. These policy constraints can block required Azure VMware Solution Network Security Group and route table creation during deployment. You must remove these policies from the Azure VMware Solution virtual network before deploying your private cloud. Once your private cloud is deployed, these policies can be added back to your Azure VMware Solution private cloud.
40
40
16. If you are using **Private DNS** for your Azure VMware Solution Gen 2 private cloud, using **Custom DNS** on the virtual network where an Azure VMware Solution Gen 2 private cloud is deployed is unsupported. Custom DNS breaks lifecycle operations such as scaling, upgrades, and patching.
41
-
17. If you are deleting your private cloud and some Azure VMware Solution created resources are not removed, you can retry the deletion of the Azure VMware Solution private cloud using the Azure CLI.
42
-
41
+
17. If you are **deleting** your private cloud and some Azure VMware Solution created resources are not removed, you can retry the deletion of the Azure VMware Solution private cloud using the Azure CLI.
42
+
18. Azure VMware Solution Gen 2 uses an HTTP Proxy to distinguish between customer and management network traffic. Certain VMware cloud service endpoints **may not follow the same network path or proxy rules as general vCenter-managed traffic**. Examples include: "scapi.vmware" and "apigw.vmware". The VAMI proxy governs the vCenter Server Appliance’s (VCSA) general outbound internet access, but not all service endpoint interactions flow through this proxy. Some interactions originate directly from the user’s browser or from integration components, which instead follow the workstation’s proxy settings or initiate connections independently. As a result, traffic to VMware cloud service endpoints may bypass the VCSA proxy entirely.
43
+
43
44
## Unsupported integrations
44
45
45
46
The following 1st-party and 3rd-party integrations aren't available:
46
47
-**Zerto DR**
47
-
-**JetStream DR**
48
+
49
+
## Delegated Subnets and Network Security Groups for Gen 2
50
+
When an Azure VMware Solution (AVS) Gen 2 private cloud is deployed, Azure automatically creates several delegated subnets within the private cloud’s host virtual network. These subnets are used to isolate and protect the private cloud’s management components.
51
+
52
+
Customers can manage access to these subnets using Network Security Groups (NSGs) that are visible in the Azure portal or through Azure CLI/PowerShell. In addition to customer-manageable NSGs, AVS applies additional system-managed NSGs to critical management interfaces. These system-managed NSGs are not visible or editable by customers and exist to ensure that the private cloud remains secure by default.
53
+
54
+
As part of the default security posture:
55
+
- Internet access is disabled for the private cloud unless the customer explicitly enables it.
56
+
- Only required management traffic is allowed to reach platform services.
57
+
58
+
> [!Note]
59
+
You may see a warning in the Azure portal indicating that certain ports appear to be exposed to the internet. This occurs because the portal evaluates only the customer-visible Network Security Group (NSG) configuration. However, Azure VMware Solution also applies additional system-managed Network Security Groups that are not visible in the portal. These system-managed Network Security Groups block inbound traffic unless access has been explicitly enabled through Azure VMware Solution configuration.
60
+
61
+
This design ensures that the AVS environment is isolated and secure out of the box, while still allowing customers to control and customize network access based on their specific requirements.
Copy file name to clipboardExpand all lines: articles/cost-management-billing/troubleshoot-billing/troubleshoot-csp-billing-issues-usage-file-pivot-tables.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,10 +7,10 @@ ms.reviewer: jkinma
7
7
ms.service: cost-management-billing
8
8
ms.subservice: billing
9
9
ms.topic: troubleshooting
10
-
ms.date: 05/01/2025
10
+
ms.date: 11/04/2025
11
11
ms.custom:
12
-
- build-2025
13
-
- sfi-image-nochange
12
+
- build-2025
13
+
- sfi-image-nochange
14
14
---
15
15
16
16
# Troubleshoot CSP billing issues with usage file pivot tables
0 commit comments