Merge pull request #307483 from yash177-maker1/docs-editor/native-network-design-consider-1761689847

Update native-network-design-consideration.md

Author: JamesJBarnett

articles/azure-vmware/native-auto-peering-sync.md

@@ -37,6 +37,7 @@ Ensures that virtual machines hosted in Azure VMware Solution can securely and c
 ## Prerequisite
 
 - Ensure the "Microsoft.BareMetal" resource provider is registered.
+- 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.
 
 ## Deployment steps 
 

articles/azure-vmware/native-dns-forward-lookup-zone.md

@@ -26,10 +26,31 @@ Azure VMware Solution allows you to configure DNS forward lookup zones in two wa
 
 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.
 
-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. 
+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.
 
 :::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":::
 
+## Using Public DNS Resolution with Azure VMware Solution Gen 2
+
+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.
+
+### How Public DNS Resolution Works
+
+Public DNS records resolve successfully from any location with internet access, including:
+- Virtual machines inside the private cloud
+- On-premises networks
+- External networks
+
+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.
+
+### Verifying DNS Resolution
+
+To verify that public DNS resolution is working:
+1. Open a terminal or command prompt from any machine with internet access.
+2. Run the following command:"nslookup vc123.eastus.avs.azure.com".
+
+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.
+
 ## Configure private DNS for your Azure VMware Solution Generation 2 private cloud  
 
 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
 
 To configure the forward lookup zone:
 
-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`).
+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`).
 
 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.
 
 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.
 
 **Example**:
 
-vCenter Server URL: `https://vc123.avs.contoso.com`
+vCenter Server URL: `https://vc123.avs.com`
 
-Forward lookup zone to create: `avs.contoso.com`
+Forward lookup zone to create: `avs.com`
 
 Forwarder target: IP address of your Azure DNS Private Resolver inbound endpoint
 

articles/azure-vmware/native-internet-connectivity-design-considerations.md

@@ -35,7 +35,7 @@ Internet connectivity using Azure Firewall is similar to the way Azure virtual n
     >The Azure route tables (UDR), associated with private cloud uplink subnets, and private cloud VNet need to be in the same Azure resource group.
 4. Have necessary firewall rules to allow traffic to and from the internet.
 
-Related topics
+## Related topics
 - [Connectivity to an Azure Virtual Network](native-network-connectivity.md)
 - [Connect to on-premises environment](native-connect-on-premises.md)
 - [Connect multiple Gen 2 private clouds](native-connect-multiple-private-clouds.md)

articles/azure-vmware/native-introduction.md

@@ -13,7 +13,7 @@ ms.author: jacobjaygbay
 ---
 # Introduction to Azure VMware Solution Generation 2 Private Clouds
 
-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).
+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).
 
 :::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"::: 
 
@@ -54,17 +54,18 @@ Gen 2 private clouds are supported on the following SKU type:
 
 Gen 2 is available in the following Azure public regions. 
 
+- Australia East
 - East US
 - Canada Central
 - Canada East
+- Central US
 - North Europe
 - Norway East
-
+- Switzerland North
 - UK West
-
 - West US 2
 
-Beyond these regions, SLAs are region specific. Contact your Microsoft account team or Microsoft Support to confirm coverage.
+There may other regions that have Gen 2 available. Contact your Microsoft account team or Microsoft Support to confirm coverage in other regions.
 
 ## Next steps
 

articles/azure-vmware/native-network-design-consideration.md

@@ -15,36 +15,50 @@ ms.custom:
 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.
 
 > [!Note]
-> Generation 2 is available in specific Azure public regions. SLAs are region specific. Contact your Microsoft account team or Microsoft Support to confirm coverage.
+> Generation 2 is available in specific Azure public regions. Contact your Microsoft account team or Microsoft Support to confirm coverage.
 
 ## Limitations
 
 The following functionality is limited during this time. These limitations will be lifted in the future:
 
 1. You cannot delete your **Resource Group**, which contains your private cloud. You must delete the private cloud first before deleting the resource group.  
 2. You can only deploy **1 private cloud per Azure virtual network**.  
-3. You can only create **1 private cloud per Resource Group**. Multiple private clouds in a single Resource Group are not supported.  
+1. You can only create **1 private cloud per Resource Group**. Multiple private clouds in a single Resource Group are not supported. 
+
 4. Your private cloud and virtual network for your private cloud must be in the ***same*** Resource Group.  
 5. You cannot ***move*** your private cloud from one Resource Group to another after the private cloud is created.  
 6. You cannot ***move*** your private cloud from one tenant to another after the private cloud is created.  
-7. **Service Endpoints** direct connectivity from Azure VMware Solution workloads isn't supported.  
-8. Only host-level mounts of Azure NetApp Files are supported. **Mounting directly from Azure VMware Solution virtual machines** is not supported.  
+1. **Service Endpoints** direct connectivity from Azure VMware Solution workloads isn't supported.  
 9. **vCloud Director** using Private Endpoints is supported. However, vCloud Director using Public Endpoints isn't supported.  
 10. **vSAN Stretched Clusters** isn't supported.  
 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).  
 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.  
 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.  
-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.  
-    - 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.  
+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.  
+    - 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.  
 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.  
 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.  
-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.  
-        
+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.
+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.
+
 ## Unsupported integrations
 
 The following 1st-party and 3rd-party integrations aren't available:
 - **Zerto DR**
-- **JetStream DR**
+
+## Delegated Subnets and Network Security Groups for Gen 2
+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.
+
+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.
+
+As part of the default security posture:
+- Internet access is disabled for the private cloud unless the customer explicitly enables it.
+- Only required management traffic is allowed to reach platform services.
+
+> [!Note]
+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.
+
+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.
 
 ## Routing and subnet considerations