Https 를 사용하기 위한 방법 : AWS CloudFront 적용 과정

CloudFront를 선택한 이유

1. 도메인 구매 없이 즉시 HTTPS 적용 가능

개발/테스트 환경에서 별도 도메인 구매 없이도 즉시 HTTPS를 적용할 수 있습니다. 도메인 구매 및 DNS 설정에 드는 시간과 비용을 절약할 수 있어 빠른 프로토타입 개발에 적합합니다.

2. SSL 인증서 관리 불필요

CloudFront는 자체 SSL 인증서를 제공하므로, ACM에서 별도 인증서를 발급받고 도메인 검증을 거치는 과정이 필요하지 않습니다. 설정 복잡도를 크게 줄일 수 있습니다.

3. 실제 서비스 환경과 유사한 아키텍처 경험

실제 프로덕션 환경에서는 CDN을 통한 HTTPS 적용이 일반적입니다. CloudFront를 사용함으로써 실무에서 자주 사용되는 아키텍처 패턴을 학습할 수 있습니다.

4. 보안 강화

ALB를 직접 노출하는 대신 CloudFront를 통해 접근하게 하여 DDoS 보호 등 추가적인 보안 계층을 확보할 수 있습니다.

5. 설정의 단순함

도메인 + ACM 방식은 Route 53 설정, DNS 전파 대기, 도메인 검증 등 여러 단계가 필요하지만, CloudFront는 ALB를 오리진으로 지정하는 것만으로 즉시 HTTPS 환경을 구축할 수 있습니다.

6. 학습 목적에 적합

프로덕션 서비스가 아닌 학습 및 개발 목적이므로, 빠르고 간편하게 HTTPS 환경을 구축하는 것이 우선순위였습니다. 이후 실제 서비스 배포 시에는 커스텀 도메인과 함께 더 최적화된 설정을 적용할 수 있습니다.

---

CloudFront와 ALB 간 통신 구조

1. 사용자와 CloudFront 간 통신

사용자가 https://d21k8bpracnjzd.cloudfront.net으로 요청하면 CloudFront가 HTTPS(443포트)로 요청을 받습니다. 이때 CloudFront의 자체 SSL 인증서를 통해 암호화된 연결이 이루어집니다.

2. CloudFront와 ALB 간 내부 통신

CloudFront는 사용자로부터 받은 HTTPS 요청을 내부적으로 HTTP(80포트)로 변환하여 ALB에 전달합니다. 이는 AWS 내부 네트워크가 이미 보안이 확보된 환경이므로 성능 최적화를 위한 설계입니다.

3. ALB 포트 설정

따라서 ALB에는 80포트만 열어두면 됩니다. CloudFront가 SSL 암호화/복호화를 담당하므로 ALB에서 443포트를 추가로 열 필요가 없습니다. 이를 통해 ALB의 SSL 처리 부담을 제거하고 전체적인 성능을 향상시킬 수 있습니다.

4. 보안과 성능의 균형

사용자 관점에서는 HTTPS로 안전한 연결을 제공받으면서, AWS 내부에서는 HTTP로 최적화된 통신이 이루어지는 구조입니다. 이는 보안성과 성능을 모두 확보할 수 있는 효율적인 아키텍처입니다.

---

잠재적 취약점 분석 및 AWS의 보안 대응

이론적 위험성

CloudFront → ALB 구간이 HTTP 평문 통신이므로:

• 중간에서 패킷을 가로챌 수 있다면 데이터 노출 가능
• 네트워크 레벨에서의 스니핑 위험

AWS 백본 네트워크 사용

• CloudFront와 ALB 간 통신은 AWS 내부 백본 네트워크 사용
• 퍼블릭 인터넷을 거치지 않음
• AWS가 물리적, 논리적으로 보안 관리

네트워크 격리

• AWS 리전 내부의 프라이빗 네트워크 구간
• 외부에서 접근 불가능한 격리된 환경

---

더 강화된 보안이 필요한 경우

End-to-End 암호화 방법

1. ALB에 443포트 추가: 커스텀 도메인 + ACM 인증서
2. CloudFront → ALB HTTPS: Origin Protocol을 HTTPS로 설정
3. Application Level 암호화: 중요 데이터는 애플리케이션에서 추가 암호화

네트워크 레벨 보안

• VPC Endpoint 사용으로 트래픽이 AWS 백본을 벗어나지 않도록 보장

현실적 위험도

AWS 내부 네트워크는 일반적으로 매우 안전하다고 평가되지만, 실제 운영에서는 ALB에도 443 포트를 열어주는 것이 좋다고 생각합니다.

---

CloudFront 생성하는 방법

AWS CloudFront에 접속하여 베포 생성을 눌러줍니다.

---

Distribution name을 입력해주시고, Single website or app으로 설정해줍니다.

Single website or app을 선택한 이유:

1. 오리진이 하나

• ALB 하나만 사용 
• 모든 요청을 같은 곳으로 보내면 됨

2. 모놀리스 구조

• 하나의 애플리케이션이 모든 기능 처리
• 복잡한 라우팅 규칙 불필요

3. 간단한 설정

• Multiple은 여러 오리진 + 복잡한 라우팅 규칙 필요
• 예: /api/* → ALB, /images/* → S3, /videos/* → 다른 서버

4. 비용 효율성

• Single이 더 간단하고 관리 비용 낮음
• 불필요한 복잡성 제거

 

Multiple을 쓰는 경우:

마이크로서비스 아키텍처:
- /api/user → User Service ALB
- /api/order → Order Service ALB  
- /static → S3 버킷
- /videos → CloudFront + MediaPackage

Single을 쓰는 경우 (현재):

모놀리스:
- /* → 하나의 ALB → 하나의 애플리케이션

---

 

 

Elastic Load Balancer로 설정해주시고, 아래에 저희의 DNS 주소를 입력합니다.

 

---

WAF 보안 보호를 비활성화한 이유:

1. 비용 절약

• WAF는 월 $14 + 사용량 기반 추가 요금 발생
• 개발/테스트 환경에서는 과도한 비용

2. 현재 목적에 불필요

• 지금 목표: ALB에 HTTPS 연결
• WAF 없어도 CloudFront 기본 보안 + HTTPS는 정상 작동
• 기본적인 DDoS 보호는 CloudFront에서 제공

3. 복잡성 방지

• WAF 룰 설정은 별도 학습 필요
• 잘못 설정하면 정상 트래픽도 차단 가능
• 일단 기본 기능부터 안정화

4. 나중에 추가 가능

• 프로덕션 단계에서 필요시 언제든 활성화
• 트래픽 패턴 파악 후 적절한 룰 설정 가능

---

마지막으로 확인하시고 Create distribution을 클릭하면 설정완료!

---

여기서 설정 -> 편집을 들어가줍니다.

 

Price class에서 미국, 유럽 그리고 아시아에서 사용하는거로 수정해주세요. (가격 더 저렴)

그리고 HTTP/2 로 설정해주세요. 

HTTP/2 추천 이유:

1. 안정성

• 이미 오래전부터 널리 사용됨 (2015년부터)
• 모든 브라우저에서 완벽 지원
• 프로덕션 환경에서 검증됨

2. 충분한 성능

• HTTP/1.1 대비 큰 성능 향상
• 멀티플렉싱, 헤더 압축 등 최적화 기능

3. 호환성

• 레거시 시스템과의 호환성 문제 없음
• CDN, 프록시 등 중간 인프라에서 안정적

HTTP/3의 문제점:

• 비교적 새로운 기술 (2022년 표준화)
• 일부 브라우저/인프라에서 지원 미완
• 디버깅 도구 부족
• 예상치 못한 이슈 가능성
  

---

예상치 못한 문제

베포에는 성공했고, POST 나 PUT같은 요청은 제대로 이뤄지지만, GET요청만 안되는 문제가 발생했습니다. 아래는 포스트맨 콘솔창인데, Response Headers 에서 X-Cache : "Error from cloudfront" 라는 에러 메시지가 떴습니다. 그래서 CloudFront의 원본 설정을 수정해주기로 했습니다.

 

여기서 원본 편집을 누르고,

현재 ALB는 별도의 DNS 를 구매하지 않아서 ACM 인증서가 없는 관계로 http 만 열려있습니다. 그래서 CloudFront <-> ALB 사이에서 프로토콜을 HTTP만 해당으로 변경해줍니다.

 

 

그리고 동작으로 넘어가서 편집을 눌러줍니다.

 

여기서 뷰어 프로토콜 정책을 Redirect HTTP to HTTPS로 설정해주고, 허용된 HTTP 방법을 다 열어줍니다. 그리고 CloudFront는 기본적으로 GET 및 HEAD 방법은 기본적으로 캐시되기때문에 위와 같은 문제가 발생한거였습니다. 그래서 캐시 키 및 원본 요청에서 원본 요청 정책을 AllViewer로 수정해주었고, 이제 모든 요청이 정상적으로 동작하는 것을 확인할 수 있었습니다.

---

 

결론:

프로덕션 배포라면 안정성이 최우선이라고 생각합니다. 우선 HTTP/2로 하고 나중에 HTTP/3가 더 성숙해지면 업그레이드 할 예정입니다. 개인적으로 보안적인 측면을 고려한 인프라 구성의 중요성을 깨닫는 시간이었습니다.