Agent RulesAgent Rules
AW

AWS Resource Naming & Tagging

Naming conventions, tagging strategies, and resource organization

Amazon Web Services
Style Guide
naming
tagging
organization
conventions
Use in BuilderAll Amazon Web Services Options

Details

Language / Topic
awsAmazon Web Services
Category
Style Guide

Rules

balanced
- Use consistent naming: {project}-{environment}-{service}-{resource} (e.g., myapp-prod-api-lambda)
- Enforce mandatory tags: Environment, Project, Owner, CostCenter on all resources via SCPs or Config rules
- Use lowercase with hyphens for resource names; avoid underscores (inconsistent support across services)
- Tag all resources at creation time — retroactive tagging is unreliable and often incomplete
- Use AWS Resource Groups to organize and query resources by tag for operational visibility
- Use consistent naming pattern: {project}-{environment}-{service}-{resource} for all resources
- Enforce mandatory tags via AWS Organizations SCPs or AWS Config rules: Environment, Project, Owner, CostCenter
- Use lowercase with hyphens for resource names; follow service-specific constraints (S3: no uppercase, IAM: specific charset)
- Tag all resources at creation time in IaC templates — never rely on manual tagging after deployment
- Use AWS Resource Groups and Tag Editor for bulk visibility and operations across tagged resources
- Separate environments by AWS account (preferred) or by prefix/tag when using shared accounts
- Use consistent tag keys across the organization — create a tag taxonomy document and enforce it
- Apply automation tags: ManagedBy (terraform/cdk/manual), Repository, PipelineId for operational context
- Use tag-based IAM policies (ABAC) to control access: e.g., developers can only manage resources tagged Team=their-team
- Avoid embedding mutable metadata in resource names — use tags for information that might change