30 € par mois pour des serveurs qui dormaient
Avant la migration, mes projets perso me coûtaient environ 30 €/mois de compute sur GCP Cloud Run. Rien de dramatique. Mais quand j'ai regardé les métriques, le constat piquait : ces services dorment 95% du temps. Je payais surtout du vide.
Ce billet raconte comment je suis passé à quasi 0 € — non pas en coupant des features, mais en changeant de modèle d'exécution.
Le secret : scale-to-zero, pour de vrai
Un Serverless Container configuré en min-scale = 0 ne garde aucune instance allumée quand personne ne l'utilise. Au premier visiteur, il démarre à froid en quelques secondes ; ensuite il reste chaud le temps du trafic, puis s'éteint. Pour un usage perso — quelques visites par jour — ça veut dire : on ne paie que les secondes réellement servies.
C'était déjà possible sur Cloud Run, mais Scaleway ajoute deux choses qui font la différence sur ce profil :
- Pas de frais par requête (Cloud Run facture aussi la requête)
- Object Storage gratuit sous 75 Go + egress quasi nul entre services co-localisés à Paris
Les chiffres
| Poste | Avant (GCP) | Après (Scaleway) |
|---|---|---|
| Compute perso | ~30 €/mois | ~0 € au repos |
| Stockage (~5 Go) | facturé | gratuit (<75 Go) |
| Egress inter-services | cross-cloud | co-localisé ~0 |
Le vrai piège à éviter
Le scale-to-zero a un coût caché : le cold start. Sur une app lourde, quelques secondes d'attente au réveil peuvent gêner. Deux parades : garder les images Docker légères (multi-stage build), et — si un service a vraiment besoin d'être toujours chaud — assumer un min-scale = 1 ciblé. Le bon réflexe FinOps, ce n'est pas « tout à zéro », c'est payer pour ce qu'on utilise vraiment.
Moralité : sur un patrimoine de petits services, l'architecture d'exécution pèse plus lourd que le prix du vCPU affiché. Le scale-to-zero, bien utilisé, transforme une facture fixe en dépense proportionnelle à l'usage réel.
Commentaires
Aucun commentaire pour le moment.