github.com/muratcelep/terraform@v1.1.0-beta2-not-internal-4/website/docs/language/meta-arguments/module-providers.html.md (about) 1 --- 2 layout: "language" 3 page_title: "The Module providers Meta-Argument - Configuration Language" 4 description: "The providers meta-argument specifies which provider configurations from a parent module are available in a child module." 5 --- 6 7 # The Module `providers` Meta-Argument 8 9 In a [module call](/docs/language/modules/syntax.html) block, the 10 optional `providers` meta-argument specifies which 11 [provider configurations](/docs/language/providers/configuration.html) from the parent 12 module will be available inside the child module. 13 14 ```hcl 15 # The default "aws" configuration is used for AWS resources in the root 16 # module where no explicit provider instance is selected. 17 provider "aws" { 18 region = "us-west-1" 19 } 20 21 # An alternate configuration is also defined for a different 22 # region, using the alias "usw2". 23 provider "aws" { 24 alias = "usw2" 25 region = "us-west-2" 26 } 27 28 # An example child module is instantiated with the alternate configuration, 29 # so any AWS resources it defines will use the us-west-2 region. 30 module "example" { 31 source = "./example" 32 providers = { 33 aws = aws.usw2 34 } 35 } 36 ``` 37 38 ## Default Behavior: Inherit Default Providers 39 40 If the child module does not declare any [configuration aliases](/docs/language/modules/develop/providers.html#provider-aliases-within-modules), 41 the `providers` argument is optional. If you omit it, a child module inherits 42 all of the _default_ provider configurations from its parent module. (Default 43 provider configurations are ones that don't use the `alias` argument.) 44 45 If you specify a `providers` argument, it cancels this default behavior, and the 46 child module will _only_ have access to the provider configurations you specify. 47 48 ## Usage and Behavior 49 50 The value of `providers` is a map, where: 51 52 - The keys are the provider configuration names used inside the child module. 53 - The values are provider configuration names from the parent module. 54 55 Both keys and values should be unquoted references to provider configurations. 56 For default configurations, this is the local name of the provider; for 57 alternate configurations, this is a `<PROVIDER>.<ALIAS>` reference. 58 59 Within a child module, resources are assigned to provider configurations as 60 normal — either Terraform chooses a default based on the name of the resource 61 type, or the resource specifies an alternate configuration with the `provider` 62 argument. If the module receives a `providers` map when it's called, the 63 provider configuration names used within the module are effectively remapped to 64 refer the specified configurations from the parent module. 65 66 ## When to Specify Providers 67 68 There are two main reasons to use the `providers` argument: 69 70 - Using different default provider configurations for a child module. 71 - Configuring a module that requires multiple configurations of the same provider. 72 73 ### Changing Default Provider Configurations 74 75 Most re-usable modules only use default provider configurations, which they can 76 automatically inherit from their caller when `providers` is omitted. 77 78 However, in Terraform configurations that use multiple configurations of the 79 same provider, you might want some child modules to use the default provider 80 configuration and other ones to use an alternate. (This usually happens when 81 using one configuration to manage resources in multiple different regions of the 82 same cloud provider.) 83 84 By using the `providers` argument (like in the code example above), you can 85 accommodate this without needing to edit the child module. Although the code 86 within the child module always refers to the default provider configuration, the 87 actual configuration of that default can be different for each instance. 88 89 ### Modules With Alternate Provider Configurations 90 91 In rare cases, a single re-usable module might require multiple configurations 92 of the same provider. For example, a module that configures connectivity between 93 networks in two AWS regions is likely to need both a source and a destination 94 region. In that case, the root module may look something like this: 95 96 ```hcl 97 provider "aws" { 98 alias = "usw1" 99 region = "us-west-1" 100 } 101 102 provider "aws" { 103 alias = "usw2" 104 region = "us-west-2" 105 } 106 107 module "tunnel" { 108 source = "./tunnel" 109 providers = { 110 aws.src = aws.usw1 111 aws.dst = aws.usw2 112 } 113 } 114 ``` 115 116 Non-default provider configurations are never automatically inherited, so any 117 module that works like this will always need a `providers` argument. The 118 documentation for the module should specify all of the provider configuration 119 names it needs. 120 121 ## More Information for Module Developers 122 123 For more details and guidance about working with providers inside a re-usable 124 child module, see 125 [Module Development: Providers Within Modules](/docs/language/modules/develop/providers.html).