Tagging Standards

This page documents our standard Azure resource tags. Each section below defines one tag: what it's for, when it's required, and the format its values should follow. Additional sections will be added as we define more tagging standards.

How Tags Are Applied

Unlike the AWS provider, the azurerm provider has no provider-level default_tags feature, so this repo implements the same behavior itself:

• default_tags — a root variable (defined in src/variables.global.tf) set per environment in its tfvars (the default_tags block in terraform.tfvars, or a dedicated default_tags.tfvars in environments that split their tfvars into multiple files, like dev). It is passed into every module and merged into every resource's tags.
• Per-resource tags maps — most resource definitions in the environment tfvars accept a tags map. Each module merges it over the defaults with merge(var_default_tags, <resource>.tags), so a per-resource tag overrides a default tag with the same key.
• Generated tags — the virtual machine modules (windows_virtual_machine and linux_virtual_machine) add two more tags on top of the merged result:
  • PatchGroup (key configurable via patch_group_tag) when patch_group_tagging = true — set to "1" or "2" based on the trailing digits of the VM name, alternating VMs between the two patch groups.
  • PilotLight (key configurable via pilot_light_tag) when pilot_light > 0 — set to "true" for the first pilot_light VMs in the group and "false" for the rest.

Standard tags defined on this page should be set in the per-resource tags map unless the standard says otherwise.

application

The application tag identifies the application or workload a resource supports. Its primary purpose is grouping hosts by application in Ansible: the ansible-epic dynamic inventory (see inventory.azure.constructed.yml) builds an app_<application> group from the tag (e.g. app_kuiper, app_systempulse), so tagging a VM is all it takes to place it in the right Ansible group and pick up that application's group_vars. Hosts missing the tag fall into app_unclassified.

The tag also enables grouping, filtering, and reporting by application elsewhere (for example, in Microsoft Cost Management and the Azure portal's tag filters).

Note that environments also set an application tag in default_tags (for example, dev sets application = "epic"), which acts as a catch-all for resources without a more specific value. Because per-resource tags win the merge, setting application in a resource's tags map overrides the environment default.

Format

• Key: application (all lowercase)
• Value: lowercase letters and digits only — no spaces, hyphens, or underscores. Multi-word application names are run together (System Pulse → systempulse), and abbreviated names use the abbreviation (Hyperspace Web → hsw).
• Use the same value for every resource belonging to the same application so grouping and filtering work consistently.
• The value becomes the Ansible group name suffix (app_<value>), so it must match the application name used in the ansible-epic repo's group_vars.
• Always use the value from the table below. If the application isn't listed yet, add it to the table in the same change that introduces the tag.

Application Values

Application	Tag Value
Authentication Hyperspace Web	ahsw
Cogito Clarity	cog
Hyperspace Web	hsw
Interconnect Background	icbg
Interconnect Foreground	icfg
IRIS/ODB	odb
Kuiper	kuiper
Multipurpose SQL Server	msql
NGINX	nginx
SMTP Forwarder	smtp
System Pulse	systempulse

Where to Set It

Add the tag to the tags map of the resource definition in the environment's tfvars:

windows_vms = {
    hsw = {
        # ...
        tags = {
            application          = "hsw",
            backend_address_pool = "hsw"
        }
    }
}