Contents

[1] 배경

특정 도메인에 연결된 서비스를 긴급하게 점검페이지(흔히 파킹페이지)로 띄울 상황이 있습니다.
호스팅 도메인에서 Nameserver를 별도로 사용하거나, AWS Route53 DNS를 통해 서비스를 할 경우에 Cloudfront 의 DNS이름을 레코드로 추가하여 호스팅할 수 있습니다.

Amazon S3의 정적 웹 호스팅과 CloudFront를 통합하여 사용할 때, 긴급 장애나 서비스 점검 시 사용자들에게 우회 페이지를 전달하기로 하였습니다.

S3 우회 페이지 준비
- 별도의 S3 버킷에 서비스 점검이나 오류에 대한 우회 페이지를 미리 준비합니다.
- 이 페이지는 정상적인 서비스가 이용할 수 없을 때 사용자에게 표시될 메시지를 포함해야 합니다.

CloudFront 오류 페이지 설정
- CloudFront 배포 설정에서 사용자 정의 오류 응답을 구성합니다.
- 503 서비스 사용 불가 등의 특정 HTTP 상태 코드에 대해 위에서 준비한 S3 우회 페이지를 반환하도록 설정합니다.
- 이렇게 설정하면, 백엔드 시스템에 문제가 발생했을 때 CloudFront는 자동으로 우회 페이지를 제공합니다.

긴급 상황 발생 시 대응
- 긴급 장애나 서비스 점검이 필요할 때, 원본 서비스를 점검 상태로 전환합니다.
- CloudFront가 백엔드 오류를 감지하면, 앞서 설정한 사용자 정의 오류 응답에 따라 S3의 우회 페이지를 반환하게 됩니다.

옵션 - 라우팅 정책 변경을 통한 우회
- Route 53의 라우팅 정책(예: 실패 시 우회 라우팅)을 활용하여, 백엔드 서비스에 문제가 감지될 때 특정 리소스(예: S3의 우회 페이지)로 트래픽을 라우팅하는 방법도 있습니다.

복구
서비스가 정상적으로 복구되면 원본 서비스로 돌아갈 수 있도록 설정을 원래대로 복구합니다.
필요하다면 CloudFront의 캐시를 무효화하여 최신 컨텐츠가 바로 사용자에게 전달되도록 합니다.
이러한 방법을 통해 AWS의 서비스를 활용하여 긴급 장애나 서비스 점검 상황에서도 사용자에게 안내 페이지를 제공함으로써 좋은 사용자 경험을 유지할 수 있습니다.

[2] 작업 순서 및 내용

### 핸즈온 순서 ###
1. S3 Bucket - Static image 업로드용 생성
2. S3 Bucket - index.html 호스팅용 생성
3. CloudFront - Distributions > 배포 생성
4. Route53 > CloudFront 의 DNS Name 설정
5. 정적 웹호스팅 사이트로 메인 도메인 서비스 사이트를 우회

2-1. S3 Bucket – Static image 업로드용 생성

web용
- PATH: s3://svc-image-bucket/parking-path/parking-image-web.png
- Image Scale: 1920px * 1080px
mobile용
- PATH: s3://svc-image-bucket/parking-path/parking-image-mob.png
- Image Scale: 360px * 760px

2-2. S3 Bucket – index.html 호스팅용 생성

web 공용
- PATH: s3://svc-hosting-bucket-web/index.html
- index.html: 하단 web용 index.html 참조
- Properties > Static website hosting
  - Static website hosting: Enable
  - Hosting type: Host a static website
  - Index document: index.html
mobile 용
- PATH: s3://svc-hosting-bucket-mob/index.html
- index.html: 하단 mobile용 index.html 참조
- Properties > Static website hosting
  - Static website hosting: Enable
  - Hosting type: Host a static website
  - Index document: index.html

2-2-1. 참조 – index.html(web용)

<!doctype html>
<html>
<head>

<meta charset="utf-8">
<title>시스템 작업 안내</title>
</head>

<body>
	<div style="width: 100%;">
<div><img src="http://image.example.com/parking-path/parking-image-web.png" width="100%">
	<div style="height: 50%;">
	</div>

</div>
</div>
	</div>
</body>
</html>

2-2-2. 참조 – index.html(mobile용)

<!doctype html>
<html>
<head>

<meta charset="utf-8">
<title>시스템 작업 안내</title>
</head>

<body>
	<div style="width: 100%;">
<div><img src="http://image.example.com/parking-path/parking-image-mob.png" width="100%">
	<div style="height: 50%;">
	</div>

</div>
</div>
	</div>
</body>
</html>

2-3. CloudFront – Distributions > Create

Distributions 를 생성하게 되면 크게 다음과 같은 범주를 설정할 수 있으며, 차후에도 인증서/캐싱/오리진 변경 등이 가능하다.

Origin
Default cache behavior
Cache key and origin requests
Function associations – optional
Settings (General Settings)

Orgin domain: 직전 생성한 hosting 용 s3용 bucket을 선택합니다. 이때 s3 web-hosting endpoint url 로 변경할 수 있습니다.

Orgin Shield는 CDN 앞단에 추가 캐싱 레이어를 제공해서 원본 서버(origin)에 대한 요청을 줄이는데 도움을 줍니다. 여로모로 장점이 있어서 이미지 컨텐츠 기반으로 장기 정적 사이트 웹호스팅시 도움을 줍니다.
AWS CloudFront Origin Shield 장점
- 중앙 집중식 캐싱: Origin Shield는 중앙 집중식 캐싱 레이어 역할을 합니다. 다양한 CloudFront 배포에서 요청이 발생할 때, 이러한 요청이 Origin Shield에 먼저 도달하게 됩니다. 이렇게 하면 원본 서버에 대한 중복 요청을 줄일 수 있습니다.
- 원본 서버 부하 감소: 여러 CloudFront 엣지 위치에서 동일한 콘텐츠에 대한 요청이 오게 되면, 이러한 요청은 Origin Shield를 통해 처리되므로 원본 서버의 부하가 크게 감소합니다.
- 원본 비용 절감: 원본 서버에 대한 요청 횟수가 줄어들기 때문에 호스팅 및 데이터 전송 비용을 절감할 수 있습니다.
- 컨텐츠 재검색 효율성: 만약 CloudFront 엣지 캐시에서 콘텐츠가 만료되었을 경우, Origin Shield를 사용하면 콘텐츠를 효율적으로 다시 가져올 수 있습니다.
- 향상된 안정성: Origin Shield를 통해 원본 서버에 대한 요청을 줄일 수 있으므로, 원본 서버의 잠재적인 장애에 대한 영향을 최소화할 수 있습니다.

HTTP 요청을 전달 받아서 HTTPS 로 리디렉션하는 정책을 선택합니다.
보안 및 데이터 무결성을 강화하기 위해 필수입니다. (데이터 보안/데이터 무결성/인증서 기반 신뢰성 인증/검색엔진 최적화(SEO)/브라우져 HTTPS 인증 업데이트/규정 및 준수 등등..)

Cache Key 및 Origin requests 는 기본 값으로 설정

인증서는 AWS ACM(Amazon Certificate Manager) 에서 기존 조직에서 사용하는 SSL/TLS 인증서를 Import 하거나 AWS에서 발급받은 Amazon ACM 인증서를 추가한 것을 선택합니다.
이때 중요한 것, “Why is it necessary to import our SSL/TLS certificate into AWS ACM specifically in the N. Virginia (us-east-1) region for CloudFront usage?” 라고 질문 할 수 있으나, AWS CloudFront 는 글로벌 CDN(Global Contents Delivery Network) 서비스입니다.
CloudFront 배포를 위한 ACM 인증서를 사용하려면 해당 인증서가 반드시 us-east-1 (N. Virginia) 리전에 있어야 합니다!
이유를 찾아보니 아래와 같습니다.
이러한 설계의 주된 이유는 다음과 같습니다:
- 중앙 관리: AWS의 내부 아키텍처 및 운영에 관련된 이유로, CloudFront는 글로벌 서비스로 설계되었고 us-east-1 리전에서 중앙 집중식으로 관리됩니다. ACM 인증서를 이 리전에서 관리하면 모든 CloudFront 배포에 대한 인증서 관리를 중앙에서 수행할 수 있습니다.
- 간소화된 인프라: 인증서를 하나의 리전에서만 관리하도록 함으로써 AWS는 인프라의 복잡성을 줄이고 효율성을 높일 수 있습니다.
- 일관된 경험: 고객들에게 단일 리전에서 인증서를 관리하도록 하는 것은 일관된 사용 경험을 제공합니다. 따라서 사용자는 인증서를 어디에서 생성하거나 가져와야 하는지에 대한 혼란을 피할 수 있습니다.

2-4. CloudFront > Distributions > Alternate domain names(대체 도메인 이름) 변경

현재 임시 정적 웹호스팅을 배포한 상태이다.
DNS 서비스의 레코드 값을 CloudFront의 DNS이름으로 변경하기 전에, 위에 표시한 대체 도메인 이름 영역을 운영 서비스 도메인으로 변경하자. (그리고, 아래 DNS 변경 진행)

2-5. Route53 > CloudFront 의 DNS Name 설정

한번 CloudFront 의 배포를 생성하게 되면 DNSName이 생성됩니다. 이 과정에서 약간 5~10min 의 시간이 소요됩니다.
기존 메인 서비스하는 Route53 호스팅영역에서 아래와 같이 설정을 진행합니다.
Route 53에서 도메인에 대한 A 레코드 생성:
- 생성된 호스티드 영역 내에서 레코드 세트 생성을 클릭합니다.
- 레코드 세트 구성에서 다음 옵션을 선택/입력합니다:
  - 이름: 비워 둡니다 (example.com을 위한 레코드).
  - 유형: A – IPv4 주소
  - 별칭: 예
  - 별칭 대상: CloudFront 배포 도메인 이름을 선택합니다 (example: d12345abcdef8.cloudfront.net).
(선택 사항) www.example.com도 같은 CloudFront 배포로 라우팅하려면:
- Route 53 내에서 새로운 레코드 세트를 생성합니다.
  - 이름: www
  - 유형: A – IPv4 주소
  - 별칭: 예
  - 별칭 대상: CloudFront 배포 도메인 이름을 선택합니다.
  - 레코드 세트를 저장합니다.
도메인 이름이 예를 들어 example.com 및 www.example.com 일때, CloudFront를 통해 Amazon S3 버킷의 정적 웹 페이지로 올바르게 라우팅됨. 하지만 DNS 전파로 인해 변경 사항이 완전히 적용되기까지 몇 시간이 걸릴 수 있습니다.

[3] 결론

웹사이트나 애플리케이션을 인터넷에 노출시키려면 도메인 이름이 필요합니다. Route 53을 사용하면 호스팅 영역을 통해 도메인을 쉽게 aws 기능과 통합 시킬 수 있는 장점이 있습니다.

사실 이번 내용은 Route53(혹은 기타 웹호스팅 사이트)과 쉽게 서비스를 우회하여 페이지를 임시 전환할 수 있고, 그로 인해 트래픽이 서비스가 아닌 임시 페이지로 가이드하는 내용입니다.

Amazon S3의 정적 웹 호스팅과 CloudFront를 통합하여 사용할 때, 긴급 장애나 서비스 점검 시 사용자들에게 우회 페이지(예: 서비스 점검중인 페이지, 오류 페이지 등)를 제공이 가능합니다.

서비스 안정성: Route 53의 높은 가용성과 확장성 덕분에 사용자는 지속적으로 안정적인 웹서비스나 애플리케이션 접근을 경험하게 됩니다.
효율적인 트래픽 관리: 다양한 라우팅 정책을 활용하여 사용자에게 최적의 리소스로 라우팅함으로써 응답 속도를 최적화할 수 있습니다.
비용 효율: 사용량 기반의 비용 책정 모델 덕분에 필요한 만큼의 리소스만 사용하고 비용을 지불하게 됩니다.
강력한 보안: AWS의 보안 기능을 활용하여 DNS 데이터와 트래픽을 보호할 수 있습니다.
손쉬운 관리: AWS 콘솔을 통해 Route 53을 쉽게 설정하고 관리할 수 있습니다.