Blog

  • Gere imagens e vídeos com vLLM-Omni no SageMaker AI – Parte 2

    Da imagem ao vídeo com um único contêiner no SageMaker AI

    A AWS publicou a segunda parte da série dedicada ao vLLM-Omni no Amazon SageMaker AI, e desta vez o foco é geração de mídia: você parte de um prompt de texto, gera uma imagem estática e depois anima essa imagem em um curto vídeo. Tudo isso usando dois endpoints implantados a partir do mesmo Contêiner de Aprendizado Profundo (DLC) da AWS.

    Para quem perdeu a primeira parte, ela abordava streaming bidirecional de voz em tempo real. A Parte 1 da série usa o vLLM-Omni com SageMaker AI para aplicações de fala em tempo real. Já esta Parte 2 demonstra dois padrões distintos de inferência — tempo real e assíncrona — aplicados a modelos de imagem e vídeo.

    O que é o vLLM-Omni e por que ele importa aqui

    Os AWS Deep Learning Containers empacotam frameworks e dependências prontas para treinamento e inferência na AWS. O AWS vLLM-Omni DLC vai além: ele rastreia as versões do vLLM-Omni e adiciona um middleware de roteamento específico para o SageMaker AI.

    O vLLM-Omni estende o vLLM tradicional — que normalmente lida apenas com texto — para modelos que processam ou geram texto, áudio, imagens e vídeo, tudo por meio de APIs compatíveis com o padrão OpenAI. Isso significa que você pode usar chamadas de API familiares para acionar modelos multimodais sem precisar reescrever sua lógica de integração.

    Visão geral da solução

    A solução implanta a mesma imagem do AWS vLLM-Omni DLC em dois endpoints do SageMaker AI. O script de implantação altera a variável SM_VLLM_MODEL para carregar o FLUX.2-klein-4B em um endpoint e o Wan2.1-VACE-1.3B no outro. Usar uma imagem de contêiner comum reduz a variação na pilha de serviço, enquanto endpoints separados permitem que cada modelo use o tipo de instância e a opção de inferência mais adequados à sua carga de trabalho.

    O fluxo funciona assim:

    • Um endpoint de inferência em tempo real do SageMaker AI executa o FLUX.2-klein e roteia requisições para /v1/images/generations.
    • Um endpoint de Inferência Assíncrona do SageMaker executa o Wan VACE e roteia requisições para /v1/videos/sync.
    • O Amazon S3 armazena tanto a requisição multipart do vídeo quanto o arquivo MP4 gerado.

    A aplicação envia o prompt de imagem ao FLUX.2-klein e recebe um arquivo PNG codificado em base64. Em seguida, redimensiona a imagem para as dimensões do vídeo, converte para JPEG em formato de URL de dados e insere essa referência na requisição do Wan VACE. A Inferência Assíncrona do SageMaker lê a requisição multipart do Amazon S3 e grava o MP4 no local de saída retornado.

    Por que usar inferência em tempo real para imagem e assíncrona para vídeo?

    A escolha de padrões de inferência diferentes para cada modelo não é arbitrária. A geração de imagem usa inferência em tempo real porque a aplicação precisa da resposta diretamente antes de construir a próxima requisição — o PNG gerado é o insumo para o passo seguinte.

    Já a geração de vídeo é uma operação mais demorada e carrega um payload multipart condicionado à imagem. A Inferência Assíncrona do SageMaker enfileira a requisição e usa o Amazon S3 para entrada e saída, permitindo que o cliente consulte o local do resultado em vez de manter uma requisição síncrona aberta. Vale reforçar: isso é uma escolha de arquitetura para esta carga de trabalho específica, não uma regra universal para todos os modelos de vídeo.

    Pré-requisitos

    Antes de começar, você vai precisar de:

    • Uma conta AWS com credenciais configuradas para o CLI da AWS ou um SDK.
    • Uma role de execução do SageMaker AI com acesso ao bucket Amazon S3 do exemplo.
    • Permissão para criar e invocar endpoints do SageMaker AI.
    • Cota de endpoint para ml.g6.xlarge e ml.g6e.xlarge na região AWS selecionada.
    • Git e Python 3.11 ou superior.

    O exemplo usa a região Leste dos EUA (Norte da Virgínia). Revise os preços do SageMaker AI antes de implantar os endpoints com GPU.

    Passo a passo: gerando a imagem e animando-a

    1. Clone o repositório

    Clone o repositório de exemplos e acesse o diretório do exemplo de imagem e vídeo com vLLM-Omni:

    git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git
    cd sagemaker-genai-hosting-examples/03-features/vllm-omni-image-video

    2. Instale as dependências Python

    Crie um ambiente virtual e instale os requisitos do exemplo:

    python -m venv .venv
    source .venv/bin/activate
    python -m pip install -r requirements.txt

    3. Implante os endpoints de imagem e vídeo

    Configure a role de execução do SageMaker AI e execute o script de implantação. O script fixa a versão omni-sagemaker-cuda-v1.6, cria um endpoint de imagem em tempo real, cria um endpoint de vídeo assíncrono e salva os nomes dos recursos em .vllm_omni_media_state.json:

    export SAGEMAKER_ROLE_ARN=<your-sagemaker-execution-role-arn>
    python deploy.py \
      --role-arn "$SAGEMAKER_ROLE_ARN" \
      --region us-east-1

    A variável de ambiente SM_VLLM_MODEL indica a cada contêiner qual modelo carregar. O endpoint de vídeo ativa o tiling do Codificador Variacional Automático (VAE) para reduzir o pico de memória durante a decodificação de vídeo. Se as credenciais AWS locais expirarem enquanto um endpoint está sendo iniciado, atualize-as e reexecute o comando com --resume — o script reutilizará os recursos já criados.

    4. Gere uma imagem e anime-a

    Execute o fluxo de linha de comando de ponta a ponta com um prompt de imagem e um prompt de movimento:

    python generate.py \
      --image-prompt "Cinematic photograph of a coastal observatory at sunrise" \
      --video-prompt "Slow camera push-in toward the coastal observatory; preserve the building and coastline"

    O FLUX.2-klein retorna uma resposta JSON compatível com OpenAI contendo o PNG como dados em base64. O helper de requisição compartilhado redimensiona a imagem para as dimensões alvo do vídeo e a codifica como JPEG antes de construir a requisição do Wan VACE:

    reference_image = prepare_video_reference(
        image_bytes,
        width=480,
        height=320,
    )
    fields = {
        "prompt": video_prompt,
        "image_reference": json.dumps(
            {"image_url": image_data_url(reference_image, "image/jpeg")}
        ),
        "num_frames": "17",
        "num_inference_steps": "30",
    }
    body, content_type = encode_multipart_formdata(fields)

    Essa conversão mantém a referência de imagem segura para JSON abaixo do limite de tamanho por parte do parser multipart da API de Vídeos. O exemplo faz upload da requisição completa para o Amazon S3 e a submete ao endpoint assíncrono com route=/v1/videos/sync. O SageMaker AI retorna os locais de saída e falha. O script consulta esses locais antes de validar e salvar o MP4 em outputs/.

    Para requisições menores, o InvokeEndpointAsync também aceita dados de requisição inline pelo parâmetro Body até 128.000 bytes. Use Body ou InputLocation, nunca os dois juntos. Este fluxo usa InputLocation porque a requisição multipart condicionada à imagem é maior que o limite de 128.000 bytes do parâmetro inline Body.

    As configurações padrão de vídeo usam 17 frames e 30 passos de difusão. Use quatro passos apenas para um teste rápido de validação do endpoint, pois essa configuração reduzida não preservou bem a composição da fonte nos testes realizados.

    Em uma execução de validação na região Leste dos EUA (Norte da Virgínia), o endpoint de imagem ml.g6.xlarge ficou ativo em 9 minutos e 30 segundos. O endpoint de vídeo ml.g6e.xlarge ficou ativo em 8 minutos e 40 segundos. Uma invocação padrão aquecida retornou a imagem em 4,7 segundos. O Wan VACE reportou 8,9 segundos de latência do modelo, e o CLI recuperou o MP4 em 11,8 segundos. Esses valores são pontos de referência de reprodução, não benchmarks de desempenho.

    5. Execute a aplicação Streamlit

    Inicie a aplicação Streamlit após ambos os endpoints atingirem o status InService:

    streamlit run app.py

    Na interface, você pode atualizar o prompt de imagem, o tamanho da imagem ou o seed e então gerar a imagem. Após revisar o resultado do FLUX.2-klein, insira um prompt de movimento e ajuste a contagem de frames, os frames por segundo ou os passos de inferência antes de gerar o vídeo. A aplicação invoca os endpoints implantados e usa os mesmos helpers de requisição do fluxo de linha de comando.

    Tipos de instância e pools de capacidade

    O exemplo usa os tipos de instância fixos ml.g6.xlarge e ml.g6e.xlarge. Para o endpoint de imagem em tempo real, os pools de instâncias com consciência de capacidade do SageMaker podem listar tipos de instância compatíveis em ordem de prioridade. Adicione um pool somente após validar cada tipo candidato quanto aos requisitos de memória de GPU e desempenho do modelo de imagem. O exemplo mantém o endpoint de vídeo assíncrono em um tipo de instância fixo.

    Limpeza dos recursos

    Ao terminar, delete os endpoints, as configurações de endpoint e os modelos com o script de limpeza:

    python cleanup.py

    O script de limpeza mantém os objetos gerados sob o prefixo de saída do Amazon S3 para revisão. Delete esse prefixo quando não precisar mais dos artefatos. Lembre-se: um endpoint GPU em execução continua gerando cobranças.

    O que esse padrão demonstra

    A solução mostra como um único runtime de serviço compartilhado pode suportar diferentes famílias de modelos enquanto o SageMaker AI aplica o padrão de resposta que melhor se adequa a cada carga de trabalho. Usar o mesmo DLC para dois modelos com comportamentos muito diferentes — um que retorna resultado imediato e outro que processa de forma assíncrona — simplifica a operação sem sacrificar a flexibilidade.

    Para explorar mais, a AWS disponibiliza o código de exemplo completo, a documentação do vLLM-Omni DLC e o guia do desenvolvedor de Inferência Assíncrona do SageMaker para adaptar o padrão a outros modelos de imagem e vídeo suportados.

    Recursos adicionais

    Fonte

    Generate images and video with vLLM-Omni on SageMaker AI – Part 2 (https://aws.amazon.com/blogs/machine-learning/generate-images-and-video-with-vllm-omni-on-sagemaker-ai-part-2/)

  • Amazon Rekognition Face Liveness agora retorna Códigos de Feedback

    O que mudou no Rekognition Face Liveness

    A AWS anunciou uma atualização relevante para o Amazon Rekognition Face Liveness: o serviço agora retorna Códigos de Feedback nas sessões de verificação de vivacidade. A novidade ajuda desenvolvedores e usuários finais a entenderem com precisão por que uma verificação recebeu uma pontuação baixa — e o que fazer para corrigir isso na próxima tentativa.

    Como funcionam os Códigos de Feedback

    Os códigos são retornados diretamente na resposta da API GetFaceLivenessSessionResults. Cada código identifica uma condição específica que contribuiu para a pontuação baixa na sessão. Entre os exemplos citados pela AWS estão:

    • Iluminação inadequada
    • Obstrução do rosto
    • Olhos fechados
    • Baixa qualidade de vídeo

    Um ponto importante: uma única sessão pode retornar múltiplos Códigos de Feedback ao mesmo tempo. Isso significa que o usuário consegue identificar e corrigir todos os problemas de uma só vez, sem precisar de várias tentativas para descobrir cada obstáculo separadamente.

    Por que isso é útil na prática

    Antes dessa atualização, quando uma verificação de vivacidade falhava ou recebia pontuação baixa, o usuário não tinha clareza sobre o motivo — o que tornava a retenção em fluxos de onboarding e reautenticação um desafio real. Agora, as aplicações podem exibir esses códigos diretamente para o usuário final, orientando correções específicas antes de uma nova tentativa.

    A AWS destaca que o recurso é especialmente útil em três cenários:

    • Onboarding de verificação de identidade — quando o usuário está se cadastrando pela primeira vez
    • Fluxos de reautenticação — quando é necessário confirmar a identidade novamente
    • Cenários de acessibilidade — onde condições específicas do ambiente ou do usuário podem afetar a qualidade da captura

    O que é o Amazon Rekognition Face Liveness

    Para quem ainda não conhece o serviço: o Amazon Rekognition Face Liveness verifica se a pessoa na frente da câmera é um ser humano real e presente — e não uma foto, replay de vídeo, máscara ou deepfake. A verificação é feita por meio de um curto processo guiado de selfie em vídeo.

    O serviço retorna três elementos principais:

    • Uma pontuação de confiança sobre a vivacidade detectada
    • Uma imagem de referência para uso em correspondência facial
    • Imagens de auditoria da sessão

    Disponibilidade

    O Amazon Rekognition Face Liveness está disponível nas seguintes regiões da AWS:

    • US East (Norte da Virgínia)
    • US West (Oregon)
    • Europe (Irlanda)
    • Asia Pacific (Tóquio, Mumbai, Malásia, Tailândia)
    • South America (São Paulo)

    Para se aprofundar, a AWS disponibiliza a documentação da API do Amazon Rekognition Face Liveness e também um FAQ do Face Liveness com respostas às dúvidas mais comuns.

    Fonte

    Amazon Rekognition Face Liveness now returns Feedback Codes (https://aws.amazon.com/about-aws/whats-new/2026/09/rekognition-liveness-feedback-codes/)

  • Grok 4.7 já está disponível no Amazon Bedrock

    O que foi anunciado

    A AWS anunciou que o Grok 4.7, modelo de fronteira desenvolvido pela SpaceXAI, já está disponível no Amazon Bedrock. O modelo foi construído com foco em tarefas de codificação, trabalho agêntico e processamento de conhecimento — e chega com suporte a inferência cross-region nas modalidades US Geo e Global.

    O que mudou em relação ao Grok 4.6

    O Grok 4.7 evolui sobre a versão anterior, o Grok 4.6, trazendo melhorias concretas em três frentes:

    • Melhor manipulação de documentos mistos: o modelo lida com mais eficiência com conteúdos que combinam diferentes tipos de informação em um mesmo contexto.
    • Codificação em escala de repositório mais confiável: o Grok 4.7 traz planejamento aprimorado e capacidade de recuperação de erros ao trabalhar com bases de código maiores e mais complexas.
    • Agentes de uso de navegador aprimorados: a nova versão melhora a capacidade de agentes executarem tarefas práticas como preenchimento de formulários e navegação em portais web.

    Como começar a usar

    Quem quiser experimentar o Grok 4.7 pode acessá-lo diretamente pelo console do Amazon Bedrock ou de forma programática pelas APIs suportadas pelo Amazon Bedrock.

    Para detalhes sobre regiões da AWS compatíveis, endpoints, APIs, funcionalidades, perfis de inferência e preços, a AWS disponibiliza a documentação oficial do Amazon Bedrock. Para uma visão mais aprofundada sobre o lançamento, vale conferir também o blog post oficial.

    Fonte

    Grok 4.7 is now available on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-grok-4-7/)

  • Claude Sonnet 5.5 já está disponível na AWS

    Um salto claro em relação ao Sonnet 5

    A AWS anunciou a disponibilidade do Claude Sonnet 5.5, o mais recente modelo de linguagem da Anthropic na plataforma. Segundo o anúncio, o Sonnet 5.5 representa uma evolução direta sobre o Sonnet 5 — mais inteligente, mais eficiente e com custo menor por tarefa para a maioria dos casos de uso, além de operar em velocidade superior.

    Para equipes que já constroem soluções sobre o Sonnet, a transição é descrita como uma atualização natural, sem necessidade de grandes adaptações.

    O que melhora na prática

    Codificação mais robusta

    O Sonnet 5.5 foi aprimorado especialmente para tarefas de desenvolvimento de software. Ele se destaca na execução de atividades bem delimitadas dentro de uma estratégia de codificação maior — como construir e corrigir funcionalidades dentro de uma mesma sessão, ou verificar se a saída gerada está de acordo com os requisitos estabelecidos.

    Produção de conhecimento pronta para compartilhar

    Além do código, o modelo também entrega resultados mais refinados em trabalhos de conhecimento: documentos de uma página, diagramas, slides de resumo, edição de documentos e organização de planilhas. O diferencial destacado é que esses materiais saem prontos para serem compartilhados, sem precisar de grandes ajustes.

    Duas formas de acessar o Claude Sonnet 5.5

    A AWS disponibiliza o modelo por dois caminhos distintos, cada um com um perfil diferente:

    Amazon Bedrock

    Para quem prioriza controle e governança dentro do ecossistema AWS, o Amazon Bedrock mantém os dados dentro da infraestrutura da AWS, com residência regional dos dados. O acesso é feito por um serviço unificado que inclui recursos gerenciados como Guardrails e Knowledge Bases. Para saber mais, consulte a documentação do Amazon Bedrock e a disponibilidade por região.

    Claude Platform on AWS

    Já a Claude Platform on AWS oferece acesso direto à experiência nativa da Anthropic, acessível pelo Console da AWS. Com ela, é possível construir, testar e implantar usando as mesmas APIs, funcionalidades e experiência de console que se teria trabalhando diretamente com a Anthropic — mas com a conveniência da cobrança e autenticação unificadas com a AWS. Para começar, acesse a documentação da Claude Platform on AWS.

    Fonte

    Claude Sonnet 5.5 now available on AWS (https://aws.amazon.com/about-aws/whats-new/2026/09/claude-sonnet-5-5-aws/)

  • AWS European Sovereign Cloud: demonstrando operação independente dentro da União Europeia

    A AWS vai provar na prática que sua nuvem europeia é soberana de verdade

    No sábado, 24 de outubro de 2026, a AWS realizará um exercício técnico para demonstrar que a AWS European Sovereign Cloud é capaz de operar de forma completamente autônoma, sem depender de nenhuma infraestrutura localizada fora da União Europeia (UE). O teste vai além de uma simples declaração: a proposta é gerar evidências concretas e verificáveis.

    Durante algumas horas, a nuvem soberana europeia da AWS funcionará desconectada do backbone da Rede Global AWS — a rede privada que normalmente transporta dados operacionais autorizados entre os datacenters da empresa, sem passar pela internet pública. No período do exercício, esse tráfego será redirecionado com segurança pela internet pública.

    O que vai (e o que não vai) ser afetado

    A AWS deixou claro que o exercício não afetará a disponibilidade dos serviços dentro da AWS European Sovereign Cloud, nem em outras Regiões AWS, nem nas conexões privadas via AWS Direct Connect.

    O único impacto esperado são breves interrupções de conectividade durante as transições de rota de rede — uma no início do exercício, quando o tráfego migra para os provedores de internet exclusivos da nuvem soberana, e outra no final, quando o tráfego retorna ao backbone global. Esse fenômeno é chamado de convergência: o tempo curto em que outras redes ajustam suas tabelas de roteamento para refletir a mudança.

    A equipe operacional responsável pela execução do exercício é composta inteiramente por residentes da UE, trabalhando dentro da UE, utilizando exclusivamente os recursos de hardware e software da própria AWS European Sovereign Cloud.

    O que é a AWS European Sovereign Cloud

    A AWS European Sovereign Cloud é uma nuvem independente, criada especificamente para a Europa. Seus datacenters estão localizados em Brandemburgo, na Alemanha, e são fisicamente e logicamente separados das demais Regiões AWS ao redor do mundo. Uma cópia local do código-fonte fica armazenada dentro da UE.

    Todo o conteúdo dos clientes e os metadados criados por eles permanecem dentro da UE. A infraestrutura não possui dependências críticas de recursos fora do bloco e é operada exclusivamente por residentes da UE.

    Em condições normais de operação, a AWS European Sovereign Cloud utiliza dois sistemas globais:

    • O backbone da Rede Global AWS, que oferece desempenho superior, capacidade, confiabilidade, segurança e economia de custos — incluindo criptografia permanente e defesas contra ataques de negação de serviço distribuído (DDoS). Vale destacar que o backbone não consegue descriptografar nem visualizar os dados trafegados pelos clientes da nuvem soberana.
    • Um sistema dedicado, controlado e supervisionado pela equipe local da UE, que gerencia transferências limitadas e controladas de dados operacionais da AWS.

    Nenhum dos dois sistemas é crítico para a operação, e nenhum deles afeta as garantias de soberania da plataforma. A AWS European Sovereign Cloud pode operar de forma independente a qualquer momento — e é exatamente isso que o exercício de outubro vai demonstrar.

    Alinhamento com frameworks regulatórios europeus

    O exercício foi desenhado para produzir evidências técnicas e operacionais verificáveis de que a nuvem pode funcionar de forma autônoma dentro da UE. A iniciativa está alinhada aos objetivos do EU Cloud Sovereignty Framework (CSF) da Comissão Europeia e aos critérios do framework C3A do BSI — o Escritório Federal Alemão para Segurança da Informação.

    Esses frameworks estabelecem os critérios para avaliar se serviços de nuvem podem ser fornecidos de forma independente e autônoma. A AWS projetou a nuvem soberana especialmente para clientes regulados e para o setor público em toda a UE.

    O AWS European Sovereign Cloud: Sovereign Reference Framework (ESC-SRF) oferece um conjunto abrangente de evidências, mapeamentos de controles, artefatos e outros elementos que reguladores e autoridades de conformidade precisam para acelerar a adoção da plataforma. Os resultados do exercício de outubro vão compor pacotes adicionais de conformidade e assurance para clientes e parceiros.

    O que acontece com os dados dos clientes durante o exercício

    A AWS reafirma o compromisso de não mover o conteúdo dos clientes nem os metadados criados por eles para fora da UE. Apenas determinados dados operacionais da AWS — que não se enquadram como conteúdo ou metadados de clientes — deixam o bloco, e isso ocorre por meio do sistema dedicado controlado pela equipe local.

    Durante o exercício, esse sistema será completamente desativado. Isso confirmará, na prática, que a AWS European Sovereign Cloud continua operando de forma independente mesmo sem ele.

    Para a conectividade com a internet mundial, a nuvem soberana utilizará exclusivamente sua conectividade dedicada com provedores europeus de serviços de internet — sem passar pelo backbone global da AWS.

    Próximos passos

    Após a realização do exercício, a AWS compartilhará uma atualização com reguladores e clientes. Para saber mais sobre o design e os controles de soberania digital da AWS European Sovereign Cloud, acesse aws.eu. Em caso de dúvidas sobre o exercício ou sobre possíveis impactos nas suas cargas de trabalho, a recomendação da AWS é entrar em contato com o Suporte AWS ou com o time de conta responsável.

    Fonte

    AWS European Sovereign Cloud: Demonstrating an independent operation (https://aws.amazon.com/blogs/security/aws-european-sovereign-cloud-demonstrating-an-independent-operation/)

  • CloudTroop Weekly #031 — 2026-w39





    CloudTroop Weekly #031 — 2026-w39

    27 de setembro de 2026

    Resumo da Semana

    A semana foi dominada pela expansão da IA agêntica na AWS. GPT-6 Sol e Luna chegaram ao Bedrock com contexto de 1 milhão de tokens e preços menores, enquanto o AgentCore Runtime resolve dois problemas críticos de produção: custo de memória ociosa e cold starts imprevisíveis. O CloudWatch Omni redefine observabilidade com interface conversacional para ambientes complexos. Na segurança, MFA obrigatório para root virou realidade em todas as contas. Quem opera MySQL 5.7 ou 8.0 ganhou fôlego extra com o suporte estendido do RDS. A mensagem da semana: IA agêntica saiu do laboratório e exige maturidade operacional.

    O que muda na prática

    • Agentes de IA em produção ficam mais baratos e previsíveis: o AgentCore Runtime elimina cobrança por memória ociosa e estabiliza latência de inicialização, impactando diretamente custo e SLA de quem já opera agentes.
    • MFA para root é obrigatório agora em todas as contas AWS — times que ainda não configuraram precisam agir antes de enfrentar bloqueio ou não conformidade em auditorias.
    • Observabilidade e segurança de IA se integram ao stack existente: CloudWatch Omni centraliza monitoramento multi-conta com IA, e Bedrock Guardrails exporta eventos em OCSF direto para o SIEM, sem pipelines customizados.

    Ações da semana

    • Verifique agora se todas as contas AWS da sua organização têm MFA ativo no usuário root — acesse o IAM Dashboard e corrija qualquer conta pendente antes que a exigência cause bloqueio operacional.
    • Se você opera ou planeja agentes no Bedrock, avalie o novo AgentCore Runtime e teste os GPT-6 Sol/Luna para workloads de alto volume: o contexto de 1M de tokens e o modelo de custo revisado podem mudar sua decisão de arquitetura.

    Top 10 da Semana

    1

    GPT-6 Sol e GPT-6 Luna da OpenAI disponíveis no Amazon Bedrock

    Dois novos modelos da OpenAI com 1M de tokens de contexto e preços menores chegam ao Bedrock, ampliando opções para workloads complexos e de alto volume dentro da infraestrutura AWS.

    Para quem: Arquitetos e engenheiros de IA que avaliam modelos de linguagem para produção no Bedrock.

    IA Generativa

    2

    Novo AgentCore Runtime: elástico, otimizado e com cold starts consistentes

    Resolve dois problemas críticos de agentes em produção — custo de memória ociosa e latência de inicialização imprevisível — com impacto direto em custo e SLA.

    Para quem: Engenheiros que operam ou planejam colocar agentes de IA em produção no Amazon Bedrock AgentCore.

    IA Agêntica

    3

    Amazon CloudWatch Omni: observabilidade com IA para agentes e aplicações

    Unifica monitoramento de workloads multi-conta, multi-região e multi-cloud com interface conversacional, mudando como equipes operam e depuram sistemas distribuídos.

    Para quem: SREs, engenheiros de plataforma e times de operações que gerenciam ambientes AWS complexos.

    Observabilidade

    4

    Agente de IA multi-conta com AgentCore Gateway e MCP

    Apresenta um padrão arquitetural concreto para governança de dados em ambientes multi-conta, permitindo que agentes acessem dados distribuídos sem centralização ou cópia.

    Para quem: Arquitetos de soluções e engenheiros de dados que constroem agentes de IA em organizações com múltiplas contas AWS.

    IA Agêntica, Governança

    5

    MFA obrigatório para root: AWS atinge marco histórico na segurança

    A exigência de MFA para todos os usuários root é uma mudança de postura de segurança com impacto imediato em qualquer conta AWS, especialmente relevante para times que ainda não adotaram a prática.

    Para quem: Administradores de contas AWS, equipes de segurança e compliance que gerenciam identidade e acesso.

    Segurança, IAM

    6

    SageMaker Inference em 2026: 13 novidades que mudam a inferência de IA

    Consolida em um único artigo as melhorias mais relevantes do ano para inferência em produção, incluindo cache de KV, separação prefill/decode e compatibilidade com API OpenAI.

    Para quem: Engenheiros de ML e arquitetos que operam endpoints de inferência de IA generativa no SageMaker.

    Inferência, MLOps

    7

    Bedrock Guardrails em OCSF no CloudWatch: segurança de IA padronizada

    Permite correlacionar eventos de intervenção de IA com dados de identidade e rede em formato padrão OCSF, integrando segurança de LLMs ao SIEM existente sem pipelines customizados.

    Para quem: Engenheiros de segurança e times de SecOps que monitoram workloads de IA generativa em produção.

    Segurança, IA

    8

    Avalie agentes com skills usando Strands Evals e AgentCore

    Oferece ferramentas concretas para medir falhas de seleção e execução em agentes com skills, problema crítico que respostas fluentes costumam mascarar em produção.

    Para quem: Engenheiros de IA e QA que desenvolvem e operam agentes baseados em skills no Amazon Bedrock.

    IA Agêntica, Avaliação

    9

    Lambda Durable Functions disponíveis na Região Soberana Europeia

    Equipes sujeitas a requisitos de conformidade europeus (GDPR, NIS2) podem agora usar fluxos de trabalho multi-etapa com checkpoints e recuperação automática sem sair da soberania de dados da UE.

    Para quem: Arquitetos e engenheiros de empresas europeias ou com obrigações regulatórias de residência de dados na Europa.

    Serverless, Compliance

    10

    RDS MySQL ganha novas versões de Suporte Estendido: 5.7.44 e 8.0.46

    Times que ainda operam MySQL 5.7 ou 8.0 sem plano de migração imediato recebem mais tempo e patches de segurança críticos, reduzindo risco operacional enquanto planejam a atualização.

    Para quem: DBAs e engenheiros de infraestrutura que gerenciam instâncias RDS MySQL em versões próximas ao fim do suporte padrão.

    Banco de Dados, Segurança


  • Transcrição com Identificação de Locutor usando WhisperX no SageMaker AI

    O problema que toda equipe que trabalha com áudio enfrenta

    Qualquer time que lida com áudio falado — centrais de atendimento, reuniões corporativas, podcasts, audiências jurídicas ou conteúdo de mídia — esbarra nos mesmos dois problemas com sistemas genéricos de reconhecimento de fala:

    • Timestamps imprecisos: os carimbos de tempo ficam no nível da frase ou segmento, podendo estar vários segundos fora do lugar.
    • Sem identificação de locutor: não há resposta confiável para “quem disse o quê”.

    Essas lacunas tornam as transcrições difíceis de pesquisar, legendar, redigir ou analisar em escala. Um rótulo de locutor ausente compromete revisões de conformidade; um timestamp impreciso quebra uma legenda ou uma redação de dado sensível.

    O que é o WhisperX e o que ele resolve

    O Whisper é um modelo popular de Reconhecimento Automático de Fala (ASR — Automatic Speech Recognition) de código aberto desenvolvido pela OpenAI. Ele transcreve áudio falado com boa precisão em vários idiomas, mas produz timestamps apenas no nível de frase ou segmento.

    O WhisperX é um projeto de código aberto que estende o Whisper para cargas de trabalho em produção. Ele adiciona três capacidades que transformam o áudio bruto em transcrições estruturadas e analisáveis:

    • Timestamps por palavra: usando alinhamento forçado via wav2vec2, cada palavra recebe seu próprio carimbo de tempo preciso.
    • Identificação de locutor (diarização): rotula quem está falando em cada trecho do áudio.
    • Inferência em lote mais rápida: acelera o processamento para cargas maiores.

    Essas capacidades se traduzem diretamente em casos de uso reais: centrais de atendimento podem medir tempo de fala, verificar aderência a scripts e rodar análise de sentimento; equipes transformam reuniões em notas pesquisáveis; times de mídia e e-learning geram legendas precisas nos formatos SRT (SubRip Subtitle) e VTT (Web Video Text Tracks); e áreas reguladas como saúde, jurídico e finanças usam as transcrições com rótulo de locutor para auditorias e descoberta legal.

    Por que usar o Deep Learning Container da AWS

    O DLC (Deep Learning Container — Contêiner de Aprendizado Profundo) do WhisperX da AWS é uma imagem mantida e pronta para GPU que já contém o Whisper, os modelos de alinhamento e os pesos de diarização — sem necessidade de token do Hugging Face. Ele segue o contrato padrão de serviço do Amazon SageMaker AI, então o deploy funciona como qualquer outro modelo.

    Alguns detalhes do contrato de serviço:

    • O contêiner serve na porta 8080 e expõe POST /invocations para inferência e GET /ping para verificação de saúde.
    • O endpoint espera requisições no formato multipart/form-data, com o áudio como parte file e campos opcionais como language, diarize e response_format.
    • Os formatos de saída suportados são: json, verbose_json, srt e vtt — o mesmo endpoint alimenta tanto pipelines de análise quanto editores de vídeo.

    Escolhendo entre endpoint em tempo real e assíncrono

    O SageMaker AI suporta dois tipos de endpoint para o mesmo DLC do WhisperX. A escolha depende do tamanho do clipe e da necessidade de interatividade:

    • Endpoint em tempo real: ideal para clipes curtos e interativos que terminam dentro do limite de 60 segundos de resposta do SageMaker AI.
    • Endpoint assíncrono: recomendado para áudios longos e processamento em lote de alto volume. Não há limite de tempo de resposta; a entrada e a saída são intermediadas pelo Amazon S3.

    A tabela abaixo resume as diferenças principais entre os dois padrões:

    • Latência: tempo real é síncrono (deve terminar em menos de 60s); assíncrono é no modelo enviar-e-consultar, sem limite de tempo.
    • Invocação: tempo real usa InvokeEndpoint com corpo inline; assíncrono usa InvokeEndpointAsync com referência ao S3.
    • Entrada/Saída: tempo real usa corpo da requisição/resposta; assíncrono usa Amazon S3 para entrada e saída.
    • Custo: tempo real cobra enquanto o endpoint está ativo; assíncrono pode escalar a zero quando ocioso, reduzindo custos.

    Pré-requisitos

    Para seguir os exemplos, você vai precisar de:

    • Uma conta AWS e uma função de execução do SageMaker AI com permissões para create_model, create_endpoint e (para inferência assíncrona) leitura e escrita no S3.
    • Cota de serviço de GPU para o tipo de instância desejado (por exemplo, ml.g4dn.xlarge ou ml.g5.2xlarge).
    • A URI de imagem do DLC do WhisperX no ECR (Amazon Elastic Container Registry): 763104351884.dkr.ecr.<region>.amazonaws.com/whisperx:3.8.6-cu128-amzn2023-sagemaker.
    • Para inferência assíncrona: um bucket S3 cujo nome contenha “sagemaker” — a política padrão AmazonSageMakerFullAccess concede acesso ao S3 apenas para buckets com esse padrão no nome.

    Um notebook JupyterLab completo e executável está disponível no repositório AWS Samples, e pode ser rodado diretamente no SageMaker AI Studio com seu próprio áudio.

    Passo a passo: endpoint em tempo real

    O endpoint em tempo real retorna a transcrição na mesma chamada síncrona. O fluxo funciona assim: o cliente monta um corpo multipart/form-data com o áudio e campos como language, diarize e granularidade de timestamp por palavra, e chama InvokeEndpoint. O SageMaker AI encaminha a requisição ao contêiner na porta 8080. Dentro do contêiner, o WhisperX executa detecção de atividade de voz, transcrição em lote, alinhamento forçado via wav2vec2 e diarização de locutor. O resultado — segmentos, timestamps por palavra e rótulos de locutor — é retornado inline ao cliente, tudo dentro do limite de 60 segundos.

    Criando o modelo e a configuração de endpoint

    Registre o DLC do WhisperX como modelo e crie a configuração de endpoint. Um detalhe crítico: em qualquer variante de GPU, é obrigatório definir InferenceAmiVersion como al2-ami-sagemaker-inference-gpu-3-1. Sem esse pin, o endpoint falha ao iniciar com um erro CannotStartContainerError sem nenhum log. Também é necessário configurar um timeout generoso para o health check de inicialização, pois os pesos são carregados de forma lazy.

    sm = boto3.client("sagemaker")
    
    # The WhisperX Deep Learning Container image (Python 3.12, CUDA 12.8, Amazon Linux 2023).
    REGION = "us-west-2"
    IMAGE_URI = f"763104351884.dkr.ecr.{REGION}.amazonaws.com/whisperx:3.8.6-cu128-amzn2023-sagemaker"
    
    sm.create_model(
        ModelName=MODEL_NAME,
        PrimaryContainer={"Image": IMAGE_URI},  # WhisperX DLC; large-v2 is the default model
        ExecutionRoleArn=ROLE_ARN,
    )
    
    sm.create_endpoint_config(
        EndpointConfigName=ENDPOINT_CONFIG_NAME,
        ProductionVariants=[{
            "VariantName": "AllTraffic",
            "ModelName": MODEL_NAME,
            "InitialInstanceCount": 1,
            "InstanceType": "ml.g4dn.xlarge",
            "InferenceAmiVersion": "al2-ami-sagemaker-inference-gpu-3-1",  # required for CUDA 12.8 DLC
            "ContainerStartupHealthCheckTimeoutInSeconds": 900,
        }],
    )
    
    sm.create_endpoint(EndpointName=ENDPOINT_NAME, EndpointConfigName=ENDPOINT_CONFIG_NAME)
    sm.get_waiter("endpoint_in_service").wait(EndpointName=ENDPOINT_NAME)

    Invocando com diarização e timestamps por palavra

    Monte um corpo multipart/form-data com o áudio e os campos de configuração, depois chame o endpoint:

    def build_multipart(audio_path, fields):
        """Audio as the `file` part + optional string fields, per the WhisperX DLC contract."""
        boundary = uuid.uuid4().hex
        body = b""
        for name, value in fields.items():
            body += (f"--{boundary}\r\n"
                     f'Content-Disposition: form-data; name="{name}"\r\n\r\n'
                     f"{value}\r\n").encode()
        body += (f"--{boundary}\r\n"
                 f'Content-Disposition: form-data; name="file"; filename="audio.wav"\r\n'
                 f"Content-Type: audio/wav\r\n\r\n").encode()
        body += open(audio_path, "rb").read() + b"\r\n"
        body += f"--{boundary}--\r\n".encode()
        return body, f"multipart/form-data; boundary={boundary}"
    
    body, content_type = build_multipart("audio.wav", {
        "language": "en",
        "response_format": "verbose_json",
        "timestamp_granularities[]": "word",   # word-level timestamps
        "diarize": "true",                      # speaker labels
    })
    
    resp = sm_runtime.invoke_endpoint(
        EndpointName=ENDPOINT_NAME,
        ContentType=content_type,
        Body=body,
    )
    transcription = json.loads(resp["Body"].read())

    O repositório de exemplo usa uma gravação de domínio público das comunicações de controle de tráfego aéreo do Voo 1549 da US Airways — o famoso pouso de emergência no Rio Hudson em 2009. É uma conversa real entre múltiplos participantes com ruído de fundo, compressão de rádio e leituras rápidas de indicativos e frequências, o que o torna um excelente teste de precisão de transcrição, timestamps por palavra e diarização. Um segmento de 40 segundos é enviado ao endpoint em tempo real, e o resultado retornado se parece com isto:

    [00:02] SPEAKER_01: Cactus 1549, turn left heading 270.
    [00:04] SPEAKER_00: This is Cactus 1539, head first to Placid Crest, I'm hoping it's returning back towards LaGuardia.
    [00:11] SPEAKER_01: Okay, you need to return to LaGuardia, turn left heading of 220.
    [00:14] SPEAKER_01: 220.
    [00:18] SPEAKER_01: Tower, stoppy to park, he's got emergency returning.
    [00:22] SPEAKER_01: Who is it?
    [00:23] SPEAKER_01: It's 1529, he, uh, bird strike, he lost all engine, he lost the thrust in the engine, so he's returning immediately.
    [00:28] SPEAKER_01: Check, it's 1529, which engines?
    [00:30] SPEAKER_01: He lost thrust in both engines, he said.
    [00:32] SPEAKER_01: Got it.
    [00:34] SPEAKER_01: Check, it's 1529, if we can get it for you, do you want to try to land 131.3?

    Passo a passo: endpoint assíncrono

    O endpoint assíncrono remove o limite de 60 segundos e é o caminho recomendado para áudios longos. A entrada e a saída são intermediadas pelo Amazon S3, e o cliente consulta o resultado após o envio.

    O fluxo funciona assim: o cliente faz upload do corpo multipart/form-data para o S3 e chama InvokeEndpointAsync com o InputLocation do objeto. Ele recebe imediatamente um OutputLocation e um FailureLocation — sem esperar pela transcrição. O SageMaker AI lê a entrada do S3, encaminha ao contêiner e executa o mesmo pipeline de detecção de voz, transcrição, alinhamento e diarização. Em caso de sucesso, o resultado é gravado no caminho de saída do S3; em caso de falha, um documento de erro vai para o caminho de falha. O cliente consulta o caminho de saída para obter o resultado.

    Criando a configuração do endpoint assíncrono

    A única diferença estrutural em relação ao endpoint em tempo real está na configuração: ela adiciona um AsyncInferenceConfig com S3OutputPath e S3FailurePath. Configure MaxConcurrentInvocationsPerInstance=1 para respeitar o limite de worker único do contêiner, e mantenha o mesmo pin de InferenceAmiVersion.

    # Same WhisperX DLC image as the real-time endpoint.
    IMAGE_URI = f"763104351884.dkr.ecr.{REGION}.amazonaws.com/whisperx:3.8.6-cu128-amzn2023-sagemaker"
    
    sm.create_model(
        ModelName=ASYNC_MODEL_NAME,
        PrimaryContainer={"Image": IMAGE_URI},  # WhisperX DLC
        ExecutionRoleArn=ROLE_ARN,
    )
    
    sm.create_endpoint_config(
        EndpointConfigName=ASYNC_ENDPOINT_CONFIG_NAME,
        ProductionVariants=[{
            "VariantName": "AllTraffic",
            "ModelName": ASYNC_MODEL_NAME,
            "InitialInstanceCount": 1,
            "InstanceType": "ml.g5.2xlarge",
            "InferenceAmiVersion": "al2-ami-sagemaker-inference-gpu-3-1",
            "ContainerStartupHealthCheckTimeoutInSeconds": 1200,
        }],
        AsyncInferenceConfig={
            "OutputConfig": {
                "S3OutputPath": f"s3://{BUCKET}/whisperx-async/output/",
                "S3FailurePath": f"s3://{BUCKET}/whisperx-async/failure/",
            },
            "ClientConfig": {"MaxConcurrentInvocationsPerInstance": 1},  # 1 request/container
        },
    )
    
    sm.create_endpoint(EndpointName=ASYNC_ENDPOINT_NAME, EndpointConfigName=ASYNC_ENDPOINT_CONFIG_NAME)
    sm.get_waiter("endpoint_in_service").wait(EndpointName=ASYNC_ENDPOINT_NAME)

    O restante do fluxo é idêntico ao endpoint em tempo real: o helper build_multipart e os campos de transcrição não mudam. A diferença é que você submete usando invoke_endpoint_async por referência ao S3, e depois lê a transcrição do OutputLocation. O processamento da gravação completa de aproximadamente 3 minutos retorna uma transcrição com rótulos de locutor do início ao fim do áudio.

    Limpeza de recursos

    Um endpoint GPU cobra continuamente até ser deletado. Ao terminar, delete o endpoint, a configuração e o modelo para ambos os endpoints, e remova os artefatos de entrada e saída do S3 que não forem mais necessários:

    # A GPU endpoint bills until deleted. Delete endpoint -> config -> model for each endpoint.
    for name, cfg, model in [
        (ENDPOINT_NAME, ENDPOINT_CONFIG_NAME, MODEL_NAME),
        (ASYNC_ENDPOINT_NAME, ASYNC_ENDPOINT_CONFIG_NAME, ASYNC_MODEL_NAME),
    ]:
        sm.delete_endpoint(EndpointName=name)
        sm.delete_endpoint_config(EndpointConfigName=cfg)
        sm.delete_model(ModelName=model)

    Boas práticas e considerações para produção

    • Fixe a AMI de GPU: sempre defina InferenceAmiVersion=al2-ami-sagemaker-inference-gpu-3-1 em variantes GPU. A AMI padrão tem drivers incompatíveis com esta imagem CUDA 12.8.
    • Escale por instâncias, não por concorrência: a inferência é serializada para uma requisição por contêiner. Defina MaxConcurrentInvocationsPerInstance=1 em endpoints assíncronos e adicione instâncias para aumentar o throughput.
    • Escale endpoints assíncronos a zero: para cargas em lote com picos, escale o endpoint assíncrono a zero instâncias quando ocioso para reduzir custos. Use notificações de conclusão via Amazon Simple Notification Service (Amazon SNS) em vez de polling agressivo.
    • Escolha a GPU certa e use pools de instâncias: use ml.g4dn.xlarge (T4) para custo ou ml.g5.2xlarge (A10G) para mais folga. Para evitar erros de capacidade insuficiente, liste até cinco tipos de instância em um pool do SageMaker AI — ele provisiona o tipo de maior prioridade e faz fallback automaticamente.
    • Proteja os artefatos no S3: ative o Block Public Access, criptografia padrão SSE-S3 ou SSE-KMS, e BucketOwnerEnforced no bucket assíncrono. Restrinja a função de execução a buckets e chaves específicos.
    • Trate dados pessoais com responsabilidade: transcrições de chamadas e reuniões podem conter dados sensíveis — criptografe os artefatos, restrinja o acesso e aplique redação downstream usando os timestamps por palavra.
    • Monitore e configure retentativas: use o Amazon CloudWatch para monitorar, configure alarmes para falhas e implemente retentativas para o comportamento de cold-start. Para visibilidade mais profunda de GPU e inferência, ative o painel de métricas detalhadas e Insights do SageMaker AI no CloudWatch.

    Conclusão

    A AWS publicou um guia completo sobre como fazer o deploy do DLC do WhisperX no SageMaker AI para transcrição com timestamps por palavra e identificação de locutor. A solução cobre dois padrões de endpoint — tempo real para clipes curtos e interativos, e assíncrono para áudios longos e alto volume — e detalha os pontos críticos de produção: o pin obrigatório da AMI de GPU, o escalonamento por instância única, a nomenclatura do bucket S3 e os controles de custo.

    Para explorar mais, consulte o guia de deploy do DLC do WhisperX, revise a documentação de inferência assíncrona do SageMaker AI e experimente o notebook de demonstração com seu próprio áudio. O exemplo completo e funcional está disponível no repositório AWS Samples no GitHub.

    Fonte

    Speaker-labeled transcription with WhisperX on SageMaker AI (https://aws.amazon.com/blogs/machine-learning/speaker-labeled-transcription-with-whisperx-on-sagemaker-ai/)

  • AWS Lambda Durable Functions agora disponíveis na Região Soberana Europeia da AWS

    Lambda Durable Functions chega à Nuvem Soberana Europeia

    A AWS anunciou que as Lambda Durable Functions já estão disponíveis na região AWS European Sovereign Cloud. Essa é uma boa notícia especialmente para equipes que precisam desenvolver aplicações complexas mantendo conformidade com regulamentações europeias de segurança e privacidade de dados.

    O que são as Lambda Durable Functions?

    As Lambda Durable Functions permitem que desenvolvedores construam aplicações multi-etapas confiáveis e fluxos de trabalho de Inteligência Artificial (IA) dentro da própria experiência do Lambda — sem precisar sair do modelo de programação já familiar ao serviço.

    Na prática, o recurso estende o modelo de programação do Lambda com novos primitivos disponíveis diretamente no handler de eventos. Entre eles, destacam-se:

    • step: permite dividir a execução em etapas com checkpoint de progresso
    • wait: permite pausar a execução sem gerar cobranças de compute para funções on-demand

    Com esses primitivos, as funções conseguem salvar o progresso automaticamente, se recuperar de falhas sem intervenção manual e aguardar eventos externos sem consumir recursos desnecessariamente.

    Casos de uso na Nuvem Soberana Europeia

    Com a chegada das Durable Functions à AWS European Sovereign Cloud, as equipes que operam nessa região passam a poder orquestrar processos mais complexos, como:

    • Fluxos de pedidos (order workflows)
    • Processos de onboarding de usuários
    • Tarefas assistidas por IA

    Tudo isso enquanto mantêm conformidade com os requisitos de segurança e regulatórios exigidos no contexto europeu — que é justamente o diferencial central da AWS European Sovereign Cloud.

    Linguagens e ferramentas suportadas

    Para ativar as Durable Functions em novas funções Lambda, a AWS oferece suporte às seguintes linguagens de programação:

    • Python: versões 3.13 e 3.14
    • Node.js: versões 22 e 24
    • Java: versão 17 ou superior

    A ativação pode ser feita por meio da AWS Lambda API, do AWS Management Console ou do AWS SDK. Também há suporte completo para ferramentas de Infraestrutura como Código (IaC), incluindo:

    • AWS CloudFormation
    • AWS Serverless Application Model (AWS SAM)
    • AWS Cloud Development Kit (AWS CDK)

    Saiba mais

    Para quem quiser se aprofundar no recurso, a AWS disponibiliza a página oficial das Lambda Durable Functions e o Guia do Desenvolvedor do AWS Lambda. Informações sobre preços estão disponíveis na página de preços do AWS Lambda.

    Fonte

    AWS Lambda durable functions are now available in AWS European Sovereign Cloud region (https://aws.amazon.com/about-aws/whats-new/2026/09/durablefunctions-european-sovereign-cloud/)

  • Amazon RDS para MySQL anuncia novas versões menores do Suporte Estendido: 5.7.44 e 8.0.46

    O que foi anunciado

    A AWS anunciou duas novas versões menores dentro do programa Amazon RDS Extended Support para o Amazon Serviço de Banco de Dados Relacional (RDS) para MySQL: a 5.7.44-rds.20260902 e a 8.0.46-rds.20260908. As atualizações foram disponibilizadas em 24 de setembro de 2026.

    O que é o Suporte Estendido do RDS

    O Amazon RDS Extended Support (Suporte Estendido) é um programa que oferece até três anos adicionais de correções para Vulnerabilidades e Exposições Comuns (CVE) críticas e bugs, contados a partir do fim do suporte padrão de uma versão principal do MySQL. Na prática, isso significa que equipes que ainda operam em versões mais antigas ganham uma janela de tempo maior para planejar e executar a migração para uma versão principal mais recente, sem ficarem expostas a riscos de segurança não corrigidos.

    Como fazer o upgrade do banco de dados

    A AWS disponibiliza três caminhos para quem precisa atualizar a versão do banco de dados:

    • Amazon RDS Blue/Green Deployments: estratégia que mantém dois ambientes paralelos (produção e staging) para validar a atualização antes de promovê-la, reduzindo o risco de indisponibilidade.
    • Upgrade in-place: atualização direta na instância existente, sem necessidade de criar um novo ambiente.
    • Restauração a partir de snapshot: criação de uma nova instância a partir de um backup, já na versão desejada.

    Mais detalhes sobre como executar cada um desses processos estão disponíveis no Guia do Usuário do Amazon RDS para MySQL.

    Migrando de fontes externas para o MySQL 8.4

    Para quem mantém bancos MySQL fora da AWS e deseja migrar para o MySQL 8.4 diretamente no RDS, a AWS indica o uso do AWS Database Migration Service (Serviço de Migração de Banco de Dados). Essa ferramenta permite transferir dados de fontes externas para o RDS com controle sobre o processo de migração.

    Disponibilidade e preços

    Informações sobre preços e disponibilidade regional do programa de Suporte Estendido podem ser consultadas diretamente na página de preços do Amazon RDS para MySQL. Para criar ou atualizar uma instância gerenciada, é possível usar o Console de Gerenciamento do Amazon RDS ou a Interface de Linha de Comando da AWS (AWS CLI).

    Por que isso importa

    Manter bancos de dados em versões sem suporte ativo é um dos maiores riscos operacionais em ambientes de produção. O programa de Suporte Estendido da AWS permite que times com ciclos de migração mais longos continuem recebendo correções de segurança críticas, evitando exposições desnecessárias enquanto o trabalho de atualização está em andamento. As novas versões menores anunciadas são parte desse compromisso contínuo de manutenção.

    Fonte

    Amazon RDS for MySQL announces Extended Support minor versions 5.7.44-rds.20260902 and 8.0.46-rds.20260908 (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-rds-mysql-extended-support-minor-5744-8046-rds/)

  • Como construir um agente de IA multi-conta com AgentCore Gateway e MCP

    O problema: agentes de IA que precisam enxergar além de uma única conta

    Empresas que operam em múltiplas contas AWS enfrentam um dilema clássico com agentes de IA: cada time mantém seus dados na própria conta por razões legítimas — isolamento de escopo, ciclos de deploy independentes e propriedade clara dos recursos. Mas um agente restrito a uma única conta entrega valor limitado. A alternativa tradicional de replicar ou centralizar dados cria problemas de governança, custo e conformidade.

    A AWS publicou uma arquitetura de referência que resolve esse impasse usando o Amazon Bedrock AgentCore Gateway em conjunto com o Model Context Protocol (MCP). A ideia central é simples: os dados ficam onde já estão, em cada conta de linha de negócio (LOB — Line of Business), e apenas o resultado específico de uma consulta trafega para a conta central no momento da requisição. Nenhum dataset sai da conta que o possui.

    Visão geral da arquitetura

    A solução segue um modelo de três camadas: uma conta de plataforma central, contas LOB distribuídas e o AgentCore Gateway como camada de integração entre elas.

    Conta de plataforma — o plano de controle do agente

    A conta de plataforma executa o agente no AgentCore Runtime, um ambiente serverless e agnóstico de framework com isolamento de sessão em microVMs dedicadas, precificação por consumo e autenticação integrada. A inferência do Modelo de Linguagem de Grande Escala (LLM — Large Language Model) roda nessa conta via Amazon Bedrock, e o time de plataforma controla os Modelos Fundamentais (FM — Foundation Models) disponíveis, aplica o Amazon Bedrock Guardrails e consolida custos em um único limite de faturamento.

    O AgentCore Gateway, também na conta de plataforma, funciona como o único endpoint MCP para o agente. Ele registra cada servidor MCP das contas LOB como um alvo e, a partir desse ponto único, oferece descoberta de ferramentas com busca semântica, autenticação centralizada via AgentCore Identity, autorização granular com Policy in AgentCore e observabilidade.

    Além de agregar servidores MCP, o Gateway suporta outros tipos de alvo. Os alvos HTTP permitem incluir agentes AgentCore Runtime, serviços agente-a-agente (A2A) e outros endpoints HTTP no mesmo ponto governado. O time de plataforma pode ainda aplicar o Amazon Bedrock Guardrails para segurança de conteúdo e configurar o Policy in AgentCore com Cedar para controle de acesso granular — tudo isso na camada do Gateway, fora do código do agente.

    Contas LOB — dados e ferramentas

    Em vez de expor recursos AWS brutos como buckets do Amazon Simple Storage Service (Amazon S3), bancos de dados ou Amazon Bedrock Knowledge Bases, cada time LOB empacota seus dados e ferramentas como um servidor MCP. O time de banco de varejo, por exemplo, expõe ferramentas como get_balance e get_profile. O time de crédito oferece get_credit_score e search_lending_policies, sendo que esta última executa Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation) sobre documentos PDF de políticas bancárias via Amazon Bedrock Knowledge Bases.

    Para novas implementações, é possível conectar um Amazon Bedrock Managed Knowledge Base diretamente ao Gateway como conector nativo, eliminando a necessidade de operar infraestrutura de recuperação própria.

    Cada servidor MCP roda no AgentCore Runtime da conta LOB, o que dá ao time completo controle sobre sua superfície de ferramentas: eles decidem o que expor e qual lógica de negócio roda por trás de cada ferramenta, podendo mudar a implementação sem afetar o agente da plataforma, desde que a interface MCP permaneça consistente.

    Integração entre contas: como Gateway e Identity conectam as camadas

    A arquitetura segue um padrão hub-and-spoke: cada LOB implanta um servidor MCP independente (o spoke) usando MCP sobre Streamable HTTP, enquanto o AgentCore Gateway (o hub) os agrega por trás de um único endpoint. Quando o agente invoca uma ferramenta, o Gateway recupera credenciais OAuth 2.0 máquina-a-máquina (M2M) do AgentCore Identity, as anexa à requisição de saída e a roteia para o servidor MCP LOB correto. Esse servidor valida o token contra o endpoint OpenID Connect (OIDC) do Okta antes de processar a requisição localmente. Os dados da fonte nunca são copiados ou relocados.

    Fluxo completo de uma requisição

    O fluxo a seguir ilustra como uma pergunta do usuário atravessa os limites de conta, invoca ferramentas distribuídas e retorna uma resposta unificada:

    • O usuário faz login via webapp React, que redireciona para o Okta para autenticação. O Okta valida as credenciais e retorna um Token Web JSON (JWT — JSON Web Token) com claims de identidade.
    • O usuário envia um prompt pelo webapp, que chega ao Amazon CloudFront via HTTPS. O CloudFront encaminha a requisição ao backend FastAPI rodando no Amazon Elastic Container Service (Amazon ECS) com AWS Fargate.
    • O backend aplica o Amazon Bedrock Guardrails para redação de Informações de Identificação Pessoal (PII — Personally Identifiable Information) na entrada do usuário e na saída do agente.
    • O backend invoca o Strands Agent no AgentCore Runtime, encaminhando o JWT do usuário no cabeçalho Authorization para propagação de identidade.
    • O agente envia o prompt ao Amazon Bedrock para raciocínio e determina quais ferramentas invocar.
    • O agente encaminha o JWT do usuário ao AgentCore Gateway, que usa busca semântica para descoberta de ferramentas entre os alvos LOB. O Policy in AgentCore (quando um motor de políticas está associado ao Gateway) avalia os claims do JWT contra regras Cedar e permite ou nega cada chamada de ferramenta por identidade, papel ou ação.
    • Para chamadas permitidas, o Gateway recupera credenciais OAuth 2.0 M2M do AgentCore Identity e encaminha a requisição ao servidor MCP LOB correto, que valida o token OAuth antes de processar.
    • O servidor MCP LOB executa a lógica da ferramenta: contra tabelas locais do Amazon DynamoDB para consultas de dados estruturados e, para o LOB de Crédito e Patrimônio, também realiza recuperação RAG contra o Amazon Bedrock Knowledge Bases sobre PDFs de políticas armazenados no Amazon S3.
    • Os resultados fluem de volta pela mesma cadeia (LOB → Gateway → Agente → Backend).

    Em produção, o time LOB configura allowedWorkloadConfiguration para restringir invocações do runtime apenas a requisições cuja cadeia de identidade inclua o Gateway, reduzindo o risco de acesso direto que contorne as políticas e a autorização Cedar.

    O Strands Agent descobre ferramentas LOB pelo método tools/list do Gateway e consulta o AWS Agent Registry (Preview) na inicialização para descobrir servidores MCP LOB registrados. Integrar um novo LOB é simples: basta adicionar um alvo ao Gateway — o agente descobre as novas ferramentas na próxima chamada tools/list.

    Implementação técnica

    Servidores MCP nas contas LOB

    Cada time LOB constrói um servidor MCP com FastMCP e o implanta no AgentCore Runtime usando a AgentCore CLI, expondo os dados como ferramentas estruturadas com entradas e saídas tipadas. Cada servidor é configurado com um customJWTAuthorizer que autentica tokens OAuth de entrada contra o endpoint de descoberta OIDC do Okta.

    O trecho abaixo mostra o servidor MCP do LOB de Crédito e Patrimônio, combinando consultas ao Amazon DynamoDB com recuperação via Amazon Bedrock Knowledge Bases:

    REGION = os.environ.get("AWS_REGION", "us-east-1")
    dynamodb = boto3.resource("dynamodb", region_name=REGION)
    bedrock_agent_runtime = boto3.client("bedrock-agent-runtime", region_name=REGION)
    KNOWLEDGE_BASE_ID = os.environ.get("KNOWLEDGE_BASE_ID", "")
    
    mcp = FastMCP("lending-wealth", host="0.0.0.0", stateless_http=True)
    
    @mcp.tool()
    def get_credit_score(customer_id: str) -> dict:
        """Get credit score and contributing factors for a customer."""
        table = dynamodb.Table("CreditScores")
        resp = table.get_item(Key={"customer_id": customer_id})
        item = resp.get("Item")
        if not item:
            return {"error": f"No credit score found for customer {customer_id}"}
        return item
    
    @mcp.tool()
    def search_lending_policies(query: str) -> str:
        """Search the bank's lending policy documents for guidelines, eligibility criteria, and regulatory requirements."""
        if not KNOWLEDGE_BASE_ID:
            return json.dumps({"error": "KNOWLEDGE_BASE_ID not configured"})
        resp = bedrock_agent_runtime.retrieve(
            knowledgeBaseId=KNOWLEDGE_BASE_ID,
            retrievalQuery={"text": query},
            retrievalConfiguration={"vectorSearchConfiguration": {"numberOfResults": 5}},
        )
        chunks = []
        for r in resp.get("retrievalResults", []):
            text = r.get("content", {}).get("text", "")
            source = r.get("location", {}).get("s3Location", {}).get("uri", "")
            if text:
                chunks.append({"text": text, "source": os.path.basename(source)})
        return json.dumps({"results": chunks}, default=str)
    
    if __name__ == "__main__":
        mcp.run(transport="streamable-http")

    Para implantar o servidor MCP no AgentCore Runtime via CLI:

    # Configure the MCP server
    agentcore configure \
      --entrypoint server.py \
      --name lending_wealth_mcp \
      --protocol MCP \
      --disable-memory \
      --non-interactive \
      --authorizer-config '{
        "customJWTAuthorizer": {
          "discoveryUrl": "<OKTA_DISCOVERY_URL>",
          "allowedAudience": ["lobfederation"]
        }
      }'
    
    # Deploy to AgentCore Runtime
    agentcore deploy --auto-update-on-conflict \
      --env KNOWLEDGE_BASE_ID=<your-knowledge-base-id>

    Configuração do AgentCore Gateway

    Na conta de plataforma, o Gateway é criado com um autorizador JWT customizado apontando para o endpoint de descoberta OIDC do Okta:

    ctrl.update_gateway(
        gatewayIdentifier=gateway_id,
        name="lobfederation-gateway",
        protocolType="MCP",
        protocolConfiguration={
            "mcp": {
                "searchType": "SEMANTIC",
                "supportedVersions": ["2025-03-26"],
            }
        },
        authorizerType="CUSTOM_JWT",
        authorizerConfiguration={
            "customJWTAuthorizer": {
                "discoveryUrl": "https://<your-okta-domain>/oauth2/<auth-server-id>/.well-known/openid-configuration",
                "allowedAudience": ["lobfederation"],
            }
        },
    )

    Para autenticação de saída aos servidores MCP LOB, o Gateway usa o fluxo de credenciais de cliente OAuth 2.0 (M2M). O time de plataforma registra um provedor de credenciais OAuth no AgentCore Identity e o associa a cada alvo do Gateway:

    # Register an OAuth credential provider (M2M / client_credentials)
    resp = ctrl.create_oauth2_credential_provider(
        name="lobfederation-okta-m2m",
        credentialProviderVendor="CustomOauth2",
        oauth2ProviderConfigInput={
            "customOauth2ProviderConfig": {
                "oauthDiscovery": {
                    "discoveryUrl": "https://<your-okta-domain>/oauth2/<auth-server-id>/.well-known/openid-configuration"
                },
                "clientId": "<M2M_CLIENT_ID>",
                "clientSecret": "<M2M_CLIENT_SECRET>",
                "clientAuthenticationMethod": "CLIENT_SECRET_BASIC",
            }
        },
    )
    cred_arn = resp["credentialProviderArn"]
    
    # Create a Gateway target for the LOB MCP server with OAuth outbound auth
    ctrl.create_gateway_target(
        gatewayIdentifier=gateway_id,
        name="lending-wealth",
        description="Lending & Wealth --- loans, credit scores, eligibility, policy search",
        targetConfiguration={
            "mcp": {
                "mcpServer": {
                    "endpoint": f"https://bedrock-agentcore.{REGION}.amazonaws.com/runtimes/{encoded_runtime_arn}/invocations",
                }
            }
        },
        credentialProviderConfigurations=[
            {
                "credentialProviderType": "OAUTH",
                "credentialProvider": {
                    "oauthCredentialProvider": {
                        "providerArn": cred_arn,
                        "scopes": ["lobfederation.invoke"],
                        "grantType": "CLIENT_CREDENTIALS",
                    }
                },
            }
        ],
    )

    Quando uma ferramenta LOB precisa aplicar controle de acesso por usuário (como segurança em nível de linha), o AgentCore Identity também oferece a troca de token on-behalf-of (OBO), onde o Gateway troca o token do usuário de entrada por um token com escopo downstream que carrega a identidade tanto do agente quanto do usuário. O AgentCore Gateway também suporta o fluxo de código de autorização e chaves de API — veja os exemplos de autenticação de saída do AgentCore Gateway.

    Implantação do agente

    O agente Strands é implantado no AgentCore Runtime com um autorizador JWT customizado para autenticação de entrada. Em tempo de execução, o agente lê o JWT do usuário nos cabeçalhos da requisição de entrada e o passa ao AgentCore Gateway, propagando a identidade do usuário final até o motor de políticas Cedar:

    @app.entrypoint
    def invoke(payload, context=None):
        prompt = payload.get("prompt", "Hello")
        # Read the user's JWT from inbound request headers (passed through by Runtime)
        request_headers = context.request_headers if context else {}
        user_jwt = request_headers.get("Authorization", "")
    
        # Connect to Gateway with the user's JWT --- Cedar evaluates per-user policies
        mcp_client = MCPClient(
            lambda: streamablehttp_client(
                url=GATEWAY_URL,
                headers={"Authorization": user_jwt},
            )
        )
        with mcp_client:
            tools = mcp_client.list_tools_sync()
            agent = Agent(model=MODEL_ID, system_prompt=SYSTEM_PROMPT, tools=tools)
            result = agent(prompt)

    Operação do agente: avaliação, versionamento e observabilidade

    Avaliação contínua

    Em uma arquitetura multi-conta onde o agente orquestra ferramentas de vários LOBs, é essencial garantir que ele continue funcionando corretamente conforme ferramentas, modelos e prompts evoluem. O AgentCore Evaluations oferece um framework gerenciado para detectar regressões antes que cheguem aos usuários.

    A avaliação online pontua continuamente uma amostra do tráfego de produção (por exemplo, 10% das sessões) usando avaliadores integrados como Acurácia de Seleção de Ferramentas, Corretude e Taxa de Sucesso de Objetivos. As pontuações aparecem no dashboard do AgentCore Observability, alimentado pelo Amazon CloudWatch, com alertas quando a qualidade cai — sem necessidade de alterações no código se o agente já emite traces OpenTelemetry. Isso permite detectar degradações silenciosas que o monitoramento de latência e taxa de erros não captura.

    A avaliação sob demanda é uma API em tempo real para desenvolvimento e Integração e Entrega Contínua (CI/CD). O time define um dataset de avaliação uma vez e o AgentCore Evaluations o reproduz a cada mudança. Para fechar o ciclo, o AgentCore Optimization analisa traces de produção e recomenda melhorias de prompt e descrição de ferramentas.

    Versionamento seguro e testes A/B

    O agente é implantado com endpoints (prod, staging, dev) que apontam para versões específicas. Quando o time de plataforma atualiza o prompt ou o modelo, publica uma nova versão e atualiza o endpoint — os servidores MCP LOB não são afetados porque a interface de ferramentas não muda. Antes de promover uma mudança, o time pode executar testes A/B pelo AgentCore Gateway, dividindo o tráfego entre a versão atual e a candidata.

    Segurança, governança e gestão de custos

    Acesso com privilégio mínimo e aprovação dos donos de dados

    Os times LOB controlam quem pode invocar seus servidores MCP via configuração do autorizador JWT no deployment do AgentCore Runtime. Uma requisição da conta de plataforma só chega às ferramentas LOB após o time ter configurado o servidor para aceitar tokens do provedor de identidade da plataforma — aprovação independente do time de plataforma.

    Autorização com Policy in AgentCore

    O Gateway executa o Policy in AgentCore em modo ENFORCE, avaliando regras antes de rotear cada chamada de ferramenta. O Policy in AgentCore usa a linguagem Cedar, com regras explícitas de permit e forbid. Por exemplo:

    // Permit all authenticated users to invoke read-only tools
    permit(
      principal is AgentCore::OAuthUser,
      action in [
        AgentCore::Action::"retail-banking___get_customer",
        AgentCore::Action::"retail-banking___get_accounts",
        AgentCore::Action::"retail-banking___get_balance",
        AgentCore::Action::"tools/list",
        AgentCore::Action::"initialize"
      ],
      resource
    );
    
    // Block destructive operations regardless of user
    forbid(
      principal,
      action == AgentCore::Action::"retail-banking___delete_customer",
      resource
    );

    Como o Policy in AgentCore usa um modelo de negação por padrão, apenas ações com um permit explícito são executadas.

    Conectividade de rede e VPC

    A implementação de referência usa o modo de rede pública padrão do AgentCore Runtime, com tráfego via HTTPS com OAuth — adequado para desenvolvimento, mas não para produção. Em produção, o AgentCore Runtime suporta conectividade de Nuvem Privada Virtual (VPC — Virtual Private Cloud) via Interfaces de Rede Elástica (ENIs), endpoint VPC de interface via AWS PrivateLink para ingresso privado ao Gateway e allowedWorkloadConfiguration para restringir invocações ao Gateway. Veja os padrões de conectividade de rede para o AgentCore Runtime e o ingresso seguro ao AgentCore Gateway usando endpoints VPC de interface.

    Guardrails

    O Amazon Bedrock Guardrails é aplicado na conta de plataforma para filtragem de conteúdo, redação de PII e restrições de tópicos. Como a inferência é centralizada, uma única configuração de guardrail cobre as interações do agente com todas as ferramentas LOB. Também é possível aplicar Guardrails como políticas diretamente no AgentCore Gateway, executando verificações na camada do Gateway, fora do código do agente.

    Auditoria e conformidade

    Para habilitar o logging do plano de dados, configure a entrega de logs no Gateway para o Amazon CloudWatch Logs, que captura invocações de ferramentas e metadados de requisição. O AWS CloudTrail captura operações do plano de controle por padrão. Para auditoria centralizada, configure um trail no nível da organização que agrega logs das contas de plataforma e LOB em uma conta de logging dedicada.

    Atribuição de custos

    A arquitetura oferece fronteiras naturais de custo. Os custos do plano de dados de cada LOB (Amazon DynamoDB, Amazon Bedrock Knowledge Bases, computação do servidor MCP) ficam na própria conta e aparecem diretamente no AWS Cost Explorer. Inferência LLM e invocações do Gateway acumulam na conta de plataforma. Para atribuí-los de volta ao LOB de origem, a role de execução do agente carrega tags (como lob ou costCenter). Após ativar a tag de alocação de custos no console de faturamento, essas tags fluem para o AWS Cost and Usage Report para chargeback por LOB. Para uma abordagem mais detalhada, veja atribuição granular de custos para o Amazon Bedrock.

    Como experimentar

    Para testar o padrão, clone o repositório de referência e execute o script de implantação, que inicializa o AWS Cloud Development Kit (AWS CDK) nas quatro contas, provisiona os recursos de plataforma e LOB, implanta os servidores MCP e alvos do Gateway, e lança uma aplicação web React no Amazon ECS atrás do CloudFront.

    Os pré-requisitos incluem: configuração multi-conta gerenciada via AWS Organizations, acesso a modelos do Amazon Bedrock na conta de plataforma, AgentCore configurado nas contas de plataforma e LOB, um provedor de identidade compatível com OIDC (como Okta, Amazon Cognito ou Microsoft Entra ID) e as fontes de dados LOB que os servidores MCP irão encapsular.

    Para evitar cobranças após o teste, execute o script de limpeza incluído no repositório. Ele remove os recursos implantados nas quatro contas — componentes AgentCore, configuração Okta, deployments de servidores MCP e stacks CDK — em ordem inversa à implantação.

    Recursos relacionados

    Fonte

    Build a multi-account AI agent with AgentCore Gateway and MCP (https://aws.amazon.com/blogs/machine-learning/build-a-multi-account-ai-agent-with-agentcore-gateway-and-mcp/)