엣지와 DNS

Amazon CloudFront — 배포, 오리진, 캐시 동작

CloudFront는 배포(distribution) 단위로 구성합니다. 배포 하나는 콘텐츠를 가져올 오리진(origin) 목록과, 요청 경로에 따라 어떻게 처리할지 정하는 캐시 동작(cache behavior) 목록을 가집니다. 배포를 만들면 d111111abcdef8.cloudfront.net 형태의 도메인 이름이 생기고, 자체 도메인을 쓰려면 대체 도메인 이름(alternate domain name, CNAME)을 등록합니다.

오리진 — S3, ALB, 그리고 커스텀 오리진

CloudFront는 오리진을 두 부류로 취급합니다. S3 REST 엔드포인트를 가리키는 S3 오리진과, 그 밖의 모든 것을 가리키는 커스텀 오리진입니다. API 문서는 커스텀 오리진을 "S3 버킷이 아닌 모든 오리진, 단 한 가지 예외가 있다"고 정의하는데, 그 예외가 정적 웹사이트 호스팅으로 구성된 S3 버킷입니다. 웹사이트 엔드포인트는 S3 오리진이 아니라 커스텀 오리진으로 등록해야 합니다.

이 구분이 시험에서 중요한 이유는 OAC를 쓸 수 있는지가 여기서 갈리기 때문입니다. 웹사이트 엔드포인트로 등록한 버킷에는 OAC도 OAI도 붙일 수 없습니다. S3를 비공개로 유지하면서 CloudFront로만 노출하려면 REST 엔드포인트 + OAC 조합이어야 합니다.

오리진과의 연결 방식은 OriginProtocolPolicy가 정합니다. 값은 http-only · https-only · match-viewer 세 가지이며, 엔드투엔드 암호화가 요구되면 https-only를 씁니다. 오리진 응답 타임아웃은 기본 30초(1~120초), 연결 유지(keep-alive) 타임아웃은 기본 5초(1~120초)입니다.

오리진을 오리진 그룹(origin group)으로 묶으면 기본 오리진이 지정한 상태 코드를 반환할 때 보조 오리진으로 넘어갑니다. 이것이 CloudFront 수준의 오리진 장애 조치이며, DNS 수준의 장애 조치인 Route 53 장애 조치 라우팅과는 계층이 다릅니다.

캐시 동작과 경로 패턴

배포에는 기본 캐시 동작이 정확히 하나 있어야 하고, 경로 패턴(images/*.jpg 같은)을 가진 추가 캐시 동작을 여러 개 둘 수 있습니다. 요청 경로는 캐시 동작이 나열된 순서대로 비교되며, 처음 일치한 동작이 적용됩니다. 정적 자산과 동적 API를 한 배포에서 다루려면 이 순서를 설계해야 합니다.

캐시 동작마다 대상 오리진, ViewerProtocolPolicy(allow-all · https-only · redirect-to-https), 허용 HTTP 메서드, 압축 여부, 그리고 세 가지 정책을 붙입니다.

TTL — 무엇이 우선하는가

CloudFront 개발자 안내서는 기본적으로 파일이 24시간 후 만료된다고 명시합니다. 이 기본값은 두 가지 방법으로 바꿉니다. 캐시 동작 전체에 적용하려면 캐시 정책의 MinTTL · DefaultTTL · MaxTTL을 조정하고, 개별 파일만 바꾸려면 오리진이 Cache-Control: max-age 또는 s-maxage, 혹은 Expires 헤더를 붙여 내려보냅니다.

두 헤더를 모두 보내면 CloudFront는 Cache-Control max-age만 봅니다. 반대로 뷰어가 보낸 Cache-Control이나 Pragma 헤더는 무시합니다. 클라이언트가 헤더를 붙여 오리진까지 강제로 다녀오게 만들 수는 없습니다.

캐시 무효화 — 마지막 수단이다

만료 전에 파일을 엣지 캐시에서 없애려면 무효화(invalidation)를 요청합니다. 경로는 /images/image1.jpg처럼 개별 파일이거나 /images/*처럼 * 와일드카드로 끝날 수 있습니다. 무효화는 대소문자를 구분하고, 쿠키나 헤더로 여러 벌이 캐시된 경우에는 모든 벌이 함께 무효화됩니다. 특정 벌만 골라 지울 수는 없습니다.

AWS 문서는 자주 바뀌는 파일에는 무효화가 아니라 버전이 붙은 파일 이름 (style.v3.css 같은)을 권장합니다. 이유는 세 가지입니다. 사용자 브라우저나 회사 프록시에 남은 캐시까지는 무효화가 닿지 않고, 액세스 로그에서 버전별 결과를 구분할 수 있으며, 되돌리기가 쉽습니다. 월별 무료 한도를 넘긴 무효화 경로에는 요금이 붙는다는 점도 이유에 들어갑니다.

# 와일드카드를 쓸 때는 셸이 확장하지 않도록 반드시 따옴표로 감쌉니다.
aws cloudfront create-invalidation \
  --distribution-id E1234567890ABC \
  --paths "/*"

# 특정 디렉터리만 비웁니다.
aws cloudfront create-invalidation \
  --distribution-id E1234567890ABC \
  --paths "/images/*" "/index.html"

오리진 보호 — OAC로 S3 버킷을 비공개로 유지한다

CloudFront 뒤에 S3를 두는 구성에서 버킷을 퍼블릭으로 여는 것은 오답입니다. 버킷이 퍼블릭이면 누구나 S3 엔드포인트로 직접 접근할 수 있어 CloudFront의 서명 URL · 지리적 제한 · WAF 규칙이 전부 우회됩니다. 정답은 버킷을 비공개로 두고, CloudFront가 서명한 요청만 버킷 정책으로 허용하는 것입니다.

원본 액세스 제어(OAC)

AWS는 S3 오리진에 인증된 요청을 보내는 방법으로 OAC와 구형인 원본 액세스 ID(Origin Access Identity, OAI) 두 가지를 제공하며, 문서는 OAC를 권장합니다. OAC가 지원하는 것 중 OAI가 못 하는 것은 다음 셋입니다.

• 2022년 12월 이후 출시된 옵트인 리전을 포함한 모든 리전의 S3 버킷
• SSE-KMS로 암호화된 객체 (KMS 키 정책에 OAC를 허용하는 문장을 추가해야 합니다)
• PUT · DELETE 같은 동적 요청

OAC 자체는 서명 프로토콜(sigv4)과 서명 동작(always · never · no-override)만 정의합니다. 접근을 실제로 허용하는 것은 S3 버킷 정책이며, 이 점이 시험에서 자주 갈립니다.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AllowCloudFrontServicePrincipalReadOnly",
    "Effect": "Allow",
    "Principal": {
      "Service": "cloudfront.amazonaws.com"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::example-static-assets/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1234567890ABC"
      }
    }
  }
}

AWS:SourceArn 조건이 없으면 다른 계정의 아무 배포나 이 버킷을 오리진으로 삼을 수 있습니다. 조건을 빼먹은 정책은 "CloudFront만 허용했다"고 착각하기 쉬운 대표적인 잘못된 구성입니다.

서명 URL과 서명 쿠키

오리진을 감추는 것과 콘텐츠를 볼 자격이 있는 사람만 보게 하는 것은 다른 문제입니다. 후자는 서명 URL 또는 서명 쿠키로 해결합니다. 캐시 동작에 신뢰할 수 있는 키 그룹(TrustedKeyGroups)을 연결하면 그 동작에 매칭되는 모든 요청에 서명이 요구됩니다. 서명은 키 그룹에 등록된 공개 키에 대응하는 개인 키로 만듭니다.

지리적 제한

CloudFront의 지리적 제한 기능은 국가 단위로 동작하며, 허용 목록(allow list) 또는 차단 목록(block list) 중 하나를 씁니다. 차단된 요청에는 403 Forbidden이 반환되고, 이 오류 응답은 기본적으로 10초 동안 캐시됩니다.

중요한 제약은 지리적 제한이 배포 전체에 적용된다는 것입니다. 콘텐츠 일부에만 다른 제한을 걸어야 하면 배포를 나누거나, 도시 · 우편번호 단위처럼 국가보다 세밀한 기준이 필요하면 서드파티 지오로케이션 서비스와 서명 URL을 조합해야 합니다.

TLS 종료 지점과 ACM 인증서

CloudFront는 뷰어와의 TLS를 엣지에서 종료합니다. 대체 도메인 이름을 쓰려면 인증서가 필요한데, 여기서 리전 제약이 하나 붙습니다. CloudFront API 문서는 CloudFront가 미국 동부(버지니아 북부) 리전 us-east-1의 ACM 인증서만 지원한다고 명시합니다. 서울 리전에서 발급한 인증서를 CloudFront에 붙일 수 없다는 뜻입니다.

SSLSupportMethod는 sni-only가 권장값입니다. SNI를 지원하지 않는 뷰어까지 받으려면 vip를 쓸 수 있으나 AWS는 권장하지 않고 추가 요금이 발생한다고 안내합니다. MinimumProtocolVersion은 콘솔에서 "보안 정책"으로 표시되며, 허용할 최소 TLS 버전과 암호 스위트를 함께 정합니다.

WAF와 Shield가 붙는 지점

AWS WAF의 웹 ACL은 범위(scope)가 두 가지입니다. CLOUDFRONT는 CloudFront 배포에 붙는 전역 범위이고, REGIONAL은 Application Load Balancer · Amazon API Gateway · AWS AppSync · Amazon Cognito 사용자 풀 같은 리전 리소스에 붙습니다.

연결 방법도 다릅니다. 리전 리소스는 AssociateWebACL API로 연결하지만, CloudFront는 배포 구성의 WebACLId 필드에 웹 ACL ARN을 넣어 연결합니다. 또한 CLOUDFRONT 범위의 웹 ACL은 us-east-1 엔드포인트에서 만들고 관리해야 합니다.

AWS Shield Standard는 모든 CloudFront 배포와 Route 53 호스팅 영역에 자동으로 적용됩니다. Shield Advanced는 별도 구독이며 대응 팀 지원과 공격 대응 기능이 추가됩니다. WAF는 계층 7 규칙, Shield는 DDoS 완화라는 역할 분담을 기억합니다.

엣지에서 코드 실행 — CloudFront Functions와 Lambda@Edge

요청과 응답을 엣지에서 손보는 방법은 두 가지입니다. CloudFront Functions는 CloudFront에 내장된 JavaScript 실행 환경이고, Lambda@Edge는 AWS Lambda의 확장으로 하나의 리전에 게시한 함수를 CloudFront가 전 세계에 복제합니다.

판단 기준은 단순합니다. 캐시 키 정규화 · 헤더 조작 · URL 재작성 · 토큰 검증처럼 요청 하나를 짧게 손보는 일은 CloudFront Functions입니다. 외부 서비스 호출, AWS SDK 사용, 요청 본문 읽기, 무거운 처리가 필요하면 Lambda@Edge입니다. 그리고 오리진 쪽 이벤트에서 뭔가를 해야 한다면 선택의 여지가 없습니다 — CloudFront Functions는 오리진 이벤트에 붙지 않습니다.

CloudFront와 비용 구조

CloudFront는 성능 서비스이면서 비용 최적화 레버이기도 합니다. 구조는 이렇습니다. 캐시가 적중하면 오리진까지 올라가는 요청이 사라지므로 오리진의 송신 트래픽과 요청 처리 부하가 함께 줄어듭니다. S3 오리진이면 GET 요청 수가 줄고, EC2나 ALB 오리진이면 인스턴스 사용량이 줄어듭니다.

비용을 다루는 문항은 금액을 계산시키지 않습니다. 구조적으로 트래픽이 줄어드는 안을 고르게 합니다. 판단 축은 셋입니다.

• 캐시 적중률을 올린다 — 캐시 키를 줄이고 TTL을 늘립니다. 가장 큰 레버입니다.
• 엣지 범위를 좁힌다 — PriceClass_100 · PriceClass_200 · PriceClass_All 중에서 고릅니다. 사용자가 특정 대륙에 몰려 있으면 전 세계 엣지를 살 이유가 없습니다.
• 무효화를 남발하지 않는다 — 버전이 붙은 파일 이름으로 대체합니다.

Amazon Route 53 — 호스팅 영역과 레코드

Route 53은 도메인 등록 · 권한 있는 DNS · 상태 확인 세 가지를 합친 서비스입니다. DNS 레코드는 호스팅 영역(hosted zone) 안에 만듭니다.

별칭 레코드와 CNAME

별칭(alias) 레코드는 Route 53 고유 기능으로, AWS 리소스를 직접 가리킵니다. API에서는 AliasTarget을 넣고 ResourceRecords와 TTL을 생략합니다. TTL은 대상 리소스의 값을 따릅니다.

Route 53 라우팅 정책 8종 SAA 빈출

Route 53의 라우팅 정책은 8종입니다. 시중 자료 상당수가 지리 근접과 IP 기반을 빠뜨려 6종이나 7종으로 적는데, Route 53 API의 레코드 구조에는 여덟 가지를 구분하는 멤버가 모두 있습니다. 여덟 가지를 전부 알고 있어야 "이 중 해당하지 않는 것은" 형태의 문항에서 실점하지 않습니다.

지연 시간 · 지리적 위치 · 지리 근접 — 시험이 노리는 3자 구분

셋 다 "가까운 데로 보낸다"처럼 들리지만 판단 기준이 완전히 다릅니다. 문제에서 어떤 단어가 쓰였는지로 갈립니다.

헷갈릴 때 쓰는 규칙은 이렇습니다. 지연 시간은 네트워크 성능이 기준이라 지리적으로 가까운 리전이 답이 아닐 수도 있습니다. 지리적 위치는 성능이 아니라 규정과 콘텐츠의 문제입니다. 지리 근접은 거리 기반이면서 편향값으로 비율을 조정할 수 있는 유일한 정책입니다.

상태 확인과 장애 조치 라우팅

Route 53 상태 확인은 여덟 가지 유형이 있고, 크게 세 부류입니다. 엔드포인트를 직접 찔러 보는 유형, 다른 상태 확인을 집계하는 유형, 그리고 외부 신호를 읽는 유형입니다.

요청 간격(RequestInterval)은 10초 또는 30초이며 지정하지 않으면 30초입니다. 실패 임계값(FailureThreshold)은 기본 3회로, 연속 3회 실패해야 상태가 뒤집힙니다. 두 값 모두 생성 후에는 바꿀 수 없습니다.

장애 조치 라우팅

장애 조치 라우팅은 같은 이름과 유형의 레코드 두 개에 PRIMARY와 SECONDARY를 지정하고 HealthCheckId를 붙여 구성합니다. 동작은 다음과 같습니다.

• 주 레코드가 정상이면 보조의 상태와 무관하게 주로 응답합니다.
• 주가 비정상이고 보조가 정상이면 보조로 응답합니다.
• 보조가 비정상이면 주의 상태와 무관하게 주로 응답합니다. 둘 다 죽었을 때는 주를 돌려줍니다.
• 보조에 상태 확인을 붙이지 않으면, 주가 비정상일 때 보조 엔드포인트의 실제 상태와 관계없이 항상 보조로 응답합니다.

장애 조치 별칭 레코드를 쓸 때는 EvaluateTargetHealth를 true로 설정해야 합니다. 그러지 않으면 대상이 죽어도 Route 53이 알아채지 못합니다.

{
  "Comment": "액티브-패시브 장애 조치",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "primary-seoul",
        "Failover": "PRIMARY",
        "HealthCheckId": "abcdef01-2345-6789-abcd-ef0123456789",
        "TTL": 60,
        "ResourceRecords": [{ "Value": "192.0.2.10" }]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "secondary-tokyo",
        "Failover": "SECONDARY",
        "HealthCheckId": "fedcba98-7654-3210-fedc-ba9876543210",
        "TTL": 60,
        "ResourceRecords": [{ "Value": "198.51.100.10" }]
      }
    }
  ]
}

AWS Global Accelerator와 CloudFront의 선택

Global Accelerator는 애니캐스트 고정 IP를 발급하고, AWS 엣지 네트워크에서 받은 트래픽을 AWS 글로벌 네트워크를 통해 최적의 엔드포인트로 보냅니다. IP 세트 하나는 최대 2개의 IP 주소를 가지며, 듀얼스택으로 만들면 IPv4 2개와 IPv6 2개를 받습니다.

핵심 차이는 캐시하지 않는다는 점입니다. Global Accelerator는 콘텐츠를 저장하지 않고 경로만 개선합니다. 리스너 프로토콜은 TCP와 UDP이며, 엔드포인트로는 Application Load Balancer, Network Load Balancer, 탄력적 IP 주소, EC2 인스턴스를 등록합니다.

판단 규칙은 두 문장으로 정리됩니다. 캐시할 수 있는 HTTP 콘텐츠라면 CloudFront입니다. 비 HTTP 프로토콜이거나, 클라이언트가 IP를 고정으로 알아야 하거나, 리전 간 장애 조치를 IP 변경 없이 하고 싶다면 Global Accelerator입니다. 게임 서버(UDP), VoIP, IoT 장비처럼 방화벽에 IP를 등록해야 하는 환경이 후자의 전형입니다.

흔한 오해

시험 포인트 정리

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

학습용 유형 연결형과 순서 배열 문항이 섞여 있을 수 있습니다. 이 두 유형은 암기 확인에 효율이 좋아서 기본개념 확인 문제에만 넣었으며, 실제 SAA-C03 시험에는 출제되지 않습니다.

이어서 볼 곳

• 15장 · 데이터 분석 파이프라인 엣지에서 모은 로그와 클릭스트림을 어디로 흘려보낼지. Kinesis 제품군과 배치 대 스트리밍 판단을 다룹니다. 기본개념
• 8장 · S3와 오브젝트 스토리지 OAC로 보호할 대상인 버킷 자체의 보안 기본값과 버킷 정책, 정적 웹사이트 호스팅을 정리합니다. 기본개념 · SAA 최우선
• 7장 · 로드 밸런싱과 오토스케일링 고정 IP가 필요할 때의 또 다른 후보인 NLB, 그리고 CloudFront 오리진이 되는 ALB의 동작을 다룹니다. 기본개념 · SAA 최우선
• 16장 · 보안 · 암호화 · 거버넌스 ACM 인증서의 종료 지점, WAF와 Shield의 역할 분담을 보안 관점에서 이어서 다룹니다. 기본개념 · SAA 최우선
• 실습 3 · S3 정적 사이트 + CloudFront + OAC 버킷을 비공개로 유지한 채 배포를 만들고, 캐시 무효화까지 손으로 확인합니다. 실습 예제
• 네트워크 빠른참조 VPC 연결 옵션, 라우팅, DNS를 한 장으로 압축했습니다. 라우팅 정책 8종도 여기에 있습니다. 빠른참조

공식 문서 출처

이 장의 개념 서술과 API 동작은 모두 아래 문서에서 확인했습니다.

• Amazon CloudFront 개발자 안내서 — CloudFront란 — 배포 · 오리진 · 엣지 로케이션의 기본 개념
• Amazon CloudFront 개발자 안내서 — 캐시에 콘텐츠가 머무는 기간 관리 — 기본 만료 24시간, Cache-Control max-age와 Expires의 우선순위, 뷰어 요청의 캐시 헤더를 무시한다는 서술
• Amazon CloudFront 개발자 안내서 — 파일 무효화 — 와일드카드 경로, 대소문자 구분, 버전 파일명 권장 근거
• Amazon CloudFront 개발자 안내서 — Amazon S3 오리진에 대한 액세스 제한 — OAC 권장 이유 3가지와 버킷 정책 예시, 웹사이트 엔드포인트는 커스텀 오리진이라 OAC를 쓸 수 없다는 제약
• Amazon CloudFront 개발자 안내서 — 서명 URL과 서명 쿠키 중 선택 — 각각의 적용 조건과 서명 URL 우선 규칙
• Amazon CloudFront 개발자 안내서 — 콘텐츠의 지리적 배포 제한 — 국가 단위 제한, 403 응답과 기본 10초 캐시, 배포 전체 적용
• Amazon CloudFront 개발자 안내서 — 엣지에서 함수로 사용자 지정 — CloudFront Functions와 Lambda@Edge의 비교표
• Amazon CloudFront API 레퍼런스 — DefaultCacheBehavior — 캐시 정책 · 오리진 요청 정책 · 응답 헤더 정책, ForwardedValues와 TTL 필드가 deprecated라는 서술
• Amazon CloudFront API 레퍼런스 — CustomOriginConfig — 커스텀 오리진의 정의, OriginProtocolPolicy, 오리진 응답 타임아웃 기본 30초와 연결 유지 5초
• Amazon CloudFront API 레퍼런스 — ViewerCertificate — CloudFront가 us-east-1의 ACM 인증서만 지원한다는 서술, sni-only 권장
• Amazon CloudFront API 레퍼런스 — OriginAccessControlConfig — 서명 프로토콜 sigv4와 서명 동작 3가지
• Amazon Route 53 API 레퍼런스 — ResourceRecordSet — 라우팅 정책 8종을 구분하는 멤버(Weight, Region, Failover, GeoLocation, GeoProximityLocation, MultiValueAnswer, CidrRoutingConfig), SetIdentifier 필수 조건, 다중값 응답 최대 8개, 장애 조치 동작 규칙
• Amazon Route 53 API 레퍼런스 — AliasTarget — 별칭 레코드에서 TTL을 생략한다는 점, EvaluateTargetHealth의 제약
• Amazon Route 53 API 레퍼런스 — HealthCheckConfig — 상태 확인 유형 8종, 요청 간격 기본 30초, 실패 임계값 기본 3회, 문자열 검색은 앞 5,120바이트
• Amazon Route 53 API 레퍼런스 — GeoProximityLocation — 리전 · 로컬 존 그룹 · 좌표 중 하나를 지정하며 Bias로 영역 크기를 조절한다는 서술
• AWS Global Accelerator API 레퍼런스 — 애니캐스트 정적 IP, 표준 가속기와 사용자 지정 라우팅 가속기, API가 us-west-2에서 동작한다는 서술
• AWS Global Accelerator API 레퍼런스 — EndpointGroup — 트래픽 다이얼, 상태 확인 간격 10초/30초와 기본 30초, 임계값 기본 3회
• AWS WAF API 레퍼런스 — AssociateWebACL — CloudFront는 이 API가 아니라 배포 구성의 웹 ACL ARN으로 연결한다는 서술
• AWS WAF API 레퍼런스 — CreateWebACL — CLOUDFRONT 범위와 REGIONAL 범위의 구분, CloudFront 범위는 us-east-1에서 관리