Micro Teams

Bootstrapping your organisation for delivery on AWS
Find the git book version here: https://app.gitbook.com/s/PTLidBS6Vrblh1f6EYpk/
Micro-teams is a repo that highlights the organizational structure benefits of using the aws-cdk with GitHub OpenID Connect.
It is designed around a tiered approach to AWS privileges, but with full transparency to the organisation, via the mono-repo.
It also provides account level formatting functionality through the AWS CDK, to keep a single typescript tool chain and encourage cross team communication.

Using Micro teams

To get started developing your own world class AWS estate use the provided CLI.
The CLI will create a project structure with example CI pipelines for GitHub and CircleCI.


  • Single monorepo management
  • Base layer infrastructure for Roles, and Teams with the SSO and AWS CDK
  • Shared layer infrastructure for common components like event streams
  • Service layer infrastructure for decoupled services such as user management and web applications.

Turtles all the way down

The focus on full-stack infrastructure as code for managing teams tends to develop toward:
  • A platform team, that owns the AWS landing zone using terraform
  • A collection of smaller service teams that are:
    • Given an new AWS account
    • Have actions restricted by permission boundaries and SSO roles
Micro teams provides all this as an example in infrastructure as code.
It is good to set out with the correct components in place, and at a low cost, so that the configuration is open and extensible.


Users (If you are an Org of one, then you are all these users!)
1 -Bootstrap
Far too high
Root Account Admin
You must provide credentials to a manual trigger in GitHub
This stack can create and update the OpenID Connect link with GitHub that ships all code, and creates all users.
2 -Base
Platform Teams, SecOps
GitHub actions via OIDC assumed Role
A low-level cdk stack(s) for users, permission boundaries, formatting SSO permission sets and in general administrating your AWS estate.
3 - Infrastructure
Architects, Engineering Managers and
GitHub actions via OIDC assumed Role
A mid-level cdk stack(s) for creating shared components such as cross account event buses, central data warehouses and DNS management.
4 - Services
GitHub actions via OIDC assumed Role
A high-level stack(s) for creating products on top of the configured AWS estate

Strong conventions

In general following strong conventions is a great way to start out, and continue.
This isn't about being prescriptive, or limiting experimentation, its about:
  • Following some known standard practices that correlate well to success.
  • Choosing well established tools and frameworks that do the undifferentiated heavy lifting.
This really means you might bootstrap a project like:
npm init --force
yarn add --dev lerna syncpack
yarn lerna init --npm-client=yarn
yarn syncpack format fix-mismatches
Why? Convention, convention is others bringing well tested tools, with good documentation.
Last modified 1yr ago