Amazon Bedrock AgentCore - architektura, komponenty i cennik
Jeśli szukasz szerszego kontekstu, AgentCore jest zarządzaną warstwą uruchomieniową pod platformą AWS Loom i jedną z odpowiedzi na agent sprawl. Tutaj skupiamy się na samym AgentCore: architekturze i kosztach.
Czym jest Amazon Bedrock AgentCore?
Bedrock AgentCore to zestaw zarządzanych, komponowalnych usług AWS do budowy, wdrażania i obsługi agentów AI na produkcji. Kluczowe słowo to komponowalny: to nie jest jeden monolityczny “produkt agentowy”, tylko kilka niezależnych usług, których możesz użyć razem albo wybiórczo. Każdą można wpiąć osobno, bez zobowiązania do całości.
Dwie rzeczy warto ustawić od razu:
- AgentCore jest neutralny wobec frameworku. Działa ze Strands Agents, LangGraph, CrewAI, Google ADK i innymi. Nie wymusza jednego SDK.
- AgentCore jest neutralny wobec modelu. Nie musisz używać modeli z Bedrock - możesz wskazać model spoza AWS. Bedrock jest modelem domyślnym, nie przymusem.
W praktyce AgentCore to warstwa “infrastruktura agentowa jako usługa”: bierzesz swoją logikę agenta i dostajesz gotowy runtime, dostęp do narzędzi, pamięć, tożsamość i telemetrię, bez stawiania tego samodzielnie na EC2 czy EKS.
Źródło, do którego się odwołujemy: strona Amazon Bedrock AgentCore oraz dokumentacja AgentCore.
Komponenty AgentCore
AgentCore składa się z kilku usług, które można łączyć w zależności od potrzeby. Oto co robi każda z nich.
| Komponent | Rola | Kiedy go potrzebujesz |
|---|---|---|
| Runtime | Bezserwerowe, izolowane środowisko uruchomieniowe agenta z długimi sesjami i izolacją per sesja | Zawsze - to serce, na którym działa agent |
| Gateway | Zamienia API, funkcje Lambda i serwery MCP w narzędzia dostępne dla agenta, z jednym punktem kontroli dostępu | Gdy agent korzysta z narzędzi i zewnętrznych API |
| Memory | Pamięć krótko i długoterminowa (kontekst sesji oraz wiedza utrwalona między sesjami) | Gdy agent ma pamiętać kontekst rozmowy lub użytkownika |
| Identity | Tożsamość agenta i propagacja uprawnień - agent działa w imieniu użytkownika, z jego zakresem dostępu | Gdy agent sięga po dane lub systemy w imieniu użytkownika |
| Observability | Śledzenie (tracing), metryki i wgląd w decyzje agenta, zintegrowane z CloudWatch | Zawsze na produkcji - bez tego nie zaudytujesz ani nie zdebugujesz |
| Browser | Zarządzana, izolowana przeglądarka do zadań webowych agenta | Gdy agent musi klikać i nawigować po stronach |
| Code Interpreter | Izolowane środowisko do wykonywania kodu przez agenta | Gdy agent generuje i uruchamia kod (analiza danych, obliczenia) |
Najważniejsza obserwacja architektoniczna: Runtime i Observability to fundament, którego użyjesz prawie zawsze. Reszta jest opcjonalna i dobierana pod przypadek. Prosty agent Q&A może potrzebować tylko Runtime + Observability. Agent, który sięga do systemów wewnętrznych i pamięta kontekst, wymaga Gateway, Memory i Identity. To właśnie znaczy “komponowalny”.
Jak komponenty łączą się w całość
Typowy przepływ dla agenta produkcyjnego wygląda tak:
- Runtime uruchamia logikę agenta (napisaną np. w Strands) w izolowanej sesji.
- Agent wywołuje model - domyślnie przez Amazon Bedrock, opcjonalnie model spoza AWS.
- Gdy agent potrzebuje narzędzia (API, Lambda, serwer MCP), przechodzi przez Gateway, który pełni rolę jednego punktu kontroli dostępu.
- Memory dostarcza kontekst sesji i wiedzę utrwaloną między sesjami.
- Identity pilnuje, by agent działał z uprawnieniami użytkownika, a nie z nadmiarowymi własnymi.
- Observability zbiera ślady i metryki każdego kroku, żebyś mógł odpowiedzieć “który agent, co zrobił, za ile i dlaczego”.
Jeśli w grze jest przeszukiwanie dokumentów wewnętrznych (RAG), pod spodem dochodzi warstwa wyszukiwania wektorowego - i to jest miejsce, w którym budżet potrafi zaskoczyć. Wracamy do tego w sekcji o kosztach. Szczegóły samej architektury RAG rozłożyliśmy w osobnym artykule o architekturze RAG na AWS.
Projektujesz agenta na AgentCore i liczysz TCO?
Umów bezpłatną rozmowę 30 min
Ile kosztuje AgentCore - model kosztów
AgentCore jest rozliczany za konsumpcję: płacisz za to, czego używasz, per komponent. Nie ma opłaty licencyjnej za “AgentCore” jako taki - koszt to suma zużycia poszczególnych usług plus koszt inferencji modeli w Bedrock (rozliczany osobno, per token).
Koszt agenta produkcyjnego składa się z kilku warstw:
| Warstwa kosztu | Model rozliczenia | Uwaga do budżetu |
|---|---|---|
| Runtime | Za zużycie zasobów uruchomieniowych (czas i zasoby sesji) | Skaluje się z liczbą i długością sesji agenta |
| Gateway | Za wywołania narzędzi przechodzące przez bramę | Rośnie z liczbą wywołań narzędzi na sesję |
| Memory | Za przechowywaną i przetwarzaną pamięć | Długoterminowa pamięć per użytkownik potrafi narastać |
| Observability | Przez CloudWatch (logi, metryki, ślady) | Wolumen telemetrii = koszt; łatwo niedoszacować |
| Inferencja modeli | Bedrock, per token (input + output), zależnie od modelu | Zwykle największa pojedyncza pozycja przy dużym ruchu |
| Wyszukiwanie wektorowe (jeśli RAG) | Najczęściej OpenSearch Serverless - koszt stały za minimalne OCU | Ta pozycja zaskakuje najczęściej - patrz niżej |
Pozycja, którą prawie wszyscy pomijają
Jeśli agent robi RAG (przeszukuje dokumenty wewnętrzne), zazwyczaj pod spodem stoi OpenSearch Serverless jako baza wektorowa. A OpenSearch Serverless ma minimalny, stały koszt za OCU (OpenSearch Compute Units) - rzędu kilkuset dolarów miesięcznie za minimalną konfigurację, niezależnie od ruchu. Nawet agent, który nie obsłużył ani jednego zapytania, generuje taki koszt, dopóki kolekcja wektorowa istnieje.
To najczęściej niedoszacowana pozycja w budżetach agentowych, bo cała reszta jest konsumpcyjna (“płacę za to, czego użyję”), a ta jedna jest stałym progiem wejścia. Przy jednym agencie to znośne. Przy dziesięciu osobnych kolekcjach wektorowych - to już realna kwota, która płynie co miesiąc bez względu na wykorzystanie.
Praktyczny wniosek FinOps: konsoliduj wyszukiwanie wektorowe tam, gdzie się da, zamiast stawiać osobną kolekcję dla każdego agenta. To dokładnie ten sam mechanizm, który opisaliśmy przy agent sprawl - koszt bierze się z rozproszenia, nie z pojedynczej usługi.
AgentCore a Loom - jak to się ma do siebie
Krótko, bo to częste pytanie: AgentCore to zarządzane elementy (runtime, brama, pamięć, tożsamość, obserwowalność). Loom to opiniotwórcza warstwa nadzoru na ich wierzchu (interfejs, cykl życia, tagowanie, rejestr, human-in-the-loop).
Innymi słowy: AgentCore możesz używać bez Loom - i dla wielu zespołów to najrozsądniejszy start (zarządzane usługi plus własna cienka warstwa nadzoru). Loom dokłada gotowy “paved path”, ale jako kod referencyjny AWS Labs, który bierzesz na utrzymanie. Pełną analizę “wdrożyć Loom, adaptować czy wybrać alternatywę” rozłożyliśmy w artykule o AWS Loom.
Kiedy AgentCore ma sens, a kiedy nie
| AgentCore pasuje, gdy... | AgentCore warto przemyśleć, gdy... |
|---|---|
| Chcesz uruchomić agenta na produkcji bez stawiania własnego runtime na EC2/EKS | Masz już dojrzałą, własną platformę uruchomieniową agentów, która spełnia wymogi |
| Zależy Ci na neutralności wobec frameworku i modelu (Strands, LangGraph, model spoza AWS) | Jesteś świadomie multi-cloud i nie chcesz warstwy uruchomieniowej związanej z AWS |
| Potrzebujesz gotowej tożsamości, pamięci i obserwowalności bez pisania ich od zera | Twój przypadek jest na tyle prosty, że zarządzane komponenty to nadmiar |
| Chcesz płacić konsumpcyjnie i widzieć koszt per komponent | Masz stały, przewidywalny wolumen, gdzie własna infrastruktura wychodzi taniej w TCO |
Dla porównania samej warstwy modelu - Bedrock kontra SageMaker kontra self-hosting na EKS - mamy osobny, szczegółowy artykuł o uruchamianiu LLM na AWS.
Kiedy warto zaangażować zewnętrznego partnera
- Model kosztów i TCO. Rozliczenie konsumpcyjne per komponent plus stały koszt wyszukiwania wektorowego trudno oszacować bez doświadczenia - a to decyduje o budżecie.
- Projekt tożsamości i least-privilege. Agent działający w imieniu użytkownika, z dostępem do danych produkcyjnych, wymaga poprawnie zaprojektowanej warstwy Identity.
- Wybór: AgentCore, Loom czy własna warstwa. To decyzja architektoniczna o długim ogonie utrzymaniowym, nie jednorazowe wdrożenie.
- Konsolidacja RAG i kosztów wektorowych. Zbicie rozproszonych kolekcji w jedną, wspólną warstwę to często najszybszy zwrot w budżecie agentowym.
Podsumowanie
Bedrock AgentCore to zarządzane, komponowalne usługi do uruchamiania agentów AI na produkcji: Runtime i Observability jako fundament, Gateway, Memory, Identity, Browser i Code Interpreter dobierane pod konkretny przypadek. Neutralny wobec frameworku i modelu, rozliczany konsumpcyjnie.
Trzy rzeczy do zapamiętania:
- To komponowalne usługi, nie monolit. Użyj tylko tych komponentów, których naprawdę potrzebujesz - prosty agent to często tylko Runtime + Observability.
- Koszt to suma warstw plus inferencja w Bedrock per token. Przy dużym ruchu inferencja jest zwykle największą pozycją.
- Uważaj na stały koszt wyszukiwania wektorowego (OpenSearch Serverless) przy RAG - kilkaset dolarów miesięcznie niezależnie od ruchu, per kolekcja. Konsoliduj, zamiast mnożyć.
Projektujesz agenta na AgentCore i liczysz TCO?
Umów bezpłatną 30-minutową rozmowę. Pomagamy zespołom zaprojektować architekturę agenta na Bedrock AgentCore, oszacować realny koszt per komponent i uniknąć niedoszacowanych pozycji jak stały koszt wyszukiwania wektorowego.
