Separate Cloud Run functions generations and pricing

Why this is worth a look

Google documents two generations with different pricing models. Current Cloud Run functions are deployed as Cloud Run services and use Cloud Run pricing, while Cloud Run functions (1st gen) use Cloud Run functions (1st gen) pricing. For current functions, the creation API changes which API can manage the function and how triggers and retries are configured. A current resource can be managed in Cloud Run even when it was originally created through the Cloud Functions v2 API, so the present management surface is not enough to establish provenance.

Classify generation from the documented resource and URL model, assign pricing, then use retained deployment or infrastructure records to identify the original API without changing resources.

1. Inspect the resource model and deployment surface. Record current Cloud Run functions when the function is a Cloud Run service deployed from source and is managed in Cloud Run. Record Cloud Run functions (1st gen) when it is the original function type.
2. Record the assigned URL. run.app supports the current classification. cloudfunctions.net is not decisive by itself because Cloud Functions v2 API-created functions can also have that endpoint.
3. Assign pricing only after generation: current Cloud Run functions use Cloud Run pricing; Cloud Run functions (1st gen) use Cloud Run functions (1st gen) pricing.
4. Review retained deployment or infrastructure records for the original API. A record showing gcloud functions deploy or google_cloudfunctions2_function indicates the Cloud Functions v2 API path. A record showing Cloud Run console, REST, or Terraform deployment can indicate the Cloud Run Admin API path only when the record identifies that API explicitly; gcloud run deploy alone is not conclusive because it can deploy functions created through either API. If no retained record identifies the original API, record unknown.
5. For a current function, record trigger and retry handling. Cloud Run Admin API functions specify triggers in the console during deployment or after deployment with the gcloud CLI; update retry policy in Eventarc and configure a dead-letter topic in Pub/Sub. Cloud Functions v2 API functions specify triggers during deployment and retries with the --retry flag.

How to confirm it

1. 01

   Classify the generation

   Inspect the resource model and deployment surface first. Current Cloud Run functions are Cloud Run services deployed from source; Cloud Run functions (1st gen) are the original function type. A run.app URL supports the current classification, while cloudfunctions.net alone is not decisive because v2 API-created functions can have that endpoint too.

2. 02

   Assign the pricing model

   Use the generation, not the creation API, to select the documented pricing path. Current Cloud Run functions use Cloud Run pricing. Cloud Run functions (1st gen) use Cloud Run functions (1st gen) pricing.

3. 03

   Check retained API provenance

   Review the deployment command or infrastructure definition that created the function. gcloud functions deploy or google_cloudfunctions2_function identifies the Cloud Functions v2 API path. A gcloud run deploy record is not conclusive because Cloud Run tools can deploy functions created through either API. If retained records do not identify the original API, record it as unknown rather than inferring it from the current Cloud Run service.

4. 04

   Separate triggers from retries

   For Cloud Run Admin API-created functions, triggers are specified in the console during deployment or after deployment with the gcloud CLI. Update retry policy in Eventarc and configure a dead-letter topic in Pub/Sub. For Cloud Functions v2 API-created functions, specify triggers during deployment and retries with the --retry flag.

Primary sources