클라우드 기초와 AWS: 서비스 모델, 인프라, 컴퓨팅, 보안 그룹

클라우드란

온프레미스(on-premises) 는 서버·네트워크·건물까지 회사가 직접 사서 운영하는 방식이다. 견적·구매 품의·입고·설치·네트워크 연결까지 몇 주에서 몇 달이 걸리므로 몇 년 뒤의 최대 수요를 예상해 미리 크게 산다. 덜 쓰면 장비가 놀고, 더 몰리면 그때 사도 늦다. 클라우드는 클라우드 사업자가 소유한 자원을 인터넷으로 빌려 쓰고 쓴 만큼 돈을 내는 방식이다. 인프라를 하드웨어가 아니라 API로 만들고 지우는 소프트웨어처럼 다룰 수 있다는 점이 본질적인 차이다.

바탕 기술은 가상화다. 물리 장비를 소프트웨어로 쪼개고 묶을 수 있게 되면서 자원을 잘게 나눠 팔 수 있게 됐다. 다만 가상화는 기술이고 클라우드는 그 위의 운영 방식이라, 사내 서버를 가상화했다고 클라우드가 되지는 않는다. 미국 국립표준기술연구소(NIST)의 정의가 그 차이를 다섯 가지 특징으로 보여 준다.

서비스 모델: IaaS, PaaS, SaaS

클라우드 상품은 제공자가 어디까지 관리해 주느냐로 나뉜다.

                       온프레미스  IaaS    PaaS    SaaS
애플리케이션             사용자     사용자  사용자  제공자
데이터                   사용자     사용자  사용자  사용자*
런타임·미들웨어          사용자     사용자  제공자  제공자
운영체제                 사용자     사용자  제공자  제공자
가상화                   사용자     제공자  제공자  제공자
서버·스토리지·네트워크   사용자     제공자  제공자  제공자

* SaaS라도 데이터의 소유와 그 데이터에 누가 접근하는지(계정, 공유 설정)는 사용자 책임으로 남는다.

IaaS에서 SaaS로 갈수록 운영 부담이 줄고 시작이 빠르지만, 바꿀 수 있는 것도 줄고 그 서비스에 묶인다(종속, lock-in). 서버리스와 컨테이너 서버리스는 PaaS와 SaaS 사이 어딘가에 있다(서버리스 아키텍처). DaaS(가상 데스크톱), BPaaS(업무 프로세스)처럼 「무엇이든 서비스로(XaaS)」 이름이 더 붙기도 한다. 실무에서는 섞어 쓴다. 앱은 컨테이너(IaaS나 관리형 쿠버네티스)에, DB는 관리형(PaaS)에, 메일과 문서는 SaaS로.

보안은 공동 책임 모델(shared responsibility model)을 따른다. 물리 시설·하드웨어·가상화 계층은 사업자가 맡고, 그 위는 위 표의 경계에 따라 사용자 몫이 달라진다. IaaS라면 OS 패치, 네트워크·보안 그룹 설정, 계정과 권한, 데이터 암호화가 모두 사용자 책임이다. 클라우드 보안 사고 대부분이 해커보다 사용자의 설정 오류와 권한 관리 실수에서 나오는 이유다(클라우드의 보안 위협).

클라우드를 받치는 기술

콘솔에서 클릭 몇 번으로 VPC·서브넷·보안 그룹·로드 밸런서가 생기는 것은 SDN과 NFV 덕분이다. 그리고 이 모든 자원을 API로 만들 수 있다는 것이 프로그램이 인프라를 조작하는 자동화와 코드형 인프라의 출발점이다(클라우드 네이티브와 코드형 인프라).

글로벌 인프라

flowchart TB
  r["리전(Region)<br/>서울(ap-northeast-2), 버지니아 북부(us-east-1) ..."] --> az["가용 영역(AZ)<br/>리전마다 보통 3개 이상. 서로 물리적으로 떨어져 있고 저지연 링크로 연결"]
  az --> dc["데이터 센터<br/>AZ 하나는 하나 이상의 데이터 센터"]
  el["엣지 로케이션<br/>전 세계 수백 곳. CloudFront(CDN)·Route 53(DNS)이 사용자 가까이서 응답"]

• 2026년 11월 기준 39개 리전, 124개 AZ가 운영되며 계속 늘고 있다(AWS 공식 현황).
• AZ 하나의 장애가 다른 AZ로 번지지 않게 설계되어 있으므로, 서비스는 여러 AZ에 나눠 배치해야 장애에 견딘다.
• 리전은 세 가지로 고른다: 데이터를 특정 국가에 둬야 하는 규제, 사용자와의 지연 시간, 리전마다 다른 가격과 제공 서비스.

EC2: 가상 서버

Amazon EC2는 크기를 고를 수 있는 가상 서버(인스턴스)다. OS부터 그 위의 모든 것을 직접 제어한다.

• AMI(Amazon Machine Image)로 OS와 기본 소프트웨어가 담긴 상태에서 시작한다. AWS 제공, 마켓플레이스, 커뮤니티, 직접 만든 AMI가 있다.
• 인스턴스 패밀리는 용도별로 나뉜다: 범용(M, T), 컴퓨팅 최적화(C), 메모리 최적화(R, X), 가속 컴퓨팅(GPU, P·G), 스토리지 최적화(I). 각 패밀리 안에서 large, xlarge처럼 크기를 고르고, 운영 중에도 바꿀 수 있다.
• 서버를 언제든 버리고 새로 만들 수 있는 일회용 자원으로 다루는 것이 클라우드다운 사용법이다. 인스턴스에 상태를 두지 않으면(stateless) Auto Scaling으로 수를 자유롭게 늘리고 줄일 수 있다.

관리형 서비스와 서버리스

• ECS는 AWS 고유의 관리형 컨테이너 오케스트레이션, EKS는 관리형 쿠버네티스다. 둘 다 컨테이너를 EC2 위에서 돌릴 수도, 서버 관리가 없는 Fargate 위에서 돌릴 수도 있다. 컨테이너가 많아질 때 오케스트레이션이 필요한 이유는 VM과 컨테이너에 있다.
• Lambda는 이벤트(HTTP 요청, 파일 업로드, 일정)가 올 때만 함수를 실행하고 실행 시간만큼 과금한다. 상태를 함수 밖(DB, S3)에 두는 짧은 작업에 맞는다.

보안 그룹과 RDS 접속

보안 그룹(Security Group) 은 EC2·RDS 앞에 놓인 가상 방화벽이다. 허용하지 않은 인바운드 트래픽은 모두 막으므로, 로컬 PC의 DB 클라이언트(DBeaver·DataGrip)에서 RDS에 직접 붙으려면 내 IP를 인바운드 규칙에 넣어야 한다.

1. RDS 콘솔 → 데이터베이스 → DB 식별자 → 연결 & 보안 탭 → VPC 보안 그룹 링크
2. 인바운드 규칙 편집 → 규칙 추가: 유형 PostgreSQL(5432) 또는 MySQL/Aurora(3306), 소스 내 IP

운영 DB는 퍼블릭 액세스를 끄고 VPC 안에만 둔다. 이때는 같은 VPC의 EC2(배스천 호스트)를 거쳐 SSH 터널로 접속한다. RDS 보안 그룹의 인바운드 소스는 내 IP가 아니라 배스천의 보안 그룹으로 지정한다.

flowchart LR
  c["DB 클라이언트"] --> l["localhost:3307"]
  l ==>|"SSH"| b["EC2(배스천)"]
  b --> r["RDS 엔드포인트:3306"]

ssh -i key.pem -N -L 3307:mydb.xxxx.ap-northeast-2.rds.amazonaws.com:3306 ec2-user@<배스천 퍼블릭 DNS>
# 클라이언트에서 Host=127.0.0.1, Port=3307 로 접속

GUI 클라이언트는 연결 설정의 SSH Tunnel 탭에서 같은 일을 한다. 일반 탭에는 RDS 엔드포인트·포트·DB 계정을, SSH 탭에는 배스천 주소, 기본 사용자(Amazon Linux ec2-user, Ubuntu ubuntu), .pem 키 경로를 넣는다. 열어 둔 SSH 포트조차 없애려면 AWS Systems Manager Session Manager 포트 포워딩을 쓴다.

AWS를 다루는 방법

콘솔과 CLI도 결국 같은 API를 부른다. 인프라 구성을 Terraform, AWS CloudFormation·CDK 같은 코드로 적어 두고 버전 관리하는 것을 코드형 인프라(IaC, Infrastructure as Code) 라고 한다. 손으로 클릭한 설정은 재현하기 어렵지만, 코드는 리뷰하고 되돌리고 다른 리전에 그대로 복제할 수 있다.

정리

• 클라우드는 인프라를 빌려 쓰고 API로 다루는 방식이다. NIST의 다섯 특징(셀프서비스, 네트워크 접근, 자원 풀링, 빠른 탄력성, 측정되는 서비스)이 사내 가상화와 가른다.
• IaaS → PaaS → SaaS로 갈수록 제공자가 더 많이 관리하고, 편해지는 만큼 통제와 이식성을 내준다. 보안은 그 경계를 따라 사업자와 사용자가 나눠 진다.
• 리전 > 가용 영역 > 데이터 센터. 장애에 견디려면 여러 AZ에 나눠 배치한다.
• EC2는 일회용 서버로 다루고, 사용 패턴에 따라 온디맨드·Savings Plans·스팟을 섞는다.
• 보안 그룹은 필요한 포트·소스만 연다. 운영 DB는 퍼블릭 액세스 없이 배스천 SSH 터널이나 Session Manager로 접속한다.
• 관리 부담을 줄이려면 관리형(RDS·ECS·EKS)과 서버리스(Lambda·Fargate)를 먼저 검토하고, 구성은 IaC로 남긴다.

관련 노트: 스타트업 인프라 선택 원칙, VM과 컨테이너, 고가용성과 재해 복구 설계, DBeaver에서 SQL로 데이터 다루기, 서버리스 아키텍처, 가상화, 클라우드 SLA·계약과 규제