06. CloudFront와 CloudWatch

AWS의 CDN 서비스인 CloudFront와 모니터링 서비스인 CloudWatch를 이해하고, 실습을 통해 콘텐츠 배포 가속화와 리소스 경보 설정을 직접 경험한다.

학습 목표

CDN(Content Delivery Network)의 개념과 필요성을 설명할 수 있다.
CloudFront의 오리진(Origin), 엣지 로케이션(Edge Location), 캐시 동작 원리를 이해한다.
S3 버킷과 CloudFront를 연동하여 정적 웹사이트를 전 세계에 배포할 수 있다.
CloudWatch의 지표(Metric), 경보(Alarm), 알림(Notification) 개념을 이해한다.
EC2 인스턴스에 CPU 부하를 발생시키고 CloudWatch 경보를 통해 이메일 알림을 받을 수 있다.

전체 구조

아래 다이어그램은 이 장에서 다루는 두 서비스의 위치와 역할을 보여준다.

Part 1: CloudFront (CDN 서비스)

1. CDN이란?

문제 상황: 물리적 거리의 한계

웹 서버가 서울 리전(Region)에 있다고 가정하자. 한국 사용자는 빠르게 접속할 수 있지만, 유럽이나 미국의 사용자는 물리적 거리 때문에 응답이 느려진다.

빛의 속도는 초당 약 30만 km이지만, 실제 인터넷 통신에서는 라우터(Router) 경유, 해저 케이블 지연, 패킷 손실 등으로 인해 왕복 지연 시간(Round Trip Time, RTT) 이 크게 늘어난다.

경로	대략적인 RTT
서울 → 서울	1~5 ms
서울 → 도쿄	30~50 ms
서울 → 미국 서부	120~180 ms
서울 → 유럽	200~300 ms

웹 페이지 하나를 로드하려면 HTML, CSS, JavaScript, 이미지 등 수십 개의 파일을 요청해야 한다. 매 요청마다 200ms씩 지연되면, 전체 로딩 시간은 수 초 이상으로 늘어날 수 있다.

해결: CDN (Content Delivery Network)

CDN은 전 세계 여러 지역에 캐시 서버를 배치하여, 사용자가 가장 가까운 서버에서 콘텐츠를 받도록 하는 기술이다.

핵심 원리는 단순하다:

원본 데이터는 하나의 서버(오리진)에 저장한다.
전 세계 주요 도시에 캐시 서버(엣지 로케이션)를 배치한다.
사용자가 요청하면, 가장 가까운 엣지 로케이션에서 응답한다.
엣지에 데이터가 없으면(캐시 미스), 오리진에서 가져와 캐시한 뒤 응답한다.

비유: 서울에 본사가 있는 치킨 프랜차이즈를 생각해보자. 부산 고객이 주문하면 서울에서 배달하는 것이 아니라, 부산 지점에서 바로 배달한다. CDN의 엣지 로케이션이 바로 이 "지역 지점"에 해당한다.

CDN 없을 때 vs 있을 때 비교

CDN을 사용하면 전 세계 어디서든 비슷한 속도로 콘텐츠를 제공할 수 있다.

2. CloudFront란?

AWS의 CDN 서비스

CloudFront는 AWS가 제공하는 글로벌 CDN 서비스이다. 전 세계 400개 이상의 엣지 로케이션(Edge Location)을 통해 콘텐츠를 빠르게 전송한다.

핵심 구성 요소

구성 요소	설명	비유
오리진 (Origin)	원본 데이터가 저장된 곳. S3 버킷, EC2 인스턴스, ALB(Application Load Balancer), 또는 외부 HTTP 서버가 될 수 있다.	치킨 프랜차이즈의 본사 주방
엣지 로케이션 (Edge Location)	전 세계에 분산된 캐시 서버. 사용자 요청을 가장 가까운 위치에서 처리한다.	각 지역 가맹점
배포 (Distribution)	CloudFront 설정의 단위. 오리진, 캐시 정책, 도메인 등을 정의한다.	프랜차이즈 운영 계약서
캐시 (Cache)	엣지 로케이션에 임시 저장된 콘텐츠 복사본. TTL(Time To Live)에 따라 갱신된다.	지점에 미리 준비해둔 재료

CloudFront의 동작 원리

x-cache 헤더를 통해 캐시 히트 여부를 확인할 수 있다:

x-cache: Hit from cloudfront → 엣지 로케이션의 캐시에서 응답됨 (빠름)
x-cache: Miss from cloudfront → 오리진에서 가져온 응답 (상대적으로 느림, 이후 캐시됨)

CloudFront가 지원하는 오리진 유형

오리진 유형	사용 사례
S3 버킷	정적 웹사이트, 이미지, 동영상 파일 호스팅
EC2 인스턴스	동적 콘텐츠를 생성하는 웹 애플리케이션
ALB (Application Load Balancer)	여러 EC2 인스턴스에 분산된 애플리케이션
MediaStore / MediaPackage	라이브 스트리밍, VOD(Video on Demand)
커스텀 오리진 (Custom Origin)	AWS 외부의 HTTP 서버

3. 실습: S3 + CloudFront로 정적 웹사이트 배포

3-1단계: S3 버킷 생성 및 파일 업로드

AWS 콘솔 → S3 서비스로 이동한다.
버킷 만들기(Create bucket) 를 클릭한다.
- 버킷 이름: my-cloudfront-demo-<고유값> (전 세계에서 유일해야 한다)
- 리전(Region): 아시아 태평양(서울) ap-northeast-2
퍼블릭 액세스 차단 설정은 기본값으로 유지한다.
- S3 버킷은 비공개로 두고 CloudFront를 통해서만 접근하게 하는 흐름이 현재 기준의 안전한 기본값이다.
- CloudFront 배포를 만들 때 OAC(Origin Access Control) 를 설정해 S3 오리진에 서명된 요청으로 접근하게 한다.
참고: 예전 실습은 OAI(Origin Access Identity) 또는 퍼블릭 버킷 정책을 많이 사용했다. 새 구성에서는 OAC를 우선 검토하고, 퍼블릭 버킷은 학습용 데모처럼 의도가 분명한 경우에만 제한적으로 사용한다.
나머지 설정은 기본값으로 두고 버킷 만들기를 클릭한다.
생성된 버킷에 들어가서 index.html 파일을 업로드한다.

html

<!DOCTYPE html>
<html lang="ko">
<head>
    <meta charset="UTF-8">
    <title>CloudFront 실습</title>
</head>
<body>
    <h1>CloudFront CDN 실습 페이지</h1>
    <p>이 페이지는 S3에서 호스팅되고 CloudFront를 통해 전 세계에 배포됩니다.</p>
    <p>현재 시간 확인용: 2024-01-01</p>
</body>
</html>

업로드된 파일에는 퍼블릭 읽기 권한을 주지 않는다. CloudFront 배포 생성 후 OAC가 S3에 접근할 수 있도록 버킷 정책을 추가한다:

json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipalReadOnly",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-cloudfront-demo-<고유값>/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::<계정ID>:distribution/<배포ID>"
                }
            }
        }
    ]
}

3-2단계: CloudFront 배포 생성

AWS 콘솔 → CloudFront 서비스로 이동한다.
배포 생성(Create Distribution) 을 클릭한다.
오리진(Origin) 설정:
- 원본 도메인(Origin Domain): 드롭다운에서 앞서 만든 S3 버킷을 선택한다.
- S3 버킷을 선택하면 자동으로 my-cloudfront-demo-<고유값>.s3.ap-northeast-2.amazonaws.com 형태가 입력된다.
- Origin access에서 OAC를 생성하거나 기존 OAC를 선택한다.
기본 캐시 동작(Default Cache Behavior) 설정:
- 뷰어 프로토콜 정책(Viewer Protocol Policy): HTTP and HTTPS (실습이므로 HTTP도 허용)
- 나머지는 기본값으로 둔다.
설정(Settings) 영역:
- 기본 루트 객체(Default Root Object): index.html 을 입력한다.
- 이것을 입력하지 않으면 https://d1234.cloudfront.net/ 접속 시 404 오류가 발생한다.
배포 생성(Create Distribution) 을 클릭한다.
배포 상태(Status) 가 Deploying → Enabled로 변경될 때까지 기다린다. (보통 5~15분 소요)

3-3단계: 접속 확인

CloudFront 배포 목록에서 배포 도메인 이름(Distribution Domain Name) 을 확인한다.
- 예: d1a2b3c4d5e6f7.cloudfront.net
브라우저에서 해당 도메인으로 접속한다.
- https://d1a2b3c4d5e6f7.cloudfront.net
브라우저 개발자 도구(F12) → 네트워크(Network) 탭에서 응답 헤더를 확인한다.
- 첫 번째 접속: x-cache: Miss from cloudfront (오리진에서 가져옴)
- 새로고침(두 번째 접속): x-cache: Hit from cloudfront (캐시에서 응답)

접속 회차	x-cache 헤더 값	의미
1회차	`Miss from cloudfront`	엣지에 캐시가 없어서 오리진(S3)에서 가져옴
2회차 이후	`Hit from cloudfront`	엣지의 캐시에서 바로 응답 (빠름)

4. CloudFront 삭제 (비용 절감)

CloudFront 배포는 운영 중에 비용이 발생한다. 실습이 끝나면 반드시 삭제한다.

삭제 순서

CloudFront 배포는 바로 삭제할 수 없다. 반드시 비활성화(Disable)를 먼저 해야 한다.

단계	작업	소요 시간
1	CloudFront 배포 선택 → 비활성화(Disable) 클릭	즉시
2	상태가 `Disabled`로 변경될 때까지 대기	약 10~15분
3	상태가 `Disabled`가 되면 삭제(Delete) 버튼이 활성화됨	-
4	삭제(Delete) 클릭	즉시
5	S3 버킷도 필요 없으면 삭제 (객체 먼저 삭제 → 버킷 삭제)	즉시

주의: 비활성화 없이 삭제 버튼을 누르면 버튼이 비활성화(회색) 상태이다. 반드시 비활성화 → 대기 → 삭제 순서를 따른다.

Part 2: CloudWatch (모니터링 서비스)

1. CloudWatch란?

AWS의 CCTV + 알림 시스템

CloudWatch는 AWS 리소스의 상태를 실시간으로 모니터링하고, 이상 상황 발생 시 경보(Alarm)를 발생시키는 서비스이다.

쉽게 비유하면:

비유 대상	CloudWatch에서의 역할
CCTV 카메라	지표(Metric) 수집 - EC2의 CPU 사용률, 네트워크 트래픽 등을 지속적으로 관찰
경비원	경보(Alarm) - 이상 수치를 감지하면 알림을 보냄
비상 연락망	SNS(Simple Notification Service) - 이메일, SMS 등으로 담당자에게 알림 전달
CCTV 녹화 영상	로그(Log) - 과거 지표 데이터를 저장하여 나중에 분석 가능

CloudWatch의 3가지 핵심 기능

기능	설명
지표 (Metrics)	AWS 리소스의 수치 데이터를 시간 순서대로 수집. CPU 사용률, 디스크 I/O, 네트워크 트래픽 등.
경보 (Alarms)	지표가 설정한 임계값(Threshold)을 초과하면 자동으로 동작(Action)을 트리거.
로그 (Logs)	애플리케이션 로그, 시스템 로그 등을 중앙 집중식으로 수집하고 분석.

2. 모니터링 가능한 지표 (Metrics)

EC2 인스턴스의 주요 지표

CloudWatch는 EC2 인스턴스에 대해 다음과 같은 지표를 자동으로 수집한다 (기본 모니터링, 5분 간격).

지표 이름	설명	단위
CPUUtilization	CPU 사용률. 서버가 얼마나 바쁜지 나타냄.	% (퍼센트)
NetworkIn	인스턴스로 들어오는 네트워크 트래픽.	바이트(Bytes)
NetworkOut	인스턴스에서 나가는 네트워크 트래픽.	바이트(Bytes)
DiskReadOps	디스크 읽기 작업 횟수.	횟수(Count)
DiskWriteOps	디스크 쓰기 작업 횟수.	횟수(Count)
DiskReadBytes	디스크에서 읽은 데이터량.	바이트(Bytes)
DiskWriteBytes	디스크에 쓴 데이터량.	바이트(Bytes)
StatusCheckFailed	상태 확인 실패 여부. 인스턴스 또는 하드웨어에 문제가 있는지 감지.	0 또는 1

기본 모니터링 vs 상세 모니터링

구분	기본 모니터링 (Basic)	상세 모니터링 (Detailed)
수집 간격	5분	1분
비용	무료	유료 (인스턴스당 월 약 $3.50)
활성화	EC2 인스턴스 생성 시 기본 활성화	EC2 콘솔에서 수동 활성화 필요
용도	일반적인 모니터링	빠른 감지가 필요한 프로덕션 환경

비용 주의: 기본 모니터링은 무료이므로 실습에 추가 비용이 발생하지 않는다. 상세 모니터링은 유료이므로 실습에서는 활성화하지 않는다.

3. 경보 (Alarm) 설정

CloudWatch 알림 파이프라인

CloudWatch 경보의 전체 흐름은 다음과 같다.

CloudWatch 경보의 3가지 상태

경보(Alarm)는 항상 다음 세 가지 상태 중 하나에 있다.

상태	설명	색상 (콘솔)
OK	지표가 정상 범위 안에 있다. 임계값을 초과하지 않은 상태.	녹색
ALARM	지표가 임계값을 초과했다. 설정된 알림 동작이 실행된다.	빨간색
INSUFFICIENT_DATA	데이터가 부족하여 판단할 수 없다. 경보 생성 직후 또는 지표 수집이 중단된 경우.	회색

실습: 경보 설정 단계

AWS 콘솔 → SNS (Simple Notification Service) 로 이동한다.
토픽 생성(Create topic) 을 클릭한다.
- 유형: 표준(Standard)
- 이름: cpu-alarm-topic
- 토픽 생성 클릭
생성된 토픽에서 구독 생성(Create subscription) 을 클릭한다.
- 프로토콜: 이메일(Email)
- 엔드포인트: 본인 이메일 주소 입력
- 구독 생성 클릭
이메일 수신함을 확인하여 Confirm Subscription 링크를 클릭한다.

중요: 이메일 Confirm Subscription을 반드시 완료해야 한다. 확인하지 않으면 경보가 발생해도 이메일을 받을 수 없다. 스팸 폴더도 확인한다.

Step 2: CloudWatch 경보 생성

AWS 콘솔 → CloudWatch → 왼쪽 메뉴에서 경보(Alarms) → 모든 경보(All alarms) 클릭
경보 생성(Create alarm) 클릭
지표 선택(Select metric):
- EC2 → 인스턴스별 지표(Per-Instance Metrics) 클릭
- 모니터링할 EC2 인스턴스의 CPUUtilization 지표를 선택
- 지표 선택(Select metric) 클릭
조건(Conditions) 설정:
- 통계(Statistic): 평균(Average)
- 기간(Period): 1분
- 조건 유형: 정적(Static)
- 비교 연산자: 보다 큼(Greater than)
- 임계값: 50 (CPU 사용률 50% 이상이면 경보)
알림(Notification) 설정:
- 경보 상태 트리거: 경보 상태(In alarm)
- SNS 토픽: 앞서 만든 cpu-alarm-topic 선택
이름 및 설명:
- 경보 이름: high-cpu-alarm
- 설명: EC2 CPU 사용률 50% 초과 시 알림
경보 생성(Create alarm) 클릭

4. 실습: CPU 부하 테스트

목표

EC2 인스턴스에 인위적으로 CPU 부하를 발생시켜, CloudWatch 경보가 정상적으로 동작하는지 확인한다.

Step 1: EC2 인스턴스에 SSH 접속

bash

ssh -i my-key.pem ec2-user@<EC2-퍼블릭-IP>

Step 2: CPU 부하 발생

리눅스의 yes 명령어를 사용하여 CPU를 100% 사용하게 만든다.

bash

yes > /dev/null &

명령어 구성	설명
`yes`	"y"를 무한 반복 출력하는 명령어
`> /dev/null`	출력을 버린다 (화면에 표시하지 않음)
`&`	백그라운드에서 실행

yes 명령어가 실행되면 CPU 코어 하나를 100% 사용하게 된다.

참고: 여러 코어를 가진 인스턴스에서는 yes > /dev/null &를 코어 수만큼 실행해야 전체 CPU 사용률이 올라간다. t2.micro는 1 vCPU이므로 하나만 실행하면 충분하다.

CPU 사용률을 실시간으로 확인하려면:

bash

top

top 화면에서 CPU 사용률이 거의 100%에 가까운 것을 확인할 수 있다. q를 눌러 종료한다.

Step 3: 경보 발생 확인

약 1~5분 후, CloudWatch가 CPU 사용률 50% 초과를 감지한다.
경보 상태가 OK → ALARM으로 변경된다.
SNS를 통해 설정한 이메일 주소로 경보 알림 이메일이 도착한다.

이메일 내용에는 다음 정보가 포함된다:

경보 이름 (high-cpu-alarm)
경보 상태 변경 내용 (OK → ALARM)
어떤 지표가 어떤 임계값을 초과했는지
해당 EC2 인스턴스의 정보

Step 4: CPU 부하 중지 및 정상화

bash

# 백그라운드 yes 프로세스 확인
jobs

# 백그라운드 프로세스 종료
kill %1

# 또는 모든 yes 프로세스를 한꺼번에 종료
killall yes

또는 포그라운드에서 실행 중이라면 Ctrl+C로 종료한다.

CPU 부하가 제거되면:

CPU 사용률이 급격히 낮아진다.
CloudWatch가 임계값 이하를 감지한다.
경보 상태가 ALARM → OK로 복귀한다.
(정상화 알림을 설정했다면) 정상 복귀 이메일도 수신된다.

5. 경보 삭제 (정리)

실습이 끝나면 불필요한 리소스를 정리한다.

삭제 순서

순서	대상	삭제 방법
1	CloudWatch 경보	CloudWatch → 경보 → `high-cpu-alarm` 선택 → 삭제(Delete)
2	SNS 구독	SNS → 구독 → 해당 구독 선택 → 삭제(Delete)
3	SNS 토픽	SNS → 토픽 → `cpu-alarm-topic` 선택 → 삭제(Delete)
4	EC2 인스턴스	(다른 실습에서 사용하지 않는다면) EC2 → 인스턴스 → 종료(Terminate)

참고: CloudWatch 기본 모니터링 자체는 무료이므로 경보만 삭제하면 추가 비용이 발생하지 않는다.

비용 정리

서비스	무료 범위	유료 시점	실습 후 조치
CloudFront	매월 1TB 데이터 전송, 1,000만 HTTP/S 요청 (12개월 프리 티어)	프리 티어 초과 시, 또는 12개월 이후	반드시 비활성화 + 삭제
CloudWatch	기본 모니터링 (5분 간격), 경보 10개, 지표 10개 등	상세 모니터링, 경보/지표 초과 시	경보 삭제 권장
SNS	매월 이메일 1,000건 등	무료 한도 초과 시	토픽/구독 삭제 권장
S3	5GB 스토리지, 2만 GET, 2천 PUT (12개월 프리 티어)	프리 티어 초과 시	실습 파일/버킷 삭제 권장

핵심 요약

CloudFront 핵심 정리

항목	내용
정체	AWS의 CDN(Content Delivery Network) 서비스
목적	전 세계 사용자에게 빠른 콘텐츠 전송
동작 원리	오리진(S3 등) → 엣지 로케이션에 캐시 → 가까운 엣지에서 응답
캐시 확인	응답 헤더의 `x-cache` 값으로 Hit/Miss 확인
삭제 순서	비활성화(Disable) → 대기(10분) → 삭제(Delete)

CloudWatch 핵심 정리

항목	내용
정체	AWS 리소스 모니터링 + 경보 서비스
3대 기능	지표(Metrics), 경보(Alarms), 로그(Logs)
경보 상태	OK → ALARM → OK (또는 INSUFFICIENT_DATA)
알림 흐름	지표 수집 → 임계값 비교 → SNS → 이메일/SMS
비용	기본 모니터링 무료, 상세 모니터링 유료

06. CloudFront와 CloudWatch ​

학습 목표 ​

전체 구조 ​

Part 1: CloudFront (CDN 서비스) ​

1. CDN이란? ​

문제 상황: 물리적 거리의 한계 ​

해결: CDN (Content Delivery Network) ​

CDN 없을 때 vs 있을 때 비교 ​

2. CloudFront란? ​

AWS의 CDN 서비스 ​

핵심 구성 요소 ​

CloudFront의 동작 원리 ​

CloudFront가 지원하는 오리진 유형 ​

3. 실습: S3 + CloudFront로 정적 웹사이트 배포 ​

3-1단계: S3 버킷 생성 및 파일 업로드 ​

3-2단계: CloudFront 배포 생성 ​

3-3단계: 접속 확인 ​

4. CloudFront 삭제 (비용 절감) ​

삭제 순서 ​

Part 2: CloudWatch (모니터링 서비스) ​

1. CloudWatch란? ​

AWS의 CCTV + 알림 시스템 ​

CloudWatch의 3가지 핵심 기능 ​

2. 모니터링 가능한 지표 (Metrics) ​

EC2 인스턴스의 주요 지표 ​

기본 모니터링 vs 상세 모니터링 ​

3. 경보 (Alarm) 설정 ​

CloudWatch 알림 파이프라인 ​

CloudWatch 경보의 3가지 상태 ​

실습: 경보 설정 단계 ​

Step 1: SNS 토픽 생성 및 이메일 구독 ​

Step 2: CloudWatch 경보 생성 ​

4. 실습: CPU 부하 테스트 ​

목표 ​

Step 1: EC2 인스턴스에 SSH 접속 ​

Step 2: CPU 부하 발생 ​

Step 3: 경보 발생 확인 ​

Step 4: CPU 부하 중지 및 정상화 ​

5. 경보 삭제 (정리) ​

삭제 순서 ​

비용 정리 ​

핵심 요약 ​

CloudFront 핵심 정리 ​

CloudWatch 핵심 정리 ​

06. CloudFront와 CloudWatch

학습 목표

전체 구조

Part 1: CloudFront (CDN 서비스)

1. CDN이란?

문제 상황: 물리적 거리의 한계

해결: CDN (Content Delivery Network)

CDN 없을 때 vs 있을 때 비교

2. CloudFront란?

AWS의 CDN 서비스

핵심 구성 요소

CloudFront의 동작 원리

CloudFront가 지원하는 오리진 유형

3. 실습: S3 + CloudFront로 정적 웹사이트 배포

3-1단계: S3 버킷 생성 및 파일 업로드

3-2단계: CloudFront 배포 생성

3-3단계: 접속 확인

4. CloudFront 삭제 (비용 절감)

삭제 순서

Part 2: CloudWatch (모니터링 서비스)

1. CloudWatch란?

AWS의 CCTV + 알림 시스템

CloudWatch의 3가지 핵심 기능

2. 모니터링 가능한 지표 (Metrics)

EC2 인스턴스의 주요 지표

기본 모니터링 vs 상세 모니터링

3. 경보 (Alarm) 설정

CloudWatch 알림 파이프라인

CloudWatch 경보의 3가지 상태

실습: 경보 설정 단계

Step 1: SNS 토픽 생성 및 이메일 구독

Step 2: CloudWatch 경보 생성

4. 실습: CPU 부하 테스트

목표

Step 1: EC2 인스턴스에 SSH 접속

Step 2: CPU 부하 발생

Step 3: 경보 발생 확인

Step 4: CPU 부하 중지 및 정상화

5. 경보 삭제 (정리)

삭제 순서

비용 정리

핵심 요약

CloudFront 핵심 정리

CloudWatch 핵심 정리