Pendant le développement, un scientifique des données utilise un notebook cloud pour exécuter des tâches légères d'ingénierie de fonctionnalités pendant les heures de bureau. Un ingénieur de données utilise le même notebook environ une fois par jour pour exécuter un prétraitement lourd et gourmand en mémoire (environ 2 heures) ; le prétraitement n'utilise pas de GPU. Actuellement, les deux s'exécutent sur une instance de notebook ml.m5.4xlarge à usage général. Le budget AWS mensuel a été dépassé. Quel changement permettra de réaliser les plus grandes économies de coûts ?

La bonne réponse est de changer le notebook pour une instance à usage général plus petite, de l'arrêter lorsqu'il est inactif, et d'exécuter le prétraitement des données en tant que job de traitement géré sur une instance r5 optimisée en mémoire avec une mémoire équivalente. Le notebook est principalement utilisé pour des tâches légères, donc une instance plus petite réduira les coûts. L'arrêter lorsqu'il est inactif est une bonne pratique pour économiser. Le prétraitement lourd et gourmand en mémoire est mieux géré par un job de traitement distinct sur une instance optimisée en mémoire (r5) qui peut être lancée et arrêtée à la demande, évitant ainsi de payer pour des ressources inutilisées sur le notebook principal. Les autres options sont moins optimales : Passer à une instance optimisée en mémoire pour le notebook est inutile pour les tâches légères et maintient une instance coûteuse active. Utiliser une instance accélérée par GPU pour le prétraitement est incorrect car le prétraitement n'utilise pas de GPU, ce qui entraînerait des coûts inutiles. Utiliser une instance réservée pour le prétraitement n'est pas idéal car le prétraitement est exécuté sporadiquement (une fois par jour), ce qui ne justifie pas l'engagement à long terme d'une instance réservée.