Wynegocjowana cena modelu nie musi być ceną dostępną dla obciążenia. Instrukcja AWS z 13 października dotycząca zarządzanych uprawnień rozwiązuje tę lukę dla kwalifikujących się modeli zewnętrznych w Amazon Bedrock: przyjęcie prywatnej oferty Marketplace tworzy licencję, lecz jej dystrybucja może pozostawić granty zaakceptowane, ale wyłączone.
AWS opisuje dwa rozwiązania. Skrypt Python pozwala administratorowi jednorazowo sprawdzić i aktywować otrzymane licencje. Przykład CDK sterowany zdarzeniami obsługuje kolejne umowy przez weryfikację sprzedawcy, tworzenie grantów, aktywację, ponowienia i dzienniki. Żadne rozwiązanie nie negocjuje rabatu ani nie dowodzi oszczędności samą instalacją.
Celem jest udostępnienie centralnych warunków handlowych kontom rozwojowym, produkcyjnym, działowym lub regionalnym. Wzrastają jednak skutki pomylenia sprzedawcy lub zakresu kont. Zatwierdzenie zakupu, aktywacja techniczna i sprawdzenie rachunku pozostają różnymi zdarzeniami.
Licencja, grant i opłata to osobne stany
AWS Marketplace Private Pricing Offers, czyli MPPO, określają uzgodnione warunki. Dla odpowiednich modeli Bedrock wspieranych przez License Manager przyjęcie oferty tworzy licencję. Zarządzane uprawnienia przekazują prawo przez grant całej organizacji, wybranym jednostkom organizacyjnym albo wskazanym kontom.
Przy włączonych wszystkich funkcjach AWS Organizations granty organizacyjne przyjmowane są automatycznie, ale pozostają wyłączone do aktywacji. AWS wskazuje ACTIVE i WORKFLOW_COMPLETED jako stany uruchamiające stawkę. Zakupy mogą więc widzieć zaakceptowaną ofertę i skonfigurowane cele, chociaż wykorzystanie nadal omija uzgodnioną ścieżkę cenową.
Przy samym rozliczeniu skonsolidowanym bez pełnych funkcji Organizations konta odbiorców muszą przyjąć grant ręcznie. Centralny rachunek nie oznacza pełnej integracji. Zasoby kontroli licencji obsługiwane są w us-east-1, nawet gdy wywołania modeli odbywają się w innych obsługiwanych regionach Bedrock.
Za przekazane wykorzystanie płaci pierwotne konto subskrypcji, zamiast tworzyć osobne subskrypcje odbiorców. Ułatwia to widoczność, lecz nie usuwa podziału wewnętrznego. Tagi, kategorie kosztów i właściciele obciążeń wspierają prezentację i rozdział kosztów. Stan licencji, wywołanie modelu oraz rzeczywiste opłaty wymagają osobnej obserwacji.
Skrypt jest ograniczoną czynnością operatora
Samodzielne narzędzie Python wyświetla licencje otrzymane przez konto zarządzające. Domyślnie tworzy plan dry-run, bez tworzenia i aktywacji grantów. Operator sprawdza wystawcę, licencję i zakres, a następnie podaje --apply oraz identyfikator konta zarządzającego.
Tworzy ono i aktywuje granty obejmujące całą organizację dla wybranych licencji. Pasuje do znanej zaległości lub rzadkich umów bez stałej infrastruktury CDK. Nie jest ciągłym silnikiem polityk.
Kluczowy brak to lista dozwolonych sprzedawców. Granicą zaufania jest człowiek porównujący każdego wystawcę z dokumentami zakupowymi i przyjętą umową Marketplace. Cykliczne bezobsługowe przetwarzanie wszystkiego, co przyjdzie, usunęłoby tę granicę.
Zakres całej organizacji też wymaga świadomej zgody. Firma regulowana może oddzielać produkcję kliniczną od badań albo ograniczać model do zatwierdzonych jednostek. Technicznie poprawna aktywacja może przekroczyć biznesowe upoważnienie.
Następnie należy sprawdzić License Manager i reprezentatywne opłaty w Cost Explorer, gdy nadejdą dane. AWS ostrzega przed opóźnieniem od godzin do dni. Aktywny grant potwierdza aktywację, nie gwarantuje natychmiast poprawnego rachunku. Narzędzie sprawdzające rabat wymaga wystawcy i kont odpowiadających rzeczywistej umowie.
CDK reaguje na umowę, nie gotową licencję
Wariant ciągły łączy EventBridge, Lambda, DynamoDB, License Manager i CloudWatch. Reguła na domyślnej magistrali w us-east-1 dopasowuje źródło aws.agreement-marketplace oraz typ szczegółów Purchase Agreement Created - Acceptor.
Lambda sprawdza listę sprzedawców w DynamoDB. Dla zatwierdzonego podmiotu odnajduje licencję, tworzy grant dla skonfigurowanych celów i żąda aktywacji przez CreateGrantVersion ze statusem aktywnym.
Zdarzenie umowy nie gwarantuje gotowości dalszych zasobów. Nowy grant może jeszcze nie nadawać się do aktywacji, dlatego przykład ponawia operację, gdy License Manager kończy swój proces. CloudWatch zapisuje aktywacje, odroczenia i pominięcia. Wyjaśnia przetwarzanie, ale nie zastępuje zatwierdzenia sprzedawcy lub celu.
Wdrożenie musi pochodzić z konta zarządzającego Organizations w us-east-1, przy pełnych funkcjach organizacji i odpowiedniej ofercie Bedrock opartej na License Manager. SaaS jest poza zakresem. To nie uniwersalny procesor prywatnych ofert Marketplace.
License Manager i Marketplace wymagają zaufanego dostępu oraz ról powiązanych z usługą. Narzędzie bootstrap sprawdza warunki, a tryb apply po potwierdzeniu konta może włączyć integracje i utworzyć role. Konfiguracja określa organizację, zweryfikowanych sprzedawców, powiadomienia i opcjonalne cele. Bez własnych celów dystrybucja obejmuje całą organizację; jednostki lub konta ją zawężają.
Tożsamość sprzedawcy i cele stanowią granicę kontroli
AWS nazywa listę sprzedawców granicą bezpieczeństwa. Identyfikatory kont należy sprawdzić w przyjętej umowie albo otrzymanej licencji, nie tylko po nazwie wyświetlanej. Niezweryfikowany lub zbyt szeroki wpis może dopuścić niezamierzone granty we wszystkich celach.
Nie oznacza to automatycznie nieograniczonego dostępu modelu do danych. IAM, kontrole usług, uprawnienia modelu i projekt aplikacji nadal regulują użycie. Dystrybucja zmienia kwalifikację do warunków handlowych i może centralizować rachunek, ale nie jest równoznaczna ze wszystkimi prawami do danych.
Jednostki organizacyjne wykorzystują istniejącą hierarchię. Wskazane konta są węższe, lecz wymagają utrzymania przy dodawaniu obciążeń. Cała organizacja bywa wygodna dla platformy centralnej; branża regulowana może wymagać zgody według środowiska i klasy danych.
Zmiany sprzedawców, organizacji i celów potrzebują przeglądu oraz kontrolowanego wdrożenia. Alerty powinny obejmować awarie i ponawiane odroczenia. Dostarczenie zdarzenia i gotowość licencji to osobne sprawy; należy planować opóźnienia, duplikaty i braki, nie uznawać ciszy w logach za kompletność.
Uzgodnienie porównuje przyjęte umowy, otrzymane licencje, zatwierdzone cele i aktywne granty. Wykrywa brak aktywacji, obcy cel lub grant bez aktualnej zaakceptowanej umowy. Skrypt może pomagać w odzyskiwaniu, lecz musi mieć wspólne zarządzanie ze stosem automatycznym, by unikać duplikatów i konfliktów. Mapowania wystawców, zgody i procedury odzyskania powinny być dostępne podczas incydentu.
Centralne zakupy nie interpretują kontraktu
Zakupy odpowiadają za umowę, inżynieria platformy za dystrybucję i aktywację, bezpieczeństwo za zaufanie i zakres, FinOps za opłaty i podział. Niejasne obowiązki mogą zastąpić wiele małych opóźnień jednym centralnym.
Klient AWS Heidi Health podaje, że wspiera miliony konsultacji klinicznych tygodniowo przy użyciu zewnętrznych modeli bazowych. Marcus Lau, kierujący platformą, wskazał prywatne ceny jako pomoc w przypisywaniu użycia i warunków między kontami i jednostkami oraz podkreślił automatyczne granty dla nowych modeli. Jest to wypowiedź klienta, nie niezależny dowód oszczędności.
Odnowienia, nowe umowy i reorganizacje wymagają dalszych kontroli. Automatyzacja nie interpretuje zakresu, zmian ani dat obowiązywania. Umowa przyjęta z przyszłym początkiem nie udostępnia nowych warunków od razu. Nowy model, region lub wariant produktu nie zostaje automatycznie objęty istniejącą umową.
Sukces wymaga trzech zgodnych dowodów
Najpierw należy mierzyć czas od kwalifikującego zdarzenia do aktywnego stanu, uwzględniając odrzucenie sprzedawcy, opóźnienia wyszukiwania, odroczenia i ręczne interwencje. Potem uzgadniać umowy, licencje, cele i granty po zmianach kont lub odnowieniach. Wreszcie, po udostępnieniu danych, sprawdzać reprezentatywne użycie względem warunków, wystawcy i właściciela rachunku.
Kontrolowane wdrożenie zaczyna się od dry-run i jednej zweryfikowanej licencji. Przetwarzanie zdarzeń obejmuje potem wąski zbiór sprzedawców i celów; rozszerzenie następuje po zgodności logów, stanu i opłat. Odzyskiwanie musi obejmować nieznanych sprzedawców, brakujące zdarzenia, opóźnioną aktywację i niespodziewane koszty.
Skrypt pasuje do ograniczonej, zaufanej pracy pod kontrolą człowieka. CDK do powtarzalnych umów, których politykę można bezpiecznie zakodować. Pytanie nie dotyczy ilości automatyzacji, lecz tego, czy każda umowa ma dokładnego sprzedawcę, zatwierdzone cele, oczekiwany stan i odpowiedzialnego właściciela rozliczenia.