In this section, you will see the complete steps for implementing Cloud Failover Extension in Microsoft Azure. You can also go straight to the Example Azure Declaration.

Azure CFE Prerequisites

These are the basic prerequisites for setting up CFE in Microsoft Azure.

  • 2 BIG-IP systems in Active/Standby configuration. You can find an example ARM template here. Any configuration tool can be used to provision the resources.
  • Virtual addresses created in a floating traffic group and matching addresses (secondary) on the IP configurations of the instance NICs serving application traffic.
  • Access to Azure’s Instance Metadata Service, which is a REST Endpoint accessible to all IaaS VMs created with the Azure Resource Manager. The endpoint is available at a well-known non-routable IP address ( that can only be accessed from within the VM. See the instructions below to Set up access to Azure’s Instance Metadata Service.


CFE makes calls to the Azure APIs in order to failover cloud resource objects such as private IP addresses and route tables. These calls may vary significantly in response time.

Complete these tasks to deploy Cloud Failover Extension in Microsoft Azure. Before getting started, we recommend you review the Known Issues and Frequently Asked Questions (FAQ).

Task Summary
Step Task

Download the RPM file

Upload and install the Cloud Failover Extension file on the BIG-IP

Create and assign a Managed Service Identity (MSI)

Tag your Azure Network Infrastructure Objects

Set up access to Azure’s Instance Metadata Service
Modify and POST the Example Azure Declaration
Update or Revert Cloud Failover Extension

Failover Event Diagram

The following diagram shows a failover event with CFE implemented in Microsoft Azure with an HA pair in an Active/Standby configuration.

In the diagram, the IP configuration has a secondary private address that matches a virtual address in a traffic group owned by the active BIG-IP. In the event of a failover, the IP configuration is deleted and recreated on that device’s network interface. Simultaneously, the user-defined routes are updated with a next hop attribute the corresponds to the self IP address of the active BIG-IP.


Example Azure Declaration

This example declaration shows the minimum information needed to update the cloud resources in Azure. See the Quickstart section for steps on how to post this declaration.

    "class": "Cloud_Failover",
    "environment": "azure",
    "externalStorage": {
        "scopingTags": {
            "f5_cloud_failover_label": "mydeployment"
    "failoverAddresses": {
        "enabled": true,
        "scopingTags": {
            "f5_cloud_failover_label": "mydeployment"
    "failoverRoutes": {
        "enabled": true,
        "scopingTags": {
            "f5_cloud_failover_label": "mydeployment"
        "scopingAddressRanges": [
                "range": ""
        "defaultNextHopAddresses": {
            "discoveryType": "static",
            "items": [


Create and assign a Managed Service Identity (MSI)

In order to successfully implement CFE in Azure, you need a system-assigned or user-managed identity with sufficient access. Your Managed Service Identity (MSI) should be limited to the resource groups that contain the BIG-IP instances, VNET, route tables, etc. that will be updated. Read more about managed identities here. To create and assign a Managed Service Identity (MSI) you must have a role of User Access Administrator or Contributor access. The following example shows a system-assigned MSI.

  1. Enable MSI for each VM: go to Virtual Machine > Identity > System assigned and set the status to On.

    For example:


  2. Assign permissions to each MSI: go to Resource Group > Access control (IAM) > Role assignments > Add, make the changes listed below, and then add the MSI.

    • Role: Contributor
    • Assign access to: System assigned managed identity > Virtual Machine

    For example:


RBAC Role Definition

Below is an example Azure role definition with permissions required by CFE.


This example provides the minimum permissions required and serves as an illustration. You are responsible for following the provider’s IAM best practices.

  • Microsoft.Authorization/*/read
  • Microsoft.Compute/locations/*/read
  • Microsoft.Compute/virtualMachines/*/read
  • Microsoft.Network/networkInterfaces/read
  • Microsoft.Network/networkInterfaces/write
  • Microsoft.Network/*/join/action
  • Microsoft.Network/routeTables/*/read
  • Microsoft.Network/routeTables/*/write
  • Microsoft.Resources/subscriptions/resourceGroups/read
  • Microsoft.Storage/storageAccounts/read
  • Microsoft.Storage/storageAccounts/listKeys/action


Certain resources such as the virtual network are commonly deployed in a seperate resource group, ensure the correct scopes are applied to all applicable resource groups.

Tag your Azure Network Infrastructure Objects

Tag your infrastructure with the the names and values that you will send in your CFE declaration.


You must tag the following resources. Even if you only have routes to update during failover (for example, there are no NIC IP configuration objects to re-map) you still have to tag the NICs on the Virtual Machines associated with the IPs in your CFE declaration.

Tag the storage account in Azure

Add a storage account to your resource group, and tag with a name/value pair that corresponds to the name/value pair in the externalStorage.scopingTags section of the CFE declaration.


Ensure the required storage accounts do not have public access.

Tag the Network Interfaces in Azure

Within Azure, go to NIC > Tags to create two distinct tags:

  • Deployment scoping tag: the example below uses f5_cloud_failover_label:mydeployment but the name and value can be anything.
  • NIC mapping tag: the name is static but the value is user-provided (f5_cloud_failover_nic_map:<your value>) and must match the corresponding NIC on the secondary BIG-IP. The example below uses f5_cloud_failover_nic_map:external.

Tag the User-Defined routes in Azure


You do not need to tag the routes if you use the static option for discoveryType in the CFE declaration. Instead, you will list the failover routes within the declaration. See the Failover Routes section for more information.

If you are using the routeTag option for discoveryType within the CFE declaration, you need to tag the route(s) with a name/value pair that will correspond to the name/value pair in the failoverRoutes.scopingTags section of the CFE declaration.

Within Azure, go to Basic UDR > Tags to create a deployment scoping tag. The name and value can be anything; the example below uses f5_cloud_failover_label:mydeployment.


Set up access to Azure’s Instance Metadata Service

Azure’s Instance Metadata Service is a REST Endpoint accessible to all IaaS VMs created via the Azure Resource Manager. The endpoint is available at a well-known non-routable IP address ( that can be accessed only from within the VM.


Certain BIG-IP versions and/or topologies may use DHCP to create the management routes (for example: dhclient_route1), if that is the case the below steps are not required.

To configure the route on BIG-IP to talk to Azure’s Instance Metadata Services, use either of the following commands:

Using TMSH

tmsh modify sys db config.allow.rfc3927 value enable
tmsh create sys management-route metadata-route network gateway
tmsh save sys config

Using Declarative Onboarding

  "managementRoute": {
    "class": "ManagementRoute",
    "gw": "",
    "network": "",
    "mtu": 1500
  "dbVars": {
    "class": "DbVariables",
    "config.allow.rfc3927": "enable"


To provide feedback on Cloud Failover Extension or this documentation, you can file a GitHub Issue.