Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into ps-partner

halkazwini · halkazwini · commit c68dcc7c6ce6 · 2024-10-08T20:56:12.000-05:00
diff --git a/.github/policies/disallow-edits.yml b/.github/policies/disallow-edits.yml
@@ -86,3 +86,4 @@ configuration:
               reply: >-
                 @${issueAuthor} - You tried to add content to a folder path that has been removed from this repository. Your pull request will be automatically closed. Submit your changes to the updated repository, which can be identified by clicking the Edit this Document link at the top of any published article for that product or service.
           - closePullRequest
+          
diff --git a/articles/azure-cache-for-redis/cache-how-to-scale.md b/articles/azure-cache-for-redis/cache-how-to-scale.md
@@ -369,7 +369,9 @@ Scaling time depends on a few factors. Here are some factors that can affect how
 - High write requests: Higher number of writes mean more data replicates across nodes or shards
 - High server load: Higher server load means the Redis server is busy and limited CPU cycles are available to complete data redistribution
 
-Generally, when you scale a cache with no data, it takes approximately 20 minutes. For clustered caches, scaling takes approximately 20 minutes per shard with minimal data.
+Scaling a cache is non-trivial action and can take a long time.
+
+Based on real world examples, the time to scale cache with one to two shards can be 1 to 2 hours when the cache is not under heavy loads.If you have more shards, the time to scale doesn't increase in a linear way.
 
 ### How can I tell when scaling is complete?
 
diff --git a/articles/expressroute/about-fastpath.md b/articles/expressroute/about-fastpath.md
@@ -89,7 +89,7 @@ FastPath Private endpoint/Private Link connectivity is supported for the followi
 > * FastPath supports a max of 100Gbps connectivity to a single Availability Zone.
 
 > [!IMPORTANT]
-> For more information about supported scenarios and to enroll in the limited GA offering, complete this [Microsoft Form](https://aka.ms/FastPathLimitedGA). Once Microsoft has reached out to you, [enable Private Link over FastPath](expressroute-howto-linkvnet-arm.md#fastpath-virtual-network-peering-user-defined-routes-udrs-and-private-link-support-for-expressroute-direct-connections) by running the commands in Step 2.
+> For more information about supported scenarios and to enroll in the limited GA offering, complete this [Microsoft Form](https://aka.ms/FPlimitedga). Once Microsoft has reached out to you, [enable Private Link over FastPath](expressroute-howto-linkvnet-arm.md#fastpath-virtual-network-peering-user-defined-routes-udrs-and-private-link-support-for-expressroute-direct-connections) by running the commands in Step 2.
 
 ## Next steps
 
diff --git a/articles/expressroute/expressroute-howto-linkvnet-arm.md b/articles/expressroute/expressroute-howto-linkvnet-arm.md
@@ -255,7 +255,7 @@ With Virtual Network Peering and UDR support, FastPath will send traffic directl
 With FastPath and Private Link, Private Link traffic sent over ExpressRoute bypasses the ExpressRoute virtual network gateway in the data path. With both of these features enabled, FastPath will directly send traffic to a Private Endpoint deployed in a "spoke" Virtual Network.
 
 These scenarios are Generally Available for limited scenarios with connections associated to 10 Gbps and 100 Gbps ExpressRoute Direct circuits. To enable, follow the below guidance:
-1. Complete this [Microsoft Form](https://aka.ms/fastpathlimitedga) to request to enroll your subscription. Requests may take up to 4 weeks to complete, so plan deployments accordingly.
+1. Complete this [Microsoft Form](https://aka.ms/fplimitedga) to request to enroll your subscription. Requests may take up to 4 weeks to complete, so plan deployments accordingly.
 2. Once you receive a confirmation from Step 1, run the following Azure PowerShell command in the target Azure subscription.
  ```azurepowershell-interactive
 $connection = Get-AzVirtualNetworkGatewayConnection -ResourceGroupName <resource-group> -ResourceName <connection-name>
diff --git a/articles/firewall/features.md b/articles/firewall/features.md
@@ -116,7 +116,7 @@ Forced Tunnel mode can't be configured at run time. You can either redeploy the
 
 ## Outbound SNAT support
 
-All outbound virtual network traffic IP addresses are translated to the Azure Firewall public IP (Source Network Address Translation). You can identify and allow traffic originating from your virtual network to remote Internet destinations. When Azure Firewall has multiple public IPs configured for providing outbound connectivity, it will use the Public IPs as needed based on available ports. It will **randomly pick the first Public IP** and only use the **next available Public IP** after no more connections can be made from the current public IP **due to SNAT port exhaustion**.
+All outbound virtual network traffic IP addresses are translated to the Azure Firewall public IP (Source Network Address Translation). You can identify and allow traffic originating from your virtual network to remote Internet destinations. When Azure Firewall has multiple public IPs configured for providing outbound connectivity, any public IP may be chosen and we do not recommend building any dependencies on which public IP may be used for outbound connections. 
 
 In scenarios where you have high throughput or dynamic traffic patterns, it is recommended to use an [Azure NAT Gateway](/azure/nat-gateway/nat-overview). Azure NAT Gateway dynamically selects public IPs for providing outbound connectivity. To learn more about how to integrate NAT Gateway with Azure Firewall, see [Scale SNAT ports with Azure NAT Gateway](/azure/firewall/integrate-with-nat-gateway).
 
diff --git a/articles/governance/policy/concepts/policy-for-kubernetes.md b/articles/governance/policy/concepts/policy-for-kubernetes.md
@@ -606,18 +606,28 @@ Finally, to identify the AKS cluster version that you're using, follow the linke
 
 ### Add-on versions available per each AKS cluster version
 
+#### 1.8.0
+Policy can now be used to evaluate CONNECT operations, for instance, to deny `exec`s. Note that there is no brownfield compliance available for noncompliant CONNECT operations, so a policy with Audit effect that targets CONNECTs is a no op.
+
+Security improvements.
+- Released November 2024
+- Kubernetes 1.27+
+- Gatekeeper 3.17.1
+
 #### 1.7.1
 Introducing CEL and VAP. Common Expression Language (CEL) is a Kubernetes-native expression language that can be used to declare validation rules of a policy. Validating Admission Policy (VAP) feature provides in-tree policy evaluation, reduces admission request latency, and improves reliability and availability. The supported validation actions include Deny, Warn, and Audit. Custom policy authoring for CEL/VAP is allowed, and existing users won't need to convert their Rego to CEL as they will both be supported and be used to enforce policies. To use CEL and VAP, users need to enroll in the feature flag `AKS-AzurePolicyK8sNativeValidation` in the `Microsoft.ContainerService` namespace. For more information, view the [Gatekeeper Documentation](https://open-policy-agent.github.io/gatekeeper/website/docs/validating-admission-policy/).
 
 Security improvements.
-- Released Sep 2024 
+- Released September 2024 
 - Kubernetes 1.27+ (VAP generation is only supported on 1.30+)
 - Gatekeeper 3.17.1 
 
 #### 1.7.0
 
 Introducing expansion, a shift left feature that lets you know up front whether your workload resources (Deployments, ReplicaSets, Jobs, etc.) will produce admissible pods. Expansion shouldn't change the behavior of your policies; rather, it just shifts Gatekeeper's evaluation of pod-scoped policies to occur at workload admission time rather than pod admission time. However, to perform this evaluation it must generate and evaluate a what-if pod that is based on the pod spec defined in the workload, which might have incomplete metadata. For instance, the what-if pod won't contain the proper owner references. Because of this small risk of policy behavior changing, we're introducing expansion as disabled by default. To enable expansion for a given policy definition, set `.policyRule.then.details.source` to `All`. Built-ins will be updated soon to enable parameterization of this field. If you test your policy definition and find that the what-if pod being generated for evaluation purposes is incomplete, you can also use a mutation with source `Generated` to mutate the what-if pods. For more information on this option, view the [Gatekeeper documentation](https://open-policy-agent.github.io/gatekeeper/website/docs/expansion#mutating-example).
 
+Expansion is currently only available on AKS clusters, not Arc clusters.
+
 Security improvements.
 - Released July 2024
 - Kubernetes 1.27+
diff --git a/articles/load-balancer/load-balancer-outbound-connections.md b/articles/load-balancer/load-balancer-outbound-connections.md
@@ -52,6 +52,8 @@ Calculate ports per instance as follows:
 
 If you have Virtual Machine Scale Sets in the backend, it's recommended to allocate ports by "maximum number of backend instances". If more VMs are added to the backend than remaining SNAT ports allowed, scale out of Virtual Machine Scale Sets could be blocked, or the new VMs won't receive sufficient SNAT ports. 
 
+When multiple frontend IPs are configured using outbound rules, outbound connections may come from any of the frontend IPs configured to the backend instance. We do not recommend building any dependencies on which frontend IP may be selected for connections.
+
 For more information about outbound rules, see [Outbound rules](outbound-rules.md).
 
 ## 2. Associate a NAT gateway to the subnet
