Comment Bedrock Streaming optimise ses couts AWS

L’optimisation des coûts d’hébergement AWS représente un défi majeur pour les entreprises de streaming vidéo et d’hébergement d’API. Cette problématique s’intensifie avec l’augmentation constante du trafic et la complexité croissante des plateformes. Les organisations peuvent réaliser des économies importantes en adoptant une approche FinOps structurée qui transforme chaque décision technique en opportunité d’optimisation. 

Bedrock Streaming illustre parfaitement cette approche. L’entreprise héberge ses plateformes sur AWS pour alimenter des diffuseurs européens majeurs comme M6+, Videoland ou RTL+. Avec un budget AWS de plusieurs millions de dollars par an, chaque pourcentage d’optimisation génère des économies considérables. La maîtrise des coûts se complique par la charge variable quotidienne. Les pics de trafic fluctuent selon les heures de diffusion d’événements sportifs et d’émissions populaires. 

Pour répondre à ces enjeux, Bedrock Streaming a développé, depuis le début de sa migration vers AWS en 2018, une approche qui dépasse les stratégies traditionnelles de réservations. Bedrock Streaming applique une stratégie FinOps multi-axe : utilisation d’instances Amazon Elastic Compute Cloud (Amazon EC2) Spot pour 100% des worker nodes Kubernetes, exploitation des processeurs AWS Graviton, rationalisation des appels d’API AWS, optimisation des flux vidéo ou encore une attention constante aux stockages de données. Cette démarche FinOps, portée par les équipes de Bedrock Streaming, transforme chaque décision technique en levier d’optimisation des couts cloud. 

Optimisation du compute et des services managés 

Bedrock Streaming optimise ses couts de compute AWS par 2 stratégies principales.

Premièrement, l’entreprise déploie des réservations d’instances pour les services managés Amazon Relational Database Service (Amazon RDS), Amazon Elasticache et Amazon OpenSearch Service et des réservations de capacité pour Amazon DynamoDB. Les Savings Plans représentent moins de 5% de l’utilisation d’EC2, couvrant également les services AWS Lambda et AWS Fargate. 

Deuxièmement, le ciblage spécifique Amazon EC2, où les instances Spot remplacent les réservations traditionnelles. Cette approche répond aux besoins d’auto-scaling de Bedrock Streaming, dont le trafic fluctue d’un facteur 10 entre les heures creuses du matin et les pics du soir. L’infrastructure de production, incluant les worker nodes Kubernetes, fonctionne sur des instances Spot avec basculement automatique vers des instances on-demand lors des périodes de capacité Spot limitée. Ces basculements restent rares en production. 

AWS peut récupérer les instances Spot à tout moment avec un préavis de 2 minutes. Bedrock Streaming a donc mis en place un termination handler qui se déclenche lorsqu’une instance signale sa récupération imminente. Ce gestionnaire démarre immédiatement une nouvelle instance tout en arrêtant proprement les applications sur l’ancien nœud.

L’équipe réduit le temps de démarrage des nouvelles instances grâce à des Amazon Machine Images (AMI) personnalisées intégrant les composants Kubernetes et les images Docker de base requises. L’utilisation de plus de 10 types d’instances dans chacune des 3 zones de disponibilité (Availability Zone : AZ) maximise la disponibilité. Bedrock Streaming atteint ainsi régulièrement 100% d’instances Spot pour ses worker-nodes Kubernetes.

Figure : Couts Amazon EC2 pour les noeuds Kubernetes – Les couts en « Saving Plans » correspondent majoritairement aux master nodes.

Pour les services managés comme Amazon RDS, Amazon Elasticache ou Amazon OpenSearch, dont l’élasticité ne correspond pas aux besoins spécifiques, les équipes suivent une approche pragmatique. Elles commencent par déployer leurs nouveaux projets avec des instances surdimensionnées, analysent leurs comportements sous charge réelle pendant quelques jours, puis redimensionnent à la taille optimale. Le surcout est mineur et cette méthode mène rapidement au cout optimal, tout en évitant les risques de sous-dimensionnement. Les éventuelles réservations sont effectuées plus tard, lors de passes globales semestrielles.

Figure : Nouveau projet utilisant Amazon OpenSearch : des instances surdimensionnées pendant quelques jours, puis dimensionnement en fonction des besoins réels.

L’adoption des processeurs AWS Graviton constitue un autre pilier d’optimisation efficace. Les équipes ont commencé par migrer quelques jobs Amazon EMR. Les économies les plus importantes sont venues de la migration de toutes les instances Amazon RDS, Amazon ElastiCache et Amazon OpenSearch Service vers AWS Graviton, générant 15% à 20% d’économies avec une simple modification de configuration. La migration des nœuds Kubernetes non-Spot vers AWS Graviton représente la dernière étape de cette optimisation.

Optimisation des services de données et de stockage

Le stockage avec Amazon Simple Storage Service (Amazon S3) constitue le socle de l’infrastructure de Bedrock Streaming pour l’hébergement de sa bibliothèque vidéo. L’entreprise exploite les fonctionnalités avancées de S3 : classes de stockage différenciées, politiques de transition automatique, Intelligent Tiering pour les buckets à usage variable, et gestion automatisée du cycle de vie des objets.

La gestion efficace du stockage s’étend au-delà d’Amazon S3. Le stockage cloud semble infini, mais vous devez surveiller l’accumulation des ressources. Cela implique entre autres un suivi rigoureux des AMIs obsolètes et des snapshots non utilisés.

L’expérience de Bedrock Streaming avec Amazon Elastic Container Registry (Amazon ECR) illustre cette problématique. Lors de sa migration vers AWS et Kubernetes, les couts Amazon ECR de l’entreprise ont augmenté significativement en raison de l’accumulation d’images Docker générées par les déploiements quotidiens. L’activation de la fonctionnalité de purge automatique des images anciennes dans ECR a permis à Bedrock Streaming de maîtriser ces couts :

Figure : Optimisation automatique des images obsolètes sur Amazon ECR : impact sur les coûts de stockage

Amazon DynamoDB fait partie des solutions retenues par Bedrock Streaming pour ses charges de travail critiques. L’optimisation des couts de DynamoDB repose sur deux axes principaux : la gestion des requêtes et le stockage des données. Ce dernier représente un levier majeur dans la maîtrise des couts.

L’entreprise a identifié que le stockage de certaines tables générait des couts supérieurs à ceux des requêtes. Pour résoudre cette problématique, Bedrock Streaming utilise la fonctionnalité TTL (Time To Live) d’Amazon DynamoDB, permettant l’expiration automatique des données obsolètes. Cette approche optimise non seulement les couts de stockage directs, mais réduit également les couts associés aux sauvegardes des tables.

Figure : Optimisation des coûts DynamoDB – L’importance du dimensionnement des données

Pour les tables DynamoDB contenant un volume important de données rarement consultées, la classe de stockage Standard-IA représente une option d’optimisation pertinente. Cette classe devient particulièrement avantageuse lorsque les couts de stockage d’une table dépassent 50% des couts liés aux opérations de lecture et d’écriture.

Optimisation des couts réseau

L’optimisation des couts réseau constitue un axe majeur chez Bedrock Streaming. L’entreprise a d’abord implémenté des VPC endpoints pour Amazon S3 et Amazon DynamoDB. Cette configuration élimine les transferts de données via les passerelles NAT et réduit significativement les coûts sur les services à fort volume de trafic.

L’entreprise optimise également ses couts de transferts Inter-AZ par des évolutions architecturales ciblées. La plateforme de diffusion de vidéos à la demande illustre cette démarche. Sa première version, déployée sur trois zones de disponibilité, impliquait des transferts de segments vidéo entre les zones. La nouvelle architecture adopte une approche zone-unique : chaque requête est traitée intégralement dans sa zone de disponibilité d’entrée, éliminant les transferts de données Inter-AZ.

Figure : Optimisation des coûts de transfert Inter-AZ suite à une refonte architecturale

Cette nouvelle architecture maintient le même niveau de résilience que la précédente. La différence réside dans son mode de fonctionnement : plutôt qu’une gestion de requêtes répartie sur trois zones, la plateforme traite désormais chaque requête intégralement dans sa zone d’entrée. Cette approche élimine les couts de transferts inter-AZ tout en préservant la haute disponibilité. Bedrock Streaming détaille cette transformation architecturale dans un article dédié.

Des aspects méconnus de l’optimisation des couts

Optimisation des couts API AWS

Alors que son déploiement sur AWS progressait en 2018-2019, Bedrock Streaming a identifié des couts imprévus sur certains projets. Un cas significatif concernait une API de téléchargement d’images stockées sur S3, où les couts d’API dépassaient ceux du stockage.

Figure : Optimisation des coûts S3 : l’effet d’une mise en cache des images

L’analyse du code a révélé que l’API effectuait des vérifications d’existence pour chaque niveau d’arborescence des chemins d’accès aux fichiers, une opération superflue dans l’environnement S3. La suppression de ces vérifications au profit d’un accès direct aux images, avec gestion des erreurs 404 en cas d’échec, a permis d’obtenir trois bénéfices : maintien de la fonctionnalité initiale, réduction de la latence et optimisation des couts d’API.

L’utilisation d’Amazon Simple Queue Service (SQS) constitue un autre cas d’optimisation significatif. En adoptant une approche de traitement groupé des messages plutôt qu’un traitement unitaire, Bedrock Streaming a réduit de 66% ses couts liés aux opérations de suppression :

Figure : Réduction des coûts Amazon SQS grâce au traitement groupé des messages

L’implémentation retenue privilégie des lots de 3 messages en moyenne. Bien qu’Amazon SQS permette de traiter jusqu’à 10 messages par lot, cette configuration représente un équilibre optimal entre réduction des couts et maintien des performances de latence.

Gestion des logs et des métriques

Bedrock Streaming privilégie une approche centralisée pour la surveillance de ses métriques. Plutôt que d’utiliser directement la console Amazon CloudWatch, l’entreprise a mis en place un système d’exportation des métriques vers une stack Prometheus. Cette exportation s’effectue via un exporter dédié qui interroge périodiquement les API GetMetricStatistics et GetMetricData d’Amazon CloudWatch.

Initialement, l’exporter collectait un large éventail de métriques, dans une optique de précaution. Après une période d’évaluation, Bedrock Streaming a optimisé la configuration en alignant précisément les métriques collectées avec celles effectivement utilisées dans Grafana. Cette rationalisation a permis de diviser par deux et demi le cout des appels d’API.

Figure : Optimisation des coûts par la rationalisation des appels API CloudWatch

La gestion des logs représente un autre axe d’optimisation des couts chez Bedrock Streaming. L’entreprise applique une double stratégie : la rationalisation des informations collectées et l’implémentation d’une politique de rétention adaptée. Pour les logs nécessitant une conservation prolongée, notamment pour la conformité, CloudWatch Logs Infrequent Access permet une réduction jusqu’à 50% des couts d’ingestion et de stockage.

Compréhension de fonctionnement des services AWS

L’optimisation des couts nécessite une compréhension approfondie des spécificités de chaque service AWS, tant au niveau fonctionnel que financier. AWS Step Functions illustre particulièrement ce principe. En optant pour le mode Express plutôt que le mode Standard par défaut, Bedrock Streaming a significativement réduit l’impact financier de ce service dans l’un de ses projets de workflows.

Figure : Analyse comparative des coûts : Step Functions Express vs Standard

L’optimisation des couts d’Amazon DynamoDB repose sur une sélection judicieuse du mode de capacité pour chaque table. 2 options principales sont considérées :

1. Le mode on-demand s’adapte aux tables avec un trafic très variable et imprévisible
2. Le mode provisionné avec auto-scaling convient mieux aux tables dont le trafic évolue de manière plus prévisible

Le choix entre ces 2 modes s’effectue table par table, en fonction des caractéristiques spécifiques de chaque charge de travail. Le mode provisionné offre un avantage supplémentaire : la possibilité d’effectuer des réservations de capacité, permettant des réductions de couts additionnelles sur le long terme.

Cette approche granulaire permet à Bedrock Streaming d’optimiser ses couts DynamoDB en alignant précisément les ressources avec les besoins réels de chaque table.

Figure : Optimisation des coûts Amazon DynamoDB par transition vers le mode provisionné (pré-2024)

Note importante : Cette analyse des couts date d’avant novembre 2024. La réduction des tarifs on-demand de 50% depuis cette date modifie significativement l’écart de couts entre les deux modes, rendant la comparaison moins pertinente pour ce cas d’usage spécifique.

Bedrock Streaming suit une méthodologie éprouvée pour ses nouveaux projets Amazon DynamoDB. L’entreprise démarre systématiquement avec le mode on-demand pour garantir la performance et la stabilité des applications. Après observation de quelques jours et l’analyse des patterns d’utilisation, les tables sont évaluées pour une potentielle migration vers le mode provisionné lorsque celui-ci présente un avantage économique.

Cette approche s’inscrit dans une stratégie plus large de gestion optimisée des services AWS. Elle repose sur trois piliers essentiels :

• Une veille continue sur la documentation et les nouveautés AWS
• Un monitoring régulier des dépenses
• Une capacité d’ajustement rapide des configurations

Une approche technique et culturelle de l’optimisation des couts

L’optimisation des couts AWS doit s’inscrire dans une réflexion globale sur le retour sur investissement (ROI) de l’infrastructure. L’objectif est d’atteindre un équilibre optimal entre les couts et la réponse aux besoins opérationnels. Bedrock Streaming illustre cette approche en limitant l’utilisation des instances EC2 de la famille T (performance à capacité extensible) en production, privilégiant la stabilité des performances malgré un coût plus élevé.

La démarche d’optimisation doit également prendre en compte le rapport entre le temps investi et les économies réalisées. Une analyse coût-bénéfice rigoureuse est essentielle pour s’assurer que les efforts d’optimisation génèrent une valeur ajoutée significative pour l’entreprise.

Bedrock Streaming a mis en place une stratégie de suivi et d’optimisation des couts basée sur trois outils complémentaires :

1. AWS Cost Explorer : utilisé depuis plusieurs années pour l’analyse détaillée des dépenses.
2. AWS Cost Anomaly Detection : un système basé sur le Machine Learning qui alerte rapidement en cas de variations imprévues des couts.
3. AWS Cost Optimization Hub : offre une vue centralisée des opportunités d’optimisation.

Cette approche multidimensionnelle permet à Bedrock Streaming de maintenir un contrôle continu sur ses dépenses AWS tout en assurant la performance et la fiabilité de ses services.

Figure : Alerte de Cost Anomaly Detection pour Step Functions (juillet 2024).

Au-delà des outils gérés par les équipes infrastructure, comme les réservations et les Saving Plans, l’optimisation des couts exige que toutes les équipes et tous les métiers intègrent que les couts d’hébergement font partie de leur périmètre et de leurs responsabilités. En termes d’outillage, cela passe par faire remonter les couts AWS, obtenus via les fichiers AWS Cost and Usage Reports (AWS CUR), dans l’outil de Business Intelligence utilisé par toute l’entreprise pour suivre ses métriques métiers. L’accès facilité aux données financières favorise l’implication et la prise de décision à tous les niveaux de l’organisation.

Enfin, l’optimisation s’inscrit dans un processus d’amélioration continue qui dépasse la simple réduction des factures. Des revues régulières identifient de nouvelles opportunités d’optimisation. Et, par-dessus tout, comme le souligne la Fondation FinOps, la prise en compte des futurs couts d’infrastructure dès le début du cycle de vie des projets est nécessaire pour les optimiser au maximum.

Conclusion

En combinant 100% d’instances EC2 Spot pour les worker nodes Kubernetes, exploitation des processeurs Graviton et optimisation fine des services de données comme DynamoDB, Bedrock Streaming réalise des économies substantielles sur un budget cloud de plusieurs millions de dollars par an. Les techniques implémentées dépassent les approches traditionnelles de réservation d’instances, puisqu’elles incluent aussi la rationalisation des appels d’API AWS, l’optimisation des transferts inter-AZ, et l’utilisation intelligente des classes de stockage.

Pour aller plus loin et réaliser des économies plus larges, il faut intégrer les questions de couts dès la phase de conception des fonctionnalités et projets. Bedrock Streaming déploie donc une culture FinOps où chaque équipe devient actrice à l’optimisation des couts tout au long du cycle de vie des composants de sa plateforme. Les coûts d’infrastructure deviennent alors un levier stratégique qui guide les choix technologiques plutôt qu’une simple contrainte.

Ces stratégies d’optimisation s’adaptent à de nombreux secteurs d’activité. Quel que soit votre profil de charge, vous pouvez activer plusieurs leviers d’optimisation. L’utilisation stratégique des instances Amazon EC2 Spot, la rationalisation des appels aux API AWS, l’adaptation des modes de capacité Amazon DynamoDB selon vos usages, et l’exploitation optimale des fonctionnalités spécifiques de chaque service AWS constituent autant d’opportunités.

La méthodologie recommandée consiste à prioriser les optimisations en fonction de leur impact financier potentiel, puis à procéder par itérations successives pour affiner les résultats.

Pour approfondir ces concepts, nous vous invitons à visionner la session complète délivrée lors de l’AWS Summit Paris 2025 où Pascal Martin de B détaille chaque optimisation avec des exemples concrets. Consultez également AWS Cost Optimization Hub pour identifier vos propres opportunités d’économies, et explorez AWS Cost Explorer pour analyser vos patterns de consommation.

Commencez votre propre parcours d’optimisation en activant AWS Cost Anomaly Detection dès aujourd’hui – comme le démontre Bedrock Streaming, chaque point de pourcentage d’optimisation compte.