Terragrunt multi-region project structure

[ttolson-code]

Hello,

I’m looking for advice on project structure for multi-region Terragrunt projects.

Today I’m using account → region → environment → units. I know some teams flip the middle two (i.e., account → environment → region).

The Gruntwork docs show (and explain) the account → region → environment pattern in their infrastructure-live guidance, plus _global folders at the account and region levels. Are there other Terragrunt docs that explain why region typically comes before environment, or is it just convention? I realize both approaches work; I’m mainly after pros/cons from those who’ve done this at scale.

Docs I’m looking at:

Gruntwork “Recommended Folder Structure” for infrastructure-live.
Gruntwork Docs

Example repo showing account/_global/region/_global/environment/resource.
GitHub

[RafaelWO]

I maintain a stack of approximately 60 Terragrunt units across three accounts and two regions per account. We use the folder structure account > region > environment > units.

Currently, we use different accounts as our environments, which makes environment always match the account, i.e. environment is redundant. This is also described in the docs:

Note that many organizations chose to isolate different environments by AWS account, and thus don't have a need for this level of granularity.
[source]

This structure works well for us - even despite the redundant environment directory 🙂

[sourava01]

I have been using terragrunt at scale for quite some time now (almost 1.5 years). We use environment > account > region. Within the region, we have kept following directories - application and shared. This has the following benefits

• environment > account means one account can host only one environment. This gives us isolation across environments which, I would say, is a must have at high scale.
• If you foresee having to host your account across multiple regions ever, you should definitely consider account > region. Some of our accounts utilize multiple regions so having this structure makes more sense.
• application contains the units specific to a single microservice. This gives us a service-centric structure for units.
• shared contains all shared resources like VPC, etc.

Hope this helps.