S3 버킷의 경로 스타일 요청과 가상 호스팅 스타일 요청
n8n에서 S3 업로드 요청 시 발생하는 오류를 해결한 방법과 가상 호스팅 권장 이유를 설명합니다.
개요
n8n 자동화를 구현하던 중 n8n에서 s3 업로드 헤더를 직접적으로 지원하지 않아 http request 노드 블럭을 활용해 요청을 전송하려고 했습니다. 하지만 The authorization header is malformed; the region 's3' is wrong; expecting 'ap-northeast-2 에러가 발생하였고 해당 문제를 해결하는 과정을 작성하였습니다.
PutObject
REST API 요청으로 버킷에 업로드하기 위한 문서는 다음과 같습니다.
따라서 다음과 같은 URL로 요청을 전송하게 되었습니다.
해당 요청을 보냈을 때 다음과 같은 오류가 발생하였고 The authorization header is malformed; the region 's3' is wrong; expecting 'ap-northeast-2 문서를 자세히 읽어본 결과 경로 기반 요청과 가상 호스팅 스타일 요청이 있다는 것을 알게되었습니다.
해당 문구를 통해 가상 호스팅 스타일 요청을 찾아본 결과 다음과 같습니다.
경로 스타일 접근 방식은 다음과 같습니다.
가상 호스팅 스타일 접근 방식은 다음과 같습니다.
가상 호스팅 스타일 요청으로는 접근되지 않아 경로 스타일 접근 방식을 사용하여 접근하였고 성공하였습니다.
AWS 권장 방식
하지만 AWS에서는 가상 호스팅 접근 방식을 권장하고 있습니다. 가상 호스팅 방식을 권장하는 이유는 다음과 같습니다.
💡 HTTP 요청의 Host 헤더에 버킷 이름을 포함시켜 버킷을 지정합니다. 실제 URL에서는 버킷 이름이 호스트 이름의 일부가 됩니다. 여기서 S3는 호스트 이름을 해석하여 요청이 어떤 버킷을 대상으로 하는지 쉽게 판단합니다. 이를 통해 모든 S3 버킷이 기본적으로 이 가상 호스팅 URL을 통해 읽기 작업 같은 일부 기본 작업을 수행할 수 있다는 뜻입니다.
또한 가상 호스팅에는 다른 이점도 있습니다. 등록된 도메인 이름으로 버킷 이름을 지정하고 해당 이름을 Amazon S3의 DNS 별칭으로 만들면 Amazon S3 리소스의 URL을 완전히 사용자 지정할 수 있습니다(예: http://my.bucket-name.com/). 또한 버킷의 가상 서버 "루트 디렉토리"에 파일을 게시할 수 있습니다. 이 기능은 많은 기존 애플리케이션이 이 표준 위치에서 파일을 검색하기 때문에 중요할 수 있습니다. 예를 들어, favicon.ico, robots.txt, crossdomain.xml 등은 모두 루트에서 찾을 수 있어야 합니다
정리하면 다음과 같습니다.
- 사용자 정의 도메인 사용 가능 (예: my.bucket-name.com)
- 웹사이트 호스팅 시 루트 경로에 파일 배치 가능
- 미래 호환성 보장 (AWS는 점차 이 방식을 권장하고 있으며 경로 방식의 지원을 종료한다고 함)
물론 버킷의 실제 접근 권한 설정에 따라 가능한 작업은 달라집니다.
정리
AWS는 가상 호스팅 버킷 요청을 권장하고 있지만, 최신화가 되지 않은건지, n8n에 문제인건지 정확히 모르겠지만 가상 호스팅 방식의 요청이 허가되지 않았습니다. 따라서 경로 기반 요청을 수행하게 되었고 해당 요청이 성공하게 되어 각자의 차이점을 정리하게 되었습니다.
