Search for a command to run...
Knowledge MCP x AWS MCP gerenciado, IAM e o passo a passo pra conectar no Kiro e no Claude Code sem colar access key no `.env`.
Staff Engineer @Serverless Guru | AWS Community Builder | Specialist in Serverless, AWS & Event-Driven Architectures | Speaker & Content Creator @willpeixoto.dev
No comments yet. Be the first to comment.
Como dar a agentes de IA acesso seguro e útil à AWS: MCP, IAM, Bedrock e o que está saindo agora. Hands-on, direto, sem hype.
What each one is and when to use it: Kinesis Data Streams, Amazon Data Firehose, Managed Service for Apache Flink, and Amazon MSK.
Multi-cloud promises more resilience and delivers the opposite: more failure surface. Let's open up the availability math, see why the "if one goes down the other holds" intuition fools you, and go through the few cases where multi-cloud actually earns its keep.
Multi-cloud promete mais resiliência e entrega o contrário: mais superfície de falha. Bora abrir a conta de disponibilidade, ver por que a intuição do "se uma cair a outra segura" engana, e quais são os poucos casos em que multi-cloud vale de verdade.
O que é e quando usar cada um: Kinesis Data Streams, Amazon Data Firehose, Managed Service for Apache Flink e Amazon MSK.
AWS just shipped Lambda MicroVMs, a new serverless primitive that gives each user or session a VM-level isolated sandbox, with near-instant launch and state preserved for up to 8 hours, all on Firecracker. Here is what it is, when to reach for it instead of a plain Lambda Function, and how to architect on top of it.
🇺🇸 Also available in English: AWS MCP Server: which one to use, when, and how to set it up
Deixa eu te contar uma cena. Aposto que você já viveu ela.
São 11 da noite, você tá de boas codando com a ajuda de uma IA do lado. Você faz uma pergunta pra ela e ela jura que existe: inventa um serviço, um nome que bate com algo parecido que você já fez, e até uma implementação que ela garante que funciona, com tudo e como resolver. E você pensa: caramba, não sabia disso, preciso olhar melhor a documentação porque faz muito sentido. E bang, você descobre que ela tava alucinando. Tava escrevendo código na Lambda chamando um serviço da AWS de uma função que não existe, ligando a tabela do DynamoDB, montando o IaC, tudinho. Aí ela pede pra "dar uma olhada na config atual da sua conta" pra validar os nomes, e você bate na parede que todo mundo bate.
O agente, além de alucinar, não tem acesso à sua conta. Ele não enxerga seus recursos, não faz ideia do que realmente tá lá. E faz o que ele faz de melhor: é criativo, é proativo, e inventa algo pra te deixar feliz. Pra ele, aquilo faz sentido existir, então ele assume que existe. O bichinho não fica nem com vergonha: na maior cara de pau, devolve um ARN que não existe, escolhe uma região que você nem usa e chuta o nome de uma tabela. Dá-lhe. Ele tá fazendo exatamente o que foi programado pra fazer: te deixar feliz.
E você, cansado de brigar com ele e já querendo finalizar, faz o quê? Cola uma access key num .env pra ele "só enxergar a conta um segundinho" e te devolver tudo certinho, com os nomes verdadeiros. Quem nunca?
E tá tudo bem, só que tem um detalhe: você esquece que fez isso. E bang, o .env foi junto no commit. Já tá no histórico do git, alerta pra todo lado, aquela doideira de sempre. Pronto, a chave tá exposta. E é assim também que o seu agente, naquele momento em que parece que quer te punir ou que resolveu ser proativo demais, ganha acesso de verdade à sua conta e, sei lá, decide apagar a stack errada. Ou então é só a continha surpresa de R$ 40 num dia, que vira um número bem pior quando ninguém tá olhando. Eu já passei por isso. Você provavelmente também.
A boa notícia é que a AWS resolveu esse problema. Na real, resolveu de duas formas diferentes, com nomes tão parecidos que confunde muita gente. Esse post é o mapa que eu queria ter tido: o que são os dois, qual dor cada um mata, e quando e como usar cada. Vamos lá.
Nota de validade: esse mundo de MCP muda rápido. Escrevi este guia em junho de 2026 e já precisei atualizar em julho de 2026, quando o fluxo de conexão mudou (a versão que você está lendo traz o OAuth direto). Vou procurar manter em dia conforme sair novidade, mas se algo não bater com a tela na sua frente, confere a doc oficial e me avisa nos comentários que eu corrijo.
Pra você não se perder, é isso que a gente cobre aqui:
A diferença entre os dois servidores MCP da AWS e qual dor cada um resolve
Como conectar no Claude Code, no app do Claude e no Kiro, passo a passo
Como configurar o IAM da sua conta pra dar acesso com segurança
Quando NÃO usar, e os cuidados pra não tomar susto na conta
Antes de falar dos servidores, vamos nivelar.
O MCP (Model Context Protocol) é o "plugue" que o seu assistente de IA usa pra falar com o mundo lá fora: ferramentas, dados e serviços. A Anthropic criou, hoje ele tá sob governança aberta, e no último ano todo assistente que presta (Claude Code, Kiro, Cursor) passou a falar MCP.
Quer uma analogia fácil? Pensa na API. A API é o que deixa duas aplicações conversarem entre si. O MCP é a mesma ideia, só que pro agente: é o que deixa a IA conversar com qualquer ferramenta sem você ter que criar uma integração personalizada pra cada sistema diferente. O MCP conecta o agente ao sistema num padrão que todo mundo combinou de usar. E o bom de ser padrão é esse: você aprende uma vez e serve pra qualquer ferramenta e qualquer cliente. Então, se você quer dar acesso ao seu sistema pra uma IA, é por esse caminho que você vai.
E tem uma coisa que facilita demais: na maioria dos casos, você nem precisa construir um MCP server seu. Dá pra construir, claro (rodando no Lambda, no Fargate, no que você preferir), e a AWS até tem um guidance oficial pra isso se for o seu caso. Mas a AWS já roda servidores gerenciados prontos, então muita vez é só plugar e usar. Construir o seu faz sentido quando a ideia é outra: expor o SEU sistema interno (uma API, um runbook, um alerta) pro agente.
Pois é, são dois. E os nomes não ajudam em nada, viu. Olha tudo numa tabela só e depois eu destrincho cada um:
| AWS Knowledge MCP Server | AWS MCP Server (gerenciado, GA) | |
|---|---|---|
| Que dor resolve | "Meu agente alucina API, ARN e nome de serviço da AWS." | "Meu agente precisa ver ou agir na minha conta, sem eu vazar chave." |
| O que acessa | Só documentação e conhecimento da AWS (read-only) | Documentação + serviços reais da sua conta (autenticado) |
| Credenciais | Nenhuma. Nem conta AWS você precisa. | Login AWS no browser (OAuth) ou AWS CLI (SigV4) |
| Auditoria | Não se aplica | CloudTrail + CloudWatch |
| Use quando | Quer sintaxe certa, docs atuais, disponibilidade regional | Quer o agente inspecionando ou operando infra real |
| Risco se usar errado | Praticamente zero | Real. É a sua conta. Least-privilege importa. |
Se você guardar uma frase só desse post, guarda essa:
Um servidor dá conhecimento pro seu agente. O outro dá mãos pra ele.
Sacar qual problema você tem de verdade já é metade do caminho.
Quer outra analogia? O Knowledge é o guru: aquele amigo que decorou a documentação inteira da AWS e tira sua dúvida na hora. Já o gerenciado é o porteiro cara-crachá: ele te deixa entrar na conta de verdade, mas fica ali conferindo e só abre as portas que o IAM autorizou. Cara, crachá. Não bateu, não passa.
Onde isso roda? O AWS MCP Server é remoto, e quem conecta nele é o MCP client: Claude Code, app do Claude (Desktop e claude.ai), Kiro, Cursor, ou o código do seu próprio agente (Strands, SDK). Isso vale inclusive com a inferência rodando no Bedrock, porque o client é a aplicação, nunca o modelo. Já um agente de produção no AgentCore normalmente consome tools pelo AgentCore Gateway (que também fala MCP) ou por um MCP server seu. Esse cenário de produção fica para outro post da série.
O que esse servidor faz é simples: é remoto, totalmente gerenciado, e dá ao modelo acesso estruturado à documentação oficial, sempre atualizada. E esse "atualizada" é o ponto. O que o modelo sabe sozinho para na data de treino dele, então ele não conhece o que veio depois e acaba chutando. A AWS mantém esse servidor em dia, então ele vira a sua fonte da verdade: busca na doc, traz a página em markdown limpo, checa se um serviço existe numa região e lista as regiões atuais. Só leitura, não escreve nem toca na conta.
Por que é quase óbvio ligar? Porque não tem credencial, e nem conta AWS é necessária. Não tem nada pra proteger, nada pra vazar. O risco é praticamente zero e o ganho é o agente parar de chutar e começar a citar a doc real antes de cuspir o CDK.
Use quando você tá aprendendo um serviço, desenhando a arquitetura que quer construir e validando a ideia, conferindo sintaxe, gerando IaC em que você confia, ou respondendo "isso já tá na minha região?" sem precisar abrir o navegador. Ligar é colar uma URL: adiciona https://knowledge-mcp.global.api.aws como servidor remoto (HTTP) no teu cliente e pronto, sem credencial nenhuma. Com ele no ar, o agente consulta a doc live antes de cuspir o CDK em vez de chutar pelo que viu no treino. ARN alucinado despenca. Legal não?
Esse aqui é o que cura a vergonha do .env.
A dor é outra: o agente precisa ver ou fazer algo na conta de verdade. Ler o log do CloudWatch da função que tá quebrando, listar o que realmente tem no bucket, conferir o schema da tabela do DynamoDB. A "solução" antiga era entregar credencial de longa duração pra ele. É essa parte que tira o sono do pessoal de segurança. E, sinceramente, devia tirar o seu também.
O que esse servidor faz: ele é remoto, hospedado e gerenciado pela AWS, e dá ao agente acesso autenticado aos serviços da AWS através de um conjunto pequeno e fixo de ferramentas. Sem instalação local, com update automático, e (essa parte eu curto demais) toda chamada vai parar no CloudTrail. O agente não ganha uma chave-mestra. Ele se autentica como você, por um fluxo de auth de verdade, com a sua identidade do IAM.
O fluxo de auth, em bom português: agora são dois caminhos, e o mais novo é o mais simples. Hoje o servidor fala OAuth direto. Você adiciona a URL no seu cliente, a primeira chamada de tool abre o browser no AWS Sign-in, você entra com a sua identidade de sempre e pronto. O token dura 1 hora e se renova sozinho por até 12. Sem proxy, sem instalar nada.
O segundo caminho é o SigV4 com o mcp-proxy-for-aws, um proxy open source que roda na sua máquina, pega as suas credenciais locais da AWS CLI e assina cada chamada. Ele continua existindo e tem hora certa: múltiplas contas na mesma sessão, read-only mode (esconder as tools de escrita do agente), região default fixa, ou organização que bloqueia as permissions de OAuth (signin:AuthorizeOAuth2Access e signin:CreateOAuth2Token).
Nos dois casos o resultado é o mesmo: você não cola chave em lugar nenhum, o agente age com a sua identidade, e tudo respeita o seu IAM. Busca na documentação, aliás, nem credencial precisa.
O fluxo OAuth, passo a passo:
Você anexa a managed policy AWSMCPSignInOAuthAccessPolicy na sua role ou user (uma vez).
Adiciona a URL do servidor no cliente e dispara a primeira chamada.
O browser abre no AWS Sign-in, você autoriza, e o cliente guarda o token (1 hora, refresh automático até 12).
O server aplica as context keys e repassa para o serviço da AWS.
O IAM autoriza pela sua policy e responde.
A chamada inteira fica registrada no CloudTrail.
O momento "aaah, sacou" é esse: pergunta "por que o checkout-prod começou a dar 500 depois das 14h?" e vê o agente puxar o log real do CloudWatch, cruzar com um deploy recente e apontar o recurso de verdade. Tudo dentro do que o IAM permite, tudo auditável, sem chave em dotfile nenhum. E funciona com o que você já usa: Claude Code, Kiro, Cursor, qualquer cliente compatível com MCP.
Agora a parte prática. O pré-requisito do caminho OAuth é um só: a identidade que você vai usar precisa da managed policy de sign-in. Anexa uma vez e esquece:
aws iam attach-role-policy \
--role-name SuaRole \
--policy-arn arn:aws:iam::aws:policy/AWSMCPSignInOAuthAccessPolicy
(Se você usa IAM user em vez de role, é attach-user-policy com --user-name.)
Uma linha, e é isso mesmo:
claude mcp add aws-mcp https://aws-mcp.us-east-1.api.aws/mcp --transport http
Na primeira chamada de tool o browser abre, você loga, e o agente já enxerga a conta pela sua identidade do IAM.
Tem também um segundo jeito: o plugin aws-core. Além do AWS MCP Server já configurado, ele traz as agent skills da AWS, que são pacotes de instrução prontos para o agente executar bem tarefas de CDK, serverless, containers e billing. Se você quer o server mais esse contexto extra de uma vez, instala do marketplace oficial da Anthropic, que já vem registrado no Claude Code:
/plugin install aws-core@claude-plugins-official
Detalhe que confunde: esse comando roda dentro do Claude Code, no terminal. A seção "Plugins" do app Claude Desktop é outro catálogo, então não procura o aws-core lá (no app, o caminho é o connector da próxima seção). O equivalente do steering aqui é um CLAUDE.md na raiz do projeto, com as mesmas regras que eu mostro no bloco do Kiro logo abaixo.
Sim, funciona no app, sem terminal. No Claude Desktop: Settings, Connectors, "Add custom connector", dá um nome (eu chamei de aws-mcp) e cola a URL:
https://aws-mcp.us-east-1.api.aws/mcp?oauth=initialize
O sufixo ?oauth=initialize instrui o server a disparar o fluxo OAuth explicitamente (Cursor e Kiro IDE usam o mesmo truque). Os campos de OAuth Client ID e Secret ficam vazios, o fluxo cuida disso. No claude.ai web é a mesma URL sem o sufixo, nas configurações de conector.
No Codex: use a URL limpa, sem
?oauth=initialize:https://aws-mcp.us-east-1.api.aws/mcp. O Codex detecta e inicia o OAuth automaticamente.
Na primeira chamada abre a tela de autorização da AWS:
Dois avisos aqui, porque eu caí neles primeiro para você não cair:
Não é o conector do Directory. Se você buscar "AWS" no diretório de conectores do Claude, aparece um "AWS API MCP Server". Ele NÃO é o gerenciado novo: é o aws-api-mcp-server antigo do awslabs (repara nas tools dele, só suggest_aws_commands e call_aws), justamente um dos que a doc oficial manda substituir. O caminho certo é o custom connector com a URL acima. E não rode os dois juntos, que é o cenário exato de conflito de tools que a AWS alerta.
Não autorize como root. A tela de consent oferece "Continue with Root or IAM user" e diz que o acesso segue "your existing AWS permissions". A identidade que você usar ali define o raio de acesso do agente. Entra com um IAM user ou role dedicada, com a managed policy de sign-in e least-privilege. Root pilotado por agente é tudo que a gente não quer. E um sinal de alerta prático: se a conexão funcionou sem você anexar policy nenhuma, investiga com um aws sts get-caller-identity. Ou a tua identidade é admin, ou você entrou como root, que nem passa pelo IAM imagina um agente operando root na conta inteira, é o que não queremos.
No Kiro CLI (2.11 em diante):
kiro-cli mcp add --name aws-mcp --url https://aws-mcp.us-east-1.api.aws/mcp
No Kiro IDE, adiciona como servidor remoto com a URL ?oauth=initialize, ou via mcp.json (por projeto em <raiz>/.kiro/settings/mcp.json, global em ~/.kiro/settings/mcp.json; quando os dois existem, o do projeto ganha).
Só que config liga o server, não garante que o Kiro vá usar. Para ele preferir essas tools, cria um steering file em .kiro/steering/aws-mcp.md:
---
inclusion: always
---
# Uso de AWS via MCP
- Antes de gerar código ou IaC de AWS (CDK, CloudFormation, SDK), valide nome
de serviço, sintaxe e disponibilidade regional na doc via server `aws-mcp`
(tool de busca na documentação). Não chute API nem ARN.
- Para inspecionar recursos reais da conta (logs do CloudWatch, itens do S3,
schema do DynamoDB), use o mesmo server `aws-mcp`. Nunca peça nem use access key.
- Nunca rode ação destrutiva (delete, scaling) sem confirmar antes.
O inclusion: always faz essa regra entrar em toda conversa do Kiro naquele projeto.
Se você caiu num dos casos do SigV4 (multi-conta, read-only mode, região default, org sem OAuth), o setup pede um pouco mais de máquina local: AWS CLI 2.32+ logada com aws login (as credenciais giram sozinhas a cada 15 minutos, sessão de até 12 horas), uv instalado, e o proxy no mcp.json:
{
"mcpServers": {
"aws-mcp": {
"command": "uvx",
"args": [
"mcp-proxy-for-aws==1.6.2",
"https://aws-mcp.us-east-1.api.aws/mcp",
"--metadata", "AWS_REGION=sa-east-1"
]
}
}
}
Deixe a versão do proxy pinada (supply chain agradece) e confira de vez em quando no PyPI se saiu versão nova. O endpoint é regional (hoje us-east-1 e eu-central-1); você conecta num deles e opera nos recursos da região que passar em AWS_REGION. Confere o atual na doc oficial, que isso pode mudar.
"Everything fails, all the time."
Werner Vogels, CTO da Amazon
Se tem uma parte pra não pular, é essa. O Werner tá certo, e com uma IA pilotando a sua conta vale levar a frase ao pé da letra: parte do princípio de que uma hora o agente vai aprontar, e projete pra isso. Dar acesso pra ele ler e operar a conta é tão sério quanto parece, então vale fazer com cuidado.
Primeira coisa: o IAM continua sendo o chefe. O servidor gerenciado não passa por cima das suas permissões, ele anda em cima delas. Trate o agente como um colega de trabalho novo. Ou melhor: como aquele estagiário recém-formado que faz tudo ao pé da letra, sem questionar, e que, com medo de fazer errado, nem para pra pensar. É o tipo que, se você mandar procurar o estoque de faísca pra guardar numa garrafa, ele sai atrás de boa. Pois é, o agente é assim também: se você der acesso demais, ele usa, mesmo quando não faz o menor sentido. Por isso, least-privilege, escopado só pro que a tarefa precisa, e nada além disso. A AWS criou context keys de IAM padronizadas pra esses servidores MCP gerenciados, então dá pra escrever policy que sabe "essa chamada veio pelo MCP server" e restringir de acordo.
Segunda: não tem chave de longa duração em lugar nenhum. No OAuth, o que existe é um token de 1 hora com refresh automático; no caminho SigV4, as credenciais temporárias da AWS CLI, que giram sozinhas a cada 15 minutos. Ou seja, não sobra segredo parado no seu histórico de shell, no repo ou no .env, que é exatamente onde a gente costuma vazar.
Terceira: tudo é auditável. O CloudTrail loga cada chamada e o CloudWatch te dá as métricas. Depois de um incidente, você responde "o que o agente fez, afinal?" de cara limpa. Se hoje você não consegue responder isso sobre o seu setup atual, só isso já é motivo de sobra pra trocar.
E uma que ainda tá chegando: suporte a VPC endpoint, pra quem precisa manter esse tráfego dentro da fronteira da rede. Se isso é requisito duro pra você, espera por ele antes de levar pra produção.
Minha regra de bolso? Uma role de IAM dedicada por propósito de agente. Se um agente for comprometido ou der ruim, o estrago para naquela role. Não reusa sua identidade de admin. E não dá * em * "só pra destravar a demo", porque a demo vira prod mais rápido do que você imagina.
Do lado da conta é menos coisa do que parece, porque o AWS MCP Server gerenciado não cria ações de IAM próprias. Não existe mcp:Invoke pra liberar: ele assina cada chamada com SigV4 usando as suas credenciais e encaminha pro serviço, que autoriza pelas suas policies de sempre. Se a sua identidade não pode chamar logs:GetLogEvents, o agente também não pode. As suas permissões atuais são a fronteira.
O quick-start é esse: comece com uma identidade read-only (uma role dedicada ou um permission set de SSO) e use as context keys novas, aws:ViaAWSMCPService e aws:CalledViaAWSMCP, pra negar ação destrutiva quando a chamada vier do agente, mesmo que a sua role pudesse fazer. Assim o agente lê à vontade e os verbos perigosos ficam bloqueados só pra ele. Depois, deixa o CloudTrail mostrar o que ele realmente usou e aperta a policy em cima disso.
Um guardrail simples, só pra você pegar a ideia:
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "BlockDestructiveActionsViaMCP",
"Effect": "Deny",
"Action": ["dynamodb:DeleteTable", "s3:DeleteBucket", "lambda:DeleteFunction"],
"Resource": "*",
"Condition": { "Bool": { "aws:ViaAWSMCPService": "true" } }
}]
}
Esse setup merece um post só dele, feito como código. Vou soltar num próximo post da série um "IAM pra agente de IA na AWS, com CDK" com o passo a passo completo (CLI, console e CDK), cdk-nag, SCP org-wide e multi-conta. Quando sair, linko aqui.
Quando esse post saiu, a resposta era "depende da dor". Três semanas depois, a AWS bateu o martelo: o setup guide oficial agora recomenda migrar para o AWS MCP Server e remover o Knowledge (e o antigo AWS API MCP) da configuração. O motivo é prático: tools duplicadas confundem o agente e derrubam a performance, e é a própria doc que manda limpar.
O Knowledge não foi desligado. Continua GA, sem credencial, funcionando. Sobrou um caso legítimo para ele: você quer SÓ consultar doc, sem conta AWS e sem autorizar nada (estudando um serviço, por exemplo). Para todo o resto, é um servidor só: o gerenciado, que já faz busca na doc sem credencial e opera a conta quando você autorizar. Menos config, menos conflito, mesma identidade sua do IAM.
Porque não existe bala de prata, e alguém tem que falar.
Não solta isso numa conta de produção sem guardrail. Começa num sandbox e acerta as fronteiras de IAM antes do agente poder tocar em qualquer coisa que cobra ou apaga. No Frugal Architect, o Werner prega que custo é requisito de arquitetura, não algo pra descobrir no fim do mês, e com um agente disparando chamada isso vale dobrado.
Não libera permissão larga "por enquanto". Não existe "por enquanto", confia em mim. Escopa desde a primeira conexão.
E não deixa coisa irreversível no automático. Delete, ação de scaling, movimentação de dinheiro: mantém humano no loop. O agente propõe, você aprova.
Três pontos que importam pra quem opera aqui em São Paulo.
O primeiro é a região sa-east-1. Antes de apontar o agente, confirma a disponibilidade dos serviços e do servidor gerenciado na região de São Paulo. E olha que beleza: essa é literalmente uma pergunta que o próprio MCP server responde pra você (a busca na doc faz isso, sem credencial). Vale checar em vez de assumir.
O segundo é LGPD e residência de dado. Se o agente vai tocar em recurso com dado pessoal, escopa o IAM pra ele não conseguir ler o que não deve, e usa a trilha do CloudTrail como evidência de quem acessou o quê. Auditabilidade aqui não é só boa prática técnica, é argumento de conformidade.
O terceiro é auditoria pra time pequeno. Esse CloudTrail "de graça" é ouro pra quem não tem um time de segurança dedicado. Você ganha o registro de tudo que o agente fez sem montar nada.
São dois servidores MCP da AWS pra duas dores: conhecimento (parar de alucinar) e ação (operar a conta com segurança).
O caminho simples agora é OAuth: adiciona a URL, loga no browser e pronto. Funciona no Claude Code, no app do Claude (Desktop e claude.ai) e no Kiro.
O gerenciado te tira do .env: token de curta duração (OAuth) ou credenciais temporárias da CLI (SigV4), com least-privilege e tudo logado no CloudTrail.
A recomendação oficial virou um servidor só: migre para o AWS MCP Server e tire o Knowledge da config. Ele segue vivo para consulta de doc sem credencial, mas rodar os dois juntos confunde o agente.
Se você vinha fazendo a gambiarra do .env, relaxa, todo mundo já fez. Mas as ferramentas pra parar estão aqui, são gerenciadas e são auditáveis. Não tem mais desculpa boa pra continuar entregando as chaves da sua conta pra um robô que de vez em quando viaja na maionese.
Esse post abre uma série sobre MCP e agentes na AWS. Nos próximos eu vou fundo em dois caminhos: configurar o IAM como código (CDK) e a OpenAI chegando no Bedrock.Comenta aí.
Curtiu? Manda aquele joinha, comenta o que achou e compartilha com a galera pra fortalecer. Valeu demais por ler até aqui.Te vejo no próximo? BUILD ESCALE REPEAT =D
Os MCP servers open source da AWS (awslabs/mcp), onde vive o Knowledge MCP Server
Agent Toolkit for AWS, de onde vem o AWS MCP Server gerenciado