AWS Route 53 ALIAS에서 S3 버킷이 보이지 않는 문제

26 April 2019

Update: 16 November 2025

Amazon Web Services(AWS)를 활용하여 서버 없이 정적 웹사이트를 구축하는 것은 현대 웹 개발에서 매우 효율적이고 비용 효과적인 표준 아키텍처로 자리 잡았습니다. AWS의 핵심 스토리지 서비스인 S3(Simple Storage Service)에 HTML, CSS, JavaScript와 같은 정적 자산을 업로드하고, DNS 서비스인 Route 53을 통해 개인 도메인을 연결하면, 단 몇 분 만에 글로벌 서비스를 위한 웹사이트 배포가 완료됩니다. 이 과정은 대부분의 단계가 직관적이지만, 많은 개발자들이 거의 마지막 단계에서 동일한 미스터리와 마주하게 됩니다. 바로 Route 53에서 '별칭(ALIAS)' 레코드를 설정하려 할 때, 방금 전까지 분명히 존재했던 내 S3 버킷이 목록에서 감쪽같이 사라져 보이지 않는 문제입니다.

이 문제는 AWS를 처음 접하는 개발자는 물론, 수많은 AWS 서비스를 다뤄본 숙련된 개발자에게도 적잖은 당혹감을 안겨줍니다. 모든 설정이 완벽하다고 생각한 순간에 발생하는 이 현상은, AWS 서비스 간의 상호작용에 대한 깊은 이해가 부족할 때 발생하는 대표적인 사례입니다. 원인을 모른다면 몇 시간이고 AWS 콘솔의 여러 메뉴를 전전하며 시간을 허비하게 될 수 있습니다. 이 글에서는 단순한 해결책 나열을 넘어, 풀스택 개발자의 시각에서 해당 문제가 발생하는 근본적인 원인을 파헤치고, 체계적인 단계별 점검 사항과 명확한 해결책을 제시합니다. 더 나아가, 왜 AWS가 이러한 방식으로 설계했는지 그 내부 동작 원리까지 깊이 있게 탐구해 보겠습니다. 이 글을 끝까지 정독하신다면, 다시는 사라진 S3 버킷을 찾아 헤매는 일은 없을 것이라고 확신합니다.

1. 근본 원인 분석: Route 53 별칭(ALIAS) 레코드의 숨겨진 규칙

Route 53 설정 화면에서 S3 버킷이 보이지 않는 문제의 99%는 단 하나의 핵심 원인, 바로 'S3 버킷 이름'과 '연결하려는 도메인 이름'의 불일치에서 기인합니다. 이것은 AWS가 권장하는 '가이드라인' 수준이 아니라, ALIAS 레코드가 AWS 인프라 내부에서 다른 서비스 리소스를 식별하고 연결하는 방식에 깊게 뿌리내린 '기술적 제약'입니다. 이 원리를 제대로 이해하기 위해서는 먼저 전통적인 DNS의 CNAME 레코드와 AWS가 제공하는 ALIAS 레코드의 본질적인 차이를 알아야 합니다.

CNAME과 ALIAS 레코드: 무엇이 다른가?

전통적인 DNS 환경에서 특정 도메인을 다른 도메인으로 연결(포인팅)할 때 가장 흔하게 사용되는 레코드는 CNAME(Canonical Name)입니다. CNAME은 `blog.example.com`이라는 도메인 주소를 `gh-pages.github.io`와 같은 다른 도메인 주소로 매핑하는, 일종의 '별명'을 붙여주는 역할을 합니다. 사용자가 `blog.example.com`에 접속하면 DNS 시스템은 "아, 이 주소의 진짜 이름은 `gh-pages.github.io`이니, 그쪽으로 다시 물어보세요"라고 응답하는 방식입니다.

하지만 CNAME에는 치명적인 제약이 있습니다. 바로 도메인 이름의 가장 최상위, 즉 'Zone Apex' 또는 '루트 도메인(Root Domain)'에는 사용할 수 없다는 점입니다. 예를 들어 `www.example.com`이나 `shop.example.com`과 같은 서브도메인에는 CNAME을 설정할 수 있지만, `example.com` 그 자체에는 CNAME 레코드를 설정할 수 없습니다. 이는 DNS 명세(RFC 1034)에 따른 것으로, Zone Apex에는 NS(Name Server) 레코드나 SOA(Start of Authority) 레코드와 같은 다른 중요한 레코드들이 반드시 존재해야 하므로, CNAME이 다른 모든 레코드를 덮어쓰는 것을 허용하지 않기 때문입니다.

이 문제를 해결하고 AWS 생태계 내에서 더 유연하고 강력한 라우팅 기능을 제공하기 위해 AWS가 독자적으로 개발한 기능이 바로 ALIAS 레코드입니다. ALIAS 레코드는 겉보기에는 CNAME과 유사하게 동작하지만, 그 내부 메커니즘은 완전히 다릅니다. ALIAS 레코드는 DNS 프로토콜 수준의 리디렉션이 아니라, Route 53 서비스가 AWS 인프라 내부에서 직접 AWS 리소스(예: Elastic Load Balancer, CloudFront 배포, API Gateway, 그리고 우리의 목표인 S3 웹사이트 엔드포인트)의 실제 IP 주소를 조회하여 A 레코드(IPv4)나 AAAA 레코드(IPv6)처럼 응답합니다. 마치 처음부터 IP 주소를 가리키는 것처럼 동작하기 때문에 CNAME의 Zone Apex 제약에서 자유로우며, 루트 도메인인 `example.com`에도 자유롭게 설정할 수 있습니다.

핵심 요약: ALIAS 레코드는 CNAME과 달리 루트 도메인(example.com)에 설정할 수 있으며, 대상 AWS 리소스의 IP 주소가 변경되어도 자동으로 추적하여 반영해주는 스마트한 AWS 전용 기능입니다.

특징	CNAME 레코드	ALIAS 레코드 (AWS Route 53)
루트 도메인(Zone Apex) 사용	불가능 (예: `example.com`)	가능
대상 리소스	다른 도메인 이름 (예: `another-domain.com`)	AWS 리소스 (ELB, CloudFront, S3, API Gateway 등)
동작 방식	DNS 수준의 별칭. 클라이언트는 2번의 DNS 조회를 수행할 수 있음.	AWS 내부의 IP 주소 직접 조회. 클라이언트에게는 A 레코드처럼 보임.
비용	DNS 쿼리 비용 발생	AWS 리소스를 가리키는 ALIAS 쿼리는 무료
표준	표준 DNS 레코드 타입	AWS 고유 기능

이름이 모든 것을 결정한다: Route 53의 식별 메커니즘

바로 이 ALIAS 레코드의 동작 방식 때문에 'S3 버킷 이름'이 절대적으로 중요해집니다. Route 53의 입장에서 생각해보겠습니다. 사용자가 `example.com`이라는 호스팅 영역에서 ALIAS 레코드를 생성하며 대상을 'S3 웹사이트 엔드포인트'로 지정했습니다. 이 순간 Route 53은 AWS의 방대한 인프라 내에서 수십억 개의 S3 버킷 중 `example.com` 도메인을 위해 준비된 '단 하나의' 웹사이트용 버킷을 찾아내야 합니다.

이 식별 과정에서 Route 53이 사용하는 유일하고 가장 명확한 기준이 바로 'S3 버킷 이름과 도메인 이름의 완전한 일치'입니다. 즉, Route 53은 다음과 같은 논리적 필터링을 수행합니다:

해당 AWS 계정 내의 모든 S3 버킷을 스캔한다.
그중에서 버킷 이름이 현재 설정하려는 레코드 이름(예: `example.com` 또는 `www.example.com`)과 정확히 일치하는(exact match) 버킷만 후보로 남긴다.
후보로 남은 버킷 중에서 '정적 웹사이트 호스팅' 속성이 '활성화(Enabled)'된 버킷만을 최종 목록에 표시한다.

따라서 만약 여러분의 도메인이 `my-cool-project.com`인데, S3 버킷을 `my-cool-project-bucket`이나 `s3-for-my-project`와 같이 조금이라도 다른 이름으로 생성했다면, Route 53은 2번 단계에서 해당 버킷을 필터링하여 제외해 버립니다. Route 53 입장에서는 그 버킷이 `my-cool-project.com` 도메인을 위한 것이라고 판단할 근거가 전혀 없기 때문입니다. 이것이 바로 여러분이 ALIAS 대상 목록에서 자신의 버킷을 찾을 수 없는 근본적인 이유입니다.

정상 사례 (O): 도메인이 `awesomedev.io`라면, S3 버킷 이름은 반드시 `awesomedev.io`여야 합니다.
오류 사례 (X): 도메인이 `awesomedev.io`인데, S3 버킷 이름이 `awesomedev-io` 또는 `my-awesomedev-site`인 경우, Route 53 ALIAS 목록에 절대 나타나지 않습니다.

이 핵심 원리를 이해했다면, 이제 문제 해결은 절반 이상 끝난 셈입니다. 이제 이 원리를 바탕으로 실제 AWS 콘솔에서 어떤 부분들을 점검하고 수정해야 하는지 구체적인 단계로 넘어가 보겠습니다.

2. 실전 해결 가이드: 사라진 S3 버킷을 찾는 단계별 체크리스트

S3 버킷이 보이지 않는 문제는 대개 여러 설정이 복합적으로 얽혀있을 때 발생합니다. 아래의 체크리스트를 순서대로 하나씩, 꼼꼼하게 점검하며 따라오시면 문제를 체계적으로 진단하고 해결할 수 있습니다.

1단계: S3 버킷 이름 - 되돌릴 수 없는 첫 단추

가장 먼저, 그리고 가장 중요하게 확인해야 할 부분입니다. 이미 생성한 S3 버킷의 이름이 연결하려는 도메인과 100% 정확하게 일치하는지 확인하세요.

AWS Management Console에 로그인하여 S3 서비스로 이동합니다.
생성된 버킷 목록을 주의 깊게 살펴봅니다.
- 루트 도메인 example.com을 연결하고 싶다면, 이름이 정확히 example.com인 버킷이 있는지 확인합니다. 오타나 하이픈(-) 같은 불필요한 문자가 없는지 다시 한번 확인하세요.
- 서브도메인 www.example.com을 연결하고 싶다면, 이름이 정확히 www.example.com인 버킷이 별도로 있어야 합니다.
만약 이름이 다르다면, 안타깝게도 S3 버킷의 이름은 생성된 이후에는 절대로 변경할 수 없습니다. 이것은 S3의 전역적인 고유성 정책 때문입니다. 따라서 기존 버킷의 데이터를 백업한 후, 해당 버킷을 삭제하고 올바른 이름으로 새 버킷을 생성하는 것이 유일한 해결책입니다.
매우 중요: 버킷을 삭제하면 그 안에 저장된 모든 객체(파일)가 영구적으로 사라집니다. 반드시 중요한 파일들을 로컬 PC나 다른 임시 버킷으로 백업하세요. AWS CLI를 사용하면 이 과정을 매우 효율적으로 처리할 수 있습니다.

로컬 PC에 `backup` 폴더를 만들고 아래 명령어를 터미널에서 실행하면 기존 버킷의 모든 내용을 해당 폴더로 동기화(다운로드)할 수 있습니다.
```
# aws s3 sync s3://[잘못된-이름의-버킷] ./backup
aws s3 sync s3://my-website-bucket ./backup
```
새 버킷을 생성한 후에는 반대로 로컬의 백업 데이터를 새 버킷으로 업로드합니다.
```
# aws s3 sync ./backup s3://[올바른-이름의-버킷]
aws s3 sync ./backup s3://example.com
```
올바른 이름으로 새 버킷을 생성할 때, '버킷 이름' 필드에 연결할 도메인 주소(예: your-domain.com)를 오타 없이 정확하게 입력합니다. AWS 리전은 웹사이트의 주 사용자층과 지리적으로 가장 가까운 곳을 선택하는 것이 지연 시간(latency) 감소에 유리합니다.

이 첫 단계를 성공적으로 마쳤다면, 문제의 가장 큰 원인을 해결한 것입니다. 하지만 아직 안심하기는 이릅니다. 버킷 이름 외에도 Route 53이 버킷을 '웹사이트'로 인식하기 위한 몇 가지 필수 설정이 더 남아있습니다.

2단계: 정적 웹사이트 호스팅 활성화 - S3를 웹 서버로 변신시키기

S3 버킷은 기본적으로 다목적 객체 스토리지, 즉 단순한 파일 저장소입니다. 이 버킷을 HTTP 요청에 응답하는 웹 서버처럼 동작하게 만들려면 '정적 웹사이트 호스팅' 옵션을 명시적으로 활성화해야 합니다. 이 설정이 꺼져 있다면 Route 53은 해당 버킷을 웹사이트 엔드포인트로 간주하지 않고 단순 스토리지로 취급하여 ALIAS 대상 목록에서 제외합니다.

이름이 올바른 S3 버킷(예: example.com)을 클릭하여 세부 정보 페이지로 들어갑니다.
상단의 여러 탭 중에서 [속성(Properties)] 탭을 선택합니다.
페이지를 맨 아래까지 스크롤하여 [정적 웹 사이트 호스팅(Static website hosting)] 섹션을 찾고, 우측의 [편집(Edit)] 버튼을 클릭합니다.
기본적으로 '비활성화(Disable)'로 설정된 상태를 '활성화(Enable)'로 변경합니다.
[호스팅 유형(Hosting type)]에서 '정적 웹 사이트 호스팅(Host a static website)'을 선택합니다.
[인덱스 문서(Index document)] 필드에 웹사이트의 진입점 역할을 하는 파일 이름을 입력합니다. 거의 모든 경우 `index.html`이 됩니다. 사용자가 도메인의 루트 경로(http://example.com/)에 접속했을 때 기본적으로 보여줄 파일입니다.
[오류 문서(Error document)] 필드에는 사용자가 존재하지 않는 경로(예: http://example.com/non-existent-page)에 접근했을 때 보여줄 404 오류 페이지 파일 이름을 입력합니다. 예를 들어 `error.html`이나 `404.html`을 지정할 수 있습니다. 이 설정은 선택 사항이지만, 사용자 경험을 크게 향상시키므로 설정하는 것을 강력히 권장합니다.
[변경 사항 저장(Save changes)]을 클릭합니다.

설정을 저장하고 나면, '정적 웹 사이트 호스팅' 섹션에 해당 버킷의 고유한 웹사이트 엔드포인트(Website endpoint) 주소가 생성된 것을 확인할 수 있습니다. 주소는 보통 http://[버킷이름].s3-website.[리전].amazonaws.com 형태입니다. 이 엔드포인트 주소를 클릭했을 때, 업로드한 `index.html` 파일이 정상적으로 보인다면 호스팅 설정은 성공적으로 완료된 것입니다. 만약 "403 Forbidden"이라는 오류 메시지가 나타난다면, 아직 외부 접근 권한이 없다는 의미이므로 다음 3단계를 이어서 진행해야 합니다.

3단계: 권한 설정 - 세상에 웹사이트 공개하기

AWS는 '보안 우선' 원칙에 따라, 새로 생성되는 모든 S3 버킷의 모든 퍼블릭 액세스를 기본적으로 차단합니다. 웹사이트는 인터넷을 통해 불특정 다수의 대중(Public)에게 공개되어야 하므로, 이 보안 장치를 해제하고 방문자들이 파일(객체)에 접근할 수 있도록 권한을 명시적으로 부여해야 합니다.

3-1. 모든 퍼블릭 액세스 차단 해제: 굳게 닫힌 대문 열기

S3 버킷 세부 정보 페이지에서 [권한(Permissions)] 탭으로 이동합니다.
[퍼블릭 액세스 차단(버킷 설정)(Block public access (bucket settings))] 섹션을 찾고 [편집(Edit)] 버튼을 클릭합니다.
'모든 퍼블릭 액세스 차단(Block all public access)' 체크박스의 체크를 해제합니다. 이 체크박스를 해제하면 아래 4개의 세부 항목도 함께 해제됩니다.
"이 변경으로 인해 이 버킷과 그 안의 객체가 퍼블릭 상태가 될 수 있음을 확인합니다."라는 경고 메시지가 나타나면, 해당 확인란에 체크합니다. 이는 이 작업의 중요성을 다시 한번 인지시키는 안전장치입니다.
[변경 사항 저장(Save changes)]을 클릭합니다. 이제 버킷 자체는 퍼블릭 상태가 될 준비가 되었지만, 아직 버킷 내부의 파일들에 대한 개별적인 접근 권한은 부여되지 않은 상태입니다. 이 권한은 버킷 정책을 통해 설정합니다.

3-2. 버킷 정책(Bucket Policy) 작성: 방문객에게 열람 권한 부여

버킷 정책은 JSON(JavaScript Object Notation) 형식을 사용하여, '누가(Principal)', '어떤 리소스(Resource)에 대해', '어떤 작업(Action)을', '허용(Allow) 또는 거부(Deny)할지'를 정의하는 강력하고 세분화된 권한 제어 규칙입니다. 정적 웹사이트를 위해서는, 인터넷상의 모든 익명 사용자("Principal": "*")가 버킷 안의 모든 객체(/*)를 읽어갈 수 있도록("Action": "s3:GetObject") 허용하는 정책이 필요합니다.

같은 [권한(Permissions)] 탭에서 [버킷 정책(Bucket policy)] 섹션을 찾아 [편집(Edit)]을 클릭합니다.

아래의 JSON 정책을 복사하여 정책 편집기에 그대로 붙여넣습니다.

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

위 정책에서 가장 중요한 부분은 `Resource` 값입니다. `[YOUR-BUCKET-NAME]` 부분을 자신의 실제 버킷 이름(예: example.com)으로 반드시 변경해야 합니다. 이 ARN(Amazon Resource Name)은 AWS 내의 모든 리소스를 고유하게 식별하는 주소이며, `/*`는 '버킷 안의 모든 객체(파일)'를 의미하는 와일드카드입니다.
[변경 사항 저장(Save changes)]을 클릭합니다. 정책에 문법 오류가 없다면 성공적으로 저장되고, [권한] 탭 상단에 "공개적으로 액세스 가능(Publicly accessible)"이라는 경고성 빨간색 태그가 나타납니다. 이는 설정이 의도대로 잘 적용되었음을 의미합니다.

이제 모든 준비가 끝났습니다. 다시 한번 S3 웹사이트 엔드포인트 주소(http://[버킷이름].s3-website.[리전].amazonaws.com)로 접속해보세요. 이전의 403 Forbidden 오류가 마법처럼 사라지고, 여러분이 업로드한 웹페이지가 정상적으로 표시될 것입니다. 이 모든 단계가 완료되었다면, S3 버킷은 Route 53 ALIAS 레코드의 대상으로 선택될 모든 자격을 갖춘 상태입니다.

3. Route 53 설정: 마침내 버킷을 찾다

이제 대망의 마지막 단계입니다. 모든 장애물을 제거했으니, Route 53에서 S3 버킷이 마법처럼 목록에 나타나는 것을 직접 확인해볼 차례입니다.

AWS Management Console에서 Route 53 서비스로 이동합니다.
왼쪽 탐색 창에서 [호스팅 영역(Hosted zones)]을 클릭하고, 연결하려는 도메인의 호스팅 영역(예: example.com)의 이름을 클릭합니다.
호스팅 영역 세부 정보 페이지에서 [레코드 생성(Create record)] 버튼을 클릭합니다.
레코드 생성 양식을 아래 가이드에 따라 정확하게 입력합니다.
- 레코드 이름(Record name): 루트 도메인(example.com)에 직접 연결할 것이므로 이 필드를 비워 둡니다. 만약 www.example.com과 같은 서브도메인에 연결한다면 여기에 `www`를 입력하면 됩니다.
- 레코드 유형(Record type): A - IPv4 주소 및 일부 AWS 리소스로 트래픽 라우팅을 선택합니다. ALIAS 레코드는 내부적으로 A 레코드 또는 AAAA 레코드처럼 동작하므로 이 유형을 선택합니다.
- 별칭(Alias) 토글 스위치: 이 스위치를 클릭하여 활성화(파란색)합니다. 이 스위치를 켜야만 AWS 리소스를 대상으로 지정할 수 있습니다.
- 트래픽 라우팅 대상(Route traffic to):
  1. 첫 번째 드롭다운 메뉴에서 'S3 웹 사이트 엔드포인트에 대한 별칭(Alias to S3 website endpoint)'을 선택합니다.
  2. 두 번째 드롭다운 메뉴(리전 선택)에서 이전에 S3 버킷을 생성했던 동일한 리전을 선택합니다. (예: ap-northeast-2 (Asia Pacific (Seoul))). 리전이 다르면 버킷이 보이지 않습니다.
  3. 세 번째 필드를 클릭하면... 드디어! 이전에 그토록 찾아 헤맸던 S3 웹사이트 엔드포인트(s3-website.ap-northeast-2.amazonaws.com)가 목록에 나타날 것입니다. 이 항목을 선택합니다.
- 라우팅 정책(Routing policy): 대부분의 경우 '단순 라우팅(Simple routing)'을 그대로 사용합니다.
- [레코드 생성(Create records)] 버튼을 눌러 모든 설정을 완료합니다.

DNS 변경 사항이 전 세계의 DNS 서버로 전파되는 데에는 기술적으로 몇 분에서 최대 48시간까지 걸릴 수 있지만, AWS Route 53은 일반적으로 매우 빠르게(수십 초에서 몇 분 내로) 적용됩니다. 잠시 후 웹 브라우저 주소창에 자신의 도메인(http://example.com)을 입력하여 접속해보세요. S3에 업로드한 멋진 웹사이트가 여러분을 맞이할 것입니다.

4. 프로덕션 환경을 위한 고급 설정

기본적인 웹사이트 배포에 성공했다면, 여기서 멈추지 말고 실제 프로덕션 환경에 걸맞게 사용자 경험과 보안을 한 단계 더 끌어올릴 수 있습니다.

'www' 서브도메인 처리 전략: 모든 방문자를 한 곳으로

사용자들은 습관적으로 `example.com`으로 접속하기도 하고, `www.example.com`으로 접속하기도 합니다. 두 주소 중 어느 쪽으로 들어와도 동일한 사이트를 보여주는 것은 필수적입니다. 더 나아가, SEO(검색 엔진 최적화) 관점에서는 하나의 주소(보통 `www`가 없는 루트 도메인)를 '대표(Canonical)' 주소로 정하고, 다른 주소는 대표 주소로 301 리디렉션(영구 이동) 시키는 것이 표준적인 방법입니다.

S3 콘솔에서 새 버킷을 생성합니다. 이번에는 버킷 이름을 www.example.com으로 지정합니다.
이 `www` 버킷에는 파일을 전혀 업로드할 필요가 없습니다. 이 버킷의 유일한 역할은 리디렉션입니다.
생성된 `www.example.com` 버킷의 [속성(Properties)] > [정적 웹 사이트 호스팅(Static website hosting)]으로 이동하여 [편집]을 클릭합니다.
'활성화(Enable)'를 선택하고, [호스팅 유형]에서 이번에는 '객체 요청 리디렉션(Redirect requests for an object)'을 선택합니다.
[호스트 이름(Host name)] 필드에 리디렉션할 최종 목적지인 루트 도메인, 즉 example.com을 입력합니다.
[프로토콜(Protocol)]은 `http`로 설정하고 변경 사항을 저장합니다.
이제 Route 53으로 돌아가, `www.example.com`에 대한 ALIAS 레코드를 하나 더 생성합니다. 과정은 위 3단계와 거의 동일합니다. '레코드 이름'에 'www'를 입력하고 '트래픽 라우팅 대상'에서 방금 생성한 `www` 리디렉션 버킷의 S3 웹사이트 엔드포인트를 선택하면 됩니다.

이 설정이 완료되면, 사용자가 브라우저에 `www.example.com`을 입력했을 때, S3는 브라우저에게 "이 주소는 영구적으로 `http://example.com`으로 이사했으니, 그쪽으로 다시 접속하세요"라는 301 응답을 보내주게 됩니다. 이를 통해 트래픽을 하나로 모으고 검색 엔진의 혼란을 방지할 수 있습니다.

HTTPS 적용: Amazon CloudFront로 보안과 속도를 동시에

지금까지의 모든 설정은 암호화되지 않은 HTTP 프로토콜로만 통신합니다. 현대 웹 환경에서 사용자 데이터 보호, 신뢰도 확보, 그리고 SEO 순위 향상을 위해 HTTPS 적용은 선택이 아닌 필수입니다. 하지만 S3 정적 웹사이트 호스팅 기능 자체는 커스텀 도메인에 대한 HTTPS를 직접 지원하지 않습니다.

S3 정적 웹사이트에 HTTPS를 적용하는 가장 표준적이고 강력한 방법은 AWS의 글로벌 CDN(Content Delivery Network) 서비스인 Amazon CloudFront를 도입하는 것입니다.

CloudFront란? 전 세계 주요 도시에 위치한 수백 개의 '엣지 로케이션(Edge Location)'에 웹사이트의 콘텐츠(HTML, CSS, 이미지 등)를 미리 복사(캐싱)해두고, 사용자가 접속했을 때 가장 가까운 엣지 로케이션에서 콘텐츠를 전송하여 로딩 속도를 획기적으로 개선하는 서비스입니다. HTTPS 적용은 CloudFront의 수많은 기능 중 하나일 뿐입니다.

AWS Certificate Manager(ACM) 서비스로 이동하여 도메인(example.com 및 *.example.com)에 대한 무료 공인 SSL/TLS 인증서를 발급받습니다. 매우 중요한 점은, CloudFront와 연동할 인증서는 반드시 '미국 동부 (버지니아 북부) us-east-1' 리전에서 생성해야 한다는 것입니다. 이는 CloudFront가 글로벌 서비스이기 때문입니다.
CloudFront 서비스로 이동하여 새 '배포(Distribution)'를 생성합니다.
[원본 도메인(Origin domain)] 설정 시, 드롭다운 목록에서 S3 버킷을 선택하지 말고, S3 버킷의 '웹사이트 엔드포인트' 주소(example.com.s3-website.ap-northeast-2.amazonaws.com)를 직접 복사하여 붙여넣습니다.
전문가 팁: 드롭다운에서 제공하는 S3 버킷 ARN(example.com.s3.amazonaws.com)은 REST API 엔드포인트입니다. 이 주소를 사용하면 S3가 웹 서버가 아닌 단순 스토리지로 동작하여 인덱스 문서 자동 로딩이나 리디렉션 규칙이 제대로 작동하지 않는 문제가 발생할 수 있습니다. 반드시 웹사이트 엔드포인트를 사용해야 합니다.
[뷰어(Viewer)] > [뷰어 프로토콜 정책(Viewer protocol policy)]에서 'Redirect HTTP to HTTPS'를 선택하여 모든 HTTP 요청을 HTTPS로 자동 리디렉션하도록 설정합니다.
[대체 도메인 이름(CNAMEs)(Alternate domain names (CNAMEs))] 필드에 example.com과 www.example.com을 추가합니다.
[사용자 정의 SSL 인증서(Custom SSL certificate)] 섹션에서 1단계에서 ACM으로 발급받은 인증서를 선택합니다.
배포 생성을 완료합니다. 배포가 완료되기까지 10~20분 정도 소요될 수 있습니다. 완료되면 CloudFront는 d12345abcdef.cloudfront.net과 같은 고유한 배포 도메인 이름을 제공합니다.
이제 Route 53으로 돌아가, 이전에 S3 버킷을 가리키도록 설정했던 A 레코드 두 개(`example.com`과 `www.example.com`)를 모두 수정합니다. '트래픽 라우팅 대상'을 'S3 엔드포인트에 대한 별칭' 대신 'CloudFront 배포에 대한 별칭(Alias to CloudFront distribution)'으로 변경하고, 새로 생성된 CloudFront 배포를 선택합니다.

이제 모든 설정이 완료되었습니다. 사용자가 여러분의 도메인에 접속하면, Route 53은 사용자를 CloudFront로 안내하고, CloudFront는 안전한 HTTPS 연결을 통해 가장 가까운 엣지 로케이션에서 캐시된 콘텐츠를 빛의 속도로 전송해 줄 것입니다. 이로써 여러분은 보안, 속도, 안정성을 모두 갖춘 전문가 수준의 정적 웹사이트 인프라를 구축하게 된 것입니다.

결론: 체계적인 점검이 모든 문제의 열쇠다

AWS Route 53에서 S3 버킷이 보이지 않는 문제는 처음 겪으면 매우 당황스럽고 복잡하게 느껴질 수 있습니다. 하지만 오늘 우리가 함께 살펴본 것처럼, 그 근본 원리는 AWS 서비스 간의 명확한 약속, 즉 '이름 규칙'에 기반하고 있습니다. 이 문제는 AWS의 결함이 아니라, 오히려 수많은 리소스를 효율적으로 관리하고 연결하기 위한 논리적인 설계의 결과물입니다.

오늘의 여정을 통해 얻은 핵심적인 교훈을 다시 한번 요약하며 마무리하겠습니다.

가장 중요한 원칙: S3 버킷 이름(example.com)은 Route 53에서 연결할 도메인 이름(example.com)과 토씨 하나 틀리지 않고, 정확하게 일치해야 합니다. 이것이 ALIAS 레코드가 버킷을 식별하는 유일한 방법입니다.
S3 버킷의 3대 필수 설정: 버킷 이름 외에도 (1)정적 웹사이트 호스팅 활성화, (2)퍼블릭 액세스 차단 해제, 그리고 (3)익명 사용자의 `s3:GetObject`을 허용하는 버킷 정책까지 모두 완벽하게 설정되어야 S3 버킷이 '웹사이트'로서의 자격을 갖추게 됩니다.
Route 53 설정의 디테일: ALIAS 레코드 생성 시, 올바른 레코드 유형(A)을 선택하고, 무엇보다 S3 버킷이 위치한 리전을 정확하게 지정해야만 해당 리전 내에서 조건에 맞는 버킷을 찾아 목록에 보여줄 수 있습니다.
프로덕션으로의 도약: 실 서비스에서는 CloudFront를 도입하여 HTTPS를 적용하고 글로벌 콘텐츠 전송 속도를 높이는 것이 현대 웹의 표준 아키텍처라는 점을 기억해야 합니다.

이 네 가지 핵심 포인트를 기억하고, 앞으로 비슷한 문제가 발생했을 때 오늘 다룬 단계별 체크리스트에 따라 차분히 점검한다면, S3와 Route 53을 연동하는 과정은 더 이상 두려움의 대상이 아닌, 즐거운 인프라 구축 과정이 될 것입니다. 서버리스 정적 웹 호스팅은 AWS 클라우드의 무한한 가능성을 체험하는 가장 훌륭한 첫걸음입니다. 이 가이드가 여러분의 성공적인 AWS 여정에 든든한 디딤돌이 되기를 바랍니다.