AWS vs OVH : performance, coûts et pourquoi nous avons changé (-122.000€ par an)

Dans le cadre de notre mission chez ViscaWeb, Djulian et moi-même avions la responsabilité d’assurer que tous nos sites, principalement des sites WordPress, soient constamment accessibles, rapides, et parfaitement fonctionnels. C’était le cas depuis 10 ans maintenant, mais la stabilité du trafic envoyé via le SEO a rendu un système alors pensé pour auto-scaler et être élastique totalement inutile.

Le constat ? On est à environ 345€ / jour de dépenses d’hébergement chez AWS.

J’ai exporté nos coûts mensuels une année entière, et on arrive donc à un total, assez dérisoire finalement… de 130.000€ 😨

Pour faire tourner une trentaine de sites WordPress et des sites de résultats sportifs en ligne avec des bases de données assez grosses. L’infrastructure est élastique (les instances EC2 peuvent se multiplier en fonction de différents critères) mais avec le temps, grâce à l’implémentation de technologies comme Varnish, les ressources réellement nécessaires afin d’offrir une navigation optimale à nos utilisateurs ont drastiquement chuté.

Notre conclusion ? On payait pour une élasticité qui n’était plus nécessaire.

Au-delà de la réduction de coûts, on a aussi décidé de professionnaliser encore un peu plus nos sites WP : ils sont déjà tous versionnés via GIT + BedRock mais Docker n’était pas encore utilisé en production. On va donc pallier à ça.

Notre objectif : professionnaliser encore un peu plus et surtout, limiter les coûts d’hébergement à 10.000€ par an (soit environ 840€ par mois).

Le constat : 130.000 € par an pour une infra figée

Dans cet article, je me concentrerai sur le plus important : EC2 + RDS. Sachant que VPC, ELB, etc. sont inclus dans EC2, en migrant ces 2 services principaux, nous réduirons déjà de 80-85 % l’ensemble.

Pourquoi ne pas pré-réserver les instances et demander un discount à AWS ? C’est une question que l’on s’est posée avant de commencer ce chantier. Si on réservait ces instances sur 3 ans, on aurait pu économiser approximativement 60%. On serait donc passé à approximativement 130 000€ — 60% soit 52 000€. Pour ça, il fallait être sûr de s’engager pour aussi longtemps et on dépenserait, quand même, 5x plus que notre objectif (de limiter les coûts à 10 000 € par an).

Pourquoi cette architecture n’avait plus aucune raison d’exister

Avoir un serveur indépendant pour chaque site, une BDD via RDS (MySQL) qui est absolument hors de prix et lente n’avait plus de sens. C’est vraiment commode au début, AWS permet d’absolument tout faire.

On est des fans inconditionnels d'AWS, mais maintenant que notre infrastructure est parfaitement maîtrisée et stable et que peu de choses évoluent , OVH pouvait nous convenir.

Pour mieux comprendre d’un point de vue technique, voici comment tournaient ces sites internets :

Comme vous le voyez, tout est facturé. Absolument tout. AWS est absolument merveilleux, complet et puissant, mais il faut que ça en vaille la peine.

Chez OVH, on paie le serveur dédié et c’est tout :

On aurait pu prendre un seul serveur EC2 chez AWS et suivre le même processus, mais le rapport coût/puissance est incomparable.

Parlons de vitesse concernant MySQL : J’avais déjà un peu comparé la vitesse d'exécution de PHP, cependant je voulais surement m’assurer que la base de données allait suivre. Faisons un petit focus sur RDS. J’ai comparé les performances de notre serveur à celles d’une instance RDS db.t3.xlarge, dont le coût est similaire chez AWS.

Le coût mensuel est très proche : environ 120 €/mois pour le serveur OVH, et ~120 €/mois pour RDS (hors backups, IOPS, snapshots, data transfer, monitoring… qui peuvent faire grimper la facture très vite).

Pour avoir une comparaison propre, j’ai lancé un benchmark sysbench (MySQL 8.0) identique sur les deux environnements : même nombre de tables, même volume de données, même nombre de threads, même durée.

Test.             | AWS RDS  | OVH Dedicated (MySQL Docker)

Transactions/sec  | 641      | 3 928 (x6)
Queries/sec       | 12 840   | 78 608 (x6)
Latence moyenne.  | 24,93 ms | 4,07 ms (x6)
P95               | 37,56 ms | Euron 5,00 ms (x7) 

C’est absolument incomparable. RDS est effectivement facile, il n'y a aucune gestion et je le recommande pour tous ceux ignorant comment gérer tout ça par soi-même, mais niveau performances, on n’y est pas.

Notre plan

Tout réunir sur des serveurs dédiés qui sont aujourd’hui largement assez puissants pour faire tourner l’ensemble de ces services. Le plan se découpe donc comme ceci :

• Étape 1 : Dockeriser les applications
• Étape 2 : Réserver le serveur, le préparer avec Dokploy
• Étape 3 : Monter un MySQL via Docker
• Étape 4 : Monter les sites via Docker

Étape 1 : Dockeriser absolument tout

L’étape 1 a été radicale : on a tout passé sous Docker.

Chaque image devait contenir tout ce qui lui permet de fonctionner, sauf MySQL qu’on a décidé de mutualiser pour une gestion plus simple.

L’image contient donc : PHP, Redis et Varnish. Apache est géré par Dokploy (on en parle plus tard) et MySQL est commun. On voulait une infra propre, portable, cohérente et surtout reproductible. Qu’un site tourne sur AWS, OVH ou un Raspberry Pi, peu importe : le container doit répondre pareil.

Je partage ici l’équivalent de notre docker-compose final pour ceux qui en auraient le besoin.

Étape 2 : Choisir OVH et miser sur le dédié

Pourquoi OVH

On a choisi OVH pour une raison très simple : le prix est imbattable pour des serveurs dédiés.

Les machines sont performantes, fiables et OVH a des infrastructures aux USA, ce qui est crucial pour nos audiences. Mais, soyons honnêtes : leur support est catastrophique.

Je le savais d’expérience. Ça nous est arrivé d’attendre des heures, parfois des jours, pour une réponse. Et c’est ça qui est frustrant : OVH sera toujours derrière AWS, rien qu’à cause du manque d’investissement dans le support. Toutes les personnes que j’ai pu avoir au téléphone ont été efficaces et très agréables, mais j’ai dû attendre en moyenne 20min pour que quelqu’un prenne l’appel.

Quel dommage. Mais, pour nous, c’était largement suffisant : on savait être autonomes, et nos besoins n’avaient rien de complexe.

L’architecture retenue

Au final, nous sommes partis sur 3 serveurs dédiés, pour un total d’environ 600 € par mois.

On aurait pu optimiser et ne prendre qu’un seul serveur, cependant on a préféré mettre les sites importants sur des serveurs dédiés indépendants, juste au cas où.

On a aussi évoqué la stratégie de redonder les sites les plus importants sur chaque machine… cela demande d’avoir une architecture beaucoup plus complexe avec des MySQL synchronisés et un système de load-balancer automatique en cas de down d’un serveur. Puisque notre uptime est de 99.7% sur les 3 dernières années, ça n’en valait pas la peine, pour nous, en tout cas.

Ainsi, on a surdimensionné les machines pour dormir tranquille et rassurer le business. En réalité, vu les gains énormes qu’on a réalisés, on pouvait largement se le permettre (en vitesse de croisière normale, moins de 5% des ressources CPU sont utilisées… merci Varnish).

Voici le serveur qu’on a pris:

• CPU: AMD EPYC 4344P — 8c/16t — 3.8 GHz/5.3 GHz
• Mémoire: 64GB (que ’on a changé pour 128GB)
• Disque dur: 2×960 GB SSD NVMe Soft RAID
• Prix: 119€ par moisC’est parti pour l’installation

Grâce à un de mes Youtubeurs préférés, cocadmin, j’ai découvert cet outil magnifique : Dokploy.

Jusque-là, on déployait manuellement Docker via un petit script PHP maison, Dokploy lui professionnalise le tout, il permet d’avoir une interface hyper claire, segmentée et collaborative pour gérer ses images Docker. Le plus sympa dans tout ça, c’est qu’il s’occupe de mapper le nom de domaine à l’image Docker, c’est en général le plus fastidieux à faire.

On a installé notre serveur sur Ubuntu 24, le serveur est tout neuf, je m’y connecte en SSH et c’est parti :

sudo apt update && sudo apt upgrade -y
curl -sSL https://dokploy.com/install.sh | sh

Et c’est tout, on peut déjà y accéder via l’URL: http://<VOTRE_IP_SERVEUR>:3000

Un petit coup de règles de sécurité pour n’autoriser que les connexions SSH, HTTP + HTTPs et les connexions à l’interface Dokploy (sur le port 3000, par défaut).

sudo ufw allow 22
sudo ufw allow 80
sudo ufw allow 443
sudo ufw allow 3000
sudo ufw enable

Étape 3 : Mise en place de MySQL

Installer MySQL m’a pris moins de 30 secondes, sans exagérer.

Pour commencer, au niveau du projet, j’ai configuré une variable d'environnement MYSQL_PASSWORD:

Puis j’ai juste lancé une nouvelle image MySQL:

services:
  mysql:
    image: mysql:8.2
    container_name: mysql
    restart: unless-stopped
    command: --innodb-buffer-pool-size=8G
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_HOST: "%"
      MYSQL_ROOT_PASSWORD: ${MYSQL_PASSWORD}
    networks:
      - dokploy-network

networks:
  dokploy-network:
    external: true

C’est tout, mais laissez-moi vous donner quelques explications :

• L’image utilisée est l’image officielle de MySQL.
• J’ai besoin de plus de mémoire tampon InnoDB (InnoDB buffer memory), c’est la raison de la commande personnalisée.
• Je mappe le port 3306 du serveur vers le port 3306 local de l’image Docker, afin que les sites web puissent facilement y accéder.
• Le port 3306 étant fermé à Internet (voir le pare-feu ci-dessus), j’accepte d’ouvrir l’accès root à % pour faciliter la connexion (même si, je dois l’admettre, je n’aime toujours pas trop ça).
• Je réutilise le mot de passe défini dans la configuration globale du projet
• Et enfin, j’utilise le réseau partagé officiel de Dokploy pour que les sites web puissent le partager et y accéder.

Étape 4 : Lancer les sites

Nous avons donc abandonné Elastic Beanstalk et toutes ses couches « magiques ». Dokploy lirait directement un docker-compose depuis Git, mais nous n’en sommes pas encore là, ça viendra. Pour l’instant, nous sommes encore en phase d’apprentissage et d’itération, et les besoins business ne nous permettent pas d’y consacrer des semaines.

Nous avons donc choisi un compromis simple et efficace : déployer manuellement le docker-compose (au fond, juste un copier-coller depuis notre repo). Et pour mettre à jour un site, il nous suffit d’uploader les nouveaux fichiers, de relancer le service… et c’est tout. Le CI/CD est devenu évident, lisible, débuggable. On contrôle chaque étape. On fait un ZIP, on l’envoie via SCP, on le dezip, on relance Docker, et c’est tout. On a bien un downtime qu’on accepte: 1 seconde à chaque déploiement.

Pour rappel, notre image se trouve ici.

Dernière étape : faire pointer notre domaine vers l’IP du serveur. Concrètement, nos sites communiquent en HTTP avec le serveur, et c’est Cloudflare qui se charge d’assurer le HTTPS pour l’utilisateur final. Comme nous ne gérons aucune transaction et que nos sites sont majoritairement statiques, ce fonctionnement est largement suffisant.

Dressons un bilan rapide :

Voici un aperçu de la consommation en production :

Le MySQL étant partagé pour tous les sites, on peut voir qu’on consomme vraiment rien… la plupart des requêtes restent au niveau de Varnish et ne demandent aucune ressource à PHP ni MySQL.

Comparaisons du TTFB sur un de nos sites:

• À gauche, ce qu’on avait chez AWS: 402ms.
• À droite, chez OVH, on obtient : 362ms.

Notre conclusion

Réduction de coûts : on passe d’une moyenne de 345€ par jour (130.000€ / 365) à 15€ par jour d’AWS (soit 465€ par mois) + environ 600€ par mois d’OVH : on est donc à environ 13.000€ par an, un peu au-dessus de l’objectif de 10.000€ mais quand même une économie de 135.000€ — 13.000€ soit 122.000€ par an d’économies.

Technique : sur une même machine, on fait très largement tourner PHP + MySQL + Varnish + Redis. Les performances fournies aujourd’hui sont absolument fantastiques, AWS n’a plus de sens pour nous. Tout est plus rapide, plus fluide. Mais… on n’a plus aucune élasticité, certes, mais les serveurs peuvent accueillir x10 de trafic.

AWS est magique quand on a besoin d’élasticité, quand on scale, quand on fait du microservice ou du Big Data. C’est aussi parfait quand on commence un projet, on peut accéder à une infrastructure et un support dignes des plus hauts standards avec une facturation à la minute, parfait pour faire ses tests. Mais pas dans notre cas.

Je vous montrerai dans un prochain article comment nous avons mis en place un système de sauvegarde robuste.