The following table provides a summary of this module:

Key resources created:

Secondary Endpoint Registration:

The secondary (standby) cluster automatically registers itself with Traffic Manager using azapi_resource.traffic_manager_secondary_endpoint. This resource:

This approach eliminates the need for the primary cluster to know the secondary's IP address in advance, simplifying the deployment sequence.

DNS Configuration Options:

The module supports two DNS configurations depending on where your DNS zone is hosted:

When DNS is managed externally (e.g., AWS Route 53):

If your DNS zone is hosted outside Azure (common when humio.net or similar domains are managed in AWS Route 53), set:

global_dns_zone_name           = "azure-dr.humio.net"  # Used for Traffic Manager host header
global_dns_zone_resource_group = ""                    # Empty - no Azure DNS zone
global_dns_create_azure_record = false                 # Skip Azure DNS CNAME creation

Then manually create a CNAME record in your external DNS provider:

Example for AWS Route 53:

Record Name: logscale.azure-dr.humio.net
Record Type: CNAME
Record Value: <tm-profile>.trafficmanager.net
TTL: 60 seconds

Traffic Manager Priority Routing:

The following diagram provides an overview of the traffic routing:

Priority Routing Logic:

The following table shows priority routing logic:

Expected Profile Status During Normal Operations:

When the secondary cluster is in standby mode (dr="standby"), the Traffic Manager profile will show a status of "Degraded". This is expected and correct behavior, not an error.

Why this happens:

What you should see:

Verification:

Despite the "Degraded" profile status, traffic routes correctly:

# Global DR FQDN should return HTTP 200
curl -sk https://logscale.azure-dr.humio.net/api/v1/status
# DNS resolves to primary IP
dig +short logscale.azure-dr.humio.net
# Returns: <tm-profile>.trafficmanager.net → <primary-ip>

When to be concerned:

Only if the primary endpoint shows "Degraded" while the primary cluster should be healthy. This indicates an actual issue requiring investigation.

Health Check Configuration:

Failover Timing:

The following table provides a summary of this module:

Key resources created:

The following table shows the key resources created:

Metric Alert Configuration:

The metric alert monitors the health state of the primary Traffic Manager external endpoint:

Implementation note:

The module scopes the alert to the Traffic Manager profile and uses the EndpointName dimension (extracted from the primary endpoint resource ID) to target only the primary endpoint.

How it works:

The following diagram provides an overview of the process:

Failover chain timing:

Configuration options (in tfvars):

Function App SKU Selection:

Azure Function Apps support multiple pricing tiers. The choice depends on quota availability in your target region:

Checking Azure Quota:

If deployment fails with quota errors, check available quota:

# Check Dynamic VMs quota (for Y1 Consumption plan)
az vm list-usage --location <region> -o table | grep -i dynamic

# Check BS Series quota (for B1/B2/B3 Basic plan)
az vm list-usage --location <region> -o table | grep -i "BS Family"

Example tfvars for Basic SKU (quota workaround):

# Use Basic plan when Consumption (Y1) quota is unavailable
dr_failover_function_sku      = "B1"
dr_failover_function_location = "eastus2"

Cross-Region Deployment:

The Function App can be deployed to a different Azure region than the AKS cluster if quota constraints prevent deployment in the primary region. This is configured using the dr_failover_function_location variable:

# Deploy Function App to westus when eastus2 lacks Y1 quota
dr_failover_function_location = "westus"

Why this works:

The Azure Function communicates with AKS using Azure's control plane API (ARM), not the pod network. The Function App's Managed Identity is granted the "Azure Kubernetes Service Cluster Admin Role" on the AKS cluster, which is a subscription-scoped RBAC assignment that works regardless of the Function App's region.

AKS Authorized IP Ranges (Critical):

When AKS is configured with authorized IP ranges (ip_ranges_allowed_to_kubeapi), the Function App's outbound IPs must be included in the authorized list. Otherwise, the function will fail to connect to the Kubernetes API with connection timeout errors.

This is handled automatically by the azapi_update_resource.aks_authorized_ips_for_function resource in data-sources.tf, which:

Why this requires a separate resource:

A circular dependency exists because:

The azapi_update_resource.aks_authorized_ips_for_function resource breaks this cycle by updating AKS after both resources exist.

Troubleshooting Function App connectivity:

If the Function App logs show connection timeout errors like:

Connection to
        <ks-cluster>.hcp.<region>.azmk8s.io timed
        out

Verify the function's outbound IPs are in the AKS authorized ranges:

# Get Function App outbound IPs
az functionapp show \
  --name <function-app-name> \
  --resource-group <rg-name> \
  --query "possibleOutboundIpAddresses" -o tsv | tr ',' '\n'

# Get AKS authorized IP ranges
az aks show \
  --name <aks-cluster-name> \
  --resource-group <rg-name> \
  --query "apiServerAccessProfile.authorizedIpRanges" -o tsv

# If IPs are missing, apply the data-sources update:
terraform apply -var-file=secondary-<region>.tfvars \
  -target=azapi_update_resource.aks_authorized_ips_for_function

Troubleshooting Function Code Deployment:

When updating the Function App code, Terraform's zip_deploy_file may not always trigger a proper code update due to Azure's caching mechanisms. If the function continues to fail with errors referencing old code after a Terraform apply, use the Kudu zipdeploy API directly.

Symptoms of stale code deployment:

Diagnose by checking deployed code:

# Get deployment credentials
CREDS=$(az functionapp deployment list-publishing-profiles \
  --name <function-app-name> \
  --resource-group <rg-name> \
  --query "[?publishMethod=='MSDeploy'].{user:userName,pass:userPWD}" -o tsv)
USER=$(echo "$CREDS" | cut -f1)
PASS=$(echo "$CREDS" | cut -f2)

# Check what's in wwwroot
curl -s -u "${USER}:${PASS}" \
  "https://<function-app-name>.scm.azurewebsites.net/api/vfs/site/wwwroot/" | jq '.[].name'

# Check recent function logs for errors
curl -s -u "${USER}:${PASS}" \
  "https://<function-app-name>.scm.azurewebsites.net/api/vfs/LogFiles/Application/Functions/Host/" | \
  jq -r '.[0].href' | xargs curl -s -u "${USER}:${PASS}" | tail -50

Force code deployment via Kudu API:

# Navigate to the dr-failover-function module
cd modules/azure/dr-failover-function

# Get deployment credentials
USER='$<function-app-name>'
PASS=$(az functionapp deployment list-publishing-profiles \
  --name <function-app-name> \
  --resource-group <rg-name> \
  --query "[?publishMethod=='MSDeploy'].userPWD" -o tsv)

# Deploy directly via Kudu zipdeploy API
curl -X POST -u "${USER}:${PASS}" \
  --data-binary @function_app.zip \
  "https://<function-app-name>.scm.azurewebsites.net/api/zipdeploy?isAsync=false" \
  -H "Content-Type: application/zip" \
  --max-time 300

# Verify deployment succeeded
curl -s -u "${USER}:${PASS}" \
  "https://<function-app-name>.scm.azurewebsites.net/api/deployments" | \
  jq '.[0] | {status, complete, end_time}'

After Kudu deployment, restart the function:

# Restart to clear any cached code
az functionapp restart \
  --name <function-app-name> \
  --resource-group <rg-name>

# Wait 30 seconds for restart, then test
sleep 30

# Test the function
FUNC_KEY=$(az functionapp keys list \
  --name <function-app-name> \
  --resource-group <rg-name> \
  --query "functionKeys.default" -o tsv)

curl -X POST "https://<function-app-name>.azurewebsites.net/api/dr_failover_trigger?code=${FUNC_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"schemaId":"azureMonitorCommonAlertSchema","data":{"essentials":{"firedDateTime":"2024-01-01T00:00:00Z"}}}'

Why Terraform deployment may fail to update code:

The zip_deploy_file attribute in the azurerm_linux_function_app resource creates the deployment package, but Azure Functions may cache the old code in memory. The FUNCTION_CODE_HASH app setting is used to trigger redeployment when code changes, but the actual extraction and loading of new code depends on Azure's deployment infrastructure.

When Terraform shows "apply complete" but the code isn't updated:

The Kudu /api/zipdeploy endpoint bypasses this by: