비공개 서브넷에서 ECR 이미지 다운로드 비용을 줄이려면 ECR API·레지스트리 요청과 S3 이미지 레이어 다운로드를 나눠 봐야 합니다. NAT Gateway 하나를 ECR 엔드포인트 하나로 바꾸는 비교로 끝나지 않습니다. ECR 인터페이스 엔드포인트의 서비스·가용 영역별 유지 비용, S3 게이트웨이 경로, 아직 인터넷이 필요한 트래픽을 함께 계산합니다.
적용 범위는 같은 AWS 리전의 비공개 ECR 이미지와 IPv4 비공개 서브넷입니다. EC2 기반 ECS와 Linux Fargate 1.4.0 이상을 중심으로 설명합니다. 다른 플랫폼 버전·듀얼 스택·교차 리전·중앙 집중형 네트워크는 실제 지원 조건을 따로 확인해야 합니다. 가격 항목의 자료 기준일은 2026년 10월 14일이며 다음 날의 고정 요금이나 절감액을 보장하지 않습니다.
비교가 틀어지는 원인: 이미지가 ECR 한 경로에서만 온다고 생각하기
ECR API 호출과 Docker Registry 요청은 인터페이스 엔드포인트를 사용하고, 실제 이미지 레이어는 S3 경로가 필요합니다. ECR의 공식 문서는 EC2 기반 ECS와 Fargate 1.4.0 이상에 두 ECR 엔드포인트와 S3 게이트웨이 엔드포인트가 필요하다고 설명합니다. 레지스트리 인증은 되지만 레이어 다운로드가 멈추는 경우, S3 라우트와 정책을 별도로 확인해야 하는 이유입니다.
| 경로/항목 | NAT 중심 구성 | ECR·S3 엔드포인트 구성 |
| ECR API·레지스트리 | NAT를 거치는 AWS 서비스 요청 | ecr.api와 ecr.dkr 인터페이스 경로 |
| 이미지 레이어 | S3 다운로드도 NAT 처리량에 포함 가능 | 연결한 라우트 테이블의 S3 게이트웨이 경로 |
| 상시 비용 | NAT 유지 시간과 배치 가용 영역 확인 | 인터페이스 서비스별·가용 영역별 시간 확인 |
| 데이터 비용 | NAT 처리량과 전송 경로 | 인터페이스 처리량과 남아 있는 NAT·전송 경로 |
| 인터넷 요청 | 일반 인터넷 목적지 처리 가능 | 엔드포인트가 지원하지 않는 외부 목적지는 별도 출구 필요 |
1. 목적지별 트래픽을 나누고 NAT가 남는지 확인한다
이미지 pull 외에도 외부 API, 패키지 저장소, 공용 레지스트리, 로그 전송과 자격 증명 조회 등 목적지를 적습니다. ECR과 S3 경로만 바꿔도 나머지 인터넷 요청 때문에 NAT를 계속 유지해야 할 수 있습니다. 이 경우 NAT 상시 비용이 사라진다는 가정은 제외하고, 우회한 데이터 처리량과 새 엔드포인트 비용을 비교합니다. 서비스마다 필요한 엔드포인트를 무작정 전부 생성하지 않습니다.
이미지 크기에 배포 횟수만 곱한 값은 실제 네트워크 전송량과 다를 수 있습니다. 호스트의 레이어 캐시, 새 노드 수, 태스크 재배치, 재시도, 레이어 공유 여부를 확인합니다. 예측은 검증용 가정으로 구분하고 가능하면 청구·사용량 자료와 배포 시각을 대조합니다. 엔드포인트 도입으로 성능이나 다운로드 성공이 자동 보장되는 것도 아닙니다.
2. API·Registry·S3 세 경로를 각각 점검한다
같은 리전의 경로 예시 — 실행 명령이 아님
com.amazonaws.ap-northeast-2.ecr.api # ECR API
com.amazonaws.ap-northeast-2.ecr.dkr # Docker Registry
com.amazonaws.ap-northeast-2.s3 # S3 gateway endpoint인터페이스 엔드포인트는 실제 서브넷·가용 영역과 보안 그룹을 확인합니다. 클라이언트에서 필요한 HTTPS 접근이 허용되는지, VPC DNS 설정과 private DNS가 올바른 이름을 비공개 주소로 해석하는지 확인합니다. S3 게이트웨이 엔드포인트는 사용 중인 비공개 서브넷의 라우트 테이블에 연결됐는지가 핵심입니다. 엔드포인트를 생성했다는 사실과 해당 트래픽이 그 경로를 실제 사용한다는 사실은 구분합니다.
엔드포인트 정책과 작업 주체의 IAM 권한은 함께 작동합니다. 네트워크 연결이 정상이어도 ECR 읽기 권한이나 S3 레이어 접근 정책이 부족하면 실패합니다. 모든 정책을 허용으로 바꾸는 대신 실패 단계의 서비스·리소스·요청을 좁힙니다. 로그·시크릿 등 다른 AWS 서비스가 필요한 워크로드는 그 통신도 독립적으로 검토합니다.
3. 비용은 실제 유지 여부와 가용 영역 단위로 비교한다
NAT Gateway는 유지 시간, 처리 데이터, 관련 전송과 주소 비용을 구분합니다. 실제 선택한 NAT 유형의 가용 영역·배치 과금 단위도 공식 가격표에서 확인합니다. 인터페이스 엔드포인트는 서비스마다 각 가용 영역에 유지한 시간과 데이터 처리 비용이 있습니다. S3 게이트웨이 엔드포인트 자체는 추가 사용 요금이 없지만, S3 저장·요청 등의 서비스 비용까지 없어지는 것은 아닙니다.
비교 입력표 — 금액을 넣기 전 필요한 관측값
기존: NAT 유형 / 유지 시간 / 처리 GB / AZ·전송 경로
추가: ecr.api·ecr.dkr 각각의 AZ 수 / 유지 시간 / 처리 GB
잔존: 외부 API·패키지·기타 AWS 요청의 NAT 사용량
검증: S3 레이어가 실제 선택한 라우트 테이블로 이동하는가여러 서비스의 엔드포인트를 여러 가용 영역에 만들면 시간 비용이 누적됩니다. 반대로 이미지 레이어 전송량이 큰 환경은 S3 경로 전환의 영향을 별도로 볼 가치가 있습니다. 어느 쪽이 더 싸다는 결론은 리전·전송량·가용성 요구·NAT 유지 여부를 입력한 뒤 내립니다. 단일 가용 영역만 써서 비용을 낮출지 결정할 때는 장애 영향도 같이 판단합니다.
도입 검증과 NAT 제거 전 주의사항
먼저 비운영 서브넷에서 새 태스크를 시작해 인증·매니페스트·레이어·앱 기동·로그·외부 호출을 순서대로 관찰합니다. 기존 캐시 때문에 실패 경로가 가려지지 않도록 새 실행 환경에서 확인하되, 운영 호스트의 이미지를 무작정 지우지는 않습니다. 새 경로에 문제가 있으면 보존한 라우트·DNS·정책으로 필요한 부분만 복구합니다. 운영 NAT 삭제는 전체 외부 통신 검증 뒤 별도 변경으로 취급합니다.
ECR pull through cache의 최초 가져오기는 공식 문서상 NAT 등 인터넷 경로가 필요한 예외가 있습니다. Windows 이미지의 foreign layer처럼 외부 레이어를 가져오는 조건도 다릅니다. 이 글의 일반 비공개 ECR Linux 이미지 조건을 이 예외에 그대로 적용하지 않습니다. S3 게이트웨이 경로 추가 시 기존 연결 영향도 있으므로 변경 창과 재시도 동작을 검토합니다.
FAQ
ECR 엔드포인트가 있으면 NAT를 삭제해도 되나요? S3 레이어와 다른 인터넷 목적지를 모두 확인한 뒤 판단합니다. ECR 구성만으로 일반 인터넷 접속을 대신할 수 없습니다.
S3 게이트웨이 엔드포인트를 만들었는데 변화가 없나요? 실제 사용하는 서브넷의 라우트 테이블 연결과 정책을 확인합니다. 생성한 리소스의 존재만으로 경로 변경을 확정하지 않습니다.
엔드포인트 방식은 항상 저렴한가요? 아닙니다. 유지하는 서비스·가용 영역 수와 데이터량, 남는 NAT 비용에 따라 다릅니다. 실제 관측값으로 비교합니다.
공식 출처와 관련 글
공식 자료 확인일은 2026년 10월 14일입니다. 아래 예시는 문서로 검토한 설정·진단 절차이며 운영 계정이나 서버에서 직접 실행한 결과가 아닙니다. 발행일의 가격이나 실제 성능을 확정하지 않습니다.
Amazon ECR: 인터페이스 엔드포인트와 S3 이미지 레이어 경로
함께 확인하면 좋은 글: ImagePullBackOff의 이미지·권한·네트워크 분기
'소프트웨어개발' 카테고리의 다른 글
| Nginx 정적 파일 404 해결: root·alias 경로와 try_files 점검 순서 (0) | 2026.10.15 |
|---|---|
| Secrets Manager와 Parameter Store 비교: DB 비밀번호 회전·설정값·조회 비용 선택 (0) | 2026.10.15 |
| systemd 203/EXEC 해결: 실행 경로·권한·shebang·noexec 점검 순서 (0) | 2026.10.14 |
