Replica di oggetti per i BLOB in blocchi

La replicazione degli oggetti copia in modo asincrono i BLOB di blocco tra un account di archiviazione di origine e un account di destinazione. Alcuni scenari supportati dalla replica di oggetti includono:

• Ridurre al minimo la latenza. La replicazione degli oggetti riduce la latenza nelle richieste di lettura permettendo ai client di consumare dati da una regione fisicamente più vicina.
• Aumento dell'efficienza per i carichi di lavoro di calcolo. Con la replica di oggetti, i carichi di lavoro di calcolo possono elaborare gli stessi set di BLOB in blocchi in aree diverse.
• Ottimizza la distribuzione dei dati. È possibile elaborare o analizzare i dati in un'unica posizione e quindi replicare solo i risultati in aree aggiuntive.
• Ottimizzare i costi. Dopo che i tuoi dati sono stati replicati, puoi ridurre i costi spostandoli al livello archivio utilizzando politiche di gestione del ciclo di vita.

Il diagramma seguente illustra come la replica di oggetti replichi i BLOB a blocchi da un account di archiviazione di origine in una regione verso account di destinazione in due regioni diverse.

Per informazioni su come configurare la replica di oggetti, vedere Configurare la replica di oggetti.

Prerequisiti e avvertenze per la replica di oggetti

La replica di oggetti richiede che siano abilitate anche le funzionalità di Archiviazione di Azure seguenti:

• Feed delle modifiche: Abilitalo nell'account di origine. Per informazioni su come abilitare il feed di modifiche, vedere Enable e disabilitare il feed di modifiche.
• Controllo delle versioni dei BLOB: abilitalo sia nell'account di origine sia in quello di destinazione. Per informazioni su come abilitare il controllo delle versioni, consultare Abilitare e gestire il controllo delle versioni dei BLOB.

L'abilitazione del feed di cambiamento e del versionamento dei blob può implicare costi aggiuntivi. Per altre informazioni, vedere la pagina dei prezzi Archiviazione di Azure.

La replicazione degli oggetti supporta account di archiviazione v2 per utilizzo generico e account BLOB a blocchi premium. Entrambi gli account di origine e di destinazione devono essere account per utilizzo generico v2 o account BLOB in blocchi Premium. La replica degli oggetti supporta solo i BLOB a blocchi; non supporta i BLOB di accodamento e i BLOB di pagine.

La replicazione degli oggetti supporta account criptati con chiavi gestite da Microsoft o gestite dal cliente. Per altre informazioni sulle chiavi gestite dal cliente, vedere Chiavi gestite dal cliente per la crittografia dello Storage di Azure.

La replica di oggetti non supporta i blob nell'account sorgente crittografati con una chiave fornita dal cliente. Per altre informazioni sulle chiavi fornite dal cliente, vedere Provide una chiave di crittografia in una richiesta di Blob storage.

Il failover gestito dal cliente non è supportato per l'origine o l'account di destinazione in un criterio di replica di oggetti.

La replica degli oggetti non è supportata negli account che hanno abilitato uno spazio di nomi gerarchico.

La replica di oggetti non è supportata per i BLOB caricati tramite api Data Lake Storage.

Funzionamento della replica di oggetti

La replica di oggetti copia in modo asincrono i BLOB in blocchi in un contenitore in base alle regole configurate. Il servizio copia il contenuto del blob, tutte le versioni associate al blob, e i metadati e le proprietà del blob dal contenitore sorgente al container di destinazione.

Importante

Poiché i dati BLOB in blocchi vengono replicati in modo asincrono, l'account di origine e l'account di destinazione non vengono sincronizzati immediatamente.

La replicazione degli oggetti (OR) ora supporta la replica prioritaria, che dà priorità alla replicazione di tutte le operazioni in una policy OR. Quando la replica con priorità OR è abilitata, le prestazioni di replica di tutte le operazioni migliorano. Quando gli account di origine e di destinazione dei criteri di replica si trovano nello stesso continente, con la replica prioritaria OR viene replicato anche il 99% degli oggetti entro 15 minuti per i carichi di lavoro supportati. Le prestazioni delle funzionalità sono garantite con un contratto di servizio. Per maggiori informazioni, consulta i termini del contratto di servizio (SLA) e l'articolo Replica con priorità della replica degli oggetti.

È anche possibile controllare lo stato della replica nel BLOB di origine per determinare se la replica è stata completata. Per altre informazioni, vedere Controllare lo stato di replica di un BLOB.

Controllo delle versioni per i BLOB

La replica degli oggetti richiede di abilitare la versione dei blob sia sull'account sorgente che su quello di destinazione. Quando modifichi un blob replicato nell'account sorgente, il servizio crea una nuova versione del blob nell'account sorgente che riflette lo stato precedente del blob, prima della modifica. La versione corrente nell'account di origine riflette gli aggiornamenti più recenti. Il servizio replica sia la versione attuale che qualsiasi versione precedente sull'account di destinazione. Per altre informazioni su come le operazioni di scrittura influiscono sulle versioni dei BLOB, vedere Controllo delle versioni nelle operazioni di scrittura.

Qualora nell'account di archiviazione siano in vigore criteri di replica degli oggetti, non è possibile disabilitare il versioning dei blob per tale account. Prima di disabilitare il controllo delle versioni dei BLOB, è necessario eliminare tutti i criteri di replica degli oggetti nell'account.

Note

Solo i blob vengono copiati nella destinazione. Il servizio non copia l'ID della versione di un blob. Dopo che il servizio posiziona un blob nella destinazione, assegna un nuovo ID di versione.

Eliminazione di un BLOB nell'account di origine

Quando elimini un blob nell'account sorgente, la versione corrente del blob diventa una versione precedente e non esiste più una versione attuale. Il servizio conserva tutte le versioni precedenti esistenti del blob. Il servizio replica questo stato sull'account di destinazione. Per maggiori informazioni su come le operazioni di eliminazione influenzano le versioni dei blob, vedi Versioning on delete operations.

Snapshot

La replica di oggetti non supporta gli snapshot dei BLOB. Il servizio non replica alcuna snapshot di un BLOB dall'account di origine all'account di destinazione.

Tag indice del BLOB

La replica di oggetti supporta ora la copia di tag di indice dai BLOB di origine ai BLOB di destinazione. È possibile configurare questa funzionalità come parte di una regola di replica nuova o esistente. Per altre informazioni, vedere Configurare la replica di oggetti.

Importante

La replica dei tag è attualmente in anteprima. Vedere i Termini di utilizzo supplementari per le anteprime di Microsoft Azure che si applicano alle funzionalità di Azure in versione beta, in anteprima o non ancora disponibili per il pubblico generale.

Suddivisione in livelli BLOB

La replica di oggetti è supportata quando gli account di origine e di destinazione si trovano in un livello online qualsiasi (ad accesso frequente, sporadico o saltuario). Gli account di origine e di destinazione potrebbero trovarsi in livelli diversi. Tuttavia, la replica di oggetti non riesce se un blob nell'account di origine o in quello di destinazione viene spostato nel livello archivio. Reidratare un blob archiviato non attiva la replica degli oggetti. La replica di oggetti viene attivata solo quando i dati del BLOB vengono aggiornati di nuovo dopo la riidratazione. Per altre informazioni sui livelli BLOB, vedere Livelli di accesso per i dati BLOB.

BLOB non modificabili

I criteri di immutabilità per Archiviazione BLOB di Azure includono criteri di conservazione basati sul tempo e blocchi legali. Quando una politica di immutabilità è attiva sull'account di destinazione, la replica degli oggetti potrebbe essere influenzata. Per ulteriori informazioni sui criteri di immutabilità, vedere Archiviare dati blob critici per il business con archiviazione immutabile.

Se il contenitore di destinazione dispone di criteri di immutabilità a livello di contenitore, le modifiche apportate agli oggetti nel contenitore di origine, ad esempio aggiornamenti o eliminazioni, potrebbero comunque avere esito positivo. Tuttavia, queste modifiche potrebbero non riuscire a eseguire la replica nel contenitore di destinazione a causa della restrizione dell'immutabilità. Per altre informazioni sulle operazioni non consentite con un criterio di immutabilità con ambito di un contenitore, vedere Scenari con ambito a livello di contenitore.

Se la versione BLOB di un account di destinazione ha un criterio di immutabilità a livello di versione attivo, un'operazione di eliminazione o aggiornamento eseguita sulla versione BLOB del contenitore di origine corrispondente potrebbe avere esito positivo. Tuttavia, la replica dell'operazione nell'oggetto di destinazione ha esito negativo. Per ulteriori informazioni sulle operazioni vietate con una politica di immutabilità con ambito a livello di versione, vedere Scenari con ambito a livello di versione.

Regole e criteri di replica di oggetti

Quando si configura la replica di oggetti, si creano criteri di replica che specificano l'account di origine storage e l'account di destinazione. I criteri di replica includono una o più regole che specificano un contenitore di origine e di destinazione e indicano quali BLOB di origine vengono replicati.

Dopo aver configurato la replica di oggetti, Archiviazione di Azure controlla periodicamente il feed di modifiche per l'account di origine e replica in modo asincrono tutte le operazioni di scrittura o eliminazione nell'account di destinazione. La latenza di replica dipende dalla dimensione del BLOB in blocchi da replicare.

Criteri di replica

Quando configuri la replica degli oggetti, crei una policy di replica sull'account destinazione tramite il provider di risorse Archiviazione di Azure. Dopo aver creato la policy di replicazione, Archiviazione di Azure le assegna un ID policy. È quindi necessario associare tale criterio di replica all'account di origine usando l'ID criterio. L'ID della policy sugli account di origine e destinazione deve essere lo stesso affinché la replica avvenga.

Un account di origine può eseguire la replica in massimo due account di destinazione, con un criterio per ogni account di destinazione. Analogamente, un account potrebbe fungere da account di destinazione per non più di due criteri di replica.

Gli account di origine e di destinazione potrebbero trovarsi nella stessa area o in aree diverse. Possono risiedere anche nella stessa sottoscrizione o in sottoscrizioni diverse. Facoltativamente, gli account di origine e di destinazione possono risiedere in tenant di Microsoft Entra diversi. Puoi creare una sola policy di replica per ogni coppia di account sorgente e destinazione.

Regole di replica

Le regole di replica specificano come Archiviazione di Azure replica i BLOB da un contenitore di origine a un contenitore di destinazione. È possibile specificare fino a 1.000 regole di replica per ogni criterio di replica. Ogni regola di replica definisce un singolo contenitore di origine e di destinazione e ogni contenitore di origine e di destinazione può essere usato in una sola regola. Di conseguenza, un massimo di 1.000 contenitori di origine e 1.000 contenitori di destinazione possono partecipare a una singola politica di replica.

Dopo aver creato una regola di replica, i BLOB preesistenti vengono ignorati; solo i nuovi BLOB in blocchi aggiunti dopo la creazione della regola vengono copiati per impostazione predefinita. È possibile tuttavia specificare che vengono copiati i BLOB in blocchi nuovi ed esistenti. È anche possibile definire un ambito di copia personalizzato che copia tutti i BLOB in blocchi creati dopo un determinato periodo di tempo.

È anche possibile specificare uno o più filtri come parte di una regola di replica per filtrare i BLOB in blocchi per prefisso. Quando si specifica un prefisso, solo i BLOB corrispondenti al prefisso nel contenitore di origine vengono copiati nel contenitore di destinazione.

Devono esistere sia i contenitori di origine che di destinazione prima di poterli specificare in una regola. Dopo aver creato i criteri di replica, le operazioni di scrittura nel contenitore di destinazione non sono consentite. Qualsiasi tentativo di scrittura nel contenitore di destinazione non riesce e viene restituito il codice errore 409 (conflitto).

Per scrivere in un contenitore di destinazione con una regola di replica, è prima necessario disabilitare la replica. Puoi disabilitare la regola eliminandola per quel contenitore o rimuovendo l'intera policy di replicazione.

Le operazioni di lettura ed eliminazione nel contenitore di destinazione sono consentite quando i criteri di replica sono attivi.

È possibile chiamare l'operazione Imposta livello BLOB su un BLOB nel contenitore di destinazione per poterlo spostare in un livello di archivio. Per ulteriori informazioni sul livello archivio, vedere Livelli di accesso per i dati BLOB.

Note

La modifica del livello access di un BLOB nell'account di origine non modifica il livello access del BLOB nell'account di destinazione.

File di definizione dei criteri

Usa un file JSON per definire una policy di replicazione degli oggetti. È possibile ottenere il file di definizione dei criteri da un criterio di replica di oggetti esistente oppure è possibile creare un criterio di replica di oggetti caricando un file di definizione dei criteri.

File di definizione dei criteri di esempio

Nell'esempio seguente vengono impostati criteri di replica nell'account di destinazione con una regola. La regola è destinata ai BLOB con il prefisso b e specifica un tempo di creazione minimo per la replica. Ricordare di sostituire i valori tra parentesi angolari con valori personalizzati:

{
  "properties": {
    "policyId": "default",
    "sourceAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "destinationAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "metrics": {
		  "enabled": false
    },
    "priorityReplication": "false",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-28T00:00:00Z"
        }
      }
    ]
  }
}

Filtri personalizzati

Puoi personalizzare i filtri con diverse opzioni in un file JSON:

• Abbina i blob per prefisso — replica solo gli blob i cui nomi iniziano con la lettera b.

"filters": {
          "prefixMatch": [
            "b"
          ],
        }

• Abbina i blob per tempo di creazione — replica solo i blob creati nel tempo specificato o dopo.

"filters": {
  "minCreationTime": "2021-08-28T00:00:00Z"
}

• Replica tutti i blob — imposta il tempo minimo di creazione al valore più precoce possibile.

"filters": {
  "minCreationTime": "1601-01-01T00:00:00Z"
}

Specificare gli ID risorsa completi per gli account di origine e di destinazione

Quando si crea il file di definizione dei criteri, specificare gli ID risorsa Azure Resource Manager completi per le voci sourceAccount e destinationAccount, come illustrato nell'esempio nella sezione precedente. Per informazioni su come individuare l'ID risorsa per un account storage, vedere Get the resource ID for a storage account.

L'ID risorsa completo è nel formato seguente:

/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>

Il file di definizione dei criteri in precedenza richiedeva solo il nome dell'account, anziché l'ID risorsa completo per l'account storage. Con l'introduzione della proprietà di sicurezza AllowCrossTenantReplication nella versione 2021-02-01 dell'API REST del provider di risorse Archiviazione di Azure, ora devi fornire l'ID completo della risorsa per qualsiasi politica di replica degli oggetti che crei quando la replica cross-tenant è vietata per un account di archiviazione che partecipa alla policy di replica. Archiviazione di Azure usa l'ID risorsa completo per verificare se gli account di origine e di destinazione si trovano nello stesso tenant. Per altre informazioni su come non consentire i criteri di replica tra tenant, vedere Impedire la replica nei tenant di Microsoft Entra.

Anche se l'uso solo del nome dell'account è ancora supportato per la replica tra tenant, Microsoft consiglia di usare l'ID risorsa completo come procedura consigliata. Tutte le versioni precedenti dell'API REST del provider di risorse Archiviazione di Azure usano il percorso completo dell'ID risorsa nei criteri di replica degli oggetti.

Nella tabella seguente viene illustrato come il comportamento dei criteri di replica differisce quando si usa un ID risorsa completo rispetto a un nome account. Il confronto dipende dal fatto che la replicazione tra tenant sia consentita per l'account di archiviazione.

Identificatore dell'account di archiviazione nella definizione dei criteri	Replica tra tenant consentita	Replica tra tenant non consentita
ID risorsa completo	È possibile creare criteri dello stesso tenant. È possibile creare criteri tra tenant.	È possibile creare criteri dello stesso tenant. Non è possibile creare criteri tra tenant.
Solo nome account	È possibile creare criteri dello stesso tenant. È possibile creare criteri tra tenant.	Non è possibile creare né criteri dello stesso tenant né tra tenant. Si verifica un errore, perché Archiviazione di Azure non è in grado di verificare che gli account di origine e di destinazione si trovino nello stesso tenant. L'errore indica che è necessario specificare l'ID risorsa completo per le voci sourceAccount e destinationAccount nel file di definizione dei criteri.

Specificare gli ID dei criteri e delle regole

Nella tabella seguente vengono riepilogati i valori da usare per le voci policyId e ruleId nel file di definizione dei criteri in ogni scenario.

Quando si crea il file di definizione dei criteri per questo account...	Impostare l'ID criterio su questo valore	Impostare gli ID regola su questo valore
Account di destinazione	Valore stringa predefinito. Archiviazione di Azure crea automaticamente il valore del policy ID per te.	Stringa vuota. Archiviazione di Azure genera i valori ID delle regole per te.
Account di origine	Il valore dell'ID criterio restituito al momento del download del file di definizione dei criteri per l'account di destinazione.	I valori degli ID delle regole restituiti al momento del download del file di definizione dei criteri per l'account di destinazione.

Impedire la replica tra tenant Microsoft Entra

Un tenant Microsoft Entra è un'istanza dedicata di Microsoft Entra ID che rappresenta un'organizzazione per la gestione delle identità e degli accessi. Ogni sottoscrizione Azure ha una relazione di trust con un singolo tenant Microsoft Entra. Tutte le risorse in una sottoscrizione, inclusi gli account di archiviazione, sono associate allo stesso tenant Microsoft Entra. Per altre informazioni, vedere Che è Microsoft Entra ID?

Per impostazione predefinita, la replica tra tenant è disabilitata per i nuovi account creati a partire dal 15 dicembre 2023. Se i criteri di sicurezza richiedono di limitare la replica degli oggetti agli account storage che risiedono solo nello stesso tenant, è possibile impedire la replica tra tenant impostando una proprietà di sicurezza, la proprietà AllowCrossTenantReplication (anteprima). Quando si disabilita la replica di oggetti tra tenant per un account di archiviazione, Archiviazione di Azure impone un requisito aggiuntivo. Per i criteri di replica degli oggetti che usano questo account di archiviazione come origine o destinazione, entrambi gli account devono appartenere allo stesso tenant Microsoft Entra. Per ulteriori informazioni su come impedire la replica degli oggetti tra tenant, vedere Prevent object replication across Microsoft Entra tenants.

Per impedire la replica di oggetti tra tenant per un account storage, impostare la proprietà AllowCrossTenantReplication su false. Se l'account storage non partecipa attualmente ad alcun criterio di replica di oggetti tra tenant, l'impostazione della proprietà AllowCrossTenantReplication su false impedisce una configurazione futura dei criteri di replica di oggetti tra tenant con questo account storage come origine o destinazione.

Se l'account storage partecipa attualmente a uno o più criteri di replica di oggetti multi-tenant, l'impostazione della proprietà AllowCrossTenantReplication su false non è consentita. È necessario eliminare i criteri tra tenant esistenti prima di non consentire la replica tra tenant.

Per impostazione predefinita, la proprietà AllowCrossTenantReplication è impostata su false per un account storage creato a partire dal 15 dicembre 2023. Per gli account storage creati prima del 15 dicembre 2023, quando il valore della proprietà AllowCrossTenantReplication per un account storage è null o true, gli utenti autorizzati possono quindi configurare i criteri di replica di oggetti tra tenant con questo account come origine o destinazione. Per altre informazioni su come configurare i criteri tra tenant, vedere Configurare la replica degli oggetti per i BLOB in blocchi.

È possibile usare Criteri di Azure per controllare un set di account di archiviazione per assicurarsi che la proprietà AllowCrossTenantReplication sia impostata per impedire la replica di oggetti tra tenant. È anche possibile usare Criteri di Azure per applicare la governance per un set di account di archiviazione. Ad esempio, è possibile creare un criterio con l'effetto deny per impedire a un utente di creare un account storage in cui la proprietà AllowCrossTenantReplication è impostata su true o dalla modifica di un account di storage esistente per modificare il valore della proprietà in true.

Metriche di replica

La replica di oggetti supporta due metriche per fornire informazioni dettagliate sullo stato di avanzamento della replica:

• Operazioni in sospeso per la replica: numero totale di operazioni in sospeso per la replica dall'account di origine all'account di archiviazione di destinazione, emesso per ciascun bucket temporale.
• Byte in sospeso per la replica: somma dei byte in sospeso per la replica dagli account di archiviazione di origine a quelli di destinazione emessi per intervalli di tempo

Ognuna delle metriche elencate in precedenza può essere visualizzata con la dimensione dei bucket di tempo. Questa suddivisione consente di acquisire informazioni dettagliate sul numero di byte o operazioni in sospeso per la replica per intervalli di tempo, come indicato di seguito.

• 0-5 minuti
• 5-10 minuti
• 10-15 minuti
• 15-30 minuti
• 30 minuti a 2 ore
• 2-8 ore
• 8-24 ore
• >24 ore

L'immagine di esempio seguente mostra la metrica delle operazioni e dei byte in sospeso per i sette giorni precedenti:

È possibile abilitare le metriche di replica nell'account di origine per il monitoraggio dei byte in sospeso e delle operazioni in sospeso. Per altre informazioni, vedere Configurare le metriche di replica.

Stato della replica

È possibile controllare lo stato della replica per un BLOB nell'account di origine. Per altre informazioni, vedere Controllare lo stato di replica di un BLOB.

Note

Mentre la replica è in corso, non c'è modo di determinare la percentuale di dati replicati.

Se lo stato di replicazione di un blob nell'account sorgente indica un fallimento, indagare sulle seguenti possibili cause:

• Assicurati che la policy di replica degli oggetti sia configurata sull'account destinazione.
• Verificare che l'account di destinazione esista ancora.
• Verificare che il contenitore di destinazione esista ancora.
• Verificare che il contenitore di destinazione non venga eliminato e che non sia in corso l'eliminazione. L'eliminazione di un contenitore può richiedere fino a 30 secondi.
• Verificare che il contenitore di destinazione partecipi ancora ai criteri di replica degli oggetti.
• Se il BLOB di origine viene crittografato con una chiave fornita dal cliente come parte di un'operazione di scrittura, la replica degli oggetti non riesce. Per altre informazioni sulle chiavi fornite dal cliente, vedere Provide una chiave di crittografia in una richiesta di Blob storage.
• Controllare se il BLOB di origine o di destinazione viene spostato nel livello archivio. I BLOB archiviati non possono essere replicati tramite la replica di oggetti. Per ulteriori informazioni sul livello archivio, vedere Livelli di accesso per i dati BLOB.
• Verificare che il contenitore di destinazione o il blob non sia protetto da una politica di immutabilità. Un container o un blob può ereditare una politica di immutabilità dal suo genitore. Per ulteriori informazioni sui criteri di immutabilità, vedere Panoramica dello storage non modificabile per i dati BLOB.

Supporto delle funzionalità

Il supporto per questa funzionalità potrebbe essere influenzato dall'abilitazione di Data Lake Storage Gen2, del protocollo NFS (Network File System) 3.0 o del protocollo SFTP (SSH File Transfer Protocol). Se hai abilitato una di queste funzionalità, vedere supporto delle funzionalità di gestione rete virtuale di Azure negli account di Archiviazione di Azure per valutare il supporto per queste funzionalità.

Fatturazione

Non c'è alcun costo per configurare la replica degli oggetti, inclusa l'abilitazione delle politiche di change feed, versioning e replicazione. Tuttavia, la replica di oggetti comporta costi per le transazioni di lettura e scrittura sugli account di origine e di destinazione. Anche i costi di uscita per la replica dei dati dal conto di origine al conto di destinazione comportano costi, così come i costi di lettura durante l'elaborazione del flusso di modifiche.

Ecco una suddivisione dei costi. Per trovare il prezzo di ogni componente di costo, consultare Archiviazione BLOB di Azure Pricing.

Costo per aggiornare un BLOB nell'account di origine	Costo per replicare i dati nell'account di destinazione
Costo della transazione di un'operazione di scrittura	Costo di transazione per la lettura di un record del feed di modifiche
Costo di archiviazione del BLOB e di ogni versione di BLOB1	Costo di transazione per la lettura del BLOB e delle versioni del BLOB2
Costo per aggiungere un record del feed di modifiche	Costo di transazione per la scrittura del BLOB e delle versioni del BLOB2
Costi di recupero dei dati su livelli a bassa frequenza e livelli a bassa temperatura	Costo di archiviazione del BLOB e di ogni versione di BLOB1
	Costo dell'uscita di rete 3

¹ Sull'account sorgente, se il livello di un blob o di una versione rimane invariato, allora vieni addebitato per blocchi di dati unici tra quel blob e le sue versioni. Vedere Prezzi e fatturazione per il controllo delle versioni dei BLOB. Nell'account di destinazione, per una versione, ti vengono addebitati tutti i blocchi di una versione, indipendentemente dal fatto che quei blocchi siano unici o meno.

² Questo costo include solo le versioni blob create dopo il completamento dell'ultima replica.

³ La replica di oggetti copia l'intera versione nella destinazione (non solo i blocchi univoci della versione). Questo trasferimento comporta il costo dell'uscita di rete. Visualizza prezzi di banda.

Suggerimento

Per ridurre il rischio di una fattura imprevista, abilitare la replica degli oggetti in un account che contiene solo alcuni oggetti. Misurare quindi l'impatto sui costi prima di abilitare la funzionalità in un'impostazione di produzione.

Passaggi successivi

• Configurare la replica di oggetti
• Impedire la replica di oggetti tra i tenant di Microsoft Entra
• Versionamento dei Blob
• Supporto del feed di modifiche nell'archiviazione BLOB di Azure