오토 스케일링
수요에 맞춰 인스턴스 수를 자동 조절. 가용성과 비용을 동시에 푸는 열쇠
이게 뭔가요? / What is this?
Auto Scaling Group은 그 자체로 손에 잡히는 자원이 아니라, EC2 인스턴스 수를 지켜보다가 필요에 따라 늘리고 줄이는 "자동 조절 규칙"입니다. 에어컨의 온도 조절기가 실내 온도를 재고 알아서 켜고 끄는 것처럼, ASG는 트래픽이나 CPU 같은 지표를 보고 서버 대수를 스스로 맞춰 나갑니다.
개요 / Overview
Auto Scaling Group(ASG)은 최소·희망·최대 용량을 정해두고 지표에 따라 인스턴스를 늘리고 줄입니다. 시험에서는 "트래픽이 예측 불가하게 변한다", "장애 인스턴스를 자동 교체" 같은 문장이 ASG를 가리킵니다. ALB와 짝을 이루고 여러 AZ에 걸치는 형태가 표준 정답입니다.
동작 원리 / How it works
Auto Scaling Group은 시작 템플릿(어떤 AMI·인스턴스 타입·보안 그룹으로 띄울지)과 용량 범위(최소·희망·최대), 그리고 여러 서브넷 목록을 갖습니다. ASG는 주기적으로 "지금 살아 있는 정상 인스턴스 수"를 희망 용량과 비교해 차이를 메꿉니다. 이 단순한 루프가 두 가지 일을 동시에 합니다 — 부하에 따른 확장과, 죽은 인스턴스의 자동 교체입니다.
조정의 방아쇠는 CloudWatch 지표입니다. Target Tracking은 "CPU 50%"처럼 목표를 주면 ASG가 알아서 용량을 계산하고, Step Scaling은 임계 구간별 증감폭을 직접 지정합니다. 여기서 자주 놓치는 것은 조정 근거가 CPU일 필요가 없다는 점입니다 — SQS 큐 깊이, ALB의 인스턴스당 요청 수, 커스텀 지표 모두 쓸 수 있고, 워커 아키텍처에서는 큐 깊이가 훨씬 정확한 신호입니다.
시험은 무엇을 보는가 / What the exam is testing
시험은 ASG를 "고가용성과 탄력성을 동시에 사는 도구"로 다룹니다. 그래서 ASG가 없는 단일 인스턴스 구성은 가용성 요구가 있는 문제에서 자동 탈락합니다. 또 하나의 축은 조정 근거를 올바르게 고르는 것 — 부하의 실제 신호가 무엇인지(CPU인가 큐인가 시각인가) 읽어내는 능력을 봅니다.
시험 포인트 / Exam points
Target Tracking은 "CPU 50% 유지"처럼 목표값을 주면 알아서 맞춥니다(가장 흔한 정답). Step Scaling은 임계값 구간별로 증감 폭을 다르게 줍니다. Scheduled Scaling은 "매일 오전 9시에 증설"처럼 시각이 예측될 때 씁니다.
워커가 큐를 소비하는 구조라면 CPU가 아니라 큐의 메시지 수(ApproximateNumberOfMessagesVisible) 또는 인스턴스당 백로그를 기준으로 조정해야 합니다. 이 선택지는 디커플링 문제에서 자주 정답입니다.
ASG는 EC2 상태 확인 외에 ELB 상태 확인을 사용할 수 있습니다. ELB 상태 확인을 켜야 애플리케이션이 죽었는데 인스턴스는 살아있는 경우까지 잡아내 교체합니다.
ASG를 여러 서브넷(서로 다른 AZ)에 걸쳐 두면 AZ 하나가 통째로 죽어도 서비스가 유지됩니다. "고가용성" 요구가 있으면 단일 AZ 구성 선택지는 모두 오답입니다.
자주 틀리는 함정 / Common traps
단일 AZ의 서브넷 하나만 지정한 ASG — 인스턴스는 교체되지만 그 AZ가 통째로 죽으면 서비스도 죽습니다. 고가용성 요구가 있으면 최소 2개 AZ의 서브넷을 포함해야 합니다.
EC2 상태 확인만 켜 둔 구성 — OS는 살아 있는데 애플리케이션만 죽은 인스턴스를 잡아내지 못합니다. ELB 상태 확인을 함께 켜야 교체가 일어납니다.
큐 소비 워커를 CPU 기준으로 조정하는 것 — I/O 대기가 많은 워커는 백로그가 쌓여도 CPU가 낮아 확장이 일어나지 않습니다. 큐 깊이나 인스턴스당 백로그를 써야 합니다.
헷갈리는 것 구분하기 / Telling them apart
부하의 시점을 미리 아는가로 갈립니다. "매일 오전 9시 급증", "월말 정산"처럼 시각이 예측되면 Scheduled가 선제적으로 용량을 올려 콜드 스타트 지연을 없앱니다. 예측 불가하면 Target Tracking입니다. 둘을 함께 쓰는 것도 정답이 됩니다.
Auto Scaling
Automatically adjusts instance count; solves availability and cost together
이게 뭔가요? / What is this?
An Auto Scaling Group is not a tangible resource itself — it is an automated rule that watches your EC2 instance count and adjusts it up or down as needed. Like a thermostat that reads room temperature and switches the AC on or off by itself, an ASG watches a metric such as traffic or CPU and keeps server count matched to it.
개요 / Overview
An Auto Scaling Group keeps capacity between a min and max, adding and removing instances on metrics. Phrases like "unpredictable traffic" or "automatically replace failed instances" point at ASG. The standard answer pairs it with an ALB and spans multiple AZs.
동작 원리 / How it works
An Auto Scaling Group holds a launch template (which AMI, instance type, and security groups), a capacity range (min, desired, max), and a list of subnets. It periodically compares the count of healthy running instances against desired capacity and closes the gap. That one loop delivers two things at once: load-driven scaling and automatic replacement of dead instances.
Scaling is triggered by CloudWatch metrics. Target Tracking takes a goal such as 50% CPU and computes capacity itself; Step Scaling lets you set increments per threshold band. What people miss is that the metric need not be CPU — SQS queue depth, ALB requests per target, or a custom metric all work, and for worker architectures queue depth is a far truer signal.
시험은 무엇을 보는가 / What the exam is testing
The exam treats an ASG as buying availability and elasticity in one move, so any single-instance design is automatically eliminated when the requirement mentions availability. The second axis is choosing the right scaling signal — reading whether real load shows up as CPU, queue depth, or a known schedule.
시험 포인트 / Exam points
Target Tracking holds a metric at a target such as 50% CPU — the most common correct answer. Step Scaling changes capacity by different amounts per threshold band. Scheduled Scaling fits known times, like scaling up every weekday at 9am.
When workers consume a queue, scale on queue depth (ApproximateNumberOfMessagesVisible) or backlog per instance rather than CPU. This option is frequently correct in decoupling questions.
Beyond EC2 status checks, an ASG can use ELB health checks. Enabling them catches instances where the OS is alive but the application is not, and replaces them.
Spanning subnets in different AZs keeps the service alive if an entire AZ fails. When the requirement says "highly available", any single-AZ option is wrong.
자주 틀리는 함정 / Common traps
An ASG bound to one subnet in one AZ — instances get replaced, but a whole-AZ failure still takes the service down. Availability requirements need subnets in at least two AZs.
Leaving only EC2 status checks enabled — an instance whose OS is fine but application is dead never gets replaced. Enable ELB health checks too.
Scaling queue-consuming workers on CPU — I/O-bound workers show low CPU while the backlog grows, so scaling never fires. Use queue depth or backlog per instance.
헷갈리는 것 구분하기 / Telling them apart
Decided by whether you know when load arrives. Known times such as "spikes at 9am" or "month-end close" favour Scheduled, which raises capacity ahead of the spike. Unpredictable load favours Target Tracking. Using both together is also a valid answer.
AWS SAA Hub Pro는 독립 학습 자료이며 Amazon Web Services, Inc.의 공식 서비스가 아닙니다. 시험 정책과 서비스 사양은 AWS 공식 문서를 기준으로 확인하세요.