01
형식부터 맞추고 자동 실행 시점을 확인
자동 실행은 기본으로 켜져 있으며 편집이 멈춘 뒤 350ms 후 실행됩니다. 입력 유형을 바꾸면 기존 입력을 새 형식으로 해석하므로, 해당 형식의 예제를 미리 보고 적용하면 구조 차이를 확인하기 쉽습니다.
- 자동 실행을 끄면 실행 버튼이 나타납니다. Ctrl/Cmd+Enter로도 실행할 수 있습니다.
Cloud Dev Helpers
Azure 리소스 ID 분석상위 경로부터 연결 필드까지
리소스 ID, 스토리지 URL, 연결 문자열 중 형식을 고르세요. 분석한 필드를 편집해 문자열로 다시 만들 수 있습니다.
Azure 리소스 ID 분석
문자열 또는 필드 JSON
결과
입력은 브라우저 메모리에서만 처리하며, 네트워크 요청이나 입력 기록 저장을 하지 않습니다.
분석 및 출력 설정
결과·미리보기·내보내기에 적용됩니다. 입력 원문은 가리지 않습니다. 쿼리 값과 안전한 공개 필드 목록에 없는 연결 값은 숨깁니다.
구성에는 fields 객체만 사용하세요. '필드 편집'은 미리보기 후 원래 값을 입력에 적용합니다. [REDACTED]가 들어 있는 복사본은 구성할 수 없습니다.
문자열 구조만 검사합니다. 리소스 존재 여부, 권한, 키 또는 실제 연결은 검증하지 않습니다.
입력 최대 32,768자 · 연결/쿼리 항목 100개 · ID 경로 조각 128개
구조 처리가 완료되었습니다. 결과를 확인하세요.
장애 기록에 남은 긴 경로에서 마지막 이름만 읽으면 어느 스토리지 계정과 컨테이너를 가리키는지 놓치기 쉽습니다. Azure 리소스 ID 분석은 구독 ID와 리소스 그룹, 공급자별 type/name 쌍을 나눠 전체 부모·자식 관계를 보여 줍니다. 기본 예제에는 가상 계정과 모두 0인 GUID가 들어 있어 실제 설정 없이도 결과 모양을 살펴볼 수 있습니다.
연결에 쓰이는 주소와 관리용 식별자는 담고 있는 정보가 다릅니다. Azure 연결 문자열에는 계정명과 인증 필드가 있을 수 있지만, 그것만으로 구독이나 리소스 그룹을 알아낼 수는 없습니다. 입력 유형을 직접 선택하고 fields, details, reconstructed를 비교하면 원문에 있는 정보와 별도로 확인해야 할 정보를 구분할 수 있습니다.
Azure 리소스 ID 분석으로 놓치기 쉬운 정보 찾기
짧은 이름만 추출하지 않고 경로의 계층과 재구성에 필요한 필드를 함께 확인합니다.
중첩 자원의 부모 관계를 유지
storageAccounts 다음에 blobServices와 containers가 이어져도 각 유형과 이름을 따로 보존합니다. 확장 리소스의 추가 providers 구간도 별도 묶음이 됩니다. 그룹 수준, 구독 수준, 관리 그룹과 테넌트 경로에서 없는 필드는 null로 남기므로, 모든 ID에 구독과 그룹이 있다고 잘못 가정하지 않게 됩니다.
필드를 고쳐 재구성하고 노출 범위를 확인
분석 결과에서 필드 편집을 선택하면 구성용 JSON을 미리 볼 수 있습니다. 적용하면 원래 필드가 입력에 들어가고, 결과는 현재 가리기 설정에 따라 만들어집니다. 복사와 다운로드도 화면의 결과를 그대로 사용합니다. 마스킹된 공유용 결과를 실제 연결에 쓸 문자열로 착각하지 않도록 구분할 수 있습니다.
입력을 덮어쓰기 전에 알아둘 세 가지
02
전체 결과 대신 fields를 편집
구성 방향은 fields 객체 자체를 받습니다. details와 reconstructed까지 포함한 전체 결과를 붙이면 구조 오류가 납니다. 필드 편집은 필요한 객체만 가져오며, 가려진 미리보기와 달리 적용되는 입력에는 원래 자격 증명이 들어갈 수 있습니다.
- 예제 불러오기, 비우기, 필드 편집은 먼저 변경 문자 수를 보여 줍니다. 적용 뒤 한 번 되돌리면 입력과 결과가 함께 복원됩니다.
03
최신 결과와 가리기 설정을 확인
입력이나 옵션이 바뀌면 이전 결과가 흐려지고 내보내기가 잠깁니다. 새 실행이 성공한 뒤 구조 결과는 JSON으로, 구성 결과는 텍스트로 받을 수 있습니다. 오류가 났다면 페이지에 남은 설명을 확인하고 수정하세요.
- 완전한 연결 값을 내보내려면 가리기를 끄고 다시 실행해야 합니다. [REDACTED]는 실제 키를 대신할 수 없습니다.
경로와 연결 정보를 읽는 네 가지 관점
범위와 공급자 체인
Azure 리소스 ID 분석 결과의 details에는 범위와 마지막 공급자 기준의 리소스 유형·이름이 나옵니다. fields에는 전체 공급자 체인을 보관하므로, 확장 리소스의 최종 이름을 확인한 뒤에도 어느 상위 리소스에 연결되었는지 되짚을 수 있습니다.
원문을 유지하는 스토리지 경로
스토리지 URL의 계정, 서비스, 클라우드 접미사와 보조 엔드포인트 여부를 나눕니다. pathSegments는 경로를 나눈 결과일 뿐 디렉터리 조회가 아닙니다. 인코딩된 이름, 중복 슬래시, 쿼리 순서와 중복 키를 보존하며 점 경로를 정규화하지 않습니다.
등호를 보존하는 연결 필드
연결 문자열은 세미콜론으로 항목을 나누고 각 항목의 첫 등호만 구분자로 사용합니다. 따라서 Base64 키 끝의 등호가 사라지지 않습니다. Storage 및 Service Bus/Event Hubs 형태를 검사하고, 키의 순서를 유지하되 대소문자만 다른 중복 키도 오류로 처리합니다.
같은 규칙으로 역방향 구성
JSON 필드로 문자열을 만들 때에도 분석과 같은 구조 검사를 거칩니다. kind는 선택한 입력 유형과 일치해야 하며 누락 필드나 추가 속성은 허용하지 않습니다. 결과에 포함된 파생 정보와 편집 가능한 원본 필드를 분리하여 무심코 요약 값을 입력하는 실수를 줄입니다.
성공 결과가 보장하는 것과 지원 범위
- 리소스가 존재한다는 뜻은 아닙니다
- Azure 리소스 ID 분석은 GUID와 범위, 유형·이름 쌍 등의 문법만 확인합니다. 공급자별 이름 제약, 배포 가능성, 권한, 실제 연결 상태까지 검사하지 않습니다. 연결 문자열과 URL에 없는 구독·리소스 그룹도 추정해서 채우지 않습니다.
- 표준 스토리지 호스트만 분류합니다
- URL 모드는 blob, dfs, file, queue, table 서비스와 core.windows.net, core.chinacloudapi.cn, core.usgovcloudapi.net을 지원합니다. 사용자 도메인, 프라이빗 도메인, Azure Stack, 과거 독일 클라우드, 정적 웹사이트와 Azurite URL은 대상이 아닙니다. 연결 문자열의 명시적 endpoint는 별도 문법으로 보존할 수 있습니다.
- SAS와 키를 생성하거나 복구하지 않습니다
- 기본 설정은 모든 쿼리 값과 공개 필드 목록 밖의 연결 값을 가립니다. 입력 원문에는 적용되지 않으며, 숨겨진 값을 [REDACTED]에서 되살릴 수 없습니다. 서명 생성, 만료·권한 검사, 키 갱신을 하지 않으므로 가려진 내보내기 결과는 실제 인증용으로 사용할 수 없습니다.
- 일반 데이터베이스 연결 문자열은 제외합니다
- Storage, Service Bus, Event Hubs 형태만 다룹니다. SQL/ODBC, JDBC, 일반 AMQP URI와 따옴표 안의 세미콜론을 이스케이프하는 문법은 지원하지 않습니다. UseDevelopmentStorage=true는 인식하고 보존하지만 기본 에뮬레이터 키로 확장하거나 Azurite를 실행하지 않습니다.
- Blob 이름의 의미를 추측하지 않습니다
- 경로를 디코딩하거나 슬래시·점 구간을 정리하지 않습니다. 한 조각의 경로는 컨테이너일 수도, 루트 컨테이너의 Blob일 수도 있으므로 어느 쪽이라고 단정하지 않습니다. 쿼리 항목은 순서대로 보존하지만 가리기를 켜면 값이 바뀌므로 서명 원문과는 달라집니다.
- 한 번에 한 입력만 처리합니다
- 입력은 최대 32,768자, 연결 문자열과 URL 쿼리는 각각 최대 100개 항목, ID는 최대 128개 경로 조각을 받습니다. 초과하면 오류를 내며 일부만 잘라 성공으로 표시하지 않습니다. 파일 업로드, 일괄 처리와 이력 저장은 제공하지 않습니다. 원래 URL은 제한 이내라도 펼친 JSON은 더 길 수 있습니다. 필드 편집은 입력을 바꾸기 전에 제한을 초과한 초안을 거부합니다.
Azure 리소스 ID 분석 관련 질문
리소스 ID에서 리소스 그룹과 리소스 이름을 어떻게 추출하나요?
리소스 ID 모드로 분석한 뒤 fields.resourceGroup과 details.resourceName을 확인하세요. 중첩 자원은 providers 안의 resources 배열에서 부모부터 이름을 읽을 수 있습니다. 리소스 그룹 범위가 없는 경로에서는 resourceGroup이 null이며, 마지막 이름 하나만으로 전체 식별자를 대체할 수는 없습니다.
스토리지 연결 문자열만으로 리소스 ID를 구할 수 있나요?
일반적으로 불가능합니다. 계정명과 endpoint를 알아도 구독과 리소스 그룹 정보가 없는 경우가 많기 때문입니다. 이 도구는 입력에 없는 관리 정보를 조회하지 않습니다. 해당 정보는 Azure 관리 환경에서 별도로 확인한 뒤 알맞은 리소스 ID 필드로 구성해야 합니다.
Blob의 경로는 어디에서 확인하나요?
스토리지 URL 모드의 fields.path에서 호스트 뒤 원래 경로를, details.pathSegments에서 분리한 조각을 볼 수 있습니다. 보통 컨테이너와 Blob 이름이 이어지지만 루트 컨테이너 예외가 있으므로 실제 파일 목록으로 해석하지 마세요. 인코딩된 공백도 원문 그대로 표시됩니다.
Azure에 연결하지 않고 Blob URL을 만들 수 있나요?
계정, 지원 서비스와 클라우드 접미사, 정확한 경로를 이미 알고 있다면 가능합니다. URL을 분석한 뒤 필드 편집으로 값을 바꾸고 구성하면 됩니다. 새 URL의 리소스 존재 여부나 접근 가능성은 확인하지 않으며, 유효한 SAS를 새로 서명해 주지도 않습니다.
포털과 PowerShell에서 연결 문자열이 다른 이유는 무엇인가요?
계정 키 방식인지 SAS 방식인지, 명시적 서비스 endpoint가 있는지에 따라 필드 조합이 달라질 수 있습니다. 항목 순서가 다른 경우도 있으므로 두 문자열을 각각 분석해 키 목록을 비교하세요. 모양만으로 어느 쪽이 현재 유효한 키인지 판단하거나 실제 권한을 확인할 수는 없습니다.
예상과 다른 구조가 나오나요?