DBaaS : AWS met l’accent sur la maîtrise des coûts

AWS étend ses Saving Plans aux bases de données

De fait, l’annonce la plus importante affecte Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces for Apache Cassandra, Amazon TimeStream, et AWS Database Migration Service.

Celle-ci consiste en l’extension du programme Savings Plan aux SGBD cités ci-dessus hébergés. Un programme valable dans toutes les régions cloud AWS, sauf en Chine.

Pour mémoire, les Savings Plans ou les plans d’économie en Français, sont des offres qui troquent un rabais important par rapport aux tarifs à la demande (jusqu’à 72 % de réduction), contre un engagement annuel ou trisannuel de consommation au volume. Elles concernaient jusqu’alors les services de calcul (EC2, ECS, Fargate, Lambda), et de machine learning (Amazon SageMaker).

AWS promet jusqu’à 35 % de réduction pour un engagement annuel sur un volume en fonction du nombre d’heures d’usage de ses SGBD. Dans les faits, le rabais varie fortement suivant « le modèle de déploiement et le type de service ». Les gains les plus intéressants par rapport au prix catalogue s’obtiennent avec les services serverless. Suivant les DbaaS, AWS propose une ristourne de 20, 30 ou 35 %.

Le fournisseur applique, a contrario, jusqu’à 20 % de réduction sur ses instances provisionnées. « Avec DynamoDB et Amazon Keyspaces, les charges de travail à débit à la demande bénéficient de réductions allant jusqu’à 18 %, et jusqu’à 12 % sur les capacités provisionnées », précise AWS.

Il y a quelques limites. Il n’est pas possible de cumuler des instances réservées et des Database Saving Plans pour la même charge de travail. Tout le monde ne sera pas logé à la même enseigne puisqu’AWS ne pratique pas les mêmes tarifs horaires suivant les régions cloud. Par exemple, une même instance d’Aurora PostgreSQL sera plus chère à Francfort (EU-Central 1) qu’à Paris (EU-West-3). Ces deux instances sont plus coûteuses que la même tranche de calcul virtualisée en Virginie du Nord (US-East-1). Cette absence de tarification unifiée rendrait la gestion et le suivi des coûts difficiles, selon Gartner.

Rappelons que si l’entreprise cliente dépasse la limite du volume d’usage engagé, c’est le tarif de base qui s’applique.

Le géant du cloud n’ajoute pas seulement de nouveaux SKU à un catalogue déjà (trop) foisonnant. Il entend guider ses clients dans leur choix. La console de facturation et de gestion des coûts permet d’obtenir des recommandations de configuration des Database Saving Plans à partir de l’historique d’usage sur 7, 30 ou 60 jours. AWS met également à disposition ce qu’il a appelé le « Purchase Analyzer », un outil de simulation pour estimer les économies suivant l’historique, le nombre d’heures engagé ainsi que le type de déploiement et d’instances choisies.

L’offre semble plus adaptée aux clients dont les charges de travail sont prédictibles.

Abaisser les coûts de licence liés à RDS pour SQL Server

Les utilisateurs d’Amazon RDS pour Oracle et pour SQL Server, eux, ont le droit à de nouvelles options. D’abord, RDS for SQL Server prend désormais en charge les licences Developer Edition. Celles-ci sont gratuites pour les environnements de développement et de tests. En clair, les entreprises peuvent baisser les coûts de licence et ne payer que les coûts de calcul et de stockage liés au développement. Jusqu’alors, pour ces charges de travail, les clients devaient passer par les éditions Express, Web ou Standard suivant leur cas d’usage.

Par ailleurs, RDS pour SQL Server est déployable sur deux nouveaux types d’instances – M7i et R7i. Elles réduiraient jusqu’à 55 % les coûts par rapport aux machines M6i et R6i. AWS explique ces gains par le fait qu’il est possible de configurer le nombre de vCPU – et donc les coûts de licence, calculés au nombre de cœurs virtuels – en conservant la même quantité de RAM et d’IOPS.

« Cette amélioration est particulièrement utile pour les charges de travail des bases de données qui nécessitent une mémoire et des opérations d’entrée/sortie par seconde (IOPS) élevées, mais un nombre de vCPU plus faible », indique un porte-parole d’AWS dans un billet de blog.

Comment ? Le fournisseur maximise la quantité de mémoire vive par vCPU et désactive automatiquement l’hyperthreading des processeurs Intel Xeon Sapphire Rapids qui équipent ses serveurs.

Après le calcul, le stockage. Il est désormais possible d’attacher jusqu’à 256 téraoctets de stockage par instance de RDS Oracle ou SQL Server. Cette capacité en ajoutant jusqu’à trois volumes de stockage. Ici, pour optimiser les coûts, AWS propose deux types de volumes SSD : io 2 et gp3. Le premier est optimisé pour les accès fréquents et dépend de disques flash « hautes performances ». Le second est plus « efficient en coût » (gp3 ou General Purpose, à usage général). Les volumes gp3 peuvent atteindre 64 To et seraient environ 20 % moins chers que leur prédécesseur tout en étant plus performants.

Ces volumes peuvent être attachés ou détachés sans arrêter l’instance de base de données. Et AWS d’assurer que ce mécanisme est compatible avec les déploiements dans plusieurs zones de disponibilités.

Accélérer et optimiser l’indexation des vecteurs dans OpenSearch

Enfin, avec OpenSearch Service, une base de données open source forkée d’ElasticSearch, AWS assure optimiser les coûts des données vectorisées. Pour rappel, elles sont nécessaires afin de propulser les mécanismes d’IA générative augmentée par la recherche (RAG). Ceux-là alimentent les assistants IA des entreprises en données internes.

L’un des postes de dépense les plus importants en matière de recherche d’informations n’est autre que l’indexation. Ici, comme Qdrant et Elastic, AWS entend accélérer cette procédure en s’appuyant sur les GPU. Le fournisseur promet une indexation « jusqu’à dix fois plus rapide à un quart du prix ». Dans les faits, les parangonnages affichés par la filiale d’Amazon laissent entrevoir une indexation de 2,4 à 4 fois plus rapide suivant le volume de vecteurs et le nombre de dimensions qu’ils incluent. En faisant la moyenne entre la création de nouveaux index et la mise à jour d’index existants, l’accélération serait plutôt d’un facteur huit.

AWS facture uniquement le temps de traitement en fonction du nombre d’unités de calcul OpenSearch sollicitées (OCU). Par défaut, chaque OCU est dotée de 2vCPU, de 8 Go de RAM (CPU) et de 6 Go de VRAM (GPU). La parallélisation des index et la mise en place du sharding sont nécessaires pour profiter au mieux de ces capacités.

En outre, OpenSearch bénéficie d’une fonction d’optimisation automatisée de la vectorisation. Il est possible d’ingérer des vecteurs depuis Amazon S3, l’outil affine la configuration de ces types de données avant de les indexer. Les ingénieurs peuvent équilibrer la qualité de la recherche et sa vitesse, en fonction des attentes des métiers et du budget du projet.

Garder les clients

« Les entreprises sont soumises à une pression constante pour optimiser leurs budgets tout en développant leurs activités, en particulier dans un contexte économique incertain », déclare Stephen Catanzano, analyste chez Omdia, une filiale d’Informa TechTarget [propriétaire du MagIT]. « L’accent mis par AWS sur la réduction des coûts est important, car il répond directement à l’un des principaux problèmes des entreprises, à savoir la gestion des coûts sans sacrifier les performances ou l’évolutivité. », ajoute-t-il auprès de SearchDataManagement, une publication sœur du MagIT.

Cet effort n’est pas nouveau. Les porte-parole du groupe ne cessent d’affirmer qu’AWS baisse ses prix. Pourtant, selon les experts du secteur, le modèle OPEX du cloud implique une hausse constante de la facture.

Une pression tarifaire trop importante sur les entreprises pourrait impliquer une hausse du taux d’attrition. Les témoignages d’entreprises ayant réalisé un retour sur site ou migré vers un autre cloud ne sont pas légion, mais c’est une réalité. Un client satisfait est un client captif : d’où les optimisations proposées par le numéro 1 du secteur.

Si le géant du cloud multiplie les offres tarifaires pour s’assurer de l’engagement des clients, il n’a pas investi massivement sur l’interopérabilité, signale Stephen Catanzano.

« J’aimerais voir AWS se concentrer davantage sur la simplification des intégrations multicloud et cloud hybride », poursuit Stephen Catanzano. « Bien qu’AWS ait fait des progrès en matière d’optimisation des coûts et d’évolutivité, permettre une interopérabilité transparente avec d’autres fournisseurs de cloud et des systèmes sur site répondrait à un besoin croissant de flexibilité et aiderait les entreprises à éviter la dépendance vis-à-vis d’un seul fournisseur ».

D’où l’usage de plus en plus fréquents des services managés des éditeurs tiers. Ceux-là peuvent réduire l’adhérence aux services PaaS des fournisseurs cloud.