RDS란 — EC2에 DB를 직접 설치하는 것과의 차이
Amazon RDS(Relational Database Service)는 MySQL, PostgreSQL 등 관계형 데이터베이스를 AWS가 관리형 서비스로 제공하는 방식입니다. DB 엔진을 직접 EC2에 설치할 수도 있지만, 그러면 OS·DB 패치, 백업, 장애 복구, 스토리지 관리, 모니터링을 직접 책임져야 합니다.
| 운영 항목 | EC2 직접 설치 | RDS |
|---|---|---|
| 서버 OS 관리 | 사용자 | AWS 관리 영역 |
| DB 엔진 패치 | 직접 계획·실행 | 유지관리 설정을 통해 관리 |
| 자동 백업 | 직접 구성 | 보존 기간 설정 가능 |
| 고가용성 | 복제·Failover 직접 설계 | Multi-AZ 옵션 제공 |
| 모니터링 | 직접 설치·연동 | CloudWatch 등과 기본 연동 |
| 서버 OS 접근 | 가능 | 일반 RDS에서는 직접 접근 불가 |
스키마, 인덱스, SQL 성능, 트랜잭션, 커넥션 풀, 권한 설계는 여전히 애플리케이션과 운영팀의 책임입니다.
네트워크 — DB를 인터넷에 직접 노출하지 않기
일반적인 3-Tier 구조에서 RDS는 프라이빗 서브넷에 배치하고 Public Access를 끕니다. 애플리케이션 서버의 Security Group만 DB 포트에 접근하도록 제한합니다.
ALB에서 필요한 애플리케이션 포트만 허용합니다.
MySQL 3306, PostgreSQL 5432 등을 전체 인터넷이 아니라 앱 서버 SG에서만 허용합니다.
Multi-AZ vs Read Replica — 목적이 다르다
둘 다 DB가 여러 개처럼 보이기 때문에 자주 혼동하지만 목적이 완전히 다릅니다. Multi-AZ는 가용성, Read Replica는 읽기 확장이 핵심입니다.
| 목적 | 선택 | 예시 |
|---|---|---|
| DB 장애에도 서비스 지속 | Multi-AZ | 운영 주문·예약 DB |
| 조회 트래픽 증가 대응 | Read Replica | 리포트·검색·조회 API |
| 둘 다 필요 | 조합 검토 | 가용성과 읽기 확장이 모두 중요한 서비스 |
자동 백업 · 스냅샷 · Point-in-Time Restore
일반 RDS DB 인스턴스의 자동 백업 보존 기간은 0~35일로 설정할 수 있습니다. 0일이면 자동 백업이 비활성화됩니다. 콘솔에서 새 DB를 만들 때 기본값은 현재 7일이므로 생성 화면에서 요구사항과 비용을 함께 확인해야 합니다.
보존 기간 동안 Point-in-Time Restore에 사용됩니다. 운영 DB는 복구 목표(RPO/RTO)에 맞춰 보존기간을 결정합니다.
사용자가 삭제하기 전까지 남을 수 있습니다. DB 인스턴스를 삭제했다고 스냅샷까지 자동으로 모두 사라진다고 생각하면 안 됩니다.
스냅샷이 있어도 실제 복원 절차, 복원 시간, 애플리케이션 재연결 방법을 확인하지 않았다면 장애 시 활용하기 어렵습니다.
비용 — Stop은 삭제가 아니다
일반 RDS DB 인스턴스는 개발·테스트 목적으로 일시 중지할 수 있지만 최대 7일 연속 중지 후 자동으로 다시 시작됩니다. 또한 중지 상태에서도 프로비저닝된 스토리지와 백업 저장소 등은 계속 과금될 수 있습니다.
| 과금 축 | 무엇을 확인하나 |
|---|---|
| DB 컴퓨팅 | 인스턴스 클래스 또는 Serverless 용량 |
| 스토리지 | 용량, 유형, IOPS/처리량 옵션 |
| 백업·스냅샷 | 보존 기간과 수동 스냅샷 잔존 여부 |
| 데이터 전송 | 리전·AZ·서비스 간 전송 경로 |
| 부가 기능 | Performance Insights, Proxy, KMS 등 사용 조건 |
RDS 가격은 리전, 엔진, 클래스, 배포 옵션에 따라 달라집니다. 학습 사이트에서는 구조를 이해하고, 실제 생성 직전에 현재 가격과 선택 옵션을 확인하는 습관을 들이는 것이 더 중요합니다.
Aurora와 Aurora Serverless v2
Amazon Aurora는 MySQL/PostgreSQL 호환 엔진으로, 컴퓨팅 인스턴스와 분산 스토리지 계층을 분리한 구조를 사용합니다. Writer와 Reader를 나누어 읽기 확장과 Failover를 구성할 수 있습니다.
최근 지원 엔진 버전의 Aurora Serverless v2는 최소 용량을 0 ACU로 설정하면 일정 시간 사용자 연결이 없을 때 자동 Pause가 가능합니다. 최소 유휴 시간은 5분이며 최대 1일까지 설정할 수 있습니다. 단, 엔진 버전과 클러스터 설정에 따라 0 ACU 지원 여부가 다르고, 스토리지 등 인스턴스 용량 외 비용은 계속 발생할 수 있습니다.
Auto-pause가 가능한 엔진 버전인지, 열린 사용자 연결이나 복제 설정이 Pause를 막지 않는지, 스토리지·I/O 등 별도 비용이 무엇인지 확인해야 합니다.
RDS Proxy — 연결 폭주를 완충하는 계층
RDS Proxy는 애플리케이션의 Client Connection을 받아 DB Connection Pool을 관리·공유합니다. Lambda처럼 연결 수가 급격히 늘거나, Auto Scaling으로 애플리케이션 인스턴스 수가 변하는 환경에서 DB 연결 폭주를 줄이는 데 도움이 됩니다.
AWS 문서도 애플리케이션 측 Connection Pooling이 애플리케이션↔Proxy 연결 재수립을 줄이는 장점이 있다고 설명합니다. HikariCP 크기, DB
max_connections, Proxy 설정을 함께 설계합니다.Parameter Group · 자격증명 · 애플리케이션 연결
DB 엔진 설정값을 관리합니다. 일부 파라미터는 즉시 적용되고 일부는 재부팅이 필요하므로 적용 방식까지 확인합니다.
DB 비밀번호를 소스코드나 Git에 하드코딩하지 않고 비밀정보 저장소에서 관리하는 패턴을 검토합니다.
연결 장애가 나면 순서대로 확인
| 순서 | 확인 항목 | 대표 증상 |
|---|---|---|
| 1 | RDS 상태와 Endpoint/Port | 호스트·포트 오입력 |
| 2 | VPC/Subnet/Route | 네트워크 경로 없음 |
| 3 | Security Group | Connection timeout |
| 4 | DB 사용자·비밀번호·권한 | Access denied |
| 5 | Connection Pool 설정 | Pool exhausted / too many connections |
| 6 | DB CPU·Memory·Connections | 성능 저하·연결 실패 |