Azure Policy: Deny HTTP listeners (Application Gateway)

Here is the second Azure Policy example in addition to the first one . The following policy is quiet simple and denies creation of HTTP listeners for Application Gateways, so only HTTPS Listeners are allowed:

#Version1
{
  "mode": "All",
  "policyRule": {
    "if": {
      "anyof": [
        {
          "not": {
            "field": "Microsoft.Network/applicationGateways/httpListeners[*].protocol",
            "notEquals": "Http"
          }
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {}
}

#Version2
{
  "mode":"All"
  "policyRule": {
    "if": {

        "not": {

            "equals": "Https",

            "field": "Microsoft.Network/applicationGateways/httpListeners[*].protocol"

        }

    },

    "then": {

        "effect": "deny"

    }
},
"parameters": {}
}

To assign the policy by using PowerShell:

# Create the Policy Definition (Subscription scope)
$policyrules = "URI here"
$policyparams = "URI here (optional)"
$definition = New-AzPolicyDefinition -Name 'Deny HTTP Listeners' -Policy $policyrules  -Parameter $policyparams -Mode All

# Set the scope to a resource group; may also be a resource, subscription, or management group
$scope = Get-AzResourceGroup -Name 'mvphero'

# Create the Policy Assignment
New-AzPolicyAssignment -Name 'Deny HTTP Listeners' -DisplayName 'Deny Application Gateway HTTP Listeners' -Scope $scope.ResourceId -PolicyDefinition $definition

Azure ARM | Cannot add the second NIC to Load Balancer (different availability sets)

Imagine that you need to configure Load Balancer (LB) to handle requests from outside to multiple scale sets , virtual machines or internal LB needs to be added in addition to external LBs. You configure VMs, scale sets, load balancer(s), backend pool and define load balancing rule. The following example shows an excerpt from the arm template:

 ####
"loadBalancingRules": [
                    {
                        "name": "[variables('lbInternalName')]",
                        "properties": {
                            "frontendIPConfiguration": {
                                "id": "[variables('lbInternalFrontEndId')]"
                            },
                            "backendAddressPool": {
                                "id": "[variables('lbInternalBackEndPoolId')]"
                            },
                            "protocol": "Tcp",
                            "frontendPort": 80,
                            "backendPort": 80, 
                            "enableFloatingIP": false,
                            "idleTimeoutInMinutes": 5,
                            "probe": {
                                "id": "[variables('lbInternalProbeId')]"
                            }
                        }
                    }
                ],
####

What can go wrong? Pay attention to the Load Balancer SKU.

You deployment/configuration may fail with the following errrors:

  • Network <..> associated with different availability set <…>
  • Network Interface and Load Balancer are in different availability sets

And, if you are trying to configure scale sets with multiple load balancers:

  • Different basic sku and standard sku load balancer or public Ip resources in VMSS is not allowed

So, if your goal is to associate multiple scale sets with a load balancer, the load balancer must be Standard. Only Standard LB allows you to have multiple endpoints in a backend pool. Also, make sure you are not mixing the LB SKUs. It happens often when int and ext LBs are in use.