Crea un servizio SaaS interno con monitoraggio dei costi e dell'utilizzo per i modelli di base su Amazon Bedrock | Servizi Web di Amazon

Le imprese stanno cercando di sbloccare rapidamente il potenziale dell’intelligenza artificiale generativa fornendo accesso a modelli di base (FM) a diverse linee di business (LOB). I team IT hanno la responsabilità di aiutare la LOB a innovare con velocità e agilità, fornendo al contempo governance e osservabilità centralizzate. Ad esempio, potrebbero dover monitorare l'utilizzo dei servizi FM tra i team, i costi di riaddebito e fornire visibilità al centro di costo pertinente nella LOB. Inoltre, potrebbe essere necessario regolamentare l’accesso a diversi modelli per squadra. Ad esempio, se solo determinati FM possono essere approvati per l'uso.

Roccia Amazzonica è un servizio completamente gestito che offre una scelta di modelli di base ad alte prestazioni di aziende leader nel settore dell'intelligenza artificiale come AI21 Labs, Anthropic, Cohere, Meta, Stability AI e Amazon tramite un'unica API, insieme a un'ampia gamma di funzionalità per creare un'intelligenza artificiale generativa applicazioni con sicurezza, privacy e intelligenza artificiale responsabile. Poiché Amazon Bedrock è serverless, non devi gestire alcuna infrastruttura e puoi integrare e distribuire in modo sicuro funzionalità di intelligenza artificiale generativa nelle tue applicazioni utilizzando i servizi AWS con cui hai già familiarità.

Un livello SaaS (Software as a Service) per i modelli di base può fornire un'interfaccia semplice e coerente per gli utenti finali, mantenendo al tempo stesso una governance centralizzata dell'accesso e del consumo. I gateway API possono fornire un accoppiamento flessibile tra i consumatori del modello e il servizio endpoint del modello e la flessibilità per adattarsi al cambiamento del modello, delle architetture e dei metodi di chiamata.

In questo post ti mostriamo come creare un livello SaaS interno per accedere ai modelli di base con Amazon Bedrock in un'architettura multi-tenant (team). Ci concentriamo in particolare sul monitoraggio dell'utilizzo e dei costi per tenant e anche su controlli come la limitazione dell'utilizzo per tenant. Descriviamo il modo in cui la soluzione e i piani di consumo di Amazon Bedrock si adattano al quadro generale del percorso SaaS. Il codice per la soluzione e un file Kit di sviluppo cloud AWS (AWS CDK) è disponibile nel file Repository GitHub.

Le sfide

Un amministratore della piattaforma AI deve fornire un accesso facile e standardizzato ai FM a più team di sviluppo.

Di seguito sono elencate alcune delle sfide per fornire un accesso regolamentato ai modelli di fondazione:

• Monitoraggio dei costi e dell'utilizzo – Monitorare e verificare i costi dei singoli inquilini e l'utilizzo dei modelli di base e fornire costi di riaddebito a centri di costo specifici
• Controlli sul budget e sull'utilizzo – Gestire la quota API, il budget e i limiti di utilizzo per l'uso consentito dei modelli di base su una frequenza definita per tenant
• Controllo degli accessi e governance dei modelli – Definire i controlli di accesso per i modelli elencati di autorizzazione specifica per tenant
• API standardizzata multi-tenant – Fornire un accesso coerente ai modelli di fondazione con OpenAPI standard
• Gestione centralizzata delle API – Fornire un singolo livello per gestire le chiavi API per l'accesso ai modelli
• Versioni e aggiornamenti del modello – Gestire il lancio di versioni di modelli nuovi e aggiornati

Panoramica della soluzione

In questa soluzione si fa riferimento a a multi-locatario approccio. UN inquilino qui può variare da un singolo utente, un progetto specifico, un team o persino un intero dipartimento. Quando discutiamo dell'approccio, usiamo il termine team, perché è il più comune. Utilizziamo le chiavi API per limitare e monitorare l'accesso API per i team. Ad ogni squadra viene assegnata una chiave API per l'accesso agli FM. Possono essere presenti diversi meccanismi di autenticazione e autorizzazione degli utenti distribuiti in un'organizzazione. Per semplicità, non li includiamo in questa soluzione. Puoi anche integrare i provider di identità esistenti con questa soluzione.

Il diagramma seguente riepiloga l'architettura della soluzione e i componenti chiave. I team (tenant) assegnati a centri di costo separati utilizzano Amazon Bedrock FM tramite un servizio API. Per tenere traccia del consumo e dei costi per team, la soluzione registra i dati per ogni singola invocazione, incluso il modello richiamato, il numero di token per i modelli di generazione di testo e le dimensioni dell'immagine per i modelli multimodali. Inoltre, aggrega le invocazioni per modello e i costi per ciascun team.

Puoi distribuire la soluzione nel tuo account utilizzando AWS CDK. AWS CDK è un framework di sviluppo software open source per modellare ed eseguire il provisioning delle risorse delle tue applicazioni cloud utilizzando linguaggi di programmazione familiari. Il codice AWS CDK è disponibile nel file Repository GitHub.

Nelle sezioni seguenti discuteremo più dettagliatamente i componenti chiave della soluzione.

Acquisizione dell'utilizzo del modello di base per team

Il flusso di lavoro per acquisire l'utilizzo di FM per team è costituito dai seguenti passaggi (come numerati nel diagramma precedente):

1. L'applicazione di un team invia una richiesta POST a Gateway API Amazon con il modello da invocare nel model_id parametro di query e il prompt dell'utente nel corpo della richiesta.
2. API Gateway instrada la richiesta a un file AWS Lambda funzione (bedrock_invoke_model) che è responsabile della registrazione delle informazioni sull'utilizzo del team Amazon Cloud Watch e invocando il modello Amazon Bedrock.
3. Amazon Bedrock fornisce un endpoint VPC basato su Collegamento privato AWS. In questa soluzione, la funzione Lambda invia la richiesta ad Amazon Bedrock utilizzando PrivateLink per stabilire una connessione privata tra il VPC nel tuo account e l'account del servizio Amazon Bedrock. Per ulteriori informazioni su PrivateLink, vedere Utilizza AWS PrivateLink per configurare l'accesso privato ad Amazon Bedrock.
4. Dopo l'invocazione dell'Amazzonia Bedrock, Amazon Cloud Trail genera a Evento CloudTrail.
5. Se la chiamata Amazon Bedrock ha esito positivo, la funzione Lambda registra le seguenti informazioni a seconda del tipo di modello richiamato e restituisce la risposta generata all'applicazione:
   • team_id – L'identificatore univoco del team che ha emesso la richiesta.
   • ID richiesta – L'identificatore univoco della richiesta.
   • id_modello – L'ID del modello da richiamare.
   • inputToken – Il numero di token inviati al modello come parte del prompt (per i modelli di generazione di testo e incorporamenti).
   • outputToken – Il numero massimo di token che devono essere generati dal modello (per i modelli di generazione di testo).
   • altezza – L'altezza dell'immagine richiesta (per modelli multimodali e modelli di incorporamenti multimodali).
   • larghezza – La larghezza dell'immagine richiesta (solo per modelli multimodali).
   • passi – I passaggi richiesti (per i modelli Stability AI).

Monitoraggio dei costi per squadra

Un flusso diverso aggrega le informazioni sull'utilizzo, quindi calcola e salva i costi su richiesta per team su base giornaliera. Avendo un flusso separato, garantiamo che il monitoraggio dei costi non influisca sulla latenza e sulla velocità effettiva del flusso di chiamata del modello. I passaggi del flusso di lavoro sono i seguenti:

1. An Amazon EventBridge la regola attiva una funzione Lambda (bedrock_cost_tracking) quotidiano.
2. La funzione Lambda ottiene le informazioni sull'utilizzo da CloudWatch per il giorno precedente, calcola i costi associati e archivia i dati aggregati per team_id ed model_id in Servizio di archiviazione semplice Amazon (Amazon S3) in formato CSV.

Per interrogare e visualizzare i dati archiviati in Amazon S3, hai diverse opzioni, tra cui S3 Selezionae Amazon Athena e Amazon QuickSight.

Controllo dell'utilizzo per squadra

Un piano di utilizzo specifica chi può accedere a una o più API distribuite e facoltativamente imposta la frequenza di richieste target per avviare la limitazione delle richieste. Il piano utilizza le chiavi API per identificare i client API che possono accedere all'API associata per ciascuna chiave. Puoi utilizzare API Gateway piani di utilizzo per limitare le richieste che superano le soglie predefinite. Puoi anche usare Chiavi API e limiti di quota, che ti consentono di impostare il numero massimo di richieste per chiave API che ciascun team può emettere entro un intervallo di tempo specificato. Questo è in aggiunta a Quote del servizio Amazon Bedrock assegnati solo a livello di account.

Prerequisiti

Prima di distribuire la soluzione, assicurati di disporre di quanto segue:

Distribuisci lo stack AWS CDK

Segui le istruzioni in README file del repository GitHub per configurare e distribuire lo stack AWS CDK.

Lo stack distribuisce le seguenti risorse:

• Ambiente di rete privato (VPC, sottoreti private, gruppo di sicurezza)
• Ruolo IAM per il controllo dell'accesso al modello
• Livelli Lambda per i moduli Python necessari
• Funzione Lambda invoke_model
• Funzione Lambda list_foundation_models
• Funzione Lambda cost_tracking
• API Rest (Gateway API)
• Piano di utilizzo del gateway API
• Chiave API associata al piano di utilizzo

Sali a bordo di una nuova squadra

Per fornire l'accesso a nuovi team, puoi condividere la stessa chiave API tra team diversi e tenere traccia dei consumi del modello fornendo una chiave API diversa team_id per l'invocazione dell'API, oppure creare chiavi API dedicate utilizzate per accedere alle risorse Amazon Bedrock seguendo le istruzioni fornite nel file README.

Lo stack distribuisce le seguenti risorse:

• Piano di utilizzo API Gateway associato all'API REST creata in precedenza
• Chiave API associata al piano di utilizzo per il nuovo team, con configurazioni riservate di throttling e burst per l'API

Per ulteriori informazioni sulla limitazione e sulle configurazioni burst di API Gateway, fare riferimento a Limita le richieste API per un throughput migliore.

Dopo aver distribuito lo stack, puoi vedere che la nuova chiave API per team-2 viene creato anche lui.

Configurare il controllo dell'accesso al modello

L'amministratore della piattaforma può consentire l'accesso a specifici modelli di base modificando la policy IAM associata alla funzione Lambda invoke_model.

Le autorizzazioni IAM sono definite nel file setup/stack_constructs/iam.py. Vedi il seguente codice:

self.bedrock_policy = iam.Policy( scope=self, id=f"{self.id}_policy_bedrock", policy_name="BedrockPolicy", statements=[ iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "sts:AssumeRole", ], resources=["*"], ), iam.PolicyStatement( effect=iam.Effect.ALLOW, actions=[ "bedrock:InvokeModel", “bedrock:ListFoundationModels", ], resources=[ "arn:aws:bedrock:*::foundation-model/anthropic.claude-v2.1", "arn:aws:bedrock:*::foundation-model/amazon.titan-text-express-v1", "arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v1"
], ) ], ) … self.bedrock_policy.attach_to_role(self.lambda_role)

Richiamare il servizio

Dopo aver distribuito la soluzione, puoi richiamare il servizio direttamente dal tuo codice. Il seguente

è un esempio in Python per consumare il file invoke_model API per la generazione del testo tramite una richiesta POST:

api_key=”abcd1234” model_id = "amazon.titan-text-express-v1" #the model id for the Amazon Titan Express model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2
} prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier }
) text = response.json()[0]["generated_text"] print(text)

Risultato: Amazon Bedrock è una piattaforma tecnologica interna sviluppata da Amazon per eseguire e gestire molti dei suoi servizi e prodotti. Alcune cose fondamentali su Bedrock...

Quello che segue è un altro esempio in Python per consumare il file invoke_model API per la generazione di incorporamenti tramite una richiesta POST:

model_id = "amazon.titan-embed-text-v1" #the model id for the Amazon Titan Embeddings Text model prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier, "embeddings": "true" #boolean value for the embeddings model }
) text = response.json()[0]["embedding"]

Uscita: 0.91796875, 0.45117188, 0.52734375, -0.18652344, 0.06982422, 0.65234375, -0.13085938, 0.056884766, 0.092285156, 0.06982422, 1.03125, 0.8515625, 0.16308594, 0.079589844, -0.033935547, 0.796875, -0.15429688, -0.29882812, -0.25585938, 0.45703125, 0.044921875 0.34570312, XNUMX …

Accesso negato ai modelli di fondazione

Quello che segue è un esempio in Python per consumare il file invoke_model API per la generazione di testo tramite una richiesta POST con risposta di accesso negato:

model_id = " anthropic.claude-v1" #the model id for Anthropic Claude V1 model model_kwargs = { # inference configuration "maxTokenCount": 4096, "temperature": 0.2
} prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier }
) print(response)
print(response.text)

“Traceback (ultima chiamata più recente):n File ”/var/task/index.py”, riga 213, nella risposta lambda_handlern = _invoke_text(bedrock_client, model_id, body, model_kwargs)n File ”/var/task/index.py ”, riga 146, in _invoke_textn raise en File ”/var/task/index.py”, riga 131, in _invoke_textn risposta = bedrock_client.invoke_model(n File ”/opt/python/botocore/client.py”, riga 535, in _api_calln return self._make_api_call(Operation_name, kwargs)n File ”/opt/python/botocore/client.py”, riga 980, in _make_api_calln raise error_class(parsed_response, Operation_name)nbotocore.errorfactory.AccessDeniedException: Si è verificato un errore (AccessDeniedException) durante la chiamata all'operazione InvokeModel: il tuo account non è autorizzato a richiamare questa operazione API.n”

Esempio di stima dei costi

Quando si richiamano i modelli Amazon Bedrock con prezzi su richiesta, il costo totale viene calcolato come la somma dei costi di input e output. I costi di input si basano sul numero di token di input inviati al modello e i costi di output si basano sui token generati. I prezzi si intendono per 1,000 token di input e per 1,000 token di output. Per ulteriori dettagli e prezzi dei modelli specifici, fare riferimento a Prezzi di Amazon Bedrock.

Diamo un'occhiata a un esempio in cui due team, team1 e team2, accedono ad Amazon Bedrock tramite la soluzione in questo post. I dati sull'utilizzo e sui costi salvati in Amazon S3 in un singolo giorno sono mostrati nella tabella seguente.

Le colonne input_tokens ed output_tokens archiviare i token di input e output totali tra le invocazioni del modello per modello e per team, rispettivamente, per un determinato giorno.

Le colonne input_cost ed output_cost memorizzare i rispettivi costi per modello e per squadra. Questi vengono calcolati utilizzando le seguenti formule:

input_cost = input_token_count * model_pricing["input_cost"] / 1000
output_cost = output_token_count * model_pricing["output_cost"] / 1000

Visualizzazione end-to-end di un ambiente SaaS serverless multi-tenant funzionale

Comprendiamo come potrebbe apparire un ambiente SaaS serverless multi-tenant funzionale end-to-end. Di seguito è riportato un diagramma dell'architettura di riferimento.

Questo diagramma dell'architettura è una versione ingrandita del diagramma dell'architettura precedente spiegato in precedenza nel post, in cui il diagramma dell'architettura precedente spiega i dettagli di uno dei microservizi menzionati (servizio modello fondamentale). Questo diagramma spiega che, oltre al servizio del modello di base, è necessario disporre anche di altri componenti nella piattaforma SaaS multi-tenant per implementare una piattaforma funzionale e scalabile.

Esaminiamo i dettagli dell'architettura.

Domande degli inquilini

Le applicazioni tenant sono le applicazioni front-end che interagiscono con l'ambiente. Qui mostriamo più tenant che accedono da diversi ambienti locali o AWS. Le applicazioni front-end possono essere estese per includere una pagina di registrazione per consentire ai nuovi tenant di registrarsi e una console di amministrazione per gli amministratori del livello di servizio SaaS. Se le applicazioni tenant richiedono l'implementazione di una logica personalizzata che richiede l'interazione con l'ambiente SaaS, possono implementare le specifiche del microservizio dell'adattatore dell'applicazione. Gli scenari di esempio potrebbero includere l'aggiunta di una logica di autorizzazione personalizzata rispettando le specifiche di autorizzazione dell'ambiente SaaS.

Servizi condivisi

Sono servizi condivisi:

• Servizi di gestione tenant e utenti –Questi servizi sono responsabili della registrazione e della gestione degli inquilini. Forniscono funzionalità trasversali separate dai servizi applicativi e condivise tra tutti i tenant.
• Servizio modello di fondazione –Il diagramma dell'architettura della soluzione spiegato all'inizio di questo post rappresenta questo microservizio, in cui l'interazione tra API Gateway e funzioni Lambda avviene nell'ambito di questo microservizio. Tutti gli inquilini utilizzano questo microservizio per richiamare i modelli fondamentali di Anthropic, AI21, Cohere, Stability, Meta e Amazon, nonché modelli ottimizzati. Cattura inoltre le informazioni necessarie per il monitoraggio dell'utilizzo nei log CloudWatch.
• Servizio di monitoraggio dei costi –Questo servizio tiene traccia del costo e dell'utilizzo per ciascun inquilino. Questo microservizio viene eseguito in base a una pianificazione per eseguire query sui log di CloudWatch e restituire il monitoraggio dell'utilizzo aggregato e il costo dedotto per l'archiviazione dei dati. Il servizio di monitoraggio dei costi può essere esteso per creare ulteriori report e visualizzazioni.

Servizio adattatore dell'applicazione

Questo servizio presenta una serie di specifiche e API che un tenant può implementare per integrare la propria logica personalizzata nell'ambiente SaaS. In base alla quantità di integrazione personalizzata necessaria, questo componente può essere facoltativo per i tenant.

Archivio dati multi-tenant

I servizi condivisi archiviano i propri dati in un archivio dati che può essere un unico condiviso Amazon DynamoDB tabella con una chiave di partizionamento del tenant che associa gli elementi DynamoDB ai singoli tenant. Il servizio condiviso di monitoraggio dei costi invia i dati aggregati di utilizzo e monitoraggio dei costi ad Amazon S3. In base al caso d'uso, può esserci anche un archivio dati specifico dell'applicazione.

Un ambiente SaaS multi-tenant può avere molti più componenti. Per ulteriori informazioni, fare riferimento a Creazione di una soluzione SaaS multi-tenant utilizzando i servizi serverless AWS.

Supporto per più modelli di distribuzione

I framework SaaS in genere delineano due modelli di distribuzione: pool e silo. Per il modello pool, tutti i tenant accedono ai FM da un ambiente condiviso con un'infrastruttura di archiviazione ed elaborazione comune. Nel modello a silo, ogni tenant dispone del proprio set di risorse dedicate. Puoi leggere informazioni sui modelli di isolamento nel file White paper sulle strategie di isolamento dei tenant SaaS.

La soluzione proposta può essere adottata per entrambi i modelli di implementazione SaaS. Nell'approccio del pool, un ambiente AWS centralizzato ospita le risorse API, storage e calcolo. In modalità silo, ogni team accede ad API, storage e risorse di calcolo in un ambiente AWS dedicato.

La soluzione si adatta anche ai piani di consumo disponibili forniti da Amazon Bedrock. AWS offre la possibilità di scegliere tra due piani di consumo per l'inferenza:

• On-Demand – Questa modalità consente di utilizzare modelli di fondazione a ripartizione senza dover assumere impegni a tempo determinato
• Throughput assegnato – Questa modalità consente di fornire un throughput sufficiente a soddisfare i requisiti prestazionali dell'applicazione in cambio di un impegno a termine basato sul tempo

Per ulteriori informazioni su queste opzioni, fare riferimento a Prezzi di Amazon Bedrock.

La soluzione di riferimento SaaS serverless descritta in questo post può applicare i piani di consumo Amazon Bedrock per fornire agli utenti finali opzioni di suddivisione in livelli Basic e Premium. Basic potrebbe includere il consumo di throughput on-demand o fornito di Amazon Bedrock e potrebbe includere limiti di utilizzo e budget specifici. I limiti del tenant possono essere abilitati limitando le richieste in base alle richieste, alle dimensioni dei token o all'allocazione del budget. I tenant del livello Premium potrebbero avere le proprie risorse dedicate con il consumo del throughput assegnato di Amazon Bedrock. Questi tenant verrebbero generalmente associati a carichi di lavoro di produzione che richiedono un throughput elevato e un accesso a bassa latenza ai servizi FM di Amazon Bedrock.

Conclusione

In questo post, abbiamo discusso di come creare una piattaforma SaaS interna per accedere ai modelli di base con Amazon Bedrock in una configurazione multi-tenant con particolare attenzione al monitoraggio dei costi e dell'utilizzo e ai limiti di limitazione per ciascun tenant. Ulteriori argomenti da esplorare includono l'integrazione di soluzioni di autenticazione e autorizzazione esistenti nell'organizzazione, il miglioramento del livello API per includere socket Web per interazioni bidirezionali tra client e server, l'aggiunta di filtraggio dei contenuti e altri guardrail di governance, la progettazione di più livelli di distribuzione, l'integrazione di altri microservizi nel SaaS architettura e molti altri.

L'intero codice per questa soluzione è disponibile nel file Repository GitHub.

Per ulteriori informazioni sui framework basati su SaaS, fare riferimento a Framework del viaggio SaaS: creazione di una nuova soluzione SaaS su AWS.

Informazioni sugli autori

Hasan Poonawala è un Senior AI/ML Specialist Solutions Architect presso AWS, lavora con clienti del settore sanitario e delle scienze della vita. Hasan aiuta a progettare, distribuire e scalare applicazioni di intelligenza artificiale generativa e machine learning su AWS. Ha oltre 15 anni di esperienza lavorativa combinata nel machine learning, nello sviluppo di software e nella scienza dei dati sul cloud. Nel tempo libero, Hasan ama esplorare la natura e trascorrere del tempo con amici e familiari.

"Anastasia Tzeveleka è un Senior AI/ML Specialist Solutions Architect presso AWS. Come parte del suo lavoro, aiuta i clienti in tutta l'area EMEA a costruire modelli fondamentali e a creare soluzioni scalabili di intelligenza artificiale generativa e machine learning utilizzando i servizi AWS.

bruniente pistone è un Generative AI e ML Specialist Solutions Architect per AWS con sede a Milano. Lavora con grandi clienti aiutandoli a comprendere a fondo le loro esigenze tecniche e a progettare soluzioni di intelligenza artificiale e machine learning che sfruttano al meglio il cloud AWS e lo stack Amazon Machine Learning. Le sue competenze includono: machine learning end-to-end, industrializzazione del machine learning e intelligenza artificiale generativa. Gli piace passare il tempo con i suoi amici ed esplorare nuovi posti, oltre a viaggiare verso nuove destinazioni.

Vikesh Pandey è un architetto di soluzioni AI/ML generative, specializzato in servizi finanziari in cui aiuta i clienti finanziari a creare e scalare piattaforme e soluzioni di AI/ML generative scalabili fino a centinaia o addirittura migliaia di utenti. Nel tempo libero, Vikesh ama scrivere su vari forum e blog e costruire i Lego con suo figlio.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://aws.amazon.com/blogs/machine-learning/build-an-internal-saas-service-with-cost-and-usage-tracking-for-foundation-models-on-amazon-bedrock/