# 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 fragment library, 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, the same in every account: `SwitchboardAccess`, the permission boundary and the event forwarder |
| `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`, …) | Switchboard | the policy envelope the deploy runs under: its carrier fragment creates the `swb-<class>-svc-{archetype}-{env}` stack role the deploy is passed |

Conventions your stack must follow:

- **Tags are the interface, and every key has a reader.** The deploy
  writes the stack set — `swb:stack-set / swb:tenant / swb:app /
  swb:env` — at stack level, and CloudFormation propagates it onto
  every taggable resource, exec roles included; your stack writes none
  of it. A workload's scopes are its record's, keyed on the role ARN,
  not read from a tag. Public surfaces carry `swb:endpoint`, which your
  template does write because only it knows what a resource exposes —
  see [endpoints](/endpoints). A tag a system outside Switchboard reads
  off your resources — Datadog's `service` / `env` / `version`, the AWS
  console's `awsApplication` grouping — is yours to declare in your
  app's manifest under `cfn.tags`, with the deploy's own placeholders;
  the platform writes none of them.
- **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 install.
- **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.