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/frontdoor/private-link.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
@@ -27,7 +27,7 @@ You must approve the private endpoint connection before traffic can pass to the
27
27
28
28
After you enable an origin for Private Link and approve the private endpoint connection, it can take a few minutes for the connection to be established. During this time, requests to the origin receives an Azure Front Door error message. The error message goes away once the connection is established.
29
29
30
-
Once your request is approved, a private endpoint gets assigned from the Azure Front Door managed virtual network. Traffic between your Azure Front Door and your origin communicates using the established private link over the Microsoft backbone network. Incoming traffic to your origin is now secured when arriving at your Azure Front Door.
30
+
Once your request is approved, a dedicated private endpoint gets assigned for routing your traffic from the Azure Front Door managed virtual network. Traffic from your clients will reach Azure Front Door Global POPs and is then routed over the Microsoft backbone network to the AFD regional cluster which hosts the managed virtual network containing the dedicated private endpoint. The traffic is then routed to your origin via the private link platform over Microsoft backbone network. Hence the incoming traffic to your origin secured upon the moment it arrives to Azure Front Door.
31
31
32
32
> [!NOTE]
33
33
> * This feature only supports private link connectivity from your AFD to your origin. Client to AFD private connectivity is not supported.
@@ -73,15 +73,16 @@ The Azure Front Door Private Link feature is region agnostic but for the best la
73
73
* Azure Front Door doesn't allow mixing public and private origins in the same origin group. Doing so can cause errors during configuration or while AFD tries to send traffic to the public/private origins. Keep all your public origins in a single origin group and keep all your private origins in a different origin group.
74
74
* Improving redundancy:
75
75
* To improve redundancy at origin level, make sure you have multiple private link enabled origins within the same origin group so that AFD can distribute traffic across multiple instances of the application. If one instance is unavailable, then other origins can still receive traffic.
76
-
* To route Private Link traffic, requests are routed from AFD POPs to the AFD managed virtual network hosted in AFD regional clusters. To have redundancy in case the regional cluster is not reachanle, it is recommended to configure multiple origins (each with a different Private Link region) under the same AFD origin group. This way even if If one regional cluster is unavailable, then other origins can still receive traffic via a different regional cluster. Below is how an origin group with both origin level and region level redundancy would look like.
76
+
* To route Private Link traffic, requests are routed from AFD POPs to the AFD managed virtual network hosted in AFD regional clusters. To have redundancy in case the regional cluster is not reachable, it is recommended to configure multiple origins (each with a different Private Link region) under the same AFD origin group. This way even if one regional cluster is unavailable, then other origins can still receive traffic via a different regional cluster. Below is how an origin group with both origin level and region level redundancy would look like.
77
77
:::image type="content" source="./media/private-link/redundant-origin-group.png" alt-text="Diagram showing an origin group with both origin level and region level redundancy.":::
78
-
* While approving the private endpoint connection or after approving the the private endpoint connection, if you double click on the private endpoint, you will see an error message saying "You don't have access. Copy the error details and send them to your administrator(s) to get access to this page." This is expected as the private endpoint is hosted within a subscription managed by Azure Front Door.
78
+
* While approving the private endpoint connection or after approving the private endpoint connection, if you double click on the private endpoint, you will see an error message saying "You don't have access. Copy the error details and send them to your administrator(s) to get access to this page." This is expected as the private endpoint is hosted within a subscription managed by Azure Front Door.
79
+
* For platform protection, each AFD regional cluster has a limit of 7200 RPS (requests per second) per AFD profile. Requests beyond 7200 RPS will be rate limited with "429 Too Many Requests". If you are onboarding or expecting traffic more than 7200 RPS, we recommend deploying multiple origins (each with a different Private Link region) so that traffic is spread across multiple AFD regional clusters. It is recommended that each origin is a separate instance of your application to improve origin level redundancy. But if you can not maintain separate instances, you can still configure multiple origins at AFD level with each origin pointing to the same hostname but the regions are kept different. This way AFD will route the traffic to the same instance but via different regional clusters.
79
80
80
81
## Association of a private endpoint with an Azure Front Door profile
81
82
82
83
### Private endpoint creation
83
84
84
-
Within a single Azure Front Door profile, if two or more Private Link enabled origins are created with the same set of resource ID, group ID and region, then for all such origins only one private endpoint gets created. Connections to the backend can be enabled using this private endpoint. This setup means you only have to approve the private endpoint once because only one private endpoint gets created. If you create more Private Link enabled origins using the same set of Private Link location, resource ID, and group ID, you don't need to approve anymore private endpoints.
85
+
Within a single Azure Front Door profile, if two or more Private Link enabled origins are created with the same set of resource ID, group ID and region, then for all such origins only one private endpoint gets created. Connections to the backend can be enabled using this private endpoint. This setup means you only have to approve the private endpoint once because only one private endpoint gets created. If you create more Private Link enabled origins using the same set of Private Link location, resource ID, and group ID, you don't need to approve any more private endpoints.
0 commit comments