Copy Blob From URL

L’opération Copy Blob From URL copie un objet blob vers une destination dans le compte de stockage de manière synchrone pour les tailles d’objet blob source allant jusqu’à 256 mebioctets (Mio). Cette API est disponible à partir de la version 2018-03-28.

La source d’une Copy Blob From URL opération peut être n’importe quel objet blob de blocs validé dans n’importe quel compte de stockage Azure public ou autorisé avec une signature d’accès partagé.

Requête

Vous pouvez construire la Copy Blob From URL requête comme suit. Nous recommandons HTTPS. Remplacez myaccount par le nom de votre compte de stockage, mycontainer par le nom de votre conteneur et myblob par le nom de votre objet blob de destination.

URI de demande de méthode PUT	Version HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob	HTTP/1.1

URI pour le service de stockage émulé

Lorsque vous effectuez une demande auprès du service de stockage émulé, spécifiez le nom d’hôte de l’émulateur et Stockage Blob Azure port comme 127.0.0.1:10000, suivi du nom du compte de stockage émulé :

URI de demande de méthode PUT	Version HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob	HTTP/1.1

Pour plus d’informations, consultez Utiliser l’émulateur Azurite à des fins de développement local pour Stockage Azure.

Paramètres URI

Vous pouvez spécifier les paramètres supplémentaires suivants dans l’URI de requête :

Paramètre	Description
timeout	facultatif. Le paramètre timeout est exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’expiration pour les opérations de stockage Blob.

En-têtes de requête

Le tableau suivant décrit les en-têtes de requête obligatoires et facultatifs :

En-tête de requête	Description
Authorization	Obligatoire. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
Date ou x-ms-date	Obligatoire. Spécifie la date/heure en temps universel coordonné (UTC) pour la requête. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
x-ms-version	Obligatoire pour toutes les demandes autorisées. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
x-ms-meta-name:value	facultatif. Spécifie une paire nom/valeur définie par l’utilisateur associée à l’objet blob. Si aucune paire nom/valeur n’est spécifiée, l’opération copiera les métadonnées de l’objet blob ou du fichier source vers l’objet blob de destination. Si une ou plusieurs paires nom/valeur sont spécifiées, l’objet blob de destination est créé avec les métadonnées spécifiées et les métadonnées ne sont pas copiées à partir de l’objet blob ou du fichier source. À compter de la version 2009-09-19, les noms de métadonnées doivent respecter les règles de nommage des identificateurs C#. Pour plus d’informations, consultez Nommer et référencer des conteneurs, des objets blob et des métadonnées.
x-ms-encryption-scope	facultatif. Indique l’étendue de chiffrement pour le chiffrement du contenu de la demande. Cet en-tête est pris en charge dans les versions 2020-12-06 et ultérieures.
x-ms-tags	facultatif. Définit des balises encodées par des chaînes de requête sur l’objet blob. Les balises ne sont pas copiées à partir de la source de copie. Pour plus d’informations, consultez Remarques. Pris en charge dans les versions 2019-12-12 et ultérieures.
x-ms-copy-source-tag-option	facultatif. Les valeurs possibles sont REPLACE et COPY (respectant la casse). La valeur par défaut est REPLACE. Si COPY est spécifié, les balises de l’objet blob source seront copiées dans l’objet blob de destination. L’objet blob source doit être privé et la demande doit avoir l’autorisation d’accéder à l’opération Get Blob Tags sur l’objet blob source et à l’opération Définir des balises blob sur l’objet blob de destination. Cela entraîne un appel supplémentaire à l’opération Get Blob Tags sur le compte source. REPLACE définit les balises que l’en-tête x-ms-tags spécifie sur l’objet blob de destination. Si x-ms-tags spécifie REPLACE et aucune balise, aucune balise n’est définie sur l’objet blob de destination. La spécification COPY et x-ms-tags entraîne une erreur 409 (conflit). Pris en charge dans les versions 2021-04-10 et ultérieures.
x-ms-source-if-modified-since	facultatif. Valeur DateTime. Spécifiez cet en-tête conditionnel pour copier l'objet blob uniquement si l'objet blob source a été modifié depuis la date/l'heure indiquées. Si l’objet blob source n’a pas été modifié, Stockage Blob retourne status code 412 (Échec de la condition préalable). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure.
x-ms-source-if-unmodified-since	facultatif. Valeur DateTime. Spécifiez cet en-tête conditionnel pour copier l'objet blob uniquement si l'objet blob source n'a pas été modifié depuis la date/l'heure indiquées. Si l’objet blob source a été modifié, Stockage Blob retourne status code 412 (Échec de la condition préalable). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure.
x-ms-source-if-match	facultatif. Valeur ETag. Spécifiez cet en-tête conditionnel pour copier l’objet blob source uniquement si sa ETag valeur correspond à la valeur spécifiée. Si les valeurs ne correspondent pas, Stockage Blob retourne status code 412 (Échec de la condition préalable). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure.
x-ms-source-if-none-match	facultatif. Valeur ETag. Spécifiez cet en-tête conditionnel pour copier l’objet blob uniquement si sa ETag valeur ne correspond pas à la valeur spécifiée. Si les valeurs sont identiques, Stockage Blob retourne status code 412 (Échec de la condition préalable). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure.
If-Modified-Since	facultatif. Valeur DateTime. Spécifiez cet en-tête conditionnel pour copier l'objet blob uniquement si l'objet blob de destination a été modifié depuis la date/l'heure indiquées. Si l’objet blob de destination n’a pas été modifié, Stockage Blob retourne status code 412 (Échec de la condition préalable).
If-Unmodified-Since	facultatif. Valeur DateTime. Spécifiez cet en-tête conditionnel pour copier l'objet blob uniquement si l'objet blob de destination n'a pas été modifié depuis la date/l'heure indiquées. Si l’objet blob de destination a été modifié, Stockage Blob retourne status code 412 (Échec de la condition préalable).
If-Match	facultatif. Valeur ETag. Spécifiez une ETag valeur pour cet en-tête conditionnel pour copier l’objet blob uniquement si la valeur spécifiée ETag correspond à la ETag valeur d’un objet blob de destination existant. Si les valeurs ne correspondent pas, Stockage Blob retourne status code 412 (Échec de la condition préalable).
If-None-Match	facultatif. Valeur ETag ou caractère générique (*). Spécifiez une ETag valeur pour cet en-tête conditionnel pour copier l’objet blob uniquement si la valeur spécifiée ETag ne correspond pas à la ETag valeur de l’objet blob de destination. Spécifiez le caractère générique (*) pour effectuer l’opération uniquement si l’objet blob de destination n’existe pas. Si la condition spécifiée n’est pas remplie, le Stockage Blob retourne status code 412 (Échec de la condition préalable).
x-ms-copy-source:name	Obligatoire. Spécifie l’URL de l’objet blob source. La valeur peut être une URL d’une longueur maximale de 2 Kibioctets (Kio) qui spécifie un objet blob. La valeur doit être encodée sous forme d'URL, comme dans une URI de demande. L’objet blob source doit être public ou autorisé via une signature d’accès partagé. Si l’objet blob source est public, aucune autorisation n’est requise pour effectuer l’opération. Si la taille de l’objet blob source est supérieure à 256 Mio, la requête échoue avec une erreur 409 (Conflit). Le type d’objet blob de l’objet blob source doit être l’objet blob de blocs. Voici quelques exemples d’URL d’objet source : - https://myaccount.blob.core.windows.net/mycontainer/myblob - https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime> - https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>
x-ms-copy-source-authorization: <scheme> <signature>	facultatif. Spécifie le schéma d’autorisation et la signature pour la source de copie. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure. Seul le porteur de schéma est pris en charge pour Azure Active Directory. Cet en-tête est pris en charge dans la version 2020-10-02 et ultérieure.
x-ms-requires-sync:true	Obligatoire. Indique qu’il s’agit d’une opération synchrone Copy Blob From URL au lieu d’une opération asynchrone Copy Blob .
x-ms-source-content-md5	facultatif. Spécifie un hachage MD5 du contenu de l’objet blob à partir de l’URI. Ce hachage est utilisé pour vérifier l’intégrité de l’objet blob pendant le transport des données à partir de l’URI. Lorsque cet en-tête est spécifié, le service de stockage compare le hachage du contenu qui est arrivé de la source de copie avec cette valeur d’en-tête. Le hachage MD5 n’est pas stocké avec l’objet blob. Si les deux hachages ne correspondent pas, l'opération échoue avec le code d'erreur 400 (Demande incorrecte).
x-ms-lease-id:<ID>	Obligatoire si l'objet blob de destination a un bail actif. L'ID de bail spécifié pour cet en-tête doit correspondre à l'ID de bail de l'objet blob de destination. Si la demande n’inclut pas l’ID de bail ou s’il n’est pas valide, l’opération échoue avec status code 412 (échec de la condition préalable). Si cet en-tête est spécifié et que l’objet blob de destination n’a pas de bail actif, l’opération échoue avec status code 412 (échec de la condition préalable). Dans les versions 2012-02-12 et ultérieures, cette valeur doit spécifier un bail actif et infini pour un objet blob loué. Un ID de bail à durée finie échoue avec status code 412 (échec de la condition préalable).
x-ms-client-request-id	facultatif. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 Kio enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes que le serveur reçoit.
x-ms-access-tier	facultatif. Spécifie le niveau à définir sur l’objet blob cible. Cet en-tête est destiné aux objets blob de pages sur un compte Premium uniquement avec la version 2017-04-17 et les versions ultérieures. Pour obtenir la liste complète des niveaux pris en charge, consultez Stockage Premium hautes performances et disques managés pour machines virtuelles. Cet en-tête est pris en charge sur la version 2018-11-09 et ultérieure pour les objets blob de blocs. La hiérarchisation d’objets blob de blocs est prise en charge sur les comptes Stockage Blob ou usage général v2. Les valeurs valides sont Hot, Cool, Cold et Archive. Note:Cold le niveau est pris en charge pour la version 2021-12-02 et ultérieure. Pour plus d’informations sur la hiérarchisation des objets blob de blocs, consultez Niveaux de stockage chaud, froid et archive.

Corps de la demande

Aucun.

response

La réponse inclut un code d'état HTTP et un ensemble d'en-têtes de réponse.

Code d’état

Une opération réussie renvoie le code d'état 202 (Accepté).

Pour plus d’informations sur les codes status, consultez Codes d’état et d’erreur.

En-têtes de réponse

La réponse de l'opération inclut les en-têtes suivants. La réponse peut également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

En-tête de réponse	Description
ETag	Si la copie est terminée, contient la ETag valeur de l’objet blob de destination. Si la copie n’est pas terminée, contient la ETag valeur de l’objet blob vide créé au début de la copie. La ETag valeur est entre guillemets.
Last-Modified	Retourne la date/heure de fin de l’opération de copie dans l’objet blob de destination.
x-ms-request-id	Identifie de manière unique la demande qui a été effectuée. Vous pouvez l’utiliser pour résoudre les problèmes liés à la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API.
x-ms-version	Indique la version de Stockage Blob utilisée pour exécuter la requête.
Date	Valeur de date/heure UTC qui indique l’heure à laquelle le service a envoyé la réponse.
x-ms-copy-id: <id>	Identificateur de chaîne pour cette opération de copie.
x-ms-copy-status: <success>	Indique l’état de l’opération de copie. La valeur de success signifie que l’opération s’est terminée avec succès.
x-ms-client-request-id	Peut être utilisé pour résoudre les problèmes liés aux demandes et aux réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête x-ms-client-request-id , si elle est présente dans la requête et que la valeur est au maximum de 1 024 caractères ASCII visibles. Si l’en-tête x-ms-client-request-id n’est pas présent dans la demande, cet en-tête ne sera pas présent dans la réponse.
x-ms-request-server-encrypted: true/false	Définissez sur true si le contenu de la requête est correctement chiffré via l’algorithme spécifié. Sinon, la valeur est false.
x-ms-encryption-scope	Retourné si la demande a utilisé une étendue de chiffrement, afin que le client puisse s’assurer que le contenu de la demande est correctement chiffré via l’étendue de chiffrement.

Response body

Aucun.

Exemple de réponse

Voici un exemple de réponse pour une demande de copie d'un objet blob :

Response Status:  
HTTP/1.1 202 Accepted  
  
Response Headers:   
Last-Modified: <date>   
ETag: "0x8CEB669D794AFE2"  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402  
x-ms-version: 2018-03-28  
x-ms-copy-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-copy-status: success  
Date: <date>  
  

Autorisation

Une autorisation est requise lors de l’appel d’une opération d’accès aux données dans stockage Azure. Le tableau suivant décrit comment les objets de destination et source d’une Copy Blob From URL opération peuvent être autorisés :

Type d’objet	autorisation Microsoft Entra ID	Autorisation signature d’accès partagé (SAP)	Autorisation de clé partagée (ou Shared Key Lite)
Objet blob de blocs de destination	Oui	Oui	Oui
Objet blob de blocs source dans le même compte de stockage	Oui	Oui	Oui
Objet blob de blocs source dans un autre compte de stockage	Non	Oui	Non

Si une demande spécifie des balises dans l’en-tête x-ms-tags de la demande, l’appelant doit répondre aux exigences d’autorisation de l’opération Définir des balises blob .

Vous pouvez autoriser l’opération Copy Blob From URL comme décrit ci-dessous. Notez qu’un objet blob source dans un autre compte de stockage doit être autorisé séparément via le jeton SAS avec l’autorisation Lecture (r). Pour plus d’informations sur l’autorisation d’objet blob source, consultez les détails de l’en-tête x-ms-copy-sourcede requête .

Microsoft Entra ID

Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les demandes de données blob. Avec Microsoft Entra ID, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée Azure. Le principal de sécurité est authentifié par Microsoft Entra ID pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une requête auprès du service BLOB.

Pour en savoir plus sur l’autorisation à l’aide de Microsoft Entra ID, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID.

Autorisations

Vous trouverez ci-dessous l’action RBAC nécessaire pour qu’un utilisateur, un groupe ou un principal de service Microsoft Entra appelle l’opérationCopy Blob From URL, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

Objet blob de destination

• Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (pour l’écriture dans un objet blob existant) ou Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (pour écrire un nouvel objet blob dans la destination)
• Rôle intégré le moins privilégié :Contributeur aux données blob de stockage

Objet blob source dans le même compte de stockage

• Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
• Rôle intégré le moins privilégié :Lecteur de données blob de stockage

Pour en savoir plus sur l’attribution de rôles à l’aide d’Azure RBAC, consultez Attribuer un rôle Azure pour l’accès aux données d’objets blob.

Signatures d’accès partagé (SAP)

Une signature d’accès partagé (SAP) fournit un accès délégué sécurisé aux ressources d’un compte de stockage. Avec une SAP, vous disposez d’un contrôle granulaire sur la façon dont un client peut accéder aux données. Vous pouvez spécifier la ressource à laquelle le client peut accéder, les autorisations dont il dispose sur ces ressources et la durée de validité de la SAP.

L’opération Copy Blob From URL prend en charge trois types de signatures d’accès partagé : sas de délégation d’utilisateur, SAP de service et SAP de compte.

Comme meilleure pratique de sécurité, nous vous recommandons d’utiliser Microsoft Entra informations d’identification plutôt que la clé de compte de stockage, qui peut être plus facilement compromise. Si la conception de votre application nécessite des signatures d’accès partagé, utilisez Microsoft Entra informations d’identification pour créer une sap de délégation d’utilisateur, si possible.

Lorsque l’accès à la clé partagée est interdit pour le compte de stockage, un jeton SAP de service ou un jeton SAP de compte ne sont pas autorisés lors d’une demande adressée au stockage Blob. Pour plus d’informations, consultez Comprendre comment l’interdiction de la clé partagée affecte les jetons SAP.

SAP de délégation d’utilisateur

Une sap de délégation d’utilisateur est sécurisée avec des informations d’identification Microsoft Entra ainsi que par les autorisations spécifiées pour la sap.

L’appel de l’opération à l’aide Copy Blob From URL d’un jeton SAP délégué à une ressource d’objet blob nécessite l’autorisation suivante dans le cadre du jeton SAP de délégation utilisateur.

Opération	Type d’objet	Autorisation signée
Copy Blob From URL	Objet blob de destination (nouveau)	Créer (c) ou Écrire (w)
Copy Blob From URL	Objet blob de destination (existant)	Écriture (w)
Copy Blob From URL	Objet blob source (dans le même compte de stockage)	Lecture (r)
Copy Blob From URL	Objet blob source (dans un compte de stockage différent)	Lecture (r)

Pour en savoir plus sur la sap de délégation d’utilisateur, consultez Créer une sap de délégation d’utilisateur.

SAP de service

Une SAP de service est sécurisée à l’aide de la clé de compte de stockage. Une sap de service délègue l’accès à une ressource dans un seul service Stockage Azure, tel que le stockage blob.

L’appel de l’opération à l’aide Copy Blob From URL d’un jeton SAP délégué à une ressource d’objet blob nécessite l’autorisation suivante dans le cadre du jeton SAP de service.

Opération	Type d’objet	Autorisation signée
Copy Blob From URL	Objet blob de destination (nouveau)	Créer (c) ou Écrire (w)
Copy Blob From URL	Objet blob de destination (existant)	Écriture (w)
Copy Blob From URL	Objet blob source (dans le même compte de stockage)	Lecture (r)
Copy Blob From URL	Objet blob source (dans un compte de stockage différent)	Lecture (r)

Pour en savoir plus sur la SAP de service, consultez Créer une SAP de service.

SAP de compte

Une SAP de compte est sécurisée à l’aide de la clé de compte de stockage. Une SAP de compte délègue l’accès aux ressources d’un ou plusieurs des services de stockage. Toutes les opérations disponibles via une SAP de service ou de délégation d’utilisateur sont également disponibles via une SAP de compte.

Le tableau suivant indique le type de ressource signé et les autorisations signées à spécifier lors de la délégation de l’accès :

Opération	Type d’objet	Service signé	Type de ressource signé	Autorisation signée
Copy Blob From URL	Objet blob de destination (nouveau)	Objet blob (b)	Objet (o)	Créer (c) ou Écrire (w)
Copy Blob From URL	Objet blob de destination (existant)	Objet blob (b)	Objet (o)	Écriture (w)
Copy Blob From URL	Objet blob source (dans le même compte de stockage)	Objet blob (b)	Objet (o)	Lecture (r)
Copy Blob From URL	Objet blob source (dans un compte de stockage différent)	Objet blob (b)	Objet (o)	Lecture (r)

Pour en savoir plus sur la SAP de compte, consultez Créer une SAP de compte.

Clé partagée

L’opération Copy Blob From URL prend en charge l’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée dans la plupart des scénarios, car elle est moins sécurisée.

Microsoft recommande d’interdire l’autorisation de clé partagée pour le compte de stockage lorsque cela est possible. Pour plus d’informations, consultez Empêcher l’autorisation avec une clé partagée.

Remarques

L’objet blob source et de destination d’une Copy Blob From URL opération doit être un objet blob de blocs.

Dans les versions 2020-10-02 et ultérieures, l’autorisation Azure Active Directory est prise en charge pour la source de l’opération de copie.

L’opération Copy Blob From URL copie toujours l’intégralité du blob source. La copie d’une plage d’octets ou d’un ensemble de blocs n’est pas prise en charge.

Vous pouvez copier un objet blob source dans un objet blob de destination qui a un autre nom. L’objet blob de destination peut être un objet blob de blocs existant ou un nouvel objet blob créé par l’opération de copie.

Lorsque vous copiez à partir d’un objet blob de blocs, tous les blocs validés et leurs ID de blocs sont copiés. Les blocs non validés ne sont pas copiés. À la fin de l’opération de copie, l’objet blob de destination aura le même nombre de blocs validés que la source.

La ETag valeur d’un objet blob de blocs change au démarrage de l’opération Copy Blob From URL et à la fin de l’opération.

Copie des propriétés et des métadonnées d’objets blob

Lorsqu’un objet blob de blocs est copié, les propriétés système suivantes sont copiées dans l’objet blob de destination avec les mêmes valeurs :

• Content-Type

• Content-Encoding

• Content-Language

• Content-Length

• Cache-Control

• Content-MD5

• Content-Disposition

La liste de blocs validée de l’objet blob source est également copiée dans l’objet blob de destination. Les blocs non validés ne sont pas copiés.

L’objet blob de destination a toujours la même taille que l’objet blob source, de sorte que la valeur de l’en-tête Content-Length de l’objet blob de destination correspond à la valeur de cet en-tête pour l’objet blob source.

Si l’en-tête x-ms-tags fournit des balises pour l’objet blob de destination, elles doivent être encodées par chaîne de requête. Les clés et les valeurs de balise doivent être conformes aux exigences de nommage et de longueur spécifiées dans l’opération Définir les balises d’objets blob .

L’en-tête x-ms-tags peut contenir jusqu’à 2 kilobits de balises. Si vous avez besoin d’autres balises, utilisez l’opération Set Blob Tags .

Si l’en-tête x-ms-tags ne fournit pas d’étiquettes, les balises ne sont pas copiées à partir de l’objet blob source.

Copie d’un objet blob loué

L’opération Copy Blob From URL lit uniquement à partir de l’objet blob source, de sorte que l’état de bail de l’objet blob source n’a pas d’importance.

Facturation

Les demandes de tarification peuvent provenir de clients qui utilisent des API Stockage Blob, soit directement via l’API REST Stockage Blob, soit à partir d’une bibliothèque cliente stockage Azure. Ces demandes cumulent des frais par transaction. Le type de transaction affecte la façon dont le compte est facturé. Par exemple, les transactions de lecture sont comptabilisées dans une catégorie de facturation différente de celle des transactions en écriture. Le tableau suivant montre la catégorie de facturation pour Copy Blob From URL les demandes en fonction du type de compte de stockage :

Opération	Type de compte de stockage	Catégorie de facturation
Copier un objet blob à partir de l’URL (comptede destination 1)	Objet blob de blocs Premium Usage général v2 Standard Usage général v1 standard	Opérations d’écriture
Copier un objet blob à partir de l’URL (compte source2)	Objet blob de blocs Premium Usage général v2 Standard Usage général v1 standard	Lire les opérations

¹Le compte de destination est facturé pour une transaction pour lancer l’écriture.
²Le compte source entraîne une transaction pour chaque demande de lecture à l’objet source.

Pour en savoir plus sur la tarification pour les catégories de facturation spécifiées, consultez Stockage Blob Azure Tarification.

En outre, si les comptes source et de destination résident dans différentes régions (par exemple, USA Nord et USA Sud), la bande passante que vous utilisez pour transférer la demande est facturée au compte de stockage source en sortie. Les sorties entre les comptes au sein de la même région sont gratuits.

Lorsque vous copiez un objet blob source vers un objet blob de destination portant un nom différent dans le même compte, vous utilisez des ressources de stockage supplémentaires pour le nouvel objet blob. L’opération de copie entraîne ensuite des frais sur l’utilisation de la capacité du compte de stockage pour ces ressources supplémentaires.

Voir aussi

Autoriser les demandes à Stockage Azure
Codes d’état et d’erreur
Codes d’erreur Stockage Blob
Présentation de la façon dont les instantanés cumulent des frais