Resource Naming and Tagging

Naming and tagging make cloud estates understandable, auditable, and recoverable. They are not cosmetic; they power ownership, automation, cost allocation, and incident response.

Naming goals

Good names help operators identify what a resource is, where it runs, and who owns it. Keep names short enough for provider limits and stable enough for automation.

Common name components include:

• Organization or business unit.
• Product or service.
• Environment.
• Region.
• Resource type.
• Sequence or shard when needed.

Do not force every provider into the same exact name format when limits or conventions differ. Consistency matters, but provider constraints are real.

Required tags

Common required tags or labels:

• service
• team
• environment
• owner
• cost_center
• managed_by
• data_classification
• criticality

Use policy to enforce required tags on resources that support it. For resources that cannot be tagged, record ownership through the IaC module or service catalog.

Tag lifecycle

Tags need lifecycle management.

• Validate required tags in CI and policy.
• Keep allowed values documented.
• Remove or archive unused values.
• Review untagged spend and orphaned resources.
• Align tag values with service catalog ownership.

Automation uses

Tags should support:

• Cost reporting and chargeback or showback.
• Incident routing and escalation.
• Backup and retention policies.
• Security posture reporting.
• Environment cleanup and TTL enforcement.
• Compliance evidence collection.

Watchouts

• Free-form tags drift quickly.
• Cost allocation fails when shared resources have unclear ownership.
• Renaming cloud resources can be destructive; design names before production use.