| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
- model
- 클린아키텍처
- 디스크i/o
- index
- SEQUENCE
- MVC요청플로우
- 이벤트핸들러this
- AOP
- 단위테스트
- springsecurity
- JPA
- string
- OOP
- 전전긍긍
- Transaction
- 공통규약
- MVC
- 커뮤니티서버
- TDD
- 설정세팅
- 문제선택근거
- 로그백
- 냄새라도
- SpringLegacy
- JDBC
- DDD
- Ajax
- 이벤트핸들러등록
- 사면초가
- 공통기술
- Today
- Total
개발이군고구마
[멱살잡고 DevOps] 4. AWS S3/Cloudfront 설정 본문
[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 관리


- 검증됨 상태가 되면 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에 바로 올리는 방식으로 전환
'Cloud Deploy' 카테고리의 다른 글
| [멱살잡고 DevOps] 6. GitHub Actions CI/CD 구축 (1) | 2025.07.23 |
|---|---|
| [멱살잡고 DevOps] 5. AWS EC2 설정 (0) | 2025.07.21 |
| [멱살잡고 DevOps] 3. Backend Dockerfile (docker compose/docker hub) (0) | 2025.07.17 |
| [멱살잡고 DevOps] 2. 배포 아키텍처 설계 (0) | 2025.07.15 |
| [멱살잡고 DevOps] 1. Docker Compose와 ECS (컨테이너의 분산 배포) (2) | 2025.07.14 |