Web Service 3 Tier Architecture (2) - Global Service (Route 53, ACM, WAF) + 도메인 (Gabia)

1. 최종 목표

---

외부 도메인을 AWS에 연결하고, HTTPS로 안전하게 서비스해보자.

• 인증서: ACM
• HTTPS 처리: ALB 리스너
• 도메인 연결: Route 53

실습 순서

1. 외부 도메인 구매
2. Route 53 호스팅존 생성
3. NS 레코드 → 가비아에 등록 (도메인 위임)
4. Route 53에서 A 레코드 추가 → ALB 엔드포인트 연결
                                                 → ALB DNS 서버 네임
5. ACM 인증서 발급 (DNS 검증은 Route 53에 위임되어 있어야 자동 등록됨)
6. ALB 리스너 생성 → HTTPS 리스너에 인증서 연결

 

2. 도메인 구매

---

2-1. 도메인 구매 고민

---

• 이전 글의 “Amazon Route 53을 사용한 ELB 트래픽 라우팅”를 참고

https://jinhos-devlog.tistory.com/entry/Web-Service-3-Tier-Architecture-1-VPC-EC2-NAT-ELBALB-RDS-OpenVPN#4-8.%20%EA%B6%81%EA%B8%88%EC%A6%9D%20%EB%B0%8F%20%EB%8F%99%EC%9E%91%EC%9B%90%EB%A6%AC-1

• ALB 자체에는 DNS로 HTTPS 설정을 할 수 없다.
  • ‘맞춤 도메인’이 필요하다. —> AWS에서 제공하는 DNS 서비스 Route 53 활용
  • ‘맞춤 도메인’을 연결하려면, Route 53이 필요하다.
• ⇒ 그래서 우리는
  • 도메인 설정(HTTPS 설정을 위해)을 하고, Route 53 설정을 할 것
• 물론 Route53에도 “도메인 등록” 또한 가능하다.
  • 어차피 네임서버 관리를 모두 위임할 예정이라면,
    Route 53에서 구입하면 → 자동으로 Hosted Zone도 같이 만들어주기 때문에 편하다.
  • 하지만, 현재 실습 상황이기에 싼 값의 도메인을 외부에서 구매해서 Route 53에 위임시키는 실습을 진행해보자.

⇒ 외부 도메인(가비아) 사용 예정

 

2-2. 외부 도메인 구매 in 가비아

---

가비아 접속

https://www.gabia.com/

• .shop 이나 .store은 500원에 살 수 있다!
• 원하는 도메인명을 검색해서 구매
  • 내 도메인에 뜨는 데에 “5분” 정도 걸리는 것 같다.

 

2. Route53 설정

---

2-1. DNS (네임 서버)의 역할

---

현재 상황

• 현재 가비아에서 “도메인”을 구매하기만 했을 뿐이다.
• 네임서버는 도메인을 구매한 업체(가비아 등)에서 기본 제공한다.
• 현재
  • 도메인을 가비아에서 구매만 한 상태고,
  • Route 53에서 호스팅 존을 만들지 않았고,
  • DNS 네임서버 위임도 하지 않은 상태

Route 53? 가비아?

• 어떻게 보면 가비아에서도 ‘도메인 구매’, ‘DNS 설정’ 등을 모두 해준다.
  • 아무거나 양쪽에서 하나만 사용하면 된다.
• 가비아에서도 네임서버를 기본 제공한다고 하였는데? 그냥 가비아에서 다 해주면 안돼?
  • ACM에서 SSL 인증서 생성 시 DNS 검증을 자동으로 해주기 위해서이다.
  • ACM이 Route 53을 통해 관리 중인 도메인이라면, 자동으로 필요한 CNAME 레코드를 생성해준다.
    • 외부 DNS(가비아 등) 를 사용할 경우, 자동 생성이 불가능하고, 수동으로 복붙해서 CNAME 레코드를 직접 추가해야 하는 번거러움이 있다. ⇒ 관리 편의성 측면

 

2-2. 호스팅 영역 생성

---

Route 53 콘솔 이동

• [Route 53] → [호스팅 영역] → [호스팅 영역 생성]

호스팅 영역 생성

• 도메인 이름: 3tierwebtest.shop
• 유형: 퍼블릭 호스팅 영역
• 그 외 설정은 기본값 유지

• 호스팅 영역이 생성되면 자동으로 NS, SOA 레코드 생김
  • NS 레코드 : 이 도메인을 누가 관리할지 알려주는 주소
    • (NS에 4개의 네임서버 주소가 생김)
    • 이 네임서버가 실제로 A 레코드, CNAME, MX 같은 세부 설정을 저장
  • SOA (Start of Authority) 레코드 : 도메인의 DNS 설정을 대표해서 누가 책임지는지 알려주는 정보
    • (손댈 일 없다.)
• ⇒ 가비아 도메인 관리 콘솔로 이동해서 네임서버로 설정

3. 도메인 등록기관(가비아)에서 네임서버 설정 변경

---

3-1. 가비아 네임서버 설정

---

• 가비아 등록 도메인 → 설정 → 네임 서버에 위의 4개 NS 설정 (끝에 온점 빼고)

 

 

4. Route 53에서 레코드 추가 (DNS 설정)

---

4-1. 루트 도메인 (3tierwebtest.shop) Alias → ALB

---

• 3tierwebtest.shop으로 접근 시 → ALB로 접근 가능
  • [레코드 생성] → 우측 상단 [마법사로 전환] → [단순 라우팅]
  • 루트 도메인(3tierwebtest.shop)은 CNAME을 사용할 수 없다. (DNS 표준상 제한)
  • AWS에서는 그걸 대신해서 ALIAS라는 특수 기능 제공

4-2. 서브도메인 (www.3tierwebtest.shop) CNAME → ALB

• www.3tierwebtest.shop으로 접근 시 → ALB로 접근 가능

---

 

 

4-3. 참고

---

• 여기까지 하면 사실 “도메인 연결”만 해준 것.
  1. Route 53 → ALB 연결 (A 레코드): 사용자가 도메인으로 접속할 때 어디로 갈지 결정
  2. ACM 인증서: HTTPS 연결 시, 브라우저에게 보안 증명
  3. ALB 리스너: HTTPS 요청 받을 준비 + 인증서 적용
     • 중 1번만 한 것
• 즉, HTTPS 설정은 아직 아무것도 안했고, DNS를 통해서 도메인으로 접속하면 내부 ALB로 접근할 수 있도록 해준것.
• 즉, http://www.3tierwebtest.shop (혹은 http://3tierwebtest.shop) 접근 시 ALB로 접근하도록 한 것.
  • 참고 : ALB 설정에서 리스너에 기본적으로 HTTP:80 → 타겟 그룹 (TG-Web-3tier)을 바라보게 설정했기 때문에 NGINX 페이지가 나옴.

 

레코드란?

• 도메인 이름을 IP 주소나 다른 AWS 리소스로 연결해주는 설정
  • nginx에서의 server_name이나 location 블록이 특정 요청을 어디로 라우팅할지 정하는 것과 같다.

레코드 종류

• A 레코드: 도메인을 IPv4 주소로 연결 (예: EC2 인스턴스 IP 등)
  • Alias 레코드 (AWS 전용 A 레코드): IP가 아닌 AWS 리소스(ALB, CloudFront 등)로 연결할 수 있는 A 레코드
• CNAME 레코드: 도메인을 다른 도메인으로 포워딩 <DNS 포워딩>

레코드 설정을 어떻게 해줘야 할까?

• ALB 안쓰는 케이스 (가정)
  • 직접 EC2 인스턴스의 퍼블릭 IP 주소 입력
    • 단점 : EC2가 재시작돼서 IP 바뀌면 직접 수정해줘야 함
  • 예시)
    • 도메인: example.com
    • 유형: A
    • 값: 3.92.80.1 (IPv4 주소)
• ALB 사용
  • A 레코드 (AWS 전용 A레코드 = Alias 레코드 = AWS 리소스에 바로 연결가능
  • 예시)
    • 도메인: example.com
    • 유형: A
    • 값: Application Load Balancer or ALB의 DNS NAME
• AWS 리소스에 바로 연결 가능 - 우리는 ALB에 연결)

 

 

4-4. 참고 : WWW 서브도메인 처리 전략

---

• 서브 도메인은 어떻게 다루는 게 좋을까?

Route 53에서 www → ALB 주소로 CNAME 연결

• www 도메인이 ALB로 직접 연결됨
• 하지만 주소창은 여전히 www.3tierwebtest.shop
• ACM 인증서에 www 포함 필수

ALB 리스너에서 host == www → 루트로 리디렉션(HTTP 301)

• ALB로 들어오는 www 요청을 감지해서 → https://3tierwebtest.shop 으로 리디렉션
• 리다이렉션이기 때문에 브라우저 주소창도 바뀜 (리디렉션 응답)
• SEO 관점에서도 중복 제거

Route 53에서 www → 루트 도메인(3tierwebtest.shop)으로 CNAME 연결

• www는 그냥 루트를 따라감 (DNS 포워딩)
• www.3tierwebtest.shop → 3tierwebtest.shop 도메인 이름으로 단순 해석
• 브라우저 입장에서는 그냥 다른 주소라고 인지

정리

• www 접속 되게만 하고 싶다 : ①만 (CNAME to ALB)
• www → 루트로 통일하고 동작시키고 싶다: ① + ②
• 그냥 www 도메인을 루트처럼 보이게 하고 싶다: ③
  • 참고 : 나중에 프런트 쪽에 적용할 Route 53 설정에서 S3 정적 웹사이트 호스팅을 사용할 경우,
  • S3 자체가 도메인 기반으로 동작하고, www는 그냥 리디렉션만 해주는 "중간 역할"만 하기 때문에
  • ALB처럼 복잡한 리스너 규칙 필요 없이 Route 53에서 www → 루트 도메인 CNAME만으로도 충분할 수 있음
  • 이럴 때 아니면 안씀.

 

 

5. ACM에서 SSL 인증서 발급

---

5-1. AWS Certificate Manager

---

• 이제 실제 HTTPS 연결 시, 브라우저에게 보안 증명을 요구하기 위해 SSL 인증서를 발급 받아보자.
• 이제 ACM(AWS Certificate Manager) 을 사용해서 SSL 인증서를 생성하고,
  ALB(Application Load Balancer)에 HTTPS(SSL) 적용해보자. (6번에서)

5-2. ACM에서 SSL 인증서 생성하기

---

• AWS 콘솔 → ACM (AWS Certificate Manager) 이동
• "인증서 요청(Request a certificate)"

인증서 요청 설정

• 퍼블릭 인증서 요청 선택
  • ALB에서 사용할 퍼블릭 인증서 필요
• 도메인 입력
  • 3tierwebtest.shop
  • (서브 도메인을 사용할 예정이라면, *.3tierwebtest.shop or www.3tierwebtest.shop(명시적)도 추가)
• 검증 방법 : DNS 검증 - 권장
• 키 알고리즘: RSA

 

 

인증서 요청 제출 & 검증 (DNS 등록)

• 요청을 제출하면 AWS에서 “CNAME 레코드 값”을 제공해준다.
• Route 53에서 해당 CNAME 레코드를 도메인에 추가
• [Route 53에서 레코드 생성] 딸깍 → [레코드 생성]

• 참고 : 검증 대기중 → 발급됨(Issued) 상태로 변경(약 10분 소요) 되면 SSL 인증서 사용 가능
  • 간혹, Route 53에서 레코드 생성을 안하면, 1시간이고 2시간이고 계속 검증 대기가 뜨는 경우가 있다.
  • Route 53에서 레코드 생성은 검증 대기중에서도 가능하기 때문에 먼저 해주자.
• 참고 : 이 CNAME은 이후 무언가 HTTPS 통신을 할 때 사용되는 것은 아니다.
  • ACM 인증서를 발급하기 위해 도메인 소유권을 증명하는 DNS 레코드를 Route 53에 추가한다는 뜻이다.
  • 인증서 “발급!!”을 위해서 해당 도메인(3tierwebtest.shop, www.3tierwebtest.shop)의 소유자임을 증명하는 과정에서 DNS 검증 방식으로 처리하기 때문에,
    Route 53에서 특정 CNAME 레코드를 생성해주는 것
  • 인증서 자체가 동작하는 과정에는 전혀 필요한 것이 아니다.

 

6. ALB에 HTTPS 리스너 연결

---

• 이제, HTTPS 요청 받을 준비와 인증서를 적용해보자.
• 도메인이 ALB로 연결되려면 → ALB가 먼저 443 포트(HTTPS) 에서 대기하고 있어야 한다.

6-1. ALB에 HTTPS 리스너 연결

---

HTTPS 리스너 생성

• AWS 콘솔 → EC2 → 로드 밸런서 (ALB) 이동

• [리스너 추가]
  • HTTPS / 443
  • 대상 그룹 : TG-web-3tier

• SSL 인증서(ACM) 연결
  • “보안 리스너 설정”에서
  • 인증서 (ACM에서) : 3tierwebtest.shop
    • 이 ACM에 3tierwebtest.shop, www.3tierwebtest.shop 모두 있음

 

보안 그룹에 443 포트 허용

• ALB에 연결된 SG(SG-web-3tier-nginx) 가 443 인바운드를 받아야 함
  • 인바운드에 443 포트 열려있는지 확인
  • 연결된 Target Group이 healthy 상태인지 확인

 

6-2 .HTTP → HTTPS 리디렉션 설정

---

• 아예 HTTP 접근을 허용하지 않으려면 어떻게 해야할까?

• 현재 당연히 80 포트로 오는 것을 타겟 그룹에 연결시켜 주었으니 접근은 된다.
• http://도메인 → https://도메인 으로 강제 리다이렉트 해버리자.
• 기존에 있던 “HTTP:80” 리스너 수정
  • 대상그룹으로 전달 → URL로 리다이렉트
  • URI 부분
  • HTTPS / 443
• 참고 : 크롬 브라우저는 브라우저단에서 HTTP 접근을 HTTPS로 강제 리디렉션 해버린다…
  • 위는 Firefox로 테스트 해본 것
  • https://chlolisher.tistory.com/135

 

 

7. 접속 테스트 및 Flow

---

7-1. 최종 설정

---

• 도메인: 3tierwebtest.shop, www.3tierwebtest.shop
• DNS 제공자: 외부 (가비아), NS를 AWS Route 53으로 위임 완료
• AWS 구성
  • Route 53 호스팅 영역에 A, CNAME 레코드 설정 완료
  • ALB (Application Load Balancer): LB-web-3tier (Internet-facing)
  • 리스너:
    • HTTP 80: 301 리디렉션 → HTTPS
    • HTTPS 443: 인증서 기반 요청 처리 → Target Group 전달
  • ACM 인증서: 두 도메인(3tierwebtest.shop, www.3tierwebtest.shop) 포함
  • Target Group: TG-web-3tier (HTTP:80, 대상 유형: EC2 인스턴스)
  • EC2 인스턴스: 웹 서버 실행 중 (Nginx)

 

7-2. 전체적인 흐름 / 테스트

---

공통적인 흐름

• [도메인 요청] → [DNS (Route 53)] → [ALB] → [리스너 규칙] → [ACM (HTTPS 요청만)] → [Target Group] → [EC2]

1.http://3tierwebtest.shop

• 브라우저가 Route 53에게 DNS 조회
  • Route 53에서 <A 레코드 사용 → 3tierwebtest.shop> 조회 → ALB의 DNS 반환
• ALB가 HTTP (80) 리스너에서 요청 수신
  • 리스너 설정에 따라 리디렉션(301) → https://3tierwebtest.shop
• 클라이언트가 다시 HTTPS로 재요청 (2번 과정으로 진행됨)

 

2. https://3tierwebtest.shop

• 브라우저가 Route 53에게 DNS 조회
  • Route 53에서 루트도메인 - A레코드 조회 → ALB의 DNS 반환
• HTTPS 요청 → ALB는 포트 443에서 리스너 활성화됨
• ACM 인증서 확인 과정 [TLS HandShake]
  • 브라우저 : 인증서 요구
  • ALB : ACM에서 발급 받은 인증서를 내어준다.
    • 등록한 ACM에 3tierwebtest.shop 도메인이 포함되어 있으므로 TLS 핸드셰이크 성공
  • ALB는 클라이언트에게 SSL 인증서 제공 + TLS 핸드셰이크 완료
    • ⇒ HTTPS 연결 인정
  • 브라우저가 대칭키(암호화에 쓸 실제 키)를 생성하고
  • ALB가 준 공개키로 암호화해서 전송
  • ALB는 자기 비공개키로 복호화 → 둘만 아는 암호화 세션 형성
  • 이후, 모든 데이터는 TLS로 암호화되어 이동
• HTTPS 리스너의 기본 규칙: 모든 요청 → 대상 그룹(TG-web-3tier) 으로 전달
  • ALB가 외부에선 HTTPS(443)으로 받더라도, 내부 EC2(Target Group) 으로는 HTTP(80) 으로 전달하는 게 일반적
  • ALB는 클라이언트 요청을 내부적으로 HTTP(포트 80)로 포워딩하여 대상 EC2로 전달

 

3. http://www.3tierwebtest.shop

• 브라우저가 Route 53에게 DNS 조회
  • Route 53에서 <CNAME 레코드 사용 → www.3tierwebtest.shop> 조회 → ALB의 DNS 반환
• ALB의 HTTP 리스너(80)가 요청 수신
  • 동일하게 리디렉션(301) 수행 → https://www.3tierwebtest.shop

 

4. https://www.3tierwebtest.shop

• 브라우저가 https://www.3tierwebtest.shop를 요청
  • CNAME 레코드 확인 → ALB의 DNS로 연결됨
• HTTPS 요청 → ALB는 포트 443에서 리스너 활성화됨
• ACM 인증서 확인 과정 [TLS HandShake]
  • 등록한 ACM에 www.3tierwebtest.shop 도메인이 포함되어 있으므로 TLS 핸드셰이크 성공
• HTTPS 리스너의 기본 규칙: 모든 요청 → 대상 그룹(TG-web-3tier) 으로 전달

• 참고 : 두 도메인은 DNS에서 각각 다른 레코드로 등록되고, 자동으로 연결되지 않는 상태
  • SEO와 UX를 일관성 있게 만들기 위해 아예 하나로 통합하고 싶다면, ALB 리스너 규칙에서 한 쪽으로 리디렉션해주면 된다.
• 나중에는 서브 도메인을 사용해서
  • api.example.com은 백엔드 서버
  • static.example.com은 S3 + CDN(CloudFront)
  • admin.example.com은 사내망에서만 접속 가능
  • 등으로 나누고 적용해보자.

 

7-3. 최종 흐름

---

 

 

8. WAF

---

• Web Application Firewall을 AWS 내에서 생성할 수 있다(글로벌임)
• ALB, CloudFront, API Gateway (HTTP 레이어의 입구 단)에 연결 하여, 웹 트래픽을 분석하고 기본적인 보안 공격을 방어해준다.
  • DDoS 공격 및 악성 웹 트래픽 등으로부터 보호
• WAF는 실제로 요청을 '막거나 허용'하는 결정권을 가진 레이어
• 규칙 기반 (Rule-based) 구조로 동작한다.
• 우리는 현재 ALB에 연결해보자

 

8-1. WAF 설정

---

• [AWS WAF] → [Web ACLs] → [Create web ACL]

Describe web ACL and associate it to AWS resources

• Regional resources 선택
  • 나중에 정적 호스팅하고 CloudFront에 WAF 설정해줄 때에는 Global Resources로
• Region: Asia Pacific(Seoul) <ALB 있는 리전>
• Name: WAF-web-3tier
• Add AWS resources
  • Application Load Balancer: 나의 로드밸런서 선택
• CloudWatch metric name: WAF-web-3tier

Add rules and rule groups

• Add rules → Add managed rule groups
  • AWS managed rule groups - Free rule groups에서 원하는 것 선택 - SQL database
  • 자유롭게 설정
• Default web ACL action for requests that don't match any rules → Allow

Set rule priority

• Set rule priority - 룰셋 우선순위 조정
  • 순서 변경 가능 (현재는 테스트로 하나 뿐 ㅜ)

Configure metrics

• Request sampling options - Enable sampled requests
  • ACL(Web Access Control List) 규칙에 매칭되는 요청들 중 일부를 샘플링하여 보여줄 수 있다.

8-2. 추가 고려 상황

---

• 차단되는 패턴이나 속도 제한이 제대로 작동하는지 테스트해보기
• CloudWatch → WAF 지표 확인
• 필요시 WAF 로그 S3로 보내는 설정 가능 (선택 사항)