AWS S3 : Comment comprendre et réduire votre facture ?

, ,

Lorsque vous stockez des objets dans le AWS S3, vous ne payez pas seulement pour l’objet stocké, mais vous accédez généralement à ces objets d’une certaine manière.

Si votre compte AWS est relativement récent (moins de 12 mois), vous pourrez probablement bénéficier du volet gratuit. Cela signifie 5 Go de stockage gratuit + 20 000 demandes GET et 2 000 demandes PUT. N’oubliez pas que cette offre expire au bout de 12 mois à compter de la création du compte.

Nous avons donc 3 éléments dans notre facture pour réduire votre facture AWS S3.

Stockage : Selon le type de stockage que vous choisissez pour votre Bucket, c’est le prix que vous payez par Go de données stockées. Vous avez 3 types, Standard, Standard-IA (accès peu fréquent) et Glacier et le prix varie en fonction de la région où votre bucket est créé.

Demandes : Il s’agit essentiellement du nombre d’appels effectués à l’API S3 pour récupérer les objets. Le prix dépend du type de requête (les requêtes DELETE sont gratuites), de la région et du type de stockage.

Vous pourriez également voir sur votre facture des choses comme :

  • Amazon Simple Storage Service EU-Requests-Tier1 : Il s’agit des demandes PUT, COPY, POST, ou LIST.
  • Amazon Simple Storage Service EU-Requests-Tier2 (Service de stockage simple Amazon EU-Requests-Tier2) : Ceci est pour les demandes GET et toutes les autres demandes.
  • Amazon Simple Storage Service EU-Requests-Tier3 (Service de stockage simple Amazon EU-Requests-Tier3) : Il s’agit des demandes concernant les glaciers.
  • Amazon Simple Storage Service EU-Requests-Tier4 : Il s’agit du nombre de transitions vers l’accès standard peu fréquent que vous avez demandé.

Transfert de données : Ceci est mesuré en entrée (IN) et en sortie (OUT). La bonne chose est que les données IN sont gratuites. Le transfert OUT dépend de l’endroit et de la manière dont vous envoyez les données. Si vous transférez des données à une autre instance EC2 dans la même région, c’est gratuit. N’oubliez pas d’utiliser les terminaux VPC S3 pour économiser encore plus d’argent.

Vous avez la liste des prix sur le site Amazon S3 ici, attention, elle change très souvent.

Maintenant, comment puis-je mesurer en temps réel combien j’utilise AWS S3 ?

Avec la nouvelle console de gestion S3 (vous devez l’activer dans votre compte AWS), vous avez la liste des buckets.

Reduire facture S3 AWS, selectionnez votre bucket

Lorsque vous sélectionnez l’un d’entre eux, choisissez l’onglet Gestion (Management) en haut de la page.

Reduire facture S3 AWS, Allez dans Management Tab

Reduire facture S3 AWS, Cliquez sur Metrics

Ensuite, choisissez Métriques (Metrics)

Ici, vous pourrez choisir entre Stockage (Storage), Demandes (Requests) ou Transfert de données (Data Transfer). Il convient de préciser que la mesure de stockage est la seule qui soit Gratuite.

Je vous recommande vivement de garder un œil sur vos factures AWS et d’analyser celle-ci via l’outil Cost Explorer, vous trouverez de nombreuses façons d’économiser de l’argent et de recevoir les félicitations de votre patron 😉 !

Aller plus loin : 

Article Premaccess = FinOps : comment réduire les couts sur AWS ?

Premaccess  = découvrir notre accompagnement avec notre équipe consulting

/par

Prix fixe ou au forfait : combien coûte le développement d’une application ?

, ,

Après 30 ans dans le domaine du développement web, Romain Demoustier “Directeur du conseil” accompagne les clients de premaccess dans la transformation de leur univers informatique. Pour ce manager de transition, les dirigeants ne doivent plus considérer la création de logiciel ou d’application comme un coût fixe, mais comme une charge récurrente, lissée dans le temps. Car, prendre en compte le besoin de ces clients demande désormais d’améliorer son offre en continu. Une posture nouvelle qui favorise le développement de nouvelles stratégies. 

Le developpement Avant Internet et le cloud

« Quand j’ai débuté ma carrière dans l’informatique, nous étions loin du développement itératif : les entreprises pensaient leur logiciel comme un produit à réaliser à un instant T. Il représentait un coût fixe pour leurs dirigeants, explique Romain Demoustier. Cette méthode leur convenait bien, car les logiciels étaient des produits que nous installions sur des postes informatiques. Le coût de distribution des logiciels étaient lourds : envoyer un CD, installer une nouvelle version sur beaucoup de machines prenaient beaucoup de temps. »

À cette époque, les projets de développement étaient menés en suivant notamment la méthode en cascade :

quels sont nos besoins > voici le produit que nous pouvons développer pour y répondre > voici le planning et le coût de ce produit. 

Cette méthode a un inconvénient majeur : entre le moment où vous énonciez vos besoins et la réalisation du produit par les développeurs, un temps s’était écoulé et votre demande avait évolué. Du coup, le produit final ne répondait plus à la requête initiale. Il fallait donc l’étoffer. Résultat : cela vous coûtait plus cher que prévu. 

Depuis, la donne a changé pour les développeurs…

Internet et le cloud ont considérablement bouleversé le métier de développeurs. Aujourd’hui, nous ne parlons plus de logiciels mais d’applications disponibles à la demande (SaaS).

Avec cette transformation digitale, les développeurs ont basculé dans le développement continu. Cela est tangible dans leurs méthodes de travail, plus agiles, plus proches du besoin utilisateur. Les logiciels ne sont plus installés sur des machines, mais sont disponibles sur le cloud. Cela leur permet de les modifier constamment pour mieux répondre à la demande du consommateur. 

… mais aussi pour les dirigeants 

Ce développement continu a forcément un impact sur les finances des entreprises. 

« Je suis souvent consulté par des chefs d’entreprises ou des porteurs de projets pour le développement d’application, rapporte Romain Demoustier. Ils me posent généralement la même question : « Je souhaite développer un nouveau service. J’ai besoin d’une application. Voici les fonctionnalités à créer. À votre avis, combien cela pourrait-il coûter ? Une entreprise m’a fait un devis de 60 000 euros pour développer mon application, qu’en pensez-vous ? »

À chaque fois, ma réponse est identique : il ne faut plus voir une application comme un produit que l’on réalise en une seule fois, mais comme un process continu d’amélioration. Nos méthodes de développement en cascade nous ont prouvé que produire un logiciel en « one-shot » peut coûter plus cher que prévu. Pour rendre nos investissements plus rentables, répartissons-les dans le temps. »

Comme les développeurs qui pensent leur logiciel de façon continue, les dirigeants et porteurs de projets doivent désormais changer leur regard sur la manière de mettre en oeuvre leurs applications. Ils ne doivent plus penser leur logiciel / application comme un coût fixe, mais comme une dépense mensuelle sur la durée du projet. Ainsi, ils pourront l’étoffer au fur et à mesure en fonction des besoins de leurs cibles. Tous doivent avoir en tête qu’une application n’est plus un produit figé, mais un service « vivant » façonné par l’expérience client.

Beaucoup diront que le principal frein à cette méthode est l’estimation du coût sur le long terme. Effectivement, au début, il est difficile de chiffrer complètement le projet. Mais ce projet lui-même n’est pas totalement défini au départ, il va évoluer au fur et à mesure de sa réalisation. L’expérience nous a prouvé que produire ainsi permet de mieux répartir les dépenses lors d’un développement. 

Notre accompagnement chez premaccess

Chez premaccess, nous avons adopté le développement continu avec plusieurs de nos clients. Quand l’un d’entre eux nous sollicite pour le développement d’un logiciel, notre objectif est de définir les besoins initiaux. 

Ainsi, nous développons un PoC (proof of concept). Ce produit n’est pas destiné à entrer en production. Il sert juste à vérifier que tout fonctionne d’un point de vue technique, mais aussi business. 

Une fois validé, nous créons un prototype opérationnel, un MVP (minimum viable product). Nous le mettons en ligne et nous le faisons évoluer progressivement avec le client. 

  • L’intérêt majeur de cette méthode est que le développement d’un MVP coûte bien moins cher.
  • Son second intérêt est que nous le mettons à disposition des utilisateurs de nos clients. Ainsi, nous confrontons l’idée au marché pour l’améliorer progressivement. 

Développement continu : les avantages pour les entreprises

  1. Vous réduisez vos risques d’échecs : De manière générale, les dirigeants ont du mal à conceptualiser ce qu’ils veulent. Lors de projets menés via la méthode en cascade, ces derniers sont très souvent déçus, car le produit final n’est pas celui attendu. La déception est d’autant plus grande qu’il faut réinvestir de l’argent pour modifier à nouveau le produit. En développant en continu, en créant un MVP, et donc en payant au fur et à mesure, cela leur permet de visualiser le résultat et de l’affiner. Vous réduisez ainsi vos risques d’échec car vous testez votre offre auprès de vos clients et vous vous assurez d’aller dans la bonne voie technologique.

  2. Vous dépensez moins au lancement du projet : Produire un MVP vous coûte bien moins cher que de créer un produit « one-shot ». Pourquoi ? Car, vous créez vos fonctionnalités au fur et mesure au lieu de créer un produit avec une multitudes de fonctionnalités qui, une fois sur deux, ne seront pas utilisées par vos utilisateurs. De plus, cela a la mérite de forcer le dirigeant à synthétiser son offre, à définir quelle est sa vraie valeur ajoutée.

  3. Vous gagnerez du temps car, dans cette démarche, il est plus rapide de produire un MVP que de développer en une seule fois un important logiciel avec pléthores de fonctionnalités.

  4. Vous testez et ajustez votre offre auprès de vos utilisateurs. Vous êtes donc plus en alerte de nouveaux business models.

  5. Vous avez un aperçu de vos dépenses : Enfin, l’équipe de premaccess conseillent à ses clients de déployer leur offre sur AWS, car ce cloud provider permet de créer des applications facilement en microservices (serverless). Par ailleurs, il permet d’avoir un aperçu sur vos dépenses : vous payez uniquement les ressources que vous consommez. Ce qui peut s’avérer stratégique en début de projet. Il n’y a plus d’infrastructure complexe à payer même si elle ne sert pas.

Avec le cloud, nous avons basculé dans une économie de plateforme. Nous sommes passés de l’acquisition de produit (payé en une fois) à l’achat mensuel de services (Spotify, Suite Adobe, Office 365…). Cette logique est désormais de mise lors du développement de vos logiciels ou d’applications. Les entreprises doivent l’avoir en tête. D’autant que l’analyse des données vous permet d’étudier la satisfaction de vos utilisateurs afin d’ajuster votre offre très rapidement.

Si vous souhaitez en savoir plus sur ce sujet, n’hésitez pas à contacter l’équipe de premaccess. Elle vous accompagnera pas à pas dans la création de votre projet, et vous présentera les atouts du développement continu.

/par

Que signifient AWS CloudFormation Registry et CLI pour les DevOps dans le cloud

, ,

Le 18 novembre dernier, AWS a annoncé la sortie de son AWS CloudFormation Registry et CLI, une extension d’AWS CloudFormation prenant en charge la création de ressources tierces via la console AWS CloudFormation. C’est également la première fois que le service AWS est associé à des partenaires de lancement tels que Spotinst et Fortinet.


Maintenant, grâce à la prise en charge de ces ressources tierces, AWS améliore toute la pratique de la création d’infrastructure dans le cloud, car le provisionnement s’étend désormais au-delà des ressources AWS pour inclure également des outils SaaS en provenance d’autres fournisseurs, renforçant la façon dont nous construisons dans le cloud.

Par conséquent, le but de cet article est de montrer l’importance d’IaC ‘Infrastructure as Code’ dans le domaine du cloud computing et de souligner l’importance des développements d’AWS pour son service AWS CloudFormation.

Les principes de l’IaC

IaC, abréviation de Infrastructure as Code, est la pratique selon laquelle les ressources sont décrites  par des scripts par opposition à l’utilisation de consoles de gestion qui permettent de créer manuellement des environnements de ressources.
Par conséquent, dans le cas d’AWS CloudFormation, vous n’avez pas besoin d’utiliser la console AWS ou de SDK pour créer des ressources AWS.
De plus, avec AWS CloudFormation Registry, vous avez plus besoin d’utiliser la console d’outils tiers pour utiliser leurs ressources.

Ces scripts lisibles permettent le déploiement automatique des ressources ainsi que les services requis qui vont avec. En effet, les outils IaC vont créer toutes les ressources nécessaire comme par exemple : les réseaux, les machines virtuelles, les équilibreurs de charge et les différents accès pour vos applications.


De plus, chaque fois qu’un script IaC est appliqué, il en résulte toujours le même environnement que celui décrit dans le script.

Par conséquent, les avantages deviennent évidents. L’IaC est une pratique courante pour les DevOps car l’objectif du DevOps est de réaliser l’automatisation du processus de production. En effet, avec l’IaC, nous sommes en mesure d’automatiser la construction de l’infrastructure, ce qui est encore plus crucial dans les environnements cloud.


Même si les environnements cloud soustraient une grande partie de l’architecture sous-jacente aux développeurs, ils nécessitent des configurations fastidieuses des ressources dépendante des contraintes du cloud provider choisi.
Par conséquent, les services IaC tels qu’AWS Cloudformation fournissent une certaine forme de répit face au besoin de configurations répétitives.

D’autres avantages incluent l’indépendance entre les états et les modèles.
Étant donné que l’IaC nous permet de modéliser notre infrastructure dans un format basé sur un script, nous pouvons définir l’état souhaité de notre infrastructure cloud.
Par conséquent, si l’infrastructure s’écarte trop de l’état souhaité, nous pouvons automatiser sa récupération à l’aide du modèle initialement utilisé.

De même, nous pouvons utiliser le même modèle pour répliquer l’état souhaité dans plusieurs environnements (Production/Pré-Production/Recette par exemple). Ceci est extrêmement avantageux à des fins de test, car cela permet  d’avoir des scénarios réels. Ainsi, au lieu d’avoir à configurer ardûment chaque composant pour refléter l’infrastructure à tester, nous pouvons simplement automatiser le provisionnement d’une infrastructure identique, suivi de tests automatisés facilités par les différents outils de CI / CD mis à disposition par le Cloud Provider.

Par conséquent, les outils IaC peuvent être considérés comme des livres  de recettes pour notre infrastructure cloud.
En fait, l’utilisation de cette analogie de livre de recettes pour les services IaC est si courante que Jeff Barr – Chief Evangelist d’AWS a habilement intitulé son blog d’introduction d’AWS CloudFormation https://aws.amazon.com/blogs/aws/cloudformation-create-your-aws-stack-from-a-recipe/, en 2011.

Cependant, les gens ne réalisent pas que les outils IaC ne sont pas comme vos livres de recettes ordinaires, mais plutôt comme des cuisines entièrement automatisées qui analysent ces recettes et cuisinent des infrastructures cloud complètes pour vous.

Nous pouvons convenir que l’IaC, en général, est impératif pour une expérience DevOps complète. La question est maintenant de savoir quels services le plus grand fournisseur de cloud, AWS, fournit en termes d’IaC ?
Avant, la réponse était CloudFormation et son générateur CDK (AWS Cloud Development Kit).

CloudFormation et ses avantages avec CloudFormation Registry

AWS CloudFormation fournit un langage commun pour vous permettre de décrire et de provisionner toutes les ressources d’infrastructure dans votre environnement cloud.
 https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/registry.html

CloudFormation vous permet de définir les ressources AWS souhaitées ainsi que leurs configurations et connexions dans des documents de plan directeurs appelés modèles CloudFormation. Ces modèles sont ensuite exécutés dans la console AWS CloudFormation pour provisionner l’infrastructure définie.
Ce faisant, le service garantit que les composants de l’infrastructure cloud sont déployés de la bonne manière en fonction des dépendances décrites dans le modèle CloudFormation.

Par exemple, si vous souhaitez qu’une instance EC2 s’exécute dans un VPC, CloudFormation garantit que le VPC est d’abord provisionné, puis l’instance EC2.
Cela signifie également que nous n’avons plus besoin d’utiliser la gestion AWS pour configurer et ajouter manuellement l’instance EC2 dans le VPC.

Cependant, un domaine que AWS CloudFormation n’avait pas était le provisionnement des ressources tierces. Oui, les ressources AWS constituent le cœur de l’infrastructure de l’application, mais ces composants communique très probablement avec des outils SaaS tiers quelque part dans le flux de travail de vos applications.
Pour revenir à l’exemple d’une instance EC2 dans un VPC, nous pouvons avoir besoin de cette instance EC2 pour ensuite interagir avec l’API Stripe.

Par conséquent, même si nous avons réussi à automatiser avec vos DevOps du côté AWS, nous ne disposions toujours pas d’outils lorsqu’il s’agissait de connecter nos infrastructures tiers à l’infrastructure AWS principale.
Cela nous ramènerait souvent à la case départ car les avantages de l’IaC discutés ci-dessus étaient limités aux seules ressources AWS.

C’est là qu’intervient AWS Cloud Registry !

Désormais, avec la nouvelle version, la capacités d’AWS CloudFormation a ce connecter sur les ressources externes est résolu. Le registre AWS CloudFormation permet le provisionnement de ces outils tiers externes avec les ressources AWS.

Avec la sortie de ce nouveau service, il y a un total de sept outils SaaS offrant leurs ressources sur le registre.
Par exemple, avec la prise en charge d’Atlassian Opsgenie par le registre AWS CloudFormation, vous pouvez désormais provisionner des ressources Opsgenie telles que des utilisateurs, des équipes et des intégrations avec vos ressources AWS.
Vous pouvez donc automatiser la configuration des services de gestion des incidents Opsgenie dans votre infrastructure AWS.

Cela signifie que nous pouvons désormais bénéficier davantage des pratiques DevOps, car AWS a étendu ses services IaC sur des piles de technologies externes et ne se limite pas uniquement à AWS.
De plus, AWS CloudFormation Registry est open source, de sorte que la communauté peut constamment créer plus de ressources personnalisées qui peuvent être provisionnées automatiquement via l’AWS CloudFormation CLI. Cela améliore l’adoption du cloud, en particulier en utilisant le IaC pour déployer vos architectures AWS.

Un pas de plus avec AWS CloudFormation CLI

AWS CloudFormation fournit des ressources tierces à inclure dans les livres de recettes de vos infrastructures cloud souhaitées.


Si nous devons suivre cette analogie de recette, le registre CloudFormation peut être considéré comme votre garde-manger de ressources, où votre garde-manger stocke les ressources fournies par les partenaires SaaS tiers.

La question est alors de savoir si vous souhaitez étendre ce garde-manger?

C’est là que le composant CLI entre dans la nouvelle version d’AWS CloudFormation. L’AWS CloudFormation CLI nous fournit un ensemble d’ustensiles qui nous permet de créer nos propres ressources personnalisées que nous pourrons ensuite inclure dans les modèles AWS CloudFormation, ce qui nous donne la liberté d’étendre nos garde-manger à l’infini.

AWS fournit la CFN ( CloudFormation Command Line Interface ) qui nous permet d’initialiser nos projets de ressources personnalisés, et génère automatiquement la structure de code de base pour nous et ensuite nous permet de tester nos ressources construites tout en l’enregistrant dans nos registres AWS CloudFormation privé .

AWS nous fournit un ensemble complet de ressources pour commencer à créer ces nouvelles ressources. De plus, la poussée de l’open source avec AWS CloudFormation open source signifie que nous pouvons nous attendre à ce que beaucoup de bibliothèque de ressources soit disponible et facile à inclus dans nos modèles AWS CloudFormation.

Améliorant ainsi toute l’expérience d’utilisation du service IaC, augmentant la vitesse avec laquelle nous construisons dans le cloud.

Récapitulatif de ce que AWS CloudFormation signifie pour le DevOps

Avec le registre AWS CloudFormation et l’interface CLI, nous voyons les avantages d’avoir des ressources tierces non AWS dans nos processus d’infrastructure cloud.

Nous pouvons être assurés que l’utilisation d’AWS CloudFormation pour des applications et la gestion des infrastructures cloud couvre désormais l’intégralité de votre besoins et pas seulement des ressources AWS spécifiques.

La flexibilité de l’AWS CloudFormation CLI et la fiabilité de l’expansion du registre AWS CloudFormation ne peuvent que signifier qu’avec le temps, comme de plus en plus de ressources seront disponibles, nous pouvons nous attendre à ce que le développement dans le cloud deviennent beaucoup plus facile. Nous ne devons plus réinventer la roue, il nous suffit maintenant de nous soucier de la destination.

Bonne lecture ! Contactez-nous si vous avez des besoins en Développement ou en Service Managés Cloud.

/par

FinOps : comment réduire les coûts sur AWS ?

, , ,

Basculer tout ou partie de son infrastructure sur le Cloud d’AWS a un coût. Mais, il est possible d’optimiser ces dépenses. La solution idéale : avoir une démarche FinOps. Ce processus fait son apparition aujourd’hui dans les grands groupes. Il vise à rapprocher finance et ingénierie. En conjuguant leurs compétences, ses équipes analysent vos infrastructures avec un oeil nouveau avec pour objectifs : améliorer votre usage du Cloud afin de réduire considérablement votre facture. 

Sur AWS, il existe 5 grands piliers pour optimiser les coûts. Si vous souhaitez installer vos applications chez ce Cloud Provider, nous vous invitons à suivre ces 5 recommandations. Vous intégrerez ainsi la FinOps dans votre stratégie digitale.

Configurez efficacement la taille de vos instances

Sur AWS, il est possible d’ajuster la taille des services utilisés en fonction de vos besoins à l’instant T, et de les redimensionner au fur et à mesure selon les pics de charges enregistrés. Cet ajustement dépend de plusieurs facteurs : de votre environnement (développement, test ou production), de la fluctuation de votre activité en ligne, etc…

Bien adapter la taille de vos instances a un impact sur la capacité de calcul de votre infrastructure, sur sa mémoire, son stockage, le débit du réseau…

Pour cela, trois services managés sont à votre disposition sur AWS : 

Optez pour l’élasticité

L’intérêt du FinOps sur le cloud est que vous pouvez augmenter ou réduire les ressources nécessaires en fonction de vos besoins. En cas d’augmentation de trafic, vous devrez utiliser plus de ressources. Une fois ce pic redescendu, inutile de garder cette configuration.

Objectif : ne payez que ce que vous consommez. 

Il existe deux types d’élasticité : une première basée sur le temps, une seconde calculée sur le volume de ressources nécessaires au bon fonctionnement. Sur AWS, plusieurs services managés vous aident à paramétrer ces élasticités :

  • Amazon EC2 Scheduler permet de configurer le planning de démarrage et d’arrêt des instances Amazon EC2.
  • AWS Lambda exécute votre code uniquement lorsque cela est nécessaire et s’adapte automatiquement, qu’il s’agisse de quelques demandes par jour ou de milliers par seconde.
  • AWS DataPipeline arrête et démarre les instances Amazon EC2 en exécutant des commandes CLI (AWS) sur un horaire fixe.
  • Amazon CloudWatch surveille votre utilisation des instances Amazon EC2 et les arrête si elles ne sont pas utilisées.
  • AWS Auto Scaling augmente et réduit automatiquement le nombre de vos instances Amazon EC2 afin de maintenir la performance du système en cas de pic de trafic et de réduire ses capacités en cas de période creuse.

Utilisez le bon modèle de tarification

AWS proposait jusqu’à présent trois modèles de tarification : instances à la demande, instances réservées, et instances spot. Il en propose un quatrième depuis ce mois-ci : le Savings Plans. La combinaison de ces quatre modèles vous permettra de réduire les coûts.

Avec les instances à la demande, vous payez la capacité de calcul à l’heure ou à la seconde (60 secondes minimum) sans engagement à long terme.

Avec les instances réservées, vous bénéficiez d’une remise conséquente (jusqu’à 75 %) par rapport à la tarification à la demande. Vous disposez également d’une réservation de capacité quand elles sont exécutées dans une zone de disponibilité spécifique.

Avec les instances Spot Amazon EC2, vous profitez des capacités EC2 non utilisées dans le cloud AWS. Ces instances sont disponibles avec une réduction allant jusqu’à 90 % par rapport aux tarifs à la demande. Elles sont utilisables pour des applications statiques, tolérantes aux pannes ou flexibles comme, par exemple, les charges de travail du test et développement. 

Lancé en Novembre 2019, le Savings Plans offre les mêmes réductions que les instances réservées, mais, pour pouvoir y accéder, l’utilisateur doit s’engager à utiliser un montant spécifique de puissance de calcul (mesuré en dollars par heure) sur une période maximale de trois ans.

Ce modèle est intéressant pour les entreprises qui ont un aperçu de leurs besoins sur le long terme. Cela leur permettra de réserver les ressources nécessaires sur une période longue bien définie, tout en réalisant des économies.

Ce Savings Plans FinOps est disponible sous deux versions :

Le plan « Compute Savings » offre une grande flexibilité et permet de réduire vos coûts jusqu’à 66% (tout comme les instances réservées convertibles). Ce plan s’applique automatiquement à toute instance EC2, quelle que soit la région. Par exemple, vous pouvez passer d’instances C4 à C5, déplacer une charge de travail de Dublin à Londres, en bénéficiant des prix de ce plan d’épargne.

À la différence, le Savings Plans EC2 s’applique à une famille d’instances spécifique dans une seule région et mais offre un rabais le plus important (jusqu’à 72%). 

Pour aller plus loin sur le Savings Plans :

https://aws.amazon.com/fr/savingsplans/

Optimisez votre espace de stockage

AWS propose plusieurs services de stockage. La clé, pour assurer votre budget FinOps sur cette partie, est de bien choisir votre espace en fonction de vos usages.

Avec Amazon S3, vous disposez d’une offre large de stockage conçue pour différents types d’utilisation :

– S3 Standard est dédié au stockage de données « à usage général ».

– À l’inverse, Reduced Redundancy Storage (RRS) vous permet de stocker les données non critiques et reproductibles à des niveaux de redondance inférieurs à ceux du stockage standard Amazon S3.

– S3 Intelligent-Tiering permet de déplacer des données entre deux niveaux d’accès (fréquent et peu fréquent). Idéal pour les données dont les schémas d’accès sont inconnus ou modifiés.

– S3 Standard-Infrequent Access (S3 Standard-IA) est prévue pour les données auxquelles on accède rarement (copie de sauvegarde secondaire de données d’un site, etc…)

– Amazon S3 Glacier (S3 Glacier) et Amazon S3 Glacier Deep Archive (S3 Glacier Deep Archive) sont des classes de stockage destinées à l’archivage et la sauvegarde des données à long terme. Toutes deux proposent des options d’accès aux archives à coûts avantageux. Ces accès ont des délais allant de quelques minutes à 12 ou 48 heures.

Avec Amazon Elastic Block Store (Amazon EBS), vous optez pour un stockage permanent accessible par des instances EC2 simples. Cela est utile pour les bases de données relationnelles et NoSQL, les applications d’entreprise, et les analyses de Big Data.

Amazon Elastic File System (Amazon EFS) est utile pour le stockage simple de fichiers et pour une charges de travail basée sur Linux. 

Amazon FSx for Lustre est nécessaire pour les charges de travail demandant une importante capacité de calcul, telles que le Machine Learning et le traitement de données multimédia.

Amazon FSx for Windows File Server est dédié aux applications Windows qui nécessitent un stockage de fichiers vers AWS.

AWS Storage Gateway soutient des opérations de cloud bursting, de hiérarchisation et de migration.

Enfin, AWS Backup centralise et automatise la sauvegarde de données sur l’ensemble des services AWS.

Mesurez et surveillez vos environnements

Pensez, en premier lieu, à baliser (Charte de TAG) vos instances, images et diverses ressources. 

Utilisez, en second temps, AWS Cost Explorer. Avec ce service managé, vous visualisez et comprenez mieux votre utilisation d’AWS avec vos balises en place projet par projet. Ainsi, vous maximisez votre gestion du Cloud au fur et à mesure. Grâce à AWS Cost Explorer, vous disposez de rapports sur vos coûts mensuels par service, par compte, par projet…

Enfin, si vous voulez être alerté en cas de dépassement de budget, optez pour AWS Budgets. Avec ce service, vous définissez des montants à investir. Une fois cette somme atteinte, vous êtes aussitôt prévenu.

Adopter une démarche FinOps n’est pas simple. Taille des instances, auto-scaling, tarification, stockage… Plusieurs éléments sont à prendre en compte pour réussir à jongler entre ingénierie et coûts.
Aussi, si vous souhaitez réduire vos dépenses d’infrastructure sur AWS, n’hésitez pas à solliciter les équipes de premaccess. Spécialisées dans les services managés de ce Cloud Provider, elles auront à coeur de vous conseiller et de vous accompagner dans cette quête d’optimisation technique et financière FinOps .

/par