Copy page

Build for Switchboard

Shared CloudFormation stacks

Apps do not write their own infrastructure from scratch. They pick an archetype — the deployment policy envelope defined in aws-bootstrap that bounds what the deployer may provision in the account — and compose fragments, the published templates in Switchboard's catalog, shipping artifacts into their shape. Archetype and fragment are different axes and are never used for each other.

Stack	Owner	What it provides
connection template	Switchboard	per-account access: SwitchboardAccess, the permission boundary, the event forwarder, a conditional GitHub OIDC provider, and — in a devops account — the artifact buckets
data-plane-core	Switchboard	per-environment plumbing: config store, event bus, KMS — installed when the environment is provisioned
archetypes (api-lambda-dynamo, s3-cdn, stackset, atlas-lakehouse, …)	aws-bootstrap	the policy envelope the deploy runs under: its carrier fragment creates the cfn-svc-{archetype}-{env} stack role the deploy is passed

Conventions your stack must follow:

• Tags are the interface. Instance resources carry awsApplication (so they group in myApplications) and the swb:tenant / swb:env / swb:app / swb:scope tags on exec roles (workload identity scope comes from tags). Public surfaces carry swb:endpoint — see endpoints.
• Outputs are read back. Component versions (landedPins) and anything a custom resource produces surface as stack outputs; the deploy read-back records them on the instance.
• Custom resources carry the odd jobs. Anything the old deploy workflows did that is not CloudFormation belongs in a custom resource — the Zuplo gateway and dev portal deploy through Custom::ZuploProject in the app's own CDK.

Templates and their locations are catalogued per repo in the console's Repositories page; the construction-phase plugin will carry the per-archetype how-to.