개발이군고구마

[멱살잡고 DevOps] 4. AWS S3/Cloudfront 설정 본문

Cloud Deploy

[멱살잡고 DevOps] 4. AWS S3/Cloudfront 설정

김구황 2025. 7. 18. 08:50
728x90
[Backend Dockerfile] 
1. backend Dockerfile 작성 🎆 
[AWS Front 설정] <- 현단계 
2. S3 버킷 & CloudFront 정적 웹 호스팅 활성화 
[AWS EC2 설정]
3. EC2 인스턴스 프로비저닝
4. EC2 환경 구성 🎆
[CI/CD] 
5. GitHub Actions CI/CD 구축 🎇
[테스트와 확장]
6.DNS 설정 및 최초 배포 테스트
7. 배포환경 분리 (dev/prod)

 


 

1. S3 버킷 생성 

1) S3 버킷 생성 

아시아 태평양(서울) ap-northeast-2 리전 설정 (지연과 가비지 트래픽 비용 절감) 

Amazon S3 관리형 키(SSE-S3)를 사용한 서버 측 암호화 선택

참고 프리티어 : 저장 용량에 따라 프리티어(월 5GB) 안에서 무료로 사용

 

 

2. ACM 인증서 발급 & DNS 검증

1) ACM 퍼블릭 SSL 인증서

✅ 왜 사용해야하는지? 

 

HTTPS 필수 : 브라우저 안전하지 않음 경고를 방지

만료 60일 전부터 자동으로 재검증과 갱신  

⛳ 대안비교
Let's Encrypt - 무료지만 별도 자동화 스크립트를 작성해야함 
💻검증 방식 선택 이유
DNS 검증은 설정 한번만 하면 나중에 자동 갱신도 DNS 레코드로 처리해도 됨 -> 관리가 간편 (가비아에 등록) 

 

-  도메인 이름 : */도메인 및 www.도메인 허용

-  검증방법 : DNS 검증 선택 

 

💥 서울 리전으로 인증서를 발행하면 Cloudfront (글로벌) 와 연동이 안됨

-> 생성시에 미국계정으로 만들어야함 

 

 

2) DNS 검증용 CNAME 레코드 등록 

- 가비아 도메인 관리 -> DNS 관리 

가비아 CNAME 등록 이후 ACM 인증서의 상태가 변경됨

 

- 검증됨 상태가 되면 SSL 인증서가 발급되어 Cloudfront 등 다른 서비스에 연결할 수 있음 

 

 

 

 

3. CloudFront 배포 생성

✅ 왜 사용해야하는지? 

 

HTTPS 지원과 성능 개선 : 전 세계 엣지 로케이션 캐시를 제공하여 사용자 시지연 시간 감소 

 

대안비교
ELB/ALB : 비용발생하고 운영 복잡도가 있음 
직접 S3로 호스팅하면 ? : HTTPS 불가함, 성능과 보안도 제한됨 

 

1) Cloudfront 배포 생성

ㄴ Origin domain은 S3가 됨 

 

 

2) Origin 접근 제어  - OAC 설정 

ㄴ 퍼블릭 읽기 대신 S3 완전 비공개를 두고, Cloudfront에서만 접근하도록 제안함 

🔊 S3 정책 변경해주어야 함

 

 

3) Default Cache Behavior 설정

ㄴ HTTP -> HTTPS로 자동 전환하여 보안 강화 

 

 

4) CNAME 및 SSL 설정 외 

ㄴ 미국 리전으로 발급한 ACM을 연결함 

💦 Alternate Domain Names 이 입력이 안됨 (ACM에 옵션에 지정이 안되어있다나 뭐라나... 이렇게 했을 때 반향을 모르겠음) 

 

 

5) 배포 상태 확인 

  • S3 버킷 생성 & 정적 웹호스팅 활성화 단계에서 했던 것들을 해제 시킴
  • Cloudfront - OAC 연결시에 제공받은 버킷 정책으로 업데이트 
  • 🧨테스트할 경로를 설정하고 테스트 파일을 업로드 시켜줘야함 

 

 

💠 Behavior: 기본(/*) → S3, /api/* → EC2(추후) 는 미완상태 

 

 

현재 까지 진행상황

 


💥 Front Dockerfile 스크립트 작성은 생략

ㄴ React 앱은 최종적으로 정적인 HTML/CSS/JS 파일 묶음(build 폴더).

ㄴ 자동화 서버(여기서는 GitHub Actions)가 소스 코드를 받아 직접 빌드한 후 그 결과물(정적 파일)을 S3에 바로 올리는 방식으로 전환