[FujiApple]

This is very similar to the layering approach I ended up with for a service I built a couple of years ago (AWS using Pulumi).

Global - Things from the AWS global region, notably DNS (DelegationSet and Zone) and IAM

Core - Semi-permanent per-stack resources such as secrets and certificates

Network - Network resources per-stack (ie. VPC & EC2)

Database - Database resources per-stack (i.e. RDS) and rotating secrets (via Lambda)

Application - Application resources per-stack (i.e. ECS)

Breakglass - Resources for breakglass shell access to the DMZ subnets

[hermanradtke]

What I like about this approach is that it maps well to different teams. The ops team can own the bottom 3 and product teams can own the top 3.

[stevekemp]

I'm using something similar at the moment, and it mostly works. There are issues now and again though - if the developers of a service own the "top" layers, and start adding new services then that often requires changes to the core.

For example if a team were to suddenly start using DynamoDB then the IAM roles for their application, in their account, suddenly need the permission to add/get records.

Most of the time the layers are distinct and the "ops" team can handle the core, leaving the application/service-specific stuff to the developers, but things do come up that have to be scheduled and coordinated across the layers/owners. It's a pain, but so far tolerable one.