Amazon ECR (Elastic Container Registry)
AWS에서 제공하는 완전 관리형 컨테이너 이미지 레지스트리. Docker Hub처럼 컨테이너 이미지를 저장하고 관리하지만, AWS 서비스들과 긴밀하게 통합되어 있어 EKS나 ECS 같은 서비스에서 자연스럽게 사용할 수 있음
ECR이란?
기본 개념
Docker 이미지를 저장하는 Private 레지스트리 서비스. 애플리케이션을 컨테이너화한 후 이미지를 ECR에 Push하고, EKS, ECS, Fargate 같은 컴퓨팅 서비스에서 이 이미지를 Pull하여 실행하는 방식으로 동작. Docker Hub가 Public 중심이라면, ECR은 기본적으로 Private하며 IAM 기반의 세밀한 권한 제어가 가능한 것이 큰 차이점
Docker Hub vs ECR 비교:
| 구분 | Docker Hub | ECR |
|------|-----------|-----|
| 관리 주체 | Docker Inc. | AWS |
| 기본 접근성 | Public (Private 유료) | Private (기본) |
| 인증 방식 | Docker 계정 | AWS IAM |
| 비용 구조 | Free tier 제한적 | 저장 용량 + 전송량 과금 |
| AWS 통합 | 별도 설정 필요 | 네이티브 통합 |
| 보안 스캔 | 유료 플랜 | 기본 제공 |
주요 기능
Private Repository
ECR의 가장 기본적인 특징은 모든 이미지가 기본적으로 비공개로 저장된다는 점. IAM 권한이 있는 사용자와 서비스만 이미지에 접근할 수 있어서, 회사의 소스 코드나 설정이 담긴 이미지를 안전하게 관리 가능. 오픈소스 프로젝트를 위한 Public ECR도 별도로 제공되지만, 대부분의 기업 환경에서는 Private Repository를 사용
이미지 스캔
이미지를 Push하거나 수동으로 요청하면 보안 취약점을 자동으로 검사해주는 기능. CVE (Common Vulnerabilities and Exposures) 데이터베이스와 비교하여 알려진 보안 취약점이 있는지 확인하고, 심각도별로 분류하여 보고서 제공. Basic Scanning은 Clair 엔진을 사용하며 무료이고, Enhanced Scanning은 Amazon Inspector를 사용하여 더 정확하고 빠른 결과를 제공하지만 추가 비용 발생
스캔 결과 활용:
스캔에서 발견된 취약점을 CI/CD 파이프라인에서 체크하여 심각한 취약점이 있으면 배포를 차단하는 정책을 구현할 수 있음. 예를 들어 CRITICAL 등급 취약점이 발견되면 자동으로 빌드를 실패시키고, 개발자에게 알림을 보내는 방식으로 보안 강화 가능
이미지 암호화
ECR에 저장되는 모든 이미지는 저장 시점에 자동으로 AES-256으로 암호화됨. 추가로 AWS KMS를 사용한 고객 관리형 키로 암호화할 수도 있어서, 금융이나 의료 같은 규정 준수가 중요한 산업에서도 안심하고 사용 가능. 전송 중에는 TLS로 암호화되므로 전체 데이터 라이프사이클에서 보안이 보장됨
수명 주기 정책
시간이 지나면서 쌓이는 오래된 이미지를 자동으로 삭제하여 스토리지 비용을 절감할 수 있는 기능. 규칙 기반으로 동작하며, 예를 들어 "최근 10개 이미지만 유지하고 나머지는 삭제" 또는 "30일 이상 된 untagged 이미지 삭제" 같은 정책을 설정 가능. 프로덕션 이미지나 특정 태그 패턴(예: prod-, v1.)은 보존하고, 개발용 이미지만 주기적으로 정리하는 세밀한 전략도 구현 가능
일반적인 정책 패턴:
개발 환경에서는 최근 5-10개 이미지만 유지하고, 프로덕션 환경에서는 모든 버전을 보존하거나 1년 이상 된 것만 삭제하는 식으로 환경별로 다른 정책을 적용하는 것이 일반적. untagged 이미지(빌드 중간 단계 레이어)는 7-14일 후 삭제하여 불필요한 비용 발생을 방지
ECR 사용 흐름
Repository 생성
ECR을 사용하려면 먼저 이미지를 저장할 Repository를 생성해야 함. 보통 애플리케이션이나 마이크로서비스 단위로 Repository를 하나씩 만들며, 생성 시 이미지 스캔 설정이나 암호화 방식을 지정할 수 있음. Repository가 생성되면 AWS 계정 ID와 리전이 포함된 고유한 URI가 할당되는데, 이 URI를 통해 이미지를 Push하고 Pull함
Repository URI 구조:
123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/myapp 형태로, 앞부분이 AWS 계정 ID, 중간에 리전 정보, 마지막이 Repository 이름으로 구성됨. 이 전체 주소가 Docker 이미지의 레지스트리 주소가 되어 Docker 명령어에서 사용됨
Docker 로그인
ECR은 IAM 기반 인증을 사용하므로, Docker CLI로 이미지를 Push하거나 Pull하기 전에 먼저 로그인 과정이 필요. AWS CLI를 통해 로그인 토큰을 받아서 Docker에 전달하는 방식으로 동작하며, 이 토큰은 12시간 동안 유효함. CI/CD 파이프라인에서는 매번 빌드 시작 시 새로 로그인하는 것이 일반적이며, IAM에서 ecr:GetAuthorizationToken 권한이 필요
이미지 Push
로컬에서 빌드한 Docker 이미지에 ECR Repository URI를 태그로 추가한 후 Push하면 ECR에 이미지가 업로드됨. Docker는 이미지를 여러 레이어로 나누어 저장하는데, 이미 존재하는 레이어는 다시 업로드하지 않아서 효율적. 태그 전략은 팀마다 다르지만, Git 커밋 해시, 빌드 번호, 시맨틱 버전, 환경 이름 등을 조합하여 사용하는 것이 일반적
태그 전략 예시:
개발 환경에서는 dev-abc123 같이 브랜치와 커밋 해시를 조합하고, 스테이징은 staging-v1.2.3, 프로덕션은 prod-v1.2.3 또는 v1.2.3 처럼 명확한 버전 번호를 사용. latest 태그는 항상 최신 빌드를 가리키도록 하되, 프로덕션 배포에서는 명시적인 버전 태그를 사용하는 것이 안전
이미지 Pull
EKS나 ECS에서 컨테이너를 실행할 때는 ECR에서 이미지를 자동으로 Pull함. Kubernetes Deployment나 ECS Task Definition에 ECR 이미지 URI를 명시하면, 컴퓨팅 서비스가 알아서 인증하고 이미지를 가져와서 실행. 이때 IAM 권한이 필요한데, EKS에서는 IRSA (IAM Roles for Service Accounts)를 사용하면 Pod별로 세밀한 권한 제어 가능
IAM 권한 설정
기본 권한 구조
ECR 접근을 위해서는 두 가지 레벨의 권한이 필요. 첫 번째는 ECR 서비스 자체에 로그인하기 위한 GetAuthorizationToken 권한이고, 두 번째는 특정 Repository에 대한 읽기 또는 쓰기 권한. 전자는 리소스 제한 없이 전역으로 부여되고, 후자는 특정 Repository ARN에 대해 부여됨
권한의 실제 의미:
BatchCheckLayerAvailability는 이미지 레이어가 이미 존재하는지 확인하는 권한으로, 중복 업로드를 방지하기 위해 필요. GetDownloadUrlForLayer는 실제 이미지 레이어를 다운로드할 수 있는 S3 presigned URL을 받기 위한 권한이며, BatchGetImage는 이미지 메타데이터(매니페스트)를 조회하는 권한. 이 세 가지는 이미지를 Pull할 때 반드시 필요한 기본 권한
Push 권한
이미지를 ECR에 업로드하려면 추가로 PutImage, InitiateLayerUpload, UploadLayerPart, CompleteLayerUpload 권한이 필요. 이름에서 알 수 있듯이 멀티파트 업로드 방식으로 동작하며, 큰 이미지를 효율적으로 업로드하기 위한 메커니즘. 보안상 개발자 개인에게는 Pull 권한만 주고, CI/CD 파이프라인에만 Push 권한을 부여하는 것이 일반적
EKS에서 ECR 접근
EKS 환경에서 ECR 이미지를 사용하는 방법은 크게 두 가지. 전통적인 방식은 노드의 IAM Role에 ECR 권한을 부여하는 것인데, 이 경우 해당 노드의 모든 Pod가 동일한 권한을 가지게 되어 보안상 권장되지 않음. 더 나은 방법은 IRSA를 사용하여 ServiceAccount별로 다른 IAM Role을 연결하는 것으로, Pod마다 필요한 최소 권한만 부여 가능
CI/CD 통합
GitHub Actions 연동
GitHub Actions에서 ECR을 사용할 때는 AWS 자격증명 설정, ECR 로그인, 이미지 빌드 및 Push 순서로 진행. aws-actions/configure-aws-credentials 액션으로 AWS 인증을 처리하고, aws-actions/amazon-ecr-login 액션으로 Docker 로그인을 자동화할 수 있음. 이미지 태그로는 Git SHA를 사용하면 커밋 단위로 추적 가능하고, 시맨틱 버전을 사용하면 릴리스 관리가 명확해짐
GitLab CI 연동
GitLab CI에서는 Docker-in-Docker 방식으로 이미지를 빌드하는 것이 일반적. AWS CLI를 설치하고 ECR 로그인 토큰을 받아서 Docker 로그인을 수행한 후, 이미지를 빌드하고 Push. GitLab CI 변수로 AWS 자격증명을 관리하며, Protected Variables를 사용하면 프로덕션 브랜치에서만 배포 가능하도록 제한 가능
EKS에서 ECR 이미지 사용
Deployment 설정
Kubernetes Deployment에서 ECR 이미지를 사용할 때는 전체 ECR URI를 이미지 이름으로 지정해야 함. Docker Hub처럼 짧은 이름으로는 사용할 수 없으며, 계정 ID와 리전이 포함된 전체 주소가 필요. 이미지 태그는 가능한 한 명시적으로 지정하는 것이 좋은데, latest 태그는 예상치 못한 변경을 초래할 수 있기 때문
ServiceAccount 연결:
IRSA를 사용하면 Deployment의 Pod가 자동으로 ECR에 접근 가능. ServiceAccount에 IAM Role ARN을 annotation으로 추가하면, kubelet이 자동으로 임시 자격증명을 발급받아서 ECR 인증에 사용. 이 방식이 ImagePullSecrets보다 훨씬 안전하고 관리가 편함
ImagePullSecrets 방식
IRSA를 사용하지 않는 환경에서는 ImagePullSecrets로 ECR 인증 정보를 제공해야 함. ECR 로그인 토큰을 Kubernetes Secret으로 생성하고, Pod에서 이 Secret을 참조하는 방식. 하지만 ECR 토큰이 12시간마다 만료되므로 CronJob으로 주기적으로 Secret을 갱신해야 하는 번거로움이 있어서, 가능하면 IRSA를 사용하는 것이 권장됨
비용 최적화
스토리지 비용 관리
ECR의 주요 비용은 이미지 저장 용량으로, GB당 월 $0.10 정도. 오래된 이미지가 계속 쌓이면 비용이 늘어나므로, 수명 주기 정책으로 불필요한 이미지를 자동 삭제하는 것이 중요. 특히 CI/CD에서 생성되는 개발용 이미지나 중간 빌드 산출물은 빠르게 삭제하고, 프로덕션 이미지만 장기 보관하는 전략이 효과적
데이터 전송 비용
ECR에서 이미지를 Pull할 때 데이터 전송 비용이 발생할 수 있는데, 같은 리전 내에서는 무료이므로 ECR과 EKS를 동일한 리전에 배치하는 것이 중요. 다른 리전이나 인터넷으로 전송할 때는 GB당 과금되므로, VPC 엔드포인트를 사용하여 인터넷을 경유하지 않고 AWS 내부 네트워크로만 통신하도록 설정하면 비용 절감 가능
이미지 크기 최적화:
Multi-stage build를 사용하여 최종 이미지에 빌드 도구나 소스 코드를 포함시키지 않으면 이미지 크기를 크게 줄일 수 있음. Alpine Linux 같은 경량 베이스 이미지를 사용하는 것도 효과적이며, 불필요한 패키지나 캐시 파일을 정리하는 것도 중요. 이미지가 작아지면 저장 비용뿐만 아니라 전송 비용과 배포 시간도 줄어듦
