Diese Preise gelten für Amazon-EMR-Anwendungen, die auf Amazon-EMR-Clustern mit Amazon-EC2-Instances ausgeführt werden.

Der Amazon-EMR-Preis gilt zusätzlich zum Amazon-EC2-Preis (der Preis für die zugrunde liegenden Server) und zum Amazon-Elastic-Block-Store (Amazon EBS)-Preis (wenn Amazon EBS-Volumes angefügt werden). Auch diese werden sekundengenau, mit einem Minimum von einer Minute, in Rechnung gestellt. Sie können aus einer Vielzahl von EC2-Preisoptionen wählen, einschließlich On-Demand-Angeboten (siehe unten), Reserved-Instances mit ein- und dreijähriger Laufzeit, Capacity Savings Plans sowie Spot-Instances. Bei Spot-Instances handelt es sich um eine freie EC2-Kapazität, die zu einem Preisnachlass von bis zu 90 % im Vergleich zu On-Demand-Preisen verfügbar ist. Sehen Sie sich Preiseinsparungen für Spot-Instances gegenüber On-Demand an, indem Sie auf der Seite „Spot Instance Advisor“ nach „Von EMR unterstützte Instance-Typen“ filtern.

Diese Preise gelten für Amazon EMR auf Amazon-EKS-Clustern.

Der Preis für Amazon EMR gilt zusätzlich zu den Preisen für Amazon EKS oder andere Services, die mit EKS genutzt werden. Sie können EKS auf AWS entweder mit EC2 oder AWS Fargate ausführen. Wenn Sie EC2 (einschließlich mit verwalteten EKS-Knotengruppen) verwenden, bezahlen Sie für AWS-Ressourcen (z. B. EC2-Instances oder EBS-Volumes), die Sie zur Ausführung Ihrer Kubernetes-Worker-Knoten erstellen. Detaillierte Preisinformationen finden Sie auf der Preisseite für EC2. Wenn Sie AWS Fargate benutzen, werden die Preise anhand der vCPU- und Arbeitsspeicherressourcen berechnet, die für die Zeitdauer des Container-Image-Downloads verwendet werden, bis der EKS-Pod beendet wird, aufgerundet auf die nächste Sekunde. Es wird immer mindestens 1 Minute berechnet. Detaillierte Preisinformationen finden Sie auf der Preisseite für AWS Fargate.

Die Preise für Amazon EMR auf Amazon EKS werden auf der Grundlage der vCPU- und Speicherressourcen berechnet, die vom Zeitpunkt des Beginns des Downloads Ihres EMR-Anwendungsimages bis zur Beendigung des EKS Pods verwendet werden, aufgerundet auf die nächste Sekunde. Die Preise basieren auf der angeforderten vCPU und den Speicherressourcen für die Aufgabe oder den Pod.

Amazon EMR bei AWS-Outposts-Preisen entspricht den cloudbasierten-Instances von EMR. Weitere Details zu AWS-Outposts-Preisen finden Sie auf der AWS Outposts Preisseite.

Bei EMR Serverless fallen keine Vorabkosten an und Sie zahlen nur für die genutzten Ressourcen. Sie zahlen für die vCPU-, Arbeitsspeicher- und Speicherressourcen, die Ihre Anwendungen verbrauchen.

Mit EMR Serverless können Sie Anwendungen unter Verwendung einer Open-Source-Frameworkversion erstellen und Aufträge an die Anwendung übertragen. Im Rahmen der Auftrags-Spezifikation können Sie außerdem ein Minimum und ein Maximum gleichzeitiger Worker, sowie Minimum und Maximum der von genutzter vCPU-Kapazität, Arbeitsspeicher und Speicher für jeden Worker definieren. EMR fügt automatisch Worker hinzu oder entfernt sie wieder, je nachdem was die Anforderungen des Auftrags im von Ihnen spezifizierten Rahmen sind. Die drei Dimensionen Rechenleistung, Arbeitsspeicher und Speicher für Worker können unabhängig voneinander konfiguriert werden. Sie können zwischen 1 vCPU, 2 vCPU, 4 vCPU, 8 vCPU und 16 vCPU pro Worker, Arbeitsspeicher von 2 GB bis 120 GB pro Worker in Schritten von 1 GB bis 8 GB wählen. Für Speicheroptionen können Sie zwischen 20 GB und 200 GB pro Worker als Standardspeicher wählen oder zwischen 20 GB und 2 TB pro Worker für die Zufallswiedergabe optimierten Speicher wählen.

Ihnen werden aggregierte vCPU, Arbeitsspeicher und Speicher-Ressourcen von Beginn der Ausführung des Workloads bis zu seinem Abschluss in Rechnung gestellt. Diese Zeit wird dabei auf eine Sekunde aufgerundet, beträgt jedoch minimal eine Minute. Wenn Sie ihre Anwendung so einrichten, dass Worker bei Beginn der Anwendung starten, starten die Worker, wenn Sie ihre Anwendung starten und werden beendet, wenn sie die Anwendung stoppen oder die Anwendung nicht arbeitet.

Preisdetails (Computing und Arbeitsspeicher)

Die Preise basieren auf den aggregierten vCPU-, Arbeitsspeicher- und Speicherressourcen, die von allen aggregierten Workern verwendet wurden.

Preisdetails (flüchtiger Speicher)

Standardspeicher: Die ersten 20 GB flüchtiger Speicher stehen standardmäßig für alle Worker zur Verfügung – Sie zahlen nur für zusätzlichen Speicher, den Sie pro Worker konfigurieren.

Zufallswiedergabe-optimierter Speicher: Sie zahlen für den gesamten konfigurierten Speicher pro Worker, einschließlich der ersten 20 GB.

Unterstützte Worker-Konfigurationen

Dauer

Die Dauer wird ab dem Zeitpunkt berechnet, an dem ein Worker bereit ist, Ihre Workload auszuführen, bis zu dem Zeitpunkt, an dem er stoppt, aufgerundet auf die nächste Sekunde mit einem Minimum von 1 Minute.

Zusätzliche Gebühren

Es können Ihnen zusätzliche Gebühren entstehen, wenn Ihre Anwendungen andere AWS-Services nutzen. Wenn Ihre Anwendung beispielsweise Amazon Simple Storage Service (S3) zum Speichern und Verarbeiten von Daten verwendet, werden Ihnen die Amazon-S3-Standardtarife berechnet. Wenn Sie Daten aus Quellen wie Amazon S3, Amazon Relational Database Service (RDS) oder Amazon Redshift verschieben, werden Ihnen Standardgebühren für Anfragen und Datenübertragungen berechnet. Wenn Sie Amazon CloudWatch nutzen, werden Ihnen Standardtarife für CloudWatch Logs und CloudWatch-Ereignisse berechnet.

Dieser Preis gilt für Amazon EMR in EC2-Clustern mit Apache-HBase-Anwendungen, die Amazon EMR WAL verwenden. Apache HBase Write Ahead Log ermöglicht das Aufzeichnen aller Änderungen an Daten in einem dateibasierten Speicher. Mit Amazon EMR auf EC2 können Sie Ihre vorausschauenden Apache-HBase-Protokolle in den Amazon EMR WAL schreiben, einer dauerhaft verwalteten Speicherebene, die Ihren Cluster überdauert. Für den Fall, dass Ihr Cluster oder in den seltenen Fällen, dass die Availability Zone fehlerhaft oder nicht mehr verfügbar ist, können Sie einen neuen Cluster erstellen. Verweisen Sie ihn auf dasselbe Amazon-S3-Stammverzeichnis und den Amazon-EMR-WAL-Workspace und stellen Sie die Daten im WAL innerhalb weniger Minuten automatisch wieder her. Weitere Informationen finden Sie in der Dokumentation zu Amazon EMR WAL. 

Sie zahlen für das, was Sie für die EMR WAL verwenden. Wenn Sie über einen aktiven Cluster verfügen, der für die Verwendung der WAL konfiguriert ist, werden Ihnen die Gebühren für den EMR WAL Speicher basierend auf der Nutzung als EMR-WAL-WALHours, für Schreibvorgänge als WriteRequestGiB und für Lesevorgänge als ReadRequestGiB in Rechnung gestellt.

EMR-WAL-WALHours: EMR WAL erstellt eine WAL pro Apache-HBase-Region. Wenn nach der Beendigung Ihres Clusters noch Daten im EMR WAL vorhanden sind, die nicht in Amazon S3 übertragen wurden, können Sie die Daten wiederherstellen, indem Sie einen Wiederherstellungscluster starten. Oder Sie wählen die Bereinigung des WAL, indem Sie einen temporären Cluster erstellen und die EMR-WAL-CLI zur Löschung der EMR-WAL-Ressourcen verwenden. Wenn Sie die EMR-WAL-Daten nicht explizit löschen, speichert EMR WAL die Daten und berechnet Ihnen alle nicht gelöschten Daten 30 Tage lang. Ein Beispiel finden Sie unten.

ReadRequestGiB und WriteRequestGiB: Diese beiden Dimensionen gelten für die Lese- und Schreibanfragen. Apache-HBase-API-Aufrufe zum Schreiben von Daten in Ihre Tabelle in einem Cluster mit EMR WAL werden als WriteRequestGiB in Rechnung gestellt. EMR-WAL-Schreibvorgänge werden für alle Apache-HBase-Schreibvorgänge ausgeführt, z. B. für `Put`-Vorgänge. Apache-HBase-API-Aufrufe zum Lesen von Daten aus Ihrer EMR WAL während Apache-HBase-Wiederherstellungsvorgängen werden als ReadRequestGiB in Rechnung gestellt. Lese- und Schreibvorgänge werden je nach Artikelgröße und EMR-Rechnungen mit mindestens 1 Byte berechnet.

Die Preisgestaltung basiert auf der Preisgestaltung für US-East-1.

Angenommen, Sie betreiben eine Amazon EMR-Anwendung, die auf Amazon EC2 bereitgestellt wird und dass Sie eine c4.2xlarge EC2-Instance als Hauptknoten und zwei c4.2xlarge EC2-Instances als Core-Knoten verwenden. Es werden sowohl für EMR- als auch für die EC2-Knoten Gebühren anfallen. Wenn sie zwei Monate lang mit voller Nutzung ausgeführt werden, und On-Demand-Preise für EC2 verwenden, lauten die Gebühren wie folgt:

Hauptknoten:

EMR-Gebühren = 1 Instance x 0,105 USD pro Stunde x (100 / 100 genutzt/Monat) x 730 Stunden in einem Monat = 76,65 USD (EMR-Hauptknoten-Gebühren) EC2-Gebühren = 1 Instance x 0,398 USD pro Stunde x 730 in einem Monat = 290,54 USD (EC2-Hauptknoten-Gebühren)

Core-Knoten:

EMR-Gebühren = 2 Instances x 0,105 USD pro Stunde x (100 / 100 genutzt/Monat) x 730 Stunden in einem Monat = 153,30 USD (EMR-Core-Knoten-Gebühren)

EC2-Gebühren = 2 Instances x 0,398 USD pro Stunde x 730 Stunden in einem Monat = 581,08 USD (EC2-Core-Knoten-Gebühren)

Gesamtgebühren = 76,65 USD + 290,54 USD + 153,30 USD + 581,08 USD = 1 101,57 USD

Die Preisgestaltung basiert auf der Preisgestaltung für US-East-1.

Angenommen, Sie betreiben eine Amazon-EMR-Spark-Anwendung, die auf Amazon EKS bereitgestellt wird. In diesem Fall bezieht EKS seine Rechenkapazität über r5.2xlarge EC2-Instances (8 vCPU, 64 GB RAM). Nehmen wir an, dass der EKS-Cluster über 100 Knoten mit insgesamt 800 vCPU und 6.400 GB Gesamtspeicher verfügt. Nehmen wir an, dass diese Anwendung 100 VCPUs und 300 GB Speicher für 30 Minuten nutzt.

Amazon-EMR-Uplift-Gesamtgebühren für die Aufgabe:

Gesamt-Uplift auf vCPU = (100 * 0,01012 USD * 0,5) = (Anzahl der vCPU * Rate pro vCPU-Stunden * Job-Laufzeit in Stunden) = 0,506 USD       

Gesamter Uplift auf Speicher = ( 300 * 0,00111125 USD *0,5) = (genutzter Speicher * Rate pro GB-Stunde * Job-Laufzeit in Stunden) = 0,1667 USD       

Gesamt-EMR-Uplift für die EMR-Aufgabe = 0,6727 USD

Weitere Kosten

Sie zahlen 0,10 USD pro Stunde für jeden Amazon EKS-Cluster, den Sie erstellen. Sie können einen einzelnen Amazon EKS-Cluster für die Ausführung verschiedener Anwendungen verwenden, wenn Sie von den Kubernetes-Namespaces und den IAM-Sicherheitsrichtlinien profitieren. Sie können EKS auf AWS entweder mit Amazon EC2 oder AWS Fargate ausführen.

Wenn Sie Amazon EC2 benutzen (einschließlich mit Amazon EKS verwalteter Knotengruppen), zahlen Sie für AWS-Ressourcen (z. B. EC2-Instances oder Amazon EBS Volumes), die Sie für den Betrieb Ihrer Kubernetes-Arbeitsknoten erstellen. Sie zahlen nur für das, was Sie tatsächlich nutzen. Es fallen weder Mindestgebühren noch Vorausleistungen an. Detaillierte Preisinformationen finden Sie auf der Preisseite für EC2.

Wenn Sie AWS Fargate benutzen, werden die Preise anhand der vCPU- und Arbeitsspeicherressourcen berechnet, die für die Zeitdauer des Container-Image-Downloads verwendet werden, bis der Amazon EKS-Pod beendet wird, aufgerundet auf die nächste Sekunde. Es wird immer mindestens 1 Minute berechnet. Detaillierte Preisinformationen finden Sie auf der Preisseite für AWS Fargate.

Nehmen wir an, sie übertragen einen Spark-Job an EMR Serverless. Nehmen wir an der Job ist so konfiguriert, dass er ein Minimum von 25 Workern nutzt und ein Maximum von 75 Workern, jeder von ihnen mit 4vCPU und 30 GB Arbeitsspeicher konfiguriert. Beachten Sie, dass kein zusätzlicher flüchtiger Speicher konfiguriert wurde. Wenn Ihr Job für 30 Minuten läuft und 25 Worker (oder 100 vCPU) nutzt und für 15 Minuten automatisch um weitere 50 Worker hochskaliert wurde (200 weitere vCPU):

Gesamte vCPU-Stundenkosten = (100 x 0,052624 USD x 0,5) + (200 x 0,052624 USD x 0,25) = (Anzahl der vCPU * Tarif pro vCPU-Stunden * Job-Laufzeit in Stunden) = 5,2624 USD

Gesamt GB-Stunden = (750 x 0,0057785 USD x 0,5) + (1500 x 0,0057785 USD x 0,25) = (Gesamter konfigurierter Arbeitsspeicher in GB x Tarif pro GB-Stunde x Job-Laufzeit in Stunden) = 4,333875 USD

EMR Serverless Gesamtkosten = 9,596275 USD

Zusätzliche Kosten: Wenn Ihre Anwendung andere AWS-Services, wie zum Beispiel Amazon S3, verwendet hat, werden Ihnen hierfür die Standard-S3-Tarife berechnet.

Angenommen, Sie erstellen einen neuen Amazon-EMR-Cluster mit Apache HBase und entscheiden sich für die vollständige Sicherung Ihres Clusters in der Region USA Ost (Nord-Virginia). Da es sich um eine neue Anwendung handelt, wissen Sie nicht, wie der Datenverkehr sich verhalten wird. Nehmen Sie der Einfachheit halber an, dass Ihr Benutzer 10 HBase-Tabellen einschließlich Systemtabellen und 2 HBase-Regionen pro Tabelle erstellt hat und dass diese jedes Mal, wenn ein Benutzer mit Ihrer Anwendung interagiert, 1 KiB an Daten schreiben. 

Für einen Zeitraum von 10 Tagen erhalten Sie nur wenig Datenverkehr zu Ihrer Anwendung, was zu 10 000 Schreibvorgängen pro Tag führt. An 11. Tag jedoch steigt der Datenverkehr Ihrer Anwendung auf 2 500 000 Schreibvorgänge an diesem Tag. Sie entscheiden sich auch dafür, gleichzeitig Ihren benutzerdefinierten Code auf Ihrem Cluster zu aktualisieren und am 11. Tag eine geplante nächtliche Ausfallzeit für Ihre Endbenutzer einzulegen. Gehen wir davon aus, dass dies zu 1 000 000 Lesevorgängen aus der EMR WAL für HBase-Wiederherstellungsvorgänge führt. Ihre Anwendung skaliert, um Ihren Benutzern ein nahtloses Erlebnis zu bieten. Bis zum Ende des Monats stellt sich für Ihre Anwendung dann ein gleichmäßigeres Datenverkehrsmuster von 50 000 Schreibvorgängen pro Tag ein. 

Die folgende Tabelle fasst die Gesamtnutzung für diesen Monat zusammen.

Für den Monat beläuft sich Ihre Rechnung auf 26,52 USD, was insgesamt 0,38 USD für WriteRequestGiB und WriteRequestGiB sowie 25,92 USD für EMR-WAL-WALHours beinhaltet.