설명서Adobe 브랜드 가시성

CloudFront(BYOCDN)

마지막 업데이트: 2026년 9월 5일

작성 대상:

  • 관리자

이 구성은 에이전틱 트래픽(AI 봇 및 LLM 사용자 에이전트의 요청)을 Edge Optimize 백엔드 서비스(live.edgeoptimize.net)로 라우팅합니다. 사람 방문자와 SEO 봇은 기존과 동일하게 사용자의 원본 서버에서 계속 제공됩니다. 구성을 테스트하려면 설정이 완료된 후 응답에서 헤더 x-edgeoptimize-request-id를 찾습니다.

사전 요구 사항

CloudFront 구성을 설정하기 전에 다음이 있는지 확인하십시오.

  • 웹 사이트를 제공하는 기존 CloudFront 배포
  • Lambda 함수, IAM 역할, CloudFront 배포 및 캐시 정책을 생성할 수 있는 AWS IAM 권한
  • Adobe Brand Visibility UI에서 가져온 Edge Optimize API 키 단계는 API 키 검색을 참조하십시오.
  • (선택 사항) 스테이징 라우팅을 테스트하려면 스테이징 API 키를 참조하십시오.

설정 옵션

Optimize at Edge를 위해 CloudFront를 구성하는 방법은 두 가지입니다.

옵션 1: Adobe Brand Visibility의 가이드 설정

https://video.tv.adobe.com/v/3502238/?captions=kor&quality=12&learn=on
https://video.tv.adobe.com/vc/3502238/kor.json
  1. 구성하려는 URL에 대한 CDN 구성​을 엽니다.
  2. AI 에이전트에 최적화 배포​에서 필요한 경우 활성화​를 선택합니다.
  3. CloudFront(Beta)에서 라우팅 배포​를 선택합니다.
  4. CloudFront 배포가 포함된 12자리 AWS 계정 ID를 입력합니다.
  5. Adobe Brand Visibility에서 생성한 링크를 사용하여 커넥터 역할을 만듭니다. AWS 관리자가 아닌 경우 역할을 만들 수 있는 사람과 링크를 복사하여 공유하십시오.
  6. 구성하려는 CloudFront 배포, 기존 원본 및 캐시 동작을 선택합니다.
  7. 제안된 변경 사항을 검토한 다음, 가이드 단계에 따라 구성을 배포하고 확인합니다.

Adobe Brand Visibility에서 CloudFront에 라우팅 배포

NOTE
가이드 설정은 적격한 계정을 위한 조기 액세스 기능으로 제공됩니다. 온보딩 지원을 받으려면 Adobe 계정 팀에 문의하거나 abv-at-edge@adobe.com으로 이메일을 보내십시오.

옵션 2: 수동 설정

CloudFront를 수동으로 구성하려면 다음 단계를 따르십시오.

1단계: Edge 최적화 원본 만들기

탐색: AWS Console > CloudFront > 배포 > [내 배포] > 원본 탭

  1. 원본 만들기​를 클릭합니다.

  2. 원본을 다음과 같이 구성합니다.

    • 원본 도메인: live.edgeoptimize.net
    • 이름: EdgeOptimize_Origin

  3. 다른 모든 필드는 기본값으로 둡니다.

  4. 사용자 정의 헤더 추가:

    table 0-row-2 1-row-2 2-row-2 3-row-2
    헤더 값
    x-edgeoptimize-api-key API 키
    x-forwarded-host www.example.com
    x-edgeoptimize-fetcher-key Fetcher 키(WAF 허용 목록에 추가의 경우에만 필요)

    www.example.com을 실제 웹 사이트 도메인으로 바꾸고 Your API key를 Adobe 담당자가 제공한 Edge Optimize API 키로 바꿉니다.

  5. 원본 만들기​를 클릭합니다.

Cloudfront 원본 만들기

2단계: 뷰어 요청 함수 만들기

탐색: AWS Console > CloudFront > 함수

  1. 함수 만들기​를 클릭합니다.

  2. 다음을 구성하십시오.

    • 이름: edgeoptimize-routing
    • 런타임: cloudfront-js-2.0

  3. 기본 코드를 viewer-request.js의 코드로 바꿉니다.

    게시하기 전에 코드에서 다음 값을 사용자 정의합니다.

    • YOUR_DEFAULT_ORIGIN - 기존 기본 원본 이름으로 대체합니다(CloudFront > 배포 > [배포] > 원본 탭에서 확인).
    • TARGETED_PATHS - null을 모든 HTML 페이지를 타기팅하도록 설정하거나 특정 경로의 배열(예: ['/', '/products', '/about'])로 설정합니다.

  4. 변경 내용 저장 > 함수 게시​를 클릭합니다.

Cloudfront 함수 만들기

3단계: 캐시 정책 구성

탐색: AWS Console > CloudFront > 배포 > [내 배포] > 동작

현재 동작에 연결된 캐시 정책을 확인합니다. 동작에서 편집​을 클릭하고 캐시 키 및 원본 요청 섹션을 보고 시나리오를 확인하십시오.

  • 시나리오 A(기존): 기존 캐시 설정​이라고 레이블이 지정된 라디오 버튼이 표시됩니다. 정책 이름 드롭다운은 없으며, 대신 인라인 TTL 및 헤더 설정이 표시됩니다.
  • 시나리오 B(사용자 정의 정책): 사용자 또는 팀이 만든 정책 이름(AWS 제공 정책이 아님)으로 선택한 캐시 정책​이 표시됩니다.
  • 시나리오 C(관리 정책): CachingOptimized, CachingDisabled 또는 CachingOptimizedForUncompressedObjects와 같이 AWS에서 제공한 이름으로 선택한 캐시 정책​이 표시되며, 해당 정책은 편집할 수 없습니다.

시나리오 A: 기존 캐시 설정

동작이 레거시 캐시 설정을 사용하는 경우:

  1. 캐시 키 및 원본 요청​을 보면 기존 캐시 설정​이 선택되어 있습니다.

  2. 헤더 허용 목록에 x-edgeoptimize-config 및 x-edgeoptimize-url을 추가합니다.

    • 드롭다운에서 다음 헤더 포함​을 선택합니다.
    • x-edgeoptimize-config 및 x-edgeoptimize-url을 추가합니다.
      Cloudfront 캐시 레거시

    헤더 드롭다운에서 이미 모두​를 선택한 경우 모든 헤더가 원본으로 자동 전달되므로 이 단계를 건너뜁니다.

  3. 오브젝트 캐싱 설정을 확인합니다.

    • 사용자 지정​으로 설정하는 경우 최소 TTL​을 0으로 설정하는 것이 좋습니다. 현재 최소 TTL이 이미 매우 짧은 경우 변경할 필요가 없습니다.
    • 원본 캐시 헤더 사용​으로 설정된 경우 변경할 필요가 없습니다.

  4. 변경 내용 저장​을 클릭합니다.

시나리오 B: 사용자 정의 캐시 정책을 사용하는 비레거시

동작이 이미 사용자 정의 캐시 정책(AWS 관리 정책이 아닌 사용자가 만든 정책)을 사용하는 경우:

탐색: AWS Console > CloudFront > 정책 > 캐시

  1. 기존 정책을 클릭합니다.

  2. 편집​을 클릭합니다.

  3. 최소 TTL​을 0으로 설정하는 것이 좋습니다. 현재 최소 TTL이 이미 매우 짧은 경우 변경할 필요가 없습니다.
    캐시 정책 TTL 설정

  4. 캐시 키 설정 > 헤더​에서 기존 포함과 함께 x-edgeoptimize-config 및 x-edgeoptimize-url을 추가합니다.
    캐시 정책 헤더

  5. 변경 내용 저장​을 클릭합니다.

시나리오 C: 관리(AWS) 캐시 정책이 있는 비레거시

동작이 AWS 관리 캐시 정책(예: CachingOptimized)을 사용하는 경우 편집할 수 없습니다. 따라서 기존 관리 정책 설정을 복제하고 상위에 Edge Optimize 헤더를 추가하는 새 사용자 정의 캐시 정책을 만들어야 합니다.

1부: 현재 관리되는 캐시 정책 설정을 기록

탐색: AWS Console > CloudFront > 정책 > 캐시

  1. 현재 동작에 연결된 관리 캐시 정책을 찾아 클릭합니다(예: CachingOptimized).

  2. 기존 설정을 모두 기록합니다.

    • 최소 TTL, 최대 TTL, 기본 TTL
    • 캐시 키에 포함된 헤더
    • 캐시 키에 포함된 쿠키
    • 캐시 키에 포함된 쿼리 문자열
    • 압축 지원(Gzip, Brotli)

2부: 동일한 설정 + Edge Optimize 구성을 사용하여 새 사용자 정의 캐시 정책 만들기

탐색: AWS Console > CloudFront > 정책 > 캐시

  1. 캐시 정책 만들기​를 클릭합니다.

  2. 이름: edgeoptimize-cache

    캐시 정책 이름

  3. 1부에 언급된 모든 설정을 다음과 같이 수정하여 복제합니다.

    • 최소 TTL​을 0으로 설정하는 것이 좋습니다. 현재 최소 TTL이 이미 매우 짧은 경우 변경할 필요가 없습니다.

    캐시 정책 TTL 설정

    • 캐시 키 설정 > 헤더​에서 관리 정책에 있는 모든 내용을 포함하고 x-edgeoptimize-config 및 x-edgeoptimize-url을 추가합니다.

    캐시 정책 헤더

  4. 만들기​를 클릭합니다.

  5. 동작으로 돌아가서 새로 만든 정책을 연결합니다.

    탐색: AWS Console > CloudFront > 배포 > [내 배포] > 동작

    1. 동작을 편집합니다.
    2. 캐시 키 및 원본 요청​에서 캐시 정책​을 선택합니다.
    3. 드롭다운에서 edgeoptimize-cache를 선택합니다.
    4. 변경 내용 저장​을 클릭합니다.

4단계: Lambda@Edge 함수 만들기(원본 요청 및 응답)

IMPORTANT
Lambda@Edge 함수​ 는 us-east-1(버지니아 북부) 지역 ​에서 만들어야 합니다. 이는 AWS 요구 사항입니다. 함수를 us-east-1에서 만들더라도 AWS가 이 함수를 전 세계의 모든 CloudFront 에지 위치에 자동 복제하므로 뷰어에 가장 가까운 에지 로케이션에서 함수가 실행됩니다. 계속하기 전에 본인이 AWS Console에서 us-east-1 지역에 있는지 확인하십시오.

Lambda 함수 만들기

탐색: AWS Console > Lambda

  1. 함수 만들기​를 클릭합니다.

  2. 처음부터 작성​을 선택합니다.

  3. 다음을 구성하십시오.

    • 함수 이름: edgeoptimize-origin
    • 다른 모든 필드는 기본값으로 둡니다.

  4. 함수 만들기​를 클릭합니다.

  5. 코드 편집기에서 기본 코드를 origin-request-response.js의 코드로 바꿉니다.

  6. 코드를 저장하려면 배포​를 클릭합니다.

  7. 구성 > 권한(예: edgeoptimize-origin-role-xxxxx)에 표시된 실행 역할 이름​을 참고하십시오. 다음 단계에서 이 작업이 필요합니다.

실행 역할의 신뢰 정책 업데이트

자동 생성된 역할은 lambda.amazonaws.com만 신뢰합니다. Lambda@Edge의 경우 edgelambda.amazonaws.com도 추가해야 합니다.

탐색: AWS Console > IAM > 역할 > [이전 단계의 역할] > 신뢰 관계 탭

  1. 신뢰 정책 편집​을 클릭합니다.

  2. 정책을 trust-policy.json의 내용으로 바꿉니다.

  3. 정책 업데이트​를 클릭합니다.

WARNING
Lambda@Edge의 edgelambda.amazonaws.com 서비스 주체는 필수​입니다. 필수가 아닌 경우 CloudFront가 에지 로케이션에서 함수를 호출할 수 없습니다.

CloudWatch 로그 권한 정책 수정

자동 생성된 역할에는 Lambda@Edge에 대한 잘못된 지역 및 로그 그룹 이름이 있는 일반 Lambda에 대해 구성된 AWSLambdaBasicExecutionRole 정책이 있습니다. 따라서 이 정책을 업데이트해야 합니다.

탐색: AWS Console > IAM > 역할 > [내 역할] > 권한 탭 > 연결된 정책 이름(예: AWSLambdaBasicExecutionRole-xxxx) 클릭

  1. 편집​을 클릭합니다.

  2. 정책을 cloudwatch-policy.json의 내용으로 바꿉니다.

    JSON에서 ACCOUNT_ID를 실제 AWS 계정 ID(AWS 콘솔의 우측 상단에서 확인)로 바꾸고, FUNCTION_NAME을 Lambda 함수 이름(예: edgeoptimize-origin)으로 바꿉니다.

  3. 변경 내용 저장​을 클릭합니다.

WARNING
ARN의 지역은 *이어야 합니다. Lambda@Edge는 뷰어에 가장 가까운 에지 위치에서 실행되므로 로그가 에지 위치의 지역(예: ap-south-1, eu-west-1)에 있는 CloudWatch에 기록되며 지역이 반드시 us-east-1일 필요는 없습니다. 로그 그룹은 지역 접두사가 있는 이름 /aws/lambda/us-east-1.FUNCTION_NAME을 사용합니다. 여기서 us-east-1은 항상 함수의 홈 지역입니다.

CloudWatch 로그 링크 수정

기본적으로 Lambda 콘솔의 CloudWatch 로그 보기 바로 가기는 Lambda@Edge에 대한 잘못된 로그 그룹인 us-east-1의 /aws/lambda/FUNCTION_NAME에 연결됩니다. 링크가 올바른 경로를 가리키도록 사용자 정의 로그 그룹을 구성합니다.

탐색: AWS 콘솔 > Lambda > [사용자 함수] > 구성 > 모니터링 및 작업 도구

  1. 편집​을 클릭합니다.

  2. CloudWatch 로그 그룹​에서 사용자 정의​를 선택합니다.

  3. 사용자 정의 로그 그룹 이름을 /aws/lambda/us-east-1.edgeoptimize-origin으로 설정합니다.

  4. 권한​에서 필요한 권한 추가 확인란을 선택 해제​로 둡니다.

    Lambda 사용자 정의 로그 그룹 구성

  5. 저장​을 클릭합니다.

NOTE
수정한 후에는 CloudWatch 로그 보기 링크가 올바른 로그 그룹 이름을 열지만, 사용자가 잘못된 지역에 있는 경우에는 데이터가 표시되지 않을 수 있습니다. Lambda@Edge 로그는 us-east-1이 아니라 요청을 처리한 엣지 영역(예: eu-west-1, ap-south-1)에 기록됩니다. 로그를 보려면 CloudWatch에서 올바른 영역으로 전환해야 합니다.

버전 게시

  1. 함수 페이지에서 작업(오른쪽 상단) > 새 버전 게시​를 클릭합니다.

  2. 설명을 추가합니다.

  3. 게시를 클릭합니다.
    Lambda 게시

  4. 함수 ARN을 복사하거나 기록하십시오. 다음 단계에서 이 정보가 필요합니다.
    Lambda ARN

5단계: 함수 및 캐시 정책을 동작과 연결

탐색: AWS Console > CloudFront > 배포 > [내 배포] > 동작

  1. 동작을 편집합니다.

  2. 3단계(시나리오 C)에서 새 캐시 정책을 만든 경우 캐시 정책​을 edgeoptimize-cache로 설정합니다.
    캐시 정책

  3. 함수 연결​에서 다음을 구성합니다.

    • 뷰어 요청: edgeoptimize-routing
    • 원본 요청: 4단계의 버전이 지정된 함수 ARN(버전 게시)
    • 원본 응답: 4단계의 버전이 지정된 함수 ARN(버전 게시)

    함수 연결 구성

  4. 변경 내용 저장​을 클릭합니다.

방화벽 규칙을 통해 Optimize at Edge 허용(선택 사항)

CDN에서 WAF 또는 Bot Manager를 사용하는 경우:

  • Optimize at Edge 서비스가 원본 콘텐츠를 가져올 수 있도록 WAF 또는 Bot Manager에 *AdobeEdgeOptimize/1.0* 사용자 에이전트를 허용 목록에 추가합니다.

  • 방화벽에 사용자 에이전트 이외의 추가 확인이 필요한 경우 암호를 생성하고(예: openssl rand -hex 32):

    • 다른 x-edgeoptimize-* 헤더와 함께 라우팅 규칙에 암호가 포함된 x-edgeoptimize-fetcher-key를 추가합니다.
    • x-edgeoptimize-fetcher-key가 같은 암호와 일치하는 요청을 허용하도록 WAF 또는 Bot Manager 규칙을 추가합니다.

  • Optimize at Edge는 이 헤더를 있는 그대로 전달하므로 키의 전체 수명 주기를 소유합니다.

6단계: 구성 테스트

1. 봇 트래픽 테스트(최적화해야 함)

에이전틱 보트 사용자 에이전트를 사용하여 요청을 보냅니다. 첫 번째 요청​에서 Edge Optimize는 페이지를 처리하고 캐시하는 동안 프록시화된(최적화되지 않은) 응답을 반환할 수 있습니다. 응답의 x-edgeoptimize-proxy: 1 헤더로 이를 식별할 수 있습니다.

에이전틱 사용자 에이전트를 사용하여 AI 봇 요청을 시뮬레이션합니다.

curl -svo /dev/null https://www.example.com/page.html \
  --header "user-agent: chatgpt-user"

성공적인 응답에는 요청이 Edge Optimize를 통해 라우팅되었음을 확인하는 x-edgeoptimize-request-id 헤더가 포함됩니다.

< HTTP/2 200
< x-edgeoptimize-request-id: 50fce12d-0519-4fc6-af78-d928785c1b85

2. 사람 트래픽 테스트(영향을 받지 않아야 함)

일반 사람 브라우저 요청을 시뮬레이션합니다.

curl -svo /dev/null https://www.example.com/page.html \
  --header "user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36"

응답에는 x-edgeoptimize-request-id 헤더가 없어야 합니다. 페이지 콘텐츠와 응답 시간은 Optimize at Edge를 활성화하기 전과 동일하게 유지되어야 합니다.

3. 두 시나리오를 구분하는 방법

헤더
봇 트래픽(최적화됨)
사람 트래픽(영향을 받지 않음)
x-edgeoptimize-request-id
있음 - 고유한 요청 ID가 포함되어 있습니다.
없음
x-edgeoptimize-fo
장애 조치가 발생한 경우에만 표시됩니다(값: 1).
없음

Adobe Brand Visibility UI에서 트래픽 라우팅 상태를 확인할 수도 있습니다. 고객 구성​으로 이동하여 CDN 구성 탭을 선택합니다.

AI 에이전트에 최적화 배포 — 완료됨

4. 로그 흐름이 올바른지 확인

위의 테스트 요청을 실행한 후 CloudFront 함수와 Lambda@Edge 함수 모두에 대해 로그가 기록되고 있는지 확인합니다.

CloudFront 함수 로그(edgeoptimize-routing)

탐색: AWS Console > CloudWatch > 로그 그룹(us-east-1 또는 CloudFront 배포가 구성된 지역)

  1. 이름이 /aws/cloudfront/function/edgeoptimize-routing인 로그 그룹을 찾습니다.

  2. 최신 로그 스트림을 엽니다.

  3. 에이전틱 요청의 경우 다음과 같은 토픽이 표시됩니다.

    • Adding origin group for userAgent: chatgpt-user
    • Routing to Edge Optimize origin for userAgent: chatgpt-user

  4. 비에이전틱 요청의 경우 다음이 표시됩니다.

    • Routing to Default origin for userAgent: ...

또한 AWS Console > CloudFront > 함수 > edgeoptimize-routing​에서 지표 탭을 확인하여 호출 수 및 오류율을 볼 수 있습니다.

Lambda@Edge 로그(edgeoptimize-origin)

IMPORTANT
Lambda@Edge 로그는 us-east-1가 아닌 요청을 제공한 에지 위치 지역​의 CloudWatch에 기록됩니다. curl 명령을 실행한 위치와 가장 가까운 AWS 지역에서 CloudWatch를 확인합니다.

탐색: AWS Console > CloudWatch > 로그 그룹(본인이 올바른 지역에 있는지 확인)

  1. 이름이 /aws/lambda/us-east-1.edgeoptimize-origin인 로그 그룹을 찾습니다.

  2. 최신 로그 스트림을 엽니다.

  3. 에이전틱 요청의 경우 다음과 같은 토픽이 표시됩니다.

    • Calling Edge Optimize Origin for agentic requests - 기본 경로입니다.
    • Calling Default Origin in case of failover for agentic requests - 장애 조치 경로입니다.
    • Failover Triggered for agentic requests - 원본-응답 장애 조치 감지입니다.

로그 그룹이 없으면 4단계에서 IAM 권한이 올바르게 업데이트되었는지 확인합니다. 요청을 제공한 에지 위치가 예상과 다를 수 있으므로 근처의 다른 AWS 지역도 확인하십시오.

문제 해결

문제
가능한 원인
솔루션
에이전틱 요청에 대한 응답에 x-edgeoptimize-request-id 없음
원본 그룹이 Edge Optimize로 라우팅되지 않음
YOUR_DEFAULT_ORIGIN이 CloudFront 함수 코드에서 올바르게 대체되었는지 확인합니다(2단계).
에이전틱 요청에 대한 403 오류
API 키가 잘못되었거나 누락됨
Edge Optimize 원본 사용자 지정 헤더에서 x-edgeoptimize-api-key 헤더 값을 확인합니다(1단계).
Lambda@Edge에 대한 CloudWatch 로그를 찾을 수 없음
잘못된 IAM 권한
CloudWatch 로그 권한 정책이 업데이트되었는지 확인합니다(4단계). 참고: Lambda@Edge 로그는 요청을 제공한 에지 지역에 표시되며 지역이 us-east-1일 필요는 없습니다.
캐시가 cache-control: no-store를 준수하지 않음
최소 TTL이 너무 높을 수 있음
캐시 정책에서 최소 TTL을 0으로 설정합니다(3단계). 최소 TTL이 이미 매우 짧은 경우 TTL이 문제가 아닐 수 있습니다.
설정 후 중단된 일반(비에이전틱) 트래픽
캐시 정책 구성 오류
새 캐시 정책을 만든 경우(시나리오 C) 원래 관리 정책에서 모든 설정을 복제했는지 확인합니다.

Edge에서 Optimize 비활성화 및 다시 재활성화

Lambda@Edge 함수(edgeoptimize-origin)는 CloudFront 동작의 원본 요청 및 원본 응답 이벤트와 연결되어 있습니다. 이 서비스는 사람 및 에이전틱을 막론하고 해당 동작을 통과하는 모든 요청에 인라인으로 실행되기 때문에 Lambda@Edge 작동 중단은 에이전틱 요청뿐만 아니라 모든 실시간 트래픽에 영향을 미칩니다. Lambda@Edge 중단을 감지하면 함수 연결을 즉시 제거하여 일반 트래픽 흐름을 기본 원본으로 복원하십시오.

Lambda@Edge 중단을 감지하는 방법

  • AWS 서비스 상태 대시보드 - AWS 서비스 상태 대시보드에서 Amazon CloudFront 또는 AWS Lambda​에 영향을 주는 활성 인시던트를 확인하십시오. 여기에 보고된 전역 또는 지역 중단은 구성이 아닌 AWS 인프라 측에 문제가 있는지 확인하는 가장 빠른 방법입니다.
  • Lambda@Edge 오류 - AWS Console > CloudFront > 모니터링 > [내 배포]​로 이동합니다. Lambda@Edge 오류 탭을 열고 실행 오류 그래프에서 실행 오류를 확인합니다. 이 값이 높으면 Lambda@Edge가 다운될 수 있습니다.

Lambda@Edge 함수 분리

탐색: AWS Console > CloudFront > 배포 > [내 배포] > 동작

  1. 동작에서 편집​을 클릭합니다.

  2. 함수 연결 섹션까지 아래로 스크롤합니다.

  3. 다음 연결을 연결 없음​으로 설정합니다.

    table 0-row-2 1-row-2 2-row-2 3-row-2
    이벤트 다음으로 변경
    뷰어 요청 연결 없음
    원본 요청 연결 없음
    원본 응답 연결 없음

    함수 연결 구성

  4. 변경 내용 저장​을 클릭합니다.

  5. CloudFront 배포가 배포를 완료할 때까지 기다립니다. 배포​에서 마지막 수정 날짜로 상태가 변경되며, 일반적으로 몇 분 이내에 수정됩니다.

배포되면 모든 트래픽이 기본 원본으로 바로 이동합니다. 구성이 삭제되지 않으므로 Lambda 함수와 해당 연결은 언제든지 복원할 수 있습니다.

Lambda@Edge 함수 재연결

탐색: AWS Console > CloudFront > 배포 > [내 배포] > 동작

  1. 동작에서 편집​을 클릭합니다.

  2. 함수 연결 섹션까지 아래로 스크롤합니다.

  3. 연결 복원:

    table 0-row-2 1-row-2 2-row-2 3-row-2
    이벤트 다음으로 설정
    뷰어 요청 edgeoptimize-routing(CloudFront 함수)
    원본 요청 4단계에서 버전이 지정된 Lambda ARN
    원본 응답 4단계에서 버전이 지정된 Lambda ARN

    4단계(버전 게시)에서 기록한 버전이 지정된 함수 ARN​을 사용합니다.

    함수 연결 구성

  4. 변경 내용 저장​을 클릭합니다.

  5. 배포가 배포를 완료할 때까지 기다린 다음 에이전틱 요청이 6단계에서 설명한 대로 x-edgeoptimize-request-id 헤더를 반환하는지 확인합니다.

사용 가능한 기회, 자동 최적화 워크플로 및 FAQ를 비롯해 Optimize at Edge에 대해 자세히 알아보려면 Optimize at Edge 개요로 돌아가십시오.

recommendation-more-help
brand-visibility-help-main-toc