[AWS] Route 53과 S3로 정적 웹사이트 올리기

Route 53은 AWS 프리티어에 해당하지 않아 고민했는데, 계속 미루다가는 공부하지 못할 것 같아 그냥 도메인을 12달러 주고 샀다.

아래의 설명은 Amazon Route 53 시작하기에서 정리/복사한 것이다. 사실 내 글보다는 자습서를 보는 것이 더 나을 테지만 예시가 필요한 사람은 참고하길 바란다.

---

Amazon Route 53

인터넷상의 모든 컴퓨터는 IP 주소라고 하는 숫자를 사용하여 서로 통신한다. 이 IP 주소에는 192.0.2.44와 같은 IPv4 주소와 2001:0db8:85a3:0000:0000:abcd:0001:2345와 같은 IPv6 주소가 있다. 그러나 우리가 해당 웹 사이트로 이동할 때는 이런 긴 숫자를 기억해 입력할 필요가 없다. 그 대신 example.com과 같은 도메인 이름을 입력해도 원하는 웹 사이트로 갈 수 있다. Amazon Route 53과 같은 DNS 서비스는 이와 같이 도메인 이름과 IP 주소를 연결하도록 돕는다.

Route 53에 도메인 이름을 등록하면 Route 53은 도메인과 동일한 이름의 퍼블릭 호스팅 영역을 자동으로 생성한다.

(* 퍼블릭 호스팅 영역이란 특정 도메인(예: example.com)과 그 하위 도메인(apex.example.com)의 트래픽을 인터넷에서 라우팅하는 방식에 대한 정보를 담고 있는 컨테이너이다.)

호스팅 영역을 생성하면 Amazon Route 53에서 해당 영역에 대한 NS(이름 서버) 레코드 및 SOA(권한 시작) 레코드를 자동으로 생성한다.

(* NS 레코드는 DNS 쿼리가 이름 서버에 라우팅되도록 등록자 또는 DNS 서비스에 부여하는 네 개의 이름 서버를 식별한다. SOA 레코드는 도메인에 대한 기본 DNS 정보를 식별한다.)

추가로 알면 좋은 DNS(Domain Name System) 관련 개념들

- Domain Name System (DNS): 컴퓨터, 스마트폰, 태블릿 및 기타 IP 지원 장치가 서로 통신하도록 도와주는 전 세계 서버 네트워크. 

- alias record(별칭 레코드): Amazon CloudFront 배포와 Amazon S3 버킷 등의 AWS 리소스로 트래픽을 라우팅하기 위해 Amazon Route 53을 통해 생성할 수 있는 레코드의 유형

- authoritative name server(신뢰할 수 있는 이름 서버): Domain Name System(DNS)의 한 부분에 관한 확정적 정보가 있고 DNS 해석기의 요청에 대해 해당되는 정보를 반환하여 응답하는 이름 서버.

- DNS query(DNS 쿼리): 일반적으로 컴퓨터나 스마트폰 같은 장치가 도메인 이름과 연결된 리소스를 위해 Domain Name System(DNS)에 제출하는 요청.  DNS 쿼리에 대한 일반적 응답은 웹 서버 같은 리소스에 연결된 IP 주소이다.

- DNS resolver(DNS 해석기): 흔히 인터넷 서비스 제공업체(ISP)가 관리하며 사용자 요청과 DNS 이름 서버 사이에서 중개 역할을 하는 DNS 서버. DNS 해석기는 재귀 이름 서버라고도 하는데, 응답(일반적으로 IP 주소)을 얻을 때까지 일련의 권한 DNS 이름 서버에 요청을 전송하고 사용자의 장치(예: 노트북 컴퓨터의 웹 브라우저)로 이 응답을 반환하기 때문

- 호스팅 영역: 도메인과 그 전체 하위 도메인의 트래픽을 라우팅하는 방법에 대한 정보를 포함하고 있는 레코드의 컨테이너. 호스팅 영역은 해당 도메인과 이름이 같다.

- routing policy(라우팅 정책): Route 53이 DNS 쿼리에 응답하는 방식을 결정하는 레코드에 대한 설정

- subdomain(하위 도메인): 등록된 도메인 이름 앞에 하나 이상의 레이블이 붙은 도메인 이름. 예를 들어 도메인 이름 example.com을 등록하면 www.example.com은 하위 도메인이 된다.

---

이제 본격적으로 실습해보자.(도메인이 없다는 것을 가정하고 진행하겠다.)

일단 AWS 서비스에서 Route 53에 들어가 'Domain registration'을 선택해 'Register Domain' 버튼을 눌러 도메인을 생성한다.

내가 갖고픈 도메인 이름을 검색하고 TLD(Top Level Domain; .com, .org와 같은 최상위 도메인)를 선택하면 그에 따른 가격이 나온다. 난 내 깃헙 아이디를 따라 yuda110.com을 샀다. 대체로 1년에 12달러다.

도메인이 활성화되는 데에는 최대 3일이 걸리지만 대체로 두어 시간 안에 완료된다.

---

Amazon S3

일단 여기까지 완료했으면 Amazon S3 서비스로 가자. 여기 S3 버킷에 우리가 만들 웹사이트 리소스를 올려둘 거다.

버킷은 example.com과 www.example.com 이렇게 총 2개를 만들 거다. 참고로 www.example.com은 선택사항이지만 만드는 것을 추천한다.

일단 첫 번째 버킷을 만들자. 첫 번째 버킷 이름은 본인 도메인으로 한다(난 yuda110.com을 만들었으니 버킷 이름도 yuda110.com이다). 사용자가 내 도메인 이름을 통해 웹사이트에 접속한다면 그에 해당하는 도메인 이름을 가진 S3 버킷에서 리소스를 가져올 수 있다.(자세한 라우팅 설명은 Amazon Route 53이 도메인의 트래픽을 라우팅하는 방법 참조)

리전은 본인으로부터 가장 가까운 곳을 선택한다.

만들고나면 버킷 정책을 업데이트 해야한다. 버킷에서 [권한 > 버킷 정책]에 다음 코드를 추가해준다. your-domain-name이라 돼있는 부분은 당연히 본인 도메인 이름으로 해야 한다.

(* 만약 access denied가 뜬다면 해당 페이지에서 [권한 > 퍼블릭 액세스 설정]에 들어가 '이 버킷에 대한 퍼블릭 버킷 정책 관리' 아래 항목들을 해제한다.)

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

다 했으면 [속성 > 정적 웹사이트 호스팅]을 선택해 인덱스 문서에 index.html 라고 적어준다. 사용자가 yuda110.com으로 접속한다면 이 index.html 파일을 보여줄 것이다.

미리 만들어둔 html 소스가 있다면 그것들을, 아직 시작단계라면 index.html 파일만을 대충 만들어 내 example.com S3에 업로드한다.

+ 선택사항) 만약 www.example.com으로도 내 웹사이트를 보여주고 싶다면 www.example.com 이라는 S3 버킷을 하나 더 만든다. 여기엔 따로 버킷 정책을 적어줄 필요는 없고, [속성 > 정적 웹 사이트 호스팅]에서 '요청 리디렉션'을 선택하고, 내 example.com 도메인을 넣으면 된다.

---

Amazon Route 53

S3 준비가 끝났으니 이제 다시 Route 53으로 돌아와 도메인의 DNS 트래픽을 S3 버킷으로 라우팅해줘야 한다. Route 53에서 Hosted zones를 선택한 뒤, 'Create Record Set' 버튼을 클릭한다.

(* 우리는 Route 53으로 도메인을 생성했으므로 NS 레코드와 SOA 레코드는 자동으로 생성돼있을 것이다.)

여기서 두 개의 레코드를 생성할 건데,

1. example.com

alias로 S3 버킷 리전을 적는다. 서울이라면 s3-website.ap-northeast-2.amazonaws.com 이렇게. 어차피 눌러보면 다 나오기 때문에 직접 칠 일은 없다. 나머지는 다 기본값으로 한다.

2. www.example.com

alias가 위의 example.com의 것과 동일해야 한다.

---

이제 example.com이나 www.example.com으로 접속해 정말 내 사이트가 뜨는지 확인해보자.

내 주소는 http://yuda110.com/ 이다.

앗, 그런데 내 도메인의 프로토콜이 http다! http는 나의 데이터를 보호해주지 않아 까딱하면 내가 사용자와, 그러니까 서버가 클라이언트와 주고받는 데이터가 유출될 수 있다. 생각만 해도 무섭군!!(http와 https에 대한 포스팅)

다음 포스팅은 http로 들어온 요청을 https로 리디렉션하는 방법....으로 하겠다!