How to handle autoapprove afdpe if the region did not support?
thomas-tran opened this issue · 5 comments
How to handle autoapprove afdpe if the region did not support? E.g. Australia southeast
Hi @thomas-tran, Why is auto approval not available in Australia southeast? I see that ACI is available in Australia Southeast, check here.
However even if you need to use a region where ACI is not supported, you can just approve the PE manually with this script from cloudshell, or you can go to the Azure Portal > Private Link Center > Pending connections
@thotheod Here is the error message if autoapprove enabled
"code": "PreflightValidationFailed",
"message": "There exists error(s) in the resources from the preflight request.",
"details": [
{
"code": "UnexpectedException",
"target": "/subscriptions/xxxx-xxx-xx-xxxxxx/resourceGroups/rg-spoke-hpapi-dev/providers/Microsoft.Cdn/profiles/afd-hpapi-dev-aue/securityPolicies/afdWafSecurityPolicy",
"message": "Unexpected exception(s) is thrown during Preflight validation."
},
{
"code": "CustomValidationError",
"target": "/subscriptions/xxxx-xxx-xx-xxxxxx/resourceGroups/rg-spoke-hpapi-dev/providers/Microsoft.Cdn/profiles/afd-hpapi-dev-aue/originGroups/webAppLza-u6ybej/origins/app-hpapi-dev-ause-d6xe5k-azurewebsites-net",
"message": "The location of the Private Link "Australia Southeast" is invalid or not supported"
}
Hi @thomas-tran,
Thanks for sharing the error with me. Unfortunately Azure Front Door private link is not available in Australia South East, but I see in documentation that it is available in "Australia East". Would that region work for you?
@thotheod The client request the solution to be deployed in 2 regions Australia east and Australia south east. Azure Front Door routes traffic based on availability of the primary region. When the primary region is unavailable it will route traffic to the secondary region. The app service will be blocked from the internet and only allow access from the front door .
It would not be a problem to approve the private endpoint manually. However, the Azure Front door would not allow to mix one region with private link and another without private link through the origin group
module afd '../../shared/bicep/network/front-door.bicep' = {
name: take ('AzureFrontDoor-${resourceNames.frontDoor}-deployment', 64)
params: {
afdName: resourceNames.frontDoor
diagnosticWorkspaceId: logAnalyticsWs.outputs.logAnalyticsWsId
endpointName: resourceNames.frontDoorEndPoint
originGroupName: resourceNames.frontDoorEndPoint
origins: [
{
name: webAppRegion1.outputs.webAppName //australia east
hostname: webAppRegion1.outputs.webAppHostName
enabledState: true
privateLinkOrigin: {
privateEndpointResourceId: webAppRegion1.outputs.webAppResourceId
privateLinkResourceType: 'sites'
privateEndpointLocation: webAppRegion1.outputs.webAppLocation
}
},
{
name: webAppRegion2.outputs.webAppName // australia south east
hostname: webAppRegion2.outputs.webAppHostName
enabledState: true
privateLinkOrigin: null
},
]
skuName:'Premium_AzureFrontDoor'
wafPolicyName: resourceNames.frontDoorWaf
}
}
@thomas-tran Since Azure Front Door private link is not available in Australia South East you need to do some modifications in your deployment.
You need to allow public access to the web apps. But once you do that you need to control who can access the web apps. You can manage access restrictions rules in the portal. So you can have an unmatched rule to default to deny, and then an allow rule for the service tag AzureFrontDoor.Backend. More details you also find here
This approach is not as secure as the one we demonstrate in the LZA, but it is good enough. Since the AFD Private link is not available in both regions you wish to deploy, this is the only viable alternative. The upside of that approach is that you can reduce cost, since you do not need premium AFD anymore.