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.

People ask me all the time. What certs should I get? What skills do I need? Where do I even start with Cloud, DevOps, or SRE? It comes from everywhere. Beginners trying to break in, career changers pivoting from other fields, senior engineers looking to fill gaps or pick up something new. For a while I would tell them I’d put together a learning plan for them. And then I wouldn’t. Life gets busy, things slip, and I’d end up feeling guilty about promises I didn’t keep.

If you’ve been paying attention to the AI space, you’ve probably seen Claude Code pop up. It’s Anthropic’s CLI tool that lets you use Claude directly in your terminal to write code, debug issues, and interact with your codebase. It’s like having a senior engineer sitting next to you, except it doesn’t steal your lunch from the fridge.

Look, I know there are probably a million blog posts about Claude Code and Bedrock at this point. I’m not here to write the definitive guide. I just want to share how I’m actually using it as an SRE who lives in AWS every day, and why the Bedrock piece specifically matters for folks like us.

Hi, my name is Samuel Tillman, but you can call me Sam. I’m an IT Professional currently working as a Staff Site Reliability Engineer for the National Basketball Association. I spend most of my days waist deep in AWS infrastructure, Terraform, and whatever else is needed to keep systems running. I’ve been doing this tech thing for a while, so you you’d think maintaining a blog would be easy.

It ain’t…