Résumé

  • Selon AWS, la facture mensuelle définitive est calculée avec les préférences de partage des remises en vigueur à 23 h 59 min 59 s UTC le dernier jour du mois. Les estimations utilisent le dernier réglage disponible.
  • La priorité du compte propriétaire et les groupes de partage changent l'ordre et le périmètre des bénéficiaires. L'économie totale et la responsabilité budgétaire de chaque unité demandent un choix de répartition explicite.

L'organigramme a rendez-vous avec la comptabilité à une heure précise : 23 h 59 min 59 s UTC, le dernier jour du mois.

Le guide de facturation d'AWS fixe à cet instant le réglage des préférences de partage utilisé pour la facture mensuelle définitive. Les estimations prennent le dernier état disponible. Entre un montant suivi pendant plusieurs semaines et sa répartition finale, il reste donc une frontière qu'un administrateur peut déplacer.

Pour les Savings Plans, cette frontière distribue un avantage tarifaire. L'application peut continuer à fonctionner au même endroit tandis que son compte change de position dans l'ordre des bénéficiaires. Aucun déménagement de serveur n'est nécessaire. La propriété de l'achat et la carte du partage font déjà une partie du travail financier.

Trois cartes pour une même remise

Le partage ouvert, réglage par défaut, rend les remises disponibles aux comptes de l'organisation dont le partage est activé. Le partage avec priorité de groupe sert d'abord le compte acheteur, puis le groupe défini, puis les autres comptes de l'organisation habilités au partage. Le partage restreint garde l'avantage exclusivement dans le groupe.

Les groupes sont définis avec Cost Categories. Un compte ne peut appartenir qu'à un seul groupe, les groupes ne se chevauchent pas et le compte de gestion ne peut rejoindre un groupe. Le compte propriétaire d'un Savings Plan doit être activé dans les préférences de partage.

Ces traits ont une portée économique. Dans un groupe restreint, un avantage restant ne franchit pas la ligne pour satisfaire la demande du département voisin. AWS indique lui-même que privilégier l'allocation par groupe peut réduire l'optimisation globale des remises.

Une unité dotée de son propre compte de résultat peut apprécier cette séparation. Les achats centraux peuvent y voir une occasion d'économie perdue. Les deux objectifs existent. Le chiffre recommandé dans une console ne décide pas de la valeur que l'entreprise accorde à chacun.

Le compte qui ne fait rien peut être utile aux achats

La propriété passe avant le partage. AWS applique l'avantage aux usages admissibles du compte propriétaire, puis le transmet aux autres comptes selon les règles prévues. À l'intérieur de l'étape d'allocation concernée, les usages offrant le plus fort pourcentage d'économie passent en premier.

Un billet officiel du 25 octobre décrit le cas d'un compte qui utilise Lambda et achète son propre Compute Savings Plan. Son usage bénéficie d'abord de la remise. Il peut ainsi passer devant un usage m8g Linux EC2 d'un autre compte offrant un pourcentage d'économie supérieur. Le billet ne chiffre aucune perte constatée : il expose l'effet de la priorité du propriétaire.

Pour centraliser les achats, AWS propose le compte de gestion ou un compte désigné sans charge de travail. Sans usage admissible propre à servir d'abord, l'avantage peut être réparti aux autres comptes selon les règles de partage. Les applications restent chez elles ; l'achat change d'adresse.

Le compte vide trouve ainsi une fonction. Il sépare le porteur de l'engagement financier de l'utilisateur du calcul. Cela laisse une tâche très concrète : la refacturation interne. Acheter ensemble ne détermine pas automatiquement qui finance l'engagement restant et qui conserve les économies réalisées.

Le siège voit 100 dollars, les équipes en additionnent 70

AWS utilise un scénario explicatif de Compute Savings Plan d'un an sans paiement initial. La recommandation au niveau de la gestion est de 100 dollars par heure ; la somme des recommandations des comptes membres n'est que de 70 dollars. Ces montants illustrent des périmètres de calcul différents.

La vue centrale regroupe les usages admissibles pouvant partager les avantages. La vue locale prend chaque compte avec ses usages et les avantages déjà appliqués. Les profils horaires et les frontières modifient l'objet optimisé. Le billet explique aussi le mouvement inverse : les priorités des propriétaires peuvent rendre la somme des achats individuels supérieure à la recommandation centrale.

Les recommandations calculent le passé. Le guide officiel précise qu'elles excluent les achats en attente ou programmés et visent des achats immédiats. Modifier les groupes change également les comptes pris en considération. Un montant issu de l'ancienne carte mérite d'être recalculé avant de servir de réponse dans la nouvelle.

Pour chiffrer l'effet dans une entreprise donnée, il faut les comptes propriétaires, les préférences de partage, les usages admissibles par heure et le stock actuel d'engagements.

La dernière seconde du mois fixe une carte économique. Celui qui la redessine participe au sort d'une remise qu'une autre équipe a peut-être déjà inscrite dans son budget. Une réorganisation ordinaire a un responsable identifié. La carte des remises mérite le même traitement.

Sources