S3 + Cloudfront를 이용해 www redirect를 구현한 Static Website 호스팅하기

 

 

유저들이 웹 사이트에 접속할때 주소를 입력하는 방법은 여러가지가 존재합니다.

 

Google에 접속하고자 할때 누군가는 www.google.com으로 접속할 수도 있지만,

 

누군가는 그저 google.com 으로 접속하고는 합니다.

 

혹은 심지어 https://www.google.com 을 입력해서 접속하는 유저도 존재합니다.

 

이렇게 유저들이 다양한 방법으로 웹 사이트에 접속하지만, 웹 사이트를 운영하는 입장에서는 결국 하나의 엔드포인트로 접속을 유도해야 합니다.

 

유저들의 다양한 접속 주소에 모두 대응하는 것은 현실적으로 어렵기 때문입니다.

 

이 경우 모든 유저들의 접속 경로를 단일화하기 위해서 사용할 수 있는 방법이  페이지 리다이렉션입니다.

 

페이지 리다이렉션을 통해서 여러 유저들의 최종 접속 경로를 단일 엔드포인트로 유도할 수 있습니다.

 

이번 포스팅에서는 S3 버켓의 Static Web hosting 기능을 이용해 호스팅되는 정적 웹 페이지를 non-www 에서 www로 리다이렉션하는 방법에 대해서 알아보겠습니다.

 

 

 

1. Overview

 

먼저 non-www -> www 리다이렉션이 가능한 웹사이트 호스팅을 구현하기 위해서 필요한 개념 및 구성요소들을 알아보겠습니다.

 

 

1-1. Requirements

이번 포스팅에서는 AWS의 Static Web Hosting을 지원하는 오브젝트 스토리지 서비스인 S3와,

 

CDN 서비스인 CloudFront를 사용하여 리다이렉션이 가능한 웹사이트 호스팅을 구현하겠습니다.

 

필요한 구성요소들은 다음과 같습니다.

 

 

• 웹사이트 컨텐츠를 적재하기 위한 S3 Bucket 1개
• non-www 도메인으로 접근했을 시 리다이렉션을 수행하는 S3 Bucket 1개
• www 도메인의 엔드포인트 및 캐싱을 담당하는 Cloudfront Distribution 1개
• non-www 도메인의 엔드포인트 및 캐싱을 담당하는 Cloudfront Distribution 1개
  
  
• www 및 non-www 도메인의 인증을 위한 Certificate 1개

 

그 외에 도메인을 관리하기 위한 웹사이트를 호스팅하기 위한 컨텐츠, 도메인 서비스, 및 AWS account가 필요합니다.

 

 

1-2. Architecture

 

 

이번 포스팅에서 알아볼 Static Web hosting의 아키텍쳐 다이어그램은 위와 같습니다.

 

상황별 웹사이트 접근 시 진행 순서는 다음과 같습니다.

 

 

Case 1. Client가 "https://www.example.com" 주소로 접근

1. www Cloudfront가 Root path("/")에 매핑된 캐시가 존재하는지 확인합니다.
2. 캐시가 존재한다면 이를 Client에게 전달하고,
   캐시가 존재하지 않는다면 www S3 bucket에 컨텐츠를 요청하고 이를 Client에게 전달합니다.
   
   

Case 2. Client가 "www.example.com" 주소로 접근

1. www Cloudfront가 https://www.example.com 으로 3xx redirection을 수행합니다.
2. www Cloudfront가 Root path("/")에 매핑된 캐시가 존재하는지 확인합니다.
3. 캐시가 존재한다면 이를 Client에게 전달하고,
   캐시가 존재하지 않는다면 www S3 bucket에 컨텐츠를 요청하고 이를 Client에게 전달합니다.

Case 3. Client가 "https://www.example.com" 주소로 접근

1. www Cloudfront가 Root path("/")에 매핑된 캐시가 존재하는지 확인합니다.
2. 캐시가 존재한다면 이를 Client에게 전달하고,
   캐시가 존재하지 않는다면 www S3 bucket에 컨텐츠를 요청하고 이를 Client에게 전달합니다.
   
   

Case 3. Client가 "http://www.example.com" 주소로 접근

1. www Cloudfront가 https://www.example.com 으로 3xx redirection을 수행합니다.
2. www Cloudfront가 Root path("/")에 매핑된 캐시가 존재하는지 확인합니다.
3. 캐시가 존재한다면 이를 Client에게 전달하고,
   캐시가 존재하지 않는다면 www S3 bucket에 컨텐츠를 요청하고 이를 Client에게 전달합니다.

Case 4. Client가 "https://example.com" 주소로 접근

1. 요청을 전달받은 non-www S3 bucket은 https://www.example.com 으로 3xx redirection을 수행합니다.
2. www Cloudfront가 Root path("/")에 매핑된 캐시가 존재하는지 확인합니다.
3. 캐시가 존재한다면 이를 Client에게 전달하고,
   캐시가 존재하지 않는다면 www S3 bucket에 컨텐츠를 요청하고 이를 Client에게 전달합니다.

Case 5. Client가 "example.com" 주소로 접근

1. non-www Cloudfront가 https://example.com 으로 3xx redirection을 수행합니다.
2. 요청을 전달받은 non-www S3 bucket은 https://www.example.com 으로 3xx redirection을 수행합니다.
3. www Cloudfront가 Root path("/")에 매핑된 캐시가 존재하는지 확인합니다.
4. 캐시가 존재한다면 이를 Client에게 전달하고,
   캐시가 존재하지 않는다면 www S3 bucket에 컨텐츠를 요청하고 이를 Client에게 전달합니다.

Case 6. Client가 "http://example.com" 주소로 접근

1. non-www Cloudfront가 https://example.com 으로 3xx redirection을 수행합니다.
2. 요청을 전달받은 non-www S3 bucket은 https://www.example.com 으로 3xx redirection을 수행합니다.
3. www Cloudfront가 Root path("/")에 매핑된 캐시가 존재하는지 확인합니다.
4. 캐시가 존재한다면 이를 Client에게 전달하고,
   캐시가 존재하지 않는다면 www S3 bucket에 컨텐츠를 요청하고 이를 Client에게 전달합니다.

 

 

2. 구성

리다이렉션 웹사이트 호스팅의 구성요소와 개념에 대해 알아봤으니, 이를 기반으로 환경을 구성하는 방법에 대해 알아보겠습니다.

 

 

2-1. S3 Bucket 구성

가장 먼저 웹사이트 컨텐츠를 호스팅할 S3 bucket을 구성해보겠습니다.

 

S3는 AWS에서 제공하는 오브젝트 스토리지 서비스로, Static website hosting 및 관련 요청을 Redirect할 수 있는 기능을 제공하고 있습니다

 

S3 bucket은 웹사이트 컨텐츠를 제공할 www S3 bucket과 리다이렉션을 수행하는 non-www S3 bucket이 필요합니다.

 

 

www S3 bucket

웹사이트 컨텐츠 제공을 담당하는 www S3 bucket은 다음과 같이 구성합니다.

 

- Object
Static Website 구성에 필요한 오브젝트들을 해당 bucket에 적재합니다. 

 

- Properties

Bucket versioning, Tags, Object lock 등의 설정은 자유롭게 구성 가능합니다.

단 Static website hosting 설정은 아래와 같이 구성합니다.
Static website hosing : Enabled

Hosting type : Host a static website
구성 후에는 http://BUCKET_NAME.s3.website-REGION.amazonaws.com 형태의 S3 Website endpoint가 생성되는 것을 확인할 수 있습니다.

 

- Permissions

Block public access는 Off 하여 퍼블릭 접근 제한을 해제합니다.

단 퍼블릭 접근 제한을 해제했을시 보안면에서 위협이 될 수 있으므로, GetObject 행위만 허용하도록 Bucket Policy를 구성합니다.

 

필요한 Bucket Policy는 다음과 같습니다.

 

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

 

non-www S3 bucket

다음으로 non-www 도메인으로 접근했을 시 www 도메인으로 redirection을 수행하는 non-www S3 bucket을 다음과 같이 구성합니다. 

 

- Object

Bucket에는 아무 object도 적재하지 않습니다. 이 Bucket은 Website hosting이 아닌 www 도메인으로의 redirection만을 수행하기 때문에 object가 필요하지 않습니다. 

 

- Properties

www S3 bucket과 동일하지만, Static webiste hosting 설정은 아래와 같이 구성합니다.

Static website hosting : Enabled

Hosting Type : Redirect requests for an object

Host name : "www.example.com"
(redirection할 www 도메인을 입력합니다.)

 

- Permissions

www S3 bucket과 동일하게 구성합니다.

 

 

2-2. Cloudfront 구성

다음으로 S3 bucket의 Static webiste 컨텐츠를 캐싱해주는 Cloudfront를 구성하겠습니다.

 

Cloudfront는 AWS의 CDN 서비스로 엣지 로케이션의 캐시 제공과 함께 HTTPS 리다이렉션 기능을 제공하고 있습니다.

 

Cloudfront는 www 도메인을 담당하는 distribution과 non-www 도메인을 담당하는 distribution이 필요합니다.

 

 

www Cloudfront distribution

www 도메인으로 접근하는 엔드포인트 및 캐싱을 담당하는 www Cloudfront distribution은 다음과 같이 구성합니다.

 

-General

Discription 및 Edge location, HTTP version 등의 설정은 자유롭게 구성합니다.

단 도메인 관련 설정은 다음과 같이 구성합니다.
Alternate domain names : www.example.com (www 도메인 네임 입력) 

SSL certificate : 사용할 도메인을 인증할 수 있는 SSL Certificate

 

-Origins

Cloudfront distribution이 컨텐츠를 가져올 소스를 지정합니다.

Origin domain에 www S3 bucket의 Website endpoint를 입력합니다.

콤보박스에서 선택할 수 있는 S3 bucket endpoint가 아닌 Static website hosting 설정시 확인할 수 있는 Website endpoint를 입력해야 함에 유의합니다.

 

-Behavior

Cloudfront의 캐싱 동작을 지정합니다. 다음과 같이 구성합니다.

Origin and origin groups: Origin란에서 생성한 www S3 bucket Website endpoint를 지정합니다.

Viewer protocol policy: HTTP / HTTPS 둘 중 어떤 프로토콜로 접근하더라도 HTTPS로 접근할 수 있도록 Redirect HTTP to HTTPS를 지정합니다.

그 외에 HTTP methods는 일반적인 Static website의 경우 CORS 처리를 위한 GET, HEAD, OPTIONS를 권장합니다.

캐싱 정책은 요구사항에 따라 자유롭게 구성합니다.

그 외에 Origin으로 보내는 요청에 대한 정책을 구성할 수 있는 Origin request policy, 응답 헤더에 대한 정책을 구성할 수 있는 Response headers policy를 지정할 수 있습니다.

 

 

non-www Cloudfront distribution

다음으로 non-www 도메인으로 접근하는 엔드포인트 및 캐싱을 담당하는 non-www Cloudfront distribution을 다음과 같이 구성합니다.

 

-General

마찬가지로 Discription 및 Edge location, HTTP version 등의 설정은 자유롭게 구성합니다.

도메인 관련 설정은 다음과 같이 구성합니다.
Alternate domain names : example.com (non-www 도메인 네임 입력) 

SSL certificate : 사용할 도메인을 인증할 수 있는 SSL Certificate (와일드카드 도메인을 사용하지 않을시, 루트 도메인을 위한 Certificate가 별도로 필요함에 유의합니다.)

 

-Origins

Origin domain에 non-www S3 bucket의 Website endpoint를 입력합니다.

마찬가지로 S3 bucket의 Website endpoint를 입력해야 함에 유의합니다.

 

-Behavior

www Cloudfront distribution과 동일하게 구성합니다.

Origin and origin groups: Origin란에서 생성한 non-www S3 bucket Website endpoint를 지정합니다.

Viewer protocol policy: HTTP / HTTPS 둘 중 어떤 프로토콜로 접근하더라도 HTTPS로 접근할 수 있도록 Redirect HTTP to HTTPS를 지정합니다.

 

2-3. 도메인 구성

생성된 Cloudfront 엔드포인트를 www 및 non-www 도메인에 매핑해 적절한 경로로 진입할 수 있도록 구성합니다.

 

다음과 같이 루트 도메인에는 non-www Cloudfront distribution의 endpoint를,

www 도메인에는 www Cloudfront distribution의 endpoint를 CNAME으로 지정합니다.

 

추가적으로 각 도메인에 HTTPS 통신에 필요한 SSL Certificate가 없을 경우,
AWS의 ACM(AWS Certificate Manager)에서 AWS Managed Certificate를 발급받을 수 있습니다.

 

 

앞서 언급했듯이, 와일드카드 도메인의 Certificate를 발급받는다면 1개의 Cert로 두 도메인을 인증할 수 있지만

 

non-www와 www 도메인을 별개의 Cert로 인증받고자 한다면 root 도메인과 www 도메인 2개의 Certificate가 필요합니다.

 

 

3. DEMO

이제 구성된 환경을 기반으로 생성된 웹사이트에 접근해 실제 동작을 확인해보겠습니다.

 

"https://www.example.com" 주소로 접근 시

웹 브라우저에서 "https://www.example.com" (본 포스팅의 경우 "https://www.test-for-lswoo.kro.kr") 주소로 접근시 결과입니다.

 

 

이 경우 200 코드와 함께 웹사이트 컨텐츠를 반환하는 것을 확인할 수 있습니다.

 

캐싱된 컨텐츠가 존재할경우 Cloudfront에서 곧바로 응답을 반환하며, 캐싱된 컨텐츠가 존재하지 않을경우 S3 bucket origin에서 경로에 따른 컨텐츠를 응답합니다.

 

 

이 경우 유저들은 "https://www.example.com" -> 200 순으로 접근합니다. 

 

 

"www.example.com" 주소로 접근 시

HTTP 프로토콜로 접근시에는 가장 먼저 Cloudfront distribution이 Redirect HTTP -> HTTPS 설정에 따라 HTTPS 주소로 리다이렉션을 수행합니다. 

 

따라서 "www.." 주소로 접근할 경우에는 "https://www.." 주소로 301 redirect되는 것을 확인할 수 있습니다.

 

참고로 현재 대부분의 웹 브라우저는 자동으로 https 프로토콜을 이용해 접속하므로 웹 브라우저 접속할 경우 별다른 리다이렉션 없이 "https://www.test-for-lswoo.kro.kr" 주소로 접근합니다.

 

 

이후 리다이렉트되는 https://www... 주소로 접근하면 200 코드와 함께 html 컨텐츠를 반환하는 것을 볼 수 있습니다.

 

 

이 경우 유저들은 "www.example.com" -> "https://www.example.com" -> 200 순으로 접근합니다. 

 

 

"https://example.com" 주소로 접근 시

https://.. 와 같은 non-www 주소로 접근했을시에는 non-www S3 bucket을 Origin으로 가지는 Cloudfront로 요청을 전송하게 됩니다.

 

요청을 받은 non-www S3 bucket은 Rediretion 정책에 따라 www 도메인으로 3xx redirection을 수행합니다.

 

따라서 아래와 같이 301 rediretion이 일어나는 것을 확인할 수 있습니다.

 

 

이후에는 평소와 같이 200 코드와 함께 html 컨텐츠를 반환하는 것을 볼 수 있습니다.

 

 

이 경우 유저들은 "https://example.com" -> "https://www.example.com" -> 200 순으로 접근합니다. 

 

 

"http://example.com" 주소로 접근 시

non-www 도메인에 http 프로토콜로 접근했을시, www redirection과 https redirection 중 먼저 일어나는 것은 https redirection입니다.

 

따라서 "http://..."와 같은 주소로 접근했을시 다음과 같이 https redirection을 가장 먼저 수행하는 것을 확인할 수 있습니다.

 

 

이후에는 "https://..." 주소로 접근했을 때와 동일하게 www redirection을 수행합니다.

 

 

www redirection 후에는 200 코드와 함께 html 컨텐츠를 반환합니다.

 

 

이 경우 유저들은 "http://example.com" -> "https://example.com" -> "https://www.example.com" -> 200 순으로 접근합니다. 

 

 

4. 마치며

 

지금까지 AWS의 S3와 Cloudfront를 활용하여 non-www 도메인으로 접근시 www 도메인으로 redirection을 수행하는 Static website hosting 구성 방법을 알아봤습니다.

 

추가적으로 HTTP 프로토콜로 접근했을시 HTTPS 프로토콜로 redirection을 수행함으로써 결과적으로 어떤 프로토콜/경로로 접근해도 단일 엔드포인트에서 컨텐츠를 반환할 수 있었습니다.

 

현재 대부분의 유명 웹사이트들은 Client에게 편의성을 제공하기 위해 www 리다이렉션을 제공하고 있습니다.

 

덕분에 Client들은 www 서브도메인을 입력하지 않고도 웹사이트에 접근할 수 있게 되었죠.

 

어쩌면 이제 www 리다이렉션은 편의성을 제공하는 것 뿐만이 아니라 웹사이트의 운영 퀄리티를 대변하는 기능도 수행하고 있다는 생각이 듭니다. 

 

이 포스팅을 보시는 분들이 관련 정보를 얻는데 도움이 되었으면 합니다.