Last week I walked through Layer 0 : the organization itself, OUs, four member accounts, guardrail SCPs, a Terraform state backend, and GitHub OIDC, all managed from the management account and nothing else. That layer was deliberately inward: everything it touched lived in one account.

Layer 1 is where the platform stops being a skeleton and grows a nervous system. This is the landing zone, the shared identity, audit, and security backbone that every layer above it, including the EKS platform in Layer 2, quietly depends on. And it’s the first time Terraform reaches across account boundaries and leans on organization-wide services with delegated administration. Those two facts drive almost every interesting decision, and every single one of the gotchas, in this post.

Last week I laid out the whole platform : five accounts, an EKS-based internal developer platform, built in the open in layers. This week I want to go all the way down to the floor, Layer 0, the org bootstrap, because it’s where the most interesting tension in any infrastructure-as-code project lives: something has to exist before Terraform can run, and I refuse to store a secret in a public repo to make that happen.

Most public AWS examples are fragments. One account, one purpose, and, if you read closely, a quiet dependency on a stored credential or some prerequisite a human built by hand and never wrote down. They teach you the shape of a resource, not the shape of a system.

I wanted the other thing. So I’ve been building a complete AWS organization in the open: multiple accounts, an internal developer platform on Kubernetes, and a realistic demo workload, a fictional fishing-charter booking SaaS, because “hello world” doesn’t have a database, a queue, and async jobs. It’s MIT-licensed, it lives on GitHub, and the whole point is that you can fork it, set your variables, and stand up your own.