Creating Infrastructure with Resource Blocks

This article focuses on the heart of Terraform: the resource block. Resource blocks are the primary building blocks of infrastructure-as-code; they declare the real infrastructure you want Terraform to create and manage. In this guide you’ll learn how to define resource blocks, understand their core components, and use references to model dependencies across providers. When we say “resources” in Terraform we mean concrete infrastructure elements — virtual machines, storage buckets, networks, databases, and more. Each provider (AWS, Azure, Kubernetes, etc.) exposes resource types that map to those elements. Terraform provides a consistent, declarative syntax to create and manage these resources across multiple providers.

An infographic titled "Terraform Resources" showing Kubernetes and AWS logos connected to hexagon icons that label specific resource types. It lists Kubernetes items (pod, pvc, secret, svc) and AWS services (Lambda, Kinesis, S3, EKS, VPC, SQS, EC2, DynamoDB).

What a resource block does

A Terraform resource block is a blueprint that declares:

What type of infrastructure to create (resource type provided by a provider).
How that infrastructure should be configured (arguments like CPU, memory, AMI, tags).
A configuration-local name used to reference the resource elsewhere.

The resource block tells Terraform: “Create or manage this specific infrastructure component with these exact specifications.” Terraform tracks each resource’s lifecycle and applies changes when your configuration changes.

Core components of a resource block

The three fundamental aspects of every Terraform resource block can be summarized and exemplified in the table below.

Component	What it means	Example
Resource type	The provider-specific type that identifies the real-world resource (determined by the provider)	`aws_instance`, `azurerm_virtual_machine`, `kubernetes_pod`
Resource name (label)	A unique identifier within your Terraform configuration used to reference the resource	`web`, `db`, `prod_repo`
Arguments (configuration)	The settings that control how the resource is created (required and optional arguments depend on the provider)	`ami`, `instance_type`, `subnet_id`, `tags`

Simple EC2 example

Below is a minimal, common example that shows two EC2 instances (a web server and a database) and illustrates the resource block structure: the resource keyword, the provider resource type, the Terraform-local name, and the argument block.

resource "aws_instance" "web" {
  ami           = "ami-012345"
  instance_type = "t2.micro"

  key_name  = "prd-web-key"
  subnet_id = "subnet_12345abc"

  tags = {
    Name = "prd-web-svr_01"
  }
}

resource "aws_instance" "db" {
  ami           = "ami-0c55b159"
  instance_type = "m5.4xlarge"
}

Key notes from the example:

The Terraform label (web, db) is internal to your configuration and does not automatically become the cloud provider’s display name.
The provider may expose a name, tags, or similar argument that controls what you see in the provider console.
Reuse the same resource type multiple times with different names to create distinct resources.
Prefer meaningful labels to make your configuration readable and maintainable.

Understanding resource arguments

Resource arguments map directly to the real-world resource properties. If you normally pick an AMI, instance type, subnet, or SSH key in the provider console, you provide the same values as arguments in the resource block. Always consult the provider documentation for required and optional arguments: https://registry.terraform.io/.

Provider arguments differ between providers and even between resource types. Omitting required arguments will cause plan/apply failures — check the provider docs for required fields, default values, and argument types.

Example: A small web application architecture

Here’s a compact, realistic example showing multiple resources that form a typical web application: a load balancer, a firewall policy, a web server, and a database. These can live together in a single Terraform file (for example, webapp.tf) and demonstrate multi-provider usage.

A presentation slide titled "Resource Block" showing a vertical diagram of cloud infrastructure components — icons and labels for Load Balancer, Firewall Rule, Virtual Machine, and Database inside a bordered panel. The slide includes HashiCorp Terraform branding and the presenter name Bryan Krausen.

resource "aws_lb" "public_load_balancer" {
  name               = "prd-web-lb"
  load_balancer_type = "network"
}

resource "fortios_firewall_policy" "allow_web_https" {
  action = "accept"
  name   = "allow_web_443"
}

resource "aws_instance" "web" {
  instance_type = "t3.large"
  ami           = "ami-0c55b159"
}

resource "aws_db_instance" "prd_db" {
  engine         = "mysql"
  instance_class = "db.t3.large"
}

Notes on this architecture:

aws_lb.public_load_balancer is the Terraform resource identifier: type aws_lb + name public_load_balancer. The internal name argument (prd-web-lb) appears in AWS.
Different providers (AWS and FortiOS in this example) can be used together while preserving the same Terraform resource block structure.
Group related resources in the same file or logical modules to improve organization.

Resource referencing and implicit dependencies

Terraform makes it easy to reference attributes from one resource in another using the pattern resource_type.resource_name.attribute. When you reference one resource from another, Terraform builds an implicit dependency graph and performs operations in the correct order. Example with GitHub resources that demonstrates references and implicit ordering:

resource "github_repository" "prod_repo" {
  name       = "prod-app-xyz-repo"
  visibility = "private"
}

resource "github_branch" "default" {
  repository = github_repository.prod_repo.name
  branch     = "main"
}

resource "github_branch_default" "default" {
  repository = github_repository.prod_repo.name
  branch     = github_branch.default.branch
}

Explanation:

github_repository.prod_repo is created first.
github_branch.default references github_repository.prod_repo.name to create a branch on that repository.
github_branch_default.default references github_branch.default.branch to set the default branch.
Terraform infers the creation order from these references and plans/apply accordingly.

Using resource references creates implicit dependencies. Terraform analyzes these references to determine the correct creation order so dependent resources are created only after the resources they reference.

Naming rules and best practices

Resource names (the Terraform label after the type) must start with a letter or underscore and may contain letters, digits, underscores, and dashes. Use consistent naming conventions (e.g., snake_case).
Use descriptive names to convey purpose, environment, and role (e.g., dev_test_server, prod_db).
Use resource attributes (name, tags, etc.) for values that should appear in the provider console. The Terraform label is local to your configuration and not necessarily visible in the cloud console.
Prefer modularization: move repeating patterns into modules to reduce duplication and improve reuse.
Keep secrets out of your configuration and use secret managers or environment variables. Never commit credentials to version control.

Wrap-up

Resource blocks are the primary mechanism for declaring and managing infrastructure with Terraform. They let you define what to create, how to configure it, and how resources relate to one another. After mastering resource types, arguments, and referencing, you can model complex, multi-provider infrastructure with a consistent, declarative approach. Further reading and references

Terraform Registry (providers & resource docs): https://registry.terraform.io/
Terraform Language docs: https://www.terraform.io/docs/language/index.html

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Creating Infrastructure with Resource Blocks

What a resource block does

Core components of a resource block

Simple EC2 example

Understanding resource arguments

Example: A small web application architecture

Resource referencing and implicit dependencies

Naming rules and best practices

Wrap-up

Watch Video

Practice Lab

​What a resource block does

​Core components of a resource block

​Simple EC2 example

​Understanding resource arguments

​Example: A small web application architecture

​Resource referencing and implicit dependencies

​Naming rules and best practices

​Wrap-up

Watch Video

Practice Lab

What a resource block does

Core components of a resource block

Simple EC2 example

Understanding resource arguments

Example: A small web application architecture

Resource referencing and implicit dependencies

Naming rules and best practices

Wrap-up