{"id":2129,"date":"2026-02-21T00:40:45","date_gmt":"2026-02-20T11:40:45","guid":{"rendered":"https:\/\/www.ronella.xyz\/?p=2129"},"modified":"2026-02-21T00:40:45","modified_gmt":"2026-02-20T11:40:45","slug":"terraform-block-types","status":"publish","type":"post","link":"https:\/\/www.ronella.xyz\/?p=2129","title":{"rendered":"Terraform Block Types"},"content":{"rendered":"

Terraform configurations are built out of blocks<\/em>. Understanding block types is critical because they define how you declare infrastructure, wire modules together, and control Terraform\u2019s behavior.<\/p>\n

\n

1. The Anatomy of a Block<\/h2>\n

Every Terraform block has the same basic shape:<\/p>\n

TYPE "label1" "label2" {\n  argument_name = expression\n\n  nested_block_type {\n    # ...\n  }\n}<\/code><\/pre>\n
Key parts:<\/p>\n
    \n
  • Type<\/strong>: The keyword at the start (resource<\/code>, provider<\/code>, variable<\/code>, etc.). This tells Terraform what kind of thing you are defining.<\/li>\n
  • Labels: Extra identifiers whose meaning depends on the block type.\n
      \n
    • Example: resource "aws_instance" "web"<\/code><\/li>\n
    • Type: resource<\/code><\/li>\n
    • Labels: "aws_instance"<\/code> (resource type), "web"<\/code> (local name)<\/li>\n<\/ul>\n<\/li>\n
    • Body: The { ... }<\/code> section, which can contain:\n
        \n
      • Arguments: name = expression<\/code><\/li>\n
      • Nested blocks: block_type { ... }<\/code><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
        Rationale:<\/strong> The consistent shape makes the language predictable. Block type + labels define what<\/em> the block is; the body defines how<\/em> it behaves or is configured.<\/p>\n
        \n
        2. Core Top-Level Block Types<\/h2>\n
        These blocks usually appear at the top level of your .tf<\/code> files and together they define a module: its inputs, logic, and outputs.<\/p>\n
        2.1 terraform<\/code> block<\/h2>\n
        Configures Terraform itself:<\/p>\n
          \n
        • Required providers and their versions.<\/li>\n
        • Required Terraform version.<\/li>\n
        • Backend configuration (usually via a nested backend<\/code> block in terraform<\/code>).<\/li>\n<\/ul>\n
          Example:<\/p>\n
          terraform {\n  required_version = ">= 1.6.0"\n\n  required_providers {\n    aws = {\n      source  = "hashicorp\/aws"\n      version = "~> 5.0"\n    }\n  }\n}<\/code><\/pre>\n
          Rationale:<\/strong> Keeps tooling constraints explicit and version-pinned, so behavior is deterministic across environments and team members.<\/p>\n
          \n
          2.2 provider<\/code> block<\/h2>\n
          Configures how Terraform talks to an external API (AWS, Azure, GCP, Kubernetes, etc.):<\/p>\n
          provider "aws" {\n  region = var.aws_region\n}<\/code><\/pre>\n
          Typical aspects:<\/p>\n
            \n
          • Credentials and regions.<\/li>\n
          • Aliases for multiple configurations (e.g., provider "aws" { alias = "eu" ... }<\/code>).<\/li>\n<\/ul>\n
            Rationale:<\/strong> Providers are the \u201cdrivers\u201d Terraform uses to translate configuration into real infrastructure; separating them lets you re-use the same module with different provider settings.<\/p>\n
            \n
            2.3 resource<\/code> block<\/h2>\n
            Declares infrastructure objects Terraform will create and manage.<\/p>\n
            resource "aws_s3_bucket" "this" {\n  bucket = "${local.name}-bucket"\n}<\/code><\/pre>\n
            Structure:<\/p>\n
              \n
            • Type label: the provider-specific resource type ("aws_s3_bucket"<\/code>).<\/li>\n
            • Name label: a local identifier ("this"<\/code>, "web"<\/code>, "db"<\/code>, etc.).<\/li>\n
            • Body: arguments and nested blocks that define the resource\u2019s configuration.<\/li>\n<\/ul>\n
              Rationale:<\/strong> The resource<\/code> block is the heart of Terraform; it expresses desired state. Every apply tries to reconcile actual infrastructure with what these blocks declare.<\/p>\n
              \n
              2.4 data<\/code> block<\/h2>\n
              Reads information about existing<\/strong> objects without creating anything.<\/p>\n
              data "aws_ami" "latest_amazon_linux" {\n  most_recent = true\n\n  filter {\n    name   = "name"\n    values = ["amazon-linux-2-*"]\n  }\n\n  owners = ["amazon"]\n}<\/code><\/pre>\n
              You reference it as data.aws_ami.latest_amazon_linux.id<\/code>.<\/p>\n
              Rationale:<\/strong> Data sources decouple \u201clookup\u201d from \u201ccreation\u201d. You avoid hardcoding IDs\/ARNs and can dynamically discover things like AMIs, VPC IDs, or roles.<\/p>\n
              \n
              2.5 variable<\/code> block<\/h2>\n
              Defines inputs to a module:<\/p>\n
              variable "aws_region" {\n  type        = string\n  description = "AWS region to deploy into"\n  default     = "us-west-2"\n}<\/code><\/pre>\n
              Key fields:<\/p>\n
                \n
              • type<\/code>: basic or complex types (string, number, list, map, object, etc.).<\/li>\n
              • default<\/code>: makes a variable optional.<\/li>\n
              • description<\/code>: documentation for humans.<\/li>\n<\/ul>\n
                Rationale:<\/strong> Explicit inputs make modules reusable, testable, and self-documenting. They are your module\u2019s API.<\/p>\n
                \n
                2.6 output<\/code> block<\/h2>\n
                Exposes values from a module:<\/p>\n
                output "bucket_name" {\n  value       = aws_s3_bucket.this.bucket\n  description = "Name of the S3 bucket created by this module."\n}<\/code><\/pre>\n
                Rationale:<\/strong> Outputs are your module\u2019s return values, allowing composition: root modules can print values, and child modules can feed outputs into other modules or systems (e.g., CI\/CD).<\/p>\n
                \n
                2.7 locals<\/code> block<\/h2>\n
                Defines computed values for use within a module:<\/p>\n
                locals {\n  name_prefix = "demo"\n  bucket_name = "${local.name_prefix}-bucket"\n}<\/code><\/pre>\n
                Notes:<\/p>\n
                  \n
                • You can have multiple locals<\/code> blocks; Terraform merges them.<\/li>\n
                • Access them via local.<name><\/code>.<\/li>\n<\/ul>\n
                  Rationale:<\/strong> Locals centralize derived values and remove duplication. That keeps your configuration DRY and easier to refactor.<\/p>\n
                  \n
                  3. Nested Blocks vs Arguments<\/h2>\n
                  Within a block body you use two constructs:<\/p>\n
                    \n
                  • \n
                    Arguments<\/strong>: key = expression<\/code>
                    \nExample: bucket = "demo-bucket"<\/code>.<\/p>\n<\/li>\n
                  • \n
                    Nested blocks<\/strong>: block_type { ... }<\/code>
                    \nExample:<\/p>\n
                    resource \"aws_instance\" \"web\" {\nami           = data.aws_ami.latest_amazon_linux.id\ninstance_type = \"t3.micro\"\n\nnetwork_interface {\n  device_index = 0\n  network_interface_id = aws_network_interface.web.id\n}\n}<\/code><\/pre>\n<\/li>\n<\/ul>\n
                    Why have both?<\/p>\n
                      \n
                    • Arguments are single values; they are the usual \u201csettings\u201d.<\/li>\n
                    • Nested blocks model structured, often repeatable configuration sections (e.g., ingress<\/code> rules in security groups, network_interface<\/code>, lifecycle<\/code>, tag<\/code> blocks in some providers).<\/li>\n<\/ul>\n
                      Rationale:<\/strong> Using nested blocks for structured\/repeated sections keeps complex resources readable and makes it clear which values logically belong together.<\/p>\n
                      \n
                      4. Meta-Arguments and Lifecycle Blocks<\/h2>\n
                      Some names inside a resource are meta-arguments<\/strong> understood by Terraform itself rather than by the provider:<\/p>\n
                      Common meta-arguments:<\/p>\n
                        \n
                      • depends_on<\/code>: Add explicit dependencies when Terraform\u2019s graph inference isn\u2019t enough.<\/li>\n
                      • count<\/code>: Create multiple instances of a resource using integer indexing.<\/li>\n
                      • for_each<\/code>: Create multiple instances keyed by a map or set.<\/li>\n
                      • provider<\/code>: Pin a resource to a specific provider configuration (e.g., aws.eu<\/code>).<\/li>\n
                      • lifecycle<\/code>: Special nested block that controls create\/update\/destroy behavior.<\/li>\n<\/ul>\n
                        Example lifecycle<\/code>:<\/p>\n
                        resource "aws_s3_bucket" "this" {\n  bucket = "${local.name}-bucket"\n\n  lifecycle {\n    prevent_destroy       = true\n    ignore_changes        = [tags]\n    create_before_destroy = true\n  }\n}<\/code><\/pre>\n
                        Rationale:<\/strong> Meta-arguments give you control over resource orchestration<\/em> rather than definition. They let you express cardinality, ordering, and safety rules without resorting to hacks or external tooling.<\/p>\n
                        \n
                        5. Putting It All Together<\/h2>\n
                        Below is a small but coherent configuration that demonstrates the main block types and how they interact. You can drop this into an empty directory as main.tf<\/code>.<\/p>\n
                        terraform {\n  required_version = ">= 1.6.0"\n\n  required_providers {\n    aws = {\n      source  = "hashicorp\/aws"\n      version = "~> 5.0"\n    }\n  }\n}\n\nvariable "aws_region" {\n  type        = string\n  description = "AWS region to deploy into (used by LocalStack as well)"\n  default     = "us-east-1"\n}\n\nlocals {\n  project = "block-types-localstack-demo"\n  bucket  = "${local.project}-bucket"\n}\n\nprovider "aws" {\n  region  = var.aws_region\n\n  # Dummy credentials \u2013 LocalStack doesn\u2019t actually validate them.\n  access_key = "test"\n  secret_key = "test"\n\n  # Talk to LocalStack instead of AWS.\n  s3_use_path_style           = true\n  skip_credentials_validation = true\n  skip_metadata_api_check     = true\n  skip_requesting_account_id  = true\n\n  endpoints {\n    s3 = "http:\/\/localhost:4566"\n    sts = "http:\/\/localhost:4566"\n  }\n}\n\n# This data source will return the LocalStack \u201ctest\u201d account (000000000000).\ndata "aws_caller_identity" "current" {}\n\nresource "aws_s3_bucket" "this" {\n  bucket = local.bucket\n\n  tags = {\n    Project = local.project\n    Owner   = data.aws_caller_identity.current.account_id\n  }\n\n  lifecycle {\n    prevent_destroy = true\n  }\n}\n\noutput "bucket_name" {\n  value       = aws_s3_bucket.this.bucket\n  description = "The name of the created S3 bucket."\n}\n\noutput "account_id" {\n  value       = data.aws_caller_identity.current.account_id\n  description = "AWS (LocalStack) account ID used for this deployment."\n}<\/code><\/pre>\n
                        What this example shows<\/h2>\n
                          \n
                        • terraform<\/code> block: pins Terraform and the AWS provider.<\/li>\n
                        • variable<\/code>: input for region.<\/li>\n
                        • locals<\/code>: internal naming logic.<\/li>\n
                        • provider<\/code>: AWS configuration.<\/li>\n
                        • data<\/code>: a data source reading your current AWS identity.<\/li>\n
                        • resource<\/code>: S3 bucket, including nested lifecycle<\/code> and tags.<\/li>\n
                        • output<\/code>: exposes bucket name and account ID.<\/li>\n<\/ul>\n
                          How to Run and Validate with LocalStack<\/h2>\n
                            \n
                          1. \n
                            Start LocalStack<\/strong> (for example, via Docker):<\/p>\n
                            docker run --rm -it -p 4566:4566 -p 4510-4559:4510-4559 localstack\/localstack<\/code><\/pre>\n
                            This exposes the LocalStack APIs on http:\/\/localhost:4566<\/code> as expected by the provider config.<\/p>\n<\/li>\n
                          2. \n
                            Initialize Terraform<\/strong>:<\/p>\n
                            terraform init<\/code><\/pre>\n<\/li>\n
                          3. \n
                            Format and validate<\/strong>:<\/p>\n
                            terraform fmt -check\nterraform validate<\/code><\/pre>\n<\/li>\n
                          4. \n
                            Plan and apply against LocalStack<\/strong>:<\/p>\n
                            terraform plan\nterraform apply<\/code><\/pre>\n
                            Confirm with yes<\/code> when prompted. Terraform will create the S3 bucket in LocalStack rather than AWS; the dummy credentials and endpoint mapping make this safe for local experimentation.<\/p>\n<\/li>\n
                          5. \n
                            Check outputs<\/strong>:<\/p>\n
                            terraform output\nterraform output bucket_name\nterraform output account_id<\/code><\/pre>\n<\/li>\n
                          6. \n
                            Configure profile<\/p>\n
                            aws configure --profile localstack<\/code><\/pre>\n<\/li>\n
                          7. \n
                            Verify in LocalStack<\/strong> (using AWS CLI configured to point to LocalStack):<\/p>\n
                            aws --endpoint-url http:\/\/localhost:4566 s3 ls --profile localstack<\/code><\/pre>\n
                            You should see the bucket named in bucket_name<\/code>. LocalStack typically uses test<\/code> credentials and a default account ID of 000000000000<\/code>.<\/p>\n<\/li>\n
                          8. \n
                            Destroy<\/strong> (noting prevent_destroy<\/code>)<\/p>\n
                            Because of prevent_destroy = true<\/code>, terraform destroy<\/code> will refuse to delete the bucket. That\u2019s intentional, to illustrate the lifecycle<\/code> block. Remove prevent_destroy<\/code>, run terraform apply<\/code> again, then:<\/p>\n
                            terraform destroy<\/code><\/pre>\n<\/li>\n<\/ol>\n
                            \n
                            6. A Quick Comparison Table<\/h2>\n
                            To solidify the concepts, here is a concise comparison of key block types:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
                            Block type<\/th>\nPurpose<\/th>\nTypical labels<\/th>\nCommonly uses nested blocks<\/th>\n<\/tr>\n<\/thead>\n
                            terraform<\/code><\/td>\nConfigure Terraform itself<\/td>\nNone<\/td>\nrequired_providers<\/code>, backend<\/code><\/td>\n<\/tr>\n
                            provider<\/code><\/td>\nConfigure connection to an API<\/td>\nProvider name (e.g., "aws"<\/code>)<\/td>\nOccasionally provider-specific blocks<\/td>\n<\/tr>\n
                            resource<\/code><\/td>\nDeclare managed infrastructure<\/td>\nResource type, local name<\/td>\nlifecycle<\/code>, provisioner<\/code>, provider-specific<\/td>\n<\/tr>\n
                            data<\/code><\/td>\nRead existing infrastructure<\/td>\nData source type, local name<\/td>\nProvider-specific nested blocks<\/td>\n<\/tr>\n
                            variable<\/code><\/td>\nDefine module inputs<\/td>\nVariable name<\/td>\nNone (just arguments)<\/td>\n<\/tr>\n
                            output<\/code><\/td>\nExpose module outputs<\/td>\nOutput name<\/td>\nNone (just arguments)<\/td>\n<\/tr>\n
                            locals<\/code><\/td>\nDefine internal computed values<\/td>\nNone<\/td>\nNone (just arguments)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"
                            Terraform configurations are built out of blocks. Understanding block types is critical because they define how you declare infrastructure, wire modules together, and control Terraform\u2019s behavior. 1. The Anatomy of a Block Every Terraform block has the same basic shape: TYPE "label1" "label2" { argument_name = expression nested_block_type { # … } } Key parts: […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[94],"tags":[],"_links":{"self":[{"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/posts\/2129"}],"collection":[{"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2129"}],"version-history":[{"count":1,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/posts\/2129\/revisions"}],"predecessor-version":[{"id":2130,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/posts\/2129\/revisions\/2130"}],"wp:attachment":[{"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2129"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2129"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2129"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}