Function Naming Patterns and Formulas
A catalog of the naming formulas serverless teams actually use — with examples, trade-offs, and guidance on separators and version suffixes.
The core formulas
| Formula | Example | Strengths | Watch out for |
|---|---|---|---|
{service}-{env}-{action}-{object} | billing-prod-process-payment | Sorts by service; the most common team pattern | Long names on deep domains — keep segments short |
{env}-{service}-{action}-{object} | prod-billing-process-payment | Groups by blast radius; incident-friendly | Service ownership less visible at a glance |
{action}-{object}-{service} | process-payment-billing | Reads like a sentence; natural for event-driven code | Related functions scatter across the console |
{service}-{action}-{object} | billing-process-payment | Short; good when environment is encoded in the account | Ambiguous if one account hosts multiple environments |
{trigger}-{action}-{object} | cron-nightly-reconcile | Invocation source is obvious | Don't duplicate it if the trigger is already in the event config |
{service}-{env}-{action}-{object}-{version} | search-prod-index-products-v2 | Safe parallel runs during migrations | Temporary by design — clean up the old version |
All six are available in the NimbusName generator via the pattern, environment, and version options — generate a batch in each formula and compare.
Separators compared
| Separator | Example | Verdict |
|---|---|---|
Hyphen (-, kebab-case) | billing-prod-process-payment | Default choice. Valid on AWS, Azure, and GCP; most readable. |
Underscore (_, snake_case) | billing_prod_process_payment | Valid on AWS and Azure, but not on GCP. Fine if your team already uses it. |
| None (PascalCase / camelCase) | BillingProdProcessPayment | Harder to scan; avoid unless matching an existing codebase convention. |
Dots and slashes are not allowed by the major providers — if you see them in a naming guide, that guide is for something else (usually DNS or file paths).
Environment placement
Middle placement (billing-prod-process-payment) keeps the service as the sort key while making the environment impossible to miss. Prefix placement (prod-billing-process-payment) optimizes for the incident responder who thinks in blast radius first. Suffix placement (billing-process-payment-prod) is the weakest: the most safety-critical token sits where tired eyes stop reading. Pick middle or prefix and apply it uniformly.
Version suffixes: when they earn their keep
A -v2 suffix is justified when two implementations must coexist — a rewrite being validated against the old path, a blue-green migration, or an A/B test of processing logic. It is not a substitute for Lambda versions and aliases in routine deploys. Every suffixed function should have a removal date; otherwise v2 through v5 accumulate into permanent confusion.
Trigger prefixes
For functions whose whole identity is their trigger, lead with it: cron- for scheduled jobs, api- for HTTP handlers, event- for stream and queue consumers, webhook- for inbound integrations. Examples: cron-daily-cleanup, api-create-user, event-order-created-notify. If the trigger is already obvious from the function's configuration, the prefix is optional — don't encode the same fact twice.
Length budgeting
With a 64-character ceiling on AWS, budget roughly: service (≤12) + env (≤8) + action (≤10) + object (≤12) + separators (3) ≈ 45 characters, leaving headroom for a version suffix or a longer object name. If a candidate exceeds the budget, shorten the object first — payment instead of payment-transaction-record — because the service and environment tokens are doing more work.