Introduction

Pour profiter au mieux des services AWS en contrôlant les coûts des services, il faut adopter une stratégie de gestion des coûts.

Pour y arriver, il est conseillé, notamment par la démarche FinOps, d’allier des compétences techniques (choix des meilleurs services à utiliser) et des compétences de finance (choix des meilleures options d’achat de services).

Cette alliance permet de questionner les architectures applicatives (en respectant les besoins métier) sous l'œil de la tarification et définir une stratégie d’achats de services (massification des achats pour obtenir des tarifs dégressifs par exemple).

Dans cet article, nous allons :

• Décrire les principes de facturation chez AWS
• Décrire les services AWS qui facilitent la mise en place d’un budget et la compréhension des coûts
• Et aborder certains services qui permettent d’optimiser la facture

Principes de Facturation

La facturation AWS est basée sur 3 principes :

• Pay-as-you-go
• Économisez en réservant des capacités
• Tarifs dégressifs selon utilisation

Les principes sont simples mais nécessitent un engagement des clients qui doivent vérifier en continu les coûts d’utilisation des services AWS et adapter leurs usages.

Pay-as-you-go

AWS nous fournit les services nécessaires pour allouer des ressources (CPU, stockage, …), les redimensionner (à la hausse ou à la baisse) ou encore les restituer.

Un pattern classique, dans les architectures à base d’instances EC2 (conçues pour héberger des sites web par exemple) consiste :

• à créer les instances EC2 dans un Auto Scaling Group (ASG)
• a configurer une scaling policy qui fixe le nombre d’instances EC2 en fonction d’une métrique donnée (suivi de la cible CPU par exemple)
  

De cette manière, le nombre d’instances EC2 augmente quand la charge (du système) augmente et diminue quand la charge diminue. Avec ce pattern, il n’est pas nécessaire d’estimer la charge : le dimensionnement est élastique.

Les services serverless comme Dynamodb, Lambda, … sont d’excellents candidats du “Pay as you go” : AWS gère le dimensionnement des ressources. Et comme les ressources sont mutualisées entre les clients, les tarifs des services serverless sont très faibles.

Économiser en réservant des capacités

AWS fait une remise aux clients qui s’engagent à acheter certains services (EC2, RDS, EMR, ...) sur une longue période.

Par exemple, en achetant une Reserved Instance plutôt qu’une On Demand Instance, le client bénéficie d’une remise allant jusqu’à 72 %. Ce type d’achat engage le client sur une période de 1 à 3 ans. Le client peut néanmoins revendre les Reserved Instances sur AWS Marketplace.

Pour reprendre l’exemple de la section précédente (instances EC2 dans un ASG), une pratique courante consiste à mixer dans un ASG

• Des Reserved Instances pour gérer la charge stable à long terme
• Des On Demand Instances ou des Spots Instances pour gérer l’augmentation de charge
  

AWS a mis en place des variantes de ce type d’offre :

• Convertible RI pour permettre aux clients de changer les caractéristiques de l’instance (notamment le type de l’instance)
• Scheduled RI pour permettre aux clients d’acheter des instances sur des fenêtres de temps spécifiques (exemple : tous les jours de 8h à 12h)
• Saving Plans est une offre plus générale d’économie qui permet à un client de s’engager (pour économiser bien sûr) sur l’utilisation de différents services de compute (EC2, Fargate, Lambda) sans avoir à choisir le service. Le client peut utiliser indifféremment des instances EC2, des conteneurs Fargate et profiter de la réduction liée au Saving Plan.

Tarifs dégressifs selon utilisation

Un bon exemple de service avec un tarif dégressif est le service de stockage S3.

Le coût d’un bucket S3 est calculé en fonction de l’espace occupé avec différents paliers de tarifs : plus l’espace de stockage du bucket est important, plus le tarif du TéraOctet diminue.

S3 implémente plusieurs classes de stockage qui ont des zones d’usages différentes. Pour exemple, les deux classes S3 Standard et S3 Standard-IA sont respectivement adaptées au stockage de fichiers avec des modèles d’accès changeants (ou inconnus) et au stockage de fichiers peu consultés.

Pour réduire la facture, il est aussi possible de configurer des règles de “cycle de vie” (lifecycle configuration) qui modifient la classe de stockage des fichiers ou définissent des règles d’expiration de fichiers (avec suppression après expiration).

Gestion d’un Budget

Dans cette section, nous allons présenter différents outils de gestion de budget sur AWS.

Comme pour tout budget, la gestion d’un budget AWS est un processus continu.

La première étape consiste à estimer le budget. Même si l’estimation est souvent fausse, elle est utile pour se faire une première idée sur l’architecture en construction. On peut se poser la question : “Est-ce que le prix de l’application est acceptable ?”

La seconde étape est une boucle continue de contrôle du budget et d’optimisation. Le client va à chaque itération vérifier le respect du budget et essayer de réduire les coûts.

Estimation du Budget

Dans une estimation, le coût d’une application est basé sur des hypothèses d’utilisation des services comme par exemple : le type d’instances EC2, le nombre d’instances, etc.

La documentation AWS est très riche et structurée : la documentation de chaque service comporte une section qui traite de sa tarification. Voici par exemple un lien vers la section tarification du service EC2. Le site AWS Pricing centralise toute la documentation de tarification des services AWS.

Via l’application AWS Pricing calculator, nous sommes guidés dans l’estimation de notre budget. Cette application met notamment en valeur les différentes modalités d’achat d’un service. Par exemple, si le client a besoin d’une instance EC2 pour une durée longue (supérieure à 1 an), l’application fait ressortir qu’il est plus rentable d’allouer une instance réservée (Reserved Instance) plutôt qu’une instance à la demande (On Demand Instance).

Ci-dessous une partie de l’écran d’estimation du coût d’une instance EC2.

Comme montré par la copie d’écran ci-dessous, l’application agrège les estimations des services dans une estimation globale.

Définition du Budget

Comme indiqué par son nom, le service AWS Budgets permet de définir un ou plusieurs budgets.

Les budgets définis peuvent être :

• des budgets globaux (tous services confondus)
• des budgets par service
• des budgets récurrents (identiques tous les mois ou pas)
• etc.
  

Ci-dessous une copie d’écran qui compare les coûts mensuels au budget prévisionnel.

Contrôle du Budget

Le dépassement d’un budget peut être une bonne nouvelle ou une mauvaise nouvelle.

• Un exemple de bonne nouvelle est l’augmentation rapide du nombre d’utilisateurs en cas de succès de l’application. Ce qui crée une utilisation plus importante des ressources (mais devrait être économiquement rentable).
• Un exemple de mauvaise nouvelle est une attaque pirate. L’attaque provoque une utilisation plus importante des ressources mais sans contrepartie économique.
  

Via AWS Budgets, il est possible de configurer des notifications (envoyées à une liste de personnes) dans le cas où un budget est dépassé. AWS Budget Reports permet aussi de générer des rapports sur les budgets et les envoyer par email (aux personnes intéressées).

Mais il n’existe pas de mécanismes qui permettent de se prémunir contre un dépassement de budget. En effet, est-ce qu’il existe une réponse unique (ou même un ensemble de réponses) à ce problème ?

En revanche, AWS nous fournit les outils nécessaires pour gérer ce genre d’événement. Et comme nous sommes responsables de l’utilisation des services, nous devons donc détecter les dépassements de budget et appliquer les réponses les plus adaptées.

Nous pouvons par exemple, implémenter le processus de dépassement de budget via une fonction lambda. Puis en nous basant sur le fait qu’un budget est une métrique, déclencher la lambda après dépassement du budget (via une alarme).

Analyse du Budget

AWS Cost Explorer est un outil graphique d’analyse des dépenses. Par défaut, Cost Explorer affiche les dépenses mois par mois.

Le client peut affiner son analyse des dépenses en :

• Filtrant sur les types de dépenses à analyser (compute EC2, lambda, …).
• Agrégeant les dépenses (par type de services, région, …).
  

La copie d’écran ci-dessous montre les coûts des instances EC2 agrégés par région.

L’analyse des coûts peut être contextualisée via des Tags. Si par exemple, nous taguons toutes les ressources d’un environnement de développement, nous pouvons évaluer le coût de cet environnement.

Ci-dessous une analyse des dépenses de l’environnement tagué “sandbox”.

Optimisation du Budget

Trusted Advisor

AWS Trusted Advisor se base sur des bonnes pratiques AWS pour remonter des recommandations sur des services sous exploités (Instances EC2 sous utilisées, ... ) voire inutilisés (base de données inactive, adresse IP élastique non affectée, …).

Cost Explorer Recommandations

En analysant les métriques des services, AWS Cost Explorer Recommandations est capable de proposer des économies à réaliser. Si par exemple une instance EC2 est sous utilisée (utilisation CPU faible), Recommandations propose de réduire la taille de l’instance.

Ci-dessous une recommandation pour réduire la taille de trois instances EC2.

AWS Organisations

AWS Organisations permet de consolider la facturation d’une organisation AWS (ensemble de comptes) dans un compte unique (appelé compte de facturation).

AWS Organisations permet la mutualisation des ressources (On demand, Reserved Instances, Saving Plans, ...) entre plusieurs comptes. Ceci simplifie l’utilisation de ressources achetées à tarifs réduits dans les charges de travail.

Cette fonction de consolidation est cohérente avec la pratique d’isoler les charges de travail, utilisateurs, … dans différents comptes. Et donc assurer une meilleure sécurité des ressources utilisées. En effet seules les personnes habilitées à accéder au compte de facturation ont accès à ce compte.

Infra As Code

Les outils d’Infra As Code (cloudformation, terraform) intègrent aussi des estimations des tarifs.

L’IHM de création d’une stack cloudformation comporte un lien Estimate cost qui redirige l’utilisateur vers l’ancienne application d’estimation de coûts AWS (Simple Monthly Calculator). Comme montré par la copie d’écran ci-dessous, cette application présente une estimation des coûts mensuels associés à la stack.

Pour les projets Terraform, l’estimation des coûts peut être réalisée via infracost (ligne de commande avec intégration github). Les projets Terraform Enterprise disposent nativement de cette fonction via la console web.

Conclusion

L’analyse du budget est un excellent outil pour questionner nos choix d’architecture. En effet, si une application est coûteuse, nous devons nous demander si nous utilisons correctement les services et/ou si nous utilisons les bons services (respect de la zone d’usage). Et donc profiter de ce questionnement pour faire évoluer nos choix techniques.

Pour ma part, j’espère que ces outils d’analyse de coûts seront complétés par d’autres coûts comme les coûts écologiques. A l’instar de cette initiative, je suis sincèrement curieux d’analyser l’empreinte écologique des applications et aussi comparer l’empreinte écologique d’applications déployées sur EC2 avec des applications serverless. Ce type de comparaison serait un atout pour la construction d’applications économes en énergie.