Amazon CloudFront FAQ

Amazon CloudFront는 비즈니스 및 웹 애플리케이션 개발자에게 짧은 지연 시간과 빠른 데이터 전송 속도를 사용하여 콘텐츠를 간편하고 비용 효율적으로 배포할 수 있는 방법을 제공합니다. 모든 AWS 인프라 서비스와 마찬가지로 Amazon CloudFront는 장기 약정 또는 최소 요금이 필요 없고 사용량에 따라 지불하는 셀프 서비스입니다. CloudFront를 활용하면 엣지 로케이션의 글로벌 네트워크를 사용하여 최종 사용자에게 파일이 전송됩니다.

Amazon CloudFront에서는 다음과 같은 작업을 수행할 수 있는 간단한 API를 제공합니다.

• 전 세계에 있는 엣지 로케이션의 네트워크를 사용해 요청을 처리하여 짧은 지연 시간과 빠른 데이터 전송 속도로 콘텐츠를 배포합니다.
• 계약 및 최소 약정 없이 시작할 수 있습니다.

Amazon CloudFront 세부 정보 페이지에서 ‘무료 계정 생성’ 버튼을 클릭합니다. Amazon CloudFront를 통해 제공되는 파일의 오리진으로 다른 AWS 서비스를 선택할 경우, CloudFront 배포를 생성하기 전에 해당 서비스에 가입해야 합니다.

Amazon CloudFront를 사용하려면 다음을 수행합니다.

• 정적 파일의 경우 파일의 가장 신뢰할 수 있는 버전을 하나 이상의 오리진 서버에 저장합니다. 이는 Amazon S3 버킷이 될 수 있습니다. 개인화 또는 사용자 지정된 동적 생성 콘텐츠의 경우 Amazon EC2 또는 다른 웹 서버를 오리진 서버로 사용할 수 있습니다. 이들 오리진 서버는 Amazon CloudFront를 통해 배포될 사용자 콘텐츠를 저장하거나 생성합니다.
• 간단한 API 호출을 통해 Amazon CloudFront에 오리진 서버를 등록합니다. 이 호출은 Amazon CloudFront 서비스를 통해 오리진 서버에서 배포하는 데 사용할 수 있는 CloudFront.net 도메인 이름을 반환합니다. 예를 들어 Amazon S3 버킷 “bucketname.s3.amazonaws.com”을 모든 사용자 정적 콘텐츠의 오리진으로 등록하고 Amazon EC2 인스턴스 “dynamic.myoriginserver.com”을 모든 동적 콘텐츠에 대해 등록할 수 있습니다. 그러면 API 또는 AWS Management Console을 사용하여 배포 도메인 이름으로 “abc123.cloudfront.net”을 반환할 Amazon CloudFront 배포를 만들 수 있습니다.
• cloudfront.net 도메인 이름 또는 웹 애플리케이션, 미디어 플레이어 또는 웹 사이트에서 만든 CNAME 별칭을 포함합니다. cloudfront.net 도메인 이름(또는 CNAME)을 사용한 각 요청은 최고의 성능으로 콘텐츠를 전송하기에 적합한 엣지 로케이션로 라우팅되고 해당 엣지 로케이션에서는 파일의 로컬 사본을 사용해 요청을 처리합니다. 로컬 사본을 사용할 수 없는 경우, Amazon CloudFront가 오리진에서 사본을 받게 됩니다. 그러면 이후에 발생하는 요청의 엣지 로케이션에서 이 사본을 사용할 수 있습니다.

Amazon CloudFront는 엣지 로케이션과 리전별 엣지 캐시로 구성된 글로벌 네트워크를 통해 콘텐츠 사본을 최종 사용자에게 가깝게 캐싱합니다. Amazon CloudFront는 사용자와 가장 가까운 엣지 로케이션에서 최종 사용자 요청이 처리되도록 보장합니다. 그 결과 최종 사용자 요청이 전송되는 거리가 짧아져서 최종 사용자에 대한 성능이 향상됩니다. 엣지 로케이션과 리전 엣지 캐시에 캐시되지 않은 파일의 경우 Amazon CloudFront는 오리진 서버와 지속적인 연결을 유지하여 해당 파일을 가능한 한 빨리 오리진 서버에서 가져올 수 있습니다. 마지막으로 Amazon CloudFront는 추가적인 최적화 도구(예: 더 넓은 TCP 초기 정체 창)를 사용하여 콘텐츠를 최종 사용자에게 전달하는 동안 더 높은 성능을 제공합니다.

다른 AWS 서비스와 마찬가지로, Amazon CloudFront는 최소 약정이 없으며 사용한 만큼만 비용을 지불합니다. 직접 파일을 호스팅하는 경우에 비해 Amazon CloudFront는 인터넷의 여러 사이트에서 캐시 서버의 네트워크를 운영하는 데 따르는 비용과 복잡성을 줄여주며 잠재적 트래픽 스파이크 문제를 처리하기 위해 용량을 과도하게 프로비저닝해야 할 필요가 없습니다. 또한 Amazon CloudFront는 엣지 로케이션에서 동일 파일에 대한 동시다발적인 최종 사용자 요청을 오리진 서버에 대한 단일 요청으로 축소하는 등의 기술을 사용합니다. 이렇게 하면 오리진 서버의 로드가 줄어들어 오리진 인프라의 규모를 조정해야 할 필요성이 감소하므로, 비용을 추가로 절감할 수 있습니다.

또한, AWS 오리진(예: Amazon S3, Amazon EC2 등)을 사용 중인 경우 2014년 12월 1일부터는 Amazon CloudFront로 전송되는 AWS 데이터에 대해 더 이상 전송 비용이 부과되지 않습니다. 이러한 사항은 모든 AWS 리전에서 모든 글로벌 CloudFront 엣지 로케이션으로 데이터를 전송하는 경우에 적용됩니다.

Amazon CloudFront는 사용자가 파일에 설정한 표준 캐시 제어 헤더를 사용하여 정적 및 동적 콘텐츠를 식별합니다. 단일 Amazon CloudFront 배포를 사용하여 모든 콘텐츠를 전송하면 성능 최적화가 사용자의 전체 웹 사이트 또는 웹 애플리케이션에 적용되도록 할 수 있습니다. AWS 오리진을 사용하면 오리진 경로를 추적 및 조정하고, 시스템 상태를 모니터링하며, 문제 발생 시 신속하게 응답할 수 있는 AWS 기능에서 비롯된 향상된 성능, 안정성 및 사용 편의성, 그리고 Amazon CloudFront와 다른 AWS 서비스의 통합이라는 이점을 누릴 수 있습니다. 또한 정적 객체에는 Amazon S3를 사용하고, 동적 콘텐츠에는 Amazon EC2를 사용하고, 타사 콘텐츠는 사용자 지정 오리진을 사용하는 등 단일 사이트에서도 다양한 유형의 콘텐츠에 서로 다른 오리진을 사용하면서 사용한 만큼만 요금을 지불하는 이점을 누릴 수 있습니다.

Amazon CloudFront는 인기 웹 사이트 이미지, 동영상, 미디어 파일, 소프트웨어 다운로드 등 엣지 전송의 이점을 활용하고 액세스 빈도가 높은 정적 콘텐츠를 배포하는 데 적합합니다.

Amazon CloudFront를 사용하면 계약이나 높은 가격에 대한 부담 없이 고성능 콘텐츠 전송의 이점을 빠르게 누릴 수 있습니다. Amazon CloudFront는 모든 개발자가 셀프 서비스 모델을 통해 저렴하고 사용량에 따라 지불하는 요금제에 액세스할 수 있도록 지원합니다. 이 외에도 개발자는 다른 Amazon Web Services와 긴밀하게 통합하는 이점을 얻을 수 있습니다. 이 솔루션에서는 Amazon S3, Amazon EC2 및 Elastic Load Balancing을 간편하게 오리진 서버로 사용할 수 있으며, 개발자는 이를 통해 내구성 높은 스토리지와 고성능 전송의 이점을 동시에 누릴 수 있습니다. Amazon CloudFront를 Amazon Route 53 및 AWS CloudFormation과 통합하면 손쉽게 구성할 수 있을 뿐만 아니라, 추가적인 성능 이점도 누릴 수 있습니다.

Amazon CloudFront에서는 HTTP 또는 WebSocket 프로토콜을 사용하여 전송할 수 있는 콘텐츠를 지원합니다. 여기에는 HTML 또는 PHP 페이지와 같은 동적 웹페이지와 애플리케이션, 또는 WebSocket 기반 애플리케이션이 포함되며 웹사이트 이미지, 오디오, 비디오, 미디어 파일 또는 소프트웨어 다운로드와 같이 웹 애플리케이션의 일부를 이루는 보편적인 정적 파일도 모두 포함됩니다. 또한 Amazon CloudFront에서는 HTTP를 통한 라이브 또는 온디맨드 미디어 스트리밍 전송을 지원합니다.

예. Amazon CloudFront는 원본 및 최종 콘텐츠 버전(정적 및 동적)을 보유하고있는 모든 오리진 서버와 연동됩니다. 사용자 지정 오리진을 사용하는 데 따른 추가 요금은 없습니다.

CloudFront 배포에 오리진을 추가할 때마다 백업 오리진을 할당할 수 있습니다. 이렇게 하면 기본 오리진을 이용할 수 없는 상황이 되어도 백업 오리진을 사용하여 자동으로 트래픽을 처리할 수 있습니다. HTTP 4xx/5xx 상태 코드를 조합하여 선택하면 되는데, 이는 기본 오리진에서 반환될 경우 백업 오리진에 대한 장애 조치를 트리거합니다. 오리진 2개는 AWS 오리진과 AWS 이외 오리진을 조합한 것이면 어떤 것이든 가능합니다.

예. Amazon CloudFront SLA에서는 고객의 월간 가동 시간이 결제 주기의 서비스 약정보다 낮을 경우 서비스 크레딧을 제공합니다. 자세한 내용은 여기에서 확인할 수 있습니다.

예. AWS Management Console의 간단한 포인트 앤 클릭 방식의 웹 인터페이스를 통해 Amazon CloudFront를 구성하고 관리할 수 있습니다. AWS Management Console에서는 Amazon CloudFront의 기능을 대부분 지원하므로, 코드를 작성하거나 소프트웨어를 설치하지 않고도 전송 지연 시간이 짧은 Amazon CloudFront를 활용할 수 있습니다. https://console.aws.amazon.com에서 무료로 AWS Management Console에 액세스할 수 있습니다.

AWS 리소스 센터에서 다양한 프로그래밍 언어로 Amazon CloudFront 배포 및 라이브러리를 관리할 수 있는 여러 가지 도구가 제공됩니다.

예. 2가지 방법으로 Zone Apex(example.com)를 Amazon CloudFront 배포에 지정할 할 수 있습니다.

AWS의 신뢰할 수 있는 DNS 서비스인 Amazon Route 53를 사용하여 ALIAS 레코드를 구성할 수 있습니다. 이러한 레코드를 활용하면 DNS 이름의 apex 또는 루트(example.com)를 Amazon CloudFront 배포에 매핑할 수 있습니다. 그런 다음, Amazon Route 53는 CloudFront 배포를 위한 올바른 IP 주소를 사용하여 ALIAS 레코드에 대한 각 요청에 응답합니다. Route 53는 CloudFront 배포에 매핑되어 있는 ALIAS 레코드에 대한 쿼리에 대해서는 요금을 청구하지 않습니다.

또는 CloudFront의 Anycast 고정 IP를 사용하면 모든 DNS 공급자를 사용하여 apex 도메인을 CloudFront 배포에 지정할 수 있습니다. CloudFront에서 제공되는 고정 IP 주소 3개를 사용하여 표준 A 레코드를 생성하기만 하면 됩니다. 이러한 기능은 apex 도메인 지원을 Route 53 이상으로 확장합니다. 그와 동시에 트래픽은 여전히 가장 가까운 엣지 로케이션으로 자동 라우팅되어 전 세계에 고성능 콘텐츠 전송이 가능합니다.

CloudFront는 엣지 로케이션이라고 하는 전 세계 데이터 센터의 네트워크를 통해 콘텐츠를 제공합니다. 리전별 엣지 캐시는 최종 사용자에게 콘텐츠를 직접 제공하는 글로벌 엣지 로케이션과 오리진 웹 서버 사이에 위치해 있습니다. 이러한 특성은 오리진 리소스의 규모 조정에 따른 운영 부담 및 비용을 줄이면서, 최종 사용자의 성능을 높이는 데에도 효과적입니다.

Amazon CloudFront에는 최종 사용자와 가까운 곳에서 추가 캐싱을 제공하는 전 세계적으로 분포된 여러 리전별 엣지 캐시(REC)가 있습니다. 리전별 엣지 캐시는 최종 사용자에게 콘텐츠를 직접 제공하는AWS 엣지 로케이션과 오리진 웹 서버 사이에 위치합니다. 캐시된 객체의 사용 빈도가 줄어들면 개별 엣지 로케이션에서 해당 객체를 제거하여 더 널리 사용되는 콘텐츠를 위한 공간을 확보할 수 있습니다. 리전별 엣지 캐시는 개별 엣지 로케이션보다 캐시 대역이 크기 때문에, 캐시에 객체를 더 오래 보관할 수 있습니다. 이를 통해 더 많은 콘텐츠를 최종 사용자와 가까운 거리가 유지할 수 있으므로 CloudFront가 오리진 웹서버로 돌아가야 할 필요성이 줄어들고 최종 사용자를 위한 전반적인 성능도 향상됩니다. 예를 들어, 이제 유럽의 CloudFront 엣지 로케이션은 오리진 웹 서버로 돌아가기 전에 프랑크푸르트의 리전별 엣지 캐시로 이동하여 객체를 가져옵니다. 리전별 엣지 캐시 로케이션은 S3, EC2 또는 사용자 지정 오리진과 같은 모든 오리진에서 사용할 수 있습니다. 애플리케이션 오리진을 현재 호스팅하는 리전에서는 REC를 건너뜁니다.

예. 이 기능은 현재 신규 및 기존 CloudFront 배포에서 기본적으로 활성화되어 있으므로 CloudFront 배포를 변경할 필요는 없습니다. 이 기능을 사용하는 데 따른 추가 요금은 없습니다.

Amazon CloudFront는 엣지 로케이션과 리전별 엣지 캐시로 구성된 글로벌 네트워크를 사용하여 콘텐츠를 전송합니다. 여기에서 Amazon CloudFront 위치가 나와 있는 전체 목록을 확인할 수 있습니다.

예. 지역 제한 기능을 사용하면 특정 국가의 사용자만 내 콘텐츠에 액세스하도록 지정할 수 있습니다. 또한, 특정 국가의 사용자가 내 콘텐츠에 액세스할 수 없도록 지정할 수도 있습니다. 어떤 방식을 사용하든 CloudFront는 제한된 국가에서 액세스를 요청한 최종 사용자에게 HTTP 상태 코드 403(금지됨)을 표시합니다.

국가/지역 검색 데이터베이스의 IP 주소 정확도는 리전에 따라 다릅니다. 최근에 진행한 테스트에 따르면 국가 매핑에 대한 IP 주소의 전체적인 정확도는 99.8%입니다.

예. 다양한 HTTP 4xx 및 5xx 오류 응답을 위해 나만의 브랜드와 콘텐츠가 포함된 사용자 지정 오류 메시지(예: HTML 파일 또는 .jpg 그래픽)를 생성할 수 있습니다. 메시지를 생성한 다음, 오리진이 Amazon CloudFront에 지정된 오류 중 하나를 반환할 때 사용자 지정 오류 메시지를 반환하도록 CloudFront를 구성하면 됩니다.

캐시 제어 헤더를 설정하지 않을 경우, 기본적으로 각 엣지 로케이션은 해당 파일에 변경 사항이 있는지 오리진을 확인한 후 24시간이 지나 업데이트 확인 요청을 받을 때마다 파일의 업데이트된 버전이 있는지 확인합니다. 이 시간을 “만료 기간”이라고 합니다. 오리진의 파일에 캐시 제어 헤더를 설정하여 이 만료 기간을 최소 0초 또는 원하는 시간으로 설정할 수 있습니다. Amazon CloudFront는 이러한 캐시 제어 헤더를 사용하여 오리진에서 해당 파일의 업데이트된 버전이 있는지 확인해야 하는 빈도를 결정할 수 있습니다. 만료 기간이 0초로 설정된 경우 Amazon CloudFront는 모든 요청을 오리진 서버에서 다시 확인합니다. 파일이 자주 변경되지 않을 경우 만료 기간을 길게 설정하고 버전 관리 시스템을 구현하여 파일에 대한 업데이트를 관리하는 것이 좋습니다.

엣지 로케이션에서 파일을 제거할 수 있는 여러 가지 방법이 있습니다. 오리진에서 파일을 삭제해도 되고, 엣지 로케이션의 콘텐츠가 각 객체의 HTTP 헤더에 정의된 만료 기간에 도달하면 제거됩니다. 위험하거나 유해한 자료를 지정된 만료 기간 전에 제거해야 하는 경우 Invalidation API를 사용해 모든 Amazon CloudFront 엣지 로케이션에서 객체를 제거할 수 있습니다. 여기에서 무효화 요청에 대한 요금을 확인할 수 있습니다.

개별적으로 객체를 무효화할 경우, 진행 중인 배포마다 한 번에 최대 3,000개의 객체에 대한 무효화 요청을 제출할 수 있습니다. 최대 3,000개의 객체에 대한 무효화 요청 1회나 객체에 대한 최대 3,000개의 요청 또는 3,000개 객체를 초과하지 않는 선에서 이 둘을 조합하여 제출할 수 있습니다.

* 와일드카드를 사용하는 경우 진행 중인 경로에 대해 한 번에 최대 15개까지 무효화 요청을 할 수 있습니다. 진행 중인 배포마다 한번에 최대 3,000개의 개별 객체에 대한 무효화 요청이 가능합니다. 와일드카드 무효화 요청 제한은 개별적인 객체 무효화 제한과 관계가 없습니다. 이 한도를 초과하는 경우 추가 무효화 요청을 제출하면 이전 요청 중 하나가 완료될 때까지 오류가 수신됩니다.

예기치 않은 상황에서만 무효화를 사용해야 합니다. 파일을 캐시에서 자주 제거해야 한다는 것을 사전에 알고 있다면 파일에 대해 버전 관리 시스템을 구현하거나, 만료 기간을 짧게 설정하는 것이 좋습니다.

CloudFront 임베디드 접속 지점(POP)은 인터넷 서비스 제공업체(ISP) 및 모바일 네트워크 사업자(MNO) 네트워크 내에서 최종 사용자에게 가장 가깝게 배포되는 CloudFront 인프라 유형입니다. 임베디드 POP는 대규모 라이브 스트리밍 이벤트, 비디오 온디맨드(VOD) 및 게임 다운로드를 제공하도록 맞춤 제작되었습니다. 이러한 임베디드 POP는 Amazon에서 소유하고 운영하며, ISP/MNO 네트워크의 라스트 마일에 배포되어 최종 사용자를 콘텐츠 소스에 연결하는 혼잡한 네트워크에서 용량 병목 현상을 방지함으로써 성능을 개선합니다.

CloudFront 임베디드 POP는 배포 위치 및 전송하는 콘텐츠 측면에서 CloudFront POP와 다릅니다. CloudFront 임베디드 POP는 AWS 네트워크 내에 배포되는 CloudFront POP와 달리 ISP 및 MNO 네트워크에 직접 배포됩니다. 임베디드 POP는 비디오 스트림 및 게임 다운로드 같은 대규모의 캐시 가능한 트래픽을 전송하기 위해 특별히 구축된 반면, CloudFront POP는 캐시 가능한 콘텐츠와 동적 콘텐츠를 둘 다 포함하는 다양한 워크로드를 전송하도록 설계되었습니다.

CloudFront 임베디드 POP는 대규모 라이브 비디오 스트리밍, 비디오 온디맨드, 게임 다운로드 등 수많은 최종 사용자가 동시에 액세스하는 캐시 가능한 콘텐츠를 전송하도록 설계되었습니다.

아니요. CloudFront 임베디드 POP를 사용하는 데 따른 추가 요금은 없습니다.

임베디드 POP는 캐시 가능한 대규모 트래픽을 전송하기 위한 옵트인 기능입니다. AWS 영업 담당자에게 문의하여 임베디드 POP가 현재 워크로드에 적합한지 평가하세요.

아니요. 임베디드 POP용으로 특별히 배포를 새로 생성할 필요는 없습니다. 워크로드가 적합하다면 요청 시 CloudFront가 기존 배포에 임베디드 POP를 활성화합니다.

콘텐츠 전송을 위해 CloudFront 임베디드 POP 또는 CloudFront POP 중에서 하나를 선택할 필요는 없습니다. CloudFront 배포에 임베디드 POP를 활성화하면 CloudFront의 라우팅 시스템은 CloudFront POP와 임베디드 POP를 둘 다 동적으로 활용하여 콘텐츠를 전송함으로써 최종 사용자에게 최적의 성능을 보장합니다.

네트워크 내에 임베디드 POP를 배포하려면 AWS에 문의하세요.

임베디드 POP 포털을 사용하여 네트워크 내에 배포된 임베디드 POP를 관리할 수 있습니다. 임베디드 POP 포털은 AWS Interconnect Portal과 통합되며 이러한 POP의 전체 수명 주기에 연결된 다양한 태스크를 셀프 서비스 방식으로 손쉽게 수행할 수 있는 통합 인터페이스를 제공합니다. 새 어플라이언스 요청, 요청 진행 상황 추적, 성능 통계 모니터링, 지원 요청 등의 태스크가 여기에 포함됩니다. PeeringDB 계정을 사용하여 Single Sign On(SSO)으로 인증하여 포털에 액세스할 수 있습니다.

Amazon CloudFront는(CloudFront 임베디드 POP를 통한 콘텐츠 전송은 제외) 서비스 공급업체가 준수해야 하는 규정 중 가장 높은 레벨인 PCI DSS(Payment Card Industry Data Security Standard) Merchant Level 1 규정을 준수하는 서비스 세트에 포함되어 있습니다. 자세한 내용은 개발자 안내서를 참조하세요.

AWS에서는 HIPAA 규정 준수 프로그램을 확장하여 Amazon CloudFront를 HIPAA 적격 서비스로 포함했습니다(CloudFront 임베디드 POP를 통한 콘텐츠 전송은 제외). AWS와 비즈니스 제휴 계약(BAA)을 체결한 경우 Amazon CloudFront(CloudFront 임베디드 POP를 통한 콘텐츠 전송은 제외)를 사용하여 PHI(개인 건강 정보)를 더 빠르게 제공할 수 있습니다. 자세한 내용은 HIPAA 규정 준수 및 AWS 개발자 안내서를 참조하세요.

Amazon CloudFront(CloudFront 임베디드 POP를 통한 콘텐츠 전송은 제외)는 SOC(시스템 및 조직 제어) 조치를 준수합니다. SOC 보고서는 AWS가 주요 규정 준수 제어 및 목표를 달성하는 방법을 보여주는 독립적인 서드 파티 심사 보고서입니다. 자세한 내용은 AWS SOC 규정 준수 및 AWS 개발자 안내서를 참조하세요.

AWS SOC 1 또는 SOC 2 보고서는 AWS의 규정 준수 보고서에 온디맨드 방식으로 액세스할 수 있는 셀프 서비스 포털인 AWS Artifact를 통해 고객에게 제공됩니다. AWS Management Console에서 AWS Artifact에 로그인하거나 AWS Artifact 시작하기를 통해 자세히 알아보세요. 최신 AWS SOC 3 보고서는 AWS 웹 사이트에 공개되어 있습니다.

현재 Amazon CloudFront에서는 GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS 요청을 지원합니다.

Amazon CloudFront는 POST, PUT, DELETE, PATCH 요청에 대한 응답을 캐시하지 않으며 이러한 요청은 오리진 서버에 프록시됩니다. OPTIONS 요청에 대한 응답을 캐싱하는 기능은 활성화할 수 있습니다.

기존 Amazon CloudFront 배포를 보유하고 있는 경우, API 또는 AWS Management Console을 사용하여 HTTP/2를 활성화할 수 있습니다. 콘솔의 [Distribution Configuration] 페이지에서 [Supported HTTP Versions] 섹션으로 이동합니다. 여기에서 “HTTP/2, HTTP/1.1 또는 HTTP/1.0”을 선택할 수 있습니다. 새로운 모든 CloudFront 배포판에서는 HTTP/2가 자동으로 활성화됩니다.

Amazon CloudFront는 현재 최종 사용자의 클라이언트 및 브라우저에 콘텐츠를 전송할 수 있도록 HTTP/2를 지원하고 있습니다. 또한 Amazon CloudFront는 엣지 로케이션과 오리진 서버 간의 통신을 위해 HTTP/1.1을 계속해서 사용할 예정입니다.

현재는 지원하지 않습니다. 하지만 대부분의 최신 브라우저는 암호화된 연결을 통해서만 HTTP/2를 지원하고 있습니다. Amazon CloudFront와 함께 SSL을 사용하는 방법에 대한 자세한 내용은 여기를 참조하세요.

HTTP/3는 Hypertext Transfer Protocol의 세 번째 메이저 버전입니다. HTTP/3는 사용자 데이터그램 프로토콜(UDP) 기반의 스트림 멀티플렉싱된 보안 전송 프로토콜인 QUIC를 사용합니다. QUIC는 기존 전송 제어 프로토콜(TCP), TLS, HTTP/2의 기능을 결합하고 개선합니다. HTTP/3는 이전 HTTP 버전에 비해 빠른 응답 시간, 향상된 보안 등 여러 가지 이점을 제공합니다.

HTTP/3는 성능 및 복원력이 뛰어나고 안전한 새로운 인터넷 전송 프로토콜인 QUIC로 구동됩니다. CloudFront의 HTTP/3 지원은 Rust의 새로운 오픈 소스 QUIC 프로토콜 구현인 s2n-quic를 기반으로 합니다. QUIC에 대해 자세히 알아보려면 ‘Introducing s2n-quic’ 블로그를 참조하세요. 

고객은 항상 최종 사용자에게 더욱 빠르고 안전한 애플리케이션을 제공할 수 있는 방법을 모색하고 있습니다. 인터넷 침투율이 전 세계적으로 증가하고 더 많은 사용자가 모바일과 원격 네트워크를 통해 온라인에 연결됨에 따라 향상된 성능 및 신뢰성에 대한 요구가 그 어느 때보다 커지고 있습니다. HTTP/3는 여러 측면에서 이전 HTTP 버전보다 개선된 성능을 제공하므로 이러한 요구 사항을 충족할 수 있습니다.

1. 빠르고 신뢰할 수 있는 연결 - CloudFront는 HTTP/3의 TLS 핸드셰이크에 1-RTT를 사용하므로 이전 HTTP 버전에 비해 연결 설정 시간이 단축되며 해당하는 핸드셰이크 실패가 줄어듭니다.
2. 향상된 웹 성능 - CloudFront의 HTTP/3 구현은 클라이언트 측 연결 마이그레이션을 지원하므로, 연결 속도가 저하된 클라이언트 애플리케이션을 복구할 수 있으며 그 과정에서 중단을 최소화합니다. TCP와 달리 QUIC는 무손실이 아니기 때문에 패킷 손실이 높은 정체된 네트워크에 더 적합합니다. 또한 QUIC를 사용하면 WiFi 또는 셀룰러 핸드오프 중에 재연결 속도를 높일 수 있습니다.
3. 보안 - HTTP/3는 TLS 핸드셰이크 중에 교환되는 패킷을 암호화하여 이전 버전의 HTTP에 비해 더욱 포괄적인 보안을 제공합니다. 미들 장비에 의한 검사가 더 어려워지므로 개인 정보 보호가 강화되고 중간자 공격이 줄어듭니다. CloudFront의 HTTP/3 지원은 효율성 및 성능에 중점을 둔 s2n-quic와 Rust를 기반으로 합니다.
    

CloudFront 콘솔, UpdateDistribution API 작업 또는 Cloudformation 템플릿을 사용하여 신규 및 기존 Amazon CloudFront 배포에 HTTP/3를 사용하도록 설정할 수 있습니다. 콘솔의 ‘Distribution Configuration(배포 구성)’ 페이지에서 ‘Supported HTTP Versions(지원되는 HTTP 버전)’ 섹션으로 이동합니다. 여기에서 ‘HTTP/3, HTTP/2, HTTP/1.1 또는 HTTP/1.0’을 선택할 수 있습니다.

CloudFront 배포에서 HTTP/3를 사용하도록 설정하면 CloudFront가 Alt-Svc 헤더를 자동으로 추가합니다. 그런 다음, 이 헤더를 사용하여 HTTP/3 지원을 사용할 수 있음을 알리므로 사용자가 수동으로 Alt-Svc 헤더를 추가할 필요가 없습니다. 애플리케이션에서 여러 프로토콜에 대한 지원을 사용하도록 설정하는 것이 좋습니다. 이렇게 하면 애플리케이션에서 HTTP/3 연결을 설정하지 못할 경우 HTTP /1.1 또는 HTTP/2로 폴백되므로 HTTP/3를 지원하지 않는 클라이언트에서도 HTTP/1.1 또는 HTTP/2를 사용하여 HTTP/3를 사용하는 CloudFront 배포와 통신할 수 있습니다. 폴백 지원은 HTTP/3 사양의 일부로 필요하며, HTTP/3를 지원하는 모든 주요 브라우저에 의해 구현됩니다.

현재 CloudFront는 뷰어의 클라이언트 및 브라우저와 CloudFront 엣지 로케이션 간의 통신에 대해 HTTP/3를 지원합니다. 또한 CloudFront는 엣지 로케이션과 오리진 서버 간의 통신에 HTTP/1.1을 계속해서 사용할 예정입니다.

HTTP/3는 QUIC를 사용하며 여기에는 TLSv1.3이 필요합니다. 따라서 선택한 보안 정책과 관계없이 TLSv1.3과 지원되는 TLSv1.3 암호 그룹만 HTTP/3 연결을 설정하는 데 사용할 수 있습니다. 자세한 내용은 CloudFront 개발자 안내서의 최종 사용자와 CloudFront 간에 지원되는 프로토콜 및 암호 섹션을 참조하세요.

아니요. Amazon CloudFront 배포에서 HTTP/3를 사용하기 위한 별도의 요금은 없습니다. HTTP/3 요청에 대한 요금은 사용하는 요금제의 요청 요율에 따라 부과됩니다.

CloudFront SaaS Manager는 서비스형 소프트웨어(SaaS) 및 웹 개발 플랫폼 공급자가 여러 웹 사이트에서 콘텐츠 전송을 효율적으로 관리할 수 있도록 지원하는 새로운 Amazon CloudFront 기능입니다. CloudFront SaaS Manager는 조직에서 대규모 다중 테넌트 애플리케이션을 제공하고 보호하는 방법을 간소화합니다. CloudFront SaaS Manager는 재사용 가능한 구성 및 파라미터를 도입하여 운영 오버헤드를 줄입니다. 이를 통해 중복되는 구성 작업을 없애고, 고객이 웹 사이트 전체에서 일관된 설정을 유지할 수 있습니다. 또한 CloudFront SaaS Manager는 보안 설정을 사용자 지정하며, 필요한 경우 각 웹 사이트의 인증서 갱신을 자동화할 수 있는 선택적인 유연성을 제공합니다.

CloudFront SaaS Manager는 여러 웹 사이트를 효율적으로 관리해야 하는 문제에 직면한 조직을 위해 설계되었습니다. 서비스형 소프트웨어(SaaS) 및 웹 개발 플랫폼 제공업체는 테넌트의 웹 사이트 전체에서 일관된 설정을 유지할 수 있기 때문에, 특히 유용하다는 것을 알 수 있습니다. 마찬가지로 여러 기업 웹 사이트를 관리하는 기업에서는 이를 사용하여 웹 사이트를 표준화하는 동시에, 개별 사이트를 사용자 지정할 수 있는 유연성을 유지할 수 있습니다. 웹 사이트가 몇 개에 불과하거나, 각 웹 사이트에 서로 다른 CloudFront 구성이 포함되어 있는 경우 단일 테넌트(기존 방식) 배포가 더 적합할 수 있습니다.

도메인 그룹 전반의 공유 설정을 관리하려는 고객은 AWS Console 및 API를 통해 CloudFront를 옵션으로 사용할 수 있습니다. 시작하는 방법은 다음과 같습니다. 1/공유 설정 정의: 도메인 그룹의 템플릿 역할을 할 공유 설정이 포함된 다중 테넌트 배포를 생성합니다. 2/배포 테넌트 생성: 도메인과 해당 TLS 인증서를 다중 테넌트 배포에 연결할 수 있도록 지원하는 배포 테넌트를 생성합니다. 3/제어 미세 조정: 필요에 따라, 재정의를 적용하여 배포 테넌트에 대한 설정을 사용자 지정할 수 있습니다.

다중 테넌트 배포는 도메인 간에 공유하게 될 기본 구성을 정의합니다. 여기에는 오리진 구성, 캐시 동작 및 보안 설정 같은 공유 구성 설정이 포함됩니다. 표준 배포와 달리, 다중 테넌트 배포는 트래픽을 직접 처리할 수 없습니다. 이 경우 각 도메인의 고유한 요구 사항을 충족하도록 사용자 지정 가능한 파라미터화된 필드를 제공합니다. 그 예로, 도메인별 오리진 경로 또는 오리진 도메인 이름을 들 수 있습니다.

배포 테넌트는 다중 테넌트 배포를 사용하는 특정 도메인을 나타냅니다. 이러한 도메인은 다중 테넌트 배포의 기본 구성을 상속하며, 유효한 TLS 인증서가 있는 도메인 또는 하위 도메인이 하나 이상 있어야 합니다.
각 배포 테넌트에는 다음과 같은 사용자 지정 설정이 포함될 수 있습니다.

• 고유한 오리진 경로 및/또는 오리진 도메인 이름(다중 테넌트 배포의 파라미터 값을 통해 정의됨)
• 사용자 지정 TLS 인증서
• 웹 ACL 재정의
• 지역 제한 재정의
  

예. 하지만 CloudFront는 AWS Certificate Manager(ACM)와 연동되어 원활한 도메인 제어 검증 경험을 제공합니다. ACM과의 통합으로 인해 인증서 발급 및 관리 부담이 사라지고, Amazon에서 발급한 SSL/TLS 인증서에 대한 수명 주기 관리를 자동화할 수 있습니다. 다른 CA를 사용하여 인증서를 발급할 경우 ACM은 서드 파티 CA에서 발급한 인증서를 지원합니다. 이 경우 해당 인증서의 수명 주기(초기 업로드, 갱신, 후속 업로드)에 대한 책임은 고객에게 있으며, 인증서 만료가 다가오면 ACM은 CloudWatch 및 이메일을 통해 AWS 계정 소유자에게 알림을 보냅니다. 자세한 내용은 https://aws.amazon.com/certificate-manager/faqs/를 참조하세요.

예. CloudFront는 apex 또는 루트 도메인(예: example.com 대 www.example.com) 도메인에 대한 지원을 허용합니다. 고객은 Route 53를 사용하여 DNS를 관리하고, CloudFront에서 제공한 도메인을 가리키도록 apex 도메인에 대한 ALIAS 레코드를 추가할 수 있습니다. Route53를 사용하여 사용자 지정 도메인을 관리할 수 없는 고객을 위해 Anycast 고정 IP에서는 CNAME/ALIAS 레코드 대신 사용 가능한 전용 IP 주소 세트를 제공할 수 있습니다. 여기에서 자세히 알아보세요.

예. CloudFront는 생성하는 배포 테넌트 리소스의 수를 기준으로 요금이 청구됩니다. 배포 테넌트는 CloudFront 다중 테넌트 배포의 구성 설정을 상속하는 새로운 리소스입니다. 자세한 내용은 CloudFront 요금 페이지를 참조하세요.

WebSocket은 오래 유지되는 TCP 연결을 통해 클라이언트와 서버 간에 양방향 통신을 제공하는 실시간 통신 프로토콜입니다. 지속적으로 개방된 연결을 사용하면, 교환할 새로운 데이터를 확인하기 위해 클라이언트와 서버는 연결을 자주 다시 시작할 필요 없이 클라이언트와 서버가 실시간으로 서로 데이터를 전송할 수 있습니다. WebSocket 연결은 채팅 애플리케이션, 협업 플랫폼, 멀티플레이어 게임, 금융 거래 플랫폼에서 자주 사용됩니다. Amazon CloudFront와 함께 WebSocket 프로토콜을 사용하는 방법을 자세히 알아보려면 설명서를 참조하세요. 

WebSocket은 전 세계에서 사용할 수 있고, 기본적으로 지원되기 때문에 CloudFront 리소스 내에서 WebSocket 프로토콜을 활성화하기 위한 추가 구성이 필요하지 않습니다.

Amazon CloudFront는 클라이언트에 ‘Upgrade: websocket’ 헤더가 포함되어 있고, 서버가 HTTP 상태 코드 101로 응답하여 WebSocket 프로토콜로 전환할 수 있다고 확인해야만 WebSocket 연결을 설정합니다.

예. Amazon CloudFront는 SSL/TLS 프로토콜을 사용하여 암호화한 WebSocket 연결(WSS)을 지원합니다.

gRPC는 오래 유지되는 HTTP/2 연결을 통해 클라이언트와 서버 간의 양방향 통신을 허용하는 최신 오픈 소스 원격 프로시저 직접 호출(RPC) 프레임워크입니다. 지속적으로 개방된 연결을 사용하면, 교환할 새로운 데이터를 확인하기 위해 클라이언트가 연결을 자주 다시 시작할 필요 없이 클라이언트와 서버가 실시간으로 서로 데이터를 전송할 수 있습니다. gRPC는 실시간 통신 애플리케이션과 온라인 게임 같이 짧은 지연 시간과 빠른 전송 속도가 중요한 사용 사례에 적합합니다.

gRPC는 CloudFront 배포의 각 캐시 동작에서 활성화됩니다. gRPC를 활성화하면 배포에서 HTTP/2 요청과 POST 지원 요청이 모두 활성화됩니다. gRPC는 HTTP/2를 통한 POST 메서드만 지원합니다.

Amazon CloudFront는 다음 조건이 충족될 때 gRPC를 통해 통신을 수행합니다.

1. 배포에서 HTTP/2가 활성화됨
2. 캐시 동작에서 POST 요청 및 gRPC가 활성화됨
3. 클라이언트가 HTTP/2 연결을 통해 ‘application/grpc’ 값이 포함된 ‘content-type’ 헤더를 전송함

1. 보안 - gRPC는 HTTP/2를 사용하여 클라이언트에서 오리진 서버로 전달되는 트래픽을 엔드 투 엔드 방식으로 암호화합니다. 또한 gRPC를 사용하면 추가 비용 없이 AWS Shield Standard를 이용할 수 있으며, AWS WAF를 구성하여 공격으로부터 gRPC 트래픽을 보호하는 데 도움이 됩니다.
2. 성능 향상 - gRPC는 프로토콜 버퍼라는 바이너리 메시지 형식을 활용합니다. 프로토콜 버퍼는 RESTful API에 사용되는 JSON 같은 기존 페이로드보다 크기가 작습니다. 데이터가 바이너리 형식으로 되어 있어 메시지 교환 속도가 더 빠르기 때문에 프로토콜 버퍼 구문 분석에 CPU가 적게 사용됩니다. 따라서 전반적인 성능이 향상됩니다.
3. 기본 제공 스트리밍 지원 - 스트리밍은 gRPC 프레임워크에서 기본 제공되며 클라이언트 측과 서버 측 스트리밍 시맨틱을 모두 지원합니다. 따라서 스트리밍 서비스나 클라이언트를 훨씬 간단하게 구축할 수 있습니다. CloudFront의 gRPC는 다음과 같은 스트리밍 조합을 지원합니다.
   • 단방향(스트리밍 없음)
   • 클라이언트-서버 스트리밍
   • 서버-클라이언트 스트리밍
   • 양방향 스트리밍

현재는 지원하지 않습니다. CloudFront는 HTTP/2를 통한 gRPC만 지원합니다.

기본적으로 URL에 CloudFront 배포 도메인 이름(예: https://dxxxxx.cloudfront.net/image.jpg)을 사용하여 HTTPS를 통해 최종 사용자에게 콘텐츠를 전달할 수 있습니다. 자체 도메인 이름과 자체 SSL 인증서를 사용하여 HTTPS를 통해 콘텐츠를 전달하려는 경우 Amazon에서 제공하는 사용자 지정 SSL 인증서 지원 기능 중 하나를 사용할 수 있습니다. 자세히 알아보세요.

필드 레벨 암호화는 신용 카드 번호처럼 사용자가 제출한 데이터를 안전하게 오리진 서버로 업로드할 수 있도록 지원하는 CloudFront의 기능입니다. 이 기능을 사용하면 PUT/POST 요청이 오리진으로 전달되기 전에 필드별 암호화 키(사용자가 제공)를 사용하여 HTTPS 형식의 민감한 데이터를 추가로 암호화할 수 있습니다. 따라서 중요한 데이터는 애플리케이션 스택의 특정 구성 요소나 서비스에서만 해독하고 볼 수 있습니다. 필드 레벨 암호화에 대해 자세히 알아보려면 설명서에서 필드 레벨 암호화 페이지를 참조하세요.

많은 웹 애플리케이션에서는 신용 카드 번호처럼 사용자가 제출하는 민감한 데이터를 수집하며, 오리진 인프라에서 실행되는 애플리케이션 서비스에서 이를 처리합니다. 이러한 모든 웹 애플리케이션에서는 최종 사용자와 CloudFront 사이, CloudFront와 오리진 사이에 SSL/TLS 암호화를 사용합니다. 이제, 오리진은 사용자 입력을 기반으로 중요한 작업을 수행하는 다중 마이크로 서비스입니다. 하지만 이러한 마이크로 서비스 중 일부 하위 집합에서만 민감한 정보를 사용하게 됩니다. 즉, 대부분 구성 요소는 이러한 데이터에 직접 액세스할 필요가 전혀 없습니다. 잘못된 변수를 로깅하는 등의 간단한 프로그래밍 실수가 고객의 신용 카드 번호를 파일에 작성하는 결과로 이어질 수 있습니다.

필드 레벨 암호화로 CloudFront의 엣지 로케이션은 신용 카드 데이터를 암호화할 수 있습니다. 이 시점부터 프라이빗 키를 가진 애플리케이션만 민감한 필드를 복호화할 수 있습니다. 따라서 주문 이행 서비스는 암호화된 신용 카드 번호만 볼 수 있지만 지불 서비스는 신용 카드 데이터를 복호화할 수 있습니다. 이렇게 하면 높은 보안 수준이 보장되며, 애플리케이션 서비스 중 하나가 암호 텍스트를 노출해도 해당 데이터는 보호된 암호를 유지합니다.

전용 IP 사용자 정의 SSL은 전용 IP 주소를 할당하여 각 CloudFront 엣지 로케이션에서 사용자의 SSL 콘텐츠를 제공합니다. IP 주소와 SSL 인증서 간에 일대일로 매핑되어 있으므로, 전용 IP 사용자 정의 SSL은 SNI를 지원하지 않는 브라우저 및 다른 클라이언트에서 사용할 수 있습니다. 현재 IP 주소 비용 때문에 전용 IP 사용자 지정 SSL의 비용은 월 600 USD이며 시간에 비례하여 계산됩니다.

SNI 사용자 정의 SSL은 최종 사용자가 연결하려는 호스트 이름을 포함하여, 동일한 IP 주소를 통해 다중 도메인에서 SSL 트래픽을 제공하도록 허용하는 전송 계층 보안 프로토콜의 SNI 확장을 사용합니다. 전용 IP 사용자 정의 SSL과 마찬가지로, CloudFront에서는 전용 IP 사용자 정의 SSL 기능과 동일한 보안을 사용하여 각 Amazon CloudFront 엣지 로케이션의 콘텐츠를 제공합니다. SNI 사용자 정의 SSL은 Chrome 버전 6 이상(Windows XP 이상 또는 OS X 10.5.7 이상에서 실행), Safari 버전 3 이상(Windows Vista 이상 또는 Mac OS X 10.5.6. 이상에서 실행), Firefox 2.0 이상 및 Internet Explorer 7 이상(Windows Vista 이상에서 실행)을 비롯한 대부분의 최신 브라우저에서 작동합니다. SNI를 지원하지 않는 오래된 브라우저는 HTTPS 버전 콘텐츠를 로드하는 CloudFront와의 연결을 설정할 수 없습니다. SNI 사용자 정의 SSL은 표준 CloudFront 데이터 전송 및 요청 요금 이외의 추가 비용 없이 사용할 수 있습니다.

서버 이름 표시(SNI)는 Transport Layer Security(TLS) 프로토콜의 확장입니다. 이 메커니즘은 연결된 SSL 요청의 도메인(서버 이름)을 식별하므로 SSL 방법에 적절한 인증서를 사용할 수 있습니다. 따라서 여러 서버 간에 단일 IP 주소를 사용할 수 있습니다. SNI에서 서버 이름을 추가하려면 브라우저에서 이를 지원해야 합니다. 대부분의 최신 서버에서는 이 기능을 지원하지만, 오래된 일부 브라우저에서는 이를 지원하지 않습니다. 자세한 내용은 CloudFront 개발자 안내서의 SNI 섹션 또는 SNI Wikipedia 도움말을 참조하세요.

예. 이제 몇 분이면 SSL/TLS 인증서를 프로비저닝하고 이를 CloudFront 배포와 연결할 수 있습니다. 새로운 AWS Certificate Manager(ACM)를 사용하여 클릭 몇 번으로 인증서를 프로비저닝하고 CloudFront 배포에 이를 배포하기만 하면, ACM에서 인증서 갱신을 대신 관리해줍니다. ACM을 사용하면 추가 비용 없이 인증서를 프로비저닝, 배포, 및 관리할 수 있습니다.

CloudFront에서는 서드 파티 인증 기관을 통해 가져온 후 IAM 인증서 저장소에 업로드한 인증서도 계속 사용할 수 있습니다.

예. Amazon CloudFront는 비공개 콘텐츠 기능(옵션)을 제공합니다. 이 옵션을 활성화하면 Amazon CloudFront가 사용자의 요청에 안전하게 서명하여 사용자가 허용한 파일만 전송합니다. 이 기능에 대한 자세한 내용은 CloudFront 개발자 안내서를 참조하세요.

AWS 고객은 추가 비용 없이 AWS Shield Standard를 사용할 수 있습니다. AWS Shield는 AWS에서 실행되는 웹 애플리케이션을 DDoS 공격으로부터 보호하는 관리형 서비스입니다. AWS Shield Standard는 AWS의 애플리케이션 고가용성을 지원하기 위해 SYN/UDP Floods, 반사 공격 등과 같은 일반적이고 가장 빈번히 발생하는 인프라(계층 3 및 4) 공격으로부터 모든 AWS 고객을 보호합니다.

AWS Shield Advanced는 선택 사항인 유료 서비스로, AWS Business Support 및 AWS Enterprise Support 고객에게 제공됩니다. AWS Shield Advanced는 더 정교하고 더 큰 규모의 공격을 차단하기 위해 Elastic Load Balancing(ELB), Amazon CloudFront, Route 53에서 실행되는 애플리케이션을 위한 추가적인 보호를 제공합니다.

CloudFront 배포를 AWS WAF와 통합할 수 있습니다. AWS WAF는 IP 주소, HTTP 헤더, 사용자 지정 URI 문자열을 기반으로 규칙을 구성하여 웹 공격으로부터 웹 애플리케이션을 보호하는 웹 애플리케이션 방화벽입니다. AWS WAF에서는 이러한 규칙을 사용하여 웹 애플리케이션에 대한 웹 요청을 차단, 허용 또는 모니터링(계수)할 수 있습니다. 자세한 내용은 AWS WAF 개발자 안내서를 참조하세요.

CloudFront는 오리진을 보호하기 위한 2가지 완전관리형 방법을 제공합니다.

1. 오리진 액세스 제어(OAC): CloudFront 오리진 액세스 제어(OAC)는 Amazon Simple Storage Service (S3) 오리진, AWS Elemental 오리진, Lambda 함수 URL에 대한 액세스를 제한하여 CloudFront만 콘텐츠에 액세스할 수 있도록 하는 보안 기능입니다.
2. VPC 오리진: CloudFront Virtual Private Cloud(VPC) 오리진을 사용하면 Amazon CloudFront를 통해 VPC 프라이빗 서브넷에 호스팅된 애플리케이션에서 콘텐츠를 전송할 수 있습니다. CloudFront에서는 프라이빗 서브넷의 Application Load Balancer(ALB), Network Load Balancer(NLB), EC2 인스턴스를 VPC 오리진으로 사용할 수 있습니다.

CloudFront 관리형 솔루션이 사용 사례 요구 사항을 충족하지 못할 경우 사용할 수 있는 몇 가지 대안적인 접근 방식은 다음과 같습니다.

1. 사용자 지정 오리진 헤더: CloudFront를 사용하면 수신 요청에 사용자 지정 헤더를 추가한 다음, 이러한 특정 헤더 값을 검증하도록 오리진을 구성하여 CloudFront를 통해 라우팅되는 요청에만 액세스하도록 액세스 권한을 효과적으로 제한할 수 있습니다. 이 방법은 추가 인증 계층을 생성하여 오리진에 대한 무단 직접 액세스의 위험을 크게 줄입니다.
2. IP 허용 목록: CloudFront의 IP 범위에서 들어오는 트래픽만 허용하도록 오리진의 보안 그룹이나 방화벽을 구성할 수 있습니다. AWS는 사용자의 편의를 위해 이러한 IP 범위를 유지 관리하고 정기적으로 업데이트합니다. IP 허용 목록 구현에 대한 자세한 내용은 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list의 종합 문서를 참조하세요. 이 리소스는 최적의 보안 구성을 위해 AWS의 관리형 접두사 목록을 활용하는 방법에 대한 단계별 지침을 제공합니다.
3. SSL/TLS 암호화: 오리진과의 HTTPS 연결만 사용하도록 CloudFront를 구성하여 CloudFront 배포와 오리진 간의 암호화된 통신을 통해 엔드 투 엔드 데이터 보호를 달성할 수 있습니다.

CloudFront Virtual Private Cloud(VPC) 오리진은 CloudFront를 사용하여 VPC 프라이빗 서브넷에 호스팅된 애플리케이션에서 콘텐츠를 전송할 수 있는 새로운 기능입니다. VPC 오리진을 사용하면 CloudFront 배포를 통해서만 액세스 가능한 VPC의 프라이빗 서브넷에 애플리케이션을 배치할 수 있습니다. 이렇게 하면 오리진에 외부에서 확인할 수 있는 도메인 이름 서비스(DNS) 이름이 있어야 할 필요가 없습니다. Application Load Balancer(ALB), Network Load Balancer(NLB), EC2 인스턴스에서 실행되는 애플리케이션에 VPC 오리진을 설정할 수 있습니다. VPC 오리진은 AWS 상용 리전에서만 사용 가능하며, 지원되는 AWS 리전의 전체 목록은 여기에서 확인할 수 있습니다.

높은 성능과 글로벌 확장성을 유지하면서 웹 애플리케이션의 보안을 강화하려면 CloudFront와 함께 VPC 오리진을 사용해야 합니다. VPC 오리진을 사용하면 비밀 헤더나 액세스 제어 목록 같은 복잡한 구성 없이 VPC의 오리진에 대한 액세스 권한을 CloudFront 배포로만 제한할 수 있습니다. 또한 VPC 오리진을 사용하면 내부 IPv4 IP 주소가 있는 프라이빗 서브넷의 오리진으로 무료로 라우팅할 수 있어 IPv4 비용을 최적화할 수 있습니다. VPC 오리진은 보안 관리를 간소화하려는 경우에 적합하며, 복잡한 보안 조치를 관리하는 대신 핵심 비즈니스 성장에 더 집중할 수 있습니다.

1. 보안 - VPC 오리진을 사용하면 로드 밸런서와 EC2 인스턴스를 프라이빗 서브넷에 배치하여 CloudFront를 유일한 수신 지점으로 설정할 수 있으므로, 애플리케이션의 보안 태세를 개선할 수 있습니다. 안전한 비공개 연결을 통해 CloudFront에서 VPC 오리진으로 사용자 요청이 전송되므로 애플리케이션 보안이 강화됩니다.
2. 관리 - VPC 오리진을 사용하면 퍼블릭 액세스가 불가능한 프라이빗 서브넷으로 오리진을 옮길 수 있고, 오리진에 대한 액세스를 제한하기 위해 액세스 제어 목록, 비밀 공유 헤더 또는 기타 메커니즘을 구현하지 않아도 되므로 안전한 CloudFront-오리진 연결에 필요한 운영 오버헤드가 줄어듭니다. 따라서 획일적인 개발 작업에 투자할 필요 없이 CloudFront를 통해 웹 애플리케이션을 쉽게 보호할 수 있습니다.
3. 확장 가능성 및 성능 - 고객은 VPC 오리진을 통해 CloudFront의 글로벌 엣지 로케이션과 AWS 백본 네트워크를 사용하여 기존의 다른 콘텐츠 전송 방법과 비슷한 규모와 성능을 활용하면서 보안 태세를 개선할 수 있습니다. 이 솔루션은 고객에게 글로벌 애플리케이션을 제공하는 동시에 보안 관리를 간소화하며, CloudFront를 애플리케이션의 단일 프론트 도어로 간편하게 사용할 수 있습니다.

CloudFront Virtual Private Cloud(VPC) 오리진을 사용하면 CloudFront를 통해 Application Load Balancer, Network Load Balancer, EC2 인스턴스가 있는 VPC 프라이빗 서브넷에 호스팅된 애플리케이션에서 콘텐츠를 전송할 수 있습니다. Amazon VPC Block Public Access(VPC BPA)는 AWS가 제공한 인터넷 경로를 통해 들어오는(수신) VPC 트래픽과 나가는(송신) VPC 트래픽을 결정적으로 차단하는 간단한 선언적 제어입니다. VPC 오리진이 있는 서브넷에서 VPC BPA를 활성화하면 CloudFront로부터의 활성 연결이 해당 서브넷에서 종료됩니다. 새 연결은 서브넷으로 전송되지 않으며, VPC 오리진이 있고 BPA가 활성화되지 않은 다른 서브넷으로 라우팅되거나, VPC 오리진이 있는 모든 서브넷에 BPA가 활성화된 경우에는 삭제됩니다.

VPC 오리진은 Application Load Balancers, Network Load Balancers, EC2 인스턴스를 지원합니다.

아니요. IPv6는 VPC 프라이빗 오리진에서 지원되지 않습니다. VPC 오리진에는 프라이빗 IPv4 주소가 필요하며, 비용은 무료이고 IPv4 요금이 부과되지 않습니다.

예. 오리진으로 전달된 요청에 사용자 지정 헤더를 추가하거나 기존 헤더 값을 무시하도록 Amazon CloudFront를 구성할 수 있습니다. 이러한 헤더를 사용하여 오리진에 전달된 요청이 CloudFront로부터 온 요청임을 확인할 수 있습니다. 지정한 사용자 정의 헤더 값이 포함된 요청만 허용하도록 오리진을 구성할 수도 있습니다. 또한, 같은 오리진에 여러 CloudFront 배포를 사용하는 경우 사용자 정의 헤더를 통해 각기 다른 배포에서 전달된 오리진 요청을 구별할 수 있습니다. 마지막으로 사용자 정의 헤더는 요청에 대해 적절한 CORS 헤더가 반환되었는지 확인하는 데 사용할 수 있습니다. 사용자 정의 헤더는 CloudFront API와 AWS Management Console을 통해 구성할 수 있습니다. 이 기능에 대한 추가 비용은 없습니다. 사용자 지정 헤더를 설정하는 방법에 대한 자세한 내용은 여기를 참조하십시오.

Amazon CloudFront는 HTTP 쿠키를 사용하여 사용자 지정되거나 개인화된 동적 콘텐츠 전달을 지원합니다. 이 기능을 사용하려면 Amazon CloudFront가 맞춤 오리진 서버로 쿠키 일부를 전달할지 또는 전부를 전달할지를 지정해야 합니다. 그런 다음 Amazon CloudFront는 캐시에서 고유 객체를 식별할 때 전달된 쿠키 값을 고려합니다. 이렇게 함으로써 최종 사용자는 쿠키를 통해 자신에게 개인화된 콘텐츠의 이점과 Amazon CloudFront의 성능 이점을 모두 얻습니다. 또한 Amazon CloudFront 액세스 로그에 쿠키 값을 기록하도록 선택할 수도 있습니다.

쿼리 문자열은 필요에 따라 Amazon CloudFront 캐시의 객체를 식별하기 위한 캐시 키의 일부로 구성될 수 있습니다. 이렇게 하면 일정 시간 동안 엣지에 캐시될 수 있는 동적 웹 페이지(예: 검색 결과)를 구축할 수 있습니다.

예. 쿼리 문자열 화이트리스트 등록 기능을 사용하면 Amazon CloudFront에서 모든 파라미터를 오리진으로 전달하는 동시에 캐시 키에서는 특정 파라미터만 사용하도록 손쉽게 구성할 수 있습니다.

예. 최대 10개의 쿼리 파라미터를 허용 목록에 등록하도록 Amazon CloudFront를 구성할 수 있습니다.

Amazon CloudFront는 RFC3986의 섹션 3.4에 정의된 URI 쿼리 파라미터를 지원합니다. 특히 HTTP GET 문자열에서 ‘?’ 문자 다음에 포함되고 ‘&’ 문자로 구분된 쿼리 파라미터를 지원합니다.

예. CloudFront에서는 텍스트 또는 바이너리 데이터를 자동으로 압축할 수 있습니다. 이 기능을 사용하려면 캐시 동작 설정에서 CloudFront가 자동으로 객체를 압축하도록 지정하고, 클라이언트가 요청 헤더에 Accept-Encoding: gzip을 추가(최신 웹 브라우저 대부분은 기본적으로 이를 수행함)하기만 하면 됩니다. 이 기능에 대한 자세한 내용은 개발자 안내서를 참조하세요.

일반적으로 스트리밍은 재생하기 전에 미디어 파일을 다운로드할 필요 없이 최종 사용자에게 인터넷을 통해 오디오 및 비디오를 전송하는 것을 말합니다. 스트리밍에 사용되는 프로토콜에는 Apple의 HTTP Live Streaming(HLS), MPEG Dynamic Adaptive Streaming over HTTP(MPEG-DASH), Adobe의 HTTP Dynamic Streaming(HDS), Microsoft의 Smooth Streaming 등과 같이 전송에 HTTP를 사용하는 프로토콜이 포함됩니다. 스트리밍 프로토콜은 실시간으로 미디어를 전송해 바이트가 전송되는 대로 최종 사용자가 이를 볼 수 있으므로 웹 페이지 및 기타 콘텐츠를 전송하는 데 사용되는 프로토콜과 다릅니다. 스트리밍 콘텐츠는 귀하와 최종 사용자에게 다음과 같은 여러 가지 잠재적인 이점을 제공합니다.

• 스트리밍을 사용하면 최종 사용자가 시청 환경에 대한 더 많은 제어 권한을 가질 수 있습니다. 예를 들어, 기존 다운로드 전송을 사용할 때보다 스트리밍을 사용할 때 최종 사용자가 비디오에서 좀 더 쉽게 앞뒤로 검색할 수 있습니다.
• 스트리밍에서는 최종 사용자가 비디오 시청을 마치면 최종 사용자의 클라이언트 또는 로컬 드라이브에 파일이 남지 않으므로 콘텐츠에 대한 제어가 강화됩니다.
• 스트리밍은 미디어 파일에서 최종 사용자가 실제로 시청하는 부분만 전송하므로 비용을 줄이는 데 도움이 될 수 있습니다. 이에 반해 기존 다운로드 방식에서는 최종 사용자가 파일 일부분만 시청하더라도 전체 미디어 파일을 전송하는 경우가 많습니다.

예. Amazon CloudFront는 온디맨드 비디오 콘텐츠를 전송할 수 있는 다양한 옵션을 제공합니다. Amazon S3(또는 사용자 지정 오리진)에 저장되기 전에 AWS Elemental MediaConvert를 사용해 미디어 파일을 HLS, MPEG-DASH 또는 Microsoft Smooth Streaming으로 전환한 경우, Amazon CloudFront 웹 배포를 사용하면 다른 미디어 서버를 구동하지 않고도 해당 형식으로 스트리밍할 수 있습니다.

또는, 미디어 파일을 필요한 HTTP 스트리밍 형식으로 변환할 수 있는 서드 파티 스트리밍 서버(예: AWS Marketplace에서 제공하는 Wowza Media Server)를 Amazon EC2에서 실행할 수 있습니다. 그런 다음, 이 서버를 Amazon CloudFront 웹 배포를 위한 오리진 서버로 지정할 수 있습니다.

자세한 내용은 AWS 페이지의 온디맨드 비디오(VOD)를 참조하세요.

예. Amazon CloudFront 라이브 스트리밍을 AWS Elemental MediaPackage 또는 AWS Elemental MediaStore 같이 HTTP 기반 스트림을 출력하는 라이브 비디오 오리지네이션 서비스와 함께 사용할 수 있습니다. MediaPackage는 다양한 전송 및 콘텐츠 보호 표준을 사용해 비디오 제공업체가 대규모 스트리밍 콘텐츠를 안전하고 안정적으로 전송할 수 있도록 지원하는 비디오 오리지네이션 및 JIT(Just-In-Time) 패키징 서비스입니다. MediaStore는 Amazon 스토리지의 보안과 안정성과 더불어 라이브 미디어를 위한 뛰어난 성능, 즉각적인 일관성, 예측 가능한 짧은 지연 시간을 제공하는 HTTP 오리지네이션 및 스토리지 서비스입니다.

자세한 내용은 AWS 라이브 비디오 스트리밍 페이지를 참조하세요.

Media-Quality Aware Resiliency(MQAR)는 Amazon CloudFront와 AWS Media Services 간의 통합된 기능으로, 동적으로 생성된 비디오 품질 점수에 따라 리전 간 오리진 선택 및 장애 조치를 자동으로 제공합니다. MQAR을 사용하면 복원력이 뛰어난 라이브 이벤트 전송을 위해 서로 다른 AWS 리전 2개에 중복 AWS 미디어 서비스 워크플로를 배포할 수 있습니다. 배포 작업 시 MQAR 기능을 활성화하면 CloudFront는 품질 평가 점수가 가장 높은 것으로 간주되는 오리진을 자동으로 선택하도록 승인합니다. 품질 점수는 블랙 프레임, 정지 또는 삭제된 프레임, 반복되는 프레임 등 오리진에서 인식한 미디어 스트리밍 품질 문제를 나타냅니다. 예를 들어 AWS Elemental MediaPackage v2 오리진이 서로 다른 AWS 리전 2개에 배포되고 한 리전이 다른 리전보다 미디어 품질 점수가 더 높다고 보고할 경우, CloudFront는 더 높은 점수를 자동으로 보고하는 오리진으로 전환합니다. 이 기능은 라이브 이벤트와 연중무휴 프로그래밍 채널을 제공하기 위해 항상 '눈을 떼지 않고 감시'하여 시뮬레이션하며 시청자에게 고품질 경험을 제공할 수 있도록 설계되었습니다. MQAR에 대한 자세한 내용은 CloudFront 개발자 안내서에서 확인할 수 있습니다.

Origin Shield는 캐시 적중률을 높여 오리진의 부하를 줄일 수 있는 중앙 집중식 캐싱 계층입니다. 또한 Origin Shield는 여러 리전에 걸친 요청을 압축하여 오리진으로 제출되는 객체당 요청을 최소 1개까지 줄임으로써 오리진 운영 비용을 절감해 줍니다. Origin Shield를 활성화하면 CloudFront가 모든 오리진 가져오기 요청을 Origin Shield로 라우팅하며, 콘텐츠가 이미 Origin Shield의 캐시에 저장되어 있지 않은 경우에만 요청을 오리진에 제출합니다.

최종 사용자가 여러 지역에 분산되어 있는 경우나, 비디오 스트리밍용 JIT(Just-in-time) 패키징/이미지 즉시 처리/기타 유사한 프로세스가 포함된 워크로드를 처리해야 하는 경우 Origin Shield를 사용하면 효율적입니다. 오리진 앞에 Origin Shield를 배치하면 중복 오리진 페치 수를 줄일 수 있습니다. 오리진의 중앙 캐시를 먼저 확인하여 Origin Shield 캐시에 아직 없는 콘텐츠의 경우에만 통합 오리진 페치를 수행하기 때문입니다. 마찬가지로 다중 CDN 아키텍처에서도 Origin Shield를 사용하여 여러 CDN 간의 중복 오리진 페치 수를 줄일 수 있습니다. 이 경우에는 다른 CDN의 오리진으로 Amazon CloudFront를 배치하면 됩니다. 이러한 사용 사례와 기타 Origin Shield 사용 사례에 대해 자세히 알아보려면 Amazon CloudFront 개발자 안내서를 참조하세요.

Amazon CloudFront에 리전별 엣지 캐시가 있는 AWS 리전에서 Origin Shield가 제공됩니다. Origin Shield를 활성화할 때는 오리진에 대한 지연 시간이 가장 짧은 AWS 리전을 Origin Shield용으로 선택해야 합니다. Origin Shield는 AWS 리전 내에 있는 오리진과 AWS 외부에 있는 오리진 양쪽 모두에 사용 가능합니다. 자세한 내용은 Amazon CloudFront 개발자 안내서에서 Origin Shield의 AWS 리전 선택을 참조하세요.

예. 모든 Origin Shield 리전은 여러 가용 영역을 포함하는 고가용성 아키텍처로 구성되어 있습니다. 이러한 가용 영역에는 Auto Scaling Amazon EC2 인스턴스 플릿이 포함됩니다. 또한 CloudFront 위치와 Origin Shield 간의 연결에서는 각 요청에 활성 오류 추적 기능을 사용해 주 Origin Shield 위치를 사용할 수 없을 경우 요청을 보조 Origin Shield 위치로 자동 라우팅합니다.

Amazon CloudFront의 Anycast 고정 IP는 전 세계 모든 CloudFront 엣지 로케이션에 연결할 수 있는 고정 IP 주소 세트입니다. 이들은 네트워크 제공업체가 적절한 계약을 체결한 특정 IP 주소에 대한 데이터 요금을 면제하는 제로 요금 청구, 보안 태세 강화를 위한 클라이언트 측 허용 목록 작성 등과 같은 사용 사례에 사용할 수 있는 작은 고정 IP 목록을 제공합니다. Anycast 고정 IP를 사용하면 동일한 IP 세트가 CloudFront의 전체 글로벌 네트워크에서 작동하면서도 CloudFront의 모든 기능을 활용할 수 있으므로, 허용 목록 또는 IP 매핑을 지속적으로 업데이트해야 하는 운영상의 문제가 사라집니다.

Anycast 고정 IP를 활성화하려면 먼저 AWS 계정에서 Anycast 고정 IP 목록을 요청하고 생성해야 합니다. 목록이 생성되면 CloudFront 배포를 Anycast 고정 IP 목록과 연결할 수 있습니다. 이 작업은 AWS Console의 Anycast 고정 IP 섹션을 통해 수행하거나, 각 배포를 편집하고 드롭다운 메뉴에서 원하는 Anycast 고정 IP 목록을 선택하여 수행할 수 있습니다. 변경 사항을 저장하면 배포에 연결된 특정한 고정 IP 주소 세트를 AWS Console에 표시된 목록이나 API를 통해 복사하거나 다운로드할 수 있습니다.

CloudFront Anycast 고정 IP를 활성화하면 IPv4용 IP 주소 21개를 받게 됩니다. 이러한 IP 주소를 모두 관련 허용 목록에 추가해야 합니다.

아니요. CloudFront Anycast는 여러 지리적 리전에 분산된 IP에서만 사용할 수 있습니다.

CloudFront가 새로운 엣지 로케이션을 추가하더라도 Anycast 고정 IP 목록은 계속 유효합니다. 적절한 경우 새 엣지 로케이션의 IP를 발표할 예정입니다.

모든 CloudFront 기능은 Anycast와 연동되지만 다음 3가지 예외 사항에 유의해야 합니다. 첫째, Anycast 고정 IP는 SNI를 지원할 수 없는 레거시 클라이언트를 지원하지 않습니다. 둘째, Anycast 고정 IP를 사용할 때는 Price Class All을 사용해야 합니다. 셋째, Anycast 고정 IP를 사용할 때는 IPv6를 비활성화해야 합니다. Anycast IP는 DNS 확인 단계에서 작동하며, 요청이 호스트에 도달하면 배포에서 기존의 모든 기능 및 다른 AWS 서비스와의 통합을 계속 사용할 수 있습니다.

Anycast 고정 IP를 여러 배포에 사용할 수 있지만 배포가 동일한 계정에 있어야 합니다. CloudFront Anycast 고정 IP는 계정의 여러 배포에 연결할 수 있습니다. CloudFront Anycast 고정 IP는 서버 이름 표시(SNI)를 지원하므로 Anycast 고정 IP 정책과 연결된 배포가 몇 개이든 배포에서 올바른 인증서가 반환됩니다. 계정 내 여러 배포에 고유한 고정 IP를 사용하려는 경우 추가 Anycast 고정 IP 목록을 생성하여 특정 배포에 연결할 수 있습니다.

Anycast 고정 IP가 활성화된 계정에서 새 배포를 생성할 때는 새 배포를 기존 Anycast 고정 IP 목록과 명시적으로 연결해야 합니다. 기본적으로 새 배포는 고정 IP 목록에 연결할 때까지 동적 IP 주소를 사용합니다.

예. 여기에서 한도 상향 조정 요청을 작성하면 영업일 기준 2일 이내에 계정 용량을 추가해 드립니다.

현재 각 AWS 계정에 대해 생성할 수 있는 배포 수 제한을 알아보려면 Amazon Web Services 일반 참조에서 Amazon CloudFront 제한 섹션을 참조하세요. 한도를 높이려면 CloudFront 한도 증가 요청 양식에서 요청하시면 됩니다.

Amazon CloudFront를 통해 전송할 수 있는 단일 파일의 최대 크기는 30GB입니다. 이 제한은 모든 Amazon CloudFront 배포에 적용됩니다.

1. 표준 로그(액세스 로그) CloudFront 표준 로그는 배포에 전송된 모든 요청에 대한 상세한 레코드를 제공합니다. 이러한 로그는 보안 감사 및 액세스 감사를 비롯한 여러 시나리오에서 유용합니다.
2. 실시간 로그 CloudFront 실시간 로그는 배포에 전송된 요청에 대한 정보를 실시간으로 제공합니다(로그 레코드는 요청 수신 후 몇 초 내에 전송됨). 실시간 로그의 샘플링 비율, 즉 실시간 로그 레코드를 수신하려는 요청의 백분율을 선택할 수 있습니다.
3. 엣지 함수 로깅: Amazon CloudWatch Logs를 사용하여 엣지 함수(Lambda@Edge 및 CloudFront Functions)의 로그를 가져올 수 있습니다. CloudWatch 콘솔이나 CloudWatch Logs API를 사용하여 해당 로그에 액세스할 수 있습니다. 자세한 내용은 엣지 함수 로그를 참조하세요.
4. 서비스 활동 로깅: AWS CloudTrail을 사용하여 AWS 계정의 CloudFront 서비스 활동(API 활동)을 로깅할 수 있습니다. CloudTrail은 CloudFront에서 사용자, 역할 또는 AWS 서비스가 수행한 API 작업의 레코드를 제공합니다. CloudTrail에서 수집된 정보를 사용하면 CloudFront에 대한 API 요청, 요청이 이루어진 IP 주소, 요청한 사람, 요청 시간 및 추가 세부 정보를 확인할 수 있습니다. 자세한 내용은 AWS CloudTrail을 사용하여 Amazon CloudFront API 직접 호출 로깅을 참조하세요.

• CloudFront 표준 로그는 선택한 Amazon S3 버킷, Amazon CloudWatch Logs, Amazon Data Firehose로 전송됩니다. 자세한 내용은 표준 로그(액세스 로그) 사용을 참조하세요.
• CloudFront 실시간 로그는 Amazon Kinesis Data Streams에서 사용자가 선택한 데이터 스트림으로 전송됩니다. CloudFront는 Kinesis Data Streams 사용 요금 외에도, 실시간 로그에 대한 요금을 청구합니다. 자세한 내용은 실시간 로그 사용을 참조하세요.
• CloudFront 엣지 함수 로그(Lambda@Edge 및 CloudFront Functions)는 Amazon CloudWatch Logs로 전송됩니다.

CloudFront 표준 액세스 로그를 Amazon S3, Amazon CloudWatch, Amazon Data Firehose에 전송할 수 있습니다. 출력 로그 형식(일반, w3c, JSON, csv, Parquet)을 선택할 수 있습니다. 로깅할 필드와 해당 필드가 로그에 포함되는 순서를 선택할 수 있습니다. S3로 전송되는 로그의 경우 S3로 전송되는 로그의 파티셔닝을 활성화할 수도 있습니다. 즉, 로그가 시간별로 또는 일별로 자동 파티셔닝되도록 구성할 수 있습니다. 또한 옵트인 AWS 리전의 S3 버킷에 표준 액세스 로그를 전송할 수 있습니다. 자세한 내용은 CloudFront 개발자 안내서의 표준 액세스 로그 섹션을 참조하세요.

CloudFront는 표준 로그 활성화에 대해서는 요금을 부과하지 않지만, 로그 전송 대상에 따라 로그 전송, 저장, 액세스에 대한 요금이 발생합니다. 자세한 내용은 CloudFront 요금 페이지의 '추가 기능' 섹션을 참조하세요.

예. 자세한 캐시 통계 보고서 수신, CloudFront 사용량 모니터링, 최종 사용자가 콘텐츠를 시청하는 장소 확인, 운영 지표에 대한 실시간에 가까운 경보 설정 등의 작업을 할 수 있도록 Amazon CloudFront는 보고 요구 사항에 따라 다양한 솔루션을 제공합니다. AWS Management Console의 Amazon CloudFront Reporting & Analytics 대시보드에서 모든 보고 옵션에 액세스할 수 있습니다. Amazon CloudFront의 보고서 및 분석 페이지에서도 다양한 보고 옵션에 대해 자세히 알아볼 수 있습니다.

예. Amazon CloudFront는 비용 할당 태깅을 지원합니다. 태그를 사용하면 AWS 리소스를 분류하고 그룹화하여 손쉽게 비용을 할당하고 지출을 최적화할 수 있습니다. 예를 들어 태그를 사용하여 리소스를 관리자, 애플리케이션 이름, 비용 센터 또는 특정 프로젝트별로 그룹화할 수 있습니다. 비용 할당 태깅에 대해 자세히 알아보려면 비용 할당 태그 사용을 참조하세요. CloudFront 배포에 태그를 추가할 준비가 되었다면 Amazon CloudFront 태그 추가 페이지를 참조하세요.

예. 계정에서 이루어진 모든 Amazon CloudFront API 직접 호출 내역을 받아보려면 CloudTrail의 AWS Management Console에서 AWS CloudTrail을 활성화하면 됩니다. 자세한 내용은 AWS CloudTrail 홈 페이지를 참조하세요.

Amazon CloudWatch를 사용하면 최종 사용자는 요청 후 몇 분 내에 Amazon CloudFront 배포의 운영 성능을 모니터링하고 경보 및 알림을 받을 수 있습니다. CloudFront는 1분 단위로 Amazon CloudWatch에 6가지 운영 지표를 자동으로 게시합니다. 따라서 CloudWatch를 사용하여 CloudFront 트래픽의 모든 비정상적인 패턴에 대해 경보를 설정할 수 있습니다. CloudFront 활동을 모니터링하고 CloudWatch를 통해 경보를 설정하는 방법에 대해 알아보려면 Amazon CloudFront 개발자 안내서의 설명을 참조하거나 Amazon CloudFront 관리 콘솔로 이동하여 탐색 창에서 모니터링 및 경보를 선택하기만 하면 됩니다.

사용 사례에 따라 대상을 선택할 수 있습니다. 급히 해결해야 하는 사용 사례가 있고 몇 초 안에 로그 데이터에 신속하게 액세스해야 하는 경우, 실시간 로그를 선택합니다. 실시간 로그 파이프라인을 좀 더 저렴한 요금으로 이용하고자 하는 경우, 특정 캐시 동작에 대해서만 로그를 활성화하거나 낮은 샘플링 비율을 선택하여 로그 데이터를 필터링하기로 선택할 수 있습니다. 실시간 로그 파이프라인은 신속한 데이터 제공에 최적화되었습니다. 따라서 데이터 지연이 발생하는 경우 로그 레코드가 삭제될 수 있습니다. 반면 실시간 데이터에 대한 요구 사항 없이 저렴한 로그 처리 솔루션이 필요한 경우, 현재 버전의 표준 로그 옵션이 가장 적합합니다. S3의 표준 로그는 완전성에 최적화되어 있으며 대개 몇 분 안에 로그를 이용할 수 있습니다. 이러한 로그는 배포 전체에 대하여 활성화할 수 있으며, 특정 캐시 동작에 대해서만 활성화할 수는 없습니다. 따라서 임시 조사, 감사 및 분석 때문에 로그가 필요한 경우라면 S3에서 표준 로그만 활성화할 수 있습니다. 두 가지 로그를 조합하여 사용하는 방법도 있습니다. 운영 가시성을 확보하려면 실시간 로그를 필터링한 목록을 사용하고, 감사 작업에는 표준 로그를 사용하세요.
 

CloudFront 표준 로그는 S3 버킷에 전달됩니다. DataDog 및 Sumologic과 같은 타사 솔루션이 구축한 통합을 사용해 이러한 로그에서 대시보드를 생성할 수도 있습니다.

실시간 로그는 Kinesis Data Stream에 전달됩니다. Kinesis Data Stream에서 로그를 Amazon Kinesis Data Firehose에 게시할 수 있습니다. Amazon Kinesis Data Firehose는 Amazon S3, Amazon Redshift, Amazon OpenSearch Service를 대상으로 간편한 데이터 전달을 지원하며 이외에 Datadog, New Relic, Splunk 같은 서비스 제공업체에도 로그를 전달할 수 있습니다. Kinesis Firehose는 일반 HTTP 엔드포인트에 대한 데이터 전송도 지원합니다.

필요한 샤드의 수를 예측하려면 다음 단계를 따르세요.

1. CloudFront 배포에서 수신하는 초당 요청 수를 계산(또는 예측)합니다. 초당 요청 수를 계산하는 데 도움이 되는 CloudFront 사용량 보고서 또는 CloudFront 지표를 사용할 수 있습니다.
2. 실시간 로그 레코드 하나의 일반적인 크기를 판단합니다. 이용 가능한 모든 필드를 포함한 일반적인 레코드 하나는 대략 1KB입니다. 로그 레코드 크기가 확실하지 않으면 샘플링 비율을 낮게 설정하여(예: 1%) 실시간 로그를 활성화한 다음 Kinesis Data Streams의 모니터링 데이터를 사용해 레코드의 평균 크기를 계산할 수 있습니다(총 레코드 수를 수신되는 총 바이트 수로 나눔).
3. 초당 요청 수(1단계에서 얻은 값)에 일반적인 실시간 로그 레코드 크기(2단계에서 얻은 값)를 곱하면 실시간 로그 구성이 Kinesis 데이터 스트림에 전송할 가능성이 큰 초당 데이터양을 알아낼 수 있습니다.
4. 초당 데이터를 사용하여 필요한 샤드 수를 계산합니다. 샤드 한 개는 초당 1MB, 초당 요청(로그 레코드) 1,000건까지만 처리할 수 있습니다. 필요한 샤드의 수를 계산할 때 완충 장치 삼아 최대 25%를 더하는 것이 좋습니다.

예를 들어 배포에서 수신하는 요청 수가 초당 10,000건이고 실시간 로그 레코드 크기가 보통 1KB라고 가정합니다. 즉, 실시간 로그 구성으로 초당 10,000,000바이트(10,000 곱하기 1,000), 즉 9.53MB를 생성할 수 있습니다. 이 경우 Kinesis 샤드는 10개만 있으면 됩니다. 그렇다면 어느 정도 완충 역할을 하기 위해 최소 12개의 샤드를 생성하는 방안을 고려해 보시기 바랍니다.

CloudFront Functions는 경량 HTTP(S) 변환 및 조작에 대한 CloudFront 엣지 로케이션에서 JavaScript 코드를 실행할 수 있는 서버리스 엣지 컴퓨팅 기능입니다. 함수는 최신 웹 애플리케이션에 필요한 성능 및 보안과 함께 전체 프로그래밍 환경의 유연성을 고객에게 제공하기 위해 특별히 구축된 기능입니다. AWS Lambda@Edge 요금의 일부로, 고객은 즉각적으로 확장 가능하고 저렴하게 초당 1백만 개의 요청을 지원할 수 있습니다.

CloudFront Functions는 기본적으로 CloudFront에 구축되어 있으므로, 고객은 동일한 서비스 내에서 함수를 쉽게 구축, 테스트, 배포할 수 있습니다. 또한, CloudFront KeyValueStore를 CloudFront Functions와 함께 활용하여 조회 데이터를 저장하고 검색하여 함수 로직을 보완할 수 있습니다. AWS의 GitHub 리포지토리에서는 개발자가 함수 구축의 시작점으로 사용할 수 있는 많은 코드 모음 예시를 제공하여 작업을 쉽게 시작할 수 있도록 합니다. CloudFront 콘솔에서 IDE를 사용하거나 CloudFront API/CLI를 사용하여 함수를 구축할 수 있습니다. 코드를 작성한 후에 프로덕션 CloudFront 배포에서 함수를 테스트할 수 있으며, 이를 통해 배포 후 함수를 올바르게 실행하도록 보장합니다. 콘솔에서 테스트 기능은 시각적 편집기에서 테스트 이벤트를 빠르게 생성하고 함수를 검증합니다. CloudFront 배포에 연결되면, CloudFront 요청에 대한 응답으로 실행을 위해 AWS의 글로벌로 분산된 엣지 로케이션의 네트워크에 코드가 배포됩니다.

CloudFront Functions는 다음과 같은 단기 실행 경량 함수에 적합합니다.

• 캐시 키 정규화: HTTP 요청 속성(헤더, 쿼리 문자열, 쿠키, 그리고 요청 URL의 상대적 경로)을 변환하여 캐시 적중률을 개선할 수 있도록 최적의 캐시 키를 생성할 수 있습니다.
• 헤더 조작: 요청 또는 응답에서 HTTP 헤더를 삽입, 수정 또는 삭제할 수 있습니다. 예를 들어, HTTP 엄격한 전송 보안(HSTS) 또는 교차 오리진 리소스 공유(CORS) 헤더를 모든 응답에 추가할 수 있습니다.
• URL 리디렉션 또는 다시 기록: 요청 정보에 따라 시청자를 다른 페이지로 리디렉션하거나 한 경로에서 다른 경로로 모든 요청을 리디렉션할 수 있습니다.
• 요청 권한 부여: 권한 부여 헤더 또는 다른 요청 메타데이터를 검사하여 JSON 웹 토큰(JWT) 같은 권한 부여 토큰을 검증할 수 있습니다.

CloudFront KeyValueStore는 지연 시간이 짧은 완전관리형 글로벌 키-값 데이터 스토어입니다. KeyValueStore를 통해 CloudFront Functions 내에서 키 값 데이터를 검색할 수 있으므로, 독립적인 데이터 업데이트를 허용하여 함수를 보다 쉽게 사용자 지정할 수 있습니다. 키 값 데이터는 모든 CloudFront 엣지 로케이션에서 액세스할 수 있으므로, CloudFront Functions 내에서 빠르게 읽을 수 있는 매우 효율적인 인메모리 키-값 스토어를 제공합니다.

CloudFront KeyValueStore는 엣지 로케이션에서 읽기 작업이 자주 실행되고, 업데이트가 자주 이루어지지 않는 다음과 같은 경우에 적합합니다.

• URL 재작성 및 리디렉션 유지 관리: 지리적 위치를 기반으로 사용자를 특정 국가 사이트로 리디렉션합니다. 이러한 지리적 위치 기반 URL을 KeyValueStore에 저장하고 업데이트하면 URL 관리가 간소화됩니다.
• A/B 테스트 및 특성 플래그: 웹 사이트 버전에 일정 비율의 트래픽을 할당하여 실험을 실행합니다. 함수 코드나 CloudFront 배포를 업데이트하지 않고도 실험 가중치를 업데이트할 수 있습니다.
• 액세스 권한 부여: HMAC 토큰 또는 JSON 웹 토큰(JWT) 같은 사용자 생성 토큰을 생성하고 검증하여 요청을 허용하거나 거부함으로써 CloudFront를 통해 제공되는 콘텐츠에 대한 액세스 제어 및 권한 부여를 구현합니다. 

아니요. CloudFront 함수는 Lambda@Edge를 보완하는 기능이며, 이를 대체하지 않습니다. Lambda@Edge 및 CloudFront 함수를 결합하면 작업에 올바른 도구를 선택할 수 있습니다. CloudFront 배포에서 동일한 캐시 동작 내 서로 다른 이벤트 트리거에서 CloudFront 함수 및 Lambda@Edge 모두를 사용하도록 선택할 수도 있습니다. 예를 들어, Lambda@Edge를 사용하여 사용자 지정 토큰을 삽입해 라이브 스트림을 보안하도록 스트리밍 매니페스트 파일을 즉시 조작할 수 있습니다. CloudFront Functions를 사용하면 사용자가 매니페스트에서 세그먼트에 대한 요청을 수행할 때 이러한 토큰을 검증할 수 있습니다.

CloudFront Functions 및 Lambda@Edge를 조합하여 사용하면 CloudFront 이벤트에 대한 응답으로 코드를 실행할 때 강력하면서도 유연한 2가지 옵션이 제공됩니다. 둘 다 인프라를 관리하지 않고도 CloudFront 이벤트에 대한 응답으로 코드를 실행하는 안전한 방법을 제공합니다. CloudFront 함수는 지연 시간에 민감한 경량의 대규모 요청/응답 변환 및 조작을 위해 특별히 설계되었습니다. Lambda@Edge는 다양한 컴퓨팅 요구 사항 및 사용자 지정을 지원하는 범용 런타임을 사용합니다. Lambda@Edge는 컴퓨팅 집약적 작업에 사용해야 합니다. 완료하는 데 시간이 더 오래 걸리거나(밀리초에서 초 단위까지), 외부 타사 라이브러리에 종속성이 존재하거나, 다른 AWS 서비스(예: S3, DynamoDB)와 통합이 필요하거나 데이터 처리를 위해 네트워크 호출이 필요한 컴퓨팅이 이에 해당될 수 있습니다. 널리 사용되는 몇 가지 고급 Lambda@Edge 사용 사례로는 HLS 스트리밍 매니페스트 조작, 서드 파티 권한 부여 및 봇 탐지 서비스와의 통합, 엣지에서 단일 페이지 앱(SPA)의 서버 측 렌더링(SSR) 등이 포함됩니다. 자세한 내용은 Lambda@Edge 사용 사례 페이지를 참조하세요.

CloudFront Functions는 예상되는 성능, 확장성, 비용 효율성을 제공하는 동시에, 독특한 보안 모델을 통해 Functions 코드 사이에 엄격한 격리 경계를 제공합니다. 공유 다중 테넌트 컴퓨팅 환경에서 사용자 지정 코드를 실행하는 경우 매우 안전한 실행 환경을 유지하는 것이 핵심입니다. 잘못된 액터가 런타임, 라이브러리 또는 CPU에 존재하는 버그를 악용하여 서버 또는 다른 컴퓨터 함수에서 민감한 데이터를 누출시킬 수 있습니다. 함수 코드 사이에 엄격한 격리 장벽이 없으면 이렇게 악용될 수 있습니다. AWS Lambda 및 Lambda@Edge 모두 Firecracker 기반 VM 격리를 통해 이러한 보안 격리를 이미 구축했습니다. CloudFront Functions를 사용하여 Spectre 및 Meltdown 같은 사이드 채널 공격, 타이밍 기반 공격 또는 기타 코드 취약성으로부터 보호하는 동일한 보안 수준을 제공하는 프로세스 기반 격리 모델을 개발했습니다. CloudFront 함수는 다른 고객에게 속한 데이터에 액세스하거나 이를 수정할 수 없습니다. 전용 CPU에서 전용 프로세스로 함수를 실행하여 이를 구현합니다. CloudFront 함수는 한 번에 한 명의 고객만 지원하는 프로세스에서 실행되며, 모든 고객 특정 데이터는 실행 사이에서 지워집니다(플러시).

CloudFront 함수는 JavaScript 엔진으로 V8을 사용하지 않습니다. Functions의 보안 모델은 서로 다르지만, 일부 다른 공급자가 제공하는 모델에 따라 v8 격리보다 보안 수준이 더 높은 것으로 간주됩니다.

기본 제공되는 테스트 기능을 사용하여 함수를 테스트할 수 있습니다. 함수 테스트는 함수가 예상 결과를 반환하는지 검증하기 위해 CloudFront 배포에서 코드를 실행합니다. 코드 실행 검증 외에도, 컴퓨팅 사용률 지표도 함께 제공됩니다. 컴퓨팅 사용률 지표는 함수가 실행 제한 시간에 근접한 정도를 비율로 표시합니다. 예를 들어, 컴퓨팅 사용률이 30이면 함수가 허용 가능한 전체 실행 시간의 30%를 사용하고 있음을 나타냅니다. 테스트 객체는 시각적 편집기를 사용하여 생성할 수 있으며, 이를 통해 각 각체에 대한 쿼리 문자열, 헤더, URL 및 HTTP 요청을 쉽게 추가할 수 있습니다. 또는 요청 또는 응답의 JSON 표현을 사용하여 테스트 객체를 생성할 수 있습니다. 테스트를 실행한 후 결과와 컴퓨팅 사용률 지표는 동일한 시각적 편집기 스타일에서 또는 JSON 응답에서 확인할 수 있습니다. 함수가 성공적으로 실행되고 컴퓨팅 사용률 지표가 100에 근사하지 않으면 CloudFront 배포에 연결될 때 함수가 작동한다는 것을 확인할 수 있습니다.

CloudFront Functions는 지표 및 실행 로그 모두를 출력하여 함수의 사용량과 성능을 모니터링합니다. 지표는 함수가 호출될 때마다 생성되며, CloudFront 또는 CloudWatch 콘솔에서 개별적으로 각 함수의 지표를 확인할 수 있습니다. 지표는 호출 수, 컴퓨팅 사용률, 검증 오류 및 실행 오류를 포함합니다. 함수에서 검증 오류 또는 실행 오류가 발생한 경우 CloudFront 액세스 로그에도 오류 메시지가 표시되어 CloudFront 트래픽에 함수가 미치는 영향을 더 효과적으로 확인할 수 있습니다. 지표 외에도, 함수 코드 내에 console.log() 문을 포함하여 실행 로그를 생성할 수 있습니다. 모든 log 문은 CloudWatch로 전송되는 CloudWatch 로그 항목을 생성합니다. 로그 및 지표는 CloudFront Functions 요금의 일부로 포함됩니다. 

Lambda@Edge는 서버를 프로비저닝하거나 관리하지 않고도 글로벌 엣지 로케이션에서 코드를 실행할 수 있는 AWS Lambda의 확장 기능입니다. Lambda@Edge는 강력하면서도 유연한 서버리스 컴퓨팅을 제공하여 전체 애플리케이션 로직 및 복잡한 함수가 시청자와 더 가까운 곳에서 실행되도록 합니다. Lambda@Edge 함수는 Node.js 또는 Python 환경에서 실행됩니다. 단일 AWS 리전에 함수를 게시하고, 함수를 CloudFront 배포에 연결하면 Lambda@Edge에서 자동으로 전 세계에 코드를 복제합니다. Lambda@Edge는 하루 몇 건의 요청에서 초당 수천 건까지 자동으로 확장하도록 지원합니다.

Lambda@Edge는 CloudFront에서 특정 캐시 동작에 함수를 연결하여 실행됩니다. 또한, CloudFront 요청 또는 응답 처리 중에 함수가 실행되는 시점(즉, 시청자가 랜드를 요청하는 경우, 요청이 오리진으로 전달되거나 오리진에서 다시 수신되는 경우 또는 최종 시청자에게 다시 응답하기 바로 직전)을 지정할 수도 있습니다. Lambda 콘솔에서 Node.js 또는 Python를 사용하거나 API 또는 서버리스 애플리케이션 모델(SAM) 같은 프레임워크를 사용하여 코드를 작성할 수 있습니다. 함수를 테스트한 후 선택한 CloudFront 캐시 동작 및 이벤트 트리거에 함수를 연결합니다. 저장이 완료된 후, 다음번에 CloudFront 배포에 대한 해당 요청이 있을 경우 함수가 CloudFront 엣지로 전파되며 필요에 따라 규모가 조정되고 실행됩니다. 자세한 내용은 설명서를 참조하세요.

다음과 같은 Amazon CloudFront 이벤트에 대한 응답으로 Lambda@Edge 함수가 자동으로 트리거됩니다.

• 뷰어 요청: 최종 사용자나 인터넷 상의 디바이스가 CloudFront에 HTTP(S) 요청을 하고 해당 사용자에게 가장 가까운 엣지 로케이션에 요청이 도착할 때 이 이벤트가 발생합니다.
• 뷰어 응답: 엣지에 있는 CloudFront 서버가 요청한 최종 사용자나 디바이스에 응답할 준비가 될 때 이 이벤트가 발생합니다.
• 오리진 요청: CloudFront 엣지 서버에 캐시에서 요청된 객체가 아직 없고 백엔드 원본 웹 서버(예: Amazon EC2, Application Load Balancer 또는 Amazon S3)로 최종 사용자 요청을 보낼 준비가 되어 있을 때 이 이벤트가 발생합니다.
• 오리진 응답: 엣지에 있는 CloudFront 서버가 백엔드 오리진 웹 서버에서 응답을 수신할 때 이 이벤트가 발생합니다.

CloudFront의 지속적 배포는 모든 최종 사용자에게 변경 사항을 배포하기 전에 라이브 트래픽의 일부로 구성 변경 사항을 테스트하고 검증하는 기능을 제공합니다.

CloudFront의 지속적 배포는 높은 수준의 배포 안전성을 제공합니다. 이제 별도지만 동일한 두 개의 환경인 블루 및 그린을 배포하고 도메인 이름 시스템(DNS)을 변경하지 않고도 점진적으로 릴리스를 롤아웃할 수 있는 기능을 통해 지속적 통합 및 전달(CI/CD) 파이프라인에 간단하게 통합할 수 있습니다. 시청자 세션을 동일한 환경에 바인딩하여 세션 고정성을 통해 시청자가 일관된 환경을 확보할 수 있도록 합니다. 또한 표준 및 실시간 로그를 모니터링하여 변경 사항의 성능을 비교할 수 있으며, 변경 사항이 서비스에 부정적인 영향을 미칠 경우 빠르게 이전 구성으로 되돌릴 수 있습니다. 

CloudFront 콘솔, SDK, 명령줄 인터페이스(CLI) 또는 CloudFormation 템플릿을 통해 스테이징 배포를 기본 배포에 연결하여 지속적 배포를 설정할 수 있습니다. 그런 다음 클라이언트 헤더를 구성하거나 스테이징 배포로 테스트할 트래픽 비율을 다이얼링하여 트래픽을 분할하는 규칙을 정의할 수 있습니다. 일단 설정되면 원하는 변경 사항으로 스테이징 구성을 업데이트할 수 있습니다. CloudFront는 사용자에 대한 트래픽 분할을 관리하고 배포를 계속할지 또는 롤백할지 결정하는 데 도움이 되는 관련 분석을 제공합니다. 스테이징 배포를 사용한 테스트가 검증되면 변경 사항을 기본 배포에 병합할 수 있습니다.

이 기능에 대해 자세히 알아보려면 설명서를 참조하세요.

지속적 배포를 사용하면 실제 웹 트래픽을 통해 실제 사용자 모니터링이 가능합니다. 사용 가능한 기존 모니터링 방법(CloudFront 콘솔, CloudFront API, CLI 또는 CloudWatch)을 사용하여 기본 및 스테이징 배포의 운영 지표를 개별적으로 측정할 수 있습니다. 2가지 배포 간의 처리량, 대기 시간, 가용성 지표를 측정하고 비교하여 특정 애플리케이션의 성공 기준을 측정할 수 있습니다.

예. 기존 배포를 기준으로 사용하여 스테이징 배포를 생성하고, 변경 사항을 도입 및 테스트할 수 있습니다.

지속적 배포를 사용하면 다양한 기능을 기본 및 스테이징 배포와 연결할 수 있습니다. 두 배포에서 동일한 기능을 사용할 수도 있습니다. 두 배포에서 사용되는 함수를 업데이트하면 두 배포 모두 업데이트를 받습니다.

CloudFormation 스택의 각 리소스는 특정 AWS 리소스에 매핑됩니다. 스테이징 배포는 자체 리소스 ID를 가지며 다른 AWS 리소스처럼 작동합니다. CloudFormation을 사용하여 해당 리소스를 생성/업데이트할 수 있습니다.

가중치 기반 구성을 사용하여 트래픽을 스테이징 배포로 라우팅할 경우, 세션 고정성을 활성화할 수도 있습니다. 이렇게 하면 CloudFront가 동일한 최종 사용자의 요청을 단일 세션으로 처리하는 데 도움이 됩니다. 세션 고정성을 활성화하면 CloudFront는 쿠키를 설정하여 단일 세션에서 동일한 최종 사용자의 모든 요청이 하나의 배포(기본 또는 스테이징)에서 처리되도록 합니다.

지속적 배포 기능은 모든 CloudFront 엣지 로케이션에서 추가 비용 없이 사용할 수 있습니다.

인터넷에 연결된 모든 서버와 디바이스에는 숫자로 구성된 인터넷 프로토콜(IP) 주소가 있어야 합니다. 인터넷과 이를 사용하는 사용자 수가 기하급수적으로 증가함에 따라 IP 주소에 대한 수요 또한 급증하고 있습니다. IPv6는 이전 버전인 IPv4보다 더 큰 주소 공간을 사용하는 새로운 버전의 인터넷 프로토콜입니다. IPv4에서는 모든 IP 주소의 길이가 32비트이므로 43억 개의 고유한 주소를 제공할 수 있습니다. IPv4 주소의 한 예로 192.0.2.1을 들 수 있습니다. 반면에 IPv6 주소는 128비트입니다. 즉, 약 340조 개의 고유한 IP 주소를 제공할 수 있습니다. IPv6 주소의 예로는 2001:0db8:85a3:0:0:8a2e:0370:7334를 들 수 있습니다.

Amazon CloudFront의 IPv6 지원 기능을 사용하면 애플리케이션은 IPv6에서 IPv4로 변환하는 소프트웨어나 시스템 없이도 Amazon CloudFront 엣지 로케이션에 연결할 수 있습니다. 미국 연방 정부를 비롯하여 정부에서 정한 IPv6 도입에 대한 요구 사항을 충족하고, IPv6 확장성, 네트워크 관리의 간편성, 보안에 대한 기본 지원을 추가로 활용할 수 있습니다.

아니요. Amazon CloudFront에서 IPv4 또는 IPv6 중 어떤 것을 사용하든 성능은 동일합니다.

모든 Amazon CloudFront의 기존 기능은 IPv6에서도 계속 작동합니다. 다만 배포에 대해 IPv6를 활성화하기 전에 내부 IPv6 주소 처리를 위해 두 가지 항목을 변경해야 할 수도 있습니다.

1. Amazon CloudFront 액세스 로그 기능을 활성화했다면 ‘c-ip’ 필드에 최종 사용자의 IPv6 주소가 표시되기 시작할 겁니다. 로그 처리 시스템이 IPv6에서도 계속 작동하는지 확인해야 할 수도 있습니다.
2. Amazon CloudFront 배포에 대해 IPv6를 활성화하면 오리진으로 전송된 ‘X-Forwarded-For’ 헤더에 IPv6 주소가 표시됩니다. 오리진 시스템에서 IPv4 주소만 처리할 수 있는 경우에는 오리진 시스템이 IPv6에서도 계속 작동하는지 확인해야 할 수도 있습니다.

또한, 신뢰할 수 있는 서명자용 IP 화이트리스트를 사용하는 경우, IP 화이트리스트의 신뢰할 수 있는 서명자 URL에 대해서는 IPv4 전용 배포를 사용하고 다른 모든 콘텐츠에 대해서는 IPv4/IPv6 배포를 사용해야 합니다. 이 모델은 서명 요청이 IPv4 주소를 통해 전송되고 서명된 경우 발생할 수 있는 문제를 방지합니다. 콘텐츠에 대한 요청이 화이트리스트에 없는 다른 IPv6 주소를 통해 수신되도록 하기만 하면 됩니다.

Amazon CloudFront의 IPv6 지원에 대해 자세히 알아보려면 Amazon CloudFront 개발자 안내서에서 ‘Amazon CloudFront의 IPv6 지원’ 섹션을 참조하세요.

IPv6와 IP 화이트리스트의 신뢰할 수 있는 서명자 URL을 사용하려면 2개의 별도 배포를 사용해야 합니다. IP 화이트리스트의 신뢰할 수 있는 서명자 URL에 대한 전용 배포를 만들고 해당 배포에 대해서는 IPv6를 비활성화해야 합니다. 그런 다음, 그 외 모든 콘텐츠에 대해서는 IPv4와 IPv6를 둘 다 사용할 수 있는 또 다른 배포를 적용해야 합니다.

예. Amazon CloudFront 액세스 로그 기능이 활성화된 경우 최종 사용자의 IPv6 주소가 액세스 로그의 ‘c-ip’ 필드에 표시됩니다. 배포에 대해 IPv6를 활성화하기 전에 로그 처리 시스템이 IPv6 주소에서도 계속 작동하는지 확인해야 할 수도 있습니다. IPv6 트래픽 문제가 액세스 로그에서 IPv6 주소를 처리하는 도구 또는 소프트웨어의 기능에 영향을 미칠 경우 Developer Support에 문의해 주시기 바랍니다. 자세한 내용은 Amazon CloudFront 액세스 로그 설명서를 참조하세요.

예. Amazon CloudFront 콘솔 또는 API를 사용하여 기존 및 새로운 배포 양쪽 모두에 대해 배포별로 IPv6를 활성화하거나 비활성화할 수 있습니다.

AWS 고객에 따르면, 비활성화해야 하는 일반 사용 사례는 내부 IP 주소 처리의 경우뿐이었습니다. Amazon CloudFront 배포에 대해 IPv6를 활성화하면 IPv6 주소가 상세 액세스 로그에 표시될 뿐만 아니라 오리진으로 전송되는 ‘X-Forwarded-For’ 헤더에도 표시됩니다. 오리진 시스템이 IPv4 주소만 처리할 수 있는 경우에는 배포에 대해 IPv6를 활성화하기 전에 오리진 시스템이 IPv6 주소에서도 계속 작동하는지 확인해야 할 수도 있습니다.

Amazon CloudFront는 전 세계에서 매우 다양한 연결을 지원합니다. 하지만 어디에서나 흔히 볼 수 있는 IPv6 연결을 지원하지 않는 네트워크가 여전히 존재합니다. 분명 장기적으로는 IPv6가 인터넷의 미래가 되겠지만, 당분간은 모든 인터넷 엔드포인트에서 IPv4 연결을 사용하게 될 것입니다. IPv6보다 IPv4 연결이 더 잘 지원되는 인터넷을 접할 경우 IPv4를 선호하게 됩니다.

예. ‘A’와 ‘AAAA’ 레코드 유형을 각각 사용하여 IPv4 및 IPv6를 둘 다 지원하도록 Amazon CloudFront 배포를 가리키는 Route 53 별칭 레코드를 생성할 수 있습니다. IPv4만 활성화하려면 ‘A’ 유형의 별칭 레코드 하나만 있으면 됩니다. 별칭 리소스 레코드 세트에 대한 자세한 내용은 Amazon Route 53 개발자 안내서를 참조하세요.

2021년 12월 1일부터 모든 AWS 고객은 매월 1TB의 데이터 전송, 10,000,000개의 HTTP/HTTPS 요청, 2,000,000개의 CloudFront Functions 호출을 무료로 받게 됩니다. 다른 모든 사용 유형(예: 무효화, 프록시 요청, Lambda@edge, 오리진 Shield, 오리진으로 데이터 전송 등)은 프리 티어에서 제외됩니다.  

아니요. 여러 계정의 결제를 통합하기 위해 통합 결제를 사용하는 고객은 조직당 하나의 프리 티어에만 액세스할 수 있습니다.

1TB 데이터 전송 및 1천만 개의 Get 요청은 모든 엣지 로케이션에서 월간 프리 티어의 한도입니다. 사용량이 월간 프리 티어 한도를 초과할 경우, 각 리전에 대해 표준 온디맨드 AWS 서비스 요금을 지불하기만 하면 됩니다. 전체 요금 내역은 AWS CloudFront 요금 페이지를 참조하세요.

계정에 로그인하여 결제 및 비용 관리 대시보드로 이동하면 리전별로 현재와 과거의 사용 내역을 확인할 수 있습니다. 여기에서 AWS Budgets를 사용하여 비용 및 사용량을 관리하고, Cost Explorer를 통해 비용 동인과 사용 추세를 시각화하고, Cost and Usage Report를 사용하여 비용을 자세히 파악할 수 있습니다. AWS 비용을 관리하는 방법에 대한 자세한 내용은 AWS 비용 관리에 대해 다루는 10분 분량의 자습서를 참조하세요.

CloudFront 보안 절감형 번들을 구독하는 고객은 프리 티어의 혜택도 누릴 수 있습니다. 프리 티어를 고려하여 CloudFront 보안 절감형 번들에 대한 약정을 낮출 필요가 있다고 생각되는 경우, 고객 서비스에 연락하시면 변경 요청을 평가해 드리겠습니다. 이에 대한 자세한 내용은 며칠 내에 제공할 예정입니다. 계속해서 관심을 가져주시기 바랍니다. 

추가 질문은 https://aws.amazon.com/free/free-tier-faqs/를 참조하세요.

Amazon CloudFront 요금은 데이터 전송, HTTP/HTTPS 요청, 무효화 요청, 실시간 로그 요청, CloudFront 배포와 연결된 전용 IP 사용자 지정 SSL 인증서의 5가지 영역에서 서비스의 실제 사용량을 기준으로 부과됩니다.

AWS 프리 티어를 사용하면 Amazon CloudFront를 무료로 시작할 수 있으며 사용량이 늘어남에 따라 요금을 낮출 수 있습니다. 모든 CloudFront 고객은 이러한 한도를 초과하는 경우에도 1TB의 데이터 전송을 받고, Amazon CloudFront에 대한 10,000,000개의 HTTP 및 HTTPS 요청을 무료로 받습니다. 경우 

• 인터넷으로의 데이터 전송
  Amazon CloudFront 엣지 로케이션에서 전송된 데이터의 양(GB 단위로 측정됨)에 대해 비용이 청구됩니다. Amazon CloudFront에서 인터넷으로의 데이터 전송에 대한 요금은 여기에서 확인할 수 있습니다. 지리적 리전별로 데이터 송신 사용량 총합을 집계한 후 각 지역의 요금 티어를 바탕으로 비용을 계산합니다. 파일 오리진으로 다른 AWS 서비스를 사용할 경우, 스토리지 및 컴퓨팅 시간을 포함한 해당 서비스 사용료가 별도로 부과됩니다. 2014년 12월 1일부터는 AWS 오리진(예: Amazon S3, Amazon EC2 등)을 사용할 경우, Amazon CloudFront로의 AWS 데이터 송신 요금을 부과하지 않습니다. 이러한 사항은 모든 AWS 리전에서 모든 글로벌 CloudFront 엣지 로케이션으로 데이터를 전송하는 경우에 적용됩니다.
• 오리진으로의 데이터 송신
  Amazon CloudFront 엣지 로케이션에서 오리진(AWS 오리진 및 기타 오리진 서버 둘 다 해당)으로 전송된 데이터의 양(GB 단위로 측정됨)에 대해 요금이 부과됩니다. Amazon CloudFront에서 오리진으로의 데이터 전송에 대한 요금은 여기에서 확인할 수 있습니다.
• HTTP/HTTPS 요청
  Amazon CloudFront에 전송한 콘텐츠의 HTTP/HTTPS 요청 수에 대해 요금이 부과됩니다. 여기에서 HTTP/HTTPS 요청에 대한 요금을 확인할 수 있습니다.
• 무효화 요청
  무효화 요청의 경로마다 요금이 청구됩니다. 무효화 요청에 기재된 경로는 CloudFront 캐시에서 무효화하려는 객체의 URL(경로에 와일드카드 문자가 포함되어 있는 경우 URL 여러 개)을 나타냅니다. 매달 추가 비용 없이 Amazon CloudFront에서 최대 1,000개 경로를 요청할 수 있습니다. 초기 1,000개 경로를 초과하는 경우 무효화 요청에 기재된 경로당 요금이 청구됩니다. 여기에서 무효화 요청에 대한 요율을 확인할 수 있습니다.
• 실시간 로그 요청
  실시간 로그 요금은 생성된 로그 줄 수를 기준으로 부과되며 CloudFront가 로그 대상에 게시하는 로그 1,000,000개당 0.01 USD가 부과됩니다.
• 전용 IP 사용자 정의 SSL
  사용자 정의 SSL 인증 지원의 전용 IP 버전을 사용하여 하나 이상의 CloudFront 배포와 관련된 각 사용자 정의 SSL 인증서에 대해 매월 600 USD를 지불합니다. 이 월별 요금은 시간 단위로 비례 청구됩니다. 예를 들어, 6월에 24시간(즉 1일) 동안 최소 하나의 CloudFront 배포에 연결된 사용자 지정 SSL 인증서를 가진 경우 6월 사용자 지정 SSL 인증서 사용에 대한 전체 비용은 (1일/30일) * 600 USD = 20 USD입니다. 전용 IP 사용자 지정 SSL 인증서 지원을 사용하려면 SSL 인증서를 업로드한 후 AWS Management Console을 사용하여 이를 CloudFront 배포에 연결합니다. CloudFront 배포에 사용자 지정 SSL 인증서를 2개 이상 연결해야 할 경우, CloudFront 한도 증가 요청 양식에 사용 사례에 대한 세부 정보 및 사용할 사용자 지정 SSL 인증서의 수를 기재하시기 바랍니다.

데이터 전송용 사용량 티어는 각 지리적 리전별로 별도로 측정됩니다. 별도의 언급이 없는 한 위의 가격은 관련 세금, 요금, 유사한 정부 요금(있는 경우)을 뺀 금액입니다.

명시된 경우를 제외하고, 요금에는 VAT 및 해당 판매세를 비롯한 관련 조세 공과가 포함되지 않습니다. 청구지 주소가 일본으로 되어 있는 고객의 경우 AWS 서비스 사용 시 일본 소비세의 적용을 받게 됩니다. 자세히 알아보세요.

로그 크기 1KB로 초당 1,000건의 요청을 처리하는 배포로, 샤드 2개를 가지고 미국 동부(오하이오)에서 Kinesis Data Stream을 생성하는 경우:

Kinesis Data Stream의 월별 비용: 여기의 Kinesis 계산기를 사용하여 계산했을 때 월 47.74 USD.

CloudFront 실시간 로그의 월별 비용: 월별 요청 수 X 실시간 로그 비용 = 1,000 * (60초 * 60분 *24시간 * 30일) X (0.01 USD / 1,000,000) = 월 25.92 USD

304는 조건부 GET 요청에 대한 응답으로서, HTTP/HTTPS 요청 및 인터넷으로의 데이터 전송 요금이 발생하게 됩니다. 304 응답은 메시지 본문을 포함하지 않지만, HTTP 헤더가 일부 대역폭을 사용하므로 표준 CloudFront 데이터 전송 요금이 부과됩니다. 데이터 전송량은 객체와 관련된 헤더에 따라 달라집니다.

예. ‘요금 클래스’는 Amazon CloudFront에서 콘텐츠를 전송하는 비용을 낮출 수 있는 옵션을 제공합니다. 기본적으로 Amazon CloudFront는 엣지의 전체 글로벌 네트워크를 이용해 콘텐츠를 전송함으로써 최종 사용자 지연 시간을 최소화합니다. 그러나 비용이 높은 곳에서는 더 많은 요금을 청구하기 때문에 지역에 따라 지연 시간이 짧은 콘텐츠를 최종 사용자에게 전송할 때 더 많은 요금을 지불해야 할 수 있습니다. 요금 계층을 사용하면 가격이 비싼 Amazon CloudFront 엣지를 Amazon CloudFront 배포에서 제외함으로써 전송 비용을 줄일 수 있습니다. 이러한 경우에 Amazon CloudFront는 고객이 선택한 가격 등급의 리전 내 엣지로부터 콘텐츠를 전송하며 해당 콘텐츠가 전송된 실제 로케이션의 데이터 전송 및 요청 요금을 사용자에게 부과합니다.

성능이 가장 중요하다면 아무것도 할 필요가 없습니다. 콘텐츠는 AWS의 모든 로케이션 네트워크를 통해 전송됩니다. 그러나 다른 가격 등급을 사용하려면 AWS Management Console 또는 Amazon CloudFront API를 통해 배포를 구성할 수 있습니다. 선택한 요금 계층에 일부 로케이션이 포함되어 있지 않은 경우, 최종 사용자 중 일부, 특히 요금 계층에 없는 지리적 로케이션에 있는 최종 사용자는 콘텐츠가 모든 Amazon CloudFront 로케이션에서 제공되는 경우보다 지연 시간이 길어질 수 있습니다.

경우에 따라 Amazon CloudFront가 해당 요금 계층에 포함되어 있지 않은 엣지에서 오는 콘텐츠 요청을 처리할 수도 있습니다. 세금 또는 요금이 적용되는 경우에는 해당 요금 적용 범위 중에서 가장 저렴한 세금 또는 요금만 부과됩니다.

각 요금 클래스를 구성하는 로케이션 목록은 여기에서 확인할 수 있습니다.

CloudFront 보안 절감형 번들은 일정 금액의 월 사용 요금(예: 월 100 USD)을 1년 약정하는 대신, CloudFront 청구 금액을 최대 30%까지 절감해 주는 유연한 셀프 서비스 요금제입니다.  추가 혜택으로, CloudFront 리소스를 보호하기 위한 AWS WAF (AWS 웹 애플리케이션 방화벽) 사용량이 약정된 플랜 금액의 최대 10%까지 추가 비용 없이 제공됩니다.  예를 들어 월 100 USD의 CloudFront 사용 요금을 약정하면 142.86 USD의 CloudFront 사용 요금을 충당할 수 있으므로 표준 요금에 비해 30% 할인을 받는 셈입니다. 또한 CloudFront 리소스를 보호하기 위한 최대 10 USD의 AWS WAF 사용량이 매달 추가 비용 없이 제공됩니다(CloudFront 약정 금액의 최대 10%).  월간 지출 약정 금액을 초과하는 모든 요금에는 표준 CloudFront 및 AWS WAF 요금이 적용됩니다.  사용량이 증가하면 절감형 번들을 추가로 구입하여 늘어난 사용량에 대한 할인을 받을 수 있습니다. 

CloudFront 보안 절감형 번들을 구입하면 월간 청구서의 CloudFront 서비스 부분에 표시되며, 오리진 안팎으로의 데이터 전송, HTTP/S 요청 요금, 필드 수준 암호화 요청, Origin Shield, 무효화, 전용 IP 사용자 지정 SSL, Anycast 고정 IP, Lambda@Edge, CloudFront Functions, 실시간 로그, 리전별 엣지 캐시 사용, gRPC, WebSocket 지원 및 기타 CloudFront 기능 등 청구되는 모든 CloudFront 사용 유형을 상쇄하는 하는 30%의 절감 혜택을 얻을 수 있습니다. 또한 CloudFront 배포와 관련한 AWS WAF 사용량에 적용되는 추가 혜택도 받을 수 있습니다.

CloudFront 보안 절감형 번들은 CloudFront 콘솔을 방문하여 과거 CloudFront 및 AWS WAF 사용량을 기준으로 한 약정 금액에 대한 권장 사항을 확인하거나 예상 월 사용량을 입력하는 것으로 시작할 수 있습니다. CloudFront 보안 절감형 번들 월별 요금을 온디맨드 비용과 비교하고 예상 절감액을 확인하여 요구 사항에 적합한 플랜을 결정할 수 있습니다.  Savings Bundle에 가입하면 월간 약정 금액이 청구되며 CloudFront 및 WAF 사용 요금을 상쇄하는 크레딧이 표시됩니다.  월간 지출 약정 금액을 초과하는 모든 요금에는 표준 서비스 요금이 적용됩니다. 

CloudFront 보안 절감형 번들 기간이 만료되면 CloudFront 및 AWS WAF 사용량에 대해 표준 서비스 요금이 적용됩니다.   월간 Savings Bundle 약정 금액은 더 이상 청구되지 않으며 Savings Bundle 혜택이 더 이상 적용되지 않습니다.  번들 기간이 만료되기 전에 언제든지 CloudFront 보안 절감형 번들을 1년 더 자동으로 갱신하도록 선택할 수 있습니다.

CloudFront 보안 절감형 번들은 AWS Organization/통합 결제 패밀리 내의 모든 계정에서 구입할 수 있습니다.   CloudFront Security Savings Bundle 혜택은 청구서에 크레딧으로 적용됩니다. 절감형 번들에서 제공하는 혜택은 AWS Organizations/통합 결제 패밀리의 모든 계정에 기본적으로 적용되며(크레딧 공유가 활성화됨), 구독 계정이 조직에 참여하거나 이탈하는 시점에 따라 결정됩니다.  단일 계정과 여러 계정에 AWS 크레딧이 어떻게 적용되는지 자세히 알아보려면 AWS 크레딧을 참조하세요.

예. 사용량이 증가하면 추가 CloudFront 보안 절감형 번들을 구입하여 증가한 사용량에 대해 할인을 받을 수 있습니다.   AWS 결제 금액을 계산할 때 활성 CloudFront 보안 절감형 번들이 모두 반영됩니다.

청구서의 별도 CloudFront 보안 번들 섹션에 월간 약정 요금이 표시됩니다.  CloudFront 보안 절감형 번들로 충당되는 사용량은 청구서의 CloudFront 및 WAF 부분에 표준 사용 요금을 상쇄하는 크레딧으로 표시됩니다.  

예. AWS Budgets를 사용하면 비용 및 사용량 임계값을 설정할 수 있으며, 실제 또는 예상 요금이 임계값을 초과할 경우 이메일 또는 Amazon SNS 주제를 통해 알림을 받을 수 있습니다.  CloudFront Service에 대해 필터링된 사용자 지정 AWS 예산을 생성하고, 예산 임계값을 CloudFront 보안 절감형 번들로 충당되는 CloudFront 온디맨드 사용 요금으로 설정하여 해당 임계값을 초과할 경우 그에 대한 알림을 받을 수 있습니다.   예산에 대한 자세한 내용은 AWS Billing and Cost Management 사용 설명서에서 AWS Budgets로 비용 관리 및 예산 생성을 참조하세요. 

CloudFront 보안 절감형 번들의 추가 혜택으로, CloudFront 리소스를 보호하기 위한 AWS WAF 사용량이 약정된 플랜 금액의 최대 10%까지 추가 비용 없이 제공됩니다. CloudFront 보안 절감형 번들에 포함되지 않는 사용량에 대해서는 표준 CloudFront 및 AWS WAF 요금이 적용됩니다.  AWS Marketplace를 통해 가입한 관리형 WAF 규칙은 CloudFront 보안 절감형 번들로 충당되지 않습니다. 

2가지 중 하나에만 가입할 수 있습니다.  사용자 지정 요금 계약과 관련하여 궁금한 점이 있는 경우 AWS 계정 관리자에게 문의하세요.

CloudFront 콘솔을 통해서만 CloudFront 보안 절감형 번들에 가입할 수 있습니다.  향후 개선 사항으로 API를 통해 이용할 수 있도록 하는 방안을 평가할 계획입니다.