AWS with Terraform (Day 05)

Mastering Terraform Variables: Essential Guide to Inputs, Locals, and Outputs for AWS Infrastructure

Imagine you build AWS resources like S3 buckets, VPCs, and EC2 instances. You tag them all with "environment = dev" over and over. One typo turns "dev" into "staging" in just one spot. Chaos hits—your setup looks messy and inconsistent.

Hardcoded values cause big headaches. You repeat "dev" across hundreds of resources. Want to switch to "staging"? Hunt through every file and fix them one by one. Errors sneak in easily. Changes take forever.

Variables fix this fast. They let you set a value once, like "environment = dev". Use it everywhere with a simple reference. Update once, and it shifts across your whole Terraform config. Your code stays clean, flexible, and ready for dev, staging, or prod.

Understanding the Purpose-Based Categories of Terraform Variables

Terraform sorts variables by purpose. You get input, locals, and output types. Each serves a clear job in your AWS setup.

Input Variables: Taking Dynamic Configuration from the User

Input variables pull values from outside your code. You define them to handle settings like environment names or regions.

Basic syntax looks like this:

variable "environment" {
  default = "dev"
  type    = string
}

Set a default so it works out of the box. Change it later for other setups. One tweak updates tags on your S3 bucket, VPC, and EC2 instance. No more copy-paste mistakes.

This keeps your Terraform files DRY—Don't Repeat Yourself. Central changes save hours.

Local Values (Locals): Deriving Values Within Configuration

Locals create values inside your config. Pull from input vars or resource outputs to build new ones.

Say you mix a prefix and environment for bucket names. Define it once:

locals {
  bucket_name = "${var.prefix}-${var.environment}-bucket"
}

Reference local.bucket_name everywhere. It builds "ttwp-dev-bucket" automatically.

Locals shine for string joins or math. They cut repetition without exposing values outside.

Output Variables: Exposing Necessary Resource Attributes

Outputs share data after Terraform creates stuff. Grab IDs or ARNs from AWS resources.

Syntax is simple:

output "vpc_id" {
  value = aws_vpc.sample.id
}

Run terraform apply. See the VPC ID printed. Use terraform output later to check it.

Outputs link modules or scripts. Pass that EC2 instance ID to another config. Perfect for big AWS projects.

Leveraging Input Variables for Flexible Infrastructure Deployment

Input vars make your code adapt quick. Declare them early. Use them wide.

Declaring and Initializing Input Variables

Start with a variable block. Pick a name like "environment". Add a default value.

variable "environment" {
  default = "dev"
  type = string
}

No default? Terraform asks during plan. Type keeps things safe—string for text, number for counts.

This sets up your AWS tags right. One spot controls it all.

Accessing Variables Within Configuration Blocks

Reference with var.name. In tags: environment = var.environment.

For strings, use interpolation: "${var.environment}-vpc". It resolves to "dev-vpc".

Test it. Add to S3, VPC, EC2 blocks. Plan shows clean output. Your config stays tight.

Actionable Tip: Using Variables for Environment-Specific Tagging

Tag every resource the same way. Set var.environment = "dev".

• S3 bucket: tags = { Environment = var.environment }
• VPC: tags = { Environment = var.environment }
• EC2: tags = { Environment = var.environment }

Switch to "staging"? Change var once. Plan detects it. Apply rolls out tags everywhere. No misses.

This trick scales to thousands of resources in real AWS fleets.

Mastering Local Values for Simplified Configuration Management

Locals beat repeating vars. They compute on the fly inside your files.

Why Use Locals Instead of Repeating Input Variables?

Inputs come from users. Locals stay internal. Mix vars into new values without clutter.

Skip long strings each time. Build once. Reference short.

Your code reads easy. Changes flow smooth.

Constructing Complex Names and Attributes with Locals

Craft bucket names smart:

locals {
  bucket_name = "${var.channel}-${var.environment}-bucket"
}

var.channel = "tech-tutorials" plus "dev" makes "tech-tutorials-dev-bucket".

Use in S3:

resource "aws_s3_bucket" "example" {
  bucket = local.bucket_name
}

Same for VPC names. One local rules all.

Add region: local.full_name = "${local.bucket_name}-${var.region}". Unique every time.

Advanced Use Case: Referencing Resource Attributes via Locals

Locals grab from resources too. Created a VPC? Capture its ID:

locals {
  vpc_id = aws_vpc.sample.id
}

Feed that to subnets or security groups. No hard lookups.

We'll dive deeper later. For now, it cleans chains of dependencies.

Controlling Data Flow with Output Variables

Outputs bridge your apply to the real world. They show what Terraform built.

Defining Outputs for Post-Apply Visibility

Declare with output:

output "ec2_id" {
  value = aws_instance.sample.id
}

Auto-prints after apply. No digging in AWS console.

List multiple: VPC ID, bucket name, instance state.

Referencing Computed Values in Outputs

Dot into resources: aws_vpc.sample.id. Copilot or docs confirm names.

Invalid? Plan catches most. Apply hits API for rest, like bad AMIs.

Fix and reapply. Outputs update.

Practical Application: Viewing Outputs After Deployment

After terraform apply, values show at bottom.

Lost them? Run terraform output. Grabs from state.

terraform output vpc_id picks one. Quick checks without full apply.

Terraform Variable Precedence: Determining Which Value Wins

Vars can set multiple ways. Precedence picks the winner. Order matters.

The Hierarchy of Variable Value Assignment (Low to High Precedence)

1. Default values (lowest—inside variable block).
2. tfvars files (auto-load terraform.tfvars).
3. Environment vars (export TF_VAR_environment=staging).
4. Command flags (-var highest).

Test it. Default "dev" loses to env var "stage".

Understanding and Utilizing terraform.tfvars

Make terraform.tfvars:

environment = "pre-prod"
region     = "us-east-1"

Auto-loads. Plan uses it over defaults.

Great for teams. Commit non-secrets here.

Using Command-Line Flags for Runtime Overrides

Top power: terraform plan -var 'environment=prod'.

Or -var-file=custom.tfvars. Beats all else.

Pass secrets safe—no files, no history. Ideal for CI/CD.

Diagram

Implementing Robust and Manageable Terraform Workflows

Master inputs for outside tweaks, locals for inside smarts, outputs for results.

Key points stick: Ditch hardcodes. Use vars for tags and names. Precedence keeps control clear.

Best practices? Defaults for fixed stuff. tfvars for envs. Flags or vaults for keys.

Clean up always: terraform destroy -auto-approve. Free your AWS account.

Here is the video link, do check it out: