EC2 Auto Scaling 최소 최대 원하는 용량 의미와 대상 추적 조정 정책 설정 방법

트래픽은 하루 중에도, 한 달 중에도 크게 오르내립니다. 가장 바쁜 시간에 맞춰 서버를 넉넉히 켜 두면 한가한 시간에는 비용이 새고, 평균에 맞춰 두면 몰리는 시간에 응답이 느려집니다. Amazon EC2 Auto Scaling은 이 두 문제 사이에서 서버 대수를 자동으로 조절해 주는 기능입니다.

 

Auto Scaling 그룹을 만들면 가장 먼저 최소 용량, 최대 용량, 원하는 용량이라는 세 숫자를 입력하게 됩니다. 이름만 보면 비슷해 보이지만 각각의 역할이 분명히 다르고, 조정 정책은 이 숫자 중 원하는 용량을 바꾸는 방식으로 동작합니다.

 

이 글에서는 세 가지 용량의 의미, 시작 템플릿의 역할, 조정 방식의 종류, 가장 많이 쓰는 대상 추적 정책이 실제로 어떻게 움직이는지, 그리고 상태 검사 유예 기간과 워밍업 같은 세부 설정까지 순서대로 정리합니다.

 

결론부터 말씀드리면 최소·최대 용량은 그룹이 벗어날 수 없는 범위이고, 원하는 용량은 지금 유지할 대수입니다. 대상 추적 정책은 CPU 평균 같은 지표를 목표값 근처에 유지하도록 원하는 용량을 자동으로 올리고 내립니다. Auto Scaling 자체에는 추가 요금이 없고, 실행된 EC2 인스턴스와 모니터링에 대한 요금만 발생합니다.

 

 

Auto Scaling 그룹은 세 개의 숫자로 움직입니다

최소 용량은 그룹이 유지해야 하는 최소 인스턴스 수입니다. 조정 정책이 아무리 줄이려 해도 이 숫자 아래로는 내려가지 않습니다. 최대 용량은 반대로 늘릴 수 있는 상한입니다. 부하가 폭증하거나 설정 실수가 있어도 이 숫자를 넘지 않으므로, 비용 폭주를 막는 안전장치 역할을 합니다.

 

원하는 용량은 지금 이 순간 그룹이 유지하려는 인스턴스 수입니다. 인스턴스 하나가 상태 검사에 실패해 종료되면 그룹은 원하는 용량을 맞추기 위해 새 인스턴스를 자동으로 띄웁니다. 조정 정책이 하는 일은 결국 이 원하는 용량 값을 최소와 최대 사이에서 바꾸는 것입니다.

 

상황	최소	원하는	최대	결과
평상시	2	2	6	2대 유지
부하 증가로 정책이 5대 요청	2	5	6	3대 추가 실행
정책이 8대 요청	2	6	6	최대값인 6대에서 멈춤
새벽에 정책이 1대 요청	2	2	6	최소값인 2대 유지

 

최소 용량을 2 이상으로 두고 서로 다른 가용 영역의 서브넷을 함께 지정하면, 한 가용 영역에 문제가 생겨도 다른 영역의 인스턴스가 서비스를 이어 갑니다. Auto Scaling은 선택한 가용 영역에 인스턴스를 고르게 나눠 배치하려고 합니다.

 

최소와 최대는 넘을 수 없는 범위, 원하는 용량은 현재 목표 대수이며, 조정 정책은 이 범위 안에서 원하는 용량을 바꿉니다.

 

시작 템플릿이 새 인스턴스의 설계도입니다

Auto Scaling이 인스턴스를 새로 띄울 때는 시작 템플릿에 적힌 설정을 그대로 사용합니다. 어떤 AMI로 부팅할지, 인스턴스 유형은 무엇인지, 어떤 보안 그룹과 키 페어를 쓸지, 부팅 직후 실행할 사용자 데이터 스크립트는 무엇인지 등이 들어갑니다.

 

예전에는 시작 구성(launch configuration)이라는 방식도 쓰였지만 지금은 사용이 제한되어 있습니다. 2023년 1월 1일부터 새로 출시된 인스턴스 유형은 시작 구성에서 지원되지 않고, 2024년 10월 1일 이후 만든 계정은 어떤 방법으로도 시작 구성을 새로 만들 수 없습니다. 새로 시작한다면 시작 템플릿을 쓰면 됩니다.

 

시작 템플릿은 버전 관리가 됩니다. 새 AMI로 교체할 때 새 버전을 만들고 그룹이 그 버전을 쓰도록 바꾸면, 이후 새로 뜨는 인스턴스부터 새 설정이 적용됩니다. 또 여러 인스턴스 유형과 온디맨드·스팟 비율을 섞어 쓰는 혼합 인스턴스 구성도 시작 템플릿과 함께 설정할 수 있습니다.

 

새 인스턴스는 시작 템플릿대로 만들어지므로, 서버에 직접 접속해 바꾼 설정은 다음에 뜨는 인스턴스에 반영되지 않는다는 점을 기억해야 합니다.

 

조정 방식은 상황에 따라 고릅니다

Auto Scaling에는 원하는 용량을 바꾸는 방법이 여러 가지 있습니다. 지표를 목표값에 맞추는 대상 추적, 지표 구간마다 늘리고 줄일 대수를 정하는 단계 조정, 정해진 시각에 용량을 바꾸는 예약된 작업, 과거 패턴으로 앞으로의 부하를 예측하는 예측 조정이 대표적입니다.

 

 

방식	동작	잘 맞는 경우
대상 추적	지표를 목표값 근처로 유지하도록 자동 계산	대부분의 웹 서비스 기본 설정
단계 조정	지표 구간별로 늘리고 줄일 대수를 직접 지정	부하 구간마다 세밀한 제어가 필요할 때
예약된 작업	지정한 날짜와 시각에 용량 변경	출근 시간, 이벤트 시작처럼 시간이 정해진 부하
예측 조정	과거 부하 패턴으로 미리 용량 확보	매일 비슷한 주기로 반복되는 트래픽

 

여러 방식을 함께 쓸 수도 있습니다. 예를 들어 평일 오전 9시에는 예약된 작업으로 최소 용량을 올려 두고, 그 위에서 대상 추적 정책이 실시간 부하에 맞춰 세부 조정을 하는 식입니다.

 

처음에는 대상 추적 정책 하나로 시작하고, 시간이 정해진 부하가 있으면 예약된 작업을 더하는 조합이 가장 관리하기 쉽습니다.

 

대상 추적 정책은 온도 조절기처럼 동작합니다

대상 추적 정책은 지표 하나와 목표값을 정하면, 그 값을 유지하도록 인스턴스 수를 알아서 계산합니다. 난방기가 설정 온도를 유지하려고 켜졌다 꺼졌다 하는 것과 비슷합니다. 미리 정의된 지표로는 그룹 평균 CPU 사용률, 평균 네트워크 입력과 출력, ALB 대상당 요청 수가 있습니다.

 

동작을 대략 계산해 보면 이렇습니다. 인스턴스 2대의 평균 CPU가 75%이고 목표값이 50%라면, 같은 부하를 50%로 나누기 위해 2 × 75 ÷ 50 = 3대가 필요하다고 볼 수 있습니다. 실제 계산은 보수적으로 이루어지는데, 1.5대가 필요하다고 판단되면 올림해 2대를 추가하고, 줄일 때는 줄인 뒤 다시 목표를 넘을 것 같으면 줄이지 않습니다.

 

몇 가지 특징을 알아두면 동작을 오해하지 않습니다. 대상 추적 정책은 필요한 CloudWatch 알람을 스스로 만들고 관리하므로, 그 알람을 직접 수정하거나 삭제하면 안 됩니다. 또 가용성을 우선하기 때문에 늘릴 때는 빠르고 줄일 때는 천천히 줄입니다. 정책을 여러 개 두면 하나라도 늘리자고 할 때 늘리고, 모두가 줄이자고 할 때만 줄입니다.

 

EC2 지표는 기본적으로 5분 간격으로 수집되므로, 빠른 반응이 필요하다면 1분 간격의 세부 모니터링을 켜는 것이 권장됩니다. 또 로드 밸런서의 전체 요청 수처럼 인스턴스 수에 비례해 변하지 않는 지표는 대상 추적에 맞지 않습니다.

 

대상 추적은 늘릴 때 빠르고 줄일 때 느리게 움직이며, 자동으로 만든 알람은 건드리지 않고 목표값만 조정하는 것이 원칙입니다.

 

상태 검사 유예 기간과 워밍업을 함께 설정합니다

새 인스턴스는 부팅하고 애플리케이션이 준비되기까지 시간이 걸립니다. 이 시간 동안 로드 밸런서 상태 검사에 실패했다고 바로 종료해 버리면, 인스턴스가 떴다가 지워지기를 반복하게 됩니다. 이를 막는 설정이 상태 검사 유예 기간입니다.

 

유예 기간의 기본값은 만드는 방법에 따라 다릅니다. 콘솔에서 그룹을 만들면 300초, AWS CLI나 SDK로 만들면 0초가 기본값입니다. 0은 유예 기간을 끈다는 뜻이므로, 코드로 그룹을 만들 때는 이 값을 직접 지정하는 것이 안전합니다.

 

기본 인스턴스 워밍업도 함께 설정하는 것이 권장됩니다. 워밍업 시간 동안 새 인스턴스는 그룹 평균 지표 계산에서 빠지므로, 막 떠서 아직 일을 하지 않는 인스턴스 때문에 평균 CPU가 낮게 계산되어 너무 일찍 줄이는 일을 막을 수 있습니다.

 

유예 기간은 애플리케이션 준비 시간보다 조금 길게 잡고, 워밍업 시간을 함께 지정해야 조정이 안정적으로 동작합니다.

 

처음 설정하는 순서

1. AMI, 인스턴스 유형, 보안 그룹, 사용자 데이터를 담은 시작 템플릿을 만듭니다.
2. Auto Scaling 그룹을 만들고 서로 다른 가용 영역의 서브넷을 두 개 이상 선택합니다.
3. 로드 밸런서를 쓴다면 대상 그룹을 연결하고 상태 검사에 ELB 검사를 추가한 뒤 유예 기간을 정합니다.
4. 최소 2, 원하는 2, 최대 6처럼 범위를 정합니다.
5. 대상 추적 정책으로 평균 CPU 50% 같은 목표값을 설정합니다.
6. 인스턴스 시작·종료 알림을 SNS로 받도록 설정하고, 부하 테스트로 늘고 주는 동작을 확인합니다.

 

시작 템플릿, 다중 가용 영역, 상태 검사, 용량 범위, 조정 정책, 알림 순서로 설정하면 빠뜨리는 항목이 없습니다.

 

Auto Scaling 핵심 정리

Auto Scaling 그룹은 최소·최대 용량으로 범위를 정하고, 원하는 용량을 목표로 인스턴스 수를 유지합니다. 새 인스턴스는 시작 템플릿대로 만들어지며, 대상 추적 정책은 지표를 목표값 근처로 유지하도록 늘릴 때는 빠르게, 줄일 때는 천천히 원하는 용량을 조정합니다. 콘솔 300초와 CLI 0초로 다른 유예 기간 기본값, 워밍업 설정, 여러 가용 영역 배치를 함께 챙기면 안정적으로 운영할 수 있습니다.

 

질문 QnA

줄어들 때는 어떤 인스턴스가 먼저 종료되나요?

기본 종료 정책은 먼저 인스턴스가 가장 많은 가용 영역을 골라 영역 간 균형을 맞추고, 그 안에서 오래된 시작 템플릿 버전을 쓰는 인스턴스 등을 우선 종료합니다. 필요하면 종료 정책을 직접 지정하거나 특정 인스턴스에 축소 보호를 걸 수 있습니다.

인스턴스에 저장한 파일은 어떻게 되나요?

축소될 때 인스턴스가 종료되면 루트 볼륨의 데이터도 함께 사라지는 경우가 많습니다. 업로드 파일은 S3, 데이터는 RDS 같은 외부 저장소에 두고 인스턴스는 언제든 교체될 수 있게 만드는 것이 기본입니다.

밤에는 0대로 줄일 수 있나요?

최소 용량을 0으로 두면 가능합니다. 예약된 작업으로 밤에는 최소·원하는 용량을 0으로, 아침에는 다시 올리는 방식이 개발 환경에서 자주 쓰입니다.

스팟 인스턴스와 함께 쓸 수 있나요?

혼합 인스턴스 구성을 사용하면 기본 용량은 온디맨드로, 추가 용량은 스팟으로 채우는 식의 비율을 정할 수 있습니다. 스팟은 회수될 수 있으므로 여러 인스턴스 유형을 함께 지정하는 것이 좋습니다.

 

Auto Scaling은 한 번 잘 설정해 두면 사람이 신경 쓰지 않아도 부하에 맞춰 서버 대수를 조절해 줍니다. 다만 인스턴스가 언제든 새로 만들어지고 사라질 수 있다는 전제에 맞게 애플리케이션을 설계해야 효과를 제대로 볼 수 있습니다.

 

지금 고정 대수로 운영 중인 서비스가 있다면, 먼저 최근 2주 동안의 CPU 사용률 그래프에서 가장 바쁜 시간과 한가한 시간의 차이를 확인해 보세요. 차이가 크다면 최소 2대, 목표 CPU 50%의 대상 추적 정책부터 적용해 보시길 권해드립니다.

함께 읽으면 좋은 글: EC2 요금 방식 차이 비교 / RTO·RPO와 멀티 AZ 구성

참고 자료: Amazon EC2 Auto Scaling 사용 설명서, 대상 추적 조정 정책, 상태 검사 유예 기간

※ 본 글은 2026년 9월 기준 Amazon EC2 Auto Scaling 사용 설명서를 참고해 작성했으며, 기본값과 지원 기능, 요금 기준은 변경될 수 있으니 최신 내용은 AWS 공식 문서에서 확인해 주세요.