Servidor AWS MCP: acesso seguro e governado à AWS para agentes de IA

Agentes de código com IA estão ficando mais capazes, mas o trabalho em AWS ainda cria um problema difícil de acesso: como permitir que um agente consulte documentação atual, entenda serviços e chame APIs da AWS sem entregar credenciais amplas e sem governança?

Esse é o problema que o AWS MCP Server tenta resolver. A AWS anunciou disponibilidade geral em 6 de maio de 2026, descrevendo o serviço como um servidor gerenciado que dá acesso seguro a serviços AWS por meio do Model Context Protocol, mantendo IAM, métricas do CloudWatch e logs do CloudTrail dentro do modelo de controle.

Resposta rápida: o que é o AWS MCP Server?

O AWS MCP Server é um servidor MCP remoto e gerenciado pela AWS que permite que agentes de IA e assistentes de código interajam com a AWS por meio de um conjunto pequeno de ferramentas. Agentes podem pesquisar documentação AWS, recuperar orientação de serviços, chamar APIs usando credenciais IAM existentes, executar workflows Python em sandbox e carregar Skills mantidas pela AWS.

Em termos simples, ele é uma ponte governada entre um agente de código e a AWS. Em vez de depender apenas do treinamento do modelo ou liberar shell local para o assistente, equipes podem encaminhar trabalho em AWS por ferramentas MCP com autenticação, autorização, documentação e observabilidade.

Por que agentes de IA precisam de melhor acesso à AWS

Agentes de IA costumam ter três problemas com AWS.

• O conhecimento fica desatualizado. Serviços, APIs, regiões e boas práticas da AWS mudam o tempo todo. Um agente pode conhecer o padrão de ontem e ignorar um novo parâmetro, serviço ou limite regional.
• Eles podem errar com confiança. Agentes podem escolher o serviço errado, ampliar IAM demais, repetir comandos com falha ou criar infraestrutura que funciona em demo mas não passa por revisão operacional.
• Acesso direto é difícil de governar. Se uma pessoa entrega credenciais locais amplas ou shell para um assistente, fica mais difícil separar ação humana de ação do agente e aplicar regras específicas.

O AWS MCP Server não elimina todo risco. Ele cria um caminho mais governável para acesso de agentes.

Como o AWS MCP Server funciona

Um fluxo típico funciona assim:

1. Uma pessoa pede a um cliente compatível com MCP para realizar uma tarefa relacionada à AWS.
2. O agente chama ferramentas expostas pelo AWS MCP Server.
3. Ferramentas de documentação recuperam informações atuais da AWS.
4. Ações de API são autenticadas com credenciais AWS existentes.
5. Serviços AWS autorizam as requisições com políticas IAM.
6. A atividade pode ser observada por métricas do CloudWatch e auditada em logs do CloudTrail.

O servidor funciona com Claude Code, Kiro, Cursor, Codex e qualquer cliente compatível com MCP. Ele está disponível em US East (N. Virginia) e Europe (Frankfurt), pode chamar APIs em qualquer Região AWS e não tem cobrança adicional além dos recursos AWS e transferência de dados usados pelos agentes.

Principais ferramentas do AWS MCP Server

O valor do AWS MCP Server vem de uma superfície de ferramentas compacta. A documentação atual do Agent Toolkit lista ferramentas importantes para pilotos:

Ferramenta	O que faz	Por que importa
aws___search_documentation	Pesquisa documentação AWS, referências de API, boas práticas, guias de serviço e Skills.	Ajuda agentes a trabalhar com informação atual, não apenas memória do modelo.
aws___read_documentation	Recupera páginas de documentação AWS e converte o conteúdo para Markdown.	Facilita o uso de documentação oficial dentro do fluxo da tarefa.
aws___retrieve_skill	Carrega Skills da AWS com workflows, contexto, boas práticas, frameworks de decisão e procedimentos.	Dá orientação para tarefas AWS em que sequência e julgamento importam.
aws___call_aws	Executa chamadas autenticadas de API AWS com validação de sintaxe e tratamento de erro.	Permite que o agente inspecione ou opere AWS dentro dos limites de IAM.
aws___run_script	Executa Python em sandbox com acesso a APIs AWS.	Apoia checagens em múltiplas etapas, chamadas paralelas, retries e inspeção cross-service sem shell local.
aws___get_tasks	Consulta tarefas longas iniciadas por ferramentas de API ou script.	Permite acompanhar operações que não terminam em uma única chamada.

Modelo de segurança: IAM ainda controla o que agentes podem fazer

O ponto mais importante é simples: o AWS MCP Server não substitui IAM.

O guia de configuração da AWS deixa um limite claro: não é necessária uma permissão IAM separada para invocar o servidor MCP. A autorização continua acontecendo no nível do serviço AWS, usando os roles e políticas IAM existentes nas credenciais em uso.

Isso é positivo para segurança, mas significa que credenciais amplas continuam perigosas. Se as credenciais disponíveis ao agente podem apagar recursos de produção, o agente pode solicitar essas ações se a política não bloquear.

Context keys de IAM para ações iniciadas por MCP

Um recurso importante de governança é o suporte a context keys globais de IAM. A AWS adiciona duas chaves às requisições feitas por servidores MCP gerenciados pela AWS:

• aws:ViaAWSMCPService: definido como true quando a requisição passa por um servidor MCP gerenciado pela AWS.
• aws:CalledViaAWSMCP: contém o service principal do servidor MCP gerenciado, como aws-mcp.amazonaws.com.

Essas chaves permitem tratar ações iniciadas por agentes de forma diferente de chamadas humanas ou automações diretas. Por exemplo, você pode bloquear ações destrutivas no S3 quando elas vierem pelo AWS MCP Server:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDestructiveS3ActionsViaAwsMcp",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteBucket",
        "s3:DeleteObject",
        "s3:PutBucketPolicy",
        "s3:PutBucketPublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:CalledViaAWSMCP": "aws-mcp.amazonaws.com"
        }
      }
    }
  ]
}

Essa política é apenas um ponto de partida. Políticas de produção devem considerar contas, roles, recursos, ambientes e modelo de aprovação.

CloudWatch vs CloudTrail: o que cada um comprova

CloudWatch e CloudTrail são relevantes, mas não são equivalentes.

Métricas do CloudWatch ajudam a observar padrões de atividade do MCP Server. CloudTrail é o registro de auditoria para chamadas de API AWS. Desenhe o controle ao redor dessa diferença: CloudWatch mostra atividade do MCP, enquanto CloudTrail guarda o histórico de chamadas de API que a auditoria vai exigir.

Essa distinção importa. Não trate métricas do CloudWatch como trilha completa de auditoria de API. Para investigações, evidência de compliance e revisão histórica de chamadas, desenhe o controle ao redor do CloudTrail.

Para que o AWS MCP Server é mais útil

O AWS MCP Server faz sentido quando uma equipe quer que agentes de IA ajudem com AWS sem sair dos padrões de governança da nuvem.

• Desenvolvedores que querem agentes usando documentação AWS atual.
• Equipes de plataforma padronizando ferramentas de IA para ambientes AWS.
• Times de segurança que precisam de controles IAM para ações iniciadas por agentes.
• Equipes DevOps e SRE que querem agentes inspecionando recursos ou apoiando troubleshooting.
• Organizações testando assistentes de código com preocupação sobre credenciais sem governança.
• Times que querem reduzir dependência de shell geral para operações AWS.

Ele não substitui arquitetura de segurança, least privilege, aprovação de mudança, controle de custo, revisão humana ou separação de ambientes.

Quando não usar ainda

Não comece com acesso amplo de escrita em produção. O AWS MCP Server pode não ser o primeiro passo se a organização ainda não definiu limites IAM para agentes, não separa desenvolvimento de produção, não tem CloudTrail adequado ou não decidiu quais ações exigem aprovação humana.

Um caminho mais seguro é começar com documentação, depois acesso read-only a APIs, depois escrita limitada em não produção e só mais tarde workflows de produção com escopo claro.

Como fazer um piloto seguro do AWS MCP Server

Comece estreito: um time de desenvolvimento, uma conta AWS de não produção e poucos casos de uso. Bons primeiros casos incluem busca de documentação, descoberta de serviços, inspeção read-only de ambiente e sugestões de infraestrutura revisadas por uma pessoa.

1. Remova servidores MCP antigos conflitantes. A AWS recomenda remover entradas antigas de AWS API MCP Server ou AWS Knowledge MCP Server antes de configurar o AWS MCP Server.
2. Use credenciais renováveis. Prefira IAM Identity Center ou outro fluxo renovável em vez de chaves IAM estáticas.
3. Comece read-only. Permita inspeção de documentação, regiões, serviços e recursos não sensíveis antes de liberar escrita.
4. Use context keys de IAM. Aplique políticas que diferenciam ações MCP de chamadas diretas.
5. Bloqueie operações destrutivas. Negue deleção, exposição pública e alterações em produção via MCP até revisão.
6. Monitore CloudWatch e CloudTrail. Use CloudWatch para visibilidade de atividade MCP e CloudTrail para auditoria de chamadas de API.
7. Revise resultados antes de ampliar permissões. Expanda só depois de provar workflows úteis, taxa de erro aceitável e caminhos de rollback.

O objetivo do piloto não é provar que um agente pode fazer tudo. É identificar quais workflows AWS podem ser acelerados com segurança.

AWS MCP Server vs acesso direto via AWS CLI

A AWS CLI continua essencial, mas acesso direto por CLI ou shell cria desafios de governança para agentes. Um assistente pode emitir comandos de um jeito difícil de diferenciar de um desenvolvedor usando o mesmo ambiente local. Ele também pode combinar comandos AWS com arquivos locais, shell e ferramentas fora de um caminho de controle dedicado.

Com o AWS MCP Server, a atividade do agente pode passar por uma interface MCP gerenciada, autorizada por IAM e distinguida por context keys específicas. Isso não elimina risco, mas dá a segurança e plataforma um modelo de controle mais claro.

AWS MCP Server vs servidores MCP customizados

Um servidor MCP customizado pode ser melhor quando você precisa expor ferramentas internas, APIs proprietárias, sistemas fora da AWS ou workflows de negócio específicos.

O AWS MCP Server é mais indicado quando o problema é o acesso à AWS em si: documentação atual, execução de APIs AWS, descoberta de serviços, autorização IAM e observabilidade AWS. Muitas organizações usarão os dois.

Erros comuns a evitar

• Dar permissão demais cedo demais. Comece com o menor conjunto de permissões que ainda é útil.
• Tratar MCP como fronteira completa de segurança. Os controles reais ainda dependem de IAM, credenciais, contas, logs, revisão e aprovações.
• Confundir observabilidade com auditoria. Métricas do CloudWatch ajudam na visibilidade; CloudTrail é o registro de chamadas de API.
• Ignorar ciclo de vida de credenciais. Credenciais expiradas quebram workflows e podem empurrar o time para atalhos inseguros.
• Medir sucesso só pela tarefa concluída. Um piloto bom prova que ações têm escopo, visibilidade, revisão e rollback.

FAQ

O AWS MCP Server é gratuito?

O AWS MCP Server está disponível sem cobrança adicional. Você ainda paga pelos recursos AWS criados ou usados pelos agentes e por custos aplicáveis de transferência de dados.

O AWS MCP Server permite acesso a todos os serviços AWS?

A AWS descreve call_aws como a ferramenta para chamadas autenticadas na maior parte das APIs AWS, com gestão de credenciais incluída. O que o agente realmente pode fazer depende das credenciais e políticas IAM em uso.

O AWS MCP Server exige permissões IAM separadas?

Não é necessária permissão IAM separada para invocar o servidor MCP. A autorização ocorre no nível do serviço AWS usando roles e políticas IAM existentes.

Posso impedir agentes de apagar recursos?

Sim, se as políticas IAM forem desenhadas para isso. Use context keys como aws:ViaAWSMCPService e aws:CalledViaAWSMCP para aplicar regras às requisições iniciadas por MCP.

Quais clientes funcionam com o AWS MCP Server?

O servidor funciona com Claude Code, Kiro, Cursor, Codex e qualquer cliente compatível com MCP.

Devo usar o AWS MCP Server em produção imediatamente?

Não. Comece com documentação, workflows read-only, contas de não produção, limites claros de IAM, visibilidade em CloudWatch e CloudTrail e revisão humana para ações de escrita.

Conclusão

O AWS MCP Server é importante porque aproxima agentes de código de trabalho útil em AWS sem obrigar equipes a abandonar governança de nuvem.

Ele oferece conhecimento AWS atual, acesso autenticado a APIs, execução em sandbox e observabilidade nativa. Mais importante: permite que equipes de plataforma e segurança usem controles conhecidos como IAM, context keys, CloudWatch e CloudTrail.

Como a Elevata ajuda

A Elevata ajuda equipes de plataforma, segurança e engenharia a desenhar acesso seguro de agentes de IA na AWS: limites de IAM, políticas MCP, revisão de CloudTrail, contas de sandbox, controle de custos, workflows de desenvolvimento e critérios de rollout.

Se sua equipe está testando AWS MCP Server ou agentes de código na AWS, agende uma revisão de prontidão para acesso de agentes de IA.