Route53

📌 Route 53 (AWS의 DNS 서비스)

Route 53은 AWS에서 제공하는 DNS(Domain Name System) 관리 서비스임. 사용자의 도메인 이름을 IP 주소로 변환하는 역할을 하며, 트래픽 라우팅과 도메인 등록 기능도 제공합니다.

---

1️⃣ Route 53의 주요 기능

✅ DNS 레코드 관리: 도메인과 IP 주소를 연결하는 DNS 레코드(A, CNAME 등)를 설정 가능
✅ 트래픽 라우팅: 사용자의 요청을 여러 AWS 리소스(EC2, S3 등)로 라우팅
✅ 도메인 등록 및 관리: 직접 도메인을 구매하고 관리 가능
✅ 가용성과 확장성: AWS의 글로벌 인프라를 이용해 빠르고 안정적인 네트워크 제공

실습

route 53

- 즐찾하고

- 가비아에 저렴한 도메인이 많음(550원)

- 명칭은 상관없음

 - 가비아에서 만들었던 도메인 이름으로 호스팅 영역의 이름을 정함.

- 내 영역에 대한 정보를 알고 있는 네임서버들

- 이 서버 목록을 가비아의 내 도메인에 입력을 해야 됨

- 한 줄씩 복붙 해서 등록하면 됨

-> 현재 내 영역에 대한 정보를 알고 있는 서버는 위 네임서버고, 실제 도메인을 소유한 사람은 가비아이기 때문임. 두 개를 매칭시키려면 가비아에게 해당 정보를 알려줘야 됨

 

- 소유자 인증하시고 이와 같이 네임서버를 등록시키면, 가비아가 상위 네임서버에 이 정보를 등록함(등록하는데 30분 정도 소요될 수도 있음.)

EC2 인스턴스

root@ip-10-10-1-149 :~#sudo -i

root@ip-10-10-1-149:~#apt update

root@ip-10-10-1-149:~#apt install -y nginx

root@ip-10-10-1-149:~# systemctl restart nginx
root@ip-10-10-1-149:~# systemctl enable nginx

-> 부팅할 때 자동으로 nginx 실행

root@ip-10-10-1-149:~# systemctl enable --now nginx

-> 지금 즉시 nginx 실행

root@ip-10-10-1-149:~# echo record test > /var/www/html/index.html
root@ip-10-10-1-149:~# curl localhost

record test

 

- 위 서버로 연결시켜 줄 레코드 생성

- ec2인스턴스 ip

- 가비아에 등록한 aws의 네임서버들이 활성화된다면www.yumzi.store로 접속이 가능할 것 

S3(Simple Storage Service)를 통한 정적 웹사이트 호스팅

S3 버킷

- S3에 간단한 웹페이지를 올려주면 웹서버처럼 페이지를 배포가 가능.

- 일반적으로 널리 쓰이는 방식   

- 버킷에 도메인 이름은 내가 만든 도메인명이랑 일치해야 됨(www포함)

- 드래그해서 가져오기

- 속성으로 가서 맨 밑에 가면 정적 웹 사이트 호스핑이 있음

 

- 접속 주소가 생김

- 현재 접근 권한이 없는 상태 => 접근 정책을 만들어줘야 함.

- 권한으로 가서 버킷 정책 편집

- 내가 직접 정책을 만들 순 없기 때문에 정책생성기를 통해 생성.

- Amazon Resoure Name

- 여기로 다시 가서 웹사이트를 클릭하면

- 잘되는 걸 확인

- 바로 버킷 삭제(강사님 이미지 가져왔어요!)

- 버킷을 지우려면 내용물이 전부 삭제가 되어 있어야 됨.

- 버킷 삭제

실습 1) www.본인도메인을 이름으로 버킷을 만든 후 프리템플릿(고양이)을 배포해 보세요.

이번에는 위에서 만든 S3 정적 웹사이트를 Route53을 통해 레코드를 만들어줄 예정.
이런 경우 반드시 S3의 버킷명과 레코드가 일치해야 함.
www.(본인 도메인).store 라는 영문주소를 내 버킷으로 연결하고 싶다면.
버킷이름을 www.(본인 도메인).store로 만들어야 함.

- 위의 과정과 동일하니까 생략 다른 과정들만 추가할게요.

 

파일 압축을 풀고 업로드하기

 - 기존에 있는 레코드로 가서 삭제해 주기

- 별칭 켜주기

-> 별칭이란? 도메인, 키, 역할 등에 더 쉽게 접근할 수 있도록 만들어진 이름임.

-> 긴 식별자 대신 짧고 의미 있는 이름으로 AWS 리소스를 사용할 수 있음.

 

• 키 ID: 1234abcd-5678-efgh-9012-ijklmnopqrst
• 별칭(Alias): alias/my-encryption-key

-> 키 ID보다 기억하기 쉬움

 

- http://www.yumzi.store 로 해야 됨. https 아님!!!!

- (고양이 웹페이지를 못 찾았어요ㅜㅜ)

실습 2) ELB도 레코드 구성이 가능함. 간단한 웹페이지를 배포하는 서버에 ALB를 붙여서 lb. <본인도메인>으로 접속되게 만들어보세요.

Certificate Manager

1️⃣ AWS 서비스와 외부 통신이 필요한 경우

➡ AWS의 다양한 서비스를 사용하기 위해서는 outbound를 통해 외부로 나가서 다양한 서비스들을 받아옴

➡ AWS 내부 서비스도 가끔 외부와 통신해야 할 때가 있음

➡ 하지만 보안상 외부 인터넷과 직접 연결되지 않는 경우가 많아서, 다음 방법을 사용해 통신 가능하도록 만들어야 함.

 

✅ 방법 1: NAT Gateway (NAT-GW)

• Private 서브넷에 있는 리소스가 인터넷으로 나가야 할 때 사용
• 예: 내부 서버에서 AWS 서비스와 통신할 때

✅ 방법 2: VPC 엔드포인트

• AWS 내부 서비스와 통신할 때 인터넷을 거치지 않고 내부 네트워크에서 바로 연결
• 예: S3, DynamoDB 같은 AWS 서비스에 안전하게 연결

2️⃣ HTTPS 통신을 위한 TLS 인증서 적용 (ALB 사용)

➡ 보통 웹 서버는 기본적으로 80번 포트(HTTP)에서 동작하지만,
➡ 사용자가 443번 포트(HTTPS)로 접속하면 보안 통신을 위해 인증서를 사용해야 함!

✅ HTTPS 통신 흐름 (ALB 기준)
1️⃣ 사용자가 https://example.com (443번 포트)으로 접속
2️⃣ ALB가 TLS 인증서를 사용해 암호화 통신 처리
3️⃣ 내부의 웹 서버는 80번 포트로만 통신하므로 ALB가 80번 리스너로 리다이렉트
4️⃣ 웹 서버가 응답을 주고 다시 ALB를 거쳐 클라이언트로 전달

💡 즉, ALB에서 HTTPS 트래픽을 받아주고, 내부 웹 서버는 HTTP로만 통신하는 구조!

실습

 

- 모든 하위 도메인 전부(*)

- 검증 방법: 검증의 대상은 yumzi.store라는 도메인임.

- 이 도메인이 유효한지 검증하고 싶어서 레코드를 한 개 만든 후, 해당 레코드로 접속되는지 여부를 확인하여, 접속이 되면 인증서를 발급하고 접속이 안되면 유효하지 않는 도메인으로 간주하여 인증서가 발급 안 될 것 임.

- 발급된 모습

 

ALB

보안 그룹 추가

대상 그룹 생성

- 내부 서버의 포트는 어쨌든 80 포트임

- 이 로드밸런서에 붙여준 인증서는 *.yumzi.store를 위한 인증서이기 때문에, alb의 dns이름(주소)으로 https요청은 불가능함. 따라서 acm.yumzi.store같은 도메인을 통해 접근할 수 있도록 레코드를 생성해 줘야 됨.

*** 이게 무슨 소리야?

- https로는 가능하지만 http로는 안됨

- 리스너를 하나 추가해서 http(80) 요청도 web서버에 연결해 줘도 되지만, 그것보다 http요청을 했을 때 어차피 인증서가 있으니까 https로 연결되도록 해보자(리다이렉션)

- 리스너 추가

 

http->https 리다이렉션

- http를 쳐도 결과가 잘 나옴

- 그리고 자동으로 리다이렉션 된 걸 확인할 수 있음

- 일반적으로 ACM에서 인증서를 만들면 같은 리전 내에서만 유효함.

- 만약에 모든 리전에서 사용 가능한 인증서를 만들고 싶다면. 버지니아 북부리전(us-east-1)에서 만들면 됨. (cloudfront를 사용하고 싶은 경우)

📌 CloudFront란?

Amazon CloudFront는 AWS에서 제공하는 CDN(Content Delivery Network, 콘텐츠 전송 네트워크) 서비스임.
즉, 웹사이트, 동영상, API 데이터 등을 전 세계에 빠르고 안전하게 제공하는 서비스임.

1️⃣ CloudFront의 주요 역할

✅ 콘텐츠 캐싱(Content Caching)
→ 사용자와 가까운 엣지 로케이션(Edge Location) 서버에 데이터를 저장하여 빠르게 제공

→  캐싱이란? 자주 사용하는 데이터를 빠르게 불러오기 위해 임시로 저장하는 기술을 말함.

✅ 속도 향상
→ 사용자와 가까운 서버에서 데이터 제공 → 지연 시간(Latency) 감소

✅ 트래픽 비용 절감
→ S3, EC2 같은 원본 서버로 가는 요청을 줄여 비용 절감

✅ 보안 강화
→ AWS Shield, AWS WAF와 연동 가능하여 DDoS 공격 방어

✅ HTTPS 지원 및 데이터 암호화
→ TLS/SSL을 기본 지원하여 안전한 데이터 전송 가능

---

2️⃣ CloudFront의 동작 과정

1️⃣ 사용자가 웹사이트(example.com)에 접속
2️⃣ CloudFront가 사용자와 가장 가까운 엣지 로케이션에서 콘텐츠 제공
3️⃣ 만약 해당 엣지 서버에 데이터가 없으면 → 원본 서버(S3, EC2 등)에서 데이터 가져옴
4️⃣ 이후 엣지 서버에 데이터를 캐싱하여 다음 요청에서 빠르게 제공

 

- Edge Location이라고 부르는 캐싱서버를 통해 미리 메인리전(서울)의 콘텐츠들을 복사해 두고 멀리 떨어진 사용자에게 빠른 서비스를 제공. cloundfront를 위해서 tls 인증서를 발급받을 텐데, 반드시 버지니아북부에서 만들어야 함.

 - 버즈니아 북부로 가서 인증서 요청

- 생겼는지 확인

리스너가 80인 ALB생성

- 확실하게 결과를 보기 위해 https only로 일단 해주기

- 나중에 생성할 레코드

- cloudfront의 주소

-> 대체 도메인(cf.yumzi.store)에 연결되는 주소

 

- cloudfront의 주소

-> 대체 도메인(cf.yumzi.store)에 연결되는 주소

-> 배포 도메인 주소

- 배포 도메인 이름으로 접속 시 잘 됨. 우리는 이 배포도메인의 대체도메인에 대한 레코드를 route53 가서 생성해 주면 됨.

- 최종적으로 대체 도메인 주소로 접속했을 때 잘 되는 걸 확인할 수 있음.

오류 /해결 방안