AWS Section 16. ECS, ECR 및 Fargate

❓ Docker란?

Docker는 소프트웨어 개발 플랫폼으로, 애플리케이션을 컨테이너로 패키징하여 배포하는 기술이다.
컨테이너는 애플리케이션이 실행될 환경을 모두 포함하고 있기 때문에, 어디에서 실행하든 동일한 결과를 보장한다.
이는 호환성 문제를 없애고, 예측 가능한 동작을 제공하여 개발자가 배포와 유지 관리에 소요되는 시간을 줄여준다.
또한, Docker는 모든 운영체제(OS)에서 동일한 방식으로 실행되며, 언어, 운영체제, 기술에 구애받지 않고 사용할 수 있다.
Use case: 마이크로서비스 아키텍처, 리프트 앤 시프트(Lift-and-Shift) 전략으로 온프레미스에서 클라우드로 애플리케이션을 마이그레이션하는 상황에서 자주 사용된다.

🦾 Docker는 운영체제에서 어떻게 작동하는가?

Docker는 운영체제에서 Docker 데몬(Docker Daemon)이라는 백그라운드 프로세스를 통해 컨테이너를 관리하고 실행한다.
예를 들어, EC2 인스턴스 또는 다른 서버에서 Docker를 실행하면, 여러 개의 컨테이너를 동시에 실행할 수 있다.
각 컨테이너는 독립적인 애플리케이션과 관련된 모든 실행 환경을 가지고 있어, 서로 간섭 없이 실행된다.
예시로 Java, Node.js, MySQL 등 다양한 기술을 사용하는 컨테이너들이 하나의 서버에서 동시에 실행될 수 있다.

Java와 Node.js 애플리케이션을 Docker 컨테이너로 서버에 배포하고, 여러 컨테이너가 동시에 실행되는 과정

이는 서버 리소스를 효율적으로 활용하고, 서로 다른 애플리케이션들이 안정적으로 동작하도록 보장한다.

💾 Docker 이미지 저장소

Docker 이미지는 애플리케이션이 실행될 환경을 포함한 상태로 패키징된 파일이다.
Docker 이미지는 Docker 리포지토리에 저장되며, 이는 Docker Hub 또는 Amazon ECR과 같은 퍼블릭 또는 프라이빗 리포지토리다.
Docker Hub는 가장 널리 사용되는 퍼블릭 리포지토리로, 다양한 OS나 애플리케이션에 맞는 베이스 이미지를 찾을 수 있다.
Amazon ECR(Elastic Container Registry)은 프라이빗 리포지토리로, 보안이 중요한 애플리케이션 이미지를 저장할 수 있으며, Amazon ECR Public Gallery를 통해 퍼블릭 이미지도 관리할 수 있다.

🆚 Docker와 가상 머신의 차이점

Docker는 가상화 기술과 비슷한 면이 있지만, 완전한 가상화 기술은 X
Docker는 호스트 운영체제의 자원을 공유하는 반면, 가상 머신(VM)은 하이퍼바이저(Hypervisor) 위에서 독립된 운영체제를 실행한다.
가상 머신에서는 각 애플리케이션이 게스트 운영체제(Guest OS)를 가지고 있어 무겁고 자원을 많이 소비한다.
반면, Docker는 경량 컨테이너를 사용해 호스트 운영체제의 자원을 공유하면서 여러 컨테이너를 동시에 실행할 수 있어 리소스 효율성이 뛰어나다.
그러나 가상 머신에 비해 보안성이 조금 낮을 수 있습니다. Docker는 자원을 공유하기 때문에, 여러 컨테이너 간의 분리와 보안이 완벽하지 않을 수 있다.

🆕 Docker 시작하기

Dockerfile 작성에서 Docker 이미지를 빌드하고, 이를 리포지토리에 푸시한 후 컨테이너로 실행

Docker를 사용하려면 먼저 Dockerfile을 작성해야 한다. Dockerfile은 베이스 이미지와 설치할 파일 또는 설정을 정의하는 파일이다.
Dockerfile을 작성한 후, 이를 사용해 Docker 이미지를 빌드할 수 있다.
빌드된 이미지는 Docker Hub 또는 Amazon ECR과 같은 Docker 리포지토리에 푸시할 수 있으며, 나중에 이를 다시 가져와 실행할 수 있다.
가져온 Docker 이미지를 실행하면 Docker 컨테이너가 생성되고, 이 컨테이너 내에서 애플리케이션이 동작하게 된다.
그림 위치: Docker 이미지 생성과 실행 과정을 설명하는 다섯 번째 슬라이드의 다이어그램을 삽입.

👩🏻‍💼 AWS에서 Docker 컨테이너 관리

AWS는 Docker 컨테이너를 관리하기 위한 여러 서비스들을 제공한다.

Amazon ECS(Elastic Container Service)
- Amazon에서 제공하는 컨테이너 관리 서비스로, Docker 컨테이너를 효율적으로 관리할 수 있는 플랫폼
Amazon EKS(Elastic Kubernetes Service)
- 오픈 소스 컨테이너 관리 도구인 Kubernetes를 AWS에서 관리형으로 제공하는 서비스.
AWS Fargate
- 서버리스 컨테이너 관리 서비스로, ECS와 EKS 모두에서 서버 인프라를 직접 관리할 필요 없이 컨테이너를 실행할 수 있는 플랫폼
Amazon ECR
- Docker 이미지를 저장하고 관리할 수 있는 컨테이너 이미지 저장소 서비스

📌 ECS

Amazon ECS - EC2 시작 유형

각 EC2 인스턴스에 ECS 에이전트가 설치되어 Docker 컨테이너가 배포되고 관리되는 과정

Amazon ECS는 Elastic Container Service로, Docker 컨테이너를 ECS 클러스터에서 실행한다.
EC2 시작 유형은 인프라를 사용자가 직접 프로비저닝하고 관리해야 합니다. 즉, 사용자가 여러 EC2 인스턴스를 준비하여 ECS 클러스터에 연결해야 한다.
각 EC2 인스턴스는 ECS 에이전트를 실행하여 ECS 클러스터에 등록된다. 이때, AWS는 자동으로 컨테이너를 시작 및 중지하지만, 인프라 관리는 사용자가 직접 해야 한다.
새로운 Docker 컨테이너는 EC2 인스턴스들에 배포되며, 각 인스턴스에 있는 ECS 에이전트를 통해 클러스터에서 관리된다.

💡 Amazon ECS - Fargate 시작 유형

Fargate는 AWS에서 제공하는 완전한 서버리스 방식의 컨테이너 실행 서비스
인프라를 직접 프로비저닝하거나 관리할 필요가 없으며, EC2 인스턴스를 관리하지 않는다.
사용자는 단순히 ECS 태스크 정의만 하면 되고, AWS는 이를 바탕으로 필요한 CPU와 메모리 자원을 자동으로 할당하여 ECS 태스크를 실행한다.
Fargate의 큰 장점은 확장성이 뛰어나다는 것!! 태스크의 수만 증가시키면 쉽게 확장할 수 있으며, 이를 위해 EC2 인스턴스를 추가할 필요가 없다.

Fargate에서는 EC2 인스턴스를 관리하지 않고, AWS가 백엔드에서 자동으로 ECS 태스크를 실행하는 과정

💡 Amazon ECS - IAM 역할

EC2 인스턴스 프로필은 EC2 시작 유형에서만 사용되며, ECS 에이전트에 의해 활용된다.
이 프로필을 통해 ECS 서비스와 통신하고, ECR에서 Docker 이미지를 가져오거나, CloudWatch Logs에 로그를 전송할 수 있다.
ECS 태스크 역할은 태스크가 실행될 때 적용되며, 서로 다른 서비스에 대한 권한을 태스크별로 정의할 수 있다. 예를 들어, 하나의 태스크는 S3에, 다른 태스크는 DynamoDB에 접근할 수 있다.
이 역할들은 태스크 정의에서 설정된다.

Amazon ECS는 Elastic Container Service로, Docker 컨테이너를 ECS 클러스터에서 실행한다.
EC2 시작 유형은 인프라를 사용자가 직접 프로비저닝하고 관리해야 합니다. 즉, 사용자가 여러 EC2 인스턴스를 준비하여 ECS 클러스터에 연결해야 한다.
각 EC2 인스턴스는 ECS 에이전트를 실행하여 ECS 클러스터에 등록된다. 이때, AWS는 자동으로 컨테이너를 시작 및 중지하지만, 인프라 관리는 사용자가 직접 해야 한다.
새로운 Docker 컨테이너는 EC2 인스턴스들에 배포되며, 각 인스턴스에 있는 ECS 에이전트를 통해 클러스터에서 관리된다.

💡 Amazon ECS - 로드 밸런서 통합

애플리케이션 로드 밸런서(ALB)는 대부분의 ECS 활용 사례에서 사용되며, HTTP 및 HTTPS 요청을 ECS 태스크로 분산시킨다.
네트워크 로드 밸런서(NLB)는 높은 성능이 요구되거나 PrivateLink와 같은 특정 요구사항을 처리할 때 권장된다.
클래식 로드 밸런서도 지원되지만, 고급 기능이 없고 Fargate와 함께 사용할 수 없기 때문에 권장되지 않는다.

ALB가 사용자 요청을 받아 ECS 클러스터의 여러 태스크로 트래픽을 분산하는 과정

💡 Amazon ECS - EFS를 통한 데이터 지속성

Amazon EFS(Elastic File System)는 ECS 태스크에 파일 시스템을 마운트할 수 있는 네트워크 파일 시스템이다.
EFS는 EC2 시작 유형과 Fargate 시작 유형 모두에서 사용할 수 있으며, 다중 가용 영역(AZ)에 걸쳐 데이터를 공유할 수 있다.
Fargate와 EFS의 조합은 완전한 서버리스 방식의 지속 가능한 스토리지를 제공하여, 관리 부담을 줄이고, 사용량에 따른 요금만 청구된다.
Use case: 여러 AZ에 걸쳐 실행되는 컨테이너에서 데이터를 공유해야 할 때 사용된다.

EFS 파일 시스템이 ECS 클러스터의 여러 태스크에 마운트되어 데이터를 공유하는 과정

💡 ECS 서비스 자동 확장(Auto Scaling)

Amazon ECS에서는 자동 확장(Auto Scaling) 기능을 통해 서비스의 ECS 태스크 수를 자동으로 증가시키거나 감소시킬 수 있다.
자동 확장은 AWS 애플리케이션 자동 확장 기능을 사용하여 설정되며, 세 가지 주요 지표에 따라 스케일링을 할 수 있다:
- CPU 사용률: ECS 서비스의 평균 CPU 사용률이 증가할 때 태스크 수를 확장한다.
- 메모리 사용률: RAM 사용량에 따라 확장할 수 있다.
- ALB 타겟당 요청 수: 애플리케이션 로드 밸런서(ALB)의 타겟당 요청 수에 따라 스케일링이 이루어진다.
자동 확장의 세 가지 주요 방식
- Target Tracking: 특정 CloudWatch 메트릭에 맞춘 타겟 값으로 스케일링.
- Step Scaling: 설정된 CloudWatch 알람에 따라 단계적으로 스케일링.
- Scheduled Scaling: 미리 설정된 날짜와 시간에 따라 스케일링.

💡 EC2 시작 유형 - EC2 인스턴스 자동 확장

EC2 시작 유형을 사용하는 경우, 오토 스케일링 그룹(ASG)을 통해 ECS 태스크를 실행할 EC2 인스턴스를 자동으로 확장할 수 있다.
ASG는 CPU 사용률에 따라 EC2 인스턴스 수를 증가시키고, 인프라를 자동으로 확장한다.
ECS 클러스터 용량 공급자(Capacity Provider)를 통해 더 지능적으로 ECS 태스크가 실행될 인프라를 확장할 수 있다.
용량 공급자는 ASG와 연동하여, 태스크 실행을 위한 리소스가 부족할 때 EC2 인스턴스를 자동으로 추가한다.

💡 ECS 서비스의 CPU 사용량 기반 확장 예시

서비스 A의 CPU 사용량이 증가하여 새로운 태스크가 자동으로 추가되는 과정 / EC2 시작 유형에서는 EC2 인스턴스가 추가되는 과정

ECS 서비스의 CPU 사용량이 증가할 때 CloudWatch 메트릭이 이를 감지하고, CloudWatch 알람이 트리거된다.
CloudWatch 알람이 ECS 오토 스케일링을 트리거하여 ECS 서비스의 희망 태스크 수(desired task count)가 증가하게 된다.
추가적인 태스크가 자동으로 생성되며, CPU 사용률이 감소할 때까지 확장이 유지된다.
EC2 시작 유형에서는 용량 공급자가 자동으로 EC2 인스턴스를 추가하여 클러스터 용량을 확장한다.

💡 ECS 롤링 업데이트 개요

ECS 롤링 업데이트는 서비스의 태스크를 버전 1(V1)에서 버전 2(V2)로 업데이트할 때, 태스크를 한 번에 몇 개씩 시작하고 종료할지 제어할 수 있는 기능이다.
업데이트 시에는 두 가지 중요한 설정을 고려해야 한다

최소 상태 퍼센트(Minimum Healthy Percent): 실행 중인 태스크 중 최소 몇 퍼센트가 건강한 상태로 유지되어야 하는지 설정.
최대 퍼센트(Maximum Percent): 동시에 실행 가능한 최대 태스크의 퍼센트를 설정. 이 값은 태스크 수의 상한을 정하며, 새 버전의 태스크를 시작할 수 있는 수를 제어한다.

예시: 현재 서비스에 9개의 태스크가 실행 중이라면, 100% 실행 용량 상태이다. 업데이트를 진행할 때 최소 퍼센트를 100%로 설정하면, 실행 중인 태스크가 모두 유지된다.

😃 ECS 롤링 업데이트 시나리오 1 - 최소 50%, 최대 100%

롤링 업데이트 중 태스크가 교체되는 과정 / V1 태스크가 50%씩 종료되고, V2 태스크가 순차적으로 생성되는 과정

이번 시나리오는 최소 50%, 최대 100%로 설정된 롤링 업데이트이다. 이 설정은 서비스의 실행 용량을 최소 50%로 유지하면서 새로운 태스크를 생성하고, 기존 태스크를 종료하게 된다.
- 시작 태스크 수: 4개
- 첫 번째 단계에서, 기존 4개의 태스크 중 2개를 종료하고 2개의 V2 태스크를 생성하여 다시 100% 용량을 맞춘다.
- 이후 나머지 V1 태스크를 종료하고, 나머지 2개의 V2 태스크를 생성하여 롤링 업데이트를 완료한다.

😃 ECS 롤링 업데이트 시나리오 2 - 최소 100%, 최대 150%

최소 100%, 최대 150% 설정에서 V2 태스크가 생성되고 V1 태스크가 종료되는 과정 - 기존 용량을 유지하면서 새로운 태스크가 추가되고, V1 태스크가 종료되는 과정

이번에는 최소 100%, 최대 150%로 설정된 롤링 업데이트 시나리오
- 이 설정은 기존 태스크를 유지하면서 새로운 태스크를 추가하는 방식이다.
  - 시작 태스크 수: 4개
  - 첫 번째 단계에서, 기존 태스크를 모두 유지한 상태로 2개의 V2 태스크를 생성하여 150% 용량으로 늘어난다.
  - 이후, 기존 V1 태스크를 종료하면서 V2 태스크를 추가적으로 생성하여 다시 100%로 돌아온다. 이 과정을 반복해 롤링 업데이트가 완료된다.

📟 ECS 작업 - EventBridge에서 호출

S3에서 객체가 업로드된 후 EventBridge를 통해 ECS 작업이 호출되고, 작업이 완료되면 DynamoDB에 결과를 저장하는 과정

Amazon EventBridge는 이벤트 기반 아키텍처로, 특정 이벤트에 따라 ECS 작업을 호출할 수 있다.
예를 들어, S3 버킷에 객체가 업로드되면, 이 이벤트가 EventBridge를 통해 ECS 작업을 실행하는 트리거가 된다.
실행된 ECS 작업은 S3 객체를 가져와 처리하고, 그 결과를 DynamoDB에 저장한다.
이와 같은 아키텍처는 서버리스 방식으로 구성되며, AWS Fargate에서 ECS 작업이 실행된다.

📟 ECS 작업 - EventBridge 스케줄을 사용한 ECS 작업 호출

EventBridge 스케줄을 사용하면 정기적으로 ECS 작업을 실행할 수 있다.
예를 들어, 매 1시간마다 Fargate에서 ECS 작업이 실행되도록 설정할 수 있다.
이 ECS 작업은 S3에 접근해 파일을 처리하는 배치 작업을 수행할 수 있다.
이 아키텍처는 서버리스로 동작하며, ECS 작업이 주기적으로 실행된다.

EventBridge 스케줄이 매시간 Fargate에서 ECS 작업을 실행하고, 해당 작업이 S3에 접근해 배치 처리를 하는 과정

🦾 ECS 작업 - SQS 큐를 사용한 ECS 작업 실행

SQS 큐는 메시지 기반 아키텍처로, SQS 큐에 쌓인 메시지를 ECS 작업이 가져와 처리한다.
SQS 큐에 메시지가 많아질 경우, ECS 서비스 오토 스케일링이 자동으로 더 많은 ECS 작업을 생성하여 처리량을 증가시킨다.
이러한 아키텍처는 서비스 차원에서 확장성을 유지하며, 메시지 기반 시스템에서 유용하다.

SQS 큐에 쌓인 메시지를 ECS 작업이 가져와 처리하고, 오토 스케일링이 활성화되는 과정

ECS 작업 상태 변경 감지 - EventBridge로 중지된 ECS 작업 감지

EventBridge는 ECS 작업의 상태 변경을 감지하고, 이를 트리거로 삼아 다른 작업을 실행할 수 있다.
예를 들어, ECS 작업이 중지되면, EventBridge에서 이를 감지하여 SNS를 통해 관리자에게 알림을 보낸다.
이와 같은 설정은 ECS 작업의 종료 이유를 추적하고, 신속하게 대응할 수 있도록 돕는다.

ECS 작업이 중지되면 EventBridge가 이를 감지하고 SNS를 통해 알림을 보내는 과정

💡 Amazon ECS - 태스크 정의(Task Definition)

태스크 정의는 JSON 형식으로 작성된 메타데이터로, ECS에서 도커 컨테이너를 실행하는 방법을 설명하는 핵심 구성 요소이다.
포함된 정보:
- 이미지 이름
- 컨테이너와 호스트 포트 매핑
- 요구 메모리 및 CPU
- 환경 변수
- 네트워크 정보
- IAM 역할
- 로깅 구성
태스크 정의는 최대 10개의 컨테이너를 정의할 수 있다.
예시: HTTP 서버의 컨테이너 포트 80을 EC2 인스턴스의 호스트 포트 8080과 매핑하여 인터넷에 노출시킴.

⚖️ ECS 로드 밸런싱 (EC2 시작 유형)

EC2 시작 유형을 사용할 때, 동적 호스트 포트 매핑을 통해 컨테이너 포트를 동적으로 호스트 포트에 매핑할 수 있다.
ALB(애플리케이션 로드 밸런서)는 동적 포트를 탐색하여 올바른 포트로 연결한다.
보안: EC2 인스턴스의 보안 그룹에서 ALB로부터 모든 포트를 허용해야 한다.

⚖️ Amazon ECS - Fargate 로드 밸런싱

Fargate에서는 각 ECS 태스크가 고유한 프라이빗 IP를 가진다.
호스트 포트 설정이 필요 없으며, 컨테이너 포트만 정의하면 된다.
보안: ECS의 ENI 보안 그룹은 ALB로부터 포트 80을 허용해야 하며, ALB는 웹에서 포트 80 또는 443을 허용해야 한다.

👪 Amazon ECS - 태스크 정의 별 IAM 역할

태스크 정의별로 S3와 DynamoDB에 접근할 수 있는 IAM 역할 설정

ECS 태스크는 태스크 정의 당 하나의 IAM 역할을 할당받는다.
태스크 정의 A는 S3에 접근 가능한 역할을, 태스크 정의 B는 DynamoDB에 접근 가능한 역할을 가진다.
서비스의 모든 태스크는 해당 태스크 정의에 지정된 IAM 역할을 상속받는다.

⚙️ Amazon ECS - 환경 변수 설정

SSM 파라미터 스토어와 Secrets Manager에서 환경 변수를 불러오고 ECS 태스크로 전달하는 과정

ECS 태스크 정의는 환경 변수를 설정할 수 있으며, 여러 가지 방법이 존재한다.
- 하드코딩: 태스크 정의 내 URL 등 고정 값 설정.
- SSM 파라미터 스토어: API 키나 공유 설정값을 저장 및 사용.
- 암호 관리자(Secrets Manager): 민감한 정보(예: DB 비밀번호)를 저장 및 참조.
- S3 버킷: 환경 변수를 파일로 저장하고 로드하는 방식.

🔉 데이터 볼륨 (Bind Mounts)

Bind Mounts는 여러 컨테이너가 동일한 데이터를 공유할 수 있게 해주는 방식이다.
EC2 태스크: 인스턴스 스토리지 사용.
Fargate 태스크: 임시 스토리지 사용.
사용 사례: 여러 컨테이너 간 로그/지표 데이터를 공유하거나, 사이드 카 컨테이너가 데이터를 처리할 때 사용.

💡 ECS 태스크 배치

EC2 시작 유형에서 ECS 태스크를 실행할 때, ECS는 CPU, 메모리, 포트 제약 조건에 따라 태스크를 배치할 위치를 결정한다.
마찬가지로, 서비스가 스케일 인할 때도 어떤 태스크를 종료할지 결정해야 한다.
태스크 배치 전략과 태스크 배치 제한을 통해 ECS 태스크 배치를 제어할 수 있다.
Note: Fargate는 지원하지 않음.

💡 ECS 태스크 배치 프로세스

태스크 배치 전략은 "최선의 노력을 다함(best effort)" 방식으로 이루어진다.
ECS가 태스크를 배치할 때 4단계 프로세스를 따른다:
1. CPU, 메모리, 포트 조건을 만족하는 인스턴스 확인
2. 태스크 배치 제한을 만족하는 인스턴스 확인
3. 태스크 배치 전략을 만족하는 인스턴스 확인
4. 최종적으로 인스턴스를 선택해 태스크 배치

💡 Amazon ECS - Binpack 배치 전략

Binpack 전략
- 태스크를 CPU와 메모리가 가장 적게 남은 인스턴스에 배치함으로써 사용 중인 EC2 인스턴스 수를 최소화하여 비용을 절감한다.
JSON 예시:

{
  "type": "binpack",
  "field": "memory"
}

💡 Amazon ECS - Random 배치 전략

Random 전략
- 태스크를 무작위로 배치한다.
JSON 예시:

{
  "type": "random"
}

💡 Amazon ECS - Spread 배치 전략

Spread 전략
- 태스크를 특정 값을 기준으로 분산하여 배치한다. 예를 들어 가용 영역(availability-zone)이나 인스턴스 ID(instanceId)를 기준으로 할 수 있다.
JSON 예시:

{
  "type": "spread",
  "field": "attribute:ecs.availability-zone"
}

💡 Amazon ECS - 혼합 배치 전략

혼합 배치 전략
- 여러 태스크 배치 전략을 결합하여 사용할 수 있다.
- 예시로 Spread와 Binpack 전략을 혼합하여 사용할 수 있다.
JSON 예시:

{
  "type": "spread",
  "field": "attribute:ecs.availability-zone"
},
{
  "type": "binpack",
  "field": "memory"
}

💡 Amazon ECS - 태스크 배치 제한

distinctInstance
- 태스크를 서로 다른 EC2 인스턴스에 배치한다.
JSON 예시:

{
  "type": "distinctInstance"
}

memberOf: 클러스터 쿼리 언어를 사용해 특정 속성을 만족하는 인스턴스에만 태스크를 배치한다.
JSON 예시:

{
  "type": "memberOf",
  "expression": "attribute:ecs.instance-type >= t2.*"
}

💡 Amazon ECR

Amazon ECR(Amazon Elastic Container Registry)은 AWS의 Docker 이미지 저장소로, AWS에 Docker 이미지를 저장하고 관리하는 데 사용된다.
ECR은 프라이빗과 퍼블릭 두 가지 유형의 리포지토리를 제공
- 퍼블릭 리포지토리의 경우, Amazon ECR Public Gallery에 이미지를 게시할 수 있다.

<주요 특징>

ECS와의 통합
- ECR은 Amazon ECS(Elastic Container Service)와 완전히 통합되어 있어 Docker 이미지를 손쉽게 배포할 수 있다.
- ECR에 저장된 이미지는 Amazon S3를 통해 백엔드에서 저장되므로 안전하게 관리된다.
IAM 역할을 통한 접근 제어
- EC2 인스턴스 또는 다른 AWS 서비스가 ECR에서 이미지를 가져오기 위해서는 해당 인스턴스에 IAM 역할을 부여해야 한다.
- 이는 AWS IAM을 통해 액세스 권한을 제어함으로써 보안을 유지한다.
취약점 스캐닝 및 이미지 관리
- ECR은 Docker 이미지에 대한 취약점 스캐닝을 지원하여 보안 문제를 조기에 파악할 수 있다.
- 또한, 버저닝을 통해 이미지 관리가 가능하고, 이미지 태그와 이미지 수명 주기 관리 기능을 제공하여 오래된 이미지를 자동으로 삭제할 수 있다.

💡 AWS Copilot

AWS Copilot은 컨테이너화된 애플리케이션을 빌드, 릴리스, 운영하는 데 사용되는 CLI 도구
AppRunner, ECS, Fargate에서 애플리케이션을 실행하는 과정을 단순화하여, 복잡한 인프라 설정 대신 애플리케이션 자체에 집중할 수 있게 도와준다.