Securely Connect Compute Engine to Cloud SQL Using the Cloud SQL Proxy with IAM Authentication

Quick answer: use the Cloud SQL Proxy with an IAM‑enabled service account

Run the Cloud SQL Proxy on a Compute Engine VM, authenticate it with a service account that has the roles/cloudsql.client role, and connect your application to 127.0.0.1:3306 (or 5432 for PostgreSQL) as if the database were local. No SSL certificates or authorized networks are required.

How the proxy works

The Cloud SQL Proxy creates a secure tunnel from the VM to the Cloud SQL instance over HTTPS. It exchanges OAuth tokens for the service account, then forwards traffic to the instance’s private IP. The proxy adds only a few milliseconds of latency and is limited by the VM’s outbound bandwidth and the instance’s maximum connections.

Worked example on a Compute Engine VM

1. Create a service account (or use an existing one) and grant it roles/cloudsql.client:

gcloud iam service-accounts create sql-proxy-sa \
    --display-name "Cloud SQL Proxy SA"
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:sql-proxy-sa@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudsql.client"

1. Enable the Cloud SQL Admin API in the project:

gcloud services enable sqladmin.googleapis.com

1. Download and install the proxy on the VM (choose the Linux binary for your architecture):

wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -O cloud_sql_proxy
chmod +x cloud_sql_proxy

1. Start the proxy, specifying the instance connection name and a local TCP port:

./cloud_sql_proxy \
    -instances=$PROJECT_ID:$REGION:$INSTANCE_NAME=tcp:3306 \
    -credential_file=/path/to/sql-proxy-sa-key.json &

The proxy runs in the background and listens on 127.0.0.1:3306.

1. Verify the tunnel from the VM:

# Check that the proxy is listening locally
netstat -tlnp | grep 3306
# Try a MySQL client connection (replace USER and DB as needed)
mysql -u USER -p -h 127.0.0.1 -P 3306 DB_NAME

If you can log in without providing --ssl-ca or similar options, the proxy is working.

1. Optional: view Cloud SQL logs to confirm the connection originated from the proxy’s IP:

gcloud sql instances describe $INSTANCE_NAME \
    --format="value(connectionName)"
# Then in Cloud Logging, filter for resource.type="cloudsql_database" and
# jsonPayload.instance="$INSTANCE_NAME" and look for successful login events.

Limits and considerations

• Latency: Expect ~1‑2 ms added round‑trip time; acceptable for most applications.
• Bandwidth: The proxy is bounded by the VM’s outbound network quota and the Cloud SQL instance’s egress limits.
• Connection limits: Each connection through the proxy counts toward the instance’s maximum connections; the proxy does not pool connections.
• Throughput: Not designed for extremely high‑throughput workloads where a direct IP with SSL might be preferable.
• Token refresh: The proxy automatically renews OAuth tokens, but if the service account key is rotated you must restart the proxy to pick up the new key.

Common mistakes and how to avoid them

• Missing Cloud SQL Admin API: Results in invalid_grant errors. Enable the API before starting the proxy.
• Incorrect instance connection name: Use the format PROJECT_ID:REGION:INSTANCE_NAME; a typo yields could not find instance.
• Insufficient IAM role: Without roles/cloudsql.client the proxy logs Permission denied. Grant the role to the service account.
• Outdated proxy binary: Older versions may fail to refresh tokens. Download the latest release from the official Cloud SQL Proxy page.
• Not restarting after key rotation: The proxy caches the credential file; restart the process after updating the key.
• Connecting to the wrong port: Ensure your application points to 127.0.0.1 and the port you specified (e.g., 3306 for MySQL).