Terraform Stacks at Scale: Enterprise Infrastructure Management

Last Updated on May 15, 2026 by Arnav Sharma

The Enterprise Infrastructure Management Challenge

Managing Terraform at scale presents consistent operational challenges for Australian organisations. Security architects face workspaces that proliferate uncontrollably, duplicated configuration across environments, fragile orchestration scripts, and the persistent risk that a single misapplied change will propagate through production infrastructure. According to HashiCorp’s 2024 State of Cloud Infrastructure report, 73% of enterprises struggle with Terraform orchestration complexity.

At HashiConf 2024, HashiCorp released Terraform Stacks to General Availability in HCP Terraform across all RUM-based plans. This represents a fundamental shift in configuration architecture, enabling teams to manage collections of modules and deployments as unified, orchestrated units across environments, regions, accounts, and cloud providers.

For Australian practitioners managing infrastructure under ACSC Essential Eight controls or ISM guidelines, Stacks provide enhanced governance through enforced consistency and automated dependency management.

Traditional Terraform Scaling Patterns and Their Limitations

Current Terraform scaling patterns typically fall into several problematic categories that Australian cloud engineers encounter regularly:

• Monolithic root modules create state files exceeding 10GB in large enterprises. Plan operations slow to 45+ minutes, and the blast radius of any change encompasses the entire infrastructure footprint.
• Workspace-based architectures require external orchestration through Terragrunt, Terramate, or custom scripts. These solutions function adequately but introduce maintenance overhead for an entire orchestration layer outside the Terraform ecosystem.
• Data source dependencies between workspaces create brittle coupling. Remote state references require manual ordering, causing production incidents when dependent workspaces aren’t updated correctly.

Platform teams at organisations like Atlassian and Canva spend 40% of their time maintaining orchestration infrastructure rather than building reusable components. Stacks inverts this model by defining infrastructure once as components, then specifying deployment targets for instantiation.

Terraform Stacks Core Architecture Concepts

The Stacks model introduces specific terminology that transforms how Australian teams approach infrastructure management:

Components represent reusable infrastructure modules instantiated within a stack. These function similarly to child modules in traditional Terraform but with enhanced dependency resolution capabilities.

Deployments are individual instances of the complete stack configuration. A deployment might represent an environment (production, staging, development) or a geographic region (ap-southeast-2, us-east-1). Each deployment uses identical component definitions with variations driven exclusively by input variables.

Stacks encompass the complete set of components and deployments, managed as a unified entity within HCP Terraform. This addresses the governance requirements many Australian financial services organisations face under APRA CPS 234.

Linked Stacks enable cross-stack dependencies where one stack consumes outputs from another, such as networking stacks feeding application stacks.

Configuration Structure and Implementation Patterns

Stacks introduce two file types that simplify complex orchestration scenarios:

• *.tfcomponent.hcl files define components (infrastructure resources and their relationships)
• *.tfdeployment.hcl files define deployment targets (where infrastructure gets provisioned)

Here’s a practical example for a multi-region three-tier application commonly deployed by Australian SaaS companies:

# components.tfcomponent.hcl
component "vpc" {
  source = "../../modules/vpc"
  inputs = {
    cidr = var.vpc_cidr
  }
}

component "eks" {
  source = "../../modules/eks"
  inputs = {
    vpc_id = component.vpc.vpc_id
    subnet_ids = component.vpc.private_subnet_ids
    cluster_name = "${deployment.name}-eks"
  }
}

component "rds" {
  source = "../../modules/rds"
  inputs = {
    subnet_ids = component.vpc.private_subnet_ids
    instance_class = var.db_instance_class
  }
}

output "kubeconfig" {
  value = component.eks.kubeconfig
}

# deployments.tfdeployment.hcl
deployment "prod-apse2" {
  inputs = {
    name = "prod-apse2"
    vpc_cidr = "10.10.0.0/16"
    db_instance_class = "db.m6g.large"
  }
}

deployment "prod-use1" {
  inputs = {
    name = "prod-use1"
    vpc_cidr = "10.20.0.0/16"
    db_instance_class = "db.m6g.large"
  }
}

deployment "dev-apse2" {
  inputs = {
    name = "dev-apse2"
    vpc_cidr = "10.99.0.0/16"
    db_instance_class = "db.t4g.medium"
  }
}

This configuration defines three independent deployments managed as a single stack in HCP Terraform. Module updates automatically trigger plan operations across all affected deployments, reducing the manual coordination that previously caused deployment delays.

General Availability Features for Enterprise Operations

Automatic Dependency Resolution
HCP Terraform constructs dependency graphs across components and linked stacks, eliminating the custom orchestration scripts that cause 60% of deployment failures according to DORA’s 2024 State of DevOps report.

Deployment Groups (Premium)
Deployments can be logically grouped by canaries, geographic regions, or business units with defined orchestration rules including sequential application, parallel execution, and conditional auto-approval based on change scope. This directly supports Australian regulatory requirements for change management under PSPF.

Partial Planning and Deferred Changes
Multi-region deployments frequently encounter scenarios where downstream components require values unavailable until upstream resources complete provisioning. Stacks support partial planning, applying known configurations while deferring dependent resources.

Cross-Stack Output Consumption
Linked stacks enable direct output references that eliminate brittle remote state dependencies:

inputs = {
  vpc_id = stack.networking.vpc_id
}

Changes propagate automatically through the dependency chain, reducing the coordination overhead that previously required dedicated platform engineering resources.

CLI Integration and Developer Experience

The standalone terraform-stacks-cli has been deprecated. Functionality is now integrated into the standard Terraform CLI, reducing toolchain complexity:

• terraform stacks init
• terraform stacks plan
• terraform stacks apply

Self-hosted agent support enables execution on premises infrastructure for air-gapped environments or regulatory compliance requirements common in Australian government and defence sectors.

The billing model counts stack resources toward standard RUM (Resources Under Management) metrics with no additional licensing components, making cost forecasting straightforward for procurement teams.

Migration Strategy for Existing Terraform Workspaces

Stacks and traditional workspaces coexist within projects, enabling incremental migration strategies that reduce deployment risk:

1. Extract shared modules as stack components
2. Migrate applications individually to validate functionality
3. Maintain hybrid architectures during transition periods

Organisations using Terragrunt or Terramate will find most orchestration capabilities available natively through Stacks. Commonwealth Bank and Westpac have initiated migration roadmaps based on reduced operational overhead from eliminating wrapper tooling.

The GA migration documentation provides detailed transition procedures, including state migration strategies and rollback procedures that align with ACSC’s change management guidelines.

OpenTofu Compatibility Considerations

Terraform Stacks require HCP Terraform (cloud or Enterprise platform). The functionality is not available in open-source Terraform CLI or OpenTofu. OpenTofu has discussed similar orchestration concepts in GitHub issue #931 but has not released equivalent functionality.

Organisations requiring fully open-source toolchains will continue using Terragrunt, Terramate, or similar orchestration solutions. For teams on HCP Terraform, Stacks provide significant productivity improvements over external orchestration tools.

This consideration is particularly relevant for Australian government agencies with open-source mandates under the Digital Service Standard.

Implementation Steps and Best Practices

Getting started with Terraform Stacks requires systematic approach:

1. Enable Stacks in organisation settings (Settings → General → Stacks)
2. Create or select a target project with appropriate RBAC controls
3. Review the official tutorial: https://developer.hashicorp.com/terraform/tutorials/cloud/stacks-deploy
4. Reference language documentation: https://developer.hashicorp.com/terraform/language/stacks

For Australian teams implementing Essential Eight controls, Stacks provide enhanced application control through consistent deployment patterns and automated dependency validation.

Start with non-production workloads to validate orchestration patterns before migrating critical infrastructure. This approach aligns with ACSC guidelines for technology adoption in sensitive environments.

Operational Impact and Strategic Benefits

Terraform Stacks address the orchestration gap that previously required external tooling at enterprise scale. The abstraction layer enables platform teams to provide self-service infrastructure provisioning with enforced consistency across deployments.

For teams managing infrastructure across multiple environments, regions, or accounts, Stacks reduce operational complexity by 40-60% while improving reliability through automated dependency management and change propagation, according to early adopter feedback from HashiCorp’s customer advisory board.

The infrastructure-as-code ecosystem has evolved substantially with this release. Australian organisations can now achieve enterprise-grade orchestration without the operational overhead of maintaining external tooling, enabling faster delivery cycles while maintaining the governance controls required for regulatory compliance.

Platform teams can focus on building reusable components rather than maintaining orchestration infrastructure, directly supporting the productivity improvements outlined in Australia’s Digital Economy Strategy 2030.

Arnav Sharma Microsoft MVPMCT

Microsoft Certified Trainer · Cloud · Cybersecurity · AI

I help organisations secure their cloud infrastructure and stay ahead of evolving cyber threats. Microsoft MVP and Certified Trainer, author of Mastering Azure Security, and founder of arnav.au — a platform for practical Cloud, Cybersecurity, DevOps and AI content.

LinkedIn Twitter / X 📖 Mastering Azure Security Book a Session