This feels brittle to me. I'd stick to creating layers by having separate root modules with their own state files (eg: in the example you could have a kubernete

This feels brittle to me. I'd stick to creating layers by having separate root modules with their own state files (eg: in the example you could have a kubernetes root module that was shared across developers, and a buckets root module for the S3 buckets) You'd then typically have multiple state files per root module applied with different tfvars to create multiple copies of the same infrastructure (eg: dev/stage/prod). Workspaces can help with this, especially when using terraform cloud. As other comments have mentioned you can use outputs to share data between state modules, and to make this nicer you can wrap the remote state blocks in a module generated from the outputs so that you can get intelisense/autocomplete (though it's a bit annoying that you can't plan speculatively across state files where output changes are involved) This page goes into a bit more detail about separating components of your infrastructure into discrete state files and talks about when (terraform cli) workspaces may or may not be appropriate https://developer.hashicorp.com/terraform/cli/workspaces https://developer.hashicorp.com/terraform/cli/workspaces In terms of creating the buckets per developer - I think there's a bigger question of do they need a bucket each or some larger subset of the infrastructure and this should guide how you organise things. It'll need to tie into your strategy around production infrastructure (eg: single Vs multi tenancy, and how you want to manage deploying to different regions). An aside, but I'd probably argue that for development purposes sharing a bucket but having your applications accept a bucket prefix (giving each developer a namespace of sorts) in addition to a bucket name is simpler, and lends itself to quicker ephemeral deployments that avoid the need to change underlying infrastructure