# Amazon S3를 사용하여 정적 웹 사이트 호스팅
<a name="WebsiteHosting"></a>

Amazon S3을 사용하여 정적 웹 사이트를 호스팅할 수 있습니다. *정적* 웹 사이트에서 개별 웹 페이지는 정적 콘텐츠를 포함합니다. 클라이언트 측 스크립트를 포함할 수도 있습니다.

**참고**  
[AWS Amplify Hosting](https://docs.aws.amazon.com//amplify/latest/userguide/welcome.html.html)을 사용하여 S3에 저장된 정적 웹 사이트 콘텐츠를 호스팅하는 것이 좋습니다. Amplify Hosting은 Amazon CloudFront로 구동되는 전 세계적으로 사용 가능한 콘텐츠 전송 네트워크(CDN)에 웹 사이트를 쉽게 배포할 수 있도록 하는 완전 관리형 서비스이므로 안전한 정적 웹 사이트 호스팅이 가능합니다.  
AWS Amplify Hosting을 사용하면 범용 버킷 내에서 객체의 위치를 선택하고, 관리형 CDN에 콘텐츠를 배포하고, 어디서나 웹 사이트에 액세스할 수 있는 퍼블릭 HTTPS URL을 생성할 수 있습니다. Amplify Hosting에 대한 자세한 내용은 *AWS Amplify 콘솔 사용 설명서*의 [S3 범용 버킷에서 AWS Amplify Hosting에 정적 웹 사이트 배포](https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-amplify.html) 및 [Amplify 콘솔을 사용하여 S3에서 정적 웹 사이트 배포](https://docs.aws.amazon.com//amplify/latest/userguide/deploy--from-amplify-console.html)를 참조하세요.

지침 및 단계별 연습을 포함하여 Amazon S3에서 정적 웹 사이트를 호스팅하는 방법에 대한 자세한 내용은 다음 주제를 참조하십시오.

**중요**  
정적 웹사이트를 호스팅하는 데 사용하는 버킷이 AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 암호화된 경우, SSE-KMS는 익명 사용자를 지원하지 않으므로 웹사이트를 제공하려면 Amazon CloudFront 배포를 생성해야 합니다. CloudFront 배포를 생성할 때는 오리진을 보호하기 위해 오리진 액세스 ID(OAI) 대신 오리진 액세스 제어(OAC)를 사용해야 합니다. OAI는 SSE-KMS를 지원하지 않으므로 OAC를 사용해야 합니다.  
OAC에 대한 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [Amazon S3 오리진에 대한 액세스 제한](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) 섹션을 참조하세요. Amazon CloudFront를 사용하여 정적 웹사이트를 호스팅하는 방법을 보여주는 자습서는 [자습서: Amazon S3, Amazon CloudFront 및 Amazon Route 53로 온디맨드 스트리밍 비디오 호스팅](tutorial-s3-cloudfront-route53-video-streaming.md) 섹션을 참조하세요.

**Topics**
+ [웹 사이트 엔드포인트](WebsiteEndpoints.md)
+ [웹 사이트 호스팅 사용 설정](EnableWebsiteHosting.md)
+ [인덱스 문서 구성](IndexDocumentSupport.md)
+ [사용자 지정 오류 문서 구성](CustomErrorDocSupport.md)
+ [웹 사이트 액세스에 대한 권한 설정](WebsiteAccessPermissionsReqd.md)
+ [(선택 사항) 웹 트래픽 로깅](LoggingWebsiteTraffic.md)
+ [(선택 사항) 웹 페이지 리디렉션 구성](how-to-page-redirect.md)
+ [교차 오리진 리소스 공유(CORS) 사용](cors.md)
+ [정적 웹 사이트 자습서](static-website-tutorials.md)

# 웹 사이트 엔드포인트
<a name="WebsiteEndpoints"></a>

버킷을 정적 웹 사이트로 구성하면 버킷의 AWS 리전별 웹 사이트 엔드포인트를 통해 웹 사이트를 사용할 수 있습니다. 웹 사이트 엔드포인트는 사용자가 REST API 요청을 보내는 엔드포인트와 다릅니다. 엔드포인트 간의 차이에 대한 자세한 내용은 [웹 사이트 엔드포인트와 REST API 엔드포인트 간의 주요 차이점](#WebsiteRestEndpointDiff)을 참조하십시오.

리전에 따라 Amazon S3 웹 사이트 엔드포인트는 다음 두 형식 중 하나를 따릅니다.
+ **s3-website 대시(-) 리전** ‐ `http://bucket-name.s3-website-Region.amazonaws.com`
+ **s3-website 점(.) 리전** ‐ `http://bucket-name.s3-website.Region.amazonaws.com`

이러한 URL은 사용자가 웹 사이트에 대해 구성한 기본 인덱스 문서를 반환합니다. Amazon S3 웹 사이트 엔드포인트의 전체 목록은 [Amazon S3 웹 사이트 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints)를 참조하십시오.

**참고**  
Amazon S3 정적 웹 사이트의 보안을 강화하기 위해 Amazon S3 웹 사이트 엔드포인트 도메인(예: *s3-website-us-east-1.amazonaws.com* 또는 *s3-website.ap-south-1.amazonaws.com*)은 [공개 접미사 목록(PSL)](https://publicsuffix.org/)에 등록되어 있습니다. 보안 강화를 위해 Amazon S3 정적 웹 사이트의 도메인 이름에 민감한 쿠키를 설정해야 하는 경우 `__Host-` 접두사가 있는 쿠키를 사용하는 것이 좋습니다. 이렇게 쿠키를 설정하면 교차 사이트 요청 위조 시도(CSRF)로부터 도메인을 보호하는 데 도움이 됩니다. 자세한 내용은 Mozilla 개발자 네트워크의 [Set-Cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes) 페이지를 참조하십시오.

웹 사이트를 퍼블릭으로 설정하려면 고객이 웹 사이트 엔드포인트의 콘텐츠에 액세스할 수 있도록 모든 콘텐츠를 공개적으로 읽기 가능하도록 만들어야 합니다. 자세한 정보는 [웹 사이트 액세스에 대한 권한 설정](WebsiteAccessPermissionsReqd.md) 섹션을 참조하세요.

**중요**  
Amazon S3 웹 사이트 엔드포인트는 HTTPS 또는 액세스 포인트를 지원하지 않습니다. HTTPS를 사용하려면 다음 중 하나를 수행하세요.  
(권장) [AWS Amplify Hosting](https://docs.aws.amazon.com//amplify/latest/userguide/welcome.html.html)을 사용하여 S3에 저장된 정적 웹 사이트 콘텐츠를 호스팅하세요. Amplify Hosting은 Amazon CloudFront로 구동되는 전 세계적으로 사용 가능한 콘텐츠 전송 네트워크(CDN)에 웹 사이트를 쉽게 배포할 수 있도록 하는 완전 관리형 서비스이므로 안전한 정적 웹 사이트 호스팅이 가능합니다.  
AWS Amplify Hosting을 사용하면 범용 버킷 내에서 객체의 위치를 선택하고, 관리형 CDN에 콘텐츠를 배포하고, 어디서나 웹 사이트에 액세스할 수 있는 퍼블릭 HTTPS URL을 생성할 수 있습니다. Amplify Hosting에 대한 자세한 내용은 *AWS Amplify 콘솔 사용 설명서*의 [S3 범용 버킷에서 AWS Amplify Hosting에 정적 웹 사이트 배포](https://docs.aws.amazon.com//AmazonS3/latest/userguide/website-hosting-amplify) 및 [Amplify 콘솔을 사용하여 S3에서 정적 웹 사이트 배포](https://docs.aws.amazon.com//amplify/latest/userguide/deploy--from-amplify-console.html)를 참조하세요.
Amazon CloudFront를 사용하여 Amazon S3에서 호스팅되는 정적 웹 사이트를 제공. 자세한 내용은 [CloudFront를 사용하여 Amazon S3 버킷에 대한 HTTPS 요청을 처리하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-https-requests-s3)를 참조하십시오 사용자 지정 도메인에서 HTTPS를 사용하려면 [Route 53에 등록된 사용자 지정 도메인을 사용하여 정적 웹 사이트 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-custom-domain-walkthrough.html)을 참조하십시오.
요청자 지불 버킷은 웹 사이트 엔드포인트를 통한 액세스를 허용하지 않습니다. 해당 버킷으로의 모든 요청은 403 Access Denied 응답을 수신합니다. 자세한 내용은 [스토리지 전송 및 사용량에 대한 요청자 지불 범용 버킷 사용](RequesterPaysBuckets.md) 섹션을 참조하세요.

**Topics**
+ [웹 사이트 엔드포인트 예제](#website-endpoint-examples)
+ [DNS CNAME 추가](#website-endpoint-dns-cname)
+ [Route 53에서 사용자 지정 도메인 사용](#custom-domain-s3-endpoint)
+ [웹 사이트 엔드포인트와 REST API 엔드포인트 간의 주요 차이점](#WebsiteRestEndpointDiff)

## 웹 사이트 엔드포인트 예제
<a name="website-endpoint-examples"></a>

다음 예제에서는 정적 웹 사이트로 구성된 Amazon S3 버킷에 액세스하는 방법을 보여줍니다.

**Example - 루트 수준의 객체 요청**  
버킷의 루트 수준에 저장된 특정 객체를 요청하려면 다음 URL 구조를 사용합니다.  

```
http://bucket-name.s3-website.Region.amazonaws.com/object-name
```
예를 들어, 다음 URL은 버킷의 루트 수준에 저장된 `photo.jpg` 객체를 요청합니다.  

```
http://example-bucket.s3-website.us-west-2.amazonaws.com/photo.jpg
```

**Example - 접두사로 객체 요청**  
버킷의 폴더에 저장된 객체를 요청하려면 다음 URL 구조를 사용합니다.  

```
http://bucket-name.s3-website.Region.amazonaws.com/folder-name/object-name
```
다음 URL은 버킷의 `docs/doc1.html` 객체를 요청합니다.  

```
http://example-bucket.s3-website.us-west-2.amazonaws.com/docs/doc1.html
```

## DNS CNAME 추가
<a name="website-endpoint-dns-cname"></a>

등록된 도메인이 있는 경우 DNS CNAME 항목을 추가하면 Amazon S3 웹 사이트 엔드포인트를 가리킬 수 있습니다. 예를 들어, 등록된 도메인 `www.example-bucket.com`이 있다면 `www.example-bucket.com` 버킷을 생성하고 `www.example-bucket.com.s3-website.Region.amazonaws.com`을 가리키는 DNS CNAME 레코드를 추가할 수 있습니다. `http://www.example-bucket.com`으로의 모든 요청은 `www.example-bucket.com.s3-website.Region.amazonaws.com`으로 라우팅됩니다.

자세한 내용은 [CNAME 레코드를 사용하여 Amazon S3 URL 사용자 지정](VirtualHosting.md#VirtualHostingCustomURLs) 섹션을 참조하세요.

## Route 53에서 사용자 지정 도메인 사용
<a name="custom-domain-s3-endpoint"></a>

Amazon S3 웹 사이트 엔드포인트를 사용하여 웹 사이트에 액세스하는 대신, Amazon Route 53에 등록된 자체 도메인(예: `example.com`)을 사용하여 콘텐츠를 처리할 수 있습니다. Route 53과 함께 Amazon S3을 사용하여 루트 도메인에서 웹 사이트를 호스팅할 수 있습니다. 예를 들어, 루트 도메인 `example.com`을 보유하고 Amazon S3에서 웹 사이트를 호스팅하는 경우 웹 사이트 방문자는 `http://www.example.com` 또는 `http://example.com`을 입력하여 브라우저에서 사이트에 액세스할 수 있습니다.

예제 연습은 섹션을 참조하십시오[자습서: Route 53에 등록된 사용자 지정 도메인을 사용하여 정적 웹 사이트 구성](website-hosting-custom-domain-walkthrough.md) 

## 웹 사이트 엔드포인트와 REST API 엔드포인트 간의 주요 차이점
<a name="WebsiteRestEndpointDiff"></a>

Amazon S3 웹 사이트 엔드포인트는 웹 브라우저를 통한 액세스에 최적화되었습니다. 다음 표에는 REST API 엔드포인트와 웹 사이트 엔드포인트 간의 주요 차이점이 요약되어 있습니다.


| 주요 차이점 | REST API 엔드포인트 | 웹 사이트 엔드포인트 | 
| --- | --- | --- | 
| 액세스 제어 |  퍼블릭 콘텐츠 및 프라이빗 콘텐츠 모두 지원  | 공개적으로 읽기 가능한 콘텐츠만 지원  | 
| 오류 메시지 처리 |  XML 형식의 오류 응답 반환  | HTML 문서 반환 | 
| 리디렉션 지원 |  해당 사항 없음  | 객체 수준 및 버킷 수준의 리디렉션 모두 지원 | 
| 요청 지원  |  모든 버킷 및 객체 작업 지원  | 객체에 대한 GET 및 HEAD 요청만 지원 | 
| 버킷의 루트에서 GET 및 HEAD 요청에 대한 응답 | 버킷의 객체 키 목록 반환 | 웹 사이트 구성에 지정된 인덱스 문서 반환 | 
| Secure Sockets Layer(SSL) 지원 | SSL 연결 지원 | SSL 연결을 지원하지 않음 | 

Amazon S3 엔드포인트의 전체 목록은 **AWS 일반 참조에서 [Amazon S3 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/s3.html)을 참조하십시오.

# 웹 사이트 호스팅 사용 설정
<a name="EnableWebsiteHosting"></a>

버킷을 정적 웹 사이트로 구성할 때 정적 웹 사이트 호스팅을 사용 설정하고, 인덱스 문서를 추가하고, 권한을 설정해야 합니다.

Amazon S3 콘솔, REST API, AWS SDK, AWS CLI 또는 CloudFormation을 사용하여 정적 웹 사이트 호스팅을 사용할 수 있습니다.

사용자 지정 도메인으로 웹 사이트를 구성하려면 [자습서: Route 53에 등록된 사용자 지정 도메인을 사용하여 정적 웹 사이트 구성](website-hosting-custom-domain-walkthrough.md) 섹션을 참조하십시오.

## S3 콘솔 사용
<a name="HowDoIWebsiteConfiguration"></a>

**정적 웹 사이트 호스팅 사용 설정**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. 버킷 목록에서 정적 웹 사이트 호스팅을 사용 설정하려는 버킷의 이름을 선택합니다.

1. [**속성(Properties)**]을 선택합니다.

1. **정적 웹 사이트 호스팅(Static website hosting)**에서 **편집(Edit)**을 선택합니다.

1. **이 버킷을 사용하여 웹 사이트를 호스팅합니다.**를 선택합니다.

1. **정적 웹 사이트 호스팅**에서 **사용**을 선택합니다.

1. **인덱스 문서(Index document)**에 인덱스 문서 이름을 입력합니다(일반적으로 `index.html`).

   인덱스 문서 이름은 대소문자를 구분하며 S3 버킷에 업로드하려는 HTML 인덱스 문서의 파일 이름과 정확히 일치해야 합니다. 웹 사이트 호스팅용 버킷을 구성하는 경우 인덱스 문서를 지정해야 합니다. 루트 도메인이나 임의의 하위 폴더로 요청이 전송되면 Amazon S3가 이 인덱스 문서를 반환합니다. 자세한 내용은 [인덱스 문서 구성](IndexDocumentSupport.md) 섹션을 참조하세요.

1. 4XX 클래스 오류에 대한 사용자 지정 오류 문서를 제공하려면 [**오류 문서(Error document)**]에 사용자 지정 오류 문서 파일 이름을 입력합니다.

   오류 문서 이름은 대소문자를 구분하며 S3 버킷에 업로드하려는 HTML 오류 문서의 파일 이름과 정확히 일치해야 합니다. 사용자 지정 오류 문서를 지정하지 않았는데 오류가 발생하면 Amazon S3에서 기본 HTML 오류 문서를 반환합니다. 자세한 내용은 [사용자 지정 오류 문서 구성](CustomErrorDocSupport.md) 섹션을 참조하세요.

1. (선택 사항) 고급 리디렉션 규칙을 지정하려면 **리디렉션 규칙(Redirection rules)**에 JSON을 입력하여 규칙을 설명합니다.

   예를 들어, 요청의 특정 객체 키 이름 또는 접두사에 따라 조건부로 요청을 라우팅할 수 있습니다. 자세한 내용은 [고급 조건부 리디렉션을 사용하도록 리디렉션 규칙 구성](how-to-page-redirect.md#advanced-conditional-redirects) 섹션을 참조하세요.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.

   Amazon S3는 버킷에 대한 정적 웹 사이트 호스팅을 지원합니다. 페이지 하단의 **정적 웹 사이트 호스팅(Static website hosting)**에 버킷의 웹 사이트 엔드포인트가 표시됩니다.

1. **정적 웹 사이트 호스팅**에서 **엔드포인트**를 기록합니다.

   **엔드포인트**는 버킷의 Amazon S3 웹 사이트 엔드포인트입니다. 버킷을 정적 웹 사이트로 구성한 후 이 엔드포인트를 사용하여 웹 사이트를 테스트할 수 있습니다.

## REST API 사용
<a name="ConfigWebSiteREST"></a>

정적 웹 사이트 호스팅을 사용 설정하기 위해 REST 요청을 직접 보내는 방법에 대한 자세한 내용은 Amazon Simple Storage Service API Reference의 다음 섹션을 참조하십시오.
+ [PUT 버킷 웹 사이트](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUTwebsite.html)
+ [GET 버킷 웹 사이트](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGETwebsite.html)
+ [DELETE 버킷 웹 사이트](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketDELETEwebsite.html)

## AWS SDK 사용
<a name="ManagingBucketWebsiteConfig"></a>

Amazon S3에서 정적 웹 사이트를 호스팅하려면 Amazon S3 버킷을 웹 사이트 호스팅용으로 구성한 후 웹 사이트 콘텐츠를 버킷에 업로드합니다. 또한 AWS SDK를 사용하여 프로그래밍 방식으로 웹 사이트 구성을 생성, 업데이트 및 삭제할 수 있습니다. SDK는 Amazon S3 REST API를 둘러싼 래퍼 클래스를 제공합니다. 애플리케이션에서 필요한 경우, 해당 애플리케이션에서 직접 REST API 요청할 수 있습니다.

------
#### [ .NET ]

다음 예제는 AWS SDK for .NET를 사용하여 버킷에 대한 웹 사이트 구성을 관리하는 방법을 보여줍니다. 버킷에 웹 사이트 구성을 추가하려면 버킷 이름 및 웹 사이트 구성을 제공해야 합니다. 웹 사이트 구성에는 인덱스 문서가 포함되어 있어야 하고 선택적 오류 문서를 포함할 수 있습니다. 이러한 문서는 버킷에 저장되어 있어야 합니다. 자세한 내용은 [PUT 버킷 웹 사이트](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUTwebsite.html)를 참조하십시오. Amazon S3 웹 사이트 기능에 대한 자세한 내용은 [Amazon S3를 사용하여 정적 웹 사이트 호스팅](WebsiteHosting.md)를 참조하십시오.

다음 C\$1 코드로 지정된 버킷에 웹 사이트 구성을 추가하는 예를 살펴봅니다. 이 구성은 인덱스 문서와 오류 문서 이름을 모두 지정합니다. 코드 예제 설정 및 실행에 대한 자세한 내용은 *AWS SDK for .NET 개발자 안내서*의 [AWS SDK for .NET 시작하기](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-setup.html)를 참조하세요.

```
using Amazon;
using Amazon.S3;
using Amazon.S3.Model;
using System;
using System.Threading.Tasks;

namespace Amazon.DocSamples.S3
{
    class WebsiteConfigTest
    {
        private const string bucketName = "*** bucket name ***";
        private const string indexDocumentSuffix = "*** index object key ***"; // For example, index.html.
        private const string errorDocument = "*** error object key ***"; // For example, error.html.
        // Specify your bucket region (an example region is shown).
        private static readonly RegionEndpoint bucketRegion = RegionEndpoint.USWest2;
        private static IAmazonS3 client;
        public static void Main()
        {
            client = new AmazonS3Client(bucketRegion);
            AddWebsiteConfigurationAsync(bucketName, indexDocumentSuffix, errorDocument).Wait();
        }

        static async Task AddWebsiteConfigurationAsync(string bucketName,
                                            string indexDocumentSuffix,
                                            string errorDocument)
        {
            try
            {
                // 1. Put the website configuration.
                PutBucketWebsiteRequest putRequest = new PutBucketWebsiteRequest()
                {
                    BucketName = bucketName,
                    WebsiteConfiguration = new WebsiteConfiguration()
                    {
                        IndexDocumentSuffix = indexDocumentSuffix,
                        ErrorDocument = errorDocument
                    }
                };
                PutBucketWebsiteResponse response = await client.PutBucketWebsiteAsync(putRequest);

                // 2. Get the website configuration.
                GetBucketWebsiteRequest getRequest = new GetBucketWebsiteRequest()
                {
                    BucketName = bucketName
                };
                GetBucketWebsiteResponse getResponse = await client.GetBucketWebsiteAsync(getRequest);
                Console.WriteLine("Index document: {0}", getResponse.WebsiteConfiguration.IndexDocumentSuffix);
                Console.WriteLine("Error document: {0}", getResponse.WebsiteConfiguration.ErrorDocument);
            }
            catch (AmazonS3Exception e)
            {
                Console.WriteLine("Error encountered on server. Message:'{0}' when writing an object", e.Message);
            }
            catch (Exception e)
            {
                Console.WriteLine("Unknown encountered on server. Message:'{0}' when writing an object", e.Message);
            }
        }
    }
}
```

------
#### [ PHP ]

다음 PHP로 지정된 버킷에 웹 사이트 구성을 추가하는 예를 살펴봅니다. `create_website_config` 메서드는 인덱스 문서와 오류 문서 이름을 명시적으로 제공합니다. 또한, 샘플이 웹 사이트 구성을 검색해 응답을 인쇄합니다. Amazon S3 웹 사이트 기능에 대한 자세한 내용은 [Amazon S3를 사용하여 정적 웹 사이트 호스팅](WebsiteHosting.md)를 참조하십시오.

AWS SDK for Ruby API에 대한 자세한 내용은 [AWS SDK for Ruby – 버전 2](https://docs.aws.amazon.com/sdkforruby/api/index.html)를 참조하세요.

```
 require 'vendor/autoload.php';

use Aws\S3\S3Client;

$bucket = '*** Your Bucket Name ***';

$s3 = new S3Client([
    'version' => 'latest',
    'region'  => 'us-east-1'
]);


// Add the website configuration.
$s3->putBucketWebsite([
    'Bucket'                => $bucket,
    'WebsiteConfiguration'  => [
        'IndexDocument' => ['Suffix' => 'index.html'],
        'ErrorDocument' => ['Key' => 'error.html']
    ]
]);

// Retrieve the website configuration.
$result = $s3->getBucketWebsite([
    'Bucket' => $bucket
]);
echo $result->getPath('IndexDocument/Suffix');

// Delete the website configuration.
$s3->deleteBucketWebsite([
    'Bucket' => $bucket
]);
```

------

## AWS CLI 사용
<a name="enabling-website-cli"></a>

AWS CLI를 사용하여 S3 버킷을 정적 웹 사이트로 구성하는 방법에 대한 자세한 내용은 *AWS CLI 명령 참조*의 [웹 사이트](https://docs.aws.amazon.com/cli/latest/reference/s3/website.html)를 참조하십시오.

그런 다음 인덱스 문서를 구성하고 권한을 설정해야 합니다. 자세한 내용은 [인덱스 문서 구성](IndexDocumentSupport.md) 및 [웹 사이트 액세스에 대한 권한 설정](WebsiteAccessPermissionsReqd.md) 섹션을 참조하십시오.

[오류 문서](CustomErrorDocSupport.md), [웹 트래픽 로깅](LoggingWebsiteTraffic.md) 또는 [리디렉션](how-to-page-redirect.md)을 선택적으로 구성할 수도 있습니다.

# 인덱스 문서 구성
<a name="IndexDocumentSupport"></a>

웹 사이트 호스팅을 사용 설정하는 경우 인덱스 문서도 구성하고 업로드해야 합니다. *인덱스 문서*는 웹 사이트의 루트나 임의의 하위 폴더로 요청이 전달되는 경우에 Amazon S3이 반환하는 웹 페이지입니다. 예를 들어, 사용자가 브라우저에 `http://www.example.com`을 입력하는 경우 사용자는 특정 페이지를 요청하는 것입니다. 이 경우 Amazon S3이 *기본 페이지*라고도 하는 인덱스 문서를 표시합니다.

버킷용 정적 웹 사이트 호스팅을 사용 설정할 때 인덱스 문서의 이름(예: `index.html`)을 입력합니다. 버킷용 정적 웹 사이트 호스팅을 사용 설정한 후 인덱스 문서 이름이 있는 HTML 파일을 버킷에 업로드합니다.

루트 수준 URL의 후행 슬래쉬는 선택 사항입니다. 예를 들어, 인덱스 문서가 `index.html`인 웹 사이트를 구성하는 경우 다음과 같은 URL 중 하나에서 `index.html`이 반환됩니다.

```
1. http://example-bucket.s3-website.Region.amazonaws.com/
2. http://example-bucket.s3-website.Region.amazonaws.com
```

Amazon S3 웹 사이트 엔드포인트에 대한 자세한 내용은 [웹 사이트 엔드포인트](WebsiteEndpoints.md) 섹션을 참조하십시오.

## 인덱스 문서 및 폴더
<a name="IndexDocumentsandFolders"></a>

Amazon S3에서 버킷은 객체의 플랫 컨테이너입니다. 버킷은 컴퓨터의 파일 시스템과 같이 계층 구조는 제공하지 않습니다. 폴더 구조를 의미하는 객체 키 이름을 사용하여 논리적 계층 구조를 만들 수 있습니다.

예를 들어, 키 이름이 다음과 같은 세 개의 객체가 있는 버킷이 있다고 생각해 보십시오. 객체가 물리적 계층 구조에 따라 저장되지는 않지만 키 이름에 비추어 논리적 폴더 구조가 다음과 같음을 유추할 수 있습니다.
+ `sample1.jpg` - 객체가 버킷의 루트에 있습니다.
+ `photos/2006/Jan/sample2.jpg` - 객체가 `photos/2006/Jan` 하위 폴더에 있습니다.
+ `photos/2006/Feb/sample3.jpg` - 객체가 `photos/2006/Feb` 하위 폴더에 있습니다.

Amazon S3 콘솔에서 버킷에 폴더를 생성할 수도 있습니다. 예를 들어 `photos`라는 폴더를 만들 수 있습니다. 이 버킷에 혹은 버킷 내부의 `photos` 폴더에 객체를 업로드할 수 있습니다. 버킷에 객체 `sample.jpg`를 추가하는 경우 키 이름은 `sample.jpg`입니다. `photos` 폴더에 객체를 업로드하는 경우 객체 키 이름은 `photos/sample.jpg`입니다.

버킷에 폴더 구조를 만드는 경우 수준별로 인덱스 문서가 있어야 합니다. 각 폴더에서 인덱스 문서의 이름은 동일해야 합니다(예: `index.html`). 사용자가 폴더 조회 URL을 지정할 때 후행 슬래시의 유무로 웹 사이트의 동작을 판단하게 됩니다. 예를 들어, 뒤에 슬래시가 있는 다음과 같은 URL은 `photos/index.html` 인덱스 문서를 반환합니다.

```
1. http://bucket-name.s3-website.Region.amazonaws.com/photos/
```

하지만 선행 URL에서 후행 슬래시를 제외하는 경우 Amazon S3은 가장 먼저 버킷의 객체 `photos`를 찾습니다. `photos` 객체를 찾을 수 없는 경우 인덱스 문서인 `photos/index.html`이 검색 대상입니다. 해당 문서를 찾은 경우 Amazon S3이 `302 Found` 메시지를 반환하고 `photos/` 키를 가리킵니다. `photos/`에 대한 후속 요청의 경우 Amazon S3이 `photos/index.html`을 반환합니다. 인덱스 문서를 찾을 수 없는 경우 Amazon S3가 오류를 반환합니다.

## 인덱스 문서 구성
<a name="configuring-index-document"></a>

S3 콘솔을 사용하여 인덱스 문서를 구성하려면 다음 절차를 사용합니다. REST API, AWS SDK, AWS CLI 또는 CloudFormation을 사용하여 인덱스 문서를 구성할 수도 있습니다.

**참고**  
버전 관리가 활성화된 버킷에서는 `index.html`의 사본을 여러 개 업로드할 수 있지만 최신 버전만 업로드할 수 있습니다. S3 버전 관리에 대한 자세한 내용은 [S3 버전 관리로 여러 버전의 객체 유지](Versioning.md) 섹션을 참조하십시오.

버킷용 정적 웹 사이트 호스팅을 사용 설정할 때 인덱스 문서의 이름(예: **index.html**)을 입력합니다. 버킷용 정적 웹 사이트 호스팅을 사용 설정한 후 인덱스 문서 이름이 있는 HTML 파일을 버킷에 업로드합니다.

**인덱스 문서 구성**

1. `index.html` 파일을 생성합니다.

   `index.html` 파일이 없으면 다음 HTML을 사용하여 파일을 생성할 수 있습니다.

   ```
   <html xmlns="http://www.w3.org/1999/xhtml" >
   <head>
       <title>My Website Home Page</title>
   </head>
   <body>
     <h1>Welcome to my website</h1>
     <p>Now hosted on Amazon S3!</p>
   </body>
   </html>
   ```

1. 인덱스 파일을 로컬에 저장합니다.

   인덱스 문서 파일 이름은 **정적 웹 사이트 호스팅** 대화 상자에 입력한 인덱스 문서 이름과 정확히 일치해야 합니다. 인덱스 문서 이름은 대/소문자를 구분합니다. 예를 들어 **정적 웹 사이트 호스팅** 대화 상자에서 **인덱스 문서** 이름에 `index.html`을 입력하는 경우, 인덱스 문서 파일은 `index.html`이 아니라 `Index.html`이어야 합니다.

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. 버킷 목록에서 정적 웹 사이트를 호스팅하는 데 사용할 버킷의 이름을 선택합니다.

1. 버킷에 정적 웹 사이트 호스팅을 사용 설정하고 인덱스 문서의 정확한 이름(예: `index.html`)을 입력합니다. 자세한 내용은 [웹 사이트 호스팅 사용 설정](EnableWebsiteHosting.md) 섹션을 참조하세요.

   정적 웹 사이트 호스팅을 사용 설정한 후 6단계로 이동합니다.

1. 버킷에 인덱스 문서를 업로드하려면 다음 중 하나를 수행합니다.
   + 인덱스 파일을 콘솔 버킷 목록으로 끌어다 놓습니다.
   + **업로드**를 선택하고 프롬프트의 메시지에 따라 인덱스 파일을 선택하고 업로드합니다.

   단계별 지침은 [객체 업로드](upload-objects.md) 섹션을 참조하세요.

1. (선택 사항) 버킷에 다른 웹 사이트 콘텐츠를 업로드합니다.

그런 다음 웹 사이트 액세스에 대한 권한을 설정해야 합니다. 자세한 정보는 [웹 사이트 액세스에 대한 권한 설정](WebsiteAccessPermissionsReqd.md) 섹션을 참조하세요.

[오류 문서](CustomErrorDocSupport.md), [웹 트래픽 로깅](LoggingWebsiteTraffic.md) 또는 [리디렉션](how-to-page-redirect.md)을 선택적으로 구성할 수도 있습니다.

# 사용자 지정 오류 문서 구성
<a name="CustomErrorDocSupport"></a>

버킷을 정적 웹 사이트로 구성한 후 오류가 발생하면 Amazon S3에서 HTML 오류 문서를 반환합니다. 선택적으로 사용자 지정 오류 문서를 사용하여 버킷을 구성하고 오류가 발생하면 Amazon S3에서 해당 문서를 반환하도록 할 수 있습니다.

**참고**  
오류가 발생할 때 일부 브라우저는 자체 오류 메시지를 표시하므로 Amazon S3이 반환하는 오류 문서는 무시됩니다. 예를 들어, HTTP 404 찾을 수 없음 오류가 발생할 때 Google Chrome은 Amazon S3이 반환하는 오류 문서를 무시하고 자체 오류 메시지를 표시할 수도 있습니다.

**Topics**
+ [Amazon S3 HTTP 응답 코드](#s3-http-error-codes)
+ [사용자 지정 오류 문서 구성](#custom-error-document)

## Amazon S3 HTTP 응답 코드
<a name="s3-http-error-codes"></a>

다음 표는 오류 발생 시 Amazon S3이 반환하는 HTTP 응답 코드의 하위 집합 목록입니다.


| HTTP 오류 코드 | 설명 | 
| --- | --- | 
| 301 Moved Permanently(301 영구 이동됨 | 사용자가 Amazon S3 웹 사이트 엔드포인트(http://s3-website.Region.amazonaws.com/)에 곧바로 요청을 보내는 경우 Amazon S3은 301 영구 이동됨 응답을 반환하고 해당 요청을 https://aws.amazon.com/s3/으로 리디렉션합니다. | 
| 302 Found(302 찾음 |  `x`의 `http://bucket-name.s3-website.Region.amazonaws.com/x` 키에 대한 요청이 후행 슬래시 없이 Amazon S3에 수신되는 경우, 키 이름이 `x`인 객체가 첫 검색 대상이 됩니다. 객체를 찾을 수 없는 경우 Amazon S3은 해당 요청이 하위 폴더 `x`에 대한 것으로 판단하므로 맨 뒤에 슬래시를 추가하여 요청을 리디렉션하고 **302 찾음**을 반환합니다.  | 
| 304 Not Modified(304 수정되지 않음 |  Amazon S3 사용자는 헤더 `If-Modified-Since`, `If-Unmodified-Since`, `If-Match` 및/또는 `If-None-Match`를 요청하여 클라이언트가 보유하는 캐시된 사본과 요청된 객체가 동일한지 확인합니다. 객체가 동일한 경우 웹 사이트 엔드포인트가 **304 Not Modified(304 수정되지 않음)** 응답을 반환합니다.  | 
| 400 Malformed Request(400 형식이 잘못된 요청 |  잘못된 리전 엔드포인트를 통해 사용자가 버킷에 액세스하려는 경우 웹 사이트 엔드포인트가 **400 Malformed Request(400 형식이 잘못된 요청)**로 응답합니다.  | 
| 403 금지됨 |  사용자 요청이 공개적으로 읽기 가능한 객체로 변환되는 경우 웹 사이트 엔드포인트가 **403 Forbidden(403 금지됨)**으로 응답합니다. 객체 소유자는 버킷 정책이나 ACL을 사용하여 객체를 공개적으로 읽기 가능하도록 설정해야 합니다.  | 
| 404 Not Found(404 찾을 수 없음 |  웹 사이트 엔드포인트가 **404 Not Found(404 찾을 수 없음)**로 응답하는 이유는 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/CustomErrorDocSupport.html) **404 Not Found(404 찾을 수 없음)**에 대해 반환되는 사용자 지정 문서를 만들 수 있습니다. 반드시 웹 사이트처럼 구성된 버킷에 문서를 업로드하고 해당 문서를 사용하는 것으로 웹 사이트 호스팅을 구성해야 합니다. Amazon S3이 URL을 객체나 인덱스 문서에 대한 요청으로 해석하는 방법에 대한 자세한 내용은 [인덱스 문서 구성](IndexDocumentSupport.md) 섹션을 참조하십시오.  | 
| 500 Service Error(500 서비스 오류 |  내부 서버 오류가 발생하는 경우 웹 사이트 엔드포인트가 **500 Service Error(500 서비스 오류)**로 응답합니다.  | 
| [503 Service Unavailable |  사용자가 요청 빈도를 줄여야 한다고 Amazon S3이 판단하는 경우 웹 사이트 엔드포인트가 **503 서비스 사용 불가**로 응답합니다.  | 

 이러한 각 오류에 대해 Amazon S3은 사전 정의된 HTML 메시지를 반환합니다. 다음은 **403 Forbidden(403 금지됨)** 요청에 대해 반환된 HTML 메시지 예입니다.

![\[403 금지됨 오류 메시지 예\]](http://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/images/WebsiteErrorExample403.png)


## 사용자 지정 오류 문서 구성
<a name="custom-error-document"></a>

버킷을 정적 웹 사이트로 구성할 때 사용자에게 친숙한 오류 메시지와 추가 도움말이 포함된 사용자 지정 오류 문서를 제공할 수 있습니다. Amazon S3은 HTTP 4XX 클래스 오류 코드에 대한 사용자 지정 오류 문서만 반환합니다.

S3 콘솔을 사용하여 사용자 지정 오류 문서를 구성하려면 아래 단계를 따릅니다. REST API, AWS SDK, AWS CLI 또는 CloudFormation을 사용하여 오류 문서를 구성할 수도 있습니다. 자세한 내용은 다음 자료를 참조하십시오.
+ *Amazon Simple Storage Service API Reference*의 [PutBucketWebsite](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketWebsite.html)
+ *CloudFormation 사용 설명서*의 [AWS::S3::Bucket WebsiteConfiguration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket-websiteconfiguration.html)
+ *AWS CLI 명령 참조*의 [put-bucket-website](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-website.html)

버킷용 정적 웹 사이트 호스팅을 사용 설정할 때 오류 문서의 이름(예: **404.html**)을 입력합니다. 버킷용 정적 웹 사이트 호스팅을 사용 설정한 후 오류 문서 이름이 있는 HTML 파일을 버킷에 업로드합니다.

**오류 문서 구성**

1. 오류 문서를 생성합니다(예: `404.html`).

1. 오류 문서 파일을 로컬에 저장합니다.

   오류 문서 이름은 대/소문자를 구분하며 정적 웹 사이트 호스팅을 사용하도록 설정할 때 입력한 이름과 정확히 일치해야 합니다. 예를 들어 **정적 웹 사이트 호스팅** 대화 상자에서 **오류 문서** 이름에 `404.html`을 입력하는 경우, 오류 문서 파일은 `404.html`이어야 합니다.

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. 버킷 목록에서 정적 웹 사이트를 호스팅하는 데 사용할 버킷의 이름을 선택합니다.

1. 버킷에 정적 웹 사이트 호스팅을 사용 설정하고 오류 문서의 정확한 이름(예: `404.html`)을 입력합니다. 자세한 내용은 [웹 사이트 호스팅 사용 설정](EnableWebsiteHosting.md) 및 [사용자 지정 오류 문서 구성](#CustomErrorDocSupport)(을)를 참조하세요.

   정적 웹 사이트 호스팅을 사용 설정한 후 6단계로 이동합니다.

1. 버킷에 오류 문서를 업로드하려면 다음 중 하나를 수행합니다.
   + 오류 문서 파일을 콘솔 버킷 목록으로 끌어다 놓습니다.
   + **업로드**를 선택하고 프롬프트의 메시지에 따라 인덱스 파일을 선택하고 업로드합니다.

   단계별 지침은 [객체 업로드](upload-objects.md) 섹션을 참조하세요.

# 웹 사이트 액세스에 대한 권한 설정
<a name="WebsiteAccessPermissionsReqd"></a>

버킷을 정적 웹 사이트로 구성할 때, 웹 사이트를 퍼블릭으로 설정하려면 퍼블릭 읽기 액세스 권한을 부여할 수 있습니다. 버킷을 공개적으로 읽기 가능하게 만들려면 버킷에 대해 퍼블릭 액세스 차단 설정을 사용 중지하고 퍼블릭 읽기 액세스 권한을 부여하는 버킷 정책을 작성해야 합니다. 버킷에 버킷 소유자가 소유하지 않은 객체가 포함되어 있는 경우 모든 사용자에게 읽기 권한을 부여하는 객체 ACL(액세스 제어 목록)을 추가해야 할 수도 있습니다.

버킷에 대한 퍼블릭 액세스 차단 설정을 비활성화하지 않으면서 웹 사이트를 퍼블릭으로 설정하려면 Amazon CloudFront 배포를 생성하여 정적 웹 사이트를 제공할 수 있습니다. 자세한 내용은 [Amazon CloudFront로 웹사이트 속도 향상](website-hosting-cloudfront-walkthrough.md) 또는 **Amazon Route 53 개발자 안내서에서 [Amazon CloudFront 배포를 사용하여 정적 웹 사이트 제공](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/getting-started-cloudfront-overview.html)을 참조하십시오.

**참고**  
웹 사이트 엔드포인트에서 사용자가 존재하지 않는 객체를 요청하는 경우, Amazon S3은 HTTP 응답 코드 `404 (Not Found)`를 반환합니다. 객체가 존재하지만 해당 객체에 대한 읽기 권한을 부여하지 않았다면 웹 사이트 엔드포인트는 HTTP 응답 코드 `403 (Access Denied)`을 반환합니다. 이 응답 코드를 사용하여 특정 객체가 존재하는지 여부를 유추할 수 있습니다. 이 동작을 원하지 않을 경우, 버킷에 웹 사이트 지원을 설정해서는 안 됩니다.

**Topics**
+ [1단계: S3 퍼블릭 액세스 차단 설정 편집](#block-public-access-static-site)
+ [2단계: 버킷 정책 추가](#bucket-policy-static-site)
+ [객체 ACL(액세스 제어 목록)](#object-acl)

## 1단계: S3 퍼블릭 액세스 차단 설정 편집
<a name="block-public-access-static-site"></a>

기존 버킷을 퍼블릭 액세스를 포함하는 정적 웹 사이트로 구성하려면 해당 버킷에 대한 퍼블릭 액세스 차단 설정을 편집해야 합니다. 계정 수준의 퍼블릭 액세스 차단 설정을 편집해야 할 수도 있습니다. Amazon S3은 버킷 수준 및 계정 수준 퍼블릭 액세스 차단 설정의 가장 제한적인 조합을 적용합니다.

예를 들어 버킷에 대한 퍼블릭 액세스는 허용하지만 계정 수준의 모든 퍼블릭 액세스는 차단하는 경우 Amazon S3에서 해당 버킷에 대한 퍼블릭 액세스를 계속 차단합니다. 이 시나리오에서는 버킷 수준 및 계정 수준의 퍼블릭 액세스 차단 설정을 편집해야 할 수도 있습니다. 자세한 내용은 [Amazon S3 스토리지에 대한 퍼블릭 액세스 차단](access-control-block-public-access.md) 섹션을 참조하세요.

기본적으로 Amazon S3은 계정 및 버킷에 대한 퍼블릭 액세스를 차단합니다. 버킷을 사용하여 정적 웹 사이트를 호스팅하려는 경우 이러한 단계를 사용하여 퍼블릭 액세스 차단 설정을 편집할 수 있습니다.

**주의**  
이러한 단계를 완료하기 전에 [Amazon S3 스토리지에 대한 퍼블릭 액세스 차단](access-control-block-public-access.md)을 검토하여 퍼블릭 액세스 허용과 관련된 위험을 이해하고 이에 동의하는지 확인합니다. 퍼블릭 액세스 차단 설정을 해제하여 버킷을 퍼블릭으로 만들면 인터넷상의 모든 사용자가 버킷에 액세스할 수 있습니다. 버킷에 대한 모든 퍼블릭 액세스를 차단하는 것이 좋습니다.

1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 정적 웹 사이트로 구성한 버킷의 이름을 선택합니다.

1. **Permissions**를 선택합니다.

1. **퍼블릭 액세스 차단(버킷 설정)(Block public access (bucket settings))**에서 **편집(Edit)**을 선택합니다.

1. ***모든* 퍼블릭 액세스 차단(Block all public access)**을 선택 취소하고 **변경 사항 저장(Save changes)**을 선택합니다.  
![\[퍼블릭 액세스 차단 버킷 설정을 보여주는 Amazon S3 콘솔.\]](http://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/images/edit-public-access-clear.png)

   Amazon S3은 버킷에 대한 퍼블릭 액세스 차단 설정을 끕니다. 정적 퍼블릭 웹 사이트를 생성하려면 버킷 정책을 추가하기 전에 계정에 대한 [퍼블릭 액세스 차단 설정을 편집](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/block-public-access-account.html)해야 할 수도 있습니다. 계정에 대한 퍼블릭 액세스 차단 설정이 현재 켜져 있는 경우 **퍼블릭 액세스 차단(버킷 설정)** 아래에 메모가 표시됩니다.

## 2단계: 버킷 정책 추가
<a name="bucket-policy-static-site"></a>

버킷의 객체를 공개적으로 읽기 가능하게 만들려면 모든 사용자에게 `s3:GetObject` 권한을 부여하는 버킷 정책을 작성해야 합니다.

S3 퍼블릭 액세스 차단 설정을 편집한 후에는 버킷 정책을 추가하여 버킷에 퍼블릭 읽기 액세스 권한을 부여할 수 있습니다. 퍼블릭 읽기 액세스 권한을 부여하면 인터넷의 모든 사용자가 버킷에 액세스할 수 있습니다.

**중요**  
다음 정책은 하나의 예일 뿐이며 버킷의 콘텐츠에 대한 전체 액세스를 허용합니다. 이 단계를 진행하기 전에 [Amazon S3 버킷에 있는 파일을 보호하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/secure-s3-resources/)를 검토하여 S3 버킷의 파일 보안을 위한 모범 사례 및 퍼블릭 액세스 권한 부여와 관련된 위험을 파악할 수 있습니다.

1. **버킷**에서 버킷의 이름을 선택합니다.

1. **Permissions**를 선택합니다.

1. **버킷 정책(Bucket Policy)**에서 **편집(Edit)**을 선택합니다.

1. 웹 사이트에 대한 퍼블릭 읽기 액세스 권한을 부여하려면 다음 버킷 정책을 복사한 후 **버킷 정책 편집기**에 붙여 넣습니다.

   ```
   {
       "Version": "2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "PublicReadGetObject",
               "Effect": "Allow",
               "Principal": "*",
               "Action": [
                   "s3:GetObject"
               ],
               "Resource": [
                   "arn:aws:s3:::Bucket-Name/*"
               ]
           }
       ]
   }
   ```

1. `Resource`를 버킷 이름으로 업데이트합니다.

   앞의 버킷 정책 예제에서 *Bucket-Name*은 버킷 이름의 자리 표시자입니다. 자체 버킷에 이 버킷 정책을 사용하려면 자체 버킷 이름과 일치하도록 이 이름을 업데이트해야 합니다.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.

   버킷 정책이 성공적으로 추가되었음을 나타내는 메시지가 나타납니다.

   `Policy has invalid resource`라는 오류가 표시되면 버킷 정책의 버킷 이름이 사용자의 버킷 이름과 일치하는지 확인합니다. 버킷 정책 추가에 대한 자세한 내용은 [S3 버킷 정책을 추가하려면 어떻게 해야 하나요?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html)를 참조하십시오.

   오류 메시지가 나타나고 버킷 정책을 저장할 수 없는 경우 계정 및 버킷의 퍼블릭 액세스 차단 설정에서 버킷에 대한 퍼블릭 액세스를 허용하는지 확인합니다.

## 객체 ACL(액세스 제어 목록)
<a name="object-acl"></a>

버킷 정책을 사용하여 객체에 퍼블릭 읽기 권한을 부여할 수 있습니다. 그러나 버킷 정책은 버킷 소유자가 소유한 객체에만 적용됩니다. 버킷에 버킷 소유자가 소유하지 않은 객체가 포함된 경우 버킷 소유자는 객체 ACL(액세스 제어 목록)을 사용하여 해당 객체에 대한 퍼블릭 읽기 권한을 부여해야 합니다.

S3 객체 소유권은 버킷에 업로드되는 객체의 소유권을 제어하고 ACL을 비활성화 또는 활성화하는 데 사용할 수 있는 Amazon S3 버킷 수준 설정입니다. 기본적으로 객체 소유권은 버킷 소유자 적용 설정으로 설정되며 모든 ACL이 비활성화되어 있습니다. ACL이 비활성화되면 버킷 소유자는 버킷의 모든 객체를 소유하고 액세스 관리 정책을 사용하여 객체에 대한 액세스를 독점적으로 관리합니다.

 Amazon S3의 최신 사용 사례 대부분은 더 이상 ACL을 사용할 필요가 없습니다. 각 객체에 대해 액세스를 개별적으로 제어할 필요가 있는 상황을 제외하고는 ACL을 비활성화한 채로 두는 것이 좋습니다. ACL을 비활성화하면 누가 객체를 버킷에 업로드했는지에 관계없이 정책을 사용하여 버킷의 모든 객체에 대한 액세스를 제어할 수 있습니다. 자세한 내용은 [객체 소유권 제어 및 버킷에 대해 ACL 사용 중지](about-object-ownership.md) 섹션을 참조하세요.

**중요**  
범용 버킷이 S3 객체 소유권에 대해 버킷 소유자 적용 설정을 사용하는 경우 정책을 사용하여 범용 버킷과 버킷의 객체에 대한 액세스 권한을 부여해야 합니다. 버킷 소유자 적용 설정이 활성화된 상태에서 액세스 제어 목록(ACL) 설정 또는 ACL 업데이트 요청은 실패하고 `AccessControlListNotSupported` 오류 코드를 반환합니다. ACL 읽기 요청은 계속 지원됩니다.

ACL을 사용하여 객체를 공개적으로 읽기 가능하게 만들려면 다음 부여 요소에 나와 있는 대로 `AllUsers` 그룹에 읽기 권한을 부여합니다. 객체 ACL에 이 부여 요소를 추가합니다. ACL 관리에 관한 자세한 내용은 [ACL(액세스 제어 목록) 개요](acl-overview.md) 섹션을 참조하십시오.

```
1. <Grant>
2.   <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3.           xsi:type="Group">
4.     <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI>
5.   </Grantee>
6.   <Permission>READ</Permission>
7. </Grant>
```

# (선택 사항) 웹 트래픽 로깅
<a name="LoggingWebsiteTraffic"></a>

선택적으로 정적 웹 사이트로 구성된 버킷에 대한 Amazon S3 서버 액세스 로깅을 사용 설정할 수 있습니다. 서버 액세스 로깅은 버킷에 대해 이루어진 요청에 따른 상세 레코드를 제공합니다. 자세한 내용은 [서버 액세스 로깅을 사용한 요청 로깅](ServerLogs.md) 섹션을 참조하세요. Amazon CloudFront를 사용하여 [웹 사이트 속도를 높이려는](website-hosting-cloudfront-walkthrough.md) 경우 CloudFront 로깅을 사용할 수도 있습니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [액세스 로그 구성 및 사용](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html)을 참조하십시오.

**정적 웹 사이트 버킷에 대한 서버 액세스 로깅 사용 설정**

1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 정적 웹 사이트로 구성된 버킷을 생성한 리전에서 로깅용 범용 버킷을 생성합니다(예: `logs.example.com`).

1. 서버 액세스 로깅 로그 파일에 대한 폴더를 생성합니다(예: `logs`).

1. (선택 사항) CloudFront를 사용하여 웹 사이트 성능을 개선하려면 CloudFront 로그 파일에 대한 폴더(예: `cdn`)를 생성합니다.

   자세한 내용은 [Amazon CloudFront로 웹사이트 속도 향상](website-hosting-cloudfront-walkthrough.md) 섹션을 참조하세요.

1. **버킷** 목록에서 버킷을 선택합니다.

1. [**속성(Properties)**]을 선택합니다.

1. **서버 액세스 로깅(Server access logging)**에서 **편집(Edit)**을 선택합니다.

1. **사용**을 선택합니다.

1. **대상 버킷(Target bucket)**에서 서버 액세스 로그의 버킷과 폴더 대상을 선택합니다.
   + 폴더 및 버킷 위치를 찾습니다.

     1. **S3 찾아보기(Browse S3)**를 선택합니다.

     1. 버킷 이름을 선택한 다음 로그 폴더를 선택합니다.

     1. **경로 선택(Choose path)**을 선택합니다.
   + S3 버킷 경로(예: **s3://logs.example.com/logs/**)를 입력합니다.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.

   이제 로그 버킷에서 로그에 액세스할 수 있습니다. Amazon S3은 2시간마다 웹 사이트 액세스 로그를 로그 버킷에 기록합니다.

# (선택 사항) 웹 페이지 리디렉션 구성
<a name="how-to-page-redirect"></a>

웹 사이트 호스팅용으로 Amazon S3 버킷이 구성된 경우 버킷 또는 버킷 내 객체에 대한 리디렉션을 구성할 수 있습니다. 리디렉션 구성에 대해 다음과 같은 옵션이 있습니다.

**Topics**
+ [버킷의 웹 사이트 엔드포인트에 대한 요청을 다른 버킷이나 도메인으로 리디렉션](#redirect-endpoint-host)
+ [고급 조건부 리디렉션을 사용하도록 리디렉션 규칙 구성](#advanced-conditional-redirects)
+ [객체에 대한 요청 리디렉션](#redirect-requests-object-metadata)

## 버킷의 웹 사이트 엔드포인트에 대한 요청을 다른 버킷이나 도메인으로 리디렉션
<a name="redirect-endpoint-host"></a>

버킷의 웹 사이트 엔드포인트에 대한 모든 요청을 다른 버킷 또는 도메인으로 리디렉션할 수 있습니다. 모든 요청을 리디렉션하면 웹 사이트 엔드포인트로 전송된 요청이 지정된 버킷 또는 도메인으로 리디렉션됩니다.

예를 들어 루트 도메인이 `example.com`이고 `http://example.com` 및 `http://www.example.com`에 대한 요청을 모두 처리할 경우, `example.com` 및 `www.example.com`이라는 이름의 버킷을 2개 만들어야 합니다. 그런 다음 `example.com` 버킷의 콘텐츠는 유지하고 다른 `www.example.com` 버킷에서 모든 요청을 `example.com` 버킷으로 리디렉션하도록 구성합니다. 자세한 내용은 [사용자 지정 도메인 이름을 사용하여 정적 웹 사이트 구성](https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html)을 참조하십시오.

**버킷 웹 사이트 엔드포인트에 대한 요청 리디렉션**

1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. **버킷(Buckets)** 아래에서 요청을 리디렉션할 버킷의 이름(예: `www.example.com`)을 선택합니다.

1. [**속성(Properties)**]을 선택합니다.

1. **정적 웹 사이트 호스팅(Static website hosting)**에서 **편집(Edit)**을 선택합니다.

1. **객체에 대한 요청 리디렉션(Redirect requests for an object)**을 선택합니다.

1. **호스트 이름(Host name)** 상자에 버킷 또는 사용자 지정 도메인의 웹 사이트 엔드포인트를 입력합니다.

   예를 들어, 루트 도메인 주소로 리디렉션하려면 **example.com**을 입력해야 합니다.

1. **프로토콜(Protocol)**에서는 리디렉션된 요청에 대한 프로토콜(**없음**, **http** 또는 **https**)을 선택합니다.

   프로토콜을 지정하지 않으면 기본 옵션은 **없음**입니다.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.

## 고급 조건부 리디렉션을 사용하도록 리디렉션 규칙 구성
<a name="advanced-conditional-redirects"></a>

어드밴스 리디렉션 규칙을 사용하면 특정 객체 키 이름, 요청 접두사 또는 응답 코드에 따라 조건부로 요청을 라우팅할 수 있습니다. 예를 들어, 버킷 내 객체를 삭제하거나 이름을 변경하는 경우를 가정해봅시다. 요청을 다른 객체에 리디렉션하는 라우팅 규칙을 추가할 수 있습니다. 폴더를 사용할 수 없게 하려면 다른 웹 페이지에 요청을 리디렉션하도록 라우팅 규칙을 추가하면 됩니다. 또한 오류를 반환하는 요청을 오류 처리 시 다른 도메인으로 라우팅하여 오류 조건을 처리하도록 라우팅 규칙을 추가할 수도 있습니다.

버킷용 정적 웹 사이트 호스팅을 사용하도록 설정할 때 고급 리디렉션 규칙을 선택적으로 지정할 수 있습니다. Amazon S3에는 웹 사이트 구성당 50개의 라우팅 규칙 제한이 있습니다. 50개 이상의 라우팅 규칙이 필요한 경우 객체 리디렉션을 사용할 수 있습니다. 자세한 내용은 [S3 콘솔 사용](#page-redirect-using-console) 섹션을 참조하세요.

REST API를 사용하여 라우팅 규칙을 구성하는 방법에 대한 자세한 내용은 *Amazon Simple Storage Service API 참조*에서 [PutBucketWebsite](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketWebsite.html)를 참조하십시오.

**중요**  
새 Amazon S3 콘솔에서 리디렉션 규칙을 생성하려면 JSON을 사용해야 합니다. JSON 예제는 [리디렉션 규칙 예제](#redirect-rule-examples) 섹션을 참조하세요.

**정적 웹 사이트에 대한 리디렉션 규칙 구성**

정적 웹 사이트 호스팅이 이미 사용 설정되어 있는 버킷에 대한 리디렉션 규칙을 추가하려면 다음 단계를 따르십시오.

1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. 버킷 목록에서 정적 웹 사이트로 구성한 버킷의 이름을 선택합니다.

1. [**속성(Properties)**]을 선택합니다.

1. **정적 웹 사이트 호스팅(Static website hosting)**에서 **편집(Edit)**을 선택합니다.

1. **리디렉션 규칙(Redirection rules)** 상자에서 JSON에 리디렉션 규칙을 입력합니다.

   S3 콘솔에서는 JSON을 사용하여 규칙을 설명합니다. JSON 예제는 [리디렉션 규칙 예제](#redirect-rule-examples) 섹션을 참조하세요. Amazon S3에는 웹 사이트 구성당 50개의 라우팅 규칙 제한이 있습니다.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.

### 라우팅 규칙 요소
<a name="configure-bucket-as-website-routing-rule-syntax"></a>

다음은 JSON 및 XML의 웹 사이트 구성에서 라우팅 규칙을 정의하기 위한 일반 구문입니다. 새 S3 콘솔에서 리디렉션 규칙을 구성하려면 JSON을 사용해야 합니다. JSON 예제는 [리디렉션 규칙 예제](#redirect-rule-examples) 섹션을 참조하십시오.

------
#### [ JSON ]

```
[
    {
      "Condition": {
        "HttpErrorCodeReturnedEquals": "string",
        "KeyPrefixEquals": "string"
      },
      "Redirect": {
        "HostName": "string",
        "HttpRedirectCode": "string",
        "Protocol": "http"|"https",
        "ReplaceKeyPrefixWith": "string",
        "ReplaceKeyWith": "string"
      }
    }
  ]
 
Note: Redirect must each have at least one child element. You can have either ReplaceKeyPrefix with or ReplaceKeyWith but not both.
```

------
#### [ XML ]

```
<RoutingRules> =
    <RoutingRules>
         <RoutingRule>...</RoutingRule>
         [<RoutingRule>...</RoutingRule>   
         ...]
    </RoutingRules>

<RoutingRule> =
   <RoutingRule>
      [ <Condition>...</Condition> ]
      <Redirect>...</Redirect>
   </RoutingRule>

<Condition> =
   <Condition> 
      [ <KeyPrefixEquals>...</KeyPrefixEquals> ]
      [ <HttpErrorCodeReturnedEquals>...</HttpErrorCodeReturnedEquals> ]
   </Condition>
    Note: <Condition> must have at least one child element.

<Redirect> =
   <Redirect> 
      [ <HostName>...</HostName> ]
      [ <Protocol>...</Protocol> ]
      [ <ReplaceKeyPrefixWith>...</ReplaceKeyPrefixWith>  ]
      [ <ReplaceKeyWith>...</ReplaceKeyWith> ]
      [ <HttpRedirectCode>...</HttpRedirectCode> ]
   </Redirect>

Note: <Redirect> must have at least one child element. You can have either ReplaceKeyPrefix with or ReplaceKeyWith but not both.
```

------

다음 표에서는 라우팅 규칙 요소를 설명합니다.


|  이름  |  설명  | 
| --- | --- | 
| RoutingRules |  RoutingRule 요소 모음용 컨테이너입니다. | 
| RoutingRule |  조건 및 조건이 충족되었을 때 적용되는 리디렉션을 식별하는 규칙입니다. 조건: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/how-to-page-redirect.html)  | 
| Condition |  지정된 리디렉션이 적용되려면 충족되어야 할 조건을 설명하기 위한 컨테이너입니다. 라우팅 규칙이 조건을 포함하지 않는 경우 해당 규칙은 모든 요청에 적용됩니다.  | 
| KeyPrefixEquals |  리디렉션된 요청을 보내는 객체 키 이름 접두사입니다. `KeyPrefixEquals` `HttpErrorCodeReturnedEquals`를 지정하지 않을 경우 가 필요합니다. `KeyPrefixEquals` 및 `HttpErrorCodeReturnedEquals`가 모두 지정되는 경우 두 항목 모두 true로 설정되어야 조건이 충족됩니다.  | 
| HttpErrorCodeReturnedEquals |  리디렉션 적용 조건과 일치하는 HTTP 오류 코드입니다. 오류가 발생하고 오류 코드가 이 값에 해당하는 경우, 지정된 리디렉션이 적용됩니다. `HttpErrorCodeReturnedEquals` `KeyPrefixEquals`를 지정하지 않을 경우 가 필요합니다. `KeyPrefixEquals` 및 `HttpErrorCodeReturnedEquals`가 모두 지정되는 경우 두 항목 모두 true로 설정되어야 조건이 충족됩니다.  | 
| Redirect |  요청에 대한 리디렉션 지침을 제공하는 컨테이너 요소입니다. 다른 호스트나 다른 페이지로 요청을 리디렉션할 수 있으며, 사용할 다른 프로토콜을 지정할 수 있습니다. `RoutingRule`에는 `Redirect` 요소가 있어야 합니다. `Redirect` 요소는 `Protocol`, `HostName`, `ReplaceKeyPrefixWith`, `ReplaceKeyWith` 또는 `HttpRedirectCode` 중 한 개 이상의 형제 요소를 포함해야 합니다.  | 
| Protocol |  응답에서 반환된 `http` 헤더에 사용할 `https` 또는 `Location` 프로토콜입니다. 해당 형제 요소 중 하나가 제공되는 경우 `Protocol`는 필요하지 않습니다.  | 
| HostName |  응답에서 반환된 `Location` 헤더에 사용할 호스트 이름입니다. 해당 형제 요소 중 하나가 제공되는 경우 `HostName`는 필요하지 않습니다.  | 
| ReplaceKeyPrefixWith |  리디렉션 요청의 `KeyPrefixEquals` 값을 대체하는 객체 키 이름의 접두사입니다. 해당 형제 요소 중 하나가 제공되는 경우 `ReplaceKeyPrefixWith`는 필요하지 않습니다. `ReplaceKeyWith`가 제공되지 않는 경우에만 제공 가능한 파라미터입니다.  | 
| ReplaceKeyWith |  응답에서 반환된 `Location` 헤더에 사용할 객체 키입니다. 해당 형제 요소 중 하나가 제공되는 경우 `ReplaceKeyWith`는 필요하지 않습니다. `ReplaceKeyPrefixWith`가 제공되지 않는 경우에만 제공 가능한 파라미터입니다.  | 
| HttpRedirectCode |  응답에서 반환된 `Location` 헤더에 사용할 HTTP 리디렉션 코드입니다. 해당 형제 요소 중 하나가 제공되는 경우 `HttpRedirectCode`는 필요하지 않습니다.  | 

#### 리디렉션 규칙 예제
<a name="redirect-rule-examples"></a>

다음 예제는 다음과 같은 일반적인 리디렉션 작업을 설명합니다.

**중요**  
새 Amazon S3 콘솔에서 리디렉션 규칙을 생성하려면 JSON을 사용해야 합니다.

**Example 1: 키 접두사 이름을 바꾼 후 리디렉션**  
버킷에 다음과 같은 객체가 포함되어 있다고 가정해 보십시오.  
+ index.html
+ docs/article1.html
+ docs/article2.html
해당 폴더의 이름을 `docs/`에서 `documents/`로 바꾸기로 합니다. 이렇게 이름을 변경한 후에는 접두사에 대한 요청을 `docs/`에서 `documents/`로 리디렉션해야 합니다. 예를 들어, `docs/article1.html`에 대한 요청은 `documents/article1.html`로 리디렉션됩니다.  
이 경우 웹 사이트 구성에 다음 라우팅 규칙을 추가합니다.  

```
[
    {
        "Condition": {
            "KeyPrefixEquals": "docs/"
        },
        "Redirect": {
            "ReplaceKeyPrefixWith": "documents/"
        }
    }
]
```

```
  <RoutingRules>
    <RoutingRule>
    <Condition>
      <KeyPrefixEquals>docs/</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <ReplaceKeyPrefixWith>documents/</ReplaceKeyPrefixWith>
    </Redirect>
    </RoutingRule>
  </RoutingRules>
```

**Example 2: 삭제된 폴더에 대한 요청을 페이지로 리디렉션**  
`images/` 폴더를 삭제한다고 가정해 보십시오(즉, 키 접두사가 `images/`인 모든 객체를 삭제). 키 접두사가 `images/`인 객체에 대한 요청을 `folderdeleted.html`라는 이름의 페이지로 리디렉션하는 라우팅 규칙을 추가할 수 있습니다.  

```
[
    {
        "Condition": {
            "KeyPrefixEquals": "images/"
        },
        "Redirect": {
            "ReplaceKeyWith": "folderdeleted.html"
        }
    }
]
```

```
  <RoutingRules>
    <RoutingRule>
    <Condition>
       <KeyPrefixEquals>images/</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <ReplaceKeyWith>folderdeleted.html</ReplaceKeyWith>
    </Redirect>
    </RoutingRule>
  </RoutingRules>
```

**Example 3: 특정 경로가 있는 다른 도메인으로 리디렉션**  
특정 경로에 대한 요청을 다른 도메인으로 리디렉션하려는 경우를 가정해 보겠습니다. 예를 들어 `/redirect/me`에 대한 요청을 `https://example.com/new/path`로 리디렉션하려고 합니다.  
`HostName` 및 `ReplaceKeyWith`를 함께 사용하는 경우 Amazon S3는 호스트 이름과 대체 키 사이에 슬래시를 추가하여 리디렉션 URL을 구성합니다. 따라서 `ReplaceKeyWith` 값에 선행 슬래시를 포함하면 안 됩니다. Amazon S3는 호스트 이름과 대체 키 사이에 슬래시를 자동으로 추가합니다.  

```
[
    {
        "Condition": {
            "KeyPrefixEquals": "redirect/me"
        },
        "Redirect": {
            "HostName": "example.com",
            "ReplaceKeyWith": "new/path"
        }
    }
]
```

```
  <RoutingRules>
    <RoutingRule>
    <Condition>
      <KeyPrefixEquals>redirect/me</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <HostName>example.com</HostName>
      <ReplaceKeyWith>new/path</ReplaceKeyWith>
    </Redirect>
    </RoutingRule>
  </RoutingRules>
```
이 구성은 `https://yourbucket.s3-website-region.amazonaws.com/redirect/me`에 대한 요청을 `https://example.com/new/path`로 리디렉션합니다. `ReplaceKeyWith`는 선행 슬래시 없이 `new/path`로 설정되어 있습니다.

**Example 4: HTTP 오류에 대한 리디렉션**  
요청된 객체를 찾을 수 없는 경우 요청을 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스로 리디렉션하려고 한다고 가정합니다. HTTP 상태 코드 404(찾을 수 없음)가 반환되는 경우 해당 요청을 처리하는 Amazon EC2 인스턴스로 사이트 방문자가 리디렉션되도록 리디렉션 규칙을 추가합니다.  
또한, 다음 예제에서는 리디렉션에서 객체 키 접두사 `report-404/`의 삽입을 설명합니다. 예를 들어, `ExamplePage.html` 페이지를 요청했지만 HTTP 404 오류가 반환되는 경우, 해당 요청은 지정된 Amazon EC2 인스턴스의 `report-404/ExamplePage.html` 페이지로 리디렉션됩니다. 라우팅 규칙이 하나도 없고 HTTP 오류 404가 발생하는 경우, 구성에 지정된 오류 문서가 반환됩니다.  

```
[
    {
        "Condition": {
            "HttpErrorCodeReturnedEquals": "404"
        },
        "Redirect": {
            "HostName": "ec2-11-22-333-44.compute-1.amazonaws.com",
            "ReplaceKeyPrefixWith": "report-404/"
        }
    }
]
```

```
  <RoutingRules>
    <RoutingRule>
    <Condition>
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals >
    </Condition>
    <Redirect>
      <HostName>ec2-11-22-333-44.compute-1.amazonaws.com</HostName>
      <ReplaceKeyPrefixWith>report-404/</ReplaceKeyPrefixWith>
    </Redirect>
    </RoutingRule>
  </RoutingRules>
```

## 객체에 대한 요청 리디렉션
<a name="redirect-requests-object-metadata"></a>

객체의 메타데이터에 웹 사이트 리디렉션 위치를 설정하여 객체에 대한 요청을 다른 객체 또는 URL로 리디렉션할 수 있습니다. 객체 메타데이터에 `x-amz-website-redirect-location` 속성을 추가하여 리디렉션을 설정할 수 있습니다. Amazon S3 콘솔에서 객체의 메타데이터에 **웹 사이트 리디렉션 위치**를 설정합니다. [Amazon S3 API](#page-redirect-using-rest-api)를 사용하는 경우 `x-amz-website-redirect-location`을 설정합니다. 이 경우 웹 사이트가 해당 객체를 301 리디렉션으로 해석합니다.

다른 객체로 요청을 리디렉션하려면 대상 객체의 키에 이르도록 리디렉션 위치를 설정합니다. 외부 URL로 요청을 리디렉션하려면 리디렉션 위치를 원하는 URL로 설정합니다. 객체 메타데이터에 대한 자세한 정보는 [시스템 정의 객체 메타데이터](UsingMetadata.md#SysMetadata) 섹션을 참조하십시오.

페이지 리디렉션을 설정하는 경우 원본 객체 콘텐츠를 유지하거나 삭제할 수 있습니다. 예를 들어 버킷에 `page1.html` 객체가 있는 경우 이 페이지에 대한 모든 요청을 다른 객체 `page2.html`로 리디렉션할 수 있습니다. 여기에는 두 가지 옵션이 있습니다.
+ `page1.html` 객체의 내용을 유지하고 페이지 요청을 리디렉션합니다.
+ `page1.html`의 내용을 삭제하고 `page1.html`라는 0바이트 객체를 업로드하여 기존 객체를 대체하고 페이지 요청을 리디렉션합니다.

### S3 콘솔 사용
<a name="page-redirect-using-console"></a>

1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. **버킷(Buckets)** 목록에서 정적 웹 사이트로 구성한 버킷의 이름(예: `example.com`)을 선택합니다.

1. **객체(Objects)**에서 객체를 선택합니다.

1. **작업(Actions)**을 선택하고 **메타데이터 편집(Edit metadata)**을 선택합니다.

1. **메타데이터**를 선택합니다.

1. **메타데이터 추가(Add Metadata)**를 선택합니다.

1. **유형(Type)**에서 **시스템 정의(System Defined)**를 선택합니다.

1. **키(Key)**에서 **x-amz-website-redirect-location**을 선택합니다.

1. **값**에 리디렉션할 객체의 키 이름(예: `/page2.html`)을 입력합니다.

   같은 버킷에 있는 다른 객체의 경우 값의 `/` 접두사가 필요합니다. 또한 이 값을 외부 URL에 설정할 수 있습니다(예: `http://www.example.com`).

1. **메타데이터 편집(Edit metadata)**을 선택합니다.

### REST API 사용
<a name="page-redirect-using-rest-api"></a>

다음 Amazon S3 API 작업은 요청의 `x-amz-website-redirect-location` 헤더를 지원합니다. Amazon S3은 객체 메타데이터의 헤더 값을 `x-amz-website-redirect-location`으로 저장합니다.
+ [PUT Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html)
+ [멀티파트 업로드 시작](https://docs.aws.amazon.com/AmazonS3/latest/API/mpUploadInitiate.html)
+ [POST Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPOST.html)
+ [PUT Object - Copy](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html)

웹 사이트 호스팅용으로 구성된 버킷은 웹 사이트 엔드포인트와 REST 엔드포인트를 모두 포함합니다. 301 리디렉션으로 구성된 페이지에 대한 요청은 요청의 엔드포인트에 따라 요청 결과가 다음과 같을 수 있습니다.
+ **리전별 웹 사이트 엔드포인트 - **Amazon S3이 `x-amz-website-redirect-location` 속성 값에 따라 페이지 요청을 리디렉션합니다.
+ **REST 엔드포인트 - **Amazon S3이 페이지 요청을 리디렉션하지 않습니다. 이 경우 요청된 객체가 반환됩니다.

엔드포인트에 대한 자세한 내용은 [웹 사이트 엔드포인트와 REST API 엔드포인트 간의 주요 차이점](WebsiteEndpoints.md#WebsiteRestEndpointDiff) 섹션을 참조하십시오.

페이지 리디렉션을 설정하는 경우 객체 콘텐츠를 유지하거나 삭제할 수 있습니다. 예를 들면, 버킷에 `page1.html` 객체가 있다고 가정해 보십시오.
+ `page1.html`의 콘텐츠를 유지하고 페이지 요청만 리디렉션하려는 경우 [PUT Object - Copy](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html) 요청을 제출하면 기존 `page1.html` 객체를 원본으로 사용하는 새 `page1.html` 객체를 생성할 수 있습니다. 해당 요청에는 `x-amz-website-redirect-location` 헤더를 설정합니다. 요청이 완료되면 콘텐츠가 변경되지 않은 원래 페이지가 생기지만 사용자가 지정한 리디렉션 위치로 Amazon S3이 해당 페이지에 대한 모든 요청을 리디렉션합니다.
+ `page1.html` 객체의 콘텐츠를 삭제하고 해당 페이지에 대한 요청을 리디렉션하려는 경우 PUT Object 요청을 보내면 객체 키가 같은 0바이트 객체인 `page1.html`을 업로드할 수 있습니다. PUT 요청에서 새 객체에 `x-amz-website-redirect-location`의 `page1.html`을 설정합니다. 요청이 완료되면 `page1.html`은 콘텐츠가 없어지고 `x-amz-website-redirect-location`에 따라 지정된 위치로 요청이 리디렉션됩니다.

[GET Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html) 작업을 사용하여 다른 객체 메타데이터와 함께 객체를 검색하는 경우 Amazon S3이 해당 응답의 `x-amz-website-redirect-location` 헤더를 반환합니다.

# 교차 오리진 리소스 공유(CORS) 사용
<a name="cors"></a>

CORS(Cross-origin 리소스 공유)는 한 도메인에서 로드되어 다른 도메인에 있는 리소스와 상호 작용하는 클라이언트 웹 애플리케이션에 대한 방법을 정의합니다. CORS 지원을 통해 Amazon S3으로 다양한 기능의 클라이언트 측 웹 애플리케이션을 구축하고, Amazon S3 리소스에 대한 Cross-Origin 액세스를 선택적으로 허용할 수 있습니다.

이 섹션에서는 CORS 개요를 다룹니다. 하위 섹션에서는 Amazon S3 콘솔을 사용하거나 프로그래밍 방식으로 Amazon S3 REST API 및 AWS SDK를 사용하여 CORS를 사용하는 방법을 설명합니다.

## CORS(Cross-Origin Resource Sharing): 사용 사례 시나리오
<a name="example-scenarios-cors"></a>

다음은 CORS 사용에 대한 예제 시나리오입니다.

**시나리오 1**  
`website`에서 설명한 대로 [Amazon S3를 사용하여 정적 웹 사이트 호스팅](WebsiteHosting.md)라는 이름의 Amazon S3 버킷에서 웹 사이트를 호스팅한다고 가정해 보겠습니다. 사용자는 웹 사이트 엔드포인트를 로드합니다.

```
http://website.s3-website.us-east-1.amazonaws.com
```

이제 이 버킷에 저장된 웹 페이지의 JavaScript를 사용하여, `website.s3.us-east-1.amazonaws.com` 버킷에 대한 Amazon S3의 API 엔드포인트를 사용하여 같은 버킷에 대해 GET 및 PUT 요청 인증을 가능하게 하려고 합니다. 일반적으로 브라우저에서 이러한 요청을 허용하지 못하도록 JavaScript를 차단하지만, CORS를 사용하여 `website.s3-website.us-east-1.amazonaws.com`으로부터의 cross-origin 요청을 사용 설정하도록 버킷을 구성할 수 있습니다.

**시나리오 2**  
S3 버킷에서 웹 글꼴을 호스팅한다고 가정해 보겠습니다. 브라우저는 웹 글꼴을 불러오기 위해 CORS 검사(preflight check라고도 함)가 필요하므로, 이 웹 글꼴을 호스팅하는 버킷이 이러한 요청을 하는 오리진을 허용하도록 구성합니다.

## Amazon S3은 버킷의 CORS 구성을 어떻게 평가하나요?
<a name="cors-eval-criteria"></a>

Amazon S3이 브라우저에서 preflight 요청을 받으면 버킷에 대한 CORS 구성을 평가하고 수신된 브라우저 요청과 일치하는 첫 번째 `CORSRule` 규칙을 사용하여 Cross-Origin 요청을 허용합니다. 규칙이 일치하려면 다음 조건이 충족되어야 합니다.
+ 버킷에 대한 CORS 요청의 `Origin` 헤더는 CORS 구성의 `AllowedOrigins` 요소에 있는 오리진과 일치해야 합니다.
+ 버킷에 대한 CORS 요청의 `Access-Control-Request-Method`에 지정된 HTTP 메서드는 CORS 구성의 `AllowedMethods` 요소에 나열된 메서드와 일치해야 합니다.
+ 사전 요청의 `Access-Control-Request-Headers` 헤더에 나열된 헤더는 CORS 구성의 `AllowedHeaders` 요소에 있는 헤더와 일치해야 합니다.

**참고**  
버킷에 대해 CORS를 허용하면 ACL과 정책이 계속 적용됩니다.

## 객체 Lambda 액세스 포인트가 CORS를 지원하는 방법
<a name="cors-olap-cors"></a>

브라우저로부터 요청을 받거나 요청에 `Origin` 헤더가 포함된 경우 S3 Object Lambda는 항상 `"AllowedOrigins":"*"` 헤더 필드를 추가합니다.

CORS 사용에 대한 자세한 내용은 다음 주제를 참조하십시오.

**Topics**
+ [CORS(Cross-Origin Resource Sharing): 사용 사례 시나리오](#example-scenarios-cors)
+ [Amazon S3은 버킷의 CORS 구성을 어떻게 평가하나요?](#cors-eval-criteria)
+ [객체 Lambda 액세스 포인트가 CORS를 지원하는 방법](#cors-olap-cors)
+ [CORS 구성의 요소](ManageCorsUsing.md)
+ [교차 오리진 리소스 공유(CORS) 구성](enabling-cors-examples.md)
+ [CORS 테스트](testing-cors.md)
+ [CORS 문제 해결](cors-troubleshooting.md)

# CORS 구성의 요소
<a name="ManageCorsUsing"></a>

Cross-Origin 요청을 허용하도록 버킷을 구성하려면 CORS 구성을 생성합니다. CORS 구성은 버킷에 액세스할 수 있도록 허용할 오리진, 각 오리진에 대해 지원되는 작업(HTTP 메서드) 및 기타 작업별 정보를 식별하는 요소가 포함된 문서입니다. 구성당 최대 100개의 규칙을 추가할 수 있습니다. CORS 구성을 `cors` 하위 리소스로 버킷에 추가할 수 있습니다.

S3 콘솔에서 CORS를 구성하는 경우 JSON을 사용하여 CORS 구성을 생성해야 합니다. 새로운 S3 콘솔은 JSON CORS 구성만 지원합니다.

CORS 구성 및 구성 내 요소에 대한 자세한 내용은 아래 주제를 참조하십시오. CORS 구성을 추가하는 방법에 대한 지침은 [교차 오리진 리소스 공유(CORS) 구성](enabling-cors-examples.md) 섹션을 참조하십시오.

**중요**  
S3 콘솔에서 CORS 구성은 JSON이어야 합니다.

**Topics**
+ [`AllowedMethods` 요소](#cors-allowed-methods)
+ [`AllowedOrigins` 요소](#cors-allowed-origin)
+ [`AllowedHeaders` 요소](#cors-allowed-headers)
+ [`ExposeHeaders` 요소](#cors-expose-headers)
+ [`MaxAgeSeconds` 요소](#cors-max-age)
+ [CORS 구성의 예](#cors-example-1)

## `AllowedMethods` 요소
<a name="cors-allowed-methods"></a>

CORS 구성에서 `AllowedMethods` 요소에 대한 다음 값을 지정할 수 있습니다.
+ GET
+ PUT
+ POST
+ DELETE
+ HEAD

## `AllowedOrigins` 요소
<a name="cors-allowed-origin"></a>

`AllowedOrigins` 요소에 교차 도메인 요청을 허용하려는 오리진을 지정합니다(예: ` http://www.example.com`). 오리진 문자열에는 `*` 와일드 문자 한 개만 포함할 수 있습니다(예: `http://*.example.com`). `*`를 모든 오리진이 교차 오리진 요청을 보낼 수 있는 오리진으로 지정할 수도 있습니다. 또한 `https`를 지정하여 안전한 오리진만 허용할 수도 있습니다.

## `AllowedHeaders` 요소
<a name="cors-allowed-headers"></a>

`AllowedHeaders` 요소는 `Access-Control-Request-Headers` 헤더를 통해 preflight 요청에 허용되는 헤더를 지정합니다. `Access-Control-Request-Headers` 헤더의 각 헤더 이름은 요소의 해당 항목과 일치해야 합니다. Amazon S3은 요청된 응답에서 허용된 헤더만을 보냅니다. Amazon S3에 대한 요청에 사용할 수 있는 샘플 헤더 목록을 보려면 *Amazon Simple Storage Service API 참조* 가이드의 [공통 요청 헤더](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.html)를 참조하십시오.

구성의 각 AllowedHeaders 문자열에는 최대 한 개의 \$1 와일드카드 문자를 포함할 수 있습니다. 예를 들어, `<AllowedHeader>x-amz-*</AllowedHeader>`는 모든 Amazon별 헤더를 허용합니다.

## `ExposeHeaders` 요소
<a name="cors-expose-headers"></a>

각 `ExposeHeader` 요소는 응답에서 고객이 해당 애플리케이션(예: JavaScript `XMLHttpRequest` 객체)으로부터 액세스할 수 있도록 하려는 헤더를 식별합니다. 공통 Amazon S3 응답 헤더 목록을 보려면 *Amazon Simple Storage Service API 참조* 가이드의 [공통 응답 헤더](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonResponseHeaders.html)를 참조하십시오.

## `MaxAgeSeconds` 요소
<a name="cors-max-age"></a>

`MaxAgeSeconds` 요소는 브라우저가 리소스, HTTP 메서드, 오리진으로 식별되는 preflight 요청에 대한 응답을 캐시할 수 있는 시간(초)을 지정합니다.

## CORS 구성의 예
<a name="cors-example-1"></a>

Amazon S3 웹 사이트 엔드포인트를 사용하여 웹 사이트에 액세스하는 대신, `example1.com`과 같은 자체 도메인을 사용하여 콘텐츠를 제공할 수 있습니다. 자체 도메인 사용에 대한 자세한 내용은 [자습서: Route 53에 등록된 사용자 지정 도메인을 사용하여 정적 웹 사이트 구성](website-hosting-custom-domain-walkthrough.md) 섹션을 참조하세요.

다음 예시 CORS 구성에는 `CORSRule` 요소로 지정된 규칙이 3개 있습니다.
+ 첫 번째 규칙은 `http://www.example1.com` 오리진에서 cross-origin PUT, POST, DELETE 요청을 허용합니다. 이 규칙은 또한 `Access-Control-Request-Headers` 헤더를 통해 preflight OPTIONS 요청의 모든 헤더를 허용합니다. Amazon S3은 preflight OPTIONS 요청에 대한 응답으로 요청된 헤더를 반환합니다.
+ 두 번째 규칙은 첫 번째 규칙과 같이 cross-origin 요청을 허용하지만 다른 오리진인 `http://www.example2.com`에 적용됩니다.
+ 세 번째 규칙은 모든 오리진에서 cross-origin GET 요청을 허용합니다. `*` 와일드카드 문자는 모든 오리진을 나타냅니다.

------
#### [ JSON ]

```
[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "PUT",
            "POST",
            "DELETE"
        ],
        "AllowedOrigins": [
            "http://www.example1.com"
        ],
        "ExposeHeaders": []
    },
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "PUT",
            "POST",
            "DELETE"
        ],
        "AllowedOrigins": [
            "http://www.example2.com"
        ],
        "ExposeHeaders": []
    },
    {
        "AllowedHeaders": [],
        "AllowedMethods": [
            "GET"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": []
    }
]
```

------
#### [ XML ]

```
<CORSConfiguration>
 <CORSRule>
   <AllowedOrigin>http://www.example1.com</AllowedOrigin>

   <AllowedMethod>PUT</AllowedMethod>
   <AllowedMethod>POST</AllowedMethod>
   <AllowedMethod>DELETE</AllowedMethod>

   <AllowedHeader>*</AllowedHeader>
 </CORSRule>
 <CORSRule>
   <AllowedOrigin>http://www.example2.com</AllowedOrigin>

   <AllowedMethod>PUT</AllowedMethod>
   <AllowedMethod>POST</AllowedMethod>
   <AllowedMethod>DELETE</AllowedMethod>

   <AllowedHeader>*</AllowedHeader>
 </CORSRule>
 <CORSRule>
   <AllowedOrigin>*</AllowedOrigin>
   <AllowedMethod>GET</AllowedMethod>
 </CORSRule>
</CORSConfiguration>
```

------

CORS 구성은 다음에서 볼 수 있듯이 선택적인 구성 파라미터도 허용합니다. 이 예제에서 CORS 구성은 `http://www.example.com` 오리진으로부터의 cross-origin PUT, POST 및 DELETE 요청을 허용합니다.

------
#### [ JSON ]

```
[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "PUT",
            "POST",
            "DELETE"
        ],
        "AllowedOrigins": [
            "http://www.example.com"
        ],
        "ExposeHeaders": [
            "x-amz-server-side-encryption",
            "x-amz-request-id",
            "x-amz-id-2"
        ],
        "MaxAgeSeconds": 3000
    }
]
```

------
#### [ XML ]

```
<CORSConfiguration>
 <CORSRule>
   <AllowedOrigin>http://www.example.com</AllowedOrigin>
   <AllowedMethod>PUT</AllowedMethod>
   <AllowedMethod>POST</AllowedMethod>
   <AllowedMethod>DELETE</AllowedMethod>
   <AllowedHeader>*</AllowedHeader>
  <MaxAgeSeconds>3000</MaxAgeSeconds>
  <ExposeHeader>x-amz-server-side-encryption</ExposeHeader>
  <ExposeHeader>x-amz-request-id</ExposeHeader>
  <ExposeHeader>x-amz-id-2</ExposeHeader>
 </CORSRule>
</CORSConfiguration>
```

------

이전 구성에서 `CORSRule` 요소는 다음의 선택적 요소를 포함합니다.
+ `MaxAgeSeconds` - 브라우저가 지정된 리소스에 대한 Amazon S3 preflight OPTIONS 요청 응답을 캐시하는 시간을 초 단위(이 예에서는 3000)로 지정합니다. 원래 요청이 반복될 경우, 브라우저는 이 응답을 캐시함으로써 Amazon S3에 preflight 요청을 보낼 필요가 없습니다.
+ `ExposeHeaders` - 고객이 자체 애플리케이션(예: JavaScript `x-amz-server-side-encryption` 객체)에서 액세스할 수 있는 응답 헤더(이 예에서는 `x-amz-request-id`, `x-amz-id-2`, `XMLHttpRequest`)를 식별합니다.

# 교차 오리진 리소스 공유(CORS) 구성
<a name="enabling-cors-examples"></a>

CORS(Cross-origin 리소스 공유)는 한 도메인에서 로드되어 다른 도메인에 있는 리소스와 상호 작용하는 클라이언트 웹 애플리케이션에 대한 방법을 정의합니다. CORS 지원을 통해 Amazon S3으로 다양한 기능의 클라이언트 측 웹 애플리케이션을 구축하고, Amazon S3 리소스에 대한 Cross-Origin 액세스를 선택적으로 허용할 수 있습니다.

이 섹션에서는 Amazon S3 콘솔, Amazon S3 REST API 및 AWS SDK를 사용하여 CORS를 사용하는 방법을 보여줍니다. 교차 오리진 요청을 허용하도록 버킷을 구성하려면 해당 버킷에 CORS 구성을 추가합니다. CORS 구성은 버킷에 대한 액세스를 허용할 오리진과 각 오리진에 대해 지원되는 작업(HTTP 메서드) 그리고 기타 작업별 정보를 각각 식별하는 규칙과 기타 작업별 정보를 포함하는 문서입니다. S3 콘솔에서 CORS 구성은 JSON 문서여야 합니다.

JSON 및 XML의 CORS 구성 예제는 [CORS 구성의 요소](ManageCorsUsing.md) 섹션을 참조하십시오.

## S3 콘솔 사용
<a name="add-cors-configuration"></a>

이 섹션에서는 Amazon S3 콘솔을 사용하여 S3 버킷에 CORS(Cross-Origin 리소스 공유) 구성을 추가하는 방법을 설명합니다.

버킷에 대해 CORS를 사용 설정하면 ACL(액세스 제어 목록)과 기타 액세스 권한 정책이 계속 적용됩니다.

**중요**  
S3 콘솔에서 CORS 구성은 JSON이어야 합니다. JSON 및 XML의 CORS 구성 예제는 [CORS 구성의 요소](ManageCorsUsing.md) 섹션을 참조하십시오.

**S3 버킷에 CORS 구성 추가**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. 버킷 목록에서 버킷 정책을 만들 버킷의 이름을 선택합니다.

1. **Permissions**를 선택합니다.

1. **CORS(Cross-Origin 리소스 공유)** 섹션에서 **편집**을 선택합니다.

1. **CORS 구성 편집기** 텍스트 상자에 새 CORS 구성을 입력하거나 복사하여 붙여넣거나, 기존 구성을 편집합니다.

   CORS 구성은 JSON 파일입니다. 편집기에 입력하는 텍스트는 유효한 JSON이어야 합니다. 자세한 내용은 [CORS 구성의 요소](ManageCorsUsing.md) 섹션을 참조하세요.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.
**참고**  
Amazon S3는 **CORS 구성 편집기** 제목 옆에 버킷의 Amazon 리소스 이름(ARN)을 표시합니다. ARN에 대한 자세한 내용은 *Amazon Web Services 일반 참조*의 [Amazon 리소스 이름(ARN) 및 AWS 서비스 네임스페이스](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)를 참조하세요.

## AWS SDK 사용
<a name="ManageCorsUsingSDK"></a>

AWS SDK를 사용하여 버킷에 대한 cross-origin 리소스 공유(CORS)를 관리할 수 있습니다. CORS에 대한 자세한 내용은 [교차 오리진 리소스 공유(CORS) 사용](cors.md) 섹션을 참조하십시오.

 다음 예제를 고려하십시오.
+ CORS 구성을 만들고 버킷에 구성 설정
+ 구성을 검색하고 규칙을 추가하여 구성 수정
+ 버킷에 수정된 구성 추가
+ 구성 삭제

------
#### [ Java ]

**Example**  

**Example**  
 실제 예제를 작성하여 테스트하는 방법에 대한 자세한 내용은 AWS SDK for Java 개발자 안내서에서 [시작하기](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/getting-started.html) 섹션을 참조하세요.  

```
import com.amazonaws.AmazonServiceException;
import com.amazonaws.SdkClientException;
import com.amazonaws.auth.profile.ProfileCredentialsProvider;
import com.amazonaws.regions.Regions;
import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.AmazonS3ClientBuilder;
import com.amazonaws.services.s3.model.BucketCrossOriginConfiguration;
import com.amazonaws.services.s3.model.CORSRule;

import java.io.IOException;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

public class CORS {

    public static void main(String[] args) throws IOException {
        Regions clientRegion = Regions.DEFAULT_REGION;
        String bucketName = "*** Bucket name ***";

        // Create two CORS rules.
        List<CORSRule.AllowedMethods> rule1AM = new ArrayList<CORSRule.AllowedMethods>();
        rule1AM.add(CORSRule.AllowedMethods.PUT);
        rule1AM.add(CORSRule.AllowedMethods.POST);
        rule1AM.add(CORSRule.AllowedMethods.DELETE);
        CORSRule rule1 = new CORSRule().withId("CORSRule1").withAllowedMethods(rule1AM)
                .withAllowedOrigins(Arrays.asList("http://*.example.com"));

        List<CORSRule.AllowedMethods> rule2AM = new ArrayList<CORSRule.AllowedMethods>();
        rule2AM.add(CORSRule.AllowedMethods.GET);
        CORSRule rule2 = new CORSRule().withId("CORSRule2").withAllowedMethods(rule2AM)
                .withAllowedOrigins(Arrays.asList("*")).withMaxAgeSeconds(3000)
                .withExposedHeaders(Arrays.asList("x-amz-server-side-encryption"));

        List<CORSRule> rules = new ArrayList<CORSRule>();
        rules.add(rule1);
        rules.add(rule2);

        // Add the rules to a new CORS configuration.
        BucketCrossOriginConfiguration configuration = new BucketCrossOriginConfiguration();
        configuration.setRules(rules);

        try {
            AmazonS3 s3Client = AmazonS3ClientBuilder.standard()
                    .withCredentials(new ProfileCredentialsProvider())
                    .withRegion(clientRegion)
                    .build();

            // Add the configuration to the bucket.
            s3Client.setBucketCrossOriginConfiguration(bucketName, configuration);

            // Retrieve and display the configuration.
            configuration = s3Client.getBucketCrossOriginConfiguration(bucketName);
            printCORSConfiguration(configuration);

            // Add another new rule.
            List<CORSRule.AllowedMethods> rule3AM = new ArrayList<CORSRule.AllowedMethods>();
            rule3AM.add(CORSRule.AllowedMethods.HEAD);
            CORSRule rule3 = new CORSRule().withId("CORSRule3").withAllowedMethods(rule3AM)
                    .withAllowedOrigins(Arrays.asList("http://www.example.com"));

            rules = configuration.getRules();
            rules.add(rule3);
            configuration.setRules(rules);
            s3Client.setBucketCrossOriginConfiguration(bucketName, configuration);

            // Verify that the new rule was added by checking the number of rules in the
            // configuration.
            configuration = s3Client.getBucketCrossOriginConfiguration(bucketName);
            System.out.println("Expected # of rules = 3, found " + configuration.getRules().size());

            // Delete the configuration.
            s3Client.deleteBucketCrossOriginConfiguration(bucketName);
            System.out.println("Removed CORS configuration.");

            // Retrieve and display the configuration to verify that it was
            // successfully deleted.
            configuration = s3Client.getBucketCrossOriginConfiguration(bucketName);
            printCORSConfiguration(configuration);
        } catch (AmazonServiceException e) {
            // The call was transmitted successfully, but Amazon S3 couldn't process
            // it, so it returned an error response.
            e.printStackTrace();
        } catch (SdkClientException e) {
            // Amazon S3 couldn't be contacted for a response, or the client
            // couldn't parse the response from Amazon S3.
            e.printStackTrace();
        }
    }

    private static void printCORSConfiguration(BucketCrossOriginConfiguration configuration) {
        if (configuration == null) {
            System.out.println("Configuration is null.");
        } else {
            System.out.println("Configuration has " + configuration.getRules().size() + " rules\n");

            for (CORSRule rule : configuration.getRules()) {
                System.out.println("Rule ID: " + rule.getId());
                System.out.println("MaxAgeSeconds: " + rule.getMaxAgeSeconds());
                System.out.println("AllowedMethod: " + rule.getAllowedMethods());
                System.out.println("AllowedOrigins: " + rule.getAllowedOrigins());
                System.out.println("AllowedHeaders: " + rule.getAllowedHeaders());
                System.out.println("ExposeHeader: " + rule.getExposedHeaders());
                System.out.println();
            }
        }
    }
}
```

------
#### [ .NET ]

**Example**  
코드 예제 설정 및 실행에 대한 자세한 내용은 *AWS SDK for .NET 개발자 안내서*의 [AWS SDK for .NET 시작하기](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-setup.html)를 참조하세요.  

```
using Amazon;
using Amazon.S3;
using Amazon.S3.Model;
using System;
using System.Collections.Generic;
using System.Threading.Tasks;

namespace Amazon.DocSamples.S3
{
    class CORSTest
    {
        private const string bucketName = "*** bucket name ***";
        // Specify your bucket region (an example region is shown).
        private static readonly RegionEndpoint bucketRegion = RegionEndpoint.USWest2; 
        private static IAmazonS3 s3Client;

        public static void Main()
        {
            s3Client = new AmazonS3Client(bucketRegion);
            CORSConfigTestAsync().Wait();
        }
        private static async Task CORSConfigTestAsync()
        {
            try
            {
                // Create a new configuration request and add two rules    
                CORSConfiguration configuration = new CORSConfiguration
                {
                    Rules = new System.Collections.Generic.List<CORSRule>
                        {
                          new CORSRule
                          {
                            Id = "CORSRule1",
                            AllowedMethods = new List<string> {"PUT", "POST", "DELETE"},
                            AllowedOrigins = new List<string> {"http://*.example.com"}
                          },
                          new CORSRule
                          {
                            Id = "CORSRule2",
                            AllowedMethods = new List<string> {"GET"},
                            AllowedOrigins = new List<string> {"*"},
                            MaxAgeSeconds = 3000,
                            ExposeHeaders = new List<string> {"x-amz-server-side-encryption"}
                          }
                        }
                };

                // Add the configuration to the bucket. 
                await PutCORSConfigurationAsync(configuration);

                // Retrieve an existing configuration. 
                configuration = await RetrieveCORSConfigurationAsync();

                // Add a new rule.
                configuration.Rules.Add(new CORSRule
                {
                    Id = "CORSRule3",
                    AllowedMethods = new List<string> { "HEAD" },
                    AllowedOrigins = new List<string> { "http://www.example.com" }
                });

                // Add the configuration to the bucket. 
                await PutCORSConfigurationAsync(configuration);

                // Verify that there are now three rules.
                configuration = await RetrieveCORSConfigurationAsync();
                Console.WriteLine();
                Console.WriteLine("Expected # of rulest=3; found:{0}", configuration.Rules.Count);
                Console.WriteLine();
                Console.WriteLine("Pause before configuration delete. To continue, click Enter...");
                Console.ReadKey();

                // Delete the configuration.
                await DeleteCORSConfigurationAsync();

                // Retrieve a nonexistent configuration.
                configuration = await RetrieveCORSConfigurationAsync();
            }
            catch (AmazonS3Exception e)
            {
                Console.WriteLine("Error encountered on server. Message:'{0}' when writing an object", e.Message);
            }
            catch (Exception e)
            {
                Console.WriteLine("Unknown encountered on server. Message:'{0}' when writing an object", e.Message);
            }
        }

        static async Task PutCORSConfigurationAsync(CORSConfiguration configuration)
        {

            PutCORSConfigurationRequest request = new PutCORSConfigurationRequest
            {
                BucketName = bucketName,
                Configuration = configuration
            };

            var response = await s3Client.PutCORSConfigurationAsync(request);
        }

        static async Task<CORSConfiguration> RetrieveCORSConfigurationAsync()
        {
            GetCORSConfigurationRequest request = new GetCORSConfigurationRequest
            {
                BucketName = bucketName

            };
            var response = await s3Client.GetCORSConfigurationAsync(request);
            var configuration = response.Configuration;
            PrintCORSRules(configuration);
            return configuration;
        }

        static async Task DeleteCORSConfigurationAsync()
        {
            DeleteCORSConfigurationRequest request = new DeleteCORSConfigurationRequest
            {
                BucketName = bucketName
            };
            await s3Client.DeleteCORSConfigurationAsync(request);
        }

        static void PrintCORSRules(CORSConfiguration configuration)
        {
            Console.WriteLine();

            if (configuration == null)
            {
                Console.WriteLine("\nConfiguration is null");
                return;
            }

            Console.WriteLine("Configuration has {0} rules:", configuration.Rules.Count);
            foreach (CORSRule rule in configuration.Rules)
            {
                Console.WriteLine("Rule ID: {0}", rule.Id);
                Console.WriteLine("MaxAgeSeconds: {0}", rule.MaxAgeSeconds);
                Console.WriteLine("AllowedMethod: {0}", string.Join(", ", rule.AllowedMethods.ToArray()));
                Console.WriteLine("AllowedOrigins: {0}", string.Join(", ", rule.AllowedOrigins.ToArray()));
                Console.WriteLine("AllowedHeaders: {0}", string.Join(", ", rule.AllowedHeaders.ToArray()));
                Console.WriteLine("ExposeHeader: {0}", string.Join(", ", rule.ExposeHeaders.ToArray()));
            }
        }
    }
}
```

------

## REST API 사용
<a name="EnableCorsUsingREST"></a>

버킷에 CORS 구성을 설정하려면 AWS Management Console을 사용할 수 있습니다. 하지만 애플리케이션에서 요구할 경우 REST 요청을 직접 전송할 수도 있습니다. *Amazon Simple Storage Service API 참조*의 다음 섹션에서는 CORS 구성과 관련된 REST API 작업에 대해 설명합니다.
+ [PutBucketCors](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUTcors.html)
+ [GetBucketCors](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGETcors.html)
+ [DeleteBucketCors](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketDELETEcors.html)
+ [OPTIONS 객체](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTOPTIONSobject.html)

# CORS 테스트
<a name="testing-cors"></a>

CORS 구성을 테스트하려면 `OPTIONS` 메서드와 함께 CORS 사전 요청을 전송하여 요청 전송이 허용되는 경우 서버가 응답하도록 할 수 있습니다. Amazon S3가 사전 요청을 받으면 S3에서 버킷에 대한 CORS 구성을 평가하고 수신된 요청과 일치하는 첫 번째 `CORSRule` 규칙을 사용하여 교차 오리진 요청을 허용합니다. 규칙이 일치하려면 다음 조건이 충족되어야 합니다.
+ 버킷에 대한 CORS 요청의 `Origin` 헤더는 CORS 구성의 `AllowedOrigins` 요소에 있는 오리진과 일치해야 합니다.
+ 버킷에 대한 CORS 요청의 `Access-Control-Request-Method`에 지정된 HTTP 메서드는 CORS 구성의 `AllowedMethods` 요소에 나열된 메서드와 일치해야 합니다.
+ 사전 요청의 `Access-Control-Request-Headers` 헤더에 나열된 헤더는 CORS 구성의 `AllowedHeaders` 요소에 있는 헤더와 일치해야 합니다.

다음은 CORS 구성 예제입니다. CORS 구성을 만들려면 [CORS 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html)을 참조하세요. CORS 구성의 자세한 예제는 [CORS 구성의 요소](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ManageCorsUsing.html)를 참조하세요.

CORS 규칙 구성 및 문제 해결에 대한 지침은 AWS re:Post 지식 센터의 [Amazon S3에서 CORS를 구성하고 cURL을 사용하여 CORS 규칙을 확인하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/s3-configure-cors)를 참조하세요.

------
#### [ JSON ]

```
[
    {
        "AllowedHeaders": [
            "Authorization"
        ],
        "AllowedMethods": [
            "GET",
            "PUT",
            "POST",
            "DELETE"
        ],
        "AllowedOrigins": [
            "http://www.example1.com"
        ],
        "ExposeHeaders":  [
             "x-amz-meta-custom-header"
        ]
    
    }
]
```

------

CORS 구성을 테스트하려면 다음 CURL 명령을 사용하여 사전 요청 `OPTIONS` 검사를 보낼 수 있습니다. CURL은 S3와 상호 작용하는 데 사용할 수 있는 명령줄 도구입니다. 자세한 내용은 [CURL](https://curl.se/)을 참조하세요.

```
 curl -v -X OPTIONS \
  -H "Origin: http://www.example1.com" \
  -H "Access-Control-Request-Method: PUT" \
  -H "Access-Control-Request-Headers: Authorization" \
  -H "Access-Control-Expose-Headers: x-amz-meta-custom-header"\
     "http://bucket_name.s3.amazonaws.com/object_prefix_name"
```

위 예제에서 `curl -v -x OPTIONS` 명령은 S3에 사전 요청을 보내 S3가 교차 오리진 `http://www.example1.com`에서 객체에 대한 `PUT` 요청을 보내는 것을 허용하는지 문의하는 데 사용됩니다. 헤더 `Access-Control-Request-Headers` 및 `Access-Control-Expose-Headers`는 선택 사항입니다.
+ Amazon S3는 사전 `OPTIONS` 요청의 `Access-Control-Request-Method` 헤더에 대한 응답으로 요청된 메서드가 일치하는 경우 허용된 메서드 목록을 반환합니다.
+ Amazon S3는 사전 `OPTIONS` 요청의 `Access-Control-Request-Headers` 헤더에 대한 응답으로 요청된 헤더가 일치하는 경우 허용된 헤더 목록을 반환합니다.
+ Amazon S3는 사전 `OPTIONS` 요청의 `Access-Control-Expose-Headers` 헤더에 대한 응답으로 요청된 헤더가 브라우저에서 실행되는 스크립트에서 액세스할 수 있는 허용 헤더와 일치하는 경우 허용된 헤더 목록을 반환합니다.

**참고**  
사전 요청을 전송할 때 CORS 요청 헤더 중 하나라도 허용되지 않는 경우 응답 CORS 헤더는 반환되지 않습니다.

이 사전 `OPTIONS` 요청에 대한 응답으로 `200 OK` 응답을 받게 됩니다. CORS를 테스트할 때 수신되는 일반적인 오류 코드와 CORS 관련 문제 해결을 위한 자세한 내용은 [CORS 문제 해결](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors-troubleshooting.html)을 참조하세요.

```
< HTTP/1.1 200 OK
< Date: Fri, 12 Jul 2024 00:23:51 GMT
< Access-Control-Allow-Origin: http://www.example1.com
< Access-Control-Allow-Methods: GET, PUT, POST, DELETE 
< Access-Control-Allow-Headers: Authorization
< Access-Control-Expose-Headers: x-amz-meta-custom-header
< Access-Control-Allow-Credentials: true
< Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
< Server: AmazonS3
< Content-Length: 0
```

# CORS 문제 해결
<a name="cors-troubleshooting"></a>

다음 주제는 S3와 관련된 몇 가지 일반적인 CORS 문제를 해결하는 데 도움이 될 수 있습니다.

**Topics**
+ [403 Forbidden 오류 - 이 버킷에 대해 CORS가 활성화되지 않음](#cors-not-enabled)
+ [403 Forbidden 오류 - 이 CORS 요청은 허용되지 않음](#cors-not-enabled)
+ [CORS 응답에서 헤더를 찾을 수 없음](#Headers-not-found)
+ [S3 프록시 통합의 CORS 관련 고려 사항](#cors-in-proxy)

## 403 Forbidden 오류: 이 버킷에 대해 CORS가 활성화되지 않음
<a name="cors-not-enabled"></a>

교차 오리진 요청이 Amazon S3로 전송되었지만 CORS가 S3 버킷에 구성되지 않은 경우 다음 `403 Forbidden` 오류가 발생합니다.

 오류: HTTP/1.1 403 Forbidden CORS Response: CORS is not enabled for this bucket.  

CORS 구성은 버킷에 액세스할 수 있도록 허용할 오리진, 각 오리진에 대해 지원되는 작업(HTTP 메서드) 및 기타 작업별 정보를 식별하는 규칙이 포함된 문서 또는 정책입니다. Amazon S3 콘솔, AWS SDK 및 REST API를 사용하여 S3에 [CORS를 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html)하는 방법을 알아보세요. CORS에 대한 자세한 내용과 CORS 구성의 예는 [CORS의 요소](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ManageCorsUsing.html#cors-example-1)를 참조하세요.

## 403 Forbidden 오류: 이 CORS 요청은 허용되지 않음
<a name="cors-not-enabled"></a>

CORS 구성의 CORS 규칙이 요청의 데이터와 일치하지 않는 경우 다음 `403 Forbidden` 오류가 발생합니다.

오류:  HTTP/1.1 403 Forbidden CORS Response: This CORS request is not allowed.

따라서 다음과 같은 여러 가지 이유로 이 `403 Forbidden` 오류가 발생할 수 있습니다.
+ 오리진이 허용되지 않습니다.
+ 메서드가 허용되지 않습니다.
+ 요청된 헤더가 허용되지 않습니다.

Amazon S3가 받은 각 요청에 대해 해당 요청의 데이터와 일치하는 CORS 규칙이 CORS 구성에 있어야 합니다.

### 오리진이 허용되지 않음
<a name="Origin-not-allowed"></a>

 버킷에 대한 CORS 요청의 `Origin` 헤더는 CORS 구성의 `AllowedOrigins` 요소에 있는 오리진과 일치해야 합니다. `AllowedOrigins` 요소의 와일드카드 문자(`"*"`)는 모든 HTTP 메서드와 일치합니다. `AllowedOrigins` 요소를 업데이트하는 방법에 대한 자세한 내용은 [교차 오리진 리소스 공유(CORS) 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html)을 참조하세요.

 예를 들어 `AllowedOrigins` 요소에 `http://www.example1.com` 도메인만 포함된 경우 `http://www.example2.com` 도메인에서 보낸 CORS 요청에서 `403 Forbidden` 오류가 발생합니다.

다음 예시에서는 `AllowedOrigins` 요소에 `http://www.example1.com` 도메인이 포함된 CORS 구성의 일부를 보여줍니다.

```
"AllowedOrigins":[
   "http://www.example1.com"
]
```

`http://www.example2.com` 도메인에서 보낸 CORS 요청이 성공하려면 해당 `http://www.example2.com` 도메인이 CORS 구성의 `AllowedOrigins` 요소에 포함되어야 합니다.

```
"AllowedOrigins":[
   "http://www.example1.com"
   "http://www.example2.com"
]
```

### 메서드가 허용되지 않음
<a name="Methods-not-allowed"></a>

 버킷에 대한 CORS 요청의 `Access-Control-Request-Method`에 지정된 HTTP 메서드는 CORS 구성의 `AllowedMethods` 요소에 나열된 메서드와 일치해야 합니다. `AllowedMethods`의 와일드카드 문자(`"*"`)는 모든 HTTP 메서드와 일치합니다. `AllowedOrigins` 요소를 업데이트하는 방법에 대한 자세한 내용은 [교차 오리진 리소스 공유(CORS) 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html)을 참조하세요.

CORS 구성에서 `AllowedMethods` 요소에 다음 메서드를 지정할 수 있습니다.
+ `GET`
+ `PUT`
+ `POST`
+ `DELETE`
+ `HEAD`

다음 예시에서는 `AllowedMethods` 요소에 `GET` 메서드가 포함된 CORS 구성의 일부를 보여줍니다. `GET` 메서드를 포함한 요청만 성공합니다.

```
"AllowedMethods":[
   "GET"
]
```

 HTTP 메서드(예:`PUT`)가 CORS 요청에 사용되었거나 버킷에 대한 사전 CORS 요청에 포함되었으나 해당 메서드가 CORS 구성에 없는 경우 요청에서 `403 Forbidden` 오류가 발생합니다. 이 CORS 요청 또는 CORS 사전 요청을 허용하려면 `PUT` 메서드를 CORS 구성에 추가해야 합니다.

```
"AllowedMethods":[
   "GET"
   "PUT"
]
```

### 요청된 헤더가 허용되지 않음
<a name="Headers-not-allowed"></a>

 사전 요청의 `Access-Control-Request-Headers` 헤더에 나열된 헤더는 CORS 구성의 `AllowedHeaders` 요소에 있는 헤더와 일치해야 합니다. Amazon S3에 대한 요청에 사용할 수 있는 공통 헤더 목록은 [공통 요청 헤더](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.html)를 참조하세요. `AllowedHeaders` 요소를 업데이트하는 방법에 대한 자세한 내용은 [교차 오리진 리소스 공유(CORS) 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enabling-cors-examples.html)을 참조하세요.

다음 예시에서는 `AllowedHeaders` 요소에 `Authorization` 헤더가 포함된 CORS 구성의 일부를 보여줍니다. `Authorization` 헤더에 대한 요청만 성공합니다.

```
"AllowedHeaders":  [
    "Authorization"
]
```

 헤더(예: `Content-MD5`)가 CORS 요청에 포함되었지만 해당 헤더가 CORS 구성에 없는 경우 요청에서 `403 Forbidden` 오류가 발생합니다. 이 CORS 요청을 허용하려면 `Content-MD5` 헤더를 CORS 구성에 추가해야 합니다. CORS 요청의 `Authorization` 헤더와 `Content-MD5` 헤더를 모두 버킷으로 전달하려면 두 헤더가 모두 CORS 구성의 `AllowedHeaders` 요소에 포함되어 있는지 확인합니다.

```
"AllowedHeaders":  [
    "Authorization"
    "Content-MD5"
]
```

## CORS 응답에서 헤더를 찾을 수 없음
<a name="Headers-not-found"></a>

 CORS 구성의 `ExposeHeaders` 요소는 CORS 요청에 대한 응답으로 브라우저에서 실행되는 스크립트와 애플리케이션이 액세스할 수 있도록 설정할 응답 헤더를 식별합니다.

S3 버킷에 저장된 객체에 응답 데이터와 함께 사용자 정의 메타데이터(예:`x-amz-meta-custom-header`)가 있는 경우 이 사용자 지정 헤더에는 클라이언트측 JavaScript 코드에서 액세스할 추가 메타데이터 또는 정보가 포함될 수 있습니다. 하지만 기본적으로 브라우저는 보안상의 이유로 사용자 지정 헤더에 대한 액세스를 차단합니다. 클라이언트측 JavaScript가 사용자 지정 헤더에 액세스할 수 있도록 하려면 CORS 구성에 해당 헤더를 포함해야 합니다.

 아래 예시에서 `x-amz-meta-custom-header1` 헤더는 `ExposeHeaders` 요소에 포함되어 있습니다. `x-amz-meta-custom-header2`는 `ExposeHeaders` 요소에 포함되지 않았으며 CORS 구성에서 누락되었습니다. 응답에서는 `ExposeHeaders` 요소에 포함된 값만 반환됩니다. 요청에서 `Access-Control-Expose-Headers` 헤더에 `x-amz-meta-custom-header2` 헤더가 포함된 경우에도 응답은 여전히 `200 OK`를 반환합니다. 하지만 허용된 헤더(예: `x-amz-meta-custom-header`)만 반환되어 응답에 표시됩니다.

```
"ExposeHeaders":  [
    "x-amz-meta-custom-header1"
]
```

 모든 헤더가 응답에 표시되도록 하려면 아래와 같이 허용된 모든 헤더를 CORS 구성의 `ExposeHeaders` 요소에 추가합니다.

```
"ExposeHeaders":  [
    "x-amz-meta-custom-header1",
    "x-amz-meta-custom-header2"
]
```

## S3 프록시 통합의 CORS 관련 고려 사항
<a name="cors-in-proxy"></a>

오류가 발생하며 이미 S3 버킷의 CORS 구성을 확인했고 교차 오리진 요청이 AWS CloudFront와 같은 프록시로 전송되는 경우 다음 작업을 시도해 봅니다.
+ `OPTIONS` 메서드에서 HTTP 요청을 허용하도록 설정을 구성합니다.
+ `Origin`, `Access-Control-Request-Headers` 및 `Access-Control-Request-Method` 헤더를 전달하도록 프록시를 구성합니다.
+ 캐시 키에 오리진 헤더를 포함하도록 프록시 설정을 구성합니다. 이는 캐시 키에 오리진 헤더를 포함하지 않는 캐싱 프록시가 다른 오리진에 적절한 CORS 헤더를 포함하지 않는 캐싱된 응답을 제공할 수 있기 때문에 중요합니다.

일부 프록시는 CORS 요청에 대한 사전 정의된 기능을 제공합니다. 예를 들어 CloudFront에서 헤더를 포함하는 정책을 구성할 수 있습니다.

 이러한 헤더는 오리진이 Amazon S3 버킷일 때 Cross-Origin Resource Sharing(CORS) 요청을 활성화하는 헤더입니다.

 이 정책에는 다음 설정이 포함되어 있습니다.
+ 오리진 요청에 포함된 헤더:

   `Origin`

   `Access-Control-Request-Headers`

   `Access-Control-Request-Method`
+ 오리진 요청에 포함된 쿠키: 없음
+ 오리진 요청에 포함된 쿼리 문자열: 없음

자세한 내용은 **Amazon CloudFront 개발자 안내서의 [정책을 통한 오리진 요청 제어](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.htm) 또는 [관리형 오리진 요청 정책 사용](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-origin-request-policies.html#managed-origin-request-policy-cors-s3)을 참조하세요.

# 정적 웹 사이트 자습서
<a name="static-website-tutorials"></a>

다음 튜토리얼 또는 연습에서는 정적 웹 사이트 호스팅 및 온디맨드 비디오 스트리밍 호스팅을 위한 Amazon S3 범용 버킷을 만들고 구성하는 방법에 대한 절차 전체를 안내합니다. 이 자습서 목적은 일반적인 지침을 제공하는 것입니다. 이러한 자습서는 예제 버킷 이름 및 사용자 이름 등을 통해 랩 유형의 환경에 맞게 고안되었습니다. 조직의 고유한 요구 사항에 맞는지 주의 깊은 검토 및 조정 없이 프로덕션 환경에 바로 사용할 수 있도록 고안된 것이 아닙니다.
+ [Amazon S3, Amazon CloudFront 및 Amazon Route 53로 온디맨드 스트리밍 비디오 호스팅](https://docs.aws.amazon.com/AmazonS3/latest/userguide/tutorial-s3-cloudfront-route53-video-streaming) – Amazon S3를 Amazon CloudFront와 함께 사용하여 안전하고 확장 가능한 방식으로 온디맨드 보기 용도의 비디오를 호스팅할 수 있습니다. 비디오를 올바른 포맷으로 패키징했으면 서버나 S3 범용 버킷에 저장한 후 최종 사용자들이 요청할 때 CloudFront를 사용하여 제공할 수 있습니다. 이 자습서에서는 전송을 위한 CloudFront와 도메인 이름 시스템(DNS) 및 사용자 지정 도메인 관리를 위한 Amazon Route 53를 사용하여 온디맨드 비디오 스트리밍을 호스팅하도록 범용 버킷을 구성하는 방법을 배울 수 있습니다. CloudFront는 해당 캐시에서 비디오를 제공하고, 아직 캐싱되지 않은 경우에만 범용 버킷에서 비디오를 검색합니다. 이 캐싱 관리 기능은 짧은 대기 시간, 높은 처리량, 빠른 전송 속도로 전 세계 뷰어에게 비디오를 빠르게 제공할 수 있습니다. CloudFront 캐싱 관리에 대한 자세한 내용은 *Amazon CloudFront 개발자 가이드*의 [캐싱 및 가용성 최적화](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ConfiguringCaching.html)를 참조하십시오.
+ [정적 웹 사이트 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HostingWebsiteOnS3Setup.html) – 웹 사이트처럼 작동하도록 범용 버킷을 구성할 수 있습니다. 이 자습서에서는 버킷 만들기, S3 콘솔에서의 정적 웹 사이트 호스팅 활성화, 인덱스 문서 만들기, 오류 문서 만들기 등 Amazon S3에 웹 사이트를 호스팅하는 단계를 안내합니다. 자세한 내용은 [Amazon S3를 사용하여 정적 웹 사이트 호스팅](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html)을 참조하세요.
+ [Route 53에 등록된 사용자 지정 도메인을 사용하여 정적 웹 사이트 구성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-custom-domain-walkthrough.html) - 정적 웹 사이트를 호스팅하는 범용 버킷을 생성 및 구성하고 S3에서 Amazon Route 53에 등록된 사용자 지정 도메인 이름의 웹 사이트에 대한 리디렉션을 만들 수 있습니다. Route 53를 사용하여 도메인을 등록하고 도메인의 인터넷 트래픽을 라우팅할 위치를 정의합니다. 이 자습서에서는 도메인 및 하위 도메인의 트래픽을 HTML 파일이 포함된 범용 버킷으로 라우팅하는 Route 53 별칭 레코드를 만드는 방법을 보여줍니다. 자세한 내용은 **Amazon Route 53 개발자 안내서의 [Amazon S3 버킷의 정적 웹 사이트에 대한 도메인 사용](https://docs.aws.amazon.com//Route53/latest/DeveloperGuide/getting-started-s3.html)을 참조하세요. 이 자습서를 완료한 후에는 필요에 따라 CloudFront를 사용하여 웹 사이트의 성능을 향상시킬 수 있습니다. 자세한 내용은 [Amazon CloudFront로 웹 사이트 속도 향상](https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-cloudfront-walkthrough.html)을 참조하세요.
+ [S3 범용 버킷에서 AWS Amplify Hosting에 정적 웹 사이트 배포](https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-amplify) - [AWS Amplify Hosting](https://docs.aws.amazon.com//amplify/latest/userguide/welcome.html.html)을 사용하여 S3에 저장된 정적 웹 사이트 콘텐츠를 호스팅하는 것이 좋습니다. Amplify Hosting은 Amazon CloudFront로 구동되는 전 세계적으로 사용 가능한 콘텐츠 전송 네트워크(CDN)에 웹 사이트를 쉽게 배포할 수 있도록 하는 완전 관리형 서비스이므로 광범위한 설정을 하지 않아도 안전한 정적 웹 사이트 호스팅이 가능합니다. AWS Amplify Hosting을 사용하면 범용 버킷 내에서 객체의 위치를 선택하고, 관리형 CDN에 콘텐츠를 배포하고, 어디서나 웹 사이트에 액세스할 수 있는 퍼블릭 HTTPS URL을 생성할 수 있습니다. 자세한 내용은 *AWS Amplify Hosting 사용 설명서*의 [Amplify 콘솔을 사용하여 S3에서 정적 웹 사이트 배포](https://docs.aws.amazon.com//amplify/latest/userguide/deploy--from-amplify-console.html)를 참조하세요.

# 자습서: Amazon S3, Amazon CloudFront 및 Amazon Route 53로 온디맨드 스트리밍 비디오 호스팅
<a name="tutorial-s3-cloudfront-route53-video-streaming"></a>

Amazon S3를 Amazon CloudFront와 함께 사용하여 보안 및 확장성이 있는 방식의 온디맨드 보기 용도로 비디오를 호스팅할 수 있습니다. 온디맨드 비디오(VOD) 스트리밍은 비디오 콘텐츠가 서버에 저장되고 뷰어가 언제든지 비디오 콘텐츠를 볼 수 있음을 의미합니다.

CloudFront는 빠르고 안전하며 프로그래밍 가능한 콘텐츠 전송 네트워크(CDN) 서비스입니다. CloudFront는 전세계적으로 모든 CloudFront의 엣지 로케이션에서 HTTPS를 통해 콘텐츠를 안전하게 전송할 수 있습니다. CloudFront 에 대한 자세한 내용은 *Amazon CloudFront 개발자 가이드*의 [Amazon CloudFront란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 단원을 참조하십시오.

CloudFront 캐싱은 오리진 서버에서 직접 응답해야 하는 요청의 수를 줄입니다. 뷰어(최종 사용자)의 경우 CloudFront에서 제공하는 비디오를 요청하면 해당 요청은 뷰어의 위치와 가까운 엣지 로케이션으로 라우팅됩니다. CloudFront는 해당 캐시에서 비디오를 제공하고, 아직 캐싱되지 않은 경우에만 S3 버킷에서 비디오를 검색합니다. 이 캐싱 관리 기능은 짧은 대기 시간, 높은 처리량, 빠른 전송 속도로 전 세계 뷰어에게 비디오를 빠르게 제공할 수 있습니다. CloudFront 캐싱 관리에 대한 자세한 내용은 *Amazon CloudFront 개발자 가이드*의 [캐싱 및 가용성 최적화](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ConfiguringCaching.html)를 참조하십시오.

![\[CloudFront 캐싱 메커니즘의 작동 방식을 보여 주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/images/cf-example-image-global.png)


**목표**  
이 자습서에서는 전송을 위해 CloudFront를 사용하고 도메인 이름 시스템(DNS) 및 사용자 지정 도메인 관리를 위해 Amazon Route 53를 사용하여 온디맨드 비디오 스트리밍을 호스팅하도록 S3 버킷을 구성합니다.

**Topics**
+ [사전 조건: Route 53에 사용자 지정 도메인 등록 및 구성](#cf-s3-prerequisites)
+ [1단계: S3 버킷 생성](#cf-s3-step1)
+ [2단계: S3 버킷에 파일 업로드](#cf-s3-step2)
+ [3단계: CloudFront 원본 액세스 자격 증명 생성](#cf-s3-step3)
+ [4단계: CloudFront 배포 생성](#cf-s3-step4)
+ [5단계: CloudFront 배포를 통해 비디오에 액세스](#cf-s3-step5)
+ [6단계: 사용자 지정 도메인 이름을 사용하도록 CloudFront 배포 구성](#cf-s3-step6)
+ [7단계: 사용자 지정 도메인 이름을 사용하여 CloudFront 배포를 통해 S3 비디오에 액세스](#cf-s3-step7)
+ [8단계: CloudFront 배포에서 수신한 요청에 대한 데이터 보기(선택 사항)](#cf-s3-step8)
+ [9단계: 정리](#cf-s3-step9)
+ [다음 단계](#cf-s3-next-steps)

## 사전 조건: Route 53에 사용자 지정 도메인 등록 및 구성
<a name="cf-s3-prerequisites"></a>

이 자습서를 시작하기 전에, 나중에 사용자 지정 도메인 이름을 사용하도록 CloudFront 배포를 구성하려면 Route 53에 사용자 지정 도메인(예: **example.com**)을 등록하고 구성해야 합니다.

사용자 지정 도메인 이름이 없으면 S3 비디오가 다음과 유사한 URL에서 CloudFront를 통해 공개적으로 액세스되고 호스팅됩니다.

```
https://CloudFront distribution domain name/Path to an S3 video
```

예를 들어 **https://d111111abcdef8.cloudfront.net/sample.mp4**입니다.

Route 53으로 구성된 사용자 지정 도메인 이름을 사용하도록 CloudFront 배포를 구성하면 S3 비디오가 다음과 유사한 URL에서 CloudFront를 통해 공개적으로 액세스되고 호스팅됩니다.

```
https://CloudFront distribution alternate domain name/Path to an S3 video
```

예를 들어 **https://www.example.com/sample.mp4**입니다. 사용자 지정 도메인 이름은 뷰어가 보다 간단하고 직관적으로 사용할 수 있습니다.

****  
사용자 지정 도메인을 등록하려면 *Amazon Route 53 개발자 안내서*의 [Route 53을 사용하여 새 도메인 이름 등록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register.html)을 참조하십시오.

Route 53을 사용하여 도메인 이름을 등록하면 Route 53은 이 자습서의 뒷부분에서 사용할 호스팅 영역을 생성합니다. 이 호스팅 영역은 트래픽을 도메인(예: Amazon EC2 인스턴스 또는 CloudFront 배포)으로 라우팅하는 방법에 대한 정보를 저장하는 곳입니다.

도메인 등록, 호스팅 영역 및 도메인에서 수신한 DNS 쿼리와 관련된 요금이 있습니다. 자세한 내용은 [Amazon Route 53 요금](https://aws.amazon.com/route53/pricing/)을 참조하세요.

**참고**  
도메인을 등록하면 즉시 비용이 청구되며, 이는 취소할 수 없습니다. 도메인을 자동 갱신하지 않도록 선택할 수 있지만, 선불로 비용을 지불하며 1년 동안 소유합니다. 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [새 도메인 등록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register.html)을 참조하십시오.

## 1단계: S3 버킷 생성
<a name="cf-s3-step1"></a>

스트리밍하려는 원본 비디오를 저장할 버킷을 생성합니다.

**버킷을 생성하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 페이지 상단의 탐색 모음에서 현재 표시된 AWS 리전의 이름을 선택합니다. 그런 다음 버킷을 생성하려는 리전을 선택합니다.
**참고**  
지연 시간과 요금을 최소화하고 규제 요건을 충족하려면 가장 가까운 리전을 선택하십시오. 특정 리전에 저장된 객체는 사용자가 명시적으로 객체를 다른 리전으로 전송하지 않는 한 해당 리전을 벗어나지 않습니다. Amazon S3 AWS 리전 목록은 **Amazon Web Services 일반 참조의 [AWS 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region)를 참조하십시오.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. **버킷 만들기**를 선택합니다. **버킷 만들기** 페이지가 열립니다.

1. **버킷 이름**에 버킷 이름을 입력합니다(예: **tutorial-bucket**).

   Amazon S3의 버킷 이름 지정 규칙에 대한 자세한 내용은 [범용 버킷 이름 지정 규칙](bucketnamingrules.md) 섹션을 참조하십시오.

1. **리전(Region)**에서 버킷이 속할 AWS 리전을 선택합니다.

   가능하면 뷰어의 대다수와 가장 가까운 리전을 선택해야 합니다. 버킷 리전에 대한 자세한 내용은 [범용 버킷 개요](UsingBucket.md) 섹션을 참조하십시오.

1. **이 버킷에 대한 퍼블릭 액세스 차단 설정(Block Public Access settings for this bucket)**에서 해당 설정을 기본값으로 유지합니다(***모든* 퍼블릭 액세스 차단(Block all public access)**이 활성화됨).

   ***모든* 퍼블릭 액세스 차단**을 활성화한 경우에도 뷰어는 CloudFront를 통해 업로드된 비디오에 계속 액세스할 수 있습니다. 이 기능은 CloudFront를 사용하여 S3에 저장된 비디오를 호스팅할 때의 주요 이점입니다.

   해당 사용 사례에 대해 하나 이상의 설정을 해제해야 하는 경우가 아니라면 모든 설정을 활성화 상태로 유지하는 것이 좋습니다. 퍼블릭 액세스 차단에 대한 자세한 내용은 [Amazon S3 스토리지에 대한 퍼블릭 액세스 차단](access-control-block-public-access.md) 섹션을 참조하세요.

1. 나머지 설정은 기본값으로 유지합니다.

   특정 사용 사례에 대한 추가 버킷 설정을 구성하려면 [범용 버킷 생성](create-bucket-overview.md) 섹션을 참조하십시오(선택 사항).

1. **버킷 생성**을 선택합니다.

## 2단계: S3 버킷에 파일 업로드
<a name="cf-s3-step2"></a>

다음 절차에서는 콘솔을 사용하여 S3 버킷에 비디오 파일을 업로드하는 방법을 설명합니다. S3에 많은 대용량 비디오파일을 업로드하는 경우 [Amazon S3 Transfer Acceleration](https://aws.amazon.com/s3/transfer-acceleration)을 사용하여 빠르고 안전한 파일 전송을 구성할 수 있습니다. Transfer Acceleration을 사용하면 S3 버킷에 비디오를 빠르게 업로드하여 대용량의 비디오를 장거리 전송할 수 있습니다. 자세한 내용은 [Amazon S3 Transfer Acceleration을 사용하여 빠르고 안전한 파일 전송 구성](transfer-acceleration.md) 섹션을 참조하세요.

**버킷에 파일을 업로드하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. **범용 버킷** 목록에서 [1단계](#cf-s3-step1)에서 생성한 버킷의 이름(예: **tutorial-bucket**)을 선택하여 파일을 업로드합니다.

1. 버킷의 **객체(Objects)** 탭에서 **업로드(Upload)**를 선택합니다.

1. **업로드(Upload)** 페이지의 **파일 및 폴더(Files and Folders)**에서 **파일 추가(Add Files)**를 선택합니다.

1. 업로드할 파일을 선택한 후 **열기**를 선택합니다.

   예를 들어 `sample.mp4` 비디오 파일을 업로드할 수 있습니다.

1. **업로드**를 선택합니다.

## 3단계: CloudFront 원본 액세스 자격 증명 생성
<a name="cf-s3-step3"></a>

S3 버킷에서 비디오에 대한 직접 액세스를 제한하려면, 원본 액세스 ID(OAI)라는 특별한 CloudFront 사용자를 생성합니다. 이 자습서의 후반에서는 OAI를 배포와 연결합니다. OAI를 사용하면 CloudFront를 우회하여 S3 버킷에서 직접 비디오를 가져올 수 없도록 할 수 있습니다. CloudFront OAI만 S3 버킷의 파일에 액세스할 수 있습니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [Amazon S3 오리진에 대한 액세스 제한](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) 섹션을 참조하세요.



**중요**  
정적 웹사이트를 호스팅하는 데 사용하는 버킷이 AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 암호화된 경우, 오리진을 보호하기 위해 오리진 액세스 ID(OAI) 대신 오리진 액세스 제어(OAC)를 사용해야 합니다. OAI는 SSE-KMS를 지원하지 않으므로 OAC를 사용해야 합니다. OAC에 대한 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [Amazon S3 오리진에 대한 액세스 제한](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) 섹션을 참조하세요.

**CloudFront OAI를 생성하려면**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창의 **보안** 섹션에서 **오리진 액세스**를 선택합니다.

1. **자격 증명** 탭에서 **오리진 액세스 ID 생성**을 선택합니다.

1. 새로운 원본 액세스 ID에 이름을 입력합니다(예: **S3-OAI**).

1. **생성(Create)**을 선택합니다.

## 4단계: CloudFront 배포 생성
<a name="cf-s3-step4"></a>

CloudFront를 사용하여 S3 버킷에서 비디오를 제공하고 배포하려면 CloudFront 배포를 생성해야 합니다.

**Topics**
+ [CloudFront 배포를 생성합니다.](#cf-s3-step4-create-cloudfront)
+ [버킷 정책 검토](#cf-s3-step4-review-bucket-policy)

### CloudFront 배포를 생성합니다.
<a name="cf-s3-step4-create-cloudfront"></a>

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **배포**를 선택합니다.

1. **배포 생성**을 선택합니다.

1. **원본** 섹션의 **원본 도메인**에서, [1단계](#cf-s3-step1)에서 생성한 S3 버킷의 이름으로 시작하는 S3 원본의 도메인 이름을 선택합니다(예: **tutorial-bucket**).

1. **원본 액세스**에서 **레거시 액세스 ID**를 선택합니다.

1. **원본 액세스 ID**에서, [3단계](#cf-s3-step3)에서 생성한 원본 액세스 ID를 선택합니다(예: **S3-OAI**).

1. **버킷 정책(Bucket policy)**에서, **예, 버킷 정책을 업데이트합니다(Yes, update the bucket policy)**를 선택합니다.

1. **기본 캐시 동작** 섹션의 **뷰어 프로토콜 정책**에서 **HTTP를 HTTPS로 리디렉션**을 선택합니다.

   이 기능을 선택하는 경우, 웹 사이트를 보호하고 뷰어의 데이터를 보호하기 위해 HTTP 요청이 자동으로 HTTPS로 리디렉션됩니다.

1. **기본 캐시 동작** 섹션의 기타 설정은 기본값을 유지하십시오.

   (선택 사항) CloudFront에서 다른 요청을 원본에 전달하기 전에 파일을 CloudFront 캐시에 보관하는 기간을 제어할 수 있습니다. 이 기간을 단축함으로써 동적 콘텐츠를 제공할 수 있습니다. 이 기간이 늘어나면 파일이 엣지 캐시에서 바로 제공될 가능성이 높으므로 뷰어에게 제공되는 성능이 향상됩니다. 보관 기간이 늘어나면 오리진에 걸리는 부하 역시 줄어듭니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [콘텐츠가 엣지 캐시에 유지되는 기간 관리(만료)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html)를 참조하십시오.

1. 다른 섹션의 경우 나머지 설정을 기본값으로 유지합니다.

   다양한 옵션에 대한 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [배포의 생성 또는 업데이트 시 지정하는 값](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html)을 참조하십시오.

1. 페이지 맨 아래에서 **배포 생성(Create distribution)**을 선택합니다.

1. CloudFront 배포에 대한 **일반** 탭의 **세부 정보**에서, 배포에 대한 **마지막 수정 날짜** 열 값이 **배포 중**에서 배포가 마지막으로 수정된 타임스탬프로 변경됩니다. 이 작업은 일반적으로 몇 분 정도 걸립니다.

### 버킷 정책 검토
<a name="cf-s3-step4-review-bucket-policy"></a>

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **버킷(Buckets)**을 선택합니다.

1. **버킷**목록에서, 이전에 CloudFront 배포의 원본으로 사용한 버킷의 이름을 선택합니다(예: **tutorial-bucket**).

1. **권한** 탭을 선택합니다.

1. **버킷 정책** 섹션에서 버킷 정책 텍스트 상자에 다음과 비슷한 문이 표시되는지 확인합니다.

   ```
   {
       "Version": "2008-10-17",		 	 	 
       "Id": "PolicyForCloudFrontPrivateContent",
       "Statement": [
           {
               "Sid": "1",
               "Effect": "Allow",
               "Principal": {
                   "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EH1HDMB1FH2TC"
               },
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::tutorial-bucket/*"
           }
       ]
   }
   ```

   이는 이전에 **예, 버킷 정책을 업데이트합니다**를 선택했을 때CloudFront 배포가 버킷 정책에 추가한 문입니다.

   이 버킷 정책 업데이트는 S3 버킷에 대한 액세스를 제한하도록 CloudFront 배포를 성공적으로 구성했음을 나타냅니다. 이러한 제한으로 인해 CloudFront 배포를 통해서만 버킷의 객체에 액세스할 수 있습니다.

## 5단계: CloudFront 배포를 통해 비디오에 액세스
<a name="cf-s3-step5"></a>

이제 CloudFront는 S3 버킷에 저장된 비디오를 제공할 수 있습니다. CloudFront를 통해 비디오에 액세스하려면 CloudFront 배포 도메인 이름을 S3 버킷의 비디오 경로와 결합해야 합니다.

**CloudFront 배포 도메인 이름을 사용하여 S3 비디오에 대한 URL을 생성하려면**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **배포**를 선택합니다.

1. 배포 도메인 이름을 가져오려면 다음을 수행합니다.

   1. **원본** 열에서, [1단계](#cf-s3-step1)에서 생성한 S3 버킷으로 시작되는 원본 이름을 찾아 올바른 CloudFront 배포를 찾습니다(예: **tutorial-bucket**).

   1. 목록에서 배포를 찾은 후 **도메인 이름** 열을 확장하여 CloudFront 배포의 도메인 이름 값을 복사합니다.

1. 새 브라우저 탭에서, 복사한 배포 도메인 이름을 붙여 넣습니다.

1. 이전 브라우저 탭으로 돌아가 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **버킷**을 선택합니다.

1. **버킷(Buckets)** 목록에서, [1단계](#cf-s3-step1)에서 생성한 버킷의 이름을 선택합니다(예: **tutorial-bucket**).

1. **객체** 목록에서, [2단계](#cf-s3-step2)에서 업로드한 비디오의 이름을 선택합니다(예: `sample.mp4`).

1. 객체 세부 정보 페이지의 **객체 개요** 섹션에서 **키** 값을 복사합니다. 이 값은 S3 버킷에서 업로드된 비디오 객체로의 경로입니다.

1. 이전에 배포 도메인 이름을 붙여 넣은 브라우저 탭으로 돌아가서 배포 도메인 이름 뒤에 사선(**/**)을 입력한 다음, 앞서 복사한 비디오로의 경로를 붙여 넣습니다(예: `sample.mp4`).

   이제 S3 비디오가 다음과 유사한 URL에서 CloudFront를 통해 공개적으로 액세스되고 호스팅됩니다.

   ```
   https://CloudFront distribution domain name/Path to the S3 video
   ```

   *CloudFront 배포 도메인 이름* 및 *S3 비디오로의 경로*를 적절한 값으로 바꿉니다. 예제 URL은 **https://d111111abcdef8.cloudfront.net/sample.mp4**입니다.

## 6단계: 사용자 지정 도메인 이름을 사용하도록 CloudFront 배포 구성
<a name="cf-s3-step6"></a>

URL에서 CloudFront 도메인 이름 대신에 고유의 도메인 이름을 사용하여 S3 비디오에 액세스하려면, 대체 도메인 이름을 CloudFront 배포에 추가합니다.

**Topics**
+ [SSL 인증서 요청](#cf-s3-step6-create-SSL)
+ [CloudFront 배포에 대체 도메인 이름을 추가합니다.](#cf-s3-step6-custom-domain)
+ [대체 도메인 이름에서 트래픽을 CloudFront 배포의 도메인 이름으로 라우팅하는 DNS 레코드를 생성합니다.](#cf-s3-step6-DNS-record)
+ [배포에 대해 IPv6이 활성화되어 있는지 확인하고, 필요한 경우 다른 DNS 레코드를 만듭니다.](#s3-step6-ipv6)

### SSL 인증서 요청
<a name="cf-s3-step6-create-SSL"></a>

뷰어가 동영상 비디오 스트리밍용 URL에 HTTPS 및 사용자 지정 도메인 이름을 사용할 수 있도록 하려면 AWS Certificate Manager(ACM)을(를) 사용하여 보안 소켓 계층(SSL) 인증서를 요청합니다. SSL 인증서는 웹 사이트에 대한 암호화된 네트워크 연결을 설정합니다.

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/)에서 ACM 콘솔을 엽니다.

1. 소개 페이지가 나타나면 **인증서 프로비저닝(Provision certificates)**에서 **시작하기(Get Started)**를 선택합니다.

1. **인증서 요청** 페이지에서 **퍼블릭 인증서 요청**을 선택한 후 **인증서 요청**을 선택합니다.

1. **도메인 이름 추가** 페이지에서 SSL/TLS 인증서로 보안을 설정할 사이트의 정규화된 도메인 이름(FQDN)을 입력합니다. 별표(`*`)를 사용하여 같은 도메인 내의 여러 사이트를 보호하는 와일드카드 인증서를 요청할 수 있습니다. 이 자습서에서는 **\$1** 및 [사전 조건](#cf-s3-prerequisites)에서 구성한 사용자 지정 도메인 이름을 입력합니다. 이 예제의 경우 **\$1.example.com**을 입력한 다음 **다음**을 선택합니다.

   자세한 내용은 *AWS Certificate Manager 사용 설명서*의 [ACM 퍼블릭 인증서를 요청하려면(콘솔)](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html#request-public-console)을 참조하십시오.

1. **검증 방법 선택(Select validation method)** 페이지에서 **DNS 검증(DNS validation)**을 선택합니다. 그리고 **다음**을 선택합니다.

   사용자 DNS 환경 설정을 편집할 수 있다면, 이메일 검증보다는 DNS 검증을 사용하는 것을 권장합니다. DNS 검증은 이메일 검증에 비해 다양한 이점이 있습니다. 자세한 내용은 *AWS Certificate Manager 사용 설명서*의 [옵션 1: DNS 유효성 검사](https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html) 단원을 참조하십시오.

1. (선택 사항) **태그 추가** 페이지에서 인증서에 메타데이터로 태그를 지정할 수 있습니다.

1. **검토**를 선택합니다.

1. **검토** 페이지에서 **도메인 이름** 및 **메서드 검증**의 정보가 올바른지 확인합니다. 그런 다음 **확인 및 요청(Confirm and request)**을 선택합니다.

   **검증** 페이지에서는 요청이 처리 중이며 인증서 도메인이 검증되고 있음을 보여줍니다. 검증 대기 중인 인증서는 **검증 보류(Pending validation)** 상태입니다.

1. **검증** 페이지에서 사용자 지정 도메인 이름의 왼쪽에 있는 아래쪽 화살표를 선택한 후 **Route 53에서 레코드 생성**을 선택하여 DNS를 통해 도메인 소유권을 검증합니다.

   그러면 AWS Certificate Manager에서 제공하는 CNAME 레코드가 DNS 구성에 추가됩니다.

1. **Route 53에서 레코드 생성(Create record in Route 53)** 대화 상자에서 **생성(Create)**을 선택합니다.

   **검증** 페이지의 하단에 **성공**이라는 상태 알림이 표시되어야 합니다.

1. **계속(Continue)**을 선택하여 **인증서(Certificates)** 목록 페이지를 확인합니다.

   새 인증서에 대한 **상태**가 30분 이내에 **검증 보류**에서 **발급 완료**로 변경됩니다.

### CloudFront 배포에 대체 도메인 이름을 추가합니다.
<a name="cf-s3-step6-custom-domain"></a>

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **배포**를 선택합니다.

1. [4단계](#cf-s3-step3)에서 생성한 배포의 ID를 선택합니다.

1. **일반**탭에서 **설정**섹션으로 이동하고 **편집**을 선택합니다.

1. **설정 편집** 페이지에서 **대체 도메인 이름(CNAME) - *선택 사항***의 경우, **항목 추가**를 선택하여 이 CloudFront 배포에서 제공하는 S3 비디오의 URL에 사용하려는 사용자 지정 도메인 이름을 추가합니다.

   이 자습서에서는 예를 들어 하위 도메인(예: `www.example.com`)에 대한 트래픽을 라우팅하려는 경우 도메인 이름(`example.com`)과 함께 하위 도메인 이름(`www`)을 입력합니다. 구체적으로 **www.example.com**을 입력합니다.
**참고**  
추가하는 대체 도메인 이름(CNAME)은 이전에 CloudFront 배포에 연결한 SSL 인증서의 적용을 받아야 합니다.

1. **사용자 지정 SSL 인증서 - *선택 사항***의 경우 이전에 요청한 SSL 인증서를 선택합니다(예: **\$1.example.com**).
**참고**  
SSL 인증서를 요청한 직후에 인증서가 표시되지 않으면 인증서를 선택할 수 있을 때까지 30분간 기다린 다음 목록을 새로 고칩니다.

1. 나머지 설정은 기본값으로 유지합니다. **변경 사항 저장**을 선택합니다.

1. 해당 배포에 대한 **일반** 탭에서, **마지막 수정 날짜** 값이 **배포 중**에서 배포가 마지막으로 수정된 타임스탬프로 변경될 때까지 기다립니다.

### 대체 도메인 이름에서 트래픽을 CloudFront 배포의 도메인 이름으로 라우팅하는 DNS 레코드를 생성합니다.
<a name="cf-s3-step6-DNS-record"></a>

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **Hosted Zones(호스팅 영역)**를 선택합니다.

1. **호스팅 영역** 페이지에서, [사전 조건](#cf-s3-prerequisites)에서 Route 53가 생성한 호스팅 영역의 이름을 선택합니다(예: **example.com**).

1. **레코드 생성**을 선택한 다음 **빠른 레코드 생성** 메서드를 사용합니다.

1. **레코드 이름**의 경우 레코드 이름의 값을 이전에 추가한 CloudFront 배포의 대체 도메인 이름과 동일하게 유지합니다.

   이 자습서에서는 하위 도메인(예: `www.example.com`)에 대한 트래픽을 라우팅하기 위해 도메인 이름 없이 하위 도메인 이름을 입력합니다. 예를 들어, 사용자 지정 도메인 이름 앞의 텍스트 필드에 **www**를 입력합니다.

1. **레코드 유형**에서 **A - IPv4 주소 및 일부 AWS 리소스로 트래픽 라우팅**을 선택합니다.

1. **값**에서 별칭 리소스를 활성화하기 위해 **별칭** 토글을 선택합니다.

1. **다음으로 트래픽 라우팅**의 드롭다운 목록에서 **CloudFront 배포에 대한 별칭**을 선택합니다.

1. **배포 선택**이라는 검색 상자에서, [4단계](#cf-s3-step4)에서 생성한 CloudFront 배포의 도메인 이름을 선택합니다.

   CloudFront 배포의 도메인 이름을 찾으려면 다음을 수행합니다.

   1. 새 브라우저 탭에서 AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/cloudfront/v3/home](https://console.aws.amazon.com/cloudfront/v3/home)에서 CloudFront 콘솔을 엽니다.

   1. 왼쪽 탐색 창에서 **배포**를 선택합니다.

   1. **원본** 열에서, [1단계](#cf-s3-step1)에서 생성한 S3 버킷으로 시작되는 원본 이름을 찾아 올바른 CloudFront 배포를 찾습니다(예: **tutorial-bucket**).

   1. 목록에서 배포를 찾은 후 **도메인 이름** 열을 확장하여 CloudFront 배포의 도메인 이름 값을 확인합니다.

1. Route 53 콘솔의 **레코드 생성** 페이지에서 나머지 설정은 기본값을 유지합니다.

1. **레코드 생성**을 선택합니다.

### 배포에 대해 IPv6이 활성화되어 있는지 확인하고, 필요한 경우 다른 DNS 레코드를 만듭니다.
<a name="s3-step6-ipv6"></a>

배포에 대해 IPv6이 활성화되어 있다면 다른 DNS 레코드를 만들어야 합니다.

1. 배포에 대해 IPv6이 활성화되어 있는지 확인하려면 다음을 수행합니다.

   1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

   1. 왼쪽 탐색 창에서 **배포**를 선택합니다.

   1. [4단계](#cf-s3-step4)에서 생성한 CloudFront 배포의 ID를 선택합니다.

   1. **일반** 탭의 **설정**에서, **IPv6**이 **활성화됨**으로 설정되어 있는지 확인합니다.

      배포에 대해 IPv6이 활성화되어 있다면 다른 DNS 레코드를 만들어야 합니다.

1. 배포에 대해 IPv6이 활성화되어 있다면 다음을 수행하여 다른 DNS 레코드를 만들어야 합니다.

   1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다.

   1. 왼쪽 탐색 창에서 **Hosted Zones(호스팅 영역)**를 선택합니다.

   1. **호스팅 영역** 페이지에서, [사전 조건](#cf-s3-prerequisites)에서 Route 53가 생성한 호스팅 영역의 이름을 선택합니다(예: **example.com**).

   1. **레코드 생성**을 선택한 다음 **빠른 레코드 생성** 메서드를 사용합니다.

   1. **레코드 이름**의 경우, 사용자 지정 도메인 이름 앞의 텍스트 필드에서 이전에 IPv4 DNS 레코드를 생성했을 때 입력한 것과 동일한 값을 입력합니다. 예를 들어 이 자습서에서는 하위 도메인 `www.example.com`의 트래픽을 라우팅하기 위해 **www**만 입력합니다.

   1. **레코드 유형**에서 **AAAA - IPv6 주소 및 일부 AWS 리소스로 트래픽 라우팅**을 선택합니다.

   1. **값**에서 별칭 리소스를 활성화하기 위해 **별칭** 토글을 선택합니다.

   1. **다음으로 트래픽 라우팅**의 드롭다운 목록에서 **CloudFront 배포에 대한 별칭**을 선택합니다.

   1. **배포 선택**이라는 검색 상자에서, [4단계](#cf-s3-step4)에서 생성한 CloudFront 배포의 도메인 이름을 선택합니다.

   1. 나머지 설정은 기본값으로 유지합니다.

   1. **레코드 생성**을 선택합니다.

## 7단계: 사용자 지정 도메인 이름을 사용하여 CloudFront 배포를 통해 S3 비디오에 액세스
<a name="cf-s3-step7"></a>

사용자 지정 URL을 사용하여 S3 비디오에 액세스하려면 대체 도메인 이름을 S3 버킷의 비디오 경로와 결합해야 합니다.

**CloudFront 배포를 통해 S3 비디오에 액세스하기 위한 사용자 지정 URL을 생성하려면**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **배포**를 선택합니다.

1. CloudFront 배포의 대체 도메인 이름을 가져오려면 다음을 수행합니다.

   1. **원본** 열에서, [1단계](#cf-s3-step1)에서 생성한 버킷의 S3 버킷 이름으로 시작되는 원본 이름을 찾아 CloudFront 배포를 찾고 수정합니다(예: **tutorial-bucket**).

   1. 목록에서 배포를 찾은 후 **대체 도메인 이름** 열을 확장하여 CloudFront 배포의 대체 도메인 이름 값을 복사합니다.

1. 새 브라우저 탭에서, CloudFront 배포의 대체 도메인 이름을 붙여 넣습니다.

1. 이전 브라우저 탭으로 돌아가 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. [5단계](#cf-s3-step5)에서 설명하는 S3 비디오의 경로를 찾습니다.

1. 이전에 대체 도메인 이름을 붙여 넣은 브라우저 탭으로 돌아가서 사선(**/**)를 입력하고 S3 비디오의 경로를 붙여 넣습니다(예: `sample.mp4`).

   이제 S3 비디오가 다음과 유사한 사용자 지정 URL에서 CloudFront를 통해 공개적으로 액세스되고 호스팅됩니다.

   ```
   https://CloudFront distribution alternate domain name/Path to the S3 video
   ```

   *CloudFront 배포 대체 도메인 이름* 및 *S3 비디오 경로*를 적절한 값으로 바꿉니다. 예제 URL은 **https://www.example.com/sample.mp4**입니다.

## 8단계: CloudFront 배포에서 수신한 요청에 대한 데이터 보기(선택 사항)
<a name="cf-s3-step8"></a>

**8단계: CloudFront 배포에서 수신한 요청에 대한 데이터를 보려면**

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창의 **보고서 및 분석**에서, **캐시 통계**, **인기 객체**, **상위 참조자**, **사용량** 및 **뷰어**의 범위에서 콘솔의 보고서를 선택합니다.

   각 보고서 대시보드를 필터링할 수 있습니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*에서 [콘솔의 CloudFront 보고서](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/reports.html)를 참조하십시오.

1. 데이터를 필터링하려면 [4단계](#cf-s3-step4)에서 생성한 CloudFront 배포의 ID를 선택합니다.

## 9단계: 정리
<a name="cf-s3-step9"></a>

CloudFront 및 Route 53을 학습 연습으로만 사용하여 S3 스트리밍 비디오를 호스팅한 경우 더 이상 요금이 발생하지 않도록 할당한 AWS 리소스를 삭제합니다.

**참고**  
도메인을 등록하면 즉시 비용이 청구되며, 이는 취소할 수 없습니다. 도메인을 자동 갱신하지 않도록 선택할 수 있지만, 선불로 비용을 지불하며 1년 동안 소유합니다. 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [새 도메인 등록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register.html)을 참조하십시오.

**Topics**
+ [CloudFront 배포 삭제](#cf-s3-step9-delete-cf)
+ [DNS 레코드 삭제](#cf-s3-step9-delete-dns)
+ [사용자 지정 도메인의 퍼블릭 호스팅 영역 삭제](#cf-s3-step9-delete-hosted-zone)
+ [Route 53에서 사용자 지정 도메인 이름 삭제](#cf-s3-step9-delete-domain)
+ [S3 소스 버킷의 원본 비디오 삭제](#cf-s3-step9-delete-video)
+ [S3 소스 버킷 삭제](#cf-s3-step9-delete-bucket)

### CloudFront 배포 삭제
<a name="cf-s3-step9-delete-cf"></a>

1. AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)에서 CloudFront 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **배포**를 선택합니다.

1. **원본** 열에서, [1단계](#cf-s3-step1)에서 생성한 버킷의 S3 버킷 이름으로 시작되는 원본 이름을 찾아 CloudFront 배포를 찾고 수정합니다(예: **tutorial-bucket**).

1. CloudFront 배포를 삭제하려면 먼저 배포를 비활성화해야 합니다.
   + **상태** 열 값이 **활성화됨**이고 **마지막 수정 날짜** 값이 배포가 마지막으로 수정되었을 때의 타임스탬프이면 삭제하기 전에 배포를 비활성화합니다.
   + **상태** 값이 **활성화됨**이고 **마지막 수정 날짜** 값이 **배포 중**이면 **상태** 값이 배포가 마지막으로 수정되었을 때의 타임스탬프로 변경될 때까지 기다립니다. 그런 다음 삭제하기 전에 배포를 비활성화합니다.

1. CloudFront 배포를 비활성화하려면 다음을 수행합니다.

   1. **배포** 목록에서 삭제할 배포에 대한 ID 옆의 확인란을 선택합니다.

   1. 배포를 비활성화하려면 **비활성화**를 선택한 후 **비활성화**를 선택하여 확인합니다.

      대체 도메인 이름이 연결된 배포를 비활성화하면, 동일한 도메인과 일치하는 와일드카드(`*`)가 있는 대체 도메인 이름(예: `*.example.com`)이 다른 배포에 있더라도 CloudFront가 해당 도메인 이름(예: `www.example.com`)에 대한 트래픽 수신을 중지합니다.

   1. **상태(Status)** 값이 **비활성화됨(Disabled)**으로 즉시 변경됩니다. **마지막 수정 날짜** 값이 **배포 중**에서 배포가 마지막으로 수정된 타임스탬프로 변경될 때까지 기다립니다.

      CloudFront는 이 변경 사항을 모든 엣지 로케이션에 전파해야 하므로, 업데이트가 완료되어 배포를 삭제할 수 있는 **삭제(Delete)** 옵션이 사용 가능해질 때까지 몇 분이 걸릴 수 있습니다.

1. 비활성화된 배포를 삭제하려면 다음을 수행합니다.

   1. 삭제하려는 배포의 ID 옆 확인란을 선택합니다.

   1. **삭제**를 선택한 후 **삭제**를 선택하여 확인합니다.

### DNS 레코드 삭제
<a name="cf-s3-step9-delete-dns"></a>

도메인의 퍼블릭 호스팅 영역(DNS 레코드 포함)을 삭제하려면 *Amazon Route 53 개발자 안내서*의 [사용자 지정 도메인의 퍼블릭 호스팅 영역 삭제](#cf-s3-step9-delete-hosted-zone)를 참조하십시오. [6단계](#cf-s3-step6)에서 생성한 DNS 레코드만 삭제하려면 다음을 수행합니다.

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **Hosted Zones(호스팅 영역)**를 선택합니다.

1. **호스팅 영역** 페이지에서, [사전 조건](#cf-s3-prerequisites)에서 Route 53이 생성한 호스팅 영역의 이름을 선택합니다(예: **example.com**).

1. 레코드 목록에서, 삭제하려는 레코드([6단계](#cf-s3-step6)에서 생성한 레코드) 옆의 확인란을 선택합니다.
**참고**  
**유형** 값이 **NS** 또는 **SOA**인 레코드는 삭제할 수 없습니다.

1. **레코드 삭제(Delete record)**를 선택합니다.

1. 삭제를 확인하려면 **삭제**를 선택합니다.

   레코드 변경 내용이 Route 53 DNS 서버로 전파되려면 시간이 걸립니다. 현재 변경 사항의 전파 여부를 확인하는 유일한 방법은 [GetChange API 작업](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)을 사용하는 것입니다. 변경 사항은 일반적으로 60초 이내에 모든 Route 53 이름 서버로 전파됩니다.

### 사용자 지정 도메인의 퍼블릭 호스팅 영역 삭제
<a name="cf-s3-step9-delete-hosted-zone"></a>

**주의**  
도메인 등록을 유지하면서 웹 사이트 또는 웹 애플리케이션으로 인터넷 트래픽이 라우팅되는 것을 중지하려면, 호스팅 영역을 삭제하는 대신 호스팅 영역에서 레코드를 삭제하는 것이 좋습니다(이전 섹션에 설명됨).  
호스팅 영역을 삭제하면 다른 사람이 이 도메인을 사용할 수 있으며 사용자의 도메인 이름을 사용하여 트래픽을 그들의 리소스로 라우팅할 수 있습니다.  
또한 호스팅 영역을 삭제하면 삭제를 취소할 수 없습니다. 새 호스팅 영역을 만들고 도메인 등록을 위한 이름 서버를 업데이트해야 합니다. 도메인 등록은 효력이 발생하려면 최대 48시간이 걸립니다.  
도메인을 인터넷에서 사용 불가능하게 만들려면 먼저 DNS 서비스를 무료 DNS 서비스로 이전한 후 Route 53 호스팅 영역을 삭제합니다. 이렇게 하면 이후의 DNS 쿼리가 잘못 라우팅되지 않도록 할 수 있습니다.  
도메인이 Route 53에 등록되어 있는 경우 Route 53 이름 서버를 새로운 DNS 서비스의 이름 서버로 바꾸는 방법은 *Amazon Route 53 개발자 안내서*의 [도메인의 이름 서버 및 글루 레코드 추가 또는 변경](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-name-servers-glue-records.html)을 참조하십시오.
도메인이 다른 등록 대행자에 등록되어 있는 경우 등록 대행자가 제공한 방법을 사용하여 도메인에 대한 이름 서버를 변경하십시오.
하위 도메인(`www.example.com`)의 호스팅 영역을 삭제하는 경우에는 도메인(`example.com`)의 이름 서버를 변경할 필요가 없습니다.

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **Hosted Zones(호스팅 영역)**를 선택합니다.

1. **호스팅 영역(Hosted zones)** 페이지에서, 삭제할 호스팅 영역의 이름을 선택합니다.

1. 호스팅 영역의 **레코드(Records)** 탭에서, 삭제할 호스팅 영역에 **NS** 및 **SOA**레코드만 포함되어 있는지 확인합니다.

   추가 레코드가 있는 경우 먼저 삭제합니다.

   호스팅 영역의 하위 도메인에 대한 NS 레코드를 생성한 경우, 해당 레코드 역시 삭제합니다.

1. 호스팅 영역의 **DNSSEC 서명(DNSSEC signing)** 탭에서 DNNSSEC 서명을 활성화한 경우 비활성화합니다. 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [DNSSEC 서명 비활성화](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-disable.html)를 참조하십시오.

1. 호스팅 영역의 세부 정보 페이지 상단에서 **영역 삭제**를 선택합니다.

1. 삭제를 확인하려면 **delete**을(를) 입력한 후 **삭제**를 선택합니다.

### Route 53에서 사용자 지정 도메인 이름 삭제
<a name="cf-s3-step9-delete-domain"></a>

TLD(최상위 도메인)에 대해 등록을 더 이상 원하지 않는 경우 등록을 삭제할 수 있습니다. 등록이 만료되기 전에 Route 53에서 도메인 이름 등록을 삭제할 경우 AWS에서는 등록 요금을 환불하지 않습니다. 자세한 내용은 *Amazon Route 53 개발자 가이드*의 [도메인 이름 등록 삭제](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-delete.html)를 참조하십시오.

**중요**  
AWS 계정 간에 도메인을 이전하거나 도메인을 다른 등록 대행사로 이전하려는 경우 도메인을 삭제해서 즉시 재등록하려고 하지 마십시오. 대신 *Amazon Route 53 개발자 가이드*의 해당 문서를 참조하십시오.  
[도메인을 다른 AWS 계정로 이전하기](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-transfer-between-aws-accounts.html)
[Amazon Route 53에서 다른 등록 기관으로 도메인 이전하기](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-transfer-from-route-53.html)

### S3 소스 버킷의 원본 비디오 삭제
<a name="cf-s3-step9-delete-video"></a>

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **버킷(Buckets)**을 선택합니다.

1. **버킷 이름** 목록에서, [2단계](#cf-s3-step2)에서 동영상을 업로드한 버킷의 이름을 선택합니다(예: **tutorial-bucket**).

1. **객체** 탭에서 삭제하려는 객체의 이름 옆에 있는 확인란을 선택합니다(예: `sample.mp4`).

1. **삭제**를 선택합니다.

1. **객체를 영구적으로 삭제하시겠습니까?**에서 **permanently delete**를 입력하여 객체를 삭제할 것인지 확인합니다.

1. **객체 삭제**를 선택합니다.

### S3 소스 버킷 삭제
<a name="cf-s3-step9-delete-bucket"></a>

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **버킷(Buckets)**을 선택합니다.

1. **버킷** 목록에서, [1단계](#cf-s3-step1)에서 생성한 버킷의 이름 옆에 있는 옵션 버튼을 선택합니다(예: **tutorial-bucket**).

1. **삭제**를 선택합니다.

1. **버킷 삭제(Delete bucket)** 페이지의 텍스트 필드에 버킷 이름을 입력하여 버킷의 삭제 여부를 확인한 다음 **버킷 삭제(Delete bucket)**를 선택합니다.

## 다음 단계
<a name="cf-s3-next-steps"></a>

이 자습서를 완료한 후에는 다음과 같은 관련 사용 사례를 더 자세히 탐색할 수 있습니다.
+ CloudFront 배포로 S3 비디오를 호스팅하기 전에 특정 TV 또는 커넥티드 디바이스에 필요한 스트리밍 형식으로 트랜스코딩합니다.

  Amazon S3 배치 작업, AWS Lambda 및 AWS Elemental MediaConvert를 사용하여 비디오 모음을 다양한 출력 미디어 형식으로 일괄 트랜스코딩하려면 [자습서: S3 Batch Operations를 통해 비디오 일괄 트랜스코딩](tutorial-s3-batchops-lambda-mediaconvert-video.md) 섹션을 참조하십시오.
+ CloudFront 및 Route 53을 사용하여 이미지, 오디오, 모션 그래픽, 스타일시트, HTML, JavaScript, React 앱 등 S3에 저장된 다른 객체를 호스팅합니다.

  예제는 [자습서: Route 53에 등록된 사용자 지정 도메인을 사용하여 정적 웹 사이트 구성](website-hosting-custom-domain-walkthrough.md) 및 [Amazon CloudFront로 웹사이트 속도 향상](website-hosting-cloudfront-walkthrough.md) 섹션을 참조하십시오.
+ [Amazon S3 Transfer Acceleration](https://aws.amazon.com/s3/transfer-acceleration)을 사용하여 빠르고 안전한 파일 전송을 구성할 수 있습니다. Transfer Acceleration을 사용하면 S3 버킷에 비디오를 빠르게 업로드하여 대용량의 비디오를 장거리 전송할 수 있습니다. Transfer Acceleration은 CloudFront의 전역으로 배포된 엣지 로케이션 및 AWS 백본 네트워크를 통해 트래픽을 라우팅하여 전송 성능을 향상시킵니다. 또한 네트워크 프로토콜 최적화를 활용합니다. 자세한 내용은 [Amazon S3 Transfer Acceleration을 사용하여 빠르고 안전한 파일 전송 구성](transfer-acceleration.md) 섹션을 참조하세요.

# 자습서: Amazon S3에서 정적 웹 사이트 구성
<a name="HostingWebsiteOnS3Setup"></a>

**중요**  
이제 Amazon S3가 Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)를 Amazon S3 내 모든 버킷 암호화의 기본 수준으로 적용합니다. 2023년 1월 5일부터 Amazon S3로의 모든 새 객체 업로드는 추가 비용 없이 성능에 영향을 미치지 않고 자동으로 암호화됩니다. S3 버킷 기본 암호화 구성에 및 신규 객체 업로드에 대한 자동 암호화 상태는 CloudTrail 로그, S3 인벤토리, S3 Storage Lens, Amazon S3 콘솔에서 사용할 수 있으며, AWS CLI 및 AWS SDK에서 추가 Amazon S3 API 응답 헤더로도 사용할 수 있습니다. 자세한 내용은 [기본 암호화 관련 FAQ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-encryption-faq.html)를 참조하십시오.

웹 사이트처럼 작동하도록 Amazon S3 버킷을 구성할 수 있습니다. 이 예제에서는 Amazon S3에서 웹 사이트를 호스팅하는 절차를 단계별로 살펴봅니다.

**중요**  
다음 자습서에서는 퍼블릭 액세스 차단을 비활성화해야 합니다. 퍼블릭 액세스 차단 설정을 활성화 상태로 유지하는 것이 좋습니다. 네 개의 퍼블릭 액세스 차단 설정을 모두 활성화하여 정적 웹 사이트를 호스팅하려는 경우 Amazon CloudFront 원본 액세스 제어(OAC)를 사용할 수 있습니다. Amazon CloudFront는 안전한 정적 웹 사이트를 설정하는 데 필요한 기능을 제공합니다. Amazon S3 정적 웹 사이트는 HTTP 엔드포인트만 지원합니다. Amazon CloudFront는 Amazon S3의 내구성 있는 스토리지를 사용하면서 HTTPS와 같은 추가 보안 헤더를 제공합니다. HTTPS는 일반적인 HTTP 요청을 암호화하고 일반적인 사이버 공격으로부터 보호함으로써 보안을 강화합니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [안전한 정적 웹 사이트 시작하기](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/getting-started-secure-static-website-cloudformation-template.html)를 참조하십시오.

**Topics**
+ [1단계: 버킷 만들기](#step1-create-bucket-config-as-website)
+ [2단계: 정적 웹 사이트 호스팅 활성화](#step2-create-bucket-config-as-website)
+ [3단계: 퍼블릭 액세스 차단 설정 편집](#step3-edit-block-public-access)
+ [4단계: 버킷 콘텐츠를 공개적으로 사용 가능하도록 설정하는 버킷 정책 추가](#step4-add-bucket-policy-make-content-public)
+ [5단계: 인덱스 문서 구성](#step5-upload-index-doc)
+ [6단계: 오류 문서 구성](#step6-upload-error-doc)
+ [7단계: 웹 사이트 엔드포인트 테스트](#step7-test-web-site)
+ [8단계: 정리](#getting-started-cleanup-s3-website-overview)

## 1단계: 버킷 만들기
<a name="step1-create-bucket-config-as-website"></a>

아래 지침에서는 웹 사이트 호스팅용 버킷을 생성하는 방법에 대한 개요를 제공합니다. 버킷 생성에 대한 자세한 단계별 지침은 [범용 버킷 생성](create-bucket-overview.md) 섹션을 참조하세요.

**버킷을 만들려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. **버킷 만들기**를 선택합니다.

1. **버킷 이름**(예: **example.com**)을 입력합니다.

1. 버킷을 생성하려는 리전을 선택합니다.

   지리적으로 가까운 리전을 선택하면 지연 시간과 요금을 최소화하고, 규제 요건을 해결할 수 있습니다. 선택한 리전에 따라 Amazon S3 웹 사이트 엔드포인트가 결정됩니다. 자세한 내용은 [웹 사이트 엔드포인트](WebsiteEndpoints.md) 섹션을 참조하세요.

1. 기본 설정을 적용하고 버킷을 생성하려면 [**Create**]를 선택합니다.

## 2단계: 정적 웹 사이트 호스팅 활성화
<a name="step2-create-bucket-config-as-website"></a>

버킷을 생성한 후 버킷에 정적 웹 사이트 호스팅을 활성화할 수 있습니다. 새 버킷을 만들거나 기존 버킷을 사용할 수 있습니다.

**정적 웹 사이트 호스팅을 활성화하려면**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. 버킷 목록에서 정적 웹 사이트 호스팅을 사용 설정하려는 버킷의 이름을 선택합니다.

1. [**속성(Properties)**]을 선택합니다.

1. **정적 웹 사이트 호스팅(Static website hosting)**에서 **편집(Edit)**을 선택합니다.

1. **이 버킷을 사용하여 웹 사이트를 호스팅합니다.**를 선택합니다.

1. **정적 웹 사이트 호스팅**에서 **사용**을 선택합니다.

1. **인덱스 문서(Index document)**에 인덱스 문서 이름을 입력합니다(일반적으로 `index.html`).

   인덱스 문서 이름은 대소문자를 구분하며 S3 버킷에 업로드하려는 HTML 인덱스 문서의 파일 이름과 정확히 일치해야 합니다. 웹 사이트 호스팅용 버킷을 구성하는 경우 인덱스 문서를 지정해야 합니다. 루트 도메인이나 임의의 하위 폴더로 요청이 전송되면 Amazon S3가 이 인덱스 문서를 반환합니다. 자세한 내용은 [인덱스 문서 구성](IndexDocumentSupport.md) 섹션을 참조하세요.

1. 4XX 클래스 오류에 대한 사용자 지정 오류 문서를 제공하려면 [**오류 문서(Error document)**]에 사용자 지정 오류 문서 파일 이름을 입력합니다.

   오류 문서 이름은 대소문자를 구분하며 S3 버킷에 업로드하려는 HTML 오류 문서의 파일 이름과 정확히 일치해야 합니다. 사용자 지정 오류 문서를 지정하지 않았는데 오류가 발생하면 Amazon S3에서 기본 HTML 오류 문서를 반환합니다. 자세한 내용은 [사용자 지정 오류 문서 구성](CustomErrorDocSupport.md) 섹션을 참조하세요.

1. (선택 사항) 고급 리디렉션 규칙을 지정하려면 **리디렉션 규칙(Redirection rules)**에 JSON을 입력하여 규칙을 설명합니다.

   예를 들어, 요청의 특정 객체 키 이름 또는 접두사에 따라 조건부로 요청을 라우팅할 수 있습니다. 자세한 내용은 [고급 조건부 리디렉션을 사용하도록 리디렉션 규칙 구성](how-to-page-redirect.md#advanced-conditional-redirects) 섹션을 참조하세요.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.

   Amazon S3는 버킷에 대한 정적 웹 사이트 호스팅을 지원합니다. 페이지 하단의 **정적 웹 사이트 호스팅(Static website hosting)**에 버킷의 웹 사이트 엔드포인트가 표시됩니다.

1. **정적 웹 사이트 호스팅**에서 **엔드포인트**를 기록합니다.

   **엔드포인트**는 버킷의 Amazon S3 웹 사이트 엔드포인트입니다. 버킷을 정적 웹 사이트로 구성한 후 이 엔드포인트를 사용하여 웹 사이트를 테스트할 수 있습니다.

## 3단계: 퍼블릭 액세스 차단 설정 편집
<a name="step3-edit-block-public-access"></a>

기본적으로 Amazon S3은 계정 및 버킷에 대한 퍼블릭 액세스를 차단합니다. 버킷을 사용하여 정적 웹 사이트를 호스팅하려는 경우 이러한 단계를 사용하여 퍼블릭 액세스 차단 설정을 편집할 수 있습니다.

**주의**  
이러한 단계를 완료하기 전에 [Amazon S3 스토리지에 대한 퍼블릭 액세스 차단](access-control-block-public-access.md)을 검토하여 퍼블릭 액세스 허용과 관련된 위험을 이해하고 이에 동의하는지 확인합니다. 퍼블릭 액세스 차단 설정을 해제하여 버킷을 퍼블릭으로 만들면 인터넷상의 모든 사용자가 버킷에 액세스할 수 있습니다. 버킷에 대한 모든 퍼블릭 액세스를 차단하는 것이 좋습니다.

1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 정적 웹 사이트로 구성한 버킷의 이름을 선택합니다.

1. **Permissions**를 선택합니다.

1. **퍼블릭 액세스 차단(버킷 설정)(Block public access (bucket settings))**에서 **편집(Edit)**을 선택합니다.

1. ***모든* 퍼블릭 액세스 차단(Block all public access)**을 선택 취소하고 **변경 사항 저장(Save changes)**을 선택합니다.  
![\[퍼블릭 액세스 차단 버킷 설정을 보여주는 Amazon S3 콘솔.\]](http://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/images/edit-public-access-clear.png)

   Amazon S3은 버킷에 대한 퍼블릭 액세스 차단 설정을 끕니다. 정적 퍼블릭 웹 사이트를 생성하려면 버킷 정책을 추가하기 전에 계정에 대한 [퍼블릭 액세스 차단 설정을 편집](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/block-public-access-account.html)해야 할 수도 있습니다. 계정에 대한 퍼블릭 액세스 차단 설정이 현재 켜져 있는 경우 **퍼블릭 액세스 차단(버킷 설정)** 아래에 메모가 표시됩니다.

## 4단계: 버킷 콘텐츠를 공개적으로 사용 가능하도록 설정하는 버킷 정책 추가
<a name="step4-add-bucket-policy-make-content-public"></a>

S3 퍼블릭 액세스 차단 설정을 편집한 후에는 버킷 정책을 추가하여 버킷에 퍼블릭 읽기 액세스 권한을 부여할 수 있습니다. 퍼블릭 읽기 액세스 권한을 부여하면 인터넷의 모든 사용자가 버킷에 액세스할 수 있습니다.

**중요**  
다음 정책은 하나의 예일 뿐이며 버킷의 콘텐츠에 대한 전체 액세스를 허용합니다. 이 단계를 진행하기 전에 [Amazon S3 버킷에 있는 파일을 보호하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/secure-s3-resources/)를 검토하여 S3 버킷의 파일 보안을 위한 모범 사례 및 퍼블릭 액세스 권한 부여와 관련된 위험을 파악할 수 있습니다.

1. **버킷**에서 버킷의 이름을 선택합니다.

1. **Permissions**를 선택합니다.

1. **버킷 정책(Bucket Policy)**에서 **편집(Edit)**을 선택합니다.

1. 웹 사이트에 대한 퍼블릭 읽기 액세스 권한을 부여하려면 다음 버킷 정책을 복사한 후 **버킷 정책 편집기**에 붙여 넣습니다.

   ```
   {
       "Version": "2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "PublicReadGetObject",
               "Effect": "Allow",
               "Principal": "*",
               "Action": [
                   "s3:GetObject"
               ],
               "Resource": [
                   "arn:aws:s3:::Bucket-Name/*"
               ]
           }
       ]
   }
   ```

1. `Resource`를 버킷 이름으로 업데이트합니다.

   앞의 버킷 정책 예제에서 *Bucket-Name*은 버킷 이름의 자리 표시자입니다. 자체 버킷에 이 버킷 정책을 사용하려면 자체 버킷 이름과 일치하도록 이 이름을 업데이트해야 합니다.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.

   버킷 정책이 성공적으로 추가되었음을 나타내는 메시지가 나타납니다.

   `Policy has invalid resource`라는 오류가 표시되면 버킷 정책의 버킷 이름이 사용자의 버킷 이름과 일치하는지 확인합니다. 버킷 정책 추가에 대한 자세한 내용은 [S3 버킷 정책을 추가하려면 어떻게 해야 하나요?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html)를 참조하십시오.

   오류 메시지가 나타나고 버킷 정책을 저장할 수 없는 경우 계정 및 버킷의 퍼블릭 액세스 차단 설정에서 버킷에 대한 퍼블릭 액세스를 허용하는지 확인합니다.

## 5단계: 인덱스 문서 구성
<a name="step5-upload-index-doc"></a>

버킷용 정적 웹 사이트 호스팅을 활성화할 때 인덱스 문서의 이름(예: **index.html**)을 입력합니다. 버킷용 정적 웹 사이트 호스팅을 사용 설정한 후 인덱스 문서 이름이 있는 HTML 파일을 버킷에 업로드합니다.

**인덱스 문서 구성**

1. `index.html` 파일을 생성합니다.

   `index.html` 파일이 없으면 다음 HTML을 사용하여 파일을 생성할 수 있습니다.

   ```
   <html xmlns="http://www.w3.org/1999/xhtml" >
   <head>
       <title>My Website Home Page</title>
   </head>
   <body>
     <h1>Welcome to my website</h1>
     <p>Now hosted on Amazon S3!</p>
   </body>
   </html>
   ```

1. 인덱스 파일을 로컬에 저장합니다.

   인덱스 문서 파일 이름은 **정적 웹 사이트 호스팅** 대화 상자에 입력한 인덱스 문서 이름과 정확히 일치해야 합니다. 인덱스 문서 이름은 대/소문자를 구분합니다. 예를 들어 **정적 웹 사이트 호스팅** 대화 상자에서 **인덱스 문서** 이름에 `index.html`을 입력하는 경우, 인덱스 문서 파일은 `index.html`이 아니라 `Index.html`이어야 합니다.

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. 버킷 목록에서 정적 웹 사이트를 호스팅하는 데 사용할 버킷의 이름을 선택합니다.

1. 버킷에 정적 웹 사이트 호스팅을 사용 설정하고 인덱스 문서의 정확한 이름(예: `index.html`)을 입력합니다. 자세한 내용은 [웹 사이트 호스팅 사용 설정](EnableWebsiteHosting.md) 섹션을 참조하세요.

   정적 웹 사이트 호스팅을 사용 설정한 후 6단계로 이동합니다.

1. 버킷에 인덱스 문서를 업로드하려면 다음 중 하나를 수행합니다.
   + 인덱스 파일을 콘솔 버킷 목록으로 끌어다 놓습니다.
   + **업로드**를 선택하고 프롬프트의 메시지에 따라 인덱스 파일을 선택하고 업로드합니다.

   단계별 지침은 [객체 업로드](upload-objects.md) 섹션을 참조하세요.

1. (선택 사항) 버킷에 다른 웹 사이트 콘텐츠를 업로드합니다.

## 6단계: 오류 문서 구성
<a name="step6-upload-error-doc"></a>

버킷용 정적 웹 사이트 호스팅을 활성화할 때 오류 문서의 이름(예: **404.html**)을 입력합니다. 버킷용 정적 웹 사이트 호스팅을 사용 설정한 후 오류 문서 이름이 있는 HTML 파일을 버킷에 업로드합니다.

**오류 문서 구성**

1. 오류 문서를 생성합니다(예: `404.html`).

1. 오류 문서 파일을 로컬에 저장합니다.

   오류 문서 이름은 대/소문자를 구분하며 정적 웹 사이트 호스팅을 사용하도록 설정할 때 입력한 이름과 정확히 일치해야 합니다. 예를 들어 **정적 웹 사이트 호스팅** 대화 상자에서 **오류 문서** 이름에 `404.html`을 입력하는 경우, 오류 문서 파일은 `404.html`이어야 합니다.

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. 버킷 목록에서 정적 웹 사이트를 호스팅하는 데 사용할 버킷의 이름을 선택합니다.

1. 버킷에 정적 웹 사이트 호스팅을 사용 설정하고 오류 문서의 정확한 이름(예: `404.html`)을 입력합니다. 자세한 내용은 [웹 사이트 호스팅 사용 설정](EnableWebsiteHosting.md) 및 [사용자 지정 오류 문서 구성](CustomErrorDocSupport.md)(을)를 참조하세요.

   정적 웹 사이트 호스팅을 사용 설정한 후 6단계로 이동합니다.

1. 버킷에 오류 문서를 업로드하려면 다음 중 하나를 수행합니다.
   + 오류 문서 파일을 콘솔 버킷 목록으로 끌어다 놓습니다.
   + **업로드**를 선택하고 프롬프트의 메시지에 따라 인덱스 파일을 선택하고 업로드합니다.

   단계별 지침은 [객체 업로드](upload-objects.md) 섹션을 참조하세요.

## 7단계: 웹 사이트 엔드포인트 테스트
<a name="step7-test-web-site"></a>

버킷에 대한 정적 웹 사이트 호스팅을 구성한 후 웹 사이트 엔드포인트를 테스트할 수 있습니다.

**참고**  
Amazon S3에서는 웹 사이트에 대한 HTTPS 액세스를 지원하지 않습니다. HTTPS를 사용하려는 경우 Amazon CloudFront를 사용하여 Amazon S3에서 호스팅되는 정적 웹 사이트를 제공할 수 있습니다.  
자세한 내용은 [CloudFront를 사용하여 Amazon S3에 호스팅된 정적 웹 사이트를 제공하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-serve-static-website/) 및 [최종 사용자와 CloudFront 간의 통신에 HTTPS 요구](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html)를 참조하십시오.

1. **버킷**에서 버킷의 이름을 선택합니다.

1. [**속성(Properties)**]을 선택합니다.

1. 페이지 하단의 **정적 웹 사이트 호스팅(Static website hosting)**에서 **버킷 웹 사이트 엔드포인트(Bucket website endpoint)**를 선택합니다.

   인덱스 문서가 별도의 브라우저 창에서 열립니다.

이제 Amazon S3에 웹 사이트가 호스팅되었습니다. 이 웹 사이트는 Amazon S3 웹 사이트 엔드포인트를 통해 제공됩니다. 하지만, 사용자가 만든 웹 사이트의 콘텐츠를 표시하기 위해 `example.com`과 같은 도메인을 사용하고자 할 수도 있습니다. 또한 Amazon S3의 루트 도메인 지원을 통해 `http://www.example.com` 및 `http://example.com` 모두에 대한 요청을 처리하고자 할 수도 있습니다. 이 경우 다음 단계를 따라야 합니다. 관련 예제는 [자습서: Route 53에 등록된 사용자 지정 도메인을 사용하여 정적 웹 사이트 구성](website-hosting-custom-domain-walkthrough.md) 섹션을 참조하세요 

## 8단계: 정리
<a name="getting-started-cleanup-s3-website-overview"></a>

실습용으로만 정적 웹 사이트를 생성한 경우에는 요금이 발생하지 않도록 할당한 AWS 리소스를 삭제합니다. AWS 리소스를 삭제한 후에는 웹 사이트를 사용할 수 없습니다. 자세한 내용은 [범용 버킷 삭제](delete-bucket.md) 섹션을 참조하세요.

# 자습서: Route 53에 등록된 사용자 지정 도메인을 사용하여 정적 웹 사이트 구성
<a name="website-hosting-custom-domain-walkthrough"></a>

Amazon S3에서 정적 웹 사이트를 호스팅하는 경우를 가정합니다. 예를 들어 `example.com`과 같은 도메인을 Amazon Route 53에 등록하고 Amazon S3 콘텐츠에서 `http://www.example.com` 및 `http://example.com`에 대한 요청을 수행하게 합니다. 이 연습을 사용하여 정적 웹 사이트를 호스팅하고 사용자 지정 도메인 이름이 Route 53에 등록된 웹 사이트에 대한 리디렉션을 Amazon S3에 만드는 방법을 학습할 수 있습니다. Amazon S3에서 호스팅할 기존 웹 사이트로 작업하거나 이 연습을 사용하여 처음부터 시작할 수 있습니다.

이 연습을 완료한 후에는 필요에 따라 Amazon CloudFront를 사용하여 웹 사이트의 성능을 향상시킬 수 있습니다. 자세한 내용은 [Amazon CloudFront로 웹사이트 속도 향상](website-hosting-cloudfront-walkthrough.md) 섹션을 참조하세요.

**참고**  
Amazon S3 웹 사이트 엔드포인트는 HTTPS 또는 액세스 포인트를 지원하지 않습니다. HTTPS를 사용하려는 경우 Amazon CloudFront를 사용하여 Amazon S3에서 호스팅되는 정적 웹 사이트를 제공할 수 있습니다.  
CloudFront 및 Amazon S3를 사용하여 콘텐츠를 안전하게 호스팅하는 방법에 대한 자세한 내용은 [자습서: Amazon S3, Amazon CloudFront 및 Amazon Route 53로 온디맨드 스트리밍 비디오 호스팅](tutorial-s3-cloudfront-route53-video-streaming.md) 섹션을 참조하세요. 자세한 내용은 [CloudFront를 사용하여 Amazon S3에 호스팅된 정적 웹 사이트를 제공하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-serve-static-website/) 및 [최종 사용자와 CloudFront 간의 통신에 HTTPS 요구](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html)를 참조하세요.

**CloudFormation 템플릿으로 정적 웹 사이트 설정 자동화**  
CloudFormation 템플릿을 사용하여 정적 웹 사이트 설정을 자동화할 수 있습니다. CloudFormation 템플릿은 안전한 정적 웹 사이트를 호스팅하는 데 필요한 구성 요소를 설정하므로 구성 요소의 구성에 대한 비중은 낮추고 웹 사이트의 콘텐츠에 더 중점을 둘 수 있습니다.

CloudFormation 템플릿에는 다음 구성 요소가 포함됩니다.
+ Amazon S3 ‐ 정적 웹 사이트를 호스팅할 Amazon S3 버킷을 생성합니다.
+ CloudFront - 정적 웹 사이트의 속도를 높이기 위해 CloudFront 배포를 생성합니다.
+ Lambda@Edge - [Lambda@Edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-at-the-edge.html)를 사용하여 모든 서버 응답에 보안 헤더를 추가합니다. 보안 헤더는 웹 서버 응답에서 웹 브라우저에 추가 보안 예방 조치를 취하도록 알려주는 헤더 그룹입니다. 자세한 내용은 [Lambda@Edge 및 Amazon CloudFront를 사용하여 HTTP 보안 헤더 추가](https://aws.amazon.com/blogs/networking-and-content-delivery/adding-http-security-headers-using-lambdaedge-and-amazon-cloudfront/) 블로그 게시물을 참조하십시오.

이 CloudFormation 템플릿은 다운로드하여 사용할 수 있습니다. 자세한 내용과 지침은 *Amazon CloudFront 개발자 안내서*의 [안전한 정적 웹 사이트 시작하기](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/getting-started-secure-static-website-cloudformation-template.html)를 참조하십시오.

**Topics**
+ [시작하기 전에](#root-domain-walkthrough-before-you-begin)
+ [1단계: Route 53에 사용자 지정 도메인 등록](#website-hosting-custom-domain-walkthrough-domain-registry)
+ [2단계: 두 개의 버킷 생성](#root-domain-walkthrough-create-buckets)
+ [3단계: 웹 사이트 호스팅용 루트 도메인 버킷 구성](#root-domain-walkthrough-configure-bucket-aswebsite)
+ [4단계: 웹 사이트 리디렉션용 하위 도메인 버킷 구성](#root-domain-walkthrough-configure-redirect)
+ [5단계: 웹 사이트 트래픽용 로깅 구성](#root-domain-walkthrough-configure-logging)
+ [6단계: 인덱스 및 웹 사이트 콘텐츠 업로드](#upload-website-content)
+ [7단계: 오류 문서 업로드](#configure-error-document-root-domain)
+ [8단계: S3 퍼블릭 액세스 차단 설정 편집](#root-domain-walkthrough-configure-bucket-permissions)
+ [9단계: 버킷 정책 연결](#add-bucket-policy-root-domain)
+ [10단계: 도메인 엔드포인트 테스트](#root-domain-walkthrough-test-website)
+ [11단계: 도메인 및 하위 도메인에 대한 별칭 레코드 추가](#root-domain-walkthrough-add-record-to-hostedzone)
+ [12단계: 웹 사이트 테스트](#root-domain-testing)
+ [Amazon CloudFront로 웹사이트 속도 향상](website-hosting-cloudfront-walkthrough.md)
+ [예제 리소스 정리](getting-started-cleanup.md)

## 시작하기 전에
<a name="root-domain-walkthrough-before-you-begin"></a>

이 예제의 단계에 따르려면 다음과 같이 작업을 합니다.

**Amazon Route 53** – Route 53을 사용하여 도메인을 등록하고 도메인의 인터넷 트래픽을 라우팅할 위치를 정의합니다. 이 예제는 도메인(`example.com`) 및 하위 도메인(`www.example.com`)의 트래픽을 HTML 파일이 포함된 Amazon S3 버킷으로 라우팅하는 Route 53 별칭 레코드의 생성 방법을 보여줍니다.

**Amazon S3** – Amazon S3을 사용하여 버킷을 생성하고 샘플 웹 사이트 페이지를 업로드해 모든 사용자가 콘텐츠를 볼 수 있도록 권한을 구성한 뒤, 웹 사이트 호스팅용 버킷을 구성합니다.

## 1단계: Route 53에 사용자 지정 도메인 등록
<a name="website-hosting-custom-domain-walkthrough-domain-registry"></a>

등록된 도메인 이름(예: `example.com`)이 아직 없으면 Route 53에 등록합니다. 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [새 도메인 등록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register.html)을 참조하십시오. 도메인 이름을 등록한 후 웹 사이트 호스팅용 Amazon S3 버킷을 생성하고 구성할 수 있습니다.

## 2단계: 두 개의 버킷 생성
<a name="root-domain-walkthrough-create-buckets"></a>

루트 도메인 및 하위 도메인의 요청을 모두 지원하려면 두 개의 버킷을 생성합니다.
+ **도메인 버킷** - `example.com`
+ **하위 도메인 버킷** - `www.example.com` 

이러한 버킷 이름은 도메인 이름과 정확히 일치해야 합니다. 이 예제에서 도메인 이름은 `example.com`입니다. 루트 도메인 버킷(`example.com`)에서 콘텐츠를 호스팅합니다. 하위 도메인 버킷(`www.example.com`)에 대한 리디렉션 요청을 만듭니다. 누군가가 브라우저에 `www.example.com`을 입력하면 `example.com`으로 리디렉션되고 해당 이름을 가진 Amazon S3 버킷에서 호스팅되는 콘텐츠가 표시됩니다.

**웹 사이트 호스팅용 버킷 생성**

아래 지침에서는 웹 사이트 호스팅용 버킷을 생성하는 방법에 대한 개요를 제공합니다. 버킷 생성에 대한 자세한 단계별 지침은 [범용 버킷 생성](create-bucket-overview.md) 섹션을 참조하십시오.

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 루트 도메인 버킷을 생성합니다.

   1. 페이지 상단의 탐색 모음에서 현재 표시된 AWS 리전의 이름을 선택합니다. 그런 다음 버킷을 생성하려는 리전을 선택합니다.
**참고**  
지연 시간과 요금을 최소화하고 규제 요건을 충족하려면 가장 가까운 리전을 선택하십시오. 특정 리전에 저장된 객체는 사용자가 명시적으로 객체를 다른 리전으로 전송하지 않는 한 해당 리전을 벗어나지 않습니다. Amazon S3 AWS 리전 목록은 **Amazon Web Services 일반 참조의 [AWS 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region)를 참조하십시오.

   1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

   1. **버킷 만들기**를 선택합니다. **버킷 만들기** 페이지가 열립니다.

   1. **버킷 이름**(예: **example.com**)을 입력합니다.

   1. 버킷을 생성하려는 리전을 선택합니다.

      지리적으로 가까운 리전을 선택하면 지연 시간과 요금을 최소화하고, 규제 요건을 해결할 수 있습니다. 선택한 리전에 따라 Amazon S3 웹 사이트 엔드포인트가 결정됩니다. 자세한 내용은 [웹 사이트 엔드포인트](WebsiteEndpoints.md) 섹션을 참조하세요.

   1. 기본 설정을 적용하고 버킷을 생성하려면 [**Create**]를 선택합니다.

1. 하위 도메인 버킷을 생성합니다.

   1. **버킷 만들기**를 선택합니다.

   1. **버킷 이름**(예: **www.example.com**)을 입력합니다.

   1. 버킷을 생성하려는 리전을 선택합니다.

      지리적으로 가까운 리전을 선택하면 지연 시간과 요금을 최소화하고, 규제 요건을 해결할 수 있습니다. 선택한 리전에 따라 Amazon S3 웹 사이트 엔드포인트가 결정됩니다. 자세한 내용은 [웹 사이트 엔드포인트](WebsiteEndpoints.md) 섹션을 참조하세요.

   1. 기본 설정을 적용하고 버킷을 생성하려면 [**Create**]를 선택합니다.

다음 단계에서는 웹 사이트 호스팅을 위한 `example.com`을 구성합니다.

## 3단계: 웹 사이트 호스팅용 루트 도메인 버킷 구성
<a name="root-domain-walkthrough-configure-bucket-aswebsite"></a>

이 단계에서는 루트 도메인 버킷(`example.com`)을 웹 사이트로 구성합니다. 이 버킷은 사용자의 웹 사이트 콘텐츠를 포함합니다. 웹 사이트 호스팅용 버킷을 구성할 때 [웹 사이트 엔드포인트](WebsiteEndpoints.md)를 사용하여 웹 사이트에 액세스할 수 있습니다.

**정적 웹 사이트 호스팅 사용 설정**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. 버킷 목록에서 정적 웹 사이트 호스팅을 사용 설정하려는 버킷의 이름을 선택합니다.

1. [**속성(Properties)**]을 선택합니다.

1. **정적 웹 사이트 호스팅(Static website hosting)**에서 **편집(Edit)**을 선택합니다.

1. **이 버킷을 사용하여 웹 사이트를 호스팅합니다.**를 선택합니다.

1. **정적 웹 사이트 호스팅**에서 **사용**을 선택합니다.

1. **인덱스 문서(Index document)**에 인덱스 문서 이름을 입력합니다(일반적으로 `index.html`).

   인덱스 문서 이름은 대소문자를 구분하며 S3 버킷에 업로드하려는 HTML 인덱스 문서의 파일 이름과 정확히 일치해야 합니다. 웹 사이트 호스팅용 버킷을 구성하는 경우 인덱스 문서를 지정해야 합니다. 루트 도메인이나 임의의 하위 폴더로 요청이 전송되면 Amazon S3가 이 인덱스 문서를 반환합니다. 자세한 내용은 [인덱스 문서 구성](IndexDocumentSupport.md) 섹션을 참조하세요.

1. 4XX 클래스 오류에 대한 사용자 지정 오류 문서를 제공하려면 [**오류 문서(Error document)**]에 사용자 지정 오류 문서 파일 이름을 입력합니다.

   오류 문서 이름은 대소문자를 구분하며 S3 버킷에 업로드하려는 HTML 오류 문서의 파일 이름과 정확히 일치해야 합니다. 사용자 지정 오류 문서를 지정하지 않았는데 오류가 발생하면 Amazon S3에서 기본 HTML 오류 문서를 반환합니다. 자세한 내용은 [사용자 지정 오류 문서 구성](CustomErrorDocSupport.md) 섹션을 참조하세요.

1. (선택 사항) 고급 리디렉션 규칙을 지정하려면 **리디렉션 규칙(Redirection rules)**에 JSON을 입력하여 규칙을 설명합니다.

   예를 들어, 요청의 특정 객체 키 이름 또는 접두사에 따라 조건부로 요청을 라우팅할 수 있습니다. 자세한 내용은 [고급 조건부 리디렉션을 사용하도록 리디렉션 규칙 구성](how-to-page-redirect.md#advanced-conditional-redirects) 섹션을 참조하세요.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.

   Amazon S3는 버킷에 대한 정적 웹 사이트 호스팅을 지원합니다. 페이지 하단의 **정적 웹 사이트 호스팅(Static website hosting)**에 버킷의 웹 사이트 엔드포인트가 표시됩니다.

1. **정적 웹 사이트 호스팅**에서 **엔드포인트**를 기록합니다.

   **엔드포인트**는 버킷의 Amazon S3 웹 사이트 엔드포인트입니다. 버킷을 정적 웹 사이트로 구성한 후 이 엔드포인트를 사용하여 웹 사이트를 테스트할 수 있습니다.

[퍼블릭 액세스 차단 설정을 편집](https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-custom-domain-walkthrough.html#root-domain-walkthrough-configure-bucket-permissions)하고 퍼블릭 읽기 액세스를 허용하는 [버킷 정책을 추가](https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-custom-domain-walkthrough.html#add-bucket-policy-root-domain)한 후 웹 사이트 엔드포인트를 사용하여 웹 사이트에 액세스할 수 있습니다.

다음 단계에서는 하위 도메인(`www.example.com`)을 구성하여 요청을 도메인(`example.com`)으로 리디렉션합니다.

## 4단계: 웹 사이트 리디렉션용 하위 도메인 버킷 구성
<a name="root-domain-walkthrough-configure-redirect"></a>

웹 사이트 호스팅용 루트 도메인 버킷을 구성하면 도메인에 대한 모든 요청을 리디렉션하도록 하위 도메인 버킷을 구성할 수 있습니다. 이 예제에서 `www.example.com`에 대한 모든 요청은 `example.com`으로 리디렉션됩니다.

**리디렉션 요청 구성**

1. Amazon S3 콘솔의 **범용 버킷** 목록에서 하위 도메인 버킷 이름(이 예시에서는 `www.example.com`)을 선택합니다.

1. [**속성(Properties)**]을 선택합니다.

1. **정적 웹 사이트 호스팅(Static website hosting)**에서 **편집(Edit)**을 선택합니다.

1. **객체에 대한 요청 리디렉션(Redirect requests for an object)**을 선택합니다.

1. **대상 버킷(Target bucket)** 상자에 루트 도메인(예: **example.com**)을 입력합니다.

1. **프로토콜(Protocol)**에서 **http**를 선택합니다.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.

## 5단계: 웹 사이트 트래픽용 로깅 구성
<a name="root-domain-walkthrough-configure-logging"></a>

웹 사이트에 접속하는 방문자들의 수를 추적하려는 경우 필요에 따라 루트 도메인 버킷에 대한 로깅을 사용 설정할 수 있습니다. 자세한 내용은 [서버 액세스 로깅을 사용한 요청 로깅](ServerLogs.md) 섹션을 참조하세요. Amazon CloudFront를 사용하여 웹 사이트 속도를 높이려는 경우 CloudFront 로깅을 사용할 수도 있습니다.

**루트 도메인 버킷에 대한 서버 액세스 로깅 사용 설정**

1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 정적 웹 사이트로 구성된 버킷을 생성한 리전에서 로깅용 버킷을 생성합니다(예: `logs.example.com`).

1. 서버 액세스 로깅 로그 파일에 대한 폴더를 생성합니다(예: `logs`).

1. (선택 사항) CloudFront를 사용하여 웹 사이트 성능을 개선하려면 CloudFront 로그 파일에 대한 폴더(예: `cdn`)를 생성합니다.
**중요**  
배포를 생성 또는 업데이트하고 CloudFront 로깅을 사용 설정하면 CloudFront는 버킷 액세스 제어 목록(ACL)을 업데이트하여 버킷에 로그를 쓸 수 있는 `FULL_CONTROL` 권한을 `awslogsdelivery` 계정에 부여합니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [표준 로깅 구성 및 로그 파일 액세스에 필요한 권한](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html#AccessLogsBucketAndFileOwnership)을 참조하세요. 로그를 저장하는 버킷이 S3 객체 소유권에 대해 버킷 소유자 적용 설정을 사용하여 ACL을 비활성화하면 CloudFront에서 버킷에 로그를 쓸 수 없습니다. 자세한 내용은 [객체 소유권 제어 및 버킷에 대해 ACL 사용 중지](about-object-ownership.md) 섹션을 참조하세요.

1. **버킷(Buckets)** 목록에서 루트 도메인 버킷을 선택합니다.

1. [**속성(Properties)**]을 선택합니다.

1. **서버 액세스 로깅(Server access logging)**에서 **편집(Edit)**을 선택합니다.

1. **사용**을 선택합니다.

1. **대상 버킷(Target bucket)**에서 서버 액세스 로그의 버킷과 폴더 대상을 선택합니다.
   + 폴더 및 버킷 위치를 찾습니다.

     1. **S3 찾아보기(Browse S3)**를 선택합니다.

     1. 버킷 이름을 선택한 다음 로그 폴더를 선택합니다.

     1. **경로 선택(Choose path)**을 선택합니다.
   + S3 버킷 경로(예: `s3://logs.example.com/logs/`)를 입력합니다.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.

   이제 로그 버킷에서 로그에 액세스할 수 있습니다. Amazon S3은 2시간마다 웹 사이트 액세스 로그를 로그 버킷에 기록합니다.

## 6단계: 인덱스 및 웹 사이트 콘텐츠 업로드
<a name="upload-website-content"></a>

이 단계에서 인덱스 문서와 선택적 웹 사이트 콘텐츠를 루트 도메인 버킷에 업로드합니다.

버킷용 정적 웹 사이트 호스팅을 사용 설정할 때 인덱스 문서의 이름(예: **index.html**)을 입력합니다. 버킷용 정적 웹 사이트 호스팅을 사용 설정한 후 인덱스 문서 이름이 있는 HTML 파일을 버킷에 업로드합니다.

**인덱스 문서 구성**

1. `index.html` 파일을 생성합니다.

   `index.html` 파일이 없으면 다음 HTML을 사용하여 파일을 생성할 수 있습니다.

   ```
   <html xmlns="http://www.w3.org/1999/xhtml" >
   <head>
       <title>My Website Home Page</title>
   </head>
   <body>
     <h1>Welcome to my website</h1>
     <p>Now hosted on Amazon S3!</p>
   </body>
   </html>
   ```

1. 인덱스 파일을 로컬에 저장합니다.

   인덱스 문서 파일 이름은 **정적 웹 사이트 호스팅** 대화 상자에 입력한 인덱스 문서 이름과 정확히 일치해야 합니다. 인덱스 문서 이름은 대/소문자를 구분합니다. 예를 들어 **정적 웹 사이트 호스팅** 대화 상자에서 **인덱스 문서** 이름에 `index.html`을 입력하는 경우, 인덱스 문서 파일은 `index.html`이 아니라 `Index.html`이어야 합니다.

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. 버킷 목록에서 정적 웹 사이트를 호스팅하는 데 사용할 버킷의 이름을 선택합니다.

1. 버킷에 정적 웹 사이트 호스팅을 사용 설정하고 인덱스 문서의 정확한 이름(예: `index.html`)을 입력합니다. 자세한 내용은 [웹 사이트 호스팅 사용 설정](EnableWebsiteHosting.md) 섹션을 참조하세요.

   정적 웹 사이트 호스팅을 사용 설정한 후 6단계로 이동합니다.

1. 버킷에 인덱스 문서를 업로드하려면 다음 중 하나를 수행합니다.
   + 인덱스 파일을 콘솔 버킷 목록으로 끌어다 놓습니다.
   + **업로드**를 선택하고 프롬프트의 메시지에 따라 인덱스 파일을 선택하고 업로드합니다.

   단계별 지침은 [객체 업로드](upload-objects.md) 섹션을 참조하세요.

1. (선택 사항) 버킷에 다른 웹 사이트 콘텐츠를 업로드합니다.

## 7단계: 오류 문서 업로드
<a name="configure-error-document-root-domain"></a>

버킷용 정적 웹 사이트 호스팅을 사용 설정할 때 오류 문서의 이름(예: **404.html**)을 입력합니다. 버킷용 정적 웹 사이트 호스팅을 사용 설정한 후 오류 문서 이름이 있는 HTML 파일을 버킷에 업로드합니다.

**오류 문서 구성**

1. 오류 문서를 생성합니다(예: `404.html`).

1. 오류 문서 파일을 로컬에 저장합니다.

   오류 문서 이름은 대/소문자를 구분하며 정적 웹 사이트 호스팅을 사용하도록 설정할 때 입력한 이름과 정확히 일치해야 합니다. 예를 들어 **정적 웹 사이트 호스팅** 대화 상자에서 **오류 문서** 이름에 `404.html`을 입력하는 경우, 오류 문서 파일은 `404.html`이어야 합니다.

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **범용 버킷**을 선택합니다.

1. 버킷 목록에서 정적 웹 사이트를 호스팅하는 데 사용할 버킷의 이름을 선택합니다.

1. 버킷에 정적 웹 사이트 호스팅을 사용 설정하고 오류 문서의 정확한 이름(예: `404.html`)을 입력합니다. 자세한 내용은 [웹 사이트 호스팅 사용 설정](EnableWebsiteHosting.md) 및 [사용자 지정 오류 문서 구성](CustomErrorDocSupport.md)(을)를 참조하세요.

   정적 웹 사이트 호스팅을 사용 설정한 후 6단계로 이동합니다.

1. 버킷에 오류 문서를 업로드하려면 다음 중 하나를 수행합니다.
   + 오류 문서 파일을 콘솔 버킷 목록으로 끌어다 놓습니다.
   + **업로드**를 선택하고 프롬프트의 메시지에 따라 인덱스 파일을 선택하고 업로드합니다.

   단계별 지침은 [객체 업로드](upload-objects.md) 섹션을 참조하세요.

## 8단계: S3 퍼블릭 액세스 차단 설정 편집
<a name="root-domain-walkthrough-configure-bucket-permissions"></a>

이 예제에서는 퍼블릭 액세스를 허용하도록 도메인 버킷(`example.com`)에 대한 퍼블릭 액세스 차단 설정을 편집합니다.

기본적으로 Amazon S3은 계정 및 버킷에 대한 퍼블릭 액세스를 차단합니다. 버킷을 사용하여 정적 웹 사이트를 호스팅하려는 경우 이러한 단계를 사용하여 퍼블릭 액세스 차단 설정을 편집할 수 있습니다.

**주의**  
이러한 단계를 완료하기 전에 [Amazon S3 스토리지에 대한 퍼블릭 액세스 차단](access-control-block-public-access.md)을 검토하여 퍼블릭 액세스 허용과 관련된 위험을 이해하고 이에 동의하는지 확인합니다. 퍼블릭 액세스 차단 설정을 해제하여 버킷을 퍼블릭으로 만들면 인터넷상의 모든 사용자가 버킷에 액세스할 수 있습니다. 버킷에 대한 모든 퍼블릭 액세스를 차단하는 것이 좋습니다.

1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 정적 웹 사이트로 구성한 버킷의 이름을 선택합니다.

1. **Permissions**를 선택합니다.

1. **퍼블릭 액세스 차단(버킷 설정)(Block public access (bucket settings))**에서 **편집(Edit)**을 선택합니다.

1. ***모든* 퍼블릭 액세스 차단(Block all public access)**을 선택 취소하고 **변경 사항 저장(Save changes)**을 선택합니다.  
![\[퍼블릭 액세스 차단 버킷 설정을 보여주는 Amazon S3 콘솔.\]](http://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/images/edit-public-access-clear.png)

   Amazon S3은 버킷에 대한 퍼블릭 액세스 차단 설정을 끕니다. 정적 퍼블릭 웹 사이트를 생성하려면 버킷 정책을 추가하기 전에 계정에 대한 [퍼블릭 액세스 차단 설정을 편집](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/block-public-access-account.html)해야 할 수도 있습니다. 계정에 대한 퍼블릭 액세스 차단 설정이 현재 켜져 있는 경우 **퍼블릭 액세스 차단(버킷 설정)** 아래에 메모가 표시됩니다.

## 9단계: 버킷 정책 연결
<a name="add-bucket-policy-root-domain"></a>

이 예제에서는 버킷 정책을 도메인 버킷(`example.com`)에 연결하여 퍼블릭 읽기 액세스를 허용합니다. 버킷 정책의 *Bucket-Name*을 도메인 버킷의 이름으로 바꿉니다(예: `example.com`).

S3 퍼블릭 액세스 차단 설정을 편집한 후에는 버킷 정책을 추가하여 버킷에 퍼블릭 읽기 액세스 권한을 부여할 수 있습니다. 퍼블릭 읽기 액세스 권한을 부여하면 인터넷의 모든 사용자가 버킷에 액세스할 수 있습니다.

**중요**  
다음 정책은 하나의 예일 뿐이며 버킷의 콘텐츠에 대한 전체 액세스를 허용합니다. 이 단계를 진행하기 전에 [Amazon S3 버킷에 있는 파일을 보호하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/secure-s3-resources/)를 검토하여 S3 버킷의 파일 보안을 위한 모범 사례 및 퍼블릭 액세스 권한 부여와 관련된 위험을 파악할 수 있습니다.

1. **버킷**에서 버킷의 이름을 선택합니다.

1. **Permissions**를 선택합니다.

1. **버킷 정책(Bucket Policy)**에서 **편집(Edit)**을 선택합니다.

1. 웹 사이트에 대한 퍼블릭 읽기 액세스 권한을 부여하려면 다음 버킷 정책을 복사한 후 **버킷 정책 편집기**에 붙여 넣습니다.

   ```
   {
       "Version": "2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "PublicReadGetObject",
               "Effect": "Allow",
               "Principal": "*",
               "Action": [
                   "s3:GetObject"
               ],
               "Resource": [
                   "arn:aws:s3:::Bucket-Name/*"
               ]
           }
       ]
   }
   ```

1. `Resource`를 버킷 이름으로 업데이트합니다.

   앞의 버킷 정책 예제에서 *Bucket-Name*은 버킷 이름의 자리 표시자입니다. 자체 버킷에 이 버킷 정책을 사용하려면 자체 버킷 이름과 일치하도록 이 이름을 업데이트해야 합니다.

1. [**변경 사항 저장(Save changes)**]을 선택합니다.

   버킷 정책이 성공적으로 추가되었음을 나타내는 메시지가 나타납니다.

   `Policy has invalid resource`라는 오류가 표시되면 버킷 정책의 버킷 이름이 사용자의 버킷 이름과 일치하는지 확인합니다. 버킷 정책 추가에 대한 자세한 내용은 [S3 버킷 정책을 추가하려면 어떻게 해야 하나요?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html)를 참조하십시오.

   오류 메시지가 나타나고 버킷 정책을 저장할 수 없는 경우 계정 및 버킷의 퍼블릭 액세스 차단 설정에서 버킷에 대한 퍼블릭 액세스를 허용하는지 확인합니다.

다음 단계에서는 웹 사이트 엔드포인트를 파악하고 도메인 엔드포인트를 테스트할 수 있습니다.

## 10단계: 도메인 엔드포인트 테스트
<a name="root-domain-walkthrough-test-website"></a>

퍼블릭 웹 사이트를 호스팅하도록 도메인 버킷을 구성한 후 엔드포인트를 테스트할 수 있습니다. 자세한 내용은 [웹 사이트 엔드포인트](WebsiteEndpoints.md) 섹션을 참조하세요. 하위 도메인 버킷은 정적 웹 사이트 호스팅이 아닌 웹 사이트 리디렉션에 대해 설정되어 있으므로 도메인 버킷의 엔드포인트만 테스트할 수 있습니다.

**참고**  
Amazon S3에서는 웹 사이트에 대한 HTTPS 액세스를 지원하지 않습니다. HTTPS를 사용하려는 경우 Amazon CloudFront를 사용하여 Amazon S3에서 호스팅되는 정적 웹 사이트를 제공할 수 있습니다.  
자세한 내용은 [CloudFront를 사용하여 Amazon S3에 호스팅된 정적 웹 사이트를 제공하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-serve-static-website/) 및 [최종 사용자와 CloudFront 간의 통신에 HTTPS 요구](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html)를 참조하십시오.

1. **버킷**에서 버킷의 이름을 선택합니다.

1. [**속성(Properties)**]을 선택합니다.

1. 페이지 하단의 **정적 웹 사이트 호스팅(Static website hosting)**에서 **버킷 웹 사이트 엔드포인트(Bucket website endpoint)**를 선택합니다.

   인덱스 문서가 별도의 브라우저 창에서 열립니다.

다음 단계에서는 Amazon Route 53을 이용해 고객이 사용자 지정 URL을 모두 사용하여 해당 사이트를 탐색할 수 있도록 합니다.

## 11단계: 도메인 및 하위 도메인에 대한 별칭 레코드 추가
<a name="root-domain-walkthrough-add-record-to-hostedzone"></a>

이 단계에서 도메인 맵 `example.com` 및 `www.example.com`에 따른 호스팅 영역에 추가하는 별칭 레코드를 생성합니다. 별칭 레코드는 IP 주소 대신 Amazon S3 웹 사이트 엔드포인트를 사용합니다. Amazon Route 53은 별칭 레코드와 Amazon S3 버킷이 존재하는 IP 주소 간 매핑을 유지합니다. 별칭 레코드를 두 개(루트 도메인용 및 하위 도메인용) 만듭니다.

### 루트 도메인 및 하위 도메인에 대한 별칭 레코드 추가
<a name="add-alis-record"></a>

**루트 도메인(`example.com`)에 대한 별칭 레코드 추가**

1. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다.
**참고**  
Route 53을 아직 사용하지 않은 경우 *Amazon Route 53 개발자 안내서*의 [1단계: 도메인 등록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/getting-started.html#getting-started-find-domain-name)을 참조하십시오. 설정을 완료했으면 지시 사항을 다시 시작할 수 있습니다.

1. **Hosted Zones(호스팅 영역)**를 선택합니다.

1. 호스팅 영역의 목록에서 사용자의 도메인 이름과 일치하는 호스팅 영역의 이름을 선택합니다.

1. **Create Record Set(레코드 세트 생성)**를 선택합니다.

1. **마법사로 전환**을 선택합니다.
**참고**  
빠른 생성을 사용하여 별칭 레코드를 생성하려면 [트래픽을 S3 버킷으로 라우팅하도록 Route 53 구성](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/RoutingToS3Bucket.html#routing-to-s3-bucket-configuring)을 참조하십시오.

1. **Simple routing(단순 라우팅)**을 선택하고 **다음**을 선택합니다.

1. **Define simple record(단순 레코드 정의)**를 선택합니다.

1. [**레코드 이름(Record name)**]에서 기본값(호스팅 영역과 도메인의 이름)을 그대로 사용합니다.

1. **값/트래픽 라우팅 대상**에서 **Alias to S3 website endpoint(S3 웹 사이트 엔드포인트에 대한 별칭)**를 선택합니다.

1. 리전을 선택합니다.

1. S3 버킷을 선택합니다.

   버킷 이름은 **이름** 상자에 나타나는 이름과 일치해야 합니다. **S3 버킷 선택** 목록에서 버킷 이름은 버킷이 생성된 리전의 Amazon S3 웹 사이트 엔드포인트와 함께 나타납니다(예: `s3-website-us-west-1.amazonaws.com (example.com)`).

   다음과 같은 경우 **S3 버킷 선택**이 버킷을 나열합니다.
   + 버킷을 정적 웹 사이트로 구성한 경우
   + 버킷 이름이 생성 중인 레코드의 이름과 동일한 경우
   + 현재 AWS 계정에서 버킷을 생성한 경우.

   버킷이 **S3 버킷 선택** 목록에 나타나지 않으면 버킷이 생성된 리전의 Amazon S3 웹 사이트 엔드포인트를 입력합니다(예: **s3-website-us-west-2.amazonaws.com**). Amazon S3 웹 사이트 엔드포인트의 전체 목록은 [Amazon S3 웹 사이트 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints)를 참조하세요. 별칭 대상에 대한 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [값/트래픽 라우팅 대상](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-alias.html#rrsets-values-alias-alias-target)을 참조하세요.

1. **레코드 유형**에서 **A ‐ IPv4 주소 및 일부 AWS 리소스로 트래픽 라우팅**을 선택합니다.

1. **대상 상태 평가**에서 **아니요**를 선택합니다.

1. **Define simple record(단순 레코드 정의)**를 선택합니다.

**하위 도메인(`www.example.com`)에 별칭 레코드 추가**

1. **레코드 구성**에서 **단순 레코드 정의**를 선택합니다.

1. 하위 도메인의 **레코드 이름**에 `www`를 입력합니다.

1. **값/트래픽 라우팅 대상**에서 **Alias to S3 website endpoint(S3 웹 사이트 엔드포인트에 대한 별칭)**를 선택합니다.

1. 리전을 선택합니다.

1. S3 버킷을 선택합니다(예: `s3-website-us-west-2.amazonaws.com (www.example.com)`).

   버킷이 **S3 버킷 선택** 목록에 나타나지 않으면 버킷이 생성된 리전의 Amazon S3 웹 사이트 엔드포인트를 입력합니다(예: **s3-website-us-west-2.amazonaws.com**). Amazon S3 웹 사이트 엔드포인트의 전체 목록은 [Amazon S3 웹 사이트 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints)를 참조하세요. 별칭 대상에 대한 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [값/트래픽 라우팅 대상](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-alias.html#rrsets-values-alias-alias-target)을 참조하세요.

1. **레코드 유형**에서 **A ‐ IPv4 주소 및 일부 AWS 리소스로 트래픽 라우팅**을 선택합니다.

1. **대상 상태 평가**에서 **아니요**를 선택합니다.

1. **Define simple record(단순 레코드 정의)**를 선택합니다.

1. **레코드 구성** 페이지에서 **레코드 생성**을 선택합니다.

**참고**  
변경 사항은 일반적으로 60초 이내에 모든 Route 53 서버로 전파됩니다. 전파가 완료되면 이 절차에서 생성한 별칭 레코드의 이름을 사용하여 트래픽을 Amazon S3 버킷으로 라우팅할 수 있습니다.

### 루트 도메인 및 하위 도메인에 대한 별칭 레코드 추가(이전 Route 53 콘솔)
<a name="add-alis-record-old"></a>

**루트 도메인(`example.com`)에 대한 별칭 레코드 추가**

Route 53 콘솔이 새롭게 디자인되었습니다. Route 53 콘솔에서 일시적으로 이전 콘솔을 사용할 수 있습니다. 이전 Route 53 콘솔로 작업하도록 선택한 경우 아래 절차를 따릅니다.

1. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다.
**참고**  
Route 53을 아직 사용하지 않은 경우 *Amazon Route 53 개발자 안내서*의 [1단계: 도메인 등록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/getting-started.html#getting-started-find-domain-name)을 참조하십시오. 설정을 완료했으면 지시 사항을 다시 시작할 수 있습니다.

1. **Hosted Zones(호스팅 영역)**를 선택합니다.

1. 호스팅 영역의 목록에서 사용자의 도메인 이름과 일치하는 호스팅 영역의 이름을 선택합니다.

1. [**Create Record Set**]를 선택합니다.

1. 다음 값을 지정합니다.  
**이름**  
기본값(호스팅 영역과 도메인의 이름)을 그대로 사용합니다.  
루트 도메인의 경우 **이름** 필드에 추가 정보를 입력할 필요는 없습니다.  
**유형**  
**A - IPv4 주소(A – IPv4 address)**를 선택합니다.  
**별칭**  
**예**를 선택합니다.  
**별칭 대상**  
목록의 **S3 website endpoints(S3 웹 사이트 엔드포인트)** 섹션에서 버킷 이름을 선택합니다.  
버킷 이름은 **이름** 상자에 나타나는 이름과 일치해야 합니다. **별칭 대상(Alias Target)** 목록에서 버킷 이름 뒤에는 버킷이 생성된 리전의 Amazon S3 웹 사이트 엔드포인트가 옵니다(예: `example.com (s3-website-us-west-2.amazonaws.com)`). 다음과 같은 경우 **Alias Target(별칭 대상)**에 하나의 버킷이 나타납니다.  
   + 버킷을 정적 웹 사이트로 구성한 경우
   + 버킷 이름이 생성 중인 레코드의 이름과 동일한 경우
   + 현재 AWS 계정에서 버킷을 생성한 경우.
버킷이 [**별칭 대상(Alias Target)**] 목록에 나타나지 않으면 버킷이 생성된 리전의 Amazon S3 웹 사이트 엔드포인트를 입력합니다(예: `s3-website-us-west-2`). Amazon S3 웹 사이트 엔드포인트의 전체 목록은 [Amazon S3 웹 사이트 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints)를 참조하십시오. 별칭 대상에 대한 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [값/트래픽 라우팅 대상](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-alias.html#rrsets-values-alias-alias-target)을 참조하십시오.  
**라우팅 정책**  
기본값인 [**Simple**]을 수락합니다.  
**대상 상태 평가**  
기본값인 [**No**]를 수락합니다.

1. **Create**를 선택합니다.

**하위 도메인(`www.example.com`)에 별칭 레코드 추가**

1. 루트 도메인(`example.com`)에 대한 호스팅 영역에서 **레코드 세트 생성**을 선택합니다.

1. 다음 값을 지정합니다.  
**이름**  
하위 도메인에 대해 `www`를 상자에 입력합니다.  
**유형**  
**A - IPv4 주소(A – IPv4 address)**를 선택합니다.  
**별칭**  
**예**를 선택합니다.  
**별칭 대상**  
목록의 **S3 웹 사이트 엔드포인트(S3 website endpoints)** 섹션에서 **이름(Name)** 필드에 표시되는 동일한 버킷 이름을 선택합니다(예: `www.example.com (s3-website-us-west-2.amazonaws.com)`).  
**라우팅 정책**  
기본값인 [**Simple**]을 수락합니다.  
**대상 상태 평가**  
기본값인 [**No**]를 수락합니다.

1. **Create**를 선택합니다.

**참고**  
변경 사항은 일반적으로 60초 이내에 모든 Route 53 서버로 전파됩니다. 전파가 완료되면 이 절차에서 생성한 별칭 레코드의 이름을 사용하여 트래픽을 Amazon S3 버킷으로 라우팅할 수 있습니다.

## 12단계: 웹 사이트 테스트
<a name="root-domain-testing"></a>

웹 사이트 및 리디렉션 작업이 올바르게 작동하는지 확인합니다. 브라우저에 해당 URL을 입력합니다. 이 예제에서는 다음 URL을 이용할 수 있습니다.
+ **도메인**(`http://example.com`) - `example.com` 버킷의 인덱스 문서를 표시합니다.
+ **하위 도메인**(`http://www.example.com`) - 요청을 `http://example.com`으로 리디렉션합니다. `example.com` 버킷의 인덱스 문서가 표시됩니다.

웹 사이트 또는 리디렉션 링크가 작동하지 않으면 다음 방법을 시도할 수 있습니다.
+ **캐시 지우기** - 웹 브라우저의 캐시를 지웁니다.
+ **이름 서버 확인** - 캐시를 지운 후에도 웹 페이지 및 리디렉션 링크가 작동하지 않으면 도메인의 이름 서버와 호스팅 영역의 이름 서버를 비교합니다. 이름 서버가 일치하지 않는 경우 호스팅 영역 아래에 나열된 이름과 일치하도록 도메인 이름 서버를 업데이트해야 할 수 있습니다. 자세한 내용은 [도메인의 글루 레코드 및 이름 서버 추가 또는 변경](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-name-servers-glue-records.html)을 참조하세요.

루트 도메인과 하위 도메인을 성공적으로 테스트한 후에는 [Amazon CloudFront](https://aws.amazon.com/cloudfront) 배포를 설정하여 웹 사이트의 성능을 개선하고 웹 사이트 트래픽을 검토하는 데 사용할 수 있는 로그를 제공할 수 있습니다. 자세한 내용은 [Amazon CloudFront로 웹사이트 속도 향상](website-hosting-cloudfront-walkthrough.md) 섹션을 참조하세요.

# Amazon CloudFront로 웹사이트 속도 향상
<a name="website-hosting-cloudfront-walkthrough"></a>

[Amazon CloudFront](https://aws.amazon.com/cloudfront)를 사용하여 Amazon S3 웹 사이트의 성능을 향상시킬 수 있습니다. CloudFront를 통해 웹 사이트 파일(HTML, 이미지, 동영상 등)을 *엣지 로케이션*이라고 하는 전 세계 각지의 데이터 센터에서 사용할 수 있습니다. 방문자가 웹 사이트에서 파일을 요청할 때 CloudFront는 가장 가까운 엣지 로케이션에 있는 파일 사본으로 요청을 자동 리디렉션합니다. 이렇게 하면 방문자가 더 멀리 있는 데이터 센터에서 콘텐츠를 요청한 경우보다 다운로드 시간이 빨라집니다.

CloudFront는 지정된 기간 동안 엣지 로케이션에 있는 콘텐츠를 캐시합니다. 방문자가 만료일보다 더 오래 캐시된 콘텐츠를 요청하는 경우에 CloudFront는 그 콘텐츠의 최신 버전이 사용 가능한지 알아보기 위해 오리진 서버를 확인합니다. 최신 버전이 사용 가능하다면, CloudFront는 새로운 버전을 엣지 로케이션에 복사합니다. 원본 콘텐츠에 대한 변경 사항은 방문객이 그 콘텐츠를 요청할 때 엣지 로케이션에 복제됩니다.

**Route 53 없이 CloudFront 사용**  
이 페이지의 자습서에서는 Route 53을 사용하여 CloudFront 배포를 가리킵니다. 그러나 Route 53을 사용하지 않고 CloudFront를 사용하여 Amazon S3 버킷에 호스팅된 콘텐츠를 제공하려면 [Amazon CloudFront 자습서, Amazon S3용 동적 콘텐츠 배포 설정](https://aws.amazon.com/cloudfront/getting-started/S3/)을 참조하십시오. CloudFront를 사용하여 Amazon S3 버킷에 호스팅된 콘텐츠를 서비스할 때는 어떤 버킷 이름이라도 사용할 수 있으며 HTTP와 HTTPS가 모두 지원됩니다.

**CloudFormation 템플릿으로 설정 자동화**  
CloudFormation 템플릿을 사용하여 웹 사이트에 제공할 CloudFront 배포를 생성하는 안전한 정적 웹 사이트를 구성하는 방법에 대한 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [안전한 정적 웹 사이트 시작하기](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/getting-started-secure-static-website-cloudformation-template.html)를 참조하십시오.

**Topics**
+ [1단계: CloudFront 배포 생성](#create-distribution)
+ [2단계: 도메인 및 하위 도메인용 레코드 세트 업데이트](#update-record-sets)
+ [(선택 사항) 3단계: 로그 파일 확인](#check-log-files)

## 1단계: CloudFront 배포 생성
<a name="create-distribution"></a>

먼저 CloudFront 배포를 생성합니다. 이를 통해 전 세계 각지의 데이터 센터에서 웹 사이트를 사용할 수 있게 됩니다.

**Amazon S3 오리진으로 배포 생성**

1. 에서 CloudFront 콘솔을 엽니다[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)

1. [**Create Distribution**]을 선택합니다.

1. [**배포 생성(Create Distribution)**] 페이지의 [**오리진 설정(Origin Settings)**] 섹션에서 [**오리진 도메인 이름(Origin Domain Name)**]에 해당 버킷에 대한Amazon S3 웹 사이트 엔드포인트를 입력합니다(예: **example.com.s3-website.us-west-1.amazonaws.com**).

   CloudFront가 사용자 대신 **오리진 ID(Origin ID)**를 채웁니다.

1. **Default Cache Behavior Settings(기본 캐시 동작 설정)**에서는 기본값으로 설정되어 있는 값을 유지합니다.

   [**뷰어 프로토콜 정책(Viewer Protocol Policy)**]의 기본 설정을 사용하면 정적 웹 사이트에 HTTPS를 사용할 수 있습니다. 이 구성 옵션에 대한 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [웹 배포의 생성 또는 업데이트 시 지정하는 값](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/WorkingWithDownloadDistributions.html#DownloadDistValuesYouSpecify)을 참조하십시오.

1. **Distribution Settings(배포 설정)**에서 다음 작업을 수행합니다.

   1. **Use All Edge Locations (Best Performance)(전체 엣지 로케이션 사용(최상의 성능))**로 설정된 **Price Class(가격 등급)**를 그대로 둡니다.

   1. [**대체 도메인 이름(CNAME)(Alternate Domain Names (CNAMEs))**]을 루트 도메인과 `www` 하위 도메인으로 설정합니다. 이 자습서에서는 `example.com` 및 `www.example.com`입니다.
**중요**  
이 단계를 수행하기 전에 [대체 도메인 이름 사용과 관련된 요구 사항](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-requirements), 특히 유효한 SSL/TLS 인증서가 필요한지 확인하십시오.

   1. **SSL 인증서(SSL Certificate)**에서 **사용자 정의 SSL 인증서(Custom SSL Certificate)(example.com)**를 선택하고, 도메인 및 하위 도메인 이름을 포함하는 사용자 지정 인증서를 선택합니다.

      자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [SSL 인증서](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesSSLCertificate)를 참조하십시오.

   1. **기본 루트 객체**에 인덱스 문서의 이름을 입력합니다(예: `index.html`).

      배포에 액세스하는 데 사용된 URL에 파일 이름이 없으면 CloudFront 배포가 인덱스 문서를 반환합니다. **기본 루트 객체**는 정적 웹 사이트에 대한 인덱스 문서의 이름과 정확히 일치해야 합니다. 자세한 내용은 [인덱스 문서 구성](IndexDocumentSupport.md) 섹션을 참조하세요.

   1. **로깅**을 **설정**으로 설정합니다.
**중요**  
배포를 생성 또는 업데이트하고 CloudFront 로깅을 사용 설정하면 CloudFront는 버킷 액세스 제어 목록(ACL)을 업데이트하여 버킷에 로그를 쓸 수 있는 `FULL_CONTROL` 권한을 `awslogsdelivery` 계정에 부여합니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [표준 로깅 구성 및 로그 파일 액세스에 필요한 권한](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html#AccessLogsBucketAndFileOwnership)을 참조하세요. 로그를 저장하는 버킷이 S3 객체 소유권에 대해 버킷 소유자 적용 설정을 사용하여 ACL을 비활성화하면 CloudFront에서 버킷에 로그를 쓸 수 없습니다. 자세한 내용은 [객체 소유권 제어 및 버킷에 대해 ACL 사용 중지](about-object-ownership.md) 섹션을 참조하세요.

   1. **Bucket for Logs(로그용 버킷)**에서 앞서 생성한 로깅 버킷을 선택합니다.

      로깅 버킷 구성에 대한 자세한 내용은 [(선택 사항) 웹 트래픽 로깅](LoggingWebsiteTraffic.md) 단원을 참조하십시오.

   1. CloudFront 배포에 대한 트래픽에 의해 생성된 로그를 폴더에 저장하려면 **로그 접두사(Log Prefix)**에 폴더 이름을 입력합니다.

   1. 기타 모든 설정은 기본값을 유지합니다.

1. [**Create Distribution**]을 선택합니다.

1. 현재의 배포 상태를 보려면, 콘솔에서 배포를 찾아 **상태** 열을 확인합니다.

   `InProgress` 상태는 배포가 아직 완전히 이루어지지 않았음을 뜻합니다.

   배포가 완료되면 새 CloudFront 도메인 이름으로 콘텐츠를 참조할 수 있습니다.

1. CloudFront 콘솔에 표시되는 **도메인 이름**의 값을 기록합니다(예: `dj4p1rv6mvubz.cloudfront.net`).

1. CloudFront 배포가 이루어지고 있는지 확인하려면, 웹 브라우저에서 배포의 도메인 이름을 입력합니다.

   웹 사이트가 표시되는 경우 CloudFront 배포가 작동하는 것입니다. 웹 사이트의 Amazon Route 53에 사용자 지정 도메인이 등록되어 있는 경우 다음 단계에서 레코드 세트를 업데이트하려면 CloudFront 도메인 이름이 필요합니다.

## 2단계: 도메인 및 하위 도메인용 레코드 세트 업데이트
<a name="update-record-sets"></a>

CloudFront 배포를 성공적으로 생성했으므로 새 CloudFront 배포를 가리키도록 Route 53의 별칭 레코드를 업데이트합니다.

**CloudFront 배포를 가리키도록 별칭 레코드 업데이트**

1. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **Hosted Zones(호스팅 영역)**를 선택합니다.

1. **Hosted Zones(호스팅 영역)** 페이지에서 하위 도메인을 위해 생성한 호스팅 영역(예: `www.example.com`)을 선택합니다.

1. **레코드**에서 하위 도메인에 대해 만든 *A* 레코드를 선택합니다.

1. **레코드 세부 정보**에서 **레코드 편집**을 선택합니다.

1. **다음으로 트래픽 라우팅**에서 **CloudFront 배포로 별칭**을 선택합니다.

1. **배포 선택**에서 CloudFront 배포를 선택합니다.

1. **저장**을 선택합니다.

1. 루트 도메인에 대한 *A* 레코드를 CloudFront 배포로 리디렉션하려면 루트 도메인에 대해 이 절차(예: `example.com`)를 반복합니다.

   레코드 세트를 업데이트한 내용은 2\$148시간 내에 적용됩니다.

1. 새 *A* 레코드가 적용되었는지 확인하려면 웹 브라우저에서 하위 도메인 URL을 입력합니다(예: `http://www.example.com`).

   브라우저가 루트 도메인(예: `http://example.com`)으로 리디렉션되지 않는 경우 새 A 레코드가 적용된 것입니다. 새로운 *A* 레코드가 적용되면 새로운 *A* 레코드에 의해 CloudFront 배포로 라우팅되는 트래픽은 루트 도메인으로 리디렉션되지 않습니다. `http://example.com` 또는 `http://www.example.com`을 이용해 사이트를 참조하는 방문자가 가장 가까운 CloudFront 엣지 로케이션으로 리디렉션됨으로써, 더 빨라진 다운로드 시간의 이점을 누릴 수 있습니다.
**작은 정보**  
브라우저는 리디렉션 설정을 캐시할 수 있습니다. 새로운 *A* 레코드 설정이 이미 적용되었어야 하는데 여전히 브라우저에서 `http://www.example.com`이 `http://example.com`으로 리디렉션된다면, 브라우저 애플리케이션을 닫았다가 다시 열어 브라우저의 검색 기록 및 캐시를 삭제하거나 다른 웹 브라우저를 사용하세요.

## (선택 사항) 3단계: 로그 파일 확인
<a name="check-log-files"></a>

액세스 로그는 웹 사이트를 방문하는 사람의 수를 알려 줍니다. 또한 [Amazon EMR](https://docs.aws.amazon.com/emr/latest/DeveloperGuide/)과 같은 다른 서비스로 분석할 수 있는 중요 비즈니스 데이터를 포함하고 있습니다.

CloudFront 로그는 CloudFront 배포를 생성하고 로깅을 사용 설정할 때 선택한 버킷과 폴더에 저장됩니다. CloudFront는 해당 요청 이후 24시간 이내에 로그 버킷에 로그를 기록합니다.

**웹 사이트의 로그 파일 보기**

1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. 웹 사이트에 대한 로깅 버킷을 선택합니다.

1. CloudFront 로그 폴더를 선택합니다.

1. 열기 전에 CloudFront에서 작성한 `.gzip` 파일을 다운로드합니다.

   실습용으로만 웹 사이트를 생성한 경우에는 요금이 발생하지 않도록 할당한 리소스를 삭제할 수 있습니다. 그렇게 하려면 [예제 리소스 정리](getting-started-cleanup.md) 단원을 참조하십시오. AWS 리소스를 삭제한 후에는 웹 사이트를 사용할 수 없습니다.

# 예제 리소스 정리
<a name="getting-started-cleanup"></a>

실습용으로 정적 웹 사이트를 생성한 경우에는 요금이 발생하지 않도록 할당한 AWS 리소스를 삭제해야 합니다. AWS 리소스를 삭제한 후에는 웹 사이트를 사용할 수 없습니다.

**Topics**
+ [1단계: Amazon CloudFront 배포 삭제](#getting-started-cleanup-cloudfront)
+ [2단계: Route 53 호스팅 영역 삭제](#getting-started-cleanup-route53)
+ [3단계: 로깅 사용 중지 및 S3 버킷 삭제](#getting-started-cleanup-s3)

## 1단계: Amazon CloudFront 배포 삭제
<a name="getting-started-cleanup-cloudfront"></a>

Amazon CloudFront 배포를 삭제하려면 먼저 사용 중지해야 합니다. 사용 중지된 배포가 작동하지 않아 요금이 발생하지 않습니다. 언제든지 사용 중지된 배포를 사용 설정할 수 있습니다. 사용 중지된 배포는 삭제 후 사용할 수 없습니다.

**CloudFront 배포를 사용하지 않도록 설정하고 삭제**

1. 에서 CloudFront 콘솔을 엽니다[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)

1. 사용 중지하려는 배포를 선택한 후 **사용 중지**를 선택합니다.

1. 확인 메시지가 표시되면 **예, 사용 중지**를 선택합니다.

1. 사용 중지된 배포를 선택한 후 **삭제**를 선택합니다.

1. 확인 메시지가 나타나면 **예, 삭제합니다**를 선택합니다.

## 2단계: Route 53 호스팅 영역 삭제
<a name="getting-started-cleanup-route53"></a>

호스팅 영역을 삭제하기 전에 반드시 앞서 만든 레코드 세트를 삭제해야 합니다. NS 및 SOA 레코드는 삭제할 필요가 없습니다. 이 둘은 호스팅 영역을 삭제할 때 자동으로 삭제됩니다.

**레코드 세트 삭제**

1. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)에서 Route 53 콘솔을 엽니다.

1.  도메인 이름 목록에서 도메인 이름을 선택한 후 **Go to Record Sets(레코드 세트로 이동)**를 선택합니다.

1. 레코드 세트 목록에서 생성한 *A* 레코드를 선택합니다.

   각 레코드 세트의 유형은 **유형** 열에 나열됩니다.

1. **Delete Record Set(레코드 세트 삭제)**를 선택합니다.

1. 확인 메시지가 표시되면 **확인**을 선택합니다.

**Route 53 호스팅 영역 삭제**

1.  이전 절차에 이어서 **Back to Hosted Zones(호스팅 영역으로 돌아가기)**를 선택합니다.

1.  도메인 이름을 선택한 후 **Delete Hosted Zone(호스팅 영역 삭제)**을 선택합니다.

1.  확인 메시지가 표시되면 **확인**을 선택합니다.

## 3단계: 로깅 사용 중지 및 S3 버킷 삭제
<a name="getting-started-cleanup-s3"></a>

S3 버킷을 삭제하기 전에 버킷에 대한 로깅이 사용 중지되어 있는지 확인하십시오. 그렇지 않으면 삭제해도 AWS가 해당 버킷에 계속 로그를 기록합니다.

**버킷에 대한 로깅 사용 중지**

1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.

1. **버킷**에서 버킷 이름을 선택한 다음 **속성**을 선택합니다.

1. **속성**에서 **로깅**을 선택합니다.

1. **사용(Enabled)** 확인란의 선택을 취소합니다.

1. **저장**을 선택합니다.

이제 버킷을 삭제할 수 있습니다. 자세한 내용은 [범용 버킷 삭제](delete-bucket.md) 섹션을 참조하세요.

# S3 범용 버킷에서 AWS Amplify Hosting에 정적 웹 사이트 배포
<a name="website-hosting-amplify"></a>

[AWS Amplify Hosting](https://docs.aws.amazon.com//amplify/latest/userguide/welcome.html.html)을 사용하여 S3에 저장된 정적 웹 사이트 콘텐츠를 호스팅하는 것이 좋습니다. Amplify Hosting은 Amazon CloudFront로 구동되는 전 세계적으로 사용 가능한 콘텐츠 전송 네트워크(CDN)에 웹 사이트를 쉽게 배포할 수 있도록 하는 완전 관리형 서비스이므로 광범위한 설정을 하지 않아도 안전한 정적 웹 사이트 호스팅이 가능합니다. AWS Amplify Hosting을 사용하면 범용 버킷 내에서 객체의 위치를 선택하고, 관리형 CDN에 콘텐츠를 배포하고, 어디서나 웹 사이트에 액세스할 수 있는 퍼블릭 HTTPS URL을 생성할 수 있습니다. Amplify Hosting을 사용하여 정적 웹 사이트를 배포하면 다음과 같은 이점 및 기능을 확보할 수 있습니다.
+ **Amazon CloudFront로 구동되는 AWS 콘텐츠 전송 네트워크(CDN)에 배포** - CloudFront는 정적 및 동적 웹 콘텐츠를 사용자에게 배포하는 속도를 높이는 웹 서비스입니다. CloudFront는 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공합니다. CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 요청이 라우팅되므로 가능한 최고의 성능, 향상된 신뢰성 및 가용성으로 콘텐츠가 제공됩니다. 자세한 내용은 *Amazon CloudFront 개발자 안내서*의 [CloudFront에서 콘텐츠를 제공하는 방법](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html)을 참조하세요.
+ **HTTPS 지원** - 웹 사이트와 사용자의 웹 브라우저 간에 안전한 통신 및 데이터 전송을 제공합니다.
+ **사용자 지정 도메인** - Amazon Route 53과 같은 도메인 등록 기관에서 구매한 사용자 지정 URL에 웹 사이트를 쉽게 연결합니다.
+ **사용자 지정 SSL 인증서** - 사용자 지정 도메인을 설정할 때 Amplify가 제공하는 기본 관리형 인증서를 사용하거나 직접 선택한 타사 인증 기관에서 구매한 자체 사용자 지정 인증서를 사용할 수 있습니다.
+ **기본 제공 지표 및 CloudWatch 모니터링** - 웹 사이트의 트래픽, 오류, 데이터 전송 및 지연 시간을 모니터링합니다.
+ **암호 보호** - Amplify 콘솔에서 사용자 이름과 암호 요구 사항을 설정하여 웹 사이트에 대한 액세스를 제한합니다.
+ **리디렉션 및 재작성** - Amplify 콘솔에서 리디렉션 및 재작성 규칙을 생성하여 웹 서버가 한 URL에서 다른 URL로 탐색 경로를 변경할 수 있도록 합니다.

Amazon S3 범용 버킷에서 Amplify Hosting으로 애플리케이션을 배포하면 AWS 요금은 Amplify의 요금 모델을 기반으로 합니다. 자세한 내용은 [AWS Amplify 요금](https://aws.amazon.com/amplify/pricing/)을 참조하세요.

**중요**  
Amazon S3를 사용할 수 있는 모든 AWS 리전에서 Amplify Hosting을 사용할 수 있는 것은 아닙니다. 정적 웹 사이트를 Amplify Hosting에 배포하려면 웹 사이트가 저장된 Amazon S3 범용 버킷이 Amplify를 사용할 수 있는 리전에 있어야 합니다. Amplify를 사용할 수 있는 리전 목록은 *Amazon Web Services 일반 참조*의 [Amplify 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/amplify.html#amplify_region)를 참조하세요.

Amazon S3 콘솔, Amplify 콘솔, AWS CLI 또는 AWS SDK에서 배포 프로세스를 시작할 수 있습니다. 자신의 계정에 위치한 범용 버킷에서만 Amplify에 배포할 수 있습니다. Amplify는 교차 계정 버킷 액세스를 지원하지 않습니다.

다음 지침에 따라 Amazon S3 콘솔을 시작으로 Amazon S3 범용 버킷의 정적 웹 사이트를 Amplify Hosting에 배포합니다.

## S3 콘솔에서 Amplify에 정적 웹 사이트 배포
<a name="DeployAmplify"></a>

**Amazon S3 콘솔에서 정적 웹 사이트 배포**

1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.

1. 왼쪽 탐색 창에서 **버킷(Buckets)**을 선택합니다.

1. **버킷** 목록에서 Amplify Hosting에 배포하려는 웹 사이트가 포함된 범용 버킷을 선택합니다.

1. **속성** 탭을 선택합니다.

1. **정적 웹 사이트 호스팅**에서 **Amplify 앱 생성**을 선택합니다. 이 단계에서 배포 프로세스는 Amplify 콘솔로 이동합니다.

1. **S3로 배포** 페이지에서 다음 단계를 수행합니다.

   1. **API 이름**에 앱 또는 웹 사이트의 이름을 입력합니다.

   1. **브랜치 이름**에 앱의 백엔드 이름을 입력합니다.

   1. **호스팅할 객체의 S3 위치**에 범용 버킷의 디렉터리 경로를 입력하거나 **S3 찾아보기**를 선택한 다음, 해당 항목을 찾아서 선택합니다.

1. **저장 및 배포**를 선택합니다.

**참고**  
 Amplify에서 호스팅되는 범용 버킷에서 정적 웹 사이트의 객체를 업데이트하는 경우 변경 사항이 적용되도록 애플리케이션을 Amplify Hosting에 재배포해야 합니다. Amplify Hosting은 버킷의 변경 사항을 자동으로 감지하지 않습니다. 자세한 내용은 *AWS Amplify Hosting 사용 설명서*의 [S3 버킷에서 Amplify로 배포된 정적 웹 사이트 업데이트](https://docs.aws.amazon.com//amplify/latest/userguide/update-website-deployed-from-s3.html)를 참조하세요.

Amplify 콘솔에서 직접 시작하려면 *AWS Amplify Hosting 사용 설명서*의 [Amplify 콘솔을 사용하여 S3에서 정적 웹 사이트 배포](https://docs.aws.amazon.com//amplify/latest/userguide/deploy--from-amplify-console.html)를 참조하세요.

AWS SDK를 사용하려면 *AWS Amplify Hosting 사용 설명서*의 [AWS SDK를 사용하여 S3에서 정적 웹 사이트를 배포하기 위한 버킷 정책 생성](https://docs.aws.amazon.com//amplify/latest/userguide/deploy-with-sdks.html)을 참조하세요.