시작하기#
기본 개념#
로컬 PC를 거치지 않고 두 클라우드 사이에서 파일 이동하기
S3와 Azure Blob은 각각 다른 클라우드 환경에서 파일과 오브젝트를 저장합니다.
두 환경 사이에서 파일을 이동할 때 중간 PC를 사용하면 다음과 같은 과정이 필요할 수 있습니다.
Amazon S3
│
│ Download
▼
Local PC
│
│ Upload
▼
Azure Blob파일 수가 적은 일회성 작업이라면 직접 내려받아 처리할 수 있지만, 정기적으로 생성되는 데이터나 대용량 파일을 반복적으로 이동하는 경우에는 중간 저장 위치를 계속 관리해야 합니다.
직접 전송을 구성하면 Source와 Target을 각각 연결해 파일이 클라우드 환경 사이에서 바로 이동하도록 구성할 수 있습니다.
┌──────────────────┐
│ Amazon S3 │
│ │
│ Source Bucket │
└────────┬─────────┘
│
│ Direct Transfer
▼
┌──────────────────┐
│ Azure Blob │
│ │
│ Target Container │
└──────────────────┘
이를 통해 파일 다운로드 → 로컬 저장 → 다시 업로드하는 중간 과정을 줄이고, S3에 있는 파일을 Azure Blob의 지정된 위치로 바로 전송할 수 있습니다.
저장 위치#
S3의 원본 경로와 Azure Blob의 대상 Container 연결하기
클라우드 간 전송에서는 전체 Storage를 모두 이동하기보다 실제 업무에 필요한 경로만 선택해 전송 범위를 구성할 수 있습니다.
예를 들어 S3 버킷에 원본 데이터와 로그, 백업 파일이 함께 저장되어 있는 경우 분석 환경에서 필요한 데이터 경로만 Azure Blob으로 전송할 수 있습니다.
Amazon S3
source-bucket
│
├── export/
│ ├── daily/ ◀ Selected
│ ├── monthly/
│ └── temporary/
│
├── logs/
└── backup/선택한 파일은 Azure Blob의 지정된 Container와 경로에 저장합니다.
Azure Blob
analytics-container
│
├── incoming/
│ └── daily/
│ ├── report-01.csv
│ ├── report-02.csv
│ └── report-03.csv
│
└── archive/
전송 경로는 업무에 따라 다음과 같이 구성할 수 있습니다.
| 구분 | Source | Target |
|---|---|---|
| Storage | Amazon S3 | Azure Blob Storage |
| 저장 위치 | S3 Bucket / Prefix | Container / Blob 경로 |
| 파일 범위 | 지정된 파일 또는 경로 | 지정된 Container 경로 |
| 파일 선택 | 이름·확장자·경로 조건 | 전송 결과에 따라 저장 |
| 활용 환경 | 원본·수집 데이터 | 분석·처리·보관 환경 |
이렇게 하면 서로 다른 클라우드 서비스를 사용하더라도 어느 S3 경로의 파일을 Azure Blob의 어느 위치로 보낼지 명확하게 분리해 관리할 수 있습니다.
실행 방식#
한 번만 전송하거나 새 파일과 변경 파일에 맞춰 자동 실행하기
S3에서 Azure Blob으로 파일을 이동하는 방식은 한 번의 대량 이전으로만 구성할 필요가 없습니다.
초기에는 기존 파일을 Azure Blob으로 전송하고, 이후에는 새로 생성되거나 변경되는 파일만 지속적으로 반영하도록 구성할 수 있습니다.
예를 들어 다음과 같은 방식으로 활용할 수 있습니다.
| 전송 목적 | 실행 방식 |
|---|---|
| 기존 데이터 이전 | 지정된 파일을 한 번에 전송 |
| 일일 데이터 전달 | 정해진 시간에 반복 실행 |
| 새 파일 반영 | Source에 생성된 파일 기준 실행 |
| 변경 파일 반영 | 변경된 파일만 확인해 전송 |
| 후속 처리 연계 | 이전 작업 완료 후 다음 전송 실행 |
S3에서 파일이 생성되는 방식과 Azure 환경에서 파일을 사용하는 시점을 기준으로 실행 조건을 선택할 수 있습니다.

예를 들어 매일 S3에 생성되는 데이터 파일을 Azure 분석 환경에서 사용한다면 다음과 같이 구성할 수 있습니다.
S3에 파일 생성
│
▼
전송 조건 확인
│
▼
대상 파일 선택
│
▼
Azure Blob 전송
│
▼
저장 결과 확인반대로 대량의 기존 데이터를 먼저 이동한 뒤 이후 변경 파일만 계속 반영하는 방식으로도 확장할 수 있습니다.
IT 엔지니어#
클라우드 연결#
Amazon S3와 Azure Blob을 각각 전송 환경에 등록하기
먼저 파일을 가져올 Amazon S3와 파일을 저장할 Azure Blob Storage를 각각 연결합니다.
두 클라우드는 서로 다른 서비스이므로 Source와 Target에서 필요한 접근 정보를 각각 관리합니다.
S3에서는 전송할 버킷과 파일을 읽을 수 있어야 하며, Azure Blob에서는 지정된 Container와 경로에 파일을 저장할 수 있어야 합니다.
Cloud Connections
Amazon S3
└── Source Bucket
└── Read Files
Azure Blob Storage
└── Target Container
└── Write Files
전송을 구성하기 전에 다음 항목을 확인합니다.
| 연결 환경 | 확인 내용 |
|---|---|
| Amazon S3 | Source Bucket 접근 가능 여부 |
| Source 권한 | 전송 대상 파일과 경로 읽기 |
| Azure Blob | Storage Account 연결 상태 |
| Target Container | 파일 저장 위치 확인 |
| Target 권한 | Blob 생성 및 저장 가능 여부 |
| 전송 경로 | Source와 Target 위치 연결 상태 |
각 클라우드 연결을 독립적으로 관리하면 S3와 Azure 환경의 접근 범위를 분리하면서 하나의 Flow에서 두 Storage를 함께 사용할 수 있습니다.
전송 경로#
S3 Source와 Azure Blob Target을 하나의 Flow로 직접 연결하기
연결 환경을 준비한 뒤 Source에서는 S3 버킷과 파일 경로를 지정하고, Target에서는 Azure Blob Container와 저장 위치를 설정합니다.
예를 들어 다음과 같은 전송 경로를 구성할 수 있습니다.
Source
Amazon S3
s3://data-source/export/
│
│ CSV / JSON / Media Files
▼
Transfer Flow
│
▼
Target
Azure Blob Storage
analytics/incoming/
필요한 경우 하나의 S3 경로를 여러 Azure Container로 분기하거나, 여러 S3 Source의 파일을 하나의 Azure Blob Storage로 모을 수도 있습니다.
예를 들어 데이터 유형에 따라 Target을 나누면 다음과 같이 구성할 수 있습니다.
┌──▶ Azure Blob / analytics/
Amazon S3 ── Flow ──┤
├──▶ Azure Blob / archive/
│
└──▶ Azure Blob / processing/이처럼 하나의 단순한 클라우드 간 전송을 시작점으로 두고, 이후 파일 유형이나 업무 목적에 따라 여러 Azure 저장 위치로 확장할 수 있습니다.
파일 기준#
필요한 파일만 선택하고 대상 환경에 맞게 전송하기
S3에는 여러 업무에서 사용하는 파일이 함께 저장될 수 있기 때문에 모든 파일을 Azure Blob으로 전송할 필요는 없습니다.
전송 작업에서는 Source 경로와 함께 파일 이름, 확장자 또는 경로 조건을 기준으로 실제 전송할 파일을 선택할 수 있습니다.
예를 들어 다음과 같이 구성할 수 있습니다.
| 파일 조건 | 전송 처리 |
|---|---|
*.csv |
Azure 분석 Container로 전송 |
*.json |
데이터 처리 경로로 전송 |
*.zip |
압축 파일 보관 경로로 전송 |
temporary/* |
전송 대상에서 제외 |
| 변경된 파일 | 변경 파일만 다시 전송 |

이렇게 하면 S3 전체 데이터를 반복적으로 이동하는 대신 Azure 환경에서 실제로 필요한 데이터만 선택적으로 전송하는 흐름을 구성할 수 있습니다.
처리 연결#
파일 전송 이후 Azure 환경의 다음 작업까지 이어가기
S3 파일이 Azure Blob에 저장된 후에는 해당 파일을 사용하는 다음 업무를 자동으로 연결할 수 있습니다.
예를 들어 파일이 Azure Blob에 정상적으로 반영된 뒤 데이터 처리 작업을 실행하거나, 처리 완료 결과를 다른 저장 위치로 이동하도록 구성할 수 있습니다.
Amazon S3
│
▼
Azure Blob
│
├──────────────▶ Processing
│
├──────────────▶ Notification
│
└──────────────▶ Next Transfer
후속 작업은 전송 자체와 별도로 구성할 수 있으므로, 파일이 정상적으로 도착한 경우에만 다음 작업을 실행하도록 연결할 수 있습니다.
| 연결 대상 | 활용 방식 |
|---|---|
| 데이터 처리 | Blob에 저장된 파일을 다음 처리 환경에서 활용 |
| 다음 Flow | 다른 Storage 또는 시스템으로 파일 전달 |
| 업무 알림 | 전송 완료 또는 실패 결과 전달 |
| 운영 확인 | 실행 상태와 파일 처리 결과 확인 |
이를 통해 단순히 S3의 파일을 Azure Blob으로 이동하는 데서 끝나는 것이 아니라 파일 전송 이후 실제 Azure 환경에서 필요한 작업까지 하나의 흐름으로 연결할 수 있습니다.
결과 검증#
전송된 파일과 Azure Blob의 반영 결과 함께 확인하기
전송 작업이 실행되면 Runs에서 전체 진행 상태와 전송 결과를 확인할 수 있습니다.
특정 Run을 선택하면 Source와 Target, 처리 파일 수와 전체 전송량을 확인하고, 필요한 경우 파일별 처리 결과까지 확인할 수 있습니다.

전송 결과에서는 다음 항목을 함께 확인할 수 있습니다.
| 확인 항목 | 확인 내용 |
|---|---|
| Source | Amazon S3 버킷과 원본 경로 |
| Target | Azure Blob Container와 저장 위치 |
| Total Files | 전송 대상 전체 파일 수 |
| Total Size | 전체 전송 용량 |
| Progress | 파일 전송 진행 상태 |
| Status | 완료·진행·실패 상태 |
| Started | 전송 시작 시간 |
| Completed | 최종 완료 시간 |
예를 들어 Run이 완료된 후에는 단순히 Completed 상태만 확인하는 것이 아니라, 실제 Target에 지정한 파일 수와 저장 결과가 정상적으로 반영되었는지 함께 확인할 수 있습니다.
예외 대응#
Source와 Target 환경을 구분해 문제를 확인하고 다시 실행하기
S3에서 Azure Blob으로 직접 전송하는 과정에서 문제가 발생하면 Source와 Target 중 어느 환경에서 추가 확인이 필요한지 먼저 구분합니다.
예를 들어 Source 파일을 읽을 수 없는 경우에는 S3 연결과 파일 접근 범위를 확인하고, Target에 저장할 수 없는 경우에는 Azure Blob의 Container와 저장 권한을 확인합니다.
Transfer Failed
│
┌──────────────┴──────────────┐
│ │
▼ ▼
Source 확인 Target 확인
│ │
S3 연결 상태 Azure 연결 상태
Bucket / 경로 Container / 경로
파일 접근 권한 파일 저장 권한
│ │
└──────────────┬──────────────┘
▼
환경 조정
│
▼
Retry
│
▼
Azure Blob 확인
재실행 후에는 새로운 Run을 통해 파일이 Azure Blob의 지정된 위치에 정상적으로 저장되었는지 확인할 수 있습니다.
이 레시피를 적용하면 Amazon S3 연결 → 전송 파일과 경로 선택 → Azure Blob Target 구성 → 실행 조건 설정 → 클라우드 간 직접 전송 → 후속 작업 연결 → Run 결과 확인 → 대상 저장 결과 검증까지 하나의 흐름으로 구성할 수 있습니다.
이를 통해 로컬 PC나 중간 저장 서버를 거치지 않고, AWS에 저장된 파일을 Azure 환경으로 직접 전송하고 이후 처리와 운영 확인까지 연결하는 클라우드 간 파일 워크플로를 구성할 수 있습니다.
개발자#
소스·대상 스토리지를 각각 장비로 등록한 뒤, 프리픽스를 지정해 전송을 만들고 종료 상태를 확인합니다. 시작 전에 다음 항목을 준비합니다.
| 준비물 | 내용 |
|---|---|
| INNORIX 인증 | INNORIX_ACCESS_TOKEN (Authorization: Bearer) |
| 소스 S3 장비 | S3 버킷의 device ID와 원본 프리픽스 (예: media/2026/09) |
| 대상 Azure 장비 | Azure Blob 컨테이너의 device ID와 대상 프리픽스 (예: archive/2026/09) |
| 런타임 | Python 3 + requests · Java 17+ · Node.js 18+ · .NET 8+ |
Python·Node.js는 REST를 직접 호출하는 최소
api()헬퍼와 상태 상수(STATUS_COMPLETE·TERMINAL)를 API 호출 레시피의 것을 재사용합니다. Java·C#은 번들 소스의InnorixClient(상수 포함)와Json(C#은J) 헬퍼를 사용합니다. 장비 식별자(s3-src·azure-dst)와 프리픽스는 실제 값으로 바꿔 넣습니다.
S3 → Azure Blob 전송 생성#
프리픽스를 폴더 루트로 넣어(sourcePaths + sendAllFolder) 전송을 만듭니다. target-action은 overwrite로 지정해 대상 프리픽스에 같은 대상 키의 객체가 있을 때 덮어쓰도록 합니다. 전송 생성 후 monitorId로 종료 상태를 확인합니다.
import time
def transfer_objects(source, target, prefixes, target_prefix, action="overwrite"):
transfer = api("POST", "/api/transfers/manual", {
"sourceDevice": source,
"targetDevice": target,
"targetPath": target_prefix,
"sourcePaths": prefixes,
"sendAllFolder": True,
"transferOptions": {"target-action": action},
})
return transfer["monitorId"]
def wait_transfer(monitor_id, timeout=14400, interval=5):
deadline = time.time() + timeout
while time.time() < deadline:
detail = api("GET", f"/api/transfers/{monitor_id}") or {}
if detail.get("status") in TERMINAL:
return detail
time.sleep(interval)
raise TimeoutError(monitor_id)
monitor_id = transfer_objects("s3-src", "azure-dst", ["media/2026/09"], "archive/2026/09")
detail = wait_transfer(monitor_id)
print("completed:", detail.get("status") == STATUS_COMPLETE)static String transferObjects(InnorixClient client, String source, String target,
List<String> prefixes, String targetPrefix, String action) {
Map<String, Object> transfer = client.apiObj("POST", "/api/transfers/manual", Json.newObj(
"sourceDevice", source,
"targetDevice", target,
"targetPath", targetPrefix,
"sourcePaths", prefixes,
"sendAllFolder", true,
"transferOptions", Json.newObj("target-action", action)), null);
return Json.str(transfer, "monitorId");
}
static Map<String, Object> waitTransfer(InnorixClient client, String monitorId,
long timeoutSec, long intervalSec) throws InterruptedException {
long deadline = System.currentTimeMillis() + timeoutSec * 1000;
while (System.currentTimeMillis() < deadline) {
Map<String, Object> detail = client.apiObj("GET", "/api/transfers/" + monitorId, null, null);
Integer status = Json.intOrNull(detail, "status");
if (status != null && InnorixClient.TERMINAL.contains(status))
return detail;
Thread.sleep(intervalSec * 1000);
}
throw new RuntimeException("timeout: " + monitorId);
}async function transferObjects(source, target, prefixes, targetPrefix, action = "overwrite") {
const transfer = await api("POST", "/api/transfers/manual", {
sourceDevice: source,
targetDevice: target,
targetPath: targetPrefix,
sourcePaths: prefixes,
sendAllFolder: true,
transferOptions: { "target-action": action },
});
return transfer.monitorId;
}
async function waitTransfer(monitorId, { timeout = 14400, interval = 5 } = {}) {
const deadline = Date.now() + timeout * 1000;
while (Date.now() < deadline) {
const detail = (await api("GET", `/api/transfers/${monitorId}`)) || {};
if (TERMINAL.has(detail.status)) return detail;
await new Promise((r) => setTimeout(r, interval * 1000));
}
throw new Error(`timeout: ${monitorId}`);
}
const monitorId = await transferObjects("s3-src", "azure-dst", ["media/2026/09"], "archive/2026/09");
const detail = await waitTransfer(monitorId);
console.log("completed:", detail.status === STATUS_COMPLETE);static async Task<string> TransferObjectsAsync(InnorixClient client, string source, string target,
IEnumerable<string> prefixes, string targetPrefix, string action = "overwrite")
{
var transfer = await client.ApiObjAsync("POST", "/api/transfers/manual", new JsonObject
{
["sourceDevice"] = source,
["targetDevice"] = target,
["targetPath"] = targetPrefix,
["sourcePaths"] = J.ArrOfStrings(prefixes),
["sendAllFolder"] = true,
["transferOptions"] = new JsonObject { ["target-action"] = action },
});
return J.Str(transfer, "monitorId");
}
static async Task<JsonObject> WaitTransferAsync(InnorixClient client, string monitorId,
int timeoutSec = 14400, int intervalSec = 5)
{
DateTime deadline = DateTime.UtcNow.AddSeconds(timeoutSec);
while (DateTime.UtcNow < deadline)
{
JsonObject detail = await client.ApiObjAsync("GET", quot;/api/transfers/{monitorId}", null, null);
int? status = J.IntOrNull(detail, "status");
if (status != null && InnorixClient.Terminal.Contains(status.Value))
return detail;
await Task.Delay(intervalSec * 1000);
}
throw new TimeoutException(monitorId);
}덮어쓰기 동작
numbering을 사용하면 대상에 같은 이름의 객체가 있을 때 이름이 변경될 수 있습니다. 지정된 대상 키의 객체를 덮어써 갱신하려면overwrite를 사용합니다.
대상 프리픽스 경로 Azure Blob은 컨테이너 아래의 가상 경로를 프리픽스로 사용합니다. 대상 프리픽스는 컨테이너 등록 방식에 맞춰 지정합니다. 객체가 많은 컨테이너는 프리픽스 단위로 여러 전송으로 나누면 각 전송의 범위가 명확해지고 실패 지점을 좁게 파악할 수 있습니다.
실패 객체가 남으면 중단 후 재개 레시피의 retry_failed(GET /api/transfers/{id}/files → POST /api/transfers/{id}/retry)로 실패분만 다시 전송합니다.
구현 결과#
이 레시피를 적용하면 다음 흐름으로 S3의 객체를 Azure Blob으로 전달할 수 있습니다.
Amazon S3 (s3-src) — 프리픽스 지정
↓
전송 생성 (overwrite) → 종료 상태까지 대기
↓
Azure Blob (azure-dst) — 대상 프리픽스에 객체 반영
↓
실패 객체만 재시도클라우드 자격 증명을 코드에서 다루지 않고 device ID만으로 S3 → Azure Blob 전송을 실행하며, 남은 실패 객체만 선택해 다시 보낼 수 있습니다.