일반 목적 버킷의 가상 호스팅

일반 목적 버킷의 가상 호스팅

가상 호스팅(virtual hosting)은 단일 웹 서버에서 여러 웹사이트를 제공하는 방식이에요. Amazon S3 REST API 요청에서 사이트를 구분하는 한 가지 방법은 URI의 경로 이름 부분만 쓰는 대신 Request-URI의 호스트 이름을 이용하는 거예요. 일반적인 Amazon S3 REST 요청은 Request-URI 경로의 첫 번째 슬래시 구분 구성 요소로 버킷을 지정해요. 반면 Amazon S3 가상 호스팅을 사용하면 REST API 호출에서 HTTP Host 헤더로 일반 목적 버킷을 지정할 수 있어요. 실제로 Amazon S3는 Host를 해석하며, 대부분의 버킷은 https://bucket-name.s3.region-code.amazonaws.com에서 제한된 유형의 요청에 자동으로 접근 가능해요.

가상 호스팅에는 다른 이점도 있어요. 등록한 도메인 이름으로 버킷 이름을 짓고 그 이름을 Amazon S3의 DNS 별칭으로 만들면, 예를 들어 http://my.bucket-name.com/처럼 Amazon S3 리소스의 URL을 완전히 사용자 정의할 수 있어요. 또한 버킷의 가상 서버 "루트 디렉터리"에 게시할 수 있어요. 많은 기존 애플리케이션이 이 표준 위치에서 파일을 검색하므로 중요해요. 예를 들어 favicon.ico, robots.txt, crossdomain.xml은 모두 루트에 있다고 기대돼요.

중요: SSL과 함께 가상 호스트 스타일 일반 목적 버킷을 사용할 때, SSL 와일드카드 인증서는 마침표(.)가 포함되지 않은 버킷만 일치해요. 이 제한을 우회하려면 HTTP를 사용하거나 직접 인증서 검증 로직을 작성하세요.

출처: 문서

본문

경로 스타일 요청 (Path-style requests)

현재 Amazon S3는 모든 AWS 리전에서 가상 호스트 스타일과 경로 스타일 URL 접근을 모두 지원해요. 하지만 경로 스타일 URL은 향후 단계적으로 중단될 예정이에요.

경로 스타일 URL 형식:

https://s3.region-code.amazonaws.com/bucket-name/key-name

예를 들어 US West (Oregon) 리전에 amzn-s3-demo-bucket1이라는 버킷을 만들고 안의 puppy.jpg 객체에 접근하려면:

https://s3.us-west-2.amazonaws.com/amzn-s3-demo-bucket1/puppy.jpg

경고: 웹 브라우저에서 접근할 웹사이트 콘텐츠를 호스팅할 때는 브라우저의 동일 출처(same origin) 보안 모델을 방해할 수 있는 경로 스타일 URL을 피하세요. 웹사이트 콘텐츠를 호스팅하려면 S3 웹사이트 엔드포인트나 CloudFront 배포를 사용하는 것이 좋아요.

가상 호스트 스타일 요청 (Virtual-hosted-style requests)

가상 호스트 스타일 URI에서는 버킷 이름이 URL의 도메인 이름 일부가 돼요.

형식:

https://bucket-name.s3.region-code.amazonaws.com/key-name

예시 (amzn-s3-demo-bucket1 버킷, US West (Oregon) 리전, puppy.png 키):

https://amzn-s3-demo-bucket1.s3.us-west-2.amazonaws.com/puppy.png

HTTP Host 헤더로 버킷 지정하기

GET 요청이 SSL 엔드포인트를 사용하지 않는다면 HTTP Host 헤더로 요청의 버킷을 지정할 수 있어요. REST 요청의 Host 헤더는 다음과 같이 해석돼요.

  • Host 헤더가 생략되거나 값이 s3.region-code.amazonaws.com이면 요청의 버킷은 Request-URI의 첫 번째 슬래시 구분 구성 요소이고, 키는 Request-URI의 나머지예요. Host 헤더 생략은 HTTP 1.0 요청에서만 유효해요.
  • Host 헤더 값이 .s3.region-code.amazonaws.com으로 끝나면 버킷 이름은 .s3.region-code.amazonaws.com 앞부분이고, 키는 Request-URI예요. 즉 버킷이 .s3.region-code.amazonaws.com의 하위 도메인으로 노출돼요.
  • 그 외에는 요청의 버킷은 Host 헤더의 소문자 값이고, 키는 Request-URI예요. 등록한 DNS 이름을 버킷 이름으로 쓰고 CNAME 별칭으로 구성했다면 유용해요.

예시 (Examples)

버킷 example.com, US East (N. Virginia) 리전, 키 homepage.html:

http://s3.us-east-1.amazonaws.com/example.com/homepage.html

요청:

GET /example.com/homepage.html HTTP/1.1
Host: s3.us-east-1.amazonaws.com

HTTP 1.0으로 Host 헤더를 생략한 요청:

GET /example.com/homepage.html HTTP/1.0

버킷 amzn-s3-demo-bucket1, Europe (Ireland) 리전, 키 homepage.html:

http://amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com/homepage.html

요청:

GET /homepage.html HTTP/1.1
Host: amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com

버킷 이름이 도메인 이름과 같은 example.com:

http://www.example.com/homepage.html

요청:

GET /homepage.html HTTP/1.1
Host: www.example.com

CNAME 레코드로 Amazon S3 URL 사용자 정의하기

필요에 따라 웹사이트나 서비스에 s3.region-code.amazonaws.com이 표시되지 않게 하고 싶을 수 있어요. 예를 들어 http://images.example.com/처럼 나타나길 원할 수 있어요. DNS 호환 이름을 가진 모든 버킷은 http://BucketName.s3.Region.amazonaws.com/[Filename]으로 참조할 수 있어요. CNAME을 사용해 images.example.com을 Amazon S3 호스트 이름에 매핑하면 URL을 http://images.example.com/mydog.jpg처럼 만들 수 있어요.

버킷 이름은 CNAME과 같아야 해요. 예를 들어 images.example.com을 images.example.com.s3.us-east-1.amazonaws.com에 매핑하는 CNAME을 만들면 두 URL이 같아져요.

images.example.com CNAME images.example.com.s3.us-east-1.amazonaws.com.

Amazon S3는 호스트 이름으로 버킷 이름을 결정하므로 CNAME과 버킷 이름이 같아야 해요. CNAME 별칭에는 어떤 Amazon S3 엔드포인트든 사용할 수 있어요.

중요: CNAME으로 맞춤 URL을 사용할 때는 구성하는 각 CNAME/별칭 레코드에 일치하는 버킷이 존재해야 해요. 일치하는 버킷 없이 S3 엔드포인트를 가리키는 CNAME/별칭 레코드를 구성하면, 소유권이 달라도 아무 AWS 사용자가 그 버킷을 만들고 별칭 아래에 콘텐츠를 게시할 수 있어요. 같은 이유로 버킷을 삭제할 때는 해당 CNAME/별칭도 변경하거나 제거하는 것을 권장해요.

호스트 이름을 Amazon S3 버킷과 연결하기

  1. 내가 제어하는 도메인에 속한 호스트 이름을 선택해요. 이 예시는 example.com 도메인의 images 하위 도메인을 사용해요.
  2. 호스트 이름과 일치하는 버킷을 만들어요. 이 예시에서 호스트와 버킷 이름은 images.example.com이고, 버킷 이름은 호스트 이름과 정확히 일치해야 해요.
  3. 호스트 이름을 Amazon S3 버킷의 별칭으로 정의하는 CNAME DNS 레코드를 만들어요: images.example.com CNAME images.example.com.s3.us-west-2.amazonaws.com

중요: 요청 라우팅 때문에 CNAME DNS 레코드는 정확히 위 예시처럼 정의해야 해요. 그렇지 않으면 올바르게 작동하는 것처럼 보일 수 있지만 결국 예측 불가능한 동작을 초래할 수 있어요.

제한 (Limitations)

Amazon S3용 SOAP API는 신규 고객에게 제공되지 않으며 2025년 8월 31일에 수명 종료(EOL)를 앞두고 있어요. REST API나 AWS SDK를 사용할 것을 권장해요.

역호환성 (Backward compatibility)

레거시 엔드포인트 — 일부 리전이 레거시 엔드포인트를 지원해요. 로그에 보일 수 있지만, 항상 표준 엔드포인트 구문으로 버킷에 접근할 것을 권장해요.

  • 가상 호스트 스타일: https://bucket-name.s3.region-code.amazonaws.com/key-name
  • 경로 스타일: https://s3.region-code.amazonaws.com/bucket-name/key-name

s3-Region — 일부 구형 리전은 s3와 리전 코드 사이에 점(.) 대신 대시(-)를 쓰는 엔드포인트를 지원해요(예: s3-us-west-2). 예: https://amzn-s3-demo-bucket1.s3-us-west-2.amazonaws.com

레거시 전역 엔드포인트 — 일부 리전에서 리전별 엔드포인트를 지정하지 않는 요청에 레거시 전역 엔드포인트를 사용할 수 있어요: bucket-name.s3.amazonaws.com. 레거시 전역 엔드포인트로 만든 요청은 기본적으로 US East (N. Virginia) 리전으로 가요. 2019년 3월 20일 이후 출시된 리전의 버킷은 DNS 서버가 요청을 직접 라우팅하지 않고 HTTP 400 Bad Request 오류를 반환해요.

더 알아보기 (Learn more)