AWS 인스턴스 스케줄러 쓰기 전에 — 청구서로 개발 서버 24시간 가동 찾기 (2026)

개발 서버를 밤에 끄자는 이야기는 누구나 한 번쯤 한다. 그리고 대부분 도구 이야기로
넘어간다. Instance Scheduler를 깔까, Lambda를 짤까, 태그 규칙은 어떻게 할까.

그런데 그 전에 답해야 할 질문이 두 개 있다. 우리가 정말 해당되나, 해당되면 얼마나
되나. 도구 설정 글은 많지만 이 두 질문에 답하는 글은 드물다. 그리고 이 두 질문은
도구 없이 청구서만으로 답할 수 있다. 스케줄러 도입 여부는 그 답을 보고 정하면 된다.

---

요약 (Quick Answer)

24×7 가동의 모양

한 달은 약 730시간이다. 개발·스테이징 리소스가 한 달에 650시간 이상 돌았다면
밤에도 주말에도 켜져 있었다는 뜻이다.

청구서 판정

확인	어디서	기준
환경 구분	비용 할당 태그 env(또는 environment·stage)	dev·stg·test 값이 있나
가동 시간	Cost Explorer 사용 유형 BoxUsage(EC2) · InstanceUsage(RDS), 단위 Hrs	리소스당 월 650h 이상
리소스별	CUR의 line_item_resource_id	어느 인스턴스인지

얼마나 줄어드나

평일 12시간만 켜면 주 168시간 → 60시간이다. 우리 진단은 이 경우 절감액을 해당 비용의
50%로 잡는다(보수치).

RDS는 함정이 두 개

1. 중지해도 스토리지·백업·공인 IPv4 요금은 계속 나간다.
2. 7일 연속 중지하면 자동으로 다시 켜진다. 장기 휴면용이 아니다.

도구는 셋: Quick Setup(EC2 전용·무료) / Instance Scheduler on AWS(EC2·RDS 등·소형 월 약 $9)
/ EventBridge Scheduler(월 1,400만 회 무료·직접 구성)

검증: 2026-09-29 AWS 공식 문서 확인

---

먼저 결론 세 줄

한 달은 약 730시간이고, 개발·스테이징 태그가 붙은 리소스가 월 650시간 이상 돌면 밤과
주말에도 켜져 있다는 뜻이다. 이건 Cost Explorer의 사용 시간(Hrs)과 비용 할당 태그만으로
확인되므로 스케줄러를 깔기 전에 청구서로 먼저 판정할 수 있다.
평일 12시간 운영으로 바꾸면 가동 시간이 주 168시간에서 60시간으로 줄고, 보수적으로
해당 비용의 절반을 절감액으로 잡는다. RDS는 중지해도 스토리지 요금이 남고 7일 뒤
자동으로 다시 켜지므로 EC2와 같은 방식으로 다루면 안 된다.

왜 도구보다 청구서가 먼저인가

스케줄러 도입이 실패하는 흔한 경로는 이렇다. 도구를 깔고, 태그를 붙이고, 한 달 뒤
청구서를 보니 거의 안 줄었다. 원인은 대개 둘 중 하나다.

• 비프로덕션 비용이 애초에 작았다. 줄일 게 없었다.
• 비프로덕션 비용의 대부분이 꺼도 안 줄어드는 항목(스토리지·공인 IP·NAT 등)이었다.

둘 다 청구서를 먼저 봤으면 알 수 있었다. 스케줄링은 인스턴스 시간 요금만 줄인다.
그 밖의 요금은 그대로 남는다(EC2를 꺼도 남는 요금은
EC2를 껐는데 요금이 계속 나온다에 정리했다).

1단계 — 비프로덕션을 구분할 수 있나

청구서에서 "개발 서버"를 찾으려면 청구서가 개발과 운영을 구분할 수 있어야 한다.
그 수단이 비용 할당 태그다.

리소스에 env=dev 같은 태그를 붙이는 것만으로는 부족하다. 결제 콘솔에서 그 태그 키를
비용 할당 태그로 활성화해야 청구서에 나타난다. 공식 문서 기준으로 태그를 붙인 뒤 활성화
목록에 뜨기까지 최대 24시간, 활성화가 적용되기까지 다시 최대 24시간이 걸린다.

활성화 전의 과거 데이터는 관리 계정에서 백필(backfill)을 요청하면 최대 12개월까지
소급된다. 단, 그 기간에 리소스에 태그가 실제로 붙어 있었어야 한다. 태그 자체가 없던
기간은 소급할 수 없다.

판정은 세 갈래다.

상태	의미	다음
env 태그가 활성화돼 있고 값이 채워져 있다	바로 판정 가능	2단계로
태그는 붙어 있는데 활성화가 안 됐다	활성화 + 백필로 과거까지 확보	활성화 후 2단계
태그가 없거나 "태그 없음" 비용이 크다	청구서로는 구분 불가	이름 규칙(-dev, -stg)으로 임시 구분, 태그 정책부터

마지막 경우가 생각보다 흔하다. 이때는 스케줄러보다 태그 정책이 먼저다. 스케줄러도
결국 태그로 대상을 고르기 때문이다.

2단계 — 몇 시간 돌았나

Cost Explorer에서 이렇게 본다.

1. 그룹화 기준: 태그 → env
2. 필터: 사용 유형에 BoxUsage(EC2 인스턴스 시간) 또는 InstanceUsage(RDS 인스턴스 시간)
3. 지표를 비용이 아니라 사용량(Usage Quantity)으로 바꾼다. 단위는 시간(Hrs)이다.

dev 그룹의 사용 시간을 인스턴스 대수로 나눈 값이 대당 월 650시간을 넘으면 24×7이다.
월 730시간 중 여유를 80시간 정도 둔 기준이다. 월중에 만들었거나 잠깐 껐던 인스턴스가
섞이면 평균이 낮아지므로, 이 기준을 넘는다면 거의 확실하게 상시 가동이 섞여 있다.

어느 인스턴스인지까지 보려면 CUR(비용 및 사용 보고서)이 필요하다. CUR에는 줄마다
line_item_resource_id가 있어서, 리소스별로 사용 시간을 더하면 650시간을 넘는 목록이
그대로 나온다. Cost Explorer는 합계와 추세를, CUR은 명단을 준다.

3단계 — 얼마나 줄어드나

일주일은 168시간이다. 평일 12시간(예: 08~20시)만 켜면 60시간이 된다.

가동 비율  = 60 ÷ 168 ≈ 36%
이론 절감률 ≈ 64%

AWS 문서는 "주 50시간 운영이면 최대 70% 절감"이라는 예를 든다. 계산 자체는 맞다.
하지만 우리는 진단에서 해당 비용의 50%만 절감액으로 잡는다. 이유는 셋이다.

• 야근·배포·장애 대응으로 스케줄 밖에서 켜는 시간이 생긴다.
• 스케줄에서 빼야 하는 리소스가 나온다(야간 배치를 돌리는 개발 DB 등).
• 인스턴스 시간 외 요금(스토리지 등)은 줄지 않는다.

예를 들어 비프로덕션 인스턴스 시간 요금이 월 $2,000이면 절감액은 월 $1,000로 잡는다.
실제로 더 줄면 좋은 일이고, 덜 줄 일은 드물다.

RDS — EC2처럼 다루면 안 되는 이유

RDS도 중지할 수 있다. 공식 문서는 개발용 DB를 주요 사용 사례로 든다. 다만 EC2와 다른
점이 셋 있다.

① 중지해도 나가는 요금

공식 문서의 표현을 그대로 옮기면 이렇다.

While your DB instance is stopped, you are charged for provisioned storage
(including Provisioned IOPS). You're also charged for backup storage, including
manual snapshots and automated backups within your specified retention window.
Additionally, if your DB instance is publicly accessible, you will continue to be
charged for the public IPv4 address.

멈추는 건 DB 인스턴스 시간 요금뿐이다. 스토리지(프로비저닝된 IOPS 포함), 백업,
그리고 퍼블릭 액세스가 켜진 DB의 공인 IPv4 요금은 계속 나간다. 그래서 RDS의 절감액은
인스턴스 시간 요금만을 기준으로 계산해야 한다. 청구서에서 InstanceUsage(또는
Multi-AZUsage) 줄만 대상이다.

② 7일 뒤 자동으로 켜진다

If you don't manually start your DB instance after it is stopped for seven
consecutive days, RDS automatically starts your DB instance for you.

유지보수 업데이트에 뒤처지지 않게 하려는 장치다. Aurora 클러스터도 똑같이 7일이다.

매일 밤 끄고 아침에 켜는 스케줄이라면 이 한도에 닿지 않는다. 문제가 되는 건
"당분간 안 쓰니 꺼 두자"로 멈춰 둔 DB다. 8일째에 조용히 다시 켜지고, 아무도 모르는 채
인스턴스 시간 요금이 다시 나가기 시작한다. 청구서에서는 몇 주 간격으로 짧게 끊겼다가
다시 이어지는 모양으로 보인다.

장기간 안 쓸 DB라면 선택지는 둘이다.

• 스냅샷을 뜬 뒤 삭제하고, 필요할 때 복원한다. ⚠️ 삭제는 비가역이다. 스냅샷이
  완료됐는지(available) 확인하고, 복원 테스트를 한 번 해 본 다음에 지운다.
• 7일마다 다시 끄는 자동화를 둔다. AWS는 Step Functions로 구현하는 방법을 안내한다
  (하단 링크).

③ 멈출 수 없는 구성이 있다

• 읽기 전용 복제본(read replica)이 있거나, 그 자신이 복제본인 DB 인스턴스는 중지할 수 없다.
• Multi-AZ 배포의 RDS for SQL Server는 중지할 수 없다.
• Aurora는 교차 리전 읽기 복제본이 있거나 블루/그린 배포 중인 클러스터를 중지할 수 없다.

그리고 시작이 느리다. 공식 문서는 DB 시작에 몇 분에서 몇 시간이 걸릴 수 있다고 적는다.
아침 스케줄은 업무 시작보다 넉넉히 앞당겨 둔다.

도구 선택 — 셋 중 하나

판정이 끝나고 줄일 게 있다고 나왔을 때 고른다. 설정 절차는 각 공식 문서에 잘 나와 있으니
여기선 고르는 기준만 적는다.

	Quick Setup (Resource Scheduler)	Instance Scheduler on AWS	EventBridge Scheduler
대상	EC2만	EC2·Auto Scaling 그룹·RDS·Aurora·Neptune·DocumentDB	API로 부를 수 있는 것 전부
대상 선택	태그 키·값	태그	직접 지정
비용	설정 자체 무료	공식 예시 월 $9~$13 (운영 모니터링 포함 여부)	월 1,400만 회 무료(영구·전 리전 합산), 이후 100만 회당 $1
멀티 계정·리전	지원	지원	직접 구성
운영 부담	가장 낮음	CloudFormation 스택 관리	가장 높음
이럴 때	EC2만 끄면 된다	RDS까지 같이 끈다	규칙이 특이하다·이미 이벤트 기반 운영 중

고를 때 알아둘 것 몇 가지:

• Quick Setup은 이벤트 방식이다. 정한 시각에 한 번 시작하거나 한 번 멈출 뿐이다.
  누가 스케줄 밖에서 손으로 켜면, 다음 중지 시각까지 그대로 켜져 있다.
• Instance Scheduler의 비용은 대부분 운영 모니터링에서 나온다. 공식 문서에 월 $9대와
  $13대 예시가 모두 나오는데, 차이의 상당 부분이 이 기능이다. 운영 모니터링은 월 $3.00
  추가에 스케줄당 $0.60, 인스턴스 타입당 $0.90, 계정·리전당 약 $0.10이 붙는 구조다.
  허브 스택에서 "Operational Monitoring"을 꺼면 이 비용이 통째로 빠진다. 대시보드가
  필요 없으면 끄라고 문서가 권한다.
• RDS 계열은 하나로 묶여 계산된다. 비용 산정에서 RDS·Aurora·Neptune·DocumentDB는
  단일 "RDS" 서비스로 취급돼 한 번의 Lambda 호출로 처리된다. DB 종류가 여럿이어도
  대상 수가 그만큼 늘지는 않는다.
• 기본 스케줄링 빈도는 5분이다. 요구사항에 따라 늘리면 Lambda 호출 수가 줄어 비용도
  내려간다.
• 암호화된 EBS가 붙은 EC2는 스케줄러 역할에 KMS 키 권한을 줘야 시작된다. 빠뜨리면
  중지는 되는데 아침에 켜지지 않는다.

자주 묻는 질문

Q. 우리 개발 서버가 24시간 도는지 도구 없이 확인할 수 있나요?
있다. Cost Explorer에서 태그 env로 그룹화하고, 사용 유형을 BoxUsage(EC2)·
InstanceUsage(RDS)로 거른 뒤 사용량(Hrs)을 본다. 대당 월 650시간을 넘으면 24×7이다.
태그가 비용 할당 태그로 활성화돼 있어야 한다.

Q. 스케줄링하면 얼마나 줄어드나요?
평일 12시간 운영이면 가동 시간이 주 168시간에서 60시간으로 줄어 이론상 약 64%다.
우리는 예외 가동과 제외 리소스를 감안해 인스턴스 시간 요금의 50%만 절감액으로 잡는다.
스토리지·IP 같은 요금은 줄지 않는다.

Q. RDS를 중지하면 요금이 0이 되나요?
아니다. DB 인스턴스 시간 요금만 멈춘다. 프로비저닝된 스토리지(IOPS 포함), 백업 스토리지,
퍼블릭 액세스가 켜져 있다면 공인 IPv4 요금은 계속 나간다.

Q. RDS를 7일 넘게 꺼 둘 수 있나요?
그대로는 안 된다. 7일 연속 중지되면 자동으로 다시 시작된다. Aurora 클러스터도 같다.
장기간 안 쓸 DB는 스냅샷 후 삭제하거나, 7일마다 다시 중지하는 자동화(Step Functions 등)를
둔다. 매일 밤 끄고 아침에 켜는 스케줄이라면 이 한도에 걸리지 않는다.

Q. 모든 RDS를 중지할 수 있나요?
아니다. 읽기 복제본이 있거나 그 자신이 복제본인 DB 인스턴스, Multi-AZ 배포의
RDS for SQL Server는 중지할 수 없다. Aurora는 교차 리전 읽기 복제본이 있거나 블루/그린
배포 중인 클러스터를 중지할 수 없다.

Q. Instance Scheduler on AWS는 유료인가요?
솔루션 자체는 무료지만 돌아가는 서비스(Lambda·DynamoDB·CloudWatch·KMS) 요금이 나간다.
공식 문서에 소형 예시가 월 $9대와 $13대로 다르게 나오는데, 차이의 상당 부분이 운영
모니터링 포함 여부다. 이 기능은 월 $3.00에 스케줄당 $0.60, 인스턴스 타입당 $0.90,
계정·리전당 약 $0.10이 더해지는 구조이고, 허브 스택에서 꺼면 통째로 빠진다. 중형
(리소스 1,000개)은 약 $161이다.

Q. EventBridge Scheduler 무료 티어는 계정당인가요, 리전당인가요?
전 리전 합산이다(GovCloud 제외). 월 1,400만 회이고 영구 무료 티어라 계정 개설 후
12개월 제한이 없다. 다만 쓰지 않은 분은 다음 달로 이월되지 않는다. 인스턴스 스케줄링
용도라면 호출 수가 하루 수십 회 수준이라 사실상 무료 구간에 머문다.

Q. EC2만 끌 거면 뭐가 제일 간단한가요?
Systems Manager Quick Setup의 Resource Scheduler다. 태그 키·값과 시간만 정하면 되고
설정 자체는 무료다. 단 EC2 전용이고, 정한 시각에 한 번 켜고 한 번 끄는 이벤트 방식이다.

Q. 스케줄링했더니 아침에 인스턴스가 안 켜져요.
EBS 볼륨이 KMS로 암호화돼 있으면 스케줄러의 IAM 역할에 그 키 권한이 있어야 시작된다.
중지는 권한 없이도 되기 때문에 저녁엔 멀쩡히 꺼지고 아침에만 실패한다.

Q. 태그가 하나도 없는데요.
스케줄러보다 태그가 먼저다. 스케줄러도 태그로 대상을 고르고, 청구서도 태그로 환경을
나눈다. 태그를 붙이고 비용 할당 태그로 활성화한 뒤, 관리 계정에서 백필을 요청하면 최대
12개월까지 과거 데이터에 반영된다(그 기간에 태그가 실제로 붙어 있었던 부분만).

이 글의 핵심 메트릭

• 한 달 가동 시간: 약 730시간 · 24×7 판정 기준: 대당 월 650시간 이상
• 평일 12시간 운영: 주 168h → 60h, 이론 절감 약 64%
• 절감액 산정: 인스턴스 시간 요금의 50% (보수치)
• 판정 사용 유형: EC2 BoxUsage · RDS InstanceUsage/Multi-AZUsage (단위 Hrs)
• 비용 할당 태그: 활성화 필요, 표시·적용 각 최대 24시간, 백필 최대 12개월(관리 계정)
• RDS 중지 중 과금: 스토리지(PIOPS 포함)·백업·공인 IPv4 (인스턴스 시간만 멈춤)
• RDS·Aurora 자동 재시작: 7일 연속 중지 후
• RDS 중지 불가: 읽기 복제본 보유·복제본 자신 · Multi-AZ SQL Server
• RDS 시작 소요: 몇 분~몇 시간
• Instance Scheduler 비용: 소형 월 $9~$13 (운영 모니터링 포함 여부) · 중형 약 $161
• 운영 모니터링 내역: 대시보드 $3 + 스케줄당 $0.60 + 인스턴스 타입당 $0.90 + 계정·리전당 ~$0.10 (끌 수 있음)
• Instance Scheduler 기본 스케줄링 빈도: 5분 · RDS 계열 4종은 단일 호출로 묶임
• EventBridge Scheduler: 월 1,400만 회 무료(영구·전 리전 합산·이월 없음), 이후 100만 회당 $1
• Quick Setup Resource Scheduler: EC2 전용, 설정 무료, 리전당 구성 1개에 5,000대
• 사실 확인일: 2026-09-29

---

확인에 쓴 공식 문서 (2026-09-29 기준)

• RDS DB 인스턴스 일시 중지(과금·7일 자동 시작·제약): https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_StopInstance.html
• Aurora DB 클러스터 중지·시작: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-cluster-stop-start.html
• 7일 이상 RDS 중지(Step Functions): https://repost.aws/knowledge-center/rds-stop-seven-days-step-functions
• Instance Scheduler on AWS 개요: https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/solution-overview.html
• Instance Scheduler on AWS 비용(스케일 요인·RDS 계열 단일 호출): https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/cost.html
• Instance Scheduler 운영 모니터링 비용(대시보드 $3·지표 단가·끄는 법): https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/monitor-the-solution.html
• Quick Setup으로 EC2 자동 중지·시작: https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-scheduler.html
• EventBridge 요금: https://aws.amazon.com/eventbridge/pricing/
• 비용 할당 태그 활성화: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html
• 비용 할당 태그 백필: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-allocation-backfill.html

요금과 제약은 개정된다. 이 글의 내용은 2026년 9월 29일에 위 페이지에서 확인한 것이다.

---

비프로덕션 24×7 가동은 청구서에서 확인 가능한 낭비 31개 항목 중 10번이다. 전체 목록은
클라우드 비용 절감 체크리스트 31개에 공개해
뒀고, 직접 볼 시간이 없다면 비용 CSV 한 장으로 무료 진단해 드린다
(계정 권한 불필요, 파일은 30일 후 자동 파기).

→ 무료 성적표 받기

---

비용 절감 시리즈

• FinOps 시작하는 법 — 도구 사기 전에 해야 할 일
• AWS 비용 계산기 제대로 쓰는 법
• 약정 — RI vs Savings Plans 차이
• 네트워크 — NAT 게이트웨이 요금 구조
• 스토리지 — gp2 → gp3 전환
• 유휴 — EC2를 껐는데 요금이 계속 나온다
• 유휴 — 트래픽 없는 로드밸런서 찾기
• 과다 — 개발 서버 24시간 가동 찾기 ← 현재 글
• 전체 판정 기준 — 클라우드 비용 절감 체크리스트 31개

---