Terraform providers are plugins that enable Terraform to interact with cloud platforms, SaaS providers, and other APIs. Terraform sources providers from the Terraform registry by default, which hosts providers maintained by HashiCorp, our partners, and community members. Each provider supports a set of resource types and data sources that you can manage with Terraform.

To use Terraform to manage resources for your chosen cloud platform, you must first install the corresponding provider and configure authentication. With the provider installed, you can use Terraform to create and manage the resources it supports. Provider configuration is the link between HCL configuration files and the APIs of cloud platforms, SaaS services, and other infrastructure systems. They are the backbone of infrastructure as code. How well you configure, manage, and version them decides whether your deployments stay reproducible as your team and infrastructure grow.

A Terraform provider is a plugin that lets Terraform talk to a specific cloud provider such as AWS, Azure, Google Cloud, a SaaS platform, an API, or any external service with a REST or gRPC interface. The provider configuration tells Terraform how to authenticate and connect to those services. Without a configured provider, Terraform has no way to manage your resources. Each provider plugin adds a set of resource types and data sources that your infrastructure code can then manage.

Providers handle authentication, connection, and the translation of Terraform operations into provider specific API calls. Provider configuration takes two steps: declare the required providers, then configure them. Provider requirements are defined in the required_providers block within the top-level terraform block.

Provider Requirements and Versioning

Provider requirements say, for example, "This module requires version v2.7.0 of the provider hashicorp/aws and will refer to it as aws." It does not, however, specify any of the configuration settings that determine what remote endpoints the provider will access, such as an AWS region; configuration settings come from provider configurations, and a particular overall Terraform configuration can potentially have several different configurations for the same provider.

To declare that a module requires particular versions of a specific provider, use a required_providers block inside a terraform block:

hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = ">= 2.7.0" } } }

Although provider configurations are shared between modules, each module must declare its own provider requirements, so that Terraform can ensure that there is a single version of the provider that is compatible with all modules in the configuration and to specify the source address that serves as the global module-agnostic identifier for a provider.

To declare multiple configuration names for a provider within a module, add the configuration_aliases argument:

hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = ">= 2.7.0" configuration_aliases = ["east", "west"] } } }

Versioning and source pinning is critical for safe upgrades. In practice you will source and version providers from the Terraform registry, configure and authenticate providers, and upgrade provider versions safely. You can complete a tutorial using AWS, Azure, or Google Cloud Platform.

Provider Installation and Initialization

When a module is added to a configuration, Terraform installs each instance of a module in its own directory in your local workspace, since each instance of the module can be a different version.

bash $ terraform init Initializing the backend... Initializing modules... Downloading registry.terraform.io/terraform-aws-modules/s3-bucket/aws 5.2.0 for website_east... - website_east in .terraform/modules/website_east Initializing provider plugins... - Reusing previous version of hashicorp/aws from the dependency lock file - Using previously-installed hashicorp/aws v6.6.0 Terraform has been successfully initialized! You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work. If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary.

Provider Configurations Are Global

Provider configurations, unlike most other concepts in Terraform, are global to an entire Terraform configuration and can be shared across module boundaries. Provider configurations can be defined only in a root Terraform module.

Each resource in the configuration must be associated with one provider configuration. Provider configurations are used for all operations on associated resources, including destroying remote objects and refreshing state. Terraform retains, as part of its state, a reference to the provider configuration that was most recently used to apply changes to each resource.

If Terraform finds a resource instance tracked in the state whose provider configuration block is no longer available then it will return an error during planning, prompting you to reintroduce the provider configuration.

The global nature of provider configurations means that a child module will automatically use the same default provider configuration as your root module. Sometimes you need multiple configurations of the same provider in your workspace. For example, you might want to create resources in multiple regions or use different authentication credentials.

Providers Within Modules

In a configuration with multiple modules, there are some special considerations for how resources are associated with provider configurations.

Each resource in the configuration must be associated with one provider configuration. Provider configurations, unlike most other concepts in Terraform, are global to an entire Terraform configuration and can be shared across module boundaries. Provider configurations can be defined only in a root Terraform module.

Providers can be passed down to descendant modules in two ways: either implicitly through inheritance, or explicitly via the providers argument within a module block. These two options are discussed in more detail in the following sections.

A module intended to be called by one or more other modules must not contain any provider blocks. A module containing its own provider configurations is not compatible with the foreach, count, and dependson arguments that were introduced in Terraform v0.13. For more information, see Legacy Shared Modules with Provider Configurations.

Implicit Inheritance and Explicit Passing

There are exactly two ways a module gets its provider configuration:

Implicit inheritance - The module automatically gets the default non-aliased provider from its parent
Explicit passing - The caller uses the providers argument to map specific provider configurations to the module

Understanding when each applies is the key to getting provider configuration right.

Implicit Inheritance

When you do not specify a providers argument, the module inherits the default provider from the calling module:

```hcl
provider "aws" {
region = "us-east-1"
}

module "vpc" {
source = "./modules/vpc"
cidr = "10.0.0.0/16"
}
```

Inside the vpc module, any aws_* resource uses the inherited provider. No additional configuration needed. Implicit inheritance only works for the default non-aliased provider.

If you configure a default AWS provider in the root module, the child module will automatically use the same default provider configuration as your root module. Resources, data sources, and modules without an explicit provider argument use the default non-aliased provider. All provider blocks will use the same version of the given provider.

Explicit Provider Passing

Modules use the providers argument to map provider aliases to their internal provider requirements. This is required when you need multiple configurations of the same provider, such as different regions or credentials.

```hcl
provider "aws" {
alias = "west"
region = "us-west-2"
}

module "website" {
source = "./modules/website"
providers = {
aws = aws.west
}
}
```

Explicit passing is the mechanism for controlling which providers your Terraform modules use to provision infrastructure. It is the only way to provide an aliased provider to a module.

Provider Aliases and Multi Region Patterns

You might want to create resources in multiple regions or use different authentication credentials. Aliases allow multiple configurations of the same provider.

Provider configuration in Terraform modules can be confusing because it works differently depending on whether you use aliased providers, whether the module declares its own provider requirements, and whether you are calling the module from the root or from another module.

A practical example with two regions:

```hcl
provider "aws" {
region = "us-east-1"
}

provider "aws" {
alias = "west"
region = "us-west-2"
}

module "website_east" {
source = "registry.terraform.io/terraform-aws-modules/s3-bucket/aws"
providers = {
aws = aws
}
}

module "website_west" {
source = "registry.terraform.io/terraform-aws-modules/s3-bucket/aws"
providers = {
aws = aws.west
}
}
```

When the configuration is applied, Terraform will perform the following actions:

```hcl

module.website.awss3bucket.this[0] will be created

resource "awss3bucket" "this" {
acceleration_status = (known after apply)
acl = (known after apply)
arn = (known after apply)
...
}
Plan: 2 to add, 0 to change, 0 to destroy.
```

Apply completes resources for both regions using the mapped provider configurations.

Module Provider Requirements Table

Concept	Definition
Provider requirement	Declares source and version for a provider, e.g. hashicorp/aws >= 2.7.0
Provider configuration	Declares authentication and connection settings, e.g. region, credentials
Implicit inheritance	Module receives default provider automatically when providers argument is omitted
Explicit passing	Caller maps provider alias to module via providers argument
Module rule	Module must not contain provider blocks; provider configs belong only in root

Best Practices for Enterprise Use

How well you configure, manage, and version them decides whether your deployments stay reproducible as your team and infrastructure grow. Whether you're on Terraform or the open-source OpenTofu fork, the configuration model is identical. Both use the same provider plugin protocol.

A Terraform provider is a plugin that lets Terraform talk to a specific cloud provider, a SaaS platform, an API, or any external service with a REST or gRPC interface. The provider configuration tells Terraform how to authenticate and connect to those services.

Providers handle authentication, connection, and resource type exposure. Each provider plugin adds a set of resource types and data sources that your infrastructure code can then manage.

For enterprise environments:

Declare required_providers in every module to lock source and version.
Define provider configurations only in the root module.
Use aliases for multi-region, multi-account, or multi-credential scenarios.
Pass providers explicitly to modules when using aliases.
Run terraform init after changing modules or provider requirements.
Keep provider configurations stable in state to avoid planning errors.

The two ways providers reach modules are implicit inheritance for the default provider and explicit passing via the providers argument. Provider configurations are global, shared between modules, and defined only in root. Modules declare their own requirements but receive configuration from the caller.

Conclusion

Terraform provider module interactions are governed by a clear separation between requirements and configuration. Provider requirements are declared per module with required_providers and ensure a compatible version is used across the configuration. Provider configurations are global, defined only in root, and shared across module boundaries.

Implicit inheritance provides the default provider automatically, which simplifies most module calls. Explicit passing via the providers argument gives precise control over which provider configuration a module uses, enabling patterns such as multi-region deployments, cross-account access, and aliased providers.

Keeping provider blocks out of reusable modules preserves compatibility with foreach, count, and dependson, and avoids state lock-in. Versioning providers from the Terraform registry, pinning sources, and re-initializing after changes ensures reproducible infrastructure as code. Mastering the interplay between required_providers, provider configurations, aliases, and the providers argument is the foundation for reliable, scalable Terraform module design.

Terraform Provider Modules and Configuration Patterns