Lambda, DynamoDB e Parameter Store reduzem código próprio na AWS esta semana

Entre 2 e 8 de novembro de 2026, a AWS não teve re:Invent nem keynote. Mesmo assim, saíram quatro mudanças que mexem direto no código de quem mantém função Lambda, fila SQS e tópico SNS em produção: Kafka ganhou um modo de fila no Lambda, o DynamoDB passou a aceitar carga em massa em tabelas já existentes, o Parameter Store validou tipo de valor na escrita e os agentes de IA ganharam busca web pronta. O resumo é do blog de Sascha, publicado na DEV Community, que acompanha anúncio por anúncio da AWS toda semana.

Lambda lê Kafka como fila, e isso resolve o gargalo de partição

Desde 2 de novembro, o event source mapping do Lambda (a configuração que conecta a função a uma fonte de eventos) suporta um modo de fila para clusters Kafka self-managed, incluindo serviços como Confluent Cloud. Até então, valia a regra clássica de consumer group: cada partição pertence a exatamente um consumidor, então mais paralelismo só vinha com mais partições.

O novo modo usa os share groups do Apache Kafka 4.2. Vários pollers passam a ler da mesma partição ao mesmo tempo, cada um disparando até dez invocações concorrentes. Você liga isso com ConsumptionMode definido como Queue; produtor, tópico e código da função continuam exatamente como estão. A troca é a ordem: dentro da partição, ela deixa de ser garantida.

Se seu time já contornou esse limite com partições extras ou desviando o fluxo por uma fila SQS, essa é a notícia da semana. Antes de trocar o modo, confira se algum consumidor depende de ordem silenciosamente; se depender, esse tópico fica no modo antigo. O handler também precisa ser idempotente, porque uma mensagem pode chegar de novo depois de um erro, o mesmo cuidado que já é rotina em consumidor de SQS com at-least-once delivery.

Pra mim, isso fecha uma lacuna que muitos times remendaram com partições extras ou um desvio pela SQS.

For me, this closes a gap that many teams have patched with extra partitions or a detour through SQS.Sascha, autor do Serverless & AI in brief

DynamoDB passa a escrever em tabelas que já estão em produção

Desde 5 de novembro, o bulk put items do DynamoDB está disponível de forma geral. Antes, a importação a partir do S3 só conseguia criar tabela nova; agora o DynamoDB grava dados do S3 direto numa tabela que já está rodando. Essas escritas usam um caminho separado e não consomem capacidade de leitura ou escrita da tabela, então a aplicação que já lê e escreve ali não sente o processo.

Dá pra passar uma condição por registro: attribute_not_exists(pk) para um comportamento de "insere só se não existir", ou uma comparação contra um atributo de versão para evitar sobrescrever algo mais novo. Sem condição, um item existente com a mesma chave é sobrescrito sem aviso. O que não foi gravado vira um relatório no S3, com o motivo. Existe um nível padrão e um acelerado, este só em regiões selecionadas (nada ainda confirmado para sa-east-1 na fonte).

Quem hoje faz backfill ou atualização noturna de catálogo via função Lambda disparada por fila, gravando em lote com BatchWriteItem, lidando com retry e throttling na mão, ganha um caminho pronto. A recomendação de Sascha vale a pena repetir: sempre defina uma condição, mesmo quando você tem certeza de que o dado é novo, porque um registro sobrescrito por engano é difícil de rastrear num lote grande.

Parameter Store valida o valor antes de aceitar a escrita

Também desde 5 de novembro, o Parameter Store (dentro do Systems Manager) reconhece 13 tipos de dado. Dez funcionam em parâmetro padrão e avançado, como integer, boolean, aws:region, aws:account:id, email e ipv4-address. Os outros três, url, json e jsonc, só existem em parâmetro avançado e são cobrados na tarifa correspondente.

Se o valor não bate com o tipo declarado, o PutParameter rejeita a escrita, inclusive para SecureString. Um AllowedPattern adiciona regra extra em cima disso, e dá pra filtrar parâmetros por tipo no console ou via DescribeParameters.

Para quem lê configuração do Parameter Store no cold start de uma função Lambda, isso ataca uma causa clássica de incidente: o typo na configuração que só aparece quando a função sobe às três da manhã. Vale manter a validação de regra de negócio no próprio código, porque o tipo garante que 5000 é um número, não que faz sentido como timeout.

Agentes ganham busca web com citação pronta

Desde 5 de novembro, o Web Answer do Amazon Bedrock AgentCore está disponível de forma geral. O agente faz uma pergunta em linguagem natural e recebe, numa única chamada, uma resposta pronta com citações: o serviço planeja várias buscas, roda em paralelo e decide quando a evidência é suficiente. É uma extensão do Web Search, lançado em junho, que só devolvia resultados brutos.

Você conecta o Web Answer como target num AgentCore Gateway, chama via MCP e protege com IAM; domínio permitido, lista de bloqueio e filtro de data reduzem o escopo da busca. A cobrança é por chamada, e por enquanto o recurso só roda em US East (N. Virginia), sem data para sa-east-1 na fonte.

Para quem monta um loop de agente orquestrado por função Lambda acionada via SQS ou SNS, isso evita construir do zero um pipeline de busca, extração, resumo e citação. Mas a Região concentrada em território americano é item de revisão de proteção de dados para quem opera na Europa (e vale o mesmo cuidado para quem está no Brasil), e citação não é garantia: o agente que cita fonte parece mais confiável do que necessariamente é, então checar se a fonte sustenta mesmo a afirmação continua sendo trabalho do time.

O que muda pra quem mantém fila e tópico no dia a dia

O padrão da semana é código próprio virando configuração. Escala de consumidor Kafka, carga em massa de dado, validação de parâmetro e busca web com citação são coisas que muitos times já construíram e mantêm na mão. A pergunta deixa de ser "como eu construo isso" e vira "qual suposição quebra quando eu troco": ordem de mensagem, sobrescrita de registro, expiração de configuração e Região disponível.

Vale também registrar, de passagem, que o Lambda durable functions teve as cotas padrão ampliadas em 5 de novembro, de um milhão para cinco milhões de execuções em andamento por conta e de 300 para 3.000 inícios por segundo (o dobro em US East N. Virginia, US West Oregon e Europe Ireland). Quem orquestra fluxo longo via SNS ou SQS por trás de uma função durable ganha fôlego sem pedir aumento de limite.

Se sobrar uma hora esta semana, a lista prática da fonte continua valendo: escolher um tópico Kafka e confirmar se algum consumidor depende de ordem; dar tipo a três parâmetros importantes no Parameter Store e ver se algum é rejeitado; e, antes de rodar bulk put items pela primeira vez, testar a condição num ambiente que não seja produção.

Fonte: DEV Community — #aws