AWS를 처음 접하면 서비스 종류가 너무 많아서 어디서부터 봐야 할지 막막한 경우가 많습니다. 실무에서 보면 결국 가장 자주 쓰이는 건 EC2, S3, RDS, EKS 네 가지로 압축됩니다. 이 글에서는 각 서비스가 무엇이고 언제 쓰는지를 기초 개념부터 정리합니다.
EC2는 가상 서버, S3는 객체 스토리지, RDS는 관리형 관계형 데이터베이스, EKS는 관리형 쿠버네티스 서비스입니다. 네 서비스는 각각 컴퓨팅, 스토리지, 데이터베이스, 컨테이너 오케스트레이션이라는 서로 다른 계층을 담당합니다.
AWS 서비스 분류를 먼저 이해해야 하는 이유
AWS 서비스는 200개가 넘지만, 이걸 전부 외울 필요는 없습니다. 대부분의 아키텍처는 컴퓨팅, 스토리지, 데이터베이스, 네트워킹이라는 몇 가지 계층으로 나뉘고, 각 계층마다 대표 서비스가 있습니다. EC2는 컴퓨팅, S3는 스토리지, RDS는 데이터베이스, EKS는 컨테이너 오케스트레이션 계층을 담당합니다.
실무에서 보면 이 네 가지 서비스의 역할을 정확히 구분하는 것만으로도 아키텍처 설계 대화의 절반은 따라갈 수 있습니다. 각 서비스를 자세히 살펴보겠습니다.
EC2, 가상 서버 컴퓨팅 서비스
EC2(Elastic Compute Cloud)는 클라우드 위의 가상 서버입니다. 물리 서버를 직접 구매하지 않고도 필요한 만큼 컴퓨팅 자원을 빌려 쓸 수 있게 해주는 서비스라고 보면 됩니다. 인스턴스 유형에 따라 CPU, 메모리, 네트워크 성능이 다르게 구성되어 있고, 사용한 만큼만 요금을 내는 구조입니다.
이건 직접 겪어보면 체감되는데, EC2를 처음 쓰는 사람들이 가장 헷갈려 하는 부분이 인스턴스 유형 선택입니다. t 시리즈는 저비용 범용 워크로드, m 시리즈는 균형 잡힌 범용, c 시리즈는 CPU 집약적 작업, r 시리즈는 메모리 집약적 작업에 적합합니다. 웹 서버, 애플리케이션 서버, 배치 작업 실행 환경 등 거의 모든 컴퓨팅 작업에 EC2가 쓰입니다.
| 인스턴스 계열 | 특징 | 주요 용도 |
|---|---|---|
| T 시리즈 | 버스터블 성능, 저비용 | 개발/테스트, 소규모 웹서버 |
| M 시리즈 | CPU와 메모리 균형 | 일반 애플리케이션 서버 |
| C 시리즈 | 고성능 CPU | 배치 처리, 게임 서버 |
| R 시리즈 | 대용량 메모리 | 인메모리 캐시, 데이터 분석 |
S3, 객체 스토리지 서비스
S3(Simple Storage Service)는 파일을 저장하는 객체 스토리지입니다. EC2처럼 서버를 켜두는 개념이 아니라, 버킷이라는 저장 공간에 파일을 올리고 필요할 때 꺼내 쓰는 방식입니다. 이미지, 동영상, 로그 파일, 백업 데이터 등 형태와 용량에 크게 구애받지 않고 저장할 수 있습니다.
많이들 여기서 막히더라고요. S3는 파일 시스템처럼 폴더 구조를 가진 것처럼 보이지만, 실제로는 폴더 개념이 없고 키(key)라는 문자열로 객체를 식별하는 구조입니다. 그래서 “폴더를 옮긴다”는 개념이 다른 스토리지와 다르게 동작합니다. 스토리지 클래스도 중요한 개념인데, 자주 접근하는 데이터는 Standard, 접근 빈도가 낮은 데이터는 Infrequent Access, 장기 보관용은 Glacier로 나눠서 비용을 최적화할 수 있습니다.
RDS, 관리형 관계형 데이터베이스
RDS(Relational Database Service)는 MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 같은 관계형 데이터베이스를 관리형으로 제공하는 서비스입니다. 데이터베이스 엔진을 직접 서버에 설치하고 패치하고 백업 스크립트를 짜는 대신, AWS가 그 운영 부담의 상당 부분을 대신 처리해줍니다.
초보자와 실무자의 차이가 여기서 갈립니다. 초보자는 RDS를 그냥 “관리 안 해도 되는 DB” 정도로 생각하지만, 실무자는 자동 백업 주기, 다중 AZ 구성을 통한 고가용성, 읽기 전용 복제본(Read Replica)을 활용한 부하 분산까지 함께 고려합니다. 다중 AZ는 장애 발생 시 자동으로 대기 인스턴스로 전환되는 구조이고, 읽기 전용 복제본은 조회 트래픽이 많은 서비스에서 원본 데이터베이스의 부하를 줄이는 용도로 씁니다.
실무 팁: 개발 초기 단계에는 단일 AZ로 비용을 아끼되, 서비스가 운영 단계로 넘어가면 반드시 다중 AZ 구성을 검토하세요. 장애 발생 시 복구 시간 차이가 체감상 매우 큽니다.
EKS, 관리형 쿠버네티스 서비스
EKS(Elastic Kubernetes Service)는 컨테이너 오케스트레이션 도구인 쿠버네티스를 AWS에서 관리형으로 제공하는 서비스입니다. 애플리케이션을 컨테이너 단위로 배포하고, 여러 개의 컨테이너를 자동으로 확장하거나 장애 시 재시작하는 작업을 쿠버네티스가 대신 처리해주는데, EKS는 그 쿠버네티스의 컨트롤 플레인을 AWS가 운영해주는 형태입니다.
실무에서 보면 EKS는 EC2나 S3보다 진입 장벽이 확실히 높습니다. 파드, 서비스, 디플로이먼트, 네임스페이스 같은 쿠버네티스 고유 개념을 먼저 이해해야 하고, 여기에 AWS의 IAM, VPC, 로드밸런서 개념까지 함께 엮여 있기 때문입니다. 마이크로서비스 아키텍처처럼 여러 개의 독립적인 서비스를 동시에 운영해야 하는 환경에서 EKS의 진가가 드러납니다. 단일 애플리케이션을 서버 한두 대에 올리는 정도라면 EKS까지 갈 필요 없이 EC2만으로도 충분한 경우가 많습니다.
초보자가 흔히 하는 오해와 교정
가장 흔한 오해는 “EC2에 데이터베이스를 직접 설치해서 쓰는 것과 RDS를 쓰는 것이 큰 차이가 없다”는 생각입니다. 기능적으로는 비슷해 보일 수 있지만, 백업, 패치, 장애 복구를 직접 관리해야 하는 부담이 완전히 다릅니다. 소규모 프로젝트가 아니라면 RDS 쪽이 운영 부담을 크게 줄여줍니다.
두 번째 오해는 “EKS를 써야 최신 아키텍처”라는 인식입니다. 이건 왜 실제로 더 잘 먹히는지 따져봐야 할 부분인데, 트래픽 규모나 팀의 운영 역량이 뒷받침되지 않는 상태에서 EKS를 도입하면 오히려 관리 복잡도만 늘어나는 경우가 많습니다. 서비스 규모에 맞는 선택이 항상 우선입니다.
어떤 상황에 어떤 서비스를 선택하는가
이 부분이 핵심입니다. 단일 웹 애플리케이션을 빠르게 띄워야 한다면 EC2와 RDS 조합으로 충분합니다. 정적 파일이나 대용량 미디어를 저장해야 한다면 S3가 기본 선택지입니다. 트래픽이 커지고 배포 주기가 잦아지면서 여러 서비스를 독립적으로 확장해야 하는 시점이 오면, 그때 EKS 도입을 검토하는 것이 자연스러운 순서입니다.
네 서비스를 처음부터 전부 쓰려고 하기보다는, 지금 서비스의 규모와 팀의 운영 경험에 맞춰 단계적으로 도입하는 편이 실제로는 훨씬 안정적입니다.
지금 바로 할 수 있는 일 하나는, 현재 운영 중이거나 계획 중인 서비스가 이 네 가지 중 어떤 조합으로 구성되어 있는지 직접 다이어그램으로 그려보는 것입니다. 각 서비스의 역할이 명확해지면 이후 학습 방향도 훨씬 잡기 쉬워집니다.
여러분은 AWS를 처음 배울 때 어떤 서비스부터 손에 익히셨나요? EC2와 RDS 조합, 혹은 EKS 기반 아키텍처 중 어떤 방식으로 서비스를 운영하고 계신지도 댓글로 공유해주시면 좋겠습니다.
다음 글 추천: “AWS VPC 네트워크 구성 기초 가이드”, “AWS 비용 최적화를 위한 서비스별 요금 구조 이해하기”
본 포스팅은 정보 전달 목적이며, 실제 적용 시 발생하는 책임은 사용자에게 있습니다.