All Products
Search
Document Center

Terraform:Basic terms

Last Updated:Oct 15, 2025

After covering template composition, Terraform configuration directories, and the HashiCorp Configuration Language (HCL), this article introduces the common terms and concepts you will encounter during the coding phase of a Terraform workflow.

Resource

A Terraform resource is a block that defines a component of your infrastructure. Resources are declared using the resource keyword, followed by the resource type, which is usually prefixed by the provider (we'll explain providers next), and a custom name. The configuration for the resource is specified inside curly braces, using arguments required for that resource. Resources can be defined in any .tf file, but they're often organized in a file like main.tf by convention.

resource "resource_type" "resource_name" {
  # Specify arguments for the resource type
}

Terraform uses the resource type and the resource name together to create a unique identifier for each infrastructure element. For example, in the code below, the resource keyword marks the block as a declaration for a cloud infrastructure component. The resource type here is alicloud_oss_bucket, which indicates an Object Storage Service (OSS) bucket from the Alibaba Cloud provider. The keyword resource is reserved in Terraform and cannot be changed. The resource type depends on the provider declared elsewhere in your configuration, and example-bucket is the user-defined name for this resource in your Terraform setup.

resource "alicloud_oss_bucket" "example-bucket" {
  bucket = "my-bucket-xxxx" # Specify a globally unique bucket name
}

The following example assumes the Alibaba Cloud provider is declared elsewhere in your configuration and defines two resource blocks: one for an OSS bucket and another for a vSwitch. Each resource type requires different arguments. For alicloud_oss_bucket, specifying a bucket name (using the bucket argument) is sufficient to create the resource. For alicloud_vswitch, you must provide the vpc_id the vSwitch belongs to, a cidr_block, and a zone_id. Other arguments, such as vswitch_name and tags, are optional and can be included as needed.

resource "alicloud_oss_bucket" "example-bucket" {
  bucket = "my-bucket-xxxxx"
}

resource "alicloud_vswitch" "main_vswitch" {
  vpc_id       = "vpc-abc12345"
  cidr_block   = "10.0.1.0/24"
  zone_id      = "cn-hangzhou-k"
  vswitch_name = "main-vswitch"
}

For complex configurations with lengthy resource definitions, it is a best practice to organize them into separate .tf files by resource type. For example, configurations for Elastic Compute Service (ECS) instances, OSS buckets, and databases could be placed in instance.tfoss.tf, and database.tf, respectively.

Provider

A provider in Terraform is a plugin that implements a set of resource types and enables Terraform to manage infrastructure. Without providers, Terraform cannot interact with any cloud services or platforms. Providers are typically defined in a separate .tf file—often named providers.tf—with a terraform block specifying required providers and their versions. After a provider is declared, running terraform init automatically downloads the plugin if it's not present. The following example shows how to declare and configure the Alibaba Cloud provider:

terraform {
  required_providers {
    alicloud = {
      source = "aliyun/alicloud"
      version = "1.225.0"
    }
  }
}

provider "alicloud" {
  # Configure your Alibaba Cloud credentials and region
  # For security, set credentials via environment variables (not hardcoded):
  # export ALICLOUD_ACCESS_KEY="<Your Alibaba Cloud AccessKey>"
  # export ALICLOUD_SECRET_KEY="<Your Alibaba Cloud SecretKey>"
  region = "cn-hangzhou"
}

The provider translates resource arguments into specific API calls to manage your infrastructure. The provider configuration always belongs to the root module of a Terraform configuration. In the example, alicloud is the local name for the provider. The required_providers block maps this local name to its source in the Terraform Registry. The source argument specifies the global address of the provider—aliyun/alicloud in this case. While the version argument is optional, it is highly recommended: it constrains Terraform to use a specific provider version (or range), helping prevent automatic upgrades to versions that might introduce breaking changes. If no version is specified, Terraform will download the latest available version during initialization.

For historical reasons, the Alibaba Cloud provider (alicloud) supports two source values: aliyun/alicloud and hashicorp/alicloud. Both sources point to identical implementations of the provider. For more information, see Terraform overview.

Arguments like access_keysecret_key, and region are specific to the Alibaba Cloud provider. If the provider block is omitted, Terraform assumes an empty default configuration and attempts to source credentials and region from environment variables. If the region is not set via environment variables, it defaults to cn-beijing. For more information, see Argument Reference.

Variable

Input variables parameterize your Terraform configuration, allowing customization without modifying the source code. This makes configurations easier to share and reuse. Variables are defined using a variable block, and their values can be provided at runtime in several ways, including environment variables, command-line arguments, or key-value files with a .tfvars extension (for example, terraform.tfvars).

image

By using input variables, you can cleanly separate resource attribute values from your execution plan. For example, in a VPC resource defined in main.tf, the vpc_name attribute can reference a variable declared in a variables.tf file. This lets you define its value at runtime or in a .tfvars file. For more information, see Variable.

Output

Outputs in Terraform are used to expose information about resources managed in your configuration. Every resource instance exports attributes (such as IDs, endpoints, etc.) whose values can be referenced elsewhere or returned as outputs. Output values make this information accessible both to users (displayed in CLI) and to other Terraform configurations or modules. By convention, output definitions are placed in an outputs.tf file.

Some resource attributes are only computed after creation—such as a vSwitch ID or endpoint—so outputs allow you to expose these for use in dependency chaining, automation, or manual inspection.

output "vswitch_id" {
  value = alicloud_vswitch.main_vswitch.id
}

The label after the output keyword (e.g., vswitch_id) is the output name. In a root module, this is displayed to the user after terraform apply. In a child module, it is used for referencing from elsewhere. The value argument takes an expression that determines what is returned. After running terraform apply, output values are shown as follows:

image (8).png

State

Terraform records the state of the resources it manages in a state file, typically named terraform.tfstate when stored locally. By default, this file is kept in your project directory, but it can also be stored remotely, which is the recommended approach for team collaboration and reliability. The state file contains detailed information about the resources, outputs, and metadata for your configuration, similar to the following example:

{
  "version": 4,
  "terraform_version": "1.7.1",
  "serial": 168,
  "lineage": "46c0889c-f4ff-d1fd-2109-364f97e55c06",
  "outputs": {
    "vswitch_id": {
      "value": "vsw-bp1ev5ei73c7y5ib887v1",
      "type": "string"
    }
  },
  "resources": [
    {
      "mode": "managed",
      "type": "alicloud_vswitch",
      "name": "main_vswitch",
      "provider": "provider[\"registry.terraform.io/hashicorp/alicloud\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "availability_zone": "cn-hangzhou-k",
            "cidr_block": "10.0.1.0/24",
            "create_time": "2024-06-23T07:53:48Z",
            "description": "",
            "enable_ipv6": null,
            "id": "vsw-bp1ev5ei73c7y5ib887v1",
            ...

Never manually modify the state file. Terraform creates and updates it automatically, and direct changes can corrupt the state, causing errors or duplicate resource creation. For more information, see Introduction to Terraform state.

Module

A module is a set of Terraform configuration files contained within a single directory. Even a simple configuration with one or more .tf files is considered a module. Modules are the primary mechanism for code reuse and organization in Terraform. You can call modules from other configurations, specifying a source from which the module code can be retrieved. This source can be a local path or a remote location. You can use open-source modules from registries like the HashiCorp Module Registryor create your own. The figure below shows a typical module directory structure:

image (9).png