AWS 앞에 Cloudflare를 두었다면, 여기서부터 확인하십시오

AWS 앞에 Cloudflare를 두는 구성은 연결 자체가 막히는 일이 드뭅니다. 네임서버를 옮기고, 레코드를 프록시 상태로 켜고, 오리진을 지정하면 화면이 뜹니다.

문제는 그다음에 생깁니다. 두 계층이 겹치는 순간 각 계층이 보는 것이 달라집니다. 오리진은 요청의 출발지를 잃고, 캐시는 두 벌이 되고, 암호화는 구간별로 갈립니다. 그리고 이 변화는 어느 것도 화면에 나타나지 않습니다. 사이트는 열리고, 응답은 빠르고, 로그에는 그럴듯한 IP가 찍혀 있습니다.

미리 밝혀 두면, 이 구성은 잘못된 아키텍처가 아닙니다. 엣지와 AWS를 함께 쓰는 이유는 분명하고 빌드업웍스도 이 구성을 다룹니다. 늘어나는 것은 확인 항목이지 위험 자체가 아닙니다.

항목마다 무엇이 깨지는가 · 왜 화면상 정상으로 보이는가 · 어떻게 확인하는가 · 어떻게 고치는가 순서를 유지했습니다. ③에만 과금이 어떻게 갈리는지를 한 항목 더 두었습니다.

요청은 어떤 경로를 지나는가

Cloudflare를 앞단에 둔 구성에서 방문자의 요청은 Cloudflare 엣지에 먼저 도착하고, 엣지가 오리진에 별도의 연결을 열어 대신 요청합니다. 이 경로는 DNS 레코드가 프록시 상태, 즉 Cloudflare 대시보드 DNS 화면에서 그 레코드의 주황색 구름 토글이 켜진 상태일 때만 성립합니다. 프록시를 끈 레코드는 오리진 주소를 그대로 응답하므로 엣지를 지나지 않습니다.

AWS 쪽에서 오리진 자리에 놓이는 것은 대개 CloudFront 배포, Application Load Balancer, EC2·컨테이너 앞의 공인 엔드포인트 중 하나입니다. 어느 쪽이든 오리진 입장에서 요청을 보낸 상대는 방문자가 아니라 엣지입니다. 이어지는 네 항목은 전부 이 한 문장에서 파생됩니다.

깨지는 곳 ①: 오리진이 인터넷에 그대로 열려 있다

엣지의 방어는 트래픽이 엣지를 지날 때만 작동합니다.

무엇이 깨지는가. 오리진 주소를 알아낸 요청이 엣지를 건너뛰고 직접 도착하면 WAF 규칙, 속도 제한, 봇 관리, 접근 제어가 하나도 적용되지 않은 채 애플리케이션에 닿습니다. Cloudflare의 Authenticated Origin Pulls 문서도 오리진 서버의 IP를 알아낸 사람은 누구든 직접 요청을 보내 Cloudflare와 그 보호를 우회할 수 있다고 적어 두었습니다. 주소가 남는 경로는 여럿입니다. 프록시를 켜기 전의 DNS 레코드 이력, 같은 호스트에서 보낸 메일의 헤더, 발급된 공개 인증서가 도메인 이름과 함께 공개 기록으로 남는 인증서 투명성 로그에 올라간 호스트명, 프록시를 끄고 남겨 둔 보조 레코드, 공인 대역 스캔이 대표적입니다.

왜 화면상 정상으로 보이는가. 브라우저로 도메인을 열면 그 요청은 엣지를 지나므로 모든 것이 정상입니다. 엣지를 건너뛴 요청은 오류를 내지 않고 그냥 성공하며, 로그에도 평범한 요청 한 건으로 남습니다. 실패가 아니라 성공으로 기록되기 때문에 아무도 찾지 않습니다.

어떻게 확인하는가. 오리진으로 직접 요청을 보내 보는 것이 유일한 확인 방법입니다. curl -sI https://example.com/ --resolve example.com:443:<오리진 IP> 처럼 이름은 그대로 두고 접속 대상만 오리진으로 고정합니다. 오리진 주소는 대개 AWS 콘솔의 배포·로드밸런서 DNS 이름이므로, dig <그 이름> 으로 조회한 주소를 --resolve 에 넣으십시오. Application Load Balancer는 주소가 바뀌므로 조회한 시점의 값으로만 유효합니다. 응답에 cf-ray 가 없으면 그 요청은 엣지를 지나지 않은 것이고, 그런데도 정상 콘텐츠가 돌아온다면 우회 경로가 열려 있는 상태입니다. 이 상태를 확인했다면 순서는 접근 제한이 먼저입니다. 주소 교체를 먼저 하면 같은 경로로 새 주소가 다시 알려집니다. 접근 제한이 적용된 구성이라면 이 요청은 거부되어야 정상입니다.

어떻게 고치는가. 성격이 다른 세 종류가 있고, 하나만 쓰기보다 겹쳐 두는 쪽이 안전합니다.

• 네트워크 계층 제한 — 오리진 보안 그룹이 Cloudflare 공인 IP 대역만 허용하게 둡니다. 목록은 Cloudflare IP Ranges에 공개돼 있고 갱신되므로, 반영을 사람 기억에 맡기면 언젠가 어긋납니다. 오리진이 CloudFront면 AWS 관리형 접두사 목록으로 같은 제한을 겁니다. 보안 그룹 인바운드 규칙의 소스를 접두사 목록으로 지정하고 com.amazonaws.global.cloudfront.origin-facing 을 고르는 방식이며, 목록 갱신은 AWS가 맡습니다.
• 요청 검증 — Authenticated Origin Pulls는 엣지가 클라이언트 인증서를 제시하고 오리진이 그것을 검증하는 mTLS 방식이라, 대역 목록 갱신에 의존하지 않습니다. 단 기본(글로벌) 설정의 인증서는 Cloudflare 전 계정이 공유하므로 요청이 Cloudflare 네트워크에서 왔다는 것까지만 보장합니다. ‘우리 계정에서 온 요청’까지 보장하려면 존 단위 또는 호스트명 단위 인증서를 직접 올려야 합니다.
• 비밀 헤더 — CloudFront가 오리진에 붙이는 커스텀 헤더를 ALB 리스너 규칙에서 확인하고, 없으면 고정 응답 403을 돌려줍니다. AWS 문서는 이 방법이 헤더 이름과 값이 비밀로 유지될 때만 성립한다고 명시합니다.

공인 인바운드 경로 자체를 없애는 선택지, 즉 오리진이 바깥으로만 연결을 여는 터널 방식도 있습니다. 이 접근과 기존 VPN의 차이는 Zero Trust와 VPN의 차이에서 따로 다룹니다.

깨지는 곳 ②: 클라이언트 IP가 엣지 IP로 바뀐다

엣지가 오리진에 대신 접속하기 때문에, 오리진이 TCP 연결에서 읽는 출발지 주소는 방문자가 아니라 엣지입니다.

무엇이 깨지는가. 원래 방문자 주소는 연결이 아니라 HTTP 헤더로만 전달됩니다. Cloudflare는 방문자 IP를 CF-Connecting-IP 헤더에 담고, X-Forwarded-For 는 덮어쓰지 않고 덧붙입니다. 일부 상위 요금 등급에서만 제공되는 True-Client-IP 헤더도 별도로 있습니다. 여기에 AWS 계층이 한 번 더 덧붙입니다. Application Load Balancer는 X-Forwarded-For 처리 방식이 routing.http.xff_header_processing.mode 속성으로 결정되고 기본값이 append 라, 애플리케이션이 받는 헤더의 마지막 값은 방문자가 아니라 직전 홉입니다. CloudFront도 같은 헤더 끝에 뷰어 IP를 덧붙입니다. 결과적으로 X-Forwarded-For 는 쉼표로 이어진 목록이 되고, 맨 앞은 위조 가능한 값, 맨 뒤는 인프라 주소가 됩니다.

왜 화면상 정상으로 보이는가. IP 칸이 비어 있으면 즉시 알아채지만, 이 경우 칸은 채워져 있습니다. 형식이 올바른 공인 IP가 매 줄에 찍히기 때문에 정상으로 보이고, 값이 소수의 대역에 몰려 있다는 사실은 집계해 보기 전에는 드러나지 않습니다.

어떻게 확인하는가. 액세스 로그에서 출발지 IP를 빈도순으로 집계해, 상위 몇 개 값이 전체의 대부분을 차지하는지 봅니다. 차지한다면 엣지 주소를 기록하고 있는 것입니다. 그다음 사내망이 아닌 회선으로 접속한 뒤 그 회선의 공인 IP가 로그에 실제로 남았는지 확인합니다. 남지 않으면 복원이 안 된 상태입니다.

어떻게 고치는가. nginx는 ngx_http_realip_module 을 켜고 set_real_ip_from 에 신뢰할 대역을, real_ip_header CF-Connecting-IP 를 지정합니다. Apache는 mod_remoteip 에서 RemoteIPHeader CF-Connecting-IP 와 RemoteIPTrustedProxy 를 씁니다. 두 경우 모두 신뢰할 대역을 함께 지정하는 것이 설정의 절반입니다. 여기에 넣을 값은 앞 항목에서 쓴 Cloudflare IP Ranges와 같은 목록입니다. 헤더는 요청을 보내는 쪽이 임의로 넣을 수 있는 값이라, 오리진이 인터넷에 열려 있으면 누구든 CF-Connecting-IP 에 원하는 주소를 적어 직접 보낼 수 있습니다. AWS WAF 문서도 공격자가 검사를 피하려고 헤더 내용을 바꿀 수 있다고 경고합니다. 헤더 신뢰는 요청이 엣지를 거쳐 왔음이 네트워크 계층에서 보장되고, 그 헤더를 엣지가 스스로 채울 때만 성립합니다. 오리진 접근 제한과 클라이언트 IP 복원이 별개의 작업이 아닌 이유가 여기 있습니다.

복원 설정이 필요한 곳은 웹 서버만이 아닙니다. 요청의 출발지 주소를 판단하는 주체마다 각각 필요하고, 여기에는 로드밸런서, 방화벽, 애플리케이션 프레임워크의 신뢰 프록시 설정, 로그를 수집하는 도구가 모두 포함됩니다. 읽는 지점을 먼저 목록으로 만들어 두면 확인이 한 바퀴로 끝납니다.

클라이언트 IP를 잃으면 네 곳이 동시에 어긋난다

출발지 주소는 여러 기능이 공통으로 참조하는 값이라, 한 번 어긋나면 증상이 여러 곳에서 따로 나타납니다.

• 차단 규칙 — 특정 주소를 막으려고 넣은 규칙이 엣지 주소를 가리켜, 아무도 안 막히거나 그 엣지를 통과한 전원이 막힙니다.
• 속도 제한 — 모든 방문자가 소수의 주소로 집계되어, 트래픽이 몰리는 시간대에 정상 사용자가 먼저 제한에 걸립니다.
• 지역 기반 정책 — 국가 판정이 방문자가 아니라 엣지 위치를 기준으로 이뤄집니다. AWS WAF에서 지역 일치, 요청이 어느 통신사업자 망에서 왔는지 보는 ASN 일치, 그리고 레이트 기반 규칙은 헤더를 쓰도록 지정하지 않으면 요청 출발지를 그대로 사용합니다. 지정할 때는 ForwardedIPConfig 의 HeaderName 과 FallbackBehavior 를 규칙마다 각각 설정해야 합니다. IP 세트 일치는 헤더 안에서 첫 번째·마지막·전체 중 어디를 볼지도 함께 정합니다.
• 감사 로그 — 사고를 조사할 때 출발지를 특정할 수 없습니다. 다른 항목은 언젠가 증상으로 드러나지만, 이 손실만 사고가 난 뒤에 필요한 것이 없다는 형태로 나타납니다. 복원을 적용한 날짜를 기록해 두면, 나중에 조사할 때 어느 구간의 로그가 엣지 주소인지 구분할 수 있습니다.

AWS WAF의 관리형 규칙 그룹 일부는 CloudFront·Cloudflare·Fastly 대역에서 온 요청을 인식해 상위 CDN의 표준 클라이언트 IP 헤더를 자동으로 사용합니다. 다만 이 동작은 해당 관리형 규칙 그룹에 한정되고 직접 만든 규칙은 여전히 개별 설정이 필요하므로, 관리형 규칙이 정상 동작하는 것을 보고 전체가 복원됐다고 판단하면 어긋납니다. 로그인 이상 감지·지역 로그인 알림·세션 바인딩처럼 애플리케이션이 자체적으로 IP를 읽는 기능도 같은 값에 묶여 있어, 웹 서버만 고쳐 두면 이쪽은 그대로 남습니다.

깨지는 곳 ③: CDN이 두 겹이 된다

Cloudflare 뒤에 CloudFront를 두면 캐시 계층이 두 개가 되고, 그 시점부터 캐시 정책과 무효화와 과금이 각각 두 벌이 됩니다.

무엇이 깨지는가. Cloudflare의 퍼지는 Cloudflare 엣지의 캐시를, CloudFront의 무효화는 CloudFront의 캐시를 지웁니다. Cloudflare 쪽에서 퍼지라고 부르는 것과 CloudFront 쪽에서 무효화라고 부르는 것은 이름만 다르고 하는 일은 같습니다. 한쪽만 실행하면 다른 쪽이 옛 응답을 계속 내보냅니다. CloudFront 문서도 무효화를 하더라도 하위 캐시에 남은 버전은 만료될 때까지 계속 보일 수 있다고 적으며, 자주 바뀌는 파일에는 버전이 붙은 파일명을 권합니다. Cloudflare는 다른 CDN이나 프록시를 가리키는 CNAME 레코드를 프록시할 때 생기는 충돌도 문서에 명시해 두었습니다. 두 프록시가 모두 TLS를 종료하려 하면서 생기는 인증서 체인 오류, 각 프록시가 서로에게 요청을 되던지는 라우팅 루프, 상위 CDN이 Cloudflare IP에서 온 요청을 거부하는 경우입니다. 요청이 자사 네트워크를 몇 번 지났는지는 CDN-Loop 헤더로 판단합니다.

과금은 어떻게 갈리는가. 두 계층은 각각 자기 계층을 지난 요청과 전송량에 별도의 과금 축을 가지므로, 앞 계층 캐시에 적중하지 않고 내려간 요청은 AWS 쪽 요청·전송으로 그대로 잡힙니다. 즉 앞 계층의 캐시 적중률이 뒤 계층의 청구액을 좌우합니다. Cloudflare는 DDoS 문서에서 반대 순서 — 제3자 CDN이 Cloudflare 앞에 오는 구성 — 에 대해, 자사가 공격을 완화하더라도 그 앞 단계에서 처리된 트래픽 비용은 첫 홉 사업자에게 지불하게 된다고 밝힙니다. 순서가 바뀌면 비용이 잡히는 자리도 바뀐다는 뜻입니다.

자기 구성에서 확인할 때는 AWS 청구서에서 CloudFront의 요청 수와 데이터 전송 항목을, Cloudflare 쪽에서는 요금제에 포함된 사용량과 초과분 항목을 나란히 봅니다. 조건이 계속 바뀌므로 이 글은 금액을 적지 않습니다. 단가는 Amazon CloudFront 요금과 Cloudflare 요금제에서 확인하십시오.

왜 화면상 정상으로 보이는가. 두 겹이어도 화면은 뜨고, 오히려 캐시가 더 잘 맞아 빨라 보이기도 합니다. 증상은 대개 배포 뒤에 나타납니다. 파일을 바꿨는데 어떤 사용자에게는 새 버전이, 어떤 사용자에게는 옛 버전이 보이는 상태가 이어지고, 그때쯤에는 원인이 캐시인지 브라우저인지 구분하기 어려워집니다.

어떻게 확인하는가. 응답 헤더 한 번이면 계층 수가 드러납니다. curl -sI https://example.com/ 을 실행하면 Cloudflare를 지난 응답에는 cf-ray 와 cf-cache-status 가, CloudFront를 지난 응답에는 Via 헤더에 .cloudfront.net (CloudFront) 형태의 값이 나옵니다. 둘이 동시에 보이면 두 겹입니다. 그다음 파일 하나를 바꾸고 한쪽만 무효화한 뒤 다시 요청해, cf-cache-status 가 HIT 인 채로 옛 응답이 돌아오는지 봅니다.

어떻게 고치는가. 두 겹 자체가 언제나 틀린 선택은 아닙니다. 빌드업웍스도 전송 최적화가 필요한 구성에서 Cloudflare와 CloudFront를 함께 두는 설계를 다룹니다. 다만 두 겹으로 가기로 했다면 어느 계층이 캐시를 판단하고 어느 계층이 접근을 통제하는지를 문서로 정하고, 배포 절차에 양쪽 무효화를 모두 넣어야 합니다.

깨지는 곳 ④: 암호화 구간이 설정에 따라 갈린다

Cloudflare의 SSL/TLS 암호화 모드는 방문자와 엣지 사이가 아니라 엣지와 오리진 사이 구간을 무엇으로 처리할지 정하는 설정입니다.

무엇이 깨지는가. 모드는 다섯 가지이고 구간의 성격이 각각 다릅니다.

• Off — 양쪽 구간 모두 암호화하지 않습니다.
• Flexible — 방문자와 엣지 사이는 HTTPS로 처리할 수 있지만, 엣지와 오리진 사이는 암호화하지 않습니다.
• Full — 오리진에 HTTPS로 연결하되 오리진 인증서를 검증하지 않습니다.
• Full (strict) — 인증서 검증을 더합니다. 오리진 인증서가 공개 CA 또는 Cloudflare Origin CA에서 발급된 것이어야 합니다.
• Strict (SSL-Only Origin Pull) — 방문자 쪽 프로토콜과 무관하게 항상 검증을 동반한 HTTPS로 오리진에 연결합니다.

Full 과 Full (strict) 의 간격이 실무에서 방치되기 쉽습니다. 검증하지 않는 설정에서는 만료된 인증서, 자체 서명 인증서, 호스트명이 맞지 않는 인증서가 모두 그대로 통과합니다. 연결은 암호화되지만 상대가 원래의 오리진이 맞는지는 확인하지 않는 상태입니다.

왜 화면상 정상으로 보이는가. 브라우저 주소창의 자물쇠는 방문자와 엣지 사이 구간만 나타냅니다. 엣지와 오리진 사이가 평문이어도 자물쇠는 그대로 켜져 있어서, 이 아이콘을 종단 간 암호화의 증거로 읽는 것이 이 항목에서 자주 나오는 오해입니다.

어떻게 확인하는가. 대시보드에서 현재 모드를 확인한 뒤 오리진 인증서를 직접 봅니다. curl -sv https://example.com/ --resolve example.com:443:<오리진 IP> -o /dev/null 로 오리진에 붙어 발급자, 만료일, 인증서에 포함된 호스트명이 실제 요청 이름과 맞는지 확인합니다. 출력이 길게 나오므로 볼 줄은 * issuer:, * expire date:, * subjectAltName: 세 줄입니다. 조건이 어긋난 채로 검증을 켜면 방문자에게는 Cloudflare의 525(SSL handshake failed) 또는 526(Invalid SSL certificate) 오류로 나타납니다. 뒤집어 말하면, 발급자가 자체 서명이거나 인증서의 이름이 요청 이름과 맞지 않는데도 방문자 쪽이 멀쩡하다면 현재 모드는 Full 이하일 수밖에 없습니다. Full (strict) 였다면 이미 526 이 보였을 것이기 때문입니다.

어떻게 고치는가. 순서는 오리진 인증서를 먼저 정리하고 그다음 검증을 켜는 쪽입니다. 반대로 하면 전면 오류가 됩니다. 오리진이 CloudFront인 경우에는 규칙이 한 겹 더 있습니다. CloudFront는 오리진에 HTTPS로 요청할 때 오리진이 유효하지 않거나 자체 서명된 인증서를 반환하면 TCP 연결을 끊고, 오리진에 보내는 Host 헤더 값을 해당 오리진의 도메인 이름으로 설정합니다. 인증서에 포함된 이름과 이 값이 맞는지를 함께 봐야 합니다.

구성 직후 확인 순서

AWS와 Cloudflare를 연결한 직후에는 엣지 경유 여부, 오리진 직접 접근, 클라이언트 IP 복원, IP 기반 규칙, TLS 모드, CDN 계층 수, 무효화 절차, 과금 축을 순서대로 확인합니다.

1. 엣지를 지나는지 — curl -sI https://example.com/ 응답에 cf-ray 가 있는지 봅니다. 없으면 해당 레코드가 프록시 상태가 아니므로, 대시보드 DNS 화면에서 그 레코드의 주황색 구름 토글을 확인합니다.
2. 오리진 직접 접근 — 같은 요청을 --resolve 로 오리진에 고정해 보냅니다. 정상 콘텐츠가 돌아오면 우회 경로가 열려 있습니다.
3. 헤더 위조 여부 — 2번에서 직접 접근이 거부됐다면 이 항목은 건너뜁니다(신뢰 경계가 이미 네트워크 계층에서 성립합니다). 거부되지 않았다면, 오리진에 직접 보내는 요청에 CF-Connecting-IP 를 임의의 값으로 넣되 식별하기 쉬운 경로로 보내 로그에서 그 한 건을 찾습니다. 넣은 값이 그대로 남으면 신뢰 경계가 없는 상태입니다.
4. 클라이언트 IP 복원 — 사내망이 아닌 회선으로 접속한 뒤 그 회선의 공인 IP가 남았는지 확인합니다. 웹 서버 로그와 애플리케이션 로그를 따로 봅니다.
5. IP를 참조하는 규칙 — 차단 목록·속도 제한·지역 정책이 복원된 값을 쓰는지 규칙 단위로 확인합니다. AWS WAF는 규칙마다 별도 설정입니다.
6. TLS 모드와 오리진 인증서 — 현재 모드를 확인하고, 오리진 인증서의 발급자·만료일·호스트명을 직접 조회합니다.
7. CDN 계층 수 — 응답 헤더에 cf-ray 와 CloudFront Via 값이 동시에 보이는지 확인합니다.
8. 무효화 절차 — 배포 스크립트에 두 계층의 무효화가 모두 들어 있는지 보고, 파일 하나를 실제로 바꿔 양쪽에 반영되는지 확인합니다.
9. 과금 축 — AWS 청구서의 CloudFront 요청 수·데이터 전송 항목과 Cloudflare 요금제의 사용량·초과분 항목을 각각 확인해, 어느 계층에서 요청과 전송이 잡히는지 구조로 파악해 둡니다.

빌드업웍스의 운영 경험에서는, 엣지를 붙인 직후에 오리진 직접 접근을 실제로 시도해 보는 절차를 구성 작업에 포함합니다. 구성도상으로는 엣지가 앞에 있는데 실제로는 우회가 가능한 상태가, 시도해 보기 전까지는 어느 화면에도 나타나지 않기 때문입니다.

덧붙이면, 위 확인 항목을 정기적으로 도는 일과 24시간 사람이 화면을 지켜보는 상시 관제는 서로 다른 일입니다. 규칙 구성과 자동 탐지·알림은 계약 범위 안에서 다루지만, 상시 관제는 그것을 전업으로 하는 전문 업체를 함께 붙이며 별도 비용이 발생합니다.

혼자 판단하기 전에 멈출 지점

AWS와 Cloudflare 구성에서 되돌리는 비용이 큰 변경은 오리진 접근 제한 적용, TLS 모드 상향, CDN 계층 정리입니다. 셋은 잘못 적용하면 조용히 어긋나는 것이 아니라 서비스가 즉시 끊깁니다.

• 오리진 접근 제한 적용 — 허용 대역을 잘못 잡으면 정상 트래픽이 전부 막힙니다. 배치 작업이나 모니터링처럼 엣지를 지나지 않는 접근이 있는지 미리 목록화해야 합니다.
• TLS 모드 상향 — 검증을 켜는 순간 오리진 인증서가 조건을 만족하지 못하면 전면 오류가 됩니다.
• CDN 계층 정리 — DNS 전환을 동반하므로 되돌리는 시간이 레코드의 TTL, 곧 다른 DNS 서버가 그 응답을 몇 초 동안 기억해 두는지를 정한 값에 묶입니다. 전환 전에 TTL을 낮춰 두어야 합니다.

이 구성은 잘못된 아키텍처가 아닙니다. 엣지와 AWS를 함께 쓰는 이유는 분명하고, 빌드업웍스의 운영 경험에서도 AWS 앞단에 Cloudflare를 두는 구성을 다뤄 왔습니다. 다만 두 계층을 쓰기로 한 순간부터 확인해야 할 것이 한 벌 늘어납니다. 같은 경험에서, 이 목록을 구성 문서에 함께 남겨 두는 편이 담당자가 바뀐 뒤에 되짚는 시간을 줄였습니다.

다음 단계

AWS와 Cloudflare 구성의 현재 상태를 항목별로 보고 싶다면 보안 진단으로 네트워크 구성 점검하기에서 시작하실 수 있습니다. 네트워크 보안과 로깅·탐지 영역이 오리진 접근·클라이언트 IP·암호화 구간과 직결됩니다. 엣지 계층 규칙의 설계와 한계는 Cloudflare WAF가 막는 것과 막지 못하는 것에서 따로 다룹니다.

다음 단계는 지금 무엇이 급한지에 따라 갈립니다. 구성 자체를 함께 설계하거나 이관을 검토하는 단계라면 AWS 인프라 설계·구축 범위 보기를 보십시오. 접근 통제와 로그 체계를 함께 잡아야 한다면 통합 보안 서비스 범위 보기가, 회원·결제처럼 구간별 보호 수준을 나눠야 하는 경우라면 회원·결제 구간 보안 구성 보기가 맞습니다. 운영을 맡기는 방식과 조건은 AWS 운영 플랜에 있습니다.

헤더 이름과 설정 값은 공식 문서 기준으로 확인한 것이며, 제품 동작과 요금 조건은 변경될 수 있습니다. 적용 전에 아래 출처에서 현재 사양을 확인하십시오.

참고 자료

• Cloudflare Docs — HTTP request headers (CF-Connecting-IP·True-Client-IP·CDN-Loop)
• Cloudflare Docs — Restoring original visitor IPs
• Cloudflare Docs — SSL/TLS encryption modes
• Cloudflare Docs — Authenticated Origin Pulls
• Cloudflare Docs — Cloudflare IP addresses
• Cloudflare — IP Ranges 목록
• Cloudflare Docs — Cache responses (CF-Cache-Status)
• Cloudflare Docs — Purge cache
• Cloudflare Docs — Proxy status use cases (다른 CDN을 가리키는 CNAME)
• Cloudflare Docs — Third-party services and DDoS protection
• AWS Docs — Using forwarded IP addresses in AWS WAF
• AWS Docs — HTTP headers and Application Load Balancers (X-Forwarded-For)
• AWS Docs — Restrict access to Application Load Balancers
• AWS Docs — Request and response behavior for custom origins
• AWS Docs — Invalidate files to remove content (CloudFront)
• AWS Docs — Restrict access with VPC origins
• AWS Docs — AWS 관리형 접두사 목록
• Amazon CloudFront 요금
• Cloudflare 요금제