# EC2 워크로드를 위한 Amazon ECS 용량 공급자
용량으로 Amazon EC2 인스턴스를 사용하는 경우 Auto Scaling 그룹을 사용하여 클러스터에 등록된 Amazon EC2 인스턴스를 관리합니다. Auto Scaling은 애플리케이션 로드를 처리하는 데 사용할 수 있는 Amazon EC2 인스턴스의 정확한 수를 확보하는 데 도움이 됩니다.
Managed Scaling 기능을 사용하여 Auto Scaling 그룹의 스케일 인 및 스케일 아웃 작업을 Amazon ECS가 관리하도록 하거나 직접 규모 조정 작업을 관리할 수 있습니다. 자세한 내용은 [클러스터 Auto Scaling을 통해 Amazon ECS 용량 자동 관리](cluster-auto-scaling.md) 섹션을 참조하세요.
새로운 빈 Auto Scaling 그룹을 생성하는 것이 좋습니다. 기존 Auto Scaling 그룹을 사용하는 경우 용량 공급자를 생성하는 데 사용되는 Auto Scaling 그룹에 앞서 이미 실행 중이고 Amazon ECS 클러스터에 등록된 그룹과 연결된 Amazon EC2 인스턴스가 용량 공급자에 제대로 등록되지 않을 수 있습니다. 이럴 경우 용량 공급자 전략에서 용량 공급자를 사용할 때 문제가 발생할 수 있습니다. `DescribeContainerInstances`를 사용하면 컨테이너 인스턴스가 용량 공급자와 연결되어 있는지를 확인할 수 있습니다.
**참고**
빈 Auto Scaling 그룹을 생성하려면 원하는 카운트를 0으로 설정합니다. 용량 공급자를 생성하고 클러스터와 연결한 후에 스케일 아웃할 수 있습니다.
Amazon ECS 콘솔을 사용하는 경우 Amazon ECS는 CloudFormation 스택의 일부로 사용자를 대신하여 Amazon EC2 시작 템플릿 및 Auto Scaling 그룹을 생성합니다. `EC2ContainerService-` 접두사가 붙습니다. Auto Scaling 그룹을 해당 클러스터의 용량 공급자로 사용할 수 있습니다.
워크로드에 지장을 주지 않으면서 Amazon EC2 인스턴스를 정상적으로 종료할 수 있도록 관리형 인스턴스 드레이닝을 사용하는 것이 좋습니다. 이 기능은 기본적으로 켜져 있습니다. 자세한 내용은 [EC2 인스턴스에서 실행되는 Amazon ECS 워크로드를 안전하게 중지](managed-instance-draining.md) 섹션을 참조하세요.
클래식 콘솔에서 Auto Scaling 그룹 용량 공급자를 사용할 경우 다음 사항을 고려합니다.
+ Auto Scaling 그룹이 스케일 아웃하려면 `MaxSize` 가 0보다 커야 합니다.
+ Auto Scaling 그룹에는 인스턴스 가중치 설정이 있을 수 없습니다.
+ Auto Scaling 그룹이 실행되는 작업 수에 맞게 스케일 아웃할 수 없는 경우 작업이 `PROVISIONING` 상태를 지나 전환되지 못합니다.
+ 용량 공급자가 관리하는 Auto Scaling 그룹과 연결된 조정 정책 리소스를 수정하지 마세요.
+ 용량 공급자를 생성하 때 관리형 조정이 켜진 경우 Auto Scaling의 원하는 수를 `0`으로 설정할 수 있습니다. 관리형 조정이 켜지면 Amazon ECS에서 Auto Scaling 그룹의 스케일 인 및 스케일 아웃 작업을 관리합니다.
+ 용량 공급자를 클러스터와 연결하려면 먼저 클러스터를 용량 공급자 전략과 연결해야 합니다.
+ 용량 공급자 전략에 최대 20개의 용량 공급자를 지정할 수 있습니다.
+ Fargate 용량 공급자를 사용하기 위해 Auto Scaling 그룹 용량 공급자를 사용하여 서비스를 업데이트할 수 없습니다. 반대의 경우도 마찬가지입니다.
+ 용량 공급자 전략에서 콘솔의 용량 공급자에 대해 `weight` 값이 지정되지 않으면 기본값 `1`을 사용합니다. API 또는 AWS CLI를 사용할 경우에 기본값은 `0`입니다.
+ 용량 공급자 전략 내에서 여러 용량 공급자가 지정된 경우 하나 이상의 용량 공급자가 0보다 큰 가중치 값을 가져야 합니다. 가중치가 0인 용량 공급자는 태스크를 배치하는 데 사용되지 않습니다. 전략에 가중치가 모두 0으로 동일한 여러 개의 용량 공급자를 지정하는 경우 용량 공급자 전략을 사용하는 `RunTask` 또는 `CreateService` 작업이 실패합니다.
+ 용량 공급자 전략에서는 하나의 용량 공급자만 정의된 base** 값을 가질 수 있습니다. base 값을 지정하지 않으면 기본값 0이 사용됩니다.
+ 클러스터에 Auto Scaling 그룹 용량 공급자와 Fargate 용량 공급자가 혼합되어 있을 수 있습니다. 그러나 용량 공급자 전략에 Auto Scaling 그룹 또는 Fargate 용량 공급자만 포함될 수 있으며 둘 다 포함될 수는 없습니다.
+ 클러스터에는 용량 공급자와 시작 유형을 모두 사용하는 서비스와 독립 실행형 작업이 혼합되어 포함될 수 있습니다. 시작 유형이 아닌 용량 공급자 전략을 사용하도록 서비스를 업데이트할 수 있습니다. 하지만 이 경우 새 배포를 강제로 실행해야 합니다.
+ Amazon ECS에서 Amazon EC2 Auto Scaling 웜 풀을 지원합니다. 웜 풀은 서비스에 배치할 준비가 되어 사전 초기화된 Amazon EC2 인스턴스의 그룹입니다. 애플리케이션을 스케일 아웃해야 할 때마다 Amazon EC2 Auto Scaling은 콜드 인스턴스를 실행하는 대신 웜 풀에서 미리 초기화된 인스턴스를 사용합니다. 이렇게 하면 인스턴스가 서비스에 배치되기 전에 최종 초기화 프로세스를 실행할 수 있습니다. 자세한 내용은 [Amazon ECS Auto Scaling 그룹에 대해 사전 초기화된 인스턴스 구성](using-warm-pool.md) 섹션을 참조하세요.
Amazon EC2 Auto Scaling 시작 템플릿 생성에 대한 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*의 [Auto Scaling 시작 템플릿](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html)을 참조하세요. Amazon EC2 Auto Scaling 그룹 생성에 대한 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*의 [오토 스케일링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)을 참조하세요.
# Amazon ECS에 대한 Amazon EC2 컨테이너 인스턴스 보안 고려 사항
위협 모델 내에서 단일 컨테이너 인스턴스와 이 인스턴스의 액세스를 고려해야 합니다. 예를 들어 영향을 받는 단일 작업이 동일한 인스턴스에서 감염되지 않은 작업의 IAM 권한을 활용할 수 있습니다.
이러한 문제를 방지하려면 다음을 사용하는 것이 좋습니다.
+ 작업을 실행할 때 관리자 권한을 사용하지 마세요.
+ 작업에 대한 최소 액세스 권한을 갖는 작업 역할을 할당합니다.
컨테이너 에이전트는 Amazon ECS 리소스에 액세스하는 데 사용되는 고유한 보안 인증 ID가 있는 토큰을 자동으로 생성합니다.
+ `awsvpc` 네트워크 모드를 사용하는 작업에서 실행하는 컨테이너가 Amazon EC2 인스턴스 프로파일에 제공된 보안 인증 정보에 액세스하지 못하게 방지하려면(단, 작업 역할에 제공된 권한은 허용) 에이전트 구성 파일에서 `ECS_AWSVPC_BLOCK_IMDS` 에이전트 구성 변수를 true로 설정하고 에이전트를 다시 시작합니다.
+ Amazon GuardDuty Runtime Monitoring을 사용하여 AWS 환경 내 클러스터 및 컨테이너에 대한 위협을 감지합니다. Runtime Monitoring은 파일 액세스, 프로세스 실행 및 네트워크 연결과 같은 개별 Amazon ECS 워크로드에 대한 런타임 가시성을 추가하는 GuardDuty 보안 에이전트를 사용합니다. 자세한 내용은 *GuardDuty 사용 설명서*의 [GuardDuty 런타임 모니터링](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html)을 참조하세요.
# Amazon EC2 워크로드에 대한 Amazon ECS 클러스터 생성
클러스터를 생성하여 태스크와 서비스가 실행되는 인프라를 정의합니다.
시작하기 전에 먼저 [Amazon ECS 사용 설정](get-set-up-for-amazon-ecs.md) 단계를 완료하고 적절한 IAM 권한을 할당했는지 확인합니다. 자세한 내용은 [Amazon ECS 클러스터 예제](security_iam_id-based-policy-examples.md#IAM_cluster_policies) 섹션을 참조하세요. Amazon ECS 콘솔은 CloudFormation 스택을 생성하여 Amazon ECS 클러스터에 필요한 리소스를 생성하는 간단한 방법을 제공합니다.
클러스터 생성 프로세스를 가능한 한 쉽게 만들기 위해 콘솔에는 아래에서 설명하는 여러 선택 항목에 대한 기본 선택 항목이 있습니다. 추가 컨텍스트를 제공하는 콘솔의 대부분의 섹션에서 사용할 수 있는 도움말 패널도 있습니다.
클러스터를 생성할 때 Amazon EC2 인스턴스를 등록하거나 클러스터를 생성한 후 클러스터에 추가 인스턴스를 등록할 수 있습니다.
다음 기본 옵션을 수정할 수 있습니다.
+ 인스턴스가 시작되는 서브넷을 변경합니다.
+ 컨테이너 인스턴스에 대한 트래픽을 제어하는 데 사용되는 보안 그룹을 변경합니다.
+ 클러스터에 네임스페이스를 추가합니다.
네임스페이스를 사용하면 클러스터에서 생성한 서비스를 추가 구성 없이 네임스페이스의 다른 서비스에 연결할 수 있습니다. 자세한 내용은 [Amazon ECS 서비스 상호 연결](interconnecting-services.md) 섹션을 참조하세요.
+ 태스크 상태 변경에 대한 EventBridge 알림을 수신하도록 태스크 이벤트를 활성화합니다.
+ 관리형 스토리지에 AWS KMS 키를 할당합니다. 키 생성 방법에 대한 자세한 내용은 *AWS Key Management Service 사용 설명서*의 [KMS 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)을 참조하세요.
+ Fargate 임시 스토리지에 AWS KMS 키를 할당합니다. 키 생성 방법에 대한 자세한 내용은 *AWS Key Management Service 사용 설명서*의 [KMS 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)을 참조하세요.
+ ECS Exec에 대한 AWS KMS 키 및 로깅을 구성합니다.
+ 클러스터를 식별하는 데 도움이 되는 태그를 추가합니다.
## Auto Scaling 그룹 옵션
Amazon EC2 인스턴스를 사용할 때 태스크와 서비스가 실행되는 인프라를 관리하려면 Auto Scaling 그룹을 지정해야 합니다.
새 Auto Scaling 그룹을 생성하도록 선택하면 다음 동작에 대해 자동으로 구성됩니다.
+ Amazon ECS에서 Auto Scaling 그룹의 축소 및 확장 작업을 관리합니다.
+ Amazon ECS는 태스크를 포함하고 Auto Scaling 그룹에 있는 Amazon EC2 인스턴스가 축소 작업 중에 종료되는 것을 방지하지 않습니다. 자세한 정보는 *AWS Auto Scaling 사용 설명서*의 [인스턴스 보호](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection)를 참조하세요.
그룹에 대해 시작할 인스턴스의 유형과 수를 결정하는 다음 Auto Scaling 그룹 속성을 구성합니다.
+ Amazon ECS 최적화 AMI
+ 인스턴스 유형.
+ 인스턴스에 연결할 때 자격 증명을 증명하는 SSH 키 페어입니다. SSH 키를 생성하는 방법에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 키 페어 및 Linux 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요.
+ Auto Scaling 그룹에 대해 시작할 최소 인스턴스 수
+ Auto Scaling 그룹에 대해 시작되는 최대 인스턴스 수입니다.
그룹을 확장하려면 최댓값이 0보다 커야 합니다.
Amazon ECS는 CloudFormation 스택의 일부로 사용자를 대신하여 Amazon EC2 Auto Scaling 시작 템플릿과 Auto Scaling 그룹을 생성합니다. AMI, 인스턴스 유형, SSH 키 페어에 대해 지정한 값은 시작 템플릿에 있습니다. 쉽게 식별할 수 있도록 템플릿에 접두사 `EC2ContainerService-`이 붙습니다. Auto Scaling 그룹의 접두사는 `-ECS-Infra-ECSAutoScalingGroup`입니다.
Auto Scaling 그룹에 대해 시작된 인스턴스는 시작 템플릿을 사용합니다.
## 네트워킹 옵션
기본적으로 인스턴스는 리전의 기본 서브넷으로 시작됩니다. 컨테이너 인스턴스에 대한 트래픽을 제어하고 현재 서브넷과 연결되어 있는 보안 그룹이 사용됩니다. 인스턴스에 대한 서브넷과 보안 그룹을 변경할 수 있습니다.
기존 서브넷을 선택할 수 있습니다. 기존의 보안 그룹을 사용하거나 새로 생성할 수 있습니다. IPv6 전용 구성으로 태스크를 생성하려면 IPv6 CIDR 블록만 포함하는 서브넷을 사용합니다.
새 보안 그룹을 생성할 때 인바운드 규칙을 하나 이상 지정해야 합니다.
인바운드 규칙은 컨테이너 인스턴스에 도달할 수 있는 트래픽을 결정하며 다음 속성을 포함합니다.
+ 허용할 프로토콜
+ 허용할 포트의 범위
+ 인바운드 트래픽(소스)
특정 주소 또는 CIDR 블록의 인바운드 트래픽을 허용하려면 허용되는 CIDR과 함께 **소스**에 **사용자 지정**을 사용합니다.
모든 대상의 인바운드 트래픽을 허용하려면 **소스**에 **위치 무관**을 사용합니다. 그러면 0.0.0.0/0 IPv4 CIDR 블록 및 ::/0 IPv6 CIDR 블록이 자동으로 추가됩니다.
로컬 컴퓨터의 인바운드 트래픽을 허용하려면 **소스**에 **소스 그룹**을 사용합니다. 그러면 로컬 컴퓨터의 IP 주소가 허용되는 소스로 추가됩니다.
**새 클러스터 생성(Amazon ECS 콘솔)**
시작하기 전에 적절한 IAM 권한을 할당합니다. 자세한 내용은 [Amazon ECS 클러스터 예제](security_iam_id-based-policy-examples.md#IAM_cluster_policies) 섹션을 참조하세요.
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 모음에서 사용할 리전을 선택합니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터(Clusters)** 페이지에서 **클러스터 생성(Create cluster)**을 선택합니다.
1. **클러스터 구성**에서 다음을 구성합니다.
+ **클러스터 이름**에 고유한 이름을 입력합니다.
이름은 최대 255자(대/소문자), 숫자 및 하이픈을 포함할 수 있습니다.
+ (선택 사항) Service Connect에 사용되는 네임스페이스를 클러스터 이름과 다르게 하려면 **Service Connect 기본값**의 **기본 네임스페이스**에서 네임스페이스 이름을 선택하거나 입력하세요. 공유 네임스페이스를 사용하려면 네임스페이스 ARN을 선택하거나 입력하세요. 공유 네임스페이스 사용에 대한 자세한 내용은 [공유 AWS Cloud Map 네임스페이스를 사용하는 Amazon ECS Service Connect](service-connect-shared-namespaces.md) 섹션을 참조하세요.
1. Amazon EC2 인스턴스를 클러스터에 추가하고 **인프라**를 확장한 다음 **Fargate 및 자체 관리형 인스턴스**를 선택하세요.
다음으로 용량 공급자 역할을 하는 Auto Scaling 그룹을 구성합니다.
1. 기존 Auto Scaling 그룹을 사용하려면 **Auto Scaling 그룹(ASG)(Auto Scaling group (ASG))**에서 해당 그룹을 선택합니다.
1. Auto Scaling 그룹을 생성하려면 **Auto Scaling 그룹(ASG)(Auto Scaling group (ASG))**에서 **새 그룹 생성(Create new group)**을 선택한 후 그룹에 대한 다음 세부 정보를 제공합니다.
+ **프로비저닝 모델**에서 **온디맨드** 인스턴스 또는 **스팟** 인스턴스 중 사용할 인스턴스를 선택합니다.
+ 스팟 인스턴스를 사용하려는 경우 **할당 전략**에서 인스턴스에 사용할 스팟 용량 풀(인스턴스 유형, 가용 영역)을 선택합니다.
대부분의 워크로드에서 **가격 용량 최적화**를 선택할 수 있습니다.
자세한 내용은 *Amazon EC2 사용 설명서*의 [스팟 인스턴스를 위한 할당 전략](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html)을 참조하세요.
+ **컨테이너 인스턴스 Amazon Machine Image(AMI)**는 Auto Scaling 그룹 인스턴스에 대한 Amazon ECS 최적화 AMI를 선택합니다.
+ **EC2 인스턴스 유형(EC2 instance type)**에서 워크로드의 인스턴스 유형을 선택합니다.
관리형 확장은 Auto Scaling 그룹에서 동일하거나 유사한 인스턴스 유형을 사용해야 가장 효과적입니다.
+ **EC2 인스턴스 역할**의 경우 기존 컨테이너 인스턴스 역할을 선택하거나 새로 생성할 수 있습니다.
자세한 내용은 [Amazon ECS 컨테이너 인스턴스 IAM 역할](instance_IAM_role.md) 섹션을 참조하세요.
+ **용량(Capacity)**에 Auto Scaling 그룹에서 시작할 최소 인스턴스 수와 최대 인스턴스 수를 입력합니다.
+ **SSH 키 페어(SSH key pair)**에서 인스턴스에 연결할 때 자격 증명을 증명하는 페어를 선택합니다.
+ 더 큰 이미지와 스토리지를 허용하려면 **루트 EBS 볼륨 크기**에 값(GIB)을 입력합니다.
1. (선택 사항) VPC와 서브넷을 변경하려면 **Amazon EC2 인스턴스에 대한 네트워킹**에서 다음 작업 중 하나를 수행합니다.
+ 서브넷을 제거하려면 **서브넷(Subnets)**에서 제거하려는 각 서브넷에 대해 **X**를 선택합니다.
+ **기본** VPC가 아닌 다른 VPC로 변경하려면 **VPC**에서 기존 **VPC**를 선택한 다음 **서브넷**에서 서브넷을 선택하세요. IPv6 전용 구성의 경우 IPv6 CIDR 블록이 있는 VPC와 IPv6 CIDR 블록만 있는 서브넷을 선택하세요.
+ 보안 그룹을 선택합니다. **보안 그룹**에서 다음 옵션 중 하나를 선택합니다.
+ 기존 보안 그룹을 선택하려면 **기존 보안 그룹 선택**을 선택한 다음 보안 그룹을 선택합니다.
+ 보안 그룹을 생성하려면 **새 보안 그룹 생성**을 선택합니다. 그런 다음 각 인바운드 규칙에 대해 **규칙 추가**를 선택합니다.
인바운드 규칙에 대한 자세한 내용은 [네트워킹 옵션](#networking-options)을 참조하세요.
+ Amazon EC2 컨테이너 인스턴스에 퍼블릭 IP 주소를 자동으로 할당하려면 **퍼블릭 IP 자동 할당**에서 다음 옵션 중 하나를 선택합니다.
+ **서브넷 설정 사용** - 인스턴스가 시작되는 서브넷이 퍼블릭 서브넷인 경우 인스턴스에 퍼블릭 IP 주소를 할당합니다.
+ **켜기** - 인스턴스에 퍼블릭 IP 주소를 할당합니다.
1. (선택 사항) Container Insights를 사용하고 **모니터링**을 확장한 후에 다음 옵션 중 하나를 선택합니다.
+ 권장되는 관찰성이 향상된 Container Insights를 사용하려면 **관찰성이 향상된 Container Insights**를 선택합니다.
+ Container Insights를 사용하려면 **Container Insights**를 선택합니다.
1. (선택 사항) 태스크 이벤트를 활성화하려면 **태스크 이벤트**를 확장한 다음 **태스크 이벤트 활성화**를 켜세요.
태스크 이벤트를 활성화하면 Amazon ECS는 태스크 상태 변경 이벤트를 EventBridge로 전송합니다. 그러면 태스크 수명 주기 변경 사항을 자동으로 모니터링하고 이에 대응할 수 있습니다.
1. (선택 사항) ECS Exec을 사용하여 클러스터의 태스크를 디버깅하려면 **문제 해결 구성**을 확장한 후 다음을 구성합니다.
+ (선택 사항) **ECS Exec용 AWS KMS 키**에 ECS Exec 세션 데이터를 암호화하는 데 사용할 AWS KMS 키의 ARN을 입력합니다.
+ (선택 사항) **ECS Exec 로깅**에서 로그 대상을 선택합니다.
+ CloudWatch Logs로 로그를 보내려면 **Amazon CloudWatch**를 선택합니다.
+ Amazon S3로 로그를 보내려면 **Amazon S3**를 선택합니다.
+ 로깅을 비활성화하려면 **없음**을 선택합니다.
1. (선택 사항)
수동 옵션으로 Runtime Monitoring을 사용하고 GuardDuty에서 이 클러스터를 모니터링하도록 하려면 **태그 추가**를 선택하고 다음을 수행합니다.
+ **키**에 **guardDutyRuntimeMonitoringManaged**를 입력합니다.
+ **값**에 **true**를 입력합니다.
1. (선택 사항) 관리형 스토리지의 데이터를 암호화합니다. **암호화**에서 **관리형 스토리지**에 관리형 스토리지 데이터를 암호화하는 데 사용할 AWS KMS 키의 ARN을 입력합니다.
1. (선택 사항) 클러스터 태그를 관리하려면 **태그(Tags)**를 확장하고 다음 작업 중 하나를 수행합니다.
[태그 추가] **태그 추가(Add tag)**를 선택하고 다음을 수행합니다.
+ **키(Key)**에 키 이름을 입력합니다.
+ **값**에 키 값을 입력합니다.
[태그 제거] 태그의 키와 값 오른쪽에 있는 **제거**를 선택합니다.
1. **생성(Create)**을 선택합니다.
## 다음 단계
클러스터를 생성한 후 애플리케이션에 대한 작업 정의를 생성한 다음 독립 실행형 작업으로 실행하거나 서비스의 일부로 실행할 수 있습니다. 자세한 내용은 다음을 참조하세요.
+ [Amazon ECS 작업 정의](task_definitions.md)
+ [애플리케이션을 Amazon ECS 태스크로 실행](standalone-task-create.md)
+ [Amazon ECS 롤링 업데이트 배포 생성](create-service-console-v2.md)
# 클러스터 Auto Scaling을 통해 Amazon ECS 용량 자동 관리
Amazon ECS는 클러스터에 등록된 Amazon EC2 인스턴스의 크기 조정을 관리할 수 있습니다. 이를 Amazon ECS **클러스터 Auto Scaling이라고 합니다. Amazon ECS Auto Scaling 그룹 용량 공급자를 생성할 때 Managed Scaling을 켭니다. 그런 다음 이 Auto Scaling 그룹에서 인스턴스 사용률에 대한 목표 백분율(`targetCapacity`)을 설정합니다. Amazon ECS는 Auto Scaling 그룹에 대한 두 가지 사용자 지정 CloudWatch 지표와 대상 추적 조정 정책을 생성합니다. 그런 다음 Amazon ECS는 태스크에서 사용하는 리소스 사용률에 따라 스케일 인 및 스케일 아웃 작업을 관리합니다.
클러스터와 연결된 각 Auto Scaling 그룹 용량 공급자에 대해 Amazon ECS는 다음 리소스를 생성하고 관리합니다.
+ 지표 값이 낮은 CloudWatch 경보
+ 지표 값이 높은 CloudWatch 경보
+ 대상 추적 조정 정책입니다.
**참고**
Amazon ECS에서 대상 추적 조정 정책을 생성하여 Auto Scaling 그룹에 연결합니다. 대상 추적 조정 정책을 업데이트하려면 조정 정책을 직접 업데이트하는 대신 용량 공급자 관리형 조정 설정을 업데이트해야 합니다.
관리형 조정을 끄거나 클러스터에서 용량 공급자 연결을 해제하면 Amazon ECS가 CloudWatch 지표와 대상 추적 조정 정책 리소스를 제거합니다.
Amazon ECS는 다음 지표를 사용하여 수행할 작업을 결정합니다.
`CapacityProviderReservation`
특정 용량 공급자에 대해 사용 중인 클러스터 컨테이너 인스턴스의 백분율. Amazon ECS는 이 지표를 생성합니다.
Amazon ECS는 `CapacityProviderReservation` 값을 0에서 100 사이의 숫자로 설정합니다. Amazon ECS는 다음 수식을 사용하여 Auto Scaling 그룹에 남아 있는 용량의 비율을 나타냅니다. Amazon ECS는 CloudWatch에 지표를 게시합니다. 지표를 계산하는 방법에 대한 자세한 내용은 [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)을 참조하세요.
```
CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
```
`DesiredCapacity`
Auto Scaling 그룹에 대한 용량의 양입니다. 이 지표는 CloudWatch에 게시되지 않습니다.
Amazon ECS는 `CapacityProviderReservation` 지표를 CloudWatch에 `AWS/ECS/ManagedScaling` 네임스페이스로 게시합니다. `CapacityProviderReservation` 지표를 사용하면 다음 작업 중 하나가 발생합니다.
**`CapacityProviderReservation` 값이 `targetCapacity`와 같음**
Auto Scaling 그룹을 스케일 인 또는 스케일 아웃할 필요가 없습니다. 목표 사용률에 도달했습니다.
**`CapacityProviderReservation` 값이 `targetCapacity`보다 큼**
`targetCapacity` 백분율보다 높은 비율의 용량을 사용하는 작업이 많습니다. `CapacityProviderReservation` 지표 값이 증가하면 관련 CloudWatch 경보가 작동합니다. 이 경보는 Auto Scaling 그룹에 대한 `DesiredCapacity` 값을 업데이트합니다. Auto Scaling 그룹은 이 값을 사용하여 EC2 인스턴스를 시작한 다음 클러스터에 등록합니다.
`targetCapacity`가 기본값인 100%인 경우 작업을 실행할 인스턴스에 사용할 수 있는 용량이 없기 때문에 스케일 아웃 중 새 작업은 `PENDING` 상태가 됩니다. 새 인스턴스가 ECS에 등록되면 이러한 작업이 새 인스턴스에서 시작됩니다.
**`CapacityProviderReservation` 값이 `targetCapacity`보다 작음**
`targetCapacity` 백분율보다 낮은 비율의 용량을 사용하는 작업이 적고 종료할 수 있는 인스턴스가 하나 이상 있습니다. `CapacityProviderReservation` 지표 값이 감소하면 관련 CloudWatch 경보가 작동합니다. 이 경보는 Auto Scaling 그룹에 대한 `DesiredCapacity` 값을 업데이트합니다. Auto Scaling 그룹은 이 값을 사용하여 EC2 컨테이너 인스턴스를 종료한 다음 클러스터에서 등록을 취소합니다.
Auto Scaling 그룹은 그룹 종료 정책에 따라 스케일 인 이벤트 중 처음 종료할 인스턴스를 결정합니다. 또한 인스턴스 스케일 인 보호 설정이 켜진 인스턴스는 피합니다. 관리형 종료 보호를 켜는 경우 클러스터 Auto Scaling에서 인스턴스 스케일 인 보호 설정이 지정된 인스턴스를 관리할 수 있습니다. 관리형 종료 보호에 대한 자세한 내용은 [Amazon ECS가 종료하는 인스턴스 제어](managed-termination-protection.md)을 참조하세요. Auto Scaling 그룹에서 인스턴스를 종료하는 방법에 대한 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*의 [Control which Auto Scaling instances terminate during scale in](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html)을 참조하세요.
클러스터 Auto Scaling을 사용할 때는 다음 사항을 고려해야 합니다.
+ Amazon ECS가 관리하는 것 이외의 조정 정책이 있는 용량 공급자와 연결된 Auto Scaling 그룹에 대해 원하는 용량을 변경하거나 관리하지 마세요.
+ Amazon ECS가 인스턴스 0개에서 스케일 아웃되면 인스턴스 2개가 자동으로 시작됩니다.
+ Amazon ECS는 사용자를 대신하여 다른 AWS Auto Scaling를 호출하는 데 필요한 권한에 대해 `AWSServiceRoleForECS` 서비스 연결 IAM 역할을 사용합니다. 자세한 내용은 [Amazon ECS에 대해 서비스 연결 역할 사용](using-service-linked-roles.md) 섹션을 참조하세요.
+ Auto Scaling 그룹에 용량 공급자를 사용하는 경우 용량 공급자를 생성하는 사용자, 그룹 또는 역할에는 `autoscaling:CreateOrUpdateTags` 권한이 필요합니다. 이는 용량 공급자와 연결할 때 Amazon ECS가 Auto Scaling 그룹에 태그를 추가하기 때문입니다.
**중요**
사용하는 도구가 Auto Scaling 그룹에서 `AmazonECSManaged` 태그를 제거하지 않는지 확인합니다. 이 태그가 제거되면 Amazon ECS에서는 규모 조정을 관리할 수 없습니다.
+ 클러스터 Auto Scaling은 그룹에 대해 **MinimumCapacity** 또는 **MaximumCapacity**를 수정하지 않습니다. 그룹을 스케일 아웃하려면 **MaximumCapacity** 값이 0보다 커야 합니다.
+ Auto Scaling(관리형 조정)이 켜져 있을 때 한 번에 하나의 클러스터에만 용량 공급자를 연결할 수 있습니다. 용량 공급자가 관리형 크기 조정을 해제한 경우 이를 여러 클러스터와 연결할 수 있습니다.
+ 관리형 조정이 꺼져 있으면 용량 공급자가 스케일 인 또는 스케일 아웃하지 않습니다. 용량 공급자 전략을 사용하여 용량 공급자 간에 작업의 균형을 조정할 수 있습니다.
+ 이 `binpack` 전략은 용량 측면에서 가장 효율적인 전략입니다.
+ 목표 용량이 100% 미만인 경우 배치 전략에서 `binpack` 전략은 `spread` 전략보다 순위가 더 높아야 합니다. 이렇게 하면 각 작업에 전용 인스턴스가 있거나 한도에 도달할 때까지 용량 공급자가 스케일 아웃할 수 없습니다.
## 클러스터 Auto Scaling 켜기
콘솔 또는 AWS CLI를 사용하여 클러스터 오토 스케일링을 활성화할 수 있습니다.
콘솔을 사용하여 EC2 용량 공급자를 사용하는 클러스터를 생성할 때 Amazon ECS에서는 사용자를 대신해 Auto Scaling 그룹을 생성하고 대상 용량을 설정합니다. 자세한 내용은 [Amazon EC2 워크로드에 대한 Amazon ECS 클러스터 생성](create-ec2-cluster-console-v2.md) 섹션을 참조하세요.
Auto Scaling 그룹을 생성한 다음에 클러스터에 할당할 수도 있습니다. 자세한 내용은 [Amazon ECS 용량 공급자 업데이트](update-capacity-provider-console-v2.md) 섹션을 참조하세요.
AWS CLI를 사용하는 경우 클러스터 생성 후
1. 용량 공급자를 생성하기 전에 Auto Scaling 그룹을 생성해야 합니다. 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*의 [오토 스케일링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)을 참조하세요.
1. `put-cluster-capacity-providers`를 사용하여 클러스터 용량 공급자를 수정합니다. 자세한 내용은 [Amazon ECS 클러스터 Auto Scaling 켜기](turn-on-cluster-auto-scaling.md) 섹션을 참조하세요.
# Amazon ECS 클러스터 Auto Scaling 최적화
Amazon EC2에서 Amazon ECS를 실행하는 고객은 클러스터 Auto Scaling을 활용하여 Amazon EC2 Auto Scaling 그룹의 규모 조정을 관리할 수 있습니다. 클러스터 Auto Scaling을 사용하면 Auto Scaling 그룹의 규모를 자동으로 조정하고 태스크 실행에만 집중하도록 Amazon ECS를 구성할 수 있습니다. Amazon ECS는 추가 개입 없이 Auto Scaling 그룹이 필요에 따라 스케일 아웃 및 스케일 인하도록 보장합니다. Amazon ECS 용량 공급자는 애플리케이션의 요구 사항을 충족하기에 충분한 컨테이너 인스턴스가 있는지 확인하여 클러스터의 인프라를 관리하는 데 사용됩니다. 클러스터 Auto Scaling이 내부적으로 어떻게 작동하는지 알아보려면 [Amazon ECS 클러스터 Auto Scaling에 대한 심층 분석](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)을 참조하세요.
클러스터 Auto Scaling은 클러스터 용량 조정을 위한 Auto Scaling 그룹과의 CloudWatch 기반 통합에 의존합니다. 따라서
+ CloudWatch 지표 게시와 관련된 고유한 지연 시간,
+ 지표 `CapacityProviderReservation`이 CloudWatch 경보(높음 및 낮음 모두)를 위반하는 데 걸리는 시간,
+ 새로 시작한 Amazon EC2 인스턴스가 워밍업하는 데 걸리는 시간이 있습니다. 더 빠른 배포를 위해 클러스터 Auto Scaling의 응답성을 높이려면 다음 작업을 수행할 수 있습니다.
## 용량 제공자 단계 규모 조정 크기
Amazon ECS 용량 공급자는 애플리케이션의 요구 사항을 충족하기 위해 컨테이너 인스턴스를 늘리거나 줄일 것입니다. Amazon ECS가 시작할 최소 인스턴스 수는 기본적으로 1로 설정됩니다. 보류 중인 작업을 배치하는 데 여러 인스턴스가 필요한 경우 배포 시간이 추가될 수 있습니다. Amazon ECS API를 통해 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html)를 늘려 Amazon ECS가 한 번에 스케일 인하거나 스케일 아웃하는 최소 인스턴스 수를 늘릴 수 있습니다. [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html)가 너무 낮으면 한 번에 스케일 인 또는 스케일 아웃하는 컨테이너 인스턴스 수를 제한하여 배포 속도가 느려질 수 있습니다.
**참고**
이 구성은 현재 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) 또는 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) API를 통해서만 사용할 수 있습니다.
## 인스턴스 워밍업 기간
인스턴스 워밍업 기간은 새로 시작된 Amazon EC2 인스턴스가 Auto Scaling 그룹의 CloudWatch 지표에 기여할 수 있는 기간입니다. 지정된 워밍업 기간이 만료되면 인스턴스는 Auto Scaling 그룹의 집계된 지표로 계산되고 클러스터 Auto Scaling은 다음 계산 반복을 진행하여 필요한 인스턴스 수를 추정합니다.
[https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod)의 기본값은 300초이며 보다 반응성이 뛰어난 조정을 위해 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) 또는 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) API를 통해 더 낮은 값으로 구성할 수 있습니다. 과다 프로비저닝을 방지하려면 값을 60초 이상으로 설정하는 것이 좋습니다.
## 예비 용량
용량 공급자가 작업 배치에 사용할 수 있는 컨테이너 인스턴스가 없는 경우 Amazon EC2 인스턴스를 즉시 시작하여 클러스터 용량을 늘리고(스케일 아웃) 컨테이너를 시작하기 전에 해당 인스턴스가 부팅될 때까지 기다려야 합니다. 이로 인해 작업 시작 속도가 크게 느려질 수 있습니다. 여기에서는 두 가지 옵션이 있습니다.
이 경우 예비 Amazon EC2 용량이 이미 시작되어 태스크를 실행할 준비가 되어 있으면 효과적인 작업 시작 속도가 빨라집니다. `Target Capacity` 구성을 사용하여 클러스터의 예비 용량을 유지하도록 지정할 수 있습니다. 예를 들어 `Target Capacity`를 80%로 설정하면 클러스터에 항상 20%의 예비 용량이 필요함을 나타냅니다. 이 여유 용량을 통해 모든 독립 실행형 태스크를 즉시 시작할 수 있으므로 태스크 시작이 제한되지 않습니다. 이 접근 방식의 단점은 예비 클러스터 용량을 유지하는 데 드는 비용이 증가할 수 있다는 것입니다.
고려할 수 있는 또 다른 접근 방식은 용량 공급자가 아닌 서비스에 헤드룸을 추가하는 것입니다. 즉, 예비 용량을 시작하기 위한 `Target Capacity` 구성을 줄이는 대신 대상 추적 조정 지표 또는 서비스 Auto Scaling의 단계 규모 조정 임계값을 수정하여 서비스의 복제본 수를 늘릴 수 있습니다. 이 접근 방식은 워크로드가 급증하는 경우에만 유용하며 새 서비스를 배포하거나 처음으로 0개에서 N개의 태스크로 전환하는 경우에는 효과가 없다는 점에 유의하세요. 관련 규모 조정 정책에 대한 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*에서 [대상 추적 조정 정책](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) 또는 [단계 조정 정책](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html)을 참조하세요.
# Amazon ECS 관리형 규모 조정 동작
관리형 규모 조정을 사용하는 Auto Scaling 그룹 용량 공급자가 있는 경우 Amazon ECS에서는 클러스터에 추가할 인스턴스의 최적 개수를 예측하고 이 값을 사용하여 요청하거나 릴리스할 인스턴스 수를 결정합니다.
## 관리형 확장 동작
Amazon ECS는 서비스, 독립 실행형 태스크 또는 클러스터 기본값의 용량 공급자 전략에 따라 각 태스크에 대한 용량 공급자를 선택합니다. 단일 용량 공급자의 경우 Amazon ECS는 이러한 단계의 나머지 내용을 따릅니다.
용량 공급자 전략이 없는 작업은 용량 공급자가 무시합니다. 용량 공급자 전략이 없는 보류 중인 작업의 경우 용량 공급자가 스케일 아웃하지 않습니다. 시작 유형을 설정하는 작업 또는 서비스에서는 용량 공급자 전략을 설정할 수 없습니다.
관리형 확장에 대한 자세한 설명은 아래와 같습니다.
+ 각 그룹에 똑같은 리소스 요구 사항이 적용되도록 이 용량 공급자의 모든 프로비저닝 작업을 그룹화합니다.
+ Auto Scaling 그룹에서 여러 인스턴스 유형을 사용하는 경우 Auto Scaling 그룹의 인스턴스 유형은 파라미터를 기준으로 정렬됩니다. 이러한 파라미터에는 vCPU, 메모리, 탄력적 네트워크 인터페이스(ENI), 포트, GPU 등이 있습니다. 각 파라미터의 가장 작은 인스턴스 유형과 가장 큰 인스턴스 유형이 선택됩니다. 인스턴스 유형을 선택하는 방법에 대한 자세한 내용은 [Amazon ECS에 대한 Amazon EC2 컨테이너 인스턴스](create-capacity.md) 섹션을 참조하세요.
**중요**
작업 그룹의 리소스 요구 사항이 Auto Scaling 그룹의 가장 작은 인스턴스 유형보다 큰 경우 해당 작업 그룹은 이 용량 공급자로 실행할 수 없습니다. 용량 공급자는 Auto Scaling 그룹의 규모를 조정하지 않습니다. 작업은 `PROVISIONING` 상태로 유지됩니다.
작업이 `PROVISIONING` 상태로 유지되지 않도록 하려면 여러 최소 리소스 요구 사항에 대해 Auto Scaling 그룹과 용량 공급자를 별도로 생성하는 것이 좋습니다. 작업을 실행하거나 서비스를 생성할 때 Auto Scaling 그룹의 가장 작은 인스턴스 유형에서 작업을 실행할 수 있는 용량 공급자 전략에만 용량 공급자를 추가하세요. 다른 파라미터에는 배치 제약 조건을 사용할 수 있습니다.
+ 각 작업 그룹에 대해 Amazon ECS는 배치되지 않은 작업을 실행하는 데 필요한 인스턴스 개수를 계산합니다. 이 계산에서는 `binpack` 전략을 사용합니다. 이 전략은 작업의 vCPU, 메모리, 탄력적 네트워크 인터페이스(ENI), 포트, GPU 요구 사항을 고려합니다. 또한 Amazon EC2 인스턴스의 리소스 가용성을 고려합니다. 가장 큰 인스턴스 유형의 값은 계산된 최대 인스턴스 개수로 처리됩니다. 가장 작은 인스턴스 유형에 대한 값은 보호로 사용됩니다. 가장 작은 인스턴스 유형이 작업의 인스턴스를 하나 이상 실행할 수 없는 경우 계산에서 작업을 호환되지 않는 것으로 간주합니다. 따라서 스케일 아웃 계산에서 작업이 제외됩니다. 모든 작업이 가장 작은 인스턴스 유형과 호환되지 않으면 클러스터 Auto Scaling이 중지되고 `CapacityProviderReservation` 값은 `targetCapacity` 값으로 유지됩니다.
+ Amazon ECS는 다음 중 하나에 해당하는 경우 `minimumScalingStepSize`를 기준으로 `CapacityProviderReservation` 지표를 CloudWatch에 게시합니다.
+ 계산된 최대 인스턴스 수가 최소 조정 단계 크기보다 작습니다.
+ `maximumScalingStepSize` 또는 계산된 최대 인스턴스 수 중 낮은 값입니다.
+ CloudWatch 경보는 용량 공급자에 `CapacityProviderReservation` 지표를 사용합니다. `CapacityProviderReservation` 지표가 `targetCapacity` 값보다 크면 경보로 인해 Auto Scaling 그룹의 `DesiredCapacity`가 증가합니다. `targetCapacity` 값은 클러스터 Auto Scaling 활성화 단계에서 CloudWatch 경보로 전송되는 용량 공급자 설정입니다.
`targetCapacity`의 기본값은 100%입니다.
+ Auto Scaling 그룹은 추가 EC2 인스턴스를 시작합니다. 오버프로비저닝을 방지하기 위해, Auto Scaling은 최근에 시작된 EC2 인스턴스 용량이 새 인스턴스를 시작하기 전에 안정화되었는지 확인합니다. Auto Scaling이 모든 기존 인스턴스가 `instanceWarmupPeriod`를 통과했는지 검사합니다(현재에서 인스턴스 시작 시간을 뺀 값). `instanceWarmupPeriod` 내에 있는 인스턴스에 대해 스케일 아웃이 차단됩니다.
새로 시작된 인스턴스의 기본 워밍업 시간은 300초입니다.
자세한 내용은 [Deep dive on Amazon ECS cluster auto scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)(Amazon ECS 클러스터 Auto Scaling 심층 분석)을 참조하세요.
### 확장 고려 사항
확장 프로세스에 대해 다음 사항을 고려하세요.
+ 여러 배치 제약이 있지만 `distinctInstance` 작업 배치 제약만 사용하는 것을 권장합니다. 이는 샘플링된 인스턴스와 호환되지 않는 배치 제약 조건을 사용하기 때문에 스케일 아웃 프로세스가 중지되지 않습니다.
+ 관리형 확장은 Auto Scaling 그룹에서 동일하거나 유사한 인스턴스 유형을 사용해야 가장 효과적입니다.
+ 스케일 아웃 프로세스가 필요하고 현재 실행 중인 컨테이너 인스턴스가 없으면 Amazon ECS는 항상 처음에는 인스턴스 2개로 스케일 아웃한 다음 추가 스케일 아웃 또는 스케일 인 프로세스를 수행합니다. 인스턴스 워밍업 기간에는 추가 스케일 아웃이 대기합니다. 스케일 인 프로세스의 경우 Amazon ECS는 항상 스케일 아웃 프로세스 후 15분을 기다린 다음 스케일 인 프로세스를 시작합니다.
+ 두 번째 스케일 아웃 단계는 전체 스케일링 제한에 영향을 미칠 수 있는 `instanceWarmupPeriod`가 만료될 때까지 기다려야 합니다. 이 시간을 줄여야 하는 경우 EC2 인스턴스가 Amazon ECS 에이전트(오버프로비저닝 방지)를 시작하고 시작할 수 있을 만큼 `instanceWarmupPeriod`가 충분히 커야 합니다.
+ 클러스터 Auto Scaling은 용량 공급자 Auto Scaling에서 시작 구성, 시작 템플릿 및 여러 인스턴스 유형을 지원합니다. 또한 여러 인스턴스 유형 없이 속성 기반 인스턴스 유형 선택을 사용할 수도 있습니다.
+ Auto Scaling 그룹과 온디맨드 인스턴스, 여러 인스턴스 유형 또는 스팟 인스턴스를 사용할 경우 우선순위 목록에서 용량이 큰 인스턴스 유형을 높은 순위에 올리고 가중치를 지정하지 않습니다. 현재는 가중치 지정을 지원하지 않습니다. 자세한 정보는 *AWS Auto Scaling 사용 설명서*의 [여러 인스턴스 유형을 제공하는 Auto Scaling 그룹](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html)을 참조하세요.
+ 그러면 Amazon ECS가 계산된 인스턴스 최댓값이 최소 조정 단계 크기보다 작을 경우 `minimumScalingStepSize`를 시작하고, 그렇지 않으면 `maximumScalingStepSize` 또는 계산된 인스턴스 개수의 최댓값 중 작은 개수를 시작합니다.
+ Amazon ECS 서비스 또는 `run-task`가 작업을 시작하고 용량 공급자 컨테이너 인스턴스에 작업을 시작하기에 충분한 리소스가 없는 경우 Amazon ECS는 각 클러스터에 대해 이 상태의 작업 수를 제한하고 이 제한을 초과하여 작업이 실행되지 않도록 합니다. 자세한 내용은 [Amazon ECS 서비스 할당량](service-quotas.md) 섹션을 참조하세요.
## 관리형 축소 동작
Amazon ECS는 클러스터 내의 각 용량 공급자에 대한 컨테이너 인스턴스를 모니터링합니다. 컨테이너 인스턴스에 실행 중인 작업이 없으면 컨테이너 인스턴스는 비어 있는 것으로 간주되고 Amazon ECS는 스케일 인 프로세스를 시작합니다.
CloudWatch 축소 경보에는 Auto Scaling 그룹의 축소 프로세스가 시작되기 전에 15데이터 포인트(15분)가 필요합니다. Amazon ECS가 등록된 컨테이너 인스턴스의 수를 줄여야 할 때까지 축소 프로세스가 시작된 후, Auto Scaling 그룹은 `DesireCapacity` 값을 인스턴스 1개보다 크고 매분 50% 미만으로 설정합니다.
스케일 인 프로세스가 진행 중인 동안 Amazon ECS가 스케일 아웃을 요청하는 경우(`CapacityProviderReservation`이 100보다 큼) 스케일 인 프로세스가 중지되고 필요한 경우 처음부터 시작됩니다.
다음은 스케일 인 동작에 대해 자세히 설명합니다.
1. Amazon ECS는 비어 있는 컨테이너 인스턴스의 수를 계산합니다. 대몬(daemon) 작업이 실행 중인 경우에도 컨테이너 인스턴스는 비어 있는 것으로 간주됩니다.
1. Amazon ECS는 다음 수식을 사용하여 Auto Scaling 그룹의 실제 크기 대비 필요한 크기의 비율을 백분율로 나타내는 0\$1100 사이의 숫자로 `CapacityProviderReservation` 값을 설정합니다. Amazon ECS는 CloudWatch에 지표를 게시합니다. 지표를 계산하는 방법에 대한 자세한 내용은 [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)을 참조하세요.
```
CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
```
1. `CapacityProviderReservation` 지표는 CloudWatch 경보를 생성합니다. 이 경보는 Auto Scaling 그룹에 대한 `DesiredCapacity` 값을 업데이트합니다. 그러면 다음 작업 중 하나가 수행됩니다.
+ 용량 공급자 관리형 종료를 사용하지 않는 경우 Auto Scaling 그룹은 Auto Scaling 그룹 종료 정책을 사용하여 EC2 인스턴스를 선택하고 EC2 인스턴스 수가 `DesiredCapacity`에 도달할 때까지 인스턴스를 종료합니다. 그런 다음 컨테이너 인스턴스가 클러스터에서 등록 취소됩니다.
+ 모든 컨테이너 인스턴스가 관리형 종료 보호를 사용하는 경우 Amazon ECS는 비어 있는 컨테이너 인스턴스에서 스케일 인 보호를 제거합니다. 그러면 Auto Scaling 그룹에서 EC2 인스턴스를 종료할 수 있습니다. 그런 다음 컨테이너 인스턴스가 클러스터에서 등록 취소됩니다.
# Amazon ECS가 종료하는 인스턴스 제어
**중요**
클러스터 Auto Scaling의 관리형 종료 보호 기능을 사용하려면 Auto Scaling 그룹에서 Auto Scaling* *인스턴스 스케일 인 보호를 켜야 합니다.
관리형 종료 보호 기능을 사용하면 클러스터 Auto Scaling을 통해 종료되는 인스턴스를 제어할 수 있습니다. 관리형 종료 보호 기능을 사용한 경우 Amazon ECS는 실행 중인 Amazon ECS 태스크가 없는 EC2 인스턴스만 종료합니다. `DAEMON` 일정 전략을 사용하는 서비스에서 실행하는 작업은 무시되며 인스턴스에서 이러한 작업을 실행 중인 경우에도 클러스터 Auto Scaling에서 인스턴스를 종료될 수 있습니다. 클러스터의 모든 인스턴스가 이러한 작업을 실행하고 있기 때문입니다.
Amazon ECS는 먼저 Auto Scaling 그룹에서 EC2 인스턴스에 대한 **인스턴스 스케일 인 보호 옵션을 켭니다. 그런 다음 Amazon ECS는 인스턴스에 작업을 배치합니다. 인스턴스에서 모든 대몬이 아닌 작업이 중지되면 Amazon ECS는 축소 프로세스를 시작하고 EC2 인스턴스에 대한 축소 보호를 해제합니다. 그러면 Auto Scaling 그룹에서 인스턴스를 종료할 수 있습니다.
Auto Scaling* *인스턴스 스케일 인 보호는 Auto Scaling에서 종료할 수 있는 EC2 인스턴스를 제어합니다. 스케일 인 기능이 켜진 인스턴스는 스케일 인 프로세스 중에 종료할 수 없습니다. Auto Scaling 인스턴스 스케일 인 보호에 대한 자세한 내용은* *Amazon EC2 Auto Scaling 사용 설명서의 [Using instance scale-in protection](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html)을 참조하세요.
`targetCapacity` 비율을 설정하여 여유 용량을 확보할 수 있습니다. 이러한 방식으로 Auto Scaling 그룹이 더 많은 인스턴스를 시작할 때까지 기다리지 않고 향후 작업을 더 빠르게 시작할 수 있습니다. Amazon ECS는 목표 용량 값을 사용하여 서비스가 생성하는 CloudWatch 지표를 관리합니다. Amazon ECS는 CloudWatch 지표를 관리합니다. Auto Scaling 그룹은 안정 상태로 처리되어 규모 조정 작업이 필요하지 않습니다. 값은 0\$1100%가 될 수 있습니다. 예를 들어, Amazon ECS 작업에서 사용하는 용량 외에 10%의 여유 용량을 유지하도록 Amazon ECS를 구성하려면 대상 용량 값을 90%로 설정합니다. 용량 공급자에 대한 `targetCapacity` 값을 설정할 때는 다음 사항을 고려해야 합니다.
+ 100% 미만의 `targetCapacity` 값은 클러스터에 있어야 하는 사용 가능한 용량(Amazon EC2 인스턴스)의 양을 나타냅니다. 여유 용량은 실행 중인 작업이 없음을 의미합니다.
+ 추가 `binpack`이 없는 가용 영역과 같은 배치 제약 조건은 Amazon ECS가 최종적으로 인스턴스당 하나의 작업을 실행하도록 하며, 이는 바람직한 동작이 아닐 수 있습니다.
관리형 종료 보호를 사용하려면 Auto Scaling 그룹에서 Auto Scaling 인스턴스 스케일 인 보호를 켜야 합니다. 스케일 인 보호를 켜지 않고 관리형 종료 보호를 켜는 경우 원치 않는 동작이 발생할 수 있습니다. 예를 들어 인스턴스가 드레이닝 상태에서 멈출 수 있습니다. 자세한 정보는 *Amazon EC2 Auto Scaling 사용 설명서*의 [인스턴스 스케일 인 방지 사용](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html)을 참조하세요.
용량 공급자와 함께 종료 보호를 사용하는 경우에는 용량 공급자와 연결된 Auto Scaling 그룹에서 인스턴스 분리와 같은 수동 작업을 수행하지 마세요. 수동 작업으로 인해 용량 공급자의 스케일 인 작업이 중단될 수 있습니다. Auto Scaling 그룹에서 인스턴스를 분리하는 경우 Amazon ECS 클러스터에서 [분리된 인스턴스를 등록 취소](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deregister_container_instance.html)해야 합니다.
# Amazon ECS 용량 공급자의 관리형 종료 방지 기능 업데이트
관리형 종료 방지 기능을 사용하는 경우 기존 용량 공급자의 설정을 업데이트해야 합니다.
## 콘솔
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다.
1. 클러스터 페이지에서 **인프라** 탭을 선택하세요.
1. 용량 공급자를 선택하세요.
1. **업데이트**를 선택하여 용량 공급자 설정을 수정합니다.
1. **Auto Scaling 그룹 설정**에서 **관리형 종료 방지 기능**을 전환하여 기능을 활성화하거나 비활성화합니다.
1. **업데이트**를 선택합니다.
## AWS CLI
다음 `update-capacity-provider` 명령을 사용하여 용량 공급자의 관리형 종료 방지 기능 설정을 업데이트할 수 있습니다.
관리형 종료 방지 기능을 활성화하려면
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=ENABLED"
```
관리형 종료 방지 기능을 비활성화하려면
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=DISABLED"
```
**참고**
클러스터 전체에 변경 사항이 적용되려면 몇 분 정도 걸릴 수 있습니다. 관리형 종료 방지 기능을 활성화하면 이미 태스크를 실행 중인 인스턴스가 스케일 인 이벤트로부터 보호됩니다. 관리형 종료 방지 기능을 비활성화하면 다음 ECS 용량 공급자 관리 주기 동안 인스턴스에서 보호 플래그가 제거됩니다.
## 태스크 실행을 위한 콘솔
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다.
1. 클러스터 페이지에서 **태스크** 탭을 선택하세요.
1. 작업을 선택합니다.
1. **구성**에서 **관리형 종료 방지 기능**을 전환하여 기능을 활성화하거나 비활성화하세요.
1. **Task scale-in protection 구성**을 선택하세요.
**Task scale-in protection 구성** 대화 상자가 표시됩니다.
1. **Task scale-in protection**에서 **켜기**로 전환하세요.
1. **만료(분)**에 Task scale-in protection이 종료되기 전의 시간(분)을 입력하세요.
1. **Update(업데이트)**를 선택합니다.
# Amazon ECS 클러스터 Auto Scaling 켜기
클러스터 오토 스케일링을 사용 설정하면 Amazon ECS가 클러스터에 등록된 Amazon EC2 인스턴스의 규모 조정을 관리합니다.
콘솔을 사용하여 클러스터 오토 스케일링을 활성화하려면 [Amazon ECS를 위한 용량 공급자 생성](create-capacity-provider-console-v2.md) 섹션을 참조하세요.
시작하기 전에 Auto Scaling 그룹과 용량 공급자를 생성합니다. 자세한 내용은 [EC2 워크로드를 위한 Amazon ECS 용량 공급자](asg-capacity-providers.md) 섹션을 참조하세요.
클러스터 Auto Scaling을 켜려면 용량 공급자를 클러스터와 연결한 다음 클러스터 Auto Scaling을 켭니다.
1. `put-cluster-capacity-providers` 명령을 사용하여 하나 이상의 용량 공급자를 클러스터와 연결합니다.
AWS Fargate 용량 공급자를 추가하려면 요청에 `FARGATE` 및 `FARGATE_SPOT` 용량 공급자를 포함합니다. 자세한 정보는 *AWS CLI 명령 참조*의 `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` 섹션을 참조하세요.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers CapacityProviderName FARGATE FARGATE_SPOT \
--default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
```
EC2에서 Auto Scaling 그룹을 추가하려면 요청에 Auto Scaling 그룹 이름을 포함합니다. 자세한 정보는 *AWS CLI 명령 참조*의 `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` 섹션을 참조하세요.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers CapacityProviderName \
--default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
```
1. `describe-clusters` 명령을 사용하여 연결에 성공했는지 확인합니다. 자세한 정보는 *AWS CLI 명령 참조*의 `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` 섹션을 참조하세요.
```
aws ecs describe-clusters \
--cluster ClusterName \
--include ATTACHMENTS
```
1. `update-capacity-provider` 명령을 사용하여 용량 공급자에 대해 관리형 Auto Scaling을 사용 설정합니다. 자세한 정보는 *AWS CLI 명령 참조*의 `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` 섹션을 참조하세요.
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=ENABLED}"
```
# Amazon ECS 클러스터 Auto Scaling 끄기
클러스터에 등록된 EC2 인스턴스를 보다 세밀하게 제어해야 하는 경우 클러스터 오토 스케일링을 끕니다.
클러스터에 대한 클러스터 Auto Scaling을 해제하려면 용량 제공자를 클러스터에서 설정한 Managed Scaling과의 연결을 해제하거나 용량 공급자를 업데이트하여 Managed Scaling을 해제할 수 있습니다.
## 용량 공급자 연결 해제
용량 공급자를 클러스터와 연결 해제하려면 다음 단계를 수행합니다.
1. `put-cluster-capacity-providers` 명령을 사용하여 Auto Scaling 그룹 용량 공급자를 클러스터와 연결 해제합니다. 클러스터는 AWS Fargate 용량 공급자와의 연결을 유지할 수 있습니다. 자세한 정보는 *AWS CLI 명령 참조*의 `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` 섹션을 참조하세요.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers FARGATE FARGATE_SPOT \
--default-capacity-provider-strategy '[]'
```
`put-cluster-capacity-providers` 명령을 사용하여 Auto Scaling 그룹 용량 공급자를 클러스터와 연결 해제합니다. 자세한 정보는 *AWS CLI 명령 참조*의 `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` 섹션을 참조하세요.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers [] \
--default-capacity-provider-strategy '[]'
```
1. `describe-clusters` 명령을 사용하여 연결 해제에 성공했는지 확인합니다. 자세한 정보는 *AWS CLI 명령 참조*의 `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` 섹션을 참조하세요.
```
aws ecs describe-clusters \
--cluster ClusterName \
--include ATTACHMENTS
```
## 용량 공급자에 대해 관리형 조정 끄기
용량 공급자에 대해 관리형 조정을 해제하려면 다음 단계를 수행합니다.
+ `update-capacity-provider` 명령을 사용하여 용량 공급자에 대해 관리형 Auto Scaling을 사용 해제합니다. 자세한 정보는 *AWS CLI 명령 참조*의 `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` 섹션을 참조하세요.
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=DISABLED}"
```
# Amazon ECS를 위한 용량 공급자 생성
클러스터 생성이 완료된 후 EC2에 대한 새 용량 공급자(Auto Scaling 그룹)를 생성할 수 있습니다. 용량 공급자는 애플리케이션의 인프라 관리 및 확장에 도움이 됩니다.
용량 공급자를 생성하기 전에 Auto Scaling 그룹을 생성해야 합니다. 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*의 [오토 스케일링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)을 참조하세요.
**클러스터에 대한 용량 공급자 생성(Amazon ECS 콘솔)**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다.
1. **Cluster : *name***(클러스터: 이름) 페이지에서 **Infrastructure**(인프라)를 선택한 다음 **Create**(생성)를 선택합니다.
1. **Create capacity providers**(용량 공급자 생성) 페이지에서 다음 옵션을 구성합니다.
1. **Basic details**(기본 세부 정보)의 **Capacity provider name**(용량 공급자 이름)에 고유한 용량 공급자 이름을 입력합니다.
1. **Auto Scaling group**(오토 스케일링) 아래에서 **Use an existing Auto Scaling group**(기존 오토 스케일링 사용)에 대해 오토 스케일링을 선택합니다.
1. (선택 사항) 조정 정책을 구성하려면 **Scaling policies**(조정 정책)에서 다음 옵션을 구성합니다.
+ Amazon ECS에서 스케일 인 및 스케일 아웃 작업을 관리하도록 하려면 **Turn on managed scaling**(관리형 크기 조정 켜기)을 선택합니다.
+ 실행 중인 Amazon ECS 작업이 있는 EC2 인스턴스가 종료되지 않도록 하려면 **Turn on scaling protection**(크기 조정 보호 켜기)을 선택합니다.
+ **Set target capacity**(대상 용량 설정)에서 Amazon ECS 관리형 대상 추적 조정 정책에서 사용되는 CloudWatch 지표에 대한 대상 값을 입력합니다.
1. **생성(Create)**을 선택합니다.
# Amazon ECS 용량 공급자 업데이트
Auto Scaling 그룹을 용량 공급자로 사용하는 경우 그룹의 조정 정책을 수정할 수 있습니다.
**클러스터의 용량 공급자를 업데이트하는 방법(Amazon ECS 콘솔)**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다.
1. **Cluster : *name***(클러스터: 이름) 페이지에서 **Infrastructure**(인프라)를 선택한 다음 **Update**(업데이트)를 선택합니다.
1. **Create capacity providers**(용량 공급자 생성) 페이지에서 다음 옵션을 구성합니다.
1. **Auto Scaling group**(오토 스케일링)의 **Scaling policies**(스케일링 정책)에서 다음 옵션을 구성합니다.
+ Amazon ECS에서 스케일 인 및 스케일 아웃 작업을 관리하도록 하려면 **Turn on managed scaling**(관리형 크기 조정 켜기)을 선택합니다.
+ 실행 중인 Amazon ECS 작업이 있는 EC2 인스턴스가 종료되지 않도록 하려면 **크기 조정 보호 켜기**를 선택합니다.
+ **Set target capacity**(대상 용량 설정)에서 Amazon ECS 관리형 대상 추적 조정 정책에서 사용되는 CloudWatch 지표에 대한 대상 값을 입력합니다.
1. **업데이트**를 선택합니다.
# Amazon ECS 용량 공급자 삭제
사용을 마친 Auto Scaling 그룹 용량 공급자는 삭제할 수 있습니다. 그룹이 삭제된 후 Auto Scaling 그룹 용량 공급자는 `INACTIVE` 상태로 전환됩니다. `INACTIVE` 상태인 용량 공급자는 일정 기간 동안 계정에서 검색 가능한 상태로 유지될 수 있습니다. 하지만 이 동작은 향후 변경될 수 있으므로 `INACTIVE` 용량 공급자가 지속되는 상태에 의존해서는 안 됩니다. Auto Scaling 그룹 용량 공급자를 삭제하기 전에 모든 서비스의 용량 공급자 전략에서 해당 용량 공급자를 제거해야 합니다. Amazon ECS 콘솔의 `UpdateService` API 또는 업데이트 서비스 워크플로를 사용하여 서비스의 용량 공급자 전략에서 용량 공급자를 제거할 수 있습니다. **새 배포 강제 적용** 옵션을 사용하면 용량 공급자가 제공한 Amazon EC2 인스턴스 용량을 사용하는 모든 작업이 나머지 용량 공급자의 용량을 사용하도록 전환될 수 있습니다.
**클러스터에 대한 용량 공급자 삭제 방법(Amazon ECS 콘솔)**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다.
1. **Cluster : *name***(클러스터: name) 페이지에서 **Infrastructure**(인프라)를 선택하고 Auto Scaling을 선택한 다음 **Delete**(삭제)를 선택합니다.
1. 확인란에 **delete *Auto Scaling group name***(오토 스케일링 이름 삭제)을 입력합니다.
1. **삭제**를 선택합니다.
# EC2 인스턴스에서 실행되는 Amazon ECS 워크로드를 안전하게 중지
관리형 인스턴스 드레이닝은 Amazon EC2 인스턴스의 정상적인 종료를 지원합니다. 이를 통해 워크로드를 안전하게 중지하고 비종료 인스턴스로 일정을 다시 예약할 수 있습니다. 워크로드 중단에 대한 걱정 없이 인프라 유지 관리 및 업데이트가 수행됩니다. 관리형 인스턴스 드레이닝을 사용하면 Amazon EC2 인스턴스를 교체해야 하는 인프라 관리 워크플로를 간소화하는 동시에, 애플리케이션의 복원력과 가용성을 보장할 수 있습니다.
Amazon ECS 관리형 인스턴스 드레이닝은 Auto Scaling 그룹 인스턴스 교체와 함께 작동합니다. 인스턴스 새로 고침 및 최대 인스턴스 수명을 기준으로 고객은 용량에 대한 최신 OS 및 보안 요구 사항을 계속 준수해나갈 수 있습니다.
관리형 인스턴스 드레이닝은 Amazon ECS 용량 공급자와만 사용할 수 있습니다. Amazon ECS 콘솔, AWS CLI 또는 SDK를 사용하여 Auto Scaling 그룹 용량 공급자를 생성하거나 업데이트할 때 관리형 인스턴스 드레이닝을 켤 수 있습니다.
다음 이벤트는 Amazon ECS 관리형 인스턴스 드레이닝에 포함됩니다.
+ [Auto Scaling 그룹 인스턴스 새로 고침](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html) - Auto Scaling 그룹의 Amazon EC2 인스턴스를 배치 단위로 수동 교체하는 대신 인스턴스 새로 고침을 사용하여 롤링 교체를 수행합니다. 이 방법은 많은 인스턴스를 교체해야 하는 경우에 유용합니다. 인스턴스 새로 고침은 Amazon EC2 콘솔 또는 `StartInstanceRefresh` API를 통해 시작됩니다. 관리형 종료 보호를 사용하는 경우 `StartInstanceRefresh` 직접 호출 시 스케일 인 보호를 위해 `Replace`를 선택해야 합니다.
+ [최대 인스턴스 수명](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-max-instance-lifetime.html) ‐ Auto Scaling 그룹 인스턴스를 교체할 때 최대 수명을 정의할 수 있습니다. 이는 내부 보안 정책 또는 규정 준수를 기반으로 교체 인스턴스를 예약하는 데 유용합니다.
+ Auto Scaling 그룹 스케일 인 - 규모 조정 정책 및 예약된 조정 작업에 따라 Auto Scaling 그룹은 인스턴스의 자동 규모 조정을 지원합니다. Auto Scaling 그룹을 Amazon ECS 용량 공급자로 사용하면 실행 중인 태스크가 없을 때 Auto Scaling 그룹 인스턴스를 스케일 인할 수 있습니다.
+ [Auto Scaling 그룹 확인](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html) - Auto Scaling 그룹은 비정상 인스턴스의 종료를 관리하기 위한 많은 상태 확인을 지원합니다.
+ [CloudFormation 스택 업데이트](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-direct.html) – CloudFormation 스택에 `UpdatePolicy` 속성을 추가하여 그룹이 변경될 때 롤링 업데이트를 수행할 수 있습니다.
+ [스팟 용량 재조정](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) - Auto Scaling 그룹은 Amazon EC2 용량 재조정 알림에 따라 중단 위험이 더 높은 스팟 인스턴스를 사전에 교체하려고 합니다. Auto Scaling 그룹은 교체가 시작되고 정상 상태이면 이전 인스턴스를 종료합니다. Amazon ECS 관리형 인스턴스 드레이닝은 스팟이 아닌 인스턴스를 드레이닝하는 것과 동일한 방식으로 스팟 인스턴스를 드레이닝합니다.
+ [스팟 중단](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html) - 스팟 인스턴스는 2분 알림과 함께 종료됩니다. Amazon ECS 관리형 인스턴스 드레이닝은 이에 대응하여 인스턴스를 드레이닝 상태로 전환합니다.
**Amazon EC2 Auto Scaling 수명 주기 후크((관리형 인스턴스 드레이닝 포함)**
Auto Scaling 그룹 수명 주기 후크를 사용하면 고객이 인스턴스 수명 주기의 특정 이벤트에 의해 트리거되는 솔루션을 생성하고 해당 특정 이벤트가 발생할 때 사용자 지정 작업을 수행할 수 있습니다. Auto Scaling 그룹은 최대 50개의 후크를 허용합니다. 종료 후크는 여러 개 존재할 수 있고 병렬로 수행되며 Auto Scaling 그룹은 모든 후크가 완료될 때까지 기다렸다가 인스턴스를 종료합니다.
Amazon ECS 관리형 후크 종료 외에도, 고유한 수명 주기 종료 후크를 구성할 수 있습니다. 수명 주기 후크에는 `default action`이 있으며 Amazon ECS 관리형 후크와 같은 다른 후크가 사용자 지정 후크로 인한 오류의 영향을 받지 않도록 기본값으로 `continue`를 설정하는 것을 권장합니다.
Auto Scaling 그룹 종료 수명 주기 후크를 이미 구성하고 Amazon ECS 관리형 인스턴스 드레이닝도 활성화한 경우 두 수명 주기 후크가 모두 수행됩니다. 하지만 상대적 타이밍은 보장되지 않습니다. 수명 주기 후크에는 제한 시간이 경과했을 때 수행할 작업을 지정하는 `default action` 설정이 있습니다. 실패할 경우 사용자 지정 후크의 기본 결과로 `continue`를 사용하는 것이 좋습니다. 이렇게 하면 다른 후크, 특히 Amazon ECS 관리형 후크가 사용자 지정 수명 주기 후크에서 발생한 오류의 영향을 받지 않습니다. `abandon`의 대체 결과로 인해 다른 모든 후크를 건너뛰므로, 이는 사용하지 않는 것이 좋습니다. Auto Scaling 그룹 수명 주기 후크에 대한 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*의 [Amazon EC2 Auto Scaling 수명 주기 후크](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)를 참조하세요.
**작업 및 관리형 인스턴스 드레이닝**
Amazon ECS 관리형 인스턴스 드레이닝은 컨테이너 인스턴스에 있는 기존 드레이닝 기능을 사용합니다. [컨테이너 인스턴스 드레이닝](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-draining.html) 기능은 Amazon ECS 서비스에 속하는 복제 작업에서 교체를 수행하고 중지합니다. `RunTask`에 의해 간접적으로 호출되는 것과 같은 `PENDING` 또는 `RUNNING` 상태의 독립 실행형 태스크는 영향을 받지 않습니다. 태스크가 수동으로 완료되거나 중지될 때까지 기다려야 합니다. 컨테이너 인스턴스는 모든 작업이 중지되거나 48시간이 경과할 때까지 `DRAINING` 상태로 남아 있습니다. 모든 복제 작업이 중지된 후 대몬 작업이 마지막으로 중지됩니다.
**관리형 인스턴스 드레이닝 및 관리형 종료 보호**
관리형 인스턴스 드레이닝은 관리형 종료가 비활성화된 경우에도 작동합니다. 관리형 종료 보호 기능에 대한 자세한 내용은 [Amazon ECS가 종료하는 인스턴스 제어](managed-termination-protection.md) 섹션을 참조하세요.
다음 테이블에는 관리형 종료와 관리형 드레이닝의 다양한 조합에 대한 동작이 요약되어 있습니다.
| 관리형 종료 | 관리형 드레이닝 | 결과 |
| --- | --- | --- |
| 활성화됨 | 활성화됨 | Amazon ECS는 작업을 실행 중인 Amazon EC2 인스턴스가 스케일 인 이벤트로 인해 종료되지 않도록 보호합니다. 종료 보호가 설정되지 않거나 스팟 중단이 수신되었거나 인스턴스 새로 고침으로 강제 적용되는 인스턴스와 같이, 종료 중인 모든 인스턴스는 정상적으로 드레이닝됩니다. |
| 비활성 | 활성화됨 | Amazon ECS는 태스크를 실행하는 Amazon EC2 인스턴스의 스케일 인을 차단하지 않습니다. 하지만 종료되는 모든 인스턴스는 정상적으로 드레이닝됩니다. |
| 활성화됨 | 비활성화됨 | Amazon ECS는 작업을 실행 중인 Amazon EC2 인스턴스가 스케일 인 이벤트로 인해 종료되지 않도록 보호합니다. 하지만 스팟 중단 또는 강제 인스턴스 새로 고침으로 인해 또는 실행 중인 작업이 없는 경우에는 여전히 인스턴스가 종료될 수 있습니다. Amazon ECS는 이러한 인스턴스에 대해 정상적인 드레이닝을 수행하지 않으며, 중지된 후 교체 서비스 작업을 시작합니다. |
| 비활성화됨 | 비활성화됨 | Amazon EC2 인스턴스는 Amazon ECS 작업을 실행하는 경우에도 언제든지 스케일 인 또는 종료될 수 있습니다. Amazon ECS는 중지된 후 교체 서비스 작업을 시작합니다. |
**관리형 인스턴스 드레이닝 및 스팟 인스턴스 드레이닝**
스팟 인스턴스 드레이닝을 사용하면 Amazon ECS 에이전트에 `ECS_ENABLE_SPOT_INSTANCE_DRAINING` 환경 변수를 설정하여 2분간의 스팟 중단에 대응하여 Amazon ECS에서 인스턴스를 드레이닝 상태로 설정할 수 있습니다. Amazon ECS 관리형 인스턴스 드레이닝을 사용하면 스팟 중단뿐 아니라 여러 가지 이유로 종료되는 Amazon EC2 인스턴스의 정상적인 종료를 지원할 수 있습니다. 예를 들어 Amazon EC2 Auto Scaling 용량 재조정을 사용하여 중단 위험이 높은 스팟 인스턴스를 사전에 교체할 수 있으며 관리형 인스턴스 드레이닝은 교체되는 스팟 인스턴스를 정상적으로 종료합니다. 관리형 인스턴스 드레이닝을 사용하는 경우 스팟 인스턴스 드레이닝을 별도로 활성화할 필요가 없으므로 Auto Scaling 그룹 사용자 데이터의 `ECS_ENABLE_SPOT_INSTANCE_DRAINING`이 중복됩니다. 스팟 인스턴스 드레이닝에 대한 자세한 내용은 [스팟 인스턴스](create-capacity.md#container-instance-spot) 섹션을 참조하세요.
## EventBridge에서 관리형 인스턴스 드레이닝이 작동하는 방식
Amazon ECS 관리형 인스턴스 드레이닝 이벤트는 Amazon EventBridge에 게시되며, Amazon ECS는 계정의 기본 버스에서 EventBridge 관리형 규칙을 생성하여 관리형 인스턴스 드레이닝을 지원합니다. Lambda, Amazon SNS 및 Amazon SQS 등의 다른 AWS 서비스로 이러한 이벤트를 필터링하고 문제를 해결할 수 있습니다.
+ Amazon EC2 Auto Scaling은 수명 주기 후크를 간접적으로 호출할 때 EventBridge에 이벤트를 전송합니다.
+ 스팟 중단 알림은 EventBridge에 게시됩니다.
+ Amazon ECS는 Amazon ECS 콘솔과 API를 통해 검색할 수 있는 오류 메시지를 생성합니다.
+ EventBridge에서는 일시적 장애를 완화하기 위한 재시도 메커니즘이 기본 제공됩니다.
# 인스턴스를 안전하게 종료하도록 Amazon ECS 용량 공급자 구성
Amazon ECS 콘솔과 AWS CLI를 사용하여 Auto Scaling 그룹 용량 공급자를 생성하거나 업데이트할 때 관리형 인스턴스 드레이닝을 켤 수 있습니다.
**참고**
용량 공급자를 생성하면 관리형 인스턴스 드레이닝이 기본적으로 켜져 있습니다.
다음은 AWS CLI를 사용하여 관리형 인스턴스 드레이닝이 활성화된 상태에서 용량 공급자를 생성하고 클러스터의 기존 용량 공급자에 대해 관리형 인스턴스 드레이닝을 활성화하는 예제입니다.
**관리형 인스턴스 드레이닝 기능이 활성화된 상태에서 용량 공급자 생성**
관리형 인스턴스 드레이닝이 활성화된 상태로 용량 공급자를 생성하려면 `create-capacity-provider` 명령을 사용합니다. `managedDraining` 파라미터를 `ENABLED`로 설정합니다.
```
aws ecs create-capacity-provider \
--name capacity-provider \
--auto-scaling-group-provider '{
"autoScalingGroupArn": "asg-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1
},
"managedDraining": "ENABLED",
"managedTerminationProtection": "ENABLED",
}'
```
응답:
```
{
"capacityProvider": {
"capacityProviderArn": "capacity-provider-arn",
"name": "capacity-provider",
"status": "ACTIVE",
"autoScalingGroupProvider": {
"autoScalingGroupArn": "asg-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1
},
"managedTerminationProtection": "ENABLED"
"managedDraining": "ENABLED"
}
}
}
```
**클러스터의 기존 용량 공급자에 대해 관리형 인스턴스 드레이닝 활성화**
클러스터의 기존 용량 공급자에 대해 관리형 인스턴스 드레이닝을 활성화하려면 `update-capacity-provider` 명령을 사용합니다. `managedDraining`에서는 현재 `DISABLED`로 표시되고, `updateStatus`에서는 `UPDATE_IN_PROGRESS`로 표시됩니다.
```
aws ecs update-capacity-provider \
--name cp-draining \
--auto-scaling-group-provider '{
"managedDraining": "ENABLED"
}
```
응답:
```
{
"capacityProvider": {
"capacityProviderArn": "cp-draining-arn",
"name": "cp-draining",
"status": "ACTIVE",
"autoScalingGroupProvider": {
"autoScalingGroupArn": "asg-draining-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1,
"instanceWarmupPeriod": 300
},
"managedTerminationProtection": "DISABLED",
"managedDraining": "DISABLED" // before update
},
"updateStatus": "UPDATE_IN_PROGRESS", // in progress and need describe again to find out the result
"tags": [
]
}
}
```
`describe-clusters` 명령을 사용하고 `ATTACHMENTS`를 포함합니다. 관리형 인스턴스의 드레이닝 연결의 `status`는 `PRECREATED`이고 전체 `attachmentsStatus`는 `UPDATING`입니다.
```
aws ecs describe-clusters --clusters cluster-name --include ATTACHMENTS
```
응답:
```
{
"clusters": [
{
...
"capacityProviders": [
"cp-draining"
],
"defaultCapacityProviderStrategy": [],
"attachments": [
# new precreated managed draining attachment
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"type": "managed_draining",
"status": "PRECREATED",
"details": [
{
"name": "capacityProviderName",
"value": "cp-draining"
},
{
"name": "autoScalingLifecycleHookName",
"value": "ecs-managed-draining-termination-hook"
}
]
},
...
],
"attachmentsStatus": "UPDATING"
}
],
"failures": []
}
```
업데이트가 끝나면 `describe-capacity-providers`를 사용합니다. 그러면 `managedDraining`은 이제 `ENABLED`입니다.
```
aws ecs describe-capacity-providers --capacity-providers cp-draining
```
응답:
```
{
"capacityProviders": [
{
"capacityProviderArn": "cp-draining-arn",
"name": "cp-draining",
"status": "ACTIVE",
"autoScalingGroupProvider": {
"autoScalingGroupArn": "asg-draning-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1,
"instanceWarmupPeriod": 300
},
"managedTerminationProtection": "DISABLED",
"managedDraining": "ENABLED" // successfully update
},
"updateStatus": "UPDATE_COMPLETE",
"tags": []
}
]
}
```
## Amazon ECS 관리형 인스턴스 드레이닝 문제 해결
관리형 인스턴스 드레이닝 문제를 해결해야 할 수 있습니다. 다음은 사용 중 발생할 수 있는 문제와 그 해결 방법의 예입니다.
**Auto Scaling을 사용하는 경우 최대 인스턴스 수명을 초과한 후에도 인스턴스가 종료되지 않습니다.**
Auto Scaling 그룹을 사용하는 동안 최대 인스턴스 수명에 도달하거나 초과한 후에도 인스턴스가 종료되지 않으면 스케일 인으로부터 보호되기 때문일 수 있습니다. 관리형 종료를 끄고 관리형 드레이닝을 허용하여 인스턴스 재활용을 처리할 수 있습니다.
## Amazon ECS 관리형 인스턴스의 드레이닝 동작
Amazon ECS 관리형 인스턴스 종료는 비용을 최적화하고 시스템 상태를 유지 관리하면서 정상적인 워크로드 전환을 보장합니다. 종료 시스템은 인스턴스 종료에 대한 세 가지 결정 경로를 제공하며, 경로마다 타이밍 특성과 고객 영향 프로파일이 서로 다릅니다.
### 종료 결정 경로
고객이 시작한 종료
서비스에서 컨테이너 인스턴스를 즉시 제거해야 하는 경우 인스턴스 제거를 직접 제어합니다. 강제 플래그가 true로 설정된 DeregisterContainerInstance API를 직접 호출합니다. 이는 실행 중인 워크로드에도 불구하고 즉시 종료해야 함을 나타냅니다.
시스템에서 시작한 유휴 종료
Amazon ECS 관리형 인스턴스는 실행 중인 태스크(task)가 없는 유휴 컨테이너 인스턴스를 종료함으로써, 비용을 지속적으로 모니터링하고 선제적으로 최적화합니다. ECS는 컨테이너 인스턴스가 종료되기 전, 새로 시작된 태스크를 할당받을 수 있는 기회를 제공하기 위해 추측성 지연(heuristic delay) 방식을 사용합니다. `scaleInAfter` Amazon ECS 관리형 인스턴스의 용량 공급자 설정 파라미터를 통해 사용자 지정이 가능합니다.
인프라 새로 고침 종료
Amazon ECS 관리형 인스턴스는 워크로드의 가용성을 유지하는 동시에 보안 및 규정 준수를 보장하기 위해, 관리형 컨테이너 인스턴스의 소프트웨어를 자동으로 관리하고 업데이트합니다. 자세한 내용은 [Amazon ECS 관리형 인스턴스의 패치 작업](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html)을 참조하세요.
### 원활한 드레이닝 및 워크로드 마이그레이션
정상적인 드레이닝 시스템은 Amazon ECS 서비스 관리와의 정교한 조정을 구현하여 서비스 관리형 태스크가 종료 예약된 인스턴스에서 적절하게 마이그레이션되도록 합니다.
**서비스 태스크 드레이닝 조정**
인스턴스가 드레이닝 중 상태로 전환되면 Amazon ECS 스케줄러는 기존 서비스 태스크에 대한 정상적인 종료 절차를 구현하는 동안 인스턴스에 새 태스크 배치를 자동으로 중지합니다. 서비스 태스크 드레이닝에는 최적의 마이그레이션 타이밍과 성공률을 보장하기 위해 서비스 배포 전략, 상태 확인 요구 사항 및 드레이닝 기본 설정과의 조정이 포함됩니다.
**독립 실행형 태스크 처리**
독립 실행형 태스크는 자동 서비스 관리의 이점을 활용하지 않기 때문에 다른 처리가 필요합니다. 시스템은 태스크 기간 추정치, 완료 확률 분석, 고객 영향 평가를 포함한 독립 실행형 태스크 특성을 평가합니다. 정상적인 완료 전략은 연장된 유예 기간에 독립 실행형 태스크를 자연스럽게 완료할 수 있도록 하는 반면, 강제 종료는 태스크가 자연스럽게 완료되지 않은 경우 허용 가능한 기간에 인프라 새로 고침을 수행하도록 합니다.
### 2단계 완료 전략
종료 시스템은 인프라 관리 요구 사항과 워크로드 연속성의 균형을 맞추는 2단계 접근 방식을 구현합니다.
**1단계: 정상적 완료 기간**
이 단계에서 시스템은 워크로드 연속성을 우선하는 적절한 드레이닝 전략을 구현합니다. 서비스 태스크는 정상적인 Amazon ECS 예약 프로세스를 통해 정상적으로 드레이닝되고, 독립 실행형 태스크는 계속 실행되며 자연적으로 완료될 수 있으며, 시스템은 모든 태스크가 자연적인 완료 프로세스를 통해 중지 상태에 도달하는지 모니터링합니다.
**2단계: 엄격한 기한 적용**
정상적인 완료 시 허용 가능한 기간에 종료 목표를 달성하지 못하면 시스템은 엄격한 기한 적용을 구현합니다. 하드 기한은 일반적으로 드레이닝 시작 시간 \$1 7일로 설정되어 운영 요구 사항을 유지하면서 정상적으로 완료할 수 있는 상당한 시간을 제공합니다. 적용에는 강제 등록 취소 절차의 자동 간접 호출과 완료 상태에 관계없이 나머지 모든 태스크의 즉각적인 종료가 포함됩니다.
# AWS Management Console을 사용하여 Amazon ECS 클러스터 Auto Scaling에 대한 리소스 생성
AWS Management Console을 사용하여 클러스터 Auto Scaling을 위한 리소스를 생성하는 방법을 알아보세요. 리소스에 이름이 필요한 경우 접두사 `ConsoleTutorial`을 사용하여 모든 리소스가 고유한 이름을 가지도록 하고 쉽게 찾을 수 있도록 합니다.
**Topics**
+ [
## 사전 조건
](#console-tutorial-prereqs)
+ [
## 1단계: Amazon ECS 클러스터 생성
](#console-tutorial-cluster)
+ [
## 2단계: 태스크 정의 등록
](#console-tutorial-register-task-definition)
+ [
## 3단계: 작업 실행
](#console-tutorial-run-task)
+ [
## 4단계: 확인
](#console-tutorial-verify)
+ [
## 5단계: 정리
](#console-tutorial-cleanup)
## 사전 조건
이 자습서에서는 다음 사전 조건이 충족되었다고 가정합니다.
+ [Amazon ECS 사용 설정](get-set-up-for-amazon-ecs.md)의 단계가 완료되었습니다.
+ IAM 사용자는 [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) IAM 정책 예제에 지정된 필수 권한을 가집니다.
+ Amazon ECS 컨테이너 인스턴스 IAM 역할이 생성됩니다. 자세한 정보는 [Amazon ECS 컨테이너 인스턴스 IAM 역할](instance_IAM_role.md) 섹션을 참조하세요.
+ Amazon ECS 서비스 연결 IAM 역할이 생성됩니다. 자세한 정보는 [Amazon ECS에 대해 서비스 연결 역할 사용](using-service-linked-roles.md) 섹션을 참조하세요.
+ Auto Scaling 서비스 연결 IAM 역할이 생성됩니다. 자세한 정보는 *Amazon EC2 Auto Scaling 사용 설명서*의 [Amazon EC2 Auto Scaling 서비스 연결 역할](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html)을 참조하세요.
+ 사용할 VPC 및 보안 그룹이 생성되었습니다. 자세한 내용은 [Virtual Private Cloud 생성](get-set-up-for-amazon-ecs.md#create-a-vpc) 섹션을 참조하세요.
## 1단계: Amazon ECS 클러스터 생성
다음 단계에 따라 Amazon ECS 클러스터를 생성합니다.
Amazon ECS는 CloudFormation 스택의 일부로 사용자를 대신하여 Amazon EC2 Auto Scaling 시작 템플릿과 Auto Scaling 그룹을 생성합니다.
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 창에서 **클러스터**를 선택한 다음 **클러스터 생성**을 선택합니다.
1. **Cluster configuration**(클러스터 구성)의 **Cluster name**(클러스터 이름)에 `ConsoleTutorial-cluster`를 입력합니다.
1. **인프라**에서 AWS Fargate(서버리스)를 선택 취소한 다음 **Amazon EC2 인스턴스**를 선택합니다. 다음으로 용량 공급자 역할을 하는 Auto Scaling 그룹을 구성합니다.
1. **Auto Scaling 그룹(ASG)**에서 다음을 수행합니다. **새 ASG 생성**을 선택한 후 그룹에 대한 다음 세부 정보를 입력합니다.
+ **Operating system/Architecture**(운영 체제/아키텍처)에서 **Amazon Linux 2**를 선택합니다.
+ **EC2 instance type**(EC2 인스턴스 유형)에서 **t3.nano**를 선택합니다.
+ **용량(Capacity)**에 Auto Scaling 그룹에서 시작할 최소 인스턴스 수와 최대 인스턴스 수를 입력합니다.
1. (선택 사항) 클러스터 태그를 관리하려면 **태그(Tags)**를 확장하고 다음 작업 중 하나를 수행합니다.
[태그 추가] **태그 추가(Add tag)**를 선택하고 다음을 수행합니다.
+ **키(Key)**에 키 이름을 입력합니다.
+ **값**에 키 값을 입력합니다.
[태그 제거] 태그의 키와 값 오른쪽에 있는 **제거**를 선택합니다.
1. **생성(Create)**을 선택합니다.
## 2단계: 태스크 정의 등록
클러스터에서 태스크를 실행하려면 먼저 태스크 정의를 등록해야 합니다. 태스크 정의는 그룹화된 컨테이너의 목록입니다. 다음 예제는 Docker Hub의 `amazonlinux` 이미지를 사용하고 대기하는 간단한 태스크 정의입니다. 사용 가능한 태스크 정의 파라미터에 대한 자세한 정보는 [Amazon ECS 작업 정의](task_definitions.md) 섹션을 참조하세요.
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 창에서 **작업 정의**를 선택합니다.
1. **새 태스크 정의 생성(Create new task definition)**, **JSON으로 새 태스크 정의 생성(Create new task definition with JSON)**을 선택합니다.
1. **JSON 편집기** 상자에서 다음 내용을 복사하여 붙여 넣습니다.
```
{
"family": "ConsoleTutorial-taskdef",
"containerDefinitions": [
{
"name": "sleep",
"image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
"memory": 20,
"essential": true,
"command": [
"sh",
"-c",
"sleep infinity"
]
}
],
"requiresCompatibilities": [
"EC2"
]
}
```
1. **생성(Create)**을 선택합니다.
## 3단계: 작업 실행
계정에 대한 태스크 정의를 등록한 후 클러스터에서 태스크를 실행할 수 있습니다. 이 자습서에서는 `ConsoleTutorial-taskdef` 클러스터에서 `ConsoleTutorial-cluster` 태스크 정의의 인스턴스 5개를 실행합니다.
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. **클러스터** 페이지에서 **ConsoleTutorial-cluster**를 선택합니다.
1. **작업에**서 **새 작업 실행**을 선택합니다.
1. **환경** 섹션의 **컴퓨팅 옵션**에서 **용량 공급자 전략**을 선택합니다.
1. **배포 구성**에서 **애플리케이션 유형**으로 **작업을** 선택합니다.
1. **패밀리** 드롭다운 목록에서 **ConsoleTutorial-taskdef**를 선택합니다.
1. **원하는 작업에** 5를 입력합니다.
1. **생성(Create)**을 선택합니다.
## 4단계: 확인
자습서의 이 지점에서, 5개의 작업이 실행되는 클러스터와 용량 공급자가 있는 Auto Scaling 그룹이 있어야 합니다. 용량 공급자가 Amazon ECS 관리형 조정을 활성화했습니다.
CloudWatch 지표, Auto Scaling 그룹 설정 및 마지막으로 Amazon ECS 클러스터 작업 수를 확인하여 모든 것이 제대로 작동하는지 확인할 수 있습니다.
**클러스터에 대한 CloudWatch 지표를 보려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 화면 상단의 탐색 모음에서 리전을 선택합니다.
1. 탐색 창의 **지표**에서 **모든 지표**를 선택합니다.
1. **모든 지표** 페이지의 **찾아보기** 탭에서 `AWS/ECS/ManagedScaling`을 선택합니다.
1. **CapacityProviderName, ClusterName**을 선택합니다.
1. `ConsoleTutorial-cluster` **ClusterName**에 해당하는 확인란을 선택합니다.
1. **그래프로 표시된 지표** 탭에서 **기간**을 **30초**로 변경하고 **통계**를 **최대**로 변경합니다.
그래프에 표시된 값은 용량 공급자에 대한 목표 용량 값을 보여 줍니다. 이것은 우리가 설정한 목표 용량 퍼센트인 `100`에서 시작되어야 합니다. 대상 추적 조정 정책에 대한 경보를 트리거하는 값인 `200`으로 확장됩니다. 그런 다음 경보가 Auto Scaling 그룹을 확장하도록 트리거합니다.
다음 단계에 따라 Auto Scaling 그룹 세부 정보를 보고 확장 작업이 발생했는지 확인합니다.
**Auto Scaling 그룹이 확장되었는지 확인하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 화면 상단의 탐색 모음에서 리전을 선택합니다.
1. 탐색 창의 **Auto Scaling**에서 **Auto Scaling 그룹**을 선택합니다.
1. 이 자습서에서 생성한 `ConsoleTutorial-cluster` Auto Scaling 그룹을 선택합니다. **원하는 용량**에서 값을 확인하고 **인스턴스 관리** 탭에서 인스턴스를 확인하여 그룹이 인스턴스 2개로 스케일 아웃되었는지 확인합니다.
다음 단계를 사용하여 Amazon ECS 클러스터를 확인하여 Amazon EC2 인스턴스가 클러스터에 등록되었고 작업이 `RUNNING` 상태로 전환되었는지 확인합니다.
**Auto Scaling 그룹에서 인스턴스 확인**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터(Clusters)** 페이지에서 `ConsoleTutorial-cluster` 클러스터를 선택합니다.
1. **작업** 탭에서 `RUNNING` 상태의 5개 작업이 표시되는지 확인합니다.
## 5단계: 정리
이 자습서를 완료한 후에는 사용하지 않는 리소스에 요금이 발생하지 않도록 연결된 리소스를 정리합니다. 용량 공급자 및 태스크 정의의 삭제는 지원되지 않지만 이러한 리소스와 관련된 비용은 없습니다.
**자습서 리소스를 정리하려면**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터** 페이지에서 **ConsoleTutorial-cluster**를 선택합니다.
1. **ConsoleTutorial-cluster** 페이지에서 **작업** 탭을 선택한 다음 **중지**, **모두 중지**를 선택합니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터** 페이지에서 **ConsoleTutorial-cluster**를 선택합니다.
1. 페이지 오른쪽 상단에서 **클러스터 삭제**를 선택합니다.
1. 확인 상자에 ****ConsoleTutorial-cluster** 삭제**를 입력하고 **삭제**를 선택합니다.
1. 다음 단계에 따라 Auto Scaling 그룹을 삭제합니다.
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 화면 상단의 탐색 모음에서 리전을 선택합니다.
1. 탐색 창의 **Auto Scaling**에서 **Auto Scaling 그룹**을 선택합니다.
1. `ConsoleTutorial-cluster` Auto Scaling 그룹을 선택한 다음 **작업**을 선택합니다.
1. **작업** 메뉴에서 **삭제**를 선택합니다. 확인 상자에 **delete**를 입력한 다음 **삭제**를 선택합니다.
# Amazon ECS에 대한 Amazon EC2 컨테이너 인스턴스
Amazon ECS 컨테이너 인스턴스는 Amazon ECS 컨테이너 에이전트를 실행하고 클러스터에 등록되는 Amazon EC2 인스턴스입니다. Amazon ECS에서 용량 공급자, 외부 용량 공급자 또는 Auto Scaling 그룹 용량 공급자를 사용하여 태스크를 실행하면 태스크가 활성 컨테이너 인스턴스에 배치됩니다. 컨테이너 인스턴스 관리 및 유지 관리는 사용자의 책임입니다.
Amazon ECS에서 컨테이너식 워크로드를 실행하는 데 필요한 기본 사양을 충족하도록 자체 Amazon EC2 인스턴스 AMI를 만들 수도 있지만 Amazon ECS 최적화 AMI는 AWS 엔지니어들에 의해 Amazon ECS에서 사전 구성 및 테스트됩니다. AWS에서 신속하게 시작하고 컨테이너를 실행할 수 있는 가장 간단한 방법입니다.
콘솔을 사용하여 클러스터를 생성하면 Amazon ECS는 선택한 운영 체제와 연결된 최신 AMI를 사용하여 인스턴스에 대한 시작 템플릿을 생성합니다.
CloudFormation을 사용하여 클러스터를 생성할 때 SSM 파라미터는 Auto Scaling 그룹 인스턴스용 Amazon EC2 시작 템플릿의 일부입니다. 동적 Systems Manager 파라미터를 사용하여 배포할 Amazon ECS 최적화 AMI를 결정하도록 템플릿을 구성할 수 있습니다. 이 파라미터를 사용하면 스택을 배포할 때마다 EC2 인스턴스에 적용해야 하는 업데이트가 있는지 확인할 수 있습니다. Systems Manager 파라미터를 사용하는 방법에 대한 예제는 *AWS CloudFormation 사용 설명서*의 [Create an Amazon ECS cluster with the Amazon ECS-optimized Amazon Linux 2023 AMI](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI)를 참조하세요.
+ [Amazon ECS 최적화 Linux AMI 메타데이터 검색](retrieve-ecs-optimized_AMI.md)
+ [Amazon ECS 최적화 Bottlerocket AMI 메타데이터 검색](ecs-bottlerocket-retrieve-ami.md)
+ [Amazon ECS 최적화 Windows AMI 메타데이터 검색](retrieve-ecs-optimized_windows_AMI.md)
애플리케이션과 호환되는 인스턴스 유형 중에서 선택할 수 있습니다. 인스턴스가 크면 동시에 더 많은 작업을 시작할 수 있습니다. 인스턴스가 작으면 더 세분화된 방식으로 스케일 아웃하여 비용을 절감할 수 있습니다. 클러스터의 모든 애플리케이션에 맞는 단일 Amazon EC2 인스턴스 유형을 선택할 필요는 없습니다. 대신 각 그룹의 인스턴스 유형이 서로 다른 여러 Auto Scaling 그룹을 생성할 수 있습니다. 그런 다음 이러한 그룹 각각에 대해 Amazon EC2 용량 공급자를 생성할 수 있습니다.
사용할 인스턴스 패밀리 유형과 인스턴스 유형을 결정하려면 다음 지침을 따르세요.
+ 애플리케이션의 특정 요구 사항을 충족하지 않는 인스턴스 유형 또는 인스턴스 패밀리를 제거합니다. 예를 들어 애플리케이션에 GPU가 필요한 경우 GPU가 없는 모든 인스턴스 유형을 제외할 수 있습니다.
+ 네트워크 처리량과 스토리지를 포함한 요구 사항을 고려하세요.
+ CPU와 메모리를 고려하세요. 일반적으로 CPU 및 메모리는 실행하려는 작업의 복제본을 하나 이상 수용할 수 있을 만큼 커야 합니다.
## 스팟 인스턴스
스팟 용량은 온디맨드 인스턴스에 비해 상당한 비용 절감 효과를 줄 수 있습니다. 스팟 용량이란 초과 용량으로, 온디맨드 또는 예약 용량보다 상당히 저렴합니다. 스팟 용량은 배치 처리 및 기계 학습 워크로드와 개발 및 스테이징 환경에 적합합니다. 더 일반적으로는, 일시적인 가동 중지가 허용되는 모든 워크로드에 적합합니다.
스팟 용량을 항상 사용할 수 있는 것은 아니므로 다음과 같은 결과가 초래될 수 있습니다.
+ 수요가 매우 많은 기간에는 스팟 용량을 사용할 수 없을 수 있습니다. 이로 인해 Amazon EC2 스팟 인스턴스 시작이 지연될 수 있습니다. 이러한 경우 Amazon ECS 서비스는 작업 시작을 다시 시도하며, Amazon EC2 Auto Scaling 그룹도 필요한 용량을 사용할 수 있을 때까지 인스턴스 시작을 다시 시도합니다. Amazon EC2는 스팟 용량을 온디맨드 용량으로 대체하지 않습니다.
+ 전체 용량 수요가 증가하면 2분 경고만 남기고 스팟 인스턴스와 작업이 종료될 수 있습니다. 경고가 전송된 후 인스턴스가 완전히 종료되기 전에 필요한 경우 작업에서 순서대로 종료를 시작해야 합니다. 이렇게 하면 오류 가능성을 최소화하는 데 도움이 됩니다. 정상 종료에 대한 자세한 내용은 [Graceful shutdowns with ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/)를 참조하세요.
스팟 용량 부족을 최소화하려면 다음 권장 사항을 고려하세요.
+ 여러 리전 및 가용 영역 사용 - 스팟 용량은 리전 및 가용 영역에 따라 다릅니다. 여러 리전 및 가용 영역에서 워크로드를 실행하여 스팟 가용성을 개선할 수 있습니다. 가능하면 작업 및 인스턴스를 실행하는 리전의 모든 가용 영역에 있는 서브넷을 지정합니다.
+ 여러 Amazon EC2 인스턴스 유형 사용 - Amazon EC2 Auto Scaling과 함께 혼합 인스턴스 정책을 사용하면 여러 인스턴스 유형이 Auto Scaling 그룹으로 시작됩니다. 이렇게 하면 필요할 때 스팟 용량 요청을 충족할 수 있습니다. 안정성을 극대화하고 복잡성을 최소화하려면 혼합 인스턴스 정책에서 CPU 및 메모리 양이 거의 같은 인스턴스 유형을 사용합니다. 이러한 인스턴스는 세대가 다른 인스턴스이거나 동일한 기본 인스턴스 유형의 변형일 수 있습니다. 이 경우 필요하지 않을 수 있는 추가 기능이 함께 제공될 수 있다는 점에 유의하세요. 이러한 목록의 예로는 m4.large, m5.large, m5a.large, m5d.large, m5n.large, m5dn.large 및 m5ad.large 등이 있습니다. 자세한 설명은 *Amazon EC2 Auto Scaling 사용 설명서*의 [여러 인스턴스 유형 및 구매 옵션이 포함된 Auto Scaling 그룹](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html)을 참조하세요.
+ 용량 최적화 스팟 할당 전략 사용 - Amazon EC2 스팟을 사용할 때 용량 최적화 및 비용 최적화 할당 전략 중에서 선택할 수 있습니다. 새 인스턴스를 시작할 때 용량 최적화 전략을 선택하면 Amazon EC2 스팟은 선택한 가용 영역에서 가용성이 가장 높은 인스턴스 유형을 선택합니다. 이렇게 하면 인스턴스가 시작되는 즉시 종료될 가능성을 줄일 수 있습니다.
컨테이너 인스턴스에서 스팟 종료 알림을 구성하는 방법에 대한 자세한 내용은 다음을 참조하세요.
+ [스팟 인스턴스 알림을 수신하도록 Amazon ECS Linux 컨테이너 인스턴스 구성](spot-instance-draining-linux-container.md)
+ [스팟 인스턴스 알림을 수신하도록 Amazon ECS Windows 컨테이너 인스턴스 구성](windows-spot-instance-draining-container.md)
# Amazon ECS 최적화 Linux AMI
**중요**
Amazon ECS 최적화 Amazon Linux 2 AMI는 업스트림 Amazon Linux 2 운영 체제의 동일한 EOL 날짜를 반영하여 2026년 6월 30일에 서비스를 완전히 종료합니다(자세한 내용은 [Amazon Linux 2 FAQ](https://aws.amazon.com/amazon-linux-2/faqs/) 참조). 고객은 2028년까지 장기 지원을 포함하는 Amazon Linux 2023을 사용하도록 애플리케이션을 업그레이드하는 것이 좋습니다. Amazon Linux 2에서 Amazon Linux 2023으로 마이그레이션하는 방법에 대한 자세한 내용은 [Amazon Linux 2 Amazon ECS 최적화 AMI에서 Amazon Linux 2023 Amazon ECS 최적화 AMI로 마이그레이션](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html)을 참조하세요.
기본적으로 모든 Amazon ECS 최적화 AMI의 사용 중단 날짜가 AMI 생성 날짜로부터 2년 후로 설정되어 있습니다. Amazon EC2 `DescribeImages` API를 사용하여 AMI의 사용 중단 상태 및 날짜를 확인할 수 있습니다. 자세한 내용은 *Amazon Elastic Compute Cloud API 참조*의 [DescribeImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html)를 참조하세요.
Amazon ECS는 이러한 요구 사항 및 권장 사항으로 미리 구성된 Amazon ECS 최적화 AMI를 제공하여 컨테이너 워크로드를 실행합니다. Amazon EC2 인스턴스에 대해 Amazon ECS 최적화 Amazon Linux 2023 AMI를 사용하는 것이 좋습니다. 최신 Amazon ECS 최적화 AMI에서 컨테이너 인스턴스를 시작하면 최신 보안 업데이트 및 컨테이너 에이전트 버전을 받을 수 있습니다. 인스턴스를 시작하는 방법에 대한 자세한 정보는 [Amazon ECS Linux 컨테이너 인스턴스 시작](launch_container_instance.md)를 참조하세요.
콘솔을 사용하여 클러스터를 생성하면 Amazon ECS는 선택한 운영 체제와 연결된 최신 AMI를 사용하여 인스턴스에 대한 시작 템플릿을 생성합니다.
CloudFormation을 사용하여 클러스터를 생성할 때 SSM 파라미터는 Auto Scaling 그룹 인스턴스용 Amazon EC2 시작 템플릿의 일부입니다. 동적 Systems Manager 파라미터를 사용하여 배포할 Amazon ECS 최적화 AMI를 결정하도록 템플릿을 구성할 수 있습니다. 이 파라미터를 사용하면 스택을 배포할 때마다 EC2 인스턴스에 적용해야 하는 업데이트가 있는지 확인할 수 있습니다. Systems Manager 파라미터를 사용하는 방법에 대한 예제는 *AWS CloudFormation 사용 설명서*의 [Create an Amazon ECS cluster with the Amazon ECS-optimized Amazon Linux 2023 AMI](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI)를 참조하세요.
Amazon ECS에 최적화된 AMI를 사용자 지정해야 하는 경우 GitHub의 [Amazon ECS Optimized AMI Build Recipes](https://github.com/aws/amazon-ecs-ami)를 참조하세요.
Amazon Linux 2023 운영 시스템으로 Amazon EC2 인스턴스에 사용할 수 있는 Amazon ECS 최적화 AMI의 변형은 다음과 같습니다.
| 운영 체제 | AMI | 설명 | 스토리지 구성 |
| --- | --- | --- | --- |
| Amazon Linux 2023 | Amazon ECS 최적화 Amazon Linux 2023 AMI | Amazon Linux 2023은 AWS의 차세대 Amazon Linux입니다. 대부분의 경우 Amazon ECS 워크로드에 대해 Amazon EC2 인스턴스를 시작하는 데 권장됩니다. 자세한 내용은 *Amazon Linux 2023 사용 설명서*의 [What is Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html)을 참조하세요. | 기본적으로 Amazon ECS 최적화 Amazon Linux 2023 AMI에는 총 30GiB 루트 볼륨이 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS 최적화 Amazon Linux 2023 AMI의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
| Amazon Linux 2023(arm64) | Amazon ECS 최적화 Amazon Linux 2023(arm64) AMI | Amazon Linux 2023을 기반으로 하는 이 AMI는 Amazon ECS 워크로드에 대해 Arm 기반 AWS Graviton/Graviton 2/Graviton 3/Graviton 4 프로세서로 구동되는 Amazon EC2 인스턴스를 시작할 때 사용하는 것이 좋습니다. 자세한 내용은 *Amazon EC2 인스턴스 유형 안내서*의 [Amazon EC2 범용 인스턴스를 위한 사양](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html)을 참조하세요. | 기본적으로 Amazon ECS 최적화 Amazon Linux 2023 AMI에는 총 30GiB 루트 볼륨이 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS 최적화 Amazon Linux 2023 AMI의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
| Amazon Linux 2023(Neuron) | Amazon ECS 최적화 Amazon Linux 2023 AMI | Amazon Linux 2023을 기반으로 하는 이 AMI는 Amazon EC2 Inf1, Trn1 또는 Inf2 인스턴스를 위한 것입니다. AWS Inferentia 및 AWS Trainium 드라이버와 Docker용 AWS Neuron 런타임이 사전 구성되어 있어 Amazon ECS에서 기계 학습 추론 워크로드를 쉽게 실행할 수 있습니다. 자세한 내용은 [AWS Neuron 기계 학습 워크로드에 대한 Amazon ECS 작업 정의](ecs-inference.md) 섹션을 참조하세요. Amazon ECS에 최적화된 Amazon Linux 2023(Neuron) AMI는 AWS CLI가 사전 설치되어 제공되지 않습니다. | 기본적으로 Amazon ECS 최적화 Amazon Linux 2023 AMI에는 총 30GiB 루트 볼륨이 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS 최적화 Amazon Linux 2023 AMI의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
| Amazon Linux 2023 GPU | Amazon ECS 최적화 Amazon Linux 2023 GPU AMI | Amazon Linux 2023을 기반으로 하는 이 AMI는 Amazon ECS 워크로드의 Amazon EC2 GPU 기반 인스턴스를 시작할 때 사용하는 것이 좋습니다. NVIDIA 커널 드라이버와 Docker GPU 런타임으로 사전 구성되어 있어 Amazon ECS에서 GPU를 활용하는 워크로드를 실행합니다. 자세한 내용은 [GPU 워크로드에 대한 Amazon ECS 작업 정의](ecs-gpu.md) 섹션을 참조하세요. | 기본적으로 Amazon ECS 최적화 Amazon Linux 2023 AMI에는 총 30GiB 루트 볼륨이 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS 최적화 Amazon Linux 2023 AMI의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
Amazon Linux 2 운영 시스템으로 Amazon EC2 인스턴스에 사용할 수 있는 Amazon ECS 최적화 AMI의 변형은 다음과 같습니다.
| 운영 체제 | AMI | 설명 | 스토리지 구성 |
| --- | --- | --- | --- |
| **Amazon Linux 2** | Amazon ECS 최적화 Amazon Linux 2 커널 5.10 AMI | Amazon Linux 2를 기반으로 하는 이 AMI는 Amazon ECS 워크로드에 Amazon EC2 인스턴스를 시작하고 Linux 커널 4.14 대신 커널 5.10을 사용하려는 경우에 사용하기 위한 것입니다. Amazon ECS 최적화 Amazon Linux 2 커널 5.10 AMI에서 AWS CLI가 사전 설치되지 않은 상태입니다. | 기본적으로 Amazon Linux 2 기반 Amazon ECS 최적화 AMI(Amazon ECS 최적화 Amazon Linux 2 AMI, Amazon ECS 최적화 Amazon Linux 2(arm64) AMI 및 Amazon ECS GPU 최적화 AMI)는 단일 30GiB 루트 볼륨과 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS에 최적화 Amazon Linux 2 AMI 의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
| **Amazon Linux 2** | Amazon ECS 최적화 Amazon Linux 2 AMI | Amazon ECS 워크로드를 위한 것입니다. Amazon ECS 최적화 Amazon Linux 2 AMI에서 AWS CLI가 사전 설치되지 않은 상태입니다. | 기본적으로 Amazon Linux 2 기반 Amazon ECS 최적화 AMI(Amazon ECS 최적화 Amazon Linux 2 AMI, Amazon ECS 최적화 Amazon Linux 2(arm64) AMI 및 Amazon ECS GPU 최적화 AMI)는 단일 30GiB 루트 볼륨과 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS에 최적화 Amazon Linux 2 AMI 의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
| **Amazon Linux 2(arm64)** | Amazon ECS 최적화 Amazon Linux 2 커널 5.10(arm64) AMI | Amazon Linux 2를 기반으로 하는 이 AMI는 Arm 기반 AWS Graviton/Graviton 2/Graviton 3/Graviton 4 프로세서로 구동되는 Amazon EC2 인스턴스를 위한 것이며, Amazon ECS 워크로드에 Linux 커널 4.14 대신 Linux 커널 5.10을 사용하려는 경우 사용할 수 있습니다. 자세한 내용은 *Amazon EC2 인스턴스 유형 안내서*의 [Amazon EC2 범용 인스턴스를 위한 사양](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html)을 참조하세요. Amazon ECS 최적화 Amazon Linux 2(arm64) AMI에서 AWS CLI가 사전 설치되지 않은 상태입니다. | 기본적으로 Amazon Linux 2 기반 Amazon ECS 최적화 AMI(Amazon ECS 최적화 Amazon Linux 2 AMI, Amazon ECS 최적화 Amazon Linux 2(arm64) AMI 및 Amazon ECS GPU 최적화 AMI)는 단일 30GiB 루트 볼륨과 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS에 최적화 Amazon Linux 2 AMI 의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
| Amazon Linux 2(arm64) | Amazon ECS 최적화 Amazon Linux 2(arm64) AMI | Amazon Linux 2를 기반으로 하는 이 AMI는 Amazon ECS 워크로드에 대해 Arm 기반 AWS Graviton/Graviton 2/Graviton 3/Graviton 4 프로세서로 구동되는 Amazon EC2 인스턴스를 시작할 때 사용하기 위한 것입니다. Amazon ECS 최적화 Amazon Linux 2(arm64) AMI에서 AWS CLI가 사전 설치되지 않은 상태입니다. | 기본적으로 Amazon Linux 2 기반 Amazon ECS 최적화 AMI(Amazon ECS 최적화 Amazon Linux 2 AMI, Amazon ECS 최적화 Amazon Linux 2(arm64) AMI 및 Amazon ECS GPU 최적화 AMI)는 단일 30GiB 루트 볼륨과 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS에 최적화 Amazon Linux 2 AMI 의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
| **Amazon Linux 2(GPU)** | Amazon ECS GPU 최적화 커널 5.10 AMI | Amazon Linux 2를 기반으로 하는 이 AMI는 Amazon ECS 워크로드에 대해 Linux 커널 5.10에서 Amazon EC2 GPU 기반 인스턴스를 시작할 때 사용하는 것이 좋습니다. NVIDIA 커널 드라이버와 Docker GPU 런타임으로 사전 구성되어 있어 Amazon ECS에서 GPU를 활용하는 워크로드를 실행합니다. 자세한 내용은 [GPU 워크로드에 대한 Amazon ECS 작업 정의](ecs-gpu.md) 섹션을 참조하세요. | 기본적으로 Amazon Linux 2 기반 Amazon ECS 최적화 AMI(Amazon ECS 최적화 Amazon Linux 2 AMI, Amazon ECS 최적화 Amazon Linux 2(arm64) AMI 및 Amazon ECS GPU 최적화 AMI)는 단일 30GiB 루트 볼륨과 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS에 최적화 Amazon Linux 2 AMI 의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
| Amazon Linux 2(GPU) | Amazon ECS GPU 최적화 AMI | Amazon Linux 2를 기반으로 하는 이 AMI는 Amazon ECS 워크로드에 대해 Linux 커널 4.14에서 Amazon EC2 GPU 기반 인스턴스를 시작할 때 사용하는 것이 좋습니다. NVIDIA 커널 드라이버와 Docker GPU 런타임으로 사전 구성되어 있어 Amazon ECS에서 GPU를 활용하는 워크로드를 실행합니다. 자세한 내용은 [GPU 워크로드에 대한 Amazon ECS 작업 정의](ecs-gpu.md) 섹션을 참조하세요. | 기본적으로 Amazon Linux 2 기반 Amazon ECS 최적화 AMI(Amazon ECS 최적화 Amazon Linux 2 AMI, Amazon ECS 최적화 Amazon Linux 2(arm64) AMI 및 Amazon ECS GPU 최적화 AMI)는 단일 30GiB 루트 볼륨과 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS에 최적화 Amazon Linux 2 AMI 의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
| Amazon Linux 2(Neuron) | Amazon ECS 최적화 Amazon Linux 2(Neuron) 커널 5.10 AMI | Amazon Linux 2를 기반으로 하는 이 AMI는 Amazon EC2 Inf1, Trn1 또는 Inf2 인스턴스를 위한 것입니다. Linux 커널 5.10에서 AWS Inferentia 및 AWS Trainium 드라이버와 Docker용 AWS Neuron 런타임이 사전 구성되어 있어 Amazon ECS에서 기계 학습 추론 워크로드를 쉽게 실행할 수 있습니다. 자세한 내용은 [AWS Neuron 기계 학습 워크로드에 대한 Amazon ECS 작업 정의](ecs-inference.md) 섹션을 참조하세요. Amazon ECS 최적화 Amazon Linux 2(Neuron) AMI는 AWS CLI가 사전 설치되지 않은 상태입니다. | 기본적으로 Amazon Linux 2 기반 Amazon ECS 최적화 AMI(Amazon ECS 최적화 Amazon Linux 2 AMI, Amazon ECS 최적화 Amazon Linux 2(arm64) AMI 및 Amazon ECS GPU 최적화 AMI)는 단일 30GiB 루트 볼륨과 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS에 최적화 Amazon Linux 2 AMI 의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
| Amazon Linux 2(Neuron) | Amazon ECS 최적화 Amazon Linux 2(Neuron) AMI | Amazon Linux 2를 기반으로 하는 이 AMI는 Amazon EC2 Inf1, Trn1 또는 Inf2 인스턴스를 위한 것입니다. AWS Inferentia 및 AWS Trainium 드라이버와 Docker용 AWS Neuron 런타임이 사전 구성되어 있어 Amazon ECS에서 기계 학습 추론 워크로드를 쉽게 실행할 수 있습니다. 자세한 내용은 [AWS Neuron 기계 학습 워크로드에 대한 Amazon ECS 작업 정의](ecs-inference.md) 섹션을 참조하세요. Amazon ECS 최적화 Amazon Linux 2(Neuron) AMI는 AWS CLI가 사전 설치되지 않은 상태입니다. | 기본적으로 Amazon Linux 2 기반 Amazon ECS 최적화 AMI(Amazon ECS 최적화 Amazon Linux 2 AMI, Amazon ECS 최적화 Amazon Linux 2(arm64) AMI 및 Amazon ECS GPU 최적화 AMI)는 단일 30GiB 루트 볼륨과 함께 제공됩니다. 시작 시 30GiB 루트 볼륨 크기를 수정하여 컨테이너 인스턴스에서 가용 스토리지를 늘릴 수 있습니다. 이 스토리지는 운영 체제와 Docker 이미지 및 메타데이터에 사용됩니다.Amazon ECS에 최적화 Amazon Linux 2 AMI 의 기본 파일 시스템은 `xfs`이며 Docker는`overlay2` 스토리지 드라이버를 사용합니다. 자세한 정보는 Docker 설명서의 [OverlayFS 스토리지 드라이버 사용](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/)을 참조하세요. |
Amazon ECS는 GitHub에서 Amazon ECS 최적화 AMI의 Linux 변형에 대한 변경 로그를 제공합니다. 자세한 정보는 [Changelog](https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md)를 참조하세요.
Amazon ECS 최적화 AMI의 Linux 변형은 Amazon Linux 2 AMI 또는 Amazon Linux 2023 AMI를 기반으로 사용합니다. Systems Manager Parameter Store API를 쿼리하여 각 변형에 대한 AMI 이름을 검색할 수 있습니다. 자세한 내용은 [Amazon ECS 최적화 Linux AMI 메타데이터 검색](retrieve-ecs-optimized_AMI.md) 섹션을 참조하세요. Amazon Linux 2 AMI 릴리스 정보도 제공됩니다. 자세한 정보는 [Amazon Linux 2 릴리스 정보](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html)를 참조하세요. Amazon Linux 2023 릴리스 정보도 제공됩니다. 자세한 정보는 [Amazon Linux 2023 release notes](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes.html)를 참조하세요.
다음 페이지에서는 변경 사항에 대한 추가 정보를 제공합니다.
+ GitHub의 [Source AMI release notes](https://github.com/aws/amazon-ecs-ami/releases)
+ Docker 설명서의 [Docker Engine 릴리스 정보](https://docs.docker.com/engine/release-notes/)
+ NVIDIA 설명서의 [NVIDIA 드라이버 설명서](https://docs.nvidia.com/datacenter/tesla/index.html)
+ GitHub의 [Amazon ECS Agent changelog](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md)
`ecs-init` 애플리케이션의 소스 코드 및 에이전트 패키징을 위한 스크립트 및 구성은 이제 에이전트 리포지토리의 일부입니다. `ecs-init`의 이전 버전 및 패키징에 대해서는 GitHub의 [Amazon ecs-init changelog](https://github.com/aws/amazon-ecs-init/blob/master/CHANGELOG.md)를 참조하세요.
## Amazon ECS 최적화 AMI에 보안 업데이트 적용
Amazon Linux를 기반으로 하는 Amazon ECS 최적화 AMI에는 cloud-init의 사용자 지정 버전이 포함되어 있습니다. Cloud-init는 클라우드 컴퓨팅 환경에서 Linux 이미지 부트스트랩을 수행하고 인스턴스를 시작할 때 원하는 작업을 수행하는 데 사용됩니다. 기본적으로 2024년 6월 12일 이전에 출시된 Amazon Linux 기반의 모든 Amazon ECS 최적화 AMI에는 인스턴스 시작 시 모든 '심각' 및 '중요' 보안 업데이트가 적용됩니다.
Amazon Linux 2를 기반으로 하는 Amazon ECS 최적화 AMI의 2024년 6월 12일 릴리스부터 기본 동작에 더 이상 시작 시 패키지 업데이트가 포함되지 않습니다. 대신 릴리스가 출시되면 새로운 Amazon ECS 최적화 AMI로 업데이트하는 것이 좋습니다. Amazon ECS 최적화 AMI는 사용 가능한 보안 업데이트 또는 기본 AMI 변경 내용이 있을 때 릴리스됩니다. 이렇게 하면 최신 패키지 버전과 보안 업데이트를 받고 인스턴스 시작을 통해 패키지 버전을 변경할 수 없게 됩니다. 최신 Amazon ECS 최적화 AMI 검색에 대한 자세한 내용은 [Amazon ECS 최적화 Linux AMI 메타데이터 검색](retrieve-ecs-optimized_AMI.md) 섹션을 참조하세요.
새 AMI가 출시되면 새 AMI로 업데이트하도록 환경을 자동화하는 것이 좋습니다. 사용 가능한 옵션에 대한 자세한 내용은 [Amazon ECS enables easier EC2 capacity management, with managed instance draining](https://aws.amazon.com/blogs/containers/amazon-ecs-enables-easier-ec2-capacity-management-with-managed-instance-draining/)을 참조하세요.
AMI 버전에서 '심각' 및 '중요' 보안 업데이트를 수동으로 계속 적용하려면 Amazon EC2 인스턴스에서 다음 명령을 실행할 수 있습니다.
```
yum update --security
```
**주의**
Docker 또는 Containerd 패키지를 업데이트하면 호스트에서 실행 중인 모든 컨테이너가 중지되므로 실행 중인 모든 Amazon ECS 작업이 중지됩니다. 서비스 중단을 최소화할 수 있도록 사전에 계획을 수립합니다.
시작 시 보안 업데이트를 다시 활성화하려면 Amazon EC2 인스턴스를 시작할 때 cloud-init 사용자 데이터의 `#cloud-config` 섹션에 다음 줄을 추가할 수 있습니다. 자세한 내용은 *Amazon Linux 사용 설명서*의 [Using cloud-init on Amazon Linux 2](https://docs.aws.amazon.com/linux/al2/ug/amazon-linux-cloud-init.html)를 참조하세요.
```
#cloud-config
repo_upgrade: security
```
## Amazon ECS 최적화 AL2023 GPU AMI의 버전 잠금 패키지
일부 패키지는 Amazon ECS 최적화 AL2023 GPU AMI에서 GPU 기능이 올바르고 성능 저하 없이 동작하는 데 필수적입니다. 다음이 포함됩니다.
+ NVIDIA 드라이버(`nvidia*`)
+ 커널 모듈(`kmod*`)
+ NVIDIA 라이브러리(`libnvidia*`)
+ 커널 패키지(`kernel*`)
**참고**
이 목록은 전체 목록이 아닙니다. 잠긴 패키지의 전체 목록은 `dnf versionlock list`로 확인할 수 있습니다.
이러한 패키지는 안정성을 보장하고 GPU 워크로드를 방해할 수 있는 의도치 않은 변경을 방지하기 위해 버전이 잠겨 있습니다. 따라서 일반적으로 이러한 패키지는 잠재적인 문제를 원활하게 처리하고 GPU 기능을 유지할 수 있는 관리형 프로세스 범위 내에서만 수정해야 합니다.
의도하지 않은 수정을 방지하기 위해 `dnf versionlock` 플러그인이 해당 패키지에 적용되어 있습니다.
잠긴 패키지를 수정하려는 경우 다음과 같이 할 수 있습니다.
```
# unlock a single package
sudo dnf versionlock delete $PACKAGE_NAME
# unlock all packages
sudo dnf versionlock clear
```
**중요**
이러한 패키지에 대한 업데이트가 필요한 경우, 고객은 필요한 업데이트가 이미 포함된 최신 AMI 버전을 사용하는 것을 고려해야 합니다. 기존 인스턴스를 업데이트해야 하는 경우에는 패키지 잠금 해제, 업데이트, 재잠금 과정을 포함한 신중한 접근 방식을 적용하여 프로세스 전체에서 GPU 기능이 지속적으로 유지되는지 반드시 확인해야 합니다.
# Amazon ECS 최적화 Linux AMI 메타데이터 검색
Amazon ECS 최적화 AMI 메타데이터를 프로그래밍 방식으로 검색할 수 있습니다. 메타데이터에는 AMI 이름, Amazon ECS 컨테이너 에이전트 버전, Docker 버전이 포함된 Amazon ECS 런타임 버전이 포함됩니다.
콘솔을 사용하여 클러스터를 생성하면 Amazon ECS는 선택한 운영 체제와 연결된 최신 AMI를 사용하여 인스턴스에 대한 시작 템플릿을 생성합니다.
CloudFormation을 사용하여 클러스터를 생성할 때 SSM 파라미터는 Auto Scaling 그룹 인스턴스용 Amazon EC2 시작 템플릿의 일부입니다. 동적 Systems Manager 파라미터를 사용하여 배포할 Amazon ECS 최적화 AMI를 결정하도록 템플릿을 구성할 수 있습니다. 이 파라미터를 사용하면 스택을 배포할 때마다 EC2 인스턴스에 적용해야 하는 업데이트가 있는지 확인할 수 있습니다. Systems Manager 파라미터를 사용하는 방법에 대한 예제는 **AWS CloudFormation 사용 설명서의 [Create an Amazon ECS cluster with the Amazon ECS-optimized Amazon Linux 2023 AMI](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI)를 참조하세요.
Amazon ECS 최적화 AMI의 각 변형에 대한 AMI ID, 이미지 이름, 운영 체제, 컨테이너 에이전트 버전, 소스 이미지 이름 및 런타임 버전은 Systems Manager Parameter Store API를 쿼리하여 프로그래밍 방식으로 검색할 수 있습니다. Systems Manager Parameter Store API에 대한 자세한 정보는 [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html) 및 [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html)를 참조하세요.
**참고**
Amazon ECS 최적화 AMI 메타데이터를 검색하려면 관리 사용자에게 다음과 같은 IAM 권한이 있어야 합니다. 이러한 권한은 `AmazonECS_FullAccess` IAM 정책에 추가되었습니다.
ssm:GetParameters
ssm:GetParameter
ssm:GetParametersByPath
## Systems Manager Parameter Store 파라미터 형식
다음은 각 Amazon ECS 최적화 AMI 변형에 대한 파라미터 이름의 형식입니다.
**Linux Amazon ECS 최적화 AMI**
+ Amazon Linux 2023 AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/
```
+ Amazon Linux 2023(arm64) AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/
```
+ Amazon Linux 2023(Neuron) AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/
```
+ Amazon Linux 2023(GPU) AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/
```
Amazon Linux 2 AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/
```
+ Amazon Linux 2 커널 5.10 AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/
```
+ Amazon Linux 2(arm64) AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/arm64/
```
+ Amazon Linux 2 커널 5.10(arm64) AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/
```
+ Amazon ECS GPU 최적화 커널 5.10 AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/
```
+ Amazon Linux 2(GPU) AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/
```
+ Amazon ECS 최적화 Amazon Linux 2(Neuron) 커널 5.10 AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/
```
+ Amazon Linux 2(Neuron) AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/inf/
```
다음과 같은 파라미터 이름 형식은 하위 파라미터 `image_id`를 사용하여 최신 권장 Amazon ECS 최적화 Amazon Linux 2 AMI의 이미지 ID를 검색합니다.
```
/aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id
```
다음 파라미터 이름 형식은 AMI 이름을 지정함으로써 특정 Amazon ECS 최적화 AMI 버전의 메타데이터를 가져옵니다.
+ Amazon ECS 최적화 Amazon Linux 2 AMI 메타데이터:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20181112-x86_64-ebs
```
**참고**
Amazon ECS 최적화 Amazon Linux 2 AMI의 버전을 모두 검색할 수 있습니다. Amazon ECS 최적화 AMI 버전 `amzn-ami-2017.09.l-amazon-ecs-optimized`(Linux) 이후 버전만 가져올 수 있습니다.
## 예제
다음 예에서는 Amazon ECS 최적화 AMI 변형에 대한 메타데이터를 검색할 수 있는 방법을 보여 줍니다.
### 최신 권장 Amazon ECS 최적화 AMI의 메타데이터 검색
다음과 같은 AWS CLI 명령과 AWS CLI를 함께 사용하여 최신 권장 Amazon ECS 최적화 AMI를 검색할 수 있습니다.
**Linux Amazon ECS 최적화 AMI**
+ **Amazon ECS 최적화 Amazon Linux 2023 AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended --region us-east-1
```
+ **Amazon ECS 최적화 Amazon Linux 2023(arm64) AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/recommended --region us-east-1
```
+ **Amazon ECS 최적화 Amazon Linux 2023(Neuron) AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended --region us-east-1
```
+ **Amazon ECS 최적화 Amazon Linux 2023 GPU AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/recommended --region us-east-1
```
+ **Amazon ECS 최적화 Amazon Linux 2 커널 5.10 AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended --region us-east-1
```
+ **Amazon ECS 최적화 Amazon Linux 2 AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended --region us-east-1
```
+ **Amazon ECS 최적화 Amazon Linux 2 커널 5.10(arm64) AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/recommended --region us-east-1
```
+ **Amazon ECS 최적화 Amazon Linux 2(arm64) AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/arm64/recommended --region us-east-1
```
+ **Amazon ECS GPU 최적화 커널 5.10 AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/recommended --region us-east-1
```
+ **Amazon ECS GPU 최적화 AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
```
+ **Amazon ECS 최적화 Amazon Linux 2(Neuron) 커널 5.10 AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/recommended --region us-east-1
```
+ **Amazon ECS 최적화 Amazon Linux 2(Neuron) AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/inf/recommended --region us-east-1
```
### 권장되는 최신 Amazon ECS 최적화 Amazon Linux 2023 AMI의 이미지 ID 검색
하위 파라미터 `image_id`를 사용하여 권장되는 최신 Amazon ECS 최적화 Amazon Linux 2023 AMI ID의 이미지 ID를 검색할 수 있습니다.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1
```
`image_id` 값만 검색하기 위해, 다음 예와 같이 특정 파라미터 값을 쿼리할 수 있습니다.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```
### 특정 Amazon ECS 최적화 Amazon Linux 2 AMI 버전의 메타데이터 검색
AWS CLI와 AWS CLI 명령을 사용하여 다음 특정 Amazon ECS 최적화 Amazon Linux AMI 버전의 메타데이터를 가져옵니다. AMI 이름을 검색할 Amazon ECS 최적화 Amazon Linux AMI의 이름으로 바꿉니다.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20200928-x86_64-ebs --region us-east-1
```
### Systems Manager GetParametersByPath API를 사용한 Amazon ECS 최적화 Amazon Linux 2 커널 5.10 AMI 메타데이터 검색
다음 명령과 AWS CLI를 사용한 Systems Manager GetParametersByPath API로 Amazon ECS 최적화 Amazon Linux 2 AMI 메타데이터 검색
```
aws ssm get-parameters-by-path --path /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/ --region us-east-1
```
### 권장되는 최신 Amazon ECS 최적화 Amazon Linux 2 커널 5.10 AMI의 이미지 ID 검색
하위 파라미터 `image_id`를 사용하여 권장되는 최신 Amazon ECS 최적화 Amazon Linux 2 커널 5.10 AMI ID의 이미지 ID를 검색할 수 있습니다.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id --region us-east-1
```
`image_id` 값만 검색하기 위해, 다음 예와 같이 특정 파라미터 값을 쿼리할 수 있습니다.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```
### CloudFormation 템플릿에서 최신 권장 Amazon ECS 최적화 AMI 사용
Systems Manager 파라미터 스토어 이름을 참조하여 CloudFormation 템플릿에서 최신 Amazon ECS 최적화 AMI를 참조할 수 있습니다.
**Linux 예**
```
Parameters:kernel-5.10
LatestECSOptimizedAMI:
Description: AMI ID
Type: AWS::SSM::Parameter::Value
Default: /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id
```
# Amazon Linux 2에서 Amazon Linux 2023 Amazon ECS 최적화 AMI로 마이그레이션
[Amazon Linux](https://aws.amazon.com/amazon-linux-2/faqs) 이후 Amazon ECS는 2026년 6월 30일에 Amazon Linux 2 Amazon ECS 최적화 AMI에 대한 표준 지원을 종료합니다. 이 날짜 이후에는 Amazon ECS 에이전트 버전이 고정되고 소스 Amazon Linux 2 AMI가 업데이트된 경우에만 새 Amazon Linux 2 Amazon ECS 최적화 AMI가 게시됩니다. 완전한 서비스 종료(EOL)는 2026년 6월 30일에 적용되며, 그 이후에는 소스 AMI가 업데이트되더라도 Amazon ECS 최적화 Amazon Linux 2 AMI는 더 이상 게시되지 않습니다.
Amazon Linux 2023은 사전 구성된 보안 정책, 허용 모드의 SELinux, 기본적으로 활성화된 IMDSv2 전용 모드, 최적화된 부팅 시간, 향상된 보안 및 성능을 위한 개선된 패키지 관리를 통해 기본적으로 안전한 접근 방식을 제공합니다.
Amazon Linux 2와 Amazon Linux 2023 Amazon ECS 최적화 AMI 사이의 호환성은 매우 높은 수준이며, 대부분의 고객은 두 운영 체제 간 워크로드의 변경은 거의 없거나 최소 수준으로 유지됩니다.
자세한 내용은 *Amazon Linux 2023 사용 설명서*의 [Comparing Amazon Linux 2 and *Amazon Linux 2023*](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) 및 [AL2023 FAQ](https://aws.amazon.com/linux/amazon-linux-2023/faqs)를 참조하세요.
## 호환성 고려 사항
### 패키지 관리 및 OS 업데이트
이전 Amazon Linux 버전과 달리, Amazon ECS 최적화 Amazon Linux 2023 AMI는 특정 Amazon Linux 리포지토리 버전에서만 사용할 수 있습니다. 이를 통해 사용자가 실수로 패키지를 업데이트하여 원치 않거나 호환되지 않는 변경 내용이 발생하는 것을 방지할 수 있습니다. 자세한 내용은 *Amazon Linux 2023 사용 설명서*의 [Managing repositories and OS updates in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html)을 참조하세요.
### Linux 커널 버전
Amazon Linux 2 AMI는 Linux 커널 4.14 및 5.10에 기반하지만, Amazon Linux 2023은 Linux 커널 6.1 및 6.12를 사용합니다. 자세한 내용은 *Amazon Linux 2023 사용 설명서*의 [Comparing Amazon Linux 2 and Amazon Linux 2023 kernels](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2-kernel.html)을 참조하세요.
### 패키지 가용성 변경 내용
다음은 Amazon Linux 2023의 주목할 만한 패키지 변경 내용입니다.
+ Amazon Linux 2의 일부 소스 바이너리 패키지는 Amazon Linux 2023에서 더 이상 사용할 수 없습니다. 자세한 내용은 *Amazon Linux 2023 릴리스 정보*의 [Packages removed from Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/removed.html)을 참조하세요.
+ Amazon Linux가 다양한 버전의 패키지를 지원하는 방법의 변경 내용. Amazon Linux 2에 사용되는 `amazon-linux-extras` 시스템이 Amazon Linux 2023에 존재하지 않습니다. 모든 패키지는 '코어' 리포지토리에서 사용할 수 있습니다.
+ Extra Packages for Enterprise Linux(EPEL)가 Amazon Linux 2023에서 지원되지 않습니다. 자세한 내용은 *Amazon Linux 2023 사용 설명서*의 [EPEL compatibility in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/epel.html)을 참조하세요.
+ 32비트 애플리케이션은 Amazon Linux 2023에서 지원되지 않습니다. 자세한 내용은 *Amazon Linux 2023 사용 설명서*의 [Deprecated features from Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2.html#deprecated-32bit-rpms)를 참조하세요
### 제어 그룹(cgroups) 변경 내용
제어 그룹(cgroup)은 프로세스를 계층적으로 구성하고 프로세스 간에 시스템 리소스를 배포하는 Linux 커널 기능입니다. 제어 그룹은 `systemd`로 컨테이너 런타임을 광범위하게 구현할 수 있습니다.
Amazon ECS 에이전트, Docker 및 컨테이너는 모두 cgroupv1과 cgroupv2 둘 다 지원합니다. Amazon ECS 에이전트와 컨테이너 런타임은 사용자를 대신해 cgroup을 관리하므로 Amazon ECS 고객은이 기본 cgroup 업그레이드를 변경하지 않아도 됩니다.
cgroupv2에 대한 자세한 내용은 *Amazon Linux 2023 사용 설명서*의 [Control groups v2 in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/cgroupv2.html)을 참조하세요.
### 인스턴스 메타데이터 서비스(IMDS) 변경 내용
Amazon Linux 2023에는 기본적으로 인스턴스 메타데이터 서비스 버전 2(IMDSv2)가 필요합니다. IMDSv2는 보안 태세를 개선하는 데 도움이 되는 몇 가지 이점을 제공합니다. 세션을 시작하려면 간단한 HTTP PUT 요청으로 비밀 토큰을 생성해야 하는 세션 지향 인증 방법을 사용합니다. 세션의 토큰은 1초에서 6시간 사이로 유효할 수 있습니다.
IMDSv1에서 IMDSv2로의 전환에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 메타데이터 서비스 버전 2 사용으로 전환](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html)을 참조하세요.
IMDSv1을 사용하려는 경우 인스턴스 메타데이터 옵션 시작 속성을 사용하여 설정을 수동으로 재정의하면 계속 사용할 수 있습니다.
### 메모리 스왑 변경 내용
Amazon Linux 2023 및 cgroups v2에서는 컨테이너별 메모리 스왑이 지원되지 않습니다. 자세한 내용은 [Amazon ECS에서 컨테이너 스왑 메모리 스페이스 관리](container-swap.md) 섹션을 참조하세요.
### FIPS 검증 변경 내용
Amazon Linux 2는 FIPS 140-2 인증을 획득했고 Amazon Linux 2023은 FIPS 140-3 인증을 획득했습니다.
Amazon Linux 2023에서 FIPS 모드를 활성화하려면 Amazon EC2 인스턴스에 필요한 패키지를 설치하고 *Amazon Linux 2023 사용 설명서*의 [Enable FIPS Mode on Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html)에 나온 지침에 따라 구성 단계를 수행합니다.
### 가속화된 인스턴스 지원
Amazon ECS 최적화 Amazon Linux 2023 AMI는 Neuron 및 GPU 가속 인스턴스 유형을 모두 지원합니다. 자세한 내용은 [Amazon ECS 최적화 Linux AMI](ecs-optimized_AMI.md) 섹션을 참조하세요.
## 사용자 지정 AMI 빌드
공식적으로 지원되고 게시된 Amazon Linux 2023용 Amazon ECS 최적화 AMI로 전환하는 것이 좋지만, Amazon ECS 최적화 AMIs의 Linux 변형을 빌드하는 데 사용되는 오픈 소스 빌드 스크립트를 사용하여 사용자 지정 Amazon Linux 2 Amazon ECS 최적화 AMI를 계속 빌드할 수 있습니다. 자세한 내용은 [Amazon ECS 최적화 Linux AMI 구축 스크립트](ecs-ami-build-scripts.md) 섹션을 참조하세요.
## 마이그레이션 전략
철저한 애플리케이션 테스트를 포함하는 마이그레이션 계획을 생성하고 구현하는 것이 좋습니다. 다음 섹션에서는 Amazon ECS 인프라를 관리하는 방법에 따라 다양한 마이그레이션 전략을 간략하게 설명합니다.
### Amazon ECS 용량 공급자로 마이그레이션
1. 새 시작 템플릿으로 새 용량 공급자를 생성하세요. 기존 항목과 와 유사한 시작 템플릿을 포함하는 Auto Scaling 그룹을 참조해야 하지만 Amazon Linux 2 Amazon ECS 최적화 AMI 대신 Amazon Linux 2023 변형 중 하나를 지정해야 합니다. 이 새 용량 공급자를 기존 Amazon ECS 클러스터에 추가하세요.
1. 기존 Amazon Linux 2 용량 공급자와 새로운 Amazon Linux 2023 용량 공급자를 모두 포함하도록 클러스터의 기본 용량 공급자 전략을 업데이트합니다. 먼저 Amazon Linux 2 공급자에서 높은 가중치, Amazon Linux 2023 공급자에서 낮은 가중치로 시작하세요(예: Amazon Linux 2: 가중치 80, Amazon Linux 2023: 가중치 20). 그러면 새 태스크가 예약될 때 Amazon ECS가 Amazon Linux 2023 인스턴스 프로비저닝을 시작합니다. 인스턴스가 올바르게 등록되고 새 인스턴스에서 태스크가 성공적으로 실행될 수 있는지 확인하세요.
1. 클러스터의 기본 전략에서 용량 공급자 가중치를 점진적으로 조정하여 Amazon Linux 2023 공급자의 가중치를 늘리는 동시에 시간 경과에 따라 Amazon Linux 2 공급자 가중치를 줄이세요(예: 60/40, 40/60, 20/80의 순서로 조정). Amazon Linux 2023 인스턴스의 우선순위를 지정하도록 개별 서비스 용량 공급자 전략을 업데이트할 수도 있습니다. 태스크 배치를 모니터링하여 Amazon Linux 2023 인스턴스에서 성공적으로 실행되고 있는지 확인하세요.
1. 선택적으로 Amazon Linux 2 컨테이너 인스턴스를 드레이닝하여 태스크 마이그레이션을 가속하세요. Amazon Linux 2023 대체 용량이 충분한 경우 Amazon ECS 콘솔 또는 AWS CLI를 통해 Amazon Linux 2 컨테이너 인스턴스를 수동으로 드레이닝하여 Amazon Linux 2에서 Amazon Linux 2023으로 태스크 전환을 가속화할 수 있습니다. 마이그레이션이 완료되면 클러스터에서 Amazon Linux 2 용량 공급자를 제거하고 연결된 Auto Scaling 그룹을 삭제하세요.
### Amazon EC2 Auto Scaling 그룹으로 마이그레이션
1. 새 시작 템플릿을 사용하여 새 Amazon EC2 Auto Scaling 그룹을 생성하세요. 기존 시작 템플릿과 유사하지만 Amazon Linux 2 Amazon ECS 최적화 AMI 대신 Amazon Linux 2023 변형 중 하나를 지정해야 합니다. 이 새로운 Auto Scaling 그룹은 기존 클러스터에서 인스턴스를 시작할 수 있습니다.
1. 먼저 Amazon Linux 2023 인스턴스가 클러스터에 등록되도록 Auto Scaling 그룹을 스케일 업하세요. 인스턴스가 올바르게 등록되고 새 인스턴스에서 태스크가 성공적으로 실행될 수 있는지 확인하세요.
1. Amazon Linux 2023에서 태스크가 작동하는지 확인한 후 모든 Amazon Linux 2 인스턴스를 완전히 교체할 때까지 Amazon Linux 2 Auto Scaling 그룹을 점진적으로 스케일 다운하면서 Amazon Linux 2023 Auto Scaling 그룹을 스케일 업하세요.
1. Amazon Linux 2023 대체 용량이 충분한 경우 컨테이너 인스턴스를 명시적으로 드레이닝하여 Amazon Linux 2에서 Amazon Linux 2023으로 태스크 전환을 가속화할 수 있습니다. 자세한 내용은 [Amazon ECS 컨테이너 인스턴스 드레이닝](container-instance-draining.md) 섹션을 참조하세요.
### 수동 관리형 인스턴스로 마이그레이션
1. Amazon Linux 2 대신 Amazon ECS 최적화 Amazon Linux 2023 AMI를 사용하여 새 Amazon EC2 인스턴스를 수동으로 시작하거나 이를 시작하는 스크립트를 조정하세요. 이러한 인스턴스가 기존 Amazon Linux 2 인스턴스와 동일한 보안 그룹, 서브넷, IAM 역할 및 클러스터 구성을 사용하는지 확인하세요. 인스턴스는 시작 시 기존 Amazon ECS 클러스터에 자동으로 등록되어야 합니다.
1. 새 Amazon Linux 2023 인스턴스가 Amazon ECS 클러스터에 성공적으로 등록되고 `ACTIVE` 상태인지 확인하세요. 자연적인 태스크 배치를 기다리거나 일부 태스크를 수동으로 중지 또는 시작하여 일정 조정을 트리거함으로써 이러한 새 인스턴스에서 태스크를 예약하고 제대로 실행할 수 있는지 테스트하세요.
1. 필요한 경우 추가 Amazon Linux 2023 인스턴스를 시작한 다음 Amazon Linux 2 인스턴스를 하나씩 수동으로 드레이닝하고 종료하여 Amazon Linux 2 인스턴스를 점진적으로 교체하세요. 인스턴스를 `DRAINING` 상태로 설정하여 Amazon ECS 콘솔을 통해 인스턴스를 드레이닝할 수 있습니다. 그러면 인스턴스에 새 태스크가 배치되지 않고 기존 태스크가 완료되거나 다른 곳에서 다시 예약됩니다.
# Amazon ECS 최적화 Linux AMI 구축 스크립트
Amazon ECS에서 Amazon ECS 최적화 AMI의 Linux 변형을 구축하는 데 사용되는 구축 스크립트를 오픈 소스로 제공합니다. 이러한 빌드 스크립트를 이제 GitHub에서 사용할 수 있습니다. 자세한 정보는 GitHub의 [amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami)를 참조하세요.
Amazon ECS에 최적화된 AMI를 사용자 지정해야 하는 경우 GitHub에서 [Amazon ECS Optimized AMI 빌드 레시피](https://github.com/aws/amazon-ecs-ami)를 참조하세요.
구축 스크립트 리포지토리에는 Amazon ECS 최적화 AMI의 각 Linux 변형을 생성하기 위한 [HashiCorp 패커](https://developer.hashicorp.com/packer/docs) 템플릿과 구축 스크립트가 포함되어 있습니다. 이러한 스크립트는 Amazon ECS 최적화 AMI 구축의 단일 출처이므로 GitHub 리포지토리를 따라 AMI에 대한 변경을 모니터링할 수 있습니다. 예를 들어 사용자가 Amazon ECS 팀이 공식 AMI에 사용하는 것과 동일한 버전의 Docker를 자체 AMI에 사용하기를 원할 수 있습니다.
자세한 정보는 GitHub의 [aws/amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami)에서 Amazon ECS AMI 리포지토리를 참조하세요.
**Amazon ECS 최적화 Linux AMI 구축**
1. `aws/amazon-ecs-ami` GitHub 리포지토리를 복제합니다.
```
git clone https://github.com/aws/amazon-ecs-ami.git
```
1. AMI를 생성할 때 사용할 AWS 리전에 대한 환경 변수를 추가합니다. `us-west-2` 값을 사용할 리전으로 바꿉니다.
```
export REGION=us-west-2
```
1. AMI 구축을 위해 Makefile이 제공됩니다. 복제된 리포지토리의 루트 디렉터리에서 구축하려는 Amazon ECS 최적화 AMI의 Linux 변형에 해당하는 다음 명령 중 하나를 사용합니다.
+ Amazon ECS 최적화 Amazon Linux 2 AMI
```
make al2
```
+ Amazon ECS 최적화 Amazon Linux 2(arm64) AMI
```
make al2arm
```
+ Amazon ECS GPU 최적화 AMI
```
make al2gpu
```
+ Amazon ECS 최적화 Amazon Linux 2(Neuron) AMI
```
make al2inf
```
+ Amazon ECS 최적화 Amazon Linux 2023 AMI
```
make al2023
```
+ Amazon ECS 최적화 Amazon Linux 2023(arm64) AMI
```
make al2023arm
```
+ Amazon ECS 최적화 Amazon Linux 2023 GPU AMI
```
make al2023gpu
```
+ Amazon ECS 최적화 Amazon Linux 2023(Neuron) AMI
```
make al2023neu
```
# Amazon ECS 최적화 Bottlerocket AMI
Bottlerocket은 Linux 기반 오픈 소스 운영 체제로, AWS에서 가상 머신 또는 베어 메탈 호스트에서 컨테이너를 실행하기 위해 특별히 개발했습니다. Amazon ECS 최적화 Bottlerocket AMI는 안전하며 컨테이너를 실행하는 데 필요한 최소 수의 패키지만 포함합니다. 이를 통해 리소스 사용량을 향상하고, 보안 공격 표면을 줄이고, 관리 오버헤드를 낮출 수 있습니다. 또한 Bottlerocket AMI는 Amazon ECS와 통합되어 클러스터의 컨테이너 인스턴스 업데이트와 관련된 운영 오버헤드를 줄이는 데에도 도움이 됩니다.
Bottlerocket은 다음과 같은 점에서 Amazon Linux와 다릅니다.
+ Bottlerocket은 패키지 관리자를 포함하지 않으며, 소프트웨어를 컨테이너로만 실행할 수 있습니다. Bottlerocket에 대한 업데이트는 한 단계로 적용하고 롤백할 수 있으므로, 업데이트 오류가 발생할 가능성이 줄어듭니다.
+ Bottlerocket 호스트를 관리하는 기본 메커니즘은 컨테이너 스케줄러를 사용하는 것입니다. Amazon Linux와 달리 개별 Bottlerocket 인스턴스에 로그인하는 것은 고급 디버깅 및 문제 해결 목적으로만 드물게 사용됩니다.
Bottlerocket에 대한 자세한 내용은 GitHub의 [설명서](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) 및 [릴리스](https://github.com/bottlerocket-os/bottlerocket/releases)를 참조하세요.
커널 6.1 및 커널 5.10용 Amazon ECS 최적화 Bottlerocket AMI 변형으로 여러 가지가 있습니다.
다음 변형은 커널 6.1을 사용합니다.
+ `aws-ecs-2`
+ `aws-ecs-2-nvidia`
다음 변형은 커널 5.10을 사용합니다.
+ `aws-ecs-1`
+ `aws-ecs-1-nvidia`
`aws-ecs-1-nvidia` 변형에 대한 자세한 정보는 [Announcing NVIDIA GPU support for Bottlerocket on Amazon ECS](https://aws.amazon.com/blogs/containers/announcing-nvidia-gpu-support-for-bottlerocket-on-amazon-ecs/)를 참조하세요.
## 고려 사항
Amazon ECS에서 Bottlerocket AMI를 사용할 때는 다음 사항을 고려해야 합니다.
+ Bottlerocket은 `x86_64` 및 `arm64` 프로세서가 있는 Amazon EC2 인스턴스를 지원합니다. Bottlerocket AMI를 Inferentia 칩이 있는 Amazon EC2 인스턴스와 함께 사용하는 것은 권장되지 않습니다.
+ Bottlerocket 이미지에는 SSH 서버 또는 쉘이 포함되지 않습니다. 하지만 대역 외 관리 도구를 사용하여 SSH 관리자 액세스 권한을 얻고 부트스트래핑을 수행할 수 있습니다.
자세한 내용은 GitHub의 [bottlerocket README.md](https://github.com/bottlerocket-os/bottlerocket)에 있는 관련 부분을 참조하세요.
+ [탐색](https://github.com/bottlerocket-os/bottlerocket#exploration)
+ [관리자 컨테이너](https://github.com/bottlerocket-os/bottlerocket#admin-container)
+ 기본적으로 Bottlerocket에는 사용 설정된 [제어 컨테이너](https://github.com/bottlerocket-os/bottlerocket-control-container)가 있습니다. 이 컨테이너는 Amazon EC2 Bottlerocket 인스턴스에서 명령을 실행하거나 셸 세션을 시작하는 데 사용할 수 있는 [AWS Systems Manager 에이전트](https://github.com/aws/amazon-ssm-agent)를 실행합니다. 자세한 내용은 *AWS Systems Manager 사용 설명서*의 [세션 관리자 설정](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html)을 참조하세요.
+ Bottlerocket은 컨테이너 워크로드에 최적화되어 있으며 보안에 중점을 둡니다. Bottlerocket은 패키지 관리자를 포함하지 않으며 변경 불가능합니다.
보안 기능 및 지침에 대한 자세한 정보는 GitHub 웹사이트의 [Security Features](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_FEATURES.md) 및 [Security Guidance](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_GUIDANCE.md)를 참조하세요.
+ `awsvpc` 네트워크 모드는 Bottlerocket AMI 버전 `1.1.0` 이상에 대해 지원됩니다.
+ 작업 정의의 App Mesh는 Bottlerocket AMI 버전 `1.15.0` 이상에 대해 지원됩니다.
+ `initProcessEnabled` 작업 정의 파라미터는 Bottlerocket AMI 버전 `1.19.0` 이상에서 지원됩니다.
+ Bottlerocket AMI는 다음 서비스 및 기능도 지원하지 않습니다.
+ ECS Anywhere
+ Service Connect
+ 암호화 모드의 Amazon EFS
+ `awsvpc` 네트워크 모드의 Amazon EFS
+ Amazon EBS 볼륨을 탑재할 수 없음
+ Elastic Inference 액셀러레이터
# Amazon ECS 최적화 Bottlerocket AMI 메타데이터 검색
AWS Systems Manager Parameter Store API를 쿼리하여 Amazon ECS 최적화 AMI의 Amazon Machine Image(AMI) ID를 검색할 수 있습니다. 이 파라미터를 사용하면 Amazon ECS 최적화 AMI ID를 수동으로 조회할 필요가 없습니다. Systems Manager 파라미터 스토어 API에 대한 자세한 내용은 [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html) 섹션을 참조하세요. Amazon ECS 최적화 AMI 메타데이터를 검색하려면 사용자에 `ssm:GetParameter` IAM 권한이 있어야 합니다.
## `aws-ecs-2` Bottlerocket AMI 변형
AWS CLI 또는 AWS Management Console을 사용하여 AWS 리전 및 아키텍처별로 안정적인 최신 `aws-ecs-2` Bottlerocket AMI 변형을 검색할 수 있습니다.
+ **AWS CLI** - 다음 AWS CLI 명령에서 하위 파라미터 `image_id`를 사용하여 권장되는 최신 Amazon ECS 최적화 Bottlerocket AMI의 이미지 ID를 검색할 수 있습니다. `region`은 필요한 AMI ID의 리전 코드로 바꿉니다.
지원되는 AWS 리전에 대한 자세한 내용은 GitHub에서 [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)를 참조하세요. 최신 버전이 아닌 다른 버전을 검색하려면 `latest` 항목을 버전 번호로 바꿉니다.
+ 64비트(`x86_64`) 아키텍처:
```
aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ 64비트 Arm(`arm64`) 아키텍처의 경우:
```
aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS Management Console** - AWS Management Console에서 URL을 사용하여 권장되는 Amazon ECS 최적화 AMI ID를 쿼리할 수 있습니다. URL을 사용하면 파라미터의 ID 값이 포함된 Amazon EC2 Systems Manager 콘솔이 열립니다. 다음 URL에서 `region`은 필요한 AMI ID의 리전 코드로 바꿉니다.
지원되는 AWS 리전에 대한 자세한 내용은 GitHub에서 [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)를 참조하세요.
+ 64비트(`x86_64`) 아키텍처:
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id/description?region=region#
```
+ 64비트 Arm(`arm64`) 아키텍처의 경우:
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id/description?region=region#
```
## `aws-ecs-2-nvidia` Bottlerocket AMI 변형
AWS CLI 또는 AWS Management Console을 사용하여 리전 및 아키텍처별로 안정적인 최신 `aws-ecs-2-nvdia` Bottlerocket AMI 변형을 검색할 수 있습니다.
+ **AWS CLI** - 다음 AWS CLI 명령에서 하위 파라미터 `image_id`를 사용하여 권장되는 최신 Amazon ECS 최적화 Bottlerocket AMI의 이미지 ID를 검색할 수 있습니다. `region`은 필요한 AMI ID의 리전 코드로 바꿉니다.
지원되는 AWS 리전에 대한 자세한 내용은 GitHub에서 [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)를 참조하세요. 최신 버전이 아닌 다른 버전을 검색하려면 `latest` 항목을 버전 번호로 바꿉니다.
+ 64비트(`x86_64`) 아키텍처:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ 64비트 Arm(`arm64`) 아키텍처의 경우:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS Management Console** - AWS Management Console에서 URL을 사용하여 권장되는 Amazon ECS 최적화 AMI ID를 쿼리할 수 있습니다. URL을 사용하면 파라미터의 ID 값이 포함된 Amazon EC2 Systems Manager 콘솔이 열립니다. 다음 URL에서 `region`은 필요한 AMI ID의 리전 코드로 바꿉니다.
지원되는 AWS 리전에 대한 자세한 내용은 GitHub에서 [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)를 참조하세요.
+ 64비트(`x86_64`) 아키텍처의 경우:
```
https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id/description?region=region#
```
+ 64비트 Arm(`arm64`) 아키텍처의 경우:
```
https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id/description?region=region#
```
## `aws-ecs-1` Bottlerocket AMI 변형
AWS CLI 또는 AWS Management Console을 사용하여 AWS 리전 및 아키텍처별로 안정적인 최신 `aws-ecs-1` Bottlerocket AMI 변형을 검색할 수 있습니다.
+ **AWS CLI** - 다음 AWS CLI 명령에서 하위 파라미터 `image_id`를 사용하여 권장되는 최신 Amazon ECS 최적화 Bottlerocket AMI의 이미지 ID를 검색할 수 있습니다. `region`은 필요한 AMI ID의 리전 코드로 바꿉니다.
지원되는 AWS 리전에 대한 자세한 내용은 GitHub에서 [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)를 참조하세요. 최신 버전이 아닌 다른 버전을 검색하려면 `latest` 항목을 버전 번호로 바꿉니다.
+ 64비트(`x86_64`) 아키텍처:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ 64비트 Arm(`arm64`) 아키텍처의 경우:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS Management Console** - AWS Management Console에서 URL을 사용하여 권장되는 Amazon ECS 최적화 AMI ID를 쿼리할 수 있습니다. URL을 사용하면 파라미터의 ID 값이 포함된 Amazon EC2 Systems Manager 콘솔이 열립니다. 다음 URL에서 `region`은 필요한 AMI ID의 리전 코드로 바꿉니다.
지원되는 AWS 리전에 대한 자세한 내용은 GitHub에서 [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)를 참조하세요.
+ 64비트(`x86_64`) 아키텍처:
```
https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id/description
```
+ 64비트 Arm(`arm64`) 아키텍처의 경우:
```
https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id/description
```
## `aws-ecs-1-nvidia` Bottlerocket AMI 변형
AWS CLI 또는 AWS Management Console을 사용하여 리전 및 아키텍처별로 안정적인 최신 `aws-ecs-1-nvdia` Bottlerocket AMI 변형을 검색할 수 있습니다.
+ **AWS CLI** - 다음 AWS CLI 명령에서 하위 파라미터 `image_id`를 사용하여 권장되는 최신 Amazon ECS 최적화 Bottlerocket AMI의 이미지 ID를 검색할 수 있습니다. `region`은 필요한 AMI ID의 리전 코드로 바꿉니다.
지원되는 AWS 리전에 대한 자세한 내용은 GitHub에서 [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)를 참조하세요.
+ 64비트(`x86_64`) 아키텍처:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ 64비트 Arm(`arm64`) 아키텍처의 경우:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS Management Console** - AWS Management Console에서 URL을 사용하여 권장되는 Amazon ECS 최적화 AMI ID를 쿼리할 수 있습니다. URL을 사용하면 파라미터의 ID 값이 포함된 Amazon EC2 Systems Manager 콘솔이 열립니다. 다음 URL에서 `region`은 필요한 AMI ID의 리전 코드로 바꿉니다.
지원되는 AWS 리전에 대한 자세한 내용은 GitHub에서 [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami)를 참조하세요.
+ 64비트(`x86_64`) 아키텍처의 경우:
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id/description?region=region#
```
+ 64비트 Arm(`arm64`) 아키텍처의 경우:
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id/description?region=region#
```
## 다음 단계
Amazon ECS에서 Bottlerocket 운영 체제를 시작하는 방법에 대한 자세한 자습서는 GitHub의 [Using a Bottlerocket AMI with Amazon ECS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) 및 AWS 블로그 사이트의 [Getting started withBottlerocket and Amazon ECS](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/)를 참조하세요.
Bottlerocket 인스턴스를 시작하는 방법에 대한 자세한 내용은 [Amazon ECS에 대한 Bottlerocket 인스턴스 시작](bottlerocket-launch.md) 섹션을 참조하세요.
# Amazon ECS에 대한 Bottlerocket 인스턴스 시작
컨테이너 워크로드를 실행할 수 있도록 Bottlerocket 인스턴스를 시작할 수 있습니다.
AWS CLI를 사용하여 Bottlerocket 인스턴스를 시작할 수 있습니다.
1. `userdata.toml`이라는 파일을 생성합니다. 이 파일은 인스턴스 사용자 데이터로 사용됩니다. *cluster-name*을 해당 클러스터의 이름으로 바꿉니다.
```
[settings.ecs]
cluster = "cluster-name"
```
1. [Amazon ECS 최적화 Bottlerocket AMI 메타데이터 검색](ecs-bottlerocket-retrieve-ami.md)에 포함된 명령 중 하나를 사용하여 Bottlerocket AMI ID를 가져옵니다. 다음 단계에서 이 정보를 사용합니다.
1. 다음 명령을 실행하여 Bottlerocket 인스턴스를 시작합니다. 다음 파라미터를 대체해야 합니다.
+ *subnet*을 인스턴스가 시작될 프라이빗 또는 퍼블릭 서브넷의 ID로 바꿉니다.
+ *bottlerocket\$1ami*를 이전 단계의 AMI ID로 바꿉니다.
+ *t3.large*를 사용하려는 인스턴스 유형으로 바꿉니다.
+ *region*을 리전 코드로 바꿉니다.
```
aws ec2 run-instances --key-name ecs-bottlerocket-example \
--subnet-id subnet \
--image-id bottlerocket_ami \
--instance-type t3.large \
--region region \
--tag-specifications 'ResourceType=instance,Tags=[{Key=bottlerocket,Value=example}]' \
--user-data file://userdata.toml \
--iam-instance-profile Name=ecsInstanceRole
```
1. 다음 명령을 실행하여 컨테이너 인스턴스가 클러스터에 등록되었는지 확인합니다. 이 명령을 실행할 때 다음 파라미터를 바꿔야 합니다.
+ *cluster*를 클러스터 이름으로 바꿉니다.
+ *region*을 리전 코드로 바꿉니다.
```
aws ecs list-container-instances --cluster cluster-name --region region
```
Amazon ECS에서 Bottlerocket 운영 체제를 시작하는 방법에 대한 자세한 연습은 GitHub의 [Using a Bottlerocket AMI with Amazon ECS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) 및 AWS 블로그 사이트의 [Getting started with Bottlerocket and Amazon ECS](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/)를 참조하세요.
# Amazon ECS Linux 컨테이너 인스턴스 관리
Amazon ECS 워크로드에 EC2 인스턴스를 사용하는 경우 인스턴스를 유지 관리할 책임은 사용자에게 있습니다.
**Topics**
+ [컨테이너 인스턴스 시작](launch_container_instance.md)
+ [Linux 컨테이너 인스턴스 부트스트래핑](bootstrap_container_instance.md)
+ [스팟 인스턴스 알림을 수신하도록 컨테이너 인스턴스 구성](spot-instance-draining-linux-container.md)
+ [컨테이너 인스턴스를 시작할 때 스크립트 실행](start_task_at_launch.md)
+ [
# Amazon ECS Linux 컨테이너 인스턴스 네트워크 인터페이스 증가
](container-instance-eni.md)
+ [컨테이너 인스턴스 메모리 예약](memory-management.md)
+ [원격으로 컨테이너 인스턴스 관리](ec2-run-command.md)
+ [Linux 컨테이너 인스턴스에 HTTP 프록시 사용](http_proxy_config.md)
+ [Auto Scaling 그룹에 대해 사전 초기화된 인스턴스 구성](using-warm-pool.md)
+ [
# Amazon ECS 컨테이너 에이전트 업데이트
](ecs-agent-update.md)
각 Amazon ECS 컨테이너 에이전트 버전은 서로 다른 기능 세트를 지원하며 이전 버전에 대한 버그 수정을 제공합니다. 기능한 한 최신 버전의 Amazon ECS 컨테이너 에이전트를 사용할 것이 좋습니다. 컨테이너 에이전트를 최신 버전으로 업데이트하려면 [Amazon ECS 컨테이너 에이전트 업데이트](ecs-agent-update.md) 섹션을 참조하세요.
각 에이전트 릴리스에 포함된 기능 및 기능 향상을 보려면 [https://github.com/aws/amazon-ecs-agent/releases](https://github.com/aws/amazon-ecs-agent/releases)를 참조하세요.
**중요**
신뢰할 수 있는 지표를 위한 최소 Docker 버전은 Docker 버전 `v20.10.13` 이상이며, Amazon ECS 최적화 AMI `20220607` 이상 버전에 포함되어 있습니다.
Amazon ECS 에이전트 버전 `1.20.0` 이상에서는 `18.01.0` 이전 Docker 버전에 대한 지원이 중단되었습니다.
# Amazon ECS Linux 컨테이너 인스턴스 시작
Amazon EC2 콘솔을 사용하여 Amazon ECS 컨테이너 인스턴스를 생성할 수 있습니다.
Amazon EC2 콘솔, AWS CLI 및 SDK을 비롯한 다양한 방법으로 인스턴스를 시작할 수 있습니다. 인스턴스를 시작하는 다른 방법에 대한 자세한 정보는 *Amazon EC2 사용 설명서*의 [인스턴스 시작](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html)을 참조하세요.
시작 마법사에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [새 인스턴스 시작 마법사를 사용하여 인스턴스 시작](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html)을 참조하세요.
시작하기 전에 [Amazon ECS 사용 설정](get-set-up-for-amazon-ecs.md)의 단계를 완료해야 합니다.
새 Amazon EC2 마법사를 사용하여 인스턴스를 시작할 수 있습니다. 인스턴스 시작 마법사는 인스턴스를 시작하는 데 필요한 시작 파라미터를 지정합니다.
**Topics**
+ [
## 절차
](#linux-liw-initiate-instance-launch)
+ [
## 이름 및 태그
](#linux-liw-name-and-tags)
+ [
## 애플리케이션 및 OS 이미지(Amazon Machine Image)
](#linux-liw-ami)
+ [
## 인스턴스 유형
](#linux-liw-instance-type)
+ [
## 키 페어(로그인)
](#linux-liw-key-pair)
+ [
## 네트워크 설정
](#linux-liw-network-settings)
+ [
## 스토리지 구성
](#linux-liw-storage)
+ [
## 고급 세부 정보
](#linux-liw-advanced-details)
## 절차
시작하기 전에 [Amazon ECS 사용 설정](get-set-up-for-amazon-ecs.md)의 단계를 완료해야 합니다.
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 화면 상단의 탐색 모음에는 현재 AWS 리전이 표시됩니다(예: 미국 동부(오하이오)). 인스턴스를 시작할 리전을 선택합니다.
1. Amazon EC2 콘솔 대시보드에서 **인스턴스 시작**을 선택합니다.
## 이름 및 태그
인스턴스 이름은 태그이며, 여기서 키는 **이름**이고 값은 사용자가 지정하는 이름입니다. 인스턴스, 볼륨 및 Elastic Graphics에 태그를 지정할 수 있습니다. 스팟 인스턴스의 경우 스팟 인스턴스 요청만 태깅할 수 있습니다.
인스턴스 이름과 추가 태그를 지정하는 것은 선택 사항입니다.
+ **이름(Name)**에 인스턴스를 설명하는 이름을 입력합니다. 이름을 지정하지 않으면 인스턴스를 시작할 때 자동으로 생성되는 ID로 인스턴스를 식별할 수 있습니다.
+ 태그를 추가하려면 **추가 태그 추가(Add additional tags)**를 선택합니다. **태그 추가(Add tag)**를 선택한 다음 키와 값을 입력하고 태그를 지정할 리소스 유형을 선택합니다. 추가할 각 추가 태그에 대해 **태그 추가(Add tag)**를 다시 선택합니다.
## 애플리케이션 및 OS 이미지(Amazon Machine Image)
Amazon Machine Image(AMI)에는 인스턴스를 생성하는 데 필요한 정보가 포함되어 있습니다. 예를 들어 AMI에는 웹 서버 역할을 수행하는 데 필요한 소프트웨어가 포함될 수 있습니다(예: Apache, 사용자의 웹 사이트).
**검색창**을 사용하여 AWS에서 공개한 적절한 Amazon ECS 최적화 AMI를 찾습니다.
1. 다음 용어 중 하나를 **검색창**에 입력합니다.
+ **ami-ecs**
+ Amazon ECS 최적화 AMI의 **값.**
최신 Amazon ECS 최적화 AMI 및 이들의 값은 [Linux Amazon ECS 최적화 AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux)를 참조하세요.
1. **Enter**를 누릅니다.
1. **Amazon Machine Image(AMI) 선택** 페이지에서 **AWSMarketplace AMIs** 탭을 선택합니다.
1. 왼쪽의 **결과 구체화(Refine results)** 창에서 **Amazon Web Services**를 **게시자(Publisher)**로 선택합니다.
1. 사용하려는 AMI 행에서 **선택(Select)**을 선택합니다.
또는, AMI를 선택하지 않고 시작 인스턴스 마법사로 돌아가려면 **취소(Cancel)**(오른쪽 상단)를 선택합니다. 기본 AMI가 선택됩니다. AMI가 [Amazon ECS 최적화 Linux AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html)에 설명된 요구 사항을 충족하는지 확인하세요.
## 인스턴스 유형
인스턴스 유형은 인스턴스의 하드웨어 구성과 크기를 정의합니다. 대형 인스턴스는 CPU와 메모리가 더 높습니다. 자세한 내용을 알아보려면 *Amazon EC2 사용 설명서*의 [인스턴스 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)을 참조하세요. IPv6 전용 워크로드를 실행하려는 경우 특정 인스턴스 유형은 IPv6 주소를 지원하지 않습니다. 자세한 내용은 *Amazon EC2 사용 설명서의*의 [IPv6 주소](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing)를 참조하세요.
+ **인스턴스 유형(Instance type)**에서 인스턴스에 대한 인스턴스 유형을 선택합니다.
여기서 선택하는 인스턴스 유형은 실행할 작업에 사용 가능한 리소스를 결정합니다.
## 키 페어(로그인)
**키 페어 이름(Key pair name)**에서 기존 키 페어를 선택하거나 **새로운 키 페어 생성(Create new key pair)**을 선택하여 새로 생성합니다.
**중요**
**키 페어 없이 진행(Proceed without key pair)**(권장하지 않음) 옵션을 선택할 경우 사용자가 다른 방법으로 로그인할 수 있도록 구성된 AMI를 선택해야만 인스턴스에 연결할 수 있습니다.
## 네트워크 설정
양식의 **네트워크 설정** 섹션에 대한 **편집** 버튼을 선택한 후 필요에 따라 네트워크 설정을 구성합니다.
+ **VPC**에서 인스턴스를 시작하려는 VPC를 선택합니다. IPv6 전용 워크로드를 실행하려면 IPv4 및 IPv6 CIDR 블록을 모두 포함하는 듀얼 스택 VPC를 선택합니다.
+ **서브넷**에서 인스턴스를 시작할 서브넷을 선택합니다. 가용 영역, 로컬 영역, Wavelength Zone 또는 Outposts와 연결된 서브넷에서 인스턴스를 시작할 수 있습니다.
가용 영역에서 인스턴스를 시작하려면 인스턴스를 시작할 서브넷을 선택합니다. 새 서브넷을 생성하려면 **새 서브넷 생성**을 선택하여 Amazon VPC 콘솔로 이동합니다. 마친 후에 인스턴스 시작 마법사로 돌아와 새로 고침 아이콘을 선택하면 해당 서브넷이 목록에 로딩됩니다.
로컬 영역에서 인스턴스를 시작하려면 로컬 영역에 생성된 서브넷을 선택합니다.
Outposts에서 인스턴스를 시작하려면 Outposts와 연결된 VPC의 서브넷을 선택합니다.
IPv6 전용 워크로드를 실행하려면 IPv6 CIDR 블록만 포함하는 서브넷을 선택합니다.
+ **퍼블릭 IP 자동 할당(Auto-assign Public IP)**: 인터넷에서 인스턴스에 액세스할 수 있어야 한다면 **퍼블릭 IP 자동 할당(Auto-assign Public IP)** 필드가 **사용 설정(Enable)**으로 설정되어 있는지 확인합니다. 이렇게 설정이 되어 있지 않으면 이 필드를 **비활성화(Disable)**로 설정합니다.
**참고**
컨테이너 인스턴스는 Amazon ECS 서비스 엔드포인트와 통신하기 위한 액세스 권한이 필요합니다. 액세스 권한은 인터페이스 VPC 엔드포인트를 통하거나 퍼블릭 IP 주소가 있는 컨테이너 인스턴스를 통해 부여할 수 있습니다.
인터페이스 VPC 엔드포인트에 대한 자세한 정보는 [Amazon ECS 및 인터페이스 VPC 엔드포인트(AWS PrivateLink)](vpc-endpoints.md) 섹션을 참조하세요.
인터페이스 VPC 엔드포인트가 구성되어 있지 않고 컨테이너 인스턴스 컴퓨팅 리소스에 퍼블릭 IP 주소가 없는 경우, NAT(Network Address Translation)를 사용하여 이 액세스 권한을 제공해야 합니다. 자세한 정보는 [Amazon VPC 사용 설명서](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)의 *NAT 게이트웨이* 및 이 가이드의 [Amazon ECS Linux 컨테이너 인스턴스에 HTTP 프록시 사용](http_proxy_config.md) 섹션을 참조하세요.
+ 듀얼 스택 VPC 및 IPv6 전용 서브넷을 선택하는 경우 **IPv6 IP 자동 할당**에서 **활성화**를 선택합니다.
+ **방화벽(보안 그룹)(Firewall (security groups))**: 보안 그룹을 사용하여 컨테이너 인스턴스의 방화벽 규칙을 정의합니다. 이 규칙은 컨테이너 인스턴스에 전달되는 수신 네트워크 트래픽을 지정합니다. 다른 모든 트래픽은 무시됩니다.
+ 기존 보안 그룹을 선택하려면 **기존 보안 그룹 선택(Select an existing security group)**을 선택하고 [Amazon ECS 사용 설정](get-set-up-for-amazon-ecs.md)에서 생성한 보안 그룹을 선택합니다.
+ IPv6 전용 워크로드에 대해 인스턴스를 시작하는 경우 **고급 네트워크 구성**을 선택한 다음 **기본 IPv6 IP 할당**에서 **예**를 선택합니다.
**참고**
기본 IPv6 주소가 없으면 호스트 또는 브리지 네트워크 모드의 컨테이너 인스턴스에서 실행되는 태스크가 로드 밸런서 또는 AWS Cloud Map에 등록되지 않습니다.
## 스토리지 구성
선택한 AMI에는 루트 볼륨을 포함한 하나 이상의 스토리지 볼륨이 있습니다. 인스턴스에 연결할 추가 볼륨을 지정할 수 있습니다.
**간단(Simple)** 보기를 사용할 수 있습니다.
+ **스토리지 유형(Storage type)**: 컨테이너 인스턴스의 스토리지를 구성합니다.
Amazon ECS 최적화 Amazon Linux 2 AMI를 사용하는 경우, 운영 체제와 Docker 간에 공유하는 단일 30GiB 볼륨이 인스턴스에 구성됩니다.
Amazon ECS 최적화 AMI를 사용하는 경우, 인스턴스에는 2개의 볼륨이 구성되어 있습니다. **Root** 볼륨은 운영 체제가 사용하고, 두 번째 Amazon EBS 볼륨(`/dev/xvdcz`에 연결)은 Docker가 사용합니다.
애플리케이션 요구에 맞춰 인스턴스의 볼륨 크기를 선택적으로 늘리거나 줄일 수 있습니다.
## 고급 세부 정보
**고급 세부 정보**에서 필드를 볼 수 있도록 섹션을 확장하고 인스턴스를 위한 추가 파라미터를 지정합니다.
+ **구매 옵션(Purchasing option)**: 스팟 인스턴스를 요청하려면 **스팟 인스턴스 요청(Request Spot Instances)**을 선택합니다. 스팟 인스턴스와 관련된 다른 필드도 설정해야 합니다. 자세한 정보는 [스팟 인스턴스 요청](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html)을 참조하세요.
**참고**
스팟 인스턴스를 사용하는 경우 `Not available` 메시지가 표시되면 다른 인스턴스 유형을 선택해야 할 수 있습니다.
+ **IAM 인스턴스 프로파일(IAM instance profile)**: 컨테이너 인스턴스 IAM 역할을 선택합니다. 이는 일반적으로 `ecsInstanceRole`로 이름이 지정됩니다.
**중요**
적절한 IAM 권한을 사용하여 컨테이너 인스턴스를 시작하지 않으면 Amazon ECS 에이전트가 클러스터에 연결할 수 없습니다. 자세한 내용은 [Amazon ECS 컨테이너 인스턴스 IAM 역할](instance_IAM_role.md) 섹션을 참조하세요.
+ **사용자 데이터**: 사용자 데이터(예: [Amazon ECS 컨테이너 에이전트 구성](ecs-agent-config.md)의 에이전트 환경 변수)로 Amazon ECS 컨테이너 인스턴스를 구성합니다. Amazon EC2 사용자 데이터 스크립트는 인스턴스가 처음 시작될 때 한 번만 실행됩니다. 다음은 사용자 데이터의 일반적인 용례입니다.
+ 기본적으로 컨테이너 인스턴스는 기본 클러스터로 시작됩니다. 기본이 아닌 클러스터로 시작하려면 **고급 세부 정보(Advanced Details)** 목록을 선택합니다. 그런 다음 **사용자 데이터(User data)** 필드에 다음 스크립트를 붙여 넣고 *your\$1cluster\$1name*을 클러스터 이름으로 대체합니다.
```
#!/bin/bash
echo ECS_CLUSTER=your_cluster_name >> /etc/ecs/ecs.config
```
+ Amazon S3에 `ecs.config` 파일이 있고 컨테이너 인스턴스 역할에 대한 Amazon S3 읽기 전용 액세스가 활성화된 경우, **고급 세부 정보(Advanced Details)** 목록을 선택합니다. 그런 다음 **사용자 데이터(User data)** 필드에 다음 스크립트를 붙여 넣고 *your\$1bucket\$1name*을 AWS CLI를 설치할 버킷 이름으로 대체하고 시작 시 구성 파일을 작성합니다.
**참고**
이 구성에 대한 자세한 정보는 [Amazon S3에 Amazon ECS 컨테이너 인스턴스 구성 저장](ecs-config-s3.md) 섹션을 참조하세요.
```
#!/bin/bash
yum install -y aws-cli
aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
```
+ `ECS_CONTAINER_INSTANCE_TAGS` 구성 파라미터를 사용하여 컨테이너 인스턴스의 태그를 지정합니다. 이렇게 하면 오로지 Amazon ECS과 연결된 태그가 생성되며, 이러한 태그는 Amazon EC2 API를 사용하여 볼 수 없습니다.
**중요**
Amazon EC2 Auto Scaling 그룹을 사용하여 컨테이너 인스턴스를 시작한 경우 ECS\$1CONTAINER\$1INSTANCE\$1TAGS 에이전트 구성 파라미터를 사용하여 태그를 추가해야 합니다. 이는 Auto Scaling을 사용하여 시작된 Amazon EC2 인스턴스에 태그가 추가되는 방식 때문입니다.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=your_cluster_name
ECS_CONTAINER_INSTANCE_TAGS={"tag_key": "tag_value"}
EOF
```
+ 컨테이너 인스턴스의 태그를 지정한 다음, `ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM` 구성 파라미터를 사용하여 Amazon EC2에서 Amazon ECS로 태그를 전파합니다.
컨테이너 인스턴스와 연결된 태그를 전파하고 `your_cluster_name`이라고 하는 클러스터에 컨테이너 인스턴스를 등록하는 사용자 데이터 스크립트의 예는 다음과 같습니다.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=your_cluster_name
ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM=ec2_instance
EOF
```
+ 기본적으로 Amazon ECS 컨테이너 에이전트는 인스턴스의 기본 IPv4 및 IPv6 경로를 보고 IPv6 전용 구성에 대한 컨테이너 인스턴스의 호환성을 감지하려고 시도합니다. 이 동작을 재정의하려면 인스턴스 `/etc/ecs/ecs.config` 파일에서 ` ECS_INSTANCE_IP_COMPATIBILITY` 파라미터를 `ipv4` 또는 `ipv6`으로 설정할 수 있습니다.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=your_cluster_name
ECS_INSTANCE_IP_COMPATIBILITY=ipv6
EOF
```
자세한 내용은 [데이터 전달을 위한 Amazon ECS Linux 컨테이너 인스턴스 부트스트래핑](bootstrap_container_instance.md) 섹션을 참조하세요.
# 데이터 전달을 위한 Amazon ECS Linux 컨테이너 인스턴스 부트스트래핑
Amazon EC2 인스턴스를 시작하면 사용자 데이터를 EC2 인스턴스에 전달할 수 있습니다. 이 데이터는 일반적인 구성 태스크를 자동으로 수행하는 데 사용할 수 있고, 인스턴스가 부팅될 때 스크립트를 실행하는 데 사용할 수도 있습니다. Amazon ECS의 경우 사용자 데이터의 가장 일반적인 사용 사례는 구성 정보를 Docker 대몬 및 Amazon ECS 컨테이너 에이전트에 전달하는 것입니다.
클라우드 boothook, 셸 스크립트, `cloud-init` 명령을 비롯하여 여러 유형의 사용자 데이터를 Amazon EC2에 전달할 수 있습니다. 이러한 유형 및 다른 형식 유형에 대한 자세한 정보는 [Cloud-Init 설명서](https://cloudinit.readthedocs.io/en/latest/explanation/format.html)를 참조하세요.
Amazon EC2 시작 마법사를 사용할 때 사용자 데이터를 전달하려면 [Amazon ECS Linux 컨테이너 인스턴스 시작](launch_container_instance.md) 섹션을 참조하세요.
컨테이너 에이전트 구성 또는 Docker 대몬 구성의 데이터를 전달하도록 컨테이너 인스턴스를 구성할 수 있습니다.
## Amazon ECS 컨테이너 에이전트
Linux 변형의 Amazon ECS 최적화 AMI는 컨테이너 에이전트가 시작될 때 `/etc/ecs/ecs.config` 파일에서 에이전트 구성 데이터를 찾습니다. 시작 시 Amazon EC2 사용자 데이터를 사용하여 이 구성 데이터를 지정할 수 있습니다. 사용 가능한 Amazon ECS 컨테이너 에이전트 구성 변수에 대한 자세한 정보는 [Amazon ECS 컨테이너 에이전트 구성](ecs-agent-config.md) 섹션을 참조하세요.
클러스터 이름과 같이 단일 에이전트 구성 변수만 설정하려면 **echo**를 사용하여 구성 파일에 변수를 복사합니다.
```
#!/bin/bash
echo "ECS_CLUSTER=MyCluster" >> /etc/ecs/ecs.config
```
`/etc/ecs/ecs.config`에 작성할 여러 변수가 있는 경우 다음 `heredoc` 형식을 사용합니다. 이 형식은 **cat**으로 시작하는 라인과 `EOF` 사이의 모든 항목을 구성 파일에 작성합니다.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
ECS_LOGLEVEL=debug
ECS_WARM_POOLS_CHECK=true
EOF
```
사용자 지정 인스턴스 속성을 설정하려면 `ECS_INSTANCE_ATTRIBUTES` 환경 변수를 설정합니다.
```
#!/bin/bash
cat <<'EOF' >> ecs.config
ECS_INSTANCE_ATTRIBUTES={"envtype":"prod"}
EOF
```
## Docker 대몬
Amazon EC2 사용자 데이터를 사용하여 Docker 대몬 구성 정보를 지정할 수 있습니다. 이 구성 옵션에 대한 자세한 정보는 [Docker 대몬 설명서](https://docs.docker.com/reference/cli/dockerd/)를 참조하세요.
**참고**
사용자 지정 Docker 구성은 경우에 따라 경고 없이 향후 Amazon ECS 변경 사항이나 기능과 충돌할 수 있으므로 AWS에서 지원하지 않습니다.
아래 예에서 사용자 정의 옵션이 Docker 대몬 구성 파일 `/etc/docker/daemon.json`에 추가되며, 파일은 인스턴스가 시작될 때 사용자 데이터에 지정됩니다.
```
#!/bin/bash
cat </etc/docker/daemon.json
{"debug": true}
EOF
systemctl restart docker --no-block
```
아래 예에서 사용자 정의 옵션이 Docker 대몬 구성 파일 `/etc/docker/daemon.json`에 추가되며, 파일은 인스턴스가 시작될 때 사용자 데이터에 지정됩니다. 이 예제에서는 Docker 대몬(daemon) 구성 파일에서 docker-proxy를 비활성화하는 방법을 보여줍니다.
```
#!/bin/bash
cat </etc/docker/daemon.json
{"userland-proxy": false}
EOF
systemctl restart docker --no-block
```
# 스팟 인스턴스 알림을 수신하도록 Amazon ECS Linux 컨테이너 인스턴스 구성
스팟 가격이 요청의 최고가를 초과하거나 용량이 더 이상 제공되지 않는 경우 Amazon EC2는 스팟 인스턴스를 종료, 중지 또는 최대 절전 모드로 전환합니다. Amazon EC2는 종료 및 중지 작업에 대해 스팟 인스턴스 2분 중단 알림을 제공합니다. 최대 절전 모드 작업에 대한 2분 알림을 제공하지 않습니다. 인스턴스에서 Amazon ECS 스팟 인스턴스 드레이닝이 활성화된 경우 Amazon ECS는 스팟 인스턴스 중단 알림을 수신하고 인스턴스를 `DRAINING` 상태로 둡니다.
**중요**
Amazon ECS는 Auto Scaling 용량 재분배에 의해 인스턴스가 제거될 때 Amazon EC2로부터 알림을 받지 않습니다. 자세한 정보는 [Amazon EC2 Auto Scaling 용량 재분배](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html)를 참조하세요.
컨테이너 인스턴스를 `DRAINING`으로 설정할 경우 Amazon ECS는 새 작업이 컨테이너 인스턴스에서 배치를 위해 예약되지 않도록 합니다. 드레이닝 컨테이너 인스턴스에서 `PENDING` 상태인 서비스 작업이 즉시 중지됩니다. 클러스터에 사용 가능한 컨테이너 인스턴스가 있는 경우 거기서 대체 서비스 작업이 시작됩니다.
스팟 인스턴스 드레이닝은 기본적으로 꺼져 있습니다.
인스턴스를 시작할 때 스팟 인스턴스 드레인을 켤 수 있습니다. **사용자 데이터** 필드에 다음 스크립트를 추가합니다. *MyCluster*를 컨테이너 인스턴스를 등록할 클러스터의 이름으로 바꿉니다.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
EOF
```
자세한 내용은 [Amazon ECS Linux 컨테이너 인스턴스 시작](launch_container_instance.md) 섹션을 참조하세요.
**기존 컨테이너 인스턴스에 스팟 인스턴스 드레이닝 사용 설정**
1. SSH를 통해 스팟 인스턴스에 연결합니다.
1. `/etc/ecs/ecs.config` 파일을 편집하고 다음을 추가합니다.
```
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
```
1. `ecs` 서비스를 다시 시작합니다.
+ Amazon ECS 최적화 Amazon Linux 2 AMI의 경우:
```
sudo systemctl restart ecs
```
1. (선택 사항) 에이전트 내부 검사 API 태스크를 쿼리하여 에이전트가 실행 중인지 확인하고 새 컨테이너 인스턴스에 대한 일부 정보를 볼 수 있습니다. 자세한 내용은 [Amazon ECS 컨테이너 내부 검사](ecs-agent-introspection.md) 섹션을 참조하세요.
```
curl http://localhost:51678/v1/metadata
```
# Amazon ECS Linux 컨테이너 인스턴스를 시작할 때 스크립트 실행
모니터링, 보안, 지표, 서비스 검색 또는 로깅과 같은 작업 또는 보안 문제를 처리하기 위해 모든 컨테이너 인스턴스에서 특정 컨테이너를 실행해야 할 수도 있습니다.
이렇게 하려면 시작 시 사용자 데이터 스크립트와 함께 **docker run** 명령(또는 일부 init 시스템에서는 Upstart나 **systemd** 등)을 호출하도록 컨테이너 인스턴스를 구성하는 것입니다. 이 방법은 효과적이지만 몇 가지 단점도 있는데, Amazon ECS는 컨테이너에 대한 지식이 없고 사용되는 CPU, 메모리, 포트 또는 기타 리소스를 모니터링할 수 없기 때문입니다. Amazon ECS가 모든 작업 리소스를 적절히 고려하도록 하려면 컨테이너 인스턴스에서 실행할 컨테이너의 태스크 정의를 생성합니다. 그런 다음 Amazon ECS를 사용하여 Amazon EC2 사용자 데이터와 함께 시작 시간에 태스크를 배치합니다.
다음 절차의 Amazon EC2 사용자 데이터 스크립트는 Amazon ECS 내부 검사 API를 사용하여 컨테이너 인스턴스를 식별한 다음 AWS CLI와 **start-task** 명령을 사용하여 시작 도중 지정된 태스크를 자체에서 실행합니다.
**컨테이너 인스턴스 시작 시간에 태스크를 시작하려면**
1. `ecsInstanceRole` IAM 역할을 수정하여 `StartTask` API 작업에 대한 권한을 추가합니다. 자세한 내용은 *AWS Identity and Access Management 사용 설명서*의 [역할 권한 업데이트](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_update-role-permissions.html)를 참조하세요.
1. Amazon ECS 최적화 Amazon Linux 2 AMI를 사용하여 하나 이상의 컨테이너 인스턴스를 시작합니다. 새 컨테이너 인스턴스를 시작하고 EC2 사용자 데이터에서 다음 예제 스크립트를 사용합니다. *your\$1cluster\$1name*을 등록할 컨테이너 인스턴스의 클러스터로, *my\$1task\$1def*를 시작 시 인스턴스에서 실행할 태스크 정의로 바꿉니다.
자세한 내용은 [Amazon ECS Linux 컨테이너 인스턴스 시작](launch_container_instance.md) 섹션을 참조하세요.
**참고**
아래의 MIME 멀티파트 콘텐츠는 셸 스크립트를 사용하여 구성 값을 설정하고 패키지를 설치합니다. 또한 **ecs** 서비스가 실행되고 내부 검사 API를 사용할 수 있게 된 후 systemd 태스크를 사용하여 태스크를 시작합니다.
```
Content-Type: multipart/mixed; boundary="==BOUNDARY=="
MIME-Version: 1.0
--==BOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
# Specify the cluster that the container instance should register into
cluster=your_cluster_name
# Write the cluster configuration variable to the ecs.config file
# (add any other configuration variables here also)
echo ECS_CLUSTER=$cluster >> /etc/ecs/ecs.config
START_TASK_SCRIPT_FILE="/etc/ecs/ecs-start-task.sh"
cat <<- 'EOF' > ${START_TASK_SCRIPT_FILE}
exec 2>>/var/log/ecs/ecs-start-task.log
set -x
# Install prerequisite tools
yum install -y jq aws-cli
# Wait for the ECS service to be responsive
until curl -s http://localhost:51678/v1/metadata
do
sleep 1
done
# Grab the container instance ARN and AWS Region from instance metadata
instance_arn=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F/ '{print $NF}' )
cluster=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .Cluster' | awk -F/ '{print $NF}' )
region=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F: '{print $4}')
# Specify the task definition to run at launch
task_definition=my_task_def
# Run the AWS CLI start-task command to start your task on this container instance
aws ecs start-task --cluster $cluster --task-definition $task_definition --container-instances $instance_arn --started-by $instance_arn --region $region
EOF
# Write systemd unit file
UNIT="ecs-start-task.service"
cat <<- EOF > /etc/systemd/system/${UNIT}
[Unit]
Description=ECS Start Task
Requires=ecs.service
After=ecs.service
[Service]
Restart=on-failure
RestartSec=30
ExecStart=/usr/bin/bash ${START_TASK_SCRIPT_FILE}
[Install]
WantedBy=default.target
EOF
# Enable our ecs.service dependent service with `--no-block` to prevent systemd deadlock
# See https://github.com/aws/amazon-ecs-agent/issues/1707
systemctl enable --now --no-block "${UNIT}"
--==BOUNDARY==--
```
1. 컨테이너 인스턴스가 올바른 클러스터로 시작되고 태스크가 시작되었는지 확인합니다.
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 모음에서 클러스터가 속한 리전을 선택합니다.
1. 탐색 창에서 **클러스터**를 선택하고 컨테이너 인스턴스를 호스팅하는 클러스터를 선택합니다.
1. **Cluster**(클러스터) 페이지에서 **Tasks**(작업)를 선택한 다음 작업을 선택합니다.
실행한 각 컨테이너 인스턴스에서 작업이 실행 중이어야 합니다.
작업이 보이지 않는 경우, SSH를 사용하여 컨테이너 인스턴스에 로그인하고 `/var/log/ecs/ecs-start-task.log` 파일에서 디버깅 정보를 확인할 수 있습니다.
# Amazon ECS Linux 컨테이너 인스턴스 네트워크 인터페이스 증가
**참고**
이 기능은 Fargate에서 사용할 수 없습니다.
`awsvpc` 네트워크 모드를 사용하는 각 작업은 고유한 탄력적 네트워크 인터페이스(ENI)를 수신합니다. 이 인터페이스는 이를 호스팅하는 컨테이너 인스턴스에 연결되어 있습니다. Amazon EC2 인스턴스에 연결할 수 있는 네트워크 인터페이스 수에 대한 기본 제한이 있으며 기본 네트워크 인터페이스는 한 개로 계산됩니다. 예를 들어 기본적으로 `c5.large` 인스턴스에는 ENI를 3개까지 연결할 수 있습니다. 인스턴스에 대한 기본 네트워크 인터페이스는 한 개로 계산되므로 인스턴스에 ENI를 2개 더 연결할 수 있습니다. `awsvpc` 네트워크 모드를 사용하는 각 작업에는 ENI가 필요하므로 대개 이 인스턴스 유형에서는 이러한 작업을 2개만 실행할 수 있습니다.
Amazon ECS에서는 지원되는 Amazon EC2 인스턴스 유형을 사용하여 늘어난 ENI 밀도와 함께 컨테이너 인스턴스를 시작할 수 있습니다. 이러한 인스턴스 유형을 사용하고 `awsvpcTrunking` 계정 설정을 활성화하면 새로 시작된 컨테이너 인스턴스에서 추가 ENI를 사용할 수 있습니다. 이 구성을 통해 각 컨테이너 인스턴스에 추가 작업을 배치할 수 있습니다. 콘솔을 사용하여 기능을 켜려면 [Amazon ECS 계정 설정 수정](ecs-modifying-longer-id-settings.md) 섹션을 참조하세요. AWS CLI를 사용하여 기능을 켜려면 [AWS CLI를 사용하여 Amazon ECS 계정 설정 관리](account-setting-management-cli.md) 섹션을 참조하세요.
예를 들어 `awsvpcTrunking`이 있는 `c5.large` 인스턴스의 경우 ENI 제한이 12로 증가합니다. 컨테이너 인스턴스는 기본 네트워크 인터페이스를 가지며 Amazon ECS는 “트렁크” 네트워크 인터페이스를 생성하여 컨테이너 인스턴스에 연결합니다. 따라서 이 구성을 통해 컨테이너 인스턴스에서 현재 두 개의 작업 대신 10개의 태스크를 시작할 수 있습니다.
트렁크 네트워크 인터페이스는 Amazon ECS에 의해 완전히 관리되며 클러스터에서 컨테이너 인스턴스를 종료하거나 등록 취소할 때 삭제됩니다. 자세한 내용은 [EC2에 대한 Amazon ECS 태스크 네트워킹 옵션](task-networking.md) 섹션을 참조하세요.
## 고려 사항
ENI 트렁킹 기능을 사용하는 경우에는 다음을 고려하세요.
+ Amazon ECS 최적화 AMI의 Linux 변형 또는 버전 `1.28.1` 이상의 컨테이너 에이전트 및 버전 `1.28.1-2` 이상의 ecs-init 패키지를 포함하는 Amazon Linux 변형에서만 늘어난 ENI 제한을 지원합니다. Amazon ECS 최적화 AMI의 최신 Linux 변형을 사용하는 경우 이러한 요구 사항이 충족됩니다. Windows 컨테이너는 현재 지원되지 않습니다.
+ `awsvpcTrunking`을 활성화한 후 시작된 새 Amazon EC2 인스턴스만 늘어난 ENI 제한 및 트렁크 네트워크 인터페이스를 수신합니다. 이전에 시작한 인스턴스는 수행된 작업에 상관없이 이러한 기능을 받지 않습니다.
+ Amazon EC2 인스턴스에는 리소스 기반 IPv4 DNS 요청이 꺼져 있어야 합니다. 이 옵션을 비활성화하려면 Amazon EC2 콘솔에서 새 인스턴스를 생성할 때 **리소스 기반 IPV4(A 레코드) DNS 요청 활성화** 옵션을 삭제합니다. AWS CLI을(를) 사용하여 이 옵션을 비활성화하려면 다음 명령을 사용합니다.
```
aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
```
+ 공유 서브넷의 Amazon EC2 인스턴스는 지원되지 않습니다. 이 인스턴스를 사용하는 경우 클러스터에 등록하지 못합니다.
+ 태스크는 `awsvpc` 네트워크 모드 및 EC2를 사용해야 합니다. Fargate를 사용하는 태스크는 시작한 인스턴스의 개수에 상관없이 항상 전용 ENI를 수신하기 때문에 이 기능은 필요하지 않습니다.
+ 작업은 컨테이너 인스턴스와 동일한 Amazon VPC에서 시작해야 합니다. 작업이 동일한 VPC 내에 있지 않으면 속성 오류로 인해 태스크를 시작하지 못할 수 있습니다.
+ 새 컨테이너 인스턴스를 시작할 때 인스턴스가 `REGISTERING` 상태로 전환되며 해당 인스턴스에 대해 트렁크 탄력적 네트워크 인터페이스가 프로비저닝됩니다. 등록이 실패하면 인스턴스가 `REGISTRATION_FAILED` 상태로 전환됩니다. 실패 이유를 설명하는 `statusReason` 필드를 확인하기 위해 컨테이너 인스턴스를 설명하여 실패한 등록 문제를 해결할 수 있습니다. 입니다. 그런 다음 컨테이너 인스턴스를 수동으로 등록 취소하거나 종료할 수 있습니다. 컨테이너 인스턴스가 성공적으로 등록 취소되거나 종료되면 Amazon ECS가 트렁크 ENI를 삭제합니다.
**참고**
Amazon ECS는 컨테이너 인스턴스 상태 변경 이벤트를 발생시켜 사용자가 `REGISTRATION_FAILED` 상태로 전환하는 인스턴스를 모니터링할 수 있습니다. 자세한 정보는 [Amazon ECS 컨테이너 인스턴스 상태 변경 이벤트](ecs_container_instance_events.md) 섹션을 참조하세요.
+ 컨테이너 인스턴스가 종료되면 인스턴스가 `DEREGISTERING` 상태로 전환되며 트렁크 탄력적 네트워크 인터페이스가 프로비저닝 해제됩니다. 그런 다음 인스턴스가 `INACTIVE` 상태로 전환됩니다.
+ 늘어난 ENI 제한이 있는 퍼블릭 서브넷의 컨테이너 인스턴스가 중지된 후 다시 시작되면 인스턴스의 해당 퍼블릭 IP 주소가 없어지고 컨테이너 에이전트의 연결이 끊어집니다.
+ `awsvpcTrunking`을 활성화하면 컨테이너 인스턴스는 VPC의 기본 보안 그룹을 사용하는 추가 ENI를 수신하며 Amazon ECS에서 관리됩니다.
기본 VPC는 각 가용 영역의 퍼블릭 서브넷, 인터넷 게이트웨이 및 DNS 확인 활성화 설정과 함께 제공됩니다. 기본 라우팅 테이블은 인터넷으로 대상 주소가 정해진 서브넷의 트래픽을 인터넷 게이트웨이로 전송하기 때문에 서브넷은 퍼블릭 서브넷입니다. 대상 주소 0.0.0.0/0에서 인터넷 게이트웨이로의 라우팅을 제거함으로써 기본 서브넷을 프라이빗 서브넷으로 만들 수 있습니다. 하지만 이렇게 하면 해당 서브넷에서 실행하는 컨테이너 인스턴스는 인터넷에 액세스할 수 없습니다. 보안 그룹 규칙을 추가하거나 삭제하여 서브넷으로 들어오고 나가는 트래픽을 제어할 수 있습니다. 자세한 내용은 *Amazon Virtual Private Cloud 사용 설명서*의 [보안 그룹 규칙](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)을 참조하세요.
## 사전 조건
늘어난 ENI 제한이 있는 컨테이너 인스턴스를 시작하기 전에 다음 필수 조건을 완료해야 합니다.
+ Amazon ECS에 대한 서비스 연결 역할을 생성해야 합니다. Amazon ECS 서비스 연결 역할은 Amazon ECS에 사용자를 대신해서 다른 AWS 서비스를 호출할 수 있는 권한을 제공합니다. 이 역할은 클러스터를 생성하거나 AWS Management Console에서 서비스를 생성 또는 업데이트할 때 자동으로 생성됩니다. 자세한 정보는 [Amazon ECS에 대해 서비스 연결 역할 사용](using-service-linked-roles.md) 섹션을 참조하세요. 다음 AWS CLI 명령을 사용하여 서비스 연결 역할을 생성할 수도 있습니다.
```
aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com
```
+ 계정 또는 컨테이너 인스턴스 IAM 역할이 `awsvpcTrunking` 계정 설정으로 활성화해야 합니다. 2개의 컨테이너 인스턴스 역할(`ecsInstanceRole`)을 생성하는 것이 좋습니다. 그런 다음, 역할 하나에 `awsvpcTrunking` 계정 설정을 활성화하고 ENI 트렁킹이 필요한 작업에 해당 역할을 사용할 수 있습니다. 컨테이너 인스턴스 역할에 대한 자세한 내용은 [Amazon ECS 컨테이너 인스턴스 IAM 역할](instance_IAM_role.md) 섹션을 참조하세요.
필수 조건이 충족되면 지원되는 Amazon EC2 인스턴스 유형 중 하나를 사용하여 새 컨테이너 인스턴스를 시작할 수 있으며, 해당 인스턴스에 늘어난 ENI 제한이 포함됩니다. 지원되는 인스턴스 유형의 목록은 [증가한 Amazon ECS 컨테이너 네트워크 인터페이스에 대해 지원되는 인스턴스](eni-trunking-supported-instance-types.md) 섹션을 참조하세요. 컨테이너 인스턴스에는 버전 `1.28.1` 이상의 컨테이너 에이전트 및 버전 `1.28.1-2` 이상의 ecs-init 패키지가 있어야 합니다. Amazon ECS 최적화 AMI의 최신 Linux 변형을 사용하는 경우 이러한 요구 사항이 충족됩니다. 자세한 내용은 [Amazon ECS Linux 컨테이너 인스턴스 시작](launch_container_instance.md) 섹션을 참조하세요.
**중요**
Amazon EC2 인스턴스에는 리소스 기반 IPv4 DNS 요청이 꺼져 있어야 합니다. 이 옵션을 비활성화하려면 **리소스 기반 IPV4(A 레코드) DNS 요청 활성화** 옵션이 Amazon EC2 콘솔을 사용하여 새 인스턴스를 생성할 때 선택 취소되었는지 확인합니다. AWS CLI을(를) 사용하여 이 옵션을 비활성화하려면 다음 명령을 사용합니다.
```
aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
```
**AWS CLI를 사용하여 늘어난 ENI 제한이 있는 컨테이너 인스턴스를 보는 방법**
각 컨테이너 인스턴스에는 트렁크 네트워크 인터페이스라고 하는 기본 네트워크 인터페이스가 있습니다. 다음 명령을 통해 `ecs.awsvpc-trunk-id` 속성을 쿼리하여 늘어난 ENI 제한이 있는 컨테이너 인스턴스를 나열합니다. 이는 컨테이너 인스턴스에 트렁크 네트워크 인터페이스가 있음을 나타냅니다.
+ [list-attributes](https://docs.aws.amazon.com/cli/latest/reference/ecs/list-attributes.html)(AWS CLI)
```
aws ecs list-attributes \
--target-type container-instance \
--attribute-name ecs.awsvpc-trunk-id \
--cluster cluster_name \
--region us-east-1
```
+ [Get-ECSAttributeList](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ECSAttributeList.html)(AWS Tools for Windows PowerShell)
```
Get-ECSAttributeList -TargetType container-instance -AttributeName ecs.awsvpc-trunk-id -Region us-east-1
```
# 증가한 Amazon ECS 컨테이너 네트워크 인터페이스에 대해 지원되는 인스턴스
다음은 지원되는 Amazon EC2 인스턴스 유형 및 `awsvpcTrunking` 계정 설정을 활성화하기 전과 후 각 인스턴스 유형에서 `awsvpc` 네트워크 모드를 사용하는 여러 작업을 시작할 수 있는 방법을 보여줍니다.
**중요**
다른 인스턴스 유형이 동일한 인스턴스 패밀리에서 지원되지만 `a1.metal`, `c5.metal`, `c5a.8xlarge`, `c5ad.8xlarge`, `c5d.metal`, `m5.metal`, `p3dn.24xlarge`, `r5.metal`, `r5.8xlarge` 및 `r5d.metal` 인스턴스 유형은 지원되지 않습니다.
`c5n`, `d3`, `d3en`, `g3`, `g3s`, `g4dn`, `i3`, `i3en`, `inf1`, `m5dn`, `m5n`, `m5zn`, `mac1`, `r5b`, `r5n`, `r5dn`, `u-12tb1`, `u-6tb1`, `u-9tb1` 및 `z1d` 인스턴스 패밀리는 지원되지 않습니다.
**Topics**
+ [
## 범용
](#eni-branch-gp)
+ [
## 컴퓨팅 최적화
](#eni-branch-co)
+ [
## 메모리 최적화
](#eni-branch-mo)
+ [
## 스토리지 최적화
](#eni-branch-so)
+ [
## 가속 컴퓨팅
](#eni-branch-ac)
+ [
## 고성능 컴퓨팅
](#eni-branch-hpc)
## 범용
| 인스턴스 유형 | ENI 트렁킹이 없는 작업 제한 | ENI 트렁킹을 포함하는 작업 제한 |
| --- | --- | --- |
| a1.medium | 1 | 10 |
| a1.large | 2 | 10 |
| a1.xlarge | 3 | 20 |
| a1.2xlarge | 3 | 40 |
| a1.4xlarge | 7 | 60 |
| m5.large | 2 | 10 |
| m5.xlarge | 3 | 20 |
| m5.2xlarge | 3 | 40 |
| m5.4xlarge | 7 | 60 |
| m5.8xlarge | 7 | 60 |
| m5.12xlarge | 7 | 60 |
| m5.16xlarge | 14 | 120 |
| m5.24xlarge | 14 | 120 |
| m5a.large | 2 | 10 |
| m5a.xlarge | 3 | 20 |
| m5a.2xlarge | 3 | 40 |
| m5a.4xlarge | 7 | 60 |
| m5a.8xlarge | 7 | 60 |
| m5a.12xlarge | 7 | 60 |
| m5a.16xlarge | 14 | 120 |
| m5a.24xlarge | 14 | 120 |
| m5ad.large | 2 | 10 |
| m5ad.xlarge | 3 | 20 |
| m5ad.2xlarge | 3 | 40 |
| m5ad.4xlarge | 7 | 60 |
| m5ad.8xlarge | 7 | 60 |
| m5ad.12xlarge | 7 | 60 |
| m5ad.16xlarge | 14 | 120 |
| m5ad.24xlarge | 14 | 120 |
| m5d.large | 2 | 10 |
| m5d.xlarge | 3 | 20 |
| m5d.2xlarge | 3 | 40 |
| m5d.4xlarge | 7 | 60 |
| m5d.8xlarge | 7 | 60 |
| m5d.12xlarge | 7 | 60 |
| m5d.16xlarge | 14 | 120 |
| m5d.24xlarge | 14 | 120 |
| m5d.metal | 14 | 120 |
| m6a.large | 2 | 10 |
| m6a.xlarge | 3 | 20 |
| m6a.2xlarge | 3 | 40 |
| m6a.4xlarge | 7 | 60 |
| m6a.8xlarge | 7 | 90 |
| m6a.12xlarge | 7 | 120 |
| m6a.16xlarge | 14 | 120 |
| m6a.24xlarge | 14 | 120 |
| m6a.32xlarge | 14 | 120 |
| m6a.48xlarge | 14 | 120 |
| m6a.metal | 14 | 120 |
| m6g.medium | 1 | 4 |
| m6g.large | 2 | 10 |
| m6g.xlarge | 3 | 20 |
| m6g.2xlarge | 3 | 40 |
| m6g.4xlarge | 7 | 60 |
| m6g.8xlarge | 7 | 60 |
| m6g.12xlarge | 7 | 60 |
| m6g.16xlarge | 14 | 120 |
| m6g.metal | 14 | 120 |
| m6gd.medium | 1 | 4 |
| m6gd.large | 2 | 10 |
| m6gd.xlarge | 3 | 20 |
| m6gd.2xlarge | 3 | 40 |
| m6gd.4xlarge | 7 | 60 |
| m6gd.8xlarge | 7 | 60 |
| m6gd.12xlarge | 7 | 60 |
| m6gd.16xlarge | 14 | 120 |
| m6gd.metal | 14 | 120 |
| m6i.large | 2 | 10 |
| m6i.xlarge | 3 | 20 |
| m6i.2xlarge | 3 | 40 |
| m6i.4xlarge | 7 | 60 |
| m6i.8xlarge | 7 | 90 |
| m6i.12xlarge | 7 | 120 |
| m6i.16xlarge | 14 | 120 |
| m6i.24xlarge | 14 | 120 |
| m6i.32xlarge | 14 | 120 |
| m6i.metal | 14 | 120 |
| m6id.large | 2 | 10 |
| m6id.xlarge | 3 | 20 |
| m6id.2xlarge | 3 | 40 |
| m6id.4xlarge | 7 | 60 |
| m6id.8xlarge | 7 | 90 |
| m6id.12xlarge | 7 | 120 |
| m6id.16xlarge | 14 | 120 |
| m6id.24xlarge | 14 | 120 |
| m6id.32xlarge | 14 | 120 |
| m6id.metal | 14 | 120 |
| m6idn.large | 2 | 10 |
| m6idn.xlarge | 3 | 20 |
| m6idn.2xlarge | 3 | 40 |
| m6idn.4xlarge | 7 | 60 |
| m6idn.8xlarge | 7 | 90 |
| m6idn.12xlarge | 7 | 120 |
| m6idn.16xlarge | 14 | 120 |
| m6idn.24xlarge | 14 | 120 |
| m6idn.32xlarge | 15 | 120 |
| m6idn.metal | 15 | 120 |
| m6in.large | 2 | 10 |
| m6in.xlarge | 3 | 20 |
| m6in.2xlarge | 3 | 40 |
| m6in.4xlarge | 7 | 60 |
| m6in.8xlarge | 7 | 90 |
| m6in.12xlarge | 7 | 120 |
| m6in.16xlarge | 14 | 120 |
| m6in.24xlarge | 14 | 120 |
| m6in.32xlarge | 15 | 120 |
| m6in.metal | 15 | 120 |
| m7a.medium | 1 | 4 |
| m7a.large | 2 | 10 |
| m7a.xlarge | 3 | 20 |
| m7a.2xlarge | 3 | 40 |
| m7a.4xlarge | 7 | 60 |
| m7a.8xlarge | 7 | 90 |
| m7a.12xlarge | 7 | 120 |
| m7a.16xlarge | 14 | 120 |
| m7a.24xlarge | 14 | 120 |
| m7a.32xlarge | 14 | 120 |
| m7a.48xlarge | 14 | 120 |
| m7a.metal-48xl | 14 | 120 |
| m7g.medium | 1 | 4 |
| m7g.large | 2 | 10 |
| m7g.xlarge | 3 | 20 |
| m7g.2xlarge | 3 | 40 |
| m7g.4xlarge | 7 | 60 |
| m7g.8xlarge | 7 | 60 |
| m7g.12xlarge | 7 | 60 |
| m7g.16xlarge | 14 | 120 |
| m7g.metal | 14 | 120 |
| m7gd.medium | 1 | 4 |
| m7gd.large | 2 | 10 |
| m7gd.xlarge | 3 | 20 |
| m7gd.2xlarge | 3 | 40 |
| m7gd.4xlarge | 7 | 60 |
| m7gd.8xlarge | 7 | 60 |
| m7gd.12xlarge | 7 | 60 |
| m7gd.16xlarge | 14 | 120 |
| m7gd.metal | 14 | 120 |
| m7i.large | 2 | 10 |
| m7i.xlarge | 3 | 20 |
| m7i.2xlarge | 3 | 40 |
| m7i.4xlarge | 7 | 60 |
| m7i.8xlarge | 7 | 90 |
| m7i.12xlarge | 7 | 120 |
| m7i.16xlarge | 14 | 120 |
| m7i.24xlarge | 14 | 120 |
| m7i.48xlarge | 14 | 120 |
| m7i.metal-24xl | 14 | 120 |
| m7i.metal-48xl | 14 | 120 |
| m7i-flex.large | 2 | 4 |
| m7i-flex.xlarge | 3 | 10 |
| m7i-flex.2xlarge | 3 | 20 |
| m7i-flex.4xlarge | 7 | 40 |
| m7i-flex.8xlarge | 7 | 60 |
| m7i-flex.12xlarge | 7 | 120 |
| m7i-flex.16xlarge | 14 | 120 |
| m8a.medium | 1 | 4 |
| m8a.large | 2 | 10 |
| m8a.xlarge | 3 | 20 |
| m8a.2xlarge | 3 | 40 |
| m8a.4xlarge | 7 | 60 |
| m8a.8xlarge | 9 | 90 |
| m8a.12xlarge | 11 | 120 |
| m8a.16xlarge | 15 | 120 |
| m8a.24xlarge | 15 | 120 |
| m8a.48xlarge | 23 | 120 |
| m8a.metal-24xl | 15 | 120 |
| m8a.metal-48xl | 23 | 120 |
| m8azn.medium | 2 | 4 |
| m8azn.large | 3 | 10 |
| m8azn.xlarge | 3 | 20 |
| m8azn.3xlarge | 7 | 40 |
| m8azn.6xlarge | 7 | 60 |
| m8azn.12xlarge | 15 | 120 |
| m8azn.24xlarge | 15 | 120 |
| m8azn.metal-12xl | 15 | 120 |
| m8azn.metal-24xl | 15 | 120 |
| m8g.medium | 1 | 4 |
| m8g.large | 2 | 10 |
| m8g.xLarge | 3 | 20 |
| m8g.2xlarge | 3 | 40 |
| m8g.4xlarge | 7 | 60 |
| m8g.8xlarge | 7 | 60 |
| m8g.12xlarge | 7 | 60 |
| m8g.16xlarge | 14 | 120 |
| m8g.24xlarge | 14 | 120 |
| m8g.48xlarge | 14 | 120 |
| m8g.metal-24xl | 14 | 120 |
| m8g.metal-48xl | 14 | 120 |
| m8gb.medium | 1 | 4 |
| m8gb.large | 2 | 10 |
| m8gb.xlarge | 3 | 20 |
| m8gb.2xlarge | 3 | 40 |
| m8gb.4xlarge | 7 | 60 |
| m8gb.8xlarge | 9 | 60 |
| m8gb.12xlarge | 11 | 60 |
| m8gb.16xlarge | 15 | 120 |
| m8gb.24xlarge | 23 | 120 |
| m8gb.48xlarge | 23 | 120 |
| m8gb.metal-24xl | 23 | 120 |
| m8gb.metal-48xl | 23 | 120 |
| m8gd.medium | 1 | 4 |
| m8gd.large | 2 | 10 |
| m8gd.xlarge | 3 | 20 |
| m8gd.2xlarge | 3 | 40 |
| m8gd.4xlarge | 7 | 60 |
| m8gd.8xlarge | 7 | 60 |
| m8gd.12xlarge | 7 | 60 |
| m8gd.16xlarge | 14 | 120 |
| m8gd.24xlarge | 14 | 120 |
| m8gd.48xlarge | 14 | 120 |
| m8gd.metal-24xl | 14 | 120 |
| m8gd.metal-48xl | 14 | 120 |
| m8gn.medium | 1 | 4 |
| m8gn.large | 2 | 10 |
| m8gn.xlarge | 3 | 20 |
| m8gn.2xlarge | 3 | 40 |
| m8gn.4xlarge | 7 | 60 |
| m8gn.8xlarge | 9 | 60 |
| m8gn.12xlarge | 11 | 60 |
| m8gn.16xlarge | 15 | 120 |
| m8gn.24xlarge | 23 | 120 |
| m8gn.48xlarge | 23 | 120 |
| m8gn.metal-24xl | 23 | 120 |
| m8gn.metal-48xl | 23 | 120 |
| m8i.large | 2 | 10 |
| m8i.xlarge | 3 | 20 |
| m8i.2xlarge | 3 | 40 |
| m8i.4xlarge | 7 | 60 |
| m8i.8xlarge | 9 | 90 |
| m8i.12xlarge | 11 | 120 |
| m8i.16xlarge | 15 | 120 |
| m8i.24xlarge | 15 | 120 |
| m8i.32xlarge | 23 | 120 |
| m8i.48xlarge | 23 | 120 |
| m8i.96xlarge | 23 | 120 |
| m8i.metal-48xl | 23 | 120 |
| m8i.metal-96xl | 23 | 120 |
| m8id.large | 2 | 10 |
| m8id.xlarge | 3 | 20 |
| m8id.2xlarge | 3 | 40 |
| m8id.4xlarge | 7 | 60 |
| m8id.8xlarge | 9 | 90 |
| m8id.12xlarge | 11 | 120 |
| m8id.16xlarge | 15 | 120 |
| m8id.24xlarge | 15 | 120 |
| m8id.32xlarge | 23 | 120 |
| m8id.48xlarge | 23 | 120 |
| m8id.96xlarge | 23 | 120 |
| m8id.metal-48xl | 23 | 120 |
| m8id.metal-96xl | 23 | 120 |
| m8i-flex.large | 2 | 4 |
| m8i-flex.xlarge | 3 | 10 |
| m8i-flex.2xlarge | 3 | 20 |
| m8i-flex.4xlarge | 7 | 40 |
| m8i-flex.8xlarge | 9 | 60 |
| m8i-flex.12xlarge | 11 | 120 |
| m8i-flex.16xlarge | 15 | 120 |
| mac2.metal | 7 | 12 |
| mac2-m1ultra.metal | 7 | 12 |
| mac2-m2.metal | 7 | 12 |
| mac2-m2pro.metal | 7 | 12 |
| mac-m4.metal | 7 | 12 |
| mac-m4pro.metal | 7 | 12 |
## 컴퓨팅 최적화
| 인스턴스 유형 | ENI 트렁킹이 없는 작업 제한 | ENI 트렁킹을 포함하는 작업 제한 |
| --- | --- | --- |
| c5.large | 2 | 10 |
| c5.xlarge | 3 | 20 |
| c5.2xlarge | 3 | 40 |
| c5.4xlarge | 7 | 60 |
| c5.9xlarge | 7 | 60 |
| c5.12xlarge | 7 | 60 |
| c5.18xlarge | 14 | 120 |
| c5.24xlarge | 14 | 120 |
| c5a.large | 2 | 10 |
| c5a.xlarge | 3 | 20 |
| c5a.2xlarge | 3 | 40 |
| c5a.4xlarge | 7 | 60 |
| c5a.12xlarge | 7 | 60 |
| c5a.16xlarge | 14 | 120 |
| c5a.24xlarge | 14 | 120 |
| c5ad.large | 2 | 10 |
| c5ad.xlarge | 3 | 20 |
| c5ad.2xlarge | 3 | 40 |
| c5ad.4xlarge | 7 | 60 |
| c5ad.12xlarge | 7 | 60 |
| c5ad.16xlarge | 14 | 120 |
| c5ad.24xlarge | 14 | 120 |
| c5d.large | 2 | 10 |
| c5d.xlarge | 3 | 20 |
| c5d.2xlarge | 3 | 40 |
| c5d.4xlarge | 7 | 60 |
| c5d.9xlarge | 7 | 60 |
| c5d.12xlarge | 7 | 60 |
| c5d.18xlarge | 14 | 120 |
| c5d.24xlarge | 14 | 120 |
| c6a.large | 2 | 10 |
| c6a.xlarge | 3 | 20 |
| c6a.2xlarge | 3 | 40 |
| c6a.4xlarge | 7 | 60 |
| c6a.8xlarge | 7 | 90 |
| c6a.12xlarge | 7 | 120 |
| c6a.16xlarge | 14 | 120 |
| c6a.24xlarge | 14 | 120 |
| c6a.32xlarge | 14 | 120 |
| c6a.48xlarge | 14 | 120 |
| c6a.metal | 14 | 120 |
| c6g.medium | 1 | 4 |
| c6g.large | 2 | 10 |
| c6g.xlarge | 3 | 20 |
| c6g.2xlarge | 3 | 40 |
| c6g.4xlarge | 7 | 60 |
| c6g.8xlarge | 7 | 60 |
| c6g.12xlarge | 7 | 60 |
| c6g.16xlarge | 14 | 120 |
| c6g.metal | 14 | 120 |
| c6gd.medium | 1 | 4 |
| c6gd.large | 2 | 10 |
| c6gd.xlarge | 3 | 20 |
| c6gd.2xlarge | 3 | 40 |
| c6gd.4xlarge | 7 | 60 |
| c6gd.8xlarge | 7 | 60 |
| c6gd.12xlarge | 7 | 60 |
| c6gd.16xlarge | 14 | 120 |
| c6gd.metal | 14 | 120 |
| c6gn.medium | 1 | 4 |
| c6gn.large | 2 | 10 |
| c6gn.xlarge | 3 | 20 |
| c6gn.2xlarge | 3 | 40 |
| c6gn.4xlarge | 7 | 60 |
| c6gn.8xlarge | 7 | 60 |
| c6gn.12xlarge | 7 | 60 |
| c6gn.16xlarge | 14 | 120 |
| c6i.large | 2 | 10 |
| c6i.xlarge | 3 | 20 |
| c6i.2xlarge | 3 | 40 |
| c6i.4xlarge | 7 | 60 |
| c6i.8xlarge | 7 | 90 |
| c6i.12xlarge | 7 | 120 |
| c6i.16xlarge | 14 | 120 |
| c6i.24xlarge | 14 | 120 |
| c6i.32xlarge | 14 | 120 |
| c6i.metal | 14 | 120 |
| c6id.large | 2 | 10 |
| c6id.xlarge | 3 | 20 |
| c6id.2xlarge | 3 | 40 |
| c6id.4xlarge | 7 | 60 |
| c6id.8xlarge | 7 | 90 |
| c6id.12xlarge | 7 | 120 |
| c6id.16xlarge | 14 | 120 |
| c6id.24xlarge | 14 | 120 |
| c6id.32xlarge | 14 | 120 |
| c6id.metal | 14 | 120 |
| c6in.large | 2 | 10 |
| c6in.xlarge | 3 | 20 |
| c6in.2xlarge | 3 | 40 |
| c6in.4xlarge | 7 | 60 |
| c6in.8xlarge | 7 | 90 |
| c6in.12xlarge | 7 | 120 |
| c6in.16xlarge | 14 | 120 |
| c6in.24xlarge | 14 | 120 |
| c6in.32xlarge | 15 | 120 |
| c6in.metal | 15 | 120 |
| c7a.medium | 1 | 4 |
| c7a.large | 2 | 10 |
| c7a.xlarge | 3 | 20 |
| c7a.2xlarge | 3 | 40 |
| c7a.4xlarge | 7 | 60 |
| c7a.8xlarge | 7 | 90 |
| c7a.12xlarge | 7 | 120 |
| c7a.16xlarge | 14 | 120 |
| c7a.24xlarge | 14 | 120 |
| c7a.32xlarge | 14 | 120 |
| c7a.48xlarge | 14 | 120 |
| c7a.metal-48xl | 14 | 120 |
| c7g.medium | 1 | 4 |
| c7g.large | 2 | 10 |
| c7g.xlarge | 3 | 20 |
| c7g.2xlarge | 3 | 40 |
| c7g.4xlarge | 7 | 60 |
| c7g.8xlarge | 7 | 60 |
| c7g.12xlarge | 7 | 60 |
| c7g.16xlarge | 14 | 120 |
| c7g.metal | 14 | 120 |
| c7gd.medium | 1 | 4 |
| c7gd.large | 2 | 10 |
| c7gd.xlarge | 3 | 20 |
| c7gd.2xlarge | 3 | 40 |
| c7gd.4xlarge | 7 | 60 |
| c7gd.8xlarge | 7 | 60 |
| c7gd.12xlarge | 7 | 60 |
| c7gd.16xlarge | 14 | 120 |
| c7gd.metal | 14 | 120 |
| c7gn.medium | 1 | 4 |
| c7gn.large | 2 | 10 |
| c7gn.xlarge | 3 | 20 |
| c7gn.2xlarge | 3 | 40 |
| c7gn.4xlarge | 7 | 60 |
| c7gn.8xlarge | 7 | 60 |
| c7gn.12xlarge | 7 | 60 |
| c7gn.16xlarge | 14 | 120 |
| c7gn.metal | 14 | 120 |
| c7i.large | 2 | 10 |
| c7i.xlarge | 3 | 20 |
| c7i.2xlarge | 3 | 40 |
| c7i.4xlarge | 7 | 60 |
| c7i.8xlarge | 7 | 90 |
| c7i.12xlarge | 7 | 120 |
| c7i.16xlarge | 14 | 120 |
| c7i.24xlarge | 14 | 120 |
| c7i.48xlarge | 14 | 120 |
| c7i.metal-24xl | 14 | 120 |
| c7i.metal-48xl | 14 | 120 |
| c7i-flex.large | 2 | 4 |
| c7i-flex.xlarge | 3 | 10 |
| c7i-flex.2xlarge | 3 | 20 |
| c7i-flex.4xlarge | 7 | 40 |
| c7i-flex.8xlarge | 7 | 60 |
| c7i-flex.12xlarge | 7 | 120 |
| c7i-flex.16xlarge | 14 | 120 |
| c8a.medium | 1 | 4 |
| c8a.large | 2 | 10 |
| c8a.xlarge | 3 | 20 |
| c8a.2xlarge | 3 | 40 |
| c8a.4xlarge | 7 | 60 |
| c8a.8xlarge | 9 | 90 |
| c8a.12xlarge | 11 | 120 |
| c8a.16xlarge | 15 | 120 |
| c8a.24xlarge | 15 | 120 |
| c8a.48xlarge | 23 | 120 |
| c8a.metal-24xl | 15 | 120 |
| c8a.metal-48xl | 23 | 120 |
| c8g.medium | 1 | 4 |
| c8g.large | 2 | 10 |
| c8g.xlarge | 3 | 20 |
| c8g.2xlarge | 3 | 40 |
| c8g.4xlarge | 7 | 60 |
| c8g.8xlarge | 7 | 60 |
| c8g.12xlarge | 7 | 60 |
| c8g.16xlarge | 14 | 120 |
| c8g.24xlarge | 14 | 120 |
| c8g.48xlarge | 14 | 120 |
| c8g.metal-24xl | 14 | 120 |
| c8g.metal-48xl | 14 | 120 |
| c8gb.medium | 1 | 4 |
| c8gb.large | 2 | 10 |
| c8gb.xlarge | 3 | 20 |
| c8gb.2xlarge | 3 | 40 |
| c8gb.4xlarge | 7 | 60 |
| c8gb.8xlarge | 9 | 60 |
| c8gb.12xlarge | 11 | 60 |
| c8gb.16xlarge | 15 | 120 |
| c8gb.24xlarge | 23 | 120 |
| c8gb.48xlarge | 23 | 120 |
| c8gb.metal-24xl | 23 | 120 |
| c8gb.metal-48xl | 23 | 120 |
| c8gd.medium | 1 | 4 |
| c8gd.large | 2 | 10 |
| c8gd.xlarge | 3 | 20 |
| c8gd.2xlarge | 3 | 40 |
| c8gd.4xlarge | 7 | 60 |
| c8gd.8xlarge | 7 | 60 |
| c8gd.12xlarge | 7 | 60 |
| c8gd.16xlarge | 14 | 120 |
| c8gd.24xlarge | 14 | 120 |
| c8gd.48xlarge | 14 | 120 |
| c8gd.metal-24xl | 14 | 120 |
| c8gd.metal-48xl | 14 | 120 |
| c8gn.medium | 1 | 4 |
| c8gn.large | 2 | 10 |
| c8gn.xlarge | 3 | 20 |
| c8gn.2xlarge | 3 | 40 |
| c8gn.4xlarge | 7 | 60 |
| c8gn.8xlarge | 9 | 60 |
| c8gn.12xlarge | 11 | 60 |
| c8gn.16xlarge | 15 | 120 |
| c8gn.24xlarge | 23 | 120 |
| c8gn.48xlarge | 23 | 120 |
| c8gn.metal-24xl | 23 | 120 |
| c8gn.metal-48xl | 23 | 120 |
| c8i.large | 2 | 10 |
| c8i.xlarge | 3 | 20 |
| c8i.2xlarge | 3 | 40 |
| c8i.4xlarge | 7 | 60 |
| c8i.8xlarge | 9 | 90 |
| c8i.12xlarge | 11 | 120 |
| c8i.16xlarge | 15 | 120 |
| c8i.24xlarge | 15 | 120 |
| c8i.32xlarge | 23 | 120 |
| c8i.48xlarge | 23 | 120 |
| c8i.96xlarge | 23 | 120 |
| c8i.metal-48xl | 23 | 120 |
| c8i.metal-96xl | 23 | 120 |
| c8id.large | 2 | 10 |
| c8id.xlarge | 3 | 20 |
| c8id.2xlarge | 3 | 40 |
| c8id.4xlarge | 7 | 60 |
| c8id.8xlarge | 9 | 90 |
| c8id.12xlarge | 11 | 120 |
| c8id.16xlarge | 15 | 120 |
| c8id.24xlarge | 15 | 120 |
| c8id.32xlarge | 23 | 120 |
| c8id.48xlarge | 23 | 120 |
| c8id.96xlarge | 23 | 120 |
| c8id.metal-48xl | 23 | 120 |
| c8id.metal-96xl | 23 | 120 |
| c8i-flex.large | 2 | 4 |
| c8i-flex.xlarge | 3 | 10 |
| c8i-flex.2xlarge | 3 | 20 |
| c8i-flex.4xlarge | 7 | 40 |
| c8i-flex.8xlarge | 9 | 60 |
| c8i-flex.12xlarge | 11 | 120 |
| c8i-flex.16xlarge | 15 | 120 |
## 메모리 최적화
| 인스턴스 유형 | ENI 트렁킹이 없는 작업 제한 | ENI 트렁킹을 포함하는 작업 제한 |
| --- | --- | --- |
| r5.large | 2 | 10 |
| r5.xlarge | 3 | 20 |
| r5.2xlarge | 3 | 40 |
| r5.4xlarge | 7 | 60 |
| r5.12xlarge | 7 | 60 |
| r5.16xlarge | 14 | 120 |
| r5.24xlarge | 14 | 120 |
| r5a.large | 2 | 10 |
| r5a.xlarge | 3 | 20 |
| r5a.2xlarge | 3 | 40 |
| r5a.4xlarge | 7 | 60 |
| r5a.8xlarge | 7 | 60 |
| r5a.12xlarge | 7 | 60 |
| r5a.16xlarge | 14 | 120 |
| r5a.24xlarge | 14 | 120 |
| r5ad.large | 2 | 10 |
| r5ad.xlarge | 3 | 20 |
| r5ad.2xlarge | 3 | 40 |
| r5ad.4xlarge | 7 | 60 |
| r5ad.8xlarge | 7 | 60 |
| r5ad.12xlarge | 7 | 60 |
| r5ad.16xlarge | 14 | 120 |
| r5ad.24xlarge | 14 | 120 |
| r5b.16xlarge | 14 | 120 |
| r5d.large | 2 | 10 |
| r5d.xlarge | 3 | 20 |
| r5d.2xlarge | 3 | 40 |
| r5d.4xlarge | 7 | 60 |
| r5d.8xlarge | 7 | 60 |
| r5d.12xlarge | 7 | 60 |
| r5d.16xlarge | 14 | 120 |
| r5d.24xlarge | 14 | 120 |
| r5dn.16xlarge | 14 | 120 |
| r6a.large | 2 | 10 |
| r6a.xlarge | 3 | 20 |
| r6a.2xlarge | 3 | 40 |
| r6a.4xlarge | 7 | 60 |
| r6a.8xlarge | 7 | 90 |
| r6a.12xlarge | 7 | 120 |
| r6a.16xlarge | 14 | 120 |
| r6a.24xlarge | 14 | 120 |
| r6a.32xlarge | 14 | 120 |
| r6a.48xlarge | 14 | 120 |
| r6a.metal | 14 | 120 |
| r6g.medium | 1 | 4 |
| r6g.large | 2 | 10 |
| r6g.xlarge | 3 | 20 |
| r6g.2xlarge | 3 | 40 |
| r6g.4xlarge | 7 | 60 |
| r6g.8xlarge | 7 | 60 |
| r6g.12xlarge | 7 | 60 |
| r6g.16xlarge | 14 | 120 |
| r6g.metal | 14 | 120 |
| r6gd.미디엄 | 1 | 4 |
| r6gd.large | 2 | 10 |
| r6gd.xlarge | 3 | 20 |
| r6gd.2xlarge | 3 | 40 |
| r6gd.4xlarge | 7 | 60 |
| r6gd.8xlarge | 7 | 60 |
| r6gd.12xlarge | 7 | 60 |
| r6gd.16xlarge | 14 | 120 |
| r6gd.metal | 14 | 120 |
| r6i.large | 2 | 10 |
| r6i.xlarge | 3 | 20 |
| r6g.2xlarge | 3 | 40 |
| r6i.4xlarge | 7 | 60 |
| r6i.8xlarge | 7 | 90 |
| r6i.12xlarge | 7 | 120 |
| r6i.16xlarge | 14 | 120 |
| r6i.24xlarge | 14 | 120 |
| r6i.32xlarge | 14 | 120 |
| r6i.metal | 14 | 120 |
| r6id.large | 2 | 10 |
| r6id.xlarge | 3 | 20 |
| r6id.2xlarge | 3 | 40 |
| r6id.4xlarge | 7 | 60 |
| r6id.8xlarge | 7 | 90 |
| r6id.12xlarge | 7 | 120 |
| r6id.16xlarge | 14 | 120 |
| r6id.24xlarge | 14 | 120 |
| r6id.32xlarge | 14 | 120 |
| r6id.metal | 14 | 120 |
| r6idn.large | 2 | 10 |
| r6idn.xlarge | 3 | 20 |
| r6idn.2xlarge | 3 | 40 |
| r6idn.4xlarge | 7 | 60 |
| r6idn.8xlarge | 7 | 90 |
| r6idn.12xlarge | 7 | 120 |
| r6idn.16xlarge | 14 | 120 |
| r6idn.24xlarge | 14 | 120 |
| r6idn.32xlarge | 15 | 120 |
| r6idn.metal | 15 | 120 |
| r6in.large | 2 | 10 |
| r6in.xlarge | 3 | 20 |
| r6in.2xlarge | 3 | 40 |
| r6in.4xlarge | 7 | 60 |
| r6in.8xlarge | 7 | 90 |
| r6in.12xlarge | 7 | 120 |
| r6in.16xlarge | 14 | 120 |
| r6in.24xlarge | 14 | 120 |
| r6in.32xlarge | 15 | 120 |
| r6in.metal | 15 | 120 |
| r7a.medium | 1 | 4 |
| r7a.large | 2 | 10 |
| r7a.xlarge | 3 | 20 |
| r7a.2xlarge | 3 | 40 |
| r7a.4xlarge | 7 | 60 |
| r7a.8xlarge | 7 | 90 |
| r7a.12xlarge | 7 | 120 |
| r7a.16xlarge | 14 | 120 |
| r7a.24xlarge | 14 | 120 |
| r7a.32xlarge | 14 | 120 |
| r7a.48xlarge | 14 | 120 |
| r7a.metal-48xl | 14 | 120 |
| r7g.medium | 1 | 4 |
| r7g.large | 2 | 10 |
| r7g.xlarge | 3 | 20 |
| r7g.2xlarge | 3 | 40 |
| r7g.4xlarge | 7 | 60 |
| r7g.8xlarge | 7 | 60 |
| r7g.12xlarge | 7 | 60 |
| r7g.16xlarge | 14 | 120 |
| r7g.metal | 14 | 120 |
| r7gd.medium | 1 | 4 |
| r7gd.large | 2 | 10 |
| r7gd.xlarge | 3 | 20 |
| r7gd.2xlarge | 3 | 40 |
| r7gd.4xlarge | 7 | 60 |
| r7gd.8xlarge | 7 | 60 |
| r7gd.12xlarge | 7 | 60 |
| r7gd.16xlarge | 14 | 120 |
| r7gd.metal | 14 | 120 |
| r7i.large | 2 | 10 |
| r7i.xlarge | 3 | 20 |
| r7i.2xlarge | 3 | 40 |
| r7i.4xlarge | 7 | 60 |
| r7i.8xlarge | 7 | 90 |
| r7i.12xlarge | 7 | 120 |
| r7i.16xlarge | 14 | 120 |
| r7i.24xlarge | 14 | 120 |
| r7i.48xlarge | 14 | 120 |
| r7i.metal-24xl | 14 | 120 |
| r7i.metal-48xl | 14 | 120 |
| r7iz.large | 2 | 10 |
| r7iz.xlarge | 3 | 20 |
| r7iz.2xlarge | 3 | 40 |
| r7iz.4xlarge | 7 | 60 |
| r7iz.8xlarge | 7 | 90 |
| r7iz.12xlarge | 7 | 120 |
| r7iz.16xlarge | 14 | 120 |
| r7iz.32xlarge | 14 | 120 |
| r7iz.metal-16xl | 14 | 120 |
| r7iz.metal-32xl | 14 | 120 |
| r8a.medium | 1 | 4 |
| r8a.large | 2 | 10 |
| r8a.xlarge | 3 | 20 |
| r8a.2xlarge | 3 | 40 |
| r8a.4xlarge | 7 | 60 |
| r8a.8xlarge | 9 | 90 |
| r8a.12xlarge | 11 | 120 |
| r8a.16xlarge | 15 | 120 |
| r8a.24xlarge | 15 | 120 |
| r8a.48xlarge | 23 | 120 |
| r8a.metal-24xl | 15 | 120 |
| r8a.metal-48xl | 23 | 120 |
| r8g.medium | 1 | 4 |
| r8g.large | 2 | 10 |
| r8g.xlarge | 3 | 20 |
| r8g.2xlarge | 3 | 40 |
| r8g.4xlarge | 7 | 60 |
| r8g.8xlarge | 7 | 60 |
| r8g.12xlarge | 7 | 60 |
| r8g.16xlarge | 14 | 120 |
| r8g.24xlarge | 14 | 120 |
| r8g.48xlarge | 14 | 120 |
| r8g.metal-24xl | 14 | 120 |
| r8g.metal-48xl | 14 | 120 |
| r8gb.medium | 1 | 4 |
| r8gb.large | 2 | 10 |
| r8gb.xlarge | 3 | 20 |
| r8gb.2xlarge | 3 | 40 |
| r8gb.4xlarge | 7 | 60 |
| r8gb.8xlarge | 9 | 60 |
| r8gb.12xlarge | 11 | 60 |
| r8gb.16xlarge | 15 | 120 |
| r8gb.24xlarge | 23 | 120 |
| r8gb.48xlarge | 23 | 120 |
| r8gb.metal-24xl | 23 | 120 |
| r8gb.metal-48xl | 23 | 120 |
| r8gd.medium | 1 | 4 |
| r8gd.large | 2 | 10 |
| r8gd.xlarge | 3 | 20 |
| r8gd.2xlarge | 3 | 40 |
| r8gd.4xlarge | 7 | 60 |
| r8gd.8xlarge | 7 | 60 |
| r8gd.12xlarge | 7 | 60 |
| r8gd.16xlarge | 14 | 120 |
| r8gd.24xlarge | 14 | 120 |
| r8gd.48xlarge | 14 | 120 |
| r8gd.metal-24xl | 14 | 120 |
| r8gd.metal-48xl | 14 | 120 |
| r8gn.medium | 1 | 4 |
| r8gn.large | 2 | 10 |
| r8gn.xlarge | 3 | 20 |
| r8gn.2xlarge | 3 | 40 |
| r8gn.4xlarge | 7 | 60 |
| r8gn.8xlarge | 9 | 60 |
| r8gn.12xlarge | 11 | 60 |
| r8gn.16xlarge | 15 | 120 |
| r8gn.24xlarge | 23 | 120 |
| r8gn.48xlarge | 23 | 120 |
| r8gn.metal-24xl | 23 | 120 |
| r8gn.metal-48xl | 23 | 120 |
| r8i.large | 2 | 10 |
| r8i.xlarge | 3 | 20 |
| r8i.2xlarge | 3 | 40 |
| r8i.4xlarge | 7 | 60 |
| r8i.8xlarge | 9 | 90 |
| r8i.12xlarge | 11 | 120 |
| r8i.16xlarge | 15 | 120 |
| r8i.24xlarge | 15 | 120 |
| r8i.32xlarge | 23 | 120 |
| r8i.48xlarge | 23 | 120 |
| r8i.96xlarge | 23 | 120 |
| r8i.metal-48xl | 23 | 120 |
| r8i.metal-96xl | 23 | 120 |
| r8id.large | 2 | 10 |
| r8id.xlarge | 3 | 20 |
| r8id.2xlarge | 3 | 40 |
| r8id.4xlarge | 7 | 60 |
| r8id.8xlarge | 9 | 90 |
| r8id.12xlarge | 11 | 120 |
| r8id.16xlarge | 15 | 120 |
| r8id.24xlarge | 15 | 120 |
| r8id.32xlarge | 23 | 120 |
| r8id.48xlarge | 23 | 120 |
| r8id.96xlarge | 23 | 120 |
| r8id.metal-48xl | 23 | 120 |
| r8id.metal-96xl | 23 | 120 |
| r8i-flex.large | 2 | 4 |
| r8i-flex.xlarge | 3 | 10 |
| r8i-flex.2xlarge | 3 | 20 |
| r8i-flex.4xlarge | 7 | 40 |
| r8i-flex.8xlarge | 9 | 60 |
| r8i-flex.12xlarge | 11 | 120 |
| r8i-flex.16xlarge | 15 | 120 |
| u-3tb1.56xlarge | 7 | 12 |
| u-6tb1.56xlarge | 14 | 12 |
| u-18tb1.112xlarge | 14 | 12 |
| u-18tb1.metal | 14 | 12 |
| u-24tb1.112xlarge | 14 | 12 |
| u-24tb1.metal | 14 | 12 |
| u7i-6tb.112xlarge | 14 | 120 |
| u7i-8tb.112xlarge | 14 | 120 |
| u7i-12tb.224xlarge | 14 | 120 |
| u7in-16tb.224xlarge | 15 | 120 |
| u7in-24tb.224xlarge | 15 | 120 |
| u7in-32tb.224xlarge | 15 | 120 |
| u7inh-32tb.480xlarge | 15 | 120 |
| x2gd.medium | 1 | 10 |
| x2gd.large | 2 | 10 |
| x2gd.xlarge | 3 | 20 |
| x2gd.2xlarge | 3 | 40 |
| x2gd.4xlarge | 7 | 60 |
| x2gd.8xlarge | 7 | 60 |
| x2gd.12xlarge | 7 | 60 |
| x2gd.16xlarge | 14 | 120 |
| x2gd.metal | 14 | 120 |
| x2idn.16xlarge | 14 | 120 |
| x2idn.24xlarge | 14 | 120 |
| x2idn.32xlarge | 14 | 120 |
| x2idn.metal | 14 | 120 |
| x2iedn.xlarge | 3 | 13 |
| x2iedn.2xlarge | 3 | 29 |
| x2iedn.4xlarge | 7 | 60 |
| x2iedn.8xlarge | 7 | 120 |
| x2iedn.16xlarge | 14 | 120 |
| x2iedn.24xlarge | 14 | 120 |
| x2iedn.32xlarge | 14 | 120 |
| x2iedn.metal | 14 | 120 |
| x2iezn.2xlarge | 3 | 64 |
| x2iezn.4xlarge | 7 | 120 |
| x2iezn.6xlarge | 7 | 120 |
| x2iezn.8xlarge | 7 | 120 |
| x2iezn.12xlarge | 14 | 120 |
| x2iezn.metal | 14 | 120 |
| x8g.medium | 1 | 4 |
| x8g.large | 2 | 10 |
| x8g.xlarge | 3 | 20 |
| x8g.2xlarge | 3 | 40 |
| x8g.4xlarge | 7 | 60 |
| x8g.8xlarge | 7 | 60 |
| x8g.12xlarge | 7 | 60 |
| x8g.16xlarge | 14 | 120 |
| x8g.24xlarge | 14 | 120 |
| x8g.48xlarge | 14 | 120 |
| x8g.metal-24xl | 14 | 120 |
| x8g.metal-48xl | 14 | 120 |
| x8aedz.large | 3 | 10 |
| x8aedz.xlarge | 3 | 20 |
| x8aedz.3xlarge | 7 | 40 |
| x8aedz.6xlarge | 7 | 60 |
| x8aedz.12xlarge | 15 | 120 |
| x8aedz.24xlarge | 15 | 120 |
| x8aedz.metal-12xl | 15 | 120 |
| x8aedz.metal-24xl | 15 | 120 |
| x8i.large | 2 | 10 |
| x8i.xlarge | 3 | 20 |
| x8i.2xlarge | 3 | 40 |
| x8i.4xlarge | 7 | 60 |
| x8i.8xlarge | 9 | 90 |
| x8i.12xlarge | 11 | 120 |
| x8i.16xlarge | 15 | 120 |
| x8i.24xlarge | 15 | 120 |
| x8i.32xlarge | 23 | 120 |
| x8i.48xlarge | 23 | 120 |
| x8i.64xlarge | 23 | 120 |
| x8i.96xlarge | 23 | 120 |
| x8i.metal-48xl | 23 | 120 |
| x8i.metal-96xl | 23 | 120 |
## 스토리지 최적화
| 인스턴스 유형 | ENI 트렁킹이 없는 작업 제한 | ENI 트렁킹을 포함하는 작업 제한 |
| --- | --- | --- |
| i4g.large | 2 | 10 |
| i4g.xlarge | 3 | 20 |
| i4g.2xlarge | 3 | 40 |
| i4g.4xlarge | 7 | 60 |
| i4g.8xlarge | 7 | 60 |
| i4g.16xlarge | 14 | 120 |
| i4i.xlarge | 3 | 8 |
| i4i.2xlarge | 3 | 28 |
| i4i.4xlarge | 7 | 58 |
| i4i.8xlarge | 7 | 118 |
| i4i.12xlarge | 7 | 118 |
| i4i.16xlarge | 14 | 248 |
| i4i.24xlarge | 14 | 118 |
| i4i.32xlarge | 14 | 498 |
| i4i.metal | 14 | 498 |
| i7i.large | 2 | 10 |
| i7i.xlarge | 3 | 20 |
| i7i.2xlarge | 3 | 40 |
| i7i.4xlarge | 7 | 60 |
| i7i.8xlarge | 7 | 90 |
| i7i.12xlarge | 7 | 90 |
| i7i.16xlarge | 14 | 120 |
| i7i.24xlarge | 14 | 120 |
| i7i.48xlarge | 14 | 120 |
| i7i.metal-24xl | 14 | 120 |
| i7i.metal-48xl | 14 | 120 |
| i7ie.large | 2 | 20 |
| i7ie.xlarge | 3 | 29 |
| i7ie.2xlarge | 3 | 29 |
| i7ie.3xlarge | 3 | 29 |
| i7ie.6xlarge | 7 | 60 |
| i7ie.12xlarge | 7 | 60 |
| i7ie.18xlarge | 14 | 120 |
| i7ie.24xlarge | 14 | 120 |
| i7ie.48xlarge | 14 | 120 |
| i7ie.metal-24xl | 14 | 120 |
| i7ie.metal-48xl | 14 | 120 |
| i8g.large | 2 | 10 |
| i8g.xlarge | 3 | 20 |
| i8g.2xlarge | 3 | 40 |
| i8g.4xlarge | 7 | 60 |
| i8g.8xlarge | 7 | 60 |
| i8g.12xlarge | 7 | 60 |
| i8g.16xlarge | 14 | 120 |
| i8g.24xlarge | 14 | 120 |
| i8g.48xlarge | 14 | 120 |
| i8g.metal-24xl | 14 | 120 |
| i8g.metal-48xl | 14 | 120 |
| i8ge.large | 2 | 20 |
| i8ge.xlarge | 3 | 29 |
| i8ge.2xlarge | 3 | 29 |
| i8ge.3xlarge | 5 | 29 |
| i8ge.6xlarge | 9 | 60 |
| i8ge.12xlarge | 11 | 60 |
| i8ge.18xlarge | 15 | 120 |
| i8ge.24xlarge | 15 | 120 |
| i8ge.48xlarge | 23 | 120 |
| i8ge.metal-24xl | 15 | 120 |
| i8ge.metal-48xl | 23 | 120 |
| im4gn.large | 2 | 10 |
| im4gn.xlarge | 3 | 20 |
| im4gn.2xlarge | 3 | 40 |
| im4gn.4xlarge | 7 | 60 |
| im4gn.8xlarge | 7 | 60 |
| im4gn.16xlarge | 14 | 120 |
| is4gen.medium | 1 | 4 |
| is4gen.large | 2 | 10 |
| is4gen.xlarge | 3 | 20 |
| 4gn.2xlarge | 3 | 40 |
| is4gen.4xlarge | 7 | 60 |
| is4gen.8xlarge | 7 | 60 |
## 가속 컴퓨팅
| 인스턴스 유형 | ENI 트렁킹이 없는 작업 제한 | ENI 트렁킹을 포함하는 작업 제한 |
| --- | --- | --- |
| dl1.24xlarge | 59 | 120 |
| dl2q.24xlarge | 14 | 120 |
| f2.6xlarge | 7 | 90 |
| f2.12xlarge | 7 | 120 |
| f2.48xlarge | 14 | 120 |
| g4ad.xlarge | 1 | 12 |
| g4dn.2xlarge | 1 | 12 |
| g4ad.4xlarge | 2 | 12 |
| g4ad.8xlarge | 3 | 12 |
| g4ad.16xlarge | 7 | 12 |
| g5.xlarge | 3 | 6 |
| g5.2xlarge | 3 | 19 |
| g5.4xlarge | 7 | 40 |
| g5.8xlarge | 7 | 90 |
| g5.12xlarge | 14 | 120 |
| g5.16xlarge | 7 | 120 |
| g5.24xlarge | 14 | 120 |
| g5.48xlarge | 6 | 120 |
| g5g.xlarge | 3 | 20 |
| g5g.2xlarge | 3 | 40 |
| g5g.4xlarge | 7 | 60 |
| g5g.8xlarge | 7 | 60 |
| g5g.16xlarge | 14 | 120 |
| g5g.metal | 14 | 120 |
| g6.xlarge | 3 | 20 |
| g6.2xlarge | 3 | 40 |
| g6.4xlarge | 7 | 60 |
| g6.8xlarge | 7 | 90 |
| g6.12xlarge | 7 | 120 |
| g6.16xlarge | 14 | 120 |
| g6.24xlarge | 14 | 120 |
| g6.48xlarge | 14 | 120 |
| g6e.xlarge | 3 | 20 |
| g6e.2xlarge | 3 | 40 |
| g6e.4xlarge | 7 | 60 |
| g6e.8xlarge | 7 | 90 |
| g6e.12xlarge | 9 | 120 |
| g6e.16xlarge | 14 | 120 |
| g6e.24xlarge | 19 | 120 |
| g6e.48xlarge | 39 | 120 |
| g6f.large | 1 | 10 |
| g6f.xlarge | 3 | 20 |
| g6f.2xlarge | 3 | 40 |
| g6f.4xlarge | 7 | 60 |
| gr6.4xlarge | 7 | 60 |
| gr6.8xlarge | 7 | 90 |
| gr6f.4xlarge | 7 | 60 |
| g7e.2xlarge | 3 | 242 |
| g7e.4xlarge | 7 | 242 |
| g7e.8xlarge | 7 | 242 |
| g7e.12xlarge | 9 | 242 |
| g7e.24xlarge | 19 | 242 |
| g7e.48xlarge | 39 | 242 |
| inf2.xlarge | 3 | 20 |
| inf2.8xlarge | 7 | 90 |
| inf2.24xlarge | 14 | 120 |
| inf2.48xlarge | 14 | 120 |
| p4d.24xlarge | 59 | 120 |
| p4de.24xlarge | 59 | 120 |
| p5.4xlarge | 3 | 60 |
| p5.48xlarge | 63 | 242 |
| p5e.48xlarge | 63 | 242 |
| p5en.48xlarge | 63 | 242 |
| p6-b200.48xlarge | 31 | 242 |
| p6-b300.48xlarge | 67 | 242 |
| p6e-gb200.36xlarge | 38 | 120 |
| trn1.2xlarge | 3 | 19 |
| trn1.32xlarge | 39 | 120 |
| trn1n.32xlarge | 79 | 242 |
| trn2.3xlarge | 1 | 14 |
| trn2.48xlarge | 31 | 242 |
| trn2u.48xlarge | 31 | 242 |
| vt1.3xlarge | 3 | 40 |
| vt1.6xlarge | 7 | 60 |
| vt1.24xlarge | 14 | 120 |
## 고성능 컴퓨팅
| 인스턴스 유형 | ENI 트렁킹이 없는 작업 제한 | ENI 트렁킹을 포함하는 작업 제한 |
| --- | --- | --- |
| hpc6a.48xlarge | 1 | 120 |
| hpc6id.32xlarge | 1 | 120 |
| hpc7g.4xlarge | 3 | 120 |
| hpc7g.8xlarge | 3 | 120 |
| hpc7g.16xlarge | 3 | 120 |
| hpc8a.96xlarge | 3 | -2 |
# Amazon ECS Linux 컨테이너 인스턴스 메모리 예약
Amazon ECS 컨테이너 에이전트가 클러스터에 컨테이너 인스턴스를 등록할 때 에이전트는 컨테이너 인스턴스에서 태스크에 대해 예약할 수 있는 메모리 크기를 결정해야 합니다. 플랫폼 메모리 오버헤드와 운영 체제 커널이 차지하는 메모리로 인해 이 수치가 Amazon EC2 인스턴스에 대해 공급된 설치된 메모리 용량과 다르기 때문입니다 예를 들어, `m4.large` 인스턴스의 설치된 메모리는 8GiB입니다. 그러나 컨테이너 인스턴스 등록 시 항상 작업에 정확히 8,192MiB의 메모리를 사용할 수 있는 것은 아닙니다.
## ECS 관리형 인스턴스 메모리 리소스 결정
Amazon ECS 관리형 인스턴스는 계층적 접근 방식을 사용하여 태스크에 대한 메모리 리소스 요구 사항을 결정합니다. Docker의 메모리 내부 검사에 의존하는 EC2 기반 ECS와 달리 ECS 관리형 인스턴스는 예약 결정 중에 태스크 페이로드에서 직접 메모리 요구 사항을 계산합니다.
ECS 관리형 인스턴스 에이전트가 태스크를 수신하면 다음 우선순위에 따라 메모리 요구 사항을 계산합니다.
1. **태스크 수준 메모리(가장 높은 우선순위)** - 태스크 정의에 태스크 수준 메모리가 지정된 경우 에이전트는 이 값을 직접 사용합니다. 이는 모든 컨테이너 수준 메모리 설정보다 우선합니다.
1. **컨테이너 수준 메모리 합계(대체)** - 태스크 수준 메모리가 지정되지 않은 경우(또는 0인 경우) 에이전트는 태스크의 모든 컨테이너에서 메모리 요구 사항을 합산합니다. 각 컨테이너에 대해 다음을 사용합니다.
1. *메모리 예약(소프트 제한)* - 컨테이너가 구성에서 `memoryReservation`을 지정하는 경우 에이전트는 이 값을 사용합니다.
1. *컨테이너 메모리(하드 제한)* - `memoryReservation`이 지정되지 않은 경우 에이전트는 컨테이너의 `memory` 필드를 사용합니다.
**Example 지정된 태스크 수준 메모리**
태스크 수준 메모리를 지정하면 컨테이너 수준 설정보다 우선합니다.
```
{
"family": "my-task",
"memory": "2048",
"containerDefinitions": [
{
"name": "container1",
"memory": 1024,
"memoryReservation": 512
}
]
}
```
에이전트는 2,048MiB(태스크 수준 메모리가 우선함)를 예약합니다.
**Example 예약 기반 컨테이너 수준 메모리**
태스크 수준 메모리가 지정되지 않은 경우 에이전트는 컨테이너 메모리 요구 사항을 합산합니다.
```
{
"family": "my-task",
"containerDefinitions": [
{
"name": "container1",
"memory": 1024,
"memoryReservation": 512
},
{
"name": "container2",
"memory": 512
}
]
}
```
에이전트는 512MiB(container1 예약) \$1 512MiB(container2 메모리) = 총 1,024MiB를 예약합니다.
ECS 관리형 인스턴스 에이전트는 3단계로 메모리 계산을 수행합니다.
1. **태스크 수신** - ECS 컨트롤 플레인에서 태스크 페이로드가 도착하면 에이전트는 즉시 필요한 메모리를 계산합니다.
1. **리소스 스토리지** - 계산된 메모리 요구 사항은 나중에 리소스 회계 작업에 사용할 수 있도록 태스크 모델에 저장됩니다.
1. **일정 결정** - 태스크를 수락하기 전에 에이전트는 충분한 메모리를 사용할 수 있는지 확인합니다. 메모리가 부족하면 태스크가 거부되고 리소스를 사용할 수 있을 때까지 ECS 서비스 대기열에 남아 있습니다.
**참고**
EC2 기반 ECS와 달리 ECS 관리형 인스턴스는 `ECS_RESERVED_MEMORY` 구성 변수를 사용하지 않습니다. 시스템 프로세스에 대한 메모리 예약은 기본 플랫폼의 리소스 관리를 통해 처리되며 에이전트는 태스크 정의를 기반으로 정확한 리소스 회계를 수행합니다.
EC2 기반 ECS에서 Amazon ECS 컨테이너 에이전트는 `ECS_RESERVED_MEMORY`라는 구성 변수를 제공합니다. 이를 사용하여 작업에 할당된 풀에서 지정된 메모리 크기(MiB)를 제거할 수 있습니다. 이를 통해 중요 시스템 프로세스에 대한 메모리를 효율적으로 예약합니다.
컨테이너 인스턴스의 모든 메모리를 작업에 사용하는 경우 작업 및 메모리의 중요 시스템 프로세스 경합으로 인해 시스템 오류가 발생할 수 있습니다.
예를 들어, 컨테이너 에이전트 구성 파일에서 `ECS_RESERVED_MEMORY=256`을 지정한 경우 에이전트는 인스턴스에 대해 총 메모리에서 256MiB를 제외하고 등록하며, 이 256MiB의 메모리는 ECS 작업에 할당될 수 없습니다. 에이전트 구성 변수 및 이를 설정하는 방법에 대한 자세한 정보는 [Amazon ECS 컨테이너 에이전트 구성](ecs-agent-config.md) 및 [데이터 전달을 위한 Amazon ECS Linux 컨테이너 인스턴스 부트스트래핑](bootstrap_container_instance.md) 섹션을 참조하세요.
작업에 대해 8,192MiB를 지정하고, 이 요구 사항을 충족하기 위해 8,192MiB 이상의 메모리를 사용할 수 있는 컨테이너 인스턴스가 없는 경우 작업은 클러스터에 배치될 수 없습니다. 관리형 컴퓨팅 환경을 사용 중인 경우 AWS Batch는 요청을 수용하기 위해 더 큰 인스턴스 유형을 시작해야 합니다.
Amazon ECS 컨테이너 에이전트는 Docker `ReadMemInfo()` 함수를 사용하여 운영 체제가 사용할 수 있는 전체 메모리를 쿼리합니다. Linux 및 Windows 모두 명령줄 유틸리티를 제공하여 총 메모리를 결정합니다.
**Example - Linux 총 메모리 결정**
**free** 명령은 운영 체제가 인식한 총 메모리를 반환합니다.
```
$ free -b
```
Amazon ECS 최적화된 Amazon Linux AMI를 실행하는 `m4.large` 인스턴스의 출력 예.
```
total used free shared buffers cached
Mem: 8373026816 348180480 8024846336 90112 25534464 205418496
-/+ buffers/cache: 117227520 8255799296
```
이 인스턴스의 총 메모리는 8,373,026,816바이트로, 이는 태스크에 대해 7,985MiB를 사용할 수 있음을 의미합니다.
**Example - Windows 총 메모리 결정**
**wmic** 명령은 운영 체제가 인식한 총 메모리를 반환합니다.
```
C:\> wmic ComputerSystem get TotalPhysicalMemory
```
Amazon ECS 최적화 Windows Server AMI를 실행하는 `m4.large` 인스턴스의 출력 예제.
```
TotalPhysicalMemory
8589524992
```
이 인스턴스의 총 메모리는 8,589,524,992바이트로, 이는 작업에 대해 8,191MiB를 사용할 수 있음을 의미합니다.
## 컨테이너 인스턴스 메모리 보기
컨테이너 인스턴스가 Amazon ECS 콘솔(또는 [DescribeContainerInstances](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeContainerInstances.html) API 작업)에 등록하는 메모리 크기를 확인할 수 있습니다. 특정 인스턴스 유형에 대해 가능한 한 많은 메모리를 작업에 제공하여 리소스 사용률을 극대화하려는 경우 해당 컨테이너 인스턴스에 사용 가능한 메모리를 관찰한 다음, 작업에 그만큼의 메모리를 할당할 수 있습니다.
**컨테이너 인스턴스 메모리를 보는 방법**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 창에서 **클러스터**를 선택하고 컨테이너 인스턴스를 호스팅하는 클러스터를 선택합니다.
1. **인프라**를 선택한 다음, 컨테이너 인스턴스에서 컨테이너 인스턴스를 선택합니다.
1. **리소스** 섹션에서는 컨테이너 인스턴스에 대해 등록된 메모리와 사용 가능한 메모리를 보여줍니다.
**등록됨** 메모리 값은 처음 시작할 때 Amazon ECS에 등록된 컨테이너 인스턴스의 값이며, **사용 가능** 메모리 값은 작업에 할당되지 않은 값입니다.
# AWS Systems Manager를 사용한 원격으로 Amazon ECS 컨테이너 인스턴스 관리
AWS Systems Manager(Systems Manager)의 Run Command 기능을 사용하면 Amazon ECS 컨테이너 인스턴스의 구성을 원격으로 안전하게 관리할 수 있습니다. Run Command를 사용하면 인스턴스에 로컬로 로그인하지 않고 간단하게 일반적인 관리 태스크를 수행할 수 있습니다. 여러 컨테이너 인스턴스에서 동시에 명령을 실행하여 클러스터의 구성 변경을 전체적으로 관리할 수 있습니다. Run Command는 각 명령의 상태와 결과를 보고합니다.
다음은 Run Command를 사용하여 수행할 수 있는 태스크 유형의 몇 가지 예입니다.
+ 패키지 설치 또는 제거.
+ 보안 업데이트 수행.
+ Docker 이미지 정리.
+ 서비스 중지 또는 시작.
+ 시스템 리소스 보기.
+ 로그 파일 보기.
+ 파일 작업 수행.
Run Command에 대한 자세한 정보는 *AWS Systems Manager 사용 설명서*의 [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)를 참조하세요.
다음은 Amazon ECS에서 Systems Manager를 사용하기 위한 사전 조건입니다.
1. Systems Manager API에 액세스하려면 컨테이너 인스턴스 역할(**ecsInstanceRole**)에 권한을 부여해야 합니다. **AmazonSSMManagedInstanceCore**를 `ecsInstanceRole` 역할에 할당하면 됩니다. 역할에 정책을 연결하는 방법에 대한 자세한 내용은 *AWS Identity and Access Management 사용 설명서*의 [역할 권한 업데이트](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html)를 참조하세요.
1. 컨테이너 인스턴스에 SSM Agent가 설치되었는지 확인합니다. 자세한 정보는 [Linux용 EC2 인스턴스에 수동으로 SSM Agent 설치 및 제거](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)를 참조하세요.
Systems Manager 관리형 정책을 AWS Systems Manager에 연결하고 `ecsInstanceRole` 에이전트(SSM Agent)가 컨테이너 인스턴스에 설치되어 있는지 확인한 후 Run Command를 사용하여 컨테이너 인스턴스로 명령 전송을 시작할 수 있습니다. 인스턴스에서 명령 및 shell 스크립트를 실행하고 결과 출력을 보는 방법에 대한 자세한 정보는 *AWS Systems Manager 사용 설명서*의 [Systems Manager Run Command를 사용하여 명령 실행](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) 및 [Run Command 연습](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command-walkthroughs.html)을 참조하세요.
일반적인 사용 사례는 실행 명령으로 컨테이너 인스턴스 소프트웨어를 업데이트하는 것입니다. 다음 파라미터를 사용하여 AWS Systems Manager 사용 설명서의 절차를 따를 수 있습니다.
| 파라미터 | 값 |
| --- | --- |
| **명령 문서** | AWS-RunShellScript |
| 명령 | $ yum update -y
|
| 대상 인스턴스 | 사용자의 컨테이너 인스턴스 |
# Amazon ECS Linux 컨테이너 인스턴스에 HTTP 프록시 사용
Amazon ECS 컨테이너 에이전트와 Docker 대몬 모두에 대해 HTTP 프록시를 사용하도록 Amazon ECS 컨테이너 인스턴스를 구성할 수 있습니다. 이 구성은 컨테이너 인스턴스가 Amazon VPC 인터넷 게이트웨이, NAT 게이트웨이 또는 인스턴스를 통해 외부 네트워크에 액세스하지 못할 경우 유용합니다.
HTTP 프록시를 사용하도록 Amazon ECS Linux 컨테이너 인스턴스를 구성하려면 시작 시(Amazon EC2 사용자 데이터를 사용해) 관련 파일에 있는 다음 변수를 설정합니다. 구성 파일을 수동으로 편집한 다음 에이전트를 재시작할 수도 있습니다.
`/etc/ecs/ecs.config`(Amazon Linux 2 및 Amazon Linux AMI)
`HTTP_PROXY=10.0.0.131:3128`
Amazon ECS 에이전트가 인터넷에 연결하는 데 사용할 HTTP 프록시의 호스트 이름(또는 IP 주소) 및 포트 번호로 이 값을 설정합니다. 예를 들어 컨테이너 인스턴스는 Amazon VPC 인터넷 게이트웨이, NAT 게이트웨이 또는 인스턴스를 통해 외부 네트워크에 액세스하지 못할 수 있습니다.
`NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`
EC2 인스턴스 메타데이터, 작업에 대한 IAM 역할 및 프록시로부터의 Docker 대몬 트래픽을 필터링하려면 이 값을 `169.254.169.254,169.254.170.2,/var/run/docker.sock`으로 설정합니다.
`/etc/systemd/system/ecs.service.d/http-proxy.conf`(Amazon Linux 2 전용)
`Environment="HTTP_PROXY=10.0.0.131:3128/"`
`ecs-init`가 인터넷에 연결하는 데 사용할 HTTP 프록시의 호스트 이름(또는 IP 주소) 및 포트 번호로 이 값을 설정합니다. 예를 들어 컨테이너 인스턴스는 Amazon VPC 인터넷 게이트웨이, NAT 게이트웨이 또는 인스턴스를 통해 외부 네트워크에 액세스하지 못할 수 있습니다.
`Environment="NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock"`
EC2 인스턴스 메타데이터, 작업에 대한 IAM 역할 및 프록시로부터의 Docker 대몬 트래픽을 필터링하려면 이 값을 `169.254.169.254,169.254.170.2,/var/run/docker.sock`으로 설정합니다.
`/etc/init/ecs.override` (Amazon Linux AMI만 해당)
`env HTTP_PROXY=10.0.0.131:3128`
`ecs-init`가 인터넷에 연결하는 데 사용할 HTTP 프록시의 호스트 이름(또는 IP 주소) 및 포트 번호로 이 값을 설정합니다. 예를 들어 컨테이너 인스턴스는 Amazon VPC 인터넷 게이트웨이, NAT 게이트웨이 또는 인스턴스를 통해 외부 네트워크에 액세스하지 못할 수 있습니다.
`env NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`
EC2 인스턴스 메타데이터, 작업에 대한 IAM 역할 및 프록시로부터의 Docker 대몬 트래픽을 필터링하려면 이 값을 `169.254.169.254,169.254.170.2,/var/run/docker.sock`으로 설정합니다.
`/etc/systemd/system/docker.service.d/http-proxy.conf`(Amazon Linux 2 전용)
`Environment="HTTP_PROXY=http://10.0.0.131:3128"`
Docker 대몬이 인터넷에 연결하는 데 사용할 HTTP 프록시의 호스트 이름(또는 IP 주소) 및 포트 번호로 이 값을 설정합니다. 예를 들어 컨테이너 인스턴스는 Amazon VPC 인터넷 게이트웨이, NAT 게이트웨이 또는 인스턴스를 통해 외부 네트워크에 액세스하지 못할 수 있습니다.
`Environment="NO_PROXY=169.254.169.254,169.254.170.2"`
프록시에서 EC2 인스턴스 메타데이터를 필터링하려면 이 값을 `169.254.169.254,169.254.170.2`로 설정합니다.
`/etc/sysconfig/docker` (Amazon Linux AMI 및 Amazon Linux 2 전용)
`export HTTP_PROXY=http://10.0.0.131:3128`
Docker 대몬이 인터넷에 연결하는 데 사용할 HTTP 프록시의 호스트 이름(또는 IP 주소) 및 포트 번호로 이 값을 설정합니다. 예를 들어 컨테이너 인스턴스는 Amazon VPC 인터넷 게이트웨이, NAT 게이트웨이 또는 인스턴스를 통해 외부 네트워크에 액세스하지 못할 수 있습니다.
`export NO_PROXY=169.254.169.254,169.254.170.2`
프록시에서 EC2 인스턴스 메타데이터를 필터링하려면 이 값을 `169.254.169.254,169.254.170.2`로 설정합니다.
이 환경 변수를 위 파일에서 설정하면 Amazon ECS 컨테이너 에이전트, `ecs-init` 및 Docker 대몬에만 영향을 미칩니다. 기타 서비스(예: **yum**)에서는 프록시를 사용하도록 구성하지 않습니다.
프록시를 구성하는 방법에 대한 자세한 내용은 [Amazon Linux 2 또는 Amazon Linux 2023에서 Docker 및 Amazon ECS 컨테이너 에이전트의 HTTP 프록시를 설정하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/ecs-http-proxy-docker-linux2)를 참조하세요.
# Amazon ECS Auto Scaling 그룹에 대해 사전 초기화된 인스턴스 구성
Amazon ECS에서 Amazon EC2 Auto Scaling 웜 풀을 지원합니다. 웜 풀은 서비스에 배치할 준비가 되어 사전 초기화된 Amazon EC2 인스턴스의 그룹입니다. 애플리케이션을 확장해야 할 때마다 Amazon EC2 Auto Scaling은 콜드 인스턴스를 시작하는 대신 웜 풀에서 미리 초기화된 인스턴스를 사용하고 모든 최종 초기화 프로세스가 실행되도록 허용한 다음 인스턴스를 서비스에 배치합니다.
웜 풀 및 Auto Scaling에 웜 풀을 추가하는 방법에 대한 자세한 정보는 *Amazon EC2 Auto Scaling 사용 설명서*의 [Amazon EC2 Auto Scaling의 웜 풀](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html)을 참조하세요.
Amazon ECS의 Auto Scaling 그룹에 대한 웜 풀을 생성하거나 업데이트할 경우, 스케일 인에서 웜 풀로 인스턴스를 반환하는 옵션을 설정할 수 없습니다(`ReuseOnScaleIn`). 자세한 내용은 *AWS Command Line Interface 참조*의 [put-warm-pool](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-warm-pool.html)을 참조하세요.
Amazon ECS 클러스터에서 웜 풀을 사용하려면 Amazon EC2 Auto Scaling 그룹 시작 템플릿의 **사용자 데이터(User data)** 필드에서 `ECS_WARM_POOLS_CHECK` 에이전트 구성 변수를 `true`로 설정합니다.
다음은 Amazon EC2 시작 템플릿의 **사용자 데이터(User data)** 필드에 에이전트 구성 변수를 지정하는 방법의 예를 보여줍니다. *MyCluster*를 사용자의 클러스터 이름으로 바꿉니다.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_WARM_POOLS_CHECK=true
EOF
```
`ECS_WARM_POOLS_CHECK` 변수는 에이전트 버전 `1.59.0` 이상에서만 지원됩니다. 변수에 대한 자세한 정보는 [Amazon ECS 컨테이너 에이전트 구성](ecs-agent-config.md)을 참조하세요.
# Amazon ECS 컨테이너 에이전트 업데이트
때때로 버그 수정 및 새로운 기능을 적용하기 위해 Amazon ECS 컨테이너 에이전트를 업데이트해야 할 수도 있습니다. Amazon ECS 컨테이너 에이전트를 업데이트할 때 컨테이너 인스턴스의 실행 작업 또는 서비스가 중단되지 않습니다. 에이전트 업데이트 절차는 컨테이너 인스턴스가 Amazon ECS 최적화 AMI 또는 기타 운영 체제에서 시작되었는지에 따라 다릅니다.
**참고**
에이전트 업데이트는 Windows 컨테이너 인스턴스에 적용되지 않습니다. 새로운 컨테이너 인스턴스를 시작하여 Windows 클러스터의 에이전트 버전을 업데이트하는 것을 권장합니다.
## Amazon ECS 컨테이너 에이전트 버전 확인
컨테이너 인스턴스에서 실행 중인 컨테이너 에이전트의 버전을 확인하고 업데이트가 필요한지 판단할 수 있습니다. Amazon ECS 콘솔의 컨테이너 인스턴스 보기에 에이전트 버전이 표시됩니다. 에이전트 버전을 확인하려면 다음 절차를 사용합니다.
------
#### [ Amazon ECS console ]
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 모음에서 외부 인스턴스가 등록되어 있는 리전을 선택합니다.
1. 탐색 창에서 **클러스터**를 선택하고 외부 인스턴스를 호스팅하는 클러스터를 선택합니다.
1. **클러스터: *name*(Cluster : name)** 페이지에서 **인프라(Infrastructure)** 탭을 선택합니다.
1. **컨테이너 인스턴스(Container instances)**에서 컨테이너 인스턴스의 **에이전트 버전(Agent version)** 열을 확인합니다. 컨테이너 인스턴스에 최신 컨테이너 에이전트 버전이 포함되어 있지 않으면 콘솔이 메시지를 통해 경고하고 이전 에이전트 버전에 플래그를 지정합니다.
에이전트 버전이 오래된 경우 다음 절차를 사용하여 컨테이너 에이전트를 업데이트할 수 있습니다.
+ 컨테이너 인스턴스가 Amazon ECS 최적화 AMI를 실행할 경우 [Amazon ECS 최적화 AMI에서 Amazon ECS 컨테이너 에이전트 업데이트](agent-update-ecs-ami.md)를 참조하세요.
+ 컨테이너 인스턴스가 Amazon ECS 최적화 AMI를 실행하지 않을 경우 [Amazon ECS 컨테이너 에이전트를 수동으로 업데이트하는 방법(비 Amazon ECS 최적화 AMI)](manually_update_agent.md)를 참조하세요.
**중요**
Amazon ECS 최적화 AMI에서 v1.0.0 이전의 Amazon ECS 에이전트 버전을 업데이트하려면 현재 컨테이너 인스턴스를 종료하고 최신 AMI 버전을 사용하여 새 인스턴스를 시작하는 것이 좋습니다. 미리 보기 버전을 사용하는 컨테이너 인스턴스는 종료하고 최신 AMI로 대체해야 합니다. 자세한 정보는 [Amazon ECS Linux 컨테이너 인스턴스 시작](launch_container_instance.md)을 참조하세요.
------
#### [ Amazon ECS container agent introspection API ]
컨테이너 인스턴스 자체에서 에이전트 Amazon ECS 컨테이너 에이전트 내부 검사 API 버전을 확인하는 데 이를 사용할 수도 있습니다. 자세한 정보는 [Amazon ECS 컨테이너 내부 검사](ecs-agent-introspection.md)을 참조하세요.
**내부 검사 API를 사용하여 Amazon ECS 컨테이너 에이전트가 최신 버전을 실행 중인지 확인하는 방법**
1. SSH를 통해 컨테이너 인스턴스에 로그인합니다.
1. 내부 검사 API를 쿼리합니다.
```
[ec2-user ~]$ curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
```
**참고**
내부 검사 API는 Amazon ECS 컨테이너 에이전트의 버전 v1.0.0에서 `Version` 정보를 추가했습니다. 내부 검사 API를 쿼리했을 때 `Version`이 없는 경우, 또는 에이전트에 내부 검사 API 자체가 없는 경우 실행되는 버전은 v0.0.3 이하입니다. 버전을 업데이트해야 합니다.
------
# Amazon ECS 최적화 AMI에서 Amazon ECS 컨테이너 에이전트 업데이트
Amazon ECS 최적화 AMI를 사용하는 경우, 최신 버전의 Amazon ECS 컨테이너 에이전트를 얻을 수 있는 옵션은 다음과 같이 여러 가지가 있습니다(권장 순서로 표시).
+ 컨테이너 인스턴스를 종료하고 (수동으로 또는 Auto Scaling 시작 구성을 최신 AMI로 업데이트하여) 최신 버전의 Amazon ECS 최적화 Amazon Linux 2 AMI를 시작합니다. 그러면 테스트 및 검증된 최신 버전의 Amazon Linux, Docker, `ecs-init` 및 Amazon ECS 컨테이너 에이전트를 포함하는 컨테이너 인스턴스가 새로 시작됩니다. 자세한 정보는 [Amazon ECS 최적화 Linux AMI](ecs-optimized_AMI.md)을 참조하세요.
+ SSH를 사용하여 인스턴스에 연결하고 `ecs-init` 패키지(및 해당 종속성)를 최신 버전으로 업데이트합니다. 이 작업은 Amazon Linux 리포지토리에서 사용 가능한 테스트 및 검증된 최신 버전의 도커 및 `ecs-init`와 최신 버전의 Amazon ECS 컨테이너 에이전트를 제공합니다. 자세한 정보는 [Amazon ECS 최적화 AMI에서 `ecs-init` 패키지를 업데이트하는 방법](#procedure_update_ecs-init)을 참조하세요.
+ 콘솔을 통해 또는 AWS CLI 또는 AWS SDK를 사용해 `UpdateContainerAgent` API 작업으로 컨테이너를 업데이트합니다. 자세한 정보는 [`UpdateContainerAgent` API 태스크를 사용하여 Amazon ECS 컨테이너 에이전트 업데이트](#agent-update-api)을 참조하세요.
**참고**
에이전트 업데이트는 Windows 컨테이너 인스턴스에 적용되지 않습니다. 새로운 컨테이너 인스턴스를 시작하여 Windows 클러스터의 에이전트 버전을 업데이트하는 것을 권장합니다.
**Amazon ECS 최적화 AMI에서 `ecs-init` 패키지를 업데이트하는 방법**
1. SSH를 통해 컨테이너 인스턴스에 로그인합니다.
1. 다음 명령을 사용하여 `ecs-init` 패키지를 업데이트합니다.
```
sudo yum update -y ecs-init
```
**참고**
`ecs-init` 패키지와 Amazon ECS 컨테이너 에이전트가 즉시 업데이트됩니다. 그러나 새 버전의 Docker는 Docker 대몬이 다시 시작되기 전에는 로드되지 않습니다. 인스턴스를 재부팅하거나 인스턴스에서 다음 명령을 실행하여 다시 시작하세요.
Amazon ECS 최적화 Amazon Linux 2 AMI:
```
sudo systemctl restart docker
```
Amazon ECS 최적화 Amazon Linux AMI:
```
sudo service docker restart && sudo start ecs
```
## `UpdateContainerAgent` API 태스크를 사용하여 Amazon ECS 컨테이너 에이전트 업데이트
**중요**
`UpdateContainerAgent` API는 Amazon ECS 최적화 AMI의 Linux 변형에서만 지원됩니다. 단, Amazon ECS 최적화 Amazon Linux 2(arm64) AMI만 예외입니다. Amazon ECS 최적화 Amazon Linux 2(arm64) AMI를 사용하는 컨테이너 인스턴스의 경우, `ecs-init` 패키지를 업데이트하여 에이전트를 업데이트하세요. 다른 운영 체제를 실행하는 컨테이너 인스턴스의 경우 [Amazon ECS 컨테이너 에이전트를 수동으로 업데이트하는 방법(비 Amazon ECS 최적화 AMI)](manually_update_agent.md) 섹션을 참조하세요. Windows 컨테이너 인스턴스를 사용하고 있을 경우 새로운 컨테이너 인스턴스를 시작하여 Windows 클러스터의 에이전트 버전을 업데이트하는 것을 권장합니다.
`UpdateContainerAgent` API 프로세스는 콘솔 또는 AWS CLI나 AWS SDK를 통해 에이전트 업데이트를 요청하면 시작됩니다. Amazon ECS는 현재 에이전트 버전을 사용 가능한 최신 에이전트 버전과 비교하여 업데이트가 가능한지 확인합니다. 업데이트가 가능하지 않으면(예: 이미 최신 버전이 실행 중) `NoUpdateAvailableException`이 반환됩니다.
위에 표시된 업데이트 프로세스의 단계는 다음과 같습니다.
`PENDING`
에이전트 업데이트가 가능하고, 업데이트 프로세스가 시작되었습니다.
`STAGING`
에이전트가 에이전트 업데이트를 다운로드하기 시작했습니다. 에이전트가 업데이트를 다운로드할 수 없는 경우 또는 업데이트의 내용이 부정확하거나 손상된 경우 에이전트가 실패 알림을 전송하고 업데이트가 `FAILED` 상태로 전환됩니다.
`STAGED`
에이전트 다운로드가 완료되었으며 에이전트 내용이 확인되었습니다.
`UPDATING`
`ecs-init` 서비스가 다시 시작되어 새 에이전트 버전을 선택합니다. 어떤 이유로 에이전트를 다시 시작할 수 없는 경우 업데이트가 `FAILED` 상태로 전환되고, 그렇지 않으면 에이전트가 Amazon ECS에게 업데이트 완료 신호를 보냅니다.
**참고**
에이전트 업데이트는 Windows 컨테이너 인스턴스에 적용되지 않습니다. 새로운 컨테이너 인스턴스를 시작하여 Windows 클러스터의 에이전트 버전을 업데이트하는 것을 권장합니다.
**콘솔에서 Amazon ECS 최적화 AMI에서 Amazon ECS 컨테이너 에이전트를 업데이트하는 방법**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 모음에서 외부 인스턴스가 등록되어 있는 리전을 선택합니다.
1. 탐색 창에서 **클러스터**를 선택하고 클러스터를 선택합니다.
1. **클러스터: *name*(Cluster : name)** 페이지에서 **인프라(Infrastructure)** 탭을 선택합니다.
1. **컨테이너 인스턴스**에서 업데이트할 인스턴스를 선택하고 **작업**, **에이전트 업데이트**를 선택합니다.
# Amazon ECS 컨테이너 에이전트를 수동으로 업데이트하는 방법(비 Amazon ECS 최적화 AMI)
때때로 버그 수정 및 새로운 기능을 적용하기 위해 Amazon ECS 컨테이너 에이전트를 업데이트해야 할 수도 있습니다. Amazon ECS 컨테이너 에이전트를 업데이트할 때 컨테이너 인스턴스의 실행 작업 또는 서비스가 중단되지 않습니다.
**참고**
에이전트 업데이트는 Windows 컨테이너 인스턴스에 적용되지 않습니다. 새로운 컨테이너 인스턴스를 시작하여 Windows 클러스터의 에이전트 버전을 업데이트하는 것을 권장합니다.
1. SSH를 통해 컨테이너 인스턴스에 로그인합니다.
1. 에이전트가 `ECS_DATADIR` 환경 변수를 사용하여 해당 상태를 저장하는지 확인합니다.
```
ubuntu:~$ docker inspect ecs-agent | grep ECS_DATADIR
```
출력:
```
"ECS_DATADIR=/data",
```
**중요**
이전 명령이 `ECS_DATADIR` 환경 변수를 반환하지 않으면 에이전트를 업데이트하기 전에 이 컨테이너 인스턴스에서 실행 중인 태스크를 모두 중지해야 합니다. `ECS_DATADIR` 환경 변수를 사용하는 새 버전의 에이전트는 해당 상태를 저장하며 태스크가 실행되는 동안 에이전트를 업데이트해도 문제가 발생하지 않습니다.
1. Amazon ECS 컨테이너 에이전트를 중지합니다.
```
ubuntu:~$ docker stop ecs-agent
```
1. 에이전트 컨테이너를 삭제합니다.
```
ubuntu:~$ docker rm ecs-agent
```
1. `/etc/ecs` 디렉터리와 Amazon ECS 컨테이너 에이전트 구성 파일이 `/etc/ecs/ecs.config`에 있는지 확인합니다.
```
ubuntu:~$ sudo mkdir -p /etc/ecs && sudo touch /etc/ecs/ecs.config
```
1. `/etc/ecs/ecs.config` 파일을 편집하고 이 파일에 최소한 다음과 같은 변수 선언이 포함되어 있는지 확인합니다. 컨테이너 인스턴스가 기본 클러스터에 등록되지 않도록 하려면 클러스터 이름을 `ECS_CLUSTER`의 값으로 지정합니다.
```
ECS_DATADIR=/data
ECS_ENABLE_TASK_IAM_ROLE=true
ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true
ECS_LOGFILE=/log/ecs-agent.log
ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"]
ECS_LOGLEVEL=info
ECS_CLUSTER=default
```
이들을 비롯한 기타 에이전트 런타임 옵션에 대한 자세한 내용은 [Amazon ECS 컨테이너 에이전트 구성](ecs-agent-config.md) 섹션을 참조하세요.
**참고**
필요할 경우 (시작 시 Amazon EC2 사용자 데이터를 사용하여 컨테이너 인스턴스에 다운로드할 수 있는) Amazon S3에 에이전트 환경 변수를 저장할 수 있습니다. 프라이빗 리포지토리의 인증 자격 증명과 같은 민감한 정보에는 이 방법을 권장합니다. 자세한 내용은 [Amazon S3에 Amazon ECS 컨테이너 인스턴스 구성 저장](ecs-config-s3.md) 및 [Amazon ECS에서 AWS 컨테이너가 아닌 이미지 사용](private-auth.md) 섹션을 참조하세요.
1. Amazon Elastic Container Registry Public에서 최신 Amazon ECS 컨테이너 에이전트 이미지를 가져옵니다.
```
ubuntu:~$ docker pull public.ecr.aws/ecs/amazon-ecs-agent:latest
```
출력:
```
Pulling repository amazon/amazon-ecs-agent
a5a56a5e13dc: Download complete
511136ea3c5a: Download complete
9950b5d678a1: Download complete
c48ddcf21b63: Download complete
Status: Image is up to date for amazon/amazon-ecs-agent:latest
```
1. 컨테이너 인스턴스에서 최신 Amazon ECS 컨테이너 에이전트를 실행합니다.
**참고**
Docker 재시작 정책 또는 프로세스 관리자(예: **upstart** 또는 **systemd**)를 사용하여 컨테이너 에이전트를 서비스 또는 대몬으로 취급하고 종료 후에 다시 시작되도록 합니다. 이를 위해 Amazon ECS 최적화 AMI는 `ecs-init` RPM을 사용합니다. GitHub에서 [이 RPM의 소스 코드](https://github.com/aws/amazon-ecs-init)를 확인할 수 있습니다.
다음의 에이전트 실행 명령 예제는 각 옵션을 표시하기 위해 여러 줄로 구분되어 있습니다. 이들을 비롯한 기타 에이전트 런타임 옵션에 대한 자세한 내용은 [Amazon ECS 컨테이너 에이전트 구성](ecs-agent-config.md) 섹션을 참조하세요.
**중요**
운영 체제에서 SELinux를 사용하는 경우 **docker run** 명령에 `--privileged` 옵션이 필요합니다. 또한 SELinux 사용 컨테이너 인스턴스의 경우에는 `:Z` 옵션을 `/log` 및 `/data` 볼륨 마운트에 추가하는 것이 좋습니다. 그러나 명령을 실행하기 전에 이러한 볼륨에 대한 호스트 마운트가 존재해야 하며 그렇지 않으면 `no such file or directory` 오류가 발생합니다. SELinux 사용 컨테이너 인스턴스에서 Amazon ECS 에이전트를 실행하는 데 문제가 있는 경우 다음 조치를 취하세요.
컨테이너 인스턴스에서 호스트 볼륨 마운트 지점을 생성합니다.
```
ubuntu:~$ sudo mkdir -p /var/log/ecs /var/lib/ecs/data
```
아래의 **docker run** 명령에 `--privileged` 옵션을 추가합니다.
아래의 **docker run** 명령에 대한 `/log` 및 `/data` 컨테이너 볼륨 마운트(예: `--volume=/var/log/ecs/:/log:Z`)에 `:Z` 옵션을 추가합니다.
```
ubuntu:~$ sudo docker run --name ecs-agent \
--detach=true \
--restart=on-failure:10 \
--volume=/var/run:/var/run \
--volume=/var/log/ecs/:/log \
--volume=/var/lib/ecs/data:/data \
--volume=/etc/ecs:/etc/ecs \
--volume=/etc/ecs:/etc/ecs/pki \
--net=host \
--env-file=/etc/ecs/ecs.config \
amazon/amazon-ecs-agent:latest
```
**참고**
`Error response from daemon: Cannot start container` 메시지가 표시되는 경우 **sudo docker rm ecs-agent** 명령을 사용하여 실패한 컨테이너를 삭제하고 에이전트를 다시 실행해볼 수 있습니다.
# Amazon ECS 최적화 Windows AMI
Amazon ECS 최적화 AMI는 Amazon ECS 워크로드를 실행하는 데 필요한 필수 구성 요소로 사전 구성됩니다. Amazon ECS에서 컨테이너화된 워크로드를 실행하는 데 필요한 기본 사양을 충족하도록 자체 컨테이너 인스턴스 AMI를 만들 수도 있지만 Amazon ECS 최적화 AMI는 AWS 엔지니어들에 의해 Amazon ECS에서 사전 구성 및 테스트됩니다. AWS에서 신속하게 시작하고 컨테이너를 실행할 수 있는 가장 간단한 방법입니다.
각 변형에 대한 AMI 이름, Amazon ECS 컨테이너 에이전트 버전 및 Docker 버전이 포함된 Amazon ECS 런타임 버전을 포함한 Amazon ECS 최적화 AMI 메타데이터는 프로그래밍 방식으로 검색할 수 있습니다. 자세한 내용은 [Amazon ECS 최적화 Windows AMI 메타데이터 검색](retrieve-ecs-optimized_windows_AMI.md) 섹션을 참조하세요.
**중요**
2022년 8월 이후에 출시된 모든 ECS 최적화 AMI 버전은 Docker EE(Mirantis)에서 Docker CE(Moby 프로젝트)로 마이그레이션됩니다.
고객들이 항상 최신 보안 업데이트를 갖출 수 있도록 하기 위해 Amazon ECS는 최소 세 개의 Windows Amazon ECS 최적화 AMI를 유지합니다. 새로운 Windows Amazon ECS 최적화 AMI를 출시한 후, Amazon ECS는 이전 프라이빗인 Windows Amazon ECS 최적화 AMI를 만듭니다. 액세스해야 하는 프라이빗 AMI가 있는 경우 Cloud Support를 통해 티켓을 제출하여 알려주세요.
## Amazon ECS 최적화 AMI 변형
Amazon EC2 인스턴스에 사용할 수 있는 Amazon ECS 최적화 AMI의 Windows Server 변형은 다음과 같습니다.
**중요**
8월 이후에 출시된 모든 ECS 최적화 AMI 버전은 Docker EE(Mirantis)에서 Docker CE(Moby 프로젝트)로 마이그레이션됩니다.
+ **Amazon ECS 최적화 Windows Server 2025 Full AMI**
+ **Amazon ECS 최적화 Windows Server 2025 Core AMI**
+ **Amazon ECS 최적화 Windows Server 2022 Full AMI**
+ **Amazon ECS 최적화 Windows Server 2022 Core AMI**
+ **Amazon ECS 최적화 Windows Server 2019 Full AMI**
+ **Amazon ECS 최적화 Windows Server 2019 Core AMI**
+ **Amazon ECS 최적화 Windows Server 2016 Full AMI**
**중요**
Windows Server 2016은 최신 Docker 버전(예: 25.x.x)을 지원하지 않습니다. 따라서 Windows Server 2016 Full AMI는 Docker 런타임에 대한 보안 또는 버그 패치를 수신하지 않습니다. 다음 Windows 플랫폼 중 하나를 사용하여 이전하는 것이 좋습니다.
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core
2022년 8월 9일에 Amazon ECS 최적화 Windows Server 20H2 Core AMI가 지원 종료 날짜에 도달했습니다. 이 AMI의 새 버전은 릴리스되지 않습니다. 자세한 정보는 [Windows Server 릴리스 정보](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info)를 참조하세요.
Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016은 장기 서비스 채널(LTSC) 릴리스입니다. Windows Server 20H2는 반기 채널(SAC) 릴리스입니다. 자세한 정보는 [Windows Server 릴리스 정보](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info)를 참조하세요.
### 고려 사항
다음은 Amazon EC2 Windows 컨테이너와 Amazon ECS에 관해 알아 두어야 할 몇 가지 사항입니다.
+ Windows 컨테이너는 Linux 컨테이너 인스턴스에서 실행할 수 없으며 그 반대도 그렇습니다. Windows 및 Linux 태스크를 더욱 적절히 배치하려면 Windows 컨테이너 인스턴스와 Linux 컨테이너 인스턴스를 별도의 클러스터에 두고 Windows 클러스터에는 Windows 작업만 배치합니다. `memberOf(ecs.os-type=='windows')` 배치 제약을 설정하여 Windows 인스턴스에만 Windows 태스크 정의가 배치되어 있는지 확인할 수 있습니다.
+ Windows 컨테이너는 EC2 및 Fargate를 사용하는 태스크에 대해 지원됩니다.
+ Windows 컨테이너와 컨테이너 인스턴스는 Linux 컨테이너 및 컨테이너 인스턴스에서 사용할 수 있는 태스크 정의 파라미터를 모두 지원할 수 없습니다. 일부 파라미터는 전혀 지원되지 않고 Windows에서 Linux에서와 다르게 동작하는 파라미터도 있습니다. 자세한 내용은 [Windows를 실행하는 EC2 인스턴스에 대한 Amazon ECS 작업 정의 차이](windows_task_definitions.md) 섹션을 참조하세요.
+ 작업에 대한 IAM 역할 기능의 경우, 시작 시 해당 기능을 허용하도록 Windows 컨테이너 인스턴스를 구성해야 합니다. 컨테이너는 기능을 사용할 때 제공된 PowerShell 코드를 실행해야 합니다. 자세한 내용은 [Amazon EC2 Windows 인스턴스 추가 구성](task-iam-roles.md#windows_task_IAM_roles) 섹션을 참조하세요.
+ 작업에 대한 IAM 역할 기능은 자격 증명 프록시를 사용하여 컨테이너에 자격 증명을 제공합니다. 이 자격 증명 프록시는 컨테이너 인스턴스에서 포트 80을 점유하므로 태스크를 위한 IAM 역할을 사용하는 경우, 해당 작업에 포트 80을 사용할 수 없습니다. 웹 서비스 컨테이너의 경우, Application Load Balancer 및 동적 포트 매핑을 사용하여 컨테이너에 표준 HTTP 포트 80 연결을 제공할 수 있습니다. 자세한 내용은 [로드 밸런싱을 사용하여 Amazon ECS 서비스 트래픽 분산](service-load-balancing.md) 섹션을 참조하세요.
+ Windows 서버 Docker 이미지는 큽니다(9GiB). 따라서 Windows 컨테이너 인스턴스에는 Linux 컨테이너 인스턴스보다 더 많은 스토리지 스페이스가 필요합니다.
+ Windows Server에서 Windows 컨테이너를 실행하려면 컨테이너와 호스트의 기본 이미지 OS 버전이 일치해야 합니다. 자세한 내용은 Microsoft 설명서 웹 사이트의 [Windows 컨테이너 버전 호환성](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11)을 참조하세요. 클러스터에서 여러 Windows 버전을 실행하는 경우 배치 제약 조건 `memberOf(attribute:ecs.os-family == WINDOWS_SERVER__)`를 사용하여 동일한 버전에서 실행되는 EC2 인스턴스에 작업이 배치되도록 할 수 있습니다. 자세한 내용은 [Amazon ECS 최적화 Windows AMI 메타데이터 검색](retrieve-ecs-optimized_windows_AMI.md) 섹션을 참조하세요.
# Amazon ECS 최적화 Windows AMI 메타데이터 검색
AMI ID, 이미지 이름, 운영 체제, 컨테이너 에이전트 버전 및 Amazon ECS 최적화 AMI의 각 변형에 대한 런타임 버전은 Systems Manager Parameter Store API를 쿼리함으로써 프로그래밍 방식으로 가져올 수 있습니다. Systems Manager Parameter Store API에 대한 자세한 정보는 [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html) 및 [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html)를 참조하세요.
**참고**
Amazon ECS 최적화 AMI 메타데이터를 검색하려면 관리 사용자에게 다음과 같은 IAM 권한이 있어야 합니다. 이러한 권한은 `AmazonECS_FullAccess` IAM 정책에 추가되었습니다.
ssm:GetParameters
ssm:GetParameter
ssm:GetParametersByPath
## Systems Manager Parameter Store 파라미터 형식
**참고**
다음 Systems Manager Parameter Store API 파라미터는 더 이상 사용되지 않으며 최신 Windows AMI를 검색하는 데 사용해서는 안 됩니다.
`/aws/service/ecs/optimized-ami/windows_server/2016/english/full/recommended/image_id `
`/aws/service/ecs/optimized-ami/windows_server/2019/english/full/recommended/image_id`
다음은 각 Amazon ECS 최적화 AMI 변형에 대한 파라미터 이름의 형식입니다.
+ Windows Server 2025 Full AMI 메타데이터:
```
/aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
```
+ Windows Server 2025 Core AMI 메타데이터:
```
/aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
```
+ Windows Server 2022 Full AMI 메타데이터:
```
/aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
```
+ Windows Server 2022 Core AMI 메타데이터:
```
/aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
```
+ Windows Server 2019 Full AMI 메타데이터:
```
/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```
+ Windows Server 2019 Core AMI 메타데이터:
```
/aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
```
+ Windows Server 2016 Full AMI 메타데이터:
```
/aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
```
다음 파라미터 이름 형식은 안정적인 최신 Windows Server 2019 Full AMI의 메타데이터를 검색합니다.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```
다음은 파라미터 값에 대해 반환된 JSON 객체의 예입니다.
```
{
"Parameters": [
{
"Name": "/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
"Type": "String",
"Value": "{\"image_name\":\"Windows_Server-2019-English-Full-ECS_Optimized-2023.06.13\",\"image_id\":\"ami-0debc1fb48e4aee16\",\"ecs_runtime_version\":\"Docker (CE) version 20.10.21\",\"ecs_agent_version\":\"1.72.0\"}",
"Version": 58,
"LastModifiedDate": "2023-06-22T19:37:37.841000-04:00",
"ARN": "arn:aws:ssm:us-east-1::parameter/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
"DataType": "text"
}
],
"InvalidParameters": []
}
```
위 출력의 각 필드를 하위 파라미터 쿼리에 사용할 수 있습니다. 선택한 AMI 경로에 하위 파라미터 이름을 추가해 하위 파라미터에 대한 파라미터 경로를 구성합니다. 다음 하위 파라미터를 사용할 수 있습니다.
+ `schema_version`
+ `image_id`
+ `image_name`
+ `os`
+ `ecs_agent_version`
+ `ecs_runtime_version`
## 예제
다음 예에서는 Amazon ECS 최적화 AMI 변형에 대한 메타데이터를 검색할 수 있는 방법을 보여 줍니다.
### 안정적인 최신 Amazon ECS 최적화 AMI의 메타데이터 검색
AWS CLI와 다음 AWS CLI 명령을 사용하여 안정적인 최신 Amazon ECS 최적화 AMI를 가져올 수 있습니다.
+ **Amazon ECS 최적화 Windows Server 2025 Full AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized --region us-east-1
```
+ **Amazon ECS 최적화 Windows Server 2025 Core AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized --region us-east-1
```
+ **Amazon ECS 최적화 Windows Server 2022 Full AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized --region us-east-1
```
+ **Amazon ECS 최적화 Windows Server 2022 Core AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized --region us-east-1
```
+ **Amazon ECS 최적화 Windows Server 2019 Full AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized --region us-east-1
```
+ **Amazon ECS 최적화 Windows Server 2019 Core AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized --region us-east-1
```
+ **Amazon ECS 최적화 Windows Server 2016 Full AMI의 경우:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized --region us-east-1
```
### CloudFormation 템플릿에서 최신 권장 Amazon ECS 최적화 AMI 사용
Systems Manager 파라미터 스토어 이름을 참조하여 CloudFormation 템플릿에서 최신 Amazon ECS 최적화 AMI를 참조할 수 있습니다.
```
Parameters:
LatestECSOptimizedAMI:
Description: AMI ID
Type: AWS::SSM::Parameter::Value
Default: /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized/image_id
```
# Amazon ECS 최적화 Windows AMI 버전
Amazon ECS 최적화 AMI의 현재 및 이전 버전과 이에 상응하는 Amazon ECS 컨테이너 에이전트, Docker 및 `ecs-init` 패키지의 버전을 확인합니다.
AMI ID를 포함하여 각 변형에 대한 Amazon ECS 최적화 AMI 메타데이터를 프로그래밍 방식으로 가져올 수 있습니다. 자세한 내용은 [Amazon ECS 최적화 Windows AMI 메타데이터 검색](retrieve-ecs-optimized_windows_AMI.md) 섹션을 참조하세요.
다음 탭에는 Windows Amazon ECS 최적화 AMI 버전 목록이 표시됩니다. CloudFormation 템플릿에서 Systems Manager Parameter Store 파라미터를 참조하는 방법에 대한 자세한 정보는 대한 자세한 정보는 [CloudFormation 템플릿에서 최신 권장 Amazon ECS 최적화 AMI 사용](retrieve-ecs-optimized_AMI.md#ecs-optimized-ami-parameter-examples-5) 섹션을 참조하세요.
**중요**
고객들이 항상 최신 보안 업데이트를 갖출 수 있도록 하기 위해 Amazon ECS는 최소 세 개의 Windows Amazon ECS 최적화 AMI를 유지합니다. 새로운 Windows Amazon ECS 최적화 AMI를 출시한 후, Amazon ECS는 이전 프라이빗인 Windows Amazon ECS 최적화 AMI를 만듭니다. 액세스해야 하는 프라이빗 AMI가 있는 경우 Cloud Support를 통해 티켓을 제출하여 알려주세요.
Windows Server 2016은 최신 Docker 버전(예: 25.x.x)을 지원하지 않습니다. 따라서 Windows Server 2016 Full AMI는 Docker 런타임에 대한 보안 또는 버그 패치를 수신하지 않습니다. 다음 Windows 플랫폼 중 하나를 사용하여 이전하는 것이 좋습니다.
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core
**참고**
gMSA 플러그인 로깅은 2025년 8월 AMI 릴리스를 통해 파일 기반 로깅 `(C:\ProgramData\Amazon\gmsa)`에서 Windows Event logging 으로 마이그레이션되었습니다. 퍼블릭 로그 수집기 스크립트는 모든 gMSA 로그를 수집합니다. 자세한 내용은 [Amazon ECS 로그 수집기를 사용하여 컨테이너 로그 수집](ecs-logs-collector.md) 섹션을 참조하세요.
------
#### [ Windows Server 2025 Full AMI versions ]
아래 테이블에는 Amazon ECS 최적화 Windows Server 2025 Full AMI의 현재 및 이전 버전과 이에 상응하는 Amazon ECS 컨테이너 에이전트 및 Docker의 버전이 나열되어 있습니다.
| Amazon ECS 최적화 Windows Server 2025 Full AMI | Amazon ECS 컨테이너 에이전트 버전 | Docker 버전 | 표시 여부 |
| --- | --- | --- | --- |
| **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | 퍼블릭 |
| **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.07.16** | `1.96.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.06.13** | `1.94.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
다음 AWS CLI 명령을 사용하여 현재 Amazon ECS 최적화 Windows Server 2025 Full AMI를 검색합니다.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
```
------
#### [ Windows Server 2025 Core AMI versions ]
아래 테이블에는 Amazon ECS 최적화 Windows Server 2025 Core AMI의 현재 및 이전 버전과 이에 상응하는 Amazon ECS 컨테이너 에이전트 및 Docker의 버전이 나열되어 있습니다.
| Amazon ECS 최적화 Windows Server 2025 Core AMI | Amazon ECS 컨테이너 에이전트 버전 | Docker 버전 | 표시 여부 |
| --- | --- | --- | --- |
| **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | 퍼블릭 |
| **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.07.16** | `1.96.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.06.13** | `1.94.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
다음 AWS CLI 명령을 사용하여 현재 Amazon ECS 최적화 Windows Server 2025 Core AMI를 검색합니다.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
```
------
#### [ Windows Server 2022 Full AMI versions ]
아래 표에는 Amazon ECS 최적화 Windows Server 2022 Full AMI의 현재 및 이전 버전과 이에 상응하는 Amazon ECS 컨테이너 에이전트 및 Docker의 버전이 나열되어 있습니다.
| Amazon ECS 최적화 Windows Server 2022 Full AMI | Amazon ECS 컨테이너 에이전트 버전 | Docker 버전 | 표시 여부 |
| --- | --- | --- | --- |
| **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | 퍼블릭 |
| **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.07.16** | `1.95.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
다음 AWS CLI 명령을 사용해 현재 Amazon ECS 최적화 Windows Server 2022 Full AMI를 검색합니다.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
```
------
#### [ Windows Server 2022 Core AMI versions ]
아래 표에는 Amazon ECS 최적화 Windows Server 2022 Core AMI의 현재 및 이전 버전과 이에 상응하는 Amazon ECS 컨테이너 에이전트 및 Docker의 버전이 나열되어 있습니다.
| Amazon ECS 최적화 Windows Server 2022 Core AMI | Amazon ECS 컨테이너 에이전트 버전 | Docker 버전 | 표시 여부 |
| --- | --- | --- | --- |
| **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | 퍼블릭 |
| **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.07.16** | `1.95.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
다음 AWS CLI 명령을 사용해 현재 Amazon ECS 최적화 Windows Server 2022 Full AMI를 검색합니다.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
```
------
#### [ Windows Server 2019 Full AMI versions ]
아래 표에는 Amazon ECS 최적화 Windows Server 2019 Full AMI의 현재 및 이전 버전과 이에 상응하는 Amazon ECS 컨테이너 에이전트 및 Docker의 버전이 나열되어 있습니다.
| Amazon ECS 최적화 Windows Server 2019 Full AMI | Amazon ECS 컨테이너 에이전트 버전 | Docker 버전 | 표시 여부 |
| --- | --- | --- | --- |
| **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | 퍼블릭 |
| **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.07.16** | `1.95.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
다음 AWS CLI 명령을 사용해 현재 Amazon ECS 최적화 Windows Server 2019 Full AMI를 검색합니다.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```
------
#### [ Windows Server 2019 Core AMI versions ]
아래 표에는 Amazon ECS 최적화 Windows Server 2019 Core AMI의 현재 및 이전 버전과 이에 상응하는 Amazon ECS 컨테이너 에이전트 및 Docker의 버전이 나열되어 있습니다.
| Amazon ECS 최적화 Windows Server 2019 Core AMI | Amazon ECS 컨테이너 에이전트 버전 | Docker 버전 | 표시 여부 |
| --- | --- | --- | --- |
| **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.09.13** | `1.99.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.08.24** | `1.98.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
| Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | 퍼블릭 |
| **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.07.16** | `1.95.0` | `25.0.6 (Docker CE)` | 퍼블릭 |
다음 AWS CLI 명령을 사용해 현재 Amazon ECS 최적화 Windows Server 2019 Full AMI를 검색합니다.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
```
------
#### [ Windows Server 2016 Full AMI versions ]
**중요**
Windows Server 2016은 최신 Docker 버전(예: 25.x.x)을 지원하지 않습니다. 따라서 Windows Server 2016 Full AMI는 Docker 런타임에 대한 보안 또는 버그 패치를 수신하지 않습니다. 다음 Windows 플랫폼 중 하나를 사용하여 이전하는 것이 좋습니다.
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core
아래 표에는 Amazon ECS 최적화 Windows Server 2016 Full AMI의 현재 및 이전 버전과 이에 상응하는 Amazon ECS 컨테이너 에이전트 및 Docker의 버전이 나열되어 있습니다.
| Amazon ECS 최적화 Windows Server 2016 Full AMI | Amazon ECS 컨테이너 에이전트 버전 | Docker 버전 | 표시 여부 |
| --- | --- | --- | --- |
| **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.09.13** | `1.99.0` | `20.10.23 (Docker CE)` | 퍼블릭 |
| **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.08.16** | `1.97.1` | `20.10.23 (Docker CE)` | 퍼블릭 |
| **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.07.16** | `1.95.0` | `20.10.23 (Docker CE)` | 퍼블릭 |
| **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.06.13** | `1.94.0` | `20.10.23 (Docker CE)` | 퍼블릭 |
다음 AWS CLI Amazon ECS 최적화 Windows Server 2016 Full AMI를 사용합니다.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
```
------
# 고유 Amazon ECS 최적화 Windows AMI 구축
EC2 Image Builder를 사용하여 사용자 지정 Amazon ECS 최적화 Windows AMI를 구축합니다. 이를 통해 Amazon ECS에서 자체 라이선스로 Windows AMI를 쉽게 사용할 수 있습니다. Amazon ECS는 컨테이너를 호스트하기 위해 Windows 인스턴스를 실행하는 데 필요한 시스템 구성을 제공하는 관리형 Image Builder 구성 요소를 제공합니다. 각 Amazon ECS 관리형 구성 요소에는 특정 컨테이너 에이전트 및 Docker 버전이 포함됩니다. 최신 Amazon ECS 관리형 구성 요소를 사용하도록 이미지를 사용자 지정하거나 이전 컨테이너 에이전트 또는 Docker 버전이 필요한 경우 다른 구성 요소를 지정할 수 있습니다.
EC2 Image Builder를 사용하는 전체 연습은 *EC2 Image Builder 사용 설명서*의 [EC2 Image Builder 시작하기](https://docs.aws.amazon.com/imagebuilder/latest/userguide/set-up-ib-env.html#image-builder-accessing-prereq)를 참조하세요.
EC2 Image Builder를 사용하여 고유의 Amazon ECS 최적화 Windows AMI를 구축할 때 이미지 레시피를 생성합니다. 이미지 레시피는 다음 요구 사항을 충족해야 합니다.
+ **소스 이미지**는 Windows Server 2019 Core, Windows Server 2019 Full, Windows Server 2022 Core 또는 Windows Server 2022 Full을 기반으로 해야 합니다. 다른 Windows 운영 체제는 지원되지 않으며 구성 요소와 호환되지 않을 수 있습니다.
+ **빌드 구성 요소**를 지정할 때 `ecs-optimized-ami-windows` 구성 요소가 필요합니다. 이미지에 최신 보안 업데이트가 포함되도록 `update-windows` 구성 요소를 사용하는 것이 좋습니다.
다른 구성 요소 버전을 지정하려면 **버전 관리 옵션(Versioning options)** 메뉴를 선택하고 사용할 구성 요소 버전을 지정합니다. 자세한 정보는 [`ecs-optimized-ami-windows` 구성 요소 버전 나열](#windows-component-list) 섹션을 참조하세요.
## `ecs-optimized-ami-windows` 구성 요소 버전 나열
EC2 Image Builder 레시피를 생성하고 `ecs-optimized-ami-windows` 구성 요소를 지정할 때 기본 옵션을 사용하거나 특정 구성 요소 버전을 지정할 수 있습니다. Amazon ECS 컨테이너 에이전트 및 구성 요소 내에 포함된 Docker 버전과 함께 사용 가능한 구성 요소 버전을 확인하기 위해 AWS Management Console을 사용할 수 있습니다.
**사용 가능한 `ecs-optimized-ami-windows` 구성 요소 버전을 나열하려면**
1. [https://console.aws.amazon.com/imagebuilder/](https://console.aws.amazon.com/imagebuilder/)에서 EC2 Image Builder 콘솔을 엽니다.
1. 탐색 모음에서 이미지를 구축하고 있는 리전을 선택합니다.
1. 탐색 창의 **저장된 구성(Saved configurations)** 메뉴에서 **구성 요소(Components)**를 선택합니다.
1. **구성 요소** 페이지의 검색 창에 `ecs-optimized-ami-windows`를 입력하고 검증 메뉴를 아래로 당겨 **빠른 시작(아마존 관리형)(Quick start (Amazon-managed))**을 선택합니다.
1. **설명(Description)** 열에서 Amazon ECS 컨테이너 에이전트와 이미지에 필요한 Docker 버전을 사용하는 구성 요소 버전을 확인할 수 있습니다.
# Amazon ECS Windows 컨테이너 인스턴스 관리
Amazon ECS 워크로드에 EC2 인스턴스를 사용하는 경우 인스턴스를 유지 관리할 책임은 사용자에게 있습니다.
에이전트 업데이트는 Windows 컨테이너 인스턴스에 적용되지 않습니다. 새로운 컨테이너 인스턴스를 시작하여 Windows 클러스터의 에이전트 버전을 업데이트하는 것을 권장합니다.
**Topics**
+ [컨테이너 인스턴스 시작](launch_window-container_instance.md)
+ [컨테이너 인스턴스 부트스트래핑](bootstrap_windows_container_instance.md)
+ [Windows 컨테이너 인스턴스에 HTTP 프록시 사용](http_proxy_config-windows.md)
+ [스팟 인스턴스 알림을 수신하도록 컨테이너 인스턴스 구성](windows-spot-instance-draining-container.md)
# Amazon ECS Windows 컨테이너 인스턴스 시작
Amazon ECS 컨테이너 인스턴스는 Amazon EC2 콘솔을 사용하여 생성됩니다. 시작하기 전에 먼저 [Amazon ECS 사용 설정](get-set-up-for-amazon-ecs.md)의 단계를 완료해야 합니다.
시작 마법사에 대한 자세한 내용은 **Amazon EC2 사용 설명서의 [새 인스턴스 시작 마법사를 사용하여 인스턴스 시작](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-launch-instance-wizard.html)을 참조하세요.
새 Amazon EC2 마법사를 사용하여 인스턴스를 시작할 수 있습니다. 파라미터에 다음 목록을 사용할 수 있으며 파라미터는 기본값으로 나열되지 않은 상태로 둘 수 있습니다. 다음 지침은 각 파라미터 그룹을 안내합니다.
## 절차
시작하기 전에 [Amazon ECS 사용 설정](get-set-up-for-amazon-ecs.md)의 단계를 완료해야 합니다.
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 화면 상단의 탐색 모음에는 현재 AWS 리전이 표시됩니다(예: 미국 동부(오하이오)). 인스턴스를 시작할 리전을 선택합니다. 일부 Amazon EC2 리소스는 리전 간에 공유될 수 있지만 그렇지 않은 리소스도 있으므로 잘 선택해야 합니다.
1. Amazon EC2 콘솔 대시보드에서 **인스턴스 시작**을 선택합니다.
## 이름 및 태그
인스턴스 이름은 태그이며, 여기서 키는 **이름**이고 값은 사용자가 지정하는 이름입니다. 인스턴스, 볼륨 및 Elastic Graphics에 태그를 지정할 수 있습니다. 스팟 인스턴스의 경우 스팟 인스턴스 요청만 태깅할 수 있습니다.
인스턴스 이름과 추가 태그를 지정하는 것은 선택 사항입니다.
+ **이름(Name)**에 인스턴스를 설명하는 이름을 입력합니다. 이름을 지정하지 않으면 인스턴스를 시작할 때 자동으로 생성되는 ID로 인스턴스를 식별할 수 있습니다.
+ 태그를 추가하려면 **추가 태그 추가(Add additional tags)**를 선택합니다. **태그 추가(Add tag)**를 선택한 다음 키와 값을 입력하고 태그를 지정할 리소스 유형을 선택합니다. 추가할 각 추가 태그에 대해 **태그 추가(Add tag)**를 다시 선택합니다.
## 애플리케이션 및 OS 이미지(Amazon Machine Image)
Amazon Machine Image(AMI)에는 인스턴스를 생성하는 데 필요한 정보가 포함되어 있습니다. 예를 들어 AMI에는 웹 서버 역할을 수행하는 데 필요한 소프트웨어가 포함될 수 있습니다(예: Apache, 사용자의 웹 사이트).
최신 Amazon ECS 최적화 AMI 및 이들의 값은 [Windows Amazon ECS 최적화 AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_windows_AMI.html)를 참조하세요.
**검색창**을 사용하여 AWS에서 공개한 적절한 Amazon ECS 최적화 AMI를 찾습니다.
1. 요구 사항에 따라 다음의 AMI 중 하나를 **Search**(검색 창)에 입력하고 **Enter** 키를 누릅니다.
+ Windows\$1Server-2022-English-Full-ECS\$1Optimized
+ Windows\$1Server-2022-English-Core-ECS\$1Optimized
+ Windows\$1Server-2019-English-Full-ECS\$1Optimized
+ Windows\$1Server-2019-English-Core-ECS\$1Optimized
+ Windows\$1Server-2016-English-Full-ECS\$1Optimized
1. **Amazon Machine Image(AMI) 선택** 페이지에서 **커뮤니티 AMI** 탭을 선택합니다.
1. 표시되는 목록에서 게시 날짜가 가장 최신인 Microsoft 인증 AMI를 선택하고 **선택(Select)**을 클릭합니다.
## 인스턴스 유형
인스턴스 유형은 인스턴스의 하드웨어 구성과 크기를 정의합니다. 대형 인스턴스는 CPU와 메모리가 더 높습니다. 자세한 정보는 [인스턴스 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)을 참조하세요.
+ **인스턴스 유형(Instance type)**에서 인스턴스에 대한 인스턴스 유형을 선택합니다.
여기서 선택하는 인스턴스 유형은 실행할 작업에 사용 가능한 리소스를 결정합니다.
## 키 페어(로그인)
**키 페어 이름(Key pair name)**에서 기존 키 페어를 선택하거나 **새로운 키 페어 생성(Create new key pair)**을 선택하여 새로 생성합니다.
**중요**
**키 페어 없이 진행(Proceed without key pair)**(권장하지 않음) 옵션을 선택할 경우 사용자가 다른 방법으로 로그인할 수 있도록 구성된 AMI를 선택해야만 인스턴스에 연결할 수 있습니다.
## 네트워크 설정
필요에 따라 네트워크 설정을 구성합니다.
+ **네트워킹 플랫폼(Networking platform)**: **Virtual Private Cloud (VPC)**를 선택한 다음 **네트워킹 인터페이스(Network interfaces)** 섹션에서 서브넷을 지정합니다.
+ **VPC**: 보안 그룹을 생성할 기존 VPC를 선택합니다.
+ **서브넷(Subnet)**: 가용 영역, 로컬 영역, Wavelength Zone 또는 Outposts와 연결된 서브넷에서 인스턴스를 시작할 수 있습니다.
가용 영역에서 인스턴스를 시작하려면 인스턴스를 시작할 서브넷을 선택합니다. 새 서브넷을 생성하려면 **새 서브넷 생성**을 선택하여 Amazon VPC 콘솔로 이동합니다. 마친 후에 인스턴스 시작 마법사로 돌아와 새로 고침 아이콘을 선택하면 해당 서브넷이 목록에 로딩됩니다.
로컬 영역에서 인스턴스를 시작하려면 로컬 영역에 생성된 서브넷을 선택합니다.
Outposts에서 인스턴스를 시작하려면 Outposts와 연결된 VPC의 서브넷을 선택합니다.
+ **퍼블릭 IP 자동 할당(Auto-assign Public IP)**: 인터넷에서 인스턴스에 액세스할 수 있어야 한다면 **퍼블릭 IP 자동 할당(Auto-assign Public IP)** 필드가 **사용 설정(Enable)**으로 설정되어 있는지 확인합니다. 이렇게 설정이 되어 있지 않으면 이 필드를 **비활성화(Disable)**로 설정합니다.
**참고**
컨테이너 인스턴스는 Amazon ECS 서비스 엔드포인트와 통신하기 위한 액세스 권한이 필요합니다. 액세스 권한은 인터페이스 VPC 엔드포인트를 통하거나 퍼블릭 IP 주소가 있는 컨테이너 인스턴스를 통해 부여할 수 있습니다.
인터페이스 VPC 엔드포인트에 대한 자세한 정보는 [Amazon ECS 및 인터페이스 VPC 엔드포인트(AWS PrivateLink)](vpc-endpoints.md) 섹션을 참조하세요.
인터페이스 VPC 엔드포인트가 구성되어 있지 않고 컨테이너 인스턴스에 퍼블릭 IP 주소가 없는 경우, NAT(Network Address Translation)를 사용하여 이 액세스 권한을 제공해야 합니다. 자세한 정보는 [Amazon VPC 사용 설명서](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)의 *NAT 게이트웨이* 및 이 가이드의 [Amazon ECS Linux 컨테이너 인스턴스에 HTTP 프록시 사용](http_proxy_config.md) 섹션을 참조하세요.
+ **방화벽(보안 그룹)(Firewall (security groups))**: 보안 그룹을 사용하여 컨테이너 인스턴스의 방화벽 규칙을 정의합니다. 이 규칙은 컨테이너 인스턴스에 전달되는 수신 네트워크 트래픽을 지정합니다. 다른 모든 트래픽은 무시됩니다.
+ 기존 보안 그룹을 선택하려면 **기존 보안 그룹 선택(Select an existing security group)**을 선택하고 [Amazon ECS 사용 설정](get-set-up-for-amazon-ecs.md)에서 생성한 보안 그룹을 선택합니다.
## 스토리지 구성
선택한 AMI에는 루트 볼륨을 포함한 하나 이상의 스토리지 볼륨이 있습니다. 인스턴스에 연결할 추가 볼륨을 지정할 수 있습니다.
**간단(Simple)** 보기를 사용할 수 있습니다.
+ **스토리지 유형(Storage type)**: 컨테이너 인스턴스의 스토리지를 구성합니다.
Amazon ECS 최적화 Amazon Linux AMI를 사용하는 경우 인스턴스에는 2개의 볼륨이 구성되어 있습니다. **Root** 볼륨은 운영 체제가 사용하고, 두 번째 Amazon EBS 볼륨(`/dev/xvdcz`에 연결)은 Docker가 사용합니다.
애플리케이션 요구에 맞춰 인스턴스의 볼륨 크기를 선택적으로 늘리거나 줄일 수 있습니다.
## 고급 세부 정보
**고급 세부 정보**에서 필드를 볼 수 있도록 섹션을 확장하고 인스턴스를 위한 추가 파라미터를 지정합니다.
+ **구매 옵션(Purchasing option)**: 스팟 인스턴스를 요청하려면 **스팟 인스턴스 요청(Request Spot Instances)**을 선택합니다. 스팟 인스턴스와 관련된 다른 필드도 설정해야 합니다. 자세한 정보는 [스팟 인스턴스 요청](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html)을 참조하세요.
**참고**
스팟 인스턴스를 사용하는 경우 `Not available` 메시지가 표시되면 다른 인스턴스 유형을 선택해야 할 수 있습니다.
.
+ **IAM 인스턴스 프로파일(IAM instance profile)**: 컨테이너 인스턴스 IAM 역할을 선택합니다. 이는 일반적으로 `ecsInstanceRole`로 이름이 지정됩니다.
**중요**
적절한 IAM 권한을 사용하여 컨테이너 인스턴스를 시작하지 않으면 Amazon ECS 에이전트가 클러스터에 연결할 수 없습니다. 자세한 정보는 [Amazon ECS 컨테이너 인스턴스 IAM 역할](instance_IAM_role.md)을 참조하세요.
+ (선택사항) **사용자 데이터(User data)**: 사용자 데이터(예: [Amazon ECS 컨테이너 에이전트 구성](ecs-agent-config.md)의 에이전트 환경 변수)로 Amazon ECS 컨테이너 인스턴스를 구성합니다. Amazon EC2 사용자 데이터 스크립트는 인스턴스가 처음 시작될 때 한 번만 실행됩니다. 다음은 사용자 데이터의 일반적인 용례입니다.
+ 기본적으로 컨테이너 인스턴스는 기본 클러스터로 시작됩니다. 기본이 아닌 클러스터로 시작하려면 **고급 세부 정보(Advanced Details)** 목록을 선택합니다. 그런 다음 **사용자 데이터(User data)** 필드에 다음 스크립트를 붙여 넣고 *your\$1cluster\$1name*을 클러스터 이름으로 대체합니다.
`EnableTaskIAMRole`은 태스크에 대한 태스크 IAM 역할 기능을 켭니다.
또한 `awsvpc` 네트워크 모드를 사용할 때 다음과 같은 옵션을 사용할 수 있습니다.
+ `EnableTaskENI`: 이 플래그는 태스크 네트워킹을 활성화하며, `awsvpc` 네트워크 모드를 사용할 때 필요합니다.
+ `AwsvpcBlockIMDS`: 이 선택적 플래그는 `awsvpc` 네트워크 모드에서 실행 중인 태스크 컨테이너에 대한 IMDS 액세스를 차단합니다.
+ `AwsvpcAdditionalLocalRoutes`: 이 선택적 플래그를 사용하면 태스크 네임스페이스에 추가 경로를 가질 수 있습니다.
`ip-address`를 추가 경로의 IP 주소(예: 172.31.42.23/32)로 교체합니다.
```
Import-Module ECSTools
Initialize-ECSAgent -Cluster your_cluster_name -EnableTaskIAMRole -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
'["ip-address"]'
```
# 데이터 전달을 위한 Amazon ECS Windows 컨테이너 인스턴스 부트스트래핑
Amazon EC2 인스턴스를 시작하면 사용자 데이터를 EC2 인스턴스에 전달할 수 있습니다. 이 데이터는 일반적인 구성 태스크를 자동으로 수행하는 데 사용할 수 있고, 인스턴스가 부팅될 때 스크립트를 실행하는 데 사용할 수도 있습니다. Amazon ECS의 경우 사용자 데이터의 가장 일반적인 사용 사례는 구성 정보를 Docker 대몬 및 Amazon ECS 컨테이너 에이전트에 전달하는 것입니다.
클라우드 boothook, 셸 스크립트, `cloud-init` 명령을 비롯하여 여러 유형의 사용자 데이터를 Amazon EC2에 전달할 수 있습니다. 이러한 유형 및 다른 형식 유형에 대한 자세한 정보는 [Cloud-Init 설명서](https://cloudinit.readthedocs.io/en/latest/explanation/format.html)를 참조하세요.
Amazon EC2 시작 마법사를 사용할 때 이 사용자 데이터를 전달할 수 있습니다. 자세한 정보는 [Amazon ECS Linux 컨테이너 인스턴스 시작](launch_container_instance.md) 섹션을 참조하세요.
## 기본 Windows 사용자 데이터
이 예제 사용자 데이터 스크립트에는 콘솔을 사용하는 경우 Windows 컨테이너 인스턴스가 수신하는 기본 사용자 데이터가 표시되어 있습니다. 아래의 스크립트는 다음을 수행합니다.
+ 클러스터 이름을 입력한 이름으로 설정합니다.
+ 태스크에 대한 IAM 역할을 설정합니다.
+ `json-file` 및 `awslogs`를 사용 가능한 로깅 드라이버로 설정합니다.
또한 `awsvpc` 네트워크 모드를 사용할 때 다음과 같은 옵션을 사용할 수 있습니다.
+ `EnableTaskENI`: 이 플래그는 태스크 네트워킹을 활성화하며, `awsvpc` 네트워크 모드를 사용할 때 필요합니다.
+ `AwsvpcBlockIMDS`: 이 선택적 플래그는 `awsvpc` 네트워크 모드에서 실행 중인 태스크 컨테이너에 대한 IMDS 액세스를 차단합니다.
+ `AwsvpcAdditionalLocalRoutes`: 이 선택적 플래그를 사용하면 추가 경로를 가질 수 있습니다.
`ip-address`를 추가 경로의 IP 주소(예: 172.31.42.23/32)로 교체합니다.
자체 컨테이너 인스턴스(Amazon ECS 최적화 Windows Server AMI에서 시작된 경우)에 이 스크립트를 사용할 수 있습니다.
`-Cluster cluster-name` 줄을 바꾸어 자체 클러스터 이름을 지정합니다.
```
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
'["ip-address"]'
```
`awslogs` 로깅 드라이버를 사용하도록 구성된 Windows 태스크의 경우 컨테이너 인스턴스에 `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` 환경 변수도 설정해야 합니다. 다음 구문을 사용합니다.
`-Cluster cluster-name` 줄을 바꾸어 자체 클러스터 이름을 지정합니다.
```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
```
## Windows 에이전트 설치 사용자 데이터
이 예제 사용자 데이터 스크립트에서는 Amazon ECS 컨테이너 에이전트를 **Windows\$1Server-2016-English-Full-Containers** AMI로 시작하는 인스턴스에 설치합니다. [Amazon ECS Container Agent GitHub repository](https://github.com/aws/amazon-ecs-agent) README 페이지의 에이전트 설치 지침에서 수정된 것입니다.
**참고**
이 스크립트는 예시용으로 공유합니다. Amazon ECS 최적화 Windows Server AMI를 사용하여 Windows 컨테이너를 시작하는 것이 훨씬 쉽습니다. 자세한 내용은 [Fargate 워크로드에 대한 Amazon ECS 클러스터 생성](create-cluster-console-v2.md) 섹션을 참조하세요.
Windows Server 2022 Full에 Amazon ECS 에이전트를 설치하는 방법에 대한 자세한 내용은 GitHub에서[문제 3753](https://github.com/aws/amazon-ecs-agent/issues/3753)을 참조하세요.
고유한 컨테이너 인스턴스(**Windows\$1Server-2016-English-Full-Containers** AMI 버전으로 시작된 경우)에 이 스크립트를 사용할 수 있습니다. `windows` 줄을 교체하여 고유한 클러스터 이름을 지정해야 합니다(이름이 `windows`인 클러스터를 사용하지 않는 경우).
```
# Set up directories the agent uses
New-Item -Type directory -Path ${env:ProgramFiles}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS\data -Force
# Set up configuration
$ecsExeDir = "${env:ProgramFiles}\Amazon\ECS"
[Environment]::SetEnvironmentVariable("ECS_CLUSTER", "windows", "Machine")
[Environment]::SetEnvironmentVariable("ECS_LOGFILE", "${env:ProgramData}\Amazon\ECS\log\ecs-agent.log", "Machine")
[Environment]::SetEnvironmentVariable("ECS_DATADIR", "${env:ProgramData}\Amazon\ECS\data", "Machine")
# Download the agent
$agentVersion = "latest"
$agentZipUri = "https://s3.amazonaws.com/amazon-ecs-agent/ecs-agent-windows-$agentVersion.zip"
$zipFile = "${env:TEMP}\ecs-agent.zip"
Invoke-RestMethod -OutFile $zipFile -Uri $agentZipUri
# Put the executables in the executable directory.
Expand-Archive -Path $zipFile -DestinationPath $ecsExeDir -Force
Set-Location ${ecsExeDir}
# Set $EnableTaskIAMRoles to $true to enable task IAM roles
# Note that enabling IAM roles will make port 80 unavailable for tasks.
[bool]$EnableTaskIAMRoles = $false
if (${EnableTaskIAMRoles}) {
$HostSetupScript = Invoke-WebRequest https://raw.githubusercontent.com/aws/amazon-ecs-agent/master/misc/windows-deploy/hostsetup.ps1
Invoke-Expression $($HostSetupScript.Content)
}
# Install the agent service
New-Service -Name "AmazonECS" `
-BinaryPathName "$ecsExeDir\amazon-ecs-agent.exe -windows-service" `
-DisplayName "Amazon ECS" `
-Description "Amazon ECS service runs the Amazon ECS agent" `
-DependsOn Docker `
-StartupType Manual
sc.exe failure AmazonECS reset=300 actions=restart/5000/restart/30000/restart/60000
sc.exe failureflag AmazonECS 1
Start-Service AmazonECS
```
# Amazon ECS Windows 컨테이너 인스턴스에 HTTP 프록시 사용
Amazon ECS 컨테이너 에이전트와 Docker 대몬 모두에 대해 HTTP 프록시를 사용하도록 Amazon ECS 컨테이너 인스턴스를 구성할 수 있습니다. 이 구성은 컨테이너 인스턴스가 Amazon VPC 인터넷 게이트웨이, NAT 게이트웨이 또는 인스턴스를 통해 외부 네트워크에 액세스하지 못할 경우 유용합니다.
HTTP 프록시를 사용하도록 Amazon ECS Windows 컨테이너 인스턴스를 구성하려면 시작 시(Amazon EC2 사용자 데이터를 사용해) 다음 변수를 설정합니다.
`[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.mydomain:port", "Machine")`
Amazon ECS 에이전트가 인터넷에 연결하는 데 사용할 HTTP 프록시의 호스트 이름(또는 IP 주소) 및 포트 번호로 `HTTP_PROXY`를 설정합니다. 예를 들어 컨테이너 인스턴스는 Amazon VPC 인터넷 게이트웨이, NAT 게이트웨이 또는 인스턴스를 통해 외부 네트워크에 액세스하지 못할 수 있습니다.
`[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")`
`NO_PROXY`를 `169.254.169.254,169.254.170.2,\\.\pipe\docker_engine`으로 설정하여 EC2 인스턴스 메타데이터, 작업에 대한 IAM 역할 및 프록시의 Docker 대몬 트래픽을 필터링합니다.
**Example Windows HTTP 프록시 사용자 데이터 스크립트**
아래의 사용자 데이터 PowerShell 스크립트 예제는 사용자가 지정한 HTTP 프록시를 사용하도록 Amazon ECS 컨테이너 에이전트와 Docker 대몬을 구성합니다. 컨테이너 인스턴스가 자신을 등록할 클러스터를 지정할 수도 있습니다.
컨테이너 인스턴스를 시작할 때 이 스크립트를 사용하려면 [Amazon ECS Windows 컨테이너 인스턴스 시작](launch_window-container_instance.md)의 절차를 따르세요. 아래 PowerShell 스크립트를 복사하여 **사용자 데이터** 필드에 붙여넣기만 하면 됩니다(빨간색 예제 값을 실제 프록시 및 클러스터 정보로 바꿔야 함).
작업에 대해 IAM 역할을 활성화하려면 `-EnableTaskIAMRole` 옵션이 필요합니다. 자세한 내용은 [Amazon EC2 Windows 인스턴스 추가 구성](task-iam-roles.md#windows_task_IAM_roles) 섹션을 참조하세요.
```
Import-Module ECSTools
$proxy = "http://proxy.mydomain:port"
[Environment]::SetEnvironmentVariable("HTTP_PROXY", $proxy, "Machine")
[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")
Restart-Service Docker
Initialize-ECSAgent -Cluster MyCluster -EnableTaskIAMRole
```
# 스팟 인스턴스 알림을 수신하도록 Amazon ECS Windows 컨테이너 인스턴스 구성
스팟 가격이 요청의 최고가를 초과하거나 용량이 더 이상 제공되지 않는 경우 Amazon EC2는 스팟 인스턴스를 종료, 중지 또는 최대 절전 모드로 전환합니다. Amazon EC2는 스팟 인스턴스 중단 2분 전에 경고하는 스팟 인스턴스 중단 공지를 제공합니다. Amazon ECS 스팟 인스턴스 드레이닝이 인스턴스에서 활성화되면 ECS는 스팟 인스턴스 중단 공지를 수신하고 인스턴스를 `DRAINING` 상태로 둡니다.
**중요**
Amazon ECS는 `terminate` 및 `stop` instance-action을 포함하고 있는 스팟 인스턴스 중단 공지를 모니터링합니다. 스팟 인스턴스 또는 스팟 플릿 요청 시 `hibernate` 인스턴스 중단 동작을 지정한 경우, 이러한 인스턴스에 대해서는 Amazon ECS 스팟 인스턴스 드레이닝은 지원되지 않습니다.
컨테이너 인스턴스를 `DRAINING`으로 설정할 경우 Amazon ECS는 새 작업이 컨테이너 인스턴스에서 배치를 위해 예약되지 않도록 합니다. 드레이닝 컨테이너 인스턴스에서 `PENDING` 상태인 서비스 작업이 즉시 중지됩니다. 클러스터에 사용 가능한 컨테이너 인스턴스가 있는 경우 거기서 대체 서비스 작업이 시작됩니다.
인스턴스를 시작할 때 스팟 인스턴스 드레인을 켤 수 있습니다. 컨테이너 에이전트를 시작하기 전에 `ECS_ENABLE_SPOT_INSTANCE_DRAINING` 파라미터를 설정해야 합니다. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다.
```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_SPOT_INSTANCE_DRAINING", "true", "Machine")
# Initialize the agent
Initialize-ECSAgent -Cluster my-cluster
```
자세한 내용은 [Amazon ECS Windows 컨테이너 인스턴스 시작](launch_window-container_instance.md) 섹션을 참조하세요.