github.com/danp/terraform@v0.9.5-0.20170426144147-39d740081351/website/source/docs/configuration/providers.html.md (about) 1 --- 2 layout: "docs" 3 page_title: "Configuring Providers" 4 sidebar_current: "docs-config-providers" 5 description: |- 6 Providers are responsible in Terraform for managing the lifecycle of a resource: create, read, update, delete. 7 --- 8 9 # Provider Configuration 10 11 Providers are responsible in Terraform for managing the lifecycle 12 of a [resource](/docs/configuration/resources.html): create, 13 read, update, delete. 14 15 Every resource in Terraform is mapped to a provider based 16 on longest-prefix matching. For example the `aws_instance` 17 resource type would map to the `aws` provider (if that exists). 18 19 Most providers require some sort of configuration to provide 20 authentication information, endpoint URLs, etc. Provider configuration 21 blocks are a way to set this information globally for all 22 matching resources. 23 24 This page assumes you're familiar with the 25 [configuration syntax](/docs/configuration/syntax.html) 26 already. 27 28 ## Example 29 30 A provider configuration looks like the following: 31 32 ```hcl 33 provider "aws" { 34 access_key = "foo" 35 secret_key = "bar" 36 region = "us-east-1" 37 } 38 ``` 39 40 ## Description 41 42 The `provider` block configures the provider of the given `NAME`. 43 Multiple provider blocks can be used to configure multiple providers. 44 45 Terraform matches providers to resources by matching two criteria. 46 Both criteria must be matched for a provider to manage a resource: 47 48 - They must share a common prefix. Longest matching prefixes are tried first. 49 For example, `aws_instance` would choose the `aws` provider. 50 51 - The provider must report that it supports the given resource type. Providers 52 internally tell Terraform the list of resources they support. 53 54 Within the block (the `{ }`) is configuration for the resource. 55 The configuration is dependent on the type, and is documented 56 [for each provider](/docs/providers/index.html). 57 58 ## Multiple Provider Instances 59 60 You can define multiple instances of the same provider in order to support 61 multiple regions, multiple hosts, etc. The primary use case for this is 62 utilizing multiple cloud regions. Other use cases include targeting multiple 63 Docker hosts, multiple Consul hosts, etc. 64 65 To define multiple provider instances, repeat the provider configuration 66 multiple times, but set the `alias` field and name the provider. For 67 example: 68 69 ```hcl 70 # The default provider 71 provider "aws" { 72 # ... 73 } 74 75 # West coast region 76 provider "aws" { 77 alias = "west" 78 region = "us-west-2" 79 } 80 ``` 81 82 After naming a provider, you reference it in resources with the `provider` 83 field: 84 85 ```hcl 86 resource "aws_instance" "foo" { 87 provider = "aws.west" 88 89 # ... 90 } 91 ``` 92 93 If a provider isn't specified, then the default provider configuration 94 is used (the provider configuration with no `alias` set). The value of the 95 `provider` field is `TYPE.ALIAS`, such as "aws.west" above. 96 97 ## Syntax 98 99 The full syntax is: 100 101 ```text 102 provider NAME { 103 CONFIG ... 104 [alias = ALIAS] 105 } 106 ``` 107 108 where `CONFIG` is: 109 110 ```text 111 KEY = VALUE 112 113 KEY { 114 CONFIG 115 } 116 ``` 117 118 ## Interpolation 119 Providers support [interpolation syntax](/docs/configuration/interpolation.html) allowing dynamic configuration at run time. 120 121 ```hcl 122 provider "aws" { 123 region = "${var.aws_region}" 124 } 125 ``` 126 127 -> **NOTE:** Because providers are one of the first things loaded when Terraform parses the graph, it is not possible to use the output from modules or resources as inputs to the provider. At this time, only [variables](/docs/configuration/variables.html) and [data sources](/docs/configuration/data-sources.html), including [remote state](/docs/providers/terraform/d/remote_state.html) may be used in an interpolation inside a provider stanza.