github.com/pdecat/terraform@v0.11.9-beta1/website/docs/state/purpose.html.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "State"
     4  sidebar_current: "docs-state-purpose"
     5  description: |-
     6    Terraform must store state about your managed infrastructure and configuration. This state is used by Terraform to map real world resources to your configuration, keep track of metadata, and to improve performance for large infrastructures.
     7  ---
     8  
     9  # Purpose of Terraform State
    10  
    11  State is a necessary requirement for Terraform to function. It is often
    12  asked if it is possible for Terraform to work without state, or for Terraform
    13  to not use state and just inspect cloud resources on every run. This page
    14  will help explain why Terraform state is required.
    15  
    16  As you'll see from the reasons below, state is required. And in the scenarios
    17  where Terraform may be able to get away without state, doing so would require
    18  shifting massive amounts of complexity from one place (state) to another place
    19  (the replacement concept).
    20  
    21  ## Mapping to the Real World
    22  
    23  Terraform requires some sort of database to map Terraform config to the real
    24  world. When you have a resource `resource "aws_instance" "foo"` in your
    25  configuration, Terraform uses this map to know that instance `i-abcd1234`
    26  is represented by that resource.
    27  
    28  For some providers like AWS, Terraform could theoretically use something like
    29  AWS tags. Early prototypes of Terraform actually had no state files and used
    30  this method. However, we quickly ran into problems. The first major issue was
    31  a simple one: not all resources support tags, and not all cloud providers
    32  support tags.
    33  
    34  Therefore, for mapping configuration to resources in the real world,
    35  Terraform uses its own state structure.
    36  
    37  ## Metadata
    38  
    39  Alongside the mappings between resources and remote objects, Terraform must
    40  also track metadata such as resource dependencies.
    41  
    42  Terraform typically uses the configuration to determine dependency order.
    43  However, when you delete a resource from a Terraform configuration, Terraform
    44  must know how to delete that resource. Terraform can see that a mapping exists
    45  for a resource not in your configuration and plan to destroy. However, since
    46  the configuration no longer exists, the order cannot be determined from the
    47  configuration alone.
    48  
    49  To ensure correct operation, Terraform retains a copy of the most recent set
    50  of dependencies within the state. Now Terraform can still determine the correct
    51  order for destruction from the state when you delete one or more items from
    52  the configuration.
    53  
    54  One way to avoid this would be for Terraform to know a required ordering
    55  between resource types. For example, Terraform could know that servers must be
    56  deleted before the subnets they are a part of. The complexity for this approach
    57  quickly explodes, however: in addition to Terraform having to understand the
    58  ordering semantics of every resource for every cloud, Terraform must also
    59  understand the ordering _across providers_.
    60  
    61  Terraform also stores other metadata for similar reasons, such as a pointer
    62  to the provider configuration that was most recently used with the resource
    63  in situations where multiple aliased providers are present.
    64  
    65  ## Performance
    66  
    67  In addition to basic mapping, Terraform stores a cache of the attribute
    68  values for all resources in the state. This is the most optional feature of
    69  Terraform state and is done only as a performance improvement.
    70  
    71  When running a `terraform plan`, Terraform must know the current state of
    72  resources in order to effectively determine the changes that it needs to make
    73  to reach your desired configuration.
    74  
    75  For small infrastructures, Terraform can query your providers and sync the
    76  latest attributes from all your resources. This is the default behavior
    77  of Terraform: for every plan and apply, Terraform will sync all resources in
    78  your state.
    79  
    80  For larger infrastructures, querying every resource is too slow. Many cloud
    81  providers do not provide APIs to query multiple resources at once, and the
    82  round trip time for each resource is hundreds of milliseconds. On top of this,
    83  cloud providers almost always have API rate limiting so Terraform can only
    84  request a certain number of resources in a period of time. Larger users
    85  of Terraform make heavy use of the `-refresh=false` flag as well as the
    86  `-target` flag in order to work around this. In these scenarios, the cached
    87  state is treated as the record of truth.
    88  
    89  ## Syncing
    90  
    91  In the default configuration, Terraform stores the state in a file in the
    92  current working directory where Terraform was run. This is okay for getting
    93  started, but when using Terraform in a team it is important for everyone
    94  to be working with the same state so that operations will be applied to the
    95  same remote objects.
    96  
    97  [Remote state](/docs/state/remote.html) is the recommended solution
    98  to this problem. With a fully-featured state backend, Terraform can use
    99  remote locking as a measure to avoid two or more different users accidentally
   100  running Terraform at the same time, and thus ensure that each Terraform run
   101  begins with the most recent updated state.