Merge pull request #296436 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: PhilKang0704

articles/application-gateway/for-containers/how-to-url-redirect-ingress-api.md

@@ -393,4 +393,4 @@ Via the response we should see:
 * Connection #0 to host contoso.com left intact
 ```
 
-Congratulations, you have installed ALB Controller, deployed a backend application, and used Ingress API to configure both an HTTP to HTTPs redirect and path based redirection to specific client requests.
+Congratulations, you have installed ALB Controller, deployed a backend application, and used Ingress API to configure both an HTTP to HTTPS redirect and path based redirection to specific client requests.

articles/azure-functions/functions-scale.md

@@ -72,7 +72,7 @@ Maximum instances are given on a per-function app (Consumption) or per-plan (Pre
 | Plan | Scale out | Max # instances | 
 | --- | --- | --- |
 | **[Flex Consumption plan]** | [Per-function scaling](./flex-consumption-plan.md#per-function-scaling). Event-driven scaling decisions are calculated on a per-function basis, which provides a more deterministic way of scaling the functions in your app. With the exception of HTTP, Blob storage (Event Grid), and Durable Functions, all other function trigger types in your app scale on independent instances. All HTTP triggers in your app scale together as a group on the same instances, as do all Blob storage (Event Grid) triggers. All Durable Functions triggers also share instances and scale together. | 1000<sup>5</sup> | 
-| **[Premium plan]** | [Event driven](event-driven-scaling.md). Scale out automatically, even during periods of high load. Azure Functions infrastructure scales CPU and memory resources by adding more instances of the Functions host, based on the number of events that its functions are triggered on. | **Windows:** 100<br/>**Linux:** 20-100<sup>2</sup>| 
+| **[Premium plan]** | [Event driven](event-driven-scaling.md). Scale out automatically, even during periods of high load. Azure Functions infrastructure scales CPU and memory resources by adding more instances of the Functions host, based on the number of events that its functions are triggered on. | **Windows:** 100<sup>6</sup><br/>**Linux:** 20-100<sup>2,6</sup>| 
 | **[Dedicated plan]**<sup>3</sup> | Manual/autoscale |10-30<br/>100 (ASE)| 
 | **[Container Apps]** | [Event driven](event-driven-scaling.md). Scale out automatically, even during periods of high load. Azure Functions infrastructure scales CPU and memory resources by adding more instances of the Functions host, based on the number of events that its functions are triggered on. | 300-1000<sup>4</sup>  |
 | **[Consumption plan]** | [Event driven](event-driven-scaling.md). Scales out automatically, even during periods of high load. Functions infrastructure scales CPU and memory resources by adding more instances of the Functions host, based on the number of incoming trigger events. | **Windows:** 200<br/>**Linux:** 100<sup>1</sup>  | 
@@ -82,6 +82,7 @@ Maximum instances are given on a per-function app (Consumption) or per-plan (Pre
 3. For specific limits for the various App Service plan options, see the [App Service plan limits](../azure-resource-manager/management/azure-subscription-service-limits.md#azure-app-service-limits).
 4. On Container Apps, the default is 10 instances, but you can set the [maximum number of replicas](../container-apps/scale-app.md#scale-definition), which has an overall maximum of 1000. This setting is honored as long as there's enough cores quota available. When you create your function app from the Azure portal you're limited to 300 instances.
 5. Total instances in a given region are effectively limited by [regional subscription memory quotas](./flex-consumption-plan.md#regional-subscription-memory-quotas).
+6. For private endpoint restricted http triggers, scaling out is limited to at most 20 instances.
 
 ## Cold start behavior
 

articles/azure-web-pubsub/howto-integrate-app-gateway.md

@@ -57,7 +57,7 @@ Second, we set up the backend targets. We configure backend targets to the backe
 :::image type="content" source="media/howto-integrate-app-gateway/create-resource-step-5.jpg" alt-text="Screenshot showing how to create an Application Gateway resource - create a routing rule, backend targets.":::
 
 
-Web PubSub service only accepts HTTPs traffic. So we instruct Application Gateway to communicate with Web PubSub using HTTPs. To keep this guide focused, we let Application Gateway to pick the host. The recommended practice is to set up a Custom Domain in production.  
+Web PubSub service only accepts HTTPS traffic. So we instruct Application Gateway to communicate with Web PubSub using HTTPS. To keep this guide focused, we let Application Gateway to pick the host. The recommended practice is to set up a Custom Domain in production.  
 
 :::image type="content" source="media/howto-integrate-app-gateway/create-resource-step-6.jpg" alt-text="Screenshot showing how to create an Application Gateway resource - create a routing rule, backend settings.":::
 
@@ -236,7 +236,7 @@ export appGatewayEndpoint="<replace with the public IP of your Application Gatew
 
 Three points to note. 
 - We use the `ws://` instead of `wss://` since your Application Gateway is configured to listen to `http` traffic only. 
-- In production, it's probably best to set up custom domain for your Application Gateway resource and configured it to accept HTTPs only.
+- In production, it's probably best to set up custom domain for your Application Gateway resource and configured it to accept HTTPS only.
 - We need to keep the access token as it is since it encodes credentials for your client to connect with your Web PubSub resource. 
 
 Open your browser and visit `http://localhost:3000` again, you can verify that the WebSocket is successfully proxied through Application Gateway and receives messages from Application Gateway roughly every 2 seconds.
@@ -359,8 +359,8 @@ Make sure you select the same Virtual Network your Web PubSub resource is in.
 :::image type="content" source="media/howto-integrate-app-gateway/web-app-enable-vnet-step-2.jpg" alt-text=" Screenshot showing how to enable Virtual Network integration - step 2.":::
 
 #### Turn off automatic HTTP redirect
-By default, Web App redirects HTTP traffic to HTTPs. We need to disable this default behavior. This is not recommended for production workload. 
-:::image type="content" source="media/howto-integrate-app-gateway/web-app-turn-off-https-redirect.jpg" alt-text="Screenshot showing how to turn off automatic HTTPs redirect.":::
+By default, Web App redirects HTTP traffic to HTTPS. We need to disable this default behavior. This is not recommended for production workload. 
+:::image type="content" source="media/howto-integrate-app-gateway/web-app-turn-off-https-redirect.jpg" alt-text="Screenshot showing how to turn off automatic HTTPS redirect.":::
 
 ### Verify that everything works
 So far in step 2, you
@@ -370,7 +370,7 @@ So far in step 2, you
 4. updated the endpoint by which a client gets an access token for connecting with your Web PubSub resource
 5. deployed `publish.js` as a Web App into the same Virtual Network,
 6. set two environment variables on your Web App resource,
-7. disabled Web App's default behavior of redirecting HTTP traffic to HTTPs.
+7. disabled Web App's default behavior of redirecting HTTP traffic to HTTPS.
 
 Now, open your web browser and enter the domain name of your Web App. If you inspect the page, open the Network panel, you see that the client goes to Web App for the access token and then uses the token to establish a WebSocket connection with Application Gateway. 
 

articles/batch/batch-technical-overview.md

@@ -2,7 +2,7 @@
 title: Azure Batch runs large parallel jobs in the cloud
 description: Learn about using the Azure Batch service for large-scale parallel and HPC workloads.
 ms.topic: overview
-ms.date: 06/12/2024
+ms.date: 03/14/2025
 ---
 
 

articles/batch/quick-create-portal.md

@@ -1,7 +1,7 @@
 ---
 title: 'Quickstart: Use the Azure portal to create a Batch account and run a job'
 description: Follow this quickstart to use the Azure portal to create a Batch account, a pool of compute nodes, and a job that runs basic tasks on the pool.
-ms.date: 07/30/2024
+ms.date: 03/14/2025
 ms.service: azure-batch
 ms.topic: quickstart
 ms.custom: mvc, mode-ui

articles/cyclecloud/how-to/running-behind-proxy.md

@@ -1,6 +1,6 @@
 ---
 title: Using a Web Proxy
-description: Configure Azure CycleCloud to use a proxy for HTTP/HTTPs web traffic, which is useful to monitor traffic or when direct internet access isn't allowed.
+description: Configure Azure CycleCloud to use a proxy for HTTP/HTTPS web traffic, which is useful to monitor traffic or when direct internet access isn't allowed.
 author: dpwatrous
 ms.date: 2/18/2020
 ms.author: dawatrou

articles/event-grid/kubernetes/event-handlers.md

@@ -13,7 +13,7 @@ ms.topic: conceptual
 # Event handlers destinations in Event Grid on Kubernetes
 An event handler is any system that exposes an endpoint and is the destination for events sent by Event Grid. An event handler receiving an event acts upon it and uses the event payload to execute some logic, which might lead to the occurrence of new events.
 
-The way to configure Event Grid to send events to a destination is through the creation of an event subscription. It can be done through [Azure CLI](/cli/azure/eventgrid/event-subscription#az-eventgrid-event-subscription-create), [management SDK](../sdk-overview.md#management-sdks), or using direct HTTPs calls using the [2020-10-15-preview API](/rest/api/eventgrid/controlplane-preview/event-subscriptions/create-or-update) version.
+The way to configure Event Grid to send events to a destination is through the creation of an event subscription. It can be done through [Azure CLI](/cli/azure/eventgrid/event-subscription#az-eventgrid-event-subscription-create), [management SDK](../sdk-overview.md#management-sdks), or using direct HTTPS calls using the [2020-10-15-preview API](/rest/api/eventgrid/controlplane-preview/event-subscriptions/create-or-update) version.
 
 In general, Event Grid on Kubernetes can send events to any destination via **Webhooks**. Webhooks are HTTP(s) endpoints exposed by a service or workload to which Event Grid has access. The webhook can be a workload hosted in the same cluster, in the same network space, on the cloud, on-premises or anywhere that Event Grid can reach.
 

articles/load-balancer/manage-probes-how-to.md

@@ -29,7 +29,7 @@ Health probes have the following properties:
 | Port | Port of the health probe. The destination port you would like the health probe to use when it connects to the virtual machine to check the virtual machine's health status. You must ensure that the virtual machine is also listening on this port (that is, the port is open). |
 | Interval (seconds) | Interval of health probe. The amount of time (in seconds) between consecutive health check attempts to the virtual machine |
 | Used by | The list of load balancer rules using this specific health probe. You should have at least one rule using the health probe for it to be effective |
-| Path | The URI used for requesting health status from the virtual machine instance by the health probe (only applicable for HTTPs probes).
+| Path | The URI used for requesting health status from the virtual machine instance by the health probe (only applicable for HTTPS probes).
 
 >[!IMPORTANT]
 >Load Balancer health probes originate from the IP address 168.63.129.16 and must not be blocked for probes to mark your instance as up. To see this probe traffic within your backend instance, review [the Azure Load Balancer FAQ](./load-balancer-faqs.yml).

articles/networking/network-monitoring-overview.md

@@ -26,7 +26,7 @@ Network Performance Monitor is a suite of capabilities that is geared towards mo
 
 * Mission critical multi-tier applications/micro-services
 
-* User locations and web-based applications (HTTP/HTTPs) 
+* User locations and web-based applications (HTTP/HTTPS) 
 
 Performance Monitor, ExpressRoute Monitor, and Service Connectivity Monitor are monitoring capabilities within Network Performance Monitor and are described in the following sections.
 

articles/sap/workloads/disaster-recovery-overview-guide.md

@@ -81,7 +81,7 @@ An SAP workload running on Azure uses different infrastructure components to run
 
 - Azure [Standard Load Balancer](../../load-balancer/load-balancer-overview.md) provides networking elements for the high-availability design of your SAP systems. For clustered systems, Standard Load Balancer provides the virtual IP address for the cluster service, like ASCS/SCS instances and databases running on VMs. To run highly available SAP system on the DR site, a separate load balancer must be created and the cluster configuration should be adjusted accordingly.
 
-- [Azure Application Gateway](../../application-gateway/overview.md) is a web traffic load-balancer. With its [Web Application Firewall](../../web-application-firewall/ag/ag-overview.md) functionality, its well suited service to expose web applications to the internet with improved security. Azure Application Gateway can service either public (internet) or private clients, or both, depending on the configuration. After failover, to accept similar incoming HTTPs traffic on DR region, a separate Azure Application Gateway must be configured in the DR region.
+- [Azure Application Gateway](../../application-gateway/overview.md) is a web traffic load-balancer. With its [Web Application Firewall](../../web-application-firewall/ag/ag-overview.md) functionality, its well suited service to expose web applications to the internet with improved security. Azure Application Gateway can service either public (internet) or private clients, or both, depending on the configuration. After failover, to accept similar incoming HTTPS traffic on DR region, a separate Azure Application Gateway must be configured in the DR region.
 
 - As networking components (like virtual network, firewall etc.) are created separately in the DR region, you need to make sure that the SAP workload on DR region is adapted to the networking changes like DNS update, firewall etc.