Na AWS, existe uma cultura organizacional baseada em discussões honestas e transparentes sobre oportunidades de crescimento, que permite investimentos contínuos e inovação para elevar constantemente o padrão de entrega de valor aos clientes. Recentemente, a empresa compartilhou um exemplo prático dessa abordagem ao detalhar o Mantle, seu novo motor de inferência para o Amazon Bedrock.
À medida que as cargas de trabalho de inferência e fine-tuning de IA generativa evoluem, também evolui a necessidade de servir essas operações aos clientes de forma otimizada. É dentro desse contexto que surgiu o desenvolvimento do Mantle. Ao reimaginar a arquitetura desse motor de inferência de próxima geração, a AWS colocou como prioridade máxima elevar os padrões de segurança.
A empresa compreende que os clientes têm foco inegociável em segurança e privacidade de dados. Essa preocupação tem sido central no negócio da AWS desde o início e foi particularmente importante nos primeiros dias do Amazon Bedrock. Desde o começo, ficou claro que as cargas de trabalho de inferência de IA generativa representam uma oportunidade sem precedentes para que os clientes extraiam valor latente de seus dados. Porém, com essa oportunidade vem a necessidade de garantir os mais altos padrões em segurança, privacidade e conformidade, permitindo que os clientes construam sistemas de IA generativa que processem seus dados mais sensíveis e interajam com seus sistemas mais críticos.
Fundamentos de segurança operacional no Bedrock
Como linha de base, o Amazon Bedrock foi projetado seguindo os mesmos padrões de segurança operacional encontrados em toda a AWS. A empresa sempre utilizou um modelo de privilégio mínimo para operações, onde cada operador da AWS tem acesso apenas ao conjunto mínimo de sistemas necessários para sua tarefa atribuída, limitado ao tempo em que esse privilégio é realmente necessário.
Qualquer acesso a sistemas que armazenam ou processam dados de clientes ou metadados é registrado em logs, monitorado para detectar anomalias e auditado regularmente. A AWS se protege contra qualquer ação que pudesse desabilitar ou contornar esses controles. Além disso, no Amazon Bedrock, os dados dos clientes nunca são utilizados para treinar nenhum modelo. Os provedores de modelos não têm nenhum mecanismo para acessar dados de clientes, uma vez que a inferência ocorre apenas dentro da conta de propriedade da AWS que os provedores de modelos não conseguem acessar.
Essa postura forte de segurança tem sido um fator fundamental para que os clientes desbloqueiem o potencial de aplicações de IA generativa com seus dados sensíveis.
O Design de Zero Acesso de Operadores no Mantle
Com o Mantle, a AWS elevou ainda mais esses padrões. Seguindo a abordagem do AWS Nitro System, o Mantle foi projetado desde o início para implementar o conceito de zero acesso de operadores (ZOA), onde a empresa eliminou intencionalmente todos os meios técnicos pelos quais operadores da AWS poderiam acessar dados de clientes. Em vez disso, sistemas e serviços são administrados por meio de automação e APIs seguras que protegem os dados do cliente.
Com o Mantle, não existe nenhum mecanismo que permita a qualquer operador da AWS fazer login em sistemas de computação subjacentes ou acessar dados de clientes, como prompts de inferência ou completudes. Ferramentas de comunicação interativa como Secure Shell (SSH), AWS Systems Manager Session Manager, e consoles seriais não estão instaladas em nenhum lugar no Mantle.
Adicionalmente, todas as atualizações de software de inferência precisam ser assinadas digitalmente e verificadas antes de poderem ser implantadas no serviço, garantindo que apenas código aprovado execute no Mantle.
O Mantle utiliza a capacidade de atestação de instância EC2, lançada recentemente, para configurar um ambiente de computação endurecido, restrito e imutável para processamento de dados de clientes. Os serviços no Mantle responsáveis por manipular pesos de modelos e conduzir operações de inferência em prompts de clientes são ainda mais reforçados pela garantia de medições de atestação criptograficamente assinadas provenientes do Nitro Trusted Platform Module (NitroTPM).
Quando um cliente chama um endpoint Mantle (por exemplo, bedrock-mantle.[regions].api.aws), como aqueles que servem a Responses API no Amazon Bedrock, os dados de clientes (prompts) saem do ambiente do cliente através de TLS e são criptografados até chegarem ao serviço Mantle, que opera com ZOA. Em todo o fluxo e dentro do Mantle, nenhum operador — seja da AWS, do cliente ou de um provedor de modelo — consegue acessar os dados do cliente.
Próximos passos e compromisso contínuo
O design ZOA do Mantle exemplifica o compromisso de longo prazo da AWS com a segurança e privacidade dos dados de seus clientes. É esse foco que tem permitido que equipes em toda a AWS invistam continuamente em elevar os padrões de segurança. Ao mesmo tempo, a empresa disponibilizou para todos os clientes as capacidades fundamentais de computação confidencial que utiliza internamente na Amazon, como o NitroTPM Attestation, para que utilizem em instâncias de Amazon Elastic Compute Cloud (Amazon EC2).
A AWS reafirma seu compromisso em continuar investindo no aprimoramento da segurança dos dados dos clientes e em fornecer mais transparência e segurança sobre como isso é alcançado.
O Amazon RDS for MySQL agora suporta o MySQL Innovation Release 9.5 no Ambiente de Pré-visualização do Amazon RDS Database. Essa disponibilidade permite que desenvolvedores e arquitetos avaliem a versão mais recente da inovação MySQL antes de implementá-la em ambientes de produção. A possibilidade de implantar o MySQL 9.5 nesse ambiente oferece os benefícios de um banco de dados totalmente gerenciado, facilitando a configuração, operação e monitoramento.
O que é Innovation Release 9.5
O MySQL 9.5 representa a versão mais recente de Innovation Release lançada pela comunidade MySQL. Esses lançamentos de inovação incluem correções de bugs, patches de segurança e novas funcionalidades desenvolvidas pela comunidade. É importante entender a diferença entre os tipos de versão: o Innovation Release recebe suporte da comunidade até o próximo Innovation minor, enquanto as versões MySQL Long Term Support (LTS) — como MySQL 8.0 e MySQL 8.4 — contam com até oito anos de suporte comunitário.
Como Usar no Ambiente de Pré-visualização
O Ambiente de Pré-visualização do Amazon RDS Database oferece flexibilidade para testar a nova versão. Ele suporta ambos os modelos de implantação: Single-AZ (zona de disponibilidade única) e Multi-AZ (múltiplas zonas), utilizando a geração mais recente de classes de instância disponíveis na AWS.
Alguns pontos importantes sobre esse ambiente:
Instâncias de banco de dados no Ambiente de Pré-visualização são retidas por no máximo 60 dias e deletadas automaticamente após esse período
Snapshots (cópias) do RDS criados no Ambiente de Pré-visualização funcionam exclusivamente dentro do próprio ambiente de pré-visualização
O custo das instâncias é igual ao de instâncias RDS de produção criadas na região US East (Ohio)
Para começar a usar o Ambiente de Pré-visualização, acesse o console do RDS e navegue até a seção de pré-visualização para iniciar sua primeira instância MySQL 9.5.
Contexto: A Evolução da IA Generativa em Ambientes Corporativos
A adoção de inteligência artificial generativa nas empresas evoluiu significativamente. Passou de simples interações com modelos de fundação para fluxos de trabalho sofisticados envolvendo agentes autônomos. Conforme as organizações transitam de prototipagens para implementações em produção, surge a necessidade crítica de ferramentas robustas que permitam desenvolvimento, avaliação e monitoramento de aplicações de IA em larga escala.
A integração entre Amazon Bedrock, o recém-lançado Amazon Bedrock AgentCore e a plataforma W&B Weave oferece uma solução abrangente para este desafio. Esta combinação permite rastrear chamadas individuais a modelos, monitorar fluxos de agentes complexos em produção e otimizar o ciclo de vida completo de desenvolvimento de soluções de IA empresariais.
O que é W&B Weave: Uma Visão Geral
Weights & Biases (W&B) é um sistema de desenvolvimento para IA que oferece ferramentas abrangentes para treinamento de modelos, ajuste fino e aproveitamento de modelos de fundação em empresas de todos os tamanhos e diversos setores. O W&B Weave funciona como um conjunto unificado de ferramentas para desenvolvedores que suportam cada etapa dos fluxos de trabalho com IA generativa e agentes.
As principais capacidades oferecidas incluem:
Rastreamento e Monitoramento: Acompanhamento de chamadas a modelos de linguagem grande (LLM) e lógica da aplicação para depuração e análise de sistemas em produção
Iteração Sistemática: Refinamento e melhoria contínua de prompts, conjuntos de dados e modelos
Experimentação: Testes com diferentes modelos e prompts através do LLM Playground
Avaliação: Uso de funções de pontuação personalizadas ou pré-construídas com ferramentas de comparação para avaliar e melhorar sistematicamente o desempenho das aplicações
Coleta de Feedback: Integração de feedback de usuários e especialistas para testes e validação em cenários reais
Proteção de Aplicações: Salvaguardas para moderação de conteúdo, segurança de prompts e mais. Inclui suporte a Amazon Bedrock Guardrails personalizadas, de terceiros ou nativas do W&B Weave
O W&B Weave pode ser gerenciado completamente pela Weights & Biases em ambientes multi-tenant ou single-tenant, ou ser implantado diretamente na Amazon Virtual Private Cloud (VPC) do cliente. Além disso, a integração do W&B Weave na Plataforma de Desenvolvimento W&B oferece às organizações uma experiência perfeitamente integrada entre fluxos de trabalho de treinamento/ajuste fino de modelos e fluxos de trabalho com IA e agentes.
Rastreamento de Modelos do Amazon Bedrock com W&B Weave
A integração entre W&B Weave e Amazon Bedrock é feita de forma simplificada através de SDKs em Python e TypeScript. Após instalar a biblioteca e patchar seu cliente Bedrock, o W&B Weave rastreia automaticamente as chamadas aos modelos de linguagem.
O processo é direto. Instale a biblioteca, configure o cliente Bedrock com o patch fornecido, e o rastreamento acontece automaticamente sem modificações no código principal da aplicação:
!pip install weave
import weave
import boto3
import json
from weave.integrations.bedrock.bedrock_sdk import patch_client
weave.init("my_bedrock_app")
# Create and patch the Bedrock client
client = boto3.client("bedrock-runtime")
patch_client(client)
# Use the client as usual
response = client.invoke_model(
modelId="anthropic.claude-3-5-sonnet-20240620-v1:0",
body=json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 100,
"messages": [
{"role": "user", "content": "What is the capital of France?"}
]
}),
contentType='application/json',
accept='application/json'
)
response_dict = json.loads(response.get('body').read())
print(response_dict["content"][0]["text"])
Esta integração versionará automaticamente experimentos e rastreará configurações, proporcionando visibilidade completa das aplicações Amazon Bedrock sem necessidade de alterações na lógica central.
Experimentação com Modelos do Amazon Bedrock no Playground do W&B Weave
O W&B Weave Playground acelera a engenharia de prompts com uma interface intuitiva para testes e comparação de modelos Bedrock. Os recursos principais incluem:
Edição direta de prompts e possibilidade de reexecutar mensagens
Comparação lado a lado de modelos
Acesso direto a partir de visualizações de rastreamento para iteração rápida
Para começar, adicione suas credenciais AWS nas configurações do Playground, selecione seus modelos preferidos do Amazon Bedrock e comece a experimentar. A interface permite iteração rápida em prompts enquanto mantém rastreabilidade completa dos experimentos.
Avaliação de Modelos do Amazon Bedrock com W&B Weave
W&B Weave Evaluations oferece ferramentas dedicadas para avaliar modelos de IA generativa de forma eficaz. Ao aproveitar W&B Weave Evaluations em conjunto com Amazon Bedrock, usuários podem avaliar eficientemente estes modelos, analisar resultados e visualizar desempenho em métricas principais.
É possível usar funções de pontuação integradas do W&B Weave, funções de terceiros ou personalizadas, além de feedback humano e de especialistas. Esta combinação permite compreender mais profundamente as compensações entre modelos, como diferenças em custo, precisão, velocidade e qualidade de saída.
W&B Weave oferece um modo nativo para rastrear avaliações através das classes Model e Evaluation. Para configurar um trabalho de avaliação, os clientes podem:
Definir um dataset ou lista de dicionários com uma coleção de exemplos a serem avaliados
Criar uma lista de funções de pontuação, onde cada função recebe a saída do modelo e opcionalmente outras entradas dos exemplos, retornando um dicionário com os scores
Definir um modelo Amazon Bedrock usando a classe Model
Executar a avaliação chamando Evaluation
Segue um exemplo de configuração de um trabalho de avaliação:
import weave
from weave import Evaluation
import asyncio
# Collect your examples
examples = [
{"question": "What is the capital of France?", "expected": "Paris"},
{"question": "Who wrote 'To Kill a Mockingbird'?", "expected": "Harper Lee"},
{"question": "What is the square root of 64?", "expected": "8"},
]
# Define any custom scoring function
@weave.op()
def match_score1(expected: str, output: dict) -> dict:
# Here is where you'd define the logic to score the model output
return {'match': expected == model_output['generated_text']}
@weave.op()
def function_to_evaluate(question: str):
# here's where you would add your LLM call and return the output
return {'generated_text': 'Paris'}
# Score your examples using scoring functions
evaluation = Evaluation(
dataset=examples,
scorers=[match_score1]
)
# Start tracking the evaluation
weave.init('intro-example')
# Run the evaluation
asyncio.run(evaluation.evaluate(function_to_evaluate))
O dashboard de avaliação visualiza métricas de desempenho, permitindo decisões informadas sobre seleção e configuração de modelos. Para orientações detalhadas, consulte o artigo anterior sobre avaliação de sumarização de LLM com Amazon Bedrock e Weave.
Observabilidade do Amazon Bedrock AgentCore com W&B Weave
Amazon Bedrock AgentCore é um conjunto completo de serviços para implantação e operação de agentes altamente capazes de forma segura em escala empresarial. Oferece ambientes de execução mais seguros, ferramentas de execução de fluxo de trabalho e controles operacionais que funcionam com frameworks populares como Strands Agents, CrewAI, LangGraph e LlamaIndex, além de muitos modelos de LLM — sejam do Amazon Bedrock ou de fontes externas.
AgentCore inclui observabilidade integrada através de dashboards do Amazon CloudWatch que rastreiam métricas principais como uso de tokens, latência, duração da sessão e taxas de erro. Também rastreia etapas de fluxo de trabalho, mostrando quais ferramentas foram invocadas e como o modelo respondeu, oferecendo visibilidade essencial para depuração e garantia de qualidade em produção.
Quando trabalhando com AgentCore e W&B Weave em conjunto, as equipes podem aproveitar o monitoramento operacional integrado e as bases de segurança do AgentCore enquanto também usam W&B Weave se se alinhar com seus fluxos de trabalho de desenvolvimento existentes. Organizações já investidas no ambiente W&B podem optar por incorporar as ferramentas de visualização do W&B Weave ao lado das capacidades nativas do AgentCore. Esta abordagem oferece flexibilidade para usar a solução de observabilidade que melhor se encaixa nos processos estabelecidos e preferências das equipes.
Duas Abordagens Principais para Observabilidade
Existem duas formas principais de adicionar observabilidade W&B Weave a seus agentes AgentCore: usando o SDK nativo W&B Weave ou integrando através de OpenTelemetry.
SDK Nativo W&B Weave
A abordagem mais simples é usar o decorador @weave.op do W&B Weave para rastrear automaticamente chamadas de função. Inicialize W&B Weave com o nome do seu projeto e envolva as funções que deseja monitorar:
Como AgentCore é executado como um container Docker, adicione W&B Weave às suas dependências (por exemplo, uv add weave) para incluí-lo na imagem do seu container.
Integração OpenTelemetry
Para equipes que já usam OpenTelemetry ou desejam instrumentação agnóstica de fornecedor, W&B Weave suporta OTLP (Protocolo OpenTelemetry) diretamente:
from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
auth_b64 = base64.b64encode(f"api:{WANDB_API_KEY}".encode()).decode()
exporter = OTLPSpanExporter(
endpoint="https://trace.wandb.ai/otel/v1/traces",
headers={"Authorization": f"Basic {auth_b64}", "project_id": WEAVE_PROJECT}
)
# Create spans to track execution
with tracer.start_as_current_span("invoke_agent") as span:
span.set_attribute("input.value", json.dumps({"prompt": user_message}))
result = agent(user_message)
span.set_attribute("output.value", json.dumps({"message": result.message}))
Esta abordagem mantém compatibilidade com a infraestrutura OpenTelemetry existente do AgentCore enquanto roteia os rastreamentos para W&B Weave para visualização.
Ao usar AgentCore e W&B Weave em conjunto, as equipes dispõem de múltiplas opções para observabilidade. A integração CloudWatch do AgentCore monitora saúde do sistema, utilização de recursos e taxas de erro, enquanto fornece rastreamento para raciocínio de agente e seleção de ferramentas. W&B Weave oferece capacidades de visualização que apresentam dados de execução em formatos familiares a equipes já usando o ambiente W&B.
Ambas as soluções fornecem visibilidade sobre como agentes processam informações e tomam decisões, permitindo que organizações escolham a abordagem de observabilidade que melhor se alinhe com fluxos de trabalho e preferências existentes.
Esta abordagem de dupla camada significa que os usuários podem:
Monitorar acordos de nível de serviço (SLAs) em produção através de alertas CloudWatch
Depurar comportamentos complexos de agentes no explorador de rastreamento do W&B Weave
Otimizar uso de tokens e latência com buscas detalhadas de execução
Comparar desempenho de agentes entre diferentes prompts e configurações
A integração requer mudanças mínimas de código, preserva sua implantação AgentCore existente e escala com a complexidade do seu agente. Seja construindo agentes simples que chamam ferramentas ou orquestrando fluxos de trabalho multi-etapa, esta pilha de observabilidade fornece os insights necessários para iterar rapidamente e implantar com confiança.
Para detalhes de implementação e exemplos de código completos, consulte o artigo anterior.
Instale o SDK Weave e siga os exemplos de código para começar a rastrear suas chamadas a modelos Bedrock
Experimente com diferentes modelos no W&B Weave Playground adicionando suas credenciais AWS e testando vários modelos do Amazon Bedrock
Configure avaliações usando o framework W&B Weave Evaluation para comparar sistematicamente o desempenho de modelos para seus casos de uso
Melhore seus agentes AgentCore adicionando observabilidade W&B Weave usando o SDK nativo ou integração OpenTelemetry
Comece com uma integração simples para rastrear suas chamadas Amazon Bedrock, depois adote progressivamente recursos mais avançados conforme suas aplicações de IA crescem em complexidade
Conclusão
A combinação de Amazon Bedrock, Amazon Bedrock AgentCore e W&B Weave oferece uma solução robusta para o desenvolvimento, otimização e operação de soluções empresariais de IA com agentes. W&B Weave aprimora cada etapa do ciclo de vida de desenvolvimento de LLM — desde experimentação inicial no Playground até avaliação sistemática de desempenho de modelos, e finalmente monitoramento em produção de fluxos de trabalho complexos de agentes.
A integração entre Amazon Bedrock e W&B Weave fornece várias capacidades-chave: rastreamento automático de chamadas a modelos de fundação do Amazon Bedrock com mudanças mínimas de código usando o SDK W&B Weave; experimentação rápida através da interface intuitiva do W&B Weave Playground para testes de prompts e comparação de modelos; avaliação sistemática com funções de pontuação personalizadas para comparar diferentes modelos do Amazon Bedrock; e observabilidade abrangente para implantações AgentCore, com métricas CloudWatch fornecendo monitoramento operacional robusto suplementado por rastreamentos de execução detalhados.
Esta combinação de Amazon Bedrock e ferramentas de desenvolvimento abrangentes do W&B Weave fornece a fundação necessária para construir, avaliar e manter soluções de IA prontas para produção em escala.
Autenticação Segura em Ambientes de Desktop Remoto
A AWS anunciou uma atualização importante no Amazon WorkSpaces Secure Browser: o suporte ao redirecionamento de autenticação web (WebAuthn). Essa nova capacidade permite que usuários autentiquem-se em websites dentro de suas sessões do WorkSpaces Secure Browser utilizando chaves de segurança e autenticadores biométricos locais, sem comprometer a segurança do ambiente remoto.
O redirecionamento WebAuthn funciona como um intermediário seguro: ao invés de manter credenciais dentro da sessão remota, o sistema permite que os tokens de autenticação sejam transmitidos de forma segura do dispositivo local do usuário para os websites acessados através do navegador seguro.
Compatibilidade e Dispositivos Suportados
Navegadores e Requisitos de Sistema
O recurso está disponível exclusivamente para navegadores baseados em Chromium no dispositivo local do usuário. As versões mínimas necessárias são Google Chrome 136 ou posterior, e Microsoft Edge 137 ou posterior. Navegadores não-Chromium, como Safari e Firefox, não são compatíveis com essa funcionalidade.
Métodos de Autenticação
A solução suporta múltiplas formas de autenticação segura:
Chaves de segurança FIDO2 (dispositivos físicos)
Senhas sem senha (passkeys)
Autenticadores de plataforma, como Windows Hello e Touch ID
Implementação e Configuração
Passos para Ativação
Os administradores precisam executar duas etapas para habilitar o redirecionamento WebAuthn. Primeiro, é necessário ativar o recurso nas configurações de portal do Secure Browser. Em segundo lugar, os navegadores locais devem ser configurados através da política WebAuthenticationRemoteDesktopAllowedOrigins.
Essa configuração garante que os tokens de autenticação sejam transmitidos com segurança do dispositivo local para os websites acessados na sessão do navegador seguro, mantendo a integridade e os benefícios de segurança do ambiente de navegação remoto.
Disponibilidade Global
O recurso está disponível sem custos adicionais em todas as regiões onde o Amazon WorkSpaces Secure Browser opera:
América do Norte: US East (N. Virginia), US West (Oregon), Canada (Central)
Europa: Frankfurt, London, Ireland
Ásia-Pacífico: Tokyo, Mumbai, Sydney, Singapore
Próximos Passos
Para começar a utilizar o redirecionamento WebAuthn, os administradores devem acessar o console do Amazon WorkSpaces Secure Browser e ativar a funcionalidade nas configurações disponíveis. Para instruções detalhadas de implementação e melhores práticas, a documentação oficial do WebAuthn redirection do Amazon WorkSpaces Secure Browser fornece todas as informações necessárias.
A AWS expandiu as capacidades do Amazon Elastic Container Service (ECS) Service Connect com suporte a Envoy Access Logs, um recurso que oferece visibilidade mais granular sobre os padrões de tráfego em nível de requisição e as interações entre serviços. Esta nova funcionalidade captura telemetria detalhada para cada requisição, habilitando rastreamento ponta a ponta, depuração eficiente e conformidade com requisitos regulatórios.
Como funciona o ECS Service Connect
O ECS Service Connect simplifica a construção de comunicação segura e resiliente entre serviços, abrangendo clusters, VPCs e contas AWS. O serviço integra funcionalidades de descoberta de serviços e malha de serviços ao injetar automaticamente proxies Envoy gerenciados pela AWS como sidecars, que tratam roteamento de tráfego, balanceamento de carga e conectividade entre serviços.
Recursos dos Envoy Access Logs
Os Envoy Access Logs capturam metadados detalhados de tráfego, proporcionando visibilidade em nível de requisição sobre os padrões de comunicação entre serviços. Isso permite que equipes realizem diagnósticos de rede, solucionem problemas com eficiência e mantenham trilhas de auditoria para conformidade regulatória.
Segurança e proteção de dados
Por padrão, as strings de consulta são ocultadas para proteger dados sensíveis durante o registro de acesso. Os logs de acesso do Envoy são direcionados para o fluxo de saída padrão (STDOUT), fluindo através do pipeline ECS de logs existente sem necessidade de infraestrutura adicional.
Compatibilidade de protocolos
Esta nova funcionalidade oferece suporte a todos os protocolos de aplicação existentes: HTTP, HTTP2, GRPC e TCP, garantindo compatibilidade ampla com diferentes arquiteturas de serviços.
Configuração e disponibilidade
A configuração dos access logs dentro do ECS Service Connect é realizada atualizando a ServiceConnectConfiguration para ativar o registro de acesso. O recurso está disponível nas regiões AWS GovCloud (US-West) e AWS GovCloud (US-East), onde o Amazon ECS Service Connect é suportado.
Do Processamento à Inteligência: O Próximo Passo na Análise de Documentos
Extrair informações estruturadas de dados não-estruturados é um passo fundamental para desbloquear valor empresarial. O Acelerador GenAI IDP (Processamento Inteligente de Documentos com IA Generativa) tem se posicionado na vanguarda dessa transformação, tendo já processado dezenas de milhões de documentos para centenas de clientes.
Porém, existe um desafio que muitas organizações enfrentam: após digitizar e estruturar seus documentos, como analisar esse volume de informações de forma eficiente e extrair insights acionáveis rapidamente? A AWS identificou essa lacuna e apresentou uma solução: o Analytics Agent, uma nova funcionalidade integrada nativamente ao Acelerador GenAI IDP.
Com esse recurso, usuários podem realizar buscas avançadas e análises complexas usando consultas em linguagem natural, sem necessidade de dominar SQL ou técnicas de análise de dados. O objetivo é democratizar o acesso a insights, permitindo que qualquer usuário de negócio possa explorar seus documentos processados em escala.
O Acelerador GenAI IDP: Fundação para a Análise Inteligente
O acelerador foi projetado para operar em larga escala, conseguindo processar milhares de documentos diariamente. Ele oferece três padrões de processamento que permitem aos usuários construir soluções customizadas para fluxos complexos de tratamento de documentos.
A implantação é simplificada através de templates do AWS CloudFormation, e usuários podem começar a processar documentos imediatamente via interface web ou carregando arquivos direto no Amazon S3 (Simple Storage Service). O acelerador inclui múltiplos módulos como classificação de documentos, extração de dados, avaliação, sumarização e análise de qualidade.
O Analytics Agent: Tornando Dados Acessíveis através de Linguagem Natural
Com a nova funcionalidade Analytics Agent, usuários podem realizar consultas através de linguagem natural na interface Agent Companion Chat, acessível na seção de navegação do acelerador (a partir da versão 0.4.7). Consultas relacionadas a análises são automaticamente roteadas para o Analytics Agent.
O agente funciona como uma interface inteligente entre usuários de negócio e seus dados de documentos processados. Ele consegue lidar com consultas complexas que normalmente exigiriam um cientista de dados experiente, tornando análises avançadas acessíveis ao usuário médio.
Alguns exemplos práticos:
Um provedor de saúde poderia perguntar: “Qual percentual de reclamações de seguro foi negado no mês passado? Daquelas, quantas foram devido a documentação incompleta? Mostre-me uma tendência de motivos de negação nos últimos seis meses.”
Um escritório de contabilidade fiscal poderia questionar: “Quais dos meus clientes estão pagando imposto estadual em mais de um estado nos formulários W2?”
Como o Analytics Agent Funciona: Arquitetura e Fluxo
O Analytics Agent é construído sobre Strands Agents, um SDK de código aberto que utiliza uma abordagem orientada por modelos para construir agentes de IA. O agente é projetado para tornar o trabalho com dados empresariais mais intuitivo, oferecendo conversão automática de linguagem natural para dados e visualizações.
O fluxo de trabalho do Analytics Agent segue estes passos:
Exploração do banco de dados: O agente usa uma ferramenta de exploração para entender as estruturas de dados armazenadas nas tabelas do Amazon Athena dentro da solução IDP. Isso é necessário porque as tabelas podem ter esquemas diferentes dependendo de como os usuários configuraram o pipeline de processamento.
Conversão para SQL: O agente converte consultas em linguagem natural em queries SQL otimizadas e compatíveis com os bancos e tabelas disponíveis, capazes de escalar para tabelas de tamanho arbitrário.
Execução de queries: O agente executa SQL contra o Athena e armazena os resultados no Amazon S3. Ele corrige e re-executa queries que falharam com base na mensagem de erro.
Transferência segura: Os resultados são transferidos com segurança do Amazon S3 para o sandbox do AWS Bedrock AgentCore Code Interpreter.
Geração de visualizações: O agente escreve código Python para analisar os resultados e gerar gráficos ou tabelas em formato estruturado compatível com a interface web.
Apresentação final: As visualizações finais são exibidas na interface web para interpretação direta pelo usuário.
Arquitetura da Solução: Design Orientado pela Segurança
O Analytics Agent é implantado principalmente dentro de funções Lambda. Quando uma consulta do usuário chega através da API AWS AppSync, uma função Lambda efêmera cria e armazena um ID único de trabalho no DynamoDB para rastrear o fluxo de processamento assíncrono, e inicializa uma função Lambda de longa duração que instancia um agente Strands.
A interface frontend consulta o status do trabalho e recupera os resultados finais (incluindo de trabalhos anteriores) do DynamoDB. A função processadora tem permissões do AWS IAM (Gerenciamento de Identidade e Acesso) para acessar as tabelas IDP no Athena e para executar um sandbox Code Interpreter com execução mais segura de código Python.
A arquitetura segue um design orientado pela segurança:
Execução em sandbox: O código Python executa no AgentCore Code Interpreter, completamente isolado do resto do ambiente AWS e da internet.
Transferência segura de dados: Os resultados são transferidos através do Amazon S3 e APIs do AgentCore, não através do contexto da janela de um modelo de linguagem.
Gerenciamento de sessões: As sessões do AgentCore Code Interpreter são gerenciadas adequadamente e limpas após o uso.
Permissões mínimas: Cada componente solicita apenas as permissões AWS necessárias.
Auditoria: A solução oferece logging e monitoramento abrangentes para revisões de segurança.
Demonstração Prática: Análise de Memorandos Departamentais
Para demonstrar as capacidades do Analytics Agent, a AWS processou 10.000 documentos do conjunto de dados RVL-CDIP usando o Acelerador GenAI IDP. O conjunto contém diversos tipos de documentos como memorandos, cartas, formulários e relatórios, processados usando a configuração de Padrão 2 para extrair informações estruturadas como tipo de documento, remetente, destinatário e detalhes de departamento.
Um usuário fez uma pergunta simples em linguagem natural: “Quais departamentos geram o maior volume de memorandos?”
Traditicionalmente, essa consulta exigiria que um analista de dados completasse várias etapas: obter credenciais, conectar ao banco de dados interno, entender o esquema através de queries exploratórias ou documentação, escrever SQL complexo com sintaxe Athena correta, executar e validar a query, processar resultados e criar visualizações, e formatar os achados para apresentação.
O Analytics Agent completou todo esse fluxo de forma autônoma em menos de 60 segundos.
A análise revelou que Lorillard gerou o maior número de memorandos (11 documentos), seguido pelos departamentos INBIFO, Assuntos Corporativos e Philip Morris (10 documentos cada). A visualização mostrou a distribuição entre as unidades organizacionais principais, com departamentos de pesquisa de tabaco e corporativos dominando a geração de memorandos.
Usuários podem rapidamente alternar entre diferentes estilos de visualização como gráficos de pizza, linhas e barras, ou exibir os resultados como tabelas.
Capacidades Transformadoras do Agente
O exemplo acima ilustra três capacidades principais:
Resolução autônoma de problemas: O agente descobriu independentemente o esquema do banco de dados, identificou as tabelas e colunas corretas, e tratou problemas de qualidade de dados (valores nulos) sem intervenção humana. Isso significa que o agente pode trabalhar com diferentes documentos analisados pela solução IDP, independentemente do tipo de documento ou configurações de processamento.
Raciocínio adaptativo: Quando o agente detectou valores nulos na visualização inicial, corrigiu automaticamente o problema filtrando os dados e regenerando o gráfico, demonstrando capacidades de auto-correção.
Interpretabilidade fim-a-fim: Todo o fluxo de trabalho, da consulta em linguagem natural até a visualização polida, executou em 90 segundos com transparência completa. Usuários podem revisar cada decisão que o agente tomou através do registro detalhado de raciocínio.
Casos de Uso Práticos para o Analytics Agent
O poder dessa funcionalidade reside em sua capacidade de democratizar análise de dados, transformando usuários de negócio em analistas através da conversa simples. Alguns casos de uso incluem:
Insights Empresariais Instantâneos
Fazer perguntas complexas em linguagem natural como “Qual percentual de faturas excedeu $50.000 no último trimestre?” ou “Como o valor médio de faturas tendenciou ao longo dos últimos 12 meses?” Tomar decisões orientadas por dados sem aguardar equipes de TI ou ciência de dados.
Monitoramento de Risco e Conformidade
Detectar anomalias em tempo real com queries como “Mostre-me todos os contratos com cláusulas obrigatórias ausentes”, rastrear taxas de conformidade entre tipos de documento e identificar documentos de alto risco que requerem atenção imediata.
Excelência Operacional
Monitorar gargalos de processamento com “Quais tipos de documento têm os tempos de processamento mais longos?”, rastrear taxas de precisão entre categorias de documento e otimizar alocação de recursos baseado em padrões de volume.
Aprimoramento da Experiência do Cliente
Analisar métricas de processamento específicas do cliente, identificar oportunidades para automação de processos e rastrear conformidade com SLA em tempo real.
Planejamento Estratégico
Prever volumes de processamento baseado em padrões históricos, identificar tendências sazonais e planejar de acordo, rastrear métricas de ROI para investimentos em processamento de documentos e tomar decisões informadas sobre escalabilidade do sistema.
Melhores Práticas para Usar o Analytics Agent
Comece abrangente: Inicie com perguntas gerais antes de mergulhar em especificidades.
Seja específico: Declare claramente que informação você está procurando. Não tenha medo de fornecer um parágrafo inteiro descrevendo suas necessidades se necessário.
Use consultas de acompanhamento: Desenvolva o que aprendeu em perguntas anteriores para explorar tópicos em profundidade. As mensagens enviadas no Agent Companion Chat possuem estado, permitindo fazer perguntas de acompanhamento.
Verifique os resultados: Valide se as visualizações fazem sentido para seus dados e leia através do processo de raciocínio do agente exibido para validar as decisões que ele tomou.
Integração com Sistemas Agênticos Externos
O Analytics Agent pode ser facilmente integrado em outros sistemas agênticos de IA, como o Amazon Quick Suite, através do novo Servidor MCP (Model Context Protocol) do Acelerador IDP. Organizações podem incorporar capacidades de análise de documentos em seus fluxos de trabalho de IA mais amplos e plataformas de automação usando essa integração. Para orientação de implementação e detalhes técnicos, consulte a documentação de integração MCP.
Limpeza e Manutenção
Após experimentar o Analytics Agent, existem duas opções de limpeza dependendo das suas necessidades:
Remover queries individuais: Navegue para a seção de Análise do Agente na interface web e use o painel “carregar chat anterior” para deletar queries específicas.
Deletar toda a implantação IDP: Use o console CloudFormation para deletar a pilha IDP. Para limpeza automatizada incluindo esvaziamento de buckets S3, use o CLI do IDP conforme documentado na documentação do IDP CLI.
O time de AWS Professional Services e AWS Partners está disponível para auxiliar com implementação. Você também pode se juntar à comunidade GitHub para contribuir com melhorias e compartilhar suas experiências.
Conclusão
O Analytics Agent representa um passo significativo na democratização da análise de dados empresariais. Ao eliminar barreiras técnicas tradicionais—conhecimento de SQL, compreensão de estruturas de banco de dados, familiaridade com ferramentas de análise—a AWS coloca o poder da exploração de dados nas mãos de qualquer usuário de negócio.
Com a integração nativa no Acelerador GenAI IDP, organizações que já investiram no processamento inteligente de documentos agora ganham uma ferramenta poderosa para extrair valor máximo de seus dados. Essa combinação de processamento de documentos automatizado e análise conversacional abre novas possibilidades para casos de uso em saúde, contabilidade, conformidade, operações e muito além.
O Que É Voxtral: Capacidades Multimodais Integradas
Os modelos Voxtral da Mistral AI marcam um avanço significativo no processamento simultâneo de texto e áudio. Ao contrário de soluções convencionais que exigem etapas separadas para transcrever e processar dados, o Voxtral integra essas funcionalidades em um único framework coeso.
A família Voxtral apresenta dois modelos específicos, cada um otimizado para cenários distintos. O Voxtral-Mini-3B-2507 é uma versão compacta com 3 bilhões de parâmetros, direcionado a aplicações onde velocidade e economia de recursos computacionais são prioridades. O Voxtral-Small-24B-2507, com 24 bilhões de parâmetros baseados no Mistral Small 3, atende casos corporativos mais complexos, proporcionando recursos avançados de conversação, execução de funções diretamente por comando de voz e processamento sofisticado em múltiplos idiomas.
Ambos suportam contexto de áudio estendido (entre 30 e 40 minutos), identificação automática de idioma e mantêm uma janela de contexto de 32 mil tokens. Disponibilizados sob licença Apache 2.0, permitem tanto uso comercial quanto em pesquisa.
Processamento Multimodal Unificado
Um dos diferenciais do Voxtral é processar fala e texto em um único fluxo de trabalho. Isso elimina a necessidade de etapas separadas de transcrição, reduzindo latência e complexidade da arquitetura. O modelo extrai contexto e sentimento diretamente do áudio, e gerencia vários arquivos de áudio dentro da mesma conversa.
O Voxtral Small acrescenta capacidade de chamada de funções, permitindo que comandos falados se convertam em ações executáveis. Isso viabiliza assistentes de voz contextualizados, transcrição automática e extração de insights em reuniões, processamento inteligente de chamadas para suporte ao cliente, ferramentas acessíveis e sistemas de comunicação multilíngue para empresas globais.
Hospedagem no Amazon SageMaker Com Contêiner Personalizado
A solução combina Amazon SageMaker AI com vLLM usando a abordagem Bring Your Own Container (BYOC). O vLLM é uma biblioteca otimizada para servir grandes modelos de linguagem, oferecendo atenção paginada para melhor gestão de memória e paralelismo tensorial para distribuir modelos entre várias GPUs.
A capacidade BYOC do SageMaker permite implantação com imagens Docker personalizadas. Isso oferece controle de versão compatível com vLLM 0.10.0+, flexibilidade para otimizar requisitos específicos do Voxtral (incluindo bibliotecas de áudio e gerenciamento customizado de memória), além de suportar ambas as variantes através de ajustes simples de configuração.
Arquitetura da Solução
O notebook do SageMaker atua como ponto central de orquestração. Gerencia a construção e envio de imagens Docker personalizadas para o Registro de Contêineres (Amazon ECR), coordena fluxos de configuração e implementação, e oferece capacidades de teste e validação.
Um componente essencial é o contêiner Docker personalizado que estende o servidor vLLM oficial com bibliotecas especializadas para processar áudio (librosa, soundfile, pydub) e mistral_common para tokenização do Voxtral. O Amazon Elastic Container Registry (ECR) fornece armazenamento seguro e distribuição escalável dessa imagem, integrando-se aos mecanismos de implantação do SageMaker.
O endpoint de inferência do SageMaker funciona como ambiente de produção, oferecendo escalonamento automático e distribuição de carga. Para Voxtral-Mini, a recomendação é ml.g6.4xlarge; para Voxtral-Small, ml.g6.12xlarge. O Amazon Simple Storage Service (S3) armazena três arquivos críticos: o manipulador de inferência personalizado (model.py), configuração do modelo (serving.properties) e dependências (requirements.txt). Essa abordagem modular permite separar configuração de imagens de contêiner e facilita mudanças sem reconstrução completa.
A solução atende múltiplos padrões de uso alinhados a necessidades organizacionais variadas. O processamento apenas de texto utiliza a API padrão de conclusão de chat para IA conversacional. O modo transcription-only oferece transcrição precisa de arquivos de áudio, ideal para anotações de reuniões. Aplicações sofisticadas combinam inteligência de áudio e texto, onde o áudio fornece contexto e texto entrega instruções específicas. O padrão avançado envolve chamada de funções a partir de áudio, onde comandos falados disparam ações automatizadas—por exemplo, “Calcule a raiz quadrada de 144” executa automaticamente a ferramenta de calculadora.
Este guia também demonstra integração do Voxtral implantado no SageMaker com Strands Agents para construir aplicações agentic com código mínimo.
Preparação Técnica Para Implantação
Antes de iniciar, certifique-se de possuir os seguintes pré-requisitos:
Requisitos de software:
vLLM >= 0.10.0
mistral_common >= 1.8.1
Configuração da AWS:
Uma conta AWS ativa
Notebook SageMaker com ml.m5.4xlarge e 100 GB de armazenamento
Quotas de serviço: instâncias ml.g6.4xlarge (Voxtral-Mini) e ml.g6.12xlarge (Voxtral-Small) disponíveis em sua região. Se necessário, solicite um aumento de cota
Processo de Implantação
Para implantar os modelos Voxtral, siga estas etapas:
1. Baixe o código do repositório
git clone https://github.com/aws-samples/mistral-on-aws.git
cd mistral-on-aws/Mistral\ Voxtral/Voxtral-vllm-byoc
Abra e execute Voxtral-vLLM-BYOC-SageMaker.ipynb para implantar seu endpoint e testar com recursos de texto, áudio e chamada de funções.
Configuração do Contêiner Docker
O repositório GitHub contém o Dockerfile completo. Os componentes principais são:
# Custom vLLM Container for Voxtral Model Deployment on SageMaker
FROM --platform=linux/amd64 vllm/vllm-openai:latest
# Set environment variables for SageMaker
ENV MODEL_CACHE_DIR=/opt/ml/model
ENV TRANSFORMERS_CACHE=/tmp/transformers_cache
ENV HF_HOME=/tmp/hf_home
ENV VLLM_WORKER_MULTIPROC_METHOD=spawn
# Install audio processing dependencies
RUN pip install --no-cache-dir \
"mistral_common>=1.8.1" \
librosa>=0.10.2 \
soundfile>=0.12.1 \
pydub>=0.25.1
Este Dockerfile estende o servidor vLLM oficial com capacidades específicas do Voxtral. A abordagem separa infraestrutura de lógica de negócio: o contêiner permanece genérico enquanto o SageMaker injeta dinamicamente código específico do modelo a partir do S3 em tempo de execução.
Configurações do Modelo
As configurações estão no arquivo serving.properties. Os parâmetros principais incluem:
Esta configuração implementa otimizações específicas do Voxtral, permitindo processamento de até oito arquivos de áudio por prompt com suporte a transcrição de 30 minutos, além de utilizar mecanismos avançados de cache para melhorar desempenho de inferência.
Manipulador de Inferência Personalizado
O arquivo model.py implementa um servidor compatível com SageMaker. Os componentes-chave são:
# FastAPI app for SageMaker compatibility
app = FastAPI(title="Voxtral vLLM Inference Server", version="1.1.0")
model_engine = None
# vLLM Server Initialization for Voxtral
def start_vllm_server():
"""Start vLLM server with Voxtral-specific configuration"""
config = load_serving_properties()
cmd = [
"vllm",
"serve",
config.get("option.model_id"),
"--tokenizer-mode", "mistral",
"--config-format", "mistral",
"--tensor-parallel-size", config.get("option.tensor_parallel_degree"),
"--host", "127.0.0.1",
"--port", "8000"
]
vllm_server_process = subprocess.Popen(cmd, env=vllm_env)
server_ready = wait_for_server()
return server_ready
@app.post("/invocations")
async def invoke_model(request: Request):
"""Handle chat, transcription, and function calling"""
# Transcription requests
if "transcription" in request_data:
audio_source = request_data["transcription"]["audio"]
return transcribe_audio(audio_source)
# Chat requests with multimodal support
messages = format_messages_for_openai(request_data["messages"])
tools = request_data.get("tools")
# Generate via vLLM OpenAI client
response = openai_client.chat.completions.create(
model=model_config["model_id"],
messages=messages,
tools=tools if supports_function_calling() else None
)
return response
Este manipulador cria um servidor baseado em FastAPI que se integra ao servidor vLLM, processando conteúdo multimodal incluindo áudio codificado em base64 e URLs de áudio, além de suportar chamadas de funções.
Código de Implantação no SageMaker
O notebook Voxtral-vLLM-BYOC-SageMaker.ipynb orquestra todo o processo de implantação:
O repositório GitHub contém o código completo. Aqui apresentamos exemplos para diferentes cenários.
Apenas texto
Uma conversa básica onde o usuário envia uma consulta e recebe resposta estruturada:
payload = {
"messages": [
{
"role": "user",
"content": "Hello! Can you tell me about the advantages of using vLLM for model inference?"
}
],
"max_tokens": 200,
"temperature": 0.2,
"top_p": 0.95
}
response = predictor.predict(payload)
Apenas transcrição
Este exemplo foca em transcrição de fala em texto. O modelo processa URL de arquivo de áudio ou arquivo em base64, retornando apenas o texto transcrito:
Combinação de instruções em texto e entrada de áudio para processamento multimodal. O modelo segue comandos escritos enquanto analisa o arquivo de áudio em uma única passada de inferência:
Este exemplo demonstra chamada de funções, permitindo que o modelo interprete comandos de voz e execute ferramentas predefinidas:
WEATHER_TOOL = {
"type": "function",
"function": {
"name": "get_current_weather",
"description": "Get the current weather for a specific location",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "The city and state, e.g. San Francisco, CA"
},
"format": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "The temperature unit to use."
}
},
"required": ["location", "format"]
}
}
}
def mock_weather(location, format="celsius"):
"""Always returns sunny weather at 25°C/77°F"""
temp = 77 if format.lower() == "fahrenheit" else 25
unit = "°F" if format.lower() == "fahrenheit" else "°C"
return f"It's sunny in {location} with {temp}{unit}"
payload = {
"messages": [
{
"role": "user",
"content": [
{
"type": "audio",
"path": "https://huggingface.co/datasets/patrickvonplaten/audio_samples/resolve/main/fn_calling.wav"
}
]
}
],
"temperature": 0.2,
"top_p": 0.95,
"tools": [WEATHER_TOOL]
}
response = predictor.predict(payload)
Integrando Com Strands Agents
O exemplo a seguir mostra como integrar Voxtral com o framework Strands para criar agentes inteligentes capazes de utilizar múltiplas ferramentas. O agente seleciona e executa ferramentas apropriadas (calculadora, operações com arquivos ou comandos shell) com base em consultas de usuário:
# SageMaker integration with Strands agents
from strands import Agent
from strands.models.sagemaker import SageMakerAIModel
from strands_tools import calculator, current_time, file_read, shell
model = SageMakerAIModel(
endpoint_config={
"endpoint_name": endpoint_name,
"region_name": "us-west-2",
},
payload_config={
"max_tokens": 1000,
"temperature": 0.7,
"stream": False,
}
)
agent = Agent(model=model, tools=[calculator, current_time, file_read, shell])
response = agent("What is the square root of 12?")
Limpeza de Recursos
Após concluir os experimentos, delete os endpoints do SageMaker criados para evitar custos desnecessários:
A abordagem apresentada demonstra como hospedar os modelos Voxtral da Mistral AI no SageMaker utilizando a estratégia BYOC. A solução é pronta para produção, aproveitando o framework vLLM mais recente e as otimizações do Voxtral para ambas as variantes Mini e Small.
A arquitetura suporta todo o espectro de capacidades do Voxtral: conversas apenas com texto, transcrição de áudio, entendimento multimodal sofisticado e chamada de funções a partir de entrada de voz. Por seu design flexível, é possível alternar entre Voxtral-Mini e Voxtral-Small através de simples atualizações de configuração, sem reconstruir contêineres.
Para aprofundar sua experiência, experimente o código completo disponível no repositório GitHub para hospedar o Voxtral no SageMaker e comece a construir suas próprias aplicações habilitadas para voz. Explore todo o potencial do Voxtral visitando o site oficial da Mistral para conhecer capacidades detalhadas, benchmarks de desempenho e especificações técnicas. Por fim, explore o framework Strands Agents para criar aplicações agentic que executem fluxos de trabalho complexos de forma integrada.
A manutenção preditiva representa uma mudança estratégica significativa na forma como as indústrias gerenciam seus ativos. Em vez de esperar que equipamentos falhem ou realizar manutenção em intervalos fixos, essa abordagem utiliza dados contínuos de sensores e análise avançada para prever quando uma máquina provavelmente enfrentará problemas. Isso permite que as equipes intervenham proativamente, evitando paradas não planejadas, melhorando a eficiência operacional e prolongando a vida útil de equipamentos críticos como motores, ventiladores, caixas de engrenagens, rolamentos e transportadores.
A AWS apresentou uma solução prática que combina modelos de fundação com IA generativa para aprimorar significativamente o processo de diagnóstico. Usando Amazon Bedrock como base tecnológica, a empresa demonstrou como um assistente inteligente pode ajudar equipes de manutenção a identificar com precisão a causa raiz de problemas nos equipamentos.
Os Dois Pilares da Manutenção Preditiva
O processo de manutenção preditiva funciona em duas fases complementares que, juntas, criam uma abordagem completa para evitar falhas.
Fase 1: Geração de Alarmes a Partir de Sensores
Nesta primeira etapa, sensores monitoram continuamente parâmetros críticos do equipamento, como temperatura e vibração. A Amazon Monitron oferece uma solução integrada de monitoramento de equipamentos com capacidades de aprendizado de máquina. O processo segue uma sequência clara: os sensores capturam dados de vibração e temperatura, que são automaticamente transferidos para a nuvem AWS, onde algoritmos de aprendizado de máquina analisam esses dados em comparação com padrões ISO de vibração, disparando notificações quando condições anormais são detectadas.
Fase 2: Diagnóstico da Causa Raiz
A segunda fase enfrenta desafios significativos que o setor há muito tempo procura resolver. Após o disparo de um alarme, os técnicos recebem ordens de trabalho genéricas com pouca orientação específica e precisam consultar entre 40 ou mais manuais de reparo, cada um contendo centenas de páginas. Quando problemas surgem em estágios iniciais e não exibem sinais claros de mau funcionamento, torna-se extremamente difícil para os técnicos identificar a causa raiz, resultando em longos períodos de inatividade, redução de eficiência e custos elevados de manutenção.
Dados mostram que mais de 50% das ordens de trabalho geradas após um alarme permanecem classificadas como “Indeterminadas” quanto à causa raiz—um problema operacional substancial que impacta diretamente a produtividade.
A Solução: Um Assistente Inteligente Multimodal
Para resolver esse desafio, a AWS desenvolveu um assistente baseado em IA generativa que transforma o processo de diagnóstico. A solução oferece várias capacidades integradas que trabalham em conjunto para fornecer orientação precisa e contextualizada aos técnicos.
Análise de Séries Temporais e Diagnóstico Orientado
O assistente processa dados de sensores e identifica padrões anômalos em relação aos padrões normais de operação. Quando anormalidades são detectadas, o sistema inicia uma conversa orientada que retém o histórico de interações, permitindo diálogos multiturno e contextualmente conscientes. O sistema faz perguntas direcionadas para reunir informações essenciais, funcionando como um técnico virtual consultivo.
Capacidades Multimodais
Uma das características mais poderosas da solução é seu suporte a múltiplos tipos de entrada. Os técnicos podem enviar imagens de componentes desgastados, descrever problemas por áudio, ou até mesmo fazer upload de vídeos mostrando o funcionamento anormal do equipamento. Usando modelos multimodais como Claude 3 Haiku e Claude 3 Sonnet disponíveis através do Amazon Bedrock, o sistema analisa todos esses formatos e fornece interpretações precisas e recomendações contextualizadas.
Recuperação Aumentada Multimodal com Fusão de Ranking
O sistema integra informações tanto de manuais de reparo em texto quanto de diagrama visuais. Quando um técnico faz uma pergunta, o assistente utiliza técnicas avançadas de busca semântica para recuperar informações relevantes. A fusão de ranking recíproco garante que os resultados retornados sejam semanticamente alinhados com a consulta do usuário, combinando insights textuais com guias visuais para diagnóstico mais efetivo.
Guardrails para Segurança e Conformidade
O assistente emprega Amazon Bedrock Guardrails para manter segurança, precisão e conformidade durante todo o processo diagnóstico. Esses guardrails incluem filtros para informações sensíveis, bloqueio de conteúdo prejudicial e passos de validação para evitar recomendações errôneas.
Implementação Técnica: Como Funciona
Processamento de Dados de Sensores
O processo começa quando um técnico carrega um arquivo Excel contendo dados de vibração e temperatura em uma aplicação Streamlit. O sistema extrai esses dados, cria visualizações que destacam desvios de padrões normais com linhas verticais em vermelho, e classifica os níveis de vibração em comparação com padrões internacionais ISO 20816-1. As classificações resultam em zonas de avaliação: Muito Bom, Satisfatório, Alerta ou Crítico, dependendo da classe de máquina e dos valores medidos em VRMS (Velocidade Raiz Quadrática Média).
Entrada por Áudio
Os técnicos podem registrar notas de áudio descrevendo as condições do equipamento. O áudio é enviado para Amazon Transcribe para transcrição automática. Após revisão da transcrição, o texto é processado pelo assistente de IA, que integra essas observações verbais no fluxo diagnóstico, mantendo contexto através de múltiplas trocas.
O seguinte exemplo mostra como isso é implementado. Um arquivo de áudio é enviado para um bucket de Amazon Simple Storage Service (Amazon S3), uma transcrição é acionada através de um endpoint customizado do Amazon API Gateway, e o resultado é recuperado:
Uma função AWS Lambda processa o trabalho de transcrição de forma assíncrona:
import boto3
import json
import time
transcribe = boto3.client('transcribe')
def lambda_handler(event, context):
print("Received event: " + json.dumps(event, indent=2))
try:
body = json.loads(event.get('body', '{}'))
audio_file_uri = body.get('audio_file_uri')
if not audio_file_uri:
return {
'statusCode': 400,
'body': json.dumps({'error': 'audio_file_uri is missing'})
}
s3_bucket = audio_file_uri.split('/')[2]
s3_key = '/'.join(audio_file_uri.split('/')[3:])
job_name = f"transcription-job-{int(time.time())}"
response = transcribe.start_transcription_job(
TranscriptionJobName=job_name,
Media={'MediaFileUri': audio_file_uri},
MediaFormat=s3_key.split('.')[-1],
LanguageCode='en-US'
)
while True:
status = transcribe.get_transcription_job(TranscriptionJobName=job_name)
if status['TranscriptionJob']['TranscriptionJobStatus'] in ['COMPLETED', 'FAILED']:
break
time.sleep(5)
if status['TranscriptionJob']['TranscriptionJobStatus'] == 'COMPLETED':
transcript_uri = status['TranscriptionJob']['Transcript']['TranscriptFileUri']
return {
'statusCode': 200,
'body': json.dumps({'transcript_uri': transcript_uri})
}
else:
return {
'statusCode': 500,
'body': json.dumps({'error': 'Transcription job failed.'})
}
except Exception as e:
return {
'statusCode': 500,
'body': json.dumps({'error': str(e)})
}
Processamento de Vídeo
Para vídeos, a solução extrai componentes de áudio e visual de forma separada. O áudio é transcrito usando o mesmo processo mencionado anteriormente. Frames individuais são extraídos em intervalos regulares, convertidos em formato base64, e processados por modelos multimodais para gerar descrições. Os timestamps dos frames são sincronizados com as transcrições de áudio para manter coerência entre informações visuais e auditivas.
A AWS nota que abordagens mais recentes, como as capacidades nativas de compreensão de vídeo do Amazon Nova, agora oferecem alternativas simplificadas e escaláveis para essa funcionalidade.
Recuperação de Informação de Manuais
O sistema extrai texto e imagens de manuais em PDF usando bibliotecas especializadas. O texto é convertido em embeddings usando o modelo Amazon Titan v2 e armazenado nas Amazon Bedrock Knowledge Bases. As imagens também são processadas: modelos multimodais geram descrições detalhadas que incluem contexto das páginas adjacentes, e essas descrições são também convertidas em embeddings.
Durante a busca, o sistema transforma a consulta do usuário em múltiplas consultas relacionadas usando um LLM (Modelo de Linguagem Grande). Cada consulta recupera resultados de uma base de dados vetorial, e um algoritmo de fusão de ranking recíproco reordena esses resultados para priorizar informações verdadeiramente relevantes e semanticamente alinhadas. Texto e imagens são processados em fluxos separados de busca, garantindo que o resultado final combine insights escritos com suporte visual.
Pré-requisitos para Implementação
Para implementar com sucesso essa solução, algumas fundações precisam estar em lugar:
Identificar ativos críticos para manutenção preditiva—determinar quais equipamentos são mais essenciais e causariam maior impacto se falhassem
Coletar e registrar dados acionáveis—configurar monitoramento contínuo de vibração e temperatura em intervalos de um minuto com transferência automática para a nuvem
Reunir manuais de reparo—obter documentos dos fabricantes de equipamentos originais que detalhem requisitos de manutenção e procedimentos seguros
Manter registros históricos de manutenção (opcional mas recomendado)—dados anteriores ajudam a refinar modelos e melhorar a precisão de previsões
Impacto Operacional e Escalabilidade
A implementação dessa solução em centros de distribuição da Amazon demonstrou capacidade de reduzir significativamente o número de diagnósticos indeterminados. Ao fornecer aos técnicos orientação clara e acionável quando um alarme é disparado, o assistente não apenas acelera o processo de diagnóstico mas também melhora a confiabilidade geral das recomendações.
O design adaptável da solução a torna viável para diversos setores além da manufatura—indústrias de óleo e gás, logística e saúde podem todas se beneficiar dessa abordagem. Melhorias futuras poderiam incluir expansão de capacidades de busca para abranger vídeos, treinamento de agentes inteligentes para recomendar próximos passos com base em diagnósticos bem-sucedidos anteriores, e geração automática de ordens de trabalho que especifiquem recursos e tarefas com base nos resultados diagnósticos.
A AWS anunciou a integração de indexação SOCI (Seekable Open Container Initiative) no SageMaker Studio. Essa novidade possibilita um carregamento seletivo de imagens de container, onde apenas as partes necessárias são baixadas inicialmente, em vez de todo o arquivo de container.
O SageMaker Studio funciona como um Ambiente Integrado de Desenvolvimento (IDE) web para desenvolvimento completo de aprendizado de máquina, permitindo que usuários construam, treinem, implantem e gerenciem tanto modelos de ML tradicionais quanto modelos de fundação para todo o fluxo de trabalho. Cada aplicação executada no SageMaker Studio roda dentro de um container que empacota as bibliotecas, frameworks e dependências necessárias, garantindo execução consistente entre diferentes cargas de trabalho e sessões de usuário.
Essa arquitetura containerizada permite ao SageMaker Studio oferecer suporte a uma ampla gama de frameworks de ML como TensorFlow, PyTorch, scikit-learn e outros, mantendo isolamento forte entre ambientes.
O desafio da customização em escala
Embora a AWS forneça containers para os ambientes de ML mais comuns, cientistas de dados frequentemente precisam personalizar esses ambientes para casos de uso específicos. Isso pode incluir adicionar ou remover pacotes, configurar variáveis de ambiente customizadas ou instalar dependências especializadas.
Para atender essa necessidade, o SageMaker Studio oferece suporte por meio de Configurações de Ciclo de Vida (LCCs), que permitem executar scripts bash durante a inicialização de um espaço IDE. No entanto, customizar repetidamente ambientes dessa forma pode se tornar demorado e difícil de manter em escala.
Como alternativa, a plataforma suporta construção e registro de imagens de container personalizadas com bibliotecas e frameworks pré-configurados. Essas imagens reutilizáveis reduzem o atrito na configuração e melhoram a reprodutibilidade para consistência entre projetos, permitindo que cientistas de dados se concentrem no desenvolvimento de modelos em vez de gerenciamento de ambiente.
O problema da inicialização lenta
Conforme as cargas de trabalho de ML se tornam mais complexas, as imagens de container que alimentam esses ambientes crescem em tamanho, levando a tempos de inicialização mais longos. Isso pode atrasar a produtividade e interromper fluxos de trabalho de desenvolvimento.
Cientistas de dados, engenheiros de ML e desenvolvedores enfrentam tempos de espera mais longos para seus ambientes iniciarem, particularmente ao alternar entre diferentes frameworks ou ao usar imagens com extensas bibliotecas e dependências pré-instaladas. Essa latência de inicialização se torna um gargalo significativo no desenvolvimento iterativo de ML, onde experimentação rápida e prototipagem ágil são essenciais.
Como SOCI resolve o problema
Em vez de baixar a imagem de container inteira antecipadamente, SOCI cria um índice que permite ao sistema buscar apenas os arquivos e camadas específicas necessários para iniciar a aplicação, com componentes adicionais carregados sob demanda conforme necessário. Isso reduz significativamente os tempos de inicialização de container de alguns minutos para segundos, permitindo que ambientes SageMaker Studio sejam iniciados muito mais rapidamente e os usuários comecem a trabalhar em projetos de ML logo em seguida, melhorando a produtividade de desenvolvedores e reduzindo o tempo para obter insights de experimentos de ML.
Pré-requisitos
Para usar indexação SOCI com SageMaker Studio, é necessário:
Verificar que você possui AWS CLI versão 2.0 ou superior instalado para interagir com esses serviços e gerenciar suas imagens indexadas com SOCI.
Visão geral do recurso SOCI indexing
O SOCI (Seekable Open Container Initiative), originalmente disponibilizado como código aberto pela AWS, aborda atrasos na inicialização de containers no SageMaker Studio por meio de carregamento seletivo de imagens. Essa tecnologia cria um índice especializado que mapeia a estrutura interna de imagens de container para acesso granular a arquivos individuais sem baixar todo o arquivo de container primeiro.
Imagens de container tradicionais são armazenadas como listas ordenadas de camadas em arquivos tar compactados com gzip, que tipicamente exigem download completo antes de acessar qualquer conteúdo. SOCI supera essa limitação gerando um índice separado armazenado como um Artefato OCI que se vincula à imagem original de container por meio de Tipos de Referência OCI. Esse design preserva todas as imagens originais de container, mantém digests de imagem consistentes e garante validade de assinatura — fatores críticos para ambientes de IA/ML com requisitos rigorosos de segurança.
Para usuários do SageMaker Studio, a implementação de indexação SOCI por meio de integração com Finch container runtime resulta em redução de 35-70% nos tempos de inicialização de container em todos os tipos de instância usando Trazer Sua Própria Imagem (BYOI). Essa implementação vai além das estratégias de otimização atuais limitadas a combinações específicas de imagens de primeiro partido e tipos de instância, fornecendo tempos de inicialização de aplicação mais rápidos em ambientes SageMaker AI Studio e SageMaker Unified Studio.
Criando um índice SOCI
Para criar e gerenciar índices SOCI, é possível usar várias ferramentas de gerenciamento de container, cada uma oferecendo vantagens diferentes dependendo do seu ambiente de desenvolvimento e preferências:
Finch CLI é uma ferramenta de linha de comando compatível com Docker desenvolvida pela AWS que fornece suporte nativo para construção e envio de índices SOCI. Oferece uma interface familiar semelhante ao Docker enquanto inclui funcionalidade SOCI integrada, tornando direto criar imagens indexadas sem ferramental adicional.
nerdctl funciona como uma CLI alternativa de container para containerd, o container runtime padrão da indústria. Fornece comandos compatíveis com Docker enquanto oferece integração direta com funcionalidades de containerd, incluindo suporte SOCI para capacidades de carregamento lazy.
Docker + SOCI CLI combina o ferramental Docker amplamente utilizado com a interface de linha de comando dedicada a SOCI. Essa abordagem permite aproveitar fluxos de trabalho Docker existentes enquanto adiciona capacidades de indexação SOCI por meio de uma ferramenta CLI separada, oferecendo flexibilidade para equipes já investidas em processos de desenvolvimento baseados em Docker.
Fluxo de trabalho padrão versus otimizado com SOCI
No fluxo de trabalho padrão do SageMaker Studio, lançar um ambiente de aprendizado de máquina requer baixar a imagem de container completa antes que qualquer aplicação possa iniciar. Quando um usuário inicia uma nova sessão do SageMaker Studio, o sistema deve extrair a imagem inteira contendo frameworks como TensorFlow, PyTorch, scikit-learn, Jupyter e dependências associadas do registro de container. Esse processo é sequencial e demorado — o container runtime baixa cada camada compactada, extrai o sistema de arquivos completo para armazenamento local e apenas então a aplicação pode começar sua inicialização. Para imagens típicas de ML variando de 2-5 GB, isso resulta em tempos de inicialização de 3-5 minutos, criando atrito significativo em fluxos de trabalho de desenvolvimento iterativo onde cientistas de dados frequentemente alternam entre diferentes ambientes ou reiniciam sessões.
O fluxo de trabalho aprimorado com SOCI transforma a inicialização de container permitindo recuperação inteligente de arquivos sob demanda. Em vez de baixar imagens inteiras, SOCI cria um índice pesquisável que mapeia a localização precisa de cada arquivo dentro das camadas de container compactadas. Ao lançar uma aplicação SageMaker Studio, o sistema baixa apenas o índice SOCI (tipicamente 10-20 MB) e o conjunto mínimo de arquivos necessários para inicialização da aplicação — geralmente 5-10% do tamanho total da imagem. O container começa executando imediatamente enquanto um processo de background continua baixando arquivos restantes conforme a aplicação os solicita. Essa abordagem de carregamento lazy reduz tempos iniciais de inicialização de alguns minutos para segundos, permitindo que usuários comecem trabalho produtivo quase imediatamente enquanto o ambiente completa inicialização transparentemente em segundo plano.
Conversão de imagem para SOCI
É possível converter sua imagem existente em uma imagem SOCI e enviá-la para seu ECR privado usando os seguintes comandos:
#/bin/bash
# Download and install soci-snapshotter, containerd, and nerdctl
sudo yum install soci-snapshotter
sudo yum install containerd jq
sudo systemctl start soci-snapshotter
sudo systemctl restart containerd
sudo yum install nerdctl
# Set your registry variables
REGISTRY="123456789012.dkr.ecr.us-west-2.amazonaws.com"
REPOSITORY_NAME="my-sagemaker-image"
# Authenticate for image pull and push
AWS_REGION=us-west-2
REGISTRY_USER=AWS
REGISTRY_PASSWORD=$(/usr/local/bin/aws ecr get-login-password --region $AWS_REGION)
echo $REGISTRY_PASSWORD | sudo nerdctl login -u $REGISTRY_USER --password-stdin $REGISTRY
# Pull the original image
sudo nerdctl pull $REGISTRY/$REPOSITORY_NAME\:original-image
# Create SOCI index using the convert subcommand
sudo nerdctl image convert --soci $REGISTRY/$REPOSITORY_NAME\:original-image $REGISTRY/$REPOSITORY_NAME\:soci-image
# Push the SOCI v2 indexed image
sudo nerdctl push --platform linux/amd64 $REGISTRY/$REPOSITORY_NAME\:soci-image
Esse processo cria dois artefatos para a imagem de container original em seu repositório ECR: o índice SOCI (metadata que permite carregamento lazy) e o manifesto de índice de imagem (manifesto compatível com OCI que os vincula).
Para usar imagens indexadas com SOCI no SageMaker Studio, é necessário fazer referência à URI de índice de imagem em vez da URI original de imagem de container ao criar recursos SageMaker Image e SageMaker Image Version. A URI de índice de imagem corresponde à tag que você especificou durante o processo de conversão SOCI (por exemplo, soci-image no exemplo anterior).
#/bin/bash
# Use the SOCI v2 image index URI
IMAGE_INDEX_URI="123456789012.dkr.ecr.us-west-2.amazonaws.com/my-sagemaker-image:soci-image"
# Create SageMaker Image
aws sagemaker create-image \
--image-name "my-sagemaker-image" \
--role-arn "arn:aws:iam::123456789012:role/SageMakerExecutionRole"
# Create SageMaker Image Version with SOCI index
aws sagemaker create-image-version \
--image-name "my-sagemaker-image" \
--base-image "$IMAGE_INDEX_URI"
# Create App Image Config for JupyterLab
aws sagemaker create-app-image-config \
--app-image-config-name "my-sagemaker-image-config" \
--jupyter-lab-app-image-config '{
"FileSystemConfig": {
"MountPath": "/home/sagemaker-user",
"DefaultUid": 1000,
"DefaultGid": 100
}
}'
#Update domain to include the custom image (required step)
aws sagemaker update-domain \
--domain-id "d-xxxxxxxxxxxx" \
--default-user-settings '{
"JupyterLabAppSettings": {
"CustomImages": [{
"ImageName": "my-sagemaker-image",
"AppImageConfigName": "my-sagemaker-image-config"
}]
}
}'
A URI de índice de imagem contém referências tanto à imagem de container quanto ao seu índice SOCI associado através do manifesto Image Index compatível com OCI. Quando SageMaker Studio inicia aplicações usando essa URI, detecta automaticamente o índice SOCI e habilita capacidades de carregamento lazy. A indexação SOCI é suportada para todos os ambientes de ML (JupyterLab, CodeEditor, etc.) tanto para SageMaker Unified Studio quanto para SageMaker AI. Para informações adicionais sobre configuração de sua imagem personalizada, consulte a documentação SageMaker Bring Your Own Image.
Impacto mensurável de SOCI no SageMaker Studio
O objetivo principal dessa novidade no SageMaker Studio é simplificar a experiência do usuário final reduzindo tempos de inicialização para aplicações SageMaker Studio lançadas com imagens personalizadas. Para medir a efetividade do carregamento lazy de imagens de container personalizadas usando SOCI, foi realizada análise empírica comparando durações de inicialização de determinada imagem personalizada com e sem SOCI. Testes foram conduzidos para variedade de imagens personalizadas representando diversos conjuntos de dependências, arquivos e dados, avaliando como a efetividade pode variar para usuários finais com diferentes necessidades de imagem personalizada.
Para quantificar empiricamente durações de inicialização para launches de aplicação em imagem personalizada, foi usado programaticamente lançamento de JupyterLab e CodeEditor Apps com a API CreateApp do SageMaker, especificando o sageMakerImageArn candidato e sageMakerImageVersionAlias com um instanceType apropriado, registrando o eventTime para análise. Posteriormente, a API ListApps do SageMaker foi consultada a cada segundo para monitorar inicialização da aplicação, registrando o eventTime da primeira resposta onde Status foi reportado como InService. O delta entre esses dois tempos para determinada aplicação é a duração de inicialização.
Para essa análise, foram criados dois conjuntos de repositórios ECR privados, cada um com as mesmas imagens de container SageMaker personalizado, mas apenas um conjunto implementando índices SOCI. Ao comparar imagens equivalentes em ECR, era possível ver artefatos SOCI presentes apenas em um repositório. As aplicações foram implantadas em um único domínio SageMaker AI. Todas as imagens personalizadas foram anexadas a esse domínio para que usuários SageMaker Studio pudessem escolher essas imagens personalizadas ao invocar inicialização de um espaço JupyterLab.
Para executar testes, para cada imagem personalizada, foi invocada série de dez chamadas API CreateApp com especificações detalhadas de domínio, espaço, tipo de aplicação e especificações de recurso.
Os testes revelaram aceleração de inicialização com índice SOCI habilitado para distribuição de imagens Amazon SageMaker. Os dados mostram que executar imagens personalizadas SageMaker Studio com índices SOCI permite usuários lançar suas aplicações significativamente mais rápido comparado sem SOCI. Especificamente, foram observados tempos de inicialização de container aproximadamente 35-70% mais rápidos, com variações dependendo do tipo de instância e aplicação específica (JupyterLab versus CodeEditor).
Conclusão
A integração de indexação SOCI no SageMaker Studio representa um avanço importante na experiência de desenvolvedor para profissionais de aprendizado de máquina. Ao otimizar tempos de inicialização de container por meio de carregamento lazy — reduzindo tempos de espera de vários minutos para perto de um minuto — a solução contribui para que cientistas de dados, engenheiros de ML e desenvolvedores gastem menos tempo esperando e mais tempo inovando. Essa melhoria aborda um dos pontos de fricção mais comuns em desenvolvimento de ML iterativo, onde alternâncias frequentes de ambiente e reinicializações impactam produtividade. Com SOCI, equipes podem manter sua velocidade de desenvolvimento, experimentar diferentes frameworks e configurações, e acelerar seu caminho de experimentação para implantação em produção.
A AWS anunciou a disponibilidade do protocolo OCSP (Protocolo de Status de Certificado Online) para o AWS Private Certificate Authority (AWS Private CA) nas regiões da China e AWS GovCloud (US). Trata-se de uma expansão importante que amplia as capacidades de validação de certificados em regiões geograficamente estratégicas para empresas que operam nessas áreas.
O que é AWS Private CA
O AWS Private CA é um serviço gerenciado de autoridade certificadora que simplifica a criação e gestão de certificados privados para organizações. Diferentemente de manter uma infraestrutura própria de CA, o serviço elimina a complexidade operacional, permitindo que as equipes foquem no negócio em vez de gerenciar a infraestrutura de certificados.
Entendendo OCSP e suas vantagens
O OCSP é um protocolo que permite validação de certificados em tempo real. Em vez de as aplicações baixarem listas de revogação de certificados (CRL), que podem ter centenas de quilobytes, o OCSP possibilita consultas sob demanda sobre o status de um certificado específico. Cada consulta requer apenas alguns centenas de bytes, tornando o processo muito mais eficiente em termos de consumo de banda.
Com o suporte a OCSP agora disponível, clientes nessas regiões podem implementar validação de certificados mais eficiente com uso mínimo de largura de banda, comparado ao download de listas CRL tradicionais que podem ser significativamente maiores.
Casos de uso práticos
O OCSP é particularmente útil para:
Validação de comunicação entre microsserviços internos
Implementação de arquiteturas de segurança zero trust
Autenticação de dispositivos IoT que precisam verificar status de certificados em tempo real
Gestão totalmente automatizada
Uma característica diferencial é que a AWS gerencia completamente a infraestrutura do respondente OCSP, garantindo alta disponibilidade sem que o cliente precise implantar ou manter servidores OCSP próprios. Isso reduz ainda mais a complexidade operacional.
Regiões disponíveis
O OCSP está agora disponível nas seguintes regiões:
China (Beijing)
China (Ningxia)
AWS GovCloud (US-East)
AWS GovCloud (US-West)
Como habilitar OCSP
Para ativar OCSP nas autoridades certificadoras existentes, é possível usar o console do AWS Private CA, a interface de linha de comando (AWS CLI) ou a API.
Próximos passos
Organizações que operam nessas regiões e necessitam de validação de certificados mais eficiente podem explorar essa funcionalidade. Para informações detalhadas sobre revogação de certificados, consulte a documentação de revogação de certificados no guia do usuário do AWS Private CA. Detalhes de precificação estão disponíveis na página de preços do AWS Private CA.
