Skip to main content

Integrating with Google Cloud services

Exam guide§2.1

A Cloud Run service rarely runs alone - it reads a cache, queries a database, or reacts to messages. This page covers the practical ways a Cloud Run service reaches out to other Google Cloud services: client libraries, Serverless VPC Access (Memorystore), the managed integrations feature, and Cloud SQL. For the reverse - event sources that invoke a service (Pub/Sub, Eventarc, ...) - see Invocation & event triggers.

The two building blocks are covered elsewhere and are assumed here:

Connecting with client libraries

Your application calls a supported Google Cloud service using that service's client library. The library transparently authenticates with the service's runtime service account - no keys in your code.

GotchaDefault identity is over-privileged

The built-in default service account has the broad Project > Editor role - it can call all Google Cloud APIs and read/write every resource in the project. Assign a per-service identity with a minimal set of permissions instead. A service that only reads Firestore should get just the Firestore User role.

For the full list of services you can integrate with, refer to the documentation.

Connecting to Memorystore for Redis

Memorystore is a fully managed, highly available in-memory cache for Redis and Memcached. A Cloud Run service reaches a Memorystore for Redis instance over its internal IP through Serverless VPC Access.

To connect to a Memorystore for Redis instance:

NumbersSteps to connect
  1. Determine your Redis instance's authorized VPC network.
  2. Create a Serverless VPC Access connector in the same region as your Cloud Run service.
  3. Attach the connector to the Redis instance's authorized VPC network.

Then deploy the service with the connector and pass the Redis host and port as environment variables so your application code can instantiate a client:

CommandsDeploy with a connector and Redis env vars
gcloud run deploy \
--image my-container-image \
--platform managed \
--region us-central1 \
--vpc-connector my-connector \
--set-env-vars REDISHOST=[REDIS_IP],REDISPORT=[REDIS_PORT]

Cloud Run integrations

The integrations feature is a console UI and gcloud command that create and configure all the resources for a specific integration in one step, eliminating the manual wiring that would otherwise be required.

Cloud RunServiceIntegrationMemorystore for Redis
A Cloud Run integration wires a service to a fully managed Memorystore for Redis cache - it provisions the cache, creates a new service revision, and configures networking and environment variables automatically.

When you create an integration to connect a service to a Memorystore for Redis cache:

NumbersWhat an integration does for you
  1. A fully configured Redis cache is automatically created with a configurable memory size.
  2. A new service revision is created for the service.
  3. Networking and environment variables are configured so the service can access the cache.

Integrations currently let you map custom domains to Cloud Run services and connect a service to a Memorystore for Redis instance; more are planned. For details, see connecting to a Memorystore instance using integrations.

Connecting to Cloud SQL

Cloud SQL is a fully managed relational database for MySQL, PostgreSQL, and SQL Server. A new instance gets a public IP by default; you can also assign a private IP.

Cloud RunServiceService AccountCloud SQL
A Cloud Run service reaches a Cloud SQL instance as its service account - grant that identity a Cloud SQL role, then add the instance connection name to the service.
  • Public IP - Cloud Run connects using the Cloud SQL Auth proxy (via network sockets or a Cloud SQL connector), which provides encryption and IAM-based authorization. Attach the instance at deploy time:
CommandsAttach a Cloud SQL instance
gcloud run services update my-service \
--add-cloudsql-instances=my-sql-instance-connection
  • Private IP - route all egress from the service to the instance through a Serverless VPC Access connector; the application connects directly.

The service account used by the service needs an appropriate Cloud SQL role - either Cloud SQL Client or Cloud SQL Admin.

NumbersCloud SQL connection facts
  • Cloud SQL connectors are language-specific libraries that add encryption and IAM-based authorization.
  • Store credentials in Secret Manager and pass them to the service as environment variables or a mounted volume - never hardcode them.
  • Use a client library with a connection pool that auto-reconnects broken connections.
  • A pool also caps connections: Cloud Run is limited to 100 connections per service to a Cloud SQL database (plus Cloud SQL's own quotas).

Recap

DECISIONHow should my Cloud Run service reach another Google Cloud service?
Call a Google Cloud API (Firestore, Storage, ...)Client library + least-privilege service account
Reach Memorystore / a private-IP resourceServerless VPC Access connector (or an integration)
Query a Cloud SQL database (public IP)Cloud SQL Auth proxy + Cloud SQL Client role
Query a Cloud SQL database (private IP)Serverless VPC Access connector
Pick this when: client libraries for Google APIs; VPC Access for internal-IP resources; Pub/Sub push for events; Cloud SQL Auth proxy or private IP for databases