Cloudflare로 구축하는 글로벌 웹 인프라

DNS·TLS·CDN·WAF·Zero Trust·Workers·R2·Queues·D1 운영 실전

Cloudflare edge와 기존 origin을 안전하게 통합한다.

상태: 출간 후보 웹교정쇄 · 자동 QA 통과 · Cloudflare 현장 감수 대기 · 25개 장

DNS·TLS·CDN·WAF·Zero Trust·Workers·R2·Queues·D1 운영 실전

기준일: 2026-08-14 · 상태: 출간 후보 웹교정쇄 · 자동 QA 후 사람 현장 감수 대기

FieldPass를 Cloudflare edge와 기존 AWS origin에 안전하게 연결하고 성능·보안·복구·비용을 검증한다. 대상 독자는 Cloudflare DNS는 써봤지만 제품 간 연결과 장애·원복·요금제 선택이 막막한 웹·인프라 개발자다. 기능을 따라 입력하는 데서 끝내지 않고 결정의 전제, 실패, 증거와 rollback을 한 세트로 남긴다. 숫자·한도·가격·UI는 영구 사실이 아니며 실습 직전 공식 문서를 다시 확인한다.

FieldPass는 방문 예약, 기사 배정, 사진, 결제와 정산을 가진 합성 B2B 서비스다. 여섯 권이 같은 tenant-demo, res-demo-101, run-demo-001을 사용한다. 따라서 도메인 결정이 API, telemetry, infrastructure, event와 edge에서 같은 의미인지 비교할 수 있다.

npm run test로 여섯 위험 fixture를 실행한다.
npm run build로 원고와 SVG를 재생성한다.
lab/public/index.html을 열어 입력·판정·증거·원복을 같은 화면에 기록한다.
실제 cloud·domain 적용은 소유자 승인, 비용 상한과 별도 staging에서만 한다.


cd fieldpass-platform
npm run qa
npm start

먼저 version 9로 의도한 실패와 Problem Details를 확인하고 새 process에서 version 1로 성공·Outbox 대사를 실행한다. 실제 cloud·domain 변경은 소유자 승인과 비용 상한이 있는 staging에서만 한다.


{"name":"fieldpass-edge","main":"src/index.ts","compatibility_date":"2026-08-14","placement":{"mode":"smart"},"observability":{"enabled":true}}


GET /assets/* -> eligible
GET /api/* -> bypass
Authorization present -> bypass
POST * -> bypass


edgeDecision({path:'/admin',method:'GET',rate:1,limit:10}); // DENY


node --test test/platform-lab.test.mjs

먼저 실제 계정에 로그인하지 않는다. fieldpass-platform에서 npm run verify:worker를 실행하면 Wrangler 4.123.0이 src/edge.mjs를 실제 Worker bundle로 만들고 배포 직전 종료한다. 예상 출력은 --dry-run: exiting now다. 이 단계에서 계정 ID, zone ID와 API token은 필요하지 않다.

edge.test.mjs는 세 가지 사고를 막는다. Access assertion 없는 /admin은 403, Authorization header가 있는 asset은 cache bypass, hash asset의 익명 GET만 cache 후보여야 한다. 테스트를 통과해도 실제 Cloudflare Cache Rules가 같은 정책이라는 뜻은 아니다. dashboard 또는 IaC rule과 application test를 대사해야 한다.

이전 48시간 전에 authoritative zone에서 A·AAAA·CNAME·MX·TXT·CAA·SRV와 TTL을 export한다. web record만 옮기지 않는다. 각 record에 owner, 목적, proxied 여부, 예상 응답과 rollback을 붙인다. DNSSEC가 켜져 있다면 registrar의 DS 제거·추가 순서를 Cloudflare 공식 안내와 registrar 정책에서 확인한다. 순서를 잘못 지키면 정상 record도 검증 실패가 된다.

전환 직전 서로 다른 resolver에서 SOA serial, NS, CAA와 mail record를 확인한다. 전환 후에는 dig +trace 결과만 보지 않고 실제 browser, API, mail, OAuth callback과 certificate validation을 시험한다. rollback은 nameserver를 되돌리는 한 줄이 아니다. 이전 provider zone이 살아 있고 최신 record 변경을 포함하는지 먼저 확인한다.

방문자→Cloudflare와 Cloudflare→origin은 별도 TLS 연결이다. origin에는 hostname과 일치하고 만료되지 않은 공개 CA 또는 Origin CA 인증서를 둔다. 다음 명령은 실제 승인 staging hostname으로 바꾸되 key나 token을 출력하지 않는다.


openssl s_client -connect origin.example.invalid:443 \
  -servername staging.example.invalid -showcerts </dev/null
curl -sSvo /dev/null https://staging.example.invalid/health

526이면 certificate chain, SAN, SNI와 origin 시간을 확인한다. Flexible로 낮춰 증상을 숨기지 않는다. redirect loop면 origin이 받은 scheme과 trusted proxy header를 확인한다. 인증서 교체는 새 chain 설치, local SNI 검증, 한 instance canary, 전체 전환, 구 key 폐기 순서로 진행한다.

FieldPass cache matrix의 정답은 다음처럼 시작한다. /assets/app.<hash>.js는 public·immutable 후보, /api/**, Authorization·session cookie가 있는 요청, tenant별 HTML과 signed download는 bypass다. 먼저 Cache-Control만 사용하고 실제 CF-Cache-Status, Age, ETag, 응답 body hash를 기록한다.

두 tenant로 같은 URL을 요청해 body hash가 섞이지 않는지 확인한다. 배포 때 purge everything을 기본값으로 쓰지 않고 변경된 URL 또는 cache tag를 사용한다. purge 직후 MISS가 origin을 압박할 수 있으므로 요청률과 origin connection 중단선을 둔다. HIT 비율이 올라도 stale 예약이나 권한 노출이 한 건이면 실패다.

Managed Rules와 custom rule의 phase, Skip과 종료 action을 먼저 그린다. 첫 배포는 가능한 plan에서 log 또는 좁은 canary로 하고 rule ID, path, method, client class, false positive를 수집한다. payment webhook과 monitoring처럼 합법 자동 client를 User-Agent만으로 허용하지 않는다. signature, service token, mTLS 같은 강한 신호를 사용한다.

Rate Limiting은 정확한 quota가 아니다. edge counter 반영 전 초과 요청이 origin에 도달할 수 있으므로 application의 tenant quota와 함께 쓴다. 429에는 Retry-After와 jitter backoff를 제공한다. login, 검색, 파일 변환은 비용과 abuse 특성이 다르므로 하나의 IP limit을 복사하지 않는다.

cloudflared connector를 두 failure domain에 두고 outbound-only 연결, update와 credential rotation을 운영한다. Tunnel 연결 뒤 origin security group이나 firewall에서 직접 public ingress를 닫고 DNS-only hostname·과거 IP·load balancer 주소로 우회가 가능한지 negative test한다.

Access policy는 Include만으로 끝내지 않고 Require MFA·device posture·group과 session duration을 검토한다. machine 호출은 사람 IdP login 대신 Service Auth를 사용한다. broad Bypass는 Access enforcement를 제거하므로 owner와 만료 없는 규칙을 차단한다. IdP 장애를 위한 break-glass는 별도 강한 인증, 짧은 만료와 사후 감사를 가진다.

사진 원본은 R2, 비동기 검사 요청은 Queues, 예약 슬롯 coordination은 Durable Objects, 작은 edge read model은 D1 후보로 둔다. 제품 이름이 아니라 consistency, ordering, data location, backup, operation cost와 복구 원천으로 선택한다. R2 성공 뒤 application metadata가 실패할 수 있고 Queues delivery는 순서가 보장되지 않으므로 checksum·eventId·version과 대사가 필요하다.

Durable Object 하나에 모든 tenant를 넣지 않는다. 예약 슬롯처럼 직렬화해야 하는 key 단위로 identity를 정하고 hot

1장. Cloudflare를 제품 목록이 아닌 경로로 본다
2장. 요금제와 한도를 설계 입력으로 둔다
3장. DNS 이전을 가역적으로 수행한다
4장. TLS는 방문자와 Origin 두 구간이다
5장. Cache key가 correctness를 결정한다
6장. TTL과 purge를 배포 계약으로 만든다
7장. Tiered Cache와 Origin 보호를 측정한다
8장. WAF는 log에서 차단으로 단계화한다
9장. Rate Limiting을 정밀 quota로 오해하지 않는다
10장. Bot·DDoS 보호의 예외를 통제한다
11장. Cloudflare Tunnel로 Origin 노출을 줄인다
12장. Access와 Zero Trust 정책을 최소 권한으로 만든다
13장. WARP·Gateway는 사용자 장치 수명주기다
14장. Workers를 Edge Adapter로 사용한다
15장. Smart Placement의 latency 거래를 이해한다
16장. Service Binding으로 내부 호출을 숨긴다
17장. 데이터 제품을 접근 패턴으로 고른다
18장. R2 업로드를 안전하게 만든다
19장. Queues는 순서를 보장하지 않는다
20장. Durable Objects는 coordination에 쓴다
21장. D1·기존 DB의 역할을 구분한다
22장. 관측과 Logpush를 데이터 계약으로 만든다
23장. IaC와 API token을 최소화한다
24장. Origin·Cloudflare 장애를 함께 rehearsal한다
25장. 최종 캡스톤과 출간 게이트

Cloudflare로 구축하는 글로벌 웹 인프라

목차