Blog

Infraestrutura de IA com múltiplas demandas simultâneas

Ambientes modernos de inteligência artificial executam várias tarefas em paralelo no mesmo cluster: pré-treinamento de modelos foundation (FM), ajuste fino (fine-tuning), inferência em produção e avaliação. Nesse contexto compartilhado, a demanda por aceleradores de IA oscila continuamente — cargas de trabalho de inferência crescem conforme padrões de tráfego, e experimentos terminam liberando recursos.

Apesar dessa disponibilidade dinâmica de aceleradores, os trabalhos de treinamento tradicionais permanecem presos à sua alocação computacional inicial, incapazes de aproveitar capacidade ociosa sem intervenção manual. O SageMaker HyperPod agora suporta treinamento elástico, permitindo que cargas de trabalho de aprendizado de máquina dimensionem automaticamente conforme a disponibilidade de recursos. Essa abordagem maximiza utilização de GPU, reduz custos e acelera desenvolvimento de modelos através da adaptação dinâmica de recursos, mantendo qualidade de treinamento e minimizando intervenção manual.

O problema da alocação estática de recursos

Considere um cluster de 256 GPUs executando simultaneamente treinamento e inferência. Durante as horas de menor tráfego à noite, a inferência pode liberar 96 GPUs. Essas 96 GPUs ficam ociosas e disponíveis para acelerar o treinamento. Porém, trabalhos de treinamento tradicionais rodam em escala fixa — um trabalho que começa com 32 GPUs fica preso a essa configuração inicial, enquanto 96 GPUs adicionais permanecem ociosas. Isso representa 2.304 horas GPU desperdiçadas por dia, traduzindo-se em milhares de dólares gastos diariamente em infraestrutura subutilizada.

O problema se intensifica conforme o cluster cresce. Dimensionar treinamento distribuído dinamicamente é tecnicamente complexo. Mesmo com infraestrutura que suporta elasticidade, é necessário pausar trabalhos, reconfigurar recursos, ajustar paralelização e redistribuir checkpoints. Essa complexidade piora pela necessidade de manter progresso de treinamento e acurácia do modelo através dessas transições. Apesar de suporte subjacente do SageMaker HyperPod com Amazon EKS e frameworks como PyTorch e NeMo, intervenção manual ainda consome horas de tempo de engenharia.

A necessidade de ajustar repetidamente execuções de treinamento conforme disponibilidade de aceleradores distrai equipes de seu trabalho real: desenvolvimento de modelos. Compartilhamento de recursos e preempção de cargas de trabalho adicionam outra camada de complexidade. Sistemas atuais carecem de capacidade para lidar graciosamente com requisições parciais de recursos de cargas de trabalho prioritárias. Imagine um cenário onde um trabalho crítico de ajuste fino necessita 8 GPUs em um cluster onde uma carga de pré-treinamento ocupa todas as 32 GPUs. Sistemas atuais forçam escolha binária: ou parar o trabalho inteiro de pré-treinamento, ou negar recursos à carga prioritária, ainda que 24 GPUs fossem suficientes para pré-treinamento em escala reduzida. Essa limitação leva organizações a superdimensionar infraestrutura evitando contenção de recursos, resultando em filas maiores de trabalhos pendentes, custos elevados e eficiência de cluster reduzida.

Solução: treinamento elástico automático

A AWS oferece através do SageMaker HyperPod uma solução: treinamento elástico. Cargas de trabalho de treinamento agora dimensionam automaticamente para utilizar aceleradores disponíveis e se contraem graciosamente quando recursos são necessários em outro lugar, tudo mantendo qualidade de treinamento. O SageMaker HyperPod gerencia a orquestração complexa de gerenciamento de checkpoint, reatribuição de classificações e coordenação de processos, minimizando intervenção manual e ajudando equipes focar em desenvolvimento de modelos.

O operador de treinamento do SageMaker HyperPod integra-se com o plano de controle do Kubernetes (K8s) e agendador de recursos para tomar decisões de dimensionamento. Monitora eventos de ciclo de vida de pod, disponibilidade de nó e sinais de prioridade do agendador, detectando oportunidades de dimensionamento quase instantaneamente, tanto de recursos recém-disponíveis quanto de novas requisições de cargas prioritárias. Antes de iniciar qualquer transição, o operador avalia ações de dimensionamento potenciais contra políticas configuradas (limites mínimos e máximos de nó, limites de frequência de dimensionamento).

Como funciona o dimensionamento elástico

Treinamento elástico adiciona ou remove réplicas paralelas de dados mantendo tamanho global de lote constante. Quando recursos ficam disponíveis, novas réplicas se integram e aceleram throughput sem afetar convergência. Quando carga prioritária necessita recursos, o sistema remove réplicas em vez de matar o trabalho inteiro. Treinamento continua em capacidade reduzida.

Quando evento de dimensionamento ocorre, o operador transmite sinal de sincronização para todas as classificações (ranks). Cada processo conclui passo atual e salva estado usando Checkpoint Distribuído do PyTorch (DCP — Distributed Checkpoint). Conforme novas réplicas se integram ou existentes saem, o operador recalcula atribuições de classificação e inicia reinicializações de processos através do trabalho de treinamento. DCP então carrega e redistribui dados de checkpoint para corresponder à nova contagem de réplica, garantindo que cada worker tenha estado correto de modelo e otimizador. Treinamento retoma com réplicas ajustadas, e tamanho global de lote constante garante convergência não afetada.

Para clusters usando Kueue (incluindo SageMaker HyperPod task governance), treinamento elástico implementa gerenciamento inteligente de carga de trabalho através de múltiplas requisições de admissão. O operador primeiro requisita recursos mínimos necessários com prioridade alta, depois incrementalmente requisita capacidade adicional com prioridade mais baixa. Essa abordagem habilita preempção parcial: quando cargas prioritárias necessitam recursos, apenas réplicas de prioridade mais baixa são revogadas, permitindo treinamento continuar na linha de base garantida em vez de terminar completamente.

Começando com treinamento elástico

Pré-requisitos

Antes de integrar treinamento elástico em sua carga de trabalho de treinamento, certifique-se que seu ambiente atende aos seguintes requisitos:

• Cluster SageMaker HyperPod orquestrado por Amazon EKS com Kubernetes v1.32 ou superior
• HyperPod training operator v1.2 ou superior instalado no cluster
• SageMaker HyperPod task governance v1.3.1 ou superior para enfileiramento, priorização e agendamento de trabalhos

Configurar isolamento de namespace e controles de recurso

Se usar escalonamento automático de cluster (como Karpenter), configure ResourceQuotas no nível de namespace. Sem elas, requisições de recurso do treinamento elástico podem disparar provisionamento ilimitado de nó. ResourceQuotas limitam máximo de recursos que trabalhos podem requisitar mantendo ainda comportamento elástico dentro de limites definidos.

Exemplo de ResourceQuota para namespace limitado a 8 instâncias ml.p5.48xlarge (cada instância possui 8 GPUs NVIDIA H100, 192 vCPUs e 640 GiB memória, totalizando 64 GPUs, 1.536 vCPUs e 5.120 GiB memória):

apiVersion: v1
kind: ResourceQuota
metadata:
  name: training-quota
  namespace: team-ml
spec:
  hard:
    nvidia.com/gpu: "64"
    vpc.amazonaws.com/efa: "256"
    requests.cpu: "1536"
    requests.memory: "5120Gi"
    limits.cpu: "1536"
    limits.memory: "5120Gi"

Recomenda-se organizar cargas de trabalho em namespaces separados por time ou projeto, com AWS Identity and Access Management (IAM) mapeamentos de controle de acesso baseado em papéis (RBAC) suportando controle de acesso apropriado e isolamento de recursos.

Construir container de treinamento HyperPod

O operador de treinamento HyperPod usa launcher customizado do PyTorch do pacote Python HyperPod Elastic Agent para detectar eventos de dimensionamento, coordenar operações de checkpoint e gerenciar processo de rendezvous quando world size muda. Instale o agente elástico, depois substitua torchrun por hyperpodrun em seu comando de inicialização. Veja HyperPod elastic agent para mais detalhes.

Exemplo de configuração de container de treinamento:

FROM 
RUN pip install hyperpod-elastic-agent
ENTRYPOINT ["entrypoint.sh"]
# entrypoint.sh
hyperpodrun --nnodes=node_count --nproc-per-node=proc_count \
--rdzv-backend hyperpod

Habilitar dimensionamento elástico no código de treinamento

Complete os seguintes passos para habilitar dimensionamento elástico em seu código de treinamento:

1. Adicione importação do agente elástico HyperPod ao script de treinamento:

from hyperpod_elastic_agent.elastic_event_handler import elastic_event_detected

2. Modifique seu loop de treinamento para verificar eventos elásticos após cada lote:

def train_epoch(model, dataloader, optimizer, args):
    for batch_idx, batch_data in enumerate(dataloader):
        # Forward and backward pass
        loss = model(batch_data).loss
        loss.backward()
        optimizer.step()
        optimizer.zero_grad()
        
        # Check if we should checkpoint (periodic or scaling event)
        should_checkpoint = (batch_idx + 1) % args.checkpoint_freq == 0
        elastic_event = elastic_event_detected()
        
        # Save checkpoint if scaling-up or scaling down job
        if should_checkpoint or elastic_event:
            save_checkpoint(model, optimizer, scheduler, checkpoint_dir=args.checkpoint_dir, step=global_step)
        
        if elastic_event:
            print("Elastic scaling event detected. Checkpoint saved.")
            return

3. Implemente funções de salvar e carregar checkpoint usando PyTorch DCP:

import torch.distributed.checkpoint as dcp
from torch.distributed.checkpoint.state_dict import get_state_dict, set_state_dict

def save_checkpoint(model, optimizer, lr_scheduler, user_content, checkpoint_path):
    """Save checkpoint using DCP for elastic training."""
    state_dict = {
        "model": model,
        "optimizer": optimizer,
        "lr_scheduler": lr_scheduler,
        **user_content
    }
    dcp.save(
        state_dict=state_dict,
        storage_writer=dcp.FileSystemWriter(checkpoint_path)
    )

def load_checkpoint(model, optimizer, lr_scheduler, checkpoint_path):
    """Load checkpoint using DCP with automatic resharding."""
    state_dict = {
        "model": model,
        "optimizer": optimizer,
        "lr_scheduler": lr_scheduler
    }
    dcp.load(
        state_dict=state_dict,
        storage_reader=dcp.FileSystemReader(checkpoint_path)
    )
    return model, optimizer, lr_scheduler

Para cenários de treinamento de época única onde cada amostra deve ser vista exatamente uma vez, é necessário persistir estado do dataloader através de eventos de dimensionamento. Sem isso, quando seu trabalho retoma com world size diferente, amostras processadas previamente podem ser repetidas ou puladas, afetando qualidade de treinamento.

Submeter trabalho de treinamento elástico

Com container de treinamento construído e código instrumentado, você está pronto submeter trabalho de treinamento elástico. Especificação de trabalho define como sua carga de trabalho dimensiona respondendo à disponibilidade de recursos de cluster através da configuração elasticPolicy.

Crie especificação HyperPodPyTorchJob definindo seu comportamento de dimensionamento elástico:

apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
  name: elastic-training-job
spec:
  elasticPolicy:
    minReplicas: 2
    maxReplicas: 8
    replicaIncrementStep: 2
    gracefulShutdownTimeoutInSeconds: 600
    scalingTimeoutInSeconds: 60
    faultyScaleDownTimeoutInSeconds: 30
  replicaSpecs:
    - name: worker
      replicas: 2
      maxReplicas: 8
      template:
        spec:
          containers:
            - name: pytorch
              image: 
              command: ["hyperpodrun"]
              args:
                - "--nnodes=2"
                - "--nproc-per-node=8"
                - "--rdzv-backend=hyperpod"
                - "train.py"
              resources:
                requests:
                  nvidia.com/gpu: 8
                  vpc.amazonaws.com/efa: 32
                limits:
                  nvidia.com/gpu: 8
                  vpc.amazonaws.com/efa: 32

Configuração elasticPolicy controla como seu trabalho de treinamento responde a mudanças de recurso:

• minReplicas e maxReplicas: Definem limites de dimensionamento. Seu trabalho manterá sempre pelo menos minReplicas e nunca excederá maxReplicas, mantendo uso de recurso previsível.
• replicaIncrementStep vs. replicaDiscreteValues: Escolha uma abordagem para granularidade de dimensionamento. Use replicaIncrementStep para dimensionamento uniforme. Use replicaDiscreteValues: [2, 4, 8] para especificar configurações exatas permitidas.
• gracefulShutdownTimeoutInSeconds: Oferece tempo para processo de treinamento completar checkpoint antes de forçado encerramento. Configure baseado em tamanho de checkpoint e desempenho de armazenamento.
• scalingTimeoutInSeconds: Introduz atraso de estabilização antes de scale-up prevenindo flutuações quando recursos oscilam rapidamente.
• faultyScaleDownTimeoutInSeconds: Quando pods falham ou travam, operador aguarda essa duração para recuperação antes de dimensionar. Previne scale-downs desnecessários por falhas transitórias.

Treinamento elástico incorpora mecanismos anti-thrashing para manter estabilidade em ambientes com disponibilidade de recurso flutuando rapidamente. Essas proteções incluem períodos mínimos de estabilidade reforçados entre eventos de dimensionamento e estratégia exponencial de backoff para transições frequentes.

Submeta o trabalho usando kubectl ou SageMaker HyperPod CLI:

kubectl apply -f elastic-job.yaml

Usar receitas SageMaker HyperPod

A AWS criou SageMaker HyperPod recipes para treinamento elástico de modelos foundation publicamente disponíveis, incluindo Llama e GPT-OSS. Essas receitas fornecem configurações pré-validadas tratando estratégia de paralelização, ajustes de hiperparâmetro e gerenciamento de checkpoint automaticamente, requerendo apenas mudanças de configuração YAML sem modificações de código.

Times simplesmente especificam limites mínimos e máximos de nó em sua especificação de trabalho, e sistema gerencia toda coordenação de dimensionamento conforme recursos de cluster flutuam:

python launcher.py \
  recipes=llama/llama3_1_8b_sft \
  recipes.elastic_policy.is_elastic=true \
  recipes.elastic_policy.min_nodes=2 \
  recipes.elastic_policy.max_nodes=8

Receitas também suportam configurações específicas por escala através do campo scale_config, permitindo definir diferentes hiperparâmetros (tamanho de lote, taxa de aprendizado) para cada world size. Veja SageMaker HyperPod Recipes repository para exemplos detalhados.

Resultados de desempenho

Para demonstrar impacto de treinamento elástico, ajuste fino de modelo Llama-3 70B foi realizado no dataset TAT-QA usando cluster SageMaker HyperPod com até 8 instâncias ml.p5.48xlarge. Esse benchmark ilustra como treinamento elástico executa na prática quando dimensionando dinamicamente respondendo à disponibilidade de recursos, simulando ambiente realista onde treinamento e cargas de inferência compartilham capacidade de cluster.

Avaliação cobriu duas dimensões chave: throughput de treinamento e convergência de modelo durante transições de dimensionamento. Melhoria consistente em throughput em diferentes configurações de dimensionamento de 1 a 8 nós foi observada. Desempenho de treinamento melhorou de 2.000 tokens/segundo em 1 nó para até 14.000 tokens/segundo em 8 nós.

Durante toda execução de treinamento, loss continuou diminuindo conforme treinamento de modelo continuou convergindo:

Integração com capacidades do SageMaker HyperPod

Além suas capacidades essenciais de dimensionamento, treinamento elástico aproveita integração com capacidades de infraestrutura do SageMaker HyperPod. Task governance policies automaticamente disparam eventos de dimensionamento quando prioridades de carga de trabalho mudam, habilitando treinamento ceder recursos a cargas prioritárias de inferência ou avaliação. Suporte para SageMaker Training Plans permite treinamento dimensionar oportunisticamente usando tipos de capacidade otimizados por custos mantendo resiliência através de scale-down automático quando instâncias spot são reclamadas. A observability add-on do SageMaker HyperPod complementa essas capacidades fornecendo insights detalhados em eventos de dimensionamento, desempenho de checkpoint e progressão de treinamento, ajudando times monitorar e otimizar suas deployments de treinamento elástico.

Conclusão

Treinamento elástico no SageMaker HyperPod endereça problema de recursos desperdiçados em clusters de IA. Trabalhos de treinamento agora dimensionam automaticamente conforme recursos ficam disponíveis sem requerer ajustes manuais de infraestrutura. Arquitetura técnica de treinamento elástico mantém qualidade de treinamento através de transições de dimensionamento. Preservando tamanho global de lote e taxa de aprendizado através de diferentes configurações paralelas de dados, sistema mantém propriedades de convergência consistentes independentemente de escala atual.

Três benefícios primários são esperados: primeiro, perspectiva operacional, redução de ciclos de reconfiguração manual fundamentalmente muda como times de aprendizado de máquina trabalham. Engenheiros podem focar em inovação e desenvolvimento de modelos em vez de gerenciamento de infraestrutura, melhorando significativamente produtividade de time e reduzindo overhead operacional. Segundo, eficiência de infraestrutura vê melhorias dramáticas conforme cargas de trabalho de treinamento dinamicamente consomem capacidade disponível, levando a reduções substanciais em horas GPU ociosas e correspondentes economias de custo. Terceiro, time-to-market acelera consideravelmente conforme trabalhos de treinamento automaticamente dimensionam utilizando recursos disponíveis, habilitando desenvolvimento e deployment de modelo mais rápido.

Para começar, consulte a documentation guide. Implementações de amostra e receitas estão disponíveis no e GitHub repository.

Fonte

Adaptive infrastructure for foundation model training with elastic training on SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/adaptive-infrastructure-for-foundation-model-training-with-elastic-training-on-sagemaker-hyperpod/)

O Desafio da Segurança Distribuída em Arquiteturas AWS

Aplicações web modernas construídas na AWS frequentemente combinam múltiplos serviços para oferecer soluções escaláveis e performáticas. Porém, essa arquitetura distribuída apresenta um desafio significativo: implementar uma estratégia coerente de segurança em camada de transporte entre todos esses componentes.

O principal obstáculo é que diferentes serviços AWS exigem abordagens distintas para configuração de HTTP Strict Transport Security (HSTS). Quando uma aplicação utiliza API Gateway para APIs, CloudFront para distribuição de conteúdo e Application Load Balancers para tráfego web, a ausência de políticas HSTS unificadas resulta em postura de segurança inconsistente. Ferramentas de auditoria de segurança frequentemente identificam headers HSTS faltantes, mas as orientações para remediar o problema estão dispersas em documentações específicas de cada serviço, criando lacunas de conformidade.

Entendendo HSTS e Seus Benefícios de Segurança

HTTP Strict Transport Security é um mecanismo de política de segurança web que protege websites contra ataques de rebaixamento de protocolo e roubo de cookies. Quando um servidor web declara política HSTS através do header Strict-Transport-Security, navegadores compatíveis convertem automaticamente solicitações HTTP para HTTPS para o domínio especificado.

Por Que HSTS Importa Além de Redirecionamentos HTTP→HTTPS

A maioria dos servidores web já implementa redirecionamento de HTTP para HTTPS. Porém, essa abordagem deixa uma janela de vulnerabilidade durante a primeira solicitação do navegador:

• Usuário digita exemplo.com.br no navegador
• Navegador envia requisição HTTP para http://exemplo.com.br
• Servidor responde com redirecionamento 301/302 para https://exemplo.com.br
• Navegador segue o redirecionamento e estabelece conexão HTTPS

A solicitação HTTP inicial (etapa 2) cria uma oportunidade para ataques. Uma parte não autorizada posicionada entre o usuário e a infraestrutura pode interceptar essa requisição e responder com conteúdo aparentemente legítimo mantendo uma conexão não segura. Essa técnica, conhecida como SSL stripping, pode ocorrer mesmo quando sua infraestrutura AWS está corretamente configurada com redirecionamentos HTTPS.

HSTS resolve essa vulnerabilidade movendo a imposição de segurança para o nível do navegador. Após receber uma política HSTS, o navegador converte automaticamente requisições HTTP para HTTPS antes de enviá-las pela rede:

• Usuário digita exemplo.com.br no navegador
• Navegador converte automaticamente para HTTPS graças à política HSTS armazenada
• Navegador envia requisição HTTPS diretamente para https://exemplo.com.br
• Nenhuma requisição HTTP inicial elimina a oportunidade de interceptação

Essa imposição no nível do navegador fornece proteção que complementa as configurações de segurança da infraestrutura AWS, criando defesa em profundidade contra problemas de rebaixamento de protocolo. HSTS também ajuda a prevenir acesso não autorizado a sessões, protegendo contra roubo de credenciais.

Casos de Uso Principais para HSTS

HSTS protege cenários que redirecionamentos HTTP simples não cobrem. Por exemplo, quando sistemas legados servem conteúdo misto, ou quando fluxos de SSO redirecionam usuários entre provedores, HSTS mantém as conexões criptografadas ao longo de todo o processo.

Em arquiteturas de microsserviços usando API Gateway com comunicação entre serviços, HSTS protege endpoints de API contra rebaixamento de protocolo durante conexões iniciais de clientes. Aplicações com CloudFront e múltiplos servidores de origem também se beneficiam, pois HSTS previne que navegadores façam fallback para HTTP durante cenários de failover.

Configurando HSTS no Amazon API Gateway

O Amazon API Gateway oferece múltiplas formas para adicionar headers HSTS em respostas de API.

HTTP APIs com Parameter Mapping

Para HTTP APIs, é possível configurar mapeamento de parâmetros de resposta para definir headers HSTS quando invocado via endpoint padrão ou domínio customizado:

1. Navegue até a configuração de rota da sua HTTP API no console do API Gateway
2. Acesse as configurações de integração na aba “Manage integrations”
3. Na seção de Response, insira 200 como código de status
4. Selecione “Append” como tipo de modificação
5. Em “Parameter to modify”, digite header.Strict-Transport-Security
6. Em Value, insira max-age=31536000; includeSubDomains; preload

REST APIs com Proxy e Non-Proxy Integration

REST APIs no API Gateway oferecem controle mais granular sobre implementação de HSTS através de padrões de integração proxy e non-proxy.

Para integrações proxy (como AWS Lambda), o serviço backend assume responsabilidade por gerar headers HSTS. Exemplo com Lambda:

import json

def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'headers': {
            'Strict-Transport-Security': 'max-age=31536000; includeSubDomains; preload'
        },
        'body': json.dumps('Resposta segura com headers HSTS')
    }

Para integrações non-proxy, os headers HSTS devem ser retornados pelo API Gateway através de templates de mapeamento ou resposta de método. Usando templates de mapeamento com Velocity Template Language (VTL), é possível configurar geração dinâmica de headers:

$input.json("$")
#set($newValue = "$input.params().header.get('Host')")
#set($context.responseOverride.header.Strict-Transport-Security = "max-age=31536000; includeSubDomains; preload")

Alternativamente, a aba “Method response” oferece configuração declarativa mapeando explicitamente o header strict-transport-security, seguido da aba “Integration response” onde você mapeia o valor como max-age=31536000; includeSubDomains; preload.

Para validar a implementação, utilize:

curl -i https://seu-api-gateway-url.execute-api.regiao.amazonaws.com/stage/recurso

A resposta esperada deve incluir:

strict-transport-security: max-age=31536000; includeSubDomains; preload

Implementando HSTS com Application Load Balancer

Os Application Load Balancers agora oferecem suporte integrado para modificação de headers de resposta HTTP, incluindo headers HSTS. Isso permite impor políticas de segurança consistentes em todos os seus serviços a partir de um único ponto, reduzindo esforço de desenvolvimento e garantindo proteção uniforme independentemente das tecnologias backend utilizadas.

Pré-requisitos e Configuração Inicial

Antes de implementar HSTS com load balancers, verifique se sua infraestrutura atende aos requisitos:

• Listener HTTPS funcional corretamente configurado
• Certificados TLS válidos na AWS Certificate Manager
• Recurso de modificação de headers habilitado para o listener (desabilitado por padrão)

Ativando Modificação de Headers de Resposta

Application Load Balancers suportam injeção direta de headers HSTS através do recurso de modificação de headers de resposta, fornecendo imposição centralizada de políticas de segurança sem necessidade de configuração em aplicações individuais.

1. Abra o console Amazon EC2 e navegue até Load Balancers
2. Selecione seu Application Load Balancer
3. Na aba “Listeners and rules”, selecione o listener HTTPS
4. Na aba “Attributes”, escolha “Edit”
5. Expanda a seção “Add response headers”
6. Selecione “Add HTTP Strict Transport Security (HSTS) header”
7. Configure o valor do header como max-age=31536000; includeSubDomains; preload
8. Clique em “Save changes”

Quando a modificação de headers é habilitada no ALB, a aplicação automática segue padrão consistente: se a resposta do backend não incluir o header especificado, o ALB o adiciona com o valor configurado; se a resposta já o contiver, o ALB substitui o valor existente pelo configurado. Isso garante imposição de política consistente em todas as respostas através do load balancer.

Para validar:

curl -I https://seu-loadbalancer-xxxx.us-west-2.elb.amazonaws.com

Resposta esperada:

strict-transport-security: max-age=31536000; includeSubDomains; preload

Configurando HSTS no Amazon CloudFront

O Amazon CloudFront oferece suporte integrado para headers de segurança HTTP, incluindo HSTS, através de políticas de headers de resposta. Esse recurso possibilita gerenciamento centralizado de headers de segurança na borda da CDN, garantindo imposição consistente de política em conteúdo cacheado e não-cacheado.

Criando Política de Headers de Resposta

É possível utilizar o recurso de política de headers de resposta do CloudFront para configurar headers de segurança automaticamente adicionados às respostas servidas por sua distribuição. O CloudFront oferece políticas de headers de resposta gerenciadas com valores pré-definidos para headers de segurança HTTP mais comuns, ou você pode criar uma política customizada.

1. No console CloudFront, navegue até “Policies” e depois “Response headers”
2. Escolha “Create response headers policy”
3. Configure as definições:
   • Name: HSTS-Security-Policy
   • Description: HSTS e headers de segurança para aplicações web
4. Sob “Security headers”, configure:
   • Strict Transport Security: ative e defina Max age como 31.536.000 segundos (1 ano)
   • Preload: ative (opcional)
   • IncludeSubDomains: ative (opcional)
5. Adicione headers de segurança adicionais:
   • X-Content-Type-Options
   • X-Frame-Options: selecione “SAMEORIGIN”
   • Referrer-Policy: selecione “strict-origin-when-cross-origin”
   • X-XSS-Protection: ative com “Block” selecionado
6. Clique em “Create”

Anexando a Política à Distribuição

1. Navegue até sua distribuição CloudFront
2. Selecione a aba “Behaviors”
3. Edite o comportamento padrão (ou crie um novo)
4. Sob “Response headers policy”, selecione a política criada
5. Clique em “Save changes”

Para validar:

curl -I https://seu-dominio-cloudfront.cloudfront.net

Resposta esperada:

strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin
x-xss-protection: 1; mode=block
x-cache: Hit from cloudfront

Considerações de Segurança e Boas Práticas

Configuração de Max-Age

A diretiva max-age determina por quanto tempo navegadores aplicarão política HTTPS-only. As recomendações de duração são:

• 300 segundos (5 minutos): Seguro para experiências durante fase de teste inicial
• 86.400 segundos (1 dia): Compromisso de curto prazo, como ambientes de desenvolvimento
• 2.592.000 segundos (30 dias): Validação de médio prazo, como ambientes staging
• 31.536.000 segundos (1 ano): Compromisso de longo prazo, como ambientes produção

Recomenda-se começar com valores menores de max-age durante implementação inicial e aumentá-los gradualmente conforme você ganha confiança na estabilidade da infraestrutura HTTPS.

Diretiva includeSubDomains

A diretiva includeSubDomains estende imposição HSTS a todos os subdomínios. Oferece proteção abrangente em toda hierarquia de domínio e previne ataques baseados em subdomínios, porém requer que todos os subdomínios suportem HTTPS com certificados SSL válidos e mantenham política de segurança consistente na hierarquia de domínio.

Preload para Máxima Cobertura

Considerar implementar HSTS preload para cobertura máxima de segurança:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Preload fornece proteção para visitantes pela primeira vez através de imposição no nível do navegador antes de requisições de rede, mas requer submissão a listas de preload do navegador e é difícil de reverter, exigindo compromisso de longo prazo com infraestrutura HTTPS.

Fonte

Implementing HTTP Strict Transport Security (HSTS) across AWS services (https://aws.amazon.com/blogs/security/implementing-http-strict-transport-security-hsts-across-aws-services/)

Novo recurso de gerenciamento centralizado de segurança de rede

A AWS anunciou, em dezembro de 2025, a expansão do AWS Shield Network Security Director com suporte a análise de segurança em múltiplas contas. Esta capacidade, que se encontra em fase de preview, permite que organizações gerenciem a segurança de rede de forma centralizada em toda sua estrutura na nuvem.

Como funciona o Network Security Director

O AWS Shield Network Security Director é uma ferramenta de visibilidade que oferece insights detalhados sobre os recursos AWS em sua organização. Seu principal objetivo é identificar lacunas na segurança e detectar serviços de segurança de rede que estão ausentes ou mal configurados, oferecendo ao mesmo tempo recomendações específicas para correção.

Análise centralizada em múltiplas contas

Com o novo recurso de análise multi-contas, é possível designar uma conta de administrador delegado para coordenar a análise contínua de segurança de rede. A partir dessa conta central, você consegue monitorar múltiplas contas ou unidades organizacionais em toda a sua AWS Organization.

A visão centralizada permite acompanhar a topologia de rede de cada conta, visualizar as descobertas de segurança identificadas e acessar as recomendações de remediação de forma agregada. Tudo isso sem precisar alternar entre diferentes contas ou consoles.

Integração com Amazon Q Developer

Uma das funcionalidades interessantes é a capacidade de gerar resumos e relatórios sobre as lacunas de segurança de rede identificadas. Esses relatórios podem ser solicitados e visualizados diretamente através do Amazon Q Developer, tanto dentro do AWS Management Console quanto em aplicativos de chat, simplificando o acesso às informações para equipes de segurança.

Expansão geográfica do serviço

Além do suporte a múltiplas contas, a AWS expandiu a disponibilidade geográfica do AWS Shield Network Security Director. O serviço agora está disponível em cinco regiões adicionais:

• Europe (Ireland)
• Europe (Frankfurt)
• Asia Pacific (Hong Kong)
• Asia Pacific (Singapore)
• Australia (Sydney)

Essa expansão permite que organizações em diferentes regiões do mundo desfrutem das mesmas capacidades de gerenciamento de segurança de rede, mantendo dados próximos de suas operações locais.

Próximos passos

Para organizações interessadas em explorar esta nova funcionalidade, a AWS recomenda consultar a página de visão geral do AWS Shield para obter mais detalhes técnicos e iniciar a avaliação da solução durante a fase de preview.

Fonte

AWS Shield network security director now supports multi-account analysis (https://aws.amazon.com/about-aws/whats-new/2025/12/aws-shield-network-security-director-multi-account-analysis)

Transformando Gerenciamento de Nuvem com Interfaces de Voz

À medida que infraestruturas em nuvem se tornam cada vez mais sofisticadas, a demanda por interfaces de gerenciamento intuitivas e eficientes cresce proporcionalmente. Interfaces de linha de comando (CLI) e consoles web tradicionais, embora poderosos, frequentemente criam barreiras que ralentizam a tomada de decisões e comprometem a eficiência operacional. E se fosse possível conversar diretamente com sua infraestrutura AWS e receber respostas inteligentes de forma imediata?

A AWS apresenta uma abordagem inovadora que combina Amazon Nova Sonic para processamento de voz com Strands Agents para orquestração de múltiplos agentes especializados. Esta solução demonstra como interações naturais por voz podem revolucionar operações em nuvem, tornando serviços AWS mais acessíveis e operações significativamente mais eficientes.

A arquitetura multi-agente apresentada vai além de simples operações AWS, estendendo-se para casos de uso diversos como automação de atendimento ao cliente, gerenciamento de dispositivos de Internet das Coisas (IoT), análise de dados financeiros e orquestração de fluxos de trabalho corporativos. Este padrão fundamental pode ser adaptado para qualquer domínio que exija roteamento inteligente de tarefas e interação baseada em linguagem natural.

Explorando a Arquitetura Técnica

A solução emprega uma arquitetura sofisticada onde Amazon Nova Sonic se integra perfeitamente com Strands Agents, criando um sistema multi-agente que processa comandos de voz e executa operações AWS em tempo real.

Componentes Principais

A arquitetura multi-agente é composta por diversos componentes especializados que trabalham em conjunto:

• Agente Supervisor: Funciona como coordenador central, analisando consultas de voz recebidas e as direcionando para o agente especializado apropriado, com base no contexto e intenção da solicitação
• Agentes Especializados:
  • Agente EC2: Responsável por gerenciamento de instâncias, monitoramento de status e operações de computação
  • Agente SSM: Gerencia operações do Systems Manager, execução de comandos e gerenciamento de patches
  • Agente de Backup: Supervisiona configurações de AWS Backup, monitoramento de trabalhos e operações de restauração
• Camada de Integração de Voz: Utiliza Amazon Nova Sonic para processamento bidirecional de voz, convertendo fala em texto para processamento e texto em fala para respostas

Visão Geral da Solução

O Assistente Nova Voice de Strands Agents demonstra um novo paradigma para gerenciamento de infraestrutura AWS através de inteligência artificial conversacional. Em vez de navegar por consoles complexos ou memorizar comandos CLI, usuários podem simplesmente expressar suas intenções por voz e receber respostas instantâneas. Esta solução coloca a comunicação humana natural no centro das operações técnicas AWS, democratizando o gerenciamento de nuvem para equipes técnicas e não-técnicas.

Stack Tecnológico

A solução utiliza tecnologias modernas e nativas de nuvem para entregar uma interface de voz robusta e escalável:

• Backend: Python 3.12+ com framework Strands Agents para orquestração de agentes
• Frontend: React com AWS Cloudscape Design System para experiência de usuário consistente com padrões AWS
• Modelos de IA: Amazon Bedrock e Claude 3 Haiku para compreensão e geração de linguagem natural
• Processamento de voz: Amazon Nova Sonic para síntese e reconhecimento de fala de alta qualidade
• Comunicação: Servidor WebSocket para comunicação bidirecional em tempo real

Recursos e Capacidades Principais

O assistente de voz oferece funcionalidades avançadas que tornam operações AWS mais intuitivas e eficientes. O sistema compreende consultas naturais de voz e as converte em chamadas apropriadas às APIs AWS. Por exemplo:

• “Mostrar todas as instâncias EC2 em execução em us-east-1”
• “Instalar o agente Amazon CloudWatch usando SSM nas minhas instâncias Dev”
• “Verificar o status dos trabalhos de backup de ontem à noite”

As respostas são especificamente otimizadas para entrega por voz, com resumos concisos limitados a 800 caracteres, informações estruturadas claras e fraseado conversacional que soa natural quando sintetizado em fala, evitando jargão técnico e utilizando sentenças completas adequadas para síntese de voz.

Colocando em Prática

Começar com o assistente de voz envolve três etapas principais:

Configuração do Ambiente

• Configurar credenciais AWS com acesso a Bedrock, Nova Sonic e serviços AWS alvo
• Preparar ambiente backend Python 3.12+ e frontend React
• Garantir permissões apropriadas de AWS Identity and Access Management (IAM) para operações multi-agente

Iniciando a Aplicação

• Iniciar o servidor Python WebSocket para processamento de voz
• Iniciar o frontend React com componentes AWS Cloudscape
• Configurar definições de voz e conexões WebSocket
• Começar interações de voz

Testando a Solução

• Conceder permissões de microfone do navegador para entrada de voz
• Testar com comandos de exemplo como “Listar minhas instâncias EC2” ou “Verificar status de backup”
• Experienciar respostas de voz em tempo real através de Amazon Nova Sonic

Instruções completas de implementação, exemplos de código e guias de solução de problemas estão disponíveis no repositório GitHub.

Exemplos de Comandos para Testar

Teste o assistente de voz com estes comandos de exemplo:

Gerenciamento de Instâncias EC2

• “Listar minhas instâncias EC2 dev onde a chave de tag é ‘env’”
• “Qual é o status dessas instâncias?”
• “Iniciar essas instâncias”
• “Essas instâncias têm permissões SSM?”

Gerenciamento de Backup

• “Garantir que essas instâncias sejam feitas backup diariamente”

Gerenciamento de SSM

• “Instalar agente CloudWatch usando SSM nessas instâncias”
• “Verificar essas instâncias quanto a patches usando SSM”

Exemplos de Implementação

Os exemplos de código demonstram padrões-chave de integração e práticas recomendadas para implementar o assistente de voz. Eles mostram como integrar Amazon Nova Sonic para processamento de voz e configurar o agente supervisor para roteamento inteligente de tarefas.

Configuração de Strands Agents

A implementação utiliza um padrão de orquestrador multi-agente com agentes especializados:

from strands import Agent
from config.conversation_config import ConversationConfig
from config.config import create_bedrock_model

class SupervisorAgent(Agent):
    def __init__(self, specialized_agents, config=None):
        bedrock_model = create_bedrock_model(config)
        conversation_manager = ConversationConfig.create_conversation_manager("supervisor")
        super().__init__(
            model=bedrock_model,
            system_prompt=self._get_routing_instructions(),
            tools=[],  # No tools for pure router
            conversation_manager=conversation_manager,
        )
        self.specialized_agents = specialized_agents

Integração com Nova Sonic

A implementação utiliza um servidor WebSocket com gerenciamento de sessão para processamento de voz em tempo real:

class S2sSessionManager:
    def __init__(self, model_id='amazon.nova-sonic-v1:0', region='us-east-1', config=None):
        self.model_id = model_id
        self.region = region
        self.audio_input_queue = asyncio.Queue()
        self.output_queue = asyncio.Queue()
        self.supervisor_agent = SupervisorAgentIntegration(config)

    async def processToolUse(self, toolName, toolUseContent):
        if toolName == "supervisoragent":
            result = await self.supervisor_agent.query(content)
            if len(result) > 800:
                result = result[:800] + "... (truncated for voice)"
            return {"result": result}

Considerações de Segurança

Esta solução foi projetada para fins de desenvolvimento e testes. Antes de implantar em ambientes produtivos, implemente controles de segurança apropriados incluindo:

• Mecanismos de autenticação e autorização
• Controles de segurança de rede e restrições de acesso
• Monitoramento e logging para conformidade de auditoria
• Controles de custo e monitoramento de uso

Sempre siga as práticas recomendadas de segurança da AWS e o princípio do menor privilégio ao configurar permissões IAM.

Considerações para Produção

Embora esta solução demonstre capacidades de Strands Agents usando uma abordagem de implantação focada em desenvolvimento, organizações planejando implementações produtivas devem considerar o Amazon Bedrock AgentCore Runtime para hospedagem e gerenciamento em nível corporativo.

Benefícios do Amazon Bedrock AgentCore para Implantação Produtiva

• Runtime Serverless: Propositadamente construído para implantar e dimensionar agentes de IA dinâmicos sem gerenciar infraestrutura
• Isolamento de Sessão: Isolamento completo de sessão com microVMs dedicadas para cada sessão de usuário, fundamental para agentes que executam operações privilegiadas
• Auto-dimensionamento: Dimensionar para milhares de sessões de agente em segundos com precificação por uso
• Segurança Corporativa: Controles de segurança integrados com integração perfeita a provedores de identidade (Amazon Cognito, Microsoft Entra ID, Okta)
• Observabilidade: Rastreamento distribuído integrado, métricas e capacidades de depuração através da integração CloudWatch
• Persistência de Sessão: Altamente confiável com persistência de sessão para interações de agentes de longa duração

Para organizações prontas para avançar além de desenvolvimento e testes, o Amazon Bedrock AgentCore Runtime oferece a base pronta para produção necessária para implantar assistentes AWS baseados em voz em escala corporativa.

Extensão para Serviços AWS Adicionais

O sistema pode ser estendido para suportar serviços AWS adicionais:

• AWS Lambda: Executar funções serverless através de comandos de voz
• Amazon CloudWatch: Consultar métricas e logs através de linguagem natural
• Amazon Relational Database Service (RDS): Operações de gerenciamento e monitoramento de banco de dados

Síntese

O Assistente Nova Voice de Strands Agents demonstra o potencial significativo de combinar interfaces de voz com orquestração inteligente de agentes em diversos domínios. Ao aproveitar Amazon Nova Sonic para processamento de fala e Strands Agents para coordenação multi-agente, organizações podem criar formas mais intuitivas e eficientes de interagir com sistemas e fluxos de trabalho complexos.

Esta arquitetura fundamental estende-se muito além de operações em nuvem, habilitando soluções baseadas em voz para automação de atendimento ao cliente, análise financeira, gerenciamento de IoT, fluxos de trabalho em saúde, otimização de cadeia de suprimentos e inúmeras outras aplicações corporativas. A combinação de processamento de linguagem natural, roteamento inteligente e conhecimento especializado de domínio cria uma plataforma versátil para transformar como usuários interagem com qualquer sistema complexo.

A arquitetura modular garante escalabilidade e extensibilidade, permitindo que organizações personalizem a solução para seus domínios e casos de uso específicos. À medida que interfaces de voz continuam evoluindo e capacidades de IA avançam, soluções como esta tendem a se tornar cada vez mais importantes para gerenciar ambientes complexos em todas as indústrias.

Começando

Pronto para construir seu próprio assistente de operações AWS alimentado por voz? O código-fonte completo e documentação estão disponíveis no repositório GitHub. Siga este guia de implementação para começar e não hesite em personalizar a solução para seus casos de uso específicos. Para dúvidas, feedback ou contribuições, consulte o repositório do projeto ou procure nos fóruns da comunidade AWS.

Fonte

Building a voice-driven AWS assistant with Amazon Nova Sonic (https://aws.amazon.com/blogs/machine-learning/building-a-voice-driven-aws-assistant-with-amazon-nova-sonic/)

Nova capacidade de transferência com desempenho ampliado

A AWS anunciou uma expansão significativa do AWS DataSync, serviço seguro e de alta velocidade para otimizar o movimento de dados pela rede. O Modo Aprimorado agora suporta transferências de dados entre servidores de arquivos on-premises e Amazon S3, permitindo que clientes transfiram datasets que escalam para números praticamente ilimitados de arquivos com níveis mais altos de desempenho em comparação ao Modo Básico do DataSync.

Como funciona o Modo Aprimorado

O Modo Aprimorado utiliza processamento paralelo para entregar maior desempenho e escalabilidade para datasets de qualquer tamanho. Seus benefícios principais incluem:

• Remoção de limitações de quantidade de arquivos
• Métricas detalhadas de transferência para melhor monitoramento e gerenciamento
• Processamento paralelo otimizado para performance superior
• Suporte a datasets de escala praticamente ilimitada

Anteriormente, o Modo Aprimorado estava disponível apenas para transferências entre localizações do Amazon S3 e para transferências multicloud. Este lançamento estende essas capacidades para suportar transferências entre servidores de arquivos NFS (Network File System) ou SMB (Server Message Block) on-premises e o Amazon S3.

Casos de uso habilitados

A expansão do DataSync abre possibilidades práticas para diversos cenários empresariais:

• Workloads de IA generativa: clientes podem acelerar essas cargas de trabalho movendo rapidamente datasets de treinamento para a AWS
• Análise de data lakes: sincronizar dados on-premises com pipelines baseados em nuvem potencializa análises em escala
• Migrações em larga escala: dirigir migrações para arquivamento e modernização de aplicações na nuvem

Disponibilidade e próximos passos

A nova capacidade está disponível em todas as regiões AWS onde o DataSync é oferecido. Para começar, clientes podem acessar o console do AWS DataSync. Informações técnicas detalhadas estão disponíveis na documentação do AWS DataSync.

Fonte

AWS DataSync increases scalability and performance for on-premises file transfers (https://aws.amazon.com/about-aws/whats-new/2025/12/aws-datasync-scalability-performance-on-premises-file-transfers)

Novo Recurso de Segurança para Ambientes Remotos

O Amazon WorkSpaces Secure Browser recebeu uma atualização significativa com a introdução da Filtragem de Conteúdo Web, um recurso abrangente de segurança e conformidade que permite que as organizações exerçam controle detalhado sobre o acesso aos conteúdos da web. Essa capacidade se apresenta como uma solução robusta para empresas que buscam fortalecer as políticas de acesso remoto sem comprometer a experiência do usuário.

Capacidades Principais da Filtragem de Conteúdo Web

Políticas Granulares e Categorização

O recurso permite que os administradores definam políticas de acesso muito específicas, com a possibilidade de bloquear URLs individuais ou categorias completas de domínios. Com mais de 25 categorias predefinidas à disposição, as equipes de TI ganham flexibilidade para estruturar as regras de forma alinhada às necessidades empresariais, mantendo a facilidade de gerenciamento centralizado que se adapta ao crescimento da organização.

Integração e Monitoramento Aprimorado

A Filtragem de Conteúdo Web se integra perfeitamente com o Session Logger (Registro de Sessão), ampliando as capacidades de monitoramento e geração de relatórios de conformidade. Enquanto as políticas existentes do Chrome para controle de domínios continuam funcionando, essa nova abordagem oferece um caminho mais abrangente para gerenciar acessos web através da filtragem por categorias e de capacidades de registro aprimoradas.

Flexibilidade e Conformidade

O recurso mantém a flexibilidade necessária para adaptações específicas ao negócio, permitindo políticas customizadas e exceções conforme as demandas particulares. Equipes de segurança em TI podem implementar políticas de negação padrão para ambientes de alta segurança, enquanto oficiais de conformidade aproveitam as capacidades detalhadas de registro e monitoramento para atender aos requisitos regulatórios.

Disponibilidade e Acesso

O recurso está disponível sem custo adicional em 10 regiões da AWS, incluindo US East (N. Virginia), US West (Oregon), Canada (Central), Europe (Frankfurt, London, Ireland) e Asia Pacific (Tokyo, Mumbai, Sydney, Singapore). O Amazon WorkSpaces Secure Browser oferece modelo de preços pay-as-you-go (pague conforme o uso).

Para começar com o WorkSpaces Secure Browser, consulte a documentação de introdução ao Amazon WorkSpaces Secure Browser. É possível ativar o recurso diretamente no console da AWS e migrar automaticamente qualquer política de navegador existente para listas de bloqueio ou permissão de URLs. Para aprofundar-se nas funcionalidades, consulte a documentação completa do recurso.

Fonte

Amazon WorkSpaces Secure Browser introduces Web Content Filtering (https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-workspaces-secure-browser-web-content-filtering/)

Uma nova forma de provisionar bancos de dados na AWS

A AWS anunciou uma importante melhoria no Amazon Aurora DSQL: a plataforma agora oferece a capacidade de criar clusters de banco de dados em questão de segundos, reduzindo drasticamente o tempo de configuração que anteriormente levava minutos. Essa otimização representa um avanço significativo para organizações que buscam agilidade no desenvolvimento e prototipagem de aplicações em nuvem.

O que mudou com essa melhoria

A redução no tempo de criação de clusters traz benefícios práticos imediatos para desenvolvedoras e desenvolvedores. Com a possibilidade de provisionar bancos de dados Aurora DSQL em segundos, é possível colocar novas ideias em produção muito mais rapidamente, sem aguardar processos de configuração longos e complexos.

A experiência foi ainda potencializada com a integração do editor de consultas direto no console da AWS. Isso significa que os desenvolvedores podem começar a trabalhar imediatamente, construindo aplicações sem necessidade de configurar clientes externos ou conectar-se através do servidor Model Context Protocol (MCP) do Aurora DSQL para ativar ferramentas de desenvolvimento com inteligência artificial.

Capacidades principais do Aurora DSQL

Independentemente do cenário — seja prototipagem rápida ou carga de produção em larga escala — o Aurora DSQL oferece um conjunto robusto de características:

• Escalabilidade virtualmente ilimitada para acompanhar o crescimento da sua aplicação
• Alta disponibilidade ativa-ativa, garantindo continuidade de operação
• Zero necessidade de gerenciamento de infraestrutura
• Modelo de preço por consumo: você paga apenas pelo que usa

Essa combinação de recursos garante que o banco de dados escala de forma automática conforme as demandas da aplicação aumentam, sem comprometer performance ou disponibilidade.

Disponibilidade e como começar

A melhoria de criação de clusters em segundos está disponível em todas as regiões onde o Aurora DSQL é oferecido. Para aqueles que desejam explorar a plataforma sem investimento inicial, a AWS disponibiliza o AWS Free Tier com acesso gratuito ao Aurora DSQL.

Para aprofundar seus conhecimentos sobre o serviço, é possível consultar a página oficial do Aurora DSQL e sua documentação técnica, onde você encontrará guias detalhados e exemplos práticos de implementação.

Fonte

Amazon Aurora DSQL now supports cluster creation in seconds (https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-aurora-dsql-cluster-creation-in-seconds)

Nova funcionalidade de conectividade privada no Amazon Cognito

A AWS anunciou suporte para AWS PrivateLink no Amazon Cognito identity pools, uma adição significativa para organizações que buscam maior segurança em seus fluxos de autenticação. Com essa novidade, agora é possível trocar identidades federadas por credenciais da AWS através de conectividade privada entre sua nuvem privada virtual (Virtual Private Cloud — VPC) e o Cognito.

A principal vantagem dessa funcionalidade é eliminar a necessidade de rotear tráfego de autenticação pela internet pública. Isso resulta em uma postura de segurança aprimorada para cargas de trabalho que exigem isolamento de rede rigoroso.

Como funciona a integração com identity pools

Os identity pools do Cognito têm a função de mapear identidades autenticadas e de convidado para papéis (roles) do AWS Identity and Access Management (IAM) e fornecer credenciais temporárias da AWS. Com o suporte ao PrivateLink, esse mapeamento agora pode ocorrer através de uma conexão segura e privada, mantendo o tráfego completamente isolado dentro da infraestrutura da AWS.

Disponibilidade e cobertura geográfica

Você pode utilizar conexões PrivateLink em todas as regiões da AWS onde o Amazon Cognito identity pools está disponível, com exceção da região AWS China (Beijing), operada pela Sinnet, e das regiões AWS GovCloud (US).

É importante observar que a criação de endpoints VPC no AWS PrivateLink gera custos adicionais. Para conhecer os detalhes de precificação, consulte a página de preços do AWS PrivateLink.

Como começar

Para iniciar o uso dessa funcionalidade, você pode criar um endpoint de interface VPC do AWS PrivateLink para o Amazon Cognito identity pools utilizando qualquer uma das seguintes ferramentas:

• AWS Management Console
• AWS Command Line Interface (CLI)
• AWS Software Development Kits (SDKs)
• AWS Cloud Development Kit (CDK)
• AWS CloudFormation

Para aprofundar-se na implementação, consulte a documentação sobre como criar um endpoint de interface VPC e o guia do desenvolvedor do Amazon Cognito.

Fonte

Amazon Cognito identity pools now support private connectivity with AWS PrivateLink (https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-cognito-identity-pools-private-connectivity-aws-privatelink)

MLflow para empresas: nova era de escalabilidade automática

A AWS anunciou recentemente Amazon SageMaker AI com MLflow, agora incluindo uma capacidade serverless que gerencia dinamicamente provisionamento de infraestrutura, escalabilidade e operações para tarefas de desenvolvimento em inteligência artificial e aprendizado de máquina (IA/ML). O destaque principal é que os recursos aumentam durante experimentos intensivos e reduzem a zero quando não estão em uso, diminuindo significativamente o overhead operacional.

A nova versão traz funcionalidades de nível empresarial como controle de acesso simplificado com compartilhamento entre contas, atualizações automáticas de versões e integração com capacidades do SageMaker AI, como customização de modelos e pipelines. O melhor: não exige configuração de administrador e não tem custo adicional, permitindo que cientistas de dados comecem imediatamente a rastrear experimentos, implementar observabilidade e avaliar desempenho de modelos sem delays relacionados a infraestrutura.

Recursos empresariais do SageMaker AI com MLflow

A nova capacidade serverless do MLflow no SageMaker AI oferece gerenciamento de nível empresarial com escalabilidade automática, provisionamento padrão, atualizações de versão perfeitas, autorização simplificada de AWS Identity and Access Management (IAM), compartilhamento de recursos através do AWS Resource Access Manager (AWS RAM), e integração com Amazon SageMaker Pipelines e customização de modelos.

A terminologia mudou: “MLflow Apps” agora substitui a designação anterior de “servidores de rastreamento MLflow”, refletindo uma abordagem simplificada e focada em aplicações. Cientistas de dados acessam a nova página MLflow Apps no Amazon SageMaker Studio.

Um MLflow App padrão é provisionado automaticamente ao criar um domínio SageMaker Studio, simplificando todo o processo de configuração. Já sai pronto para uso empresarial, sem exigir provisionamento ou configuração adicional. O MLflow App escala elasticamente conforme o uso, eliminando a necessidade de planejamento manual de capacidade. Cargas de trabalho de treinamento, rastreamento e experimentação recebem automaticamente os recursos necessários, simplificando operações enquanto mantém desempenho.

Atualizações automatizadas e versionamento

Administradores podem definir uma janela de manutenção durante a criação do MLflow App, período no qual ocorrem atualizações in-place da versão. Isso garante que o MLflow App permaneça padronizado, seguro e constantemente atualizado, minimizando overhead de manutenção manual. A versão 3.4 do MLflow é suportada neste lançamento, estendendo a plataforma para aplicações de IA generativa e cargas de trabalho com agentes.

Controle de identidades simplificado com MLflow Apps

A AWS simplificou o controle de acesso e permissões IAM para equipes de aprendizado de máquina com o novo MLflow App. Um conjunto de permissões racionalizado, como sagemaker:CallMlflowAppApi, agora cobre operações comuns — desde criar e buscar experimentos até atualizar informações de rastreamento — tornando o controle de acesso muito mais direto de aplicar.

Ao ativar limites de permissões IAM simplificados, usuários e administradores de plataforma podem padronizar papéis IAM entre equipes, personas e projetos, facilitando acesso consistente e auditável a experimentos e metadados do MLflow. Para configurações completas de permissão e políticas IAM, a documentação disponibiliza detalhes em Set up IAM permissions for MLflow Apps.

Compartilhamento entre contas AWS usando AWS RAM

Administradores frequentemente desejam gerenciar centralmente sua infraestrutura MLflow enquanto provisionam acesso em diferentes contas AWS. Os MLflow Apps suportam compartilhamento entre contas para desenvolvimento empresarial colaborativo em IA. Usando AWS RAM, essa funcionalidade permite que administradores de plataforma de IA compartilhem um MLflow App perfeitamente entre cientistas de dados em contas consumidoras separadas.

Administradores de plataforma mantêm um domínio SageMaker centralizado e governado que provisiona e gerencia o MLflow App, enquanto cientistas de dados em contas consumidoras separadas podem iniciar e interagir com o MLflow App com segurança. Combinado com as novas permissões IAM simplificadas, empresas podem iniciar e gerenciar um MLflow App a partir de uma conta AWS administrativa centralizada. Usando o MLflow App compartilhado, um cientista de dados consumidor downstream pode registrar suas experimentações MLflow e cargas de trabalho de IA generativa mantendo governança, auditabilidade e conformidade a partir de um único plano de controle do administrador de plataforma. Para saber mais sobre compartilhamento entre contas, consulte Getting Started with AWS RAM.

Integração entre SageMaker Pipelines e MLflow

Amazon SageMaker Pipelines está integrado ao MLflow. Trata-se de um serviço serverless de orquestração de fluxo de trabalho construído especificamente para automação de MLOps (operações de aprendizado de máquina) e LLMOps (operações com modelos de linguagem grande). Você pode construir, executar e monitorar fluxos de trabalho ML repetíveis de ponta a ponta de forma perfeita, usando interface arrastar-e-soltar intuitiva ou SDK Python.

A partir de um pipeline SageMaker, um MLflow App padrão é criado automaticamente se não existir, um nome de experimento MLflow pode ser definido, e métricas, parâmetros e artefatos são registrados no MLflow App conforme definido no código do pipeline SageMaker.

Customização de modelos SageMaker e integração com MLflow

A customização de modelos SageMaker integra-se com MLflow por padrão, oferecendo vinculação automática entre trabalhos de customização de modelos e experimentos MLflow. Ao executar trabalhos de fine-tuning (ajuste fino) de customização de modelos, o MLflow App padrão é utilizado, um experimento é selecionado, e métricas, parâmetros e artefatos são registrados automaticamente.

Na página de trabalho de customização de modelos do SageMaker, você pode visualizar métricas provenientes do MLflow e acessar métricas adicionais na interface do MLflow.

Próximos passos

Essas funcionalidades preparam os novos MLflow Apps no SageMaker AI para cargas de trabalho ML e IA generativa em escala empresarial com mínimo peso administrativo. Para começar, existem exemplos disponíveis no repositório de exemplos no GitHub e em workshop AWS.

Os MLflow Apps estão geralmente disponíveis nas regiões AWS onde o SageMaker Studio está disponível, com exceção das regiões China e US GovCloud. Para explorar a nova capacidade, você pode visitar a página de detalhes do produto SageMaker AI com MLflow e consultar a documentação sobre aceleração de desenvolvimento de IA generativa usando MLflow gerenciado no Amazon SageMaker AI. Para feedback, a AWS disponibiliza AWS re:Post para SageMaker ou canais usuais de suporte AWS.

Fonte

Scaling MLflow for enterprise AI: What’s New in SageMaker AI with MLflow (https://aws.amazon.com/blogs/machine-learning/scaling-mlflow-for-enterprise-ai-whats-new-in-sagemaker-ai-with-mlflow/)