AWS AgentCore vs Google Vertex vs Microsoft Foundry: platformy agentowe w chmurze - porównanie

AWS AgentCore vs Google Vertex vs Microsoft Foundry: platformy agentowe w chmurze - porównanie

Każdą z platform opisaliśmy osobno: Amazon Bedrock AgentCore, Google Vertex AI oraz Microsoft Foundry Agent Service. Ten materiał to porównanie, do którego zmierzały te szczegółowe porównania.

Trzy platformy, każda w jednym zdaniu

Nazwy w 2026 roku się zmieniały jak i cały rynek, więc najpierw je ustalmy:

• AWS - Bedrock AgentCore. Zestaw składanych usług zarządzanych (Runtime, Gateway, Memory, Identity, Observability, Browser, Code Interpreter) do uruchamiania agentów na produkcji. Neutralny wobec frameworka i modelu.
• Google - Vertex AI Agent Engine. Zarządzany runtime hostowany dla agentów, część Vertex AI Agent Builder - który Google włączył pod markę Gemini Enterprise Agent Platform na Cloud Next 2026. Platforma pod spodem jest ta sama; o zmianie nazwy piszemy w przewodniku po Vertex AI.
• Microsoft - Foundry Agent Service. Runtime agentów wewnątrz Microsoft Foundry (dawniej Azure AI Foundry), z darmową warstwą orkiestracji dla agentów natywnych i płatnym runtime kontenerowym dla agentów hostowanych.

Trzy różne nazwy na ten sam pomysł: przynieś swojego agenta, a dostaniesz zarządzane miejsce do jego uruchomienia - gotowe na produkcyjny ruch.

Wspólny wzorzec (co je łączy)

Zanim o różnicach, wspólny grunt - bo jest realny i stanowi większość obrazu:

• Przynosisz swój framework. Wszystkie trzy uruchamiają agentów zbudowanych w zewnętrznych frameworkach. LangGraph działa na wszystkich trzech. Każda promuje też własne domyślne SDK: AWS ma Strands, Google ma ADK (Agent Development Kit), Microsoft ma Microsoft Agent Framework (połączenie Semantic Kernel i AutoGen).
• Zarządzany, izolowany runtime. Każda daje izolowane sesyjnie miejsce na uruchomienie agenta bez stawiania własnego klastra EC2/GKE/AKS, z autoskalowaniem i (na AWS oraz Azure) skalowaniem do zera, tak że bezczynni agenci kosztują niewiele albo nic.
• Rozliczanie według zużycia. Brak “licencji na platformę agentową”. Płacisz za to, co agent zużywa - compute w czasie pracy plus pamięć, narzędzia i pozostałe elementy.
• Inferencja modelu jest osobno - i zwykle to największa pozycja cennikowa. Na wszystkich trzech platformach tokeny, które agent wysyła do modelu, są rozliczane oddzielnie, przez Bedrock / Vertex Model Garden / Foundry Models. Przy realnym ruchu inferencja zwykle przyćmiewa koszt runtime. To najważniejsza rzecz do zrozumienia w rachunkach wszystkich trzech rozwiązań.

Zatem wybór platformy rzadko decyduje o twoim całkowitym koszcie agenta. Decyduje o nim model i wolumen. Wybór platformy dotyczy dopasowania, lock-inu i - jak zaraz zobaczymy - tego, jak łatwo w ogóle dowiesz się, ile to kosztuje.

Zestawienie obok siebie

Stawki poniżej to ceny cennikowe za zarządzany runtime agenta, stan na październik 2026, i zmieniają się w zależności od regionu oraz w czasie. Inferencja modelu i usługi towarzyszące są dodatkowe na wszystkich trzech rozwiązaniach. Zweryfikuj koszt na stronie cennika każdego dostawcy przed planowaniem budżetu.

Asymetria przejrzystości cennika (fragment wart przeczytania dwa razy)

Spójrz jeszcze raz na wiersz “opublikowana stawka runtime”. Dwóch z trzech dostawców publikuje liczbę, którą wstawisz do arkusza; jeden nie.

• AWS publikuje stawki AgentCore otwarcie - $0,1276 za vCPU-godzinę, $0,0169 za GB-godzinę, stawki Browser i Code Interpreter też. Koszt runtime agenta AgentCore oszacujesz z publicznej strony, zanim w ogóle się zalogujesz.
• Google publikuje stawkę Agent Engine otwarcie - około $0,0864 za vCPU-godzinę, z darmowym miesięcznym limitem, który pokrywa lekkie użycie w całości. Znów: do oszacowania z publicznej strony.
• Microsoft nie publikuje liczb per jednostka dla Foundry Agent Service. Strona cennika pokazuje strukturę kosztów - agenci natywni za darmo, agenci hostowani rozliczani według zużycia kontenera, narzędzia mierzone - ale faktyczne liczby per vCPU-godzina i per GiB-godzina leżą za wyborem regionu i waluty oraz logowaniem. Aby je zdobyć, uruchamiasz kalkulator cenowy Azure albo rozmawiasz ze specjalistą ds. sprzedaży.

To nie jest zarzut do platformy i nie twierdzenie, że Foundry jest droższy - zając swoje potrzeby możesz łatwo to zweryfikować logując się na platformie. Ale to realna różnica w koszcie oceny. Jeśli robisz szybkie trójstronne szacowanie na kolanie, zanim wybierzesz kierunek, zrobisz je dla AWS i GCP z ich publicznych stron, a dla Azure nie. Dla zespołu neutralnego wobec dostawcy to ma znaczenie, a większość porównań “X vs Y vs Z” po cichu to pomija, bo jest to niepochlebne dla jednej strony. My tego nie pomijamy.

Realny wniosek praktyczny: nie próbuj rankować tych trzech wyłącznie po cenie runtime. AWS i GCP porównasz wprost (cennikowa stawka GCP jest niższa za vCPU-godzinę, a darmowy limit pomaga lekkim obciążeniom); dla Azure musisz wymodelować to sam. I pamiętaj, że runtime to mała pozycja - inferencja to miejsce, w którym pojawią się realne koszty we wszystkich trzech rozwiązaniach.

Co do czego pasuje

Ponieważ wybór platformy dotyczy głównie grawitacji ekosystemu, przydatne pytanie to nie “która jest najlepsza”, ale “na czym twój zespół już pracuje”.

W praktyce decyzję zwykle podejmuje za ciebie to, gdzie zajdują się już twoja baza tożsamości, dane i zespół. Środowiska w pełni oparte o BigQuery i Looker nie tak łatwo przeniesć na AWS, aby zaoszczędzić ułamek centa na vCPU-godzinie, i słusznie. Platformy są na tyle bliskie możliwościami, że to dopasowanie ekosystemowe, a nie tabela funkcji, jest właściwym rozstrzygnięciem.

Czego to porównanie NIE rozstrzyga

• Twojego faktycznego rachunku. Stawka runtime to mała część. Tokeny inferencji modelu dominują przy realnym ruchu, a to wybór modelu (Gemini vs Claude vs model open-weight), nie wybór platformy. Dwa zespoły na tej samej platformie mogą mieć skrajnie różne rachunki.
• Kosztów pamięci i narzędzi. Każda platforma mierzy pamięć i narzędzia inaczej; w skali to się sumuje i łatwo ich niedoszacować. Stawka per vCPU-godzina to nie cała historia runtime.
• Lock-inu i kosztu migracji. Przeniesienie agenta między tymi runtime’ami nie jest darmowe - domyślne SDK się różnią, a integracje tożsamości/pamięci/narzędzi są specyficzne dla platformy. Przenośność LangGraph to łagodzi, ale nie rozwiązuje wszystkiego.

Kiedy warto zaangażować partnera

• Sam wybór międzychmurowy. Jeśli jesteś naprawdę neutralny wobec chmury, właściwa platforma zależy od trzeźwego spojrzenia na to, gdzie już są twoje dane, tożsamość i zespół - oraz od kosztu zmiany, jeśli to się zmieni.
• TCO w trzech modelach rozliczeń. Porównanie zużycia per komponent (AWS), per vCPU-godzina plus darmowy limit (GCP) i darmowe-natywne-ale-zamknięte-hostowane (Azure) to nie jednolinijkowa kalkulacja - a liczby Azure są za kalkulatorem.
• Problem “liczb za logowaniem” w Azure. Jeśli Foundry jest kandydatem, ktoś musi przejść prez kalkulator i rozmowę sprzedażową, by zdobyć realne liczby. To dokładnie ten rodzaj pracy, którą partner wykonuje, zanim się zobowiążesz.

Podsumowanie

AWS AgentCore, Google Vertex AI Agent Engine i Microsoft Foundry Agent Service to ta sama podstawowa oferta od trzech chmur: zarządzany, izolowany runtime, na który przynosisz swój framework i uruchamiasz agentów na produkcji. Trzy rzeczy do zapamiętania:

1. Zbiegają się we wzorcu, różnią w szczegółach. Ten sam zarządzany runtime “przynieś swój framework”; różne domyślne SDK (Strands / ADK / Microsoft Agent Framework), modele pamięci i ekosystemy.
2. Przejrzystość cennika nie jest równa. AWS i Google publikują stawki runtime per vCPU-godzina; Azure trzyma stawki Foundry za kalkulatorem. Dwie z trzech oszacujesz na kolanie; trzecia wymaga kalkulatora.
3. To nie platforma decyduje o twoim koszcie. Inferencja modelu dominuje rachunek na wszystkich trzech. Wybieraj po grawitacji ekosystemu, a potem zarządzaj wydatkiem na model i wolumen - tam naprawdę są pieniądze.

Najczęstsze pytania

Wybierasz platformę agentową między AWS, GCP a Azure?

Umów bezpłatną 30-minutową rozmowę. Pomagamy zespołom wybrać między AgentCore, Vertex Agent Engine a Foundry na uczciwych kryteriach - dopasowanie ekosystemowe, realne TCO w trzech modelach rozliczeń i liczby Azure, które żyją za kalkulatorem.

Umów rozmowę Wyślij wiadomość