Skip to main content

augint-org (ai-org)

AWS organization automation for Control Tower environments.

augint-org helps manage the parts of a multi-account AWS setup that sit around AWS Control Tower:

  • custom OUs such as Workloads
  • service-managed CloudFormation StackSets
  • custom Service Control Policies
  • IAM Identity Center permission assignment
  • GitHub Actions OIDC setup
  • DNS delegation helpers
  • a read-only cost role (billing-cost-reader) for the ai-agency GoHighLevel billing job

It is best understood as post-Control-Tower automation, not as a replacement for AWS Control Tower itself.

Project Health

Library Publishing Infrastructure PyPI Python License: MIT

📖 Documentation 🧪 Tests 📊 Coverage 🔒 Security ⚖️ Compliance

What It Does

The current codebase supports these workflows:

  • create and inspect organization structure around a Control Tower landing zone
  • deploy org-wide StackSets into governed OUs
  • attach a custom baseline SCP to Workloads
  • create GitHub OIDC trust for both the management account and member accounts
  • assign IAM Identity Center permission sets to AWS accounts
  • create delegated DNS hosted zones per account
  • deploy management-account stacks: the account lifecycle hook, the Forge broker's account-listing role, and the read-only billing-cost-reader role

Current Scope

Some parts of the repo are production-ready today, and some are not.

Implemented

  • scripts.org_setup: deploy management-account GitHub OIDC and OrgPipelineRole
  • scripts.deploy: deploy custom StackSets and the workloads-baseline SCP
  • scripts.status: inspect deployed StackSets, OUs, and SCPs
  • ai-org sso: assign and list IAM Identity Center access
  • ai-org dns delegate: create delegated Route53 zones
  • ai-org stackset: inspect and deploy StackSets

Not Implemented Yet

  • end-to-end account creation through ai-org account create

The current ai-org account create command is a placeholder that tells you to use AWS Control Tower Account Factory manually.

Architecture

The live organization model this repo is built around looks like this:

Control Tower (AWS Managed)
├── Security OU
│   ├── Audit Account
│   └── Log Archive Account
├── Sandbox OU
└── Workloads OU
    └── Workload accounts managed by this repo's StackSets and SCPs

Important details:

  • Security and Sandbox are created by AWS Control Tower.
  • Workloads is a custom OU layered on top.
  • both Sandbox and Workloads can receive the repo's auto-deployed StackSets.
  • the custom workloads-baseline SCP is attached only to Workloads.
  • production and staging are currently represented by account naming and OU choice, not by required nested Production and Staging OUs.

What Gets Deployed Automatically

The current StackSet registry auto-deploys these resources to both Workloads and Sandbox:

Resource Workloads OU Sandbox OU
S3 SAM artifacts bucket ✅ ✅
aws-sam-cli-cfn-exec-role ✅ ✅
GitHub OIDC provider ✅ ✅
SAMDeployRole ✅ ✅
API Gateway account logging role ✅ ✅
Budgets / anomaly detection / billing alarm ✅ ✅
Custom workloads-baseline SCP ✅ ❌

These StackSets are created but not auto-instanced:

  • monitoring
  • DNS delegation
  • log aggregation
  • ACM certificates

Prerequisites

Before using this repo, you should already have:

  • an AWS Control Tower landing zone deployed
  • IAM Identity Center enabled
  • an AWS CLI v2 SSO profile with management-account access
  • Python 3.12+
  • uv
  • a GitHub organization or repository to trust for OIDC

For new organizations, use the AWS Control Tower console first. This repo should be used after the landing zone is healthy.

Install

With uv

uv sync --all-groups

Editable Install

make install

Configuration

You can store personal defaults in ~/.ai-org.env:

AWS_PROFILE=org
DEFAULT_SSO_USER=sam
DEFAULT_PERMISSION_SET=AWSAdministratorAccess
NOTIFICATIONS_EMAIL=alerts@example.com
BUDGETS_MONTHLY_DEFAULT=1000
BUDGETS_ANOMALY_THRESHOLD=100

Or initialize it interactively:

uv run ai-org config init

For org-level deployment, create a project .env:

GH_REPO=augint-org
GH_ACCOUNT=Augmenting-Integrations
AWS_PROFILE=org
NOTIFICATIONS_EMAIL=alerts@example.com
BUDGETS_MONTHLY_DEFAULT=1000
BUDGETS_ANOMALY_THRESHOLD=100

Optional migration settings:

GH_REPO_LEGACY=old-repo-name
GH_ACCOUNT_SECONDARY=secondary-github-org

This is the current safe workflow.

1. Launch and validate AWS Control Tower manually

Use the AWS console to:

  • enable IAM Identity Center in the Control Tower home Region
  • create the landing zone
  • create or confirm the audit and log archive accounts
  • wait until the landing zone is ACTIVE

2. Create or register the Workloads OU

This repo assumes a top-level Workloads OU exists and is governed.

Create it in AWS Organizations, then register it in AWS Control Tower before deploying custom StackSets.

3. Deploy the management-account pipeline role

uv run python -m scripts.org_setup --profile org

This creates:

  • the management-account GitHub OIDC provider
  • OrgPipelineRole

4. Deploy org StackSets and SCPs

make deploy

5. Verify

uv run python -m scripts.status --profile org

Account Creation

Current Reality

Account creation is not wired through the public CLI yet.

uv run ai-org account create --help

The current implementation tells you to use AWS Control Tower Account Factory manually.

  1. Create the account in AWS Control Tower Account Factory.
  2. Place it in either Workloads or Sandbox.
  3. Wait for Control Tower provisioning to finish.
  4. Let StackSets auto-deploy based on OU placement.
  5. Use ai-org sso assign to add any additional human admins.
  6. Use ai-org dns delegate if the account needs a delegated DNS zone.

GitHub Actions Setup

Member accounts receive SAMDeployRole through the org-github-oidc StackSet.

Typical workflow usage:

name: Deploy
on:
  push:
    branches: [main, staging]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

    steps:
      - uses: actions/checkout@v4

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.AWS_ROLE_ARN }}
          aws-region: us-east-1

      - run: sam deploy

For management-account automation, use the OrgPipelineRole output from scripts.org_setup.

Common Commands

Configuration

uv run ai-org config init
uv run ai-org config show
uv run ai-org config get DEFAULT_SSO_USER
uv run ai-org config list-permission-sets

Accounts

uv run ai-org account list
uv run ai-org account get 123456789012
uv run ai-org account enrollment-status 123456789012

IAM Identity Center

uv run ai-org sso assign 123456789012 --principal founder@example.com
uv run ai-org sso list 123456789012
uv run ai-org sso sync --ou ou-xxxx-workloads --principal founder@example.com

StackSets

uv run ai-org stackset list
uv run ai-org stackset describe org-github-oidc
uv run ai-org stackset status 123456789012 --stackset org-github-oidc
uv run ai-org stackset deploy 123456789012 --stackset org-monitoring

DNS

uv run ai-org dns delegate "My Account Name" --prefix myapp

Scripted Org Operations

make setup
uv run python -m scripts.deploy --profile org
make status
make drift

Client Billing

Client AWS costs are invoiced from GoHighLevel by the ai-agency daily billing job (infra/sst/ghl-jobs.ts and docs/GHL.md in Augmenting-Integrations/ai-agency). This repo's part is the billing-cost-reader role in the management account (stacks/billing-cost-reader/). It allows ce:GetCostAndUsage, invoicing:ListInvoiceSummaries and organizations:ListAccounts, and trusts only that job's role. The earlier Stripe billing stack and the ai-org billing commands are removed.

Development

make lint
make format
make typecheck
make test
make pre-commit

Known Limitations

  • ai-org account create is not implemented yet.
  • the safest Control Tower bootstrap path is still manual console work.
  • documentation outside this README may still contain older references to Workloads/Production and Workloads/Staging.

Documentation

Resource Description
Architecture Guide design notes and historical decisions
Configuration Guide config values and examples
Development Guide local development and contribution
AWS Org Runbook current validated setup guide based on the live org

License

MIT License. See LICENSE.

Metadata

Release files for augint-org 0.14.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for augint-org 0.14.0
File Size Uploaded
augint_org-0.14.0.tar.gz 370.5 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for augint-org 0.14.0
File Interpreter ABI Platform
augint_org-0.14.0-py3-none-any.whl Python 3 none any Details

Total release size: 445.9 kB

Release files / augint_org-0.14.0.tar.gz

Download URL augint_org-0.14.0.tar.gz
Size 370.5 kB
Tags Source
SHA-256 checksum
How to use checksums
ac3cc62143223e08a423ffe1c098acb0c4bc4a99c7e7e8173b8d2e71e6cdd58a
BLAKE2b-256 checksum
How to use checksums
088a5e83d334741df3914fde472214ec81f9abea33320682af215ed746d5567e
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 4, 2026.

Transparency log

Release files / augint_org-0.14.0-py3-none-any.whl

Download URL augint_org-0.14.0-py3-none-any.whl
Size 75.4 kB
Tags Python 3
SHA-256 checksum
How to use checksums
889c04be244f8aeafbfe827a73b942708ef1eb241d2230fa07ef0eb8bb43261a
BLAKE2b-256 checksum
How to use checksums
ab470bd8b2f02a4444cd839859f7c6faa051daaf711e67e15b57f0d432487a97
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 4, 2026.

Transparency log

Release history Release notifications | RSS feed

0.17.0

2 release files

0.16.0

2 release files

0.15.0

2 release files

0.14.1

2 release files

This release

0.14.0 This release

2 release files

0.13.2

2 release files

0.11.0

2 release files

0.10.0

2 release files

0.9.0

2 release files

0.8.0

2 release files

0.7.1

2 release files

0.7.0

2 release files

0.6.2

2 release files

0.6.1

2 release files

0.6.0

2 release files

0.5.0

2 release files

0.4.0

2 release files

0.3.0

2 release files

0.2.2

2 release files

0.2.1

2 release files

0.2.0

2 release files

0.1.2

2 release files

0.1.1

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page