AWS, EC2 Capacity Manager에 실시간 지원 가능성 점검과 용량 충족률 지표 추가, AWS Unified Operations에 포함: 점수는 참고용이며 용량 보장이 아니고 블로그 수치는 가상 회사의 예

2026년 11월 4일 AWS는 “What's New”에서 Amazon EC2 Capacity Manager에 두 가지 기능이 추가되었다고 발표했습니다. 실시간 “지원 가능성 점검”과 “용량 충족률 지표”입니다. 지원 가능성 점검은 인스턴스를 시작하거나 예약하지 않고도 인스턴스 유형과 가용 영역의 각 조합이 요청을 얼마나 감당할 수 있는지 High, Medium, Low로 점수를 매기고 전체 점수도 줍니다. 충족률 지표는 실제로 얼마나 용량이 제공되었는지를 AWS 조직, 계정, 리전, 태그가 붙은 워크로드별로 보여 주고 인스턴스 유형과 가용 영역별로 나눠 볼 수 있습니다. AWS는 두 기능 모두 핵심 업무를 운영하는 글로벌 기업을 위한 AWS 지원 플랜인 AWS Unified Operations에 포함되며 모든 상용 리전에서 쓸 수 있다고 합니다. 따라서 모든 EC2 사용자에게 기본 제공되는 기능은 아닙니다.

같은 날 올라온 AWS 컴퓨트 블로그는 사용 방법을 자세히 설명하지만 AnyCompany라는 가상의 회사를 예로 들었으므로, 그 안의 구체적인 수치는 모두 예시이며 실제 고객의 측정값이 아닙니다. 사용하려면 관리 계정이나 위임된 관리자로 조직 수준에서, 또는 단일 계정에서 Capacity Manager를 켜야 하고 계정이 AWS Unified Operations 적용 대상이어야 합니다. 워크로드별로 보려면 태그를 모니터링 대상 태그 키로 활성화할 수 있습니다. 용량은 vCPU로 측정합니다.

충족률은 요청 단위로 네 가지 지표가 있습니다. 요청한 vCPU, 제공된 vCPU, 요청 충족률(제공÷요청, vCPU 가중), 그리고 각 요청이 쓸 수 있게 설정된 “인스턴스 유형×영역” 조합의 평균 수이며 1보다 크면 그 요청에 유연성이 있습니다. 블로그는 같은 구성의 5분 안 재시도는 한 번으로 세고, 지표는 점검의 정확도가 아니라 실제 시작을 측정한다고 설명합니다. 예시에서 search-index 워크로드는 51,712 vCPU를 요청해 45,632를 받아 충족률 88.2%였고 평균 21개 조합을 쓸 수 있었습니다. batch-etl은 조합이 하나뿐이어서 72.8%였습니다. 조합별 비율은 분산의 이점을 포함한 요청 전체 비율보다 대개 낮습니다. 예시에서 28개 조합은 단독으로 평균 46.6%이지만 요청 전체는 88.2%이며 그 차이가 유연성이 더하는 몫입니다. use1-az5의 세 조합은 26,880 vCPU를 제공해 전체의 절반을 넘지만 각각은 68.6~82.8%에 그쳐서, 이 영역이 선택지를 늘리거나 용량을 예약해야 할 곳입니다.

지원 가능성 점검은 계획 단계에서 씁니다. 시장 유형(온디맨드 또는 스팟), 용량, 영역, 검토할 인스턴스 유형을 주거나 vCPU와 메모리 범위를 주어 유형을 맞추게 할 수 있고, 각 조합의 High, Medium, Low와 전체 점수가 나옵니다. 한 번의 점검에는 최대 10개 영역(여러 리전 가능)과 최대 100개 조합을 넣을 수 있습니다. 예시는 5가지 유형으로 3개 영역에서 인스턴스 100개를 점검했습니다. 전체 점수는 High였고, r5.16xlarge는 세 영역 모두 High, r7a.16xlarge는 use1-az6에서만 High, r6a.16xlarge는 모두 Medium, 새 후보 r7i.16xlarge는 두 영역에서 Medium, 나머지 여섯 조합은 r6i.16xlarge 전부를 포함해 Low였습니다. High는 요청에 충분하고도 남는다는 뜻, Medium은 여유가 거의 없이 감당한다는 뜻, Low는 요청한 것보다 적다는 뜻입니다.

블로그는 두 가지 제한을 말합니다. 첫째, 점수는 참고용이지 보장이 아니므로 시작할 때 용량이 반드시 있어야 한다면 용량 예약이나 미래 날짜 용량 예약을 써야 합니다. 둘째, 점검은 워크로드를 계획할 때 하고 시작할 때마다 부르지 말아야 합니다. 호출이 Capacity Manager를 켠 리전으로 가기 때문에 시작마다 호출하면 리전 간 의존성이 생기고 시간당 할당량을 소진하기 때문입니다. 예시는 놓치기 쉬운 차이도 보여 줍니다. r5.16xlarge는 use1-az5에서 지금 점검하면 High지만 과거 실적은 그곳에서 82.8%만 제공되었습니다. 점검은 현재에 대한 판단이고 충족률은 과거에 대한 사실이어서 어느 쪽도 다른 쪽을 대신하지 못합니다.

구성 면에서 블로그는 점검을 통과한 조합을 Auto Scaling 그룹의 혼합 인스턴스 정책, EC2 Fleet, Karpenter에 추가하면 유연성을 한 번 설정해 이후의 모든 시작에 이득이 되고, 평균 조합 수로 변경을 확인하라고 제안합니다. 확실함이 필요한 기준 용량에는 온디맨드 용량 예약을 쓰되, 예약은 사용 여부와 관계없이 과금되므로 기준 크기에 맞추라고 합니다. 일상적인 방법으로는 매주 충족률을 검토하고 목표에 못 미치는 워크로드의 상세를 열어 보며 변경 관리에 지원 가능성 점검을 넣는 것을 듭니다.

이 글은 AWS 자신의 제품 발표와 튜토리얼이라는 점을 기억해야 합니다. 예시 수치는 실제 고객을 대표하지 않고, 점검 점수와 실제 시작 성공률 사이의 통계적 관계는 자료에 없으며, 이 기능을 쓸 수 있는지는 먼저 계정이 AWS Unified Operations 적용 대상인지에 달려 있습니다.