CloudFront 배포 생성

배포를 따라 CloudFront 웹 배포를 생성합니다. 자동으로 생성된 기본 오리진 및 동작이 동적 콘텐츠에 사용됩니다. 4개의 추가 동작을 생성하여 정적 요청과 동적 요청이 모두 처리되는 방식을 추가로 사용자 지정합니다. 다음 표에는 다섯 가지 동작에 대한 구성 속성이 요약되어 있습니다. 이 수동 구성을 건너뛰고 부록 B: 플러그 인 설치 및 구성에 설명되어 있는 AWS for WordPress 플러그 인을 사용할 수도 있습니다. 이것이 WordPress 사이트를 가속화하도록 CloudFront를 구성하는 가장 쉬운 방법입니다.

표 1: CloudFront 동작 구성 속성 요약

속성	정적	동적(관리자)	동적(프런트 엔드)
경로(동작)	wp-content/* wp-includes/*	wp-admin/* wp-login.php	기본값(*)
프로토콜	HTTP 및 HTTPS	HTTPS로 리디렉션	HTTP 및 HTTPS
HTTP 메서드	GET, HEAD	모두	모두
HTTP 헤더	없음	모두	호스트 CloudFront-Forwarded-Proto CloudFront-Is-Mobile-Viewer CloudFront-Is-Tablet-Viewer CloudFront-Is-Desktop-Viewer
쿠키	없음	모두	comment_* wordpress_* wp-settings-*
쿼리 문자열	예(무효화)	예	예

기본 동작의 경우 다음 구성을 권장합니다.

• 최종 사용자가 HTTPS를 사용하여 CloudFront에 연결하는 경우 CloudFront도 HTTPS를 사용하여 오리진에 연결하여 엔드투엔드 암호화를 달성할 수 있도록 오리진 프로토콜 정책이 최종 사용자와 일치하도록 허용합니다. 이를 위해서는 로드 밸런서에 신뢰할 수 있는 SSL 인증서를 설치해야 합니다. 자세한 내용은 CloudFront와 사용자 지정 오리진 간의 통신에 HTTPS 요구를 참조하십시오.

• 웹 사이트의 동적 부분에는 GET 및 POST 요청이 모두 필요하므로(예: 주석 제출 양식에 POST를 지원하기 위해) 모든 HTTP 메서드를 허용합니다.

• WordPress 출력을 변경하는 쿠키만 전달합니다(예: >wordpress_*, wp-settings-* 및 comment_*). 목록에 없는 다른 쿠키에 의존하는 플러그 인을 설치한 경우 해당 목록을 확장해야 합니다.

• WordPress의 출력에 영향을 미치는 HTTP 헤더만 전달합니다(예: Host, 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이 아님) 배포 설정의대체 도메인 이름 아래에 적절한 URI를 입력합니다. 이 경우 사용자 지정 도메인 이름에 대한 SSL 인증서도 필요합니다. AWS Certificate Manager를 통해 SSL 인증서를 요청하고 CloudFront 배포에 대해 구성할 수 있습니다.

이제 동적 콘텐츠용 캐시 동작을 두 개 더 만듭니다. 하나는 로그인 페이지(경로 패턴: wp-login.php)를 위한 것이고 다른 하나는 관리 대시보드(경로 패턴: wp-admin/*)를 위한 것입니다. 이 두 동작의 설정은 다음과 같습니다.

• HTTPS 전용의 최종 사용자 프로토콜 정책을 적용합니다.

• 모든 HTTP 메서드를 허용합니다.

• 모든 HTTP 헤더를 기반으로 캐시합니다.

• 모든 쿠키를 전달합니다.

• 모든 쿼리 문자열을 기반으로 전달 및 캐시합니다.

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

부록 B에서 설명한 AWS for WordPress 플러그 인은 위의 구성을 충족하는 CloudFront 배포를 자동으로 생성합니다.

기본적으로 WordPress는 모든 것을 단일 서버 배포의 경우 블록 스토리지(Amazon EBS) 또는 탄력적 배포의 경우 파일 스토리지(Amazon EFS)인 웹 서버에 로컬로 저장합니다. 스토리지 및 데이터 전송 비용을 줄이는 것 외에도 정적 자산을 Amazon S3로 이동하면 확장성, 데이터 가용성, 보안, 성능이 확보됩니다. 정적 콘텐츠를 Amazon S3로 쉽게 이동할 수 있는 플러그 인이 몇 가지 있습니다. 그중 하나가 부록 B: 플러그 인 설치 및 구성에도 설명되어 있는 W3 Total Cache입니다.