Практичне використання Bedrock AgentCore: Terraform, LangGraph та виявлені проблеми.

Розміщення AI-агента на AWS вручну означає необхідність самостійного вирішення проблем із ізоляцією сеансів, доступом до інструментів, пам’яттю та аутентифікацією. Amazon Bedrock AgentCore — це керована версія того ж рішення, яка стала загальнодоступною з жовтня 2025 року. Практичним способом оцінити таку платформу є припинення читання про неї та створення щось реальне; невеликий агент для триажу у режимі лише читання типу DevOps виконав саме цю функцію. Його розгорнули за допомогою Terraform замість вбудованого CLI-майстра AWS, а також написали за допомогою LangGraph замість SDK Strands від AWS. Обидві ці рішення були усвідомленими, адже метою було дізнатися, що може працювати поза стандартними шляхами.

Що таке AgentCore

AgentCore — це набір керованих компонентів, які опікуються складними та важливими аспектами роботи агента у продакшені, дозволяючи при цьому зберегти будь-яку існуючу фреймворк-структуру агента. Основною обіцянкою є підтримка будь-якого фреймворку, і вона переважно дотримується. Підтримуються LangGraph, LangChain, CrewAI, Strands та звичайні API-запити.

Компоненти та їхні функції:

• Runtime зберігає код агента та надає кожній сесії власну ізольовану мікро-VM. Він скорочує свою активність до нуля у стані спокою та оплачується за секунди під час роботи.
• Gateway перетворює існуючі функції Lambda або API на інструменти, сумісні з MCP, які може використовувати агент, тому не потрібен власний сервер MCP.
• Memory зберігає історію розмов у вигляді короткострокових подій та за потреби може видобувати довгострокові семантичні знання між сесіями.

Ідентифікація охоплює два напрямки автентифікації: хто може звертатися до агента та що агент може робити від імені користувача, включаючи сервіси третіх сторін, такі як Slack чи GitHub.

Функція спостережуваності надсилає дані OpenTelemetry до CloudWatch, щоб був запис про те, що робив агент та чому.

Інструмент для браузера та інструмент для інтерпретації коду обслуговують агенти, які мають діяти в відкритому інтернеті чи виконувати довільний код.

У оголошенні AWS Summit у червні 2026 року було додано шар Harness та можливість пошуку в мережі. Обидва ці інструменти ще занадто молоді, тож критична інфраструктура поки що не повинна покладатися на них.

Процес інтеграції вже було перебудовано один раз. Початковий інструментарій Starter Toolkit CLI тепер вважається застарілим та замінений пакетом npm на основі CDK під назвою @aws/agentcore. Туторіал, який описує налаштування та запуск agentcore як окремі кроки, ілюструє старий підхід. Цей деталь має значення, адже вона вказує на швидкість змін: через дев’ять місяців після загального випуску процес початку роботи вже було перероблено, тож все, що написано про продукт, має обмежений термін дії.

Тестовий проект

Агент відповідає на запитання, такі як чи активні якісь сповіщення CloudWatch чи який статус певної інстанції EC2. У нього є два справжніх інструменти лише для читання, тож ніщо з того, що він може використовувати, не здатне змінювати інфраструктуру — лише спостерігати за нею. Він пам’ятає хід розмови між запитами, а кожен перехід між компонентами аутентифікується.

LangGraph було обрано замість Strands, тому що Strands — це власна платформа AWS, яка забезпечує найбільш плавну роботу з усіма офіційними прикладами. Використання іншого інструменту стало справжнім тестом твердження про універсальність будь-якої платформи, і це відповідало вже наявним інструментам. З подібної причини Terraform було обрано замість CLI. Майстер призначений для швидкого запуску демонстрації, а метою тут було побачити кожні взаємозв’язки довіри IAM та кожне з’єднання між компонентами, а не їх прихований створення. Ця видимість виявилась важливішою, ніж очікувалося.

Архітектура складається з контейнера Runtime, який запускає агента LangGraph, що взаємодіє з Гейтвеєм, який через MCP надає два інструменти на основі Lambda. У AgentCore Memory зберігається хід розмови, а Cognito видає токени між машинами для кожного кроку.

Переходьте далі перед написанням скриптів

Перш ніж було написано будь-який код Terraform, консольна версія налаштувань була протестована один раз, головним чином щоб зрозуміти, що саме автоматизується. Цю практику варто запозичити навіть тоді, коли Terraform здійснює реальне розгортання, адже читати файли інфраструктури значно простіше після того, як ви бачили форми, які вони заповнюють.

Реєстр контейнерів потребує ручного керування, незалежно від інструменту, який виконує решту завдань, адже це єдиний крок, який Terraform не може виконати. Створення репозиторію відбувається на одному екрані консолі. Однак зображення мусить надійти іншим способом, оскільки в консолі немає кнопки для створення Dockerfile. Це робиться у терміналі за допомогою команди docker buildx build для платформи linux/arm64, після чого відбувається його надсилання. Усе справа у ручному вказуванні платформи. Якщо цього не зробити, зображення буде створено без проблем, але потім мовчки відхилене під час спроби Runtime його запустити, оскільки Runtime працює лише на Graviton.

Як тільки зображення надійде, консоль відображає його точний URI. Цей рядок є єдиним елементом стану, який має перейти від ручно виконаних дій до інформації, відомої Terraform, чи то у файл tfvars, чи то у поле зображення контейнера Runtime для тих, хто залишається в консолі.

Інструменти AgentCore для керування пам’яттю, гейтвеєм та часом виконання знаходяться у своєму окремому розділі консолі Bedrock. Кожен з них — це форма з тими самими полями, які встановлює Terraform, що має сенс, адже Terraform використовує той самий API під капотом.

• У налаштуваннях пам’яті потрібно вказати назву та термін зберігання короткострокових подій.
• У налаштуваннях гейтвею потрібно вказати протокол, роль виконання та спосіб автентифікації користувачів. Проблема, описана нижче щодо параметрів Cognito audience-versus-client-id, проявляється саме тут у вигляді спадного списку, який змушує обрати один із варіантів.
• У налаштуваннях часу виконання потрібно вказати URI реєстру, роль та ту саму налаштування авторизатора, що й у гейтвеї.

Нічого складного немає, коли форми знаходяться прямо перед вами. Terraform все одно залишається кращим вибором для будь-яких довгострокових проектів, адже переходити між сімома формами у трьох розділах консолі — це процес розгортання, який ніхто не хоче повторювати чи передавати колезі.

Де відбулося укусання

Зображення мають бути у форматі ARM64

Середовище виконання — лише Graviton, без жодних винятків. Звичайна конфігурація Docker на більшості ноутбуків створює зображення у форматі amd64, яке мовчки відхиляється під час розгортання. Кожна конфігурація вимагає використання команди buildx із флагом платформи arm64. Коментар безпосередньо над рядком FROM у Dockerfile є простим засобом захисту, адже інакше його можна забути.

Контракт Lambda Gateway

У кількох публікаціях у блогу показано подію Lambda, загорнуту в обгортку з полям toolName та параметрами. Насправді ж це вхідні властивості інструменту у вигляді плоского словника. Справжнє ім’я інструменту міститься у значенні ключа bedrockAgentCoreToolName під елементом context.client_context.custom; воно починається з назви цільового гейтвею та розділено трьома підкресленими символами. Ця розбіжність стала помітною лише після прямого ознайомлення з документацією AWS щодо Lambda-target, а не покладання на сторонні узагальнення. Більша частина інформації про цей продукт походить з періоду прев’ю або є просто неправдивою.

Токени Cognito не мають поля aud

Щоб зрозуміти цю ситуацію, знадобився час. Коли використовується Cognito для автентифікації між машинами через механізм client_credentials без участі користувача, Cognito видає токен доступу, а не токен ідентифікації. Токени доступу ніколи не містять поля aud. Лише токени ідентифікації його мають, але у сценарії M2M токен ідентифікації відсутній, оскільки немає користувача, якому його можна було б видати. Необхідно налаштувати авторизатор JWT у AgentCore так, щоб він перевіряв значення allowed_audience для такого токена, і в результаті отримується помилка 403 без очевидної причини. Рішенням є використання параметра allowed_clients, який перевіряє значення client_id, що дійсно міститься у токенах доступу Cognito.

boto3 не може викликати Runtime, захищений JWT

Це було найбільше здивування – це не обхідний захід, а речення у власному довіднику API AWS. Якщо агент використовує автентифікацію типу OAuth, то InvokeAgentRuntime зовсім не можна викликати через AWS SDK. Замість цього використовується прямий HTTPS-запит із токеном-носієм у заголовку Authorization, який надсилається за URL, створеним вручну з ARN рунтайму, перекодованим у вигляді percent-кодування, у самому шляху. Кожен приклад boto3 передбачає стандартний шлях IAM та SigV4. Як тільки налаштовується custom_jwt_authorizer, що є необхідним для будь-чого, що не є суто внутрішнім, уся ця категорія прикладів більше не застосовується.

Конфлікт пакетів у Python

Пакет mcp для Python випустив основну версію 2.0.0, яка змінила назви внутрішніх модулів, тоді як langchain-mcp-adapters ще не оновився. Він заявляє про сумісність із mcp версії 1.24.0 та вище без встановлення верхньої межі, тому просте запуском команди pip install зараз призводить до несправної пари компонентів. Принаймні це призводить до чіткого помилки під час імпорту, а не до прихованої проблеми. У тестовому проекті встановлена конкретна версія mcp 1.29.0. Перевірте, чи все ще потрібна ця фіксована версія, адже тихі патчі можуть перетворити виправлення на зайвий „бруд“.

Розгортання — це більше, ніж просто одне застосування

Ресурс Runtime потребує образу контейнера, який вже знаходиться у реєстрі, і Terraform не може створити та надіслати образ у межах власної команди apply. Справжня послідовність полягає у створенні лише репозиторію в реєстрі, створенні та надсиланні образу поза Terraform, а потім застосуванні всього іншого. Інженери у значно більших стеках AgentCore підключили CodeBuild до графу Terraform за допомогою null_resource, щоб усунути цей недолік. Це розумний наступний крок та ознака того, що ця проблема поширена та не є особистою помилкою.

Стан розмови має знаходитися в одному місці

Це не баг, а структурний вибір: агент навмисно не використовує власний чекпоінтер LangGraph для зберігання стану розмови, хоча більшість навчальних матеріалів LangGraph рекомендують його як стандарт. Сеанси під час виконання можуть зменшитися до нуля, і між викликами може бути створена нова мікроVM, тож все, що зберігається лише в оперативній пам’яті процесу, зникає. Пам’ять AgentCore є тією стабільною частиною, яка зберігає інформацію. Використання локального чекпоінтера разом із пам’яттю створює два конкуруючі записи однієї розмови, і рано чи пізно вони почнуть суперечити щодо того, що було сказано. Варто обрати один з варіантів. Пам’ять є більш розумним вибором, оскільки вона зберігається навіть під час початкового запуску.

Яка це коштує

Ціноутворення ґрунтується на обсязі використання без мінімальних ставок, що є хорошим рішенням для системи, яка більшу частину часу очікує на відповідь великої мовної моделі. В результаті рахунок складається з кількох невеликих позицій, які вимірюються окремо, а не з однєї цифри. На момент написання:

• Витрати на експлуатацію становлять приблизно 9 центів за кожну годину роботи vCPU та близько 1 цента за кожну годину використання пам’яті у ГБ; розрахунок ведеться за секунду з мінімумом у одну секунду, тож запит тривалістю три секунди коштує саме три секунди, а не округленої до хвилини.
• Витрати на Gateway становлять приблизно пів цента за тисячу викликів MCP.
• Ціна на пам’ять складає 0,25 цента за кожні 1 000 збережених записів та 0,5 цента за кожні 1 000 отриманих записів.
• Використання Identity через Runtime або Gateway замість прямого виклику не оплачується, що стосується майже всіх сценаріїв використання.

Усе це не включає витрати на запуск моделей, які для будь-яких завдань, що виходять за межі простих тестів, становитимуть найбільшу суму у рахунку, і на які AgentCore не впливає. Це просто та сума, яку Bedrock бере за обрану модель. Нові акаунти отримують двісті доларів у кредитах AgentCore, що достатньо для створення та переробки подібного проекту кілька разів. Перед тим, як покладатися на будь-які цифри, слід перевірити офіційну сторінку з цінами, адже вони змінювалися вже неодноразово з моменту загального доступу та, ймовірно, зміняться знову.

Керована платформа чи самостійне хостинг

Стек для розміщення агентів, створений вручну, є корисним для порівняння, і чесний висновок має дві сторони. AgentCore забезпечує ізоляцію сеансів, керований шлюз MCP, стабільну пам’ять та модель автентифікації, які працюють разом; це швидше, ніж розробляти політики довіри IAM вручну, а саме на цих політиках тут було витрачено години. Це значна кількість роботи з інфраструктурою, яка не потребує додаткових зусиль. Для тих, чия робота полягає у створенні агентів, а не платформи для їх розміщення, така заміна, ймовірно, варта уваги.

Те, чого не надає платформа, — це оцінка того, що агенту слід дозволити робити, скільки це має коштувати в реальних умовах, чи будь-яка платформа автоматично означає використання найкраще задокументованого підходу від самої AWS. Також бракує стабільності. CLI було перебудовано один раз, і принаймні три випадки були виявлені, коли документація AWS не збігалася з реальним API у незначних, але важливих аспектах. Усе це не робить продукт поганим. Це просто описує молодий керований сервіс, який швидко розвивається, і про нього краще дізнатися перед початком використання, ніж з’ясовувати його особливості посеред процесу розгортання.

Усе це насправді було створено, а не лише описано. Для кожного ресурсу є Terraform, агент готовий, існують інструменти Lambda, а набір тестів не потребує облікових даних AWS, тож усе, що можна було перевірити, було перевірено спочатку. При подібному створенні найімовірніше проблеми виникнуть у двох місцях: у прапорці платформи ARM64 для образу та у параметрі allowed_clients у налаштуваннях авторизатора Cognito.