AWS Certificate Manager로 HTTPS 인증서 발급 완벽 가이드

AWS Certificate Manager를 사용하여 무료로 SSL/TLS 인증서를 발급받고, 로드 밸런서에 적용하여 안전한 HTTPS 웹 서비스를 구축하는 방법을 초급자도 쉽게 따라 할 수 있도록 단계별로 안내합니다.

1. HTTPS와 SSL/TLS 인증서의 필요성

김개발 씨가 드디어 자신의 첫 웹 서비스를 AWS에 배포했습니다. 기쁜 마음으로 친구들에게 URL을 공유했는데, 곧바로 친구에게서 문자가 왔습니다.

"야, 네 사이트 주소창에 '안전하지 않음'이라고 뜨는데 괜찮은 거야?"

HTTPS는 HTTP에 보안 계층을 추가한 프로토콜로, 사용자와 서버 간의 통신을 암호화합니다. 마치 우편물을 투명한 봉투가 아닌 불투명한 봉투에 넣어 보내는 것과 같습니다.

SSL/TLS 인증서는 이러한 암호화 통신을 가능하게 해주는 디지털 증명서로, 웹사이트의 신원을 보증합니다.

다음 코드를 살펴봅시다.

# HTTP vs HTTPS 비교
# HTTP - 암호화되지 않은 통신
http://example.com/login?password=1234
# 누구나 중간에서 비밀번호를 볼 수 있습니다!

# HTTPS - 암호화된 통신
https://example.com/login?password=encrypted_data
# 암호화되어 중간에서 가로채도 내용을 알 수 없습니다

# 브라우저에서 HTTPS 확인
// 현대 브라우저는 HTTPS가 아니면 경고를 표시합니다
if (window.location.protocol !== 'https:') {
  console.warn('이 사이트는 안전하지 않습니다!');
}

김개발 씨는 당황했습니다. 분명히 모든 기능이 잘 작동하는데 왜 브라우저가 경고를 표시하는 걸까요?

선배 개발자 박시니어 씨에게 급히 전화를 걸었습니다. "선배님, 제 사이트가 안전하지 않다고 뜨는데 제가 뭘 잘못한 건가요?" 박시니어 씨가 웃으며 대답했습니다.

"아, HTTPS 인증서를 아직 안 달았구나. 요즘은 필수야." HTTPS가 왜 필요할까요? 쉽게 비유하자면, HTTP는 엽서를 보내는 것과 같습니다.

누구나 내용을 볼 수 있습니다. 반면 HTTPS는 봉인된 편지를 보내는 것과 같습니다.

발신자와 수신자만 내용을 확인할 수 있습니다. 특히 로그인 정보나 개인정보를 다루는 웹사이트라면 HTTPS는 선택이 아닌 필수입니다.

HTTP로 통신하면 중간에서 누군가가 패킷을 가로채서 비밀번호를 훔쳐볼 수 있기 때문입니다. HTTPS가 없던 시절의 문제들 인터넷 초창기에는 대부분의 웹사이트가 HTTP를 사용했습니다.

그 결과 심각한 보안 사고들이 빈번하게 발생했습니다. 카페에서 공용 와이파이를 사용할 때 해커가 같은 네트워크에 있으면, HTTP 통신 내용을 모두 엿볼 수 있었습니다.

로그인 정보, 신용카드 번호, 개인 메시지까지 모두 노출되었습니다. 더 큰 문제는 중간자 공격이었습니다.

해커가 중간에서 데이터를 가로채서 변조할 수도 있었습니다. 사용자는 진짜 웹사이트에 접속했다고 믿지만, 실제로는 해커가 만든 가짜 사이트일 수도 있었습니다.

SSL/TLS 인증서의 등장 이런 문제를 해결하기 위해 SSL/TLS 인증서가 등장했습니다. SSL/TLS 인증서는 두 가지 중요한 역할을 합니다.

첫째, 통신 내용을 암호화하여 중간에서 가로채도 내용을 알 수 없게 만듭니다. 둘째, 웹사이트의 신원을 보증하여 가짜 사이트가 아님을 증명합니다.

마치 여권과 같은 역할입니다. 여권이 있으면 "이 사람이 진짜 본인입니다"라고 증명할 수 있는 것처럼, SSL/TLS 인증서가 있으면 "이 웹사이트가 진짜입니다"라고 증명할 수 있습니다.

인증서의 작동 원리 사용자가 HTTPS 웹사이트에 접속하면 어떤 일이 일어날까요? 먼저 브라우저가 서버에게 "인증서 좀 보여주세요"라고 요청합니다.

서버는 자신의 SSL/TLS 인증서를 브라우저에게 보냅니다. 브라우저는 이 인증서가 신뢰할 수 있는 기관에서 발급한 것인지 확인합니다.

인증서가 유효하다고 판단되면, 브라우저와 서버는 암호화 키를 교환합니다. 이제부터 두 사이의 모든 통신은 이 키로 암호화됩니다.

해커가 중간에서 가로채도 암호화된 데이터만 보이기 때문에 의미를 알 수 없습니다. 브라우저의 보안 표시 HTTPS가 적용된 웹사이트는 브라우저 주소창에 자물쇠 아이콘이 표시됩니다.

사용자들은 이 아이콘을 보고 "아, 이 사이트는 안전하구나"라고 인식합니다. 반대로 HTTPS가 없는 웹사이트는 "안전하지 않음"이라는 경고가 표시됩니다.

최신 브라우저들은 심지어 HTTP 사이트에 접속하려고 하면 큰 경고창을 띄우기도 합니다. 사용자들은 이런 경고를 보면 사이트를 신뢰하지 않고 떠나버립니다.

SEO와 비즈니스 측면 구글은 2014년부터 HTTPS를 검색 순위 결정 요소로 사용한다고 발표했습니다. 같은 품질의 콘텐츠라면 HTTPS 사이트가 HTTP 사이트보다 높은 순위를 받습니다.

또한 많은 브라우저가 HTTP 사이트에서는 위치 정보, 카메라 등의 기능을 제한합니다. 현대적인 웹 기능을 사용하려면 HTTPS는 필수입니다.

인증서 발급의 어려움 과거에는 SSL/TLS 인증서를 받기가 쉽지 않았습니다. 인증 기관에 돈을 내고 구매해야 했고, 매년 갱신 비용도 만만치 않았습니다.

작은 개인 프로젝트나 스타트업에게는 부담이었습니다. 설정 과정도 복잡했습니다.

인증서 파일을 받아서 서버에 설치하고, 웹 서버 설정을 수정하고, 방화벽 규칙을 조정하는 등 여러 단계를 거쳐야 했습니다. 초보 개발자에게는 높은 진입 장벽이었습니다.

AWS의 해결책 다행히 AWS는 **Certificate Manager(ACM)**라는 서비스를 제공합니다. ACM을 사용하면 무료로 SSL/TLS 인증서를 발급받을 수 있고, 자동 갱신까지 됩니다.

김개발 씨는 박시니어 씨의 조언을 듣고 곧바로 ACM으로 인증서를 발급받기로 마음먹었습니다. "무료라니, 정말 좋네요!" 이제 본격적으로 HTTPS를 적용해볼 시간입니다.

실전 팁

💡 - 모든 웹사이트는 HTTPS를 사용해야 합니다. 개인 프로젝트라도 예외는 없습니다.

HTTP에서 HTTPS로 마이그레이션할 때는 301 리다이렉트를 설정하여 검색 순위를 유지하세요.
인증서 만료일을 모니터링하세요. ACM은 자동 갱신되지만, 다른 서비스는 수동 갱신이 필요할 수 있습니다.

2. AWS Certificate Manager(ACM) 소개

김개발 씨가 AWS 콘솔에 접속하여 서비스 목록을 살펴보다가 "Certificate Manager"라는 메뉴를 발견했습니다. "인증서를 관리해주는 서비스인가?" 호기심이 생겨 클릭해보니 생각보다 훨씬 간단해 보였습니다.

**AWS Certificate Manager(ACM)**는 AWS에서 제공하는 무료 SSL/TLS 인증서 관리 서비스입니다. 클릭 몇 번으로 인증서를 발급받을 수 있고, 자동 갱신까지 지원하여 만료 걱정이 없습니다.

발급받은 인증서는 로드 밸런서, CloudFront, API Gateway 등 다양한 AWS 서비스에 쉽게 연결할 수 있습니다.

다음 코드를 살펴봅시다.

# AWS SDK를 사용한 ACM 인증서 요청
import boto3

# ACM 클라이언트 생성
acm_client = boto3.client('acm', region_name='us-east-1')

# 인증서 요청
response = acm_client.request_certificate(
    DomainName='example.com',
    # 와일드카드로 모든 서브도메인 포함
    SubjectAlternativeNames=['*.example.com'],
    # DNS 검증 방식 사용
    ValidationMethod='DNS',
    Tags=[
        {'Key': 'Name', 'Value': 'MyWebsiteCert'},
        {'Key': 'Environment', 'Value': 'Production'}
    ]
)

# 인증서 ARN 출력
certificate_arn = response['CertificateArn']
print(f"인증서가 요청되었습니다: {certificate_arn}")

김개발 씨는 ACM 콘솔을 보며 감탄했습니다. "이렇게 간단하다니!" 예전에 다른 프로젝트에서 SSL 인증서를 구매했을 때가 생각났습니다.

신용카드 정보를 입력하고, 도메인 소유권을 증명하는 복잡한 절차를 거치고, 결제까지 했는데도 인증서를 받기까지 하루가 걸렸습니다. ACM이란 무엇일까요? AWS Certificate Manager는 AWS 생태계 내에서 SSL/TLS 인증서를 쉽게 관리할 수 있도록 도와주는 서비스입니다.

마치 자동차 정비소와 같습니다. 직접 부품을 사서 조립하고 관리하는 대신, 전문가에게 맡기면 알아서 정비하고 점검까지 해주는 것과 같습니다.

ACM도 마찬가지로 인증서 발급, 설치, 갱신까지 모두 자동으로 처리해줍니다. ACM 이전의 세상 ACM이 등장하기 전에는 개발자들이 직접 인증서를 관리해야 했습니다.

먼저 인증 기관에서 인증서를 구매해야 했습니다. 저렴한 것은 연간 수만 원, 비싼 것은 수십만 원까지 했습니다.

소규모 프로젝트나 개인 개발자에게는 부담스러운 금액이었습니다. 인증서를 받으면 서버에 직접 설치해야 했습니다.

프라이빗 키 파일, 인증서 파일, 중간 인증서 파일 등을 올바른 위치에 배치하고, Nginx나 Apache 설정을 수정해야 했습니다. 실수하면 웹사이트가 접속 불가 상태가 되었습니다.

가장 골치 아픈 것은 만료 관리였습니다. 인증서는 보통 1년마다 갱신해야 합니다.

갱신을 깜빡하면 어느 날 갑자기 웹사이트에 "이 사이트는 안전하지 않습니다"라는 경고가 뜨면서 사용자들이 접속할 수 없게 됩니다. 새벽에 급하게 인증서를 갱신한 경험이 있는 개발자들이 많습니다.

ACM의 핵심 기능 ACM은 이 모든 문제를 한 번에 해결해줍니다. 첫째, 무료입니다.

AWS 서비스와 함께 사용하는 퍼블릭 인증서는 비용이 전혀 들지 않습니다. 소규모 프로젝트부터 대규모 엔터프라이즈까지 부담 없이 사용할 수 있습니다.

둘째, 자동 갱신됩니다. ACM이 만료일을 추적하여 자동으로 갱신해줍니다.

개발자는 신경 쓸 필요가 없습니다. 한번 설정하면 영구적으로 작동합니다.

셋째, AWS 서비스와 완벽한 통합입니다. 로드 밸런서, CloudFront, API Gateway 등에 클릭 몇 번으로 인증서를 연결할 수 있습니다.

복잡한 파일 복사나 설정 수정이 필요 없습니다. 퍼블릭 vs 프라이빗 인증서 ACM은 두 종류의 인증서를 제공합니다.

퍼블릭 인증서는 인터넷에 공개된 웹사이트용입니다. 무료이며, 일반 사용자들이 브라우저로 접속하는 사이트에 사용합니다.

우리가 주로 사용하는 것이 바로 이것입니다. 프라이빗 인증서는 내부 시스템용입니다.

회사 내부 인트라넷이나 마이크로서비스 간 통신에 사용합니다. 이것은 유료이며, Private CA를 구축해야 합니다.

리전별 인증서 관리 ACM은 리전별로 인증서를 관리합니다. 이 점이 중요합니다.

로드 밸런서나 API Gateway에 사용할 인증서는 해당 리소스와 같은 리전에서 발급받아야 합니다. 예를 들어 서울 리전(ap-northeast-2)의 로드 밸런서에는 서울 리전에서 발급받은 인증서를 사용해야 합니다.

단, CloudFront에 사용할 인증서는 예외입니다. CloudFront는 글로벌 서비스이므로 **반드시 버지니아 북부 리전(us-east-1)**에서 인증서를 발급받아야 합니다.

와일드카드 인증서 ACM은 와일드카드 인증서를 지원합니다. 이것은 매우 유용한 기능입니다.

예를 들어 *.example.com 형태로 인증서를 발급받으면, www.example.com, api.example.com, blog.example.com 등 모든 서브도메인에서 사용할 수 있습니다. 서브도메인마다 인증서를 따로 발급받을 필요가 없습니다.

제약사항 ACM 인증서에는 몇 가지 제약사항이 있습니다. 가장 중요한 것은 프라이빗 키를 내보낼 수 없다는 점입니다.

ACM 인증서는 AWS 서비스 내에서만 사용할 수 있습니다. EC2 인스턴스에 직접 설치하거나, AWS 외부 서버에서 사용할 수 없습니다.

EC2에서 직접 HTTPS를 사용하려면 Let's Encrypt 같은 다른 무료 인증서를 사용하거나, ACM 인증서를 로드 밸런서에 적용하고 로드 밸런서를 통해 트래픽을 받아야 합니다. 실제 사용 시나리오 김개발 씨의 경우를 생각해봅시다.

그는 EC2에서 웹 애플리케이션을 실행하고 있습니다. ACM에서 인증서를 발급받고, Application Load Balancer를 앞에 배치합니다.

로드 밸런서가 HTTPS 트래픽을 받아서 복호화하고, HTTP로 EC2에 전달합니다. 이런 구조를 SSL Termination이라고 합니다.

사용자는 안전한 HTTPS로 접속하고, 내부적으로는 간단한 HTTP로 통신하는 효율적인 구조입니다. ACM의 장점 정리 박시니어 씨가 김개발 씨에게 말했습니다.

"ACM은 정말 AWS의 숨은 보물이야. 무료에 자동 갱신까지 되니까 안 쓸 이유가 없지." 김개발 씨도 고개를 끄덕였습니다.

복잡한 인증서 관리에서 해방되어 비즈니스 로직 개발에만 집중할 수 있다니, 정말 좋은 서비스라는 생각이 들었습니다.

실전 팁

💡 - CloudFront용 인증서는 반드시 us-east-1 리전에서 발급받으세요.

와일드카드 인증서(*.example.com)를 사용하면 서브도메인 관리가 훨씬 편리합니다.
ACM 인증서는 AWS 서비스에서만 사용 가능하며, 프라이빗 키를 내보낼 수 없습니다.

3. ACM으로 무료 인증서 발급받기

김개발 씨가 드디어 ACM 콘솔에서 "인증서 요청" 버튼을 클릭했습니다. 화면에 나타난 폼을 보니 생각보다 간단했습니다.

"도메인 이름만 입력하면 되는 건가?"

ACM에서 인증서를 발급받는 과정은 매우 간단합니다. 도메인 이름을 입력하고, 검증 방법을 선택하고, 검증을 완료하면 끝입니다.

보통 몇 분 안에 인증서가 발급되며, 발급된 인증서는 즉시 AWS 서비스에 연결할 수 있습니다.

다음 코드를 살펴봅시다.

# AWS CLI를 사용한 인증서 요청
# 1. 인증서 요청
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names *.example.com \
  --validation-method DNS \
  --region ap-northeast-2 \
  --tags Key=Name,Value=MyWebsiteCert

# 2. 인증서 목록 조회
aws acm list-certificates --region ap-northeast-2

# 3. 특정 인증서의 상세 정보 조회 (검증 레코드 포함)
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-2:123456789012:certificate/abc123 \
  --region ap-northeast-2

# 4. 인증서 삭제 (필요한 경우)
aws acm delete-certificate \
  --certificate-arn arn:aws:acm:ap-northeast-2:123456789012:certificate/abc123 \
  --region ap-northeast-2

김개발 씨는 ACM 콘솔의 "인증서 요청" 버튼을 누르고 첫 번째 화면을 마주했습니다. "퍼블릭 인증서 요청"과 "프라이빗 인증서 요청" 두 가지 옵션이 보였습니다.

박시니어 씨가 말했던 것이 기억났습니다. "일반 웹사이트는 퍼블릭 인증서야." 김개발 씨는 퍼블릭 인증서를 선택했습니다.

1단계: 도메인 이름 입력 다음 화면에서 가장 중요한 필드가 나타났습니다. "도메인 이름"이라는 입력창입니다.

김개발 씨는 자신의 도메인 myawesomeapp.com을 입력했습니다. 그런데 문득 궁금증이 생겼습니다.

"서브도메인은 어떻게 하지?" 화면 아래에 "이 인증서에 다른 이름 추가" 버튼이 보였습니다. 클릭하니 또 다른 입력창이 나타났습니다.

여기에 *.myawesomeapp.com을 입력했습니다. 이렇게 하면 www.myawesomeapp.com, api.myawesomeapp.com 등 모든 서브도메인을 한 인증서로 커버할 수 있습니다.

와일드카드의 중요성 와일드카드(*.domain.com)를 사용하면 나중에 서브도메인을 추가할 때마다 새 인증서를 발급받지 않아도 됩니다. 예를 들어 처음에는 www.myawesomeapp.com만 사용하다가, 나중에 blog.myawesomeapp.com을 추가하고 싶을 수 있습니다.

와일드카드 인증서가 있다면 추가 작업 없이 바로 사용할 수 있습니다. 단, 와일드카드는 한 단계 서브도메인만 커버합니다.

*.myawesomeapp.com은 api.myawesomeapp.com은 포함하지만, v1.api.myawesomeapp.com은 포함하지 않습니다. 다단계 서브도메인이 필요하면 별도로 추가해야 합니다.

2단계: 검증 방법 선택 다음 단계에서 검증 방법을 선택해야 했습니다. "DNS 검증"과 "이메일 검증" 두 가지 옵션이 있었습니다.

박시니어 씨의 조언이 생각났습니다. "DNS 검증을 쓰는 게 좋아.

자동 갱신이 더 잘 작동하거든." 김개발 씨는 DNS 검증을 선택했습니다. 3단계: 태그 추가 (선택사항) 태그를 추가하는 화면이 나타났습니다.

이것은 선택사항이지만, 나중에 인증서를 관리하기 편하게 해줍니다. 김개발 씨는 Name: MyWebsiteCert, Environment: Production 태그를 추가했습니다.

여러 개의 인증서를 관리할 때 이런 태그가 있으면 쉽게 구분할 수 있습니다. 4단계: 검토 및 요청 마지막으로 입력한 내용을 검토하는 화면이 나타났습니다.

모든 것이 정확한지 확인한 후 "요청" 버튼을 클릭했습니다. 잠시 후 화면이 바뀌면서 "인증서가 요청되었습니다"라는 메시지가 나타났습니다.

그런데 상태가 "검증 보류 중"으로 표시되었습니다. 아직 끝이 아니었습니다.

도메인 소유권 검증 ACM이 인증서를 발급하기 전에 반드시 도메인 소유권을 검증해야 합니다. 이것은 보안상 매우 중요합니다.

만약 검증 없이 누구나 인증서를 발급받을 수 있다면, 해커가 다른 사람의 도메인으로 인증서를 받아서 피싱 사이트를 만들 수 있습니다. 검증 과정은 "당신이 정말 이 도메인의 소유자입니까?"를 확인하는 절차입니다.

DNS 검증 레코드 확인 김개발 씨는 요청한 인증서를 클릭해서 상세 정보를 확인했습니다. "도메인" 섹션을 펼치니 CNAME 레코드 정보가 표시되었습니다.

예를 들어 이런 형태입니다: - 이름: _abc123.myawesomeapp.com - 값: _xyz789.acm-validations.aws 이 CNAME 레코드를 자신의 DNS 서비스(Route 53, Cloudflare 등)에 추가하면 검증이 완료됩니다. Route 53에서 원클릭 검증 운이 좋게도 김개발 씨는 Route 53을 사용하고 있었습니다.

ACM 화면에 "Route 53에서 레코드 생성" 버튼이 보였습니다. 이 버튼을 클릭하니 자동으로 Route 53에 검증 레코드가 추가되었습니다.

정말 편리했습니다. 수동으로 복사-붙여넣기 할 필요가 없었습니다.

Route 53을 사용하지 않는다면, 표시된 CNAME 레코드를 복사해서 자신의 DNS 서비스에 수동으로 추가해야 합니다. 검증 대기 DNS 레코드를 추가한 후 몇 분을 기다렸습니다.

DNS 전파에는 시간이 걸립니다. 김개발 씨는 커피를 한 잔 타러 갔다가 돌아왔습니다.

화면을 새로고침하니 인증서 상태가 "발급됨"으로 바뀌어 있었습니다! 드디어 성공입니다.

발급 완료 인증서가 발급되면 ARN(Amazon Resource Name)이 부여됩니다. 이것은 인증서의 고유 식별자입니다.

예를 들어 arn:aws:acm:ap-northeast-2:123456789012:certificate/abc-def-123 같은 형태입니다. 나중에 로드 밸런서나 CloudFront에 인증서를 연결할 때 이 ARN을 사용합니다.

자동 갱신 확인 발급된 인증서의 상세 정보를 보면 "갱신 자격" 항목이 있습니다. "적격"으로 표시되어 있다면, ACM이 만료 전에 자동으로 갱신해줍니다.

이 자동 갱신이 작동하려면 DNS 검증 레코드가 계속 유지되어야 합니다. 실수로 DNS 레코드를 삭제하면 자동 갱신이 실패할 수 있으니 주의해야 합니다.

여러 도메인 추가 하나의 인증서에 여러 도메인을 추가할 수도 있습니다. 예를 들어 example.com, example.net, example.org를 모두 하나의 인증서로 관리할 수 있습니다.

단, 각 도메인마다 별도로 검증을 완료해야 합니다. 세 개의 도메인을 추가했다면 세 개의 DNS 검증 레코드를 모두 추가해야 인증서가 발급됩니다.

발급 시간 보통 DNS 검증이 완료되면 몇 분 안에 인증서가 발급됩니다. 하지만 때로는 30분 정도 걸릴 수도 있습니다.

만약 한 시간이 넘도록 "검증 보류 중"으로 남아있다면, DNS 레코드가 제대로 추가되었는지 확인해보세요. nslookup 명령어로 DNS 레코드를 조회해볼 수 있습니다.

성공의 기쁨 김개발 씨는 "발급됨" 상태를 보며 뿌듯함을 느꼈습니다. 생각보다 훨씬 쉬웠습니다.

과거에 다른 서비스에서 유료 인증서를 구매했을 때는 복잡한 절차를 거쳐야 했는데, ACM은 정말 사용자 친화적이었습니다. "이제 이 인증서를 로드 밸런서에 연결하면 되겠구나!" 다음 단계가 기대되었습니다.

실전 팁

💡 - Route 53 사용자는 "Route 53에서 레코드 생성" 버튼으로 원클릭 검증할 수 있습니다.

와일드카드(*.example.com)와 루트 도메인(example.com)을 함께 추가하면 모든 경우를 커버합니다.
DNS 검증 레코드는 절대 삭제하지 마세요. 자동 갱신에 필요합니다.

4. DNS 검증 vs 이메일 검증

김개발 씨가 박시니어 씨에게 물었습니다. "선배님, ACM에서 이메일 검증도 있던데 왜 DNS 검증을 추천하신 거예요?" 박시니어 씨가 의자를 돌리며 설명을 시작했습니다.

"좋은 질문이야. 각각 장단점이 있거든."

ACM은 DNS 검증과 이메일 검증 두 가지 방법으로 도메인 소유권을 확인합니다. DNS 검증은 DNS 레코드를 추가하는 방식으로, 자동 갱신이 가능하여 권장됩니다.

이메일 검증은 도메인 관리자 이메일로 승인 링크를 클릭하는 방식으로, DNS 접근이 없을 때 유용하지만 수동 갱신이 필요합니다.

다음 코드를 살펴봅시다.

# DNS 검증 레코드 추가 예제 (Route 53)
import boto3

route53 = boto3.client('route53')

# ACM에서 받은 검증 레코드 정보
validation_record = {
    'Name': '_abc123def.myawesomeapp.com',
    'Type': 'CNAME',
    'Value': '_xyz789.acm-validations.aws.'
}

# Route 53에 검증 레코드 추가
response = route53.change_resource_record_sets(
    HostedZoneId='Z1234567890ABC',  # 호스팅 영역 ID
    ChangeBatch={
        'Changes': [{
            'Action': 'CREATE',
            'ResourceRecordSet': {
                'Name': validation_record['Name'],
                'Type': validation_record['Type'],
                'TTL': 300,
                'ResourceRecords': [{'Value': validation_record['Value']}]
            }
        }]
    }
)

print("DNS 검증 레코드가 추가되었습니다!")

박시니어 씨가 화이트보드를 꺼내며 설명을 시작했습니다. "두 가지 검증 방법은 목적은 같지만 과정이 완전히 다르지.

각자 상황에 맞는 게 있어." DNS 검증의 작동 원리 DNS 검증은 DNS 레코드를 추가하여 도메인 소유권을 증명하는 방식입니다. 마치 집 주인임을 증명하기 위해 문패를 다는 것과 같습니다.

ACM이 "이 주소에 특정 문패를 달아보세요"라고 요청하면, 실제로 그 문패를 달아서 "제가 이 집 주인입니다"라고 증명하는 것입니다. ACM은 특정 형식의 CNAME 레코드를 요구합니다.

예를 들어 _abc123.example.com이라는 이름으로 _xyz789.acm-validations.aws를 가리키는 CNAME 레코드를 만들라고 합니다. 도메인 소유자만이 DNS 레코드를 추가할 수 있으므로, 이 레코드가 존재한다는 것은 도메인 소유자라는 증거가 됩니다.

DNS 검증의 장점 DNS 검증의 가장 큰 장점은 자동 갱신입니다. 한번 DNS 레코드를 추가해두면, ACM이 인증서 만료가 가까워질 때마다 자동으로 갱신합니다.

개발자는 아무것도 할 필요가 없습니다. DNS 레코드가 계속 유지되는 한, 인증서는 영구적으로 자동 갱신됩니다.

또한 프로그래밍 방식으로 자동화하기 쉽습니다. Infrastructure as Code(IaC) 도구인 Terraform이나 CloudFormation을 사용하면 인증서 발급부터 검증까지 모두 자동화할 수 있습니다.

DNS 검증의 단점 단점도 있습니다. DNS 관리 권한이 필요합니다.

만약 도메인을 외부 업체에서 관리하고 있고, DNS 레코드를 직접 수정할 수 없다면 DNS 검증을 사용하기 어렵습니다. 담당자에게 요청해서 레코드를 추가해달라고 해야 하는데, 이 과정이 복잡하거나 시간이 오래 걸릴 수 있습니다.

또한 DNS 전파 시간이 필요합니다. DNS 레코드를 추가한 후 전 세계 DNS 서버에 전파되기까지 몇 분에서 몇 시간이 걸릴 수 있습니다.

급하게 인증서가 필요한 경우 불편할 수 있습니다. 이메일 검증의 작동 원리 이메일 검증은 도메인 관리자 이메일로 승인 링크를 보내는 방식입니다.

ACM은 다음과 같은 특정 이메일 주소로 승인 메일을 보냅니다: - admin@example.com - administrator@example.com - hostmaster@example.com - postmaster@example.com - webmaster@example.com 또는 WHOIS 데이터베이스에 등록된 도메인 소유자 이메일 주소로도 발송됩니다. 이메일을 받으면 안에 있는 승인 링크를 클릭하기만 하면 검증이 완료됩니다.

마치 온라인 쇼핑몰에서 이메일 인증하는 것과 비슷합니다. 이메일 검증의 장점 이메일 검증의 장점은 DNS 접근이 필요 없다는 것입니다.

DNS 레코드를 수정할 권한이 없어도, 도메인 관리자 이메일만 받을 수 있으면 검증할 수 있습니다. 외부 업체가 DNS를 관리하는 경우나, 조직 내에서 DNS 팀과 개발 팀이 분리된 경우 유용합니다.

또한 절차가 직관적입니다. 이메일을 확인하고 링크를 클릭하는 것은 누구나 쉽게 할 수 있습니다.

기술적인 지식이 부족한 사람도 처리할 수 있습니다. 이메일 검증의 단점 가장 큰 단점은 자동 갱신이 안 된다는 점입니다.

인증서가 만료될 때마다 다시 이메일 검증을 해야 합니다. 매년 이메일을 확인하고 링크를 클릭해야 한다는 뜻입니다.

이것을 깜빡하면 인증서가 만료되어 웹사이트에 접속할 수 없게 됩니다. 또한 이메일 주소가 변경되거나 사용 불가능해지면 문제가 생깁니다.

예를 들어 admin@example.com으로 갱신 메일이 왔는데, 그 메일함을 더 이상 사용하지 않는다면 갱신할 방법이 없습니다. AWS의 권장사항 AWS는 공식 문서에서 DNS 검증을 강력히 권장합니다.

자동 갱신의 이점이 너무 크기 때문입니다. 한번 설정하면 영구적으로 작동하므로, 인증서 만료로 인한 서비스 중단 위험이 없습니다.

이메일 검증은 특별한 사유가 있을 때만 사용하는 것이 좋습니다. 예를 들어 DNS 접근이 절대 불가능하거나, 일회성 테스트용 인증서가 필요한 경우에만 사용합니다.

검증 방법 전환 한번 선택한 검증 방법은 바꿀 수 없습니다. 이메일 검증으로 발급받은 인증서를 나중에 DNS 검증으로 변경할 수 없습니다.

방법을 바꾸려면 기존 인증서를 삭제하고 새로 발급받아야 합니다. 따라서 처음부터 신중하게 선택하는 것이 중요합니다.

실제 사례 김개발 씨가 물었습니다. "그럼 대부분 DNS 검증을 쓰나요?" 박시니어 씨가 고개를 끄덕였습니다.

"그렇지. 우리 회사에서도 모든 인증서를 DNS 검증으로 발급받아.

Route 53을 쓰면 클릭 한 번이면 되니까 정말 편해." 실제로 현업에서는 대부분 DNS 검증을 사용합니다. 특히 Route 53을 사용하는 경우 ACM과의 통합이 완벽하여 완전 자동화가 가능합니다.

선택 가이드 박시니어 씨가 정리해주었습니다. "DNS 검증을 선택해: DNS 레코드를 추가할 수 있고, 자동 갱신을 원하는 경우 (대부분의 경우)" "이메일 검증을 선택해: DNS 접근이 불가능하고, 도메인 관리자 이메일만 받을 수 있는 경우 (특수한 경우)" 김개발 씨는 이제 명확하게 이해했습니다.

"DNS 검증이 훨씬 낫네요. 자동 갱신이 최고죠!"

실전 팁

💡 - 가능하면 항상 DNS 검증을 사용하세요. 자동 갱신의 편리함은 대체 불가능합니다.

Route 53 사용자는 ACM에서 원클릭으로 DNS 레코드를 추가할 수 있습니다.
이메일 검증은 갱신 알림을 놓치기 쉬우므로, 캘린더에 만료일을 등록해두세요.

5. 로드 밸런서에 HTTPS 리스너 추가

김개발 씨가 발급받은 ACM 인증서를 보며 생각했습니다. "이제 이걸 어디에 연결하지?" 현재 EC2 인스턴스가 직접 HTTP 트래픽을 받고 있었는데, HTTPS를 적용하려면 구조를 바꿔야 할 것 같았습니다.

**Application Load Balancer(ALB)**는 트래픽을 여러 EC2 인스턴스에 분산하는 로드 밸런서입니다. ALB에 HTTPS 리스너를 추가하고 ACM 인증서를 연결하면, 사용자는 HTTPS로 접속하고 내부적으로는 HTTP로 통신하는 SSL Termination 구조를 만들 수 있습니다.

이렇게 하면 EC2 인스턴스에서 복잡한 SSL 설정을 하지 않아도 됩니다.

다음 코드를 살펴봅시다.

# Boto3로 로드 밸런서에 HTTPS 리스너 추가
import boto3

elbv2 = boto3.client('elbv2', region_name='ap-northeast-2')

# 로드 밸런서 ARN (미리 생성된 ALB)
load_balancer_arn = 'arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:loadbalancer/app/my-alb/abc123'
# ACM 인증서 ARN
certificate_arn = 'arn:aws:acm:ap-northeast-2:123456789012:certificate/xyz789'
# 타겟 그룹 ARN (EC2 인스턴스들이 등록된 그룹)
target_group_arn = 'arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:targetgroup/my-targets/def456'

# HTTPS 리스너 생성 (포트 443)
response = elbv2.create_listener(
    LoadBalancerArn=load_balancer_arn,
    Protocol='HTTPS',
    Port=443,
    Certificates=[{'CertificateArn': certificate_arn}],
    DefaultActions=[{
        'Type': 'forward',
        'TargetGroupArn': target_group_arn
    }]
)

print(f"HTTPS 리스너가 생성되었습니다: {response['Listeners'][0]['ListenerArn']}")

김개발 씨는 박시니어 씨에게 다시 조언을 구했습니다. "선배님, 인증서는 발급받았는데 이제 어떻게 하죠?" 박시니어 씨가 웃으며 말했습니다.

"로드 밸런서를 쓰는 게 가장 깔끔해. EC2에 직접 설치하는 것보다 훨씬 관리가 편하거든." 왜 로드 밸런서인가? ACM 인증서는 AWS 서비스에서만 사용할 수 있습니다.

EC2 인스턴스에 직접 설치할 수 없습니다. 마치 특별한 열쇠가 특정 자물쇠에만 맞는 것과 같습니다.

ACM 인증서라는 열쇠는 로드 밸런서, CloudFront, API Gateway라는 자물쇠에만 맞습니다. 따라서 HTTPS를 적용하려면 로드 밸런서를 앞에 배치하고, 로드 밸런서가 HTTPS 트래픽을 받아서 EC2로 전달하는 구조를 만들어야 합니다.

Application Load Balancer 소개 **Application Load Balancer(ALB)**는 AWS의 7계층 로드 밸런서입니다. 기본적으로는 들어오는 트래픽을 여러 EC2 인스턴스에 분산하는 역할을 합니다.

하지만 그 이상의 기능도 있습니다. HTTPS 종료, 경로 기반 라우팅, 호스트 기반 라우팅 등 다양한 기능을 제공합니다.

비유하자면 ALB는 건물의 안내 데스크와 같습니다. 방문자(사용자)가 오면 적절한 사무실(EC2 인스턴스)로 안내해줍니다.

또한 보안 검색(HTTPS 복호화)도 처리합니다. SSL Termination 개념 SSL Termination은 HTTPS 암호화를 로드 밸런서에서 끝내는 것을 의미합니다.

사용자는 HTTPS로 로드 밸런서에 접속합니다. 로드 밸런서가 HTTPS를 복호화하여 HTTP로 변환한 후, EC2 인스턴스에 전달합니다.

EC2 인스턴스는 평범한 HTTP 트래픽을 받습니다. 이렇게 하면 EC2 인스턴스에서 복잡한 SSL 설정을 할 필요가 없습니다.

Nginx나 Apache에서 인증서를 설치하고 관리하는 번거로움이 사라집니다. 모든 SSL 관리는 로드 밸런서가 담당합니다.

로드 밸런서 생성 먼저 Application Load Balancer를 생성해야 합니다. EC2 콘솔에서 "로드 밸런서" 메뉴로 이동합니다.

"로드 밸런서 생성" 버튼을 클릭하고, "Application Load Balancer"를 선택합니다. 이름을 입력하고, 인터넷 연결(Internet-facing)을 선택합니다.

가용 영역을 최소 2개 선택해야 합니다. 예를 들어 ap-northeast-2a와 ap-northeast-2c를 선택합니다.

이렇게 하면 한 가용 영역에 장애가 발생해도 서비스가 계속 작동합니다. 보안 그룹 설정 로드 밸런서의 보안 그룹에서 포트 80(HTTP)과 포트 443(HTTPS)을 열어야 합니다.

인바운드 규칙에 다음을 추가합니다: - 포트 80, 소스 0.0.0.0/0 (모든 곳에서 HTTP 접속 허용) - 포트 443, 소스 0.0.0.0/0 (모든 곳에서 HTTPS 접속 허용) EC2 인스턴스의 보안 그룹은 수정해야 합니다. 이제 사용자가 직접 EC2에 접속하는 것이 아니라, 로드 밸런서를 통해서만 접속해야 하기 때문입니다.

EC2의 인바운드 규칙을 로드 밸런서의 보안 그룹으로만 제한합니다. 타겟 그룹 생성 타겟 그룹은 로드 밸런서가 트래픽을 전달할 EC2 인스턴스들의 그룹입니다.

"타겟 그룹 생성" 메뉴에서 타겟 유형을 "인스턴스"로 선택합니다. 프로토콜은 HTTP, 포트는 80을 입력합니다.

헬스 체크 경로를 설정합니다. 보통 / 또는 /health 같은 경로를 사용합니다.

다음 단계에서 실제 EC2 인스턴스를 선택하여 타겟 그룹에 등록합니다. 여러 개의 인스턴스를 등록하면 로드 밸런서가 자동으로 트래픽을 분산합니다.

HTTPS 리스너 추가 이제 핵심 단계입니다. 로드 밸런서에 HTTPS 리스너를 추가합니다.

로드 밸런서 상세 페이지에서 "리스너" 탭으로 이동합니다. 기본적으로 HTTP:80 리스너가 있을 것입니다.

"리스너 추가" 버튼을 클릭합니다. 프로토콜을 "HTTPS", 포트를 "443"으로 설정합니다.

그 아래 "기본 SSL 인증서" 섹션에서 "ACM에서" 옵션을 선택하고, 앞서 발급받은 인증서를 선택합니다. 기본 작업은 "타겟 그룹으로 전달"을 선택하고, 앞서 생성한 타겟 그룹을 선택합니다.

"추가" 버튼을 클릭하면 HTTPS 리스너가 생성됩니다. DNS 설정 변경 로드 밸런서의 DNS 이름을 확인합니다.

예를 들어 my-alb-123456789.ap-northeast-2.elb.amazonaws.com 같은 형태입니다. Route 53에서 자신의 도메인을 이 로드 밸런서로 연결합니다.

A 레코드 또는 ALIAS 레코드를 생성하여 myawesomeapp.com이 로드 밸런서를 가리키도록 설정합니다. Route 53을 사용한다면 ALIAS 레코드를 사용하는 것이 좋습니다.

ALIAS 레코드는 AWS 리소스를 가리킬 때 추가 비용이 없고, 로드 밸런서의 IP가 변경되어도 자동으로 추적됩니다. 테스트 DNS 전파가 완료되면 브라우저에서 https://myawesomeapp.com으로 접속해봅니다.

주소창에 자물쇠 아이콘이 표시되면 성공입니다! 인증서 정보를 클릭해보면 ACM에서 발급한 인증서 정보를 확인할 수 있습니다.

김개발 씨는 자신의 웹사이트가 HTTPS로 작동하는 것을 보며 감격했습니다. "드디어 '안전하지 않음' 경고가 사라졌어!" 다중 인증서 지원 하나의 HTTPS 리스너에 여러 개의 인증서를 추가할 수도 있습니다.

SNI(Server Name Indication) 기능을 사용하면, 하나의 로드 밸런서에서 여러 도메인을 서로 다른 인증서로 처리할 수 있습니다. 예를 들어 example.com과 another.com을 같은 로드 밸런서에서 서비스하되, 각각 다른 인증서를 사용할 수 있습니다.

리스너의 "인증서 관리" 메뉴에서 추가 인증서를 등록하면 됩니다. 비용 고려 ALB는 시간당 요금과 LCU(Load Balancer Capacity Unit) 요금이 부과됩니다.

소규모 트래픽이라면 월 20-30달러 정도입니다. 하지만 ACM 인증서 자체는 무료이고, SSL 관리의 편리함을 고려하면 충분히 가치가 있습니다.

수동으로 인증서를 관리하는 시간과 노력을 절약할 수 있습니다.

실전 팁

💡 - EC2 보안 그룹은 로드 밸런서에서만 접속 가능하도록 제한하여 보안을 강화하세요.

헬스 체크 경로를 적절히 설정하여 장애 발생 시 자동으로 트래픽을 건강한 인스턴스로 전환하세요.
CloudWatch를 통해 로드 밸런서의 메트릭을 모니터링하여 성능을 추적하세요.

6. HTTP에서 HTTPS로 리다이렉션 설정

김개발 씨가 HTTPS 적용을 완료하고 기뻐했지만, 곧 문제를 발견했습니다. 사용자가 http://myawesomeapp.com으로 접속하면 여전히 HTTP로 연결되었습니다.

"HTTPS를 강제하려면 어떻게 해야 하지?"

많은 사용자가 습관적으로 http://로 접속하거나, 북마크에 HTTP URL이 저장되어 있습니다. 따라서 HTTP로 들어오는 모든 요청을 HTTPS로 리다이렉트해야 합니다.

ALB에서는 리스너 규칙을 사용하여 HTTP 요청을 자동으로 HTTPS로 301 리다이렉트할 수 있습니다.

다음 코드를 살펴봅시다.

# Boto3로 HTTP → HTTPS 리다이렉트 규칙 생성
import boto3

elbv2 = boto3.client('elbv2', region_name='ap-northeast-2')

# HTTP 리스너 ARN (포트 80 리스너)
http_listener_arn = 'arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:listener/app/my-alb/abc123/def456'

# HTTP 리스너의 기본 작업을 HTTPS 리다이렉트로 변경
response = elbv2.modify_listener(
    ListenerArn=http_listener_arn,
    DefaultActions=[{
        'Type': 'redirect',
        'RedirectConfig': {
            'Protocol': 'HTTPS',
            'Port': '443',
            'StatusCode': 'HTTP_301',  # 영구 리다이렉트
            'Host': '#{host}',
            'Path': '/#{path}',
            'Query': '#{query}'
        }
    }]
)

print("HTTP → HTTPS 리다이렉트가 설정되었습니다!")
# 이제 http://example.com/page?id=123 → https://example.com/page?id=123

박시니어 씨가 김개발 씨의 화면을 보며 말했습니다. "아, HTTP 리다이렉트를 안 했구나.

이건 필수야." 김개발 씨가 고개를 갸우뚱했습니다. "HTTPS 리스너를 만들었는데 왜 리다이렉트가 필요한가요?" 왜 리다이렉트가 필요한가? HTTPS 리스너를 추가했다고 해서 사용자가 자동으로 HTTPS로 접속하는 것은 아닙니다.

사용자가 브라우저 주소창에 myawesomeapp.com만 입력하면, 대부분의 브라우저는 기본적으로 HTTP를 시도합니다. 또한 오래된 북마크, 검색 엔진 결과, 외부 링크 등에는 HTTP URL이 많습니다.

마치 건물에 새 정문을 만들었지만, 여전히 사람들이 옛날 후문으로 들어오는 것과 같습니다. 후문에 "정문으로 가세요"라는 안내판을 세워야 하는 것처럼, HTTP 요청에 "HTTPS로 가세요"라고 알려줘야 합니다.

리다이렉트의 작동 원리 HTTP 리다이렉트는 301 영구 이동 또는 302 임시 이동 상태 코드를 사용합니다. 사용자가 http://example.com/page로 접속하면, 서버가 "이 페이지는 https://example.com/page로 이동했습니다"라는 응답을 보냅니다.

브라우저는 자동으로 새 URL로 다시 요청을 보냅니다. 301은 영구 이동을 의미합니다.

검색 엔진은 이 코드를 보고 "아, 이 페이지는 영구적으로 HTTPS로 이동했구나"라고 인식하고 검색 결과를 HTTPS URL로 업데이트합니다. HTTP에서 HTTPS로 전환할 때는 반드시 301을 사용해야 SEO에 유리합니다.

ALB에서 리다이렉트 설정 Application Load Balancer는 리다이렉트 기능을 내장하고 있습니다. 별도의 코드 작성 없이 설정만으로 구현할 수 있습니다.

로드 밸런서 콘솔에서 HTTP:80 리스너를 선택합니다. 이미 리스너가 있다면 편집하고, 없다면 새로 만듭니다.

리스너의 "규칙 보기/편집"을 클릭합니다. 기본 규칙을 편집합니다.

기존 "타겟 그룹으로 전달" 작업을 삭제하고, "리다이렉트 대상" 작업을 추가합니다. 리다이렉트 설정 옵션 리다이렉트 설정에서 다음과 같이 입력합니다: - 프로토콜: HTTPS - 포트: 443 - 상태 코드: 301 - 영구 이동 - 호스트: #{host} (원래 호스트 유지) - 경로: /#{path} (원래 경로 유지) - 쿼리: #{query} (원래 쿼리 문자열 유지) #{host}, #{path}, #{query}는 ALB의 변수입니다.

이렇게 설정하면 원래 URL의 모든 부분을 그대로 유지하면서 프로토콜만 HTTPS로 바꿉니다. 예를 들어 http://example.com/products?category=books로 접속하면, https://example.com/products?category=books로 리다이렉트됩니다.

경로와 쿼리 문자열이 모두 보존됩니다. 301 vs 302 301 영구 이동은 "이 페이지는 영원히 새 위치로 이동했습니다"라는 의미입니다.

브라우저와 검색 엔진은 이 정보를 캐싱합니다. 다음번에 같은 URL로 접속하면 서버에 묻지 않고 바로 새 URL로 이동합니다.

302 임시 이동은 "이 페이지는 일시적으로 다른 곳에 있습니다"라는 의미입니다. 브라우저는 매번 서버에 확인합니다.

HTTP에서 HTTPS로의 전환은 영구적인 변경이므로 반드시 301을 사용해야 합니다. 302를 사용하면 SEO에 불리하고, 성능도 떨어집니다.

HSTS 헤더 추가 더 강력한 보안을 원한다면 HSTS(HTTP Strict Transport Security) 헤더를 추가할 수 있습니다. HSTS는 브라우저에게 "앞으로 이 사이트는 항상 HTTPS로만 접속하세요"라고 명령합니다.

한번 HSTS 헤더를 받은 브라우저는 해당 도메인에 대해 자동으로 HTTP를 HTTPS로 변환합니다. 서버에 리다이렉트를 요청하지도 않습니다.

ALB의 HTTPS 리스너에서 "규칙 편집"을 통해 HTTP 헤더를 삽입할 수 있습니다. Strict-Transport-Security: max-age=31536000; includeSubDomains 헤더를 추가합니다.

이것은 "1년 동안 이 도메인과 모든 서브도메인은 HTTPS로만 접속하세요"라는 의미입니다. 매우 강력한 보안 조치이지만, 한번 설정하면 HTTP로 돌아가기 어렵다는 점을 주의해야 합니다.

리다이렉트 테스트 설정을 완료한 후 반드시 테스트해야 합니다. 브라우저에서 http://myawesomeapp.com으로 접속해봅니다.

즉시 https://myawesomeapp.com으로 리다이렉트되어야 합니다. 개발자 도구의 Network 탭을 열면 301 응답을 확인할 수 있습니다.

하위 경로도 테스트합니다. http://myawesomeapp.com/products?id=123으로 접속하면 https://myawesomeapp.com/products?id=123으로 리다이렉트되는지 확인합니다.

경로와 쿼리 문자열이 정확히 보존되어야 합니다. curl 명령어로 확인 터미널에서 curl 명령어로도 확인할 수 있습니다: curl -I http://myawesomeapp.com 결과에서 HTTP/1.1 301 Moved Permanently와 Location: https://myawesomeapp.com/를 확인할 수 있어야 합니다.

SEO 고려사항 HTTP에서 HTTPS로 마이그레이션할 때는 검색 순위에 영향을 주지 않도록 주의해야 합니다. 301 리다이렉트를 사용하면 구글은 기존 HTTP 페이지의 검색 순위를 HTTPS 페이지로 이전합니다.

하지만 302를 사용하거나 리다이렉트를 안 하면 검색 순위가 떨어질 수 있습니다. Google Search Console에 HTTPS 버전의 사이트를 추가하고, 사이트맵을 제출하는 것도 좋은 방법입니다.

이렇게 하면 구글이 빠르게 HTTPS 페이지를 색인합니다. 혼합 콘텐츠 문제 HTTPS 페이지에서 HTTP 리소스를 로드하면 "혼합 콘텐츠" 경고가 발생합니다.

예를 들어 https://example.com 페이지에서 <img src="http://example.com/image.jpg">처럼 HTTP 이미지를 로드하면, 브라우저가 경고를 표시하거나 리소스를 차단합니다. HTML 코드에서 모든 리소스 URL을 HTTPS로 변경하거나, 프로토콜 상대 URL(//example.com/image.jpg)을 사용하여 자동으로 현재 프로토콜을 따르도록 해야 합니다.

완성 김개발 씨는 모든 설정을 완료하고 테스트해보았습니다. HTTP로 접속하면 자동으로 HTTPS로 리다이렉트되었고, 주소창에 자물쇠 아이콘이 빛났습니다.

"드디어 완벽한 HTTPS 사이트가 되었어!" 김개발 씨는 뿌듯함을 느꼈습니다. 박시니어 씨가 어깨를 두드리며 말했습니다.

"잘했어. 이제 사용자들이 안전하게 접속할 수 있겠네." 보안은 선택이 아닌 필수입니다.

HTTPS는 현대 웹 개발의 기본이며, ACM과 ALB를 사용하면 누구나 쉽게 구현할 수 있습니다.

실전 팁

💡 - 301 영구 리다이렉트를 사용하여 SEO를 보호하세요.

HSTS 헤더를 추가하여 브라우저가 자동으로 HTTPS를 사용하도록 강제할 수 있습니다.
HTML의 모든 리소스 URL을 HTTPS로 변경하여 혼합 콘텐츠 경고를 방지하세요.

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#ACM#HTTPS#SSL/TLS#LoadBalancer#AWS,ACM,Security

AWS Certificate Manager로 HTTPS 인증서 발급 완벽 가이드

# AWS Certificate Manager로 HTTPS 인증서 발급 완벽 가이드 AWS Certificate Manager를 사용하여 무료로 SSL/TLS 인증서를 발급받고, 로드 밸런서에 적용하여 안전한 HTTPS 웹 서비스를 구축하는 방법을 초급자도 쉽게 따라 할 수 있도록 단계별로 안내합니다. --- ## 목차 1. [HTTPS와 SSL/TLS 인증서의 필요성](#https와-ssl/tls-인증서의-필요성) 2. [AWS Certificate Manager(ACM) 소개](#aws-certificate-manager(acm)-소개) 3. [ACM으로 무료 인증서 발급받기](#acm으로-무료-인증서-발급받기) 4. [DNS 검증 vs 이메일 검증](#dns-검증-vs-이메일-검증) 5. [로드 밸런서에 HTTPS 리스너 추가](#로드-밸런서에-https-리스너-추가) 6. [HTTP에서 HTTPS로 리다이렉션 설정](#http에서-https로-리다이렉션-설정) --- ## 1. HTTPS와 SSL/TLS 인증서의 필요성 김개발 씨가 드디어 자신의 첫 웹 서비스를 AWS에 배포했습니다. 기쁜 마음으로 친구들에게 URL을 공유했는데, 곧바로 친구에게서 문자가 왔습니다. "야, 네 사이트 주소창에 '안전하지 않음'이라고 뜨는데 괜찮은 거야?" **HTTPS**는 HTTP에 **보안 계층**을 추가한 프로토콜로, 사용자와 서버 간의 통신을 **암호화**합니다. 마치 우편물을 투명한 봉투가 아닌 불투명한 봉투에 넣어 보내는 것과 같습니다. **SSL/TLS 인증서**는 이러한 암호화 통신을 가능하게 해주는 디지털 증명서로, 웹사이트의 신원을 보증합니다. 다음 코드를 살펴봅시다. ```javascript # HTTP vs HTTPS 비교 # HTTP - 암호화되지 않은 통신 http://example.com/login?password=1234 # 누구나 중간에서 비밀번호를 볼 수 있습니다! # HTTPS - 암호화된 통신 https://example.com/login?password=encrypted_data # 암호화되어 중간에서 가로채도 내용을 알 수 없습니다 # 브라우저에서 HTTPS 확인 // 현대 브라우저는 HTTPS가 아니면 경고를 표시합니다 if (window.location.protocol !== 'https:') { console.warn('이 사이트는 안전하지 않습니다!'); } ``` 김개발 씨는 당황했습니다. 분명히 모든 기능이 잘 작동하는데 왜 브라우저가 경고를 표시하는 걸까요? 선배 개발자 박시니어 씨에게 급히 전화를 걸었습니다. "선배님, 제 사이트가 안전하지 않다고 뜨는데 제가 뭘 잘못한 건가요?" 박시니어 씨가 웃으며 대답했습니다. "아, HTTPS 인증서를 아직 안 달았구나. 요즘은 필수야." **HTTPS가 왜 필요할까요?** 쉽게 비유하자면, HTTP는 엽서를 보내는 것과 같습니다. 누구나 내용을 볼 수 있습니다. 반면 HTTPS는 봉인된 편지를 보내는 것과 같습니다. 발신자와 수신자만 내용을 확인할 수 있습니다. 특히 로그인 정보나 개인정보를 다루는 웹사이트라면 HTTPS는 선택이 아닌 필수입니다. HTTP로 통신하면 중간에서 누군가가 패킷을 가로채서 비밀번호를 훔쳐볼 수 있기 때문입니다. **HTTPS가 없던 시절의 문제들** 인터넷 초창기에는 대부분의 웹사이트가 HTTP를 사용했습니다. 그 결과 심각한 보안 사고들이 빈번하게 발생했습니다. 카페에서 공용 와이파이를 사용할 때 해커가 같은 네트워크에 있으면, HTTP 통신 내용을 모두 엿볼 수 있었습니다. 로그인 정보, 신용카드 번호, 개인 메시지까지 모두 노출되었습니다. 더 큰 문제는 **중간자 공격**이었습니다. 해커가 중간에서 데이터를 가로채서 변조할 수도 있었습니다. 사용자는 진짜 웹사이트에 접속했다고 믿지만, 실제로는 해커가 만든 가짜 사이트일 수도 있었습니다. **SSL/TLS 인증서의 등장** 이런 문제를 해결하기 위해 **SSL/TLS 인증서**가 등장했습니다. SSL/TLS 인증서는 두 가지 중요한 역할을 합니다. 첫째, 통신 내용을 **암호화**하여 중간에서 가로채도 내용을 알 수 없게 만듭니다. 둘째, 웹사이트의 **신원을 보증**하여 가짜 사이트가 아님을 증명합니다. 마치 여권과 같은 역할입니다. 여권이 있으면 "이 사람이 진짜 본인입니다"라고 증명할 수 있는 것처럼, SSL/TLS 인증서가 있으면 "이 웹사이트가 진짜입니다"라고 증명할 수 있습니다. **인증서의 작동 원리** 사용자가 HTTPS 웹사이트에 접속하면 어떤 일이 일어날까요? 먼저 브라우저가 서버에게 "인증서 좀 보여주세요"라고 요청합니다. 서버는 자신의 SSL/TLS 인증서를 브라우저에게 보냅니다. 브라우저는 이 인증서가 신뢰할 수 있는 기관에서 발급한 것인지 확인합니다. 인증서가 유효하다고 판단되면, 브라우저와 서버는 **암호화 키를 교환**합니다. 이제부터 두 사이의 모든 통신은 이 키로 암호화됩니다. 해커가 중간에서 가로채도 암호화된 데이터만 보이기 때문에 의미를 알 수 없습니다. **브라우저의 보안 표시** HTTPS가 적용된 웹사이트는 브라우저 주소창에 **자물쇠 아이콘**이 표시됩니다. 사용자들은 이 아이콘을 보고 "아, 이 사이트는 안전하구나"라고 인식합니다. 반대로 HTTPS가 없는 웹사이트는 "안전하지 않음"이라는 경고가 표시됩니다. 최신 브라우저들은 심지어 HTTP 사이트에 접속하려고 하면 큰 경고창을 띄우기도 합니다. 사용자들은 이런 경고를 보면 사이트를 신뢰하지 않고 떠나버립니다. **SEO와 비즈니스 측면** 구글은 2014년부터 HTTPS를 검색 순위 결정 요소로 사용한다고 발표했습니다. 같은 품질의 콘텐츠라면 HTTPS 사이트가 HTTP 사이트보다 높은 순위를 받습니다. 또한 많은 브라우저가 HTTP 사이트에서는 위치 정보, 카메라 등의 기능을 제한합니다. 현대적인 웹 기능을 사용하려면 HTTPS는 필수입니다. **인증서 발급의 어려움** 과거에는 SSL/TLS 인증서를 받기가 쉽지 않았습니다. 인증 기관에 돈을 내고 구매해야 했고, 매년 갱신 비용도 만만치 않았습니다. 작은 개인 프로젝트나 스타트업에게는 부담이었습니다. 설정 과정도 복잡했습니다. 인증서 파일을 받아서 서버에 설치하고, 웹 서버 설정을 수정하고, 방화벽 규칙을 조정하는 등 여러 단계를 거쳐야 했습니다. 초보 개발자에게는 높은 진입 장벽이었습니다. **AWS의 해결책** 다행히 AWS는 **Certificate Manager(ACM)**라는 서비스를 제공합니다. ACM을 사용하면 무료로 SSL/TLS 인증서를 발급받을 수 있고, 자동 갱신까지 됩니다. 김개발 씨는 박시니어 씨의 조언을 듣고 곧바로 ACM으로 인증서를 발급받기로 마음먹었습니다. "무료라니, 정말 좋네요!" 이제 본격적으로 HTTPS를 적용해볼 시간입니다. **실전 팁** 💡 - 모든 웹사이트는 HTTPS를 사용해야 합니다. 개인 프로젝트라도 예외는 없습니다. - HTTP에서 HTTPS로 마이그레이션할 때는 301 리다이렉트를 설정하여 검색 순위를 유지하세요. - 인증서 만료일을 모니터링하세요. ACM은 자동 갱신되지만, 다른 서비스는 수동 갱신이 필요할 수 있습니다. --- ## 2. AWS Certificate Manager(ACM) 소개 김개발 씨가 AWS 콘솔에 접속하여 서비스 목록을 살펴보다가 "Certificate Manager"라는 메뉴를 발견했습니다. "인증서를 관리해주는 서비스인가?" 호기심이 생겨 클릭해보니 생각보다 훨씬 간단해 보였습니다. **AWS Certificate Manager(ACM)**는 AWS에서 제공하는 무료 SSL/TLS 인증서 관리 서비스입니다. 클릭 몇 번으로 인증서를 발급받을 수 있고, **자동 갱신**까지 지원하여 만료 걱정이 없습니다. 발급받은 인증서는 **로드 밸런서, CloudFront, API Gateway** 등 다양한 AWS 서비스에 쉽게 연결할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript # AWS SDK를 사용한 ACM 인증서 요청 import boto3 # ACM 클라이언트 생성 acm_client = boto3.client('acm', region_name='us-east-1') # 인증서 요청 response = acm_client.request_certificate( DomainName='example.com', # 와일드카드로 모든 서브도메인 포함 SubjectAlternativeNames=['*.example.com'], # DNS 검증 방식 사용 ValidationMethod='DNS', Tags=[ {'Key': 'Name', 'Value': 'MyWebsiteCert'}, {'Key': 'Environment', 'Value': 'Production'} ] ) # 인증서 ARN 출력 certificate_arn = response['CertificateArn'] print(f"인증서가 요청되었습니다: {certificate_arn}") ``` 김개발 씨는 ACM 콘솔을 보며 감탄했습니다. "이렇게 간단하다니!" 예전에 다른 프로젝트에서 SSL 인증서를 구매했을 때가 생각났습니다. 신용카드 정보를 입력하고, 도메인 소유권을 증명하는 복잡한 절차를 거치고, 결제까지 했는데도 인증서를 받기까지 하루가 걸렸습니다. **ACM이란 무엇일까요?** **AWS Certificate Manager**는 AWS 생태계 내에서 SSL/TLS 인증서를 쉽게 관리할 수 있도록 도와주는 서비스입니다. 마치 자동차 정비소와 같습니다. 직접 부품을 사서 조립하고 관리하는 대신, 전문가에게 맡기면 알아서 정비하고 점검까지 해주는 것과 같습니다. ACM도 마찬가지로 인증서 발급, 설치, 갱신까지 모두 자동으로 처리해줍니다. **ACM 이전의 세상** ACM이 등장하기 전에는 개발자들이 직접 인증서를 관리해야 했습니다. 먼저 인증 기관에서 인증서를 구매해야 했습니다. 저렴한 것은 연간 수만 원, 비싼 것은 수십만 원까지 했습니다. 소규모 프로젝트나 개인 개발자에게는 부담스러운 금액이었습니다. 인증서를 받으면 서버에 직접 설치해야 했습니다. 프라이빗 키 파일, 인증서 파일, 중간 인증서 파일 등을 올바른 위치에 배치하고, Nginx나 Apache 설정을 수정해야 했습니다. 실수하면 웹사이트가 접속 불가 상태가 되었습니다. 가장 골치 아픈 것은 **만료 관리**였습니다. 인증서는 보통 1년마다 갱신해야 합니다. 갱신을 깜빡하면 어느 날 갑자기 웹사이트에 "이 사이트는 안전하지 않습니다"라는 경고가 뜨면서 사용자들이 접속할 수 없게 됩니다. 새벽에 급하게 인증서를 갱신한 경험이 있는 개발자들이 많습니다. **ACM의 핵심 기능** ACM은 이 모든 문제를 한 번에 해결해줍니다. 첫째, **무료입니다**. AWS 서비스와 함께 사용하는 퍼블릭 인증서는 비용이 전혀 들지 않습니다. 소규모 프로젝트부터 대규모 엔터프라이즈까지 부담 없이 사용할 수 있습니다. 둘째, **자동 갱신**됩니다. ACM이 만료일을 추적하여 자동으로 갱신해줍니다. 개발자는 신경 쓸 필요가 없습니다. 한번 설정하면 영구적으로 작동합니다. 셋째, **AWS 서비스와 완벽한 통합**입니다. 로드 밸런서, CloudFront, API Gateway 등에 클릭 몇 번으로 인증서를 연결할 수 있습니다. 복잡한 파일 복사나 설정 수정이 필요 없습니다. **퍼블릭 vs 프라이빗 인증서** ACM은 두 종류의 인증서를 제공합니다. **퍼블릭 인증서**는 인터넷에 공개된 웹사이트용입니다. 무료이며, 일반 사용자들이 브라우저로 접속하는 사이트에 사용합니다. 우리가 주로 사용하는 것이 바로 이것입니다. **프라이빗 인증서**는 내부 시스템용입니다. 회사 내부 인트라넷이나 마이크로서비스 간 통신에 사용합니다. 이것은 유료이며, Private CA를 구축해야 합니다. **리전별 인증서 관리** ACM은 리전별로 인증서를 관리합니다. 이 점이 중요합니다. 로드 밸런서나 API Gateway에 사용할 인증서는 **해당 리소스와 같은 리전**에서 발급받아야 합니다. 예를 들어 서울 리전(ap-northeast-2)의 로드 밸런서에는 서울 리전에서 발급받은 인증서를 사용해야 합니다. 단, CloudFront에 사용할 인증서는 예외입니다. CloudFront는 글로벌 서비스이므로 **반드시 버지니아 북부 리전(us-east-1)**에서 인증서를 발급받아야 합니다. **와일드카드 인증서** ACM은 와일드카드 인증서를 지원합니다. 이것은 매우 유용한 기능입니다. 예를 들어 `*.example.com` 형태로 인증서를 발급받으면, `www.example.com`, `api.example.com`, `blog.example.com` 등 모든 서브도메인에서 사용할 수 있습니다. 서브도메인마다 인증서를 따로 발급받을 필요가 없습니다. **제약사항** ACM 인증서에는 몇 가지 제약사항이 있습니다. 가장 중요한 것은 **프라이빗 키를 내보낼 수 없다**는 점입니다. ACM 인증서는 AWS 서비스 내에서만 사용할 수 있습니다. EC2 인스턴스에 직접 설치하거나, AWS 외부 서버에서 사용할 수 없습니다. EC2에서 직접 HTTPS를 사용하려면 Let's Encrypt 같은 다른 무료 인증서를 사용하거나, ACM 인증서를 로드 밸런서에 적용하고 로드 밸런서를 통해 트래픽을 받아야 합니다. **실제 사용 시나리오** 김개발 씨의 경우를 생각해봅시다. 그는 EC2에서 웹 애플리케이션을 실행하고 있습니다. ACM에서 인증서를 발급받고, Application Load Balancer를 앞에 배치합니다. 로드 밸런서가 HTTPS 트래픽을 받아서 복호화하고, HTTP로 EC2에 전달합니다. 이런 구조를 **SSL Termination**이라고 합니다. 사용자는 안전한 HTTPS로 접속하고, 내부적으로는 간단한 HTTP로 통신하는 효율적인 구조입니다. **ACM의 장점 정리** 박시니어 씨가 김개발 씨에게 말했습니다. "ACM은 정말 AWS의 숨은 보물이야. 무료에 자동 갱신까지 되니까 안 쓸 이유가 없지." 김개발 씨도 고개를 끄덕였습니다. 복잡한 인증서 관리에서 해방되어 비즈니스 로직 개발에만 집중할 수 있다니, 정말 좋은 서비스라는 생각이 들었습니다. **실전 팁** 💡 - CloudFront용 인증서는 반드시 us-east-1 리전에서 발급받으세요. - 와일드카드 인증서(*.example.com)를 사용하면 서브도메인 관리가 훨씬 편리합니다. - ACM 인증서는 AWS 서비스에서만 사용 가능하며, 프라이빗 키를 내보낼 수 없습니다. --- ## 3. ACM으로 무료 인증서 발급받기 김개발 씨가 드디어 ACM 콘솔에서 "인증서 요청" 버튼을 클릭했습니다. 화면에 나타난 폼을 보니 생각보다 간단했습니다. "도메인 이름만 입력하면 되는 건가?" ACM에서 인증서를 발급받는 과정은 매우 간단합니다. **도메인 이름을 입력**하고, **검증 방법을 선택**하고, **검증을 완료**하면 끝입니다. 보통 몇 분 안에 인증서가 발급되며, 발급된 인증서는 즉시 AWS 서비스에 연결할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript # AWS CLI를 사용한 인증서 요청 # 1. 인증서 요청 aws acm request-certificate \ --domain-name example.com \ --subject-alternative-names *.example.com \ --validation-method DNS \ --region ap-northeast-2 \ --tags Key=Name,Value=MyWebsiteCert # 2. 인증서 목록 조회 aws acm list-certificates --region ap-northeast-2 # 3. 특정 인증서의 상세 정보 조회 (검증 레코드 포함) aws acm describe-certificate \ --certificate-arn arn:aws:acm:ap-northeast-2:123456789012:certificate/abc123 \ --region ap-northeast-2 # 4. 인증서 삭제 (필요한 경우) aws acm delete-certificate \ --certificate-arn arn:aws:acm:ap-northeast-2:123456789012:certificate/abc123 \ --region ap-northeast-2 ``` 김개발 씨는 ACM 콘솔의 "인증서 요청" 버튼을 누르고 첫 번째 화면을 마주했습니다. "퍼블릭 인증서 요청"과 "프라이빗 인증서 요청" 두 가지 옵션이 보였습니다. 박시니어 씨가 말했던 것이 기억났습니다. "일반 웹사이트는 퍼블릭 인증서야." 김개발 씨는 퍼블릭 인증서를 선택했습니다. **1단계: 도메인 이름 입력** 다음 화면에서 가장 중요한 필드가 나타났습니다. "도메인 이름"이라는 입력창입니다. 김개발 씨는 자신의 도메인 `myawesomeapp.com`을 입력했습니다. 그런데 문득 궁금증이 생겼습니다. "서브도메인은 어떻게 하지?" 화면 아래에 "이 인증서에 다른 이름 추가" 버튼이 보였습니다. 클릭하니 또 다른 입력창이 나타났습니다. 여기에 `*.myawesomeapp.com`을 입력했습니다. 이렇게 하면 `www.myawesomeapp.com`, `api.myawesomeapp.com` 등 모든 서브도메인을 한 인증서로 커버할 수 있습니다. **와일드카드의 중요성** 와일드카드(`*.domain.com`)를 사용하면 나중에 서브도메인을 추가할 때마다 새 인증서를 발급받지 않아도 됩니다. 예를 들어 처음에는 `www.myawesomeapp.com`만 사용하다가, 나중에 `blog.myawesomeapp.com`을 추가하고 싶을 수 있습니다. 와일드카드 인증서가 있다면 추가 작업 없이 바로 사용할 수 있습니다. 단, 와일드카드는 한 단계 서브도메인만 커버합니다. `*.myawesomeapp.com`은 `api.myawesomeapp.com`은 포함하지만, `v1.api.myawesomeapp.com`은 포함하지 않습니다. 다단계 서브도메인이 필요하면 별도로 추가해야 합니다. **2단계: 검증 방법 선택** 다음 단계에서 검증 방법을 선택해야 했습니다. "DNS 검증"과 "이메일 검증" 두 가지 옵션이 있었습니다. 박시니어 씨의 조언이 생각났습니다. "DNS 검증을 쓰는 게 좋아. 자동 갱신이 더 잘 작동하거든." 김개발 씨는 DNS 검증을 선택했습니다. **3단계: 태그 추가 (선택사항)** 태그를 추가하는 화면이 나타났습니다. 이것은 선택사항이지만, 나중에 인증서를 관리하기 편하게 해줍니다. 김개발 씨는 `Name: MyWebsiteCert`, `Environment: Production` 태그를 추가했습니다. 여러 개의 인증서를 관리할 때 이런 태그가 있으면 쉽게 구분할 수 있습니다. **4단계: 검토 및 요청** 마지막으로 입력한 내용을 검토하는 화면이 나타났습니다. 모든 것이 정확한지 확인한 후 "요청" 버튼을 클릭했습니다. 잠시 후 화면이 바뀌면서 "인증서가 요청되었습니다"라는 메시지가 나타났습니다. 그런데 상태가 "검증 보류 중"으로 표시되었습니다. 아직 끝이 아니었습니다. **도메인 소유권 검증** ACM이 인증서를 발급하기 전에 반드시 **도메인 소유권을 검증**해야 합니다. 이것은 보안상 매우 중요합니다. 만약 검증 없이 누구나 인증서를 발급받을 수 있다면, 해커가 다른 사람의 도메인으로 인증서를 받아서 피싱 사이트를 만들 수 있습니다. 검증 과정은 "당신이 정말 이 도메인의 소유자입니까?"를 확인하는 절차입니다. **DNS 검증 레코드 확인** 김개발 씨는 요청한 인증서를 클릭해서 상세 정보를 확인했습니다. "도메인" 섹션을 펼치니 CNAME 레코드 정보가 표시되었습니다. 예를 들어 이런 형태입니다: - 이름: `_abc123.myawesomeapp.com` - 값: `_xyz789.acm-validations.aws` 이 CNAME 레코드를 자신의 DNS 서비스(Route 53, Cloudflare 등)에 추가하면 검증이 완료됩니다. **Route 53에서 원클릭 검증** 운이 좋게도 김개발 씨는 Route 53을 사용하고 있었습니다. ACM 화면에 "Route 53에서 레코드 생성" 버튼이 보였습니다. 이 버튼을 클릭하니 자동으로 Route 53에 검증 레코드가 추가되었습니다. 정말 편리했습니다. 수동으로 복사-붙여넣기 할 필요가 없었습니다. Route 53을 사용하지 않는다면, 표시된 CNAME 레코드를 복사해서 자신의 DNS 서비스에 수동으로 추가해야 합니다. **검증 대기** DNS 레코드를 추가한 후 몇 분을 기다렸습니다. DNS 전파에는 시간이 걸립니다. 김개발 씨는 커피를 한 잔 타러 갔다가 돌아왔습니다. 화면을 새로고침하니 인증서 상태가 "발급됨"으로 바뀌어 있었습니다! 드디어 성공입니다. **발급 완료** 인증서가 발급되면 ARN(Amazon Resource Name)이 부여됩니다. 이것은 인증서의 고유 식별자입니다. 예를 들어 `arn:aws:acm:ap-northeast-2:123456789012:certificate/abc-def-123` 같은 형태입니다. 나중에 로드 밸런서나 CloudFront에 인증서를 연결할 때 이 ARN을 사용합니다. **자동 갱신 확인** 발급된 인증서의 상세 정보를 보면 "갱신 자격" 항목이 있습니다. "적격"으로 표시되어 있다면, ACM이 만료 전에 자동으로 갱신해줍니다. 이 자동 갱신이 작동하려면 DNS 검증 레코드가 계속 유지되어야 합니다. 실수로 DNS 레코드를 삭제하면 자동 갱신이 실패할 수 있으니 주의해야 합니다. **여러 도메인 추가** 하나의 인증서에 여러 도메인을 추가할 수도 있습니다. 예를 들어 `example.com`, `example.net`, `example.org`를 모두 하나의 인증서로 관리할 수 있습니다. 단, 각 도메인마다 별도로 검증을 완료해야 합니다. 세 개의 도메인을 추가했다면 세 개의 DNS 검증 레코드를 모두 추가해야 인증서가 발급됩니다. **발급 시간** 보통 DNS 검증이 완료되면 몇 분 안에 인증서가 발급됩니다. 하지만 때로는 30분 정도 걸릴 수도 있습니다. 만약 한 시간이 넘도록 "검증 보류 중"으로 남아있다면, DNS 레코드가 제대로 추가되었는지 확인해보세요. `nslookup` 명령어로 DNS 레코드를 조회해볼 수 있습니다. **성공의 기쁨** 김개발 씨는 "발급됨" 상태를 보며 뿌듯함을 느꼈습니다. 생각보다 훨씬 쉬웠습니다. 과거에 다른 서비스에서 유료 인증서를 구매했을 때는 복잡한 절차를 거쳐야 했는데, ACM은 정말 사용자 친화적이었습니다. "이제 이 인증서를 로드 밸런서에 연결하면 되겠구나!" 다음 단계가 기대되었습니다. **실전 팁** 💡 - Route 53 사용자는 "Route 53에서 레코드 생성" 버튼으로 원클릭 검증할 수 있습니다. - 와일드카드(*.example.com)와 루트 도메인(example.com)을 함께 추가하면 모든 경우를 커버합니다. - DNS 검증 레코드는 절대 삭제하지 마세요. 자동 갱신에 필요합니다. --- ## 4. DNS 검증 vs 이메일 검증 김개발 씨가 박시니어 씨에게 물었습니다. "선배님, ACM에서 이메일 검증도 있던데 왜 DNS 검증을 추천하신 거예요?" 박시니어 씨가 의자를 돌리며 설명을 시작했습니다. "좋은 질문이야. 각각 장단점이 있거든." ACM은 **DNS 검증**과 **이메일 검증** 두 가지 방법으로 도메인 소유권을 확인합니다. **DNS 검증**은 DNS 레코드를 추가하는 방식으로, 자동 갱신이 가능하여 권장됩니다. **이메일 검증**은 도메인 관리자 이메일로 승인 링크를 클릭하는 방식으로, DNS 접근이 없을 때 유용하지만 수동 갱신이 필요합니다. 다음 코드를 살펴봅시다. ```javascript # DNS 검증 레코드 추가 예제 (Route 53) import boto3 route53 = boto3.client('route53') # ACM에서 받은 검증 레코드 정보 validation_record = { 'Name': '_abc123def.myawesomeapp.com', 'Type': 'CNAME', 'Value': '_xyz789.acm-validations.aws.' } # Route 53에 검증 레코드 추가 response = route53.change_resource_record_sets( HostedZoneId='Z1234567890ABC', # 호스팅 영역 ID ChangeBatch={ 'Changes': [{ 'Action': 'CREATE', 'ResourceRecordSet': { 'Name': validation_record['Name'], 'Type': validation_record['Type'], 'TTL': 300, 'ResourceRecords': [{'Value': validation_record['Value']}] } }] } ) print("DNS 검증 레코드가 추가되었습니다!") ``` 박시니어 씨가 화이트보드를 꺼내며 설명을 시작했습니다. "두 가지 검증 방법은 목적은 같지만 과정이 완전히 다르지. 각자 상황에 맞는 게 있어." **DNS 검증의 작동 원리** DNS 검증은 **DNS 레코드를 추가**하여 도메인 소유권을 증명하는 방식입니다. 마치 집 주인임을 증명하기 위해 문패를 다는 것과 같습니다. ACM이 "이 주소에 특정 문패를 달아보세요"라고 요청하면, 실제로 그 문패를 달아서 "제가 이 집 주인입니다"라고 증명하는 것입니다. ACM은 특정 형식의 CNAME 레코드를 요구합니다. 예를 들어 `_abc123.example.com`이라는 이름으로 `_xyz789.acm-validations.aws`를 가리키는 CNAME 레코드를 만들라고 합니다. 도메인 소유자만이 DNS 레코드를 추가할 수 있으므로, 이 레코드가 존재한다는 것은 도메인 소유자라는 증거가 됩니다. **DNS 검증의 장점** DNS 검증의 가장 큰 장점은 **자동 갱신**입니다. 한번 DNS 레코드를 추가해두면, ACM이 인증서 만료가 가까워질 때마다 자동으로 갱신합니다. 개발자는 아무것도 할 필요가 없습니다. DNS 레코드가 계속 유지되는 한, 인증서는 영구적으로 자동 갱신됩니다. 또한 **프로그래밍 방식으로 자동화**하기 쉽습니다. Infrastructure as Code(IaC) 도구인 Terraform이나 CloudFormation을 사용하면 인증서 발급부터 검증까지 모두 자동화할 수 있습니다. **DNS 검증의 단점** 단점도 있습니다. **DNS 관리 권한**이 필요합니다. 만약 도메인을 외부 업체에서 관리하고 있고, DNS 레코드를 직접 수정할 수 없다면 DNS 검증을 사용하기 어렵습니다. 담당자에게 요청해서 레코드를 추가해달라고 해야 하는데, 이 과정이 복잡하거나 시간이 오래 걸릴 수 있습니다. 또한 DNS 전파 시간이 필요합니다. DNS 레코드를 추가한 후 전 세계 DNS 서버에 전파되기까지 몇 분에서 몇 시간이 걸릴 수 있습니다. 급하게 인증서가 필요한 경우 불편할 수 있습니다. **이메일 검증의 작동 원리** 이메일 검증은 **도메인 관리자 이메일로 승인 링크**를 보내는 방식입니다. ACM은 다음과 같은 특정 이메일 주소로 승인 메일을 보냅니다: - `admin@example.com` - `administrator@example.com` - `hostmaster@example.com` - `postmaster@example.com` - `webmaster@example.com` 또는 WHOIS 데이터베이스에 등록된 도메인 소유자 이메일 주소로도 발송됩니다. 이메일을 받으면 안에 있는 승인 링크를 클릭하기만 하면 검증이 완료됩니다. 마치 온라인 쇼핑몰에서 이메일 인증하는 것과 비슷합니다. **이메일 검증의 장점** 이메일 검증의 장점은 **DNS 접근이 필요 없다**는 것입니다. DNS 레코드를 수정할 권한이 없어도, 도메인 관리자 이메일만 받을 수 있으면 검증할 수 있습니다. 외부 업체가 DNS를 관리하는 경우나, 조직 내에서 DNS 팀과 개발 팀이 분리된 경우 유용합니다. 또한 절차가 직관적입니다. 이메일을 확인하고 링크를 클릭하는 것은 누구나 쉽게 할 수 있습니다. 기술적인 지식이 부족한 사람도 처리할 수 있습니다. **이메일 검증의 단점** 가장 큰 단점은 **자동 갱신이 안 된다**는 점입니다. 인증서가 만료될 때마다 다시 이메일 검증을 해야 합니다. 매년 이메일을 확인하고 링크를 클릭해야 한다는 뜻입니다. 이것을 깜빡하면 인증서가 만료되어 웹사이트에 접속할 수 없게 됩니다. 또한 이메일 주소가 변경되거나 사용 불가능해지면 문제가 생깁니다. 예를 들어 `admin@example.com`으로 갱신 메일이 왔는데, 그 메일함을 더 이상 사용하지 않는다면 갱신할 방법이 없습니다. **AWS의 권장사항** AWS는 공식 문서에서 **DNS 검증을 강력히 권장**합니다. 자동 갱신의 이점이 너무 크기 때문입니다. 한번 설정하면 영구적으로 작동하므로, 인증서 만료로 인한 서비스 중단 위험이 없습니다. 이메일 검증은 특별한 사유가 있을 때만 사용하는 것이 좋습니다. 예를 들어 DNS 접근이 절대 불가능하거나, 일회성 테스트용 인증서가 필요한 경우에만 사용합니다. **검증 방법 전환** 한번 선택한 검증 방법은 바꿀 수 없습니다. 이메일 검증으로 발급받은 인증서를 나중에 DNS 검증으로 변경할 수 없습니다. 방법을 바꾸려면 기존 인증서를 삭제하고 새로 발급받아야 합니다. 따라서 처음부터 신중하게 선택하는 것이 중요합니다. **실제 사례** 김개발 씨가 물었습니다. "그럼 대부분 DNS 검증을 쓰나요?" 박시니어 씨가 고개를 끄덕였습니다. "그렇지. 우리 회사에서도 모든 인증서를 DNS 검증으로 발급받아. Route 53을 쓰면 클릭 한 번이면 되니까 정말 편해." 실제로 현업에서는 대부분 DNS 검증을 사용합니다. 특히 Route 53을 사용하는 경우 ACM과의 통합이 완벽하여 완전 자동화가 가능합니다. **선택 가이드** 박시니어 씨가 정리해주었습니다. "DNS 검증을 선택해: DNS 레코드를 추가할 수 있고, 자동 갱신을 원하는 경우 (대부분의 경우)" "이메일 검증을 선택해: DNS 접근이 불가능하고, 도메인 관리자 이메일만 받을 수 있는 경우 (특수한 경우)" 김개발 씨는 이제 명확하게 이해했습니다. "DNS 검증이 훨씬 낫네요. 자동 갱신이 최고죠!" **실전 팁** 💡 - 가능하면 항상 DNS 검증을 사용하세요. 자동 갱신의 편리함은 대체 불가능합니다. - Route 53 사용자는 ACM에서 원클릭으로 DNS 레코드를 추가할 수 있습니다. - 이메일 검증은 갱신 알림을 놓치기 쉬우므로, 캘린더에 만료일을 등록해두세요. --- ## 5. 로드 밸런서에 HTTPS 리스너 추가 김개발 씨가 발급받은 ACM 인증서를 보며 생각했습니다. "이제 이걸 어디에 연결하지?" 현재 EC2 인스턴스가 직접 HTTP 트래픽을 받고 있었는데, HTTPS를 적용하려면 구조를 바꿔야 할 것 같았습니다. **Application Load Balancer(ALB)**는 트래픽을 여러 EC2 인스턴스에 분산하는 로드 밸런서입니다. ALB에 **HTTPS 리스너**를 추가하고 ACM 인증서를 연결하면, 사용자는 HTTPS로 접속하고 내부적으로는 HTTP로 통신하는 **SSL Termination** 구조를 만들 수 있습니다. 이렇게 하면 EC2 인스턴스에서 복잡한 SSL 설정을 하지 않아도 됩니다. 다음 코드를 살펴봅시다. ```javascript # Boto3로 로드 밸런서에 HTTPS 리스너 추가 import boto3 elbv2 = boto3.client('elbv2', region_name='ap-northeast-2') # 로드 밸런서 ARN (미리 생성된 ALB) load_balancer_arn = 'arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:loadbalancer/app/my-alb/abc123' # ACM 인증서 ARN certificate_arn = 'arn:aws:acm:ap-northeast-2:123456789012:certificate/xyz789' # 타겟 그룹 ARN (EC2 인스턴스들이 등록된 그룹) target_group_arn = 'arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:targetgroup/my-targets/def456' # HTTPS 리스너 생성 (포트 443) response = elbv2.create_listener( LoadBalancerArn=load_balancer_arn, Protocol='HTTPS', Port=443, Certificates=[{'CertificateArn': certificate_arn}], DefaultActions=[{ 'Type': 'forward', 'TargetGroupArn': target_group_arn }] ) print(f"HTTPS 리스너가 생성되었습니다: {response['Listeners'][0]['ListenerArn']}") ``` 김개발 씨는 박시니어 씨에게 다시 조언을 구했습니다. "선배님, 인증서는 발급받았는데 이제 어떻게 하죠?" 박시니어 씨가 웃으며 말했습니다. "로드 밸런서를 쓰는 게 가장 깔끔해. EC2에 직접 설치하는 것보다 훨씬 관리가 편하거든." **왜 로드 밸런서인가?** ACM 인증서는 AWS 서비스에서만 사용할 수 있습니다. EC2 인스턴스에 직접 설치할 수 없습니다. 마치 특별한 열쇠가 특정 자물쇠에만 맞는 것과 같습니다. ACM 인증서라는 열쇠는 로드 밸런서, CloudFront, API Gateway라는 자물쇠에만 맞습니다. 따라서 HTTPS를 적용하려면 로드 밸런서를 앞에 배치하고, 로드 밸런서가 HTTPS 트래픽을 받아서 EC2로 전달하는 구조를 만들어야 합니다. **Application Load Balancer 소개** **Application Load Balancer(ALB)**는 AWS의 7계층 로드 밸런서입니다. 기본적으로는 들어오는 트래픽을 여러 EC2 인스턴스에 분산하는 역할을 합니다. 하지만 그 이상의 기능도 있습니다. HTTPS 종료, 경로 기반 라우팅, 호스트 기반 라우팅 등 다양한 기능을 제공합니다. 비유하자면 ALB는 건물의 안내 데스크와 같습니다. 방문자(사용자)가 오면 적절한 사무실(EC2 인스턴스)로 안내해줍니다. 또한 보안 검색(HTTPS 복호화)도 처리합니다. **SSL Termination 개념** **SSL Termination**은 HTTPS 암호화를 로드 밸런서에서 끝내는 것을 의미합니다. 사용자는 HTTPS로 로드 밸런서에 접속합니다. 로드 밸런서가 HTTPS를 복호화하여 HTTP로 변환한 후, EC2 인스턴스에 전달합니다. EC2 인스턴스는 평범한 HTTP 트래픽을 받습니다. 이렇게 하면 EC2 인스턴스에서 복잡한 SSL 설정을 할 필요가 없습니다. Nginx나 Apache에서 인증서를 설치하고 관리하는 번거로움이 사라집니다. 모든 SSL 관리는 로드 밸런서가 담당합니다. **로드 밸런서 생성** 먼저 Application Load Balancer를 생성해야 합니다. EC2 콘솔에서 "로드 밸런서" 메뉴로 이동합니다. "로드 밸런서 생성" 버튼을 클릭하고, "Application Load Balancer"를 선택합니다. 이름을 입력하고, 인터넷 연결(Internet-facing)을 선택합니다. 가용 영역을 최소 2개 선택해야 합니다. 예를 들어 ap-northeast-2a와 ap-northeast-2c를 선택합니다. 이렇게 하면 한 가용 영역에 장애가 발생해도 서비스가 계속 작동합니다. **보안 그룹 설정** 로드 밸런서의 보안 그룹에서 포트 80(HTTP)과 포트 443(HTTPS)을 열어야 합니다. 인바운드 규칙에 다음을 추가합니다: - 포트 80, 소스 0.0.0.0/0 (모든 곳에서 HTTP 접속 허용) - 포트 443, 소스 0.0.0.0/0 (모든 곳에서 HTTPS 접속 허용) EC2 인스턴스의 보안 그룹은 수정해야 합니다. 이제 사용자가 직접 EC2에 접속하는 것이 아니라, 로드 밸런서를 통해서만 접속해야 하기 때문입니다. EC2의 인바운드 규칙을 로드 밸런서의 보안 그룹으로만 제한합니다. **타겟 그룹 생성** 타겟 그룹은 로드 밸런서가 트래픽을 전달할 EC2 인스턴스들의 그룹입니다. "타겟 그룹 생성" 메뉴에서 타겟 유형을 "인스턴스"로 선택합니다. 프로토콜은 HTTP, 포트는 80을 입력합니다. 헬스 체크 경로를 설정합니다. 보통 `/` 또는 `/health` 같은 경로를 사용합니다. 다음 단계에서 실제 EC2 인스턴스를 선택하여 타겟 그룹에 등록합니다. 여러 개의 인스턴스를 등록하면 로드 밸런서가 자동으로 트래픽을 분산합니다. **HTTPS 리스너 추가** 이제 핵심 단계입니다. 로드 밸런서에 HTTPS 리스너를 추가합니다. 로드 밸런서 상세 페이지에서 "리스너" 탭으로 이동합니다. 기본적으로 HTTP:80 리스너가 있을 것입니다. "리스너 추가" 버튼을 클릭합니다. 프로토콜을 "HTTPS", 포트를 "443"으로 설정합니다. 그 아래 "기본 SSL 인증서" 섹션에서 "ACM에서" 옵션을 선택하고, 앞서 발급받은 인증서를 선택합니다. 기본 작업은 "타겟 그룹으로 전달"을 선택하고, 앞서 생성한 타겟 그룹을 선택합니다. "추가" 버튼을 클릭하면 HTTPS 리스너가 생성됩니다. **DNS 설정 변경** 로드 밸런서의 DNS 이름을 확인합니다. 예를 들어 `my-alb-123456789.ap-northeast-2.elb.amazonaws.com` 같은 형태입니다. Route 53에서 자신의 도메인을 이 로드 밸런서로 연결합니다. A 레코드 또는 ALIAS 레코드를 생성하여 `myawesomeapp.com`이 로드 밸런서를 가리키도록 설정합니다. Route 53을 사용한다면 ALIAS 레코드를 사용하는 것이 좋습니다. ALIAS 레코드는 AWS 리소스를 가리킬 때 추가 비용이 없고, 로드 밸런서의 IP가 변경되어도 자동으로 추적됩니다. **테스트** DNS 전파가 완료되면 브라우저에서 `https://myawesomeapp.com`으로 접속해봅니다. 주소창에 자물쇠 아이콘이 표시되면 성공입니다! 인증서 정보를 클릭해보면 ACM에서 발급한 인증서 정보를 확인할 수 있습니다. 김개발 씨는 자신의 웹사이트가 HTTPS로 작동하는 것을 보며 감격했습니다. "드디어 '안전하지 않음' 경고가 사라졌어!" **다중 인증서 지원** 하나의 HTTPS 리스너에 여러 개의 인증서를 추가할 수도 있습니다. **SNI(Server Name Indication)** 기능을 사용하면, 하나의 로드 밸런서에서 여러 도메인을 서로 다른 인증서로 처리할 수 있습니다. 예를 들어 `example.com`과 `another.com`을 같은 로드 밸런서에서 서비스하되, 각각 다른 인증서를 사용할 수 있습니다. 리스너의 "인증서 관리" 메뉴에서 추가 인증서를 등록하면 됩니다. **비용 고려** ALB는 시간당 요금과 LCU(Load Balancer Capacity Unit) 요금이 부과됩니다. 소규모 트래픽이라면 월 20-30달러 정도입니다. 하지만 ACM 인증서 자체는 무료이고, SSL 관리의 편리함을 고려하면 충분히 가치가 있습니다. 수동으로 인증서를 관리하는 시간과 노력을 절약할 수 있습니다. **실전 팁** 💡 - EC2 보안 그룹은 로드 밸런서에서만 접속 가능하도록 제한하여 보안을 강화하세요. - 헬스 체크 경로를 적절히 설정하여 장애 발생 시 자동으로 트래픽을 건강한 인스턴스로 전환하세요. - CloudWatch를 통해 로드 밸런서의 메트릭을 모니터링하여 성능을 추적하세요. --- ## 6. HTTP에서 HTTPS로 리다이렉션 설정 김개발 씨가 HTTPS 적용을 완료하고 기뻐했지만, 곧 문제를 발견했습니다. 사용자가 `http://myawesomeapp.com`으로 접속하면 여전히 HTTP로 연결되었습니다. "HTTPS를 강제하려면 어떻게 해야 하지?" 많은 사용자가 습관적으로 `http://`로 접속하거나, 북마크에 HTTP URL이 저장되어 있습니다. 따라서 HTTP로 들어오는 모든 요청을 **HTTPS로 리다이렉트**해야 합니다. ALB에서는 **리스너 규칙**을 사용하여 HTTP 요청을 자동으로 HTTPS로 301 리다이렉트할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript # Boto3로 HTTP → HTTPS 리다이렉트 규칙 생성 import boto3 elbv2 = boto3.client('elbv2', region_name='ap-northeast-2') # HTTP 리스너 ARN (포트 80 리스너) http_listener_arn = 'arn:aws:elasticloadbalancing:ap-northeast-2:123456789012:listener/app/my-alb/abc123/def456' # HTTP 리스너의 기본 작업을 HTTPS 리다이렉트로 변경 response = elbv2.modify_listener( ListenerArn=http_listener_arn, DefaultActions=[{ 'Type': 'redirect', 'RedirectConfig': { 'Protocol': 'HTTPS', 'Port': '443', 'StatusCode': 'HTTP_301', # 영구 리다이렉트 'Host': '#{host}', 'Path': '/#{path}', 'Query': '#{query}' } }] ) print("HTTP → HTTPS 리다이렉트가 설정되었습니다!") # 이제 http://example.com/page?id=123 → https://example.com/page?id=123 ``` 박시니어 씨가 김개발 씨의 화면을 보며 말했습니다. "아, HTTP 리다이렉트를 안 했구나. 이건 필수야." 김개발 씨가 고개를 갸우뚱했습니다. "HTTPS 리스너를 만들었는데 왜 리다이렉트가 필요한가요?" **왜 리다이렉트가 필요한가?** HTTPS 리스너를 추가했다고 해서 사용자가 자동으로 HTTPS로 접속하는 것은 아닙니다. 사용자가 브라우저 주소창에 `myawesomeapp.com`만 입력하면, 대부분의 브라우저는 기본적으로 HTTP를 시도합니다. 또한 오래된 북마크, 검색 엔진 결과, 외부 링크 등에는 HTTP URL이 많습니다. 마치 건물에 새 정문을 만들었지만, 여전히 사람들이 옛날 후문으로 들어오는 것과 같습니다. 후문에 "정문으로 가세요"라는 안내판을 세워야 하는 것처럼, HTTP 요청에 "HTTPS로 가세요"라고 알려줘야 합니다. **리다이렉트의 작동 원리** HTTP 리다이렉트는 **301 영구 이동** 또는 **302 임시 이동** 상태 코드를 사용합니다. 사용자가 `http://example.com/page`로 접속하면, 서버가 "이 페이지는 `https://example.com/page`로 이동했습니다"라는 응답을 보냅니다. 브라우저는 자동으로 새 URL로 다시 요청을 보냅니다. 301은 영구 이동을 의미합니다. 검색 엔진은 이 코드를 보고 "아, 이 페이지는 영구적으로 HTTPS로 이동했구나"라고 인식하고 검색 결과를 HTTPS URL로 업데이트합니다. HTTP에서 HTTPS로 전환할 때는 반드시 301을 사용해야 SEO에 유리합니다. **ALB에서 리다이렉트 설정** Application Load Balancer는 리다이렉트 기능을 내장하고 있습니다. 별도의 코드 작성 없이 설정만으로 구현할 수 있습니다. 로드 밸런서 콘솔에서 HTTP:80 리스너를 선택합니다. 이미 리스너가 있다면 편집하고, 없다면 새로 만듭니다. 리스너의 "규칙 보기/편집"을 클릭합니다. 기본 규칙을 편집합니다. 기존 "타겟 그룹으로 전달" 작업을 삭제하고, "리다이렉트 대상" 작업을 추가합니다. **리다이렉트 설정 옵션** 리다이렉트 설정에서 다음과 같이 입력합니다: - 프로토콜: HTTPS - 포트: 443 - 상태 코드: 301 - 영구 이동 - 호스트: `#{host}` (원래 호스트 유지) - 경로: `/#{path}` (원래 경로 유지) - 쿼리: `#{query}` (원래 쿼리 문자열 유지) `#{host}`, `#{path}`, `#{query}`는 ALB의 변수입니다. 이렇게 설정하면 원래 URL의 모든 부분을 그대로 유지하면서 프로토콜만 HTTPS로 바꿉니다. 예를 들어 `http://example.com/products?category=books`로 접속하면, `https://example.com/products?category=books`로 리다이렉트됩니다. 경로와 쿼리 문자열이 모두 보존됩니다. **301 vs 302** **301 영구 이동**은 "이 페이지는 영원히 새 위치로 이동했습니다"라는 의미입니다. 브라우저와 검색 엔진은 이 정보를 캐싱합니다. 다음번에 같은 URL로 접속하면 서버에 묻지 않고 바로 새 URL로 이동합니다. **302 임시 이동**은 "이 페이지는 일시적으로 다른 곳에 있습니다"라는 의미입니다. 브라우저는 매번 서버에 확인합니다. HTTP에서 HTTPS로의 전환은 영구적인 변경이므로 반드시 301을 사용해야 합니다. 302를 사용하면 SEO에 불리하고, 성능도 떨어집니다. **HSTS 헤더 추가** 더 강력한 보안을 원한다면 **HSTS(HTTP Strict Transport Security)** 헤더를 추가할 수 있습니다. HSTS는 브라우저에게 "앞으로 이 사이트는 항상 HTTPS로만 접속하세요"라고 명령합니다. 한번 HSTS 헤더를 받은 브라우저는 해당 도메인에 대해 자동으로 HTTP를 HTTPS로 변환합니다. 서버에 리다이렉트를 요청하지도 않습니다. ALB의 HTTPS 리스너에서 "규칙 편집"을 통해 HTTP 헤더를 삽입할 수 있습니다. `Strict-Transport-Security: max-age=31536000; includeSubDomains` 헤더를 추가합니다. 이것은 "1년 동안 이 도메인과 모든 서브도메인은 HTTPS로만 접속하세요"라는 의미입니다. 매우 강력한 보안 조치이지만, 한번 설정하면 HTTP로 돌아가기 어렵다는 점을 주의해야 합니다. **리다이렉트 테스트** 설정을 완료한 후 반드시 테스트해야 합니다. 브라우저에서 `http://myawesomeapp.com`으로 접속해봅니다. 즉시 `https://myawesomeapp.com`으로 리다이렉트되어야 합니다. 개발자 도구의 Network 탭을 열면 301 응답을 확인할 수 있습니다. 하위 경로도 테스트합니다. `http://myawesomeapp.com/products?id=123`으로 접속하면 `https://myawesomeapp.com/products?id=123`으로 리다이렉트되는지 확인합니다. 경로와 쿼리 문자열이 정확히 보존되어야 합니다. **curl 명령어로 확인** 터미널에서 curl 명령어로도 확인할 수 있습니다: ``` curl -I http://myawesomeapp.com ``` 결과에서 `HTTP/1.1 301 Moved Permanently`와 `Location: https://myawesomeapp.com/`를 확인할 수 있어야 합니다. **SEO 고려사항** HTTP에서 HTTPS로 마이그레이션할 때는 검색 순위에 영향을 주지 않도록 주의해야 합니다. 301 리다이렉트를 사용하면 구글은 기존 HTTP 페이지의 검색 순위를 HTTPS 페이지로 이전합니다. 하지만 302를 사용하거나 리다이렉트를 안 하면 검색 순위가 떨어질 수 있습니다. Google Search Console에 HTTPS 버전의 사이트를 추가하고, 사이트맵을 제출하는 것도 좋은 방법입니다. 이렇게 하면 구글이 빠르게 HTTPS 페이지를 색인합니다. **혼합 콘텐츠 문제** HTTPS 페이지에서 HTTP 리소스를 로드하면 "혼합 콘텐츠" 경고가 발생합니다. 예를 들어 `https://example.com` 페이지에서 ` `처럼 HTTP 이미지를 로드하면, 브라우저가 경고를 표시하거나 리소스를 차단합니다. HTML 코드에서 모든 리소스 URL을 HTTPS로 변경하거나, 프로토콜 상대 URL(`//example.com/image.jpg`)을 사용하여 자동으로 현재 프로토콜을 따르도록 해야 합니다. **완성** 김개발 씨는 모든 설정을 완료하고 테스트해보았습니다. HTTP로 접속하면 자동으로 HTTPS로 리다이렉트되었고, 주소창에 자물쇠 아이콘이 빛났습니다. "드디어 완벽한 HTTPS 사이트가 되었어!" 김개발 씨는 뿌듯함을 느꼈습니다. 박시니어 씨가 어깨를 두드리며 말했습니다. "잘했어. 이제 사용자들이 안전하게 접속할 수 있겠네." 보안은 선택이 아닌 필수입니다. HTTPS는 현대 웹 개발의 기본이며, ACM과 ALB를 사용하면 누구나 쉽게 구현할 수 있습니다. **실전 팁** 💡 - 301 영구 리다이렉트를 사용하여 SEO를 보호하세요. - HSTS 헤더를 추가하여 브라우저가 자동으로 HTTPS를 사용하도록 강제할 수 있습니다. - HTML의 모든 리소스 URL을 HTTPS로 변경하여 혼합 콘텐츠 경고를 방지하세요. --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS,ACM,Security

언어: JavaScript

태그: AWS, ACM, HTTPS, SSL/TLS, LoadBalancer, AWS,ACM,Security

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS Certificate Manager로 HTTPS 인증서 발급 완벽 가이드

목차

1. HTTPS와 SSL/TLS 인증서의 필요성

2. AWS Certificate Manager(ACM) 소개

3. ACM으로 무료 인증서 발급받기

4. DNS 검증 vs 이메일 검증

5. 로드 밸런서에 HTTPS 리스너 추가

6. HTTP에서 HTTPS로 리다이렉션 설정

댓글 (0)

함께 보면 좋은 카드 뉴스

VPC 네트워크의 기초 - CIDR과 서브넷 설계 완벽 가이드

AWS 리소스 정리와 비용 관리 완벽 가이드

Route 53으로 도메인 연결 완벽 가이드

AWS RDS 관리형 데이터베이스 완벽 가이드

AWS Auto Scaling 완벽 가이드