클라우드 서비스 지도: AWS·Azure·GCP 대응표

왜 범주로 익히나

클라우드마다 서비스가 수백 개라 이름부터 외우면 끝이 없다. 그런데 범주는 거의 같다. 가상 서버, 객체 스토리지, 관리형 DB, 가상 네트워크, 큐는 어느 클라우드에나 있다. 범주와 각 범주의 역할을 먼저 익히고, 클라우드별 이름은 대응표로 찾는다. 클라우드의 기본 개념(리전·AZ, 요금 모델)은 클라우드 기초와 AWS에 있다.

범주별 대응표

AWS App Runner는 2026년 4월 30일부터 신규 고객을 받지 않는다. 컨테이너 이미지 하나로 Fargate 서비스·ALB·오토 스케일링을 한 번에 만들어 주는 ECS Express Mode가 후속 선택지다.

같은 범주라도 세부 기능과 한계는 다르다. 특히 NoSQL(DynamoDB·Cosmos DB·Firestore)은 데이터 모델과 일관성 옵션이 서로 많이 다르다.

처음 익힐 AWS 서비스

AWS에서 처음 배울 것은 대부분의 웹 서비스가 공통으로 쓰는 몇 가지다. 아래 순서로 익히면 앞의 것이 뒤의 것의 바탕이 된다.

AWS는 2006년 S3·SQS·EC2 세 서비스로 시작해 관리형 DB, 서버리스(2014년 Lambda), 컨테이너, 머신러닝·생성형 AI로 범위를 넓혀 왔다. 서비스가 계속 늘고 바뀌므로 목록을 외우기보다 위의 범주와 핵심 서비스를 단단히 하는 편이 낫다.

클라우드 로드 밸런서 고르기

로드 밸런서는 몇 계층에서 판단하나와 어디까지 퍼지나 두 축으로 고른다. 로드 밸런서 자체의 역할과 분산 알고리즘은 로드 밸런서에 있다.

빅데이터 파이프라인

데이터 파이프라인은 어느 클라우드든 다섯 단계로 이뤄진다.

flowchart LR
  A["수집(Ingestion)"] --> B["데이터 레이크<br>(원본 저장)"] --> C["처리(Computation)"] --> D["웨어하우스<br>(정제된 구조화 데이터)"] --> E["표현<br>(시각화·리포트)"]

처리 단계는 비싼 고성능 서버 한 대 대신 평범한 서버 여럿을 묶어(클러스터링) 일을 나눠 맡기고, 몇 대가 고장 나도 나머지가 이어받는 분산 처리다. 마스터가 작업을 나누고 워커가 계산하는 구조라 워커를 늘리면 처리량이 거의 비례해 는다. 클러스터를 필요할 때만 띄웠다 끄면 되므로 클라우드와 잘 맞는다(EMR, Dataproc).

레이크와 웨어하우스를 하나로 합친 레이크하우스(Delta Lake·Apache Iceberg 같은 테이블 포맷 위에서 SQL 분석)도 흔하다. 배치·스트림, ETL·ELT, 레이크·웨어하우스 같은 용어는 데이터 파이프라인과 저장소 용어에 있다.

클라우드 모니터링이 갖출 것

클라우드 기본 도구(CloudWatch, Azure Monitor, Cloud Monitoring) 대신 Prometheus·Grafana·OpenTelemetry 같은 오픈소스 표준을 쓰면 여러 클라우드를 한 화면에서 본다. 로그·메트릭·트레이스의 차이는 관측 가능성: 로그, 트레이스, 메트릭에 있다.

정리

• 클라우드는 이름이 아니라 범주로 익힌다. 범주는 세 클라우드가 거의 같다.
• AWS는 IAM → VPC → EC2·ELB → S3·RDS → Lambda·컨테이너 순으로 익히면 앞의 것이 뒤의 바탕이 된다.
• 로드 밸런서는 L4·L7과 리전·전역 두 축으로 고른다.
• 데이터 파이프라인은 수집 → 레이크 → 처리 → 웨어하우스 → 표현의 다섯 단계다.

관련 노트: AWS 클라우드 기초, 로드 밸런서, 데이터 파이프라인과 저장소 용어, AWS VPC 네트워크 구성, 클라우드 비용 최적화와 숨은 비용, 클라우드 네이티브와 코드형 인프라, 관측 가능성: 로그, 트레이스, 메트릭