실전 AWS: S3 정적 호스팅부터 CloudFront CDN 최적화까지 ~ Dev.

현대 웹 개발 환경은 끊임없이 진화하고 있습니다. 과거에는 데이터베이스와 서버사이드 로직이 복잡하게 얽힌 동적 웹사이트가 주류를 이루었지만, Jamstack 아키텍처의 부상과 함께 클라이언트 측 렌더링 및 사전 렌더링(Pre-rendering) 기술이 보편화되면서 정적 웹사이트(Static Website)가 다시금 주목받고 있습니다. 정적 웹사이트는 단순한 HTML, CSS, JavaScript 파일의 집합을 넘어, 강력한 사용자 경험과 뛰어난 성능, 그리고 견고한 보안을 제공하는 현대적인 웹 애플리케이션의 핵심 기반으로 자리 잡았습니다.

이러한 정적 웹사이트를 배포하고 운영하는 데 있어 Amazon Web Services(AWS)의 S3(Simple Storage Service)는 가장 신뢰할 수 있고 비용 효율적인 솔루션 중 하나로 꼽힙니다. 하지만 단순히 S3에 파일을 올리는 것만으로는 현대 웹이 요구하는 속도, 보안, 안정성을 모두 충족시키기 어렵습니다. 진정한 프로덕션 수준의 정적 웹사이트를 구축하기 위해서는 S3를 기반으로 AWS의 다른 강력한 서비스들, 특히 콘텐츠 전송 네트워크(CDN) 서비스인 CloudFront와 DNS 서비스인 Route 53을 유기적으로 결합하는 과정이 필수적입니다. 이 글에서는 AWS S3를 이용한 기본적인 정적 웹사이트 호스팅 설정부터 시작하여, 커스텀 도메인을 연결하고, 최종적으로 CloudFront를 통해 전 세계 사용자에게 빠르고 안전하게 콘텐츠를 제공하는 전체 과정을 심도 있게 다룹니다.

1장: 왜 정적 웹사이트 호스팅에 AWS S3를 선택하는가?

1.1 정적 웹사이트의 부활과 그 본질적 가치

정적 웹사이트는 서버가 요청을 받을 때마다 데이터베이스 쿼리나 템플릿 렌더링 같은 복잡한 처리 과정 없이, 미리 생성된 HTML, CSS, JavaScript, 이미지 등의 정적 파일을 그대로 사용자에게 전달하는 방식의 웹사이트를 의미합니다. 이는 다음과 같은 명확하고 강력한 장점을 가집니다.

압도적인 속도: 서버 측 처리 과정이 없기 때문에 응답 시간이 매우 빠릅니다. 파일은 요청 즉시 전달되며, CDN과 결합될 경우 사용자와 가장 가까운 위치에서 콘텐츠를 제공받아 로딩 속도를 극적으로 단축시킬 수 있습니다.
강화된 보안: WordPress나 Joomla 같은 CMS(콘텐츠 관리 시스템) 기반의 동적 사이트에서 흔히 발견되는 서버사이드 언어(PHP, Python 등)나 데이터베이스 관련 보안 취약점으로부터 자유롭습니다. 공격 표면(Attack Surface) 자체가 매우 작아 보안 관리가 용이합니다.
비용 효율성: 고성능의 애플리케이션 서버나 데이터베이스 서버를 운영할 필요가 없습니다. 저렴한 객체 스토리지와 트래픽 비용만으로 운영이 가능하여, 개인 프로젝트부터 대규모 기업 사이트까지 비용 부담을 크게 줄일 수 있습니다.
뛰어난 확장성: 정적 파일은 캐싱이 매우 용이하므로, 갑작스러운 트래픽 급증에도 CDN을 통해 손쉽게 대응할 수 있습니다. 서버 증설과 같은 복잡한 과정 없이도 글로벌 규모의 트래픽을 감당할 수 있습니다.

Gatsby, Next.js(SSG 모드), Hugo, Jekyll과 같은 현대적인 정적 사이트 생성기(Static Site Generator, SSG)의 등장은 이러한 정적 웹사이트의 가능성을 한 단계 끌어올렸습니다. 개발자들은 React나 Vue와 같은 최신 프레임워크를 사용하여 동적인 개발 경험을 유지하면서도, 빌드 시점에는 최적화된 정적 파일들을 생성하여 정적 호스팅의 모든 이점을 누릴 수 있게 되었습니다.

1.2 객체 스토리지의 거인, AWS S3 심층 분석

AWS S3는 'Simple Storage Service'라는 이름에서 알 수 있듯이 파일을 저장하는 서비스이지만, 그 내부 구조와 철학은 일반적인 파일 시스템과는 근본적으로 다릅니다. S3는 객체 스토리지(Object Storage) 모델을 따릅니다.

파일 스토리지(File Storage) vs. 객체 스토리지(Object Storage): 일반적인 컴퓨터의 파일 시스템(NTFS, ext4 등)은 디렉터리 계층 구조를 가집니다. 반면, 객체 스토리지는 모든 데이터를 '객체(Object)'라는 단위로 취급하며, 이 객체들은 평평한 주소 공간(Flat Address Space)에 저장됩니다. 각 객체는 데이터 본체, 고유한 키(Key, 파일 이름과 경로의 조합), 그리고 풍부한 메타데이터로 구성됩니다. 이러한 구조는 무한에 가까운 확장성을 제공하는 비결입니다.

S3의 핵심 가치:

99.999999999% (11-nines)의 내구성: S3에 저장된 객체는 여러 가용 영역(Availability Zone)에 자동으로 복제되어 저장됩니다. 이는 1만 개의 객체를 1,000만 년 동안 저장했을 때 1개의 객체가 유실될까 말까 한 수준의 극도로 높은 데이터 내구성을 보장합니다.
높은 가용성과 확장성: S3는 전 세계 수백만 개의 애플리케이션에서 발생하는 요청을 처리하도록 설계되었습니다. 저장 공간의 한계나 성능 저하에 대한 걱정 없이 원하는 만큼의 데이터를 저장하고 트래픽을 처리할 수 있습니다.
다양한 스토리지 클래스: 데이터의 접근 빈도와 보관 기간에 따라 S3 Standard, S3 Intelligent-Tiering, S3 Glacier 등 다양한 스토리지 클래스를 선택하여 비용을 최적화할 수 있습니다.

이러한 S3의 특성은 정적 웹사이트의 파일(HTML, CSS, JS, 이미지 등)을 보관하고 서비스하기에 완벽한 환경을 제공합니다. 서버 관리에 대한 부담 없이, 극도의 안정성과 무한한 확장성을 바탕으로 웹사이트를 운영할 수 있는 것입니다.

2장: 첫걸음 떼기: S3 버킷 생성과 파일 업로드

이론을 알았으니 이제 직접 실습해볼 차례입니다. AWS 계정이 있다는 가정 하에, 정적 웹사이트를 호스팅할 S3 버킷을 생성하고 파일을 업로드하는 과정을 단계별로 진행합니다. AWS의 프리 티어는 S3에 대해 상당한 양의 무료 스토리지와 요청 횟수를 제공하므로, 작은 프로젝트는 비용 부담 없이 시작할 수 있습니다.

2.1 S3 버킷 생성: 상세 가이드

AWS Management Console에 로그인한 후, 서비스 검색창에서 'S3'를 검색하여 S3 대시보드로 이동합니다. 그리고 '버킷 만들기' 버튼을 클릭하여 생성 프로세스를 시작합니다.

버킷 이름: 버킷 이름은 S3의 모든 리전, 모든 계정을 통틀어 전역적으로 고유해야 합니다. 즉, 다른 누군가가 이미 사용 중인 이름은 사용할 수 없습니다. 또한, DNS 규약을 준수하는 것이 좋습니다.
- 소문자, 숫자, 하이픈(-)만 사용하세요.
- 마침표(.)를 포함할 수 있지만, SSL 인증서 문제나 다른 서비스와의 연동 시 예기치 않은 문제를 일으킬 수 있으므로, 커스텀 도메인을 연결할 계획이라면 마침표는 피하는 것이 좋습니다.
- 나중에 커스텀 도메인(예: www.example.com)을 연결할 계획이라면, 버킷 이름을 도메인 이름과 똑같이 www.example.com으로 만드는 것이 과거에는 일반적인 관행이었으나, CloudFront를 사용할 경우에는 필수가 아닙니다. 혼동을 피하기 위해 my-awesome-static-site와 같이 프로젝트를 설명하는 이름으로 짓는 것을 권장합니다.
AWS 리전(Region): 버킷이 물리적으로 생성될 데이터 센터의 위치를 선택합니다. 웹사이트의 주 사용자층과 가장 가까운 리전을 선택하는 것이 지연 시간(Latency)을 줄이는 데 유리합니다. 예를 들어, 주 사용자가 한국에 있다면 '아시아 태평양(서울) ap-northeast-2' 리전을 선택하는 것이 좋습니다. 리전별로 약간의 요금 차이가 있을 수 있습니다.
객체 소유권: 기본값인 'ACL 비활성화됨(권장)'을 유지합니다. 이는 버킷의 모든 객체 소유권을 버킷 소유자가 가지며, 접근 제어는 IAM 정책과 버킷 정책으로만 관리하겠다는 의미입니다. 이는 최신 AWS 보안 모범 사례입니다.
이 버킷의 모든 퍼블릭 액세스 차단: 이 부분이 매우 중요합니다. 기본적으로 모든 항목이 체크되어 있어 버킷에 대한 모든 퍼블릭 액세스가 차단됩니다. 정적 웹사이트를 호스팅하려면 인터넷상의 모든 사용자가 파일에 접근할 수 있어야 하므로, '모든 퍼블릭 액세스 차단' 체크박스를 해제해야 합니다. 체크를 해제하면 하위 4개의 개별 설정이 나타나는데, 지금은 모두 해제된 상태로 둡니다. 이후 버킷 정책을 통해 세밀하게 접근을 제어할 것이므로 걱정하지 않아도 됩니다. AWS는 이 설정 변경에 대한 경고와 확인을 요청할 것입니다. 내용을 이해했음을 확인하는 체크박스에 표시합니다.
기타 설정: 버킷 버전 관리, 태그, 기본 암호화 등은 지금 단계에서는 기본값으로 두어도 무방합니다. '버킷 만들기'를 클릭하여 생성을 완료합니다.

2.2 웹사이트 파일 준비 및 업로드

이제 생성된 버킷에 웹사이트를 구성하는 파일들을 업로드해야 합니다. 테스트를 위해 간단한 HTML, CSS, 오류 페이지 파일을 준비해 보겠습니다.

index.html:

<!DOCTYPE html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Awesome Static Site</title>
    <link rel="stylesheet" href="styles.css">
</head>
<body>
    <h1>Welcome to My S3 Hosted Website!</h1>
    <p>This website is served directly from an AWS S3 bucket.</p>
</body>
</html>

styles.css:

body {
    font-family: sans-serif;
    background-color: #f0f0f0;
    color: #333;
    display: flex;
    flex-direction: column;
    justify-content: center;
    align-items: center;
    height: 100vh;
    margin: 0;
}

h1 {
    color: #007BFF;
}

error.html:

<!DOCTYPE html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <title>Page Not Found</title>
    <link rel="stylesheet" href="styles.css">
</head>
<body>
    <h1>404 - Page Not Found</h1>
    <p>Oops! The page you are looking for does not exist.</p>
</body>
</html>

파일이 준비되었다면, S3 콘솔에서 방금 생성한 버킷을 클릭하여 들어간 후 '업로드' 버튼을 누릅니다. 파일 추가 또는 폴더 추가 버튼을 이용해 준비한 파일들을 모두 업로드합니다. 업로드 과정에서 권한이나 속성 등은 변경할 필요 없이 기본값으로 두고 업로드를 완료합니다.

전문가를 위한 팁: AWS CLI를 이용한 자동화

매번 콘솔을 통해 수동으로 파일을 업로드하는 것은 비효율적입니다. AWS Command Line Interface(CLI)를 사용하면 이 과정을 자동화할 수 있습니다. 로컬 컴퓨터에 AWS CLI를 설치하고 자격 증명을 설정한 후, 터미널에서 다음 명령어를 실행하면 로컬 폴더의 내용을 S3 버킷과 동기화할 수 있습니다.

aws s3 sync . s3://your-bucket-name --delete

.은 현재 디렉터리를 의미하며, s3://your-bucket-name은 대상 버킷을 지정합니다. --delete 옵션은 로컬에는 없지만 버킷에 존재하는 파일을 삭제하여, 로컬 폴더와 버킷의 상태를 완전히 동일하게 만듭니다. 이 명령어 하나로 웹사이트 배포를 간단하게 처리할 수 있습니다.

3장: 웹사이트의 심장: 권한과 호스팅 활성화

파일 업로드가 끝났다고 해서 웹사이트가 바로 열리지는 않습니다. S3에게 이 버킷을 웹사이트처럼 동작하도록 지시하고, 외부 사용자가 파일에 접근할 수 있도록 권한을 설정하는 두 가지 중요한 과정이 남아있습니다.

3.1 보안과 개방성의 균형: 버킷 정책(Bucket Policy) 설정

과거에는 객체별로 접근 제어 목록(ACL, Access Control List)을 설정하여 퍼블릭 읽기 권한을 부여했지만, 이는 관리가 복잡하고 실수가 발생하기 쉽습니다. 현대적인 AWS 환경에서는 버킷 정책을 사용하여 버킷 전체에 대한 접근 규칙을 중앙에서 관리하는 것을 강력히 권장합니다.

버킷 정책은 JSON 형식의 문서로, '누가(Principal)', '어떤 리소스(Resource)에 대해', '어떤 조건(Condition)에서', '무슨 행동(Action)을', '허용(Allow)할지 또는 거부(Deny)할지'를 명시적으로 정의합니다. 우리의 목표는 인터넷상의 모든 사용자(익명 사용자)가 우리 버킷의 모든 객체를 읽을 수 있도록(다운로드할 수 있도록) 허용하는 것입니다.

버킷 상세 화면에서 '권한' 탭으로 이동합니다.
'버킷 정책' 섹션에서 '편집' 버튼을 클릭합니다.
정책 편집기에 아래의 JSON 코드를 붙여넣습니다. your-bucket-name 부분은 실제 버킷 이름으로 반드시 변경해야 합니다.

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

버킷 정책 분석:

Version: 정책 언어의 버전을 명시합니다. 일반적으로 "2012-10-17"을 사용합니다.
Statement: 실제 정책 규칙들의 배열입니다.
Sid: (Statement ID) 이 규칙을 식별하기 위한 이름입니다. 원하는 대로 지정할 수 있습니다.
Effect: 이 규칙의 효과를 지정합니다. "Allow"(허용) 또는 "Deny"(거부)가 있습니다.
Principal: 정책의 영향을 받는 대상을 지정합니다. "*"는 '모든 사용자(익명 포함)'를 의미합니다.
Action: 허용하거나 거부할 작업을 지정합니다. "s3:GetObject"는 S3 객체를 읽는(다운로드하는) 권한입니다.
Resource: 정책이 적용될 자원을 지정합니다. "arn:aws:s3:::your-bucket-name/*"는 'your-bucket-name' 버킷 내부의 모든 객체(/*)를 의미합니다.

정책을 붙여넣고 '변경 사항 저장'을 클릭합니다. 이제 S3 버킷은 외부에서 파일을 읽어갈 수 있도록 준비되었습니다.

3.2 정적 웹사이트 호스팅 기능 활성화

이제 마지막으로 S3에게 이 버킷이 웹 서버처럼 동작해야 함을 알려주어야 합니다.

버킷 상세 화면에서 '속성' 탭으로 이동합니다.
페이지 맨 아래로 스크롤하여 '정적 웹 사이트 호스팅' 카드에서 '편집' 버튼을 클릭합니다.
'정적 웹 사이트 호스팅'을 '활성화'로 변경합니다.
인덱스 문서: 사용자가 디렉터리 경로(예: /)로 접근했을 때 보여줄 기본 파일의 이름을 입력합니다. 일반적으로 index.html입니다.
오류 문서: 사용자가 존재하지 않는 경로로 접근했을 때(404 Not Found 등) 보여줄 파일의 이름을 입력합니다. 준비해 둔 error.html을 입력합니다.
'변경 사항 저장'을 클릭합니다.

설정이 완료되면 '정적 웹 사이트 호스팅' 카드에 버킷 웹 사이트 엔드포인트가 표시됩니다. http://your-bucket-name.s3-website.ap-northeast-2.amazonaws.com과 같은 형식의 URL입니다. 이 URL을 복사하여 웹 브라우저 주소창에 붙여넣으면, 방금 업로드한 웹사이트가 성공적으로 나타나는 것을 확인할 수 있습니다! 존재하지 않는 주소(예: /non-existent-page.html)를 입력하면 error.html의 내용이 나타나는지도 확인해 보세요.

핵심 개념: 웹사이트 엔드포인트 vs. REST API 엔드포인트

S3 객체에 접근하는 엔드포인트는 두 종류가 있으며, 이 둘의 차이를 이해하는 것이 중요합니다.

REST API 엔드포인트: https://your-bucket-name.s3.ap-northeast-2.amazonaws.com/index.html 과 같은 형식입니다. 이는 S3의 API와 통신하기 위한 일반적인 엔드포인트로, 인덱스 문서나 오류 문서 기능을 지원하지 않습니다. 이 URL로 루트에 접근하면 파일 목록이 보이거나(권한에 따라) 에러가 발생합니다.
웹사이트 엔드포인트: http://your-bucket-name.s3-website.ap-northeast-2.amazonaws.com 과 같은 형식입니다. 이 엔드포인트는 웹 브라우저의 요청에 최적화되어 있으며, 위에서 설정한 인덱스 문서 및 오류 문서 기능을 처리해 줍니다. 따라서 정적 웹사이트를 호스팅할 때는 반드시 이 엔드포인트를 사용해야 합니다.

4장: 세상과 연결하기: Route 53으로 커스텀 도메인 연결

s3-website...로 시작하는 긴 URL은 전문성이 떨어져 보입니다. 이제 소유하고 있는 커스텀 도메인(예: example.com)을 S3 웹사이트에 연결해 보겠습니다. 이 과정에서는 AWS의 DNS(Domain Name System) 서비스인 Amazon Route 53을 사용합니다.

도메인을 아직 소유하고 있지 않다면 Route 53, GoDaddy, 가비아 등 다양한 도메인 등록 기관을 통해 구매할 수 있습니다. 이미 도메인을 가지고 있다면 Route 53을 해당 도메인의 DNS 서버로 사용하도록 네임서버를 변경하는 과정이 필요합니다.

4.1 Route 53 호스팅 영역(Hosted Zone) 설정

Route 53에서 도메인의 DNS 레코드를 관리하기 위해서는 먼저 '호스팅 영역'을 생성해야 합니다. 호스팅 영역은 특정 도메인에 대한 DNS 레코드의 컨테이너 역할을 합니다.

AWS 콘솔에서 'Route 53'으로 이동합니다.
왼쪽 메뉴에서 '호스팅 영역'을 선택하고 '호스팅 영역 생성'을 클릭합니다.
'도메인 이름'에 소유한 도메인(예: my-awesome-site.com)을 입력합니다.
'유형'은 '퍼블릭 호스팅 영역'으로 선택합니다.
'호스팅 영역 생성'을 클릭합니다.

생성이 완료되면 NS(네임서버) 레코드와 SOA(권한 시작) 레코드가 자동으로 생성됩니다. 만약 다른 곳에서 도메인을 구매했다면, NS 레코드에 표시된 4개의 네임서버 주소를 해당 도메인 등록 기관의 네임서버 설정에 입력해야 합니다.

4.2 도메인 연결의 핵심: ALIAS 레코드 생성

이제 Route 53에 "my-awesome-site.com으로 들어오는 요청을 아까 만든 S3 웹사이트 엔드포인트로 보내라"는 규칙을 추가해야 합니다. 이를 위해 레코드를 생성합니다.

여기서 중요한 개념이 등장합니다. 루트 도메인(my-awesome-site.com과 같이 'www'가 없는 도메인, Zone Apex라고도 함)은 DNS 규약상 CNAME 레코드를 가질 수 없습니다. CNAME은 다른 도메인 이름의 별칭을 만드는 것인데, 루트 도메인에는 NS나 SOA 같은 다른 중요한 레코드들이 이미 존재하기 때문입니다. 이 문제를 해결하기 위해 AWS는 ALIAS(별칭)라는 특별한 레코드 유형을 제공합니다.

ALIAS 레코드는 CNAME과 유사하게 동작하지만, 내부적으로는 대상 AWS 리소스(S3 웹사이트 엔드포인트, CloudFront 배포, ELB 등)의 IP 주소로 해석됩니다. 따라서 A 레코드처럼 루트 도메인에 설정할 수 있으면서도, 대상의 IP가 변경되어도 자동으로 추적하는 CNAME의 유연성을 가집니다.

생성한 호스팅 영역의 상세 페이지로 들어가 '레코드 생성'을 클릭합니다.
루트 도메인 (my-awesome-site.com) 설정:
- 레코드 이름: 비워 둡니다.
- 레코드 유형: 'A - IPv4 주소로 트래픽 라우팅'을 선택합니다.
- '별칭(Alias)' 토글을 활성화합니다.
- 트래픽 라우팅 대상 선택: 'S3 웹 사이트 엔드포인트에 대한 별칭'을 선택합니다.
- 리전 선택: S3 버킷을 생성한 리전(예: ap-northeast-2)을 선택합니다.
- S3 엔드포인트 선택: 드롭다운 목록에 나타나는 S3 웹사이트 엔드포인트 (s3-website.ap-northeast-2.amazonaws.com으로 시작하는 주소)를 선택합니다.
- '레코드 생성'을 클릭합니다.
'www' 서브도메인 (www.my-awesome-site.com) 설정 (선택 사항):
사용자가 'www'를 붙여서 접속해도 동일한 사이트로 연결되도록 설정하는 것이 좋습니다. 'www'는 서브도메인이므로 일반적인 CNAME을 사용할 수 있습니다.
- 다시 '레코드 생성'을 클릭합니다.
- 레코드 이름: www를 입력합니다.
- 레코드 유형: 'CNAME - 다른 도메인 이름 및 일부 AWS 리소스로 트래픽 라우팅'을 선택합니다.
- 값: 루트 도메인 이름(예: my-awesome-site.com)을 입력합니다. 이렇게 하면 www 주소는 루트 주소의 별칭이 됩니다.
- '레코드 생성'을 클릭합니다.

DNS 변경 사항이 전 세계로 전파되는 데는 몇 분에서 최대 48시간까지 걸릴 수 있지만, 보통은 수 분 내에 완료됩니다. 잠시 후 웹 브라우저에서 자신의 커스텀 도메인 주소로 접속했을 때 S3 웹사이트가 나타난다면 성공입니다!

5장: 성능과 보안의 날개를 달다: CloudFront 연동

지금까지의 설정만으로도 훌륭한 정적 웹사이트를 운영할 수 있습니다. 하지만 두 가지 치명적인 약점이 남아있습니다.

HTTP 전용: S3 웹사이트 엔드포인트는 HTTPS를 지원하지 않습니다. 요즘 웹 환경에서 HTTPS는 선택이 아닌 필수입니다. 브라우저는 HTTP 사이트를 '안전하지 않음'으로 표시하며, SEO에도 불이익이 있습니다.
지연 시간: 사용자가 S3 버킷이 있는 리전에서 멀리 떨어져 있을수록 웹사이트 로딩 속도는 느려집니다.

이 모든 문제를 한 번에 해결해 주는 서비스가 바로 Amazon CloudFront입니다. CloudFront는 전 세계 수백 개의 엣지 로케이션(Edge Location)에 웹사이트 콘텐츠의 복사본(캐시)을 저장해두는 CDN 서비스입니다. 사용자가 웹사이트에 접속하면, 가장 가까운 엣지 로케이션에서 콘텐츠를 전달받아 지연 시간을 최소화합니다.

5.1 CloudFront를 사용해야 하는 결정적 이유

무료 HTTPS/SSL: CloudFront는 AWS Certificate Manager(ACM)와 통합되어, 커스텀 도메인에 대한 무료 SSL/TLS 인증서를 손쉽게 발급하고 적용할 수 있습니다. 이를 통해 모든 트래픽을 암호화하여 보안을 강화할 수 있습니다.
글로벌 성능 향상: 한국의 사용자는 서울 엣지 로케이션에서, 미국의 사용자는 캘리포니아 엣지 로케이션에서 콘텐츠를 받게 되므로 전 세계 어디서든 빠른 로딩 속도를 경험할 수 있습니다.
강화된 보안 (OAC): Origin Access Control(OAC)라는 기능을 사용하면, S3 버킷에 대한 퍼블릭 액세스를 완전히 차단하고 오직 특정 CloudFront 배포만을 통해 접근하도록 설정할 수 있습니다. 이는 S3 버킷을 외부로부터 완벽하게 보호하는 가장 강력한 보안 구성입니다.
비용 절감 가능성: 대부분의 트래픽이 엣지 로케이션의 캐시에서 처리되므로 S3로의 데이터 전송 요청(GET 요청)이 줄어들어 S3 데이터 전송 요금을 절약할 수 있습니다.

5.2 CloudFront 배포(Distribution) 생성: 상세 가이드

이제 S3 버킷을 원본(Origin)으로 하는 CloudFront 배포를 생성해 보겠습니다.

SSL 인증서 발급 (선행 작업):
- AWS 콘솔에서 AWS Certificate Manager(ACM)로 이동합니다.
- 중요: CloudFront와 함께 사용할 인증서는 반드시 미국 동부(버지니아 북부) us-east-1 리전에서 생성해야 합니다. 다른 리전에서 생성한 인증서는 CloudFront 배포에 연결할 수 없습니다.
- '인증서 요청'을 클릭하고 '퍼블릭 인증서 요청'을 선택합니다.
- '도메인 이름'에 웹사이트의 루트 도메인(my-awesome-site.com)과 www 서브도메인(*.my-awesome-site.com 또는 www.my-awesome-site.com)을 모두 추가합니다.
- 검증 방법은 'DNS 검증'을 선택합니다. Route 53을 사용하고 있다면, ACM이 자동으로 필요한 CNAME 레코드를 생성해주므로 검증이 매우 간편합니다.
- 요청이 완료되고 상태가 '발급됨'으로 변경될 때까지 기다립니다.

CloudFront 배포 생성:
- AWS 콘솔에서 'CloudFront'로 이동하여 '배포 생성'을 클릭합니다.
- 원본 도메인: 드롭다운 목록에서 이전에 생성한 S3 버킷을 선택합니다. 주의: 목록에는 your-bucket-name.s3.ap-northeast-2.amazonaws.com과 같은 REST API 엔드포인트가 표시됩니다. 이것을 선택하는 것이 맞습니다. (웹사이트 엔드포인트가 아닙니다.)
- 원본 액세스: 'Origin access control settings(recommended)'를 선택합니다. 그리고 'Control setting 생성' 버튼을 클릭하여 새로운 OAC 설정을 만듭니다. 기본 이름으로 생성하면 됩니다.
- 생성 후 'Copy policy' 버튼을 클릭하여 S3 버킷에 적용할 정책을 복사하고, 'Go to S3 bucket permissions' 링크를 통해 S3 버킷의 권한 페이지로 이동하여 기존 정책을 이 내용으로 대체합니다. 이 새로운 정책은 오직 이 CloudFront 배포에게만 s3:GetObject 권한을 부여합니다. 이제 S3 버킷의 '모든 퍼블릭 액세스 차단' 설정을 다시 활성화하여 버킷을 비공개로 만듭니다.
- 뷰어 프로토콜 정책: 'Redirect HTTP to HTTPS'를 선택하여 모든 사용자가 안전한 HTTPS 연결을 사용하도록 강제합니다.
- 캐시 키 및 원본 요청: 'Cache policy and origin request policy(recommended)'에서 'CachingOptimized'와 'Managed-CORS-S3Origin'를 기본으로 사용합니다.
- 설정(Settings):
  - 가격 분류: '모든 엣지 로케이션 사용(최고 성능)'을 선택하거나, 특정 지역에만 서비스를 제공한다면 비용 절감을 위해 다른 옵션을 선택할 수 있습니다.
  - 대체 도메인 이름(CNAME): '항목 추가'를 눌러 커스텀 도메인(my-awesome-site.com과 www.my-awesome-site.com)을 모두 입력합니다.
  - 사용자 정의 SSL 인증서: 방금 us-east-1 리전에서 발급받은 ACM 인증서를 선택합니다.
  - 기본값 루트 객체: index.html을 입력합니다.
- 모든 설정이 완료되면 '배포 생성'을 클릭합니다. 배포가 전 세계 엣지 로케이션에 전파되는 데 5~15분 정도 소요될 수 있습니다.

5.3 마지막 단계: Route 53 레코드 업데이트

CloudFront 배포가 완료되면, 이제 사용자의 도메인 요청을 S3가 아닌 CloudFront로 보내도록 Route 53 설정을 변경해야 합니다.

Route 53의 해당 호스팅 영역으로 돌아갑니다.
이전에 생성했던 루트 도메인(my-awesome-site.com)의 A(ALIAS) 레코드를 선택하고 '레코드 편집'을 클릭합니다.
트래픽 라우팅 대상 선택: 기존의 'S3 웹 사이트 엔드포인트에 대한 별칭' 대신 'CloudFront 배포에 대한 별칭'을 선택합니다.
드롭다운 목록에서 방금 생성한 CloudFront 배포(d1234abcd.cloudfront.net과 같은 주소)를 선택합니다.
'변경 사항 저장'을 클릭합니다.
'www' 서브도메인의 CNAME 레코드도 마찬가지로 편집하여, 값이 루트 도메인(my-awesome-site.com)을 가리키도록 하거나, 직접 CloudFront 배포 도메인을 가리키도록 설정할 수 있습니다.

모든 설정이 완료되고 DNS가 전파된 후, https://my-awesome-site.com으로 접속해 보세요. 주소창에 자물쇠 아이콘과 함께 안전한 HTTPS 연결이 표시되고, 웹사이트는 전 세계 엣지 로케이션을 통해 그 어느 때보다 빠르게 로딩될 것입니다. 이로써 비용 효율적이고, 확장 가능하며, 빠르고 안전한 현대적인 정적 웹사이트 아키텍처가 완성되었습니다.

Thursday, July 20, 2023

실전 AWS: S3 정적 호스팅부터 CloudFront CDN 최적화까지