Stop pasting AWS access keys into your .env files.
We have all been there. It is late, you are debugging a Lambda permission error, and your AI assistant keeps inventing service names or ARNs with imaginary account IDs. You want the model to see your actual resources so it stops hallucinating and starts fixing. Out of desperation, you grab an access key, drop it into an environment file, and feed it to the agent. It works. Relief floods in. Then morning arrives, and you realize that secret is sitting in your shell history, terminal scrollback, or worse, a commit that just pushed to a shared repository.
This is the exact mess the Model Context Protocol was built to prevent.
MCP creates a standard bridge between your AI agent and external systems. Instead of handing over raw credentials and hoping the agent does not leak them, you connect through a controlled server that handles authentication, scopes permissions, and keeps your keys out of the chat window entirely.
For AWS, you currently have two official MCP servers to pick from. Choosing the wrong one either leaves your agent blind or gives it too much access with too little oversight.
Know the Difference: Knowledge vs. Hands
The first option is the AWS Knowledge MCP Server. Think of it as a senior engineer who has memorized the entire AWS documentation library but has no login credentials for your account. It is read-only by design, referencing official AWS docs to ground the agent in real API syntax, correct service names, and current best practices.
You do not need an AWS account to use it. You do not connect it to your infrastructure. You spin it up when you are sketching an architecture diagram, learning a new service like ECS or EventBridge, or validating whether a particular API call still behaves the way you remember from two years ago. It stops the agent from guessing. If you ask it to write Terraform for an S3 bucket policy, it knows the real fields and valid values because it is pulling from the source, not from training data that cut off last year.
The second option is the AWS MCP Server (Managed). This one gives your agent hands, not just memory. With proper authentication, it can inspect your CloudWatch logs, list your S3 buckets, read your DynamoDB table schemas, check IAM policies attached to a role, or verify which security groups are open to the internet. It operates on your real account, which makes it powerful for troubleshooting production issues or refactoring live infrastructure.
The Managed server refuses long-lived keys. It authenticates through OAuth via a browser sign-in, or through AWS CLI using SigV4 signing. Every tool call happens with short-lived tokens, every action leaves a trail in CloudTrail, and the agent operates strictly within the IAM boundaries you define. It cannot wander outside its permissions because it is bound by the same policy engine that governs every other AWS user or role in your organization.
Here is the golden rule to remember: one server gives your agent knowledge, the other gives it hands. Use the Knowledge server when you are studying or designing. Use the Managed server when you are operating or repairing.
Why AWS Recommends the Managed Server for Most Tasks
AWS now pushes most users toward the single Managed MCP Server rather than running both in parallel. The Managed server has absorbed the documentation context that the Knowledge server provided, so it handles both reference material and live account actions under one endpoint.
Running both servers simultaneously can actually degrade the experience. The agent receives overlapping tool definitions and can get confused about whether to call a read-only documentation lookup or a live API against your account. That hesitation produces slower responses and occasional tool-selection errors. Consolidating down to the Managed server simplifies your configuration and keeps the agent focused.
Setting Up the Managed Server with OAuth
Getting the Managed server running takes about five minutes, but the steps matter because this is a live connection to your account.
Step 1: Prepare your IAM identity
Створіть або виберіть спеціальну IAM-роль або користувача. Не використовуйте свій Root-акаунт. Прикріпіть до неї керовану політику (managed policy) під назвою AWSMCPSignInOAuthAccessPolicy. Ця політика надає лише дозволи, необхідні для ініціації процесу входу через OAuth для доступу до MCP. Сама по собі вона не надає широких адміністративних прав. Фактичні можливості вашого агента визначатимуться іншими IAM-політиками, які ви прикріпите до цієї ідентичності. Якщо ви хочете, щоб агент міг читати логи CloudWatch, але ніколи не торкався IAM або білінгу, створіть власну політику, яка дозволяє лише logs:DescribeLogGroups та logs:FilterLogEvents і нічого більше.
Крок 2: Налаштуйте свій клієнт
Додайте офіційну URL-адресу AWS MCP сервера до конфігурації вашого клієнта. Це працює з Claude Desktop, Claude Code та Kiro. У файлі налаштувань MCP зареєструйте endpoint сервера, щоб клієнт знав, куди спрямовувати виклики інструментів, пов'язаних з AWS.
Крок 3: Пройдіть автентифікацію через браузер
Під час першої спроби агента викликати інструмент AWS ваша операційна система відкриє вікно браузера. Увійдіть за допомогою тієї ж IAM-ідентичності, яку ви підготували на Кроці 1. Процес OAuth повертає короткостроковий токен серверу MCP. Ви не побачите секретного ключа. Вам не доведеться нічого вставляти у файл конфігурації. Токен оновлюється автоматично та швидко закінчується термін його дії.
Крок 4: Перевірте межі довіри
Після автентифікації відкрийте CloudTrail і переконайтеся, що дії відображаються під створеною вами ідентичністю. Ви маєте бачити події на кшталт ListBuckets або DescribeInstances, пов'язані з цим конкретним IAM-користувачем або роллю. Якщо ви бачите активність Root-акаунта, ви зробили щось не так і повинні негайно анулювати сесію.
Якщо OAuth не підходить для вашого робочого процесу, Managed-сервер також підтримує автентифікацію SigV4 через ваші існуючі облікові дані AWS CLI. Цей шлях дозволяє уникнути спливаючого вікна браузера, але ви все одно отримуєте перевагу від того, що сервер MCP бере на себе підпис та керування сесіями, замість того, щоб відкривати сирі облікові дані агенту.
Звички безпеки, які справді мають значення
Безпека MCP-сервера залежить виключно від IAM-ідентичності, яка стоїть за ним.
Починайте з принципу найменших привілеїв. Вашому агенту не потрібен AdministratorAccess, щоб виправити неправильно налаштовану інтеграцію API Gateway. Надайте йому саме ті дозволи на читання або запис, які необхідні для поточного завдання, і ротуйте або анулюйте їх після завершення роботи. Якщо ви використовуєте роль, встановіть коротку тривалість сесії. Якщо ви використовуєте користувача, увімкніть MFA всюди, де це дозволяють ваші інструменти.
Ніколи не авторизуйтеся як Root-користувач. Root обходить політики контролю сервісів (service control policies) і має необмежений доступ до всього акаунта. Якщо агент неправильно інтерпретує запит і спробує видалити ресурси, ви захочете, щоб цей запит був заблокований політикою меж (boundary policy). У Root немає таких запобіжників.
Нарешті, ставтеся до агента як до нового стажера, який ідеально виконує інструкції, але не має здорового глузду. Він виконуватиме те, що ви просите, буквально і негайно. Якщо ви скажете йому «очистити невикористовувані групи безпеки», він може видалити ту, що підключена до вашої робочої бази даних, оскільки вона підпала під широкі критерії, які ви надали. Перевіряйте будь-які деструктивні команди перед підтвердженням, особливо якщо агент має доступ на запис.
Головний висновок
Вам не потрібно жертвувати безпекою заради корисності. Managed AWS MCP Server дозволяє вашому ШІ-помічнику бачити вашу реальну інфраструктуру, виправляти власні галюцинації та працювати в межах тієї ж структури IAM, яка керує рештою вашої команди. Ви отримуєте актуальний контекст, не зберігаючи секрети у файлах середовища. Налаштуйте потік OAuth, обмежте дозволи та дозвольте агенту працювати з відкритими очима, але з руками, прив'язаними вашими політиками.