Trilhas AWS: escolha o tema, comece no seu nível

Caso de uso

Uma clínica recebe guias e pedidos de exame em PDF e foto, e hoje uma pessoa digita cada campo no sistema de agendamento. O Textract extrai os campos estruturados do documento, o Comprehend sinaliza onde há dado pessoal, e o sistema apresenta o formulário já preenchido para a recepcionista confirmar. A pessoa deixa de digitar e passa a revisar. O ganho é medível porque a clínica sabia quanto tempo levava a digitação antes.

Caso de uso

Uma operação de suporte tem centenas de páginas de política, contrato e procedimento, e o time novo demora semanas para achar a resposta certa. Uma base de conhecimento indexa esse material, o assistente responde citando o trecho e o documento de origem, e o guardrail bloqueia resposta que não esteja embasada na fonte. O atendente confere a citação em vez de confiar no texto gerado. A permissão do índice segue a permissão original do documento, então quem não podia ler o contrato continua não podendo.

Caso de uso

Uma distribuidora recebe pedido por e-mail em texto livre, em formatos diferentes por cliente. Um agente interpreta o pedido, consulta preço e estoque no ERP através de ferramentas expostas por um gateway, verifica a situação de crédito do cliente e prepara a ordem. A política determina que pedido acima de um limite, ou de cliente com restrição, para para aprovação humana. Cada passo fica rastreado, e a avaliação contínua compara o que o agente decidiu com o que o time comercial decidiria. O agente não "tem acesso ao ERP": ele tem acesso a quatro operações específicas, com identidade própria e registro.

Caso de uso

Uma aplicação web em .NET rodando em duas instâncias EC2 que ninguém reinicia sem avisar no grupo. O deploy é feito por acesso remoto à máquina, copiando arquivos publicados. O banco é um SQL Server na mesma VPC, em instância própria, com backup por script agendado. O sistema funciona. O problema é que a cada patch de sistema operacional o time perde uma noite, o ambiente de homologação divergiu do de produção há mais de um ano e a pessoa que montou o servidor original saiu da empresa.

O caminho neste nível não é quebrar em microsserviços. É: containerizar a aplicação como está, colocar a imagem no ECR, subir em Fargate atrás de um ALB, mover o banco para RDS, e descrever tudo isso em IaC. A arquitetura lógica continua a mesma. O que muda é que o ambiente vira código, o deploy vira pipeline e o patch vira responsabilidade da AWS.

Caso de uso

Um monólito de faturamento com cerca de 15 pessoas no time e release mensal com janela de madrugada. O sistema tem um módulo de emissão fiscal que muda toda semana por mudança de regra, e um módulo de cadastro que não muda há dois anos. Os dois são deployados juntos, então a regra fiscal nova espera a janela mensal, e a janela mensal é arriscada porque leva junto tudo o que foi mexido no mês.

O corte aqui é pela taxa de mudança: emissão fiscal sai primeiro, atrás de uma regra de path no ALB, com o próprio banco para o que é dela e evento no EventBridge avisando o monólito do que foi emitido. Antes disso, o time roda o Babelfish Compass sobre as procedures T-SQL, porque metade da regra fiscal vive em stored procedure, e o relatório é o que vai dizer se a regra viaja para o serviço novo ou se fica no SQL Server por mais um ciclo.

Caso de uso

Uma plataforma com seis times de produto e cerca de 40 serviços em EKS. Cada time montou seu próprio Helm chart, três padrões de log convivem, o upgrade de versão do Kubernetes é empurrado há dois ciclos porque ninguém quer ser o dono da quebra, e a conta consolidada da AWS não é atribuível a nenhum produto específico, então a conversa sobre custo termina sempre em "vamos pedir para todo mundo economizar".

O trabalho aqui não é técnico no sentido de escrever código novo. É definir o workload como unidade (cada serviço de produto é um workload registrado), avaliar o EKS Auto Mode contra o requisito de vida de nó de 21 dias, publicar um template de serviço que já nasce no padrão e ligar alocação de custo por tag antes de qualquer promessa de economia.

Caso de uso

Uma empresa de serviços suspeita que a IA "ainda não chegou" na operação. Ao cruzar Cost Explorer com CloudTrail, aparecem chamadas a modelos em três contas diferentes, de times distintos, nenhuma com registro de invocação habilitado e nenhuma com política publicada. O primeiro entregável não foi bloquear nada. Foi produzir a lista: qual conta, qual time, qual dado, qual finalidade. A decisão de o que permitir veio depois, e veio informada.

Caso de uso

Um assistente interno responde dúvidas sobre contratos, com RAG sobre uma base documental. Três controles mudam o perfil de risco: o filtro de informação sensível mascara PII na saída, evitando que um dado pessoal presente no documento fonte seja repetido para quem não deveria vê-lo; o contextual grounding check derruba resposta que não está sustentada no trecho recuperado; e a role da aplicação enxerga apenas o índice daquele caso de uso, de modo que uma pergunta criativa não alcança documento de outra área. O prompt continua importando, mas ele deixou de ser a única linha de defesa.

Caso de uso

Um agente de atendimento consulta pedido, escreve nota no CRM e dispara e-mail ao cliente. Cada ferramenta, isolada, é inofensiva e passou na revisão. Encadeadas, elas permitem que uma entrada manipulada leve o agente a ler o dado de um cliente, gravá-lo onde não deveria e enviá-lo para fora, sem que nenhuma permissão individual tenha sido violada. O controle que endereça isso não é um prompt melhor: é política no Gateway que barra a combinação antes da execução, permission boundary que limita o teto da role, e trace que permite reconstruir o que aconteceu.

Caso de uso

Uma startup de SaaS B2B com dois fundadores sobe o MVP em uma única conta AWS, criada no cadastro padrão, sem prestar atenção no plano escolhido. Roda três meses, valida a hipótese e decide aplicar ao Activate para escalar. Na aplicação, esbarra no requisito de plano da conta e descobre que a conta em que está todo o produto não é a conta que deveria ter criado. O problema não foi técnico: foi uma caixa de seleção no cadastro, marcada quando ninguém estava pensando em crédito.

Caso de uso

Uma plataforma de agendamento tem uso concentrado em horário comercial e praticamente nenhum tráfego à noite, no fim de semana e em feriado. O banco provisionado fica ligado 24 por 7 e responde pela maior fatia do consumo, mas isso está invisível porque o crédito absorve tudo. Ao migrar para Aurora serverless com mínimo de 0 ACU e auto-pause, a instância passa a pausar nas janelas ociosas, e o crédito para de ser consumido por horas em que a empresa não tem cliente ativo. O crédito não aumentou: o desperdício por hora ociosa diminuiu, e o prazo até a expiração passou a cobrir mais experimentos.

Caso de uso

Um SaaS multi-tenant com plano único descobre, ao alocar custo por tenant sobre dado padronizado em FOCUS, que uma minoria de contas grandes concentra a maior parte do consumo de compute e inferência, enquanto paga o mesmo que as contas pequenas. A conclusão não é técnica: é de pricing. A empresa passa a ter, na mesma tabela, o custo por tenant, o custo por feature e a projeção da fatura sem crédito. Com isso, entra na negociação da rodada com margem por cliente conhecida, em vez de com um custo agregado que não explica nada.

Caso de uso

Uma indústria de médio porte pediu orçamento pra migrar 140 servidores de um datacenter próprio. O inventário com utilização real mostrou que 30 estavam abaixo de 5% de CPU e memória, sem nenhuma conexão de entrada em 90 dias: sistemas de um ERP substituído anos antes, que ninguém desligou por medo. Outros 12 rodavam uma aplicação cujo fornecedor já tinha versão SaaS contratada em outro departamento. O escopo real de migração caiu bem abaixo dos 140 antes de qualquer bit ser copiado, e o business case foi aprovado sobre o consumo real, não sobre o tamanho provisionado.

Caso de uso

Um provedor de serviços com 60 servidores dividiu o portfólio em quatro ondas. O time levou o rehost de duas aplicações internas na primeira onda pra calibrar o roteiro, e a lição veio no ensaio: o cutover do banco precisava de 3 horas a mais que o da aplicação, porque a validação dos dados só terminava depois. A onda foi redesenhada com a trilha de banco em cronograma separado e um ponto de decisão de rollback definido no meio da janela. Nas ondas seguintes, o ensaio de rollback pegou uma regra de firewall que só existia no ambiente de origem e teria derrubado a integração com o parceiro logo após o corte.

Caso de uso

Uma empresa de logística concluiu o rehost de um ERP em .NET Framework sobre Windows Server e só então abriu o projeto de modernização. A análise de licença mostrou que a conta de Windows e SQL Server era o item dominante do custo de destino, e a demanda de negócio existia e era nomeada: o time não conseguia entregar mudança no módulo de rastreamento em menos de um trimestre. A empresa portou a aplicação pra .NET multiplataforma sobre Linux e levou o banco pra serviço gerenciado, mantendo três módulos periféricos como estavam por não terem demanda de negócio que justificasse o trabalho. Se essa mesma sequência tivesse sido tentada durante a migração, o projeto teria virado dois projetos concorrentes disputando o mesmo time e a mesma janela.

Caso de uso

Uma empresa de software com cerca de quarenta pessoas recebe a fatura e percebe que ela cresceu de forma perceptível em relação ao mês anterior. Ninguém lançou funcionalidade nova, o número de clientes é o mesmo, e o time de engenharia não fez deploy relevante no período. A discussão consome duas reuniões e termina sem conclusão, porque a conta é uma só, os recursos não têm tag, e o Cost Explorer foi habilitado na semana passada, o que significa que não há histórico para comparar. A empresa acaba fazendo o que quase toda empresa nessa situação faz: escolhe o recurso mais caro da lista e pergunta se dá para diminuir. É a pergunta errada, feita sobre o dado errado, porque o dado certo nunca foi coletado. O custo do mês não foi o problema. O problema foi não ter como responder.

Caso de uso

Uma empresa com seis squads e uma única conta AWS decide que precisa reduzir custo, e a primeira proposta na mesa é comprar Savings Plans, porque alguém viu que o desconto chega a 72%. Antes disso, o time monta Cost Categories derivando valor da chave de tag de produto, aplica split charge para ratear a conta de rede e o cluster compartilhado, e roda o Compute Optimizer com lookback de 93 dias por causa do pico de fechamento mensal. O mapa que aparece muda a conversa: uma fatia relevante do compute está em ambiente de homologação que não tem uso fora do horário comercial, e dois dos maiores volumes EBS estão desanexados desde uma migração antiga. Nada disso é problema de preço, é problema de recurso ligado sem propósito. Comprar compromisso de um ano antes desse mapa teria congelado o desperdício dentro do contrato, e a empresa estaria pagando com desconto por capacidade que não deveria existir.

Caso de uso

Uma empresa coloca um assistente de IA em produção dentro do próprio produto, com Budgets configurado e Cost Anomaly Detection ligado na conta. Um cliente integra o assistente a uma automação que reprocessa a mesma base em loop. O consumo de token sobe em poucas horas. O Anomaly Detection não dispara, porque o modelo usado é de terceiro e aparece na fatura sob a entidade de faturamento do provedor do modelo, exatamente o caso que a documentação exclui do monitoramento. O Budgets dispararia, mas dentro da própria janela de atualização, que é medida em horas. Nenhum dos dois controles estava errado, e nenhum dos dois foi configurado de forma incompetente: os dois estavam fazendo exatamente o que a documentação diz que fazem. O que faltou foi o controle que roda antes da chamada: contador por janela, teto por conta, maxTokens explícito e recusa síncrona quando o limite é atingido. Esse controle não é do console, é do código, e ele é a diferença entre um incidente de custo e um erro 429 devolvido para uma automação que estava mal configurada de qualquer forma.