Skip to content
BuiltForProd
Talk to us
BuiltForProd Baseline

Build the foundation

A complete production foundation, customized for your organization, deployed into your own cloud accounts by our engineers, and handed over with the code and the documentation. From that point it is yours.

What the Baseline is

BuiltForProd Baseline is a production-grade, multi-account cloud foundation written as infrastructure as code. It defines the organization and accounts, the identity model, the network, the guardrails, the security services, the compliance controls and the delivery pipeline that every workload you run will depend on. BuiltForProd customizes it for your organization, deploys it into your own cloud accounts, verifies it against objective acceptance criteria, and hands over the repositories and the documentation.

It is the part of production that is cheap to build once and expensive to retrofit. Account structure, identity and network design are decisions you make at the beginning and live with for years. Most teams make them by accident, at five people, and discover the cost at fifty.

Not a black box you rent.

Three editions, one Standard

Each edition is engineered around the architecture framework of its own cloud provider. All three are built to the same eight properties, delivered the same way and handed over the same way.

AWS Enterprise Baseline

Engineered around the AWS Well-Architected Framework.

Azure Enterprise Baseline

Engineered around the Azure Well-Architected Framework.

GCP Enterprise Baseline

Engineered around the Google Cloud Architecture Framework.

About the numbers on this page

Every specific count, service and control named below describes the AWS Enterprise Baseline. The Azure and GCP editions are scoped in your proposal and described at the level of the Standard, the architecture framework, the ownership model and the handover.

What the AWS Enterprise Baseline deploys

One AWS Organization, built entirely in OpenTofu and Terragrunt. Every deployment-specific value is tagged in the code, and every optional feature is a switch with the price in the comment next to it.

Accounts and guardrails

14 accounts, 2 OUs, 3 SCPs

  • A management account, 9 core accounts (security, audit, identity, network, dns, artifacts, auto, corp, public) and 4 identical workload accounts (sandbox, dev, staging, prod) from one template
  • Three service control policies: no IAM users or access keys, allowed regions only, and audit logging that cannot be stopped or deleted
  • A tag policy with six required tags, report-only by default and enforced with one flag
  • A new account is a map entry and a folder — two pull requests
Identity

11 permission sets, zero IAM users

  • IAM Identity Center single sign-on across every account, with 12-hour sessions
  • Eleven permission sets, from PlatformAdmin to ReadOnly. Production is read-only for everyone except the Platform and DevOps leads
  • Auditors get an explicit deny on data reads: they can see the controls, not the contents
  • An unused-access analyzer flags permissions nobody has used in 90 days
Network

Hub-and-spoke on Transit Gateway

  • Separate production and non-production isolation domains. Routes between them are blackholed: production and non-production cannot reach each other
  • Centralized egress through a hub VPC with NAT in each of three Availability Zones; spokes have no NAT
  • One AWS VPC IPAM address plan with capacity for 16 regions and 8 workload stages per region. Continuous integration rejects hardcoded address ranges
  • Flow logs on all six VPCs, public zones with DNSSEC and query logging on the apex, production and staging, and a private internal zone
Security

Nine security services, administered centrally

  • On by default: organization-wide multi-region CloudTrail with log file validation, AWS Config in every account with an organization aggregator, GuardDuty, Security Hub, IAM Access Analyzer, and Firewall Manager putting WAF on every workload load balancer
  • One switch away, with the price in the comment: Inspector, Macie and Shield Advanced
  • Seven CIS CloudWatch alarms, from root account use to CloudTrail and VPC changes
  • Automated remediation of public S3 buckets, customer-managed KMS keys with annual rotation, TLS 1.2 and above
Compliance readiness

29 conformance pack templates

  • The SOC 2 baseline pack is on by default; 28 more templates are one flag away
  • Documented control mappings for eleven frameworks, including SOC 2, HIPAA, PCI DSS 4.0, NIST CSF, CMMC 2.0 and CIS
  • Four Security Hub standards available, and five quick-start compliance profiles
  • Evidence comes from the infrastructure — Config history, CloudTrail, findings, pull requests

How compliance readiness works →

Delivery pipeline

GitHub OIDC, plan on every pull request

  • GitHub Actions federated through OIDC. No AWS keys are stored in version control, because no long-lived AWS credential exists for anyone
  • Every change is a pull request: a plan is posted as a comment, reviewed, merged, then applied across all 14 accounts in dependency order, with production gated by required reviewers
  • Six guard scripts plus Checkov, Trivy, tflint and formatting checks, with every action pinned by commit hash
  • Daily drift detection on critical accounts and weekly across all 14. Drift opens an issue; nothing is silently reverted
The AWS Enterprise Baseline, by the numbers.
Accounts and structure 14 accounts · 2 organizational units · 3 service control policies
Identity 11 permission sets · 0 IAM users · 0 long-lived AWS keys
Network 6 VPCs · NAT across 3 Availability Zones · an address plan for 16 regions × 8 stages
Security and compliance 9 security services · 29 conformance pack templates · 11 mapped frameworks · 7 CIS alarms
Code 34 modules · 48 unit definitions · 6 continuous integration guard scripts
Acceptance 84-item deployment checklist · 17 verification checks mapped to SOC 2 controls, run twice

The shape of it

One organization, two isolation domains, and a network that keeps production out of reach of everything that is not production.

The AWS Enterprise Baseline topology One AWS Organization contains two organizational units. The core organizational unit holds nine accounts: security, audit, identity, network, dns, artifacts, auto, corp and public. The plat organizational unit holds four workload accounts: sandbox, dev, staging and production. Below them, a hub-and-spoke network connects a hub VPC with NAT gateways in three Availability Zones to a Transit Gateway, which carries two route domains: a non-production domain for sandbox, dev and staging, and a production domain. Routes between the two domains are blackholed, so production and non-production cannot reach each other. AWS Organization core OU · 9 accounts plat OU · 4 workload accounts security audit identity network dns artifacts auto corp public sandbox dev staging prod hub-and-spoke network · AWS Transit Gateway hub VPC · NAT in 3 AZs centralized egress Transit Gateway non-prod route domain prod route domain blackholed
Production and non-production sit in separate route domains, and the routes between them are blackholed. One address plan, one egress path, one pipeline.

Three ways to engage

All three are fixed-fee and fully executed by the BuiltForProd team.

Tier 1

Standard Deployment

The complete Baseline for your cloud: customized, deployed into your accounts, verified against the acceptance criteria, and handed over with the repositories and the full documentation set.

Tier 2

Full Deployment with Blueprints

Everything in the Standard Deployment, plus any two Blueprints deployed into your workload accounts. The usual choice when a workload is waiting behind the foundation.

Tier 3

Blueprint Deployment

For teams that already have a Baseline: one or more additional Blueprints, each individually priced and deployed into the existing workload accounts.

Every engagement is quoted as a fixed fee. What shapes a quote, and what is excluded — cloud spend is billed by your cloud provider, not by us.

What you receive

Repositories

The full source in your own version control organization, customized to your namespace, region, domains and address plan. Source-available under the PolyForm Internal Use License 1.0.0, built on open-source tooling: OpenTofu, Terragrunt, Kubernetes, ArgoCD.

A deployed environment

Not a kit. The foundation is deployed phase by phase into your accounts by our engineers, then verified. In the AWS edition that means an 84-item deployment checklist signed off and 17 verification checks mapped to SOC 2 controls, run twice.

Documentation

Architecture decision records, how-to guides, operations runbooks, roughly 160 troubleshooting entries with cause, fix and prevention, upgrade guides, an integration guide and a compliance audit guide. Every code sample shows your own namespace, domains, region and account identifiers.

A hands-on handover

A working session, not a presentation. Your team performs the real tasks unaided before sign-off — 11 of them in the AWS edition, from making a change and reading its plan through to handling drift, rotating a secret and promoting a release.

Cost-aware defaults

Cheap resilience is on. Expensive features are off, one switch away, with the price written in the comment next to the switch. Nothing is hidden and nothing turns itself on.

Ownership, and what happens after handover

The repositories and the cloud accounts are yours. BuiltForProd keeps no standing access: after handover there is no principal, no role and no credential belonging to us in your environment, and nothing in the delivered code names BuiltForProd. There is no control plane to depend on and no runtime to rent.

You can continue without us, and the point of the documentation and the handover session is to make that a real option rather than a polite sentence. If you want help, BuiltForProd Managed engineers work through your own single sign-on groups, pull requests and pipelines — access you grant and can remove.

Updates arrive as pull requests

Your repositories are forks of the upstream BuiltForProd repositories. When an improvement lands upstream, you pull it the same way you change anything else:

  1. Compare your fork against upstream
  2. Branch and open a pull request
  3. Read the plan posted on the pull request
  4. Review against the risk and approval matrix
  5. Merge, and let the pipeline apply it

You decide what to take and when. Documented upgrade guides cover the patch, minor, major and provider cases.

Questions about the Baseline

What is BuiltForProd Baseline?

BuiltForProd Baseline is a production-grade, multi-account cloud foundation written as infrastructure as code. BuiltForProd customizes it for your organization, deploys it into your own cloud accounts, verifies it against objective acceptance criteria and hands over the repositories and the documentation.

Is this a product I download or a service you deliver?

Both, in that order. The Baseline is finished, tested code, and the engagement is our engineers customizing and deploying it into your environment. You do not receive a kit to assemble; you receive a running, verified foundation and the source that built it.

Which cloud can the Baseline be deployed on?

The Baseline comes in three editions: the AWS Enterprise Baseline, the Azure Enterprise Baseline and the GCP Enterprise Baseline. Each is engineered around its cloud provider’s own architecture framework and all three are built to the same BuiltForProd Standard, with the same ownership, delivery and handover model.

How many accounts does the AWS Enterprise Baseline create?

The AWS Enterprise Baseline deploys one AWS Organization with 14 accounts across 2 organizational units: a management account, 9 core accounts (security, audit, identity, network, dns, artifacts, auto, corp, public) and 4 identical workload accounts (sandbox, dev, staging, prod). Adding another account is a map entry and a folder.

Do you keep access to our environment afterward?

No. After handover BuiltForProd holds no principal, no role and no credential in your environment, and nothing in the delivered code names BuiltForProd. If you later buy BuiltForProd Managed, our engineers work through access you grant in your own identity provider and can remove at any time.

Security and ownership

How do we get improvements after handover?

Your repositories are forks of the upstream BuiltForProd repositories. When an improvement lands upstream you compare, branch, open a pull request, read the plan, review it and merge, exactly like any other change. Documented upgrade guides and a risk and approval matrix come with the delivery.

Does the Baseline make us SOC 2 compliant?

No product can. The AWS Enterprise Baseline ships controls and automated evidence sources mapped to SOC 2 and ten other frameworks, with the SOC 2 conformance pack on by default. Certification is your auditor’s decision, and BuiltForProd provides readiness, not certification.

What compliance readiness means

What do we need to have before you start?

A cloud management account, a team-owned mailbox, a domain you can delegate subdomains from, a version control organization, named people in the platform roles, and a handful of decisions: your namespace, home region, address plan, which paid features you want on and which compliance packs to enable.

Still deciding? Compare the alternatives honestly, read the Standard the Baseline is built to, or start with an Assessment.

Find out what production would take.

Tell us what you are running and what is coming: a funding round, an audit, a first enterprise customer, a migration. We will tell you what we would build, what it costs, and whether we are the right fit.

Talk to us Read the Standard