Amazon S3 오리진에 대한 요청 및 응답 동작 - Amazon CloudFront

Amazon S3 오리진에 대한 요청 및 응답 동작

CloudFront에서 요청을 처리하고 Amazon S3 오리진 서버에 요청을 전달하는 방법

이 주제에는 CloudFront에서 최종 사용자 요청을 처리하고 이 요청을 Amazon S3 오리진에 전달하는 방법에 대한 자세한 내용이 포함되어 있습니다.

캐싱 시간 및 최소 TTL

CloudFront에서 다른 요청을 오리진에 전달하기 전에 객체를 CloudFront 캐시에 보관하는 시간을 제어하려면 다음을 수행합니다.

  • Cache-Control 또는 Expires 헤더 파일을 각 객체에 추가하도록 오리진을 구성합니다.

  • CloudFront 캐시 동작에 최소 TTL 값을 지정합니다.

  • 기본값인 24시간을 사용합니다.

자세한 내용은 콘텐츠가 캐시에 유지되는 기간(만료) 관리 단원을 참조하세요.

클라이언트 IP 주소

최종 사용자가 CloudFront에 요청을 보내고 X-Forwarded-For 요청 헤더를 포함하지 않는 경우, CloudFront는 TCP 연결에서 최종 사용자의 IP 주소를 가져오고 IP 주소를 포함하는 X-Forwarded-For 헤더를 추가하고 오리진에 요청을 전달합니다. 예를 들어, CloudFront가 TCP 연결에서 IP 주소 192.0.2.2를 가져오면 오리진에 다음 헤더를 전달합니다.

X-Forwarded-For: 192.0.2.2

최종 사용자가 CloudFront에 요청을 보내고 X-Forwarded-For 요청 헤더를 포함하는 경우, CloudFront는 TCP 연결에서 최종 사용자의 IP 주소를 가져와 X-Forwarded-For 헤더의 끝에 첨부하고 오리진에 요청을 전달합니다. 예를 들어, 최종 사용자 요청에 X-Forwarded-For: 192.0.2.4,192.0.2.3이 포함되고 CloudFront가 TCP 연결에서 IP 주소 192.0.2.2를 가져오면 오리진에 다음 헤더를 전달합니다.

X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2

참고

X-Forwarded-For 헤더에는 IPv4 주소(예: 192.0.2.44)와 IPv6 주소(예: 2001:0db8:85a3:0000:0000:8a2e:0370:7334)가 포함됩니다.

조건부 GET

CloudFront는 엣지 캐시에서 만료된 객체에 대한 요청을 받으면 이 요청을 Amazon S3 오리진으로 전달하여 최신 버전의 객체를 가져오거나 CloudFront 엣지 캐시에 이미 최신 버전이 있는지 Amazon S3의 확인을 받습니다. Amazon S3에서는 처음에 CloudFront에 객체를 보낼 때 ETag 값과 LastModified 값을 응답에 포함하여 보냈습니다. CloudFront에서 Amazon S3에 전달하는 새 요청에서 CloudFront는 다음 중 하나 또는 둘 모두를 추가합니다.

  • 만료된 버전의 객체에 대한 If-Match 값을 포함하는 If-None-Match 또는 ETag 헤더

  • 만료된 버전의 객체에 대한 If-Modified-Since 값을 포함하는 LastModified 헤더

Amazon S3에서는 이 정보를 사용하여 객체가 업데이트되는지와, 그에 따라 전체 객체를 CloudFront에 반환할지 아니면 HTTP 304 상태 코드만 반환할지(수정되지 않음) 여부를 결정합니다.

Cookies

Amazon S3는 쿠키를 처리하지 않습니다. 쿠키를 Amazon S3 오리진에 전달하도록 캐시 동작을 구성하는 경우, CloudFront에서는 이 쿠키를 전달하지만 Amazon S3에서는 이를 무시합니다. 향후 동일한 객체에 대한 모든 요청은 쿠키 변경 여부와 관계없이 캐시에 들어 있는 기존 객체로 처리합니다.

CORS(Cross-Origin Resource Sharing)

CloudFront에서 Amazon S3 CORS(Cross-Origin Resource Sharing) 설정을 준수하도록 하려는 경우 선택한 헤더를 Amazon S3로 전달하도록 CloudFront를 구성합니다. 자세한 내용은 요청 헤더 기반의 콘텐츠 캐싱 단원을 참조하세요.

본문이 포함되는 GET 요청

최종 사용자 GET 요청에 본문이 포함되는 경우, CloudFront에서는 HTTP 상태 코드 403(금지됨)을 최종 사용자에게 반환합니다.

HTTP 메소드

지원되는 모든 HTTP 메소드를 처리하도록 CloudFront를 구성하는 경우, CloudFront에서는 최종 사용자의 다음 요청을 수락하고 이를 Amazon S3 오리진에 전달합니다.

  • DELETE

  • GET

  • HEAD

  • OPTIONS

  • PATCH

  • POST

  • PUT

CloudFront에서는 GETHEAD 요청에 대한 응답을 항상 캐싱합니다. 또한 OPTIONS 요청에 대한 응답을 캐싱하도록 CloudFront를 구성할 수도 있습니다. CloudFront에서는 다른 메서드를 사용하는 요청에 대한 응답을 캐싱하지 않습니다.

Amazon S3 버킷을 배포용 오리진으로 사용하는 경우와 CloudFront 원본 액세스 ID를 사용하는 경우, POST 요청은 일부 Amazon S3 리전에서 지원되지 않으며 해당 리전의 PUT 요청에는 추가 헤더가 필요합니다. 자세한 내용은 서명 버전 4 인증만 지원하는 Amazon S3 리전에서 OAI 사용 단원을 참조하세요.

다중 파트 업로드를 사용하여 객체를 Amazon S3 버킷에 추가하려는 경우, CloudFront 원본 액세스 ID를 배포에 추가하고 이 원본 액세스 ID에 필요한 사용 권한을 부여해야 합니다. 자세한 내용은 원본 액세스 ID(OAI)를 사용하여 Amazon S3 콘텐츠에 대한 액세스 제한 단원을 참조하세요.

중요

CloudFront에서 지원하는 모든 HTTP 메서드를 허용하고 Amazon S3에 전달하도록 CloudFront를 구성하는 경우, Amazon S3 콘텐츠에 대한 액세스를 제한하는 CloudFront 원본 액세스 ID를 만들어 이 원본 액세스 ID에 필수 사용 권한을 부여해야 합니다. 예를 들어, PUT를 사용할 의도로 이러한 메서드를 허용 및 전달하도록 CloudFront를 구성한 경우, 최종 사용자에 의해 삭제되는 것을 원치 않는 리소스를 이들이 삭제할 수 없도록 DELETE 요청을 적절히 처리하여 Amazon S3 버킷 정책 또는 ACL을 구성해야 합니다. 자세한 내용은 원본 액세스 ID(OAI)를 사용하여 Amazon S3 콘텐츠에 대한 액세스 제한 단원을 참조하세요.

Amazon S3에서 지원되는 동작에 대한 자세한 내용은 Amazon S3 설명서를 참조하십시오.

CloudFront에서 제거하거나 업데이트하는 HTTP 요청 헤더

CloudFront는 Amazon S3 오리진에 요청을 전달하기 전에 몇몇 헤더를 제거하거나 업데이트합니다. 대부분의 헤더에서 이 동작은 사용자 지정 오리진에서의 동작과 같습니다. HTTP 요청 헤더의 전체 목록과 CloudFront에서 이를 처리하는 방법은 HTTP 요청 헤더 및 CloudFront 동작(사용자 지정 및 S3 오리진) 단원을 참조하십시오.

요청의 최대 길이 및 최대 URL 길이

경로, 쿼리 문자열(있는 경우), 헤더를 모두 포함한 요청의 최대 길이는 20,480바이트입니다.

CloudFront에서는 이 요청으로부터 URL을 구성합니다. 이 URL의 최대 길이는 8,192바이트입니다.

요청 또는 URL이 이 최대값을 초과할 경우 CloudFront에서는 HTTP 요청 코드 413(요청 개체가 너무 큼)을 반환한 후 최종 사용자와의TCP 연결을 종료합니다.

OCSP 스테이플링

최종 사용자가 객체에 대한 HTTPS 요청을 제출할 때 CloudFront 또는 최종 사용자는 CA(인증 기관)을 통해 도메인의 SSL 인증서가 해지되지 않았는지 확인해야 합니다. OCSP 스테이플링은 CloudFront에서 인증서의 유효성을 검사하고 CA로부터 응답을 캐싱할 수 있도록 함으로써 클라이언트가 CA를 통해 직접 인증서의 유효성을 검사하지 않아도 되므로 인증서 유효성 검사 속도가 향상됩니다.

OSCP 스테이플링의 성능 개선은 CloudFront에서 같은 도메인 내의 객체에 대해 많은 HTTPS 요청을 받은 경우 더욱 확연히 드러납니다. CloudFront 엣지 로케이션의 각 서버는 개별적인 유효성 검사 요청을 제출해야 합니다. CloudFront에서 같은 도메인에 대해 다수의 HTTPS 요청을 받은 경우, 엣지 로케이션의 각 서버에서는 곧 CA로부터 SSL 핸드쉐이크의 패킷에 "스테이플"할 수 있다는 응답을 받습니다. 최종 사용자가 인증서가 유효하다는 조건을 충족하면 CloudFront에서는 요청된 객체를 제공할 수 있습니다. 배포가 CloudFront 엣지 로케이션에서 많은 양의 트래픽을 받지 않는 경우, 새로운 요청은 아직 CA를 통해 인증서의 유효성을 검사하지 않은 서버로 리디렉션될 가능성이 높습니다. 그러한 경우, 최종 사용자는 유효성 검사 단계를 개별적으로 수행하고 CloudFront 서버에서는 객체를 제공합니다. 해당 CloudFront 서버에서는 또한 유효성 검사 요청을 CA에 제출하고, 다음에 동일한 도메인 이름을 포함한 요청을 수신하면 CA로부터 유효성 검사 응답을 받습니다.

Protocols

CloudFront에서는 HTTP 또는 HTTPS 요청을 최종 사용자 요청의 프로토콜(HTTP 또는 HTTPS)을 바탕으로 오리진 서버에 전달합니다.

중요

웹 사이트 엔드포인트로 Amazon S3 버킷이 구성되어 있는 경우, Amazon S3에서 해당 구성으로 HTTPS 연결을 지원하지 않으므로 HTTPS를 사용하여 오리진과 통신하도록 CloudFront를 구성할 수 없습니다.

쿼리 문자열

CloudFront에서 쿼리 문자열 파라미터를 Amazon S3 오리진에 전달할지 여부를 구성할 수 있습니다. 자세한 내용은 쿼리 문자열 파라미터 기반의 콘텐츠 캐싱 단원을 참조하세요.

오리진 연결 제한 시간 및 시도 횟수

오리진 연결 제한 시간은 CloudFront가 오리진에 대한 연결을 설정하려고 할 때 기다리는 시간(초)입니다.

오리진 연결 시도는 CloudFront가 오리진에 대한 연결을 시도하는 횟수입니다.

이러한 설정은 모두 CloudFront가 보조 오리진에 대해 장애 조치하거나(오리진 그룹의 경우) 뷰어에 대한 오류 응답을 반환하기 전에 오리진에 대한 연결을 시도하는 시간을 결정합니다. 기본적으로 CloudFront는 보조 오리진에 연결하거나 오류 응답을 반환하기 전에 30초(각각 10초 동안 3회 시도)까지 기다립니다. 더 짧은 연결 제한 시간, 더 적은 시도 횟수 중 하나 또는 둘 다를 지정하여 이 시간을 줄일 수 있습니다.

자세한 내용은 오리진 제한 시간 및 시도 횟수 제어 단원을 참조하세요.

오리진 응답 제한 시간

오리진 응답 제한 시간(오리진 읽기 제한 시간 또는 오리진 요청 제한 시간이라고도 함)은 다음 두 값에 모두 적용됩니다.

  • CloudFront가 오리진에 요청을 전달한 후 응답을 기다리는 시간(초).

  • CloudFront가 오리진으로부터 응답 패킷을 수신한 후 다음 패킷을 수신할 때까지 대기하는 시간(초).

CloudFront 동작은 최종 사용자 요청의 HTTP 메서드에 따라 달라집니다.

  • GETHEAD 요청 – 오리진에서 30초 내에 응답하지 않거나 30초 동안 응답이 중지된 경우, CloudFront에서는 연결을 끊습니다. 지정된 오리진 연결 시도 횟수가 1보다 많으면 CloudFront가 다시 연결을 설정하려고 시도합니다. CloudFront는 오리진 연결 시도 설정 값에 따라 최대 3회까지 시도합니다. 오리진이 마지막 시도에 응답하지 않는 경우, CloudFront에서는 동일한 오리진의 콘텐츠에 대해 다른 요청을 받을 때까지 다시 시도하지 않습니다.

  • DELETE, OPTIONS, PATCH, PUTPOST 요청 – 오리진에서 30초 내에 응답하지 않는 경우, CloudFront에서는 연결을 끊고 오리진에 다시 연결을 시도하지 않습니다. 필요한 경우 클라이언트는 요청을 다시 제출할 수 있습니다.

Amazon S3 오리진(정적 웹 사이트 호스팅으로 구성되지 않은 S3 버킷)에 대한 응답 제한 시간을 변경할 수 없습니다.

동일 객체에 대한 동시 요청(트래픽 스파이크)

CloudFront 엣지 로케이션에서 객체에 대한 요청을 받을 때 객체가 현재 캐시에 있지 않거나 객체가 만료된 경우, CloudFront에서는 즉시 요청을 Amazon S3 오리진으로 보냅니다. 트래픽 스파이크가 있는 경우 — Amazon S3에서 첫 번째 요청에 응답하기 전에 동일 객체에 대한 추가 요청이 엣지 로케이션에 도착하는 경우 — CloudFront는 객체에 대한 추가 요청을 오리진에 전달하기 전에 작업을 일시 중단합니다. 일반적으로는 후속 요청에 응답하기 전에 첫 번째 요청에 대한 응답이 CloudFront 엣지 로케이션에 도착하게 됩니다. 이러한 일시 중단은 Amazon S3에 불필요하게 로드가 걸리는 것을 줄여 줍니다. 요청 헤더나 쿼리 문자열에 따라 캐싱하도록 CloudFront를 구성하는 등의 이유로 추가 요청이 동일하지 않은 경우, CloudFront에서는 모든 고유한 요청을 오리진에 전달합니다.

오리진의 응답에 Cache-Control: no-cache 헤더가 포함된 경우, CloudFront에서는 일반적으로 동일 객체에 대한 다음 요청을 이 오리진에 전달하여 객체가 업데이트되었는지 여부를 확인합니다. 그러나 트래픽 스파이크가 발생하여 CloudFront에서 첫 번째 요청을 오리진에 전달한 후에 작업이 일시 중단된 경우, CloudFront에서 오리진의 응답을 받기 전에 복수 개의 최종 사용자 요청이 도착할 수 있습니다. CloudFront에서 Cache-Control: no-cache 헤더가 포함된 응답을 받은 경우, 원래 요청한 최종 사용자와 일시 중지 중에 객체를 요청한 모든 최종 사용자에 대한 응답으로 객체를 전달합니다. 오리진에서 응답이 도착한 후에는 CloudFront에서 동일 객체에 대한 다음 최종 사용자 요청을 오리진에 전달합니다. CloudFront 액세스 로그에서, 첫 번째 요청은 Miss 열에서 x-edge-result-type로 식별되고 CloudFront에서 일시 중지 중에 받은 모든 후속 요청은 Hit로 식별됩니다. 로그 파일 형식에 대한 자세한 내용은 표준 로그 파일 필드 단원을 참조하십시오.

CloudFront에서 Amazon S3 오리진 서버의 요청을 처리하는 방법

이 주제에는 CloudFront가 Amazon S3 오리진에서 요청을 처리하는 방법에 대한 자세한 내용이 포함되어 있습니다.

취소된 요청

객체가 엣지 캐시에 있지 않은 경우 최종 사용자가 CloudFront가 오리진에서 객체를 가져온 뒤 요청된 객체를 제공하기 전에 브라우저 닫기 등으로 세션을 종료하면, CloudFront에서는 엣지 로케이션의 객체를 캐싱하지 않습니다.

CloudFront에서 제거하거나 업데이트하는 HTTP 응답 헤더

CloudFront는 Amazon S3 오리진에서 최종 사용자에게 응답을 전달하기 전에 다음 헤더 필드를 제거하거나 업데이트합니다.

  • Set-Cookie – 쿠키를 전달하도록 CloudFront를 구성하는 경우, Set-Cookie 헤더 필드가 클라이언트에 전달됩니다. 자세한 내용은 쿠키 기반의 콘텐츠 캐싱 단원을 참조하세요.

  • Trailer

  • Transfer-Encoding – Amazon S3 오리진에서 이 헤더 필드를 반환하는 경우, CloudFront에서는 최종 사용자에게 응답을 반환하기 전에 chunked에 값을 설정합니다.

  • Upgrade

  • Via – CloudFront는 최종 사용자에 대한 응답으로 값을 다음과 같이 설정합니다.

    Via: http-version alphanumeric-string.cloudfront.net (CloudFront)

    예를 들어, 클라이언트가 HTTP/1.1을 통해 요청한 경우 값은 다음과 같습니다.

    Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)

최대 파일 크기

CloudFront에서 최종 사용자에게 반환하는 응답 본문의 최대 크기는 30GB입니다. 여기에는 Content-Length 헤더 값으로 지정하지 않은 조각난 전송 응답이 포함됩니다.

Redirects

모든 요청을 다른 호스트 이름으로 리디렉션하도록 Amazon S3 버킷을 구성할 수 있습니다. 이 대상은 다른 Amazon S3 버킷 또는 HTTP 서버가 될 수 있습니다. 모든 요청을 리디렉션하도록 버킷을 구성하는 경우와 버킷이 CloudFront 배포에 대한 오리진인 경우, 배포의 도메인 이름(예: d111111abcdef8.cloudfront.net) 또는 배포와 연결된 대체 도메인 이름(CNAME)(예: example.com)을 사용하여 모든 요청을 CloudFront 배포에 리디렉션하도록 버킷을 구성하는 것이 좋습니다. 그렇지 않은 경우 최종 사용자는 CloudFront를 우회하도록 요청하고 객체는 새 오리진에서 직접 제공됩니다.

참고

요청을 대체 도메인 이름으로 리디렉션하는 경우, CNAME 레코드를 추가하여 도메인에 대한 DNS 서비스 역시 업데이트해야 합니다. 자세한 내용은 대체 도메인 이름(CNAME)을 추가하여 파일에 대해 사용자 지정 URL 사용 단원을 참조하세요.

모든 요청을 리디렉션하도록 버킷을 구성했을 경우 다음과 같은 상황이 발생합니다.

  1. 브라우저 등의 최종 사용자가 CloudFront에서 객체를 요청합니다.

  2. CloudFront에서는 이 요청을 배포에 대한 오리진인 Amazon S3 버킷에 전달합니다.

  3. Amazon S3에서는 HTTP 상태 코드 301(영구적으로 옮겨짐)과 함께 새 위치를 반환합니다.

  4. CloudFront에서는 리디렉션 상태 코드와 새 위치를 캐싱하고 최종 사용자에게 값을 반환합니다. CloudFront는 이 리디렉션을 따라가지 않고 새 위치에서 객체를 가져옵니다.

  5. 최종 사용자는 객체에 대한 다른 요청을 보내지만, 이때 최종 사용자는 CloudFront에서 가져온 새 위치를 지정합니다.

    • Amazon S3 버킷에서 모든 요청을 CloudFront 배포로 리디렉션하는 경우, CloudFront에서는 배포의 도메인 이름 또는 대체 도메인 이름을 사용하여 새 위치의 Amazon S3 버킷 또는 HTTP 서버에서 객체를 요청합니다. 새 위치에서 객체를 반환하는 경우, CloudFront에서는 최종 사용자에게 이를 반환하고 엣지 로케이션에 이를 캐싱합니다.

    • Amazon S3 버킷에서 요청을 다른 위치로 리디렉션하는 경우, 두 번째 요청은 CloudFront를 우회합니다. 새 위치의 Amazon S3 버킷 또는 HTTP 서버에서 최종 사용자에게 직접 객체를 반환하므로 객체는 CloudFront 엣지 캐시에서 캐싱되지 않습니다.