App Service : le plan fait la facture
Une Web App tourne dans un plan App Service, qui réserve des instances. On paie ces instances en continu, que les applications soient sollicitées ou non. Les leviers :
- Choisir le bon tier. Premium et Isolated se justifient pour la performance, l'isolation ou la sécurité. Hors prod, Basic ou Standard suffisent presque toujours.
- Dimensionner sur l'usage réel. Nous regardons le CPU et la mémoire sur plusieurs semaines. Exemple réel : un plan qui n'a jamais dépassé 50 % de sa capacité pendant trois semaines, passé de B3 à B1, a vu son coût journalier baisser des deux tiers.
- Linux par défaut. Sur tous les tiers, un plan Windows coûte plus cher qu'un plan Linux, et Azure Hybrid Benefit ne s'y applique pas.
- Supprimer les plans vides. Supprimer toutes les applications d'un plan ne supprime pas le plan, qui reste facturé.
- Mutualiser les Web Apps et les Functions d'un même périmètre sur un plan existant.
- Autoscaling en prod si la charge suit un cycle jour et nuit ou saisonnier, et une seule instance minimum hors prod.
- Réserver les plans Premium v3 stables, une fois l'usage optimisé.
Une requête Azure Resource Graph suffit pour repérer les plans vides :
Resources
| where type =~ 'microsoft.web/serverfarms'
| where properties.numberOfSites == 0
| project name, resourceGroup, sku = tostring(sku.name)Avant de réduire un plan pour une application qui fait beaucoup de multithreading, nous testons l'impact sur les performances : moins de cœurs peut ralentir certains traitements.
Azure Functions
En plan Consumption, on paie à l'exécution : rien à dimensionner. Dans un plan App Service, la capacité est fixe, quelle que soit l'activité. Pour une activité continue, le plan dédié peut revenir moins cher ; pour une activité ponctuelle, c'est l'inverse. Le plan d'hébergement se choisit à la création : en changer impose de redéployer.
Azure SQL Database
- Rightsizing des vCores ou des DTU à partir de l'usage réel.
- Serverless avec auto-pause pour les bases peu sollicitées, typiquement hors prod.
- Elastic pools quand plusieurs bases ont des pics à des moments différents.
- Réservation des vCores pour les bases de prod stables.
- Géo-réplication challengée : elle double à peu près le coût, et n'a pas toujours de justification hors prod.
MySQL, PostgreSQL et MariaDB
Les serveurs flexibles MySQL et PostgreSQL peuvent être arrêtés : ils redémarrent automatiquement au bout de 30 jours, l'arrêt doit donc être automatisé. En non-prod, c'est le même raisonnement que le Stop/Start des VM. En prod : rightsizing, réservation et géo-réplication justifiée.
Cosmos DB
Autoscale du débit plutôt qu'un débit provisionné pour le pic, mode serverless pour les faibles trafics, capacité réservée pour la prod stable, et géo-redondance limitée aux régions réellement nécessaires.
Application Gateway, Front Door et Event Hubs
- Application Gateway : un coût fixe à l'heure plus des unités de capacité. Autoscaling avec un minimum d'instances bas, WAF seulement là où il est utile, et mutualisation des gateways entre applications.
- Front Door : quand un groupe d'origines n'a qu'un seul backend, les health probes sont inutiles et peuvent être désactivées.
- Event Hubs : l'auto-inflate augmente les throughput units mais ne les réduit pas tout seul. Il faut fixer un maximum et revenir au besoin réel.