Tarification d’Amazon EMR

La tarification concerne les applications Amazon EMR exécutées sur des clusters Amazon EMR avec des instances Amazon EC2.

Le tarif d'Amazon EMR s'ajoute au tarif d'Amazon EC2 (prix des serveurs sous-jacents) et à celui d'Amazon Elastic Block Store (Amazon EBS) (si des volumes Amazon EBS sont joints). Ces prix sont également facturés à la seconde avec un forfait d'une minute minimum. De nombreuses options de tarification EC2 vous sont proposées, notamment les instances à la demande (présentées ci-après), les instances réservées pour un et trois ans, les Capacity Savings Plans et les instances Spot. Les instances Spot sont une capacité EC2 inutilisée et sont disponibles avec une remise pouvait atteindre 90 % par rapport aux tarifs à la demande. Découvrez les économies liées aux instances Spot par rapport aux instances à la demande en utilisant le filtre « Instance types supported by EMR » (Types d'instance pris en charge par EMR) sur la page Spot Instance Advisor.

Cette tarification concerne Amazon EMR sur les clusters Amazon EKS.

La tarification d'Amazon EMR s'ajoute à la tarification d'Amazon EKS ou à tout autre service utilisé avec EKS. Vous pouvez exécuter EKS sur AWS soit avec EC2 soit avec AWS Fargate. Si vous utilisez EC2 (y compris avec les groupes de nœuds gérés EKS), vous payez les ressources AWS (par ex. les instances EC2 ou les volumes EBS) que vous créez pour exécuter vos composants master Kubernetes. Consultez la tarification détaillée sur la page de tarification EC2. Si vous utilisez AWS Fargate, la tarification est calculée en fonction des ressources de vCPU et de mémoire utilisées entre le moment où vous commencez à télécharger votre image de conteneur et celui où le pod EKS prend fin, à la seconde près. Un montant minimal équivalent à une minute d'utilisation s'applique. Consultez la tarification détaillée sur la page de tarification AWS Fargate.

La tarification d'Amazon EMR sur Amazon EKS est calculée en fonction des ressources de vCPU et des ressources de mémoire utilisées entre le moment où vous commencez à télécharger votre image d'application EMR et celui où le pod EKS prend fin, à la seconde près. La tarification se base sur les ressources vCPU et les ressources de mémoire nécessaires à la tâche ou au pod.

La tarification d'Amazon EMR sur AWS Outposts est la même que pour les instances cloud d'EMR. Consultez la page de tarification AWS Outposts pour plus d'informations sur la tarification d'AWS Outposts.

Avec EMR Serverless, il n'existe aucun coûts initial et vous ne payez que les ressources que vous utilisez. Vous payez la quantité de ressources vCPU, mémoire et de stockage consommée par vos applications.

Avec EMR Serverless, vous créez une application en utilisation une version de cadre open source, puis vous soumettez les tâches à l'application. Dans le cadre de la spécification des tâches, vous pouvez indiquer le nombre minimum et maximum de subordonnées simultanées, ainsi que les ressources de vCPU, de mémoire et de stockage pour chaque programme exécutant. EMR ajoute et supprime automatiquement des subordonnées en fonction des exigences de la tâche dans vos limites spécifiées. Les trois dimensions de calcul, de mémoire et de stockage pour les subordonnées peuvent être configurées de manière indépendante. Vous pouvez choisir entre 1 vCPU, 2 vCPU, 4 vCPU, 8 vCPU ou 16 vCPU par subordonnée, une mémoire de 2 Go à 120 Go par subordonnée par incréments de 1 Go à 8 Go, et un stockage de 20 Go à 200 Go.

Vous êtes facturé pour les ressources vCPU, de mémoire et de stockage agrégées utilisée à partir du moment où les subordonnées sont prêtes à exécuter votre charge de travail jusqu'au moment où elles arrêtent. La durée est arrondie à la seconde la plus proche, avec un minimum d'une minute. Si vous configurez votre application pour démarrer les subordonnées au démarrage de l'application, les subordonnées demandées commenceront lorsque vous démarrez votre application et s'arrêteront lorsque vous arrêtez l'application, ou lorsque celle-ci reste inactive.

Informations de tarification (calcul et mémoire)

La tarification est basée sur les ressources vCPU, de mémoire et de stockage utilisées par les subordonnées, agrégées entre toutes les subordonnées.

Informations de tarification (magasin éphémère)

Par défaut, 20 Go de magasin éphémère sont disponibles pour toutes les subordonnées. Vous payez uniquement le stockage supplémentaire que vous configurez par subordonnée.

Configurations de subordonnées prises en charge

Durée

La durée est calculée à partir du moment où une subordonnée est prête à exécuter votre charge de travail jusqu'au moment où elle arrête. La durée est arrondie à la seconde la plus proche, avec un minimum d'une minute.

Frais supplémentaires

Des frais supplémentaires peuvent vous être facturés si vos applications utilisent d'autres services AWS. Par exemple, si votre application utilise Amazon Simple Storage Service (S3) pour stocker et traiter les données, alors vous serez facturé aux tarifs standard Amazon S3. Si vous déplacez les données à partir de différentes sources, comme Amazon Simple Storage Service (S3), Amazon Relational Database Service (RDS) ou Amazon Redshift, les tarifs standard de requêtes et de transferts de données vous sont facturés. Si vous utilisez Amazon CloudWatch, les taux standard vous sont facturés pour les journaux et les événements CloudWatch.

Cette tarification s'applique à Amazon EMR sur des clusters EC2 avec des applications Apache HBase utilisant Amazon EMR WAL. Apache HBase Write Ahead Log permet d'enregistrer toutes les modifications apportées aux données dans un stockage basé sur des fichiers. Avec Amazon EMR sur EC2, vous pouvez écrire vos journaux d'écriture anticipée Apache HBase dans le WAL Amazon EMR, une couche de stockage gérée durable qui dure plus longtemps que votre cluster. Si votre cluster, ou dans les rares cas où la zone de disponibilité devient défectueuse ou indisponible, vous pouvez créer un nouveau cluster, le diriger vers le même répertoire racine Amazon S3 et l'espace de travail Amazon EMR WAL, et récupérer automatiquement les données dans WAL en quelques minutes. Pour plus d'informations, consultez la documentation Amazon EMR WAL. 

Vous payez en fonction de votre utilisation de l'EMR WAL. Si vous avez un cluster actif configuré pour utiliser le WAL, vous serez facturé pour le stockage EMR WAL sur la base de l'utilisation facturée en heures EMR-WAL-WALHours, en écritures en WriteRequestGiB et en lectures en ReadRequestGiB.

EMR-WAL-WALHours : EMR WAL créera un WAL par région Apache HBase. Après l'arrêt de votre cluster, s'il reste des données dans EMR WAL qui n'ont pas été transférées sur Amazon S3, vous pouvez soit récupérer les données en lançant un cluster de récupération, soit choisir de nettoyer le WAL en créant un cluster temporaire et en utilisant le EMR WAL CLI pour supprimer les ressources EMR WAL. Si vous ne supprimez pas explicitement les données EMR WAL, EMR WAL les conservera et vous facturera les données non supprimées pendant 30 jours. Vous pouvez consulter l'exemple ci-dessous.

ReadRequestGiB et WriteRequestGiB : ces deux dimensions concernent les demandes de lecture et d'écriture. Les appels d'API Apache HBase pour écrire des données dans votre table sur un cluster avec EMR WAL sont facturés comme WriteRequestGiB. Les écritures EMR WAL se produiront pour toutes les écritures Apache HBase, telles que Opérations `Put`. Les appels d'API Apache HBase pour lire les données de votre WAL EMR pendant les opérations de restauration d'Apache HBase sont facturés comme ReadRequestGiB. Les lectures et les écritures sont facturées en fonction de la taille des articles et des factures EMR à un minimum de 1 octet.

Tarification basée sur la tarification US-East-1.

Supposons que vous exécutez une application Amazon EMR déployée sur Amazon EC2, et que vous utilisez une instance EC2 c4.2xlarge comme nœud maître et deux instances EC2 c4.2xlarge comme nœuds principaux. Vous serez facturé à la fois pour les nœuds EMR et les nœuds EC2. Pour un mois d'utilisation, avec une utilisation de 100 % au cours de ce mois, et en utilisant la tarification à la demande pour EC2, vous serez facturé :

Nœud maître :

frais EMR = 1 instance x 0,105 USD par heure x (100/100 utilisation/mois) x 730 heures dans un mois = 76,65 USD (coût du nœud maître EMR)frais EC2 = 1 instance x 0,398 USD par heure x 730 heures dans un mois = 290,54 USD (coût du nœud maître EC2)

Nœuds principaux :

frais EMR = 2 instances x 0,105 USD par heure x (100/100 utilisation/mois) x 730 heures dans un mois = 153,30 USD (coût des nœuds principaux EMR)

frais EC2 = 2 instances x 0,398 USD par heure x 730 heures dans un mois = 581,08 USD (coût des nœuds principaux EC2)

Total des frais = 76,65 USD + 290,54 USD + 153,30 USD + 581,08 USD = 1101,57 USD

Tarification basée sur la tarification US-East-1.

Supposons que vous exécutez une application Amazon EMR-Spark déployée sur Amazon EKS. Dans ce cas, EKS obtient sa capacité de calcul à l'aide d'instances EC2 r5.2xlarge (8 vCPU, 64 Go de RAM). Supposons que le cluster EKS a 100 nœuds, pour un total de 800 vCPU et 6 400 Go de mémoire. Supposons que cette application utilise 100 vCPU et 300 Go de mémoire pendant 30 minutes.

Total des frais Amazon EMR pour la tâche :

Total des frais de vCPU = (100 * 0,01012 USD * 0,5) = (nombre de vCPU * taux par heure vCPU * exécution de la tâche en heures) = 0,506 USD       

Total des frais de mémoire = (300 * 0,00111125 USD *0,5) = (quantité de mémoire utilisée * taux par Go-heure * exécution de la tâche en heures) = 0,1667 USD       

Total des frais EMR pour la tâche EMR = 0,6727 USD

Coûts supplémentaires

Vous payez 0,10 USD par heure pour chaque cluster Amazon EKS que vous créez. Vous pouvez utiliser un seul cluster Amazon EKS pour exécuter plusieurs applications en tirant parti des espaces de noms Kubernetes et des stratégies de sécurité IAM. Vous pouvez exécuter EKS sur AWS soit avec Amazon EC2 soit avec AWS Fargate.

Si vous utilisez Amazon EC2 (notamment avec les groupes de nœuds gérés Amazon EKS), vous payez les ressources AWS (par ex. les instances EC2 ou les volumes Amazon EBS) que vous créez pour exécuter vos composants master Kubernetes. Vous ne payez que ce que vous utilisez, au moment où vous l'utilisez. Il n'y a pas de frais minimums et aucun engagement initial n'est requis. Consultez la tarification détaillée sur la page de tarification EC2.

Si vous utilisez AWS Fargate, la tarification est calculée en fonction des ressources de vCPU et de mémoire utilisées entre le moment où vous commencez à télécharger votre image de conteneur et celui où le pod Amazon EKS prend fin, à la seconde près. Un montant minimal équivalent à une minute d'utilisation s'applique. Consultez la tarification détaillée sur la page de tarification AWS Fargate.

Supposons que vous soumettez une tâche Spark à EMR Serverless. Imaginons que la tâche est configurée pour utiliser un minimum de 25 subordonnées et un maximum de 75 subordonnées, chacune configurée avec 4 vCPU et 30 Go de mémoire. Considérons qu'aucun magasin éphémère supplémentaire n'ait été configuré. Si votre tâche s'exécute pendant 30 minutes à l'aide de 25 subordonnées (ou 100 vCPU) et était automatiquement mise à l'échelle pour ajouter 50 subordonnées supplémentaires (200 vCPU supplémentaires) pendant 15 minutes :

Total des frais par heure vCPU = (100 * 0,052624 USD * 0,5) + (200 * 0,052624 USD * 0,25) = (nombre de vCPU * taux par heure vCPU * exécution de la tâche en heures) = 5,2624 USD

Total des Go-heures = (750 * 0,0057785 USD * 0,5) + (1500 * 0,0057785 USD * 0,25) = (Total de Go de mémoire configuré * taux par Go-heure * exécution de la tâche en heures) = 4,333875 USD

Total des frais EMR Serverless = 9,596275 USD

Frais supplémentaires : si votre application utilise d'autres services AWS tels qu'Amazon S3, les tarifs S3 standard vous sont facturés.

Supposons que vous créiez un nouveau cluster Amazon EMR avec Apache HBase et que vous choisissiez de sauvegarder entièrement votre cluster dans la région USA Est (Virginie du Nord). Comme il s'agit d'une nouvelle application, vous ne savez pas quelles seront vos modèles de trafic. Pour simplifier, supposons que votre utilisateur a créé 10 tables HBase, y compris des tables système, 2 régions HBase par table, et que chaque fois qu'un utilisateur interagit avec votre application, il écrit 1 Ko de données. 

Pendant une période de 10 jours, vous recevez peu de trafic vers votre application, ce qui se traduit par 10 000 écritures par jour. Cependant, le 11e jour, le trafic de votre application atteint 2 500 000 écritures ce jour-là. Vous décidez également de mettre à jour simultanément votre code personnalisé sur votre cluster et de prévoir une interruption nocturne programmée pour vos utilisateurs finaux le jour 11. Supposons que cela entraîne 1 000 000 de lectures depuis le WAL EMR pour les opérations de restauration HBase. Votre application se met à l'échelle pour offrir une expérience transparente à vos utilisateurs. Votre application reçoit alors un modèle de trafic plus régulier de 50 000 écritures chaque jour jusqu'à la fin du mois. 

Le tableau suivant résume votre utilisation totale pour le mois.

Pour le mois, votre facture sera de 26,52 USD, un total qui comprend 0,38 USD pour ReadRequestGiB et WriteRequestGiB, et 25,92 USD pour EMR-WAL-WALHours.