ElastiCache 연동 과정에서 짚어본 TLS와 Security Group

이건선·2026년 4월 18일

해결

목록 보기
66/66

배경

Spring Boot 세션 저장소를 AWS ElastiCache(Valkey Serverless)로 옮기면서 이 에러를 만났다.

Unable to connect to test-edjqks.serverless.use1.cache.amazonaws.com/<unresolved>:6379

원인은 두 가지였다. TLS 미설정Security Group 방향 오인.


원인 1 — Serverless는 TLS가 강제다

ElastiCache Serverless는 멀티 테넌트 구조라서 TLS를 끌 수 없다. 평문 패킷은 즉시 끊긴다.

yml에 한 줄 추가하면 끝난다.

spring:
  data:
    redis:
      host: test-edjqks.serverless.use1.cache.amazonaws.com
      port: 6379
      ssl:
        enabled: true   # 필수

노드 기반 ElastiCache는 단일 테넌트라 TLS가 선택사항이지만, Serverless는 옵션 자체가 없다.


원인 2 — SG 규칙은 "수신자" 쪽에 건다

트래픽은 EC2 → ElastiCache로 흐르므로, 받는 쪽(ElastiCache)의 SG에 규칙이 있어야 한다.

EC2와 ElastiCache가 같은 SG(launch-wizard-11)를 공유했기에 self-reference 한 줄로 해결됐다.

ElastiCache의 사설 IP는 AWS가 자동 변경하므로 IP 기반 규칙 대신 SG ID 기반이 안정적이다.


진단 순서

# 1) DNS — 사설 IP로 해석되면 OK
nslookup test-edjqks.serverless.use1.cache.amazonaws.com

# 2) TCP — timeout이면 SG 문제
nc -zv test-edjqks.serverless.use1.cache.amazonaws.com 6379

# 3) 세션 생성
curl -X POST http://<ec2-ip>:8080/create

에러 메시지로 본 진척도

TCP 연결 전 (SG 차단)

연결·TLS OK, 명령만 거부

성공

KEYS가 막힌 건 Serverless가 클러스터 모드로 동작하기 때문이다. 다중 슬롯을 스캔할 수 없어 SCAN을 써야 한다.

ScanOptions options = ScanOptions.scanOptions()
        .match("spring:session:*")
        .count(100)
        .build();

정리

  • Serverless = TLS 필수ssl.enabled: true
  • SG 인바운드는 수신자에게 → ElastiCache SG에 self-reference
profile
멋지게 기록하자

0개의 댓글