Route 53 Alias vs CNAME 레코드: ALB 연결 시 무엇을 선택해야 하는가

ALB를 새로 프로비저닝하고 도메인을 연결하려는 순간, 대부분의 엔지니어는 CNAME 레코드를 먼저 떠올린다. 그런데 example.com 자체(zone apex)를 ALB에 연결하려는 순간 CNAME은 동작하지 않는다 — DNS 표준이 이를 금지하기 때문이다. Route 53 Alias 레코드는 이 문제를 해결하기 위해 설계된 AWS 전용 확장이며, 단순한 편의 기능이 아니라 운영 비용과 장애 내성에 직접 영향을 미친다.

TL;DR — Route 53 Alias vs CNAME 핵심 비교

항목CNAMERoute 53 Alias
Zone Apex 사용 가능 여부❌ 불가 (RFC 1912)✅ 가능
쿼리 과금쿼리당 과금AWS 리소스 대상 시 무료
DNS 응답 내용CNAME 체인 반환A/AAAA 레코드로 직접 응답
대상 리소스 상태 연동없음ALB 등 AWS 리소스와 연동
TTL 설정직접 설정Route 53이 자동 관리
사용 가능 대상임의 호스트명AWS 리소스 한정

DNS 동작 원리: CNAME 체인과 Alias 플래팅

CNAME 레코드는 한 호스트명을 다른 호스트명으로 위임한다. 클라이언트가 www.example.com을 조회하면 리졸버는 CNAME 대상인 ALB의 DNS 이름을 다시 조회해야 한다. 이 추가 조회가 CNAME 체인이다. Zone apex(example.com)에 CNAME을 설정할 수 없는 이유는 RFC 1912에 명시되어 있다 — zone apex에는 SOA, NS 레코드가 반드시 공존해야 하는데, CNAME은 같은 이름에 다른 레코드가 존재하는 것을 허용하지 않는다.

Route 53 Alias 레코드는 DNS 표준 레코드 타입이 아니다. Route 53 네임서버 내부에서 처리되는 확장으로, 쿼리 시점에 대상 리소스의 현재 IP 주소를 조회해 A 또는 AAAA 레코드로 직접 응답한다. 클라이언트 입장에서는 CNAME 체인 없이 IP 주소만 받는다. 이 동작을 'DNS 플래팅(flattening)'이라고 부른다.

sequenceDiagram participant C as 클라이언트 participant R as DNS 리졸버 participant R53 as Route 53 participant ALB as ALB DNS Note over C,ALB: CNAME 경로 (www.example.com) C->>R: www.example.com 조회 R->>R53: www.example.com? R53-->>R: CNAME: alb-xxx.us-east-1.elb.amazonaws.com R->>ALB: alb-xxx.us-east-1.elb.amazonaws.com? ALB-->>R: A: 203.0.113.10 R-->>C: 203.0.113.10 Note over C,ALB: Alias 경로 (example.com) C->>R: example.com 조회 R->>R53: example.com? Note right of R53: Route 53 내부에서
ALB IP 직접 조회 R53-->>R: A: 203.0.113.10 R-->>C: 203.0.113.10
  1. CNAME 경로 (위쪽): 클라이언트가 www.example.com을 조회하면 리졸버는 CNAME 응답을 받고, ALB DNS 이름을 다시 조회하는 두 번의 왕복이 발생한다.
  2. Alias 경로 (아래쪽): Route 53 네임서버가 내부적으로 ALB IP를 조회한 뒤 A 레코드로 직접 응답한다. 클라이언트 입장에서는 단일 왕복이다.
  3. Zone Apex: example.com은 CNAME 경로를 사용할 수 없다. Alias만 가능하다.

Route 53 Alias 레코드가 Zone Apex에서 중요한 이유

많은 팀이 처음에는 www.example.com만 운영하다가 나중에 naked 도메인(example.com)으로도 접근 가능하게 해달라는 요구를 받는다. 이때 CNAME으로는 해결이 안 된다. 일부 팀은 임시방편으로 example.com에 ALB IP를 A 레코드로 하드코딩하는데, ALB의 IP는 AWS가 관리하며 언제든 변경될 수 있어 이 방식은 운영 장애로 이어진다.

ALB에 고정 IP를 기대하는 것은 오토스케일링 그룹의 특정 인스턴스 ID에 의존하는 것과 같다. AWS가 언제든 교체할 수 있다.

Alias 레코드는 Route 53이 대상 리소스의 현재 DNS 이름을 추적하므로, ALB IP가 변경되어도 자동으로 반영된다. 이것이 zone apex에서 Alias가 유일하게 올바른 선택인 이유다.

Alias 레코드 설정: ALB 연결 실전 가이드

AWS CLI로 Route 53 Alias 레코드를 생성할 때는 AliasTarget 블록에 ALB의 호스팅 존 ID와 DNS 이름이 모두 필요하다. ALB의 호스팅 존 ID는 리전별로 고정된 값이며, ALB 자체의 호스팅 존 ID(describe-load-balancers로 확인)와 동일하다.

1단계: ALB 정보 확인

aws elbv2 describe-load-balancers \
  --names my-application-lb \
  --query 'LoadBalancers[0].{DNSName:DNSName,CanonicalHostedZoneId:CanonicalHostedZoneId}' \
  --output json

출력 예시:

{
    "DNSName": "my-application-lb-1234567890.us-east-1.elb.amazonaws.com",
    "CanonicalHostedZoneId": "Z35SXDOTRQ7X7K"
}

CanonicalHostedZoneId는 Alias 레코드의 HostedZoneId 필드에 사용된다. 이 값은 ALB가 위치한 리전의 ELB 호스팅 존 ID다.

2단계: Route 53 호스팅 존 ID 확인

aws route53 list-hosted-zones-by-name \
  --dns-name example.com \
  --query 'HostedZones[0].Id' \
  --output text

3단계: Alias 레코드 생성 (Zone Apex)

🔽 change-resource-record-sets JSON 전체 보기 
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1D633PJN98FT9 \
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "example.com",
          "Type": "A",
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "my-application-lb-1234567890.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'

EvaluateTargetHealth를 true로 설정하면 ALB의 헬스 체크 상태가 Route 53 라우팅 결정에 반영된다. 장애 조치(failover) 라우팅 정책과 함께 사용할 때 특히 중요하다.

4단계: www 서브도메인 Alias 레코드 (선택)

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1D633PJN98FT9 \
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "www.example.com",
          "Type": "A",
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "my-application-lb-1234567890.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'

서브도메인도 Alias를 사용할 수 있다. 외부 도메인을 대상으로 할 때는 CNAME을 써야 하지만, AWS 리소스가 대상이라면 Alias가 항상 우선이다.

실제 장애 패턴: 잘못된 가정이 만드는 문제

한 팀이 example.com에 ALB IP를 직접 A 레코드로 등록해두고 수개월간 운영했다. 어느 날 ALB 스케일링 이벤트 이후 IP가 변경되면서 zone apex로 들어오는 트래픽이 전부 끊겼다. www.example.com은 CNAME → ALB DNS 이름 체인으로 정상 동작했기 때문에 모니터링에서 즉시 잡히지 않았고, 사용자 신고로 발견됐다.

원인은 명확했다 — ALB는 IP 고정을 보장하지 않는다. 하지만 팀은 수개월간 IP가 바뀌지 않았기 때문에 안전하다고 가정했다. Alias 레코드로 전환한 뒤 동일한 문제는 재발하지 않았다.

이 패턴에서 주목할 점은 www와 naked 도메인의 모니터링이 분리되어 있지 않았다는 것이다. 두 엔드포인트를 독립적으로 헬스 체크하는 것이 운영상 올바른 접근이다.

graph TD A["example.com 요청"] --> B{"레코드 타입?"} B -->|"Alias 레코드"| C["Route 53이 ALB DNS 추적"] B -->|"하드코딩 A 레코드"| D["고정 IP 반환"] C --> E["ALB IP 변경 발생"] D --> E E --> F["Alias: 자동 반영 ✅"] E --> G["A 레코드: 구 IP 반환 ❌"] G --> H["트래픽 단절"] F --> I["정상 서비스 지속"] C --> J["EvaluateTargetHealth: true"] J --> K["ALB 헬스 체크 실패 시
Route 53 라우팅에서 제외"]
  1. 정상 상태: Alias 레코드는 ALB DNS 이름을 추적하므로 IP 변경이 자동 반영된다.
  2. 장애 상태: 하드코딩된 A 레코드는 ALB IP 변경 시 즉시 단절된다.
  3. EvaluateTargetHealth: ALB 헬스 체크 실패 시 Route 53이 해당 Alias 레코드를 응답에서 제외할 수 있다 (라우팅 정책에 따라 동작이 다름).

Alias 레코드 사용 시 알아야 할 동작 특성

Alias 레코드의 TTL은 사용자가 설정하지 않는다. Route 53이 대상 리소스의 TTL을 사용한다. ALB의 경우 Route 53은 60초 TTL로 응답한다. 이 값은 콘솔이나 CLI에서 변경할 수 없다.

Alias 레코드는 같은 호스팅 존 내의 다른 Route 53 레코드를 대상으로 지정할 수도 있다. 예를 들어 example.com Alias가 같은 존의 www.example.com A 레코드를 가리키도록 구성할 수 있다. 이 경우 두 레코드가 동일한 호스팅 존에 있어야 한다.

Alias 레코드가 지원하는 AWS 리소스 목록은 Route 53 공식 문서에 명시되어 있다. CloudFront 배포, S3 정적 웹사이트 엔드포인트, API Gateway, Elastic Beanstalk, VPC 인터페이스 엔드포인트 등이 포함된다. 외부 서비스나 온프레미스 엔드포인트는 Alias 대상이 될 수 없다.

언제 CNAME을 써야 하는가

Alias가 항상 우월한 것은 아니다. 대상이 AWS 리소스가 아닌 경우 — 예를 들어 서드파티 SaaS의 커스텀 도메인 연결, 외부 CDN, 또는 온프레미스 로드밸런서 — 에는 CNAME이 유일한 선택이다. Alias는 Route 53이 대상 리소스를 직접 조회할 수 있는 AWS 관리 리소스에만 동작한다.

또한 CNAME은 모든 DNS 제공자에서 표준으로 지원되므로, Route 53 외의 DNS 서비스를 사용하는 환경에서는 Alias 개념 자체가 존재하지 않는다. 일부 DNS 제공자가 'ALIAS' 또는 'ANAME'이라는 이름으로 유사한 기능을 제공하지만, 이는 각 제공자의 독자적인 구현이며 Route 53 Alias와 동일하지 않다.

graph TD START(["도메인 레코드 설정 시작"]) --> Q1{"Zone Apex인가?
(example.com)"} Q1 -->|"Yes"| ALIAS1["Route 53 Alias 레코드 필수"] Q1 -->|"No (서브도메인)"| Q2{"대상이
AWS 리소스인가?"} Q2 -->|"Yes (ALB, CF, S3 등)"| ALIAS2["Route 53 Alias 권장
(무료 쿼리, 자동 IP 추적)"] Q2 -->|"No (외부 호스트명)"| CNAME1["CNAME 레코드 사용"] ALIAS1 --> DONE1["설정 완료"] ALIAS2 --> DONE2["설정 완료"] CNAME1 --> DONE3["설정 완료"]
  1. Zone Apex 여부를 먼저 확인한다. Zone apex라면 Alias 외에 선택지가 없다.
  2. 대상이 AWS 리소스인지 확인한다. AWS 리소스라면 서브도메인이더라도 Alias를 권장한다.
  3. 외부 호스트명이 대상이라면 CNAME을 사용한다.

Route 53 Alias 레코드 설정 마무리 및 다음 단계

ALB를 도메인에 연결할 때 zone apex는 반드시 Alias 레코드를 사용해야 하고, 서브도메인도 대상이 AWS 리소스라면 Alias가 운영 비용과 안정성 면에서 유리하다. 하드코딩된 IP는 ALB 특성상 언제든 무효화될 수 있으므로 운영 환경에서는 사용하지 않는다.

다음 단계로 EvaluateTargetHealth와 Route 53 헬스 체크를 결합한 장애 조치(failover) 라우팅 구성, 그리고 Route 53 Resolver를 활용한 하이브리드 DNS 아키텍처를 검토하는 것을 권장한다.

핵심 용어 정리

용어설명
Zone ApexDNS 존의 루트 도메인 (example.com). SOA, NS 레코드가 반드시 존재하며 CNAME을 설정할 수 없다.
CNAME한 호스트명을 다른 호스트명으로 위임하는 표준 DNS 레코드 타입. Zone apex에 사용 불가.
Route 53 AliasRoute 53 전용 확장 레코드. 대상 AWS 리소스의 IP를 내부적으로 조회해 A/AAAA로 응답한다.
DNS 플래팅CNAME 체인을 제거하고 최종 IP 주소를 직접 반환하는 동작.
EvaluateTargetHealthAlias 레코드 설정 옵션. 대상 리소스의 헬스 체크 상태를 Route 53 라우팅 결정에 반영한다.
CanonicalHostedZoneIdALB가 속한 ELB 서비스의 리전별 호스팅 존 ID. Alias 레코드 생성 시 필수.

Related Posts

댓글

댓글 쓰기

이 블로그의 인기 게시물

EC2 SSH 연결 시간 초과: 확인해야 할 보안 그룹(Security Group) 규칙

EC2 SSH 연결 시간 초과(Connection timeout)는 새 인스턴스를 시작할 때 가장 흔히 발생하는 장애물 중 하나입니다. 해결 방법은 거의 항상 보안 그룹(Security Group)의 인바운드 규칙이 누락되었거나 잘못 구성된 경우입니다. 요약 — 한눈에 보는 진단 단계 단계 확인할 사항 일반적인 해결 방법 1 보안 그룹(Security Group) 인바운드 규칙 사용자 IP로부터의 SSH (TCP 22) 추가 2 서브넷 라우팅 테이블(Route table) 0.0.0.0/0이 인터넷 게이트웨이(IGW)로 라우팅되는지 확인 3 네트워크 ACL(Network ACL) 규칙 인바운드 TCP 22 및 임시(ephemeral) 반환 포트 허용 4 인스턴스 퍼블릭 IP / 탄력적 IP(Elastic IP) 퍼블릭 IP가 할당되었는지 확인 5 키 페어(Key pair) 및 SSH 사용자 이름 올바른 프라이빗 키 및 AMI 전용 사용자 이름 사용 SSH 연결이 거부(Refused)되지 않고 시간 초과(Timeout)되는 이유 연결 거부(Connection refused) 오류는 TCP 핸드셰이크가 호스트에 도달했으나 대기 중인 서비스가 없음을 의미합니다. 반면 연결 시간 초과(Connection timed out) 오류는 패킷이 도달하지 못했거나 응답이 돌아오지 못했음을 의미합니다. EC2에서 이러한 무응답은 거의 항상 OS 수준의 문제가 아닌 네트워크 계층에서의 차단 때문입니다. 인스턴스 수준의 상태 저장(stateful) 방화벽인 보안 그룹(Security Group)이 가장 먼저 의심해야 할 빈번한 원인입니다. blockquote> 비유: 보안 그룹을 인스턴스 문 앞의 경비원이라고 생각해 보세요. SSH(포트 22)가 게스트 목록에 없으면 패킷은 거부 알림도 받지 못한 채 밖에서...
자세한 내용 보기

EC2 SSH 연결 타임아웃 완전 해결 가이드: Security Group 인바운드 규칙부터 라우팅까지

새로 생성한 EC2 인스턴스에 SSH로 접속하려는데 'Connection timed out' 에러가 뜨는 상황은, AWS를 처음 쓰는 엔지니어뿐 아니라 경험 있는 운영자도 종종 마주친다. 문제는 단순히 Security Group 포트 하나가 아니라, Security Group → Network ACL → 라우팅 테이블 → 인스턴스 상태 까지 여러 레이어가 겹쳐 있다는 점이다. 이 글에서는 EC2 SSH 연결 타임아웃의 실제 원인을 레이어별로 진단하고, CLI 기반으로 빠르게 수정하는 방법을 다룬다. TL;DR — EC2 SSH 연결 타임아웃 빠른 진단표 진단 레이어 확인 항목 가장 흔한 원인 Security Group (인바운드) TCP 22 허용 여부, 소스 IP 포트 22 규칙 누락 또는 소스 0.0.0.0/0 미설정 Network ACL 인바운드 22 허용, 아웃바운드 임시 포트 허용 아웃바운드 임시 포트(1024-65535) 차단 라우팅 테이블 Internet Gateway 연결 여부 Public Subnet에 IGW 라우트 없음 퍼블릭 IP / EIP 인스턴스에 퍼블릭 IP 할당 여부 퍼블릭 IP 없이 직접 접속 시도 인스턴스 상태 Status Check 통과 여부 System/Instance reachability 실패 EC2 SSH 연결이 어떻게 동작하는가 SSH 연결 요청이 EC2에 도달하기까지 거치는 경로를 이해하지 않으면, 어느 레이어에서 막혔는지 추측에 의존하게 된다. 패킷은 인터넷 → IGW → 서브넷 → Network ACL → Security Group → 인스턴스 순서로 흐른다. 각 레이어는 독립적으로 동작하며, 하나라도 막히면 클라이언트 입장에서는 동일하게 타임아웃으로 보인다. graph LR Client["클라이언트"] ...
자세한 내용 보기

IAM User vs IAM Role 차이점 완전 정리 — EC2에서 S3 접근 시 무엇을 써야 하는가

IAM User와 IAM Role의 차이를 명확히 이해하지 못하면, EC2 인스턴스에서 S3에 접근할 때 자격증명을 하드코딩하거나 불필요하게 장기 키를 발급하는 실수를 반복하게 된다. 이 글은 두 개념의 구조적 차이와, EC2 인스턴스가 S3에 접근하는 실제 운영 시나리오 에서 어떤 선택이 올바른지를 명확히 설명한다. TL;DR — IAM User vs IAM Role 핵심 비교 EC2 인스턴스에서 S3에 접근할 때는 IAM Role(인스턴스 프로파일)을 사용하는 것이 AWS 공식 권장 방식이다. IAM User의 액세스 키를 인스턴스에 직접 저장하는 방식은 키 노출 위험이 있고, 자격증명 교체 비용이 높다. 항목 IAM User IAM Role 자격증명 유형 장기 액세스 키 (Access Key ID + Secret) 임시 보안 토큰 (STS 발급) 주체(Principal) 사람 또는 애플리케이션 AWS 서비스, 계정, 사람 등 자격증명 수명 명시적으로 삭제하기 전까지 유효 기본 1시간, 최대 12시간 (설정에 따라 다름) EC2 사용 권장 여부 ❌ 비권장 (키 하드코딩 위험) ✅ 권장 (인스턴스 프로파일) 자격증명 자동 교체 수동 교체 필요 STS가 자동 갱신 멀티 계정 접근 제한적 Cross-account Role Assumption 지원 IAM User와 IAM Role의 작동 원리 IAM User는 AWS 계정 내에 영구적으로 존재하는 자격증명 주체다. 콘솔 로그인용 패스워드와 API 호출용 액세스 키를 가지며, 이 키는 명시적으로 비활성화하거나 삭제하지 않는 한 계속 유효하다. 사람이 직접 AWS 콘솔이나 CLI를 사용하는 경우에 적합하다. IAM Role은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...
자세한 내용 보기