Determine how applications will connect to the database

Configure networking, key management, encryption, and security is how applications reach Google Cloud databases over private paths while stored data and network traffic stay protected. Virtual Private Cloud (VPC) (opens in a new tab) networks carry private database traffic, Private Service Access links customer networks to Google-managed networks, and identity and perimeter controls limit who can connect and where data can move. Customer-Managed Encryption Keys (CMEK) (opens in a new tab) in Cloud Key Management Service (KMS) protect data at rest, while Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protect data in transit.

1.1Protecting Stored Data with Customer-Managed Encryption

Protecting stored data with customer-managed encryption means the database encrypts data at rest with a key in the customer's Cloud KMS key ring. The database service depends on Cloud KMS for every encrypt and decrypt operation, so if the key is disabled, destroyed, or its permission is revoked, the database cannot read its own stored data. This creates an ownership boundary where the customer controls access to the key and the database controls use of the key.

CMEK is applied at creation time and each database resource has a different enforcement point. An AlloyDB cluster must reference a Cloud KMS key in its cluster configuration, a Cloud SQL instance must reference the key in the kmsKeyName field of the diskEncryptionKey object, and a Database Migration Service migration must use a destination database that was created with CMEK. A Cloud SQL instance cannot be switched to CMEK after creation. To add CMEK later, first create a new CMEK-enabled instance, then move the data over, and only after that delete the original instance.

1.2Managing the Cloud KMS Key Lifecycle

Managing the Cloud KMS key lifecycle means controlling how each encryption key is generated, shared, stored, used, and retired under policy. Policies require strong generation with an approved algorithm and protection level, secure distribution only to services that need the key, and restricted access to the fewest custodians necessary. The system must also track cryptographic material used by database services and report changes in key status over time.

The lifecycle moves through ordered states. First, the key is generated in Cloud KMS with a defined protection level and encrypt-decrypt purpose. Then it is distributed to supported database services through CMEK grants so only authorized service accounts can use it. Then it is stored separately from the data it protects and used for ongoing encryption with limited access and monitoring. Finally, it is retired at the end of its cryptoperiod, when its integrity is weakened, or when compromise is suspected, and a retired key is never used for new encryption. Secret and private keys must stay in protected form as encrypted key components, inside a secure device such as a hardware security module (HSM), or as split key shares.

1.3Requiring SSL and TLS for Connections in Transit

Requiring SSL and TLS for connections in transit means every application-to-database connection must negotiate an encrypted session before data flows. Traffic flows from the database client across the network boundary to the database server, and the server accepts the connection only when both sides agree on a secure protocol version and valid credentials. Controls for AlloyDB and other databases require SSL encryption on the instance and enforce SSL for all incoming database connections.

The in-transit policy requires TLS 1.2 or higher and blocks fallback to insecure versions, algorithms, key sizes, or implementations. Only trusted keys and certificates are accepted, and each certificate must be confirmed as valid with no expiration or revocation. Restricting legacy TLS versions and insecure SSL policies keeps the trust boundary strong, so sensitive fields stay protected while moving over open or public networks.

1.4Creating Private Isolation with Private Service Access

Creating private isolation with Private Service Access means giving a Cloud SQL instance a private IP address inside a VPC so traffic stays on Google's internal network. Private Service Access connects the customer's VPC network to Google's managed service network for Cloud SQL. The result is internal-only communication where applications and databases reach each other by private address, even across regions, with reduced public exposure.

Private Service Access relies on VPC Network Peering implemented internally by Google Cloud. The customer does not create the peering explicitly, but after the connection is created its underlying peering appears on the VPC Network Peering page. Traffic flows from resources in the customer VPC network to internal IP addresses of Cloud SQL resources in the Google-managed VPC network, and the boundary sits between those two peered networks. Private IP connections work across regions, but they do not work from legacy networks because legacy networks do not support VPC Network Peering or Private Service Access.

Setting up a new project for private IP requires an ordered network foundation before instance creation:

1. Enable required APIs: Enable sqladmin.googleapis.com, compute.googleapis.com, and servicenetworking.googleapis.com in the project.
2. Allocate an IP range for peering: Create a global address with purpose VPC_PEERING, commonly with --prefix-length=16, on the selected VPC network.
3. Establish the peering connection: Connect the VPC network to servicenetworking.googleapis.com using the allocated range.

If creation is attempted without this foundation, it fails with SERVICE_NETWORKING_NOT_ENABLED or NETWORK_NOT_PEERED.

1.5Reaching Private Instances from Multiple VPC Networks

Reaching private instances from multiple VPC networks is difficult because VPC Network Peering is not transitive. Routes are shared only between the two directly peered VPCs, so a third VPC cannot use the original VPC's connection to reach Cloud SQL. The private connection allows internal addresses to cross two VPC networks whether they belong to the same project or organization, but that trust does not extend further.

To connect one private Cloud SQL instance to multiple VPCs, use one of these documented patterns:

• Connect using custom advertised routes to export the private service routes to additional networks.
• Connect using an intermediate proxy, such as SOCKS5, that bridges traffic between networks.
• Connect using Cloud SQL Auth Proxy as a service that forwards private traffic from another network.

Shared VPC extends the same private model across host and service projects in an organization. A new Cloud SQL instance can be created with a private IP address in a Shared VPC network, where the service project owns the instance and the host project owns the network. However, an existing Cloud SQL instance cannot later be assigned a private IP address in a Shared VPC network.

1.6Rules for Private IP Lifecycle and Secure Connection Paths

Rules for private IP lifecycle and secure connection paths define what can change after private connectivity is enabled and where the database client must run. A Cloud SQL instance can be configured for private IP at creation time or added to an existing instance, and public IP and private IP can be enabled together without affecting each other. Configuring an existing instance for private IP, or changing its connected network, restarts the instance and causes a few minutes of downtime. Private IP capability cannot be removed after it is configured, a read replica inherits its private IP status from its primary, and the incoming address of an instance is static.

Secure connection paths describe where the database client must run so private traffic never leaves the VPC boundary:

Traffic flows from the application to the local proxy, then from the proxy to the instance private IP inside the peered VPC network. The proxy defaults to public IP when an instance has both IP types, so placement and address selection control whether traffic stays private.

1.7Controlling Identity, Perimeters, and Firewall Boundaries

Controlling identity, perimeters, and firewall boundaries means combining who can act with where data can move. Identity and Access Management (IAM) governs which users and service accounts can use database resources with least privilege at the smallest scope. VPC Service Controls creates a service perimeter around explicitly specified projects and services to mitigate data exfiltration, while firewall rules allow or deny traffic to database servers and ports.

Securing a database project with VPC Service Controls follows an ordered workflow. First, select the database project that the perimeter will protect. Then create a service perimeter and add the project to it. Then add existing database instances by updating the perimeter configuration. Then add required APIs as restricted services so data cannot be copied out through them, including the Database Center, Compute Engine, Cloud Storage, Container Registry, Certificate Authority Service, and Cloud KMS APIs. Access levels are optional exceptions that permit external access to protected resources inside the perimeter when IP, device, or certificate conditions are met. Firewall hardening supports this with default-deny, blocking generic access from all IP addresses to database ports and to access ports for SSH, RDP, Telnet, FTP, and HTTP, and blocking overly permissive external IP access.

Justifying the use of session pooler services means showing why reusing database sessions is required for scalable and efficient application connectivity. Creating a new connection or session requires a handshake and round trip that adds latency and consumes memory and CPU. A session pool keeps ready-to-use backend connections alive so many application operations can share a smaller set of connections, which lowers latency, reduces overhead, and prevents connection exhaustion.

2.1Reusing Spanner Sessions with Session Pools

Reusing Spanner (opens in a new tab) sessions with session pools avoids paying session-creation cost for every operation. A Spanner session provides the context for database operations against the Spanner database service and is used to execute transactions that read, write, or modify data. Each session applies to a single database, and creating a new session requires a round trip to the Spanner database service. A session pool is a collection of available sessions that are ready to use, so the pool returns an existing session for an operation and reclaims it for reuse afterward.

This reuse spreads session-creation latency across many operations rather than eliminating it entirely. Spanner sessions are intended to be long-lived, so the client should return each session to the pool after use and the pool cleans up unused sessions. A regular Spanner session executes a single transaction at a time, so the pool must maintain enough sessions for concurrent work. Increasing the pool is different from adding more clients because the pool reuses backend context while additional clients add new connection and session overhead.

2.2Running Concurrent Transactions with Multiplexed Sessions

Running concurrent transactions with multiplexed sessions means executing multiple transactions at the same time on a single Spanner session. Requests flow from the application into the same session context, and the session carries the concurrent transactions to the Spanner database service in parallel. Because fewer distinct sessions are created and maintained, backend overhead and resource consumption are reduced. Standalone reads, writes, and queries each use one transaction internally, so without multiplexing each concurrent operation needs its own session context.

Choose multiplexed sessions when high concurrency would otherwise require a very large session pool. The sharing lowers backend tracking cost for memory and CPU without reducing the number of concurrent transactions the application can submit. This design is especially valuable when hundreds of overlapping requests must share limited database capacity.

2.3Tuning Transport with gRPC Channels and Sizing Pools

Tuning transport with gRPC channels and sizing pools controls both session reuse and network capacity for Spanner and Cloud SQL workloads. A gRPC channel pool is the transport layer that carries Spanner session traffic between the client library and the Spanner database service. When traffic grows, congestion on too few channels increases high tail latency at p95 and p99 even if sessions are available. Tuning the gRPC channel pool increases transport capacity so session requests flow without queuing behind each other.

For Cloud SQL workloads, the same pooling principle applies at the database-connection layer with connection pooling and exponential backoff. An application pool such as HikariCP for Cloud SQL for PostgreSQL and MySQL uses maximumPoolSize to limit total concurrent connections and minimumIdle to keep a minimum number of idle connections warm. Small and short transactions keep pooled connections from being held too long and help the application stay within Cloud SQL connection limits.

2.4Preventing Exhaustion from Ephemeral Serverless Scale-Out

Preventing exhaustion from ephemeral serverless scale-out means controlling how many simultaneous requests and application instances share limited database connections. In cloud environments, compute layers such as Cloud Run (opens in a new tab) and Cloud Run functions can scale from zero to hundreds of ephemeral instances almost instantly, while the database can only support a fixed number of concurrent sessions. Without shared management, each new instance opening its own connections causes connection exhaustion, higher latency, and failed requests.

A Cloud Run instance can serve multiple requests simultaneously up to a configurable maximum concurrency with a default of 80. When traffic spikes, Cloud Run adds instances quickly and each instance that opens its own database connections multiplies total demand. Operators must calculate maximum connections per Cloud Run instance and configure maximum instances so that maximum instances times connections per instance is less than the maximum connections allowed by the database. Cloud Run concurrency also trades latency, throughput, and cost: lower concurrency lowers per-request latency but needs more instances, while higher concurrency raises throughput per instance but increases contention for CPU, memory, and connections.

Assessing auditing policies for managed services means deciding which administrative and data-access events to record, how long to keep them, and who can read them. Cloud Audit Logs (opens in a new tab) records who did what, where, and when on Google Cloud resources. Log entries are written by Google Cloud services to Cloud Logging for each project, folder, and organization, and entries are immutable once written. For managed databases such as Cloud SQL, Spanner, and Bigtable, the same categories separate control-plane administration from data-plane access.

3.1Separating Admin Activity, Data Access, and System Event Logs

Separating Admin Activity, Data Access, and System Event logs means using each category for a different source of change. Admin Activity audit logs record user-driven API calls that modify configuration or metadata, such as creating a Cloud SQL instance, restoring a backup, updating an instance, or changing IAM permissions. Data Access audit logs record user-driven operations that read configuration or read or write user-provided data, such as getting instance details, listing databases, exporting data, or creating and deleting databases. System Event audit logs record automated actions by Google Cloud systems that modify resource configuration, such as maintenance or failover.

The three categories differ in default state and access:

In Cloud SQL, the log category follows the IAM permission type: ADMIN_WRITE generates Admin Activity logs, while ADMIN_READ, DATA_READ, and DATA_WRITE generate Data Access logs. Cloud Audit Logs audit management-API operations on an instance, while database-engine auditing audits SQL inside the database, such as pgAudit for Cloud SQL for PostgreSQL or SQL Server Audit for Cloud SQL for SQL Server.

3.2Choosing Granularity for Data Access Auditing

Choosing granularity for Data Access auditing means deciding which data interactions to log and how much detail to keep. Data Access auditing is divided into three subtypes: ADMIN_READ for reads of configuration or metadata, DATA_READ for reads of user-provided data, and DATA_WRITE for modifications to user-provided data. Enabling only ADMIN_READ gives lightweight visibility into metadata access, while adding DATA_READ and DATA_WRITE gives full visibility into user queries at the cost of much larger log volume.

Configuration is set in the IAM AuditConfig object for a specific service, where an administrator selects whether ADMIN_READ, DATA_READ, and DATA_WRITE are recorded. Greater granularity directly increases log volume, ingestion, and storage cost because every read and write can create an entry, and a single request can generate more than one entry. Teams balance this by enabling DATA_WRITE broadly while limiting high-volume DATA_READ to regulated datasets, exporting logs through a log sink for long-term storage, and combining Cloud Audit Logs with database flags such as slow-query and general logs where engine-level detail is needed.

Viewing rules also control granularity protection. A holder of the Logs Viewer role can read Admin Activity, System Event, and Policy Denied logs but cannot view Data Access logs in the _Default bucket. The Private Logs Viewer role includes Logs Viewer permissions plus permission to read Data Access logs in the _Default bucket. For Cloud SQL, audit entries can be isolated in Logs Explorer with the filter protoPayload.serviceName="cloudsql.googleapis.com".

3.3Retaining, Protecting, and Exporting Audit Telemetry

Retaining, protecting, and exporting audit telemetry means keeping a complete, tamper-resistant record beyond the limited retention in Cloud Logging. Audit telemetry flows from Google Cloud services into Cloud Logging, and from Cloud Logging through log sinks to long-term destinations for compliance and analysis. Exporting logs to BigQuery lets teams view selected columns over time and run aggregate analysis of security and access patterns, while sinks can also route to Cloud Storage or Pub/Sub for archival storage or streaming delivery. Retention policies on log buckets configured with Bucket Lock prevent early deletion.

IAM controls determine who can view, query, and manage log data and its destinations, with predefined, basic, and custom roles plus column-level, row-level, and masking controls for sensitive data. VPC Service Controls (opens in a new tab) prevents exfiltration by placing a virtual network boundary around Google Cloud resources and their audit and database data. The perimeter enforces its boundary even when the requester is authorized by IAM, so traffic that would copy audit telemetry or database exports to an outside project or location is denied. Choose VPC Service Controls when audit logs and managed database exports must stay within approved networks and regions despite valid credentials.

Key Facts

• A Cloud SQL instance cannot gain CMEK after creation; a new CMEK-enabled instance must be created and data migrated to it.
• Private Service Access uses internally managed VPC Network Peering to give Cloud SQL a private IP, and VPC peering is not transitive to a third network.
• When a Cloud SQL instance has both public and private IP, the Cloud SQL Auth Proxy defaults to public IP unless started with -ip_address_types=PRIVATE.
• Maximum Cloud Run instances times connections per instance must be less than the maximum connections allowed by the database to prevent connection exhaustion.
• Admin Activity audit logs are always enabled and cannot be disabled, while Data Access audit logs are disabled by default and must be explicitly enabled.