Web Service 3 Tier Architecture (4) - S3 & CloudFront 정적 웹사이트 호스팅

1. 프런트엔드 배포 방식

---

1-1. NGINX 사용

---

브라우저
  │
  ▼
[Nginx (EC2)]
 ├─ React 정적 파일 서빙
 └─ /api 요청 → Spring Boot 프록시

 

 

1-2. S3 + CloudFront + ALB 사용

---

브라우저
  │
  ├─ 정적 리소스 요청 → [CloudFront → S3 (React)]
  └─ API 요청        → [ALB → EC2(Spring Boot)]

출처 : https://kukim.tistory.com/174

 

• 1-3. 참고사항

---

프런트와 백의 위치

• 프론트: S3 (서버리스) → VPC 밖
• 백엔드: EC2, ECS 등 VPC 내부

ALB vs Nginx

• 리버스 프록시로써의 Nginx 역할은 사라짐
  • 이제는 프론트에서 직접 API 서버로 요청
  • (다만 Cors 문제는 따로 해결)
• ALB는 단순히 HTTP 라우팅 + 로드 밸런싱만 해줌
• React 정적 파일은 무조건 S3에서 CloudFront로 서빙
  • 정적 파일 서빙 위치 : 서버 → CDN

CORS

• 이제 프론트와 백이 도메인이 다름 → CORS 발생
• Spring Boot에서 CORS 허용 설정 필요

도메인 설계

• React 앱 : (www.)yourdomain.com [CloudFront + S3]
• API 서버 : api.yourdomain.com [ALB + EC2(SpringBoot)]

 

 

2. S3으로 정적 페이지 서빙

---

2-1. S3 버킷 생성

---

• 이름 : 3tierwebtest.shop으로 만들기
• 리전 : ap-northeast-2 (서울)
• 버킷 버전 관리 : 비활성화
  • 롤백을 위해 활성화하는 것이 좋지만, 실습이니 비활성화 (비용문제)
• 모든 퍼블릭 액세스 차단
  • S3만으로 HTTP 웹 호스팅 할 예정이라면 모두 허용

2-2. 정적 웹 호스팅 설정

---

• 버킷 클릭 → [속성] → 가장 하단 [정적 웹 사이트 호스팅] → [편집]
  • 활성화
  • 정적 웹사이트 호스팅
  • index.html
  • 404.html

버킷 정책 설정

• [권한] → [버킷 정책] → [편집]

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::3tierwebtest.shop/*"
        }
    ]
}

테스트

• 테스트용 : [객체] → [업로드]
• index.html 업로드

• [속성] 맨 밑의 ‘버킷 웹 사이트 엔드포인트’로 접근

 

 

3. CloudFront

---

3-1. CloudFront

---

• Amazon CloudFront는 짧은 대기 시간과 빠른 전송 속도로 전 세계 고객에게 데이터, 비디오, 애플리케이션 및 API를 안전하게 전달하는 고속 콘텐츠 전송 네트워크(CDN) 서비스
• S3를 정적 파일 저장소 역할
  • 하지만 HTTPS 지원 ❌ → CloudFront 필요
• 버킷 클릭 → [권한] → [퍼블릭 엑세스 차단 (버킷 설정)] → 비활성화로 변경

3-2. 요청 로직

---

• 사용자가 https://3tierwebtest.shop 접속
• CloudFront 엣지 서버가 확인:
  • 캐시된 파일 있으면 바로 응답
  • 없으면 S3에서 받아서 캐시 → 사용자에게 응답
• CloudFront는 HTTPS로 서비스하고,
• S3는 비공개 상태지만 CloudFront의 OAC로만 접근 허용됨
  • S3 버킷 정책에 CloudFront에서만 읽을 수 있도록 권한 설정

3-3 . 도메인, ACM에 대해

---

• 현재는 3tierwebtest.shop, www.3tierwebtest.shop 모두 → ALB (Nginx → EC2) 구조로 연결되어 있음.
  • 3tierwebtest.shop : CloudFront 배포 (정적 웹 오리진: S3)
  • www.3tierwebtest.shop : S3 리디렉션 버킷 → 3tierwebtest.shop
  • ACM도 새로 생성해야 함 (us-east-1 CloudFront가 있는 리전)
    • ALB (백엔드 API) [ap-northeast-2] : api.3tierwebtest.shop 등
    • CloudFront (프런트 정적 웹) [us-east-1]: 3tierwebtest.shop, www.3tierwebtest.shop
• 백엔드
  • api.3tierwebtest.shop
    • Route53에 A 레코드 추가, 대상은 기존 ALB → ALB 리스너에서 Host is api.3tierwebtest.shop 조건 걸면 백엔드만 전달 가능

---

ACM 인증서 발급

• AWS 콘솔 → 리전 us-east-1(N. Virginia)로 변경
• ACM → [인증서 요청]
• 퍼블릭 인증서
  • 도메인 이름 입력:

3tierwebtest.shop
www.3tierwebtest.shop

• 인증 방법: ✅ DNS 검증
• [요청] → Route53 사용 시 자동 검증 가능 (아니면 CNAME 수동 입력)
• 상태가 "발급됨"으로 뜰 때까지 대기

 

 

4. CloudFront 배포 생성

---

• AWS 콘솔 → CloudFront → [배포 만들기]

4-1. 기본 설정

---

• Origin domain : 3tierwebtest.shop S3 버킷 선택
  • 원본 엑세스
    • 원본 액세스 제어 설정(권장) - 새 OAC 사용
    • OAI (구버전) 사용하고 싶다면 ⇒ Legacy access identities - 새 OAI 사용
• 버킷 정책 업데이트(OAI에 대한 읽기 액세스를 허용하도록) - 예 (S3 퍼블릭 차단 상태여도 접근 허용됨)

• ‘정책 복사’ 해두기
• Enable Origin Shield : 아니요

 

참고 : OAI란

OAI는 Origin Access Identity의 약자로, S3 버킷과 같은 오리진 리소스에 대해 CloudFront 배포가 접근할 수 있도록 하는 특수한 사용자입니다.

• 주요 역할:
• OAI를 사용하면 S3 버킷에 공개적으로 접근하지 못하도록 하고, 오직 CloudFront 배포를 통해서만 콘텐츠에 접근하도록 제한할 수 있습니다.
• 보안 강화:
• 이를 통해 S3 버킷의 객체가 직접 인터넷에 노출되는 것을 막고, CloudFront를 통한 안전한 콘텐츠 배포가 가능해집니다.

즉, CloudFront OAI는 S3 버킷을 보호하면서, CloudFront 배포가 버킷의 콘텐츠에 접근할 수 있도록 허용하는 보안 메커니즘입니다.

OAC (Origin Access Control)

• 신 방식 (2023 이후 기본값)
• S3 버킷 정책에 OAI ID를 허용 → S3 버킷 정책에 CloudFront 배포 ARN 허용
• "AWS:SourceArn" 조건 필수
• CloudFront → Origin → OAC 설정

 

4-2. 기본 캐시 동작

---

• 뷰어 프로토콜 정책 : Redirect HTTP to HTTPS

캐시 키 및 원본 요청

• Legacy cache settings
  • 객체 캐싱 : Customize → 기본 / 최대 TTL
  • (60 60 60)

 

4-3. 웹 애플리케이션 방화벽(WAF)

---

• 보안 보호 비활성화

 

4-4. 설정

---

• 가격 분류 : 북미, 유럽, 아시아, 중동 및 아프리카에서 사용
• CNAME : 3tierwebtest.shop, www.3tierwebtest.shop
• SSL : us-east-1(버지니아 북부)에서 생성된 인증서
• IPv6 : 끄기
• 기본값 루트 객체 - 선택 사항 : index.html

4-5. S3 버킷 정책 교체

---

• 복사한 정책 복붙

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontAccessOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::3tierwebtest.shop/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::<YOUR_AWS_ACCOUNT_ID>:distribution/<YOUR_CLOUDFRONT_ID>"
        }
      }
    }
  ]
}

• <YOUR_AWS_ACCOUNT_ID> → 본인 AWS 계정 ID
• <YOUR_CLOUDFRONT_ID> → CloudFront 배포 ID

 

테스트

• 배포 도메인 이름으로 접근

 

4-6. Route53 연결

---

• 현재 도메인 3tierwebtest.shop의 A 레코드가 아직도 ALB 쪽으로 향하고 있다.
  • 기존 3tierwebtest.shop (A) , www.3tierwebtest.shop (CNAME) 삭제

1. Route53 → 3tierwebtest.shop의 Hosted Zone으로 이동
2. A 레코드 생성

테스트

 

4-7. 서브도메인(www) 처리

---

• HTTP로만 리디렉션 : CloudFront로 또 배포하지 않고, 간단하게 S3에서 리디렉션 처리하는 방식
• HTTPS를 www.에도 적용하고 싶다면 CloudFront 배포를 따로 해줘야 한다.
• www.3tierwebtest.shop 이름의 버킷 하나 만들기
  • 이름 : 3tierwebtest.shop
  • 퍼블릭 액세스 차단(버킷 설정) : 모두 체크 해제
  • www.3tierwebtest.shop 으로 들어오는 요청을 https://3tierwebtest.shop 로 리디렉션 하는 "포워딩용 버킷"
  • 즉, HTML을 서빙하지 않고 그냥 리디렉션만 담당하는 HTTP 301/302 역할임.

정적 웹사이트 호스팅 편집

• 호스팅 : 활성화
• 유형 : 객체에 대한 요청 리디렉션
• 이름 : 3tierwebtest.shop
• 프로토콜 - https

 

CloudFront

• Origin domain :
  • www.3tierwebtest.shop
  • (주의, 웹사이트 엔드포인트 사용)

• 원본 엑세스 : 리디렉션용이기 때문에 공개 액세스 허용
• Redirect HTTP to HTTPS
• 웹 애플리케이션 방화벽(WAF) 정보 비활성화
• 북미, 유럽, 아시아, 중동 및 아프리카에서 사용
• CNAME : www.3tierwebtest.shop
• 인증서 : 버지니아 북부(us-east-1) 리전에서 발급한 3tierwebtest.shop [해당 인증서에 루트 / 서브 둘 다 포함되어있음]
• IPv6 : 끄기

 

Route 53 레코드 추가

• 레코드 이름 : www.3tierwebtest.shop
• 레코드 유형 : A – IPv4 주소 및 일부 AWS 리소스로 트래픽 라우팅
• 별칭 대상 : CloudFront 배포에 대한 별칭
  • ****www.3tierwebtest.shop

 

테스트