Parametric Infrastructure Values

When a runtime component needs a value that infrastructure owns — a DNS zone name, a bucket, a role ARN, a CDN domain — it has two ways to get it: consume the published value, or re-derive it from parts the component happens to also know. This guide is a standing preference for the former, distilled from the Email module’s sending-domain defect (see Email Module Decisions § D1).

The rule

Consume the infrastructure-published value; never hard-code or re-derive it.

A component should read the value the owning stack exports (a CloudFormation -API- export, a config key projected at deploy time), not reconstruct it from its own knowledge of the naming convention. Re-derivation duplicates a fact that infrastructure already owns, and the two copies drift the moment either side changes.

Worked example (what went wrong, what fixed it)

The Email module needs each tenant’s sending domain, {slug}.{partition}.ardamails.com. Two ways to build it:

• Re-derive (the bug): hard-code ardamails.com in the component and append the slug → {slug}.ardamails.com. The partition was dropped entirely; the mail-root was a second copy of a constant infrastructure already owns. Per-tenant DNS records would have been written to the wrong (or non-existent) zone.
• Consume (the fix): read …-API-PartitionMailZoneName (the name of the very zone the records are written into) and compose {slug}.{mailZoneName}. The domain is now guaranteed to match the zone — because it is the zone’s published name.

The infrastructure already exported the zone id (which the component consumed) right next to the zone name (which it didn’t). The fix was one more readExport line, not new logic.

Corollaries

• One fact, one source. If infrastructure exports it, that export is the single source of truth. A MAIL_ROOT_DOMAIN constant in CDK and a second "ardamails.com" literal in the consuming service are a drift waiting to happen.
• Prefer the most specific published value. Consume the zone name over re-deriving it from a partition label + a mail-root; consume the CDN domain over rebuilding it from a distribution id.
• Fail fast on a missing value. A required infrastructure value absent at startup should fail the pod, not silently default — the gross-misconfiguration case is better caught at boot than at first use.

Partition identity has several representations — pick deliberately

A deployment “partition” surfaces in more than one form; consuming the wrong one is a common mistake. For the Application Runtime partitions:

Representation	Example	Source	Use for
partition label	dev	global.purpose	the bare partition concept
infrastructure fqn	Alpha002-dev	{infrastructure}-{purpose}; CFN export prefix; Sentry environment	export naming, cross-tool correlation
mail zone name	dev.ardamails.com	…-API-PartitionMailZoneName export	composing sending domains
mail zone id	Z0…	…-API-PartitionMailZoneId export	addressing the zone for writes

These are not interchangeable. The Email module consumes the zone name to build domains, the zone id to write records, and the fqn (via Sentry’s environment dimension) for telemetry — and it does not carry a redundant partition tag where the environment dimension already conveys it. When a value is needed only as a log/telemetry tag, check whether an existing dimension already carries it before plumbing a new one.