rss.livelink.threads-in-node

Evoluindo a Resposta a Incidentes em AKS com Azure SRE Agent - Parte 1

fabiodasilva — Tue, 04 Aug 2026 15:51:55 GMT

Resumo executivo

Em aplicações executadas no Azure Kubernetes Services (AKS), eventos OOMKilled estão entre as causas recorrentes de reinicialização de contêineres e indisponibilidade intermitente em aplicações web. A observabilidade fornecida por Azure Monitor, Container Insights, Log Analytics e métricas Prometheus permite detectar o sintoma, registrar o evento e disparar o alerta. A detecção isolada, porém, ainda deixa para a equipe de plantão o trabalho mais caro: correlacionar métricas, logs, eventos, alterações recentes e limites de recursos até chegar a uma hipótese defensável.

Sobre essa base de observabilidade, o Azure SRE Agent adiciona uma camada de raciocínio e execução governada. Ao receber o incidente, ele coleta evidências nas fontes conectadas, valida hipóteses e produz um diagnóstico explicável. Em seguida, recomenda a ação de menor risco e, conforme o modo de execução configurado, solicita aprovação humana ou executa uma remediação pré-autorizada. O resultado é um fluxo mais rápido e rastreável, sem eliminar os controles de acesso e aprovação.

Este whitepaper documenta o padrão em um laboratório reproduzível. No cenário, um pod em CrashLoopBackOff por limite de memória subdimensionado (20 Mi de limite, 10 Mi de solicitação) é investigado, diagnosticado e corrigido pelo agente sob aprovação humana, com verificação posterior e disparo automatizado por alerta do Azure Monitor.

Além do passo a passo, o documento aprofunda a mecânica que sustenta o diagnóstico, cgroups v2, o OOM killer do kernel, classes de QoS, working set versus RSS e o comportamento de heap dos runtimes, porque a qualidade da resposta assistida depende diretamente da qualidade dos sinais que a alimentam.

O que este documento entrega

A anatomia técnica de um evento OOMKilled em AKS, do cgroup ao status do pod.
Consultas KQL e PromQL prontas para detecção e para o desenho da regra de alerta.
O modelo operacional do Azure SRE Agent: fontes de contexto, modos de execução, permissões, hooks e políticas de acesso a ferramentas.
Um laboratório completo, do provisionamento do agente à recuperação verificada do workload.
Um enquadramento de governança, auditoria e segurança para operações agênticas.

O que este documento não cobre

Disparo totalmente automatizado a partir do alerta e integração com o processo de gestão de incidentes, tema da Parte 2.
Ajuste fino de capacidade em escala de frota (VPA/HPA em produção), tratado apenas como método.
Valores de preço vigentes; o modelo de cobrança é descrito de forma qualitativa.

1. Introdução

Aplicações nativas de nuvem distribuem o processamento entre pods, serviços, dependências e nós. Essa elasticidade melhora a escala, mas amplia a complexidade da investigação quando uma falha ocorre. Em um incidente de memória, o primeiro sinal pode ser um pod reiniciado, uma elevação de erros HTTP, aumento de latência ou degradação parcial de uma jornada específica.

O problema raramente é a ausência de dados. É o custo cognitivo de atravessar métricas, logs, eventos do Kubernetes, histórico de implantação e manifestos sob pressão de tempo, para só então formular uma hipótese. Esse custo é pago integralmente a cada incidente, e não se acumula como conhecimento reutilizável.

Este whitepaper apresenta um padrão de resposta a incidentes em que o Azure Monitor sustenta a detecção e a telemetria, enquanto o Azure SRE Agent converte sinais em contexto operacional acionável, preservando a decisão humana onde ela é necessária.

2. Contexto e desafio operacional

O cenário considera uma aplicação web em AKS instrumentada com Container Insights, Log Analytics, métricas Prometheus e alertas do Azure Monitor. O desafio não é apenas saber que um contêiner foi encerrado, é determinar por que a memória ultrapassou o limite, qual versão e qual carga estavam envolvidas, qual foi o impacto ao usuário e qual ação reduz risco sem ocultar a causa raiz. Ou seja, transformar sinais distribuídos em uma decisão defensável sobre pressão de tempo.

Telemetria distribuída entre métricas, logs, eventos e histórico de implantação.
Pressão de tempo para restaurar o serviço antes da violação do SLO.
Risco de reinicializações repetitivas que mascaram a ausência de correção estrutural.
Necessidade de aprovação, rastreabilidade e segregação de funções em ambientes regulados.

Há ainda um viés operacional relevante: sob pressão, o caminho mais curto, reiniciar o pod ou ampliar o limite de memória, quase sempre funciona no curto prazo. Isso torna difícil distinguir, retrospectivamente, um limite subdimensionado de um vazamento de memória lento, porque a evidência que separaria os dois é descartada junto com o contêiner encerrado.

3. Anatomia técnica do evento OOMKilled

Antes de delegar a investigação a um agente, é necessário estabelecer com precisão o que o sinal significa. Boa parte dos diagnósticos incorretos de memória em Kubernetes nasce da confusão entre três mecanismos distintos: o OOM killer do kernel atuando no cgroup do contêiner, o despejo (eviction) decidido pelo kubelet por pressão no nó, e o encerramento por falha da aplicação.

3.1 O caminho do kernel: cgroups v2, memory.max e o OOM killer

Quando um contêiner declara resources.limits.memory, o kubelet traduz esse valor para o controlador de memória do cgroup correspondente. Em nós AKS com imagens baseadas em Ubuntu 22.04 ou superior e Azure Linux 3.0, padrão em versões recentes do Kubernetes, o runtime opera sobre cgroup v2, e o limite é materializado no arquivo memory.max do cgroup do contêiner.

A partir daí, o comportamento é do kernel Linux, não do Kubernetes. Quando as páginas anônimas do cgroup não podem mais ser recuperadas e a alocação ultrapassaria memory.max, o kernel invoca o OOM killer restrito àquele cgroup, escolhe um processo e envia SIGKILL. O contador correspondente é incrementado em memory.events, no campo oom_kill.

# Dentro do nó, inspecionando o cgroup do contêiner (cgroup v2)

cat /sys/fs/cgroup/.../memory.max        # limite efetivo (bytes)

cat /sys/fs/cgroup/.../memory.high       # ponto de throttling por reclaim

cat /sys/fs/cgroup/.../memory.current    # uso corrente

cat /sys/fs/cgroup/.../memory.events     # low / high / max / oom / oom_kill

Vale distinguir dois campos frequentemente confundidos em memory.events: max conta quantas vezes a alocação esbarrou no teto e forçou reclaim, enquanto oom_kill conta quantos processos foram efetivamente encerrados. Um valor alto em max com oom_kill igual a zero indica um contêiner operando permanentemente no limite: degradado, porém vivo. É exatamente o estado que antecede o incidente e que raramente dispara alerta.

Como o processo recebe SIGKILL (sinal 9), o código de saída observado é 137, resultado da convenção POSIX 128 + número do sinal. O kubelet então registra o término e reinicia o contêiner conforme a restartPolicy. É por isso que a evidência canônica não está no status corrente do pod, mas no estado anterior do contêiner:

kubectl get pod <pod> -n pets -o jsonpath='{.status.containerStatuses[0].lastState.terminated}' | jq

# Saída esperada em um OOMKill:

# {

#   "exitCode": 137,

#   "reason": "OOMKilled",

#   "startedAt": "...",

#   "finishedAt": "..."

# }

Reinícios sucessivos levam o pod a CrashLoopBackOff, em que o kubelet aplica um atraso exponencial entre tentativas, iniciando na ordem de dezenas de segundos e dobrando até um teto de poucos minutos, cujo valor padrão vem sendo revisado em versões recentes do Kubernetes. Esse atraso é o motivo pelo qual a indisponibilidade percebida cresce ao longo do incidente mesmo sem agravamento da causa raiz.

3.2 OOMKilled não é eviction: dois mecanismos, duas correções

A distinção é operacionalmente decisiva porque as correções divergem: um OOMKill se resolve no manifesto do workload; um despejo se resolve na capacidade ou no agendamento do nó.

Dimensão	*OOMKilled* *(cgroup)*	*Eviction* *(kubelet)*
Gatilho	Alocação excede memory.max do cgroup do contêiner	memory.available do nó abaixo do limiar evictionHard/evictionSoft
Quem decide	Kernel Linux (OOM killer restrito ao cgroup)	kubelet, ordenando os pods por QoS e excesso sobre requests
Escopo	Um contêiner	O pod inteiro, podendo atingir vários pods do nó
Sinal	SIGKILL → exit code 137	Encerramento do pod; sem exit code 137 característico
Evidência	lastState.terminated.reason = OOMKilled	status.phase = Failed, reason = Evicted
Objeto do pod	Preservado; contêiner reinicia no mesmo pod	Pod permanece como registro de falha e é reagendado por seu controlador
Correção típica	Ajustar limits/requests ou o consumo da aplicação	Capacidade do nó, requests coerentes, limiares de despejo, distribuição

Nota. Um terceiro caso é frequentemente confundido com ambos: o encerramento do processo principal por erro da aplicação, que produz códigos de saída próprios (1, 2, 143 para SIGTERM). Verificar exitCode e reason antes de concluir por memória evita corrigir o sintoma errado.

3.3 Classes de QoS e a ordem em que os pods são sacrificados

O Kubernetes deriva a classe de Quality of Service de cada pod a partir da relação entre requests e limits. Essa classe não é apenas rótulo: ela determina a prioridade de despejo e influencia diretamente o valor de oom_score_adj atribuído aos processos do contêiner.

Classe de QoS	Condição	Prioridade de despejo
Guaranteed	requests iguais a limits para CPU e memória em todos os contêineres	Última a ser despejada
Burstable	Pelo menos um request ou limit definido, sem igualdade entre eles	Intermediária, proporcional ao excesso sobre o request
BestEffort	Nenhum request ou limit definido	Primeira a ser despejada

Para pods Burstable, o kubelet calcula oom_score_adj em função da fração da memória do nó reservada pelo request: quanto menor o request em relação à capacidade do nó, maior o score e mais atraente o processo se torna para o OOM killer. Pods Guaranteed recebem um valor fortemente negativo, e pods BestEffort recebem o valor máximo.

Aplicação ao laboratório

O order-service deste cenário declara requests de 10 Mi e limits de 20 Mi. A desigualdade entre os dois o classifica como Burstable, e o request muito baixo em relação à capacidade do nó eleva seu oom_score_adj. O workload é, portanto, simultaneamente o mais provável de estourar o próprio limite e um dos primeiros candidatos ao OOM killer sob pressão do nó, combinação que o torna um caso de teste representativo.

Há uma consequência de projeto pouco explorada: elevar apenas o limit sem elevar o request melhora a sobrevivência ao OOMKill do cgroup, mas mantém o pod vulnerável em cenários de pressão do nó, porque o agendador continua reservando pouca memória para ele. Foi exatamente por isso que a recomendação do agente no laboratório ajustou os dois valores, e não apenas o limite.

3.4 Working set, RSS e por que o dashboard pode enganar

A métrica que melhor aproxima a decisão do OOM killer é o working set, e não o RSS. Em cAdvisor, a fonte de container_memory_working_set_bytes e da métrica memoryWorkingSetBytes exposta pelo Container Insights, o working set corresponde ao uso total do cgroup menos o page cache inativo, isto é, a porção da memória que o kernel não conseguiria liberar trivialmente sob pressão.

Métrica	O que representa	Uso recomendado
container_memory_working_set_bytes	Uso do cgroup menos page cache inativo	Referência para alertas e para dimensionar limits
container_memory_rss	Páginas anônimas residentes do processo	Investigação de vazamento no heap da aplicação
container_memory_usage_bytes	Uso total, incluindo page cache reclaimável	Diagnóstico; superestima a pressão real
container_memory_cache	Page cache atribuído ao cgroup	Explicar divergência entre usage e working set

A armadilha prática: um painel construído sobre container_memory_usage_bytes pode indicar uso próximo ao limite sem risco real, porque boa parte é cache recuperável. Inversamente, um painel com média de 5 minutos pode mostrar 60% de uso e ainda assim o contêiner ser encerrado, porque o OOM killer reage a um pico instantâneo que a agregação suavizou. Alertas de memória devem usar working set e agregação por máximo, não por média.

3.5 Heap do runtime versus limite do contêiner

Uma causa frequente de OOMKilled não está no limite em si, mas no desalinhamento entre o limite do cgroup e a política de heap do runtime. Runtimes que dimensionam o heap a partir da memória visível do host, e não do limite do cgroup, planejam crescer muito além do que o contêiner pode alocar, e o kernel encerra o processo antes que o coletor de lixo julgue necessário agir.

*Runtime*	Controle recomendado	Observação
Node.js	--max-old-space-size (MB)	Fixar abaixo do limite do contêiner; o order-service deste laboratório é Node.js
JVM	-XX:MaxRAMPercentage com UseContainerSupport	Reservar espaço para metaspace, threads e buffers fora do heap
.NET	DOTNET_GCHeapHardLimitPercent; avaliar Server GC	Server GC eleva o consumo por número de núcleos visíveis
Go	GOMEMLIMIT	Limite flexível: intensifica a coleta em vez de abortar
Python	Limitar workers e pool de conexões	Sem heap gerenciado; o consumo escala com concorrência

Regra prática: o limite do contêiner deve acomodar o heap máximo do runtime somada a memória fora do heap, pilhas de threads, buffers de I/O, conexões, bibliotecas nativas e o próprio page cache anônimo. Dimensionar o heap igual ao limite do contêiner é uma causa clássica de OOMKilled sob carga.

3.6 Causas frequentes

Limite subdimensionado: o consumo legítimo da carga excede o valor configurado, como ocorre neste laboratório.
Vazamento de memória: o processo retém memória de forma progressiva entre requisições.
Pico de tráfego ou payload atípico: a demanda transitória ultrapassa a capacidade provisionada.
Concorrência excessiva: workers, filas ou caches locais ampliam o working set de forma não linear.
Requests e limits incoerentes: o agendamento e a contenção não refletem o perfil real de consumo.
Heap do runtime maior que o limite do cgroup: o processo planeja crescer além do permitido.
Valores herdados de um dimensionamento anterior que nunca foi revisado após mudanças de código ou de carga.

4. Impactos para aplicações web em AKS

Dimensão	Impacto potencial
Usuário	Erros HTTP 5xx, timeouts, perda de sessão e latência elevada.
Aplicação	Interrupção de requisições em andamento, reprocessamento e perda de cache local.
Plataforma	CrashLoopBackOff, aumento de restarts e pressão sobre outros pods ou nós.
Negócio	Violação de SLO, risco à receita e degradação da experiência digital.
Operações	Escalonamento de plantão, investigação manual e aumento do MTTR.

Um agravante específico do OOMKilled é o efeito em cascata: ao reiniciar, o contêiner reconstrói caches e refaz conexões, produzindo um pico de consumo de memória e CPU justamente no momento em que a capacidade agregada do serviço está reduzida. Isso pode encadear novos encerramentos em réplicas ainda saudáveis e transformar uma falha localizada em degradação do serviço.

5. Detecção: sinais, consultas e desenho do alerta

A qualidade da investigação assistida depende da qualidade dos sinais disponíveis. Esta seção consolida as consultas usadas para detectar OOMKilled em AKS e o desenho da regra de alerta empregada no laboratório.

5.1 Sinais canônicos

# Estado atual e contagem de reinícios

kubectl get pods -n pets -o wide

# Razão do término anterior, a evidência decisiva

kubectl get pods -n pets -o custom-columns=\

NAME:.metadata.name,\

STATUS:.status.phase,\

RESTARTS:.status.containerStatuses[0].restartCount,\

REASON:.status.containerStatuses[0].lastState.terminated.reason,\

EXIT:.status.containerStatuses[0].lastState.terminated.exitCode

# Limites efetivamente aplicados ao contêiner

kubectl get deployment order-service -n pets \

-o jsonpath='{.spec.template.spec.containers[0].resources}'

# Eventos correlatos na janela do incidente

kubectl get events -n pets --sort-by=.lastTimestamp

5.2 Consultas KQL no Log Analytics

Com Container Insights habilitado, o inventário de pods carrega o estado anterior de cada contêiner em formato JSON, o que permite isolar terminações por OOMKilled diretamente na consulta:

// Contêineres encerrados por OOMKilled nas últimas 6 horas

KubePodInventory

| where TimeGenerated > ago(6h)

| where isnotempty(ContainerLastStatus)

| extend LastStatus = parse_json(ContainerLastStatus)

| where tostring(LastStatus.reason) == "OOMKilled"

| project TimeGenerated, ClusterName, Namespace, Name,

          ContainerName = ContainerName,

          ExitCode = toint(LastStatus.exitCode),

          RestartCount = ContainerRestartCount,

          FinishedAt = todatetime(LastStatus.finishedAt)

| summarize Ocorrencias = count(),

            Ultima = max(FinishedAt),

            MaxRestarts = max(RestartCount)

          by ClusterName, Namespace, ContainerName

| order by Ocorrencias desc

Os eventos do Kubernetes oferecem uma segunda camada de confirmação, útil quando o intervalo de coleta do inventário perde uma terminação de curta duração:

// Eventos de OOM e falhas de inicialização correlatas

KubeEvents

| where TimeGenerated > ago(6h)

| where Reason in ("OOMKilling", "OOMKilled", "BackOff", "Failed")

| project TimeGenerated, ClusterName, Namespace, Name, Reason, Message

| order by TimeGenerated desc

Para separar limite subdimensionado de vazamento, a consulta relevante é a tendência do working set contra o limite declarado. Um platô estável junto ao teto sugere subdimensionamento; uma inclinação positiva sustentada entre reinícios sugere retenção progressiva:

// Working set máximo por contêiner, em janelas de 5 minutos

Perf

| where TimeGenerated > ago(24h)

| where ObjectName == "K8SContainer"

| where CounterName == "memoryWorkingSetBytes"

| summarize MaxWorkingSetMi = max(CounterValue) / 1024 / 1024

by bin(TimeGenerated, 5m), InstanceName

| render timechart

5.3 Equivalentes em PromQL

Em clusters com Azure Monitor managed service for Prometheus, os mesmos sinais ficam disponíveis como séries temporais, o que facilita alertas baseados em razão de utilização:

# Razão entre working set e limite declarado, por pod

max by (namespace, pod, container) (

container_memory_working_set_bytes{namespace="pets", container!=""}

)

/

max by (namespace, pod, container) (

kube_pod_container_resource_limits{namespace="pets", resource="memory"}

)

# Contêineres cuja última terminação foi OOMKilled

kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1

# Taxa de reinícios na última hora

increase(kube_pod_container_status_restarts_total{namespace="pets"}[1h]) > 0

Nota. Um alerta preventivo sobre a razão working set / limite acima de 0,85 por vários minutos antecipa o incidente antes do primeiro OOMKill, transformando uma interrupção em uma tarefa de dimensionamento planejada. Essa é a regra que mais reduz incidentes desta classe.

5.4 Desenho da regra de alerta utilizada no laboratório

A regra empregada no cenário é uma Log Alert V2 sobre o workspace do Log Analytics, avaliando a consulta de OOMKilled e disparando quando a contagem de resultados é maior que zero.

Parâmetro	Valor no laboratório	Consideração de produção
Tipo	Log search alert (Log Alerts V2)	Consultas sobre logs; considerar alerta de métrica para latência menor
Escopo	Workspace do Log Analytics do cluster	Escopo por cluster ou por assinatura, conforme o modelo de plantão
Lógica	Contagem de resultados maior que 0	Aumentar o limiar para tolerar reinícios isolados e evitar ruído
Severidade	1, Error	Alinhar à criticidade do serviço e à política de plantão
Frequência / janela	Avaliação periódica sobre janela curta	Janela igual ou maior que a frequência, para não perder eventos
Ação	Action group com notificação por e-mail	Encaminhar também a ITSM/PagerDuty e ao gatilho do agente
Auto-resolução	Padrão da regra	Habilitar para incidentes transitórios; desabilitar se exigir baixa manual

Latência esperada de ponta a ponta

No laboratório, o pod entrou em OOMKilled às 17h45 e a notificação chegou às 17h47. Esses dois minutos somam ingestão no Log Analytics, período de avaliação da regra e entrega pelo action group. Alertas baseados em log carregam essa latência por construção, um dado relevante ao definir SLOs de detecção e ao decidir entre alerta de log e alerta de métrica.

6. O processo tradicional e seus limites

6.1 Fluxo típico de resposta

O Azure Monitor dispara o alerta e notifica o plantão.
O plantonista abre o portal, os dashboards e o Log Analytics.
Executa comandos kubectl para localizar o pod e confirmar a razão do término.
Compara consumo, limite, reinícios, eventos e alterações recentes.
Formula uma hipótese, reinicia ou reimplanta o workload e acompanha a recuperação.
Registra evidências e ações no sistema ITSM.

6.2 Limitações do modelo reativo

Esse fluxo depende da experiência individual, exige alternância constante entre ferramentas e produz decisões inconsistentes entre plantonistas. Um restart reduz o sintoma, mas não distingue vazamento de memória, limite inadequado ou pico legítimo de carga.

Sob pressão, cresce também o risco de ampliar recursos sem validação, perder evidências ao encerrar o contêiner afetado ou executar ações privilegiadas fora do processo de mudança. O custo mais alto, porém, é invisível: o conhecimento produzido durante a investigação permanece no indivíduo e não fica disponível para o próximo incidente da mesma classe.

7. Azure SRE Agent: arquitetura e modelo operacional

O Azure SRE Agent é um agente de confiabilidade que conecta fontes de observabilidade, plataformas de incidente, repositórios de código e conhecimento operacional. Ele investiga causas prováveis, propõe mitigações e automatiza respostas orientadas por planos e runbooks, dentro de guardrails e fluxos de aprovação.

Princípio de arquitetura

O Azure Monitor permanece como fonte de detecção e evidência. O SRE Agent atua como camada de investigação, decisão e orquestração governada. O agente não substitui a observabilidade: ele consome e correlaciona o que ela produz.

7.1 Fontes de contexto

A qualidade do diagnóstico é função direta das fontes conectadas. Durante a configuração, o agente solicita explicitamente a associação de quatro categorias de contexto.

Fonte	O que habilita	Uso no cenário OOMKilled
Recursos do Azure	Consultar e operar recursos por meio da identidade do agente	Ler o estado do cluster AKS e aplicar a mitigação aprovada
Logs	Consultar workspaces do Log Analytics	Correlacionar eventos, inventário de pods e métricas de working set
Código	Acessar repositórios e artefatos de engenharia	Relacionar o limite aplicado ao manifesto de origem
Incidentes	Integrar Azure Monitor, ServiceNow e PagerDuty	Receber o alerta e vincular a investigação ao incidente

7.2 Execução por ferramentas e classificação de risco

O agente não age por um canal opaco, cada passo é uma chamada de ferramenta explícita, um comando da CLI do Azure, uma consulta KQL, um comando kubectl, apresentada na thread com o comando exato e uma classificação de risco associada. No laboratório, comandos de leitura como az aks show aparecem marcados como Safe, enquanto operações como kubectl get deployments e kubectl patch recebem a marcação Medium risk.

Essa transparência tem duas consequências práticas. A primeira é auditoria: a thread registra a sequência exata de comandos, permitindo reconstruir a investigação. A segunda é revisão: o operador avalia o comando concreto, não uma descrição em linguagem natural do que o agente pretende fazer.

7.3 Modos de execução (Run Modes)

Os modos de execução controlam o fluxo de aprovação, isto é, se o agente pergunta antes de agir. É importante separar esse conceito das permissões, que controlam o acesso ao recurso. O agente precisa das duas condições satisfeitas para executar uma ação.

Modo	Comportamento	Indicação
Review	O agente propõe a ação e aguarda Approve ou Deny	Produção, infraestrutura crítica, alertas de segurança
Autonomous	O agente executa imediatamente e relata o que fez	Ambientes de não produção e tarefas recorrentes confiáveis

Três detalhes que mudam o desenho de governança

Primeiro: o modo de execução é definido por plano de resposta e por tarefa agendada, não no nível do agente; a configuração do agente serve apenas como padrão de fallback. Segundo: os botões Approve e Deny aparecem para operações de infraestrutura do Azure; outras ações, como enviar e-mail, publicar no Teams ou consultar fontes externas, seguem a instrução do plano de resposta e exigem hooks ou políticas de acesso a ferramentas para receber controle equivalente. Terceiro: apenas administradores do SRE Agent podem aprovar ações, o que materializa a segregação de funções.

Uma observação de adoção relevante: os planos de resposta e as tarefas agendadas assumem Autonomous como padrão, enquanto o agente é criado em Review. Assumir que criar o agente em Review protege automaticamente todos os fluxos é um erro de configuração fácil de cometer e caro de descobrir.

7.4 Permissões, escopo e elevação sob demanda

O agente opera por meio de uma identidade gerenciada, e o que ele consegue fazer é delimitado pelas atribuições RBAC dessa identidade e pelo escopo em que foram concedidas. Quando o agente não possui a permissão necessária para uma operação, ele solicita acesso temporário por meio do fluxo On-Behalf-Of do Microsoft Entra, em vez de falhar silenciosamente.

Esse comportamento é arquiteturalmente importante: ele permite conceder à identidade do agente um conjunto mínimo e permanente de permissões de leitura, deixando as operações de escrita dependentes de uma elevação explícita e rastreável. É o oposto do padrão adotado no laboratório, que concede permissões amplas por conveniência de demonstração.

7.5 Hooks e políticas de acesso a ferramentas

Hooks são pontos de verificação personalizados que validam, auditam ou bloqueiam o comportamento do agente em momentos específicos do fluxo. Eles complementam os modos de execução: enquanto os modos controlam quando o agente pode agir, os hooks controlam o que acontece antes e depois de cada ação.

Evento	Quando dispara	Aplicações típicas
PostToolUse	Após a execução de uma ferramenta	Auditar o uso, bloquear ou sinalizar operações inseguras, injetar contexto adicional no resultado
Stop	Quando o agente vai devolver a resposta final	Validar completude, exigir formato, rejeitar a resposta e forçar continuidade da investigação

Tipos de execução: Prompt, avaliado pelo modelo para verificações que exigem julgamento; e Command, script determinístico para auditoria e aplicação de política.
Escopos de configuração: no nível do agente, aplicando-se a todas as threads; ou no nível de um agente personalizado. Quando ambos correspondem, os dois executam.
Políticas de acesso a ferramentas complementam os hooks ao restringir previamente quais ferramentas podem ser invocadas em cada contexto.

7.6 Provedor de modelo e residência de dados

O provedor de modelo é escolhido na criação do agente e pode ser alterado depois, sem recriar o recurso. Há duas famílias disponíveis, com perfis distintos: modelos do Azure OpenAI e modelos Anthropic Claude.

Para organizações reguladas, essa escolha ultrapassa o critério de qualidade de raciocínio e entra no domínio de conformidade: os provedores diferem quanto à cobertura de requisitos de residência de dados, incluindo o EU Data Boundary, e a disponibilidade varia por região. A recomendação é validar os requisitos de residência e a lista de regiões suportadas na documentação vigente antes de padronizar o provedor para cargas de produção.

7.7 Modelo de consumo

O consumo do agente é medido em Azure Agent Units e combina dois componentes: um fluxo contínuo, associado à existência do agente e ao monitoramento de base, e um fluxo ativo, proporcional aos tokens processados durante investigações. Modelos com janelas de contexto maiores tendem a consumir mais no fluxo ativo.

A implicação de FinOps é direta: o custo escala com o volume de investigações e com a profundidade do contexto conectado, não com o número de recursos monitorados. Reduzir alertas ruidosos diminui o custo do agente pelo mesmo mecanismo que reduz a fadiga do plantão. Consulte a página de preços para os valores vigentes.

8. Processo de resposta com o SRE Agent

Receber e classificar: consumir o incidente do Azure Monitor e aplicar filtros por severidade, serviço e título.
Coletar evidências: consultar Log Analytics, métricas, eventos do Kubernetes, estado do pod, histórico de implantação e runbooks.
Formar hipóteses: comparar limite versus uso, tendência temporal, payload, versão implantada e eventos correlatos.
Validar: sustentar cada hipótese com evidência observável e registrar as alternativas descartadas.
Recomendar: apresentar ação imediata, correção estrutural, risco associado e critérios de rollback.
Agir sob governança: executar apenas ações pré-autorizadas ou aguardar aprovação, conforme o modo de execução do plano.
Verificar e aprender: confirmar a estabilidade, documentar o resultado e enriquecer a memória operacional.

A etapa 4 é a que mais diferencia uma investigação assistida de uma sugestão genérica. Um diagnóstico útil não afirma apenas qual é a causa provável: registra qual evidência sustenta a conclusão, qual hipótese foi descartada e por quê. É esse registro que permite ao operador revisar a decisão em segundos, em vez de refazer a investigação.

9. Cenário do incidente

9.1 Situação

O serviço order-service, no namespace pets, processa requisições de uma aplicação web de comércio eletrônico. Após aumento de tráfego e uso de payloads maiores, as réplicas passam a reiniciar. O Azure Monitor detecta a elevação na contagem de reinicializações e a ocorrência de eventos OOMKilled.

9.2 Linha de investigação

#	Evidência buscada	Interpretação
1	reason igual a OOMKilled e exitCode 137 em lastState	Encerramento pelo kernel por ultrapassagem do limite do cgroup, não falha da aplicação.
2	Working set atingindo o limite declarado	Distinguir limite inadequado de crescimento anômalo entre requisições.
3	Pico correlacionado a tráfego ou tamanho de payload	Avaliar comportamento legítimo versus retenção progressiva de memória.
4	Implantação recente do workload	Determinar se houve regressão em código ou em configuração de recursos.
5	Contagem de restarts e erros HTTP	Quantificar impacto ao usuário e urgência da mitigação.
6	Classe de QoS e relação requests/limits	Avaliar exposição adicional a despejo por pressão no nó.

9.3 Formato do diagnóstico assistido

O agente entrega um resumo com causa provável, grau de confiança, evidências que a sustentam, alternativas descartadas e plano de mitigação com critério de reversão. A estrutura importa tanto quanto o conteúdo: ela permite que a revisão humana seja auditoria, e não repetição do trabalho.

O contêiner atingiu repetidamente o limite de memória durante o processamento de payloads acima do padrão histórico. Não há evidência suficiente de crescimento contínuo entre requisições; a hipótese principal é limite subdimensionado para a nova carga. Mitigação proposta: elevar limits e requests de memória, com verificação do consumo após a alteração.

10. Implementação e validação do cenário no AKS

A seguir, o padrão conceitual é aplicado a um ambiente AKS de demonstração. O objetivo é conectar o cluster ao SRE Agent, conceder as permissões necessárias, integrar as fontes de observabilidade e validar o fluxo de diagnóstico e recuperação de um pod afetado por OOMKilled.

Preparar o ambiente: validar o cluster AKS, a aplicação de demonstração e o estado inicial do workload.
Criar o SRE Agent: provisionar o agente e selecionar o provedor de modelo conforme os requisitos do ambiente.
Conectar as fontes de dados: integrar o cluster, o Azure Monitor e o Log Analytics para disponibilizar alertas, logs e métricas.
Conceder permissões: atribuir à identidade gerenciada do agente o acesso necessário para investigar e, no laboratório, executar a remediação aprovada.
Validar diagnóstico e recuperação: provocar o evento OOMKilled, acompanhar a investigação, aprovar a recomendação e confirmar a recuperação do pod.

Escopo do laboratório

As permissões concedidas nesta seção são deliberadamente amplas para reduzir o atrito da demonstração. Elas não representam uma configuração recomendada para produção. A seção 10.5 apresenta o desenho de menor privilégio equivalente, e a seção 12 detalha as implicações de segurança.

10.1 Ambiente e pré-requisitos

A aplicação utilizada é o AKS Store Demo, exemplo de referência da Microsoft que representa uma loja de comércio eletrônico decomposta em microsserviços poliglotas. A tabela a seguir consolida a configuração do ambiente, para permitir a reprodução do cenário.

Componente	Configuração no laboratório
Cluster	AKS-SRE-Demo-Cluster, SKU Base, tier Free, 1 node pool
Versão do Kubernetes	1.35.6
Região	East US 2
Rede	Azure CNI Overlay
Observabilidade	Container Insights habilitado, enviando logs e métricas ao Log Analytics
Aplicação	AKS Store Demo, namespace pets, exposta por Service do tipo LoadBalancer
Workload em falha	order-service (Node.js), requests 10 Mi / limits 20 Mi de memória
Alerta	Alert-OOMKilled-Pods, Log Alerts V2, severidade 1, Error
Agente	Azure SRE Agent provisionado no grupo de recursos Azure-SRE-RG

A arquitetura da aplicação é relevante para o diagnóstico: o order-service recebe pedidos do store-front e os publica em uma fila RabbitMQ, consumida pelo makeline-service. Um serviço que faz buffer de mensagens antes de publicar é estruturalmente sensível ao tamanho do payload e à concorrência, precisamente o perfil que torna um limite de 20 Mi insustentável sob carga.

10.2 Arquitetura e estado inicial da aplicação

Figura 1: Arquitetura do AKS Store Demo. O store-front e o store-admin consomem o order-service (Node.js), o product-service (Rust), o makeline-service (Go) e o ai-service (Python), com RabbitMQ como broker de mensagens e MongoDB como armazenamento de estado.

Figura 2: Página inicial da aplicação de demonstração, publicada por meio de um Service do tipo LoadBalancer. O endereço IP público foi suprimido.

Figura 3: Visão geral do cluster AKS antes da investigação: Kubernetes 1.35.6, região East US 2, configuração de rede Azure CNI Overlay e um único node pool. Identificadores de assinatura e o endereço do servidor de API foram suprimidos.

A inspeção do namespace revela o estado que servirá de referência para todo o exercício. O pod do order-service encontra-se em CrashLoopBackOff, acumulando reinicializações sucessivas, o sintoma de superfície de um encerramento repetido pelo kernel.

Figura 4: Saída de kubectl get all -n pets. O pod do order-service aparece em CrashLoopBackOff com reinicializações acumuladas, enquanto os demais serviços do namespace permanecem íntegros. Endereços IP públicos foram suprimidos.

Nota. Observe que apenas um serviço está afetado. Essa assimetria já elimina hipóteses de escopo mais amplo, pressão de memória no nó, falha do runtime de contêiner ou problema de rede, e concentra a investigação na configuração ou no comportamento daquele workload específico.

10.3 Criação do agente e escolha do provedor de modelo

O agente é provisionado no portal do SRE Agent, em sre.azure.com.

Figura 5: Portal do Azure SRE Agent. A criação inicia pela opção Create Agent.

No formulário, define-se o grupo de recursos, o nome do agente e o provedor de modelo. É possível escolher entre Azure OpenAI, com a família GPT-5, e Anthropic, com a família Claude, e alterar essa opção posteriormente sem recriar o recurso. Conforme discutido na seção 7.6, essa escolha deve considerar também os requisitos de residência de dados da organização.

Figura 6: Formulário de criação do agente, com a seleção do grupo de recursos, do nome e do provedor de modelo.

Figura 7: Revisão da configuração antes da confirmação. Nomes de assinatura foram suprimidos.

Figura 8: Provisionamento do agente em andamento.

Figura 9: Agente criado. A opção Set up your agent conduz à configuração das fontes de contexto.

10.4 Conexão das fontes de contexto

O objetivo do agente é investigar as aplicações em execução no cluster AKS. Para isso, conecta-se primeiro o recurso do cluster.

Figura 10: Associação do recurso do cluster AKS ao agente.

Figura 11: Seleção do grupo de recursos onde o cluster AKS está provisionado.

Figura 12: Confirmação do escopo selecionado. Nomes de assinatura foram suprimidos.

Neste laboratório, o agente receberá permissões ampliadas para executar tarefas específicas no cluster. Essa configuração é restrita ao ambiente de demonstração. Em produção, recomenda-se aplicar o princípio do menor privilégio, limitar o escopo das funções, exigir aprovação para ações de maior impacto e validar previamente operações autorizadas, como alterar um pod ou recuperar um nó com estado desconhecido.

Figura 13: Definição do nível de permissão concedido ao agente sobre os recursos conectados.

Em seguida, integra-se o agente ao Azure Monitor, para que ele acesse os alertas configurados e inicie uma investigação quando o incidente correspondente for emitido.

Figura 14: Integração com o Azure Monitor, habilitando o consumo de alertas como gatilho de investigação.

Além do Azure Monitor, o agente pode ser integrado ao ServiceNow e ao PagerDuty para apoiar fluxos de investigação e gestão de incidentes, permitindo que a thread da investigação seja correlacionada ao registro formal do incidente.

Figura 15: Integrações disponíveis com plataformas de gestão de incidentes.

O cluster tem o Container Insights habilitado e envia logs e métricas ao workspace do Log Analytics. Conectar esse workspace é o que permite ao agente executar as consultas KQL apresentadas na seção 5 durante a investigação.

Figura 16: Início da conexão com o Log Analytics.

Figura 17: Seleção do workspace do Log Analytics associado ao cluster.

Figura 18: Preenchimento dos dados do workspace. Identificadores de assinatura foram suprimidos.

Figura 19: Conclusão da conexão com o Log Analytics.

Figura 20: Painel de configuração das fontes de contexto, consolidando código, logs, recursos do Azure e incidentes. A amplitude do contexto conectado determina diretamente a profundidade possível do diagnóstico.

10.5 Identidade gerenciada e atribuições RBAC

Neste ponto o agente já é funcional para investigação. Para que ele também possa executar a remediação no cluster, atribuem-se funções à sua identidade gerenciada. O primeiro passo é identificar essa identidade.

Figura 21: Identidade gerenciada associada ao agente. Os identificadores de cliente, de principal e de assinatura foram suprimidos.

No laboratório, foram atribuídas as funções Azure Kubernetes Service Cluster Admin Role e Azure Kubernetes Service Contributor Role, com escopo no grupo de recursos do cluster.

az role assignment create `

   --assignee "<uami-client-id>" `

   --role "Azure Kubernetes Service Cluster Admin Role" `

   --scope "/subscriptions/<subscription-id>/resourceGroups/Azure-SRE-RG"

az role assignment create `

   --assignee "<uami-client-id>" `

   --role "Azure Kubernetes Service Contributor Role" `

   --scope "/subscriptions/<subscription-id>/resourceGroups/Azure-SRE-RG"

Figura 22: Resultado da atribuição da função Azure Kubernetes Service Cluster Admin Role. Identificadores de assinatura, de principal e da atribuição foram suprimidos.

Figura 23: Resultado da atribuição da função Azure Kubernetes Service Contributor Role.

A confirmação é feita no painel Access control (IAM) do cluster, localizando as atribuições concedidas à identidade gerenciada do agente.

Figura 24: Painel de controle de acesso do cluster, confirmando as duas atribuições à identidade gerenciada do agente (destacadas). Identificadores de objeto e nomes de entidades de serviço do locatário foram suprimidos.

Por que essa configuração não deve ir para produção

A função Azure Kubernetes Service Cluster Admin Role autoriza a obtenção da credencial administrativa do cluster. Essa credencial é um certificado de cliente que opera fora da integração com o Microsoft Entra ID e da autorização RBAC do Kubernetes, ou seja, contorna exatamente os controles de identidade que a organização configurou no cluster. Some-se a isso a função Contributor no grupo de recursos, e a identidade do agente passa a acumular controle administrativo do plano de dados e amplo poder no plano de controle.

O desenho equivalente sob menor privilégio troca esse par de funções por um conjunto mínimo, com escopo no cluster e não no grupo de recursos, apoiando-se no fluxo de elevação sob demanda descrito na seção 7.4 para as operações de escrita eventuais.

Necessidade	Função recomendada	Escopo
Obter kubeconfig respeitando o Entra ID	Azure Kubernetes Service Cluster User Role	Cluster
Leitura no plano de dados do Kubernetes	Azure Kubernetes Service RBAC Reader	Cluster ou namespace
Escrita controlada no plano de dados	Azure Kubernetes Service RBAC Writer	Namespace do workload
Consultar métricas e logs	Monitoring Reader	Workspace do Log Analytics
Operações de infraestrutura do cluster	Elevação sob demanda via fluxo On-Behalf-Of	Por operação, com registro

Nota. As funções RBAC do Kubernetes (Reader, Writer, Admin) exigem que a autorização RBAC do Azure para Kubernetes esteja habilitada no cluster. Escopar por namespace, e não pelo cluster inteiro, reduz o raio de impacto de uma ação incorreta ao conjunto de workloads sob responsabilidade daquele agente.

10.6 Investigação assistida

A primeira interação é deliberadamente simples: uma pergunta aberta sobre a saúde do cluster, sem indicar o problema. O objetivo é avaliar se o agente chega ao workload afetado por conta própria.

Figura 25: Estado do pod do order-service imediatamente antes da investigação, usado como linha de base para validar diagnóstico e recuperação.

Figura 26: O agente inicia a investigação executando comandos de inspeção. Cada chamada de ferramenta exibe o comando exato e a classificação de risco associada: Safe para az aks show e Medium risk para kubectl get deployments. Identificadores de assinatura foram suprimidos.

A Figura 26 concentra o que diferencia esse modelo de uma automação convencional. O agente não executa um runbook fixo: ele escolhe o próximo comando a partir do resultado do anterior, e cada escolha fica registrada com o comando literal e sua classificação de risco. O operador acompanha a cadeia de raciocínio como uma sequência auditável de operações, não como uma caixa-preta que devolve uma conclusão.

Figura 27: O agente identifica o pod do order-service em CrashLoopBackOff, com 13 reinicializações acumuladas.

A partir do estado do pod, o agente correlaciona a razão do término com os limites declarados no manifesto e conclui que o limite de 20 Mi é insuficiente para a carga observada. A recomendação é elevar o limite para 128 Mi e a solicitação para 64 Mi, acompanhando o consumo após a alteração.

Figura 28: Diagnóstico do agente: OOMKilled associado ao limite de 20 Mi e à solicitação de 10 Mi, com recomendação de elevação para 128 Mi e 64 Mi respectivamente.

Figura 29: Continuação do diagnóstico, com o detalhamento das evidências e das alternativas consideradas.

Leitura crítica da recomendação

A recomendação ajusta requests e limits em conjunto, e não apenas o limite, o que, conforme a seção 3.3, preserva a classe Burstable com uma reserva de memória compatível e reduz a exposição a despejo por pressão no nó. O agente também sinaliza que valores maiores, como 256 Mi, só devem ser adotados após análise de métricas, testes de carga e investigação de possível vazamento. Essa ressalva é o que separa uma mitigação de uma correção: o número proposto restabelece o serviço, mas ainda não é um dimensionamento validado.

10.7 Mitigação aprovada e verificação

A recomendação é apresentada como uma ação concreta a ser aprovada. O comando exibido é exatamente o que será executado:

kubectl patch deployment order-service -n pets --type='json' -p='[

{"op":"replace",

   "path":"/spec/template/spec/containers/0/resources/limits/memory",

   "value":"128Mi"},

{"op":"replace",

   "path":"/spec/template/spec/containers/0/resources/requests/memory",

   "value":"64Mi"}

]'

O efeito é alterar os recursos de memória do deployment order-service no namespace pets: o limite passa de 20 Mi para 128 Mi e a solicitação, de 10 Mi para 64 Mi. Como a alteração atinge o template do pod, o controlador executa um rollout, substituindo as réplicas existentes.

Figura 30: Proposta de alteração apresentada para revisão. A ação é classificada como Medium risk e apresenta os controles Approve action e Cancel, com a indicação de que as permissões do agente serão utilizadas para concluí-la.

Aprovada a ação, o agente a executa e passa espontaneamente à verificação, consultando o estado do novo pod em vez de declarar sucesso pela ausência de erro no comando.

Figura 31: Após aplicar o patch, o agente consulta o estado do novo pod e aguarda a conclusão do startup probe antes de concluir.

Esse detalhe merece destaque: o agente distingue a execução bem-sucedida de um comando da recuperação efetiva do serviço, e aguarda a passagem pelo startup probe antes de afirmar que o problema foi resolvido. É a mesma disciplina que se espera de um operador experiente.

Figura 32: Comparação entre o estado anterior e o posterior apresentada pelo agente, acompanhada da ressalva sobre reconciliação com a fonte da verdade quando o deployment é gerenciado por GitOps, Helm ou pipeline de IaC.

Dimensão	Antes	Depois
Estado do pod	CrashLoopBackOff, 13 reinicializações	Running, Ready, 0 reinicializações
Memória (request/limit)	10 Mi / 20 Mi	64 Mi / 128 Mi
Classe de QoS	Burstable, com reserva mínima	Burstable, com reserva compatível

Figura 33: Validação manual por kubectl: todos os objetos do namespace pets em execução, com o order-service estável e sem reinicializações.

10.8 Reconciliação com a fonte da verdade

Um ponto levantado pelo próprio agente na Figura 32 merece tratamento explícito, porque é onde a maioria das remediações assistidas falha silenciosamente: a alteração foi aplicada diretamente ao objeto no cluster.

Se o deployment for gerenciado por GitOps, Helm ou qualquer pipeline de infraestrutura como código, a fonte da verdade continua declarando 20 Mi. A próxima reconciliação do controlador, ou a próxima implantação, reverterá a correção e reintroduzirá o incidente, agora sem a memória do diagnóstico que o originou. O sintoma reaparece dias depois, aparentemente sem causa.

Modelo de gestão	Efeito do kubectl patch	Ação obrigatória de fechamento
Manifesto aplicado manualmente	Persiste até a próxima aplicação	Atualizar o manifesto no repositório
Helm	Revertido no próximo upgrade	Atualizar o values.yaml e versionar o chart
GitOps (Flux/Argo CD)	Revertido na próxima reconciliação	Abrir pull request na fonte da verdade
Pipeline de IaC	Revertido na próxima execução	Atualizar o template e o registro de mudança

Regra operacional

Toda mitigação aplicada diretamente ao cluster deve gerar um item de acompanhamento na fonte da verdade antes do encerramento do incidente. Um incidente cuja correção existe apenas no cluster não está resolvido: está agendado para reincidir.

10.9 Do acionamento sob demanda ao disparo por alerta

Até aqui, o agente foi acionado sob demanda. A etapa seguinte valida o caminho automatizado: um alerta do Azure Monitor configurado para disparar quando um pod apresentar terminação por OOMKilled.

Figura 34: Regra de alerta configurada no Azure Monitor para detectar terminações por OOMKilled no cluster.

Para provocar o evento de forma controlada, utiliza-se uma aplicação local que gera carga sobre o order-service até que o consumo ultrapasse o limite do cgroup.

Figura 35: Painel local de simulação, com o gatilho de geração de carga sobre o order-service e o acompanhamento de pods íntegros, terminações por OOMKilled e alertas disparados. Às 17h45, o pod entra em estado OOMKilled com código de saída 137.

Figura 36: Confirmação do estado por kubectl, evidenciando a terminação por OOMKilled.

Dois minutos após o evento, a notificação do alerta chega ao destinatário configurado no action group, intervalo que corresponde à soma da ingestão no Log Analytics, do período de avaliação da regra e da entrega da notificação.

Figura 37: Notificação recebida por e-mail às 17h47, referente à regra Alert-OOMKilled-Pods.

Figura 38: Detalhe da notificação, indicando a condição atendida: contagem de resultados maior que zero, com o valor alcançado igual a 1.

O disparo é então confirmado no portal do Azure, com a severidade e o tipo de sinal registrados.

Figura 39: Alerta registrado no portal do Azure com estado Fired.

Figura 40: Detalhes do alerta: severidade 1, Error, tipo de sinal Log Alerts V2 e horário de disparo consistente com o evento observado no cluster.

Com esse alerta emitido e o agente integrado ao Azure Monitor, o gatilho necessário para a automação completa está validado. A Parte 2 tratará da transição do acionamento assistido para o fluxo disparado automaticamente pelo alerta, incluindo planos de resposta, modos de execução por plano e a integração com o processo de gestão de incidentes.

10.10 Do restabelecimento ao dimensionamento correto

O laboratório encerra com o serviço estável, mas os valores aplicados são uma mitigação informada, não um dimensionamento validado. Fechar o ciclo exige um método, e esse método é independente do agente.

Estabelecer a linha de base: medir o working set em percentil 95 e 99 sobre uma janela que cubra o ciclo completo de carga do serviço, incluindo picos previsíveis.
Definir o request pelo consumo típico: o percentil 95 do working set em regime normal, valor que o agendador usará para reservar capacidade.
Definir o limit com folga sobre o pico: o percentil 99 acrescido de margem para transientes, tipicamente entre 25% e 50%, evitando folga excessiva que desperdiça capacidade do nó.
Alinhar o runtime: ajustar o heap máximo conforme a seção 3.5, reservando espaço para memória fora do heap.
Validar sob carga: reproduzir o cenário que originou o incidente e confirmar que o working set permanece abaixo do limite com margem estável.
Descartar vazamento: comparar a inclinação do consumo entre reinícios; crescimento sustentado sem correlação com a carga indica retenção progressiva, que nenhum aumento de limite resolve.
Automatizar a revisão: usar o Vertical Pod Autoscaler em modo recomendação para acompanhar a adequação dos valores ao longo do tempo, sem aplicação automática.

Nota. Elevar o limite de memória é uma resposta legítima quando a evidência aponta subdimensionamento, e ilegítima quando serve para adiar a investigação de um vazamento. A diferença entre as duas situações está na inclinação do consumo entre reinícios, um dado que só existe se a telemetria for retida além do ciclo de vida do contêiner.

11. Governança, aprovação e rastreabilidade

Esta seção separa deliberadamente dois planos: capacidades do produto, que podem ser verificadas na documentação, e recomendações de arquitetura, que cada organização deve validar e adaptar às próprias políticas.

Nota. Nomenclaturas, opções e comportamentos evoluem. Antes de aplicar este padrão em produção, valide a documentação vigente, os controles disponíveis no ambiente e os requisitos internos de segurança, auditoria e mudança.

11.1 O que foi observado no laboratório

O agente coletou métricas, eventos e o estado dos pods para investigar o incidente, com cada comando registrado na thread.
Identificou que os valores de memória estavam subdimensionados para a carga observada.
Propôs um comando kubectl patch explícito, exibindo a alteração de 20 Mi para 128 Mi no limite e de 10 Mi para 64 Mi na solicitação.
Apresentou a ação para revisão humana, classificada como Medium risk, e aguardou aprovação antes de executar.
Após a aprovação, executou a alteração e verificou a recuperação do pod antes de concluir.
Sinalizou espontaneamente o risco de reversão da correção em cenários gerenciados por GitOps ou Helm.

Esse comportamento reflete o cenário demonstrado e não estabelece regra universal para todas as ferramentas, comandos ou ambientes.

11.2 Referência de governança para a organização

A tabela a seguir é uma recomendação de desenho, não uma matriz fixa nem garantia de comportamento do produto.

Categoria	Exemplos	Política sugerida
Leitura	get, list, show, describe, consultas KQL	Permitir quando escopo e RBAC forem compatíveis com a investigação.
Escrita	patch, update, scale, restart	Exigir revisão humana em ambientes críticos por meio de Review Mode no plano de resposta ou de hooks.
Alto impacto	delete, redução de capacidade, mudanças destrutivas	Restringir por RBAC e por política de acesso a ferramentas; submeter a processo formal de mudança ou negar conforme o risco.

A classificação de risco deve ser definida pela organização conforme o ambiente, o tipo de recurso, a criticidade do serviço e os requisitos regulatórios. A documentação do produto não deve ser interpretada como regra universal de que toda leitura é sempre permitida, toda escrita sempre exige aprovação ou todo delete é sempre negado.

11.3 Camadas de evidência para auditoria

Nenhuma fonte isolada reconstrói o incidente por completo. A rastreabilidade útil vem da correlação entre camadas com escopos distintos.

Camada	O que registra	Limitação
Thread do agente	Comandos executados, evidências, proposta e aprovação	Escopo da conversa; confirmar retenção e exportação no ambiente
Telemetria de auditoria do agente	Atividade do agente para acompanhamento e conformidade	Confirmar granularidade e campos disponíveis no ambiente
Log de auditoria do Kubernetes	Chamadas ao servidor de API do cluster	Requer habilitação e destino de coleta configurados
Azure Activity Log	Operações do plano de controle do Azure	Não cobre alterações internas do Kubernetes
Sistema de ITSM	Registro formal de incidente e mudança	Depende da integração e da disciplina de preenchimento

Recomenda-se correlacionar, conforme disponibilidade: horário da proposta e da execução; a ação ou comando apresentado ao operador; o estado anterior e posterior do recurso; o resultado da ferramenta e mensagens de erro relevantes; os identificadores do agente, recurso, alerta, incidente e mudança; e as informações de aprovação expostas pelos mecanismos disponíveis.

11.4 Fluxo recomendado para este cenário

Etapa	Aplicação no laboratório	Controle recomendado
1. Diagnóstico e proposta	O agente consulta métricas, eventos e estado do cluster e apresenta a ação recomendada.	RBAC de menor privilégio, escopo por namespace e evidências observáveis.
2. Revisão humana	Em Review Mode, o operador analisa o comando, o impacto e o escopo antes da execução.	Critérios de aprovação e rollback definidos; aprovação restrita a administradores do agente.
3. Execução controlada	Após a aprovação, o agente executa a alteração dentro das permissões concedidas.	Identidade gerenciada, escopo mínimo, hooks de PostToolUse para auditoria.
4. Verificação	O agente valida a recuperação antes de concluir.	Critério de sucesso objetivo, baseado em estado observado e não em ausência de erro.
5. Reconciliação	Não aplicável ao laboratório; a alteração permaneceu no cluster.	Atualizar a fonte da verdade e vincular ao registro de mudança.
6. Registro	O resultado é apresentado na thread do agente.	Correlação entre telemetria, logs do cluster, registros do Azure e ITSM.

Enquadramento

Os modos de execução, os controles de acesso, os hooks e a telemetria são capacidades do produto. A matriz de risco, as evidências exigidas, as convenções de repositório e as integrações de auditoria são decisões de governança da organização. Manter essa separação explícita evita transformar recomendações de arquitetura em garantias de produto.

12. Considerações de segurança para operações agênticas

Introduzir um agente com capacidade de execução no caminho de resposta a incidentes altera o modelo de ameaças da plataforma. As considerações a seguir derivam diretamente da configuração demonstrada.

Consideração	Risco	Mitigação
Privilégio excessivo	Cluster Admin Role concede credencial que contorna o Entra ID e o RBAC do Kubernetes	Substituir por Cluster User + RBAC Reader/Writer com escopo por namespace; elevar sob demanda
Escopo amplo demais	Funções no grupo de recursos alcançam recursos não relacionados ao incidente	Escopar no recurso, não no grupo de recursos
Segregação de funções	Quem opera aprova a própria ação	Restringir aprovação a administradores do agente distintos de quem aciona a investigação
Conteúdo não confiável no contexto	Logs e eventos podem carregar texto capaz de influenciar o raciocínio do agente	Hooks de PostToolUse e políticas de acesso a ferramentas; revisão humana para ações de escrita
Raio de impacto	Uma ação incorreta atinge o cluster inteiro	Escopo por namespace, janelas de mudança e critérios de rollback definidos previamente
Residência de dados	O provedor de modelo determina onde o contexto é processado	Selecionar o provedor conforme os requisitos regulatórios e as regiões suportadas
Exposição em capturas e threads	Identificadores e segredos aparecem em evidências compartilhadas	Revisar artefatos antes de circular; suprimir identificadores, como feito neste documento

O item sobre conteúdo não confiável merece atenção particular. Durante a investigação, o agente lê logs e eventos produzidos pela aplicação, dados que, em última instância, podem ser influenciados por entradas de usuários. Tratar esse conteúdo como dado, e não como instrução, é responsabilidade compartilhada entre o produto e o desenho de governança: manter operações de escrita sob revisão humana em ambientes críticos é a defesa mais direta contra essa classe de risco.

Princípio de composição

Nenhum controle isolado é suficiente. A defesa em profundidade nesse modelo compõe quatro camadas independentes: RBAC delimita o que a identidade alcança; os modos de execução determinam se há aprovação humana; a classificação de risco por chamada de ferramenta informa a decisão do revisor; e os hooks aplicam política e auditoria antes e depois de cada ação. Remover qualquer uma delas transfere risco às demais.

13. Métricas para avaliar a adoção

A adoção de resposta assistida deve ser avaliada por evidência, não por percepção. As métricas a seguir permitem comparar o antes e o depois de forma objetiva.

Métrica	O que mede	Sinal de maturidade
MTTD	Tempo entre o evento e a detecção	Estável; limitado pela latência de ingestão e avaliação
MTTA	Tempo entre o alerta e o início da investigação	Redução acentuada com investigação automática
MTTR	Tempo entre o alerta e a recuperação verificada	Redução sustentada, sem aumento de reincidência
Taxa de aprovação sem alteração	Recomendações aprovadas sem ajuste pelo operador	Crescente; habilita migração seletiva para modo autônomo
Taxa de reincidência em 30 dias	Incidentes da mesma classe que retornam	Decrescente; indica correção estrutural e não apenas mitigação
Aderência à reconciliação	Mitigações refletidas na fonte da verdade	Próxima de 100%; principal defesa contra reincidência
Ações autônomas por classe de risco	Distribuição entre leitura, escrita e alto impacto	Crescimento apenas nas classes com histórico consistente

A recomendação de adoção é conservadora e apoiada na própria documentação do produto: iniciar em Review Mode, observar as recomendações por algumas semanas e migrar para modo autônomo apenas os gatilhos cujo padrão de aprovação já se mostrou consistente. A taxa de aprovação sem alteração é o indicador que sustenta essa decisão com dados.

14. Limitações e armadilhas observadas

A mitigação foi aplicada diretamente ao cluster. Em ambientes gerenciados por GitOps, Helm ou IaC, a correção será revertida se a fonte da verdade não for atualizada.
Os valores de 128 Mi e 64 Mi restabeleceram o serviço, mas constituem mitigação informada, não dimensionamento validado por testes de carga.
As permissões concedidas no laboratório são amplas por conveniência de demonstração e contornam a integração com o Entra ID no plano de dados do cluster.
Alertas baseados em log carregam latência de ingestão e de avaliação, dois minutos no laboratório, o que os torna inadequados para SLOs de detecção mais agressivos.
Um restart bem-sucedido mascara a distinção entre limite subdimensionado e vazamento de memória; sem telemetria retida além do ciclo do contêiner, a diferença se perde.
O modelo pode propor valores plausíveis, mas a validação por métricas e carga permanece responsabilidade da engenharia.
O cenário cobre uma única classe de falha em um único workload; a generalização para outras classes exige validação própria.

15. Conclusão da Parte 1

O Azure Monitor e o Azure SRE Agent transformaram um evento OOMKilled em um fluxo governado de detecção, investigação, recomendação, aprovação e recuperação verificada. O resultado demonstra valor não apenas por restabelecer o pod, mas por correlacionar evidências, manter a decisão explicável e executar a remediação dentro dos limites de acesso definidos.

Três observações se destacam do exercício. A primeira é que a transparência por chamada de ferramenta, com o comando literal e sua classificação de risco, transforma a revisão humana em auditoria rápida em vez de repetição do trabalho. A segunda é que o agente verificou a recuperação antes de concluir, distinguindo execução bem-sucedida de serviço restabelecido. A terceira é que ele sinalizou o risco de reversão por GitOps, armadilha que mais frequentemente converte uma correção em incidente recorrente.

A conclusão arquitetural permanece: a observabilidade continua sendo a base. O agente amplifica o valor de uma telemetria bem construída, e amplifica igualmente as lacunas de uma telemetria pobre. Investir em sinais corretos, como working set em vez de uso bruto, agregação por máximo em vez de média e retenção além do ciclo de vida do contêiner, é pré-requisito, não consequência.

Na Parte 2, o fluxo evoluirá do acionamento assistido para o disparo automatizado por alertas, com planos de resposta, definição de modos de execução por plano, hooks de auditoria e integração com o processo de gestão de incidentes.

16. Referências

Azure SRE Agent

Azure Monitor e observabilidade de contêineres

Kubernetes e AKS

Multithreading, GIL e paralelismo no Python

ClaudioGodoy — Tue, 04 Aug 2026 13:36:33 GMT

Concorrência vs. paralelismo

Os dois conceitos são parecidos, mas não são a mesma coisa:

Concorrência: lidar com várias tarefas ao mesmo tempo, alternando entre elas. As tarefas progridem de forma intercalada, mas não necessariamente executam no mesmo instante. É ideal para trabalho I/O-bound (rede, disco, banco de dados), onde o programa passa a maior parte do tempo esperando.
Paralelismo: executar várias tarefas literalmente ao mesmo tempo, em múltiplos núcleos de CPU. É o que acelera trabalho CPU-bound (cálculo pesado, compressão, hashing).

Resumindo: todo paralelismo é concorrência, mas nem toda concorrência é paralelismo.

Para concorrência de I/O sem threads, o Python oferece o asyncio, baseado em uma única thread com um event loop e a sintaxe async/await. Como ele não cria threads nem processos, é leve e eficiente para milhares de conexões simultâneas — mas não oferece paralelismo de CPU.

Threads e o GIL: por que multithreading não paraleliza CPU

O módulo threading permite criar threads reais do sistema operacional, mas o CPython usa o GIL (Global Interpreter Lock): uma trava global que garante que apenas uma thread execute bytecode Python por vez.

Por que ele existe? O GIL simplifica o interpretador e torna o modelo de objetos (incluindo tipos como dict) implicitamente seguro contra acesso concorrente, além de facilitar a integração com bibliotecas C. O preço é abrir mão de boa parte do paralelismo em máquinas multi-core.

Na prática:

Tarefas I/O-bound se beneficiam de threads, pois o GIL é liberado durante operações de I/O (e por extensões como hashlib/zlib em trechos pesados).
Tarefas CPU-bound não escalam com threads: o GIL serializa a execução, e usar mais threads não deixa o programa mais rápido — às vezes até o deixa mais lento pelo overhead de troca de contexto.

Desde o Python 3.13 existe um build experimental free-threaded (compilado com --disable-gil, descrito na PEP 703) que permite desligar o GIL. Porém isso exige um interpretador compilado especificamente para isso (python3.14t); as compilações padrão não permitem desabilitá-lo.

O GIL não dispensa sincronização

Mesmo com o GIL, ainda precisamos nos preocupar com sincronização. O GIL garante que uma instrução de bytecode não seja interrompida no meio, mas operações de alto nível (como contador += 1) envolvem várias instruções de bytecode e podem sofrer race conditions se uma thread for interrompida no meio delas.

Por isso o módulo threading oferece primitivos de sincronização — todos usáveis com with para liberação automática:

Lock / RLock — exclusão mútua.
Semaphore — limita o número de acessos simultâneos.
Condition / Event — coordenação entre threads.

Multiprocessing: paralelismo real com processos

A saída para aplicações CPU-bound é o módulo multiprocessing (ou o ProcessPoolExecutor do concurrent.futures). Em vez de threads, ele cria processos separados, e cada processo tem seu próprio interpretador e seu próprio GIL, permitindo paralelismo real em múltiplos núcleos.

O custo intrínseco é que criar um novo processo cria também um interpretador Python inteiro, o que é pesado em memória e no tempo de inicialização. Além disso, processos não compartilham memória: os dados precisam ser serializados (via pickle) e trocados por mecanismos de comunicação entre processos como Queue e Pipe, ou por memória compartilhada. Isso torna a sincronização mais complexa e adiciona overhead de comunicação.

Benchmark: medindo o impacto do GIL

Para comprovar o conceito, um pequeno script calcula muitos hashes SHA-256 encadeados (uma tarefa puramente CPU-bound) e distribui esse trabalho de três formas, usando concurrent.futures:

Sequencial — executa tudo em uma única thread, servindo de baseline.
ThreadPoolExecutor — divide o trabalho entre várias threads.
ProcessPoolExecutor — divide o trabalho entre vários processos.

Cada abordagem é medida em tempo de execução e memória consumida. Rodando no Python 3.14.6 (16 núcleos), o resultado foi:

Abordagem               Tempo  Speedup      Memória
------------------------------------------------------------
Sequencial              0.79s    1.00x       0.0 MB
ThreadPoolExecutor      0.80s    0.99x       0.2 MB
ProcessPoolExecutor     0.31s    2.56x     148.6 MB

Interpretando os números:

As threads não aceleraram a tarefa (speedup ~1.0x, praticamente igual ao sequencial). O GIL serializou a execução do bytecode: mesmo com várias threads, apenas uma roda por vez, então não há ganho de paralelismo para trabalho de CPU.
Os processos foram ~2.5x mais rápidos. Como cada processo tem seu próprio interpretador e seu próprio GIL, o trabalho realmente rodou em paralelo em vários núcleos.
Esse paralelismo cobra um custo de memória: os 8 processos consumiram ~148 MB (~18,6 MB por interpretador novo), contra apenas ~0,2 MB das threads, que compartilham o mesmo processo. É o trade-off central entre threading e multiprocessing: velocidade real de CPU ao preço de duplicar o interpretador em memória.

Conclusão: I/O-bound ou CPU-bound?

O GIL é a razão pela qual multithreading no CPython não entrega paralelismo de CPU. A regra prática é:

I/O-bound → use threading ou asyncio (o GIL é liberado durante a espera).
CPU-bound → use multiprocessing, aceitando o custo de memória e de comunicação entre processos.
No futuro, o build free-threaded (PEP 703) promete paralelismo real com threads e sem o custo de vários interpretadores — mas ainda depende de um interpretador compilado sem o GIL.

Escolher a ferramenta certa depende, antes de tudo, de entender se o gargalo é de I/O ou de CPU.

Alocação de memória - .NET

ClaudioGodoy — Wed, 22 Jul 2026 13:51:44 GMT

Alocação de memória - .NET

Há pouco tempo, memória RAM era um recurso escasso e os engenheiros de software precisavam dominar a utilização de recursos de seus programas. Caso contrário, provavelmente a aplicação não funcionaria apropriadamente.

Atualmente, o cenário mudou: memória RAM é um recurso abundante. Entretanto, para aplicações críticas que processam volumes massivos de dados, o gerenciamento eficiente de memória nunca deixou de ser crucial, principalmente em sistemas distribuídos baseados em nuvem.

Neste artigo, explorarei de forma prática aspectos importantes sobre gerenciamento de memória em aplicações .NET.

Sistemas de tipos

No .NET todos os tipos são classificados de duas formas:

Tipos de valor: Em inglês Value Type são alocados na própria Thread Stack. Também podem ser alocados em campos de valores de referência.
Tipos de referência: Em inglês Reference Type são alocados na Heap Gerenciada. O operator new retorna um endereço de memória do objeto.

Por definição, toda Classe é um tipo de referência. Variáveis são como ponteiros, que dão ligação entre a Thread Stack e a Heap Gerenciada.

Exemplo prático

// Value Type - struct
struct Coordenada { public int X; }

// Reference Type - class  
class Ponto { public int X; }

// VALUE TYPE: Cria cópia independente
Coordenada c1 = new Coordenada { X = 10 };
Coordenada c2 = c1;
c2.X = 100;
Console.WriteLine(c1.X); // 10 (não mudou)

// REFERENCE TYPE: Compartilha a mesma instância
Ponto p1 = new Ponto { X = 10 };
Ponto p2 = p1;
p2.X = 100;
Console.WriteLine(p1.X); // 100 (mudou!)

Thread Stack

Computadores executam instruções de forma sequencial, seguindo o fluxo de chamadas de métodos. Para gerenciar essa execução, cada thread mantém sua própria stack (pilha), seguindo o método LIFO (Last In, First Out).

Quando um método é invocado, o runtime cria um stack frame (quadro de pilha) contendo todas as variáveis locais e parâmetros daquele método. Esse frame é empilhado no topo da stack.

A alocação de objetos na stack segue uma regra simples: tipos de valor (structs, primitivos) são armazenados diretamente no stack frame com seu valor completo. Já tipos de referência (classes) "escapam" para a heap gerenciada, o stack frame armazena apenas um ponteiro (referência) de 8 bytes (em sistemas 64-bit) que aponta para o objeto real na heap. Isso permite que objetos de tamanho dinâmico existam além do tempo de vida do método que os criou, enquanto a stack mantém acesso rápido através das referências.

Exemplo: Alocação de Value Types na Stack

Vamos observar como a stack gerencia as chamadas de métodos e suas variáveis locais:

using System;

class Program
{
    static void Main()
    {
        int a = 10;
        int b = 20;
        int resultado = Somar(a, b);
    }

    static int Somar(int x, int y)
    {
        int soma = x + y;
        return soma;
    }
}

Pontos importantes:

Cada método cria seu próprio stack frame com todas as variáveis locais e parâmetros
Todas as variáveis (a, b, resultado, x, y, soma) são Value Types (int/Int32)
Valores são copiados ao passar parâmetros (Somar recebe cópias de a e b)
Ao término de Somar, seu frame é automaticamente removido (desempilhado)
Não há uso da heap gerenciada neste exemplo, tudo permanece na stack

Heap gerenciada e GC

Enquanto a Thread Stack gerencia a execução e variáveis locais de forma automática e determinística, a heap gerenciada é responsável por armazenar objetos de tipos de referência que precisam existir além do escopo de um único método. A heap é composta por dois componentes principais: o allocator (alocador) e o collector (coletor).

O allocator é chamado sempre que criamos um objeto com new (tipos de referência). Ele divide os objetos em duas categorias baseadas no tamanho: objetos pequenos (< 85.000 bytes) que são alocados na Small Object Heap (SOH), e objetos grandes (≥ 85.000 bytes) que vão para a Large Object Heap (LOH). Para otimizar performance, o allocator trabalha com allocation contexts (contextos de alocação), pequenas regiões de memória dedicadas a cada thread, evitando a necessidade de locks em cada alocação. Quando o orçamento de alocação (allocation budget) é excedido ou não há mais espaço disponível, o allocator aciona o coletor.

Atualmente threshold do LOH pode ser alterado nas configurações do runtime.

O Garbage Collector (GC) é um coletor geracional que organiza objetos em gerações baseadas em sua idade: Gen0 (objetos recém-criados), Gen1 (objetos que sobreviveram a uma coleta) e Gen2 (objetos de longa duração). Essa divisão geracional se baseia na hipótese de que a maioria dos objetos tem vida curta. O GC coleta gerações mais jovens com maior frequência (mais barato) e Gen2 com menor frequência (mais caro). Objetos grandes na LOH formam a Gen3 e são sempre coletados junto com Gen2 devido ao alto custo de compactação.

A conexão entre stack e heap é simples: quando um método cria um objeto de tipo de referência (new Ponto()), o allocator reserva espaço na heap gerenciada e retorna o endereço de memória. Esse endereço (ponteiro/referência de 8 bytes em sistemas 64-bit) é armazenado no stack frame do método. Assim, a stack mantém as referências enquanto os objetos reais vivem na heap, permitindo que múltiplas referências na stack apontem para o mesmo objeto na heap e que objetos sobrevivam além do tempo de vida do método que os criou.

Conclusão

O gerenciamento de memória em .NET equilibra eficiência e simplicidade através de dois mecanismos complementares: a stack oferece alocação ultrarrápida e determinística para tipos de valor e referências locais, enquanto a heap gerenciada com seu Garbage Collector cuida automaticamente de objetos de vida longa. Compreender a distinção entre Value Types e Reference Types, e como a stack e heap trabalham juntas, é fundamental para escrever aplicações performáticas. O sistema geracional do GC otimiza coletas baseando-se na observação de que a maioria dos objetos tem vida curta, tornando o gerenciamento de memória eficiente sem exigir intervenção manual do desenvolvedor na maioria dos cenários.

Referências

GitHub Copilot Dev Days Online

cynthiazanoni — Thu, 14 May 2026 13:38:38 GMT

After a series of in-person events, GitHub Copilot Dev Days is now going online, bringing developers from around the world together to explore modern AI-assisted software development in practice.

Through live sessions focused on agentic development, modern workflows, and hands-on learning in VS Code, attendees will learn how to use GitHub Copilot beyond autocomplete and apply it across real development scenarios.

Register for the session that fits your language and community

GitHub Copilot Dev Days LATAM [Spanish] - May 26

A hands-on session for Spanish-speaking developers across Latin America focused on building modern applications with GitHub Copilot, TypeScript, React, and Tailwind.

Attendees will explore agentic workflows, context engineering, and practical ways to use GitHub Copilot as an active development partner in VS Code.

Date: May 26, 2026, 12 PM (Mexico City / CDMX)
Register: GitHub Copilot Dev Days LATAM | Microsoft Reactor

GitHub Copilot Dev Days Brazil [Portuguese] - May 25

This edition focuses on AI-assisted development with Python, FastAPI, and HTMX using GitHub Copilot throughout the development workflow.

The session covers practical workflows for code generation, refactoring, debugging, and day-to-day development with GitHub Copilot in VS Code.

Date: May 25, 2026, 7 PM (Brasilia Time)
Register: GitHub Copilot Dev Days Brasil | Microsoft Reactor

GitHub Copilot Dev Days 中文版 [Simplified Chinese] - May 26

This session explores how GitHub Copilot and GitHub Actions can work together to create intelligent and automated development workflows.

Topics include ChatOps, automated summaries, syncing content into GitHub Issues, and agentic workflows designed to improve collaboration and engineering efficiency.

Date: May 26, 2026, 7:30 PM (China Standard Time - CST)
Register: GitHub Copilot Dev Days - 中文版 | Microsoft Reactor

GitHub Copilot Dev Days [English] - May 27

An English-language workshop for developers who want to learn how to build modern applications with GitHub Copilot in VS Code.

The session focuses on TypeScript, React, Tailwind, and Agent Mode workflows, showing how better context and prompting can improve AI-assisted development.

Date: May 27, 2026, 9 AM (PST)
Register: GitHub Copilot Dev Days | Microsoft Reactor

All sessions are hosted through Microsoft Reactor. Check the registration pages for local times and additional event details.

APIM Circuit Breaker com Azure OpenAI

wdossantos — Fri, 22 May 2026 17:32:11 GMT

APIM Circuit Breaker com Azure OpenAI

Visão Geral

Ao consumir modelos do Azure OpenAI em produção, depender de um único endpoint representa um risco real. Basta uma instância ficar indisponível ou atingir limites de throttling para que toda a aplicação seja impactada.

Neste artigo, construímos uma arquitetura resiliente utilizando o Azure API Management (APIM) como camada de proteção entre o cliente e os serviços de IA.

O ponto de partida são dois backends do Azure OpenAI (oiaws01 e oiaws02), ambos configurados com Managed Identity. A partir deles, criamos um Load Balancer Pool no APIM, distribuindo o tráfego em um modelo 50/50 entre os dois endpoints.

Em seguida, habilitamos o Circuit Breaker, que detecta falhas consecutivas e "abre o circuito", impedindo que novas requisições sejam enviadas a um backend com problemas. Nesse estado, o APIM passa a responder com 503 – Service Unavailable, incluindo o header Retry-After, até que o backend se recupere.

O ponto mais crítico está na configuração das políticas XML. Posicionar o set-backend-service dentro do bloco <retry> garante que cada tentativa seja roteada novamente pelo Load Balancer, evitando que as retentativas atinjam sempre o mesmo backend com falha.

Todo o fluxo foi validado usando o Trace do APIM, onde é possível acompanhar, passo a passo:

Seleção do backend no pool
Autenticação via Managed Identity
Fallback para o segundo endpoint
Resposta final ao cliente

Por fim, exploramos a camada de observabilidade. Os eventos de abertura do Circuit Breaker são capturados e enviados para uma Storage Queue, de onde um Logic App os exporta via HTTP POST para o Elastic Observability, permitindo monitoramento em tempo real de quando e por que os circuitos são abertos.

Diagrama

Diagrama do fluxo da Requisição http, Load balancer falhas e Circuit Break

1. Criando os Backends para Azure OpenAI

O primeiro passo é registrar no APIM os endpoints que representam as instâncias do Azure OpenAI. Neste cenário, criamos dois backends apontando para:

https://oiaws01.openai.azure.com/openai
https://oiaws02.openai.azure.com/openai

Cada backend funciona como uma abstração dentro do APIM — ele encapsula a URL, as credenciais e as configurações de resiliência (como o Circuit Breaker) em um único recurso reutilizável.

Dois backends registrados no APIM: openapi01-openai-endpoint e openapi02-openai-endpoint, apontando para os respectivos endpoints do Azure OpenAI.

Configuração de Managed Identity

Para que o APIM consiga se autenticar nos backends sem expor chaves de API, configuramos Managed Identity. O Azure API Management pode apresentar credenciais ao backend utilizando cabeçalhos de autorização, parâmetros de consulta ou certificados de cliente — mas a abordagem mais segura e moderna é usar a identidade gerenciada.

Com essa configuração, o APIM solicita um token OAuth ao Azure AD usando sua própria identidade (System Assigned), e o apresenta ao backend como um Bearer token. Não há segredos para rotacionar, não há chaves para vazar.

Backend openia02-openai-endpoint configurado com Managed Identity (System Assigned) apontando para https://cognitiveservices.azure.com/.

Em alguns cenários — especialmente quando a configuração via portal não é suficiente ou quando precisamos de controle granular — é necessário configurar a autenticação diretamente nas políticas XML do APIM:

<authentication-managed-identity resource="https://cognitiveservices.azure.com" output-token-variable-name="msi-access-token" />  <set-header name="Authorization" exists-action="override"> <value>@("Bearer " + (string)context.Variables["msi-access-token"])</value> </set-header>

Essa abordagem é útil quando você precisa reutilizar o token em múltiplas policies ou quando o backend exige um formato específico de apresentação das credenciais.

Teste Básico

Com os backends e a autenticação configurados, o próximo passo é validar que tudo funciona. Um teste simples direto no console do APIM confirma a conectividade:

Parâmetros:

deployment-id: o1 api-version: 2025-01-01-preview

Request body:

{ "messages": [ { "role": "user", "content": "I am going to Paris, what should I see?" } ], "max_completion_tokens": 40000, "model": "o1" }Teste no console do APIM confirmando resposta 200 OK do Azure OpenAI (modelo o1) via Managed Identity.

2. Criando o Load Balancer (LB)

Ter dois backends funcionando individualmente é um bom começo, mas não garante resiliência por si só. Se a API estiver apontada para um backend fixo e ele cair, o serviço para. É aqui que entra o Load Balancer Pool.

O Load Balancer Pool é um recurso do APIM que agrupa múltiplos backends e distribui o tráfego entre eles segundo regras configuráveis. Em vez de apontar a política set-backend-service para um backend individual, apontamos para o pool — e o APIM se encarrega de escolher para qual instância enviar cada requisição.

Criação do Load Balancer Pool

Criamos um pool chamado LB01 contendo os dois backends OpenAI. A distribuição foi configurada como 50/50 com pesos customizados, o que significa que cada backend recebe metade do tráfego em condições normais.

Benefícios imediatos:

Distribuição de carga — nenhum backend recebe 100% das requisições
Alta disponibilidade — se um backend falhar, o outro absorve o tráfego (quando combinado com retry)
Flexibilidade — pesos e prioridades podem ser ajustados sem alterar código

Criação do Load Balancer Pool com os dois backends OpenAI, peso 50/50 e prioridades customizadas.

Com o pool criado, qualquer política que referencia backend-id="LB01" passa automaticamente a ter balanceamento de carga. Mas distribuir tráfego não é suficiente — precisamos também detectar e isolar falhas. É o que o Circuit Breaker faz.

3. Entendendo e Configurando o Circuit Breaker

O que é o Circuit Breaker?

O Circuit Breaker é um padrão de resiliência para sistemas distribuídos, inspirado nos disjuntores elétricos. Assim como um disjuntor corta a energia quando detecta uma sobrecarga para proteger o circuito, o Circuit Breaker em software interrompe temporariamente as chamadas a um serviço que está falhando, evitando que falhas em cascata derrubem toda a aplicação.

Sem Circuit Breaker, quando um backend começa a falhar, o sistema continua enviando requisições para ele — consumindo recursos, aumentando latência e potencialmente causando timeout em cadeia. Com o Circuit Breaker, o sistema "aprende" que aquele backend está com problemas e para de enviar tráfego até que ele se recupere.

Os Três Estados do Circuit Breaker

O Circuit Breaker opera em três estados bem definidos:

Estado	Comportamento	Analogia
Closed (Fechado)	Tráfego flui normalmente para o backend. Falhas são contadas silenciosamente.	Disjuntor ligado — energia passa.
Open (Aberto)	Todas as requisições são imediatamente rejeitadas com 503 Service Unavailable + header Retry-After. Nenhuma chamada chega ao backend.	Disjuntor desligado — energia cortada para proteger o circuito.
Half-Open (Meio-aberto)	Após o trip duration expirar, o circuito permite uma requisição de teste. Se ela for bem-sucedida, volta para Closed. Se falhar, volta para Open.

A transição entre os estados segue este fluxo:

Por que isso importa para Azure OpenAI?

No contexto de IA generativa, uma chamada ao Azure OpenAI pode levar vários segundos. Se o backend está retornando erros (429 throttling, 500 internal error, 404 modelo não encontrado), cada tentativa desperdiça tempo precioso. O Circuit Breaker garante fail-fast: em vez de esperar 30 segundos por um timeout, o cliente recebe imediatamente um 503 com a informação de quando pode tentar novamente.

Configuração no APIM

Configuração do Circuit Breaker: 1 falha dispara abertura, status codes 400–599, trip duration de 1 minuto e Retry-After habilitado.

Os parâmetros configurados foram:

Parâmetro	Valor	Significado
Rule name	rulecb	Identificador da regra
Failure count	1	Basta 1 falha para abrir o circuito (agressivo, ideal para testes)
Failure interval	1 hora	Janela de tempo para contagem de falhas
Failure status code range	400-599	Qualquer resposta 4xx ou 5xx conta como falha
Failure error reason	BackendConnectionFailure	Tipo de erro que dispara o Circuit Breaker
Trip duration	1 minuto	Tempo que o circuito permanece aberto antes de tentar Half-Open
Check Retry-After header	True (Accept)	Respeita o header Retry-After do backend

Nota sobre o Failure Count: Em produção, um valor de 1 é muito agressivo — uma única falha transitória abriria o circuito. Valores entre 3 e 5 são mais comuns. Para este artigo, usamos 1 para facilitar a demonstração.

Comportamento Observado

Após falhas consecutivas, o APIM retorna 503 – Service Unavailable

O Circuit Breaker aparece como aberto no portal do Azure

O header Retry-After é incluído na resposta

4. Configurando as Políticas para usar o LB

Com backends, Load Balancer e Circuit Breaker configurados, o último passo é garantir que as políticas XML do APIM conectem tudo corretamente. Aqui estão os pontos que fazem toda a diferença entre uma configuração que funciona e uma que parece funcionar.

Ponto Importante #1 — Apontar para o Pool, não para o Backend

A política set-backend-service deve referenciar o Load Balancer Pool, e não um backend individual:

<set-backend-service id="apim-generated-policy" backend-id="LB01" />

Se você apontar diretamente para openapi01-openai-endpoint, perde todo o benefício do balanceamento e do failover automático.

Ponto Importante #2 — Buffer do Request Body

A política de retry deve usar forward-request com buffer-request-body="true". Sem isso, o body da requisição é consumido na primeira tentativa e não está disponível para retentativas:

Ponto Importante #3 — Retry balanceado pelo LB

Este é o ponto mais crítico e o que diferencia uma configuração robusta de uma ingênua. Se o set-backend-service estiver fora do bloco <retry>, o backend é selecionado uma única vez — e todas as retentativas vão para o mesmo endpoint. Se esse endpoint está falhando, todas as retentativas falham também.

A solução é colocar o set-backend-service dentro do <retry>:

Com essa configuração, a cada tentativa o Load Balancer é consultado novamente e pode rotear para um backend diferente. O resultado prático: se oiaws02 falha, a retentativa vai para oiaws01 automaticamente.

Explicação dos Elementos

Elemento	Descrição
<retry>	Define lógica de repetição (retry) para chamadas a serviços de backend
condition="@(context.Response.StatusCode == 404)"	Condição para acionar a repetição: resposta HTTP 404 (Not Found)
count="2"	Número máximo de tentativas adicionais (além da original)
interval="1"	Intervalo de 1 segundo entre as tentativas
first-fast-retry="true"	A primeira repetição é imediata, sem aguardar o intervalo
<forward-request />	Envia a requisição ao serviço de backend

5. Trace — Validação do Fluxo

onfiguração feita, é hora de validar. O Trace do APIM permite acompanhar passo a passo o que acontece com cada requisição — desde a entrada até a resposta final ao cliente. É a ferramenta definitiva para confirmar que o Load Balancer, o Circuit Breaker e o retry estão funcionando em conjunto.

No cenário de teste, o backend oiaws02 não possui o modelo o1 deployado, então retorna 404. O Trace mostra exatamente como o APIM lida com isso:

Backend selecionado no pool:

Backend '(, https://oiaws02.openai.azure.com/openai)' was selected in Backend pool 'LB01'.

Autenticação via Managed Identity:

Managed identity token is added to Authorization header.

Primeira tentativa — falha (oiaws02 não possui o modelo o1):

Request sent to https://oiaws02.openai.azure.com/openai/deployments/o1/chat/completions → Response: 404 Not Found

Retry com novo backend selecionado pelo LB:

Backend service URL was changed. oldBackendServiceUrl: https://oiaws02.openai.azure.com/openai newBackendServiceUrl: https://oiaws01.openai.azure.com/openai

Segunda tentativa — sucesso:

Request sent to https://oiaws01.openai.azure.com/openai/deployments/o1/chat/completions → Response: 200 OK

Resposta final ao cliente:

Response has been sent to the caller in full

O cliente recebeu a resposta com sucesso, sem saber que houve uma falha nos bastidores. Isso é resiliência transparente.

6. Events — Monitoramento do Circuit Breaker

Ter resiliência é essencial, mas saber quando ela está sendo acionada é igualmente importante. Se o Circuit Breaker está abrindo com frequência, pode indicar um problema que precisa de atenção — um backend degradado, um modelo removido, ou limites de throttling sendo atingidos repetidamente.

Captura de Eventos via Storage Queue

O APIM foi configurado para capturar eventos de abertura do Circuit Breaker e enviá-los para uma Storage Queue. Cada vez que um circuito abre, um evento é publicado com todos os detalhes relevantes.

Observação: Após essa configuração, a abertura do Circuit Breaker pode não aparecer mais no Trace, embora continue sendo registrada na fila.

Criação da Event Subscription no Event Grid com os tipos "Circuit Breaker Opened" e "Circuit Breaker Closed" selecionados para capturar eventos de abertura e fechamento do circuito.

Painel de Events do APIM mostrando 20 eventos publicados e entregues com sucesso à Storage Queue via subscription cbapim (Circuit Breaker Opened/Closed).

Exemplo de Evento

{ "id": "e5da5756-61b9-42cf-8097-f8a684f1b74c", "topic": "/subscriptions/.../resourceGroups/apimappgw/providers/Microsoft.ApiManagement/service/apimappgwws01", "subject": "/backends/openapi01-openai-endpoint/circuit-breaker/rules/cb01", "data": { "backendName": "openapi01-openai-endpoint", "circuitBreaker": { "rules": { "cb01": { "tripDuration": "00:00:15" } } } }, "eventType": "Microsoft.ApiManagement.CircuitBreaker.Opened", "dataVersion": "1.0", "metadataVersion": "1", "eventTime": "2025-08-14T15:41:30.948673Z" }

O evento nos diz exatamente: qual backend foi isolado (openapi01-openai-endpoint), qual regra foi violada (cb01), e por quanto tempo o circuito ficará aberto (15 segundos).

7. Export Events com Logic Apps → Elastic Observability

A Storage Queue resolve o problema de captura, mas para monitoramento em tempo real e dashboards operacionais, precisamos levar esses dados para uma plataforma de observabilidade. Neste caso, utilizamos o Elastic Observability.

Fluxo de Integração

O pipeline completo funciona assim:

Circuit Breaker abre → evento é publicado na Storage Queue
Logic App é acionado pelo trigger da fila
Logic App recupera a API Key no Key Vault (via Managed Identity — sem segredos hardcoded)
Logic App envia os dados via HTTP POST para o Elastic Observability

Exemplo de Chamada HTTP

POST https://apim-a5eaba.es.eastus.azure.elastic.cloud/apim/_doc Content-Type: application/json Authorization: ApiKey ...

Body: JSON do evento do Circuit Breaker.

Configuração no Elastic

Para receber e visualizar os eventos, é necessário:

Criar um índice (apim) para armazenar os documentos
Criar uma API Key com permissão de escrita no índice
Obter a URL do projeto Elastic Cloud
Criar uma View/Dashboard para visualizar os eventos de abertura do Circuit Breaker

Com esse pipeline completo, a equipe de operações consegue responder rapidamente a perguntas como: "Quantas vezes o circuito abriu nas últimas 24 horas?", "Qual backend está mais instável?", "Os problemas coincidem com horários de pico?".

8. Troubleshooting — Event Grid em VNet com Forced Tunneling

Toda a configuração de eventos descrita na seção 6 funciona perfeitamente em ambientes com conectividade direta à internet. Porém, ao replicar essa arquitetura em um ambiente corporativo com APIM em VNet (internal mode) e forced tunneling, os eventos do Circuit Breaker simplesmente não chegam à Storage Queue.

O Problema

O cenário é o seguinte:

APIM está deployado em uma subnet com uma Route Table (UDR) configurada com rota default 0.0.0.0/0 → Virtual Appliance (firewall corporativo)
O Event Grid System Topic está criado e a Event Subscription configurada corretamente
No portal, o painel de Events não mostra nenhum evento publicado — mesmo com o Circuit Breaker abrindo e fechando normalmente

A princípio, parece um problema de configuração do Event Grid. Mas a causa está na camada de rede.

Root Cause — Rota AzureEventGrid ausente

Quando o APIM publica um evento de Circuit Breaker, ele precisa alcançar o Azure Event Grid via HTTPS (porta 443). Em ambientes com forced tunneling, todo o tráfego que não tem uma rota explícita é capturado pela rota default e enviado ao firewall/NVA.

A maioria das documentações de APIM em VNet orienta a criação de rotas com service tags para as dependências conhecidas:

Service Tag	Uso
Storage	Core dependency
SQL	Core dependency
AzureKeyVault	Core dependency
AzureMonitor	Diagnostics & metrics
EventHub	Log to Event Hubs policy

Porém, AzureEventGrid não está listado na documentação oficial como dependência obrigatória — porque só é necessário quando você utiliza o recurso de Events/System Topics do APIM. Se a rota não existe, o tráfego é engolido pelo firewall e os eventos nunca são entregues.

A Solução

Adicionar uma rota na Route Table da subnet do APIM:

Propriedade	Valor
Nome da rota	route-eventgrid-internet
Destination type	Service Tag
Service tag	AzureEventGrid
Next hop type	Internet

Após aplicar a rota, os eventos começam a ser entregues imediatamente — sem necessidade de reiniciar o APIM ou recriar o System Topic.

Como Diagnosticar

Se você está enfrentando o mesmo problema, valide:

Route Table — Verifique se existe uma rota com service tag AzureEventGrid e next hop Internet
NSG — Confirme que a regra AllowInternetOutBound (ou equivalente) não está bloqueando tráfego de saída na porta 443
Event Grid → Metrics — No System Topic, verifique as métricas Published Events e Delivery Succeeded. Se ambas estão zeradas, o problema é de publicação (rede), não de entrega
Network Status — No APIM, vá em Deployment + Infrastructure → Network → Network Status. O Event Grid pode não aparecer como dependência explícita, mas falhas genéricas de conectividade podem indicar o problema

O que a Documentação diz

A documentação oficial de APIM em VNet com forced tunneling estabelece o princípio:

"Configure a user-defined route (UDR) for [service tags] with next hop type set to 'Internet', to steer traffic back to Azure."

Embora o AzureEventGrid não esteja explicitamente listado na tabela de portas obrigatórias, o mesmo princípio se aplica: qualquer serviço Azure que o APIM precise alcançar precisa de uma rota explícita quando há forced tunneling.

Conclusão

A combinação de Load Balancer + Circuit Breaker + Retry inteligente no APIM transforma uma arquitetura frágil em uma arquitetura resiliente — onde falhas em backends individuais são tratadas de forma transparente, sem impacto para o cliente.

Os pontos-chave para levar:

Nunca exponha um único endpoint de Azure OpenAI diretamente — use o APIM como abstração
Managed Identity elimina o gerenciamento manual de segredos entre APIM e backends
O set-backend-service deve estar dentro do <retry> para que retentativas sejam distribuídas pelo Load Balancer
Circuit Breaker protege contra falhas em cascata — fail-fast é melhor que timeout lento
Observabilidade não é opcional — se o circuito está abrindo, você precisa saber

Referências

Detectando Anomalias de Custo no Azure com FinOps Hub + SRE Agent

arsilvan — Thu, 23 Apr 2026 12:59:25 GMT

Introdução

Um dos maiores desafios em ambientes cloud é manter a visibilidade sobre os custos. Picos inesperados podem passar despercebidos por dias e quando chegam na fatura, já é tarde demais.

Neste artigo, vou mostrar como configurei uma análise automática diária de anomalias de custo usando o Azure SRE Agent, conectado ao FinOps Hub (Azure Data Explorer), com notificação automática no Microsoft Teams quando algo fora do padrão é detectado.

🏗️ Arquitetura da Solução

FinOps Hub (ADX) → SRE Agent (Scheduled Task) → KQL Anomaly Detection

↓ anomalia detectada?

SIM → Adaptive Card → Teams Channel

NÃO → Log: 'custos dentro do esperado'

Pré-requisitos

	Requisito	Detalhe
✅	FinOps Hub implantado	Com dados de custo sendo ingeridos no Azure Data Explorer
✅	Azure SRE Agent configurado	Com acesso à subscription onde o FinOps Hub está
✅	Canal no Microsoft Teams	Onde as notificações serão postadas
✅	Permissões adequadas	Managed Identity com Viewer no database Hub do ADX

Passo a Passo

① Identificar o Cluster ADX do FinOps Hub

O primeiro passo é localizar o cluster Azure Data Explorer onde o FinOps Hub armazena os dados de custo. No Azure SRE Agent, usamos o Azure Resource Graph:

az graph query -q "Resources | where type =~ 'Microsoft.Kusto/clusters'" --first 10 --subscription <subscription-id>

No meu caso como exemplo, o cluster retornado foi:

Propriedade	Valor
Nome	finopshubadx
URI	https://finopshubadx.northcentralus.kusto.windows.net
Database	Hub
SKU	Dev(No SLA)_Standard_D11_v2
Região	North Central US

② Configurar Permissões (RBAC no ADX)

A managed identity do SRE Agent precisa de acesso Viewer ao database Hub do ADX. Sem isso, a query KQL falhará com erro 403.

Opção A — Azure CLI:

az kusto database-principal-assignment create \
--cluster-name finopshubadx \
--database-name Hub \
--resource-group <resource-group> \
--subscription <subscription-id> \
--principal-assignment-name "sre-agent-viewer" \
--principal-id "<managed-identity-client-id>" \
--principal-type App --role Viewer

Opção B — Portal:

ADX → Cluster → Database Hub → Permissions → Add → Viewer → Selecionar managed identity

Opção C — KQL (ADX Web UI):

.add database Hub viewers ('aadapp=<client-id>') 'SRE Agent'

③ A Query KQL de Detecção de Anomalias

Esta query utiliza series_decompose_anomalies do Kusto para detectar padrões anômalos nos custos diários ao longo dos últimos 12 meses:

let numberOfMonths = 12;
let start = startofmonth(ago(numberOfMonths * 30d));
let end = now();
let interval = 1d;

Costs()
| where ChargePeriodStart between (start .. end)
| summarize DailyCost = sum(EffectiveCost)
by bin(ChargePeriodStart, interval)
| make-series CostSeries = sum(DailyCost)
on ChargePeriodStart from start to end step interval
| extend anomalies = series_decompose_anomalies(CostSeries)
| project ChargePeriodStart, CostSeries, anomalies

💡 Como a query funciona

Costs() → Função do FinOps Hub que retorna dados de custo consolidados
make-series → Cria série temporal diária contínua (sem gaps)
series_decompose_anomalies → Algoritmo ML nativo do Kusto que detecta spikes e drops usando decomposição sazonal + STL
Score > 0 → custo acima do esperado | Score < 0 → abaixo do esperado
Quanto maior o |score|, mais significativa a anomalia

④ Configurar Webhook no Microsoft Teams

Para receber notificações no Teams, criamos um Incoming Webhook via Power Automate Workflows (método recomendado pela Microsoft):

No canal do Teams, clique nos 3 pontos (...) → Workflows
Pesquise "Post to a channel when a webhook request is received"
Selecione o Team e Channel desejados → Add workflow
Copie a URL gerada (formato: https://prod-xx...logic.azure.com/...)
Ative o workflow no Power Automate (My flows → Turn on)

⚠️ Atenção: O workflow pode ser criado com status 'Suspended'. Ative em: Power Automate → My flows → Turn on.

⑤ Criar a Scheduled Task no SRE Agent

Agora a parte principal: criar a tarefa agendada (Scheduled Task) no Azure SRE Agent. Basta pedir em linguagem natural:

"Crie uma tarefa diária para analisar anomalias de custo no FinOps Hub e me notificar pelo Teams quando houver anomalias detectadas."

O SRE Agent criará a task com os seguintes parâmetros:

Parâmetro	Valor
Nome	Daily FinOps Cost Anomaly Analysis
Schedule	0 8 * * * (diariamente às 08:00 UTC)
ADX Cluster	https://finopshubadx.northcentralus.kusto.windows.net
Database	Hub
Query	KQL com series_decompose_anomalies (12 meses)
Notificação	Adaptive Card no Teams via webhook
Escalação	HIGH se anomalias por 3+ dias consecutivos
Idempotência	Sem anomalia = 'custos dentro do esperado'

Task details:

Obs: Modificar os campos na task para adequar seu ambiente

Autonomous Scheduled Run - Daily FinOps Cost Anomaly Analysis ## Scope - Subscription: xxxxxxx-xxxxxxx-xxxxxx-xxxx-xxxxx - ADX Cluster: https://finopshub.northcentralus.kusto.windows.net - Database: Hub - Resource Group: finopshub-rg ## Goal Detect cost anomalies in Azure spending using the FinOps Hub data. Run the KQL query against the ADX cluster, analyze results, and notify via Teams if anomalies are found. ## Step 1: Execute KQL Query Use the KustoQuery subagent to run this query against the ADX cluster (https://finopshubadx.northcentralus.kusto.windows.net, database: Hub): ```kql let numberOfMonths = 12; let start = startofmonth(ago(numberOfMonths * 30d)); let end = now(); let interval = 1d; Costs() | where ChargePeriodStart between (start .. end) | summarize DailyCost = sum(EffectiveCost) by bin(ChargePeriodStart, interval) | make-series CostSeries = sum(DailyCost) on ChargePeriodStart from start to end step interval | extend anomalies = series_decompose_anomalies(CostSeries) | project ChargePeriodStart, CostSeries, anomalies ``` ## Step 2: Analyze Results - Parse the anomalies array from series_decompose_anomalies output - Identify days where anomaly score is significantly positive (cost spike) or negative (unusual drop) - For each anomaly found, calculate: the date, actual cost value, expected baseline, and percentage deviation - Focus on the last 7 days of data for actionable anomalies, but use the full 12-month history for context ## Step 3: Generate Report Create a summary with: - Total anomalies detected in the last 7 days - For each anomaly: date, cost value, deviation from expected, severity (high/medium/low) - Trend analysis: whether costs are trending up, down, or stable - Top recommendations (e.g., investigate specific resource groups, check for new deployments, review reserved instances) ## Step 4: Teams Notification (ONLY if anomalies detected in last 7 days) If anomalies are found, send a notification to Microsoft Teams using the executing_code skill (ExecutePythonCode) to POST to this webhook URL: https://839eace659ab424397eca5b8fcc104.e4.environment.api.powerplatform.com:443/powerautomate/automations/direct/workflows/88ec6b6c43014d8f8cb13999714dddd8/triggers/manual/paths/invoke?api-version=1&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=br2rNi4x1zKjWp6CgKWcajvEUW_7EUBkHrkbnp6Hk2g Use Adaptive Card format for the Teams message with: - Title: "⚠️ Azure Cost Anomaly Detected" - Summary of anomalies (dates, values, deviations) - Severity indicator - Link back to this SRE Agent thread for details Python code example for the webhook POST: ```python import urllib.request import json webhook_url = "<colar-url-webhook-aqui>" card = { "type": "message", "attachments": [{ "contentType": "application/vnd.microsoft.card.adaptive", "content": { "$schema": "http://adaptivecards.io/schemas/adaptive-card.json", "type": "AdaptiveCard", "version": "1.4", "body": [ {"type": "TextBlock", "text": "⚠️ Azure Cost Anomaly Detected", "weight": "Bolder", "size": "Large"}, {"type": "TextBlock", "text": "<ANOMALY_SUMMARY_HERE>", "wrap": True}, {"type": "FactSet", "facts": [ {"title": "Date", "value": "<DATE>"}, {"title": "Actual Cost", "value": "<COST>"}, {"title": "Expected", "value": "<EXPECTED>"}, {"title": "Deviation", "value": "<DEVIATION>%"}, {"title": "Severity", "value": "<SEVERITY>"} ]} ], "actions": [{"type": "Action.OpenUrl", "title": "View in SRE Agent", "url": "https://sre.azure.com/agents/subscriptions/<sua-subscricao>/resourceGroups/finopshub-rg/providers/Microsoft.App/agents/finopshub/views/thread/7314d219-77d6-4e12-a3fb-f30606d13077"}] } }] } req = urllib.request.Request(webhook_url, data=json.dumps(card).encode('utf-8'), headers={'Content-Type': 'application/json'}, method='POST') response = urllib.request.urlopen(req) ``` ## Step 5: Report in Thread Always post a summary in this thread with: - Whether anomalies were found or not - Key metrics and trends - If no anomalies: "No material cost anomalies detected. Daily costs within expected range." ## Constraints - Read-only operations only against ADX - Max 5 KQL queries per execution - Do not modify any Azure resources ## Idempotence If no anomalies detected in the last 7 days and costs are within normal thresholds, output: "No material cost anomalies detected. Daily costs within expected range." ## Escalation If anomalies are detected for 3+ consecutive days, flag as HIGH severity in the Teams notification and recommend immediate investigation.

⑥ Notificação no Teams (Adaptive Card)

Quando anomalias são detectadas, o SRE Agent envia um Adaptive Card rico para o Teams:

⚠️ AZURE COST ANOMALY DETECTED
🔴 HIGH — 2026-04-21
Custo Real	$1,847.32
Custo Esperado	$623.15
Desvio	+196.5% (↑ $1,224.17)
Score Anomalia	4.7 (threshold: 1.5)

🟡 MEDIUM — 2026-04-20
Custo Real	$987.44
Desvio	+59.5% (↑ $368.54)
📊 Trend (7d)	$601 → $615 → $622 → $619 → $987 → $1,847

Exemplo de Adaptive Card enviado ao canal do Teams

O card inclui botões: Ver Detalhes no SRE Agent e Abrir FinOps Hub (ADX) para investigação.

⑦ Testar a Integração (Simular Anomalia)

Antes de confiar no agendamento, teste pedindo ao SRE Agent:

"Simular uma anomalia de custo para eu receber no Teams"

O agente enviará um Adaptive Card de teste com dados simulados para validar que o webhook está funcionando.

Dica: Se o webhook retornar erro 400 - WorkflowTriggerIsNotEnabled, ative o flow em: Power Automate → My flows → Turn on.

Como Funciona no Dia a Dia

Horário	Ação	Resultado
08:00 UTC	SRE Agent executa query KQL no ADX	Dados de custo (12 meses)
08:01 UTC	Análise de anomalias (últimos 7 dias)	Identifica spikes e drops
08:02 UTC	Se anomalia → Teams notification	Adaptive Card no canal
08:02 UTC	Se normal → log no thread	"Custos dentro do esperado"
Contínuo	3+ dias anomalia → escalação HIGH	Investigação recomendada

Gerenciamento da Task

Após criada, a tarefa pode ser gerenciada pelo SRE Agent:

Pausar: "Pausar a tarefa de anomalia de custo"
Retomar: "Retomar a tarefa"
Alterar horário: "Mudar para executar às 10h UTC"
Ver histórico: "Mostrar histórico de execuções"
Cancelar: "Cancelar a tarefa de anomalia"

Conclusão

Com essa configuração, você tem um sistema inteligente de vigilância de custos que:

🔍 Analisa 12 meses de histórico para detectar padrões sazonais

🤖 Usa ML nativo do Kusto — sem infraestrutura adicional

📱 Notifica proativamente no Teams — só quando há anomalia

📈 Escala automaticamente a severidade em anomalias persistentes

💬 Mantém histórico completo no thread do SRE Agent

🔧 É gerenciável por linguagem natural — sem YAML, sem pipelines

A combinação FinOps Hub + Azure SRE Agent + Teams transforma a governança de custos de reativa (olhar dashboards) em proativa e automatizada.

🚀 Quer implementar na sua organização?

Se você quer testar, o Azure SRE Agent está disponível como preview. Configure um agente na sua subscription e comece a conversar em linguagem natural.

Já usa FinOps Hub? Conte nos comentários como você monitora anomalias de custo hoje!

#FinOps #Azure #SREAgent #CostManagement #AzureDataExplorer #CloudGovernance #DevOps #MicrosoftTeams #AIOps

Uso de contextos no Entra ID

wdossantos — Thu, 23 Apr 2026 12:53:59 GMT

Visão Geral

Com a crescente necessidade de segurança adaptativa, o Microsoft Entra ID oferece recursos avançados para aplicar políticas dinâmicas de acesso. Em cenários corporativos, autenticação e autorização tradicionais, baseadas apenas em roles e claims estáticos, nem sempre são suficientes. Imagine que um usuário já está logado e possui permissão para acessar uma API, mas você precisa garantir que, para uma operação crítica como deletar um registro, ele esteja dentro da rede corporativa, em um dispositivo gerenciado ou tenha assinado um termo de confidencialidade. É exatamente isso que os contextos de autenticação do Microsoft Entra ID resolvem.

Neste artigo vou detalhar todo o processo, desde a habilitação do Continuous Access Evaluation (CAE), passando pela configuração dos contextos e das políticas de acesso condicional no portal do Entra ID, até a integração prática com uma aplicação .NET dividida em frontend web e API de backend. No código, veremos como o MSAL intercepta o fluxo, verifica se o token contém a claim acrs com o contexto exigido e, caso não contenha, dispara um challenge que leva o usuário de volta ao Entra ID para cumprir o requisito adicional. Se o contexto já estiver satisfeito, o fluxo é transparente para o usuário.

O objetivo é destacar a granularidade no controle de acesso, a estrutura de contexto, os desafios de implementação e potenciais aplicações práticas.

Diagrama de Arquitetura

1. Caso de Uso

Para exemplificar, utilizamos uma aplicação .NET simples, dividida em dois componentes:

API de backend, que expõe endpoints protegidos
Aplicação web frontend, que consome a API via tokens

Fluxo Básico

A aplicação web é protegida pelo Entra ID
Ao iniciar, o MSAL (SDK de identidade da Microsoft) verifica se o usuário está autenticado
Se não estiver, solicita a autenticação
Após autenticado, a aplicação armazena um token para consumir a API

O Diferencial

Não basta um token de acesso convencional para consumir um endpoint específico da API. É necessário um token com uma claim especial (acrs), contendo exatamente o valor do contexto esperado.

2. Configuração do Entra ID

App Registration e Contextos

O processo inicia com o registro das aplicações (cliente e API) no Entra ID, mantendo as etapas tradicionais de permissionamento e definição de escopos.

A novidade está na configuração de contextos, que são pares chave-valor criados no Entra ID e utilizados em políticas de acesso condicional.

Pré-requisito: Licença Entra ID P1 para uso de acesso condicional.

O contexto é configurado em uma aba específica dentro das políticas de acesso condicional.

Ao criar um novo contexto, define-se o nome, descrição e o ID sequencial (ex: c1). O checkbox "Publish to apps" torna o contexto disponível para as aplicações consumirem:

Estrutura e Limitações dos Contextos

Aspecto	Detalhe
Identificação	Número sequencial (ex: c1, c2, até c99)
Limite	Vinculado ao número máximo de regras de acesso condicional (195)
Composição	Nome + Descrição
Utilidade	Depende da implementação na aplicação

Aplicação Prática dos Contextos

O contexto permite granularidade adicional além das tradicionais roles e claims do token JWT:

Rede corporativa: restringir acesso a uma área apenas para usuários dentro da rede interna
Dispositivos gerenciados: exigir que o dispositivo esteja em compliance
Assinatura de termos: exigir ações adicionais (ex: NDA) antes do acesso a dados sensíveis, mesmo que o token permita o acesso

Por fim, o contexto é vinculado a uma política de acesso condicional. No exemplo abaixo, a policy "Teste - C10" associa o contexto "Teste WebApp" como target resource:

3. Implementação no Código

3.1 Configuração no Cliente (Startup.cs)

No processo de inicialização, utiliza-se o método AddMicrosoftIdentityWebAppAuthentication para configurar a autenticação, incluindo o parâmetro ClientCapabilities, que habilita o uso de contexto.

Além disso, é adicionado o handler MicrosoftIdentityConsentAndConditionalAccessHandler para gerenciar o fluxo de acesso condicional.

// Habilita autenticação com suporte a contexto e acesso condicional services.AddMicrosoftIdentityWebAppAuthentication(Configuration) .EnableTokenAcquisitionToCallDownstreamApi( Configuration.GetSection("TodoList:Scopes").Get<string[]>() ) .AddInMemoryTokenCaches(); // Handler para gerenciar challenge de acesso condicional services.AddScoped<MicrosoftIdentityConsentAndConditionalAccessHandler>();

3.2 Configuração (appsettings.json)

O ponto-chave é o ClientCapabilities: ["cp1"], que habilita o suporte a Continuous Access Evaluation:

{ "AzureAd": { "Instance": "https://login.microsoftonline.com/", "Domain": "cyber.meudominio.com.br", "TenantId": "...-8888-4400-8c9c-...", "ClientId": "...-e635-...-bb9f-...", "CallbackPath": "/signin-oidc", "SignedOutCallbackPath": "/signout-oidc", "ClientCapabilities": [ "cp1" ], "ClientSecret": "XHm8Q~6_rNy_ib-....~KbcvF" } }

A classe Configuration, passada para AddMicrosoftIdentityWebAppAuthentication, localiza e carrega automaticamente a seção AzureAd do arquivo de configuração.

3.3 Método Crítico: Validação do Contexto

No endpoint crítico (ex: deletar item), o código verifica se o token do usuário contém a claim acrs com o valor do contexto exigido:

// GET: TodoList/Delete/5 public async Task<ActionResult> DeleteItem(int id) { string requiredAuthContextId = "c10"; string acrsClaimType = "acrs"; // Construção do claimsChallenge var claimsChallengeObj = new { id_token = new { acrs = new { essential = true, value = requiredAuthContextId } } }; string claimsChallenge = System.Text.Json.JsonSerializer.Serialize(claimsChallengeObj); // Verifica se o usuário possui o claim necessário Claim acrsClaim = User.FindAll(acrsClaimType) .FirstOrDefault(x => x.Value == requiredAuthContextId); if (acrsClaim?.Value != requiredAuthContextId) { // Dispara challenge para cumprir o contexto exigido _consentHandler.ChallengeUser( new[] { "api://ce845259-3c67-43c1-9816-43f82f4d7704/ToDoList.Read", "api://ce845259-3c67-43c1-9816-43f82f4d7704/ToDoList.ReadWrite" }, claimsChallenge ); } try { var todo = await _downstreamApi.GetForUserAsync<Todo>( "TodoList", options => options.RelativePath = $"api/todolist/{id}"); if (todo == null) return NotFound(); return View(todo); } catch (Exception) { return RedirectToAction("Index"); } }

Lógica do Fluxo

Claim presente e válida: a operação é permitida normalmente
Claim ausente: o ChallengeUser() abre a tela do Entra ID para o usuário cumprir o requisito (ex: MFA, assinatura de termo)
Contexto já satisfeito: o fluxo é transparente para o usuário

4. Fluxo de Challenge e Resposta

Do lado da API (Backend)

Quando o contexto não é atendido, a API retorna:

401 Unauthorized com headers customizados
Informações sobre o contexto exigido no corpo/headers da resposta

Do lado do Cliente (Frontend)

O cliente captura exceções específicas (WebApiMsalUiRequiredException)
Extrai informações do header da resposta
Executa o fluxo de challenge conforme necessário
Após cumprido o requisito, o token é renovado com a claim acrs

5. Considerações Finais

O uso de contextos no Entra ID amplia as possibilidades de controle de acesso, permitindo requisitos dinâmicos e contextuais além das roles tradicionais
A implementação exige integração cuidadosa entre backend e frontend, além de testes para garantir o correto tratamento dos fluxos de challenge e resposta
A documentação limitada reforça a importância de compartilhar experiências e boas práticas para fomentar o uso do recurso
Requer licença Entra ID P1 para acesso condicional

Referências

FinOps Hub Privado: Implementação Manual em Ambientes Corporativos

carolinamelo — Fri, 10 Apr 2026 16:51:20 GMT

O que é o FinOps Hub?

O FinOps Hub é uma solução open source da Microsoft, parte do FinOps Toolkit, que fornece uma base escalável e extensível para análise, governança e otimização de custos em nuvem. A solução centraliza dados de custos por meio de recursos de armazenamento e pipelines de dados, permitindo que as organizações padronizem a forma como analisam seus gastos na nuvem, adotando o modelo de dados FOCUS definido pela FinOps Foundation.

Além de disponibilizar relatórios e dashboards prontos, o FinOps Hub expõe os dados de custos de forma estruturada por meio do Azure Data Explorer ou do Microsoft Fabric, possibilitando a criação de relatórios customizados no Power BI e o desenvolvimento de soluções internas sob medida, de acordo com as necessidades do negócio.

Objetivo

Esse artigo visa orientar a implementação manual do acesso privado ao FinOps Hub após uma implementação pública, sem usar diretamente a opção de implementação privada oferecida pelo template.

Por que implementar o FinOps Hub com acesso privado de forma manual?

O template disponibilizado para a implementação do FinOps Hub permite que selecionemos duas formas de implementação:

Pública: forma de implementação mais simples e comum. Os recursos são provisionados com acesso público habilitado, sendo acessados por meio de seus endpoints públicos padrões do Azure. O controle de acesso é feito exclusivamente via permissões RBAC.
Privada: forma de implementação mais segura. Os recursos são provisionados com acesso público desabilitado e expostos apenas por meio de private endpoints, ficando acessíveis somente através de redes privadas que possuem conectividade com a rede onde esses endpoints estão implementados.

Embora a comunicação privada traga ganhos significativos de segurança, sua habilitação através do template do FinOps Hub introduz algumas implicações importantes no processo de implantação. O template, de forma automática, tenta:

Criar uma rede virtual (/26);
Provisionar Private DNS Zones;
Criar os registros DNS associados aos private endpoints;
Configurar os links entre as VNets e as zonas DNS.

Em muitas organizações, esse tipo de configuração é restrito por políticas internas. A criação de redes, zonas DNS e seus respectivos vínculos costuma ser responsabilidade de times especializados, que garantem a padronização e a aderência às diretrizes arquiteturais definidas pela empresa.

Em cenários onde a organização adota, por exemplo, uma topologia Hub & Spoke, com landing zones bem definidas para workloads e conectividade, é fundamental considerar alguns pontos adicionais:

Garantir que a rede criada para os private endpoints não tenha sobreposição (overlap) com outras redes existentes;
Assegurar que exista peering com a VNet de hub;
Integrar os registros DNS dos novos private endpoints às Private DNS Zones centralizadas;
Configurar corretamente os VNet links;
Garantir que a resolução de nomes esteja funcional no ambiente on-premises, permitindo o acesso ao FinOps Hub por meio de VPN, ExpressRoute ou outras formas de conectividade híbrida.

Esses fatores explicam por que, em muitos casos, o uso do template com configuração privada se torna inviável quando utilizado de forma isolada. Isso ocorre porque, frequentemente, o time de FinOps não é o mesmo time responsável por redes e DNS, possuindo permissão para implantar apenas parte dos recursos necessários.

Nesses cenários, a implementação privada exige a orquestração entre diferentes times, cada um atuando dentro de suas responsabilidades. Como resultado, algumas etapas que o template tenta executar automaticamente precisam ser realizadas manualmente, conforme descrito nas próximas seções.

Passo a Passo para Implementação

Faça a implementação do template seguindo o tutorial documentado, com “Networking” em modo público.
Assim que o template é implementado, alguns scripts de configuração são executados. Aguarde até que esses scripts sejam executados, ou seja, desapareçam do grupo de recursos onde o FinOps Hub foi implementado para seguir com os próximos passos. Exemplos dos “Deployment Scripts” que desaparecerão:

Crie uma rede de tamanho mínimo /26 – valide com o time de infraestrutura o espaçamento que pode ser utilizado. Dentro dessa rede implemente uma subrede:
- private-endpoint-subnet (/28) – subrede para os private endpoints.
Garanta a existência das Private DNS Zones: se seu ambiente possui zonas de DNS privadas centralizadas pré-configuradas. Garanta que as seguintes zonas já existam na subscription padrão para os seus recursos de rede:
- privatelink.blob.core.windows.net– para o Data Explorer e storage
- privatelink.dfs.core.windows.net– para o Data Explorer and o data lake hospedando os dados de FinOps data e configuração das pipelines
- privatelink.table.core.windows.net– para Data Explorer
- privatelink.queue.core.windows.net– para o Data Explorer
- privatelink.{location}.kusto.windows.net– para Data Explorer

Configurando a Storage Account com Acesso Privado

O primeiro recurso que a ser configurado será a Storage Account.

A configuração a seguir deve ser realizada duas vezes uma para o target sub-resource “blob” e outra para o target sub-resource “dfs”.
- Acesse “Networking” e a aba “Private Endpoints”
- Na aba “Basics” defina:
  - Subscription: mesma que o FinOps Hub foi implementado
  - Resource Group: mesmo que o FinOps Hub foi implementado
  - Name: use um nome que remeta ao recurso criado (private endpoint) e o sub recurso que ele fará exposição (blob/dfs). Exemplo: pe-storageaccount-blob/ pe-storageaccount-dfs
- Na aba “Resource” defina o target sub-resource para o qual a configuração está sendo feita. No caso, primeiro foi feito para “blob” e depois “dfs”.
- Na aba “Virtual Network”, deve-se selecionar a rede criada para os private endpoints bem como a subrede (private-endpoint-subnet).
- Na aba “DNS” selecione a private DNS zone na qual são realizados os registros do seus private endpoints. Quando estiver configurando o private endpoint para blob será privatelink.blob.core.windows.net e para dfs privatelink.dfs.core.windows.net.
- Adicione Tags caso seja necessário.
- Clique em “Review + create”.
- Ao final, dois private endpoints devem estar criados para a storage account:

Agora será necessário configurar o private endpoint usado pelo Data Factory para acessar a Storage Account.
- Acesse o Data Factory e clique em "Launch Studio".
- No menu lateral, selecione a opção "Manage" -> "Linked services":
- Selecione o serviço correspondente ao Azure Data Lake Storage Gen2.
- Em “Connect via integration runtime” substitua “AutoResolveIntegrationRuntime” por New+:
- Em “Integration runtime setup” selecione “Azure” -> Botão “Continue”:
- Na aba “Settings”, apenas altere o campo “Name”. Use algo como “ManagedIntegrationRuntime”. Os demais campos, mantenha como estão:
- Na aba “Virtual Network”, configure conforme a imagem abaixo:
- Por fim, na aba “Data flow runtime”, use as configurações abaixo:
- Clique em “Create”.
- Agora, voltando a página “Edit linked Service”, adicione o “Managed Private Endpoint”. Ele ficará em estado “Pending”.
- Clique em “Save”.
- Além disso, use a managed identity fornecida na página “Edit linked Service”, e lhe dê os seguintes acessos na storage account:
  - Reader
  - Storage Account Contributor
  - Storage Blob Data Contributor
- Por fim, acesse a seção “Networking” da Storage Account novamente, selecione o private endpoint criado pelo Data Factory e clique no botão “Approve”.

Configurando o Linked Service ftkRepo no Data Factory

Voltando na seção “Manage” do Azure Data Factory, será necessário editar o serviço “ftkRepo”. Nele, o único campo a ser alterado é o “Connect via integration runtime” usando o “ManagedIntegrationRuntime” criado na etapa de configuração da storage account.

Clique em “Save”.

Configurando o Azure Data Explorer com Acesso Privado

Acesse a seção “Networking” cluster do Data Explorer criado pelo script do FinOps Hub e acesse a aba “Private Endpoint Connections”
Clique em “+ Private Endpoint”.
Em “Basics” inclua um nome para o private endpoint e garanta que a região selecionada é a de implementação do seu FinOps Hub e da vnet criada para ele.
Na aba “Virtual Network” selecione a rede e subrede criadas para os private endpoints.
Na aba “DNS”, associar cada configuração a sua private DNS zone correspondente. Se essas zonas já existirem no ambiente e forem utilizadas de forma centralizada, usar as existentes. Caso contrário, a configuração poderá criar private DNS zones novas:
Novamente será preciso configurar o private endpoint gerenciado pelo Data Factory. Para isso, acesse “Managed” -> “Linked Services” e selecione o serviço referente ao Azure Data Explorer.
Nessa seção, o único campo a ser editado é o “Connect via integration runtime” usando o “ManagedIntegrationRuntime” criado na etapa de configuração da storage account.
Agora ainda em “Manage” no Data Factory, selecione a opção “Managed Private Endpoints”. Clique em “+New” -> “Azure Data Explorer (Kusto)”
Forneça um nome para o private endpoint, marque a subscription na qual o Data Explorer foi implementado e em "Cluster" selecione o recurso implementado via template do FinOps Hub:
Ao final, deve-se ter dois private endpoints configurados no Azure Data Explorer:

Ajustes Finais e Validações de Conectividade

Tanto para a Storage Account quanto para o Data Explorer, acesse as configurações de rede e altere o Public network access para “Disabled”.
Por fim, no seu servidor local de DNS, crie o registro para o Data Explorer apontando para o forwarder correto no Azure seja ele uma máquina virtual ou o inbound endpoint do Azure Private Resolver. Não use o domínio com privatelink, mas sim o padrão, no caso do Data Explorer a forma geral é <localização>.kusto.windows.net conforme o exemplo abaixo:

Ao configurar os apontamentos corretamente, será possível configurar os dashboards em máquinas locais/on-premises que tenham acesso privado ao ambiente Azure. Os dashboards precisam ser capazes de resolver a URL do cluster Data Explorer que é apontado como parâmetro do Dashboard em PowerBI.
Se desejar validar a comunicação antes de configurar o dashboard de Power BI, teste da sua máquina local a resolução da URI do Data Explorer implementado para o FinOps Hub, usando nslookup conforme o exemplo abaixo.

Segurança Corporativa no Azure VMware Solution (AVS): Como Inspecionar o Tráfego com Firewall NVA

LeandroBarbosa — Wed, 11 Mar 2026 14:50:40 GMT

Muitas vezes faz sentido usar uma NVA (Network Virtual Appliance) como firewall dentro do AVS, porque permite reaproveitar a solução de firewall já existente (Palo Alto, Check Point, etc..) e manter a proficiência do time de segurança, evita parte da complexidade de roteamento que pode surgir ao forçar o tráfego passar por um firewall “fora” do AVS . Além disso, administrar esse firewall dentro do AVS continua familiar para quem já opera VMware, e você ganha acesso a recursos avançados de inspeção do fabricante (como filtragem por aplicação em camada 7 e inspeção SSL/TLS), que são muito úteis para controle de tráfego outbound e políticas corporativas.

Neste artigo eu demonstro e um laboratório prático de inspeção de tráfego Norte-Sul e Leste-Oeste, fazendo isolamento por ambiente (DEV/PRD) dentro do Azure VMware Solution (AVS) usando NSX-T (Tier-0/Tier-1) e um Firewall NVA (pfSense) implantado no SDDC. Também serão demonstradas as principais configurações no NSX (criação/associação de segments, gateways T0/T1 e ajustes de roteamento necessários para forçar o tráfego a passar pela NVA).

Arquitetura

Informações do Laboratório

Segmentos de Trânsito

Transit_Outside | CIDR: 192.168.30.0/24 | GW: 192.168.30.1
Transit_PRD | CIDR: 192.168.21.0/24 | GW: 192.168.21.1
Transit_DEV | CIDR: 192.168.22.0/24 | GW: 192.168.22.1

Segmentos de Workloads

PRD_WEB | CIDR: 192.168.70.0/24 | GW: 192.168.70.1
PRD_DATA | CIDR: 192.168.71.0/24 | GW: 192.168.71.1
DEV_WEB | CIDR: 192.168.80.0/24 | GW: 192.168.80.1
DEV_DATA | CIDR: 192.168.81.0/24 | GW: 192.168.81.1

Interfaces da NVA (pfSense)

Transit_Outside: 192.168.30.5
Transit_PRD: 192.168.21.5
Transit_DEV: 192.168.22.5

Configuração do Azure VMware Solution

Na configuração Internet connectivity (egress/ingress) do Azure VMware Solution (AVS) irei utilizar a opção "Connect using Public IP down to the NSX Edge". Isso permite usar o NSX Data Center para criar regras de outbound e inbound (DNAT/SNAT) usando esses IPs públicos diretamente no Edge do AVS.

Configuração de SNAT e NoSnat no NSX

Regras “No SNAT” : Define que não deve haver tradução de origem quando o tráfego vai para redes privadas RFC1918. Isso preserva o IP original de origem para comunicação interna (ex.: on-prem, Azure, spoke VNets/rotas privadas), evita quebra de roteamento/retorno.
Regra “SNAT”: Aplica tradução de origem para o restante do tráfego (Internet). Ou seja, quando uma VM com IP privado sai para fora, o NSX troca o IP de origem pelo IP público configurado ( 20.20.138.0/32).

Criação dos Gateways TIER-1 (PRD e DEV).

Importante: Estes gateway são "Isolados", portando não serão conectados ao TIER-0

T1_PRD_Isolado

T1_DEV_Isolado

Resultado

Criação dos Segmentos de Trânsito PRD e DEV

Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_Isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior

TRANSIT_PRD

TRANSIT_DEV

Criação do Segmento PRD WEB e DATA

Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior

PRD_WEB

PRD_DATA

DEV_WEB

DEV_DATA

Visão Geral dos Segmentos

Configuração de Rotas

Rotas no Gateway T1 Default

No Gateway T1 Default que está conectado ao T0 , irei configurar rotas para todos os segmentos com Next Hop ao ip da interface Outside do meu PFsense (192.168.30.5) .

obs: o nome do gateway T1 é diferente em cada AVS SDDC, no meu ambiente é "TNT13-T1"

Informei o CIDR da Rede , neste caso é para o segmento TRANSIT_PRD

Next Hop aqui é o ip da interface Outside do PFsense ( 192.168.30.5) , que está conectada diretamente a este GW T1.

Repeti os mesmos passos para todos os outros Segmentos, sempre com next hop para 192.168.30.5.

Interfaces Firewall Pfsense

Neste cenário o Firewall possui apenas três interfaces.

Deve ser configurada a rota default ( 0.0.0.0/0) para o gateway do Segmento Transit Outside ( 192.168.30.1)

Interfaces do Pfsense

Rotas no Gateways de Transito : T1_PRD_isolado

Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.21.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1

Configuração da Rodas default

Next Hop para ip da Interface Inside PFsense.

Rotas no Gateways de Transito : T1_DEV_Isolado

Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.22.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1

Configuração da Rodas default

Next Hop para ip da Interface Inside PFsense.

Teste de Acesso

Tráfego Norte-Sul ( Saída Internet)

Para comprovar que conseguimos agora ter o tráfego Norte-Sul, pelo NVA PFense , irei fazer um teste a partir da máquina no segmento PRD_WEB , com ip 192.168.70.1

É possivel observar que o ip públlico de saída é do AVS

Agora vou criar uma regra no Pfsense bloqueando a porta 443 , mas deixando liberada as outras portas.

Podemos comprovar que o tráfego está sendo inspersionado fazendo um teste de conexão na porta 53 e outro teste https.

No Pfsense podemos ver o bloqueio

Tráfego Leste-Oeste

Para testar o tráfego leste oeste entre os Segmentos PRD_WEB ( VM 192.168.70.10 ) e DEV_WEB ( VM 192.168.80.10) , irei deixar ICMP liberado e bloquear a porta 3389 ( RDP)

Fazendo o teste a partir da máquina 192.168.70.10

Verificando no PFsense o bloqueio da porta 3389

Resumo

Neste laboratório demonstrei como integrar uma NVA ao Azure VMware Solution usando NSX-T com Tier-0/Tier-1, criando T1s isolados para DEV e PRD, segments de trânsito e a configuração de SNAT/NoSNAT no NSX para controlar o egress. Também mostrei o ajuste de rotas para garantir que o tráfego siga pelo caminho de inspeção no firewall. Validei a arquitetura com testes práticos de tráfego Norte-Sul (saída para Internet com IP público do AVS) e Leste-Oeste (controle entre DEV e PRD), comprovando a inspeção via logs e bloqueios aplicados no pfSense. Como próximos passos para produção, recomenda-se padronizar regras, logging, e revisar resiliência/HA do firewall e rotas para reduzir pontos únicos de falha.

Referências

Anonimização de Dados Sensíveis com a plataforma de IA do Azure

anaritak — Fri, 26 Dec 2025 17:51:22 GMT

A Lei Geral de Proteção de Dados (LGPD) estabelece padrões rigorosos para o tratamento de dados pessoais e sensíveis no Brasil. Dados pessoais incluem informações que identificam diretamente um indivíduo, como nome, endereço, telefone, CPF, RG e data de nascimento. Já os dados sensíveis abrangem categorias especiais, como origem racial ou étnica, crenças religiosas, opiniões políticas, dados de saúde ou genéticos, biometria, orientação sexual e filiação sindical. Esses dados exigem cuidados adicionais, pois impactam diretamente a privacidade e os direitos dos titulares.

No contexto do processamento e compartilhamento de documentos — especialmente em setores como o público e o médico — é essencial reconhecer e classificar corretamente esses tipos de dados. Documentos oficiais ou registros de saúde frequentemente contêm tanto informações pessoais quanto dados altamente sensíveis, tornando a anonimização uma necessidade prática além de uma exigência legal.

Proposta de Arquitetura

Para atender à demanda de anonimização de dados sensíveis em documentos, soluções modernas de inteligência artificial, como Azure Document Intelligence e Azure Language Service, oferecem capacidade para detectar e classificar automaticamente informações pessoais. Esses serviços aceleram o processo de proteção de dados, mas seus modelos genéricos podem não abranger totalmente todas as categorias previstas pela LGPD — especialmente aquelas mais complexas ou dependentes de contexto, como opiniões políticas, crenças religiosas ou informações específicas de saúde.

Um caso simbólico pode ilustrar esse cenário: imagine uma plataforma responsável pelo armazenamento e compartilhamento de documentos administrativos. Para garantir que conteúdos sensíveis possam ser divulgados sem violar a privacidade das pessoas citadas, é possível implementar uma solução de anonimização baseada em IA. Ao utilizar modelos genéricos dos serviços de linguagem do Azure, conseguimos cobrir aproximadamente metade das classes previstas na LGPD, mas essas já abrangem a maior parte das classes determinísticas da legislação.

Abaixo, a arquitetura sugerida é detalhada de forma segmentada:

Azure Document Intelligence

O Azure Document Intelligence compõe a primeira camada do processamento, responsável por extrair texto, estrutura e coordenadas dos elementos presentes nos documentos — como tabelas, formulários, assinaturas e marcações visuais. Essa leitura estrutural permite compreender não apenas o que está escrito, mas onde cada informação se encontra.

A escolha por esse serviço se deve à sua capacidade de fornecer OCR avançado, interpretar layouts complexos e identificar elementos adicionais, como códigos de barras e QR Codes, que muitas vezes carregam metadados sensíveis. Esse mapeamento preciso é essencial para aplicar anonimização diretamente nas regiões corretas, preservando a integridade visual do documento.

Azure Language Service — PII e Classificação

Nesta segunda etapa, o Azure Language Service é utilizado para identificar automaticamente informações pessoalmente identificáveis (PII), como nomes, endereços, dados de contato e números de documentos. O modelo analisa o conteúdo com foco semântico, classificando entidades conforme categorias previstas na LGPD.

A motivação para empregá-lo está em sua capacidade de fornecer uma base abrangente e pronta para uso, permitindo detectar rapidamente grande parte dos dados sensíveis encontrados em documentos reais. Isso reduz a necessidade de regras manuais e acelera o processo de anonimização.

Azure Language Service — Modelos Personalizados (Custom NER)

Embora os modelos genéricos atendam a boa parte dos cenários, documentos reais costumam conter entidades específicas do domínio — expressões próprias da instituição, cargos incomuns, nomes de sistemas internos, termos de contexto ou siglas não previstas pelo modelo padrão.

Para suprir essas lacunas, são usados modelos personalizados de Reconhecimento de Entidades Nomeadas (NER). Eles permitem treinar novas categorias sensíveis e adaptar o processamento à realidade da organização. A motivação principal é reduzir falsos positivos/negativos e garantir maior precisão nos casos de uso mais complexos.

Azure Computer Vision

Quando documentos incluem imagens, fotografias ou capturas de telas, a anonimização precisa ir além do texto. O Azure Computer Vision é utilizado para detectar rostos e outras características visuais que possam identificar indivíduos.

Sua inclusão no processamento permite aplicar desfocagem ou mascaramento diretamente nos elementos encontrados, garantindo proteção também em conteúdo multimídia. Isso se torna especialmente relevante em documentos digitalizados que podem conter retratos, crachás, assinaturas digitalizadas ou imagens que exponham a identidade de terceiros.

Orchestrator Python — Lógica de Anonimização Baseada em Coordenadas

A última camada da solução é desenvolvida em Python, responsável por orquestrar os serviços de IA e aplicar a anonimização final no documento. Com base nas coordenadas extraídas pelo Document Intelligence e nas entidades classificadas pelo Language Service, o componente Redaction realiza o mascaramento diretamente sobre a área correspondente.

A escolha pelo Python se justifica pela sua flexibilidade, ampla disponibilidade de bibliotecas para manipulação de PDFs e imagens, e facilidade para integrar diferentes serviços do Azure em um único fluxo. Além disso, permite criar filtros adicionais — como evitar mascarar nomes de organizações ou estruturas fixas — garantindo precisão e consistência no resultado final.

Recomendações

Veja o repositório de uma demonstração simplificada com arquivos fictícios: Repo

Se você deseja implantar essa solução, pode utilizar o código disponível no repositório e adaptá-lo aos seus filtros e regras específicas. A estratégia recomendada é empacotar a aplicação em contêineres para facilitar a escalabilidade e a integração com diferentes ambientes.

Além disso, é possível consumir os serviços do Azure diretamente via APIs, garantindo flexibilidade na arquitetura e integração com outras aplicações. Todas essas informações, incluindo exemplos e orientações detalhadas, estão disponíveis na documentação oficial dos serviços Azure.

Essa abordagem integrada garante que documentos públicos possam ser compartilhados de forma segura, respeitando a legislação e protegendo a privacidade das pessoas. A evolução para modelos personalizados representa um salto importante, permitindo identificar e anonimizar dados que hoje passam despercebidos pelos modelos padrão, elevando o nível de conformidade e confiança no tratamento de dados sensíveis.

Agradecimentos

Agradeço especialmente ao Gilberto Santos, meu colega Cloud Solution Architect Linkedin, pela generosidade em compartilhar sua expertise sobre os serviços do Azure e pelo apoio essencial no desenvolvimento desta arquitetura.

Também registro meu agradecimento ao Alexandre Teoi, Cloud Solution Architect Linkedin, pela revisão criteriosa e pelas contribuições valiosas para o aprimoramento deste artigo.

Protegendo Máquinas no Azure VMware Solution com Azure Firewall

LeandroBarbosa — Fri, 17 Oct 2025 20:49:10 GMT

O Azure VMware Solution oferece três opções principais de conectividade outbound para a Internet.

A primeira é o Managed SNAT, opção padrão e totalmente gerenciada pela plataforma, em que o próprio AVS realiza a tradução de endereços (SNAT) para permitir o acesso à Internet. Essa abordagem é simples e não requer configuração adicional, porém não oferece controle sobre os endereços IP públicos utilizados.

A segunda opção é o uso de Public IPs no NSX-T Edge, onde o administrador atribui endereços públicos diretamente ao edge do ambiente AVS. Com isso, o tráfego de saída das máquinas virtuais utiliza esses IPs específicos, permitindo maior controle, ideal para cenários em que é necessário manter IPs fixos ou previamente autorizados em listas de acesso externas.

Por fim, há a opção de rotear o tráfego via rede Azure (ou Azure Virtual WAN), em que uma rota padrão é anunciada por meio do ExpressRoute, direcionando o tráfego de saída para uma rede Azure que contém NVAs, Azure Firewall ou proxies. Essa abordagem oferece o maior nível de controle e segurança, pois permite aplicar inspeção, políticas e NAT centralizados, de forma integrada à arquitetura de rede do cliente.

Neste artigo será demonstrado em um ambiente de laboratório como utilizar o Virtual Wan com Azure Firewall para inspeção do tráfego de saída das Vms em um segmento do AVS

A arquitetura do laboratório.

Virtual Wan com Azure Firewall
ER Gateway conectado ao Express Route do Azure VMware Solution

Os passos necessários são:

Configuração da opção de Internet Connectivity do AVS
Habilitar a propagação da Rota no Vwan
Configuração do Routing Intent

Configuração do Azure VMware Solution.

Acesse o Private Cloud no portal do Azure e certifique que a opção abaixo esteja selecionada.

Fazendo um "dump" das rotas no T0 do NSX, é possível verificar que não temos a rota default sendo propagada.

Portanto não temos conectividade para internet a partir da máquina VM1 que está no AVS.

Habilitando a propagação da Rota default no Virtual Wan

Devemos agora habilitar a propagação da rota default pelo Virtual Wan , e para isso é necessário editar a conexão do Express Route do AVS, conectado ao Hub do Vwan .

Habilite a propagação da Rota default

Routing Intent

O Routing Intent no Azure Virtual WAN é um recurso que simplifica e automatiza o roteamento de tráfego dentro do hub do Virtual WAN. Ele define como o tráfego entre redes (VNets, branches, e Internet) deve ser direcionado, sem necessidade de configurar manualmente tabelas de rotas complexas

Observação: Em geral, no Brasil, caso já exista um Express Route On-premises, o Routing Intent já deve estar ativado para permitir o tráfego na comunicação com o Express Route do AVS, devido a não disponibilidade na região do Brasil do Express Route Global Reach

Nas configurações do HUB, habilite o Routing Intent.

Fazendo um novo "dump"das rotas BGP no NSX, agora é possível observar a rota default sendo propagada.

Testando a partir da VM no AVS

Conforme esperado é o mesmo IP público do meu Firewall no Vwan

Nos Logs do Azure Firewall, comprovamos que o tráfego da VM (10.145.0.10) realmente está passando pelo Azure Firewall

Referências: https://learn.microsoft.com/en-us/azure/azure-vmware/disable-internet-access

Alta Disponibilidade e Resiliência com App Gateway e Múltiplos APIMs: Uma Arquitetura Estratégica

wdossantos — Tue, 09 Sep 2025 18:54:23 GMT

Resiliência como Pilar do Azure Well-Architected Framework

A resiliência é um dos pilares fundamentais do WAF e desempenha papel crítico na construção de arquiteturas modernas em nuvem. Este artigo explora o design de alta disponibilidade (HA) utilizando a oferta Premium Tier do Azure API Management (APIM) em cenários multi-região ou mesmo intra-região, com foco na aplicação de Availability Zones — uma prática recomendada no pilar de Confiabilidade.

A configuração Premium permite que as regiões primária e secundária compartilhem a mesma instância de APIM. No entanto, dependendo dos requisitos de negócio e tolerância a falhas, pode ser estratégico operar com duas instâncias separadas, garantindo continuidade de serviço mesmo diante de falhas regionais ou em uma das instâncias. Essa abordagem está alinhada ao modelo de DR Ativo-Ativo, promovendo tolerância a falhas, escalabilidade horizontal e resiliência operacional, conforme descrito no modelo de maturidade de confiabilidade.

A imagem acima representa os componentes do APIM nas regiões primária e secundária. Em cenários com instâncias separadas, esses componentes também estariam presentes em cada região. Já em uma configuração com Availability Zones, os elementos podem escalar dentro da mesma região, conforme a demanda — prática que também se conecta ao pilar de excelência operacional , ao permitir automação e monitoramento contínuo.

O fluxo de comunicação entre a API e os serviços de backend pode ocorrer por rotas diretas ou por meio de balanceadores de carga, dependendo do caso de uso. Essa arquitetura inspirou uma solução personalizada para um de nossos clientes, que buscava alta disponibilidade com baixa latência, mesmo em cenários de falha regional.

Configuração do APIM como gateway de saída para o cluster de aplicações

Press enter or click to view image in full size

Em alguns casos, por questões de compliance, não é possível operar fora de um regions específica . Ainda assim, essa arquitetura já proporciona ganhos significativos mesmo dentro da mesma região, como maior resiliência, escalabilidade e eficiência operacional.

Visão Geral da Arquitetura

Componentes principais:

Usuário: Inicia a requisição.
WAF: Protege contra ameaças e ataques na borda.
AKS: Gerencia APIs e aplicações containerizadas.
App Gateway (AppGW): Roteia o tráfego para os APIMs.
APIM001 e APIM002: Instâncias do Azure API Management, com IPs distintos e potencialmente em regiões diferentes.
Sistemas legados (kubernets / VMS): Integração com sistemas on-premises.

Essa arquitetura é interessante, pois, neste caso de uso, o APIM atua como ponto de saída do cluster de aplicações — exatamente o caminho crítico que queremos proteger

Com duas instâncias de APIM atrás do AppGW, é possível:

Realizar manutenções planejadas em uma instância sem impactar os usuários.
Redirecionar o tráfego automaticamente para a instância saudável.
Garantir zero downtime, mesmo durante atualizações críticas.

Essa abordagem é especialmente útil em ambientes com alta exigência de SLA, como bancos, governo e telecom.

Testes Blue-Green com Segurança e Controle

A arquitetura permite implementar estratégias Blue-Green com facilidade:

Uma instância do APIM pode representar o ambiente “Blue” (produção atual).
A outra instância representa o ambiente “Green” (nova versão).
O AppGW pode direcionar parte do tráfego para o ambiente Green para testes controlados.
Após validação, o tráfego pode ser totalmente migrado para o Green, promovendo a nova versão com segurança.

Isso reduz riscos de regressão e permite deploys mais confiáveis

Redução de Riscos em Caminhos Críticos

Ao distribuir o tráfego entre dois APIMs:

Reduz-se o risco de ponto único de falha.
A arquitetura se torna mais resiliente a falhas regionais ou de serviço.
Em caso de falha de uma instância, o AppGW garante continuidade do serviço.

Essa redundância é essencial para caminhos críticos de negócio, como autenticação, transações financeiras ou integrações com sistemas legados.

Outros Benefícios Estratégicos

✅ Disaster Recovery Ativo-Ativo

As duas instâncias do APIM funcionam simultaneamente em modo ativo-ativo.
Em caso de falha em uma das instâncias, o tráfego é automaticamente redirecionado.
Reduz significativamente o RTO e assegura a continuidade dos serviços..

✅ Mitigação de Esgotamento de IPs

O uso de múltiplas instâncias permite distribuir o consumo de IPs.
Evita gargalos de rede e problemas de limitação de recursos.

✅ Escalabilidade Regional

A arquitetura possibilita escalabilidade horizontal simplificada.
Suporta o crescimento de demanda em diferentes regiões de forma eficiente.

Como configurar o APPGW para uma POC de balanceamento entre dois APIMs

O Azure Application Gateway é um balanceador de carga de camada 7 (HTTP/HTTPS) que permite gerenciar o tráfego de aplicações web com inteligência, segurança e escalabilidade. Ele opera com base em um conjunto de configurações como Listeners, Routing Rules, Backend Targets entre outras.

Além disso, o Application Gateway oferece recursos avançados como WAF (Web Application Firewall), SSL offloading, redirecionamento baseado em caminho e afinidade de sessão, tornando-o ideal para cenários que exigem alta disponibilidade e proteção contra ameaças web.

Press enter or click to view image in full size

📦 Descrição de cada componente do diagrama

Listener (porta 80): Detecta conexões de entrada na porta especificada (ex: 80 para HTTP). É o ponto inicial onde o tráfego chega ao gateway.
Routing Rule: Define como o tráfego será roteado com base em critérios como URL, cabeçalhos ou métodos. É o cérebro da decisão de encaminhamento.
Backend Targets: Especifica os destinos finais para o tráfego, como VMs, instâncias de App Service ou containers. 🔁 Relação com Backend Pools: 1 para N — uma regra pode apontar para vários destinos.
Backend Setting: Configurações aplicadas ao tráfego, como tempo de timeout, protocolo (HTTP/HTTPS), e afinidade de sessão. 🔁 Relação com Health Probes: 1 para 1 — cada configuração tem uma sonda associada.
Backend Pools: Agrupamento lógico dos destinos (targets). Permite distribuir carga entre múltiplas instâncias. 🔁 Relação com Backend Targets: 1 para N — um pool pode conter vários destinos.
Health Probes (path:/status-0123456789abcdef)
Verifica a saúde dos destinos usando um caminho específico. Se um destino estiver inativo, ele é automaticamente removido do balanceador.

Vamos apresentar algumas telas de configuração e destacar pontos de atenção no Application Gateway (AppGW).

Um detalhe importante que acabei não mencionando: à frente do Listener existe uma configuração de Frontend IP, que define se o IP do AppGW será público ou privado. Para facilitar os testes iniciais, recomendo começar com o Frontend IP público,alem disso mantenha o Listener configurado na porta 80. Isso evita complicações com certificados SSL durante os testes.

Observe a imagem abaixo: o Frontend IP está corretamente vinculado ao Listener1, como indicado. Essa associação é essencial para garantir que o tráfego seja direcionado corretamente, conforme a configuração do IP público ou privado definida no Frontend.

Press enter or click to view image in full size

O Listener1, configurado na porta 80, está associado à Rule1, que define como o tráfego será roteado para o backend correspondente.

Press enter or click to view image in full size

A Rule1 está associada às configurações de Backend Settings, que definem como o tráfego será encaminhado para os recursos de backend — incluindo o pool de servidores, o protocolo, a porta e os critérios de saúde.

Press enter or click to view image in full size

As Backend Settings do Application Gateway incluem configurações importantes, como “Pick host name from backend target” e a associação a um Custom Probe.

Por padrão, o AppGW encaminha ao backend o mesmo cabeçalho HTTP Host recebido do cliente. No entanto, se o serviço ou aplicação no backend exigir um valor específico para o cabeçalho Host, é possível sobrescrevê-lo utilizando essa configuração. Com isso, o Application Gateway passa a usar o host do backend para resolver o balanceamento e validar o probe de integridade, garantindo compatibilidade com serviços que dependem de hostname específico para funcionar corretamente.

Press enter or click to view image in full size

Perceba que o Health Probe também está vinculado às Backend Settings, e utiliza a configuração “Pick host name from backend settings”.

Essa associação é fundamental para garantir que o probe de integridade seja executado corretamente, especialmente em cenários onde o backend exige um cabeçalho Host específico. Ao ativar essa opção, o Application Gateway passa a usar o hostname do backend tanto para o roteamento quanto para a validação do probe, assegurando compatibilidade com serviços que dependem dessa configuração.

Press enter or click to view image in full size

Esse endereço /status-0123456789abcdef é o endereço de sondagem do apim (helth cehck) do APIM

Voltando à Rule1, podemos observar que ela também define o Backend Target, que neste caso aponta para o serviço de backend do APIM (Azure API Management).

Essa configuração é essencial para garantir que o tráfego roteado pelo Application Gateway seja direcionado corretamente ao endpoint do APIM, respeitando as regras de roteamento, cabeçalhos e probes definidos nas Backend Settings.

Press enter or click to view image in full size

Nos Backend Pools, temos o pool de backend do APIM, que contém duas instâncias do serviço Azure API Management. Essa configuração permite distribuir o tráfego entre as instâncias, garantindo alta disponibilidade e escalabilidade para os serviços expostos via AppGW.

Press enter or click to view image in full size

Do lado do APIM

Para observar o processo de balanceamento entre instâncias do APIM (por exemplo, APIM A e APIM B), podemos criar uma API de mock que responda de forma simples, identificando qual instância está respondendo.

Principais Objetos do APIM

Políticas: São regras aplicadas às requisições HTTP, permitindo manipulações como transformação de payloads, controle de acesso, limitação de chamadas (rate limiting), entre outras.
API: Representa um conjunto de operações agrupadas sob um único endpoint. Cada API pode conter múltiplas operações.
Operações: São as ações HTTP específicas, como os verbos GET, POST, PUT, DELETE, etc. Cada operação define o comportamento de uma rota dentro da API.

Como criar um mock no Azure API Management (APIM)

Adicionar uma nova API

Acesse o menu lateral e clique em “Add API”.
Selecione a opção para criar uma API manualmente.
Na caixa de diálogo exibida, preencha os dados necessários (nome, URL base, etc.).

eu criei uma APIA, com sufixo apim

Press enter or click to view image in full size

Definir o response da operação

Clique em “add operation” e preencha o verbo como get a url como /moq
Após criar a operação desejada, clique na aba “Responses”.
Clique em “Add response” e selecione o código 200.
Em Content type, escolha application/json.
No campo Sample, insira um JSON de exemplo para identificar a instância, como:

JSON

{
"name": "APIMA"
}

Press enter or click to view image in full size

Adicionar a política de mock

Vá para a aba “Design” da operação.
Na seção Inbound processing, clique em “Add policy”.
Selecione a política “Mock response”.

Verificação

Após salvar, o pipeline da requisição exibirá uma tarja amarela, indicando que o mock está ativo.

Press enter or click to view image in full size

Repita esse processo para a instância dois. Agora já podemos testar o balanceamento de carga pelo Application Gateway

Press enter or click to view image in full size

Sincronização das Instâncias com o API OPS

Conforme mencionado no início deste artigo, a arquitetura “by the book” foi projetada para utilizar o recurso nativo de multi-região do Azure API Management (APIM), o que elimina a necessidade de esforços adicionais para sincronizar configurações entre instâncias.

No entanto, ao optarmos por manter duas instâncias separadas na mesma região, com o objetivo de obter os benefícios citados anteriormente, passamos a ter o desafio de manter ambas sincronizadas — ou seja, com as mesmas APIs, endpoints e políticas.

Para atender a essa necessidade de sincronização, utilizaremos o API Ops, que automatiza o processo de publicação e atualização das configurações entre as instâncias, garantindo consistência e reduzindo o risco de divergências operacionais.

Press enter or click to view image in full size

Resumo do Fluxo de API Ops para Sincronização com o APIM

Press enter or click to view image in full size

Operadores de API executam o pipeline de extração para sincronizar o repositório Git com a instância do API Management, populando o repositório com os objetos no formato necessário.
Se houver alterações detectadas na instância do APIM, é criado um Pull Request (PR) para revisão. Após aprovação, os operadores fazem o merge das mudanças no repositório.
Desenvolvedores de API clonam o repositório, criam uma branch e definem as APIs usando especificações OpenAPI ou ferramentas de sua preferência.
Quando um desenvolvedor envia alterações para o repositório, um novo PR é gerado para revisão.
O PR pode ser aprovado automaticamente ou revisado manualmente, conforme o nível de controle exigido.
Após a aprovação e o merge, o pipeline de publicação implanta as alterações na instância do API Management.
Os operadores também podem criar ou modificar políticas, diagnósticos, produtos e outros objetos relevantes, e então comitar essas alterações.
Após o merge, o pipeline publica as mudanças usando o processo de definição de APIs.

Conclusão

A adoção de uma arquitetura com App Gateway à frente de múltiplos APIMs, integrada com Akamai WAF, Azure Functions, Key Vault e sistemas legados, oferece uma solução robusta, segura e altamente disponível. Essa abordagem não apenas melhora a experiência do usuário, mas também reduz riscos operacionais e facilita a evolução contínua da plataforma.

Referencias

AKS - Problemas de desempenho do NGINX Ingress Controller Gerenciado

ClaudioGodoy — Fri, 05 Sep 2025 13:44:38 GMT

O NGINX ingress controller gerenciado é um complemento de roteamento que permite direcionar tráfego HTTP e HTTPS para aplicações executando em um cluster Azure Kubernetes Service (AKS).

Em problemas relacionados à performance, o sistema de roteamento pode ser a causa raiz. Este artigo fornece um guia passo a passo para solucionar problemas de performance do NGINX ingress controller.

Pré-requisitos

Antes de começar, certifique-se de ter as seguintes ferramentas instaladas:

Kubernetes CLI (kubectl): Use o Azure CLI para instalar executando o comando az aks install-cli.

Sintomas Comuns

Sintoma	Descrição
Erros de Gateway HTTP	Códigos de erro como 502, 504 podem indicar um problema de exaustão do NGINX.
Alta Diferença no Tempo de Resposta	Diferença significativa entre o tempo de resposta do seu serviço e o tempo de resposta fim a fim. Existe uma latência comum adicionada pelo NGINX, mas quando é muito grande, pode indicar exaustão do NGINX.

Passo 1: Verifique o Comportamento do HPA

A razão mais comum para problemas de performance no NGINX é exaustão de CPU. Durante picos de carga no sistema, uma boa abordagem é observar o comportamento do HPA. Por padrão, o plugin de roteamento cria um namespace chamado app-routing-system.

Obtenha o nome do HPA:
```
 kubectl get hpa -n app-routing-system
```

Observe o comportamento do HPA:

 kubectl get hpa <HPA_NAME> -n app-routing-system -w

Avalie o resultado:

 $ kubectl get hpa <HPA_NAME> -n app-routing-system -w

 NAME    REFERENCE          TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
 nginx   Deployment/nginx   cpu: 83%/70%   1         2         1          77m
 nginx   Deployment/nginx   cpu: 83%/70%   1         2         2          77m
 nginx   Deployment/nginx   cpu: 106%/70%        1         2         2          79m
 nginx   Deployment/nginx   cpu: 133%/70%        1         2         2          80m

A coluna TARGETS mostra o limite de CPU onde o HPA irá acionar o aumento de replicas. Você deve interpretar esse comportamento. Existem algumas possibilidades:

O HPA atingiu o número máximo de pods.
Não há nodes disponíveis para agendar os pods.

Passo 2: Procure por Pods em Estado Pending

Se no passo anterior você viu que o NGINX HPA não atingiu o número máximo de pods, o kube-scheduler pode estar tendo dificuldades para encontrar nodes disponíveis para agendar os pods do NGINX.

Obtenha Pods em Pending:

 kubectl get pod --field-selector=status.phase=Pending -n app-routing-system

Se houver pods em Pending, o cluster provavelmente está enfrentando um problema de exaustão de recursos. Nesse caso, consulte Solucionar erros do agendador de pods no Azure Kubernetes Service.

Passo 3: Verifique se Existem Limites Aplicados ao Deployment do NGINX

Qualquer configuração incorreta nos limites ou requests de recursos do NGINX pode fazer com que o HPA escale mais pods do que o necessário.

Descreva o Deployment do NGINX:

 kubectl describe deploy nginx -n app-routing-system

Verifique Requests e Limits:

 $ kubectl describe deploy nginx -n app-routing-system
 Name:                   nginx
 ....
 Selector:               app=nginx
 ....
 Pod Template:
 ....
 Containers:
 controller:
     ...
     Limits:
     ...
     Requests:
     ...

Solução

Por padrão, a versão atual do NGINX ingress controller não define limites para os pods do NGINX e define requests 500m de CPU, que é usado pelo HPA. Não é recomendado alterar esses valores diretamente na definição do deployment.

Se o seu HPA está atingindo o número máximo de pods e os requests e limits do deployment permanecem inalterados, você deve configurar o custom resource definition (CRD) chamado NginxIngressController.

Opções de Configuração

As opções de configuração abaixo impactam diretamente o comportamento do HPA:

Propriedade	Tipo	Descrição	Obrigatório	Padrão
`scaling`	objeto	Configuração para escalonamento do controller. Contém propriedades aninhadas.	Não	-
`maxReplicas`	inteiro	Limite superior de réplicas.	Não	100
`minReplicas`	inteiro	Limite inferior de réplicas.	Não	2
`threshold`	string	Limite de escalonamento definindo quão agressivo será o scaling. Opções: `rapid`, `steady`, `balanced`.	Não	balanced

Como Aplicar a Configuração

Siga os passos abaixo para aplicar a configuração:

Edite o CRD NginxIngressController:

 kubectl edit nginxingresscontroller -n app-routing-system

Adicione ou modifique a configuração de scaling:

 spec:
   scaling:
     maxReplicas: 10
     minReplicas: 2
     threshold: "balanced"

Salve e saia do editor para aplicar as alterações.
Verifique as alterações:
```
 kubectl get hpa -n app-routing-system
```

O HPA será atualizado automaticamente com base na nova configuração, e o NGINX ingress controller irá escalar conforme os parâmetros especificados.

Recursos adicionais

Zonas de Disponibilidade no Azure: Entendendo a Diferença entre Zonas Lógicas e Físicas

fabiodasilva — Tue, 26 Aug 2025 13:17:42 GMT

O que é o mapeamento de zonas do Azure (Zona Lógica vs Zona Física)

No Azure, as Zonas de Disponibilidade (AZs) são agrupamentos de datacenters fisicamente separados dentros de uma mesma região. Cada zona possui infraestrutura independente - energia, refrigeração e rede - garantindo alta disponibilidade e resiliência.

Porém, há uma distinção entre:

Tipo de Zona	Definição
Zona Lógica	Identificador exibido no portal do Azure (AZ1, AZ2, AZ3).
Zona Física	Grupo real de datacenters. O mapeamento entre lógica e física varia por assinatura

O mapeamento entre zonas lógicas e físicas não é fixo. Isso significa que:

AZ1 na assinatura A pode ser fisicamente igual à AZ3 na assinatura B.
Sem verificação, você pode estar executando produção e DR na mesma infraestrutura física, anulando os benefícios da separação.

Esse comportamento é intencional e inspirado no modelo da AWS, que também não garante consistência entre zonas lógicas em diferentes contas.

Qual o objetivo desse design?
A motivação por trás desse mapeamento dinâmico é:

Distribuir a carga de consumo de forma mais eficiente entre os datacenters.
Evitar hotspots e garantir resiliência operacional.
Permitir flexibilidade de alocação conforme a capacidade física disponível.

Esse modelo ajuda a balancear o uso da infraestrutura global, sem expor diretamente a topologia física aos clientes — o que também reforça a segurança e abstração da plataforma.

Essa distinção é essencial: a zona lógica AZ1 em uma assinatura pode, na prática, ser a mesma zona física que a AZ3 em outra. Sem uma verificação adequada, o cliente pode acabar executando cargas de produção e de DR (Disaster Recovery) na mesma infraestrutura física, o que anula os benefícios esperados da separação entre zonas.

Exemplo prático de risco

Vamos considerar o seguinte cenário de um cliente:

Produção: AZ1 e AZ2 em uma assinatura A
DR: AZ3 em outra assinatura B, na mesma região

O cliente acredita estar distribuindo suas cargas entre três zonas distintas. No entanto, ao verificar o mapeamento real, encontra a seguinte saída:

[

{ "logicalZone": "1", "physicalZone": "brazilsouth-az3" },

{ "logicalZone": "2", "physicalZone": "brazilsouth-az1" },

{ "logicalZone": "3", "physicalZone": "brazilsouth-az2" }

]

Neste exemplo, a AZ3 lógica está mapeada para a AZ2 física, que já está sendo usada na produção. Ou seja, não há separação física real.

Como verificar o mapeamento de zonas?

Para evitar esse problema, é essencial verificar o mapeamento entre zonas lógicas e físicas em cada assinatura. Use o seguinte comando via Azure CLI:

az rest --method get \

--uri "/subscriptions/<subscription-id>/locations?api-version=2022-12-01" \

--query "value[?name=='<region-name>'].{displayName: displayName,name: name,availabilityZoneMappings: availabilityZoneMappings }" \

-o json

Substitua <subscription-id> e <region-name> (ex: brazilsouth) conforme necessário.

Veja abaixo um exemplo de saída obtida no meu ambiente de laboratório, onde tenho duas assinaturas. Vou executar o mapeamento de zonas entre elas para a região Brazil South.

Na primeira subscription 1 temos o seguinte mapeamento.

Zona lógica: 1 – Zona Física: brazilsouth-az1
Zona lógica: 2 – Zona Física: brazilsouth-az2
Zona lógica: 3 – Zona Física: brazilsouth-az3

Na segunda subscription 2 temos o seguinte mapeamento.

Zona lógica: 1 – Zona Física: brazilsouth-az3
Zona lógica: 2 – Zona Física: brazilsouth-az1
Zona lógica: 3 – Zona Física: brazilsouth-az2

Resumindo: Se minha estratégia de DR envolve o uso das zonas lógicas 1 e 2 na subscription 1, pois elas estão mapeadas fisicamente para as zonas AZ1 e AZ2, então, na subscription 2 destinada ao DR, devo utilizar a zona lógica 1 — já que, nessa assinatura, ela está mapeada fisicamente para a AZ3.

Boas práticas

Sempre verifique o mapeamento entre zonas lógicas e físicas antes de definir sua estratégia de DR.
Evite assumir que AZ1, AZ2 e AZ3 representam zonas físicas distintas entre diferentes assinaturas.
Considere utilizar regiões diferentes para DR quando a separação física for um requisito crítico.
Documente e compartilhe o mapeamento com sua equipe de arquitetura e operações para garantir alinhamento e evitar riscos.

Referência oficial

Para mais detalhes, consulte a documentação oficial da Microsoft:

https://learn.microsoft.com/en-us/azure/availability-zones/az-overview

Comparing AWS and Azure regions and zones - Azure Architecture Center | Microsoft Learn

Anatomia de um serviço ASP.NET Core

ClaudioGodoy — Mon, 30 Jun 2025 00:39:17 GMT

O ecossistema do .NET é uma plataforma de desenvolvimento de software criada pela Microsoft. Ele inclui ferramentas, bibliotecas e frameworks para a criação de aplicações desktop, web, mobile, serviços e muito mais. Desde sua unificação, o .NET Core e o .NET Framework passaram a ser conhecidos apenas como .NET.

O .NET SDK (Software Development Kit) fornece as ferramentas necessárias para criar, compilar, depurar e publicar aplicações .NET. Ele inclui o compilador C#), bibliotecas de classes como ASP.NET Core e Entity Framework Core, além de utilitários como o MSBuild.

O ambiente de execução .NET (Common Language Runtime ou CLR) gerencia a execução de programas .NET, oferecendo serviços como gerenciamento de memória, coleta de lixo e controle de exceções.

Tipos de Aplicações .NET

Web API: Aplicações que fornecem serviços e endpoints RESTful para interação com clientes.
Razor com SSR (Server-Side Rendering): Ideal para aplicações que precisam de SEO e renderização eficiente.
Console Application: Útil para tarefas automatizadas e scripts.
MAUI (Multi-platform App UI): Permite o desenvolvimento de aplicativos multiplataforma.
Libraries (.NET Standard/Core Libraries): Conjuntos de código reutilizável para funcionalidades específicas.

ASP.NET Core WebAPI

Uma WebAPI segue o estilo arquitetural REST (Representational State Transfer), utilizando o protocolo HTTP para comunicação.

Protocolo HTTP: Define métodos como GET, POST, PUT e DELETE para manipulação de recursos.
REST API: Utiliza URIs para identificar recursos e métodos HTTP para operações CRUD.
Modelo de Richardson: Estabelece níveis de maturidade em APIs REST.

O foco principal do artigo está na WebAPI, devido à sua relevância na criação de serviços modernos.

Demo

Para criar uma webapi, com o dotnet sdk instalado, rode o comando:

dotnet new webapi -n MinhaApi

Após executar o comando, será gerada uma estrutura básica de projeto contendo:

Controllers: Arquivos para definir os endpoints da API.
Program.cs: Configuração inicial da aplicação.
appsettings.json: Arquivo de configuração.

Você pode iniciar o servidor com:

cd MinhaApi

dotnet run

Ciclo de vida de uma requisição HTTP em aplicações ASP.NET Core

Server

Uma aplicação ASP.NET Core é executada com uma implementação de servidor HTTP in-process. Esse servidor escuta por requisições HTTP e as disponibiliza para a aplicação através do HttpContext.

As responsabilidades do servidor incluem:

Escutar em uma porta específica para receber solicitações HTTP.
Processar as requisições e encaminhá-las para os middlewares configurados.

Middlewares

Os middlewares são componentes que processam requisições e respostas. Eles podem:

Autenticar usuários.
Registrar logs.
Manipular erros.

Exemplo de configuração de middleware:

app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    endpoints.MapControllers();
});

Controllers

Os controllers são responsáveis por definir os endpoints da API. Um exemplo básico:

[ApiController]
[Route("api/[controller]")]
public class MinhaController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        return Ok("Hello World");
    }
}

Resumo

O ciclo de vida de uma requisição HTTP envolve o servidor, middlewares e controllers, garantindo que cada etapa seja processada de forma eficiente e escalável.

Conclusão

O ASP.NET Core é uma plataforma poderosa e flexível que permite o desenvolvimento de aplicações modernas, robustas e escaláveis. Desde sua arquitetura modular com middlewares até a configuração do pipeline de requisições, ele fornece ferramentas essenciais para criar soluções otimizadas e adaptadas a diferentes necessidades, seja para web, APIs RESTful ou sistemas distribuídos.

Ao longo deste artigo, exploramos desde os fundamentos do .NET e a ampla gama de tipos de aplicativos que podem ser criados, até os detalhes do ciclo de vida de uma requisição HTTP e a importância dos servidores Kestrel e HTTP.sys. Com uma compreensão clara do pipeline de requisições e dos middlewares, é possível projetar sistemas que não apenas atendem aos requisitos técnicos, mas também oferecem excelente desempenho e uma experiência de usuário consistente.

Dominar o ecossistema do ASP.NET Core é essencial para desenvolvedores que desejam se destacar no desenvolvimento de serviços e aplicações web de alto desempenho.

Participe da 2ª edição do GitHub Copilot Global Bootcamp

cynthiazanoni — Fri, 06 Jun 2025 14:19:57 GMT

O GitHub Copilot Global Bootcamp começou em fevereiro como uma jornada totalmente virtual de aprendizado — e foi um sucesso. Mais de 60 mil desenvolvedores participaram da primeira edição, em vários idiomas e regiões. Agora, estamos empolgados em lançar a segunda edição — maior e melhor — com workshops virtuais e presenciais, organizados por comunidades de tecnologia ao redor do mundo.

Essa nova edição chega logo após os anúncios do Microsoft Build 2025, onde as equipes do GitHub e do Visual Studio Code revelaram novidades empolgantes:

A extensão GitHub Copilot Chat será open source, reforçando a transparência e a colaboração.
A IA está sendo profundamente integrada ao Visual Studio Code, que agora está evoluindo para um editor de IA de código aberto.
Novas APIs e ferramentas estão tornando mais fácil do que nunca construir com IA e LLMs.

Este bootcamp é a sua oportunidade de explorar essas novas ferramentas, entender como usar o GitHub Copilot de forma eficaz e fazer parte da crescente conversa global sobre IA no desenvolvimento de software.

👩‍💻 Quem pode participar?

Seja você um(a) desenvolvedor(a) iniciante, estudante ou profissional experiente em tecnologia, este bootcamp foi feito para você. Você aprenderá casos de uso práticos do GitHub Copilot e como aumentar sua produtividade usando IA — em um formato acessível e prático.

Participe da edição virtual

Não importa onde você esteja, é possível participar online e aprender com a gente:

Português (Brasil – UTC -3)

24 de junho, 19h: Boas práticas para dominar o GitHub Copilot Chat
25 de junho, 19h: Integrações práticas com MCP Servers no VS Code e GitHub Copilot

Aprenda na sua cidade!

Estamos em parceria com comunidades locais de desenvolvedores para levar workshops presenciais a diversas cidades ao redor do mundo.

Sessões presenciais confirmadas no Brasil:

Data	Cidade	Inscrições
17 de Junho	Brasília, Brasil	Registre-se agora!
17 de Junho	Pato de Minas, Brasil	Registre-se agora!
21 de Junho	Mogi das Cruzes, Brasil	Registre-se agora!
26 de Junho	Recife, Brasil	Registre-se agora!
27 de Junho	Rio de Janeiro, Brasil	Registre-se agora!

O Microsoft Applied Skills é um programa de credenciamento criado para validar sua capacidade de realizar tarefas técnicas específicas do mundo real. Diferente das certificações tradicionais que costumam abranger cargos amplos, o Applied Skills foca em habilidades práticas e cenários reais, diretamente aplicáveis a desafios de negócios.

E a melhor parte? É totalmente gratuito!
Você demonstra suas habilidades por meio de avaliações interativas, baseadas em tarefas, em um ambiente simulado — sem perguntas de múltipla escolha, apenas trabalho real.

Uma das adições mais recentes é o Applied Skill do GitHub Copilot, que comprova sua habilidade de aproveitar a IA para aumentar a produtividade no desenvolvimento de software e melhorar a qualidade do código:

Acelere o desenvolvimento de aplicativos usando o GitHub Copilot.

Crie seu Primeiro Agente de IA com JavaScript e Azure AI Agent Service!

Glaucia_Lemos — Wed, 07 May 2025 17:37:50 GMT

Introdução: A Era dos Agentes de IA em JavaScript

Durante o AI Agents Hackathon, uma das sessões mais aguardadas foi apresentada por Wassim Chegham, que é Senior AI Developer Advocate em JavaScript na Microsoft. O tema? "Como Criar seu Primeiro Agente de IA com JavaScript e Azure AI Agent Service?" - uma ferramenta poderosa e pensada para desenvolvedores modernos que desejam criar aplicações AI-first com segurança, escabilidade e produtividade.

E, nesse artigo, vamos explorar os principais pontos abordados na sessão, com um foco especial em como você pode criar seu próprio agente de IA utilizando JavaScript e o Azure AI Agent Service.

A proposta do vídeo é clara: mostrar o passo a passo de como qualquer pessoa pode criar agentes de IA com JavaScript e TypeScript, utilizando Azure AI Foundry, e explicar todos os conceitos essenciais para dominar esse novo paradigma de desenvolvimento.

Se você perdeu a sessão, não se preocupe! Você pode assistir a gravação:

O que são Agentes de IA?

Wassim inicia a sessão com um panorama histórico: desde os chatbots tradicionais até os agentes inteligentes e autônomos que conhecemos hoje. Ele destacou:

Agentes baseados em LLMs (Large Language Models) que entendem a linguagem natural.
Agentes com ferramentas (tools) que executam ações no mundo real, como chamadas de API, buscas, execução de código etc.
Sistemas multiagentes, que coordenam vários agentes para resolver tarefas complexas.

O diferencial do Azure AI Agent Service é simplificar tudo isso, oferecendo uma plataforma gerenciada que cuida da orquestração, segurança, rastreamento e execução dos agentes.

Arquitetura de Soluções com Azure AI Agent Service

Durante a sessão, Wassim apresentou uma visão clara da arquitetura típica de uma aplicação de agente de IA desenvolvida com JavaScript. Ele explicou que, embora seja possível ter uma interface gráfica (FrontEnd) usando frameworks como Angular ou React, isso não é obrigatório - a aplicação pode muito bem funcionar num terminal, como foi o caso das demonstrações feitas ao vivo.

No BackEnd, o foco recai sobre o uso de Node.js, que pode ser combinado com frameworks como Express.js ou Fastify para expor APIs que comunicam com os agentes. Essa camada de API atua como ponte entre o usuário e a lógica do agente, coordenando mensagens, execuções e chamadas de ferramentas.

O próprio agente é criado e gerenciado com o SDK azure/ai-projects, que fornece uma API simples e direta para registrar agentes, definir instruções, anexar ferramentas e controlar execuções. Wassim destacou o quanto essa abordagem reduz a complexidade em comparação a outros frameworks de agentes, que exigem configuração manual de estado, orquestração e controle de contexto.

Além disso, há uma camada de ferramentas integradas ao serviço que ampliam significamente as capacidades do agente. São elas:

Code Interpreter: para execução de código Python em sandbox
Function Calling: para chamadas de funções definidas pelo usuário
Azure AI Search: para buscas vetoriais e RAG (Retrieval-Augmented Generation)
Bing Search: para grounding com dados em tempo real

Todas essas ferramentas são disponibilizadas de forma plug-and-play pela infraestrutura do Azure AI Agent Service.

Toda essa arquitetura é gerenciada por uma instância do Azure AI Foundry, que centraliza o controle de modelos, ferramentas, conexões e dados, proporcionando uma base robusta, segura e escalável para criar aplicações AI-first. Wassim fez questão de frisar que o agente é o verdadeiro "cérebro" da aplicação - recebendo instruções, raciocionando sobre elas e coordenando a execução de tarefas com auxílio de ferramentas externas, tudo isso com o poucos comandos em JavaScript.

Criando seu primeiro agente: Hands-on com JavaScript

Durante a demonstração prática, Wassim conduz os participantes por todas as etapas necessárias para criar um agente de IA funcional com JavaScript, utilizando o Azure AI Agent Service. Ele começa destacando que todo o código utilizado está disponível publicamente num repositório no GitHub, o que permite que qualquer pessoa possa clonar, rodar e adaptar os exemplos para seus próprios projetos.

> Link do repositório: Azure AI Agent Service - Demonstration

A primeira etapa envolve a instalação dos pacotes essenciais. O principal deles é o SDK azure/ai-projects (pacote npm - aqui), responsável por toda a interação com o serviço de agentes. Também é necessário instalar o azure/identity, que permite autenticar de forma segura com as credenciais da Azure sem precisar lidar com chaves ou tokens diretamente — utilizando, por exemplo, o DefaultAzureCredential.

Após configurar o ambiente com as dependências, Wassim mostra como criar uma instância do cliente de agente a partir de uma string de conexão obtida no portal do Azure Foundry. Essa string é armazenada em um arquivo .env, e permite que o código se conecte de forma segura ao serviço para criar e gerenciar agentes.

Com o cliente em mãos, o próximo passo é criar o agente propriamente dito. Para isso, é necessário definir o nome, o modelo de linguagem a ser usado (como o GPT-4) e fornecer instruções claras sobre o comportamento desejado para o agente — seja para realizar cálculos, responder perguntas, interpretar dados ou interagir com ferramentas externas.

Na sequência, Wassim introduz o conceito de thread, que funciona como um espaço de conversa entre o agente e o usuário. É nesse thread que as mensagens são armazenadas, as execuções são iniciadas e o histórico de interações é mantido. Ele mostra como criar um thread, enviar uma mensagem e iniciar uma run, ou seja, uma execução do agente a partir da mensagem fornecida.

A sessão então avança para demonstrar o uso de ferramentas. No primeiro exemplo, o agente resolve uma equação simples apenas com seu conhecimento interno, sem recorrer a ferramentas externas — um exemplo clássico para mostrar como o modelo pode raciocinar com base nas instruções fornecidas. Em seguida, Wassim mostra como ativar uma chamada de função personalizada: o agente acessa uma função que retorna o uso da CPU da máquina local, demonstrando a capacidade de executar ações no ambiente do usuário.

Outro exemplo impressionante é o uso do Code Interpreter, uma ferramenta que permite executar código Python remotamente e com segurança. Wassim fornece um arquivo CSV contendo dados de vendas de carros, e o agente não só processa os dados, como também gera visualizações gráficas em tempo real.

Além disso, ele demonstra como o agente pode utilizar o Bing Grounding para buscar informações atualizadas diretamente da internet, como cotações do mercado de ações. E, por fim, mostra a integração com o Azure AI Search, onde um índice vetorial previamente carregado com informações sobre planos de saúde é consultado para responder perguntas específicas, com direito a citações precisas da fonte utilizada — um ótimo exemplo do padrão RAG (Retrieval-Augmented Generation) em ação.

Esses exemplos mostram que, mesmo com poucos comandos em JavaScript, é possível criar agentes sofisticados, capazes de interagir com dados, ferramentas e usuários de maneira fluida, segura e produtiva.

Entendendo a mecânica interna: Como um agente funciona?

Wassim explica os conceitos fundamentais do ciclo de vida de um agente:

Agent: configurado com modelo e instruções.
Thread: representa a conversa (contexto).
Run: execução de uma tarefa.
Run Steps: etapas da execução.
Tools: definidas com schemas e acionadas conforme necessário.
Events: eventos emitidos durante a execução (streaming, tool-call, resposta, erro, etc).

Além disso, ele demonstra um projeto pessoal: uma ferramenta de tracing visual para acompanhar em tempo real cada etapa do agente, o que facilita o entendimento e o debug.

Um pouco sobre as tecnologias utilizadas no projeto

Para quem está curioso sobre as tecnologias utilizadas no projeto, Wassim fez questão de destacar algumas delas:

📦 SDK utilizado
- azure/ai-projects@2.0.0-beta.4
- azure/identity para autenticação com credenciais seguras.
🔧 Ferramentas integradas
- Function Calling: executa funções com base na entrada do LLM.
- Code Interpreter: executa código Python remotamente com segurança.
- Azure AI Search: busca vetorial e full-text com RAG.
- Bing Search Grounding: informações em tempo real da web.
- File Search (em breve): busca em arquivos carregados.
⚙️ Segurança e compliance
- Autenticação sem chaves (keyless)
- Private Networking (VNet)
- Content Filtering
- Tracing e logs para evitar alucinações

Conclusão: O Futuro dos Agentes de IA com JavaScript

A sessão de Wassim Chegham no AI Agents Hackathon foi uma verdadeira aula sobre como criar agentes de IA com JavaScript e Azure AI Agent Service. Ele não só apresentou os conceitos fundamentais, mas também mostrou na prática como é fácil e rápido desenvolver aplicações inteligentes utilizando essa nova abordagem.

Novamente se você perdeu a sessão, não se preocupe! Você pode assistir a gravação aqui.

E, claro , não deixe de conferir o repositório no GitHub com todos os exemplos e códigos utilizados durante a apresentação: Azure AI Agent Service - Demonstration.

E, no final, Wassim deixou uma mensagem clara: o futuro dos agentes de IA é promissor, e com as ferramentas certas, qualquer desenvolvedor pode criar soluções inovadoras e impactantes. Então, não perca tempo! Comece a explorar o Azure AI Agent Service e crie seu próprio agente de IA hoje mesmo!

Links úteis

Azure AI Agent Service: Documentação oficial do serviço de agentes de IA da Azure.
Azure AI Foundry: Plataforma para criar e gerenciar agentes de IA.
Azure AI Agent Service - Demonstration: Repositório GitHub com exemplos e códigos utilizados na sessão.
AI Agents Hackathon: Evento que reuniu desenvolvedores para explorar o potencial dos agentes de IA.
Wassim Chegham: LinkedIn do apresentador da sessão.
Azure AI Foundry - Getting Started: Guia para começar a usar o Azure AI Foundry.
Azure AI Agent Service - Quickstart: Tutorial rápido para criar seu primeiro agente de IA.
Azure AI Agent Service - Tools: Documentação sobre as ferramentas disponíveis no serviço de agentes de IA.
Azure AI Agent Service - Function Calling: Documentação sobre chamadas de função no serviço de agentes de IA.
Azure AI Agent Service - Code Interpreter: Documentação sobre o interpretador de código no serviço de agentes de IA.
Azure AI Agent Service - Azure AI Search: Documentação sobre o Azure AI Search no serviço de agentes de IA.
Azure AI Agent Service - Bing Search: Documentação sobre o Bing Search no serviço de agentes de IA.

Conectando o Azure Vmware Solution (AVS) com VPN Site to Site em topologia Hub Spoke.

LeandroBarbosa — Mon, 05 May 2025 14:46:04 GMT

A conexão de VPN entre AVS e o ambiente On-premises na maioria das vezes é realizada através do Virtual WAN, conforme descrito em: https://learn.microsoft.com/en-us/azure/azure-vmware/configure-site-to-site-vpn-gateway.

Contudo, caso necessário utilizar em uma topologia Hub-Spoke, existem componentes adicionais que devem ser considerados para permitir o trânsito entre o ExpressRoute do AVS e o VPN Gateway, bem como a propagação das rotas para o ambiente On-premises, assim como é feito por padrão com o Virtual WAN.

Nesta topologia, o Azure Route Server deve ser integrado para habilitar esse trânsito (propagação de rotas)

O objetivo deste artigo é demonstrar em um ambiente de laboratório como conectar um ambiente On-premises com o Azure VMware Solution (AVS) através de uma VPN Site-to-Site em topologia Hub-Spoke.

Arquitetura do Laboratório com topologia Hub-Spoke.

Componentes Azure.

Vnet 10.90.0.0/16 com 3 Subnets.
- Gateway Subnet - 10.90.0.0/24
- RouteServerSubnet - 10.90.1.0/24
- VmSubnet : 10.90.2.0/24
Virtual Network Gateway - VPN
Virtual Network Gateway - Express Route
Azure Route Server
Azure Vm Linux Ubuntu

Componentes On-premises

Firewall VPN PfSense - 192.168.90.0/24 , 192.168.200.0/22 , 192.168.92.0/24

Componetes Azure Vmware Solution

VMware SDDC
Circuito Express Route

*Este laboratório presume que os componentes como o Azure Vmware Solution e ambiente On-premises com Pfsense ou qualquer outro equipamento esteja presente.

1. Deploy componentes Azure

# 1. Variáveis - Altere conforme necessário RESOURCE_GROUP="rg-avs-lab" LOCATION="eastus2" VNET_NAME="vnet-avs-lab" VNET_ADDRESS_PREFIX="10.90.0.0/16" SUBNET_GATEWAY_PREFIX="10.90.0.0/24" SUBNET_ROUTE_SERVER_PREFIX="10.90.1.0/24" SUBNET_GATEWAY_NAME="GatewaySubnet" SUBNET_ROUTE_SERVER_NAME="RouteServerSubnet" EXPRESSROUTE_GW_NAME="er-avs-lab" VPN_GW_NAME="vpn-avs-lab" VPN_GW_IP1_NAME="vpn-gw-ip1" VPN_GW_IP2_NAME="vpn-gw-ip2" VPN_GW_ASN=65515 EXPRESSROUTE_IP_NAME="er-ip" LOCAL_NETWORK_GATEWAY_NAME="local-gw-avs-lab" BGP_PEER_IP="192.168.90.1" ASN_LOCAL=65503 ROUTE_SERVER_NAME="rserver-avs-lab" # Variáveis para subnet e VM SUBNET_VM_NAME="subnet-vm" SUBNET_VM_PREFIX="10.90.5.0/24" VM_NAME="vm-ubuntu" VM_ADMIN_USERNAME='azureuser' VM_ADMIN_PASSWORD='P@ssword123!' # Use um método seguro em produção VM_NIC_NAME="vm-ubuntu-nic" VM_IMAGE="Canonical:0001-com-ubuntu-server-focal:20_04-lts:latest" VM_SIZE="Standard_B2ms" # 2. Criar grupo de recursos az group create --name $RESOURCE_GROUP --location $LOCATION # 3. Criar VNet e subnets az network vnet create \ --resource-group $RESOURCE_GROUP \ --location $LOCATION \ --name $VNET_NAME \ --address-prefixes $VNET_ADDRESS_PREFIX \ --subnet-name $SUBNET_GATEWAY_NAME \ --subnet-prefix $SUBNET_GATEWAY_PREFIX az network vnet subnet create \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name $SUBNET_ROUTE_SERVER_NAME \ --address-prefix $SUBNET_ROUTE_SERVER_PREFIX # Criar subnet para a VM az network vnet subnet create \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name $SUBNET_VM_NAME \ --address-prefix $SUBNET_VM_PREFIX # 4. Criar IP público para ExpressRoute az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $EXPRESSROUTE_IP_NAME \ --sku Standard \ --allocation-method Static # 5. Criar Gateway ExpressRoute az network vnet-gateway create \ --resource-group $RESOURCE_GROUP \ --name $EXPRESSROUTE_GW_NAME \ --location $LOCATION \ --vnet $VNET_NAME \ --public-ip-addresses $EXPRESSROUTE_IP_NAME \ --gateway-type ExpressRoute \ --sku Standard # 6. Criar IPs públicos para VPN Gateway ativo-ativo az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_IP1_NAME \ --sku Standard \ --allocation-method Static az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_IP2_NAME \ --sku Standard \ --allocation-method Static # 7. Criar VPN Gateway az network vnet-gateway create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_NAME \ --location $LOCATION \ --vnet $VNET_NAME \ --public-ip-addresses $VPN_GW_IP1_NAME $VPN_GW_IP2_NAME \ --gateway-type Vpn \ --vpn-type RouteBased \ --sku VpnGw1 # Após a criação, configurar ativo-ativo e BGP az network vnet-gateway update \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_NAME \ --set activeActive=true enableBgp=true bgpSettings.asn=$VPN_GW_ASN # 8. Criar Local Network Gateway com BGP e ASN az network local-gateway create \ --resource-group $RESOURCE_GROUP \ --name $LOCAL_NETWORK_GATEWAY_NAME \ --gateway-ip-address $BGP_PEER_IP \ --local-address-prefixes "192.168.90.0/24" \ --asn $ASN_LOCAL \ --bgp-peering-address $BGP_PEER_IP \ --location $LOCATION # 9. Criar conexão VPN entre o Gateway de VPN e o Local Network Gateway az network vpn-connection create \ --resource-group $RESOURCE_GROUP \ --name vpn-s2s-connection \ --vnet-gateway1 $VPN_GW_NAME \ --local-gateway2 $LOCAL_NETWORK_GATEWAY_NAME \ --shared-key 'teste@123' \ --enable-bgp # 10. Criar NIC para a VM az network nic create \ --resource-group $RESOURCE_GROUP \ --name $VM_NIC_NAME \ --vnet-name $VNET_NAME \ --subnet $SUBNET_VM_NAME # 12. Criar VM com Ubuntu az vm create \ --resource-group $RESOURCE_GROUP \ --name $VM_NAME \ --nics $VM_NIC_NAME \ --image $VM_IMAGE \ --admin-username $VM_ADMIN_USERNAME \ --admin-password $VM_ADMIN_PASSWORD \ --size $VM_SIZE \ --location $LOCATION

2. Conectando o Express Route do AVS no VPN Gateway da Hub.

No Virtual Network Gateway de ER , adicione uma conexão

Defina o connection type como ExpressRoute

No AVS, copie o authorization key e o ExpressRoute ID

Para este cenário será utilizado o modelo de resiliência standard, o Virtual network gateway, informe um nome para conexão, insira a "authorization key" e "ExpressRoute ID" (per cirtuit URI) copiados nos passos acima e execute o deploy.

Verificando que a conexão foi estabelecida com sucesso.

Verificando as rotas na Vm de teste.

Ao verificar as rotas do Pfsense ( onprem) , é possível observar que não temos as rotas do AVS, somente da Vnet do Azure.

Para habilitar o trânsito e troca de rotas entre o Express Route do AVS e o VPN gateway precisamos inserir o Azure Route Server.

3. Deploy do Azure Route Server.

#Criar Azure Route Server #Cria Public IP para o Route Server az network public-ip create --resource-group $RESOURCE_GROUP --name routeserver-pip --sku Standard --allocation-method Static # Identifica o ID da Subnet do Route Server SUBNET_ID=$(az network vnet subnet list --resource-group $RESOURCE_GROUP --vnet-name $VNET_NAME --query "[?name=='$SUBNET_ROUTE_SERVER_NAME'].id" --output tsv) # Cria o Route Server az network routeserver create \ --resource-group $RESOURCE_GROUP \ --name $ROUTE_SERVER_NAME \ --hosted-subnet $SUBNET_ID \ --location $LOCATION \ --public-ip-address routeserver-pip

Após criado habilitamos a opção Branch-to-Branch

Podemos verificar que agora as rotas do AVS (172.30.0.0/22), agora foram propagadas para o Pfsense.

Validando acesso ao Vcenter do AVS.

Referências:

https://learn.microsoft.com/en-us/azure/route-server/overview

https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke

Migração de Aplicações Full Framework para Azure AKS e .NET Core

wdossantos — Mon, 28 Apr 2025 12:18:09 GMT

Criando e Abrindo um projeto 4.7.2

Vou criar o projeto no Visual Studio 2015, usando a versão FULL Framework .NET 4.7 escolhi o template de uma aplicação ASP.NET Web Application. Este é um projeto pequeno, desses que já nascem prontos, vai servir bem para testar as ferramentas de migração.

Depois de criado o projeto, e é importante habilitar essa versão .NET Core no Visual Studio 2022, pois precisaremos abrir o projeto nessa IDE para usar as extensões. Caso você tenha algum projeto pronto em uma versão mais antiga do dotnet então basta usá-lo

Depois de ter o projeto que vamos migrar, precisei instar o dotnet-appcat conforme essa doc Azure Migrate application and code assessment for .NET — Azure Migrate | Microsoft Learn

A documentação pende a instalando dessa extensão no visual studio Azure Migrate application and code assessment — Visual Studio Marketplace depois disso podemos abri o projeto pelo Visual Studio 2022 e já e vamos encontrar a opção re-plataform to Azure clicando com botão direito no projeto ou na solution.

Se escolhermos clicar na solution o item re-plataform to Azure disponibilizara a opção new report

Então vamos escolher para qual o tipo de computação a aplicação vai ser migrada

E como escolhemos a solution, agora vamos selecionar os projetos que queremos analisar

Um relatório com as issues será apresentado

entramos na issue e podemos ver a opção de perguntar para o copilot

Resposta do copilot para um issue especifica

E é isso basta ir resolvendo as issues, com essa ferramenta você pode verificar o código-fonte, configurações e binários da sua aplicação para encontrar oportunidades de migração para o Azure. Ele vai ajudar a identificar problemas ao mover sua aplicação para o Azure e melhora o desempenho, escalabilidade e segurança, sugerindo soluções modernas e nativas da nuvem.

NET Upgrade Assistant

Agora vamos pensar na migração do código, antigamente eu utilizava um cara chamado Portability Analyzer O .NET Portability Analyzer — .NET — .NET | Microsoft Learn, mas ele foi descontinuado e no lugar agora temos o Assistente de Atualização do .NET

Vou escolher um projeto por vez, clicando com o botão direito sobre o projeto e selecionando a opção 'update'. Esse método, em vez de gerar um relatório com as issues, tenta uma conversão direta de código. Na maioria das vezes, ele apenas faz o retarget, mas mesmo assim ajuda

No caso de um projeto WEB, a melhor opção é criar um novo projeto, pois ele vai criar uma espécie de proxy para permitir a migração paralela dos controllers

Selecionar o framework para 8

O assistente vai criar o projeto .net core, mas apenas uma casca, sem ter migrado ó código de fato

A partir disso, precisamos voltar ao projeto original onde começamos a migração e clicar novamente em 'update' usando o botão direito sobre esse projeto. Então, será possível migrar controller por controller. Cada controller migrada leva consigo suas dependência

Escolher a solution

Também podemos escolher a solution que contém vários projetos. Nesse caso, vou clicar na solution e não no projeto. Veja que agora, em vez de converter, ele me dá a opção de criar um relatório.

e então ele analisa projeto por projeto e gera as issues para serem corrigidas

aqui também consegui pedir ajuda do copilot paras as issues, e assim fica muito mais prático do que o Portability Analyzer

O Assistente de Atualização do .NET ajuda a atualizar projetos para versões mais recentes do .NET e analisa seu código para detectar e corrigir possíveis incompatibilidades. Um foco da ferramenta é ajudar a migrar um projeto do .NET Framework, .NET Core ou .NET para a versão mais recente do .NET. Você usa a extensão ou a ferramenta para atualizar projetos inteiros do .NET ou algum aspecto do projeto, como a migração de um arquivo de configuração de um tipo mais antigo para um tipo mais recente.

Podemos utilizar a CLI

upgrade-assistant --help

para iniciar o assistente use o comando

upgrade-assistant upgrade

Script para fazer vários projetos

upgrade-assistant upgrade# Defina o diretório raiz $rootDir = "..." $destDir = "..." # Obtenha todos os arquivos .csproj no diretório raiz e subdiretórios $csprojFiles = Get-ChildItem -Path $rootDir -Recurse -Filter *.csproj # Execute o comando upgrade-assistant para cada arquivo .csproj foreach ($file in $csprojFiles) { Write-Host "Executando upgrade-assistant para $($file.FullName)" Start-Process -FilePath "upgrade-assistant" -ArgumentList "upgrade $($file.FullName) --operation Inplace --targetFramework net8.0 --destination ${destDir} " -Wait }

Referência

Destaques do VS Code Live: Agent Mode Day

cynthiazanoni — Tue, 22 Apr 2025 19:04:13 GMT

🎙️ Palestrantes: Olivia McVicker, Cassidy Williams, Burke Holland, Harald Kirschner, Toby Padilla, Rob Lourens, Tim Rogers, James Montemagno, Don Jayamanne, Brigit Murtaugh, Chris Harrison.

O que é o Agent Mode?

O Agent Mode no VS Code representa um avanço além da tradicional sugestão de código por IA. Em vez de apenas sugerir trechos de código, o Agent Mode permite que a IA:

Escreva, edite e itere sobre o código
Execute comandos no terminal de forma autônoma
Corrija seus próprios erros durante o fluxo de trabalho
Interaja com ferramentas externas, APIs e serviços

Isso cria um parceiro de codificação mais dinâmico e “agente”, capaz de automatizar tarefas complexas, reduzir intervenções manuais e manter o desenvolvedor no fluxo. O Agent Mode está disponível diretamente no VS Code e se integra perfeitamente ao GitHub Copilot, tornando recursos avançados de IA acessíveis a desenvolvedores de todos os níveis.

1. Model Context Protocol (MCP)

O MCP é um protocolo aberto que padroniza como aplicações fornecem contexto para Modelos de Linguagem de Grande Escala (LLMs). Ele serve como uma ponte, permitindo que agentes de IA no VS Code se conectem de forma segura a um vasto ecossistema de ferramentas, APIs e recursos internos — muito além do que está disponível nativamente.

Principais pontos sobre o MCP:

Abordagem de ecossistema: permite conectar Copilot e outros agentes a tudo que for necessário — documentação interna, bancos de dados, ferramentas de design como Figma, etc.
Aberto e extensível: qualquer pessoa pode criar e compartilhar novas integrações, com milhares de servidores MCP já disponíveis.
Encadeamento de ferramentas: servidores MCP podem ser combinados, permitindo que a IA automatize fluxos de trabalho que envolvem múltiplas ferramentas.
Seguro e em evolução: o protocolo está evoluindo para suportar autenticação mais segura e facilitar a descoberta e instalação de integrações.

2. Next Edit Suggestions (NES)

O Next Edit Suggestions (NES) é um recurso projetado para aprimorar a experiência de edição, oferecendo recomendações contextuais para mudanças no código. O NES auxilia desenvolvedores sugerindo edições relevantes com base no contexto atual, apoiando tarefas como refatoração, correção de bugs e adição de funcionalidades. Ele permite aceitar, desfazer ou iterar rapidamente sobre mudanças sugeridas pela IA, mantendo o controle total sobre o código.

3. Bring Your Own Key (BYOK): Integração de Modelos de IA Personalizados

O BYOK permite que usuários conectem suas próprias chaves de API para modelos de IA personalizados, incluindo OpenAI, Anthropic ou até modelos locais. Com o BYOK, desenvolvedores podem escolher entre vários modelos, integrar soluções locais ou em nuvem por motivos de privacidade, custo ou desempenho, e adaptar a experiência da IA às suas necessidades específicas.

4. O Futuro Agente

Uma prévia do “Project Padawan” mostrou que fluxos de trabalho agentes poderão rodar de forma assíncrona na nuvem. Será possível delegar tarefas ao Copilot (como resolver issues do GitHub), que criará pull requests, executará testes e iterará sobre feedbacks de forma autônoma, enquanto o desenvolvedor foca em outras atividades.

GitHub Copilot Skills Challenge

Quer aprender e experimentar o Agent Mode do GitHub Copilot enquanto conquista um Selo Digital? Participe do GitHub Copilot Skills Challenge — uma experiência prática de aprendizado no Microsoft Learn, onde você construirá um aplicativo Python usando o Agent Mode por meio de um tutorial guiado. Complete o desafio até 30 de abril de 2025 para ganhar seu selo!

Confira as regras oficiais: https://aka.ms/csc/terms
Inscreva-se no Desafio: https://aka.ms/csc/githubcopilot
Solicite seu selo em: https://aka.ms/getyourbadge

Como começar

Ative o Agent Mode — disponível nas versões estável e insiders do VS Code — para experimentar esses recursos avançados de IA. Explore integrações MCP navegando pela lista de servidores ou criando o seu próprio com os SDKs disponíveis.

Quer ver essas funcionalidades em ação? Assista ao stream completo para demonstrações ao vivo, dicas de especialistas e marque a data para o próximo episódio da nossa série VS Code Live: https://aka.ms/VSCode/Live

Happy coding!