AWS EC2 인스턴스 이름 이해하기
AWS EC2 인스턴스 이름, 5분만에 이해하기
AWS EC2 인스턴스 이름, 제대로 이해하고 있나요?
처음 AWS를 접하면 이렇게 생각할 수 있습니다.
"c6i.2xlarge? 이게 대체 뭘까?"
숫자와 알파벳 조합이 마치 암호처럼 느껴질지도 모릅니다.
하지만 사실, AWS EC2 인스턴스 이름은 놀랍도록 단순합니다.
"패밀리, 세대, 크기" 이 세 가지만 기억하면 됩니다.
복잡해 보이는 이름도 알고 보면 하나의 규칙을 따르고 있습니다.
이 글은 AWS 인스턴스 이름을 한 번에, 그리고 정확히 이해할 수 있도록 가장 체계적이고 구체적으로 풀어드리는 글입니다.
이제 더 이상 서버 이름 앞에서 당황하지 않을 것입니다.
이 글을 다 읽고 나면, c6i.2xlarge 같은 이름이 자연스럽게 읽히게 될 것입니다.
c6i.2xlarge
이것은 AWS 서버에서 흔히 얘기하는 서버인스턴스의 사양입니다. c6i.2xlarge 인스턴스라고 부릅니다. 이게 어떤 의미일까요?
간단한 요약
AWS EC2 인스턴스 이름 읽는 법을 요약하면 아래와 같습니다.
1) c → 인스턴스 패밀리
c(컴퓨팅), m(범용), r(메모리 최적화)
2) 6 → 세대
숫자가 클수록 최신 (5세대 → 6세대 → 7세대)
3) i → 프로세서 타입
i(Intel), a(AMD), g(Graviton)
4) 2xlarge → 크기
large(x2), xlarge(x4), 2xlarge(x8)처럼 배수로 확장
서버의 성능은 주로 CPU와 메모리에 좌우됩니다. 그리고 목적에 따라 CPU의 크기와 메모리의 크기 배율을 적절히 조합해야 합니다. 인스턴스 패밀리는 그 목적에 따른 분류를 나타내며 6은 세대, 즉 최신 서버의 세대수를 의미합니다. i는 인텔 프로세서 타입을 의미하며 이렇게 c6i를 얘기하면 어떤 서버의 몇세대, 프로세서가 무엇인지를 확인할 수 있습니다.
그리고 뒤에 있는 크기는 해당 스펙으로 정해진 CPU와 메모리의 성능을 배수로 확장해서 표시하는 개념입니다.
즉, 이름 하나로 목적, 성능, 크기까지 모두 파악이 가능합니다.
패밀리 개념의 이해
c6i.2xlarge에서 c는 인스턴스의 패밀리(Family)를 뜻합니다.
AWS EC2에서 패밀리는 그 인스턴스가 어떤 목적을 위해 최적화되어 있는지를 나타냅니다.
여기서 c는 컴퓨팅 최적화 (Compute Optimized)를 의미합니다.
CPU 성능이 뛰어나고, 연산량이 많은 작업에 적합합니다.
다른 패밀리 종류를 예를 들면 다음과 같습니다.
t: 버스트 가능한 범용 인스턴스 (가벼운 서버용)
m: 균형 잡힌 범용 인스턴스 (웹 서버, DB 서버 등)
r: 메모리 최적화 인스턴스 (데이터베이스, 캐시 서버)
i: 스토리지 최적화 인스턴스 (I/O가 많은 워크로드)
g: GPU 가속 인스턴스 (머신러닝, 그래픽 처리)
즉, c를 보면 "아, 이건 CPU를 많이 쓰는 작업을 위한 인스턴스구나"라고 이해하면 됩니다.
AWS EC2 인스턴스는 워크로드의 특성에 맞게 다양한 타입으로 구분됩니다. 그중에서도 t타입, c타입, m타입, r타입은 가장 널리 사용되는 기본 인스턴스 계열입니다. 각 타입은 CPU, 메모리, 네트워크 성능의 비율이 다르기 때문에, 어떤 목적에 맞는지 정확히 이해하는 것이 중요합니다.
c타입은 컴퓨팅 최적화 인스턴스입니다.
c5, c6i, c7i 같은 시리즈가 여기에 해당합니다. vCPU 비율이 매우 높고, CPU 성능이 중요한 워크로드를 위해 설계되었습니다. 고성능 웹 서버, 배치 처리 서버, 머신러닝 전처리 작업, 고부하 API 서버 등에 적합합니다. 메모리보다는 CPU 성능을 최대한 활용하는 용도에 최적화되어 있습니다.
t타입은 버스트 가능한 성능을 가진 범용 인스턴스입니다.
t2, t3, t3a, t4g 시리즈가 있으며, 기본적으로 CPU 성능이 필요할 때만 터보 모드처럼 올라갔다가 평소에는 리소스를 절약합니다. 일반적인 웹 서버, 테스트 서버, 저부하 워크로드에 적합합니다. 단, 오랜 시간 고성능을 지속적으로 요구하는 경우에는 CPU 크레딧을 소진할 수 있어 주의가 필요합니다. 이 때는 추가 비용이 발생하게 됩니다.
m타입은 범용 균형형 인스턴스입니다.
m5, m6i, m7i 같은 시리즈로 구성되어 있으며, CPU와 메모리 비율이 1:4 정도로 균형 있게 설계되었습니다. 특별히 CPU나 메모리 중 하나가 과도하게 필요한 것은 아니지만, 둘 다 평균 이상으로 필요한 워크로드에 잘 맞습니다. 기업 내부 시스템, 애플리케이션 서버, 중간 규모 데이터베이스 서버 등에 주로 사용됩니다. 특별한 이유가 없다면 처음 구축할 때 기본 선택지가 되는 경우가 많습니다.
r타입은 메모리 최적화 인스턴스입니다.
r5, r6i, r7i 같은 시리즈가 있으며, CPU 대비 메모리 비율이 매우 높습니다. 데이터를 많이 다루는 인메모리 캐시 서버, 대규모 데이터베이스, 메모리 중심의 애플리케이션에 적합합니다. 특히 Redis, Memcached, SAP HANA와 같은 워크로드에서는 r타입이 사실상 필수입니다. CPU 성능도 나쁘지 않지만, 상대적으로 메모리를 최대한 활용하는 설계입니다.
인스턴스 세대의 이해
c6i.2xlarge에서 6i는 인스턴스의 세대(Generation)와 프로세서 타입을 나타냅니다.
6은 6세대를 의미합니다. 최근에는 7세대까지 출시된 상황입니다.
EC2 인스턴스는 세대를 거듭할수록 더 빠르고 더 저렴해집니다. 6 이후에 붙게 되는 i는 CPU 종류로 여기서는 Intel Xeon Scalable 3세대 프로세서를 의미합니다. 저희는 주로 i 타입을 사용하고 있습니다만 최근에는 g 타입으로 넘어가면서 비용절감을 달성하고 있습니다.
1) 5세대 (예: c5, m5, r5)
Intel Xeon Scalable (Skylake) 프로세서 기반
2) 6세대 (예: c6i, m6i, r6i)
Intel Xeon Scalable 3세대 (Ice Lake) 기반
3) 6a 세대 (예: m6a, r6a)
AMD EPYC Milan 프로세서 기반
4) 6g 세대 (예: c6g, m6g, r6g)
AWS Graviton2 (ARM 기반) 프로세서 사용
5) 7세대 (예: c7i, r7i)
Intel Xeon Scalable 4세대 (Sapphire Rapids) 기반, 일부 최신 제품은 이미 7세대 출시
CPU의 종류는 아래와 같습니다.
이와 같이 이름을 보면 세대와 프로세서를 연결해서 쉽게 이해할 수 있습니다
예를 들어서,
c5.large: 5세대, Intel Skylake CPU, 컴퓨팅 최적화, 작은 크기
m6a.xlarge: 6세대, AMD EPYC CPU, 범용 인스턴스, 중형 크기
r6g.4xlarge: 6세대, Graviton2 ARM CPU, 메모리 최적화, 큰 크기
c7i.2xlarge: 7세대, Intel 4세대 Xeon, 컴퓨팅 최적화, 대형 크기
이렇게 이름만 봐도
"어떤 세대이고, 어떤 CPU이고, 어떤 목적용이고, 어느 정도 크기"인지 파악할 수 있습니다.
6i를 보면 "6세대 Intel CPU를 쓴 고성능 인스턴스구나"라고 알 수 있습니다.
가격 대비 성능(가성비) 기준으로 보면, g타입(Graviton 기반)은 "대부분의 경우 가장 좋은 선택"이라고 볼 수 있습니다.
Graviton 인스턴스는 같은 세대의 Intel이나 AMD 인스턴스보다 시간당 요금이 평균 20~40% 더 저렴합니다.
그러면서 성능도 좋은데요. Graviton2(g) 기준으로는 같은 세대 Intel 기반 대비 7배 높은 성능 효율을 달성했습니다. Graviton3(gr)는 여기서 또 25% 정도 성능이 향상되었습니다.
이는 낮은 전력 소모로 동일 작업을 처리할 수 있어서, 장기 운영 시 비용 절감 효과가 크기 때문입니다.
단 Gravition 인스턴스의 경우 x86 전용 소프트웨어는 호환성 문제가 있습니다.
Graviton은 ARM 아키텍처 기반이라 Intel/AMD x86용 바이너리를 그대로 가져다 쓸 수 없습니다.
즉,
별도 ARM 빌드를 지원하지 않는 상용 소프트웨어
오래된 라이브러리, 드라이버
를 사용하는 경우 문제가 생길 수 있습니다.
만약 Graviton으로 비용절감을 하고 싶은 경우 운영체제와 어플리케이션 호환성 체크가 필요합니다.
대부분의 Linux 배포판(Ubuntu, Amazon Linux, RHEL 등)은 ARM 버전을 잘 지원합니다.
하지만 특수한 미들웨어나 모니터링 에이전트는 ARM 지원 여부를 확인해야 합니다.
또한 아주 높은 클럭 주파수가 필요한 단일 스레드 작업같이 특정 워크로드는 x86이 더 빠를 수 있습니다.
사이즈의 이해
WS 인스턴스 크기 체계도 규칙은 매우 간단합니다.
"기본 large를 기준으로 2배, 4배, 8배씩 커진다."
CPU 수, 메모리 용량, 가격도 거의 정비례한다고 생각하면 됩니다.
xlarge는 인스턴스의 크기(Size)를 나타냅니다.
크기는 CPU 수와 메모리 양을 상대적으로 표현한 것입니다
large는 기준 크기입니다.
xlarge는 그 두 배라는 의미입니다.
예를 들면 c6i.2xlarge의 스펙은 대략 아래와 같습니다
vCPU 8개
메모리 16GiB
네트워크 대역폭 중간 정도
비슷한 크기 체계를 쉽게 설명하면 이렇게 됩니다.
large: 소형 (vCPU 2개)
xlarge: 중형 (vCPU 4개)
2xlarge: 대형 (vCPU 8개)
4xlarge: 초대형 (vCPU 16개)
8xlarge: 슈퍼대형 (vCPU 32개)
숫자가 2배, 4배, 8배 커질수록 CPU와 메모리도 그에 비례해서 증가합니다. 그리고 비용도 마찬가지입니다. 2배씩 증가합니다.
일반적으로 우리는 c, r, m 타입을 많이 사용한다고 했습니다. 각 사이즈별로 메모리까지 비교하면 아래와 같습니다.
인스턴스 선택 시 주의할 점
1)워크로드에 따라 인스턴스 타입을 신중하게 선택해야 합니다.
CPU 집약적 작업(예: 대규모 연산, 머신러닝 전처리 등): c타입(컴퓨팅 최적화)
메모리 집약적 작업(예: 대규모 데이터베이스, 인메모리 캐시): r타입(메모리 최적화)
CPU와 메모리 균형이 필요한 경우: m타입(범용)
저부하, 테스트, 비용 절감이 중요한 경우: t타입(버스트 가능)
2)Graviton(g타입, ARM 기반) 인스턴스는 가격 대비 성능이 매우 뛰어나지만, x86 전용 소프트웨어는 호환성 문제가 있을 수 있습니다.
운영체제, 미들웨어, 주요 애플리케이션이 ARM 아키텍처를 지원하는지 반드시 확인하세요.
공식 문서, 커뮤니티, 또는 AWS Graviton 호환성 체크 가이드를 참고하면 도움이 됩니다.
3)인스턴스 크기는 필요에 따라 유연하게 조정할 수 있으니, 처음에는 작은 사이즈로 시작해 점진적으로 확장하는 것도 좋은 전략입니다.
더 알아보기
이 자료들을 참고하면, 실제 환경에 맞는 인스턴스 선택과 운영에 큰 도움이 될 것입니다.
FinOps 커뮤니티에 함께 하실래요?
저는 최근 48%, $36000의 AWS 비용절감을 달성했습니다.
클라우드 비용을 효율화하고 싶은 분들, 비슷한 고민을 나누고 싶다면 제가 운영 중인 AWS-FINOPS-KR Slack 커뮤니티에 참여하세요. 실제 절감 사례, 질문, 전략 공유를 나누실 수 있습니다.
