BI com QuickSight e o Capstone Ponta a Ponta do Lakehouse

Dezesseis lições construíram algo que produz números: bronze no S3, silver e gold como tabelas Iceberg, um catálogo Glue, Step Functions segurando a agenda junta, Lake Formation decidindo quem pode ler qual linha, Macie achando os dados pessoais, Glue Data Quality recusando os lotes ruins, e uma escada de custo que ninguém pode pular. Nada disso é o ponto de um lakehouse. O ponto é que uma gerente regional em Frankfurt abre um link numa manhã de segunda-feira e vê as suas regiões, as suas lojas, a sua receita, em menos de dois segundos, e não vê as de ninguém mais.

Esta é a lição. A camada de BI é onde toda decisão de montante se paga ou te envergonha: uma permissão do Lake Formation ausente aparece como um dashboard vazio, um snapshot da SPICE aparece como um dashboard velho, uma escolha de coluna texto contra numérico aparece como segurança de nível de linha silenciosamente não funcionando, e uma consulta direta sem poda aparece na fatura do Athena três semanas depois. Você vai configurar QuickSight de ponta a ponta, depois dar um passo atrás e redesenhar o curso inteiro como uma arquitetura de referência com dezessete camadas, mais o plano de 30/60/90 dias que leva um time até lá.

Ao fim desta lição você será capaz de:

• dizer o que mudou e o que não mudou quando o QuickSight virou Quick Suite e depois Amazon Quick, e precificar um deploy real linha por linha;
• escolher entre SPICE e consulta direta usando o medidor de bytes varridos do Athena em vez de um feeling, e defender a escolha com aritmética;
• dimensionar um dataset de SPICE a partir de uma lista de colunas usando a fórmula de tamanho lógico, e agendar refreshes que nem colidem nem ficam velhos em silêncio;
• conectar uma fonte de lakehouse corretamente: Athena através do Lake Formation, um manifesto JSON do S3 para extracts, Redshift para cargas de trabalho densas de warehouse;
• construir a cadeia de conteúdo dataset → análise → dashboard → tema → pasta, e escolher uma família de visual de propósito;
• separar os três mecanismos de segurança de nível de linha e declarar, para cada um, a quem ele se aplica, que tipos de dados ele restringe, e quanto ele te custa;
• montar todas as dezessete camadas em uma arquitetura de referência e sequenciá-las em um plano de 30/60/90 dias;
• ler os resultados de QuickSight publicados pela Trustly como um praticante lê um caso: como um resultado de cliente com data, nunca como uma garantia de serviço.

---

1. Nomeando a coisa que você está configurando

Antes de um único ajuste: em 2025-10-09 a AWS anunciou que o "Amazon QuickSight está evoluindo para o Amazon Quick Suite", com a metade de BI renomeada para Quick Sight e "Além das capacidades de BI familiares (agora chamadas Quick Sight), o Quick Suite introduz várias funcionalidades movidas a IA" (AWS BI Blog, 2025-10-09). O manual de usuário hoje descreve o serviço como Amazon Quick, que "evoluiu a partir do Amazon QuickSight. O QuickSight continua como Amazon Quick Sight, um recurso dentro do Quick" (Quick User Guide, What is Amazon Quick?, acesso em 2026-10-11).

A metade operacional daquele anúncio é a parte que você de fato precisa:

"Seu ambiente QuickSight inteiro, incluindo dashboards, datasets e análises, permanece inalterado… Suas integrações de API existentes continuam funcionando como antes, e nenhuma migração de dados é necessária.": AWS BI Blog, 2025-10-09

e

"Todas as APIs, SDKs e integrações QuickSight existentes continuam funcionando sem mudanças.": Quick User Guide, acesso em 2026-10-11

Duas consequências para tudo abaixo:

1. ARNs e ações de IAM ainda dizem quicksight. Um ARN de usuário ainda é arn:aws:quicksight:{region}:{account}:user/{namespace}/{username}, a service role default ainda é aws-quicksight-service-role-v0, e cada API que você toca nesta lição (CreateIngestion, GenerateEmbedUrlForRegisteredUser, CreateAccountCustomization) mantém o seu nome antigo (AWS Machine Learning Blog, 2026-06-08; AWS Builder Center, 2026-03-27).
2. Tabelas de preços mudaram para o novo branding. As taxas abaixo foram lidas da página de preços do QuickSight em 2026-10-11, onde o painel do Quick Suite as carrega.

• 📚 Você sabia? O encurtamento de "Quick Suite" para "Amazon Quick" não tem data em lugar nenhum da documentação da própria AWS. Os posts de 2025-10-09 dizem Quick Suite; o manual de usuário simplesmente diz Amazon Quick, sem uma linha de anúncio para a segunda renomeação. A afirmação defensável é "anunciado como Quick Suite em outubro de 2025; até outubro de 2026 o manual de usuário chama o serviço de Amazon Quick": atribuir uma data precisa ao encurtamento seria inventar uma fonte.

---

2. Personas, edições e a pilha de preços de outubro de 2026

2.1 As três personas, e por que Admins faturam como Authors

Fonte de cada linha: página de preços e FAQs do QuickSight, acesso em 2026-10-11.

A armadilha naquela tabela é a linha do Admin: um Admin que "só gerencia usuários" ainda é um Author na fatura. A segunda armadilha é que Readers não seguram SPICE alguma: SPICE é propriedade da conta, não propriedade do usuário.

2.2 Duas edições, e só uma delas faz segurança de nível de linha

Fontes: página de preços, Data source quotas, Refreshing SPICE data, Using row-level security, Embedding overview: todas com acesso em 2026-10-11.

2.3 Exemplo resolvido E1: precificando um deploy real, linha por linha

Um time implanta 3 Authors, 1 Admin, 60 Readers, um dataset de SPICE de 52 GB, sem usuários Pro, sem Q topics, sem Dashboard Q&A (lista de us-east-1, em outubro de 2026).

Agora duas mudanças que parecem pequenas em um slide:

A taxa de infraestrutura dobrou a fatura por um flag de funcionalidade. Ela se aplica "se a sua conta tiver qualquer um dos seguintes: pelo menos um usuário Pro / Q&A habilitado via tópicos / Dashboard Q&A habilitado" (página de preços e FAQs, acesso em 2026-10-11), e, a parte que pega as pessoas, deletar os usuários Pro não a para enquanto ainda existir um Q Topic em qualquer Região da conta (AWS re:Post Knowledge Center, 2026-08-27).

---

3. SPICE: o que é, quanto custa, como você a enche

3.1 O motor em um parágrafo

SPICE é o Super-fast, Parallel, In-memory Calculation Engine: um snapshot materializado e atualizável do seu dataset, construído a partir de "uma combinação de armazenamento colunar, tecnologias in-memory… e geração de código de máquina" (AWS BI Blog, Best practices for Amazon QuickSight SPICE and direct query mode, 2024-07-17). Na edição Enterprise o snapshot é criptografado em repouso, gerenciado pela AWS por default, ou com uma chave gerenciada pelo cliente no AWS KMS, e criptografado em trânsito com TLS (mesma fonte; Importing data into SPICE, acesso em 2026-10-11).

Quatro propriedades decidem toda escolha de desenho que você vai fazer:

• A capacidade é agrupada por conta e por Região da AWS, não por usuário: "a capacidade SPICE é alocada separadamente por Região da AWS… compartilhada por todas as pessoas que usam QuickSight em uma única Região da AWS" (Managing SPICE memory capacity, acesso em 2026-10-11).
• A compra automática de capacidade está ligada por default para contas criadas no console, e "a compra automática de capacidade não suporta auto-decremento": ela pode crescer o seu pool, nunca encolhê-lo. Desligue-a com o pool super-alocado e a próxima ingestão ou falha de refresh.
• Você é cobrado pela consulta de origem na ingestão, não no momento da visualização: "se você usar uma fonte de dados que cobra por consulta, você é cobrado pela consulta dos dados quando cria o dataset pela primeira vez e depois quando atualiza o dataset" (Importing data into SPICE).
• Dashboards continuam servindo o snapshot anterior enquanto um refresh roda, e depois de um refresh falhado, sem banner de obsolescência no canvas por default.

3.2 Tamanho lógico: a aritmética que decide a sua fatura de capacidade

O que consome capacidade não é o arquivo Parquet no S3 e não é a contagem de linhas: é o tamanho lógico, calculado depois da coerção de tipos e das colunas calculadas:

Fonte: Importing data into SPICE, acesso em 2026-10-11. "Somente as mudanças salvas no dataset se aplicam à capacidade SPICE."

3.3 Exemplo resolvido E2: dimensionando o dataset capstone antes de ingerir

A tabela gold capstone gold.sales guarda 40.000.000 de linhas, cerca de 3 GB de Parquet no S3. O dataset de QuickSight usa esta SQL personalizada (note o que foi derrubado):

Tamanho lógico por linha:

Dois movimentos fizeram isso caber: derrubar colunas não usadas na SQL (uma coluna de texto customer_note com média de 200 caracteres teria acrescentado 24 + 200 bytes por linha: 8,96 GB sozinha, o que por si excederia o pool) e truncar o timestamp para uma data, o mesmo movimento que torna o refresh incremental e a segurança de nível de linha possíveis de modo algum.

• 📚 Você sabia? Os quatro passos de preparação de dados Append, Aggregate, Pivot e Unpivot não podem rodar no tempo de consulta: eles são exclusivos da SPICE, o que significa que o QuickSight os materializa na SPICE em vez de executá-los em cada carregamento de visual (SPICE-only features, acesso em 2026-10-11). Isso os torna a alavanca documentada de "pré-agregar para encolher o seu dataset": um passo de agregação aplicado no momento da autoria é pago uma vez por refresh em vez de em cada visualização.

3.4 Refresh: agendas, cotas e a falha que você não vai ver

Duas regras operacionais seguem diretamente. Espalhe as agendas para que os datasets não disparem todos no mesmo minuto (AWS re:Post, 2026-06-26), e trate um refresh falhado como um incidente, porque o dashboard vai felizmente continuar renderizando os números de ontem como se nada tivesse acontecido.

3.5 Melhores práticas de autoria em SPICE

1. Selecione colunas no momento da autoria. Cada coluna de texto que você arrasta para o dataset é cobrada a 24 + tamanho UTF-8 bytes por linha, para sempre. Desmarque o que nenhuma visualização usa.
2. Agregue antes de importar. Use o passo Aggregate exclusivo da SPICE, ou agregue na camada gold, o que é ainda melhor, quando um dashboard precisa de medidas por dia em vez de por transação.
3. Faça cast das chaves pelas quais você vai restringir. A segurança de nível de linha funciona apenas em campos texto, então faça cast de chaves de região numéricas ou de data para string na SQL do dataset (seção 7).
4. Agende depois do ETL, nunca perto dele. Um refresh completo diário às 04:00 que dispara antes do job silver-to-gold terminar importa o snapshot errado e o reporta confiante. CreateIngestion orientado a eventos a partir de Step Functions depois do job é a versão determinística; a agenda é apenas o chão.
5. Um dataset, muitos dashboards. O consumo em qualquer número de dashboards e usuários "não gera cobranças", o medidor é capacidade em GB-mês, não visualizações (página de preços, acesso em 2026-10-11).

---

4. SPICE contra consulta direta: a fatura do Athena é o desempate

4.1 O trade, enunciado nas duas direções

Fontes: Data source quotas (2026-10-11); melhores práticas do AWS BI Blog (2024-07-17).

4.2 O híbrido recomendado pela AWS

A própria orientação da AWS não é "escolha uma": use uma folha de aterrissagem em SPICE para KPIs agregados atualizados diária ou incrementalmente, mais uma folha de detalhe em consulta direta, e avise o leitor sobre a inconsistência de frescor entre elas (BI Blog, 2024-07-17). O padrão existe porque os dois modos de falha são opostos: a SPICE falha ficando velha, a consulta direta falhando ficando lenta e cara.

4.3 Exemplo resolvido E3, o mesmo dashboard, dois medidores

Cenário. 200 leitores, 4 visualizações de dashboard cada por dia, cada visualização varrendo 200 MB de Parquet com poda de partições em modo de consulta direta, contra os mesmos dados importados em um dataset de SPICE de 6 GB. Athena é $5,00 por TB varrido (preços do Amazon Athena, acesso em 2026-10-11).

O ponto de equilíbrio é aritmética, não opinião: o custo de capacidade da SPICE iguala o custo do Athena quando

Abaixo de cerca de 76 visualizações por dia, a consulta direta é mais barata e mais fresca; acima disso, a SPICE vence e continua vencendo, porque a linha da SPICE é plana na contagem de visualizações. A coluna sem poda é a que deveria te preocupar: a mesma forma de SQL sem poda de partições é 15x a fatura, e é por isso que os redutores da lição 09 são um pré-requisito desta lição em vez de um extra opcional.

4.4 Exemplo resolvido E4: a fatura do híbrido

Mesmo público, 4.000 visualizações por dia: 3.600 caem na folha de KPI em SPICE, 400 batem na folha de detalhe em consulta direta a 200 MB cada.

Acrescente a caixa de texto de disclaimer na folha de consulta direta, "linhas de detalhe são ao vivo; blocos de KPI atualizam diariamente às 04:00 UTC", e você tem o formato recomendado pela AWS com o seu custo quantificado.

• 📚 Você sabia? O Athena cobra bytes varridos, arredondados para cima para o megabyte mais próximo, com mínimo de 10 MB por consulta para fontes federadas, então um dashboard renderizando 40 visualizações pequenas em consulta direta pode cobrar 40 mínimos em vez de uma varredura mesclada. Mesclar filtros e emitir menos consultas e mais largas através de parâmetros de dataset é uma alavanca de custo tanto quanto de desempenho (preços do Amazon Athena, acesso em 2026-10-11).

As linhas se cruzam em cerca de 2.280 visualizações por mês: aproximadamente 76 por dia. À esquerda do cruzamento, a consulta direta é mais barata e mais fresca; à direita, a SPICE custa o mesmo quer 10 quer 10.000 pessoas olhem. A linha da SPICE também esconde uma cobrança fixa de ingestão de $0,45/mês (E3), que move o cruzamento apenas marginalmente.

---

5. Fontes do lakehouse: Athena, o manifesto do S3 e o Redshift

O QuickSight suporta uma lista longa de fontes, Athena, Aurora, Glue Data Catalog, OpenSearch, Redshift, Redshift Spectrum, S3, S3 Tables, RDS, mais BigQuery, Databricks, Snowflake, Trino e Q Business, com uma regra dura de posicionamento: "Amazon Redshift clusters, Amazon Athena databases, and Amazon RDS instances must be in AWS" (Supported data sources, acesso em 2026-10-11). Para este curso, três importam.

A regra de decisão deste curso: tudo que é governado fica atrás do Athena (ou do Redshift), nunca atrás de um manifesto. Um manifesto é um drop de arquivos: sem entrada de catálogo, sem time travel, sem grant do Lake Formation, sem filtro de dados.

Um manifesto como o de cima importa bem e ainda é a resposta errada para gold.sales: no momento em que governança de nível de linha, evolução de schema ou time travel importam, o caminho do Athena é o único que herda o que as lições 04, 07 e 12 construíram.

Dois detalhes de ligação que quebram em silêncio:

• A service role do QuickSight, por default aws-quicksight-service-role-v0, precisa dos seus próprios grants do Lake Formation, além dos grants dados a ARNs de usuário e de grupo do QuickSight (Using AWS Lake Formation with Amazon QuickSight, acesso em 2026-10-11; AWS Builder Center, 2026-03-27).
• Com S3 Tables (Iceberg gerenciado) o catálogo é s3tablescatalog, não o catálogo default do Glue: você precisa de glue:GetCatalog naquele ARN de catálogo, e precisa usar SQL personalizada, porque o navegador de tabelas só mostra o catálogo default (AWS Builder Center, 2026-03-27).

E a regra de ordem do próprio guia da AWS: faça a consulta funcionar no Athena primeiro, depois abra o QuickSight: um passo que separa um problema do Lake Formation de um problema do QuickSight.

---

6. O modelo de conteúdo: datasets, análises, dashboards, temas e pastas

Famílias de visual disponíveis em uma análise: barras e colunas (empilhadas), heat map, linha e área, dispersão, pizza e donut, treemap, funil, medidor/KPI, nuvem de palavras, box plot, histograma, mapa de dispersão, mapa em camadas, componente de imagem, Highcharts, tabelas e tabelas dinâmicas, e widgets de texto autonarrativo (histórico de documentos do Quick User Guide e documentação de forecast/insight, acesso em 2026-10-11).

Temas. Quatro ARNs de tema inicial vêm com o serviço, arn:aws:quicksight:aws:theme/CLASSIC, .../MIDNIGHT, .../SEASIDE, .../RAINIER, e o default da conta ou do namespace é definido através de CreateAccountCustomization / UpdateAccountCustomization com um DefaultTheme, o que exige que o tema seja compartilhado primeiro (Setting a default theme, acesso em 2026-10-11). Dashboards embarcados acrescentam tematização em runtime a partir do Embedding SDK 2.5.0 e superior (setTheme, setThemeOverride, até cinco temas pré-carregados).

Pastas (Enterprise). Pastas pessoais, pastas compartilhadas e pastas restritas compartilhadas, o tipo restrito é criado apenas pela API CreateFolder e força criados a partir do seu conteúdo a permanecerem dentro da árvore de pastas. Leia o boundary com cuidado: ele cobre análises, dashboards, datasets, fontes de dados e tópicos, mas não superfícies mais novas como agentes de chat, que ainda podem recuperar detalhes de um dataset dentro de uma pasta restrita (Organizing assets into folders, acesso em 2026-10-11).

---

7. Segurança de nível de linha: três mecanismos que não são intercambiáveis

Esta é a seção que decide se o seu dashboard capstone é uma vitória de governança ou um vazamento de dados. Existem três mecanismos de nível de linha, eles resolvem problemas diferentes, e nenhum deles se converte em outro automaticamente.

7.1 Mecanismo um: um dataset de regras de usuário ou de grupo (Enterprise)

Uma tabela de permissões anexada ao seu dataset: uma coluna para identidade (UserName e GroupName, ou UserARN e GroupARN) mais uma coluna por campo restrito. Você a anexa com "Conceder acesso ao dataset".

Fontes: Using row-level security e Using RLS with user-based rules, acesso em 2026-10-11.

Uma ingestão de dataset de regras quebrada deixa, portanto, o dataset restrito sem regras selecionadas, o que significa que os leitores não veem nada até você anexar regras novas. Monitore o status da ingestão e ligue alertas de e-mail de falha.

7.2 Mecanismo dois: regras baseadas em tag (apenas embedding anônimo)

Regras por tag mapeiam uma chave de tag para uma coluna e injetam valores em runtime através de SessionTags em GenerateEmbedUrlForAnonymousUser, configuradas via RowLevelPermissionTagConfiguration.TagRules (TagKey, ColumnName, TagMultiValueDelimiter, MatchAllValue). A declaração de escopo da AWS é inequívoca: regras baseadas em tag existem quando "você está usando dashboards embarcados e quer proteger dados para usuários não provisionados (usuários não registrados)", e elas são suportadas apenas para embedding anônimo: não para GenerateEmbedURLForRegisteredUser, não para o legado GetDashboardEmbedUrl, e não para identidade de console (Using RLS with tag-based rules, acesso em 2026-10-11).

7.3 Mecanismo três: Lake Formation na fonte, através do Athena

Registre a localização S3 no Lake Formation, revogue IAMAllowedPrincipals, e conceda SELECT e DESCRIBE (mais permissões de filtro de dados) para ARNs de usuário e de grupo do QuickSight em Enterprise, e também para a service role. Aqueles filtros são aplicados pelo Athena no tempo de consulta, que é o problema inteiro e a oportunidade inteira:

• um dataset em consulta direta respeita os filtros de dados do Lake Formation por usuário;
• um dataset em SPICE não, porque "ao usar SPICE, os dados são importados (replicados) e portanto as permissões na fonte não podem ser usadas" (AWS Big Data Blog, Automate replication of row-level security from AWS Lake Formation to Amazon QuickSight, 2025-05-07).

A AWS documenta exatamente duas pontes através daquela lacuna:

1. Propagação de identidade confiável (TIP). Apenas IAM Identity Center, apenas consulta direta: "QuickSight SPICE não pode ser usado com propagação de identidade confiável". A identidade do leitor se propaga ao Athena, ao Redshift, e ao Lake Formation quando Redshift Spectrum está envolvido, então permissões de schema, tabela, linha e coluna são aplicadas na fonte e isso "elimina a necessidade de criar regras adicionais de segurança de nível de linha e de coluna no QuickSight" (AWS BI Blog, 2024-05-16; entrada de histórico de documentos "Trusted identity propagation support with Athena data sources", 2025-06-30).
2. Replicação automatizada. Uma Lambda lê ListDataCellFilters e ListPermissions, transforma os predicados PartiQL em linhas do dataset de regras do QuickSight, e atualiza um dataset de RLS do QuickSight. Funciona com SPICE e sem Identity Center, mas precisa ser re-executada a cada mudança no Lake Formation, e a janela de atraso é um risco que é seu.

• 📚 Você sabia? A frase "tags viram RLS" descreve duas funcionalidades não relacionadas. Tags do Lake Formation dirigem alcance de tabela e coluna e não conseguem carregar filtros de dados de linha algum, enquanto regras por tag do QuickSight dirigem segurança de nível de linha apenas para embedding anônimo. Não existe funcionalidade documentada da AWS que mapeie uma na outra: para gerentes regionais registrados você precisa de um dataset de regras de usuário/grupo, ponto final (documentação do QuickSight e do Lake Formation, acesso em 2026-10-11).

7.4 Exemplo resolvido E5: qual mecanismo para qual público

---

8. Q, visuais de ML e embedding: mapa em nível de consciência

8.1 Funcionalidades de linguagem natural e generativas

A linhagem é três gerações de uma ideia: QuickSight Q, depois Amazon Q in QuickSight (GA em 2024-04-30), depois incorporada ao Amazon Quick (2025-10-09). O que importa operacionalmente em outubro de 2026:

• O Q&A está incluído nos assentos de Reader e Author, mas habilitá-lo custa dinheiro. Crie Q Topics (modelos semânticos curados com instruções personalizadas, criados por Author Pro) ou ligue o Dashboard Q&A de um clique (disponível desde 2025-01-31, sem necessidade de tópico), e qualquer um desses liga a taxa de infraestrutura de $250/mês por conta.
• Q Topics são cobrados e ainda criáveis. Nenhuma declaração da AWS deprecando-os foi encontrada, mesmo com o Dashboard Q&A sendo promovido como o caminho sem tópico.
• Capacidade em lote de perguntas do Amazon Q existe para cenários embarcados e de escala: 500 perguntas/mês por $250, 60.000/ano por $18.000, 600.000/ano por $120.000 (página de preços, acesso em 2026-10-11).
• Assentos Pro acrescentam construção de dashboard em linguagem natural, resumos executivos, data stories generativas e cenários.
• A barra de busca Q embarcada está rotulada como Classic; a substituição declarada pela AWS é a experiência de Q&A generativo embarcada.

8.2 Visuais movidos a ML

Fontes: Forecasting and what-if scenarios, Insights and anomaly detection, página de preços: todas com acesso em 2026-10-11.

8.3 Embedding, em nível de consciência

Apenas Enterprise, com dois caminhos de autenticação: usuários registrados (GenerateEmbedUrlForRegisteredUser, mais cópia de um clique) e usuários anônimos (GenerateEmbedUrlForAnonymousUser, tags de sessão para RLS, sem provisionamento de usuário). Allow-lists de domínio precisam usar HTTPS e comportar até 100 domínios, estáticos mais adições em runtime. O amazon-quicksight-embedding-sdk no npm fornece callbacks, ligação de controle, tematização em runtime e visualizações embarcadas compartilhadas.

A nota de segurança que a AWS adicionou em 2026-01-27 merece tratamento de aviso: orientação explícita contra vulnerabilidades de bypass de AllowedEmbeddingDomains, mais orientação de RLS multi-tenant: porque uma allow-list permissiva combinada com RLS baseado em tag é exatamente a combinação que um portal multi-tenant erra.

Preço para um público embarcado é ou Readers provisionados a $3 ou capacidade de sessões de leitor: uma sessão é um período de 30 minutos, 500 sessões custam $250 por mês com sessões excedentes a $0,50, e planos anuais vão de 50.000/ano a $20.000 descendo até $0,16 por sessão no plano de 1,6M/ano. Capacidade anual é também o que remove o branding "Powered by Quick", e o preço por capacidade é obrigatório para o refresh programático de dashboards.

• 📚 Você sabia? O preço de Reader é escrito apenas para interações de sessão manuais: a AWS "reserva o direito de cobrar o leitor na taxa mensal mais alta de author" se sessões de leitor forem usadas para consultas programáticas ou automatizadas (FAQs do QuickSight, acesso em 2026-10-11). Uma tela de parede que consulta um dashboard em um timer é o caminho documentado de choque de fatura, e é precisamente o uso que exige preço por capacidade em vez de assentos.

---

9. Exemplo resolvido capstone: vendas em gold para SPICE, para RLS regional, para um dashboard de gerente

Tudo das lições 01 to 16 agora converge em uma construção. Configuração: tabela Iceberg gold.sales com colunas order_id, order_ts, region, store_id, product, qty, revenue, 40.000.000 de linhas, cerca de 3 GB de Parquet no S3, registrada no Lake Formation, workgroup do Athena qs-bi.

Passo 1: Grants do Lake Formation. SELECT e DESCRIBE em gold.sales para o ARN do grupo QuickSight_Authors e para aws-quicksight-service-role-v0. Revogue IAMAllowedPrincipals da localização registrada.

Passo 2: Dataset sobre o Athena, em modo SPICE. SQL personalizada com colunas não usadas derrubadas, order_ts truncada para order_day, region com cast para texto (RLS precisa de texto). Tamanho lógico 5,68 GB (E2), dentro do pool incluído de 20 GB.

Passo 3, Refresh. Refresh completo diário às 04:00 UTC depois do job silver-to-gold, mais uma chamada CreateIngestion orientada a eventos a partir de Step Functions quando aquele job termina, a agenda é o chão, o evento é a verdade. Look-back incremental semanal de 7 dias em order_day se a tabela for pesada em append. Mantenha-se abaixo do teto de 32 refreshes completos sob demanda a cada 24 horas.

Passo 4: Dataset de regras de RLS. Crie rls_region_rules com colunas GroupARN, region; as linhas mapeiam arn:…:group/default/regional-managers-eu para EU e …-us para US; marque-a com UseAs: RLS_RULES, o que é irreversível. Anexe-a ao dataset com "Conceder acesso ao dataset".

Passo 5: Verificar de três maneiras. O autor vê todas as regiões (donos de dataset não são restringidos); um membro de regional-managers-eu vê apenas EU; uma exportação em CSV respeita a mesma restrição.

Passo 6: Construir e publicar. Uma folha de KPI (receita, pedidos, valor médio de pedido por região), uma folha de tendência com um forecast de ML de 14 períodos, e um insight de anomalia na receita diária; publique, compartilhe com o grupo como Reader, e assine os gerentes regionais em um relatório de e-mail agendado (a entrega de e-mail agendada respeita o RLS).

Passo 7: Precificar (us-east-1, em outubro de 2026):

O que esta construção prova. Cada lição anterior é estrutural: sem a lição 04 a tabela é uma pilha de arquivos; sem a 07 o Athena não resolve gold.sales; sem a 12 o gerente vê todas as regiões; sem a 15 o dashboard reporta dados ruins confiante; sem a 16 o fallback de consulta direta custa discretamente mais do que a linha inteira de BI.

---

10. O capstone: dezessete camadas como uma arquitetura de referência

Abaixo está o curso inteiro como um único diagrama. Leia-o como uma espinha correndo da esquerda para a direita (ingerir, armazenar, catalogar, transformar, consultar, servir), com planos de controle enrolados em volta (orquestração, governança, privacidade, segurança, qualidade, custo), e note que o QuickSight é o único nó que um usuário de negócio toca algum dia.

10.1 As dezessete camadas, e a decisão que cada uma delas detém

• 📚 Você sabia? A própria página What is a Data Lakehouse? da AWS nomeia a mesma espinha que esta tabela descreve, ingestão, armazenamento, metadados, API, semântica/consumo, e a camada semântica é onde as ferramentas de BI se encaixam. As dezessete lições são uma expansão das cinco camadas publicadas da AWS nas decisões serviço a serviço que um time de fato tem que tomar, e é por isso que o diagrama capstone tem dezessete caixas mas apenas cinco colunas de fluxo (páginas What-is da AWS, acesso em 2026-10-11).

---

11. O roteiro de implementação de 30/60/90 dias

Uma arquitetura de referência é uma imagem; um roteiro é uma ordem de operações. A regra que governa a sequência é simples: nada de montante pode ser construído antes que a coisa da qual ele depende exista e tenha sido verificada. Você não consegue conceder em uma localização não registrada, não consegue fazer refresh antes de existir uma tabela, não consegue restringir linhas em uma coluna que ainda é numérica.

11.1 Exemplo resolvido E7: dimensionando o público embarcado antes de comprar qualquer coisa

Uma ISV embarca um dashboard em uma aplicação multi-tenant para 50.000 visitantes mensais, com média de 2 sessões de 30 minutos cada: 100.000 sessões por mês, ou 1,2 milhão por ano.

Leia isso como um exercício de aritmética, não como uma fórmula publicada pela AWS: a AWS não publica orientação de ponto de equilíbrio para capacidade contra assentos, e a definição de sessão de 30 minutos significa que um usuário que reabre um dashboard quatro vezes por dia consome quatro sessões. O que os números estabelecem é a direção: com 100.000 sessões por mês, o preço por assento não é uma opção séria; a capacidade anual é cerca de 2,3x mais barata que a capacidade mensal para o mesmo volume; e apenas o plano anual remove o branding "Powered by Quick" e habilita o refresh programático de dashboards.

---

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

---

Casos Reais

Cada cifra abaixo é um resultado de cliente que a AWS escolheu publicar, nunca uma promessa da AWS. As páginas de estudo de caso não trazem data de publicação, então o que elas trazem é uma data de acesso: acesso em outubro de 2026.

Caso A, Trustly: insights 4x mais rápidos, custo 50% menor, usuários de 80 para 300

Lendo como um praticante. Três alavancas separadas se moveram aqui, e valem a pena separá-las: o cadência de 15 minutos é uma decisão de agenda de refresh da SPICE (seção 3.4); o crescimento de usuários a custo menor é uma decisão de economia por-assento contra capacidade (exemplo resolvido E8 abaixo); e os 89% de precisão em 15.000 perguntas são um resultado de cliente sobre um conjunto específico de perguntas: não uma garantia de precisão do Amazon Q, e não uma afirmação que você possa reformular como "o Amazon Q tem 89% de precisão".

Caso B: dois resultados de QuickSight de apoio do mesmo corpus

Ambos são resultados de cliente, não garantias de nível de serviço, e ambos descrevem migrações específicas, que é o único modo que este curso permite citar uma porcentagem.

Caso C, o ponto de equilíbrio da Trustly, computado a partir das taxas publicadas

Tome os 300 usuários publicados pela Trustly e as taxas de outubro de 2026 da seção 2, depois encontre a contagem de sessões em que Readers provisionados e capacidade de sessões de leitor custam o mesmo:

Isso é aritmética sobre taxas publicadas, não uma fórmula da AWS: a AWS não publica orientação de ponto de equilíbrio, e uma "sessão" é um período de 30 minutos, então um leitor que reabre um dashboard três vezes em uma hora consome três sessões. A pergunta transferível para qualquer deploy de BI é a que este exercício força: quantas sessões de 30 minutos um leitor real consome por mês? Meça antes de se comprometer, porque aquela resposta decide se uma esteira de 300 leitores custa $900,$600 ou $1.500.

• 📚 Você sabia? A cadência de 15 minutos da Trustly é exatamente o intervalo mínimo de agenda que o QuickSight oferece: as frequências vão de "A cada 15 minutos, A cada 30 minutos, Por hora, Diariamente, Semanalmente ou Mensalmente", e a ingestão acontece em até 10 minutos do horário agendado (Refreshing SPICE data, acesso em 2026-10-11). Um dashboard de "15 minutos" é na verdade um dashboard de 15 a 25 minutos, e é por isso que um carimbo visível de "data as of" no canvas é prática padrão em vez de decoração.

Perguntas de Prática (Practice Questions)

Doze itens, todos na série lh-17-qN: uma resposta correta, três ou quatro distratores, com o teardown dentro de cada explicação. Preços de lista de us-east-1 em outubro de 2026.