Azure and GCP function naming: rules and patterns

Lambda is not the only cloud. The naming rules, limits, and conventions for Azure Functions and Google Cloud Functions — plus patterns that survive multi-cloud.

Why cloud-specific rules matter

Function names are not just labels — they become part of ARNs, URLs, log group names, and IAM policies. Each cloud enforces its own character set and length limits at creation time, so a name that deploys happily on AWS can be rejected on Azure. If you run multi-cloud (or might one day), name for the strictest platform from the start.

Azure Functions naming rules

Azure is the strictest of the three major clouds about function names:

Start with a letter. Names must begin with an alphabetic character — no leading digits or hyphens.
Letters, numbers, and hyphens only. No underscores, no dots, no spaces. This is stricter than AWS Lambda, which allows underscores.
Keep them URL-friendly. Function names surface in HTTP trigger routes, so treat them like URL path segments: lowercase, hyphenated, no surprises.
Mind the app boundary. In Azure, functions live inside a Function App, and the app name carries the environment and service context — so function names themselves can stay focused on the action: process-payment inside billing-prod-app.

Google Cloud Functions naming rules

Google's constraints are closer to AWS but with their own quirks:

Lowercase letters, numbers, and hyphens. Uppercase is not allowed — a common gotcha when porting Lambda names that use camelCase or underscores.
63-character limit. Slightly tighter than Lambda's 64; long service-env-action-object chains can overflow, so count before you commit.
Must start with a letter and end with a letter or number. No trailing hyphens.
Names are regional. Like Lambda, uniqueness is per region per project — which is why environment tags in the name still matter even though the console groups by project.

AWS vs Azure vs GCP at a glance

Rule	AWS Lambda	Azure Functions	Google Cloud Functions
Max length	`64 chars`	`Varies by resource`	`63 chars`
Allowed characters	`a-z A-Z 0-9 - _`	`a-z A-Z 0-9 -` (start with letter)	`a-z 0-9 -` (lowercase only)
Underscores	Yes	No	No
Uppercase	Yes	Yes	No
Uniqueness scope	Region + account	Within Function App	Region + project

The multi-cloud-safe pattern

The intersection of all three rule sets is simple: lowercase letters, numbers, and hyphens; start with a letter; keep it short. A pattern like service-env-action-object in that character set deploys everywhere:

billing-prod-process-payment — valid on AWS, Azure, and GCP.
Billing_Prod_ProcessPayment — valid on AWS only. Rejected elsewhere.
prod-billing-process-payment — valid everywhere; environment-first ordering also groups nicely in consoles.

Generate candidates with the cloud function name generator using the strict character set, and you will never have a name rejected at deploy time. See the naming patterns guide for more formulas and the serverless naming guide for the broader conventions.

Environment tags: still worth it

Even though Azure scopes names to the Function App and GCP to the project, keep the environment in the name (-prod, -staging). Names escape their scope constantly — in log aggregators, alert messages, IAM policies, and incident calls. "Which environment is process-payment failing in?" is a question you never want to ask at 3am.

Rule of thumb: if a name deploys on Azure's stricter rules, it deploys anywhere. Name for the strictest cloud you might ever use.

Naming the supporting resources

Functions never travel alone — storage buckets, queues, and log groups need names too, and the same discipline applies. Derive resource names from the function name with a role suffix: billing-prod-process-payment-dlq for the dead-letter queue, billing-prod-uploads for the bucket. Keep one naming document per project listing every resource pattern, so the fifth developer names things exactly like the first did. And remember that some resource names are globally unique (storage buckets on AWS and GCP) — prefix those with something you own, like a company or project slug, to avoid collisions and squatting.

FAQ

Can I use underscores in Azure Function names?

No — Azure allows letters, numbers, and hyphens only, and the name must start with a letter. Convert underscores to hyphens when porting from AWS.

Why does GCP reject my uppercase function name?

Google Cloud Functions require lowercase. It is one of the most common porting errors from Lambda, where uppercase is allowed.

Should the environment go in the function name or the app/project name?

Both, ideally — the app or project carries the primary context, but the environment tag in the function name saves you when names appear without context in logs and alerts.

How do I rename a function that is already deployed?

You do not rename in place on any cloud — you deploy a new function with the new name, migrate triggers and permissions, then delete the old one. Plan renames like migrations.

Do these rules apply to Cloud Run too?

Cloud Run service names follow similar lowercase-and-hyphens rules. The multi-cloud-safe pattern covers Cloud Run as well.