Copiar blob de la dirección URL

2025-05-11

La Copy Blob From URL operación copia un blob en un destino dentro de la cuenta de almacenamiento de forma sincrónica para tamaños de blob de origen de hasta 256 mebibytes (MiB). Esta API está disponible a partir de la versión 2018-03-28.

El origen de una Copy Blob From URL operación puede ser cualquier blob en bloques confirmado de cualquier cuenta de almacenamiento de Azure que sea pública o autorizada con una firma de acceso compartido.

Solicitud

Puede construir la solicitud Copy Blob From URL de la siguiente manera. Se recomienda HTTPS. Reemplace myaccount por el nombre de la cuenta de almacenamiento, mycontainer por el nombre del contenedor y myblob por el nombre del blob de destino.

URI de solicitud de método PUT	Versión HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob`	HTTP/1.1

URI para el servicio de almacenamiento emulado

Al realizar una solicitud en el servicio de almacenamiento emulado, especifique el nombre de host del emulador y el puerto de Azure Blob Storage como 127.0.0.1:10000, seguido del nombre de la cuenta de almacenamiento emulada:

URI de solicitud de método PUT	Versión HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob`	HTTP/1.1

Para más información, consulte Uso del emulador de Azurite para el desarrollo local de Azure Storage.

Parámetros de URI

Puede especificar los siguientes parámetros adicionales en el URI de solicitud:

Parámetro	Descripción
`timeout`	Opcional. El parámetro `timeout` se expresa en segundos. Para obtener más información, consulte Establecer tiempos de espera para operaciones de Blob Storage.

Cabeceras de solicitud

En la tabla siguiente se describen los encabezados de solicitud obligatorios y opcionales:

Cabecera de solicitud	Descripción
`Authorization`	Obligatorio. Especifica el esquema de autorización, el nombre de la cuenta y la firma. Para más información, consulte Autorizar solicitudes a Azure Storage.
`Date` o `x-ms-date`	Obligatorio. Especifica la hora universal coordinada (UTC) de la solicitud. Para más información, consulte Autorizar solicitudes a Azure Storage.
`x-ms-version`	Necesario para todas las solicitudes autorizadas. Para más información, consulte Control de versiones de para los servicios de Azure Storage.
`x-ms-meta-name:value`	Opcional. Especifica un par nombre-valor definido por el usuario asociado al blob. Si no se especifica ningún par nombre-valor, la operación copiará los metadatos del blob o archivo de origen en el blob de destino. Si se especifican uno o varios pares nombre-valor, el blob de destino se crea con los metadatos especificados y los metadatos no se copian del blob o archivo de origen. A partir de la versión 2009-09-19, los nombres de metadatos deben cumplir las reglas de nomenclatura para los identificadores de C#. Para obtener más información, consulte Nomenclatura y referencia a contenedores, blobs y metadatos.
`x-ms-encryption-scope`	Opcional. Indica el ámbito de cifrado para cifrar el contenido de la solicitud. Este encabezado es compatible con la versión 2020-12-06 y posteriores.
`x-ms-tags`	Opcional. Establece etiquetas codificadas en cadena de consulta en el blob. Las etiquetas no se copian del origen de copia. Para obtener más información, vea Comentarios. Compatible con la versión 2019-12-12 y posteriores.
`x-ms-copy-source-tag-option`	Opcional. Los valores posibles son `REPLACE` y (distingue entre mayúsculas y `COPY` minúsculas). El valor predeterminado es `REPLACE`. Si `COPY` se especifica, las etiquetas del blob de origen se copiarán en el blob de destino. El blob de origen debe ser privado y la solicitud debe tener permiso para la operación Get Blob Tags en el blob de origen y la operación Set Blob Tags en el blob de destino. Esto incurre en una llamada adicional a la `Get Blob Tags` operación en la cuenta de origen. `REPLACE` establecerá las etiquetas que el `x-ms-tags` encabezado especifica en el blob de destino. Si `x-ms-tags` especifica `REPLACE` y no hay etiquetas, no se establecerá ninguna etiqueta en el blob de destino. Especificando `COPY` y `x-ms-tags` dará como resultado un error 409 (Conflicto). Compatible con la versión 2021-04-10 y posteriores.
`x-ms-source-if-modified-since`	Opcional. Valor de `DateTime`. Especifique este encabezado condicional para copiar el blob solo si el blob de origen se ha modificado desde la fecha y hora especificadas. Si el blob de origen no se ha modificado, Blob Storage devuelve el código de estado 412 (error de condición previa). No se puede especificar este encabezado si el origen es un archivo de Azure.
`x-ms-source-if-unmodified-since`	Opcional. Valor de `DateTime`. Especifique este encabezado condicional para copiar el blob solo si el blob de origen no se ha modificado desde la fecha y hora especificadas. Si se ha modificado el blob de origen, Blob Storage devuelve el código de estado 412 (error de condición previa). No se puede especificar este encabezado si el origen es un archivo de Azure.
`x-ms-source-if-match`	Opcional. Valor `ETag`. Especifique este encabezado condicional para copiar el blob de origen solo si su `ETag` valor coincide con el valor especificado. Si los valores no coinciden, Blob Storage devuelve el código de estado 412 (error de condición previa). No se puede especificar este encabezado si el origen es un archivo de Azure.
`x-ms-source-if-none-match`	Opcional. Valor `ETag`. Especifique este encabezado condicional para copiar el blob solo si su `ETag` valor no coincide con el valor especificado. Si los valores son idénticos, Blob Storage devuelve el código de estado 412 (error de condición previa). No se puede especificar este encabezado si el origen es un archivo de Azure.
`If-Modified-Since`	Opcional. Valor de `DateTime`. Especifique este encabezado condicional para copiar el blob solo si el blob de destino se ha modificado desde la fecha y hora especificadas. Si el blob de destino no se ha modificado, Blob Storage devuelve el código de estado 412 (error de condición previa).
`If-Unmodified-Since`	Opcional. Valor de `DateTime`. Especifique este encabezado condicional para copiar el blob solo si el blob de destino no se ha modificado desde la fecha y hora especificadas. Si se ha modificado el blob de destino, Blob Storage devuelve el código de estado 412 (error de condición previa).
`If-Match`	Opcional. Valor `ETag`. Especifique un `ETag` valor para este encabezado condicional para copiar el blob solo si el valor especificado `ETag` coincide con el valor de `ETag` un blob de destino existente. Si los valores no coinciden, Blob Storage devuelve el código de estado 412 (error de condición previa).
`If-None-Match`	Opcional. Un `ETag` valor o el carácter comodín (). Especifique un `ETag` valor para este encabezado condicional para copiar el blob solo si el valor especificado `ETag` no coincide con el `ETag` valor del blob de destino. Especifique el carácter comodín () para realizar la operación solo si el blob de destino no existe. Si no se cumple la condición especificada, Blob Storage devuelve el código de estado 412 (error de condición previa).
`x-ms-copy-source:name`	Obligatorio. Especifica la dirección URL del blob de origen. El valor puede ser una dirección URL de hasta 2 kibibytes (KiB) de longitud que especifique un blob. El valor debe estar codificado con dirección URL, ya que aparecería en un URI de solicitud. El blob de origen debe ser público o estar autorizado a través de una firma de acceso compartido. Si el blob de origen es público, no se requiere ninguna autorización para realizar la operación. Si el tamaño del blob de origen es superior a 256 MiB, se produce un error 409 (conflicto) en la solicitud. El tipo de blob del blob de origen debe ser blob en bloques. Estos son algunos ejemplos de direcciones URL de objeto de origen: - `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>`	Opcional. Especifica el esquema de autorización y la firma del origen de copia. Para más información, consulte Autorizar solicitudes a Azure Storage. Solo se admite el portador del esquema para Microsoft Entra. Este encabezado se admite en la versión 2020-10-02 y posteriores.
`x-ms-requires-sync:true`	Obligatorio. Indica que se trata de una operación sincrónica `Copy Blob From URL` en lugar de una operación asincrónica `Copy Blob` .
`x-ms-source-content-md5`	Opcional. Especifica un hash MD5 del contenido del blob desde el URI. Este hash se usa para comprobar la integridad del blob durante el transporte de los datos desde el URI. Cuando se especifica este encabezado, el servicio de almacenamiento compara el hash del contenido que ha llegado del origen de copia con este valor de encabezado. El hash MD5 no se almacena con el blob. Si los dos hash no coinciden, se produce un error en la operación con el código de error 400 (solicitud incorrecta).
`x-ms-lease-id:<ID>`	Obligatorio si el blob de destino tiene una concesión activa. El identificador de concesión especificado para este encabezado debe coincidir con el identificador de concesión del blob de destino. Si la solicitud no incluye el identificador de concesión o no es válido, se produce un error en la operación con el código de estado 412 (error de condición previa). Si se especifica este encabezado y el blob de destino no tiene actualmente una concesión activa, se produce un error en la operación con el código de estado 412 (error de condición previa). En la versión 2012-02-12 y posteriores, este valor debe especificar una concesión activa e infinita para un blob arrendado. Se produce un error en un ID de concesión de duración finita con el código de estado 412 (error de condición previa).
`x-ms-client-request-id`	Opcional. Proporciona un valor opaco generado por el cliente con un límite de caracteres de 1 KiB que se registra en los registros cuando se configura el registro. Se recomienda encarecidamente usar este encabezado para correlacionar las actividades del lado cliente con las solicitudes que recibe el servidor.
`x-ms-access-tier`	Opcional. Especifica el nivel que se va a establecer en el blob de destino. Este encabezado es para blobs en páginas en una cuenta premium solo con la versión 2017-04-17 y posteriores. Para obtener una lista completa de los niveles admitidos, consulte Almacenamiento premium de alto rendimiento y discos administrados para máquinas virtuales. Este encabezado se admite en la versión 2018-11-09 y posteriores para blobs en bloques. La organización en niveles de blobs en bloques se admite en cuentas de Blob Storage o de uso general v2. Los valores válidos son `Hot`, `Cool`, `Cold`y `Archive`. Nota:`Cold` nivel es compatible con la versión 2021-12-02 y posteriores. Para obtener información detallada sobre la organización en niveles de blobs en bloques, consulte Niveles de almacenamiento frecuente, esporádico y de archivo.
`x-ms-file-request-intent`	Obligatorio si `x-ms-copy-source` el encabezado es una dirección URL de archivo de Azure y `x-ms-copy-source-authorization` el encabezado especifica un token de OAuth. El valor aceptable es `backup`. Este encabezado especifica que se debe conceder el `Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action` o `Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action` si se incluyen en la directiva de RBAC asignada a la identidad autorizada mediante el encabezado `x-ms-copy-source-authorization`. Disponible para la versión 2025-07-05 y posteriores.

Cuerpo de la solicitud

Ninguno.

Respuesta

La respuesta incluye un código de estado HTTP y un conjunto de encabezados de respuesta.

Código de estado

Una operación correcta devuelve el código de estado 202 (aceptado).

Para obtener información sobre los códigos de estado, vea Códigos de estado y de error.

Encabezados de respuesta

La respuesta de esta operación incluye los siguientes encabezados. La respuesta también puede incluir encabezados HTTP estándar adicionales. Todos los encabezados estándar se ajustan a la especificación del protocolo HTTP/1.1 de .

Encabezado de respuesta	Descripción
`ETag`	Si la copia está completa, contiene el `ETag` valor del blob de destino. Si la copia no está completa, contiene el `ETag` valor del blob vacío creado al principio de la copia. El `ETag` valor está entre comillas.
`Last-Modified`	Devuelve la fecha y hora en que finalizó la operación de copia en el blob de destino.
`x-ms-request-id`	Identifica de forma única la solicitud que se realizó. Puede usarlo para solucionar problemas de la solicitud. Para obtener más información, consulte Solución de problemas de operaciones de API.
`x-ms-version`	Indica la versión de Blob Storage que se usa para ejecutar la solicitud.
`Date`	Valor de fecha y hora UTC que indica la hora a la que el servicio envió la respuesta.
`x-ms-copy-id: <id>`	Identificador de cadena para esta operación de copia.
`x-ms-copy-status: <success>`	Indica el estado de la operación de copia. Un valor de `success` significa que la operación finalizó correctamente.
`x-ms-client-request-id`	Se puede usar para solucionar problemas de solicitudes y respuestas correspondientes. El valor de este encabezado es igual al valor del encabezado `x-ms-client-request-id`, si está presente en la solicitud y el valor es como máximo 1024 caracteres ASCII visibles. Si el encabezado `x-ms-client-request-id` no está presente en la solicitud, este encabezado no estará presente en la respuesta.
`x-ms-request-server-encrypted: true/false`	Establézcalo si `true` el contenido de la solicitud se cifra correctamente a través del algoritmo especificado. De lo contrario, el valor es `false`.
`x-ms-encryption-scope`	Se devuelve si la solicitud usó un ámbito de cifrado, para que el cliente pueda asegurarse de que el contenido de la solicitud se cifra correctamente a través del ámbito de cifrado.

Cuerpo de respuesta

Ninguno.

Respuesta de ejemplo

A continuación se muestra un ejemplo de respuesta para una solicitud de copia de un 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>

Autorización

Se requiere autorización al llamar a cualquier operación de acceso a datos en Azure Storage. En la tabla siguiente se describe cómo se pueden autorizar los objetos de destino y de origen de una operación de Copy Blob From URL:

Tipo de objeto	Autorización de ID de Microsoft Entra	Autorización de firma de acceso compartido (SAS)	Autorización de clave compartida (o clave compartida lite)
Blob en bloques de destino	Sí	Sí	Sí
Blob en bloques de origen en la misma cuenta de almacenamiento	Sí	Sí	Sí
Blob en bloques de origen en otra cuenta de almacenamiento	No	Sí	No

Si una solicitud especifica etiquetas en el encabezado de la x-ms-tags solicitud, el autor de la llamada debe cumplir los requisitos de autorización de la operación Set Blob Tags .

Puede autorizar la operación de Copy Blob From URL como se describe a continuación. Tenga en cuenta que un blob en origen de una cuenta de almacenamiento diferente debe autorizarse por separado a través de un token de SAS con el permiso de lectura (r). Para obtener más información sobre la autorización de blobs en el origen, consulte los detalles del encabezado x-ms-copy-sourcede solicitud .

Importante

Microsoft recomienda usar el identificador de Entra de Microsoft con identidades administradas para autorizar solicitudes a Azure Storage. Microsoft Entra ID proporciona seguridad y facilidad de uso superiores en comparación con la autorización de clave compartida.

Microsoft Entra ID (recomendado)
firmas de acceso compartido (SAS)
clave compartida

Azure Storage admite el uso de Microsoft Entra ID para autorizar solicitudes a datos de blobs. Con microsoft Entra ID, puede usar el control de acceso basado en rol de Azure (RBAC de Azure) para conceder permisos a una entidad de seguridad. La entidad de seguridad puede ser un usuario, un grupo, una entidad de servicio de aplicación o una identidad administrada de Azure. Microsoft Entra ID autentica la entidad de seguridad para devolver un token de OAuth 2.0. Después, el token se puede usar para autorizar una solicitud en Blob service.

Para obtener más información sobre la autorización mediante el identificador de Entra de Microsoft, consulte Autorizar el acceso a blobs mediante el identificador de Microsoft Entra.

Permisos

A continuación se enumeran las acciones de RBAC necesarias para que un usuario, grupo, identidad administrada o entidad de servicio de Microsoft Entra llame a la operación de Copy Blob From URL y el rol RBAC integrado con privilegios mínimos que incluye esta acción:

Blob de destino

Acción de RBAC de Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (para escribir en un blob existente) o Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (para escribir un nuevo blob en el destino)
rol integrado con privilegios mínimos:colaborador de datos de Blob storage

Blob de origen dentro de la misma cuenta de almacenamiento

Acción de RBAC de Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Rol integrado con privilegios mínimos:Lector de datos de blob de almacenamiento

Para más información sobre cómo asignar roles mediante Azure RBAC, consulte Asignación de un rol de Azure para el acceso a datos de blobs.

Una firma de acceso compartido (SAS) proporciona acceso delegado seguro a los recursos de una cuenta de almacenamiento. Con una SAS, tiene un control pormenorizado sobre cómo un cliente puede acceder a los datos. Puede especificar a qué recurso puede tener acceso el cliente, a qué permisos tienen esos recursos y cuánto tiempo es válido la SAS.

La operación de admite tres tipos de firmas de acceso compartido: SAS de delegación de usuarios, saS de servicio y saS de cuenta de.

Como procedimiento recomendado de seguridad, se recomienda usar credenciales de Microsoft Entra en lugar de la clave de la cuenta de almacenamiento, que se puede poner en peligro con mayor facilidad. Si el diseño de la aplicación requiere firmas de acceso compartido, use las credenciales de Microsoft Entra para crear una SAS de delegación de usuarios, siempre que sea posible.

Cuando no se permite el acceso a la clave compartida para la cuenta de almacenamiento, no se permitirá un token de SAS de servicio o un token de SAS de cuenta en una solicitud a Blob Storage. Para obtener más información, consulte Descripción de cómo no permitir la clave compartida afecta a los tokens de SAS.

SAS de delegación de usuarios

Una SAS de delegación de usuarios está protegida con las credenciales de Microsoft Entra y también por los permisos especificados para la SAS.

Para llamar a la Copy Blob From URL operación mediante un token de SAS delegado a un recurso de blob, se requiere el siguiente permiso como parte del token de SAS de delegación de usuarios.

Operación	Tipo de objeto	Permiso firmado
Copiar blob de la dirección URL	Blob de destino (nuevo)	Crear (c) o Escribir (w)
Copiar blob de la dirección URL	Blob de destino (existente)	Escritura (w)
Copiar blob de la dirección URL	Blob en origen (dentro de la misma cuenta de almacenamiento)	Leer (r)
Copiar blob de la dirección URL	Blob de origen (en una cuenta de almacenamiento diferente)	Leer (r)

Para obtener más información sobre la SAS de delegación de usuarios, consulte Creación de una SAS de delegación de usuarios.

SAS de servicio

Una SAS de servicio está protegida con la clave de cuenta de almacenamiento. Una SAS de servicio delega el acceso a un recurso en un único servicio de Azure Storage, como Blob Storage.

Para llamar a la Copy Blob From URL operación mediante un token de SAS delegado en un recurso de blob, se requiere el siguiente permiso como parte del token de SAS de servicio.

Operación	Tipo de objeto	Permiso firmado
Copiar blob de la dirección URL	Blob de destino (nuevo)	Crear (c) o Escribir (w)
Copiar blob de la dirección URL	Blob de destino (existente)	Escritura (w)
Copiar blob de la dirección URL	Blob en origen (dentro de la misma cuenta de almacenamiento)	Leer (r)
Copiar blob de la dirección URL	Blob de origen (en una cuenta de almacenamiento diferente)	Leer (r)

Para obtener más información sobre la SAS de servicio, consulte Creación de una SAS de servicio.

Cuenta SAS

Una SAS de cuenta está protegida con la clave de cuenta de almacenamiento. Una SAS de cuenta delega el acceso a los recursos de uno o varios de los servicios de almacenamiento. Todas las operaciones disponibles a través de un servicio o saS de delegación de usuarios también están disponibles a través de una SAS de cuenta.

En la tabla siguiente se indica el tipo de recurso firmado y los permisos firmados que se deben especificar al delegar el acceso:

Operación	Tipo de objeto	Servicio firmado	Tipo de recurso firmado	Permiso firmado
Copiar blob de la dirección URL	Blob de destino (nuevo)	Mancha (b)	Objeto (o)	Crear (c) o Escribir (w)
Copiar blob de la dirección URL	Blob de destino (existente)	Mancha (b)	Objeto (o)	Escritura (w)
Copiar blob de la dirección URL	Blob en origen (dentro de la misma cuenta de almacenamiento)	Mancha (b)	Objeto (o)	Leer (r)
Copiar blob de la dirección URL	Blob de origen (en una cuenta de almacenamiento diferente)	Mancha (b)	Objeto (o)	Leer (r)

Para obtener más información sobre la SAS de la cuenta, consulte Creación de una saS de cuenta.

La operación de Copy Blob From URL admite autorización de clave compartida. No se recomienda autorizar con claves de cuenta para la mayoría de los escenarios, ya que es menos seguro.

Microsoft recomienda no permitir la autorización de clave compartida para la cuenta de almacenamiento siempre que sea posible. Para obtener más información, consulte Impedir autorización con clave compartida.

Observaciones

El blob de origen y de destino de una Copy Blob From URL operación debe ser un blob en bloques.

En la versión 2020-10-02 y posteriores, se admite la autorización de Microsoft Entra para el origen de la operación de copia.

La operación de Copy Blob From URL siempre copia todo el blob de origen. No se admite la copia de un intervalo de bytes o conjunto de bloques.

Puede copiar un blob de origen en un blob de destino que tenga un nombre diferente. El blob de destino puede ser un blob en bloques existente o puede ser un nuevo blob que crea la operación de copia.

Al copiar desde un blob en bloques, se copian todos los bloques confirmados y sus identificadores de bloque. Los bloques no confirmados no se copian. Al final de la operación de copia, el blob de destino tendrá el mismo recuento de bloques confirmados que el origen.

El ETag valor de un blob en bloques cambia cuando se inicia la Copy Blob From URL operación y cuando finaliza.

Copia de propiedades y metadatos de blob

Cuando se copia un blob en bloques, se copian las siguientes propiedades del sistema en el blob de destino con los mismos valores:

Content-Type
Content-Encoding
Content-Language
Content-Length
Cache-Control
Content-MD5
Content-Disposition

La lista de bloques confirmados del blob de origen también se copia en el blob de destino. Los bloques no confirmados no se copian.

El blob de destino siempre tiene el mismo tamaño que el blob de origen, por lo que el valor del encabezado del blob de Content-Length destino coincide con el valor de ese encabezado para el blob de origen.

Si el x-ms-tags encabezado proporciona etiquetas para el blob de destino, deben estar codificadas en cadena de consulta. Las claves y los valores de etiqueta deben cumplir los requisitos de nomenclatura y longitud especificados en la operación Establecer etiquetas de blob .

El x-ms-tags encabezado puede contener hasta 2 kilobits de etiquetas. Si necesita más etiquetas, utilice la Set Blob Tags operación.

Si el x-ms-tags encabezado no proporciona etiquetas, las etiquetas no se copian del blob de origen.

Copia de un blob arrendado

La Copy Blob From URL operación solo lee del blob de origen, por lo que el estado de concesión del blob de origen no importa.

Facturación

Las solicitudes de precios pueden originarse en clientes que usan api de Blob Storage, ya sea directamente a través de la API REST de Blob Storage o desde una biblioteca cliente de Azure Storage. Estas solicitudes acumulan cargos por transacción. El tipo de transacción afecta a cómo se cobra la cuenta. Por ejemplo, las transacciones de lectura se acumulan en una categoría de facturación diferente a las transacciones de escritura. En la tabla siguiente se muestra la categoría de facturación de las solicitudes de Copy Blob From URL en función del tipo de cuenta de almacenamiento:

Operación	Tipo de cuenta de almacenamiento	Categoría de facturación
Copiar blob desde dirección URL (cuenta de destino¹)	Blob en bloques Premium Uso general estándar v2 Uso general estándar v1	Operaciones de escritura
Copiar blob desde dirección URL (cuenta de origen²)	Blob en bloques Premium Uso general estándar v2 Uso general estándar v1	Operaciones de lectura

¹La cuenta de destino se cobra por una transacción para iniciar la escritura.
²La cuenta de origen incurre en una transacción por cada solicitud de lectura al objeto de origen.

Para obtener información sobre los precios de las categorías de facturación especificadas, consulte precios de Azure Blob Storage.

Además, si las cuentas de origen y destino residen en regiones diferentes (por ejemplo, Norte de EE. UU. y Sur de EE. UU.), el ancho de banda que use para transferir la solicitud se cargará a la cuenta de almacenamiento de origen como salida. La salida entre cuentas dentro de la misma región es gratuita.

Al copiar un blob de origen en un blob de destino que tiene un nombre diferente dentro de la misma cuenta, se utilizan recursos de almacenamiento adicionales para el nuevo blob. A continuación, la operación de copia da lugar a un cargo por el uso de la capacidad de la cuenta de almacenamiento para esos recursos adicionales.

Consulte también

Autorizar solicitudes a Azure Storage
Estado y códigos de error
códigos de error de Blob Storage
Descripción de cómo se acumulan cargos en las instantáneas

Compartir a través de