Você já construiu alertas inteligentes, automatizou runbooks de resposta a incidentes, definiu SLIs, SLOs e Error Budgets e validou resiliência com Engenharia de Caos. Mas quando chega uma ligação de madrugada dizendo que o sistema está fora, e metade da sua infraestrutura está no Azure e a outra metade na AWS, a pergunta mais urgente não é "qual cloud falhou?", mas sim: "como investigar as duas ao mesmo tempo, com velocidade e contexto unificado?"

Essa é a realidade de quem opera arquiteturas multi-cloud em produção. E é exatamente o problema que o Azure SRE Agent resolve agora com a integração oficial ao MCP Server da AWS – permitindo que um único agente de IA conduza investigações cross-cloud, consulte documentação, execute APIs da AWS, e até acione o AWS DevOps Agent para análise de causa raiz, tudo sem sair do contexto do Azure.

Neste artigo, vamos explorar como configurar essa integração do zero, entender a arquitetura por trás do MCP (Model Context Protocol), criar Skills especializadas para operações na AWS, e colocar em prática cenários reais de investigação que cruzam as fronteiras entre Azure e AWS.

O cenário multi-cloud é a regra, não a exceção

Antes de entrar na parte técnica, vale contextualizar por que isso importa. Segundo pesquisas recentes da Flexera e do Gartner, mais de 87% das organizações empresariais operam em cenários multi-cloud. Os motivos são variados:

O problema é que as ferramentas de observabilidade e investigação de cada cloud foram desenhadas para operar de forma isolada. O Azure Monitor não enxerga o CloudWatch. O CloudTrail não se integra nativamente com o Log Analytics. Quando um incidente cruza as fronteiras das clouds, o engenheiro de plantão precisa alternar entre consoles, correlacionar timestamps manualmente e reconstruir a cadeia de eventos sem uma visão unificada.

É aqui que o Azure SRE Agent, combinado com o protocolo MCP, muda o jogo.

O que é o Azure SRE Agent?

O Azure SRE Agent é um agente de IA gerenciado pelo Azure, projetado para auxiliar engenheiros de confiabilidade em tarefas operacionais. Ele não substitui o humano -- ele amplifica a capacidade do engenheiro, especialmente durante incidentes quando cada minuto conta.

Capacidades nativas

O SRE Agent é acessível pelo Portal do Azure e pode ser configurado com conectores que ampliam suas capacidades para além dos serviços nativos do Azure. E é exatamente essa extensibilidade via conectores que permite a integração com a AWS.

MCP: o protocolo que conecta agentes de IA a ferramentas externas

O Model Context Protocol (MCP) é um protocolo aberto que padroniza como agentes de IA se conectam a fontes de dados e ferramentas externas. Pense no MCP como uma interface universal -- semelhante ao que o USB fez para periféricos de hardware, o MCP faz para ferramentas de IA.

Como funciona

Conceitos-chave do MCP

O ponto crucial é que o MCP é agnóstico de provider. A mesma interface que o SRE Agent usa para se conectar à AWS pode ser usada para conectar a qualquer outro serviço que implemente um MCP Server -- GitHub, bancos de dados, ferramentas internas, e assim por diante.

AWS MCP Server: o que ele oferece

A AWS disponibiliza oficialmente um MCP Proxy for AWS, um servidor MCP que expõe 23 ferramentas organizadas em categorias distintas. Quando conectado ao Azure SRE Agent, ele dá acesso completo à infraestrutura AWS sem precisar sair do contexto da investigação.

Categorias de ferramentas

Arquitetura da integração

A comunicação funciona via um proxy local que o SRE Agent executa como processo filho:

O proxy lida com toda a autenticação SigV4 usando as credenciais fornecidas como variáveis de ambiente. Não é necessário nenhum deploy de infraestrutura adicional – o proxy roda localmente como um processo uvx.

Configuração passo a passo

Pré-requisitos

Antes de começar, você vai precisar de:

• Um recurso Azure SRE Agent já implantado no Azure
• Uma conta AWS com acesso ao console IAM
• O gerenciador de pacotes uv (docs.astral.sh/uv) instalado no host do SRE Agent
• Permissões IAM: aws-mcp:InvokeMcp, aws-mcp:CallReadOnlyTool e, opcionalmente, aws-mcp:CallReadWriteTool

Passo 1: Criar um usuário IAM dedicado na AWS

A primeira etapa é criar um usuário IAM específico para o SRE Agent. Nunca reutilize credenciais pessoais -- crie um usuário dedicado para facilitar a gestão de permissões e rotação de chaves.

1. Acesse o console IAM da AWS
2. No menu lateral, selecione Users -> Create user
3. Nome do usuário: sre-agent-mcp
4. Não marque acesso ao console (este usuário só precisa de acesso programático)
5. Selecione Attach policies directly -> Create policy

Cole o seguinte JSON no editor de políticas:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "aws-mcp:InvokeMcp",
        "aws-mcp:CallReadOnlyTool",
        "aws-mcp:CallReadWriteTool"
      ],
      "Resource": "*"
    }
  ]
}

6. Nomeie a política como SREAgentMCPAccess e crie
7. Volte à tela de criação do usuário, busque a política criada e associe
8. Finalize a criação do usuário

Passo 2: Gerar Access Keys

Após a criação do usuário:

1. Selecione o usuário sre-agent-mcp na lista
2. Vá até a aba Security credentials
3. Na seção Access keys, clique em Create access key
4. Selecione Third-party service como caso de uso
5. Copie os dois valores imediatamente:

Atenção: O Secret Access Key é exibido apenas uma vez. Se fechar a página sem copiar, será necessário criar uma nova chave. Faça download do CSV como backup e armazene-o de forma segura.

Passo 3: Adicionar permissões específicas de serviço

As permissões do MCP acima concedem acesso ao servidor MCP em si, mas cada chamada de API individual requer suas próprias permissões IAM. Para um cenário de investigação abrangente, considere adicionar:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ecs:Describe*",
        "ecs:List*",
        "eks:Describe*",
        "eks:List*",
        "lambda:Get*",
        "lambda:List*",
        "logs:GetQueryResults",
        "logs:StartQuery",
        "logs:GetLogEvents",
        "logs:DescribeLogGroups",
        "cloudwatch:GetMetricData",
        "cloudwatch:DescribeAlarms",
        "cloudtrail:LookupEvents",
        "s3:GetBucketPolicy",
        "s3:ListAllMyBuckets",
        "rds:Describe*",
        "iam:GetPolicy",
        "iam:ListRoles"
      ],
      "Resource": "*"
    }
  ]
}

Dica de segurança: Comece com permissões amplas de leitura para testes e refine progressivamente usando o princípio do menor privilégio. Use o IAM Access Analyzer para identificar permissões não utilizadas.

Passo 4: Configurar o conector no Azure SRE Agent

Agora vamos conectar tudo no Portal do Azure:

1. Navegue até o recurso Azure SRE Agent
2. Selecione Builder -> Connectors
3. Clique em Add connector
4. Selecione MCP server (User provided connector)
5. Preencha os campos:

6. Revise e clique em Add connector

Endpoints regionais disponíveis

O MCP Server da AWS opera em endpoints regionais. Escolha o que corresponde à sua infraestrutura:

Nota: Sem o argumento --metadata AWS_REGION=<region>, as operações usam us-east-1 como padrão. Você pode sempre sobrescrever a região diretamente na sua consulta.

Passo 5: Validar a conexão

Após adicionar o conector, aguarde até 30 segundos para a inicialização (o uvx baixa ~89 dependências na primeira execução). Abra um novo chat com o SRE Agent e teste:

Quais regiões AWS estão disponíveis?

Se o agente retornar a lista de regiões, a conexão está funcionando. Se houver erros de autenticação, revise as credenciais IAM configuradas no conector.

Criando Skills para operações na AWS

Com o conector ativo, o próximo passo é criar uma Skill que ensine o SRE Agent a usar as ferramentas da AWS de forma eficaz. Skills injetam conhecimento de domínio no contexto do agente -- diferente de subagentes, elas não criam um agente separado, mantendo o contexto da conversa intacto.

Por que Skills e não Subagents?

Para operações AWS dentro de investigações cross-cloud, Skills são a escolha certa.

Configuração da Skill

No Portal do Azure, navegue até Builder -> Skills -> Add skill e cole:

api_version: azuresre.ai/v1
kind: SkillConfiguration
metadata:
  owner: sua-equipe@empresa.com
  version: "1.0.0"
spec:
  name: aws_infrastructure_operations
  display_name: AWS Infrastructure & Operations

  description: |
    Operações de infraestrutura e investigação na AWS: EC2, EKS, Lambda,
    S3, RDS, CloudWatch, CloudTrail, IAM, VPC. Inclui integração com
    AWS DevOps Agent para investigação de incidentes, análise de causa
    raiz e recomendações de remediação.

  instructions: |
    ## Visão Geral
    O AWS MCP Server fornece acesso autenticado a serviços AWS via
    protocolo MCP. Autenticação é gerenciada automaticamente pelo proxy.

    ## Documentação
    Use aws___search_documentation para buscar em toda a documentação AWS.

    ## Execução de APIs
    Use aws___call_aws para executar chamadas autenticadas.
    O proxy cuida da assinatura SigV4 automaticamente.

    ## Agent SOPs
    Use aws___retrieve_agent_sop para encontrar workflows guiados
    seguindo princípios do AWS Well-Architected.

    ## AWS DevOps Agent
    - aws___create_investigation: iniciar investigação (assíncrona, 5-8 min)
    - aws___get_task: verificar status da investigação
    - aws___list_journal_records: ler análise de causa raiz
    - aws___list_recommendations: obter recomendações de remediação
    - aws___create_chat / aws___send_message: chat com DevOps Agent

  mcp_connectors:
    - aws-mcp

A propriedade mcp_connectors: - aws-mcp vincula a Skill ao conector que criamos anteriormente, dando ao agente o contexto necessário para usar as 23 ferramentas de forma inteligente.

Investigação cross-cloud na prática

Aqui é onde a integração realmente brilha. Vamos explorar cenários reais onde o SRE Agent opera simultaneamente nas duas clouds.

Cenário 1: Azure Function falhando ao chamar S3

Imagine que você tem uma Azure Function que processa uploads de arquivos enviando-os para um bucket S3 na AWS. O erro começa a aparecer nos logs do Application Insights:

System.Net.Http.HttpRequestException: Response status code does not indicate success: 403 (Forbidden)

No chat com o SRE Agent, você pode pedir:

Minha Azure Function "file-processor" está retornando 403 ao acessar o bucket S3
"uploads-prod" na AWS. Investigue os dois lados: verifique os logs da Function
no Application Insights e analise a bucket policy no S3.

O agente vai:

1. Lado Azure: Consultar Application Insights para ver os traces de erro, verificar se houve mudanças recentes na configuração da Function
2. Lado AWS: Usar aws___call_aws para buscar a bucket policy do S3, verificar as permissões IAM do role utilizado, e checar se houve alterações recentes via CloudTrail

Tudo em uma única conversa, com contexto cruzado.

Cenário 2: Investigação paralela com DevOps Agent

Para incidentes mais complexos, o SRE Agent pode iniciar uma investigação autônoma no AWS DevOps Agent enquanto investiga o lado Azure em paralelo.

Nosso sistema de pagamentos está falhando. O backend roda em AKS no Azure
e chama um serviço de fraude que roda em EKS na AWS. Inicie uma investigação
na AWS para o cluster EKS "fraud-detection-prod" em us-west-2 enquanto
você verifica o AKS no Azure.

O fluxo que o agente executa:

Cenário 3: Comparação de saúde multi-cloud

Para equipes que operam clusters em ambas as clouds, uma verificação rotineira pode ser tão simples quanto:

Compare a saúde do meu cluster AKS "production-aks" no Azure com
o cluster EKS "production-eks" na AWS. Verifique métricas de CPU,
memória, pods pendentes e eventos recentes em ambos.

Cenário 4: Análise de custos cruzada

Nosso gasto com compute aumentou 40% no último mês. Analise os custos
de VMs no Azure e instâncias EC2 na AWS para identificar onde está
o aumento.

AWS DevOps Agent: o poder da investigação autônoma

Uma das capacidades mais poderosas da integração é o acesso ao AWS DevOps Agent, que recentemente se tornou Generally Available (GA). Ele permite que o SRE Agent inicie investigações autônomas na infraestrutura AWS.

Ciclo de vida de uma investigação

Ferramentas disponíveis por categoria

Gerenciamento de espaços (AgentSpaces):

Investigação de incidentes:

Avaliação proativa:

Chat interativo:

Exemplo prático: investigação de Lambda com timeout

Minha Lambda function "order-processor" em us-west-2 está com timeout
intermitente. Inicie uma investigação no AWS DevOps Agent e me traga
a causa raiz com recomendações de remediação.

O SRE Agent vai:

1. Chamar aws___create_investigation com o contexto do problema
2. Aguardar 5-8 minutos (enquanto isso, pode fazer outras verificações)
3. Usar aws___list_journal_records para ler a análise completa
4. Buscar aws___list_recommendations para obter os passos de correção
5. Apresentar tudo em um relatório unificado

Troubleshooting: problemas comuns e soluções

Erros de conexão do conector

Erros em chamadas de API

Rotação de credenciais

Se encontrar problemas persistentes de autenticação:

1. Acesse o console IAM da AWS
2. Selecione o usuário sre-agent-mcp
3. Em Security credentials -> Access keys, desative ou delete a chave antiga
4. Crie uma nova access key
5. Atualize as variáveis de ambiente do conector no Portal do Azure

Boa prática: Implemente rotação automática de chaves usando AWS Secrets Manager ou integre com Azure Key Vault para gerenciamento centralizado de credenciais.

Boas práticas para operações cross-cloud

Depois de configurar a integração, algumas práticas vão garantir que você tire o máximo valor:

1. Padronize a nomenclatura

Use convenções consistentes entre as clouds para facilitar a correlação:

2. Defina SLOs cross-cloud

Estenda seus SLOs existentes para cobrir o fluxo completo:

• SLI: Latência end-to-end da requisição (Azure -> AWS -> resposta)
• SLO: 99,9% das requisições completam em menos de 2 segundos
• Error Budget: Calculado sobre o fluxo completo, não por cloud individual

3. Crie runbooks multi-cloud

Documente procedimentos que cobrem ambas as clouds para os cenários mais comuns:

## Runbook: Falha de comunicação Azure -> AWS

1. Verificar Service Health em ambas as clouds
2. Checar NSG/Security Groups na comunicação
3. Validar certificados e credenciais
4. Consultar CloudTrail e Activity Log para mudanças recentes
5. Testar conectividade de rede (traceroute, DNS)

4. Monitore o conector

Adicione monitoramento para o próprio conector MCP:

• Verifique periodicamente se o conector está com status Connected
• Configure alertas para falhas de autenticação
• Monitore a latência das chamadas cross-cloud

O que vem a seguir?

A integração do Azure SRE Agent com AWS via MCP Server é apenas o começo. O protocolo MCP é aberto e extensível -- o que significa que a mesma arquitetura pode ser usada para conectar o SRE Agent a:

• Google Cloud Platform (quando um MCP Server para GCP estiver disponível)
• Ferramentas internas (APIs proprietárias expostas via MCP)
• Bancos de dados (consultas diretas durante investigações)
• Repositórios Git (correlação com deploys e PRs)
• Ferramentas de on-call (PagerDuty, OpsGenie via MCP)

A tendência é clara: os agentes de IA para operações estão se tornando o ponto central de investigação, capazes de cruzar fronteiras entre clouds, ferramentas e sistemas -- tudo mantendo o contexto de uma conversa unificada.

Para quem opera infraestrutura multi-cloud em produção, essa integração transforma o que antes era uma investigação fragmentada entre consoles em um fluxo contínuo, inteligente e colaborativo. O engenheiro de plantão não precisa mais ser expert em cada cloud -- o SRE Agent traz o conhecimento e a capacidade de execução para onde o problema estiver.

Referências

• Announcing AWS with Azure SRE Agent (Tech Community)
• MCP Proxy for AWS (GitHub)
• AWS MCP Server Documentation
• Model Context Protocol (Specification)
• Azure SRE Agent Documentation
• AWS DevOps Agent – General Availability