반응형
1. 최종 목표
외부 도메인을 AWS에 연결하고, HTTPS로 안전하게 서비스해보자.
- 인증서: ACM
- HTTPS 처리: ALB 리스너
- 도메인 연결: Route 53
실습 순서
- 외부 도메인 구매
- Route 53 호스팅존 생성
- NS 레코드 → 가비아에 등록 (도메인 위임)
- Route 53에서 A 레코드 추가 → ALB 엔드포인트 연결
→ ALB DNS 서버 네임 - ACM 인증서 발급 (DNS 검증은 Route 53에 위임되어 있어야 자동 등록됨)
- ALB 리스너 생성 → HTTPS 리스너에 인증서 연결
2. 도메인 구매
2-1. 도메인 구매 고민
- 이전 글의 “Amazon Route 53을 사용한 ELB 트래픽 라우팅”를 참고
- ALB 자체에는 DNS로 HTTPS 설정을 할 수 없다.
- ‘맞춤 도메인’이 필요하다. —> AWS에서 제공하는 DNS 서비스 Route 53 활용
- ‘맞춤 도메인’을 연결하려면, Route 53이 필요하다.
- ⇒ 그래서 우리는
- 도메인 설정(HTTPS 설정을 위해)을 하고, Route 53 설정을 할 것
- 물론 Route53에도 “도메인 등록” 또한 가능하다.
- 어차피 네임서버 관리를 모두 위임할 예정이라면,
Route 53에서 구입하면 → 자동으로 Hosted Zone도 같이 만들어주기 때문에 편하다. - 하지만, 현재 실습 상황이기에 싼 값의 도메인을 외부에서 구매해서 Route 53에 위임시키는 실습을 진행해보자.
- 어차피 네임서버 관리를 모두 위임할 예정이라면,
⇒ 외부 도메인(가비아) 사용 예정
2-2. 외부 도메인 구매 in 가비아
가비아 접속
- .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 설정을 대표해서 누가 책임지는지 알려주는 정보
- (손댈 일 없다.)
- NS 레코드 : 이 도메인을 누가 관리할지 알려주는 주소
- ⇒ 가비아 도메인 관리 콘솔로 이동해서 네임서버로 설정
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. 참고
- 여기까지 하면 사실 “도메인 연결”만 해준 것.
- Route 53 → ALB 연결 (A 레코드): 사용자가 도메인으로 접속할 때 어디로 갈지 결정
- ACM 인증서: HTTPS 연결 시, 브라우저에게 보안 증명
- 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 주소)
- 직접 EC2 인스턴스의 퍼블릭 IP 주소 입력
- 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로 보내는 설정 가능 (선택 사항)
반응형
