Author: Make.com Service User

AWS lança versão 1.0 da CLI do Amazon Bedrock AgentCore

A AWS anunciou a disponibilidade geral da versão 1.0 da Interface de Linha de Comando (CLI) do Amazon Bedrock AgentCore, publicada no registro npm como @aws/agentcore 1.0.0. Esta versão foi reconstruída do zero com foco em desempenho, consistência e suporte mais amplo aos recursos da plataforma.

O que é a CLI do AgentCore?

A CLI do AgentCore é a ferramenta que permite aos desenvolvedores criar, desenvolver, implantar e operar agentes de Inteligência Artificial (IA) e os recursos de suporte associados diretamente pelo terminal. Em vez de depender exclusivamente do console web da AWS, o desenvolvedor ganha agilidade e controle total pelo fluxo de trabalho em linha de comando.

Principais novidades da versão 1.0

A versão 1.0 traz melhorias significativas em relação às versões anteriores. Entre os destaques estão:

• Inicialização mais rápida: a CLI responde com mais agilidade, melhorando a experiência no dia a dia de desenvolvimento.
• Estrutura de comandos consistente: os comandos seguem um padrão uniforme, com flags globais que funcionam da mesma forma em todos os contextos — incluindo seleção de região, saída em formato JSON (JavaScript Object Notation), modo de depuração e exibição de informações de versão.
• Acesso direto a recursos sem projeto: agora é possível trabalhar diretamente com harnesses, runtimes, memória, identidade, gateways e pagamentos sem a necessidade de associá-los previamente a um projeto.
• Invocação por ID ou ARN (Amazon Resource Name): recursos existentes podem ser invocados diretamente pelo seu identificador ou pelo ARN.
• Shell interativo: o desenvolvedor pode abrir um shell interativo para explorar e operar recursos em tempo real.
• Exportação de harness: é possível exportar um harness diretamente pela CLI.
• Menus pesquisáveis e seletores de recursos: a navegação ficou mais intuitiva com menus pesquisáveis, seletores de recursos e fluxos de trabalho guiados.

Migração de projetos existentes

Quem já utiliza projetos em versões anteriores pode migrar para o AgentCore versão 1 usando o comando agentcore migrate. A AWS disponibilizou esse caminho de migração para garantir que times com projetos em andamento não fiquem para trás na atualização.

Como começar

A CLI do AgentCore versão 1.0 pode ser instalada diretamente pelo npm, ou o código-fonte pode ser explorado no GitHub. Para mais informações, a AWS disponibiliza a página do produto Amazon Bedrock AgentCore, a referência completa da CLI do AgentCore e o guia de primeiros passos com o Amazon Bedrock AgentCore.

Fonte

Amazon Bedrock AgentCore CLI version 1.0 is now available (https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-bedrock-agentcore-cli-version-1-0-available/)

O verdadeiro gargalo não é o modelo — é tudo ao redor dele

Quem já tentou colocar um agente de Inteligência Artificial (IA) em produção sabe que o modelo em si raramente é o problema. O que trava o avanço é a infraestrutura ao redor: como garantir que múltiplas equipes trabalhem em um ambiente seguro, quem é responsável por cada modelo e ferramenta, como manter o controle de custos entre contas e como lidar com erros sem quebrar as fronteiras de cada time.

Para endereçar exatamente esse cenário, a AWS publicou uma arquitetura de referência detalhada para a construção de uma plataforma de IA agêntica empresarial usando o Amazon Bedrock e o Amazon Bedrock AgentCore. O post original descreve o modelo operacional multi-conta, o plano de controle da plataforma, um padrão de implantação repetível por equipe, gateways separados para inferência e ferramentas, e um pipeline de avaliação que controla a promoção de cada agente para produção.

O que é o Amazon Bedrock AgentCore

O Amazon Bedrock AgentCore oferece serviços modulares para construir, implantar e operar agentes em escala. Isso inclui runtime, gateway, identidade, memória, políticas, registro e avaliações. Por cima dessa base, o Enterprise Agentic AI Platform Blueprint adiciona os contratos empresariais como infraestrutura implantável: limites de conta, entrega de software, observabilidade, governança de custos e ciclo de vida completo dos agentes.

Princípios arquiteturais: cinco desafios comuns

A AWS identificou cinco categorias de desafios que aparecem repetidamente em clientes que tentam estabelecer uma plataforma de agentes:

• Acesso governado a modelos: toda requisição de inferência não confiável deve passar por um gateway aprovado. Esse gateway aplica as guardrails da organização (como o Amazon Bedrock Guardrails), restringe quais modelos e regiões cada equipe pode usar, e impõe limites de taxa, cotas de tokens e orçamentos por equipe.
• Acesso governado a ferramentas: os agentes devem descobrir e invocar apenas ferramentas aprovadas por meio de um gateway autenticado usando o Protocolo de Contexto de Modelo (MCP — Model Context Protocol), com funções de execução de menor privilégio e rastreabilidade.
• Entrega delegada: as equipes de produto precisam implantar e reverter mudanças de forma independente, dentro de limites pré-aprovados, sem depender da equipe de plataforma para cada deploy.
• Operações de frota e custos: diferentes perfis precisam de visibilidade entre contas sem ter acesso de escrita. Engenheiros de operações precisam de logs, métricas e traces. Donos de fluxos precisam ver custo por agente. Times de Operações Financeiras (FinOps) precisam de estorno por equipe via AWS Cost Explorer e pelo Relatório de Custo e Uso da AWS (CUR).
• Evidências e ciclo de vida: cada versão de agente precisa de comprovação em cada fronteira que toca — acesso a modelos, acesso a ferramentas, identidade, capacidade de reversão e desativação completa sem deixar resíduos.

Modelos operacionais: centralizado, descentralizado ou federado

A AWS descreve três modelos que as empresas costumam adotar para IA agêntica. No modelo centralizado, uma única equipe de IA e Aprendizado de Máquina (IA/AM) constrói e opera todos os agentes — a governança é consistente, mas essa equipe rapidamente vira um gargalo. No modelo descentralizado, cada unidade de negócio cuida dos seus próprios agentes, o que garante agilidade, mas gera drift nos controles, duplicação de esforço e perda de visibilidade de custos.

O blueprint implementa o modelo federado: uma equipe central de plataforma fornece serviços compartilhados e governados, enquanto as equipes de domínio mantêm a propriedade de seus agentes, ferramentas e dados. Para saber mais sobre como escolher o modelo adequado, a AWS disponibiliza a página de Modelos de Governança no AWS Prescriptive Guidance.

Os dois planos principais da arquitetura

Plano de controle da plataforma

A conta de plataforma publica templates versionados e interfaces, opera o Registro de Agentes da AWS e os Gateways de Inferência compartilhados, admite modelos e guardrails, orquestra releases revisados e agrega sinais de toda a frota. As equipes consomem essas capacidades por meio de código, descritores e pipelines — não por sessões de administrador ou tickets de deploy.

Célula de Workstream repetível

Cada produto ou domínio recebe uma fronteira isolada com um repositório de código próprio, um pipeline de carga de trabalho e três capacidades do Amazon Bedrock AgentCore: Runtime, Memória com escopo por ator e um Gateway que usa autorização AWS_IAM e expõe apenas os alvos de ferramentas aprovados. A célula também inclui chaves do Serviço de Gerenciamento de Chaves da AWS (AWS KMS — AWS Key Management Service) gerenciadas pelo cliente, tags, alarmes, orçamentos e um link de origem do Gerenciador de Acesso de Observabilidade (OAM — Observability Access Manager) do Amazon CloudWatch.

O ponto central dessa arquitetura é que uma célula pode ser implantada, falhar, ser revertida ou desativada sem coordenar com outra equipe. A unidade de escala é a célula de Workstream, não um agente configurado manualmente ou uma conta de carga de trabalho compartilhada.

Topologia de contas e camadas da solução

O blueprint define funções lógicas de conta que separam a governança empresarial, os serviços compartilhados de plataforma e a execução por equipe:

• Fundação de gerenciamento: AWS Organizations, AWS IAM Identity Center, políticas preventivas, auditoria, retenção e políticas de custo.
• Segurança e arquivo de logs: AWS CloudTrail, AWS Config, AWS Security Hub, Amazon GuardDuty e dados de auditoria retidos.
• Observabilidade: sink do CloudWatch OAM com logs, métricas, traces e visões de custo centralizados.
• Camada de plataforma de IA agêntica: caminhos dourados, catálogo de governança, guardrails, Gateways de Inferência compartilhados, aliases exatos de ferramentas, pipelines e interfaces operacionais comuns.
• Frota de Workstreams: cada produto, domínio ou fronteira regulada recebe uma ou mais células de não-produção e produção.

Essa topologia se integra a uma landing zone existente, onde os rótulos de Gerenciamento, Plataforma e Workstream descrevem responsabilidades, não uma estrutura fixa de três contas.

Políticas de controle de serviço e separação de responsabilidades

As Políticas de Controle de Serviço (SCPs — Service Control Policies) restringem as permissões máximas disponíveis para as contas de plataforma e Workstream. Elas complementam — mas não substituem — o Gerenciamento de Identidade e Acesso (IAM), as autorizações de gateway, as guardrails, as políticas de recursos e os controles de rede.

Alguns pontos-chave das SCPs no blueprint:

• Admissão de modelos e regiões: políticas da organização e funções de execução do gateway restringem a inferência a modelos aprovados e à região suportada.
• Aplicação de guardrails: os agentes não chamam provedores de modelos diretamente — toda inferência passa pelo gateway governado.
• Mutação exclusiva via pipeline: implantações diretas de desenvolvedores em contas de Workstream estão fora do modelo suportado.
• Governança de registro e gateway: a síntese do Gateway de Workstream falha quando um registro subscrito está ausente, alterado ou não aprovado.

Pipeline de Integração e Entrega Contínua (CI/CD) com portões de avaliação

O blueprint usa pipelines revisados de plataforma e de carga de trabalho para impor a seguinte sequência de promoção:

• Fonte e revisão: um pull request estabelece a revisão de fonte imutável.
• Build e síntese: o pipeline compila código, executa testes, cria o manifesto do agente, escaneia imagens, valida políticas e inspeciona a saída do AWS CloudFormation.
• Funções estáveis e transferência de permissões: o pipeline de carga de trabalho cria funções estáveis de Workstream e pausa. O pipeline de plataforma concede aliases exatos de ferramentas à função de Gateway correta — e só então o pipeline de carga de trabalho continua.
• Deploy em não-produção: o pipeline implanta Runtime, Memória, Gateway de Ferramentas, observabilidade, alarmes, orçamentos, tags e recursos de aplicação na fronteira de não-produção da célula.
• Avaliação do agente implantado: o portão invoca o Runtime real e mede regressão, qualidade, sucesso de ferramentas, comportamento de recusa, latência do primeiro token e custo. Cada chamada autorizada é pareada com um teste adversarial: o portão chama um modelo aprovado e confirma sucesso, depois chama um modelo não aprovado e confirma a negação. Se uma negação esperada estiver ausente, o portão reprova o build.
• Aprovação humana: um revisor examina as evidências implantadas, limitações conhecidas e riscos residuais.
• Promoção, observação e reversão: a promoção para produção usa a revisão aprovada e verificações de continuidade. O pipeline prova tanto o caminho de avanço quanto o de recuperação.

A desativação segue uma ordem estrita de dependências: as concessões de alias de plataforma são revogadas primeiro, depois o Gateway e as funções de ferramentas do Workstream, e por fim o Runtime, a Memória e os recursos de aplicação. Cada etapa é verificada antes de prosseguir, e um inventário final confirma que nenhum recurso residual permanece.

Segurança e governança em profundidade

O blueprint implementa defesa em profundidade por meio de controles de identidade, políticas, entrega, dados e evidências:

• Identidade e fronteiras de confiança: o AgentCore Identity e o Amazon Cognito fornecem credenciais de inferência de curta duração. AWS_IAM e SigV4 autenticam o tráfego de ferramentas.
• Segurança e admissão de modelos: a inferência flui pelo gateway governado, aplicando guardrails e listas de modelos permitidos antes de cada chamada.
• Autorização de ferramentas: o Gateway de Ferramentas invoca apenas aliases aprovados pelo registro. Políticas Cedar fornecem autorização, com um wrapper AWS Lambda para defesa em profundidade.
• Proteção de dados por tenant: as contas de Workstream isolam o estado da aplicação. A memória do AgentCore usa namespaces com escopo por ator e chaves KMS gerenciadas pelo cliente.
• Cadeia de suprimentos de software e release: fonte revisada, hashing de manifesto, builds reproduzíveis, escaneamento de imagem, validação de políticas, avaliação de runtime implantado, aprovação humana, reversão e teardown ordenado por dependência formam um único contrato de release.
• Auditoria, observabilidade e governança de custos: o CloudTrail e os dados de plano de controle retidos corroboram as evidências do pipeline. O OAM compartilha logs, métricas e traces com operadores centrais. Tags de alocação padrão, orçamentos, cotas e reconciliação do Relatório de Custo e Uso atribuem propriedade sem dar ao agente permissão de reescrever sua própria atribuição.

Frameworks suportados e experiência do desenvolvedor

Na escala empresarial, o plano de experiência do desenvolvedor é um catálogo de templates de agentes versionados e aprovados pela organização. O blueprint inclui templates de referência para Strands, LangGraph e CrewAI — mas qualquer framework pode ser usado, desde que o template preserve os contratos de gateway de inferência, gateway de ferramentas, identidade, política, avaliação e entrega.

As equipes de aplicação são donas dos prompts, da lógica dos agentes, das ferramentas e dos casos de avaliação. A equipe de plataforma é dona dos controles comuns e dos requisitos de release.

Como começar

A recomendação da AWS é clara: implante uma célula de Workstream representativa a partir do repositório do blueprint, prove seu ciclo de vida completo — onboarding, promoção para produção, reversão, observabilidade centralizada e desativação sem resíduos — e depois automatize células adicionais a partir da mesma base versionada.

O deployment e os recursos disponíveis são baseados na região eu-west-1 (Irlanda). Qualquer componente substituído, outra região ou um rollout organizacional mais amplo requer suas próprias evidências de disponibilidade, segurança, carga, reversão, observabilidade e teardown.

Recursos relacionados

• Enterprise Agentic AI Platform Blueprint no GitHub
• Arquitetura multi-conta para IA agêntica em produção na AWS (Prescriptive Guidance)
• Workshop: Construindo uma Plataforma de IA Agêntica Empresarial no Amazon Bedrock AgentCore
• Documentação do Amazon Bedrock AgentCore

Fonte

Building an Agentic AI Platform on Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/building-an-agentic-ai-platform-on-amazon-bedrock-agentcore/)

O problema que o SOCI resolve

Quem trabalha com treinamento de modelos no Amazon SageMaker AI conhece bem aquele tempo perdido antes do job sequer começar a processar dados. Antes de executar qualquer linha de código, o serviço precisa baixar a imagem de container armazenada no Amazon Elastic Container Registry (Amazon ECR), descomprimindo e gravando cada camada no disco da instância.

Para imagens pequenas, isso leva alguns segundos. O problema é que imagens de deep learning modernas facilmente ultrapassam 10 GB. Resultado: vários minutos de espera a cada job — e esse tempo é cobrado normalmente, sem gerar nenhum progresso no modelo. O impacto é ainda mais crítico em cenários de alta iteração, como varreduras de hiperparâmetros com centenas de jobs ou experimentos rápidos, onde o download da imagem pode dominar o tempo total de execução.

Como o SOCI funciona

O Seekable OCI (SOCI) é uma tecnologia open source que implementa o conceito de lazy loading (carregamento sob demanda) para imagens de container. Em vez de baixar tudo antes de iniciar, o runtime usa um índice SOCI para buscar apenas os arquivos necessários para subir o container imediatamente. O restante é transmitido em segundo plano conforme o código vai acessando os dados.

Um índice SOCI é basicamente um mapa de todos os arquivos dentro da imagem. Ele é armazenado no Amazon ECR como um artefato compatível com o padrão OCI (Open Container Initiative), vinculado à imagem original. Como o índice é um artefato separado, o digest da imagem e eventuais assinaturas existentes continuam válidos.

Como o SageMaker AI usa o índice

Quando um job de treinamento ou processamento é criado, o SageMaker AI verifica automaticamente se a imagem especificada possui um índice SOCI e age de acordo:

• Imagem com índice SOCI: o SageMaker AI faz o lazy loading e inicia o container antes de concluir o download completo.
• Imagem sem índice SOCI: comportamento padrão, sem alteração.
• Índice ilegível ou falha no lazy loading: o job faz fallback para o download padrão e continua executando normalmente.

Esse mecanismo de fallback garante que adicionar um índice SOCI nunca interrompa um workflow existente. O pior cenário é simplesmente não ter a melhoria de velocidade.

O que foi medido

A AWS realizou benchmarks comparando o download padrão com o lazy loading via SOCI em jobs reais de treinamento no SageMaker AI. Foram utilizadas oito imagens com tamanhos entre 1,8 GB e 35,4 GB comprimidos, em instâncias GPU e CPU das famílias ml.g4dn, ml.g5, ml.g6, ml.g6e, ml.g7, ml.g7e, ml.p4d, ml.p5 e ml.m7i, nas regiões US West (Oregon) e US East (N. Virginia).

Resultado 1: tempo de download cai de minutos para segundos em todos os tamanhos

O download padrão cresce proporcionalmente ao tamanho da imagem, pois cada arquivo precisa ser descomprimido e gravado. Com lazy loading, o tempo ficou entre 3 e 11 segundos independentemente do tamanho — uma melhoria de 8x a 46x. Quanto maior a imagem, mais minutos são economizados por job.

Tamanho da imagem (comprimida)	Download padrão	Lazy loading	Melhoria
1,8 GB	48 s	3–11 s	~8x
13,2 GB	3 min 42 s	~6 s	~34x
35,4 GB	7 min 17 s	3–11 s	~38x

Resultado 2: a melhoria se mantém em todos os tipos e tamanhos de instância

Testando a imagem de 13,2 GB em 13 combinações de tipo e tamanho de instância, o download padrão variou entre 3 min 16 s e 4 min 20 s, enquanto o lazy loading se manteve entre 6 e 8 segundos — cerca de 34x mais rápido em todas as configurações. Não é necessário mudar o tipo de instância para se beneficiar.

Resultado 3: performance de treinamento não é afetada (além de uma penalidade na primeira época)

A AWS também executou jobs de treinamento completos para comparar a performance época a época. Os workloads testados foram:

• Classificação de imagens com ResNet-50 no dataset Imagenette (9.469 imagens), usando containers PyTorch (13,2 GB) e TensorFlow (9,9 GB), em instâncias ml.p5.48xlarge, ml.p4d.24xlarge, ml.g7e.48xlarge, ml.g7.48xlarge, ml.g6e.12xlarge, ml.g6e.24xlarge e ml.g6e.48xlarge.
• Fine-tuning de modelo de linguagem (LLM): ajuste fino supervisionado completo do Qwen2.5-0.5B no dataset alpaca-cleaned (51.760 exemplos) com o Hugging Face Trainer, usando container PyTorch da Hugging Face (9,4 GB), em instâncias ml.p5.48xlarge, ml.p4d.24xlarge e ml.g6.48xlarge.

A partir da segunda época, o tempo por época é idêntico entre os dois métodos em todas as instâncias e workloads. A primeira época leva entre 3 e 16 segundos a mais com a imagem lazy-loaded, enquanto os arquivos acessados pelo framework pela primeira vez são buscados. Esse custo inicial é fixo e independente do tamanho da instância. O resultado líquido: cada job terminou entre 1 e 6 minutos mais cedo — que é a economia no download menos o custo único da primeira época.

Vale considerar que o lazy loading traz maior ganho quando a primeira etapa de treinamento precisa de apenas uma fração da imagem — o restante é transmitido enquanto o treinamento avança. Se o entry point lê a maior parte da imagem antes de começar (por exemplo, fazendo scan, checksum ou pré-carregamento de conteúdo), a melhoria líquida será menor. Mesmo em cenários mais “pesados” no início — como uso de torch.compile ou extensões CUDA compiladas em tempo real, que adicionaram 7 a 15 segundos à primeira época —, o ganho líquido ainda foi de 3 min 25 s a 3 min 56 s. Um modelo de 6 GB embutido na imagem adicionou 2 a 3,5 minutos à primeira época, mas o job ainda terminou 2 a 2,5 minutos antes.

Como adotar o SOCI indexing

Há duas formas de usar imagens com índice SOCI no SageMaker AI.

Opção 1: usar um AWS Deep Learning Container já indexado

A AWS publica variantes com índice SOCI de vários Deep Learning Containers (DLCs) populares, identificadas pelo sufixo -soci na tag da imagem. Exemplo:

763104351884.dkr.ecr.us-east-1.amazonaws.com/pytorch-training:2.9-gpu-py312-cu130-ubuntu22.04-sagemaker-v1-soci

Variantes pré-indexadas estão disponíveis para PyTorch Training, TensorFlow Training, vLLM e SGLang, incluindo variantes arm64 para alguns frameworks. Para adotar, basta atualizar a tag da imagem na definição do job para a variante -soci. Consulte a lista completa na AWS Deep Learning Containers Gallery.

Atenção: se você constrói sua própria imagem a partir de uma DLC base, é necessário criar um índice SOCI para a imagem final. O índice da imagem base não é herdado por imagens derivadas.

Opção 2: criar um índice SOCI para sua própria imagem

Para indexar uma imagem customizada, é necessário um host Linux (como uma instância Amazon EC2 com Amazon Linux 2023) com containerd, o SOCI snapshotter e o Finch ou nerdctl instalados.

Defina as variáveis de ambiente:

ACCOUNT_ID="111122223333"
REGION="us-east-1"
REPOSITORY_NAME="my-training-image"
ORIGINAL_IMAGE_TAG="v1.0"
SOCI_IMAGE_TAG="v1.0-soci"
REGISTRY="$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com"

Instale as ferramentas necessárias:

sudo dnf install -y containerd fuse soci-snapshotter runfinch-finch
sudo systemctl start soci-snapshotter
sudo systemctl restart containerd

Autentique-se no Amazon ECR:

aws ecr get-login-password --region "$REGION" \
  | sudo nerdctl login -u AWS --password-stdin "$REGISTRY"

Faça o pull da imagem original:

sudo nerdctl pull "$REGISTRY/$REPOSITORY_NAME:$ORIGINAL_IMAGE_TAG"

Crie a imagem com índice SOCI:

sudo nerdctl image convert --soci \
  "$REGISTRY/$REPOSITORY_NAME:$ORIGINAL_IMAGE_TAG" \
  "$REGISTRY/$REPOSITORY_NAME:$SOCI_IMAGE_TAG"

Faça o push da imagem indexada:

sudo nerdctl push --platform linux/amd64 \
  "$REGISTRY/$REPOSITORY_NAME:$SOCI_IMAGE_TAG"

Esse processo cria dois artefatos no repositório: o índice SOCI e um manifesto de índice OCI vinculando a imagem ao índice. A imagem original e seu digest permanecem inalterados.

Automatizando a criação de índices no pipeline de CI/CD

Para gerar índices automaticamente a cada push, é possível implantar o CFN ECR SOCI Index Builder. Ele usa uma regra do Amazon EventBridge para detectar eventos de push no Amazon ECR e construir o índice automaticamente, sem necessidade de alterações no pipeline de build.

Usando a imagem indexada no job do SageMaker AI

A imagem com índice SOCI é referenciada exatamente como qualquer outra imagem — nenhuma mudança na API é necessária. Apenas a tag difere. Exemplo com o SageMaker Python SDK:

from sagemaker.train import ModelTrainer
from sagemaker.train.configs import Compute

trainer = ModelTrainer(
    training_image="111122223333.dkr.ecr.us-east-1.amazonaws.com/my-training-image:v1.0-soci",
    role="arn:aws:iam::111122223333:role/SageMakerExecutionRole",
    compute=Compute(
        instance_type="ml.g5.12xlarge",
        instance_count=2,
    ),
)
trainer.train()

Verificando se a imagem possui índice SOCI

Antes de executar o job, é possível confirmar se a tag aponta para uma imagem indexada:

aws ecr batch-get-image \
  --repository-name "$REPOSITORY_NAME" \
  --image-ids imageTag="$SOCI_IMAGE_TAG" \
  --accepted-media-types \
    "application/vnd.oci.image.index.v1+json" \
  --query 'images[0].imageManifest' --output text \
  | jq '.manifests[] | {mediaType, artifactType}'

Procure por um manifesto filho cujo artifactType comece com application/vnd.amazon.soci.index. ao lado do manifesto de plataforma. Se não estiver presente, a tag não aponta para uma imagem indexada.

Pontos de atenção

• Somente repositórios privados do Amazon ECR. Imagens em outros registries ou acessadas via Docker registry privado (TrainingRepositoryAccessMode definido como Vpc) não são elegíveis para lazy loading.
• A melhoria escala com o tamanho da imagem. Imagens menores que aproximadamente 4 GB têm ganhos relativamente pequenos.
• Verifique dependências específicas do Docker. Imagens com índice SOCI rodam em um runtime baseado em containerd. Revise entry points e scripts de setup que chamam o Docker CLI, leem /var/run/docker.sock ou derivam identificadores de caminhos de cgroup. O SageMaker AI monta um marcador /.dockerenv para compatibilidade retroativa, mas evite criar novas dependências nele.
• Disponibilidade global. O SOCI indexing para jobs do SageMaker AI está disponível em todas as regiões AWS.

Conclusão

Com o suporte a índices SOCI, o Amazon SageMaker AI passa a oferecer uma forma direta de eliminar o overhead de download de imagens de container em jobs de treinamento e processamento. A adoção é simples — basta apontar para um DLC pré-indexado ou criar o índice para a própria imagem — e não exige nenhuma mudança nas definições de job, chamadas de API ou pipelines de dados existentes. O resultado é um início de job em segundos em vez de minutos, menor custo total e ciclos de iteração de machine learning (ML) mais rápidos.

Para aprofundar o tema, a AWS disponibiliza recursos adicionais: a Deep Learning Containers Gallery com a lista de imagens pré-indexadas, o guia de orientações específicas por framework em SOCI index for AWS Deep Learning Containers, o passo a passo no SageMaker AI Developer Guide, o guia de introdução ao SOCI snapshotter para opções avançadas, o CFN ECR SOCI Index Builder para automação no CI/CD, o walkthrough de lazy loading com Finch para testes locais, e os posts técnicos Reducing container cold start times using SOCI index on DLAMI and DLC e Under the hood: Lazy loading container images with Seekable OCI and AWS Fargate para quem quiser entender o mecanismo em profundidade.

Fonte

Announcing SOCI-indexed images for faster SageMaker AI jobs (https://aws.amazon.com/blogs/machine-learning/announcing-soci-indexed-images-for-faster-sagemaker-ai-jobs/)

O que mudou no ElastiCache for Valkey

A AWS anunciou uma atualização importante no Amazon ElastiCache for Valkey: agora é possível habilitar ou desabilitar a durabilidade em clusters baseados em nós já existentes, sem a necessidade de criar um novo cluster do zero.

Antes dessa mudança, a configuração de durabilidade era definida no momento da criação do cluster e não podia ser alterada depois. Isso criava uma barreira real para equipes que precisavam migrar um workload de cache simples para um armazenamento persistente de dados — ou simplesmente adaptar o comportamento do cluster conforme as necessidades da aplicação evoluíam. Agora, essa flexibilidade está disponível em qualquer ponto do ciclo de vida da aplicação.

As duas opções de durabilidade disponíveis

O ElastiCache for Valkey oferece duas modalidades de escrita, cada uma com características e trade-offs distintos:

• Escritas síncronas: os dados são persistidos em pelo menos duas Zonas de Disponibilidade (AZs) antes de o serviço responder ao cliente. Essa opção é projetada para cenários de zero perda de dados, com latência de escrita na casa de milissegundos de um único dígito.
• Escritas assíncronas: o serviço responde ao cliente primeiro e persiste os dados em seguida, mantendo latência de escrita em microssegundos sem custo adicional. A contrapartida é que, em um evento raro de falha, até 10 segundos de dados não confirmados podem ser perdidos.

Vale destacar que ambas as opções mantêm latência de leitura em microssegundos, independentemente da escolha de durabilidade.

Casos de uso além do cache tradicional

Com essa nova capacidade, o ElastiCache for Valkey se torna uma opção viável para um conjunto mais amplo de aplicações — especialmente aquelas em que a perda de dados é inaceitável. A AWS destaca alguns exemplos relevantes:

• Memória de longo prazo para agentes de IA
• Gerenciamento de estado de fluxos de trabalho de agentes de IA
• Bases de conhecimento para aplicações de RAG (Geração Aumentada por Recuperação)
• Tokenização de pagamentos
• Gerenciamento de inventário em tempo real

Disponibilidade e como começar

O recurso está disponível em todas as regiões da AWS onde o ElastiCache for Valkey 9.0 ou versões posteriores estão disponíveis. Para utilizá-lo, é possível acessar pelo Console de Gerenciamento da AWS, pelo SDK da AWS ou pela Interface de Linha de Comando (CLI) da AWS.

Para detalhes sobre preços, consulte a página de preços do Amazon ElastiCache. Para aprofundar o entendimento técnico sobre o tema, a documentação oficial traz uma seção dedicada sobre Durabilidade no ElastiCache.

Fonte

Amazon ElastiCache for Valkey now supports changing durability on existing clusters (https://aws.amazon.com/about-aws/whats-new/2026/10/elasticache-changing-durability/)

Nova versão disponível no SageMaker MLflow Apps

A AWS anunciou que o Amazon SageMaker AI MLflow Apps passou a oferecer suporte ao MLflow 3.16, a versão mais recente da popular plataforma de rastreamento e gerenciamento de experimentos de aprendizado de máquina (ML). A atualização chega com melhorias relevantes tanto para quem trabalha com modelos tradicionais de ML quanto para quem desenvolve aplicações de Inteligência Artificial (IA) generativa e agentes.

O que muda com o MLflow 3.16

Experiência de rastreamento redesenhada

Uma das principais novidades desta versão é a reformulação completa da experiência de rastreamento. O explorador de rastreamentos — ferramenta central para depuração e análise de aplicações de IA generativa e agentes — foi redesenhado e agora é a visualização padrão. Entre as melhorias práticas, estão:

• Altura de linhas ajustável, facilitando a leitura de rastreamentos mais densos;
• Colunas reordenáveis, permitindo organizar a visualização conforme a necessidade;
• Suporte a colunas personalizadas criadas a partir de qualquer tag de rastreamento ou campo de metadados.

Essas mudanças tornam o processo de depuração e análise de fluxos de IA generativa mais visual e eficiente no dia a dia.

Gráficos de métricas mais rápidos

O MLflow 3.16 também traz ganhos de desempenho para quem lida com experimentos de grande escala. Os gráficos de métricas agora são renderizados com mais velocidade, especialmente em experimentos que acumularam um histórico extenso de métricas — um cenário comum em treinamentos longos ou em pipelines com muitas iterações.

Como funciona a atualização

Novas instâncias do MLflow Apps criadas a partir de agora já utilizam o MLflow 3.16 por padrão. Para quem já possui aplicações existentes, a AWS informou que a atualização será realizada automaticamente durante uma janela de manutenção programada, sem necessidade de nenhuma ação por parte do usuário.

Disponibilidade

O MLflow 3.16 está disponível em todas as regiões da AWS onde o MLflow Apps já estava disponível. Para explorar os detalhes técnicos e começar a usar os novos recursos, a AWS disponibiliza o guia do desenvolvedor do SageMaker AI MLflow.

Fonte

SageMaker MLflow Apps now support MLflow 3.16 (https://aws.amazon.com/about-aws/whats-new/2026/10/mflow-version-3-16/)

O que foi anunciado

A AWS anunciou que o Amazon Elastic Container Service (Amazon ECS) agora oferece suporte ao compartilhamento de GPU por meio do NVIDIA Multi-Process Service (MPS). Com esse recurso, é possível executar múltiplas tarefas do Amazon ECS simultaneamente em uma única GPU da NVIDIA.

Por que isso importa

Muitas cargas de trabalho de IA e computação intensiva não utilizam 100% da capacidade de uma GPU — e é exatamente aí que o compartilhamento de GPU faz diferença. Em vez de reservar uma GPU inteira para cada tarefa, agora é possível empacotar mais workloads em cada instância, aumentando a utilização da GPU e reduzindo os custos de infraestrutura.

A AWS cita como casos de uso típicos para esse modelo:

• Inferência de modelos pequenos
• Simulações de veículos autônomos e sistemas avançados de assistência ao motorista (AV/ADAS)
• Geração de embeddings
• Serviço de múltiplos modelos simultaneamente (multi-model serving)

Como funciona na prática

O ponto mais relevante para quem opera workloads no ECS é que não é necessário alterar o código da aplicação. A configuração é feita diretamente na definição da tarefa: você especifica quanto de memória de GPU cada contêiner precisa e, opcionalmente, define um limite máximo de uso de computação da GPU. A partir daí, o Amazon ECS cuida do posicionamento das tarefas nas GPUs com capacidade disponível conforme os serviços escalam e são implantados.

Suporte e resiliência

O compartilhamento de GPU está disponível tanto nas Amazon ECS Managed Instances quanto no Amazon ECS on Amazon EC2. Nas ECS Managed Instances, a AWS vai além: o serviço monitora ativamente o daemon de controle do MPS em cada instância — o componente responsável por habilitar o compartilhamento. Se esse daemon parar ou ficar com problemas, o Amazon ECS substitui automaticamente a instância e migra as tarefas para capacidade saudável, sem necessidade de intervenção manual.

Como começar

Para habilitar o recurso, a AWS disponibiliza os caminhos tradicionais de configuração: Console de Gerenciamento da AWS, AWS CLI, AWS SDKs, AWS CloudFormation ou outras ferramentas de infraestrutura como código. O fluxo básico envolve:

• Criar um capacity provider com instâncias de GPU da NVIDIA
• Definir a estratégia de compartilhamento de GPU e a memória na definição de contêiner da task definition
• Criar um serviço nesse capacity provider

O recurso está disponível em todas as regiões comerciais da AWS e na AWS GovCloud (EUA). Para detalhes técnicos completos, a AWS disponibiliza a documentação oficial de compartilhamento de GPU no Amazon ECS.

Fonte

Amazon ECS now supports GPU sharing with NVIDIA Multi-Process Service (MPS) (https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-ecs-gpu-sharing-nvidia-mps/)