Add default tags in sub-modules

Terraform
1

I’ve been using the default_tags of aws provider for a while, super practical and saves so much code. I noticed that many submodules I write have all resources add the same tags to the default tags, by setting them in the tags property of the resource.

So I’m wondering if there is a way for a submodule to “extend” the parent’s aws provider that it inherits, with additional default tags, so that I could remove the tags property form almost every resource of every submodule.

Sounds like defining provider aliases in submodule is anti pattern, so approach of adding an aws provider block in submodule is no-go.

So the only other way I see is to define additional providers in the root module. But

  1. this is a fair bit of work: if your root module uses N submodules which each use M sub-submodules, you need N*M provider aliases!
  2. this seems to violate treating modules as black boxes: a submodule should be able to “customize” what it inherits (at least in terms of tags), without affecting the parent; a root module should not know details of a submodule.

Which technically means submodules should have their own providers, with syntax on each provider to specify whether it should inherit from one of the “passed in” providers, or be a “clean slate”.

Is there a better solution?

1 Like
2

Hi @schollii,

I can’t think of any way other than what you’ve already considered. Since default_tags is a property of the provider configuration, the only way to vary it between resources would be to declare multiple provider configurations.

For legacy reasons it is technically possible to declare a separate provider "aws" block inside a module, but I would not recommend doing so because if you ever want to remove the module from your configuration you’ll get into a tricky mess where you need to somehow avoid removing both the resources and the provider configuration at the same time, or else Terraform won’t have the configuration necessary to destroy the resources. We continue to support this really only for backward compatibility with very old modules that predate the ability to explicitly pass provider configuration from a parent module into a child module.

1 Like