Vuildy바이브 코딩을 실제 서비스로설계부터 클라우드 배포와 운영까지 함께합니다.
홈콘텐츠공개 견적상담하기
아키텍처

EC2 2대로 서비스 운영하기 - 데이터베이스 분리

2개의 서버에 각각 나누어서 웹/애플리케이션 서버를 함께 사용하고, 부하 분산을 위해서 DB 서버를 분리하여 사용하는 방법입니다.

2026. 9. 6.
EC2 2대로 서비스 운영하기 - 데이터베이스 분리 대표 이미지
ARCHITECTURE GUIDE

그림으로 이해하는 구성

그림을 확대하면서 아래의 구성 설명을 확인하세요.

아키텍처마지막 변경 2026. 10. 19. 오후 4:19:48 (KST)
75%
AZ - 2a
AZ - 2c
VPC
Internet Gateway
Elastic IP
Public Subnet
Public Subnet
Client
EC2 - Amazon Linux
Nginx
Next.js
Squid Proxy
EC2
PostgreSQL
1
2
3
inbound trafficip assignmentoutbound traffic

1. 아키텍처 다이어그램


이번에는 하나의 EC2에 애플리케이션과 데이터베이스를 모두 구성했던 이전 방식에서 한 단계 확장하여, EC2 2대를 사용해 애플리케이션 서버와 데이터베이스 서버를 분리하는 구조를 살펴봅니다.

바이브 코딩으로 만든 서비스를 AWS에 배포하고 실제 운영을 시작한다면, 애플리케이션과 데이터베이스를 서로 다른 서버로 분리하는 것을 생각해볼 수 있습니다.

이번 구성에서는 첫 번째 EC2에 Nginx, Next.js, Squid Proxy를 구성하고, 두 번째 EC2에는 PostgreSQL을 구성합니다. 두 서버를 서로 다른 가용 영역(AZ)에 배치하여 AWS의 네트워크 구조도 함께 살펴봅니다.


2. 아키텍처 살펴보기


사용자의 요청은 인터넷을 통해 Internet Gateway를 거쳐 첫 번째 EC2로 전달됩니다. EC2의 Nginx가 요청을 받아 Next.js 애플리케이션으로 전달하고, Next.js에서 데이터가 필요한 경우 두 번째 EC2의 PostgreSQL에 연결합니다.

외부 API 등에 특정 IP로 요청을 보내야 하는 경우를 고려하여 첫 번째 EC2에는 Elastic IP를 연결하고 Squid Proxy도 함께 구성했습니다.

[1] VPC - default
  • VPC(Virtual Private Cloud)는 AWS에서 사용하는 가상 네트워크 공간입니다. AWS 계정을 생성하면 기본 VPC가 준비되어 있습니다.
  • VPC에서 인터넷을 사용하기 위해 Internet Gateway가 연결되어 있습니다.
  • 기본 VPC에는 가용 영역별로 Public Subnet이 만들어져 있으며, 여기에 EC2 인스턴스를 생성할 수 있습니다.
  • AZ(Availability Zone)는 물리적으로 분리된 데이터센터 영역입니다.
  • 그림에서는 2a와 2c 두 개의 가용 영역을 사용하여 각각 EC2를 배치했습니다.
  • 두 EC2는 같은 VPC 내부에 있기 때문에 Private IP를 이용하여 서로 통신할 수 있습니다.

[2] EC2 - Web/Application Server
첫 번째 EC2는 사용자의 요청을 받아 실제 애플리케이션을 실행하는 서버입니다.
  • Amazon Linux 2023을 사용합니다.
  • Elastic IP를 연결하여 고정된 Public IPv4 주소를 사용합니다.
  • Nginx를 설치하여 웹 서버와 Reverse Proxy 역할을 담당합니다.
  • Next.js 애플리케이션을 실행하여 서비스의 기능을 처리합니다.
  • PM2를 사용하면 Next.js 프로세스를 백그라운드에서 안정적으로 실행하고 관리할 수 있습니다.
  • Squid Proxy를 구성하면 외부 서비스와 통신할 때 지정된 Elastic IP를 통해 요청하도록 구성할 수 있습니다.

[3] EC2 - Database Server
두 번째 EC2는 애플리케이션에서 사용하는 데이터를 저장하는 데이터베이스 전용 서버입니다.
  • Amazon Linux 기반의 별도 EC2를 사용합니다.
  • PostgreSQL을 설치하고 서비스에 필요한 DB와 사용자를 생성합니다.
  • Web/Application EC2에서 PostgreSQL로 연결합니다.
  • 인터넷을 통한 DB 접근보다는 VPC 내부 Private IP를 이용하여 연결하는 것이 좋습니다.
  • 보안 그룹에서 PostgreSQL 포트(기본 5432)를 인터넷 전체에 공개하지 않고, Web/Application Server에서만 접근할 수 있도록 제한합니다.

이렇게 구성하면 기존 1대 구성과 달리 애플리케이션과 데이터베이스의 역할이 분리됩니다.

3. EC2 1대 구성과 무엇이 다를까요?


EC2 1대로 구성하면 Nginx, Next.js, PostgreSQL이 모두 하나의 서버 자원을 공유합니다. 구조가 단순하고 비용이 저렴하다는 장점이 있지만, 애플리케이션의 CPU나 메모리 사용량이 증가하면 PostgreSQL에도 영향을 줄 수 있습니다.

EC2 2대로 분리하면 다음과 같이 역할이 명확해집니다.
사용자
  ↓
Web/Application EC2
└ Nginx / Next.js
  ↓
Database EC2
└ PostgreSQL


애플리케이션과 DB가 각각 독립적인 CPU, 메모리, 디스크를 사용하므로 한쪽의 리소스 사용량이 다른 쪽에 미치는 영향을 줄일 수 있습니다.

또한 애플리케이션 서버를 재시작하거나 배포하는 과정에서도 데이터베이스 서버는 계속 별도로 동작합니다.

다만 EC2를 2대로 만들었다고 해서 바로 고가용성(HA)이 되는 것은 아닙니다. 그림처럼 서로 다른 AZ에 배치하더라도 각각의 역할을 담당하는 EC2가 한 대씩이기 때문에 어느 한쪽에 장애가 발생하면 서비스에 영향을 받습니다.


4. 배포 과정 살펴보기


서버가 2대로 분리되면서 첫 번째 EC2에는 애플리케이션 환경을, 두 번째 EC2에는 데이터베이스 환경을 각각 구성해야 합니다.

(1) EC2 2대 생성
  • Web/Application Server용 EC2 생성
  • Database Server용 EC2 생성
  • 필요하다면 서로 다른 가용 영역에 배치
  • 각 EC2에 필요한 EBS 스토리지 설정

(2) Web/Application EC2 구성
  • SSH를 통해 EC2 연결
  • Nginx 설치
  • Node.js LTS 버전 설치
  • PM2 설치
  • Next.js 프로젝트 배포
  • 필요할 경우 Squid Proxy 설치
  • Elastic IP 연결

(3) Database EC2 구성
  • SSH를 통해 EC2 연결
  • PostgreSQL 설치
  • 서비스 DB 생성
  • DB 사용자 및 비밀번호 생성
  • PostgreSQL 외부 연결 설정
  • Web/Application EC2에서만 DB에 접근할 수 있도록 보안 그룹 설정

(4) Next.js와 PostgreSQL 연결
Next.js의 데이터베이스 연결 정보를 Database EC2의 Private IP 기준으로 설정합니다.

예를 들어 DB 서버의 Private IP가 172.31.x.x라면 인터넷을 거치지 않고 VPC 내부 네트워크를 통해 PostgreSQL에 연결할 수 있습니다.

DB 서버의 Public IP를 이용하여 연결할 필요가 없습니다.

(5) 도메인 연결
  • Web/Application EC2에 Elastic IP 연결
  • 도메인 DNS 관리에서 A 레코드 등록
  • Nginx 가상호스트 설정
  • SSL 인증서 설치
  • HTTPS 접속 확인

(6) 테스트
마지막으로 전체 흐름을 확인합니다.
사용자
  ↓
Internet Gateway
  ↓
Nginx
  ↓
Next.js
  ↓
PostgreSQL


브라우저에서 서비스를 접속하고 로그인, 데이터 조회·등록·수정 등 DB를 사용하는 기능까지 테스트합니다.


5. 보안 그룹도 분리합니다


EC2를 2대로 구성할 때 중요한 부분 중 하나가 보안 그룹(Security Group)입니다.

Web/Application Server는 인터넷에서 사용자의 요청을 받아야 하기 때문에 일반적으로 HTTP 80, HTTPS 443 포트를 허용합니다. SSH 22 포트는 관리자 IP에서만 접근할 수 있도록 제한하는 것이 좋습니다.

Database Server의 PostgreSQL 5432 포트는 인터넷 전체에 공개하지 않습니다.

가능하면 다음과 같이 구성합니다.
Web/Application Security Group
  ↓
Database Security Group : TCP 5432 허용


즉, 특정 IP 주소 대신 Web/Application EC2가 사용하는 Security Group을 DB Security Group의 Source로 지정할 수 있습니다.

이렇게 하면 애플리케이션 서버에서만 PostgreSQL에 접근할 수 있어 DB를 외부에 직접 노출하는 것보다 안전하게 구성할 수 있습니다.


6. 운영 관리는 필요합니다


서버가 2대로 늘어나면서 관리해야 할 대상도 늘어납니다. 애플리케이션 서버뿐만 아니라 데이터베이스 서버의 상태와 백업도 함께 관리해야 합니다.
  • 각 EC2의 CPU, 메모리, 디스크 사용량 확인
  • Nginx 및 Next.js 로그 모니터링
  • PostgreSQL 로그 및 디스크 사용량 확인
  • 애플리케이션 소스 주기적 백업
  • 사용자 업로드 데이터 주기적 백업
  • PostgreSQL 사용자 DB 주기적 백업
  • EBS Snapshot을 이용한 서버 데이터 백업
  • SSH 접근 IP 제한
  • PostgreSQL 5432 외부 접근 차단
  • HTTPS 서비스를 위한 SSL 인증서 설치 및 갱신
  • 필요하면 ModSecurity 등 웹 방화벽 구성

특히 Database EC2의 장애나 EBS 손상에 대비하여 PostgreSQL 백업은 별도로 관리하는 것이 중요합니다.


7. 월 예상 비용


EC2가 1대에서 2대로 증가하기 때문에 이전 구성보다 비용도 증가합니다.

예를 들어 t3.micro EC2 2대와 각 10 GiB EBS를 사용하고 24시간 운영한다고 가정하면, 대략적으로 월 32,500원 요금이 발생하고, 다음 항목의 비용을 생각할 수 있습니다.

  • EC2 t3.micro × 2 = 25,000원
  • EBS 10 GiB × 2  = 2,500원
  • Public IPv4 × 1 =  5,000원

정확한 비용은 AWS 리전, EC2 가격 정책, Public IPv4 사용 개수, 트래픽, 환율, 부가세 등에 따라 달라질 수 있습니다.

Database EC2는 외부에서 접근할 경우, EC2 Web 서버를 통해서 접근하기 때문에 별도의 Public IPv4를 사용하지 않아도 되어서 IPv4 는 1개만 사용하면 됩니다.


8. EC2 2대 구성의 장점과 한계


이 구조의 가장 큰 장점은 애플리케이션과 데이터베이스를 분리했다는 것입니다.

서버별 역할이 명확해지고 각각 독립적으로 리소스를 사용할 수 있습니다. 애플리케이션 서버를 변경하거나 재배포할 때 DB 서버를 별도로 유지할 수 있다는 장점도 있습니다.

반면 관리해야 할 EC2가 늘어나고 비용도 증가합니다. 또한 Database EC2에 PostgreSQL을 직접 설치했기 때문에 DB 설치, 업데이트, 백업, 장애 복구를 직접 관리해야 합니다.

그리고 앞서 설명한 것처럼 서버를 서로 다른 AZ에 배치했다고 하더라도 Web/Application Server와 Database Server가 각각 한 대뿐이라면 완전한 고가용성 구조는 아닙니다.


9. 마무리 및 다음 단계


이번 구성에서는 EC2 2대를 이용하여 Web/Application Server와 Database Server를 분리하는 2-Tier 아키텍처를 살펴봤습니다.

EC2 한 대에 모든 서비스를 구성하는 방식보다 구조가 조금 복잡해지지만, 애플리케이션과 데이터베이스의 역할을 분리하면서 실제 서비스 운영에 조금 더 가까운 AWS 인프라 구조를 경험할 수 있습니다.

전체 구조는 다음과 같이 정리할 수 있습니다.
User
  ↓
Internet Gateway
  ↓
Web/Application EC2
  ↓
Database EC2


이 구성은 AWS 네트워크와 EC2 간 통신, Security Group, Private IP, 애플리케이션과 데이터베이스 분리 구조를 학습하면서 소규모 서비스를 운영해보기에 적합한 구성입니다.

하지만 데이터베이스를 EC2에서 직접 운영해야 하고 각각의 서버가 단일 장애 지점으로 남아 있다는 한계가 있습니다.

다음 단계에서는 Database EC2를 Amazon RDS로 변경하거나, Web/Application Server 앞에 Application Load Balancer(ALB)를 배치하고 EC2를 여러 대로 구성하는 방식으로 확장할 수 있습니다. 이렇게 하나씩 구성 요소를 분리해 나가면 AWS에서 사용하는 일반적인 운영 아키텍처로 발전시킬 수 있습니다.
#EC2#2-Tier#데이터베이스
내 서비스에 맞는 구성이 궁금하신가요?

요구사항을 선택하면 예상 아키텍처와 구축 견적을 확인할 수 있습니다.

내 조건으로 견적 작성하기

© 2026 Vuildy. All rights reserved.