Réplication d'objets blob de blocs

La réplication d'objets copie de manière asynchrone des objets blob de blocs entre un compte de stockage source et un compte de destination. Voici quelques scénarios pris en charge par la réplication d’objets :

• Minimisation de la latence. La réplication d’objets peut réduire la latence des demandes de lecture en permettant aux clients d’utiliser des données provenant d’une région plus proche en termes de proximité physique.
• Augmentation de l’efficacité des charges de travail de calcul. Avec la réplication d’objets, les charges de travail de calcul peuvent traiter les mêmes ensembles d’objets blob de blocs dans différentes régions.
• Optimisation de la distribution des données. Vous pouvez traiter ou analyser des données dans un emplacement unique, puis répliquer uniquement les résultats dans des régions supplémentaires.
• Optimisation des coûts. Une fois vos données répliquées, vous pouvez réduire les coûts en les déplaçant vers le niveau archive à l’aide de stratégies de gestion du cycle de vie.

Le diagramme suivant montre comment la réplication d’objets réplique les objets blob de blocs d’un compte de stockage source dans une région vers des comptes de destination dans deux régions différentes.

Pour plus d'informations sur la configuration de la réplication d'objets, consultez Configurer la réplication d'objets.

Conditions préalables et mises en garde pour la réplication d’objets

La réplication d'objets exige que les fonctionnalités de stockage Azure suivantes soient également activées :

• Flux de modification : doit être activé sur le compte source. Pour plus d'informations sur l'activation du flux de modifications, consultez Activer et désactiver le flux de modifications.
• Contrôle de version des objets blob : doit être activé sur les comptes source et de destination. Pour plus d'informations sur l'activation du contrôle de version des objets blob, consultez Activer et gérer le contrôle de version des objets blob.

L'activation du flux de modification et du versionnage de blob peut entraîner des coûts supplémentaires. Pour plus d’informations, consultez la page Tarification de Stockage Azure.

La réplication d’objet est prise en charge pour les comptes de stockage v2 universels et les comptes d’objets blob de blocs Premium. Les comptes source et de destination doivent être des comptes à usage général v2 ou des comptes d’objet blob de blocs Premium. La réplication d’objets prend en charge uniquement les objets blob de blocs. Les objets blob d’ajouts et les objets blob de pages ne sont pas pris en charge.

La réplication d’objets est prise en charge pour les comptes chiffrés avec des clés gérées par Microsoft ou gérées par le client. Pour plus d'informations sur les clés gérées par le client, consultez Clés gérées par le client pour le chiffrement du Stockage Azure.

La réplication d’objets n’est pas prise en charge pour les objets blob dans le compte source, qui sont chiffrés avec une clé fournie par le client. Pour plus d’informations sur les clés fournies par le client, consultez Fournir une clé de chiffrement lors d’une requête au stockage d’objets blob.

Le basculement géré par le client n’est pas pris en charge pour le compte source ou de destination dans une stratégie de réplication d’objet.

La réplication d’objets n’est pas encore prise en charge dans les comptes qui ont un espace de noms hiérarchique activé.

La réplication d’objets n’est pas prise en charge pour les objets blob chargés à l’aide des API Data Lake Storage .

Fonctionnement de la réplication d’objets

La réplication d’objets copie de façon asynchrone les objets blob de blocs dans un conteneur selon les règles que vous configurez. Le contenu de l’objet blob, toutes les versions associées à l’objet blob, ainsi que les métadonnées et propriétés de l’objet blob sont copiés du conteneur source vers le conteneur de destination.

Important

Étant donné que les données d'objets blob de type bloc sont répliquées de manière asynchrone, le compte source et le compte de destination ne sont pas immédiatement synchronisés.

OR prend désormais en charge la réplication prioritaire, qui hiérarchise la réplication de toutes les opérations dans une politique OR. Lorsque la réplication de priorité OR est activée, les performances de réplication de toutes les opérations sont améliorées. Lorsqu'un compte source et un compte de destination d'une stratégie de réplication se trouvent sur le même continent, la réplication prioritaire OU réplique aussi 99,0 % des objets dans les 15 minutes pour les charges de travail prises en charge. Les performances des fonctionnalités sont garanties avec un contrat de niveau de service (SLA). Pour plus d’informations, consultez les termes du contrat SLA et l’article sur la priorité de réplication des objets.

Vous pouvez également vérifier l’état de réplication sur l’objet blob source pour déterminer si la réplication est terminée. Pour plus d’informations, consultez Vérifier l’état de réplication d’un objet blob.

Contrôle de version des objets blob

La réplication d’objets implique que le contrôle de version des objets blob soit activé sur les comptes source et de destination. Lorsqu’un objet blob répliqué dans le compte source est modifié, une nouvelle version de l’objet blob est créée dans le compte source et reflète l’état précédent de l’objet blob, avant modification. La version actuelle du compte source reflète les mises à jour les plus récentes. La version actuelle ainsi que toutes les versions précédentes sont répliquées vers le compte de destination. Pour plus d’informations sur la façon dont les opérations d’écriture affectent les versions d’objets blob, consultez Contrôle de version sur les opérations d’écriture.

Si votre compte de stockage a des stratégies de réplication d’objets en vigueur, vous ne pouvez pas désactiver la gestion des versions des blobs pour ce compte. Vous devez supprimer toutes les stratégies de réplication d’objets du compte avant de désactiver le versioning des objets blob.

Remarque

Seuls les objets blob sont copiés vers la destination. L'ID de version d'un blob n'est pas copié. Une fois qu’un objet blob est placé à l’emplacement de destination, un nouvel ID de version est affecté.

Suppression d’un objet blob dans le compte source

Lorsqu’un objet blob du compte source est supprimé, la version actuelle de l’objet blob devient une version antérieure, et il n’y a plus de version actuelle. Toutes les versions antérieures du blob sont conservées. Cet état est répliqué dans le compte de destination. Pour plus d’informations sur la façon dont les opérations de suppression affectent les versions d’objets blob, consultez Contrôle de version sur les opérations de suppression.

Instantanés

La réplication d’objets ne prend pas en charge les instantanés d’objets blob. Les instantanés d’un objet blob dans le compte source ne sont pas répliqués vers le compte de destination.

Étiquettes d’index d’objet blob

La réplication d’objets ne copie pas les balises d’index de l’objet blob source vers l’objet blob de destination.

Hiérarchisation des objets blob

La réplication d’objets est prise en charge quand les comptes source et de destination se trouvent dans n’importe quel niveau en ligne (chaud, sporadique ou froid). Les comptes source et de destination peuvent se trouver dans différents niveaux. Toutefois, la réplication d’objets échoue si un objet blob dans le compte source ou de destination est déplacé vers le niveau archive. Pour plus d’informations sur les niveaux d’objets blob, consultez Niveaux d’accès aux données blob.

Objets blob immuables

Les stratégies d’immuabilité comprennent des stratégies de rétention limitées dans le temps et la conservation légale. Lorsqu’une stratégie d’immuabilité est en vigueur sur le compte de destination, la réplication d’objets pourrait être affectée. Pour plus d’informations sur les stratégies d’immuabilité relatives au stockage d’objets blob, consultez Stocker des données blob critiques pour l’entreprise avec un stockage immuable.

Si le conteneur de destination a une stratégie d’immuabilité au niveau du conteneur en place, les modifications apportées aux objets du conteneur source, telles que les mises à jour ou les suppressions, peuvent toujours réussir. Toutefois, ces modifications peuvent ne pas être répliquées sur le conteneur de destination en raison de la restriction d’immuabilité. Pour plus d’informations sur les opérations interdites avec une stratégie d’immuabilité limitée à un conteneur, consultez Scénarios avec une portée au niveau du conteneur.

Si la version d’objet blob d’un compte de destination a une stratégie d’immuabilité active au niveau de la version, il est possible qu'une opération de suppression ou de mise à jour effectuée sur la version d’objet blob du conteneur source correspondante réussisse. Toutefois, la réplication de cette opération vers l’objet de destination échoue. Pour plus d'informations sur les opérations interdites par une politique d'immuabilité appliquée à un conteneur, voir Scénarios avec une portée de niveau version.

Stratégies et règles de réplication d’objets

Lorsque vous configurez la réplication d’objets, vous créez une stratégie de réplication qui spécifie le compte de stockage source et le compte de destination. Une stratégie de réplication inclut une ou plusieurs règles qui spécifient un conteneur source et de destination, et indiquent les objets blob sources répliqués.

Après avoir configuré la réplication d’objets, Stockage Azure vérifie régulièrement le flux de modification du compte source et réplique de manière asynchrone toutes les opérations d’écriture ou de suppression sur le compte de destination. La latence de la réplication dépend de la taille de l’objet blob de blocs en cours de réplication.

Stratégies de réplication

Lorsque vous configurez une réplication d’objet, vous créez une stratégie de réplication sur le compte de destination via le fournisseur de ressources de Stockage Azure. Une fois la stratégie de réplication créée, le service Stockage Azure lui attribue un ID de stratégie. Vous devez ensuite associer cette stratégie de réplication au compte source à l’aide de l’ID de stratégie. Pour que la réplication ait lieu, l’ID de stratégie doit être le même sur les comptes source et de destination.

Un compte source peut être répliqué sur deux comptes de destination maximum, avec une stratégie pour chaque compte de destination. De même, un compte peut servir de compte de destination pour pas plus de deux stratégies de réplication.

Les comptes source et de destination peuvent se trouver dans la même région ou dans différentes régions. Ils peuvent également résider dans le même abonnement ou dans différents abonnements. Si vous le souhaitez, les comptes source et de destination peuvent résider dans différents locataires Microsoft Entra. Une seule stratégie de réplication peut être créée pour chaque paire de comptes source/compte de destination.

Règles de réplication

Les règles de réplication spécifient comment Stockage Azure réplique les objets blob d’un conteneur source vers un conteneur de destination. Vous pouvez spécifier jusqu’à 1 000 règles de réplication pour chaque stratégie de réplication. Chaque règle de réplication définit un conteneur source et de destination unique, et chaque conteneur source et de destination peut être utilisé dans une seule règle. Par conséquent, un maximum de 1 000 conteneurs sources et 1 000 conteneurs de destination peuvent participer à une stratégie de réplication unique.

Après avoir créé une règle de réplication, les objets blob préexistants sont ignorés ; Seuls les nouveaux objets blob de blocs ajoutés après la création de la règle sont copiés par défaut. Toutefois, vous pouvez spécifier que les blobs de blocs nouveaux et existants sont copiés. Vous pouvez également définir une portée de copie personnalisée qui copie tous les block blobs créés après un moment spécifié.

Vous pouvez aussi spécifier un ou plusieurs filtres dans le cadre d’une règle de réplication pour filtrer les objets blob de blocs par préfixe. Lorsque vous spécifiez un préfixe, seuls les objets blob correspondant à ce préfixe dans le conteneur source sont copiés dans le conteneur de destination.

Les conteneurs source et de destination doivent tous les deux exister pour que vous puissiez les spécifier dans une règle. Une fois que vous avez créé la stratégie de réplication, les opérations d’écriture vers le conteneur de destination ne sont pas autorisées. Toute tentative d’écriture dans le conteneur de destination échoue avec le code d’erreur 409 (Conflit).

Pour écrire dans un conteneur de destination avec une règle de réplication, vous devez d’abord désactiver la réplication. Vous pouvez désactiver la règle en la supprimant pour ce conteneur ou en supprimant toute la stratégie de réplication.

Les opérations de lecture et de suppression sur le conteneur de destination sont autorisées lorsque la stratégie de réplication est active.

Vous pouvez appeler l’opération Définir le niveau du blob sur un blob dans le conteneur de destination pour le déplacer vers le niveau archive. Pour plus d’informations sur le niveau d’archive, consultez Niveaux d’accès aux données blob.

Remarque

La modification du niveau d’accès d’un objet blob dans le compte source ne modifie pas le niveau d’accès de cet objet blob dans le compte de destination.

Fichier de définition de la stratégie

Un fichier JSON est utilisé pour définir une stratégie de réplication d’objet. Vous pouvez obtenir le fichier de définition de stratégie à partir d’une stratégie de réplication d’objet existante ou créer une stratégie de réplication d’objet en chargeant un fichier de définition de stratégie.

Exemple de fichier de définition de la stratégie

L’exemple suivant définit une stratégie de réplication sur le compte de destination avec une règle. La règle cible les objets blob avec le préfixe b et spécifie une durée de création minimale pour la réplication. N’oubliez pas de remplacer les valeurs entre crochets par vos propres valeurs :

{
  "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>",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-028T00:00:00Z"
        }
      }
    ]
  }
}

Spécifier des ID de ressources complets pour les comptes source et de destination

Lorsque vous créez le fichier de définition de la stratégie, spécifiez les ID de ressource complets du Gestionnaire de ressource Azure pour les entrées sourceAccount et destinationAccount, comme indiqué dans l’exemple de la section précédente. Pour savoir comment localiser l’ID de ressource pour un compte de stockage, consultez Obtenir l’ID de ressource pour un compte de stockage.

L’ID de ressource complet est au format suivant :

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

Le fichier de définition de la stratégie ne nécessitait précédemment que le nom du compte, au lieu de l’ID de ressource complet du compte de stockage. Avec l’introduction de la propriété de sécurité AllowCrossTenantReplication dans la version du 02/01/2021 de l’API REST du fournisseur de ressource du Stockage Azure, vous devez maintenant fournir l’ID de ressource complet pour toutes les stratégies de réplication d’objet créées lorsque la réplication entre locataires est interdite pour un compte de stockage qui participe à la stratégie de réplication. Le Stockage Azure utilise l’ID de ressource complet pour vérifier si les comptes source et de destination se trouvent dans le même locataire. Pour en savoir plus sur l'interdiction des stratégies de réplication entre locataires, consultez Empêcher la réplication entre locataires Microsoft Entra.

Bien que l’utilisation uniquement du nom du compte soit toujours prise en charge pour la réplication interlocataire, Microsoft recommande d’utiliser l’ID de ressource complet comme meilleure pratique. Toutes les versions précédentes de l’API REST du fournisseur de ressource du Stockage Azure prennent en charge l’utilisation du chemin d’accès complet de l’ID de ressource dans les stratégies de réplication d’objets.

Le tableau suivant montre comment le comportement de stratégie de réplication diffère lorsque vous utilisez un ID de ressource complet et un nom de compte. La comparaison dépend du fait que la réplication entre locataires est autorisée pour le compte de stockage.

Identificateur de compte de Stockage dans la définition de la stratégie	Réplication entre locataires autorisée	Réplication entre locataires interdite
ID de ressource complet	Les mêmes stratégies de locataire peuvent être créées. Les stratégies entre locataires peuvent être créées.	Les mêmes stratégies de locataire peuvent être créées. Les stratégies entre locataires peuvent être créées.
Nom du compte uniquement	Les mêmes stratégies de locataire peuvent être créées. Les stratégies entre locataires peuvent être créées.	Vous ne pouvez pas créer de stratégies de locataires identiques ou entre locataires. Une erreur se produit, car Stockage Azure ne peut pas vérifier que les comptes source et de destination se trouvent dans le même locataire. L’erreur indique que vous devez spécifier l’ID de ressource complet pour les entrées sourceAccount et destinationAccount dans le fichier de définition de la stratégie.

Spécifier les ID de stratégie et de règle

Le tableau suivant récapitule les valeurs à utiliser pour les entrées policyId et ruleId dans le fichier de définition de la stratégie de chaque scénario.

Lors de la création du fichier de définition de la stratégie pour ce compte...	Définissez l’ID de stratégie sur cette valeur	Définissez les ID de règle sur cette valeur
Compte de destination	Valeur de chaîne par défaut. Le stockage Azure crée la valeur d’ID de stratégie pour vous.	Chaîne vide. Le stockage Azure crée les valeurs d’ID de règle pour vous.
Compte source	La valeur de l’ID de stratégie est retournée quand vous téléchargez le fichier de définition de la stratégie pour le compte de destination.	La valeur des ID de règle est retournée quand vous téléchargez le fichier de définition de la stratégie pour le compte de destination.

Empêcher la réplication entre les locataires Microsoft Entra

Un locataire Microsoft Entra est une instance dédiée de Microsoft Entra ID qui représente une organisation pour la gestion des identités et des accès. Chaque souscription Azure entretient une relation d’approbation avec un seul locataire Microsoft Entra. Toutes les ressources d'un abonnement, y compris les comptes de stockage, sont associées au même locataire Microsoft Entra. Pour plus d’informations, consultez Qu’est-ce que Microsoft Entra ID ?

Par défaut, la réplication entre locataires est désactivée pour les nouveaux comptes créés à compter du 15 décembre 2023. Si vos stratégies de sécurité exigent que vous restreigniez la réplication d’objets aux comptes de stockage qui résident dans le même locataire uniquement, vous pouvez interdire la réplication entre les locataires en définissant une propriété de sécurité, la propriété AllowCrossTenantReplication (préversion). Lorsque vous désactivez la réplication d’objets interlocataires pour un compte de stockage, Stockage Azure impose une exigence supplémentaire. Pour toute stratégie de réplication d’objet qui utilise ce compte de stockage comme source ou destination, les deux comptes doivent appartenir au même locataire Microsoft Entra. Pour plus d'informations sur l'interdiction de la réplication d'objets entre locataires, consultez Empêcher la réplication d'objets entre locataires Microsoft Entra.

Pour interdire la réplication d’objets entre locataires pour un compte de stockage, affectez la valeur falseà la propriété AllowCrossTenantReplication. Si le compte de stockage ne participe actuellement à aucune stratégie de réplication d’objet entre locataires, l’affectation de la valeur false à la propriété AllowCrossTenantReplication empêche la configuration ultérieure de stratégies de réplication d’objets entre locataires avec ce compte de stockage comme source ou destination.

Si le compte de stockage participe actuellement à une ou plusieurs stratégies de réplication d’objet entre locataires, l’affectation de la valeur false à la propriété AllowCrossTenantReplication n’est pas autorisée. Vous devez supprimer les stratégies entre locataires existantes avant de pouvoir désactiver la réplication entre locataires.

Par défaut, la propriété AllowCrossTenantReplication a la valeur false pour un compte de stockage créé à compter du 15 décembre 2023. Pour les comptes de stockage créés avant le 15 décembre 2023, lorsque la valeur de la propriété AllowCrossTenantReplication pour un compte de stockage a la valeur Null ou true, les utilisateurs autorisés peuvent configurer des stratégies de réplication d’objets interlocataires avec ce compte comme source ou destination. Pour plus d’informations sur la configuration des stratégies entre locataires, consultez Configurer la réplication d’objets pour les objets Blob de blocs.

Vous pouvez utiliser la Stratégie Azure pour auditer un ensemble de comptes de stockage et vous assurer que la propriété AllowCrossTenantReplication est définie pour empêcher la réplication d’objets entre locataires. Vous pouvez également utiliser la Stratégie Azure pour appliquer la gouvernance d’un ensemble de comptes de stockage. Par exemple, vous pouvez créer une stratégie avec l’effet deny pour empêcher un utilisateur de créer un compte de stockage où la propriété AllowCrossTenantReplication a la valeur true ou de modifier un compte de stockage existant pour modifier la valeur de propriété sur true.

Métriques de réplication

La réplication d’objets prend en charge deux métriques pour vous fournir des informations sur la progression de la réplication :

• Opérations en attente de réplication : nombre total d’opérations en attente de réplication de la source vers le compte de stockage de destination émis par les compartiments de temps
• Octets en attente pour la réplication : somme des octets en attente de réplication de la source vers les comptes de stockage de destination émis par les compartiments de temps

Chacune des métriques répertoriées précédemment peut être affichée avec la dimension des compartiments de temps. Cette répartition permet d’obtenir des insights sur le nombre d’octets ou d’opérations en attente pour la réplication par compartiments de temps comme suit :

• 0 à 5 minutes
• 5 à 10 minutes
• 10 à 15 minutes
• 15 à 30 minutes
• 30 minutes-2 heures
• 2 à 8 heures
• 8 à 24 heures
• >24 heures

L’exemple d’image suivant montre l’opération en attente et la métrique d’octets pour les sept jours précédents :

Vous pouvez activer les métriques de réplication sur le compte source pour surveiller les octets en attente et les opérations en attente. Pour plus d’informations, consultez Configurer les métriques de réplication.

État de la réplication

Vous pouvez vérifier l’état de réplication d’un objet blob dans le compte source. Pour plus d’informations, consultez Vérifier l’état de réplication d’un objet blob.

Remarque

Bien que la réplication soit en cours, il n’existe aucun moyen de déterminer le pourcentage ou les données répliquées.

Si l’état de réplication d’un blob dans le compte source indique un échec, examinez les causes possibles suivantes :

• Assurez-vous que la stratégie de réplication d’objet est configurée sur le compte de destination.
• Vérifiez que le compte de destination existe toujours.
• Vérifiez que le conteneur de destination existe toujours.
• Vérifiez que le conteneur de destination n’est pas supprimé et n’est pas en cours de suppression. La suppression d’un conteneur peut prendre jusqu’à 30 secondes.
• Vérifiez que le conteneur de destination participe toujours à la stratégie de réplication d’objets.
• Si l’objet blob source est chiffré avec une clé fournie par le client dans le cadre d’une opération d’écriture, la réplication d’objet échoue. Pour plus d’informations sur les clés fournies par le client, consultez Fournir une clé de chiffrement lors d’une requête au stockage d’objets blob.
• Vérifiez si l’objet blob source ou de destination est déplacé vers le niveau archive. Les objets blob archivés ne peuvent pas être répliqués via la réplication d’objets. Pour plus d’informations sur le niveau d’archive, consultez Niveaux d’accès aux données blob.
• Vérifiez que le conteneur de destination ou l’objet blob n’est pas protégé par une stratégie d’immuabilité. N’oubliez pas qu’un conteneur ou un objet blob peut hériter d’une stratégie d’immuabilité de son parent. Pour plus d’informations sur les stratégies d’immuabilité, consultez Vue d’ensemble du stockage immuable pour les données blob.

Prise en charge des fonctionnalités

La prise en charge de cette fonctionnalité peut être impactée par l’activation de Data Lake Storage Gen2, du protocole NFS (Network File System) 3.0 ou du protocole SFTP (SSH File Transfer Protocol). Si vous avez activé l’une de ces fonctionnalités, consultez Prise en charge des fonctionnalités Stockage Blob dans les comptes Stockage Azure pour évaluer la prise en charge de cette fonctionnalité.

Facturation

Il n’y a aucun coût pour configurer la réplication d’objets, notamment la tâche d’activation du flux de modification, l’activation du contrôle de version et l’ajout de stratégies de réplication. Toutefois, la réplication d’objets entraîne des coûts sur les transactions de lecture et d’écriture sur les comptes source et de destination. Les frais de sortie pour la réplication des données du compte source vers le compte de destination entraînent également un coût, tout comme les frais de lecture lors du traitement du flux de modifications.

Vous trouverez ci-dessous une répartition des coûts. Pour connaître le prix de chaque composant de coût, consultez la page Tarifs Stockage Blob Azure.

Coût de la mise à jour d’un objet blob dans le compte source	Coût de la réplication des données dans le compte de destination
Coût de transaction d’une opération d’écriture	Coût de transaction pour la lecture d’un enregistrement de flux de modification
Coût de stockage de l’objet blob et de chaque version d’objet blob1	Coût de transaction pour la lecture de l’objet blob et des versions d’objets blob2
Coût d’ajout d’un enregistrement de flux de modification	Coût de transaction pour l’écriture de l’objet blob et des versions d’objets blob2
Coûts de récupération des données sur les niveaux de stockage cool et froid	Coût de stockage de l’objet blob et de chaque version d’objet blob1
	Coût de la sortie réseau3

¹ Sur le compte source, si le niveau d’un objet blob ou d’une version n’est pas modifié, vous êtes facturé pour des blocs de données uniques sur cet objet blob, ses versions. Consultez Tarifs et facturation du contrôle de version des objets blob. Dans le compte de destination, pour une version, vous êtes facturé pour tous les blocs d’une version, que ces blocs soient uniques ou non.

² Cela inclut uniquement les versions d’objets blob créées depuis la dernière réplication terminée.

³ La réplication d’objets copie l’intégralité de la version vers la destination (pas seulement les blocs uniques de la version). Ce transfert entraîne le coût de sortie du réseau. Consultez les tarifs de la bande passante.

Conseil

Pour réduire le risque d’une facture inattendue, activez la réplication d’objets dans un compte qui contient seulement quelques objets. Ensuite, mesurez l’impact sur les coûts avant d’activer la fonctionnalité dans un paramétrage de production.

Étapes suivantes

• Configurer la réplication d’objets
• Empêcher la réplication d'objets entre les locataires Microsoft Entra
• Contrôle de version des blobs
• Prise en charge du flux de modification dans Stockage Blob Azure