Kosztami Amazon Bedrock najlepiej zarządzać przez przypisywanie wydatków do użytkowników i aplikacji, bieżący podgląd wywołań oraz kontrolę budżetu dopasowaną do sposobu kierowania żądań. AWS ujmuje ten proces w pięciu etapach: przypisanie, obserwacja, egzekwowanie limitów, optymalizacja i regularne zarządzanie. To praktyczny model dla zespołów FinOps i inżynierii platformowej.
Pięć etapów kontroli kosztów
AWS rozdziela zadania między FinOps i inżynierię platformową, a przegląd kosztów traktuje jako wspólną pracę obu zespołów. FinOps odpowiada za przypisywanie wydatków, budżety i analizę odchyleń; zespół platformowy konfiguruje logowanie, metadane żądań, limity i zasady routingu. Cały cykl obejmuje:
- Przypisanie: ustal, który użytkownik, zespół lub aplikacja generuje koszt.
- Obserwacja: śledź zużycie i wykrywaj wzrost wydatków.
- Egzekwowanie: zdecyduj, czy przekroczenie budżetu ma wywołać alert, ograniczenie dostępu czy blokadę żądania.
- Optymalizacja: sprawdzaj, czy tańszy model lub ponowne użycie prefiksu promptu zmniejsza koszt bez pogorszenia jakości pracy.
- Bieżące zarządzanie: regularnie przeglądaj metryki i dostosowuj progi.
Przypisz wydatki użytkownikom i aplikacjom
W AWS Cost and Usage Report (CUR) 2.0 AWS opisuje pole line_item_iam_principal jako miejsce, w którym można znaleźć dane o tożsamości wywołującego. Atrybuty IAM można też wykorzystać jako tagi alokacji kosztów z prefiksem iamPrincipal/; po ich aktywowaniu AWS podaje, że pojawiają się w Cost Explorer w ciągu 24–48 godzin.
Wspólna rola IAM używana przez bramę (gateway) może sprawić, że wydatki będą przypisane do tej roli, a nie do konkretnych użytkowników. W opisanym przez AWS rozwiązaniu brama przyjmuje rolę Bedrock w imieniu każdego użytkownika: jego tożsamość trafia do nazwy sesji, a informacje biznesowe, takie jak zespół, do tagów sesji.
W przypadku stabilnych grup aplikacja–model–region AWS opisuje application inference profiles: osobny profil dla każdej takiej grupy, wywoływany za pomocą jego ARN. Amazon Bedrock Projects ma inny zakres: AWS wskazuje projekty dla obciążeń bedrock-mantle korzystających z Responses API lub Chat Completions API. Jeden projekt może obejmować wiele modeli.
Monitoruj wywołania, zanim pojawią się dane rozliczeniowe
CUR służy do analizy rozliczeń, ale według AWS przypisanie kosztów w tym raporcie może być opóźnione o około 24 godziny. W przykładzie AWS dashboard oparty na CloudWatch i OpenTelemetry pokazuje wydatki na programistę w ciągu minut. To operacyjny podgląd zużycia, a nie ten sam strumień danych co CUR.
AWS opisuje zapisywanie danych o żądaniu, odpowiedzi i metadanych w CloudWatch Logs, Amazon S3 albo w obu miejscach. CloudWatch nadaje się do bieżących zapytań operacyjnych; dane z S3 można analizować długoterminowo w Athena. Metadane żądania mogą wskazywać aplikację, przepływ pracy, dzierżawcę lub agenta, ale Bedrock nie wymusza jednego, spójnego schematu. Zespół powinien więc ustalić własne nazwy i stosować je konsekwentnie.
Wybierz sposób egzekwowania budżetu
AWS opisuje trzy możliwości. Wybór zależy przede wszystkim od tego, czy wystarczy powiadomienie po wzroście wydatków, czy limit ma zatrzymać żądanie, oraz czy klienci mogą kierować ruch przez bramę.
| Kontrola | Co dzieje się po osiągnięciu budżetu | Czas reakcji | Wymóg operacyjny |
| Budżety AWS i alerty | Zespół otrzymuje powiadomienie; wywołania nie są automatycznie blokowane. | Po wykryciu przekroczenia w danych budżetowych. | Bez twardej blokady żądań. |
| Egzekwowanie przez IAM | Zmiana polityki lub wstrzymanie poświadczeń może odebrać dostęp. | Asynchronicznie: aktualizacja polityki może potrwać od sekund do minut, a wstrzymanie poświadczeń zadziała przy ich odświeżeniu. | Sprawdza się przy bezpośrednich wywołaniach, bez dodatkowej bramy w ścieżce inferencji. |
| Egzekwowanie przez bramę | Brama odrzuca żądanie po przekroczeniu limitu; AWS opisuje odpowiedź HTTP 429. | Synchronicznie, w czasie krótszym niż sekunda według opisu AWS. | Klienci muszą kierować żądania przez bramę, którą trzeba wdrożyć, skalować i poddać przeglądowi bezpieczeństwa. |
Jeśli klienci wywołują Bedrock bezpośrednio, alerty lub kontrola IAM nie wymagają wstawiania dodatkowego elementu w ścieżkę żądania. Alerty same nie zatrzymają jednak dalszych wywołań. Brama daje synchroniczną blokadę, ale zadziała tylko wtedy, gdy ruch rzeczywiście przez nią przechodzi.
Oceniaj routing modeli i założenia prompt caching
AWS zaleca, by przed kierowaniem zadań do tańszego modelu sprawdzić jego jakość na konkretnym obciążeniu. Ta decyzja zależy od wyników danego zadania; sam udział wywołań obsługiwanych przez tańsze modele nie jest uniwersalnym celem.
W artykule AWS z października 2026 r. podano mnożniki prompt caching dla Anthropic Claude w regionie US East (N. Virginia). Zapis cache kosztuje 1,25× bazowej stawki za tokeny wejściowe przy TTL wynoszącym 5 minut albo 2× przy TTL wynoszącym godzinę. Odczyt cache opisano jako 0,1× dla Claude Sonnet 4.6 i Claude Haiku 4.5 oraz 0,05× dla Claude Sonnet 5.5 i Claude Opus 5.5.
Przykład dziesięciu wywołań zakłada jeden zapis prefiksu i dziewięć odczytów o tej samej liczbie tokenów wejściowych. Przy zapisie z TTL 5 minut obliczenie wygląda tak:
- Dla stawki odczytu 0,1×:
(1,25 + 9 × 0,1) / 10 = 0,215, czyli 21,5% kosztu niebuforowanych tokenów wejściowych prefiksu. - Dla stawki odczytu 0,05×:
(1,25 + 9 × 0,05) / 10 = 0,17, czyli 17% tego kosztu.
To wyliczenie dotyczy wyłącznie tokenów wejściowych prefiksu przy założonym ponownym użyciu. Nie obejmuje tokenów wyjściowych ani innych opłat za usługę. Jeśli zapisany prefiks nie zostanie ponownie odczytany, wyższa stawka za zapis nie zostanie zrównoważona tańszymi odczytami.
Przeglądaj metryki regularnie
AWS proponuje śledzić dzienny koszt na programistę, udział zadań kierowanych do oszczędniejszych modeli, współczynnik trafień odczytu cache oraz koszt udanego rezultatu. Podane przez AWS progi oceny są punktami wyjścia do kalibracji, a nie uniwersalnymi wartościami docelowymi. AWS sugeruje cotygodniowe przeglądy dla środowisk o szybko zmieniającym się zużyciu i przeglądy co dwa tygodnie w pozostałych przypadkach.