Variables, Custom Type Constraints & Validation Rules

The Big Idea

Hardcoding values like CIDR blocks, instance sizes, and environment names directly inside your resource declarations makes your code brittle, impossible to reuse across environments, and prone to copy-paste drift.

Input Variables serve as the parameters of your infrastructure modules. Like function arguments in programming, they define what callers can customize while establishing strict type constraints, default fallbacks, and human-friendly documentation.

Modern Terraform allows you to build defensive infrastructure through Custom Validation Rules. Instead of waiting for a 15-minute AWS API call to fail because an AMI ID was invalid or an environment name had uppercase letters, you can enforce validation rules that fail instantaneously during the local planning phase.

Production Variable Validation & Computed Locals

# variables.tf: Defensive input variable with custom validation
variable "environment" {
  type        = string
  description = "Deployment environment tier (dev, staging, or prod)"

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "The environment variable must be exactly one of: dev, staging, or prod."
  }
}

variable "vpc_cidr" {
  type        = string
  default     = "10.0.0.0/16"
  description = "IPv4 CIDR block for the VPC"

  validation {
    condition     = can(cidrhost(var.vpc_cidr, 0)) && endswith(var.vpc_cidr, "/16")
    error_message = "VPC CIDR must be a valid IPv4 address block with a /16 prefix."
  }
}

# locals.tf: Compute derived values and standard tagging policies
locals {
  is_production = var.environment == "prod"
  
  # Standard tagging contract
  standard_tags = {
    Environment = var.environment
    ManagedBy   = "terraform"
    BillingCode = local.is_production ? "CORP-PROD-01" : "CORP-DEV-NONPROD"
  }
}