Cloud SQL Postgres + monitoring et alertes facturation — tutoriel ACE 2026

Déployer une instance Cloud SQL Postgres managée, configurer la haute disponibilité, les sauvegardes automatiques et les read replicas, puis mettre en place Cloud Monitoring et des alertes de facturation pour ne jamais être surpris. Tutoriel pas-à-pas du cluster Associate Cloud Engineer.

📍 Article principal du cluster : Devenir Google Cloud Associate Cloud Engineer (ACE) — Guide complet 2026
Cet article fait partie du cluster « GCP ACE ». Pour la vue d’ensemble, lire d’abord le pilier.

Introduction

Cloud SQL est le service de bases relationnelles managées de GCP : Postgres, MySQL et SQL Server. Pour un candidat ACE, l’essentiel se concentre sur quatre choses : créer une instance Postgres, configurer haute disponibilité et sauvegardes, ajouter une read replica, et mettre en place les alertes de monitoring et de facturation. Ce tutoriel couvre l’ensemble avec des commandes officielles validées sur la doc Google Cloud d’avril 2026, et ferme la boucle du cluster ACE en posant aussi les garde-fous coûts qui complètent ceux du tutoriel Compte GCP gratuit 300 USD sans risque de facturation.

Prérequis

• Compte GCP Free Trial actif et projet lab-ace-2026.
• VPC vpc-lab avec un subnet en europe-west9.
• gcloud CLI ; client psql (apt install postgresql-client ou équivalent).
• Niveau attendu : intermédiaire en SQL, à l’aise avec un terminal.
• Temps estimé : 90 minutes.

Étape 1 — Choisir le moteur et le tier de machine

Cloud SQL propose trois moteurs : Postgres, MySQL et SQL Server. Pour de nouveaux projets en 2026, Postgres est le choix par défaut côté open source — moteur plus moderne et plus complet pour la majorité des charges. Côté tier de machine, on choisit parmi des familles dérivées de Compute Engine : db-f1-micro (legacy, partagé), db-custom-1-3840 (1 vCPU, 3,75 Go), db-custom-2-7680 (2 vCPU, 7,5 Go) et au-delà. Pour un lab ACE, db-custom-1-3840 suffit largement.

Cloud SQL facture trois choses indépendamment : le tier (vCPU + RAM), le storage SSD ou HDD provisionné, et le trafic réseau sortant. Comprendre cette décomposition est utile à l’examen pour répondre aux questions « comment réduire le coût de cette instance ».

Étape 2 — Créer une instance Postgres

INSTANCE="lab-pg"
ROOT_PASS="$(openssl rand -base64 24)"
echo "ROOT_PASS=$ROOT_PASS  # gardez le quelque part de sur"

gcloud sql instances create $INSTANCE \
  --database-version=POSTGRES_16 \
  --tier=db-custom-1-3840 \
  --region=europe-west9 \
  --storage-type=SSD \
  --storage-size=10 \
  --availability-type=zonal \
  --backup-start-time=03:00 \
  --backup-location=eu \
  --enable-point-in-time-recovery \
  --network=projects/lab-ace-2026/global/networks/vpc-lab \
  --no-assign-ip \
  --root-password="$ROOT_PASS" \
  --project=lab-ace-2026

Plusieurs options stratégiques. POSTGRES_16 est la version courante recommandée — Cloud SQL supporte aussi 17 et 14/15 selon la disponibilité. --availability-type=zonal est volontaire : zonal coûte deux fois moins cher que regional (HA), parfait pour un lab. --enable-point-in-time-recovery active les WAL archives qui permettent un PITR jusqu’à la seconde près sur les 7 derniers jours par défaut. --no-assign-ip retire l’IP publique : la base ne sera joignable qu’en privé via Private Service Access depuis le VPC. --backup-location=eu stocke les sauvegardes en multi-région UE pour la conformité RGPD.

La création prend 10 à 15 minutes. Pendant ce temps, configurez la connexion privée si ce n’est pas déjà fait :

# Pre-requis : Service Networking activer + VPC peering pour Cloud SQL
gcloud services enable servicenetworking.googleapis.com

gcloud compute addresses create google-managed-services-vpc-lab \
  --global \
  --purpose=VPC_PEERING \
  --prefix-length=16 \
  --network=vpc-lab

gcloud services vpc-peerings connect \
  --service=servicenetworking.googleapis.com \
  --ranges=google-managed-services-vpc-lab \
  --network=vpc-lab

Étape 3 — Se connecter et créer une base

# Recuperer l'IP privee de l'instance
PG_IP=$(gcloud sql instances describe $INSTANCE \
  --format='get(ipAddresses[0].ipAddress)')

# Depuis une VM dans le VPC :
psql -h $PG_IP -U postgres
# Mot de passe : $ROOT_PASS

postgres=# CREATE DATABASE app_demo;
postgres=# CREATE USER app_user WITH PASSWORD 'p@ssApp123';
postgres=# GRANT ALL PRIVILEGES ON DATABASE app_demo TO app_user;

Cloud SQL Auth Proxy est l’alternative recommandée à la connexion directe psql : il établit un tunnel chiffré authentifié par IAM, sans gérer de mots de passe Postgres. Pour une production, c’est le pattern par défaut.

Étape 4 — Activer la haute disponibilité

Pour passer une instance zonal à HA (regional avec failover automatique), une seule commande. La conversion provoque un redémarrage de quelques secondes mais aucune perte de données.

gcloud sql instances patch $INSTANCE \
  --availability-type=regional

Le coût double (vCPU + RAM facturés en double pour la stand-by replica), mais un failover automatique survient en cas de panne de zone. Pour un lab ACE, restez en zonal pour économiser ; pour un projet de production, regional est obligatoire.

Étape 5 — Ajouter une read replica

Une read replica est une instance Postgres asynchrone qui réplique en streaming les writes du master. Elle sert à offloader les requêtes de lecture sans surcharger le master. Cloud SQL gère la configuration côté Postgres ; vous ne touchez pas aux fichiers de configuration.

gcloud sql instances create lab-pg-read1 \
  --master-instance-name=$INSTANCE \
  --region=europe-west9 \
  --tier=db-custom-1-3840 \
  --replica-type=READ

La read replica peut être promue master en cas de besoin (failover géographique manuel par exemple). Notez qu’une read replica n’est pas une sauvegarde : elle réplique aussi les DROP TABLE. Pour une vraie protection, comptez sur les sauvegardes automatiques + PITR.

Étape 6 — Sauvegardes et restauration PITR

Les sauvegardes automatiques sont activées via --backup-start-time à la création. Par défaut, Cloud SQL conserve 7 jours de sauvegardes. Le Point-in-Time Recovery (PITR) permet de restaurer à n’importe quelle seconde dans cette fenêtre, en s’appuyant sur les transaction logs.

# Lister les sauvegardes
gcloud sql backups list --instance=$INSTANCE

# Restaurer une sauvegarde dans une nouvelle instance
gcloud sql backups restore BACKUP_ID \
  --restore-instance=lab-pg-restored \
  --backup-instance=$INSTANCE

# Cloner avec PITR a un instant precis
gcloud sql instances clone $INSTANCE lab-pg-pitr \
  --point-in-time="2026-04-28T10:30:00Z"

Le clone PITR crée une nouvelle instance avec l’état exact à l’instant T. C’est précieux pour récupérer après un DELETE accidentel sans toucher la prod.

Étape 7 — Cloud Monitoring et alertes

Cloud Monitoring agrège les métriques de toutes vos ressources GCP — CPU, mémoire, latence, IOPS, lag de réplication Cloud SQL. La création d’une alerte sur la CPU se fait via la console Monitoring → Alerting.

# Lister les metriques disponibles pour Cloud SQL
gcloud monitoring metrics list \
  --filter="metric.type=cloudsql.googleapis.com/database/cpu/utilization"

# Voir la metrique en CLI
gcloud monitoring time-series list \
  --filter='metric.type="cloudsql.googleapis.com/database/cpu/utilization"' \
  --interval-end-time=$(date -u +%FT%TZ)

Les alertes se configurent en YAML ou via la console. Recommandations pour Cloud SQL : alerte CPU > 80 % sur 5 minutes, lag de réplication > 60 secondes, espace disque < 20 %, connexions actives > 80 % du max. Notification par email + Slack via webhook Pub/Sub pour les incidents critiques.

Étape 8 — Budget alerts pour fermer la boucle

On revient à l’étape garde-fou facturation, puisque Cloud SQL est l’un des services les plus coûteux quand mal configuré.

gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="Budget cluster ACE" \
  --budget-amount=100USD \
  --threshold-rule=percent=0.5,basis=ACTUAL \
  --threshold-rule=percent=0.9,basis=ACTUAL \
  --threshold-rule=percent=1.0,basis=ACTUAL \
  --threshold-rule=percent=1.0,basis=FORECASTED

Pour aller plus loin, scriptez l’arrêt automatique des instances en cas de dépassement : Pub/Sub topic associé au budget alert + Cloud Function qui exécute gcloud sql instances patch --activation-policy=NEVER sur les instances cibles. Pattern de production recommandé pour les comptes formation et POC.

Étape 9 — Cleanup

# Supprimer la read replica avant le master
gcloud sql instances delete lab-pg-read1 --quiet

# Supprimer le master
gcloud sql instances delete $INSTANCE --quiet

# Conserver les sauvegardes ? Par defaut elles sont supprimees avec l'instance.
# Pour conserver, exporter avant suppression :
# gcloud sql export sql $INSTANCE gs://$BUCKET/backup.sql --database=app_demo

Erreurs fréquentes

Adaptation au contexte ouest-africain

Coût Cloud SQL pour PME UEMOA. Une instance Postgres db-custom-2-7680 zonal en europe-west9 avec 50 Go SSD et 7 jours de backups tourne typiquement autour de 50-70 USD/mois — moins qu’une VM dédiée bien dimensionnée pour faire la même chose, et avec sauvegardes incluses. Pour un ERP Odoo de PME ivoirienne ou un CRM sénégalais, c’est rentable.

Conformité RGPD/ARTCI/CDP. Le paramètre –backup-location=eu garantit que les sauvegardes restent en Union européenne — point indispensable pour des audits ARTCI ou CDP. Documentez ce choix dans votre PIA (Privacy Impact Assessment) côté client.

Latence applicative. Une app hébergée à Hetzner (Allemagne) ou OVH (Roubaix) qui appelle Cloud SQL en europe-west9 ajoute 10-20 ms de latence inter-cloud — acceptable pour la plupart des workloads. En revanche, app à Dakar/Abidjan + Cloud SQL Paris = 100-150 ms par requête : pour une app très chatty, regrouper l’app et la base sur GCP plutôt que faire du multi-cloud.

Migration depuis MySQL on-prem. Cloud SQL Database Migration Service est un outil dédié qui réplique en streaming une base MySQL/Postgres on-prem vers Cloud SQL avec basculement final en quelques minutes. Pour une PME africaine qui veut sortir de son serveur Tigo/Sonatel sans interruption, c’est l’outil officiel à connaître pour l’examen et utile en pratique.

Bonus — Cloud SQL Auth Proxy en pratique

Le Cloud SQL Auth Proxy est l’outil officiel recommandé pour connecter une application à une instance Cloud SQL. Il établit un tunnel chiffré authentifié par IAM, sans IP publique exposée et sans gestion de mots de passe Postgres dans l’application. C’est le pattern par défaut en production en 2026.

# Telecharger le proxy (linux amd64)
curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.13.0/cloud-sql-proxy.linux.amd64
chmod +x cloud-sql-proxy

# Lancer le proxy avec le service account attache (typique sur une VM)
./cloud-sql-proxy --address=127.0.0.1 --port=5432 \
  lab-ace-2026:europe-west9:lab-pg

# Cote application, se connecter en local
psql -h 127.0.0.1 -U app_user -d app_demo

Sur Kubernetes, le proxy s’exécute typiquement comme sidecar container dans le pod applicatif, accessible sur localhost. La doc officielle GKE détaille le manifest YAML standard. Pour Cloud Run, il existe un mode natif Cloud SQL connections qui injecte automatiquement le proxy sans manipulation manuelle.

Les permissions IAM requises côté service account : roles/cloudsql.client pour se connecter, roles/cloudsql.instanceUser pour authentifier en mode IAM database authentication (sans mot de passe Postgres du tout). Ce dernier mode est la pratique la plus moderne : un compte Google IAM s’authentifie directement à Postgres, et la rotation des credentials est automatique.

Bonus — Questions complémentaires

Quelle est la différence entre Cloud SQL et un Postgres self-hosted sur Compute Engine ?
Cloud SQL gère pour vous les sauvegardes, le failover, le patching minor de Postgres, les rotations TLS et le monitoring. Le surcoût par rapport à un Postgres self-hosted est typiquement de 30 à 50 % du coût brut de la VM, ce qui est généralement très inférieur au coût opérationnel d’un DBA junior pour faire le même travail manuellement.

Peut-on utiliser des extensions Postgres custom ?
Cloud SQL maintient une liste d’extensions supportées (postgis, pgvector, pg_partman, etc.). Les extensions hors liste ne peuvent pas être installées. Pour des besoins d’extensions exotiques, AlloyDB ou Postgres self-hosted sont des alternatives.

Le free tier couvre-t-il Cloud SQL ?
Pas complètement. Cloud SQL n’est pas dans la liste Always Free. Il consomme votre crédit Welcome de 300 USD pendant les 90 jours. À la fin, soit upgrade payant, soit suppression de l’instance pour ne pas être facturé.

Tutoriels frères

• Compute Engine : déployer une VM Linux et Windows — l’app qui tournera devant la base.
• Cloud Storage : buckets, versioning, lifecycle, sécurité — où exporter les dumps SQL pour archivage long terme.

Pour aller plus loin

• 🔝 Retour au pilier : Devenir Google Cloud Associate Cloud Engineer (ACE) — Guide complet 2026
• Doc Cloud SQL Postgres : cloud.google.com/sql/docs/postgres
• Cloud Monitoring : cloud.google.com/monitoring/docs
• Database Migration Service : cloud.google.com/database-migration
• Suggestion de fin de cluster : revenir au pilier pour valider votre vue d’ensemble.

FAQ

Cloud SQL ou Cloud Spanner ?
Cloud SQL pour 99 % des cas : Postgres/MySQL/SQL Server standards, scaling vertical, prix raisonnable. Cloud Spanner pour des charges qui exigent du scaling horizontal automatique sur des téraoctets, avec consistance forte distribuée — c’est rare et cher.

Combien de read replicas peut-on avoir ?
Jusqu’à plusieurs dizaines selon la version Postgres et le tier. En pratique, 2-3 suffisent pour la plupart des charges. Au-delà, le master devient le goulet d’étranglement.

Combien de temps Cloud SQL conserve-t-il les sauvegardes ?
7 jours par défaut, configurable jusqu’à 365 jours via –retained-backups-count. PITR ajoute la granularité seconde sur la fenêtre de rétention.

Cloud SQL Auth Proxy vs IP privée VPC ?
Les deux fonctionnent. Auth Proxy ajoute un chiffrement IAM-authentifié et est recommandé pour les apps modernes. IP privée VPC est plus simple à mettre en place et fonctionne avec n’importe quel client compatible Postgres standard.

Comment migrer Postgres on-prem vers Cloud SQL sans downtime ?
Database Migration Service avec mode Continuous : il copie d’abord la base initiale, puis applique en streaming les changements jusqu’au cutover final que vous déclenchez quand vous êtes prêt.

Le PITR fonctionne-t-il après suppression d’une table ?
Oui, à condition d’avoir activé PITR avant la suppression. Vous clonez à la seconde précédant le DROP, puis exportez la table depuis le clone. C’est exactement le cas d’usage classique du PITR.

Mots-clés : Cloud SQL, Postgres GCP, haute disponibilité, read replica, PITR, Cloud Monitoring, alertes facturation, Database Migration Service, ACE certification database