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.