O preço destina-se a aplicações do Amazon EMR em execução em clusters do Amazon EMR com instâncias do Amazon EC2.

O preço do Amazon EMR é adicionado ao preço do Amazon EC2 (o preço para os servidores subjacentes) e ao preço do Amazon Elastic Block Store (Amazon EBS) (se houver volumes do Amazon EBS anexados). Esses preços também são cobrados por segundo, com um mínimo de um minuto. Você pode escolher entre diversas opções de preço do EC2, incluindo instâncias sob demanda (exibidas abaixo), instâncias reservadas de um e três anos, Savings Plans de capacidade e instâncias spot. As instâncias spot são a capacidade ociosa do EC2, disponíveis com um desconto de até 90% em relação ao preço de instâncias sob demanda. Veja a economia do preço da instância spot em comparação com o preço sob demanda filtrando por “tipos de instância compatíveis com o EMR” na página do consultor de instâncias spot.

O preço refere-se aos clusters do Amazon EMR no Amazon EKS.

O preço do Amazon EMR é somado ao preço do Amazon EKS ou de qualquer outro serviço usado com o EKS. Você pode executar o EKS na AWS usando o EC2 ou o AWS Fargate. Se estiver usando o EC2 (inclusive com grupos de nós gerenciados do EKS), você pagará pelos recursos da AWS (por exemplo, instâncias do EC2 ou volumes do EBS) que criar para executar nós de processamento do Kubernetes. Consulte as informações de preço detalhadas na página de preço do EC2. Se estiver usando o AWS Fargate, o preço será calculado de acordo com os recursos de vCPU e memória usados desde o momento em que você começar a baixar a imagem do contêiner até que o pod do EKS seja encerrado, arredondado para o segundo mais próximo. Há uma cobrança mínima de um minuto. Veja as informações de preço detalhadas na página de preço do AWS Fargate.

O preço do Amazon EMR no Amazon EKS é calculado de acordo com os recursos de vCPU e memória usados do momento em que você começa a baixar da sua imagem da aplicação do EMR até que o pod do EKS seja encerrado, arredondado para o segundo mais próximo. O preço é baseado nos recursos de vCPU e memória solicitados para a tarefa ou o pod.

O preço do Amazon EMR no AWS Outposts é o mesmo das instâncias baseadas na nuvem do EMR. Consulte a página de preço do AWS Outposts para obter detalhes sobre o preço do AWS Outposts.

Com o EMR Serverless, não há custos iniciais, e você paga apenas pelos recursos que usar. Pague pela quantidade de recursos de vCPU, memória e armazenamento consumidos pelas suas aplicações.

Com o EMR Serverless, você cria uma aplicação usando um framework de código aberto e então envia os trabalhos para a aplicação. Como parte da especificação do trabalho, você pode fornecer o número mínimo e máximo de operadores simultâneos, além do número de vCPUs, da memória e do armazenamento para cada operador. O EMR automaticamente adiciona e remove operadores com base no que o trabalho exige dentro dos limites que você especificou. As três dimensões de computação, memória e armazenamento para operadores podem ser configuradas de maneira independente. É possível escolher entre 1 vCPU, 2 vCPUs, 4 vCPUs, 8 vCPUs ou 16 vCPUs por operador, memória de 2 GB a 120 GB por operador em incrementos de 1 GB a 8 GB. Para opções de armazenamento, é possível escolher o armazenamento padrão de 20 GB a 200 GB por operador ou escolher o armazenamento otimizado aleatório de 20 GB a 2 TB por operador.

Você é cobrado pelos recursos agregados de vCPU, memória e armazenamento usados a partir do momento em que os operadores estiverem prontos para executar sua workload até quando terminarem. O tempo é arredondado para o segundo mais próximo, e o período mínimo é de um minuto. Se você configurar a aplicação para executar operadores no momento da inicialização, os operadores necessários entrarão em uso quando você iniciar a aplicação e terminarão quando você a interromper ou quando ela estiver inativa.

Detalhes do preço (computação e memória)

O preço se baseia no total de recursos de vCPU, memória e armazenamento usados por todos os operadores.

Detalhes do preço (armazenamento temporário)

Armazenamento padrão: os primeiros 20 GB de armazenamento temporário são disponibilizados para todos os operadores por padrão. Você só paga pelo armazenamento adicional configurado por operador.

Armazenamento otimizado aleatório: você paga por todo o armazenamento configurado por operador, incluindo os primeiros 20 GB.

Configurações de operador compatíveis

Duração

A duração é calculada desde o momento em que um operador estiver pronto para executar a workload até quando ele terminar. O tempo é arredondado para o segundo mais próximo, e o período mínimo é de um minuto.

Cobranças adicionais

Pode haver taxas adicionais caso as aplicações usem outros serviços da AWS. Por exemplo, se a aplicação usa o Amazon Simple Storage Service (S3) para armazenar e processar dados, as taxas padrão desse serviço serão cobradas. Se você mover os dados de fontes como Amazon S3, Amazon Relational Database Service (RDS) ou Amazon Redshift, serão cobradas taxas padrão de solicitação e transferência de dados. Se você usar o Amazon CloudWatch, serão cobradas taxas padrão para o CloudWatch Logs e o CloudWatch Events.

Essa definição de preço se aplica ao Amazon EMR em clusters EC2 com aplicações Apache HBase usando o Amazon EMR WAL. O log Write Ahead do Apache HBase permite registrar todas as alterações nos dados no armazenamento baseado em arquivos. Com o Amazon EMR no EC2, você pode gravar seus logs de gravação antecipada do Apache HBase no Amazon EMR WAL, uma camada de armazenamento gerenciado durável que sobrevive ao seu cluster. Caso seu cluster, ou nos raros casos em que a zona de disponibilidade fique insalubre ou indisponível, você pode criar um novo cluster, direcioná-lo para o mesmo diretório raiz do Amazon S3 e espaço de trabalho WAL do Amazon EMR e recuperar automaticamente os dados no WAL em alguns minutos. Para obter mais informações, consulte a documentação WAL do Amazon EMR. 

Você pagará pelo que usar para o EMR WAL. Se você tiver um cluster ativo configurado para usar o WAL, você será cobrado pelo armazenamento WAL do EMR com base no uso cobrado como EMR-WAL-WALHours, gravado como WriteRequestGiB e lido como ReadRequestGiB.

EMR-WAL-WALhours: o EMR WAL criará um WAL por região do Apache HBase. Depois que seu cluster for encerrado, se ainda houver dados no EMR WAL que não foram transferidos para o Amazon S3, você pode recuperar os dados iniciando um cluster de recuperação ou optar por limpar o WAL criando um cluster temporário e usar a CLI do EMR WAL para excluir os recursos do EMR WAL. Se você não excluir os dados do EMR WAL explicitamente, o EMR WAL reterá os dados e cobrará por qualquer dado não liberado por 30 dias. Você pode conferir um exemplo abaixo.

ReadRequestGiB e WriteRequestGiB: essas duas dimensões são para as solicitações de leitura e gravação. As chamadas da API do Apache HBase para gravar dados em sua tabela em um cluster com o EMR WAL são cobradas como WriteRequestGiB. As gravações WAL do EMR ocorrerão para todas as gravações do Apache HBase, como operações “Put”. As chamadas de API do Apache HBase para ler dados do seu EMR WAL durante as operações de recuperação do Apache HBase são cobradas como ReadRequestGiB. As leituras e gravações são cobradas com base nos tamanhos dos itens e nas faturas do EMR com um mínimo de 1 byte.

Preço baseado na estimativa de preço para a região US-East-1.

Suponha que você execute uma aplicação Amazon EMR implantada no Amazon EC2 e que use uma instância c4.2xlarge do EC2 como seu nó principal e duas instâncias c4.2xlarge do EC2 como nós centrais. Você será cobrado tanto pelo EMR quanto pelos nós do EC2. Se você trabalhar por um mês, com 100% de utilização durante esse mês, e usar o preço sob demanda para o EC2, suas cobranças serão:

Nó principal:

Cobranças EMR = 1 instância x 0,105 USD por hora x (100 / 100 utlizado/mês) x 730 horas em um mês = 76,65 USD (custo do nó principal do EMR). Cobranças do EC2 = 1 instância x 0,398 USD por hora x 730 em um mês = 290,54 USD (custo do nó principal EC2)

Nós centrais:

Cobranças do EMR = 2 instâncias x 0,105 USD por hora x (100 / 100 utilizados/mês) x 730 horas em um mês = 153,30 USD (custo do nó central do EMR)

Cobranças do EC2 = 2 instâncias x 0,398 USD por hora x 730 horas em um mês = 581,08 USD (custo do nó central do EC2)

Total de cobranças = USD 76,65 + USD 290,54 + USD 153,30 + USD 581,08 = USD 1.101,57

Preço baseado na estimativa de preço para a região US-East-1.

Suponha que você esteja executando uma aplicação do Amazon EMR-Spark implantada no Amazon EKS. Nesse caso, o EKS obtém sua capacidade computacional por meio de instâncias do EC2 r5.2xlarge (8 vCPU, RAM de 64 GB). Digamos que o cluster do EKS tenha 100 nós, totalizando 800 vCPU e 6400 GB de memória total. Vamos supor que essa aplicação utilize 100 VCPUs e 300 GB de memória por 30 minutos.

Total de aumentos de cobranças do Amazon EMR para o trabalho:

Total de aumentos para vCPU = (100 * 0,01012 USD * 0,5) = (número de vCPUs * por taxa de horas/vCPU * tempo de execução do trabalho em hora) = 0,506 USD       

Total de aumentos para memória = ( 300 * 0,00111125 USD * 0,5) = (quantidade de memória utilizada * por taxa de horas/GB * tempo de execução do trabalho em hora) = 0,1667 USD       

Total de aumentos do EMR para o trabalho do EMR = 0,6727 USD

Custos adicionais

Você paga 0,10 USD por hora por cluster do Amazon EKS criado. Você pode usar um único cluster do Amazon EKS para executar várias aplicações ao utilizar as políticas de segurança do IAM e os namespaces do Kubernetes. Você pode executar o EKS na AWS usando o Amazon EC2 ou o AWS Fargate.

Se estiver usando o Amazon EC2 (incluindo com grupos de nós gerenciados pelo Amazon EKS), você pagará pelos recursos da AWS (p. ex., instâncias do EC2 ou volumes do Amazon EBS) que criar para executar nós de processamento do Kubernetes. Você só paga pelo que usa, no momento em que usa. Não há taxas mínimas nem compromissos antecipados. Consulte as informações de preço detalhadas na página de preço do EC2.

Se estiver usando o AWS Fargate, o preço será calculado de acordo com os recursos de vCPU e memória usados desde o momento em que você começar a baixar a imagem do contêiner até que o pod do Amazon EKS seja terminado, arredondado para o segundo mais próximo. Há uma cobrança mínima de um minuto. Veja as informações de preço detalhadas na página de preço do AWS Fargate.

Digamos que você tenha enviado um trabalho do Spark para o EMR Serverless. Vamos imaginar que o trabalho está configurado para utilizar pelo menos 25 e no máximo 75 operadores, cada um configurado com 4 vCPUs e 30 GB de memória. Considere que não se configurou armazenamento temporário adicional. Se o seu trabalho é executado durante 30 minutos usando 25 operadores (ou 100 vCPUs) e foi escalado automaticamente para adicionar mais 50 operadores (mais 200 vCPUs) por 15 minutos:

Custo total das horas de vCPU = (100 * USD 0,052624 * 0,5) + (200 * USD 0,052624* 0,25) = (número de vCPUs * por taxa de vCPU/hora * tempo de execução do trabalho em horas) = USD 5,2624

Total de GB/hora = (750 * USD 0,0057785 * 0,5) + (1.500 * USD 0,0057785 * 0,25) = (Total de GB de memória configurada * por taxas de GB/hora * tempo de execução do trabalho em horas) = USD 4,333875

Total de cobranças do EMR Serverless = USD 9,596275

Cobranças adicionais: se a aplicação usa outros serviços da AWS, como o Amazon S3, são cobradas as taxas padrão do S3.

Suponha que você crie um novo cluster do Amazon EMR com o Apache HBase e opte por fazer o backup completo do seu cluster na região Leste dos EUA (Norte da Virgínia). Como isso é para uma nova aplicação, você não conhece os padrões de tráfego. Para simplificar, suponha que seu usuário tenha criado 10 tabelas do HBase, incluindo tabelas do sistema, 2 regiões do HBase por tabela, e que cada vez que um usuário interage com sua aplicação, ele grava 1 KiB de dados. 

Por um período de 10 dias, você recebe pouco tráfego para sua aplicação, resultando em 10.000 gravações por dia. No entanto, no dia 11, o tráfego da sua aplicação aumenta para 2.500.000 gravações naquele dia. Você também decide atualizar simultaneamente seu código personalizado em seu cluster e fazer um tempo de inatividade noturno programado para seus usuários finais no dia 11. Vamos supor que isso resulte em 1.000.000 de leituras do EMR WAL para operações de recuperação do HBase. A sua aplicação escala para oferecer uma experiência transparente aos usuários. Sua aplicação, então, se estabelece em um padrão de tráfego mais regular de 50.000 gravações por dia até o final do mês. 

A tabela a seguir resumo o uso total nesse mês.

Para o mês, sua fatura será de 26,52 USD, um total que inclui 0,38 USD para ReadRequestGiB e WriteRequestGiB e 25,92 USD para EMR-WAL-WALHours.