CloudFront + Lambda@Edge to Cloudflare Worker + R2 PoC

들어가며

안녕하세요, 백엔드 개발자 이찬희입니다. 이번 글에서는 저희가 운영 중인 AWS 미디어 스택(CloudFront + S3 + Lambda@Edge + MediaConvert)을 Cloudflare 스택(Worker + R2 + Stream)으로 옮길 수 있을지 검토한 4-Stage PoC 과정을 정리합니다. 결론부터 말씀드리면, 이미지·일반 VOD 영역은 충분히 옮길 만하고 4K·AES-128 암호화가 필요한 영역은 MediaConvert를 유지하는 하이브리드 구조가 가장 합리적이라고 판단했습니다.

TL;DR

• 호환성: R2는 S3 SDK를 그대로 사용할 수 있었고, Worker는 Lambda@Edge가 하던 일(쿠키 발급, Cache-Control 설정)을 그대로 대체할 수 있었습니다.
• 이득: R2 앞에 Worker를 붙이는 구조에서는 캐시 Hit 여부와 무관하게 모든 요청에 Worker가 실행됩니다. 다만 Worker는 요청 수와 CPU 연산 시간 기준으로 과금되어 단가가 매우 낮고, egress 비용이 0원이라는 점과 캐시 정책을 잘 설계하면 R2 접근 자체를 줄일 수 있다는 점에서 비용 효율적인 구조입니다.
• 한계: Cloudflare Stream은 MediaConvert가 제공하던 세밀한 인코딩 제어(비트레이트, GOP, B-Frame, AES-128, 4K 등)를 대부분 지원하지 않습니다. 설정 항목 기준으로 약 30%만 호환됩니다.
• 결론: 일반 VOD/이미지는 Cloudflare로 옮길 만합니다. 4K·AES-128이 필수인 프리미엄 콘텐츠는 MediaConvert를 유지하는 하이브리드 구조로 가기로 했습니다.

---

1. 왜 옮기려 했나

가장 큰 이유는 비용이었습니다

2025년 9월 기준 저희의 AWS 미디어 스택 청구서를 뜯어보니, 총 비용의 90% 이상이 CloudFront Egress(데이터 전송) 비용이었습니다. 같은 사용량을 Cloudflare로 환산했을 때 예상되는 절감률은 다음과 같았습니다.

항목	절감률
데이터 전송 (Egress)	100% (무제한)
스토리지 (S3 → R2)	34%
Edge Function (Lambda@Edge → Workers)	약 35%
API 요청 (PUT/GET)	10%
전체 합계	약 92%

핵심은 Cloudflare의 무제한 Egress 정책입니다. CloudFront는 GB당 과금이 발생하지만 Cloudflare는 데이터 전송 비용 자체가 0이기 때문에, 트래픽이 늘어날수록 격차는 더 벌어지는 구조였습니다. 부수적으로 R2 스토리지가 S3 대비 약 34% 저렴하고, Workers는 월 300만 요청까지 무료로 제공되어 Lambda@Edge 대비 추가 절감 여지도 있었습니다.

옮기려면 함께 풀어야 할 숙제들

기존 스택은 전형적인 AWS 구성이었습니다.

Client
  → CloudFront (CDN + Signed Cookies 검증)
    → Behaviors (경로별 라우팅)
      → S3 (스토리지)
        → Lambda@Edge (응답 헤더 추가)
          → Client

영상은 MediaConvert로 인코딩하여 S3에 적재하고, 접근 제어는 CloudFront Signed Cookies 3종 세트(Policy/Signature/Key-Pair-Id)로 처리합니다. 현재 구조 자체는 잘 동작하지만, Cloudflare로 옮긴다고 가정하면 비용 외에도 다음 세 가지를 함께 검토해야 했습니다.

1. CloudFront 락인을 어떻게 풀 것인가. Signed Cookies는 CloudFront 전용 메커니즘이라, CDN을 교체하려면 인증 로직 자체를 새로 설계해야 합니다.
2. Lambda@Edge가 하던 일을 Worker가 대체할 수 있는가. 현재 Lambda@Edge는 특정 경로 요청에 대해 인증용 쿠키를 Set-Cookie로 발급하고, 그 외 응답에는 사내 정책에 맞는 Cache-Control 헤더를 부여하는 역할을 합니다. Worker 모델에서도 이 두 동작(경로 기반 쿠키 발급 + 응답 헤더 가공)을 동일하게 구현할 수 있는지 확인이 필요했습니다.
3. MediaConvert 워크플로우(12단계)를 Stream으로 옮길 수 있는가. 현재는 presigned URL 발급부터 S3 업로드, S3 Event → Lambda → MediaConvert Job → EventBridge → DB 업데이트까지 단계가 길게 이어집니다. Stream으로 단순화할 수 있다면 이득이 크지만, 인코딩 옵션 호환성을 먼저 확인해야 했습니다.

그래서 저희가 검증하고 싶었던 것은 Cloudflare로 옮기면 비용도 잡고 이 세 가지 문제도 함께 풀 수 있는가였습니다.

---

2. 무엇을 검증해야 했나 — 사전 조사

2-1. 접근 제어: Signed Cookies를 다른 방식으로 대체할 수 있을까

CloudFront Signed Cookies는 CloudFront 전용 메커니즘이라, CDN을 옮긴다면 인증 방식도 새로 선택해야 합니다. PoC 단계에서는 후보로 JWT 기반 검증을 가정해두고 비교만 해봤습니다. 어떤 토큰/검증 방식을 최종적으로 채택할지는 별도 설계 검토가 필요합니다.

항목	CloudFront + Signed Cookies	Cloudflare + 토큰 기반(예: JWT 가정)
검증 주체	CloudFront 내부 (자동)	Worker 코드 (매 요청)
토큰 구성	3개 쿠키 (Policy/Signature/Key-Pair-Id)	단일 토큰 가정
권한 제어	제한적	Worker 로직에 따라 설계 자유도 높음
캐시 위치	CloudFront Cache → Origin → Lambda@Edge	Cloudflare Cache → Worker → R2

2-2. Lambda@Edge viewer_response는 정확히 어떤 일을 하고 있었는가

기존 Lambda@Edge 코드를 분석해보니, 실제로 수행하는 작업은 응답 헤더를 손보는 두 가지 작업이 전부였습니다.

1. 특정 경로에 대한 쿠키 발급 — 인증용 쿠키를 Set-Cookie 헤더로 발급하는 작업.
2. 그 외 모든 응답에 대한 캐시 정책 부여 — 사용자별 권한이 다른 콘텐츠라 CDN/프록시 단의 공유 캐싱은 차단하고, 브라우저 단에서만 캐싱이 유지되도록 하는 정책.

기능적으로는 이 두 가지가 전부였습니다. 비용 자체는 크지 않더라도, 매 응답마다 함수가 한 번씩 실행된다는 구조 자체가 비효율적이라고 판단했습니다.

2-3. MediaConvert를 Cloudflare Stream으로 어디까지 옮길 수 있는가

이 부분에서 가장 많은 제약이 발견되었습니다. 현재 MediaConvert에서 사용 중인 설정 약 20개 중 Cloudflare Stream과 호환되는 항목은 6개 정도, 비율로는 약 30% 수준이었습니다.

호환 가능한 항목

• H.264 / AAC 코덱
• 360p / 720p / 1080p 해상도
• HLS 출력
• 세로 영상 자동 처리, 업스케일 방지, 인터레이싱 제거

호환 불가능한 항목

• 4K(2160p) — Stream은 최대 1080p까지만 지원합니다.
• 비트레이트 수동 설정 — Stream은 ABR(Adaptive Bitrate) 자동 방식만 지원합니다.
• Quality Level, GOP, B-Frames, Codec Profile, Adaptive Quantization — 모두 자동 설정만 가능합니다.
• HLS Segment 길이 — 자동 설정만 지원됩니다.
• AES-128 Segment 암호화 — Signed URLs 방식만 지원하고, 세그먼트 단위 암호화는 불가능합니다.
• Multi-Pass Encoding, Scene Change Detection, HRD Buffer

대신 워크플로우는 매우 단순해집니다.

MediaConvert: 12단계 (Lambda 3개 + S3 2개 + MediaConvert + EventBridge)
Stream:        5단계 (Stream API 단일)

결국 의사결정의 핵심은 세밀한 인코딩 제어를 Stream의 자동 최적화에 위임할 수 있는가였습니다.

---

3. PoC 4-Stage

Stage 1. R2 기본 연결

가장 먼저 테스트용 R2 버킷을 생성하고, Public Development URL을 활성화한 뒤 이미지 한 장을 업로드해보았습니다. 결과적으로 S3와 동일한 방식으로 동작했습니다. 다만 Cache-Control 헤더를 커스터마이징하려면 Worker가 필요합니다.

Stage 2. S3 SDK가 R2를 그대로 다룰 수 있는가

이 단계의 핵심은 API 한 줄만 변경해도 기존 코드가 깨지지 않는가였습니다.

// 기존 S3 클라이언트에서 endpoint만 변경
const r2 = new S3Client({
    endpoint: `https://${ACCOUNT_ID}.r2.cloudflarestorage.com`,
    // ... credentials 등은 동일
});
await r2.send(new PutObjectCommand({ ... }));

• @aws-sdk/client-s3를 그대로 사용할 수 있습니다.
• PutObjectCommand, Presigned URL 모두 정상 동작합니다.
• 검증된 엔드포인트: Base64 업로드 / 프론트 직접 업로드용 presigned URL 발급 / 파일 조회 모두 정상.

추가로 Custom Domain을 연결해 자체 도메인으로도 서빙이 되는지 확인했고, CORS는 로컬 개발 환경과 dev API 도메인만 화이트리스트에 추가했습니다.

결과적으로 기존 S3 코드를 거의 수정하지 않고도 R2로 전환이 가능했습니다. SDK, 인증 방식, 명령어 체계가 모두 동일합니다.

Stage 3. Worker가 Lambda@Edge를 완전히 대체할 수 있는가

Worker 한 파일로 Lambda@Edge의 두 가지 역할(쿠키 발급, 파일 서빙)을 모두 구현했습니다. 핵심 흐름만 추린 의사 코드는 다음과 같습니다.

async function handleSetCookie(request) {
  const url = new URL(request.url);
  const cookies = [];
  const domain = COOKIE_DOMAIN;

  for (const [key, value] of url.searchParams) {
    cookies.push(`${key}=${value}; Domain=${domain}; SameSite=None; Secure`);
  }

  return new Response("Cookies set successfully", {
    status: 200,
    headers: {
      "Set-Cookie": cookies.join(", "),
      "Cache-Control": "no-cache, no-store, must-revalidate",
      "Content-Type": "text/plain",
    },
  });
}

async function handleFileServing(request, env) {
  const url = new URL(request.url);
  const key = url.pathname.slice(1);

  const object = await env.MY_BUCKET.get(key, {
    range: request.headers.has("Range")
      ? request.headers.get("Range")
      : undefined,
  });
  if (!object) return new Response("Not Found", { status: 404 });

  const headers = new Headers();
  headers.set(
    "Content-Type",
    object.httpMetadata.contentType || "application/octet-stream"
  );
  if (object.etag) headers.set("ETag", object.etag);
  headers.set("Cache-Control", CACHE_POLICY); // 사내 정책에 맞춰 설정
  headers.set("Access-Control-Allow-Origin", ALLOWED_ORIGIN);
  headers.set("Access-Control-Allow-Methods", "GET, HEAD, OPTIONS");
  headers.set("Access-Control-Allow-Headers", "Range");

  if (request.headers.has("Range")) {
    headers.set("Content-Range", object.range);
    return new Response(object.body, { status: 206, headers });
  }
  return new Response(object.body, { status: 200, headers });
}

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.pathname === COOKIE_PATH) return handleSetCookie(request, env);
    return handleFileServing(request, env);
  },
};

MY_BUCKET은 Worker에 R2 바인딩으로 연결한 변수입니다. 별도의 키 관리 없이 R2를 마치 메모리 객체처럼 다룰 수 있다는 점이 인상적이었습니다.

검증: Cache-Control 헤더

이미지 요청에 대해 Lambda@Edge가 부여하던 것과 동일한 캐시 정책 헤더가 응답에 정상적으로 부여되는 것을 확인했습니다.

$ curl -I https://<worker-domain>/<path>
HTTP/2 200
content-type: image/png
cache-control: <기존 Lambda@Edge와 동일한 정책>
etag: <hash>
access-control-allow-origin: <허용 Origin>

검증: 쿠키 발급 경로

기존 Signed Cookies 3종이 동일한 형식으로 발급되는 것을 확인했습니다.

$ curl -v "https://<worker-domain>/<cookie-path>?Policy=xxx&Signature=yyy&Key-Pair-Id=zzz"
HTTP/2 200
set-cookie: Policy=xxx; Domain=<cdn-domain>; SameSite=None; Secure,
            Signature=yyy; Domain=<cdn-domain>; SameSite=None; Secure,
            Key-Pair-Id=zzz; Domain=<cdn-domain>; SameSite=None; Secure
cache-control: no-cache, no-store, must-revalidate

쿠키 3개가 기존과 동일한 형식으로 정상 발급되는 것을 확인했습니다. Range 요청(206 Partial Content)도 정상적으로 처리되어 HLS 스트리밍에도 문제가 없었습니다.

Lambda@Edge와 Worker의 기능 매핑

기능	Lambda@Edge	Worker	결과
쿠키 발급 경로	✅	✅	동일
파일 서빙	✅	✅	동일
Cache-Control	✅	✅	동일
Range 요청	✅	✅	동일
더미 파일 필요	S3에 더미 오브젝트 필요	불필요	Worker가 더 간단
접근 제어	Signed Cookies	코드로 커스텀	Worker가 더 유연

쿠키 발급용 더미 파일에 대해 잠깐 부연 설명을 드리자면, CloudFront에서 Lambda@Edge viewer_response는 origin이 한 번 응답을 반환해야 실행되는 구조입니다. 그래서 S3에 빈 더미 오브젝트를 두고 이를 트리거로 활용하고 있었습니다. Worker는 origin이 자기 자신이기 때문에 더미 파일이 필요하지 않습니다. 작은 차이처럼 보이지만, 운영 관점에서는 “S3에 의미 없는 파일 하나가 항상 존재해야 한다”는 부담이 사라지는 것이라 꽤 의미 있는 개선이었습니다.

Stage 3.5. 접근 제어 — Worker에서 직접 검증

이 단계는 어디까지나 “Worker 내에서 임의의 인증 로직을 끼워 넣을 수 있는가” 만 확인하기 위한 PoC였습니다. 따라서 JWT 같은 실제 토큰 검증을 구현하지 않고, “특정 값이 Cookie에 포함되어 있으면 통과” 정도로만 단순화했습니다. 실제 도입 시 어떤 토큰/검증 방식을 사용할지는 별도 설계가 필요합니다.

# (1) public 이미지 → 200
$ curl https://<worker-domain>/<public-path> -I
HTTP/2 200
cache-control: <사내 캐시 정책>

# (2) private 이미지, 쿠키 없음 → 401
$ curl https://<worker-domain>/<private-path>
Unauthorized: No token provided

# (3) private 이미지, 잘못된 쿠키 → 401
$ curl https://<worker-domain>/<private-path> -H "Cookie: access_token=<invalid>"
Unauthorized: Invalid token

# (4) private 이미지, 올바른 쿠키 → 200
$ curl https://<worker-domain>/<private-path> -H "Cookie: access_token=<valid>" -I
HTTP/2 200

기존 구조와 가장 큰 차이는 검증 주체입니다. 기존에는 백엔드가 발급한 Signed Cookies를 클라이언트가 저장한 뒤, 매 이미지 요청마다 함께 전송하는 방식이었습니다. Worker 방식에서는 검증 로직 자체를 저희가 직접 구성할 수 있기 때문에, 어떤 권한 모델(사용자 단위, 경로 단위, 만료 시간 등)로 가져갈지를 비교적 자유롭게 설계할 수 있습니다. 다만 구체적인 토큰 포맷과 검증 정책은 PoC 이후 별도 설계 단계에서 정할 예정입니다.

Stage 4. 크로스 도메인 쿠키

PoC 과정에서 가장 많은 시간을 소비한 부분입니다. 프론트 도메인과 CDN 도메인이 분리되어 있는 구조이기 때문에, 쿠키를 정상적으로 발급하고 전송하려면 충족해야 할 조건이 까다로웠습니다.

프론트 호출 코드

async function setCookie() {
  const token = document.getElementById("jwtToken").value.trim();
  await fetch(`${WORKER_URL}/<cookie-path>?token=${token}`, {
    method: "GET",
    credentials: "include", // ★ 크로스 도메인 쿠키 전송/저장 허용
    mode: "cors",
  });
}

async function testFileAccess() {
  await fetch(`${WORKER_URL}/<private-path>`, {
    credentials: "include", // ★ 쿠키 자동 전송
  });
}

Worker 응답 헤더 예시

Set-Cookie: auth_token=<token>; Domain=<worker-domain>;
            Path=/; SameSite=None; Secure; HttpOnly
Access-Control-Allow-Origin: <요청 Origin>
Access-Control-Allow-Credentials: true

구현 시 주의할 점 네 가지

1. credentials: 'include' 양쪽 모두 설정 필요 — 프론트의 fetch 호출과 Worker의 CORS 응답 헤더 양쪽에 모두 명시해야 합니다. 한쪽이라도 빠뜨리면 쿠키가 사라집니다.
2. Access-Control-Allow-Origin: * 사용 불가 — credentials 모드에서는 와일드카드가 허용되지 않습니다. 요청 Origin을 그대로 응답에 담아 반환해야 합니다.
3. SameSite=None이면 Secure 속성 필수 — 크로스 사이트 쿠키 전송은 HTTPS 환경에서만 가능합니다.
4. 브라우저 캐시 유의사항 — 쿠키가 유효한 상태에서 한 번 받은 이미지는 사내 캐시 정책에 따라 브라우저에 장기간 캐싱됩니다. 따라서 쿠키를 삭제한 뒤 다시 요청하더라도 Worker까지 도달하지 못하고 브라우저 캐시에서 응답이 반환됩니다. DevTools의 Disable cache 옵션을 켜지 않고 테스트하면 401이 발생하지 않아 “인증이 제대로 걸리지 않는 것 같다”는 잘못된 결론에 도달할 수 있습니다. 시크릿 모드를 사용하는 것이 가장 빠른 해결 방법이었습니다.

의도된 실패 케이스도 정상적으로 잡혔습니다.

[11:31:00] 인증 없이 접근 테스트 (쿠키 없음)
[11:31:01] 예상대로 401 Unauthorized
[11:31:01] Response: Unauthorized: No token provided

---

4. 한계와 트레이드오프

MediaConvert를 완전히 대체할 수는 없었습니다.

설정 호환률이 30% 수준이기 때문에, 다음 두 케이스는 MediaConvert를 유지해야 합니다.

• 4K 영상이 필요한 경우 (Stream은 1080p가 상한입니다)
• AES-128 세그먼트 암호화가 필요한 경우 (Stream은 Signed URL만 지원합니다)

반대로 1080p 일반 VOD에 해당한다면 Stream으로 충분히 옮길 수 있고, 인프라 단계가 12단계에서 5단계로 줄어듭니다. 비용은 80~95% 절감이 가능할 것으로 예상하고 있지만, 정확한 수치는 실제 트래픽 기반으로 다시 검증이 필요합니다.

---

5. 결론

영역	결정
스토리지 (S3 → R2)	이전 가능. SDK 그대로 활용, endpoint만 변경
접근 제어 (Signed Cookies → 토큰 기반)	이전 가능성 확인. Worker에서 임의의 검증 로직 구성 가능 (실제 토큰/정책은 별도 설계 필요)
Edge 함수 (Lambda@Edge → Worker)	이전 권장. Worker는 매 요청 실행되지만 단가가 낮고, egress 0원 + 캐시 정책으로 비용 우위
인코딩 (MediaConvert → Stream)	하이브리드. 일반 VOD는 Stream, 4K/AES 콘텐츠는 MediaConvert 유지
라이브 방송 원본	검토 중. Brightcove에서 R2로의 저장 경로 미해결

다음 단계는 프론트 개발서버 코드를 수정하여 실제 영상 재생 흐름을 끝까지 통과시키는 것입니다. 이 검증이 마무리되면 신규 콘텐츠부터 Cloudflare 라인으로 흘려보낼 계획이며, 기존 자산 마이그레이션은 그 이후에 별도로 검토할 예정입니다.

---

마치며

이번 PoC를 통해 “AWS 미디어 스택을 Cloudflare로 옮길 수 있는가”라는 질문에 대해 어느 정도 명확한 답을 얻을 수 있었습니다. 비용 측면의 임팩트가 크다는 점이 가장 큰 수확이었고, 동시에 Cloudflare Stream의 인코딩 제약처럼 옮길 수 없는 영역도 분명히 존재한다는 점을 확인할 수 있었습니다. 모든 것을 한 번에 옮기기보다는, 비용 효과가 가장 큰 영역부터 단계적으로 전환하면서 4K·AES-128 같은 특수 요구사항은 기존 스택을 유지하는 하이브리드 구조가 현실적인 답이라고 판단했습니다.