TL;DR · Key Takeaways
- Tags are the control plane for placement. Capability tags say what infrastructure can do; constraint tags on templates say what a deployment needs.
- Capability tags live on cloud zones, network and storage profiles, and resources. Constraint tags live on cloud templates.
- The format key:value:hard must match or the deploy fails. key:value:soft prefers a match but proceeds without one.
- Resource tags are stamped onto deployed machines for management and reporting; custom properties carry values for the UI, API, and extensibility.
- VCF 9.0 adds Centralized Tag Management. None of it works without a tag taxonomy agreed before anyone starts tagging.
Tags look like metadata. In VCF Automation they are the control plane for placement. A tag on a cloud zone declares what it can do. The same key on a template declares what a deployment needs. Matching the two is how the platform decides where work runs, with no human picking a cluster. Earlier Parts used tags in passing; this one treats them as the system they are, because a sloppy tag taxonomy quietly breaks placement across the whole estate.
Three kinds of tag, three jobs
The word tag covers three different things in VCF Automation, and conflating them is where confusion starts. Capability tags sit on infrastructure, cloud zones, network and storage profiles, and individual resources, and declare what that infrastructure can offer. Constraint tags sit on cloud templates and declare what a deployment requires. Resource tags are stamped onto the machines a deployment creates, for management and reporting afterward. Capability describes supply, constraint describes demand, and resource labels the result.
| Tag type | Lives on | Job |
|---|---|---|
| Capability | Zones, profiles, resources | Declares what infrastructure can do |
| Constraint | Cloud templates | Declares what a deployment needs |
| Resource | Deployed machines | Labels results for management and reports |
Hard and soft: the format that decides outcomes
A constraint tag carries an intent in its format, and this is the detail that decides whether a deployment fails or just settles for less. Use key:value:hard when the deployment must land on infrastructure with the matching capability; if nothing matches, the deploy fails rather than placing somewhere wrong. Use key:value:soft when you prefer a match but can accept placement without one. The choice is a risk decision: hard for things that must be true, like compliance, soft for things that are merely better, like a preferred cluster.
# Capability tag on a cloud zone (what it CAN do)
zone-prod-a:
tags: [ env:prod, compliance:pci ]
# Constraint tags on a cloud template (what a deploy NEEDS)
constraints:
- tag: 'compliance:pci:hard' # MUST match, or the deploy fails
- tag: 'tier:gold:soft' # prefer it, but proceed if absent
# Resource tag applied to every machine the project deploys
project_resource_tags: [ owner:finance, costcenter:4812 ]
# hard = a rule; soft = a preference; resource tags = a label for later.| Format | If a match exists | If no match |
|---|---|---|
| key:value:hard | Places there | Deployment fails |
| key:value:soft | Prefers there | Proceeds elsewhere |
How the platform actually filters
It helps to know the order Automation Assembler applies. It starts with the candidate cloud zones, filters them by availability and by the profiles for the region, then filters the survivors by hard constraint tags, dropping any zone that does not carry the required capability. Out of whatever zones remain, priority selects one. Soft constraints nudge that selection but never eliminate a zone. Understanding this pipeline is what lets you predict where a deployment will land, and debug it when it lands somewhere surprising.
Taxonomy first, tags second
None of this works without a taxonomy agreed before anyone tags anything. A tag is only useful if everyone means the same thing by it, so decide the keys and values up front: a fixed set of keys like env, compliance, tier, and owner, with a known list of values for each. Use simple, clear names so a person reading a template or a zone understands the intent at a glance. The failure I see most is organic tagging, where env=prod, environment=production, and Env=PROD all exist and none of them match each other, so placement silently misbehaves. VCF 9.0 adds Centralized Tag Management to help keep this consistent, but a tool cannot rescue a taxonomy you never designed.
Worked example
A workable starter taxonomy is four keys. env with values dev, test, prod. compliance with values none, pci, hipaa. tier with values bronze, silver, gold. owner with the team name. Capability tags put env:prod and compliance:pci on the right zones; a template for a regulated app carries compliance:pci:hard so it can only ever land on cleared capacity; resource tags stamp owner:finance and a cost centre on every machine for chargeback. Four keys, a closed list of values, and most of your placement and reporting needs are covered. Add keys only when a real requirement demands one, because every key is a thing every zone and template now has to get right.
Custom properties and the reporting payoff
Tags are not only about placement; they are also how you get reporting and chargeback out of the platform for free. Resource tags stamped on every machine, like owner:finance and a cost centre, are what let you answer who owns this and what does it cost without maintaining a spreadsheet on the side. A project can define resource tags that get applied to every machine it deploys, so the labelling is automatic and consistent rather than something people have to remember. That consistency is the whole value: a report is only as good as the tags behind it, and tags applied by the platform beat tags applied by hand every single time.
Custom properties go a step further than resource tags. A custom property on a deployment carries a value you can read in the UI, retrieve through the API for a report, or hand to an extensibility subscription so a workflow can act on it. Where a resource tag labels a machine for grouping, a custom property carries data the rest of the platform can consume. The rule of thumb I use: tags for the things you slice and filter reports by, custom properties for the values automation downstream needs to compute or act on. They overlap a little, but keeping that distinction in mind stops you from cramming everything into tags and then wondering why your reports are noisy.
Centralized Tag Management, new in VCF 9.0, is what keeps all of this from drifting. Instead of tags defined ad hoc in a dozen places, you manage the vocabulary centrally, which is how you stop the env versus environment versus Env sprawl before it starts rather than cleaning it up after. Treat it as the registrar for your taxonomy: the keys and values live there, and zones, profiles, templates, and projects reference them. It does not invent the taxonomy for you, but once you have designed one, it is how you enforce it across the estate without relying on everyone remembering the same conventions. A taxonomy plus a registrar is the combination that actually holds up at scale.
A tag taxonomy that scales
Design the namespace before you tag
Tags fail at scale when they grow organically, one engineer’s label at a time, until the same idea exists five ways. Decide the key:value namespace first: a small set of keys with agreed allowed values, owned and reviewed like any shared schema. env:prod is governable; prod, production and PROD scattered across templates are not. The taxonomy is the asset; the individual tags are just instances of it.
Keep the three roles distinct
Capability tags describe what infrastructure offers, constraint tags describe what a workload requires, and resource tags carry metadata for reporting and automation. They look alike and do very different jobs. Mixing them, using a reporting tag as if it drove placement, produces deployments that land in surprising places or reports that do not add up. Name the role of every tag key so nobody has to guess whether a given tag steers placement or just labels a record.
Govern the vocabulary
A taxonomy only stays useful if additions go through a light review rather than appearing ad hoc. Keep the agreed tag dictionary in version control next to the templates, require a change to it the way you would require a schema change, and audit periodically for orphans, tags on templates that match no capability anywhere. The cost of governance here is minutes; the cost of drift is placement failures and reports nobody trusts.
A platform settles on six keys: env, region, tier, data-class, owner and cost-center. The first three drive placement and governance, the last three are reporting metadata. Allowed values are fixed, lowercase and documented on one page everyone references. New keys require a review. The payoff is concrete: placement is predictable because the vocabulary is closed, and showback reports reconcile because every deployment carries the same six dimensions. Six governed keys beat sixty improvised ones every time.
The quietest tag failure is a constraint tag on a template that matches no capability tag on any zone. The template validates, the catalog item publishes, and the first request fails with no suitable placement, because the requirement can never be satisfied. Nothing flags it in advance; the mismatch only bites at deploy time.
The defense is an audit that lists every constraint tag in use and confirms each has a matching capability somewhere, plus a single test deployment of any item before tenants touch it. Run that check whenever you add a region or a template, because an orphaned constraint tag is invisible until someone tries to use the item that depends on it.
What I’d Do
Tags are cheap to add and expensive to get wrong, so spend the design effort up front. My recommendation: agree a small, closed taxonomy before tagging anything, with fixed keys and known values; keep capability, constraint, and resource tags clearly separate in your own head and your documentation; use hard for rules that must hold and soft for mere preferences, never reaching for hard out of habit because a single unsatisfiable hard tag blocks every deploy that carries it; and lean on Centralized Tag Management to keep the vocabulary consistent across the estate. Get the taxonomy right and placement becomes predictable and self-documenting. Let it grow organically and you will spend your time chasing deployments that landed in the wrong place for reasons no one can explain.
Next we publish the template that all this supports to users: the Automation Service Broker catalog. For the zones these tags steer, revisit Part 10 on cloud zones. How many tag keys does your taxonomy run to? Tell me in the comments.
References
- How to Use Tags in VCF Automation (Broadcom TechDocs)
- Introducing Centralized Tag Management in VCF 9.0 (VCF Blog)
- Tagging Design in VCF Automation (Cloud Blogger)
About The Author
