Де я б дивився на ціну в першу чергу
Я б не починав з Enterprise або Team. Для такого кейсу це зазвичай не перша розвилка, а вже наступний етап, коли у вас зрозумілий місячний обсяг, SLA і переговорна сила щодо знижок.
Якщо задача звучить як Claude-агент всередині AWS, який отримує дані від бекенду, розраховує скоринг фінансових даних і іноді ходить назад в API, то у мене на столі залишаються два реальні варіанти: прямий Anthropic API і Claude через AWS Bedrock.
Я подивився поточні ціни на березень 2026 року, і картина досить приземлена: on-demand тарифи у прямого API та Bedrock для Sonnet-класу приблизно однакові. Умовно близько $3 за 1M input tokens і $15 за 1M output tokens. Тобто магії в стилі «в Bedrock все раптово дорожче, тому що це AWS» тут зазвичай немає.
І ось тут починається найцікавіше. Економіка змінюється не на базовій ціні токена, а на режимах використання.
Чому Bedrock раптом виглядає розумнішим для скорингу
У фінансовому скорингу у вас майже завжди повторюється каркас запиту: system prompt, правила оцінки, схема відповіді, обмеження, формат JSON. Змінюються дані клієнта, транзакції, витяги з документів. Це ідеальний сценарій під кешування промптів (prompt caching).
У Bedrock кешування не декоративне. Якщо у вас один і той самий великий префікс промпту крутиться знову і знову, читання з кешу обходиться значно дешевше, ніж повторний повний прогін входу. На великих обсягах це вже не «приємний бонус», а цілком відчутний рядок економії.
Другий козир Bedrock, який мені подобається для такого кейсу, це асинхронна або пакетна (batch) обробка. Якщо скоринг не зобов'язаний відповідати за секунди і ви можете рахувати пачками, AWS дає знижку до 50% відносно on-demand. Для нічних прогонів, перерахунку портфеля, anti-fraud черг і bulk-скорингу це майже очевидний вибір.
Якщо сказати зовсім просто: realtime scoring краще вважати premium path, а все, що терпить затримку, треба виштовхувати в batch. Саме так зазвичай і виглядає здорова AI-архітектура, коли рахунок за LLM не починає дратувати CFO.
Коли прямий API теж є нормальним варіантом
Я б не ховав прямий Anthropic API. Він нормальний, якщо AWS у вас не центральна платформа, якщо потрібна більш пряма робота з Anthropic-фічами без очікування їх появи в Bedrock, або якщо у вас вже зібраний свій gateway-контур під зовнішні моделі.
Але якщо ви все одно живете всередині AWS, прямий API часто тягне за собою зайві деталі: окрему авторизацію, мережеву обв'язку, проксі-шар, контроль egress, аудит викликів і додаткові місця, де можна випадково ускладнити собі життя. Воно працює, звісно. Просто архітектура ШІ-рішень виходить менш акуратною.
Для regulated finance це особливо помітно. Bedrock простіше вбудовується в IAM, VPC, CloudWatch, guardrails навколо даних і загальний контур безпеки. Я б за це не переплачував, але тут якраз часто і немає переплати за токени.
Що б я зробив на практиці
Якби мені принесли такий проєкт у Nahornyi AI Lab, я б збирав перший production-контур на Bedrock і одразу ділив трафік на два класи.
- Терміновий скоринг, де відповідь потрібна швидко: on-demand inference.
- Масовий і нетерміновий перерахунок: batch або async зі знижкою 50%.
- Повторювані системні інструкції та шаблони: через prompt caching.
Плюс я б дуже жорстко стежив за output tokens. У таких системах саме вони часто роздувають бюджет сильніше за вхід. Якщо агент любить багатослівність, красивий reasoning і довгі пояснення, рахунок злітає швидше, ніж здається.
Тому для фінансового скорингу я майже завжди стискаю відповіді у структурований JSON, короткі label-поля, score, confidence, reasons з лімітом довжини. Це банально дешевше і краще для подальшої автоматизації за допомогою ШІ.
Мій короткий висновок такий: якщо ви вже в AWS і вам потрібен Claude-агент як API endpoint для скорингу, Bedrock зазвичай виглядає найпрактичнішим варіантом за ціною та експлуатацією. Enterprise має сенс обговорювати пізніше, коли у вас вже є підтверджений обсяг і зрозуміла модель навантаження.
Цей розбір я зробив як Вадим Нагорний, Nahornyi AI Lab. Я сам проєктую і збираю такі контури: впровадження ШІ, ШІ інтеграція з бекендом, маршрутизація batch і realtime-навантаження, контроль вартості на LLM у production.
Якщо хочете, я можу допомогти розкласти саме ваш кейс по цифрах: якою буде токен-економіка, де ставити caching, а де краще зробити ШІ-автоматизацію через batch. Пишіть, обговоримо ваш проєкт разом із Nahornyi AI Lab.