Architettura di riferimento della chat Baseline di Microsoft Foundry in una landing zone di Azure

Questo articolo fa parte di una serie basata sull'architettura di riferimento della chat baseline di Microsoft Foundry. Esaminare l'architettura di base in modo da poter identificare le modifiche necessarie prima di distribuirla in una sottoscrizione della zona di destinazione dell'applicazione azure.

Questo articolo descrive un'architettura generativa del carico di lavoro di intelligenza artificiale che distribuisce l'applicazione chat di base, ma usa risorse esterne all'ambito del team del carico di lavoro. I team della piattaforma gestiscono centralmente le risorse e più team del carico di lavoro li usano. Le risorse condivise includono risorse di rete per connessioni cross-premise, sistemi di gestione degli accessi alle identità e criteri. Queste linee guida consentono alle organizzazioni che usano le zone di destinazione di Azure di mantenere una governance coerente e un'efficienza dei costi.

Microsoft Foundry usa account e progetti per organizzare lo sviluppo e la distribuzione di intelligenza artificiale. Ad esempio, un'implementazione della zona di destinazione potrebbe usare un account come risorsa centralizzata a livello di gruppo aziendale e progetti come risorsa delegata per ogni carico di lavoro in tale gruppo aziendale. A causa dei fattori dell'organizzazione delle risorse e delle limitazioni di allocazione dei costi, non è consigliabile usare questa topologia e questo articolo non fornisce indicazioni su di esso. Questa architettura considera invece il workload come proprietario dell'istanza Foundry, ovvero l'approccio consigliato.

In qualità di proprietario del carico di lavoro, si delega la gestione delle risorse condivise ai team della piattaforma in modo che sia possibile concentrarsi sulle attività di sviluppo del carico di lavoro. Questo articolo presenta la prospettiva del team del carico di lavoro e specifica le raccomandazioni per il team della piattaforma.

Layout articolo

Architettura	Decisioni relative alla progettazione	Approccio Azure Well-Architected Framework
▪ Diagramma dell'architettura ▪ Risorse del carico di lavoro ▪ Risorse federate	▪ Configurazione sottoscrizione ▪ Rete ▪ Accesso ai data scientist ▪ Monitorare le risorse ▪ Governance organizzativa ▪ Gestione delle modifiche	▪ Affidabilità ▪ Sicurezza ▪ Ottimizzazione dei costi ▪ Eccellenza operativa ▪ Efficienza prestazionale

Architettura

Scaricare un file di Visio di questa architettura.

Componenti

Tutte le architetture della zona di destinazione di Azure separano la proprietà tra il team della piattaforma e il team del carico di lavoro, detto democratizzazione delle sottoscrizioni. Gli architetti delle applicazioni, i data scientist e i team DevOps devono comprendere chiaramente questa divisione per determinare cosa rientra nella loro influenza diretta o controllo e cosa non lo fa.

Analogamente alla maggior parte delle implementazioni della zona di destinazione dell'applicazione, il team del carico di lavoro gestisce principalmente la configurazione, la distribuzione e la supervisione dei componenti del carico di lavoro, inclusi i servizi di intelligenza artificiale in questa architettura.

Risorse di proprietà del team del carico di lavoro

Le risorse seguenti rimangono per lo più invariate rispetto all'architettura di base.

• L'account e i progetti Di Microsoft Foundry sono una piattaforma applicativa per sviluppatori di intelligenza artificiale e data scientist per compilare, valutare e distribuire modelli di intelligenza artificiale e agenti host. In questa architettura Foundry consente al team del carico di lavoro di ospitare modelli di intelligenza artificiale generativi come servizio, implementare la sicurezza dei contenuti e stabilire connessioni specifiche del carico di lavoro a origini e strumenti di conoscenza.

  Se il Centro di intelligenza artificiale dell'organizzazione limita l'accesso alle distribuzioni di modelli di intelligenza artificiale, il team del carico di lavoro potrebbe non ospitare modelli in progetti e account. Potrebbe invece essere necessario usare risorse di intelligenza artificiale centralizzate. In questo scenario, l'utilizzo di tutti i modelli in genere passa attraverso un gateway fornito dal team della piattaforma di intelligenza artificiale.

  Questo articolo presuppone che i modelli di intelligenza artificiale generativi in questo scenario siano risorse di proprietà del carico di lavoro. In caso contrario, l'host del modello o un gateway per i modelli diventa una dipendenza del carico di lavoro. Il team della piattaforma deve mantenere una connettività di rete affidabile alle API.

  Il servizio Foundry Agent gestisce le dipendenze del modello in modo specifico, in modo che le problematiche possano verificarsi quando si usano modelli ospitati centralmente. Potrebbe essere necessario usare un agente di orchestrazione alternativo.

• Foundry Agent Service è un ambiente di runtime nativo del cloud che consente agli agenti intelligenti di operare in modo sicuro e autonomo. In questa architettura, foundry Agent Service fornisce il livello di orchestrazione per le interazioni di chat. Ospita e gestisce l'agente di chat che elabora le richieste utente.

  Usare la configurazione dell'agente standard in questa architettura. Connettere l'agente a una subnet dedicata nella rete virtuale spoke e instradare il traffico in uscita attraverso la sottoscrizione di connettività.

  Il team del carico di lavoro fornisce risorse di Azure dedicate per lo stato dell'agente, la cronologia delle chat e l'archiviazione file. Queste risorse sono Azure Cosmos DB per NoSQL, Archiviazione di Azure e Ricerca di intelligenza artificiale di Azure. L'istanza del servizio Foundry Agent gestisce queste risorse e i relativi dati esclusivamente. Altri componenti dell'applicazione nel carico di lavoro o in altri carichi di lavoro dell'organizzazione non devono usarli.

• Il servizio app di Azure consente agli sviluppatori di creare app Web e per dispositivi mobili e automatizzare i processi aziendali con le app per le API. In questa architettura ospita l'applicazione Web che contiene l'interfaccia utente della chat e distribuisce il componente rivolto all'utente, con più istanze in più zone per la disponibilità.

  Un account di archiviazione di Azure ospita il codice dell'applicazione Web come file ZIP, che viene montato nel servizio app.

• Ricerca di intelligenza artificiale è un'infrastruttura di ricerca scalabile che indicizza contenuti eterogenei e consente il recupero dei dati tramite API, applicazioni e agenti di intelligenza artificiale. In questa architettura, ricerca di intelligenza artificiale funge da archivio conoscenze del carico di lavoro per il modello Di generazione aumentata di recupero. Questo modello estrae una query appropriata da un prompt, esegue query sulla ricerca di intelligenza artificiale e usa i risultati come dati di base per l'intelligenza artificiale generativa.

• Il gateway applicazione di Azure è un servizio di bilanciamento del carico del traffico Web e un controller di recapito delle applicazioni. In questa architettura funge da proxy inverso per instradare le richieste utente all'interfaccia utente di chat ospitata nel servizio app. Ospita un web application firewall di Azure per proteggere l'applicazione front-end da traffico potenzialmente dannoso.

• Azure Key Vault è un servizio cloud per archiviare e accedere in modo sicuro a segreti, chiavi e certificati. In questa architettura viene archiviato il certificato TLS (Transport Layer Security) del gateway applicazione.

• Monitoraggio di Azure, Log di Monitoraggio di Azure e Application Insights raccolgono, archiviano e visualizzano i dati di osservabilità. In questa architettura abilitano il monitoraggio, la diagnostica e le informazioni operative per tutti i componenti del carico di lavoro.

• Criteri di Azure applica criteri specifici del carico di lavoro per gestire, proteggere e applicare controlli su larga scala. In questa architettura applica regole di governance e conformità alle risorse gestite dal team del carico di lavoro.

Il team del carico di lavoro gestisce anche le risorse seguenti:

• Le subnet di rete virtuale spoke e i gruppi di sicurezza di rete mantengono la segmentazione e controllano il flusso del traffico tra subnet. In questa architettura applicano limiti di rete e sicurezza tra i componenti del carico di lavoro.

• Gli endpoint privati proteggono la connettività alle soluzioni PaaS (Platform as a Service). In questa architettura, assicurano che i servizi sensibili siano accessibili solo all'interno della rete privata, riducendo così l'esposizione alla rete Internet pubblica.

Risorse di proprietà del team della piattaforma

Il team della piattaforma possiede e gestisce le risorse centralizzate seguenti. Questa architettura presuppone che queste risorse vengano sottoposte a provisioning preliminare e che le considerino come dipendenze.

• Firewall di Azure è un servizio di sicurezza di rete gestito basato sul cloud. In questa architettura Firewall di Azure nelle route di rete hub controlla e limita il traffico in uscita che ha origine dal carico di lavoro, incluso il traffico dell'agente. Il traffico in uscita del carico di lavoro passa a Internet, a destinazioni cross-premise o ad altre zone di destinazione dell'applicazione.

  Passare dalla linea di base: Nell'architettura di base il team del carico di lavoro è proprietario di questo componente. In questa architettura, il team della piattaforma lo gestisce nella sottoscrizione di connettività.

• Azure Bastion è un servizio PaaS gestito usato per connettersi alle macchine virtuali tramite indirizzo IP privato. In questa architettura, Azure Bastion nella rete hub fornisce accesso operativo sicuro ai componenti del carico di lavoro e consente l'accesso ai componenti Foundry. Garantisce che gli amministratori e il personale di supporto possano connettersi in modo sicuro alle macchine virtuali senza esporre le porte RDP/SSH alla rete Internet pubblica.

  Passare dalla linea di base: Nell'architettura di base il team del carico di lavoro è proprietario di questo componente.

• La rete virtuale spoke è la posizione in cui viene distribuito il carico di lavoro.

  Passare dalla linea di base: Nell'architettura di base il team del carico di lavoro è proprietario di questa rete.

• Le route definite dall'utente applicano il tunneling al firewall della rete hub.

  Passare dalla linea di base: Nell'architettura di base il team del carico di lavoro possiede questo routing.

• I vincoli e i criteri di DeployIfNotExists si applicano alla sottoscrizione del carico di lavoro. È possibile applicare questi criteri a livello di gruppo di gestione di proprietà del team della piattaforma o direttamente alla sottoscrizione del carico di lavoro.

  Modifica rispetto alla linea di base: questi criteri sono nuovi in questa architettura. Il team della piattaforma applica criteri che vincolano il carico di lavoro. Alcuni criteri potrebbero duplicare i vincoli del carico di lavoro esistenti o introdurre nuovi vincoli.

• Le zone DNS private di Azure ospitano A i record per gli endpoint privati in modo che i componenti del carico di lavoro possano risolvere in modo sicuro il nome di dominio completo dei servizi PaaS usati all'interno del carico di lavoro. Per altre informazioni, vedere Collegamento privato di Azure e integrazione DNS su larga scala.

  Passare dalla linea di base: Nell'architettura di base il team del carico di lavoro è proprietario di questa rete. In questa architettura, il team della piattaforma gestisce questo componente nella sottoscrizione di connettività.

• Il servizio di risoluzione DNS supporta reti virtuali spoke e workstation cross-premise. Questo servizio usa in genere Firewall di Azure come proxy DNS o resolver privato DNS di Azure. In questa architettura, il servizio risolve i record DNS dell'endpoint privato per tutte le richieste DNS dallo spoke. Il resolver privato DNS e i set di regole collegati è il modo consigliato per il team della piattaforma per abilitare questi requisiti di risoluzione dell'architettura a causa delle caratteristiche di risoluzione DNS del servizio foundry Agent.

• Protezione DDoS di Azure consente di proteggere gli indirizzi IP pubblici da attacchi distribuiti. In questa architettura Protezione DDoS consente di proteggere l'indirizzo IP pubblico associato al gateway applicazione.

  Passare dalla linea di base: Nell'architettura di base il team del carico di lavoro acquista Protezione DDoS.

Configurazione sottoscrizione

Il team del carico di lavoro deve informare il team della piattaforma di requisiti specifici della zona di destinazione per implementare questa architettura. E il team della piattaforma deve comunicare i propri requisiti al team del carico di lavoro.

Ad esempio, il team del carico di lavoro deve fornire informazioni dettagliate sullo spazio di rete necessario. Il team della piattaforma usa queste informazioni per allocare le risorse necessarie. Il team del carico di lavoro definisce i requisiti e il team della piattaforma assegna gli indirizzi IP appropriati all'interno della rete virtuale.

Il team della piattaforma assegna un gruppo di gestione in base alle esigenze tecniche e alla criticità aziendale del carico di lavoro. Ad esempio, se il carico di lavoro è esposto a Internet, come questa architettura, il team della piattaforma seleziona un gruppo di gestione appropriato. Per stabilire la governance, il team della piattaforma configura e implementa anche i gruppi di gestione. Il team del carico di lavoro deve progettare e gestire il carico di lavoro entro i vincoli di questa governance. Per altre informazioni sulle distinzioni tipiche dei gruppi di gestione, vedere Personalizzare l'architettura della zona di destinazione di Azure.

Il team della piattaforma configura la sottoscrizione per questa architettura. Le sezioni seguenti forniscono indicazioni sulla configurazione iniziale della sottoscrizione.

Requisiti e adempimenti del carico di lavoro

Il team del carico di lavoro e il team della piattaforma devono collaborare a dettagli come l'assegnazione del gruppo di gestione, la governance di Criteri di Azure e la configurazione della rete. Preparare un elenco di controllo dei requisiti per avviare discussioni e negoziazione con il team della piattaforma. L'elenco di controllo seguente funge da esempio.

	Considerazioni relative alla progettazione	Requisito del carico di lavoro per questa architettura
☐	Il numero di reti virtuali spoke e le relative dimensioni: Il team della piattaforma crea e configura la rete virtuale, quindi esegue il peering all'hub a livello di area per designarlo come spoke. È anche necessario assicurarsi che la rete possa supportare la crescita futura del carico di lavoro. Per svolgere queste attività in modo efficace, è necessario conoscere il numero di spoke necessari.	Distribuire tutte le risorse in una singola rete virtuale spoke dedicata. Richiedere /22 spazio indirizzi contiguo per supportare operazioni e scenari su larga scala, ad esempio distribuzioni side-by-side. I fattori seguenti determinano la maggior parte delle esigenze degli indirizzi IP: - Gateway applicazione requisiti per le dimensioni della subnet (dimensione fissa). - Endpoint privati con indirizzi IP singoli per i servizi PaaS (dimensione fissa). - Dimensioni della subnet per gli agenti di compilazione (dimensione fissa). - Il servizio agente Foundry richiede una subnet all'interno di un /24 prefisso.
☐	Prefissi degli indirizzi di rete virtuale: In genere, il team della piattaforma assegna indirizzi IP in base alle convenzioni esistenti, evita la sovrapposizione con le reti con peering e la disponibilità all'interno del sistema di gestione degli indirizzi IP.	La subnet di integrazione dell'agente deve usare un prefisso di indirizzo che inizia con 172. o 192. ad 192.168.45.1/24esempio . Una restrizione di runtime nell'host della funzionalità del servizio Foundry Agent applica questo requisito. Il servizio agente Foundry non supporta le subnet che usano 10.. Chiedere al team della piattaforma di fornire un spoke con un prefisso di indirizzo valido per la subnet dell'agente.
☐	Area di distribuzione: Il team della piattaforma deve distribuire un hub nella stessa area delle risorse del carico di lavoro.	Comunicare l'area selezionata per il carico di lavoro e le aree per le risorse di calcolo sottostanti. Assicurarsi che le aree supportino le zone di disponibilità. Azure OpenAI nei modelli Foundry ha una disponibilità a livello di area limitata.
☐	Sovranità dei dati: Il team della piattaforma deve rispettare tutti i requisiti di residenza dei dati del carico di lavoro.	Se il carico di lavoro richiede una rigorosa residenza dei dati, assicurarsi che il team della piattaforma non duplici i log di Diagnostica di Azure o invii dati a Purview in un'area non consentita dai requisiti.
☐	Tipo, volume e modello di traffico: Il team della piattaforma deve determinare i requisiti di ingresso e uscita delle risorse condivise del carico di lavoro.	Fornire informazioni sui fattori seguenti: - Come gli utenti devono usare questo carico di lavoro. - Come questo carico di lavoro utilizza le risorse circostanti. - Protocollo di trasporto configurato. - Il modello di traffico e le ore di punta previste e non di punta. Comunicare quando si prevede un numero elevato di connessioni simultanee a Internet (chatty) e quando si prevede che il carico di lavoro generi traffico di rete minimo (rumore di fondo).
☐	Configurazione del firewall: Il team della piattaforma deve impostare regole per consentire il traffico in uscita legittimo.	Condividere informazioni dettagliate sul traffico in uscita dalla rete spoke, incluso il traffico dell'agente. L'agente di compilazione e i jump box richiedono l'applicazione regolare di patch del sistema operativo. Gli agenti potrebbero dover interagire con origini, strumenti o altri agenti ospitati all'esterno del carico di lavoro.
☐	Traffico in ingresso da ruoli specializzati: Il team della piattaforma deve fornire ai ruoli specificati l'accesso di rete al carico di lavoro e implementare la segmentazione corretta.	Collaborare con il team della piattaforma per determinare il modo migliore per consentire l'accesso autorizzato per i ruoli seguenti: - Data scientist e sviluppatori che accedono al portale Foundry dalle loro workstation nelle connessioni di rete aziendali - Operatori che accedono al livello di calcolo tramite un jump box gestito dal carico di lavoro
☐	Accesso a Internet pubblico al carico di lavoro: Il team della piattaforma usa queste informazioni per la valutazione dei rischi, che determina diverse decisioni: - Posizionamento del carico di lavoro in un gruppo di gestione con protezioni appropriate - Protezione DDoS (Distributed Denial of Service) per l'indirizzo IP pubblico segnalato dal team del carico di lavoro - Approvvigionamento e gestione dei certificati TLS	Informare il team della piattaforma sul profilo del traffico in ingresso: - Traffico con origine Internet destinato all'indirizzo IP pubblico nel gateway applicazione - Nomi di dominio completi (FQDN) associati all'indirizzo IP pubblico per l'approvvigionamento di certificati TLS
☐	Utilizzo dell'endpoint privato: Il team della piattaforma deve configurare zone DNS private di Azure per gli endpoint privati e assicurarsi che il firewall nella rete hub esegua correttamente la risoluzione DNS.	Informare il team della piattaforma su tutte le risorse che usano endpoint privati, incluse le risorse seguenti: - AI Search - Azure Cosmos DB per NoSQL - Key Vault - Microsoft Foundry - Account di archiviazione Comprendere in che modo l'hub gestisce la risoluzione DNS e definire le responsabilità del team del carico di lavoro per la gestione dei record di zona DNS privati e del set di regole del resolver privato DNS.
☐	Risorse di intelligenza artificiale centralizzate: Il team della piattaforma deve comprendere l'utilizzo previsto dei modelli e delle piattaforme di hosting. Queste informazioni vengono usate per stabilire una rete per le risorse di intelligenza artificiale centralizzate all'interno dell'organizzazione. Ogni organizzazione definisce i propri piani di adozione e governance dell'IA e il team del carico di lavoro deve operare entro tali vincoli.	Informare il team della piattaforma sulle risorse di intelligenza artificiale e Machine Learning che si prevede di usare. Questa architettura usa Foundry, Foundry Agent Service e modelli di base generativi ospitati nei modelli Foundry. Comprendere chiaramente quali servizi di intelligenza artificiale centralizzati è necessario usare e come queste dipendenze influiscono sul carico di lavoro.

Calcolo

Il livello di orchestrazione e l'hosting dell'interfaccia utente della chat rimangono uguali all'architettura di base.

Rete

Nell'architettura di base viene effettuato il provisioning del carico di lavoro in una singola rete virtuale.

Passare dalla linea di base: Questa architettura divide il carico di lavoro su due reti virtuali. Una rete ospita i componenti del carico di lavoro. L'altra rete gestisce la connettività Internet e ibrida. Il team della piattaforma determina il modo in cui la rete virtuale del carico di lavoro si integra con l'architettura di rete più grande dell'organizzazione, che in genere segue una topologia hub-spoke.

Scaricare un file di Visio di questa architettura.

• Rete virtuale hub: Questa rete virtuale funge da hub a livello di area che contiene servizi centralizzati e spesso condivisi che comunicano con le risorse del carico di lavoro nella stessa area. L'hub si trova nella sottoscrizione di connettività. Il team della piattaforma possiede le risorse in questa rete.

• Rete virtuale spoke: In questa architettura, la singola rete virtuale dall'architettura di base diventa essenzialmente la rete virtuale spoke. Il team della piattaforma collega questa rete spoke alla rete hub. Sono proprietari e gestiscono la rete spoke, tra cui il peering e la configurazione DNS. Il team del carico di lavoro è proprietario delle risorse in questa rete, incluse le relative subnet. Questa rete contiene molte delle risorse del carico di lavoro.

A causa di questa divisione di gestione e proprietà, il team del carico di lavoro deve comunicare chiaramente i requisiti del carico di lavoro al team della piattaforma.

Subnet della rete virtuale

Nella rete virtuale spoke si creano e allocano le subnet in base ai requisiti del carico di lavoro. Per fornire la segmentazione, applicare controlli che limitano il traffico all'interno e all'esterno delle subnet. Questa architettura non aggiunge subnet oltre le subnet nell'architettura di base. Tuttavia, l'architettura di rete non richiede più le AzureBastionSubnet subnet o AzureFirewallSubnet perché il team della piattaforma probabilmente ospita questa funzionalità nelle sottoscrizioni.

È comunque necessario implementare controlli di rete locali quando si distribuisce il carico di lavoro in una zona di destinazione di Azure. L'organizzazione potrebbe imporre ulteriori restrizioni di rete per proteggersi dall'esfiltrazione dei dati e garantire visibilità per il centro operativo centrale per la sicurezza e il team della rete IT.

Traffico in ingresso

Il flusso del traffico in ingresso rimane uguale all'architettura di base.

Le risorse correlate all'ingresso internet pubblico sono gestite nel carico di lavoro. In questa architettura, ad esempio, il gateway applicazione e il relativo indirizzo IP pubblico risiedono nella rete spoke anziché nella rete hub. Alcune organizzazioni inseriscono le risorse in ingresso in una sottoscrizione di connettività usando una rete perimetrale centralizzata (nota anche come rete perimetrale, zona demilitarizzata e subnet schermata). L'integrazione con tale topologia specifica non rientra nell'ambito di questo articolo.

Approccio alternativo per controllare il traffico in ingresso

Questa architettura non usa Firewall di Azure per esaminare il traffico in ingresso, ma a volte è necessaria la governance organizzativa. In questi casi, il team della piattaforma supporta l'implementazione per fornire ai team del carico di lavoro un livello aggiuntivo di rilevamento e prevenzione delle intrusioni. Questo livello consente di bloccare il traffico in ingresso indesiderato. Per supportare questa topologia, questa architettura richiede più configurazioni UDR. Per altre informazioni, vedere Rete Zero Trust per le applicazioni Web con Firewall di Azure e gateway applicazione.

Configurazione del DNS

Nell'architettura di base tutti i componenti usano DNS di Azure direttamente per la risoluzione DNS.

Passare dalla linea di base: In questa architettura, in genere uno o più server DNS nell'hub eseguono la risoluzione DNS. Quando viene creata la rete virtuale, le proprietà DNS nella rete virtuale devono essere già impostate di conseguenza. Il team del carico di lavoro non deve comprendere i dettagli di implementazione del servizio DNS.

Questa architettura configura i componenti del carico di lavoro con DNS nei modi seguenti.

Componente	Configurazione del DNS
Gateway delle applicazioni	Ereditato dalla rete virtuale
Servizio app (interfaccia utente della chat)	Ereditato dalla rete virtuale
Ricerca IA	Non è possibile eseguire l'override, usa DNS di Azure
Fonderia	Non è possibile eseguire l'override, usa DNS di Azure
Servizio agente Foundry	Non è possibile eseguire l'override, usa DNS di Azure
Azure Cosmos DB, un servizio di database distribuito globale di Microsoft	Non è possibile eseguire l'override, usa DNS di Azure
Console di salto	Ereditato dalla rete virtuale
Agenti di compilazione	Ereditato dalla rete virtuale

Questa architettura non configura le impostazioni DNS per i componenti che non avviano la comunicazione in uscita. Questi componenti non richiedono la risoluzione DNS.

Molti componenti di questa architettura si basano sui record DNS ospitati nei server DNS dell'hub per risolvere gli endpoint privati del carico di lavoro. Per altre informazioni, vedere Zone DNS private di Azure.

Quando la risoluzione DNS basata su hub non è possibile, tali componenti devono affrontare le limitazioni seguenti:

• Il team della piattaforma non riesce a registrare le richieste DNS, che potrebbero violare un requisito del team di sicurezza aziendale.

• La risoluzione dei servizi esposti tramite collegamento privato nella zona di destinazione o in altre zone di destinazione dell'applicazione potrebbe essere impossibile.

È consigliabile acquisire familiarità con il modo in cui il team della piattaforma gestisce IL DNS. Per ulteriori informazioni, vedere Private Link e integrazione DNS su larga scala. Quando si aggiungono funzionalità dei componenti che dipendono direttamente da DNS di Azure, è possibile introdurre complessità nella topologia DNS fornita dalla piattaforma. È possibile riprogettare componenti o negoziare eccezioni per ridurre al minimo la complessità.

Traffico in uscita

Nell'architettura di base, tutto il traffico in uscita instrada verso Internet tramite Firewall di Azure.

Passare dalla linea di base: In questa architettura la piattaforma fornisce una route definita dall'utente che punta a un'istanza di Firewall di Azure ospitata. Applicare questa route definita dall'utente alle stesse subnet nell'architettura di base.

Tutto il traffico che lascia la rete virtuale spoke, incluso il traffico dalla subnet di integrazione dell'agente, reindirizza attraverso la rete hub con peering tramite un firewall in uscita.

Scaricare un file di Visio di questa architettura.

La comunicazione est-ovest dei client verso gli endpoint privati per Key Vault, Foundry e altri servizi rimane la stessa come è nell'architettura di base. Il diagramma precedente non include tale percorso.

Traffico Internet routing al firewall

Tutte le subnet nella rete spoke includono una route che indirizza tutto il traffico associato a Internet o 0.0.0.0/0 il traffico all'istanza di Firewall di Azure dell'hub.

Componente	Meccanismo per forzare il traffico Internet attraverso l'hub
Gateway delle applicazioni	Nessuno. Il traffico associato a Internet proveniente da questo servizio non può essere forzato tramite il firewall del team della piattaforma.
Servizio app (interfaccia utente della chat)	L'integrazione della rete virtuale a livello di area e l'impostazione vnetRouteAllEnabled sono abilitate.
Ricerca IA	Nessuno. Il traffico proveniente da questo servizio non può essere forzato attraverso un firewall. Questa architettura non usa competenze.
Servizio agente Foundry	Route definita dall'utente applicata alla subnet snet-agentsEgress.
Jump box	Route definita dall'utente applicata alla subnet snet-jumpbox.
Agenti di compilazione	Route definita dall'utente applicata alla subnet snet-agents.

Questa architettura non configura il tunneling forzato per i componenti che non avviano la comunicazione in uscita.

Per i componenti o le funzionalità che non possono instradare il traffico in uscita attraverso l'hub, il team del carico di lavoro deve essere allineato ai requisiti dell'organizzazione. Per soddisfare questi requisiti, usare i controlli di compensazione, riprogettare il carico di lavoro per escludere le funzionalità non supportate o richiedere eccezioni formali. L'utente è responsabile della mitigazione dell'esfiltrazione e dell'abuso dei dati.

Applicare la route Internet fornita dalla piattaforma a tutte le subnet, anche se non si prevede che la subnet abbia traffico in uscita. Questo approccio garantisce che le distribuzioni impreviste in tale subnet passano attraverso il filtro in uscita di routine. Per le subnet che contengono endpoint privati, abilitare i criteri di rete per supportare il routing completo e il controllo NSG.

Questa configurazione del percorso garantisce che tutte le connessioni in uscita dal Servizio app, da Foundry e dai relativi progetti e tutti gli altri servizi provenienti dalla rete virtuale del carico di lavoro vengano ispezionati e controllati.

Zone DNS private di Azure

I carichi di lavoro che usano endpoint privati per il traffico east-west richiedono record di zona DNS nel provider DNS configurato. Per supportare il collegamento privato, questa architettura si basa su molti record di zona DNS per servizi come Key Vault, Foundry e Archiviazione di Azure.

Passare dalla linea di base: Nell'architettura di base il team del carico di lavoro gestisce direttamente le zone DNS private. In questa architettura, il team della piattaforma gestisce in genere zone DNS private. Il team del carico di lavoro deve comprendere chiaramente i requisiti e le aspettative del team della piattaforma per la gestione dei record di zona DNS privati. Il team della piattaforma può usare altre tecnologie anziché record di zona DNS privati.

In questa architettura, il team della piattaforma deve configurare DNS per gli endpoint API FQDN di Microsoft Foundry seguenti:

• privatelink.services.ai.azure.com
• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com

Il team della piattaforma deve anche configurare DNS per i nomi di dominio completi seguenti, ovvero dipendenze del servizio Foundry Agent:

• privatelink.search.windows.net
• privatelink.blob.core.windows.net
• privatelink.documents.azure.com

Il team della piattaforma deve anche ospitare le zone DNS private per altre dipendenze del carico di lavoro in questa architettura:

• privatelink.vaultcore.azure.net
• privatelink.azurewebsites.net

Accesso per sviluppatori di data scientist e agenti

Analogamente all'architettura di base, questa architettura disabilita l'accesso in ingresso pubblico al portale foundry e ad altre esperienze basate su browser. L'architettura di base distribuisce un jump box per fornire a un browser un indirizzo IP di origine dalla rete virtuale usato da vari ruoli del carico di lavoro.

Quando il carico di lavoro si connette a una zona di destinazione di Azure, il team ottiene altre opzioni di accesso. Collaborare con il team della piattaforma per verificare se è possibile ottenere l'accesso privato a vari portali Foundry basati su browser senza gestire e governare una macchina virtuale. Questo accesso potrebbe essere possibile tramite il routing transitivo da una connessione ExpressRoute o gateway VPN esistente.

L'accesso nativo basato su workstation richiede il routing cross-premise e la risoluzione DNS, che il team della piattaforma può fornire. Includere questo requisito nella richiesta di distribuzione automatica della sottoscrizione.

L'accesso nativo basato su workstation a questi portali migliora la produttività e semplifica la manutenzione rispetto alla gestione dei jumpbox delle macchine virtuali.

Ruolo del jump box

La jump box in questa architettura offre valore per il supporto operativo, non per scopi di runtime o per lo sviluppo di intelligenza artificiale e Machine Learning. La jumpbox può risolvere i problemi di routing dns e di rete perché fornisce l'accesso alla rete interna a componenti altrimenti inaccessibili esternamente.

Nell'architettura di base Azure Bastion accede alla jump box gestita.

In questa architettura Azure Bastion viene distribuito nella sottoscrizione di connettività come risorsa a livello di area condivisa gestita dal team della piattaforma. Per dimostrare che il caso d'uso in questa architettura, Azure Bastion si trova nella sottoscrizione di connettività e il team non lo distribuisce.

La macchina virtuale che funge da jump box deve essere conforme ai requisiti dell'organizzazione per le macchine virtuali. Questi requisiti possono includere elementi come le identità aziendali in Microsoft Entra ID, immagini di base specifiche e regimi di applicazione di patch.

Monitorare le risorse

La piattaforma della zona di destinazione di Azure fornisce risorse di osservabilità condivise come parte della sottoscrizione di gestione. È tuttavia consigliabile effettuare il provisioning delle proprie risorse di monitoraggio per facilitare le responsabilità di proprietà del carico di lavoro. Questo approccio è allineato all'architettura di base.

È possibile effettuare il provisioning delle risorse di monitoraggio seguenti:

• Application Insights funge da servizio di gestione delle prestazioni delle applicazioni (APM) per il team. Questo servizio viene configurato nell'interfaccia utente della chat, nel servizio agente Foundry e nei modelli.

• L'area di lavoro Log di Monitoraggio di Azure funge da sink unificato per tutti i log e le metriche delle risorse di Azure di proprietà del carico di lavoro.

Analogamente all'architettura di base, tutte le risorse devono inviare i log di diagnostica di Azure all'area di lavoro Log di Monitoraggio di Azure di cui effettua il provisioning il team. Questa configurazione fa parte della distribuzione dell'infrastruttura come codice (IaC) delle risorse. Potrebbe anche essere necessario inviare log a un'area di lavoro dei log di Monitoraggio di Azure centrale. Nelle zone di destinazione di Azure l'area di lavoro si trova in genere nella sottoscrizione di gestione.

Il team della piattaforma potrebbe avere più processi che influiscono sulle risorse nella zona di destinazione dell'applicazione. Ad esempio, possono usare i criteri DINE per configurare la diagnostica e inviare i log alle sottoscrizioni di gestione centralizzate. Possono anche applicare gli avvisi di base di Monitoraggio di Azure tramite i criteri. Assicurarsi che l'implementazione non blocchi questi flussi di registrazione e avvisi aggiuntivi.

Criteri di Azure

L'architettura di base consiglia criteri generali per gestire il carico di lavoro. Quando si distribuisce questa architettura in una zona di destinazione dell'applicazione, non è necessario aggiungere o rimuovere criteri aggiuntivi. Per applicare la governance e migliorare la sicurezza di questo carico di lavoro, continuare ad applicare criteri alla sottoscrizione, ai gruppi di risorse o alle risorse.

Si prevede che la sottoscrizione dell'area di destinazione dell'applicazione disponga di criteri esistenti, anche prima di distribuire il carico di lavoro. Alcuni criteri consentono la governance dell'organizzazione controllando o bloccando configurazioni specifiche nelle distribuzioni.

I criteri di esempio seguenti possono causare complessità di distribuzione del carico di lavoro:

• Policy:Secrets [in Key Vault] deve avere il periodo di validità massimo specificato.

  Complicazione: Foundry può conservare i segreti relativi alle connessioni di strumenti e informazioni in un Key Vault connesso. Tali segreti non hanno una data di scadenza impostata dal servizio. L'architettura di base non usa questi tipi di connessioni, ma è possibile estendere l'architettura per supportarle.

• Criteri:i servizi di ricerca di intelligenza artificiale devono usare chiavi gestite dal cliente per crittografare i dati inattivi.

  Complicazione: Questa architettura non richiede chiavi gestite dal cliente. È tuttavia possibile estendere l'architettura per supportarle.

• Politica:I modelli di fonderia non devono essere visualizzati in anteprima.

  Complicazione: Durante lo sviluppo, è possibile usare un modello di anteprima che si prevede di essere disponibile a livello generale quando si abilita la funzionalità agente nel carico di lavoro di produzione.

I team della piattaforma possono applicare criteri DINE per gestire le distribuzioni automatizzate in una sottoscrizione della zona di destinazione dell'applicazione. Incorporare e testare in modo preliminare le restrizioni e le modifiche avviate dalla piattaforma nei modelli IaC. Se il team della piattaforma usa criteri di Azure in conflitto con i requisiti dell'applicazione, è possibile negoziare una risoluzione.

Gestire le modifiche nel tempo

In questa architettura, i servizi e le operazioni forniti dalla piattaforma fungono da dipendenze esterne. Il team della piattaforma continua ad applicare modifiche, eseguire l'onboarding delle zone di destinazione e applicare i controlli dei costi. Il team della piattaforma potrebbe non assegnare priorità ai singoli carichi di lavoro. Le modifiche apportate a tali dipendenze, ad esempio le modifiche del firewall, possono influire su più carichi di lavoro.

È necessario comunicare con i team della piattaforma in modo efficiente e tempestivo per gestire tutte le dipendenze esterne. È importante testare le modifiche in anticipo in modo che non influiscano negativamente sui carichi di lavoro.

Modifiche della piattaforma che influiscono sul carico di lavoro

In questa architettura, il team della piattaforma gestisce le risorse seguenti. Le modifiche apportate a queste risorse possono influire potenzialmente sull'affidabilità, la sicurezza, le operazioni e gli obiettivi di prestazioni del carico di lavoro. Valutare queste modifiche prima che il team della piattaforma li implementi per determinare come influiscono sul carico di lavoro.

• Criteri di Azure: le modifiche apportate ai criteri di Azure possono influire sulle risorse del carico di lavoro e sulle relative dipendenze. Queste modifiche possono includere aggiornamenti diretti dei criteri o spostamento della zona di destinazione in una nuova gerarchia dei gruppi di gestione. Queste modifiche potrebbero non essere rilevate fino a quando non si verifica una nuova distribuzione, quindi è necessario testarle accuratamente.

  Esempio: Un criterio non consente più la distribuzione delle istanze di Azure Cosmos DB che richiedono la crittografia della chiave gestita dal cliente e l'architettura usa la crittografia della chiave gestita da Microsoft.

• Regole del firewall: le modifiche alle regole del firewall possono influire sulla rete virtuale o sulle regole del carico di lavoro che si applicano su larga scala in tutto il traffico. Queste modifiche possono causare traffico bloccato e persino errori di processo invisibile all'utente. Questi potenziali problemi si applicano sia al firewall in uscita che alle regole del gruppo di sicurezza di rete applicate da Azure Rete virtuale Manager.

  Esempio: Il traffico bloccato verso le API Bing causa chiamate allo strumento agente non riuscite per i dati a terra su Internet.

• Routing nella rete hub: le modifiche apportate alla natura transitiva del routing nell'hub possono influire potenzialmente sulla funzionalità del carico di lavoro se un carico di lavoro dipende dal routing ad altre reti virtuali.

  Esempio: Una modifica di routing impedisce agli agenti Foundry di accedere a un archivio vettoriale gestito da un altro team o impedisce ai team di data science di accedere al portale Foundry dalle workstation.

• Host Azure Bastion: modifiche alla disponibilità o alla configurazione dell'host Azure Bastion.

  Esempio: una modifica di configurazione impedisce l'accesso alle jump box e alle macchine virtuali dell'agente di compilazione.

Modifiche del carico di lavoro che influiscono sulla piattaforma

Gli esempi seguenti descrivono le modifiche del carico di lavoro che è necessario comunicare con il team della piattaforma. Il team della piattaforma deve convalidare l'affidabilità, la sicurezza, le operazioni e gli obiettivi di prestazioni del servizio della piattaforma rispetto alle nuove modifiche prima che vengano applicate.

• Uscita di rete: monitorare qualsiasi aumento significativo dell'uscita di rete per evitare che il carico di lavoro diventi un vicino rumoroso nei dispositivi di rete. Questo problema può potenzialmente influire sugli obiettivi di prestazioni o affidabilità di altri carichi di lavoro. Questa architettura è principalmente autonoma ed è improbabile che si verifichi un cambiamento significativo nei modelli di traffico in uscita.

• Accesso pubblico: Le modifiche all'accesso pubblico per i componenti del carico di lavoro potrebbero richiedere test aggiuntivi. Il team della piattaforma potrebbe spostare il carico di lavoro in un gruppo di gestione diverso.

  Esempio: in questa architettura, se si rimuove l'indirizzo IP pubblico da gateway applicazione e si rende questa applicazione solo interna, l'esposizione del carico di lavoro alle modifiche a Internet. Un altro esempio è l'esposizione dei portali di intelligenza artificiale basati su browser a Internet, che non è consigliabile.

• Valutazione della criticità aziendale: Le modifiche ai contratti di servizio del carico di lavoro potrebbero richiedere un nuovo approccio di collaborazione tra i team della piattaforma e del carico di lavoro.

  Esempio: Il carico di lavoro potrebbe passare da basso a elevato livello aziendale a causa di un aumento dell'adozione e del successo.

• Sovranità dei dati: Le modifiche ai requisiti relativi alla sovranità dei dati potrebbero richiedere al team della piattaforma di modificare il piano di raccolta dei log, il supporto dell'integrazione purview del carico di lavoro o il supporto della soluzione SIEM (Security Information and Event Management) dell'organizzazione.

  Esempio: Il carico di lavoro potrebbe ora richiedere che tutti i dati del thread dell'agente rimangano entro un limite geografico. Se Foundry è connesso a Purview o a siem, è necessario assicurarsi che i dati degli utenti non vengano replicati in un'area che viola i requisiti normativi.

Team dell'architettura aziendale

Alcune organizzazioni hanno un team di architettura aziendale che potrebbe influenzare la progettazione del carico di lavoro e la relativa architettura. Il team comprende la strategia di adozione dell'IA aziendale e i principi e le raccomandazioni nei carichi di lavoro di intelligenza artificiale nella progettazione di Azure. Collaborare con questo team per assicurarsi che questo carico di lavoro di chat soddisfi gli obiettivi specifici dello scenario e si allinea alla strategia e alle raccomandazioni dell'organizzazione.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Questa architettura mantiene le garanzie di affidabilità nell'architettura di base. Non introduce nuove considerazioni sull'affidabilità per i componenti principali del carico di lavoro.

Dipendenze critiche

Considerare tutte le funzionalità eseguite dal carico di lavoro nella piattaforma e nell'area di destinazione dell'applicazione come dipendenze. Gestire i piani di risposta agli eventi imprevisti che includono metodi di contatto e percorsi di escalation per ogni dipendenza. Includere queste dipendenze nell'analisi della modalità di errore del carico di lavoro.Include these dependencies in the workload's failure mode analysis (FMA).

Si considerino le dipendenze del carico di lavoro e gli scenari di esempio seguenti che possono verificarsi:

• Firewall in uscita: Il firewall in uscita centralizzato subisce modifiche non correlate al carico di lavoro. Più carichi di lavoro condividono il firewall.

• Risoluzione DNS: Questa architettura usa IL DNS fornito dal team della piattaforma per la maggior parte delle risorse, combinato con DNS di Azure e set di regole del resolver privato DNS collegato per il servizio agente Foundry. Di conseguenza, il carico di lavoro dipende dagli aggiornamenti tempestivi ai record DNS per gli endpoint privati e la disponibilità dei servizi DNS.

• Criteri DINE: I criteri DINE per le zone DNS private di Azure o qualsiasi altra dipendenza fornita dalla piattaforma operano con il massimo sforzo e non includono un contratto di servizio. Ad esempio, un ritardo nella configurazione DNS per gli endpoint privati di questa architettura può impedire all'interfaccia utente della chat di diventare agenti pronti per il traffico o bloccare il completamento delle query del servizio Foundry Agent.

• Criteri di gruppo di gestione: I criteri coerenti tra gli ambienti supportano l'affidabilità. Assicurarsi che gli ambienti di preproduzione corrispondano agli ambienti di produzione per fornire test accurati e prevenire deviazioni specifiche dell'ambiente in grado di bloccare una distribuzione o una scalabilità. Per maggiori informazioni, consultare la sezione Gestire gli ambienti di sviluppo di applicazioni nelle zone di destinazione di Azure.

Molte di queste considerazioni potrebbero esistere senza zone di destinazione di Azure. È necessario collaborare con i team della piattaforma per risolvere questi problemi e assicurarsi di soddisfare tutti i requisiti. Per altre informazioni, vedere Identificare le dipendenze.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Controllo del traffico in ingresso

Per isolare il carico di lavoro da altri spoke del carico di lavoro all'interno dell'organizzazione, applicare gruppi di sicurezza di rete nelle subnet e usare la natura nontransitiva o i controlli nell'hub a livello di area. Creare gruppi di sicurezza di rete completi che consentano solo i requisiti di rete in ingresso dell'applicazione e dell'infrastruttura. È consigliabile non basarsi esclusivamente sulla natura non transitiva della rete hub per la sicurezza.

Il team della piattaforma implementa i criteri di Azure per la sicurezza. Ad esempio, un criterio potrebbe garantire che gateway applicazione abbia un Web application firewall impostato su modalità Nega, che limita il numero di indirizzi IP pubblici disponibili per la sottoscrizione. Oltre a questi criteri, è consigliabile distribuire criteri incentrati sul carico di lavoro che rafforzano il comportamento di sicurezza in ingresso.

La tabella seguente mostra esempi di controlli di ingresso in questa architettura.

Fonte	Scopo	Controllo del carico di lavoro	Controllo della piattaforma
Internet	Flussi di traffico applicazione	Instradare tutte le richieste del carico di lavoro tramite un gruppo di sicurezza di rete, un web application firewall e regole di routing prima di consentire al traffico pubblico di passare al traffico privato per l'interfaccia utente della chat.	Nessuno
Internet	Accesso all'API REST del portale di Microsoft Foundry e all'API REST del piano dati	Negare tutto l'accesso tramite la configurazione a livello di servizio.	Nessuno
Internet	Accesso del piano dati a tutti i servizi ad eccezione del gateway applicazione	Negare l'accesso tramite le regole del gruppo di sicurezza di rete e la configurazione a livello di servizio.	Nessuno
Azure Bastion	Accesso all'agente di compilazione e jump box	Applicare un gruppo di sicurezza di rete nella subnet jump box che blocca tutto il traffico verso le porte di accesso remoto, a meno che l'origine non sia la subnet di Azure Bastion designata dalla piattaforma.	Nessuno
Cross-premise	Accesso al portale foundry e all'API REST del piano dati	Nega tutto l'accesso. Se non si usa il jump box, consentire l'accesso solo dalle workstation nelle subnet autorizzate per i data scientist.	Applicare il routing nontransitivo o usare Firewall di Azure in un hub protetto della rete WAN virtuale di Azure
Altri spoke	Nessuno	Bloccato tramite regole del gruppo di sicurezza di rete.	Applicare il routing nontransitivo o usare Firewall di Azure in un hub protetto della rete WAN virtuale

Controllo del traffico in uscita

Applicare le regole del gruppo di sicurezza di rete che esprimono i requisiti di connettività in uscita richiesti della soluzione e negano tutto il resto. Non basarsi solo sui controlli di rete hub. Come operatore del carico di lavoro, è necessario arrestare il traffico in uscita indesiderato il più vicino possibile all'origine.

Le subnet del carico di lavoro sono proprietarie all'interno della rete virtuale, ma il team della piattaforma ha probabilmente creato regole del firewall per rappresentare in modo specifico i requisiti acquisiti come parte del processo di distribuzione automatica delle sottoscrizioni. Assicurarsi che le modifiche apportate alle subnet e al posizionamento delle risorse per tutta la durata dell'architettura rimangano compatibili con la richiesta originale. Collaborare con il team di rete per garantire la continuità del controllo in uscita con accesso minimo.

La tabella seguente mostra esempi di controlli in uscita in questa architettura.

Punto finale	Scopo	Controllo del carico di lavoro	Controllo della piattaforma
Origini Internet pubbliche	L'agente potrebbe richiedere la ricerca Internet per avviare una richiesta di Azure OpenAI in Foundry Models	Applicare gruppi di sicurezza di rete nella subnet di integrazione dell'agente	Applicare le regole dell'applicazione firewall per gli archivi conoscenze e gli strumenti esterni
Piano dati di Microsoft Foundry	L'interfaccia utente della chat interagisce con l'agente di chat	Consentire il traffico TCP/443 dalla subnet di integrazione del Servizio App alla subnet dell'endpoint privato Foundry.	Nessuno
Azure Cosmos DB, un servizio di database distribuito globale di Microsoft	Per accedere al database di memoria dal servizio Agente Foundry	Consentire TCP su ogni porta nella subnet dell'endpoint privato di Azure Cosmos DB	Nessuno

Per il traffico che lascia la rete virtuale del carico di lavoro, questa architettura applica i controlli a livello di carico di lavoro tramite gruppi di sicurezza di rete e a livello di piattaforma tramite un firewall di rete hub. I gruppi di sicurezza di rete forniscono regole di traffico di rete iniziali e generali. Nell'hub della piattaforma il firewall applica regole più specifiche per una maggiore sicurezza.

Questa architettura non richiede il traffico east-west tra componenti interni, ad esempio il servizio agente Foundry e l'istanza di ricerca di intelligenza artificiale dipendente, per instradare attraverso la rete hub.

Protezione DDoS

Determinare chi deve applicare il piano di protezione DDoS che copre gli indirizzi IP pubblici della soluzione. Il team della piattaforma potrebbe usare i piani di protezione degli indirizzi IP oppure potrebbe usare Criteri di Azure per applicare i piani di protezione della rete virtuale. Questa architettura richiede la copertura protezione DDoS perché ha un indirizzo IP pubblico per l'ingresso da Internet. Per maggiori informazioni, consultare la sezione Raccomandazioni per la rete e la connettività.

Gestione delle identità e degli accessi

A meno che l'automazione della governance del team della piattaforma non richieda controlli aggiuntivi, questa architettura non introduce nuovi requisiti di autorizzazione a causa del coinvolgimento del team della piattaforma. Il controllo degli accessi in base al ruolo di Azure deve continuare a soddisfare il principio dei privilegi minimi, che concede l'accesso limitato solo alle persone che ne hanno bisogno e solo quando necessario. Per maggiori informazioni, consultare la sezione Raccomandazioni per la gestione delle identità e degli accessi.

Certificati e crittografia

Il team in genere ottiene il certificato TLS per l'indirizzo IP pubblico nel gateway applicazione. Collaborare con il team della piattaforma per comprendere in che modo i processi di approvvigionamento e gestione dei certificati devono essere allineati alle aspettative dell'organizzazione.

Tutti i servizi di archiviazione dati in questa architettura supportano le chiavi di crittografia gestite da Microsoft o gestite dal cliente. Usare chiavi di crittografia gestite dal cliente se la progettazione o l'organizzazione del carico di lavoro richiede un maggiore controllo. Le zone di destinazione di Azure stesse non impongono un metodo specifico.

Microsoft Defender for Cloud

Usare la stessa configurazione per Microsoft Defender for Cloud come descritto nell'architettura di base. Se il processo di distribuzione automatica della sottoscrizione non abilita automaticamente questi piani di Defender, assicurarsi di assumere questa responsabilità come team del carico di lavoro. L'integrazione di Purview per i componenti di intelligenza artificiale in questo carico di lavoro viene abilitata tramite il piano di servizi di Defender per intelligenza artificiale.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Tutte le strategie di ottimizzazione dei costi nell'architettura di base si applicano alle risorse del carico di lavoro in questa architettura.

Questa architettura trae notevolmente vantaggio dalle risorse della piattaforma della zona di destinazione di Azure. Ad esempio, le risorse come Firewall di Azure e Protezione DDoS passano dal carico di lavoro alle risorse della piattaforma. Anche se si usano tali risorse tramite un modello di chargeback, la sicurezza e la connettività cross-premise aggiunte sono più convenienti rispetto alla gestione automatica di tali risorse. Sfruttare i vantaggi di altre offerte centralizzate del team della piattaforma per estendere tali vantaggi al carico di lavoro senza compromettere l'obiettivo del livello di servizio, l'obiettivo del tempo di ripristino o l'obiettivo del punto di ripristino.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

L'utente rimane responsabile di tutte le considerazioni sull'eccellenza operativa dell'architettura di base. Queste responsabilità includono monitoraggio, GenAIOps, controllo della qualità e procedure di distribuzione sicure.

Correlare i dati da più sink

L'area di lavoro Log di Monitoraggio di Azure del carico di lavoro archivia i log e le metriche del carico di lavoro e i relativi componenti dell'infrastruttura. Tuttavia, un'area di lavoro centrale dei log di Monitoraggio di Azure archivia spesso log e metriche da servizi centralizzati, ad esempio Firewall di Azure, resolver privato DNS e Azure Bastion. La correlazione dei dati da più sink può essere un'attività complessa.

I dati correlati consentono di supportare la risposta agli eventi imprevisti. Il runbook di valutazione per questa architettura deve risolvere questa situazione e includere le informazioni di contatto dell'organizzazione se il problema si estende oltre le risorse del carico di lavoro. Gli amministratori del carico di lavoro potrebbero richiedere assistenza agli amministratori della piattaforma per correlare le voci di log dalle reti aziendali, dalla sicurezza o da altri servizi della piattaforma.

Agenti di compilazione

Molti servizi in questa architettura usano endpoint privati. Analogamente all'architettura di base, questa progettazione potrebbe richiedere agenti di compilazione. Il team distribuisce gli agenti di compilazione in modo sicuro e affidabile. Il team della piattaforma non è coinvolto in questo processo.

Assicurarsi che la gestione dell'agente di compilazione sia conforme agli standard dell'organizzazione. Questi standard possono includere l'uso di immagini del sistema operativo approvate dalla piattaforma, pianificazioni di patch, report di conformità e metodi di autenticazione utente.

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Le considerazioni sull'efficienza delle prestazioni nell'architettura di base si applicano anche a questa architettura. Il team mantiene il controllo sulle risorse nei flussi dell'applicazione, non sul team della piattaforma. Ridimensionare l'host dell'interfaccia utente della chat, i modelli linguistici e altri componenti in base ai vincoli di carico di lavoro e costi. A seconda dell'implementazione finale dell'architettura, prendere in considerazione i fattori seguenti quando si misurano le prestazioni rispetto agli obiettivi di prestazioni:

• Uscita e latenza cross-premise
• Limitazioni dello SKU dalla governance del contenimento dei costi

Distribuire lo scenario

Distribuire un'implementazione della zona di destinazione di questa architettura di riferimento.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

• Bilal Amjad | Microsoft Cloud Solution Architect
• Freddy Ayala | Microsoft Cloud Solution Architect
• Chad Kittel | Principal Software Engineer - Modelli e procedure di Azure

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passo successivo

Informazioni su come collaborare ai dettagli tecnici con il team della piattaforma.

Risorsa collegata

• Una prospettiva di Well-Architected Framework sui carichi di lavoro di intelligenza artificiale in Azure