Tarification, gestion des coûts et gouvernance du cloud

Une facture cloud est construite à partir d’unités de tarification. Le calcul peut être facturé à la seconde ou à l’heure, le stockage par Go-mois et les requêtes par tranche de 1 000 ou par million d’opérations. Les fonctions sans serveur combinent généralement des frais d’invocation et le temps d’exécution multiplié par la mémoire attribuée. Augmenter la mémoire attribuée modifie les frais liés à la mémoire et au temps.

Associer la quantité au tarif

Pour une machine virtuelle à un tarif fictif de 0,10 € par heure, un mois de 730 heures coûte 73 €. Un fonctionnement de 10 heures pendant chacun des 22 jours ouvrés représente 220 heures et coûte 22 €. Son disque de 100 Go à 0,08 € par Go-mois ajoute 8 € dans les deux cas s’il reste provisionné tout le mois. Le calcul planifié et le stockage conservé totalisent 30 €.

La convention des 730 heures répartit en moyenne les 8 760 heures annuelles sur 12 mois ; la durée des mois civils varie. De nombreuses machines virtuelles sont facturées à la seconde avec un minimum d’une minute, tandis que d’autres produits sont facturés à la minute ou à l’heure.

Une capacité inutilisée peut encore coûter de l’argent

La capacité provisionnée est la capacité réservée à ta ressource. Une machine virtuelle en fonctionnement ou une base de données provisionnée entraîne des frais selon sa taille et sa durée, même si elle effectue peu de travail. Les requêtes sur les objets et les invocations de fonctions suivent plus directement l’utilisation. Un disque provisionné est facturé selon sa taille allouée, et pas seulement selon les fichiers qui y sont écrits.

L’arrêt d’une instance AWS EC2 met fin à ses frais de calcul. Sur Azure, la machine virtuelle doit être arrêtée et désallouée pour mettre fin à la facturation du calcul. L’arrêt de son système d’exploitation la laisse allouée et facturée. Les disques et les instantanés restent des ressources facturables distinctes ; les adresses IP publiques conservées peuvent également entraîner des frais.

Comparer des configurations équivalentes

Une comparaison de prix doit garder constants les vCPU, la mémoire, la région, le système d’exploitation et le modèle d’achat. Les images Windows Server ou SQL Server peuvent inclure une licence logicielle dans leur tarif. Des licences existantes éligibles peuvent réduire le tarif. La région influe sur le prix, la latence et la résidence des données.

Les logiciels de place de marché ajoutent des frais tiers à la facture du fournisseur. La conversion de devise et les taxes peuvent ensuite modifier le total de la facture. AWS Pricing Calculator exclut les taxes ; les factures peuvent ajouter une taxe sur les ventes, une TVA ou une taxe sur les biens et services selon le lieu de facturation et le statut du client.

Comprendre les offres gratuites

Les offres gratuites comprennent des quotas mensuels récurrents, des essais limités dans le temps et des crédits. AWS offre aux nouveaux comptes jusqu’à 200 dollars américains de crédits. Un compte associé à son offre Free est fermé après six mois ou à l’épuisement des crédits, selon la première éventualité, sauf s’il passe à l’offre Paid. Les comptes payants sont facturés aux tarifs normaux au-delà de leurs quotas ou après l’épuisement des crédits. Définis une alerte budgétaire pour un compte de test payant même lorsque ses premières charges de travail entrent dans une offre gratuite.

Estime ensemble la quantité stockée, les opérations, la récupération, la conservation, la redondance et le transfert de données.

Chiffrer selon l’utilisation prévue des données

Les niveaux de stockage en mode objet à accès fréquent comprennent Amazon S3 Standard, Azure Blob hot et Google Cloud Storage Standard. Ils facturent le stockage plus cher que les niveaux d’accès moins fréquent et ne comportent pas de frais de récupération. Parmi les options d’accès moins fréquent figurent S3 Standard-IA et les classes Glacier, Azure cool, cold et archive, ainsi que Google Nearline, Coldline et Archive. Leur stockage moins cher s’accompagne de frais de récupération et, pour certains produits d’archivage, d’un délai de restauration de plusieurs heures.

Avec des tarifs fictifs, 10 000 Go dans un niveau standard à 0,023 € par Go-mois coûtent 230 € par mois. Un niveau d’archivage à 0,002 € coûte 20 € pour le stockage. La récupération de 2 000 Go à 0,02 € par Go ajoute 40 €, soit 60 € avant les opérations et les autres frais applicables. La récupération des 10 000 Go ajoute 200 €, ce qui porte ces deux composantes à 220 €. Des récupérations fréquentes peuvent effacer l’économie, et les délais de restauration peuvent exclure l’archivage.

Tenir compte de la conservation et de la capacité

Une durée minimale de stockage signifie qu’une suppression ou un déplacement anticipé peut entraîner des frais pour la durée restante. Google Coldline impose un minimum de 90 jours ; Azure archive impose un minimum de 180 jours. Si tu supprimes un objet après 30 jours dans un niveau avec un minimum de 90 jours, les 60 jours restants sont tout de même facturés.

Les disques en mode bloc sont généralement facturés selon leur taille provisionnée et parfois selon les performances provisionnées. Un disque de 500 Go sur lequel 50 Go sont écrits reste facturé pour 500 Go. Le stockage en mode objet facture les données stockées. Les instantanés et les sauvegardes ajoutent leurs propres frais de stockage. La redondance ajoute des copies, et une copie dans une seconde région peut ajouter des frais de stockage et de transfert.

Suivre le sens du transfert

Le transfert de données entrant désigne les données qui arrivent ; le transfert de données sortant désigne celles qui partent. Le transfert entrant depuis Internet est généralement gratuit, notamment pour les données ordinaires transférées d’Internet vers AWS. Le transfert sortant vers Internet est généralement facturé par Go, avec des tranches et des quotas. Les copies interrégionales sont également facturées, généralement comme trafic sortant de la région source.

Pour une application donnée en exemple, l’envoi de 2 000 Go aux utilisateurs sur Internet à 0,09 € par Go coûte 180 €. La réplication de 500 Go vers une autre région à 0,02 € ajoute 10 €. La réception gratuite de 300 Go de données chargées n’ajoute aucun coût. Le sous-total du transfert est de 190 €. La facture de stockage des données répliquées est distincte.

Le transfert entre zones peut également coûter de l’argent. Chez AWS, le trafic EC2 entre zones de disponibilité peut entraîner des frais des deux côtés du transfert ; les autres services ont leurs propres règles et exemptions. Le trafic sur adresses privées au sein d’une même zone est généralement gratuit. Retrace chaque chemin à travers les services utilisés et vérifie leurs pages de tarification, y compris les quotas. Inclus les transferts sortants lorsque tu prévois un passage ultérieur à un autre fournisseur.

Le tarif horaire le plus bas n’est utile que si ses conditions conviennent à la charge de travail. Compare la flexibilité, l’obligation à long terme et la capacité à tolérer une interruption avant de choisir un modèle d’achat.

Utilisation flexible ou engagement stable

La tarification à la demande ne comporte pas d’engagement à long terme : tu paies le tarif normal pour la durée utilisée. Elle convient aux charges de travail courtes, incertaines et changeantes. Un engagement réduit le tarif en échange d’une obligation d’un ou trois ans. Une durée de trois ans donne une remise plus importante qu’une durée d’un an. Les engagements sur les ressources correspondent à des caractéristiques comme le type de ressource et la région ; les engagements de dépenses couvrent l’utilisation éligible jusqu’à un montant horaire.

AWS utilise les Reserved Instances et les Savings Plans ; Azure propose les Reservations et le savings plan for compute. Google Cloud propose des remises sur utilisation engagée fondées sur les ressources ou sur les dépenses. AWS annonce des économies allant jusqu’à 72 % pour les Reserved Instances et les Savings Plans. L’économie maximale annoncée n’est pas celle de toutes les configurations.

Un engagement est payé pour chaque heure de sa durée, y compris les heures inutilisées. À 10 € par heure pendant un an, l’obligation est de 87 600 €. Si une heure ne comprend que 8 € d’utilisation éligible aux tarifs du plan, cette heure coûte tout de même 10 €. Les 2 € inutilisés ne peuvent pas être reportés sur une heure de forte activité. L’utilisation au-delà de l’engagement est facturée aux tarifs à la demande.

Calculer le seuil d’indifférence

Une machine virtuelle donnée en exemple coûte 0,20 € par heure à la demande ou 0,13 € par heure avec un engagement d’un an. L’engagement coûte 1 138,80 € pour 8 760 heures. Une utilisation à la demande toute l’année coûte 1 752 €, soit une économie de 613,20 €, ou 35 %, avec l’engagement.

Au seuil d’indifférence, les heures à la demande doivent coûter 1 138,80 € : divise par 0,20 € pour obtenir 5 694 heures. Cela représente 65 % de l’année. Au-dessus de 65 % d’utilisation, l’engagement est avantageux ; à 65 %, les totaux sont égaux. Une charge de travail utilisée uniquement les jours de semaine pendant 2 080 heures ne coûte que 416 € à la demande. Prends un engagement adapté à un niveau de base mesuré, et non au maximum brièvement atteint par une charge de travail.

Les options de paiement AWS sont All Upfront, Partial Upfront et No Upfront ; les paiements initiaux plus élevés améliorent généralement la remise. Les Azure savings plans ont le même coût total, qu’ils soient payés mensuellement ou à l’avance, et ne peuvent être ni annulés ni remboursés.

Savoir ce que garantit une réservation

Une AWS Reserved Instance est un avantage de facturation, pas un serveur physique dédié. La correspondance tient compte des caractéristiques de l’instance, de la région, du système d’exploitation et du type d’hébergement. Les réservations régionales s’appliquent dans toutes les zones ; les réservations zonales réservent aussi de la capacité dans une zone choisie. Les Standard Reserved Instances peuvent être modifiées mais pas échangées ; les Convertible Reserved Instances peuvent être échangées contre des caractéristiques différentes, avec une remise plus faible. À la fin de l’engagement, les instances en fonctionnement continuent aux tarifs à la demande.

Utiliser Spot pour les travaux qui peuvent redémarrer

Spot utilise une capacité disponible que le fournisseur peut reprendre. AWS annonce jusqu’à 90 % de réduction ; Google Cloud jusqu’à 91 %. AWS donne normalement un préavis d’interruption de deux minutes ; Azure donne, dans la mesure du possible, un préavis jusqu’à 30 secondes.

Avec des tarifs fictifs, 400 heures de calcul coûtent 80 € à la demande à 0,20 € ou 24 € en Spot à 0,06 €. Si les reprises augmentent le travail de 10 % pour atteindre 440 heures, Spot coûte 26,40 €. Les tâches par lots, le rendu, les compilations et les analyses qui peuvent redémarrer peuvent convenir à Spot ; une base de données unique qui doit rester disponible ne convient pas. Une combinaison utile comprend des engagements pour la demande stable, la tarification à la demande pour la demande variable et Spot pour les tâches qui peuvent redémarrer.

Les remises Google pour utilisation soutenue sont différentes : les types de machines éligibles, notamment N1 et N2, peuvent bénéficier automatiquement de remises après plus de 25 % d’utilisation mensuelle sans engagement, jusqu’à 20 % ou 30 % selon le type.

Trois besoins distincts peuvent justifier un choix d’achat particulier : du matériel exclusif, une capacité garantie ou des licences logicielles éligibles. Identifie d’abord le besoin, puis compare le coût de l’option qui y répond.

Partager un serveur ou contrôler un hôte

Dans un hébergement mutualisé, les machines virtuelles de différents clients occupent le même serveur physique et sont isolées par l’hyperviseur. C’est le choix économique standard pour de nombreuses charges de travail. Les AWS Dedicated Instances fonctionnent sur du matériel utilisé par un seul client, mais ne lui permettent pas de choisir leur placement sur l’hôte ni de voir le serveur physique.

Un hôte dédié fournit un serveur entier et une visibilité sur ses sockets et ses cœurs. AWS Dedicated Hosts, Azure Dedicated Host et Google Cloud sole-tenant nodes répondent à ce besoin. Les clients peuvent contrôler le placement des machines virtuelles sur cet hôte. Les exigences de conformité imposant un hébergement réservé à un seul client et les licences liées aux cœurs ou aux sockets physiques peuvent rendre cette option utile.

L’hôte entier est facturé même lorsqu’il est partiellement vide. À un tarif fictif de 5 € par heure, un hôte coûte 3 650 € pour un mois de 730 heures. S’il accueille 12 machines virtuelles, le coût horaire de l’hôte est en moyenne d’environ 0,42 € par machine virtuelle lorsqu’il est plein. Avec seulement quatre machines virtuelles, il est en moyenne de 1,25 €. La même facture d’hébergement est alors répartie entre moins de machines utiles. Compare le taux d’occupation prévu ainsi que le tarif annoncé de l’hôte.

La réservation de capacité est un achat distinct

Une réservation de capacité met de côté une capacité de calcul correspondante afin qu’elle soit disponible au moment voulu. AWS et Azure proposent des réservations de capacité zonales à la demande. Les réservations Google Cloud sont également zonales, avec un périmètre de consommation qui dépend de la réservation et du service. Précise les caractéristiques et le lieu requis pour la machine.

Une réservation de capacité entraîne des frais pour la capacité réservée même lorsqu’elle n’est pas utilisée. Elle ne crée pas de remise à elle seule ; un avantage compatible lié à un engagement peut réduire la facture. Elle ne rend pas non plus l’hôte physique exclusif à un client. Pour un événement prévu ou un site de reprise, demande-toi séparément si la capacité doit être disponible et si un tarif réduit sur engagement vaut la peine.

Cette distinction explique aussi la terminologie AWS. Une Reserved Instance régionale fournit une remise de facturation. Une Reserved Instance zonale combine une remise de facturation et une réservation de capacité. Un hôte dédié répond à la question du type d’hébergement. Des noms similaires ne rendent pas ces options interchangeables.

Vérifier l’éligibilité des logiciels

Les images avec licence incluse intègrent la licence logicielle au tarif cloud. L’apport de licences existantes utilise des licences éligibles déjà détenues par le client. L’éligibilité dépend des conditions du logiciel ; posséder une licence ne donne pas à elle seule le droit de l’utiliser sur n’importe quel serveur cloud.

Azure Hybrid Benefit prend en charge les licences Windows Server et SQL Server éligibles avec Software Assurance ou des abonnements admissibles. AWS License Manager aide à suivre l’utilisation des licences. Certaines licences exigent un hôte physique identifié, ce qui peut faire de l’hébergement dédié un élément du choix de licence.

Supposons qu’une équipe cherche un prix plus bas pour un service fonctionnant en continu, sans règle imposant un hébergement réservé à un seul client. Un engagement sur un hébergement mutualisé répond à son objectif de prix. Si l’équipe a plutôt besoin d’une capacité garantie dans une zone pour un lancement, elle ajoute une réservation de capacité. Si une licence doit être liée à des cœurs physiques, elle évalue un hôte dédié et son taux d’occupation. Le prix, la disponibilité et le type d’hébergement sont des caractéristiques distinctes à choisir délibérément.

Le coût total de possession additionne les coûts de possession et d’exploitation d’un système sur une période choisie, souvent de trois à cinq ans. Il permet une comparaison plus équitable que la mise en regard d’une facture cloud et d’un prix d’achat de matériel. Les deux options doivent fournir le même service requis sur la même période.

Séparer les coûts d’achat des coûts d’exploitation

Les dépenses d’investissement achètent des actifs comme des serveurs et des bâtiments, utilisés et amortis sur plusieurs années. Les dépenses d’exploitation paient les services courants et les frais de fonctionnement. Le cloud transforme une grande partie des achats initiaux de matériel en frais de service récurrents.

Un centre de données en propre entraîne de nombreux coûts fixes même lorsqu’il est peu utilisé. Les frais d’utilisation du cloud peuvent augmenter ou diminuer, mais les engagements et les ressources provisionnées créent toujours des obligations. Un changement de type de dépense influe sur les flux de trésorerie et la flexibilité ; son coût total doit tout de même être calculé.

Pour les systèmes sur site, inclus le matériel, les licences, l’espace, l’électricité, le refroidissement, la maintenance, la sécurité physique, le temps du personnel, les renouvellements, la capacité de pointe et la reprise après sinistre. Pour le cloud, inclus le calcul, le stockage, le transfert, les services managés, le support, le temps du personnel, la formation et la migration. Pendant une migration, l’organisation peut payer les deux environnements en même temps.

Le temps du personnel est un élément à estimer à partir des responsabilités réelles. Un fournisseur cloud gère le matériel physique, mais le client continue de gérer les configurations, les données, les décisions de sécurité et les systèmes d’exploitation des machines virtuelles. Évalue le travail et les compétences nécessaires au lieu de supposer que les coûts de personnel disparaissent.

Construire une comparaison étape par étape

1. Fixe le périmètre du service et la période de comparaison.
2. Répertorie les serveurs et le stockage existants ainsi que leur utilisation mesurée.
3. Additionne les coûts d’achat et d’exploitation sur site.
4. Dimensionne le système cloud selon la demande observée et chiffre ses composants.
5. Ajoute la migration, la formation et toute période de chevauchement.
6. Compare les totaux, puis teste les hypothèses de croissance et de dimensionnement.

Prenons un exemple sur trois ans. Sur site, le matériel coûte 60 000 €. Les coûts annuels sont de 9 000 € pour l’électricité et le refroidissement, 6 000 € pour l’espace, 40 000 € pour le personnel, 10 000 € pour les licences et 5 000 € pour la maintenance. Ces coûts annuels totalisent 70 000 €. Trois ans coûtent 60 000 € plus 210 000 €, soit 270 000 €.

L’option cloud comprend 3 500 € par mois pour le calcul et le stockage, 300 € pour le transfert et 350 € pour le support. Les 4 150 € mensuels deviennent 149 400 € sur 36 mois. Ajoute 60 000 € pour trois ans de temps de personnel et 25 000 € de migration : 234 400 €. La différence est de 35 600 €, soit environ 13 % du total sur site.

Tester ce qui pourrait modifier le résultat

Une configuration cloud plus importante, une croissance plus rapide ou davantage de transferts sortants peuvent réduire cette économie. Un engagement peut réduire les tarifs mais ajoute une obligation. Copier dans le cloud la capacité de pointe achetée peut surestimer les besoins ; l’utilisation mesurée permet de redimensionner l’estimation de façon optimale.

AWS Migration Evaluator, l’analyse de rentabilité d’Azure Migrate et Google Cloud Migration Center aident à inventorier les systèmes et à comparer les coûts. Leurs résultats dépendent de l’inventaire et des hypothèses saisis. Indique les avantages difficiles à chiffrer, comme une livraison plus rapide, la couverture mondiale, l’élasticité et la résilience, à côté du calcul financier. Les économies d’échelle aident les fournisseurs à réduire leurs coûts, mais une charge de travail stable réhébergée sans modification et facturée à la demande peut tout de même coûter autant ou plus cher que son équivalent sur site.

Un calculateur de prix transforme une configuration cloud prévue en frais estimés. AWS, Azure et Google Cloud proposent des calculateurs web gratuits. Saisis tous les composants et une utilisation réaliste avant de comparer les conceptions.

Répertorier chaque composant

Commence par l’architecture : machines virtuelles de l’application, base de données, disques, données en mode objet, requêtes, sauvegardes et chemins de transfert. Inclus les environnements de développement et de test, pas seulement la production. Choisis une région, un système d’exploitation, des tailles de ressources, des heures de fonctionnement et un modèle de tarification pour chaque service. Ajoute séparément l’offre de support si elle n’est pas déjà incluse.

Utilise la même base de temps partout. Pour l’estimation d’un mois de fonctionnement continu, utilise 730 heures. Un système de test utilisé en semaine nécessite son horaire réel, tandis que les disques conservés peuvent nécessiter un mois entier de stockage. Convertis le nombre brut de requêtes en millions avant d’appliquer un tarif par million.

Additionner les lignes

Pour une petite application web, utilise ces tarifs fictifs et quantités mensuelles :

Le total de ces quatre éléments est de 325,26 € par mois, soit 3 903,12 € par an. Ajoute à ce sous-total les sauvegardes, le support et les autres services nécessaires.

Si un engagement d’un an réduit uniquement le tarif des machines virtuelles de 35 %, leur ligne devient 140,16 € multipliés par 0,65, soit 91,104 € avant arrondissement. Ajoute la base de données, le stockage et le transfert sortant inchangés pour obtenir 276,204 €, présentés comme 276,20 € par mois. Appliquer 35 % à toute l’estimation réduirait à tort le prix des services exclus de cette offre pour machines virtuelles.

Consigner ce que signifie l’estimation

Examine ensemble les frais mensuels, les paiements initiaux et les totaux annuels. Une offre payée intégralement à l’avance peut afficher une petite facture récurrente tout en exigeant une somme au départ. Consigne la date, la région, la configuration, les heures, les transferts, la durée de l’engagement et la base de prix. Les estimations publiques utilisent les tarifs catalogue ; certains calculateurs peuvent utiliser des prix négociés. Le calculateur de Google peut utiliser les prix contractuels lorsqu’il est lié à un compte de facturation éligible.

AWS Pricing Calculator exclut les taxes. Les listes de prix et les API, comme AWS Price List API et Azure Retail Prices API, fournissent des tarifs aux outils et aux scripts ; les tarifs peuvent changer après l’enregistrement d’une estimation.

Regroupe l’estimation par charge de travail, enregistre un lien partageable et exporte-la pour examen. AWS prend en charge les exportations CSV et PDF. Après le déploiement, compare chaque ligne principale au rapport de coûts. Examine les écarts entre les heures, le stockage et les transferts réels et les quantités enregistrées.

Une entité de facturation centrale peut payer les comptes, abonnements ou projets distincts de plusieurs équipes. Suis à la fois le payeur et le responsable de la ressource.

Trouver l’entité qui paie

Chez AWS, une organisation dans AWS Organizations possède un compte de gestion qui paie pour ses comptes membres grâce à la facturation consolidée. Sur Azure, les abonnements relèvent d’un compte de facturation ; dans le cadre d’un Microsoft Customer Agreement, les profils de facturation et les sections de facture organisent le paiement. Sur Google Cloud, chaque projet est lié à un compte Cloud Billing qui paie ses frais.

Une facture couvre normalement un mois civil. Ses regroupements par service, type d’utilisation, région et compte ou projet expliquent les frais. Les crédits, remboursements et taxes influent sur le montant dû. Les lignes détaillées relient une quantité mesurée à un tarif et, lorsqu’elle est disponible, à une ressource.

Cumuler l’utilisation éligible pour la tarification au volume

La facturation consolidée AWS ne comporte pas de frais supplémentaires et cumule l’utilisation éligible pour les tranches de volume. Prenons des tarifs fictifs de stockage : 0,023 € par Go-mois pour les 50 000 premiers Go et 0,022 € au-delà. Trois comptes stockent chacun 20 000 Go pendant un mois.

Facturé séparément, chacun paie 460 € et le total cumulé est de 1 380 €. L’utilisation consolidée est de 60 000 Go : les 50 000 premiers coûtent 1 150 € et les 10 000 restants coûtent 220 €. Le total consolidé est de 1 370 €.

Seule la quantité au-dessus de la borne de la tranche bénéficie du tarif inférieur. Facturer les 60 000 Go à 0,022 € donnerait 1 320 € et étendrait à tort le tarif inférieur à l’utilisation des tranches précédentes.

Suivre les avantages partagés des engagements

Les avantages des instances réservées et des Savings Plans peuvent aussi être partagés entre comptes éligibles. Si le compte A possède une instance réservée mais n’a aucune utilisation correspondante pendant une heure, l’instance correspondante en fonctionnement du compte B peut bénéficier de l’avantage. Le compte de gestion peut désactiver le partage pour certains comptes.

La facture affichée d’un compte membre est donc une vue informative des frais et des avantages répartis. Applique la règle centrale de répartition lorsqu’une autre équipe consomme l’avantage acheté.

Des comptes, abonnements ou projets distincts rendent les responsabilités visibles, car les frais appartiennent déjà à ces périmètres. Les balises permettent d’affiner la répartition des coûts au sein de chacun, par exemple par application ou par environnement.

L’accès à la facturation nécessite toujours une permission. Donne aux personnes qui consultent les coûts la possibilité d’examiner les rapports sans leur accorder aussi le droit de modifier les coordonnées de paiement ou de souscrire des engagements. Sépare la consultation des coûts, les modifications de paiement et la souscription d’engagements à l’aide de permissions respectant le principe du moindre privilège.

Utilise les rapports de coûts pour trouver le service, la ressource et le responsable à l’origine d’un changement de dépenses.

Choisir une vue utile

AWS Cost Explorer, l’analyse des coûts dans Microsoft Cost Management et les rapports Google Cloud Billing affichent les dépenses dans le temps. Filtre et regroupe-les par service, compte ou projet, région, type d’utilisation et balises. Les prévisions estiment les coûts futurs à partir des profils d’utilisation passés.

Pour une analyse détaillée, exporte les données de facturation. Les données AWS Cost and Usage Report peuvent être envoyées vers S3 via AWS Data Exports, les exportations Azure Cost Management écrivent dans un compte de stockage et les exportations de facturation Google Cloud vont vers BigQuery. Ces jeux de données permettent aux analystes d’interroger les identifiants de ressources, les quantités et les balises ou de créer leurs propres tableaux de bord.

Séparer le moment du paiement du coût dans le temps

Une vue des coûts réels affiche les frais pendant la période de facturation. Une vue des coûts amortis répartit les frais initiaux d’un engagement sur sa durée. Si un engagement d’un an coûte 8 760 € à l’avance, le mois d’achat affiche 8 760 € dans une vue des coûts réels. Une vue mensuelle simple des coûts amortis le répartit à environ 730 € par mois.

Utilise les coûts réels pour suivre le moment des paiements et les coûts amortis pour comparer les périodes ; un achat initial n’est pas une hausse soudaine de l’utilisation.

Examiner le changement le plus important

Supposons que la facture passe de 10 000 € à 12 000 €. La hausse de 2 000 € représente 20 % du mois précédent. Le regroupement par service révèle :

Le transfert explique 1 900 € de la hausse nette de 2 000 €, soit 95 %. Commence par là : regroupe les transferts par région, puis par compte ou balise, puis examine la ressource et le type d’utilisation. Une hausse sur un chemin de réplication appelle une réponse différente d’une hausse des téléchargements par les clients. Une fois la cause trouvée, désigne un responsable et définis une action.

Tenir compte des délais et des changements masqués

Les rapports de facturation suivent l’activité des ressources avec un décalage. Les données budgétaires AWS sont mises à jour jusqu’à trois fois par jour ; les données de coûts Azure arrivent généralement sous 8 à 24 heures. Une nouvelle charge de travail peut entraîner des dépenses avant que son coût n’apparaisse. Compare des périodes et des vues de coûts équivalentes lorsque tu vérifies une alerte.

Les outils de détection des anomalies repèrent les profils de dépenses inhabituels. AWS Cost Anomaly Detection, les alertes d’anomalie de Microsoft Cost Management et la détection des anomalies Google Cloud peuvent repérer un cluster oublié ou une hausse soudaine des transferts. Des services de recommandation comme AWS Trusted Advisor, Azure Advisor et Google Cloud Recommender suggèrent des économies à examiner.

Un total stable peut masquer une hausse des coûts de base de données compensée par une baisse des coûts des machines virtuelles. Compare les changements par service ainsi que les groupes par compte et par balise pour identifier à la fois l’utilisation et les responsabilités.

Un budget fixe un montant prévu pour une période et un périmètre. Les alertes comparent les coûts ou l’utilisation à ce montant. Elles aident quelqu’un à réagir avant la facture finale : leur périmètre, leurs seuils et leur destinataire sont donc aussi importants que leur montant.

Définir le périmètre et l’objectif

AWS Budgets, les budgets Microsoft Cost Management et les budgets Google Cloud Billing peuvent suivre un compte ou un périmètre plus restreint. Par exemple, un abonnement ou un groupe de ressources Azure, un projet Google ou un filtre par service ou par balise. Azure prend en charge les réinitialisations mensuelles, trimestrielles et annuelles ; AWS prend aussi en charge des périodes personnalisées comme la durée d’un projet.

AWS propose des budgets de coûts et d’utilisation ainsi que des budgets de taux d’utilisation et de couverture pour les instances réservées et les Savings Plans. Le taux d’utilisation indique quelle part de l’engagement acheté est utilisée. La couverture indique quelle part de l’utilisation éligible bénéficie d’un engagement. Une équipe peut avoir un taux d’utilisation élevé mais une faible couverture si un petit engagement est entièrement utilisé par une charge de travail bien plus importante.

Utiliser des seuils réels et prévisionnels

Une alerte sur les coûts réels compare les dépenses engagées jusque-là à un seuil. Une alerte sur les coûts prévisionnels compare les dépenses attendues sur toute la période à un seuil. Les seuils par défaut suggérés par Google comprennent 50 %, 90 % et 100 % ; choisis des niveaux qui laissent au responsable le temps de réagir.

Pour un budget mensuel de 5 000 €, un seuil sur les coûts réels de 80 % représente 4 000 €. Au 12e jour d’un mois de 30 jours, les dépenses sont de 2 400 €. Cela représente 48 % du budget : le seuil réel n’est donc pas atteint. Au rythme actuel de 200 € par jour, une prévision simple atteint 6 000 €, soit 120 % du budget. Un seuil prévisionnel de 100 % avertit dès maintenant.

Le budget restant est de 2 600 € pour 18 jours. La division donne environ 144,44 € par jour. C’est le rythme moyen restant nécessaire pour respecter le budget prévu ; réduire le rythme futur ne supprime pas les frais déjà engagés.

Décider de ce qui se passe après l’alerte

Un budget ordinaire émet une alerte ; il n’arrête pas les dépenses par défaut. Les notifications budgétaires Azure n’affectent pas les ressources. Les budgets Google qui ne font qu’alerter ne plafonnent pas la consommation. Les données de facturation arrivent avec un délai : les coûts peuvent donc franchir un seuil avant que la notification parvienne à quelqu’un.

L’automatisation nécessite une configuration. Les actions budgétaires AWS peuvent appliquer des politiques IAM ou de contrôle des services, ou arrêter des instances EC2 et RDS. Les groupes d’actions Azure peuvent invoquer Functions, Logic Apps ou des webhooks. Les notifications Google Pub/Sub peuvent déclencher une automatisation ; Google propose aussi des budgets avec plafond de dépenses configurés séparément qui suspendent les services pris en charge dans un projet.

Choisis l’action en tenant compte des besoins de disponibilité de la charge de travail. Arrêter automatiquement un système de test peut être acceptable ; arrêter la seule base de données de production peut provoquer une panne coûteuse. Teste le périmètre et les permissions d’une action automatisée avant de t’y fier.

Désigner un responsable du budget

Les notifications peuvent être envoyées par e-mail, vers des rubriques AWS SNS et des applications de messagerie, des groupes d’actions Azure et l’application mobile, ou des canaux Google Pub/Sub et Cloud Monitoring. Désigne la personne ou l’équipe chargée d’examiner les alertes et définis comment les alertes urgentes sont traitées. Une boîte de réception partagée n’est utile que si quelqu’un est chargé d’y répondre. Lors des analyses régulières, vérifie que le périmètre correspond toujours à la charge de travail et que les destinataires ont toujours le pouvoir d’agir.

Une balise est un libellé clé-valeur sur une ressource, comme « Environment = Production » ou « CostCenter = 4410 ». Les balises relient les ressources techniques aux personnes et aux objectifs métier à l’origine de leurs coûts. AWS et Azure utilisent des balises à cette fin ; Google Cloud utilise des libellés pour ventiler la facturation et des balises distinctes principalement pour appliquer des politiques sous condition.

Définir une norme commune

Les clés utiles comprennent CostCenter, Owner, Environment, Project et Application. Définis les noms et les valeurs autorisés, puis applique-les lors de la création des ressources. « Environment = Production » et « environment = prod » peuvent diviser en deux un groupe qui devait être unique. Les clés et les valeurs des balises AWS sont sensibles à la casse. Les noms des balises Azure ne sont pas sensibles à la casse pour les opérations, mais leurs valeurs le sont.

La séparation des comptes donne un périmètre général de responsabilité ; les balises ajoutent des détails à l’intérieur de celui-ci. Un compte partagé peut contenir des ressources portant « Application = Orders » et « Application = Search », ce qui permet à un rapport de coûts de distinguer ces applications sans les déplacer.

Rendre les libellés utilisables pour la facturation

Chez AWS, un compte de gestion ou un compte autonome doit activer les balises comme balises de répartition des coûts dans Billing and Cost Management. Les balises définies par l’utilisateur coexistent avec les balises générées par AWS portant le préfixe « aws: », comme « aws:createdBy ». Leur activation et leur disponibilité peuvent prendre du temps, notamment jusqu’à 24 heures avant leur apparition. Une application rétroactive demandée peut appliquer les balises à 12 mois maximum de données de coûts antérieures pour les ressources qui les portaient déjà.

Les ressources Azure n’héritent pas par défaut des balises de leur groupe de ressources ou de leur abonnement. Azure Policy peut ajouter des balises aux ressources ou les leur faire hériter. L’héritage des balises dans Cost Management applique les balises des niveaux supérieurs aux enregistrements d’utilisation ; cette fonction de rapport est distincte de l’écriture des balises sur les ressources elles-mêmes. Azure autorise jusqu’à 50 balises par ressource, groupe de ressources ou abonnement.

Répartir explicitement les coûts partagés et manquants

Tous les types de ressources ne prennent pas en charge les balises, et les frais de support, les taxes et certains frais de transfert peuvent ne pas avoir de balise de ressource. Conserve une catégorie non attribuée et conviens d’une méthode pour répartir les coûts réellement partagés.

Supposons que les frais de ressources totalisent 5 000 € : l’Équipe A représente 3 000 €, l’Équipe B 1 500 €, et 500 € ne sont pas balisés. Les coûts balisés totalisent 4 500 €. Des frais de support distincts de 400 € sont répartis au prorata des coûts balisés. L’Équipe A reçoit une part des frais égale à 3 000 € divisés par 4 500 €, soit 266,67 €. L’Équipe B reçoit 133,33 €. La facture complète est de 5 400 €, et les 500 € non balisés restent à traiter par les responsables. Ne les répartis pas silencieusement comme si leur responsable était connu.

La restitution des coûts informe une équipe de ses coûts. La refacturation interne impute ces coûts à son budget interne. Les deux nécessitent des responsables de ressources fiables et une méthode de répartition qui explique les frais partagés.

Garder des balises exactes et sûres

Applique la norme par l’infrastructure en tant que code et les processus de création de ressources. Les politiques de balisage AWS normalisent les clés et les valeurs de balises prises en charge ; utilise des contrôles supplémentaires pour détecter ou empêcher les balises manquantes. Azure Policy peut exiger une balise, ajouter une valeur ou refuser une création non conforme. Suis le taux de couverture des balises comme part des coûts concernés portant les balises requises, et examine les cas où elles manquent.

Les balises apparaissent en texte clair dans les rapports, les journaux et les exportations. N’y place pas de mots de passe, de données personnelles ou d’autres valeurs sensibles. Une balise seule est une métadonnée ; les règles d’accès nécessitent une politique distincte qui l’utilise.

La gouvernance du cloud combine des règles, des processus et des contrôles. Un contrôle préventif bloque une action indésirable, un contrôle de détection signale un problème et un contrôle correctif y remédie. Associe le contrôle à l’exigence réelle : qui peut agir, quel état de ressource est autorisé ou ce qui doit résister à une modification accidentelle.

Appliquer les règles de ressources Azure

Le contrôle d’accès fondé sur les rôles Azure détermine qui peut effectuer des actions. Azure Policy vérifie les propriétés des ressources, quelle que soit la personne qui envoie la demande. Un Contributor peut avoir la permission de créer des machines virtuelles, mais une stratégie Allowed locations peut tout de même refuser une région non approuvée.

Une définition de stratégie contient une règle et un effet. Une initiative regroupe des définitions. Une affectation applique l’une d’elles à un groupe d’administration, un abonnement, un groupe de ressources ou une ressource ; les étendues inférieures en héritent, avec des exclusions lorsqu’elles sont configurées.

L’effet détermine la réponse. audit consigne la non-conformité ; deny bloque une modification non conforme. modify et append peuvent modifier une demande, par exemple en ajoutant une balise. auditIfNotExists vérifie les ressources associées et deployIfNotExists peut les déployer. denyAction bloque les actions précisées comme la suppression ; disabled désactive l’évaluation. Les ressources existantes peuvent nécessiter des tâches de correction. Les évaluations ont lieu lors des changements concernés et lors d’analyses normalement exécutées toutes les 24 heures. Commence par audit lorsque tu dois comprendre l’impact d’une affectation avant d’appliquer deny.

Protéger les ressources contre les modifications accidentelles

Les verrous Azure s’appliquent à l’étendue d’un abonnement, d’un groupe de ressources ou d’une ressource et sont transmis par héritage. CanNotDelete, affiché sous le nom Delete dans le portail, autorise la lecture et la modification mais bloque la suppression. ReadOnly autorise uniquement la lecture et peut bloquer des opérations d’administration inattendues, notamment le démarrage d’une machine virtuelle ou le listage des clés de stockage.

Seuls les rôles disposant des permissions relatives aux verrous, comme Owner ou User Access Administrator, peuvent gérer les verrous. Un verrou peut bloquer une action par ailleurs autorisée, mais une personne autorisée à le supprimer peut retirer cette protection. Les verrous protègent les opérations d’administration, pas les données stockées : un verrou sur un compte de stockage n’empêche pas la suppression de blobs par le plan de données. Une ressource verrouillée peut empêcher la suppression de tout son groupe de ressources.

Utiliser les garde-fous organisationnels correspondants

Les politiques de contrôle des services AWS fixent les permissions maximales des utilisateurs et des rôles IAM dans les comptes membres, y compris les utilisateurs racine de ces comptes. Elles n’accordent elles-mêmes aucune permission et ne limitent pas le compte de gestion. Une politique de contrôle des services peut refuser les actions hors des régions approuvées. Les règles AWS Config détectent les non-conformités des ressources ; Control Tower aide à établir les comptes et les contrôles. Les politiques de balisage normalisent les valeurs de balises prises en charge, mais une règle sur les balises manquantes nécessite un mécanisme adapté supplémentaire pour la faire respecter.

Google Cloud Organization Policy Service applique des contraintes à l’étendue d’une organisation, d’un dossier ou d’un projet, transmises par héritage dans la hiérarchie. Les trois fournisseurs utilisent des quotas pour limiter des quantités comme les vCPU. Un quota limite la quantité de ressources, pas la facture totale de tous les services.

Pour « des régions de l’UE approuvées, une balise CostCenter et une protection contre la suppression de la base de données », Azure nécessite des stratégies de région et de balisage ainsi qu’un verrou CanNotDelete. AWS combine des politiques de contrôle des services régionales, des normes et contrôles de balisage et une protection contre la suppression de la base de données. Google combine des contraintes sur les lieux des ressources, des vérifications des libellés et une protection contre la suppression.

Microsoft Purview a une autre fonction : découvrir, classer, cataloguer et protéger les données dans différents environnements et faciliter la conformité. Restreins les tailles de machines virtuelles et les régions à l’aide d’une stratégie de gestion des ressources, pas d’un catalogue de données.

Une personne disposant de permissions cloud peut créer une ressource facturable en quelques minutes. La gouvernance financière nécessite donc une pratique continue : afficher les coûts, attribuer les responsabilités, agir sur les changements et vérifier que les contrôles restent adaptés à l’entreprise.

Relier les personnes, les processus et la technologie

FinOps réunit les équipes financières, techniques et métier pour prendre des décisions éclairées sur les dépenses. Les ingénieurs comprennent les systèmes et peuvent modifier leur utilisation. Les équipes financières définissent les budgets et les prévisions. Les dirigeants métier décident de l’équilibre entre les coûts, la rapidité, la fiabilité et la qualité.

Attribue à chaque compte, abonnement ou projet un responsable des coûts désigné. Une équipe FinOps centrale ou un centre d’excellence cloud définit des normes communes, prépare les rapports et coordonne les engagements pour le niveau de base partagé. Elle soutient les décisions des équipes techniques au lieu de faire à leur place tous leurs choix quotidiens de ressources.

Les outils soutiennent ce travail : structures de comptes, balises, rapports de coûts, budgets, alertes d’anomalie, politiques, quotas et recommandations. Un tableau de bord sans responsable ne décide pas quoi faire ; une alerte sans processus de réponse peut rester non lue.

Répéter les phases FinOps

Le cadre FinOps nomme trois phases qui se répètent :

• Informer : rendre les dépenses visibles et les attribuer aux responsables.
• Optimiser : améliorer l’utilisation et les tarifs tout en respectant les exigences.
• Exploiter : définir des objectifs et des politiques, agir selon des processus convenus et améliorer la pratique.

Elles forment un cycle, pas un projet ponctuel. Une analyse mensuelle peut comparer les coûts réels aux prévisions, examiner les changements par équipe, vérifier le taux de couverture des balises et examiner les engagements inutilisés. Entre les analyses, un processus de gestion des anomalies traite les changements urgents. Un processus de souscription d’engagements doit identifier qui peut approuver l’obligation et sur quel niveau de base elle repose.

La hiérarchie des ressources Google, organisation, dossiers, projets et ressources, aide à associer les responsabilités aux politiques d’accès et d’organisation transmises par héritage. La visibilité des coûts, les périmètres de permissions et l’audit doivent correspondre à cette structure afin que le responsable d’un projet puisse examiner ses dépenses.

Relier le coût au résultat utile

L’économie unitaire divise le coût par une unité de résultat de l’activité, comme les commandes traitées. À 12 000 € pour 400 000 commandes, le coût est de 0,03 € par commande. À 15 000 € pour 600 000 commandes, il descend à 0,025 € par commande.

La facture a augmenté de 25 %, tandis que les commandes ont augmenté de 50 %. Une facture plus élevée peut donc s’accompagner d’une amélioration du coût par unité. Vérifie à la fois le total et la mesure unitaire : le total compte pour le budget, tandis que la mesure unitaire explique l’efficacité lorsque le résultat de l’activité change. Un coût unitaire plus bas peut coexister avec des ressources inutilisées ; continue donc d’examiner les coûts au niveau des ressources.

Aller jusqu’au bout après un incident

Supposons qu’une anomalie hebdomadaire révèle une hausse de 40 %. L’alerte parvient au responsable du compte, qui regroupe le rapport par balise et trouve un cluster de test laissé à pleine capacité. L’équipe arrête le travail inutile, confirme l’effet dans les données de coûts ultérieures et ajoute une date de fin aux demandes de ressources de test. Lors de l’analyse suivante, elle met à jour la norme et vérifie si des ressources similaires existent.

Cette séquence donne une fonction à chaque outil : l’alerte détecte, le rapport explique, le responsable agit et le processus réduit les récidives. Avant de réduire un coût, vérifie son effet sur la sécurité, les performances et la fiabilité. La gouvernance financière vise à obtenir des résultats utiles pour l’entreprise à partir des dépenses cloud, en rendant les compromis visibles aux responsables.

Une offre de support donne accès à une aide selon des conditions définies. Choisis-la selon l’impact de la charge de travail et la première réponse nécessaire, puis calcule les frais. Un délai cible de réponse indique quand l’aide commence, pas quand l’application sera réparée.

Comparer les niveaux de support

Les offres Basic incluent une aide pour les comptes et la facturation, de la documentation et l’accès à la communauté. Les offres payantes ajoutent la prise en charge de demandes techniques et des réponses plus rapides pour les incidents graves. Les niveaux supérieurs peuvent ajouter des conseils d’architecture et un responsable technique de compte, ou TAM, qui fournit des conseils continus. Ouvre les demandes dans la console du fournisseur, comme AWS Support Center ou Azure Help + support.

En octobre 2026, AWS recommande Business Support+ comme offre minimale pour la production. Elle comprend un support technique 24 h/7 j par téléphone, messagerie et e-mail, l’ensemble des contrôles Trusted Advisor et un délai cible de réponse inférieur à 30 minutes lorsqu’un système critique pour l’activité est indisponible. Enterprise Support ajoute un TAM désigné et des évaluations Well-Architected, avec un délai cible inférieur à 15 minutes pour ce niveau de gravité. Unified Operations ajoute des ingénieurs en gestion des incidents avec un délai cible inférieur à cinq minutes, des spécialistes et une surveillance des charges de travail 24 h/7 j.

AWS met fin aux anciennes offres Developer, Business et Enterprise On-Ramp le 1er janvier 2027 dans les régions commerciales. Les utilisateurs Developer et Business peuvent passer à Business Support+ ; les utilisateurs Enterprise On-Ramp passent à Enterprise Support.

Appliquer les tranches et le minimum

Business Support+ coûte le montant le plus élevé entre 29 dollars américains par mois et par compte et des pourcentages par tranches des frais AWS mensuels : 9 % des 10 000 premiers dollars américains, 7 % de 10 000 à 80 000, 5 % de 80 000 à 250 000 et 3 % au-delà de 250 000.

Pour 20 000 dollars américains de frais, la première tranche représente 900 dollars américains et la suivante 700, soit 1 600 dollars américains au total. N’applique pas 7 % à l’ensemble des 20 000 dollars américains : les dépenses précédentes conservent le tarif de leur tranche. Pour 200 dollars américains de frais, 9 % donnent 18 dollars américains : le minimum de 29 dollars américains s’applique donc.

Enterprise Support utilise un minimum de 5 000 dollars américains ou 10 % des 150 000 premiers dollars américains, 7 % jusqu’à 500 000, 5 % jusqu’à 1 million et 3 % au-delà. Pour 100 000 dollars américains, les frais sont de 10 000 dollars américains. Unified Operations commence à 50 000 dollars américains par mois. Compare le minimum au total calculé après avoir appliqué toutes les tranches concernées.

Adapter l’offre au besoin

Azure Basic inclut une aide pour la facturation et les abonnements. Developer coûte 29 dollars américains par mois pour une utilisation hors production, avec une réponse aux cas à impact minimal sous huit heures ouvrées. Standard coûte 100 dollars américains pour la production, avec une réponse aux cas critiques sous une heure. Professional Direct coûte 1 000 dollars américains pour les usages critiques pour l’activité, avec une réponse aux cas critiques sous une heure et aux cas d’impact modéré sous deux heures. Unified Enterprise propose une tarification personnalisée, une réponse sous 15 minutes en cas d’arrêt d’un système Azure et un support pour d’autres produits Microsoft.

Google Cloud Customer Care propose les niveaux Basic, Standard, Enhanced et Premium. Les niveaux payants améliorent les délais cibles de réponse ; Premium ajoute un TAM.

Une boutique en ligne en production qui a besoin d’une aide technique permanente sans responsable de compte désigné peut choisir AWS Business Support+ ou Azure Standard. L’exigence d’un TAM modifie la comparaison. Vérifie ensemble la gravité, les heures de couverture, le délai cible de première réponse, les conseils inclus et le prix. Le support aide l’équipe du client ; le client continue d’exploiter son application.

Un fournisseur propose plusieurs types d’aide parce que les problèmes nécessitent des réponses différentes. Commence par nommer la tâche : apprendre à effectuer une configuration, examiner un incident, analyser les coûts, acheter un logiciel ou planifier une migration.

Apprendre et concevoir

La documentation officielle explique les fonctionnalités et leur configuration. AWS propose en plus des livres blancs, des blogs, Prescriptive Guidance pour les stratégies et les modèles, ainsi que le Knowledge Center pour les questions courantes. Microsoft Learn et Azure Architecture Center fournissent des références comparables. La documentation Google Cloud et Architecture Center expliquent les services Google et les modèles de conception.

Les communautés permettent de poser des questions et d’y répondre : AWS re:Post, Microsoft Q&A et les communautés Azure, ainsi que Google Cloud Community. Elles peuvent aider pour une question de conception ou un partage d’expérience. Pour un incident urgent en production nécessitant un délai cible de réponse, ouvre une demande technique dans le cadre de l’offre de support adaptée.

Les architectes de solutions AWS conseillent sur la conception des charges de travail, tandis qu’AWS Professional Services aide à réaliser des projets de conseil de plus grande ampleur. Les partenaires peuvent concevoir, migrer et exploiter des environnements. Les éditeurs de logiciels indépendants vendent des logiciels ; les intégrateurs de systèmes et les partenaires de conseil relient les systèmes et aident à leur mise en œuvre. Les programmes de partenariat des fournisseurs proposent des formations, des certifications, des événements et des avantages commerciaux.

Examiner l’état des services et les recommandations

Les tableaux de bord de l’état des services signalent les événements côté fournisseur. AWS Health affiche l’état public des services et les événements qui affectent ton compte ; AWS Health API permet aux automatisations d’exploiter ces événements. Azure Service Health présente les problèmes, les maintenances et les avis concernant les abonnements. Les services d’état de Google Cloud fournissent des informations sur l’état des services et, lorsqu’elles sont disponibles, des informations personnalisées sur les incidents.

Une page d’état publique normale peut coexister avec un événement qui affecte un compte ou une ressource précise. Lors de l’examen d’une panne, consulte la vue du compte ou de l’abonnement et compare-la à la surveillance propre à l’application. L’absence d’événement répertorié invite à poursuivre l’examen de l’application, pas à ignorer ses symptômes.

Les outils de conseil examinent les configurations et l’utilisation. AWS Trusted Advisor contrôle les coûts, la sécurité, la tolérance aux pannes, les performances, les limites des services et l’excellence opérationnelle. Basic inclut les contrôles essentiels ; les offres payantes incluent l’ensemble des contrôles. Azure Advisor couvre la fiabilité, la sécurité, les performances, les coûts et l’excellence opérationnelle, avec un score Advisor. Google Cloud Recommender, qui fait partie d’Active Assist, suggère des actions comme le redimensionnement des machines virtuelles inutilisées.

Acheter, faire appel à un expert ou signaler

Les places de marché vendent des logiciels, des données et des services tiers facturés sur la facture cloud. Elles peuvent simplifier les achats et le suivi des droits d’utilisation des logiciels achetés. Elles ne servent pas à déposer des demandes de support technique. Fais appel à un partenaire ou à une équipe de conseil du fournisseur lorsque tu as besoin d’expertise pour réaliser une migration ou concevoir une organisation.

AWS Trust and Safety traite les abus présumés provenant de ressources AWS, comme les pourriels, les analyses, le trafic de déni de service ou les logiciels malveillants. Toute personne peut signaler un abus présumé ; cette démarche est distincte d’une demande de support concernant ta propre application.

Associe chaque demande concrète au service adapté : « Qu’est-ce qui a changé dans l’état des services de notre abonnement ? » appelle la vue personnalisée de l’état des services. « Qui peut nous aider à réaliser notre migration ? » appelle un partenaire de conseil ou Professional Services. « Où pouvons-nous obtenir une licence de pare-feu facturée sur notre facture cloud ? » appelle la place de marché. « Quelles ressources semblent inutilisées ? » appelle un outil de conseil ou de recommandation, puis un examen des besoins de la charge de travail par son responsable.

Un cadre Well-Architected organise les bonnes pratiques de conception et d’exploitation d’une charge de travail. Ses piliers aident une équipe à poser des questions équilibrées sur le système. Il s’agit de recommandations pour l’évaluation et l’amélioration, pas d’une certification ou d’une norme de conformité.

Connaître les piliers et leur sens

AWS comporte six piliers : excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts et développement durable. Azure en comporte cinq : fiabilité, sécurité, optimisation des coûts, excellence opérationnelle et efficacité des performances. Google Cloud en comporte six : excellence opérationnelle ; sécurité, confidentialité et conformité ; fiabilité ; optimisation des coûts ; optimisation des performances ; et développement durable.

L’excellence opérationnelle consiste à exploiter et à améliorer les systèmes grâce à la surveillance, à l’automatisation et à des modifications sûres. La sécurité protège les systèmes et les données. La fiabilité consiste à se remettre des pannes et à continuer de remplir les fonctions prévues. L’efficacité ou l’optimisation des performances consiste à répondre à la demande avec des ressources adaptées et une mise à l’échelle appropriée. L’optimisation des coûts recherche le coût approprié le plus bas pour la valeur métier requise. Le développement durable tient compte de l’impact environnemental de la charge de travail.

Le pilier des coûts relie la tarification à la conception : mesurer les dépenses, les attribuer à des responsables, choisir des modèles d’achat adaptés et examiner l’utilisation. Un service managé peut réduire le coût total d’exploitation même lorsque ses frais directs dépassent les frais de machine virtuelle d’une solution autogérée.

Transformer les questions en plan d’amélioration

AWS Well-Architected Tool est un service gratuit de la console qui permet d’évaluer une charge de travail au moyen de questions pour chaque pilier. Il consigne les problèmes à risque élevé et moyen et facilite l’établissement d’un plan d’amélioration. Les prismes ajoutent des questions pour certains types de charges de travail, comme les applications sans serveur. Azure fournit une évaluation Well-Architected Review, et Azure Advisor organise ses recommandations autour de ses piliers.

Lors d’une évaluation, l’absence de budget révèle un problème de coût. Une base de données fonctionnant dans une seule zone de disponibilité présente un risque pour la fiabilité. L’absence d’authentification multifacteur sur les comptes administrateurs est un problème de sécurité. Les déploiements manuels suggèrent des risques opérationnels. Classe en priorité l’absence d’authentification multifacteur et l’exposition aux pannes selon les exigences et l’impact de la charge de travail ; ne traite pas tous les constats comme s’ils étaient aussi urgents.

Expliquer les compromis

Une seconde région peut améliorer la résilience, mais elle ajoute des coûts d’infrastructure, de réplication et de transfert. Une duplication complète double approximativement le coût des composants dupliqués. Un environnement de secours plus petit coûte moins cher et prend généralement plus de temps pour rétablir la pleine capacité. Aucun de ces choix ne peut être fait judicieusement sans exigence concernant la durée d’interruption acceptable et la reprise.

Une réduction des coûts qui supprime une copie nécessaire à la reprise peut dégrader la fiabilité. Des contrôles de sécurité supplémentaires peuvent demander plus d’efforts et de dépenses tout en réduisant le risque. L’objectif est un équilibre justifié, pas le score maximal possible pour chaque pilier pris isolément.

Imagine un service qui peut tolérer une interruption de plusieurs heures et un autre qui perd des revenus importants après quelques minutes. Une même conception coûteuse avec une seconde région peut avoir une valeur différente pour ces deux services. Consigne l’exigence métier qui motive le choix et réexamine-la lorsque le trafic, l’architecture ou le caractère critique changent.

Une évaluation Well-Architected porte sur une charge de travail. Un plan à l’échelle de l’organisation pour les compétences, la gouvernance et la migration utilise un cadre d’adoption du cloud. Garde les deux niveaux liés : les normes de l’organisation aident les équipes, tandis que les constats sur les charges de travail révèlent les lacunes pratiques de ces normes.

Un cadre d’adoption du cloud guide le passage d’une organisation au cloud. Il relie les objectifs métier, les personnes, la gouvernance, la sécurité et les opérations au travail technique. Une évaluation Well-Architected examine comment une charge de travail doit fonctionner ; les recommandations d’adoption examinent comment l’organisation se prépare à construire et à exploiter de nombreuses charges de travail.

Utiliser les perspectives et les phases AWS

AWS CAF regroupe les capacités en six perspectives. Business, People et Governance portent sur les capacités métier. Platform, Security et Operations portent sur les capacités techniques. Une analyse de rentabilité relève de Business ; les compétences du personnel de People ; la gestion financière du cloud de Governance.

Les phases du parcours sont Envision, Align, Launch et Scale. AWS décrit les résultats souhaités, notamment la réduction des risques pour l’entreprise, l’amélioration des performances environnementales, sociales et de gouvernance, l’augmentation des revenus et l’amélioration de l’efficacité opérationnelle. Les perspectives décrivent des domaines de capacité ; les phases décrivent le parcours. Elles répondent à des questions d’organisation différentes.

Situer les tâches Azure dans son cadre

Les sept phases Microsoft sont Strategy, Plan, Ready, Adopt, Govern, Secure et Manage. Strategy définit pourquoi adopter le cloud et comment reconnaître la réussite. Plan prépare les personnes et les charges de travail. Ready établit l’environnement. Adopt déplace, modernise et construit les charges de travail. Govern contrôle l’environnement, Secure le protège et Manage l’exploite et l’améliore.

Govern, Secure et Manage se poursuivent pendant que les charges de travail fonctionnent. Ce sont des responsabilités continues, pas trois tâches réservées à la fin de toutes les migrations.

Une zone d’atterrissage est l’environnement préparé pour les charges de travail, avec les comptes ou abonnements, l’identité, le réseau, la journalisation, les politiques et la structure de facturation. Azure landing zones soutient Ready ; AWS Control Tower aide à mettre en place un environnement à plusieurs comptes doté de contrôles. Prépare ces fondations avant que les équipes commencent à déployer des charges de travail dans un environnement sans gouvernance.

Évaluer la maturité Google Cloud

Google Cloud Adoption Framework utilise quatre thèmes : Learn, Lead, Scale et Secure. Il évalue chacun selon les phases tactique, stratégique et transformationnelle de la Cloud Maturity Scale. Le travail tactique porte sur des charges de travail individuelles sans plan à long terme. Le travail stratégique prépare les besoins futurs. Les organisations transformationnelles fonctionnent sans heurt et se concentrent sur l’innovation et les données.

Une équipe peut avoir besoin de progresser en direction ou en compétences même lorsque sa plateforme technique est solide. Évalue les thèmes pour identifier quelle capacité organisationnelle freine l’adoption ; acheter davantage de services ne fournit ni des personnes formées ni un plan commun.

Associer les tâches réelles sans mélanger les vocabulaires

Pour une entreprise de commerce, « réduire les coûts du centre de données de 20 % en trois ans » relève de Microsoft Strategy et de la perspective AWS Business. « Former 40 membres du personnel » correspond à Microsoft Plan et AWS People. « Préparer les comptes, le réseau et les politiques » correspond à Microsoft Ready et AWS Platform. Migrer 30 applications correspond à Microsoft Adopt ; les balises et les budgets correspondent à Govern et AWS Governance. La surveillance des services en fonctionnement correspond à Microsoft Manage et AWS Operations.

Utilise les noms propres à chaque fournisseur lorsque tu expliques ces associations. AWS n’a pas de phase appelée Ready, et le thème Learn de Google n’est pas une phase Azure. Adapte les recommandations aux objectifs de l’organisation, organise le travail selon les dépendances et maintiens la gouvernance et les opérations après l’arrivée des premières charges de travail.