Amazon RDS와 EC2에 직접 설치한 데이터베이스 차이 관리형 DB가 대신해 주는 일

AWS에서 데이터베이스를 준비할 때 가장 먼저 부딪히는 선택은 EC2 인스턴스에 MySQL이나 PostgreSQL을 직접 설치할지, Amazon RDS 같은 관리형 데이터베이스를 쓸지입니다. 요금표만 보면 같은 사양의 EC2가 더 저렴해 보여서 직접 설치를 택하는 경우가 많습니다. 하지만 데이터베이스는 설치보다 운영이 훨씬 긴 일이라, 누가 어떤 운영 작업을 맡는지까지 비교해야 정확한 판단이 됩니다.

 

관리형이라는 말은 AWS가 모든 것을 대신해 준다는 뜻이 아닙니다. 서버 준비, 운영체제와 엔진 패치, 백업, 장애 조치 같은 반복 작업은 AWS가 맡지만, 스키마 설계와 쿼리 성능, 접근 권한 관리는 여전히 사용자의 몫입니다.

 

이 글에서는 RDS가 대신해 주는 일과 사용자가 계속 책임지는 일, 자동 백업과 특정 시점 복구의 동작 방식, 다중 AZ와 읽기 전용 복제본의 차이, 그리고 비용을 비교할 때 놓치기 쉬운 항목을 차례로 정리합니다.

 

결론부터 말씀드리면 RDS는 설치, 패치, 백업, 장애 조치를 자동화하는 대신 운영체제 접근이 제한되고 인스턴스 시간당 요금이 같은 사양의 EC2보다 높게 책정됩니다. 운영 인력이 적고 표준 엔진을 쓰는 서비스라면 RDS가, 운영체제 수준의 설정이나 RDS가 지원하지 않는 엔진·확장이 꼭 필요하다면 EC2 직접 설치가 맞습니다.

 

 

관리형 데이터베이스가 대신해 주는 일

Amazon RDS는 Aurora(MySQL·PostgreSQL 호환), MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, Db2 엔진을 지원합니다. 콘솔에서 엔진과 인스턴스 클래스, 스토리지 크기를 고르면 몇 분 안에 접속 가능한 데이터베이스와 엔드포인트 주소가 만들어집니다.

 

만든 뒤의 운영 작업 상당수도 자동화됩니다. 지정한 유지 관리 시간대에 운영체제와 엔진 패치가 적용되고, 매일 자동 백업이 수행되며, 다중 AZ 구성에서는 장애가 생기면 대기 인스턴스로 자동 전환됩니다. 스토리지 자동 확장을 켜 두면 여유 공간이 부족할 때 스토리지가 늘어납니다.

 

운영 작업	EC2에 직접 설치	Amazon RDS
설치와 초기 설정	사용자	AWS(콘솔에서 선택)
운영체제·엔진 패치	사용자	AWS(유지 관리 시간대에 적용)
백업과 특정 시점 복구	스크립트 작성과 점검 필요	자동 백업, 보존 기간 설정만
장애 조치	복제와 전환 직접 구성	다중 AZ 선택 시 자동
읽기 확장	복제 서버 직접 구성	읽기 전용 복제본 생성
운영체제 접근	가능	불가(일부 RDS Custom 제외)
스키마·쿼리·인덱스	사용자	사용자

 

RDS는 설치, 패치, 백업, 장애 조치 같은 반복 운영을 맡아 주지만, 운영체제 접근은 막혀 있고 데이터베이스 내부 설계는 여전히 사용자 책임입니다.

 

RDS를 써도 사용자가 계속 책임지는 부분

클라우드의 공동 책임 모델은 RDS에도 그대로 적용됩니다. AWS는 하드웨어, 운영체제, 데이터베이스 소프트웨어의 설치와 패치를 책임지고, 사용자는 그 위에서 데이터와 접근을 책임집니다.

 

구체적으로는 테이블 구조와 인덱스 설계, 느린 쿼리 개선, 파라미터 그룹 설정, 데이터베이스 사용자와 비밀번호 관리가 사용자 몫입니다. 네트워크 노출도 마찬가지입니다. 퍼블릭 액세스를 켜고 보안 그룹에서 모든 IP를 허용하면 관리형이라도 인터넷에서 접속 시도가 들어옵니다. 데이터베이스는 프라이빗 서브넷에 두고 애플리케이션 서버의 보안 그룹에서 오는 연결만 허용하는 것이 기본입니다.

 

암호화도 선택 사항입니다. 저장 데이터 암호화는 데이터베이스를 만들 때 켜 두는 것이 가장 간단하고, 접속 구간은 SSL/TLS 연결을 사용하도록 애플리케이션 설정을 맞춰야 합니다.

 

관리형이라도 스키마, 쿼리, 계정, 네트워크 노출, 암호화 설정은 사용자가 직접 결정하고 점검해야 합니다.

 

자동 백업과 특정 시점 복구

RDS의 자동 백업은 매일 백업 시간대에 스토리지 스냅샷을 만들고, 그 사이의 트랜잭션 로그를 5분마다 S3에 올려 둡니다. 이 두 가지를 조합하기 때문에 보존 기간 안의 원하는 시각으로 복구할 수 있고, 가장 최근 복구 가능 시각은 대개 현재로부터 몇 분 전입니다.

 

보존 기간은 0일에서 35일 사이로 정합니다. 콘솔에서 만들면 기본 7일, AWS CLI나 API로 만들면서 값을 지정하지 않으면 기본 1일이 적용됩니다. 0일로 설정하면 자동 백업이 꺼지므로 운영 데이터베이스에서는 쓰지 않는 것이 좋습니다.

 

복구가 어떻게 이루어지는지도 알아두어야 합니다. 예를 들어 보존 기간이 7일이고 화요일 오후 2시 30분에 실수로 테이블을 지웠다면, 2시 29분 시점으로 복구할 수 있습니다. 이때 기존 인스턴스가 되돌아가는 것이 아니라 새 인스턴스가 만들어지고 엔드포인트 주소도 새로 생기므로, 애플리케이션의 접속 주소를 바꾸거나 필요한 데이터만 옮겨 오는 작업이 뒤따릅니다.

 

수동 스냅샷은 자동 백업과 별개로 관리됩니다. 인스턴스를 삭제해도 수동 스냅샷은 남아 있으며, 리전당 최대 100개까지 보관할 수 있습니다. 큰 변경 작업 전에는 수동 스냅샷을 하나 만들어 두는 습관이 안전합니다.

 

자동 백업은 0~35일 보존과 5분 단위 로그 업로드로 특정 시점 복구를 지원하며, 복구 결과는 새 인스턴스와 새 엔드포인트로 만들어집니다.

 

다중 AZ와 읽기 전용 복제본은 목적이 다릅니다

두 기능 모두 데이터베이스 사본을 하나 더 만든다는 점은 같지만, 해결하려는 문제가 다릅니다. 다중 AZ는 가용성, 읽기 전용 복제본은 읽기 성능 확장이 목적입니다.

 

 

구분	다중 AZ 배포(대기 인스턴스 1개)	읽기 전용 복제본
목적	장애 시 자동 전환	읽기 부하 분산
복제 방식	동기식	비동기식
대기본으로 읽기	불가	가능(별도 엔드포인트)
전환	자동, 보통 60~120초	필요 시 수동 승격
접속 주소	같은 엔드포인트가 새 기본 인스턴스를 가리킴	복제본마다 다른 엔드포인트

 

다중 AZ에서는 기본 인스턴스의 변경이 다른 가용 영역의 대기 인스턴스에 동기식으로 복제됩니다. 기본 인스턴스에 문제가 생기면 RDS가 DNS 기록을 대기 인스턴스로 바꾸므로, 애플리케이션은 같은 엔드포인트로 다시 연결하면 됩니다. 전환에는 보통 60~120초가 걸리며, 큰 트랜잭션이 진행 중이었다면 더 길어질 수 있습니다. 동기식 복제 때문에 단일 AZ보다 쓰기 지연이 약간 늘어날 수 있다는 점도 알아두세요.

 

읽기 전용 복제본은 비동기로 따라오기 때문에 기본 인스턴스보다 약간 늦은 데이터를 보여 줄 수 있습니다. 조회가 많은 서비스에서 보고서나 목록 조회를 복제본으로 돌리면 기본 인스턴스의 부담이 줄어듭니다.

 

다중 AZ는 장애 대비용이라 대기본으로 읽을 수 없고, 읽기 확장이 필요하면 읽기 전용 복제본을 따로 만들어야 합니다.

 

비용을 비교할 때 놓치기 쉬운 항목

RDS 비용은 인스턴스 사용 시간, 할당한 스토리지와 프로비저닝된 IOPS, 백업 스토리지, 데이터 전송으로 구성됩니다. 다중 AZ를 켜면 대기 인스턴스 몫이 추가되므로 단일 AZ보다 비용이 올라갑니다.

 

개발용 데이터베이스는 중지 기능으로 비용을 줄일 수 있습니다. 중지한 동안에는 인스턴스 시간 요금이 나가지 않지만, 스토리지와 백업 스토리지, 퍼블릭 액세스를 켠 경우의 퍼블릭 IPv4 주소 요금은 계속 발생합니다. 또 중지 상태는 최대 7일까지만 유지되고, 7일이 지나면 유지 관리 업데이트를 위해 자동으로 다시 시작됩니다. 이 점을 모르고 중지해 두었다가 요금이 다시 나오는 경우가 많습니다.

 

EC2 직접 설치는 요금표 숫자만 보면 저렴하지만, 백업 스크립트 작성과 점검, 복제 구성, 장애 시 수동 전환, 패치 작업에 드는 사람의 시간이 빠져 있습니다. 데이터베이스 전담 인력이 없다면 이 시간이 가장 큰 비용이 되는 경우가 많습니다.

 

RDS는 중지해도 스토리지 요금이 나오고 7일 뒤 자동 시작되며, EC2 직접 설치는 요금표에 보이지 않는 운영 시간을 함께 계산해야 공정한 비교가 됩니다.

 

관리형 데이터베이스 선택 핵심 정리

RDS는 설치, 패치, 자동 백업, 다중 AZ 장애 조치를 대신 맡아 주는 대신 운영체제 접근이 제한되고 인스턴스 요금이 높은 편입니다. 자동 백업은 0~35일 보존과 5분 단위 로그로 특정 시점 복구를 지원하지만 복구는 새 인스턴스로 이루어집니다. 다중 AZ는 60~120초 안팎의 자동 전환을 위한 기능이고, 읽기 확장은 읽기 전용 복제본의 역할입니다. 스키마, 쿼리, 계정, 네트워크 노출은 어느 쪽을 택하든 사용자가 책임집니다.

 

질문 QnA

RDS에 SSH로 접속할 수 있나요?

일반 RDS 인스턴스는 운영체제 접속을 제공하지 않습니다. 운영체제 수준의 접근이 꼭 필요한 Oracle이나 SQL Server 환경이라면 RDS Custom을 검토하거나 EC2 직접 설치를 선택해야 합니다.

다중 AZ를 켜면 백업은 필요 없나요?

필요합니다. 다중 AZ는 인프라 장애에 대비하는 기능이라, 실수로 지운 데이터도 대기 인스턴스에 그대로 복제됩니다. 잘못된 작업을 되돌리려면 자동 백업과 스냅샷이 있어야 합니다.

애플리케이션에서 IP 주소로 접속해도 되나요?

권장하지 않습니다. 장애 조치나 복구 과정에서 IP는 바뀔 수 있으므로 항상 엔드포인트 주소로 접속해야 합니다. 일부 Java 환경은 DNS 결과를 오래 기억하므로 캐시 시간을 60초 이하로 설정하는 것이 권장됩니다.

개발용 DB 비용을 가장 쉽게 줄이는 방법은?

작은 인스턴스 클래스를 쓰고, 쓰지 않는 기간에는 중지하는 것입니다. 오래 쓰지 않을 예정이라면 스냅샷을 남기고 삭제한 뒤 필요할 때 복원하는 방법도 있습니다.

 

데이터베이스는 서비스에서 가장 되돌리기 어려운 부분이라, 비용보다 복구 가능성을 먼저 따져 보는 것이 좋습니다. 백업 보존 기간과 복구 절차가 준비되어 있다면 어느 방식을 택하든 큰 사고를 막을 수 있습니다.

 

지금 운영 중인 데이터베이스가 있다면 자동 백업 보존 기간이 몇 일로 되어 있는지, 퍼블릭 액세스가 꺼져 있는지 두 가지를 먼저 확인해 보세요. 한 번도 복구를 해 본 적이 없다면 개발 환경에서 특정 시점 복구를 실제로 실행해 걸리는 시간을 재 보시길 권해드립니다.

함께 읽으면 좋은 글: RTO·RPO와 멀티 AZ 구성 / EBS 스냅샷과 AWS Backup 차이

참고 자료: Amazon RDS 사용 설명서, RDS 백업 보존 기간, RDS 다중 AZ 배포, RDS 인스턴스 일시 중지

※ 본 글은 2026년 9월 기준 Amazon RDS 사용 설명서를 참고해 작성했으며, 지원 엔진과 기본값, 전환 시간, 요금 기준은 변경될 수 있으니 최신 내용은 AWS 공식 문서에서 확인해 주세요.