2022

Using Table Storage as an Alternative to Remote State

Terraform is a fantastic tool for Infrastructure as Code. From the YAML-like HCL syntax (no JSON!), to importing files (linting JSON files FTW!), to retrieving the results of previous runs to link resources, Terraform has made a massive difference in my work. However, like all technologies, it is not without its weaknesses. Terraform uses state files to keep track of what the world looked like when it last ran, which is wonderful for identifying drift. The default pattern is to use these state files for passing data between Terraform modules. But this is actually an anti-pattern, for HashiCorp recommend not using remote state for passing data, in large part because to read the outputs from a state file the caller must have full access to read the entire remote state file, which include secrets they probably shouldn’t be allowed to access.

Allow Traffic Manager Probes Through Azure Firewall

Traffic Manager is an essential component of any resilient deployment within Azure. Whether you have a multi-region behemoth, or simply want a simple way to activate DR instances should the primary go down, Traffic Manager has a configuration for you. One key component of Traffic Manager is its probes—by frequently checking the status of your application, Traffic Manager can make intelligent decisions about where to direct the traffic.

As with all services, there are a specific set of IP addresses from which the probes will originate. Microsoft even helpfully provide a Service Tag AzureTrafficManager which is kept up-to-date with the latest IP addresses used by Traffic Manager probes. They even tell us that this Service Tag is supported for use in Azure Firewall.¹ Except… that is not the whole story.

2021

Logic App (Standard) and API Connections

I have recently had the pleasure (You keep using that word. I do not think it means what you think it means.) of deploying Logic App workflows on a Logic App (Standard) instance. For those not familiar with Logic App (Standard), they are the single-tenant instance of Logic Apps. They provide the ability to host your workflows within a virtual network, something that cannot be done with a consumption Logic App. Under the hood, standard Logic Apps are a completely different beast to consumption Logic Apps. Consumption apps can only have a single Workflow in the app (which makes sense when you consider you also pay by the execution), while standard apps are deployed into an App Service plan and can therefore have multiple workflows in a single Logic App.