Route53, CloudFront, S3로 운영 콘솔 도메인 라우팅하기

AWS 실전 운영 시리즈 10/12

운영 콘솔을 AWS에 올릴 때 배포만큼 중요한 것이 도메인 라우팅이다.

React SPA를 S3에 올리고 CloudFront를 붙이면 화면은 열릴 수 있다. 하지만 실제 운영에서는 도메인이 여러 개 생긴다.

• 프론트엔드 도메인
• API 도메인
• CloudFront origin 도메인
• 디버깅용 직접 접근 도메인

도메인은 단순 주소가 아니다.

사용자가 어디로 들어오고, CloudFront가 어떤 origin을 보고, WAF가 어디에 붙고, API가 어떤 경로로 백엔드에 도달하는지 결정하는 인프라 설계 요소다.

문제 상황

운영 콘솔은 크게 두 종류의 트래픽을 가졌다.

첫째, React SPA 정적 파일을 가져오는 프론트엔드 트래픽이다.

사용자
-> console.example.com
-> CloudFront
-> S3

둘째, 대시보드나 분석 데이터를 조회하는 API 트래픽이다.

사용자
-> api.example.com
-> CloudFront
-> Origin API server
-> Database

둘 다 CloudFront를 거치지만 origin이 다르다.

프론트엔드 CloudFront는 S3를 origin으로 본다.

API CloudFront는 상주 API 서버를 origin으로 본다.

이 차이를 도메인 설계에 반영해야 한다.

기본 구성

일반화하면 다음 구조다.

Route53은 도메인을 CloudFront나 origin 서버로 연결한다.

CloudFront는 HTTPS 종단, 캐시, 보안 정책, origin 연결을 담당한다.

S3와 API 서버는 실제 콘텐츠와 데이터를 제공한다.

프론트엔드와 API가 모두 CloudFront를 지나더라도 같은 정책을 쓰는 것은 아니다. 정적 자산 CloudFront는 캐시가 중요하고, API CloudFront는 header 전달, WAF, origin 보호가 더 중요하다.

프론트엔드 도메인

프론트엔드 도메인은 사용자가 접속하는 주소다.

예를 들어 공개 글에서는 이렇게 표현할 수 있다.

console.example.com

이 도메인은 Route53 A alias record로 CloudFront distribution을 가리킨다.

console.example.com
-> CloudFront
-> S3 static assets

이 구조의 장점은 명확하다.

• S3 bucket을 직접 공개하지 않아도 된다.
• CloudFront에서 HTTPS를 처리할 수 있다.
• SPA 라우팅 fallback과 캐시 정책을 적용할 수 있다.
• WAF를 CloudFront에 붙일 수 있다.

프론트엔드 도메인은 사용자 경험과 보안 경계의 시작점이다.

API 도메인

API 도메인은 프론트엔드가 호출하는 주소다.

예를 들어:

api.example.com

API 도메인도 CloudFront를 거칠 수 있다.

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

API 앞에 CloudFront를 두면 다음 장점이 있다.

• HTTPS 종단을 CloudFront에서 처리할 수 있다.
• WAF를 붙일 수 있다.
• origin 서버를 직접 노출하지 않을 수 있다.
• 나중에 origin을 EC2에서 ALB나 ECS로 바꿔도 사용자 도메인을 유지할 수 있다.

다만 API는 정적 자산과 캐시 전략이 다르다.

API 응답을 무조건 캐시하면 안 된다.

origin 도메인

API CloudFront가 바라보는 origin에도 도메인이 필요할 수 있다.

예를 들어:

origin-api.example.com

이 도메인은 Route53에서 실제 API 서버의 IP나 load balancer를 가리킨다.

origin-api.example.com
-> EC2 public IP 또는 ALB

사용자는 api.example.com을 호출한다.

CloudFront는 내부적으로 origin-api.example.com을 호출한다.

이렇게 사용자용 도메인과 origin용 도메인을 나누면 운영이 쉬워진다.

왜 도메인을 나누는가

처음에는 API 서버 IP를 바로 쓰고 싶을 수 있다.

하지만 도메인을 나누면 장점이 있다.

도메인	역할
console.example.com	사용자용 프론트엔드
api.example.com	사용자용 API
origin-api.example.com	CloudFront가 바라보는 API origin

역할이 나뉘면 변경도 쉬워진다.

예를 들어 API 서버가 EC2에서 ALB로 바뀌어도 origin-api.example.com의 대상만 바꾸면 된다.

사용자는 여전히 api.example.com을 호출한다.

직접 접근 도메인의 장단점

origin 도메인은 디버깅에 유용하다.

CloudFront를 우회해서 API 서버가 직접 정상인지 확인할 수 있다.

예를 들어:

api.example.com          # CloudFront 경유
origin-api.example.com   # origin 직접 접근

장점:

• CloudFront 문제와 origin 문제를 구분할 수 있다.
• cache나 header 정책 영향을 제외하고 테스트할 수 있다.
• origin 서버 교체 시 검증이 쉽다.

하지만 단점도 있다.

origin 직접 접근이 열려 있으면 CloudFront/WAF를 우회할 수 있다.

따라서 운영 환경에서는 보안 그룹, 방화벽, origin custom header, allowlist 등을 고려해야 한다.

디버깅 편의와 보안 경계를 함께 봐야 한다.

Route53 문서화가 필요한 이유

도메인 라우팅은 한 번 설정하면 잊기 쉽다.

하지만 장애가 나면 가장 먼저 확인해야 할 수 있다.

운영 문서에는 다음을 남긴다.

• 도메인 이름
• 레코드 유형
• 라우팅 대상
• 용도
• CloudFront distribution
• origin
• 직접 접근 가능 여부

예시:

도메인	대상	용도
console.example.com	CloudFront	SPA 프론트엔드
api.example.com	CloudFront	API 프로덕션 경로
origin-api.example.com	API server	CloudFront origin

이 표가 있으면 장애 때 DNS부터 origin까지 빠르게 추적할 수 있다.

공개 글로 쓸 때

인프라 문서에는 실제 도메인과 distribution ID가 들어간다.

블로그 글에서는 모두 제거해야 한다.

실제 도메인 대신:

console.example.com
api.example.com
origin-api.example.com

실제 리소스 ID 대신:

CloudFront distribution
API Gateway
S3 bucket
API server

구조와 판단 기준만 남긴다.

정리

운영 콘솔의 도메인 라우팅은 단순 DNS 설정이 아니다.

프론트엔드, API, origin, 디버깅 경로, 보안 경계를 나누는 설계다.

좋은 도메인 설계는 다음을 분리한다.

• 사용자가 접속하는 프론트엔드 도메인
• 프론트엔드가 호출하는 API 도메인
• CloudFront가 바라보는 origin 도메인
• 운영자가 문제를 확인하는 디버깅 경로

Route53, CloudFront, S3, API 서버는 각각의 역할이 있다.

그 역할을 도메인 이름에 반영하면 운영 중 문제를 훨씬 쉽게 추적할 수 있다.

함께 볼 GitHub 저장소

• aws-console-operations-notes