CloudFront Custom Origin 앞에 별도 API 도메인을 둔 이유

AWS 실전 운영 시리즈 11/12

CloudFront를 S3 앞에 붙이는 구성은 익숙하다.

하지만 CloudFront를 EC2나 API 서버 앞에 둘 때는 조금 다른 문제가 생긴다.

CloudFront의 Custom Origin에는 origin domain name이 필요하다. 운영 중인 API 서버가 EC2 IP로만 접근 가능하다면, CloudFront origin으로 쓰기 위해 별도의 도메인을 만들어야 할 수 있다.

이 글은 API용 CloudFront 앞뒤에 왜 도메인을 두 개 만들었는지 정리한 것이다.

문제 상황

운영 콘솔에는 상주 API 서버가 있었다.

이 서버는 대시보드와 분석 API처럼 짧고 잦은 요청을 처리했다.

사용자는 다음 도메인으로 API를 호출하게 하고 싶었다.

api.example.com

그리고 이 도메인 앞에는 CloudFront를 두고 싶었다.

api.example.com
-> CloudFront
-> API server

문제는 CloudFront가 바라볼 origin이다.

API 서버가 EC2 위에 있고 고정 IP 또는 public IP로 접근 가능하더라도, CloudFront Custom Origin에는 도메인 이름을 지정하는 방식이 자연스럽다.

그래서 origin용 도메인을 하나 더 만들었다.

origin-api.example.com
-> EC2 API server

최종 구조

일반화하면 다음과 같다.

사용자는 api.example.com만 본다.

CloudFront는 origin-api.example.com을 origin으로 사용한다.

Route53은 origin-api.example.com을 실제 API 서버로 연결한다.

이 구조에서 사용자용 API 도메인은 외부 계약이고, origin 도메인은 CloudFront와 인프라 사이의 연결점이다.

왜 API 도메인과 origin 도메인을 나누나

두 도메인은 역할이 다르다.

도메인	역할
api.example.com	사용자와 프론트엔드가 호출하는 프로덕션 API
origin-api.example.com	CloudFront가 바라보는 실제 origin

사용자용 API 도메인은 안정적인 외부 계약이다.

origin 도메인은 내부 인프라 연결점이다.

이 둘을 나누면 origin이 바뀌어도 사용자 API 도메인은 유지할 수 있다.

예를 들어 나중에 EC2를 ALB나 ECS로 바꿔도 origin-api.example.com의 대상만 바꾸면 된다.

IP 변경에 대응하기 쉽다

EC2 IP가 바뀔 수 있다.

Elastic IP를 쓰지 않는다면 재시작이나 교체 과정에서 주소가 달라질 수 있다.

CloudFront origin에 서버 주소가 직접 박혀 있으면 변경이 번거롭다.

하지만 origin 도메인을 두면 Route53 record만 바꾸면 된다.

origin-api.example.com
-> 기존 EC2 IP
-> 새 EC2 IP

CloudFront 설정을 매번 바꾸지 않아도 된다.

디버깅이 쉬워진다

API 장애가 났을 때 문제 구간을 나눠야 한다.

브라우저
-> CloudFront
-> origin API server

api.example.com 호출이 실패할 때, origin-api.example.com이 정상인지 확인하면 CloudFront 문제인지 origin 문제인지 구분할 수 있다.

예를 들어:

• api.example.com 실패
• origin-api.example.com 성공
• CloudFront 설정, 캐시, header, WAF 쪽 확인

반대로 origin도 실패하면 API 서버 자체를 봐야 한다.

이런 디버깅 경로는 운영 중 유용하다.

하지만 우회 경로가 될 수 있다

origin 도메인은 편리하지만 보안상 주의가 필요하다.

사용자가 origin-api.example.com으로 직접 접근할 수 있다면 CloudFront와 WAF를 우회할 수 있다.

따라서 다음을 검토해야 한다.

• origin 서버 security group에서 CloudFront IP만 허용할 수 있는가
• origin에 custom header를 요구할 것인가
• origin 도메인을 내부용으로 제한할 수 있는가
• 직접 접근은 테스트 환경에서만 허용할 것인가
• API 자체 인증이 충분한가

CloudFront를 앞에 뒀다고 해서 origin이 자동으로 보호되는 것은 아니다.

이 점은 반드시 운영 문서에 남겨야 한다.

API CloudFront는 정적 CloudFront와 다르다

S3 앞의 CloudFront는 정적 파일 캐시가 핵심이다.

API 앞의 CloudFront는 역할이 조금 다르다.

• HTTPS 종단
• WAF 연결
• origin 보호
• header 전달
• path 기반 routing
• 일부 응답 캐시 가능성
• access log

API 응답은 대부분 사용자나 조건에 따라 달라질 수 있으므로 캐시 정책을 조심해야 한다.

정적 자산처럼 무조건 길게 캐시하면 안 된다.

CORS 관점에서의 영향

프론트엔드 도메인과 API 도메인이 다르면 CORS가 필요하다.

예를 들어:

console.example.com
api.example.com

둘은 다른 origin이다.

따라서 API 서버는 console.example.com을 허용해야 한다.

CloudFront가 API 앞에 있으면 CORS header가 제대로 전달되는지도 확인해야 한다.

특히 credentials를 쓰는 경우에는 wildcard origin을 사용할 수 없다.

문서화해야 할 것

API CloudFront 구성은 운영 문서에 명확히 남겨야 한다.

• 사용자용 API 도메인
• origin 도메인
• origin 대상
• CloudFront distribution
• WAF 적용 여부
• origin 직접 접근 가능 여부
• CORS 허용 origin
• health check URL
• 로그 위치

예시:

항목	예시
사용자 API	api.example.com
Origin domain	origin-api.example.com
Origin target	EC2 API server
Frontend origin	https://console.example.com
Health check	/api/health

이 표가 있으면 새 담당자가 구조를 빠르게 이해할 수 있다.

정리

CloudFront Custom Origin 앞에 별도 API 도메인을 둔 이유는 단순 설정 문제가 아니다.

운영 유연성을 위한 선택이다.

이 구조는 다음을 가능하게 한다.

• 사용자용 API 도메인 유지
• origin 서버 교체 대응
• IP 변경 대응
• CloudFront 우회 디버깅
• 나중에 ALB/ECS로 이전하기 쉬운 구조

하지만 origin 직접 접근이 보안 우회 경로가 될 수 있다는 점도 함께 봐야 한다.

도메인을 나누는 것은 편의가 아니라 책임 경계를 나누는 일이다.

함께 볼 GitHub 저장소

• aws-console-operations-notes