Skip to main content

The BuiltForProd Standard

The BuiltForProd Standard defines what production-ready means: a system is built for production when it is Secure, Reliable, Observable, Scalable, Automated, Recoverable, Compliant and Operable. Each property is a design constraint, not a later upgrade, and each pillar page on this site names the units, services and workflows in the AWS Baseline and the blueprints that deliver it.

The eight pillars

PillarA BuiltForProd system...Page
Secureprotects identities, data, workloads and supply chainsSecure
Reliablecontinues operating through expected failuresReliable
Observablemakes its state and behavior visible to operatorsObservable
Scalablegrows predictably without architectural failureScalable
Automatedmakes routine provisioning, deployment, validation and operations repeatableAutomated
Recoverablehas tested recovery mechanisms for failures and disastersRecoverable
Compliantcan demonstrate controls and evidence consistentlyCompliant
Operablecan be understood, operated, troubleshot and changed safely by humansOperable

The BuiltForProd test

The test is one question, "Would you trust this in production?", asked eight ways:

DimensionQuestion
SecurityIs it secure by default?
ReliabilityWhat happens when something fails?
ObservabilityCan operators see what is happening?
ScalabilityWhat happens when demand grows 10x?
AutomationHow much depends on manual intervention?
RecoveryCan the system actually be restored?
ComplianceCan controls and evidence be demonstrated?
OperationsCan another engineer operate it safely?

A demo passes none of these. A system that "works" answers only the first half of each question. The pillar pages answer all eight for the AWS Baseline and the three blueprints, with the concrete mechanism and how you verify it in your own accounts.

How the pillars map to the platform

Each pillar is delivered by several parts of the platform, and most parts serve more than one pillar. The table shows the principal mechanisms; the pillar pages hold the full lists.

PillarPrincipal mechanisms in the AWS Baseline and blueprints
SecureThree service control policies, IAM Identity Center with environment-scoped permission sets, keyless CI through GitHub OIDC, KMS encryption, SOPS-encrypted secrets, GuardDuty, Security Hub, Firewall Manager WAF, isolation-domain routing
ReliableThree Availability Zones everywhere, one NAT Gateway per AZ, multi-AZ DocumentDB and Redis in staging and prod, ArgoCD high availability, horizontal pod autoscaler settings with disruption budgets, plan-before-apply with mocked dependencies
ObservableOrganization CloudTrail, VPC Flow Logs, the CloudWatch observability sink in the security account, seven CIS metric filters and alarms, Fluent Bit application logs, X-Ray tracing
ScalableA /8 address plan with room for 16 regions and 8 stages per region, IPAM, region discovery from folders, three layers of EKS scaling (pod autoscaler, Karpenter, Cluster Autoscaler), Spot runners that scale to zero
AutomatedPlan on pull request, apply on merge, scheduled drift detection, pre-commit and CI guardrail scripts, immutable images promoted by pull request, secrets synced on merge
RecoverableVersioned and locked state, DocumentDB automated backups and deletion protection in prod, S3 versioning, Git revert as rollback, promotion of a previous tag
CompliantThe SOC 2 baseline conformance pack, 28 further packs, Security Hub standards, an audit-protection SCP, log file validation, auditor permission sets that cannot read data
OperableWorkbooks and runbooks, CODEOWNERS by blast radius, twelve named roles, TODO: and @optional: tags, one switch file per concern with the price beside each switch

How to read the pillar pages

Every pillar page has the same three parts: what the pillar means, what in the code delivers it, and how you verify it in your own accounts without changing anything. The architecture overview gives the map the pillar pages assume, and the security posture summary condenses the Secure and Compliant pillars for a reviewer.