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/active-directory-b2c/policy-keys-overview.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -75,7 +75,7 @@ If an Azure AD B2C keyset has multiple keys, only one of the keys is active at a
75
75
- When the current date and time is greater than a key's activation date, Azure AD B2C activates the key and stop using the prior active key.
76
76
- When the current key's expiration time has elapsed and the key container contains a new key with valid *nbf (not before)* and *exp (expiration)* times, the new key becomes active automatically. New tokens are signed with the newly active key. It's possible to keep an expired key published for token validation until disabled by an admin, but this must be requested by [filing a support request](/azure/active-directory-b2c/find-help-open-support-ticket).
77
77
78
-
- When the current key's expiration time has elapsed and the key container *doesn't* contain a new key with valid *not before* and *expiration* times, Azure AD B2C won't be able to use the expired key. Azure AD B2C raises an error message within a dependant component of your custom policy. To avoid this issue, you can create a default key without activation and expiration dates as a safety net.
78
+
- When the current key's expiration time has elapsed and the key container *doesn't* contain a new key with valid *not before* and *expiration* times, Azure AD B2C won't be able to use the expired key. Azure AD B2C raises an error message within a dependent component of your custom policy. To avoid this issue, you can create a default key without activation and expiration dates as a safety net.
79
79
- The key's endpoint (JWKS URI) of the OpenId Connect well-known configuration endpoint reflects the keys configured in the Key Container, when the Key is referenced in the [JwtIssuer Technical Profile](./jwt-issuer-technical-profile.md). An application using an OIDC library will automatically fetch this metadata to ensure it uses the correct keys to validate tokens. For more information, learn how to use [Microsoft Authentication Library](../active-directory/develop/msal-b2c-overview.md), which always fetches the latest token signing keys automatically.
80
80
81
81
:::image type="content" source="media/policy-keys-overview/key-rollover.png" alt-text="A diagram describing the process for key rollover in Azure AD B2C." lightbox="media/policy-keys-overview/key-rollover.png":::
@@ -41,15 +40,15 @@ Certain limitations and consequences of scaling decisions need to be considered
41
40
42
41
+ The [pricing tier](api-management-features.md) of your API Management instance determines the [maximum number of units](upgrade-and-scale.md#upgrade-and-scale) you may scale to. For example, the **Standard tier** can be scaled to 4 units. You can add any number of units to the **Premium** tier.
43
42
+ If the service is locked by another operation, the scaling request will fail and retry automatically.
44
-
+ If your service instance is deployed in multiple regions (locations), only units in the **Primary location** can be autoscaled with Azure Monitor autoscale. Units in other locations can only be scaled manually.
45
-
+ If your service instance is configured with [availability zones](zone-redundancy.md) in the **Primary location**, be aware of the number of zones when configuring autoscaling. The number of API Management units in autoscale rules and limits must be a multiple of the number of zones.
43
+
+ If your service instance is deployed in multiple regions (locations), only units in the **Primary location** can be autoscaled with Azure Monitor autoscale. Units in other locations can be scaled manually or using custom scaling tools.
44
+
+ If your service instance is configured with [availability zones](zone-redundancy.md) in the **Primary location**, we recommend leaving the default **Automatic** setting for availability zones. If you select specific zones, the number of API Management units in autoscale rules and limits must be a multiple of the number of zones configured.
46
45
47
46
## Enable and configure autoscale for an API Management instance
48
47
49
48
Follow these steps to configure autoscale for an Azure API Management service:
50
49
51
50
1. Sign in to the [Azure portal](https://portal.azure.com), and navigate to your API Management instance.
52
-
1. In the left menu, select **Scale out (auto-scale)**, and then select **Custom autoscale**.
51
+
1. In the left menu, select **Deployment + infrastructure** > **Scale out (auto-scale)**, and then select **Custom autoscale**.
53
52
54
53
:::image type="content" source="media/api-management-howto-autoscale/01.png" alt-text="Screenshot of scale-out options in the portal.":::
Copy file name to clipboardExpand all lines: articles/api-management/how-to-create-workspace.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
@@ -5,7 +5,7 @@ author: dlepow
5
5
ms.topic: how-to
6
6
ms.service: azure-api-management
7
7
ms.author: danlep
8
-
ms.date: 05/14/2025
8
+
ms.date: 06/03/2025
9
9
ms.custom:
10
10
- build-2025
11
11
---
@@ -56,7 +56,7 @@ Follow the steps in this article to:
56
56
> [!IMPORTANT]
57
57
> Plan your workspace's network configuration carefully. You can't change the network configuration after you create the workspace.
58
58
59
-
* If you select a network configuration that includes private inbound or private outbound network access, select a **Virtual network** and **Subnet** to isolate the workspace gateway, or create a new one. For network requirements, see [Network resource requirements for workspace gateways](virtual-network-workspaces-resources.md).
59
+
* If you select either **Inbound public access, outbound private access** (virtual network integration) or **Inbound private access, outbound private access** (virtual network injection), select a **Virtual network** and **Subnet** to isolate the workspace gateway, or create a new one. For network requirements, see [Network resource requirements for workspace gateways](virtual-network-workspaces-resources.md).
60
60
61
61
1. Select **Next**. After validation completes, select **Create**.
Copy file name to clipboardExpand all lines: articles/api-management/upgrade-and-scale.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
@@ -6,7 +6,7 @@ author: dlepow
6
6
7
7
ms.service: azure-api-management
8
8
ms.topic: how-to
9
-
ms.date: 07/02/2024
9
+
ms.date: 06/03/2025
10
10
ms.author: danlep
11
11
ms.custom:
12
12
- engagement-fy23
@@ -20,7 +20,7 @@ ms.custom:
20
20
Customers can scale an Azure API Management instance in a dedicated service tier by adding and removing units. A **unit** is composed of dedicated Azure resources and has a certain load-bearing capacity expressed as a number of API calls per second. This number doesn't represent a call limit, but rather an estimated maximum throughput value to allow for rough capacity planning. Actual throughput and latency vary broadly depending on factors such as number and rate of concurrent connections, the kind and number of configured policies, request and response sizes, and backend latency.
21
21
22
22
> [!NOTE]
23
-
> * In the **Basic**, **Standard**, and **Premium** tiers of the API Management service, you can configure an instance to [scale automatically](api-management-howto-autoscale.md) based on a set of rules.
23
+
> * In the **Basic**, **Standard**, and **Premium** tiers of the API Management service, and in [workspace gateways](workspaces-overview.md#workspace-gateway), you can configure an instance to [scale automatically](api-management-howto-autoscale.md) based on a set of rules.
24
24
> * API Management instances in the **Consumption** tier scale automatically based on the traffic. Currently, you cannot upgrade from or downgrade to the Consumption tier.
25
25
26
26
The throughput and price of each unit depend on the [service tier](api-management-features.md) in which the unit exists. If you need to increase capacity for a service within a tier, you should add a unit. If the tier that is currently selected in your API Management instance doesn't allow adding more units, you need to upgrade to a higher-level tier.
description: Learn about requirements for network resources when you integrate your API Management workspace gateway in an Azure virtual network.
3
+
description: Learn about requirements for network resources when you integrate or inject your API Management workspace gateway in an Azure virtual network.
4
4
author: dlepow
5
5
6
6
ms.service: azure-api-management
7
7
ms.topic: concept-article
8
-
ms.date: 07/15/2024
8
+
ms.date: 06/03/2025
9
9
ms.author: danlep
10
10
---
11
11
12
-
# Network resource requirements for integration of a workspace gateway into a virtual network
12
+
# Network resource requirements to integrate or inject a workspace gateway into a virtual network
Network isolation is an optional feature of an API Management [workspace gateway](workspaces-overview.md#workspace-gateway). This article provides network resource requirements when you integrate your gateway in an Azure virtual network. Some requirements differ depending on the desired inbound and outbound access mode. The following modes are supported:
16
+
Network isolation is an optional feature of an API Management [workspace gateway](workspaces-overview.md#workspace-gateway). This article provides network resource requirements when you integrate or inject your gateway in an Azure virtual network. Some requirements differ depending on the desired inbound and outbound access mode. The following modes are supported:
For information about networking options in API Management, see [Use a virtual network to secure inbound or outbound traffic for Azure API Management](virtual-network-concepts.md).
21
+
For background about networking options in API Management, see [Use a virtual network to secure inbound or outbound traffic for Azure API Management](virtual-network-concepts.md).
*The virtual network must be in the same region and Azure subscription as the API Management instance.
27
+
The virtual network must be in the same region and Azure subscription as the API Management instance.
29
28
30
29
### Dedicated subnet
31
30
32
-
* The subnet used for virtual network integration can only be used by a single workspace gateway. It can't be shared with another Azure resource.
31
+
* The subnet used for virtual network integration or injection can only be used by a single workspace gateway. It can't be shared with another Azure resource.
33
32
34
33
## Subnet size
35
34
@@ -42,19 +41,19 @@ The subnet must be delegated as follows to enable the desired inbound and outbou
42
41
43
42
For information about configuring subnet delegation, see [Add or remove a subnet delegation](../virtual-network/manage-subnet-delegation.md).
44
43
45
-
#### [Public/Private](#tab/external)
44
+
#### [Virtual network integration](#tab/external)
46
45
47
46
48
-
For Public/Private mode, the subnet needs to be delegated to the **Microsoft.Web/serverFarms** service.
47
+
For virtual network integration, the subnet needs to be delegated to the **Microsoft.Web/serverFarms** service.
49
48
50
49
:::image type="content" source="media/virtual-network-injection-workspaces-resources/delegate-external.png" alt-text="Screenshot showing subnet delegation to Microsoft.Web/serverFarms in the portal.":::
51
50
52
51
> [!NOTE]
53
52
> You might need to register the `Microsoft.Web/serverFarms` resource provider in the subscription so that you can delegate the subnet to the service.
54
53
55
-
#### [Private/Private](#tab/internal)
54
+
#### [Virtual network injection](#tab/internal)
56
55
57
-
For Private/Private mode, the subnet needs to be delegated to the **Microsoft.Web/hostingEnvironments** service.
56
+
For virtual network injection, the subnet needs to be delegated to the **Microsoft.Web/hostingEnvironments** service.
58
57
59
58
:::image type="content" source="media/virtual-network-injection-workspaces-resources/delegate-internal.png" alt-text="Screenshot showing subnet delegation to Microsoft.Web/hostingEnvironments in the portal.":::
60
59
@@ -67,27 +66,30 @@ For Private/Private mode, the subnet needs to be delegated to the **Microsoft.We
67
66
68
67
## Network security group (NSG) rules
69
68
70
-
A network security group (NSG) must be attached to the subnet to explicitly allow inbound connectivity. Configure the following rules in the NSG. Set the priority of these rules higher than that of the default rules.
69
+
A network security group (NSG) must be attached to the subnet to explicitly allow certain inbound or outbound connectivity. Configure the following rules in the NSG. Set the priority of these rules higher than that of the default rules.
70
+
71
+
Configure other NSG rules to meet your organization's network access requirements.
0 commit comments