AWS를 처음 보면 서비스 이름부터 많다.
EC2, S3, RDS, VPC, IAM, Lambda, CloudFront, Route 53, ECS, EKS 같은 이름이 계속 나온다. 하나씩 보면 별개의 서비스처럼 보이지만 실제 서비스를 운영할 때는 여러 서비스를 조합해서 하나의 인프라를 만든다.
그래서 AWS는 서비스 목록을 외우는 것보다 애플리케이션이 실제 서버에서 어떻게 실행되고 외부 요청이 어떻게 들어오는지를 기준으로 보는 게 이해하기 편하다.
간단한 웹 서비스라면 다음과 같은 구조가 될 수 있다.
그리고 이 인프라 전체가 네트워크와 권한 체계 안에서 동작한다.
AWS를 공부할 때는 개별 서비스보다 이런 관계를 먼저 잡는 게 좋다.
AWS가 하는 일
AWS는 클라우드 컴퓨팅 서비스다.
직접 서버를 구매해서 데이터센터에 설치하는 대신 AWS에서 필요한 컴퓨팅 자원, 저장 공간, 데이터베이스, 네트워크 등을 만들어 사용할 수 있다.
예전에는 서버를 운영하려면 직접 서버를 준비해야 했다.
서버 구매 -> 데이터센터 설치 -> 네트워크 구성 -> OS 설치 -> 애플리케이션 배포
AWS에서는 이런 인프라를 콘솔이나 API를 통해 생성하고 관리할 수 있다.
AWS -> 컴퓨팅 -> 저장소 -> 데이터베이스 -> 네트워크 -> 보안 -> 모니터링
필요한 자원을 사용하고 상황에 따라 확장하거나 축소할 수 있다는 것이 클라우드의 큰 특징이다.
Region과 Availability Zone
AWS 인프라를 이해하려면 Region과 Availability Zone부터 알아두는 게 좋다.
Region은 AWS의 물리적인 지리적 영역이다.
예를 들어 서울 Region을 사용할 수 있고, 하나의 Region 안에는 여러 Availability Zone(AZ)이 존재한다.
AZ는 서로 독립적인 데이터센터 인프라로 구성된다.
하나의 AZ에 모든 서버를 몰아넣으면 해당 AZ에 문제가 발생했을 때 서비스 전체가 영향을 받을 수 있다.
그래서 중요한 서비스는 여러 AZ에 분산해서 구성하는 경우가 많다.
이런 구조를 통해 특정 AZ에 장애가 발생하더라도 다른 AZ의 서버로 서비스를 유지할 수 있다.
EC2
EC2는 AWS에서 제공하는 가상 서버다.
직접 서버 하나를 빌린다고 생각하면 이해하기 쉽다.
EC2를 생성할 때는 CPU, 메모리, 스토리지, OS 등을 선택한다.
그 위에 애플리케이션을 설치해서 실행한다.
예를 들어 Spring Boot 애플리케이션을 EC2에서 실행할 수 있다.
사용자 -> EC2 -> Java -> Spring Boot
EC2는 자유도가 높다는 장점이 있다.
직접 OS에 접속해서 패키지를 설치하거나 프로세스를 관리할 수 있다.
반대로 서버 관리도 직접 해야 한다.
OS 업데이트, 프로세스 관리, 배포, 스케일링 같은 작업을 직접 고려해야 한다.
AMI
EC2를 생성할 때 OS와 기본 실행 환경을 이미지로 만들어 사용할 수 있다.
이 이미지가 AMI(Amazon Machine Image)다.
애플리케이션 실행에 필요한 환경을 미리 구성하고 이를 이미지로 만들어두면 동일한 환경의 EC2를 여러 개 생성할 수 있다.
서버를 하나씩 처음부터 구성하는 대신 동일한 서버 환경을 복제할 수 있다는 점에서 의미가 있다.
S3
S3는 객체 스토리지다.
이미지, 동영상, 로그, 백업 파일, 정적 파일 같은 데이터를 저장하는 용도로 많이 사용한다.
EC2의 디스크에 파일을 저장하는 것과는 성격이 다르다.
S3는 서버와 분리된 저장소이기 때문에 서버가 여러 대로 늘어나더라도 파일을 하나의 저장 공간에서 관리할 수 있다.
예를 들어 사용자가 프로필 이미지를 업로드하면 애플리케이션 서버에 직접 저장하기보다 S3에 저장하고 데이터베이스에는 파일의 경로나 식별자 같은 정보를 저장하는 구조를 사용할 수 있다.
RDS
RDS는 관계형 데이터베이스를 관리해주는 서비스다.
MySQL, PostgreSQL 등의 데이터베이스를 사용할 수 있다.
EC2에 직접 MySQL을 설치하는 방법도 있지만 RDS를 사용하면 데이터베이스 운영에 필요한 여러 관리 기능을 AWS가 제공하는 형태로 사용할 수 있다.
애플리케이션 서버와 데이터베이스 서버를 분리하는 구조가 일반적이다.
EC2 -> RDS
이렇게 하면 애플리케이션 서버를 여러 대로 늘리더라도 데이터베이스는 별도로 관리할 수 있다.
VPC
AWS에서 서버를 만들다 보면 네트워크를 구성해야 한다.
이때 기본이 되는 것이 VPC(Virtual Private Cloud)다.
VPC는 AWS 안에서 논리적으로 분리된 네트워크 공간이다.
하나의 VPC 안에서 Public Subnet과 Private Subnet을 나눌 수 있다.
외부에서 직접 접근할 필요가 없는 서버는 Private Subnet에 배치하는 식이다.
Public Subnet과 Private Subnet
Public과 Private를 단순히 “인터넷이 된다 / 안 된다”로 외우면 부족하다.
핵심은 인터넷 게이트웨이를 통한 인터넷 경로가 라우팅 테이블에 존재하는가다.
Public Subnet에 있는 리소스는 인터넷으로 연결될 수 있도록 구성할 수 있다.
Internet -> Internet Gateway -> Public Subnet -> EC2
Private Subnet은 외부에서 직접 접근할 필요가 없는 서버를 배치하는 데 사용한다.
Internet -X-> Private Subnet -> EC2 / RDS
다만 Private Subnet의 서버가 외부로 나가는 통신이 필요할 수 있다.
이 경우 NAT Gateway 등을 이용할 수 있다.
Private Subnet -> NAT Gateway -> Internet
외부에서 내부로 들어오는 통신과 내부에서 외부로 나가는 통신은 구분해서 봐야 한다.
Security Group
AWS에서 서버에 접근할 수 있는 트래픽을 제어하는 대표적인 기능이 Security Group이다.
예를 들어 웹 서버에는 HTTP와 HTTPS를 외부에 허용하고 SSH는 특정 IP에서만 접근하도록 구성할 수 있다.
Security Group은 EC2 같은 리소스에 연결해서 사용한다.
데이터베이스에도 접근 제어를 설정할 수 있다.
예를 들어 RDS는 애플리케이션 서버의 Security Group에서 오는 트래픽만 허용하는 식으로 구성할 수 있다.
EC2 Security Group -> 3306 -> RDS Security Group
이런 방식으로 애플리케이션 서버에서만 데이터베이스에 접근하도록 제한할 수 있다.
IAM
IAM은 AWS의 권한 관리 서비스다.
AWS에서는 서버, 데이터베이스, S3 같은 리소스에 대한 권한을 관리해야 한다.
예를 들어 애플리케이션 서버가 S3에 파일을 업로드해야 한다고 하자.
애플리케이션 코드에 AWS Access Key를 직접 넣는 것은 좋은 방법이 아니다.
대신 IAM을 통해 필요한 권한을 부여할 수 있다.
EC2 -> IAM Role -> S3 접근 권한
IAM에서는 User, Group, Role, Policy 같은 개념을 사용한다.
특히 AWS 리소스가 다른 AWS 서비스를 호출해야 하는 경우 IAM Role을 자주 사용한다.
권한은 필요한 것만 주는 것이 기본이다.
필요한 권한 -> 최소 권한 -> 보안 강화
AWS에서 보안을 구성할 때 중요한 원칙이다.
Load Balancer
서버가 하나일 때는 요청을 바로 서버로 보내면 된다.
Client -> EC2
서버가 여러 대가 되면 요청을 적절히 분배해야 한다.
AWS에서는 Elastic Load Balancing을 사용할 수 있다.
Load Balancer는 여러 서버로 트래픽을 분산하고 서버의 상태를 확인해서 정상적인 서버로 요청을 전달할 수 있다.
이를 기반으로 여러 애플리케이션 서버를 운영하는 구조를 만들 수 있다.
Auto Scaling
서버가 여러 대 있다고 해서 항상 같은 수의 서버가 필요한 것은 아니다.
트래픽이 적을 때는 서버 2대를 사용하고 트래픽이 증가하면 서버를 더 추가할 수 있다.
트래픽 증가 -> EC2 추가 -> 처리 용량 증가
트래픽 감소 -> EC2 제거 -> 비용 감소
Load Balancer와 함께 사용하면 일반적인 웹 서비스의 확장 구조를 만들 수 있다.
Auto Scaling은 트래픽이나 CPU 사용량 같은 조건을 기준으로 인스턴스를 자동으로 늘리거나 줄이는 구조를 만들 수 있다.
Route 53
Route 53은 AWS의 DNS 서비스다.
사용자가 example.com 같은 도메인으로 접속했을 때 실제 서비스 위치를 찾을 수 있도록 DNS를 관리한다.
example.com -> Route 53 -> Load Balancer
도메인 이름과 AWS 리소스를 연결하는 역할이라고 생각하면 된다.
CloudFront
CloudFront는 AWS의 CDN 서비스다.
사용자가 서버에서 멀리 떨어져 있으면 매번 원본 서버까지 요청을 보내야 한다.
CDN은 콘텐츠를 여러 Edge Location에 캐시해서 사용자와 가까운 위치에서 전달할 수 있다.
이미지나 JavaScript, CSS 같은 정적 파일을 제공할 때 많이 사용한다.
S3와 CloudFront를 함께 사용하는 구조도 흔하다.
User -> CloudFront -> S3
Lambda
EC2가 서버를 직접 운영하는 방식이라면 Lambda는 서버를 직접 관리하지 않고 코드를 실행하는 방식에 가깝다.
함수를 등록해놓고 특정 이벤트가 발생했을 때 실행할 수 있다.
Event -> Lambda -> Code 실행
예를 들어 S3에 파일이 업로드되었을 때 Lambda를 실행할 수 있다.
S3 파일 업로드 -> Lambda -> 이미지 처리
짧게 실행되는 이벤트 기반 작업이나 서버를 직접 운영할 필요가 없는 기능에 적합하다.
반대로 항상 실행되고 있어야 하는 복잡한 서버 애플리케이션을 Lambda로 억지로 구성할 필요는 없다.
ECS와 Docker
Docker 컨테이너를 AWS에서 운영하려면 ECS 같은 서비스를 사용할 수 있다.
Docker에서는 애플리케이션과 실행 환경을 이미지로 패키징한다.
Docker Image -> Container -> Application
ECS는 이런 컨테이너를 AWS에서 실행하고 관리하기 위한 서비스다.
EC2에서 직접 애플리케이션을 실행하는 것과 비교하면 배포 환경을 이미지 단위로 관리하기 편해진다.
ECS는 EC2를 기반으로 실행할 수도 있고 Fargate를 사용하면 서버 인프라를 직접 관리하지 않고 컨테이너를 실행할 수도 있다.
서버리스
AWS에서 서버리스라는 말을 자주 볼 수 있다.
서버가 존재하지 않는다는 뜻은 아니다.
서버를 직접 관리하는 책임이 줄어든다는 의미에 가깝다.
대표적으로 Lambda, S3, DynamoDB, API Gateway 같은 서비스를 조합해서 서버리스 애플리케이션을 만들 수 있다.
서버를 직접 생성하고 관리하는 대신 AWS가 제공하는 서비스를 조합해서 애플리케이션을 구성한다.
CloudWatch
서비스를 운영하면 서버가 정상적으로 동작하고 있는지 확인해야 한다.
CloudWatch는 AWS 리소스의 모니터링과 로그 관리 등에 사용하는 서비스다.
예를 들어 EC2의 CPU 사용량이나 애플리케이션 로그 등을 확인할 수 있다.
특정 지표가 기준치를 넘었을 때 Alarm을 발생시키는 식으로 운영 환경을 구성할 수도 있다.
하나의 웹 서비스를 구성한다면
지금까지 나온 서비스를 실제 웹 서비스 구조에 넣어보면 다음과 같은 형태가 된다.
서버가 여러 AZ에 분산되어 있다면 다음과 같이 구성할 수 있다.
네트워크는 VPC 안에서 구성한다.
IAM으로 AWS 리소스에 필요한 권한을 부여한다.
EC2 -> IAM Role -> S3
Security Group으로 네트워크 접근을 제한한다.
Load Balancer -> EC2 -> RDS
CloudWatch를 통해 서비스 상태와 로그를 관찰한다.
EC2 / RDS / Application -> CloudWatch -> Metrics / Logs / Alarm
서비스 규모가 커지면 Auto Scaling이나 ECS 같은 방식으로 애플리케이션 실행 환경을 확장할 수 있다.
AWS에서 중요한 건 서비스보다 구조
AWS를 처음 공부하면 서비스가 너무 많아서 전부 알아야 할 것처럼 느껴진다.
그럴 필요는 없다.
먼저 웹 애플리케이션 하나를 운영한다고 생각하면 된다.
Domain -> DNS -> Load Balancer -> Application Server -> Database
파일이 필요하면 S3를 붙인다.
Application -> S3
서버가 여러 대 필요하면 Load Balancer와 Auto Scaling을 붙인다.
외부에서 직접 접근하면 안 되는 자원은 Private Subnet에 배치하고 Security Group으로 접근을 제한한다.
AWS 리소스가 다른 AWS 서비스를 사용할 때는 IAM으로 권한을 부여한다.
AWS Resource -> IAM Role -> AWS Service
서비스가 동작하는 상태는 CloudWatch로 관찰한다.
Application -> CloudWatch -> Metrics / Logs / Alarm
이 정도 구조가 잡히면 AWS 서비스 이름을 봤을 때도 어디에 사용되는지 감이 온다.
AWS를 공부하면서 같이 알아야 할 것
AWS는 클라우드 서비스지만 결국 컴퓨터 시스템과 네트워크 위에서 동작한다.
그래서 다음 개념을 알고 있으면 AWS를 이해하기 훨씬 수월하다.
Linux -> Process -> Network -> TCP / HTTP -> DNS -> IP / Port -> Database -> Docker -> Cloud
특히 VPC를 공부할 때는 IP, Subnet, Routing, NAT, Gateway를 이해해야 한다.
EC2를 제대로 사용하려면 Linux와 프로세스 관리에 대한 이해가 필요하다.
RDS를 사용하려면 데이터베이스를 알아야 하고, ECS를 사용하려면 Docker와 Container 개념이 필요하다.
AWS가 이런 기술을 없애는 것은 아니다.
AWS는 이미 존재하는 컴퓨팅, 네트워크, 스토리지 등의 기술을 관리 가능한 서비스 형태로 제공하는 쪽에 가깝다.
정리
AWS를 공부하면서 가장 먼저 익혀야 할 것은 서비스 이름이 아니다.
애플리케이션이 AWS 위에서 어떤 구조로 실행되는지를 이해하는 것이 먼저다.
전체적인 웹 서비스 흐름은 다음처럼 볼 수 있다.
User -> Route 53 -> CloudFront -> Load Balancer -> EC2 / ECS / Lambda -> RDS / S3
그리고 이 전체 구조가 네트워크 안에서 동작한다.
권한은 IAM이 담당한다.
AWS Resource -> IAM Role / Policy -> AWS Service
서비스 상태와 로그는 CloudWatch가 담당한다.
Application / AWS Resource -> CloudWatch -> Metrics / Logs / Alarm
서비스마다 역할은 다르지만 결국 목적은 하나의 애플리케이션을 안정적으로 실행하고 운영하는 것이다.
AWS를 외우려고 하면 서비스가 끝없이 늘어난다.
반대로 하나의 서비스를 운영하는 데 필요한 컴퓨팅, 스토리지, 데이터베이스, 네트워크, 보안, 모니터링으로 나눠서 보면 훨씬 단순해진다.
AWS를 이해하는 핵심 흐름은 결국 이것이다.
