URL에서 블록 넣기

2025-06-13

이 Put Block From URL 작업은 URL에서 콘텐츠를 읽는 Blob의 일부로 커밋할 새 블록을 만듭니다. 이 API는 버전 2018-03-28부터 사용할 수 있습니다.

요청

다음과 같이 Put Block From URL 요청을 생성할 수 있습니다. HTTPS를 사용하는 것이 좋습니다. myaccount 스토리지 계정 이름으로 바꿉니다.

PUT 메서드 요청 URI	HTTP 버전
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=id`	HTTP/1.1

에뮬레이트된 스토리지 서비스 요청

에뮬레이트된 스토리지 서비스에 대해 요청할 때 에뮬레이터 호스트 이름 및 Blob 서비스 포트를 로 127.0.0.1:10000지정한 다음 에뮬레이트된 스토리지 계정 이름을 지정합니다.

PUT 메서드 요청 URI	HTTP 버전
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=block&blockid=id`	HTTP/1.1

자세한 내용은 로컬 Azure Storage 개발에 Azurite 에뮬레이터 사용을 참조하세요.

URI 매개 변수

매개 변수	설명
`blockid`	필수 사항입니다. 블록을 식별하는 유효한 Base64 문자열 값입니다. 인코딩하기 전에 문자열 크기는 64바이트보다 작거나 같아야 합니다. 지정된 Blob의 경우 매개 변수에 대해 `blockid` 지정된 값의 길이는 각 블록에 대해 동일한 크기여야 합니다. 참고: Base64 문자열은 URL로 인코딩되어야 합니다.
`timeout`	선택 사항입니다. `timeout` 매개 변수는 초 단위로 표현됩니다. 자세한 내용은 Blob Service 작업대한 시간 제한 설정을 참조하세요.

요청 헤더

필수 및 선택적 요청 헤더는 다음 표에 설명되어 있습니다.

요청 헤더	설명
`Authorization`	필수 사항입니다. 권한 부여 체계, 계정 이름 및 서명을 지정합니다. 자세한 내용은 Azure Storage대한 요청 권한 부여를 참조하세요.
`Date` 또는 `x-ms-date`	필수 사항입니다. 요청에 대한 UTC(협정 세계시)를 지정합니다. 자세한 내용은 Azure Storage대한 요청 권한 부여를 참조하세요.
`x-ms-version`	모든 권한 있는 요청에 필요합니다. 이 요청에 사용할 작업의 버전을 지정합니다. 자세한 내용은 Azure Storage 서비스에 대한 버전 관리를 참조하세요. 의 경우 `Put Block From URL`버전은 2018-03-28 이상이어야 합니다.
`Content-Length`	필수 사항입니다. 요청 본문에서 전송되는 바이트 수를 지정합니다. 이 헤더의 값은 0으로 설정해야 합니다. 길이가 0이 아니면 상태 코드 400(잘못된 요청)으로 작업이 실패합니다.
`x-ms-copy-source:name`	필수 사항입니다. 원본 Blob의 URL을 지정합니다. 값은 Blob을 지정하는 최대 2KiB(키비바이트) 길이의 URL일 수 있습니다. 값은 요청 URI에 표시되므로 URL로 인코딩되어야 합니다. 원본 Blob은 공용이거나 공유 액세스 서명을 통해 권한이 부여되어야 합니다. 원본 Blob이 공용인 경우 작업을 수행하는 데 권한 부여가 필요하지 않습니다. 다음은 원본 개체 URL의 몇 가지 예입니다. - `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>`	선택 사항입니다. 복사 원본에 대한 권한 부여 체계 및 서명을 지정합니다. 자세한 내용은 Azure Storage대한 요청 권한 부여를 참조하세요. 참고: Microsoft Entra에는 전달자 체계만 지원됩니다. 참고: 원본 개체에 공개적으로 액세스할 수 있거나 원본 개체가 스토리지 계정에 있고 전달 `x-ms-copy-source:name`되는 SAS 토큰을 사용하는 경우 이 헤더가 필요하지 않습니다. 이 헤더는 버전 2020-10-02 이상에서 지원됩니다.
`x-ms-source-range`	선택 사항입니다. 지정된 범위의 원본 URL에 있는 Blob의 바이트만 업로드합니다. 이 헤더를 지정하지 않으면 전체 원본 Blob 콘텐츠가 단일 블록으로 업로드됩니다. 자세한 내용은 Blob 서비스 작업에 대한 범위 헤더 지정을 참조하세요.
`x-ms-source-content-md5`	선택 사항입니다. URI에서 블록 콘텐츠의 MD5 해시입니다. 이 해시는 URI에서 데이터를 전송하는 동안 블록의 무결성을 확인하는 데 사용됩니다. 이 헤더를 지정하면 스토리지 서비스는 복사 원본에서 도착한 콘텐츠의 해시를 이 헤더 값과 비교합니다. 참고: 이 MD5 해시는 Blob과 함께 저장되지 않습니다. 두 해시가 일치하지 않으면 오류 코드 400(잘못된 요청)과 함께 작업이 실패합니다.
`x-ms-source-content-crc64`	선택 사항입니다. URI에서 블록 콘텐츠의 CRC64 해시입니다. 이 해시는 URI에서 데이터를 전송하는 동안 블록의 무결성을 확인하는 데 사용됩니다. 이 헤더를 지정하면 스토리지 서비스는 복사 원본에서 도착한 콘텐츠의 해시를 이 헤더 값과 비교합니다. 참고: 이 CRC64 해시는 Blob과 함께 저장되지 않습니다. 두 해시가 일치하지 않으면 오류 코드 400(잘못된 요청)과 함께 작업이 실패합니다. 와 `x-ms-source-content-md5` 헤더가 모두 `x-ms-source-content-crc64` 있으면 요청이 실패하고 400(잘못된 요청)이 표시됩니다. 이 헤더는 버전 2019-02-02 이상에서 지원됩니다.
`x-ms-encryption-scope`	선택 사항입니다. 원본 콘텐츠를 암호화하는 데 사용할 암호화 범위를 나타냅니다. 이 헤더는 버전 2019-02-02 이상에서 지원됩니다.
`x-ms-lease-id:<ID>`	Blob에 활성 임차가 있는 경우 필수입니다. 활성 임대가 있는 Blob에서 이 작업을 수행하려면 이 헤더에 대한 유효한 임대 ID를 지정합니다.
`x-ms-client-request-id`	선택 사항입니다. 로깅이 구성될 때 로그에 기록되는 1kibibyte(KiB) 문자 제한으로 클라이언트에서 생성된 불투명 값을 제공합니다. 이 헤더를 사용하여 클라이언트 쪽 활동과 서버가 수신하는 요청의 상관 관계를 지정하는 것이 좋습니다. 자세한 내용은 Azure Blob Storage 모니터링을 참조하세요.
`x-ms-file-request-intent`	header가 Azure 파일 URL이고 `x-ms-copy-source` header가 OAuth 토큰을 지정하는 경우 `x-ms-copy-source-authorization` 필요합니다. 허용되는 값은 `backup`. 이 헤더는 `Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action` 헤더를 사용하여 권한이 부여된 ID에 할당된 RBAC 정책에 포함된 경우 `Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action` 또는 `x-ms-copy-source-authorization` 부여하도록 지정합니다. 버전 2025-07-05 이상에 사용할 수 있습니다.

요청 헤더(고객 제공 암호화 키)

버전 2019-02-02를 기준으로 고객이 제공한 키로 Blob을 암호화하라는 요청에 다음 헤더를 지정할 수 있습니다. 고객이 제공한 키(및 해당 헤더 집합)를 사용한 암호화는 선택 사항입니다.

요청 헤더	설명
`x-ms-encryption-key`	필수 사항입니다. Base64로 인코딩된 AES-256 암호화 키입니다.
`x-ms-encryption-key-sha256`	필수 사항입니다. 암호화 키의 Base64로 인코딩된 SHA256 해시입니다.
`x-ms-encryption-algorithm: AES256`	필수 사항입니다. 암호화에 사용할 알고리즘을 지정합니다. 이 헤더의 값은 `AES256`이어야 합니다.

요청 메시지 본문

없음.

샘플 요청

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=AAAAAA%3D%3D HTTP/1.1  
  
Request Headers:  
x-ms-version: 2018-03-28  
x-ms-date: Sat, 31 Mar 2018 14:37:35 GMT    
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-499

응답

응답에는 HTTP 상태 코드와 응답 헤더 집합이 포함됩니다.

상태 코드

작업이 성공하면 상태 코드 201(생성됨)이 반환됩니다.

상태 코드에 대한 자세한 내용은 상태 및 오류 코드참조하세요.

응답 헤더

이 작업에 대한 응답에는 다음 헤더가 포함됩니다. 응답에는 추가 표준 HTTP 헤더도 포함될 수 있습니다. 모든 표준 헤더는 HTTP/1.1 프로토콜 사양준수합니다.

응답 헤더	설명
`Content-MD5`	클라이언트가 메시지 콘텐츠 무결성을 확인할 수 있도록 반환됩니다. 이 헤더의 값은 Blob Storage에 의해 계산됩니다. 반드시 요청 헤더에 지정된 값과 동일하지는 않습니다. 버전 2019-02-02 이상에서는 요청에 이 헤더가 있는 경우에만 이 헤더가 반환됩니다.
`x-ms-content-crc64`	버전 2019-02-02 이상. 클라이언트가 메시지 콘텐츠 무결성을 확인할 수 있도록 반환됩니다. 이 헤더의 값은 Blob Storage에 의해 계산됩니다. 요청 헤더에 지정된 값과 반드시 같을 필요는 없습니다. 헤더가 요청에 없을 때 `x-ms-source-content-md5` 반환됩니다.
`x-ms-request-id`	만들어진 요청을 고유하게 식별하며 이를 사용하여 요청 문제를 해결할 수 있습니다. 자세한 내용은 API 작업문제 해결을 참조하세요.
`x-ms-version`	요청을 실행하는 데 사용된 Blob Storage 버전입니다.
`Date`	서비스에서 생성되는 UTC 날짜/시간 값으로, 응답이 시작된 시간을 나타냅니다.
`x-ms-request-server-encrypted: true/false`	버전 2015-12-11 이상. 이 헤더의 값은 블록의 내용이 지정된 알고리즘을 사용하여 성공적으로 암호화된 경우로 `true` 설정됩니다. 그렇지 않으면 값이 `false`설정됩니다.
`x-ms-encryption-key-sha256`	버전 2019-02-02 이상. 요청이 암호화에 고객이 제공한 키를 사용한 경우 반환되므로 클라이언트는 제공된 키를 사용하여 요청 내용이 성공적으로 암호화되었는지 확인할 수 있습니다.
`x-ms-encryption-scope`	버전 2019-02-02 이상. 요청이 암호화 범위를 사용한 경우 반환되므로 클라이언트는 암호화 범위를 사용하여 요청 내용이 성공적으로 암호화되었는지 확인할 수 있습니다.
`x-ms-client-request-id`	요청 및 해당 응답 문제를 해결하는 데 사용할 수 있습니다. 이 헤더의 값은 요청에 있고 값에 표시되는 ASCII 문자가 1,024자 이하인 경우 `x-ms-client-request-id` 헤더의 값과 같습니다. 요청에 `x-ms-client-request-id` 헤더가 없으면 응답에 표시되지 않습니다.

샘플 응답

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sat, 31 Mar 2018 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

승인

Azure Storage에서 데이터 액세스 작업을 호출할 때 권한 부여가 필요합니다. 아래 설명된 대로 Put Block From URL 작업에 권한을 부여할 수 있습니다.

중요합니다

Microsoft는 관리 ID와 함께 Microsoft Entra ID를 사용하여 Azure Storage에 대한 요청을 승인하는 것이 좋습니다. Microsoft Entra ID는 공유 키 권한 부여에 비해 뛰어난 보안 및 사용 편의성을 제공합니다.

Microsoft Entra ID(권장)
SAS(공유 액세스 서명)
공유 키

Azure Storage는 Microsoft Entra ID를 사용하여 Blob 데이터 요청에 대해 권한을 부여하는 것을 지원합니다. Microsoft Entra ID를 사용하면 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 보안 주체에 권한을 부여할 수 있습니다. 보안 주체는 사용자, 그룹, 애플리케이션 서비스 주체 또는 Azure 관리 ID일 수 있습니다. 보안 주체는 OAuth 2.0 토큰을 반환하기 위해 Microsoft Entra ID에 의해 인증됩니다. 그런 다음 토큰을 사용하여 Blob service에 대한 요청을 승인할 수 있습니다.

Microsoft Entra ID를 사용한 권한 부여에 대한 자세한 내용은 Microsoft Entra ID사용하여 Blob에 대한 액세스 권한 부여를 참조하세요.

권한

아래에는 Microsoft Entra 사용자, 그룹, 관리 ID 또는 서비스 주체가 Put Block From URL 작업을 호출하는 데 필요한 RBAC 작업과 이 작업을 포함하는 최소 권한의 기본 제공 Azure RBAC 역할이 나와 있습니다.

Azure RBAC 작업 : Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
최소 권한 기본 제공 역할:Storage Blob 데이터 기여자

Azure RBAC를 사용하여 역할을 할당하는 방법에 대한 자세한 내용은 Blob 데이터액세스하기 위한 Azure 역할 할당을 참조하세요.

SAS(공유 액세스 서명)는 스토리지 계정의 리소스에 대한 보안 위임된 액세스를 제공합니다. SAS를 사용하면 클라이언트가 데이터에 액세스하는 방법을 세부적으로 제어할 수 있습니다. 클라이언트가 액세스할 수 있는 리소스, 해당 리소스에 대한 사용 권한 및 SAS가 유효한 기간을 지정할 수 있습니다.

Put Block From URL 작업은 세 가지 유형의 공유 액세스 서명인 사용자 위임 SAS, 서비스 SAS및 계정 SAS지원합니다.

보안 모범 사례로 더 쉽게 손상될 수 있는 스토리지 계정 키 대신 Microsoft Entra 자격 증명을 사용하는 것이 좋습니다. 애플리케이션 디자인에 공유 액세스 서명이 필요한 경우 가능한 경우 Microsoft Entra 자격 증명을 사용하여 사용자 위임 SAS를 만듭니다.

스토리지 계정에 대해 공유 키 액세스가 허용되지 않는 경우 Blob Storage에 대한 요청에는 서비스 SAS 토큰 또는 계정 SAS 토큰이 허용되지 않습니다. 자세한 내용은 공유 키를 허용하지 않으면 SAS 토큰미치는 영향 이해를 참조하세요.

사용자 위임 SAS

사용자 위임 SAS는 Microsoft Entra 자격 증명 및 SAS에 대해 지정된 권한으로 보호됩니다.

컨테이너 또는 Blob 리소스에 위임된 SAS 토큰을 사용하여 Put Block From URL 작업을 호출하려면 사용자 위임 SAS 토큰의 일부로 쓰기(w) 권한이 필요합니다.

사용자 위임 SAS에 대한 자세한 내용은 사용자 위임 SAS만들기를 참조하세요.

서비스 SAS

서비스 SAS는 스토리지 계정 키로 보호됩니다. 서비스 SAS는 Blob Storage와 같은 단일 Azure Storage 서비스의 리소스에 대한 액세스를 위임합니다.

컨테이너 또는 Blob 리소스에 위임된 SAS 토큰을 사용하여 Put Block From URL 작업을 호출하려면 서비스 SAS 토큰의 일부로 쓰기(w) 권한이 필요합니다.

서비스 SAS에 대한 자세한 내용은 서비스 SAS만들기를 참조하세요.

계정 SAS

계정 SAS는 스토리지 계정 키로 보호됩니다. 계정 SAS는 하나 이상의 스토리지 서비스에서 리소스에 대한 액세스 권한을 위임합니다. 서비스 SAS 또는 사용자 위임 SAS를 통해 가능한 모든 작업은 계정 SAS를 통해서도 가능합니다.

다음 표에서는 액세스를 위임할 때 지정할 서명된 리소스 종류 및 서명된 권한을 나타냅니다.

수술	서명된 서비스	서명된 리소스 종류	서명된 권한
URL에서 블록 넣기	Blob(b)	Object(o)	쓰기(w)

계정 SAS에 대한 자세한 내용은 계정 SAS만들기를 참조하세요.

비고

Put Block From URL 나중에 블록 Blob에 포함할 블록을 업로드합니다. 블록 Blob에는 최대 50,000개의 블록이 포함될 수 있습니다. 각 블록은 다른 크기일 수 있습니다. 로 Put Block From URL 업로드되는 블록의 최대 크기는 100메비바이트(MiB)입니다. 더 큰 블록(최대 4,000MiB)을 업로드하려면 Put Block을 참조하세요.

버전 2020-10-02 이상에서는 복사 작업의 원본에 대해 Microsoft Entra 권한 부여가 지원됩니다.

Blob에는 언제든지 최대 100,000개의 커밋되지 않은 블록이 있을 수 있습니다. 이 최대값을 초과하면 서비스는 상태 코드 409(RequestEntityTooLargeBlockCountExceedsLimit)를 반환합니다.

다음 표에서는 서비스 버전별로 허용되는 최대 블록 및 Blob 크기에 대해 설명합니다.

서비스 버전	최대 블록 크기(경유 `Put Block From URL`)	최대 Blob 크기(via `Put Block List`)	단일 쓰기 작업을 통한 최대 Blob 크기( `Put Blob From URL`via )
버전 2020-04-08 이상	4,000MiB	약 190.7TiB(4,000MiB × 50,000블록)	5,000MiB
2020-04-08 이전 버전	100MiB	약 4.75TiB(100MiB × 50,000 블록)	256MiB

블록 집합을 업로드한 후 Put Block List 작업을 호출하여 이 집합에서 서버의 Blob을 만들거나 업데이트할 수 있습니다. 집합의 각 블록은 해당 Blob 내에서 고유한 블록 ID로 식별됩니다. 블록 ID는 특정 Blob으로 범위가 지정되므로 다른 Blob에는 동일한 ID를 가진 블록이 있을 수 있습니다.

아직 존재하지 않는 Blob을 호출 Put Block From URL 하면 콘텐츠 길이가 0인 새 블록 Blob이 만들어집니다. 이 Blob은 옵션이 지정된 경우 List Blobs 작업에 의해 include=uncommittedblobs 열거됩니다. 업로드한 블록은 새 Blob을 호출할 Put Block List 때까지 커밋되지 않습니다. 이러한 방식으로 만든 Blob은 일주일 동안 서버에서 유지 관리됩니다. 해당 기간 내에 Blob에 더 많은 블록을 추가하거나 블록을 커밋하지 않은 경우 Blob은 가비지 수집됩니다.

작업을 사용하여 Put Block From URL 성공적으로 업로드된 블록은 로 Put Block List커밋될 때까지 Blob의 일부가 되지 않습니다. Before Put Block List 가 호출되어 새 blob 또는 업데이트된 blob을 커밋하면 Get Blob 에 대한 모든 호출은 커밋되지 않은 블록을 포함하지 않고 blob 콘텐츠를 반환합니다.

아직 커밋되지 않은 다른 블록과 동일한 블록 ID를 가진 블록을 업로드하는 경우 해당 ID를 가진 마지막으로 업로드된 블록이 다음 성공적인 Put Block List 작업에서 커밋됩니다.

After Put Block List 가 호출되면 블록 목록에 지정된 커밋되지 않은 모든 블록이 새 Blob의 일부로 커밋됩니다. Blob에 대한 블록 목록에 지정되지 않은 커밋되지 않은 블록은 가비지 수집되고 Blob Storage에서 제거됩니다. 커밋되지 않은 블록은 마지막으로 성공한 Put Block From URL 작업 후 일주일 이내에 동일한 Blob에 대한 Put Block ListPut Block From URL 성공적인 호출이 없는 경우에도 가비지 수집됩니다. Blob에서 Put Blob 이 호출되면 커밋되지 않은 블록은 가비지 수집됩니다.

Blob에 활성 임대가 있는 경우 클라이언트는 Blob에 블록을 쓰기 위해 요청에 유효한 임대 ID를 지정해야 합니다. 클라이언트가 임대 ID를 지정하지 않거나 잘못된 임대 ID를 지정하는 경우 Blob Storage는 상태 코드 412(사전 조건 실패)를 반환합니다. 클라이언트가 임대 ID를 지정하지만 Blob에 활성 임대가 없는 경우 Blob Storage는 상태 코드 412(사전 조건 실패)도 반환합니다.

지정된 Blob의 경우 모든 블록 ID의 길이가 같아야 합니다. 커밋되지 않은 기존 블록에 대한 블록 ID와 다른 길이의 블록 ID를 사용하여 블록이 업로드되면 서비스는 오류 응답 코드 400(잘못된 요청)을 반환합니다.

호출 Put Block From URL 은 기존 Blob의 마지막 수정 시간을 업데이트하지 않습니다.

페이지 Blob을 호출하면 Put Block From URL 오류가 반환됩니다.

'보관' Blob을 호출하면 Put Block From URL 오류가 반환되고 또는 hot Blob에서 cool 호출해도 Blob 계층은 변경되지 않습니다.

청구서 발행

가격 책정 요청은 Blob Storage REST API를 통해 직접 Blob Storage API를 사용하는 클라이언트 또는 Azure Storage 클라이언트 라이브러리에서 비롯할 수 있습니다. 이러한 요청은 트랜잭션당 요금이 발생합니다. 트랜잭션 유형은 계정에 청구되는 방식에 영향을 줍니다. 예를 들어 읽기 트랜잭션은 쓰기 트랜잭션과 다른 청구 범주에 발생합니다. 다음 표에서는 스토리지 계정 유형에 따라 Put Block From URL 요청에 대한 청구 범주를 보여 줍니다.

수술	Storage 계정 유형	청구 범주
URL에서 블록 넣기(대상 계정¹)	프리미엄 블록 Blob 표준 범용 v2 표준 범용 v1	쓰기 작업
URL에서 블록 배치(소스 계정²)	프리미엄 블록 Blob 표준 범용 v2 표준 범용 v1	읽기 작업

¹ 개대상 계정에는 쓰기를 시작하기 위해 하나의 트랜잭션에 대해 요금이 청구됩니다.
² 개소스 계정은 소스 객체에 대한 각 읽기 요청에 대해 하나의 트랜잭션을 발생시킵니다.

또한 원본 및 대상 계정이 서로 다른 지역(예: 미국 북부 및 미국 남부)에 있는 경우 요청을 전송하는 데 사용되는 대역폭은 원본 스토리지 계정에 송신으로 청구됩니다. 동일한 지역 내의 계정 간 송신은 무료입니다.

지정된 청구 범주의 가격 책정에 대한 자세한 내용은 Azure Blob Storage 가격 책정을 참조하세요.