Every few months, we send out a newsletter to all Gruntwork customers that describes all the updates we’ve made since the last newsletter and news from the DevOps industry. Note that some of the links below may go to private repositories in the Gruntwork Infrastructure as Code Library that are only accessible to customers.

As always, if you have any questions or need help, email us at support@gruntwork.io!

Gruntwork Updates

Fundamentals of DevOps and Software Delivery has been published!

We’re excited to share that Gruntwork Co-Founder Jim Brickman has just released his latest book, Fundamentals of DevOps and Software Delivery, a hands-on guide to running and maintaining software in production. It's the 3rd book he's published, and we think, its his best one yet!

I read every DevOps book out there trying to find a comprehensive resource that teaches software delivery end-to-end, but I never found one. So I wrote it.

This book is a hands-on guide to software delivery. It includes dozens of examples of how to run production systems, starting with the basics, a single server, and working up to microservices in a Kubernetes cluster with a service mesh, automated deployment pipeline, & more. — Jim

Whether you’re a DevOps practitioner or a leader aiming to modernize your software delivery processes, this book provides actionable insights drawn from years of real-world experience building and scaling production infrastructure. Learn more about the book here.

AWS VPC Library v2 Architecture Preview

The latest VPC v2 modules represent a significant evolution in how we approach network infrastructure definition. Built with lessons learned from years of real-world deployments, these modules introduce what we hope you’ll find to be a more intuitive and maintainable approach to designing cloud network architectures.

The VPC v2 modules introduce three core principles that address the most common pain points in traditional network management with Infrastructure-as-Code (IaC) tools - Explicit Resource Management, an Edge-Based architecture and AWS Alignment.

Explicit Resource Management

Some of the loudest feedback we’ve heard working with existing VPC module has been the challenge of implicitly created resources. The prior module would automatically provisioned behind the scenes – route tables, security groups, NAT gateways etc. that could consume costs without clear visibility.

VPC v2 modules eliminate this by requiring explicit definition of every resource. When you deploy a VPC using these modules, you'll know exactly what gets created, when it gets created, and why it exists. This explicit approach provides several benefits:

• Cost transparency: No surprise charges from resources you didn't know were being created
• Security clarity: Every security group, route, and access control is intentionally defined
• Maintenance simplicity: When troubleshooting, you know exactly what resources are part of your infrastructure
• Compliance confidence: Auditors can clearly see every component of your network architecture

Edge-Based Architecture

Traditional network design often focuses on individual components – VPCs, Transit Gateways, Network Firewalls – with routing as a side product.

VPC v2 clearly separates "nodes" and "edges" (also referred to as relationships or links). In this way, VPC v2 modules provide the ability to properly deploy network resources and then, using the outputs, explicitly define routes for traffic to flow.

This relationship-focused model makes it easier to understand traffic flows, troubleshoot connectivity issues, and implement security policies that follow the principle of least privilege.

AWS-Native Alignment

One of the biggest challenges with many Terraform modules is the disconnect between the module's abstractions and the underlying AWS resources. VPC v2 modules solve this by maintaining close alignment with the official AWS Terraform provider resources.

This alignment manifests in several ways:

• Consistent naming conventions: Resource names in the module match AWS naming patterns, making it easier to correlate Terraform code with AWS console resources
• Matching descriptions: Documentation and resource descriptions use AWS terminology, reducing the cognitive load when switching between Terraform and AWS contexts
• Preserved defaults: Where AWS resources have sensible defaults, the modules preserve them rather than imposing alternatives
• Direct parameter mapping: Module parameters closely mirror the underlying AWS resource parameters, reducing confusion and enabling easier customization

This approach means that your existing AWS knowledge translates directly to working with these modules. Whether you're reading AWS Provider documentation, working in the console, or writing Terraform code, you're speaking the same language throughout.

EKS Library Updates

Announcing v1 of Our EKS Terraform Module: Modernization and Exciting New Features

We’re excited to announce that our EKS Library module has officially reached v1! With this milestone, we’re adopting semantic versioning to provide clear, predictable updates for all users. This marks a new era for the module, focused on stability, modernization, and rapid support for the latest AWS EKS features.

Support for EKS 1.33

Work is already underway to deliver support for EKS 1.33. As AWS continues to evolve its managed Kubernetes offering, we are committed to ensuring our module keeps pace. With EKS 1.33, there are some important changes to be aware of:

• Amazon Linux 2 Deprecation: AWS is dropping support for Amazon Linux 2 worker nodes in EKS 1.33. If you are currently using Amazon Linux 2, now is the time to plan your migration.
• Amazon Linux 2023 Support: We’re adding full support and comprehensive testing for Amazon Linux 2023, ensuring a smooth transition for users and taking advantage of the latest performance, security, and lifecycle improvements.

Stay tuned for more details as we finalize and release EKS 1.33 support!

Under the Hood Improvements

Our journey to v1 isn’t just about new Kubernetes versions—it’s also about making the module more robust, flexible, and future-ready. Here’s what’s being planned behind the scenes:

• Kubergrunt Dependency Removal: We’re eliminated the hard dependency on kubergrunt, reducing complexity and external dependencies. This streamlines deployments and simplifies upgrades and general stability of the module.
• First-Class GitOps Support: This will be specific to many of the core-services sub-modules that we are looking to provide first-class support for GitOps workflows, making the module more flexible for additional declarative workflows.
• Enhanced Worker Node Capabilities: We’re updating worker node management to support the latest node types and configurations, providing more flexibility and scalability options for your workloads.

Looking Ahead

With v1, our focus is on delivering stability, rapid feature adoption, and a more predictable experience for all users. We’re excited about these improvements and look forward to your feedback as we continue to evolve the module.

Keep an eye out for upcoming releases and detailed guides on migrating to Amazon Linux 2023 and leveraging our new GitOps capabilities!

Terragrunt Updates

Bare Includes Deprecated

The use of Terragrunt include blocks of the following form:

include {
	path = find_in_parent_folders("root.hcl")
}

Have been deprecated in favor of include blocks like the following:

include "root" {
	path = find_in_parent_folders("root.hcl")
}

If you are currently using bare include blocks, know that they will be backwards compatible until at least Terragrunt 2.0, so you have time to migrate.

Introduction of the constraint_check HCL function

The constraint_check HCL function has been added to Terragrunt configurations to support driving configuration based on semantic versions.

feature "module_version" {
  default = "1.2.3"
}

locals {
  module_version       = feature.module_version.value
  needs_v2_adjustments = constraint_check(local.module_version, ">= 2.0.0")
}

terraform {
  source = "github.com/my-org/my-module.git//?ref=v${local.module_version}"
}

inputs = !local.needs_v2_adjustments ? {
  old_module_input_name = "old_module_input_value"
} : {
  new_module_input_name = "new_module_input_value"
}

You can use this function to dynamically adjust inputs based on the versions of OpenTofu/Terraform modules, and handle breaking changes in module versions smoothly.

The report experiment has been added

Providing experimental support for the functionality outlined in #3628, Terragrunt has a new experiment named report which triggers the printing of run summaries at the end of runs

$ terragrunt run --all plan --experiment report

# Omitted for brevity...

❯❯ Run Summary  3 units  62ms
   ────────────────────────────
   Succeeded    3

The experiment also provides the --summary-per-unit flag, which provides more detailed information for the runs in the summary.

$ terragrunt run --all plan --experiment report --summary-per-unit

# Omitted for brevity...

❯❯ Run Summary  3 units     10m
   ──────────────────────────────
   Succeeded (3)
      long-running-unit     10m
      medium-running-unit   12s
      short-running-unit    5ms

In addition, you can generate a full report of each unit that was run to programmatically assess the outcome of each unit.

# Will generate a CSV report
$ terragrunt run --all plan --report-file report.csv

# Will generate a JSON report
$ terragrunt run --all plan --report-file report.json

‍

# report.csv

Name,Started,Ended,Result,Reason,Cause
first-exclude,2025-06-05T16:28:41-04:00,2025-06-05T16:28:41-04:00,excluded,exclude block,
second-exclude,2025-06-05T16:28:41-04:00,2025-06-05T16:28:41-04:00,excluded,exclude block,
first-failure,2025-06-05T16:28:41-04:00,2025-06-05T16:28:42-04:00,failed,run error,
first-success,2025-06-05T16:28:41-04:00,2025-06-05T16:28:41-04:00,succeeded,,
second-failure,2025-06-05T16:28:41-04:00,2025-06-05T16:28:42-04:00,failed,run error,
second-success,2025-06-05T16:28:41-04:00,2025-06-05T16:28:41-04:00,succeeded,,
second-early-exit,2025-06-05T16:28:42-04:00,2025-06-05T16:28:42-04:00,early exit,run error,
first-early-exit,2025-06-05T16:28:42-04:00,2025-06-05T16:28:42-04:00,early exit,run error,

‍

# report.json

[
  {
    "Name": "first-exclude",
    "Started": "2025-06-05T16:28:41-04:00",
    "Ended": "2025-06-05T16:28:41-04:00",
    "Result": "excluded",
    "Reason": "exclude block"
  },
  {
    "Name": "first-success",
    "Started": "2025-06-05T16:28:41-04:00",
    "Ended": "2025-06-05T16:28:41-04:00",
    "Result": "succeeded"
  }
]

You can learn more about the Run Report feature in Terragrunt documentation.

Terratest Updates

Terratest now supports the use of the GOOGLE_OAUTH_ACCESS_TOKEN environment variable directly. This enables authentication with Google Cloud using workload identity service accounts and no locally-stored key file.  This change makes it significantly easier to use terratest with GCP in CI systems that support workload identity federation (relevant PR).

Terratest now supports initializing and testing Terragrunt stacks by introducing new terragrunt specific module under modules/terragrunt (relevant PR).

OpenTofu 1.10 Release

OpenTofu release 1.10 was published on June 23rd, 2025 with a host of very significant updates!  Several of these updates were developed in coordination with the Terragrunt team, in particular the native global provider cache lock and OpenTelemetry tracing, that will significantly benefit users when used as a combination of Terragrunt and OpenTofu (see Terragrunt & OpenTofu Better Together for more on that). Stay tuned for specific announcements from the Terragrunt team on that front.

• OCI Registry Support – Distribute providers & modules via Docker Hub, Harbor, or any container registry. Perfect for air-gapped environments!
• Native S3 State Locking – No more DynamoDB! Simply enable use_lockfile = true and reduce infrastructure complexity.
• OpenTelemetry Tracing – Debug and optimize your OpenTofu runs with privacy-focused, local-only observability. In collaboration with the OpenTofu team, traces natively propagate from Terragrunt to OpenTofu, giving deep insight into IaC operations.
• Global Provider Cache Lock - Safely access shared OpenTofu provider plugin cache concurrently across OpenTofu runs, natively through filesystem locking. This is especially important for Terragrunt users, as it's a massive performance improvement for Terragrunt runs.
• Deprecation Support – Module authors can now gracefully evolve APIs with clear migration messages.
• Enhanced moved blocks – Migrate between different resource types seamlessly.

‍