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:
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á:
Procure pela quota de modelo específico (por exemplo, “Claude Sonnet 4.5 tokens por minuto”).
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.
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.
Derrubando barreiras técnicas na análise geoespacial
Organizações há muito tempo utilizam aprendizado de máquina geoespacial para avaliação de risco de propriedades, resposta a desastres e planejamento de infraestrutura. Esses sistemas funcionavam bem, mas enfrentavam limitações críticas de escalabilidade. Cada pergunta demandava múltiplos conjuntos de dados geoespaciais, frequentemente com modelos independentes e fluxos de trabalho distintos, restringindo essas capacidades a poucos casos de alto valor nas maiores empresas que podiam arcar com os investimentos necessários.
A barreira histórica era clara: não existia uma chave de junção universal capaz de combinar diferentes formatos de dados. Os dados geoespaciais chegavam em variações desconcertantes — imagens de satélite em formato GeoTIFF, limites administrativos em shapefiles, modelos climáticos em grades NetCDF, registros de propriedade em formatos cadastrais proprietários. Cada formato exigia bibliotecas de análise específicas e pipelines customizados de engenharia de dados.
Implementações anteriores ainda demandavam entre 6 e 12 meses com equipes especializadas em Sistemas de Informação Geográfica (GIS). Cinco requisitos empresariais permaneciam sem solução: tornar análises geoespaciais acessíveis a especialistas de domínio não técnicos, explicar como a IA chegava a conclusões, permitir análises flexíveis, entregar tempos de resposta interativos e oferecer previsibilidade de custos em escala.
Três tecnologias convergindo para transformar a realidade
Resolver essa complexidade exigiu uma abordagem fundamentalmente diferente. A solução combina três tecnologias complementares:
Dados prontos para análise com o Foursquare Spatial H3 Hub
O Foursquare Spatial H3 Hub transforma dados geoespaciais inacessíveis (rasters e vetores) em características prontas para análise, indexadas ao sistema de grade hierárquica H3, em formato tabular que cientistas de dados consultam usando ferramentas familiares como Spark, Python e DuckDB. Conjuntos de dados contendo coordenadas de latitude e longitude, nomes de cidades ou códigos postais podem ser facilmente enriquecidos unindo-se por célula H3 comum, eliminando meses de preparação de dados e a necessidade de expertise especializada em GIS.
Modelos com raciocínio e IA agêntica para fluxos adaptativos
Modelos como DeepSeek-R1 e Llama 3 decompõem problemas complexos, raciocinam através de fluxos de trabalho de múltiplas etapas e orquestram ações entre fontes de dados. Eles determinam dinamicamente quais conjuntos de dados combinar e planejam sequências analíticas que anteriormente exigiam expertise em GIS, transformando fluxos estáticos e pré-configurados em sistemas adaptativos de raciocínio.
Inferência generativa econômica com Amazon SageMaker AI
O Amazon SageMaker AI oferece infraestrutura gerenciada para implantar modelos de IA generativa de código aberto com tempos de execução de inferência otimizados, autoescala e ferramentas operacionais. Equipes podem focar em construir capacidades de inteligência geoespacial em vez de gerenciar infraestrutura subjacente.
Juntas, essas tecnologias permitem que organizações acessem dados geoespaciais prontos para análise, implantem agentes de raciocínio adaptativos e executem inferência em produção sem construir infraestrutura especializada.
O motor H3: simplificando o caos geoespacial
O núcleo da solução do Foursquare está no motor de indexação H3 proprietário. Este mecanismo transformou dezenas de conjuntos de dados geoespaciais distintos em um catálogo Iceberg pronto para análise imediata, substituindo meses de engenharia de dados por acesso instantâneo a características geoespaciais prontas.
O motor resolve o problema raiz da complexidade geoespacial: a vasta variedade de formatos e sistemas de coordenadas que historicamente limitavam o acesso a informações geográficas. Ele converte dados espaciais, imagens raster ou conjuntos de vetores indexando-os na grade espacial hierárquica H3 em escala global. H3 divide toda a Terra em células hexagonais aninhadas, criando um sistema de grade universal onde cada localização tem um identificador padronizado.
O motor extrai dados de imagens raster ou formas vetoriais diversas como polígonos de tratos censitários e as converte em características anexadas a IDs de célula H3 em formato tabular, onde o ID de célula se torna uma chave de junção universal que abstrai a complexidade de formatos e sistemas de coordenadas.
Dados de propriedade de uma companhia de seguros, projeções climáticas da Administração Nacional Oceânica e Atmosférica (NOAA), demografia censitária e redes de infraestrutura podem todos ser combinados porque compartilham este índice espacial comum.
Precisão adaptável conforme necessário
O motor pode indexar dados a células H3 em qualquer precisão, desde resolução 0 (hexágonos de aproximadamente 1.000 km cobrindo continentes) até resolução 15 (hexágonos de cerca de 1 metro cobrindo edifícios individuais). Você escolhe a resolução apropriada para cada caso de uso — resoluções mais grosseiras para análise climática regional, resoluções mais finas para avaliação em nível de propriedade.
Quando limites não se alinham perfeitamente — como um trato censitário sobrepondo múltiplos hexágonos H3 — o motor inteligentemente trata sobreposições parciais através de aproximação rápida baseada em centróide ou alocação proporcional exata baseada em áreas de interseção. Também agrega ou desagrega automaticamente dados ao combinar conjuntos em diferentes escalas, eliminando pré-processamento manual que tradicionalmente consumia meses de tempo de especialistas em GIS.
Modelos de raciocínio: inteligência verdadeiramente adaptativa
Modelos de raciocínio como DeepSeek-R1 transformam como a IA lida com inteligência geoespacial. Sistemas geoespaciais tradicionais operavam como coleções de modelos estáticos e propósito-específico — modelos separados para risco de inundação, exposição a incêndios florestais e vulnerabilidade a terremotos. Cada modelo era treinado em conjuntos de dados específicos e incapaz de responder perguntas fora de seu domínio estreito.
Modelos de raciocínio mudam este paradigma. Ao invés de exigir modelos pré-treinados para cada pergunta, esses sistemas raciocinam através de cenários novos combinando dados disponíveis de formas nunca explicitamente programadas. Quando questionado “quais bairros enfrentam riscos climáticos e econômicos compostos?”, um agente de raciocínio determina que precisa de dados de exposição a inundações, renda domiciliar, densidade de propriedades e limites de bairro, então executa esse pipeline analítico chamando ferramentas e fontes de dados apropriadas.
O agente compreende relações espaciais conceitualmente: dados pontuais agregam a polígonos, células de grade mapeiam para limites administrativos, proximidade exige métricas de distância apropriadas. A cada passo, raciocina sobre qual informação vem em seguida e se ajusta quando dados revelam padrões inesperados, transformando análise geoespacial de consultas pré-scripts em investigação adaptativa.
Implantação em produção: infraestrutura gerenciada para agentes geoespaciais
Dados geoespaciais prontos e modelos com capacidade de raciocínio resolvem partes críticas, mas implantação em produção cria novos desafios. Agentes geoespaciais precisam de capacidade de inferência sustentada para processar consultas, executar cadeias de raciocínio, recuperar dados e gerar visualizações.
Organizações enfrentavam escolha: construir infraestrutura de inferência customizada com clusters GPU, balanceadores de carga e políticas de autoescala, ou depender de APIs comerciais de modelos de linguagem de grande escala (LLM) onde custos escalam imprevisivelmente com uso e governança de dados se torna complexa.
O Amazon SageMaker AI oferece infraestrutura gerenciada para implantar e operar modelos de IA generativa de código aberto em produção. Você pode implantar modelos do Hugging Face ou Amazon SageMaker AI JumpStart — incluindo modelos de raciocínio como DeepSeek-R1, Llama 3 ou Qwen — para pontos de extremidade de inferência em tempo real ou assíncrona no SageMaker AI sem gerenciar infraestrutura subjacente.
Escalabilidade inteligente para cargas variáveis
O Amazon SageMaker AI Inference trata provisionamento de instâncias, suporta tempos de execução de serviço otimizados como vLLM e SGLang, e oferece autoescala baseada em padrões de tráfego. Agentes geoespaciais manipulando cargas de consulta variáveis ao longo do dia se beneficiam de escalabilidade automática em instâncias GPU como G5, P4d e P5 baseada em volume de requisição ou métricas customizadas.
Análises espaciais de longa duração que excedem timeouts típicos de API podem rotear para pontos de extremidade de inferência assíncrona onde SageMaker AI enfileira requisições, as processa e entrega resultados ao Amazon Simple Storage Service (Amazon S3), permitindo análises complexas de múltiplos conjuntos de dados sem problemas de timeout no lado do cliente.
Para arquiteturas empregando múltiplos modelos, pontos de extremidade multi-container hospedam diferentes modelos em infraestrutura compartilhada com políticas de escalabilidade independentes e roteamento de tráfego. Integração incorporada com Amazon CloudWatch para monitoramento, AWS Identity and Access Management (IAM) para controle de acesso e Amazon Virtual Private Cloud (Amazon VPC) para isolamento de rede simplifica requisitos operacionais.
Arquitetura do agente geoespacial em ação
O Foursquare Spatial Agent combina modelos de raciocínio implantados no SageMaker AI com capacidades de tool-calling que consultam o Foursquare Spatial H3 Hub diretamente. O agente orquestra o fluxo de trabalho completo desde pergunta em linguagem natural até visualização sem intervenção manual.
Fluxo de trabalho do agente
Quando um usuário coloca uma pergunta em linguagem natural sobre relações espaciais — como “Quais bairros de Los Angeles enfrentam tanto alto risco de inundação quanto vulnerabilidade econômica?” — o agente executa um processo de raciocínio com múltiplas etapas.
O modelo de raciocínio primeiro analisa a pergunta e identifica informação requerida: scores de risco de inundação, indicadores econômicos como renda e emprego, e limites de bairro. Determina qual H3 Hub dataset contém informação relevante através de raciocínio sobre descrições de dataset. Com datasets selecionados, o modelo chama ferramentas de consulta H3 Hub, construindo consultas SQL que unem datasets em IDs de célula H3.
Após executar essas consultas, o modelo analisa resultados para identificar padrões espaciais e relações estatísticas. Finalmente, gera especificações Vega para gráficos e especificações Kepler.gl para mapas que visualizam as descobertas. Este fluxo de trabalho usa a capacidade do modelo de raciocínio de planejar, adaptar e recuperar-se de erros. Se consultas iniciais retornam resultados inesperados, o modelo pode refinar sua abordagem, selecionar datasets adicionais ou ajustar operações espaciais — capacidades que fluxos de trabalho estáticos e pré-programados não possuem.
Decisões de design para requisitos empresariais
Acessibilidade através de linguagem natural
Subscritores de seguros entendem risco de inundação e exposição de propriedade mas não escrevem SQL ou Python. A arquitetura do agente torna análise geoespacial acessível aceitando perguntas em linguagem natural e traduzindo-as em consultas apropriadas ao H3 Hub. O modelo de raciocínio interpreta terminologia específica de domínio como “bairros vulneráveis” ou “áreas de alto risco” e mapeia esses conceitos a datasets relevantes e operações analíticas. Isso elimina o gargalo onde especialistas de domínio devem submeter requisições de análise a equipes de dados, permitindo exploração de auto-serviço.
Transparência em decisões de IA
Especialistas de domínio também precisam entender como o agente chegou a conclusões, especialmente quando análises informam decisões comerciais. O agente pode registrar seu processo de raciocínio a cada passo: quais datasets foram considerados e por quê, que operações espaciais foram planejadas, quais consultas foram executadas e como resultados foram interpretados. Cada visualização inclui metadados mostrando quais células H3 e datasets de origem contribuíram para a análise.
Essa transparência significa que usuários podem validar a abordagem analítica do agente e entender as fontes de dados por trás de conclusões. Se um subscritor de seguros vê uma avaliação de alto risco para uma propriedade, pode rastrear de volta pela cadeia de raciocínio para ver que combinou dados de exposição a inundações da Agência Federal de Gerenciamento de Emergências (FEMA), risco de incêndio florestal de dados de silvicultura estadual e características de propriedade de registros de avaliador local — construindo confiança em insights gerados por IA.
Flexibilidade para análises emergentes
Dashboards pré-construídos servem perguntas conhecidas mas falham quando analistas precisam explorar variações. A arquitetura do agente oferece flexibilidade usando tool-calling para compor análises dinamicamente. Em vez de predefinir fluxos de trabalho para cada cenário, o modelo de raciocínio determina quais H3 Hub datasets consultar e como combiná-los baseado na pergunta específica. Isso permite ao agente manipular perguntas analíticas não previstas sem exigir novo trabalho de engenharia para cada variação.
Casos de uso demonstrados
Avaliação de risco em seguros
O agente prediz quais áreas da região de Los Angeles provavelmente testemunharão aumento nas taxas de seguros computando um score de risco composto a partir de risco de inundação, severidade de perigo de fogo, taxas de crime e datasets do índice de risco nacional FEMA em diferentes resoluções espaciais e formatos, agora consultáveis através de IDs de célula H3 comuns. Um subscritor coloca a pergunta em linguagem natural e o agente trata seleção de dataset, junções espaciais, agregação de risco e visualização em mapa sem exigir expertise em GIS. Análises que previamente consumiam semanas de tempo de especialista em GIS agora são entregues em minutos através de interação conversacional.
Planejamento de infraestrutura urbana
Planejadores urbanos da cidade de Chandler, Arizona usam o agente para planejar desenvolvimento urbano sustentável ao longo da próxima década. Combina projeções de crescimento populacional, padrões de desenvolvimento habitacional, tendências de renda mediana e dados de infraestrutura incluindo edifícios, linhas de energia e torres de celular — todos indexados a células H3. Planejadores exploram cenários perguntando “quais áreas testemunharão crescimento populacional mas carecem de infraestrutura adequada?” O agente raciocina através dos requisitos analíticos, executa consultas espaciais apropriadas e gera visualizações mostrando lacunas de infraestrutura que precisam de investimento.
Democratizando a inteligência geoespacial
Foursquare Spatial H3 Hub, modelos de raciocínio e Amazon SageMaker AI juntos removem as barreiras. Organizações podem agora acessar dados geoespaciais padronizados, implantar agentes de raciocínio com capacidades de tool-calling e executar inferência em produção sem construir infraestrutura especializada.
Para implantar agentes de IA geoespacial, as organizações devem: acessar Foursquare Spatial H3 Hub para datasets prontos para análise; implantar modelos de raciocínio no Amazon SageMaker AI com SageMaker JumpStart ou Hugging Face; construir capacidades de agente que conectam modelos a datasets H3 Hub através de tool-calling.
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.
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.
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.
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.
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.
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).
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.
Investigação de Incidentes de Segurança Mais Eficiente com Inteligência Artificial
Quem já passou horas vasculhando manualmente os registros do AWS CloudTrail, verificando permissões do AWS Identity and Access Management (IAM) e reconstruindo a cronologia de um evento de segurança, compreende bem o investimento de tempo que uma investigação de incidente exige. A AWS anunciou a adição de capacidades de investigação impulsionadas por inteligência artificial ao AWS Security Incident Response, automatizando o trabalho de coleta e análise de evidências que costumava ser realizado manualmente.
O serviço Security Incident Response da AWS foi projetado para ajudar organizações a se prepararem, responderem e recuperarem-se de eventos de segurança de forma mais rápida e eficaz. Ele combina monitoramento e triagem automatizados de descobertas de segurança, contenção e agora novas capacidades de investigação baseadas em IA, tudo integrado com acesso 24/7 à equipe especializada de resposta a incidentes da AWS.
O Desafio da Investigação Manual de Incidentes
Durante a investigação de uma chamada de API suspeita ou atividade de rede incomum, os analistas precisam consultar múltiplas fontes de dados, correlacionar timestamps, identificar eventos relacionados e construir uma visão completa do que ocorreu. Profissionais de centros de operações de segurança (SOC) dedicam uma quantidade significativa de tempo a cada investigação, com aproximadamente metade desse esforço consumido pela coleta manual e correlação de evidências de diversas ferramentas e logs complexos.
Esse trabalho manual frequentemente atrasa a análise e a resposta aos incidentes. Para resolver esse gargalo, a AWS introduz um agente investigador ao Security Incident Response, transformando esse paradigma e adicionando camadas de eficiência que reduzem drasticamente o tempo necessário para validar e responder a possíveis eventos de segurança.
O Agente Investigador: Como Funciona
Quando um caso de preocupação de segurança é criado — seja manualmente ou de forma proativa pelo Security Incident Response — o agente investigador faz perguntas de esclarecimento para garantir que compreende totalmente o contexto do possível evento de segurança. Em seguida, ele reúne automaticamente evidências de eventos do CloudTrail, configurações do IAM, detalhes de instâncias do Amazon Elastic Compute Cloud (Amazon EC2) e até analisa padrões de uso de custos.
Em poucos minutos, o agente correlaciona as evidências, identifica padrões e apresenta um resumo claro e compreensível. Diferentemente da automação tradicional, o agente não oferece resultados genéricos — a investigação é adaptada especificamente à sua preocupação.
Fluxo de Operação na Prática
Imagine o seguinte cenário: você descobre que as credenciais de um usuário IAM em sua conta foram expostas em um repositório público do GitHub. Você precisa entender quais ações foram realizadas com essas credenciais e escopar adequadamente o possível evento de segurança, incluindo movimentos laterais e operações de reconhecimento. Você também precisa identificar mecanismos de persistência que possam ter sido criados e determinar as etapas de contenção apropriadas.
Para começar, você cria um caso no console do Security Incident Response e descreve a situação. É aqui que a abordagem do agente se diferencia: ele faz perguntas esclarecedoras primeiro. Quando as credenciais foram expostas pela primeira vez? Qual é o nome do usuário IAM? Você já rotacionou as credenciais? Qual conta da AWS foi afetada? Essa etapa interativa coleta os detalhes e metadados apropriados antes de iniciar a coleta de evidências.
Depois que o agente tem as informações necessárias, ele investiga. Busca eventos do CloudTrail para ver quais chamadas de API foram feitas usando as credenciais comprometidas, obtém detalhes do usuário e das funções do IAM para verificar quais permissões foram concedidas, identifica novos usuários ou funções do IAM que foram criados, verifica informações de instâncias do EC2 se recursos de computação foram iniciados e analisa padrões de custos e uso para consumo anômalo de recursos.
Em vez de você consultar cada serviço da AWS individualmente, o agente orquestra isso automaticamente. Em poucos minutos, você recebe um resumo contendo uma visão de alto nível, descobertas críticas, padrões de exposição de credenciais, atividades observadas e cronogramas, recursos afetados e fatores limitantes.
O resumo da investigação inclui várias abas com informações detalhadas, como descobertas técnicas com uma cronologia de eventos, fornecendo a você uma imagem de alta resolução do que aconteceu. Com essa transparência, você pode tomar decisões informadas sobre contenção, erradicação e recuperação.
Impacto Operacional para as Equipes de Segurança
O cenário de credenciais expostas demonstra o que o agente pode fazer para um incidente individual, mas o impacto maior está na transformação das operações diárias:
Menos tempo em coleta de evidências: O agente investigador automatiza a parte mais demorada das investigações — reunir e correlacionar evidências de múltiplas fontes. Em vez de gastar uma hora em análise manual de logs, você pode dedicar a maior parte desse tempo a decisões de contenção e prevenção de recorrências.
Investigação em linguagem natural: O agente investigador utiliza processamento de linguagem natural (NLP), permitindo descrever o que você está investigando em linguagem natural, como “chamadas de API incomuns do endereço IP X” ou “acesso a dados com credenciais de funcionário desligado”. O agente traduz essas descrições em consultas técnicas necessárias, eliminando a necessidade de ser um especialista em formatos de logs da AWS ou conhecer a sintaxe exata para consultar o CloudTrail.
Base sólida para investigações precisas: O agente investigador realiza a investigação inicial — reunindo evidências, identificando padrões e fornecendo um resumo abrangente. Se seu caso exigir análise mais profunda ou orientação em cenários complexos, você pode envolver a equipe especializada da AWS, que pode construir imediatamente sobre o trabalho que o agente já realizou, acelerando seu tempo de resposta. Eles veem as mesmas evidências e cronologia, podendo focar em análise avançada de ameaças e estratégias de contenção em vez de começar do zero.
Configuração e Primeiros Passos
Se você já tem o Security Incident Response habilitado, as capacidades de investigação com inteligência artificial estão disponíveis agora — nenhuma configuração adicional é necessária. Crie seu próximo caso de segurança e o agente começará a trabalhar automaticamente.
Se você é novo no Security Incident Response, aqui está como configurar:
Habilite o Security Incident Response através da sua conta de gerenciamento do AWS Organizations. Isso leva alguns minutos através do Console de Gerenciamento da AWS e fornece cobertura em todas as suas contas.
Crie um caso. Descreva o que você está investigando; você pode fazer isso através do console do Security Incident Response, uma API, ou configurar criação automática de casos a partir de alertas do Amazon GuardDuty ou AWS Security Hub.
Analise os resultados. O agente apresenta suas descobertas através do console do Security Incident Response, ou você pode acessá-las através de seus sistemas de tickets existentes, como Jira ou ServiceNow.
Considerações Técnicas e Segurança
O agente investigador utiliza a função ligada ao serviço de suporte da AWS para reunir informações de seus recursos. Essa função é criada automaticamente quando você configura sua conta da AWS e fornece o acesso necessário para ferramentas de suporte consultarem eventos do CloudTrail, configurações do IAM, detalhes do EC2 e dados de custos. Todas as ações realizadas pelo agente são registradas no CloudTrail para auditoria completa.
O agente investigador está incluído sem custo adicional com o Security Incident Response, que agora oferece preços medidos com um nível gratuito cobrindo seus primeiros 10 mil achados ingeridos por mês. Após esse limite, os achados são faturados em taxas que diminuem com volume. Com essa abordagem baseada em consumo, você pode escalar suas capacidades de resposta a incidentes de segurança conforme suas necessidades crescem.
Integração com Ferramentas Existentes
Casos do Security Incident Response podem ser criados por clientes ou proativamente pelo serviço. O agente investigador é acionado automaticamente quando um novo caso é criado, e os casos podem ser gerenciados através do console, API ou integrações do Amazon EventBridge. Você pode usar o EventBridge para construir fluxos de trabalho automatizados que roteiem eventos de segurança do GuardDuty, Security Hub e do próprio Security Incident Response para criar casos e iniciar planos de resposta, possibilitando pipelines completos de detecção para investigação.
Antes do agente investigador iniciar seu trabalho, o sistema de auto-triagem do serviço monitora e filtra achados de segurança do GuardDuty e ferramentas de segurança de terceiros através do Security Hub. Ele utiliza informações específicas do cliente, como endereços IP conhecidos e entidades do IAM, para filtrar achados com base no comportamento esperado, reduzindo o volume de alertas enquanto escalona alertas que exigem atenção imediata. Isso garante que o agente investigador se concentre em alertas que realmente necessitam investigação.
Conclusão
A adição do agente investigador ao AWS Security Incident Response automatiza a coleta e análise de evidências, reduzindo o tempo necessário para investigar eventos de segurança de horas para minutos. O agente faz perguntas esclarecedoras para compreender suas preocupações específicas, consulta automaticamente múltiplas fontes de dados da AWS, correlaciona evidências e apresenta uma cronologia e resumo abrangente, mantendo transparência e auditoria completas.
Com a adição do agente investigador, clientes do Security Incident Response agora recebem a velocidade e eficiência da automação impulsionada por IA, apoiadas pela expertise e supervisão de especialistas em segurança da AWS quando necessário. As capacidades de investigação com inteligência artificial estão disponíveis hoje em todas as regiões comerciais da AWS onde o Security Incident Response opera. Para saber mais sobre preços e recursos, ou para começar, visite a página do produto AWS Security Incident Response.
O que mudou: Apache Spark 4.0.1 no Amazon EMR Serverless
A AWS disponibilizou em preview o suporte ao Apache Spark 4.0.1 no Amazon EMR Serverless. Esta atualização traz melhorias significativas para a construção e manutenção de pipelines de dados, com foco em acessibilidade, conformidade e aplicações em tempo real. As novas capacidades permitem que as equipes reduzam débito técnico, iterem mais rapidamente e garantam precisão e consistência dos dados.
Principais capacidades do Spark 4.0.1
SQL ANSI padrão para pipelines acessíveis
Uma das grandes mudanças é a possibilidade de construir pipelines de dados utilizando SQL ANSI padrão, tornando a tecnologia acessível a um público muito maior. Desenvolvedores e analistas que não dominam linguagens de programação como Python ou Scala agora podem contribuir efetivamente no desenvolvimento de pipelines, democratizando o acesso a ferramentas de processamento de dados em larga escala.
Suporte nativo a dados semi-estruturados com VARIANT
O Spark 4.0.1 oferece suporte nativo a JSON e dados semi-estruturados através dos tipos de dados VARIANT. Isso proporciona maior flexibilidade para trabalhar com diversos formatos de dados, um requisito cada vez mais comum em ambientes heterogêneos de dados.
Conformidade e governança com Apache Iceberg v3
Outro destaque é a integração com Apache Iceberg v3 no formato de tabelas. O Iceberg oferece garantias de transação e rastreia como os dados mudam ao longo do tempo, criando trilhas de auditoria essenciais para atender a requisitos regulatórios. Com isso, organizações conseguem fortalecer seus frameworks de conformidade e governança de forma significativa.
Streaming em tempo real mais ágil
O Spark 4.0.1 introduz controles de streaming aprimorados que permitem gerenciar operações com estado complexo e monitorar jobs de streaming com facilidade. Essas melhorias habilitam casos de uso como detecção de fraude e personalização em tempo real, tecnologias críticas para negócios modernos.
Disponibilidade e próximos passos
O Apache Spark 4.0.1 está disponível em preview em todas as regiões onde o EMR Serverless opera, com exceção das regiões China e AWS GovCloud (US).
Quando a IA generativa se tornou mainstream, a AWS lançou a Matriz de Escopo de Segurança para IA Generativa para ajudar organizações a compreender e lidar com os desafios únicos de segurança em aplicações baseadas em modelos de fundação. Esse framework foi amplamente adotado não apenas por clientes da AWS, mas também referenciado por organizações como OWASP, CoSAI e outros órgãos de padronização da indústria, parceiros e integradores de sistemas.
Agora, conforme sistemas de IA agêntica com capacidades de chamadas de funções e tomada de decisão autônoma emergem, surge a necessidade de um framework complementar para lidar com um conjunto totalmente novo de desafios de segurança. Diferentemente dos modelos de fundação tradicionais que operam em padrões previsíveis de solicitação e resposta, os sistemas agênticos introduzem capacidades autônomas, memória persistente, orquestração de ferramentas, desafios de identidade e agência, além de integração com sistemas externos. Isso expande significativamente os riscos que as organizações precisam gerenciar.
Sistemas de IA agêntica podem executar tarefas multietapas de forma autônoma, tomar decisões e interagir com infraestrutura e dados. Essa transformação fundamental exige que as organizações se adaptem a uma realidade diferente daquela dos modelos de fundação convencionais. Após trabalhar com clientes que implementam esses sistemas, observou-se que os frameworks tradicionais de segurança em IA nem sempre se estendem adequadamente para o espaço agêntico. A natureza autônoma desses sistemas demanda abordagens de segurança fundamentalmente diferentes.
Para preencher essa lacuna, a AWS desenvolveu a Matriz de Escopo de Segurança para IA Agêntica: um modelo conceitual e um framework que categoriza quatro arquiteturas agênticas distintas com base em níveis de conectividade e autonomia, mapeando controles críticos de segurança em cada uma delas.
Distinção entre agência e autonomia
Os sistemas de IA generativa tradicional funcionam em um padrão bem compreendido e previsível: recebem uma instrução ou prompt, geram uma resposta e encerram a sessão. Controles de segurança e conformidade focam em medidas básicas como validação de entrada, filtragem de saída e guardrails de moderação de conteúdo. Esse modelo funciona porque as falhas de segurança têm escopo limitado — uma interação comprometida afeta apenas aquele request e response específico, sem persistir ou se propagar para outros sistemas ou usuários.
Sistemas agênticos transformam fundamentalmente esse modelo de segurança. Agentes iniciadores podem agir com base em objetivos e gatilhos ambientais que podem ou não exigir prompts humanos ou aprovação. Isso cria riscos de ações não autorizadas, processos descontrolados e decisões que extrapolam os limites pretendidos quando agentes interpretam incorretamente objetivos ou operam com instruções comprometidas.
Ao discutir IA agêntica, é essencial esclarecer a distinção entre dois conceitos relacionados mas distintos: agência e autonomia. Esses conceitos informam diretamente a estratégia de segurança.
Agência refere-se ao escopo de ações que um sistema de IA é autorizado e capaz de executar dentro do ambiente operacional, e quanto um humano delimita as ações ou capacidades do agente. Inclui quais sistemas ele pode interagir, quais operações pode realizar e quais recursos pode modificar. Agência é fundamentalmente sobre capacidades e permissões — o que o sistema está autorizado a fazer.
Autonomia, em contraste, refere-se ao grau de tomada de decisão e ação independente que o sistema pode exercer sem intervenção humana. Inclui quando opera, como escolhe entre ações disponíveis e se requer aprovação humana para execução. Autonomia é sobre independência na tomada de decisão e execução — com quanto liberalismo o sistema pode agir dentro de sua agência concedida.
Por exemplo, um agente de IA pode ter alta agência (capaz de executar muitas ações) mas baixa autonomia (exigindo aprovação humana para cada ação), ou vice-versa. Compreender essa distinção é fundamental para implementar controles de segurança apropriados. Agência requer sistemas de fronteiras e permissões, enquanto autonomia requer mecanismos de supervisão e controles comportamentais.
Capacidades centrais dos sistemas agênticos e seus riscos
Vários fatores chave diferenciam os sistemas agênticos dos modelos tradicionais e ampliam os desafios de segurança:
Execução autônoma e agência: Agentes podem iniciar ações com base em objetivos e gatilhos ambientais, criando riscos de ações não autorizadas e processos descontrolados quando agentes interpretam incorretamente objetivos ou operam com instruções comprometidas.
Memória persistente: Agentes frequentemente mantêm contexto e comportamentos aprendidos entre sessões, construindo bases de conhecimento que informam decisões futuras. Essa persistência de dados introduz requisitos adicionais de proteção de dados e novos vetores de risco, como ataques de envenenamento de memória, onde adversários injetam informações falsas que corrompem a tomada de decisão entre múltiplas interações e usuários.
Orquestração de ferramentas: Agentes se integram diretamente via funções com conexões a bancos de dados, APIs, serviços e potencialmente outros agentes. Essa superfície de ataque expandida cria riscos de compromissos em cascata, onde uma única falha em um agente pode se propagar através de sistemas conectados, workflows multiagente e serviços e armazenamentos de dados a jusante.
Conectividade externa: Agentes operam através de limites de rede, acessando recursos da internet, APIs de terceiros e sistemas empresariais. Essa conectividade expandida pode desbloquear novo valor comercial, mas deve ser projetada com controles de segurança que limitem riscos como exfiltração de dados, movimento lateral e manipulação externa.
Comportamento autodirecionado: Agentes avançados podem iniciar atividades com base no monitoramento ambiental, agendamento ou padrões aprendidos, sem instanciação ou revisão humana. Essa autodireção introduz riscos de operações descontroladas, explicabilidade limitada e auditabilidade reduzida, dificultando a manutenção de fronteiras de segurança previsíveis.
A Matriz de Escopo de Segurança para IA Agêntica
Trabalhando com clientes e a comunidade, a AWS identificou quatro escopos arquiteturais que representam a evolução dos sistemas de IA agêntica, baseados em duas dimensões críticas: o nível de supervisão humana comparado à autonomia e o nível de agência que o sistema de IA tem permissão para exercer. Cada escopo introduz novas capacidades — e requisitos de segurança correspondentes — que as organizações devem priorizar ao lidar com riscos agênticos.
Neste escopo mais básico, os sistemas operam com processos iniciados por humanos e nenhuma capacidade de mudança autônoma ou mesmo aprovada por humanos através do agente. Os agentes são, essencialmente, apenas leitura. Esses sistemas seguem caminhos de execução predefinidos e operam sob workflows rigorosamente acionados por humanos, geralmente predefinidos e com etapas discretas.
O foco de segurança é primariamente na integridade do processo e na aplicação de limites, ajudando operações a permanecerem dentro de limites predeterminados. Agentes são altamente controlados e proibidos de executar mudanças e ações sem limites.
Características principais: Agentes não podem executar mudanças diretas no ambiente, execução passo a passo seguindo caminhos predeterminados, componentes de IA generativa processam dados dentro de nós individuais de workflow, ramificação condicional apenas onde explicitamente projetada no workflow, nenhum comportamento de planejamento dinâmico ou busca autônoma de objetivos, persistência de estado limitada ao contexto de execução de workflow, acesso a ferramentas restrito a etapas específicas de workflow predefinidas.
Foco de segurança: Proteger integridade de dados dentro do ambiente e restringir agentes para não exceder limites, especialmente em relação à modificação de ambiente e dados. As preocupações primárias incluem asegurar transições de estado entre etapas, validar dados passados entre nós de workflow e prevenir componentes de IA de modificarem a lógica de orquestração ou escaparem de seus limites designados.
Exemplo: Imagine um agente projetado para ajudar na criação de convites de calendário. No Escopo 1, você instancia um agente através de um workflow para examinar seu calendário e o de um colega em busca de horários disponíveis. O agente executa uma busca contextual usando um servidor Model Context Protocol conectado à aplicação de calendário empresarial. Ele só tem permissão para consultar horários disponíveis, analisar os melhores momentos para encontro e fornecer uma resposta, que você então usa manualmente para agendar a reunião. Neste exemplo, o humano define workflows específicos (sem agência) e revisa e aprova ações (sem mudança autônoma).
Escopo 2: Agência prescrita
Movendo-se para cima em agência e risco, sistemas de Escopo 2 também são instanciados por um humano, mas agora têm potencial para executar ações — agência limitada — que poderiam alterar o ambiente. Contudo, todas as ações executadas por um agente requerem aprovação humana explícita para todas as ações de consequência, comumente referida como human-in-the-loop (HITL).
Esses sistemas podem coletar informações, analisar dados e preparar recomendações, mas não podem executar ações que modifiquem sistemas externos ou acessem recursos sensíveis sem autorização humana. Agentes também podem solicitar entrada humana para esclarecer ambiguidades, fornecer contexto faltante ou otimizar sua abordagem antes de apresentar recomendações.
Características principais: Agentes podem executar mudanças no ambiente com revisão e aprovação humana, supervisão humana em tempo real com workflows de aprovação, interação bidirecional humano-agente, ações autônomas limitadas a operações apenas leitura, solicitações iniciadas pelo agente para esclarecimento ou informação adicional, trilhas de auditoria de todas as decisões de aprovação humana.
Foco de segurança: Implementar workflows de aprovação robustos e prevenir agentes de contornarem controles de autorização humana. Preocupações chave incluem prevenir escalação de privilégios, aplicar contextos de identidade apropriados, asegurar o processo de aprovação, validar contexto fornecido por humano para prevenir ataques de injeção, e manter visibilidade em todas as recomendações de agente e seu raciocínio.
Exemplo: Um sistema agêntico de Escopo 2 é instanciado por um humano. O agente consulta disponibilidade do calendário das partes interessadas, realiza sua análise e retorna uma recomendação de horário para reunião ao usuário, perguntando se o usuário quer que o agente envie o convite em seu nome. O usuário revisa a resposta e recomendação do agente, valida se atende seus requisitos e então reconhece e aprova a solicitação do agente de modificar os calendários e enviar o convite. Neste exemplo, o humano orquestra um workflow estruturado, mas o agente agora pode instanciar mudança revisada por humano através de ações delimitadas (agência limitada e autonomia limitada).
Escopo 3: Agência supervisionada
No Escopo 3, expande-se a agência para permitir um grau maior de autonomia agêntica — agência alta — na execução. Esses são sistemas de IA que executam tarefas autônomas complexas iniciadas por humanos, com a capacidade de tomar decisões e executar ações em sistemas conectados sem aprovação ou mecanismos de HITL adicionais.
Humanos definem objetivos e disparam execução, mas agentes operam independentemente para alcançar objetivos através de planejamento dinâmico e uso de ferramentas. Durante execução, agentes podem solicitar orientação humana para otimizar trajetória ou lidar com casos extremos, embora possam continuar operando sem ela.
Características principais: Agentes podem executar mudanças no ambiente sem interação ou revisão humana adicional (ou opcionalmente), execução acionada por humano com conclusão autônoma de tarefa, planejamento dinâmico e tomada de decisão durante execução, pontos opcionais de intervenção humana para otimização de trajetória, capacidade humana de ajustar parâmetros ou fornecer contexto durante execução, acesso direto a APIs e sistemas externos para conclusão de tarefa, memória persistente entre sessões de execução estendida, seleção e orquestração autônoma de ferramentas dentro de limites definidos.
Foco de segurança: Implementar monitoramento abrangente de ações do agente durante fases de execução autônoma e estabelecer limites claros de agência para operações agentes. Preocupações críticas incluem asegurar o canal de intervenção humana para prevenir modificações não autorizadas, prevenir aumento de escopo durante execução de tarefa, implementar construtos de propagação de identidade confiável, monitorar anomalias comportamentais e validar que agentes permanecem alinhados com intenção humana original mesmo quando ajustes de trajetória são feitos.
Exemplo: Um sistema agêntico de Escopo 3 ainda é instanciado por um humano. O agente consulta disponibilidade do calendário das partes interessadas, realiza análise e retorna uma recomendação de horário para reunião ao usuário. Contudo, está dentro dos limites do agente atuar sobre sua própria recomendação em nome do usuário para automaticamente agendar o melhor slot disponível. O usuário não é solicitado ou se espera que dê permissão ao agente para isso antes de suas ações. O resultado é que todas as partes interessadas têm uma entrada de calendário adicionada em seu calendário no contexto do usuário chamador. Neste exemplo, o humano define um resultado mas com mais liberdade para o agente determinar como alcançar aquele objetivo, e o agente agora pode executar ação autônoma sem revisão humana (agência alta e autonomia alta).
Escopo 4: Agência completa
O Escopo 4 inclui sistemas de IA totalmente autônomos que podem iniciar suas próprias atividades com base no monitoramento ambiental, padrões aprendidos ou condições predefinidas, e executar tarefas complexas sem intervenção humana. Esses sistemas representam o mais alto nível de agência de IA, operando continuamente e tomando decisões independentes sobre quando e como agir.
É crucial notar que sistemas de IA dentro do Escopo 4 poderiam ter agência completa ao executar dentro de seus limites designados; portanto, é essencial que humanos mantenham supervisão de vigilância com capacidade de fornecer orientação estratégica, correções de curso ou intervenções quando necessário. Mecanismos contínuos de conformidade, auditoria e gerenciamento de ciclo de vida completo — tanto revisões humanas quanto automatizadas, potencialmente auxiliadas por IA — são críticos para asegurar e governar sistemas agênticos de Escopo 4 enquanto se limitam os riscos.
Características principais: Iniciação de atividades autodirecionadas com base em gatilhos ambientais, operação contínua com supervisão humana mínima durante execução, capacidade humana de injetar orientação estratégica sem interromper operações, altos a plenos graus de autonomia em definição de objetivo, planejamento e execução, interação dinâmica com múltiplos sistemas e agentes externos, capacidade para auto-melhoria recursiva e expansão de capacidade.
Foco de segurança: Implementar guardrails avançados para monitoramento comportamental, detecção de anomalias, controles de acesso a ferramentas baseados em escopo e mecanismos à prova de falha para prevenir operações descontroladas. Preocupações primárias incluem manter alinhamento com objetivos organizacionais, asegurar canais de intervenção humana contra manipulação adversarial, prevenir expansão de capacidade não autorizada, prevenir que mecanismos de supervisão humana sejam desabilitados pelo agente e permitir degradação graciosa quando agentes encontram situações inesperadas.
Exemplo: Considere como nosso exemplo de calendário poderia ser deployado em Escopo 4. Suponha que você tenha implementado um sumarizador de IA generativa para reunião. Esse agente é habilitado automaticamente quando você hospeda uma videoconferência. Ao fim da reunião, o agente sumarizador observa uma nova reunião que ocorreu e o agente de calendário vê isso. Ele examina itens de ação que foram sumarizados e determina que seis pessoas concordaram em uma sessão de whiteboarding na sexta. O agente de calendário poderia ter uma configuração de API estaticamente definida ou alavancar descoberta dinâmica em servidores MCP para ajudar com calendário. Ele então encontra disponibilidade para os seis recursos identificados e agenda o melhor slot. Usa então o contexto de identidade apropriado do usuário solicitando a reunião para agendar a reunião autonomamente. Em nenhum ponto um usuário instancia diretamente a solicitação de calendário; é totalmente automatizado e acionado por mudanças ambientais que o agente é instruído a buscar (agência completa e autonomia completa).
Dimensões críticas de segurança entre escopos
À medida que as organizações progridem pelos escopos, os requisitos de segurança aumentam em complexidade e escopo. Seis dimensões críticas de segurança devem ser consideradas:
Contexto de identidade (autenticação e autorização): Do Escopo 1 ao 4, evoluindo de autenticação básica de usuário para autenticação de serviço, delegação de identidade para ações autônomas, dinamicidade completa de ciclo de vida de identidade e autenticação federada.
Proteção de dados, memória e estado: Começando com permissões de recurso local e controle de acesso ao sistema de arquivos, progredindo para autorização baseada em função, elevação de privilégio just-in-time e finalmente para controles de autorização adaptativos e validação de autorização contínua.
Auditoria e logging: Evoluindo de logs de atividade local para trilhas de auditoria de decisão humana, captura de cadeia de raciocínio agente, logging comportamental contínuo e análise preditiva.
Controles de agente e modelo de fundação: Isolamento de processo em Escopo 1 progredindo para análise comportamental e detecção de anomalias em escopos posteriores, com contenção automatizada em Escopos 3 e 4.
Perímetros de agência e políticas: Limites de execução fixa em Escopo 1 evoluindo para ajuste de limite dinamicamente e adaptação autônoma em Escopos 3 e 4.
Orquestração: Orquestração simples de workflow em Escopo 1 progredindo para descoberta dinâmica de serviço e aprendizado entre sessões em Escopos 3 e 4.
Implementação de padrões arquiteturais bem-sucedidos
Deployments bem-sucedidos de sistemas agênticos compartilham padrões comuns que balanceiam autonomia com controle:
Deployment progressivo de autonomia: Iniciar com implementações de Escopo 1 ou 2 e gradualmente avançar pelos escopos conforme a confiança organizacional e capacidades de segurança amadurecem. Essa abordagem minimiza risco enquanto constrói experiência operacional. Seja cauteloso e seletivo ao analisar casos de uso e definir limites de controle para implementações de Escopo 4.
Arquitetura de segurança em camadas: Implementar defesa em profundidade com controles de segurança em múltiplos níveis — rede, aplicação, agente e camadas de dados. Esforce-se particularmente em endereçar preocupações de identidade e autorização para máquinas e humanos, prevenindo problemas como o problema do deputy confuso — quando um humano ou serviço com menores permissões consegue elevar permissões através de agentes que podem ter mais direitos.
Loops contínuos de validação: Estabelecer sistemas automatizados que continuamente verificam comportamento do agente contra padrões esperados, com procedimentos de escalação quando desvios são detectados. Auditabilidade e explicabilidade são requisitos chave para confirmar que agentes estão operando dentro dos limites pretendidos e para ajudar determinar efetividade de controle.
Integração de supervisão humana: Mesmo em sistemas altamente autônomos, manter supervisão humana significativa através de checkpoints estratégicos, relatórios comportamentais e capacidades de override manual. A supervisão humana não diminui de Escopo 1 para 4; ela simplesmente muda foco. Em Escopos 1 e 2, o requisito humano de instanciar, revisar e aprovar ações agentes é alto. Em Escopos 3 e 4 é menor, mas o requisito humano de auditar, avaliar, validar e implementar controles de segurança e operacionais mais complexos é muito maior.
Degradação graciosa: Desenhar sistemas para automaticamente reduzir níveis de autonomia quando eventos de segurança são detectados, permitindo operações continuarem seguramente enquanto operadores humanos investigam. Se agentes começarem a agir além dos limites pretendidos de seu design, comportamento anômalo é detectado, ou começam executar ações particularmente arriscadas ou sensíveis ao seu negócio, considere ter controles detetivos que automaticamente injetem restrições mais apertadas, como exigir mais HITL ou reduzir as ações que um agente pode executar.
Conclusão
A Matriz de Escopo de Segurança para IA Agêntica fornece um modelo mental estruturado e um framework para compreender e endereçar os desafios de segurança de sistemas autônomos agênticos de IA em quatro escopos distintos. Ao avaliar acuradamente seu escopo atual e implementar controles apropriados em todas as seis dimensões críticas de segurança, as organizações podem confidentemente deployar IA agêntica enquanto gerenciam a paisagem de riscos associados.
A progressão de agentes básicos e altamente constrangidos para agentes totalmente autônomos e até mesmo autodirecionados representa uma mudança fundamental em como abordamos segurança de IA. Cada escopo requer capacidades de segurança específicas, e as organizações devem construir essas capacidades sistematicamente para apoiar suas ambições agênticas de forma segura.
Próximos passos
Para implementar a Matriz de Escopo de Segurança para IA Agêntica em sua organização:
Avalie seus casos de uso agênticos atuais e maturidade em relação aos quatro escopos para compreender seus requisitos de segurança e riscos associados.
Integre a matriz em seus processos de procurement e SDLC.
Identifique lacunas de capacidade nas seis dimensões de segurança para seu escopo-alvo.
Desenvolva uma estratégia de deployment progressivo que constrói capacidades de segurança conforme você avança pelos escopos.
Implemente monitoramento contínuo e análise comportamental apropriada para seu nível de escopo.
Estabeleça processos de governança para progressão de escopo e validação de segurança.
Treine seus times nos desafios de segurança únicos de cada escopo.
À medida que as organizações ampliam a adoção de capacidades de inteligência artificial em seus aplicativos, surge um desafio crítico: como centralizar o gerenciamento, a segurança e o controle de custos do acesso a modelos de IA? Esse é um passo fundamental para escalar soluções de IA de forma consistente e controlada.
Para empresas que trabalham com IA generativa, o cenário se torna particularmente complexo. As equipes frequentemente precisam acessar diferentes modelos de IA de diversos provedores — Amazon Bedrock, Amazon SageMaker AI, OpenAI, Anthropic e outros — cada um com suas próprias APIs, métodos de autenticação e modelos de faturamento. Sem um ponto de acesso unificado, as organizações enfrentam dificuldades para implementar políticas de segurança consistentes, monitorar o uso e controlar custos em todos os serviços de IA.
Os Principais Obstáculos na Operação de IA em Larga Escala
Fragmentação de Provedores
A diversidade de fornecedores de modelos cria uma fragmentação operacional significativa. Cada provedor apresenta interfaces diferentes, mecanismos de autenticação distintos e estruturas de preço variadas. Essa pluralidade, embora ofereça flexibilidade, aumenta a complexidade operacional.
Governança Descentralizada
Sem uma interface central, é extremamente desafiador manter políticas de segurança uniformes, rastrear o uso de modelos e controlar gastos de forma centralizada. Cada equipe pode operar de forma isolada, dificultando a visibilidade global e o cumprimento de padrões corporativos.
Complexidade Operacional
Gerenciar múltiplos paradigmas de acesso — que variam desde funções de AWS Identity and Access Management até chaves de API, limites de taxa específicos de modelos e estratégias de failover — cria sobrecarga operacional e aumenta o risco de interrupções no serviço.
Controle de Custos
Compreender e controlar gastos com IA em múltiplos provedores e equipes se torna cada vez mais difícil à medida que o uso escala. Sem visibilidade centralizada, é fácil perder o controle do orçamento destinado a operações de IA.
Segurança e Conformidade
Implementar políticas de segurança consistentes e manter trilhas de auditoria em diferentes provedores de IA apresenta desafios significativos para a governança corporativa.
A Solução: Gateway de IA Multiprovedora
Para endereçar esses desafios comuns, a AWS ofereceu uma arquitetura de referência que fornece um gateway centralizado capaz de abstrair a complexidade de múltiplos provedores de IA atrás de uma interface única e gerenciada. Construída sobre serviços AWS e utilizando o projeto open source LiteLLM, essa solução permite que as organizações se integrem com diversos provedores de IA enquanto mantêm controle centralizado, segurança e observabilidade robustas.
A Generative AI Gateway on AWS é uma arquitetura de referência para empresas que desejam implementar soluções completas de IA generativa, com múltiplos modelos, respostas enriquecidas por dados e capacidades de agentes em formato auto-hospedado. Essa orientação combina o amplo acesso a modelos do Amazon Bedrock, a experiência unificada de desenvolvedor do Amazon SageMaker AI e os recursos robustos de gerenciamento do LiteLLM, tudo enquanto oferece suporte a acesso a modelos de provedores externos de forma mais segura e confiável.
Flexibilidade de Implantação na AWS
A solução oferece múltiplos padrões de implantação para atender às necessidades diversas das organizações.
Implantação em Amazon ECS
Para equipes que preferem aplicações containerizadas com infraestrutura gerenciada, a opção Amazon ECS oferece orquestração de containers sem servidor, com dimensionamento automático e balanceamento de carga integrado.
Implantação em Amazon EKS
Organizações com experiência existente em Kubernetes podem utilizar a opção Amazon EKS, que oferece controle total sobre a orquestração de containers enquanto se beneficia de um plano de controle Kubernetes gerenciado. É possível implantar um novo cluster ou aproveitar clusters existentes.
Vale notar que a arquitetura de referência fornecida está sujeita a testes de segurança adicionais baseados nos requisitos específicos da organização. É recomendável conduzir testes de segurança e revisão antes de implantar em produção.
Opções de Arquitetura de Rede
O gateway oferece múltiplas configurações de rede para diferentes cenários operacionais.
Implantação Pública Global
Para serviços de IA com base de usuários global, o gateway pode ser combinado com Amazon CloudFront e Amazon Route 53. Essa configuração fornece proteção aprimorada contra DDoS com AWS Shield, gerenciamento simplificado de HTTPS com certificados padrão do CloudFront, cache global em edge locations para reduzir latência e roteamento inteligente de tráfego entre regiões. Esta é a configuração recomendada para serviços de IA com alcance global.
Acesso Direto Regional
Para implantações em uma única região que priorizam baixa latência e otimização de custos, acesso direto ao Application Load Balancer (ALB) remove a camada de CloudFront mantendo segurança através de grupos de segurança e ACLs de rede adequadamente configurados.
Acesso Privado Interno
Organizações que exigem isolamento completo podem implantar o gateway dentro de uma VPC privada sem exposição à internet. Essa configuração garante que o acesso a modelos de IA permaneça dentro do perímetro de segurança, com grupos de segurança do ALB restringindo tráfego apenas aos CIDRs de sub-redes privadas autorizadas. O acesso pode ser restrito a redes confiáveis como VPN, Direct Connect, VPC peering ou AWS Transit Gateway.
Governança e Gerenciamento Abrangentes de IA
O gateway foi construído para habilitar padrões robustos de governança de IA através de uma interface administrativa simplificada. Além de gerenciamento de acesso e configuração baseada em políticas, usuários podem configurar capacidades avançadas como balanceamento de carga e cache de prompts.
Interface de Administração Centralizada
O Gateway de IA Generativa inclui uma interface administrativa baseada em web no LiteLLM que oferece suporte a gerenciamento abrangente do uso de LLMs em toda a organização. As capacidades principais incluem:
Gerenciamento de usuários e equipes: Configure controles de acesso em níveis granulares, de usuários individuais a equipes inteiras, com permissões baseadas em papéis que se alinham com a estrutura organizacional.
Gerenciamento de chaves de API: Gerencie centralmente e rotacione chaves de API para provedores de IA conectados mantendo trilhas de auditoria de uso e padrões de acesso.
Controles de orçamento e alertas: Configure limites de gastos por provedor, equipe e usuário individual com alertas automatizados quando limiares se aproximam ou são excedidos.
Controles de custo abrangentes: Os custos são influenciados pela infraestrutura AWS e provedores de LLM. Embora seja responsabilidade do cliente configurar a solução para atender seus requisitos de custo, as organizações podem revisar as configurações de custo existentes para orientação adicional.
Suporte a múltiplos provedores de modelos: Compatível com Boto3, OpenAI e LangGraph SDK, permitindo que clientes usem o melhor modelo para cada carga de trabalho independentemente do provedor.
Suporte a Amazon Bedrock Guardrails: Clientes podem aproveitar guardrails criados no Amazon Bedrock para suas cargas de trabalho de IA generativa, independentemente do provedor de modelo.
Roteamento Inteligente e Resiliência
Considerações comuns sobre implantação de modelos incluem resiliência de modelos e prompts. Esses fatores são importantes para determinar como falhas são tratadas ao responder a um prompt ou acessar armazenamentos de dados.
Balanceamento de Carga e Failover
O gateway implementa lógica sofisticada de roteamento que distribui requisições entre múltiplas implantações de modelos e automaticamente realiza failover para provedores de backup quando problemas são detectados.
Lógica de Retry
Mecanismos integrados de retry com backoff exponencial facilitam entrega de serviço confiável mesmo quando provedores individuais experimentam problemas transitórios.
Cache de Prompts
Cache inteligente reduz custos evitando requisições duplicadas a modelos de IA caros enquanto mantém precisão de respostas.
Gerenciamento Avançado de Políticas
A arquitetura de implantação de modelos pode variar do simples ao extremamente complexo. O Gateway de IA Multiprovedora oferece ferramentas avançadas de gerenciamento de políticas necessárias para manter postura forte de governança:
Rate limiting: Configure políticas sofisticadas de limitação de taxa que variam por usuário, chave de API, tipo de modelo ou hora do dia para facilitar alocação justa de recursos e ajudar a prevenir abusos.
Controles de acesso a modelos: Restrinja acesso a modelos de IA específicos baseado em papéis de usuário, garantindo que modelos sensíveis ou caros sejam acessíveis apenas a pessoal autorizado.
Regras de roteamento personalizadas: Implemente lógica de negócio que roteia requisições a provedores específicos baseado em critérios como tipo de requisição, localização do usuário ou requisitos de otimização de custo.
Monitoramento e Observabilidade
À medida que cargas de trabalho de IA crescem para incluir mais componentes, as necessidades de observabilidade também crescem. A arquitetura do Gateway de IA Multiprovedora se integra com Amazon CloudWatch. Essa integração permite que usuários configurem inúmeras soluções de monitoramento e observabilidade, incluindo ferramentas open source como Langfuse.
Logging e Análise Abrangentes
As interações do gateway são automaticamente registradas no CloudWatch, fornecendo insights detalhados sobre:
Padrões de requisição e tendências de uso entre provedores e equipes
Métricas de desempenho incluindo latência, taxas de erro e throughput
Alocação de custos e padrões de gastos por usuário, equipe e tipo de modelo
Eventos de segurança e padrões de acesso para relatórios de conformidade
Troubleshooting Integrado
A interface administrativa oferece capacidades de visualização de logs em tempo real, permitindo que administradores diagnostiquem e resolvam rapidamente problemas de uso sem necessidade de acessar CloudWatch diretamente.
Integração com Amazon SageMaker para Acesso Expandido a Modelos
O Amazon SageMaker AI amplia a orientação do Gateway de IA Multiprovedora ao fornecer um sistema completo de aprendizado de máquina que se integra perfeitamente à arquitetura do gateway. Ao utilizar a infraestrutura gerenciada do SageMaker para treinamento, implantação e hospedagem de modelos, as organizações podem desenvolver modelos de fundação customizados ou ajustar finos em modelos existentes que podem ser acessados através do gateway juntamente com modelos de outros provedores.
Essa integração elimina a necessidade de gerenciamento separado de infraestrutura enquanto facilita governança consistente entre modelos customizados e de terceiros. As capacidades de hospedagem de modelos do SageMaker AI expandem o acesso de modelos do gateway para incluir modelos auto-hospedados, bem como aqueles disponíveis no Amazon Bedrock, OpenAI e outros provedores.
Começando: Ferramentas e Recursos Disponíveis
A arquitetura de referência do Gateway de IA Multiprovedora está disponível através de um GitHub repository, completo com:
O repositório de código descreve várias opções de implantação flexíveis para começar.
Gateway Público com Distribuição Global CloudFront
Use CloudFront para fornecer um ponto de acesso distribuído globalmente e com baixa latência para seus serviços de IA generativa. Os edge locations do CloudFront entregam conteúdo rapidamente aos usuários em todo o mundo, enquanto o AWS Shield Standard ajuda a proteger contra ataques DDoS. Esta é a configuração recomendada para serviços de IA com acesso público e base de usuários global.
Domínio Customizado com CloudFront
Para uma experiência mais personalizada, configure o gateway para usar seu próprio nome de domínio customizado, aproveitando ainda os recursos de desempenho e segurança do CloudFront. Essa opção é ideal quando se deseja manter consistência com a presença online da empresa.
Acesso Direto via Application Load Balancer Público
Clientes que priorizam baixa latência sobre distribuição global podem optar por implantação direta ao ALB, sem a camada CloudFront. Essa arquitetura simplificada oferece economia de custos, embora exija consideração adicional para proteção com web application firewall.
Acesso Privado Exclusivo em VPC
Para alto nível de segurança, implante o gateway inteiramente dentro de uma VPC privada, isolado da internet pública. Essa configuração é apropriada para processamento de dados sensíveis ou implantação de serviços internos de IA generativa.
Explorando Casos de Uso Práticos
A AWS também publicou um exemplo que integra o gateway em uma aplicação prática de atendimento ao cliente com agentes de IA. O sistema de agentes é orquestrado usando LangGraph e implantado em Amazon Bedrock AgentCore. As chamadas a LLM são roteadas através do gateway, oferecendo flexibilidade para testar agentes com diferentes modelos — seja hospedados na AWS ou em outro provedor.
Uma Fundação Madura para IA Generativa
Essa orientação é apenas uma parte de uma fundação madura de IA generativa na AWS. Para leitura mais profunda sobre os componentes de um sistema de IA generativa na AWS, consulte a orientação sobre Architect a mature generative AI foundation on AWS, que descreve componentes adicionais de um sistema de IA generativa.
Conclusão
O Gateway de IA Multiprovedora representa uma abordagem significativa para simplificar operações de IA em ambientes corporativos. Ao centralizar o gerenciamento, segurança e observabilidade de múltiplos provedores de modelos, as organizações conquistam maior controle sobre custos, conformidade e experiência de desenvolvimento.
A solução oferece flexibilidade de implantação através de ECS ou EKS, múltiplas opções de arquitetura de rede, e integração robusta com serviços AWS como SageMaker e CloudWatch. Para equipes brasileiras que trabalham em escala com IA, essa orientação fornece um ponto de partida bem fundamentado para implementar soluções de IA generativa de forma governada e segura.
Novo Modelo de Segurança para Ambientes Regulamentados
A AWS anunciou a disponibilidade da mais recente linha de base de segurança do Landing Zone Accelerator on AWS (LZA): a Configuração Universal. Desenvolvida a partir de anos de experiência prática com clientes altamente regulamentados, incluindo órgãos governamentais de diversos países, e contando com a consulta de parceiros AWS e especialistas do setor, esta configuração foi construída especificamente para ajudar organizações a implementar segurança e conformidade em escala para cargas de trabalho reguladas.
Ao estabelecer um alto padrão com as mais recentes práticas de segurança da AWS, a Configuração Universal busca atender aos requisitos de controles técnicos de diferentes frameworks de conformidade, abrangendo várias regiões geográficas e verticais de indústria.
Arquitetura Multi-Conta e Preparação para o Futuro
A arquitetura de segurança multi-conta da Configuração Universal fornece uma fundação robusta para hospedar suas necessidades diversas de cargas de trabalho hoje, ao mesmo tempo em que oferece a possibilidade de explorar soluções de inteligência artificial generativa e IA agentic que moldarão o futuro da sua organização.
Um dos principais diferenciais é a capacidade de substituir meses de planejamento e design complexo. Ao implantar um ambiente abrangente orientado por segurança e conformidade, baseado nos princípios do AWS Well-Architected, o processo leva apenas horas. Essa velocidade de implementação é transformadora para organizações que precisam balancear inovação com rigor regulatório.
Conformidade Escalável em Qualquer Estágio
À medida que as organizações crescem, frequentemente precisam aderir a novas certificações de segurança e conformidade. O LZA e a Configuração Universal apoiam organizações de qualquer tamanho e fase em sua jornada de segurança e conformidade.
A velocidade de implantação, documentação passo a passo e recursos de conformidade podem reduzir cronogramas tradicionais de avaliação e autorização em meses, resultando em auditorias mais previsíveis e bem-sucedidas. Isso permite que as organizações direcionem recursos para crescimento empresarial, em vez de enfrentar dilemas entre segurança e conformidade.
Principais Benefícios da Configuração Universal
Automatiza a implantação de um ambiente AWS multi-conta seguro
Estabelece controles de segurança fundamentados nas melhores práticas do AWS Well-Architected
Aplica controles de segurança consistentes e previsíveis após a implantação
Integra-se nativamente com serviços de segurança, identidade e conformidade da AWS
Implementa controles em múltiplas camadas de sistema
Fornece arquitetura de segurança em nível organizacional
Inclui controles preventivos, proativos e detetivos em perímetro e recursos específicos
Suporta resiliência multi-região, recuperação de desastres e failover ativo
Estabelece fundações para prontidão em segurança e conformidade
Incorpora melhores práticas de segurança AWS com declarações de implementação técnica
Mapeia capacidades do LZA em frameworks de conformidade globais e específicos por indústria
Implanta centenas de controles em horas, não em meses
O Manuais de Conformidade do LZA
O mecanismo do LZA tem sido uma ferramenta confiável para implantar rapidamente ambientes AWS multi-conta seguros por mais de 4 anos. Além disso, é eficiente em termos de custo — você paga apenas pelos serviços AWS utilizados para operar seu ambiente.
A Configuração Universal é o primeiro modelo de configuração acompanhado pelo Manuais de Conformidade do LZA, disponível no AWS Artifact. Trata-se de um recurso inédito que apresenta mapeamentos detalhados de controles, demonstrando como a Configuração Universal pode atender a requisitos de diversos frameworks, incluindo NIST 800-53 Rev5, CMMC/NIST 800-171, ISO-27001, HIPAA, C5:2020, NATO D-32 (Apêndice B) e DoD CCI.
O Manuais de Conformidade é mantido regularmente para refletir a versão mais recente da linha de base da Configuração Universal, e incluirá mapeamentos de conformidade adicionais em futuros lançamentos. O documento contém descrições detalhadas de configuração de segurança baseadas nos arquivos de implantação da Configuração Universal, junto com mapeamentos de requisitos de controle e declarações de implementação que traduzem suas capacidades de segurança em um formato amigável à conformidade.
Ao combinar as melhores práticas de segurança da AWS com experiência global em conformidade, a Configuração Universal entrega resultados de segurança previsíveis, ao mesmo tempo em que ajuda a organização a atender requisitos regionais e específicos da indústria.
Como Começar
Para iniciar com a Configuração Universal do Landing Zone Accelerator on AWS, o Guia de Implementação do LZA orientará você através dos passos, casos de uso e considerações ao fazer a implantação com o LZA.
Você pode utilizar a ferramenta AWS Partner Finder e buscar por solução para Landing Zone Accelerator e descobrir as ofertas mais recentes de parceiros especializados em LZA.
