The Terraform AWS Provider exposes more than seven hundred resources that map Terraform configuration to AWS infrastructure. The demand for a provider-level mechanism to enforce consistent tagging across those resources drove the introduction of default_tags in provider version 3.38.0. The feature allows a single declaration in the provider block to propagate tags to every taggable resource created by that provider instance, while preserving resource-level control when a conflict occurs. The design acknowledges operational realities in AWS, most notably the dynamic instance launch behavior of Auto Scaling Groups, which remain outside the automatic propagation path. The result is a configuration surface that reduces repetition, supports organizational cost allocation and access control policies, and integrates with variable validation to fail plans early when tagging standards are not met.
The capability requires Terraform 0.12 or later and Terraform AWS Provider v3.38.0 or later. Once enabled, tags defined in defaulttags are inherited by dependent Terraform modules that use the same provider instance. The inheritance is additive and non-destructive. Resource-level tags merge on top of provider defaults and resource-level values win on key conflicts. The merged view is exposed via the tagsall attribute on supported resources. AWS enforces a hard limit of fifty tags per resource, including system tags, which shapes design decisions when combining provider defaults with resource-specific tags.
Provider Level Configuration
A provider block with default_tags establishes the baseline tagging for all resources created through that provider.
hcl
provider "aws" {
default_tags {
tags = {
Environment = "Test"
Owner = "TFProviders"
Project = "Test"
}
}
}
The configuration applies to every taggable resource created by the provider. The impact for operators is immediate reduction in manual tag repetition and a guarantee that new resources created in the future will carry the baseline attributes without additional code. The contextual layer is that teams can centralize naming conventions, cost center identifiers, and ownership metadata in one location, which simplifies audits and supports AWS Cost Explorer allocation reports.
The same pattern is used with variables to make defaults dynamic.
hcl
provider "aws" {
region = var.aws_region
default_tags {
tags = {
Environment = var.environment
Project = var.project_name
ManagedBy = "terraform"
Team = var.team_name
CostCenter = var.cost_center
}
}
}
Every supported AWS resource created by this provider receives those five tags automatically. The approach aligns with AWS recommendations for a robust and consistent tagging strategy to enable better auditing, cost allocation, and access control. The operational consequence is that untagged resources that historically consumed budget without attribution become unlikely, because the provider enforces baseline metadata at creation time.
Inheritance and Precedence Rules
Default tags do not supersede tags set on individual resources. Resource tags take precedence when a conflict exists for the same key.
hcl
resource "aws_vpc" "example" {
cidr_block = "10.1.0.0/16"
tags = {
Name = "my-vpc-resource"
}
}
The VPC receives the provider default tags plus the Name tag defined at resource level. The same merging behavior applies to subnets.
hcl
resource "aws_subnet" "example" {
cidr_block = "10.1.1.0/24"
vpc_id = aws_vpc.test.id
tags = {
Name = "my-subnet-resource"
}
}
The impact is predictable composition. Operators can define global attributes once and override selectively for specific resources without duplicating the entire tag set. The contextual connection is that modules consuming the provider automatically inherit the defaults, so module authors do not need to re-declare organizational tags inside each module.
The merge result is observable through tags_all.
```hcl
provider "aws" {
region = "us-east-1"
default_tags {
tags = {
Environment = "production"
ManagedBy = "terraform"
Owner = "platform-team"
}
}
}
resource "awss3bucket" "example" {
bucket = "my-app-assets"
tags = {
Purpose = "static-assets"
}
}
```
The bucket carries four tags in total: the three defaults and the resource-specific Purpose tag. Resource-level values win on key conflicts. The practical consequence is safe incremental adoption. Existing resources with explicit tags remain unchanged, and new resources gain the baseline automatically.
Tag precedence table
| Layer | Scope | Precedence |
|---|---|---|
| Provider default_tags | All resources from provider instance | Lowest |
| Module or variable common tags | Passed via inputs | Middle |
| Resource-level tags | Specific resource block | Highest |
Auto Scaling Group Exception and Dynamic Launch Behavior
Due to the dynamic nature of Auto Scaling Groups, they behave differently than other AWS resources. The provider cannot propagate default_tags to instances launched by an Auto Scaling Group because those instances are created outside Terraform's direct management after the ASG is established.
The reference implementation notes:
hcl
resource "aws_instance" "web" {
ami = var.ami_id
instance_type = "t3.medium"
tags = {
Name = "web-server"
Service = "frontend"
OnCall = "web-team"
}
}
Resulting tags are Environment, ManagedBy, Project, Name, Service, OnCall when provider defaults are present. For an Auto Scaling Group, the tags present on the group itself may include default ASG tags but not the default tags from provider configuration.
The observed tag set includes system tags such as:
json
[
{
"Key": "aws:ec2launchtemplate:version",
"Value": "1"
},
{
"Key": "aws:autoscaling:groupName",
"Value": "terraform-20210720164457433400000003"
}
]
The impact for operations is that cost allocation and ownership metadata can be missing on the instances that actually consume compute. The workaround is to define tags explicitly on the ASG resource or to use the awsdefaulttags data source with a dynamic tag block, or to define a local and merge it explicitly into each resource.
Reprovisioning with replace is a common remediation path.
bash
terraform apply -replace aws_autoscaling_group.example
The command forces Terraform to recreate the Auto Scaling Group and launch a new instance with the appropriate tags. The trade-off is disruption to running instances and the need for careful rollout planning.
Variable Validation and Tag Standards Enforcement
Consistent tagging is enforced most effectively at the variable level so Terraform plans fail fast if required tags are missing. Variable validation ensures that environment names, team names, cost centers, and project names conform to organizational patterns before any resource is created.
hcl
variable "environment" {
type = string
description = "Environment name"
validation {
condition = contains(["production", "staging", "development", "sandbox"], var.environment)
error_message = "Environment must be one of: production, staging, development, sandbox."
}
}
hcl
variable "team_name" {
type = string
description = "Team that owns these resources"
validation {
condition = length(var.team_name) > 0 && length(var.team_name) <= 50
error_message = "Team name must be between 1 and 50 characters."
}
}
hcl
variable "cost_center" {
type = string
description = "Cost center for billing attribution"
validation {
condition = can(regex("^CC-[0-9]{4,6}$", var.cost_center))
error_message = "Cost center must match format CC-XXXX (e.g., CC-1234)."
}
}
hcl
variable "project_name" {
type = string
description = "Project name"
validation {
condition = can(regex("^[a-z][a-z0-9-]{2,29}$", var.project_name))
error_message = "Project name"
}
}
The impact is shift-left validation. Plans fail during validation rather than after deployment when audit findings appear. The contextual benefit is integration with organizational policies. When combined with default_tags, the variables supply the values that propagate to all resources, creating a single source of truth for tagging standards.
Default tags can also be expressed via variables for reuse.
hcl
variable "common_tags" {
type = map(string)
default = {
Environment = "Development"
}
}
Usage:
hcl
tags = var.common_tags
This pattern avoids repetition and ensures consistency across resources. Merging default and custom tags can be done with Terraform functions like merge() to combine the default tags with custom tags while giving priority to the custom ones.
Implementation Patterns and Provider Differences
Terraform default tags refer to tags applied to all or most of the resources in a configuration. They can be defined at a higher level through variables or modules to avoid repetition and ensure consistency across resources.
A typical composition pattern is:
- Override at the resource level by explicitly defining the tags argument in the resource definition.
- Merge default and custom tags using merge() to combine defaults with custom tags while giving priority to custom ones.
AWS has the most complete tagging support of the major providers. The default_tags block in the provider applies tags automatically to all supported resources, and any resource-level tags are merged on top, with resource-level values winning on key conflicts.
AzureRM provider v4.x does not support provider-level default tags. Every resource must define its tags explicitly using the tags block. Understanding each provider's handling of defaults, inheritance, and naming constraints prevents subtle misconfigurations that are easy to miss in a plan.
The operational implication is that multi-cloud teams must maintain different tagging strategies per provider. AWS configurations benefit from centralized defaults, while Azure configurations require explicit tag propagation through modules or wrapper locals.
Limitations and Practical Constraints
Defaulttags does not apply to all resources. Most notably awsautoscaling_group does not pick them up automatically. This is because ASGs dynamically create EC2 instances outside Terraform's direct management, so the provider cannot propagate defaults to the launched instances.
AWS imposes a limit of fifty tags per resource. The combination of provider defaults, module defaults, and resource-specific tags must remain under this ceiling. Exceeding the limit causes plan failures.
Tagging is often an afterthought. Without consistent tagging, resources cannot be attributed to teams, costs cannot be allocated, and compliance gaps cannot be closed. The default_tags feature combined with validation and organizational policies solves this problem at the infrastructure level by making tagging a default rather than an optional step.
External systems can interact with resource tags, such as Configuration Management Databases or cloud-added auto-generated tags. Ignoring changes to Terraform tags may be required when external systems manage tags independently.
Workflow Integration
The tutorial workflow supports both Terraform Community Edition and HCP Terraform. HCP Terraform is a platform to manage and execute Terraform projects and includes features like remote state and execution, structured plan output, workspace resource summaries, and more.
The tutorial assumes familiarity with Terraform and HCP Terraform workflows. New users complete Get Started tutorials first.
The default tags configuration enables consistent tagging for all AWS resources managed with Terraform, with the ability to override tags for a specific resource and to manage Auto Scaling group tags through explicit configuration.
Conclusion
Default tags in the Terraform AWS Provider provide a centralized, provider-level mechanism to enforce organizational tagging standards without repeating tag definitions across hundreds of resources. The feature reduces configuration drift, supports cost allocation and access control policies, and integrates with variable validation to fail plans early when standards are violated.
The precedence model guarantees that resource-level tags win on conflicts, preserving flexibility for exceptions while maintaining a baseline. The most significant operational boundary is Auto Scaling Groups, where dynamic instance launch prevents automatic propagation, requiring explicit tag definition or workarounds using data sources and merge functions.
When combined with validation rules for environment, team, cost center, and project names, default_tags shifts tagging enforcement from manual review to automated infrastructure checks. The result is fewer untagged resources, clearer ownership, and auditable cost attribution across the AWS estate managed by Terraform.