# Amazon S3 범용 버킷 액세스
Amazon S3 콘솔, AWS Command Line Interface, AWS SDK 또는 Amazon S3 REST API를 사용하여 Amazon S3 범용 버킷에 액세스할 수 있습니다. S3 범용 버킷에 액세스하는 각 방법은 특정 사용 사례에 적용됩니다. 자세한 내용은 다음 섹션을 참조하세요.
**Topics**
+ [사용 사례](#accessing-use-cases)
+ [Amazon S3 콘솔](#accessing-aws-management-console)
+ [AWS CLI](#accessing-aws-cli)
+ [AWS SDK](#accessing-aws-sdks)
+ [Amazon S3 REST API](#AccessingUsingRESTAPI)
+ [범용 버킷의 가상 호스팅](VirtualHosting.md)
## 사용 사례
Amazon S3 범용 버킷의 사용 사례에 따라 버킷의 기본 데이터에 액세스하는 데 권장되는 다양한 방법이 있습니다. 다음 목록에는 데이터 액세스를 위한 일반적인 사용 사례가 포함되어 있습니다.
+ **정적 웹 사이트** – Amazon S3를 사용하여 정적 웹 사이트를 호스팅할 수 있습니다. 이 사용 사례에서는 웹 사이트처럼 작동하도록 범용 S3 버킷을 구성할 수 있습니다. Amazon S3에서의 웹 사이트 호스팅 절차를 단계별로 안내하는 예제는 [자습서: Amazon S3에서 정적 웹 사이트 구성](HostingWebsiteOnS3Setup.md)을 참조하십시오.
퍼블릭 액세스 차단과 같은 보안 설정이 활성화된 정적 웹 사이트를 호스팅하려면 원본 액세스 제어(OAC)와 함께 Amazon CloudFront를 사용하고 HTTPS와 같은 추가 보안 헤더를 구현하는 것이 좋습니다. 자세한 내용은 [안전한 정적 웹 사이트 시작하기](https://docs.aws.amazon.com//AmazonCloudFront/latest/DeveloperGuide/getting-started-secure-static-website-cloudformation-template.html)를 참조하십시오.
**참고**
Amazon S3는 정적 웹 사이트 액세스에 대해 [가상 호스팅 방식 URL](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#virtual-hosted-style-access)과 [경로 방식 URL](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#path-style-access)을 모두 지원합니다. 버킷은 경로 방식과 가상 호스팅 방식의 URL을 사용하여 액세스할 수 있기 때문에 DNS를 준수하는 버킷 이름으로 버킷을 만드는 것이 좋습니다. 자세한 내용은 [범용 버킷 할당량, 제한 및 규제](BucketRestrictions.md) 섹션을 참조하세요.
+ **공유 데이터세트** - Amazon S3를 기반으로 규모를 조정할 때 공유 범용 버킷 내의 고유한 접두사에 다양한 최종 고객 또는 사업부를 할당하는 다중 테넌트 모델을 채택하는 것이 일반적입니다. [Amazon S3 액세스 포인트](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html)를 사용하면 공유 데이터 세트에 액세스해야 하는 각 애플리케이션에 대해 하나의 대형 버킷 정책을 별도의 개별 액세스 포인트 정책으로 나눌 수 있습니다. 이 접근 방식을 사용하면 공유 데이터 세트 내에서 다른 애플리케이션이 수행하는 작업을 방해하지 않으면서 애플리케이션에 적합한 액세스 정책을 빌드하는 데 더 쉽게 집중할 수 있습니다. 자세한 내용은 [액세스 포인트로 공유 데이터세트에 대한 액세스 관리](access-points.md) 섹션을 참조하세요.
+ **높은 처리량 워크로드** – Mountpoint for Amazon S3는 Amazon S3 범용 버킷을 로컬 파일 시스템으로 마운트하는 데 사용되는 높은 처리량 성능의 오픈 소스 파일 클라이언트입니다. Mountpoint를 사용하면 애플리케이션에서 열기 및 읽기와 같은 파일 시스템 작업을 통해 Amazon S3에 저장된 객체에 액세스할 수 있습니다. Mountpoint는 이러한 작업을 S3 객체 API 호출로 자동 변환하여 애플리케이션이 파일 인터페이스를 통해 Amazon S3의 탄력적 스토리지 및 처리량을 이용할 수 있도록 합니다. 자세한 내용은 [Amazon S3 버킷을 로컬 파일 시스템으로 마운트](mountpoint.md) 섹션을 참조하세요.
+ **다중 리전 애플리케이션** – Amazon S3 다중 리전 액세스 포인트는 애플리케이션이 여러 AWS 리전에 있는 S3 범용 버킷의 요청을 이행하는 데 사용할 수 있는 글로벌 엔드포인트를 제공합니다. 다중 리전 액세스 포인트를 사용하여 단일 리전에서 사용되는 것과 동일한 아키텍처로 다중 리전 애플리케이션을 빌드하면 전 세계 어디에서나 해당 애플리케이션을 실행할 수 있습니다. 다중 리전 액세스 포인트는 퍼블릭 인터넷을 통해 요청을 보내는 대신 Amazon S3에 대한 인터넷 기반 요청의 가속화를 통해 기본 제공 네트워크 복원력을 제공합니다. 자세한 내용은 [다중 리전 액세스 포인트로 다중 리전 트래픽 관리](MultiRegionAccessPoints.md) 섹션을 참조하세요.
+ **Secure Shell(SSH) File Transfer 프로토콜(SFTP)** - 인터넷을 통해 민감한 데이터를 안전하게 전송하려는 경우 Amazon S3 범용 버킷과 함께 SFTP 지원 서버를 사용할 수 있습니다. AWS SFTP는 SSH의 전체 보안 및 인증 기능을 지원하는 네트워크 프로토콜입니다. 이 프로토콜을 사용하면 사용자 ID, 권한 및 키를 세밀하게 제어하거나 IAM 정책을 사용하여 액세스를 관리할 수 있습니다. SFTP 지원 서버를 Amazon S3 버킷과 연결하려면 먼저 SFTP 지원 서버를 만들어야 합니다. 그런 다음 사용자 계정을 설정하고 서버를 Amazon S3 범용 버킷과 연결합니다. 이 프로세스에 대한 자세한 내용은 *AWS 블로그*에서 [AWS Transfer for SFTP - Amazon S3용 완전 관리형 SFTP 서비스](https://aws.amazon.com/blogs/aws/new-aws-transfer-for-sftp-fully-managed-sftp-service-for-amazon-s3/)를 참조하십시오.
## Amazon S3 콘솔
이 콘솔은 Amazon S3 및 AWS 리소스를 관리하기 위한 웹 기반 사용자 인터페이스입니다. Amazon S3 콘솔을 사용하면 쉽게 버킷에 액세스하고 버킷의 속성을 수정할 수 있습니다. 코드를 작성하지 않고 콘솔 UI를 사용하여 대부분의 버킷 작업을 수행할 수 있습니다.
AWS 계정에 가입한 경우 Amazon S3 콘솔에 로그인한 후 Amazon S3 콘솔 홈페이지에서 **S3**을 선택하여 Amazon S3 콘솔에 액세스할 수 있습니다. 이 링크를 사용하여 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에 직접 액세스할 수도 있습니다.
## AWS CLI
AWS CLI를 통해 시스템 명령줄에서 명령을 실행하거나 스크립트를 빌드하여 AWS(S3 등) 작업을 수행할 수 있습니다. 예를 들어 여러 버킷에 액세스해야 할 경우 AWS CLI를 사용하여 일반적이고 반복적인 작업을 자동화하여 시간을 절약할 수 있습니다. 조직이 확장됨에 따라 일반적인 작업에 대한 스크립팅 가능성과 반복성을 자주 고려합니다.
[AWS CLI](https://aws.amazon.com/cli/)는 광범위한 AWS 서비스의 명령을 제공합니다. AWS CLI는 Windows, macOS, Linux에서 지원됩니다. 시작하려면 [https://docs.aws.amazon.com/cli/latest/userguide/](https://docs.aws.amazon.com/cli/latest/userguide/)를 참조하세요. Amazon S3용 명령에 대한 자세한 내용은 *AWS CLI 명령 참조*의 [s3api](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/index.html) 및 [s3control](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3control/index.html)을 참조하세요.
## AWS SDK
AWS에서는 다양한 프로그래밍 언어 및 플랫폼(Java, Python, Ruby, .NET, iOS, Android 등)을 위한 라이브러리와 샘플 코드로 구성된 소프트웨어 개발 키트(SDK)를 제공합니다. AWS SDK를 사용하면 편리하게 S3 및 AWS에 프로그래밍 방식으로 액세스할 수 있습니다. Amazon S3은 REST 서비스입니다. 프로그래밍 태스크를 간소화하기 위해 기본 Amazon S3 REST API를 래핑하는 AWS SDK 라이브러리를 사용하여 Amazon S3에 요청을 전송할 수 있습니다. 예를 들어 SDK는 서명 계산, 암호화 방식으로 요청 서명, 오류 관리 및 자동으로 요청 재시도와 같은 작업을 처리합니다. 다운로드 및 설치 방법을 비롯하여 AWS SDK에 대한 자세한 내용은 [AWS용 도구](https://aws.amazon.com/tools/)를 참조하세요.
Amazon S3와의 모든 상호 작용은 인증을 거치거나 익명으로 할 수 있습니다. AWS SDK를 사용할 경우 라이브러리는 사용자가 제공하는 키로부터 인증을 위한 서명을 컴퓨팅합니다. Amazon S3에 요청하는 방법에 대한 자세한 내용은 [요청](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html)을 참조하세요.
## Amazon S3 REST API
Amazon S3 아키텍처는 AWS에서 지원하는 인터페이스를 사용하여 객체를 저장 및 검색하는 프로그래밍 언어 중립적 아키텍처로 설계되었습니다. Amazon S3 REST API를 사용하여 프로그래밍 방식으로 S3 및 AWS에 액세스할 수 있습니다. REST API는 Amazon S3에 대한 HTTP 인터페이스입니다. REST API를 통해 표준 HTTP 요청을 사용하여 버킷과 객체를 생성하고, 가져오며, 삭제할 수 있습니다.
HTTP를 지원하는 임의의 도구 키트를 사용하여 REST API를 사용할 수 있습니다. 심지어 브라우저를 사용하여 객체를 가져올 수도 있습니다. 단, 객체를 익명으로 읽을 수 있어야 합니다.
REST API는 표준 HTTP 헤더 및 상태 코드를 사용하므로 표준 브라우저 및 도구 키트가 예상대로 작동합니다. Amazon은 일부 영역에서 HTTP에 기능을 추가했습니다. 예를 들어, 액세스 제어를 지원하기 위해 헤더를 추가했습니다. 이 경우 새로운 기능은 최대한 표준 HTTP 사용법과 일치하는 방식으로 추가되었습니다.
애플리케이션에서 직접 REST API를 호출할 경우 서명을 계산하는 코드를 작성하여 요청에 추가해야 합니다. Amazon S3에 요청하는 방법에 대한 자세한 내용은 **Amazon S3 API 참조에서 [요청](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html)을 참조하세요.
# 범용 버킷의 가상 호스팅
가상 호스팅은 한 웹 서버에 있는 여러 웹 사이트에 서비스를 제공하는 기능입니다. Amazon S3 REST API 요청에서 사이트를 구별하는 한 가지 방법은 URI의 경로 이름 부분 대신 요청-URI의 명백한 호스트 이름을 사용하는 것입니다. 일반적인 Amazon S3 REST 요청은 요청-URI 경로의 슬래시로 구분된 구성 요소를 사용하여 버킷을 지정합니다. 대신 Amazon S3 가상 호스팅을 통해 HTTP `Host` 헤더를 사용하여 REST API 직접 호출에서 범용 버킷을 지정할 수 있습니다. 실제로 Amazon S3은 `Host`의 의미를 `https://bucket-name.s3.region-code.amazonaws.com`에서 대부분의 버킷이 제한된 요청 유형에 대해 자동으로 액세스가 가능하다고 해석합니다. Amazon S3 리전 및 엔드포인트의 전체 목록은 **Amazon Web Services 일반 참조에서 [Amazon S3 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/s3.html)을 참조하세요.
가상 호스팅에는 다른 이점도 있습니다. 또한 등록된 도메인 이름 뒤에 버킷 이름을 지정하고 해당 이름을 Amazon S3용 DNS 별칭으로 만들어 Amazon S3 리소스의 URL을 `http://my.bucket-name.com/`처럼 완전하게 사용자 지정할 수 있습니다. 또한 버킷의 가상 서버에 있는 “루트 디렉터리”에 게시할 수도 있습니다. 이 기능은 기존의 많은 애플리케이션이 이 표준 위치에서 파일을 검색하기 때문에 중요할 수 있습니다. 예를 들어, `favicon.ico`, `robots.txt`, `crossdomain.xml`은 모두 루트에서 검색될 수 있습니다.
**중요**
SSL과 함께 가상 호스팅 스타일 범용 버킷을 사용하는 경우 SSL 와일드카드 인증서는 점(`.`)이 포함되지 않은 버킷과만 일치합니다. 이 제한을 해결하려면 HTTP를 사용하거나 고유한 인증서 확인 논리를 직접 작성합니다. 자세한 내용은 *AWS 뉴스 블로그*에 있는 [Amazon S3 경로 사용 중지 계획](https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/)을 참조하세요.
**Topics**
+ [경로 방식 요청](#path-style-access)
+ [가상 호스팅 방식 요청](#virtual-hosted-style-access)
+ [HTTP `Host` 헤더 버킷 사양](#VirtualHostingSpecifyBucket)
+ [예제](#VirtualHostingExamples)
+ [CNAME 레코드를 사용하여 Amazon S3 URL 사용자 지정](#VirtualHostingCustomURLs)
+ [호스트 이름과 Amazon S3 버킷 연결](#VirtualHostingCustomURLsHowTo)
+ [제한 사항](#VirtualHostingLimitations)
+ [이전 버전과의 호환성](#VirtualHostingBackwardsCompatibility)
## 경로 방식 요청
현재 Amazon S3는 모든 AWS 리전에서 가상 호스팅 방식 및 경로 방식 URL 액세스를 모두 지원합니다. 그러나 경로 스타일 URL은 향후 중단될 예정입니다. 자세한 내용은 다음 **중요** 참고 사항을 참조하세요.
Amazon S3에서 경로 방식 URL은 다음 형식을 사용합니다.
```
https://s3.region-code.amazonaws.com/bucket-name/key-name
```
예를 들어 미국 서부(오리건) 리전에서 이름이 `amzn-s3-demo-bucket1`인 버킷을 생성하고 해당 버킷의 `puppy.jpg` 객체에 액세스하려는 경우 다음 경로 방식 URL을 사용할 수 있습니다.
```
https://s3.us-west-2.amazonaws.com/amzn-s3-demo-bucket1/puppy.jpg
```
**중요**
업데이트(2020년 9월 23일) – 고객이 가상 호스팅 스타일 URL로 전환하는 데 필요한 시간을 가질 수 있도록 경로 스타일 URL의 사용 중단을 연기하기로 결정했습니다. 자세한 내용은 *AWS 뉴스 블로그*에서 [Amazon S3 경로 사용 중지 계획 - 나머지 이야기](https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/)를 참조하세요.
**주의**
웹 브라우저에서 액세스할 웹 사이트 콘텐츠를 호스팅할 때는 경로 스타일 URL을 사용하지 마세요. 브라우저의 동일 오리진 보안 모델을 방해할 수 있습니다. 웹 사이트 콘텐츠를 호스팅하려면 S3 웹 사이트 엔드포인트 또는 CloudFront 배포를 사용하는 것이 좋습니다. 자세한 내용은 [웹 사이트 엔드포인트](WebsiteEndpoints.md) 및 **AWS 퍼스펙티브 지침 패턴에서 [React 기반 단일 페이지 애플리케이션을 Amazon S3 및 CloudFront에 배포](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html)를 참조하세요.
## 가상 호스팅 방식 요청
가상 호스팅 방식의 URI에서 버킷 이름은 URL에서 도메인 이름의 일부입니다.
Amazon S3 가상 호스팅 방식 URL은 다음 형식을 사용합니다.
```
https://bucket-name.s3.region-code.amazonaws.com/key-name
```
이 예제에서 `amzn-s3-demo-bucket1`은 버킷 이름이고, 미국 서부(오리건)는 리전이며, `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`이면, 요청 버킷은 요청-URI의 슬래시로 구분된 첫 번째 구성 요소가 되고 요청 키는 요청-URI의 나머지 부분이 됩니다. 이는 일반적인 메서드로 이 단원의 첫 번째 예제와 두 번째 예제에 나와 있습니다. `Host` 헤더를 생략하는 것은 HTTP 1.0 요청에만 유효합니다.
+ 또는 `Host` 헤더 값이 `.s3.region-code.amazonaws.com`으로 끝나는 경우 버킷 이름이 `Host` 헤더 값에서 `.s3.region-code.amazonaws.com`까지의 선행 구성 요소가 됩니다. 요청에 대한 키는 요청-URI입니다. 이 해석은 이 단원의 세 번째와 네 번째 예제에 나와 있는 것처럼 버킷을 `.s3.region-code.amazonaws.com`의 하위 도메인으로 표시합니다.
+ 그렇지 않은 경우 요청에 대한 버킷은 `Host` 헤더의 소문자 값이며 요청에 대한 키는 요청-URI입니다. 이 해석은 버킷 이름과 동일한 DNS 이름을 등록하고 이 이름을 Amazon S3용 표준 이름(CNAME) 별칭으로 구성한 경우에 유용합니다. 도메인 이름 등록 및 CNAME DNS 레코드 구성 절차는 본 가이드에서 다루지 않지만, 이 단원의 마지막 예제에 나와 있습니다.
## 예제
이 단원은 예제 URL 및 요청을 제공합니다.
**Example - 경로 방식 URL 및 요청**
이 예에서는 다음을 사용합니다.
+ 버킷 이름 ‐ `example.com`
+ 리전 - 미국 동부(버지니아 북부)
+ 키 이름 ‐ `homepage.html`
URL은 다음과 같습니다.
```
1. http://s3.us-east-1.amazonaws.com/example.com/homepage.html
```
요청은 다음과 같습니다.
```
1. GET /example.com/homepage.html HTTP/1.1
2. Host: s3.us-east-1.amazonaws.com
```
HTTP 1.0을 사용한 요청 및 `Host` 헤더 생략은 다음과 같습니다.
```
1. GET /example.com/homepage.html HTTP/1.0
```
DNS를 준수하는 이름에 대한 자세한 내용은 [제한 사항](#VirtualHostingLimitations)을 참조하십시오. 키에 대한 자세한 내용은 [키](Welcome.md#BasicsKeys)를 참조하십시오.
**Example - 가상 호스팅 방식 URL 및 요청**
이 예에서는 다음을 사용합니다.
+ **버킷 이름** ‐ `amzn-s3-demo-bucket1`
+ **리전** ‐ 유럽(아일랜드)
+ **키 이름** ‐ `homepage.html`
URL은 다음과 같습니다.
```
1. http://amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com/homepage.html
```
요청은 다음과 같습니다.
```
1. GET /homepage.html HTTP/1.1
2. Host: amzn-s3-demo-bucket1.s3.eu-west-1.amazonaws.com
```
**Example — CNAME 별칭 메서드**
이 메서드를 사용하려면 DNS 이름을 `bucket-name.s3.us-east-1.amazonaws.com`의 CNAME 별칭으로 구성해야 합니다. 자세한 내용은 [CNAME 레코드를 사용하여 Amazon S3 URL 사용자 지정](#VirtualHostingCustomURLs) 섹션을 참조하세요.
이 예에서는 다음을 사용합니다.
+ 버킷 이름 ‐ `example.com`
+ **키 이름** ‐ `homepage.html`
URL은 다음과 같습니다.
```
1. http://www.example.com/homepage.html
```
예제는 다음과 같습니다.
```
1. GET /homepage.html HTTP/1.1
2. Host: www.example.com
```
## CNAME 레코드를 사용하여 Amazon S3 URL 사용자 지정
필요에 따라 웹 사이트 또는 서비스에 `s3.region-code.amazonaws.com`이 표시되지 않게 할 수도 있습니다. 예를 들어 Amazon S3에 웹 사이트 이미지를 호스팅할 경우 `http://images.example.com/` 대신 `http://images.example.com.s3.us-east-1.amazonaws.com/`을 선호할 수 있습니다. DNS를 준수하는 이름의 버킷은 ` http://BucketName.s3.Region.amazonaws.com/[Filename]`과 같이 참조될 수 있습니다(예: `http://images.example.com.s3.us-east-1.amazonaws.com/mydog.jpg`). 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을 만드는 경우 `http://images.example.com/filename` 및 `http://images.example.com.s3.us-east-1.amazonaws.com/filename`은 모두 동일합니다.
CNAME DNS 레코드는 도메인 이름으로 적절한 가상 호스팅 방식 호스트 이름의 별칭을 사용해야 합니다. 예를 들어 버킷 이름과 도메인 이름이 `images.example.com`이고 버킷이 미국 동부(버지니아 북부) 리전에 있는 경우, CNAME 레코드의 별칭은 `images.example.com.s3.us-east-1.amazonaws.com`으로 지정되어야 합니다.
```
1. images.example.com CNAME images.example.com.s3.us-east-1.amazonaws.com.
```
Amazon S3은 호스트 이름을 사용하여 버킷 이름을 확인합니다. 따라서 CNAME과 버킷 이름은 동일해야 합니다. 예를 들어, `www.example.com`을 `www.example.com.s3.us-east-1.amazonaws.com`. `http://www.example.com`을 액세스하는 경우, Amazon S3은 다음과 같은 요청을 받습니다.
**Example**
```
1. GET / HTTP/1.1
2. Host: www.example.com
3. Date: date
4. Authorization: signatureValue
```
Amazon S3은 원래 호스트 이름 `www.example.com`만 볼 수 있으며 요청을 해결하는 데 사용한 CNAME 매핑을 알지 못합니다.
모든 Amazon S3 엔드포인트를 CNAME 별칭에서 사용할 수 있습니다. 예를 들어, `s3.ap-southeast-1.amazonaws.com`은 CNAME 별칭에서 사용될 수 있습니다. 엔드포인트에 대한 자세한 내용은 *Amazon S3 API 참조*에서 [요청 엔드포인트](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTAPI.html)를 참조하세요. 사용자 지정 도메인을 사용하여 정적 웹 사이트를 만들려면 [자습서: Route 53에 등록된 사용자 지정 도메인을 사용하여 정적 웹 사이트 구성](website-hosting-custom-domain-walkthrough.md)을 참조하세요.
**중요**
CNAME과 함께 사용자 지정 URL을 사용하는 경우 구성하는 CNAME 또는 별칭 레코드에 대해 일치하는 버킷이 있는지 확인해야 합니다. 예를 들어, S3를 사용하여 웹 콘텐츠를 게시하기 위해 `www.example.com` 및 `login.example.com`에 대한 DNS 항목을 생성하는 경우 버킷 `www.example.com` 및 `login.example.com`을 모두 생성해야 합니다.
일치하는 버킷이 없는 S3 엔드포인트를 가리키는 CNAME 또는 별칭 레코드가 구성된 경우 소유권이 동일하지 않더라도 모든 AWS 사용자는 해당 버킷을 생성하고 구성된 별칭으로 콘텐츠를 게시할 수 있습니다.
같은 이유로 버킷을 삭제할 때 해당 CNAME 또는 별칭을 변경하거나 제거하는 것이 좋습니다.
## 호스트 이름과 Amazon S3 버킷 연결
**CNAME 별칭을 사용하여 호스트 이름과 Amazon S3 버킷 연결**
1. 제어하는 도메인에 속한 호스트 이름을 선택합니다.
이 예제는 `images` 도메인의 `example.com` 하위 도메인을 사용합니다.
1. 호스트 이름과 일치하는 버킷을 만듭니다.
이 예제에서 호스트 및 버킷 이름은 `images.example.com`입니다. 버킷 이름은 호스트 이름과 *정확하게* 일치해야 합니다.
1. Amazon S3 버킷에 대한 별칭으로 호스트 이름을 정의하는 CNAME DNS 레코드를 만듭니다.
예:
`images.example.com CNAME images.example.com.s3.us-west-2.amazonaws.com`
**중요**
요청 라우팅으로 인해, CNAME DNS 레코드는 앞의 예제에 나와 있는 것처럼 정확하게 정의해야 합니다. 그렇지 않은 경우 제대로 작동하는 것처럼 보일 수 있으나 결국 예기치 않은 동작이 발생합니다.
CNAME DNS 레코드를 구성하는 절차는 해당 DNS 서버나 DNS 공급자에 따라 다릅니다. 자세한 내용은 서버 설명서를 참조하거나, 제공자에게 문의하십시오.
## 제한 사항
Amazon S3용 SOAP API는 신규 고객에게 제공되지 않으며 2025년 8월 31일에 서비스 종료(EOL)됩니다. REST API 또는 AWS SDK를 사용하는 것이 좋습니다.
## 이전 버전과의 호환성
다음 섹션에서는 경로 스타일 및 가상 호스팅 스타일 URL 요청과 관련된 Amazon S3 이전 버전과의 다양한 호환성 측면을 다룹니다.
### 레거시 엔드포인트
일부 리전에서 레거시 엔드포인트를 지원합니다. 서버 액세스 로그 또는 AWS CloudTrail 로그에 이러한 엔드포인트가 표시될 수 있습니다. 자세한 내용은 아래 정보를 검토하세요. Amazon S3 리전 및 엔드포인트의 전체 목록은 **Amazon Web Services 일반 참조에서 [Amazon S3 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/s3.html)을 참조하세요.
**중요**
로그에 레거시 엔드포인트가 표시될 수도 있지만 항상 표준 엔드포인트 구문을 사용하여 버킷에 액세스하는 것이 좋습니다.
Amazon S3 가상 호스팅 방식 URL은 다음 형식을 사용합니다.
```
https://bucket-name.s3.region-code.amazonaws.com/key-name
```
Amazon S3에서 경로 방식 URL은 다음 형식을 사용합니다.
```
https://s3.region-code.amazonaws.com/bucket-name/key-name
```
#### s3‐리전
일부 이전 Amazon S3 리전은 점(예: `s3.us-west-2`) 대신 `s3`와 리전 코드(예: `s3‐us-west-2`) 사이에 대시(`-`)가 포함된 엔드포인트를 지원합니다. 버킷이 이러한 리전 중 하나에 있는 경우, 서버 액세스 로그 또는 CloudTrail 로그에 다음과 같은 엔드포인트 형식이 표시될 수 있습니다.
```
https://bucket-name.s3-region-code.amazonaws.com
```
이 예제에서 버킷 이름은 amzn-s3-demo-bucket1이고 리전은 미국 서부(오리건)입니다.
```
https://amzn-s3-demo-bucket1.s3-us-west-2.amazonaws.com
```
#### 레거시 전역 엔드포인트
일부 리전의 경우 레거시 전역 엔드포인트를 사용하여 리전별 엔드포인트를 지정하지 않는 요청을 구성할 수 있습니다. 레거시 전역 엔드포인트 지점은 다음과 같습니다.
```
bucket-name.s3.amazonaws.com
```
레거시 전역 엔드포인트를 사용하는 요청이 서버 액세스 로그 또는 CloudTrail 로그에 표시될 수 있습니다. 이 예제에서 버킷 이름은 `amzn-s3-demo-bucket1`이며 레거시 전역 엔드포인트는 다음과 같습니다.
```
https://amzn-s3-demo-bucket1.s3.amazonaws.com
```
**미국 동부(버지니아 북부)에 대한 가상 호스팅 방식 요청**
레거시 전역 엔드포인트를 사용한 요청은 기본적으로 미국 동부(버지니아 북부) 리전으로 이동합니다. 따라서 레거시 전역 엔드포인트는 미국 동부(버지니아 북부)에 대한 리전 엔드포인트 대신 사용되기도 합니다. 미국 동부(버지니아 북부)에 버킷을 생성하고 전역 엔드포인트를 사용하는 경우 Amazon S3은 기본적으로 요청을 이 리전으로 라우팅합니다.
**다른 리전에 대한 가상 호스팅 방식 요청**
또한 레거시 전역 엔드포인트는 지원되는 다른 리전의 가상화 호스팅 방식 요청에도 사용됩니다. 2019년 3월 20일 이전에 시작된 리전에 버킷을 생성하고 레거시 전역 엔드포인트를 사용하는 경우 Amazon S3은 DNS 레코드를 업데이트하여 요청을 올바른 위치로 다시 라우팅하며, 이로 인해 시간이 걸릴 수 있습니다. 그 동안 기본 규칙이 적용되며 가상 호스팅 방식의 요청은 미국 동부(버지니아 북부) 리전으로 이동합니다. 그런 다음 Amazon S3이 HTTP 307 임시 리디렉션을 사용하여 올바른 리전으로 리디렉션합니다.
2019년 3월 20일 이후에 시작된 리전의 S3 버킷인 경우 DNS 서버는 버킷이 상주하는 AWS 리전으로 요청을 직접 라우팅하지 않습니다. 대신, HTTP 400 Bad Request 오류를 반환합니다. 자세한 내용은 **Amazon S3 API 참조에서 [요청](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html)을 참조하세요.
**경로 방식 요청**
미국 동부(버지니아 북부) 리전에서는 경로 스타일 요청에 레거시 전역 엔드포인트를 사용할 수 있습니다.
다른 모든 리전에서 경로 방식 구문을 사용할 경우 버킷에 액세스할 때 리전별 엔드포인트를 사용해야 합니다. 버킷이 상주하는 리전의 엔드포인트와 다른 엔드포인트 또는 레거시 전역 엔드포인트가 있는 버킷에 액세스하려고 하면 HTTP 응답 코드 301 영구 리디렉션 오류와 리소스에 대한 올바른 URI를 나타내는 메시지가 표시됩니다. 예를 들어 미국 서부(오리건) 리전에 생성된 버킷에 `https://s3.amazonaws.com/bucket-name`을 사용하는 경우 HTTP 301 영구 리디렉션 오류가 표시됩니다.