개발/infra

[infra/terraform] ECR이란?

2ivii 2025. 11. 21. 11:08

지난 글에서는 EC2 / ECS / Fargate가 어떤 차이인지 알아봤다.
이제 실제로 컨테이너를 “어디에서 가져와서 실행하냐?”라는 질문이 생긴다. 그게 바로 ECR이다!

도커 배포 과정에서 가장 많이 등장하는 단어이니 정확히 개념을 잡아두면 전체적 흐름을 이해하는 속도가 훨씬 빨라진다.

ECR이란?

“ECR = AWS가 제공하는 Docker 이미지 저장소(레지스트리)”이다. 도커 이미지를 올려두는 전용 GitHub 같은 공간이라고 생각하면 된다.

 

ECR을 쓰는 이유는 아주 간단하다:

  • ECS / Fargate가 이미지를 ECR에서 가져다가 실행하기 때문
  • AWS 내부망에서 pull → 속도 빠르고 안정적
  • IAM 기반으로 보안 제어하기 쉬움
  • CI/CD(GitHub Actions)와 연동하기 쉬움

즉, 배포에서 “이미지 저장” 역할을 담당하는 애다.

 

도커 이미지를 저장하는 곳은 사실 여러 개가 있다.

아래 표로 살펴보자.

Docker Hub 공용, 무료/유료 모두 있고 속도가 느릴 때가 있음
GitHub Container Registry GitHub 기반, 편하지만 AWS 내부에서 pull하려면 네트워크 비용 생김
ECR AWS 내부에서 pull → 빠름 + 보안 강함 + ECS와 궁합 최고

이러한 이유때문에 실무에서 AWS ECS/Fargate 쓰면 거의 ECR을 사용한다고 한다!

 

ECR 기본 구조

 

ECR은 이렇게 생겼다:

ECR(도커 이미지 저장소)
 ┗━ dev-repo (리포지토리)
      ┣━ latest (태그)
      ┣━ a73bc91 (커밋 기반 태그)
      ┗━ 2024-11-21T… (배포 시간 기반 태그)

리포지토리 하나는 하나의 서비스(백엔드·AI 서버 등) 를 위한 이미지 모음이다.

예를 들어:

  • 백엔드 → dev-repo
  • AI 서버 → ai-repo
  • 프론트엔드 SSR → web-repo

이런 식으로 하나씩 만든다.

GitHub Actions -> ECR push 과정

이게 실제 배포의 핵심이다. 흐름은 이렇다.

 

① GitHub Actions가 Docker 이미지 빌드

 

예:

docker build -t gitfit-dev-repo:latest .

 

② ECR에 로그인

aws ecr get-login-password | docker login ...

 

③ ECR로 push

docker push 935194211812.dkr.ecr.ap-northeast-2.amazonaws.com/gitfit-dev-repo:latest

 

이렇게 ECR에 올려두면
ECS / Fargate가 이 이미지를 가져다가 실행하는 것이다.

 

즉,

GitHub Actions는 “이미지를 만들고 ECR에 맡기는 역할”

ECS(Fargate)는 “ECR에서 이미지를 가져다가 실행하는 역할”

이라고 생각하면 된다.

 

배포 전체 흐름을 다시 보면:

개발자가 push →
GitHub Actions 실행 →
Docker 이미지 생성 →
ECR에 업로드 →
ECS(Fargate)가 이미지 가져감 →
컨테이너 실행 →
ALB가 라우팅

 

여기서 “이미지 저장소” 단계가 없으면ECS는 뭘 가져다가 실행할 수가 없다.

ECR은 바로 이 자리를 담당한다.

 

이 중에서 ‘이미지 저장소(ECR)’ 단계가 없다면 ECS/Fargate는 실행할 이미지를 가져올 수 없다.
즉, ECR은 배포 흐름의 중심에 있는 필수 연결고리다.

 

조금 더 내부 동작을 살펴보면:

  1. GitHub Actions가 새 Docker 이미지를 빌드하고, ECR에 push한다.
  2. 그 후 ECS 서비스에서 force-new-deployment를 실행하면,
  3. ECS는 새로운 Task Definition을 적용하고,
  4. Fargate에게 “새 이미지로 컨테이너 띄워줘”라고 요청한다.
  5. Fargate는 ECR에서 이미지를 pull하여 컨테이너를 실행한다.
  6. ALB는 /actuator/health로 헬스체크 후 정상일 때만 트래픽을 보낸다.

즉, Actions → ECR → ECS(Fargate) → 컨테이너 실행 → ALB 라우팅

이 전체 구조가 “AWS 컨테이너 배포 파이프라인”이며,
여기서 ECR은 없어서는 안 되는 핵심 역할을 담당한다.

 

실무에서 쓰는 태그 전략

 

실제 회사들은 이미지를 이렇게 태그를 사용해서 관리한다. 태그는 같은 이미지의 ‘버전 스티커’ 같은 것으로, 태그가 없다면 이미지 버전 구분이 매우 어렵다! 그래서 태그를 붙이면, 어떤 이미지를 ECS가 pull해야 하는지 명확히 알 수 있다.

 

이런식으로 태그를 사용한다.

gitfit-backend:latest        → 가장 최근
gitfit-backend:abc1234       → abc1234 커밋 기반 (재현 가능)
gitfit-backend:prod-2024-11-21 → 릴리즈 날짜 버전

 

자주 쓰는 태그는 아래와 같다

 

1) latest

  • 가장 최신 빌드가 여기로 덮어씌워짐
  • ECS 서비스는 보통 latest를 기본 pull

2) ${GITHUB_SHA}

  • GitHub Actions에서 자동으로 들어가는 커밋 해시값

이 태그를 쓰면 “정확히 어떤 커밋 기반 이미지인지 100% 재현 가능”하기에 문제 생기면 해당 SHA 태그만 ECS에 배포해서 바로 롤백 가능하다. 실무에서 진짜 가장 중요한 태그다.

 

3) 릴리즈 버전 태그 (prod-2024-11-21)

  • 특정 릴리즈 단위로 안정 버전을 따로 태그함
  • 실무에서 “운영 릴리즈 관리”할 때 자주 씀

 

실무에서는 latest만 쓰는 건 위험하다. 
→ 문제 생기면 어떤 버전인지 모르고 복구 불가

 

그렇다해서 SHA만 쓰면 매번 태그가 달라서 자동 업그레이드 불편
→ 항상 버전 명시해야 함

 

그래서 둘 다 쓰는게 최고이다.

마무리

ECR은 AWS에서 도커 이미지를 안전하게 저장하는 전용 레지스트리다.

  • GitHub Actions는 이미지를 ECR로 보내고
  • ECS/Fargate는 ECR에서 이미지를 가져가 실행한다

즉, ECR은 AWS 배포 파이프라인의 중심에 있는 “이미지 보관 창고” 역할이다. 이걸 이해하면 GitHub Actions, ECS, Fargate의 연결 구조가 단번에 정리된다!