Otimização de Custo e Lifecycle: dos Prefixos Quentes ao Glacier Deep Archive

As lições 01 to 15 construíram um lakehouse que funciona: armazenamento, formatos, tabelas, ingestão, um catálogo, transformação, consultas, um warehouse, orquestração, governança, tratamento de PII, segurança e observabilidade. Cada uma dessas decisões tem um medidor acoplado, e até agora esses medidores se juntaram em uma fatura mensal que ninguém consegue ler linha por linha. A má notícia: custo é a única propriedade de lakehouse que degrada em silêncio, porque a fatura chega um mês depois da decisão que a causou. A boa notícia: diferente de correção, custo tem uma escada: uma ordem fixa de operações que a própria orientação Well-Architected da AWS implica e que todo estudo de caso de custo publicado pela AWS segue.

Esta lição ensina essa escada de ponta a ponta: formato → temperatura → escala acidental → gasto sem atribuição → compromissos, nessa ordem, com as taxas de outubro de 2026 de us-east-1 que fazem cada degrau virar aritmética em vez de conselho. A única regra que organiza tudo abaixo: nunca compre um desconto no tamanho errado, e nunca mova um byte para uma classe mais fria antes de saber quando você vai lê-lo de volta.

Nesta lição você vai:

• ler uma tabela de formas de custo por serviço que nomeia a unidade cobrável de cada camada do lakehouse antes de tocar em uma única alavanca;
• percorrer a cascata de lifecycle do S3, cada classe de armazenamento, duração mínima, taxa de retrieval e caminho de restore, e calcular um TCO de três a cinco anos para uma pegada de 60 TB;
• cair na armadilha da taxa de monitoramento do Intelligent-Tiering de propósito, no papel, com oito milhões de objetos minúsculos, para você nunca fazer isso em produção;
• cercar a camada de consulta do Athena com cortes de workgroup, partition projection, poda de colunas e ZSTD, e depois calcular duas vezes a fatura mensal de 500 analistas: antes e depois dos redutores;
• fazer right-sizing do Glue (DPU = 4 vCPU + 16 GB, $0.44/DPU-hour, mínimo de 1 minuto, timeout default de 48 horas no Glue 4.0 e anteriores) e esboçar EMR Serverless versus Glue em vCPU/GB-hours;
• aplicar as alavancas do Redshift: pause/resume, Redshift Managed Storage a $0.024/GB-mês, créditos de Concurrency Scaling e reservas do Serverless;
• escolher entre o preço por usuário do QuickSight e a capacidade de sessão de leitor com um cálculo de ponto de equilíbrio, e impedir que a capacidade de SPICE só suba;
• precificar as formas de streaming (shard-hours do Kinesis versus GB sob demanda, incrementos de 5 KB do Firehose, as cinco linhas do MSK Serverless) e os multiplicadores silenciosos (requests do KMS com e sem bucket keys, data events do CloudTrail, NAT versus gateway endpoints gratuitos);
• operar Cost Explorer, Budgets e Cost Anomaly Detection e etiquetar o ambiente com CostCenter / Layer / Project para que todo número seguinte seja legível;
• estudar a GE Aerospace (economia anual estimada >$500.000 no Redshift) e o Transport for NSW (~80% de corte no custo de integração de dados no Glue), mais uma caixa de atualização de 2026 com fontes;
• praticar com doze questões de prova e quatro verificações interativas (um plot de TCO, um matching de alavanca para serviço, um preenchimento de nomes de taxas e um arrastar-e-soltar da própria escada).

---

1. Anatomia de custo: o medidor de cada camada antes da alavanca

1.1 A escada de cinco degraus, e por que a ordem não é negociável

A disciplina de otimização de custo da AWS, documentada no pilar de custo do Well-Architected e repetida em todo estudo de caso de custo publicado pela AWS, é uma sequência, não um menu. Cada degrau é mais barato e mais seguro que o de baixo:

1. Formato: pare de pagar pelo formato errado dos dados. Formatos colunares, compressão e projeção de colunas fazem os scanners lerem menos bytes. Em um medidor por varredura, essa é a mudança de maior alavanca que existe, e não custa nada além de uma reescrita do caminho de gravação.
2. Temperature: pare de pagar pela temperatura errada. Regras de lifecycle movem dados envelhecendo para classes de armazenamento mais baratas com custo de configuração zero; você paga apenas a request de transição.
3. Escala acidental, pare de pagar por gasto acidental: cortes de scan em workgroup, timeouts de job, orçamentos de Max RPU-hour, ações de budget. Isso são disjuntores, não otimizações, eles limitam a cauda.
4. Atribuição: pare de pagar por gasto sem atribuição. Cost allocation tags por pipeline transformam uma fatura ilegível em N legíveis. Sem esse degrau, toda medição seguinte é chute.
5. Compromissos, só agora compre descontos: reserved nodes do Redshift, Serverless Reservations do Redshift, Savings Plans. Um compromisso baixa o preço unitário e não faz nada com a quantidade, e é por isso que o degrau 5 em um ambiente não otimizado é como você trava desperdício por um ou três anos.

1.2 Formas de custo por serviço: a tabela que torna todo o resto legível

Cada linha nomeia a unidade cobrável primeiro, o âncora de taxa de outubro de 2026 em us-east-1 segundo, e o modo de falha que inflaciona a fatura terceiro. Uma alavanca que não ataca a unidade cobrável do seu serviço não é uma alavanca.

1.3 Tags: o degrau que torna todo número seguinte legível

Quatro chaves de tag carregam quase toda a necessidade de atribuição de um lakehouse, aplicadas a todo recurso que pode receber tag: buckets e prefixos do S3 (via tags de objeto onde o serviço as suporta), jobs e crawlers e connections do Glue, workgroups do Athena, clusters e workgroups do Redshift, pastas e datasets do QuickSight, streams do Kinesis, clusters do MSK, NAT gateways e VPC endpoints:

Três regras duras, todas documentadas pela AWS:

1. As tags precisam ser ativadas como cost allocation tags antes de aparecerem no Cost Explorer ou em um relatório de alocação de custo, e a ativação pode levar até 24 horas para a chave aparecer na página de ativação, mais outras até 24 horas para entrar em vigor.
2. Tags não são retroativas. Elas afetam o relatório de faturamento apenas a partir do momento da ativação. Uma estratégia de tags lançada em outubro de 2026 não te diz nada sobre setembro.
3. Em AWS Organizations, as cost allocation tags são ativadas apenas a partir da conta de gerenciamento (pagadora), e a AWS recomenda um número pequeno de chaves de tag consistentes: a dispersão é ela própria um custo, porque cada chave extra é um eixo extra para reconciliar.

1.4 Visibilidade antes da otimização: Cost Explorer, Budgets, Anomaly Detection

Você não otimiza o que não vê, e os três serviços de visibilidade de custo da AWS têm três trabalhos diferentes, e três faturas diferentes:

A forma operacional que a AWS documenta: Budgets para o disjuntor em tempo real (limiar → SNS → ação via Lambda), Cost Anomaly Detection como a rede de segurança semanal (ele é lento por desenho), Cost Explorer para a investigação quando qualquer um dos dois dispara. Nenhum dos três consegue atribuir gasto a um pipeline sem as tags da seção 1.3.

• 📚 Você sabia? A ferramenta de FinOps mais barata da sua conta é uma ação de budget, não um dashboard: os dois primeiros budgets com ação habilitada são gratuitos, e uma ação pode desabilitar um workgroup do Athena ou desanexar uma política de IAM no momento em que um limiar estoura. O Cost Anomaly Detection, por mais inteligentes que sejam os modelos, não consegue parar nada, e pode levar até 24 horas para notar uma fuga que uma ação de budget teria pego em minutos (documentação de AWS Budgets e Cost Anomaly Detection, acesso em 2026-10-11).

---

2. S3: a cascata de lifecycle, e a fatura de restore que ninguém modela

2.1 Cada classe, cada duração mínima, cada taxa de retrieval

Esta é a tabela mais valiosa da lição. As taxas de armazenamento são o título; durações mínimas e taxas de retrieval é onde o desenho vive.

Mais as taxas do lado da request que completam o quadro: as requests de transição de lifecycle custam $0.01 por 1.000 para Standard-IA / One Zone-IA / Intelligent-Tiering, $0.02 por 1.000 para Glacier Instant Retrieval e $0.05 por 1.000 para Glacier Deep Archive; as taxas de request de restore são $0.01 / $0.05 / $0.00 por 1.000 requests para Expedited / Standard / Bulk; objetos arquivados cobram adicionalmente 40 KB de metadados por objeto; e toda classe arquivada cobra a sua duração mínima por inteiro: um objeto deletado ou re-transitado para fora do Deep Archive no dia 30 ainda cobra 180 dias.

2.2 Regras de lifecycle versus Batch Operations versus movimentações manuais

Uma regra de lifecycle transiciona ou expira existentes e novos objetos que casam com um filtro, e a configuração em si é gratuita: você paga apenas a request de transição ($0.01 to$0.05 por 1.000). A AWS não cobra nada para a regra continuar casando com objetos de amanhã. S3 Batch Operations é o caminho retroativo dirigido por manifesto: $0.25 por job mais $1.00 por milhão de operações de objeto, com um manifesto geralmente produzido pelo S3 Inventory a $0.0025 por milhão de objetos listados. Re-enviar manualmente ou usar CopyObject em milhões de objetos queima taxas de request PUT/COPY, precisa de uma frota de computação, e abre uma janela em que duas cópias são cobradas.

A regra prática: reclassificação por idade = regra de lifecycle; reclassificação dirigida por tag ou manifesto = Batch Operations. Você quase nunca precisa de Batch Operations para reclassificar objetos comuns que envelhecem, e pagar para que ele faça o trabalho de uma regra de lifecycle é uma fatura autoinfligida.

Três outras ações de lifecycle pertencem a todo bucket de produção, porque versionar sem elas é um multiplicador silencioso: expirar versões não atuais (NoncurrentDays), limitar quantas versões não atuais são mantidas (MaxNoncurrentVersions, válido de 1 a 100), e abortar uploads multipart incompletos. Com versionamento habilitado, todo PUT cria uma nova versão atual enquanto a versão anterior continua cobrada integralmente na taxa da sua classe: um bucket churnado pode cobrar várias vezes o seu tamanho "lógico" até que essas três regras existam.

2.3 Economia do restore: a cópia temporária é o verdadeiro choque

Restaurar um objeto arquivado cobra duas coisas, e só uma delas é intuitiva:

1. a taxa de retrieval por GB da tier de velocidade escolhida (tabela acima), mais a taxa de request de restore; e
2. uma cópia temporária restaurada, cobrada nas taxas de armazenamento do S3 Standard, pela duração que você escolher mantê-la: por cima do objeto arquivado que você ainda está pagando.

Então um restore do Deep Archive é barato na linha de retrieval ($0.0025/GB Bulk) e caro no plano: 48 horas de latência, uma cópia temporária a $0.023/GB-mês rateada, e nenhuma opção Expedited a qualquer preço. Restores do Deep Archive devem portanto ser agendados, nunca casuais: Bulk para backfills planejados, Standard apenas para emergências reais de 12 horas. E lembre do penhasco da duração mínima pelo avesso: se o seu padrão de acesso diz "podemos ler isso dentro de 90 dias", a duração mínima de 180 dias do Deep Archive significa que a classe está errada, não que você deva aceitar o risco.

• 📚 Você sabia? O Deep Archive não tem tier de retrieval Expedited: as opções de velocidade param no Standard (em até 12 horas) e no Bulk (em até 48 horas). Qualquer diagrama de arquitetura que mostre um caminho "instantâneo" de saída do Deep Archive está inventando uma tier que a AWS não vende (documentação do Amazon S3 Glacier, acesso em 2026-10-11).

2.4 Exemplo resolvido E1: um lakehouse de 60 TB, três anos, depois cinco

O cenário: um lake operacional de 50 TiB, 20 TiB quentes curados no S3 Standard, 25 TiB mornos no Standard-IA, 5 TiB frios no Glacier Instant Retrieval, mais 10 TiB de histórico de compliance no Glacier Deep Archive. Uma pegada de 60 TiB, mantida por três anos. A AWS cobra GB como 1.073.741.824 bytes, então TiB → GB é ×1.024.

O intervalo cresce em $591,46 a cada mês e é inteiramente uma decisão do degrau 2: nenhum código mudou, nenhuma consulta foi ajustada, nenhum compromisso foi comprado. Agora os dois eventos que quebram os modelos de arquivo, leituras e a fatura única de transição, que pertencem à mesma planilha do armazenamento.

2.5 Exemplo resolvido E1b: cenários de restore e a fatura única de transição

O mesmo ambiente de 60 TiB. Quanto custa ler 1 TiB de volta, por caminho, e quanto custou reclassificar 45 TiB existentes dele?

2.6 Intelligent-Tiering: a armadilha da taxa de monitoramento em objetos minúsculos

Intelligent-Tiering é o default mais seguro quando os padrões de acesso são genuinamente desconhecidos: sem duração mínima, sem taxas de retrieval, movimentação automática entre as tiers Frequent, Infrequent, Archive Instant, Archive e Deep Archive Access com base no acesso observado (objetos ociosos por 30 dias vão para a tier Infrequent, 90 dias para Archive Instant, e Deep Archive Access exige um mínimo de 180 dias consecutivos de ociosidade). Mas é um negócio de monitoramento: cobra $0.0025 por 1.000 objetos por mês de monitoramento e automática, e apenas objetos de pelo menos 128 KB são elegíveis para auto-tiering de modo algum. Para objetos grandes e mornos a taxa é um erro de arredondamento; para milhões de objetos minúsculos ela é a fatura.

2.7 Exemplo resolvido E2: oito milhões de objetos minúsculos "poupados" pelo Intelligent-Tiering

Um lake de eventos pousa fragmentos minúsculos no Intelligent-Tiering "para economizar dinheiro". Nada neste desenho economiza dinheiro.

A regra de decisão que sai do E2: o Intelligent-Tiering é para objetos grandes, mornos, com acesso desigual e padrões desconhecidos; as classes explícitas de lifecycle são para objetos que você entende; e nenhum dos dois pertence a objetos menores que 128 KB: esses devem ser compactados na gravação, o que é uma correção de custo e de desempenho de consulta em um movimento só.

2.8 Replicação pode mirar uma classe mais barata, mas cobra em dobro

A classe de armazenamento de destino é uma configuração de replicação de primeira linha: você pode replicar direto para Glacier Flexible Retrieval, Glacier Deep Archive, Intelligent-Tiering e as outras classes (o StorageClass de destino no CloudFormation aceita DEEP_ARCHIVE, GLACIER, GLACIER_IR, INTELLIGENT_TIERING, ONEZONE_IA, STANDARD, STANDARD_IA; o default é manter a classe de origem). A região de DR portanto nunca paga taxas Standard por uma cópia que ninguém lê.

A pegada é aritmética, não de capacidade: você paga pelas duas cópias, mais os custos de request de replicação, mais $0.015 por milhão de objetos por mês no bucket de origem de monitoramento de replicação. Replicar para uma classe mais barata é um padrão de recuperação de desastres e compliance, não um desconto de armazenamento: modele como "a cópia de DR é barata o suficiente para manter para sempre", nunca como "isso corta minha fatura do S3 pela metade".

---

3. A camada de consulta: o Athena cobra bytes varridos, então toda varredura é uma decisão de desenho

3.1 O medidor e os quatro redutores multiplicativos

Athena SQL no S3 custa $5,00 por TB varrido em us-east-1: cobrado tanto para consultas bem-sucedidas quanto para as mal-sucedidas (consultas federadas somam um mínimo de 10 MB por consulta e agregam entre fontes de dados), mais as cobranças normais de requests do S3 para gravar e ler resultados. Em um modelo de preço por varredura, otimizar é faturar. Quatro redutores independentes se empilham multiplicativamente:

1. Particionamento e partition projection: só as partições correspondentes são listadas e lidas. A projection calcula valores de partições a partir de propriedades da tabela em vez do catálogo, o que evita completamente a consulta de metadata; ative-a e o Athena ignora os metadados de partição do catálogo, então ela exige predicados em todas as chaves projetadas e degrada onde mais da metade das partições projetadas está vazia. O Athena pode ler no máximo 1 milhão de partições em uma única varredura (tabelas do Glue suportam até 10 milhões).
2. Projeção de colunas: Parquet e ORC leem apenas as colunas referenciadas.
3. Compressão, você paga pelos bytes varridos antes da descompressão, então ZSTD/GZIP reduz a fatura do Athena e a do S3 ao mesmo tempo. ZSTD é a compressão padrão de tabelas Iceberg na versão do motor 3 (nível 3), e a AWS recomenda o nível 3 ou 6 to 9 para gravações em Parquet/ORC; níveis acima de 19 exigem memória séria. Mantenha os row groups do Parquet no default de 128 MB e as stripes do ORC em 64 MB, encolhê-los abaixo do default não é recomendado.
4. Reuso de resultados, re-execuções de uma consulta idêntica na versão do motor 3 no mesmo workgroup retornam o resultado em cache com DataScannedInBytes: 0, com idade default de até 60 minutos e máximo de 7 dias. SQL não determinístico (rand(), shuffle()) contorna isso, e também permissões de linha/coluna do Lake Formation e consultas federadas, que sempre re-executam.

O exemplo resolvido da própria AWS do mecanismo: 3 TB de texto sem compressão, uma coluna selecionada, sem compressão = 3 × $5 = $15; com compressão 3:1 = $5; como Parquet com compressão 3:1 e seleção de colunas 4:1 = $1,25. Três alavancas, doze vezes mais barato, mesma consulta.

3.2 Disjuntores de gasto do workgroup: circuit breakers da camada de consulta

Workgroups são simultaneamente a unidade de isolamento e a unidade de controle de custo, e a AWS documenta um padrão de produção com dois workgroups:

• Corte por consulta, BytesScannedCutoffPerQuery (mínimo de API de 10.000.000 bytes = 10 MB) cancela uma consulta desgovernada no instante em que ela cruza o limiar. A consulta cancelada ainda é cobrada por tudo o que foi varrido até a parada, o corte limita a cauda, ele nunca dá desconto na cabeça.
• Controles de uso por workgroup: levantar um alarme SNS, e a escalação documentada é uma função Lambda que desabilita o workgroup quando uma marca de nível mais alto dispara.
• Cost allocation tags no workgroup: etiquete cada workgroup (digamos, Name=ad-hoc-users, Dept=analytics) para que o gasto do Athena aterrisse sob o CostCenter certo no Cost and Usage Report.

O Athena também vende Capacity Reservations a $0,30 por DPU-hour (uma reserva de 160 DPUs para uma hora de pico de 15 minutos custa 160 × $0,30 × 0,25 = $12,00 no exemplo resolvido da AWS) e sessões de Spark a $0,35 por DPU-hour: a opção do degrau 5, depois que os degraus 1 to 3 já fizeram o seu trabalho. Existem até 1.000 workgroups por Região como teto, que é capacidade para um workgroup por time ou pipeline, não um por usuário.

3.3 Exemplo resolvido E3: 500 analistas, 50 GB por dia, antes e depois dos redutores

Este é o cálculo que todo time de analytics deveria saber reproduzir de memória, porque é ele que decide se o Athena é uma linha de fatura ou um erro de arredondamento.

A lição do E3 é a proporção: os redutores levaram ~$2.563 até ~$154, uma redução de 16x, antes de alguém comprar qualquer coisa. Um time que negocia um compromisso enquanto ainda roda SELECT * sobre arquivos de texto pulou os degraus 1 e 2 para economizar centavos no degrau 5.

---

4. Transformação: right-sizing de DPU do Glue, cobrança de um minuto e o esboço do EMR Serverless

4.1 O que o Glue de fatura, e onde os defaults mordem

O Glue ETL é $0,44 por DPU-hour, cobrado por segundo com mínimo de 1 minuto (crawlers carregam mínimo de 10 minutos; tarefas de Data Quality têm mínimo de 1 minuto com chão de 2 DPUs). Uma DPU é 4 vCPUs de computação e 16 GB de memória. Existem dois modelos de capacidade, divididos por versão:

• Jobs no estilo do Glue 1.0 especificam capacidade provisionada via MaxCapacity em DPUs (mínimo 2, máximo 100, default 10).
• Jobs do Glue 2.0 e posteriores não podem definir capacidade máxima alguma: eles especificam um tipo de worker × número de workers: G.1X = 1 DPU, G.2X = 2 DPU, até G.16X; G.025X é um quarto de DPU para streaming de baixo volume a um quarto do custo; workers R.* são otimizados para memória em M-DPUs (4 vCPU + 32 GB); Z.2X é o worker Ray (2 M-DPU, 8 workers Ray). Jobs de Spark alocam 2 a 100 DPUs, default 10; jobs de shell Python usam 0,0625 ou 1 DPU. Jobs criados sem versão defaultam para Glue 5.1.

Três defaults se escondem nessa tabela: uma alocação default de 10 DPUs, um timeout default de job de 2.880 minutos (48 horas) no Glue 4.0 e anteriores (480 minutos no Glue 5.0 e posteriores; máximo rígido logo abaixo de 7 dias), e a classe de execução Flex a $0,29 por DPU-hour para capacidade interruptível, cobrada por worker-time em vez de capacidade-máxima × tempo de parede. Right-sizing é uma atividade medida: compare os executors máximos necessários contra os executors máximos alocados, e pare de escalar quando o tempo de parede parar de melhorar: no exemplo publicado pela própria AWS o job melhora de 10 DPUs / 6 minutos para 55 DPUs / 3 minutos e 100 DPUs não compra nada mais.

4.2 Exemplo resolvido E4: um job desgovernado, um job right-sized e a alternativa EMR Serverless

• 📚 Você sabia? O Glue publica uma métrica do CloudWatch DPUHours por execução de job (as dimensões incluem JobName, JobRunId, JobType, GlueVersion e ExecutionClass), então um alarme de budget pode disparar sobre DPU-hours consumidos, e não sobre tempo de parede: a única maneira confiável de pegar o caso do E4 antes que o timeout pegue. Ligar métricas de job, logs de aplicação e continuous logging acrescenta cobranças próprias do CloudWatch, então habilite-as onde o valor do alarme superar o custo dos logs (AWS Big Data Blog, 2023-04-28).

---

5. Redshift: pause/resume, armazenamento gerenciado, créditos de concurrency, RPUs do Serverless

A perna de warehouse do lakehouse tem três medidores, e a maioria dos argumentos de preço de tabela confunde eles:

1. Computação, provisionada: nós RA3 e RG são cobrados por hora (o exemplo resolvido da própria AWS precifica ra3.4xlarge a $3,26 por node-hour sob demanda: 4 nós × $3,26 × 730 horas = $9.519,20 por mês). Reserved nodes dão desconto nisso de cerca de 20% (No Upfront) até 42 to 76% (All Upfront).
2. Armazenamento, sempre separado, o Redshift Managed Storage cobra $0,024 por GB-mês quer os dados estejam em SSDs locais quer no S3. Esse é o ponto de desenho do RA3: pare de pagar por disco local que você só enchia de dados frios. 10 TiB de armazenamento gerenciado = 10.240 GB × $0,024 = $245,76 por mês.
3. Computação serverless, RPU-hours por segundo com mínimo de 60 segundos a $0,375 por RPU-hour em us-east-1 (1 RPU ≈ 16 GB); a base de 4 RPU é $1,50 por hora; não há cobrança enquanto nenhuma consulta roda, e Spectrum mais Concurrency Scaling estão incluídos. Limite com as configurações de Max RPU-hours e Max capacity; Serverless Reservations cortam a computação em até 24% (1 ano) ou 45% (3 anos), a resposta do degrau 5 para uma carga serverless contínua.

Pause/resume suspende a cobrança de computação sob demanda: enquanto pausado você paga apenas o armazenamento de backup, o que torna clusters de dev/test e janelas de lote baratos. A armadilha: cobranças de reserved node continuam durante a pausa, porque você comprou o nó, não o tempo ligado. Concurrency Scaling rende uma hora grátis de crédito de cluster transitório a cada 24 horas por cluster ativo, acumulável até 30 horas (créditos não expiram enquanto o cluster vive), depois é cobrado por segundo com mínimo de um minuto apenas enquanto o cluster transitório serve consultas. E Spectrum em clusters provisionados cobra $5,00 por TB varrido, o mesmo medidor do Athena, então o degrau 1 (poda, layout colunar) dá desconto nos dois motores ao mesmo tempo.

5.1 Exemplo resolvido E5, o warehouse que dorme

---

6. A camada de BI: os dois eixos de preço do QuickSight e o pool de SPICE

O QuickSight precifica dois eixos ao mesmo tempo, e uma esteira de dashboards pode ser otimizada em qualquer um deles:

• Por usuário (Enterprise): Author $24 por usuário-mês, Reader $3 por usuário-mês, mais SPICE a $0,38 por GB-mês além dos 10 GB incluídos em cada Author provisionado. O Standard Edition é $9 por usuário-mês anual (ou $12 mensal) com 10 GB por usuário incluídos e $0,25 por GB adicional. Cada dataset de SPICE em Enterprise suporta no máximo 1 bilhão de linhas por 1 TB de tamanho.
• Capacidade: sessões de leitor vendidas em pacotes: 500 sessões por mês por $250 ($0,50 por sessão), com tiers anuais descendo até $0,40 em 50.000 sessões/ano, $0,28 em 200.000, $0,24 em 400.000,$0,20 em 800.000 e $0,16 por sessão em 1,6 milhão de sessões/ano. Uma sessão é um período de 30 minutos, não uma visualização, e o preço por capacidade é obrigatório para o refresh programático de dashboards.

O por-usuário vence para uma população conhecida e contínua; a capacidade vence para consumo espinhento, embarcado ou programático. A própria SPICE é um pool compartilhado por Região: capacidade comprada em uma Região não pode ser usada em outra, datasets permanecem na SPICE até alguém removê-los, e a compra automática de capacidade está ligada por default para contas criadas no console, a clássica catraca silenciosa que sobe o seu pool e nunca desce (desligá-la depois deixa o pool atual como a sua capacidade comprada). Por fim, a escolha de modo move o medidor: Import (SPICE) converte custo de consulta em um $/GB-mês fixo com atraso de refresh, enquanto Direct Query empurra cada interação de visualização de volta para Athena/Redshift, a economia de bytes varridos da seção 3, multiplicada pelas contagens de visualização de dashboard.

6.1 Exemplo resolvido E6: 10 Authors, 400 Readers, 500 GB de SPICE

• 📚 Você sabia? O preço de Reader é escrito apenas para interações de sessão manuais: a AWS reserva o direito de cobrar um leitor na taxa mais alta de Author se sessões de leitor forem usadas para consultas programáticas ou automatizadas. Analytics embarcados que consultam dashboards em um timer é o caminho documentado de choque de fatura, e é exatamente o uso que exige preço por capacidade em vez de por usuário (preço e FAQs do Amazon QuickSight, acesso em 2026-10-11).

---

7. Formas de streaming: shard-hours, GB-com-piso, incrementos de 5 KB, cluster-hours

Serviços de streaming parecem iguais em um diagrama de arquitetura e cobram quatro unidades diferentes. O resumo relevante para o lakehouse: Firehose + Kinesis são baratos por GB; MSK é caro por hora: escolha MSK apenas quando precisar de semântica Kafka que a alternativa não pode fornecer.

• Kinesis Data Streams, provisionado: shard-hours a $0,015 por shard-hour, unidades de payload PUT contadas em chunks de 25 KB a $0,014 por milhão, retenção estendida opcional a $0,020 por shard-hour, e enhanced fan-out a $0,015 por shard-hour por consumidor-shard.
• Kinesis on-demand Standard: por GB, com um piso no nível da conta de 25 MB/s ingeridos e 25 MB/s recuperados em todos os streams on-demand, streams pequenos podem pagar por throughput que nunca enviam. O Advantage on-demand (introduzido em 2025-11-04) remove a cobrança por hora do stream e corta a ingestão para $0,032/GB, com mínimo comprometido de 25 MiB/s; o lado a lado de 48 horas publicado pela AWS foi $2.071,75 (Standard) versus $823,44 (Advantage), cerca de 60% menor, aproximadamente $228.125 anualizados para aquela carga de trabalho, e a própria ressalva da AWS é que cargas espinhosas abaixo de 10 MiBps devem ficar no Standard. Retenção além de 24 horas custa Standard +$0,10/GB até 7 dias, contra $0,023 por GB-mês no Advantage além de 24 horas até 365 dias.
• Firehose: cobra GB ingeridos em incrementos de 5 KB (primeiros 500 TB a $0,029/GB), um registro de 3 KB é cobrado como 5 KB, com add-ons de conversão de formato, entrega em VPC e dynamic partitioning, e $0,045/GB ao entregar do Kinesis para tabelas Iceberg.
• MSK Serverless: cinco linhas de fatura: cluster-hours $0,75, partition-hours $0,0015, data-in $0,10/GB, data-out $0,05/GB, armazenamento $0,10/GB-mês. O exemplo resolvido oficial da AWS (31 dias, 100 partições, 100 GB/dia) totaliza $1.299,60: $558,00 + $111,60 + $310,00 + $310,00 + $10,00.

7.1 Exemplo resolvido E7: três formas de streaming, três faturas

---

8. Os multiplicadores silenciosos: KMS, data events do CloudTrail e a taxa do NAT

8.1 Custos de request do KMS e a alavanca das bucket keys

SSE-KMS em um lake cobra $1,00 por chave gerenciada pelo cliente por mês mais $0,03 por 10.000 requests acima de uma faixa grátis mensal de 20.000 requests. Em um lake de alto QPS, a linha de request regularmente ultrapassa a linha de GET do S3, e é por isso que as bucket keys do S3, que a AWS documenta como redutoras de custos do KMS em até 99%, são higiene obrigatória e não otimização. A alavanca companheira é data events do CloudTrail: a primeira cópia de management events é grátis (cópias extra $2,00 por 100.000), mas data events do S3 custam $0,10 por 100.000 events entregues: registrar data events do bucket inteiro em um lake ocupado é uma linha de fatura com cinco dígitos, e a correção é advanced event selectors com escopo em prefixos sensíveis (a análise de agregação de data events custa mais barato, $0,03 por 100.000). Advanced event selectors nunca se misturam com basic event selectors no mesmo trail, e cada trail suporta 500 deles.

8.2 NAT versus endpoints: a economia de rede de maior confiança

Cada GB através de um NAT gateway custa $0,045, mais $0,045 por hora por AZ enquanto provisionado e disponível. Gateway endpoints para S3 e DynamoDB são gratuitos, sem cobrança de processamento de dados, sem cobrança por hora, e são o caminho correto para qualquer frota de ETL residente em VPC falando com o S3. Interface endpoints cobram cerca de $0,01 por hora por AZ mais $0,01 por GB (tier do primeiro PB, depois $0,006 e$0,004), com cada endpoint-hour parcial cobrado como uma hora cheia. Uma frota em VPC que empurra tráfego do S3 pelo NAT carrega um acréscimo não forçado de 3 to 5× no seu networking de caminho de dados e perde a condition key aws:SourceVpce da qual o perímetro de rede da lição 14 depende.

8.3 Exemplo resolvido E8: side-quests de criptografia, auditoria e rede

---

9. Colocando a escada para trabalhar: verificações interativas nas próprias alavancas

9.1 Verificação interativa: combine a alavanca com o medidor que ela ataca

9.2 Verificação interativa: preencha as taxas das quais o desenho depende

9.3 Verificação interativa: ordene a escada antes de tocar em uma fatura

• 📚 Você sabia? A replicação pode ser apontada direto para uma classe de armazenamento de destino mais barata (DEEP_ARCHIVE, GLACIER, GLACIER_IR e companhia são todos destinos legais de replicação): um desenho genuíno de DR, já que a cópia cai fria sem que uma regra de lifecycle dispare nunca. O que ela não é, é um desconto: você paga pelas duas cópias mais as requests de replicação mais $0,015 por milhão de objetos por mês de monitoramento (documentação de replicação do Amazon S3, acesso em 2026-10-11).

---

Atualizações de 2026 (em outubro de 2026)

---

Casos Reais

A AWS publica como essa escada aparece em produção. Cada cifra abaixo é afirmação do cliente ou da AWS, não auditada, com a fonte nomeada para você conferir, o ponto examinável é o padrão: qual degraum se moveu, e em que direção.

Caso A, GE Aerospace: modernizando um operational data store no Redshift

Leia os $500.000 como estimativa de economia da própria GE, nunca como garantia da AWS ou uma taxa que você possa aplicar à sua esteira. O padrão transferível é a sequência: PoC primeiro, nove meses de migração em fases, fronteira de conformidade (GovCloud) tratada como uma entrada de arquitetura, e a vitória de custo chegando como subproduto de modernizar a carga de trabalho, não como um desconto comprado em um sistema superdimensionado.

Caso B, Transport for NSW: mais de 400 workflows de ETL migrados para o Glue, ~80% mais baratos

A leitura da lição 16 sobre o TfNSW é que os 80% vieram da troca de medidor e da mudança operacional juntas: uma plataforma licenciada cobra pela existência, o Glue cobra pelos DPU-segundos de fato usados. Mas note o que tornou a migração possível: suporte a Python e treinamento para mais de 30 pessoas: que é uma alavanca de gente, não de preço. Um terceiro ponto de referência do mesmo corpus da AWS: a Integral Ad Science rodava um workgroup do Athena por unidade de negócio com tags de faturamento por departamento e limites de consulta (AWS Big Data Blog, 2021-09-23), o desenho das seções 1.3 e 3.2, em produção.

• 📚 Você sabia? Os dois percentuais de manchete são páginas de cliente sem data, então elas carregam "acesso em outubro de 2026" em vez de uma data de publicação, e ambas descrevem migrações específicas, não garantias de serviço. O >$500.000 da GE Aerospace é uma estimativa; os ~80% do TfNSW cobrem custos de integração de dados especificamente, não a fatura inteira de analytics. Citar qualquer um deles como "Redshift economiza 70%" ou "Glue é 80% mais barato" é o tipo de deriva para o qual a disciplina de fontes deste curso existe para prevenir (estudos de caso da AWS, acesso em 2026-10-11).

Perguntas de Prática (Practice Questions)