Blog

  • NVIDIA Nemotron 3 Nano Omni já está disponível no Amazon SageMaker JumpStart

    O que é o NVIDIA Nemotron 3 Nano Omni?

    A NVIDIA disponibilizou o modelo Nemotron 3 Nano Omni no Amazon SageMaker JumpStart com disponibilidade imediata desde o dia zero do lançamento. Trata-se de um Modelo de Linguagem Grande (LLM) multimodal aberto, com 30 bilhões de parâmetros totais e 3 bilhões de parâmetros ativos — uma configuração chamada de 30B A3B.

    O modelo é construído sobre uma arquitetura híbrida chamada Mamba2 Transformer com Mistura de Especialistas (MoE), que combina três componentes principais:

    • Nemotron 3 Nano LLM — a espinha dorsal de linguagem
    • CRADIO v4-H — o encoder de visão para imagens e vídeos
    • Parakeet — o encoder de fala para transcrição e compreensão de áudio

    Essa arquitetura unificada aceita vídeo, áudio, imagens e texto como entrada e gera texto como saída. O modelo suporta um contexto de 131 mil tokens, raciocínio em cadeia de pensamento, chamada de ferramentas, saída em JSON e timestamps em nível de palavra para tarefas de transcrição. No SageMaker JumpStart, ele está disponível em precisão FP8, equilibrando acurácia e eficiência para cargas de trabalho empresariais. A licença é a NVIDIA Open Model Agreement, permitindo uso comercial.

    Por que um modelo multimodal unificado importa?

    Fluxos de trabalho de agentes empresariais são, por natureza, multimodais. Um agente precisa interpretar telas, documentos, áudio, vídeo e texto — frequentemente dentro do mesmo ciclo de raciocínio. O problema é que a maioria dos sistemas agênticos atuais costura vários modelos separados para visão, fala e linguagem. Isso gera:

    • Aumento de latência por múltiplas passagens de inferência
    • Complexidade na orquestração e no tratamento de erros
    • Fragmentação de contexto entre modalidades
    • Custos e pontos de falha amplificados ao longo do tempo

    O Nemotron 3 Nano Omni resolve esse problema funcionando como o sub-agente de percepção e contexto multimodal em um sistema de agentes. Ele fornece ao sistema de agentes “olhos e ouvidos”: lê telas, interpreta documentos, transcreve fala e analisa vídeo — tudo mantendo um contexto multimodal convergido ao longo dos ciclos de raciocínio.

    Para quem está construindo arquiteturas agênticas, isso significa colapsar saltos de inferência, lógica de orquestração e sobrecarga de sincronização entre modelos em uma única chamada de modelo.

    Formatos de entrada suportados

    • Vídeo: mp4 — até 2 minutos, até 256 frames
    • Áudio: wav, mp3 — até 1 hora, taxa de amostragem de 8kHz ou superior
    • Imagem: JPEG, PNG (RGB) — resolução padrão
    • Texto: String — até 131K de contexto

    Casos de uso empresariais

    Agentes de uso computacional

    O Nemotron 3 Nano Omni alimenta o loop de percepção de agentes que navegam em Interfaces Gráficas de Usuário (GUI). Ele lê telas, entende o estado da interface ao longo do tempo e valida resultados, enquanto agentes de execução cuidam das ações. Isso elimina a necessidade de pipelines de percepção separados. Aplicações práticas incluem dashboards de gerenciamento de incidentes, busca agêntica, automação de navegador e agentes de fluxo de trabalho de e-mail.

    Inteligência documental

    O modelo interpreta documentos, gráficos, tabelas, capturas de tela e entradas de mídia mista, permitindo que agentes raciocinem de forma coerente sobre estrutura visual e conteúdo textual. Isso é fundamental para análises empresariais e fluxos de conformidade envolvendo contratos, declarações de trabalho, documentos financeiros e literatura científica.

    Agentes de compreensão de áudio e vídeo

    Para fluxos de atendimento ao cliente, pesquisa e monitoramento, o Nemotron 3 Nano Omni mantém contexto contínuo de áudio e vídeo. Ele conecta o que foi dito, mostrado e documentado em um único fluxo de raciocínio. Isso viabiliza aplicações como análise de gravações de reuniões, gerenciamento de ativos de mídia e entretenimento, verificação de pedidos em drive-thru e revisão de vídeos de atendimento ao cliente.

    Como fazer o deploy no SageMaker JumpStart

    O deploy do Nemotron 3 Nano Omni pelo Amazon SageMaker JumpStart pode ser feito de duas formas. O JumpStart cuida da infraestrutura, dos containers de inferência otimizados e do download dos artefatos do modelo automaticamente.

    Pré-requisitos

    Deploy pelo SageMaker Studio

    • Abra o Amazon SageMaker Studio
    • No painel de navegação esquerdo, selecione JumpStart
    • Pesquise por Nemotron 3 Nano Omni
    • Selecione o card do modelo e clique em Deploy
    • Configure o tipo de instância e as configurações de deploy
    • Clique em Deploy para criar o endpoint

    Deploy pelo SDK Python do SageMaker

    Também é possível fazer o deploy de forma programática usando o SDK Python do SageMaker:

    from sagemaker.jumpstart.model import JumpStartModel
    
    model = JumpStartModel(
        model_id="huggingface-vlm-nvidia-nemotron3-nano-omni-30ba3b-reasoning-fp8",
        role="",
    )
    
    predictor = model.deploy(
        accept_eula=True,
    )

    Executando inferência

    Compreensão de imagem

    import base64
    
    def encode_image(image_path):
        with open(image_path, "rb") as f:
            return base64.b64encode(f.read()).decode("utf-8")
    
    image_b64 = encode_image("example.jpg")
    
    payload = {
        "messages": [{
            "role": "user",
            "content": [
                {"type": "text", "text": "Describe this image in detail."},
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}},
            ],
        }],
        "max_tokens": 1024,
        "temperature": 0.2,
    }
    
    response = predictor.predict(payload)
    print(response["choices"][0]["message"]["content"])

    Compreensão de vídeo com raciocínio

    import base64
    
    def encode_video(video_path):
        with open(video_path, "rb") as f:
            return base64.b64encode(f.read()).decode("utf-8")
    
    video_b64 = encode_video("meeting_recording.mp4")
    
    payload = {
        "messages": [{
            "role": "user",
            "content": [
                {"type": "video_url", "video_url": {"url": f"data:video/mp4;base64,{video_b64}"}},
                {"type": "text", "text": "Summarize the key discussion points."},
            ],
        }],
        "max_tokens": 20480,
        "temperature": 0.6,
        "top_p": 0.95,
    }
    
    response = predictor.predict(payload)
    print(response["choices"][0]["message"]["content"])

    Transcrição de áudio

    import base64
    
    def encode_audio(audio_path):
        with open(audio_path, "rb") as f:
            return base64.b64encode(f.read()).decode("utf-8")
    
    audio_b64 = encode_audio("customer_call.wav")
    
    payload = {
        "messages": [{
            "role": "user",
            "content": [
                {"type": "audio_url", "audio_url": {"url": f"data:audio/wav;base64,{audio_b64}"}},
                {"type": "text", "text": "Transcribe this audio and identify key action items."},
            ],
        }],
        "max_tokens": 1024,
        "temperature": 0.2,
    }
    
    response = predictor.predict(payload)
    print(response["choices"][0]["message"]["content"])

    Parâmetros de inferência recomendados

    Os valores recomendados variam de acordo com o modo de inferência:

    • Modo Thinking (raciocínio): temperature 0.6, top_p 0.95, max_tokens 20480 — para raciocínio complexo
    • Modo Instruct: temperature 0.2, max_tokens 1024 — para tarefas gerais e Reconhecimento Automático de Fala (ASR)

    Para tarefas que envolvem raciocínio e compreensão complexa, recomenda-se habilitar o modo thinking. Para transcrição e tarefas diretas, o modo instruct oferece respostas mais rápidas.

    Limpeza de recursos

    Para evitar cobranças desnecessárias, exclua o endpoint do SageMaker ao terminar:

    predictor.delete_endpoint()

    Conclusão

    O NVIDIA Nemotron 3 Nano Omni representa um avanço relevante em inteligência multimodal disponível no Amazon SageMaker JumpStart. Ao unificar compreensão de vídeo, áudio, imagem e texto em um único modelo eficiente, ele simplifica o desenvolvimento de aplicações agênticas empresariais e entrega, segundo a NVIDIA, até 9x mais throughput em comparação com modelos omni abertos alternativos.

    Seja para construir agentes que navegam em interfaces gráficas, pipelines de inteligência documental para fluxos de conformidade, ou sistemas de análise de áudio e vídeo para atendimento ao cliente, o Nemotron 3 Nano Omni oferece a camada de percepção necessária em uma única chamada de modelo. Para mais informações sobre o modelo, acesse a página do NVIDIA Nemotron no Hugging Face.

    Fonte

    NVIDIA Nemotron 3 Nano Omni model now available on Amazon SageMaker JumpStart (https://aws.amazon.com/blogs/machine-learning/nvidia-nemotron-3-nano-omni-model-now-available-on-amazon-sagemaker-jumpstart/)

  • Migrando um agente de texto para assistente de voz com Amazon Nova 2 Sonic

    Por que migrar de texto para voz não é trivial

    Transformar um agente de texto em um assistente de voz parece simples à primeira vista — afinal, a lógica de negócio já existe, certo? A AWS, no entanto, deixa claro que essa visão subestima as diferenças fundamentais entre os dois modelos de interação. Setores como finanças, saúde, educação e varejo estão explorando o Amazon Nova 2 Sonic para viabilizar interações de fala em tempo real, e entender o que muda na arquitetura é o primeiro passo para uma migração bem-sucedida.

    A AWS também disponibilizou uma Skill no repositório de exemplos do Nova que funciona com IDEs de IA como Kiro e Claude Code para converter automaticamente um agente de texto em agente de voz.

    As diferenças entre agentes de texto e de voz

    Antes de qualquer decisão arquitetural, é preciso entender em quais dimensões esses dois tipos de agente se comportam de forma diferente:

    • Entrada do usuário: No texto, o usuário digita no próprio ritmo, rola a tela e copia conteúdo. Na voz, tudo acontece em tempo real, com possibilidade de interrupção (barge-in) e pausas que carregam significado.
    • Estilo de resposta: Agentes de texto entregam parágrafos, listas, tabelas e links de uma vez. Agentes de voz precisam de frases curtas, uma informação por vez, com confirmações intermediárias (“Quer que eu continue?”).
    • Tolerância à latência: No texto, alguns segundos de espera são aceitáveis com um indicador de carregamento. Na voz, o silêncio parece falha de conexão — a resposta precisa chegar em centenas de milissegundos.
    • Gerenciamento de turnos: Texto é estritamente sequencial: o usuário envia, o agente responde. Voz é fluida, com sobreposição de fala, detecção de atividade de voz (VAD) e suporte a interrupções.
    • Transporte: Agentes de texto usam HTTP/REST ou Server-Sent Events (SSE). Agentes de voz exigem conexão bidirecional persistente, como WebSocket ou WebRTC.

    Design de resposta: menos é mais na voz

    Um exemplo prático ilustra bem a diferença. Um agente bancário de texto poderia retornar um resumo completo de todas as contas de uma vez, com saldos formatados em lista. Já um agente de voz deve quebrar essa informação em partes, guiando o usuário ativamente:

    Texto: “Aqui está o resumo da sua conta: Corrente (****4521): R$ 3.245,67 | Poupança (****8903): R$ 12.450,00 | Cartão de Crédito (****2187): -R$ 1.823,45 (vencimento: 15 de março)”

    Voz: “Você tem três contas. Sua conta corrente termina em 4521 com saldo de três mil duzentos e quarenta e cinco reais. Quer que eu continue com as outras ou prefere detalhes desta?”

    O agente de voz fragmenta a informação e confirma antes de prosseguir, adotando um estilo de conversa autônomo que guia o usuário em vez de despejar tudo de uma vez.

    Latência e chamadas de ferramentas

    No texto, múltiplas chamadas sequenciais a ferramentas são toleráveis. Na voz, cada chamada adiciona um silêncio perceptível. O Amazon Nova 2 Sonic suporta chamadas assíncronas de ferramentas, o que significa que a conversa continua naturalmente enquanto as ferramentas processam em segundo plano. O modelo aceita novas entradas, pode executar múltiplas ferramentas em paralelo e se adapta caso o usuário mude de assunto no meio do processo.

    Arquitetura da migração: três componentes, três evoluções

    A AWS divide a arquitetura de um agente de texto em três componentes principais, e cada um evolui de forma diferente na transição para voz:

    Imagem original — fonte: Aws

    1. A aplicação cliente

    O cliente de um agente de texto geralmente se comunica via REST ou streaming HTTP unidirecional — algo relativamente simples de implementar. Um cliente de voz, por outro lado, exige conexão bidirecional persistente, codificação e decodificação de áudio, lógica de barge-in, controle de ruído e exibição de transcrição. Isso frequentemente significa refatoração completa ou reescrita do componente. Por exemplo, um protótipo construído com Streamlit provavelmente precisaria ser reconstruído com um framework como React para suportar conexões bidirecionais. A AWS disponibiliza um exemplo de cliente web leve em React com WebSocket.

    2. O orquestrador

    O orquestrador é o núcleo de qualquer agente — gerencia o system prompt, seleciona ferramentas ou sub-agentes e mantém o contexto da conversa. Em agentes de texto, ele conecta o cliente ao modelo de raciocínio e às ferramentas. Em agentes de voz, as mesmas responsabilidades se mantêm, mas adicionam streaming de áudio, Reconhecimento Automático de Fala (ASR), Detecção de Atividade de Voz (VAD) e Síntese de Fala (TTS).

    O Amazon Nova 2 Sonic oferece uma interface de streaming bidirecional que unifica todas essas funcionalidades. Em vez de encadear componentes separados de ASR → Modelo de Linguagem Grande (LLM) → TTS, o Sonic integra reconhecimento de fala, raciocínio, uso de ferramentas e síntese de fala em um único modelo. Isso permite reutilizar prompts e ferramentas existentes, simplificando a arquitetura e reduzindo a latência.

    Imagem original — fonte: Aws

    3. A camada de lógica de negócio

    As ferramentas que conectam o agente aos sistemas de negócio — APIs, bancos de dados, pipelines de Geração Aumentada por Recuperação (RAG), sub-agentes — podem ser reaproveitadas com pouca ou nenhuma alteração de código. A integração usa protocolos como Protocolo de Contexto de Modelo (MCP), Agente-para-Agente (A2A) e HTTP padrão.

    Exemplo prático com Strands Agents

    A AWS demonstra a migração usando o framework Strands Agents. O ponto central é que o estilo de código para agentes de texto e de voz é muito parecido. Abaixo, o exemplo de ferramentas compartilhadas entre os dois tipos de agente:

    from strands import Agent, tool
    from strands.models import BedrockModel
    
    # ---- Mock tools will be used in both text and voice agents ----
    @tool
    def authenticate_customer(account_id: str, date_of_birth: str) -> str:
        """Verify customer identity and return an auth token."""
        # In real implementation, call your auth service / API
        if account_id == "123456":
            return "AUTH_TOKEN_ABC123"
        return "Authentication failed"
    
    @tool
    def get_account_balance(auth_token: str) -> str:
        """Return the customer's current account balance."""
        if auth_token == "AUTH_TOKEN_ABC123":
            return "Your current checking account balance is $5,420."
        return "Unauthorized request"
    
    @tool
    def get_recent_transactions(auth_token: str) -> str:
        """Return recent transactions."""
        if auth_token == "AUTH_TOKEN_ABC123":
            return "Recent transactions: $45 groceries, $120 utilities, $18 coffee."
        return "Unauthorized request"

    O agente de texto com Amazon Nova 2 Lite como LLM:

    # ---- Nova 2 Lite model ----
    model = BedrockModel(model_id="amazon.nova-2-lite-v1:0")
    
    # ---- Banking assistant text agent ----
    bank_agent = Agent(
        model=model,
        system_prompt="""You are a banking assistant. Answer user questions about account balances, recent transactions accurately. Always validate user identity before providing sensitive information.
    """,
        tools=[authenticate_customer, get_account_balance, get_recent_transactions],
    )

    E o agente de voz usando o Strands BidiAgent com Nova 2 Sonic, reaproveitando as mesmas ferramentas:

    # voice_orchestrator.py — BidiAgent with sub-agents as tools
    from strands.experimental.bidi.agent import BidiAgent
    from strands.experimental.bidi.models.nova_sonic import BidiNovaSonicModel
    
    # ---- Nova 2 Sonic model ----
    model = BidiNovaSonicModel(
        region="us-east-1",
        model_id="amazon.nova-2-sonic-v1:0",
        provider_config={"audio": {"voice": "tiffany", "input_sample_rate": 16000, "output_sample_rate": 16000}},
    )
    
    # ---- Banking assistant voice agent ----
    agent = BidiAgent(
        model=model,
        system_prompt="""
    You are a banking assistant. Speak naturally and answer questions about account balances, recent transactions. Confirm the customer's identity before sharing sensitive details. Use short, clear responses and acknowledge when retrieving data.
    """,
        tools=[authenticate_customer, get_account_balance, get_recent_transactions],
    )
    
    await agent.run(inputs=[ws_input], outputs=[ws_output])

    Adaptando o system prompt para voz

    O system prompt é a base tanto de agentes de texto quanto de voz — define o papel, o tom e as restrições do agente. Na transição para voz, ele precisa ser adaptado para o contexto de áudio em tempo real: mais conciso, conversacional, com orientações divididas em etapas menores e considerando a latência e o contexto de múltiplos turnos.

    Exemplo de adaptação para o agente bancário:

    • Prompt de texto: “You are a banking assistant. Answer user questions about account balances, recent transactions accurately. Always validate user identity before providing sensitive information.”
    • Prompt adaptado para voz: “You are a banking assistant. Speak naturally and answer questions about account balances, recent transactions. Confirm the customer’s identity before sharing sensitive details. Use short, clear responses and acknowledge when retrieving data.”

    No orquestrador de voz com Nova 2 Sonic, o próprio modelo gerencia o system prompt, a seleção de ferramentas e o contexto da sessão — não é mais necessário um LLM separado para raciocínio no nível do orquestrador.

    Reutilizando sub-agentes com ajustes para voz

    Se a arquitetura atual já usa múltiplos agentes especializados, eles podem ser reaproveitados para voz com alguns ajustes. O diagrama abaixo mostra um assistente bancário onde o orquestrador de voz aciona sub-agentes de autenticação e de consultas de hipoteca:

    Imagem original — fonte: Aws

    Os principais ajustes recomendados pela AWS são:

    • Respostas mais curtas: Um sub-agente de texto pode retornar um parágrafo detalhado. Para voz, o ideal é 1 a 2 frases que o orquestrador possa falar naturalmente. A instrução no system prompt do sub-agente deve ser algo como “Resuma em 1 a 2 frases concisas”.
    • Redução de latência: Escolha modelos menores e mais rápidos para sub-agentes — por exemplo, começar com Nova 2 Lite em vez de um modelo maior. Em conversas de voz, cada inferência adicional gera uma pausa perceptível. Para o Nova 2 Lite, a recomendação é limitar ou evitar o modo de raciocínio estendido para reduzir latência. Mais detalhes no Amazon Nova Developer Guide para Amazon Nova 2.
    • Menor verbosidade nos resultados de ferramentas: Sub-agentes que retornam grandes payloads JSON aumentam a latência, podem reduzir a precisão e expor dados sensíveis. Respostas enxutas e direcionadas são críticas em experiências de voz.
    • Mensagens de preenchimento: Com o Nova 2 Sonic, é possível fazer chamadas assíncronas de ferramentas e personalizar mensagens intermediárias, mantendo o usuário engajado enquanto o agente processa tarefas mais longas.

    A maioria desses ajustes envolve mudanças de prompt e configuração, não modificações arquiteturais. As ferramentas, a lógica de negócio e o deployment dos sub-agentes permanecem os mesmos. Para mais padrões de arquitetura e boas práticas de gerenciamento de latência em agentes de voz, consulte este post.

    Conclusão

    Migrar um agente de texto para um assistente de voz não é apenas adicionar uma camada de áudio. O modelo de interação é fundamentalmente diferente — do design de resposta ao orçamento de latência, passando pelo gerenciamento de turnos. Com uma arquitetura multi-agente bem estruturada e o Amazon Nova 2 Sonic, a camada de lógica de negócio permanece intacta, e a transição se torna muito mais gerenciável.

    Para um exemplo funcional completo de agente de voz com Amazon Nova 2 Sonic, a AWS disponibiliza o Amazon Nova 2 Sonic no Strands BidiAgent. Documentação e recursos adicionais:

    Fonte

    Migrating a text agent to a voice assistant with Amazon Nova 2 Sonic (https://aws.amazon.com/blogs/machine-learning/migrating-a-text-agent-to-a-voice-assistant-with-amazon-nova-2-sonic/)

  • O que a atualização de março de 2026 do Catálogo de Técnicas de Ameaças significa para seu ambiente AWS

    O Catálogo de Técnicas de Ameaças da AWS ganhou três novas entradas

    A equipe de Resposta a Incidentes de Clientes da AWS (AWS CIRT — Customer Incident Response Team) mantém um repositório público chamado Catálogo de Técnicas de Ameaças para AWS (TTC) — um documento vivo que documenta padrões reais de ataque observados em engajamentos de resposta a incidentes. A ideia é simples e valiosa: em vez de guardar esse conhecimento internamente, a AWS o disponibiliza para que qualquer equipe de segurança possa se preparar antes de precisar lidar com um incidente.

    A atualização de março de 2026 traz três novas entradas, todas com algo em comum: exploram comportamentos normais e esperados da plataforma para manter acesso não autorizado ou dificultar a recuperação. Veja o que mudou e por que isso importa para o seu ambiente.

    O que está sendo observado na prática

    Abuso de refresh tokens do Cognito: a persistência silenciosa

    O Amazon Cognito usa refresh tokens para que aplicações possam obter novos tokens de acesso sem exigir que o usuário faça login novamente. Por padrão, esses tokens têm validade de 30 dias — e podem ser configurados com validade de até 10 anos.

    O problema documentado na entrada T1098.A006 é o seguinte: quando um agente malicioso obtém um refresh token válido — seja por roubo de credenciais, comprometimento de armazenamento no lado do cliente ou abuso de permissões elevadas — ele pode chamar a API cognito-idp:GetTokensFromRefreshToken para gerar novos tokens silenciosamente, mantendo acesso ativo por toda a janela de validade do token.

    O detalhe mais perigoso: o usuário legítimo continua usando a aplicação normalmente, porque sua sessão também renova tokens de forma independente. As chamadas do invasor não invalidam a sessão original. Isso cria um acesso paralelo e persistente, completamente invisível para o usuário.

    Em ambientes onde a rotação de refresh tokens não está habilitada, o mesmo token pode ser reutilizado indefinidamente dentro do período de validade. Equipes de resposta que acreditaram ter contido o comprometimento inicial já descobriram, semanas depois, que o acesso não autorizado continuava ativo por meio de um refresh token que nem sabiam que existia.

    Mitigação recomendada: habilitar a rotação de refresh tokens e reduzir o tempo de vida desses tokens são as ações mais diretas para reduzir esse risco.

    Exclusão de imagens AMI: atacando a capacidade de recuperação

    As Imagens de Máquina da Amazon (AMI — Amazon Machine Images) são peças centrais em estratégias de recuperação de desastres. Elas contêm o sistema operacional, configurações de aplicação e tudo o que é necessário para reconstruir a infraestrutura. Exatamente por isso, elas se tornaram alvo.

    A técnica documentada em T1485.A002 envolve o uso da API ec2:DeregisterImage para remover AMIs e dificultar — ou inviabilizar — a recuperação após um incidente. Por padrão, quando uma AMI é desregistrada, ela simplesmente some. Regras de retenção no Recycle Bin permitem recuperar a imagem, mas apenas se essa funcionalidade tiver sido explicitamente habilitada antes do incidente.

    Em casos reais acompanhados pela AWS CIRT, o impacto foi além da perda imediata: os agentes maliciosos também removeram as imagens “golden” — aquelas versões base e validadas que as equipes planejavam usar para restaurar os sistemas. Sem elas, a recuperação se torna muito mais lenta e complexa.

    Mitigação recomendada: habilitar regras de retenção no Recycle Bin para AMIs críticas. O TTC fornece orientações detalhadas sobre como detectar e mitigar essa técnica.

    Roles adicionais na nuvem: o ponto cego nas políticas de confiança

    A entrada T1098.003: Roles Adicionais na Nuvem foi atualizada para incluir o rastreamento da chamada de API UpdateAssumeRolePolicy.

    O contexto é relevante: muitas equipes configuram alertas para detectar a criação de novas roles via iam:CreateRole. Para contornar esse monitoramento, agentes maliciosos com permissões suficientes passaram a modificar a política de confiança de uma role já existente usando UpdateAssumeRolePolicy. Com isso, eles adicionam uma conta externa ou uma identidade que controlam como principal confiável — sem criar nenhuma role nova, sem criar nenhuma política nova.

    A role existente simplesmente passa a confiar em um novo principal, que o invasor pode assumir quando quiser. Nenhum alarme dispara. Nenhuma anomalia óbvia aparece. A modificação se mistura ao volume normal de operações do AWS Identity and Access Management (IAM), especialmente em ambientes com grande número de roles onde mudanças em políticas de confiança não são monitoradas ativamente.

    Mitigação recomendada: incluir UpdateAssumeRolePolicy no monitoramento e configurar alertas para modificações em políticas de confiança de roles existentes.

    A tendência que conecta os três casos

    Há um fio condutor claro nas três atualizações: agentes maliciosos estão usando comportamentos sutis, padrões ou inesperados para escapar da detecção. Refresh tokens funcionando exatamente como foram projetados. Desregistro de AMIs concluindo sem nenhum bloqueio. Políticas de confiança sendo modificadas por chamadas de API completamente legítimas.

    Essas ações provavelmente não dispararão alarmes na maioria dos ambientes — porque parecem operações normais. Essa é uma mudança de postura que merece atenção. Em vez de exploits inéditos ou zero-days, as técnicas catalogadas refletem agentes que entendem como os serviços de nuvem funcionam e usam esse conhecimento para se esconder à vista de todos.

    A implicação para equipes de segurança é direta: as estratégias de prevenção e detecção precisam evoluir além do monitoramento de ações obviamente maliciosas. É preciso observar ações legítimas acontecendo em contexto ilegítimo — a chamada de API certa, feita pelo principal errado, no momento errado.

    Checklist: o que revisar agora no seu ambiente

    A AWS recomenda que as equipes revisem as entradas relevantes do TTC e avaliem se o monitoramento atual conseguiria detectar esses padrões:

    • T1098.A006: Abuso de Refresh Token do Cognito — Você está monitorando chamadas de cognito-idp:GetTokensFromRefreshToken vindas de fontes inesperadas? A rotação de refresh tokens está habilitada?
    • T1485.A002: Exclusão de Imagem AMI — Você tem regras de retenção no Recycle Bin protegendo suas AMIs críticas? Você saberia se uma AMI de produção fosse desregistrada fora de uma janela de manutenção?
    • T1098.003: Roles Adicionais na Nuvem — Modificações em políticas de confiança são rastreadas e geram alertas? Uma conta externa poderia ser adicionada a uma role existente sem que ninguém percebesse?

    Todas essas técnicas deixam rastros no AWS CloudTrail, e o TTC fornece orientações específicas sobre o que monitorar e como responder.

    Por que o TTC existe e como usá-lo

    O Catálogo de Técnicas de Ameaças para AWS parte de uma premissa simples: os padrões observados em engajamentos de resposta a incidentes não deveriam ficar guardados a sete chaves. Quando uma técnica se repete em múltiplos clientes, documentá-la e torná-la pública é a forma mais eficaz de permitir que outras equipes se preparem antes de se encontrarem no meio de um incidente.

    A recomendação da AWS é que equipes de segurança revisem o catálogo regularmente, incorporem suas técnicas em exercícios de modelagem de ameaças e o utilizem como vocabulário compartilhado para discutir ameaças específicas de ambientes de nuvem. O catálogo continuará evoluindo conforme novos padrões forem observados em campo.

    Recursos adicionais

    Fonte

    What the March 2026 Threat Technique Catalog update means for your AWS environment (https://aws.amazon.com/blogs/security/what-the-march-2026-threat-technique-catalog-update-means-for-your-aws-environment/)

  • Amazon Connect Talent: solução de contratação com IA agora em Preview

    O que é o Amazon Connect Talent?

    A AWS anunciou a disponibilidade em Preview do Amazon Connect Talent, uma solução de recrutamento com inteligência artificial voltada para equipes de aquisição de talentos que precisam avaliar grandes volumes de candidatos com consistência e agilidade.

    Segundo a AWS, o serviço foi desenvolvido com base em décadas de ciência de contratação da própria Amazon — o que significa que os modelos e metodologias por trás das avaliações não partem do zero, mas de uma base bastante consolidada de práticas internas.

    Como o serviço funciona na prática

    O Amazon Connect Talent utiliza agentes de IA para conduzir três etapas centrais do processo seletivo de forma automatizada:

    • Entrevistas por voz estruturadas: conduzidas por IA com perguntas adaptativas, sem necessidade de um recrutador humano presente no momento da entrevista.
    • Avaliações baseadas em ciência: testes de competências aplicados de forma padronizada a todos os candidatos.
    • Pontuação consistente: os candidatos são avaliados com critérios uniformes, reduzindo variações subjetivas no processo.

    Do lado dos candidatos, o processo pode ser feito a qualquer hora do dia, sete dias por semana, a partir de qualquer dispositivo — o que amplia bastante o alcance geográfico e de horário para empresas que recrutam em escala.

    O que o recrutador recebe ao final

    Após as entrevistas e avaliações, o recrutador tem acesso a um painel completo com:

    • Pontuações dos candidatos
    • Transcrições das entrevistas
    • Avaliações detalhadas geradas pelo agente de IA

    A proposta é que o recrutador humano foque nas decisões estratégicas — escolher entre os finalistas, conduzir entrevistas aprofundadas — enquanto a triagem inicial fica a cargo da IA.

    Capacidades disponíveis no Preview

    A AWS detalhou o conjunto de funcionalidades que já está disponível nesta fase de Preview:

    • Avaliações de habilidades conduzidas por IA
    • Entrevistas por voz com perguntas adaptativas
    • Portal do candidato mobile-first com personalização de marca
    • Painel completo para recrutadores
    • Ferramentas de onboarding para administradores do sistema
    • Integrações com sistemas de Rastreamento de Candidatos (ATS — Applicant Tracking System) para implantação rápida

    Escala e disponibilidade regional

    Um dos pontos destacados pela AWS é a capacidade de escala: o Amazon Connect Talent consegue avaliar centenas de candidatos simultaneamente, o que o torna especialmente útil em períodos de contratação intensa — como expansões de equipe, sazonalidades ou grandes processos seletivos corporativos.

    Atualmente, o serviço está disponível nas regiões AWS US East (N. Virginia) e AWS US West (Oregon). Para saber mais e solicitar acesso ao Preview, a AWS disponibilizou a página oficial do Amazon Connect Talent.

    Fonte

    Amazon Connect Talent for AI-powered hiring (now available in Preview) (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-connect-talent-ai-powered/)

  • Como Construir Agentes de IA com Strands SDK, SageMaker AI e MLflow

    Por que usar modelos no SageMaker AI em vez de serviços gerenciados?

    Empresas que constroem agentes de IA frequentemente precisam de mais do que os serviços gerenciados de modelos de fundação (FM — Foundation Model) conseguem oferecer. Requisitos como controle preciso de desempenho, otimização de custos em escala, conformidade regulatória, residência de dados e configurações de rede que se integrem às arquiteturas de segurança existentes são comuns em ambientes corporativos.

    O Amazon SageMaker AI atende a esses requisitos ao dar às organizações controle sobre recursos de computação, comportamento de escalabilidade e posicionamento de infraestrutura — tudo isso aproveitando a camada operacional gerenciada da AWS. Os modelos implantados via SageMaker AI podem alimentar agentes de IA, lidar com cargas de trabalho conversacionais e se integrar com frameworks de orquestração, assim como os FMs disponíveis no Amazon Bedrock. A diferença fundamental é que a organização mantém o controle arquitetural sobre como e onde a inferência acontece.

    Neste artigo, a AWS demonstra como construir agentes de IA usando o Strands Agents SDK com modelos implantados em endpoints do SageMaker AI. O tutorial cobre o deploy de modelos de fundação via SageMaker JumpStart, a integração com o Strands Agents, a configuração de observabilidade com MLflow e a implementação de testes A/B entre variantes de modelos.

    Visão geral das ferramentas envolvidas

    O Strands Agents SDK é um SDK de código aberto que adota uma abordagem orientada a modelos para construir e executar agentes de IA com poucas linhas de código. Ele escala desde casos de uso simples até os mais complexos, e do desenvolvimento local até o deploy em produção.

    O Amazon SageMaker JumpStart é um hub de aprendizado de máquina (ML — Machine Learning) que acelera a jornada de ML das equipes. Com ele, é possível avaliar, comparar e selecionar FMs rapidamente com base em métricas de qualidade e responsabilidade predefinidas.

    O SageMaker AI MLflow é uma funcionalidade gerenciada que simplifica o ciclo de vida de ML por meio de rastreamento de experimentos, versionamento de modelos e gerenciamento de deploy.

    Um Jupyter Notebook com o código completo está disponível no repositório no GitHub.

    Construindo o primeiro agente com Strands

    Um agente Strands combina um modelo, um prompt de sistema e um conjunto de ferramentas. O SDK oferece suporte a diversos provedores de modelos, incluindo o Amazon SageMaker AI, e disponibiliza ferramentas comuns por meio do pacote strands-agent-tools. O trecho de código abaixo mostra como criar um primeiro agente usando o Strands Agents SDK com o modelo Claude 4.5 Sonnet via Amazon Bedrock:

    model = BedrockModel(
        model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0"
    )
    
    agent = Agent(model=model, tools=[http_request])
    agent("Where is the international space station now?")

    Uma lista de perfis de inferência disponíveis pode ser consultada no Guia do Usuário do Amazon Bedrock. Exemplos detalhados de agentes construídos com o Strands Agents SDK estão disponíveis no repositório de exemplos no GitHub.

    Passo a passo: construindo um agente Strands com SageMaker AI

    O Strands Agents SDK implementa um provedor nativo para o SageMaker AI, permitindo executar agentes contra modelos implantados em endpoints de inferência do SageMaker. Isso inclui tanto modelos pré-treinados do SageMaker JumpStart quanto modelos customizados com fine-tuning. O modelo utilizado deve suportar APIs de completions de chat compatíveis com OpenAI. O tutorial usa os modelos Qwen3 4B e Qwen3 8B disponíveis no SageMaker JumpStart.

    Pré-requisitos

    • Uma conta AWS com acesso ao Amazon Bedrock e ao Amazon SageMaker AI
    • Uma role com permissões para SageMaker AI, Amazon Bedrock, SageMaker AI Serverless MLflow, Amazon S3 e SageMaker JumpStart
    • Um Jupyter Notebook rodando localmente ou no SageMaker AI Studio

    Passo 1: Instalar os pacotes necessários

    %%writefile requirements.txt
    strands-agents>=1.9.1
    strands-agents-tools>=0.2.8
    mlflow>=3.4.0
    strands-agents[sagemaker]
    mlflow-sagemaker>=1.5.11
    
    pip install -r requirements.txt

    Passo 2: Fazer o deploy do modelo como endpoint no SageMaker AI

    # Deploy initial endpoint with Qwen-4B
    import sagemaker
    import boto3
    from boto3.session import Session
    from sagemaker.jumpstart.model import JumpStartModel
    
    boto_session = Session()
    sts = boto3.client('sts')
    account_id = sts.get_caller_identity().get("Account")
    region = boto_session.region_name
    
    ENDPOINT_NAME = INITIAL_CONFIG_NAME = "llm-qwen-endpoint-sagemaker"
    
    model_a = JumpStartModel(
        model_id="huggingface-reasoning-qwen3-4b",
        model_version="1.0.0",
        name="qwen3-4b-model"
    )
    
    predictor_a = model_a.deploy(
        initial_instance_count=1,
        instance_type="ml.g5.2xlarge",
        endpoint_name=ENDPOINT_NAME
    )

    Passo 3: Usar o modelo implantado com o agente Strands

    from strands.models.sagemaker import SageMakerAIModel
    from strands import Agent, tool
    from strands_tools import http_request, calculator
    
    model_sagemaker = SageMakerAIModel(
        endpoint_config={
            "endpoint_name": ENDPOINT_NAME,
            "region_name": region
        },
        payload_config={
            "max_tokens": 2048,
            "temperature": 0.2,
            "stream": True,
        }
    )
    
    agent = Agent(model=model_sagemaker, tools=[http_request])
    agent("Where is the international space station now? (Use: http://api.open-notify.org/iss-now.json)")

    Para mais informações sobre o SageMaker AI como provedor de modelos para o Strands Agents, consulte a documentação do Amazon SageMaker no site do Strands Agents.

    Observabilidade com SageMaker AI Serverless MLflow

    O SageMaker AI Serverless MLflow oferece observabilidade abrangente para agentes de IA, capturando automaticamente traces de execução, padrões de uso de ferramentas e fluxos de tomada de decisão — sem necessidade de instrumentação manual. O serviço gerenciado reduz a sobrecarga operacional e se integra nativamente ao Strands Agents SDK, permitindo monitorar o comportamento dos agentes em múltiplos deploys, identificar gargalos de desempenho e manter trilhas de auditoria para requisitos de conformidade.

    Passo 1: Configurar o MLflow App

    É possível configurar um MLflow App via interface do SageMaker AI Studio ou programaticamente com o SDK Boto3. O exemplo abaixo usa o Boto3:

    s3_client = boto3.client('s3', region_name=region)
    bucket_name = f'{account_id}-mlflow-bucket'
    
    if region == 'us-east-1':
        s3_client.create_bucket(Bucket=bucket_name)
    else:
        s3_client.create_bucket(
            Bucket=bucket_name,
            CreateBucketConfiguration={'LocationConstraint': region}
        )
    
    sagemaker_client = boto3.client('sagemaker')
    
    mlflow_app_details = sagemaker_client.create_mlflow_app(
        Name='strands-mlflow-app',
        ArtifactStoreUri=f's3://{account_id}-mlflow-bucket/artifacts',
        RoleArn=role,
    )
    print(f"MLflow app creation initiated: {mlflow_app_details['Arn']}")

    Passo 2: Habilitar o logging automático para o agente

    import os
    import mlflow
    
    tracking_uri = mlflow_app_details['Arn']
    os.environ["MLFLOW_TRACKING_URI"] = tracking_uri
    
    mlflow.set_experiment("Strands-MLflow")
    mlflow.strands.autolog()

    Passo 3: Executar o agente com rastreamento ativo

    def capitalize(response):
        return response.upper()
    
    agent = Agent(model=model_sagemaker, tools=[http_request])
    response = agent("Where is the international space station now?")
    capitalize(response.message['content'][0]['text'])

    Os traces e métricas ficam disponíveis na interface do MLflow App por meio de uma URL pré-assinada:

    presigned_response = sagemaker_client.create_presigned_mlflow_app_url(
        Arn=mlflow_app_details['Arn']
    )
    mlflow_ui_url = presigned_response['AuthorizedUrl']
    print(f"MLflow UI URL: {mlflow_ui_url}")

    Rastreamento manual de funções personalizadas

    O logging automático do MLflow captura a invocação do agente e suas chamadas de ferramentas e FMs. Funções externas ao agente, como a capitalize do exemplo, não são registradas automaticamente. Para rastrear um bloco completo de código, o MLflow oferece a capacidade de rastreamento manual via decoradores:

    @mlflow.trace(span_type="func", attributes={"operation": "capitalize"})
    def capitalize(response):
        return response.upper()
    
    @mlflow.trace
    def run_agent():
        agent = Agent(tools=[http_request])
        mlflow.update_current_trace(request_preview="Run Strands Agent")
        response = agent("Where is the international space station now? (Use: http://api.open-notify.org/iss-now.json) ")
        capitalized_response = capitalize(response.message['content'][0]['text'])
        return capitalized_response
    
    capitalized_response = run_agent()
    print(capitalized_response)

    Testes A/B com múltiplas variantes de modelos

    Com o SageMaker AI, é possível otimizar os modelos de linguagem de grande porte (LLM — Large Language Model) para aplicações de agentes. Por exemplo, ao considerar uma migração do Qwen3-4B para o Qwen3-8B, não é necessário fazer a troca completa imediatamente. É possível implantar o novo modelo lado a lado com o atual e distribuir o tráfego entre os dois endpoints de LLM para conduzir testes A/B antes de confirmar a atualização.

    Configurando as variantes de produção

    # Step1: Create a model from JumpStart
    model_b_name ="sagemaker-strands-demo-qwen3-8b"
    model_b_id, model_b_version = "huggingface-reasoning-qwen3-8b", "1.0.0"
    
    model_8b = JumpStartModel(
        model_id="huggingface-reasoning-qwen3-8b",
        model_version="1.0.0",
        name=model_b_name
    )
    model_b.create(instance_type="ml.g5.2xlarge")
    
    # Step2: Create production variants for A/B testing
    production_variants = [
        {
            "VariantName": "qwen-4b-variant",
            "ModelName": "qwen3-4b-model",
            "InitialInstanceCount": 1,
            "InstanceType": "ml.g5.2xlarge",
            "InitialVariantWeight": 0.5
        },
        {
            "VariantName": "qwen3-8b-variant",
            "ModelName": model_b_name,
            "InitialInstanceCount": 1,
            "InstanceType": "ml.g5.2xlarge",
            "InitialVariantWeight": 0.5
        }
    ]
    
    # Step3: Create new endpoint configuration
    ENDPOINT_CONFIG_AB_TESTING = "llm-endpoint-config-ab"
    sagemaker_client.create_endpoint_config(
        EndpointConfigName=ENDPOINT_CONFIG_AB_TESTING,
        ProductionVariants=production_variants
    )
    
    # Step4: Update the endpoint with new A/B testing configuration
    sagemaker_client.update_endpoint(
        EndpointName=ENDPOINT_NAME,
        EndpointConfigName=ENDPOINT_CONFIG_AB_TESTING
    )
    
    waiter = boto3.client('sagemaker').get_waiter('endpoint_in_service')
    waiter.wait(EndpointName=ENDPOINT_NAME)

    Para um experimento controlado, é possível criar dois agentes apontando para variantes específicas:

    model_sagemaker_a = SageMakerAIModel(
        endpoint_config={
            "endpoint_name": ENDPOINT_NAME,
            "region_name": region,
            "target_variant":"qwen-4b-variant"
        },
        payload_config={
            "max_tokens": 2048,
            "temperature": 0.2,
            "stream": True,
        }
    )
    
    model_sagemaker_b = SageMakerAIModel(
        endpoint_config={
            "endpoint_name": ENDPOINT_NAME,
            "region_name": region,
            "target_variant":"qwen-8b-variant"
        },
        payload_config={
            "max_tokens": 2048,
            "temperature": 0.2,
            "stream": True,
        }
    )

    Avaliando os agentes com MLflow GenAI

    Com ambas as variantes implantadas, o próximo passo é avaliá-las sistematicamente usando o framework de avaliação de IA generativa (GenAI — Generative Artificial Intelligence) do MLflow, que combina métricas customizadas e juízes baseados em LLM.

    Criando o dataset de avaliação

    eval_dataset = [
        {
            "inputs": {"query": "Calculate 15% tip on a $85.50 bill. Use calculator tool"},
            "expectations": {
                "expected_tool": "calculator",
                "expected_facts": ["The tip amount is approximately $12.83"]
            }
        },
        {
            "inputs": {"query": "What is 2048 divided by 64? Use calculator tool"},
            "expectations": {
                "expected_tool": "calculator",
                "expected_facts": ["The answer is 32"]
            }
        }
    ]

    Definindo os scorers de avaliação

    from mlflow.genai.scorers import scorer, Correctness, RelevanceToQuery
    from mlflow.entities import Feedback
    
    @scorer
    def tool_selection_scorer(inputs, outputs, expectations):
        expected_tool = expectations.get("expected_tool", "")
        tool_used = expected_tool in outputs.get("tools", [])
        return Feedback(name="tool_selection", value=1.0 if tool_used else 0.0)

    Executando a avaliação comparativa

    import mlflow
    from strands import Agent
    from strands_tools import calculator
    
    mlflow.set_experiment("Strands_Agents_AB_Evaluation")
    
    def predict_4b(query):
        agent = Agent(model=model_sagemaker_a, tools=[calculator])
        response = agent(query)
        return {"outputs": str(response), "tools": list(response.metrics.tool_metrics.keys())}
    
    def predict_8b(query):
        agent = Agent(model=model_sagemaker_b, tools=[calculator])
        response = agent(query)
        return {"outputs": str(response), "tools": list(response.metrics.tool_metrics.keys())}
    
    scorers = [
        tool_selection_scorer,
        Correctness(model="bedrock:/us.amazon.nova-pro-v1:0"),
        RelevanceToQuery(model="bedrock:/us.amazon.nova-pro-v1:0")
    ]
    
    eval_results_4b = mlflow.genai.evaluate(data=eval_dataset, predict_fn=predict_4b, scorers=scorers)
    eval_results_8b = mlflow.genai.evaluate(data=eval_dataset, predict_fn=predict_8b, scorers=scorers)

    Comparando os resultados

    metrics_4b = eval_results_4b.metrics
    metrics_8b = eval_results_8b.metrics
    
    for metric in metrics_4b:
        print(f"{metric}: 4B={metrics_4b[metric]:.3f}, 8B={metrics_8b[metric]:.3f}")

    Caso o novo modelo se mostre superior, basta ajustar os pesos das variantes para direcionar 100% do tráfego para ele:

    production_variants = [
        {
            "VariantName": "qwen-8b-variant",
            "ModelName": model_b_name,
            "InitialInstanceCount": 1,
            "InstanceType": "ml.g5.2xlarge",
            "InitialVariantWeight": 1
        }
    ]

    Solução de problemas e limpeza de recursos

    Caso ocorra o erro ImportError: cannot import name 'TokenUsageKey' from 'mlflow.tracing.constant' ou outros problemas com o rastreamento do Strands no MLflow, verifique se a versão do MLflow instalada é 3.4.0 ou superior, e se a role utilizada possui permissões de leitura, escrita e listagem no bucket S3 configurado como artifact store do MLflow.

    Para remover os recursos criados ao longo do tutorial:

    sagemaker_client.delete_endpoint(EndpointName=ENDPOINT_NAME)
    sagemaker_client.delete_endpoint_config(EndpointConfigName=INITIAL_CONFIG_NAME)
    sagemaker_client.delete_endpoint_config(EndpointConfigName=ENDPOINT_CONFIG_AB_TESTING)
    
    sagemaker_client.delete_mlflow_app(
        Arn=server_info["Arn"]
    )

    Conclusão

    A combinação do Strands Agents SDK com o Amazon SageMaker AI e o SageMaker Serverless MLflow cria um framework robusto para construir, implantar e monitorar agentes de IA com controle total sobre a infraestrutura. O deploy de modelos no SageMaker AI garante controle preciso sobre recursos de computação, configurações de rede e políticas de escalabilidade — especialmente valioso para organizações com requisitos específicos de desempenho, custo ou conformidade. A integração com o MLflow oferece observabilidade sólida, rastreamento de comportamento dos agentes e trilhas de auditoria.

    Para quem quiser se aprofundar, a AWS recomenda explorar o Strands Agents SDK e consultar o guia de decisão entre Amazon Bedrock e Amazon SageMaker AI para entender qual serviço é mais adequado para cada caso de uso.

    Fonte

    Build Strands Agents with SageMaker AI models and MLflow (https://aws.amazon.com/blogs/machine-learning/build-strands-agents-with-sagemaker-ai-models-and-mlflow/)

  • Como construir uma solução de sincronização automática para o Amazon Bedrock Knowledge Bases

    O problema: sincronização manual não escala

    O Amazon Bedrock Knowledge Bases permite que modelos de fundação (Foundation Models — FMs) e agentes de IA utilizem dados privados da organização para entregar respostas mais relevantes e precisas. Mas há um detalhe importante: sempre que documentos são adicionados, modificados ou excluídos no Amazon Simple Storage Service (Amazon S3), a base de conhecimento precisa ser ressincronizada — e, por padrão, esse processo é manual.

    Em ambientes com atualizações frequentes, múltiplas equipes fazendo upload de arquivos ao longo do dia ou aplicações como sistemas de suporte ao cliente que exigem acesso imediato às informações mais recentes, depender de sincronização manual é um gargalo real. Sem automação, requests de sync se acumulam, exigem supervisão humana e ficam sujeitos a atrasos ou simplesmente serem esquecidos.

    Para resolver isso, a AWS publicou um guia com uma solução automatizada que detecta eventos no S3 e dispara jobs de ingestão de forma inteligente, respeitando as cotas de serviço do Amazon Bedrock e oferecendo monitoramento abrangente.

    Restrições que a solução precisa respeitar

    Antes de entrar na arquitetura, é importante entender os limites impostos pelo Amazon Bedrock que qualquer solução de automação precisa considerar:

    • Máximo de 5 jobs de ingestão simultâneos por conta AWS
    • Máximo de 1 job por knowledge base
    • Máximo de 1 job por data source

    Além disso, a API StartIngestionJob tem um rate limit de 0,1 requisições por segundo — ou seja, uma requisição a cada 10 segundos por Região. Esses limites valem por Região AWS e podem mudar; consulte as cotas de serviço do Amazon Bedrock para informações atualizadas.

    Imagine um time de conteúdo atualizando vários arquivos durante uma release. Sem coordenação, os requests de sync se acumulam e ultrapassam os limites. Uma abordagem orquestrada resolve isso de forma transparente.

    Visão geral da solução

    A solução proposta é totalmente serverless, utiliza o AWS Serverless Application Model (AWS SAM) para deploy e não exige gerenciamento de infraestrutura. Ela é orientada a eventos e combina cinco serviços AWS para processar mudanças no S3 em tempo real enquanto gerencia os jobs de ingestão de forma inteligente:

    As cinco fases da arquitetura

    Fase 1: Detecção de mudanças nos documentos

    Quando um documento é criado, modificado ou excluído no S3, o EventBridge captura o evento imediatamente. Uma função Lambda processa esses eventos sequencialmente: extrai metadados do arquivo (caminho, tipo de mudança, timestamp), cria uma entrada de rastreamento no DynamoDB para fins de auditoria e envia uma mensagem para a fila SQS.

    # Event Processor Lambda extracts change information
    def lambda_handler(event, context):
        for record in event.get('Records', []):
            # Extract S3 information
            bucket = record['s3']['bucket']['name']
            key = record['s3']['object']['key']
            event_name = record['eventName']
    
            # Determine change type
            change_type = get_change_type(event_name)
    
            # Create tracking entry in DynamoDB
            tracking_table.put_item(
                Item={
                    'change_id': str(uuid.uuid4()),
                    'knowledge_base_id': kb_id,
                    'change_type': change_type,
                    'key': key,
                    'processed': False,
                    'timestamp': datetime.utcnow().timestamp()
                }
            )
    
            # Send immediate notification to SQS
            sqs.send_message(
                QueueUrl=QUEUE_URL,
                MessageBody=json.dumps({
                    'change_type': change_type,
                    'bucket': bucket,
                    'key': key,
                    'knowledge_base_id': kb_id
                })
            )

    Fase 2: Gerenciamento da fila

    O SQS atua como buffer para garantir que o rate limit entre os jobs de sync seja respeitado. Uma segunda função Lambda consome uma mensagem por vez da fila e inicia uma execução no Step Functions com os detalhes da mudança e a configuração da knowledge base.

    def lambda_handler(event, context):
        for record in event.get('Records', []):
            message = json.loads(record['body'])
            kb_id = message['knowledge_base_id']
    
            # Get or discover data source ID
            data_source_id = get_data_source_id(kb_id)
    
            # Start Step Functions workflow
            sfn_input = {
                'knowledge_base_id': kb_id,
                'data_source_id': data_source_id,
                'message': message
            }
    
            response = sfn.start_execution(
                stateMachineArn=STEP_FUNCTION_ARN,
                name=f"sync-{kb_id}-{int(datetime.utcnow().timestamp())}",
                input=json.dumps(sfn_input)
            )

    Fase 3: Sincronização orquestrada

    O Step Functions coordena o processo de sincronização com lógica de decisão para gerenciar as cotas. O fluxo verifica se há jobs ativos, inicia o sync imediatamente se as cotas permitirem ou aguarda 5 minutos antes de tentar novamente. Inclui também monitoramento do progresso e tratamento de falhas com retry automático.

    {
      "Comment": "Workflow for syncing documents to Amazon Bedrock Knowledge Base",
      "StartAt": "CheckServiceQuota",
      "States": {
        "CheckServiceQuota": {
          "Type": "Task",
          "Resource": "${CheckQuotaFunctionArn}",
          "Next": "EvaluateQuotaCheck"
        },
        "EvaluateQuotaCheck": {
          "Type": "Choice",
          "Choices": [
            {
              "Variable": "$.quota_check.all_quotas_ok",
              "BooleanEquals": true,
              "Next": "StartSyncJob"
            },
            {
              "Variable": "$.quota_check.all_quotas_ok",
              "BooleanEquals": false,
              "Next": "QuotaExceeded"
            }
          ]
        },
        "QuotaExceeded": {
          "Type": "Wait",
          "Seconds": 300,
          "Next": "CheckServiceQuota"
        },
        "StartSyncJob": {
          "Type": "Task",
          "Resource": "${StartSyncFunctionArn}",
          "Next": "MonitorSyncJob"
        }
      }
    }

    Fase 4: Processamento pela knowledge base

    Nesta fase, o Amazon Bedrock processa o conteúdo sincronizado: escaneia os documentos alterados, divide-os em chunks, converte cada trecho em embeddings vetoriais usando o modelo configurado e atualiza o índice vetorial — removendo embeddings desatualizados e inserindo os novos. O conteúdo atualizado fica imediatamente disponível para busca semântica.

    Fase 5: Monitoramento e alertas

    A solução inclui monitoramento completo: o DynamoDB registra o status de cada mudança de documento, o Amazon CloudWatch rastreia duração dos jobs, taxas de sucesso e utilização de cotas, alarmes são disparados quando a taxa de erros ultrapassa limites definidos, e notificações de sucesso ou falha são enviadas via Amazon SNS para os endereços configurados.

    Recursos-chave da solução

    Processamento de eventos em tempo real

    A integração com o EventBridge garante que mudanças no S3 sejam capturadas imediatamente, sem depender de processos agendados. A resposta é praticamente instantânea.

    Gerenciamento completo de cotas

    A solução valida os limites do serviço antes de disparar qualquer job:

    # Service quotas validation
    MAX_CONCURRENT_JOBS_PER_ACCOUNT = 5
    MAX_CONCURRENT_JOBS_PER_DATA_SOURCE = 1
    MAX_CONCURRENT_JOBS_PER_KB = 1
    MAX_FILE_SIZE_BYTES = 50 * 1024 * 1024 * 1024  # 50 GB
    MAX_TOTAL_SIZE_BYTES = 100 * 1024 * 1024 * 1024  # 100 GB
    
    def check_quotas(kb_id, data_source_id):
        # Get current active jobs
        response = bedrock.list_ingestion_jobs(
            knowledgeBaseId=kb_id,
            dataSourceId=data_source_id
        )
        active_jobs = [job for job in response['ingestionJobSummaries']
                       if job['status'] in ['STARTING', 'IN_PROGRESS']]
        return {
            'all_quotas_ok': len(active_jobs) == 0,
            'kb_quota_ok': len(active_jobs) < MAX_CONCURRENT_JOBS_PER_KB
        }

    Rate limiting inteligente via SQS

    A fila SQS é configurada para processar uma mensagem por vez, com retenção de 14 dias e dead letter queue para mensagens que falharem após 5 tentativas:

    SyncQueue:
      Type: AWS::SQS::Queue
      Properties:
        VisibilityTimeout: 300
        MessageRetentionPeriod: 1209600  # 14 days
        RedrivePolicy:
          deadLetterTargetArn: !GetAtt SyncQueueDLQ.Arn
          maxReceiveCount: 5
    
    SyncProcessorFunction:
      Events:
        SQSEvent:
          Type: SQS
          Properties:
            Queue: !GetAtt SyncQueue.Arn
            BatchSize: 1  # Process one message at a time

    Pré-requisitos para o deploy

    Antes de implantar a solução, é necessário ter:

    O tempo estimado para o deploy da infraestrutura é de 5 a 10 minutos.

    Passo a passo do deploy

    Para implantar a solução, clone o repositório no GitHub e execute os comandos abaixo:

    git clone https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases
    cd sample-automatic-sync-for-bedrock-knowledge-bases

    Em seguida, faça o build e o deploy guiado:

    sam build
    sam deploy --guided

    Durante o deploy, você será solicitado a informar os seguintes parâmetros:

    • Stack Name — nome para sua stack do CloudFormation (padrão: kb-auto-sync)
    • AWS Region — Região onde sua knowledge base existe (padrão: us-west-2)
    • KnowledgeBaseId — identificador da sua knowledge base no Amazon Bedrock
    • S3BucketName — nome do bucket S3 com seus documentos
    • S3KeyPrefix (opcional) — prefixo de pasta específico para sincronizar (ex: documents/)
    • NotificationsEmail (opcional) — e-mail para receber notificações dos jobs
    • MaxConcurrentJobs — número máximo de jobs simultâneos (padrão: 5)

    Exemplo de entrada durante o deploy:

    Setting default arguments for sam deploy
    ===============================
    Stack Name [kb-auto-sync]: my-kb-sync
    AWS Region [us-west-2]: us-east-1
    Parameter KnowledgeBaseId: kb-1234567890
    Parameter S3BucketName: my-document-bucket
    Parameter S3KeyPrefix: documents/
    Parameter NotificationsEmail: user@example.com
    Allow SAM CLI IAM role creation [Y/n]: Y
    Save arguments to configuration file [Y/n]: Y

    Considerações de custo

    A solução usa múltiplos serviços AWS com modelos de cobrança distintos. Para uma estimativa de uso típico com 10.000 documentos por mês:

    Os outros serviços têm custos mínimos para esse volume. No geral, a solução é bastante econômica para organizações que precisam de sincronização em tempo real.

    Troubleshooting: problemas mais comuns

    Falha no job de sincronização

    Pode ocorrer quando as permissões do IAM estão mal configuradas ou quando o tamanho dos documentos ultrapassa os limites permitidos. Para resolver: verifique o histórico de sincronização da data source no console do Amazon Bedrock, confirme que as permissões IAM estão corretas e valide que os documentos estão dentro dos tamanhos permitidos.

    Rate limiting

    Acontece quando muitas requisições de sync são processadas simultaneamente ou as cotas de serviço são atingidas. Para resolver: monitore as métricas no CloudWatch para identificar gargalos e ajuste as configurações de concorrência conforme necessário.

    Limpeza dos recursos

    Para evitar cobranças contínuas, remova a stack criada com um dos métodos abaixo.

    Via AWS SAM:

    # Deleção interativa (recomendada)
    sam delete \
      --stack-name kb-auto-sync \
      --region YOUR_REGION
    
    # Ou deleção não-interativa
    sam delete \
      --stack-name kb-auto-sync \
      --region YOUR_REGION \
      --no-prompts

    Via console do AWS CloudFormation: selecione a stack kb-auto-sync, clique em Delete e confirme. Aguarde a conclusão sem erros.

    Após a deleção, permanecerão: os documentos originais no S3, a knowledge base do Amazon Bedrock, os logs do CloudWatch (até o período de retenção expirar) e quaisquer recursos criados manualmente fora da stack.

    Recursos adicionais

    Para aprofundar o conhecimento sobre os temas abordados, a AWS disponibiliza os seguintes recursos:

    Fonte

    Build and deploy an automatic sync solution for Amazon Bedrock Knowledge Bases (https://aws.amazon.com/blogs/machine-learning/build-and-deploy-an-automatic-sync-solution-for-amazon-bedrock-knowledge-bases/)

  • Como estruturar um POC do AWS Security Hub para otimizar suas operações de segurança

    O que é o AWS Security Hub e por que fazer um POC?

    O AWS Security Hub chegou à disponibilidade geral trazendo uma proposta bastante ambiciosa: centralizar e priorizar os problemas críticos de segurança de toda a sua infraestrutura AWS em um único lugar. O serviço agrega, correlaciona e enriquece sinais nativos de segurança da AWS, transformando-os em insights acionáveis que permitem respostas mais rápidas e eficientes.

    Para times que ainda não conhecem o serviço na prática, a AWS oferece um período de teste gratuito que permite montar uma Prova de Conceito (POC) completa — sem grande investimento de tempo ou recursos logo de cara. Este guia percorre as etapas recomendadas para planejar e executar esse POC de forma estruturada.

    Entendendo o valor do Security Hub

    O Security Hub funciona como uma Plataforma de Proteção de Aplicações Nativas em Nuvem (CNAPP — Cloud-Native Application Protection Platform). Ele ingere sinais de múltiplos serviços AWS e soluções parceiras, consolidando tudo em uma visão única. As fontes de sinal incluem:

    Imagem original — fonte: Aws

    Na prática, o serviço entrega quatro capacidades principais em uma solução unificada:

    • Operações de segurança unificadas: todos os sinais de segurança em uma única visão consolidada, eliminando a necessidade de alternar entre múltiplas ferramentas. Isso inclui visibilidade sobre ambientes AWS, multi-cloud e on-premises.
    • Priorização inteligente: o Security Hub correlaciona findings analisando relações entre recursos e sinais de diferentes serviços, ajudando a identificar riscos críticos que seriam difíceis de perceber isoladamente.
    • Insights acionáveis: por meio de análise avançada, o serviço transforma findings correlacionados em insights claros e priorizados, permitindo entender rapidamente o impacto potencial e quais problemas representam maior risco.
    • Resposta e automação simplificadas: integração com sistemas de gestão de incidentes como Jira Cloud e ServiceNow, permitindo investigar riscos críticos a partir de um único painel, monitorar tendências e automatizar respostas.

    O papel do OCSF na integração de ferramentas

    O Security Hub adota o Framework Aberto de Esquema de Cibersegurança (OCSF — Open Cybersecurity Schema Framework) para padronizar os dados de segurança. Essa padronização simplifica como os findings são estruturados e analisados, permitindo integração e troca de dados entre diferentes ferramentas de segurança com formatos normalizados e consistentes.

    Ao planejar seu POC, é importante se familiarizar com as especificações OCSF que o Security Hub utiliza e confirmar que as ferramentas de análise ou sistemas de Informação de Segurança e Gerenciamento de Eventos (SIEM — Security Information and Event Management) que você pretende integrar suportam esse formato.

    Definindo critérios de sucesso

    Antes de habilitar qualquer serviço, é fundamental estabelecer critérios de sucesso que conectem os resultados do POC aos objetivos do negócio. Alguns exemplos de indicadores-chave de desempenho (KPI — Key Performance Indicator) recomendados:

    • Consolidação de alertas: medir a redução do esforço de correlação de eventos de segurança, especialmente os processos realizados fora da AWS ou via SIEM.
    • Melhoria no tempo de resposta: redução do Tempo Médio de Detecção (MTTD — Mean Time to Detect) e do Tempo Médio de Resposta (MTTR — Mean Time to Respond) para findings críticos, além de maior precisão na análise de caminhos de ataque.
    • Capacidades de automação: avaliar quais partes dos playbooks de resposta a incidentes podem ser automatizadas, incluindo roteamento automático de findings para as equipes corretas via Jira Cloud, ServiceNow ou ferramentas de terceiros.
    • Classificação de severidade e risco: reduzir o tempo para identificar recursos críticos e lacunas de cobertura afetados por novas vulnerabilidades, ameaças e configurações incorretas.

    Após definir os critérios, avalie a maturidade atual do ambiente: quais serviços de segurança já estão habilitados, quais são as cargas de trabalho críticas, e se há restrições organizacionais que possam impactar a implementação.

    Maximizando o valor do POC com os períodos de teste gratuito

    Para aproveitar ao máximo a avaliação, a AWS recomenda ativar os serviços subjacentes de forma coordenada, sobrepondo os períodos de teste gratuito disponíveis:

    • Security Hub: 30 dias de teste (capacidades do plano essencial)
    • GuardDuty: 30 dias de teste (cobre a maioria dos planos de proteção, exceto o GuardDuty Malware Protection)
    • Security Hub CSPM: 30 dias de teste
    • Macie: 30 dias de teste
    • Amazon Inspector: 15 dias de teste

    A recomendação é habilitar todos esses serviços simultaneamente para garantir pelo menos duas semanas de cobertura sobreposta, permitindo avaliar as capacidades completas de correlação e priorização de riscos. Se houver limitações, é possível iniciar o POC habilitando apenas o Security Hub CSPM e o Amazon Inspector.

    Dica importante: documente as datas de ativação e expiração dos testes. Crie lembretes no calendário e agende os marcos de avaliação do POC enquanto os serviços ainda estiverem ativos.

    Configurando o Security Hub

    Com os critérios de sucesso definidos, é hora de planejar a configuração. As principais decisões envolvem:

    • Administrador delegado: a partir da conta de gerenciamento do AWS Organizations, é possível definir um administrador delegado para o Security Hub. A recomendação da Arquitetura de Referência de Segurança AWS (AWS SRA) é usar o mesmo administrador delegado em todos os serviços de segurança para uma governança consistente.
    • Contas e regiões em escopo: definir quais contas e regiões AWS terão o Security Hub habilitado.
    • Integrações com serviços AWS: além das capacidades principais de CSPM e gerenciamento de vulnerabilidades, o Security Hub integra sinais de GuardDuty e Macie.
    • Integrações com terceiros: para gestão de tickets, o serviço integra com Jira Service Management Cloud e ServiceNow. Parceiros que já suportam ou pretendem suportar o esquema OCSF incluem Dynatrace, Netskope, Orca Security, SentinelOne, Sumo Logic, Tines, Wiz, entre outros como Arctic Wolf, CrowdStrike, DataBee, Datadog, Fortinet, IBM, Palo Alto Networks, Rapid7, Securonix, Sophos, Splunk, Trellix e Zscaler. Parceiros de serviços como Accenture, Caylent, Deloitte, IBM e Optiv também podem ajudar na adoção.
    • Estimativa de custos: utilize a Ferramenta de Estimativa de Custos do Security Hub para obter uma estimativa pré-habilitação com base no gasto atual em Amazon Inspector, Security Hub CSPM e GuardDuty.

    Preparando o deployment

    Com a configuração definida, o próximo passo é preparar o projeto com um plano estruturado. A linha do tempo sugerida é:

    • Antes da habilitação: validar a configuração dos serviços de segurança base (GuardDuty, Amazon Inspector, Security Hub CSPM e Macie) e obter as aprovações necessárias para o teste gratuito.
    • Dia 0: habilitar o serviço, familiarizar-se com o layout do Security Hub e iniciar o treinamento da equipe de segurança.
    • Semana 1: validar a cobertura desejada de detecção de ameaças, gerenciamento de vulnerabilidades e gerenciamento de postura em todas as contas e regiões.
    • Semana 2: conectar às ferramentas de Gerenciamento de Serviços de TI (ITSM — IT Service Management) e iniciar a criação de automações para cargas de trabalho e recursos críticos.
    • Semana 3: executar um exercício de simulação (tabletop exercise) em resposta a um finding de exposição selecionado.
    • Semana 4: analisar tendências de ameaças e exposições desde o dia 1 até a semana 4.

    Na parte de acessos e permissões, é recomendado configurar funções do AWS Identity and Access Management (IAM) alinhadas a uma matriz de Responsabilidade, Autoridade, Consulta e Informação (RACI), incluindo funções de gerenciamento de casos, escalonamento e acesso somente leitura usando Políticas Gerenciadas da AWS. Também é necessário configurar o acesso à conta de gerenciamento para delegação administrativa — veja os detalhes em Permissões necessárias para designar uma conta administradora delegada do Security Hub.

    Habilitando o Security Hub

    O Security Hub se integra ao AWS Organizations para facilitar o gerenciamento centralizado. O mínimo necessário para aproveitar as capacidades de correlação é habilitar o Security Hub CSPM e o Amazon Inspector. A combinação desses dois serviços fornece a telemetria necessária para o mecanismo de correlação do Security Hub e para os findings de exposição.

    Para habilitar o Security Hub para sua organização, acesse a conta de gerenciamento. Se for definir um administrador delegado, consulte a documentação sobre como configurar uma conta administradora delegada no Security Hub e aplique a política adequada para controle granular por região e por conta membro.

    O Security Hub oferece os planos Essentials, Threat Analytics e Extended. Após a habilitação, os findings de exposição são criados e analisados imediatamente — porém, pode levar até 6 horas para que um finding de exposição para um recurso específico seja gerado.

    Validando o deployment

    A etapa final é confirmar que o Security Hub está configurado corretamente e avaliar os resultados em relação aos critérios de sucesso definidos no início:

    • Validar políticas: verificar se as permissões para gerenciar contas membro e as restrições regionais estão configuradas corretamente.
    • Validar integrações: confirmar que os tickets no ServiceNow ou Jira Cloud estão sendo criados corretamente, verificando se há um ID de ticket associado aos findings no console do Security Hub.
    • Avaliar critérios de sucesso: determinar se os objetivos definidos no início do projeto foram alcançados.

    Conclusão

    O AWS Security Hub oferece uma abordagem estruturada para unificar e priorizar operações de segurança em nuvem. Seguindo as fases descritas — definição de critérios de sucesso, configuração, preparação e validação — é possível realizar uma avaliação completa aproveitando os períodos de teste gratuito sem incorrer em custos significativos.

    Durante o POC, vale manter o foco nos critérios predefinidos, mas também estar aberto a benefícios ou desafios inesperados que possam surgir. Para dúvidas técnicas, o time de conta AWS pode apoiar durante todo o processo.

    Recursos adicionais

    Fonte

    Optimize security operations through an AWS Security Hub POC (https://aws.amazon.com/blogs/security/how-to-develop-an-aws-security-hub-poc/)

  • AWS KMS agora rastreia o último uso de todas as chaves KMS

    O que mudou no AWS KMS

    A AWS anunciou uma melhoria importante no Serviço de Gerenciamento de Chaves (KMS): a partir de agora, o serviço registra automaticamente o último uso criptográfico de cada chave KMS. Isso elimina a necessidade de consultar e analisar logs manualmente para descobrir quando uma chave foi utilizada pela última vez.

    Para equipes de segurança e conformidade, essa visibilidade é um ganho real no dia a dia. Antes, identificar se uma chave estava ativa ou abandonada exigia cruzar dados do AWS CloudTrail de forma manual — um processo trabalhoso e sujeito a erros.

    O que é possível visualizar

    Com o novo recurso, é possível consultar, diretamente pelo console de gerenciamento do AWS KMS ou via API, as seguintes informações sobre cada chave:

    • O timestamp da última operação criptográfica realizada;
    • O tipo de operação que foi executada;
    • O ID do evento no AWS CloudTrail associado àquela operação.

    Casos de uso práticos

    A AWS destaca três aplicações diretas para esse novo recurso:

    • Identificar chaves sem uso para limpeza e organização do ambiente;
    • Confirmar que chaves críticas estão sendo usadas ativamente, o que é essencial para auditorias de conformidade;
    • Rastrear como as chaves são utilizadas em conjunto com o AWS CloudTrail, facilitando investigações e revisões de segurança.

    Proteção contra exclusão acidental

    Além da visibilidade, a atualização traz uma nova condition key chamada kms:TrailingDaysWithoutKeyUsage. Ela permite criar políticas que protegem chaves usadas recentemente contra exclusão acidental — ou seja, é possível configurar uma regra que impeça a remoção de qualquer chave que tenha sido utilizada nos últimos N dias.

    Esse tipo de proteção baseada em política reduz o risco operacional em ambientes onde múltiplas equipes gerenciam chaves, tornando o controle mais robusto sem depender apenas de processos manuais.

    Disponibilidade

    O recurso já está disponível em todas as regiões AWS onde o KMS opera, incluindo as regiões comerciais globais, as regiões AWS GovCloud (US) e as regiões AWS China. Para mais detalhes técnicos, a documentação oficial traz um guia completo sobre como determinar o uso passado de uma chave KMS no AWS KMS Developer Guide.

    Fonte

    AWS KMS now tracks last usage of all KMS keys (https://aws.amazon.com/about-aws/whats-new/2026/04/aws-kms-tracks-last-usage-kms-keys/)

  • Entendendo o AWS Service Authorization Reference: o que as políticas IAM realmente conseguem controlar

    O que as políticas IAM realmente conseguem controlar?

    Quem trabalha com segurança na AWS já se deparou com perguntas do tipo: “Consigo usar uma SCP do AWS Organizations para bloquear a criação de security groups que permitem tráfego de 0.0.0.0/0?” ou “Dá para impedir o upload de objetos no S3 que não estejam criptografados?” ou ainda “Posso bloquear funções Lambda com mais de 512 MB de memória alocada?”

    Algumas dessas situações são perfeitamente controláveis via políticas Gerenciamento de Identidade e Acesso (IAM). Outras, simplesmente não são. A diferença está em um princípio fundamental da autorização na AWS: as políticas tomam decisões com base nas informações disponíveis no contexto de autorização no momento da chamada de API. Se a informação não estiver nesse contexto, a política não tem como avaliá-la.

    A AWS publicou um post detalhado no blog de segurança explicando exatamente como usar o AWS Service Authorization Reference para descobrir o que é ou não controlável por políticas — e o que fazer quando as políticas não são suficientes.

    Como funciona o contexto de autorização na AWS

    Toda vez que uma requisição é feita à AWS — seja pelo console, pela Interface de Linha de Comando (AWS CLI) ou por um SDK — o serviço que recebe a requisição monta um contexto de requisição com as informações sobre aquela operação. É esse contexto que será usado para avaliar as políticas.

    Esse contexto segue o modelo PARC, com quatro componentes:

    • Principal: quem está fazendo a requisição, incluindo atributos como tags e contexto de sessão
    • Action (Ação): a operação de API solicitada (por exemplo, s3:PutObject ou ec2:RunInstances)
    • Resource (Recurso): o recurso AWS de destino, identificado pelo ARN (Nome de Recurso da Amazon)
    • Condition (Condição): contexto adicional disponível no momento da requisição, como endereço IP, horário, parâmetros de criptografia, status de MFA (Autenticação Multifator) e atributos específicos do serviço

    Para ilustrar, veja como seria o contexto de uma requisição de upload de objeto no Amazon S3:

    Principal: AIDA123456789EXAMPLE
    Action: s3:PutObject
    Resource: arn:aws:s3:::my-bucket/documents/samplereport.pdf
    Condition:
      aws:PrincipalTag/Department=Finance
      aws:RequestedRegion=us-east-1
      aws:SourceIp=x.x.x.x
      aws:MultiFactorAuthPresent=true
      s3:x-amz-server-side-encryption=AES256
      s3:x-amz-storage-class=STANDARD_IA

    Repare que o contexto inclui o método de criptografia e a classe de armazenamento especificados — e isso significa que uma política pode avaliar esses atributos. Por outro lado, o conteúdo real do arquivo, o tamanho do objeto ou padrões de dados internos não fazem parte do contexto, portanto não podem ser avaliados por políticas IAM.

    O Service Authorization Reference: a fonte definitiva

    O Service Authorization Reference é a documentação oficial da AWS que lista, para cada serviço, quais ações podem ser controladas por políticas, quais tipos de recursos podem ser alvos dessas ações e — o mais importante — quais condition keys (chaves de condição) estão disponíveis para cada ação.

    As chaves de condição se dividem em duas categorias:

    • Chaves de condição globais: aplicáveis a qualquer serviço AWS (como aws:SourceIp, aws:PrincipalTag, etc.)
    • Chaves de condição específicas de serviço: definidas para uso com um serviço específico (como s3:x-amz-server-side-encryption ou ec2:InstanceType)

    A regra é simples: se a informação que você quer controlar não aparece como uma chave de condição nessa documentação, você não conseguirá controlá-la apenas com políticas IAM.

    Como usar o Service Authorization Reference na prática

    O processo para verificar se um requisito pode ser atendido por políticas IAM é direto:

    • Acesse a página do serviço específico no Service Authorization Reference — por exemplo, ações, recursos e chaves de condição para o Amazon S3
    • Localize a ação que você quer controlar (seja preciso, pois diferentes ações têm diferentes chaves disponíveis)
    • Examine a coluna de chaves de condição para aquela ação
    • Se a informação que você precisa não estiver listada como chave de condição, uma política IAM não será suficiente

    Como exemplo, ao examinar a ação RunInstances do Amazon Elastic Compute Cloud (Amazon EC2) na seção do EC2 no Service Authorization Reference, é possível ver que diferentes tipos de recursos têm chaves de condição diferentes. Para o tipo de recurso instance*, estão disponíveis chaves como ec2:InstanceType, ec2:EbsOptimized e aws:RequestTag/. Para network-interface*, há chaves como ec2:Subnet, ec2:Vpc e ec2:AssociatePublicIpAddress. O reference completo lista dezenas de chaves de condição para os vários tipos de recursos afetados pelo RunInstances.

    Acesso programático ao Service Authorization Reference

    Além da documentação em formato legível, a AWS disponibiliza o Service Authorization Reference em formato JSON para automação de fluxos de trabalho de gerenciamento de políticas. Para detalhes sobre a estrutura JSON e definições dos campos, consulte a documentação sobre acesso programático às informações simplificadas de serviços AWS. Desenvolvedores também podem usar o IAM MCP Server para operações IAM com assistentes de IA, gerenciando usuários, funções, políticas e permissões seguindo boas práticas de segurança.

    Exemplos práticos: o que é possível controlar com políticas IAM

    Exemplo 1: Exigir criptografia AES-256 em uploads no S3

    No Service Authorization Reference do Amazon S3, a chave de condição s3:x-amz-server-side-encryption está disponível para a ação s3:PutObject. Isso significa que é possível criar uma política que bloqueie uploads sem criptografia AES-256:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "DenyUnencryptedObjectUploads",
          "Effect": "Deny",
          "Action": "s3:PutObject",
          "Resource": "arn:aws:s3:::my-bucket/*",
          "Condition": {
            "StringNotEquals": {
              "s3:x-amz-server-side-encryption": "AES256"
            }
          }
        }
      ]
    }

    Essa é uma política baseada em recurso que pode ser aplicada diretamente no bucket S3. Ela nega qualquer requisição PutObject que não especifique criptografia AES-256.

    Exemplo 2: Restringir tipos de instância EC2 por centro de custo

    No Service Authorization Reference do Amazon EC2, a chave ec2:InstanceType está disponível para a ação ec2:RunInstances. Combinando essa chave com a chave global aws:PrincipalTag/tag-key, é possível criar uma política baseada em identidade que aplica restrições diferentes dependendo do centro de custo do usuário:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "AllowDevInstanceTypes",
          "Effect": "Allow",
          "Action": "ec2:RunInstances",
          "Resource": "arn:aws:ec2:*:*:instance/*",
          "Condition": {
            "StringEquals": {
              "aws:PrincipalTag/CostCenter": "Development"
            },
            "StringLike": {
              "ec2:InstanceType": "t3.*"
            }
          }
        },
        {
          "Sid": "AllowProdInstanceTypes",
          "Effect": "Allow",
          "Action": "ec2:RunInstances",
          "Resource": "arn:aws:ec2:*:*:instance/*",
          "Condition": {
            "StringEquals": {
              "aws:PrincipalTag/CostCenter": "Production"
            },
            "StringLike": {
              "ec2:InstanceType": [
                "m5.*",
                "c5.*",
                "r5.*"
              ]
            }
          }
        }
      ]
    }

    Com essa política, usuários com a tag CostCenter=Development só podem lançar instâncias T3 (mais econômicas), enquanto usuários de produção têm acesso às famílias M5, C5 e R5. Essa abordagem permite controle de custos dinâmico com base na identidade do solicitante. Atenção: recursos adicionais são necessários na política IAM para lançar instâncias EC2 com sucesso — consulte a documentação de lançamento de instâncias para a lista completa.

    Exemplo 3: Controle de acesso granular no DynamoDB por nome de usuário

    O Service Authorization Reference do Amazon DynamoDB expõe valores de chave de partição no contexto de autorização para as ações GetItem, PutItem e UpdateItem. Isso permite criar uma política em que cada usuário só acessa os itens onde a chave de partição corresponde ao seu próprio nome de usuário:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "dynamodb:GetItem",
            "dynamodb:PutItem",
            "dynamodb:UpdateItem"
          ],
          "Resource": "arn:aws:dynamodb:us-east-1:111122223333:table/UserProfiles",
          "Condition": {
            "ForAllValues:StringEquals": {
              "dynamodb:LeadingKeys": ["${aws:username}"]
            }
          }
        }
      ]
    }

    Com essa política, se a usuária alice tentar acessar um item com chave de partição bob, a requisição será negada automaticamente.

    Cenários que exigem mais do que políticas IAM

    Alguns requisitos de segurança simplesmente não podem ser atendidos apenas com políticas IAM — e o Service Authorization Reference é a ferramenta certa para descobrir isso antes de perder tempo tentando.

    Cenário 1: Bloquear criação de regras de security group com 0.0.0.0/0 na porta 22

    A ação responsável por adicionar regras de entrada em security groups é a ec2:AuthorizeSecurityGroupIngress. Ao consultar o Service Authorization Reference do Amazon EC2 e examinar as chaves de condição disponíveis para a ação AuthorizeSecurityGroupIngress, encontramos apenas:

    Não há nenhuma chave de condição para blocos CIDR, números de porta ou protocolos. O contexto de autorização simplesmente não inclui essas informações — portanto, políticas IAM não conseguem controlar esses atributos.

    Solução alternativa: usar uma abordagem reativa com o AWS Config e a regra gerenciada INCOMING_SSH_DISABLED para detectar regras excessivamente permissivas. Também é possível combinar o Amazon EventBridge com Lambda para notificar a equipe de segurança ou reverter automaticamente a configuração não conforme. Para mais detalhes, a AWS publicou um guia sobre como reverter automaticamente e receber notificações sobre alterações em security groups da VPC.

    Cenário 2: Impedir criação de funções Lambda com mais de 512 MB de memória

    Seguindo a mesma metodologia, ao consultar o Service Authorization Reference do AWS Lambda e examinar as chaves de condição disponíveis para a ação CreateFunction com o tipo de recurso function*, encontramos apenas chaves como lambda:CodeSigningConfigArn, lambda:Layer e lambda:VpcIds. Não existe nenhuma chave de condição para alocação de memória, timeout, armazenamento efêmero ou seleção de runtime.

    Soluções alternativas:

    Princípios para trabalhar com políticas IAM de forma eficaz

    Com base no que a AWS detalhou, vale reforçar alguns pontos fundamentais:

    • Políticas controlam o que está no contexto de autorização, não todos os parâmetros visíveis na documentação de API
    • O Service Authorization Reference é a fonte definitiva: se algo não está listado como chave de condição, não é controlável via políticas
    • Ações diferentes têm contextos diferentes, mesmo dentro do mesmo serviço
    • Abordagens alternativas existem: AWS Config, EventBridge e controles específicos de serviços cobrem o que as políticas não alcançam
    • Segurança em camadas é essencial: combine controles preventivos, detectivos e responsivos para uma defesa em profundidade eficaz

    Próximos passos recomendados

    Para quem quer aprofundar o conhecimento em políticas IAM, a AWS sugere explorar o simulador de políticas IAM para testar e depurar políticas, ler sobre tipos de políticas IAM e quando usar cada uma, e assistir ao vídeo Entendendo a linguagem de políticas IAM da AWS: elementos, avaliação e boas práticas.

    O ponto central é que as políticas IAM são ferramentas poderosas de prevenção, mas a segurança eficaz na AWS não depende de um único controle perfeito — ela vem da combinação inteligente de medidas preventivas, detectivas e responsivas.

    Fonte

    Can I do that with policy? Understanding the AWS Service Authorization Reference (https://aws.amazon.com/blogs/security/can-i-do-that-with-policy-understanding-the-aws-service-authorization-reference/)

  • Amazon Redshift Serverless agora usa escalabilidade orientada por IA como padrão para novos workgroups

    O que mudou

    A AWS tornou a escalabilidade orientada por IA (AI-driven scaling) o comportamento padrão para todos os novos workgroups criados no Amazon Redshift Serverless. Isso significa que, a partir de agora, qualquer novo workgroup já nasce com essa capacidade ativada — sem necessidade de configuração manual.

    Como funciona a escalabilidade orientada por IA

    Esse recurso utiliza aprendizado de máquina para prever a demanda de computação e ajustar automaticamente os recursos antes que as consultas entrem em fila. Na prática, o Redshift monitora os padrões de carga de trabalho e adapta os recursos computacionais com base na complexidade das queries, no volume de dados e no tamanho esperado da varredura de dados.

    O resultado é uma melhor relação preço-desempenho sem que o time precise fazer ajustes manuais constantes.

    Redução do custo de entrada

    Além de tornar o recurso padrão, a AWS expandiu o suporte para workloads com faixa de Unidades de Processamento do Redshift (RPU) Base entre 8 e 512 RPU. Anteriormente, o mínimo era 32 RPU. Essa mudança reduz significativamente o custo de entrada para quem deseja utilizar a escalabilidade orientada por IA, tornando o recurso acessível para cargas de trabalho menores.

    Controle de preço-desempenho

    O Amazon Redshift oferece um controle deslizante (slider) de preço-desempenho que permite escolher se a prioridade será custo, desempenho ou um equilíbrio entre ambos. Com base nessa escolha, o serviço também aplica otimizações adicionais automaticamente, incluindo visualizações materializadas automáticas e otimização automática de design de tabelas.

    Para configurar as metas de preço-desempenho, é possível usar o Console de Gerenciamento da AWS (AWS Management Console) ou as operações da API do Amazon Redshift. O alvo também pode ser modificado após a criação do workgroup.

    Disponibilidade

    A escalabilidade orientada por IA do Amazon Redshift Serverless está disponível em todas as regiões da AWS onde o Redshift Serverless opera. Para mais detalhes, consulte a página do produto Amazon Redshift Serverless e a documentação sobre escalabilidade e otimização orientada por IA.

    Fonte

    Amazon Redshift Serverless AI-driven scaling is now the default for new workgroups (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-redshift-serverless-ai-driven-scaling-default/)