기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Auto Scaling 그룹
**참고**
Auto Scaling 그룹을 처음 사용하는 경우 [첫 번째 Auto Scaling 그룹 생성](create-your-first-auto-scaling-group.md) 자습서의 단계를 진행하여 시작하고, 그룹의 인스턴스가 종료될 때 Auto Scaling 그룹이 어떻게 응답하는지 확인하세요.
*Auto Scaling 그룹*에는 자동 크기 조정 및 관리를 위해 논리적 그룹으로 취급되는 EC2 인스턴스 모음이 포함되어 있습니다. Auto Scaling 그룹을 통해 건전성 체크 교체 및 조정 정책과 같은 Amazon EC2 Auto Scaling 기능도 사용할 수 있습니다. Auto Scaling 그룹 내 인스턴스 수 유지와 및 자동 크기 조정, 이 두 가지가 Amazon EC2 Auto Scaling 서비스의 핵심 기능입니다.
Auto Scaling 그룹의 크기는 사용자가 원하는 용량으로 설정한 인스턴스 수에 따라 달라집니다. 수동으로 또는 자동 크기 조정을 사용하여 수요에 맞게 크기를 조정할 수 있습니다.
Auto Scaling 그룹은 원하는 용량을 충족하도록 충분한 인스턴스를 시작하여 시작합니다. 그룹 내 인스턴스에 대한 주기적인 건전성 체크를 수행하여 이 인스턴스 수를 유지합니다. Auto Scaling 그룹은 인스턴스 상태가 이상이 있는 경우에도 고정된 수의 인스턴스를 계속 유지합니다. 인스턴스가 비건전 상태가 되면 그룹에서는 비건전 인스턴스를 해지하고 이를 교체할 다른 인스턴스를 시작합니다. 자세한 설명은 [Auto Scaling 그룹의 인스턴스에 대한 상태 확인](ec2-auto-scaling-health-checks.md) 섹션을 참조하세요.
조정 정책을 사용하여 바뀌는 조건을 충족하도록 그룹의 인스턴스 수를 동적으로 늘리거나 줄일 수 있습니다. 조정 정책의 효력이 발생되면, Auto Scaling 그룹이 해당 그룹의 희망 용량을 사용자가 지정하는 최소 및 최대 용량 값 사이에서 조절하고 필요에 따라 인스턴스를 시작 또는 해지합니다. 일정에서도 스케일 아웃이 가능합니다. 자세한 설명은 [스케일링 방법 선택](scaling-overview.md) 섹션을 참조하세요.
Auto Scaling 그룹을 생성할 때 온디맨드 인스턴스를 띄울지, 스팟 인스턴스 또는 둘 모두를 띄울지를 선택할 수 있습니다. launch template을 사용하는 경우에만 Auto Scaling 그룹에 대해 여러 구매 옵션을 지정할 수 있습니다. 자세한 내용은 [여러 인스턴스 유형 및 구매 옵션이 포함된 Auto Scaling 그룹](ec2-auto-scaling-mixed-instances-groups.md) 단원을 참조하십시오.
스팟 인스턴스를 사용하면 온디맨드 가격과 비교하여 대폭 할인된 금액으로 미사용 EC2 용량에 액세스할 수 있습니다. 자세한 설명은 [Amazon EC2 스팟 인스턴스](https://aws.amazon.com/ec2/spot/pricing/) 섹션을 참조하세요. 스팟 인스턴스와 온 디맨드 인스턴스 간에는 다음과 같은 주요 차이점이 있습니다.
+ 스팟 인스턴스의 가격은 수요에 따라 변동합니다.
+ 스팟 인스턴스의 가용성 또는 가격이 변동함에 따라 Amazon EC2가 개별 스팟 인스턴스를 해지할 수 있습니다.
스팟 인스턴스가 해지되면 Auto Scaling 그룹에서는 교체 인스턴스를 시작하여 그룹의 원하는 용량을 유지하려고 합니다.
인스턴스가 시작되고 사용자가 여러 가용 영역을 지정한 경우, 희망 용량이 이러한 가용 영역에 분산됩니다. 크기 조정 작업이 발생하는 경우, 사용자가 지정한 모든 가용 영역에서 Amazon EC2 Auto Scaling이 자동으로 균형을 유지합니다.
**Topics**
+ [시작 템플릿을 사용하여 Auto Scaling 그룹 생성](create-auto-scaling-groups-launch-template.md)
+ [시작 구성을 사용하여 Auto Scaling 그룹 생성](create-auto-scaling-groups-launch-configuration.md)
+ [동기식으로 인스턴스 시작](launch-instances-synchronously.md)
+ [Auto Scaling 업데이트](update-auto-scaling-group.md)
+ [Auto Scaling 그룹 및 인스턴스에 태그 지정](ec2-auto-scaling-tagging.md)
+ [인스턴스 유지 관리 정책](ec2-auto-scaling-instance-maintenance-policy.md)
+ [Amazon EC2 Auto Scaling 수명 주기 후크](lifecycle-hooks.md)
+ [웜 풀을 사용하여 부팅 시간이 긴 애플리케이션의 지연 시간 단축](ec2-auto-scaling-warm-pools.md)
+ [Auto Scaling 그룹 영역 전환](ec2-auto-scaling-zonal-shift.md)
+ [Auto Scaling 그룹 가용 영역 배포](ec2-auto-scaling-availability-zone-balanced.md)
+ [Auto Scaling 그룹에서 인스턴스 분리 또는 연결](ec2-auto-scaling-detach-attach-instances.md)
+ [Auto Scaling 그룹에서 일시적으로 인스턴스 제거](as-enter-exit-standby.md)
+ [Auto Scaling 인프라 삭제](as-process-shutdown.md)
# 시작 템플릿을 사용하여 Auto Scaling 그룹 생성
시작 템플릿을 생성한 경우, 시작 템플릿을 EC2 인스턴스에 대한 구성 템플릿으로 사용하는 자동 스케일 아웃 그룹을 생성할 수 있습니다. 시작 템플릿은 귀하의 인스턴스를 위한 AMI ID, 인스턴스 유형, 키 페어, 보안 그룹, 블록 디바이스 매핑 등의 정보를 지정합니다. 시작 템플릿 생성에 대한 자세한 설명은 [Auto Scaling 그룹에 대한 시작 템플릿 생성](create-launch-template.md) 섹션을 참조하십시오.
Auto Scaling 그룹을 만들려면 충분한 권한이 있어야 합니다. 또한 아직 존재하지 않는 경우, 사용자를 대신하여 작업을 수행하기 위해 Amazon EC2 Auto Scaling이 사용하는 서비스 연결 역할을 생성할 수 있는 충분한 권한이 있어야 합니다. 관리자가 사용자에게 권한을 부여하기 위한 참고 자료로 사용할 수 있는 IAM 정책의 예는 [ID 기반 정책 예시](security_iam_id-based-policy-examples.md) 및 [Auto Scaling 그룹에서 Amazon EC2 시작 템플릿 사용량 제어](ec2-auto-scaling-launch-template-permissions.md)를 참조하세요.
**Topics**
+ [시작 템플릿을 사용하여 Auto Scaling 그룹 생성](create-asg-launch-template.md)
+ [Amazon EC2 시작 마법사를 사용하여 Auto Scaling 그룹 생성](create-asg-ec2-wizard.md)
+ [여러 인스턴스 유형 및 구매 옵션이 포함된 Auto Scaling 그룹](ec2-auto-scaling-mixed-instances-groups.md)
# 시작 템플릿을 사용하여 Auto Scaling 그룹 생성
Auto Scaling 그룹을 생성할 때 Amazon EC2 인스턴스, 인스턴스의 가용 영역 및 VPC 서브넷, 원하는 용량, 최소 및 최대 용량 제한을 구성하는 데 필요한 정보를 지정해야 합니다.
Auto Scaling 그룹에서 시작하는 Amazon EC2 인스턴스를 구성하려면 시작 템플릿이나 시작 구성을 지정합니다. 다음 절차는 시작 템플릿을 사용하여 Auto Scaling 그룹을 생성하는 방법을 보여줍니다.
**사전 조건**
+ 시작 템플릿을 생성해야 합니다. 자세한 설명은 [Auto Scaling 그룹에 대한 시작 템플릿 생성](create-launch-template.md) 섹션을 참조하세요.
**시작 템플릿을 사용하여 Auto Scaling 그룹을 생성하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. 화면 상단의 탐색 모음에서 시작 템플릿을 생성할 때 사용한 AWS 리전 것과 동일한를 선택합니다.
1. **Create an Auto Scaling group**(Auto Scaling 그룹 생성)을 선택합니다.
1. **시작 템플릿 또는 구성 선택** 페이지에서 다음을 수행하십시오:
1. **Auto Scaling group name**(Auto Scaling 그룹 명칭)에 Auto Scaling 그룹 명칭을 입력합니다.
1. **시작 템플릿**에서 기존 시작 템플릿을 선택합니다.
1. **Launch template version**(시작 템플릿 버전)에서 Auto Scaling 그룹이 스케일 아웃 시 시작 템플릿의 기본 버전을 사용할지, 최신 버전을 사용할지, 아니면 특정 버전을 사용할지를 선택합니다.
1. 시작 템플릿이 사용하려는 모든 옵션을 지원하는지 확인한 후 **다음**을 선택합니다.
1. **인스턴스 시작 옵션** 선택 페이지에서 여러 인스턴스 유형을 사용하지 않는 경우, **인스턴스 유형 요건** 섹션을 건너뛰고 시작 템플릿에 지정된 EC2 인스턴스 유형을 사용할 수 있습니다.
여러 인스턴스 유형을 사용하려면 [여러 인스턴스 유형 및 구매 옵션이 포함된 Auto Scaling 그룹](ec2-auto-scaling-mixed-instances-groups.md)을 참조하십시오.
1. **네트워크(Network)**의 **VPC**에서 VPC를 선택합니다. Auto Scaling 그룹은 시작 템플릿에서 지정한 보안 그룹과 동일한 VPC에 생성되어야 합니다.
1. **가용 영역 및 서브넷**에서 지정한 VPC에 있는 서브넷 하나 이상을 선택합니다. 여러 가용 영역의 서브넷을 사용하여 가용성을 높일 수 있습니다. 자세한 내용은 [VPC 서브넷 선택 시 고려 사항](asg-in-vpc.md#as-vpc-considerations) 단원을 참조하십시오.
1. **가용 영역 배포**에서 배포 전략을 선택합니다. 자세한 내용은 [Auto Scaling 그룹 가용 영역 배포](ec2-auto-scaling-availability-zone-balanced.md) 단원을 참조하십시오.
1. 지정된 인스턴스 유형으로 시작 템플릿을 생성한 경우, 다음 단계를 계속 진행하여 시작 템플릿의 인스턴스 유형을 사용하는 Auto Scaling 그룹을 생성할 수 있습니다.
또는 시작 템플릿에 인스턴스 유형이 지정되지 않았거나 자동 크기 조정에 여러 인스턴스 유형을 사용하려는 경우, **시작 템플릿 재정의(Override launch template)** 옵션을 선택할 수 있습니다. 자세한 설명은 [여러 인스턴스 유형 및 구매 옵션이 포함된 Auto Scaling 그룹](ec2-auto-scaling-mixed-instances-groups.md) 섹션을 참조하세요.
1. **다음(Next)**을 선택하여 다음 단계로 계속 진행합니다.
또는 나머지 기본값을 그대로 두고, **검토로 이동(Skip to review)**을 선택할 수 있습니다.
1. (선택 사항) **다른 서비스와 통합** 페이지에서 다음 옵션을 구성하고 **다음**을 선택합니다.
1. **로드 밸런싱**에서 Auto Scaling 그룹을 로드 밸런서에 연결할지 여부를 선택합니다. 자세한 내용은 [Elastic Load Balancing](autoscaling-load-balancer.md) 단원을 참조하십시오.
1. **VPC Lattice 통합 옵션**의 경우 VPC Lattice를 사용할지 여부를 선택합니다. 자세한 내용은 [VPC Lattice 대상 그룹을 사용하여 트래픽 흐름 관리](ec2-auto-scaling-vpc-lattice.md) 단원을 참조하십시오.
1. **Amazon Application Recovery Controller(ARC) 영역 전환**의 경우 확인란을 선택하여 영역 전환을 활성화합니다. 자세한 내용은 [Auto Scaling 그룹 영역 전환](ec2-auto-scaling-zonal-shift.md) 단원을 참조하십시오.
1. 영역 전환을 활성화한 경우 **상태 확인 동작**에서 비정상 인스턴스 무시 또는 비정상 인스턴스 교체를 선택합니다. 자세한 내용은 [Auto Scaling 그룹에서 영역 전환 작동 방식](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works) 단원을 참조하십시오.
1. **상태 확인**의 **추가 상태 확인 유형**에서 **Amazon EBS 상태 확인 활성화**를 선택합니다. 자세한 내용은 [상태 확인을 사용하여 Amazon EBS 볼륨이 손상된 Auto Scaling 인스턴스 모니터링](monitor-and-replace-instances-with-impaired-ebs-volumes.md) 단원을 참조하십시오.
1. **상태 확인 유예 기간**에 시간을 초 단위로 입력합니다. 이는 Amazon EC2 Auto Scaling이 인스턴스가 `InService` 상태에 진입한 후 상태를 확인하기 전에 기다려야 하는 시간입니다. 자세한 내용은 [Auto Scaling 그룹의 상태 확인 유예 기간 설정](health-check-grace-period.md) 단원을 참조하십시오.
1. (선택 사항) **그룹 크기 및 조정 구성** 페이지에서 다음 옵션을 구성하고 **다음**을 선택합니다.
1. **그룹 사이즈**에서 **원하는 용량**에 시작시킬 초기 인스턴스 수를 입력합니다.
1. **스케일링**의 **스케일링 제한**에서 **희망 용량**에 대한 새 값이 **최소 희망 용량** 및 **최대 희망 용량**보다 큰 경우, **최대 희망 용량**은 자동으로 새 희망 용량 값으로 증가합니다. 필요에 따라 이러한 한도를 변경할 수 있습니다. 자세한 설명은 [Auto Scaling 그룹에 대한 스케일링 제한 설정](asg-capacity-limits.md) 섹션을 참조하세요.
1. **자동 조정**의 경우, 대상 추적 조정 정책을 생성할지 여부를 선택합니다. Auto Scaling 그룹을 생성한 후에 이 정책을 생성할 수도 있습니다.
**대상 추적 조정 정책**을 선택하는 경우, [대상 추적 조정 정책 생성](policy_creating.md)의 지침에 따라 정책을 생성하십시오.
1. **인스턴스 유지 관리 정책**에서 인스턴스 유지 관리 정책을 만들지 여부를 선택합니다. Auto Scaling 그룹을 생성한 후에 이 정책을 생성할 수도 있습니다. [인스턴스 유지 관리 정책 설정](set-instance-maintenance-policy.md)의 지침에 따라 정책을 만듭니다.
1. **추가 용량 설정**, **용량 예약 기본 설정**에서 용량 예약 기본 설정을 사용할지 여부를 선택합니다. 자세한 내용은 [용량 예약을 사용하여 특정 가용 영역의 용량 예약](use-ec2-capacity-reservations.md) 단원을 참조하십시오.
1. **추가 설정**, **인스턴스 스케일 인 보호**에서 인스턴스 스케일 인 보호를 활성화할지 여부를 선택합니다. 자세한 내용은 [인스턴스 스케일 인 보호를 사용하여 인스턴스 종료 제어](ec2-auto-scaling-instance-protection.md) 단원을 참조하십시오.
1. **모니터링**에서 CloudWatch 그룹 지표 수집 사용 여부를 선택합니다. 이러한 지표는 해지 인스턴스 수 또는 보류 중인 인스턴스 수와 같은 잠재적 문제의 지표가 될 수 있는 측정값을 제공합니다. 자세한 내용은 [Auto Scaling 그룹 및 인스턴스에 대한 CloudWatch 지표 모니터링](ec2-auto-scaling-cloudwatch-monitoring.md) 단원을 참조하십시오.
1. **기본 인스턴스 워밍업**에서 이 옵션을 선택하고 애플리케이션의 워밍업 시간을 선택합니다. 조정 정책이 있는 Auto Scaling 그룹을 생성하는 경우, 기본 인스턴스 워밍업 기능은 동적 조정에 사용되는 Amazon CloudWatch 지표를 개선합니다. 자세한 내용은 [Auto Scaling 그룹의 기본 인스턴스 워밍업 설정](ec2-auto-scaling-default-instance-warmup.md) 단원을 참조하십시오.
1. (선택 사항) **알림 추가** 페이지에서 알림을 구성하고 **다음**을 선택합니다. 자세한 내용은 [Amazon EC2 Auto Scaling에 대한 Amazon SNS 알림 옵션](ec2-auto-scaling-sns-notifications.md) 단원을 참조하십시오.
1. (선택 사항) **태그 추가** 페이지에서 **태그 추가**를 선택하고 각 태그에 태그 키와 값을 제공한 후 **다음**을 선택합니다. 자세한 내용은 [Auto Scaling 그룹 및 인스턴스에 태그 지정](ec2-auto-scaling-tagging.md) 단원을 참조하십시오.
1. **검토(Review)** 페이지에서 **Auto Scaling 그룹 생성(Create Auto Scaling group)**을 선택합니다.
**명령행을 사용하여 Auto Scaling 그룹을 생성하려면**
다음 명령 중 하나를 사용할 수 있습니다:
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)(AWS CLI)
+ [New-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html)(AWS Tools for Windows PowerShell)
# Amazon EC2 시작 마법사를 사용하여 Auto Scaling 그룹 생성
다음 절차는 Amazon EC2 콘솔에서 **인스턴스 시작(Launch instance)** 마법사를 사용하여 Auto Scaling 그룹을 생성하는 방법을 보여줍니다. 이 옵션은 **인스턴스 시작(Launch instance)** 마법사의 특정 구성 세부 정보로 시작 템플릿을 자동으로 채웁니다.
**참고**
마법사는 지정한 인스턴스 수로 Auto Scaling 그룹을 채우지 않으며, Amazon Machine Image(AMI) 및 인스턴스 유형으로 시작 템플릿만 채웁니다. **Auto Scaling 그룹 생성(Create Auto Scaling group)** 마법사를 사용하여 시작할 인스턴스 수를 지정합니다.
AMI는 인스턴스를 구성하는 데 필요한 정보를 제공합니다. 동일한 구성의 인스턴스가 여러 개 필요할 때는 한 AMI에서 여러 인스턴스를 시작할 수 있습니다. Auto Scaling 그룹에 속한 인스턴스를 재부팅할 경우, 인스턴스가 해지되지 않도록 이미 애플리케이션이 설치된 사용자 정의 AMI를 사용하는 것이 좋습니다. Amazon EC2 Auto Scaling에서 사용자 정의 AMI를 사용하려면 먼저 사용자 지정 인스턴스에서 AMI를 생성한 다음 AMI를 사용하여 Auto Scaling 그룹에 대한 시작 템플릿을 생성해야 합니다.
**사전 조건**
+ Auto Scaling 그룹을 생성하려는 AWS 리전 동일한에서 사용자 지정 AMI를 생성해야 합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [AMI 생성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html)을 참조하세요.
## 사용자 지정 AMI를 템플릿으로 사용
이 섹션에서는 Amazon EC2 시작 마법사를 사용하여 사용자 지정 AMI로 시작 템플릿을 자동으로 채웁니다. 또는 시작 템플릿을 처음부터 설정하거나 시작 템플릿에 대해 구성할 수 있는 파라미터에 대한 자세한 설명을 보려면 [시작 템플릿 생성(콘솔)](create-launch-template.md#create-launch-template-for-auto-scaling)을 참조하세요.
**사용자 정의 AMI를 템플릿으로 사용**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 화면 상단의 탐색 모음에 현재 AWS 리전 가 표시됩니다. Auto Scaling 그룹을 시작할 지역을 선택합니다.
1. 탐색 창에서 **인스턴스**를 선택합니다.
1. **인스턴스 시작(Launch instance)**을 선택하고 다음을 수행하십시오:
1. **이름 및 태그(Name and tags)**에서 **이름(Name)**을 비워 둡니다. 이름은 시작 템플릿을 생성하는 데 사용되는 데이터의 일부가 아닙니다.
1. **애플리케이션 및 OS 이미지(Amazon Machine Image)(Application and OS Images (Amazon Machine Image))**에서 **더 많은 AMI 찾아보기(Browse more AMIs)**를 선택하여 전체 AMI 카탈로그를 찾아봅니다.
1. **내 AMI(My AMIs)**를 선택하고 앞서 생성한 AMI를 찾은 다음 **선택(Select)**을 선택합니다.
1. **인스턴스 유형(Instance type)**에서 인스턴스 유형을 선택합니다.
**참고**
AMI를 생성할 때 사용한 것과 동일한 인스턴스 유형 또는 더 강력한 인스턴스 유형을 선택합니다.
1. 화면 오른쪽의 **요약(Summary)**에서 **인스턴스 수(Number of instances)**에 원하는 숫자를 입력합니다. 여기에 입력하는 숫자는 중요하지 않습니다. 시작할 인스턴스 수는 Auto Scaling 그룹을 생성할 때 지정합니다.
**인스턴스 수(Number of instances)** 필드 아래에 **2개 이상의 인스턴스를 시작할 때 EC2 Auto Scaling 고려(When launching more than 1 instance, consider EC2 Auto Scaling)**라는 메시지가 표시됩니다.
1. **EC2 Auto Scaling 고려(consider EC2 Auto Scaling)** 하이퍼링크 텍스트를 선택합니다.
1. **Auto Scaling 그룹 시작(Launch into Auto Scaling Group)** 확인 대화 상자에서 **계속(Continue)**을 선택하여 시작 인스턴스 마법사에서 선택한 AMI 및 인스턴스 유형이 이미 채워진 **시작 템플릿 생성(Create launch template)** 페이지로 이동합니다.
**계속(Continue)**을 선택하면 **시작 템플릿 생성(Create launch template)** 페이지가 열립니다. 다음 절차에 따라 시작 템플릿 생성을 완료하십시오.
**시작 템플릿 생성**
1. **시작 템플릿 이름 및 설명(Launch template name and description)**에서 새 시작 템플릿의 이름과 설명을 입력합니다.
1. (옵션) **키 페어(로그인)(Key pair (login))** 아래의 **키 페어 이름(Key pair name)**에서 인스턴스에 연결할 때 사용할 이전에 생성한 키 페어의 이름을 선택합니다(예: SSH 사용).
1. (옵션) **네트워크 설정(Network settings)** 아래의 **보안 그룹(Security groups)**에서 이전에 생성한 [보안 그룹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)을 하나 이상 선택합니다.
1. (옵션) **스토리지 구성(Configure storage)**에서 스토리지 구성을 업데이트합니다. AMI와 인스턴스 유형에 따라 기본 스토리지 구성이 결정됩니다.
1. 시작 템플릿 구성이 끝나면 **시작 템플릿 생성(Create launch template)**을 선택합니다.
1. 확인 페이지에서 **Create Auto Scaling group**(Auto Scaling 그룹 생성)을 선택합니다.
## Auto Scaling 그룹 생성
**참고**
이 주제의 나머지 부분에서는 Auto Scaling 그룹을 생성하는 기본 절차를 설명합니다. Auto Scaling 그룹에 대해 구성할 수 있는 파라미터에 대한 자세한 설명은 [시작 템플릿을 사용하여 Auto Scaling 그룹 생성](create-asg-launch-template.md) 섹션을 참조하세요.
**Auto Scaling 그룹 생성(Create Auto Scaling group)**을 선택하면 **Auto Scaling 그룹(Auto Scaling group)** 마법사가 열립니다. 다음 절차에 따라 Auto Scaling 그룹을 생성합니다.
**Auto Scaling 그룹을 생성하려면**
1. **시작 템플릿 또는 구성 선택** 페이지에서 Auto Scaling 그룹의 이름을 입력합니다.
1. 생성한 시작 템플릿이 이미 선택되어 있습니다.
**Launch template version**(시작 템플릿 버전)에서 Auto Scaling 그룹이 스케일 아웃 시 시작 템플릿의 기본 버전을 사용할지, 최신 버전을 사용할지, 아니면 특정 버전을 사용할지를 선택합니다.
1. **다음(Next)**을 선택하여 다음 단계로 계속 진행합니다.
1. **인스턴스 시작 옵션** 선택 페이지에서 여러 인스턴스 유형을 사용하지 않는 경우, **인스턴스 유형 요건** 섹션을 건너뛰고 시작 템플릿에 지정된 EC2 인스턴스 유형을 사용할 수 있습니다.
여러 인스턴스 유형을 사용하려면 [여러 인스턴스 유형 및 구매 옵션이 포함된 Auto Scaling 그룹](ec2-auto-scaling-mixed-instances-groups.md)을 참조하십시오.
1. **네트워크(Network)**의 **VPC**에서 VPC를 선택합니다. Auto Scaling 그룹은 시작 템플릿에서 지정한 보안 그룹과 동일한 VPC에 생성되어야 합니다.
**작은 정보**
시작 템플릿에 보안 그룹을 지정하지 않은 경우, 지정한 VPC의 기본 보안 그룹으로 인스턴스가 시작됩니다. 기본적으로 이 보안 그룹은 외부 네트워크로부터의 인바운드 트래픽을 허용하지 않습니다.
1. **가용 영역 및 서브넷**에서 지정한 VPC에 있는 서브넷 하나 이상을 선택합니다.
1. **가용 영역 배포**에서 배포 전략을 선택합니다. 자세한 내용은 [Auto Scaling 그룹 가용 영역 배포](ec2-auto-scaling-availability-zone-balanced.md) 단원을 참조하십시오.
1. **다음(Next)**을 두 번 선택하여 **그룹 크기 및 조정 정책 구성(Configure group size and scaling policies)** 페이지로 이동합니다.
1. **그룹 크기**에서 **원하는 용량**(Auto Scaling 그룹이 생성된 후 즉시 실행할 초기 인스턴스 수)을 정의합니다.
1. **스케일링** 섹션의 **스케일링 제한**에서 **희망 용량**에 대한 새 값이 **최소 희망 용량** 및 **최대 희망 용량**보다 큰 경우, **최대 희망 용량**은 자동으로 새 희망 용량 값으로 증가합니다. 필요에 따라 이러한 한도를 변경할 수 있습니다. 자세한 설명은 [Auto Scaling 그룹에 대한 스케일링 제한 설정](asg-capacity-limits.md) 섹션을 참조하세요.
1. **Skip to review**(검토로 건너뛰기)를 선택합니다.
1. **검토(Review)** 페이지에서 **Auto Scaling 그룹 생성(Create Auto Scaling group)**을 선택합니다.
## 다음 단계
Auto Scaling 그룹이 제대로 생성되었는지는 활동 기록을 통해 확인할 수 있습니다. **활동(Activity)** 탭의 **활동 기록(Activity history)**에 있는 **상태(Status)** 열에 Auto Scaling 그룹이 성공적으로 인스턴스를 시작했는지가 표시됩니다. 인스턴스가 시작되지 않거나 시작되었지만 즉시 해지되는 경우, 가능한 원인 및 해결 방법은 다음 주제를 참조하세요.
+ [Amazon EC2 Auto Scaling 문제 해결: EC2 인스턴스 시작 실패](ts-as-instancelaunchfailure.md)
+ [Amazon EC2 Auto Scaling 문제 해결: AMI 문제](ts-as-ami.md)
+ [Amazon EC2 Auto Scaling의 비정상 인스턴스 문제 해결](ts-as-healthchecks.md)
이제 원하는 경우, Auto Scaling 그룹과 동일한 지역에서 로드 밸런서를 연결할 수 있습니다. 자세한 설명은 [Auto Scaling 그룹에 들어오는 애플리케이션 트래픽을 분산하기 위해 Elastic Load Balancing 사용](autoscaling-load-balancer.md) 섹션을 참조하세요.
# 여러 인스턴스 유형 및 구매 옵션이 포함된 Auto Scaling 그룹
단일 Auto Scaling 그룹 내에서 온디맨드 인스턴스 및 스팟 인스턴스 플릿를 자동으로 확장할 수 있습니다. 스팟 인스턴스 사용에 대한 할인뿐만 아니라 예약 인스턴스 또는 절감형 플랜을 사용하여 일반 온디맨드 인스턴스 요금에서도 할인을 받을 수 있습니다. 이러한 요소를 활용하여 EC2 인스턴스의 비용 절감을 최적화하고 애플리케이션에서 원하는 규모 및 성능을 얻을 수 있습니다.
스팟 인스턴스는 EC2 온디맨드 요금에 비해 크게 할인된 가격으로 사용할 수 있는 예비 용량입니다. 스팟 인스턴스는 애플리케이션이 실행되는 시간을 유연하게 조정할 수 있고 애플리케이션을 중단할 수 있는 경우에 선택하는 비용 효율적인 방법입니다. 다양한 내결함성 및 유연한 애플리케이션에 사용할 수 있습니다. 예를 들어 상태 비저장 웹 서버, API 엔드포인트, 빅 데이터 및 분석 애플리케이션, 컨테이너형 워크로드, CI/CD 파이프라인, 고성능 컴퓨팅 및 고처리량 컴퓨팅(HPC/HTC), 렌더링 워크로드 및 기타 유연한 워크로드 등이 있습니다.
자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 구매 옵션](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)을 참조하세요.
**Topics**
+ [혼합 인스턴스 그룹 생성을 위한 설정 개요](mixed-instances-groups-set-up-overview.md)
+ [여러 인스턴스 유형에 대한 할당 전략](allocation-strategies.md)
+ [속성 기반 인스턴스 유형 선택을 사용하여 혼합 인스턴스 그룹 생성](create-mixed-instances-group-attribute-based-instance-type-selection.md)
+ [인스턴스 유형을 수동으로 선택하여 혼합 인스턴스 그룹 생성](create-mixed-instances-group-manual-instance-type-selection.md)
+ [인스턴스 가중치를 사용하도록 Auto Scaling 그룹 구성](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)
+ [여러 시작 템플릿 사용](ec2-auto-scaling-mixed-instances-groups-launch-template-overrides.md)
# 혼합 인스턴스 그룹 생성을 위한 설정 개요
이 주제에서는 Auto Scaling 혼합 인스턴스 그룹 생성에 대한 개요와 모범 사례를 제공합니다.
**Topics**
+ [개요](#mixed-instances-groups-overview)
+ [인스턴스 유형 유연성](#mixed-instances-group-instance-flexibility)
+ [가용 영역 유연성](#mixed-instances-group-az-flexibility)
+ [스팟 최고가](#mixed-instances-group-spot-max-price)
+ [사전 대응 용량 재분배](#use-capacity-rebalancing)
+ [크기 조정 동작](#mixed-instances-group-scaling-behavior)
+ [인스턴스 유형의 지역별 가용성](#setup-overview-regional-availability-of-instance-types)
+ [관련 리소스](#setup-overview-related-resources)
+ [제한 사항](#setup-overview-limitations)
## 개요
혼합 인스턴스 그룹 생성을 위한 두 가지 옵션은 다음과 같습니다.
+ [속성 기반 인스턴스 유형 선택](create-mixed-instances-group-attribute-based-instance-type-selection.md) - 특정 인스턴스 속성에 따라 인스턴스 유형을 자동으로 선택하도록 컴퓨팅 요구 사항을 정의합니다.
+ [수동 인스턴스 유형 선택](create-mixed-instances-group-manual-instance-type-selection.md) - 워크로드에 적합한 인스턴스 유형을 수동으로 선택합니다.
------
#### [ Manual selection ]
다음 단계에서는 인스턴스 유형을 수동으로 선택하여 혼합 인스턴스 그룹을 생성하는 방법을 설명합니다.
1. EC2 인스턴스를 시작하기 위한 파라미터가 포함된 시작 템플릿을 선택합니다. 시작 템플릿의 파라미터는 선택 사항이지만 amilong;(AMI) ID가 시작 템플릿에 없는 경우 Amazon EC2 Auto Scaling에서 인스턴스를 시작할 수 없습니다.
1. 시작 템플릿을 재정의하는 옵션을 선택합니다.
1. 워크로드에 적합한 인스턴스 유형을 수동으로 선택합니다.
1. 시작할 온디맨드 인스턴스 및 스팟 인스턴스의 비율을 지정합니다.
1. Amazon EC2 Auto Scaling이 가능한 인스턴스 유형에서 온디맨드 및 스팟 용량을 충족하는 방법을 결정하는 할당 전략을 선택하세요.
1. 인스턴스를 시작할 가용 영역 및 VPC 서브넷을 선택합니다.
1. 그룹의 초기 크기(원하는 용량)와 그룹의 최소 및 최대 크기를 지정합니다.
시작 템플릿에 선언된 인스턴스 유형을 재정의하고 Auto Scaling 그룹의 자체 리소스 정의에 포함된 여러 인스턴스 유형을 사용하려면 재정의가 필요합니다. 사용 가능한 인스턴스 유형에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)을 참조하세요.
또한 각 인스턴스 유형에 대해 다음과 같은 선택적 파라미터를 구성할 수 있습니다.
+ `LaunchTemplateSpecification` - 필요에 따라 인스턴스 유형에 서로 다른 시작 템플릿을 할당할 수 있습니다. 현재 콘솔에서는 이 옵션을 사용할 수 없습니다. 자세한 내용은 [여러 시작 템플릿 사용](ec2-auto-scaling-mixed-instances-groups-launch-template-overrides.md) 단원을 참조하십시오.
+ `WeightedCapacity` - 원하는 용량으로 계산되는 인스턴스의 양을 그룹 내 나머지 인스턴스와 비교하여 결정합니다. 하나의 인스턴스 유형에 대해 `WeightedCapacity` 값을 지정하는 경우 모든 인스턴스 유형에 대해 `WeightedCapacity` 값을 지정해야 합니다. 기본적으로 각 인스턴스는 원하는 용량에 대해 1개로 계산됩니다. 자세한 내용은 [인스턴스 가중치를 사용하도록 Auto Scaling 그룹 구성](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)(을)를 참조하세요.
------
#### [ Attribute-based selection ]
Amazon EC2 Auto Scaling에서 특정 인스턴스 속성에 따라 인스턴스 유형을 자동으로 선택하도록 하려면 다음 단계를 사용하여 컴퓨팅 요구 사항을 지정하고 혼합 인스턴스 그룹을 생성하세요.
1. EC2 인스턴스를 시작하기 위한 파라미터가 포함된 시작 템플릿을 선택합니다. 시작 템플릿의 파라미터는 선택 사항이지만 amilong;(AMI) ID가 시작 템플릿에 없는 경우 Amazon EC2 Auto Scaling에서 인스턴스를 시작할 수 없습니다.
1. 시작 템플릿을 재정의하는 옵션을 선택합니다.
1. vCPU 및 메모리 요구 사항 등의 컴퓨팅 요구 사항과 일치하는 인스턴스 속성을 지정합니다.
1. 시작할 온디맨드 인스턴스 및 스팟 인스턴스의 비율을 지정합니다.
1. Amazon EC2 Auto Scaling이 가능한 인스턴스 유형에서 온디맨드 및 스팟 용량을 충족하는 방법을 결정하는 할당 전략을 선택하세요.
1. 인스턴스를 시작할 가용 영역 및 VPC 서브넷을 선택합니다.
1. 그룹의 초기 크기(원하는 용량)와 그룹의 최소 및 최대 크기를 지정합니다.
시작 템플릿에 선언된 인스턴스 유형을 재정의하고 컴퓨팅 요구 사항을 설명하는 인스턴스 속성 세트를 사용하려면 재정의가 필요합니다. 지원되는 속성은 *Amazon EC2 Auto Scaling API 참조*의 [InstanceRequirements](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstanceRequirements.html)를 참조하세요. 또는 인스턴스 속성 정의가 이미 있는 시작 템플릿을 사용할 수 있습니다.
필요에 따라 인스턴스 요구 사항 세트에 다른 시작 템플릿을 할당하도록 재정의 구조 내에서 `LaunchTemplateSpecification` 파라미터를 구성할 수도 있습니다. 현재 콘솔에서는 이 옵션을 사용할 수 없습니다. 자세한 내용은 *Amazon EC2 Auto Scaling API 참조*의 [LaunchTemplateOverrides](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_LaunchTemplateOverrides.html)를 참조하세요.
기본적으로 인스턴트 수를 Auto Scaling 그룹의 원하는 용량으로 설정합니다.
또는 원하는 용량 값을 vCPU 수 또는 메모리 양으로 설정할 수 있습니다. 이렇게 하려면, `CreateAutoScalingGroup` API 작업의 `DesiredCapacityType` 속성을 사용하거나 AWS Management Console의 **원하는 용량 유형** 드롭다운 필드를 사용합니다. 이는 [인스턴스 가중치](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)에 대한 유용한 대안입니다.
------
## 인스턴스 유형 유연성
가용성을 높이려면 애플리케이션을 여러 인스턴스 유형에 배포합니다. 용량 요구 사항을 충족하려면 여러 인스턴스 유형을 사용하는 것이 가장 좋습니다. 이러한 방식으로 Amazon EC2 Auto Scaling은 선택한 가용 영역에 인스턴스 용량이 부족한 경우 다른 인스턴스 유형을 시작할 수 있습니다.
스팟 인스턴스에 인스턴스 용량이 부족할 경우 Amazon EC2 Auto Scaling은 다른 스팟 인스턴스 풀에서 시작하려고 계속 시도합니다. (사용하는 풀은 선택한 인스턴스 유형 및 할당 전략에 따라 결정됩니다.) Amazon EC2 Auto Scaling을 사용하면 온디맨드 인스턴스 대신 스팟 인스턴스를 시작하여 스팟 인스턴스의 비용 절감 효과를 활용할 수 있습니다.
각 워크로드에 대해 최소 10개의 인스턴스 유형을 유연하게 선택할 것을 권장합니다. 인스턴스 유형을 선택할 때 가장 많이 사용되는 새 인스턴스 유형으로 사용자 자신을 제한하지 마세요. 이전 세대의 인스턴스 유형을 선택하면 온디맨드 고객의 수요가 적기 때문에 스팟 중단이 적은 경향이 있습니다.
## 가용 영역 유연성
Auto Scaling 그룹을 여러 가용 영역으로 확장하는 것이 좋습니다. 여러 가용 영역을 사용하면 복원력을 높이기 위해 영역 간에 자동으로 장애 조치가 이루어지는 애플리케이션을 설계할 수 있습니다.
추가 이점으로, 단일 가용 영역의 그룹과 비교할 때 더 깊은 Amazon EC2 용량 풀에 액세스할 수 있습니다. 용량은 각 가용 영역에서 인스턴스 유형과 관계없이 변동되므로, 인스턴스 유형과 가용 영역이 둘 다 유연한 경우 대부분 더 많은 컴퓨팅 용량을 확보할 수 있습니다.
다중 가용 영역 사용에 대한 자세한 내용은 [예: 가용 영역 전반에 인스턴스 분산](auto-scaling-benefits.md#arch-AutoScalingMultiAZ)(을)를 참조하세요.
## 스팟 최고가
AWS CLI 또는 SDK를 사용하여 Auto Scaling 그룹을 생성할 때 `SpotMaxPrice` 파라미터를 지정할 수 있습니다. `SpotMaxPrice` 파라미터는 스팟 인스턴스 시간당 지불하려는 최고 가격을 결정합니다.
오버라이드(그룹 수준의 `"DesiredCapacityType": "vcpu"` 또는 `"DesiredCapacityType": "memory-mib"`)에서 `WeightedCapacity` 파라미터를 지정하는 경우 최고 가격은 전체 인스턴스의 최고 가격이 아니라 최고 단가를 나타냅니다.
최고 가격을 지정하지 않는 것이 매우 좋습니다. 스팟 인스턴스를 받지 못하면(예: 최고가가 너무 낮은 경우) 애플리케이션이 실행되지 않을 수 있습니다. 최고 가격을 지정하지 않는 경우, 기본 최고 가격은 온디맨드 가격입니다. 시작하는 스팟 인스턴스에 대해 스팟 가격만 지불합니다. 스팟 인스턴스에서 제공하는 대폭 할인 금액은 여전히 적용됩니다. 이러한 할인은 [스팟 요금 모델](https://aws.amazon.com/blogs/compute/new-amazon-ec2-spot-pricing/)을 사용해 실현된 안정적인 스팟 요금 덕분에 가능해진 것입니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [요금 및 비용 절감](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html#spot-pricing)을 참조하세요.
## 사전 대응 용량 재분배
사용 사례에서 허용하는 경우, 용량 재분배를 권장합니다. 용량 재조정은 중단 위험이 있는 스팟 인스턴스를 선제적으로 교체하여 워크로드 가용성을 유지하도록 도와줍니다.
용량 재조정을 활성화하면 Amazon EC2 Auto Scaling이 EC2 인스턴스 재분배 권장 사항을 받은 스팟 인스턴스를 사전에 교체하려고 합니다. 이는 중단 위험이 높지 않은 새로운 스팟 인스턴스로 워크로드를 재조정할 수 있는 기회를 제공합니다.
자세한 내용은 [위험 상태의 스팟 인스턴스를 대체하기 위한 Auto Scaling의 용량 재조정](ec2-auto-scaling-capacity-rebalancing.md) 단원을 참조하십시오.
## 크기 조정 동작
혼합 인스턴스 그룹을 생성하면 기본적으로 온디맨드 인스턴스가 사용됩니다. 스팟 인스턴스를 사용하려면 온디맨드 인스턴스로 시작할 그룹의 비율을 수정해야 합니다. 온디맨드 백분율에 0에서 100까지의 숫자를 지정할 수 있습니다.
선택 사항으로, 시작할 온디맨드 인스턴스의 기본 수를 지정할 수도 있습니다. 이러한 경우 Amazon EC2 Auto Scaling은 그룹 스케일 아웃 시 온디맨드 인스턴스의 기본 용량을 시작한 후에만 스팟 인스턴스를 시작합니다. 기본 용량을 초과하는 용량은 온디맨드 백분율을 사용하여 시작할 온디맨드 인스턴스 및 스팟 인스턴스 수를 결정합니다.
Amazon EC2 Auto Scaling은 백분율을 상응하는 인스턴스 수로 변환합니다. 변환 결과에 소수가 포함되면 온디맨드 인스턴스를 위해 다음 정수로 반올림합니다.
이 수가 증가하거나 감소할 경우 Auto Scaling 그룹은 다음 표와 같이 동작합니다.
**예: 확장 동작**
| 구매 옵션 | 구매 옵션 전체에서 실행되는 인스턴스 그룹의 크기와 수 |
| --- |--- |
| | **10** | **20** | **30** | **40** |
| --- |--- |--- |--- |--- |
| **예 1**: 기본 10, 50/50% 온디맨드/스팟 | | | | |
| On-Demand Instances (base amount) | 10 | 10 | 10 | 10 |
| On-Demand Instances | 0 | 5 | 10 | 15 |
| Spot Instances | 0 | 5 | 10 | 15 |
| **예 2**: 기본 0, 0/100% 온디맨드/스팟 | | | | |
| On-Demand Instances (base amount) | 0 | 0 | 0 | 0 |
| On-Demand Instances | 0 | 0 | 0 | 0 |
| Spot Instances | 10 | 20 | 30 | 40 |
| **예 3**: 기본 0, 60/40% 온디맨드/스팟 | | | | |
| On-Demand Instances (base amount) | 0 | 0 | 0 | 0 |
| On-Demand Instances | 6 | 12 | 18 | 24 |
| Spot Instances | 4 | 8 | 12 | 16 |
| **예 4**: 기본 0, 100/0% 온디맨드/스팟 | | | | |
| On-Demand Instances (base amount) | 0 | 0 | 0 | 0 |
| On-Demand Instances | 10 | 20 | 30 | 40 |
| Spot Instances | 0 | 0 | 0 | 0 |
| **예 5**: 기본 12, 0/100% 온디맨드/스팟 | | | | |
| On-Demand Instances (base amount) | 10 | 12 | 12 | 12 |
| On-Demand Instances | 0 | 0 | 0 | 0 |
| Spot Instances | 0 | 8 | 18 | 28 |
그룹 크기가 *커지면* Amazon EC2 Auto Scaling이 지정된 가용 영역 전체에 용량을 고르게 유지하도록 조정합니다. 그런 다음, 지정한 할당 전략에 따라 인스턴스 유형을 시작합니다.
그룹 크기가 *줄어들면* Amazon EC2 Auto Scaling이 먼저 두 가지 유형(스팟 또는 온디맨드) 중 종료해야 하는 유형을 식별합니다. 그런 다음, 지정된 가용 영역 전체에서 균형 잡힌 방식으로 인스턴스 종료를 시도합니다. 또한 할당 전략에 더 가깝게 정렬하는 방식으로 인스턴스를 종료하는 것이 좋습니다. 종료 정책에 대한 자세한 내용은 [Amazon EC2 Auto Scaling의 종료 정책 구성](ec2-auto-scaling-termination-policies.md)(을)를 참조하세요.
## 인스턴스 유형의 지역별 가용성
EC2 인스턴스 유형의 가용성은에 따라 다릅니다 AWS 리전. 예를 들어, 최신 세대 인스턴스 유형을 지정된 리전에서 아직 사용하지 못할 수 있습니다. 리전마다 인스턴스 가용성이 다르기 때문에 재정의의 여러 인스턴스 유형을 해당 리전에서 사용할 수 없는 경우 프로그래밍 방식 요청을 할 때 문제가 발생할 수 있습니다. 해당 리전에서 사용할 수 없는 여러 인스턴스 유형을 사용하면 요청이 완전히 실패할 수 있습니다. 문제를 해결하려면 다양한 인스턴스 유형으로 요청을 재시도하고 해당 리전에서 각 인스턴스 유형을 사용할 수 있는지 확인합니다. 위치별로 제공되는 인스턴스 유형을 검색하려면 [describe-instance-type-offerings](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-instance-type-offerings.html) 명령을 사용합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 인스턴스 유형 찾기](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html)를 참조하세요.
## 관련 리소스
스팟 인스턴스의 모범 사례에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [EC2 스팟 모범 사례](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html)를 참조하세요.
## 제한 사항
[혼합 인스턴스 정책](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MixedInstancesPolicy.html)을 사용하여 Auto Scaling 그룹에 재정의를 추가한 후에는 `UpdateAutoScalingGroup` API 직접 호출로 재정의를 업데이트할 수 있지만 삭제할 수는 없습니다. 재정의를 완전히 제거하려면 먼저 Auto Scaling 그룹을 전환하여 혼합 인스턴스 정책 대신 시작 템플릿 또는 시작 구성을 사용해야 합니다. 그런 다음 재정의 없이 혼합 인스턴스 정책을 다시 추가할 수 있습니다.
# 여러 인스턴스 유형에 대한 할당 전략
여러 인스턴스 유형을 사용하는 경우 Amazon EC2 Auto Scaling이 가능한 인스턴스 유형으로 온디맨드 및 스팟 용량을 충족하는 방식을 관리할 수 있습니다. 이를 위해서는 할당 전략을 지정해야 합니다.
혼합 인스턴스 그룹의 모범 사례를 검토하려면 [혼합 인스턴스 그룹 생성을 위한 설정 개요](mixed-instances-groups-set-up-overview.md) 섹션을 참조하세요.
**Topics**
+ [스팟 인스턴스](#spot-allocation-strategy)
+ [온디맨드 인스턴스](#on-demand-allocation-strategy)
+ [할당 전략이 가중치로 작동하는 방식](#lowest-price-allocation-strategy)
## 스팟 인스턴스
Amazon EC2 Auto Scaling은 스팟 인스턴스에 사용할 수 있는 다음과 같은 할당 전략을 제공합니다.
`price-capacity-optimized`(권장)
가격 및 용량 최적화 할당 전략은 가격과 용량을 모두 고려하여 중단될 가능성이 가장 낮으면서 가격이 가장 낮은 스팟 인스턴스 풀을 선택합니다.
시작할 때는 이 전략을 사용하는 것이 좋습니다. 자세한 내용은 AWS 블로그[의 EC2 스팟 인스턴스에 대한 price-capacity-optimized 할당 전략 소개](https://aws.amazon.com/blogs/compute/introducing-price-capacity-optimized-allocation-strategy-for-ec2-spot-instances/)를 참조하세요.
`capacity-optimized`
Amazon EC2 Auto Scaling이 시작하는 인스턴스의 수에 대한 최적 용량의 스팟 인스턴스 풀에서 스팟 인스턴스를 요청합니다.
스팟 인스턴스에서 요금은 시간이 지나면서 수요 및 공급의 장기 추세에 따라 서서히 변화합니다. 하지만, 용량은 실시간으로 변동됩니다. `capacity-optimized` 전략은 실시간 용량 데이터를 기준으로 가장 가용성이 높은 풀을 예측하여 자동으로 스팟 인스턴스를 가장 가용성이 높은 풀로 시작합니다. 이를 통해 작업 재시작 및 체크포인트 수행과 연관된 중단 비용이 높을 수 있는 워크로드에 대한 중단 가능성을 최소화하는 데 도움이 됩니다. 특정 인스턴스 유형이 먼저 시작될 확률을 높이려면 `capacity-optimized-prioritized`를 사용합니다.
`capacity-optimized-prioritized`
시작 템플릿 재정의 목록의 인스턴스 유형 순서를 가장 높은 우선순위에서 가장 낮은 우선순위 순서로(목록의 첫 번째부터 마지막까지) 설정합니다. Amazon EC2 Auto Scaling은 최상의 노력으로 인스턴스 유형 우선순위를 준수하지만 먼저 용량을 최적화합니다. 이 옵션은 중단 가능성을 최소화해야 하지만 특정 인스턴스 유형에 대한 선호도가 중요한 워크로드에 적합합니다. 온디맨드 할당 전략을 `prioritized`로 설정하면 온디맨드 용량을 이행할 때 동일한 우선순위가 적용됩니다.
`lowest-price` (권장되지 않음)
`lowest-price` 전략은 스팟 인스턴스의 중단 위험이 가장 높기 때문에 권장하지 않습니다.
Amazon EC2 Auto Scaling은 **최저가 풀** 설정에 대해 지정한 N개의 스팟 풀 개수에 걸쳐 가용 영역 내에서 최저가인 풀을 사용하여 스팟 인스턴스를 요청합니다. 예를 들어, 인스턴스 유형 4개와 가용 영역 4개를 지정한 경우 Auto Scaling 그룹은 최대 16개의 스팟 풀에 액세스할 수 있습니다. (가용 영역당 4개) 할당 전략을 위해 스팟 풀 2개(N=2)를 지정한 경우 Auto Scaling 그룹이 가용 영역당 가장 저렴한 두 개의 풀에서 스팟 용량을 충족할 수 있습니다.
`lowest-price` 전략은 AWS CLI를 사용하는 경우에만 제공됩니다.
Amazon EC2 Auto Scaling은 지정된 N개의 풀에서 스팟 인스턴스를 끌어오려고 합니다. 하지만, 원하는 용량을 충족하기 전에 풀에 스팟 용량이 부족해질 경우 Amazon EC2 Auto Scaling은 다음으로 저렴한 풀에서 끌어와 요청을 계속 이행합니다. 원하는 용량을 충족하기 위해, 지정한 N개보다 많은 풀에서 스팟 인스턴스를 받게 될 수 있습니다. 마찬가지로 대부분의 풀에 스팟 용량이 없는 경우 지정한 N개보다 적은 풀에서 원하는 전체 용량을 받게 될 수 있습니다.
**참고**
[AMD SEV-SNP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sev-snp.html)가 켜진 상태에서 스팟 인스턴스를 시작하도록 구성하면 선택한 인스턴스 유형의 [온디맨드 시간당 요금](https://aws.amazon.com/ec2/pricing/on-demand/)의 10%에 상응하는 시간당 사용 요금이 추가로 부과됩니다. 할당 전략에서 가격을 입력으로 사용하는 경우 Amazon EC2 Auto Scaling에는 이 추가 요금이 포함되지 않고 스팟 가격만 사용됩니다.
## 온디맨드 인스턴스
Amazon EC2 Auto Scaling은 온디맨드 인스턴스에 사용할 수 있는 다음 할당 전략을 제공합니다.
`lowest-price`
Amazon EC2 Auto Scaling은 현재 온디맨드 가격을 기준으로 각 가용 영역에 가장 저렴한 인스턴스 유형을 자동으로 배포합니다.
원하는 용량을 충족하기 위해서, 각 가용 영역에서 둘 이상의 인스턴스 유형의 온디맨드 인스턴스를 수신할 수 있습니다. 이는 요청한 용량에 따라 달라집니다.
`prioritized`
온디맨드 용량을 이행할 때, Amazon EC2 Auto Scaling은 시작 템플릿 재정의 목록에 있는 인스턴스 유형 순서를 기반으로 우선 사용할 인스턴스 유형을 결정합니다. 예를 들어, 세 가지 시작 템플릿 재정의를 `c5.large`, `c4.large`, `c3.large` 순으로 지정했다고 가정해 보겠습니다. 온디맨드 인스턴스가 시작되면 Auto Scaling 그룹이 `c5.large`, `c4.large`, `c3.large` 순으로 온디맨드 용량을 채웁니다.
온디맨드 인스턴스의 우선순위 순서를 관리할 때는 다음 사항을 고려하세요.
+ 사용량에 대해 선결제하면 예약 인스턴스 또는 절감형 플랜을 사용하여 온디맨드 인스턴스에 대해 상당한 할인을 받을 수 있습니다. 자세한 정보는 [Amazon EC2 요금](https://aws.amazon.com/ec2/pricing/) 페이지를 참조하세요.
+ 예약 인스턴스의 경우 Amazon EC2 Auto Scaling에서 일치하는 인스턴스 유형을 시작할 경우 일반 온디맨드 인스턴스 요금의 할인율이 적용됩니다. 따라서, `c4.large`에 사용되지 않은 예약 인스턴스가 있는 경우 인스턴스 유형 우선순위를 설정하여 예약 인스턴스의 `c4.large` 인스턴스 유형에 가장 높은 우선순위를 지정할 수 있습니다. `c4.large` 인스턴스가 시작되면 예약 인스턴스 요금을 받게 됩니다.
+ 절감형 플랜을 사용하는 경우, Amazon EC2 인스턴스 절감형 플랜 또는 컴퓨팅 절감형 플랜을 사용할 때 일반 온디맨드 인스턴스 요금의 할인율이 적용됩니다. 절감형 플랜을 사용하면 인스턴스 유형의 우선순위를 유연하게 지정할 수 있습니다. 절감형 플랜이 적용되는 인스턴스 유형을 사용하는 한, 어떤 우선순위로든 인스턴스를 설정할 수 있습니다. 또한 가끔 절감형 플랜 할인 요금을 받으면서 인스턴스 유형의 전체 순서를 변경할 수 있습니다. 절감형 플랜에 대한 자세한 정보는 [절감형 플랜 사용 설명서](https://docs.aws.amazon.com/savingsplans/latest/userguide/)를 참조하세요.
## 할당 전략이 가중치로 작동하는 방식
재정의(그룹 수준의 `"DesiredCapacityType": "vcpu"` 또는 `"DesiredCapacityType": "memory-mib"`)에서 `WeightedCapacity` 파라미터를 지정하는 경우 할당 전략은 다른 Auto Scaling 그룹에서와 똑같이 수행됩니다.
다양한 양의 vCPU를 가진 여러 인스턴스 유형이 있는 Auto Scaling 그룹이 있다고 가정해 봅시다. 스팟 및 온디맨드 할당 전략에 대해 `lowest-price`를 사용합니다. 각 인스턴스 유형의 vCPU 수를 기준으로 가중치를 할당하도록 선택하면 Amazon EC2 Auto Scaling은 이행 시점에 할당된 가중치 값당(예: vCPU당) 가격이 가장 저렴한 인스턴스 유형을 시작합니다. 스팟 인스턴스인 경우 이는 vCPU당 최저 스팟 가격을 의미합니다. 온디맨드 인스턴스인 경우 이는 vCPU당 최저 온디맨드 가격을 의미합니다.
자세한 내용은 [인스턴스 가중치를 사용하도록 Auto Scaling 그룹 구성](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md) 단원을 참조하십시오.
# 속성 기반 인스턴스 유형 선택을 사용하여 혼합 인스턴스 그룹 생성
혼합 인스턴스 그룹을 위한 인스턴스 유형을 수작업으로 선택하는 대신 컴퓨팅 요건을 기술하는 인스턴스 속성 집합을 지정할 수 있습니다. Amazon EC2 Auto Scaling이 인스턴스를 시작할 때 Auto Scaling 그룹에서 사용하는 모든 인스턴스 유형은 필요한 인스턴스 속성과 일치해야 합니다. 이를 *속성 기반 인스턴스 유형 선택*이라고 합니다.
이 접근 방식은 컨테이너, 빅 데이터 및 CI/CD와 같이 사용하는 인스턴스 유형에 대해 유연한 워크로드 및 프레임워크에 이상적입니다.
속성 기반 인스턴스 유형을 선택하면 다음과 같은 이점이 있습니다.
+ **스팟 인스턴스를 위한 최적의 유연성** - Amazon EC2 Auto Scaling은 스팟 인스턴스 시작을 위해 다양한 인스턴스 유형 중에서 선택할 수 있습니다. 이는 Amazon EC2 스팟 서비스가 필요한 양의 컴퓨팅 용량을 찾고 할당할 수 있는 더 나은 기회를 제공하는 인스턴스 유형에 대한 유연성이라는 스팟 모범 사례를 충족합니다.
+ **쉽게 올바른 인스턴스 유형 사용** - 사용 가능한 인스턴스 유형이 너무 많기 때문에 워크로드에 적합한 인스턴스 유형을 찾는 데 시간이 많이 걸릴 수 있습니다. 인스턴스 속성을 지정하면 인스턴스 유형에는 워크로드에 필요한 속성이 자동으로 포함됩니다.
+ **새로운 인스턴스 유형 자동 사용** - Auto Scaling 그룹은 릴리스되는 최신 세대 인스턴스 유형을 사용할 수 있습니다. 최신 세대 인스턴스 유형은 요건과 일치하고 Auto Scaling 그룹에 대해 선택한 할당 전략과 일치하면 자동으로 사용됩니다.
**Topics**
+ [속성 기반 인스턴스 유형 선택 작동 방법](#how-attribute-based-instance-type-selection-works)
+ [가격 보호](#understand-price-protection)
+ [성능 보호](#understand-performance-protection)
+ [사전 조건](#attribute-based-instance-type-selection-prerequisites)
+ [속성 기반 인스턴스 유형 선택을 사용하여 혼합 인스턴스 그룹 생성(콘솔)](#attribute-based-instance-type-selection-console)
+ [속성 기반 인스턴스 유형 선택을 사용하여 혼합 인스턴스 그룹 생성(AWS CLI)](#attribute-based-instance-type-selection-aws-cli)
+ [구성의 예](#attribute-based-instance-type-selection-example-configurations)
+ [인스턴스 유형 미리 보기](#attribute-based-instance-type-selection-preview)
+ [관련 리소스](#attribute-based-instance-type-selection-related-resources)
## 속성 기반 인스턴스 유형 선택 작동 방법
속성 기반 인스턴스 유형 선택을 통해 특정 인스턴스 유형 목록을 제공하는 대신 인스턴스에 필요한 다음과 같은 인스턴스 속성 목록을 제공합니다.
+ **vCPU 수** – 인스턴스당 최소 및 최대 vCPU 수입니다.
+ **메모리** - 인스턴스당 최소 및 최대 메모리 GiB입니다.
+ **로컬 스토리지** - 로컬 스토리지에 EBS를 사용할지 아니면 인스턴스 스토어 볼륨을 사용할지입니다.
+ **성능 버스트 기능** – T4g, T3a, T3 및 T2 유형을 포함한 T 인스턴스 패밀리를 사용할지 여부입니다.
인스턴스 요구 사항을 정의하는 데 사용할 수 있는 옵션이 많이 있습니다. 각 옵션 및 기본값에 대한 설명은 *Amazon EC2 Auto Scaling API 참조*의 [InstanceRequirements](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstanceRequirements.html)를 참조하세요.
Auto Scaling 그룹이 인스턴스를 시작해야 하는 경우 지정된 속성과 일치하고 해당 가용 영역에서 사용할 수 있는 인스턴스 유형을 검색합니다. 할당 전략에 따라 매칭 인스턴스 중에서 시작할 인스턴스 유형이 결정됩니다. 기본적으로 속성 기반 인스턴스 유형 선택에는 Auto Scaling 그룹이 예산 임곗값을 초과하는 인스턴스 유형을 시작하지 못하도록 가격 보호 기능이 활성화되어 있습니다.
기본적으로 Auto Scaling 그룹의 원하는 용량을 설정할 때 인스턴스 수를 측정 단위로 사용합니다. 즉, 각 인스턴스는 하나의 단위로 계산됩니다.
또는 원하는 용량 값을 vCPU 수 또는 메모리 양으로 설정할 수 있습니다. 이렇게 하려면의 **원하는 용량 유형** 드롭다운 필드 AWS Management Console 또는 `CreateAutoScalingGroup` 또는 `UpdateAutoScalingGroup` API 작업의 `DesiredCapacityType` 속성을 사용합니다. 그런 다음 Amazon EC2 Auto Scaling은 원하는 vCPU 또는 메모리 용량을 충족하는 데 필요한 수의 인스턴스를 시작합니다. 예를 들어 vCPU를 원하는 용량 유형으로 사용하고 각각 vCPU가 2개인 인스턴스를 사용하는 경우, 원하는 용량인 vCPU 10개가 인스턴스 5개를 시작합니다. 이는 [인스턴스 가중치](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)에 대한 유용한 대안입니다.
## 가격 보호
가격 보호를 사용하면 Auto Scaling 그룹에서 시작한 EC2 인스턴스에 대해 지불할 최대 가격을 지정할 수 있습니다. 가격 보호는 Auto Scaling 그룹이 사용자가 지정한 속성에 적합하더라도 너무 비싼 인스턴스 유형을 사용하지 못하게 방지하는 기능입니다.
가격 보호는 기본적으로 활성화되어 있으며 온디맨드 인스턴스와 스팟 인스턴스에 대해 별도의 가격 임곗값이 있습니다. Amazon EC2 Auto Scaling에서 새 인스턴스를 시작해야 하는 경우 가격이 관련 임곗값을 초과하는 인스턴스 유형은 시작되지 않습니다.
**Topics**
+ [온디맨드 가격 보호](#on-demand-price-price-protection)
+ [스팟 가격 보호](#spot-price-price-protection)
+ [가격 보호 사용자 지정](#customize-price-price-protection)
### 온디맨드 가격 보호
온디맨드 인스턴스의 경우 식별된 온디맨드 가격보다 더 높은 비율로 지불할 최대 온디맨드 가격을 정의합니다. 식별된 온디맨드 가격은 지정된 속성이 있는 최저 가격의 현재 세대 C, M 또는 R 인스턴스 유형의 가격입니다.
온디맨드 가격 보호 값이 명시적으로 정의되지 않은 경우, 식별된 온디맨드 가격보다 20% 높은 기본 최대 온디맨드 가격이 사용됩니다.
### 스팟 가격 보호
기본적으로 Amazon EC2 Auto Scaling은 다양한 인스턴스 유형 중에서 일관되게 선택할 수 있도록 최적의 스팟 인스턴스 가격 보호를 자동으로 적용합니다. 가격 보호를 직접 수동으로 설정할 수도 있습니다. 하지만 Amazon EC2 Auto Scaling이 자동으로 수행하면 스팟 용량이 충족될 가능성을 높일 수 있습니다.
다음 옵션 중 하나를 사용하여 가격 보호를 수동으로 지정할 수 있습니다. 가격 보호를 수동으로 설정하는 경우 첫 번째 옵션을 사용하는 것이 좋습니다.
+ **식별된 *온디맨드 가격*의 비율** - 식별된 온디맨드 가격은 지정된 속성이 있는 최저 가격의 현재 세대 C, M 또는 R 인스턴스 유형의 가격입니다.
+ **식별된 *스팟 가격*보다 높은 비율** - 식별된 스팟 가격은 지정된 속성이 있는 최저 가격의 현재 세대 C, M 또는 R 인스턴스 유형의 가격입니다. 스팟 가격은 변동될 수 있어 가격 보호 기준도 변동될 수 있으므로 이 옵션을 사용하지 않는 것이 좋습니다.
### 가격 보호 사용자 지정
Amazon EC2 Auto Scaling 콘솔에서 또는 AWS CLI 또는 SDKs.
+ 콘솔에서 **추가 인스턴스 속성**의 **온디맨드 가격 보호** 및 **스팟 가격 보호** 설정을 사용합니다.
+ [InstanceRequirements](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstanceRequirements.html) 구조에서 온디맨드 인스턴스 가격 보호 임곗값을 지정하려면 `OnDemandMaxPricePercentageOverLowestPrice` 속성을 사용합니다. 스팟 인스턴스 가격 보호 임곗값을 지정하려면 `MaxSpotPriceAsPercentageOfOptimalOnDemandPrice` 또는 `SpotMaxPricePercentageOverLowestPrice` 속성을 사용합니다.
**원하는 용량 유형**(`DesiredCapacityType`)을 **vCPU** 또는 **메모리 GiB**로 설정하면 가격 보호가 인스턴스당 가격이 아닌 vCPU당 또는 메모리당 가격을 기준으로 적용됩니다.
가격 보호를 끌 수도 있습니다. 가격 보호 기준이 없음을 나타내려면 `999999`와 같은 높은 백분율 값을 지정합니다.
**참고**
현재 세대 C, M 또는 R 인스턴스 유형이 지정된 속성과 일치하지 않는 경우에도 가격 보호가 적용됩니다. 일치하는 항목이 없는 경우 식별된 가격은 가장 저렴한 현재 세대 인스턴스 유형에서 가져온 것이거나 속성과 일치하는 가장 저렴한 이전 세대 인스턴스 유형에서 가져온 것입니다.
## 성능 보호
*성능 보호*는 Auto Scaling 그룹이 지정된 성능 기준과 비슷하거나 이를 초과하는 인스턴스 유형을 사용하도록 하는 기능입니다. 성능 보호를 사용하려면 인스턴스 패밀리를 기준 참조로 지정합니다. 지정된 인스턴스 패밀리의 기능에 따라 허용 가능한 최저 수준의 성능이 정해집니다. Auto Scaling이 인스턴스 유형을 선택할 때는 사용자가 지정한 속성과 성능 기준을 고려합니다. 성능 기준보다 낮은 인스턴스 유형은 사용자가 지정한 다른 속성과 일치하더라도 선택에서 자동으로 제외됩니다. 이렇게 하면 선택한 모든 인스턴스 유형이 지정된 인스턴스 패밀리에서 설정한 기준과 비슷하거나 더 나은 성능을 제공할 수 있습니다. Auto Scaling은 이 기준을 사용하여 인스턴스 유형 선택을 안내하지만, 선택한 인스턴스 유형이 모든 애플리케이션의 기준을 항상 초과한다는 보장은 없습니다.
현재 이 기능은 CPU 성능만 기준 성능 요소로 지원합니다. 지정된 인스턴스 패밀리의 CPU 성능은 성능 기준 역할을 하며 선택한 인스턴스 유형이 이 기준과 비슷하거나 이를 초과하도록 합니다. CPU 프로세서가 동일한 인스턴스 패밀리는 네트워크 또는 디스크 성능이 다르더라도 필터링 결과가 동일합니다. 예를 들어 `c6in` 또는 `c6i`를 기준 참조로 지정하면 두 인스턴스 패밀리가 동일한 CPU 프로세서를 사용하기 때문에 동일한 성능 기반 필터링 결과가 생성됩니다.
**지원되지 않는 인스턴스 패밀리**
다음 인스턴스 패밀리는 성능 보호에서 지원되지 않습니다.
+ `c1`
+ `g3` \$1 `g3s`
+ `hpc7g`
+ `m1` \$1 `m2`
+ `mac1` \$1 `mac2` \$1 `mac2-m1ultra` \$1 `mac2-m2` \$1 `mac2-m2pro`
+ `p3dn` \$1 `p4d` \$1 `p5`
+ `t1`
+ `u-12tb1` \$1 `u-18tb1` \$1 `u-24tb1` \$1 `u-3tb1` \$1 `u-6tb1` \$1 `u-9tb1` \$1 `u7i-12tb` \$1 `u7in-16tb` \$1 `u7in-24tb` \$1 `u7in-32tb`
지원되는 인스턴스 패밀리를 지정하여 성능 보호를 활성화하면 위의 지원되지 않는 인스턴스 패밀리는 반환되는 인스턴스 유형에서 제외됩니다.
**예: CPU 성능 기준 설정**
다음 예제에서 인스턴스 요구 사항은 `c6i` 인스턴스 패밀리만큼 성능이 뛰어난 CPU 코어가 있는 인스턴스 유형으로 시작하는 것입니다. 이렇게 하면 vCPU 수 등 지정된 다른 인스턴스 요구 사항을 충족하더라도 CPU 성능이 이보다 낮은 인스턴스 유형은 필터링됩니다. 예를 들어 지정된 인스턴스 속성에 vCPU 4개와 메모리 16GB가 포함된 경우 이러한 속성이 있지만 CPU 성능이 `c6i`보다 낮은 인스턴스 유형은 선택에서 제외됩니다.
```
"BaselinePerformanceFactors": {
"Cpu": {
"References": [
{
"InstanceFamily": "c6i"
}
]
}
```
**고려 사항**
성능 보호를 사용할 때는 다음 사항을 고려하세요.
+ 인스턴스 유형 또는 인스턴스 속성을 지정할 수 있지만 둘 다 동시에 지정할 수는 없습니다.
+ 요청 구성에서 최대 4개의 `InstanceRequirements` 구조를 지정할 수 있습니다.
## 사전 조건
+ 시작 템플릿을 생성합니다. 자세한 설명은 [Auto Scaling 그룹에 대한 시작 템플릿 생성](create-launch-template.md) 섹션을 참조하세요.
+ 시작 템플릿이 아직 스팟 인스턴스를 요청하지 않았는지 확인합니다.
## 속성 기반 인스턴스 유형 선택을 사용하여 혼합 인스턴스 그룹 생성(콘솔)
속성 기반 인스턴스 유형 선택을 사용하여 혼합 인스턴스 그룹을 만들려면 다음 절차를 따르세요. 단계를 효율적으로 진행하는 데 도움이 되도록 일부 선택 사항 섹션은 생략했습니다.
대부분의 범용 워크로드의 경우, 필요한 vCPU의 수와 메모리를 지정하는 것으로 충분합니다. 고급 사용 사례의 경우, 스토리지 유형, 네트워크 인터페이스, CPU 제조업체, 액셀러레이터 유형 등의 속성을 지정할 수 있습니다.
혼합 인스턴스 그룹의 모범 사례를 검토하려면 [혼합 인스턴스 그룹 생성을 위한 설정 개요](mixed-instances-groups-set-up-overview.md) 섹션을 참조하세요.
**혼합 인스턴스 그룹을 생성하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. 화면 상단의 탐색 모음에서 시작 템플릿을 만들 때 사용한 지역과 동일한 AWS 리전 을 선택합니다.
1. **Create an Auto Scaling group**(Auto Scaling 그룹 생성)을 선택합니다.
1. **시작 템플릿 또는 구성 선택** 페이지에서 **Auto Scaling group name**(Auto Scaling 그룹 명칭)에 Auto Scaling 그룹의 이름을 입력합니다.
1. 시작 템플릿을 선택하려면 다음을 수행하십시오:
1. **시작 템플릿**에서 기존 시작 템플릿을 선택합니다.
1. **Launch template version**(시작 템플릿 버전)에서 Auto Scaling 그룹이 스케일 아웃 시 시작 템플릿의 기본 버전을 사용할지, 최신 버전을 사용할지, 아니면 특정 버전을 사용할지를 선택합니다.
1. 시작 템플릿이 사용하려는 모든 옵션을 지원하는지 확인한 후 **다음**을 선택합니다.
1. **인스턴스 시작 옵션 선택** 페이지에서 다음을 선택합니다:
1. **인스턴스 유형 요건(Instance type requirements)**에서 **시작 템플릿 재정의(Override launch template)**를 선택합니다.
**참고**
vCPU 및 메모리와 같은 인스턴스 속성 집합이 이미 포함된 시작 템플릿을 선택한 경우, 인스턴스 속성이 표시됩니다. 이러한 속성은 Auto Scaling 그룹 속성에 추가되며, 언제든지 Amazon EC2 Auto Scaling 콘솔에서 업데이트할 수 있습니다.
1. **인스턴스 속성 지정(Specify instance attributes)**에서 vCPU 및 메모리 요건을 입력하여 시작합니다.
+ **vCPU(vCPUs)**에 원하는 최소 및 최대 vCPU 수를 입력합니다. 무한을 지정하려면 **최소 없음(No minimum)**, **최대 없음(No maximum)** 또는 둘 다 선택합니다.
+ **메모리(GiB)(Memory (GiB))**에 원하는 최소 및 최대 메모리 양을 입력합니다. 무한을 지정하려면 **최소 없음(No minimum)**, **최대 없음(No maximum)** 또는 둘 다 선택합니다.
1. (선택 사항) **추가 인스턴스 속성(Additional instance attributes)**에서 필요에 따라 하나 이상의 속성을 지정하여 컴퓨팅 요구 사항을 더 자세히 표현할 수 있습니다. 각 추가 속성은 요청에 제약 조건을 추가합니다.
1. 지정한 속성을 가진 인스턴스 유형을 보려면 **일치하는 인스턴스 유형 미리 보기**를 확장합니다.
1. **인스턴스 구매 옵션**에서 **인스턴스 배포**에 대해 각각 온디맨드 인스턴스로 및 스팟 인스턴스로 시작시킬 그룹의 백분율을 지정합니다. 귀하의 애플리케이션이 무상태이고 내결함성이 있으며 중단되는 인스턴스를 처리할 수 있는 경우, 귀하는 더 높은 백분율의 스팟 인스턴스를 지정할 수 있습니다.
1. (옵션) 스팟 인스턴스를 위한 백분율을 지정할 때 **온디맨드 기본 용량 포함**란을 선택한 다음 온디맨드 인스턴스가 충족해야 하는 Auto Scaling 그룹 초기 용량의 최소량을 지정하십시오. 기본 용량을 초과하는 용량은 **인스턴스 배치(Instances distribution)** 설정을 사용하여 시작할 온디맨드 인스턴스 및 스팟 인스턴스 수를 결정합니다.
1. **할당 전략(Allocation strategies)** 아래에서 **온디맨드 할당 전략(On-Demand allocation strategy)**에 대해 **최저가(Lowest price)**가 자동으로 선택되며 변경할 수 없습니다.
1. **스팟 할당 전략(Spot allocation strategy)**에서 할당 전략을 선택합니다. **Price capacity optimized**(가격 용량 최적화)가 기본적으로 선택됩니다.
1. **용량 재조정**에서 용량 재조정을 활성화 또는 비활성화할지 선택합니다. 용량 재조정을 사용하여 스팟 중단으로 인해 스팟 인스턴스가 해지되려 할 때 자동화를 통해 대응하십시오. 자세한 설명은 [위험 상태의 스팟 인스턴스를 대체하기 위한 Auto Scaling의 용량 재조정](ec2-auto-scaling-capacity-rebalancing.md) 섹션을 참조하세요.
1. **네트워크(Network)**의 **VPC**에서 VPC를 선택합니다. Auto Scaling 그룹은 시작 템플릿에서 지정한 보안 그룹과 동일한 VPC에 생성되어야 합니다.
1. **가용 영역 및 서브넷(Availability Zones and subnets)**에서 지정한 VPC에 있는 서브넷을 하나 이상 선택합니다. 여러 가용 영역의 서브넷을 사용하여 가용성을 높일 수 있습니다. 자세한 설명은 [VPC 서브넷 선택 시 고려 사항](asg-in-vpc.md#as-vpc-considerations) 섹션을 참조하세요.
1. **다음**, **다음**을 선택합니다.
1. **그룹 크기 및 조정 정책 구성** 단계에서는 다음을 수행하십시오:
1. 원하는 용량을 인스턴스 이외의 다른 단위로 측정하려면, **그룹 크기**, **원하는 용량 유형**에서 적절한 옵션을 선택합니다. **Units**(단위), **vCPU**, **Memory GiB**(메모리 GiB)가 지원됩니다. 기본적으로 Amazon EC2 Auto Scaling은 인스턴스 수로 변환되는 **Units**(단위)를 지정합니다.
1. **원하는 용량**이란 Auto Scaling 그룹의 최초 크기입니다.
1. **스케일링** 섹션의 **스케일링 제한**에서 **희망 용량**에 대한 새 값이 **최소 희망 용량** 및 **최대 희망 용량**보다 큰 경우, **최대 희망 용량**은 자동으로 새 희망 용량 값으로 증가합니다. 필요에 따라 이러한 한도를 변경할 수 있습니다. 자세한 설명은 [Auto Scaling 그룹에 대한 스케일링 제한 설정](asg-capacity-limits.md) 섹션을 참조하세요.
1. **Skip to review**(검토로 건너뛰기)를 선택합니다.
1. **검토(Review)** 페이지에서 **Auto Scaling 그룹 생성(Create Auto Scaling group)**을 선택합니다.
## 속성 기반 인스턴스 유형 선택을 사용하여 혼합 인스턴스 그룹 생성(AWS CLI)
**명령행을 사용하여 혼합 인스턴스 그룹을 생성하려면**
다음 명령 중 하나를 사용합니다.
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)(AWS CLI)
+ [New-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html)(AWS Tools for Windows PowerShell)
## 구성의 예
AWS CLI을 사용하여 속성 기반 인스턴스 유형 선택으로 Auto Scaling 그룹을 생성하려면 다음 [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용하십시오.
다음과 같은 인스턴스 속성이 지정됩니다.
+ `VCpuCount` - 인스턴스 유형에는 최소 4개의 vCPU와 최대 8개의 vCPU가 있어야 합니다.
+ `MemoryMiB` - 인스턴스 유형에 최소 16,384MiB의 메모리가 있어야 새 시작 템플릿 버전을 생성하지 않은 경우합니다.
+ `CpuManufacturers` - 인스턴스 유형에는 인텔에서 제조한 CPU가 있어야 합니다.
### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
다음은 예 `config.json` 파일입니다.
```
{
"AutoScalingGroupName": "my-asg",
"DesiredCapacityType": "units",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Default"
},
"Overrides": [{
"InstanceRequirements": {
"VCpuCount": {"Min": 4, "Max": 8},
"MemoryMiB": {"Min": 16384},
"CpuManufacturers": ["intel"]
}
}]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 50,
"SpotAllocationStrategy": "price-capacity-optimized"
}
},
"MinSize": 0,
"MaxSize": 100,
"DesiredCapacity": 4,
"DesiredCapacityType": "units",
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
원하는 용량 값을 vCPU 수 또는 메모리 양으로 설정하려면 파일에서 `"DesiredCapacityType": "vcpu"` 또는 `"DesiredCapacityType": "memory-mib"`를 지정합니다. 기본 원하는 용량 유형은 원하는 용량 값을 인스턴스 수로 설정하는 `units`입니다.
### YAML
또는, 다음 [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용하여 Auto Scaling 그룹을 생성할 수 있습니다. 이는 Auto Scaling 그룹의 유일한 파라미터로 YAML 파일을 참조합니다.
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
다음은 예 `config.yaml` 파일입니다.
```
---
AutoScalingGroupName: my-asg
DesiredCapacityType: units
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceRequirements:
VCpuCount:
Min: 2
Max: 4
MemoryMiB:
Min: 2048
CpuManufacturers:
- intel
InstancesDistribution:
OnDemandPercentageAboveBaseCapacity: 50
SpotAllocationStrategy: price-capacity-optimized
MinSize: 0
MaxSize: 100
DesiredCapacity: 4
DesiredCapacityType: units
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
원하는 용량 값을 vCPU 수 또는 메모리 양으로 설정하려면 파일에서 `DesiredCapacityType: vcpu` 또는 `DesiredCapacityType: memory-mib`를 지정합니다. 기본 원하는 용량 유형은 원하는 용량 값을 인스턴스 수로 설정하는 `units`입니다.
속성 기반 인스턴스 유형 선택과 함께 여러 시작 템플릿을 사용하는 방법의 예는 [여러 시작 템플릿 사용](ec2-auto-scaling-mixed-instances-groups-launch-template-overrides.md) 섹션을 참조하세요.
## 인스턴스 유형 미리 보기
컴퓨팅 요건과 일치하는 인스턴스 유형을 시작하지 않고 미리 보고 필요한 경우, 요건을 조정할 수 있습니다. Amazon EC2 Auto Scaling 콘솔에서 Auto Scaling 그룹을 생성할 때 인스턴스 유형의 미리 보기가 **인스턴스 시작 옵션 선택(Choose instance launch options)** 페이지의 **일치하는 인스턴스 유형 미리 보기(Preview matching instance types)** 섹션에 나타납니다.
또는 AWS CLI 또는 또는 SDK를 사용하여 Amazon EC2 [GetInstanceTypesFromInstanceRequirements](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetInstanceTypesFromInstanceRequirements.html) API 호출을 수행하여 인스턴스 유형을 미리 볼 수 있습니다. Auto Scaling 그룹을 생성하거나 업데이트하는 데 사용할 정확한 형식으로 `InstanceRequirements` 파라미터를 요청에 전달합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [지정된 속성이 있는 인스턴스 유형 미리 보기](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html#ec2fleet-get-instance-types-from-instance-requirements)를 참조하세요.
## 관련 리소스
속성 기반 인스턴스 유형 선택에 대한 자세한 내용은 AWS 블로그의 [ EC2 Auto Scaling 및 EC2 플릿에 대한 속성 기반 인스턴스 유형 선택을](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/) 참조하세요.
CloudFormation을 사용하여 Auto Scaling 그룹을 생성할 때 속성 기반 인스턴스 유형 선택을 선언할 수 있습니다. 자세한 설명은 *CloudFormation 사용자 가이드*의 [Auto Scaling 템플릿 스니펫](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-autoscaling.html#scenario-mixed-instances-group-template-examples)에서 예 스니펫을 참조하세요.
# 인스턴스 유형을 수동으로 선택하여 혼합 인스턴스 그룹 생성
이 항목에서는 인스턴스 유형을 수동으로 선택하여 단일 Auto Scaling 그룹에서 여러 인스턴스 유형을 시작하는 방법을 보여줍니다.
인스턴스 유형을 선택하는 기준으로 인스턴스 속성을 사용하려는 경우 [속성 기반 인스턴스 유형 선택을 사용하여 혼합 인스턴스 그룹 생성](create-mixed-instances-group-attribute-based-instance-type-selection.md)(을)를 참조하세요.
**Topics**
+ [사전 조건](#manual-instance-type-selection-prerequisites)
+ [혼합 인스턴스 그룹 생성(콘솔)](#manual-instance-type-selection-console)
+ [혼합 인스턴스 그룹 생성 (AWS CLI)](#manual-instance-type-selection-aws-cli)
+ [구성의 예](#manual-instance-type-selection-example-configurations)
## 사전 조건
+ 시작 템플릿을 생성합니다. 자세한 설명은 [Auto Scaling 그룹에 대한 시작 템플릿 생성](create-launch-template.md) 섹션을 참조하세요.
+ 시작 템플릿이 아직 스팟 인스턴스를 요청하지 않았는지 확인합니다.
## 혼합 인스턴스 그룹 생성(콘솔)
다음 절차를 사용하여 그룹에서 시작할 수 있는 인스턴스 유형을 수동으로 선택하여 혼합 인스턴스 그룹을 생성합니다. 단계를 효율적으로 진행하는 데 도움이 되도록 일부 선택 사항 섹션은 생략했습니다.
혼합 인스턴스 그룹의 모범 사례를 검토하려면 [혼합 인스턴스 그룹 생성을 위한 설정 개요](mixed-instances-groups-set-up-overview.md) 섹션을 참조하세요.
**혼합 인스턴스 그룹을 생성하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. 화면 상단의 탐색 모음에서 시작 템플릿을 만들 때 사용한 지역과 동일한 AWS 리전 을 선택합니다.
1. **Create an Auto Scaling group**(Auto Scaling 그룹 생성)을 선택합니다.
1. **시작 템플릿 또는 구성 선택** 페이지에서 **Auto Scaling group name**(Auto Scaling 그룹 명칭)에 Auto Scaling 그룹의 이름을 입력합니다.
1. 시작 템플릿을 선택하려면 다음을 수행하십시오:
1. **시작 템플릿**에서 기존 시작 템플릿을 선택합니다.
1. **Launch template version**(시작 템플릿 버전)에서 Auto Scaling 그룹이 스케일 아웃 시 시작 템플릿의 기본 버전을 사용할지, 최신 버전을 사용할지, 아니면 특정 버전을 사용할지를 선택합니다.
1. 시작 템플릿이 사용하려는 모든 옵션을 지원하는지 확인한 후 **Next**(다음)를 선택합니다.
1. **인스턴스 시작 옵션 선택** 페이지에서 다음을 수행합니다.
1. **Instance type requirements**(인스턴스 유형 요구 사항)에서 **Override launch template**(시작 템플릿 재정의), **Manually add instance types**(수동으로 인스턴스 유형 추가)를 선택합니다.
1. 인스턴스 유형을 선택합니다. 권장 사항을 시작점으로 사용할 수 있습니다. **Family and generation flexible**(유연한 패밀리 및 세대)이 기본적으로 선택됩니다.
+ 인스턴스 유형의 순서를 변경하려면 화살표를 사용합니다. 우선순위 지정을 지원하는 할당 전략을 선택하면 인스턴스 유형 순서에 따라 시작 우선순위가 설정됩니다.
+ 인스턴스 유형을 제거하려면 **X**를 선택합니다.
+ (선택 사항) **가중치** 열의 상자에 대해 각 인스턴스 유형에 상대적 가중치를 할당합니다. 이렇게 하려면, 해당 유형의 인스턴스가 그룹의 원하는 용량에 포함되는 단위 수를 입력합니다. 인스턴스 유형마다 서로 다른 vCPU, 메모리, 스토리지 또는 네트워크 대역폭 기능을 제공하는 경우 이렇게 하는 것이 유용할 수 있습니다. 자세한 내용은 [인스턴스 가중치를 사용하도록 Auto Scaling 그룹 구성](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)(을)를 참조하세요.
**유연한 크기** 권장 사항 사용을 선택하는 경우 이 섹션에 포함된 모든 인스턴스 유형에는 자동으로 가중치 값이 지정됩니다. 가중치를 지정하지 않으려면 모든 인스턴스 유형의 **Weight**(가중치) 열에 있는 상자를 지웁니다.
1. **Instance purchase options**(인스턴스 구매 옵션)에서 **Instances distribution**(인스턴스 배포)에 대해 각각 온디맨드 인스턴스 및 스팟 인스턴스로 시작할 그룹의 비율을 지정합니다. 애플리케이션이 무상태이고 내결함성이 있으며 중단되는 인스턴스를 처리할 수 있는 경우 더 높은 비율의 스팟 인스턴스를 지정할 수 있습니다.
1. (옵션) 스팟 인스턴스를 위한 백분율을 지정할 때 **온디맨드 기본 용량 포함**란을 선택한 다음 온디맨드 인스턴스가 충족해야 하는 Auto Scaling 그룹 초기 용량의 최소량을 지정하십시오. 기본 용량을 초과하는 용량은 **인스턴스 배치(Instances distribution)** 설정을 사용하여 시작할 온디맨드 인스턴스 및 스팟 인스턴스 수를 결정합니다.
1. **할당 전략(Allocation strategies)**에서 **온디맨드 할당 전략(On-Demand allocation strategy)**에 대해 할당 전략을 선택합니다. 인스턴스 유형을 수동으로 선택하면 기본적으로 **Prioritized**(우선순위 지정됨)가 선택됩니다.
1. **스팟 할당 전략(Spot allocation strategy)**에서 할당 전략을 선택합니다. **Price capacity optimized**(가격 용량 최적화)가 기본적으로 선택됩니다.
**용량 최적화**를 선택한 경우 필요에 따라 **인스턴스 유형 우선순위 지정** 확인란을 선택하여 Amazon EC2 Auto Scaling이 인스턴스 유형 나열 순서에 따라 먼저 시작할 인스턴스 유형을 선택할 수 있습니다.
1. **용량 재분배**에서 용량 재분배를 활성화 또는 비활성화할지 선택합니다. 용량 재조정을 사용하여 스팟 중단으로 인해 스팟 인스턴스가 해지되려 할 때 자동화를 통해 대응하십시오. 자세한 설명은 [위험 상태의 스팟 인스턴스를 대체하기 위한 Auto Scaling의 용량 재조정](ec2-auto-scaling-capacity-rebalancing.md) 섹션을 참조하세요.
1. **네트워크(Network)**의 **VPC**에서 VPC를 선택합니다. Auto Scaling 그룹은 시작 템플릿에서 지정한 보안 그룹과 동일한 VPC에 생성되어야 합니다.
1. **가용 영역 및 서브넷(Availability Zones and subnets)**에서 지정한 VPC에 있는 서브넷을 하나 이상 선택합니다. 여러 가용 영역의 서브넷을 사용하여 가용성을 높일 수 있습니다. 자세한 설명은 [VPC 서브넷 선택 시 고려 사항](asg-in-vpc.md#as-vpc-considerations) 섹션을 참조하세요.
1. **다음**, **다음**을 선택합니다.
1. **그룹 크기 및 조정 정책 구성** 단계에서는 다음을 수행하십시오:
1. **그룹 크기**의 **원하는 용량**에서 시작할 초기 인스턴스 수를 입력합니다.
기본적으로 원하는 용량은 인스턴스 수로 표시됩니다. 인스턴스 유형에 가중치를 할당한 경우 이러한 값을 가중치를 할당할 때 사용되는 것과 동일한 측정 단위(예: vCPU 수)로 변환해야 합니다.
1. **스케일링** 섹션의 **스케일링 제한**에서 **희망 용량**에 대한 새 값이 **최소 희망 용량** 및 **최대 희망 용량**보다 큰 경우, **최대 희망 용량**은 자동으로 새 희망 용량 값으로 증가합니다. 필요에 따라 이러한 한도를 변경할 수 있습니다. 자세한 설명은 [Auto Scaling 그룹에 대한 스케일링 제한 설정](asg-capacity-limits.md) 섹션을 참조하세요.
1. **Skip to review**(검토로 건너뛰기)를 선택합니다.
1. **검토(Review)** 페이지에서 **Auto Scaling 그룹 생성(Create Auto Scaling group)**을 선택합니다.
## 혼합 인스턴스 그룹 생성 (AWS CLI)
**명령행을 사용하여 혼합 인스턴스 그룹을 생성하려면**
다음 명령 중 하나를 사용합니다.
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)(AWS CLI)
+ [New-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html)(AWS Tools for Windows PowerShell)
## 구성의 예
다음 예제 구성은 여러 스팟 할당 전략을 사용하여 혼합 인스턴스 그룹을 생성하는 방법을 보여 줍니다.
**참고**
다음 예에서는 JSON 또는 YAML로 형식이 지정된 구성 파일을 사용하는 방법을 보여 줍니다. AWS CLI 버전 1을 사용하는 경우 JSON 형식의 구성 파일을 지정해야 합니다. AWS CLI 버전 2를 사용하는 경우 YAML 또는 JSON 형식의 구성 파일을 지정할 수 있습니다.
**Topics**
+ [예제 1: `capacity-optimized` 할당 전략을 사용하여 스팟 인스턴스 시작](#capacity-optimized-aws-cli)
+ [예제 2: `capacity-optimized-prioritized` 할당 전략을 사용하여 스팟 인스턴스 시작](#capacity-optimized-prioritized-aws-cli)
+ [예제 3: 두 개의 풀로 분산된 `lowest-price` 할당 전략을 사용한 스팟 인스턴스 시작](#lowest-price-aws-cli)
+ [예 4: `price-capacity-optimized` 할당 전략을 사용하여 스팟 인스턴스 시작](#price-capacity-optimized-aws-cli)
### 예제 1: `capacity-optimized` 할당 전략을 사용하여 스팟 인스턴스 시작
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령은 다음을 지정하는 Auto Scaling 그룹을 생성합니다.
+ 온디맨드 인스턴스로 시작할 그룹의 백분율(`0`) 및 온디맨드 인스턴스의 처음 시작 기본 개수(`1`)
+ 우선순위(`c5.large`, `c5a.large`, `m5.large`, `m5a.large`, `c4.large`, `m4.large`, `c3.large`, `m3.large`)에 따라 시작할 인스턴스 유형
+ 인스턴스(`subnet-5ea0c127`, `subnet-6194ea3b`, `subnet-c934b782`)를 시작하는 서브넷 각각 다른 가용 영역에 해당합니다.
+ 시작 템플릿(`my-launch-template`) 및 시작 템플릿 버전(`$Default`)
Amazon EC2 Auto Scaling이 온디맨드 용량을 채우려고 시도하는 경우 `c5.large` 인스턴스 유형을 먼저 시작합니다. 스팟 인스턴스는 스팟 인스턴스 용량에 따라 각 가용 영역의 최적의 스팟 풀에서 나옵니다.
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` 파일에는 다음 내용이 포함되어 있습니다.
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Default"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandBaseCapacity": 1,
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "capacity-optimized"
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
또는, 다음 [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용하여 Auto Scaling 그룹을 생성할 수 있습니다. 이는 YAML 파일을 Auto Scaling 그룹의 유일한 파라미터로 참조합니다.
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
`config.yaml` 파일에는 다음 콘텐츠가 포함되어 있습니다.
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandBaseCapacity: 1
OnDemandPercentageAboveBaseCapacity: 0
SpotAllocationStrategy: capacity-optimized
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
### 예제 2: `capacity-optimized-prioritized` 할당 전략을 사용하여 스팟 인스턴스 시작
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령은 다음을 지정하는 Auto Scaling 그룹을 생성합니다.
+ 온디맨드 인스턴스로 시작할 그룹의 백분율(`0`) 및 온디맨드 인스턴스의 처음 시작 기본 개수(`1`)
+ 우선순위(`c5.large`, `c5a.large`, `m5.large`, `m5a.large`, `c4.large`, `m4.large`, `c3.large`, `m3.large`)에 따라 시작할 인스턴스 유형
+ 인스턴스(`subnet-5ea0c127`, `subnet-6194ea3b`, `subnet-c934b782`)를 시작하는 서브넷 각각 다른 가용 영역에 해당합니다.
+ 시작 템플릿(`my-launch-template`) 및 시작 템플릿 버전(`$Latest`)
Amazon EC2 Auto Scaling이 온디맨드 용량을 채우려고 시도하는 경우 `c5.large` 인스턴스 유형을 먼저 시작합니다. Amazon EC2 Auto Scaling은 스팟 용량을 충족하려고 할 때 최대한 인스턴스 유형 우선순위를 준수합니다. 그러나, 먼저 용량을 최적화합니다.
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` 파일에는 다음 내용이 포함되어 있습니다.
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandBaseCapacity": 1,
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "capacity-optimized-prioritized"
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
또는, 다음 [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용하여 Auto Scaling 그룹을 생성할 수 있습니다. 이는 YAML 파일을 Auto Scaling 그룹의 유일한 파라미터로 참조합니다.
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
`config.yaml` 파일에는 다음 콘텐츠가 포함되어 있습니다.
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandBaseCapacity: 1
OnDemandPercentageAboveBaseCapacity: 0
SpotAllocationStrategy: capacity-optimized-prioritized
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
### 예제 3: 두 개의 풀로 분산된 `lowest-price` 할당 전략을 사용한 스팟 인스턴스 시작
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령은 다음을 지정하는 Auto Scaling 그룹을 생성합니다.
+ 온디맨드 인스턴스로 시작할 그룹의 백분율(`50`) (이것은 시작할 온디맨드 인스턴스의 기본 수를 지정하지 않습니다.)
+ 우선순위(`c5.large`, `c5a.large`, `m5.large`, `m5a.large`, `c4.large`, `m4.large`, `c3.large`, `m3.large`)에 따라 시작할 인스턴스 유형
+ 인스턴스(`subnet-5ea0c127`, `subnet-6194ea3b`, `subnet-c934b782`)를 시작하는 서브넷 각각 다른 가용 영역에 해당합니다.
+ 시작 템플릿(`my-launch-template`) 및 시작 템플릿 버전(`$Latest`)
Amazon EC2 Auto Scaling이 온디맨드 용량을 채우려고 시도하는 경우 `c5.large` 인스턴스 유형을 먼저 시작합니다. 스팟 용량의 경우, Amazon EC2 Auto Scaling은 각 가용 영역 내 가장 낮은 가격의 풀 2개에 걸쳐 스팟 인스턴스를 균등하게 시작하려고 시도합니다.
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` 파일에는 다음 내용이 포함되어 있습니다.
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 50,
"SpotAllocationStrategy": "lowest-price",
"SpotInstancePools": 2
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
또는, 다음 [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용하여 Auto Scaling 그룹을 생성할 수 있습니다. 이는 YAML 파일을 Auto Scaling 그룹의 유일한 파라미터로 참조합니다.
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
`config.yaml` 파일에는 다음 콘텐츠가 포함되어 있습니다.
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandPercentageAboveBaseCapacity: 50
SpotAllocationStrategy: lowest-price
SpotInstancePools: 2
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
### 예 4: `price-capacity-optimized` 할당 전략을 사용하여 스팟 인스턴스 시작
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령은 다음을 지정하는 Auto Scaling 그룹을 생성합니다.
+ 온디맨드 인스턴스로 시작할 그룹의 백분율(`30`) (이것은 시작할 온디맨드 인스턴스의 기본 수를 지정하지 않습니다.)
+ 우선순위(`c5.large`, `c5a.large`, `m5.large`, `m5a.large`, `c4.large`, `m4.large`, `c3.large`, `m3.large`)에 따라 시작할 인스턴스 유형
+ 인스턴스(`subnet-5ea0c127`, `subnet-6194ea3b`, `subnet-c934b782`)를 시작하는 서브넷 각각 다른 가용 영역에 해당합니다.
+ 시작 템플릿(`my-launch-template`) 및 시작 템플릿 버전(`$Latest`)
Amazon EC2 Auto Scaling이 온디맨드 용량을 채우려고 시도하는 경우 `c5.large` 인스턴스 유형을 먼저 시작합니다. 스팟 인스턴스의 경우, Amazon EC2 Auto Scaling은 가능한 한 낮은 가격뿐만 아니라 시작하는 인스턴스 수에 대한 최적의 용량으로 스팟 인스턴스 풀에서 스팟 인스턴스를 시작하려고 시도합니다.
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` 파일에는 다음 내용이 포함되어 있습니다.
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 30,
"SpotAllocationStrategy": "price-capacity-optimized"
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
또는, 다음 [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용하여 Auto Scaling 그룹을 생성할 수 있습니다. 이는 YAML 파일을 Auto Scaling 그룹의 유일한 파라미터로 참조합니다.
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
`config.yaml` 파일에는 다음 콘텐츠가 포함되어 있습니다.
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandPercentageAboveBaseCapacity: 30
SpotAllocationStrategy: price-capacity-optimized
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
# 인스턴스 가중치를 사용하도록 Auto Scaling 그룹 구성
여러 인스턴스 유형을 사용하는 경우 각 인스턴스 유형과 연결할 단위 수를 지정한 다음 동일한 측정 단위로 그룹의 용량을 지정할 수 있습니다. 이러한 용량 사양 옵션을 가중치라고 합니다.
예를 들어, 최소 8개의 vCPU 및 15GiB의 RAM에서 최적의 성능을 발휘하는 컴퓨팅 집약적 애플리케이션을 실행하는 경우, `c5.2xlarge`를 기본 유닛으로 사용할 때 다음 EC2 인스턴스 유형은 모두 애플리케이션 요구 사항을 충족합니다.
**인스턴스 유형의 예**
| 인스턴스 유형 | vCPU | 메모리(GiB) |
| --- | --- | --- |
| c5.2xlarge | 8 | 16 |
| c5.4xlarge | 16 | 32 |
| c5.12xlarge | 48 | 96 |
| c5.18xlarge | 72 | 144 |
| c5.24xlarge | 96 | 192 |
기본적으로 모든 인스턴스 유형은 크기에 관계없이 동일한 가중치를 갖습니다. Amazon EC2 Auto Scaling이 인스턴스를 시작하면 해당 인스턴스 유형이 크든 작든 각 인스턴스가 Auto Scaling 그룹의 원하는 용량에 동일하게 가산됩니다.
하지만 가중치를 사용하는 경우 각 인스턴스 유형에 연결할 단위 수를 지정하는 숫자 값을 할당하게 됩니다. 예를 들어, 인스턴스 간의 크기가 서로 다른 경우 `c5.2xlarge` 인스턴스의 가중치는 2, `c5.4xlarge`(2배 더 큼)의 가중치는 4와 같은 식으로 지정할 수 있습니다. 그런 다음, Amazon EC2 Auto Scaling이 그룹을 조정할 때 가중치는 원하는 용량에 각 인스턴스가 가산되는 유닛 수로 변환됩니다.
가중치는 Amazon EC2 Auto Scaling에서 시작하려는 인스턴스 유형을 변경하지 않고, 대신 할당 전략이 변경합니다. 자세한 내용은 [여러 인스턴스 유형에 대한 할당 전략](allocation-strategies.md)(을)를 참조하세요.
**중요**
각 인스턴스 유형의 vCPU 수 또는 메모리 양을 사용하여 원하는 용량을 채우도록 Auto Scaling 그룹을 구성하려면 속성 기반 인스턴스 유형 선택을 사용하는 것이 좋습니다. `DesiredCapacityType` 파라미터를 설정하면 이 파라미터에 대해 설정한 값을 기반으로 각 인스턴스 유형과 연결할 단위 수가 자동으로 지정됩니다. 자세한 내용은 [속성 기반 인스턴스 유형 선택을 사용하여 혼합 인스턴스 그룹 생성](create-mixed-instances-group-attribute-based-instance-type-selection.md) 단원을 참조하십시오.
**Topics**
+ [고려 사항](#weights-considerations)
+ [인스턴스 가중치 동작](#instance-weighting-behaviors)
+ [가중치를 사용하도록 Auto Scaling 그룹 구성](configue-auto-scaling-group-to-use-weights.md)
+ [단위 시간당 스팟 가격의 예](weights-spot-price-per-unit-hour-example.md)
## 고려 사항
이 섹션에서는 가중치를 효과적으로 구현하는 데 필요한 주요 고려 사항을 설명합니다.
+ 애플리케이션의 성능 요구 사항에 맞는 몇 가지 인스턴스 유형을 선택합니다. 각 인스턴스 유형이 Auto Scaling 그룹의 원하는 용량에 포함되어야 하는 가중치를 해당 기능에 따라 결정합니다. 가중치는 현재 인스턴스와 향후 인스턴스에 적용됩니다.
+ 가중치 사이의 범위가 크지 않게 하세요. 예를 들어 한 인스턴스 유형에 가중치 1을 지정하고 다음으로 큰 인스턴스 유형에 가중치 200을 지정하는 것은 좋지 않습니다. 가장 작은 가중치와 가장 큰 가중치의 차이가 너무 커서도 안 됩니다. 가중치 차이가 크면 비용 대비 성능 최적화에 부정적인 영향을 미칠 수 있습니다.
+ 인스턴스가 아닌 단위로 그룹의 원하는 용량을 지정합니다. 예를 들어 가중치가 vCPU를 기반으로 하는 경우 원하는 코어 수뿐 아니라 최소 및 최대 코어 수도 지정합니다.
+ 원하는 용량이 가장 큰 가중치보다 최소 2\$13배 더 크도록 가중치와 원하는 용량을 설정합니다.
기존 그룹을 업데이트할 때는 다음 사항에 유의하세요.
+ 기존 그룹에 가중치를 추가할 때 현재 사용 중인 모든 인스턴스 유형에 가중치를 포함합니다.
+ 기존 가중치를 추가하거나 변경하면 Amazon EC2 Auto Scaling이 새 가중치 값을 기준으로 원하는 용량에 도달하기 위해 인스턴스를 시작하거나 종료합니다.
+ 인스턴스 유형을 제거할 경우 해당 유형의 인스턴스를 실행하면 더 이상 정의되지 않더라도 마지막 가중치가 유지됩니다.
## 인스턴스 가중치 동작
인스턴스 가중치를 사용하는 경우 Amazon EC2 Auto Scaling은 다음과 같은 방식으로 작동합니다.
+ 현재 용량이 원하는 용량 이상이 될 수 있습니다. 인스턴스가 시작되어 나머지 원하는 용량 단위를 초과하는 경우 현재 용량이 원하는 용량을 초과할 수 있습니다. 예를 들어, 두 인스턴스 유형 `c5.2xlarge`와 `c5.12xlarge`를 지정하고 `c5.2xlarge`에 인스턴스 가중치 2, `c5.12xlarge`에 인스턴스 가중치 12를 할당한 경우, 원하는 용량을 충족하기까지 5개 유닛이 남은 상태에서 Amazon EC2 Auto Scaling이 `c5.12xlarge`을 프로비저닝하면 원하는 용량이 7개 유닛만큼 초과됩니다.
+ 인스턴스를 시작할 때 Amazon EC2 Auto Scaling은 가용 영역 전체에 용량을 분산하고 원하는 용량을 초과하는 것보다 할당 전략을 준수하는 데 우선순위를 둡니다.
+ Amazon EC2 Auto Scaling은 사용자가 기본 설정한 할당 전략을 사용하여 가용 영역 간의 균형을 유지하기 위해 최대 용량 제한을 초과할 수 있습니다. Amazon EC2 Auto Scaling에서 강제하는 하드 제한은 원하는 용량과 가장 큰 가중치를 합한 값입니다.
# 가중치를 사용하도록 Auto Scaling 그룹 구성
다음 AWS CLI 예와 같이 가중치를 사용하도록 Auto Scaling 그룹을 구성할 수 있습니다. 콘솔을 사용하는 방법은 [인스턴스 유형을 수동으로 선택하여 혼합 인스턴스 그룹 생성](create-mixed-instances-group-manual-instance-type-selection.md) 섹션을 참조하세요.
**가중치를 사용하도록 새 Auto Scaling 그룹을 구성하려면(AWS CLI)**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용합니다. 예를 들어, 다음 명령은 새 Auto Scaling 그룹을 만들고 다음 내용을 지정하여 인스턴스 가중치를 할당합니다.
+ 온디맨드 인스턴스로 시작할 그룹의 백분율(`0`)
+ 각 가용 영역의 스팟 인스턴스에 대한 할당 전략(`capacity-optimized`)
+ 우선순위(`m4.16xlarge`, `m5.24xlarge`)에 따라 시작할 인스턴스 유형
+ 인스턴스 유형(`16`, `24`) 간의 상대적 크기 차이(vCPU)에 해당하는 인스턴스 가중치
+ 각각 다른 가용 영역에 해당하는 인스턴스를 시작하는 서브넷(`subnet-5ea0c127`, `subnet-6194ea3b`, `subnet-c934b782`)
+ 시작 템플릿(`my-launch-template`) 및 시작 템플릿 버전(`$Latest`)
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` 파일에는 다음 내용이 포함되어 있습니다.
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "m4.16xlarge",
"WeightedCapacity": "16"
},
{
"InstanceType": "m5.24xlarge",
"WeightedCapacity": "24"
}
]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "capacity-optimized"
}
},
"MinSize": 160,
"MaxSize": 720,
"DesiredCapacity": 480,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782",
"Tags": []
}
```
**가중치를 사용하도록 기존 Auto Scaling 그룹을 구성하려면(AWS CLI)**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) 명령을 사용합니다. 예를 들어, 다음을 지정하여 아래 명령을 실행하면 기존 Auto Scaling 그룹의 인스턴스 유형에 가중치가 할당됩니다.
+ 우선순위(`c5.18xlarge`, `c5.24xlarge`, `c5.2xlarge`, `c5.4xlarge`)에 따라 시작할 인스턴스 유형
+ 인스턴스 유형(`18`, `24`, `2`, `4`) 간의 상대적 크기 차이(vCPU)에 해당하는 인스턴스 가중치
+ 가장 큰 가중치보다 크게 증가된 새 원하는 용량
```
aws autoscaling update-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` 파일에는 다음 내용이 포함되어 있습니다.
```
{
"AutoScalingGroupName": "my-existing-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"Overrides": [
{
"InstanceType": "c5.18xlarge",
"WeightedCapacity": "18"
},
{
"InstanceType": "c5.24xlarge",
"WeightedCapacity": "24"
},
{
"InstanceType": "c5.2xlarge",
"WeightedCapacity": "2"
},
{
"InstanceType": "c5.4xlarge",
"WeightedCapacity": "4"
}
]
}
},
"MinSize": 0,
"MaxSize": 100,
"DesiredCapacity": 100
}
```
**명령줄을 사용하여 가중치를 확인하려면**
다음 명령 중 하나를 사용합니다.
+ [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html)(AWS CLI)
+ [Get-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ASAutoScalingGroup.html)(AWS Tools for Windows PowerShell)
# 단위 시간당 스팟 가격의 예
다음 표는 미국 동부(버지니아 북부)의 여러 가용 영역에 있는 스팟 인스턴스의 시간당 가격과 동일한 리전의 온디맨드 인스턴스 가격을 비교한 것입니다. 표시된 가격은 현재 가격이 아니라 예를 든 것이며, *인스턴스 시간당* 가격입니다.
**예: 인스턴스 시간당 스팟 가격**
| 인스턴스 유형 | us-east-1a | us-east-1b | us-east-1c | 온디맨드 가격 |
| --- | --- | --- | --- | --- |
| c5.2xlarge | 0.180 USD | 0.191 USD | 0.170 USD | 0.34 USD |
| c5.4xlarge | 0.341 USD | 0.361 USD | 0.318 USD | 0.68 USD |
| c5.12xlarge | 0.779 USD | 0.777 USD | 0.777 USD | 2.04 USD |
| c5.18xlarge | 1.207 USD | 1.475 USD | 1.357 USD | 3.06 USD |
| c5.24xlarge | 1.555 USD | 1.555 USD | 1.555 USD | 4.08 USD |
인스턴스 가중치를 사용하면 *단위 시간당* 사용량을 기준으로 비용을 평가할 수 있습니다. 단위 시간당 가격은 인스턴스 유형에 따른 가격을 인스턴스가 나타내는 유닛 수로 나누어 계산합니다. 온디맨드 인스턴스의 경우, 하나의 인스턴스 유형을 배포하는 경우 동일한 인스턴스 유형의 다른 크기를 배포하더라도 단위 시간당 가격이 동일합니다. 그러나, 단위 시간당 스팟 가격은 스팟 풀에 따라 다릅니다.
다음 예제는 인스턴스 가중치를 기준으로 단위 시간당 스팟 가격을 계산하는 방법을 보여줍니다. 간단한 계산을 위해 `us-east-1a`에서만 스팟 인스턴스를 시작한다고 가정합니다. 단위 시간당 가격은 다음 표에 수집되어 있습니다.
**예시: 단위 시간당 스팟 가격**
| 인스턴스 유형 | us-east-1a | 인스턴스 가중치 | 단위 시간당 가격 |
| --- | --- | --- | --- |
| c5.2xlarge | 0.180 USD | 2 | 0.090 USD |
| c5.4xlarge | 0.341 USD | 4 | 0.085 USD |
| c5.12xlarge | 0.779 USD | 12 | 0.065 USD |
| c5.18xlarge | 1.207 USD | 18 | 0.067 USD |
| c5.24xlarge | 1.555 USD | 24 | 0.065 USD |
# 여러 시작 템플릿 사용
여러 인스턴스 유형을 사용하는 것 외에도 여러 시작 템플릿을 사용할 수 있습니다.
예를 들어, 컴퓨팅 집약적인 애플리케이션을 위한 Auto Scaling 그룹을 구성하고 C5, C5a 및 C6g 인스턴스 유형을 혼합해 포함하려 한다고 가정해 보세요. 그러나 C6g 인스턴스는 64비트 Arm 아키텍처를 기반으로 하는 AWS Graviton 프로세서를 사용하는 반면, C5 및 C5a 인스턴스는 64비트 Intel x86 프로세서에서 실행됩니다. C5 및 C5a 인스턴스용 AMI는 두 인스턴스에서 작동하지만 C6g 인스턴스에서는 작동하지 않습니다. 이 문제를 해결하려면 다른 C6g 인스턴스용 시작 템플릿을 사용합니다. C5 및 C5a 인스턴스에 동일한 시작 템플릿을 계속 사용할 수 있습니다.
이 단원에는 AWS CLI 를 사용하여 여러 시작 템플릿 사용과 관련된 작업을 수행하는 절차가 포함되어 있습니다. 현재 이 기능은 AWS CLI 또는 SDK를 사용하는 경우에만 사용할 수 있으며 콘솔에서는 사용할 수 없습니다.
**Topics**
+ [여러 시작 템플릿을 사용하도록 Auto Scaling 그룹 구성](#configue-auto-scaling-group-to-use-multiple-launch-templates)
+ [관련 리소스](#multiple-launch-templates-related-resources)
## 여러 시작 템플릿을 사용하도록 Auto Scaling 그룹 구성
다음 예와 같이 여러 시작 템플릿을 사용하도록 Auto Scaling 그룹을 구성할 수 있습니다.
**여러 시작 템플릿을 사용하도록 새 Auto Scaling 그룹을 구성하려면(AWS CLI)**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용합니다. 예를 들어, 다음 명령은 새 Auto Scaling 그룹을 생성합니다. 이 파일은 `c5.large`, `c5a.large`, 및 `c6g.large` 인스턴스 유형을 지정하고, `c6g.large` 인스턴스 유형에 대한 새 시작 템플릿을 정의하여 Arm 인스턴스를 시작하는 데 적절한 AMI가 사용되는지 확인합니다. Amazon EC2 Auto Scaling은 인스턴스 유형 순서를 사용하여 온디맨드 용량을 채울 때 우선 사용할 인스턴스 유형을 결정합니다.
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` 파일에는 다음 내용이 포함되어 있습니다.
```
{
"AutoScalingGroupName":"my-asg",
"MixedInstancesPolicy":{
"LaunchTemplate":{
"LaunchTemplateSpecification":{
"LaunchTemplateName":"my-launch-template-for-x86",
"Version":"$Latest"
},
"Overrides":[
{
"InstanceType":"c6g.large",
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template-for-arm",
"Version": "$Latest"
}
},
{
"InstanceType":"c5.large"
},
{
"InstanceType":"c5a.large"
}
]
},
"InstancesDistribution":{
"OnDemandBaseCapacity": 1,
"OnDemandPercentageAboveBaseCapacity": 50,
"SpotAllocationStrategy": "capacity-optimized"
}
},
"MinSize":1,
"MaxSize":5,
"DesiredCapacity":3,
"VPCZoneIdentifier":"subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782",
"Tags":[ ]
}
```
**여러 시작 템플릿을 사용하도록 기존 Auto Scaling 그룹을 구성하려면(AWS CLI)**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) 명령을 사용합니다. 예를 들어, 다음 명령은 이름이 `my-launch-template-for-arm`로 지정된 시작 템플릿을 이름이 *`my-asg`*인 Auto Scaling 그룹의 `c6g.large` 인스턴스 유형에 할당합니다.
```
aws autoscaling update-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` 파일에는 다음 콘텐츠가 포함되어 있습니다.
```
{
"AutoScalingGroupName":"my-asg",
"MixedInstancesPolicy":{
"LaunchTemplate":{
"Overrides":[
{
"InstanceType":"c6g.large",
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template-for-arm",
"Version": "$Latest"
}
},
{
"InstanceType":"c5.large"
},
{
"InstanceType":"c5a.large"
}
]
}
}
}
```
**속성 기반 인스턴스 유형 선택과 함께 여러 시작 템플릿을 사용하도록 새 Auto Scaling 그룹을 구성하려면(AWS CLI)**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용합니다. 예를 들어 다음 명령은 ARM AMI가 있는 AWS Graviton 인스턴스에 대한 시작 템플릿과 x86 AMI가 있는 AMD 또는 Intel 기반 인스턴스에 대한 추가 시작 템플릿을 지정하여 새 Auto Scaling 그룹을 생성합니다. 그런 다음 [속성 기반 인스턴스 선택](create-mixed-instances-group-attribute-based-instance-type-selection.md)을 두 번 사용하여 각 CPU 아키텍처에 대한 다양한 인스턴스 유형 중에서 선택합니다. [update-autoscaling-group](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html) 명령을 사용하여 기존 Auto Scaling 그룹에 유사한 구성을 추가할 수 있습니다.
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
`config.json` 파일에는 다음 콘텐츠가 포함되어 있습니다.
```
{
"AutoScalingGroupName":"my-asg",
"MixedInstancesPolicy":{
"LaunchTemplate":{
"LaunchTemplateSpecification":{
"LaunchTemplateName":"my-launch-template-for-arm",
"Version":"$Latest"
},
"Overrides":[
{
"InstanceRequirements": {
"VCpuCount": {"Min": 2},
"MemoryMiB": {"Min": 2048},
"CpuManufacturers": ["amazon-web-services"]
}
},
{
"InstanceRequirements": {
"VCpuCount": {"Min": 2},
"MemoryMiB": {"Min": 2048},
"CpuManufacturers": ["intel", "amd"]
},
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template-for-x86",
"Version": "$Latest"
}
}
]
},
"InstancesDistribution":{
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "price-capacity-optimized"
}
},
"MinSize":1,
"MaxSize":10,
"DesiredCapacity":6,
"VPCZoneIdentifier":"subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782",
"Tags":[ ]
}
```
**Auto Scaling 그룹의 시작 템플릿 확인**
다음 명령 중 하나를 사용합니다.
+ [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html)(AWS CLI)
+ [Get-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ASAutoScalingGroup.html)(AWS Tools for Windows PowerShell)
## 관련 리소스
[AWS re:Post](https://repost.aws/articles/ARQeKDQX68TcqipYaaisl6bA/cloudformation-auto-scaling-group-sample-template-for-mixed-x86-intel-amd-and-aws-graviton-instances)의 템플릿에서 속성 기반 인스턴스 유형 선택을 사용하여 여러 시작 CloudFormation 템플릿을 지정하는 예를 찾을 수 있습니다.
# 시작 구성을 사용하여 Auto Scaling 그룹 생성
**중요**
제한 사항:
**2023년 1월 1일**부터 새 Amazon EC2 인스턴스 유형은 시작 구성에서 더 이상 지원되지 않습니다. 여기에는 초기 리전 시작 AWS 리전 후에 추가된 모든 인스턴스 유형에 대한 지원이 포함됩니다.
**2023년 6월 1일** 이후에 생성된 계정은 콘솔을 사용하여 새 시작 구성을 생성할 수 없습니다.
**2024년 10월 **1일 이후에 생성된 계정은 어떤 메서드(콘솔, API AWS CLI또는 CloudFormation)를 사용하여 새 시작 구성을 생성할 수 없습니다.
시작 템플릿으로 마이그레이션하여 현재 또는 향후에 새 시작 구성을 생성할 필요가 없게 합니다. Auto Scaling 그룹을 위한 시작 템플릿 생성에 대한 자세한 설명은 [Auto Scaling 그룹을 시작 템플릿으로 마이그레이션](migrate-to-launch-templates.md)을 참조하세요.
시작 구성 또는 EC2 인스턴스를 생성한 경우, 시작 구성을 해당 EC2 인스턴스를 위한 구성 템플릿으로 사용하는 Auto Scaling 그룹을 생성할 수 있습니다. 시작 구성은 귀하의 인스턴스를 위한 AMI ID, 인스턴스 유형, 키 페어, 보안 그룹, 블록 디바이스 매핑 등의 정보를 지정합니다. 시작 구성을 생성하는 자세한 설명은 [시작 구성 생성](create-launch-config.md) 섹션을 참조하십시오.
Auto Scaling 그룹을 만들려면 충분한 권한이 있어야 합니다. 또한 아직 존재하지 않는 경우, 사용자를 대신하여 작업을 수행하기 위해 Amazon EC2 Auto Scaling이 사용하는 서비스 연결 역할을 생성할 수 있는 충분한 권한이 있어야 합니다. 관리자가 귀하에게 권한을 부여하기 위한 준거로 사용할 수 있는 IAM 정책의 예는 [ID 기반 정책 예시](security_iam_id-based-policy-examples.md)을 참조하세요.
**Topics**
+ [시작 구성을 사용하여 Auto Scaling 그룹 생성](create-asg-launch-configuration.md)
+ [를 사용하여 기존 인스턴스에서 Auto Scaling 그룹 생성 AWS CLI](create-asg-from-instance.md)
# 시작 구성을 사용하여 Auto Scaling 그룹 생성
**중요**
시작 구성은 시작 구성에서 시작 템플릿으로 아직 마이그레이션하지 않은 고객을 위해 제공하고 있습니다. Auto Scaling 그룹을 위한 시작 템플릿 생성에 대한 자세한 설명은 [Auto Scaling 그룹을 시작 템플릿으로 마이그레이션](migrate-to-launch-templates.md)을 참조하세요.
Auto Scaling 그룹을 생성할 때 Amazon EC2 인스턴스, 인스턴스의 가용 영역 및 VPC 서브넷, 원하는 용량, 최소 및 최대 용량 제한을 구성하는 데 필요한 정보를 지정해야 합니다.
다음 절차는 시작 구성을 사용하여 Auto Scaling 그룹을 생성하는 방법을 보여줍니다. 시작 구성을 생성한 후에는 수정할 수가 없지만 Auto Scaling 그룹에 대한 시작 구성을 교체할 수 있습니다. 자세한 설명은 [Auto Scaling 그룹에 대한 시작 구성 변경](change-launch-config.md) 섹션을 참조하세요.
**사전 조건**
+ 시작 구성을 생성해야 합니다. 자세한 설명은 [시작 구성 생성](create-launch-config.md) 섹션을 참조하세요.
**시작 구성을 사용하여 Auto Scaling 그룹을 생성하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. 화면 상단의 탐색 모음에서 시작 구성을 생성할 때 사용한 AWS 리전 것과 동일한를 선택합니다.
1. **Auto Scaling 그룹 생성**을 선택합니다.
1. **시작 템플릿 또는 구성 선택** 페이지에서 **Auto Scaling 그룹 명칭**에 Auto Scaling 그룹의 이름을 입력합니다.
1. 시작 구성을 선택하려면 다음을 수행하십시오:
1. **시작 템플릿(Launch template)**에서 **시작 구성으로 전환(Switch to launch configuration)**을 선택합니다.
1. **시작 구성**에 대해 기존 시작 구성을 선택합니다.
1. 시작 구성이 사용하려는 모든 옵션을 지원하는지 확인한 후 **다음**을 선택합니다.
1. **인스턴스 시작 옵션 구성** 페이지의 **네트워크**에서 **VPC**에 대해 VPC를 선택합니다. Auto Scaling 그룹은 시작 구성에서 지정한 보안 그룹과 동일한 VPC에 생성되어야 합니다.
1. **가용 영역 및 서브넷**에서 지정한 VPC에 있는 서브넷 하나 이상을 선택합니다. 여러 가용 영역의 서브넷을 사용하여 가용성을 높일 수 있습니다. 자세한 설명은 [VPC 서브넷 선택 시 고려 사항](asg-in-vpc.md#as-vpc-considerations) 섹션을 참조하세요.
1. **Next(다음)**를 선택합니다.
또는 나머지 기본값을 그대로 두고, **검토로 이동(Skip to review)**을 선택할 수 있습니다.
1. (옵션) **고급 옵션 구성(Configure advanced options)** 페이지에서 다음 옵션을 구성하고 **다음(Next)**을 선택합니다.
1. (옵션) **상태 확인**, **추가 상태 확인 유형**의 경우 **Amazon EBS 상태 확인 활성화**를 선택합니다. 자세한 내용은 [상태 확인을 사용하여 Amazon EBS 볼륨이 손상된 Auto Scaling 인스턴스 모니터링](monitor-and-replace-instances-with-impaired-ebs-volumes.md) 단원을 참조하십시오.
1. (옵션) **상태 확인 유예 기간**에 시간을 초 단위로 입력합니다. 이는 Amazon EC2 Auto Scaling이 인스턴스가 `InService` 상태에 진입한 후 상태를 확인하기 전에 기다려야 하는 시간입니다. 자세한 내용은 [Auto Scaling 그룹의 상태 확인 유예 기간 설정](health-check-grace-period.md) 단원을 참조하십시오.
1. **추가 설정(Additional settings)**, **모니터링(Monitoring)**에서 CloudWatch 그룹 지표 수집 사용 여부를 선택합니다. 이러한 지표는 해지 인스턴스 수 또는 보류 중인 인스턴스 수와 같은 잠재적 문제의 지표가 될 수 있는 측정값을 제공합니다. 자세한 내용은 [Auto Scaling 그룹 및 인스턴스에 대한 CloudWatch 지표 모니터링](ec2-auto-scaling-cloudwatch-monitoring.md) 단원을 참조하십시오.
1. **기본 인스턴스 워밍업 활성화**에서 이 옵션을 선택하고 애플리케이션의 워밍업 시간을 선택합니다. 조정 정책이 있는 Auto Scaling 그룹을 생성하는 경우, 기본 인스턴스 워밍업 기능은 동적 조정에 사용되는 Amazon CloudWatch 지표를 개선합니다. 자세한 설명은 [Auto Scaling 그룹의 기본 인스턴스 워밍업 설정](ec2-auto-scaling-default-instance-warmup.md) 섹션을 참조하세요.
1. (옵션) **그룹 크기 및 조정 정책 구성** 페이지에서 다음 옵션을 구성하고 **다음**을 선택합니다.
1. **그룹 사이즈**에서 **원하는 용량**에 시작시킬 초기 인스턴스 수를 입력합니다.
1. **스케일링** 섹션의 **스케일링 제한**에서 **희망 용량**에 대한 새 값이 **최소 희망 용량** 및 **최대 희망 용량**보다 큰 경우, **최대 희망 용량**은 자동으로 새 희망 용량 값으로 증가합니다. 필요에 따라 이러한 한도를 변경할 수 있습니다. 자세한 설명은 [Auto Scaling 그룹에 대한 스케일링 제한 설정](asg-capacity-limits.md) 섹션을 참조하세요.
1. **자동 조정**의 경우, 대상 추적 조정 정책을 생성할지 여부를 선택합니다. Auto Scaling 그룹을 생성한 후에 이 정책을 생성할 수도 있습니다.
**대상 추적 조정 정책**을 선택하는 경우, [대상 추적 조정 정책 생성](policy_creating.md)의 지침에 따라 정책을 생성하십시오.
1. **인스턴스 유지 관리 정책**에서는 인스턴스 유지 관리 정책을 만들지 여부를 선택합니다. Auto Scaling 그룹을 생성한 후에 이 정책을 생성할 수도 있습니다. [인스턴스 유지 관리 정책 설정](set-instance-maintenance-policy.md)의 지침에 따라 정책을 만듭니다.
1. **인스턴스 스케일 인 보호(Instance scale-in protection)**에서 인스턴스 스케일 인 보호를 활성화할지를 선택합니다. 자세한 설명은 [인스턴스 스케일 인 보호를 사용하여 인스턴스 종료 제어](ec2-auto-scaling-instance-protection.md) 섹션을 참조하세요.
1. (옵션) 알림을 받으려면 **알림 추가(Add notification)**에 알림을 구성하고 **다음(Next)**을 선택합니다. 자세한 설명은 [Amazon EC2 Auto Scaling에 대한 Amazon SNS 알림 옵션](ec2-auto-scaling-sns-notifications.md) 섹션을 참조하세요.
1. (옵션) 태그를 추가하려면 **태그 추가(Add tag)**를 선택하고 각 태그에 태그 키와 값을 제공한 후 **다음(Next)**을 선택합니다. 자세한 설명은 [Auto Scaling 그룹 및 인스턴스에 태그 지정](ec2-auto-scaling-tagging.md) 섹션을 참조하세요.
1. **검토(Review)** 페이지에서 **Auto Scaling 그룹 생성(Create Auto Scaling group)**을 선택합니다.
**명령행을 사용하여 Auto Scaling 그룹을 생성하려면**
다음 명령 중 하나를 사용할 수 있습니다:
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)(AWS CLI)
+ [New-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html)(AWS Tools for Windows PowerShell)
# 를 사용하여 기존 인스턴스에서 Auto Scaling 그룹 생성 AWS CLI
**중요**
시작 구성은 시작 구성에서 시작 템플릿으로 아직 마이그레이션하지 않은 고객을 위해 제공하고 있습니다. Auto Scaling 그룹을 시작 템플릿으로 마이그레이션하는 데 대한 자세한 설명은 [Auto Scaling 그룹을 시작 템플릿으로 마이그레이션](migrate-to-launch-templates.md)을 참조하세요.
Auto Scaling 그룹을 처음 생성하는 경우, 콘솔을 사용하여 기존 EC2 인스턴스에서 시작 템플릿을 생성하는 것이 좋습니다. 그런 다음 시작 템플릿을 사용하여 새 Auto Scaling 그룹을 생성합니다. 이 절차는 [Amazon EC2 시작 마법사를 사용하여 Auto Scaling 그룹 생성](create-asg-ec2-wizard.md) 섹션을 참조하세요.
다음 절차에서는 다른 인스턴스를 시작하기 위한 기반으로 사용할 기존 인스턴스를 지정하여 Auto Scaling 그룹을 생성하는 방법을 보여줍니다. EC2 인스턴스를 생성하려면 Amazon Machine Image(AMI) ID, 인스턴스 유형, 키 페어 및 보안 그룹 등 여러 파라미터가 필요합니다. 이러한 모든 정보는 크기 조정이 필요할 때 사용자를 대신하여 Amazon EC2 Auto Scaling에서 인스턴스를 시작하는 데 사용됩니다. 이 정보는 시작 템플릿 또는 시작 구성에 저장됩니다.
기존 인스턴스를 사용하면 Amazon EC2 Auto Scaling이 동시에 생성된 시작 구성에 근거하여 인스턴스를 시작하는 Auto Scaling 그룹을 생성합니다. 새 시작 구성은 Auto Scaling 그룹과 이름이 동일하며 식별된 인스턴스의 특정 구성 세부 정보를 포함합니다.
다음 구성 세부 정보가 식별된 인스턴스에서 시작 구성으로 복사됩니다.
+ AMI ID
+ 인스턴스 유형
+ 키 페어
+ 보안 그룹
+ IP 주소 유형(퍼블릭 또는 프라이빗)
+ IAM 인스턴스 프로파일(해당하는 경우)
+ 모니터링(true 또는 false)
+ EBS 최적화(true 또는 false)
+ 테넌시 설정(VPC에서 시작하는 경우, 공유 또는 전용)
+ 커널 ID 및 RAM 디스크 ID(해당되는 경우)
+ 사용자 데이터(지정된 경우)
+ 스팟 (최고) 가격
VPC 서브넷 및 가용성 영역이 식별된 인스턴스에서 Auto Scaling 그룹의 자체 리소스 정의로 복사됩니다.
식별된 인스턴스가 배치 그룹에 있는 경우, 새 Auto Scaling 그룹은 식별된 인스턴스와 동일한 배치 그룹으로 인스턴스를 시작합니다. 시작 구성 설정에서는 배치 그룹을 지정할 수 없으므로 배치 그룹이 새 Auto Scaling 그룹의 `PlacementGroup` 속성에 복사됩니다.
다음 구성 세부 정보는 식별된 인스턴트에서 복사되지 않습니다.
+ 스토리지: 블록 디바이스(EBS 볼륨 및 인스턴스 스토어 볼륨)는 식별된 인스턴스에서 복사되지 않습니다. 대신 AMI 생성의 일부로 생성된 블록 디바이스 매핑에 따라 사용되는 디바이스가 결정됩니다.
+ 네트워크 인터페이스 수: 식별된 인스턴스에서 네트워크 인터페이스가 복사되지 않습니다. 대신 Amazon EC2 Auto Scaling은 기본 설정을 사용하여 기본 네트워크 인터페이스(eth0)인 하나의 네트워크 인터페이스를 생성합니다.
+ 인스턴스 메타데이터 옵션: 액세스 가능한 메타데이터, 메타데이터 버전 및 토큰 응답 홉 제한 설정은 식별된 인스턴스에서 복사되지 않습니다. 대신 Amazon EC2 Auto Scaling은 기본 설정을 사용합니다. 자세한 설명은 [인스턴스 메타데이터 옵션 구성](create-launch-config.md#launch-configurations-imds) 섹션을 참조하세요.
+ 로드 밸런서: 식별된 인스턴스가 하나 이상의 로드 밸런서에 등록되어 있으면 로드 밸런서에 대한 정보가 새 Auto Scaling 그룹의 로드 밸런서 또는 대상 그룹 속성에 복사되지 않습니다.
+ 태그: 식별된 인스턴스에 태그가 있는 경우, 해당 태그가 새 Auto Scaling 그룹의 `Tags` 속성에 복사되지 않습니다.
## 사전 조건
EC2 인스턴스는 다음 기준을 충족해야 합니다.
+ 인스턴스가 다른 오토 스케일링의 구성원이 아닙니다.
+ 인스턴스는 `running` 상태에 있습니다.
+ 인스턴스를 시작할 때 사용된 AMI가 항상 있어야 합니다.
## EC2 인스턴스(AWS CLI)에서 Auto Scaling 그룹 생성
다음 절차에서는 CLI 명령을 사용하여 EC2 인스턴스에서 Auto Scaling 그룹을 생성하는 방법을 보여줍니다.
이 절차에서는 인스턴스를 Auto Scaling 그룹에 추가하지 않습니다. 연결할 인스턴스의 경우, Auto Scaling 그룹이 생성된 후 [attach-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/attach-instances.html) 명령을 실행해야 합니다.
시작하기 전에 Amazon EC2 콘솔 또는 [describe-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-instances.html) 명령을 사용하여 EC2 인스턴스의 ID를 확인합니다.
**현재 인스턴스를 템플릿으로 사용하는 방법**
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)명령을 사용하여 EC2 인스턴스 `i-123456789abcdefg0`에서 Auto Scaling 그룹 `my-asg-from-instance`를 생성합니다.
```
aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg-from-instance \
--instance-id i-123456789abcdefg0 --min-size 1 --max-size 2 --desired-capacity 2
```
**Auto Scaling 그룹에서 인스턴스를 시작했는지 확인하려면**
+ [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 명령을 사용하여 Auto Scaling 그룹이 성공적으로 생성되었는지 확인합니다.
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg-from-instance
```
다음 예의 응답은 해당 그룹의 원하는 용량이 2이고 그룹에 실행 중인 인스턴스가 2개이며 시작 구성의 이름이 `my-asg-from-instance`임을 보여 줍니다.
```
{
"AutoScalingGroups":[
{
"AutoScalingGroupName":"my-asg-from-instance",
"AutoScalingGroupARN":"arn",
"LaunchConfigurationName":"my-asg-from-instance",
"MinSize":1,
"MaxSize":2,
"DesiredCapacity":2,
"DefaultCooldown":300,
"AvailabilityZones":[
"us-west-2a"
],
"LoadBalancerNames":[],
"TargetGroupARNs":[],
"HealthCheckType":"EC2",
"HealthCheckGracePeriod":0,
"Instances":[
{
"InstanceId":"i-34567890abcdef012",
"InstanceType":"t2.micro",
"AvailabilityZone":"us-west-2a",
"LifecycleState":"InService",
"HealthStatus":"Healthy",
"LaunchConfigurationName":"my-asg-from-instance",
"ProtectedFromScaleIn":false
},
{
"InstanceId":"i-012345abcdefg6789",
"InstanceType":"t2.micro",
"AvailabilityZone":"us-west-2a",
"LifecycleState":"InService",
"HealthStatus":"Healthy",
"LaunchConfigurationName":"my-asg-from-instance",
"ProtectedFromScaleIn":false
}
],
"CreatedTime":"2020-10-28T02:39:22.152Z",
"SuspendedProcesses":[ ],
"VPCZoneIdentifier":"subnet-0abc1234",
"EnabledMetrics":[ ],
"Tags":[ ],
"TerminationPolicies":[
"Default"
],
"NewInstancesProtectedFromScaleIn":false,
"ServiceLinkedRoleARN":"arn",
"TrafficSources":[]
}
]
}
```
**시작 구성을 보려면**
+ 다음 [describe-launch-configurations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-launch-configurations.html) 명령을 사용하여 시작 구성의 세부 정보를 봅니다.
```
aws autoscaling describe-launch-configurations --launch-configuration-names my-asg-from-instance
```
다음은 예 출력입니다.
```
{
"LaunchConfigurations":[
{
"LaunchConfigurationName":"my-asg-from-instance",
"LaunchConfigurationARN":"arn",
"ImageId":"ami-234567890abcdefgh",
"KeyName":"my-key-pair-uswest2",
"SecurityGroups":[
"sg-12abcdefgh3456789"
],
"ClassicLinkVPCSecurityGroups":[ ],
"UserData":"",
"InstanceType":"t2.micro",
"KernelId":"",
"RamdiskId":"",
"BlockDeviceMappings":[ ],
"InstanceMonitoring":{
"Enabled":true
},
"CreatedTime":"2020-10-28T02:39:22.321Z",
"EbsOptimized":false,
"AssociatePublicIpAddress":true
}
]
}
```
**인스턴스를 해지하려면**
+ 인스턴스가 더 이상 필요하지 않은 경우, 해지할 수 있습니다. [terminate-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/terminate-instances.html) 명령을 사용하여 인스턴스 `i-123456789abcdefg0`를 해지합니다.
```
aws ec2 terminate-instances --instance-ids i-123456789abcdefg0
```
Amazon EC2 인스턴스를 해지한 후에는 인스턴스를 다시 시작할 수 없습니다. 해지하면 데이터가 사라지므로 해당 볼륨을 인스턴스에 연결할 수 없습니다. 인스턴스 종료에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 종료](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console)를 참조하세요.
# 동기식으로 인스턴스 시작
Amazon EC2 Auto Scaling은 Auto Scaling 그룹에서 인스턴스를 시작하는 두 가지 방법, 즉 LaunchInstances API를 사용한 비동기 조정 동작과 동기 프로비저닝을 제공합니다.
동기 프로비저닝을 사용하면 LaunchInstances API를 사용하여 특정 가용 영역에서 특정 수의 인스턴스를 요청할 수 있습니다. 동기 프로비저닝은 다음과 같은 이점을 제공합니다.
+ 특정 가용 영역의 용량 가용성에 대한 즉각적인 피드백
+ 에서 시작되는 가용 영역 인스턴스에 대한 정확한 제어
+ 오케스트레이션 시스템에서 즉시 사용할 수 있는 결정적 인스턴스 IDs
+ 실제 용량 제약 조건에 따른 실시간 조정 결정
+ 비동기 Auto Scaling 시작의 대기 시간을 제거하여 더 빠른 조정
비동기 Auto Scaling을 사용하면 원하는 용량을 변경하거나 조정 정책이 트리거될 때 Amazon EC2 Auto Scaling은 조정 요청을 처리하고 백그라운드에서 인스턴스를 시작합니다. 인스턴스가 성공적으로 시작된 시기를 확인하려면 조정 활동을 모니터링하거나 Auto Scaling 그룹을 설명해야 합니다.
**참고**
LaunchInstances API는 시작 템플릿을 사용하는 Auto Scaling 그룹에서만 작동합니다. 시작 구성을 사용하는 Auto Scaling 그룹은 지원되지 않습니다. Auto Scaling 그룹에서 시작 구성을 사용하는 경우 동기 프로비저닝을 사용하기 전에 시작 템플릿으로 마이그레이션해야 합니다.
LaunchInstances API는 완전 온디맨드 또는 완전 스팟 구매 옵션만 있는 혼합 인스턴스 정책을 지원합니다. 온디맨드 인스턴스와 스팟 인스턴스를 모두 결합한 혼합 정책은 지원되지 않습니다.
여러 가용 영역을 포함하는 Auto Scaling 그룹의 경우 대상 가용 영역 또는 서브넷을 지정해야 합니다. 단일 AZ 그룹의 경우이 파라미터는 선택 사항입니다.
## 동기 프로비저닝 및 비동기 조정
### 동기 프로비저닝
LaunchInstances API를 사용하는 경우 Amazon EC2 Auto Scaling은 다음을 수행합니다.
+ CreateFleet을 사용하여 요청된 인스턴스를 즉시 시작하려고 시도합니다.
+ 응답하기 전에 CreateFleet이 인스턴스 IDs 반환할 때까지 기다립니다.
+ 성공 시 인스턴스 IDs, 인스턴스 유형 및 가용 영역 정보를 반환합니다.
+ 실패에 대한 특정 오류 코드 및 세부 정보를 반환합니다.
+ 즉각적인 피드백을 제공하여 실시간 조정 결정 가능
### 비동기 조정
원하는 용량 변경 또는 조정 정책 사용과 같은 비동기 Auto Scaling 메서드를 사용하는 경우 Amazon EC2 Auto Scaling은 다음을 수행합니다.
+ API에서 원하는 용량을 업데이트하지만 인스턴스를 즉시 반환하지 않음
+ 가용 영역에서 인스턴스 시작을 자동으로 계획합니다.
+ 백그라운드 워크플로를 통해 인스턴스를 시작합니다.
+ 균형을 위해 여러 가용 영역에 용량을 자동으로 분산합니다.
+ 기본 제공 재시도 로직을 사용하여 시작 실패 처리
시작 작업의 상태를 확인하려면 조정 활동을 폴링하거나 Auto Scaling 그룹을 설명해야 합니다.
## 제한 사항 및 고려 사항
동기 프로비저닝 작업 시 다음 참고 사항과 제한 사항에 유의하세요.
+ **시작 후 인스턴스 상태** - API에서 반환된 인스턴스는 보류 상태입니다. 후속 워크플로 프로세스 또는 수명 주기 후크 중에도 여전히 실패할 수 있습니다. API 응답이 성공하면 EC2가 시작 요청을 수락하고 인스턴스 IDs를 반환했음을 의미합니다. 인스턴스는 워크로드에 대해 완전히 준비된 것으로 자동 간주되지 않으므로 표준 EC2 및 Auto Scaling 수명 주기 프로세스를 완료해야 합니다.
+ **웜 풀 제한** - 웜 풀이 있는 Auto Scaling 그룹은 현재 지원되지 않습니다. 웜 풀이 구성된 Auto Scaling 그룹에서 LaunchInstances API를 호출하려고 하면 API는 웜 풀 인스턴스를 사용하는 대신 콜드 스타트를 수행하고 UnsupportedOperation 오류를 반환합니다. 콜드 스타트에 대한 자세한 내용은 [웜 풀의 제한을 참조하세요](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html#warm-pools-limitations).
+ **API 제한 시간 및 재시도 **- 기본 CreateFleet 작업이 예상보다 오래 걸리는 경우 API가 제한 시간을 초과하고 멱등성 토큰을 반환할 수 있습니다. 동일한 ClientToken을 사용하여 원래 시작 작업을 추적하거나 클라이언트 토큰과 함께 describe-instances를 사용하여 시작된 인스턴스를 확인할 수 있습니다.
+ **가용 영역 제약 **- Auto Scaling 그룹이 여러 가용 영역에 걸쳐 있고 가용 영역 리밸런싱이 활성화된 경우 인스턴스를 동기적으로 시작하면 운영 충돌이 발생할 수 있습니다.
+ 호출당 단일 AZ 제한 - Auto Scaling 그룹이 여러 영역에 걸쳐 있더라도 각 LaunchInstances API 호출은 하나의 가용 영역만 대상으로 할 수 있습니다.
+ AZ 리밸런싱 충돌 - Auto Scaling 그룹에 AZ 리밸런싱이 활성화된 경우 서로 다른 AZs에서 순차적으로 호출하면 추가 비동기 시작이 트리거되어 의도한 것보다 많은 인스턴스가 발생할 수 있습니다. 정확한 용량 제어를 위해 AZ 리밸런싱을 일시 중지하는 것이 좋습니다. 자세한 내용은 [Amazon EC2 Auto Scaling 프로세스 일시 중지 및 재개](as-suspend-resume-processes.md) 단원을 참조하십시오.
+ **부분적 성공 시나리오** - 요청된 용량 중 일부만 사용할 수 있는 경우 `LaunchInstances` API가 부분적 성공을 반환할 수 있으며, 이는 정상적인 EC2 동작입니다. API는 실패한 시작에 대한 오류 세부 정보와 함께 성공적으로 시작된 인스턴스를 반환합니다. 모든 인스턴스를 함께 시작해야 하는 사용 사례(예: 짧은 지연 시간으로 인해 동일한 AZ에 있는 모든 인스턴스가 필요한 애플리케이션)의 경우 부분적으로 시작된 인스턴스를 종료하고 다른 AZ에서 다시 시도해야 합니다. 용량에 민감한 워크로드에 대한 재시도 로직을 설계할 때는이 동작을 고려하세요.
+ **인스턴스 가중치** - Auto Scaling 그룹에서 인스턴스 가중치를 사용하는 경우 RequestedCapacity 파라미터는 인스턴스 수가 아닌 가중 용량 단위를 나타냅니다. 시작된 인스턴스의 실제 수는 선택한 인스턴스 유형과 구성된 가중치에 따라 달라집니다. EC2 Auto Scaling은 요청된 가중치 기반 용량에 관계없이 API 호출당 100개의 인스턴스로 시작을 제한합니다.
+ **혼합 인스턴스 유형** - LaunchInstances API는 Auto Scaling 그룹의 기존 혼합 인스턴스 정책을 사용하여 시작할 인스턴스 유형을 결정합니다. API는 그룹의 할당 전략 및 인스턴스 유형 우선 순위에 따라 인스턴스를 시작합니다.
# 동기 프로비저닝을 사용하여 인스턴스 시작
LaunchInstances API를 사용하여 Auto Scaling 그룹에서 특정 수의 인스턴스를 동기식으로 시작할 수 있습니다. API는 지정한 가용 영역 또는 서브넷에서 인스턴스를 시작하고 인스턴스 IDs 또는 오류 정보를 즉시 반환합니다.
## 사전 조건
LaunchInstances API를 사용하려면 먼저 다음이 필요합니다.
+ 시작 템플릿을 사용하는 Auto Scaling 그룹(시작 구성은 지원되지 않음)
+ 다음 IAM 작업에 대한 권한이 있어야 합니다.
+ `autoscaling:LaunchInstances`
+ `ec2:CreateFleet`
+ `ec2:DescribeLaunchTemplateVersions`
## 동기 프로비저닝을 사용하여 인스턴스 시작
를 통해 동기 프로비저닝으로 인스턴스를 시작할 수 있습니다 AWS CLI.
### AWS CLI
동기 프로비저닝을 사용하여 인스턴스를 시작하려면:
```
aws autoscaling launch-instances \
--auto-scaling-group-name group-name \
--requested-capacity number \
[--availability-zones zone-name] \
[--subnet-ids subnet-id] \
[--availability-zone-ids zone-id] \
[--retry-strategy none|retry-with-group-configuration] \
[--client-token token]
```
#### 예제
**특정 가용 영역에서 인스턴스 시작**
```
aws autoscaling launch-instances \
--auto-scaling-group-name my-asg \
--requested-capacity 3 \
--availability-zones us-east-1a \
--retry-strategy retry-with-group-configuration
```
**특정 서브넷에서 인스턴스 시작**
```
aws autoscaling launch-instances \
--auto-scaling-group-name my-asg \
--requested-capacity 2 \
--subnet-ids subnet-12345678 \
--retry-strategy none \
--client-token my-unique-token-123
```
#### 응답 처리
**성공적인 응답의 예:**
```
{
"AutoScalingGroupName": "my-asg",
"ClientToken": "my-unique-token-123",
"Instances": [
{
"InstanceType": "m5.xlarge",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az1",
"SubnetId": "subnet-12345678",
"MarketType": "OnDemand",
"InstanceIds": ["i-0123456789abcdef0", "i-0fedcba9876543210"]
}
],
"Errors": []
}
```
**오류가 있는 응답의 예**
```
{
"AutoScalingGroupName": "my-asg",
"ClientToken": "my-unique-token-123",
"Instances": [],
"Errors": [
{
"InstanceType": "m5.large",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az1",
"SubnetId": "subnet-12345678",
"MarketType": "OnDemand",
"ErrorCode": "InsufficientInstanceCapacity",
"ErrorMessage": "There is not enough capacity to fulfill your request for instance type 'm5.large' in 'us-east-1a'"
}
]
}
```
## 시작 실패 및 재시도 처리
LaunchInstances API에 장애가 발생하면 멱등성 토큰과 적절한 재시도 정책을 사용하여 재시도 전략을 구현할 수 있습니다.
클라이언트 토큰 파라미터를 사용하여 요청을 재시도할 수 있습니다. 다음 재시도 전략을 사용할 수도 있습니다.
+ `RetryStrategy: none` (기본값) - API 호출이 실패하면 Auto Scaling 그룹의 원하는 용량은 변경되지 않고 자동 재시도가 발생하지 않습니다.
+ `RetryStrategy: retry-with-group-configuration` - API 호출이 실패하면 Auto Scaling 그룹의 원하는 용량이 요청된 양만큼 증가하며 Auto Scaling은 그룹의 표준 구성 및 프로세스를 사용하여 인스턴스 시작을 자동으로 재시도합니다.
에 대한 재시도 동작`RetryStrategy: retry-with-group-configuration`은 실패 유형에 따라 다릅니다.
+ **검증 오류**: 작업을 진행할 수 없으므로 원하는 용량이 증가하지 않습니다. 예를 들어 잘못된 파라미터 또는 지원되지 않는 구성입니다.
+ **용량 오류**: 원하는 용량이 증가하고 Auto Scaling은 그룹의 일반 조정 프로세스를 사용하여 인스턴스 시작을 비동기적으로 재시도합니다.
### 멱등성을 위한 클라이언트 토큰 사용
`client-token` 파라미터는 멱등성 작업을 보장하고 시작 요청의 안전한 재시도를 활성화합니다.
주요 동작:
+ 클라이언트 토큰의 수명은 초기 요청부터 8시간입니다.
+ 8시간 이내에 동일한 클라이언트 토큰으로 재시도하면 새 인스턴스를 시작하는 대신 캐시된 응답이 반환됩니다.
+ 8시간 후 동일한 클라이언트 토큰이 새 시작 작업을 시작합니다.
# Auto Scaling 업데이트
Auto Scaling 그룹의 세부 정보 대부분을 업데이트할 수 있습니다. Auto Scaling 그룹의 이름은 업데이트하거나 변경할 수 없습니다 AWS 리전.
**Auto Scaling 그룹 업데이트(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹을 선택하면 **세부 정보**, **활동**, **Auto Scaling**, **인스턴스 관리**, **모니터링** 및 **인스턴스 새로 고침** 탭과 함께 그룹에 대한 정보가 표시됩니다.
1. 관심 있는 구성 영역의 탭을 선택하고 필요에 따라 설정을 업데이트하십시오. 편집하는 각 설정에 대해 **업데이트**를 선택하여 Auto Scaling 그룹의 구성에 변경 사항을 저장합니다.
+ **세부 정보** 탭
다음은 Auto Scaling 그룹에 대한 일반적인 설정입니다. Auto Scaling 그룹을 생성할 때와 동일한 방식으로 편집하고 관리할 수 있습니다.
**고급 구성** 섹션에는 [해지 정책](ec2-auto-scaling-termination-policies.md), [쿨다운](ec2-auto-scaling-scaling-cooldowns.md), [일시 중단된 프로세스](as-suspend-resume-processes.md) 및 [최대 인스턴스 수](asg-max-instance-lifetime.md)명과 같이 그룹을 만들 때 사용할 수 없는 몇 가지 옵션이 있습니다. 또한 Auto Scaling 그룹의 배치 그룹 및 [서비스 연결 역할](autoscaling-service-linked-role.md)은 볼 수 있지만 편집할 수는 없습니다.
+ **통합** 탭
+ **로드 밸런싱** - [Elastic Load Balancing ](autoscaling-load-balancer.md)
그룹이 Elastic Load Balancing 리소스와 연결되어 있는 경우, 가용 영역을 변경하기 전에 [가용 영역 추가가용 영역 제거](as-add-az-console.md)을 참조하세요. 로드 밸런서의 일부 제한 사항으로 인해 그룹의 가용 영역 변경 사항을 로드 밸런서의 가용 영역에 적용하지 못할 수도 있습니다.
+ **VPC Lattice 통합 옵션** - [VPC Lattice](ec2-auto-scaling-vpc-lattice.md)
+ **ARC 영역 전환** - [Auto Scaling 그룹 영역 전환](ec2-auto-scaling-zonal-shift.md)
+ **자동 규모 조정** 탭
+ **동적 조정 정책** - [동적 조정 정책](as-scale-based-on-demand.md)
+ **예측 조정 정책** - [예측 조정 정책](ec2-auto-scaling-predictive-scaling.md)
+ **예약된 작업** - [예약된 작업](ec2-auto-scaling-scheduled-scaling.md)
+ **인스턴스 관리** 탭
+ **수명 주기 후크** - [수명 주기 후크](lifecycle-hooks.md)
+ **웜 풀** - [웜 풀](ec2-auto-scaling-warm-pools.md)
+ **활동** 탭
+ **활동 알림** - [Amazon SNS 알림](ec2-auto-scaling-sns-notifications.md)
+ **모니터링** 탭
+ 이 탭에는 [CloudWatch 그룹 지표 수집](ec2-auto-scaling-metrics.md)을 사용하거나 사용하지 않도록 설정할 수 있는 옵션이 하나만 있습니다.
**명령행을 사용하여 Auto Scaling 그룹을 업데이트하려면**
다음 명령 중 하나를 사용할 수 있습니다:
+ [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html)(AWS CLI)
+ [Update-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Update-ASAutoScalingGroup.html)(AWS Tools for Windows PowerShell)
## Auto Scaling 인스턴스 업데이트
새 시작 템플릿 또는 시작 구성을 Auto Scaling 그룹과 연결하면 모든 새 인스턴스에 업데이트된 구성이 적용됩니다. 기존 인스턴스는 원래 시작된 구성으로 계속 실행됩니다. 기존 인스턴스에 변경 사항을 적용하려면 다음과 같은 옵션이 있습니다.
+ 인스턴스 새로 고침을 시작하여 이전 인스턴스를 교체합니다. 자세한 내용은 [인스턴스 새로 고침을 사용하여 Auto Scaling 그룹의 인스턴스 업데이트](asg-instance-refresh.md) 단원을 참조하십시오.
+ [해지 정책](as-instance-termination.md)에 근거하여 스케일링 활동이 이전 인스턴스를 새 인스턴스로 점진적으로 교체하도록 기다리십시오.
+ Auto Scaling 그룹으로 교체되도록 수동으로 해지합니다.
**참고**
다음 인스턴스 속성을 시작 템플릿 또는 시작 구성의 일부로 지정하여 변경할 수 있습니다.
Amazon Machine Image(AMI)
블록 디바이스
키 페어
인스턴스 유형
보안 그룹
사용자 데이터
모니터링
IAM 인스턴스 프로파일
배치 테넌시
kernel
ramdisk
인스턴스에 공용 IP 주소가 있는지 여부
가용 영역 배포 전략
## Auto Scaling 그룹 할당 전략 및 용량 변경
Auto Scaling 그룹 할당 전략을 변경하면 기존 인스턴스가 교체되지 않습니다. 스케일 아웃 이벤트로 인해 시작된 모든 새 인스턴스는 새 할당 전략을 따릅니다. 향후 스케일 인 이벤트는 [종료 정책](ec2-auto-scaling-termination-policies.md)을 따르며 종료 정책이 `Default` 또는 `AllocationStrategy`로 설정된 경우 새 할당 전략을 사용합니다. 예를 들어 할당 전략을 `lowest-price`에서 `price-capacity-optimized`로 변경하면 인스턴스가 종료되지 않을 수 있지만, 새 인스턴스는 새 할당 전략으로 시작됩니다. 인스턴스 유형 변경 사항은 기존 인스턴스에 영향을 주지 않습니다.
[OnDemandBaseCapacity](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstancesDistribution.html) 또는 [OnDemandPercentageAboveBaseCapacity](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstancesDistribution.html)와 같은 특정 파라미터를 변경하면 온디맨드 인스턴스 및 스팟 인스턴스의 백분율이 새 사양과 일치하지 않는 경우에 Auto Scaling이 자동으로 재조정됩니다. 예를 들어 Auto Scaling 그룹에서 `OnDemandPercentageAboveBaseCapacity`가 50% 온디맨드 인스턴스와 50% 스팟 인스턴스로 설정되어 있다고 가정해 보겠습니다. 그러면 `OnDemandPercentageAboveBaseCapacity`가 100% 온디맨드 인스턴스로 증가합니다. Auto Scaling 그룹은 새 온디맨드 인스턴스를 시작하고 스팟 인스턴스를 종료하여 사전에 재조정합니다. 사용자가 정의한 [인스턴스 유지 관리 정책](instance-maintenance-policy-overview-and-considerations.md)에 따라 시작 및 종료 활동의 순서가 결정됩니다.
# Auto Scaling 그룹 및 인스턴스에 태그 지정
*태그*는 사용자가 할당하거나가 AWS 리소스에 AWS 할당하는 사용자 지정 속성 레이블입니다. 각 태그는 두 부분으로 구성됩니다.
+ 태그 키(예: `costcenter`, `environment` 또는 `project`)
+ 태그 값(예: `111122223333` 또는 `production`)으로 알려진 선택적 필드
태그는 다음을 지원합니다.
+ AWS 비용을 추적합니다. AWS 결제 및 비용 관리 대시보드에서 이러한 태그를 활성화합니다. AWS 는 태그를 사용하여 비용을 분류하고 월별 비용 할당 보고서를 제공합니다. 자세한 설명은 *AWS Billing 사용자 가이드*에서 [비용 할당 태그 사용](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)을 참조하세요.
+ 태그에 근거하여 Auto Scaling 그룹에 대한 액세스를 제어합니다. IAM 정책의 조건을 사용하여 해당 그룹의 태그에 근거하여 Auto Scaling 그룹에 대한 액세스를 제어할 수 있습니다. 자세한 설명은 [보안을 위한 태그](tag-security.md) 섹션을 참조하세요.
+ 추가하는 태그를 기준으로 Auto Scaling 그룹을 필터링하고 검색합니다. 자세한 내용은 [태그를 사용하여 Auto Scaling 그룹 필터링](use-tag-filters-aws-cli.md) 단원을 참조하십시오.
+ AWS 리소스를 식별하고 구성합니다. 많은가 태그 지정을 AWS 서비스 지원하므로 서로 다른 서비스의 리소스에 동일한 태그를 할당하여 리소스가 관련이 있음을 나타낼 수 있습니다.
신규 또는 기존 Auto Scaling 그룹에 태그를 지정할 수 있습니다. 또한 Auto Scaling 그룹의 태그를 해당 그룹이 시작한 EC2 인스턴스에 전파할 수 있습니다.
태그는 Amazon EBS 볼륨에는 전파되지 않습니다. Amazon EBS 볼륨에 태그를 추가하려면 시작 템플릿에서 태그를 지정합니다. 자세한 내용은 [Auto Scaling 그룹에 대한 시작 템플릿 생성](create-launch-template.md) 단원을 참조하십시오.
AWS Management Console AWS CLI또는 SDKs.
**Topics**
+ [태그 이름 지정 및 사용 제한](#tag_restrictions)
+ [EC2 인스턴스 태크 지정 수명 주기](#tag-lifecycle)
+ [Auto Scaling 그룹에 태그 지정](add-tags.md)
+ [태그 삭제](delete-tag.md)
+ [보안을 위한 태그](tag-security.md)
+ [태그에 대한 액세스 통제](tag-permissions.md)
+ [태그를 사용하여 Auto Scaling 그룹 필터링](use-tag-filters-aws-cli.md)
## 태그 이름 지정 및 사용 제한
태그에 적용되는 기본 제한 사항은 다음과 같습니다.
+ 리소스당 최대 태그 수는 50개입니다.
+ 단일 호출을 사용하여 추가하거나 제거할 수 있는 최대 태그 수는 25입니다.
+ 최대 키 길이는 유니코드 문자 128자입니다.
+ 최대 값 길이는 유니코드 문자 256자입니다.
+ 태그 키와 값은 대/소문자를 구분합니다. 태그를 대문자로 사용하는 전략을 세우고 이러한 전략을 모든 리소스 유형에 대해 일관되게 구현하는 것이 가장 좋습니다.
+ 태그 이름 또는 값에 `aws:` 접두사는 AWS 사용하도록 예약되어 있으므로 사용하지 마십시오. 이 접두사를 가진 태그 이름이나 값은 편집 또는 삭제할 수 없으며 리소스 할당량당 태그로도 계수되지 않습니다.
## EC2 인스턴스 태크 지정 수명 주기
EC2 인스턴스에 태그를 전파하기로 선택하면 태그가 다음과 같이 관리됩니다.
+ Auto Scaling 그룹에서 인스턴스를 시작하면 리소스를 생성한 후가 아니라 리소스를 생성하는 동안 인스턴스에 태그를 추가합니다.
+ Auto Scaling 그룹은 `aws:autoscaling:groupName` 키와 Auto Scaling 그룹 명칭 값을 사용하여 인스턴스에 태그를 자동으로 추가합니다.
+ 시작 템플릿에 인스턴스 태그를 지정하고 그룹의 태그를 해당 인스턴스로 전파하도록 선택한 경우, 모든 태그가 병합됩니다. 시작 템플릿의 태그와 Auto Scaling 그룹의 태그에 대해 동일한 태그 키가 지정된 경우, 그룹의 태그 값이 우선합니다.
+ 기존 인스턴스를 연결하면 Auto Scaling 그룹이 인스턴스에 태그를 추가하여 동일한 태그 키를 가진 기존 태그를 덮어씁니다. 또한 `aws:autoscaling:groupName` 키와 Auto Scaling 그룹 명칭 값을 사용하여 태그를 추가합니다.
+ Auto Scaling 그룹에서 인스턴스를 분리하면 `aws:autoscaling:groupName` 태그만 제거됩니다.
# Auto Scaling 그룹에 태그 지정
Auto Scaling 그룹에 태그를 추가할 때 Auto Scaling 그룹에서 시작되는 인스턴스에 추가할지를 지정할 수 있습니다. 태그를 수정하면 변경 후 태그의 업데이트 버전이 Auto Scaling 그룹에서 시작되는 인스턴스에 추가됩니다. Auto Scaling 그룹의 태그를 생성하거나 수정하는 경우, 이러한 변경 사항은 Auto Scaling 그룹에서 이미 실행 중인 인스턴스에는 적용되지 않습니다.
**Topics**
+ [태그 추가 또는 수정(콘솔)](#add-tags-console)
+ [태그 추가 또는 수정(AWS CLI)](#add-tags-aws-cli)
## 태그 추가 또는 수정(콘솔)
**생성 시 Auto Scaling 그룹에 태그를 지정하려면**
Amazon EC2 콘솔을 사용하여 Auto Scaling 그룹을 생성할 때 Auto Scaling 그룹 생성 마법사의 **태그 추가** 페이지에서 태그 키와 값을 지정할 수 있습니다. Auto Scaling 그룹에서 시작된 인스턴스에 태그를 전파하려면 선택된 태그에 대한 **새 인스턴스에 태그 지정(Tag new instances)** 옵션을 유지해야 합니다. 그렇지 않은 경우, 선택을 취소할 수 있습니다.
**기존 Auto Scaling 그룹의 태그를 추가하거나 수정하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
**Auto Scaling 그룹(Auto Scaling groups)** 페이지 하단에 분할 창이 열립니다.
1. **세부 정보** 탭에서 **태그**, **편집**을 선택합니다.
1. 기존의 태그를 수정하려면 **Key** 및 **Value**를 수정합니다.
1. 새 태그를 추가하려면 **Add tag**를 선택하고 **Key** 및 **Value**를 편집합니다. Auto Scaling 그룹에서 시작된 인스턴스에 태그를 자동으로 추가하려면 **새 인스턴스에 태그 지정(Tag new instances)**을 선택한 채로 두고 그러지 않으려는 경우, 이 옵션을 선택 취소할 수 있습니다.
1. 태그 추가를 마쳤으면 **저장**을 선택합니다.
## 태그 추가 또는 수정(AWS CLI)
다음 예제에서는를 사용하여 Auto Scaling 그룹을 생성할 때 태그를 AWS CLI 추가하고 기존 Auto Scaling 그룹에 대한 태그를 추가하거나 수정하는 방법을 보여줍니다.
**생성 시 Auto Scaling 그룹에 태그를 지정하려면**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용하여 새 Auto Scaling 그룹을 생성하고 해당 Auto Scaling 그룹에 태그(예:**environment=production**)를 추가합니다. 태그는 Auto Scaling 그룹에서 시작되는 모든 인스턴스에도 추가됩니다.
```
aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg \
--launch-configuration-name my-launch-config --min-size 1 --max-size 3 \
--vpc-zone-identifier "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782" \
--tags Key=environment,Value=production,PropagateAtLaunch=true
```
**기존 Auto Scaling 그룹의 태그를 생성하거나 수정하려면**
[create-or-update-tags](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-or-update-tags.html) 명령을 사용하여 태그를 생성하거나 수정합니다. 예컨대, 다음 명령은 `Name=my-asg` 및 `costcenter=cc123` 태그를 추가합니다. 태그는 이 변경 후에 Auto Scaling 그룹에서 시작되는 모든 인스턴스에도 추가됩니다. 이 키를 가진 태그가 이미 있으면 기존 태그가 교체됩니다. Amazon EC2 콘솔은 각 인스턴스의 표시 이름을 `Name` 키에 지정된 이름(대소문자 구분)과 연결합니다.
```
aws autoscaling create-or-update-tags \
--tags ResourceId=my-asg,ResourceType=auto-scaling-group,Key=Name,Value=my-asg,PropagateAtLaunch=true \
ResourceId=my-asg,ResourceType=auto-scaling-group,Key=costcenter,Value=cc123,PropagateAtLaunch=true
```
### Auto Scaling 그룹의 태그 설명(AWS CLI)
특정 Auto Scaling 그룹에 적용된 태그를 보려는 경우, 다음 명령 중 하나를 사용할 수 있습니다:
+ [describe-tags](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-tags.html) - Auto Scaling 그룹 명칭을 제공하면 지정된 그룹의 태그 목록을 보여줍니다.
```
aws autoscaling describe-tags --filters Name=auto-scaling-group,Values=my-asg
```
다음은 응답의 예입니다.
```
{
"Tags": [
{
"ResourceType": "auto-scaling-group",
"ResourceId": "my-asg",
"PropagateAtLaunch": true,
"Value": "production",
"Key": "environment"
}
]
}
```
+ [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) - Auto Scaling 그룹 명칭을 제공하면 태그를 포함하여 지정된 그룹의 속성을 보여줍니다.
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg
```
다음은 응답의 예입니다.
```
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "my-asg",
"AutoScalingGroupARN": "arn",
"LaunchTemplate": {
"LaunchTemplateId": "lt-0b97f1e282EXAMPLE",
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 1,
...
"Tags": [
{
"ResourceType": "auto-scaling-group",
"ResourceId": "my-asg",
"PropagateAtLaunch": true,
"Value": "production",
"Key": "environment"
}
],
...
}
]
}
```
# 태그 삭제
Auto Scaling 그룹과 연결된 태그는 언제든지 삭제할 수 있습니다.
**Topics**
+ [태그 삭제(콘솔)](#delete-tag-console)
+ [태그 삭제(AWS CLI)](#delete-tag-aws-cli)
## 태그 삭제(콘솔)
**태그를 삭제하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. 기존 그룹 옆의 확인란을 선택합니다.
**Auto Scaling 그룹(Auto Scaling groups)** 페이지 하단에 분할 창이 열립니다.
1. **세부 정보** 탭에서 **태그**, **편집**을 선택합니다.
1. 태그 옆에 있는 **제거**를 선택합니다.
1. **업데이트**를 선택합니다.
## 태그 삭제(AWS CLI)
[delete-tags](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-tags.html) 명령을 사용하여 태그를 삭제합니다. 예컨대, 다음 명령은 키가 `environment`인 태그를 삭제합니다.
```
aws autoscaling delete-tags --tags "ResourceId=my-asg,ResourceType=auto-scaling-group,Key=environment"
```
태그 키는 지정해야 하지만 값은 지정하지 않아도 됩니다. 값을 지정했는데 해당 값이 잘못된 경우, 태그가 삭제되지 않습니다.
# 보안을 위한 태그
태그를 사용하여 요청자(예: IAM 사용자 또는 역할)에게 특정 Auto Scaling 그룹을 생성, 수정 또는 삭제할 수 있는 권한이 있는지 확인합니다. 다음 조건 키를 하나 이상 사용하여 IAM 정책의 조건 요소에 태그 정보를 제공합니다.
+ 특정 태그가 있는 Auto Scaling 그룹에 대한 사용자 작업을 허용(또는 거부)하려면 `autoscaling:ResourceTag/tag-key: tag-value`를 사용합니다.
+ 요청에 특정 태그가 존재하도록 (또는 존재하지 않도록) 요구하려면 `aws:RequestTag/tag-key: tag-value`를 사용합니다.
+ 요청에 특정 태그 키가 존재하도록 (또는 존재하지 않도록) 요구하려면 `aws:TagKeys [tag-key, ...]`를 사용합니다.
예컨대, 다음 예에 표시된 것처럼 키가 `environment`이고 값이 `production`인 태그가 포함된 모든 Auto Scaling 그룹에 대한 액세스를 거부할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"autoscaling:CreateAutoScalingGroup",
"autoscaling:UpdateAutoScalingGroup",
"autoscaling:DeleteAutoScalingGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {"autoscaling:ResourceTag/environment": "production"}
}
}
]
}
```
------
조건 키를 사용하여 Auto Scaling 그룹에 대한 액세스를 제어하는 방법에 대한 자세한 설명은 [Amazon EC2 Auto Scaling에서 IAM을 사용하는 방식](control-access-using-iam.md)을 참조하세요.
# 태그에 대한 액세스 통제
태그를 사용하여 요청자(예: IAM 사용자 또는 역할)에게 Auto Scaling 그룹에 대한 태그를 추가, 수정 또는 삭제할 수 있는 권한이 있는지 확인합니다.
다음 예 IAM 정책은 `temporary` 키가 있는 태그만 Auto Scaling 그룹에서 제거할 수 있는 권한을 주체에 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "autoscaling:DeleteTags",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": { "aws:TagKeys": ["temporary"] }
}
}
]
}
```
------
Auto Scaling 그룹에 지정된 태그에 제약 조건을 적용하는 IAM 정책의 자세한 예는 [사용할 수 있는 태그 키 및 태그 값 제어](security_iam_id-based-policy-examples.md#policy-example-tags)을 참조하세요.
**참고**
사용자가 Auto Scaling 그룹에서 태그 지정 또는 태그 해제 작업을 수행하지 못하도록 제한하는 정책을 설정해도 인스턴스를 시작한 후에 수동으로 인스턴스의 태그를 변경하는 것을 막을 수 없습니다. EC2 인스턴스의 태그에 대한 액세스를 제어하는 예는 *Amazon EC2 사용 설명서*의 [예: 리소스에 태그 지정](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-taggingresources)을 참조하세요.
# 태그를 사용하여 Auto Scaling 그룹 필터링
다음 예에서는 [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 명령과 함께 필터를 사용하여 특정 태그로 Auto Scaling 그룹을 설명하는 방법을 보여줍니다. 태그별 필터링은 AWS CLI 또는 SDK로 제한되며 콘솔에서는 사용할 수 없습니다.
**필터링 고려 사항**
+ 단일 요청에서 여러 필터와 여러 필터 값을 지정할 수 있습니다.
+ 또한 필터 값과 함께 와일드카드를 사용할 수 없습니다.
+ 필터 값은 대/소문자를 구분합니다.
**예: 특정 태그 키 및 값 페어로 Auto Scaling 그룹 설명**
다음 명령은 **`environment=production`**의 태그 키 및 값 페어가 있는 Auto Scaling 그룹만 표시하도록 결과를 필터링하는 방법을 보여줍니다.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment Name=tag-value,Values=production
```
다음은 응답의 예입니다.
```
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "my-asg",
"AutoScalingGroupARN": "arn",
"LaunchTemplate": {
"LaunchTemplateId": "lt-0b97f1e282EXAMPLE",
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 1,
...
"Tags": [
{
"ResourceType": "auto-scaling-group",
"ResourceId": "my-asg",
"PropagateAtLaunch": true,
"Value": "production",
"Key": "environment"
}
],
...
},
... additional groups ...
]
}
```
또는 `tag:` 필터를 사용하여 태그를 지정할 수 있습니다. 예컨대, 다음 명령은 **`environment=production`**의 태그 키 및 값 페어가 있는 Auto Scaling 그룹만 표시하도록 결과를 필터링하는 방법을 보여줍니다. 이 필터의 형식은 `Name=tag:,Values=`이며 **** 및 ****는 태그 키 및 값 페어를 나타냅니다.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag:environment,Values=production
```
`--query` 옵션을 사용하여 AWS CLI 출력을 필터링할 수도 있습니다. 다음 예제에서는 이전 명령의 AWS CLI 출력을 그룹 이름, 최소 크기, 최대 크기 및 원하는 용량 속성으로만 제한하는 방법을 보여줍니다.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag:environment,Values=production \
--query "AutoScalingGroups[].{AutoScalingGroupName: AutoScalingGroupName, MinSize: MinSize, MaxSize: MaxSize, DesiredCapacity: DesiredCapacity}"
```
다음은 응답의 예입니다.
```
[
{
"AutoScalingGroupName": "my-asg",
"MinSize": 0,
"MaxSize": 10,
"DesiredCapacity": 1
},
... additional groups ...
]
```
필터링에 대한 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [AWS CLI 출력 필터링](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-filter.html)을 참조하세요.
**예: 지정된 태그 키와 일치하는 태그가 있는 Auto Scaling 그룹 설명**
다음 명령은 태그 값에 관계없이 `environment` 태그가 있는 Auto Scaling 그룹만 표시하도록 결과를 필터링하는 방법을 보여줍니다.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment
```
**예: 지정된 태그 키 집합과 일치하는 태그가 있는 Auto Scaling 그룹 설명**
다음 명령은 태그 값에 관계없이 `environment` 및 `project`에 대한 태그가 있는 Auto Scaling 그룹만 표시하도록 결과를 필터링하는 방법을 보여줍니다.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment Name=tag-key,Values=project
```
**예: 지정된 태그 키 중 하나 이상과 일치하는 태그가 있는 Auto Scaling 그룹 설명**
다음 명령은 태그 값에 관계없이 `environment` 또는 `project`에 대한 태그가 있는 Auto Scaling 그룹만 표시하도록 결과를 필터링하는 방법을 보여줍니다.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment,project
```
**예: 지정된 태그 값이 있는 Auto Scaling 그룹 설명**
다음 명령은 태그 키에 관계없이 `production`의 태그 값이 있는 Auto Scaling 그룹만 표시하도록 결과를 필터링하는 방법을 보여줍니다.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-value,Values=production
```
**예: 지정된 태그 값 집합이 있는 Auto Scaling 그룹 설명**
다음 명령은 태그 키에 관계없이 태그 값 `production` 및 `development`가 있는 Auto Scaling 그룹만 표시하도록 결과를 필터링하는 방법을 보여줍니다.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-value,Values=production Name=tag-value,Values=development
```
**예: 지정된 태그 값 중 하나 이상과 일치하는 태그가 있는 Auto Scaling 그룹 설명**
다음 명령은 태그 키에 관계없이 `production` 또는 `development`의 태그 값이 있는 Auto Scaling 그룹만 표시하도록 결과를 필터링하는 방법을 보여줍니다.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-value,Values=production,development
```
**예: 여러 태그 키 및 값과 일치하는 태그가 있는 Auto Scaling 그룹 설명**
또한 필터를 결합하여 사용자 정의 AND 및 OR 로직을 생성하여 보다 복잡한 필터링을 수행할 수 있습니다.
다음 명령은 특정 태그 집합이 있는 Auto Scaling 그룹만 표시하도록 결과를 필터링하는 방법을 보여줍니다. 하나의 태그 키는 `environment`이고(AND) 태그 값은 (`production` OR `development`)이고(AND) 다른 태그 키는 `costcenter`이고(AND) 태그 값은 `cc123`입니다.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag:environment,Values=production,development Name=tag:costcenter,Values=cc123
```
# 인스턴스 유지 관리 정책
인스턴스 새로 고침 또는 상태 확인 프로세스와 같이 인스턴스 교체를 유발하는 이벤트 발생 중에 특정 용량 요구 사항을 충족하도록 Auto Scaling 그룹에 대한 인스턴스 유지 관리 정책을 구성할 수 있습니다.
예를 들어, 적은 수의 인스턴스가 있는 Auto Scaling 그룹이 있다고 가정합니다. 상태 점검 결과 손상된 인스턴스가 발견될 경우 인스턴스가 종료되고 교체되어 발생할 수 있는 중단을 방지하는 것이 좋습니다. 인스턴스 유지 관리 정책을 사용하면 Amazon EC2 Auto Scaling에서 먼저 새 인스턴스를 시작한 다음 완전히 준비될 때까지 기다렸다가 비정상 인스턴스를 종료하도록 할 수 있습니다.
또한 인스턴스 유지 관리 정책은 여러 인스턴스가 동시에 교체되는 경우 발생할 수 있는 중단을 최소화하는 데도 도움이 됩니다. 정책의 최소 및 최대 정상 백분율 파라미터를 설정하면 Auto Scaling 그룹에서 인스턴스를 교체할 때 해당 최소-최대 범위 내에서만 용량을 늘리거나 줄일 수 있습니다. 범위가 클수록 동시에 교체될 수 있는 인스턴스 수가 늘어납니다.
**Topics**
+ [Auto Scaling 그룹의 인스턴스 유지 관리 정책](instance-maintenance-policy-overview-and-considerations.md)
+ [Auto Scaling 그룹에서 인스턴스 유지 관리 정책 설정](set-instance-maintenance-policy-on-group.md)
# Auto Scaling 그룹의 인스턴스 유지 관리 정책
이 항목에서는 사용 가능한 옵션에 대한 개요와 인스턴스 유지 관리 정책을 생성할 때 고려해야 할 사항을 설명합니다.
**Topics**
+ [개요](#instance-maintenance-policy-overview)
+ [핵심 개념](#instance-maintenance-policy-core-concepts)
+ [인스턴스 워밍업](#instance-maintenance-policy-instance-warm-up)
+ [건전성 체크 유예 기간](#instance-maintenance-policy-health-check-grace-period)
+ [Auto Scaling 그룹 조정](#instance-maintenance-policy-scaling-limits)
+ [예제 시나리오](#instance-maintenance-policy-scenarios)
## 개요
Auto Scaling 그룹에 대한 인스턴스 유지 관리 정책을 생성하면 정책이 인스턴스가 교체되는 Amazon EC2 Auto Scaling 이벤트에 영향을 줍니다. 그 결과 동일한 Auto Scaling 그룹 내에서 보다 일관된 교체 동작이 가능합니다. 또한 필요에 따라 그룹의 가용성 또는 비용을 최적화할 수 있습니다.
콘솔에서는 다음과 같은 구성 옵션을 사용할 수 있습니다.
+ **종료 전 시작** - 기존 인스턴스를 종료하기 전에 새 인스턴스를 프로비저닝해야 합니다. 이 접근 방식은 비용 절감보다 가용성을 선호하는 애플리케이션에 적합합니다.
+ **종료 및 시작** - 기존 인스턴스가 종료되는 동시에 새 인스턴스가 프로비저닝됩니다. 이 접근 방식은 가용성보다 비용 절감을 선호하는 애플리케이션에 적합합니다. 또한 인스턴스를 교체하더라도 현재 사용 가능한 용량보다 많은 용량을 실행하지 않아야 하는 애플리케이션에도 적합합니다.
+ **사용자 지정 정책** - 이 옵션을 사용하면 인스턴스 교체 시 사용할 수 있는 용량에 대한 사용자 지정 최소 및 최대 범위로 정책을 설정할 수 있습니다. 이 접근 방식은 비용과 가용성의 균형을 적절하게 조정하는 데 도움이 될 수 있습니다.
Auto Scaling 그룹의 기본값은 인스턴스 유지 관리 정책을 사용하지 않는 것인데, 이렇게 하면 기본 동작으로 인스턴스 유지 관리 이벤트에 응답합니다. 기본 동작은 다음 표에 설명되어 있습니다.
**인스턴스 유지 관리 이벤트 기본 동작**
| 이벤트 | 설명 | 기본 동작 |
| --- | --- | --- |
| 상태 확인 실패 | 인스턴스가 상태 확인에 실패할 때 자동으로 발생합니다. Amazon EC2 Auto Scaling은 상태 확인에 실패한 인스턴스를 교체합니다. 상태 확인 실패의 원인을 이해하려면 [Auto Scaling 그룹의 인스턴스에 대한 상태 확인](ec2-auto-scaling-health-checks.md)(을)를 참조하세요. | 종료 및 시작 |
| 인스턴스 새로 고침 | 인스턴스 새로 고침을 시작할 때 발생합니다. 구성에 따라 인스턴스 새로 고침은 인스턴스를 한 번에 하나씩, 한 번에 여러 개 또는 한 번에 모두 교체할 수 있습니다. 자세한 내용은 [인스턴스 새로 고침을 사용하여 Auto Scaling 그룹의 인스턴스 업데이트](asg-instance-refresh.md)(을)를 참조하세요. | 종료 및 시작 |
| 최대 인스턴스 수명 | 인스턴스가 Auto Scaling 그룹에 지정한 최대 인스턴스 수명에 도달할 때 자동으로 발생합니다. Amazon EC2 Auto Scaling은 최대 인스턴스 수명에 도달한 인스턴스를 교체합니다. 자세한 내용은 [최대 인스턴스 수명을 기준으로 Auto Scaling 인스턴스 교체](asg-max-instance-lifetime.md)(을)를 참조하세요. | 종료 및 시작 |
| 재분배 | 그룹의 불균형을 초래하는 근본적인 변화가 있는 경우 자동으로 발생합니다. Amazon EC2 Auto Scaling은 다음과 같은 상황에서 그룹의 균형을 재조정합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/instance-maintenance-policy-overview-and-considerations.html) | 종료 전 시작 Amazon EC2 Auto Scaling은 그룹의 크기 제한을 *최대 용량*의 10%까지 초과할 수 있습니다. 하지만, 용량 재분배를 사용하는 경우 *원하는 용량*의 최대 10%까지만 이러한 제한을 초과할 수 있습니다. |
Amazon EC2 Auto Scaling은 다음과 같은 상황에서 계속해서 기본적으로 종료되고 시작됩니다. 따라서, 이러한 상황 중 하나가 발생하면 그룹 용량이 인스턴스 유지 관리 정책의 하한 임계값보다 적을 수 있습니다.
+ 예를 들어, 사람의 행동으로 인해 인스턴스가 예기치 않게 종료되는 경우는 다음과 같습니다. Amazon EC2 Auto Scaling에서 더 이상 실행되지 않는 인스턴스를 즉시 교체합니다. 자세한 내용은 [Amazon EC2 상태 확인](health-checks-overview.md#instance-health-detection)(을)를 참조하세요.
+ Amazon EC2 Auto Scaling에서 대체 인스턴스를 시작하기 전에 예정된 이벤트의 일환으로 Amazon EC2가 인스턴스를 재부팅, 중지 또는 폐기하는 경우. 이러한 이벤트에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [예약된 인스턴스 이벤트](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html)를 참조하세요.
+ Amazon EC2 스팟 서비스가 스팟 인스턴스 중단을 시작하고 스팟 인스턴스가 강제로 종료되는 경우는 다음과 같습니다.
스팟 인스턴스와 관련하여 Auto Scaling 그룹에서 용량 재분배를 활성화한 경우 스팟 중단을 시작하기 전에 시작한 다른 스팟 풀의 보류 중인 인스턴스가 인스턴스에 이미 있을 수 있습니다. 용량 재분배 방법에 대한 자세한 내용은 [위험 상태의 스팟 인스턴스를 대체하기 위한 Auto Scaling의 용량 재조정](ec2-auto-scaling-capacity-rebalancing.md)(을)를 참조하세요.
그러나, 스팟 인스턴스는 사용 가능한 상태로 유지될 수 없으며 2분 스팟 인스턴스 중단 알림과 함께 종료될 수 있으므로 새 인스턴스가 시작되기 전에 인스턴스가 중단되면 인스턴스 유지 관리 정책의 하한 임계값이 초과될 수 있습니다.
## 핵심 개념
시작하기 전에 다음과 같은 핵심 개념 및 용어를 익힙니다.
**원하는 용량**
*원하는 용량*은 생성 시 Auto Scaling 그룹의 용량입니다. 또한 그룹에 연결된 조정 조건이 없을 때 그룹이 유지하려고 시도하는 용량이기도 합니다.
**인스턴스 유지 관리 정책**
*인스턴스 유지 관리 정책*은 기존 인스턴스가 종료되기 전에 인스턴스 유지 관리 이벤트를 위해 인스턴스를 먼저 프로비저닝할지 여부를 제어합니다. 또한 Auto Scaling 그룹이 동시에 여러 인스턴스를 교체할 때 원하는 용량보다 낮거나 초과할 수 있는 범위도 결정합니다.
**최대 정상 백분율**
*최대 정상 백분율*은 Auto Scaling 그룹이 인스턴스를 교체할 때 늘릴 수 있는 원하는 용량의 백분율입니다. 이는 워크로드를 지원하기 위해 서비스 중이고 정상 상태이거나 보류 중일 수 있는 그룹의 최대 비율을 나타냅니다. 콘솔에서는 **종료 전 시작** 옵션 또는 **사용자 지정 정책** 옵션을 사용할 때 최대 정상 비율을 설정할 수 있습니다. 유효한 값은 100\$1200%입니다.
**최소 건전 백분율**
*최소 정상 백분율*은 인스턴스를 교체할 때 서비스 상태를 유지하고 워크로드 지원에 사용할 준비가 된 상태로 유지하기 위해 필요한 용량의 비율입니다. 첫 번째 상태 확인을 성공적으로 완료하고 지정된 준비 시간이 경과하면 인스턴스가 정상이며 사용할 준비가 된 것으로 간주됩니다. 콘솔에서는 **종료 및 시작** 옵션 또는 **사용자 지정 정책** 옵션을 사용할 때 최소 정상 비율을 설정할 수 있습니다. 유효한 값은 0\$1100%입니다.
인스턴스를 더 빨리 교체하려면 최소 정상 비율을 낮게 지정할 수 있습니다. 하지만, 실행 중인 정상 인스턴스가 충분하지 않으면 가용성이 저하될 수 있습니다. 여러 인스턴스가 교체되는 상황에서 가용성을 유지하기 위해 적절한 값을 선택하는 것이 좋습니다.
## 인스턴스 워밍업
`InService` 상태가 된 후 인스턴스를 초기화하는 데 시간이 필요한 경우 Auto Scaling 그룹의 기본 인스턴스 워밍업을 활성화합니다. 기본 인스턴스 워밍업을 사용하면 인스턴스가 준비되기 전에 최소 정상 백분율에 포함되는 것을 방지할 수 있습니다. 따라서, Amazon EC2 Auto Scaling은 기존 인스턴스를 종료하기 전에 워크로드를 지원할 충분한 용량을 확보하는 데 걸리는 시간을 고려할 수 있습니다.
또한 기본 인스턴스 워밍업 기능을 사용하여 동적 조정에 사용되는 Amazon CloudWatch 지표도 개선할 수 있습니다. Auto Scaling 그룹에 조정 정책이 있는 경우 그룹이 스케일 아웃될 때 동일한 기본 준비 기간을 사용하여 인스턴스가 초기화를 완료하기 전에 CloudWatch 지표에 포함되는 것을 방지합니다.
자세한 내용은 [Auto Scaling 그룹의 기본 인스턴스 워밍업 설정](ec2-auto-scaling-default-instance-warmup.md)(을)를 참조하세요.
## 건전성 체크 유예 기간
Amazon EC2 Auto Scaling은 Auto Scaling 그룹이 사용하는 건전성 체크의 상태에 따라 인스턴스가 정상인지 여부를 결정합니다. 자세한 설명은 [Auto Scaling 그룹의 인스턴스에 대한 상태 확인](ec2-auto-scaling-health-checks.md) 섹션을 참조하세요.
건전성 체크가 최대한 빨리 시작되게 하려면 그룹의 건전성 체크 유예 기간을 너무 길게 설정하지 마세요. 하지만 Elastic Load Balancing 건전성 체크에서 대상이 요청을 처리할 수 있는지 확인할 수 있을 만큼 길게 설정하세요. 자세한 내용은 [Auto Scaling 그룹의 상태 확인 유예 기간 설정](health-check-grace-period.md)(을)를 참조하세요.
## Auto Scaling 그룹 조정
인스턴스 유지 관리 정책은 인스턴스 유지 관리 이벤트에만 적용되며 그룹을 수동 또는 자동으로 조정하는 것을 방지하지 못합니다.
Auto Scaling 그룹에 연결된 조정 정책 또는 예약된 작업이 있으면 인스턴스 유지 관리 이벤트가 발생하는 동안 병렬로 실행할 수 있습니다. 이 경우 사용자가 정의한 조정 한도 내에서만 그룹의 원하는 용량을 늘리거나 줄일 수 있습니다. 한도에 대한 자세한 내용은 [Auto Scaling 그룹에 대한 스케일링 제한 설정](asg-capacity-limits.md)(을)를 참조하세요.
## 예제 시나리오
일반적인 시나리오에서 인스턴스 유지 관리 정책과 원하는 용량은 다음과 같을 수 있습니다.
+ 최소 정상 백분율 = 90%
+ 최대 건전 백분율 = 120%
+ 원하는 용량 = 100
인스턴스 유지 관리 이벤트 중에 Auto Scaling 그룹에는 적게는 90개에서 많게는 120개의 인스턴스가 있을 수 있습니다. 이벤트가 끝나면 그룹은 다시 100개의 인스턴스를 보유하게 됩니다.
웜 풀이 있는 Auto Scaling 그룹에서 인스턴스 유지 관리 정책을 사용하는 경우 최소 및 최대 정상 비율이 Auto Scaling 그룹과 웜 풀에 각각 적용됩니다.
예를 들어, 다음과 같은 구성을 가정해 보겠습니다.
+ 최소 정상 백분율 = 90%
+ 최대 건전 백분율 = 120%
+ 원하는 용량 = 100
+ 웜 풀 크기 = 10
그룹의 인스턴스를 재활용하기 위해 인스턴스 새로 고침을 시작하는 경우 Amazon EC2 Auto Scaling은 Auto Scaling 그룹의 인스턴스를 먼저 교체한 다음 웜 풀의 인스턴스를 교체합니다. Amazon EC2 Auto Scaling은 아직 Auto Scaling 그룹의 인스턴스를 교체하는 작업을 진행 중이지만 그룹에 적게는 90개에서 많게는 120개의 인스턴스가 있을 수 있습니다. Amazon EC2 Auto Scaling은 그룹 작업을 완료한 후 웜 풀의 인스턴스를 교체하는 작업을 수행할 수 있습니다. 이 경우 웜 풀에는 최소 9개에서 최대 12개의 인스턴스가 있을 수 있습니다.
# Auto Scaling 그룹에서 인스턴스 유지 관리 정책 설정
Auto Scaling 그룹을 만들 때 인스턴스 유지 관리 정책을 생성할 수 있습니다. 기존 그룹에서도 생성할 수 있습니다.
Auto Scaling 그룹에서 인스턴스 유지 관리 정책을 설정하면 인스턴스 유지 관리 정책을 재정의하지 않는 한 인스턴스 새로 고침 기능에 대한 최소 및 최대 정상 백분율 파라미터 값을 더 이상 지정할 필요가 없습니다.
콘솔에서는 Amazon EC2 Auto Scaling에서 제공하는 옵션이 시작하는 데 도움이 됩니다.
**Topics**
+ [인스턴스 유지 관리 정책 설정](set-instance-maintenance-policy.md)
+ [인스턴스 유지 관리 정책 제거](remove-instance-maintenance-policy.md)
# 인스턴스 유지 관리 정책 설정
Auto Scaling 그룹에서 인스턴스 유지 관리 정책을 설정하려면 다음 방법 중 하나를 사용합니다.
------
#### [ Console ]
**새 그룹에 인스턴스 유지 관리 정책을 설정하려면(콘솔)**
1. [시작 템플릿을 사용하여 Auto Scaling 그룹 생성](create-asg-launch-template.md)의 지침에 따라 절차의 각 단계(최대 11단계)를 완료합니다.
1. **그룹 크기 및 조정 정책 구성**의 **원하는 용량**에 시작할 인스턴스의 초기 수를 입력합니다.
1. **스케일링** 섹션의 **스케일링 제한**에서 **희망 용량**에 대한 새 값이 **최소 희망 용량** 및 **최대 희망 용량**보다 큰 경우, **최대 희망 용량**은 자동으로 새 희망 용량 값으로 증가합니다. 필요에 따라 이러한 제한을 변경할 수 있습니다.
1. **자동 조정**의 경우, 대상 추적 조정 정책을 생성할지 여부를 선택합니다. Auto Scaling 그룹을 생성한 후에 이 정책을 생성할 수도 있습니다.
**대상 추적 조정 정책**을 선택하는 경우 [대상 추적 조정 정책 생성](policy_creating.md)의 지침에 따라 정책을 생성합니다.
1. **인스턴스 유지 관리 정책** 섹션에서 사용 가능한 옵션 중 하나를 선택합니다.
+ **종료 전 시작**: 기존 인스턴스를 종료하기 전에 새 인스턴스를 프로비저닝해야 합니다. 이 방식은 비용 절감보다 가용성을 선호하는 경우에 적합합니다.
+ **해지 후 시작**: 기존 인스턴스가 해지되는 것과 동시에 새 인스턴스가 시작됩니다. 이 방식은 가용성보다 비용 절감을 선호하는 경우에 적합합니다. 또한 현재 사용 가능한 용량보다 많은 용량을 실행하지 않아야 하는 애플리케이션에도 적합합니다.
+ **사용자 지정 정책**: 이 옵션을 사용하면 인스턴스 교체 시 사용할 수 있는 용량에 대한 사용자 지정 최소 및 최대 범위로 정책을 설정할 수 있습니다. 이는 비용과 가용성의 균형을 적절하게 조정하는 데 도움이 될 수 있습니다.
1. **정상 백분율 설정**의 경우, 다음 필드 중 하나 또는 둘 다에 값을 입력합니다. 활성화된 필드는 이전 단계에서 선택한 옵션에 따라 달라집니다.
+ **최소**: 인스턴스 교체를 진행하는 데 필요한 최소 정상 비율을 설정합니다.
+ **최대**: 인스턴스 교체 시 가능한 최대 정상 비율을 설정합니다.
1. **원하는 용량을 기준으로 교체 중 용량 보기** 섹션을 확장하여 **최소** 및 **최대** 값이 그룹에 어떻게 적용되는지 확인하세요. 사용되는 정확한 값은 원하는 용량 값에 따라 달라지며, 이 값은 그룹이 조정되면 변경됩니다.
1. [시작 템플릿을 사용하여 Auto Scaling 그룹 생성](create-asg-launch-template.md)의 단계를 계속합니다.
------
#### [ AWS CLI ]
**새 그룹에 인스턴스 유지 관리 정책을 설정하려면(AWS CLI)**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령에 `--instance-maintenance-policy` 옵션을 추가합니다. 다음 예제에서는 이름이 `my-asg`로 지정된 새 Auto Scaling 그룹에서 인스턴스 유지 관리 정책을 설정합니다.
```
aws autoscaling create-auto-scaling-group \
--launch-template LaunchTemplateName=my-launch-template,Version='1' \
--auto-scaling-group-name my-asg \
--min-size 1 \
--max-size 10 \
--desired-capacity 5 \
--default-instance-warmup 20 \
--instance-maintenance-policy '{
"MinHealthyPercentage": 90,
"MaxHealthyPercentage": 120
}' \
--vpc-zone-identifier "subnet-5e6example,subnet-613example,subnet-c93example"
```
------
------
#### [ Console ]
**기존 그룹에 인스턴스 유지 관리 정책을 설정하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. 화면 상단의 탐색 모음에서 Auto Scaling 그룹을 생성한 AWS 리전 을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **세부 정보** 탭에서 **인스턴스 유지 관리 정책**, **편집**을 선택합니다.
1. 그룹에서 인스턴스 유지 관리 정책을 설정하려면 사용 가능한 옵션 중 하나를 선택합니다.
+ **종료 전 시작**: 기존 인스턴스를 종료하기 전에 새 인스턴스를 프로비저닝해야 합니다. 이 방식은 비용 절감보다 가용성을 선호하는 경우에 적합합니다.
+ **해지 후 시작**: 기존 인스턴스가 해지되는 것과 동시에 새 인스턴스가 시작됩니다. 이 방식은 가용성보다 비용 절감을 선호하는 경우에 적합합니다. 또한 현재 사용 가능한 용량보다 많은 용량을 실행하지 않아야 하는 애플리케이션에도 적합합니다.
+ **사용자 지정 정책**: 이 옵션을 사용하면 인스턴스 교체 시 사용할 수 있는 용량에 대한 사용자 지정 최소 및 최대 범위로 정책을 설정할 수 있습니다. 이는 비용과 가용성의 균형을 적절하게 조정하는 데 도움이 될 수 있습니다.
1. **정상 백분율 설정**의 경우, 다음 필드 중 하나 또는 둘 다에 값을 입력합니다. 활성화된 필드는 이전 단계에서 선택한 옵션에 따라 달라집니다.
+ **최소**: 인스턴스 교체를 진행하는 데 필요한 최소 정상 비율을 설정합니다.
+ **최대**: 인스턴스 교체 시 가능한 최대 정상 비율을 설정합니다.
1. **원하는 용량을 기준으로 교체 중 용량 보기** 섹션을 확장하여 **최소** 및 **최대** 값이 그룹에 어떻게 적용되는지 확인하세요. 사용되는 정확한 값은 원하는 용량 값에 따라 달라지며, 이 값은 그룹이 조정되면 변경됩니다.
1. **업데이트**를 선택합니다.
------
#### [ AWS CLI ]
**기존 그룹에 인스턴스 유지 관리 정책을 설정하려면(AWS CLI)**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) 명령에 `--instance-maintenance-policy` 옵션을 추가합니다. 다음 예제에서는 지정된 Auto Scaling 그룹에서 인스턴스 유지 관리 정책을 설정합니다.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \
--instance-maintenance-policy '{
"MinHealthyPercentage": 90,
"MaxHealthyPercentage": 120
}'
```
------
# 인스턴스 유지 관리 정책 제거
Auto Scaling 그룹에서 인스턴스 유지 관리 정책 사용을 중지하려면 해당 정책을 제거하면 됩니다.
------
#### [ Console ]
**인스턴스 유지 관리 정책을 제거하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. 화면 상단의 탐색 모음에서 Auto Scaling 그룹을 생성한 AWS 리전 을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **세부 정보** 탭에서 **인스턴스 유지 관리 정책**, **편집**을 선택합니다.
1. **인스턴스 유지 관리 정책 없음**을 선택합니다.
1. **업데이트**를 선택합니다.
------
#### [ AWS CLI ]
**인스턴스 유지 관리 정책을 제거하려면(AWS CLI)**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) 명령에 `--instance-maintenance-policy` 옵션을 추가합니다. 다음 예제에서는 지정된 Auto Scaling 그룹에서 인스턴스 유지 관리 정책을 제거합니다.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \
--instance-maintenance-policy '{
"MinHealthyPercentage": -1,
"MaxHealthyPercentage": -1
}'
```
------
# Amazon EC2 Auto Scaling 수명 주기 후크
Amazon EC2 Auto Scaling은 Auto Scaling 그룹에 수명 주기 후크를 추가할 수 있는 기능을 제공합니다. 이러한 후크를 사용하면 Auto Scaling 인스턴스 수명 주기의 이벤트를 인식하는 솔루션을 생성한 다음 해당 수명 주기 이벤트가 발생할 때 인스턴스에 대한 사용자 정의 작업을 수행할 수 있습니다. 수명 주기 후크는 인스턴스가 다음 상태로 전환되기 전에 작업이 완료될 때까지 대기할 지정된 시간(기본적으로 1시간)을 제공합니다.
Auto Scaling 인스턴스에서 수명 주기 후크를 사용하는 예는 다음과 같습니다.
+ 스케일 아웃 이벤트가 발생하면 새로 시작된 인스턴스는 시작 시퀀스를 완료하고 대기 상태로 전환합니다. 인스턴스가 대기 상태에 있는 동안 그룹은 스크립트를 실행하여 애플리케이션에 필요한 소프트웨어 패키지를 다운로드해 설치하여 트래픽 수신을 시작하기 전에 인스턴스가 준비를 마치도록 합니다. 스크립트가 소프트웨어 설치를 마치면 **complete-lifecycle-action** 명령을 전송하여 계속 진행합니다.
+ 축소 이벤트가 발생하는 경우, 수명 주기 후크는 인스턴스가 해지되기 전 인스턴스를 일시 중지하고 Amazon EventBridge를 사용하여 알림을 보냅니다. 인스턴스가 대기 상태인 동안 AWS Lambda 함수를 호출하거나 인스턴스가 완전히 종료되기 전에 인스턴스에 연결하여 로그 또는 기타 데이터를 다운로드할 수 있습니다.
수명 주기 후크의 일반적인 용도는 인스턴스가 Elastic Load Balancing에 등록되는 시점을 제어하는 것입니다. Auto Scaling 그룹에 시작 수명 주기 후크를 추가하면 부트스트랩 스크립트가 성공적으로 완료되었고 수명 주기 후크 해지 시 로드 밸런서에 등록되기 전에 인스턴스의 애플리케이션이 트래픽을 수락할 준비가 되도록 할 수 있습니다.
**Topics**
+ [수명 주기 후크 가용성](#lifecycle-hooks-availability)
+ [고려 사항 및 제한 사항](#lifecycle-hook-considerations)
+ [관련 리소스](#lifecycle-hook-related-resources)
+ [Auto Scaling 그룹에서 수명 주기 후크 작동 방식](lifecycle-hooks-overview.md)
+ [수명 주기 후크 추가 준비](prepare-for-lifecycle-notifications.md)
+ [인스턴스 수명 주기 정책을 사용하여 인스턴스 보존 제어](instance-lifecycle-policy.md)
+ [대상 수명 주기 상태 검색](retrieving-target-lifecycle-state-through-imds.md)
+ [Auto Scaling 그룹에 수명 주기 후크 추가](adding-lifecycle-hooks.md)
+ [Auto Scaling 그룹에서 수명 주기 작업 완료](completing-lifecycle-hooks.md)
+ [자습서: 인스턴스 메타데이터를 사용하여 수명 주기 상태 검색](tutorial-lifecycle-hook-instance-metadata.md)
+ [자습서: Lambda 함수를 호출하는 수명 주기 후크 구성](tutorial-lifecycle-hook-lambda.md)
## 수명 주기 후크 가용성
다음 표에는 다양한 시나리오에 사용할 수 있는 수명 주기 후크가 나와 있습니다.
| 이벤트 | 인스턴스 시작 또는 해지¹ | [최대 인스턴스 수명 주기](asg-max-instance-lifetime.md): 교체 인스턴스 | [인스턴스 새로 고침](asg-instance-refresh.md): 교체 인스턴스 | [용량 재조정](ec2-auto-scaling-capacity-rebalancing.md): 교체 인스턴스 | [웜 풀](ec2-auto-scaling-warm-pools.md): 웜 풀에 들어오고 웜 풀에서 나가는 인스턴스 |
| --- | --- | --- | --- | --- | --- |
| 인스턴스 시작 | ✓ | ✓ | ✓ | ✓ | ✓ |
| 인스턴스 해지 | ✓ | ✓ | ✓ | ✓ | ✓ |
`SetDesiredCapacity` 또는 `TerminateInstanceInAutoScalingGroup` 작업을 호출할 때와 같이 자동으로 시작하든 수동으로 시작하든 모든 시작 및 해지에 적용됩니다. 강제 삭제 옵션을 사용하여 인스턴스를 연결 또는 분리하거나, 인스턴스를 대기 모드로 전환하거나 대기 모드에서 해제하거나, 그룹을 삭제할 때는 적용되지 않습니다.
## 수명 주기 후크에 대한 고려 사항 및 제한 사항
수명 주기 후크를 사용하는 경우, 다음 고려 사항 및 제한 사항에 유의하세요:
+ Amazon EC2 Auto Scaling은 Auto Scaling 그룹의 배치를 돕기 위해 자체 수명 주기를 제공합니다. 이 수명 주기는 다른 EC2 인스턴스의 수명 주기와 다릅니다. 자세한 설명은 [Amazon EC2 Auto Scaling 인스턴스 수명 주기](ec2-auto-scaling-lifecycle.md) 섹션을 참조하세요. [웜 풀의 인스턴스에 대한 수명 주기 상태 전환](warm-pool-instance-lifecycle.md#lifecycle-state-transitions)에 설명된 바와 같이, 웜 풀의 인스턴스에도 자체 수명 주기가 있습니다.
+ 기본적으로 종료 수명 주기 후크는 최선을 다해 작동합니다. 종료 수명 주기 후크가 시간 초과되거나 중단되면 Amazon EC2 Auto Scaling은 인스턴스를 즉시 종료합니다. 종료 수명 주기 후크를 인스턴스 보존을 위한 인스턴스 수명 주기 정책과 결합할 수 있습니다. 자세한 내용은 [인스턴스 수명 주기 정책을 사용하여 인스턴스 보존 제어](instance-lifecycle-policy.md) 단원을 참조하십시오.
+ 수명 주기 호크를 스팟 인스턴스와 함께 사용할 수 있지만 수명 주기 후크는 용량을 더 이상 사용할 수 없는 경우, 인스턴스 해지를 방지하지 않습니다. 이 상황은 2분 중단 알림과 함께 언제든지 발생할 수 있습니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [스팟 인스턴스 중단](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html)을 참조하세요. 그러나 Amazon EC2 스팟 서비스로부터 스팟 인스턴스의 중단 위험이 높아질 때 전송되는 신호인 리밸런싱 권고를 수신하는 스팟 인스턴스를 사전 교체하도록 용량 리밸런싱을 활성화할 수 있습니다. 자세한 설명은 [위험 상태의 스팟 인스턴스를 대체하기 위한 Auto Scaling의 용량 재조정](ec2-auto-scaling-capacity-rebalancing.md) 섹션을 참조하세요.
+ 인스턴스는 한정된 시간 동안 대기 상태를 유지할 수 있습니다. 수명 주기 후크의 기본 제한 시간은 1시간(하트비트 제한 시간)입니다. 인스턴스를 대기 상태로 유지할 수 있는 최대 시간을 지정하는 전역 제한 시간도 있습니다. 전역 제한 시간은 48시간 또는 하트비트 제한 시간의 100배 중 적은 쪽입니다.
+ 수명 주기 후크의 결과는 포기 또는 계속입니다. 인스턴스를 시작하는 중인 경우, 계속은 작업에 성공했고 Amazon EC2 Auto Scaling에서 인스턴스를 서비스 상태로 전환할 수 있음을 나타냅니다. 그에 반해 포기는 사용자 지정 작업이 실패했으며, 인스턴스를 해지하고 교체할 수 있음을 표시합니다. 인스턴스가 해지 중인 경우에는 포기와 계속 둘 다 인스턴스 해지를 허용합니다. 그러나 중단은 수명 주기 후크와 같은 남아 있는 모든 작업을 중지하는 반면, 계속은 다른 모든 수명 주기 후크를 완료합니다.
+ Amazon EC2 Auto Scaling은 수명 주기 후크가 일관되게 실패하는 경우, 인스턴스를 시작할 수 있도록 허용하는 속도를 제한하므로 수명 주기 작업의 영구적 오류를 테스트하고 수정해야 합니다.
+ AWS CLI CloudFormation또는 SDK를 사용하여 수명 주기 후크를 생성하고 업데이트하면에서 수명 주기 후크를 생성할 때 사용할 수 없는 옵션이 제공됩니다 AWS Management Console. 예컨대, Amazon EC2 Auto Scaling에서 먼저 Amazon EventBridge로 이벤트를 전송하기 때문에 SNS 주제 또는 SQS 대기열의 ARN을 지정하는 필드가 콘솔에 표시되지 않습니다. 이러한 이벤트는 필요에 따라 필터링하여 Lambda, Amazon SNS 및 Amazon SQS와 같은 AWS 서비스로 리디렉션할 수 있습니다.
+ 생성 중에 AWS CLI CloudFormation또는 SDK를 사용하여 CreateAutoScalingGroup API를 호출하여 Auto Scaling 그룹에 여러 수명 주기 후크를 추가할 수 있습니다. [CreateAutoScalingGroup](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CreateAutoScalingGroup.html) 그러나 지정된 경우, 각 후크에는 동일한 알림 대상 및 IAM 역할이 있어야 합니다. 다른 알림 대상 및 다른 역할을 사용하여 수명 주기 후크를 생성하려면 [PutLifecycleHook](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PutLifecycleHook.html) API를 별도로 호출해 한 번에 하나씩 수명 주기 후크를 생성합니다.
+ 인스턴스 시작을 위한 수명 주기 후크를 추가하면 인스턴스가 상태에 도달하는 즉시 `InService` 건전성 체크 유예 기간이 시작됩니다. 자세한 설명은 [Auto Scaling 그룹의 상태 확인 유예 기간 설정](health-check-grace-period.md) 섹션을 참조하세요.
**스케일 아웃 고려 사항**
+ 동적 스케일링 정책은 여러 인스턴스에 걸쳐 집계되는 CPU 및 네트워크 I/O와 같은 CloudWatch 지표 데이터에 따라 스케일 인 및 아웃이 이루어집니다. 스케일 아웃 시, Amazon EC2 Auto Scaling은 Auto Scaling 그룹의 집계된 인스턴스 지표에 새 인스턴스를 즉시 계산하지 않습니다. 인스턴스가 `InService` 상태에 도달하고 인스턴스 워밍업이 완료될 때까지 기다립니다. 자세한 설명은 기본 인스턴스 워밍업 주제에 대한 [스케일링 수행 고려 사항](ec2-auto-scaling-default-instance-warmup.md#scaling-performance-considerations) 섹션을 참조하세요.
+ 스케일 인 시 집계된 인스턴스 지표에 해지 인스턴스 제거가 즉시 반영되지 않을 수 있습니다. Amazon EC2 Auto Scaling 해지 워크플로우가 시작된 직후 해지 인스턴스는 그룹의 집계된 인스턴스 지표에 대한 계산을 중지합니다.
+ 대부분의 경우에 수명 주기 후크가 호출되면 수명 주기 작업이 완료되고 냉각 기간이 만료될 때까지 단순 크기 조정 정책으로 인한 크기 조정 활동이 일시 중지됩니다. 냉각 기간에 긴 간격을 설정하면 크기 조정을 재개하는 데 더 많은 시간이 걸립니다. 자세한 설명은 냉각 주제에서 [수명 주기 후크는 추가적 지연을 야기할 수 있습니다.](ec2-auto-scaling-scaling-cooldowns.md#cooldowns-lifecycle-hooks) 섹션을 참조하세요. 일반적으로 단계 스케일링 또는 대상 추적 스케일링 정책을 대신 사용할 수 있는 경우, 단순 스케일링 정책을 사용하지 않는 것이 좋습니다.
## 관련 리소스
소개 동영상은 *YouTube*.에서 [AWS re:Invent 2018: Capacity Management Made Easy with Amazon EC2 Auto Scaling(Amazon EC2 Auto Scaling으로 간편하게 용량 관리하기)](https://youtu.be/PideBMIcwBQ?t=469)을 참조하세요.
CloudFormation 스택 템플릿에서 수명 주기 후크를 선언하는 방법을 이해하는 데 사용할 수 있는 몇 가지 JSON 및 YAML 템플릿 코드 조각을 제공합니다. 자세한 설명은 *AWS CloudFormation 사용자 가이드*의 [AWS::AutoScaling::LifecycleHook](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-autoscaling-lifecyclehook.html) 레퍼런스를 참조하세요.
[GitHub 리포지토리](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)를 방문하여 수명 주기 후크용 예 템플릿과 사용자 데이터 스크립트를 다운로드할 수도 있습니다.
수명 주기 후크의 사용 예는 다음 블로그 게시물을 참조하세요.
+ [Lambda 및 Amazon EC2 실행 명령을 사용하여 스케일 아웃된 인스턴스를 위한 백업 시스템 구축](https://aws.amazon.com/blogs/compute/building-a-backup-system-for-scaled-instances-using-aws-lambda-and-amazon-ec2-run-command/)
+ [EC2 Auto Scaling 인스턴스를 해지하기 전에 코드를 실행합니다](https://aws.amazon.com/blogs/infrastructure-and-automation/run-code-before-terminating-an-ec2-auto-scaling-instance/).
# Auto Scaling 그룹에서 수명 주기 후크 작동 방식
Amazon EC2 인스턴스는 시작한 순간부터 해지될 때까지 여러 상태로 전환됩니다. 수명 주기 후크로 인해 인스턴스가 대기 상태로 전환될 때 Auto Scaling 그룹이 행동하도록 사용자 지정 조치를 만들 수 있습니다.
다음 그림은 스케일 아웃 및 스케일 인을 위해 수명 주기 후크를 사용할 때 Auto Scaling 인스턴스 상태 간 전환을 보여줍니다.
![\[스케일 아웃 및 스케일 인을 위해 수명 주기 후크를 사용할 때 Auto Scaling 인스턴스 상태 간 전환을 나타냅니다.\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/how-lifecycle-hooks-work.png)
앞의 다이어그램에 표시된 것처럼 다음과 같습니다.
1. Auto Scaling 그룹은 스케일 아웃 이벤트에 응답하고 인스턴스 실행을 시작합니다.
1. 수명 주기 후크는 인스턴스를 대기 상태(`Pending:Wait`)로 전환한 다음 사용자 지정 작업을 수행합니다.
인스턴스는 수명 주기 작업을 완료하거나 제한 시간이 끝날 때까지 대기 상태로 유지됩니다. 기본적으로 인스턴스는 한 시간 동안 대기 상태로 유지된 후 Auto Scaling 그룹에서 시작 프로세스를 진행합니다(`Pending:Proceed`). 시간이 더 필요한 경우, 하트비트를 기록하여 제한 시간을 다시 시작할 수 있습니다. 사용자 지정 작업이 완료됐으나 제한 기간이 만료되지 않았을 때 수명 주기 작업을 완료하면 제한 기간이 해지되고 Auto Scaling 그룹이 시작 프로세스를 계속합니다.
1. 인스턴스가 `InService` 상태로 전환되고 건전성 체크 유예 기간이 시작됩니다. 그러나 인스턴스가 `InService` 상태에 도달하기 전에, Auto Scaling 그룹이 Elastic Load Balancing 로드 밸런서와 연결된 경우, 인스턴스가 로드 밸런서에 등록되고 로드 밸런서가 해당 상태를 확인하기 시작합니다. 건전성 체크 유예 기간이 끝나면 Amazon EC2 Auto Scaling이 인스턴스의 건전성 체크를 시작합니다.
1. Auto Scaling 그룹은 축소 이벤트에 응답하고 인스턴스 해지를 시작합니다. Auto Scaling 그룹이 Elastic Load Balancing과 함께 사용되는 경우, 해지 인스턴스가 먼저 로드 밸런서에서 등록 취소됩니다. 로드 밸런서에 대해 Connection Draining이 활성화된 경우, 인스턴스는 새 연결 수락을 중지하고 기존 연결이 드레이닝될 때까지 기다린 다음 등록 취소 프로세스를 완료합니다.
1. 수명 주기 후크는 인스턴스를 대기 상태(`Terminating:Wait`)로 전환한 다음 사용자 지정 작업을 수행합니다.
수명 주기 작업을 완료할 때까지 혹은 제한 시간(기본 1시간)이 끝날 때까지 인스턴스는 대기 상태로 유지됩니다. 수명 주기 후크를 완료하거나 시간 초과 기간이 만료되면 인스턴스가 다음 상태(`Terminating:Proceed`)로 전환됩니다.
1. 인스턴스가 해지됩니다.
**중요**
[웜 풀의 인스턴스에 대한 수명 주기 상태 전환](warm-pool-instance-lifecycle.md#lifecycle-state-transitions)에 설명된 바와 같이, 웜 풀의 인스턴스에도 해당 대기 상태와 자체 수명 주기가 있습니다.
## 루트 볼륨 교체 중인 인스턴스의 수명 주기 상태 전환
다음 다이어그램은 루트 볼륨 교체에 수명 주기 후크를 사용할 때 Auto Scaling 인스턴스 상태 간 전환을 보여줍니다.
![\[루트 볼륨 대체에 수명 주기 후크를 사용하는 경우 Auto Scaling 인스턴스 상태 간 전환입니다.\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/root-volume-replacement-lifecycle-states.png)
앞의 다이어그램에 표시된 것처럼 다음과 같습니다.
1. Auto Scaling 그룹은 인스턴스 새로 고침에 응답하고 루트 볼륨 교체를 위한 인스턴스를 선택합니다. 인스턴스가 `ReplacingRootVolume` 상태로 전환됩니다. 인스턴스가 로드 밸런서에 등록된 경우 로드 밸런서에서 등록 취소됩니다.
1. 수명 주기 후크는 인스턴스를 대기 상태(`ReplacingRootVolume:Wait`)로 전환한 다음 사용자 지정 작업을 수행합니다. 인스턴스는 수명 주기 작업을 완료하거나 제한 시간이 끝날 때까지 대기 상태로 유지됩니다. 사용자 지정 작업이 완료되고 제한 시간이 아직 만료되지 않은 상태에서 수명 주기 작업을 완료하면 기간이 종료되고 Auto Scaling 그룹이 루트 볼륨 교체 프로세스를 계속합니다.
1. 인스턴스가 루트 볼륨 교체를 완료하고 `RootVolumeReplaced` 상태로 전환됩니다.
1. 인스턴스가 `Pending` 상태로 전환됩니다.
1. 수명 주기 후크는 인스턴스를 대기 상태(`Pending:Wait`)로 전환한 다음 사용자 지정 작업을 수행합니다. 수명 주기 작업을 완료할 때까지 또는 제한 시간이 끝날 때까지 인스턴스는 대기 상태로 유지됩니다. 수명 주기 후크를 완료하거나 시간 초과 기간이 만료되면 인스턴스가 다음 상태(`Pending:Proceed`)로 전환됩니다.
1. 인스턴스가 `InService` 상태로 전환됩니다. 그러나 인스턴스가 `InService` 상태에 도달하기 전에 Auto Scaling 그룹이 Elastic Load Balancing 로드 밸런서와 연결된 경우 인스턴스는 로드 밸런서에 등록됩니다.
# Auto Scaling 그룹에 대한 수명 주기 후크 추가 준비
Auto Scaling 그룹에 수명 주기 후크를 추가하기 전에 사용자 데이터 스크립트 또는 알림 대상이 올바르게 설정되어 있는지 확인하세요.
+ 인스턴스가 시작될 때 사용자 데이터 스크립트를 사용하여 사용자 지정 작업을 수행하려는 경우, 알림 대상을 구성할 필요가 없습니다. 그러나 사용자 데이터 스크립트를 지정하는 시작 템플릿 또는 시작 구성을 사전에 생성하고 이를 Auto Scaling 그룹과 연결해야 합니다. 사용자 데이터 스크립트에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [시작 시 Linux 인스턴스에서 명령 실행](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)을 참조하세요.
+ 수명 주기 작업이 완료되었을 때 Amazon EC2 Auto Scaling에 신호를 보내려면 스크립트에 [CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html) API 호출을 추가하고 Auto Scaling 인스턴스가 이 API를 호출하도록 허용하는 정책을 사용하여 IAM 역할을 수동으로 생성해야 합니다. 시작 템플릿 또는 시작 구성은 시작 시 Amazon EC2 인스턴스에 연결되는 IAM 인스턴스 프로필을 사용하여 이 역할을 지정해야 합니다. 자세한 내용은 [Auto Scaling 그룹에서 수명 주기 작업 완료](completing-lifecycle-hooks.md) 및 [Amazon EC2 인스턴스에서 실행되는 애플리케이션에 대한 IAM 역할](us-iam-role.md) 섹션을 참조하세요.
+ 수명 주기 작업이 완료되었을 때 Lambda가 Amazon EC2 Auto Scaling에 신호를 보내도록 하려면 [CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html) API 호출을 함수 코드에 추가해야 합니다. 또한 Lambda에 수명 주기 작업을 완료할 수 있는 권한을 부여하는 함수의 집행 역할에 IAM 정책을 연결해야 합니다. 자세한 설명은 [자습서: Lambda 함수를 호출하는 수명 주기 후크 구성](tutorial-lifecycle-hook-lambda.md) 섹션을 참조하세요.
+ Amazon SNS 또는 Amazon SQS와 같은 서비스를 사용하여 사용자 지정 작업을 수행하려면 사전에 SNS 주제 또는 SQS 대기열을 생성하고 Amazon 리소스 이름(ARN)을 준비해야 합니다. 또한 사전에 Amazon EC2 Auto Scaling에 SNS 주제 또는 SQS 대상에 대한 액세스 권한을 부여하는 IAM 역할을 생성하고 ARN을 준비해야 합니다. 자세한 설명은 [수명 주기 알림에 대한 알림 대상 구성](#lifecycle-hook-notification-target) 섹션을 참조하세요.
**참고**
기본적으로 콘솔에 수명 주기 후크를 추가하면 Amazon EC2 Auto Scaling이 Amazon EventBridge EventBridge로 수명 주기 이벤트 알림을 전송합니다. 권장되는 모범 사례는 EventBridge 또는 사용자 데이터 스크립트를 사용하는 것입니다. 알림을 Amazon SNS, Amazon SQS 또는 로 직접 보내는 수명 주기 후크를 생성하려면 AWS CLI,, AWS CloudFormation 또는 SDK를 AWS Lambda사용하여 수명 주기 후크를 추가합니다.
## 수명 주기 알림에 대한 알림 대상 구성
Auto Scaling 그룹에 수명 주기 후크를 추가하여 인스턴스가 대기 상태로 전환될 때 사용자 정의 작업을 수행할 수 있습니다. 선호하는 개발 방식에 따라 다양한 Amazon Web Services를 사용하여 이러한 작업을 수행하도록 알림 대상을 구성할 수 있습니다.
수명 주기 후크에 대한 알림 대상을 구현하기 위한 네 가지 접근 방식이 있습니다.
+ **Amazon EventBridge** - 알림을 수신하고 원하는 작업을 수행합니다.
+ **Amazon Simple Notification Service(Amazon SNS)** - 알림을 게시하기 위한 주제를 생성합니다. 클라이언트는 SNS 주제를 구독하고 지원되는 프로토콜을 사용하여 게시된 메시지를 수신할 수 있습니다.
+ **Amazon Simple Queue Service(Amazon SQS)** - 폴링 모델을 통해 메시지를 교환합니다.
+ **AWS Lambda** - 원하는 작업을 수행하는 Lambda 함수를 간접적으로 호출합니다.
EventBridge를 사용하는 방법이 가장 좋습니다. Amazon SNS 및 Amazon SQS로 전송되는 알림에는 Amazon EC2 Auto Scaling이 EventBridge에 전송하는 알림과 동일한 정보가 포함되어 있습니다. EventBridge를 사용하기 전에는 SNS 또는 SQS에 알림을 보내고 다른 서비스를 SNS 또는 SQS와 통합하여 프로그래밍 작업을 수행하는 것이 표준 방식이었습니다. 현재, EventBridge는 대상으로 지정할 수 있는 서비스에 대해 더 많은 옵션을 제공하며 서버리스 아키텍처를 사용하여 이벤트를 더욱 쉽게 처리할 수 있도록 합니다.
시작 템플릿 또는 시작 구성에 인스턴스가 시작될 때 인스턴스를 구성하는 사용자 지정 스크립트가 있는 경우, 인스턴스에 사용자 지정 작업을 수행하기 위해 알림을 받을 필요가 없습니다.
다음 절차에서는 알림 대상을 설정하는 방법에 대해 설명합니다.
**Topics**
+ [EventBridge를 사용하여 Lambda로 알림 라우팅](#cloudwatch-events-notification)
+ [Amazon SNS를 사용하여 알림 수신](#sns-notifications)
+ [Amazon SQS 사용하여 알림 수신](#sqs-notifications)
+ [에 AWS Lambda 직접 알림 라우팅](#lambda-notification)
+ [알림 메시지의 예](#notification-message-example)
**중요**
수명 주기 후크와 함께 사용하는 EventBridge 규칙, Lambda 함수, Amazon SNS 주제 및 Amazon SQS 대기열은 항상 Auto Scaling 그룹을 생성한 지역에 있어야 합니다.
### EventBridge를 사용하여 Lambda로 알림 라우팅
인스턴스가 대기 상태로 전환될 때 Lambda 함수를 호출하도록 EventBridge 규칙을 구성할 수 있습니다. Amazon EC2 Auto Scaling은 시작되거나 해지되는 인스턴스에 대한 수명 주기 이벤트 알림과 수명 주기 작업을 제어하는 데 사용할 수 있는 토큰을 EventBridge에 전송합니다. 이러한 이벤트의 예는 [Amazon EC2 Auto Scaling 이벤트 참조](ec2-auto-scaling-event-reference.md) 섹션을 참조하세요.
**참고**
AWS Management Console 를 사용하여 이벤트 규칙을 생성하면 콘솔은 EventBridge에 Lambda 함수를 호출할 수 있는 권한을 부여하는 데 필요한 IAM 권한을 자동으로 추가합니다. AWS CLI를 사용하여 이벤트 규칙을 만드는 경우, 이 권한을 명시적으로 부여해야 합니다.
EventBridge 콘솔에서 이벤트 규칙을 생성하는 방법에 대한 자세한 설명은 [Amazon EventBridge User Guide](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)(Amazon EventBridge 사용자 가이드)의 *Creating Amazon EventBridge rules that react to events*(이벤트에 대응하는 Amazon EventBridge 규칙 생성)를 참조하세요.
또는
콘솔 사용자를 대상으로 하는 입문자용 자습서는 [자습서: Lambda 함수를 호출하는 수명 주기 후크 구성](tutorial-lifecycle-hook-lambda.md) 섹션을 참조하세요. 이 자습서에서는 시작 이벤트를 수신하여 CloudWatch Logs 로그에 기록하는 간단한 Lambda 함수를 만드는 방법을 보여줍니다.
**Lambda 함수를 호출하는 EventBridge 규칙 생성**
1. [Lambda 콘솔](https://console.aws.amazon.com/lambda/home#/functions)을 사용하여 Lambda 함수를 생성하고 Amazon 리소스 이름(ARN)을 적어둡니다. 예를 들어 `arn:aws:lambda:region:123456789012:function:my-function`입니다. EventBridge 대상을 생성하려면 ARN이 필요합니다. 자세한 설명은 *AWS Lambda 개발자 가이드*에서 [Lambda 시작하기](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html)를 참조하세요.
1. 인스턴스 시작에 대한 이벤트와 일치하는 규칙을 생성하려면 다음 [put-rule](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/events/put-rule.html) 명령을 사용합니다.
```
aws events put-rule --name my-rule --event-pattern file://pattern.json --state ENABLED
```
다음 예에서는 인스턴스 시작 수명 주기 작업을 위한 `pattern.json`을 보여 줍니다. **기울임꼴** 텍스트를 Auto Scaling 그룹의 이름으로 바꿉니다.
```
{
"source": [ "aws.autoscaling" ],
"detail-type": [ "EC2 Instance-launch Lifecycle Action" ],
"detail": {
"AutoScalingGroupName": [ "my-asg" ]
}
}
```
이 명령이 성공적으로 실행되면 EventBridge는 규칙의 ARN을 사용하여 응답합니다. ARN을 적어 두세요. 4단계에서 이 정보가 필요합니다.
다른 이벤트와 일치하는 규칙을 생성하려면 이벤트 패턴을 수정합니다. 자세한 설명은 [EventBridge를 사용하여 Auto Scaling 이벤트 처리](automating-ec2-auto-scaling-with-eventbridge.md) 섹션을 참조하세요.
1. 규칙의 대상으로 사용할 Lambda 함수를 지정하려면 다음 [put-targets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/events/put-targets.html) 명령을 사용합니다.
```
aws events put-targets --rule my-rule --targets Id=1,Arn=arn:aws:lambda:region:123456789012:function:my-function
```
앞의 명령에서 *my-rule*은 2단계에서 규칙에 지정한 이름이고, `Arn` 파라미터 값은 1단계에서 생성한 함수의 ARN입니다.
1. 규칙이 Lambda 함수를 호출하도록 허용하는 권한을 추가하려면 다음 Lambda [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) 명령을 사용합니다. 이 명령은 EventBridge 서비스 보안 주체(`events.amazonaws.com`)를 신뢰하고 지정된 규칙에 대한 권한의 범위를 지정합니다.
```
aws lambda add-permission --function-name my-function --statement-id my-unique-id \
--action 'lambda:InvokeFunction' --principal events.amazonaws.com --source-arn arn:aws:events:region:123456789012:rule/my-rule
```
앞의 명령에서:
+ *my-function*은 규칙에서 대상으로 사용하도록 할 Lambda 함수의 이름입니다.
+ *my-unique-id*는 Lambda 함수 정책의 명령문을 설명하기 위해 정의하는 고유 식별자입니다.
+ `source-arn`은 EventBridge 규칙의 ARN입니다.
이 명령이 성공적으로 실행되면 다음과 비슷한 출력이 표시됩니다.
```
{
"Statement": "{\"Sid\":\"my-unique-id\",
\"Effect\":\"Allow\",
\"Principal\":{\"Service\":\"events.amazonaws.com\"},
\"Action\":\"lambda:InvokeFunction\",
\"Resource\":\"arn:aws:lambda:us-west-2:123456789012:function:my-function\",
\"Condition\":
{\"ArnLike\":
{\"AWS:SourceArn\":
\"arn:aws:events:us-west-2:123456789012:rule/my-rule\"}}}"
}
```
`Statement` 값은 Lambda 함수 정책에 추가된 문의 JSON 문자열 버전입니다.
1. 이 지침을 따른 후에는 다음 단계 [Auto Scaling 그룹에 수명 주기 후크 추가](adding-lifecycle-hooks.md)로 계속 진행합니다.
### Amazon SNS를 사용하여 알림 수신
Amazon SNS를 사용하여 수명 주기 작업 발생 시 알림을 수신하도록 Amazon SNS 알림 대상(SNS 주제)을 설정할 수 있습니다. 그러면 Amazon SNS에서는 구독한 수신자에게 알림을 보냅니다. 구독이 확인되기 전에는 주제에 게시된 알림이 수신자에게 전송되지 않습니다.
**Amazon SNS를 사용하여 알림 설정**
1. [Amazon SNS 콘솔](https://console.aws.amazon.com/sns/) 또는 다음 [create-topic](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sns/create-topic.html) 명령을 사용하여 Amazon SNS 주제를 생성합니다. 사용 중인 Auto Scaling 그룹과 동일한 지역에 주제가 있는지 확인합니다. 자세한 설명은 *Amazon Simple Notification Service 개발자 안내서*의 [Amazon SNS 시작하기](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html)를 참조하세요.
```
aws sns create-topic --name my-sns-topic
```
1. 주제 Amazon 리소스 이름(ARN)을 기록합니다(예: `arn:aws:sns:region:123456789012:my-sns-topic`). 이 이름은 수명 주기 후크를 생성하는데 필요합니다.
1. Amazon SNS 알림 대상에게 Amazon EC2 Auto Scaling 액세스 권한을 부여할 IAM 서비스 역할을 생성합니다.
**Amazon EC2 Auto Scaling에 SNS 주제에 대한 액세스 권한 부여**
1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.
1. 왼쪽의 탐색 창에서 **역할**을 선택합니다.
1. **역할 생성**을 선택합니다.
1. **신뢰할 수 있는 엔터티 선택(Select trusted entity)**에서 **AWS 서비스( service)**를 선택합니다.
1. 사용 사례를 보려면 **다른 AWS 서비스의 사용 사례(Use cases for other services)**에서 **EC2 Auto Scaling**을 선택한 다음 **EC2 Auto Scaling 알림 액세스(EC2 Auto Scaling Notification Access)**를 선택합니다.
1. **다음(Next)**을 두 번 선택하여 **이름 지정, 검토 및 생성(Name, review, and create)** 페이지로 이동합니다.
1. **역할 이름(Role name)**에 역할의 이름(예: **my-notification-role**)을 입력하고 **역할 생성(Create role)**을 선택합니다.
1. **역할** 페이지에서 방금 만든 역할을 선택하여 **요약** 페이지를 엽니다. 역할 **ARN**을 기록해 둡니다. 예를 들어 `arn:aws:iam::123456789012:role/my-notification-role`입니다. 이 이름은 수명 주기 후크를 생성하는데 필요합니다.
1. 이 지침을 따른 후에는 다음 단계 [수명 주기 후크 추가(AWS CLI)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-aws-cli)로 계속 진행합니다.
### Amazon SQS 사용하여 알림 수신
Amazon SQS를 사용하여 수명 주기 작업이 발생할 때 메시지를 수신할 알림 대상을 설정할 수 있습니다. 그런 다음 대기열 소비자는 이러한 알림에 따라 작업을 수행하기 위해 SQS 대기열을 폴링해야 합니다.
**중요**
FIFO 대기열은 수명 주기 후크와 호환되지 않습니다.
**Amazon SQS를 사용하여 알림 설정**
1. [Amazon SQS 콘솔](https://console.aws.amazon.com/sqs/)을 사용하여 SQS 대기열을 생성합니다. 사용 중인 Auto Scaling 그룹과 동일한 지역에 대기열이 있는지 확인합니다. 자세한 설명은 *Amazon Simple Queue Service 개발자 안내서*의 [Amazon SQS 시작하기](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)를 참조하세요.
1. 대기열 ARN을 적어 둡니다(예: `arn:aws:sqs:us-west-2:123456789012:my-sqs-queue`). 이 이름은 수명 주기 후크를 생성하는데 필요합니다.
1. Amazon SQS 알림 대상에게 Amazon EC2 Auto Scaling 액세스 권한을 부여할 IAM 서비스 역할을 생성합니다.
**Amazon EC2 Auto Scaling에 SQS 대기열에 대한 액세스 권한 부여**
1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.
1. 왼쪽의 탐색 창에서 **역할**을 선택합니다.
1. **역할 생성**을 선택합니다.
1. **신뢰할 수 있는 엔터티 선택(Select trusted entity)**에서 **AWS 서비스( service)**를 선택합니다.
1. 사용 사례를 보려면 **다른 AWS 서비스의 사용 사례(Use cases for other services)**에서 **EC2 Auto Scaling**을 선택한 다음 **EC2 Auto Scaling 알림 액세스(EC2 Auto Scaling Notification Access)**를 선택합니다.
1. **다음(Next)**을 두 번 선택하여 **이름 지정, 검토 및 생성(Name, review, and create)** 페이지로 이동합니다.
1. **역할 이름(Role name)**에 역할의 이름(예: **my-notification-role**)을 입력하고 **역할 생성(Create role)**을 선택합니다.
1. **역할** 페이지에서 방금 만든 역할을 선택하여 **요약** 페이지를 엽니다. 역할 **ARN**을 기록해 둡니다. 예를 들어 `arn:aws:iam::123456789012:role/my-notification-role`입니다. 이 이름은 수명 주기 후크를 생성하는데 필요합니다.
1. 이 지침을 따른 후에는 다음 단계 [수명 주기 후크 추가(AWS CLI)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-aws-cli)로 계속 진행합니다.
### 에 AWS Lambda 직접 알림 라우팅
수명 주기 작업이 발생할 때 Lambda 함수를 알림 대상으로 사용할 수 있습니다.
**알림을 로 AWS Lambda 직접 라우팅하려면**
1. Lambda 콘솔에서 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 원하는 Lambda 함수를 선택합니다.
새 Lambda 함수를 생성하려면 [Lambda 함수 생성](lambda-custom-termination-policy.md#lambda-custom-termination-policy-create-function)을 참조하세요.
1. **구성** 탭을 선택한 다음 **권한**을 선택합니다.
1. **Resource-based policy(리소스 기반 정책)**까지 스크롤한 다음 **Add permissions(권한 추가)**를 선택합니다. 리소스 기반 정책은 정책에 지정된 보안 주체에 함수를 호출하는 권한을 부여하는 데 사용됩니다. 이 경우, 보안 주체는 Auto Scaling 그룹과 연결된 [Amazon EC2 Auto Scaling 서비스 연결 역할](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html)입니다.
1. **Policy statement(정책 설명)** 섹션에서 권한을 구성합니다.
1. **AWS 계정**를 선택합니다.
1. **Principal(보안 주체)**에 호출 서비스 연결 역할의 ARN 입력합니다(예: **arn:aws:iam:::role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling**).
1. **Action(작업)**으로**lambda:InvokeFunction**을 선택합니다.
1. **Statement ID(설명 ID)**에 고유한 설명 ID를 입력합니다(예: **AllowInvokeByAutoScaling**).
1. **저장**을 선택합니다.
1. 이 지침을 따른 후에는 다음 단계 [수명 주기 후크 추가(AWS CLI)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-aws-cli)로 계속 진행합니다.
### 알림 메시지의 예
이 섹션에서는 Amazon SNS, Amazon SQS 및에 대한 알림의 예를 제공합니다 AWS Lambda.
인스턴스가 대기 상태인 동안 Amazon SNS, Amazon SQS 및 AWS Lambda 알림 대상에 메시지가 게시됩니다.
메시지에 포함되는 정보는 다음과 같습니다.
+ `Origin` - EC2 인스턴스의 출처입니다.
+ `Destination` - EC2 인스턴스가 전송되는 위치입니다.
+ `LifecycleActionToken` - 수명 주기 작업 토큰
+ `AccountId` - AWS 계정 ID입니다.
+ `AutoScalingGroupName` — Auto Scaling 그룹의 이름입니다.
+ `LifecycleHookName` - 수명 주기 후크 이름
+ `EC2InstanceId` — EC2 인스턴스의 ID입니다.
+ `LifecycleTransition` - 수명 주기 후크 유형
+ `NotificationMetadata` - 알림 메타데이터
다음은 알림 메시지의 예입니다.
```
Service: AWS Auto Scaling
Time: 2021-01-19T00:36:26.533Z
RequestId: 18b2ec17-3e9b-4c15-8024-ff2e8ce8786a
Origin: EC2
Destination: AutoScalingGroup
LifecycleActionToken: 71514b9d-6a40-4b26-8523-05e7ee35fa40
AccountId: 123456789012
AutoScalingGroupName: my-asg
LifecycleHookName: my-hook
EC2InstanceId: i-0598c7d356eba48d7
LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING
NotificationMetadata: hook message metadata
```
#### 테스트 알림 메시지의 예
수명 주기 후크를 처음 추가하면 알림 대상에게 테스트 알림 메시지가 전송됩니다. 다음은 테스트 알림 메시지의 예입니다.
```
Service: AWS Auto Scaling
Time: 2021-01-19T00:35:52.359Z
RequestId: 18b2ec17-3e9b-4c15-8024-ff2e8ce8786a
Event: autoscaling:TEST_NOTIFICATION
AccountId: 123456789012
AutoScalingGroupName: my-asg
AutoScalingGroupARN: arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:042cba90-ad2f-431c-9b4d-6d9055bcc9fb:autoScalingGroupName/my-asg
```
**참고**
Amazon EC2 Auto Scaling에서 EventBridge로 전달되는 이벤트의 예는 [Amazon EC2 Auto Scaling 이벤트 참조](ec2-auto-scaling-event-reference.md)를 참조하세요.
# 인스턴스 수명 주기 정책을 사용하여 인스턴스 보존 제어
인스턴스 수명 주기 정책은 종료 수명 주기 작업이 중단될 때 Amazon EC2 Auto Scaling 종료에 대한 보호를 제공합니다. 수명 주기 후크와 달리 인스턴스 수명 주기 정책은 정상적인 종료 절차가 성공적으로 완료되지 않을 때 인스턴스가 유지 상태로 전환되도록 설계되었습니다.
## 인스턴스 수명 주기 정책을 사용해야 하는 경우
애플리케이션의 정상적인 종료가 선택 사항이 아니지만 필수적이고 실패한 종료에 수동 개입이 필요한 경우 인스턴스 수명 주기 정책을 사용합니다. 일반적인 사용 사례는 다음과 같습니다.
+ 종료 전에 데이터 지속성을 완료해야 하는 상태 저장 애플리케이션입니다.
+ 최대 수명 주기 후크 제한 시간인 48시간을 초과할 수 있는 연장 드레이닝 기간이 필요한 애플리케이션.
+ 정리가 실패하거나 불완전한 민감한 데이터를 처리하는 워크로드는 데이터 손실 또는 손상을 초래할 수 있습니다.
+ 갑작스러운 종료로 인해 가용성에 영향을 미치는 미션 크리티컬 서비스입니다.
인스턴스 종료를 정상적으로 처리하는 방법에 대한 자세한 내용은 섹션을 참조하세요[인스턴스 종료를 원활하게 처리할 수 있도록 애플리케이션 설계](gracefully-handle-instance-termination.md).
## 인스턴스 수명 주기 정책이 종료 수명 주기 후크와 작동하는 방식
인스턴스 수명 주기 정책은 대체가 아닌 종료 수명 주기 후크와 함께 작동합니다. 이 프로세스는 여러 단계를 따릅니다.
1. **종료 수명 주기 작업이 실행됩니다.** Amazon EC2 Auto Scaling이 종료할 인스턴스를 선택하면 종료 수명 주기 후크가 호출되고 인스턴스가 `Terminating:Wait` 상태로 전환되어 종료 수명 주기 작업 실행을 시작합니다.
1. **정상적인 종료 시도가 시작됩니다.** 인스턴스에서 실행되거나 컨트롤 플레인을 통해 실행되는 애플리케이션은 종료 수명 주기 작업 알림을 수신하고 연결 드레이닝, 진행 중인 작업 완료 또는 데이터 전송과 같은 정상적인 종료 절차를 시작합니다.
1. **종료 수명 주기 작업이 완료되었습니다.** 종료 수명 주기 작업은 `CONTINUE` 또는 `ABANDON` 결과로 완료될 수 있습니다.
1. **인스턴스 수명 주기 정책은 상황을 평가합니다.** 인스턴스 수명 주기 정책을 구성하지 않으면 종료 수명 주기 작업이 완료되어`ABANDON`도 인스턴스가 즉시 종료됩니다. 에 인스턴스를 유지하도록 구성된 인스턴스 수명 주기 정책을 사용하면 종료 수명 주기 작업이 `ABANDON` 결과로 완료된 경우 `TerminateHookAbandon`인스턴스가 보존 상태로 전환됩니다.
1. **보관된 인스턴스는 수동 작업을 기다립니다.** 보존 상태의 인스턴스에는 표준 Amazon EC2 요금이 계속 발생합니다. 이러한 인스턴스는 Auto Scaling 그룹의 원하는 용량에 포함되지 않으므로 Auto Scaling은 대체 인스턴스를 시작하여 원하는 크기를 유지합니다. 인스턴스 새로 고침 및 최대 인스턴스 수명과 같은 Auto Scaling 기능도 보관된 인스턴스를 무시합니다. 이렇게 하면 인스턴스를 수동으로 종료하기 전에 수동으로 정리 절차를 완료하거나, 데이터를 복구하거나, 자동 종료가 실패한 이유를 조사할 수 있습니다.
1. **수동 종료가 발생합니다.** 보관된 인스턴스에서 필요한 작업을 완료한 후에는 `TerminateInstanceInAutoScalingGroup` API를 호출하여 인스턴스를 종료해야 합니다.
# 인스턴스 보존 구성
종료 수명 주기 작업이 실패할 때 인스턴스를 유지하도록 Amazon EC2 Auto Scaling 그룹을 설정합니다.
Auto Scaling 그룹에서 인스턴스 수명 주기 정책을 사용하려면 종료 수명 주기 후크도 구성해야 합니다. 인스턴스 수명 주기 정책을 구성하지만 종료 수명 주기 후크가 없는 경우 정책은 적용되지 않습니다. 인스턴스 수명 주기 정책은 종료 수명 주기 작업이 중단된 경우에만 적용되며 `CONTINUE` 결과로 성공적으로 완료된 경우에는 적용되지 않습니다.
인스턴스 수명 주기 정책은 보존 트리거를 사용하여 인스턴스를 보존할 시기를 결정합니다. `TerminateHookAbandon` 트리거는 여러 시나리오에서 보존을 유발합니다.
+ `ABANDON` 결과와 함께 [ CompleteLifecycleAction ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html) API를 명시적으로 호출하는 경우.
+ 하트비트를 수신하지 않고 하트비트 제한 `ABANDON` 시간에 도달하여 기본 결과가 있는 종료 수명 주기 작업이 시간 초과되는 경우.
+ 기본 결과가 인 종료 수명 주기 작업에서 전역 제한 시간에 도달하면 `ABANDON`48시간 또는 하트비트 제한 시간의 100배 중 더 작은 값입니다.
------
#### [ Console ]
**인스턴스 보존을 구성하려면**
1. Amazon EC2 Auto Scaling 콘솔 열기
1. Auto Scaling 그룹 생성(인스턴스 수명 주기 정책은 기본적으로 종료)
1. Auto Scaling 그룹 세부 정보 페이지로 이동하여 **인스턴스 관리** 탭을 선택합니다.
1. 수명 **주기 후크에 대한 인스턴스 수명 주기 정책**에서 **보관**을 선택합니다.
1. 다음을 사용하여 종료 수명 주기 후크를 생성합니다.
+ **인스턴스 종료**로 설정된 수명 주기 전환
+ 기본 결과를 **포기**로 설정
------
#### [ AWS CLI ]
**인스턴스 보존을 구성하려면**
인스턴스 수명 주기 정책과 함께 [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 사용합니다.
```
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-asg \
--launch-template LaunchTemplateName=my-template,Version='$Latest' \
--min-size 1 \
--max-size 3 \
--desired-capacity 2 \
--vpc-zone-identifier subnet-12345678 \
--instance-lifecycle-policy file://lifecycle-policy.json
```
lifecycle-policy.json의 내용:
```
{
"RetentionTriggers": {
"TerminateHookAbandon": "retain"
}
}
```
**종료 수명 주기 후크를 추가하려면**
[put-lifecycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html) 명령을 사용합니다.
```
aws autoscaling put-lifecycle-hook \
--lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
--default-result ABANDON \
--heartbeat-timeout 300
```
------
# 보관된 인스턴스 관리
보존 상태로 이동된 Amazon EC2 인스턴스를 모니터링하고 제어합니다. CloudWatch 지표를 사용하여 보관된 인스턴스를 추적한 다음 사용자 지정 작업을 완료한 후 보관된 인스턴스를 수동으로 종료합니다.
보관된 인스턴스는 Amazon EC2 Auto Scaling 그룹의 원하는 용량에 포함되지 않습니다. 인스턴스가 보존 상태로 전환되면 Auto Scaling은 대체 인스턴스를 시작하여 원하는 용량을 유지합니다. 예를 들어 Auto Scaling 그룹의 용량이 10이라고 가정해 보겠습니다. 인스턴스가 `Terminating:Retained` 상태가 되면 Auto Scaling은 대체 인스턴스를 시작하여 원하는 용량인 10을 유지합니다. 이제 총 11개의 인스턴스가 실행 중입니다. 활성 그룹에 10개, 보관된 인스턴스 1개입니다. 보관된 인스턴스를 수동으로 종료할 때까지 11개 인스턴스 모두에 표준 Amazon EC2 요금이 적용됩니다.
## 보관된 인스턴스의 인스턴스 수명 주기 상태
인스턴스 수명 주기 정책이 사용될 때 인스턴스가 수명 주기 상태를 통해 전환하는 방법을 이해합니다. 인스턴스는 정상 종료부터 보존, 최종 종료까지 특정 경로를 따릅니다.
*보존이 트리거되면 인스턴스는 다음 상태를 통해 전환됩니다.*
1. `Terminating` - 정상 종료 시작
1. `Terminating:Wait` - 수명 주기 후크 실행
1. `Terminating:Proceed` - 수명 주기 작업 마무리(성공 또는 실패 여부)
1. `Terminating:Retained` - 후크 실패, 수동 개입을 위해 인스턴스 유지
웜 풀 인스턴스는 시나리오에 따라 다른 수명 주기 상태 경로를 사용합니다.
*웜 풀로 다시 확장되는 인스턴스:*
1. `Warmed:Pending` - 일반적인 웜 풀 전환 시작
1. `Warmed:Pending:Wait` - 수명 주기 후크 실행
1. `Warmed:Pending:Proceed` - 수명 주기 작업 마무리(성공 또는 실패 여부)
1. `Warmed:Pending:Retained` - 후크 실패, 수동 개입을 위해 인스턴스 유지
*웜 풀에서 종료되는 인스턴스:*
1. `Warmed:Terminating` - 정상 종료 시작
1. `Warmed:Terminating:Wait` - 수명 주기 후크 실행
1. `Warmed:Terminating:Proceed` - 수명 주기 작업 마무리(성공 또는 실패 여부)
1. `Warmed:Terminating:Retained` - 후크 실패, 수동 개입을 위해 인스턴스 유지
## 보관된 인스턴스 모니터링
보관된 Amazon EC2 인스턴스는 비용이 발생하고 수동 개입이 필요하므로 모니터링하는 것이 중요합니다. Amazon EC2 Auto Scaling은 보관된 인스턴스를 추적하기 위한 여러 CloudWatch 지표를 제공합니다.
그룹 지표를 활성화하여 보존된 인스턴스를 추적합니다.
```
aws autoscaling enable-metrics-collection \
--auto-scaling-group-name my-asg \
--metrics GroupTerminatingRetainedInstances
```
사용 가능한 지표는 다음과 같습니다.
+ `GroupTerminatingRetainedInstances`는 `Terminating:Retained` 상태의 인스턴스 수를 보여줍니다.
+ `GroupTerminatingRetainedCapacity`는 `Terminating:Retained` 상태의 인스턴스로 표시되는 용량 단위를 보여줍니다.
+ `WarmPoolTerminatingRetainedCapacity`는 웜 풀에서 종료되는 보관된 인스턴스를 추적합니다.
+ `WarmPoolPendingRetainedCapacity`는 웜 풀로 반환되는 보관된 인스턴스를 추적합니다.
Amazon EC2 Auto Scaling 그룹의 조정 활동을 확인하여 인스턴스가 유지되는 이유를 파악할 수도 있습니다. 수명 주기 후크 실패를 나타내는 `StatusCode: Cancelled` 및 상태 이유 메시지를 사용하여 종료 활동을 찾습니다.
```
aws autoscaling describe-scaling-activities \
--auto-scaling-group-name my-asg
```
인스턴스가 보존 상태로 전환되면 알림을 받으려면 이러한 지표에 CloudWatch 경보를 생성하는 것이 좋습니다. 이렇게 하면 비용 영향을 추적하고 수동 개입이 필요한 인스턴스를 정리하는 것을 잊지 않을 수 있습니다.
## 보관된 인스턴스 종료
사용자 지정 작업을 완료한 후 [ TerminateInstanceInAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html) API를 호출하여 보관된 인스턴스를 종료합니다.
```
aws autoscaling terminate-instance-in-auto-scaling-group \
--instance-id i-1234567890abcdef0 \
--no-should-decrement-desired-capacity
```
# 인스턴스 메타데이터를 통해 대상 수명 주기 상태 검색
사용자가 시작하는 각 Auto Scaling 인스턴스는 여러 수명 주기 상태를 거칩니다. 특정 수명 주기 상태 전환 시에 행동하는 인스턴스 내로부터 사용자 지정 조치를 호출하려면 인스턴스 메타데이터를 통해 대상 수명 주기 상태를 검색해야 합니다.
예컨대, 인스턴스가 해지되기 전에 인스턴스에서 일부 코드를 실행하기 위해 인스턴스 내부에서 인스턴스 해지를 감지하는 메커니즘이 필요할 수 있습니다. 인스턴스에서 직접 인스턴스의 수명 주기 상태를 폴링하는 코드를 작성하여 이 작업을 수행할 수 있습니다. 그런 다음 Auto Scaling 그룹에 수명 주기 후크를 추가하여 코드에서 계속하라는 **complete-lifecycle-action** 명령을 보낼 때까지 인스턴스를 계속 실행할 수 있습니다.
Auto Scaling 인스턴스 수명 주기에는 `InService`와 `Terminated`의 두 가지 기본 건전 상태 및 `Detached`와 `Standby`의 두 가지 부 건전 상태가 있습니다. 웜 풀을 사용하는 경우, 수명 주기에는 `Warmed:Hibernated`, `Warmed:Running`, `Warmed:Stopped` 및 `Warmed:Terminated`의 네 가지 추가 건전 상태가 있습니다.
인스턴스가 이전 건전 상태 중 하나로 전환될 준비가 되면 Amazon EC2 Auto Scaling은 `autoscaling/target-lifecycle-state` 인스턴스 메타데이터 항목의 값을 업데이트합니다. 인스턴스 내에서 대상 수명 주기 상태를 가져오려면 인스턴스 메타데이터 서비스를 사용하여 인스턴스 메타데이터에서 해당 상태를 검색해야 합니다.
**참고**
*인스턴스 메타데이터*는 애플리케이션에서 인스턴스 정보를 쿼리하는 데 사용할 수 있는 Amazon EC2 인스턴스 관련 데이터입니다. *인스턴스 메타데이터 서비스*는 지역 코드가 인스턴스 메타데이터에 액세스하기 위해 사용하는 온인스턴스 구성 요소입니다. 지역 코드에는 인스턴스에서 실행 중인 사용자 데이터 스크립트 또는 애플리케이션이 포함될 수 있습니다.
지역 코드는 인스턴스 메타데이터 서비스 버전 1(IMDSv1) 또는 인스턴스 메타데이터 서비스 버전 2(IMDSv2)의 두 가지 방법 중 하나를 사용하여 실행 중인 인스턴스에서 인스턴스 메타데이터에 액세스할 수 있습니다. IMDSv2는 세션 지향 요청을 사용하며 인스턴스 메타데이터에 액세스하기 위해 사용될 수 있는 여러 유형의 취약성을 완화합니다. 이 두 가지 방법에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [IMDSv2 사용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)을 참조하세요.
------
#### [ IMDSv2 ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/autoscaling/target-lifecycle-state
```
------
#### [ IMDSv1 ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/autoscaling/target-lifecycle-state
```
------
다음은 예제 출력입니다.
```
InService
```
대상 수명 주기 상태는 인스턴스가 전환 중인 대상 상태입니다. 현재 수명 주기 상태는 인스턴스의 현재 상태입니다. 이런 상태는 수명 주기 작업이 완료되고 인스턴스가 대상 수명 주기 상태로 전환을 끝마친 후에도 동일할 수 있습니다. 인스턴스 메타데이터에서 인스턴스의 현재 수명 주기 상태를 검색할 수 없습니다.
Amazon EC2 Auto Scaling은 2022년 3월 10일에 대상 수명 주기 상태를 생성하기 시작했습니다. 인스턴스가 이 날짜 이후에 대상 수명 주기 상태 중 하나로 전환되면 인스턴스 메타데이터에 대상 수명 주기 상태 항목이 있습니다. 그렇지 않은 경우, 해당 항목이 없고 HTTP 404 오류가 발생합니다.
인스턴스 메타데이터 검색에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 메타데이터 검색](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html)을 참조하세요.
대상 수명 주기 상태를 사용하는 사용자 데이터 스크립트에서 사용자 지정 작업을 통해 수명 주기 후크를 만드는 방법을 설명하는 자습서는 [자습서: 데이터 스크립트와 인스턴스 메타데이터를 사용하여 수명 주기 상태 검색](tutorial-lifecycle-hook-instance-metadata.md) 섹션을 참조하세요.
**중요**
가능한 한 빨리 사용자 지정 작업을 호출할 수 있도록 로컬 코드에서 IMDS를 자주 폴링하고 오류가 발생하면 다시 시도해야 합니다.
# Auto Scaling 그룹에 수명 주기 후크 추가
Auto Scaling 인스턴스를 대기 상태로 전환하고 해당 인스턴스에 대해 사용자 지정 작업을 수행하려는 경우, Auto Scaling 그룹에 수명 주기 후크를 추가할 수 있습니다. 사용자 지정 작업은 인스턴스가 시작될 때 또는 해지되기 전에 수행됩니다. 수명 주기 작업을 완료할 때까지 혹은 제한 시간이 끝날 때까지 인스턴스는 대기 상태로 유지됩니다.
에서 Auto Scaling 그룹을 생성한 후 최대 총 50개의 수명 주기 후크까지 수명 주기 후크를 하나 이상 추가할 AWS Management Console수 있습니다. AWS CLI CloudFormation또는 SDK를 사용하여 오토 스케일링을 생성할 때 Auto Scaling에 수명 주기 후크를 추가할 수도 있습니다.
기본적으로 콘솔에 수명 주기 후크를 추가하면 Amazon EC2 Auto Scaling이 Amazon EventBridge EventBridge로 수명 주기 이벤트 알림을 전송합니다. 권장되는 모범 사례는 EventBridge 또는 사용자 데이터 스크립트를 사용하는 것입니다. 이 주제의 예제와 같이 알림을 Amazon SNS, Amazon SQS로 직접 보내는 수명 주기 후크를 생성 AWS Lambda 하거나 [put-lifecycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html) 명령을 사용할 수 있습니다.
**Topics**
+ [수명 주기 후크 추가(콘솔)](#adding-lifecycle-hooks-console)
+ [수명 주기 후크 추가(AWS CLI)](#adding-lifecycle-hooks-aws-cli)
## 수명 주기 후크 추가(콘솔)
Auto Scaling 그룹에 수명 주기 후크를 추가하려면 다음 단계를 따르십시오. 스케일 아웃(인스턴스 시작) 및 스케일 인(인스턴스 해지)를 위한 수명 주기 후크를 생성하려면 두 개의 개별 후크를 생성해야 합니다.
시작하기 전에 필요한 대로 [Auto Scaling 그룹에 대한 수명 주기 후크 추가 준비](prepare-for-lifecycle-notifications.md)의 설명에 따라 사용자 지정 작업을 설정하십시오.
**스케일 아웃을 위한 수명 주기 후크를 추가**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다. 페이지 하단에 분할 창이 열립니다.
1. **인스턴스 관리** 탭의 **Lifecycle hooks**(수명 주기 후크)에서 **Create lifecycle hook**(수명 주기 후크 생성)을 선택합니다.
1. 스케일 아웃(인스턴스 실행)을 위한 수명 주기 후크를 정의하려면 다음을 수행하세요.
1. **Lifecycle hook name**(수명 주기 후크 이름)에 수명 주기 후크의 이름을 지정합니다.
1. **Lifecycle transition(수명 주기 전환)**에서 **Instance launch(인스턴스 시작)**를 선택합니다.
1. **하트비트 제한 시간**에서는 스케일 아웃할 때 훅이 시간 초과되기 전에 인스턴스가 대기 상태로 유지되는 시간을 지정하십시오. 범위는 `30` \$1 `7200`초입니다. 제한 시간을 길게 설정하면 사용자 지정 작업을 완료하기 위한 시간을 더 많이 제공합니다. 그러면, 제한 시간이 해지되기 전에 작업을 마칠 경우, 인스턴스가 다음 상태로 진행하도록 [complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html) 명령을 보냅니다.
1. **기본 결과(Default result)**에서 수명 주기 후크 제한 시간이 경과하거나 예기치 못한 오류가 발생할 때 수행할 작업을 지정합니다. **계속** 또는 **포기**를 선택할 수 있습니다.
+ **계속**을 선택하면 Auto Scaling 그룹이 다른 수명 주기 후크를 진행한 다음 인스턴스를 서비스할 수 있습니다.
+ **포기**를 선택하면 Auto Scaling 그룹이 잔여 작업을 중단하고 인스턴스를 즉각 해지합니다.
1. (옵션) **알림 메타데이터**에 Amazon EC2 Auto Scaling이 알림 대상에 메시지를 전송할 때 포함할 다른 정보를 지정합니다.
1. **생성(Create)**을 선택합니다.
**스케일 인을 위한 수명 주기 후크 추가**
1. 스케일 아웃을 위한 **수명 주기 후크**를 생성한 후 중단한 부분부터 계속하려면 수명 주기 후크 만들기를 선택합니다.
1. 스케일 인(인스턴스가 해지되거나 웜 풀로 돌아가는 것)을 위한 수명 주기 후크를 정의하려면 다음과 같이 하세요.
1. **Lifecycle hook name**(수명 주기 후크 이름)에 수명 주기 후크의 이름을 지정합니다.
1. **Lifecycle transition**(수명 주기 전환)에서 **Instance terminate**(인스턴스 해지)를 선택합니다.
1. **하트비트 제한 시간**에서는 스케일 아웃할 때 훅이 시간 초과되기 전에 인스턴스가 대기 상태로 유지되는 시간을 지정하십시오. CloudWatch에서 EC2 로그를 가져오는 것과 같은 최종 작업을 수행하는 데 필요한 시간에 따라 `30` - `120`초의 짧은 타임아웃 기간을 사용하는 것이 좋습니다.
1. **Default result**(기본 결과)에 제한 시간이 경과하거나 예기치 못한 오류가 발생할 때 Auto Scaling 그룹에서 수행하는 작업을 지정합니다. **ABANDON**(중단) 및 **CONTINUE**(계속) 둘 다 인스턴스를 해지할 수 있습니다.
+ **CONTINUE**(계속)을 선택하면 해지 전에 Auto Scaling 그룹이 남아 있는 모든 작업(예: 다른 수명 주기 후크)을 진행할 수 있습니다.
+ **포기**를 선택하면 Auto Scaling 그룹이 인스턴스를 즉각 해지합니다.
1. (옵션) **알림 메타데이터**에 Amazon EC2 Auto Scaling이 알림 대상에 메시지를 전송할 때 포함할 추가 정보를 지정합니다.
1. **생성(Create)**을 선택합니다.
## 수명 주기 후크 추가(AWS CLI)
[put-lifecycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html) 명령을 사용하여 수명 주기 후크를 생성하고 업데이트합니다.
스케일 아웃 시 작업을 수행하려면 다음 명령을 사용합니다.
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_LAUNCHING
```
축소 시 작업을 수행하려면 대신 다음 명령을 사용합니다.
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING
```
Amazon SNS 또는 Amazon SQS를 사용하여 알림을 수신하려면 `--notification-target-arn`과 `--role-arn` 옵션을 추가합니다. 를 사용하여 알림을 받으려면를 AWS Lambda추가합니다`--notification-target-arn`.
다음 예에서는 `my-sns-topic`이라는 SNS 주제를 알림 대상으로 지정하는 수명 주기 후크를 생성합니다.
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
--notification-target-arn arn:aws:sns:region:123456789012:my-sns-topic \
--role-arn arn:aws:iam::123456789012:role/my-notification-role
```
이 주제는 다음 키-값 쌍에 해당하는 테스트 알림을 보냅니다.
```
"Event": "autoscaling:TEST_NOTIFICATION"
```
기본적으로 [put-lifecycle ycleycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html) 명령은 `3600`초(1시간)의 하트비트 제한 시간으로 수명 주기 후크를 생성합니다.
기존 수명 주기 후크에 대한 하트비트 제한 시간을 변경하려면 다음 예에 따라 `--heartbeat-timeout` 옵션을 추가합니다.
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg --heartbeat-timeout 120
```
인스턴스가 이미 대기 상태에 있는 경우, [record-lifecycle-action-heartbeat](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/record-lifecycle-action-heartbeat.html) CLI 명령을 통해 하트비트를 기록하여 수명 주기 후크가 제한 시간을 초과하지 않도록 할 수 있습니다. 그러면 수명 주기 후크를 만들 때 지정한 제한 시간 값을 기준으로 제한 시간이 늘어납니다. 제한 시간이 해지되기 전에 작업을 마칠 경우, [complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html) 명령을 전송하여 인스턴스가 다음 상태로 진행하도록 할 수 있습니다. 자세한 내용과 예제는 [Auto Scaling 그룹에서 수명 주기 작업 완료](completing-lifecycle-hooks.md) 섹션을 참조하세요.
# Auto Scaling 그룹에서 수명 주기 작업 완료
Auto Scaling 그룹에서 수명 주기 이벤트에 응답할 때 인스턴스를 대기 상태로 설정하고 이벤트 알림을 전송합니다. 인스턴스가 대기 상태에 있는 동안 사용자 지정 작업을 수행할 수 있습니다.
타임아웃 기간이 만료되기 전에 완료하면 결과가 `CONTINUE`인 수명 주기 작업을 완료하는 데 도움이 됩니다. 수명 주기 작업을 완료하지 않으면 시간 초과 기간이 해지된 후 수명 주기 후크가 **기본 결과**에 지정된 상태로 전환됩니다.
**Topics**
+ [수명 주기 작업 완료(수동)](#completing-lifecycle-hooks-aws-cli)
+ [수명 주기 작업 완료(자동)](#completing-lifecycle-hooks-automatic)
## 수명 주기 작업 완료(수동)
다음 절차는 명령행 인터페이스용이며 콘솔에서는 지원되지 않습니다. 인스턴스 ID 또는 Auto Scaling 그룹의 이름과 같이 교체해야 하는 정보는 기울임꼴으로 표시됩니다.
**수명 주기 작업 완료(AWS CLI)**
1. (옵션) 사용자 지정 작업을 완료할 시간이 더 필요한 경우, [record-lifecycle-action-heartbeat](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/record-lifecycle-action-heartbeat.html) 명령을 사용하여 제한 시간을 재시작하고 인스턴스를 대기 상태로 유지합니다. 예컨대, 제한 시간이 1시간이고 이 명령을 30분 후에 호출한 경우, 인스턴스는 추가 1시간 동안 대기 상태로 유지됩니다(총 90분).
다음 명령과 같이 [알림](prepare-for-lifecycle-notifications.md#notification-message-example)에서 받은 수명 주기 작업 토큰을 지정할 수 있습니다.
```
aws autoscaling record-lifecycle-action-heartbeat --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg --lifecycle-action-token bcd2f1b8-9a78-44d3-8a7a-4dd07d7cf635
```
또는 다음 명령과 같이 [알림](prepare-for-lifecycle-notifications.md#notification-message-example)과 함께 받은 인스턴스의 ID를 지정할 수 있습니다.
```
aws autoscaling record-lifecycle-action-heartbeat --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg --instance-id i-1a2b3c4d
```
1. 제한 시간이 끝나기 전에 사용자 정의 작업을 완료하는 경우, [complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html) 명령을 사용하여 Auto Scaling 그룹에서 인스턴스를 계속 시작하거나 해지할 수 있습니다. 다음 명령과 같이 수명 주기 작업 토큰을 지정할 수 있습니다.
```
aws autoscaling complete-lifecycle-action --lifecycle-action-result CONTINUE \
--lifecycle-hook-name my-launch-hook --auto-scaling-group-name my-asg \
--lifecycle-action-token bcd2f1b8-9a78-44d3-8a7a-4dd07d7cf635
```
또는 다음 명령과 같이 인스턴스의 ID를 지정할 수도 있습니다.
```
aws autoscaling complete-lifecycle-action --lifecycle-action-result CONTINUE \
--instance-id i-1a2b3c4d --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg
```
## 수명 주기 작업 완료(자동)
인스턴스를 시작 후에 구성하는 사용자 데이터 스크립트가 있는 경우, 수명 주기 작업을 수동으로 완료할 필요가 없습니다. 스크립트에 [complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html) 명령을 추가할 수 있습니다. 스크립트는 인스턴스 메타데이터에서 인스턴스 ID를 검색하고 부트스트랩 스크립트가 성공적으로 완료되면 Amazon EC2 Auto Scaling에 알릴 수 있습니다.
아직 없는 경우, 인스턴스 메타데이터에서 인스턴스의 인스턴스 ID를 검색하도록 스크립트를 업데이트합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 메타데이터 검색](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html)을 참조하세요.
Lambda를 사용하는 경우, 함수 코드에 대한 콜백을 설정하여 사용자 지정 작업이 성공할 경우, 인스턴스의 수명 주기가 진행되도록 할 수도 있습니다. 자세한 내용은 [자습서: Lambda 함수를 호출하는 수명 주기 후크 구성](tutorial-lifecycle-hook-lambda.md) 단원을 참조하십시오.
# 자습서: 데이터 스크립트와 인스턴스 메타데이터를 사용하여 수명 주기 상태 검색
수명 주기 후크에 대한 사용자 지정 작업을 생성하는 일반적인 방법은 Amazon EC2 Auto Scaling에서 Amazon EventBridge 등의 다른 서비스로 전송하는 알림을 사용하는 것입니다. 그러나 대신 사용자 데이터 스크립트를 사용하여 인스턴스를 구성하고 수명 주기 작업을 완료하는 코드를 인스턴스 자체로 이동하면 추가 인프라를 생성하지 않아도 됩니다.
다음 자습서에서는 사용자 데이터 스크립트 및 인스턴스 메타데이터 사용을 시작하는 방법을 보여줍니다. 그룹에서 인스턴스의 [대상 수명 주기 상태](retrieving-target-lifecycle-state-through-imds.md)를 읽고 시작 프로세스를 계속하기 위해 인스턴스 수명 주기의 특정 단계에서 콜백 작업을 수행하는 사용자 데이터 스크립트를 사용하여 기본 Auto Scaling 그룹 구성을 생성합니다.
다음 그림은 사용자 데이터 스크립트를 사용하여 사용자 지정 작업을 수행할 때 스케일 아웃 이벤트의 흐름을 요약합니다. 인스턴스가 시작되면 제한 시간을 초과하거나 Amazon EC2 Auto Scaling에서 계속 진행하라는 신호를 수신하여 수명 주기 후크가 완료될 때까지 인스턴스의 수명 주기가 일시 중지됩니다.
![\[사용자 데이터 스크립트를 사용하여 사용자 지정 작업을 수행할 때 스케일 아웃 이벤트의 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/lifecycle-hook-user-data-script.png)
**Topics**
+ [1단계: 수명 주기 작업을 완료할 권한이 있는 IAM 역할 생성](#instance-metadata-create-iam-role)
+ [2단계: 시작 템플릿 생성 및 IAM 역할과 사용자 데이터 스크립트 추가](#instance-metadata-create-hello-world-function)
+ [3단계: Auto Scaling 그룹 생성](#instance-metadata-create-auto-scaling-group)
+ [4단계: 수명 주기 후크 추가](#instance-metadata-add-lifecycle-hook)
+ [5단계: 기능 테스트 및 확인](#instance-metadata-testing-hook)
+ [6단계: 정리](#instance-metadata-lifecycle-hooks-tutorial-cleanup)
+ [관련 리소스](#instance-metadata-lifecycle-hooks-tutorial-related-resources)
## 1단계: 수명 주기 작업을 완료할 권한이 있는 IAM 역할 생성
AWS CLI 또는 AWS SDK를 사용하여 콜백을 전송하여 수명 주기 작업을 완료하는 경우 수명 주기 작업을 완료할 권한이 있는 IAM 역할을 사용해야 합니다.
**정책 생성**
1. IAM 콘솔에서 [정책(Policies)](https://console.aws.amazon.com/iam/home?#/policies) 페이지를 열고 **Create policy(정책 생성)**를 선택합니다.
1. **JSON** 탭을 선택합니다.
1. **정책 문서(Policy Document)** 상자에서 다음 정책 문서를 복사하여 상자에 붙여넣습니다. **샘플 텍스트(sample text)**를 생성하려는 Auto Scaling 그룹의 계정 번호 및 이름(**TestAutoScalingEvent-group**)으로 교체합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:CompleteLifecycleAction"
],
"Resource": "arn:aws:autoscaling:*:123456789012:autoScalingGroup:*:autoScalingGroupName/TestAutoScalingEvent-group"
}
]
}
```
------
1. **다음**을 선택합니다.
1. **정책 이름(Policy name)**에 **TestAutoScalingEvent-policy**을 입력합니다. **Create policy(정책 생성)**를 선택합니다.
정책 생성을 완료하면 정책을 사용하는 역할을 생성할 수 있습니다.
**역할 생성**
1. 왼쪽의 탐색 창에서 **역할**을 선택합니다.
1. **역할 생성**을 선택합니다.
1. **신뢰할 수 있는 엔터티 선택(Select trusted entity)**에서 **AWS 서비스( service)**를 선택합니다.
1. 사용 사례에 대해 **EC2**를 선택하고 **다음(Next)**을 선택합니다.
1. **권한 추가(Add permissions)**에서 생성한 정책(**TestAutoScalingEvent-policy**)을 선택합니다. 그리고 **다음**을 선택합니다.
1. **이름 지정, 검토 및 생성(Name, review, and create)** 페이지에서 **역할 이름(Role name)**에 **TestAutoScalingEvent-role**을 입력하고 **역할 생성(Create role)**을 선택합니다.
## 2단계: 시작 템플릿 생성 및 IAM 역할과 사용자 데이터 스크립트 추가
Auto Scaling 그룹에서 사용할 시작 템플릿을 생성합니다. 생성한 IAM 역할과 제공된 샘플 사용자 데이터 스크립트를 추가합니다.
**시작 템플릿 생성**
1. Amazon EC2 콘솔의 [시작 템플릿](https://console.aws.amazon.com/ec2/v2/#LaunchTemplates) 페이지를 엽니다.
1. **Create launch template**(시작 템플릿 생성)을 선택합니다.
1. **Launch template name**(시작 템플릿 이름)에 **TestAutoScalingEvent-template**을 입력합니다.
1. **Auto Scaling guidance**(Auto Scaling 지침)에서 확인란을 선택합니다.
1. **애플리케이션 및 OS 이미지(Amazon Machine Image)(Application and OS Images (Amazon Machine Image))**에서 **빠른 시작(Quick Start)** 목록의 Amazon Linux 2(HVM), SSD 볼륨 유형, 64비트(x86)를 선택합니다.
1. **인스턴스 유형(Instance type)**에서 Amazon EC2 인스턴스 유형을 선택합니다(예: “t2.micro”).
1. **Advanced details(고급 세부 정보)**에서 섹션을 스케일 아웃하여 필드를 표시합니다.
1. **IAM 인스턴스 프로파일(IAM instance profile)**에서 IAM 역할의 IAM 인스턴스 프로필 이름을 선택합니다(**TestAutoScalingEvent-role**). 인스턴스 프로파일은 인스턴스가 시작될 때 Amazon EC2가 인스턴스에 IAM 역할을 전달하도록 허용하는 IAM 역할을 위한 컨테이너입니다.
IAM 콘솔을 사용하여 IAM 역할을 생성한 경우, 콘솔에서 해당 역할과 동일한 이름으로 인스턴스 프로파일을 자동으로 생성합니다.
1. **사용자 데이터(User data)**에서 필드에 다음 사용자 데이터 스크립트를 붙여넣습니다. 의 샘플 텍스트를 생성하려는 Auto Scaling 그룹의 `group_name` 이름으로 바꾸고 Auto Scaling 그룹에서 사용할 `region`로 바꿉 AWS 리전 니다.
```
#!/bin/bash
function token {
echo "X-aws-ec2-metadata-token: $(curl -X PUT 'http://169.254.169.254/latest/api/token' -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600')"
}
function get_target_state {
echo $(curl -H "$(token)" -s http://169.254.169.254/latest/meta-data/autoscaling/target-lifecycle-state)
}
function get_instance_id {
echo $(curl -H "$(token)" -s http://169.254.169.254/latest/meta-data/instance-id)
}
function complete_lifecycle_action {
instance_id=$(get_instance_id)
group_name='TestAutoScalingEvent-group'
region='us-west-2'
echo $instance_id
echo $region
echo $(aws autoscaling complete-lifecycle-action \
--lifecycle-hook-name TestAutoScalingEvent-hook \
--auto-scaling-group-name $group_name \
--lifecycle-action-result CONTINUE \
--instance-id $instance_id \
--region $region)
}
function main {
while true
do
target_state=$(get_target_state)
if [ \"$target_state\" = \"InService\" ]; then
# Change hostname
export new_hostname="${group_name}-$instance_id"
hostname $new_hostname
# Send callback
complete_lifecycle_action
break
fi
echo $target_state
sleep 5
done
}
main
```
이 간단한 사용자 데이터 스크립트는 다음을 수행하십시오:
+ 인스턴스 메타데이터를 호출하여 인스턴스 메타데이터에서 대상 수명 주기 상태 및 인스턴스 ID를 검색합니다.
+ 대상 수명 주기 상태가 `InService`로 변경될 때까지 해당 상태를 반복적으로 검색합니다.
+ 대상 수명 주기 상태가 `InService`인 경우, 인스턴스의 호스트 이름을 Auto Scaling 그룹 명칭이 앞에 추가된 인스턴스 ID로 변경합니다.
+ **complete-lifecycle-action** CLI 명령을 호출하여 콜백을 보내 EC2 시작 프로세스를 `CONTINUE`하도록 Amazon EC2 Auto Scaling에 신호를 보냅니다.
1. **Create launch template**(시작 템플릿 생성)을 선택합니다.
1. 확인 페이지에서 **Create Auto Scaling group**(Auto Scaling 그룹 생성)을 선택합니다.
**참고**
사용자 데이터 스크립트를 개발하기 위한 참조로 사용할 수 있는 다른 예는 Amazon EC2 Auto Scaling에 대한 [GitHub 리포지토리](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)를 참조하세요.
## 3단계: Auto Scaling 그룹 생성
시작 템플릿을 생성한 후 Auto Scaling 그룹을 생성합니다.
**Auto Scaling 그룹 생성**
1. **시작 템플릿 또는 구성 선택** 페이지에서 **Auto Scaling 그룹 명칭(Auto Scaling group name)**에 Auto Scaling 그룹의 이름(**TestAutoScalingEvent-group**)을 입력합니다.
1. **다음(Next)**을 선택하여 **인스턴스 시작 옵션 선택** 페이지로 이동합니다.
1. **네트워크(Network)**에서 VPC를 선택합니다.
1. **가용 영역 및 서브넷(Availability Zones and subnets)**에 대해 하나 이상의 가용 영역에서 서브넷을 하나 이상 선택합니다.
1. **인스턴스 유형 요건(Instance type requirements)** 섹션에서 기본 설정을 사용하여 이 단계를 단순화합니다. (시작 템플릿을 재정의하지 마세요.) 이 자습서에서는 시작 템플릿에 지정된 인스턴스 유형을 사용하여 하나의 온디맨드 인스턴스만 시작합니다.
1. 화면 맨 아래에 있는 **검토로 건너뛰기(Skip to review)**를 선택합니다.
1. **검토** 페이지에서 Auto Scaling 그룹 세부 정보를 검토한 다음 **Auto Scaling 그룹 생성(Create Auto Scaling group)**을 선택합니다.
## 4단계: 수명 주기 후크 추가
수명 주기 작업이 완료될 때까지 인스턴스를 대기 상태로 유지하도록 수명 주기 후크를 추가합니다.
**수명 주기 후크 추가**
1. Amazon EC2 콘솔에서 [Auto Scaling 그룹](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) 페이지를 엽니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다. 페이지 하단에 분할 창이 열립니다.
1. 창 하단 **Instance management(인스턴스 관리)** 탭의 **Lifecycle hooks(수명 주기 후크)**에서 **Create lifecycle hook(수명 주기 후크 생성)**를 선택합니다.
1. 스케일 아웃(인스턴스 실행)을 위한 수명 주기 후크를 정의하려면 다음을 수행하세요.
1. **Lifecycle hook name(수명 주기 후크 이름)**으로 **TestAutoScalingEvent-hook**를 입력합니다.
1. **Lifecycle transition(수명 주기 전환)**에서 **Instance launch(인스턴스 시작)**를 선택합니다.
1. **하트비트 시간 제한(Heartbeat timeout)**에 사용자 데이터 스크립트에서 콜백을 기다리는 시간(초)으로 **300**을 입력합니다.
1. **Default result(기본 결과)**로 **ABANDON(포기)**을 선택합니다. 사용자 데이터 스크립트에서 콜백을 수신하지 않고 후크가 시간 초과되는 경우, Auto Scaling 그룹이 새 인스턴스를 해지합니다.
1. (옵션) **알림 메타데이터(Notification metadata)**를 비워 둡니다.
1. **생성(Create)**을 선택합니다.
## 5단계: 기능 테스트 및 확인
기능을 테스트하기 위해 Auto Scaling 그룹의 원하는 용량을 1씩 늘리면서 Auto Scaling 그룹을 업데이트합니다. 인스턴스가 시작된 직후 사용자 데이터 스크립트가 실행되고 인스턴스의 대상 수명 주기 상태를 확인하기 시작합니다. 대상 수명 주기 상태가 `InService`이면 스크립트가 호스트 이름을 변경하고 콜백 작업을 보냅니다. 완료하는 데 보통 몇 초 정도 소요됩니다.
**Auto Scaling 그룹 크기 증가**
1. Amazon EC2 콘솔에서 [Auto Scaling 그룹](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) 페이지를 엽니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다. 위쪽 창의 맨 위 행을 계속 보면서 아래쪽 창에서 세부 정보를 확인합니다.
1. 아래 창의 **Details(세부 정보)** 탭에서 **Group details(그룹 세부 정보)**, **Edit(편집)**을 선택합니다.
1. **원하는 용량**에 대해 현재 값을 1씩 늘립니다.
1. **Update(업데이트)**를 선택합니다. 인스턴스가 시작되는 동안 위쪽 창의 **Status(상태)** 열에 *Updating capacity(용량 업데이트 중)* 상태가 표시됩니다.
원하는 용량을 늘린 후 인스턴스가 성공적으로 시작되었는지 그리고 크기 조정 활동의 설명에서 해지되지 않았는지 확인할 수 있습니다.
**조정 활동을 보려면**
1. **Auto Scaling groups(Auto Scaling 그룹)** 페이지로 돌아가 그룹을 선택합니다.
1. **Activity(활동)** 탭의 **Activity history(활동 기록)**에 있는 **Status(상태)** 열에 Auto Scaling 그룹이 성공적으로 인스턴스를 시작했는지가 표시됩니다.
1. 사용자 데이터 스크립트가 실패하면 제한 시간이 경과한 후 상태가 `Canceled`이고 상태 메시지가 `Instance failed to complete user's Lifecycle Action: Lifecycle Action with token e85eb647-4fe0-4909-b341-a6c42EXAMPLE was abandoned: Lifecycle Action Completed with ABANDON Result`인 크기 조정 활동이 표시됩니다.
## 6단계: 정리
이 자습서를 진행하기 위해 생성한 리소스로 작업을 마쳤으면 다음 단계에 따라 해당 리소스를 삭제합니다.
**수명 주기 후크 삭제**
1. Amazon EC2 콘솔에서 [Auto Scaling 그룹 페이지](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups)를 엽니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
1. **Instance management(인스턴스 관리)** 탭의 **Lifecycle hooks(수명 주기 후크)**에서 수명 주기 후크(`TestAutoScalingEvent-hook`)를 선택합니다.
1. **작업**, **삭제**를 선택합니다.
1. **삭제**를 다시 선택하여 확인합니다.
**시작 템플릿을 삭제하려면**
1. Amazon EC2 콘솔의 [시작 템플릿](https://console.aws.amazon.com/ec2/v2/#LaunchTemplates) 페이지를 엽니다.
1. 시작 템플릿(`TestAutoScalingEvent-template`)을 선택한 다음 **작업(Actions)**, **템플릿 삭제(Delete template)**를 선택합니다.
1. 확인 메시지가 표시되면 **Delete**를 입력하여 지정된 시작 템플릿 삭제를 확인한 다음 **Delete**(삭제)를 선택합니다.
Auto Scaling 그룹 예를 이용한 작업을 마쳤으면 해당 그룹을 삭제합니다. 생성한 IAM 역할 및 권한 정책도 삭제할 수 있습니다.
**Auto Scaling 그룹을 삭제하려면**
1. Amazon EC2 콘솔에서 [Auto Scaling 그룹 페이지](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups)를 엽니다.
1. Auto Scaling 그룹(`TestAutoScalingEvent-group`) 옆에 있는 확인란을 선택하고 **삭제(Delete)**를 선택합니다.
1. 확인 메시지가 표시되면 **delete**를 입력하여 지정된 Auto Scaling 그룹 삭제를 확인한 다음 **Delete**(삭제)를 선택합니다.
**Name**(이름) 열의 로딩 아이콘은 Auto Scaling 그룹이 삭제 중임을 나타납니다. 인스턴스를 해지하고 그룹을 삭제하는 데 몇 분 정도 걸립니다.
**IAM 역할 삭제**
1. IAM 콘솔에서 [역할 페이지](https://console.aws.amazon.com/iam/home?#/roles)를 엽니다.
1. 함수의 역할(`TestAutoScalingEvent-role`)을 선택합니다.
1. **삭제**를 선택합니다.
1. 확인 메시지가 나타나면 역할의 이름을 입력한 다음 **Delete**(삭제)를 선택합니다.
**IAM 정책 삭제**
1. IAM 콘솔에서 [정책 페이지](https://console.aws.amazon.com/iam/home?#/policies)를 엽니다.
1. 생성한 정책을 선택합니다(`TestAutoScalingEvent-policy`).
1. **작업**, **삭제**를 선택합니다.
1. 확인 메시지가 나타나면 정책의 이름을 입력한 다음 **Delete**(삭제)를 선택합니다.
## 관련 리소스
인스턴스 메타데이터에서 사용 가능한 데이터에 근거하여 인스턴스에서 작업을 호출하는 코드를 개발할 때 다음과 같은 관련 주제가 도움이 될 수 있습니다.
+ [인스턴스 메타데이터를 통해 대상 수명 주기 상태 검색](retrieving-target-lifecycle-state-through-imds.md). 이 섹션에서는 인스턴스 해지와 같은 다른 사용 사례의 수명 주기 상태에 대해 설명합니다.
+ [수명 주기 후크 추가(콘솔)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-console). 이 절차에서는 스케일 아웃(인스턴스 시작) 및 스케일 인(인스턴스 해지 또는 웜 풀로의 복귀)을 위해 수명 주기 후크를 추가하는 방법을 설명합니다.
+ *Amazon EC2 사용 설명서*의 [인스턴스 메타데이터 카테고리](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-categories). 이 주제에는 EC2 인스턴스에서 작업을 호출하는 데 사용할 수 있는 인스턴스 메타데이터의 모든 카테고리가 열거되어 있습니다.
Amazon EventBridge를 사용하여 Auto Scaling 그룹의 인스턴스에서 발생하는 이벤트에 근거하여 Lambda 함수를 호출하는 규칙을 만드는 방법을 보여주는 자습서은 [자습서: Lambda 함수를 호출하는 수명 주기 후크 구성](tutorial-lifecycle-hook-lambda.md)을 참조하세요.
# 자습서: Lambda 함수를 호출하는 수명 주기 후크 구성
이 연습에서는 일치 시 AWS Lambda 함수를 규칙 대상으로 호출하는 필터 패턴이 포함된 Amazon EventBridge 규칙을 생성합니다. 사용할 필터 패턴과 샘플 함수 코드가 제공됩니다.
모든 설정을 올바르게 구성하면 이 자습서를 마친 후 인스턴스가 시작될 때 Lambda 함수가 사용자 지정 작업을 수행합니다. 사용자 지정 작업은 Lambda 함수와 연결된 CloudWatch Logs 로그 스트림에 이벤트를 로깅하기만 합니다.
또한 Lambda 함수는 이 작업에 성공할 경우, 인스턴스의 수명 주기가 진행되도록 하지만 작업에 실패하면 인스턴스가 시작을 중단하고 해지할 수 있도록 하는 콜백을 수행합니다.
다음 그림은 Lambda 함수를 사용하여 사용자 지정 작업을 수행할 때 스케일 아웃 이벤트의 흐름을 요약합니다. 인스턴스가 시작되면 제한 시간을 초과하거나 Amazon EC2 Auto Scaling에서 계속 진행하라는 신호를 수신하여 수명 주기 후크가 완료될 때까지 인스턴스의 수명 주기가 일시 중지됩니다.
![\[Lambda 함수를 사용하여 사용자 지정 작업을 수행할 때 스케일 아웃 이벤트의 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/lifecycle-hook-lambda-function.png)
**참고**
사용 사례별로 아래 단계에 따라 EventBridge 규칙을 생성하여 수명 주기 후크를 구성할 수 있습니다. 또는 Lambda 함수를 사용하여 EventBridge 규칙을 생성하지 않고도 수명 주기 후크를 직접 구성할 수 있습니다.
**Topics**
+ [사전 조건](#lambda-hello-world-tutorial-prerequisites)
+ [1단계: 수명 주기 작업을 완료할 권한이 있는 IAM 역할 생성](#lambda-create-iam-role)
+ [2단계: Lambda 함수 생성](#lambda-create-hello-world-function)
+ [3단계: EventBridge 규칙 생성](#lambda-create-rule)
+ [4단계: 수명 주기 후크 추가](#lambda-add-lifecycle-hook)
+ [5단계: 이벤트 테스트 및 확인](#lambda-testing-hook-notifications)
+ [6단계: 정리](#lambda-lifecycle-hooks-tutorial-cleanup)
+ [관련 리소스](#lambda-lifecycle-hooks-tutorial-related-resources)
## 사전 조건
Auto Scaling 그룹이 없는 경우, 이 자습서를 시작하기 전에 Auto Scaling 그룹을 생성합니다. Auto Scaling 그룹을 생성하려면 Amazon EC2 콘솔에서 [Auto Scaling 그룹](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) 페이지를 열고 **Auto Scaling 그룹 생성**을 선택합니다.
## 1단계: 수명 주기 작업을 완료할 권한이 있는 IAM 역할 생성
Lambda 함수를 생성하기 전에 먼저 집행 역할과 사용 권한 정책을 만들어 Lambda가 수명 주기 후크를 완료할 수 있도록 해야 합니다.
**정책 생성**
1. IAM 콘솔에서 [정책(Policies)](https://console.aws.amazon.com/iam/home?#/policies) 페이지를 열고 **Create policy(정책 생성)**를 선택합니다.
1. **JSON** 탭을 선택합니다.
1. **Policy Document(정책 문서)** 상자에 다음 정책 문서를 붙여 넣고 **기울임꼴**로 표시된 텍스트를 계정 번호 및 Auto Scaling 그룹의 이름으로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:CompleteLifecycleAction"
],
"Resource": "arn:aws:autoscaling:*:123456789012:autoScalingGroup:*:autoScalingGroupName/my-asg"
}
]
}
```
------
1. **다음**을 선택합니다.
1. **정책 이름(Policy name)**에 **LogAutoScalingEvent-policy**을 입력합니다. **Create policy(정책 생성)**를 선택합니다.
정책 생성을 완료하면 정책을 사용하는 역할을 생성할 수 있습니다.
**역할 생성**
1. 왼쪽의 탐색 창에서 **역할**을 선택합니다.
1. **역할 생성**을 선택합니다.
1. **신뢰할 수 있는 엔터티 선택(Select trusted entity)**에서 **AWS 서비스( service)**를 선택합니다.
1. 사용 사례에 대해 **Lambda**를 선택하고 **다음(Next)**을 선택합니다.
1. **권한 추가(Add permissions)**에서 생성한 정책(**LogAutoScalingEvent-policy**)과 이름이 **AWSLambdaBasicExecutionRole**인 정책을 선택합니다. 그리고 **다음**을 선택합니다.
**참고**
**AWSLambdaBasicExecutionRole** 정책은 함수가 CloudWatch Logs에 로그를 쓰는 데 필요한 권한을 가집니다.
1. **이름 지정, 검토 및 생성(Name, review, and create)** 페이지에서 **역할 이름(Role name)**에 **LogAutoScalingEvent-role**을 입력하고 **역할 생성(Create role)**을 선택합니다.
## 2단계: Lambda 함수 생성
이벤트의 대상 역할을 할 Lambda 함수를 생성합니다. Node.js 형식으로 작성된 샘플 Lambda 함수는 Amazon EC2 Auto Scaling에서 일치하는 이벤트가 발생할 때 EventBridge에서 호출합니다.
**Lambda 함수를 생성하려면**
1. Lambda 콘솔에서 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. **Create function(함수 생성)**과 **Author from scratch(새로 작성)**를 차례로 선택합니다.
1. **기본 정보(Basic information)**에서 **함수 이름(Function name)**에 **LogAutoScalingEvent**을 입력합니다.
1. **런타임**에서 **Node.js 18.x**를 선택합니다.
1. 아래로 스크롤하여 **집행 역할 기본값 변경**을 선택하고 **집행 역할**에서 **기존 역할 사용**을 선택합니다.
1. **Existing role(기존 역할)**로 **LogAutoScalingEvent-role**을 선택합니다.
1. 나머지는 기본값을 그대로 사용합니다.
1. **Create function(함수 생성)**을 선택합니다. 함수의 코드 및 구성으로 돌아갑니다.
1. 콘솔에 `LogAutoScalingEvent` 함수를 여전히 열어둔 상태에서 편집기의 **코드 소스**에서 다음 샘플 코드를 index.mjs 파일에 붙여 넣습니다.
```
import { AutoScalingClient, CompleteLifecycleActionCommand } from "@aws-sdk/client-auto-scaling";
export const handler = async(event) => {
console.log('LogAutoScalingEvent');
console.log('Received event:', JSON.stringify(event, null, 2));
var autoscaling = new AutoScalingClient({ region: event.region });
var eventDetail = event.detail;
var params = {
AutoScalingGroupName: eventDetail['AutoScalingGroupName'], /* required */
LifecycleActionResult: 'CONTINUE', /* required */
LifecycleHookName: eventDetail['LifecycleHookName'], /* required */
InstanceId: eventDetail['EC2InstanceId'],
LifecycleActionToken: eventDetail['LifecycleActionToken']
};
var response;
const command = new CompleteLifecycleActionCommand(params);
try {
var data = await autoscaling.send(command);
console.log(data); // successful response
response = {
statusCode: 200,
body: JSON.stringify('SUCCESS'),
};
} catch (err) {
console.log(err, err.stack); // an error occurred
response = {
statusCode: 500,
body: JSON.stringify('ERROR'),
};
}
return response;
};
```
이 코드는 이벤트를 간단하게 로깅하므로 자습서를 마치면 이 Lambda 함수와 연결된 CloudWatch Logs 로그 스트림에 이벤트가 나타나는 것을 볼 수 있습니다.
1. **Deploy(배치)**를 선택합니다.
## 3단계: EventBridge 규칙 생성
Lambda 함수를 실행하는 EventBridge 규칙을 생성합니다. EventBridge 사용에 대한 자세한 설명은 [EventBridge를 사용하여 Auto Scaling 이벤트 처리](automating-ec2-auto-scaling-with-eventbridge.md) 섹션을 참조하세요.
**콘솔을 사용하여 규칙 생성**
1. [EventBridge 콘솔](https://console.aws.amazon.com/events/)을 엽니다.
1. 탐색 창에서 **규칙**을 선택합니다.
1. **규칙 생성**을 선택합니다.
1. **규칙 세부 정보 정의(Define rule detail)**에 대해 다음을 수행하십시오:
1. **이름**에 **LogAutoScalingEvent-rule**를 입력합니다.
1. **이벤트 버스**에서 **기본값**을 선택합니다. 계정 AWS 서비스 의가 이벤트를 생성하면 항상 계정의 기본 이벤트 버스로 이동합니다.
1. **규칙 유형(Rule type)**에서 **이벤트 패턴이 있는 규칙(Rule with an event pattern)**을 생성합니다.
1. **다음**을 선택합니다.
1. **이벤트 패턴 빌드(Build event pattern)**에서 다음을 수행합니다.
1. **이벤트 소스(Event source)**에서 **AWS 이벤트 또는 EventBridge 파트너 이벤트( events or EventBridge partner events)**를 선택합니다.
1. **이벤트 패턴**까지 아래로 스크롤하여 다음을 수행하십시오:
1.
1. **이벤트 소스(Event source)**에서 **AWS 서비스**를 선택합니다.
1. **AWS 서비스**에서 **Auto Scaling**을 선택합니다.
1. **이벤트 유형**에서 **인스턴스 시작 및 해지**를 선택합니다.
1. 기본적으로 규칙은 모든 스케일 인 또는 스케일 아웃 이벤트와 일치합니다. 스케일 아웃 이벤트가 있고 인스턴스가 수명 주기 후크로 인해 대기 상태가 될 때 알려주는 규칙을 생성하려면 **특정 인스턴스 이벤트(Specific instance event(s))**를 선택하고 **EC2 인스턴스 시작 수명 주기 작업(EC2 Instance-launch Lifecycle Action)**을 선택합니다.
1. 기본적으로 규칙은 지역의 모든 Auto Scaling 그룹과 일치합니다. 규칙을 특정 Auto Scaling 그룹과 매칭시키려면 **특정 그룹 명칭**을 선택하고 해당 그룹을 선택합니다.
1. **다음**을 선택합니다.
1. **대상 선택(Select target(s))**에서 다음을 수행하십시오:
1. **대상 유형(Target types**)에서 **AWS 서비스**를 선택합니다.
1. **대상 선택(Select a target)**에서 **Lambda 함수(Lambda function)**를 선택합니다.
1. **함수(Function)**에서 **LogAutoScalingEvent**를 선택합니다.
1. **다음**을 두 번 선택합니다
1. **검토 및 생성** 페이지에서 **규칙 생성**을 선택합니다.
## 4단계: 수명 주기 후크 추가
이 섹션에서는 Lambda가 시작 시 인스턴스에 대해 함수를 실행할 수 있도록 수명 주기 후크를 추가합니다.
**수명 주기 후크 추가**
1. Amazon EC2 콘솔에서 [Auto Scaling 그룹](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) 페이지를 엽니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다. 페이지 하단에 분할 창이 열립니다.
1. 창 하단 **Instance management(인스턴스 관리)** 탭의 **Lifecycle hooks(수명 주기 후크)**에서 **Create lifecycle hook(수명 주기 후크 생성)**를 선택합니다.
1. 스케일 아웃(인스턴스 실행)을 위한 수명 주기 후크를 정의하려면 다음을 수행하세요.
1. **Lifecycle hook name(수명 주기 후크 이름)**으로 **LogAutoScalingEvent-hook**를 입력합니다.
1. **Lifecycle transition(수명 주기 전환)**에서 **Instance launch(인스턴스 시작)**를 선택합니다.
1. **Heartbeat timeout(하트비트 시간 제한)**에 Lambda 함수에서 콜백을 기다리는 시간(초)으로 **300**을 입력합니다.
1. **Default result(기본 결과)**로 **ABANDON(포기)**을 선택합니다. 즉, Lambda 함수에서 콜백을 수신하지 않았는데 후크가 시간 초과되면 Auto Scaling 그룹이 새 인스턴스를 해지합니다.
1. (옵션)**Notification metadata(알림 메타데이터)**를 비워 둡니다. EventBridge로 전달하는 이벤트 데이터에는 Lambda 함수를 호출하는 데 필요한 모든 정보가 들어 있습니다.
1. **생성(Create)**을 선택합니다.
## 5단계: 이벤트 테스트 및 확인
이벤트를 테스트하기 위해 Auto Scaling 그룹의 원하는 용량을 1씩 늘리면서 Auto Scaling 그룹을 업데이트합니다. 원하는 용량을 늘린 후 몇 초 내에 Lambda 함수가 호출됩니다.
**Auto Scaling 그룹 크기 증가**
1. Amazon EC2 콘솔에서 [Auto Scaling 그룹](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) 페이지를 엽니다.
1. Auto Scaling 그룹 옆의 확인란을 선택하여 아래쪽 창에 세부 정보를 표시하고 위쪽 창의 맨 위 행을 계속 표시합니다.
1. 아래 창의 **Details(세부 정보)** 탭에서 **Group details(그룹 세부 정보)**, **Edit(편집)**을 선택합니다.
1. **원하는 용량**에 대해 현재 값을 1씩 늘립니다.
1. **Update(업데이트)**를 선택합니다. 인스턴스가 시작되는 동안 위쪽 창의 **Status(상태)** 열에 *Updating capacity(용량 업데이트 중)* 상태가 표시됩니다.
원하는 용량을 늘린 후 Lambda 함수가 호출되었는지 확인할 수 있습니다.
**Lambda 함수에서 출력 확인**
1. CloudWatch 콘솔에서 [로그 그룹 페이지](https://console.aws.amazon.com/cloudwatch/home#logs:)를 엽니다.
1. Lambda 함수에 대한 로그 그룹 명칭을 선택합니다(`/aws/lambda/LogAutoScalingEvent`).
1. 로그 스트림 이름을 선택하여 수명 주기 작업에 대해 해당 함수에서 제공하는 데이터를 확인합니다.
다음으로, 크기 조정 활동의 열거을 통해 인스턴스가 성공적으로 시작되었는지 확인할 수 있습니다.
**조정 활동을 보려면**
1. **Auto Scaling groups(Auto Scaling 그룹)** 페이지로 돌아가 그룹을 선택합니다.
1. **Activity(활동)** 탭의 **Activity history(활동 기록)**에 있는 **Status(상태)** 열에 Auto Scaling 그룹이 성공적으로 인스턴스를 시작했는지가 표시됩니다.
+ 작업에 성공하면 크기 조정 활동의 상태가 “성공”으로 표시됩니다.
+ 실패하면 몇 분이 지난 후 “Cancelled(취소됨)” 상태의 크기 조정 활동이 표시되고 “Instance failed to complete user's Lifecycle Action: Lifecycle Action with token e85eb647-4fe0-4909-b341-a6c42EXAMPLE was abandoned: Lifecycle Action Completed with ABANDON Result(인스턴스가 사용자의 수명 주기 작업을 완료하지 못함: 토큰이 e85eb647-4fe0-4909-b341-a6c42EXAMPLE인 수명 주기 작업이 중단됨: 수명 주기 작업 완료되었으나 결과가 중단임)”이라는 상태 메시지가 표시됩니다.
**Auto Scaling 그룹 크기 감소**
이 테스트를 위해 시작한 추가 인스턴스가 필요하지 않으면 **Details(세부 정보)** 탭을 열고 **원하는 용량**을 1씩 줄일 수 있습니다.
## 6단계: 정리
이 자습서 전용으로 생성한 리소스 사용을 마친 경우, 다음 단계에 따라 리소스를 삭제합니다.
**수명 주기 후크 삭제**
1. Amazon EC2 콘솔에서 [Auto Scaling 그룹 페이지](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups)를 엽니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
1. **Instance management(인스턴스 관리)** 탭의 **Lifecycle hooks(수명 주기 후크)**에서 수명 주기 후크(`LogAutoScalingEvent-hook`)를 선택합니다.
1. **작업**, **삭제**를 선택합니다.
1. 확인하려면 **Delete(삭제)**를 다시 선택합니다.
**Amazon EventBridge 규칙 삭제**
1. Amazon EventBridge 콘솔에서 [Rules(규칙)](https://console.aws.amazon.com/events/home?#/rules) 페이지를 엽니다.
1. **Event bus(이벤트 버스)**에서 규칙과 연결된 이벤트 버스(`Default`)를 선택합니다.
1. 규칙(`LogAutoScalingEvent-rule`) 옆에 있는 확인란을 선택합니다.
1. **삭제**를 선택합니다.
1. 확인 메시지가 나타나면 규칙의 이름을 입력한 다음 **Delete**(삭제)를 선택합니다.
예 함수를 사용한 작업이 완료되면 해당 함수를 삭제하세요. 함수의 로그를 저장하는 로그 그룹과 생성한 집행 역할 및 정책 권한을 삭제할 수도 있습니다.
**Lambda 함수 삭제**
1. Lambda 콘솔에서 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 함수(`LogAutoScalingEvent`)를 선택합니다.
1. **작업**, **삭제**를 선택합니다.
1. 확인 메시지가 표시되면 **delete**를 입력하여 지정된 함수 삭제를 확인한 다음 **Delete**(삭제)를 선택합니다.
**로그 그룹 삭제**
1. CloudWatch 콘솔에서 [로그 그룹 페이지](https://console.aws.amazon.com/cloudwatch/home#logs:)를 엽니다.
1. 함수의 로그 그룹(`/aws/lambda/LogAutoScalingEvent`)을 선택합니다.
1. **작업(Actions)**, **로그 그룹 삭제(Delete log group(s))**를 선택합니다.
1. **로그 그룹 삭제(Delete log group(s))** 대화 상자에서 **삭제(Delete)**를 선택합니다.
**집행 역할 삭제**
1. IAM 콘솔에서 [역할 페이지](https://console.aws.amazon.com/iam/home?#/roles)를 엽니다.
1. 함수의 역할(`LogAutoScalingEvent-role`)을 선택합니다.
1. **삭제**를 선택합니다.
1. 확인 메시지가 나타나면 역할의 이름을 입력한 다음 **Delete**(삭제)를 선택합니다.
**IAM 정책 삭제**
1. IAM 콘솔에서 [정책 페이지](https://console.aws.amazon.com/iam/home?#/policies)를 엽니다.
1. 생성한 정책을 선택합니다(`LogAutoScalingEvent-policy`).
1. **작업**, **삭제**를 선택합니다.
1. 확인 메시지가 나타나면 정책의 이름을 입력한 다음 **Delete**(삭제)를 선택합니다.
## 관련 리소스
Auto Scaling 그룹의 인스턴스에서 발생하는 이벤트에 근거하여 EventBridge 규칙을 만들 때 다음과 같은 관련 주제가 도움이 될 수 있습니다.
+ [EventBridge를 사용하여 Auto Scaling 이벤트 처리](automating-ec2-auto-scaling-with-eventbridge.md). 이 섹션에서는 스케일 인을 위한 이벤트를 포함하여 다른 사용 사례에 대한 이벤트의 예를 보여줍니다.
+ [수명 주기 후크 추가(콘솔)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-console). 이 절차에서는 스케일 아웃(인스턴스 시작) 및 스케일 인(인스턴스 해지 또는 웜 풀로의 복귀)을 위해 수명 주기 후크를 추가하는 방법을 설명합니다.
인스턴스 메타데이터 서비스(IMDS)를 사용하여 인스턴스 자체 내에서 작업을 호출하는 방법을 보여주는 자습서은 [자습서: 데이터 스크립트와 인스턴스 메타데이터를 사용하여 수명 주기 상태 검색](tutorial-lifecycle-hook-instance-metadata.md)을 참조하세요.
# 웜 풀을 사용하여 부팅 시간이 긴 애플리케이션의 지연 시간 단축
웜 풀을 사용하면 예컨대, 인스턴스가 많은 양의 데이터를 디스크에 기록해야 하기 때문에 부팅 시간이 매우 길어지는 애플리케이션의 지연 시간을 줄일 수 있습니다. 웜 풀을 사용하면 애플리케이션 성능 향상을 위해 대기 시간을 관리하려고 Auto Scaling 그룹을 과도하게 프로비저닝할 필요가 없습니다. 자세한 설명은 블로그 게시물 [EC2 Auto Scaling 웜 풀로 애플리케이션의 크기를 더 빠르게 조정(Scaling your applications faster with EC2 Auto Scaling Warm Pools)](https://aws.amazon.com/blogs/compute/scaling-your-applications-faster-with-ec2-auto-scaling-warm-pools/)를 참조하세요.
**중요**
필요하지 않은 경우, 웜 풀을 생성하면 불필요한 비용이 발생할 수 있습니다. 첫 번째 부팅 시간으로 인해 애플리케이션에서 눈에 띄는 대기 시간 문제가 발생하지 않는 경우, 웜 풀을 사용할 필요가 없습니다.
**Topics**
+ [핵심 개념](#warm-pool-core-concepts)
+ [사전 조건](#warm-pool-prerequisites)
+ [웜 풀에서 인스턴스 업데이트](#update-warm-pool)
+ [관련 리소스](#warm-pools-related-resources)
+ [제한 사항](#warm-pools-limitations)
+ [수명 주기 후크 사용](warm-pool-instance-lifecycle.md)
+ [Auto Scaling 그룹을 위한 웜 풀 생성](create-warm-pool.md)
+ [건전성 체크의 상태 보기](warm-pools-health-checks-monitor-view-status.md)
+ [AWS CLI 웜 풀 작업 예제](examples-warm-pools-aws-cli.md)
## 핵심 개념
시작하기 전에 다음과 같은 핵심 개념을 익힙니다.
**웜 풀**
웜 풀은 Auto Scaling 그룹과 함께 있는 미리 초기화된 EC2 인스턴스의 풀입니다. 애플리케이션을 스케일 아웃해야 할 때마다 Auto Scaling 그룹은 원하는 새 용량을 충족하기 위해 웜 풀을 사용할 수 있습니다. 이렇게 하면 인스턴스가 애플리케이션 트래픽 제공을 신속하게 시작하여 스케일 아웃 이벤트에 대한 응답 속도를 높일 수 있습니다. 인스턴스가 웜 풀을 벗어나면 그룹의 원하는 용량에 가산됩니다. 이를 *웜 스타트*라고 합니다.
인스턴스가 웜 풀에 있는 동안 조정 정책은 `InService` 상태에 있는 인스턴스의 지표 값이 대상 추적 조정 정책의 대상 사용률과 동일한 조정 정책의 경보 상한 임계값보다 큰 경우에만 스케일 아웃됩니다.
**웜 풀 크기**
기본적으로 웜 풀의 크기는 Auto Scaling 그룹의 최대 용량과 원하는 용량 간의 차이로 계산됩니다. 예컨대, Auto Scaling 그룹의 원하는 용량이 6이고 최대 용량이 10인 경우, 웜 풀을 처음 설정하고 풀을 초기화할 때 웜 풀의 크기는 4가 됩니다.
웜 풀의 최대 용량을 개별적으로 지정하려면 사용자 지정 사양(`MaxGroupPreparedCapacity`) 옵션을 사용하고 그룹의 현재 용량보다 큰 사용자 지정 값을 설정합니다. 사용자 지정 값을 제공하는 경우 웜 풀의 크기는 사용자 지정 값과 그룹의 현재 원하는 용량 간의 차이로 계산됩니다. 예를 들어 Auto Scaling 그룹의 원하는 용량이 6, 최대 용량이 20, 사용자 지정 값이 8인 경우 웜 풀을 처음 설정하고 풀을 초기화할 때 웜 풀의 크기는 2가 됩니다.
대규모 Auto Scaling 그룹으로 작업할 때 웜 풀 사용에 따르는 비용 혜택을 관리하기 위해 사용자 지정 사양(`MaxGroupPreparedCapacity`) 옵션을 사용해야 할 수 있습니다. 예컨대, 최대 용량이 1,500(비상 트래픽 급증 시 추가 용량 제공용)이고, 100개의 인스턴스로 구성된 웜 풀이 있는, 인스턴스 1,000개의 Auto Scaling 그룹은 웜 풀 내에 향후 사용을 위해 예약된 인스턴스 500개를 유지하는 것보다 목표를 더 잘 달성할 수 있습니다.
**최소 웜 풀 크기**
최소 크기 설정(`MinSize`)을 사용해 웜 풀에 유지할 최소 인스턴스 수를 정적으로 설정하는 것이 좋습니다. 기본적으로 설정된 최소 크기는 없습니다. 이 `MinSize` 설정은 Auto Scaling 그룹의 원하는 용량이 `MaxGroupPreparedCapacity`보다 높더라도 최소 인스턴스 수가 웜 풀에 유지되도록 `MaxGroupPreparedCapacity`를 지정할 때 유용합니다.
**웜 풀 인스턴스 상태**
웜 풀의 인스턴스를 `Stopped`, `Running`, `Hibernated`의 세 가지 상태 중 하나로 유지할 수 있습니다. `Stopped` 상태로 인스턴스를 유지하는 것이 비용을 최소화하는 효과적인 방법입니다. 중지된 인스턴스의 경우, 사용하는 볼륨과 인스턴스에 연결된 탄력적 IP 주소에 대해서만 요금을 지불합니다.
또는 인스턴스를 `Hibernated` 상태로 유지하여 메모리 콘텐츠(RAM)를 삭제하지 않고 인스턴스를 중지할 수 있습니다. 인스턴스가 최대 절전 모드로 전환되면 운영 체제에 RAM 콘텐츠를 Amazon EBS 루트 볼륨에 저장하라는 신호가 전달됩니다. 인스턴스를 다시 시작하면 루트 볼륨이 이전 상태로 복원되고 RAM의 콘텐츠가 다시 로드됩니다. 인스턴스가 최대 절전 모드에 있는 동안에는 RAM 콘텐츠용 스토리지를 포함한 EBS 볼륨과 인스턴스에 연결된 탄력적 IP 주소에 대해서만 요금을 지불하면 됩니다.
웜 풀 내에서 인스턴스를 `Running` 상태로 유지하는 것도 가능하지만 불필요한 요금이 발생하지 않도록 하는 것이 좋습니다. 인스턴스가 중지되거나 최대 절전 모드로 전환되면 인스턴스 자체의 비용이 절감됩니다. 인스턴스가 실행 중일 때만 해당 인스턴스에 대한 요금을 지불합니다.
**수명 주기 후크**
[수명 주기 후크](warm-pool-instance-lifecycle.md)를 사용하여 인스턴스를 대기 상태에 놓음으로써 인스턴스에서 사용자 지정 작업을 수행할 수 있습니다. 사용자 지정 작업은 인스턴스가 시작될 때 또는 해지되기 전에 수행됩니다.
또한 웜 풀 구성에서 수명 주기 후크는 인스턴스의 초기화가 완료될 때까지 스케일 아웃 이벤트 중에 인스턴스가 중지 또는 동면되거나 서비스 상태가 되지 않도록 인스턴스를 지연시킬 수 있습니다. 수명 주기 후크 없이 Auto Scaling 그룹에 웜 풀을 추가하는 경우, 초기화를 완료하는 데 시간이 오래 걸리는 인스턴스는 준비가 되기 전에 스케일 아웃 이벤트 동안 중지되거나 최대 절전 모드로 전환된 다음 서비스 상태가 될 수 있습니다.
**인스턴스 재사용 정책**
기본적으로 Amazon EC2 Auto Scaling은 Auto Scaling 그룹이 축소되면 인스턴스를 해지합니다. 그런 다음 웜 풀로 새 인스턴스를 시작하여 해지된 인스턴스를 교체합니다.
그러지 않고 웜 풀로 인스턴스를 반환하려는 경우, 인스턴스 재사용 정책을 지정할 수 있습니다. 이렇게 하면 이미 애플리케이션 트래픽을 처리하도록 구성된 인스턴스를 재사용할 수 있습니다. 웜 풀이 과다 프로비저닝되지 않도록 Amazon EC2 Auto Scaling은 해당 설정을 기준으로 웜 풀이 필요 이상으로 큰 경우, 웜 풀의 인스턴스를 해지하여 그 크기를 줄일 수 있습니다. 웜 풀에서 인스턴스를 해지할 때 웜 풀은 [기본 해지 정책](ec2-auto-scaling-termination-policies.md#default-termination-policy)을 사용하여 먼저 해지할 인스턴스를 선택합니다.
축소 시 인스턴스를 최대 절전 모드로 전환하려는 경우, Auto Scaling 그룹에 기존 인스턴스가 있으면 인스턴스가 인스턴스 최대 절전 모드에 대한 요건을 충족해야 합니다. 그렇지 않으면 인스턴스가 웜 풀로 반환될 때 최대 절전 모드 대신 중지 상태로 전환됩니다.
현재는 AWS CLI 또는 SDK만 사용하여 인스턴스 재사용 정책을 지정할 수 있습니다. 콘솔에서는 이 기능을 사용할 수 없습니다.
## 사전 조건
Auto Scaling 그룹에 대한 웜 풀을 만들기 전에 수명 주기 후크를 사용하여 새 인스턴스를 적절한 초기 상태로 초기화할 방법을 결정하세요.
수명 주기 후크로 인해 대기 상태에 있는 인스턴스에 대해 사용자 지정 작업을 수행하려면 다음 두 가지 옵션이 있습니다.
+ 시작 시 인스턴스에서 명령을 실행하는 간단한 시나리오의 경우, Auto Scaling 그룹에 대한 시작 템플릿 또는 시작 구성을 생성할 때 사용자 데이터 스크립트를 포함할 수 있습니다. 사용자 데이터 스크립트는 인스턴스를 시작할 때 cloud-init을 통해 실행되는 단순한 일반 쉘 스크립트 또는 cloud-init 명령입니다. 이 스크립트는 스크립트가 실행되는 인스턴스의 ID를 사용하여 인스턴스가 다음 상태로 전환되는 시기를 제어할 수도 있습니다. 아직 없는 경우, 인스턴스 메타데이터에서 인스턴스의 인스턴스 ID를 검색하도록 스크립트를 업데이트합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 메타데이터 액세스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html)를 참조하세요.
**작은 정보**
인스턴스가 다시 시작될 때 사용자 데이터 스크립트를 실행하려면 사용자 데이터가 MIME 멀티 파트 형식이어야 하며 사용자 데이터의 `#cloud-config` 섹션에 다음과 같은 사항을 지정해야 합니다.
```
#cloud-config
cloud_final_modules:
- [scripts-user, always]
```
+ 인스턴스가 웜 풀 AWS Lambda 에 들어오거나 나갈 때와 같은 서비스가 필요한 고급 시나리오의 경우 Auto Scaling 그룹에 대한 수명 주기 후크를 생성하고 수명 주기 알림을 기반으로 사용자 지정 작업을 수행하도록 대상 서비스를 구성할 수 있습니다. 자세한 내용은 [지원되는 알림 대상](warm-pool-instance-lifecycle.md#warm-pools-supported-notification-targets) 단원을 참조하십시오.
**인스턴스의 최대 절전 모드 준비**
`Hibernated` 풀 상태를 사용하도록 Auto Scaling 인스턴스를 준비하려면 *Amazon EC2 사용 설명서*의 [최대 절전 모드 사전 조건](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html) 주제에 설명된 대로 인스턴스 최대 절전 모드를 지원하도록 올바르게 설정된 새 시작 템플릿 또는 시작 구성을 생성합니다. 그런 다음 새 시작 템플릿 또는 시작 구성을 Auto Scaling 그룹과 연결하고 인스턴스 새로 고침을 시작하여 이전 시작 템플릿 또는 시작 구성과 연결된 인스턴스를 교체합니다. 자세한 설명은 [인스턴스 새로 고침을 사용하여 Auto Scaling 그룹의 인스턴스 업데이트](asg-instance-refresh.md) 섹션을 참조하세요.
## 웜 풀에서 인스턴스 업데이트
웜 풀의 인스턴스를 업데이트하려면 새 시작 템플릿 또는 시작 구성을 만들어 Auto Scaling 그룹에 연결하면 됩니다. 새 인스턴스는 시작 템플릿 또는 시작 구성에 지정된 새 AMI 및 기타 업데이트를 사용하여 시작되지만 기존 인스턴스는 영향을 받지 않습니다.
새 시작 템플릿 또는 시작 구성을 사용하는 교체 웜 풀 인스턴스가 강제로 시작되도록 하려면 인스턴스 새로 고침을 시작하여 그룹의 롤링 업데이트를 수행하면 됩니다. 인스턴스 새로 고침은 먼저 `InService` 인스턴스를 교체합니다. 그런 다음 웜 풀의 인스턴스를 교체합니다. 자세한 설명은 [인스턴스 새로 고침을 사용하여 Auto Scaling 그룹의 인스턴스 업데이트](asg-instance-refresh.md) 섹션을 참조하세요.
## 관련 리소스
[GitHub 리포지토리](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)에서 웜 풀용 수명 주기 후크의 예를 확인할 수 있습니다.
## 제한 사항
+ 혼합 인스턴스 유형이 있는 Auto Scaling 그룹의 웜 풀 제한 사항:
+ 웜 풀은 가중치 기반 혼합 인스턴스 그룹에서 지원되지 않습니다. Auto Scaling 그룹에서 인스턴스 가중치를 사용하는 경우 웜 풀을 추가할 수 없습니다.
+ 웜 풀은 혼합 인스턴스 그룹 내의 스팟 인스턴스를 지원하지 않습니다. 혼합 인스턴스 정책은 웜 풀을 사용할 때만 온디맨드 인스턴스에 대해 구성해야 합니다.
+ 최대 절전 모드로 혼합 인스턴스 그룹과 함께 웜 풀을 사용하는 경우 시작 템플릿에서 `HibernationOptions`를 구성해야 합니다.
+ Amazon EC2 Auto Scaling은 루트 디바이스로 Amazon EBS 볼륨이 있는 경우에만 인스턴스를 `Stopped` 또는 `Hibernated` 상태로 전환할 수 있습니다. 루트 디바이스에 인스턴스 스토어를 사용하는 인스턴스는 중지하거나 최대 전절 모드로 전환할 수 없습니다.
+ Amazon EC2 Auto Scaling은 *Amazon EC2 사용 설명서*의 [최대 절전 모드 사전 조건](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html) 주제에 열거된 요건을 충족하는 경우에만 인스턴스를 `Hibernated` 상태로 전환할 수 있습니다.
+ 스케일 아웃 이벤트가 있을 때 웜 풀이 고갈되면 인스턴스는 Auto Scaling 그룹으로 바로 시작됩니다(*콜드 스타트*). 또한 가용 영역의 용량이 부족할 경우, 콜드 스타트가 발생할 수도 있습니다.
+ 웜 풀 내의 인스턴스가 시작 프로세스 중에 문제가 발생하여 `InService` 상태에 도달하지 못하는 경우 해당 인스턴스는 시작 실패로 간주되고 종료됩니다. 이는 용량 부족 오류 또는 기타 요인과 같은 기본 원인과 관계없이 적용됩니다.
+ Amazon Elastic Kubernetes Service(Amazon EKS) 관리형 노드 그룹에서 웜 풀을 사용하려는 경우, 아직 초기화 중인 인스턴스가 Amazon EKS 클러스터에 등록될 수 있습니다. 따라서 클러스터가 중지 또는 최대 절전 모드를 준비할 때 인스턴스에 대한 작업을 예약하게 될 수 있습니다.
+ 마찬가지로 Amazon ECS 클러스터에서 웜 풀을 사용하려는 경우, 초기화가 완료되기 전에 인스턴스가 클러스터에 등록될 수 있습니다. 이 문제를 해결하려면 사용자 데이터에 특수 에이전트 구성 변수를 포함하는 시작 템플릿 또는 시작 구성을 구성해야 합니다. 자세한 설명은 *Amazon Elastic Container Service 개발자 안내서*의 [Auto Scaling 그룹의 웜 풀 사용](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html#using-warm-pool)을 참조하세요.
# Auto Scaling 그룹에서 웜 풀과 함께 수명 주기 후크 사용
웜 풀의 인스턴스는 각 전환에 적절한 사용자 지정 작업을 생성하는 데 도움이 되도록 독립적인 자체 수명 주기를 유지합니다. 이 수명 주기는 인스턴스가 아직 초기화 중이고 서비스 상태가 되기 전에 대상 서비스에서 작업(예: Lambda 함수)을 호출하는 데 도움이 되도록 설계되었습니다.
**참고**
수명 주기 후크를 추가 및 관리하고 수명 주기 작업을 완료하는 데 사용하는 API 작업은 변경되지 않습니다. 인스턴스 수명 주기만 변경됩니다.
수명 주기 후크 추가에 대한 자세한 설명은 [Auto Scaling 그룹에 수명 주기 후크 추가](adding-lifecycle-hooks.md) 섹션을 참조하세요. 수명 주기 작업 완료에 대한 자세한 설명은 [Auto Scaling 그룹에서 수명 주기 작업 완료](completing-lifecycle-hooks.md) 섹션을 참조하세요.
웜 풀에 들어가는 인스턴스의 경우, 다음 이유 중 하나로 인해 수명 주기 후크가 필요할 수 있습니다.
+ 초기화를 완료하는 데 시간이 오래 걸리는 AMI에서 EC2 인스턴스를 시작하려고 합니다.
+ EC2 인스턴스를 부트스트랩하기 위해 사용자 데이터 스크립트를 실행하려고 합니다.
웜 풀에서 나가는 인스턴스의 경우, 다음 이유 중 하나로 인해 수명 주기 후크가 필요할 수 있습니다.
+ 사용할 EC2 인스턴스를 준비하는 데 추가 시간이 필요할 수 있습니다. 예컨대, 애플리케이션의 올바른 작동을 위해 인스턴스를 다시 시작할 때 반드시 시작해야 하는 서비스가 있을 수 있습니다.
+ 새 서버가 비어 있는 캐시로 시작되지 않도록 캐시 데이터를 미리 채우려고 합니다.
+ 새 인스턴스를 구성 관리 서비스에 관리형 인스턴스로 등록하려고 합니다.
## 웜 풀의 인스턴스에 대한 수명 주기 상태 전환
Auto Scaling 인스턴스는 수명 주기의 일부로 여러 가지 상태로 전환할 수 있습니다.
다음 다이어그램은 웜 풀을 사용할 때 Auto Scaling 상태 간의 전환을 보여줍니다.
![\[웜 풀의 인스턴스에 대한 수명 주기 상태 전환을 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/warm-pools-lifecycle-diagram.png)
¹ 이 상태는 웜 풀의 풀 상태 설정에 따라 다릅니다. 풀 상태가 `Running`으로 설정된 경우는 이 상태는 `Warmed:Running`이 됩니다. 풀 상태가 `Hibernated`로 설정된 경우, 이 상태는 `Warmed:Hibernated`가 됩니다.
수명 주기 후크를 추가할 때 다음 사항을 고려하세요.
+ `autoscaling:EC2_INSTANCE_LAUNCHING` 수명 주기 작업에 대해 수명 주기 후크가 구성된 경우, 새로 시작된 인스턴스가 `Warmed:Pending:Wait` 상태에 도달하면 먼저 일시 중지하여 사용자 지정 작업을 수행하고 인스턴스가 다시 시작되어 `Pending:Wait` 상태에 도달합니다.
+ `EC2_INSTANCE_TERMINATING` 수명 주기 작업에 대해 수명 주기 후크가 구성된 경우, 해지 인스턴스가 `Terminating:Wait` 상태에 도달하면 일시 중지하여 사용자 지정 작업을 수행합니다. 하지만 인스턴스를 해지하지 않고 스케일 인 시 웜 풀에 반환하도록 인스턴스 재사용 정책을 지정하는 경우, `EC2_INSTANCE_TERMINATING` 수명 주기 작업에 대해 `Warmed:Pending:Wait` 상태에서 웜 풀에 반환한 인스턴스가 일시 중지되어 사용자 지정 작업을 수행합니다.
+ 애플리케이션의 수요로 인해 웜 풀이 고갈되는 경우, Amazon EC2 Auto Scaling은 아직 최대 용량에 도달하지 않은 Auto Scaling 그룹으로 인스턴스를 직접 시작할 수 있습니다. 인스턴스가 그룹으로 직접 시작되는 경우, `Pending:Wait` 상태에서 사용자 지정 작업을 수행하기 위해서만 일시 중지됩니다.
+ 인스턴스가 다음 상태로 전환되기 전에 대기 상태를 유지하는 기간을 제어하려면 **complete-lifecycle-action** 명령을 사용하도록 사용자 지정 작업을 구성합니다. 수명 주기 후크를 사용하면 사용자가 지정된 수명 주기 작업이 완료되었음을 Amazon EC2 Auto Scaling에 알릴 때까지 혹은 제한 시간(기본적으로 1시간)이 끝날 때까지 인스턴스는 대기 상태로 유지됩니다.
다음은 스케일 아웃 이벤트의 흐름을 요약한 것입니다.
![\[스케일 아웃 이벤트의 흐름 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/images/warm-pools-scale-out-event-diagram.png)
인스턴스가 대기 상태에 도달하면 Amazon EC2 Auto Scaling이 알림을 전송합니다. 이러한 알림의 예는 이 가이드의 EventBridge 섹션에서 확인할 수 있습니다. 자세한 설명은 [웜 풀 예 이벤트 및 패턴](warm-pools-eventbridge-events.md) 섹션을 참조하세요.
## 지원되는 알림 대상
Amazon EC2 Auto Scaling은 수명 주기 알림에 대한 알림 대상으로 다음 중 하나를 정의하는 기능에 대한 지원을 제공합니다.
+ EventBridge 규칙
+ Amazon SNS 주제
+ Amazon SQS 대기열
+ AWS Lambda 함수
**중요**
시작 템플릿 또는 시작 구성에 인스턴스가 시작될 때 인스턴스를 구성하는 사용자 데이터(cloud-init) 스크립트가 있는 경우, 시작하거나 다시 시작하고 있는 인스턴스에 사용자 지정 작업을 수행하기 위해 알림을 받을 필요가 없습니다.
다음 섹션에는 알림 대상을 구성하는 방법을 설명하는 문서에 대한 링크가 포함되어 있습니다.
**EventBridge 규칙** - Amazon EC2 Auto Scaling이 인스턴스를 대기 상태로 설정할 때 코드를 실행하려면 EventBridge 규칙을 생성하고 Lambda 함수를 대상으로 지정할 수 있습니다. 수명 주기 알림에 따라 서로 다른 Lambda 함수를 호출하려면 여러 규칙을 생성하고 각 규칙을 특정 이벤트 패턴 및 Lambda 함수에 연결할 수 있습니다. 자세한 내용은 [웜 풀 이벤트에 대한 EventBridge 규칙 생성](warm-pool-events-eventbridge-rules.md) 단원을 참조하십시오.
**Amazon SNS 주제** - 인스턴스가 대기 상태로 설정될 때 알림을 받으려면 Amazon SNS 주제를 생성한 다음 메시지 속성에 따라 수명 주기 알림을 다르게 전송하도록 Amazon SNS 메시지 필터링을 설정합니다. 자세한 내용은 [Amazon SNS를 사용하여 알림 수신](prepare-for-lifecycle-notifications.md#sns-notifications) 단원을 참조하십시오.
**Amazon SQS 대기열** - 관련 소비자가 알림을 수신하고 처리할 수 있는 수명 주기 알림 전송 지점을 설정하려면 Amazon SQS 대기열과 해당 SQS 대기열의 메시지를 처리하는 대기열 소비자를 생성할 수 있습니다. 대기열 소비자가 메시지 속성에 따라 수명 주기 알림을 다르게 처리하도록 하려면 메시지를 구문 분석한 다음 특정 속성이 원하는 값과 일치하면 메시지에 대해 조치를 취하도록 대기열 소비자를 설정해야 합니다. 자세한 내용은 [Amazon SQS 사용하여 알림 수신](prepare-for-lifecycle-notifications.md#sqs-notifications) 단원을 참조하십시오.
**AWS Lambda 함수** - Amazon EC2 Auto Scaling이 인스턴스를 대기 상태로 전환할 때 사용자 지정 코드를 실행하려면 Lambda 함수를 알림 대상으로 지정할 수 있습니다. Lambda 함수는 수명 주기 알림 데이터와 함께 호출되므로 인스턴스 구성, 애플리케이션 설정 또는 다른 AWS 서비스와의 통합과 같은 사용자 지정 작업을 수행할 수 있습니다. Auto Scaling 서비스 연결 역할이 함수를 간접적으로 호출할 수 있도록 Lambda 함수의 리소스 기반 정책을 구성해야 합니다. 자세한 내용은 [에 AWS Lambda 직접 알림 라우팅](prepare-for-lifecycle-notifications.md#lambda-notification) 단원을 참조하십시오.
# Auto Scaling 그룹을 위한 웜 풀 생성
이 주제에서는 Auto Scaling 그룹을 위한 웜 풀을 생성하는 방법을 설명합니다.
**중요**
계속하기 전에 웜 풀을 만들기 위한 [전제 조건](ec2-auto-scaling-warm-pools.md#warm-pool-prerequisites)을 완료하고 Auto Scaling 그룹에 대한 수명 주기 후크를 만들었는지 확인하세요.
## 웜 풀 생성
다음 절차에 따라 Auto Scaling 그룹에 대한 웜 풀을 생성할 수 있습니다.
**웜 풀을 생성하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. 기존 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **Instance management(인스턴스 관리)** 탭을 선택합니다.
1. **Warm pool(웜 풀)**에서 **Create warm pool(웜 풀 만들기)**을 선택합니다.
1. 웜 풀을 구성하려면 다음을 수행하십시오:
1. **Warm pool instance state(웜 풀 인스턴스 상태)**에서 웜 풀에 들어갈 때 인스턴스를 전환할 상태를 선택합니다. 기본값은 `Stopped`입니다.
1. **Minimum warm pool size(최소 웜 풀 크기)**에 웜 풀에서 유지할 최소 인스턴스 수를 입력합니다.
1. **인스턴스 재사용**의 경우 Auto Scaling 그룹의 인스턴스가 스케일 인 시 웜 풀로 돌아가도록 허용하려면 **스케일 인 시 재사용** 확인란을 선택합니다.
1. **웜 풀 크기**에서 사용 가능한 옵션 중 하나를 선택합니다.
+ **기본 사양**: 웜 풀의 크기는 Auto Scaling 그룹의 최대 용량과 원하는 용량 간의 차이에 따라 결정됩니다. 이 옵션은 웜 풀 관리를 간소화합니다. 웜 풀을 생성한 후에는 그룹의 최대 용량을 조정하는 것만으로 웜 풀의 크기를 쉽게 업데이트할 수 있습니다.
+ **사용자 지정 사양**: 웜 풀의 크기는 사용자 지정 값과 Auto Scaling 그룹의 원하는 용량 간의 차이에 따라 결정됩니다. 이 옵션을 사용하면 그룹의 최대 용량과 독립적으로 웜 풀의 크기를 유연하게 관리할 수 있습니다.
1. **현재 설정을 기반으로 한 예상 웜 풀 크기**를 보고 기본 또는 사용자 지정 사양이 웜 풀 크기에 어떻게 적용되는지 확인합니다. 웜 풀의 크기는 Auto Scaling 그룹의 원하는 용량에 따라 달라지며, 그룹의 규모가 조정되면 변경됩니다.
1. **생성(Create)**을 선택합니다.
## 혼합 인스턴스 그룹이 있는 인스턴스 유형 선택
Auto Scaling은 그룹이 혼합 인스턴스 정책으로 구성된 경우 규모 조정 이벤트 중에 이미 웜 풀에 있는 인스턴스 유형의 우선순위를 지정합니다. 시작 동작:
1. Auto Scaling은 웜 풀에서 사용할 수 있는 인스턴스 유형을 사용하여 인스턴스를 시작하려고 시도합니다.
1. 웜 런치가 실패하면 Auto Scaling은 혼합 인스턴스 정책의 나머지 모든 인스턴스 유형을 사용하여 콜드 런치를 시도합니다.
**Example**
**예제**
Auto Scaling 그룹을 10개의 인스턴스 유형으로 구성했고 워밍 풀에 그중 6개가 포함되어 있다고 가정합니다. 스케일 아웃 중에 Auto Scaling은 먼저 웜 풀에서 6개의 인스턴스 유형을 시도합니다. 실패한 경우 Auto Scaling은 콜드 런치를 통해 구성된 모든 인스턴스 유형을 시도합니다.
이렇게 하면 전체 혼합 인스턴스 구성의 유연성을 유지하면서 가능하면 웜 풀 성능 이점을 얻을 수 있습니다.
## 웜 풀 삭제
더 이상 웜 풀이 필요하지 않으면 다음 절차에 따라 삭제합니다.
**웜 풀을 삭제하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. 기존 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **Instance management(인스턴스 관리)** 탭을 선택합니다.
1. **웜 풀(Warm pool)**에서 **작업(Actions)**, **삭제(Delete)**를 선택합니다.
1. 확인 메시지가 나타나면 **삭제**를 선택합니다.
# 건전성 체크의 상태 및 건전성 체크 불합격 이유 보기
상태 확인을 통해 Amazon EC2 Auto Scaling은 인스턴스가 비정상이며 해지되어야 하는 시점을 확인할 수 있습니다. `Stopped` 상태로 유지되는 웜 풀 인스턴스의 경우, Amazon EBS가 `Stopped`인스턴스의 가용성에 대해 알고 있는 정보를 사용하여 비건전 인스턴스를 식별할 수 있습니다. 인스턴스에 연결된 EBS 볼륨의 상태를 확인하는 `DescribeVolumeStatus` API를 호출하여 식별할 수 있습니다. `Running` 상태로 유지되는 웜 풀 인스턴스의 경우, EC2 건전성 체크에 따라 인스턴스 상태를 결정합니다. 웜 풀 인스턴스에 대한 건전성 체크 유예 기간은 없지만 Amazon EC2 Auto Scaling은 수명 주기 후크가 완료될 때까지 인스턴스 상태를 확인을 시작하지 않습니다.
인스턴스가 건전하지 않은 것으로 확인되면 Amazon EC2 Auto Scaling은 비건전 인스턴스를 자동으로 삭제하고 새 인스턴스를 생성하여 교체합니다. 인스턴스는 일반적으로 건전성 체크에 실패한 후 몇 분 이내에 해지됩니다. 자세한 설명은 [상태 확인 불합격 이유 확인](replace-unhealthy-instance.md)을 참조하세요.
사용자 지정 건전성 체크도 지원됩니다. 이는 인스턴스의 상태를 감지하고 해당 정보를 Amazon EC2 Auto Scaling에 전송할 수 있는 자체 건전성 체크 시스템이 있는 경우, 유용합니다. 자세한 내용은 [Auto Scaling 그룹에 대한 사용자 지정 상태 확인 설정](set-up-a-custom-health-check.md) 단원을 참조하십시오.
Amazon EC2 Auto Scaling 콘솔에서 웜 풀 인스턴스의 상태(정상 또는 비정상)를 확인할 수 있습니다. AWS CLI 또는 SDKs.
**웜 풀 인스턴스의 건전성 체크(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
**Auto Scaling 그룹(Auto Scaling groups)** 페이지 하단에 분할 창이 열립니다.
1. **인스턴스 관리(Instance management)** 탭의 **웜 풀 인스턴스(Warm pool instances)**에서 **수명 주기(Lifecycle)** 열은 인스턴스의 상태를 포함합니다.
**건전성 체크(Health status)** 열에는 Amazon EC2 Auto Scaling이 인스턴스 상태에 대해 평가한 내용이 표시됩니다.
**참고**
새 인스턴스가 정상으로 시작됩니다. 수명 주기 후크가 완료될 때까지 인스턴스의 상태는 확인되지 않습니다.
**건전성 체크 불합격 이유를 확인하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
**Auto Scaling 그룹(Auto Scaling groups)** 페이지 하단에 분할 창이 열립니다.
1. **활동(Activity)** 탭에서 **활동 기록(Activity history)**의 **상태(Status)** 열에 Auto Scaling 그룹이 성공적으로 인스턴스를 시작 또는 해지했는지가 표시됩니다.
비건전 인스턴스를 해지한 경우, **원인(Cause)** 열에는 해지 날짜 및 시간과 건전성 체크 불합격 이유가 표시됩니다. 예: “2021-04-01T21:48:35Z에 EBS 볼륨 건전성 체크 불합격에 대한 응답으로 인스턴스가 서비스 중단되었습니다.”
**웜 풀 인스턴스의 건전성 체크(AWS CLI)**
다음을 [describe-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-warm-pool.html) 명령을 사용하여 Auto Scaling 그룹의 웜 풀을 확인할 수 있습니다.
```
aws autoscaling describe-warm-pool --auto-scaling-group-name my-asg
```
출력 예제
```
{
"WarmPoolConfiguration": {
"MinSize": 0,
"PoolState": "Stopped"
},
"Instances": [
{
"InstanceId": "i-0b5e5e7521cfaa46c",
"InstanceType": "t2.micro",
"AvailabilityZone": "us-west-2a",
"LifecycleState": "Warmed:Stopped",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-08c4cd42f320d5dcd",
"LaunchTemplateName": "my-template-for-auto-scaling",
"Version": "1"
}
},
{
"InstanceId": "i-0e21af9dcfb7aa6bf",
"InstanceType": "t2.micro",
"AvailabilityZone": "us-west-2a",
"LifecycleState": "Warmed:Stopped",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-08c4cd42f320d5dcd",
"LaunchTemplateName": "my-template-for-auto-scaling",
"Version": "1"
}
}
]
}
```
**건전성 체크 불합격 이유 확인(AWS CLI)**
다음 [describe-scaling-activities](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-scaling-activities.html) 명령을 사용합니다.
```
aws autoscaling describe-scaling-activities --auto-scaling-group-name my-asg
```
다음은 응답의 예입니다. `Description`은 Auto Scaling 그룹이 인스턴스를 해지했음을 나타내며 `Cause`는 건전성 체크 불합격의 원인을 나타냅니다.
크기 조정 활동은 시작 시간으로 정렬됩니다. 아직 진행 중인 활동이 먼저 설명됩니다.
```
{
"Activities": [
{
"ActivityId": "4c65e23d-a35a-4e7d-b6e4-2eaa8753dc12",
"AutoScalingGroupName": "my-asg",
"Description": "Terminating EC2 instance: i-04925c838b6438f14",
"Cause": "At 2021-04-01T21:48:35Z an instance was taken out of service in response to EBS volume health check failure.",
"StartTime": "2021-04-01T21:48:35.859Z",
"EndTime": "2021-04-01T21:49:18Z",
"StatusCode": "Successful",
"Progress": 100,
"Details": "{\"Subnet ID\":\"subnet-5ea0c127\",\"Availability Zone\":\"us-west-2a\"...}",
"AutoScalingGroupARN": "arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:283179a2-f3ce-423d-93f6-66bb518232f7:autoScalingGroupName/my-asg"
},
...
]
}
```
# 를 사용하여 웜 풀을 생성하고 관리하는 예제 AWS CLI
AWS Management Console, AWS Command Line Interface (AWS CLI) 또는 SDKs.
다음 예에서는 AWS CLI를 사용하여 웜 풀을 생성하고 관리하는 방법을 보여줍니다.
**Topics**
+ [예 1: `Stopped` 상태로 인스턴스 유지](#warm-pool-configuration-ex1)
+ [예 2: `Running` 상태로 인스턴스 유지](#warm-pool-configuration-ex2)
+ [예 3: `Hibernated` 상태로 인스턴스 유지](#warm-pool-configuration-ex3)
+ [예 4: 축소 시 웜 풀로 인스턴스 반환](#warm-pool-configuration-ex4)
+ [예 5: 웜 풀의 최소 인스턴스 수 지정](#warm-pool-configuration-ex5)
+ [예제 6: 사용자 지정 사양을 사용하여 웜 풀 크기 정의](#warm-pool-configuration-ex6)
+ [예 7: 절대 웜 풀 크기 정의](#warm-pool-configuration-ex7)
+ [예 8: 웜 풀 삭제](#delete-warm-pool-cli)
## 예 1: `Stopped` 상태로 인스턴스 유지
다음 [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) 예는 인스턴스를 `Stopped` 상태로 유지하는 웜 풀을 생성합니다.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped
```
## 예 2: `Running` 상태로 인스턴스 유지
다음 [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) 예는 인스턴스를 `Stopped` 상태 대신 `Running` 상태로 유지하는 웜 풀을 생성합니다.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Running
```
## 예 3: `Hibernated` 상태로 인스턴스 유지
다음 [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) 예는 인스턴스를 `Stopped` 상태 대신 `Hibernated` 상태로 유지하는 웜 풀을 생성합니다. 이렇게 하면 메모리 콘텐츠(RAM)를 삭제하지 않고 인스턴스를 중지할 수 있습니다.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Hibernated
```
## 예 4: 축소 시 웜 풀로 인스턴스 반환
다음 [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) 예는 인스턴스를 `Stopped` 상태로 유지하고 `--instance-reuse-policy` 옵션을 포함하는 웜 풀을 생성합니다. 인스턴스 재사용 정책 값 `'{"ReuseOnScaleIn": true}'`는 Auto Scaling 그룹이 축소되면 Amazon EC2 Auto Scaling에서 인스턴스를 웜 풀로 반환하도록 지시합니다.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --instance-reuse-policy '{"ReuseOnScaleIn": true}'
```
## 예 5: 웜 풀의 최소 인스턴스 수 지정
다음 [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) 예는 최소 4개의 인스턴스를 유지하는 웜 풀을 생성하므로 트래픽 급증을 처리할 수 있는 인스턴스가 적어도 4개가 있게 됩니다.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --min-size 4
```
## 예제 6: 사용자 지정 사양을 사용하여 웜 풀 크기 정의
기본적으로 Amazon EC2 Auto Scaling은 Auto Scaling 그룹의 최대 용량과 원하는 용량 간의 차이에 따라 웜 풀의 크기를 관리합니다. 하지만 `--max-group-prepared-capacity` 옵션을 사용하여 그룹의 최대 용량과 독립적으로 웜 풀의 크기를 관리할 수 있습니다.
다음 [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) 예제는 웜 풀을 생성하고 웜 풀과 Auto Scaling 그룹 모두에 동시에 존재할 수 있는 최대 인스턴스 수를 설정합니다. 그룹의 원하는 용량이 800인 경우 웜 풀은 이 명령을 실행한 후 초기화될 때 처음에 크기가 100이 됩니다.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --max-group-prepared-capacity 900
```
웜 풀의 최소 인스턴스 수를 유지하려면 다음과 같이 명령에 `--min-size` 옵션을 포함합니다.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --max-group-prepared-capacity 900 --min-size 25
```
## 예 7: 절대 웜 풀 크기 정의
`--max-group-prepared-capacity` 및 `--min-size` 옵션에 동일한 값을 설정하는 경우, 웜 풀은 절대 크기를 갖습니다. 다음 [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html) 예는 웜 풀 크기를 인스턴스 10개로 일정하게 유지하는 웜 풀을 생성합니다.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --min-size 10 --max-group-prepared-capacity 10
```
## 예 8: 웜 풀 삭제
웜 풀을 삭제하려면 다음 [delete-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-warm-pool.html) 명령을 사용합니다.
```
aws autoscaling delete-warm-pool --auto-scaling-group-name my-asg
```
웜 풀에 인스턴스가 있거나 조정 활동이 진행 중인 경우, `--force-delete` 옵션과 함께 [delete-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-warm-pool.html) 명령을 사용합니다. 또한 이 옵션은 Amazon EC2 인스턴스와 모든 미처리 수명 주기 작업을 해지합니다.
```
aws autoscaling delete-warm-pool --auto-scaling-group-name my-asg --force-delete
```
# Auto Scaling 그룹 영역 전환
영역 전환은 Amazon Application Recovery Controller(ARC)의 기능입니다. 영역 전환을 사용하면 단일 작업으로 가용 영역의 애플리케이션 장애로부터 신속하게 복구할 수 있습니다. Auto Scaling 그룹에 대해 영역 전환을 활성화하면 그룹이 ARC 영역 전환 서비스에 등록됩니다. 그런 다음 AWS Management Console AWS CLI또는 API를 사용하여 영역 전환을 시작할 수 있으며 Auto Scaling 그룹은 활성 영역 전환이 있는 가용 영역을 손상된 것으로 취급합니다.
## Auto Scaling 그룹 영역 전환 개념
계속하기 전에 ARC 영역 전환과의 통합과 관련된 다음 핵심 개념을 숙지해야 합니다.
**ARC 영역 전환**
이 기능을 활성화하면 Auto Scaling이 ARC 영역 전환으로 Auto Scaling 그룹을 등록할 수 있습니다. 등록 후 [ARC `ListManagedResources`](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_ListManagedResources.html) API를 사용하여 리소스를 볼 수 있습니다. 자세한 내용은 *Amazon Application Recovery Controller(*[ARC) 개발자 안내서의 ARC의 영역 전환을](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html) 참조하세요.
**가용 영역 재조정**
Auto Scaling은 각 가용 영역의 용량을 균형 있게 유지하려고 시도합니다. 가용 영역 간에 불균형이 발생하면 Auto Scaling은 자동으로 불균형을 해결하려고 시도합니다. 자세한 내용은 [인스턴스 분산](auto-scaling-benefits.md#AutoScalingBehavior.Rebalancing) 단원을 참조하십시오.
**동적 조정**
동적 조정은 조정 정책으로 선택한 지표를 기반으로 Auto Scaling 그룹의 원하는 용량을 조정합니다. 자세한 내용은 [Amazon EC2 Auto Scaling의 동적 조정](as-scale-based-on-demand.md) 단원을 참조하십시오.
**상태 확인**
Auto Scaling은 Auto Scaling 그룹 내 모든 인스턴스의 상태를 주기적으로 확인하여 실행 중이고 상태가 양호한지 확인합니다. 비정상 인스턴스가 감지되면 Auto Scaling은 이를 교체 대상으로 표시합니다. 자세한 내용은 [Auto Scaling 그룹의 인스턴스에 대한 상태 확인](ec2-auto-scaling-health-checks.md) 단원을 참조하십시오.
**인스턴스 새로 고침**
인스턴스 새로 고침을 사용하여 Auto Scaling 그룹의 인스턴스를 업데이트할 수 있습니다. 인스턴스 새로 고침이 시작된 후 Auto Scaling은 Auto Scaling 그룹의 모든 인스턴스를 교체하려고 시도합니다. 자세한 내용은 [인스턴스 새로 고침을 사용하여 Auto Scaling 그룹의 인스턴스 업데이트](asg-instance-refresh.md) 단원을 참조하십시오.
**미리 조정됨**
애플리케이션의 나머지 가용 영역에 충분한 용량이 있으므로 단일 가용 영역의 손실을 허용할 수 있습니다.
**확장**
Auto Scaling 그룹의 원하는 용량을 늘리면 Auto Scaling은 원하는 새 용량을 충족하기 위해 추가 인스턴스를 시작하려고 시도합니다. 기본적으로 Auto Scaling은 Auto Scaling 그룹의 활성화된 각 가용 영역에서 동일한 용량을 유지하기 위해 균형 잡힌 방식으로 인스턴스를 시작합니다.
## Auto Scaling 그룹에서 영역 전환 작동 방식
다음 가용 영역이 있는 Auto Scaling 그룹이 있다고 가정해 보겠습니다.
+ `us-east-1a`
+ `us-east-1b`
+ `us-east-1c`
모든 가용 영역에서 영역 전환이 활성화되어 있고에서 장애가 발견`us-east-1a`되어 영역 전환을 트리거합니다. 에서 영역 전환이 트리거되면 다음 동작이 발생합니다`us-east-1a`.
+ **확장 **- Auto Scaling은 정상 가용 영역(`us-east-1b` 및 )에서 모든 새 용량 요청을 시작합니다`us-east-1c`.
+ **동적 조정** - Auto Scaling은 조정 정책이 모든 가용 영역에서 원하는 용량을 줄이는 것을 차단합니다. Auto Scaling은 조정 정책이 모든 가용 영역에서 원하는 용량을 늘리는 것을 차단하지 않습니다.
+ **인스턴스 새로 고침** - Auto Scaling은 영역 전환이 활성화되어 있는 동안 지연되는 모든 인스턴스 새로 고침 프로세스의 제한 시간을 연장합니다.
다음 표에서는에서 영역 전환이 트리거될 때 각 옵션의 상태 확인 동작을 설명합니다`us-east-1a`.
| 손상된 가용 영역 상태 확인 동작 선택 | 상태 확인 동작 |
| --- | --- |
| 비정상 교체 | 비정상으로 보이는 인스턴스는 모든 가용 영역(`us-east-1a`, `us-east-1b`및 `us-east-1c`)에서 교체됩니다. |
| 비정상 무시 | 비정상으로 보이는 인스턴스는 `us-east-1b` 및에서 교체됩니다`us-east-1c`. 가용 영역에서 활성 영역 전환()으로 인스턴스가 교체되지 않습니다`us-east-1a`. |
## 영역 전환 사용 모범 사례
영역 전환을 사용할 때 애플리케이션의 고가용성을 유지하려면 다음 모범 사례를 따르는 것이 좋습니다.
+ EventBridge 알림을 모니터링하여 진행 중인 가용 영역 장애 이벤트가 있는지 확인합니다. 자세한 내용은 [EventBridge를 사용하여 Auto Scaling 이벤트 처리](automating-ec2-auto-scaling-with-eventbridge.md) 단원을 참조하십시오.
+ 적절한 임계값이 있는 조정 정책을 사용하여 가용 영역 손실을 견딜 수 있는 충분한 용량이 있는지 확인합니다.
+ 최소 정상 백분율이 100인 인스턴스 유지 관리 정책을 설정합니다. 이 설정을 사용하면 Auto Scaling은 비정상 인스턴스를 종료하기 전에 새 인스턴스를 사용할 준비가 될 때까지 기다립니다.
사전 규모 조정된 고객의 경우 다음 사항도 권장합니다.
+ 장애 이벤트 중에 **비정상 인스턴스를 교체할 필요가 없으므로 손상된 가용 영역의 상태 확인 동작**으로 비정상 무시를 선택합니다.
+ Auto Scaling 그룹에 대해 ARC에서 영역 자동 전환을 사용합니다. ARC의 영역 자동 전환 기능을 사용하면가 가용 영역의 장애를 AWS 감지할 때 리소스의 트래픽을 가용 영역에서 다른 곳으로 AWS 이동할 수 있습니다. 자세한 내용은 *Amazon Application Recovery Controller(*[ARC) 개발자 안내서의 ARC의 영역 자동 전환을](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html) 참조하세요.
교차 영역 비활성화 로드 밸런서가 있는 고객의 경우 다음 사항도 권장합니다.
+ 가용 영역 배포**에만 밸런스**를 사용합니다.
+ Auto Scaling 그룹과 로드 밸런서 모두에서 영역 전환을 사용하는 경우 먼저 Auto Scaling 그룹의 영역 전환을 취소합니다. 그런 다음 로드 밸런서에서 영역 전환을 취소하기 전에 모든 가용 영역에서 용량이 균형을 이룰 때까지 기다립니다.
+ 영역 전환을 활성화하고 교차 영역 비활성화 로드 밸런서를 사용할 때 용량이 불균형할 수 있으므로 Auto Scaling에는 추가 검증 단계가 포함됩니다. 모범 사례를 따르는 경우 AWS Management Console 확인란을 선택하거나 , 또는의 `skip-zonal-shift-validation` 플래그를 사용하여 이러한 가능성을 확인할 수 있습니다`CreateAutoScalingGroup``UpdateAutoScalingGroup``AttachTrafficSources`.
Auto Scaling 그룹에서 영역 전환을 사용하는 방법에 대한 자세한 내용은 [ Amazon EC2 Auto Scaling에서 영역 전환을 사용하는](https://aws.amazon.com/blogs/compute/using-zonal-shift-with-amazon-ec2-auto-scaling/) AWS 컴퓨팅 블로그를 참조하세요.
# AWS Management Console 또는를 사용하여 영역 전환 활성화 AWS CLI
영역 전환을 활성화하려면 다음 방법 중 하나를 사용합니다.
------
#### [ Console ]
**새 그룹에서 영역 전환을 활성화하려면(콘솔)**
1. 의 지침에 따라 절차의 각 단계를 10단계까지 [시작 템플릿을 사용하여 Auto Scaling 그룹 생성](create-asg-launch-template.md) 완료합니다.
1. **다른 서비스와 통합** 페이지의 **Application Recovery Controller(ARC) 영역 전환**에서 확인란을 선택하여 영역 전환을 활성화합니다.
1. **상태 확인 동작**에서 비정상 무시 또는 비정상 교체를 선택합니다. 자세한 내용은 [Auto Scaling 그룹에서 영역 전환 작동 방식](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works) 단원을 참조하십시오.
1. [시작 템플릿을 사용하여 Auto Scaling 그룹 생성](create-asg-launch-template.md)의 단계를 계속합니다.
------
#### [ AWS CLI ]
**새 그룹에서 영역 전환을 활성화하려면(AWS CLI)**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령에 `--availability-zone-impairment-policy` 파라미터를 추가합니다.
`--availability-zone-impairment-policy` 파라미터에는 두 가지 옵션이 있습니다.
+ **ZonalShiftEnabled** - 로 설정하면 `true` Auto Scaling은 Auto Scaling 그룹을 ARC 영역 전환에 등록하고 ARC 콘솔에서 [영역 전환을 시작, 업데이트 또는 취소할](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) 수 있습니다. 로 설정하면 `false` Auto Scaling은 ARC 영역 전환에서 Auto Scaling 그룹의 등록을 취소합니다. 를 로 설정하려면 영역 전환이 이미 활성화되어 있어야 합니다`false`.
+ **ImpairedZoneHealthCheckBehavior** – 로 설정하면 `replace-unhealthy`비정상 인스턴스가 가용 영역에서 활성 영역 전환으로 대체됩니다. 로 설정하면 가용 영역에서 `ignore-unhealthy`비정상 인스턴스가 활성 영역 전환으로 대체되지 않습니다. 자세한 내용은 [Auto Scaling 그룹에서 영역 전환 작동 방식](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works) 단원을 참조하십시오.
다음 예시에서는 라는 새 Auto Scaling 그룹에서 영역 전환을 활성화합니다`my-asg`.
```
aws autoscaling create-auto-scaling-group \
--launch-template LaunchTemplateName=my-launch-template,Version='1' \
--auto-scaling-group-name my-asg \
--min-size 1 \
--max-size 10 \
--desired-capacity 5 \
--availability-zones us-east-1a us-east-1b us-east-1c \
--availability-zone-impairment-policy '{
"ZonalShiftEnabled": true,
"ImpairedZoneHealthCheckBehavior": IgnoreUnhealthy
}'
```
------
------
#### [ Console ]
**기존 그룹에서 영역 전환을 활성화하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. 화면 상단의 탐색 모음에서 Auto Scaling 그룹을 생성한 AWS 리전 을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **통합** 탭의 **Application Recovery Controller(ARC) 영역 전환**에서 **편집**을 선택합니다.
1. 확인란을 선택하여 영역 전환을 활성화합니다.
1. **상태 확인 동작**에서 비정상 무시 또는 비정상 교체를 선택합니다. 자세한 내용은 [Auto Scaling 그룹에서 영역 전환 작동 방식](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works) 단원을 참조하십시오.
1. **업데이트**를 선택합니다.
------
#### [ AWS CLI ]
**기존 그룹에서 영역 전환을 활성화하려면(AWS CLI)**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) 명령에 `--availability-zone-impairment-policy` 파라미터를 추가합니다.
`--availability-zone-impairment-policy` 파라미터에는 두 가지 옵션이 있습니다.
+ **ZonalShiftEnabled** - 로 설정하면 `true` Auto Scaling은 Auto Scaling 그룹을 ARC 영역 전환에 등록하고 ARC 콘솔에서 [영역 전환을 시작, 업데이트 또는 취소할](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) 수 있습니다. 로 설정하면 `false` Auto Scaling은 ARC 영역 전환에서 Auto Scaling 그룹의 등록을 취소합니다. 를 로 설정하려면 영역 전환이 이미 활성화되어 있어야 합니다`false`.
+ **ImpairedZoneHealthCheckBehavior** – 로 설정하면 `replace-unhealthy`비정상 인스턴스가 가용 영역에서 활성 영역 전환으로 대체됩니다. 로 설정하면 가용 영역에서 `ignore-unhealthy`비정상 인스턴스가 활성 영역 전환으로 대체되지 않습니다. 자세한 내용은 [Auto Scaling 그룹에서 영역 전환 작동 방식](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works) 단원을 참조하십시오.
다음 예시에서는 지정된 Auto Scaling 그룹에서 영역 전환을 활성화합니다.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \
--availability-zone-impairment-policy '{
"ZonalShiftEnabled": true,
"ImpairedZoneHealthCheckBehavior": IgnoreUnhealthy
}'
```
------
# Auto Scaling 그룹 가용 영역 배포
다음 정보는 Auto Scaling 그룹 가용 영역 전략을 설명합니다.
**균형 기반 최대 노력**
Auto Scaling은 활성화된 가용 영역에서 동일한 수의 인스턴스를 유지합니다. 가용 영역에서 시작이 실패할 경우 Auto Scaling은 다른 정상 가용 영역에서 인스턴스를 시작하려고 시도합니다. 이 전략은 가용 영역 이중화가 필요하고 불균형한 그룹의 영향을 받지 않는 애플리케이션에 중요합니다.
**균등 분배 전용**
Auto Scaling은 활성화된 가용 영역에서 동일한 수의 인스턴스를 유지합니다. 가용 영역에서 시작 시도가 실패하면 Auto Scaling은 가용 영역에서 인스턴스 시작을 계속 시도합니다. 이 전략은 쿼럼 기반 워크로드와 같은 특정 요구 사항을 충족하거나 나머지 가용 영역에 충분한 용량이 있기 때문에 Auto Scaling 그룹이 가용 영역 손실을 허용할 수 있는 경우에 중요합니다.
가용 영역 배포 전략 선택은의 **네트워크** 섹션에 AWS Management Console 있거나 [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 또는 [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) 명령을 사용할 수 있습니다.
자세한 내용은 [시작 템플릿을 사용하여 Auto Scaling 그룹 생성](create-auto-scaling-groups-launch-template.md) 단원을 참조하십시오.
# Auto Scaling 그룹에서 인스턴스 분리 또는 연결
Auto Scaling 그룹에서 인스턴스를 분리할 수 있습니다. 인스턴스가 분리되면 해당 인스턴스는 독립적이 되고 자체적으로 관리되거나 원래 속해 있던 그룹과 별도로 다른 Auto Scaling 그룹에 연결할 수 있습니다. 예를 들어 애플리케이션을 이미 실행 중인 기존 인스턴스를 사용하여 테스트를 수행하려는 경우에 유용할 수 있습니다.
이 주제에서는 인스턴스를 분리하고 연결하는 방법에 대한 지침을 제공합니다. 인스턴스를 연결할 때 분리된 인스턴스가 아닌 기존 인스턴스를 사용할 수도 있습니다.
인스턴스를 분리했다가 동일한 그룹에 다시 연결하는 대신 대기 절차를 사용하여 그룹에서 인스턴스를 일시적으로 제거하는 것이 좋습니다. 자세한 내용은 [Auto Scaling 그룹에서 일시적으로 인스턴스 제거](as-enter-exit-standby.md) 단원을 참조하십시오.
**Topics**
+ [인스턴스 분리 시 고려 사항](#detach-instances-considerations)
+ [인스턴스 연결 시 고려 사항](#attach-instances-considerations)
+ [분리 및 연결을 사용하여 인스턴스를 다른 그룹으로 이동](#detach-attach-instances)
## 인스턴스 분리 시 고려 사항
인스턴스를 분리할 때 다음 사항에 유의하세요.
+ 인스턴스가 `InService` 또는 `StandBy` 상태인 경우에만 인스턴스를 분리할 수 있습니다. `StandBy` 상태에 있는 인스턴스를 분리하는 경우, 주의하세요. 인스턴스를 `StandBy` 상태로 전환한 뒤 분리하려 할 때 API 직접 호출에 `ShouldDecrementDesiredCapacity` 플래그를 포함하면, 다른 인스턴스가 예기치 않게 종료될 수 있습니다.
+ 인스턴스를 분리한 후에도 계속 실행되고 요금이 발생합니다. 불필요한 요금을 방지하려면 분리된 인스턴스가 더 이상 필요하지 않을 때 다시 연결하거나 종료해야 합니다.
+ 분리하려는 인스턴스 수만큼 원하는 용량을 줄이도록 선택할 수 있습니다. 용량을 줄이지 않도록 선택하면 Amazon EC2 Auto Scaling에서 새 인스턴스를 시작하여 분리한 인스턴스를 교체하고 원하는 용량을 유지합니다.
+ 분리하려는 인스턴스의 수로 인해 Auto Scaling 그룹이 최소 용량 아래로 감소할 경우, 최소 용량을 줄여야 합니다.
+ 원하는 용량을 줄이지 않고 동일한 가용 영역에서 여러 인스턴스를 분리하는 경우, `AZRebalance` 프로세스를 일시 중지하지 않는 한 그룹이 자체적으로 균형을 재조정합니다. 자세한 내용은 [Amazon EC2 Auto Scaling 프로세스 일시 중지 및 재개](as-suspend-resume-processes.md) 단원을 참조하십시오.
+ 연결된 로드 밸런서 대상 그룹 또는 Classic Load Balancer가 있는 Auto Scaling 그룹에서 인스턴스를 분리하면 해당 인스턴스가 로드 밸런서에서 등록 취소됩니다. 로드 밸런서에서 Connection Draining(등록 취소 지연)이 활성화된 경우, Amazon EC2 Auto Scaling은 진행 중인 요청이 완료될 때까지 기다립니다.
## 인스턴스 연결 시 고려 사항
인스턴스를 연결할 때 다음 사항에 유의하세요.
+ Amazon EC2 Auto Scaling은 연결된 인스턴스를 그룹 자체에서 시작된 인스턴스와 동일하게 처리합니다. 즉, 연결된 인스턴스를 선택한 경우 스케일 인 이벤트 중에 종료할 수 있습니다. AWSServiceRoleForAutoScaling 서비스 연결 역할에서 부여한 권한으로 Amazon EC2 Auto Scaling은 그렇게 할 수 있습니다.
+ 인스턴스를 연결하면 연결되는 인스턴스 수에 따라 그룹의 원하는 용량을 늘립니다. 새 인스턴스를 추가한 후에 원하는 용량이 그룹의 최대 크기를 초과하는 경우, 더 많은 인스턴스를 연결하기 위한 요청이 실패합니다.
+ 그룹에 인스턴스를 추가하여 가용 영역 간에 고르지 않은 분포가 발생하는 경우, `AZRebalance` 프로세스를 일시 중단하지 않는 한 Amazon EC2 Auto Scaling이 그룹의 균형을 재조정하여 균등한 분포를 다시 설정합니다. 자세한 내용은 [Amazon EC2 Auto Scaling 프로세스 일시 중지 및 재개](as-suspend-resume-processes.md) 단원을 참조하십시오.
+ 연결된 로드 밸런서 대상 그룹 또는 Classic Load Balancer가 있는 Auto Scaling 그룹에 인스턴스를 연결하면 해당 인스턴스가 로드 밸런서에 등록됩니다.
연결할 인스턴스는 다음 기준을 충족해야 합니다.
+ 인스턴스는 Amazon EC2에서 `running` 상태입니다.
+ 인스턴스를 시작할 때 사용되는 AMI가 항상 있어야 합니다.
+ 인스턴스가 다른 Auto Scaling 그룹의 구성원이 아닙니다.
+ 인스턴스가 Auto Scaling 그룹에 정의된 가용 영역 중 하나로 시작됩니다.
+ Auto Scaling 그룹에 연결된 로드 밸런서 대상 그룹 또는 Classic Load Balancer가 있는 경우, 인스턴스와 로드 밸런서는 모두 동일한 VPC에 있어야 합니다.
## 분리 및 연결을 사용하여 인스턴스를 다른 그룹으로 이동
다음 절차 중 하나를 사용하여 Auto Scaling 그룹에서 인스턴스를 분리하고 다른 Auto Scaling 그룹에 연결합니다.
분리된 인스턴스에서 새 Auto Scaling 그룹을 생성하려면 [를 사용하여 기존 인스턴스에서 Auto Scaling 그룹 생성 AWS CLI](create-asg-from-instance.md)(권장하지 않음, 시작 구성 생성) 섹션을 참조하세요.
------
#### [ Console ]
**Auto Scaling 그룹에서 인스턴스를 분리하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **인스턴스 관리(Instance management)** 탭의 **인스턴스(Instances)**에서 인스턴스를 선택하고 **작업(Actions)**, **분리(Detach)**를 선택합니다.
1. **인스턴스 분리 대화 상자에서 인스턴스** 교체 확인란을 선택한 상태로 유지하여 **교체 인스턴스를 시작**합니다. 원하는 용량을 줄이려면 확인란을 선택 취소합니다.
1. 확인하라는 메시지가 표시되면 **detach**를 입력하여 Auto Scaling 그룹에서 지정된 인스턴스의 삭제를 확인한 다음 **인스턴스 분리**를 선택합니다.
이제 인스턴스를 다른 Auto Scaling 그룹에 연결할 수 있습니다.
**Auto Scaling 그룹에 인스턴스를 연결하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. (옵션) 탐색 창의 **Auto Scaling**에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다. Auto Scaling 그룹을 선택하고 Auto Scaling 그룹의 최대 크기가 다른 인스턴스를 추가할 수 있을 만큼 큰지 확인합니다. 그렇지 않으면 **세부 정보(Details)** 탭에서 최대 용량을 늘립니다.
1. 탐색 창의 **인스턴스(Instances)**에서 **인스턴스(Instances)**를 선택한 다음 인스턴스를 선택합니다.
1. **Actions**(작업), **Instance settings**(인스턴스 설정), **Attach to Auto Scaling Group**(Auto Scaling 그룹에 연결)을 차례로 선택합니다.
1. **Auto Scaling 그룹에 연결** 페이지에서 **Auto Scaling Group**(Auto Scaling 그룹)에 대한 Auto Scaling 그룹을 선택하고 **Attach**(연결)를 선택합니다.
1. 인스턴스가 기준을 충족하지 않으면 세부 정보가 포함된 오류 메시지가 표시됩니다. 예컨대, Auto Scaling 그룹과 동일한 가용 영역에 있지 않을 수도 있습니다. **닫기**를 선택하고 기준에 맞는 Auto Scaling 그룹으로 다시 시도합니다.
------
#### [ AWS CLI ]
인스턴스를 분리하고 연결하려면 다음 예제 명령을 사용합니다. *user input placeholder*를 사용자의 정보로 바꿉니다.
**Auto Scaling 그룹에서 인스턴스를 분리하려면**
1. 현재 인스턴스를 설명하려면 다음 [describe-auto-scaling-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-instances.html) 명령을 사용합니다.
```
aws autoscaling describe-auto-scaling-instances \
--query 'AutoScalingInstances[?AutoScalingGroupName==`my-asg`]'
```
다음 예제에서는 이 명령을 실행할 때 생성되는 출력을 보여줍니다.
그룹에서 제거하려는 인스턴스의 ID를 기록해 둡니다. 다음 단계에서 이 ID가 필요합니다.
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-0c20ac468fa3049e8",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-0787762faf1c28619",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-0f280a4c58d319a8a",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
}
]
}
```
1. 용량을 줄이지 않고 인스턴스를 분리하려면 다음 [detach-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/detach-instances.html) 명령을 사용합니다.
```
aws autoscaling detach-instances --instance-ids i-05b4f7d5be44822a6 \
--auto-scaling-group-name my-asg
```
인스턴스를 분리하고 원하는 용량을 줄이려면 `--should-decrement-desired-capacity` 옵션을 포함합니다.
```
aws autoscaling detach-instances --instance-ids i-05b4f7d5be44822a6 \
--auto-scaling-group-name my-asg --should-decrement-desired-capacity
```
이제 인스턴스를 다른 Auto Scaling 그룹에 연결할 수 있습니다.
**Auto Scaling 그룹에 인스턴스를 연결하려면**
1. 다른 Auto Scaling 그룹에 인스턴스를 연결하려면 다음 [attach-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/attach-instances.html) 명령을 사용합니다.
```
aws autoscaling attach-instances --instance-ids i-05b4f7d5be44822a6 --auto-scaling-group-name my-asg-for-testing
```
1. 인스턴스를 연결한 후 Auto Scaling 그룹의 크기를 확인하려면 다음 [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 명령을 사용합니다.
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names my-asg-for-testing
```
다음 예제 응답은 그룹에 실행 중인 인스턴스가 두 개 있으며, 그 중 하나가 연결한 인스턴스임을 보여줍니다.
```
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "my-asg-for-testing",
"AutoScalingGroupARN": "arn",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "2",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 2,
...
"Instances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"HealthStatus": "Healthy",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "2",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-00dcdfffdf5175890",
"InstanceType": "t3.micro",
"HealthStatus": "Healthy",
"LifecycleState": "InService"
}
],
...
}
]
}
```
------
# Auto Scaling 그룹에서 일시적으로 인스턴스 제거
`InService` 상태의 인스턴스를 `Standby` 상태로 설정하고, 인스턴스를 업데이트하거나 문제 해결한 다음, 해당 인스턴스를 서비스 상태로 되돌릴 수 있습니다. 대기 상태의 인스턴스는 Auto Scaling 그룹에 여전히 속하나, 로드 밸런서 트래픽을 처리하지는 못합니다.
이 기능을 사용하면 건전성 체크의 일부로 또는 축소 이벤트 중에 인스턴스를 해지하는 Amazon EC2 Auto Scaling에 대한 걱정 없이 인스턴스를 중지 및 시작하거나 재부팅할 수 있습니다.
예컨대, 시작 템플릿 또는 시작 구성을 변경하여 Auto Scaling 그룹의 Amazon Machine Image(AMI)를 언제든 변경할 수 있습니다. Auto Scaling 그룹이 시작하는 모든 후속 인스턴스가 이 AMI를 사용합니다. 그러나 Auto Scaling 그룹은 현재 서비스 중인 인스턴스를 업데이트하지 않습니다. 이러한 인스턴스를 해지하고 Amazon EC2 Auto Scaling이 인스턴스를 교체하도록 하거나 인스턴스 새로 고침 기능을 사용하여 인스턴스를 해지하고 교체할 수 있습니다. 또는 인스턴스 상태를 대기로 설정하고 소프트웨어를 업데이트한 후 인스턴스를 다시 서비스 상태로 설정할 수 있습니다.
Auto Scaling 그룹에서 인스턴스를 분리하는 것은 인스턴스를 대기 상태로 전환하는 것과 유사합니다. 인스턴스를 다른 그룹에 연결하거나 독립 실행형 EC2 인스턴스와 같은 인스턴스를 관리하고 종료하려는 경우, 인스턴스 분리가 유용할 수 있습니다. 자세한 내용은 [Auto Scaling 그룹에서 인스턴스 분리 또는 연결](ec2-auto-scaling-detach-attach-instances.md) 단원을 참조하십시오.
**Topics**
+ [대기 상태를 작동하는 방법](#standby-state)
+ [고려 사항](#standby-instance-considerations)
+ [대기 상태의 인스턴스 상태](#standby-instance-health-status)
+ [인스턴스를 대기 상태로 설정하여 임시로 제거](#standby-state)
## 대기 상태를 작동하는 방법
대기 상태는 Auto Scaling 그룹에서 인스턴스를 일시적으로 제거할 수 있도록 다음과 같이 작동합니다.
1. 인스턴스를 대기 상태에 놓습니다. 인스턴스는 대기 상태를 끝낼 때까지 이 상태로 유지됩니다.
1. Auto Scaling 그룹에 연결된 로드 밸런서 대상 그룹 또는 Classic Load Balancer가 있는 경우, 로드 밸런서에서 해당 인스턴스가 등록 취소됩니다. 로드 밸런서에 대해 Connection Draining이 활성화된 경우, Elastic Load Balancing은 등록 취소 프로세스를 완료하기 전에 300초 동안 대기하는데, 이는 진행 중인 요청을 완료하는 데 도움이 될 수 있습니다.
1. 인스턴스를 업데이트하거나 문제를 해결할 수 있습니다.
1. 대기 상태를 끝내 인스턴스를 서비스 상태로 되돌립니다.
1. Auto Scaling 그룹에 연결된 로드 밸런서 대상 그룹 또는 Classic Load Balancer가 있는 경우, 로드 밸런서에 해당 인스턴스가 등록됩니다.
Auto Scaling 그룹에서 인스턴스의 수명 주기에 대한 자세한 설명은 [Amazon EC2 Auto Scaling 인스턴스 수명 주기](ec2-auto-scaling-lifecycle.md) 섹션을 참조하세요.
## 고려 사항
인스턴스를 대기 상태로 전환하거나 대기 상태에서 벗어날 때 고려할 사항은 다음과 같습니다.
+ 인스턴스를 대기 상태로 설정할 때 이 작업을 통해 원하는 용량을 줄이거나 동일한 값을 유지할 수 있습니다.
+ Auto Scaling 그룹의 원하는 용량을 줄이지 않기로 선택하면 Amazon EC2 Auto Scaling이 인스턴스를 시작하여 대기 중인 인스턴스를 교체합니다. 하나 이상의 인스턴스가 대기 상태에 있는 동안 애플리케이션의 용량을 유지하기 위해서입니다.
+ Auto Scaling 그룹의 원하는 용량을 점감하도록 선택하면 대기 중인 인스턴스를 교체할 인스턴스가 시작되지 않습니다.
+ 인스턴스를 다시 서비스하면 Auto Scaling 그룹에 있는 인스턴스 수를 반영하여 원하는 용량이 증가합니다.
+ 증가(및 감소)를 수행하려면 새로 원하는 용량이 최소 그룹 크기와 최대 그룹 크기 사이여야 합니다. 그렇지 않은 경우, 작업이 실패합니다.
+ 인스턴스를 대기 상태로 설정하거나 대기 상태를 해지하여 인스턴스를 서비스로 복귀한 후 언제든지 Auto Scaling 그룹이 가용 영역 간에 균형이 맞지 않는 것으로 확인되면, `AZRebalance` 프로세스를 일시 중단하지 않는 한 Amazon EC2 Auto Scaling은 가용 영역의 균형을 재조정하여 이를 보완합니다. 자세한 설명은 [Amazon EC2 Auto Scaling 프로세스 일시 중지 및 재개](as-suspend-resume-processes.md) 섹션을 참조하세요.
+ 대기 상태의 인스턴스에 대해 요금이 청구됩니다.
## 대기 상태의 인스턴스 상태
Amazon EC2 Auto Scaling은 대기 상태의 인스턴스에 대한 건전성 체크를 수행하지 않습니다. 인스턴스가 대기 상태에 있는 동안 이 인스턴스의 상태는 대기 상태로 설정되기 전의 상태를 반영합니다. 스턴스를 서비스 상태로 설정할 때까지 Amazon EC2 Auto Scaling은 해당 인스턴스에 대한 건전성 체크를 수행하지 않습니다.
예컨대, 정상인 인스턴스를 대기 상태로 설정한 후 해지하면 Amazon EC2 Auto Scaling은 해당 인스턴스를 정상으로 계속 보고합니다. 대기 상태에 있던 해지된 인스턴스를 다시 서비스 상태로 전환하려면, Amazon EC2 Auto Scaling는 인스턴스에 대한 건전성 체크를 수행하고, 인스턴스가 해지 중이거나 건전하지 않은 것으로 판단되면 교체 인스턴스를 시작합니다. 자세한 내용은 [Auto Scaling 그룹의 인스턴스에 대한 상태 확인](ec2-auto-scaling-health-checks.md) 단원을 참조하십시오.
## 인스턴스를 대기 상태로 설정하여 임시로 제거
다음 절차 중 하나를 사용하여 인스턴스를 대기 상태로 전환함으로써 일시적으로 서비스를 중단합니다.
------
#### [ Console ]
**인스턴스를 일시적으로 제거하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
페이지 하단에 분할 창이 열립니다.
1. **인스턴스 관리(Instance management)** 탭의 **인스턴스(Instances)**에서 인스턴스를 선택합니다.
1. **작업(Actions)**, **대기로 설정(Set to Standby)**을 선택합니다.
1. 교체 인스턴스를 시작시키려면 **대기로 설정** 대화상자에서 **인스턴스 교체** 체크박스를 선택된 대로 유지하십시오. 원하는 용량을 줄이려면 확인란을 선택 취소합니다.
1. 확인 메시지가 표시되면 **standby**를 입력하여 지정된 인스턴스를 `Standby` 상태로 설정하는 것을 확인한 다음 **대기 상태로 설정**을 선택합니다.
1. 필요에 따라 인스턴스를 업데이트하거나 문제 해결할 수 있습니다. 모두 마쳤으면 다음 단계를 계속하여 인스턴스를 서비스 상태로 되돌립니다.
1. 인스턴스를 선택하고 **작업(Actions)**, **대기로 설정(Set to Standby)**을 선택합니다. **서비스 중으로 설정(Set to InService)** 대화 상자에서 **서비스 중으로 설정(Set to InService)**을 선택합니다.
------
#### [ AWS CLI ]
Auto Scaling 그룹에서 인스턴스를 일시적으로 제거하려면 다음 예제 명령을 사용합니다. *user input placeholder*를 사용자의 정보로 바꿉니다.
**인스턴스를 일시적으로 제거하려면**
1. [describe-auto-scaling-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-instances.html) 명령을 사용하여 업데이트할 인스턴스를 식별합니다.
```
aws autoscaling describe-auto-scaling-instances \
--query 'AutoScalingInstances[?AutoScalingGroupName==`my-asg`]'
```
다음 예제에서는 이 명령을 실행할 때 생성되는 출력을 보여줍니다.
그룹에서 제거하려는 인스턴스의 ID를 기록해 둡니다. 다음 단계에서 이 ID가 필요합니다.
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceId": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
...
]
}
```
1. [enter-standby](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/enter-standby.html) 명령을 사용하여 인스턴스를 `Standby` 상태로 이동합니다. `--should-decrement-desired-capacity` 옵션을 사용하면 원하는 용량을 줄이므로 Auto Scaling 그룹에서는 교체 인스턴스를 시작하지 않습니다.
```
aws autoscaling enter-standby --instance-ids i-05b4f7d5be44822a6 \
--auto-scaling-group-name my-asg --should-decrement-desired-capacity
```
다음은 응답의 예입니다.
```
{
"Activities": [
{
"ActivityId": "3b1839fe-24b0-40d9-80ae-bcd883c2be32",
"AutoScalingGroupName": "my-asg",
"Description": "Moving EC2 instance to Standby: i-05b4f7d5be44822a6",
"Cause": "At 2023-12-15T21:31:26Z instance i-05b4f7d5be44822a6 was moved to standby
in response to a user request, shrinking the capacity from 4 to 3.",
"StartTime": "2023-12-15T21:31:26.150Z",
"StatusCode": "InProgress",
"Progress": 50,
"Details": "{\"Subnet ID\":\"subnet-c934b782\",\"Availability Zone\":\"us-west-2a\"}"
}
]
}
```
1. (옵션) [describe-auto-scaling-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-instances.html) 명령을 사용하여 인스턴스가 `Standby`에 있는지 확인합니다.
```
aws autoscaling describe-auto-scaling-instances --instance-ids i-05b4f7d5be44822a6
```
다음은 응답의 예입니다. 인스턴스가 현재 `Standby` 상태임을 확인할 수 있습니다.
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "Standby"
},
...
]
}
```
1. 필요에 따라 인스턴스를 업데이트하거나 문제 해결할 수 있습니다. 모두 마쳤으면 다음 단계를 계속하여 인스턴스를 서비스 상태로 되돌립니다.
1. 다음 [exit-standby](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/exit-standby.html) 명령을 사용하여 인스턴스를 다시 서비스 상태로 설정합니다.
```
aws autoscaling exit-standby --instance-ids i-05b4f7d5be44822a6 --auto-scaling-group-name my-asg
```
다음은 응답의 예입니다.
```
{
"Activities": [
{
"ActivityId": "db12b166-cdcc-4c54-8aac-08c5935f8389",
"AutoScalingGroupName": "my-asg",
"Description": "Moving EC2 instance out of Standby: i-05b4f7d5be44822a6",
"Cause": "At 2023-12-15T21:46:14Z instance i-05b4f7d5be44822a6 was moved out of standby in
response to a user request, increasing the capacity from 3 to 4.",
"StartTime": "2023-12-15T21:46:14.678Z",
"StatusCode": "PreInService",
"Progress": 30,
"Details": "{\"Subnet ID\":\"subnet-c934b782\",\"Availability Zone\":\"us-west-2a\"}"
}
]
}
```
1. (옵션) 다음 `describe-auto-scaling-instances` 명령을 사용하여 인스턴스가 다시 서비스 상태가 되었는지 확인합니다.
```
aws autoscaling describe-auto-scaling-instances --instance-ids i-05b4f7d5be44822a6
```
다음은 응답의 예입니다. 인스턴스의 상태가 `InService`입니다.
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
...
]
}
```
------
# Auto Scaling 인프라 삭제
조정 인프라를 완전히 삭제하려면 다음 작업을 완료하세요.
**Topics**
+ [Auto Scaling 그룹 삭제](#as-shutdown-lbs-delete-asg-cli)
+ [(옵션) 시작 구성 삭제](#as-shutdown-lbs-delete-lc-cli)
+ [(옵션) 시작 템플릿 삭제](#as-shutdown-lbs-delete-lt-cli)
+ [(옵션) 로드 밸런서 및 대상 그룹 삭제](#as-shutdown-lbs-delete-lbs-cli)
+ [(옵션) CloudWatch 경보 삭제](#as-shutdown-delete-alarms-cli)
+ [Amazon EC2 Auto Scaling 리소스에 대한 삭제 방지 구성](resource-deletion-protection.md)
## Auto Scaling 그룹 삭제
Auto Scaling 그룹을 삭제하면 원하는 값과 최소, 최대값이 0으로 설정됩니다. 그리고 인스턴스가 해지됩니다. 인스턴스를 삭제하면 연결된 로그 또는 데이터, 그리고 인스턴스의 모든 볼륨도 모두 삭제됩니다. 하나 이상의 인스턴스를 해지하지 않으려면 Auto Scaling 그룹을 삭제하기 전에 인스턴스를 분리할 수 있습니다. 그룹에 조정 정책이 있는 경우, 그룹을 삭제하면 정책, 기본 경보 작업 및 더 이상 연결된 작업이 없는 경보가 삭제됩니다.
**Auto Scaling 그룹을 삭제하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆에 있는 확인란을 선택하고 **조치**, **삭제**를 선택합니다.
1. 확인 메시지가 표시되면 **delete**를 입력하여 지정된 Auto Scaling 그룹 삭제를 확인한 다음 **Delete**(삭제)를 선택합니다.
**Name**(이름) 열의 로딩 아이콘은 Auto Scaling 그룹이 삭제 중임을 나타납니다. **원하는 수**, **최소** 및 **최대** 열에 Auto Scaling 그룹에 대한 인스턴스가 `0`으로 표시됩니다. 인스턴스를 해지하고 그룹을 삭제하는 데 몇 분 정도 걸립니다. 목록을 새로 고침하여 상태를 확인합니다.
**Auto Scaling 그룹을 삭제하려면(AWS CLI)**
다음 [delete-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-auto-scaling-group.html) 명령을 사용하여 Auto Scaling 그룹을 삭제합니다. 그룹에 EC2 인스턴스가 있는 경우에는 이 작업이 유효하지 않습니다. 인스턴스가 없는 그룹에만 유효합니다.
```
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name my-asg
```
그룹에 진행 중인 인스턴스 또는 크기 조정 활동이 있는 경우, [delete-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-auto-scaling-group.html) 명령을 `--force-delete` 옵션과 함께 사용합니다. 그러면 EC2 인스턴스도 해지됩니다. Amazon EC2 Auto Scaling 콘솔에서 Auto Scaling 그룹을 삭제하면 콘솔은 이 작업을 사용하여 EC2 인스턴스를 해지하는 동시에 그룹을 삭제합니다.
```
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name my-asg --force-delete
```
## (옵션) 시작 구성 삭제
나중에 시작 구성을 사용하려면 이 단계를 건너뛸 수 있습니다.
**시작 구성을 삭제하는 방법(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 왼쪽 탐색 창의 **Auto Scaling**에서 **Auto Scaling 그룹**을 선택합니다.
1. 페이지 상단에서 **시작 구성**을 선택합니다. 확인 메시지가 표시되면 **시작 구성 보기**를 선택하여 **시작 구성** 페이지를 볼 것인지 확인합니다.
1. 시작 구성을 선택한 다음 **조치**, **시작 구성 복사**를 선택합니다.
1. 확인 메시지가 나타나면 **삭제**를 선택합니다.
**시작 구성을 삭제하는 방법(AWS CLI)**
다음 [delete-launch-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-launch-configuration.html) 명령을 사용합니다.
```
aws autoscaling delete-launch-configuration --launch-configuration-name my-launch-config
```
## (옵션) 시작 템플릿 삭제
시작 템플릿 또는 시작 템플릿의 한 가지 버전만 삭제할 수 있습니다. 시작 템플릿을 삭제하면 모든 해당 버전이 삭제됩니다.
나중에 시작 템플릿을 사용하려면 이 단계를 건너뛸 수 있습니다.
**시작 템플릿을 삭제하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Instances**(인스턴스)에서 **Launch Templates**(시작 템플릿)을 선택합니다.
1. 시작 템플릿을 선택한 다음, 다음 중 하나를 수행하세요.
+ **Actions**(작업)와 **Delete template**(템플릿 삭제)을 차례로 선택합니다. 확인 메시지가 표시되면 **Delete**를 입력하여 지정된 시작 템플릿 삭제를 확인한 다음 **Delete**(삭제)를 선택합니다.
+ [**Actions**]와 [**Delete template version**]을 차례로 선택합니다. 삭제할 버전을 선택하고 **삭제**를 선택합니다.
**시작 템플릿(AWS CLI) 삭제**
[delete-launch-template](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-launch-template.html) 명령을 사용하여 템플릿과 모든 버전을 삭제합니다.
```
aws ec2 delete-launch-template --launch-template-id lt-068f72b72934aff71
```
또는 [delete-launch-template-versions](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-launch-template-versions.html) 명령을 사용하여 시작 템플릿의 특정 버전을 삭제할 수 있습니다.
```
aws ec2 delete-launch-template-versions --launch-template-id lt-068f72b72934aff71 --versions 1
```
## (옵션) 로드 밸런서 및 대상 그룹 삭제
Auto Scaling 그룹이 Elastic Load Balancing 로드 밸런서에 연결되지 않았거나 로드 밸런서를 나중에 사용하려면 이 단계를 건너뛰세요.
**로드 밸런서를 삭제하려면(콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서를 선택한 다음 **작업**, **삭제**를 선택합니다.
1. 확인 메시지가 나타나면 **예, 삭제합니다(Yes, Delete)**를 선택합니다.
**대상 그룹을 삭제하려면(콘솔)**
1. 탐색 창의 **Load Balancing** 아래에서 **대상 그룹**을 선택합니다.
1. 대상 그룹을 선택하고 [**Actions**], [**Delete**]를 차례로 선택합니다.
1. 확인 메시지가 나타나면 **예, 삭제합니다(Yes, Delete)**를 선택합니다.
**Auto Scaling 그룹과 연결된 로드 밸런서를 삭제하려면(AWS CLI)**
Application Load Balancers 및 Network Load Balancer의 경우, 다음 [delete-load-balancer](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/elbv2/delete-load-balancer.html) 및 [delete-target-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/elbv2/delete-target-group.html) 명령을 사용합니다.
```
aws elbv2 delete-load-balancer --load-balancer-arn my-load-balancer-arn
aws elbv2 delete-target-group --target-group-arn my-target-group-arn
```
Classic Load Balancer의 경우, [delete-load-balancer](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/elb/delete-load-balancer.html) 명령을 사용합니다.
```
aws elb delete-load-balancer --load-balancer-name my-load-balancer
```
## (옵션) CloudWatch 경보 삭제
Auto Scaling 그룹과 관련된 CloudWatch 경보를 삭제하려면 다음 단계를 완료하세요. 예컨대, 단계별 스케일링 또는 단순 스케일링 정책과 관련된 경보가 있을 수 있습니다.
**참고**
Auto Scaling 그룹을 삭제하면 대상 추적 조정 정책에 대해 Amazon EC2 Auto Scaling에서 관리하는 CloudWatch 경보가 자동으로 삭제됩니다.
Auto Scaling 그룹이 CloudWatch 경보와 연결되지 않았거나 나중에 경보를 사용하려면 이 단계를 건너뛸 수 있습니다.
**CloudWatch 경보를 삭제하려면(콘솔)**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **Alarms(경보)**를 선택합니다.
1. 경보를 선택하고 **작업**, **삭제**를 선택합니다.
1. 확인 메시지가 나타나면 **삭제**를 선택합니다.
**CloudWatch 경보를 삭제하려면(AWS CLI)**
[delete-alarms](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/delete-alarms.html) 명령을 사용합니다. 한 번에 하나 이상의 경보를 삭제할 수 있습니다. 예컨대, 다음 명령을 사용하여 `Step-Scaling-AlarmHigh-AddCapacity` 및 `Step-Scaling-AlarmLow-RemoveCapacity` 경보를 삭제합니다.
```
aws cloudwatch delete-alarms --alarm-name Step-Scaling-AlarmHigh-AddCapacity Step-Scaling-AlarmLow-RemoveCapacity
```
# Amazon EC2 Auto Scaling 리소스에 대한 삭제 방지 구성
여러 보호 계층을 구성하여 Amazon EC2 Auto Scaling 인프라가 실수로 삭제되지 않도록 보호합니다. Auto Scaling은 Auto Scaling 그룹과 Auto Scaling이 관리하는 Amazon EC2 인스턴스에 대한 원치 않는 리소스 삭제를 방지하기 위한 몇 가지 접근 방식을 제공합니다.
**Topics**
+ [Auto Scaling 그룹 삭제 보호 구성](#asg-deletion-protection)
+ [IAM 정책을 사용하여 삭제 권한 제어](#deletion-protection-iam-policies)
## Auto Scaling 그룹 삭제 보호 구성
삭제 방지는 Amazon EC2 Auto Scaling 그룹이 실수로 삭제되는 것을 방지하는 리소스 수준 설정입니다. 활성화되면 삭제 방지 기능은 [ DeleteAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DeleteAutoScalingGroup.html) API 작업이 성공하지 못하도록 차단하므로 Auto Scaling 그룹을 삭제하기 전에 먼저 삭제 방지 설정을 덜 제한적인 수준으로 업데이트해야 합니다.
Amazon EC2 Auto Scaling은 세 가지 수준의 삭제 보호를 제공합니다.
**없음**(기본값)
삭제 방지가 활성화되지 않았습니다. 즉, `ForceDelete` 옵션을 사용하거나 사용하지 않고 Auto Scaling 그룹을 삭제할 수 있습니다. `ForceDelete`를 사용하면 Auto Scaling 그룹에서 관리하는 모든 Amazon EC2 인스턴스도 종료 수명 주기 후크를 실행하지 않고 강제로 종료됩니다.
**강제 삭제 방지**
`ForceDelete` 옵션을 사용할 때는 Auto Scaling 그룹을 삭제할 수 없습니다. 이 구성을 사용하면 빈 Auto Scaling 그룹(인스턴스가 없는 그룹)을 삭제할 수 있습니다. 이 옵션은 대량 인스턴스 종료를 방지하지만 빈 그룹을 정리할 수 있는 프로덕션 워크로드에 권장됩니다.
**모든 삭제 방지**
Auto Scaling 그룹은 `ForceDelete` 옵션 사용 여부에 관계없이 삭제할 수 없습니다. 이 옵션은 우발적 삭제로부터 가장 강력한 보호를 제공합니다. Auto Scaling 그룹을 삭제하려면 먼저 삭제 방지 기능을 명시적으로 비활성화해야 합니다. 이는 거의 또는 절대 삭제하지 않아야 하는 미션 크리티컬 Auto Scaling 그룹에 권장됩니다.
### 삭제 방지 작동 방식
삭제 방지가 활성화된 상태에서 [ DeleteAutoScalingGroup ](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DeleteAutoScalingGroup.html) API 작업을 시도하는 경우:
1. Amazon EC2 Auto Scaling은 요청을 처리하기 전에 삭제 방지 설정을 검증합니다.
1. 구성된 삭제 방지 수준이 삭제 시도를 차단하면 Amazon EC2 Auto Scaling은를 반환합니다`ValidationError`.
1. Auto Scaling 그룹과 해당 Amazon EC2 인스턴스는 변경되지 않습니다.
1. Auto Scaling 그룹을 삭제하려면 먼저 삭제 방지 설정을 덜 제한적인 수준으로 업데이트해야 합니다.
삭제 방지 기능은 다음과 같은 다른 작업을 방지하지 않습니다.
+ Auto Scaling 그룹 구성 업데이트.
+ 개별 인스턴스 종료.
+ 조정 작업(수동 또는 자동).
+ 프로세스를 일시 중지하거나 재개합니다.
인스턴스 종료를 정상적으로 처리하는 방법에 대한 자세한 내용은 섹션을 참조하세요[인스턴스 종료를 원활하게 처리할 수 있도록 애플리케이션 설계](gracefully-handle-instance-termination.md).
### 삭제 방지 구성
Auto Scaling 그룹을 생성하거나 기존 Auto Scaling 그룹의 설정을 업데이트할 때 삭제 방지를 설정할 수 있습니다.
------
#### [ Console ]
**삭제 방지 기능을 사용하여 Auto Scaling 그룹을 생성하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. **Create Auto Scaling group**(Auto Scaling 그룹 생성)을 선택합니다.
1. Auto Scaling 그룹의 구성 단계를 완료합니다.
1. **그룹 크기 및 크기 조정 구성** 페이지에서 **추가 설정을** 확장합니다.
1. **Auto Scaling 그룹 삭제 보호**에서 원하는 보호 수준을 선택합니다.
+ **없음** - 삭제 방지 없음(기본값)
+ **강제 삭제 방지** - 강제 삭제 작업 차단
+ **모든 삭제 방지** - 모든 삭제 작업 차단
1. 나머지 단계를 완료하여 Auto Scaling 그룹을 생성합니다.
**기존 Auto Scaling 그룹에서 삭제 방지를 업데이트하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling 그룹(Auto Scaling Groups)**을 선택합니다.
1. Auto Scaling 그룹 옆의 확인란을 선택합니다.
1. **작업(Actions)**, **편집(Edit)**을 선택합니다.
1. **추가 설정**에서 **Auto Scaling 그룹 삭제 보호** 설정을 업데이트합니다.
1. **업데이트**를 선택합니다.
------
#### [ AWS CLI ]
**삭제 방지 기능을 사용하여 Auto Scaling 그룹을 생성하려면**
[create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) 명령을 `--deletion-protection` 파라미터와 함께 사용합니다.
```
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-asg \
--launch-template LaunchTemplateName=my-template,Version='$Latest' \
--min-size 1 \
--max-size 5 \
--desired-capacity 2 \
--vpc-zone-identifier "subnet-12345678,subnet-87654321" \
--deletion-protection prevent-force-deletion
```
에 유효한 값은 \$1 `none` `prevent-force-deletion` \$1`--deletion-protection`입니다. `prevent-all-deletion`
**기존 Auto Scaling 그룹에서 삭제 방지를 업데이트하려면**
[update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) 명령을 사용합니다.
```
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name my-asg \
--deletion-protection prevent-all-deletion
```
**삭제 방지를 비활성화하려면**
삭제 방지를 로 설정합니다`none`.
```
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name my-asg \
--deletion-protection none
```
**삭제 방지 상태를 확인하려면**
[describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 명령을 사용합니다.
```
aws autoscaling describe-auto-scaling-groups \
--auto-scaling-group-names my-asg
```
------
## IAM 정책을 사용하여 삭제 권한 제어
AWS Identity and Access Management (IAM) 정책을 사용하여 Auto Scaling 그룹을 삭제할 수 있는 사용자 및 역할을 제어합니다. IAM 기반 제어는 자격 증명 수준에서 권한을 제한하여 추가 보안 계층을 제공합니다.
IAM 정책은 다음과 같은 경우에 특히 유용합니다.
+ 사용자마다 Auto Scaling 작업에 대한 다양한 수준의 액세스를 허용합니다.
+ 특정 사용자가 다른 Auto Scaling 작업을 수행할 수 있더라도 `ForceDelete` 옵션을 사용하지 못하도록 합니다.
+ 삭제 권한을 특정 Auto Scaling 그룹으로 제한합니다.
다음 정책은 그룹에 `environment=development` 태그가 있는 경우에만 Auto Scaling 그룹의 삭제를 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "autoscaling:DeleteAutoScalingGroup",
"Resource": "*",
"Condition": {
"StringEquals": { "aws:ResourceTag/environment": "development" }
}
}]
}
```
------
다음 정책은 `autoscaling:ForceDelete` 조건 키를 사용하여 `DeleteAutoScalingGroup` API 작업에 대한 액세스를 제어합니다. 이렇게 하면 특정 사용자가 Auto Scaling 그룹 내의 모든 Amazon EC2 인스턴스를 종료하는 `ForceDelete` 작업을 사용하지 못할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "autoscaling:DeleteAutoScalingGroup",
"Resource": "*",
"Condition": {
"Bool": {
"autoscaling:ForceDelete": "true"
}
}
}]
}
```
------
또는 조건 키를 사용하여 Auto Scaling 그룹에 대한 액세스를 제어하고 있지 않은 경우, `Resource` 요소에서 리소스의 ARN을 지정하여 대신 액세스를 제어할 수 있습니다.
다음 정책은 사용자에게 `DeleteAutoScalingGroup` API 작업을 사용할 수 있는 권한을 부여하지만 이름이 로 시작하는 Auto Scaling 그룹에만 적용됩니다`devteam-`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "autoscaling:DeleteAutoScalingGroup",
"Resource": "arn:aws:autoscaling:us-east-1:111122223333:autoScalingGroup:*:autoScalingGroupName/devteam-*"
}
]
}
```
------
여러 ARN을 목록에 포함시켜 지정할 수도 있습니다. UUID를 포함하면 특정 Auto Scaling 그룹에 대한 액세스 권한을 부여할 수 있습니다. 새 그룹의 UUID는 이름이 같은 삭제된 그룹의 UUID와 다릅니다.
```
"Resource": [
"arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-1",
"arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-2",
"arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-3"
]
```
삭제 권한을 제어하는 정책을 포함하여 Amazon EC2 Auto Scaling에 대한 IAM 정책의 추가 예는 섹션을 참조하세요[ID 기반 정책 예시](security_iam_id-based-policy-examples.md).