[AWS] EC2 인스턴스 자동 중지 및 시작하기

[AWS] EC2 인스턴스 자동 중지 및 시작하기 - Quick Setup 활용DevOps/클라우드2024. 11. 23. 20:55@Chanos

Table of Contents

AWS와 같은 퍼블릭 클라우드를 사용할 때, 가장 중요한 것은 비용 관리입니다.

많은 사용자가 활용하는 EC2 인스턴스는 중지되면 비용이 부과되지 않는데요. 이를 편리하게 관리하기 위해 자동화하는 것을 다뤄보겠습니다.

기본적으로 AWS EC2는 ~~온디맨드~~ 요금제를 채택하고 있습니다. 온디맨드 요금제는 사용한 만큼 비용을 지불하는 방식인데요. (자료: EC2 요금제)

인스턴스가 중지되면 인스턴스에 대한 비용이 부과되지 않습니다. 물론 함께 사용하는 Elastic IP, 볼륨 스토리지 등에 대한 비용은 계속 청구됩니다.

사용하지 않을 때 인스턴스를 중지시키면 운영 비용을 최소화할 수 있습니다.

하지만, 사람이 일일이 하다 보면 까먹기 마련이지요. 인스턴스의 개수가 많아지면 24시간 돌아야 하는 인스턴스도 만들어지기도 합니다.

결국 시간이 지날수록 관리의 복잡도가 점점 증가합니다. 이 때, 조건에 맞춰 자동으로 동작하는 기능이 있다면 인스턴스 편하게 관리할 수 있습니다.

이러한 기능을 구현하는 것은 크게 두 가지 방법이 있습니다.

AWS에서 제공하는 Quick Setup 기능 활용
Lambda, EventBridge, CloudWatch를 활용하여 직접 구현

람다는 구현에 따라 좀 다르겠지만, 일반적으로 두 방식 모두 인스턴스의 태그에 지정된 값에 따라 동작하는 방식은 동일합니다.

인스턴스의 태그에 특정 Key-Value 값이 존재한다면 관리 대상으로 인식하고 인스턴스의 상태를 변경하는 것이지요.

단순히 일정에 맞춰 운영한다면 Quick Setup으로 간단히 설정할 수 있습니다.

기능/상황에 따라 입맛대로 운영하고 싶다면 Lambda를 중심으로 직접 구현하는 방식을 채택하는 것이 유리합니다.

대부분 Lambda로 직접 구현하는 것 같습니다만.. 이번 기회에 두 방법 모두 정리해보도록 하겠습니다.

저는 EC2 인스턴스를 조건에 맞춰 자동으로 시작/중지 하는 기능을 ~~Auto Runner~~라고 부르기로 했습니다.

이번 포스팅에서는 Quick Setup을 활용해 Auto Runner를 구현하는 과정을 정리해 보고, 다음 포스팅에서 Lambda로 직접 구현해보겠습니다.

AWS Systems Manager와 Quick Setup

🔸 AWS Systems Manager란?

이번 포스팅에서 활용할 Quick Setup은 AWS Systems Manager라는 솔루션에서 제공하는 기능 중 하나입니다.

Systems Manager는 클라우드 리소스 관리를 단순화하는 솔루션입니다.

다양한 리소스를 Systems Manager에 모아놓고 중앙 집중식으로 관리하는 것이지요.

~~SSM(Systems Manager Agent)~~를 통해 SSH와 같이 따로 연결하지 않고 리소스를 관리할 수 있습니다.

퍼블릭 클라우드에서 인프라를 설정하다 보면 사용하는 리소스가 다양해지는데요. 이렇게 복잡한 리소스를 운영하는데 도움을 줍니다.

운영을 자동화하거나 보안/규정 관리를 하는 등 다양한 기능을 제공하며, 대시보드를 통해 여러 지표를 확인할 수 있습니다.

다른 솔루션과 통합해서 활용할 수도 있는데요. CloudWatch와 통합해서 로그나 메트릭을 수집할 수도 있습니다.

EC2 인스턴스도 리소스 중 하나기 때문에, 인스턴스 상태를 변경하는 명령을 내릴 수 있는 것입니다.

🔸 Quick Setup의 특징

Quick Setup은 AWS Systems Manager의 기능 중 하나로, AWS에서 무료로 제공하고 있습니다.

설정한 일정에 맞춰 동작하며, 특정 리전에서 한 구성 당 최대 5,000개의 인스턴스를 지원하고 있습니다.

구성은 어렵지 않으니, 기능을 활용하기 위한 동작 방식 몇 가지만 확인해 보도록 하겠습니다.

1. 구성을 여러 개 한 경우 태그 값 분리

구성을 여러 개 했다면, 각 구성은 서로 다른 태그 값을 지정해야 합니다.

아마도 일관된 동작을 위해서 구성마다 태그 값을 구분하는 방식을 사용하는 것으로 생각됩니다.

예시: 관리하는 인스턴스가 5,000개가 넘어간 상황

키가 Env인 태그를 설정했다면, Value는 한 구성에는 "Dev", 다른 구성에는 "Test"라는 값을 사용할 수 있습니다.

둘이 동일하게 쓰면 안되고, 구분이 되어야 합니다.

2. 인스턴스 상태 변경

인스턴스가 ~~stopped(중지됨)~~ 상태인 경우에만 인스턴스를 시작합니다. 반대로, ~~running(실행 중)~~ 상태인 경우에만 인스턴스가 중지됩니다.

즉, 인스턴스를 막 생성해 초기화하는 ~~pending~~, 콘솔에서 인스턴스를 중지해 ~~stopping(중지 중)이면~~ Quick Setup에 의해 동작하지 않습니다.

3. 동작 시간

종료 시간이 시작 시간보다 빠르면, 시작은 다음 날에 동작하게 됩니다. 즉 하룻밤 내내 동작하는 것입니다.

당연하다고 생각할 수 있는데, 이 경우엔 종료 시간이 다음 날로 넘어간다는 것을 명시하는 것입니다.

예시: 인스턴스 시작 시간이 21시, 종료 시간이 09시로 설정되어 있다.

13시에 인스턴스를 생성했다면, 익일 09시까지 인스턴스는 계속 동작한다.

공식 문서에 정리가 잘 되어 있으니, 해당 기능을 활용하기 전에 읽어보시면 좋을 것 같습니다. (참고 문서)

Quick Setup으로 구현하기

🔸 Resource Scheduler 설정 생성

일정에 맞게 인스턴스 상태를 변경하기 위해 Quick Setup을 활용한다면, 먼저 Scheduler Configuration을 생성해야 합니다.

먼저, AWS 콘솔로 접속하셔서 AWS Systems Manager를 검색해 이동하신 다음, 탐색 창에서 ~~빠른 설정(Quick Setup)~~으로 이동합니다.

빠른 설정으로 이동하면 카드 형태의 여러 가지 메뉴가 보이실 텐데요.

하단의 ~~Resource Scheduler~~에서 ~~Create~~를 선택하시면 됩니다.

그럼, Resource Scheduler의 설정을 생성하는 메뉴로 이동하실 수 있습니다.

여기서 본인이 원하는 대로 설정하시면, 그 외에 필요한 것은 자동으로 생성이 됩니다.

첫 번째로 해당 설정이 적용될 ~~태그 값~~을 설정해주셔야 합니다.

이 일정이 적용될 인스턴스는 여기서 설정된 태그 값을 반드시 가지고 있어야 합니다.

저는 AutoRunnerEnabled라는 키 값이 True이면 이 일정을 사용하는 것으로 결정했습니다.

태그에 이 Key-Value가 저장되어 있는 인스턴스는 지정한 시간에 맞게 상태가 변경되겠지요.

다음으로 일정을 설정해야 합니다. 여기서 설정한 요일, 시간에 맞게 상태가 변경되는 것입니다.

일정의 Timezone, 요일, 시작 시간, 종료 시간을 차례대로 설정합니다.

아무래도 리전의 시간대와 일치하는 것이 운영할 때 조금 더 편리하겠지요.

다음은 대상이 될 대상(target)을 선택합니다. 어느 리전에 속한 인스턴스를 대상으로 동작할 것인지 지정하는 것입니다.

이 글을 보시는 대부분은 서울 리전에서 운영하실 테니, ap-northeast-2로 설정하면 되겠지요.

우측 상단에서 현재 콘솔에서 어떤 리전을 보고 있는지 확인하시고, 서울이라면 Current Region을 선택하셔도 무방합니다.

다음으로 ~~역할(role)~~을 설정할 차례입니다.

여기서 설정하는 역할은 스케줄러가 리소스(Ex. EC2 인스턴스) 등을 제어할 때 가지는 권한입니다.

필요한 권한을 자동으로 생성해도 되고, 생성해 놓은 role을 사용해도 됩니다.

제가 생성한 역할은 ~~AWSQuickSetupDeploymentRolePolicy~~ 정책을 갖고 있습니다.

그리고 Cloudformation과 특정 리소스에 대한 접근을 위해 신뢰 관계를 설정했습니다.

중요한 것은 동작하는데 필요한 정책과 신뢰 관계가 제대로 설정되어야 한다는 것인데요.

관련 권한을 표로 정리하면 다음과 같습니다.

솔루션	필요 권한	비고
CloudFormation	cloudformation:CreateStack cloudformation:UpdateStack cloudformation:DescribeStacks	Quick Setup의 로컬 구성 작업을 수행 Event Bridge 규칙 생성
SSM	ssm:CreateDocument ssm:SendCommand ssm:ListCommands ssm:GetCommandInvocation ssm:DescribeInstanceInformation	SSM Agent를 통해 관리 명령 실행 로컬 리소스 모니터링 및 로그 수집
EC2	ec2:DescribeInstances ec2:StartInstances ec2:StopInstances	EC2 인스턴스 상태 변경

이 외에도, 추가적인 로그를 기록한다면 Cloud Watch에서 로그를 생성하는 권한을 추가하시면 됩니다.

마지막으로 부가적인 설명을 작성해 주시면 끝입니다. 동작에 영향을 주진 않고, 콘솔에서 확인할 수 있는 값입니다.

필수는 아니지만, 관리할 때 편리하니 적당히 작성해주시면 됩니다.

이렇게 작성해주시면 필요한 설정은 모두 끝입니다.

마지막 하단에서 제대로 설정되었는지 요약을 확인하고 생성하시면 됩니다.

일정 시간 대기하면 콘솔에서 생성된 설정을 확인하실 수 있습니다.

설정된 내용과 통계 자료를 확인하실 수 있습니다.

테스트를 위해 값을 살짝 조절하고 인스턴스 상태를 확인해 보면 다음과 같이 정상 동작하는 것을 확인하실 수 있습니다.

🔸 이벤트와 관련한 로그 기록하기

Quick Setup은 ~~Event Bridge~~에서 이벤트를 전달하는 방식으로 동작합니다. 지정한 시간이 되면 규칙의 대상에게 전달되는 것이지요.

그래서 Event Bridge의 규칙을 가보시면 자동으로 생성된 규칙을 확인하실 수 있습니다.

이렇게 자동으로 동작하는 기능들은 편리하지만, 문제가 생겼을 때 추적하기 힘들다는 단점이 있습니다.

트러블 슈팅을 쉽게 하려면 이벤트 처리에 따른 로그를 기록하는 것이 상당히 중요한데요.

따로 설정을 하지 않아도, 인스턴스의 상태 변화는 AWS의 ~~CloudTrail~~에 기록되어 있습니다.

이벤트 레코드를 통해서 어떤 이벤트가 처리되었는지 자세히 확인할 수 있습니다.

일반적으로 AWS에서 클라우드와 관련된 로그는 ~~CloudWatch~~로 관리하는데요.

Quick Setup으로 설정한 이벤트도 똑같이 처리하기를 원한다면, 생성된 규칙에 권한을 부여하고 대상을 연결해 주면 됩니다.

권한은 콘솔에서 지정해도 되고, 하단의 Cloud Shell을 활용해서 CLI로 편하게 추가할 수도 있습니다.

aws events put-targets \
--rule <RuleName> \
--targets '[
	{
		"Id": "CloudWatchLogs",
		"Arn": "arn:aws:logs:<Region>:<AccountID>:log-group:<LogGroupName>"
	}
]'

정상적으로 추가가 되었다면, 규칙의 대상에 CloudWatch가 추가된 것을 보실 수 있습니다.