기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 부록 A: CloudFront 구성
<a name="appendix-a-cloudfront-configuration"></a>

 웹 CloudFront WordPress 사이트에서 Amazon을 사용할 때 최적의 성능과 효율성을 얻으려면 제공되는 다양한 유형의 콘텐츠에 맞게 웹 사이트를 올바르게 구성하는 것이 중요합니다.

**Topics**
+ [오리진 및 동작](origins-and-behaviors.md)
+ [CloudFront 배포 생성](cloudfront-distribution-creation.md)

# 오리진 및 동작
<a name="origins-and-behaviors"></a>

 [오](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistS3AndCustomOrigins.html)리진은 가 엣지 로케이션을 통해 배포하는 콘텐츠에 대한 요청을 CloudFront 보내는 로케이션입니다. 구현에 따라 오리진이 하나 또는 두 개 있을 수 있습니다. 사용자 지정 오리진을 사용하는 동적 콘텐츠([단일 서버 배포 옵션](simple-deployment.md) 의 Lightsail 인스턴스 또는 [탄력적 배포 옵션 ](elastic-deployment.md)의 Application Load Balancer)용 1개. 정적 콘텐츠에 대해 로 직접 CloudFront 보낼 두 번째 오리진이 있을 수 있습니다. 이전 [참조 아키텍처 ](reference-architecture.md)에서 이 는 S3 버킷입니다. Amazon S3를 배포의 오리진으로 사용하는 경우 [버킷 정책을](https://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteAccessPermissionsReqd.html) 사용하여 콘텐츠에 공개적으로 액세스할 수 있도록 해야 합니다.

 [동작을](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehavior.html) 사용하면 가 콘텐츠를 CloudFront 캐시하는 방법을 제어하는 규칙을 설정하고 캐시의 효과를 확인할 수 있습니다. 동작을 사용하면 웹 사이트에 액세스할 수 있는 프로토콜과 HTTP 방법을 제어할 수 있습니다. 또한 HTTP 헤더, 쿠키 또는 쿼리 문자열을 백엔드에 전달할지 여부(그리고 전달할 경우 어느 문자열인지)를 제어할 수 있습니다. 동작은 특정 URL 경로 패턴에 적용됩니다.

# CloudFront 배포 생성
<a name="cloudfront-distribution-creation"></a>

 배포에 따라 CloudFront 웹 배포를 생성하면 자동으로 생성된 기본 오리진 및 동작이 동적 콘텐츠에 사용됩니다. 정적 요청과 동적 요청을 모두 처리하는 방식을 추가로 사용자 지정하려면 네 가지 추가 동작을 생성합니다. 다음 표에는 다섯 가지 동작의 구성 속성이 요약되어 있습니다.

* 표 1: CloudFront 동작에 대한 구성 속성 요약 *


|  속성  |  정적  |  동적(관리자)  |  동적(프런트 엔드)  | 
| --- | --- | --- | --- | 
|  경로(행동)  |   `wp-content/* ` ` wp-includes/* `  |  ` wp-admin/*`   `wp-login.php `  |  기본값(\$1)  | 
|  프로토콜  |  HTTP 및 HTTPS  |  리디렉션 대상 HTTPS  |  HTTP 및 HTTPS  | 
|  HTTP 메서드  |  GET, HEAD  |  ALL  |  ALL  | 
|  HTTP 헤더  |  NONE  |  ALL  |   Host   CloudFront-Forwarded-Proto   CloudFront-Is-Mobile-Viewer   CloudFront-Is-Tablet-Viewer   CloudFront-Is-Desktop-Viewer   | 
|   |   |   |   | 
|  쿠키  |  NONE  |  ALL  |   의견\$1\$1   wordpress\$1\$1   wp-settings-\$1   | 
|  쿼리 문자열  |  YES (무효화)  |  YES  |  YES  | 

 기본 동작의 경우 는 다음 구성을 AWS 권장합니다.
+  오리진 프로토콜 정책이 뷰어와 일치하도록 허용하여 시청자가 를 사용하여 에 CloudFront 연결하면 HTTPS도 를 사용하여 오리진에 HTTPS CloudFront 연결하여 암호화를 달성 end-to-end합니다. 이렇게 하려면 로드 밸런서에 신뢰할 수 있는 SSL 인증서를 설치해야 합니다. 자세한 내용은 [ CloudFront 및 사용자 지정 오리진 간의 HTTPS 통신 요구 섹션을 참조하세요](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html).
+  웹 사이트의 동적 부분에 GET 및 POST 요청이 모두 필요하므로(예: POST 의견 제출 양식 지원) 모든 HTTP 방법을 허용합니다.
+  , 및 와 같이 WordPress 출력을 변경하는 쿠키만 전달합니다`>wordpress_*``wp-settings-*``comment_*`. 목록에 없는 다른 쿠키에 종속되는 플러그인을 설치한 경우 해당 목록을 확장해야 합니다.
+  , WordPress, `Host`, , 등의 출력에 영향을 미치는 HTTP 헤더만 전달합니다`CloudFront-Forwarded-Proto``CloudFront-is-Desktop-Viewer``CloudFront-is-Mobile-Viewer``CloudFront-is-Tablet-Viewer`.
  +  `Host` 는 여러 WordPress 웹 사이트를 동일한 오리진에서 호스팅할 수 있도록 허용합니다.
  +  `CloudFront-Forwarded-Proto` 에서는 HTTP 또는 를 통해 액세스되는지 여부에 따라 다양한 버전의 페이지를 캐시할 수 있습니다HTTPS.
  +  `CloudFront-is-Desktop-Viewer`, `CloudFront-is-Mobile-Viewer`를 `CloudFront-is-Tablet-Viewer` 사용하면 최종 사용자의 디바이스 유형에 따라 테마의 출력을 사용자 지정할 수 있습니다.
+  모든 쿼리 문자열을 해당 값에 따라 캐시에 전달합니다. WordPress 는 이러한 쿼리 문자열을 사용하므로 캐시된 객체를 무효화하는 데 사용할 수도 있습니다.

 사용자 지정 도메인 이름(즉, 가 아님`*.cloudfront.net`)으로 웹 사이트를 제공하려면 배포 설정의 **대체** 도메인 이름URIs에 적절한 를 입력합니다. **** 이 경우 사용자 지정 도메인 이름에 대한 SSL 인증서도 필요합니다. AWS Certificate Manager를 통해 SSL 인증서를 [요청](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request.html)하고 CloudFront 배포에 대해 구성할 수 있습니다.

 이제 동적 콘텐츠에 대해 두 가지 캐시 동작을 추가로 생성합니다. 하나는 로그인 페이지(경로 패턴: `wp-login.php`)용이고 다른 하나는 관리자 대시보드(경로 패턴: )용입니다`wp-admin/*`. 이러한 두 동작은 다음과 같이 정확히 동일한 설정을 갖습니다.
+  의 뷰어 프로토콜 정책HTTPS만 적용합니다.
+  모든 HTTP 메서드를 허용합니다.
+  모든 HTTP 헤더를 기반으로 캐시합니다.
+  모든 쿠키를 전달합니다.
+  모든 쿼리 문자열을 기반으로 전달 및 캐시합니다.

이 구성의 이유는 웹 사이트의 이 섹션이 고도로 개인화되어 있고 일반적으로 사용자 수가 적기 때문에 캐싱 효율성이 주요 관심사가 아니기 때문입니다. 모든 쿠키와 헤더를 오리진에 전달하여 설치된 플러그인과의 호환성을 극대화하기 위해 구성을 간단하게 유지하는 것이 중요합니다.

기본적으로 는 [단일 서버 배포](simple-deployment.md)의 경우 블록 스토리지(Amazon EBS)이고 [탄력](elastic-deployment.md)적 배포의 경우 파일 스토리지(Amazon EFS)인 모든 것을 웹 서버에 로컬로 WordPress 저장합니다. 스토리지 및 데이터 전송 비용을 줄이는 것 외에도 정적 자산을 Amazon S3로 이동하면 확장성, 데이터 가용성, 보안 및 성능이 제공됩니다. 정적 콘텐츠를 Amazon S3로 쉽게 이동할 수 있는 몇 가지 플러그인이 있습니다. 그 중 하나는 [W3 Total Cache](https://wordpress.org/plugins/w3-total-cache/) 이며, [부록 B: 플러그인 설치 및 구성 ](appendix-b-plugins-installation-and-configuration.md)에서도 다룹니다.