diff --git a/website/docs/cli/code/index.html.md b/website/docs/cli/code/index.html.md
index ba05a8940571..3c72083c4636 100644
--- a/website/docs/cli/code/index.html.md
+++ b/website/docs/cli/code/index.html.md
@@ -15,7 +15,7 @@ potentially save you time and effort.
- [The `terraform console` command](/docs/commands/console.html) starts an
interactive shell for evaluating Terraform
- [expressions](/docs/configuration/expressions.html), which can be a faster way
+ [expressions](/docs/configuration/expressions/index.html), which can be a faster way
to verify that a particular resource argument results in the value you expect.
diff --git a/website/docs/commands/0.12upgrade.html.markdown b/website/docs/commands/0.12upgrade.html.markdown
index 1136599b7711..0499e5eec4c4 100644
--- a/website/docs/commands/0.12upgrade.html.markdown
+++ b/website/docs/commands/0.12upgrade.html.markdown
@@ -71,7 +71,7 @@ the change.
Once upgraded the configuration will no longer be compatible with Terraform
v0.11 and earlier. When upgrading a shared module that is called from multiple
configurations, you may need to
-[fix existing configurations to a previous version](/docs/configuration/modules.html#module-versions)
+[fix existing configurations to a previous version](/docs/configuration/blocks/modules/syntax.html#version)
to allow for a gradual upgrade. If the module is published via
[a Terraform registry](/docs/registry/), assign a new _major_ version number
to the upgraded module source to represent the fact that this is a breaking
diff --git a/website/docs/commands/console.html.markdown b/website/docs/commands/console.html.markdown
index 511f8516462a..5e146c79181e 100644
--- a/website/docs/commands/console.html.markdown
+++ b/website/docs/commands/console.html.markdown
@@ -10,14 +10,14 @@ description: |-
# Command: console
The `terraform console` command provides an interactive console for
-evaluating [expressions](/docs/configuration/expressions.html).
+evaluating [expressions](/docs/configuration/expressions/index.html).
## Usage
Usage: `terraform console [options]`
This command provides an interactive command-line console for evaluating and
-experimenting with [expressions](/docs/configuration/expressions.html).
+experimenting with [expressions](/docs/configuration/expressions/index.html).
This is useful for testing interpolations before using them in configurations,
and for interacting with any values currently saved in
[state](/docs/state/index.html).
diff --git a/website/docs/commands/import.html.md b/website/docs/commands/import.html.md
index 7ae3568181b4..c29fa90e2b3c 100644
--- a/website/docs/commands/import.html.md
+++ b/website/docs/commands/import.html.md
@@ -133,7 +133,7 @@ $ terraform import module.foo.aws_instance.bar i-abcd1234
## Example: Import into Resource configured with count
The example below will import an AWS instance into the first instance of the `aws_instance` resource named `baz` configured with
-[`count`](/docs/configuration/resources.html#count-multiple-resource-instances-by-count):
+[`count`](/docs/configuration/meta-arguments/count.html):
```shell
$ terraform import 'aws_instance.baz[0]' i-abcd1234
@@ -142,7 +142,7 @@ $ terraform import 'aws_instance.baz[0]' i-abcd1234
## Example: Import into Resource configured with for_each
The example below will import an AWS instance into the `"example"` instance of the `aws_instance` resource named `baz` configured with
-[`for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings):
+[`for_each`](/docs/configuration/meta-arguments/for_each.html):
Linux, Mac OS, and UNIX:
diff --git a/website/docs/commands/state/mv.html.md b/website/docs/commands/state/mv.html.md
index 41118ed0f11b..ce5f7449c3c7 100644
--- a/website/docs/commands/state/mv.html.md
+++ b/website/docs/commands/state/mv.html.md
@@ -95,7 +95,7 @@ $ terraform state mv -state-out=other.tfstate 'module.app' 'module.app'
## Example: Move a Resource configured with count
The example below moves the first instance of a `packet_device` resource named `worker` configured with
-[`count`](/docs/configuration/resources.html#count-multiple-resource-instances-by-count) to
+[`count`](/docs/configuration/meta-arguments/count.html) to
the first instance of a resource named `helper` also configured with `count`:
```shell
@@ -105,7 +105,7 @@ $ terraform state mv 'packet_device.worker[0]' 'packet_device.helper[0]'
## Example: Move a Resource configured with for_each
The example below moves the `"example123"` instance of a `packet_device` resource named `worker` configured with
-[`for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
+[`for_each`](/docs/configuration/meta-arguments/for_each.html)
to the `"example456"` instance of a resource named `helper` also configuring `for_each`:
Linux, Mac OS, and UNIX:
diff --git a/website/docs/commands/state/rm.html.md b/website/docs/commands/state/rm.html.md
index f153320e6ca3..3930821dbc62 100644
--- a/website/docs/commands/state/rm.html.md
+++ b/website/docs/commands/state/rm.html.md
@@ -78,7 +78,7 @@ $ terraform state rm 'module.foo.packet_device.worker'
## Example: Remove a Resource configured with count
The example below removes the first instance of a `packet_device` resource named `worker` configured with
-[`count`](/docs/configuration/resources.html#count-multiple-resource-instances-by-count):
+[`count`](/docs/configuration/meta-arguments/count.html):
```shell
$ terraform state rm 'packet_device.worker[0]'
@@ -87,7 +87,7 @@ $ terraform state rm 'packet_device.worker[0]'
## Example: Remove a Resource configured with for_each
The example below removes the `"example"` instance of a `packet_device` resource named `worker` configured with
-[`for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings):
+[`for_each`](/docs/configuration/meta-arguments/for_each.html):
Linux, Mac OS, and UNIX:
diff --git a/website/docs/commands/state/show.html.md b/website/docs/commands/state/show.html.md
index da95b3822662..85f53d95ce75 100644
--- a/website/docs/commands/state/show.html.md
+++ b/website/docs/commands/state/show.html.md
@@ -61,7 +61,7 @@ $ terraform state show 'module.foo.packet_device.worker'
## Example: Show a Resource configured with count
The example below shows the first instance of a `packet_device` resource named `worker` configured with
-[`count`](/docs/configuration/resources.html#count-multiple-resource-instances-by-count):
+[`count`](/docs/configuration/meta-arguments/count.html):
```shell
$ terraform state show 'packet_device.worker[0]'
@@ -70,7 +70,7 @@ $ terraform state show 'packet_device.worker[0]'
## Example: Show a Resource configured with for_each
The example below shows the `"example"` instance of a `packet_device` resource named `worker` configured with
-[`for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings):
+[`for_each`](/docs/configuration/meta-arguments/for_each.html):
Linux, Mac OS, and UNIX:
diff --git a/website/docs/configuration-0-11/interpolation.html.md b/website/docs/configuration-0-11/interpolation.html.md
index 8da16e154a8a..7178cd215e3a 100644
--- a/website/docs/configuration-0-11/interpolation.html.md
+++ b/website/docs/configuration-0-11/interpolation.html.md
@@ -10,7 +10,7 @@ description: |-
-> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
and later, see
-[Configuration Language: Expressions](../configuration/expressions.html) and
+[Configuration Language: Expressions](/docs/configuration/expressions/index.html) and
[Configuration Language: Functions](../configuration/functions.html).
Embedded within strings in Terraform, whether you're using the
diff --git a/website/docs/configuration/attr-as-blocks.html.md b/website/docs/configuration/attr-as-blocks.html.md
index d9b95deacaa5..de4778675240 100644
--- a/website/docs/configuration/attr-as-blocks.html.md
+++ b/website/docs/configuration/attr-as-blocks.html.md
@@ -153,7 +153,7 @@ example = [
For the arguments that use the attributes-as-blocks usage mode, the above is
a better pattern than using
-[`dynamic` blocks](/docs/configuration/expressions.html#dynamic-blocks)
+[`dynamic` blocks](/docs/configuration/expressions/dynamic-blocks.html)
because the case where the
caller provides an empty list will result in explicitly assigning an empty
list value, rather than assigning no value at all and thus retaining and
diff --git a/website/docs/configuration/blocks/modules/index.html.md b/website/docs/configuration/blocks/modules/index.html.md
index bdb1a317beaa..e5f756102a30 100644
--- a/website/docs/configuration/blocks/modules/index.html.md
+++ b/website/docs/configuration/blocks/modules/index.html.md
@@ -48,12 +48,20 @@ module registry for sharing modules internally within your organization.
## Using Modules
-- [Module Blocks](/docs/configuration/modules.html) documents the syntax for
+- [Module Blocks](/docs/configuration/blocks/modules/syntax.html) documents the syntax for
calling a child module from a parent module, including meta-arguments like
`for_each`.
+
- [Module Sources](/docs/modules/sources.html) documents what kinds of paths,
addresses, and URIs can be used in the `source` argument of a module block.
+- The Meta-Arguments section documents special arguments that can be used with
+ every module, including
+ [`providers`](/docs/configuration/meta-arguments/module-providers.html),
+ [`depends_on`](/docs/configuration/meta-arguments/depends_on.html),
+ [`count`](/docs/configuration/meta-arguments/count.html),
+ and [`for_each`](/docs/configuration/meta-arguments/for_each.html).
+
## Developing Modules
For information about developing reusable modules, see
diff --git a/website/docs/configuration/blocks/modules/syntax.html.md b/website/docs/configuration/blocks/modules/syntax.html.md
new file mode 100644
index 000000000000..04d05b84ca71
--- /dev/null
+++ b/website/docs/configuration/blocks/modules/syntax.html.md
@@ -0,0 +1,201 @@
+---
+layout: "language"
+page_title: "Modules - Configuration Language"
+sidebar_current: "docs-config-modules"
+description: |-
+ Modules allow multiple resources to be grouped together and encapsulated.
+---
+
+# Module Blocks
+
+-> **Note:** This page is about Terraform 0.12 and later. For Terraform 0.11 and
+earlier, see
+[0.11 Configuration Language: Modules](../configuration-0-11/modules.html).
+
+> **Hands-on:** Try the [Reuse Configuration with Modules](https://learn.hashicorp.com/collections/terraform/modules?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) collection on HashiCorp Learn.
+
+A _module_ is a container for multiple resources that are used together.
+
+Every Terraform configuration has at least one module, known as its
+_root module_, which consists of the resources defined in the `.tf` files in
+the main working directory.
+
+A module can call other modules, which lets you include the child module's
+resources into the configuration in a concise way. Modules
+can also be called multiple times, either within the same configuration or
+in separate configurations, allowing resource configurations to be packaged
+and re-used.
+
+This page describes how to call one module from another. For more information
+about creating re-usable child modules, see [Module Development](/docs/modules/index.html).
+
+## Calling a Child Module
+
+To _call_ a module means to include the contents of that module into the
+configuration with specific values for its
+[input variables](/docs/configuration/variables.html). Modules are called
+from within other modules using `module` blocks:
+
+```hcl
+module "servers" {
+ source = "./app-cluster"
+
+ servers = 5
+}
+```
+
+A module that includes a `module` block like this is the _calling module_ of the
+child module.
+
+The label immediately after the `module` keyword is a local name, which the
+calling module can use to refer to this instance of the module.
+
+Within the block body (between `{` and `}`) are the arguments for the module.
+Module calls use the following kinds of arguments:
+
+- The `source` argument is mandatory for all modules.
+
+- The `version` argument is recommended for modules from a registry.
+
+- Most other arguments correspond to [input variables](/docs/configuration/variables.html)
+ defined by the module. (The `servers` argument in the example above is one of
+ these.)
+
+- Terraform defines a few other meta-arguments that can be used with all
+ modules, including `for_each` and `depends_on`.
+
+### Source
+
+All modules **require** a `source` argument, which is a meta-argument defined by
+Terraform. Its value is either the path to a local directory containing the
+module's configuration files, or a remote module source that Terraform should
+download and use. This value must be a literal string with no template
+sequences; arbitrary expressions are not allowed. For more information on
+possible values for this argument, see [Module Sources](/docs/modules/sources.html).
+
+The same source address can be specified in multiple `module` blocks to create
+multiple copies of the resources defined within, possibly with different
+variable values.
+
+After adding, removing, or modifying `module` blocks, you must re-run
+`terraform init` to allow Terraform the opportunity to adjust the installed
+modules. By default this command will not upgrade an already-installed module;
+use the `-upgrade` option to instead upgrade to the newest available version.
+
+### Version
+
+When using modules installed from a module registry, we recommend explicitly
+constraining the acceptable version numbers to avoid unexpected or unwanted
+changes.
+
+Use the `version` argument in the `module` block to specify versions:
+
+```shell
+module "consul" {
+ source = "hashicorp/consul/aws"
+ version = "0.0.5"
+
+ servers = 3
+}
+```
+
+The `version` argument accepts a [version constraint string](/docs/configuration/version-constraints.html).
+Terraform will use the newest installed version of the module that meets the
+constraint; if no acceptable versions are installed, it will download the newest
+version that meets the constraint.
+
+Version constraints are supported only for modules installed from a module
+registry, such as the public [Terraform Registry](https://registry.terraform.io/)
+or [Terraform Cloud's private module registry](/docs/cloud/registry/index.html).
+Other module sources can provide their own versioning mechanisms within the
+source string itself, or might not support versions at all. In particular,
+modules sourced from local file paths do not support `version`; since
+they're loaded from the same source repository, they always share the same
+version as their caller.
+
+### Meta-arguments
+
+Along with `source` and `version`, Terraform defines a few more
+optional meta-arguments that have special meaning across all modules,
+described in more detail in the following pages:
+
+- `count` - Creates multiple instances of a module from a single `module` block.
+ See [the `count` page](/docs/configuration/meta-arguments/count.html)
+ for details.
+
+- `for_each` - Creates multiple instances of a module from a single `module`
+ block. See
+ [the `for_each` page](/docs/configuration/meta-arguments/for_each.html)
+ for details.
+
+- `providers` - Passes provider configurations to a child module. See
+ [the `providers` page](/docs/configuration/meta-arguments/module-providers.html)
+ for details. If not specified, the child module inherits all of the default
+ (un-aliased) provider configurations from the calling module.
+
+- `depends_on` - Creates explicit dependencies between the entire
+ module and the listed targets. See
+ [the `depends_on` page](/docs/configuration/meta-arguments/depends_on.html)
+ for details.
+
+In addition to the above, the `lifecycle` argument is not currently used by
+Terraform but is reserved for planned future features.
+
+## Accessing Module Output Values
+
+The resources defined in a module are encapsulated, so the calling module
+cannot access their attributes directly. However, the child module can
+declare [output values](/docs/configuration/outputs.html) to selectively
+export certain values to be accessed by the calling module.
+
+For example, if the `./app-cluster` module referenced in the example above
+exported an output value named `instance_ids` then the calling module
+can reference that result using the expression `module.servers.instance_ids`:
+
+```hcl
+resource "aws_elb" "example" {
+ # ...
+
+ instances = module.servers.instance_ids
+}
+```
+
+For more information about referring to named values, see
+[Expressions](/docs/configuration/expressions/index.html).
+
+## Transferring Resource State Into Modules
+
+When refactoring an existing configuration to split code into child modules,
+moving resource blocks between modules causes Terraform to see the new location
+as an entirely different resource from the old. Always check the execution plan
+after moving code across modules to ensure that no resources are deleted by
+surprise.
+
+If you want to make sure an existing resource is preserved, use
+[the `terraform state mv` command](/docs/commands/state/mv.html) to inform
+Terraform that it has moved to a different module.
+
+When passing resource addresses to `terraform state mv`, resources within child
+modules must be prefixed with `module..`. If a module was called with
+[`count`](/docs/configuration/meta-arguments/count.html) or
+[`for_each`](/docs/configuration/meta-arguments/for_each.html),
+its resource addresses must be prefixed with `module.[].`
+instead, where `` matches the `count.index` or `each.key` value of a
+particular module instance.
+
+Full resource addresses for module contents are used within the UI and on the
+command line, but cannot be used within a Terraform configuration. Only
+[outputs](/docs/configuration/outputs.html) from a module can be referenced from
+elsewhere in your configuration.
+
+## Tainting resources within a module
+
+The [taint command](/docs/commands/taint.html) can be used to _taint_ specific
+resources within a module:
+
+```shell
+$ terraform taint module.salt_master.aws_instance.salt_master
+```
+
+It is not possible to taint an entire module. Instead, each resource within
+the module must be tainted separately.
diff --git a/website/docs/configuration/blocks/providers/index.html.md b/website/docs/configuration/blocks/providers/index.html.md
index a6790044a5dc..81ef9f094101 100644
--- a/website/docs/configuration/blocks/providers/index.html.md
+++ b/website/docs/configuration/blocks/providers/index.html.md
@@ -13,7 +13,7 @@ configuration (like endpoint URLs or cloud regions) before they can be used.
## What Providers Do
-Each provider adds a set of [resource types](/docs/configuration/resources.html)
+Each provider adds a set of [resource types](/docs/configuration/blocks/resources/index.html)
and/or [data sources](/docs/configuration/data-sources.html) that Terraform can
manage.
diff --git a/website/docs/configuration/blocks/resources/behavior.html.md b/website/docs/configuration/blocks/resources/behavior.html.md
new file mode 100644
index 000000000000..d405c18dcf19
--- /dev/null
+++ b/website/docs/configuration/blocks/resources/behavior.html.md
@@ -0,0 +1,107 @@
+---
+layout: "language"
+page_title: "Resource Behavior - Configuration Language"
+---
+
+# Resource Behavior
+
+A `resource` block declares that you want a particular infrastructure object
+to exist with the given settings. If you are writing a new configuration for
+the first time, the resources it defines will exist _only_ in the configuration,
+and will not yet represent real infrastructure objects in the target platform.
+
+_Applying_ a Terraform configuration is the process of creating, updating,
+and destroying real infrastructure objects in order to make their settings
+match the configuration.
+
+## How Terraform Applies a Configuration
+
+When Terraform creates a new infrastructure object represented by a `resource`
+block, the identifier for that real object is saved in Terraform's
+[state](/docs/state/index.html), allowing it to be updated and destroyed
+in response to future changes. For resource blocks that already have an
+associated infrastructure object in the state, Terraform compares the
+actual configuration of the object with the arguments given in the
+configuration and, if necessary, updates the object to match the configuration.
+
+In summary, applying a Terraform configuration will:
+
+- _Create_ resources that exist in the configuration but are not associated with a real infrastructure object in the state.
+- _Destroy_ resources that exist in the state but no longer exist in the configuration.
+- _Update in-place_ resources whose arguments have changed.
+- _Destroy and re-create_ resources whose arguments have changed but which cannot be updated in-place due to remote API limitations.
+
+This general behavior applies for all resources, regardless of type. The
+details of what it means to create, update, or destroy a resource are different
+for each resource type, but this standard set of verbs is common across them
+all.
+
+The meta-arguments within `resource` blocks, documented in the
+sections below, allow some details of this standard resource behavior to be
+customized on a per-resource basis.
+
+## Accessing Resource Attributes
+
+[Expressions](/docs/configuration/expressions/index.html) within a Terraform module can access
+information about resources in the same module, and you can use that information
+to help configure other resources. Use the `..`
+syntax to reference a resource attribute in an expression.
+
+In addition to arguments specified in the configuration, resources often provide
+read-only attributes with information obtained from the remote API; this often
+includes things that can't be known until the resource is created, like the
+resource's unique random ID.
+
+Many providers also include [data sources](./data-sources.html), which are a
+special type of resource used only for looking up information.
+
+For a list of the attributes a resource or data source type provides, consult
+its documentation; these are generally included in a second list below its list
+of configurable arguments.
+
+For more information about referencing resource attributes in expressions, see
+[Expressions: References to Resource Attributes](/docs/configuration/expressions/references.html#references-to-resource-attributes).
+
+## Resource Dependencies
+
+Most resources in a configuration don't have any particular relationship, and
+Terraform can make changes to several unrelated resources in parallel.
+
+However, some resources must be processed after other specific resources;
+sometimes this is because of how the resource works, and sometimes the
+resource's configuration just requires information generated by another
+resource.
+
+Most resource dependencies are handled automatically. Terraform analyses any
+[expressions](/docs/configuration/expressions/index.html) within a `resource` block to find references
+to other objects, and treats those references as implicit ordering requirements
+when creating, updating, or destroying resources. Since most resources with
+behavioral dependencies on other resources also refer to those resources' data,
+it's usually not necessary to manually specify dependencies between resources.
+
+However, some dependencies cannot be recognized implicitly in configuration. For
+example, if Terraform must manage access control policies _and_ take actions
+that require those policies to be present, there is a hidden dependency between
+the access policy and a resource whose creation depends on it. In these rare
+cases, [the `depends_on` meta-argument](./depends_on.html) can explicitly specify a
+dependency.
+
+## Local-only Resources
+
+While most resource types correspond to an infrastructure object type that
+is managed via a remote network API, there are certain specialized resource
+types that operate only within Terraform itself, calculating some results and
+saving those results in the state for future use.
+
+For example, local-only resource types exist for
+[generating private keys](/docs/providers/tls/r/private_key.html),
+[issuing self-signed TLS certificates](/docs/providers/tls/r/self_signed_cert.html),
+and even [generating random ids](/docs/providers/random/r/id.html).
+While these resource types often have a more marginal purpose than those
+managing "real" infrastructure objects, they can be useful as glue to help
+connect together other resources.
+
+The behavior of local-only resources is the same as all other resources, but
+their result data exists only within the Terraform state. "Destroying" such
+a resource means only to remove it from the state, discarding its data.
+
diff --git a/website/docs/configuration/blocks/resources/index.html.md b/website/docs/configuration/blocks/resources/index.html.md
index f29d327e0074..a570b0da64de 100644
--- a/website/docs/configuration/blocks/resources/index.html.md
+++ b/website/docs/configuration/blocks/resources/index.html.md
@@ -12,8 +12,21 @@ Each resource block describes one or more infrastructure objects, such
as virtual networks, compute instances, or higher-level components such
as DNS records.
-- [Resource Blocks](/docs/configuration/resources.html) documents how to declare
- resources, including information about meta-arguments like `for_each`.
+- [Resource Blocks](/docs/configuration/blocks/resources/syntax.html) documents
+ the syntax for declaring resources.
+
+- [Resource Behavior](/docs/configuration/resources/behavior.html) explains in
+ more detail how Terraform handles resource declarations when applying a
+ configuration.
+
+- The Meta-Arguments section documents special arguments that can be used with
+ every resource type, including
+ [`depends_on`](/docs/configuration/meta-arguments/depends_on.html),
+ [`count`](/docs/configuration/meta-arguments/count.html),
+ [`for_each`](/docs/configuration/meta-arguments/for_each.html),
+ [`provider`](/docs/configuration/meta-arguments/resource-provider.html),
+ and [`lifecycle`](/docs/configuration/meta-arguments/lifecycle.html).
+
- [Provisioners](/docs/configuration/blocks/resources/provisioners/index.html)
documents configuring post-creation actions for a resource using the
`provisioner` and `connection` blocks. Since provisioners are non-declarative
diff --git a/website/docs/configuration/blocks/resources/syntax.html.md b/website/docs/configuration/blocks/resources/syntax.html.md
new file mode 100644
index 000000000000..a9b369a03677
--- /dev/null
+++ b/website/docs/configuration/blocks/resources/syntax.html.md
@@ -0,0 +1,171 @@
+---
+layout: "language"
+page_title: "Resources - Configuration Language"
+sidebar_current: "docs-config-resources"
+description: |-
+ Resources are the most important element in a Terraform configuration.
+ Each resource corresponds to an infrastructure object, such as a virtual
+ network or compute instance.
+---
+
+# Resource Blocks
+
+-> **Note:** This page is about Terraform 0.12 and later. For Terraform 0.11 and
+earlier, see
+[0.11 Configuration Language: Resources](../configuration-0-11/resources.html).
+
+> **Hands-on:** Try the [Terraform: Get Started](https://learn.hashicorp.com/collections/terraform/aws-get-started?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) collection on HashiCorp Learn.
+
+_Resources_ are the most important element in the Terraform language.
+Each resource block describes one or more infrastructure objects, such
+as virtual networks, compute instances, or higher-level components such
+as DNS records.
+
+## Resource Syntax
+
+Resource declarations can include a number of advanced features, but only
+a small subset are required for initial use. More advanced syntax features,
+such as single resource declarations that produce multiple similar remote
+objects, are described later in this page.
+
+```hcl
+resource "aws_instance" "web" {
+ ami = "ami-a1b2c3d4"
+ instance_type = "t2.micro"
+}
+```
+
+A `resource` block declares a resource of a given type ("aws_instance")
+with a given local name ("web"). The name is used to refer to this resource
+from elsewhere in the same Terraform module, but has no significance outside
+that module's scope.
+
+The resource type and name together serve as an identifier for a given
+resource and so must be unique within a module.
+
+Within the block body (between `{` and `}`) are the configuration arguments
+for the resource itself. Most arguments in this section depend on the
+resource type, and indeed in this example both `ami` and `instance_type` are
+arguments defined specifically for [the `aws_instance` resource type](/docs/providers/aws/r/instance.html).
+
+-> **Note:** Resource names must start with a letter or underscore, and may
+contain only letters, digits, underscores, and dashes.
+
+## Resource Types
+
+Each resource is associated with a single _resource type_, which determines
+the kind of infrastructure object it manages and what arguments and other
+attributes the resource supports.
+
+### Providers
+
+Each resource type is implemented by a [provider](/docs/configuration/provider-requirements.html),
+which is a plugin for Terraform that offers a collection of resource types. A
+provider usually provides resources to manage a single cloud or on-premises
+infrastructure platform. Providers are distributed separately from Terraform
+itself, but Terraform can automatically install most providers when initializing
+a working directory.
+
+In order to manage resources, a Terraform module must specify which providers it
+requires. Additionally, most providers need some configuration in order to
+access their remote APIs, and the root module must provide that configuration.
+
+For more information, see:
+
+- [Provider Requirements](/docs/configuration/provider-requirements.html), for declaring which
+ providers a module uses.
+- [Provider Configuration](/docs/configuration/providers.html), for configuring provider settings.
+
+Terraform usually automatically determines which provider to use based on a
+resource type's name. (By convention, resource type names start with their
+provider's preferred local name.) When using multiple configurations of a
+provider (or non-preferred local provider names), you must use the `provider`
+meta-argument to manually choose an alternate provider configuration. See
+[the `provider` meta-argument](/docs/configuration/meta-arguments/resource-provider.html) for more details.
+
+### Resource Arguments
+
+Most of the arguments within the body of a `resource` block are specific to the
+selected resource type. The resource type's documentation lists which arguments
+are available and how their values should be formatted.
+
+The values for resource arguments can make full use of
+[expressions](/docs/configuration/expressions/index.html) and other dynamic Terraform
+language features.
+
+There are also some _meta-arguments_ that are defined by Terraform itself
+and apply across all resource types. (See [Meta-Arguments](#meta-arguments) below.)
+
+### Documentation for Resource Types
+
+Every Terraform provider has its own documentation, describing its resource
+types and their arguments.
+
+Most publicly available providers are distributed on the
+[Terraform Registry](https://registry.terraform.io/browse/providers), which also
+hosts their documentation. When viewing a provider's page on the Terraform
+Registry, you can click the "Documentation" link in the header to browse its
+documentation. Provider documentation on the registry is versioned, and you can
+use the dropdown version menu in the header to switch which version's
+documentation you are viewing.
+
+To browse the publicly available providers and their documentation, see
+[the providers section of the Terraform Registry](https://registry.terraform.io/browse/providers).
+
+-> **Note:** Provider documentation used to be hosted directly on terraform.io,
+as part of Terraform's core documentation. Although some provider documentation
+might still be hosted here, the Terraform Registry is now the main home for all
+public provider docs. (The exception is the built-in
+[`terraform` provider](/docs/providers/terraform/index.html) for reading state
+data, since it is not available on the Terraform Registry.)
+
+## Resource Behavior
+
+For more information about how Terraform manages resources when applying a
+configuration, see
+[Resource Behavior](/docs/configuration/blocks/resources/behavior.html).
+
+## Meta-Arguments
+
+The Terraform language defines several meta-arguments, which can be used with
+any resource type to change the behavior of resources.
+
+The following meta-arguments are documented on separate pages:
+
+- [`depends_on`, for specifying hidden dependencies](/docs/configuration/meta-arguments/depends_on.html)
+- [`count`, for creating multiple resource instances according to a count](/docs/configuration/meta-arguments/count.html)
+- [`for_each`, to create multiple instances according to a map, or set of strings](/docs/configuration/meta-arguments/for_each.html)
+- [`provider`, for selecting a non-default provider configuration](/docs/configuration/meta-arguments/resource-provider.html)
+- [`lifecycle`, for lifecycle customizations](/docs/configuration/meta-arguments/lifecycle.html)
+- [`provisioner` and `connection`, for taking extra actions after resource creation](/docs/configuration/blocks/resources/provisioners/index.html)
+
+## Operation Timeouts
+
+Some resource types provide a special `timeouts` nested block argument that
+allows you to customize how long certain operations are allowed to take
+before being considered to have failed.
+For example, [`aws_db_instance`](/docs/providers/aws/r/db_instance.html)
+allows configurable timeouts for `create`, `update` and `delete` operations.
+
+Timeouts are handled entirely by the resource type implementation in the
+provider, but resource types offering these features follow the convention
+of defining a child block called `timeouts` that has a nested argument
+named after each operation that has a configurable timeout value.
+Each of these arguments takes a string representation of a duration, such
+as `"60m"` for 60 minutes, `"10s"` for ten seconds, or `"2h"` for two hours.
+
+```hcl
+resource "aws_db_instance" "example" {
+ # ...
+
+ timeouts {
+ create = "60m"
+ delete = "2h"
+ }
+}
+```
+
+The set of configurable operations is chosen by each resource type. Most
+resource types do not support the `timeouts` block at all. Consult the
+documentation for each resource type to see which operations it offers
+for configuration, if any.
diff --git a/website/docs/configuration/data-sources.html.md b/website/docs/configuration/data-sources.html.md
index ec5185666373..7d8597b27c49 100644
--- a/website/docs/configuration/data-sources.html.md
+++ b/website/docs/configuration/data-sources.html.md
@@ -18,7 +18,8 @@ configuration to make use of information defined outside of Terraform,
or defined by another separate Terraform configuration.
Each [provider](./providers.html) may offer data sources
-alongside its set of [resource types](./resources.html#resource-types-and-arguments).
+alongside its set of [resource](/docs/configuration/blocks/resources/index.html)
+types.
## Using Data Sources
@@ -71,7 +72,7 @@ infrastructure platform.
Most of the items within the body of a `data` block are defined by and
specific to the selected data source, and these arguments can make full
-use of [expressions](./expressions.html) and other dynamic
+use of [expressions](/docs/configuration/expressions/index.html) and other dynamic
Terraform language features.
However, there are some "meta-arguments" that are defined by Terraform itself
@@ -113,7 +114,7 @@ operation, and is re-calculated each time a new plan is created.
## Data Resource Dependencies
Data resources have the same dependency resolution behavior
-[as defined for managed resources](./resources.html#resource-dependencies).
+[as defined for managed resources](/docs/configuration/blocks/resources/behavior.html#resource-dependencies).
Setting the `depends_on` meta-argument within `data` blocks defers reading of
the data source until after all changes to the dependencies have been applied.
@@ -122,8 +123,8 @@ the data source until after all changes to the dependencies have been applied.
## Multiple Resource Instances
-Data resources support [`count`](./resources.html#count-multiple-resource-instances-by-count)
-and [`for_each`](./resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
+Data resources support [`count`](/docs/configuration/meta-arguments/count.html)
+and [`for_each`](/docs/configuration/meta-arguments/for_each.html)
meta-arguments as defined for managed resources, with the same syntax and behavior.
As with managed resources, when `count` or `for_each` is present it is important to
@@ -133,7 +134,7 @@ own variant of the constraint arguments, producing an indexed result.
## Selecting a Non-default Provider Configuration
-Data resources support [the `provider` meta-argument](./resources.html#provider-selecting-a-non-default-provider-configuration)
+Data resources support [the `provider` meta-argument](/docs/configuration/meta-arguments/resource-provider.html)
as defined for managed resources, with the same syntax and behavior.
## Lifecycle Customizations
@@ -187,13 +188,15 @@ resource "aws_instance" "web" {
## Meta-Arguments
As data sources are essentially a read only subset of resources, they also
-support the same [meta-arguments](./resources.html#meta-arguments) of resources
+support the same [meta-arguments](/docs/configuration/blocks/resources/syntax.html#meta-arguments) of resources
with the exception of the
-[`lifecycle` configuration block](./resources.html#lifecycle-lifecycle-customizations).
+[`lifecycle` configuration block](/docs/configuration/meta-arguments/lifecycle.html).
### Non-Default Provider Configurations
-Similarly to [resources](./resources.html), when a module has multiple configurations for the same provider you can specify which configuration to use with the `provider` meta-argument:
+Similarly to [resources](/docs/configuration/blocks/resources/index.html), when
+a module has multiple configurations for the same provider you can specify which
+configuration to use with the `provider` meta-argument:
```hcl
data "aws_ami" "web" {
@@ -204,7 +207,7 @@ data "aws_ami" "web" {
```
See
-[Resources: Selecting a Non-Default Provider Configuration](./resources.html#provider-selecting-a-non-default-provider-configuration)
+[The Resource `provider` Meta-Argument](/docs/configuration/meta-arguments/resource-provider.html)
for more information.
## Data Source Lifecycle
diff --git a/website/docs/configuration/dependency-lock.html.md b/website/docs/configuration/dependency-lock.html.md
index 37c95068c44c..c65902ba167e 100644
--- a/website/docs/configuration/dependency-lock.html.md
+++ b/website/docs/configuration/dependency-lock.html.md
@@ -14,9 +14,9 @@ dependency that come from outside of its own codebase:
* [Providers](./provider-requirements.html), which are plugins for Terraform
that extend it with support for interacting with various external systems.
-* [Modules](./modules.html), which allow splitting out groups of Terraform
- configuration constructs (written in the Terraform language) into reusable
- abstractions.
+* [Modules](/docs/configuration/blocks/modules/index.html), which allow
+ splitting out groups of Terraform configuration constructs (written in the
+ Terraform language) into reusable abstractions.
Both of these dependency types can be published and updated independently from
Terraform itself and from the configurations that depend on them. For that
@@ -168,7 +168,7 @@ block in the dependency lock file.
@@ -6,6 +6,26 @@
]
}
-
+
+provider "registry.terraform.io/hashicorp/azurerm" {
+ version = "2.30.0"
+ constraints = "~> 2.12"
@@ -219,7 +219,7 @@ block to reflect that change.
+++ .terraform.lock.hcl 2020-10-07 16:43:42.785665945 -0700
@@ -7,22 +7,22 @@
}
-
+
provider "registry.terraform.io/hashicorp/azurerm" {
- version = "2.1.0"
- constraints = "~> 2.1.0"
diff --git a/website/docs/configuration/expressions.html.md b/website/docs/configuration/expressions.html.md
index c7f9a4000129..560b5c014293 100644
--- a/website/docs/configuration/expressions.html.md
+++ b/website/docs/configuration/expressions.html.md
@@ -1,905 +1,123 @@
---
layout: "language"
-page_title: "Expressions - Configuration Language"
+page_title: "Expressions Landing Page - Configuration Language"
sidebar_current: "docs-config-expressions"
-description: |-
- The Terraform language allows the use of expressions to access data exported
- by resources and to transform and combine that data to produce other values.
---
-# Expressions
+# Expressions Landing Page
--> **Note:** This page is about Terraform 0.12 and later. For Terraform 0.11 and
-earlier, see
-[0.11 Configuration Language: Interpolation Syntax](../configuration-0-11/interpolation.html).
-
-_Expressions_ are used to refer to or compute values within a configuration.
-The simplest expressions are just literal values, like `"hello"` or `5`,
-but the Terraform language also allows more complex expressions such as
-references to data exported by resources, arithmetic, conditional evaluation,
-and a number of built-in functions.
-
-Expressions can be used in a number of places in the Terraform language,
-but some contexts limit which expression constructs are allowed,
-such as requiring a literal value of a particular type or forbidding
-[references to resource attributes](/docs/configuration/expressions.html#references-to-resource-attributes).
-Each language feature's documentation describes any restrictions it places on expressions.
-
-You can experiment with the behavior of Terraform's expressions from
-the Terraform expression console, by running
-[the `terraform console` command](/docs/commands/console.html).
-
-The rest of this page describes all of the features of Terraform's
-expression syntax.
-
-## Types and Values
-
-The result of an expression is a _value_. All values have a _type_, which
-dictates where that value can be used and what transformations can be
-applied to it.
-
-The Terraform language uses the following types for its values:
-
-* `string`: a sequence of Unicode characters representing some text, like
- `"hello"`.
-* `number`: a numeric value. The `number` type can represent both whole
- numbers like `15` and fractional values like `6.283185`.
-* `bool`: either `true` or `false`. `bool` values can be used in conditional
- logic.
-* `list` (or `tuple`): a sequence of values, like
- `["us-west-1a", "us-west-1c"]`. Elements in a list or tuple are identified by
- consecutive whole numbers, starting with zero.
-* `map` (or `object`): a group of values identified by named labels, like
- `{name = "Mabel", age = 52}`.
-
-Strings, numbers, and bools are sometimes called _primitive types._ Lists/tuples and maps/objects are sometimes called _complex types,_ _structural types,_ or _collection types._
-
-Finally, there is one special value that has _no_ type:
-
-* `null`: a value that represents _absence_ or _omission._ If you set an
- argument of a resource or module to `null`, Terraform behaves as though you
- had completely omitted it — it will use the argument's default value if it has
- one, or raise an error if the argument is mandatory. `null` is most useful in
- conditional expressions, so you can dynamically omit an argument if a
- condition isn't met.
-
-### Advanced Type Details
-
-In most situations, lists and tuples behave identically, as do maps and objects.
-Whenever the distinction isn't relevant, the Terraform documentation uses each
-pair of terms interchangeably (with a historical preference for "list" and
-"map").
-
-However, module authors and provider developers should understand the
-differences between these similar types (and the related `set` type), since they
-offer different ways to restrict the allowed values for input variables and
-resource arguments.
-
-For complete details about these types (and an explanation of why the difference
-usually doesn't matter), see [Type Constraints](./types.html).
-
-### Type Conversion
-
-Expressions are most often used to set values for the arguments of resources and
-child modules. In these cases, the argument has an expected type and the given
-expression must produce a value of that type.
-
-Where possible, Terraform automatically converts values from one type to
-another in order to produce the expected type. If this isn't possible, Terraform
-will produce a type mismatch error and you must update the configuration with a
-more suitable expression.
-
-Terraform automatically converts number and bool values to strings when needed.
-It also converts strings to numbers or bools, as long as the string contains a
-valid representation of a number or bool value.
-
-* `true` converts to `"true"`, and vice-versa
-* `false` converts to `"false"`, and vice-versa
-* `15` converts to `"15"`, and vice-versa
-
-## Literal Expressions
-
-A _literal expression_ is an expression that directly represents a particular
-constant value. Terraform has a literal expression syntax for each of the value
-types described above:
-
-* Strings are usually represented by a double-quoted sequence of Unicode
- characters, `"like this"`. There is also a "heredoc" syntax for more complex
- strings. String literals are the most complex kind of literal expression in
- Terraform, and have additional documentation on this page:
- * See [String Literals](#string-literals) below for information about escape
- sequences and the heredoc syntax.
- * See [String Templates](#string-templates) below for information about
- interpolation and template directives.
-* Numbers are represented by unquoted sequences of digits with or without a
- decimal point, like `15` or `6.283185`.
-* Bools are represented by the unquoted symbols `true` and `false`.
-* The null value is represented by the unquoted symbol `null`.
-* Lists/tuples are represented by a pair of square brackets containing a
- comma-separated sequence of values, like `["a", 15, true]`.
-
- List literals can be split into multiple lines for readability, but always
- require a comma between values. A comma after the final value is allowed,
- but not required. Values in a list can be arbitrary expressions.
-* Maps/objects are represented by a pair of curly braces containing a series of
- ` = ` pairs:
-
- ```hcl
- {
- name = "John"
- age = 52
- }
- ```
-
- Key/value pairs can be separated by either a comma or a line break. Values
- can be arbitrary expressions. Keys are strings; they can be left unquoted if
- they are a valid [identifier](./syntax.html#identifiers), but must be quoted
- otherwise. You can use a non-literal expression as a key by wrapping it in
- parentheses, like `(var.business_unit_tag_name) = "SRE"`.
-
-## Indices and Attributes
-
-[inpage-index]: #indices-and-attributes
-
-Elements of list/tuple and map/object values can be accessed using
-the square-bracket index notation, like `local.list[3]`. The expression within
-the brackets must be a whole number for list and tuple values or a string
-for map and object values.
-
-Map/object attributes with names that are valid identifiers can also be accessed
-using the dot-separated attribute notation, like `local.object.attrname`.
-In cases where a map might contain arbitrary user-specified keys, we recommend
-using only the square-bracket index notation (`local.map["keyname"]`).
-
-## References to Named Values
-
-Terraform makes several kinds of named values available. Each of these names is
-an expression that references the associated value; you can use them as
-standalone expressions, or combine them with other expressions to compute new
-values.
-
-The following named values are available:
-
-* `.` is an object representing a
- [managed resource](./resources.html) of the given type
- and name. The attributes of the resource can be accessed using
- [dot or square bracket notation][inpage-index].
-
- Any named value that does not match another pattern listed below
- will be interpreted by Terraform as a reference to a managed resource.
-
- If the resource has the `count` argument set, the value of this expression
- is a _list_ of objects representing its instances.
-
- If the resource has the `for_each` argument set, the value of this expression
- is a _map_ of objects representing its instances.
-
- For more information, see
- [references to resource attributes](#references-to-resource-attributes) below.
-* `var.` is the value of the
- [input variable](./variables.html) of the given name.
-* `local.` is the value of the
- [local value](./locals.html) of the given name.
-* `module..