ElastiCache Cost Explorer 분석
클라우드에서의 비용은 조용히 증가하다가 한 달의 인보이스로 존재감을 드러냅니다. 특히 ElastiCache는 빠른 속도를 제공하는 만큼, 숨은 비용 항목도 많고 변화도 빠릅니다.
ElastiCache 비용은 AWS Cost Explorer 데이터를 기준으로 ‘무엇이 얼마만큼, 왜 올랐는지’를 명확히 드러냅니다. 또한, RI(RI 만료 → 온디맨드 전환), Cross-AZ 데이터 전송, 비효율적인 캐시 노드 구성 등 실제 비용 상승의 주요 원인을 구체적으로 분석하여, 1회성이 아닌 지속 가능한 최적화 전략을 세울 수 있습니다.
이번 글에서는 ElastiCache를 Cost Explorer에서 비용 분석해보도록 하겠습니다.
ElastiCache의 현재 비용 진단하기
Amazon ElastiCache의 비용을 정확하게 파악하려면 AWS Cost Explorer를 활용해 세부 항목을 필터링하고 분석해야 합니다. ElastiCache는 인스턴스 유형(노드 타입), 클러스터 시간 사용량, 데이터 계층화, 백업 저장소, CloudWatch 모니터링 등 항목별로 요금이 과금되므로, 이를 분리해 파악해야 최적의 비용 절감 전략을 수립할 수 있습니다.
Cost Explorer 접속 방법
ElastiCache 비용을 분석하려면 먼저 AWS Console 상단의 검색창에 "Cost Explorer"를 입력하여 해당 서비스를 선택하고, 이후 "Cost Explorer 열기"를 클릭하여 비용 분석 도구에 진입합니다.
Group By 설정
비용을 세부적으로 분석하기 위해 Group By 항목을 설정하는 것이 중요합니다. ElastiCache는 노드 단위로 과금되므로, Resource ID를 기준으로 그룹핑할 경우 각 클러스터 또는 노드별로 세부적인 비용을 확인할 수 있습니다. 또한 UsageType으로 그룹핑하면 리소스 사용 형태별(예: 노드 사용량, 예약 인스턴스 사용량, 백업 저장소 등) 과금 구조를 파악할 수 있습니다.
필터링 설정
정확한 비용 분석을 위해 Service 필터에서 Amazon ElastiCache를 선택해야 합니다. 이어서 UsageType 필터에서는 NodeUsage, HeavyUsage 등의 특정 항목을 선택하거나, 모든 항목을 선택한 후 후처리 방식으로 인스턴스 유형별, 시간대별, 백업 및 스토리지 비용을 세분화하여 분석할 수 있습니다.
일별/월별 트렌드 분석 설정
분석 기간은 Cost Explorer 상단의 기간 선택 메뉴를 활용하여 지정합니다. 상단의 기간 선택 메뉴에서 이번 달, 지난 3개월, 6개월 등을 선택하여 분석할 수 있습니다.
일별 분석은 갑작스러운 비용 상승이나 구성 변경(예: 노드 증가, 데이터 폭증)과 같은 이벤트를 즉시 추적하는 데 유용합니다. 반면 월별 분석은 장기적인 사용량 트렌드, 예약 인스턴스 도입 효과, 클러스터 리사이징 전후의 변화 등을 파악하는 데 적합합니다.
Cost Explorer 항목 설명
APN2-HeavyUsage:cache.r6g.large
이 항목은 Reserved Instances(예약 인스턴스) 방식으로 구매한 cache.r6g.large 인스턴스에 대해 할인된 요금이 과금된 시간입니다. 예약 인스턴스를 사전에 구매해놓고 사용할 경우, 온디맨드 요금보다 할인된 시간당 요금이 적용됩니다.
APN2-NodeUsage:cache.r6g.large
이 항목은 온디맨드 방식으로 실행 중인 cache.r6g.large 노드의 시간당 사용량을 나타냅니다. 예약 없이 사용하는 인스턴스는 이 항목을 통해 요금이 청구됩니다.
데이터 전송 비용이 보이지 않는 이유
ElastiCache 서비스 비용 항목을 UsageType으로 보면 인스턴스 사용에 대한 비용만 있고 데이터 전송에 대한 비용은 보이지 않습니다.
ElastiCache가 데이터를 보낼 때, 네트워크 전송 비용은 “발생합니다”. 다만, ElastiCache 서비스 사용자가 그 비용을 부담하지 않을 뿐입니다. 그 대신, 데이터를 받는 쪽 또는 연결된 리소스(VPC 소속 주체)가 비용을 부담하게 됩니다.
ElastiCache는 완전 관리형 서비스입니다. AWS가 내부적으로 VPC에 ENI를 붙여서 제공하지만, 사용자는 그 ENI나 네트워크 구성을 직접 통제하지 못합니다. 따라서, AWS는 ElastiCache에서 나가는 네트워크 트래픽에 대해서는 과금을 하지 않고, 대신 이를 수신하는 쪽(VPC, EC2, Lambda 등)이 트래픽을 소비한 것으로 보고 비용을 부과합니다.
따라서 데이터 전송비용은 EC2, Lambda, VPC, NAT, Transit 등 ElastiCache와 통신하는 서비스에서 확인해야 합니다
고비용의 주요 원인 분석
과도한 노드 규모 또는 과다한 노드 수
ElastiCache는 노드 인스턴스 유형(예: cache.r6g.large)과 개수에 따라 시간당 요금이 발생합니다. 예를 들어 캐시 용량을 훨씬 초과하는 r6g.2xlarge 노드를 사용하거나, 여러 개의 복제 노드(replica)를 구성해 두었으나 실제 조회 요청이 마스터 노드 하나에서만 대부분 처리된다면 과도한 자원 낭비로 이어져 요금이 증가합니다. 또한 개발, 테스트용 클러스터가 운영 이후에도 삭제되지 않고 계속 실행 중이라면 노드 수 증가에 따른 비용 누적이 큽니다.
Cross-AZ 배치에 따른 데이터 전송 비용
ElastiCache 클러스터와 이를 사용하는 EC2, Lambda 등의 클라이언트가 서로 다른 가용 영역(AZ)에 있을 경우 Cross-AZ 데이터 전송 비용이 발생합니다. 특히 Redis 리더-리플리카 구성에서 서로 다른 AZ에 배치되면, 복제 트래픽이나 읽기 요청이 많을수록 GB당 $0.01의 전송 요금이 지속 발생합니다.
데이터 전송 비용은 Usage Type에는 명확히 노출되지 않고 EC2 등 다른 서비스 측의 요금으로 청구되기 때문에, Cost Explorer에서는 전체 비용 구조를 한눈에 파악하기 어렵습니다.
서버리스 ElastiCache에서 트래픽 급증
서버리스 Redis는 사용한 처리량에 따라 GB 단위 처리량 기반 요금이 발생합니다. 일정 트래픽 수준을 초과하면 온디맨드 Redis보다 높은 요금이 청구될 수 있습니다. 캐시 효율이 떨어지거나 캐시 미스가 잦은 구조라면, 트래픽이 증가해 백엔드 DB 호출 증가와 함께 서버리스 Redis의 처리량 과금도 증가할 수 있습니다.
Cost Explorer 분석
ElastiCache의 UsageType 별 비용 구조를 예시로 분석해보겠습니다.
주요 비용 항목을 분석해보면 다음과 같습니다.
APN2-HeavyUsage:cache.r6g.xlarge (RI r6g.xlarge 사용)
총 $2,356.86 (총 비용의 약 58.4%)로 가장 큰 비중을 차지합니다. 월별 비용은 $496.99(12월~3월)로 안정적이었으나, 2025년 4월 $416.98로 감소했습니다. 사용 시간도 1,488시간에서 1,248.46시간으로 감소했습니다.
HeavyUsage는 예약 인스턴스(RI)에 대한 비용이므로, 이 계정은 cache.r6g.xlarge 인스턴스에 대한 RI를 구매하여 사용하고 있음을 알 수 있습니다. 4월의 감소는 해당 RI의 적용 대상 노드 수가 줄었거나, RI 자체가 만료되어 온디맨드로 전환되기 시작했음을 시사할 수 있습니다.
RI는 온디맨드보다 훨씬 저렴하므로, 해당 인스턴스 유형의 장기적인 사용 계획이 있다면 RI 구매를 유지하거나 갱신하는 것이 중요합니다. 4월의 감소가 RI 만료 때문이라면, 즉시 재구매를 검토해야 합니다.
APN2-HeavyUsage:cache.r6g.large (RI r6g.large 사용)
총 $1,178.43 (총 비용의 약 29.2%)로 두 번째로 큰 비중입니다. 월별 비용은 $248.50(12월~3월)으로 안정적이었으나, 2025년 4월 $208.50로 감소했습니다. 사용 시간도 r6g.xlarge와 동일하게 감소했습니다.
이 역시 cache.r6g.large 인스턴스에 대한 RI 비용입니다. r6g.xlarge와 유사한 비용 패턴을 보이며, 함께 사용량이 줄어들었거나 RI 전략에 변화가 있었음을 나타냅니다.
APN2-HeavyUsage:cache.t4g.micro (RI t4g.micro 사용)
총 $225.81 (총 비용의 약 5.6%)를 차지합니다. 월별 $47.62(12월~3월)에서 4월 $39.96으로 감소했습니다. 사용 시간도 비슷하게 감소했습니다. t4g.micro는 비교적 작은 인스턴스 유형으로, 개발/테스트 환경이나 소규모 애플리케이션에 주로 사용될 수 있습니다. 이 또한 RI로 구매되어 비용 효율을 높이고 있음을 보여줍니다.
APN2-NodeUsage:cache.t4g.micro (온디맨드 t4g.micro 사용)
총 $132.53 (총 비용의 약 3.3%)를 차지합니다. 월별 $35.71(12월)에서 $9.12(4월)로 비용이 꾸준히 감소했습니다. t4g.micro 인스턴스의 온디맨드 사용량입니다. 비용 감소는 해당 유형의 온디맨드 노드 수가 줄거나, 사용량이 최적화되었음을 시사합니다.
APN2-NodeUsage:cache.r6g.xlarge 및 APN2-NodeUsage:cache.r6g.large (온디맨드 r6g 인스턴스 사용)
두 항목 모두 2025년 4월에 각각 $93.29와 $46.74의 비용이 발생했습니다. 그 이전에는 $0.00였습니다. 4월에 HeavyUsage (RI)가 감소한 반면, NodeUsage (온디맨드)가 새롭게 발생했습니다. 이는 앞에서 언급했듯이 기존에 구매했던 cache.r6g.xlarge 및 cache.r6g.large 인스턴스에 대한 RI가 4월에 만료되면서, 해당 노드들의 비용이 온디맨드로 전환되어 과금되기 시작했음을 의미합니다. 이는 비용 효율성 측면에서 매우 중요한 변화입니다.
이번에는 Resouce ID 별로 분류하여 비용을 분석해보겠습니다.
주목할 만한 점은 2024년 12월부터 2025년 3월까지는 대부분의 클러스터 비용이 $0.00이었으나, 2025년 4월에 일제히 비용이 발생하기 시작했다는 것입니다.
cluster:web-cache2
2025년 4월에 $46.65의 비용이 발생했으며, 사용 시간은 720시간으로 월 전체 시간과 거의 일치합니다. 이 클러스터가 4월부터 가동되기 시작했거나, 이전에 RI 혜택을 받다가 4월에 온디맨드로 전환되었음을 의미합니다. 이름으로 보아 웹 서비스 캐시로 사용되는 프로덕션 클러스터일 가능성이 높습니다.
cluster:athena-prod-redis-auth2, cluster:athena-prod-redis-auth
두 클러스터 모두 2025년 4월에 $23.37의 비용이 발생했으며, 사용 시간은 각각 720시간으로 월 전체 시간과 일치합니다. athena-prod-redis-auth 관련 클러스터들은 프로덕션 환경에서 인증/권한 부여 관련 캐시로 사용될 가능성이 높습니다. 이들 역시 4월부터 비용이 발생했다는 점에서, RI 만료 후 온디맨드 전환의 영향을 받았을 수 있습니다.
cluster:athena-dev-redis-auth, cluster:web-session2
각각 2025년 4월에 $2.28의 비용이 발생했으며, 사용 시간은 각각 720시간으로 월 전체 시간과 일치합니다. dev 및 session 클러스터는 개발/테스트 환경이나 세션 관리용으로 사용될 수 있습니다. 비용이 상대적으로 낮지만, 720시간 사용되었다는 것은 해당 월 내내 가동되었다는 의미입니다.
이 계정의 ElastiCache 비용 구조를 분석한 결과, 예약 인스턴스(RI) 만료로 인한 온디맨드 요금 전환이 가장 시급하게 해결해야 할 비용 문제로 판단됩니다. 2025년 4월부터 cache.r6g.xlarge 및 cache.r6g.large 인스턴스의 RI가 만료되어 온디맨드 요금이 부과되고 있습니다. 이는 비용 효율성을 크게 저해하므로, 최대 70% 이상 할인되는 RI 또는 컴퓨트 Savings Plans 구매를 즉시 고려해야 합니다.
또한 지표상 드러나진 않지만 현재 사용 중인 r6g.xlarge 및 r6g.large 노드의 실제 캐시 히트율(Cache Hit Ratio)과 메모리 사용률을 모니터링하여 과도하게 큰 인스턴스 유형을 사용하고 있지 않은지 검토합니다. 실제 사용량에 맞춰 노드 인스턴스 크기를 줄이거나, 불필요한 복제 노드(replica)를 줄이는 것을 고려합니다.
Redis의 경우 INFO memory 명령이나 CloudWatch 지표(예: CacheHitRate, BytesUsedForCache)를 통해 캐시 효율성을 면밀히 분석합니다.
ElastiCache 자체 비용에는 데이터 전송 비용이 포함되지 않지만, ElastiCache 클라이언트(EC2, Lambda 등)가 캐시와 다른 AZ에 있을 경우 Cross-AZ 데이터 전송 비용이 발생할 수 있습니다.
CloudWatch 지표(NetworkBytesIn, NetworkBytesOut)를 통해 AZ 간 트래픽을 모니터링하고, 가능하다면 캐시 클라이언트와 ElastiCache 노드를 동일 AZ에 배치하여 불필요한 데이터 전송 비용을 최소화합니다. Redis 리더-리플리카 구성 시에도 AZ 분리를 통한 고가용성과 비용 효율성 간의 균형점을 찾아야 합니다.
결론
많은 팀이 Redis나 Memcached를 “성능 개선”용으로 도입합니다. 캐시 시스템도 결국 ‘리소스 소비자’입니다. 지속적으로 모니터링하지 않으면 성능의 이름으로 비용을 잠식합니다.
이 글을 통해 우리는 다음 사실을 명확히 확인했습니다.
예약 인스턴스가 만료된 순간, 비용은 2배 이상 뛰기 시작합니다.
캐시 노드는 설정해두고 잊기 쉽지만, 매시간 과금되고 있습니다.
Cross-AZ에 따른 전송 비용은 ElastiCache가 아니라 EC2에서 조용히 터지고 있습니다.
비용은 숫자지만, 그 뒤엔 의사결정의 흔적이 숨어 있습니다. ElastiCache 비용을 최적화한다는 것은, 곧 우리 조직이 리소스를 얼마나 민감하게 다루고 있는지를 증명하는 과정입니다.
RI 갱신, 인스턴스 리사이징, Cross-AZ 최적화, 캐시 효율성 점검은 모두 우리가 지금 당장 실행할 수 있는 ‘비용 행동 전략’입니다.
