본문 바로가기
서비스 운영 및 트러블슈팅

AWS ECR 비용이 계속 증가하는 이유와 절감 방법 정리 (Java + Spring Boot 운영 기준)

by collenkim 2026. 2. 12.
반응형

AWS 환경에서 Spring Boot 기반 서비스를 Docker로 운영하다 보면
어느 순간 ECR 스토리지 비용이 계속 증가하는 현상을 겪게 된다.

 

EC2, RDS는 모니터링하면서
ECR은 “이미지 저장소” 정도로 생각하고 방치하는 경우가 많다.

 

하지만 ECR은 저장된 이미지 용량(GB) 기준 과금 구조이기 때문에
운영 기간이 길어질수록 비용이 누적된다.

 

이 글에서는 Java(Spring Boot) 기반 서비스 운영 경험을 기준으로:

  • AWS ECR 비용이 증가하는 구조
  • 실제 운영에서 비용이 쌓이는 이유
  • Docker 이미지 최적화를 통한 절감 방법

을 정리한다.


AWS ECR 비용 과금 구조 이해

ECR 비용은 크게 두 가지다.

1. 스토리지 비용 (가장 큰 원인)

  • 저장된 Docker 이미지 용량 기준 과금
  • GB/월 단위로 청구

즉, 이미지가 많거나 크면 비용이 계속 증가한다.

2. 데이터 전송 비용

  • 다른 리전에서 Pull
  • 외부 네트워크 Pull

일반적인 ECS, EC2 내부 Pull 환경에서는
대부분 스토리지 비용이 문제다.


Java 기반 서비스에서 ECR 비용이 증가하는 이유

Spring Boot 기반 서비스는 기본적으로 이미지가 크다.

 

1. openjdk 기본 이미지 사용

FROM openjdk:17

 

이 이미지 하나만으로도 700MB 이상이다.

여기에 fat jar(100~200MB)까지 포함되면
이미지 크기는 쉽게 800MB를 넘는다.


2. Multi-stage Build 미적용

다음과 같은 Dockerfile은 실무에서 자주 보인다.

FROM gradle:8.5-jdk17

WORKDIR /app
COPY . .
RUN gradle build

CMD ["java","-jar","build/libs/app.jar"]

 

문제점:

  • Gradle 전체 포함
  • 빌드 캐시 포함
  • 테스트 코드 포함
  • 소스코드 전체 포함

결과적으로 불필요한 파일이 이미지에 들어간다.


3. Untagged 이미지 누적

CI/CD 자동 배포 시:

  • 매 빌드마다 새 이미지 push
  • 이전 이미지는 untagged 상태
  • Lifecycle Policy 미설정

결국 ECR Repository 용량이 계속 증가한다.


Java(Spring Boot) Docker 이미지 최적화 방법

이제 실제로 적용 가능한 방법을 정리한다.

 

1. Multi-stage Build 적용

개선된 Dockerfile 예제

# 1단계: 빌드
FROM gradle:8.5-jdk17-alpine AS builder

WORKDIR /build
COPY . .
RUN gradle clean build -x test


# 2단계: 실행
FROM amazoncorretto:17-alpine

WORKDIR /app
COPY --from=builder /build/build/libs/*.jar app.jar

EXPOSE 8080
ENTRYPOINT ["java","-jar","app.jar"]

 

효과:

  • 빌드 도구 제거
  • 소스코드 제거
  • jar 파일만 포함

실제 운영 기준
900MB → 250~300MB 수준 감소 가능


2. 경량 베이스 이미지 사용

비교:

  • openjdk:17 → 700MB 이상
  • amazoncorretto:17-alpine → 200~300MB

권장:

FROM amazoncorretto:17-alpine

 

AWS 환경에서는 Corretto 사용이 안정적이다.


3. dockerignore 필수 적용

Spring Boot 기준 예시:

.git
.gitignore
.gradle
build/
target/
logs/
*.log
Dockerfile
docker-compose.yml
README.md

 

이 설정을 하지 않으면
.git 히스토리, gradle 캐시 등이 이미지에 포함된다.


4. ECR Lifecycle Policy 설정

Repository → Lifecycle Policy

권장 설정:

  • 최근 10개 이미지만 유지
  • 30일 지난 untagged 이미지 삭제
  • dev, test 태그 자동 정리

이 설정 하나로도 스토리지 증가를 막을 수 있다.


실제 운영 적용 전후 예시

적용 전:

  • 평균 이미지 크기: 920MB
  • Repository 전체 용량: 30GB 이상
  • 비용 지속 증가

적용 후:

  • 평균 이미지 크기: 270MB
  • Repository 용량: 8~10GB 유지
  • 비용 증가세 중단

이미지 최적화는
ECR 비용 절감뿐 아니라 배포 속도 개선 효과도 있다.


결론

AWS ECR 비용이 계속 증가하는 가장 큰 이유는
Java 기반 Docker 이미지의 크기와 이미지 관리 부재다.

다음 3가지는 반드시 적용해야 한다.

  • Multi-stage Build
  • 경량 베이스 이미지 사용
  • Lifecycle Policy 설정

ECR은 사용량이 아니라
저장된 이미지 총 용량으로 과금된다는 점을 기억해야 한다.

반응형