AWS 인스턴스 스케줄러 : 자동화로 클라우드 비용 절감하기

클라우드 환경에서는 모든 인스턴스를 항상 실행할 필요가 없습니다. 특히 개발이나 테스트 환경처럼 특정 시간에만 필요한 인스턴스는 효율적으로 관리할 필요가 있습니다.

이를 AWS의 서비스를 이용해서 관리할 수 있도록 구성해 주는 AWS Instance Scheduler (이하 인스턴스 스케줄러)가 있습니다.

이 글은 인스턴스 스케줄러에 대해서 실무에서 사용할 수 있는 방법이나 한계점에 대해서 설명합니다.

인스턴스 스케줄러를 도입함으로써 얻을 수 있는 효과와 함께, 실제 운영 환경에서 고려해야 할 부분들까지 함께 살펴보겠습니다.

보다 효율적인 클라우드 자원 관리를 위해 인스턴스 스케줄러가 어떤 역할을 할 수 있는지 알아보겠습니다.

AWS Instance Scheduler 개요

AWS Instance Scheduler 란?

AWS Instance Scheduler는 특정 시간에 EC2, RDS, AutoScalingGroup 등의 AWS 리소스를 스케줄링을 통해 자동으로 시작 및 중지할 수 있도록 해주는 AWS 설루션입니다.

인스턴스 스케줄러를 적절하게 적용한다면 다음과 같은 이점을 가질 수 있습니다.

첫째, 24/7으로 실행할 필요가 없는 인스턴스를 자동으로 관리함으로써 비용을 절감할 수 있습니다. 항상 켜져 있을 필요가 없는 자원을 자동으로 중지하거나 시작하여 불필요한 과금을 방지합니다.

둘째, 인스턴스를 수동으로 시작하거나 중지해야 하는 번거로움을 줄여 운영 효율성이 향상됩니다. 관리자는 반복적인 작업에서 벗어나 더 중요한 업무에 집중할 수 있습니다.

셋째, 개발이나 테스트 환경처럼 특정 시간에만 필요한 인스턴스를 효율적으로 운영할 수 있습니다. 예를 들어 업무 시간 동안만 실행되도록 설정하여 자원을 합리적으로 활용할 수 있습니다.

주요 기능 및 특징

Cloud Formation을 사용한 간단한 배포 방식
- Cloud Formation template 배포로 모든 구성 컴포넌트를 구성할 수 있습니다.
스케줄링 기반 인스턴스 시작 및 중지
- EventBridge Rule을 이용하여 사용자가 구성한 간격으로 이벤트를 발생시킵니다.
태그 기반으로 리소스 식별
- 리소스에 정의한 태그를 기반으로 시작과 중지할 리소스를 식별합니다.
- 태그키 값으로 스케줄러 적용 여부를 식별하고, 태그값으로 선언된 스케줄러를 선택합니다.
교차 계정 권한 취득 방식으로 중앙 집중 관리 가능
- 구성하는 방식에 따라 인스턴스 스케줄러를 관리 및 실행하는 계정(Hub Account)에서 권한을 취득하여 리소스를 소유한 계정 (Spoke Account)의 리소스를 제어하여 다수의 계정에 대한 중앙 관리가 가능합니다.

Instance Scheduler 구성

위 인프라 아키텍처는 CloudFormation을 이용하여 배포된 AWS Instance Scheduler의 전체 구성도를 보여줍니다. 이 구성은 여러 AWS 서비스들이 유기적으로 결합되어 동작하는 구조로 이루어져 있으며, 각각의 서비스는 인스턴스의 자동 시작과 중지를 위한 역할을 수행합니다.

핵심 구성요소는 다음과 같습니다.

AWS EventBridge Rule
- 사용자가 정의한 주기적인 스케줄에 따라 이벤트를 발생시키고, 이 이벤트는 인스턴스를 제어하는 Lambda 함수를 호출합니다.
AWS DynamoDB
- Config, Schedule, Period 등 스케줄링에 필요한 정보 저장합니다.
- Config, Schedule, Period 등 다양한 속성들을 포함하고 있어, 리소스를 언제 시작하고 중지할지 판단하는 기준이 됩니다.
AWS Lambda
- Config를 읽어 Scheduling 확인
- Spoke Account Assume Role
- Spoke Account 리소스 제어

이처럼 다양한 AWS 서비스가 결합된 인스턴스 스케줄러는 수동으로 각각의 구성 요소를 설치하고 설정하는 경우 복잡도가 매우 높습니다. 그러나 AWS의 인프라를 코드로 관리할 수 있는 도구인 CloudFormation을 사용하면, 이러한 구성 요소들을 템플릿 기반으로 손쉽게 배포하고 설정할 수 있습니다. 복잡한 절차 없이도 하나의 템플릿으로 전체 구성을 빠르게 완료할 수 있다는 점이 큰 장점입니다.

인스턴스 스케줄러 배포하기

AWS는 인스턴스 스케줄러를 위한 두 가지 CloudFormation 템플릿을 제공합니다. 아래 링크에서 공식 템플릿을 다운로드하거나 바로 실행할 수 있습니다. CloudFormation 템플릿 페이지 (AWS 공식 문서)

현재는 링크를 타고 들어가면 view template 버튼이 활성화되지 않습니다.

그렇기 때문에 아래 버튼을 눌러 나오는 pop-up에서 s3 url을 클릭해서 다운로드할 수 있습니다.

instance-scheduler-on-aws.template

이 템플릿은 인스턴스 스케줄러 전체 설루션을 설치할 때 사용하는 템플릿입니다.

앞에서 봤던 인스턴스 스케줄러를 구성하는 구성 요소가 설치됩니다.

환경에 따라 설정을 커스터마이징 할 수도 있습니다. 만약 교차 계정간 인스턴스 스케줄링을 수행하려는 경우 Hub 계정, 즉 인스턴스 스케줄러를 실행하고 관리할 계정에서 이 템플릿을 사용하여 배포합니다.

Cloud Formation을 통해서 template을 배포하는 순서는 아래와 같습니다. (아래에서 사용한 template의 버전은 v3.0.8입니다.)

템플릿 선택

템플릿을 통해 스택을 생성하면 템플릿을 통해 생성할 리소스에 필요한 파라미터를 세부 정보로 구성해야 합니다.

인스턴스 스케줄러의 파라미터는 크게 5가지 섹션으로 나뉘어 있습니다.

Scheduler

파라미터명

설명

Schedule tag key

해당 태그키는 인스턴스 스케줄러가 관리하는 리소스

Schedule interval

인스턴스 스케줄러를 실행하는 시간 간격

Default time zone

인스턴스 스케줄러가 실행되는 시간

Enable scheduling

스케줄링 사용 여부

Service

해당하는 서비스의 스케줄링 기능 활성화 여부를 설정합니다.

Tagging

스케줄러 실행/중지 후 리소스에 적용될 태그를 설정합니다.

Account Structure

파라미터명

설명

Use AWS Organizations

AWS 의 org 를 사용하여 계정 구성을 하는 경우 Yes 로 설정

Namespace

고유한 값으로 spoke 계정 사용시 동일한 ns 설정이 필요

Organization ID / Remote Account ID

org 를 사용하는 경우 org id / 아닌 경우 hub account id

Region

인스턴스 스케줄러를 실행할 region

Enable hub account scheduling

hub 계정의 스케줄링 설정 여부

Monitoring

해당 설정은 Instance Scheduler의 Monitoring 설정을 하는 부분입니다. 해당 부분에 대한 설정은 추가적인 비용을 발생시킬 수 있기 때문에 적절하게 설정이 필요합니다.

instance-scheduler-on-aws-remote.template

이 템플릿은 Hub-Spoke 구조로 인스턴스 스케줄러를 사용하는 경우 사용하는 템플릿입니다.

해당 템플릿을 사용하여 Spoke 계정, 즉 인스턴스를 실제로 소유하고 있는 계정에서 역할을 생성하여 Assume Role을 통해 사용합니다. 해당 역할을 통해 Hub 계정이 Spoke 계정의 리소스를 제어할 수 있습니다. 이는 Hub-Spoke 구조로 설정된 인스턴스 스케줄러에서 사용 가능합니다.

AWS Organizations를 사용하는 경우, 이 템플릿을 배포하면 Spoke 계정이 자동으로 Hub에 등록되어 별도의 수동 설정이 필요 없습니다.

Cloud Formation을 통해 remote template을 배포하는 순서는 아래와 같습니다.

템플릿 선택

파라미터

remote template 을 사용하는 경우 설정해야 하는 parameter는 다음과 같다.

파라미터

설명

Hub Account ID

Hub 계정의 ID

Use AWS Organization

Hub-Spoke 에서 Organization 을 사용하는 경우 사용

Namespace

Hub 계정에 설정한 namespace 와 동일하게 설정

인스턴스 스케줄러의 두 가지 사용 방식

AWS Instance Scheduler는 환경에 따라 두 가지 방식으로 사용할 수 있습니다. 하나는 인스턴스 스케줄러가 배포된 단일 계정 내에서 직접 사용하는 방식이며, 다른 하나는 여러 계정을 중앙에서 제어하는 Hub - Spoke 구조로 사용하는 방식입니다.

인스턴스 스케줄러가 배포된 계정에서 사용하기

가장 기본적인 사용 방식은 인스턴스 스케줄러가 배포된 계정 안에서 해당 계정의 인스턴스만 제어하는 방식입니다.

이 방식에서는 instance-scheduler-on-aws.template을 사용하여 스케줄러를 설치합니다. 설치 후, 같은 계정 내의 인스턴스들에 특정 태그를 설정하면, 스케줄러가 해당 태그를 기준으로 인스턴스를 자동으로 시작하거나 중지합니다.

Hub - Spoke 구조로 사용하기

여러 계정을 통합적으로 운영하고 있다면, Hub - Spoke 구조로 인스턴스 스케줄러를 사용하는 것이 효율적입니다.

이 방식에서는 인스턴스 스케줄러를 배포하고 관리하는 계정을 Hub 계정, 실제로 인스턴스를 소유하고 있는 계정을 Spoke 계정이라 부릅니다.

Hub 계정에는 instance-scheduler-on-aws.template을 사용하여 스케줄러 전체 구성을 배포하고,
Spoke 계정에는 instance-scheduler-on-aws-remote.template을 배포하여 Hub 계정에서 Spoke 계정의 리소스를 제어할 수 있도록 역할(Role)을 위임합니다.

이때 Assume Role을 통한 권한 관리 방식이 사용됩니다.

Spoke 계정에는 IAM Role을 생성하고, Hub 계정(제어 계정)에서는 이 Role을 Assume Role 방식으로 사용하여 리소스 제어 권한을 획득합니다.
보안성을 높이기 위해, 이 Role에는 최소 권한 원칙(Least Privilege)을 적용하여 필요한 권한만 부여합니다.

아래는 이미지에 나타난 AWS Instance Scheduler의 작업 흐름을 단계별로 설명한 내용입니다.

Resource Tag for Scheduling (스케줄링을 위한 리소스 태깅)
- Spoke 계정의 관리자가 EC2, RDS, ASG와 같은 리소스에 스케줄링 태그를 추가합니다. 이 태그는 리소스가 스케줄링 대상임을 나타내며, 스케줄링 정책(예: 시작/중지 시간)을 정의합니다.
- 예: Schedule: working-hours (평일 9시 시작, 18시 중지).
EventBridge 트리거 (스케줄링 이벤트 시작)
- Hub 계정의 EventBridge가 스케줄링 이벤트를 주기적으로 트리거합니다. 이는 미리 정의된 스케줄(예: 매 시간, 특정 시간)에 따라 발생합니다.
- 트리거는 1)의 리소스 태깅과는 별개로 설정된 시간마다 트리거 됩니다 (예를 들어, 15분마다, 1시간마다 등).
- EventBridge는 이벤트를 Orchestrator Lambda로 전달합니다.\
DynamoDB에서 스케줄링 설정 조회 (Remote Account IDs 조회)
- Orchestrator Lambda는 DynamoDB에서 스케줄링 설정과 대상 Spoke 계정의 계정 ID(Remote Account IDs)를 조회합니다.
- DynamoDB에는 Spoke 계정 목록, 스케줄링 정책, 리소스 태그 정보 등이 저장되어 있습니다.
Spoke 계정 리소스 스케줄링 람다 호출 (Call Handler Lambda)
- Orchestrator Lambda는 조회된 Spoke 계정 정보 등을 포함하여 Handler Lambda를 호출합니다.
  - Handler Lambda를 호출하는 기준은 Spoke 계정 수 * Region * service(EC2, RDS, ASG)입니다.
- 호출 시, Hub 계정은 Spoke 계정의 Scheduler-Role을 통해 리소스에 접근할 권한을 획득합니다.
Scheduler-Role 권한 취득 (Assume Role)
- Hub 계정의 Handler Lambda는 Spoke 계정의 Scheduler-Role(혹은 ASG Scheduling role)을 Assume Role 하여 해당 계정의 리소스에 접근합니다.
- 이 역할은 Spoke 계정에서 EC2, RDS, ASG에 대한 시작/중지 작업을 수행할 수 있는 권한을 부여합니다.
Scheduling 조건 확인을 위한 DynamoDB 조회 (Read Scheduling Config Table)
- Handler에서부터 DynamoDB에 저장된 스케줄링 설정을 읽어옵니다.
- Handler Lambda는 Hub 계정에서 호출되어 Spoke 계정의 리소스를 관리하는 역할을 합니다. 이 Lambda 함수는 스케줄링 작업(리소스 시작/중지)을 수행하기 위해 필요한 설정 정보를 DynamoDB에서 조회해야 합니다.
- DynamoDB에는 스케줄링 설정, 리소스 태그 매핑, 대상 계정 정보 등이 저장되어 있으며, Handler Lambda는 이 데이터를 기반으로 작업을 수행합니다.
리소스 시작/중지 (Resource Start/Stop)
- Handler Lambda는 Spoke 계정의 리소스(EC2, RDS, ASG)를 대상으로 시작 또는 중지 작업을 수행합니다.
- 해당 작업은 1) 의 작업에서 Administrator 가 리소스에 부착한 Tag의 값으로 식별합니다.
- Instance Scheduler 를 설치할 때 설정한 Instance Scheduler Tag Key 값의 여부로 Resource를 조회합니다.
- 해당 Key 값이 존재하는 리소스를 조회한 후 설정된 Tag Value 에 따라서 스케줄링 조건을 판별한 후 Resource에 대한 Operation을 수행합니다.
- EC2 / RDS
  - 태그된 인스턴스 ( 혹은 RDS )에 대한 시작 / 중지 요청을 직접 리소스로 호출합니다.
  - 스케줄링 성공 여부에 따라서 해당 리소스에 스케줄링 성공에 대한 tag를 추가적으로 부착합니다.
- ASG
  - 태그된 ASG 리소스에 대해 스케줄링 작업이 수행되면 ASG의 Scheduled Action을 업데이트합니다.
  - 바로 인스턴스 스케줄링이 실행되지 않고 예약된 작업을 생성하는 방식으로 작동하기 때문에 EC2 혹은 RDS 와는 작동하는 방식이 다릅니다.
스케줄링 상태 업데이트 (Update Scheduling State)
- 작업 완료 후, Handler Lambda는 DynamoDB에 스케줄링 상태를 업데이트합니다.
- 특정 리소스가 중지됨, 시작됨 등의 상태를 기록하여 추적 가능하도록 합니다.
- ASG 의 경우 상태 추적을 지원하지 않습니다.

인스턴스 스케줄러 사용하기

인스턴스 스케줄러를 배포한 후, 실제로 인스턴스를 자동으로 시작하고 중지하기 위해서는 스케줄 설정과 리소스에 태그를 지정해야 합니다.

스케줄 Config

DynamoDB에 생성되는 ConfigTable을 사용하여 스케줄과 기간 (Period)를 정의합니다. 각 항목은 type 속성으로 구분되며, 주요 속성은 다음과 같습니다.

config: 스케줄러 전역 설정으로 인스턴스 스케줄러가 관리하는 org와 spoke 계정에 대한 설정이 포함되어 있습니다.
schedule: 인스턴스 스케줄러에 적용할 스케줄러에 대한 설정으로, 실제 기간이 포함된 periods 리스트와 스케줄러 태그, 스케줄러가 수행될 시간대 등을 포함합니다.
period: 시작 시간, 종료 시간, 적용할 요일에 대한 스케줄러의 시간 설정이 포함되어 있습니다.

스케줄 구성

DynamoDB에 스케줄을 정의하는 방법은 크게 3가지로 구분됩니다.

DynamoDB 콘솔 사용

AWS Management Console에서 DynamoDB 테이블을 직접 편집하여 스케줄과 기간을 추가, 수정 또는 삭제할 수 있습니다.

Scheduler Cli 사용

Instance Scheduler의 스케줄과 기간을 관리할 수 있는 cli 도구를 제공합니다.
scheduler cli를 설치한 후 제공되는 명령어를 사용해 구성 변경이 가능합니다.

Scheduler cli를 통한 scheduler 구성은 AWS 공식 문서에서 확인해 볼 수 있습니다.

AWS Cloud Formation의 Custom Resource 사용

IaC 방식으로 관리 가능한 Cloud Formation에 스케줄을 정의하고 관리 가능합니다.
ServiceInstanceSchedule이라는 커스텀 리소스를 사용하여 cloud formation으로 템플릿을 배포합니다.
IaC 방식을 사용하면 위 두 방식과 혼용해서 사용하는 경우 충돌이 발생할 수 있기 때문에 IaC 방식으로만 스케줄링을 관리해야 합니다.

https://docs.aws.amazon.com/ko_kr/solutions/latest/instance-scheduler-on-aws/manage-schedules-using-infrastructure-as-code-iac.html

[코드형 인프라(IaC)를 사용하여 일정 관리 - AWS의 인스턴스 스케줄러

DynamoDB 콘솔 또는 스케줄러 CLI를 사용하여 사용자 지정 리소스를 사용하여 구성된 일정 및 기간을 삭제하거나 수정하지 마십시오. 이렇게 하면 스택에 저장된 파라미터와 테이블의 값 간에 충돌

docs.aws.amazon.com](https://docs.aws.amazon.com/ko_kr/solutions/latest/instance-scheduler-on-aws/manage-schedules-using-infrastructure-as-code-iac.html)

아래는 여러 사용 케이스로 구성한 template의 예제입니다.

AWSTemplateFormatVersion: 2010-09-09
Parameters:
  ServiceInstanceScheduleServiceTokenARN:
    Type: String
    Description: (Required) service token arn taken from InstanceScheduler outputs
Metadata:
  'AWS::CloudFormation::Designer': {}
Resources:
  # 1. 평일 09시 - 18시 실행, 평일 18시-09시 및 주말/휴일 24시간 종료
  Schedule1:
    Type: 'Custom::ServiceInstanceSchedule'
    Properties:
      ServiceToken: !Ref ServiceInstanceScheduleServiceTokenARN
      NoStackPrefix: 'True'
      Name: weekday-9-18-schedule
      Description: Runs instances on weekdays from 09:00 to 18:00 KST
      Timezone: Asia/Seoul
      Periods:
      - Description: Run from 09:00 to 18:00 on weekdays
        BeginTime: '09:00'
        EndTime: '18:00'
        WeekDays: mon-fri

  # 2. 평일 계속 실행, 주말/휴일 24시간 종료
  Schedule2:
    Type: 'Custom::ServiceInstanceSchedule'
    Properties:
      ServiceToken: !Ref ServiceInstanceScheduleServiceTokenARN
      NoStackPrefix: 'True'
      Name: weekday-continuous-schedule
      Description: Runs instances continuously on weekdays KST
      Timezone: Asia/Seoul
      Periods:
      - Description: Run continuously on weekdays (no begin/end time means 24h)
        WeekDays: mon-fri

  # 3. 평일 09시 ~ 24시 실행, 평일 00시 ~ 09시 및 주말/휴일 24시간 종료
  Schedule3:
    Type: 'Custom::ServiceInstanceSchedule'
    Properties:
      ServiceToken: !Ref ServiceInstanceScheduleServiceTokenARN
      NoStackPrefix: 'True'
      Name: weekday-9-24-schedule
      Description: Runs instances on weekdays from 09:00 to 24:00 KST
      Timezone: Asia/Seoul
      Periods:
      - Description: Run from 09:00 to 23:59 on weekdays
        BeginTime: '09:00'
        EndTime: '23:59'
        WeekDays: mon-fri

  # 4. 평일 07시 - 21시 실행, 평일 21시-07시 및 주말/휴일 24시간 종료
  Schedule4:
    Type: 'Custom::ServiceInstanceSchedule'
    Properties:
      ServiceToken: !Ref ServiceInstanceScheduleServiceTokenARN
      NoStackPrefix: 'True'
      Name:
      Description: Runs instances on weekdays from 07:00 to 21:00 KST
      Timezone: Asia/Seoul
      Periods:
      - Description: Run from 07:00 to 21:00 on weekdays
        BeginTime: '07:00'
        EndTime: '21:00'
        WeekDays: mon-fri

태그 값

스케줄 시간

시간대

weekday-9-18-schedule

평일 09시 - 18시 실행

Asia/Seoul

weekday-9-24-schedule

평일 09시 ~ 24시 실행

Asia/Seoul

weekday-7-21-schedule

평일 07시 - 21시 실행

Asia/Seoul

weekday-continuous-schedule

평일 계속 실행, 주말 종료

Asia/Seoul

인스턴스 스케줄러 태그 리소스에 태깅하기

스케줄이 정의된 후에는, 해당 스케줄을 적용할 EC2 또는 RDS 인스턴스에 특정 태그를 추가해야 합니다. 인스턴스 스케줄러는 이 태그를 기준으로 어떤 리소스를 제어할지 식별합니다.

Key: 배포 시 지정한 Schedule tag key
Value: weekday-9-18-schedule

이 태그가 지정된 리소스는 office-hours 스케줄에 따라 자동으로 시작 및 중지됩니다.

주의할 점:

태그 Key 값은 배포 시 설정한 값과 반드시 일치해야 합니다.
태깅된 리소스만 스케줄러에 의해 제어되므로, 의도하지 않은 인스턴스가 제어되지 않도록 유의해야 합니다.

ASG의 경우는 일반적인 Instance Scheduler의 동작과 다르게 수행됩니다.

ASG에 schedule tag key 가 설정된 경우 Auto Scaling Group의 Automatic Scaling의 Scheduled Actions에 스케줄링을 추가합니다.

그 후 올바른 스케줄이 됐다는 tag를 asg 태그에 부착합니다.

asg 에 부착한 tag

인스턴스 스케줄러 사용 주의점

AWS Instance Scheduler는 클라우드 자원 비용 절감과 자동화를 위한 강력한 도구이지만, 실무 환경에서는 몇 가지 제약사항과 관리 포인트가 존재합니다. 특히 여러 계정과 리전을 운영하거나, 다양한 서비스에 스케줄링을 적용할 경우 고려해야 할 부분이 많습니다. 아래에서는 인스턴스 스케줄러 사용 시 실제로 마주칠 수 있는 주요 이슈입니다.

계정/리전 확장 시 Lambda 호출 비용 증가

Instance Scheduler는 주기적으로 실행되는 Lambda 함수를 통해 EC2, RDS, ASG 등의 리소스 상태를 점검하고 제어합니다. 이 Lambda는 일정한 간격(Interval)으로 반복 호출되며, 호출 수는 다음과 같이 계산됩니다.

총 Lambda 호출 수 = 계정 수 × 리전 수 × 서비스 수 × (24 × 60 ÷ interval 분)

예를 들어,

5개 계정
3개 리전
EC2/RDS/ASG 3개 서비스
10분 간격

으로 구성한 경우, 하루 동안 발생하는 호출 수는 다음과 같습니다.

5 × 3 × 3 × (24 × 60 ÷ 10) = 64,800회/일

리소스가 없는 경우에도 Lambda가 호출되어 불필요한 비용이 발생합니다.
호출 수가 많아지면 Lambda 사용 요금뿐만 아니라, DynamoDB 조회 비용, CloudWatch 로그 저장 비용 또한 함께 증가합니다.
규모가 커질수록 비용 부담과 비효율이 커지게 됩니다.

위와 같은 한계 사항을 잘 고려해서 인스턴스 스케줄러를 사용해야 합니다.

EC2, RDS와 ASG는 서로 다른 방식으로 스케줄링

Instance Scheduler를 CloudFormation으로 배포하면 총 8개의 Lambda 함수가 생성되며, 이 중 실제로 스케줄링을 수행하는 핵심 Lambda는 두 가지입니다.

scheduler-handler: EC2와 RDS 인스턴스를 대상으로 start/stop API 호출
scheduler-asg-handler: ASG는 Scheduled Action (Cron 방식)으로 작업 예약

즉, EC2와 RDS는 즉시 실행 방식, ASG는 예약 기반 방식으로 제어됩니다.

리소스별로 처리 방식이 상이하여 코드 복잡도와 관리 포인트가 증가합니다.
예를 들어, ASG Lifecycle Hook과 같은 고급 기능을 사용할 경우 로직이 더욱 복잡해지고, 예외 상황 처리도 까다로워집니다.
상태 변경의 일관성을 유지하기 어렵고, 운영자가 이를 따로 감안해야 합니다.

엣지 케이스(예외 상황) 관리 어려움

현실적인 운영 환경에서는 다음과 같은 예외 상황이 자주 발생합니다:

업무 시간 외에 인스턴스를 즉시 시작하거나 중지해야 하는 상황
특정 인스턴스를 일시적으로 스케줄링 대상에서 제외하고 싶은 경우

이러한 요구사항을 처리하는 데 한계가 있습니다.

태그를 수정하더라도, 상태 변경은 다음 스케줄링 주기(interval)까지 대기해야 합니다.
특히 ASG는 태그 기반의 즉시 실행이나 제어를 지원하지 않아, 수동 개입이 필요합니다.
스케줄에 맞지 않는 일회성 작업은 관리가 번거롭고 일관성 유지가 어렵습니다.

AWS Instance Scheduler는 강력한 자동화 도구지만, 여러 한계점도 분명 존재합니다.

멀티 계정/리전 운영
다양한 서비스 유형 관리
예외 상황 대응

이러한 제약을 극복하고 안정적인 운영을 위해서는, 경우에 따라 Lambda 코드를 직접 수정하거나, 스케줄링 시스템을 커스터마이징 하는 접근이 필요할 수 있습니다.