Un prezzo negoziato per un modello non è necessariamente quello utilizzabile da un carico di lavoro. La guida AWS del 13 ottobre sui diritti gestiti affronta questa lacuna per i modelli di terze parti idonei su Amazon Bedrock: accettare un’offerta privata Marketplace crea una licenza, ma distribuirla può lasciare grant accettati e ancora disabilitati.
AWS presenta due percorsi. Uno script Python consente all’amministratore di esaminare e attivare una volta le licenze ricevute. Un esempio CDK basato su eventi tratta accordi ricorrenti mediante verifica del venditore, creazione dei grant, attivazione, tentativi e log. Nessuno negozia uno sconto o dimostra risparmi semplicemente installandolo.
La novità rende utilizzabile un accordo centrale negli account di sviluppo, produzione, divisione o regione. Aumenta anche le conseguenze di un venditore o ambito errato. Approvazione commerciale, attivazione tecnica e verifica della fattura rimangono eventi diversi.
Licenza, grant e addebito sono stati distinti
AWS Marketplace Private Pricing Offers, o MPPO, definiscono condizioni negoziate. Per i modelli Bedrock idonei supportati da License Manager, l’accettazione genera una licenza. I diritti gestiti distribuiscono tale facoltà mediante grant all’organizzazione, a unità organizzative scelte o a singoli account.
Con tutte le funzioni AWS Organizations abilitate, i grant organizzativi vengono accettati automaticamente ma restano disabilitati fino all’attivazione. AWS indica ACTIVE e WORKFLOW_COMPLETED come stati dopo i quali si applica la tariffa. Gli acquisti possono vedere offerta accettata e destinazioni configurate mentre il consumo resta fuori dal percorso negoziato.
Con sola fatturazione consolidata, senza tutte le funzioni Organizations, gli account destinatari devono accettare manualmente. Conto centrale e integrazione completa non coincidono. Le risorse di controllo licenza sono gestite in us-east-1, anche se i modelli vengono chiamati in altre regioni Bedrock supportate.
L’account della sottoscrizione originaria paga il consumo distribuito, invece di creare abbonamenti indipendenti per ogni destinatario. Questo centralizza la visibilità, non l’attribuzione interna. Tag, categorie di costo e responsabili servono ancora per mostrare o ripartire le spese. Stato della licenza, chiamata del modello e addebito effettivo vanno osservati separatamente.
Lo script è un’azione limitata dell’operatore
L’utilità Python elenca le licenze ricevute dall’account di gestione. Per impostazione predefinita produce un piano dry-run, senza creare o attivare grant. L’operatore verifica emittente, licenza e ambito, poi specifica --apply e l’ID dell’account di gestione per eseguire.
Crea e attiva grant estesi all’intera organizzazione per le licenze selezionate. È adatto a un arretrato noto o ad accordi infrequenti, senza infrastruttura CDK permanente. Non è un motore continuo di policy.
Il limite importante è l’assenza di un elenco di venditori consentiti. Il confine di fiducia è la persona che confronta ogni emittente con documenti di acquisto e accordo accettato. Ripeterlo senza supervisione su qualsiasi licenza in arrivo eliminerebbe quel confine.
Anche l’intera organizzazione richiede approvazione consapevole. Un’impresa regolamentata può separare produzione clinica e ricerca o limitare modelli a unità approvate. Un’attivazione tecnicamente riuscita può comunque superare il perimetro autorizzato.
Dopo l’esecuzione si controlla License Manager e, quando arrivano i dati, una quota rappresentativa di consumo in Cost Explorer. AWS avverte di ritardi da ore a giorni. Un grant attivo conferma l’attivazione, non garantisce immediatamente ogni addebito. Il verificatore di sconto richiede emittente e account corrispondenti all’accordo reale.
CDK risponde a un accordo, non a una licenza pronta
Il percorso ricorrente combina EventBridge, Lambda, DynamoDB, License Manager e CloudWatch. Una regola sul bus predefinito in us-east-1 filtra la sorgente aws.agreement-marketplace e il tipo Purchase Agreement Created - Acceptor.
Lambda controlla l’elenco venditori in DynamoDB. Se il venditore è approvato, cerca la licenza correlata, crea il grant per i destinatari configurati e richiede lo stato attivo tramite CreateGrantVersion.
L’evento contrattuale non garantisce che ogni risorsa successiva sia pronta. Un grant nuovo può non essere subito attivabile; l’esempio riprova mentre License Manager conclude il flusso. CloudWatch registra attivazione, rinvio e mancata elaborazione intenzionale. Il log spiega il processo, ma non sostituisce l’approvazione del venditore o della destinazione.
Il deployment deve partire dall’account di gestione Organizations in us-east-1, con tutte le funzioni e un’offerta Bedrock supportata da License Manager. SaaS è escluso: non è un elaboratore universale di offerte private Marketplace.
License Manager e Marketplace richiedono accesso attendibile e ruoli collegati al servizio. Un bootstrap verifica i prerequisiti; la modalità apply può abilitare integrazioni e creare ruoli dopo conferma esplicita dell’account. La configurazione specifica organizzazione, venditori verificati, notifiche e destinazioni facoltative. Senza destinatari personalizzati vale tutta l’organizzazione; unità o account singoli restringono l’ambito.
Identità del venditore e destinazioni sono il confine
AWS definisce l’elenco dei venditori una barriera di sicurezza. Gli ID vanno verificati nell’accordo accettato o nella licenza ricevuta, non solo dal nome visualizzato. Una voce non verificata o troppo ampia può consentire grant non previsti verso tutti i destinatari.
Questo non concede automaticamente accesso illimitato ai dati aziendali. IAM, controlli dei servizi, permessi del modello e architettura applicativa regolano ancora l’utilizzo. La distribuzione cambia l’idoneità commerciale e può concentrare gli addebiti, ma non equivale a ogni autorizzazione sui dati.
Le unità organizzative seguono una gerarchia esistente. Gli account nominativi sono più stretti ma richiedono manutenzione quando arrivano nuovi carichi. L’intera organizzazione può servire una piattaforma centrale; contesti regolamentati possono esigere approvazione per ambiente e classificazione dei dati.
Modifiche a venditori, organizzazione e destinatari necessitano revisione e distribuzione controllata. Gli allarmi devono coprire errori e rinvii ripetuti. Consegna dell’evento e disponibilità della licenza sono aspetti separati: bisogna prevedere ritardi, duplicati e omissioni, non dedurre completezza da log silenziosi.
La riconciliazione confronta accordi accettati, licenze ricevute, destinazioni approvate e grant attivi. Trova accordi non attivati, destinatari inattesi o grant senza accordo attuale approvato. Lo script aiuta il recupero, ma deve condividere la responsabilità con lo stack per evitare duplicati e ambiti contraddittori. Mappature degli emittenti, approvazioni e procedure devono restare disponibili durante incidenti.
Acquistare centralmente non interpreta il contratto
Gli acquisti gestiscono l’accordo, la piattaforma distribuisce e attiva, la sicurezza verifica fiducia e ambito, FinOps controlla addebiti e attribuzione. Compiti poco chiari possono trasformare molte attese individuali in un collo di bottiglia centrale.
Il cliente AWS Heidi Health dichiara milioni di consultazioni cliniche settimanali con modelli di terzi. Il responsabile piattaforma Marcus Lau descrive i prezzi privati come utili per attribuire consumo e condizioni fra account e unità e sottolinea grant automatici all’aggiunta di modelli. È una testimonianza del cliente, non una prova indipendente di risparmio.
Rinnovi, nuovi accordi e riorganizzazioni richiedono verifiche continue. L’automazione non interpreta copertura, modifiche o decorrenza. Un accordo accettato con avvio futuro non rende subito disponibili i termini. Modelli, regioni e varianti ulteriori non sono automaticamente coperti da un contratto già esistente.
Servono tre prove che coincidano
Prima si misura il tempo dall’evento idoneo allo stato attivo accettato, includendo rifiuti del venditore, ritardi di ricerca, rinvii e interventi manuali. Poi si riconciliano contratti, licenze, destinatari e grant dopo rinnovi o cambi di account. Infine, con i dati di fatturazione disponibili, si confronta consumo rappresentativo con termini, emittente e responsabile del conto.
Un rilascio controllato comincia con dry-run e una licenza verificata. Gli eventi vengono poi trattati per pochi venditori e destinazioni limitate, ampliando solo quando log, stato e costi coincidono. Il recupero deve gestire venditori sconosciuti, eventi mancanti, attivazioni tardive e addebiti inattesi.
Lo script è adatto a lavoro circoscritto e fidato verificabile da una persona. CDK è adatto ad accordi ricorrenti con policy codificabili in sicurezza. Il punto non è quanta automazione installare, ma se ogni accordo ha venditore esatto, destinazioni autorizzate, stato previsto e responsabile della fatturazione.