Blog

Claude Opus 4.5 chega ao Amazon Bedrock

O modelo de linguagem mais recente da Anthropic, o Claude Opus 4.5, está agora disponível no Amazon Bedrock, um serviço gerenciado que oferece acesso a modelos de linguagem de alto desempenho de empresas líderes em inteligência artificial. O Opus 4.5 representa um avanço significativo no que os sistemas de inteligência artificial podem realizar e estabelece novos patamares em programação, agentes de IA, interação com computadores e tarefas de produtividade.

Este modelo se destaca por superar tanto o Sonnet 4.5 quanto o Opus 4.1, enquanto oferece capacidades equivalentes às do Opus com um terço do custo anterior. Sua arquitetura foi especificamente projetada para desenvolvedores que constroem agentes de IA sofisticados—sistemas capazes de raciocinar, planejar e executar tarefas complexas com mínima supervisão humana.

O que distingue o Opus 4.5

Engenharia de software e codificação

O Opus 4.5 demonstra desempenho excepcional em desenvolvimento profissional de software, alcançando 80,9% no benchmark SWE-bench Verified. Isso significa que o modelo pode transformar projetos de desenvolvimento que levariam vários dias em tarefas executáveis em horas. O modelo trabalha independentemente e inclui capacidades aprimoradas de codificação multilíngue, gerando código mais eficiente, melhor cobertura de testes e arquiteturas mais limpas.

Produtividade em tarefas empresariais

Para operações corporativas, o Opus 4.5 gerencia projetos complexos do início ao fim. Ele capacita agentes para criar apresentações em PowerPoint, planilhas em Excel e documentos em Word com acabamento profissional, incluindo revisão detalhada de documentos para contratos e acordos de não divulgação. O modelo também produz artefatos de React e HTML de qualidade superior, mantendo consistência e precisão—aspectos críticos para setores como finanças, onde a exatidão é fundamental. Ele preserva contexto entre arquivos durante projetos longos, garantindo coerência nas decisões.

Raciocínio visual avançado

Esta é a melhor capacidade de visão que a Anthropic ofereceu até agora, alcançando 80,7% no benchmark MMMU para fluxos de trabalho que dependem de interpretação visual complexa e navegação em múltiplas etapas. Exemplos incluem análise de mockups de design, processamento de documentos com layouts complexos e automatização de tarefas baseadas em navegação do navegador—com desempenho ainda mais aprimorado em interação com computadores.

Melhorias para desenvolvimento de agentes

O modelo introduz dois aprimoramentos-chave para desenvolvedores que criam agentes. A ferramenta de busca de ferramentas permite que agentes trabalhem com centenas de ferramentas descobrindo e carregando dinamicamente apenas aquelas que precisam, em vez de carregar todas as definições antecipadamente—potencialmente economizando dezenas de milhares de tokens e evitando confusão de esquemas ao escalar para grandes bibliotecas de ferramentas. Os exemplos de uso de ferramentas permitem fornecer chamadas de ferramentas exemplares diretamente na definição da ferramenta, melhorando a precisão para esquemas complexos com objetos ou arrays aninhados.

Casos de uso principais

Desenvolvimento de software

O Opus 4.5 é ideal para construir agentes que escrevem e refatoram código em projetos inteiros, gerenciam arquiteturas completas ou projetam sistemas multiagente que decompõem objetivos de alto nível em passos executáveis. A geração Claude abrange o ciclo completo de desenvolvimento: Opus 4.5 para código de produção e agentes sofisticados que usam 10 ou mais ferramentas em fluxos de trabalho como engenharia de software completa, cibersegurança ou análise financeira; Sonnet 4.5 para iteração rápida e experiências de usuário em escala; Haiku 4.5 para subagentos e produtos de acesso gratuito.

O Opus 4.5 pode analisar documentação técnica, planejar uma implementação de software, escrever o código necessário e refiná-lo iterativamente—mantendo rastreabilidade dos requisitos e contexto arquitetônico durante todo o processo.

Operações empresariais

Para gerenciar projetos complexos do início ao fim, o Opus 4.5 utiliza memória para manter contexto e consistência entre arquivos, com melhorias adicionais na criação de planilhas, slides e documentos. O modelo lida com projetos corporativos contínuos, automatizando fluxos de trabalho manuais.

Análise financeira

O modelo funciona eficientemente em sistemas complexos de informações—arquivos regulatórios, relatórios de mercado, dados internos—possibilitando modelagem preditiva e conformidade proativa. Sua consistência e precisão o tornam valioso para finanças e outros setores onde a exatidão é fundamental.

Cibersegurança

O Opus 4.5 oferece análise de nível profissional em fluxos de trabalho de segurança, correlacionando logs, bancos de dados de problemas de segurança e inteligência de segurança para detecção de eventos de segurança e resposta a incidentes automatizada.

Integração com o Amazon Bedrock AgentCore

A AWS fornece a fundação corporativa para implantar o Opus 4.5 em produção através do Amazon Bedrock AgentCore. O serviço gerenciado oferece uma API unificada para modelos de linguagem com segurança de nível corporativo, conformidade e governança.

O Opus 4.5 se integra ao AgentCore, que fornece infraestrutura e elementos primitivos para construir agentes de produção. O AgentCore inclui memória persistente para manter contexto entre sessões, o Gateway de Ferramentas para converter suas APIs e funções Lambda em ferramentas compatíveis com agentes, e gerenciamento de identidade e acesso integrado para acesso seguro aos recursos.

Você pode implantar e monitorar agentes com isolamento completo de sessão, suporte para fluxos de trabalho de longa duração (até 8 horas) e recursos de observabilidade—permitindo que você se concentre na construção de agentes em vez de gerenciar infraestrutura.

O Gateway de Ferramentas converte suas APIs e funções Lambda existentes em ferramentas compatíveis com agentes com mínimo de código—funcionando junto com o recurso de busca de ferramentas do modelo para orquestrar centenas de ferramentas. A observabilidade integrada através do Amazon CloudWatch rastreia uso de tokens, latência e taxas de erro em seus fluxos de trabalho de agentes.

Como começar

Para começar a usar o Opus 4.5 no Amazon Bedrock, você precisa configurar um cliente Python e importar as bibliotecas necessárias:

# Importar bibliotecas necessárias
import boto3
import json

# Criar uma sessão e cliente Bedrock
session = boto3.Session()
bedrock_client = session.client(
    service_name='bedrock-runtime',
    region_name='us-east-1'
)

Neste exemplo, definimos múltiplas ferramentas com defer_loading para ativar a busca de ferramentas. Isso permite que o modelo descubra e carregue apenas as ferramentas que necessita em vez de carregar todas as definições antecipadamente:

# Definir ferramentas com busca de ferramentas ativada
tools = [
    # Ativar busca de ferramentas - permite descoberta dinâmica de ferramentas
    {
        "type": "tool_search_tool_regex",
        "name": "tool_search_tool_regex"
    },
    # Ferramentas marcadas com defer_loading são descobertas sob demanda
    {
        "name": "get_weather",
        "description": "Obter clima atual para uma localização",
        "input_schema": {
            "type": "object",
            "properties": {
                "location": {"type": "string"},
                "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
            },
            "required": ["location"]
        },
        "defer_loading": True,
        # Fornecer exemplos de entrada para melhorar precisão de esquemas complexos
        "input_examples": [
            {"location": "San Francisco, CA", "unit": "fahrenheit"},
            {"location": "Tokyo, Japan", "unit": "celsius"}
        ]
    },
    {
        "name": "search_documentation",
        "description": "Pesquisar documentação da AWS",
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {"type": "string"},
                "service": {"type": "string"}
            },
            "required": ["query"]
        },
        "defer_loading": True,
        "input_examples": [
            {"query": "Lambda pricing", "service": "lambda"},
            {"query": "S3 bucket policies"}
        ]
    },
    {
        "name": "analyze_logs",
        "description": "Analisar logs de aplicação para erros",
        "input_schema": {
            "type": "object",
            "properties": {
                "log_file": {"type": "string"},
                "time_range": {"type": "string"}
            },
            "required": ["log_file"]
        },
        "defer_loading": True,
        "input_examples": [
            {"log_file": "/var/log/app.log", "time_range": "last 24 hours"},
            {"log_file": "/var/log/error.log"}
        ]
    }
]

Agora invocamos o modelo usando a Aplicação Programática (API) invoke_model com o parâmetro effort definido como médio:

# Construir a requisição com recursos beta ativados
request_body = {
    "anthropic_version": "bedrock-2023-05-31",
    # Ativar recursos beta: busca de ferramentas, exemplos de ferramentas e parâmetro effort
    "anthropic_beta": ["tool-search-tool-2025-10-19", "tool-examples-2025-10-29", "effort-2025-11-24"],
    "max_tokens": 4096,
    "temperature": 0.7,
    # Definir effort para "medium" para uso equilibrado de tokens
    "output_config": {
        "effort": "medium"
    },
    "messages": [
        {
            "role": "user",
            "content": "What's the weather in Seattle?"
        }
    ],
    "tools": tools
}

# Invocar o modelo
response = bedrock_client.invoke_model(
    modelId="global.anthropic.claude-opus-4-5-20251101-v1:0",
    body=json.dumps(request_body)
)

# Fazer parsing da resposta
response_body = json.loads(response['body'].read())

O modelo utiliza busca de ferramentas para localizar a ferramenta relevante (get_weather) da biblioteca sem carregar todas as definições de ferramentas antecipadamente. O parâmetro effort, disponível em versão beta, controla quanto liberalmente o modelo gasta tokens em raciocínio, chamadas de ferramentas e respostas. Você pode definir effort como alto para melhores resultados, médio para uso equilibrado ou baixo para uso conservador de tokens.

Capacidades principais para desenvolvimento de agentes

O Opus 4.5 possui várias capacidades que o tornam adequado para construir agentes em produção. O modelo mantém coerência em fluxos de trabalho estendidos, permitindo tomada de decisão consistente para agentes que executam processos com múltiplas etapas ao longo de horas ou dias. Melhor manipulação de ferramentas significa que agentes interagem mais confiávelmente com sistemas externos, Aplicações Programáticas (APIs) e interfaces de software—o modelo escolhe as ferramentas certas e interpreta resultados com maior precisão.

O Opus 4.5 também rastreia informações entre conversas e mantém contexto, ajudando agentes a acumular conhecimento ao longo do tempo e tomar decisões baseadas em histórico. O parâmetro effort, disponível em versão beta, oferece controle sobre uso de tokens. Você pode defini-lo como alto para melhores resultados quando qualidade importa mais, médio para desempenho equilibrado ou baixo para uso conservador de tokens. O Opus 4.5 ajusta o gasto de tokens entre raciocínio, chamadas de ferramentas e respostas com base nesta configuração.

Para implantações em produção, o Amazon Bedrock AgentCore oferece monitoramento e observabilidade através da integração com CloudWatch, rastreando uso de tokens em tempo real (útil ao ajustar o parâmetro effort), junto com métricas de latência, duração da sessão e taxas de erro para ajudar a otimizar desempenho do agente e gerenciar custos.

Preços e disponibilidade

O modelo é precificado em $5 por milhão de tokens de entrada e $25 por milhão de tokens de saída, tornando a inteligência em nível Opus acessível a um terço do custo das ofertas anteriores.

O modelo está disponível hoje no Amazon Bedrock através de inferência entre regiões, que roteia automaticamente requisições para capacidade disponível em regiões da AWS para maior throughput durante picos de demanda. Use este modelo para agentes que lidam com tarefas de longa duração, coordenam múltiplas ferramentas ou mantêm contexto em sessões estendidas.

Para informações detalhadas sobre disponibilidade, preços e especificações do modelo, consulte a documentação do Amazon Bedrock.

Próximos passos

Para começar, experimente o modelo no console do Amazon Bedrock, explore a documentação técnica e consulte a página de detalhes do modelo Claude da Anthropic para mais informações sobre suas capacidades.

Para implantar agentes em escala, explore o Opus 4.5 no Amazon Bedrock AgentCore para obter infraestrutura gerenciada com orquestração de ferramentas e monitoramento. O Opus 4.5 se destaca em fluxos de trabalho complexos e de longa duração, como desenvolvimento de software e operações empresariais. Suas capacidades em manipulação de ferramentas, gerenciamento de contexto e tomada de decisão o tornam valioso para construir agentes que operam de forma confiável em ambientes de produção.

Fonte

Claude Opus 4.5 now in Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/claude-opus-4-5-now-in-amazon-bedrock/)

O que é o Amazon Bedrock Custom Model Import?

O Amazon Bedrock Custom Model Import agora amplia seus recursos para incluir modelos OpenAI com pesos abertos, particularmente as variantes GPT-OSS de 20 bilhões e 120 bilhões de parâmetros. Esse serviço permite que as organizações importem modelos customizados diretamente em um ambiente serverless, onde é possível acessar simultaneamente modelos de fundação (FMs) por meio de uma interface unificada.

A principal vantagem dessa abordagem é eliminar a necessidade de gerenciar múltiplos endpoints ou infraestruturas isoladas. Após fazer o upload dos arquivos do modelo para o Amazon S3 (Amazon Simple Storage Service), a AWS assume todas as operações complexas: provisionamento de GPUs (Processadores Gráficos), configuração de servidores de inferência e dimensionamento automático conforme a demanda. Dessa forma, as equipes podem concentrar-se no desenvolvimento de aplicações enquanto a infraestrutura é gerenciada automaticamente.

Compatibilidade com a API do OpenAI

Os modelos GPT-OSS suportam completamente a API de Conclusões de Chat do OpenAI, mantendo compatibilidade integral com aplicações existentes. Isso significa que recursos como matrizes de mensagens, definições de papéis (sistema, usuário ou assistente) e estruturas de resposta padrão — incluindo métricas de uso de tokens — funcionam sem modificações.

Ao apontar suas aplicações para os endpoints do Amazon Bedrock, o código existente requer mudanças mínimas ou nenhuma mudança. Essa continuidade reduz significativamente o esforço de migração e o risco de regressões em produção.

Entendendo os Modelos GPT-OSS

Os modelos GPT-OSS representam os primeiros modelos de linguagem com pesos abertos lançados pela OpenAI desde o GPT-2, distribuídos sob a licença Apache 2.0. Isso significa que qualquer organização pode fazer download, modificar e utilizar esses modelos sem custos adicionais, inclusive para aplicações comerciais.

GPT-OSS-20B (20 Bilhões de Parâmetros)

Este modelo é otimizado para situações onde velocidade e eficiência são críticas. Apesar de possuir 21 bilhões de parâmetros, apenas 3,6 bilhões são ativados por token, permitindo execução em dispositivos com apenas 16 GB de memória. Com 24 camadas, 32 especialistas (4 ativos por token) e janela de contexto de 128k, oferece desempenho comparável ao o3-mini da OpenAI com a vantagem de poder ser implantado localmente para respostas mais rápidas.

GPT-OSS-120B (120 Bilhões de Parâmetros)

Desenvolvido para tarefas complexas de raciocínio — como codificação, matemática e uso de ferramentas em agentes automáticos — este modelo ativa 5,1 bilhões de parâmetros por token. Com 36 camadas, 128 especialistas (4 ativos por token) e janela de contexto de 128k, atinge desempenho equivalente ao o4-mini da OpenAI executando eficientemente em uma única Unidade de Processamento Gráfico (GPU) de 80 GB.

Arquitetura de Mistura de Especialistas

Ambos os modelos utilizam uma arquitetura de Mistura de Especialistas (MoE). Nessa abordagem, diferentes subconjuntos dos componentes do modelo (chamados de especialistas) tratam diferentes tipos de tarefas. Para cada requisição, apenas os especialistas mais relevantes são ativados, oferecendo desempenho potente enquanto mantém os custos computacionais gerenciáveis.

Formato dos Arquivos do Modelo GPT-OSS

Quando você faz download de modelos GPT-OSS do Hugging Face, recebe vários tipos de arquivo que trabalham em conjunto:

• Arquivos de pesos (.safetensors): Contêm os parâmetros reais do modelo
• Arquivos de configuração (config.json): Definem como o modelo funciona
• Arquivos do tokenizador: Realizam o processamento de texto
• Arquivo de índice (model.safetensors.index.json): Mapeia dados de pesos para arquivos específicos

O arquivo de índice exige uma estrutura específica para funcionar com o Amazon Bedrock. Deve incluir um campo de metadados no nível raiz, que pode estar vazio ({}) ou conter o tamanho total do modelo (que precisa estar abaixo de 200 GB para modelos de texto).

Modelos do Hugging Face às vezes incluem campos de metadados extras — como total_parameters — que o Amazon Bedrock não suporta. Esses campos devem ser removidos antes da importação. A estrutura correta deve ser assim:

{
  "metadata": {},
  "weight_map": {
    "lm_head.weight": "model-00009-of-00009.safetensors",
    ...
  }
}

Certifique-se de excluir o diretório .metal antes de iniciar o upload para o S3.

Processo de Implantação

O fluxo de implantação envolve quatro etapas principais:

1. Fazer download dos arquivos do modelo do Hugging Face e prepará-los para AWS
2. Enviar os arquivos do modelo para o Amazon S3
3. Usar o Amazon Bedrock Custom Model Import para trazer o modelo para o Bedrock
4. Invocar o modelo com chamadas à API compatível com OpenAI para testar a implantação

Pré-requisitos

Antes de começar a implantar seu modelo GPT-OSS, certifique-se de ter:

• Uma conta AWS ativa com permissões apropriadas
• Permissões do AWS Identity and Access Management (IAM) para:
  • Criar trabalhos de importação de modelos no Amazon Bedrock
  • Fazer upload de arquivos para o Amazon S3
  • Invocar modelos após implantação
  • Usar a função de serviço do Custom Model Import
• Um bucket S3 na sua região AWS de destino
• Aproximadamente 40 GB de espaço em disco local para download do modelo
• Acesso à Região US East 1 (N. Virginia) — obrigatória para modelos personalizados baseados em GPT-OSS
• Interface de Linha de Comando da AWS (AWS CLI) versão 2.x instalada
• Interface de Linha de Comando do Hugging Face (instale com pip install -U "huggingface_hub[cli]")

Download e Preparação dos Arquivos do Modelo

Para fazer download do modelo GPT-OSS usando a biblioteca Hugging Face Hub com transferência rápida habilitada:

import os
os.environ['HF_HUB_ENABLE_HF_TRANSFER'] = '1'
from huggingface_hub import snapshot_download

local_dir = snapshot_download(
    repo_id="Tonic/med-gpt-oss-20b",
    local_dir="./med-gpt-oss-20b",
)
print(f"Download complete! Model saved to: {local_dir}")

Após o download ser concluído (típicamente entre 10 a 20 minutos para 40 GB), verifique a estrutura do arquivo model.safetensors.index.json. Edite-o se necessário para garantir que o campo de metadados exista (pode estar vazio):

{
  "metadata": {},
  "weight_map": {
    "lm_head.weight": "model-00009-of-00009.safetensors",
    ...
  }
}

Envio dos Arquivos do Modelo para o Amazon S3

Antes de importar seu modelo, você deve armazenar os arquivos em um bucket S3 onde o Amazon Bedrock possa acessá-los.

Usando a Interface de Linha de Comando da AWS (AWS CLI), você pode sincronizar os arquivos diretamente:

aws s3 sync ./med-gpt-oss-20b/ s3://amzn-s3-demo-bucket/med-gpt-oss-20b/

O envio de 40 GB normalmente é concluído em 5 a 10 minutos. Para verificar se os arquivos foram enviados:

aws s3 ls s3://amzn-s3-demo-bucket/med-gpt-oss-20b/ --human-readable

Anote o URI do S3 (por exemplo, s3://amzn-s3-demo-bucket/med-gpt-oss-20b/) para usar no trabalho de importação. Os arquivos de saída são criptografados com as configurações de criptografia do bucket S3, seja com criptografia do lado do servidor SSE-S3 (Criptografia de Lado do Servidor S3) ou AWS Key Management Service (AWS KMS) dependendo de como você configurou o bucket.

Importação do Modelo no Amazon Bedrock

Após fazer upload dos arquivos do modelo para o S3, você pode importá-lo para o Amazon Bedrock, onde será processado e disponibilizado para inferência.

Use o AWS CLI para criar o trabalho de importação:

aws bedrock create-model-import-job \
  --job-name "gpt-oss-20b-import-$(date +%Y%m%d-%H%M%S)" \
  --imported-model-name "gpt-oss-20b" \
  --role-arn "arn:aws:iam::YOUR-ACCOUNT-ID:role/YOUR-ROLE-NAME" \
  --model-data-source "s3DataSource={s3Uri=s3://amzn-s3-demo-bucket/med-gpt-oss-20b/}"

A importação do modelo normalmente é concluída em 10 a 15 minutos para um modelo de 20B de parâmetros. Você pode acompanhar o progresso no console do Amazon Bedrock ou via AWS CLI. Após a conclusão, anote seu importedModelArn, que será usado para invocar o modelo.

Invocação do Modelo com API Compatível com OpenAI

Após a conclusão da importação, você pode testar o modelo usando o formato familiar da API de Conclusões de Chat do OpenAI para verificar se está funcionando corretamente.

Crie um arquivo chamado test-request.json com o seguinte conteúdo:

{
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful AI assistant."
    },
    {
      "role": "user",
      "content": "What are the common symptoms of Type 2 Diabetes?"
    }
  ],
  "max_tokens": 500,
  "temperature": 0.7
}

Use o AWS CLI para enviar a requisição ao seu endpoint de modelo importado:

aws bedrock-runtime invoke-model \
  --model-id "arn:aws:bedrock:us-east-1:YOUR-ACCOUNT-ID:imported-model/MODEL-ID" \
  --body file://test-request.json \
  --cli-binary-format raw-in-base64-out \
  response.json

cat response.json | jq '.'

A resposta retorna no formato padrão do OpenAI:

{
  "id": "chatcmpl-f06adcc78daa49ce9dd2c58f616bad0c",
  "object": "chat.completion",
  "created": 1762807959,
  "model": "YOUR-ACCOUNT-ID-MODEL-ID",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Type 2 Diabetes often presents with a range of symptoms...",
        "refusal": null,
        "function_call": null,
        "tool_calls": []
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 98,
    "completion_tokens": 499,
    "total_tokens": 597
  }
}

A estrutura da resposta corresponde exatamente ao formato do OpenAI — choices contém a resposta, usage fornece contagens de tokens e finish_reason indica o status de conclusão. O código existente de análise de resposta do OpenAI funciona sem modificações.

Migração do OpenAI para Amazon Bedrock

Migrar do OpenAI requer apenas mudanças mínimas no código — apenas o método de invocação muda, enquanto as estruturas de mensagens permanecem idênticas.

No OpenAI:

import openai
response = openai.ChatCompletion.create(model="....", messages=[...])

No Amazon Bedrock:

import boto3, json
bedrock = boto3.client('bedrock-runtime')
response = bedrock.invoke_model(
    modelId='arn:aws:bedrock:us-east-1:ACCOUNT:imported-model/MODEL-ID',
    body=json.dumps({"messages": [...]})
)

A migração é direta e oferece vantagens significativas: custos previsíveis, melhor privacidade de dados e a capacidade de ajustar modelos para necessidades específicas.

Limpeza de Recursos

Quando terminar, limpe seus recursos para evitar cobranças desnecessárias:

aws bedrock delete-imported-model --model-identifier "arn:aws:bedrock:us-east-1:ACCOUNT:imported-model/MODEL-ID"
aws s3 rm s3://amzn-s3-demo-bucket/med-gpt-oss-20b/ --recursive

Se não precisar mais da função IAM, delete-a usando o console do IAM.

Práticas Recomendadas

Considere as seguintes práticas recomendadas ao trabalhar com importação de modelos:

• Validação de arquivos: Antes de fazer upload, verifique se model.safetensors.index.json tem a estrutura de metadados correta, se os arquivos safetensors referenciados existem e se os tokenizadores são suportados. A validação local economiza tempo em tentativas de importação.
• Segurança: No console do Amazon Bedrock, crie funções IAM automaticamente com permissões de privilégio mínimo. Para múltiplos modelos, use prefixos S3 separados para manter isolamento.
• Versionamento: Use caminhos descritivos no S3 (como gpt-oss-20b-v1.0/) ou nomes de trabalhos de importação com data para rastreamento de implantações.

Custos e Disponibilidade

Você é cobrado pela execução de inferência com modelos customizados que importa no Amazon Bedrock. Para mais detalhes, consulte Calcular o custo de executar um modelo customizado e Preços do Amazon Bedrock.

O Amazon Bedrock Custom Model Import está disponível em múltiplas regiões, com suporte se expandindo para regiões adicionais em breve. Consulte Suporte de recursos por região AWS no Amazon Bedrock para as atualizações mais recentes. Os modelos GPT-OSS estarão inicialmente disponíveis na Região US-East-1 (N. Virginia).

Conclusão

O Amazon Bedrock Custom Model Import oferece às organizações a capacidade de trazer modelos GPT-OSS para um ambiente gerenciado e serverless, mantendo compatibilidade total com a API do OpenAI. Isso reduz significativamente o esforço de migração de aplicações existentes para a AWS.

Os benefícios práticos são evidentes: segurança de nível empresarial, dimensionamento automático, controle de custos previsível, privacidade de dados aprimorada e a possibilidade de ajustar modelos com seus próprios dados proprietários. Tudo isso com mudanças mínimas no código existente.

Tem dúvidas ou feedback? Conecte-se com a comunidade através do AWS re:Post para Amazon Bedrock — eles adorariam ouvir sobre sua experiência.

Fonte

Deploy GPT-OSS models with Amazon Bedrock Custom Model Import (https://aws.amazon.com/blogs/machine-learning/deploy-gpt-oss-models-with-amazon-bedrock-custom-model-import/)

O que muda no CloudFront

A AWS anunciou o suporte para Autenticação TLS Mútua (mTLS) no CloudFront, um protocolo de segurança que exige que tanto o servidor quanto o cliente se autentiquem mutuamente utilizando certificados X.509. Com esse recurso, os clientes conseguem validar a identidade dos acessantes nas localizações edge do CloudFront, antes que as conexões cheguem aos servidores de aplicação ou APIs.

Até então, as empresas precisavam investir esforço contínuo para implementar e manter suas próprias soluções de gestão de acesso de clientes — uma tarefa repetitiva e sem agregação de valor diferenciado. Agora, a autenticação mútua TLS simplifica esse processo, garantindo que apenas clientes portadores de certificados confiáveis consigam acessar as distribuições do CloudFront.

Benefícios práticos para sua infraestrutura

Com essa novidade, é possível proteger distribuições contra acessos não autorizados e ameaças de segurança, validando identidades de clientes no edge antes de qualquer conexão ser estabelecida. O uso de autenticação mútua TLS no CloudFront oferece os mesmos benefícios de performance e escala da plataforma, agora aplicados a workloads que demandam autenticação de clientes.

O recurso está disponível para todos os clientes do CloudFront sem custo adicional e pode ser configurado através do Console de Gerenciamento da AWS, CLI, SDK, CDK e CloudFormation.

Casos de uso principais

Integrações seguras de APIs B2B

Para cenários B2B, empresas podem autenticar requisições de API provenientes de parceiros e terceiros confiáveis utilizando autenticação mútua TLS. Isso é especialmente valioso para integrações entre organizações que precisam validar identidades em cada transação.

Autenticação de dispositivos IoT

Em ambientes com Internet das Coisas, é possível validar que apenas dispositivos autorizados recebem conteúdo proprietário, como atualizações de firmware. Dessa forma, garante-se que apenas equipamentos legítimos acessam recursos críticos.

Flexibilidade para escolher certificados

Os clientes podem aproveitar Autoridades de Certificação de terceiros já existentes ou utilizar a Autoridade de Certificados Privada da AWS para assinar certificados X.509. Essa flexibilidade permite que as organizações continuem usando sua infraestrutura de certificados ou adotem a solução gerenciada pela AWS conforme sua necessidade.

Como começar

Para empresas que desejam implementar essa solução, a AWS fornece orientações detalhadas e boas práticas na documentação de autenticação mútua TLS do CloudFront. O processo de configuração é direto e integrado aos fluxos de trabalho já familiares aos usuários da plataforma.

Fonte

Amazon CloudFront announces support for mutual TLS authentication (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-cloudfront-mutual-tls-authentication/)

Nova Abordagem para Análise de Logs

A AWS anunciou recentemente melhorias significativas nas capacidades de análise de logs do Amazon OpenSearch Service. A principal novidade está na transformação do espaço de Observabilidade da interface do OpenSearch, onde a Linguagem de Processamento em Pipe (PPL) e as consultas em linguagem natural agora funcionam como experiência padrão. Essa mudança combina a sintaxe comprovada de pipelines com fluxos de trabalho simplificados, oferecendo aos usuários uma experiência mais intuitiva para monitorar sistemas em escala crescente sem aumentar custos.

Capacidades Expandidas para Análise Profunda

A atualização disponibiliza mais de 35 novos comandos que ampliam as possibilidades de análise. Esses comandos permitem exploração em facetas, consultas em linguagem natural e análise profunda de dados, habilitando times a extrair insights significativos sobre infraestrutura, segurança e métricas de negócio. A solução também incorpora recursos de nível empresarial para correlação avançada de eventos usando linguagem natural, auxiliando equipes a descobrir padrões relevantes de forma mais ágil.

Interface Unificada e Mais Produtiva

Um diferencial importante é a possibilidade de transição perfeita entre consultas e visualizações dentro de uma única interface. Esse design reduz o tempo médio para detectar e resolver problemas, eliminando a necessidade de alternar entre múltiplas ferramentas durante o processo de investigação.

Implementação Facilitada com OpenTelemetry

Para facilitar a adoção, a AWS oferece um fluxo de início rápido no console. Administradores conseguem estruturar uma solução completa baseada em OpenTelemetry usando o workflow “Get Started” do OpenSearch, sem complexidade adicional. O serviço inclui pipelines de ingestão do OpenSearch já configurados para dados de OpenTelemetry, acelerando o processo de onboarding para as equipes.

Disponibilidade Geográfica

A interface do Amazon OpenSearch UI está disponível em múltiplas regiões da AWS, abrangendo os principais polos de infraestrutura global: nos Estados Unidos, América do Sul (incluindo São Paulo), Europa, Ásia Pacífico e Canadá. Essa distribuição garante baixa latência e conformidade com regulamentações regionais para organizações brasileiras e latino-americanas.

Próximos Passos

Para explorar essa nova experiência de análise de logs, a documentação completa sobre observabilidade do OpenSearch Service está disponível. Você pode começar a utilizar essas capacidades aprimoradas diretamente na interface do OpenSearch UI e avaliar como a combinação de PPL e linguagem natural pode beneficiar suas operações.

Fonte

OpenSearch Service Enhances Log Analytics with New PPL Experience (https://aws.amazon.com/about-aws/whats-new/2025/11/opensearch-service-log-analytics-ppl/)

Inovação em IA Generativa no Canadá: Um Novo Horizonte

Organizações canadenses estão descobrindo oportunidades significativas para transformar suas operações e experiências de clientes através de inteligência artificial generativa. A AWS expandiu recentemente suas capacidades nessa região com um anúncio importante: clientes no Canadá agora podem acessar modelos de fundação avançados, incluindo Claude Sonnet 4.5 e Claude Haiku 4.5 da Anthropic, por meio do Amazon Bedrock utilizando perfis de inferência cross-region (CRIS).

Este desenvolvimento abre caminhos para que empresas canadenses implementem soluções de IA em escala, aproveitando os últimos modelos de linguagem disponíveis globalmente, ao mesmo tempo em que mantêm conformidade com requisitos de governança de dados locais. O artigo a seguir explora como organizar essa transição, configurar os permissionamentos necessários e gerenciar a capacidade de forma eficiente.

Entendendo a Inferência Cross-Region: Capacidades e Arquitetura

O que são Perfis de Inferência Cross-Region?

A AWS oferece no Amazon Bedrock os chamados perfis de inferência cross-region (CRIS), um mecanismo poderoso que permite às organizações distribuir requisições de processamento de forma automática entre múltiplas regiões. Esse recurso resolve um desafio fundamental para aplicações de IA em escala: equilibrar a demanda de throughput enquanto mantém a responsividade mesmo sob carga elevada.

A AWS oferece dois tipos principais de perfis de inferência cross-region:

• CRIS Geográfico: A AWS seleciona automaticamente a região comercial ideal dentro de uma determinada geografia para processar sua requisição de inferência.
• CRIS Global: Amplia ainda mais as possibilidades ao rotear requisições para regiões comerciais suportadas em qualquer parte do mundo, otimizando recursos disponíveis e permitindo maior throughput dos modelos.

Segurança e Conformidade: Onde Residem Seus Dados

Um ponto essencial para organizações com requisitos regulatórios rigorosos: a inferência cross-region opera através da rede segura da AWS com criptografia de ponta a ponta, tanto para dados em trânsito quanto em repouso. Quando uma requisição de inferência é enviada da região Canadá (Central), o CRIS a roteia inteligentemente para uma das regiões de destino configuradas no perfil de inferência.

A distinção crítica é esta: enquanto o processamento de inferência (a computação transitória) pode ocorrer em outra região, todos os dados em repouso — incluindo logs de invocação, bases de conhecimento e configurações armazenadas — permanecem exclusivamente dentro da região Canadá (Central). A requisição viaja pela rede global da AWS, sem passar pela internet pública, e as respostas retornam criptografadas para sua aplicação no Canadá.

Vantagens Estratégicas da Inferência Cross-Region para o Canadá

Implementar CRIS oferece ganhos tangíveis para organizações canadenses em múltiplas dimensões:

Acesso Acelerado a Modelos Novos: Com CRIS, organizações canadenses ganham acesso antecipado a modelos de ponta, como Claude Sonnet 4.5 com capacidades aprimoradas de raciocínio. Em vez de esperar meses por disponibilidade regional, o acesso pode ser conquistado em dias.

Capacidade e Performance Aprimoradas: O acesso distribuído a recursos de múltiplas regiões permite maior throughput geral. Durante períodos de pico — como temporada de impostos, Black Friday e compras de final de ano — a capacidade escala automaticamente sem intervenção manual, absorvendo surtos de demanda.

Resiliência Operacional: Servir requisições de um pool maior de recursos aumenta a resiliência geral. Se uma região enfrenta restrições de capacidade, o tráfego é automaticamente distribuído, garantindo que aplicações de IA permaneçam responsivas.

Escolhendo Entre Perfis US e Global

Organizações canadenses podem optar entre dois modelos de perfil de inferência conforme suas necessidades específicas:

• Inferência Cross-Region US: Recomendada para organizações com acordos de processamento de dados existentes com regiões US, requisitos de throughput e resiliência elevados, e ambientes de desenvolvimento e teste.
• Inferência Global: Apropriada quando máxima capacidade é prioritária ou quando restrições geográficas permitem processamento em qualquer região comercial suportada.

Começando com Perfis de Inferência Cross-Region

Etapa 1: Configurar Permissões IAM

Antes de implementar CRIS, é necessário validar que sua função ou usuário IAM possui as permissões corretas para invocar modelos Amazon Bedrock utilizando perfis de inferência cross-region.

Abaixo está um exemplo de política para inferência cross-region US:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel*"
      ],
      "Resource": [
        "arn:aws:bedrock:ca-central-1::inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel*"
      ],
      "Resource": [
        "arn:aws:bedrock:*::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
      ],
      "Condition": {
        "StringLike": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:ca-central-1::inference-profile/us.anthropic.claude-sonnet-4-5-20250929-v1:0"
        }
      }
    }
  ]
}

Para configurar CRIS global, consulte o artigo dedicado disponível na documentação AWS sobre escalabilidade de inferência global com o Claude Sonnet 4.5.

Etapa 2: Utilizar Perfis de Inferência Cross-Region

Configure sua aplicação para usar os identificadores de perfil de inferência relevantes. Os perfis utilizam prefixos que indicam seu escopo de roteamento:

• Claude Sonnet 4.5 (Regiões US): us.anthropic.claude-sonnet-4-5-20250929-v1:0
• Claude Sonnet 4.5 (Global): global.anthropic.claude-sonnet-4-5-20250929-v1:0
• Claude Haiku 4.5 (Regiões US): us.anthropic.claude-haiku-4-5-20251001-v1:0
• Claude Haiku 4.5 (Global): global.anthropic.claude-haiku-4-5-20251001-v1:0

Exemplo Prático: Utilizando a API Converse

Abaixo está um exemplo de como usar a API Converse do Amazon Bedrock com um perfil de inferência CRIS US a partir do Canadá:

import boto3

# Inicializar cliente Bedrock Runtime
bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name="ca-central-1"  # Região Canadá (Central)
)

# Definir o identificador do perfil de inferência
inference_profile_id = "us.anthropic.claude-sonnet-4-5-20250929-v1:0"

# Preparar a conversa
response = bedrock_runtime.converse(
    modelId=inference_profile_id,
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "text": "What are the benefits of using Amazon Bedrock for Canadian organizations?"
                }
            ]
        }
    ],
    inferenceConfig={
        "maxTokens": 512,
        "temperature": 0.7
    }
)

# Exibir a resposta
print(f"Response: {response['output']['message']['content'][0]['text']}")

Gerenciando Quotas de Capacidade para Cargas no Canadá

Como as Quotas Funcionam com CRIS

Ao utilizar CRIS a partir do Canadá, o gerenciamento de quotas é realizado no nível da região de origem (ca-central-1). Isto significa que aumentos de quota solicitados para a região Canadá (Central) aplicam-se a todas as requisições de inferência originadas no Canadá, independentemente de onde são efetivamente processadas.

Entendendo Taxa de Burndown

Um conceito crítico ao calcular aumentos necessários de quota: quando você planeja aumentos, deve levar em conta a taxa de burndown, definida como a velocidade na qual tokens de entrada e saída são convertidos em uso de quota de token para o sistema de throttling.

Os seguintes modelos possuem taxa de burndown de 5x para tokens de saída (1 token de saída consome 5 tokens de sua quota):

• Anthropic Claude Opus 4
• Anthropic Claude Sonnet 4.5
• Anthropic Claude Sonnet 4
• Anthropic Claude 3.7 Sonnet

Para outros modelos, a taxa de burndown é de 1:1 (1 token de saída consome 1 token de sua quota). Para tokens de entrada, a proporção é sempre 1:1.

A fórmula para calcular o total de tokens por requisição é:

Contagem de tokens de entrada + Tokens de entrada em cache escrito + (Contagem de tokens de saída × Taxa de burndown)

Solicitando Aumentos de Quota

Para solicitar aumentos de quota para CRIS no Canadá:

1. Navegue para o console de quotas de serviço da AWS na região Canadá (Central).
2. Procure pela quota de modelo específico (por exemplo, “Claude Sonnet 4.5 tokens por minuto”).
3. Envie uma solicitação de aumento baseada no seu uso projetado.

Migrando de Modelos Claude Anteriores para Claude 4.5

Organizações utilizando versões anteriores de Claude devem considerar uma migração planejada para aproveitar as capacidades do Claude 4.5. Para estruturar essa transição:

Estabeleça Métricas de Baseline: Defina métricas de desempenho inicial para seus modelos existentes, criando um ponto de referência claro.

Teste com Cargas Representativas e Otimize Prompts: Valide o desempenho do Claude 4.5 com seus casos de uso específicos. Ajuste seus prompts para aproveitar as capacidades mais recentes do modelo e utilize a ferramenta de otimização de prompt do Bedrock.

Implemente Rollout Gradual: Transicione tráfego progressivamente em vez de uma mudança brusca, reduzindo risco operacional.

Monitore e Ajuste: Acompanhe métricas de desempenho e ajuste quotas conforme necessário durante o período de transição.

Síntese: Conformidade, Velocidade e Escala

A inferência cross-region para Amazon Bedrock representa uma oportunidade para organizações canadenses que desejam implementar IA generativa mantendo rigorosa governança de dados. Ao diferenciar entre processamento de inferência transitório e armazenamento de dados persistente, CRIS oferece acesso acelerado aos últimos modelos de fundação sem comprometer conformidade regulatória.

Com CRIS, organizações canadenses obtêm acesso a novos modelos em dias em vez de meses. O sistema escala automaticamente durante períodos de pico de negócios mantendo trilhas de auditoria completas dentro do Canadá, ajudando a atender requisitos regulatórios enquanto utilizam as mesmas capacidades avançadas de IA disponíveis globalmente.

Para começar, revise seus requisitos de governança de dados e configure os permissionamentos IAM necessários. Depois, teste com o perfil de inferência que melhor se alinha com suas necessidades — US para latência reduzida com regiões americanas, ou Global para máxima capacidade.

Fonte

Accelerate generative AI innovation in Canada with Amazon Bedrock cross-Region inference (https://aws.amazon.com/blogs/machine-learning/accelerate-generative-ai-innovation-in-canada-with-amazon-bedrock-cross-region-inference/)

A AWS Anuncia Criptografia Pós-Quântica no Payments Cryptography

A AWS anunciou o suporte a TLS pós-quântico híbrido (PQ-TLS) no serviço de Payments Cryptography, focando em proteger as chamadas de API com criptografia resistente a ataques quânticos. Essa expansão representa um passo importante para que as empresas possam assegurar a transmissão de dados e comandos sensíveis contra futuras ameaças quânticas.

O Desafio da Segurança em Longo Prazo

Organizações que operam cargas de trabalho altamente regulamentadas enfrentam uma preocupação crescente: o risco conhecido como “capturar agora, descriptografar depois”. Dados em trânsito podem ser registrados e armazenados hoje, para então serem descriptografados no futuro quando computadores quânticos suficientemente poderosos se tornarem disponíveis.

Com esse anúncio, o AWS Payments Cryptography agora se integra a serviços de proteção de dados como o AWS Key Management Service (KMS), ambos endereçando essa preocupação ao implementar suporte a PQ-TLS com criptografia pós-quântica ML-KEM.

Como Começar com PQ-TLS

Para ativar essa capacidade, basta garantir que sua aplicação utilize uma versão do AWS SDK ou navegador que suporte PQ-TLS. A AWS fornece orientações detalhadas por linguagem de programação e plataforma na documentação de ativação de PQ-TLS.

Os clientes também podem validar que ML-KEM foi utilizado para proteger a sessão TLS de uma chamada de API revisando os detalhes do TLS (tlsDetails) no evento CloudTrail correspondente, tanto no console quanto em trilhas CloudTrail configuradas.

Disponibilidade e Custos

Essas capacidades estão geralmente disponíveis em todas as regiões da AWS sem custo adicional. Para começar a trabalhar com PQ-TLS e Payment Cryptography, a AWS disponibiliza um guia de TLS pós-quântico.

Para mais informações sobre criptografia pós-quântica na AWS, incluindo detalhes sobre responsabilidades compartilhadas, consulte a documentação sobre PQC e responsabilidade compartilhada.

Fonte

AWS Payments Cryptography announces support for post-quantum cryptography to secure data in transit (https://aws.amazon.com/about-aws/whats-new/2025/11/aws-payments-cryptography-post-quantum-data-transit)

O Desafio das Credenciais de Longa Duração

Credenciais expostas continuam sendo o método mais explorado por atores maliciosos em incidentes de segurança observados pela equipe de resposta a incidentes da AWS. Quando credenciais de longa duração ou chaves de acesso caem em mãos não autorizadas, o risco para ambientes em nuvem se intensifica. Práticas inadequadas de rotação de chaves, compartilhamento de credenciais entre múltiplos usuários e falha em revogar acessos não utilizados deixam sistemas vulneráveis.

O uso de credenciais de longa duração é fortemente desaconselhado, criando uma oportunidade clara para migração em direção aos papéis do AWS Identity and Access Management (IAM) e ao acesso federado. Embora a melhor prática recomende que organizações se afastem desse modelo, entende-se que essa transição pode não ser imediata para todos os ambientes.

Para construir uma defesa abrangente contra exposição não intencional de credenciais, é necessário adotar uma abordagem estratificada em camadas. Essa estratégia funciona como ponte entre o ideal de segurança e as realidades operacionais, fornecendo passos práticos para equipes que gerenciam cargas de trabalho legadas que ainda dependem de credenciais de longa duração.

Identificando Riscos e Exposições Existentes

Auditando Chaves de Acesso Atuais

O primeiro passo é ganhar visibilidade. Organizações devem gerar regularmente relatórios de credenciais que identifiquem propriedade de usuários IAM sobre credenciais de longa duração, incluindo informações como última rotação, último uso, serviço e região utilizados. Esses relatórios oferecem uma visão essencial do cenário de credenciais, permitindo identificar chaves inativas ou potencialmente comprometidas — especialmente aquelas com rotações atrasadas, fora da política, ou com padrões de uso inesperados de regiões desconhecidas.

Detectando Chaves de Acesso Expostas

A fonte mais comum de comprometimento de credenciais é o commit acidental em repositórios públicos. Quando desenvolvedores, sem intencionalidade, enviam credenciais para repositórios acessíveis publicamente, ferramentas automatizadas de scanning utilizadas por adversários colhem essas chaves imediatamente.

A varredura de código é fundamental para identificar esses problemas críticos antes que credenciais sejam commitadas acidentalmente ou implantadas em ambientes de produção onde possam ser exploradas. O Amazon CodeGuru Security oferece uma capacidade de detecção de secrets que integra com o AWS Secrets Manager, localizando proativamente dados sensíveis não criptografados no código — como chaves secretas da AWS, senhas embutidas e strings de conexão de banco de dados. Quando descobertos, o CodeGuru cria achados com remediação recomendada.

O AWS Trusted Advisor também fornece uma verificação de chaves de acesso expostas que examina repositórios públicos populares e detecta uso irregular do Amazon Elastic Compute Cloud (Amazon EC2) que poderia indicar comprometimento. É importante notar que essas ferramentas não conseguem detectar segredos armazenados fora de seu escopo — como máquinas de desenvolvimento local ou sistemas externos — e devem ser vistas como parte de uma estratégia mais ampla, não como única solução.

Quando há indício de comprometimento, a rotação imediata das chaves é essencial. Instruções específicas estão disponíveis nos guias de rotação de chaves de acesso para usuários IAM.

Identificando Acessos Não Utilizados

Além de detectar credenciais expostas, identificar chaves de acesso inativas reduz a superfície de ataque. O AWS IAM Access Analyzer inclui um analisador de acesso não utilizado que identifica permissões excessivas ou em desuso — incluindo papéis IAM não utilizados, chaves de acesso inativas, senhas não usadas e ações em papéis e usuários ativos. Após revisar os achados, é possível remover ou modificar permissões desnecessárias.

Revogar credenciais sem uso limita o impacto caso um ator malicioso tenha obtido acesso a elas. Essas ferramentas em conjunto oferecem visibilidade profunda sobre riscos de credenciais no ambiente.

Estabelecendo Guardrails Preventivos: O Perímetro de Dados

Após compreender como identificar exposições, é hora de implementar controles preventivos. As políticas de controle de serviço (SCPs) e políticas de controle de recursos (RCPs) criam um perímetro de dados que garante apenas identidades confiáveis acessem recursos confiáveis de redes esperadas.

Para implementar guardrails preventivos é crucial estabelecer esse perímetro. Mais detalhes sobre perímetros de dados estão disponíveis na série de publicações sobre Estabelecendo um Perímetro de Dados na AWS.

Controles na Camada de Política

As políticas de controle de serviço podem negar que credenciais de usuários IAM sejam utilizadas fora de redes esperadas — como rangos CIDR corporativos ou VPCs específicas. Exemplos atualizados e repositórios de políticas estão disponíveis no repositório de exemplos de políticas de perímetro de dados.

Implementar esse perímetro de rede reduz risco quando credenciais são comprometidas — atores maliciosos tentando usar chaves roubadas de cafeterias ou casas serão bloqueados, limitando o impacto de acesso não autorizado.

Para defesa em profundidade adicional, as RCPs protegem dados controlando quais identidades podem acessar recursos. Por exemplo, permitindo acesso apenas a identidades dentro da organização e bloqueando identidades externas. Você pode consultar a lista de serviços AWS que suportam RCPs. O repositório no GitHub contém exemplos atualizados para uso.

Quando há plano para migrar de credenciais de longa duração, uma SCP pode negar criação e atualização de chaves de acesso, impondo uso de métodos de autenticação mais seguros como papéis IAM e acesso federado.

Controles de Rede: Protegendo o Ambiente de Execução

Além do perímetro de dados, proteger a infraestrutura de computação e rede onde chaves de acesso operam é essencial. O risco de exposição via ambientes comprometidos torna essa proteção crítica — atores maliciosos frequentemente atacam esses ambientes para obter acesso não autorizado.

Grupos de Segurança e Listas de Controle de Acesso à Rede

Proteções de segurança em nível de rede — funcionando como firewalls em múltiplos níveis, como instância ou subnet — ajudam contra acesso não autorizado. Restringir portas críticas como SSH (porta 22) e RDP (porta 3389) é essencial, pois são alvos primários de atores maliciosos. Portas administrativas abertas aumentam significativamente a superfície de ataque.

O AWS Systems Manager Session Manager oferece acesso remoto seguro sem expor portas de entrada, eliminando necessidade de bastion hosts ou gerenciamento de chaves SSH.

As listas de controle de acesso à rede (NACLs) bloqueiam acesso em nível de subnet atuando como filtros de pacote stateless nas bordas. Diferentemente de grupos de segurança que protegem instâncias individuais, NACLs protegem subnets inteiras com regras explícitas de permissão/negação para tráfego de entrada e saída. Quando implantadas como parte de defesa em profundidade, oferecem isolamento entre camadas de aplicação, bloqueiam padrões maliciosos nas bordas e mantêm proteção mesmo se outras camadas sejam comprometidas.

Para proteção de rede aprimorada, o AWS Network Firewall oferece defesa de perímetro em nível empresarial através de proteção abrangente de VPC. Combina sistemas de prevenção de intrusão, filtragem de domínio, inspeção profunda de pacotes e controles geográficos de IP, protegendo automaticamente contra ameaças emergentes usando inteligência global de ameaças coletada pela Amazon.

Integrando Network Firewall com AWS Transit Gateway, implementam-se políticas de segurança consistentes em VPCs e Zonas de Disponibilidade com gerenciamento centralizado. Para automatizar e escalar segurança de rede, o AWS Firewall Manager oferece administração centralizada de regras de Network Firewall e políticas de grupos de segurança, automatizando implantação de políticas comuns de grupo de segurança, limpando grupos não utilizados e remediando regras excessivamente permissivas em múltiplas contas.

Detecção de Vulnerabilidades e Exposição de Rede

Para identificar exposição de rede não intencional em escala, considere o Amazon Inspector. Realiza varredura contínua de cargas de trabalho AWS para vulnerabilidades de software e exposição de rede não intencional, ajudando identificar e remediar riscos antes de exploração.

As capacidades incluem vulnerabilidades de pacote (identificando pacotes de software expostos a CVEs comuns que atores podem explorar), vulnerabilidades de código (identificando linhas em código AWS Lambda exploráveis — como injeção de código, vazamento de dados, criptografia fraca — com detecção colaborativa com CodeGuru Security, listada na Biblioteca de Detectores da Amazon Q), e alcançabilidade de rede (mostrando se portas são acessíveis da internet via internet gateway, conexões de peering de VPC ou VPN através de gateway virtual).

Proteção com WAF

Complementando controles de segurança de rede, o AWS WAF adiciona uma camada de defesa filtrando tráfego web malicioso que poderia levar à exposição de credenciais. Oferece grupos de regras gerenciados para proteção contra acesso não autorizado:

O grupo de regras AWS WAF Fraud Control para prevenção de fraude em criação de contas (ACFP) usa tokens de requisição para coletar informações sobre navegador do cliente e interatividade humana. Detecta e gerencia tentativas em massa de criação de conta agregando requisições por endereço IP e sessão de cliente, além de dados como endereço físico e telefone. Também detecta e bloqueia novas contas usando credenciais comprometidas.

O grupo de regras AWS WAF Fraud Control para prevenção de sequestro de conta (ATP) oferece visibilidade e controle sobre tentativas anômalas de login e logins com credenciais roubadas. Para distribuições do Amazon CloudFront, além de inspecionar requisições de login, o ATP analisa respostas da aplicação para rastrear sucessos e falhas, verificando combinações de email e senha contra seu banco de dados de credenciais vazadas, atualizado regularmente conforme novas credenciais aparecem na dark web.

Práticas Operacionais: Mantendo a Higiene de Segurança

Para complementar essas camadas de proteção e manter postura de segurança contínua, implemente gerenciamento automatizado de credenciais através do Secrets Manager facilitando rotação e ciclo de vida de chaves de acesso adequados em todo o ambiente. Automação reduz erros humanos, garante atualizações de credenciais em tempo, limitando janela de exposição se comprometidas.

Recomenda-se rotação de chaves a cada 90 dias no mínimo. O Secrets Manager automatiza rotação conforme cronograma, garantindo atualizações regulares sem intervenção manual, além de centralizar armazenamento de segredos reduzindo likelihood de compartilhamento entre usuários. É possível configurar rotação automática via integração com Lambda.

Existe também uma solução disponível para implementar rotação automática de chaves de acesso em escala. Esse padrão utiliza templates do AWS CloudFormation disponíveis no repositório de rotação de chaves IAM.

Se não conseguir implementar rotação automática e precisar identificar rapidamente chaves que exigem rotação, o AWS Trusted Advisor oferece verificação de rotação de chaves de acesso IAM que identifica chaves ativas não rotacionadas nos últimos 90 dias, permitindo identificar quais chaves precisam de rotação manual.

Detectando Atividade Anômala em IAM

Enquanto medidas proativas para proteger infraestrutura IAM são cruciais, mecanismos robustos de detecção e alerta são igualmente importantes. Apesar de toda diligência, ameaças não previstas ou atividades não autorizadas podem ocorrer. Por isso, uma defesa em profundidade completa deve incluir capacidade de identificar e responder rapidamente a eventos anômalos relacionados a IAM.

O Amazon GuardDuty combina machine learning e inteligência de ameaças integrada para proteger contas AWS, cargas de trabalho e dados contra ameaças. A Detecção Estendida de Ameaças correlaciona múltiplos eventos em diferentes fontes de dados para identificar ameaças potenciais em ambientes AWS. Quando detecta sequências suspeitas, gera achados abrangentes. O sistema analisa atividades de API individuais como sinais fracos que, independentemente, podem não indicar riscos, mas quando observados em padrões específicos revelam potenciais problemas de segurança. Essa capacidade é ativada por padrão ao ativar GuardDuty em uma conta AWS, fornecendo proteção sem configuração adicional.

O achado de sequência de ataque específico relacionado a credenciais comprometidas é AttackSequence:IAM/CompromisedCredentials, marcado com severidade crítica. Ele informa que GuardDuty detectou sequência de ações suspeitas usando credenciais AWS afetando um ou mais recursos. Múltiplos comportamentos ameaçadores suspeitos e anômalos foram observados pelas mesmas credenciais, resultando em confiança elevada de que credenciais estão sendo mal utilizadas.

Conclusão

As práticas de segurança apresentadas oferecem abordagem abrangente e estratificada para mitigar riscos associados a credenciais de longa duração. Implementando varredura proativa de código, rotação automatizada de chaves, controles em nível de rede, restrições de perímetro de dados e detecção de ameaças, é possível reduzir significativamente a superfície de ataque e proteger melhor recursos AWS até que migração completa para credenciais temporárias seja viável.

Embora as recomendações forneçam conjunto amplo de controles posicionando organizações em boa postura de segurança, podem existir medidas adicionais dependendo de necessidades e perfil de risco específicos de cada ambiente. O ponto-chave é adotar abordagem holística e em camadas para gerenciamento e proteção de credenciais.

É importante reconhecer que credenciais de longa duração inerentemente carregam riscos. Mesmo com melhores práticas rigorosas e controles abrangentes, possibilidade de comprometimento não pode ser completamente eliminada. Organizações devem avaliar sua postura de segurança e priorizar transição para credenciais temporárias através de papéis IAM e federação sempre que possível. A AWS oferece suporte para ajudar nessa jornada.

Fonte

Practical steps to minimize key exposure using AWS Security Services (https://aws.amazon.com/blogs/security/practical-steps-to-minimize-key-exposure-using-aws-security-services/)

Uma plataforma integrada para ciência de dados

A AWS anunciou a disponibilidade do Amazon Athena para Apache Spark nos notebooks do Amazon SageMaker. Essa integração reúne uma nova experiência de notebooks com processamento serverless de Spark em um ambiente de trabalho unificado.

Agora, engenheiros de dados, analistas e cientistas de dados podem executar múltiplas tarefas em um único lugar: consultar dados, escrever código Python, desenvolver jobs, treinar modelos de machine learning, visualizar informações e trabalhar com inteligência artificial. Tudo isso sem a necessidade de gerenciar infraestrutura ou se preocupar com cobranças por segundo mantendo recursos ociosos.

Escalabilidade e performance sob demanda

O Athena para Apache Spark escala em segundos, adaptando-se a qualquer tipo de workload. Seja uma consulta interativa rápida ou um processamento de dados em escala petabyte, a plataforma responde dinamicamente às demandas de cada situação.

O serviço executa a versão 3.5.6 do Spark, o mesmo motor de alto desempenho disponível em toda a AWS. Essa versão foi otimizada para trabalhar com formatos abertos de tabelas, incluindo Apache Iceberg e Delta Lake, oferecendo flexibilidade para diferentes arquiteturas de dados.

Segurança e ferramentas de desenvolvimento

A AWS implementou recursos avançados de depuração e monitoramento em tempo real através da interface Spark UI. A comunicação segura entre clusters interativos agora acontece via Spark Connect, estabelecendo um padrão de segurança mais robusto.

Um aspecto importante para governança é que o Athena para Spark agora respeita os controles de acesso em nível de tabela definidos no AWS Lake Formation. Isso significa que as políticas de segurança e permissões de acesso aos dados são aplicadas automaticamente, sem configurações adicionais.

Disponibilidade regional

O serviço está disponível em múltiplas regiões ao redor do mundo: US East (Ohio), US East (N. Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Mumbai), Asia Pacific (Tokyo), Asia Pacific (Singapore) e Asia Pacific (Sydney).

Próximos passos

Para explorar essa integração, é recomendável consultar a documentação sobre versões do motor Spark 3.5 e visitar o blog de notícias da AWS para detalhes adicionais. A documentação do Amazon SageMaker oferece informações completas sobre a plataforma.

Para começar a utilizar, há um guia de primeiros passos disponível especificamente para explorar essas funcionalidades a partir dos notebooks do Amazon SageMaker.

Fonte

Amazon Athena for Apache Spark is now available in Amazon SageMaker notebooks (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-athena-apache-spark-sagemaker-notebooks/)