AWS Certified CloudOps Engineer - Associate (SOA-C03) #11 Domain 4-2 네트워킹: Route 53,CloudFront,전송 운영

5 분 소요

#10에서 VPC 내부 연결을 잡았다면, 이 글은 사용자에게 닿는 길인 DNS(Route 53)와 콘텐츠 전송(CloudFront)을 다룹니다. #5에서 가용성 관점으로 Route 53 페일오버를 봤다면, 여기서는 레코드,라우팅,캐싱의 운영 디테일을 정리하겠습니다.

Route 53: DNS 운영 #

레코드 종류 #

레코드역할
A / AAAA도메인 → IPv4 / IPv6
CNAME도메인 → 다른 도메인(루트 도메인에는 불가)
AliasAWS 자원(ELB,CloudFront,S3) → 무료, 루트 도메인 가능

핵심 함정은 CNAME은 루트 도메인(zone apex, 예: example.com)에 못 쓴다는 점입니다. 루트 도메인을 ELB나 CloudFront에 연결하려면 Alias 레코드를 써야 합니다. Alias는 Route 53 전용이고 쿼리 비용이 없으며 대상의 IP 변경을 자동 추적합니다. “루트 도메인을 ALB에 연결"의 답이 Alias입니다.

라우팅 정책 #

#5에서 본 정책을 운영 용도로 다시 정리하겠습니다.

정책용도
Simple단일 자원
Failover주,보조 전환(헬스체크 기반)
Weighted가중치 분산(점진 배포,카나리)
Latency가장 빠른 리전으로
Geolocation사용자 위치별 다른 응답(규제,현지화)
Geoproximity위치 + 바이어스로 트래픽 이동
Multivalue여러 정상 IP 반환

운영 시나리오 매핑이 시험 포인트입니다. 점진 배포,A/B는 Weighted, 지역 규제,콘텐츠 현지화는 Geolocation, 최저 지연은 Latency입니다.

헬스체크 #

Route 53 헬스체크는 엔드포인트를 주기적으로 점검해 비정상이면 DNS 응답에서 제외합니다. Failover의 전제이며, 다른 헬스체크 결과를 묶는 계산형(calculated) 헬스체크도 있습니다. DNS 캐시(TTL) 때문에 전환이 즉시는 아니므로, 빠른 전환이 필요하면 TTL을 낮춥니다.

CloudFront: 콘텐츠 전송(CDN) #

CloudFront는 전 세계 엣지 로케이션에 콘텐츠를 캐시해 지연을 줄이고 오리진 부하를 던다.

개념설명
Origin원본. S3, ALB, 임의 HTTP 서버
Behavior경로 패턴별 캐시,전달 규칙
Cache Policy무엇을 캐시 키로 쓸지(헤더,쿼리,쿠키)
TTL캐시 보존 시간

캐싱 운영 포인트 #

  • 정적 콘텐츠(이미지,JS,CSS)는 길게 캐시, 동적 콘텐츠는 짧게 또는 캐시 안 함
  • 배포 후 옛 콘텐츠가 남으면 무효화(invalidation)로 강제 갱신. 다만 무효화 남발은 비용이므로 버전 파일명(예: app.v2.js)이 더 권장
  • 오리진 부하를 줄이려는 목적이면 캐시 적중률(hit ratio)을 높이는 정책 설정

“배포했는데 사용자에게 옛 파일이 보인다"는 답이 무효화 또는 버전 파일명, “오리진 부하가 높다"는 캐시 정책으로 적중률을 올리는 것입니다.

S3 오리진 보안: OAC #

S3를 오리진으로 쓸 때, 사용자가 S3 URL로 직접 접근하는 것을 막고 CloudFront만 거치게 하려면 OAC(Origin Access Control)를 씁니다(과거 OAI의 후속). S3 버킷은 비공개로 두고 CloudFront에만 읽기를 허용합니다. “S3 콘텐츠를 CloudFront로만 접근하게 하라"는 답이 OAC입니다.

ACM: TLS 인증서 #

ACM은 HTTPS를 위한 인증서를 무료로 발급하고 자동 갱신합니다. 운영 포인트 두 가지가 단골입니다.

  • CloudFront에 붙이는 인증서는 반드시 us-east-1(버지니아 북부)에서 발급해야 합니다. 다른 리전 인증서는 CloudFront에 못 붙습니다.
  • ALB에 붙이는 인증서는 ALB와 같은 리전에서 발급합니다.
  • ACM 발급 인증서는 자동 갱신되지만, DNS 검증 레코드가 유지돼야 합니다.

“CloudFront에 ACM 인증서가 안 붙는다"의 답은 거의 항상 리전이 us-east-1이 아니어서입니다.

전송 트러블슈팅 #

증상점검
옛 콘텐츠가 보임무효화,캐시 TTL,버전 파일명
HTTPS 안 됨ACM 리전(CloudFront는 us-east-1), 인증서 도메인 일치
S3 직접 접근이 열려 있음OAC + 버킷 비공개
특정 지역만 느림엣지,라우팅 정책(Latency)
페일오버가 느림DNS TTL 낮추기

시험 출제 패턴 #

  • 루트 도메인을 ELB,CloudFront에 연결 → Alias 레코드
  • 점진 배포,카나리 → Weighted 라우팅
  • 지역 규제,현지화 → Geolocation 라우팅
  • 배포 후 옛 파일이 보임 → 무효화 / 버전 파일명
  • S3를 CloudFront로만 접근 → OAC + 버킷 비공개
  • CloudFront HTTPS 인증서 → ACM을 us-east-1에서 발급
  • 빠른 DNS 페일오버 → TTL 낮추기 + 헬스체크

자주 만나는 함정 #

1) 루트 도메인에 CNAME을 씀 #

zone apex에는 CNAME이 안 됩니다. Alias가 정답입니다.

2) CloudFront 인증서를 다른 리전에서 발급 #

CloudFront용 ACM은 반드시 us-east-1입니다. 가장 자주 나오는 함정입니다.

3) 무효화를 상시 배포 수단으로 씀 #

무효화는 비용이 들고 즉시도 아닙니다. 버전 파일명이 더 권장됩니다.

4) S3 정적 호스팅과 CloudFront OAC를 혼동 #

OAC로 비공개 S3를 쓰면 S3 정적 웹사이트 호스팅 엔드포인트가 아니라 REST 엔드포인트를 오리진으로 씁니다.

정리 #

이번 글에서 잡은 것:

  • Route 53 Alias로 루트 도메인을 AWS 자원에 연결(CNAME은 apex 불가, 무료)
  • 라우팅 정책: Weighted(점진),Geolocation(규제,현지화),Latency(최저 지연),Failover(헬스체크)
  • CloudFront로 지연,오리진 부하 감소. 옛 콘텐츠는 무효화/버전 파일명, 적중률로 오리진 보호
  • OAC로 S3를 CloudFront 전용 접근. 버킷은 비공개
  • ACM은 CloudFront용은 us-east-1, ALB용은 같은 리전. 자동 갱신

다음: Domain 5-1 IAM과 Organizations #

네트워킹 도메인을 마쳤습니다. 마지막 도메인은 보안과 컴플라이언스입니다.

#12 Domain 5-1 보안: IAM,Organizations,멀티계정 운영에서는 IAM 권한 운영, 자격 증명 보고서와 Access Analyzer, MFA 강제, AWS Organizations와 SCP, 그리고 멀티계정 거버넌스까지 운영 관점에서 정리하겠습니다.

X