Operable
An Operable system can be understood, operated, troubleshot and changed safely by humans who did not build it. If only one person knows how it works, it is not production-ready. The AWS Baseline is delivered with the roles, the ownership rules, the runbooks and the conventions that let the next engineer operate it at 3 AM.
Who operates what
The Team Roles workbook defines twelve roles across six teams and sizes the minimum team at ten people:
| Team | Roles | Owns |
|---|---|---|
| Platform | Platform Lead, Platform Engineer | The landing zone: accounts, network, guardrails, modules, address plan; production approval; cost governance; incident escalation |
| DevOps | DevOps Lead, DevOps Engineer | Pipelines, OIDC roles, deployment strategy, monitoring and alerting, drift triage, incident command |
| App Development | Lead App Developer, App Developer | The Web App Blueprint repositories and the EKS workloads |
| Data Engineering | Lead ETL Engineer, ETL Engineer | The Data and ETL Blueprint repositories, Glue jobs, data lake governance |
| AI/ML | Lead AI Engineer, AI Engineer | ML pipelines; optional at first |
| Security | Lead Security Auditor, Security Auditor | Findings triage, compliance evidence, quarterly access reviews; read-only |
Each role maps to an ACME_* Identity Center group and a permission set, so who can do what is the same in the org chart, in IAM and in the VPN access matrix. The shared responsibility model places these roles against AWS and BuiltForProd.
Ownership in the repositories
CODEOWNERS makes ownership enforceable. In the Baseline, environments/core/, units/, .github/, root.hcl, common.hcl, scripts/ and the VPC maps are owned by the infra admins; stacks/ and modules/ by the infra admins and platform leads; security.hcl by the infra admins and the security team; environments/plat/prod/ by the platform leads and the security team. In the secrets repository, staging/, prod/, .github/, scripts/ and .sops.yaml are owned by the platform leads and infra admins. An approval from any one listed owner satisfies the rule for a path. The prod GitOps pull request is merged by a person. Branch protection on main requires a pull request, a passing CI run and a code-owner approval.
Every decision is findable
Two comment tags make the repositories self-describing:
git grep "TODO: " # values that must be set for your deployment: emails, ids, domains, group ids
git grep "@optional: " # choices the platform works without: switches, packs, sizing, extra stages
Feature switches live in one file per concern, read by every unit that must agree: network.hcl per region for NAT per AZ, isolation domains, Network Firewall and Transit Gateway peering; security.hcl for every security service and the alert email. Every switch that costs money states its price in the comment beside it, so the person changing it knows what it costs before the plan runs.
Runbooks and documentation
The handover includes the deployment workbooks: the design decisions with the reasoning behind every choice, the architecture deep dive with module-by-module detail, the compliance and audit guides, the Client VPN guide, the module extensibility guide, the team workflow documents and the Update Lifecycle with a runbook for every change that touches an already-deployed platform (tool and provider upgrades, moved units, isolation domains, egress inspection, peering, security services, image rollback). This site is the customer-facing form of the same material; the support tiers page says what BuiltForProd adds beyond it.
A change process anyone can follow
Every change to shared environments follows the same path, and nobody applies from a laptop. In the blueprint infrastructure repositories the dev and staging jobs apply on merge and the prod job waits for the required reviewers of the prod GitHub Environment; the Baseline's single apply job runs under the prod Environment. Application code promotes by immutable tag. Rollback is a revert or a promotion of the previous tag, described on the Recoverable page.
Day-to-day operations
The DevOps workflow workbook gives the operator a monitoring checklist with a threshold for each signal: subnet utilization above 80 percent, sustained Transit Gateway packet drops, NAT bandwidth above 80 percent, any high or critical GuardDuty finding, any non-compliant Config rule, any CIS alarm, any auto-remediation, any external-access finding, a runner not starting within two minutes, a cost anomaly above 20 percent. Drift issues are triaged daily: a console change is reverted from code; a desired change is brought into code. The drift page describes the triage.
The Team Workflow workbook defines incident severities for the customer's own team: P1 (prod down) with a 15-minute response by the DevOps Lead and Platform Lead, P2 (prod degraded) within an hour, P3 (non-production) the next business day, and Slack channels for infrastructure, incidents, deployments, drift alerts and security. These are the operating conventions the platform is delivered with; the response commitments BuiltForProd itself makes under Managed are on the service level agreements page.
Operated with you or for you
Everything above assumes your team operates the platform. BuiltForProd Managed adds on-demand engineers, an SLA-backed support contract, or engineers embedded in your team; contacting support lists the channels.
How you verify it
.github/CODEOWNERSin each repository: the rules above.- Repository settings: branch protection on
mainand theprodEnvironment with required reviewers. git grep "TODO: "on your repositories returns nothing unresolved after handover.- The handover documentation set includes every workbook named above.