# Pięcioetapowy model zarządzania kosztami Amazon Bedrock

- Source: MechNext — https://mechnext.eu/pl/article/57-a-five-stage-framework-for-managing-amazon-bedrock-costs
- Published: 2026-10-31
- Updated: 2026-10-31
- Category: Industry News
- Language: pl (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=zh, ?lang=ru)

> Wpis AWS łączy atrybucję kosztów, obserwowalność żądań, egzekwowanie budżetów, optymalizację platformy i cykliczne przeglądy operacyjne w jeden model.

Wpis AWS skierowany do zespołów FinOps i inżynierii platformowej przedstawia zarządzanie kosztami Amazon Bedrock jako ciągłą pętlę obejmującą pięć etapów: **atrybucję, obserwację, egzekwowanie, optymalizację i eksploatację**. Etapy są ze sobą powiązane. Atrybucja wskazuje właściciela wydatku, obserwacja dodaje kontekst żądań, egzekwowanie reaguje na przekroczenia budżetu, optymalizacja koryguje ustawienia platformy, a eksploatacja zamienia sygnały w regularny proces przeglądu.

### Przypisanie wydatków do właściciela

Amazon Bedrock automatycznie przypisuje koszty inferencji do wywołującego podmiotu IAM. ARN wywołującego znajduje się w kolumnie `line_item_iam_principal` raportu CUR 2.0. Jest to podstawowe powiązanie zużycia z tożsamością techniczną, która zainicjowała żądanie.

Bardziej opisowy podział można uzyskać za pomocą tagów podmiotów IAM aktywowanych jako tagi alokacji kosztów. W CUR 2.0 pola te pojawiają się z prefiksem `iamPrincipal/`, a w Cost Explorer są dostępne w kategorii IAM w ciągu 24–48 godzin od aktywacji. Opóźnienie ma znaczenie podczas analizy najnowszych danych, ponieważ świeżo aktywowany tag nie musi być widoczny natychmiast.

Brama korzystająca z jednej współdzielonej roli IAM przypisuje wszystkie związane z nią wydatki Amazon Bedrock do tej roli. Sama rola nie pozwala więc rozróżnić użytkowników działających za bramą. Rozwiązaniem opisanym we wpisie są osobne sesje roli dla użytkowników, przenoszące tożsamość w nazwie sesji i dodatkowe atrybuty w tagach sesji.

### Atrybucja aplikacji i obserwacja żądań

Application inference profiles zapewniają atrybucję według aplikacji, modelu i regionu dla obciążeń korzystających z `bedrock-runtime`. Projekty mogą obejmować wiele modeli i zapewniać atrybucję obciążeń zgodnych z OpenAI w punkcie końcowym `bedrock-mantle`. Wybór mechanizmu zależy zatem od sposobu, w jaki obciążenie łączy się z usługą, oraz od oczekiwanego poziomu reprezentacji właściciela.

Rejestrowanie wywołań modeli Amazon Bedrock może wysyłać dane żądań, odpowiedzi i metadane do CloudWatch Logs, Amazon S3 albo do obu miejsc. Amazon Bedrock nie wymusza jednak metadanych żądania. Wpis zaleca centralne wstrzykiwanie i normalizowanie obowiązkowych metadanych przez wspólną nakładkę SDK lub bramę. Pokrycie metadanymi powinno być śledzone jako wskaźnik kondycji platformy, pokazujący, jaka część ruchu zawiera wymagany kontekst.

### Trzy poziomy egzekwowania budżetu

- **Monitorowanie i alerty** sygnalizują przekroczenie bez blokowania żądań.
- **Asynchroniczna odmowa oparta na IAM** zmienia dostęp po wystąpieniu przekroczenia.
- **Synchroniczne blokowanie w bramie** odrzuca żądanie, gdy użytkownik lub zespół przekroczył limit.

Egzekwowanie przez IAM może zacząć działać od kilku sekund do kilku minut po żądaniu powodującym przekroczenie albo przy następnym odświeżeniu poświadczeń. Brama może natomiast zwrócić `HTTP 429`, gdy użytkownik lub zespół przekroczy limit. Różnica ta oddziela opóźnioną zmianę autoryzacji od decyzji podejmowanej bezpośrednio na ścieżce żądania.

Architektura ogranicza dostępne opcje. Przy bezpośrednich połączeniach z Amazon Bedrock bez serwera proxy, według wpisu, możliwe są tylko monitorowanie z alertami oraz egzekwowanie oparte na IAM. Synchroniczna blokada wymaga obecności bramy na ścieżce ruchu.

### Optymalizacja we właściwym kontekście cenowym

Ekonomikę pamięci podręcznej należy oceniać z uwzględnieniem daty, regionu i modelu. Według cen cytowanych dla modeli Anthropic Claude w US East (N. Virginia) w październiku 2026 roku pięciominutowy zapis w pamięci podręcznej rozliczano według 1,25-krotności podstawowej stawki wejściowej, a zapis godzinny według dwukrotności tej stawki. Mnożniki odczytu z pamięci podręcznej różniły się zależnie od modelu. Dane te dotyczą wyłącznie wskazanego czasu i zakresu.

### Stały rytm operacyjny

Opisany pulpit operacyjny śledzi udział poszczególnych modeli, odsetek nieudanych żądań, skuteczność pamięci podręcznej oraz pokrycie metadanymi. Wskaźniki pokazują, czego używa platforma, gdzie żądania zawodzą, czy pamięć podręczna jest skuteczna i czy dostępny jest kontekst potrzebny do atrybucji oraz analizy.

Dla szybko zmieniających się flot zalecane są cotygodniowe przeglądy karty wyników, a w pozostałych przypadkach przeglądy co dwa tygodnie. Taki rytm domyka pętlę, umożliwiając ponowną ocenę własności kosztów, widoczności żądań, działania zabezpieczeń i decyzji optymalizacyjnych. Jest to więc model operacyjny oparty na regularnych decyzjach, a nie jednorazowy raport kosztowy.