Apps no Amazon Quick vs. App Studio vs. build próprio
Toda empresa em que trabalhei tem a mesma dívida invisível: entre trinta e trezentas planilhas que ninguém versiona, alimentadas por exportações manuais de quatro sistemas diferentes, e que ainda assim entram em decisão de crédito, capacity plan e fechamento. O anúncio de 1º de setembro de 2026, construir apps no Amazon Quick descrevendo o que se quer em linguagem natural, mira exatamente essa dívida. O risco é trocar planilha não governada por app não governado, agora com conector de escrita e fatura da AWS. Então não escrevi um review do recurso: escrevi o bake-off que eu faria antes de aprovar o primeiro app, com as quatro rotas que realmente competem por esse trabalho.
O que a GA de 1º de setembro realmente entrega
A documentação de Apps in Quick é mais reveladora que o anúncio. Sete capacidades importam para arquitetura: autoria conversacional (o agente escreve o código enquanto você assiste), embed de visuais do Quick Sight dentro do app, action connectors que chamam APIs externas, inferência de fundação embutida para sumarização e classificação, leitura de documentos das spaces, armazenamento chave-valor persistente entre sessões e publicação em um clique com o SSO do Quick.
Leia de novo a combinação "action connectors" + "persistent key-value storage". Isso não é um dashboard bonito: é um app com estado próprio e caminho de escrita para sistemas de terceiros, autorado por conversa, publicado por um clique. É exatamente a categoria de artefato que, em ambiente financeiro, um comitê de mudança quer ver com dono, versão e rollback.
O posicionamento também importa. O Quick é a evolução do QuickSight num workspace agêntico, e a documentação já oferece BYOI: Bring Your Own Amazon Q Business Index e a conexão de knowledge bases gerenciadas do Bedrock. Ou seja: a AWS está costurando o índice do Q Business e o conhecimento do Bedrock para dentro do Quick. Se a sua empresa já tem investimento em qualquer um dos dois, a rota de menor atrito passa a ser essa, e isso pesa mais na decisão do que qualquer benchmark de "quantos minutos para o primeiro app".
As quatro rotas que realmente competem
Comparar Apps no Quick com "low-code" em geral não ajuda ninguém. Na prática, quando alguém pede um tracker interno na minha frente, existem quatro destinos possíveis.
Apps no Amazon Quick. Autoria pelo próprio usuário de negócio, dentro do workspace onde ele já faz chat, pesquisa e BI. Cobrança por assento. Disponível para Plus, Professional e Enterprise desde 1º de setembro de 2026.
AWS App Studio. O outro construtor da AWS por linguagem natural, GA desde novembro de 2024, mirando "profissional técnico", gerente de projeto de TI, engenheiro de dados, arquiteto. Conecta a mais de 200 serviços AWS e a terceiros via conectores de API/OpenAPI. Cobra US$ 0,25 por usuário-hora do app publicado; o ambiente de construção é gratuito.
Build sob medida. Amplify/AppSync + Lambda + DynamoDB + Cognito, com o código num repositório, PR, teste e pipeline. Caro em engenharia, barato em auditoria.
Nenhum app. Um dashboard do Quick Sight mais um Quick Flow. Metade dos pedidos de "app interno" que eu recebo é, na verdade, um número numa tela e um e-mail disparado quando ele passa de um limiar. Essa rota tem que estar na mesa, senão a comparação vira uma disputa entre construtores quando a resposta certa era não construir.
Head-to-head: as dimensões que decidem
| Apps no Amazon Quick | AWS App Studio | Build sob medida | Sem app (Quick Sight + Flows) | |
|---|---|---|---|---|
| Quem constrói | O próprio usuário de negócio, por conversa | Profissional técnico (TI, dados, arquitetura) | Time de engenharia com backlog e prioridade | Analista de BI em horas, não semanas |
| Unidade de cobrança | Assento/mês (US$ 20 Plus e Pro; US$ 40 Enterprise) | US$ 0,25 por usuário-hora do app publicado | Consumo dos serviços + custo de engenharia | Já incluso no assento Quick existente |
| Piso fixo | US$ 250/conta/mês de infra em Pro e Enterprise | Nenhum; ambiente de construção gratuito | Baixo em serviço, alto em pessoas | Nenhum adicional |
| Onde vive o código | Gerado e hospedado dentro do Quick | Gerado e operado pelo App Studio | No seu Git, com diff e rollback | Não há código de aplicação |
| Identidade e autorização | Herdada do Quick; RBAC/SSO listado como Enterprise | Modelo próprio do App Studio sobre conectores | Cognito/IAM com entitlement por linha se você escrever | Regras de dataset do Quick Sight, já auditadas |
| Escrita em sistema de registro | Sim, via action connectors autorados por conversa | Sim, via conectores de API/OpenAPI | Sim, com idempotência e retry que você controla | Não; leitura e notificação apenas |
| Evidência para auditoria | A confirmar: diff entre versões do app gerado | Versionamento do builder, sem repositório próprio | Commit, PR, pipeline, evidência nativa | Linhagem do dataset; superfície mínima |
| Pegada regional | Segue a região da assinatura Quick | Só US West (Oregon) e Europe (Ireland) | Qualquer região, inclusive sa-east-1 | Segue a região da assinatura Quick |
| Tempo até a v1 | Minutos, pelo próprio dono do processo | Horas a dias, com alguém técnico no volante | Semanas, competindo com o roadmap | Horas |
| Custo de saída | Alto: lógica e estado presos ao workspace | Alto: sem artefato portável do app | Baixo: é código seu | Baixo: SQL e dataset são portáveis |
A conta que quase ninguém faz: assento contra hora-usuário
As duas rotas AWS cobram em unidades incomparáveis, e é aí que a decisão vira FinOps. Um assento Quick Enterprise custa US$ 40/usuário/mês; o App Studio cobra US$ 0,25 por usuário-hora. O ponto de virada é aritmética simples: US$ 40 ÷ US$ 0,25 = 160 horas-usuário por mês. Um mês útil inteiro tem cerca de 168 horas. Ou seja, se o app for a única razão para comprar o assento, o App Studio só perde quando a pessoa vive dentro do app em tempo integral.
O cenário realista é o inverso. Quarenta usuários ocasionais, 3 horas por mês cada: 120 horas-usuário: US$ 30/mês no App Studio. Os mesmos quarenta em Enterprise custam 40 × 40 + 250 de taxa de infraestrutura = US$ 1.850/mês, ou US$ 22,2 mil por ano. Sessenta vezes mais caro para o mesmo app.
Agora inverta: se os 250 usuários já têm assento Quick porque usam chat, pesquisa e BI, o custo marginal do app tende a zero e o App Studio vira uma linha nova na fatura. A pergunta certa não é qual serviço é mais barato, é se o assento já está comprado.
Dois detalhes escondidos. Primeiro, a taxa de US$ 250/conta/mês em Professional e Enterprise é um piso: com 10 usuários, o efetivo salta para US$ 65/usuário. Segundo, a página de preços mete horas de agente na conta: 4 h/mês em Professional, 8 h em Enterprise, US$ 3 por hora de agente excedente. Iterar app por conversa consome exatamente esse recurso. Confirme com o time de conta se essas horas são por usuário ou por conta antes de liberar cem pessoas para "descrever o que quiserem".
Triagem: três perguntas antes de escolher o construtor
O erro comum é começar pela ferramenta. Eu começo pela natureza do que o app faz, escrita, evidência e perfil de uso, e deixo a ferramenta cair como consequência das três respostas.
- Escreve no SoR? / Writes to SoR? · Salesforce, ServiceNow, ERP
- Vira evidência? / Regulated evidence? · fechamento, risco, auditoria
- Usuários × horas / Users × hours · break-even: 160 h/user/month
- Apps in Quick · conversational authoring, 1-click publish
- Action connectors + knowledge bases · MCP, S3, Drive, OneDrive
- Key-value storage · state across sessions
- App Studio · $0.25 / user-hour
- Oregon + Ireland only · no sa-east-1
- Amplify / AppSync + Lambda · code in Git, PR, tests
- DynamoDB + Cognito · row-level entitlement
- CI/CD pipeline · diff, rollback, evidence
- Quick Sight + Quick Flows · dashboard + automation
Matriz de decisão
Apps no Amazon Quick
- Custo marginal próximo de zero se os assentos já existem
- Embed nativo de Quick Sight e integração com spaces e knowledge bases
- Dono do processo constrói e itera sem fila de TI
- É a direção estratégica: BYOI traz o índice do Q Business para dentro
- Assento é caro para usuário ocasional; piso de US$ 250/conta em Pro e Enterprise
- RBAC/SSO e soberania de dados aparecem só no Enterprise
- Iteração conversacional consome horas de agente (US$ 3/h de excedente)
- Custo de saída alto: lógica e estado ficam no workspace
Melhor escolha quando a população já é assinante Quick e o app é read-mostly.
AWS App Studio
- US$ 0,25/usuário-hora é imbatível para uso esporádico e cauda longa
- Ambiente de construção gratuito e 250 horas-usuário de teste
- Alcance a 200+ serviços AWS e a terceiros por conectores de API/OpenAPI
- Só Oregon e Irlanda, inviável para dado que precisa ficar no Brasil
- Sem novas regiões desde o GA de novembro de 2024
- Exige alguém técnico no volante, não é autoatendimento de negócio
Ganha no custo por usuário ocasional, perde na pegada regional e na trajetória do produto.
Build sob medida (Amplify/AppSync)
- Diff, PR, teste e rollback: evidência de auditoria por construção
- Entitlement por linha e idempotência sob seu controle
- Qualquer região, inclusive sa-east-1; custo de saída baixo
- Semanas de engenharia competindo com o roadmap do produto
- Você herda operação, patch e plantão de mais um app interno
Reserve para o que escreve em sistema de registro ou vira evidência regulatória.
Não construir app (Quick Sight + Flows)
- Custo incremental zero e superfície de risco mínima
- Reaproveita linhagem e permissão de dataset já auditadas
- Entrega em horas e morre sem dor quando não for mais útil
- Não cobre entrada de dados nem fluxo de aprovação
- Frustra quem pediu um "app" e recebeu um gráfico
A opção default. Só saia dela quando houver escrita ou fluxo de verdade.
"Respeita suas políticas de acesso", o que isso significa e o que não significa
Essa frase do anúncio é verdadeira e insuficiente. O que a documentação descreve é propagação de identidade na fronteira do conector: a integração com Salesforce ou ServiceNow carrega a identidade do usuário, e o que ele não pode ver lá, não vê aqui. Isso é bom e é diferente de entitlement por linha dentro do app. Se o app junta pipeline do Salesforce com custo de um data warehouse e devolve margem por cliente, a autorização do resultado combinado é uma propriedade nova, que nenhum conector garante sozinho.
O teste que eu exijo antes de publicar não é funcional, é negativo: pegue um usuário sem acesso à conta X no CRM, abra o app publicado e prove que ele não vê a conta X, nem na tabela, nem no total, nem na resposta do bloco de inferência. Agregado vaza. Sumarização por modelo de fundação vaza com elegância.
Depois vêm as perguntas de operação, que valem mais que qualquer demo: existe diff entre a versão de hoje e a de março do app gerado? Quem aprova a promoção? Qual sinal chega ao CloudTrail e ao seu SIEM quando um action connector escreve num sistema de registro? Qual é o comportamento sob falha do conector, retry, idempotência, escrita parcial?
E há a camada de licença virando restrição de arquitetura: a página de preços coloca RBAC/SSO e soberania de dados no Enterprise. Numa instituição regulada, a federação de identidade não é opcional, então o preço real não é US$ 20, é US$ 40 mais os US$ 250 de infraestrutura. Decida o tier na fase de arquitetura, não na renovação.
O ponto de virada real não é técnico
US$ 40 de assento Enterprise equivalem a 160 horas-usuário no App Studio, quase um mês útil inteiro dentro do app. Isso significa que, por app isolado, o App Studio quase sempre ganha em custo. O Quick só ganha quando o assento já foi comprado por outro motivo (chat, pesquisa, BI). Logo, a decisão de plataforma vem antes da decisão de app: se o Quick já é o workspace da empresa, construir fora dele é pagar duas vezes. Se não é, um único app não justifica adotá-lo.
Como isso dá errado em produção
- Publicar "para a organização inteira" com um clique num modelo de assento, a distribuição vira um evento de custo, não um evento de adoção.
- Tratar o app conversacional como planilha descartável e descobrir, no fechamento, que um número regulatório sai de um artefato sem versão nem dono.
- Confundir propagação de identidade no conector com autorização do resultado agregado, e nunca rodar o teste negativo.
- Liberar action connectors de escrita antes de definir retry, idempotência e o sinal que chega ao SIEM quando o app altera um sistema de registro.
- Escolher o App Studio para dado que precisa ficar no Brasil, ignorando que ele só existe em Oregon e Irlanda.
- Deixar cem pessoas iterando apps por conversa sem saber se as horas de agente incluídas são por usuário ou por conta.
Leitura pelo Well-Architected
Segurança
Identidade herdada é ponto de partida, não conclusão. Exija teste negativo por perfil, revise action connectors de escrita como mudança em sistema de registro e trate o tier de licença (RBAC/SSO no Enterprise) como requisito de segurança, não de compras.
Confiabilidade
O app depende de sistemas de terceiros via conector. Defina o comportamento esperado quando o Salesforce ou o ServiceNow degrada: dado obsoleto visível, falha explícita ou escrita em fila com idempotência.
Três perguntas que sempre aparecem
Isso substitui o AWS App Studio?
Formalmente não: o App Studio não aparece na atualização de disponibilidade de serviços de março de 2026 e segue GA. Na prática, ele não ganhou região nova desde novembro de 2024 e continua em Oregon e Irlanda, enquanto o Quick recebe BYOI, knowledge bases do Bedrock e agora apps. Eu leio isso como direção de investimento e planejo de acordo.
Posso construir apps no tier Free?
O anúncio diz que a construção de apps está disponível para Plus, Professional e Enterprise a partir de 1º de setembro de 2026, enquanto a página de preços lista "no-code apps" entre os recursos do Free. As duas páginas não estão alinhadas, confirme com o seu time de conta antes de desenhar o rollout em cima do Free.
Qual é o primeiro app que eu deixaria alguém construir?
Um que só lê, tem menos de vinte usuários nomeados, substitui uma planilha existente e não produz número que entra em relatório externo. Se ele sobreviver a um trimestre com uso real, aí discuto conector de escrita.
Eu não abriria a construção de apps para a empresa inteira; abriria para um piloto de dois processos com dono nomeado e data de revisão em 90 dias. A lição que me custou caro foi outra: em um banco, matamos uma planilha crítica substituindo-a por uma ferramenta interna melhor, e seis meses depois descobrimos que o time de risco tinha voltado à planilha porque a ferramenta não conseguia mostrar como o número de março foi calculado. Capacidade de reproduzir o passado vale mais que velocidade de construir o presente. Por isso a minha régua para qualquer app conversacional é uma só pergunta: se o auditor pedir a diferença entre a versão de hoje e a de três meses atrás, eu consigo mostrar? Se a resposta for não, o app pode existir, mas não pode ser fonte de número oficial.
Recomendação
Se a sua empresa já paga assentos do Amazon Quick, Apps no Quick é a escolha certa para apps read-mostly: custo marginal próximo de zero, embed de Quick Sight, identidade já resolvida na fronteira do conector e alinhamento com a direção do produto (BYOI, knowledge bases do Bedrock). Se você não é assinante, um único app não justifica US$ 40/usuário mais US$ 250/conta: o App Studio entrega o mesmo resultado por US$ 0,25 a hora-usuário: desde que o dado possa viver em Oregon ou na Irlanda, o que elimina boa parte dos casos brasileiros regulados. Para qualquer coisa que escreva em sistema de registro ou sustente número de relatório externo, continue no build sob medida: você está comprando diff, rollback e evidência, não tecnologia. E antes de tudo isso, teste a hipótese barata, metade desses pedidos morre com um dashboard do Quick Sight e um Quick Flow, e essa é a arquitetura mais elegante das quatro.
Referências
Continue lendo
Deep dives de arquitetura, AWS, IA e mercado: direto no seu email. Grátis.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Uma resposta focada sobre este artigo, do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar, você também recebe a newsletter. Sem senha.