# Amazon ECS 클러스터
Amazon ECS 클러스터는 컨테이너화된 애플리케이션에 인프라 용량을 제공하는 태스크 또는 서비스의 논리적 그룹입니다. 클러스터를 생성할 때 각기 다른 사용 사례 및 운영 요구 사항에 맞게 최적화된 세 가지 기본 인프라 유형 중에서 선택합니다.
## 올바른 클러스터 유형 선택
Amazon ECS는 클러스터에 세 가지 인프라 유형을 제공합니다. 워크로드 요구 사항, 운영 기본 설정 및 비용 최적화 목표에 가장 적합한 유형을 선택합니다.
Amazon ECS 관리형 인스턴스(권장)
**대부분의 워크로드에 가장 적합** - AWS는 프로비저닝, 패치 적용 및 규모 조정을 포함하여 기본 Amazon EC2 인스턴스를 완전히 관리합니다. 이 옵션은 성능, 비용 효율성 및 운영 단순성의 최적의 균형을 제공합니다.
**사용 상황**
+ AWS를 통해 인프라 관리를 처리하려는 경우
+ 자동 최적화를 통한 비용 효율적인 컴퓨팅이 필요한 경우
+ 인프라가 아닌 애플리케이션에 집중하려는 경우
+ 유연한 조정을 통해 예측 가능한 성능이 필요한 경우
Fargate
**서버리스 컴퓨팅** - 인프라 관리 없이 태스크가 사용하는 리소스에 대해서만 비용을 지불합니다. 가변 워크로드 및 빠른 시작에 적합합니다.
**사용 상황**
+ 완전한 서버리스 작업을 원하는 경우
+ 예측할 수 없거나 가변적인 워크로드가 있는 경우
+ 운영 오버헤드를 최소화하려는 경우
+ 빠른 배포 및 확장이 필요한 경우
Amazon EC2 인스턴스
**전체 제어** - 인스턴스 선택, 구성 및 유지 관리를 포함하여 기본 Amazon EC2 인스턴스를 직접 관리합니다.
**사용 상황**
+ 특정 인스턴스 유형 또는 구성이 필요한 경우
+ 활용할 기존 Amazon EC2 인프라가 있는 경우
+ 사용자 지정 AMI 또는 특수 소프트웨어가 필요한 경우
+ 기본 인프라를 최대한 제어해야 하는 경우
**참고**
Amazon ECS 관리형 인스턴스는 AWS에서 인프라 관리 태스크를 처리할 수 있도록 하면서 성능, 비용 최적화 및 운영 단순성에 대한 최상의 조합을 제공하므로 대부분의 새 워크로드에 권장되는 선택입니다.
## 클러스터 구성 요소
인프라 용량 외에도 클러스터는 다음 리소스로 구성됩니다.
+ 작업과 서비스가 실행되는 네트워크(VPC 및 서브넷)
용량으로 Amazon ECS 관리형 인스턴스 또는 Amazon EC2 인스턴스를 사용하는 경우 서브넷은 가용 영역, 로컬 영역, Wavelength 영역 또는 AWS Outposts에 있을 수 있습니다.
+ 선택적 네임스페이스
네임스페이스는 Service Connect와의 서비스 간 통신에 사용됩니다.
+ 모니터링 옵션
CloudWatch Container Insights는 추가 비용이 발생하며 완전 관리형 서비스입니다. 이 서비스는 Amazon ECS 지표 및 로그를 자동으로 수집, 집계 및 요약합니다.
## 클러스터 개념
다음은 Amazon ECS 클러스터에 관한 일반 개념입니다.
+ 클러스터를 생성하여 리소스를 분리합니다.
+ 클러스터는 AWS 리전별로 고유합니다.
+ 클러스터는 다음 상태 중 하나일 수 있습니다.
ACTIVE
클러스터는 해당하는 태스크에 적용될 준비가 되었으며, 클러스터로 컨테이너 인스턴스를 등록할 수 있습니다.
PROVISIONING
클러스터에 연결된 용량 공급자가 있으며 용량 공급자에게 필요한 리소스가 생성 중입니다.
DEPROVISIONING
클러스터에 연결된 용량 공급자가 있으며 용량 공급자에게 필요한 리소스를 삭제 중입니다.
FAILED
클러스터에 연결된 용량 공급자가 있으며 용량 공급자에게 필요한 리소스를 생성하는 데 실패했습니다.
INACTIVE
클러스터가 삭제되었습니다. `INACTIVE` 상태인 클러스터는 일정 기간 동안 계정에서 검색 가능한 상태로 유지될 수 있습니다. 이 동작은 향후 변경될 수 있으므로 `INACTIVE` 클러스터가 지속되는 상태에 의존해서는 안 됩니다.
+ 클러스터에는 Amazon ECS 관리형 인스턴스, AWS Fargate, Amazon EC2 인스턴스 또는 외부 인스턴스에서 호스팅되는 태스크가 혼합되어 포함될 수 있습니다. 태스크는 시작 유형 또는 용량 공급자 전략으로 Amazon ECS 관리형 인스턴스, Fargate 또는 EC2 인프라에서 실행될 수 있습니다. EC2 용량 공급자를 사용하는 경우 Amazon ECS는 Amazon EC2 Auto Scaling 그룹의 용량을 추적하거나 규모를 조정하지 않습니다.
+ 클러스터에는 Amazon ECS 관리형 인스턴스 용량 공급자, Auto Scaling 그룹 용량 공급자 및 Fargate 용량 공급자가 혼합되어 포함될 수 있습니다. 용량 공급자 전략에는 Amazon ECS 관리형 인스턴스 용량 공급자, Auto Scaling 그룹 용량 공급자 또는 Fargate 용량 공급자만 포함될 수 있습니다.
+ Amazon ECS 관리형 인스턴스 및 EC2 또는 Auto Scaling 그룹 용량 공급자에 대해 여러 인스턴스 유형을 사용할 수 있습니다. 인스턴스는 한 번에 하나의 클러스터에만 등록할 수 있습니다.
+ 사용자 지정 IAM 정책을 생성하여 클러스터에 대한 액세스를 제한할 수 있습니다. 자세한 정보는 [Amazon Elastic Container Service의 자격 증명 기반 정책 예](security_iam_id-based-policy-examples.md)의 [Amazon ECS 클러스터 예제](security_iam_id-based-policy-examples.md#IAM_cluster_policies) 섹션을 참조하세요.
+ Service Auto Scaling을 사용하여 Fargate 태스크의 규모를 조정할 수 있습니다. 자세한 내용은 [Amazon ECS 서비스 자동 조정](service-auto-scaling.md) 섹션을 참조하세요.
+ 클러스터에 대한 기본 Service Connect 네임스페이스를 구성할 수 있습니다. 기본 Service Connect 네임스페이스를 설정한 후 Service Connect를 켜서 네임스페이스의 클라이언트 서비스로 클러스터에 생성된 모든 새 서비스를 추가할 수 있습니다. 추가 구성은 필요하지 않습니다. 자세한 내용은 [Service Connect를 사용하여 짧은 이름으로 Amazon ECS 서비스 연결](service-connect.md) 섹션을 참조하세요.
## 용량 공급자
Amazon ECS 용량 공급자는 클러스터의 작업에 대한 인프라의 조정을 관리할 수 있습니다. 각 클러스터에는 하나 이상의 용량 공급자와 하나의 선택적 용량 공급자 전략이 있을 수 있습니다. 클러스터에 기본 용량 공급자 전략을 할당할 수 있습니다. 용량 공급자 전략은 태스크가 클러스터의 용량 공급자에 분배되는 방식을 결정합니다. 표준 실행 작업을 실행하거나 서비스를 생성할 때 클러스터의 기본 용량 공급자 전략 또는 기본 전략을 재정의하는 용량 공급자 전략을 사용할 수 있습니다. 클러스터의 기본 용량 공급자 전략은 태스크 또는 서비스에 대한 시작 유형 또는 용량 공급자 전략을 지정하지 않은 경우에만 적용됩니다. 이러한 파라미터 중 하나를 제공하면 기본 전략이 사용되지 않습니다.
Amazon ECS는 클러스터에 대해 세 가지 유형의 용량 공급자를 제공합니다.
Amazon ECS 관리형 인스턴스 용량 공급자
AWS는 프로비저닝, 패치 적용, 규모 조정 및 수명 주기 관리를 포함하여 기본 Amazon EC2 인스턴스를 완전히 관리합니다. 이를 통해 성능, 비용 효율성 및 운영 단순성에서 최적의 균형을 확보할 수 있습니다. Amazon ECS 관리형 인스턴스 용량 공급자는 워크로드 요구 사항에 따라 인스턴스 선택 및 규모 조정을 자동으로 최적화합니다.
Amazon ECS 관리형 인스턴스를 사용하면 다음과 같은 이점을 얻을 수 있습니다.
+ 자동 인스턴스 프로비저닝 및 조정
+ 관리형 패치 적용 및 보안 업데이트
+ 지능형 인스턴스 선택을 통한 비용 최적화
+ 운영 오버헤드 감소
Fargate 용량 공급자
인프라 관리 없이 태스크가 사용하는 리소스에 대해서만 비용을 지불하는 서버리스 컴퓨팅. 사전 정의된 용량 공급자(Fargate 및 Fargate 스팟)를 클러스터에 연결하기만 하면 됩니다.
오토 스케일링 용량 공급자
용량으로 Amazon EC2 인스턴스를 사용하는 경우 Auto Scaling 그룹을 사용하여 Amazon EC2 인스턴스를 관리합니다. Auto Scaling은 애플리케이션 로드를 처리하는 데 사용할 수 있는 Amazon EC2 인스턴스의 정확한 수를 확보하는 데 도움이 됩니다. 기본 인프라를 완전히 제어할 수 있습니다.
클러스터에는 Amazon ECS 관리형 인스턴스, AWS Fargate, Amazon EC2 인스턴스 또는 외부 인스턴스에서 호스팅되는 태스크가 혼합되어 포함될 수 있습니다. 태스크는 시작 유형 또는 용량 공급자 전략으로 Amazon ECS 관리형 인스턴스, Fargate 또는 EC2 인프라에서 실행될 수 있습니다. EC2를 시작 유형으로 사용하는 경우 Amazon ECS는 Amazon EC2 Auto Scaling 그룹의 용량을 추적하거나 규모를 조정하지 않습니다.
클러스터에는 Amazon ECS 관리형 인스턴스 용량 공급자, Auto Scaling 그룹 용량 공급자 및 Fargate 용량 공급자가 혼합되어 포함될 수 있습니다. 용량 공급자 전략에는 Amazon ECS 관리형 인스턴스 용량 공급자, Auto Scaling 그룹 용량 공급자 또는 Fargate 용량 공급자만 포함될 수 있습니다.
# Amazon ECS 관리형 인스턴스용 클러스터
Amazon ECS 용량 공급자는 클러스터의 작업에 대한 인프라의 조정을 관리할 수 있습니다. 클러스터를 생성한 후 하나 이상의 용량 공급자와 클러스터에 대한 선택적 용량 공급자 전략을 생성합니다. 용량 공급자 전략은 태스크가 클러스터의 용량 공급자에 분배되는 방식을 결정합니다. 표준 실행 작업을 실행하거나 서비스를 생성할 때 클러스터의 기본 용량 공급자 전략 또는 기본 전략을 재정의하는 용량 공급자 전략을 사용할 수 있습니다.
Amazon ECS 관리형 인스턴스에는 다음과 같은 용량 공급자가 있습니다.
| Type | 인스턴스를 선택하는 데 사용되는 기준 |
| --- | --- |
| 기본값 | 다음 태스크 정의 및 서비스 파라미터 요구 사항을 충족하는 가장 비용 효율적인 인스턴스.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/managed-instance-clusters.html) |
| 사용자 지정 | 클러스터를 생성할 때 사용자가 지정하는 속성 및 유형 요구 사항을 충족하는 인스턴스. 속성에 대한 자세한 내용은 [Amazon ECS 컨테이너 인스턴스 속성](task-placement-constraints.md#attributes) 섹션을 참조하세요. 인스턴스 유형에 대한 자세한 내용은 Amazon EC2 인스턴스 유형의 [Amazon EC2 instance type specifications](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html)를 참조하세요. |
Amazon ECS는 인스턴스를 시작하고 Amazon ECS 관리형 인스턴스 용량 공급자와 연결합니다. 사용자 지정 용량 공급자의 경우 Amazon ECS는 용량 공급자도 생성합니다.
# Amazon ECS 관리형 인스턴스용 클러스터 생성
클러스터를 생성하여 태스크와 서비스가 실행되는 인프라를 정의합니다.
Amazon ECS 관리형 인스턴스용 클러스터를 생성하면 기본적으로 `FARGATE_MANAGED_INSTANCE` 용량 공급자에 액세스할 수 있습니다. 이 용량 공급자는 워크로드에 가장 비용 최적화된 인스턴스 유형을 자동으로 선택합니다. 특정 인스턴스 속성 또는 유형이 필요한 경우 사용자 지정 용량 공급자를 생성할 수도 있습니다.
클러스터를 최대한 쉽게 만들 수 있도록 콘솔에는 여러 선택에 대한 기본 선택 항목이 있습니다.
+ AWS Cloud Map에서 클러스터와 이름이 동일한 기본 네임스페이스를 생성합니다. 네임스페이스를 사용하면 클러스터에서 생성한 서비스를 추가 구성 없이 네임스페이스의 다른 서비스에 연결할 수 있습니다.
자세한 내용은 [Amazon ECS 서비스 상호 연결](interconnecting-services.md) 섹션을 참조하세요.
다음 옵션을 수정할 수 있습니다.
+ 클러스터와 연결된 기본 네임스페이스를 변경합니다.
네임스페이스를 사용하면 클러스터에서 생성한 서비스를 추가 구성 없이 네임스페이스의 다른 서비스에 연결할 수 있습니다. 기본 네임스페이스는 클러스터 이름과 동일합니다. 자세한 내용은 [Amazon ECS 서비스 상호 연결](interconnecting-services.md) 섹션을 참조하세요.
+ 관리형 스토리지에 AWS KMS 키를 할당합니다. 키 생성 방법에 대한 자세한 내용은 *AWS Key Management Service 사용 설명서*의 [KMS 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)을 참조하세요.
+ 클러스터를 식별하는 데 도움이 되는 태그를 추가합니다.
## 사전 조건
시작하기 전에 먼저 [Amazon ECS 사용 설정](get-set-up-for-amazon-ecs.md) 단계를 완료하고 적절한 IAM 권한을 할당했는지 확인합니다. 자세한 내용은 [Amazon ECS 클러스터 예제](security_iam_id-based-policy-examples.md#IAM_cluster_policies) 섹션을 참조하세요.
클러스터를 생성하는 사용자에게는 `iam:CreateServiceLinkedRole`의 추가 권한이 있어야 합니다.
기본적으로 Amazon ECS는 태스크 정의에서 지정한 요구 사항에 따라 인스턴스 유형을 선택합니다. 기본 용량 공급자입니다. 특정 인스턴스 속성 또는 유형이 필요한 경우 모든 요구 사항을 기록해 둡니다. 사용자 지정 용량 공급자를 사용한 다음 인스턴스 요구 사항을 지정해야 합니다.
인스턴스를 선택하는 방법을 이해합니다. 자세한 내용은 [Amazon ECS 관리형 인스턴스에 대한 인스턴스 선택 모범 사례](managed-instances-instance-selection-best-practices.md) 섹션을 참조하세요.
Amazon ECS 관리형 인스턴스에 필요한 IAM 역할이 있습니다. 여기에는 다음이 포함됩니다.
+ **인프라 역할** - Amazon ECS가 사용자를 대신해 AWS 서비스를 직접 호출하여 Amazon ECS 관리형 인스턴스 인프라를 관리하도록 허용합니다.
자세한 내용은 [Amazon ECS 인프라 IAM 역할](infrastructure_IAM_role.md) 섹션을 참조하세요.
+ **인스턴스 프로파일** - 관리형 인스턴스에서 실행되는 Amazon ECS 컨테이너 에이전트 및 Docker 대몬에 대한 권한을 제공합니다.
자세한 내용은 [Amazon ECS 관리형 인스턴스의 인스턴스 프로파일](managed-instances-instance-profile.md) 섹션을 참조하세요.
## 콘솔 절차
**새 클러스터 생성(Amazon ECS 콘솔)**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 모음에서 사용할 리전을 선택합니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터(Clusters)** 페이지에서 **클러스터 생성(Create cluster)**을 선택합니다.
1. **클러스터 구성**에서 다음을 구성합니다.
+ **클러스터 이름**에 고유한 이름을 입력합니다.
이름은 최대 255자(대/소문자), 숫자 및 하이픈을 포함할 수 있습니다.
+ (선택 사항) 서비스 연결에 사용되는 네임스페이스를 클러스터 이름과 다르게 하려면 **네임스페이스**에 고유한 이름을 입력합니다.
1. **사용자 지정 용량 공급자**에서 다음을 수행합니다.
+ **EC2 용량을 얻는 방법 선택**에서 **Amazon ECS 관리형 인스턴스**를 선택하세요.
+ 인스턴스 프로파일에서 인스턴스 프로파일 유형을 선택하세요.
+ 인프라 역할에서 인프라 역할을 선택합니다.
+ 사용자 지정 용량 공급자를 사용하려면 **인스턴스 선택**에서 **사용자 지정 사용**을 선택하세요. 그런 다음 각 속성에 대해 **속성 값**을 입력하세요.
1. (선택 사항) Container Insights를 사용하고 **모니터링**을 확장한 후에 다음 옵션 중 하나를 선택합니다.
+ 권장되는 관찰성이 향상된 Container Insights를 사용하려면 **관찰성이 향상된 Container Insights**를 선택합니다.
+ Container Insights를 사용하려면 **Container Insights**를 선택합니다.
1. (선택 사항) 관리형 스토리지의 데이터를 암호화합니다. **암호화**에서 **관리형 스토리지**에 관리형 스토리지 데이터를 암호화하는 데 사용할 AWS KMS 키의 ARN을 입력합니다.
1. (선택 사항) 클러스터를 식별하려면 **태그(Tags)**를 펼친 다음, 태그를 구성합니다.
[태그 추가] **태그 추가(Add tag)**를 선택하고 다음을 수행합니다.
+ **키(Key)**에 키 이름을 입력합니다.
+ **값**에 키 값을 입력합니다.
1. **생성(Create)**을 선택합니다.
## AWS CLI 절차
AWS CLI를 사용하여 Amazon ECS 관리형 인스턴스용 클러스터를 생성할 수 있습니다. AWS CLI의 최신 버전을 사용합니다. 최신 버전으로 업그레이드하는 방법에 대한 자세한 내용은 [AWS CLI 최신 버전의 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
**참고**
듀얼 스택 서비스 엔드포인트를 사용하면 AWS AWS CLI, SDK 및 Amazon ECS API에서 IPv4 및 IPv6 모두를 통해 Amazon ECS와 상호 작용할 수 있습니다. 자세한 내용은 [Amazon ECS 듀얼 스택 엔드포인트 사용](dual-stack-endpoint.md) 섹션을 참조하세요.
**새로운 클러스터를 생성하는 방법(AWS CLI)**
1. 다음 명령을 사용하여 고유한 이름의 클러스터를 생성하세요.
```
aws ecs create-cluster --cluster-name managed-instances-cluster
```
출력:
```
{
"cluster": {
"status": "ACTIVE",
"defaultCapacityProviderStrategy": [],
"statistics": [],
"capacityProviders": [],
"tags": [],
"clusterName": "managed-instances-cluster",
"settings": [
{
"name": "containerInsights",
"value": "disabled"
}
],
"registeredContainerInstancesCount": 0,
"pendingTasksCount": 0,
"runningTasksCount": 0,
"activeServicesCount": 0,
"clusterArn": "arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster"
}
}
```
1. (선택 사항) 클러스터에 대한 향상된 관찰성으로 Container Insights를 활성화하려면 다음 명령을 사용하세요.
```
aws ecs put-account-setting --name containerInsights --value enhanced
```
1. (선택 사항) 클러스터에 태그를 추가하려면 다음 명령을 사용하세요.
```
aws ecs tag-resource --resource-arn arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster --tags key=Environment,value=Production
```
## 다음 단계
Amazon ECS 관리형 인스턴스에 대한 태스크 정의를 생성하세요. 자세한 내용은 [콘솔을 사용하여 Amazon ECS 작업 정의 생성](create-task-definition.md) 섹션을 참조하세요.
애플리케이션을 독립 실행형 태스크 또는 서비스의 일부로 실행합니다. 자세한 내용은 다음을 참조하세요.
+ [애플리케이션을 Amazon ECS 태스크로 실행](standalone-task-create.md)
+ [Amazon ECS 롤링 업데이트 배포 생성](create-service-console-v2.md)
# Amazon ECS 관리형 인스턴스를 사용하도록 클러스터 업데이트
Amazon ECS 관리형 인스턴스를 사용하도록 기존 클러스터를 업데이트할 수 있습니다.
클러스터에 Amazon ECS 관리형 인스턴스를 추가하면 기본적으로 `FARGATE_MANAGED_INSTANCE` 용량 공급자에 액세스할 수 있습니다. 이 용량 공급자는 워크로드에 가장 비용 최적화된 범용 인스턴스 유형을 자동으로 선택합니다. 특정 인스턴스 속성 또는 유형이 필요한 경우 사용자 지정 용량 공급자를 생성할 수도 있습니다.
## 사전 조건
기본적으로 Amazon ECS는 태스크 정의에서 지정한 요구 사항에 따라 인스턴스 유형을 선택합니다. 기본 용량 공급자입니다. 특정 인스턴스 속성 또는 유형이 필요한 경우 모든 요구 사항을 기록해 둡니다. 사용자 지정 용량 공급자를 사용한 다음 인스턴스 요구 사항을 지정해야 합니다.
Amazon ECS 관리형 인스턴스에 필요한 IAM 역할이 있습니다. 여기에는 다음이 포함됩니다.
+ **인프라 역할** - Amazon ECS가 사용자를 대신해 AWS 서비스를 직접 호출하여 Amazon ECS 관리형 인스턴스 인프라를 관리하도록 허용합니다.
자세한 내용은 [Amazon ECS 인프라 IAM 역할](infrastructure_IAM_role.md) 섹션을 참조하세요.
+ **인스턴스 프로파일** - 관리형 인스턴스에서 실행되는 Amazon ECS 컨테이너 에이전트 및 Docker 대몬에 대한 권한을 제공합니다.
자세한 내용은 [Amazon ECS 관리형 인스턴스의 인스턴스 프로파일](managed-instances-instance-profile.md) 섹션을 참조하세요.
## 업데이트 고려 사항
Amazon ECS 관리형 인스턴스의 클러스터를 업데이트할 경우 다음 사항을 고려합니다.
+ 태스크 실행 - 클러스터 설정을 업데이트해도 현재 실행 중인 태스크에는 영향을 주지 않습니다. 변경 사항은 업데이트 후 시작된 새 태스크에 적용됩니다.
+ 용량 공급자 변경 - 용량 공급자 설정을 수정하면 기존 관리형 인스턴스는 계속 실행되지만 새 인스턴스는 업데이트된 구성을 사용합니다.
+ 변경 사항 모니터링 - Container Insights를 활성화하거나 비활성화하면 전체 클러스터의 지표 수집에 영향을 미칩니다.
## 콘솔 절차
**클러스터 업데이트 방법(Amazon ECS 콘솔)**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 모음에서 사용할 리전을 선택합니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터**를 선택하고 업데이트할 클러스터를 선택하세요.
1. **클러스터 업데이트**를 선택하세요.
1. (선택 사항) 용량 공급자 설정을 수정하려면 **사용자 지정 용량 공급자**에서 필요에 따라 다음을 업데이트하세요.
+ **인스턴스 프로파일**에서 필요한 경우 다른 인스턴스 프로파일 역할을 선택하세요.
+ **인프라 역할**에서 필요한 경우 다른 인프라 역할을 선택하세요.
+ 사용자 지정 용량 공급자를 사용하려면 **인스턴스 선택**에서 **속성 값** 설정을 업데이트하세요.
1. **업데이트**를 선택합니다.
## AWS CLI 절차
AWS CLI를 사용하여 Amazon ECS 관리형 인스턴스의 클러스터를 업데이트할 수 있습니다. AWS CLI의 최신 버전을 사용합니다. 최신 버전으로 업그레이드하는 방법에 대한 자세한 내용은 [AWS CLI 최신 버전의 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
**참고**
듀얼 스택 서비스 엔드포인트를 사용하면 AWS AWS CLI, SDK 및 Amazon ECS API에서 IPv4 및 IPv6 모두를 통해 Amazon ECS와 상호 작용할 수 있습니다. 자세한 내용은 [Amazon ECS 듀얼 스택 엔드포인트 사용](dual-stack-endpoint.md) 섹션을 참조하세요.
**클러스터 업데이트 방법(AWS CLI)**
1. 용량 공급자를 생성하세요. 다음 명령을 실행합니다.
모든 *사용자 입력*을 사용자의 값으로 바꿉니다.
```
aws ecs create-capacity-provider \
--name my-managed-instances-provider \
--managed-instances-provider \
--instance-profile arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile \
--infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRole \
--instance-requirements '{
"vCpuCount": {"min": 2, "max": 8},
"memoryMiB": {"min": 4096, "max": 16384}
}
```
1. 클러스터에 용량 공급자를 추가하려면 다음 명령을 사용하세요.
모든 *사용자 입력*을 사용자의 값으로 바꿉니다.
```
aws ecs put-cluster-capacity-providers --cluster managed-instances-cluster --capacity-providers my-managed-instances-provider --default-capacity-provider-strategy capacityProvider=my-managed-instances-provider,weight=1
```
# Amazon ECS 관리형 인스턴스 용량 공급자
Amazon ECS 관리형 인스턴스 용량 공급자는 AWS 기능과 Amazon EC2 오퍼링의 전체 범위에 대한 액세스를 제공하는 컨테이너 컴퓨팅 모델을 제공하면서 AWS가 운영 및 보안 책임을 관리합니다. AWS는 소프트웨어 및 OS 패치, 인스턴스 규모 조정 및 유지 관리를 처리하여 모든 AWS 기능과 통합에 대한 액세스를 유지하면서 Fargate의 운영 이점을 제공합니다.
Amazon ECS는 Amazon ECS 관리형 인스턴스에 대한 시작 템플릿을 생성합니다. 여기에서는 Amazon ECS가 태스크에 대한 인스턴스 프로파일, 네트워크 및 스토리지 구성, 용량 옵션, 유연한 인스턴스 유형 선택을 위한 인스턴스 요구 사항을 포함하여 Amazon ECS 관리형 인스턴스를 시작하는 방법을 정의합니다.
## 사용자 지정 용량 공급자를 사용해야 하는 경우
워크로드에 다음이 필요한 경우 사용자 지정 용량 공급자를 고려합니다.
+ 특정 컴퓨팅 요구 사항: 표준 Fargate 옵션에서 사용할 수 없는 가속화된 컴퓨팅, 특정 CPU 명령 세트, 높은 네트워크 성능 또는 대용량 메모리 구성이 필요한 애플리케이션.
+ GPU 워크로드: 기계 학습 추론, 실시간 이미지 렌더링, 비디오 인코딩 또는 NVIDIA 또는 AMD GPU에 액세스해야 하는 기타 GPU.
+ 용량 예약: 예측 가능한 용량 가용성이 필요한 미션 크리티컬 워크로드.
+ 고급 관찰성: eBPF 기반 모니터링 솔루션 또는 네트워크 분석 도구와 같이 기본 OS에 대한 권한 있는 액세스가 필요한 보안 및 모니터링 도구.
+ 비용 최적화: 다중 태스크 배치, 공유 인프라 구성 요소의 이점을 누릴 수 있거나 더 큰 인스턴스 유형의 사용률을 극대화해야 하는 워크로드.
## 모니터링 옵션
Amazon ECS 관리형 인스턴스는 컨테이너화된 워크로드의 성능, 상태 및 리소스 사용률을 추적하는 데 도움이 되는 포괄적인 모니터링 기능을 제공합니다. 운영 요구 사항에 따라 여러 모니터링 수준 중에서 선택할 수 있습니다.
+ **기본 모니터링** - 대부분의 지표에 대해 5분 간격, 상태 확인에 대해 1분 간격으로 필수 지표를 제공합니다. 기본적으로 활성화되어 있으며 추가 요금이 발생하지 않습니다.
+ **세부 모니터링** - 1분 간격으로 사용할 수 있는 모든 지표를 통해 향상된 가시성을 제공하므로 운영 문제를 더 빠르게 감지하고 이에 대응할 수 있습니다. 자세한 내용은 [Amazon ECS 관리형 인스턴스에 대한 세부 모니터링](monitoring-managed-instances.md#detailed-monitoring-managed-instances) 섹션을 참조하세요.
두 모니터링 옵션 모두 CloudWatch와 원활하게 통합되어 대시보드, 경보 및 자동화된 응답을 제공하여 최적의 애플리케이션 성능과 가용성을 유지하는 데 도움이 됩니다.
## 용량 공급자 고려 사항
클러스터에는 Amazon ECS 관리형 인스턴스 용량 공급자, Auto Scaling 그룹 용량 공급자 및 Fargate 용량 공급자가 혼합되어 포함될 수 있습니다. 용량 공급자 전략에는 Amazon ECS 관리형 인스턴스 용량 공급자, Auto Scaling 그룹 용량 공급자 또는 Fargate 용량 공급자만 포함될 수 있습니다.
## 태그 전파
Amazon ECS 관리형 인스턴스의 용량 공급자는 태그 전파를 지원합니다. 태그 전파를 사용하면 관리형 인스턴스, Amazon ECS 컨테이너 인스턴스, 시작 템플릿, 볼륨, 탄력적 네트워크 인터페이스 등 용량 공급자가 관리하는 모든 리소스에 용량 공급자 수준에서 지정된 것과 동일한 태그가 지정됩니다. 용량 공급자 생성 중에 태그를 지정하고 `propagateTags` 파라미터를 `CAPACITY_PROVIDER`로 지정하여 태그 전파를 활성화할 수 있습니다.
Amazon ECS 관리형 인스턴스 태그 지정에 대한 자세한 내용은 [Amazon ECS 관리형 인스턴스에 대한 태그](instance-details-tags-managed-instances.md) 섹션을 참조하세요.
# Amazon ECS 관리형 인스턴스의 용량 공급자 업데이트 모범 사례
최고 수준의 안전 및 롤백 지원을 위해 용량 공급자를 변경할 수 없는 리소스로 취급하는 것이 좋습니다. 용량 공급자 구성을 업데이트해야 하는 경우 다음 권장 워크플로를 따릅니다.
1. 기존 용량 공급자를 수정하는 대신 업데이트된 구성으로 **새 용량 공급자를 생성**합니다.
1. 새 용량 공급자를 사용하고 배포를 완료하도록 **각 서비스를 업데이트**합니다.
1. 새 구성이 예상대로 작동하는지 확인한 후 **이전 용량 공급자를 삭제**합니다.
이 접근 방식은 다음과 같은 몇 가지 이점을 제공합니다.
+ **제어된 롤아웃** - 서비스를 한 번에 하나씩 업데이트하고 영향을 모니터링할 수 있습니다.
+ **간편한 롤백** - 문제가 발생하면 서비스를 신속하게 되돌려 이전 용량 공급자를 사용할 수 있습니다.
+ **영향 범위 감소** - 새 구성 문제가 모든 워크로드에 즉시 영향을 미치지 않습니다.
**참고**
CloudFormation을 사용하는 경우 스택 변경 사항을 롤백하는 기능을 보존하도록 나중에 배포할 때까지 이전 용량 공급자를 유지하는 방법을 고려합니다.
용량 공급자를 업데이트할 수 있지만 이 접근 방식은 제어되지 않는 더 큰 영향 범위를 생성합니다. 인플레이스 업데이트는 향후 프로비저닝되는 모든 새 용량에 새 설정을 적용하지만 서비스 배포는 트리거하지 않습니다. 즉, 훨씬 나중에 서비스를 조정해야 할 때까지 구성 문제를 발견하지 못할 수 있습니다.
# Amazon ECS 관리형 인스턴스에 대한 용량 공급자 생성
Amazon ECS 관리형 인스턴스는 용량 공급자를 사용하여 워크로드의 컴퓨팅 용량을 관리합니다. 기본적으로 Amazon ECS는 가장 비용 최적화된 범용 인스턴스 유형을 자동으로 선택하는 기본 용량 공급자를 제공합니다. 그러나 사용자 지정 용량 공급자를 생성하여 인스턴스 유형, CPU 제조업체, 액셀러레이터 유형 및 기타 요구 사항과 같은 인스턴스 속성을 지정할 수 있습니다.
사용자 지정 용량 공급자는 속성 기반 인스턴스 유형 선택을 사용하므로 인스턴스 요구 사항을 속성 세트로 표현할 수 있습니다. 이러한 요구 사항은 일치하는 모든 Amazon EC2 인스턴스 유형으로 자동 전환되므로 인스턴스 유형 구성의 생성 및 유지 관리가 단순화됩니다. 인스턴스 요구 사항 및 속성 기반 선택에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 Fleet 속성 기반 인스턴스 유형 선택](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) 설명서를 참조하세요.
## 사전 조건
시작하기 전에 다음을 완료해야 합니다.
+ 사용할 모니터링 유형을 결정합니다. 자세한 내용은 [Amazon ECS 관리형 인스턴스에 대한 세부 모니터링](monitoring-managed-instances.md#detailed-monitoring-managed-instances) 섹션을 참조하세요.
+ 기존 클러스터가 있거나 그렇지 않으면 새로 생성할 계획을 세웁니다. 자세한 내용은 [Amazon ECS 관리형 인스턴스용 클러스터 생성](create-cluster-managed-instances.md) 섹션을 참조하세요.
+ Amazon ECS 관리형 인스턴스에 필요한 IAM 역할이 있습니다. 여기에는 다음이 포함됩니다.
+ **인프라 역할** - Amazon ECS가 사용자를 대신해 AWS 서비스를 직접 호출하여 Amazon ECS 관리형 인스턴스 인프라를 관리하도록 허용합니다.
자세한 내용은 [Amazon ECS 인프라 IAM 역할](infrastructure_IAM_role.md) 섹션을 참조하세요.
+ **인스턴스 프로파일** - 관리형 인스턴스에서 실행되는 Amazon ECS 컨테이너 에이전트 및 Docker 대몬에 대한 권한을 제공합니다.
자세한 내용은 [Amazon ECS 관리형 인스턴스의 인스턴스 프로파일](managed-instances-instance-profile.md) 섹션을 참조하세요.
인스턴스를 선택하는 방법을 이해합니다. 자세한 내용은 [Amazon ECS 관리형 인스턴스에 대한 인스턴스 선택 모범 사례](managed-instances-instance-selection-best-practices.md) 섹션을 참조하세요.
## 콘솔 절차
**Amazon ECS 관리형 인스턴스에 대한 용량 공급자를 생성하는 방법(Amazon ECS 콘솔)**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 모음에서 사용할 리전을 선택합니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터** 페이지에서 클러스터 이름을 선택하세요.
1. 클러스터 페이지에서 **인프라** 탭을 선택하세요.
1. **용량 공급자** 섹션에서 **용량 공급자 생성**을 선택하세요.
1. **용량 공급자 구성**에서 다음을 구성하세요.
+ **용량 공급자 이름**에 용량 공급자의 고유한 이름을 입력하세요.
+ **용량 공급자 유형**에서 **Amazon ECS 관리형 인스턴스**를 선택하세요.
1. **인스턴스 구성**에서 다음을 구성하세요.
+ **인스턴스 프로파일**에서 Amazon ECS 관리형 인스턴스에 대해 생성된 인스턴스 프로파일 역할을 선택하세요.
+ **인프라 역할**에서 Amazon ECS 관리형 인스턴스에 대해 생성된 인프라 역할을 선택하세요.
1. **인스턴스 요구 사항**에서 인스턴스의 속성을 지정하세요. 다음 항목을 조합하여 구성할 수 있습니다.
+ **vCPU 수** - vCPU 수를 지정합니다(예: `4` 또는 범위의 경우 `8-16`).
+ **메모리(MiB)** - 메모리 양을 MiB 단위로 지정합니다(예: `8192` 또는 범위의 경우 `16384-32768`).
+ **인스턴스 유형** - 특정 인스턴스 유형(예: `m5.large,m5.xlarge,c5.large`)을 지정합니다.
+ **CPU 제조업체** - `intel`, `amd` 또는 `amazon-web-services` 중에서 선택합니다.
+ **액셀러레이터 유형** - `gpu`, `fpga` 또는 `inference`와 같은 액셀러레이터 유형을 지정합니다.
+ **액셀러레이터 수** - 액셀러레이터 수를 지정합니다(예: `1` 또는 범위의 경우 `2-4`).
1. **고급 구성**에서 다음 모니터링 옵션 중 하나를 선택하세요.
+ CloudWatch가 상태 확인 지표를 전송하도록 하려면 **기본**을 선택하세요.
+ CloudWatch가 모든 지표 지표를 전송하도록 하려면 **세부**를 선택하세요.
1. (선택 사항) 용량 공급자를 식별하려면 **태그**를 확장하고 태그를 구성하세요.
용량 공급자에서 용량 공급자에서 시작된 인스턴스와 같은 관리형 리소스로 태그 전파를 활성화하려면 **태그 전파**에서 **용량 공급자**를 선택하세요.
[태그 추가] **태그 추가(Add tag)**를 선택하고 다음을 수행합니다.
+ **키(Key)**에 키 이름을 입력합니다.
+ **값**에 키 값을 입력합니다.
1. **생성(Create)**을 선택합니다.
## AWS CLI 절차
AWS CLI를 사용하여 Amazon ECS 관리형 인스턴스의 용량 공급자를 생성할 수 있습니다. AWS CLI의 최신 버전을 사용합니다. 최신 버전으로 업그레이드하는 방법에 대한 자세한 내용은 [AWS CLI 최신 버전의 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
**Amazon ECS 관리형 인스턴스의 용량 공급자를 생성하는 방법(AWS CLI)**
1. 다음 명령을 실행합니다.
```
aws ecs create-capacity-provider --cli-input-json file://capacity-provider-definition.json
```
다음 `capacity-provider-definition.json`은 기본 인스턴스 요구 사항과 인스턴스 스토리지 크기를 지정하고 태그 전파를 활성화하는 데 사용할 수 있습니다.
```
{
"name": "my-managed-instances-provider",
"cluster": "my-cluster",
"tags": [
{
"key": "version",
"value": "test"
}
],
"managedInstancesProvider": {
"infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole",
"instanceLaunchTemplate": {
"ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
"instanceRequirements": {
"vCpuCount": {
"min": 4,
"max": 8
},
"memoryMiB": {
"min": 8192,
"max": 16384
}
},
"networkConfiguration": {
"subnets": [
"subnet-abcdef01234567",
"subnet-bcdefa98765432"
],
"securityGroups": [
"sg-0123456789abcdef"
]
},
"storageConfiguration": {
"storageSizeGiB": 100
},
"monitoring": "basic"
},
"propagateTags": "CAPACITY_PROVIDER"
}
}
```
1. 용량 공급자가 성공적으로 생성되었는지 확인하세요.
```
aws ecs describe-capacity-providers \
--capacity-providers my-managed-instances-provider
```
## 다음 단계
용량 공급자를 생성한 후 서비스를 생성하거나 작업을 실행할 때 사용할 수 있습니다.
+ 서비스에서 용량 공급자를 사용하려면 [Amazon ECS 롤링 업데이트 배포 생성](create-service-console-v2.md) 섹션을 참조하세요.
+ 독립 실행형 태스크와 함께 용량 공급자를 사용하려면 [애플리케이션을 Amazon ECS 태스크로 실행](standalone-task-create.md) 섹션을 참조하세요.
# Amazon ECS 관리형 인스턴스 모니터링 업데이트
Amazon ECS 관리형 인스턴스 용량 공급자의 모니터링 옵션을 수정하여 기본 모니터링과 세부 모니터링 사이를 변경할 수 있습니다. 이를 통해 용량 공급자를 다시 생성하지 않고도 수집된 모니터링 데이터의 수준을 조정할 수 있습니다.
모니터링 옵션에 대한 자세한 내용은 [Amazon ECS 관리형 인스턴스 모니터링](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-managed-instances.html)을 참조하세요.
## 콘솔 절차
**Amazon ECS 관리형 인스턴스에 대한 모니터링을 업데이트하는 방법(Amazon ECS 콘솔)**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 모음에서 사용할 리전을 선택합니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터** 페이지에서 클러스터 이름을 선택하세요.
1. 클러스터 페이지에서 **인프라** 탭을 선택하세요.
1. **고급 구성**에서 다음 모니터링 옵션 중 하나를 선택하세요.
+ CloudWatch가 상태 확인 지표를 전송하도록 하려면 **기본**을 선택하세요.
+ CloudWatch가 모든 지표 지표를 전송하도록 하려면 **세부**를 선택하세요.
1. **업데이트**를 선택합니다.
기존 Amazon ECS 관리형 인스턴스 용량 공급자와 연결된 태그를 업데이트하려면 다음 단계를 따릅니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. 클러스터 페이지에서 **인프라**를 선택하세요.
1. 인프라 페이지에서 사용자가 생성한 용량 공급자를 선택하세요.
1. 용량 공급자 페이지에서 **태그**를 선택하세요.
1. **태그**에서 **태그 관리**를 선택합니다.
1. 태그를 추가하려면 추가하려는 태그의 키와 값을 지정한 다음 **저장**을 선택하세요. 한 번에 여러 태그를 추가하려면 추가하려는 각 태그에 대해 **태그 추가**를 선택하세요. 최대 50개의 태그를 추가할 수 있습니다.
태그를 제거하려면 **제거**를 선택합니다.
**참고**
태그 전파가 활성화된 경우 용량 공급자 생성 후 추가되거나 제거된 태그는 용량 공급자가 이전에 생성한 리소스에 적용되지 않습니다.
## AWS CLI 절차
AWS CLI를 사용하여 Amazon ECS 관리형 인스턴스의 용량 공급자를 업데이트할 수 있습니다. AWS CLI의 최신 버전을 사용합니다. 최신 버전으로 업그레이드하는 방법에 대한 자세한 내용은 [AWS CLI 최신 버전의 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
**Amazon ECS 관리형 인스턴스에 대한 모니터링을 업데이트하는 방법(AWS CLI)**
1. 세부 모니터링을 활성화하려면 다음 명령을 사용하세요.
```
aws ecs update-capacity-provider \
--name my-managed-instances-provider \
--managed-instances-provider '{
"instanceLaunchTemplateUpdate": {
"monitoring": "DETAILED"
}
}'
```
1. 기본 모니터링을 활성화하려면 다음 명령을 사용하세요.
```
aws ecs update-capacity-provider \
--name my-managed-instances-provider \
--managed-instances-provider '{
"instanceLaunchTemplateUpdate": {
"monitoring": "BASIC"
}
}'
```
# Amazon ECS 관리형 인스턴스 용량 공급자 삭제
Amazon ECS 관리형 인스턴스 용량 공급자를 사용하여 완료한 경우 삭제할 수 있습니다. 그룹이 삭제되면 Amazon ECS 관리형 인스턴스 용량 공급자가 `INACTIVE` 상태로 전환됩니다. `INACTIVE` 상태인 용량 공급자는 일정 기간 동안 계정에서 검색 가능한 상태로 유지될 수 있습니다. 하지만 이 동작은 향후 변경될 수 있으므로 `INACTIVE` 용량 공급자가 지속되는 상태에 의존해서는 안 됩니다. Amazon ECS 관리형 인스턴스 용량 공급자를 삭제하기 전에 모든 서비스의 용량 공급자 전략에서 해당 용량 공급자를 제거해야 합니다. Amazon ECS 콘솔의 `UpdateService` API 또는 업데이트 서비스 워크플로를 사용하여 서비스의 용량 공급자 전략에서 용량 공급자를 제거할 수 있습니다. **새 배포 강제 적용** 옵션을 사용하면 용량 공급자가 제공한 Amazon ECS 관리형 인스턴스 용량을 사용하는 모든 태스크가 나머지 용량 공급자의 용량을 사용하도록 전환됩니다.
**클러스터에 대한 용량 공급자 삭제 방법(Amazon ECS 콘솔)**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다.
1. **클러스터: *이름*** 페이지에서 **인프라**, Amazon ECS 관리형 인스턴스 용량 공급자를 선택한 다음 **삭제**를 선택하세요.
1. 확인 상자에 ***Amazon ECS Managed Instances capacity provider name* 삭제**를 입력하세요.
1. **삭제**를 선택합니다.
# Amazon ECS 관리형 인스턴스에서 실행되는 Amazon ECS 워크로드를 안전하게 중지
Amazon ECS Task Scale-in Protection을 사용하여 서비스 규모 조정 또는 배포의 스케일 인 이벤트로 인해 태스크가 종료되지 않도록 보호할 수 있습니다.
특정 애플리케이션에는 사용률이 낮은 시간이나 서비스 배포 중에 스케일 인 이벤트로 인해 미션 크리티컬 작업이 종료되지 않도록 보호하는 메커니즘이 필요합니다. 예제:
+ 누적 서비스 사용률이 낮더라도 일부 작업을 몇 시간 동안 실행해야 하는 비디오 트랜스코딩 작업과 같은 큐 처리 비동기 애플리케이션이 있습니다.
+ 모든 사용자가 로그아웃한 경우에도 서버 재부팅으로 인한 시작 지연 시간을 줄이기 위해 게임 서버를 태스크로 실행하는 게임 애플리케이션이 있습니다.
+ 새 코드 버전을 배포할 때는 재처리하는 데 비용이 많이 들기 때문에 작업을 계속 실행해야 합니다.
서비스에 속한 작업이 스케일 인 이벤트로 인해 종료되지 않도록 보호하려면 `ProtectionEnabled` 속성을 `true`로 설정합니다. `ProtectionEnabled`을 true로 설정하면 작업이 기본적으로 2시간 동안 보호됩니다. 그러면 `ExpiresInMinutes` 속성을 사용하여 보호 기간을 사용자 지정할 수 있습니다. 최소 1분, 최대 2,880분(48시간) 동안 작업을 보호할 수 있습니다. AWS CLI를 사용하는 경우 `--protection-enabled` 옵션을 지정할 수 있습니다.
작업이 필요한 작업을 완료한 후 `ProtectionEnabled` 속성을 `false`로 설정하여 후속 스케일 인 이벤트에 의해 작업이 종료되도록 할 수 있습니다. AWS CLI를 사용하는 경우 `--no-protection-enabled` 옵션을 지정할 수 있습니다.
## Task scale-in protection 메커니즘
Amazon ECS 컨테이너 에이전트 엔드포인트 또는 Amazon ECS API를 사용하여 Task scale-in protection을 설정하고 가져올 수 있습니다.
+ **Amazon ECS 컨테이너 에이전트 엔드포인트**
보호 필요성을 스스로 결정할 수 있는 작업에는 Amazon ECS 컨테이너 에이전트 엔드포인트를 사용하는 것이 좋습니다. 대기열 기반 또는 작업 처리 워크로드에 이 접근 방식을 사용합니다.
예를 들어, 컨테이너가 SQS 메시지를 사용하여 작업 처리를 시작하면 컨테이너 내에서 Task scale-in protection 엔드포인트 경로 `$ECS_AGENT_URI/task-protection/v1/state`를 통해 `ProtectionEnabled` 속성을 설정할 수 있습니다. Amazon ECS는 스케일 인 이벤트 중에 이 작업을 종료하지 않습니다. 작업이 완료된 후 동일한 엔드포인트를 사용하여 `ProtectionEnabled` 속성 선택을 해제하여 후속 스케일 인 이벤트 중에 작업을 종료할 수 있습니다.
Amazon ECS 컨테이너 에이전트 엔드포인트 사용에 대한 자세한 내용은 [Amazon ECS task scale-in protection 엔드포인트](managed-instance-task-scale-in-protection-endpoint.md) 섹션을 참조하세요.
+ **Amazon ECS API**
애플리케이션에 활성 작업의 상태를 추적하는 구성 요소가 있는 경우 Amazon ECS API를 사용하여 Task scale-in protection을 설정할 수 있습니다. `UpdateTaskProtection`을 사용하여 하나 이상의 작업을 보호됨으로 표시합니다. `GetTaskProtection`을 사용하여 보호 상태를 검색합니다.
애플리케이션이 게임 서버 세션을 Amazon ECS 작업으로 호스팅하는 경우를 예로 들 수 있습니다. 사용자가 서버의 세션(작업)에 로그인하면 작업을 보호된 것으로 표시할 수 있습니다. 사용자가 로그아웃한 후에는 서버를 유휴 상태로 유지해야 하는 요구 사항에 따라 이 작업에 대한 보호 설정을 해제하거나 더 이상 활성 세션이 없는 유사한 작업에 대한 보호 설정을 주기적으로 해제할 수 있습니다.
자세한 내용은 Amazon Elastic Container Service API 참조의 [UpdateTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateTaskProtection.html) 및 [GetTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_GetTaskProtection.html)을 참조하세요**.
두 가지 방법을 결합할 수 있습니다. 예를 들어 Amazon ECS 에이전트 엔드포인트를 사용하여 컨테이너 내에서 작업 보호를 설정하고 Amazon ECS API를 사용하여 외부 컨트롤러 서비스에서 작업 보호를 제거할 수 있습니다.
## 고려 사항
Task scale-in protection 사용 전에 다음 사항을 고려하세요.
+ Task scale-in protection은 서비스에서 배포된 태스크에서만 지원됩니다.
+ Task Scale-in Protection은 Amazon ECS 관리형 인스턴스에서 실행되는 서비스에서 배포된 태스크에서 지원됩니다.
+ Amazon ECS 에이전트에는 재시도 메커니즘과 더 간단한 인터페이스가 내장되어 있으므로 Amazon ECS 컨테이너 에이전트 엔드포인트를 사용하는 것이 좋습니다.
+ 이미 보호 기능이 켜진 작업에서 `UpdateTaskProtection`을 호출하여 Task scale-in protection 만료 기간을 재설정할 수 있습니다.
+ 작업이 필요한 작업을 완료하는 데 필요한 시간을 결정하고 그에 따라 `expiresInMinutes` 속성을 설정합니다. 보호 만료를 필요 이상으로 길게 설정하면 비용이 발생하고 새 작업의 배포가 지연될 수 있습니다.
+ 배포 고려 사항
+ 서비스가 롤링 업데이트를 사용하는 경우 새 작업이 생성되지만 이전 버전을 실행하는 작업은 `protectionEnabled`가 설정 해제되거나 만료될 때까지 종료되지 않습니다. 배포 구성의 `maximumPercentage` 파라미터를 이전 작업이 보호될 때 새 작업을 생성할 수 있는 값으로 조정할 수 있습니다.
+ CloudFormation을 사용하는 경우 업데이트 스택의 제한 시간은 3시간입니다. 따라서 작업 보호를 3시간 이상으로 설정하면 CloudFormation 배포가 실패하고 롤백이 발생할 수 있습니다.
이전 작업이 보호되는 동안 CloudFormation 스택은 `UPDATE_IN_PROGRESS`를 표시합니다. Task scale-in protection이 제거되거나 3시간 내에 만료되면 배포가 성공하고 `UPDATE_COMPLETE` 상태로 전환됩니다. 배포가 3시간 이상 `UPDATE_IN_PROGRESS` 상태로 유지되면 실패하고 `UPDATE_FAILED` 상태가 표시되며, 이전 작업 세트로 롤백됩니다.
+ Amazon ECS는 보호 대상 작업으로 인해 배포(롤링 또는 블루/그린)가 안정 상태에 도달하지 못하는 경우 서비스 이벤트를 전송하여 수정 조치를 취할 수 있도록 합니다. 작업의 보호 상태를 업데이트하려고 시도하는 동안 `DEPLOYMENT_BLOCKED` 오류 메시지가 표시되면 서비스에 대해 바람직한 작업 수보다 보호되는 작업 수가 많음을 의미합니다. 이 오류를 해결하려면 다음 중 하나 이상을 수행합니다.
+ 현재 작업 보호가 만료될 때까지 기다립니다. 그런 다음 작업 보호를 설정합니다.
+ 중지할 수 있는 작업을 확인합니다. 그런 다음 이러한 작업에 대해 `protectionEnabled` 옵션을 `false`로 설정한 상태에서 `UpdateTaskProtection`을 사용합니다.
+ 서비스의 바람직한 작업 수를 보호되는 작업 수 이상으로 늘립니다.
## Task scale-in protection에 필요한 IAM 권한
태스크에는 다음 권한이 있는 Amazon ECS 태스크 역할이 있어야 합니다.
+ `ecs:GetTaskProtection`: Amazon ECS 컨테이너 에이전트가 `GetTaskProtection`을 호출할 수 있습니다.
+ `ecs:UpdateTaskProtection`: Amazon ECS 컨테이너 에이전트가 `UpdateTaskProtection`을 호출할 수 있습니다.
# Amazon ECS task scale-in protection 엔드포인트
Amazon ECS 컨테이너 에이전트는 Amazon ECS 작업의 컨테이너에 `ECS_AGENT_URI` 환경 변수를 자동으로 주입하여 컨테이너 에이전트 API 엔드포인트와 상호 작용하는 방법을 제공합니다.
보호 필요성을 스스로 결정할 수 있는 작업에는 Amazon ECS 컨테이너 에이전트 엔드포인트를 사용하는 것이 좋습니다.
컨테이너가 작업 처리를 시작하면 컨테이너 내에서 Task scale-in protection 엔드포인트 경로 `$ECS_AGENT_URI/task-protection/v1/state`를 통해 `protectionEnabled` 속성을 설정할 수 있습니다.
컨테이너 내에서 이 URI에 대한 PUT 요청은 Task scale-in protection을 설정합니다. 이 URI에 대한 GET 요청은 작업의 현재 보호 상태를 반환합니다.
## Task scale-in protection 요청 파라미터
다음 요청 파라미터와 함께 `${ECS_AGENT_URI}/task-protection/v1/state` 엔드포인트를 사용하여 Task scale-in protection을 설정할 수 있습니다.
`ProtectionEnabled`
작업을 보호 대상으로 표시하려면 `true`를 지정합니다. 보호를 제거하고 작업을 종료할 수 있도록 표시하려면 `false`를 지정합니다.
유형: Boolean
필수 여부: 예
`ExpiresInMinutes`
작업이 보호되는 시간(분)입니다. 최소 1분에서 최대 2,880분(48시간)까지 지정할 수 있습니다. 이 기간 동안에는 서비스 Auto Scaling 또는 배포의 스케일 인 이벤트로 인해 작업이 종료되지 않습니다. 이 기간이 경과하면 `protectionEnabled` 파라미터가 `false`로 설정됩니다.
시간을 지정하지 않으면 작업이 120분(2시간) 동안 자동으로 보호됩니다.
유형: 정수
필수 여부: 아니요
다음은 각기 다른 기간으로 작업 보호를 설정하는 예입니다.
**기본 기간에 작업을 보호하는 방법 예제**
이 예제에서는 기본 시간인 2시간으로 작업을 보호하는 방법을 보여줍니다.
```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true}'
```
**60분간 작업을 보호하는 방법 예제**
이 예제에서는 `expiresInMinutes` 파라미터를 사용하여 60분 동안 작업을 보호하는 방법을 보여줍니다.
```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":60}'
```
**24시간 동안 작업을 보호하는 방법 예제**
이 예제에서는 `expiresInMinutes` 파라미터를 사용하여 24시간 동안 작업을 보호하는 방법을 보여줍니다.
```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}'
```
PUT 요청은 다음과 같은 응답을 반환합니다.
```
{
"protection": {
"ExpirationDate": "2023-12-20T21:57:44.837Z",
"ProtectionEnabled": true,
"TaskArn": "arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
}
}
```
## Task scale-in protection 응답 파라미터
다음 정보가 Task scale-in protection 엔드포인트(`${ECS_AGENT_URI}/task-protection/v1/state`)에서 JSON 응답으로 반환됩니다.
`ExpirationDate`
작업에 대한 보호가 만료되는 Epoch 시간입니다. 작업이 보호되지 않는 경우 이 값은 null입니다.
`ProtectionEnabled`
작업의 보호 상태입니다. 작업에 대해 축소 보호가 활성화되면 값은 `true`이고, 그렇지 않으면 `false`입니다.
`TaskArn`
컨테이너가 속한 태스크의 전체 Amazon 리소스 이름(ARN)
다음 예제에서는 보호된 작업에 대해 반환된 세부 정보를 보여줍니다.
```
curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
```
```
{
"protection":{
"ExpirationDate":"2023-12-20T21:57:44Z",
"ProtectionEnabled":true,
"TaskArn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
}
}
```
결함이 발생하면 다음 정보가 반환됩니다.
`Arn`
작업의 전체 Amazon 리소스 이름(ARN)입니다.
`Detail`
실패와 관련된 세부 정보입니다.
`Reason`
실패 이유
다음 예제에서는 보호되지 않는 작업에 대해 반환된 세부 정보를 보여줍니다.
```
{
"failure":{
"Arn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0",
"Detail":null,
"Reason":"TASK_NOT_VALID"
}
}
```
예외가 발생하면 다음 정보가 반환됩니다.
`requestID`
예외를 발생시키는 Amazon ECS API 호출에 대한 AWS 요청 ID입니다.
`Arn`
작업 또는 서비스의 전체 Amazon 리소스 이름(ARN)입니다.
`Code`
오류 코드입니다.
`Message`
오류 메시지입니다.
`RequestError` 또는 `RequestTimeout` 오류가 표시되면 이는 네트워킹 문제일 수 있습니다. Amazon ECS에 VPC 엔드포인트를 사용해 보세요.
다음 예제에서는 오류 발생 시 반환되는 세부 정보를 보여줍니다.
```
{
"requestID":"12345-abc-6789-0123-abc",
"error":{
"Arn":"arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
"Code":"AccessDeniedException",
"Message":"User: arn:aws:sts::444455556666:assumed-role/my-ecs-task-role/1234567890abcdef0 is not authorized to perform: ecs:GetTaskProtection on resource: arn:aws:ecs:us-west-2:555555555555:task/test/1234567890abcdef0 because no identity-based policy allows the ecs:GetTaskProtection action"
}
}
```
네트워크 문제 또는 Amazon ECS 컨트롤 플레인 중단과 같은 이유로 Amazon ECS 에이전트가 Amazon ECS 엔드포인트에서 응답을 받을 수 없는 경우 다음 오류가 표시됩니다.
```
{
"error": {
"Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
"Code": "RequestCanceled",
"Message": "Timed out calling Amazon ECS Task Protection API"
}
}
```
Amazon ECS 에이전트가 Amazon ECS에서 제한 예외를 받으면 다음 오류가 표시됩니다.
```
{
"requestID": "12345-abc-6789-0123-abc",
"error": {
"Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
"Code": "ThrottlingException",
"Message": "Rate exceeded"
}
}
```
# Fargate용 Amazon ECS 클러스터
AWS Fargate 용량 공급자의 Amazon ECS를 사용하면 Amazon ECS 작업에서 Fargate 및 Fargate Spot 용량을 모두 사용할 수 있습니다.
Fargate Spot을 사용하면 Fargate 가격 대비 할인된 요금으로 중단 방지 Amazon ECS 작업을 실행할 수 있습니다. Fargate 스팟은 여분의 컴퓨팅 용량에 대한 태스크를 실행합니다. AWS에 용량이 다시 필요한 경우 2분간 경고한 후에 작업이 중단됩니다.
Fargate 및 Fargate Spot 용량 공급자를 사용하는 작업이 중지되면 작업 상태 변경 이벤트가 Amazon EventBridge로 전송됩니다. 중지된 이유는 원인을 설명합니다. 자세한 내용은 [Amazon ECS 작업 상태 변경 이벤트](ecs_task_events.md) 섹션을 참조하세요.
클러스터에 Fargate 용량 공급자와 Auto Scaling 그룹 용량 공급자가 혼합되어 있을 수 있습니다. 그러나 용량 공급자 전략에 Fargate 또는 Auto Scaling 그룹 용량 공급자만 포함될 수 있으며 둘 다 포함될 수는 없습니다. 자세한 내용은 [Auto Scaling 그룹 용량 공급자](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html#asg-capacity-providers)를 참조하세요.
용량 공급자를 사용할 때는 다음 사항을 고려해야 합니다.
+ 용량 공급자를 클러스터와 연결하려면 먼저 클러스터를 용량 공급자 전략과 연결해야 합니다.
+ 용량 공급자 전략에 최대 20개의 용량 공급자를 지정할 수 있습니다.
+ Fargate 용량 공급자를 사용하기 위해 Auto Scaling 그룹 용량 공급자를 사용하여 서비스를 업데이트할 수 없습니다. 반대의 경우도 마찬가지입니다.
+ 용량 공급자 전략에서 콘솔의 용량 공급자에 대해 `weight` 값이 지정되지 않으면 기본값 `1`을 사용합니다. API 또는 AWS CLI를 사용할 경우에 기본값은 `0`입니다.
+ 용량 공급자 전략 내에서 여러 용량 공급자가 지정된 경우 하나 이상의 용량 공급자가 0보다 큰 가중치 값을 가져야 합니다. 가중치가 0인 용량 공급자는 태스크를 배치하는 데 사용되지 않습니다. 전략에 가중치가 모두 0으로 동일한 여러 개의 용량 공급자를 지정하는 경우 용량 공급자 전략을 사용하는 `RunTask` 또는 `CreateService` 작업이 실패합니다.
+ 용량 공급자 전략에서는 하나의 용량 공급자만 정의된 base** 값을 가질 수 있습니다. base 값을 지정하지 않으면 기본값 0이 사용됩니다.
+ 클러스터에 Auto Scaling 그룹 용량 공급자와 Fargate 용량 공급자가 혼합되어 있을 수 있습니다. 그러나 용량 공급자 전략에 Auto Scaling 그룹 또는 Fargate 용량 공급자만 포함될 수 있으며 둘 다 포함될 수는 없습니다.
+ 클러스터에는 두 용량 공급자를 모두 사용하는 서비스와 독립 실행형 태스크가 혼합되어 포함될 수 있습니다. 시작 유형이 아닌 용량 공급자 전략을 사용하도록 서비스를 업데이트할 수 있습니다. 하지만 이 경우 새 배포를 강제로 실행해야 합니다.
## Fargate Spot 종료 알림
수요가 매우 많은 기간에는 Fargate 스팟 용량을 사용할 수 없을 수 있습니다. 이로 인해 Fargate 스팟 작업이 지연될 수 있습니다. 이러한 경우 필요한 용량을 사용할 수 있을 때까지 Amazon ECS 서비스에서 태스크 시작을 다시 시도합니다. Fargate는 스팟 용량을 온디맨드 용량으로 대체하지 않습니다.
스팟 중단으로 인해 Fargate Spot 용량을 사용하는 태스크가 중지되면 태스크가 중단되기 전에 2분 간 경고가 전송됩니다. 경고는 작업 상태 변경 이벤트로 Amazon EventBridge에 전송되고 실행 중인 작업에 SIGTERM 신호로 전송됩니다. Fargate Spot을 서비스의 일부로 사용할 경우 이 시나리오에서 서비스 스케줄러는 중단 신호를 수신하고 사용 가능한 용량이 있는 경우 Fargate Spot에 대한 추가 작업의 시작을 시도합니다. 작업이 하나뿐인 서비스는 용량을 사용할 수 있을 때까지 중단됩니다. 정상 종료에 대한 자세한 내용은 [Graceful shutdowns with ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/)를 참조하세요.
작업이 중지되기 전에 컨테이너가 정상적으로 종료되도록 하려면 다음을 구성할 수 있습니다.
+ 태스크가 사용 중인 컨테이너 정의에서 `stopTimeout` 초 이하의 `120` 값을 지정할 수 있습니다. 기본 `stopTimeout` 값은 30초입니다. `stopTimeout` 값을 더 길게 지정하면 작업 상태 변경 이벤트가 수신되는 순간부터 컨테이너가 강제로 중지되는 시점 사이의 시간이 더 많이 확보됩니다. 자세한 내용은 [컨테이너 제한 시간](task_definition_parameters.md#container_definition_timeout) 섹션을 참조하세요.
+ SIGTERM 신호를 컨테이너 내에서 수신해야 정리 태스크를 수행할 수 있습니다. 이 신호를 처리하는 데 실패하면 작업은 구성된 `stopTimeout` 이후에 SIGKILL 신호를 받는 데 실패하여 데이터가 손실되거나 오류가 발생할 수 있습니다.
다음은 작업 상태 변경 이벤트의 코드 조각입니다. 이 코드 조각에는 Fargate Spot 중단에 대한 중지 사유와 중지 코드가 표시됩니다.
```
{
"version": "0",
"id": "9bcdac79-b31f-4d3d-9410-fbd727c29fab",
"detail-type": "ECS Task State Change",
"source": "aws.ecs",
"account": "111122223333",
"resources": [
"arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6f1cebef"
],
"detail": {
"clusterArn": "arn:aws:ecs:us-east-1:111122223333:cluster/default",
"createdAt": "2016-12-06T16:41:05.702Z",
"desiredStatus": "STOPPED",
"lastStatus": "RUNNING",
"stoppedReason": "Your Spot Task was interrupted.",
"stopCode": "SpotInterruption",
"taskArn": "arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6fEXAMPLE",
...
}
}
```
다음은 Amazon ECS 작업 상태 변경 이벤트에 대한 EventBridge 규칙을 생성하는 데 사용되는 이벤트 패턴입니다. 필요한 경우 `detail` 필드에 클러스터를 지정할 수 있습니다. 이렇게 하면 해당 클러스터에 대한 작업 상태 변경 이벤트를 수신하게 됩니다. EventBridge 규칙 생성에 대한 자세한 내용은 *Amazon EventBridge 사용 설명서*의 [Amazon EventBridge 시작하기](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html)를 참조하세요.
```
{
"source": [
"aws.ecs"
],
"detail-type": [
"ECS Task State Change"
],
"detail": {
"clusterArn": [
"arn:aws:ecs:us-west-2:111122223333:cluster/default"
]
}
}
```
# Fargate 워크로드에 대한 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 클러스터에 필요한 리소스를 생성합니다.
콘솔은 Fargate 및 Fargate Spot 용량 공급자를 클러스터와 자동으로 연결합니다.
다음 옵션을 수정할 수 있습니다.
+ 클러스터에 네임스페이스를 추가합니다.
네임스페이스를 사용하면 클러스터에서 생성한 서비스를 추가 구성 없이 네임스페이스의 다른 서비스에 연결할 수 있습니다. 자세한 내용은 [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 키 및 로깅을 구성합니다.
## 절차
**새 클러스터 생성(Amazon ECS 콘솔)**
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. (선택 사항) 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. (선택 사항) **암호화**에서 다음을 구성할 수 있습니다.
+ Fargate 임시 스토리지에서 데이터를 암호화합니다. **암호화**에서 **Fargate 임시 스토리지**에 Fargate 임시 스토리지 데이터를 암호화하는 데 사용할 AWS KMS 키의 ARN을 입력합니다.
+ 관리형 스토리지의 데이터를 암호화합니다. **암호화**에서 **관리형 스토리지**에 관리형 스토리지 데이터를 암호화하는 데 사용할 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)
# 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) 섹션을 참조하세요.
# 외부 인스턴스에 대한 Amazon ECS 클러스터
Amazon ECS Anywhere는 *외부 인스턴스*(예: 온프레미스 서버 또는 가상 머신(VM))을 Amazon ECS 클러스터에 등록하도록 지원합니다. 외부 인스턴스는 아웃바운드 트래픽 또는 프로세스 데이터를 생성하는 애플리케이션 실행에 최적화되어 있습니다. 애플리케이션에 인바운드 트래픽이 필요한 경우 Elastic Load Balancing 지원이 없기 때문에 이러한 워크로드를 실행하는 데 효율성이 떨어집니다. Amazon ECS는 외부 인스턴스에서 서비스를 생성하거나 태스크를 실행하는 데 사용할 수 있는 새로운 `EXTERNAL` 시작 유형을 추가했습니다.
## 지원되는 운영 체제 및 시스템 아키텍처
지원되는 운영 체제의 목록은 다음과 같습니다. `x86_64` 및 `ARM64` CPU 아키텍처가 지원됩니다.
+ Amazon Linux 2023
+ Ubuntu 20, Ubuntu 22, Ubuntu 24
+ RHEL 9 — [ECS Anywhere 설치 스크립트](https://github.com/aws/amazon-ecs-agent/blob/master/scripts/ecs-anywhere-install.sh)를 실행하기 전에 Docker가 반드시 설치되어 있어야 합니다. 자세한 내용은 Docker 설명서의 [RHEL에 Docker 엔진 설치](https://docs.docker.com/engine/install/rhel/)를 참조하세요.
2026년 8월 7일부터 다음 운영 체제는 Amazon ECS Anywhere에서 더 이상 지원되지 않습니다.
+ Amazon Linux 2
+ CentOS Stream 9
+ RHEL 7, RHEL 8
+ Fedora 32, Fedora 33, Fedora 40
+ OpenSUSE Tumbleweed
+ Ubuntu 18
+ Debian 9, Debian 10, Debian 11, Debian 12
+ SUSE Enterprise Server 15
+ Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 20H2
## 고려 사항
외부 인스턴스를 사용하기 전에 다음 사항을 고려해야 합니다.
+ 한 번에 하나의 클러스터에 외부 인스턴스를 등록할 수 있습니다. 다른 클러스터에 외부 인스턴스를 등록하는 방법에 대한 지침은 [Amazon ECS 외부 인스턴스 등록 취소](ecs-anywhere-deregistration.md) 섹션을 참조하세요.
+ 외부 인스턴스에는 AWS API와 통신할 수 있도록 하는 IAM 역할이 필요합니다. 자세한 내용은 [Amazon ECS Anywhere IAM 역할](iam-role-ecsanywhere.md) 섹션을 참조하세요.
+ 외부 인스턴스에는 사전 구성된 인스턴스 자격 증명 체인이 로컬로 정의되어 있지 않아야 합니다. 정의된 경우 등록 스크립트에 방해가 될 수 있습니다.
+ 컨테이너 로그를 CloudWatch Logs로 보내려면 태스크 정의에 태스크 실행 IAM 역할을 생성하고 지정해야 합니다.
+ 외부 인스턴스가 클러스터에 등록되면 `ecs.capability.external` 속성은 인스턴스와 연결되어 있습니다. 이 속성은 인스턴스를 외부 인스턴스로 식별합니다. 외부 인스턴스에 사용자 지정 속성을 추가하여 작업 배치 제약 조건으로 사용할 수 있습니다. 자세한 정보는 [사용자 지정 속성](task-placement-constraints.md#ecs-custom-attributes) 섹션을 참조하세요.
+ 외부 인스턴스에 리소스 태그를 추가할 수 있습니다. 자세한 정보는 [Amazon ECS에 대한 외부 컨테이너 인스턴스에 태그 추가](instance-details-tags-external.md)을 참조하세요.
+ ECS Exec은 외부 인스턴스에서 지원됩니다. 자세한 정보는 [ECS Exec를 사용하여 Amazon ECS 컨테이너 모니터링](ecs-exec.md)을 참조하세요.
+ 외부 인스턴스와의 네트워킹과 관련된 추가 고려 사항은 다음과 같습니다. 자세한 정보는 [네트워킹](#ecs-anywhere-networking) 섹션을 참조하세요.
+ 서비스 로드 밸런싱은 지원되지 않습니다.
+ 서비스 검색은 지원되지 않습니다.
+ 외부 인스턴스에서 실행되는 태스크는 `bridge`, `host` 또는 `none` 네트워크 모드를 사용해야 합니다. `awsvpc` 네트워크 모드는 지원되지 않습니다.
+ 각 AWS 리전에 Amazon ECS 서비스 도메인이 있습니다. 외부 인스턴스로 트래픽을 보낼 수 있도록 이러한 서비스 도메인이 허용되어야 합니다.
+ 외부 인스턴스에 설치된 SSM Agent는 하드웨어 지문을 사용하여 30분마다 교체되는 IAM 자격 증명을 유지합니다. 외부 인스턴스와 AWS의 연결이 끊어지는 경우 SSM Agent는 연결이 다시 설정된 후 자격 증명을 자동으로 새로 고칩니다. 자세한 정보는 *AWS Systems Manager 사용 설명서*의 [하드웨어 지문을 사용하여 온프레미스 서버 및 가상 머신 유효성 검사](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation)를 참조하세요.
+ 인스턴스가 IPv6 전용 서브넷에 있는 한 IPv6 전용 구성의 외부 인스턴스에서 Linux 태스크를 실행할 수 있습니다. 자세한 내용은 [IPv6 전용 모드에서 VPC 사용](task-networking.md#networking-ipv6-only) 섹션을 참조하세요.
+ `UpdateContainerAgent` API는 지원되지 않습니다. 외부 인스턴스에서 SSM Agent 또는 Amazon ECS 에이전트를 업데이트하는 방법에 대한 지침은 [외부 인스턴스의 AWS Systems Manager 에이전트 및 Amazon ECS 컨테이너 에이전트 업데이트](ecs-anywhere-updates.md) 섹션을 참조하세요.
+ Amazon ECS 용량 공급자는 지원되지 않습니다. 외부 인스턴스에서 서비스를 생성하거나 독립 실행형 태스크를 실행하려면 `EXTERNAL` 시작 유형을 사용합니다.
+ SELinux는 지원되지 않습니다.
+ Amazon EFS 볼륨 사용이나 `EFSVolumeConfiguration` 지정은 지원되지 않습니다.
+ App Mesh와의 통합은 지원되지 않습니다.
+ 콘솔을 사용하여 외부 인스턴스 작업 정의를 생성하는 경우 콘솔 JSON 편집기로 작업 정의를 생성해야 합니다.
+ Amazon ECS 최적화가 아닌 AMI를 사용하는 경우 외부 컨테이너 인스턴스에서 다음 명령을 실행하여 작업에 IAM 역할을 사용하도록 규칙을 구성합니다. 자세한 내용은 [외부 인스턴스 추가 구성](task-iam-roles.md#enable_task_iam_roles) 섹션을 참조하세요.
```
$ sysctl -w net.ipv4.conf.all.route_localnet=1
$ iptables -t nat -A PREROUTING -p tcp -d 169.254.170.2 --dport 80 -j DNAT --to-destination 127.0.0.1:51679
$ iptables -t nat -A OUTPUT -d 169.254.170.2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 51679
```
### 네트워킹
Amazon ECS 외부 인스턴스는 아웃바운드 트래픽 또는 프로세스 데이터를 생성하는 애플리케이션 실행에 최적화되어 있습니다. 애플리케이션에 웹 서비스와 같은 인바운드 트래픽이 필요한 경우 Elastic Load Balancing 지원이 부족하여 이러한 워크로드를 로드 밸런서 뒤에 배치할 수 없기 때문에 이러한 워크로드를 실행하는 데 효율성이 떨어집니다.
외부 인스턴스와의 네트워킹과 관련된 추가 고려 사항은 다음과 같습니다.
+ 서비스 로드 밸런싱은 지원되지 않습니다.
+ 서비스 검색은 지원되지 않습니다.
+ 외부 인스턴스에서 실행되는 Linux 태스크는 `bridge`, `host` 또는 `none` 네트워크 모드를 사용해야 합니다. `awsvpc` 네트워크 모드는 지원되지 않습니다.
각 네트워크 모드에 대한 자세한 내용은 [EC2 인스턴스에 대한 Amazon ECS 태스크 네트워킹 옵션](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html)을 참조하세요.
+ 인스턴스가 IPv6 전용 서브넷에 있는 한 IPv6 전용 구성의 외부 인스턴스에서 Linux 태스크를 실행할 수 있습니다. 자세한 내용은 [IPv6 전용 모드에서 VPC 사용](task-networking.md#networking-ipv6-only) 섹션을 참조하세요.
+ 각 리전에 Amazon ECS 서비스 도메인이 있으며 외부 인스턴스로 트래픽을 보낼 수 있도록 허용해야 합니다.
+ 외부 인스턴스에 설치된 SSM Agent는 하드웨어 지문을 사용하여 30분마다 교체되는 IAM 자격 증명을 유지합니다. 외부 인스턴스와 AWS의 연결이 끊어지는 경우 SSM Agent는 연결이 다시 설정된 후 자격 증명을 자동으로 새로 고칩니다. 자세한 정보는 *AWS Systems Manager 사용 설명서*의 [하드웨어 지문을 사용하여 온프레미스 서버 및 가상 머신 유효성 검사](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation)를 참조하세요.
다음 도메인은 Amazon ECS 서비스와 외부 인스턴스에 설치된 Amazon ECS 에이전트 간의 통신에 사용됩니다. 트래픽이 허용되고 DNS 확인이 작동하는지 확인합니다. 각 엔드포인트의 *리전*은 미국 동부(오하이오) 리전의 `us-east-2`와 같이 Amazon ECS가 지원하는 AWS 리전의 리전 식별자를 나타냅니다. 사용하는 모든 리전의 엔드포인트가 허용되어야 합니다. `ecs-a` 및 `ecs-t` 엔드포인트의 경우 별표를 포함해야 합니다(예: `ecs-a-*`).
+ `ecs-a-*.region.amazonaws.com` — 이 엔드포인트는 태스크를 관리할 때 사용됩니다.
+ `ecs-t-*.region.amazonaws.com` — 이 엔드포인트는 태스크 및 컨테이너 지표를 관리하는 데 사용됩니다.
+ `ecs.region.amazonaws.com` — Amazon ECS의 서비스 엔드포인트입니다.
+ `ssm.region.amazonaws.com ` - AWS Systems Manager의 서비스 엔드포인트입니다.
+ `ec2messages.region.amazonaws.com` - AWS Systems Manager에서 클라우드의 Systems Manager 에이전트와 Systems Manager 서비스 간에 통신하는 데 사용하는 서비스 엔드포인트입니다.
+ `ssmmessages.region.amazonaws.com` - 이 서비스 엔드포인트는 클라우드의 Session Manager 서비스를 사용하여 세션 채널을 생성하고 삭제하는 데 필요합니다.
+ 태스크에 다른 AWS 서비스와의 통신이 필요한 경우 해당 서비스 엔드포인트가 허용되는지 확인합니다. 예제 애플리케이션으로는 Amazon ECR을 사용하여 컨테이너 이미지를 가져오거나 CloudWatch 로그에 대해 CloudWatch를 사용하는 것이 있습니다. 자세한 정보는 *AWS 일반 참조*의 [서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)를 참조하세요.
### Amazon FSx for Windows File Server와 ECS Anywhere
**중요**
Amazon ECS Anywhere에 대한 Windows 지원은 사용 중단되었습니다. 이 섹션은 더 이상 적용되지 않습니다.
Amazon ECS 외부 인스턴스와 함께 Amazon FSx for Windows File Server를 사용하려면 온프레미스 데이터 센터와 AWS 클라우드 간에 연결을 설정해야 합니다. VPC에 네트워크를 연결하는 옵션에 대한에 대한 자세한 정보는 [Amazon Virtual Private Cloud Connectivity Options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)(Amazon Virtual Private Cloud 연결 옵션)를 참조하세요.
### gMSA와 ECS Anywhere
**중요**
Amazon ECS Anywhere에 대한 Windows 지원은 사용 중단되었습니다. 이 섹션은 더 이상 적용되지 않습니다.
다음은 Windows가 지원되는 운영 체제였을 당시 Amazon ECS Anywhere에서 지원되던 사용 사례입니다.
+ Active Directory가 AWS 클라우드에 있음 - 이 구성의 경우 AWS Direct Connect 연결을 사용하여 온프레미스 네트워크와 AWS 클라우드 간에 연결을 생성합니다. 연결을 생성하는 방법에 대한 자세한 정보는 [Amazon Virtual Private Cloud 연결 옵션](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)을 참조하세요. AWS 클라우드에서 Active Directory를 생성합니다. AWS Directory Service를 시작하는 방법에 대한 자세한 정보는 *AWS Directory Service 관리 안내서*의 [AWS Directory Service 설정](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/setting_up.html)을 참조하세요. 그런 다음 AWS Direct Connect 연결을 사용하여 외부 인스턴스를 도메인에 조인할 수 있습니다. Amazon ECS에서 gMSA 작업에 대한 자세한 정보는 [Amazon ECS의 EC2 Windows 컨테이너에 대해 gMSA를 사용하는 방법 알아보기](windows-gmsa.md) 섹션을 참조하세요.
+ Active Directory는 온프레미스 데이터 센터에 있습니다. - 이 구성의 경우 외부 인스턴스를 온프레미스 Active Directory에 조인합니다. 그런 다음 Amazon ECS 태스크를 실행할 때 로컬에서 사용 가능한 자격 증명을 사용합니다.
# 외부 인스턴스 워크로드에 대한 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 ECS 서비스 상호 연결](interconnecting-services.md) 섹션을 참조하세요.
+ 외부 인스턴스에 대한 클러스터를 구성합니다.
+ 관리형 스토리지에 AWS KMS 키를 할당합니다. 키 생성 방법에 대한 자세한 내용은 *AWS Key Management Service 사용 설명서*의 [KMS 키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)을 참조하세요.
+ 클러스터를 식별하는 데 도움이 되는 태그를 추가합니다.
**새 클러스터 생성(Amazon ECS 콘솔)**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 모음에서 사용할 리전을 선택합니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터(Clusters)** 페이지에서 **클러스터 생성(Create cluster)**을 선택합니다.
1. **클러스터 구성**에서 다음을 구성합니다.
+ **클러스터 이름**에 고유한 이름을 입력합니다.
이름은 최대 255자(대/소문자), 숫자 및 하이픈을 포함할 수 있습니다.
+ (선택 사항) 서비스 연결에 사용되는 네임스페이스를 클러스터 이름과 다르게 하려면 **네임스페이스**에 고유한 이름을 입력합니다.
1. (선택 사항) Container Insights를 사용하고 **모니터링**을 확장한 후에 다음 옵션 중 하나를 선택합니다.
+ 권장되는 관찰성이 향상된 Container Insights를 사용하려면 **관찰성이 향상된 Container Insights**를 선택합니다.
+ Container Insights를 사용하려면 **Container Insights**를 선택합니다.
1. (선택 사항) ECS Exec을 사용하여 클러스터의 태스크를 디버깅하려면 **문제 해결 구성**을 확장한 후 다음을 구성합니다.
+ **ECS Exec 켜기**를 선택합니다.
+ (선택 사항) **ECS Exec용 AWS KMS 키**에 ECS Exec 세션 데이터를 암호화하는 데 사용할 AWS KMS 키의 ARN을 입력합니다.
+ (선택 사항) **ECS Exec 로깅**에서 로그 대상을 선택합니다.
+ CloudWatch Logs로 로그를 보내려면 **Amazon CloudWatch**를 선택합니다.
+ Amazon S3로 로그를 보내려면 **Amazon S3**를 선택합니다.
+ 로깅을 비활성화하려면 **없음**을 선택합니다.
1. (선택 사항) 관리형 스토리지의 데이터를 암호화합니다. **암호화**에서 **관리형 스토리지**에 관리형 스토리지 데이터를 암호화하는 데 사용할 AWS KMS 키의 ARN을 입력합니다.
1. (선택 사항) 클러스터를 식별하려면 **태그(Tags)**를 펼친 다음, 태그를 구성합니다.
[태그 추가] **태그 추가(Add tag)**를 선택하고 다음을 수행합니다.
+ **키(Key)**에 키 이름을 입력합니다.
+ **값**에 키 값을 입력합니다.
1. **생성(Create)**을 선택합니다.
## 다음 단계
클러스터에 인스턴스를 등록해야 합니다. 자세한 내용은 [Amazon ECS 클러스터에 외부 인스턴스 등록](ecs-anywhere-registration.md) 섹션을 참조하세요.
외부 시작 유형에 대한 태스크 정의를 생성합니다. 자세한 내용은 [콘솔을 사용하여 Amazon ECS 작업 정의 생성](create-task-definition.md) 섹션을 참조하세요.
애플리케이션을 독립 실행형 태스크 또는 서비스의 일부로 실행합니다. 자세한 내용은 다음을 참조하세요.
+ [애플리케이션을 Amazon ECS 태스크로 실행](standalone-task-create.md)
+ [Amazon ECS 롤링 업데이트 배포 생성](create-service-console-v2.md)
# Amazon ECS 클러스터에 외부 인스턴스 등록
Amazon ECS 클러스터에 등록하는 각 외부 인스턴스에 대해 SSM Agent, Amazon ECS 컨테이너 에이전트 및 Docker가 설치되어 있어야 합니다. Amazon ECS 클러스터에 외부 인스턴스를 등록하려면 먼저 AWS Systems Manager 관리형 인스턴스로 등록되어야 합니다. Amazon ECS 콘솔에서 몇 번의 클릭만으로 설치 스크립트를 생성할 수 있습니다. 설치 스크립트에는 Systems Manager 활성화 키와 필요한 에이전트 및 Docker를 각각 설치하는 명령이 포함되어 있습니다. 설치 및 등록 단계를 완료하려면 온프레미스 서버 또는 VM에서 설치 스크립트를 실행해야 합니다.
**참고**
클러스터에 외부 인스턴스를 등록하기 전에 Linux 외부 인스턴스에 `/etc/ecs/ecs.config` 파일을 열고 생성하고 원하는 컨테이너 에이전트 구성 파라미터를 추가합니다. 외부 인스턴스를 클러스터에 등록한 후에는 이 태스크를 수행할 수 없습니다. 자세한 내용은 [Amazon ECS 컨테이너 에이전트 구성](ecs-agent-config.md) 섹션을 참조하세요.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 모음에서 사용할 리전을 선택합니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터** 페이지에서 외부 인스턴스를 등록할 클러스터를 선택합니다.
1. **클러스터: *name*(Cluster : name)** 페이지에서 **인프라(Infrastructure)** 탭을 선택합니다.
1. **외부 인스턴스 등록(Register external instances)** 페이지에서 다음 단계를 수행합니다.
1. **활성화 키 기간(일)(Activation key duration (in days))**에 활성화 키가 활성 상태로 유지되는 일수를 입력합니다. 입력한 일수가 경과하면 외부 인스턴스를 등록할 때 키가 더 이상 작동하지 않습니다.
1. **인스턴스 개수(Number of instances)**에 활성화 키를 사용하여 클러스터에 등록할 외부 인스턴스 수를 입력합니다.
1. **인스턴스 역할(Instance role**에서 외부 인스턴스와 연결할 IAM 역할을 선택합니다. 역할이 아직 생성되지 않은 경우 **새 역할 생성(Create new role)**을 선택하여 Amazon ECS가 사용자를 대신하여 역할을 생성하도록 합니다. 외부 인스턴스에 필요한 IAM 권한에 대한 자세한 정보는 [Amazon ECS Anywhere IAM 역할](iam-role-ecsanywhere.md) 섹션을 참조하세요.
1. 등록 명령을 복사합니다. 이 명령은 클러스터에 등록하려는 각 외부 인스턴스에서 실행해야 합니다.
**중요**
스크립트의 bash 부분은 루트로 실행해야 합니다. 명령이 루트로 실행되지 않으면 오류가 반환됩니다.
1. **닫기**를 선택하세요.
------
#### [ AWS CLI for Linux operating systems ]
1. Systems Manager 정품 인증 쌍을 생성합니다. 이것은 Systems Manager 관리형 인스턴스 정품 인증에 사용됩니다. 출력에는 `ActivationId` 및 `ActivationCode`가 포함됩니다. 이것은 이후 단계에서 사용하게 됩니다. 생성한 ECS Anywhere IAM 역할을 지정해야 합니다. 자세한 내용은 [Amazon ECS Anywhere IAM 역할](iam-role-ecsanywhere.md) 섹션을 참조하세요.
```
aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
```
1. 온프레미스 서버 또는 가상 머신(VM)에서 설치 스크립트를 다운로드합니다.
```
curl --proto "https" -o "/tmp/ecs-anywhere-install.sh" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh"
```
1. (선택 사항) 온프레미스 서버 또는 가상 머신(VM)에서 다음 단계를 통해 스크립트 서명 파일을 사용하여 설치 스크립트를 확인합니다.
1. GnuPG를 다운로드하고 설치합니다. GNUpg에 대한 자세한 정보는 [GnuPG 웹 사이트](https://www.gnupg.org)를 참조하세요. Linux 시스템의 경우 원하는 Linux 패키지 관리자를 사용하여 `gpg`를 설치합니다.
1. Amazon ECS PGP 퍼블릭 키를 가져옵니다.
```
gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
```
1. 설치 스크립트 서명을 다운로드합니다. 서명은 `.asc` 확장자 파일에 저장된 ASCII 분리 PGP 서명입니다.
```
curl --proto "https" -o "/tmp/ecs-anywhere-install.sh.asc" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh.asc"
```
1. 키를 사용하여 설치 스크립트 파일을 확인합니다.
```
gpg --verify /tmp/ecs-anywhere-install.sh.asc /tmp/ecs-anywhere-install.sh
```
예상 출력은 다음과 같습니다.
```
gpg: Signature made Tue 25 May 2021 07:16:29 PM UTC
gpg: using RSA key 50DECCC4710E61AF
gpg: Good signature from "Amazon ECS " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: F34C 3DDA E729 26B0 79BE AEC6 BCE9 D9A4 2D51 784F
Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB 346F 50DE CCC4 710E 61AF
```
1. 온프레미스 서버 또는 가상 머신(VM)에서 설치 스크립트를 실행합니다. 첫 번째 단계에서 클러스터 이름, 리전 및 Systems Manager 정품 인증 ID 및 정품 인증 코드를 지정합니다.
```
sudo bash /tmp/ecs-anywhere-install.sh \
--region $REGION \
--cluster $CLUSTER_NAME \
--activation-id $ACTIVATION_ID \
--activation-code $ACTIVATION_CODE
```
GPU 워크로드용으로 NVIDIA 드라이버가 설치된 온프레미스 서버 또는 가상 머신(VM)의 경우 `--enable-gpu` 플래그를 설치 스크립트에 추가해야 합니다. 이 플래그가 지정되면 설치 스크립트에서 NVIDIA 드라이버가 실행 중인지 확인한 다음 Amazon ECS 태스크를 실행하는 데 필요한 구성 변수를 추가합니다. GPU 워크로드 실행 및 태스크 정의에서 GPU 요구 사항 지정에 대한 자세한 정보는 [Amazon ECS 작업 정의에서 GPU 지정](ecs-gpu-specifying.md) 섹션을 참조하세요.
```
sudo bash /tmp/ecs-anywhere-install.sh \
--region $REGION \
--cluster $CLUSTER_NAME \
--activation-id $ACTIVATION_ID \
--activation-code $ACTIVATION_CODE \
--enable-gpu
```
다음 단계를 사용하여 기존 외부 인스턴스를 다른 클러스터에 등록합니다.
**기존 외부 인스턴스를 다른 클러스터에 등록하려면**
1. Amazon ECS 컨테이너 에이전트를 중지합니다.
```
sudo systemctl stop ecs.service
```
1. `/etc/ecs/ecs.config` 파일을 편집하고 `ECS_CLUSTER` 행에서 클러스터 이름이 외부 인스턴스를 등록할 클러스터의 이름과 일치하는지 확인합니다.
1. 기존 Amazon ECS 에이전트 데이터를 제거합니다.
```
sudo rm /var/lib/ecs/data/agent.db
```
1. Amazon ECS 컨테이너 에이전트를 시작합니다.
```
sudo systemctl start ecs.service
```
------
#### [ AWS CLI for Windows operating systems ]
1. Systems Manager 정품 인증 쌍을 생성합니다. 이것은 Systems Manager 관리형 인스턴스 정품 인증에 사용됩니다. 출력에는 `ActivationId` 및 `ActivationCode`가 포함됩니다. 이것은 이후 단계에서 사용하게 됩니다. 생성한 ECS Anywhere IAM 역할을 지정해야 합니다. 자세한 내용은 [Amazon ECS Anywhere IAM 역할](iam-role-ecsanywhere.md) 섹션을 참조하세요.
```
aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
```
1. 온프레미스 서버 또는 가상 머신(VM)에서 설치 스크립트를 다운로드합니다.
```
Invoke-RestMethod -URI "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install.ps1" -OutFile “ecs-anywhere-install.ps1”
```
1. (선택 사항) PowerShell 스크립트는 Amazon에서 서명하므로 Windows에서 자동으로 인증서 검증을 수행합니다. 수동 검증을 수행할 필요가 없습니다.
인증서를 수동으로 확인하려면 파일을 마우스 오른쪽 버튼으로 클릭하고 속성으로 이동한 다음 디지털 서명(Digital Signatures) 탭을 사용하여 자세한 정보를 확인합니다.
이 옵션은 호스트의 인증서 스토어에 인증서가 있는 경우에만 사용할 수 있습니다.
다음과 비슷한 정보가 반환됩니다.
```
# Verification (PowerShell)
Get-AuthenticodeSignature -FilePath .\ecs-anywhere-install.ps1
SignerCertificate Status Path
----------------- ------ ----
EXAMPLECERTIFICATE Valid ecs-anywhere-install.ps1
...
Subject : CN="Amazon Web Services, Inc.",...
----
```
1. 온프레미스 서버 또는 가상 머신(VM)에서 설치 스크립트를 실행합니다. 첫 번째 단계에서 클러스터 이름, 리전 및 Systems Manager 정품 인증 ID 및 정품 인증 코드를 지정합니다.
```
.\ecs-anywhere-install.ps1 -Region $Region -Cluster $Cluster -ActivationID $ActivationID -ActivationCode $ActivationCode
```
1. Amazon ECS 컨테이너 에이전트가 실행 중인지 확인합니다.
```
Get-Service AmazonECS
Status Name DisplayName
------ ---- -----------
Running AmazonECS Amazon ECS
```
다음 단계를 사용하여 기존 외부 인스턴스를 다른 클러스터에 등록합니다.
**기존 외부 인스턴스를 다른 클러스터에 등록하려면**
1. Amazon ECS 컨테이너 에이전트를 중지합니다.
```
Stop-Service AmazonECS
```
1. 클러스터 이름이 외부 인스턴스를 등록할 클러스터 이름과 일치하도록 `ECS_CLUSTER` 파라미터를 수정합니다.
```
[Environment]::SetEnvironmentVariable("ECS_CLUSTER", $ECSCluster, [System.EnvironmentVariableTarget]::Machine)
```
1. 기존 Amazon ECS 에이전트 데이터를 제거합니다.
```
Remove-Item -Recurse -Force $env:ProgramData\Amazon\ECS\data\*
```
1. Amazon ECS 컨테이너 에이전트를 시작합니다.
```
Start-Service AmazonECS
```
------
외부 인스턴스 등록 프로세스를 완료하기 위해 설치 스크립트를 실행하기 전에 AWS CLI를 사용하여 Systems Manager 정품 인증을 생성할 수 있습니다.
# Amazon ECS 외부 인스턴스 등록 취소
인스턴스 사용을 마친 후에 Amazon ECS 및 AWS Systems Manager 모두에서 인스턴스를 등록 취소하는 것이 좋습니다. 등록 취소 후 외부 인스턴스는 더 이상 새 태스크를 받을 수 없습니다.
등록 취소 시 컨테이너 인스턴스에서 실행 중인 태스크가 있는 경우, 이러한 태스크는 다른 수단을 통해 중지될 때까지 계속 실행됩니다. 그러나 이러한 태스크는 Amazon ECS에서 더 이상 모니터링하거나 고려하지 않습니다. 외부 인스턴스의 이러한 태스크가 Amazon ECS 서비스의 일부인 경우, 서비스 스케줄러는 가능하다면 다른 인스턴스에서 해당 태스크의 다른 사본을 시작합니다.
인스턴스를 등록 취소한 후 인스턴스에서 남은 AWS 리소스를 정리합니다. 그런 다음, 새 클러스터에 등록할 수 있습니다.
## 절차
------
#### [ AWS Management 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)**에서 등록 취소하려는 외부 인스턴스 ID를 선택합니다. 컨테이너 인스턴스 세부 정보 페이지로 리디렉션됩니다.
1. **컨테이너 인스턴스 : *id*** 페이지에서 **등록 취소(Deregister)**를 선택합니다.
1. 등록 취소 메시지를 검토합니다. **AWS Systems Manager에서 등록 취소(Deregister from SYSlong)**를 선택하여 외부 인스턴스를 Systems Manager 관리형 인스턴스로 등록 취소할 수도 있습니다. **등록 취소(Deregister)**를 선택합니다.
**참고**
Systems Manager 콘솔에서 외부 인스턴스를 Systems Manager 관리형 인스턴스로 등록 취소할 수 있습니다. 지침은 *AWS Systems Manager 사용 설명서*의 [하이브리드 및 멀티클라우드 환경의 관리형 노드 등록 취소](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-deregister-hybrid-nodes.html)를 참조하세요.
1. 인스턴스를 등록 취소한 후 온프레미스 서버 또는 VM에서 AWS 리소스를 정리하세요.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)
------
#### [ AWS CLI ]
1. 컨테이너 인스턴스를 등록 취소하려면 인스턴스 ID와 컨테이너 인스턴스 ARN이 필요합니다. 이러한 값이 없는 경우 다음 명령을 실행합니다.
다음 명령을 실행하여 인스턴스 ID를 가져옵니다.
인스턴스 ID(`instanceID`)를 사용하여 컨테이너 인스턴스 ARN(`containerInstanceARN`)을 가져옵니다.
```
instanceId=$(aws ssm describe-instance-information --region "{{ region }}" | jq ".InstanceInformationList[] |select(.IPAddress==\"{{ IPv4 Address }}\") | .InstanceId" | tr -d'"'
```
다음 명령을 실행합니다.
`containerInstanceArn`을 명령의 파라미터로 사용하여 인스턴스 등록을 취소합니다(`deregister-container-instance`).
```
instances=$(aws ecs list-container-instances --cluster "{{ cluster }}" --region "{{ region }}" | jq -c '.containerInstanceArns')
containerInstanceArn=$(aws ecs describe-container-instances --cluster "{{ cluster }}" --region "{{ region }}" --container-instances $instances | jq ".containerInstances[] | select(.ec2InstanceId==\"{{ instanceId }}\") | .containerInstanceArn" | tr -d '"')
```
1. 다음 명령을 실행하여 인스턴스를 드레이닝합니다.
```
aws ecs update-container-instances-state --cluster "{{ cluster }}" --region "{{ region }}" --container-instances "{{ containerInstanceArn }}" --status DRAINING
```
1. 컨테이너 인스턴스의 드레이닝이 완료되면 다음 명령을 실행하여 인스턴스 등록을 취소합니다.
```
aws ecs deregister-container-instance --cluster "{{ cluster }}" --region "{{ region }}" --container-instance "{{ containerInstanceArn }}"
```
1. 다음 명령을 사용하여 SSM에서 인스턴스를 제거합니다.
```
aws ssm deregister-managed-instance --region "{{ region }}" --instance-id "{{ instanceId }}"
```
1. 인스턴스를 등록 취소한 후 온프레미스 서버 또는 VM에서 AWS 리소스를 정리하세요.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)
------
# 외부 인스턴스의 AWS Systems Manager 에이전트 및 Amazon ECS 컨테이너 에이전트 업데이트
온프레미스 서버 또는 VM은 Amazon ECS 워크로드를 실행할 때 AWS Systems Manager 에이전트(SSM Agent) 및 Amazon ECS 컨테이너 에이전트를 모두 실행해야 합니다. AWS는 기능이 추가되거나 업데이트될 때 이러한 에이전트의 새 버전을 릴리스합니다. 외부 인스턴스에서 이전 버전의 에이전트를 사용하는 경우 다음 절차에 따라 에이전트를 업데이트할 수 있습니다.
## 외부 인스턴스에서 SSM Agent 업데이트
AWS Systems Manager는 인스턴스에서 SSM Agent를 업데이트하는 프로세스를 자동화하는 것이 좋습니다. 업데이트를 자동화하는 몇 가지 방법이 있습니다. 자세한 정보는 *AWS Systems Manager 사용 설명서*의 [SSM Agent 업데이트 자동화](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-automatic-updates.html)를 참조하세요.
## 외부 인스턴스에서 Amazon ECS 에이전트 업데이트
외부 인스턴스에서 `ecs-init` 패키지를 업그레이드하여 Amazon ECS 컨테이너 에이전트를 업데이트합니다. Amazon ECS 에이전트를 업데이트해도 실행 중인 태스크나 서비스가 중단되지 않습니다. Amazon ECS는 각 리전의 Amazon S3 버킷에 `ecs-init` 패키지와 서명 파일을 제공합니다. `ecs-init` 버전 `1.52.1-1`을 시작할 때 Amazon ECS는 외부 인스턴스에서 사용하는 운영 체제 및 시스템 아키텍처에 따라 사용할 수 있는 별도의 `ecs-init` 패키지를 제공합니다.
다음 표를 사용하여 외부 인스턴스에서 사용하는 운영 체제 및 시스템 아키텍처를 기반으로 다운로드해야 하는 `ecs-init` 패키지를 결정합니다.
**참고**
다음 명령을 사용하여 외부 인스턴스에서 사용하는 운영 체제 및 시스템 아키텍처를 결정할 수 있습니다.
```
cat /etc/os-release
uname -m
```
| 운영 체제(아키텍처) | ecs-init 패키지 |
| --- | --- |
| CentOS 7(x86\$164) CentOS 8(x86\$164) CentOS Stream 9(x86\$164) SUSE Enterprise Server 15(x86\$164) RHEL 7(x86\$164) RHEL 8 (x86\$164) | `amazon-ecs-init-latest.x86_64.rpm` |
| CentOS 7(aarch64) CentOS 8(aarch64) CentOS Stream 9(aarch64) RHEL 7(aarch64) | `amazon-ecs-init-latest.aarch64.rpm` |
| Debian 9(x86\$164) Debian 10(x86\$164) Debian 11(x86\$164) Debian 12(x86\$164) Ubuntu 18(x86\$164) Ubuntu 20(x86\$164) Ubuntu 22(x86\$164) Ubuntu 24(x86\$164) | `amazon-ecs-init-latest.amd64.deb` |
| Debian 9(aarch64) Debian 10(aarch64) Debian 11(aarch64) Debian 12(aarch64) Ubuntu 18(aarch64) Ubuntu 20(aarch64) Ubuntu 22(aarch64) Ubuntu 24(aarch64) | `amazon-ecs-init-latest.arm64.deb` |
Amazon ECS 에이전트를 업데이트하려면 다음 단계를 따르세요.
**Amazon ECS 에이전트를 업데이트하려면**
1. 실행 중인 Amazon ECS 에이전트 버전을 확인합니다.
```
curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
```
1. 운영 체제 및 시스템 아키텍처에 맞는 `ecs-init` 패키지를 다운로드합니다. Amazon ECS는 각 리전의 Amazon S3 버킷에 `ecs-init` 패키지 파일을 제공합니다. 명령의 ** 식별자를 지리적으로 가장 가까운 리전 이름(예: `us-west-2`)으로 교체했는지 확인합니다.
**amazon-ecs-init-latest.x86\$164.rpm**
```
curl -o amazon-ecs-init.rpm https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.x86_64.rpm
```
**amazon-ecs-init-latest.aarch64.rpm**
```
curl -o amazon-ecs-init.rpm https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.aarch64.rpm
```
**amazon-ecs-init-latest.amd64.deb**
```
curl -o amazon-ecs-init.deb https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.amd64.deb
```
**amazon-ecs-init-latest.arm64.deb**
```
curl -o amazon-ecs-init.deb https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.arm64.deb
```
1. (선택 사항) PGP 서명을 사용하여 `ecs-init` 패키지 파일을 유효성을 확인합니다.
1. GnuPG를 다운로드하고 설치합니다. GNUpg에 대한 자세한 정보는 [GnuPG 웹 사이트](https://www.gnupg.org)를 참조하세요. Linux 시스템의 경우 원하는 Linux 패키지 관리자를 사용하여 `gpg`를 설치합니다.
1. Amazon ECS PGP 퍼블릭 키를 가져옵니다.
```
gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
```
1. `ecs-init` 패키지 서명을 다운로드합니다. 서명은 `.asc` 확장자 파일에 저장된 ASCII 분리 PGP 서명입니다. Amazon ECS는 각 리전의 Amazon S3 버킷에 서명 파일을 제공합니다. 명령의 ** 식별자를 지리적으로 가장 가까운 리전 이름(예: `us-west-2`)으로 교체했는지 확인합니다.
**amazon-ecs-init-latest.x86\$164.rpm**
```
curl -o amazon-ecs-init.rpm.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.x86_64.rpm.asc
```
**amazon-ecs-init-latest.aarch64.rpm**
```
curl -o amazon-ecs-init.rpm.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.aarch64.rpm.asc
```
**amazon-ecs-init-latest.amd64.deb**
```
curl -o amazon-ecs-init.deb.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.amd64.deb.asc
```
**amazon-ecs-init-latest.arm64.deb**
```
curl -o amazon-ecs-init.deb.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.arm64.deb.asc
```
1. 키를 사용해 `ecs-init` 패키지 파일을 확인합니다.
**`rpm` 패키지의 경우**
```
gpg --verify amazon-ecs-init.rpm.asc ./amazon-ecs-init.rpm
```
**`deb` 패키지의 경우**
```
gpg --verify amazon-ecs-init.deb.asc ./amazon-ecs-init.deb
```
예상 출력은 다음과 같습니다.
```
gpg: Signature made Fri 14 May 2021 09:31:36 PM UTC
gpg: using RSA key 50DECCC4710E61AF
gpg: Good signature from "Amazon ECS " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: F34C 3DDA E729 26B0 79BE AEC6 BCE9 D9A4 2D51 784F
Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB 346F 50DE CCC4 710E 61AF
```
1. `ecs-init` 패키지를 설치합니다.
**CentOS 7, CentOS 8, RHEL 7의 `rpm` 패키지의 경우**
```
sudo yum install -y ./amazon-ecs-init.rpm
```
**SUSE Enterprise Server 15의 `rpm` 패키지의 경우**
```
sudo zypper install -y --allow-unsigned-rpm ./amazon-ecs-init.rpm
```
**`deb` 패키지의 경우**
```
sudo dpkg -i ./amazon-ecs-init.deb
```
1. `ecs` 서비스를 다시 시작합니다.
```
sudo systemctl restart ecs
```
1. Amazon ECS 에이전트 버전이 업데이트되었는지 확인합니다.
```
curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
```
# Amazon ECS 클러스터 업데이트
다음 클러스터 속성을 수정할 수 있습니다.
+ 기본 용량 공급자를 설정합니다.
각 클러스터에는 하나 이상의 용량 공급자와 하나의 선택적 용량 공급자 전략이 있을 수 있습니다. 용량 공급자 전략은 태스크가 클러스터의 용량 공급자에 분배되는 방식을 결정합니다. 표준 실행 작업을 실행하거나 서비스를 생성할 때 클러스터의 기본 용량 공급자 전략 또는 기본 전략을 재정의하는 용량 공급자 전략을 사용할 수 있습니다.
+ Container Insights를 설정합니다.
CloudWatch Container Insights는 컨테이너 애플리케이션 및 마이크로서비스의 지표 및 로그를 수집하고, 종합하며, 요약합니다. 또한 Container Insights는 컨테이너 재시작 오류 등의 진단 정보를 제공합니다. 이 정보를 사용하여 문제를 격리하고 신속하게 해결할 수 있습니다. 자세한 정보는 [관찰성이 향상된 Container Insights를 사용하여 Amazon ECS 컨테이너 모니터링](cloudwatch-container-insights.md)을 참조하세요.
+ 클러스터를 식별하는 데 도움이 되는 태그를 추가합니다.
**절차**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다.
1. **클러스터: *name*** 페이지에서 **클러스터 업데이트**를 선택합니다.
1. 기본 용량 공급자를 설정하려면 **기본 용량 공급자 전략**에서 **더 추가**를 선택합니다.
1. **용량 공급자**에서 용량 공급자를 선택합니다.
1. (선택 사항) **기본**에 용량 공급자에서 실행되는 최소 작업 수를 입력합니다.
**기본** 값은 하나의 용량 공급자에 대해서만 설정할 수 있습니다.
1. (선택 사항) **가중치**에 지정된 용량 공급자를 사용하는 시작된 총 작업 수의 상대 백분율을 입력합니다.
1. (선택 사항) 추가 용량 공급자가 있으면 단계를 반복합니다.
1. Container Insights를 켜겨나 끄려면 **모니터링**을 확장한 다음 **Container Insights 사용**을 켭니다.
1. 클러스터를 식별하려면 **태그**를 확장한 다음, 태그를 구성합니다.
[태그 추가] **태그 추가(Add tag)**를 선택하고 다음을 수행합니다.
+ **키(Key)**에 키 이름을 입력합니다.
+ **값**에 키 값을 입력합니다.
[태그 제거] 태그의 키와 값 오른쪽에 있는 **제거**를 선택합니다.
1. **업데이트**를 선택합니다.
# Amazon ECS 클러스터 삭제
클러스터 사용을 마치면 이를 삭제할 수 있습니다. 클러스터를 삭제하면 `INACTIVE` 상태로 전환됩니다. `INACTIVE` 상태인 클러스터는 일정 기간 동안 계정에서 검색 가능한 상태로 유지될 수 있습니다. 하지만 이 동작은 향후 변경될 수 있으므로 `INACTIVE` 클러스터가 지속되는 상태에 의존해서는 안 됩니다.
클러스터를 삭제하려면 다음 작업을 수행해야 합니다.
+ 클러스터의 모든 서비스를 삭제합니다. 자세한 내용은 [콘솔을 사용하여 Amazon ECS 서비스 삭제](delete-service-v2.md) 섹션을 참조하세요.
+ 현재 실행 중인 태스크를 모두 중지합니다. 자세한 내용은 [Amazon ECS 태스크 중지](standalone-task-stop.md) 섹션을 참조하세요.
+ 클러스터에 등록된 모든 컨테이너 인스턴스를 등록 취소합니다. 자세한 내용은 [Amazon ECS 컨테이너 인스턴스 등록 취소](deregister_container_instance.md) 섹션을 참조하세요.
+ 네임스페이스를 삭제합니다. 자세한 내용은 *AWS Cloud Map 개발자 안내서*의 [네임스페이스 삭제](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html)를 참조하세요.
**절차**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 모음에서 사용할 리전을 선택합니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터** 페이지에서 삭제할 클러스터를 선택합니다.
1. 페이지 오른쪽 상단에서 **클러스터 삭제**를 선택합니다.
클러스터와 연결된 모든 리소스를 삭제하지 않은 경우 메시지가 표시됩니다.
1. 확인란에 **delete *cluster name***를 입력합니다.
# Amazon ECS 컨테이너 인스턴스 등록 취소
**중요**
이 주제는 Amazon EC2에서 생성된 컨테이너 인스턴스에만 적용됩니다. 외부 인스턴스의 등록 취소에 대한 자세한 정보는 [Amazon ECS 외부 인스턴스 등록 취소](ecs-anywhere-deregistration.md) 섹션을 참조하세요.
Amazon EC2 지원 컨테이너 인스턴스 태스크를 마치면 클러스터에서 컨테이너 인스턴스 등록을 취소해야 합니다. 등록 취소 후 컨테이너 인스턴스는 더 이상 새 태스크를 받을 수 없습니다.
등록 취소 시 컨테이너 인스턴스에서 실행 중인 태스크가 있는 경우, 이러한 태스크는 인스턴스를 종료할 때까지 계속 실행되거나 몇 가지 다른 수단을 통해 중지됩니다. 그러나 이러한 태스크는 분리되어 Amazon ECS에서 더 이상 모니터링하거나 고려하지 않습니다. 컨테이너 인스턴스에서 분리된 태스크가 Amazon ECS 서비스의 일부인 경우, 서비스 스케줄러는 가능하다면 다른 컨테이너 인스턴스에서 해당 태스크의 다른 사본을 시작합니다. Application Load Balancer 대상 그룹에 등록된 분리된 서비스 작업의 모든 컨테이너의 등록이 취소됩니다. 이러한 컨테이너는 로드 밸런서 또는 대상 그룹에서의 설정에 따라 Connection Draining을 시작합니다. 분리된 작업이 `awsvpc` 네트워크 모드를 사용 중인 경우 탄력적 네트워크 인터페이스가 삭제됩니다.
등록 취소 후 컨테이너 인스턴스를 다른 목적으로 사용하려는 경우, 등록 취소 전에 컨테이너 인스턴스에서 실행 중인 모든 태스크를 중지해야 합니다. 이렇게 하면 분리된 태스크가 리소스를 소모하는 것을 방지합니다.
컨테이너 인스턴스의 등록을 취소할 때는 다음 사항을 고려해야 합니다.
+ 각각의 컨테이너 인스턴스에는 고유의 상태 정보가 있기 때문에 클러스터에서 등록을 취소하고 다른 클러스터에 다시 등록해서는 안 됩니다. 컨테이너 인스턴스 리소스의 위치를 바꾸려면 클러스터에서 컨테이너 인스턴스를 종료한 다음, 새 클러스터에서 새 컨테이너 인스턴스를 시작하는 것이 좋습니다. 자세한 내용은 **Amazon EC2 사용 설명서의 [인스턴스 종료](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) 및 [Amazon ECS Linux 컨테이너 인스턴스 시작](launch_container_instance.md) 섹션을 참조하세요.
+ 컨테이너 인스턴스를 Auto Scaling 그룹 또는CloudFormation 스택에서 관리하는 경우, Auto Scaling 그룹 또는 CloudFormation 스택을 업데이트하여 인스턴스를 종료합니다. 그렇지 않은 경우 사용자가 인스턴스를 종료한 후 Auto Scaling 그룹 또는 CloudFormation이 새 인스턴스를 생성합니다.
+ Amazon ECS 컨테이너 에이전트가 연결된 상태로 실행 중인 컨테이너 인스턴스를 종료하는 경우, 에이전트는 자동으로 인스턴스를 클러스터에서 등록 취소합니다. 에이전트 연결이 끊긴 상태로 중지된 컨테이너 인스턴스 또는 인스턴스는 종료 시 자동으로 등록 취소되지 않습니다.
+ 컨테이너 인스턴스의 등록을 취소하면 클러스터에서 인스턴스는 제거되지만 Amazon EC2 인스턴스는 종료되지 않습니다. 인스턴스 사용이 끝나면 인스턴스를 종료해 요금이 청구되지 않도록 해야 합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 종료](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html)를 참조하세요.
## 절차
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)**에서 등록 취소하려는 인스턴스 ID를 선택합니다. 컨테이너 인스턴스 세부 정보 페이지로 리디렉션됩니다.
1. **컨테이너 인스턴스 : *id*** 페이지에서 **등록 취소(Deregister)**를 선택합니다.
1. 확인 화면에서 **Deregister**(등록 취소)를 선택합니다.
1. 컨테이너 인스턴스 작업이 완료되면 기본 Amazon EC2 인스턴스를 종료합니다. 자세한 내용은 **Amazon EC2 사용 설명서의 [인스턴스 종료](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html)를 참조하세요.
# Amazon ECS 컨테이너 인스턴스 드레이닝
예를 들어 시스템 업데이트를 수행하거나 클러스터 용량을 스케일 다운하기 위해 클러스터에서 컨테이너 인스턴스를 제거해야 하는 경우가 있을 수 있습니다. Amazon ECS는 컨테이너 인스턴스를 `DRAINING` 상태로 전환할 수 있는 기능을 제공합니다. 이것을 *컨테이너 인스턴스 드레이닝*이라고 합니다. 컨테이너 인스턴스를 `DRAINING`으로 설정할 경우 Amazon ECS는 새 작업이 컨테이너 인스턴스에서 배치를 위해 예약되지 않도록 합니다.
## 서비스에 대한 드레이닝 동작
`PENDING` 상태에 있는 서비스의 일부인 모든 태스크가 즉시 중지됩니다. 클러스터에 사용 가능한 컨테이너 인스턴스 용량이 있는 경우 서비스 스케줄러는 교체 태스크를 시작합니다. 컨테이너 인스턴스 용량이 충분하지 않으면 문제를 나타내는 서비스 이벤트 메시지가 전송됩니다.
컨테이너 인스턴스에 있는 서비스의 일부인 `RUNNING` 상태의 태스크가 `STOPPED` 상태로 전환됩니다. 서비스 스케줄러는 서비스의 배포 유형 및 배포 구성 파라미터인 `minimumHealthyPercent` 및 `maximumPercent`에 따라 작업을 교체하려고 시도합니다. 자세한 내용은 [Amazon ECS 서비스](ecs_services.md) 및 [Amazon ECS 서비스 정의 파라미터](service_definition_parameters.md)(을)를 참조하세요.
+ 만약 `minimumHealthyPercent`가 100% 미만이면 스케줄러는 태스크 대체 도중 `desiredCount`를 일시적으로 무시할 수 있습니다. 예를 들어 `desiredCount`가 4개 작업인 경우, 50%의 최솟값은 스케줄러가 새로운 2개 태스크를 시작하기 전에 2개의 기존 태스크를 중지하도록 허용합니다. 최솟값이 100%인 경우, 서비스 스케줄러는 대체 태스크가 이 정상 상태라고 간주될 때까지 기존 태스크를 제거할 수 없습니다. 로드 밸런서를 사용하지 않는 서비스의 태스크는 `RUNNING` 상태일 경우에 정상 상태로 간주됩니다. 로드 밸런서를 사용하는 서비스의 태스크는 `RUNNING` 상태이고 태스크가 호스팅된 컨테이너 인스턴스가 로드 밸런서에 의해 정상 상태로 보고되는 경우에 정상 상태로 간주됩니다.
**중요**
Spot Instances를 사용하고 `minimumHealthyPercent`가 100% 이상인 경우 Spot Instance 종료 전에 서비스에서 작업을 교체할 시간이 충분하지 않습니다.
+ `maximumPercent` 파라미터는 작업 대체 도중 실행 중인 작업 수의 상한을 나타내며, 이를 통해 대체 배치 크기를 정의할 수 있습니다. 예를 들어 `desiredCount`가 4개 태스크인 경우, 200%의 최댓값은 드레이닝할 4개 태스크를 중지하기 전에 4개의 새 태스크를 시작합니다(이렇게 하는 데 필요한 클러스터 리소스를 사용할 수 있는 경우). 최댓값이 100%인 경우, 드레이닝 작업이 중지될 때까지 대체 태스크를 시작할 수 없습니다.
**중요**
`minimumHealthyPercent`와 `maximumPercent`가 모두 100%이면 서비스에서 기존 태스크를 제거할 수 없으며 교체 태스크도 시작할 수 없습니다. 그러면 컨테이너 인스턴스 드레이닝이 실패하고 새 배포가 만들어지지 않습니다.
## 독립 실행형 태스크에 대한 드레이닝 동작
`PENDING` 또는 `RUNNING` 상태의 모든 독립 실행형 태스크는 영향을 받지 않습니다. 스스로 중지할 때까지 기다리거나 수동으로 중지해야 합니다. 컨테이너 인스턴스는 `DRAINING` 상태를 유지합니다.
## Amazon ECS 관리형 인스턴스의 드레이닝 동작
Amazon ECS 관리형 인스턴스 종료는 비용을 최적화하고 시스템 상태를 유지 관리하면서 정상적인 워크로드 전환을 보장합니다. 종료 시스템은 인스턴스 종료에 대한 세 가지 결정 경로를 제공하며, 경로마다 타이밍 특성과 고객 영향 프로파일이 서로 다릅니다.
고객이 시작한 종료
서비스에서 컨테이너 인스턴스를 즉시 제거해야 하는 경우 인스턴스 제거를 직접 제어합니다. `force` 요청 파라미터가 true로 설정된 상태에서 `deregister-container-instance`을(를) 실행합니다. 이는 실행 중인 워크로드에 관계없이 즉각적인 종료가 필요함을 의미합니다.
시스템에서 시작한 유휴 종료
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)을 참조하세요.
종료 시스템은 인프라 관리 요구 사항과 워크로드 연속성의 균형을 맞추는 2단계 접근 방식을 구현합니다.
**1단계: 정상적 완료 기간**
이 단계에서 시스템은 워크로드 연속성을 우선하는 적절한 드레이닝 전략을 구현합니다. 서비스 태스크는 일반적인 Amazon ECS 예약 프로세스를 통해 정상적으로 드레이닝됩니다. 독립 실행형 태스크는 자연스럽게 완료될 수 있으므로 계속 실행됩니다. 시스템은 모든 태스크가 자연 완료 프로세스를 통해 중지 상태에 도달하는지 모니터링합니다.
**2단계: 엄격한 기한 적용**
정상적인 완료 시 허용 가능한 기간에 종료 목표를 달성하지 못하면 시스템은 엄격한 기한 적용을 구현합니다. 하드 기한은 일반적으로 드레이닝 시작 시간 \$1 7일로 설정되어 운영 요구 사항을 유지하면서 정상적으로 완료할 수 있는 상당한 시간을 제공합니다. 적용에는 자동 강제 등록 취소 절차와 완료 상태에 관계없이 나머지 모든 태스크의 즉각적인 종료가 포함됩니다.
컨테이너 인스턴스는 인스턴스에서 실행 중인 모든 태스크가 `STOPPED` 상태로 전환되면 드레이닝을 완료합니다. 컨테이너 인스턴스는 다시 활성화되거나 삭제될 때까지 `DRAINING` 상태를 유지합니다. `containerInstance` 파라미터와 함께 [ListTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ListTasks.html) 태스크를 사용하여 컨테이너 인스턴스에 있는 태스크의 상태를 확인하고, 상태를 확인할 각 태스크의 Amazon 리소스 이름(ARN) 또는 ID와 함께 [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) 태스크를 사용하여 인스턴스에 있는 태스크 목록을 가져옵니다.
컨테이너 인스턴스가 태스크를 다시 호스팅할 준비가 되면 컨테이너 인스턴스의 상태를 `DRAINING`에서 `ACTIVE`로 변경합니다. 그러면 Amazon ECS 서비스 스케줄러는 다시 태스크 배치에 대해 컨테이너 인스턴스를 고려합니다.
## 절차
다음 단계를 사용하여 컨테이너 인스턴스를 새 AWS Management Console을 사용한 드레이닝으로 설정할 수 있습니다.
[UpdateContainerInstancesState](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateContainerInstancesState.html) API 작업 또는 [update-container-instances-state](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-container-instances-state.html) 명령을 사용하여 컨테이너 인스턴스의 상태를 `DRAINING`으로 변경할 수도 있습니다.
**AWS Management Console**
1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다.
1. 탐색 창에서 **클러스터**를 선택합니다.
1. **클러스터(Clusters)**페이지에서 인스턴스를 호스팅하는 클러스터를 선택합니다.
1. **클러스터: *name*(Cluster : name)** 페이지에서 **인프라(Infrastructure)** 탭을 선택합니다. **컨테이너 인스턴스(Container instances)**에서 드레이닝할 각 컨테이너 인스턴스의 확인란을 선택합니다.
1. **Actions**(작업), **Drain**(드레이닝)을 차례로 선택합니다.
# Auto Scaling 그룹 외부에서 인스턴스 유형 또는 크기 변경
AWS에서는 인프라를 변경할 수 없도록 유지할 것을 권장합니다. 인스턴스 크기를 변경해야 하는 경우 다음 중 하나를 수행할 수 있습니다.
+ 수평적으로 조정하고 인스턴스를 더 추가합니다. 그런 다음 해당 인스턴스에 추가 태스크를 배치합니다. 또는
+ 더 크거나 작은 새 인스턴스를 시작하여 수직으로 조정한 다음 이전 인스턴스를 드레이닝합니다.
이 두 가지 접근 방식은 애플리케이션 가용성에 미치는 영향을 최소화하는 데 도움이 됩니다.
다른 방법을 사용하여 인스턴스를 변경한 경우 다음 오류가 발생할 수 있습니다.
```
Container instance type changes are not supported.
```
이 오류가 발생하면 다음 단계를 수행합니다.
1. 원하는 인스턴스 유형으로 새 인스턴스를 시작합니다.
1. 이전 인스턴스 유형을 드레이닝합니다. 자세한 내용은 [Amazon ECS 컨테이너 인스턴스 드레이닝](container-instance-draining.md) 섹션을 참조하세요.
# Amazon EC2 컨테이너 인스턴스
Amazon ECS 에이전트는 클러스터에 등록된 모든 컨테이너 인스턴스에서 실행되는 프로세스입니다. 컨테이너 인스턴스와 Amazon ECS 간의 통신을 용이하게 합니다.
**참고**
Linux 컨테이너 인스턴스에서 에이전트 컨테이너는 `/lib`, `/lib64` 및 `/proc`과 같은 최상위 디렉터리를 탑재합니다. 이는 Amazon EBS 볼륨, `awsvpc` 네트워크 모드, Amazon ECS Service Connect 및 Amazon ECS용 FireLens 같은 ECS 기능에 필요합니다.
각 Amazon ECS 컨테이너 에이전트 버전은 서로 다른 기능 세트를 지원하며 이전 버전에 대한 버그 수정을 제공합니다. 기능한 한 최신 버전의 Amazon ECS 컨테이너 에이전트를 사용할 것이 좋습니다. 컨테이너 에이전트를 최신 버전으로 업데이트하려면 [Amazon ECS 컨테이너 에이전트 업데이트](ecs-agent-update.md) 섹션을 참조하세요.
Amazon ECS 컨테이너 에이전트에는 `amazon-ecs-pause` 이미지가 포함되어 있습니다.Amazon ECS는 `awsvpc` 네트워크 모드를 사용하는 작업에 이 이미지를 사용합니다.
각 에이전트 릴리스에 포함된 기능 및 기능 향상을 보려면 [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 컨테이너 에이전트가 Amazon EC2 인스턴스를 클러스터에 등록하면 Amazon EC2 인스턴스는 상태를 `ACTIVE`로, 에이전트 연결 상태를 `TRUE`로 보고합니다. 이 컨테이너 인스턴스는 작업 실행 요청을 수락할 수 있습니다.
`ACTIVE` 컨테이너 인스턴스를 중지(종료가 아님)하면 상태는 계속 이지만 에이전트 연결 상태는 몇 분 안에 `FALSE`로 전환됩니다. 컨테이너 인스턴스에서 실행 중이던 모든 작업이 중지됩니다. 컨테이너 인스턴스를 다시 시작하면 컨테이너 에이전트는 Amazon ECS 서비스에 다시 연결되고 인스턴스에서 다시 태스크를 실행할 수 있습니다.
컨테이너 인스턴스의 상태를 `DRAINING`로 변경하면 컨테이너 인스턴스에서 새 작업이 배치되지 않습니다. 시스템 업데이트를 수행할 수 있도록 컨테이너 인스턴스에서 실행 중인 모든 서비스 태스크는 가능한 경우 제거됩니다. 자세한 정보는 [Amazon ECS 컨테이너 인스턴스 드레이닝](container-instance-draining.md) 섹션을 참조하세요.
컨테이너 인스턴스 등록을 취소하거나 종료하면 해당 컨테이너 인스턴스 상태가 곧바로 `INACTIVE`로 바뀌며, 컨테이너 인스턴스를 나열할 때 해당 컨테이너 인스턴스가 더 이상 보고되지 않습니다. 하지만 종료 후 한 시간 동안은 여전히 컨테이너 인스턴스 설명이 가능합니다. 한 시간이 지나면 더 이상 인스턴스 설명을 사용할 수 없습니다.
인스턴스를 수동으로 드레이닝하거나 Auto Scaling 그룹 수명 주기 후크를 구축하여 인스턴스 상태를 `DRAINING`으로 설정할 수 있습니다. Auto Scaling 수명 주기 후크에 대한 자세한 정보는 [Amazon EC2 Auto Scaling 수명 주기 후크](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)를 참조하세요.
## Docker 지원
Amazon ECS는 Amazon Linux에 게시된 Docker의 마지막 두 메이저 버전을 지원합니다. 현재 여기에는 Docker 20.10.x 및 Docker 25.x가 포함됩니다.
Amazon ECS에 필요한 최소 Docker 버전은 GitHub의 [Amazon ECS Agent specification file](https://github.com/aws/amazon-ecs-agent/blob/dev/packaging/amazon-linux-ami-integrated/ecs-agent.spec#L53)에서 찾을 수 있습니다.
Amazon ECS 최적화 AMI를 사용하는 경우 Docker는 Amazon ECS 컨테이너 에이전트와 함께 작동하도록 사전 설치 및 구성됩니다. AMI는 Amazon ECS에서 테스트하고 지원하는 Docker 버전을 포함합니다.
**참고**
Amazon ECS는 여러 Docker 버전을 지원하지만 최상의 호환성과 지원을 위해 Amazon ECS 최적화 AMI와 함께 제공되는 Docker 버전을 사용하는 것이 좋습니다.
## Amazon ECS 최적화 AMI
Amazon ECS 최적화 AMI에 관한 자세한 내용은 [Amazon ECS 최적화 Linux AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html)를 참조하세요.
## 추가 정보
다음 페이지에서는 변경 사항에 대한 추가 정보를 제공합니다.
+ GitHub의 [Amazon ECS Agent changelog](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md)
+ [Amazon Linux 2 릴리스 정보](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html)
+ Docker 설명서의 [Docker Engine 릴리스 정보](https://docs.docker.com/engine/release-notes/27/)
+ NVIDIA 설명서의 [NVIDIA 드라이버 설명서](https://docs.nvidia.com/datacenter/tesla/index.html)
# Amazon ECS 컨테이너 에이전트 구성
**적용 대상**: EC2 인스턴스
Amazon ECS 컨테이너 에이전트는 다양한 구성 옵션을 지원하며 대부분은 환경 변수를 통해 설정합니다.
Amazon ECS 최적화 AMI의 Linux 변형을 사용하여 컨테이너 인스턴스를 시작한 경우, 이들 환경 변수를 `/etc/ecs/ecs.config` 파일에서 설정한 후 에이전트를 다시 시작할 수 있습니다. 실행 시 Amazon EC2 사용자 데이터를 사용하여 컨테이너 인스턴스에 구성 변수를 작성할 수도 있습니다. 자세한 내용은 [데이터 전달을 위한 Amazon ECS Linux 컨테이너 인스턴스 부트스트래핑](bootstrap_container_instance.md) 섹션을 참조하세요.
컨테이너 인스턴스가 Amazon ECS 최적화 AMI의 Windows 변형으로 시작된 경우 PowerShell SetEnvironmentVariable 명령을 사용하여 이러한 환경 변수를 설정한 다음 에이전트를 다시 시작할 수 있습니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [사용자 데이터 입력을 사용하여 EC2 인스턴스를 시작할 때 명령 실행](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)과 [데이터 전달을 위한 Amazon ECS Windows 컨테이너 인스턴스 부트스트래핑](bootstrap_windows_container_instance.md)를 참조하세요.
수동으로 Amazon ECS 컨테이너 에이전트(비 Amazon ECS 최적화 AMI 이외 용도)를 시작하는 경우 에이전트를 시작하는 데 사용하는 **docker run** 명령에서 이 환경 변수를 사용할 수 있습니다. `--env=VARIABLE_NAME=VARIABLE_VALUE` 구문에 이러한 변수를 사용합니다. 프라이빗 리포지토리의 인증 자격 증명과 같은 민감한 정보의 경우, 에이전트 환경 변수를 파일에 저장하고 `--env-file path_to_env_file` 옵션을 사용하여 한 번에 모두 전달해야 합니다. 이러한 명령을 사용하여 변수를 추가할 수 있습니다.
```
sudo systemctl stop ecs
sudo vi /etc/ecs/ecs.config
# And add the environment variables with VARIABLE_NAME=VARIABLE_VALUE format.
sudo systemctl start ecs
```
## 호스트 PID 네임스페이스로 Amazon ECS 에이전트 실행
기본적으로 Amazon ECS 에이전트는 자체 PID 네임스페이스로 실행됩니다. 다음 구성에서 호스트 PID 네임스페이스로 실행되도록 Amazon ECS 에이전트를 구성할 수 있습니다.
+ SELinux 적용 모드가 활성화되었습니다.
+ Docker의 SELinux 보안 정책이 true로 설정되었습니다.
`/etc/ecs/ecs.config` 파일에서 `ECS_AGENT_PID_NAMESPACE_HOST` 환경 변수를 `true`로 설정하여 이 동작을 구성할 수 있습니다. 이 변수가 활성화되면 `ecs-init`는 호스트의 PID 네임스페이스(`--pid=host`)로 Amazon ECS 에이전트 컨테이너를 시작하여 에이전트가 SELinux 적용 환경에서 올바르게 부트스트랩할 수 있도록 합니다. 이 기능은 Amazon ECS 에이전트 버전 `1.94.0` 이상에서 사용할 수 있습니다.
이 기능을 활성화하려면 `/etc/ecs/ecs.config` 파일에 다음 줄을 추가하세요.
```
ECS_AGENT_PID_NAMESPACE_HOST=true
```
이렇게 변경한 후 Amazon ECS 에이전트를 다시 시작하여 변경 사항을 적용하세요.
```
sudo systemctl restart ecs
```
SELinux 적용 모드가 활성화되어 있고 Docker 보안 정책이 true로 설정되어 있는 경우 `ECS_AGENT_PID_NAMESPACE_HOST=true`가 설정되어 있어도 다음 기능은 작동하지 않습니다.
+ Amazon ECS Exec
+ Amazon EBS 태스크 연결
+ Service Connect
+ Amazon ECS용 FireLens
## 사용 가능한 파라미터
사용 가능한 Amazon ECS 컨테이너 에이전트 구성 파라미터에 대한 자세한 정보는 GitHub의 [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md)를 참조하세요.
# Amazon S3에 Amazon ECS 컨테이너 인스턴스 구성 저장
Amazon ECS 컨테이너 에이전트 구성은 환경 변수로 제어됩니다. Amazon ECS 최적화 AMI의 Linux 변형은 컨테이너 에이전트가 시작될 때 `/etc/ecs/ecs.config`에서 이들 변수를 확인하여 그에 따라 에이전트를 구성합니다. `ECS_CLUSTER`와 같이 민감하지 않은 환경 변수는 시작 시 Amazon EC2 사용자 데이터를 통해 컨테이너 인스턴스로 전달되고 아무 영향 없이 이 파일에 기록될 수 있습니다. 하지만 AWS 자격 증명 또는 `ECS_ENGINE_AUTH_DATA` 변수와 같은 기타 민감한 정보는 사용자 데이터에서 인스턴스로 전달되거나 `.bash_history` 파일에 표시되도록 허용할 `/etc/ecs/ecs.config`에 기록되어서는 절대 안 됩니다.
Amazon S3에서 구성 정보를 프라이빗 버킷에 저장하고 컨테이너 인스턴스 IAM 역할에 읽기 전용 액세스를 부여하면 시작 시 컨테이너 인스턴스 구성을 안전하고 편리하게 허용할 수 있습니다. 프라이빗 버킷에 `ecs.config` 파일의 사본을 저장할 수 있습니다. 그런 다음 Amazon EC2 사용자 데이터를 사용하여 AWS CLI를 설치하고 인스턴스가 시작될 때 구성 정보를 `/etc/ecs/ecs.config`에 복사할 수 있습니다.
**Amazon S3에 `ecs.config` 파일을 저장하는 방법**
1. Amazon S3에 대해 읽기 전용으로 액세스하려면 컨테이너 인스턴스 역할(**ecsInstanceRole**)에 권한을 부여해야 합니다. **AmazonS3ReadOnlyAccess**를 `ecsInstanceRole` 역할에 할당하면 됩니다. 역할에 정책을 연결하는 방법에 대한 자세한 내용은 *AWS Identity and Access Management 사용 설명서*의 [역할 권한 업데이트](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html)를 참조하세요.
1. 다음 형식을 사용하여 유효한 Amazon ECS 에이전트 구성 변수를 포함하는 `ecs.config` 파일을 생성합니다. 이 예제에서는 프라이빗 레지스트리 인증을 구성합니다. 자세한 내용은 [Amazon ECS에서 AWS 컨테이너가 아닌 이미지 사용](private-auth.md) 섹션을 참조하세요.
```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
```
**참고**
사용 가능한 Amazon ECS 에이전트 구성 변수의 전체 목록은 GitHub의 [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md)를 참조하세요.
1. 구성 파일을 저장하려면 Amazon S3에 프라이빗 버킷을 만듭니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*에서 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)을 참조하세요.
1. `ecs.config` 파일을 S3 버킷에 업로드합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [객체 업로드](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)를 참조하세요.
**시작 시 Amazon S3에서 `ecs.config` 파일을 로드하려면**
1. 이 섹션에서 앞서 설명한 절차를 완료하여 컨테이너 인스턴스에 읽기 전용 Amazon S3 액세스를 부여하고 프라이빗 S3 버킷에 `ecs.config` 파일을 저장합니다.
1. 새 컨테이너 인스턴스를 시작하고 EC2 사용자 데이터에서 다음 예제 스크립트를 사용합니다. 스크립트는 AWS CLI를 설치하고 구성 파일을 `/etc/ecs/ecs.config`에 복사합니다. 자세한 내용은 [Amazon ECS Linux 컨테이너 인스턴스 시작](launch_container_instance.md) 섹션을 참조하세요.
```
#!/bin/bash
yum install -y aws-cli
aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
```
# Amazon ECS 컨테이너 에이전트 설치
Amazon ECS 클러스터에 Amazon EC2 인스턴스를 등록하려고 하는데 해당 인스턴스가 Amazon ECS 최적화 AMI 기반 AMI를 사용하지 않는 경우에는 다음 절차에 따라 Amazon ECS 컨테이너 에이전트를 수동으로 설치할 수 있습니다. 이렇게 하려면 리전의 Amazon S3 버킷 중 하나 또는 Amazon Elastic Container Registry Public에서 에이전트를 다운로드하면 됩니다. 리전 Amazon S3 버킷 중 하나에서 다운로드하는 경우 선택적으로 PGP 서명을 사용하여 컨테이너 에이전트 파일의 유효성을 확인할 수 있습니다.
**참고**
Amazon ECS 및 도커 서비스 모두를 위한 `systemd` 단위에는 이 두 서비스를 시작하기 전에 완료하기 위해 `cloud-init`를 대기하는 명령이 있습니다. `cloud-init` 프로세스는 Amazon EC2 사용자 데이터의 실행이 완료될 때까지 완료된 것으로 간주되지 않습니다. 따라서 Amazon EC2 사용자 데이터를 통해 Amazon ECS 또는 도커를 시작하면 교착 상태가 발생할 수 있습니다. Amazon EC2 사용자 데이터를 사용하여 컨테이너 에이전트를 시작하려면 `systemctl enable --now --no-block ecs.service`를 사용할 수 있습니다.
## 비 Amazon Linux EC2 에이전트에 Amazon ECS 컨테이너 에이전트 설치
Amazon EC2 인스턴스에 Amazon ECS 컨테이너 에이전트를 설치하려면 리전 Amazon S3 버킷 중 하나에서 에이전트를 다운로드하여 설치할 수 있습니다.
**참고**
비 Amazon Linux AMI를 사용할 때 Amazon EC2 인스턴스는 `cgroupfs` 드라이버에 대한 `cgroup` 지원이 있어야 Amazon ECS 에이전트가 작업 수준 리소스 제한을 지원할 수 있습니다. 자세한 내용은 [GitHub의 Amazon ECS 에이전트](https://github.com/aws/amazon-ecs-agent)를 참조하세요.
참조용으로 아래에 각 시스템 아키텍처에 대해 최신 Amazon ECS 컨테이너 에이전트 파일이 리전별로 나열되어 있습니다.
| 리전 | 리전 이름 | Amazon ECS init deb 파일 | Amazon ECS init rpm 파일 |
| --- | --- | --- | --- |
| us-east-2 | 미국 동부(오하이오) | [Amazon ECS init amd64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| us-east-1 | 미국 동부(버지니아 북부) | [Amazon ECS init amd64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| us-west-1 | 미국 서부(캘리포니아 북부) | [Amazon ECS init amd64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| us-west-2 | 미국 서부(오리건) | [Amazon ECS init amd64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| ap-east-1 | 아시아 태평양(홍콩) | [Amazon ECS init amd64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| ap-northeast-1 | 아시아 태평양(도쿄) | [Amazon ECS init amd64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| ap-northeast-2 | 아시아 태평양(서울) | [Amazon ECS init amd64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| ap-south-1 | 아시아 태평양(뭄바이) | [Amazon ECS init amd64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| ap-southeast-1 | 아시아 태평양(싱가포르) | [Amazon ECS init amd64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| ap-southeast-2 | 아시아 태평양(시드니) | [Amazon ECS init amd64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| ca-central-1 | 캐나다(중부) | [Amazon ECS init amd64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| eu-central-1 | 유럽(프랑크푸르트) | [Amazon ECS init amd64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| eu-west-1 | 유럽(아일랜드) | [Amazon ECS init amd64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| eu-west-2 | 유럽(런던) | [Amazon ECS init amd64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| eu-west-3 | 유럽(파리) | [Amazon ECS init amd64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| sa-east-1 | 남아메리카(상파울루) | [Amazon ECS init amd64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.x86_64.rpm) [Amazon ECS init aarch64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| us-gov-east-1 | AWS GovCloud(미국 동부) | [Amazon ECS init amd64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
| us-gov-west-1 | AWS GovCloud(미국 서부) | [Amazon ECS init amd64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.amd64.deb)(amd64) [Amazon ECS init arm64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.arm64.deb)(arm64) | [Amazon ECS init x86\$164](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.x86_64.rpm)(x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.aarch64.rpm)(aarch64) |
**비 Amazon Linux AMI를 사용하는 Amazon EC2 인스턴스에 Amazon ECS 컨테이너 에이전트를 설치하는 방법**
1. Amazon ECS에 액세스할 수 있는 IAM 역할로 Amazon EC2 인스턴스를 시작합니다. 자세한 정보는 [Amazon ECS 컨테이너 인스턴스 IAM 역할](instance_IAM_role.md)을 참조하세요.
1. 인스턴스에 연결합니다.
1. 인스턴스에 최신 버전의 Docker를 설치합니다.
1. 시스템이 최소 버전 요구 사항을 충족하는지 Docker 버전을 확인하세요. Docker 지원에 대한 자세한 내용은 [Amazon EC2 컨테이너 인스턴스](ecs-agent-versions.md) 섹션을 참조하세요.
```
docker --version
```
1. 운영 체제 및 시스템 아키텍처에 적합한 Amazon ECS 에이전트 파일을 다운로드하여 설치합니다.
`deb` 아키텍처의 경우:
```
ubuntu:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb
ubuntu:~$ sudo dpkg -i amazon-ecs-init-latest.amd64.deb
```
`rpm` 아키텍처의 경우:
```
fedora:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm
fedora:~$ sudo yum localinstall -y amazon-ecs-init-latest.x86_64.rpm
```
1. `/lib/systemd/system/ecs.service` 파일을 편집하고 `[Unit]` 섹션의 끝에 다음 줄을 추가합니다.
```
After=cloud-final.service
```
1. (선택 사항) 인스턴스를 `default` 클러스터가 아닌 클러스터에 등록하려면, `/etc/ecs/ecs.config` 파일을 편집하고 다음 내용을 추가하세요. 다음 예제는 `MyCluster` 클러스터를 지정합니다.
```
ECS_CLUSTER=MyCluster
```
이들을 비롯한 기타 에이전트 런타임 옵션에 대한 자세한 내용은 [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. `ecs` 서비스를 시작합니다.
```
ubuntu:~$ sudo systemctl start ecs
```
## 호스트 네트워크 모드로 Amazon ECS 에이전트 실행
Amazon ECS 컨테이너 에이전트를 실행하는 경우 `ecs-init`는 `host` 네트워크 모드로 컨테이너 에이전트 컨테이너를 만듭니다. 이 모드는 컨테이너 에이전트 컨테이너에서 유일하게 지원되는 네트워크 모드입니다.
이렇게 하면 컨테이너 에이전트가 시작한 컨테이너가 [Amazon EC2 인스턴스 메타데이터 서비스 엔드포인트](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)(`http://169.254.169.254`)에 액세스하는 것을 차단할 수 있습니다. 이 경우 컨테이너가 컨테이너 인스턴스 프로필에서 IAM 역할 자격 증명에 액세스할 수 없으며 해당 작업이 IAM 태스크 역할 자격 증명만 사용합니다. 자세한 정보는 [Amazon ECS 작업 IAM 역할](task-iam-roles.md)을 참조하세요.
이렇게 하면 컨테이너 에이전트가 `docker0` 브리지에서 연결 및 네트워크 트래픽을 위해 경합하지 않습니다.
## Amazon ECS 컨테이너 에이전트 로그 구성 파라미터
Amazon ECS 컨테이너 에이전트는 컨테이너 인스턴스에 로그를 저장합니다.
컨테이너 에이전트 버전 1.36.0 이상에서는 기본적으로 로그가 Linux 인스턴스의 `/var/log/ecs/ecs-agent.log`와 Windows 인스턴스의 `C:\ProgramData\Amazon\ECS\log\ecs-agent.log`에 있습니다.
컨테이너 에이전트 버전 1.35.0 및 이전 버전의 경우 기본적으로 로그는 Linux 인스턴스의 `/var/log/ecs/ecs-agent.log.timestamp`와 Windows 인스턴스의 `C:\ProgramData\Amazon\ECS\log\ecs-agent.log.timestamp`에 있습니다.
기본적으로 에이전트 로그는 매시간 교체되며 최대 24개의 로그가 저장됩니다.
다음은 기본 에이전트 로깅 동작을 변경하는 데 사용할 수 있는 컨테이너 에이전트 구성 변수입니다. 사용 가능한 모든 구성 파라미터에 대한 자세한 내용은 [Amazon ECS 컨테이너 에이전트 구성](ecs-agent-config.md) 또는 GitHub의 [Amazon ECS Agent README](https://github.com/aws/amazon-ecs-agent/blob/master/README.md)를 참조하세요.
다음은 컨테이너 에이전트 버전 1.36.0 이상에서 `logfmt` 형식을 사용할 때의 로그 파일 예시입니다.
```
level=info time=2019-12-12T23:43:29Z msg="Loading configuration" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-agent:latest" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-pause:0.1.0" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Amazon ECS agent Version: 1.36.0, Commit: ca640387" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Creating root ecs cgroup: /ecs" module=init_linux.go
level=info time=2019-12-12T23:43:29Z msg="Creating cgroup /ecs" module=cgroup_controller_linux.go
level=info time=2019-12-12T23:43:29Z msg="Loading state!" module=statemanager.go
level=info time=2019-12-12T23:43:29Z msg="Event stream ContainerChange start listening..." module=eventstream.go
level=info time=2019-12-12T23:43:29Z msg="Restored cluster 'auto-robc'" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Restored from checkpoint file. I am running as 'arn:aws:ecs:us-west-2:0123456789:container-instance/auto-robc/3330a8a91d15464ea30662d5840164cd' in cluster 'auto-robc'" module=agent.go
```
다음은 JSON 형식을 사용할 때의 로그 파일 예시입니다.
```
{"time": "2019-11-07T22:52:02Z", "level": "info", "msg": "Starting Amazon Elastic Container Service Agent", "module": "engine.go"}
```
# 프라이빗 Docker 이미지를 위한 Amazon ECS 컨테이너 인스턴스 구성
Amazon ECS 컨테이너 에이전트는 기본 인증을 사용하여 프라이빗 레지스트리로 인증할 수 있습니다. 프라이빗 레지스트리 인증을 활성화하면 태스크 정의에서 프라이빗 Docker 이미지를 사용할 수 있습니다. 이 기능은 EC2를 사용하는 태스크에서만 지원됩니다.
프라이빗 레지스트리 인증을 활성화하는 또 다른 방법은 AWS Secrets Manager를 사용하여 프라이빗 레지스트리 자격 증명을 안전하게 저장한 후 나중에 컨테이너 정의에서 참조합니다. 태스크에서 프라이빗 리포지토리의 이미지를 사용할 수 있는 것도 이러한 인증 기능 때문입니다. 이 방법은 EC2 또는 Fargate를 사용하는 태스크만 지원합니다. 자세한 내용은 [Amazon ECS에서 AWS 컨테이너가 아닌 이미지 사용](private-auth.md) 섹션을 참조하세요.
Amazon ECS 컨테이너 에이전트는 시작할 때 다음 환경 변수 2개를 찾습니다.
+ `ECS_ENGINE_AUTH_TYPE`, 전송되는 인증 데이터의 유형을 지정합니다.
+ `ECS_ENGINE_AUTH_DATA`, 실제 인증 자격 증명이 포함됩니다.
Amazon ECS 최적화 AMI의 Linux 변형은 컨테이너 인스턴스가 시작될 때, 그리고 서비스가 시작될 때마다이 변수에 대해 `/etc/ecs/ecs.config` 파일을 스캔할 수 있습니다(**sudo start ecs** 명령 사용). Amazon ECS 최적화가 아닌 AMI는 이러한 환경 변수를 파일에 저장하고 `--env-file path_to_env_file` 옵션을 사용하여 컨테이너 에이전트를 시작하는 **docker run** 명령에 전달해야 합니다.
**중요**
이러한 인증 환경 변수를 인스턴스 시작 시 Amazon EC2 사용자 데이터를 사용하여 첨가하거나 `--env` 옵션을 사용하여 **docker run** 명령으로 전달하지 않는 것이 좋습니다. 인증 자격 증명과 같은 민감한 정보인 경우 이러한 방법이 적절하지 않습니다. 인증 자격 증명을 컨테이너 인스턴스에 안전하게 추가하는 방법에 대한 자세한 내용은 [Amazon S3에 Amazon ECS 컨테이너 인스턴스 구성 저장](ecs-config-s3.md) 섹션을 참조하세요.
## 인증 형식
프라이빗 레지스트리 인증에 `dockercfg` 및 `docker` 두 가지 형식을 사용할 수 있습니다.
**Dockercfg 인증 형식**
`dockercfg` 형식은 **docker login** 명령을 실행하면 만들어지는 구성 파일에 저장된 인증 정보를 사용합니다. 이 파일은 로컬 시스템에서 **docker login**을 실행하고 레지스트리 사용자 이름, 암호 및 이메일 주소를 입력하여 만들 수 있습니다. 컨테이너 인스턴스에 로그인한 후 그 인스턴스에서 명령을 실행할 수도 있습니다. Docker 버전에 따라 이 파일은 `~/.dockercfg` 또는 `~/.docker/config.json`으로 저장됩니다.
```
cat ~/.docker/config.json
```
출력:
```
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "zq212MzEXAMPLE7o6T25Dk0i"
}
}
}
```
**중요**
Docker 버전이 새로우면 바깥쪽 `auths` 객체를 사용하여 위와 같은 구성 파일이 생성됩니다. Amazon ECS 에이전트는 `auths` 객체 없이 아래 형식의 `dockercfg` 인증 데이터만 지원합니다. **jq** 유틸리티가 설치된 경우에는 **cat \$1/.docker/config.json \$1 jq .auths** 명령으로 이 데이터를 추출할 수 있습니다.
```
cat ~/.docker/config.json | jq .auths
```
출력:
```
{
"https://index.docker.io/v1/": {
"auth": "zq212MzEXAMPLE7o6T25Dk0i",
"email": "email@example.com"
}
}
```
위 예제에서는 실행 시간에 Amazon ECS 컨테이너 에이전트가 로드하는 환경 변수 파일(Amazon ECS 최적화 AMI의 경우에는 `/etc/ecs/ecs.config`)에 다음 환경 변수를 추가해야 합니다. Amazon ECS 최적화 AMI를 사용하지 않고 **docker run**을 사용하여 수동으로 에이전트를 시작하는 경우 에이전트를 시작할 때 `--env-file path_to_env_file` 옵션을 통해 환경 변수 파일을 지정합니다.
```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
```
다음 구문을 사용하면 여러 프라이빗 레지스트리를 구성할 수 있습니다.
```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example-01.com"},"repo.example-02.com":{"auth":"fQ172MzEXAMPLEoF7225DU0j","email":"email@example-02.com"}}
```
**Docker 인증 형식**
`docker` 형식은 에이전트가 인증할 때 사용하는 레지스트리 서버의 JSON 표현을 사용합니다. 여기에는 해당 레지스트리가 요구하는 인증 파라미터도 포함됩니다(예: 해당 계정의 사용자 이름, 암호, 이메일 주소). Docker Hub 계정의 경우 JSON 표현은 다음과 같습니다.
```
{
"https://index.docker.io/v1/": {
"username": "my_name",
"password": "my_password",
"email": "email@example.com"
}
}
```
이 예제에서는 실행 시간에 Amazon ECS 컨테이너 에이전트가 로드하는 환경 변수 파일(Amazon ECS 최적화 AMI의 경우에는 `/etc/ecs/ecs.config`)에 다음 환경 변수를 추가해야 합니다. Amazon ECS 최적화 AMI를 사용하지 않고 **docker run**을 사용하여 수동으로 에이전트를 시작하는 경우 에이전트를 시작할 때 `--env-file path_to_env_file` 옵션을 통해 환경 변수 파일을 지정합니다.
```
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_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"username":"my_name","password":"my_password","email":"email@example-01.com"},"repo.example-02.com":{"username":"another_name","password":"another_password","email":"email@example-02.com"}}
```
## 절차
컨테이너 인스턴스에 대한 프라이빗 레지스트리를 사용 설정하려면 다음 절차를 따르세요.
**Amazon ECS 최적화 AMI에서 프라이빗 레지스트리를 활성화하는 방법**
1. SSH를 사용해 컨테이너 인스턴스에 로그인합니다.
1. `/etc/ecs/ecs.config` 파일을 열고 레지스트리 및 계정으로 다음과 같이 `ECS_ENGINE_AUTH_TYPE` 및 `ECS_ENGINE_AUTH_DATA` 값을 추가합니다.
```
sudo vi /etc/ecs/ecs.config
```
이 예제에서는 Docker Hub 사용자 계정을 인증합니다.
```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
```
1. 에이전트가 `ECS_DATADIR` 환경 변수를 사용하여 해당 상태를 다음과 같이 저장하는지 확인합니다.
```
docker inspect ecs-agent | grep ECS_DATADIR
```
출력:
```
"ECS_DATADIR=/data",
```
**중요**
이전 명령이 `ECS_DATADIR` 환경 변수를 반환하지 않으면 에이전트를 중지하기 전에 이 컨테이너 인스턴스에서 실행 중인 태스크를 모두 중지해야 합니다. `ECS_DATADIR` 환경 변수를 사용하는 새 버전의 에이전트는 해당 상태를 저장하며 태스크가 실행되는 동안 에이전트를 중지하고 시작해도 문제가 발생하지 않습니다. 자세한 정보는 [Amazon ECS 컨테이너 에이전트 업데이트](ecs-agent-update.md)을 참조하세요.
1. 다음과 같이 `ecs` 서비스를 중단합니다.
```
sudo stop ecs
```
출력:
```
ecs stop/waiting
```
1. `ecs` 서비스를 다시 시작합니다.
+ Amazon ECS 최적화 Amazon Linux 2 AMI의 경우:
```
sudo systemctl restart ecs
```
+ Amazon ECS 최적화 Amazon Linux AMI의 경우:
```
sudo stop ecs && sudo start ecs
```
1. (선택 사항) 에이전트 내부 검사 API 태스크를 쿼리하여 에이전트가 실행 중인지 확인하고 새 컨테이너 인스턴스에 대한 일부 정보를 볼 수 있습니다. 자세한 내용은 [Amazon ECS 컨테이너 내부 검사](ecs-agent-introspection.md) 섹션을 참조하세요.
```
curl http://localhost:51678/v1/metadata
```
# 자동 Amazon ECS 태스크 및 이미지 정리
컨테이너 인스턴스에 작업이 배치될 때마다 Amazon ECS 컨테이너 에이전트가 작업에서 참조된 이미지가 리포지토리에서 지정된 태그의 최신 이미지인지 확인합니다. 최신이 아닌 경우 기본 동작은 에이전트가 해당 리포지토리에서 이미지를 가져오도록 허용합니다. 태스크와 서비스에서 이미지를 자주 업데이트하는 경우 컨테이너 인스턴스 스토리지가 더 이상 사용하지 않고 앞으로도 다시 사용하지 않을 Docker 이미지로 금세 가득 찰 수 있습니다. 예를 들어 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 사용할 수 있습니다.
**참고**
Amazon ECS 에이전트 이미지 가져오기 동작은 `ECS_IMAGE_PULL_BEHAVIOR` 파라미터를 사용하여 사용자 지정할 수 있습니다. 자세한 정보는 [Amazon ECS 컨테이너 에이전트 구성](ecs-agent-config.md)을 참조하세요.
마찬가지로, 중지된 태스크에 속하는 컨테이너가 로그 정보, 데이터 볼륨 및 기타 아티팩트로 컨테이너 인스턴스 스토리지를 소비할 수도 있습니다. 이러한 아티팩트는 예기치 않게 중지한 컨테이너를 디버깅하는 데 유용하지만, 이 스토리지는 대부분 일정 시간 후에 안전하게 해제될 수 있습니다.
기본적으로 Amazon ECS 컨테이너 에이전트는 컨테이너 인스턴스에서 어떤 작업도 사용하고 있지 않은 중지된 작업 및 Docker 이미지를 자동으로 정리합니다.
**참고**
자동 이미지 정리 기능을 사용하려면 Amazon ECS 컨테이너 에이전트 버전 1.13.0 이상이 필요합니다. 에이전트를 최신 버전으로 업데이트하려면 [Amazon ECS 컨테이너 에이전트 업데이트](ecs-agent-update.md) 섹션을 참조하세요.
다음의 에이전트 구성 변수를 사용하여 자동 태스크 및 이미지 정리 환경을 조정할 수 있습니다. 컨테이너 인스턴스에서 이들 변수를 설정하는 방법에 대한 자세한 내용은 [Amazon ECS 컨테이너 에이전트 구성](ecs-agent-config.md) 섹션을 참조하세요.
`ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`
중지된 태스크의 컨테이너를 삭제하기 위해 대기하는 기본 시간. 값이 1보다 작게 설정된 경우 값은 무시됩니다. 기본적으로 이 파라미터는 3시간으로 설정되지만 애플리케이션에 필요할 경우 이 기간을 최소 1초로 줄일 수 있습니다.
이미지 정리 프로세스는 컨테이너가 이미지를 참조하는 한 해당 이미지를 삭제할 수 없습니다. 컨테이너가 제거되면 참조되지 않은 모든 이미지는 이미지 정리 구성 파라미터를 기반으로 정리 대상이 됩니다.
`ECS_DISABLE_IMAGE_CLEANUP`
이 변수를 `true`로 설정할 경우 컨테이너 인스턴스에서 자동 이미지 정리가 꺼지고 이미지가 자동으로 제거되지 않습니다.
`ECS_IMAGE_CLEANUP_INTERVAL`
이 변수는 자동 이미지 정리 프로세스가 삭제할 이미지가 있는지 확인하는 주기를 지정합니다. 기본값은 매 30분이지만 애플리케이션에 필요할 경우 사용자가 이 기간을 최소 10분으로 단축하여 이미지를 제거할 수 있습니다.
`ECS_IMAGE_MINIMUM_CLEANUP_AGE`
이 변수는 이미지를 끌어온 시점과 이미지가 제거 후보가 될 수 있는 시점 사이의 최소 시간 간격을 지정합니다. 이 변수는 방금 끌어온 이미지가 정리되는 것을 방지하기 위해 사용합니다. 기본값은 1시간입니다.
`ECS_NUM_IMAGES_DELETE_PER_CYCLE`
이 변수는 단일 정리 사이클에서 제거할 수 있는 이미지 수를 지정합니다. 기본값은 5이고, 최솟값은 1입니다.
Amazon ECS 컨테이너 에이전트가 실행 중이고 자동 이미지 정리가 꺼지지 않았으면 에이전트가 실행 중 또는 중지된 컨테이너에 의해 참조되지 않는 Docker 이미지가 있는지 `ECS_IMAGE_CLEANUP_INTERVAL` 변수로 지정된 주기로 확인합니다. 사용되지 않는 이미지가 발견되고 해당 이미지가 `ECS_IMAGE_MINIMUM_CLEANUP_AGE` 변수로 지정된 최소 정리 기간보다 오래된 경우 에이전트가 `ECS_NUM_IMAGES_DELETE_PER_CYCLE` 변수로 지정된 최대 이미지 수만큼 제거합니다. 가장 이전에 참조된 이미지가 먼저 삭제됩니다. 이미지가 제거된 후, 에이전트는 다음 주기까지 대기했다 프로세스를 반복합니다.