[security] ACM

One-Line Summary

ACM은 SSL/TLS 인증서를 무료로 발급·관리하고 자동 갱신(auto-renew) 해 HTTPS를 손쉽게 붙이게 하는 서비스다. 시험 최대 빈출은 ① ELB·CloudFront·API Gateway에는 붙지만 EC2에 직접 설치는 불가, ② CloudFront용 인증서는 반드시 us-east-1(버지니아 북부), ③ 인증서는 리전 리소스라 통합 대상과 같은 리전에 있어야 다.

뭔지 (What / Why)

HTTPS를 쓰려면 TLS 인증서를 발급받아 서버에 설치하고, 만료 전에 갱신해야 한다. 갱신을 놓치면 사이트가 통째로 다운되는데, 이는 흔한 대형 장애 원인이다.

ACM은 공인 인증서를 무료로 발급하고 만료 전 자동 갱신해, 인증서 관리 부담과 만료 사고를 없앤다.

클라이언트 ──HTTPS──▶ [ALB / CloudFront / API Gateway] ──(TLS 종료)──▶ 백엔드
                          ▲ 여기에 ACM 인증서 연결, ACM이 자동 갱신

TLS 종료(Termination)와 통합 지점 이해

ACM 인증서는 TLS를 종료하는 지점(ALB/CloudFront/API GW)에 붙는다. 그 뒤 백엔드로 가는 구간은 별개다.

[클라이언트] ==HTTPS(ACM)==> [ALB] --HTTP 또는 재암호화--> [EC2]
  - ALB에서 TLS 종료: 클라이언트↔ALB 구간 암호화(가장 흔함)
  - 백엔드까지 암호화(end-to-end)하려면 ALB→EC2도 HTTPS로 재암호화

두 가지 최대 함정 (빈출)

1) EC2 직접 설치 불가

• ACM 공인 인증서는 EC2에 직접 설치할 수 없다. EC2로 HTTPS를 서비스하려면 앞단에 ALB/CloudFront를 두고 거기에 ACM을 붙인다.
• 굳이 서버에 직접 넣어야 하면 외부 구매 인증서를 IAM/ACM에 임포트해야 하는데, 임포트 인증서는 자동 갱신이 안 된다(수동 재임포트).

2) CloudFront는 us-east-1

• CloudFront는 글로벌 엣지 서비스라, 붙일 인증서를 us-east-1(N. Virginia) 에 발급해야 인식한다. 서비스 리전이 서울이어도 CloudFront용 인증서는 버지니아에.

자동 갱신 조건 (실무 포인트)

• DNS 검증 + 통합 서비스에서 실제 사용 중이면 ACM이 만료 전 자동 갱신(무개입).
• DNS 검증용 CNAME 레코드를 지우면 갱신이 실패할 수 있다(그대로 둬야 함).
• 임포트한 인증서는 ACM이 갱신하지 않는다 → 만료 관리 직접.

실무 활용 사례

사례 1. ALB HTTPS 웹서비스

• Route 53에서 DNS 검증으로 ACM 발급 → ALB 리스너(443)에 연결 → HTTP(80)는 HTTPS로 리다이렉트. 갱신은 ACM 자동.

사례 2. CloudFront로 글로벌 HTTPS

• us-east-1에 ACM 발급 → CloudFront 배포에 연결 → 커스텀 도메인으로 전 세계 HTTPS 제공.

사례 3. 내부 서비스 사설 인증서

• 사내 마이크로서비스 간 TLS는 공인 인증서가 필요 없으니 ACM Private CA로 사설 인증서를 발급·관리.

Common Wrong Directions

Exam Triggers

Memory Sentence

ACM은 공인 TLS 인증서를 무료 발급·자동 갱신(DNS검증+사용중 조건)하고 ALB·CloudFront·API Gateway에 붙는다. EC2 직접 설치 불가(앞단 LB/CDN), CloudFront용은 us-east-1, 인증서는 리전 리소스라 통합 대상과 같은 리전. 임포트 인증서는 자동 갱신 안 됨, 내부용은 Private CA.

References

• AWS Certificate Manager
• Services integrated with ACM
• Managed renewal & DNS validation
• Certificates for CloudFront (us-east-1)