Route53 / S3 Bucket
AWS Route 53
AWS 에서 제공하는 클라우드 Domain 이름 DNS 웹 서비스. Domain Name을 실제 서버나 서비스(IP 주소 등)와 연결해주는 서비스이다.
주요 기능 및 특징
1) Domian Registration(등록)과 관리
AWS Console 내에서 Domain을 직접 구매 및 등록 할 수 있으며 해당 도메인은 Route 53에서 연동하여 관리할 수 있다.
2) DNS Hosting
Route 53은 DNS Hosting 을 제공하므로 도메인에 대한 레코드 (A, MX, TXT, CNAME) 등을 등록 및 관리할 수 있다.
ex) 예를 들어, http://www.example.com을 12.34.56.78 IP로 연결하는 A 레코드, 또는 blog.example.com을 다른 도메인으로 연결하는 CNAME 레코드 등을 손쉽게 설정할 수 있다
Record A 만 설정했을 때 Route Domain (example.com → www 없이 접속)도 연결될까??
Record A의 www만 설정했다면 example.com 으로 www 없이 접속하면 연결이 되지 않는다. 이런 경우에는
Route Domain(example.com)도 www.example.com 과 같은 instance로 연결할려면 별도의 A record를 추가해야한다.
3) Traffic Routing Option
Simple Routing: 가장 기본적인 라우팅으로, 특정 레코드에 해당 IP나 도메인을 매핑한다.
Latency-based Routing : 용자와 가장 가까운(지연 시간이 가장 짧은) 리전에 있는 서버로 트래픽을 보내도록 구성할 수 있다.
Geo Location Routing: 사용자의 위치(국가, 대륙 등)에 따라 다른 서버로 트래픽을 보낼 수 있다.
Weighted Routing : 여러 서버 혹은 여러 리소스 사이에 트래픽 비중(Weight)을 나눠 분산할 수 있다.
Failover Routing: 메인 서버에 장애가 발생하면 백업 서버로 트래픽을 유도하는 구성도 가능
4) Health Checks
Route 53은 헬스 체크 기능을 제공해서, 특정 엔드포인트(웹 서버, HTTP/HTTPS URL 등)에 대해 정기적으로 가용성이 가능하다.
헬스 체크 상태에 따라 자동으로 DNS 레코드를 업데이트(Failover)해 장애를 우회할 수 있다.
5) 높은 가용성과 확장성
전 세계 여러 지역에 DNS 서버를 운영하고 있으므로, 매우 안정적인 DNS 응답을 제공한다.
AWS 리소스와 밀접하게 연동되므로, EC2, S3, CloudFront, ELB 등에 대한 DNS 설정이 용이하다.
AWS Route 53과 Reocrd의 역할
AWS Route 53은 DNS 서비스로 Domain 이름과 서버(IP 주소)를연결하는 역할을 한다.
사람이 이해하기 쉬운 도메인을 입력하면 이를 컴퓨터가 이해할 수 있는 IP address 로 변환해주는 시스템이라고 생각하면 된다.
Reocrd
는 도메인에 대한 특정 정보를 정의하는 설정이다.
사용자가 특정 도메인으로 접속할 때 어디로 요청을 보내야 할지를 결정하는 정보이다.
CNAME vs A 레코드 차이
A 레코드: 도메인을 특정 IP 주소와 직접 연결
CNAME 레코드: 도메인을 다른 도메인으로 연결
예: blog.example.com → example.medium.com
Route 53 + Load Balancer 연결
EC2 인스턴스가 아닌 ELB(Elastic Load Balancer)와 연결할 경우,
A 레코드 값에 IP 주소가 아니라 ALB의 DNS 이름을 입력해야 함.
또는 CNAME을 활용.
SSL(HTTPS) 적용
HTTPS를 사용하려면 AWS Certificate Manager(ACM)에서 SSL 인증서를 적용하고,
ALB + Route 53을 조합해 HTTPS 요청을 처리할 수 있음.
루트 도메인 연결 (example.com vs http://www.example.com)
http://www.example.com은 A 레코드로 설정 가능.
하지만 example.com을 CNAME으로 설정할 수 없음 → A 레코드 필요.
S3(Simple Storage Service)
AWS S3(Amazon Simple Storage Service)는 클라우드 스토리지 서비스로, 데이터를 인터넷을 통해 저장하고 액세스할 수 있도록 설계된 서비스
파일 저장소 역할을 하며, 이미지, 동영상, 백업 데이터, 로그 파일, 정적 웹사이트 등을 저장하는 데 사용된다.
S3의 핵심 특징
확장성(Scalability): 저장 공간이 무제한(이론적으로)
내구성(Durability): 99.999999999% (11 9s) 데이터 보호
가용성(Availability): 여러 리전(Region)에 분산 저장 가능
보안(Security): IAM, 버킷 정책, 암호화 제공
비용 효율성(Cost Efficiency): 사용한 만큼 비용 지불 (Pay-as-you-go)
***** S3는 계층적 파일 시스템이 아니라 키-값(Key-Value) 저장 방식을 사용합니다. ****
버킷(Bucket) → 객체(Object) 구조로 동작
S3 스토리지 클래스 (Storage Classes)
S3는 여러 종류의 스토리지 클래스(Storage Class)를 제공하여 비용과 성능을 최적화할 수 있다.
S3의 주요 기능
1. 정적 웹사이트 호스팅 (Static Website Hosting)
S3에 HTML, CSS, JavaScript 파일을 업로드하여 정적 웹사이트를 호스팅 가능.
Route 53을 통해 도메인 연결 가능.
CloudFront + SSL 적용 시 HTTPS 지원 가능.
2. 객체 수명 주기 관리 (Lifecycle Policies)
데이터를 일정 시간이 지나면 자동으로 IA(Standard-IA) 또는 Glacier로 이동.
예: 30일 후 IA로 이동, 90일 후 Glacier로 이동.
3. 버전 관리 (Versioning)
같은 파일을 덮어써도 이전 버전을 보존할 수 있음.
데이터 복구 및 실수 방지 가능.
4. 서버 액세스 로그 (Server Access Logs)
누가 어떤 파일을 다운로드했는지 로그 기록 저장 가능.
보안 분석 및 감사 용도로 활용.
5. 암호화 (Encryption)
S3는 기본적으로 데이터를 암호화 가능 (SSE-S3, SSE-KMS).
전송 중 암호화(HTTPS) & 저장 중 암호화(SSE) 제공.
6. 이벤트 알림 (Event Notification)
S3에 파일이 업로드되면 Lambda, SNS, SQS와 연동 가능.
예: 새로운 이미지가 업로드되면 자동으로 썸네일 생성.
7. 크로스 리전 복제 (Cross-Region Replication, CRR)
한 리전(예: 서울)에 저장된 데이터를 다른 리전(예: 미국)으로 자동 복제.
재해 복구(DR) 및 글로벌 접근성을 높일 때 유용.
S3 사용 사례
웹사이트 및 애플리케이션 데이터 저장
HTML, CSS, JavaScript 파일 배포
정적 웹사이트 호스팅
데이터 백업 및 복원
기업의 중요한 문서 및 데이터 저장
장기 보관(Glacier)
로그 및 분석 데이터 저장
웹 서버, 애플리케이션 로그 저장
빅데이터 분석
미디어(이미지, 비디오) 저장 및 스트리밍
Netflix, Disney+ 같은 기업이 S3를 활용하여 영상 저장
데이터 공유 및 협업
데이터 공유 및 엑세스 권한 관리
S3(Simple Storage Service)로 정적 웹사이트 호스팅 + Route 53 연결
WS S3를 이용하면 서버 없이 정적 웹사이트(HTML, CSS, JavaScript 파일 등)를 호스팅할 수 있다. AWS S3에는 정적 웹사이트 호스팅 기능이 있어서 특정 Bucket을 웹사이트처럼 사용할 수 있다. 이 기능을 사용하면 HTML, CSS, JS 등의 정적 파일을 업로드하여 웹사이트로 제공할 수 있다.
하지만 PHP, Python, Node.js 같은 서버 사이드 로직이 필요한 웹사이트는 사용 불가능하며, 데이터베이스(MySQL, PostgreSQL)와의 직접적인 연결 불가능하다.
문제 1) S3 정적 웹사이트를 Route53을 통해 레코드를 만들어줄 예정.
이런 경우 반드시 S3의 버킷명과 레코드가 일치해야합니다.
http://www.example.store 라는 영문주소를 내 버킷으로 연결하고 싶다면.
버킷이름을 http://www.example.store로 만들어야한다.
이유는 무엇일까??
S3 정적 웹사이트를 Route 53과 연결할 때 버킷 이름을 도메인 이름과 동일하게 설정해야 하는 이유는
S3의 정적 웹사이트 엔드포인트(Website Endpoint) 구조 때문이다.
S3에서 Static Website을 호스팅할때는 S3는 특정한 URL 구조를 사용하여 웹 사이트를 제공한다.
ex) Bucket Name 이 www.example.com 이라고 한다면 S3는 자동으로 이와 같은 URL 을 생성하여 웹 사이트를 제공하게 된다.
http://www.example.store.s3-website-us-east-1.amazonaws.com
S3는 버킷 이름을 도메인과 일치시켜야만 위 URL을 만들고 웹사이트를 제공할 수 있음
Route 53에서 http://www.example.store을 S3 정적 웹사이트와 연결하려면,
Alias 레코드(A 레코드)를 S3의 웹사이트 엔드포인트에 연결해야 한다.
Route 53 설정 시, S3 정적 웹사이트 엔드포인트와 연결하는 과정은
Route 53에서 www.example.store 도메인의 A 레코드(Alias) 추가
Alias Target(대상)으로 S3 웹사이트 엔드포인트 선택
S3에서 www.chanman.store 버킷의 웹사이트 URL로 자동 연결됨
만약 버킷 이름이 다르면?
S3가 www.example.store이라는 도메인을 인식하지 못함
Route 53이 해당 도메인을 S3 버킷과 연결할 수 없음
도메인과 S3 버킷 이름이 일치해야 하는 이유
1) S3는 특정한 URL 패턴을 따름,
S3 Static 웹사이트는 버킷 이름을 기반으로 웹사이트 Endpoint (URL)을 생성합니다.
버킷 이름이 도메인과 같아야 Route 53이 해당 S3 버킷을 찾아 연결할 수 있음.
2) Route 53의 Alias Record 설정과 관계됨
Route 53의 Alias 레코드는 S3 웹사이트 엔드포인트를 직접 참조
이때 도메인 이름과 S3 버킷 이름이 일치해야만 자동으로 엔드포인트가 매칭된다.
3) S3는 Host Bucket을 Route Domain 기반으로 찾는다.
버킷이름이 다르면 S3는 해당 도메인을 호스팅할 버킷을 찾지 못한다. 따라서 S3가 이 도메인에 대한 웹사이트가 존재하지 않는다고 판단하여 연결하지 않게 된다.
결론적 중요한 점은 S3가 웹사이트의 Endpoint (URL)가 Bucket Name 을 기반으로 생성된다는 것이다. 그렇기 Bucket의 이름이 Domain과 다른 경우 Route 53의 Alias record가 Endpoint 를 기반으로 Domain의 Hosting Bucket 을 찾지 못하기 때문에 두 개를 동일하게 설정해야하고
만약 다른 Root Dmoain (ex: example.com) 등을 추가하려면 Redirection 과 같은 설정이 필요하다.
CNAME 도 Alias Record 와 비슷한 역할을 할 수 있지만 CNAME 은 Domain을 기준으로 A라고 입력 받은 도메인을 B 로 변환시켜 전달하는 역할을 한다면
Alias Record는 Domian을 기반으로 해당 Bucket의 웹사이트 Endpoint (URL)에 직접 연결시키는 것이다.
Alias Record
- Route 53에서 AWS 리소스(예: S3, CloudFront, ELB)를 직접 연결하는 역할.
- Alias Record는 DNS 쿼리를 AWS 내부적으로 최적화하여 빠르게 처리함.
- 도메인 → 특정 AWS 리소스의 엔드포인트(URL)와 직접 매핑
http://www.example.com → example.cohttp://m.s3-website-us-east-1.amazonaws.com
CNAME Record
- 도메인 이름을 다른 도메인 이름으로 변환하는 역할.
- CNAME은 특정 IP가 아니라 도메인 기준으로 매핑됨.
blog.example.com → myblog.medium.com
루트 도메인(example.com)에는 CNAME을 사용할 수 없음.
example.com → http://www.example.com을
대신 Alias Record 또는 Redirection 사용해야 함.
별칭 또는 비 별칭 레코드 선택 - Amazon Route 53
Route 53 호스팅 영역(동일한 호스팅 영역 또는 다른 호스팅 영역)에 있는 다른 레코드의 이름으로 리디렉션되는 CNAME 레코드를 생성하는 경우 각 DNS 쿼리는 다음 두 개의 쿼리로 요금이 부과됩니
docs.aws.amazon.com
Alias 레코드와 CNAME 레코드의 비교
별칭 레코드는 CNAME 레코드와 비슷하지만, 다음과 같은 중요한 차이점이 몇 가지 있습니다. 다음 목록은 별칭 레코드와 CNAME 레코드를 비교합니다.
쿼리를 리디렉션할 수 있는 리소스
별칭 레코드
별칭 레코드는 다음을 포함하되 이에 국한되지 않는 쿼리를 선택한 AWS 리소스로 리디렉션할 수 있습니다.
Amazon S3 버킷
CloudFront 배포
동일한 Route 53 호스팅 영역의 다른 레코드
예를 들어, acme.example.com이라는 이름의 Amazon S3 버킷으로 쿼리를 리디렉션하는 acme.example.com이라는 별칭 레코드를 생성할 수 있습니다. example.com 호스팅 영역의 zenith.example.com 레코드로 쿼리를 리디렉션하는 acme.example.com 별칭 레코드를 생성할 수도 있습니다.
CNAME 레코드
CNAME 레코드는 DNS 쿼리를 DNS 레코드로 리디렉션할 수 있습니다. 예를 들어 acme.example.com에서 zenith.example.com 또는 acme.example.org로 쿼리를 리디렉션하는 CNAME 레코드를 생성할 수 있습니다. 쿼리를 리디렉션할 도메인의 DNS 서비스로 Route 53를 사용할 필요가 없습니다.
도메인과 이름이 동일한 레코드 생성(zone apex의 레코드)
별칭 레코드
대부분의 구성에서 호스팅 영역(zone apex)과 이름이 동일한 별칭 레코드를 만들 수 있습니다. 단, zone apex(예: example.com)의 쿼리를 CNAME 유형의 동일한 호스팅 영역에 있는 레코드(예: zenith.example.com)로 리디렉션하려는 경우는 예외입니다. 별칭 레코드는 트래픽이 라우팅되는 레코드와 동일한 유형이어야 하고 zone apex에 대한 CNAME 레코드 생성은 별칭 레코드에 대해서도 지원되지 않기 때문입니다.
CNAME 레코드
호스팅 영역(zone apex)과 이름이 동일한 CNAME 레코드는 만들 수 없습니다. 이는 도메인 이름(example.com)의 호스팅 영역과 하위 도메인(zenith.example.com)의 호스팅 영역 모두에 해당됩니다.
DNS 쿼리 요금
별칭 레코드
Route 53는 AWS 리소스에 대한 별칭 쿼리에 대해 요금을 부과하지 않습니다. 자세한 내용은 Amazon Route 53 요금을 참조하십시오.
CNAME 레코드
Route 53는 CNAME 쿼리에 대해 요금을 부과합니다.
참고
Route 53 호스팅 영역(동일한 호스팅 영역 또는 다른 호스팅 영역)에 있는 다른 레코드의 이름으로 리디렉션되는 CNAME 레코드를 생성하는 경우 각 DNS 쿼리는 다음 두 개의 쿼리로 요금이 부과됩니다.
Route 53는 리디렉션하려는 레코드의 이름으로 첫 번째 DNS 쿼리에 응답합니다.
그런 다음 DNS 해석기는 트래픽을 리디렉션하려는 위치(예: 웹 서버의 IP 주소)에 대한 정보를 얻기 위해 첫 번째 응답의 레코드에 대한 다른 쿼리를 제출해야 합니다.
CNAME 레코드가 다른 DNS 서비스와 함께 호스팅되는 레코드의 이름으로 리디렉션되는 경우 Route 53는 한 개의 쿼리에 대해 요금을 부과합니다. 다른 DNS 서비스는 두 번째 쿼리에 대해 요금을 부과할 수 있습니다.
DNS 쿼리에 지정된 레코드 유형
별칭 레코드
Route 53는 별칭 레코드 이름(예: acme.example.com)과 별칭 레코드 유형(예: A 또는 AAAA)이 DNS 쿼리의 이름 및 유형과 일치할 때만 DNS 쿼리에 응답합니다.
CNAME 레코드
CNAME 레코드는 A 또는 AAAA와 같이 DNS 쿼리에 지정된 레코드 유형에 관계없이 레코드 이름에 대한 DNS 쿼리를 리디렉션합니다.
레코드가 dig 또는 nslookup 쿼리에 나열되는 방법
별칭 레코드
dig 또는 nslookup 쿼리에 대한 응답에서 별칭 레코드는 레코드를 생성할 때 지정한 레코드 유형(예: A 또는 AAAA)으로 나열됩니다. (별칭 레코드에 지정하는 레코드 유형은 트래픽을 라우팅하는 리소스에 따라 다릅니다. 예를 들어 S3 버킷으로 트래픽을 라우팅하려면 유형에 A를 지정합니다.) 별칭 속성은 Route 53 콘솔 또는 AWS CLI list-resource-record-sets 명령과 같은 프로그래밍 요청에 대한 응답에서만 표시됩니다.
CNAME 레코드
CNAME 레코드는 dig 또는 nslookup 쿼리에 대한 응답에서 CNAME 레코드로 나열됩니다.
Root Domain Redirection
Why?
S3는 "http://www.example.com"과 같은 서브도메인에 정적 웹사이트를 직접 제공할 수 있다. 하지만 "example.com" (루트 도메인)은 S3에서 정적 웹사이트로 직접 호스팅할 수 없다. 그래서 루트 도메인(example.com)을 "www.example.com"으로 리디렉션해야한다. example.com을 http://www.example.com으로 리디렉션하는 설정이 필요함.
이 설정을 하지 않으면 사용자가 example.com에 접속했을 때 웹사이트를 찾을 수 없다.
루트 도메인을 리디렉션하는 방법
AWS에서는 S3 정적 웹사이트 호스팅 + Route 53을 조합하여 루트 도메인 리디렉션을 설정할 수 있다.
1) S3 리디렉션 버킷을 사용한 루트 도메인 리디렉션
루트 도메인(example.com)용 S3 버킷 생성
AWS S3 콘솔에서 버킷 생성
버킷 이름을 루트 도메인과 동일하게 설정 (example.com)
Public Access 차단 해제
Route 53에서만 사용하므로 실제 파일을 저장할 필요 없음.
Static Website Hosting 활성화
"이 버킷을 사용하여 웹사이트 호스팅 활성화" 체크
리디렉션 대상: http://www.example.com 입력
리디렉션 유형: HTTP 301 (영구 이동, Permanent Redirect)
이제 이 S3 버킷은 example.com으로 접속하면 자동으로 http://www.example.com으로 리디렉션함.
2) Route 53에서 루트 도메인(example.com) 연결
Route 53 콘솔로 이동
"호스팅 영역(Hosted Zone)"에서 example.com 클릭
새 A 레코드(Alias) 추가
이름(Name): (비워둠) → 루트 도메인 설정
레코드 유형(Type): A - IPv4 주소
Alias 활성화: "예(Yes)" 선택
Alias 대상(Target): "example.com" S3 리디렉션 버킷 선택
이제 example.com으로 접속하면, http://www.example.com으로 자동 리디렉션됨!
Test
S3 리디렉션 버킷이 제대로 동작하는지 확인
브라우저에서 http://example.com 입력
자동으로 http://www.example.com으로 이동하는지 확인
이동하지 않는다면 S3의 정적 웹사이트 호스팅 설정 및 리디렉션 대상이 올바른지 확인
Route 53 레코드 설정 확인
AWS Route 53에서 example.com의 **A 레코드(Alias)**가 S3 리디렉션 버킷을 가리키는지 확인
http://www.example.com이 올바르게 설정되어 있는지 확인
2) CloudFront + Lambda@Edge 리디렉션
HTTPS를 지원해야 한다면 CloudFront 사용을 고려해야 함
CloudFront 배포 생성
오리진을 http://www.example.com의 S3 웹사이트로 설정
Lambda@Edge를 사용하여 example.com → http://www.example.com으로 리디렉션 설정
이 방식의 장점
HTTPS 지원
전 세계 CDN(CloudFront) 캐시를 사용하여 빠른 응답
더 강력한 커스텀 리디렉션 로직 적용 가능
3) Application Load Balancer(ALB) Redirect Rules
ALB의 Listener Rules을 사용하여 example.com → http://www.example.com으로 리디렉션 설정 가능
EC2 또는 ECS와 함께 사용할 때 유용
ALB 리디렉션 설정 방법
ALB 생성
Listener에서 Redirect Rule 추가
example.com으로 들어오는 요청을 **HTTP 301 → http://www.example.com으로 리디렉션
이 방식은 동적 웹사이트(예: WordPress, Django, Node.js)와 함께 사용할 때 적합
비용이 발생하지만 HTTPS 및 트래픽 관리 기능이 필요할 경우 유용