Blog

O que é o Amazon SageMaker Feature Store

O Amazon SageMaker Feature Store é um repositório gerenciado pela AWS para armazenar, compartilhar e gerenciar features de modelos de Aprendizado de Máquina (ML). Ele oferece serving online de baixa latência para inferência em tempo real, um offline store para retenção histórica e dados de treinamento, além de suporte a padrões de ingestão via streaming e batch.

Os dois problemas que motivaram as novas APIs

À medida que as plataformas de ML amadurecem, dois gaps operacionais aparecem com frequência.

Problema 1: throughput limitado na ingestão

O primeiro desafio envolve pipelines de features de alta vazão. A API existente, o PutRecord, grava um único registro por chamada, em um único feature group. Isso força um padrão de chamadas N×M — N registros multiplicados por M feature groups. O resultado prático: uma pipeline de detecção de fraudes que ingere 10.000 registros por segundo em cinco feature groups precisa sustentar 50.000 chamadas individuais de API por segundo, gerando overhead de conexão e alta latência de cauda.

Problema 2: registros irrecuperáveis no tier In-Memory

O segundo problema afeta quem usa o storage tier In-Memory. Nesse modelo, não há como navegar ou enumerar os registros armazenados no online store. Se os identificadores de registro forem perdidos por um bug ou falha de pipeline, esses registros se tornam permanentemente irrecuperáveis — não existe offline store para consultar, nenhuma query no Amazon Athena para rodar, e nenhuma API para descobrir o que existe.

As duas novas APIs anunciadas

Para endereçar esses dois problemas, a AWS anunciou duas novas APIs para o Amazon SageMaker Feature Store:

• BatchWriteRecord — Grava até 25 registros em múltiplos feature groups em uma única chamada de API, com semântica de sucesso parcial, controle de TTL (Time-to-Live) por registro e as mesmas garantias de ordenação baseadas em EventTime do PutRecord.
• ListRecords — Enumera identificadores de registro dentro de um feature group com paginação. Funciona com os dois tiers de storage: Standard (baseado em Amazon DynamoDB) e In-Memory (baseado em Redis).

Pré-requisitos

Para acompanhar os exemplos apresentados, você precisará de:

• Uma conta AWS com permissões para criar recursos do Amazon SageMaker AI.
• Uma execution role do Amazon SageMaker AI com acesso ao Amazon Simple Storage Service (Amazon S3) e ao AWS Glue, além de permissões para interagir com as APIs do plano de dados do Feature Store. A política mínima de Gerenciamento de Identidade e Acesso (IAM) necessária é:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sagemaker:BatchWriteRecord",
        "sagemaker:PutRecord",
        "sagemaker:ListRecords"
      ],
      "Resource": "arn:aws:sagemaker:*:*:feature-group/*"
    }
  ]
}

• Boto3 (versão mais recente) ou SageMaker Python SDK v3.8.0 ou superior.
• Um ou mais feature groups existentes com registros ingeridos. Se você é novo no Feature Store, consulte o notebook de workshop end-to-end.

BatchWriteRecord

A API BatchWriteRecord aceita até 25 entradas em uma única requisição, podendo atingir um ou mais feature groups simultaneamente. Cada registro tem sucesso ou falha de forma independente — trata-se de uma API de sucesso parcial, o que significa que falhas individuais não cancelam a requisição inteira.

A API preserva a mesma ordenação baseada em EventTime do PutRecord:

• Se o EventTime do registro recebido for mais recente do que o existente, ele se torna a versão mais atual no online store.
• Caso contrário, o registro é gravado como versão histórica no offline store (para feature groups com storage offline habilitado).
• Registros que falham por outros motivos (erros de autenticação, validação ou throttling) são retornados na resposta com detalhes do erro. As entradas não processadas aparecem em UnprocessedEntries e podem ser retentadas.

Estrutura da requisição

{
  "Entries": [
    {
      "FeatureGroupName": "click-features",
      "Record": [
        {"FeatureName": "user_id", "ValueAsString": "user-123"},
        {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:00Z"},
        {"FeatureName": "click_count", "ValueAsString": "42"}
      ],
      "TargetStores": ["OnlineStore", "OfflineStore"],
      "TtlDuration": {"Unit": "Days", "Value": 7}
    },
    {
      "FeatureGroupName": "login-features",
      "Record": [
        {"FeatureName": "user_id", "ValueAsString": "user-456"},
        {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:01Z"},
        {"FeatureName": "login_count", "ValueAsString": "18"}
      ],
      "TargetStores": ["OnlineStore", "OfflineStore"]
    }
  ]
}

A resposta retorna apenas os registros que falharam. Registros não listados em Errors ou UnprocessedEntries foram gravados com sucesso. A aplicação deve retentar apenas os registros falhos usando exponential backoff para erros retriáveis.

Exemplo de código: ingestão em lote com Boto3

import boto3

featurestore_runtime = boto3.client("sagemaker-featurestore-runtime")

response = featurestore_runtime.batch_write_record(
    Entries=[
        {
            "FeatureGroupName": "click-features",
            "Record": [
                {"FeatureName": "user_id", "ValueAsString": "user-123"},
                {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:00Z"},
                {"FeatureName": "click_count", "ValueAsString": "42"},
            ],
            "TargetStores": ["OnlineStore", "OfflineStore"],
        },
        {
            "FeatureGroupName": "login-features",
            "Record": [
                {"FeatureName": "user_id", "ValueAsString": "user-456"},
                {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:01Z"},
                {"FeatureName": "login_count", "ValueAsString": "18"},
            ],
            "TargetStores": ["OnlineStore", "OfflineStore"],
        },
    ]
)

if response["Errors"]:
    for error in response["Errors"]:
        print(f"Record {error['Entry']}, ErrorCode: {error['ErrorCode']} Failed: {error['ErrorMessage']}")

if response["UnprocessedEntries"]:
    for unprocessed in response["UnprocessedEntries"]:
        print(f"Unprocessed: {unprocessed['FeatureGroupName']}")

if not response["Errors"] and not response["UnprocessedEntries"]:
    print("All records written successfully.")

Exemplo de código: gravando em múltiplos feature groups

É possível atingir múltiplos feature groups em uma única requisição. Os registros são agrupados por feature group e processados de forma independente:

featurestore_runtime = boto3.client("sagemaker-featurestore-runtime")

response = featurestore_runtime.batch_write_record(
    Entries=[
        {
            "FeatureGroupName": "user-profile-features",
            "Record": [
                {"FeatureName": "user_id", "ValueAsString": "user-123"},
                {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:00Z"},
                {"FeatureName": "age", "ValueAsString": "34"},
                {"FeatureName": "region", "ValueAsString": "us-west-2"},
            ],
            "TargetStores": ["OnlineStore"],
        },
        {
            "FeatureGroupName": "click-features",
            "Record": [
                {"FeatureName": "user_id", "ValueAsString": "user-123"},
                {"FeatureName": "event_time", "ValueAsString": "2026-06-05T12:00:00Z"},
                {"FeatureName": "click_count", "ValueAsString": "42"},
            ],
            "TargetStores": ["OnlineStore", "OfflineStore"],
        },
    ]
)

Uma falha em um feature group não afeta os registros destinados a outros feature groups.

Suporte a TTL (Time-to-Live)

A API BatchWriteRecord suporta TTL em três níveis de precedência:

• TTL por registro — Definido via TtlDuration em entradas individuais. Tem a maior prioridade.
• TTL por requisição — Um TtlDuration padrão no nível superior da requisição, aplicado às entradas sem TTL de registro.
• TTL por feature group — O TTL configurado no próprio feature group, aplicado quando nem o TTL de registro nem o de requisição estão definidos.

Considerações importantes

• Máximo de 25 entradas por requisição, contando o total de entradas em todos os feature groups.
• Semântica de sucesso parcial: ao contrário de APIs transacionais, o BatchWriteRecord não desfaz gravações bem-sucedidas se alguns registros falharem. Projete a lógica de retry para reenviar apenas os registros retornados em Errors.
• Modelo de IAM similar ao PutRecord: o chamador precisa ter permissões sagemaker:BatchWriteRecord e sagemaker:PutRecord no ARN (Nome de Recurso da Amazon) de cada feature group alvo.
• Ordenação por EventTime preservada: um registro desatualizado não pode sobrescrever um mais recente no online store.
• Flexibilidade de TargetStores: cada entrada pode independentemente ter como alvo o OnlineStore, o OfflineStore ou ambos.

ListRecords

A API ListRecords fecha a lacuna na descoberta de registros para ambos os tiers de storage. Ela enumera identificadores de registro dentro de um feature group usando paginação, retornando apenas registros ativos, não deletados e não expirados — prontos para uso com GetRecord ou DeleteRecord.

O problema com a descoberta de registros

O Feature Store suporta PutRecord, GetRecord e DeleteRecord, mas todas exigem que o chamador conheça o identificador exato do registro. Não havia API para navegar ou enumerar registros dentro de um feature group.

Para o tier Standard, o workaround era consultar o offline store via Amazon Athena — o que exige configuração de offline store, adiciona custo e não é em tempo real. Para o tier In-Memory, a situação é crítica: não há offline store correspondente por padrão. Se os identificadores de registro forem perdidos, esses registros se tornam completamente irrecuperáveis, gerando dados fantasmas, custos de storage desperdiçados e riscos de conformidade quando usuários solicitam exclusão de dados.

Como o ListRecords funciona

A API funciona com os dois tiers de storage:

• Tier Standard (Amazon DynamoDB): Faz scan do online store, retornando o identificador da versão mais recente de cada registro. Registros soft-deleted e expirados são automaticamente excluídos.
• Tier In-Memory (Redis): Faz scan das keys e filtra registros soft-deleted e keys internas do sistema. Retorna identificadores de registro extraídos dos nomes das keys.

Exemplo de código: enumerar todos os registros de um feature group

import boto3

featurestore_runtime = boto3.client("sagemaker-featurestore-runtime")

all_identifiers = []
next_token = None

while True:
    params = {
        "FeatureGroupName": "user-profile-features",
        "MaxResults": 100,
    }
    if next_token:
        params["NextToken"] = next_token

    response = featurestore_runtime.list_records(**params)
    all_identifiers.extend(response["RecordIdentifiers"])
    next_token = response.get("NextToken")

    if not next_token:
        break

print(f"Found {len(all_identifiers)} active records.")

Exemplo de código: limpeza de registros órfãos

Um caso de uso comum é identificar e deletar registros que não são mais necessários. Isso é crítico para feature groups do tier In-Memory, onde registros órfãos persistem indefinidamente:

import boto3

featurestore_runtime = boto3.client("sagemaker-featurestore-runtime")

# Step 1: Enumerate all record identifiers
all_ids = []
next_token = None

while True:
    params = {"FeatureGroupName": "session-features", "MaxResults": 100}
    if next_token:
        params["NextToken"] = next_token

    response = featurestore_runtime.list_records(**params)
    all_ids.extend(response["RecordIdentifiers"])
    next_token = response.get("NextToken")

    if not next_token:
        break

# Step 2: Compare against your application's active session list
active_sessions = get_active_sessions()  # Your application logic
orphaned = [rid for rid in all_ids if rid not in active_sessions]

# Step 3: Delete orphaned records
for record_id in orphaned:
    featurestore_runtime.delete_record(
        FeatureGroupName="session-features",
        RecordIdentifierValueAsString=record_id,
        EventTime="2026-06-05T12:00:00Z",
    )

print(f"Deleted {len(orphaned)} orphaned records.")

Comportamento da paginação

• Tamanho da página: configurável via MaxResults (padrão 10, máximo 100).
• Formato do token: string opaca e criptografada. Não tente parsear ou construir tokens — passe-os sem alteração.
• Ordenação: os resultados não têm garantia de ordem específica.
• Escritas concorrentes: se registros forem gravados ou deletados durante a paginação, podem ocorrer duplicatas ou lacunas. Esse é um comportamento documentado.
• Escopo do token: tokens estão vinculados a um feature group e conta específicos e não podem ser reutilizados entre eles.

Considerações importantes

• Apenas identificadores de registro: a versão atual retorna identificadores de registro sem valores de features. Use GetRecord ou BatchGetRecord para recuperar os registros completos.
• Filtragem automática: a API exclui registros soft-deleted, expirados e keys internas do sistema. Você vê apenas registros ativos e recuperáveis.
• Permissão IAM: o chamador precisa ter a permissão sagemaker:ListRecords no ARN do feature group.
• Ambos os tiers suportados: o ListRecords funciona de forma idêntica do ponto de vista do chamador, independentemente do tier de storage.

Combinando as duas APIs: um caso de uso completo

As duas APIs se complementam naturalmente. Veja um exemplo de workflow de conformidade que verifica a exclusão completa de dados de um usuário em múltiplos feature groups:

import boto3

featurestore_runtime = boto3.client("sagemaker-featurestore-runtime")

feature_groups = ["user-profiles", "click-history", "purchase-signals"]
user_to_delete = "user-789"

# Step 1: Find and delete the user across all feature groups
for fg_name in feature_groups:
    all_ids = []
    next_token = None

    while True:
        params = {"FeatureGroupName": fg_name, "MaxResults": 100}
        if next_token:
            params["NextToken"] = next_token

        response = featurestore_runtime.list_records(**params)
        all_ids.extend(response["RecordIdentifiers"])
        next_token = response.get("NextToken")

        if not next_token:
            break

    if user_to_delete in all_ids:
        featurestore_runtime.delete_record(
            FeatureGroupName=fg_name,
            RecordIdentifierValueAsString=user_to_delete,
            EventTime="2026-06-05T23:59:59Z",
        )
        print(f"Deleted '{user_to_delete}' from {fg_name}")

# Step 2: Log the deletion event using BatchWriteRecord
featurestore_runtime.batch_write_record(
    Entries=[
        {
            "FeatureGroupName": "deletion-audit-log",
            "Record": [
                {"FeatureName": "request_id", "ValueAsString": "del-001"},
                {"FeatureName": "event_time", "ValueAsString": "2026-06-05T23:59:59Z"},
                {"FeatureName": "user_id", "ValueAsString": user_to_delete},
                {"FeatureName": "status", "ValueAsString": "completed"},
                {"FeatureName": "feature_groups_cleaned", "ValueAsString": "3"},
            ],
            "TargetStores": ["OnlineStore", "OfflineStore"],
        }
    ]
)

Limpeza de recursos

Para evitar cobranças contínuas, exclua os feature groups criados durante os testes. Para feature groups do tier In-Memory, use o ListRecords para enumerar os registros e o DeleteRecord para removê-los antes de excluir o feature group.

Conclusão

As APIs BatchWriteRecord e ListRecords representam melhorias significativas no plano de dados do Amazon SageMaker Feature Store. O BatchWriteRecord reduz o volume de chamadas de API para ingestão de alta vazão em até 25x, preservando as garantias de ordenação baseadas em EventTime. O ListRecords habilita a descoberta e o gerenciamento do ciclo de vida de registros — algo crítico para clientes do tier In-Memory, que anteriormente não tinham como enumerar ou limpar seus dados.

Juntas, essas APIs viabilizam padrões que antes eram difíceis ou impossíveis: pipelines de ingestão em bulk com menos conexões e menor latência, workflows de conformidade que verificam exclusão completa de dados, e ferramentas operacionais que navegam pelo conteúdo de feature groups em tempo real.

Para mais informações, consulte a documentação do Feature Store, a referência de API do Feature Store, a documentação de configuração do offline store e o anúncio de novidades. Para aprofundar o conhecimento sobre as capacidades do Feature Store, confira também os posts relacionados: Understanding the Key Capabilities of Amazon SageMaker Feature Store, Accelerate ML Feature Pipelines with new capabilities in Amazon SageMaker Feature Store e Using Streaming Ingestion with Amazon SageMaker Feature Store.

Fonte

Batch write and discover records in Amazon SageMaker Feature Store (https://aws.amazon.com/blogs/machine-learning/batch-write-and-discover-records-in-amazon-sagemaker-feature-store/)

O que mudou no Amazon Bedrock AgentCore Memory

A AWS anunciou uma novidade relevante para quem desenvolve aplicações com agentes de IA usando o Amazon Bedrock AgentCore Memory: o serviço agora suporta variáveis de namespace flexíveis. Essa atualização dá aos desenvolvedores muito mais controle sobre como as memórias de longo prazo são organizadas, isoladas e acessadas dentro de aplicações complexas.

O problema que essa novidade resolve

Aplicações multi-tenant ou com hierarquias complexas — como sistemas que atendem múltiplas organizações, times ou ambientes diferentes — precisam separar as memórias de cada contexto com precisão. Antes dessa atualização, fazer isso exigia criar estratégias duplicadas ou forçar o uso de variáveis nativas do serviço para fins que elas não foram projetadas para atender.

Com as variáveis de namespace flexíveis, esse problema deixa de existir. Agora é possível definir dimensões personalizadas — como organização, tenant, time ou ambiente — sem gambiarra e sem redundância.

Como funciona na prática

O mecanismo é direto: o desenvolvedor define chaves (keys) no recurso de memória, referencia essas chaves no template de namespace de uma estratégia e, em tempo de execução, fornece os valores correspondentes por meio da API CreateEvent. O serviço então substitui automaticamente essas variáveis nos templates de namespace durante o processo de extração de memória de longo prazo.

Alguns pontos importantes sobre os limites e o funcionamento:

• É possível definir até cinco chaves por recurso de memória
• Cada chave pode ser referenciada em múltiplas estratégias
• Os valores são fornecidos em tempo de execução via API CreateEvent

Disponibilidade e custo

As variáveis de namespace flexíveis já estão disponíveis em todas as regiões da AWS onde o Amazon Bedrock AgentCore Memory está em disponibilidade geral (generally available), sem custo adicional.

Para começar a usar e entender como configurar a organização de memórias de longo prazo com namespaces, a AWS disponibiliza documentação detalhada no guia oficial: Especifique a organização de memória de longo prazo com namespaces no Amazon Bedrock AgentCore Developer Guide.

Fonte

Amazon Bedrock AgentCore Memory now supports flexible namespace variables (https://aws.amazon.com/about-aws/whats-new/2026/08/agentcorememory-flexible-namespaces)

Graviton4 chega a Paris: o que muda para workloads de rede

A AWS expandiu a disponibilidade das instâncias Amazon EC2 C8gn para a região Europa (Paris). Movidas pelos processadores AWS Graviton4 de última geração, essas instâncias entregam até 30% mais desempenho computacional em comparação com as C7gn, que eram baseadas no Graviton3.

Principais capacidades técnicas

As instâncias C8gn se destacam especialmente no quesito conectividade. Elas utilizam as Nitro Cards de 6ª geração e oferecem até 600 Gbps de largura de banda de rede — o maior valor disponível entre todas as instâncias EC2 voltadas para cargas de trabalho intensivas em rede.

Em termos de escalabilidade, as C8gn chegam ao tamanho 48xlarge, com até 384 GiB de memória e até 120 Gbps de banda para o Amazon Elastic Block Store (EBS).

Para clusters de alto desempenho, os tamanhos 16xlarge, 24xlarge, 48xlarge, metal-24xl e metal-48xl contam com suporte ao Elastic Fabric Adapter (EFA), o que reduz a latência e melhora o desempenho em ambientes com nós fortemente acoplados.

Casos de uso recomendados

A AWS posiciona as instâncias C8gn para cenários que exigem alto throughput de rede combinado com eficiência de custo, como:

• Appliances virtuais de rede (network virtual appliances)
• Análise de dados em larga escala
• Inferência de inteligência artificial e aprendizado de máquina (IA/ML) baseada em CPU

Disponibilidade global

Com a adição de Paris, as instâncias C8gn estão agora disponíveis em um conjunto amplo de regiões AWS ao redor do mundo:

• América do Norte: Leste dos EUA (N. Virgínia, Ohio), Oeste dos EUA (Oregon, N. Califórnia), Canadá Oeste (Calgary, Central)
• Europa: Frankfurt, Estocolmo, Irlanda, Londres, Espanha, Zurique, Milão e Paris
• Ásia-Pacífico: Singapura, Malásia, Sydney, Tailândia, Mumbai, Seul, Melbourne, Jacarta, Hyderabad, Tóquio, Hong Kong
• Oriente Médio: EAU
• África: Cidade do Cabo
• América do Sul: São Paulo
• AWS GovCloud: Leste e Oeste dos EUA

Como começar

Para quem quiser se aprofundar nas especificações e começar a usar as instâncias C8gn, a AWS disponibiliza documentação e recursos de acesso direto:

• Consulte a página oficial das instâncias Amazon C8gn para detalhes técnicos completos.
• Explore a página de evolução de compute com AWS Graviton para entender o ecossistema Graviton.
• Provisione instâncias pelo Console de Gerenciamento AWS, pela Interface de Linha de Comando AWS (AWS CLI) ou pelos AWS SDKs.

Fonte

Amazon EC2 C8gn instances are now available in AWS Europe (Paris) region (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ec2-c8gn-europe-paris/)

Expansão regional das instâncias P6-B300

A AWS anunciou a disponibilidade das instâncias Amazon EC2 P6-B300 em novas regiões, incluindo Ásia-Pacífico (Hyderabad) e América do Sul (São Paulo). Para equipes brasileiras que trabalham com cargas de trabalho intensivas de Inteligência Artificial (IA), essa é uma novidade relevante: agora é possível acessar esse hardware de ponta sem precisar rotear tráfego para regiões fora do país.

O que são as instâncias P6-B300?

As instâncias P6-B300 são voltadas para workloads de IA de alta demanda — especialmente treinamento e inferência de modelos de fundação (FMs) e Modelos de Linguagem de Grande Escala (LLMs) com trilhões de parâmetros. Cada instância é equipada com:

• 8 GPUs NVIDIA Blackwell Ultra
• 2,1 TB de memória de GPU de alta largura de banda
• 6,4 Tbps de rede EFA (Elastic Fabric Adapter — adaptador de malha elástica para comunicação de baixa latência entre instâncias)
• 300 Gbps de throughput dedicado ENA (Elastic Network Adapter — adaptador de rede elástica)
• 4 TB de memória de sistema

O que muda em relação à geração anterior?

Comparando com as instâncias P6-B200, a nova geração P6-B300 entrega ganhos expressivos:

• 2x mais largura de banda de rede
• 1,5x mais memória de GPU
• 1,5x mais TFLOPS de GPU (medido em FP4, sem esparsidade)

Na prática, isso se traduz em tempos de treinamento mais rápidos e maior throughput de tokens para workloads de IA — dois fatores críticos para quem lida com modelos de grande porte em produção.

Regiões disponíveis

As instâncias P6-B300 estão disponíveis no tamanho p6-b300.48xlarge nas seguintes regiões AWS:

• US West (Oregon)
• AWS GovCloud (US-East)
• US East (N. Virginia)
• Ásia-Pacífico (Hyderabad e Seul)
• América do Sul (São Paulo)

Por que isso importa para o Brasil?

A chegada das instâncias P6-B300 à região de São Paulo é um sinal claro de que a AWS está apostando no mercado brasileiro como destino relevante para workloads de IA de alto desempenho. Equipes locais que antes precisavam usar regiões nos EUA para acessar hardware de última geração agora podem operar com menor latência, dentro da jurisdição brasileira — o que também pode facilitar o atendimento a requisitos de conformidade e soberania de dados.

Para saber mais sobre as instâncias P6-B300 e suas especificações completas, a AWS disponibiliza a documentação oficial em Amazon EC2 instâncias P6.

Fonte

Amazon EC2 P6-B300 instances are now available in additional AWS Regions (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ec2-p6-b300-instances-available-additional-regions)

O que foi anunciado

A AWS anunciou que o Amazon Redshift passou a se integrar com o Agent Toolkit for AWS, abrindo caminho para que agentes de IA como Claude Code, Kiro e Cursor consigam construir, consultar, fazer troubleshooting e migrar data warehouses e data lakes no Redshift diretamente — sem que o usuário precise sair do ambiente do agente para executar essas tarefas.

Como a integração funciona

A integração combina dois componentes principais. O primeiro é o servidor MCP (Model Context Protocol) da AWS, responsável por executar chamadas autenticadas às APIs da AWS em nome do usuário. O segundo são as Redshift skills — pacotes curados de procedimentos testados e materiais de referência que orientam os agentes de IA a concluírem tarefas no Redshift com mais precisão e eficiência.

O que as Redshift Skills cobrem

As Redshift skills abrangem uma série de capacidades práticas para o dia a dia de quem trabalha com o serviço:

• Referências de sintaxe SQL para reduzir erros na geração de consultas
• Descoberta de metadados para explorar schemas e dados sem precisar escrever SQL manualmente
• Padrões de carregamento de dados
• Boas práticas para materialized views
• Orientações sobre funções e tipos de dados
• Extensões como Qualify, Pivot e Super

Além disso, as skills também guiam migrações completas de data warehouses para o Amazon Redshift, cobrindo as etapas de descoberta, conversão de schema e SQL, movimentação de dados, validação e comparação de performance.

Disponibilidade e requisitos

As skills funcionam tanto com clusters provisionados quanto com workgroups do Serverless, não exigem nenhuma alteração na infraestrutura existente e estão disponíveis sem custo adicional em todas as regiões da AWS onde o Amazon Redshift e o servidor MCP da AWS estão disponíveis. A AWS também indicou que continuará expandindo essas habilidades com novas capacidades ao longo do tempo.

Como começar a usar

Para dar os primeiros passos, basta instalar o plugin aws-data-analytics no seu agente. Esse plugin já agrupa a configuração do servidor MCP e as Redshift skills em uma única etapa de instalação. Agentes que já possuem acesso ao servidor MCP também conseguem descobrir e carregar as skills em tempo de execução, sem necessidade de pré-instalação.

Para instruções de configuração, a AWS disponibiliza a documentação do Agent Toolkit e a documentação das Amazon Redshift skills.

Fonte

Amazon Redshift integrates with Agent Toolkit for AWS for AI-assisted data warehouse management (https://aws.amazon.com/about-aws/whats-new/2026/08/redshift-agenttoolkit-for-ai-assisted-datawarehouse-mgmt)

Novos modelos de fundação chegam ao SageMaker JumpStart

A AWS anunciou a disponibilidade de dois novos modelos de fundação no Amazon SageMaker JumpStart: o Muse-Glimmer-30B, desenvolvido pela Meta, e o Qwen 3.8-27B, da Alibaba. A adição amplia o portfólio de modelos prontos para uso na plataforma, oferecendo aos clientes AWS mais opções para construir soluções de IA de alta performance em infraestrutura escalável.

Cada modelo foi projetado para responder a desafios distintos dentro do ecossistema de IA empresarial, com capacidades especializadas que se complementam bem dependendo do caso de uso.

Muse-Glimmer-30B: agentes autônomos com raciocínio local

O Muse-Glimmer-30B é um modelo denso de 30 bilhões de parâmetros desenvolvido pelo Meta Superintelligence Lab, projetado especificamente para tarefas agênticas autônomas — ou seja, fluxos de trabalho em que o modelo precisa tomar decisões sequenciais, usar ferramentas externas e se recuperar de falhas sem intervenção humana constante.

Entre suas características técnicas mais relevantes:

• Encoder de percepção visual dedicado (~1,8B parâmetros, ViT-G/14), com suporte a entradas intercaladas de texto e imagem
• Janela de contexto superior a 131 mil tokens
• Níveis de raciocínio ajustáveis, de baixo a extra-alto
• Capacidade de executar chamadas sequenciais a ferramentas e se recuperar de falhas
• Operação completamente local, sem dependência de infraestrutura em nuvem — ideal para agentes empresariais sempre ativos

O modelo é disponibilizado sob licença Apache 2.0.

Qwen 3.8-27B: codificação, raciocínio e compreensão multimodal

O Qwen 3.8-27B é um modelo de linguagem e visão nativo (VLM — Vision-Language Model) com 27 bilhões de parâmetros densos, desenvolvido pela Alibaba. Ele se destaca em tarefas de codificação, raciocínio em múltiplas etapas e compreensão multimodal envolvendo texto, imagens e vídeo.

Destaques técnicos do modelo:

• Janela de contexto de 262 mil tokens, expansível a aproximadamente 1 milhão via escalonamento YaRN
• Níveis de esforço de raciocínio ajustáveis
• Pontuação de 61,7 no benchmark SWE-bench Pro
• Tamanho de aproximadamente 17 GB quantizado
• Ganhos substanciais de desempenho em relação à versão anterior, com maior confiabilidade na conclusão de tarefas complexas

Como implantar os modelos no SageMaker JumpStart

A AWS destaca que a implantação de ambos os modelos pode ser feita com poucos cliques. Os clientes podem acessar o catálogo de modelos do SageMaker JumpStart diretamente pelo console do SageMaker ou utilizar o SDK Python do SageMaker para implantar os modelos em sua conta AWS.

Para quem quiser se aprofundar nos detalhes de implantação e uso de modelos de fundação no SageMaker JumpStart, a AWS disponibiliza a documentação oficial do Amazon SageMaker JumpStart.

Fonte

Muse-Glimmer-30B and Qwen 3.8-27B models now available on Amazon SageMaker JumpStart (https://aws.amazon.com/about-aws/whats-new/2026/01/muse-glimmer-30b-qwen-3.8-27b-on-sagemaker-jumpstart/)

Família Cosmos 3 chega ao SageMaker JumpStart

A AWS anunciou a disponibilidade dos modelos Cosmos3-Edge, Cosmos3-Nano e Cosmos3-Super — da NVIDIA — no Amazon SageMaker JumpStart, expandindo o portfólio de modelos de fundação acessíveis aos clientes da plataforma. Os três modelos formam a família Cosmos 3, uma linha de modelos omnimodais de fronteira para IA física, projetados para capacitar robôs, veículos autônomos e sistemas de visão artificial que precisam perceber, raciocinar, planejar e agir no mundo físico.

Três modelos, três propósitos

Cada modelo da família Cosmos 3 foi desenvolvido para endereçar desafios específicos dentro do universo da IA física. Veja o que cada um oferece:

Cosmos3-Edge — IA física na borda

O Cosmos3-Edge foi projetado para controle de robôs diretamente no dispositivo e raciocínio visual em tempo real em hardware de borda (edge). Com 4 bilhões de parâmetros (mais um raciocínio baseado em Nemotron de 2B), o modelo opera na resolução de controle robótico (640×360), gerando 32 ações por inferência a 15 Hz no NVIDIA Jetson Thor. Ele suporta vídeo em 256p e 480p a 12–30 quadros por segundo, trazendo capacidades de IA física de fronteira diretamente para sistemas embarcados.

Cosmos3-Nano — raciocínio físico compacto

O Cosmos3-Nano se destaca na geração de mundos com consciência física e no raciocínio sobre o mundo real. Com 16 bilhões de parâmetros, este modelo omnimodal compacto processa combinações de texto, imagem, vídeo, áudio e trajetórias de ação para produzir saídas correspondentes. Isso permite que robôs e agentes de visão artificial raciocinem com base em conhecimento prévio, compreensão de física e senso comum. O modelo suporta raciocínio em cadeia de pensamento (chain-of-thought) sobre texto, imagens e vídeo, com resoluções de até 720p.

Cosmos3-Super — simulação de alta fidelidade

O Cosmos3-Super oferece a geração e simulação de mundos com a maior fidelidade da família Cosmos 3, com 64 bilhões de parâmetros. Ele processa e gera conjuntamente linguagem, imagens, vídeo, áudio e sequências de ação dentro de uma arquitetura unificada de Mistura de Transformadores (Mixture-of-Transformers), suportando resoluções de até 720p em múltiplas proporções de tela. É o modelo ideal para fluxos de trabalho de simulação em larga escala, geração de dados sintéticos e aprendizado de políticas.

Como implantar os modelos

Com o SageMaker JumpStart, os clientes AWS podem implantar qualquer um desses modelos com poucos cliques para atender aos seus casos de uso específicos de IA. Para começar, basta acessar o catálogo de modelos do SageMaker JumpStart pelo console do SageMaker ou utilizar o SDK Python do SageMaker para implantar os modelos na sua conta AWS. Para mais detalhes sobre como implantar e utilizar modelos de fundação no SageMaker JumpStart, consulte a documentação oficial do Amazon SageMaker JumpStart.

Fonte

Cosmos3-Edge, Cosmos3-Nano, and Cosmos3-Super models now available on Amazon SageMaker JumpStart (https://aws.amazon.com/about-aws/whats-new/2026/01/cosmos3-edge-cosmos3-nano-cosmos3-super-on-sagemaker-jumpstart/)

O problema de produção criativa que a IA sozinha não resolve

Equipes criativas vivem sob pressão crescente: mais assets, mais formatos, mais revisões — e os recursos não crescem no mesmo ritmo. 78% dos líderes criativos afirmam que a demanda supera a capacidade de suas equipes. Mas gerar conteúdo mais rápido por si só não resolve o problema central: os roteiros, referências, modelos e resultados ficam espalhados entre ferramentas diferentes, e o contexto precisa ser remontado manualmente a cada etapa.

Para endereçar esse desafio, a AWS publicou uma demonstração de como construir um harness agêntico reutilizável — uma estrutura que preserva contexto, suporta tarefas de mídia de longa duração e introduz revisão humana em momentos críticos do processo criativo. A solução combina o Amazon Quick, a plataforma fal e o Protocolo de Contexto de Modelo (MCP) como interface padrão de integração.

Os quatro componentes do harness criativo

A arquitetura proposta é dividida em quatro camadas reutilizáveis que trabalham juntas para cobrir todo o ciclo criativo:

Amazon Quick

O Amazon Quick é um workspace de IA agêntica voltado para pesquisa, insights de negócio, automação de fluxos e criação de aplicações sem código. Nessa solução, ele atua como a camada de orquestração: interpreta a solicitação do criador, planeja as etapas, retém as decisões aprovadas e aciona as ferramentas externas adequadas para apresentar os resultados para revisão.

Skills (Habilidades)

As Skills são processos repetíveis capturados como instruções reutilizáveis dentro do Amazon Quick. Uma Skill pode codificar regras como “confirmar a direção de arte antes de gerar imagens”, “criar referências de personagem antes de produzir cenas” e “pausar para aprovação em checkpoints de qualidade definidos”. Isso permite que equipes reutilizem um processo criativo em vez de reconstruí-lo do zero a cada campanha.

fal

A fal é uma plataforma de mídia generativa para desenvolvedores e empresas, com acesso a mais de 1.000 modelos para geração de imagem, vídeo, áudio, 3D e outras modalidades. Esses modelos cobrem exploração de personagens, geração de imagens guiada por referência, produção de áudio e criação de vídeo.

Protocolo de Contexto de Modelo (MCP)

O Protocolo de Contexto de Modelo (MCP) é um padrão aberto que permite que aplicações de IA se conectem a ferramentas externas e fontes de dados por meio de uma interface consistente. A fal disponibiliza suas capacidades generativas via servidor MCP, e o Amazon Quick usa seu cliente MCP para descobrir e invocar essas ferramentas.

Benefícios da integração para equipes criativas

Conectar o Amazon Quick à fal via MCP oferece vantagens práticas para times de produção:

• Workspace criativo unificado: planejamento, geração, comparação e refinamento de assets acontecem em um só lugar, sem alternar entre ferramentas para cada modalidade.
• Contexto preservado entre etapas: escolhas de estilo aprovadas, referências de personagem, beats narrativos e requisitos de formato permanecem no contexto de trabalho ao longo de todo o projeto.
• Julgamento humano nos gates criativos: o agente pode pausar após etapas-chave para que o criador escolha uma direção antes de gerar os assets seguintes.
• Acesso a múltiplos modelos generativos: equipes usam modelos diferentes para imagem, áudio e vídeo por meio de uma única conexão MCP.
• Práticas de produção repetíveis: as Skills do Amazon Quick codificam as etapas preferidas da equipe, permitindo que outros membros sigam o mesmo processo com os mesmos checkpoints de qualidade.
• Validação de conceito mais rápida: é possível avaliar um storyboard ou conceito de vídeo antes de comprometer recursos com uma produção completa.

Visão geral da arquitetura

A arquitetura separa a orquestração do fluxo de trabalho da geração de mídia. O Amazon Quick funciona como workspace agêntico e cliente MCP, enquanto a fal hospeda o servidor MCP e fornece as ferramentas generativas. As Skills capturam instruções de fluxo reutilizáveis, e o MCP oferece a interface consistente para descobrir e invocar as capacidades da fal em diferentes workflows de mídia.

O criador descreve o resultado desejado no Amazon Quick, que aciona as ferramentas apropriadas via conector MCP da fal. A fal processa cada solicitação e retorna o asset gerado para revisão. O criador pode então aprovar o resultado, solicitar revisões ou gerar assets adicionais.

Como configurar a integração

Pré-requisitos

• Acesso ao Amazon Quick com o aplicativo desktop instalado e autenticado.
• Conta na fal e uma chave de API disponível para a integração.
• Permissão para adicionar e configurar um conector remoto de Protocolo de Contexto de Modelo (MCP) no Amazon Quick.

Passo 1: Obter a chave de API da fal

Acesse o painel da fal, crie uma nova chave de API para a integração ou recupere uma existente. Armazene a chave com segurança e não a inclua em capturas de tela, arquivos de código ou documentos compartilhados.

Passo 2: Conectar o servidor MCP da fal ao Amazon Quick

No aplicativo desktop do Amazon Quick, acesse Settings → Capabilities → Connectors e escolha Add MCP Server: Remote. Para a URL, informe https://mcp.fal.ai/mcp. No campo de cabeçalho, insira Authorization: Key SUA_CHAVE_API_FAL.

Passo 3: Validar as ferramentas da fal

Salve o conector e confirme que o Amazon Quick consegue descobrir as ferramentas expostas pelo servidor MCP da fal. Após a conexão estar ativa, inicie uma nova conversa no Amazon Quick para verificar o funcionamento.

Workflow 1: Produção de storyboard em oito painéis

O primeiro exemplo mostra como uma equipe de marketing pode criar um storyboard de oito painéis para o lançamento de um produto. Em um processo tradicional, isso envolveria briefing, designer, três rodadas de feedback e uma semana de trabalho. Com o Amazon Quick, o mesmo trabalho acontece em uma sessão interativa como um loop agêntico: o Quick planeja, gera, apresenta opções, aguarda aprovação e continua.

O prompt utilizado no exemplo é:

Create an 8-panel storyboard for a futuristic racing-prototype launch. Use an anime style and comic-grid layout. The story follows a young racer from pre-test preparation and the prototype reveal through a high-speed test drive. Follow this sequence:
1. Lock the creative direction: Confirm the art style, comic-grid format, aspect ratio, and restrictions.
2. Approve the story plan: Draft eight story beats, a shot list, and the character description.
3. Lock the character design: After approval, inspect the available fal models and generate two labeled character options for comparison. Once I select one, create its multi-view reference sheet and wait for approval before generating storyboard panels.

Etapa 1: Definir estilo, formato e plano narrativo

O Quick confirma o estilo anime, o layout de grid de quadrinhos, a proporção e as restrições visuais, transportando essas definições para todas as chamadas seguintes. Em seguida, produz um esboço escrito com oito beats narrativos, lista de planos e descrição do personagem — sem gerar imagens nessa etapa. O criador pode revisar a história, o ritmo, o tratamento do personagem ou a direção visual antes de aprovar o plano.

Etapa 2: Explorar e definir o design do personagem

Após a aprovação do plano escrito, o Quick inspeciona os modelos disponíveis na fal e gera dois designs alternativos de personagem para comparação. O criador seleciona a opção que melhor corresponde à campanha pretendida. Em seguida, o Quick cria um pacote de referência mostrando o personagem selecionado de frente e de costas, em múltiplas poses com capacete e em close-up facial. Nenhum painel do storyboard é gerado até que essa referência seja aprovada.

Etapa 3: Geração de painéis guiada por referência

Com o design do personagem aprovado, o Quick usa o modelo FLUX.1 Kontext para gerar cada painel, fornecendo as referências aprovadas do personagem em cada chamada para preservar a identidade visual ao longo das cenas.

Etapa 4: Renderização final

Após os oito painéis serem aprovados, o Quick os organiza na ordem da lista de planos e adiciona legendas para criar um visualizador interativo de storyboard. O criador pode revisar e ajustar painéis individuais antes de apresentar o storyboard no formato grid de quadrinhos, scroll ou slideshow — sem regenerar as imagens já aprovadas.

Etapa 5: Converter o workflow em uma Skill reutilizável

Após validar o processo, o criador pode pedir ao Quick para criar uma Skill chamada “AI Storybuilding” a partir da conversa. A Skill captura todas as etapas: confirmação da direção criativa, planejamento narrativo escrito, comparação A/B de designs de personagem, criação de folha de referência multi-ângulo, aprovação antes da geração de painéis, geração guiada por referência e revisão final. As Skills no Amazon Quick são fluxos compartilháveis — uma pessoa captura o processo validado e outros membros da equipe o executam com os mesmos checkpoints de qualidade.

Workflow 2: Prototipagem de conceito de videoclipe

O segundo workflow reutiliza uma Skill salva para levar um conceito de videoclipe do briefing até um preview com lip-sync.

Etapa 1: Ativar a Skill existente

A equipe já possui uma Skill compartilhada de “Music Video Prototyping” no Amazon Quick, que codifica coleta de briefing, planejamento de planos, geração de música, referências de personagem, gates de aprovação criativa, testes de movimento e lip-sync, aprovação de substituição de modelo e entrega de assets. O criador inicia com o prompt:

Use the Music Video Prototyping Skill to create a 60-second country music video concept. Generate the song, design the characters, and produce a lip-synced video preview.

O Quick ativa a Skill, coleta os requisitos ausentes e segue o fluxo e os gates de aprovação salvos.

Etapa 2: Planejar a produção

O Quick decompõe o conceito em planos individuais, identificando os close-ups de performance que precisam de lip-sync, os planos de estabelecimento e B-roll, as referências de personagem necessárias e o áudio para cada sequência. O criador revisa o plano de planos antes de iniciar a geração de mídia.

Etapa 3: Gerar música e referências visuais

Após a aprovação, o Quick gera uma trilha de música country com os modelos de áudio disponíveis via fal, cria referências de personagem para consistência visual e produz os stills de cena e trechos de áudio necessários para os planos planejados.

Etapa 4: Produzir e revisar um teste de lip-sync

Antes de gerar o vídeo completo, o Quick produz um clipe curto de performance com lip-sync. O criador pode avaliar o movimento facial, o timing, a qualidade da performance e a consistência visual antes de continuar.

Etapa 5: Avançar para o preview completo do conceito

Após validar a música, a direção do personagem e o teste de lip-sync, o criador pode continuar prototipando o vídeo. O Quick pode criar o storyboard da sequência restante, gerar stills de cena, testar um plano com movimento animado e salvar os assets aprovados. O criador então monta esses assets em um preview mais longo do conceito.

Considerações operacionais

• Prefira saída em JPEG quando transparência e qualidade lossless não forem necessárias, pois assets menores reduzem os dados transferidos pela conexão MCP.
• Monitore o uso e os custos da fal durante workflows com geração intensiva.
• Em sessões longas, salve os assets aprovados externamente e processe o trabalho em lotes gerenciáveis.
• Trate a chave de API da fal como um segredo: armazene-a apenas na configuração do conector, restrinja o acesso, faça rotação se for exposta e não a inclua em prompts, arquivos, capturas de tela ou logs.
• Como a fal é um serviço de terceiros, envie apenas conteúdo aprovado, siga os requisitos de tratamento de dados da sua organização e revise os resultados antes de compartilhá-los.

Conclusão

A integração entre Amazon Quick e fal demonstra um padrão de harness agêntico voltado para produção de mídia. O Amazon Quick orquestra o fluxo e captura a lógica reutilizável em Skills; o MCP fornece o contrato de ferramentas compartilhado; e a fal disponibiliza as capacidades de imagem, áudio e vídeo. O valor da integração não está apenas em produzir um asset isolado — está em coordenar o loop criativo completo: estabelecer direção, gerar alternativas, preservar referências aprovadas, pausar para julgamento humano e montar um protótipo.

Para experimentar esse padrão, a AWS recomenda seguir o guia de integração MCP do Amazon Quick para configurar o conector da fal, validar as ferramentas disponíveis e iniciar com um workflow criativo com gates de aprovação.

Fonte

Build agentic creative workflows with Amazon Quick and fal (https://aws.amazon.com/blogs/machine-learning/build-agentic-creative-workflows-with-amazon-quick-and-fal/)