Les différents services Azure offrent des fonctionnalités et des niveaux de prix variés. Une fois que vous avez choisi un plan, ne laissez pas ses fonctionnalités inutilisées. Trouvez des moyens de les exploiter pleinement pour rentabiliser votre investissement. Surveillez également vos modèles de facturation : il est judicieux de vérifier s’il existe un modèle plus adapté à votre utilisation réelle du service.

Scénario d’exemple

Contoso University utilise un système COTS (commercial prêt à l’emploi) qui aide les enseignants à gérer les cours et les étudiants à s’inscrire. Ce système est connecté à une plateforme cloud de gestion de l’éducation, vers laquelle l’université prévoit de migrer complètement dans quelques années. Pour l’instant, elle souhaite optimiser les coûts des parties personnalisées de l’intégration.

La solution COTS est généralement considérée comme une boîte noire, sauf pour sa base de données, qui fonctionne sur Azure Database for MySQL. L’intégration personnalisée est une fonction durable Azure exécutée en parallèle sur un plan App Service Standard, qui hébergeait auparavant le site web de l’université (désormais retiré). Cette fonction durable est une application Python qui utilise Azure Storage et synchronise les données chaque nuit entre la base MySQL et l’API cloud.

Utiliser pleinement la valeur de vos ressources

Achetez uniquement ce dont vous avez besoin, et utilisez tout ce que vous payez.

Certains SKU de ressources incluent des fonctionnalités intégrées de performance, sécurité ou fiabilité. Si vous les payez, assurez-vous de les utiliser. Et si vous n’en avez pas besoin, choisissez un SKU plus simple pour économiser.

Défi de Contoso

La fonction durable s’exécute sur un plan App Service Standard dimensionné à l’origine pour un site web public, aujourd’hui retiré.

L’équipe n’a jamais réévalué le SKU, donc elle continue de payer pour des fonctionnalités et une capacité inutilisées.

Elle ne sait pas quelles fonctionnalités sont réellement nécessaires pour la charge d’intégration.

Approche et résultats

L’équipe examine le plan App Service actuel et conclut que l’intégration ne nécessite pas autant de scalabilité ni de performance. Elle migre la fonction vers un plan de niveau inférieur, compatible avec les fonctions durables mais beaucoup moins coûteux.

Elle vérifie également le SKU MySQL et confirme qu’il est adapté à la charge actuelle.

Ces changements permettent de réduire les coûts sans affecter la performance ni la fiabilité.

Optimiser la conception haute disponibilité

Privilégiez les modèles actif-actif ou actif-seul plutôt que actif-passif, surtout si vous avez déjà payé pour les ressources.

Un modèle actif-passif peut entraîner des ressources inactives. Passer à un modèle actif-actif peut vous aider à répondre aux pics de charge sans surcoût. Si vos objectifs de récupération peuvent être atteints avec un modèle actif-seul, vous pouvez éliminer complètement les coûts liés aux ressources passives.

Défi de Contoso

L’application COTS utilise Azure Database for MySQL Flexible Server avec une haute disponibilité dans la même zone, ce qui implique un serveur de secours. Les sauvegardes automatiques sont activées.

Les objectifs de récupération sont :

• RPO (point de récupération) : 12 heures
• RTO (temps de récupération) : 3 heures pendant la journée scolaire

Les tests montrent que ces objectifs peuvent être atteints via le basculement automatique ou la restauration depuis une sauvegarde.

Approche et résultats

L’équipe réévalue le rapport coût/bénéfice de la haute disponibilité, sachant que le service coûte deux fois plus qu’une instance unique.

Elle teste la création d’une nouvelle instance et la restauration depuis une sauvegarde, et constate que les objectifs sont toujours respectés. Elle décide donc de supprimer l’instance de secours.

Le plan de reprise après sinistre est mis à jour, et l’équipe réalise des économies grâce à cette nouvelle configuration.

Adapter intelligemment la capacité à la demande

Ajustez la capacité en fonction de vos besoins réels.

Au lieu de provisionner pour une utilisation maximale en permanence, augmentez la capacité en cas de demande et réduisez-la lorsqu’elle baisse. Cette approche permet de aligner les coûts sur l’utilisation réelle.

Défi de Contoso

La fonction d’intégration s’exécute chaque nuit, mais le plan App Service reste actif toute la journée.

L’université paie pour des ressources de calcul inutilisées pendant la majeure partie du temps.

L’équipe n’a pas exploré les options de mise en veille ou de réduction automatique.

Approche et résultats

L’équipe configure le plan App Service pour réduire la capacité en dehors des heures d’activité.

Elle envisage de migrer la fonction vers Azure Container Apps ou le plan de consommation Azure Functions, qui peuvent scaler à zéro.

Elle met en place des alertes pour surveiller l’utilisation et ajuster les règles de scalabilité.

Ces changements permettent de réduire le gaspillage et d’aligner les coûts sur l’utilisation réelle.