Amazon CloudFront FAQ

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

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

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

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

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

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

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

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

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 리전의 Opt에 있는 S3 버킷에 표준 액세스 로그를 전송할 수 있습니다. 자세한 내용은 CloudFront 개발자 안내서의 표준 액세스 로그 섹션을 참조하세요.

CloudFront는 표준 로그 활성화에 대해서는 요금을 부과하지 않지만, 로그 전송 대상에 따라 로그 전송, 저장, 액세스에 대한 요금이 발생합니다. 자세한 내용은 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 Elasticsearch 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개의 샤드를 생성하는 방향으로 고민해보시기 바랍니다.