This is part of a collection of articles covering an Introduction to Advanced Terraform, it is deliberately of a certain style, you can find out more in the first post.

Introduction

In case you missed it, I covered these topics in the series:

  • Setting your code up for multi-region infrastructure from the off: link
    • Setting up your credentials so that Terraform can access your account.
    • Defining and using multi-region aliased providers.
    • An example of how to deploy a multi-region infrastructure.
  • Terraform data structures, including objects, maps, lists and sets: link
    • Will mostly focus on Objects and Tuples
  • Terraform workspaces and Environments [link]
  • User-friendly Terraform: link
    • A technique for writing Terraform code that will allow other users to easily understand and interact with your infrastructure.
  • Flattening data in Terraform, a deep-dive into flattening and combining data structures: link
    • Keeping your local's definitions clean and easy to use/read.
    • Why you might flatten data and some detailed examples of how to do it.
    • A fully dynamic example of Terraform without child modules.
  • Handling remote state link

The Wrap-Up

This article is not just the sum of the parts, I will bring the concepts together with additional code to provide a fully formed example of how to write terraform code without child modules that is dynamic, and while there is complexity, I think (once understood) it is easy to maintain, in fact, with the code being in the root module it is more visible and easier to troubleshoot than if it were in a child module.

The Code

The code is available in the ArryWalkerCodebase GitHub repository.

I won't walk through every line of code, but I will pick out some references to other articles and notable additions. I've split the code out into logical files to make them more manageable and I've added code for other regions.

Regional vs Global Resources

Global Resources

IAM resources in ec2-iam.tf are not constrained by regional limitations, so they do not need to have a provider set and we don't need to repeat blocks of code for each region.

Similarly, these snippets of flattening code do not need to be regional:

  • flatten_ec2.tf because it's just taking the count value and creating a map of maps from that.
  • flatten_vpc.tf because it's just extracting the subnets out of a tuple and assigning an Availability Zone to them which can be used in subnet resource naming.

Regional Resources

Pretty much everything else needs to be regional, whether that's the creation of the VPC, subnets, EC2, etc. Or the flattening and merging of route tables, routes and EC2 Instances.

Where this is the case I've added blocks for each, starting with Dublin (eu-west-1), then Virginia (us-east-1) and finally Mumbai (ap-south-1).

Summary

I've taken the preparation we've put in from Terraform setup, Providers and Multi-Region Deployments, User-friendly Terraform and Flattening data in Terraform and added to them to create a fully dynamic Terraform configuration that can be used to deploy multi-region infrastructure.

The series also covered Terraform data structures, Terraform workspaces and Environments and Handling remote state.

I hope this provides some value to you, and I hope you've enjoyed the series. If you have any questions or comments, please feel free to reach out to me on Email, X or Threads