github.com/rstandt/terraform@v0.12.32-0.20230710220336-b1063613405c/website/docs/configuration/data-sources.html.md (about) 1 --- 2 layout: "docs" 3 page_title: "Data Sources - Configuration Language" 4 sidebar_current: "docs-config-data-sources" 5 description: |- 6 Data sources allow data to be fetched or computed for use elsewhere in Terraform configuration. 7 --- 8 9 # Data Sources 10 11 -> **Note:** This page is about Terraform 0.12 and later. For Terraform 0.11 and 12 earlier, see 13 [0.11 Configuration Language: Data Sources](../configuration-0-11/data-sources.html). 14 15 _Data sources_ allow data to be fetched or computed for use elsewhere 16 in Terraform configuration. Use of data sources allows a Terraform 17 configuration to make use of information defined outside of Terraform, 18 or defined by another separate Terraform configuration. 19 20 Each [provider](./providers.html) may offer data sources 21 alongside its set of [resource types](./resources.html#resource-types-and-arguments). 22 23 ## Using Data Sources 24 25 A data source is accessed via a special kind of resource known as a 26 _data resource_, declared using a `data` block: 27 28 ```hcl 29 data "aws_ami" "example" { 30 most_recent = true 31 32 owners = ["self"] 33 tags = { 34 Name = "app-server" 35 Tested = "true" 36 } 37 } 38 ``` 39 40 A `data` block requests that Terraform read from a given data source ("aws_ami") 41 and export the result under the given local name ("example"). The name is used 42 to refer to this resource from elsewhere in the same Terraform module, but has 43 no significance outside of the scope of a module. 44 45 The data source and name together serve as an identifier for a given 46 resource and so must be unique within a module. 47 48 Within the block body (between `{` and `}`) are query constraints defined by 49 the data source. Most arguments in this section depend on the 50 data source, and indeed in this example `most_recent`, `owners` and `tags` are 51 all arguments defined specifically for [the `aws_ami` data source](/docs/providers/aws/d/ami.html). 52 53 When distinguishing from data resources, the primary kind of resource (as declared 54 by a `resource` block) is known as a _managed resource_. Both kinds of resources 55 take arguments and export attributes for use in configuration, but while 56 managed resources cause Terraform to create, update, and delete infrastructure 57 objects, data resources cause Terraform only to _read_ objects. For brevity, 58 managed resources are often referred to just as "resources" when the meaning 59 is clear from context. 60 61 ## Data Source Arguments 62 63 Each data resource is associated with a single data source, which determines 64 the kind of object (or objects) it reads and what query constraint arguments 65 are available. 66 67 Each data source in turn belongs to a [provider](./providers.html), 68 which is a plugin for Terraform that offers a collection of resource types and 69 data sources that most often belong to a single cloud or on-premises 70 infrastructure platform. 71 72 Most of the items within the body of a `data` block are defined by and 73 specific to the selected data source, and these arguments can make full 74 use of [expressions](./expressions.html) and other dynamic 75 Terraform language features. 76 77 However, there are some "meta-arguments" that are defined by Terraform itself 78 and apply across all data sources. These arguments often have additional 79 restrictions on what language features can be used with them, and are described 80 in more detail in the following sections. 81 82 ## Data Resource Behavior 83 84 If the query constraint arguments for a data resource refer only to constant 85 values or values that are already known, the data resource will be read and its 86 state updated during Terraform's "refresh" phase, which runs prior to creating a plan. 87 This ensures that the retrieved data is available for use during planning and 88 so Terraform's plan will show the actual values obtained. 89 90 Query constraint arguments may refer to values that cannot be determined until 91 after configuration is applied, such as the id of a managed resource that has 92 not been created yet. In this case, reading from the data source is deferred 93 until the apply phase, and any references to the results of the data resource 94 elsewhere in configuration will themselves be unknown until after the 95 configuration has been applied. 96 97 ## Local-only Data Sources 98 99 While many data sources correspond to an infrastructure object type that 100 is accessed via a remote network API, some specialized data sources operate 101 only within Terraform itself, calculating some results and exposing them 102 for use elsewhere. 103 104 For example, local-only data sources exist for 105 [rendering templates](/docs/providers/template/d/file.html), 106 [reading local files](/docs/providers/local/d/file.html), and 107 [rendering AWS IAM policies](/docs/providers/aws/d/iam_policy_document.html). 108 109 The behavior of local-only data sources is the same as all other data 110 sources, but their result data exists only temporarily during a Terraform 111 operation, and is re-calculated each time a new plan is created. 112 113 ## Data Resource Dependencies 114 115 Data resources have the same dependency resolution behavior 116 [as defined for managed resources](./resources.html#resource-dependencies). 117 118 In particular, the `depends_on` meta-argument is also available within `data` 119 blocks, with the same meaning and syntax as in `resource` blocks. 120 121 However, due to the data resource behavior of deferring the read until the 122 apply phase when depending on values that are not yet known, using `depends_on` 123 with data resources will force the read to _always_ be deferred to the apply 124 phase, and therefore a configuration that uses `depends_on` with a data 125 resource can never converge. 126 127 Due to this behavior, we do not recommend using `depends_on` with data 128 resources. 129 130 ## Multiple Resource Instances 131 132 Data resources support [`count`](./resources.html#count-multiple-resource-instances-by-count) 133 and [`for_each`](./resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings) 134 meta-arguments as defined for managed resources, with the same syntax and behavior. 135 136 As with managed resources, when `count` or `for_each` is present it is important to 137 distinguish the resource itself from the multiple resource _instances_ it 138 creates. Each instance will separately read from its data source with its 139 own variant of the constraint arguments, producing an indexed result. 140 141 ## Selecting a Non-default Provider Configuration 142 143 Data resources support [the `providers` meta-argument](./resources.html#provider-selecting-a-non-default-provider-configuration) 144 as defined for managed resources, with the same syntax and behavior. 145 146 ## Lifecycle Customizations 147 148 Data resources do not currently have any customization settings available 149 for their lifecycle, but the `lifecycle` nested block is reserved in case 150 any are added in future versions. 151 152 ## Example 153 154 A data source configuration looks like the following: 155 156 ```hcl 157 # Find the latest available AMI that is tagged with Component = web 158 data "aws_ami" "web" { 159 filter { 160 name = "state" 161 values = ["available"] 162 } 163 164 filter { 165 name = "tag:Component" 166 values = ["web"] 167 } 168 169 most_recent = true 170 } 171 ``` 172 173 ## Description 174 175 The `data` block creates a data instance of the given _type_ (first 176 block label) and _name_ (second block label). The combination of the type 177 and name must be unique. 178 179 Within the block (the `{ }`) is configuration for the data instance. The 180 configuration is dependent on the type, and is documented for each 181 data source in the [providers section](/docs/providers/index.html). 182 183 Each data instance will export one or more attributes, which can be 184 used in other resources as reference expressions of the form 185 `data.<TYPE>.<NAME>.<ATTRIBUTE>`. For example: 186 187 ```hcl 188 resource "aws_instance" "web" { 189 ami = data.aws_ami.web.id 190 instance_type = "t1.micro" 191 } 192 ``` 193 194 ## Meta-Arguments 195 196 As data sources are essentially a read only subset of resources, they also 197 support the same [meta-arguments](./resources.html#meta-arguments) of resources 198 with the exception of the 199 [`lifecycle` configuration block](./resources.html#lifecycle-lifecycle-customizations). 200 201 ### Multiple Provider Instances 202 203 Similarly to [resources](./resources.html), the 204 `provider` meta-argument can be used where a configuration has 205 multiple aliased instances of the same provider: 206 207 ```hcl 208 data "aws_ami" "web" { 209 provider = "aws.west" 210 211 # ... 212 } 213 ``` 214 215 See [Resources: Multiple Provider Instances](./resources.html#provider-selecting-a-non-default-provider-configuration) 216 for more information. 217 218 ### Data Source Lifecycle 219 220 If the arguments of a data instance contain no references to computed values, 221 such as attributes of resources that have not yet been created, then the 222 data instance will be read and its state updated during Terraform's "refresh" 223 phase, which by default runs prior to creating a plan. This ensures that the 224 retrieved data is available for use during planning and the diff will show 225 the real values obtained. 226 227 Data instance arguments may refer to computed values, in which case the 228 attributes of the instance itself cannot be resolved until all of its 229 arguments are defined. In this case, refreshing the data instance will be 230 deferred until the "apply" phase, and all interpolations of the data instance 231 attributes will show as "computed" in the plan since the values are not yet 232 known.