CloudFront에 ISP·양자내성 TLS 정보 추가: 새 헤더로 무엇을 알 수 있나요?

같은 콘텐츠를 제공하는데 특정 네트워크에서만 문제가 보고되거나, 양자내성 암호(PQC)가 실제 연결에 사용되는지 확인하고 싶을 때가 있습니다. 접속자가 사용한 네트워크와 TLS 정보를 오리진에서 함께 읽을 수 있다면 조사할 기준이 하나 더 생기죠.

이번 CloudFront 소식은 이런 관측 정보를 추가하는 기능입니다. 새 헤더의 의미와 적용 위치, 기록을 해석할 때 놓치기 쉬운 범위를 차례로 살펴볼게요.

10/30 CloudFront 발표에서 무엇이 추가됐나요?

CloudFront는 접속자의 ISP와 TLS 암호 정보를 오리진 요청에 담는 선택형 헤더를 추가했습니다.

AWS의 2026년 10월 30일 공식 발표에 따르면 이름은 CloudFront-Viewer-ISP와 CloudFront-Viewer-TLS-Details입니다. 오리진은 CDN 뒤에서 실제 콘텐츠나 애플리케이션 응답을 제공하는 서버를 뜻합니다.

주목할 점은 전달 방향입니다. CloudFront가 오리진으로 보내는 요청에 정보를 붙이는 기능이죠. 브라우저 개발자 도구의 응답 헤더에 두 값이 자동으로 나타난다고 기대하면 확인 위치가 어긋나요.

따라서 기능 도입 여부를 확인할 때는 사용자가 받은 응답만 살피기보다 오리진의 요청 수신 지점을 정해야 합니다. 어떤 항목을 기록하고 누가 해석할지도 함께 정리하는 편이 좋습니다. 이 부분은 기능 자체의 자동화가 아니라 운영을 위한 준비 제안입니다.

ISP와 TLS 헤더는 각각 어떤 정보를 담나요?

ISP 헤더는 접속 통신사 이름을, TLS 헤더는 뷰어 연결에 사용된 암호 정보를 전달합니다.

AWS는 네트워크별 트래픽·성능 분석과 PQC 사용 현황 파악을 활용 사례로 소개합니다. 다만 이 두 값만으로 지연 원인이 해당 ISP에 있다고 확정할 수는 없습니다. 실제 분석에는 같은 시간대와 요청 조건을 맞춘 성능 기록이 더 필요하죠. 이 판단은 헤더가 제공하는 정보 범위에서 도출한 운영상 해석입니다.

TLS 정보의 대상은 뷰어와 CloudFront 사이의 연결입니다. CloudFront와 커스텀 오리진 사이의 HTTPS는 별도의 오리진 프로토콜 정책과 인증서 설정으로 관리합니다. 한쪽의 암호 정보를 보고 반대쪽 연결까지 같은 상태라고 생각하면 안 돼요.

또한 이 헤더는 사용된 암호를 알려주는 관측 수단입니다. 헤더를 추가하는 행위와 PQC 사용을 활성화하는 행위는 구분해야 합니다. 양자내성 암호의 배경은 기존 글 지금 쓰는 HTTPS는 양자 컴퓨터에 안전한가: 포스트 양자 암호로 넘어가는 웹에서 확인할 수 있습니다. 해당 글의 과거 보급률 수치는 이번 기능의 측정 결과가 아닙니다.

오리진에서 받으려면 어떤 정책이 필요한가요?

Origin request policy에 필요한 헤더를 추가한 뒤 해당 배포의 대상 캐시 동작에 연결합니다.

AWS의 정책 생성·연결 안내에서 실제 연결 단위는 캐시 동작(cache behavior)입니다. 정책을 만들어 두기만 하거나 다른 경로에 연결하면, 확인하려던 요청에 적용되지 않을 수 있죠.

1. 확인할 URL이 어느 캐시 동작과 오리진에 연결되는지 찾습니다.

2. 적용 중인 정책의 헤더·쿠키·쿼리 문자열 전달 조건을 확인합니다.

3. 필요한 새 헤더를 포함한 Origin request policy를 대상 캐시 동작에 연결합니다.

4. 오리진에 도달한 요청에서 수신 값과 로그 저장 여부를 대조합니다.

위 순서는 공식 연결 절차에 로그 확인 단계를 더한 운영 제안입니다. 다른 정책으로 교체할 때 기존 쿠키나 쿼리 전달 조건을 빠뜨리지 않도록 비교해 보세요. 공식 문서는 Origin request policy를 사용하는 캐시 동작에 cache policy도 필요하다고 설명합니다.

두 정책은 역할이 다릅니다. Origin request policy는 오리진에 전달할 정보를, cache policy는 캐시 키를 제어합니다. 관측 정보를 전달하려는 목적과 캐시를 별도 객체로 나누려는 목적을 먼저 구분해야 해요. 새 헤더를 캐시 키에 넣을 수 있는지까지 이번 발표만으로 단정하지 않습니다.

헤더를 오리진으로 전달하는 설정과 로그에 저장하는 작업도 별개입니다. CloudFront 헤더 안내는 오리진이 전달받은 값을 로그에 쓸 수 있다고 설명합니다. 현재 웹 서버나 애플리케이션의 로그 형식이 해당 항목을 수집하는지 확인하세요.

오리진 기록으로 전체 방문자의 비율을 계산해도 되나요?

오리진 로그의 비율은 기록된 요청 범위의 값이며 전체 방문자의 비율로 바로 확대할 수 없습니다.

AWS 문서는 캐시 미적중 시 콘텐츠를 가져오기 위해 오리진 요청을 보낸다고 설명합니다. 반대로 캐시에서 응답이 끝난 요청은 같은 방식으로 오리진에 도달하지 않죠. 따라서 오리진 로그만 사용하면 캐시 처리 방식에 따라 관측 대상이 달라질 수 있습니다.

여기서 도출되는 해석상의 주의점은 분모입니다. PQC가 관측된 요청 수를 기록된 TLS 요청 수로 나눴다면, 우선 그 결과를 해당 로그의 요청 기준 비율로 설명해야 합니다. 전체 뷰어 요청을 얼마나 대표하는지와 고유 사용자 수를 어떻게 구분했는지는 별도 검증이 필요해요.

이 표는 통계 해석을 위해 제안하는 기록 항목입니다. 헤더가 없다는 이유만으로 PQC 미사용으로 분류하지 말고, 정책 적용과 로그 수집 상태부터 대조하는 것이 좋습니다.

집계할 요청이 실제로 CloudFront를 거쳤는지도 확인해야 합니다. 공개 ALB를 오리진으로 사용하는 경우 AWS는 직접 접근을 제한하는 구성을 안내합니다. 여기서 도출되는 운영상 주의점은, 직접 접근 요청이 같은 로그에 섞일 수 있다면 이를 구분하고 경유 경로를 검증한 요청을 분석 대상으로 삼아야 한다는 것입니다. 수신한 헤더 이름만으로 CloudFront 경유를 입증하지 마세요.

기존 캐시 진단과 이번 기능은 어떻게 구분하나요?

이번 헤더는 접속자의 네트워크·TLS 관측용이며 캐시 적중 여부를 판정하는 헤더와 다릅니다.

기존 글 Fastly X-Cache 읽는 법: HIT·MISS만으로 오리진 요청을 판단하면 안 되는 이유는 응답 헤더의 캐시 처리 상태와 기록 시점을 다뤘습니다. 이번 글은 다른 제품의 오리진 요청 헤더를 다루므로 그 해석 규칙을 그대로 옮겨 쓰면 안 되죠.

실무에서는 먼저 질문을 나누면 됩니다. 어느 네트워크에서 왔는지, 어떤 TLS 암호가 사용됐는지, 캐시가 어디에서 응답했는지는 서로 다른 확인 항목입니다. 한 헤더로 세 질문을 모두 해결하려고 하지 마세요.

도입 검토의 출발점은 새 정보를 어디에 쓸지 정하는 것입니다. 조사하려는 문제와 수집 대상을 먼저 적고 정책·로그·집계 기준을 맞추면, 기능이 추가됐다는 소식을 실제로 확인 가능한 관측 항목으로 바꿀 수 있습니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)