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은 사용량이 아니라
저장된 이미지 총 용량으로 과금된다는 점을 기억해야 한다.
'서비스 운영 및 트러블슈팅' 카테고리의 다른 글
| NCP MariaDB → MySQL 서버리스 전환 시 ANSI 표준 쿼리 문제와 마이그레이션 고려사항 (0) | 2026.02.20 |
|---|---|
| Docker 서비스 업그레이드 시 데이터 유지 전략: 볼륨과 설정 관리 (0) | 2026.02.19 |
| SAP JCo NoClassDefFoundError 해결 방법 (0) | 2026.02.03 |
| Tomcat 레거시 구조의 위험성 | JVM(PID) 공유로 발생한 서비스 장애 사례 (0) | 2026.01.29 |
| AWS Client TLS Negotiation Error 원인 분석 및 해결 (0) | 2025.12.01 |