Amazon RDS FAQ

DB 인스턴스는 고객이 지정한 컴퓨팅 및 스토리지 리소스를 제공하는 클라우드의 데이터베이스 환경이라고 생각할 수 있습니다. AWS Management Console, Amazon RDS API 및 AWS 명령줄 인터페이스를 통해 DB 인스턴스를 생성 및 삭제하고, DB 인스턴스의 인프라 속성을 정의/미세 조정하며, 액세스 및 보안을 제어할 수 있습니다. 하나 이상의 DB 인스턴스를 실행할 수 있으며 각 DB 인스턴스는 엔진 유형에 따라 하나 이상의 데이터베이스 또는 데이터베이스 스키마를 지원할 수 있습니다.

DB 인스턴스는 AWS Management Console, Amazon RDS API 또는 AWS Command Line Interface를 사용하여 간단하게 생성할 수 있습니다. AWS Management Console을 사용하여 DB 인스턴스를 시작하려면 ‘RDS’를 클릭한 다음 Instances(인스턴스) 탭에서 ‘Launch DB Instance(DB 인스턴스 시작)’ 버튼을 클릭하세요. 여기에서 DB 엔진 및 버전, 라이선스 모델, 인스턴스 유형, 스토리지 유형 및 용량, 기본 사용자 보안 인증 정보를 비롯하여 DB 인스턴스에 대한 파라미터를 지정할 수 있습니다.

또한, DB 인스턴스의 백업 보존 정책, 기본 백업 기간, 예약된 유지 관리 기간을 변경할 수 있습니다. 또는 CreateDBInstance API 또는 create-db-instance 명령을 사용하여 DB 인스턴스를 생성할 수 있습니다.

DB 인스턴스를 사용할 수 있게 되면, AWS Management Console, DescribeDBInstances API 또는 describe-db-instances 명령에서 DB 인스턴스 설명을 사용하여 엔드포인트를 검색할 수 있습니다. 이 엔드포인트에서 익숙한 데이터베이스 도구 또는 프로그래밍 언어를 사용해 DB 인스턴스에 직접 연결하는 데 필요한 연결 문자열을 구성할 수 있습니다. 실행 중인 DB 인스턴스에 대한 네트워크 요청을 허용하려면 액세스 권한을 부여해야 합니다. 연결 문자열을 구성하고 시작하는 방법에 대한 상세한 설명은 시작안내서를 참조하세요.

기본적으로 고객은 최대 총 40개의 Amazon RDS DB 인스턴스를 보유할 수 있습니다. 이러한 인스턴스 40개 중 최대 10개는 ‘라이선스 포함’ 모델에 따른 RDS for Oracle 또는 RDS for SQL Server DB 인스턴스가 될 수 있습니다. BYOL(개인 소유 라이선스 이용 허용) 모델에 따라 40개 모두 Amazon Aurora, RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for Oracle에 사용할 수 있습니다. RDS for SQL Server에서는 단일 DB 인스턴스에 최대 100개의 데이터베이스만 구성할 수 있습니다. 자세한 내용은 Amazon RDS for SQL Server 사용 설명서를 참조하세요.

• Amazon Aurora용 RDS: 소프트웨어에서 지정한 제한 없음
• MySQL용 RDS: 소프트웨어에서 지정한 제한 없음
• MariaDB용 RDS: 소프트웨어에서 지정한 제한 없음
• RDS for Oracle: 인스턴스당 데이터베이스 1개, 데이터베이스당 스키마 수에는 소프트웨어에서 지정한 제한 없음
• RDS for SQL Server: 인스턴스당 데이터베이스 최대 100개
• PostgreSQL용 RDS: 소프트웨어에서 지정한 제한 없음
• RDS for Db2: 인스턴스당 최대 1개의 데이터베이스

다음은 Amazon RDS로 데이터를 가져오는 다양한 방법입니다.

• MySQL: mysqldump 또는 mysqlimport 유틸리티
• Oracle: Data Pump, 가져오기/내보내기 또는 SQL Loader
• SQL Server: 가져오기/내보내기 마법사, 전체 백업 파일(.bak) 또는 대량 복사 프로그램(BCP)
• PostgreSQL: pg_dump

데이터 가져오기 및 내보내기에 대한 자세한 내용은 MySQL 데이터 가져오기 설명서, Oracle 데이터 가져오기 설명서, SQL Server 데이터 가져오기 설명서, PostgreSQL 데이터 가져오기 설명서 또는 Db2 데이터 가져오기 설명서를 참조하세요.

또한 AWS Database Migration Service를 사용하면 데이터베이스를 AWS로 안전하게 마이그레이션할 수 있습니다.

Amazon RDS 유지 관리 기간을 사용하여 요청이나 필요에 따라 DB 인스턴스 수정, 데이터베이스 엔진 버전 업그레이드 및 소프트웨어 패치를 적용하는 시기를 조정할 수 있습니다. 유지 관리 이벤트가 특정 주에 예정된 경우 사용자가 지정한 유지 관리 기간에 시작됩니다.

Amazon RDS가 DB 인스턴스를 오프라인으로 전환해야 하는 유지 관리 이벤트는 컴퓨팅 조정 작업(일반적으로 시작에서 완료까지 몇 분이면 됨), 데이터베이스 엔진 업그레이드 및 필수 소프트웨어 패치 작업입니다. 필수 소프트웨어 패치 작업은 보안 및 내구성과 관련된 패치에 대해서만 자동으로 예약됩니다. 이러한 패치 적용은 자주 발생하는 것은 아닙니다(일반적으로 몇 달에 한 번). 또한 유지 관리 시간에서 차지하는 비중도 크지 않습니다.

DB 인스턴스를 생성할 때 기본 주별 유지 관리 기간을 지정하지 않으면 30분이 기본값으로 지정됩니다. 자동으로 유지 관리를 수행하는 시기를 수정하려면 AWS Management Console, ModifyDBInstance API 또는 modify-db-instance 명령을 사용하여 DB 인스턴스를 수정하면 됩니다. 원하는 경우 DB 인스턴스마다 기본 유지 관리 기간을 다르게 설정할 수 있습니다.

DB 인스턴스를 다중 AZ 배포로 실행하면 유지 관리 이벤트의 영향을 더 줄일 수 있습니다. 유지 관리 작업에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

프로덕션 데이터베이스의 경우 50개가 넘는 CPU, 메모리, 파일 시스템 및 디스크 I/O 지표에 대한 액세스를 제공하는 향상된 모니터링을 사용하는 것이 좋습니다. 이러한 기능을 인스턴스별로 활성화할 수 있고 세부 수준을 선택할 수 있습니다(최소 1초까지). CPU 사용률이 높으면 쿼리 성능이 저하될 수 있으며 이 경우 DB 인스턴스 클래스를 조정하는 것이 좋습니다. DB 인스턴스 모니터링에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

RDS for MySQL 또는 MariaDB를 사용하는 경우, 데이터베이스의 느린 쿼리 로그에 액세스하여 실행 속도가 느린 SQL 쿼리가 있는지 확인하고, 있는 경우 각 쿼리의 성능 특성을 확인할 수 있습니다. 'slow_query_log' DB 파라미터를 설정하고 mysql.slow_log 테이블을 쿼리하여 실행 속도가 느린 SQL 쿼리를 확인할 수 있습니다. 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

RDS for Oracle을 사용하는 경우, Oracle 추적 파일 데이터를 사용하여 실행 속도가 느린 쿼리를 확인할 수 있습니다. 추적 파일 데이터에 액세스하는 방법에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요. 

RDS for SQL Server를 사용하는 경우, 클라이언트 측 SQL Server 추적 기능을 사용하여 실행 속도가 느린 쿼리를 확인할 수 있습니다. 서버 측 추적 파일 데이터에 액세스하는 방법에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

지원되는 데이터베이스 엔진 버전 목록은 각 엔진의 설명서를 참조하십시오.

• Amazon Aurora
• Amazon RDS for PostgreSQL
• Amazon RDS for MySQL
• Amazon RDS for MariaDB
• Amazon RDS for SQL Server
• Amazon RDS for Oracle
• Amazon RDS for Db2

버전 번호 지정에 대한 자세한 내용은 Amazon RDS 데이터베이스 엔진별 FAQ 페이지를 참조하세요.

• Amazon RDS for MySQL
• Amazon RDS for MariaDB
• Amazon RDS for PostgreSQL
• Amazon RDS for Oracle
• Amazon RDS for SQL Server
• Amazon Aurora
• Amazon RDS for Db2

시간이 지나면 Amazon RDS에서는 새로운 메이저 및 마이너 데이터베이스 엔진 버전에 대한 지원을 추가합니다. 몇 개의 새 버전을 지원할지는 엔진 공급업체 또는 개발 조직의 릴리스 및 패치 빈도와 내용, 그리고 AWS 데이터베이스 엔지니어링 팀의 철저한 릴리스 및 패치 검사 결과에 따라 달라질 수 있습니다. 그러나 일반 지침으로 상용 버전 출시 후 5개월 이내에 새로운 엔진 버전을 지원하는 것을 목표로 하고 있습니다.

AWS Management Console에서 DB 인스턴스 시작 작업 또는 CreateDBInstance API를 통해 새로운 DB 인스턴스를 생성할 때 현재 지원되는 버전(메이저 및 마이너) 중 원하는 버전을 지정하면 됩니다. AWS 리전별로 지원되지 않는 데이터베이스 엔진 버전이 있을 수 있습니다.

Amazon RDS는 지원되는 데이터베이스 엔진의 신규 버전을 제공하여 사용자의 데이터베이스 인스턴스를 최신 상태로 유지하기 위해 최선을 다합니다. 공급업체 또는 개발 조직에서 데이터베이스 엔진의 신규 버전을 출시하면 Amazon RDS에서 이를 제공하기 전에 AWS 데이터베이스 엔지니어링 팀에서 철저한 테스트를 수행합니다.

최신 버전에는 최신 보안 및 기능 수정 사항이 포함되므로 데이터베이스 인스턴스를 최신 마이너 버전으로 업그레이드하는 것이 좋습니다. 메이저 버전 업그레이드와는 달리 마이너 버전 업그레이드에는 데이터베이스 엔진의 동일한 메이저 버전의 이전 마이너 버전과 호환되는 데이터베이스 변경 사항만 포함되어 있습니다. 

새 마이너 버전에 Amazon RDS 고객에게 도움이 될 만한 수정 사항이 없는 경우, AWS에서는 이를 Amazon RDS에서 제공하지 않기로 결정할 수도 있습니다. 새로운 마이너 버전을 Amazon RDS에서 사용할 수 있게 되자마자, AWS에서는 이를 새로운 DB 인스턴스의 기본 마이너 버전으로 설정합니다. 

데이터베이스 인스턴스를 지원되는 엔진 버전으로 수동으로 업그레이드하려면 AWS Management Console에서 Modify DB Instance(DB 인스턴스 수정) 명령 또는 ModifyDBInstance API를 사용하여 DB Engine Version(DB 엔진 버전) 파라미터를 원하는 버전으로 설정합니다. 기본적으로 업그레이드는 다음 유지 관리 기간에 적용됩니다. 콘솔 API에서 Apply Immediately(즉시 적용) 옵션을 선택하여 즉시 업그레이드할 수도 있습니다.

이전에 릴리스된 마이너 버전과 비교하여 새로운 엔진 마이너 버전에 상당한 오류 수정 사항이 포함되어 있다고 판단한 경우, AWS에서는 Auto Minor Version Upgrade가 ‘Yes(예)’로 설정되어 있는 DB 인스턴스에 대한 자동 업그레이드 일정을 예약합니다. 이러한 업그레이드는 고객이 지정한 유지 관리 기간에 수행되도록 예약됩니다.

다중 AZ 인스턴스라 하더라도 DB 엔진 버전을 업그레이드하려면 가동 중지가 필요하므로, 미리 계획을 세울 수 있도록 이렇게 일정을 잡는 것입니다. 자동 마이너 버전 업그레이드 기능을 비활성화하려면 Auto Minor Version Upgrade를 ‘No(아니요)’로 설정하면 됩니다.

RDS for Oracle 및 RDS for SQL Server의 경우, 다음 마이너 버전으로 업그레이드하기 위해서는 다른 에디션으로 변경해야 한다면 사용자가 Auto Minor Version Upgrade 설정을 활성화했더라도 AWS에서 자동 업그레이드 일정을 예약하지 않을 수 있습니다. 이럴 때 자동 업그레이드 일정을 예약할지는 사례별로 결정합니다.

메이저 버전 업그레이드에는 호환성 위험이 따르므로, 자동으로 수행되지 않으며 반드시 사용자가 시작해야 합니다(메이저 버전 사용 중단은 예외, 아래 참조). DB 인스턴스를 새로운 DB 엔진 버전으로 업그레이드하는 데 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

예. 기존의 DB 인스턴스의 DB 스냅샷을 생성하고, DB 스냅샷에서 복원하여 새 DB 인스턴스를 만든 다음, 새로운 DB 인스턴스에 대한 버전 업그레이드를 시작할 수 있습니다. 그런 다음 업그레이드된 DB 인스턴스 복제본에서 안전하게 테스트한 후 원래의 DB 인스턴스를 업그레이드할지를 결정할 수 있습니다.

DB 스냅샷 복원에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

• AWS에서는 메이저 버전 릴리스(예: MySQL 5.6, PostgreSQL 9.6)는 Amazon RDS에서 처음으로 지원된 후 최소 3년 동안 지원하고,
• 마이너 버전(예: MySQL 5.6.37, PostgreSQL 9.6.1)은 Amazon RDS에서 처음으로 지원한 후 최소 1년 동안 지원하려고 합니다.

AWS에서는 정기적으로 메이저 또는 마이너 엔진 버전을 폐지합니다. 메이저 버전은 해당 커뮤니티 버전에 대한 커뮤니티 수명이 종료되거나 버전이 더 이상 소프트웨어 수정 또는 보안 업데이트를 받지 못할 때까지 사용할 수 있습니다. 마이너 버전의 경우, 마이너 버전에 상당한 버그 또는 보안 문제가 있고 이러한 문제가 이후 마이너 버전에서 해결되었을 때 이를 폐지합니다.

이 지침을 준수하도록 노력하고는 있지만 보안 문제가 우려되는 등의 경우에는 특정 주 버전이나 부 버전을 계획보다 일찍 폐기할 수도 있습니다. 예기치 않게 이러한 경우가 발생하는 경우 Amazon RDS는 이러한 문제를 해결하기 위해 데이터베이스 엔진을 자동으로 업그레이드합니다. 해결해야 할 문제에 따라 상황별로 업그레이드 시기가 달라질 수 있습니다.

Amazon RDS에서 데이터베이스 엔진의 마이너 버전이 중요도가 떨어져 폐지되는 경우, AWS에서는 자동 업그레이드를 시작하기 전에 폐지 공지 후 3개월의 기간을 제공합니다. 이 기간이 끝나면 여전히 폐지되는 마이너 버전을 실행하고 있는 모든 인스턴스를 대상으로 자동 업그레이드 일정이 예약되고, 예약된 유지 관리 기간 동안 지원되는 최신 마이너 버전으로 업그레이드됩니다.

Amazon RDS에서 데이터베이스 엔진의 메이저 버전이 폐지되는 경우, AWS에서는 고객이 지원되는 메이저 버전으로 업그레이드할 수 있도록 폐지 공지 후 최소한 6개월의 기간을 제공합니다. 이 기간이 끝나면 여전히 폐지된 버전을 실행하고 있는 모든 인스턴스를 대상으로 예약된 유지 관리 기간 동안 다음 메이저 버전으로 자동 업그레이드가 진행됩니다.

일부 경우에는 사전 공지 없이 특정 메이저 또는 마이너 버전을 폐지할 수 있습니다(예: 버전이 고품질, 성능 또는 보안 기준을 충족하지 않음을 발견한 경우). 이러한 경우 Amazon RDS에서는 이러한 버전의 새 데이터베이스 인스턴스 및 클러스터 생성을 중단합니다. 기존 고객은 계속해서 데이터베이스를 실행할 수 있습니다. 해결해야 할 문제에 따라 상황별로 업그레이드 시기가 달라질 수 있습니다.

최소 비용이나 설정 비용이 없으며, 사용한 만큼만 지불하면 됩니다. 다음을 기준으로 요금이 청구됩니다.

• DB 인스턴스 시간 – 사용한 DB 인스턴스의 클래스(예: db.t2.micro, db.m4.large) 기준. 부분적으로 사용된 DB 인스턴스의 경우 DB 인스턴스 클래스 생성, 시작 또는 수정 같은 청구 가능한 상태 변경에 따라 1초 단위로 청구되며 최소 10분의 요금이 부과됩니다. 자세한 내용은 새로운 소식 발표를 참조하세요.
• 스토리지(월별 GB당) – DB 인스턴스에 프로비저닝한 스토리지 용량. 월 중간에 프로비저닝된 스토리지 용량을 조정하는 경우, 비례 할당으로 계산된 요금이 적용됩니다.
• 월별 I/O 요청 – 사용자가 요청한 총 스토리지 I/O 요청 수(Amazon RDS 마그네틱 스토리지와 Amazon Aurora에만 해당)
• 월별 프로비저닝된 IOPS - 프로비저닝된 IOPS 속도이며 사용된 IOPS와 무관합니다[Amazon RDS의 프로비저닝된 IOPS(SSD) 스토리지에만 해당].
• 백업 스토리지 – 백업 스토리지는 자동화된 데이터베이스 백업 및 사용자가 생성한 데이터베이스 스냅샷과 연결되어 있습니다. 백업 보존 기간을 연장하거나 추가 데이터베이스 스냅샷을 생성하면 데이터베이스가 사용하는 백업 스토리지가 증가합니다.
• 데이터 전송 – DB 인스턴스에서 인터넷을 통한 데이터 송수신.

Amazon RDS의 요금 정보는 Amazon RDS 제품 페이지의 요금 섹션을 참조하세요.

DB 인스턴스를 사용할 수 있게 되면 즉시 DB 인스턴스에 대한 청구가 시작됩니다. 청구는 인스턴스가 삭제되거나 인스턴스 장애가 발생하여 DB 인스턴스가 종료될 때까지 계속됩니다.

DB 인스턴스 시간은 DB 인스턴스가 가용 상태로 실행되고 있는 각 시간에 대해 비용이 청구됩니다. DB 인스턴스에 대한 요금이 더 이상 청구되지 않도록 하려면 추가 인스턴스 시간당 비용이 청구되지 않도록 DB 인스턴스를 중지하거나 삭제해야 합니다. 부분적으로 사용된 DB 인스턴스의 경우 DB 인스턴스 클래스 생성, 시작 또는 수정 같은 청구 가능한 상태 변경에 따라 1초 단위로 청구되며 최소 10분의 요금이 부과됩니다.

데이터베이스 인스턴스를 중지하면 DB 인스턴스 시간이 아니라 프로비저닝된 스토리지(프로비저닝된 IOPS 포함) 및 백업 스토리지(지정된 보존 기간 내의 수동 스냅샷 및 자동화된 백업 포함)에 대해 비용이 청구됩니다.

계정에서 전체 리전에 프로비저닝한 데이터베이스 스토리지의 총량에 대해서는 백업 스토리지가 무료로 제공됩니다. 예를 들어 동일 리전과 동일 계정에서 MySQL DB 인스턴스에 월 100GB의 스토리지를 프로비저닝했고 PostgreSQL DB 인스턴스에 월 150GB의 스토리지를 프로비저닝한 경우 추가 요금 없이 250GB의 백업 스토리지가 이 계정과 리전에 제공됩니다. 이 양을 초과하는 백업 스토리지에 대한 요금만 부과됩니다.

계정에서 리전에 프로비저닝한 데이터베이스 스토리지의 총량을 해당 리전의 총 백업 스토리지와 매일 비교하여 초과 백업 스토리지에 대한 요금만 부과합니다. 예를 들어 매일 정확히 10GB의 백업 스토리지가 초과된 경우 해당 월에 10GB-월의 백업 스토리지 요금이 부과됩니다. 또는 매일 300GB의 스토리지를 프로비저닝하고 15일 동안만 매일 500GB의 백업 스토리지를 프로비저닝한 경우 100GB-월의 백업 스토리지 요금만 부과됩니다(200GB-월 요금이 부과되지 않음). 요금이 일 단위(비례 배분)로 계산되고 한 달 내내 백업을 사용한 것이 아니기 때문입니다. 무료 백업 스토리지는 계정 및 리전별로 적용된다는 점을 참고하시기 바랍니다.

백업의 크기는 인스턴스에 있는 데이터의 양과 직접적으로 비례합니다. 예를 들어 DB 인스턴스에 100GB의 스토리지를 프로비저닝하고 5GB의 데이터만 저장한 경우 첫 번째 백업은 100GB가 아니라 약 5GB가 됩니다. 후속 백업은 증분 백업이며 DB 인스턴스의 변경된 데이터만 저장됩니다. 참고로 백업 스토리지 크기는 RDS 콘솔이나 DescribeDBSnapshots API 응답에 표시되지 않습니다.

기본 데이터 용도로 DB 인스턴스에 프로비저닝된 스토리지는 단일 가용 영역 내에 있습니다. 데이터베이스를 백업하면 백업 데이터(트랜잭션 로그 포함)는 여러 가용 영역에 지리적으로 이중화되어 복제됩니다. 따라서 데이터 내구성 수준이 훨씬 강화됩니다. 무료 할당량을 초과하는 백업 스토리지 가격에는 중요한 백업의 내구성을 극대화하기 위한 이 추가 복제 비용이 반영되어 있습니다.

DB 인스턴스를 다중 AZ 배포로 지정하면 Amazon RDS 요금 페이지에 게시된 다중 AZ 요금에 따라 비용이 청구됩니다. 다중 AZ 비용은 다음에 따라 청구됩니다.

• 다중 AZ DB 인스턴스 시간 - 사용한 DB 인스턴스의 클래스(예: db.t2.micro, db.m4.large) 기준 단일 가용 영역에서 표준 배포와 마찬가지로, 부분적으로 사용된 DB 인스턴스 시간의 경우 DB 인스턴스 클래스 생성, 시작 또는 수정 같은 청구 가능한 상태 변경에 따라 1초 단위로 청구되며 최소 10분의 요금이 부과됩니다. 한 시간 이내에 DB 인스턴스 배포를 표준과 다중 AZ 배포 간에 전환하는 경우 해당 시간에 대해 표준 배포 요금과 다중 AZ 배포 요금이 모두 청구됩니다.
• 다중 AZ DB 인스턴스용으로 프로비저닝된 스토리지 – 한 시간 이내에 DB 인스턴스 배포를 표준과 다중 AZ 배포 간에 전환하는 경우 해당 시간에 대해 표준 배포 스토리지 요금과 다중 AZ 배포 스토리지 요금 중 높은 금액이 청구됩니다.
• 월별 I/O 요청 – 사용자가 요청한 총 스토리지 I/O 요청 수. 다중 AZ 배포는 데이터베이스 읽기/쓰기 비율에 따라 표준 DB 인스턴스 배포보다 많은 수의 I/O 요청을 사용합니다. 데이터베이스 업데이트에 따른 쓰기 I/O 사용량은 Amazon RDS가 데이터를 예비 DB 인스턴스에 동기 복제하는 경우 2배가 됩니다. 읽기 I/O 사용량은 변하지 않습니다.
• 백업 스토리지 – 백업 스토리지 사용량은 DB 인스턴스가 표준이든 다중 AZ 배포든 변하지 않습니다. 기본 DB 인스턴스에서 I/O가 일시적으로 중단되지 않도록 예비 복제본에서 백업이 수행됩니다.
• 데이터 전송 – 기본 복제본과 예비 복제본 간에 데이터를 복제할 때 발생하는 데이터 전송에 대해서는 요금이 부과되지 않습니다. DB 인스턴스에서 송수신되는 인터넷 데이터 전송 요금은 표준 배포와 같은 요금이 청구됩니다.

달리 명시하지 않는 한 가격에는 VAT 및 해당 판매세를 포함한 관련 조세 공과가 포함되지 않습니다. 청구지 주소가 일본으로 되어 있는 고객의 경우 AWS 서비스 사용 시 일본 소비세의 적용을 받게 됩니다. 자세히 알아보기.

Amazon RDS용 AWS 프리 티어는 MySQL, MariaDB, PostgreSQL, SQL Server Express Edition을 실행하는 단일 AZ Micro DB 인스턴스를 무료로 사용할 수 있는 혜택을 제공합니다. 프리 티어는 월별 최대 750 인스턴스 시간까지 사용할 수 있습니다. 또한, 고객은 매달 20GB의 범용(SSD) 데이터베이스 스토리지와 20GB의 백업 스토리지를 무료로 제공받습니다.

AWS 계정을 새로 생성하면 12개월 동안 AWS 프리 티어 액세스 권한을 가지게 됩니다. 자세한 내용은 AWS 프리 티어 FAQ를 참조하세요.

예. AWS 고객은 동시에 두 개 이상의 단일 AZ 마이크로 DB 인스턴스를 실행할 수 있으며 그 사용량은 Amazon RDS용 AWS 프리 티어 사용량 계산에 포함됩니다. 하지만 모든 Amazon RDS 단일 AZ 마이크로 DB 인스턴스 및 모든 해당되는 데이터베이스 엔진과 리전의 사용량을 합쳐 750 인스턴스 시간을 초과하는 경우, 초과 사용량에 대해서는 표준 Amazon RDS 요금이 부과됩니다.

예를 들어 한 달 동안 두 개의 단일 AZ 마이크로 DB 인스턴스를 각각 400시간 실행한 경우 총 누적 사용량은 800 인스턴스 시간이며, 이 중 750시간은 무료로 제공됩니다. 나머지 50시간에 대해서는 표준 Amazon RDS 요금이 청구됩니다.

아니요. AWS 프리 티어 액세스 권한이 있는 고객은 MySQL, PostgreSQL 또는 SQL Server Express 버전을 구동하는 마이크로 인스턴스 모두를 합쳐 최대 750 인스턴스 시간을 사용할 수 있습니다. 모든 Amazon RDS 단일 AZ Micro DB 인스턴스 및 모든 해당되는 데이터베이스 엔진과 리전의 사용량을 합쳐 750 인스턴스 시간을 초과하는 경우, 초과 사용량에 대해서는 표준 Amazon RDS 요금이 부과됩니다.

프리 티어에서 제공하는 인스턴스 시간을 초과하는 경우 표준 Amazon RDS 요금이 청구됩니다. 자세한 내용은 Amazon RDS 요금 페이지를 참조하세요.

Amazon RDS 예약형 인스턴스는 1년 또는 3년의 약정 기간에 DB 인스턴스를 예약할 수 있는 옵션을 제공하므로 온디맨드 인스턴스 요금보다 DB 인스턴스의 시간당 요금을 대폭 할인받을 수 있습니다. RI 결제 옵션에는 선결제 없음, 부분 선결제, 전체 선결제 등 3가지가 있으며 선결제 금액으로 실질 시간당 요금을 지불할 수 있습니다.

예약형 인스턴스와 온디맨드 DB 인스턴스는 기능 면에서 전혀 차이가 없습니다. 유일한 차이점은 DB 인스턴스가 청구되는 방식입니다. 예약형 인스턴스에서는 1년 또는 3년 예약을 구매하고 해당 기간에 온디맨드 DB 인스턴스와 비교하여 더 낮은 실질 시간당 사용 요금을 지불하게 됩니다. 리전 내 예약 인스턴스를 구매하지 않는 한, 모든 DB 인스턴스는 온디맨드 시간당 요금으로 청구됩니다.

Amazon RDS용 AWS Management Console의 ‘Reserved Instance(예약형 인스턴스)’ 섹션에서 예약형 인스턴스를 구매할 수 있습니다. 또는 Amazon RDS API 또는 AWS Command Line Interface를 사용하여 구매할 수 있는 예약형 인스턴스를 나열한 후, 원하는 DB 인스턴스 예약을 구매할 수도 있습니다.

일단 예약 구매를 완료한 후에는 사용 면에서 예약 DB 인스턴스와 온디맨드 DB 인스턴스는 차이가 없습니다. 예약했던 것과 같은 인스턴스 클래스, 엔진 및 리전을 사용하여 DB 인스턴스를 시작합니다. 예약 구매가 활성화되어 있는 한, Amazon RDS는 해당하는 할인된 시간당 요금을 새 DB 인스턴스에 적용합니다.

Amazon RDS 예약 인스턴스는 특정 가용 영역이 아니라 리전에 대해 구매하게 됩니다. RI가 한 가용 영역에 종속되지 않으므로 용량 예약은 아닙니다. 즉, 특정 가용 영역에 용량이 제한된 경우에도 해당 리전에서 예약 인스턴스를 구매할 수 있으며 할인은 해당 리전 내에서 사용량에 일치하는 모든 가용 영역에 적용됩니다.

예약 DB 인스턴스는 최대 40개까지 구매할 수 있습니다. 41개 이상의 DB 인스턴스를 실행하려면 Amazon RDS DB 인스턴스 요청 양식을 작성하세요.

동일 리전 내에서 현재 실행 중이며 예약하려는 DB 인스턴스와 동일한 DB 인스턴스 클래스, DB 엔진, 다중 AZ 옵션 및 라이선스 모델의 DB 인스턴스 예약을 구매하면 됩니다. 예약 인스턴스를 구매하면 Amazon RDS가 기존 DB 인스턴스에 새로운 시간당 사용 요금을 자동으로 적용합니다.

지불 인증을 처리하는 동안 귀하의 요청을 받을 경우 예약형 인스턴스와 관련된 요금 변경 내용이 적용됩니다. AWS Account Activity 페이지, DescribeReservedDBInstances API 또는 describe-reserved-db-instances 명령을 사용하여 예약 상태를 확인할 수 있습니다. 다음 청구 기간에 일회성 결제가 승인되지 않는 경우는 할인 요금이 적용되지 않습니다.

예약 기간이 지나면 예약 인스턴스는 DB 인스턴스 클래스와 리전에 해당하는 온디맨드 시간당 사용 요금으로 전환됩니다.

Amazon RDS의 DB 인스턴스 생성, 수정 및 삭제 작업은 온디맨드 인스턴스와 예약 인스턴스에 차이가 없습니다. 요금을 계산할 때 시스템이 사용자의 예약 상태를 자동으로 적용하고 해당하는 모든 DB 인스턴스에 저렴한 시간당 예약 DB 인스턴스 요금을 청구합니다.

각 예약은 DB 엔진, DB 인스턴스 클래스, 다중 AZ 배포 옵션, 라이선스 모델 및 리전과 같은 속성과 관련이 있습니다.

크기 유연성의 대상이 되는 DB 엔진 및 라이선스 모델(MySQL, MariaDB, PostgreSQL, Amazon Aurora 또는 Oracle ‘기존 보유 라이선스 사용’)에 대한 예약은 같은 데이터베이스 엔진 및 리전의 인스턴스 패밀리(M4, T2, R3 등) 내에서 실행 중인 모든 크기의 DB 인스턴스에 자동으로 적용됩니다. 또한, 예약은 단일 AZ 또는 다중 AZ 베포 옵션으로 실행되는 DB 인스턴스에도 적용됩니다.

예를 들어 db.m4.2xlarge MySQL 예약을 구매했다고 가정해 보겠습니다. 실행 중인 DB 인스턴스를 db.m4.4xlarge로 확장하기로 하면, 이 RI의 할인율이 더 큰 DB 인스턴스 사용량의 1/2에 적용됩니다.

크기 유연성의 대상이 아닌 DB 엔진이나 라이선스 모델(Microsoft SQL Server 또는 Oracle '라이선스 포함')을 실행 중인 경우에는 각 예약이 약정 기간 동안 같은 속성을 가진 DB 인스턴스에만 적용될 수 있습니다. 예약 기간이 끝나기 전에 실행 중인 DB 인스턴스의 이러한 속성을 수정하면, 해당 DB 인스턴스의 시간당 사용 요금이 온디맨드 시간당 사용 요금으로 전환됩니다.

크기 유연성에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

각 예약 인스턴스는 특정 리전과 연결되어 있으며 이는 예약의 수명 기간 동안 고정되어 변경할 수 없습니다. 그러나 각 예약은 연결된 리전 내의 모든 가용 영역에서 사용할 수 있습니다.

예. 예약 인스턴스를 구매할 때 DB 인스턴스 구성에서 다중 AZ 옵션을 선택하여 구매할 수 있습니다. 그뿐 아니라 예약형 인스턴스 크기의 유연성을 지원하는 DB 엔진 및 라이선스 모델을 사용하는 경우 다중 AZ 예약형 인스턴스는 두 개의 단일 AZ DB 인스턴스를 사용할 수 있습니다.

DB 인스턴스 예약은 DB 인스턴스 클래스와 리전이 동일한 경우에 한해 읽기 전용 복제본에 사용할 수 있습니다. 요금을 계산할 때 시스템이 사용자의 예약 상태를 자동으로 적용하고 해당하는 모든 DB 인스턴스에 저렴한 시간당 예약 인스턴스 요금을 청구합니다.

아니요. 예약 DB 인스턴스는 취소할 수 없으며 일회성 요금(해당하는 경우)은 환불되지 않습니다. 예약 DB 인스턴스 기간에는 사용량과 관계없이 시간당 요금을 계속해서 지불하게 됩니다.

전체 선결제 옵션으로 RI를 구매하는 경우 RI의 전체 계약 기간에 대한 요금을 한 번에 선결제하게 됩니다. 선결제 없음 옵션을 선택하면 선결제 금액을 지불하지 않습니다. 이 경우 RI의 전체 요금은 계약 기간 내 각 시간으로 분배되며 사용량에 관계없이 기간 내 시간에 대해 요금이 청구됩니다. 부분 선결제 옵션은 전체 선결제와 선결제 없음 옵션에 대한 하이브리드 옵션입니다. 소정의 선결제 금액을 지불하고 사용량에 관계없이 기간 내 시간에 대해 저렴한 시간당 요금을 지불하는 옵션입니다.

초기 DB 인스턴스 클래스와 스토리지 용량을 선택하려면 애플리케이션의 컴퓨팅, 메모리 및 스토리지 요구 사항을 확인하세요. 사용 가능한 DB 인스턴스 클래스에 대한 정보는 Amazon RDS 사용 설명서를 참조하세요.

AWS Management Console(원하는 DB 인스턴스를 선택하고 Modify(수정) 버튼 클릭), Amazon RDS API 또는 AWS Command Line Interface를 통해 DB 인스턴스에 할당된 컴퓨팅 리소스와 스토리지 용량을 조정할 수 있습니다. 메모리와 CPU 리소스는 DB 인스턴스 클래스를 변경하여 수정하고, 사용 가능한 스토리지는 스토리지 할당을 수정하면 변경됩니다. 

DB 인스턴스 클래스 또는 할당된 스토리지를 수정하면 지정된 유지 관리 기간에 요청된 변경 내용이 적용된다는 점에 유의하십시오. 또는 “apply-immediately” 플래그를 사용하여 확장 요청을 즉시 적용할 수 있습니다. 다른 처리되지 않은 시스템 변경 내용도 적용됩니다.

일부 구형 SQL Server용 RDS 인스턴스는 확장된 스토리지에 적합하지 않을 수 있습니다. 자세한 내용은 RDS for SQL Server FAQ를 참조하세요.

Amazon RDS는 데이터베이스와 로그를 저장하는 데 EBS 볼륨을 사용합니다. Amazon RDS는 필요한 스토리지의 크기에 따라 자동으로 데이터를 여러 EBS 볼륨에 나누어 저장하여 IOPS 성능을 강화합니다. MySQL 및 Oracle의 기존 DB 인스턴스의 경우 스토리지를 스케일 업하면 I/O 용량이 일부 개선될 수 있습니다. AWS Management Console, ModifyDBInstance API 또는 modify-db-instance 명령을 사용하여 DB 인스턴스에 할당된 스토리지 용량을 조정할 수 있습니다.

자세한 내용은 Amazon RDS용 스토리지를 참조하세요.

DB 인스턴스 가용성을 유지하면서 DB 인스턴스에 할당된 스토리지 용량을 늘릴 수 있습니다. 그러나 DB 인스턴스에서 사용하는 컴퓨팅 리소스를 스케일 업하거나 스케일 다운할 경우 DB 인스턴스 클래스를 수정하는 동안 데이터베이스를 일시적으로 사용할 수 없게 됩니다. 사용이 불가능한 시간은 일반적으로 몇 분 정도이며, 수정 사항을 즉시 적용하도록 지정하지 않은 이상, DB 인스턴스의 유지 관리 기간에 수정 사항이 적용됩니다.

Amazon RDS는 여러 애플리케이션 요구를 충족하기 위해 다양한 DB 인스턴스 클래스와 스토리지 할당을 지원합니다. 애플리케이션에 최대 DB 인스턴스 클래스보다 더 많은 컴퓨팅 리소스가 필요하거나 최대 할당보다 더 많은 스토리지가 필요할 경우, 파티셔닝을 구현하여 여러 DB 인스턴스에 데이터를 분산할 수 있습니다.

Amazon RDS의 범용(SSD) 스토리지는 I/O 요구 수준이 보통인 광범위한 데이터베이스 워크로드에 적합합니다. 기준 성능이 IOPS 3회/GB이고 순간 최고 성능이 IPOS 3,000회인 이 스토리지 옵션은 대다수 애플리케이션의 요구 사항을 충족하는 예측 가능한 성능을 제공합니다.

Amazon RDS의 프로비저닝된 IOPS(SSD) 스토리지는 빠르고 예측 가능하며 일관성 있는 I/O 성능을 제공하기 위해 설계된 SSD 지원 스토리지 옵션입니다. Amazon RDS의 프로비저닝된 IOPS(SSD) 스토리지의 경우, DB 인스턴스 생성 시 IOPS 속도를 지정하면 Amazon RDS에서는 DB 인스턴스의 수명 기간에 해당 IOPS 속도를 프로비저닝합니다. Amazon RDS의 프로비저닝된 IOPS(SSD) 스토리지는 I/O 집중형 트랜잭션(OLTP) 데이터베이스 워크로드를 위해 최적화되어 있습니다. 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

Amazon RDS 마그네틱 스토리지는 데이터에 대한 액세스 빈도가 낮은 소규모 데이터베이스 워크로드에 유용합니다. 마그네틱 스토리지는 프로덕션 데이터베이스 인스턴스용으로는 권장되지 않습니다.

워크로드에 가장 적합한 스토리지 유형을 선택합니다.

• 고성능 OLTP 워크로드: Amazon RDS의 프로비저닝된 IOPS(SSD) 스토리지
• I/O 요구 사항이 보통인 데이터베이스 워크로드: Amazon RDS의 범용(SSD) 스토리지

Amazon RDS가 지원하는 IOPS는 데이터베이스 엔진에 따라 다릅니다. 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

Amazon RDS는 DB 인스턴스 백업 및 복구를 위한 두 가지 방법, 즉 자동 백업 및 데이터베이스 스냅샷(DB 스냅샷)을 제공합니다.

Amazon RDS의 자동 백업 기능을 사용해 DB 인스턴스를 특정 시점으로 복구할 수 있습니다. DB 인스턴스의 자동 백업을 활성화하면 Amazon RDS가 매일 자동으로 데이터에 대한 전체 스냅샷을 만들고(기본 백업 기간 내에), 트랜잭션 로그를 캡처(DB 인스턴스를 업데이트할 때)합니다. 특정 시점으로 복구를 시작할 때, DB 인스턴스를 사용자가 요청한 특정 시점으로 복구하기 위해 가장 적합한 일일 백업에 트랜잭션 로그가 적용됩니다. 

Amazon RDS는 사용자가 지정한 일정 기간(보존 기간) 동안 DB 인스턴스의 백업을 보관합니다. 보존 기관은 기본적으로 1일이지만 최대 35일까지 설정할 수 있습니다. 특정 시점으로 복구를 시작할 수 있으며, 복구 가능한 최근 시간까지 보존 기간을 초 단위로 지정할 수 있습니다. DescribeDBInstances API를 사용하여 DB 인스턴스의 복구 가능한 최근 시간(일반적으로 최근 5분)으로 돌아갈 수 있습니다. 

또는 AWS Management Console에서 DB 인스턴스를 선택하고 콘솔의 아래쪽 창에 있는 ‘Description(설명)’ 탭에서 복구 가능한 최근 시간을 찾을 수 있습니다.

사용자가 시작하는 DB 스냅샷에서는 원하는 빈도로 DB 인스턴스를 일관되게 백업한 다음 언제든지 해당 상태로 복구할 수 있습니다. DB 스냅샷은 AWS Management Console, CreateDBSnapshot API 또는 create-db-snapshot 명령을 사용하여 생성할 수 있으며 사용자가 명시적으로 삭제할 때까지 유지됩니다.

사용자는 Amazon RDS가 자동 백업을 지원하기 위해 수행하는 스냅샷을 복사(AWS Console 또는 copy-db-snapshot 명령 사용)하거나 스냅샷 복구 기능을 사용할 수 있습니다. 스냅샷은 "automated" 스냅샷 유형을 사용하여 찾을 수 있습니다. 또 "Snapshot Created Time" 필드에서 스냅샷이 촬영된 시간을 확인할 수 있습니다. 

또는 "automated" 스냅샷 식별자에도 스냅샷이 만들어진 시간(단위: UTC)이 포함되어 있습니다.

참고: 특정 시점으로 복구 또는 DB 스냅샷에서 복구 작업을 수행하면 새로운 엔드포인트를 가지는 새 DB 인스턴스가 생성됩니다(필요한 경우 기존 DB 인스턴스를 삭제할 수 있음). 이 작업을 완료하면 특정 DB 스냅샷 또는 시점에서 여러 DB 인스턴스를 만들 수 있습니다.

기본적으로 Amazon RDS는 DB 인스턴스를 자동으로 백업합니다. 이때 보존 기간은 7일입니다. 백업 보존 기간을 수정하려면 RDS 콘솔이나 CreateDBInstance API(새 DB 인스턴스 생성 시) 또는 ModifyDBInstance API(기존 인스턴스의 경우)를 사용하면 됩니다. 이러한 메서드를 사용하여 RetentionPeriod 파라미터를 0(자동 백업 비활성화)부터 원하는 일수(최대 35일) 사이의 임의 숫자로 변경할 수 있습니다. DB 인스턴스가 읽기 전용 복제본에 대한 소스인 경우 값을 0으로 설정할 수 없습니다. 자동 백업에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

기본 백업 기간은 DB 인스턴스를 백업하기 위해 사용자가 지정하는 기간입니다. Amazon RDS는 이러한 정기 데이터 백업과 트랜잭션 로그를 함께 사용하여 최대 복구 가능한 최근 시간(일반적으로 최근 몇 분)까지 DB 인스턴스를 보존 기간 중 원하는 시점(단위: 초)으로 복구할 수 있도록 지원합니다. 백업 기간 중에 백업 프로세스가 시작될 때 스토리지 I/O가 일시적으로 중단(일반적으로 몇 초 미만)될 수 있으며, 일시적으로 지연 시간이 증가하는 것을 경험할 수도 있습니다. 다중 AZ DB 배포를 사용하면 백업이 예비 복제본에서 수행되므로, I/O가 중단되지 않습니다.

Amazon RDS DB 스냅샷과 자동 백업은 S3에 저장됩니다.

AWS Management Console, ModifyDBInstance API 또는 modify-db-instance 명령을 사용해 RetentionPeriod 파라미터를 수정하여 자동 백업이 보관되는 기간을 관리할 수 있습니다. 자동 백업을 완전히 비활성화하려는 경우 보존 기간을 0으로 설정하면 됩니다(권장하지 않음). Amazon RDS 콘솔의 ‘Snapshots(스냅샷)’ 섹션을 사용하여 사용자가 만든 DB 스냅샷을 관리할 수 있습니다. DescribeDBSnapshots API 또는 describe-db-snapshots 명령을 사용하여 특정 DB 인스턴스에 대해 사용자가 작성한 DB 스냅샷 목록을 확인하고, DeleteDBSnapshot API 또는 delete-db-snapshot 명령을 사용해 스냅샷을 삭제할 수 있습니다.

보존 기간의 날짜 수보다 자동 DB 스냅샷 수가 1 또는 2개 더 많은 것이 정상입니다. 보존 기간 중 원하는 시점으로 특정 시점 복원을 수행할 수 있도록 보장하기 위해 자동 스냅샷 하나가 추가로 유지됩니다.

예를 들어 백업 기간이 1일로 설정된 경우, 이전 24시간 내 원하는 시점으로 복원할 수 있으려면 2개의 자동 스냅샷이 필요합니다. 또한, 언제나 가장 오래된 자동 스냅샷이 삭제되기 전에 새로운 자동 스냅샷이 생성되므로 자동 스냅샷이 하나 더 보일 수도 있습니다.

DB 인스턴스를 삭제할 때 삭제 시에 최종 DB 스냅샷을 생성할 수 있고 그렇게 하면 이 DB 스냅샷을 사용하여 나중에 삭제된 DB 인스턴스를 복구할 수 있습니다. Amazon RDS는 이 최종 사용자 생성 DB 스냅샷을 DB 인스턴스 삭제 후에 수동으로 생성한 모든 다른 DB 스냅샷과 함께 보관합니다. 백업 스토리지 비용에 대한 자세한 내용은 요금 페이지를 참조하세요.

DB 인스턴스를 삭제해도 백업 보존 기간까지 자동 백업을 유지할 수 있습니다. 자세한 내용은 자동 백업 유지를 참조하세요.

Amazon VPC를 사용하면 AWS 클라우드의 격리된 프라이빗 공간에 가상 네트워킹 환경을 생성하고 프라이빗 IP 주소 범위, 서브넷, 라우팅 테이블, 네트워크 게이트웨이 등 다양한 항목을 완벽하게 제어할 수 있습니다. Amazon VPC를 사용하여 가상 네트워크 토폴로지를 정의하고 자체 데이터 센터에서 운영하는 IP 네트워크와 흡사하게 네트워크 설정을 사용자 지정할 수 있습니다.

예를 들어, 프라이빗 서브넷에서 공개적으로 액세스할 수 없는 백엔드 서버를 유지 관리하면서 퍼블릭 측 웹 애플리케이션을 실행하고자 할 때 VPC를 활용할 수 있습니다. 인터넷에 액세스할 수 있는 웹 서버에 퍼블릭 서브넷을 만들고 인터넷에 액세스할 수 없는 프라이빗 서브넷에 백 엔드 Amazon RDS DB 인스턴스를 배포할 수 있습니다. Amazon VPC에 대한 자세한 내용은 Amazon Virtual Private Cloud 사용 설명서를 참조하세요.

AWS 계정이 2013년 12월 4일 이전에 생성되었다면 Amazon Elastic Compute Cloud(EC2)-Classic 환경에서 Amazon RDS를 실행할 수도 있습니다. Amazon RDS의 기본 기능은 EC2-Classic을 사용하든 EC2-VPC를 사용하든 관계없이 동일합니다. Amazon RDS는 DB 인스턴스를 VPC 내부 또는 외부 중 어디에 배포하든 관계없이 백업, 소프트웨어 패치 적용, 자동 장애 감지, 읽기 전용 복제본 및 복구를 관리합니다. EC2-Classic과 EC2-VPC의 차이점에 대한 자세한 내용은 EC2 설명서를 참조하세요.

DB 서브넷 그룹은 VPC 내의 Amazon RDS DB 인스턴스에 대해 지정할 수 있는 서브넷의 모음입니다. 각 DB 서브넷 그룹에는 특정 리전의 가용 영역마다 하나 이상의 서브넷이 있어야 합니다. VPC에 DB 인스턴스를 만들 때, DB 서브넷 그룹을 선택해야 합니다. 그러면 Amazon RDS가 DB 서브넷 그룹과 기본 가용 영역을 사용하여 서브넷과 서브넷의 IP 주소를 선택합니다. Amazon RDS가 엘라스틱 네트워크 인터페이스를 만든 다음 해당 IP 주소를 가진 DB 인스턴스에 연결합니다.

기본 IP 주소가 변경될 수 있으므로(예: 장애 조치 도중) 사용자의 DB 인스턴스에 연결할 때 DNS 이름을 사용하는 것이 좋습니다.

다중 AZ 배포의 경우, 특정 리전의 모든 가용 영역에 서브넷을 정의하면 Amazon RDS가 필요한 경우 다른 가용 영역에 새로운 예비 복제본을 만들 수 있습니다. 단일 AZ 배포의 경우도 어느 시점에 단일 AZ 배포를 다중 AZ 배포로 변환하려면 이 작업을 수행해야 합니다.

이 프로세스를 진행하는 절차는 Amazon RDS 사용 설명서의 VPC에서 DB 인스턴스 만들기를 참조하세요.

Amazon RDS 사용 설명서의 보안 그룹 섹션을 참조하여 DB 인스턴스에 대한 액세스를 제어하는 다양한 방법에 대해 알아보세요.

VPC 내에 배포된 DB 인스턴스는 동일한 VPC에 배포된 EC2 인스턴스에서 액세스할 수 있습니다. 이러한 EC2 인스턴스가 엘라스틱 IP가 연결된 공인 서브넷에 배포된 경우 인터넷을 통해 EC2 인스턴스에 액세스할 수 있습니다. VPC 내에 배포된 DB 인스턴스는 인터넷에서 액세스하거나 VPN 또는 퍼블릭 서브넷에서 실행할 수 있는 Bastion Host를 통해 VPC 외부의 EC2 인스턴스에서 액세스하거나 Amazon RDS의 공용 액세스 옵션을 사용하여 액세스할 수 있습니다.

• Bastion Host를 사용하려면 SSH Bastion 역할을 하는 EC2 인스턴스를 사용하여 퍼블릭 서브넷을 설정해야 합니다. 이 퍼블릭 서브넷은 SSH 호스트를 통해 트래픽을 제어할 수 있는 인터넷 게이트웨이 또는 라우팅 규칙이 필요합니다. 또한, SSH 호스트에서 Amazon RDS DB 인스턴스의 프라이빗 IP 주소로 요청을 전달할 수 있어야 합니다.
• 공용 연결을 사용하려면 Publicly Accessible 옵션을 yes로 설정하여 DB 인스턴스를 만듭니다. 공용 액세스가 활성화되면 기본적으로 VPC 내부의 DB 인스턴스를 VPC 외부에서 완벽하게 액세스할 수 있게 됩니다. 따라서 인스턴스에 대한 액세스를 허용하기 위해 VPN이나 배스천 호스트를 설정할 필요가 없습니다.

VPN 게이트웨이를 설정해 사내 네트워크를 VPC로 확장하여 해당 VPC의 Amazon RDS DB 인스턴스에 액세스할 수 있도록 하는 방법도 있습니다. 자세한 내용은 Amazon VPC 사용 설명서를 참조하세요.

기본 IP 주소가 변경될 수 있으므로(예: 장애 조치 도중) DB 인스턴스에 연결할 때 DNS 이름을 사용하는 것이 좋습니다.

DB 인스턴스가 VPC 내에 있지 않은 경우 AWS Management Console을 사용하여 손쉽게 DB 인스턴스를 VPC로 이동할 수 있습니다. 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요. 또한, VPC 외부에 있는 DB 인스턴스의 스냅샷을 생성한 다음, 사용할 DB 서브넷 그룹을 지정함으로써 이를 VPC 내에 복원할 수도 있습니다. 또는 “지정 시간으로 복원” 작업도 가능합니다.

DB 인스턴스를 VPC 내부에서 VPC 외부로 마이그레이션하는 기능은 지원되지 않습니다. 보안상의 이유로 VPC 내부에 있는 DB 인스턴스의 DB 스냅샷은 VPC 외부로 복원할 수 없습니다. 마찬가지로 “특정 시점으로 복원” 기능도 지원되지 않습니다. 

사용자는 VPC의 라우팅 테이블과 네트워킹 ACL을 수정하여 VPC의 클라이언트 인스턴스에서 DB 인스턴스에 도달할 수 있도록 해야 합니다. 다중 AZ 배포의 경우 장애 조치 후 클라이언트 EC2 인스턴스와 Amazon RDS DB 인스턴스가 서로 다른 가용 영역에 속할 수 있습니다. 따라서 AZ 사이의 통신이 가능하도록 네트워킹 ACL을 구성해야 합니다.

기존 DB 서브넷 그룹을 업데이트하여 기존 가용 영역 또는 DB 인스턴스를 만든 후 추가된 새로운 가용 영역에 서브넷을 추가할 수 있습니다. 기존 DB 서브넷 그룹에서 서브넷을 제거하면 이 서브넷 그룹에서 제거된 특정 AZ에서 실행 중이던 인스턴스를 사용하지 못할 수도 있습니다. 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

Amazon RDS를 사용하려면 AWS 개발자 계정이 필요합니다. Amazon RDS에 가입하기 전에 이 계정을 가지고 있지 않은 경우, 가입 프로세스를 시작할 때 계정을 만들라는 메시지가 표시됩니다. 기본 사용자 계정은 AWS 개발자 계정과 달라야 하고, Amazon RDS에서 DB 인스턴스에 대한 액세스를 제어하기 위한 용도로만 사용합니다. 기본 사용자 계정은 DB 인스턴스에 액세스하는 데 사용할 수 있는 네이티브 데이터베이스 사용자 계정입니다. 

DB 인스턴스를 만들 때 각 DB 인스턴스에 연결할 기본 사용자 이름과 암호를 지정할 수 있습니다. DB 인스턴스를 만들면 기본 사용자 자격 증명을 사용하여 데이터베이스에 연결할 수 있습니다. 나중에 추가 사용자 계정을 만들어 DB 인스턴스에 액세스할 수 있는 사용자를 제한할 수도 있습니다.

MySQL의 기본 사용자의 기본 권한은 create, drop, references, event, alter, delete, index, insert, select, update, create temporary tables, lock tables, trigger, create view, show view, alter routine, create routine, execute, trigger, create user, process, show databases, grant option입니다.

Oracle의 기본 사용자에게는 ‘dba’ 역할이 부여됩니다. 기본 사용자는 해당 역할과 관련된 권한을 대부분 상속합니다. 권한의 제한 목록과 이러한 권한이 필요한 관리 작업을 수행할 수 있는 방법은 Amazon RDS 사용 설명서를 참조하세요.

SQL Server에서는 데이터베이스를 만든 사용자에게 "db_owner" 역할이 부여됩니다. 권한의 제한 목록과 이러한 권한이 필요한 관리 작업을 수행할 수 있는 방법은 Amazon RDS 사용 설명서를 참조하세요.

아니요, 관계형 데이터베이스를 사용하여 사용자가 직접 관리하는 것과 동일한 익숙한 방법으로 모두 작동합니다.

예. 보안 그룹을 구성하여 인터넷을 통해 데이터베이스에 액세스할 수 있는 기능을 활성화해야 합니다. 자체 데이터 센터의 서버에 해당하는 특정 IP, IP 범위 또는 서브넷에 대한 액세스만 허용할 수 있습니다.

예. 이 옵션은 모든 Amazon RDS 엔진에서 지원됩니다. Amazon RDS는 각 DB 인스턴스에 대해 SSL/TLS 인증서를 생성합니다. 암호화된 연결이 설정되면 DB 인스턴스와 애플리케이션 간에 전송되는 데이터는 전송 중에 암호화됩니다.

SSL/TLS는 보안상 장점이 있지만, SSL 암호화는 컴퓨팅 중심 작업이며 데이터베이스 연결의 지연 시간을 늘린다는 점에 유의해야 합니다. Amazon RDS에서의 SSL/TLS 지원은 애플리케이션과 DB 인스턴스 간의 연결을 암호화하기 위한 것이므로 DB 인스턴스 자체를 인증하는 데 사용해서는 안 됩니다.

Amazon RDS를 통한 암호화된 연결 설정에 대한 자세한 내용은 Amazon RDS의 MySQL 사용 설명서, MariaDB 사용 설명서, PostgreSQL 사용 설명서 또는 Oracle 사용 설명서를 참조하세요. SSL/TLS와 이러한 엔진의 연동에 대해 자세히 알아보려면 MySQL 설명서, MariaDB 설명서, MSDN SQL Server 설명서, PostgreSQL 설명서 또는Oracle 설명서를 직접 참조하시기 바랍니다.

Amazon RDS는 AWS Key Management Service(KMS)를 통해 관리하는 키를 사용하여 모든 데이터베이스 엔진에 대한 저장 중 암호화를 지원합니다. Amazon RDS 암호화를 실행 중인 데이터베이스 인스턴스에서는 자동 백업, 읽기 전용 복제본 및 스냅샷과 마찬가지로 기본 스토리지에 저장된 데이터가 암호화됩니다. 암호화와 복호화는 투명하게 처리됩니다. Amazon RDS와 KMS 사용에 관한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

또한, DB 스냅샷을 생성한 후 해당 스냅샷의 사본을 만들어 KMS 암호화 키를 지정함으로써 이전에 암호화되지 않은 DB 인스턴스나 DB 클러스터도 암호화할 수 있습니다. 그런 다음 암호화된 스냅샷에서 암호화된 DB 인스턴스 또는 DB 클러스터를 복원할 수 있습니다.

Amazon RDS for Oracle 및 SQL Server는 이러한 엔진의 TDE(Transparent Data Encryption) 기술을 지원합니다. 자세한 내용은 Oracle 및 SQL Server 관련 Amazon RDS 사용 설명서를 참조하세요.

AWS IAM 사용자 및 그룹이 Amazon RDS 리소스에서 수행할 수 있는 작업을 제어할 수 있습니다. 사용자 및 그룹에 적용할 AWS IAM 정책에서 Amazon RDS 리소스를 참조하면 이 작업을 수행할 수 있습니다. AWS IAM 정책에서 참조할 수 있는 Amazon RDS 리소스에는 DB 인스턴스, DB 스냅샷, 읽기 전용 복제본, DB 보안 그룹, DB 옵션 그룹, DB 파라미터 그룹, 이벤트 구독 및 DB 서브넷 그룹이 포함됩니다. 

또한 이러한 리소스에 태그를 지정하여 메타데이터를 추가할 수 있습니다. 태그를 지정하여 리소스를 분류(예: ‘Development’ DB 인스턴스, ‘Production’ DB 인스턴스, ‘Test’ DB 인스턴스)하고 동일한 태그를 가진 리소스에서 수행할 수 있는 권한(즉, 작업)을 나열하는 AWS IAM 정책을 작성할 수 있습니다. 자세한 내용은 Amazon RDS 리소스 태깅을 참조하세요.

예. AWS CloudTrail은 계정에 대한 AWS API 호출을 기록하고 로그 파일을 사용자에게 전달하는 웹 서비스입니다. CloudTrail에서 작성되는 AWS API 호출 내역을 통해 보안 분석, 리소스 변경 사항 추적 및 규정 준수 감사를 수행할 수 있습니다. 

예. 모든 Amazon RDS 데이터베이스 엔진은 HIPAA 적격 서비스입니다. 따라서 AWS와 체결한 비즈니스 제휴 계약(BAA)에 따라 HIPAA 규정 준수 애플리케이션을 구축하고 개인 건강 정보(PHI)를 비롯한 의료 서비스 관련 정보를 저장하는 데 이를 사용할 수 있습니다.

이미 BAA를 체결한 경우, 다른 작업 없이 BAA에 포함된 계정에서 이러한 서비스 사용을 시작할 수 있습니다. AWS와 BAA를 아직 체결하지 않았거나, AWS의 HIPAA 규정 준수 애플리케이션에 대한 질문이 있는 경우 해당하는 고객 관리자에게 문의하십시오.

기본적으로 Amazon RDS는 인스턴스 클래스와 스토리지 용량을 고려하여 DB 인스턴스에 최적인 구성 파라미터를 선택합니다. 하지만 원하는 경우 AWS Management Console, Amazon RDS API 또는 AWS 명령줄 인터페이스를 사용하여 이를 변경할 수 있습니다. 다만 구성 파라미터를 권장값에서 변경하면 성능 저하에서 시스템 작동 중단에 이르기까지 예기치 않은 결과가 발생할 수 있으므로 이러한 위험을 충분히 인식하고 있는 고급 사용자만 이 작업을 시도하는 게 좋습니다.

데이터베이스 파라미터 그룹(DB 파라미터그룹)은 하나 이상의 DB 인스턴스에 적용 가능한 엔진 설정값의 “컨테이너” 역할을 합니다. DB 파라미터 그룹을 지정하지 않고 DB 인스턴스를 만드는 경우 기본 DB 파라미터 그룹이 사용됩니다. 이 기본값 그룹에는 실행하는 DB 인스턴스에 최적화된 엔진 기본값과 Amazon RDS 시스템 기본 값이 포함됩니다.

그러나 사용자 지정 엔진 설정값을 사용해 DB 인스턴스를 실행하려면 새 DB 파라미터 그룹을 만들고, 필요한 파라미터를 수정하고, 새 DB 파라미터 그룹을 사용하기 위해 DB 인스턴스를 수정하기만 하면 됩니다. 연결이 이루어지면 특정 DB 파라미터 그룹을 사용하는 모든 DB 인스턴스가 해당 DB 파라미터 그룹에 대한 모든 파라미터 업데이트를 가져옵니다.

DB 파라미터 그룹 설정에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

AWS Config를 사용하여 Amazon RDS DB 인스턴스, DB 서브넷 그룹, DB 스냅샷, DB 보안 그룹 및 이벤트 구독에 대한 구성 변경 사항을 지속적으로 기록하고 Amazon Simple Notification Service(SNS)를 통해 변경 사항에 대한 알림을 받을 수 있습니다. 또한 AWS Config 규칙을 생성하여 해당 Amazon RDS 리소스가 원하는 구성을 사용하고 있는지 평가할 수 있습니다.

다중 AZ 배포로 실행되도록 DB 인스턴스를 생성 또는 수정하면 Amazon RDS가 다른 가용 영역에 동기식 ‘예비’ 복제본을 자동으로 프로비저닝하고 유지합니다. DB 인스턴스에 대한 업데이트는 가용 영역 전체에서 예비 복제본에 동기식으로 복제됩니다. 이는 양쪽의 동기화를 유지하고 DB 인스턴스 장애로부터 최신 데이터베이스 업데이트를 보호하기 위해서입니다. 

특정 유형의 계획된 유지 관리를 수행하는 도중에, 또는 예기치 않은 DB 인스턴스 장애나 가용 영역 장애가 발생할 경우 Amazon RDS가 자동으로 예비 복제본으로 장애 조치하므로 예비 복제본이 승격되자마자 데이터베이스 쓰기 및 읽기를 재개할 수 있습니다. DB 인스턴스의 이름 레코드는 변경되지 않으므로 관리자가 직접 개입할 필요 없이 애플리케이션이 데이터베이스 작업을 재개할 수 있습니다. 다중 AZ 배포에서 복제본은 투명합니다. 사용자는 예비와 직접 상호 작용하지 않으며, 예비는 읽기 트래픽을 처리하는 데 사용될 수 없습니다. 다중 AZ 배포에 대한 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

가용 영역은 다른 가용 영역에서 발생한 장애를 격리시키기 위해 만들어진 리전 내의 개별 장소입니다. 각 가용 영역은 물리적으로 분리된 자체 독립 인프라에서 실행되며 높은 안정성을 제공하도록 설계되었습니다. 발전기 및 냉각 장비와 같은 일반적인 장애 지점은 가용 영역 전체에서 공유되지 않습니다. 또한 물리적으로 분리되어 있어 화재, 태풍 또는 홍수와 같이 예기치 않은 자연 재해가 발생할 경우 단일 가용 영역만 영향을 받게 됩니다. 같은 지역에 있는 가용 영역은 지연 시간이 짧은 네트워크 연결을 제공합니다.

DB 인스턴스를 다중 AZ 배포로 실행할 경우 ‘프라이머리’가 데이터베이스 쓰기 및 읽기를 처리합니다. 또한 Amazon RDS는 백그라운드에서 기본 복제본의 최신 복제본인 "예비 복제본"을 프로비저닝하고 관리합니다. 예비 복제본은 장애 조치 시, “승격”됩니다. 장애 조치 후 예비 복제본이 기본 복제본이 되어 데이터베이스 작업을 수락합니다. 승격되기 전에는 어떠한 경우에도 대기 인스턴스를 사용할 수 없습니다(예: 읽기 작업의 경우). 단일 DB 인스턴스의 용량 한도 이상으로 읽기 트래픽을 확장하려는 경우 읽기 전용 복제본 FAQ를 참조하세요.

DB 인스턴스를 다중 AZ 배포로 실행할 경우 얻을 수 있는 주요 이점은 데이터베이스 내구성과 가용성의 향상입니다. 다중 AZ 배포가 제공하는 향상된 가용성과 내결함성 덕분에 다중 AZ 배포는 프로덕션 환경에 최적입니다.
 

DB 인스턴스를 다중 AZ 배포로 실행하면 DB 인스턴스 구성요소 장애 또는 한 가용 영역의 가용성 손실 등 예기치 않은 이벤트 발생 시 데이터를 보호할 수 있습니다. 예를 들어, 기본 복제본의 스토리지 볼륨에 장애가 발생할 경우 Amazon RDS가 자동으로 예비 복제본에 장애 조치를 수행하고 데이터베이스 업데이트는 예비 복제본에서 모두 완전한 상태로 유지됩니다. 이것은 단일 AZ의 표준 배포와 관련하여 추가 데이터 내구성을 제공합니다. 단일 AZ의 표준 배포에서는 사용자가 복구 작업을 시작해야 하고 복구 가능한 최근 시간(일반적으로 최근 5분 내) 후 발생한 업데이트는 사용할 수 없습니다.

DB 인스턴스를 다중 AZ 배포로 실행할 경우 향상된 데이터베이스 가용성을 활용할 수 있습니다. 가용 영역 장애 또는 DB 인스턴스 장애가 발생하면 자동 장애 조치가 완료되는 동안에만 가용성이 영향을 받습니다. 계획된 유지 관리에서도 다중 AZ의 가용성 이점을 활용할 수 있습니다.

예를 들어, 자동 백업을 사용하면 백업이 예비 복제본에서 수행되므로 기본 백업 기간 동안 기본 복제본에서 I/O 작업이 더 이상 중단되지 않습니다. 패치 적용 또는 DB 인스턴스 클래스를 확장하는 경우 이러한 작업은 자동 장애 조치 전에 예비 복제본에 먼저 적용됩니다. 결과적으로 가용성에 미치는 영향은 자동 장애 조치를 완료하는 데 필요한 시간으로 제한됩니다.

DB 인스턴스를 다중 AZ 배포로 실행할 경우 얻을 수 있는 또 다른 이점은 DB 인스턴스 장애 조치가 자동으로 수행되므로 관리가 필요하지 않다는 것입니다. Amazon RDS의 맥락에서 이는 가용 영역 장애 또는 DB 인스턴스 장애가 발생할 경우 DB 인스턴스 이벤트를 모니터링하고 수동으로 DB 인스턴스 복구를 수행(RestoreDBInstanceToPointInTime 또는 RestoreDBInstanceFromSnapshot API를 사용하여)할 필요가 없음을 의미합니다.

고객을 대신해 수행하는 동기식 데이터 복제로 인해 단일 가용 영역에서 표준 DB 인스턴스 배포와 관련된 지연 시간이 증가할 수 있습니다.

아니요. 다중 AZ 예비 복제본은 읽기 요청을 처리할 수 업습니다. 다중 AZ 배포는 읽기 기능 확장의 이점보다는 향상된 데이터베이스 가용성과 내구성을 제공하도록 설계되었습니다. 따라서 이 기능은 기본 복제본과 예비 복제본 간의 동기 복제를 사용합니다. 당사의 구현 기술은 기본 및 예비가 항상 동기화되지만 읽기 또는 쓰기 작업에 예비를 사용할 수 없도록 합니다. 읽기 확장 솔루션에 관심이 있다면 읽기 전용 복제본의 FAQ를 참조하세요.

다중 AZ DB 인스턴스 배포를 만들려면 AWS Management Console에서 DB 인스턴스를 시작할 때 ‘다중 AZ 배포’에서 ‘예’ 옵션을 클릭하면 됩니다.

또는 Amazon RDS API를 사용하는 경우 CreateDBInstance API를 직접적으로 호출하여 ‘Multi-AZ’ 파라미터 값을 ‘true’로 설정합니다. 기존의 표준(단일 AZ) DB 인스턴스를 다중 AZ로 전환하려면 AWS Management Console에서 DB 인스턴스를 수정하거나 ModifyDBInstance API를 사용하여 Multi-AZ 파라미터를 true로 설정합니다.

RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for SQL Server, RDS for Oracle 및 RDS for Db2 데이터베이스 엔진의 경우 Amazon RDS 인스턴스를 단일 AZ에서 다중 AZ로 변환하도록 선택하면 다음과 같은 프로세스가 수행됩니다.

• 기본 인스턴스의 스냅샷이 생성됩니다.
• 다른 가용 영역에서 위의 스냅샷으로부터 새로운 대기 인스턴스가 생성됩니다.
• 기본 인스턴스와 대기 인스턴스 간에 동기식 복제가 구성됩니다.

이에 따라 인스턴스가 단일 AZ에서 다중 AZ로 전환될 때 가동 중지 시간이 발생하지 않습니다. 하지만 예비 인스턴스의 데이터가 기본 인스턴스의 데이터와 일치하도록 업데이트되는 동안 지연 시간이 증가할 수 있습니다.

Amazon RDS는 다중 AZ 배포에 대한 가장 빈번한 오류를 감지해 자동으로 복구하므로 관리자의 개입 없이 데이터베이스 작업을 최대한 빨리 재개할 수 있습니다. Amazon RDS는 다음과 같은 이벤트가 발생하는 경우 장애 조치를 자동으로 수행합니다.

• 기본 가용 영역의 가용성 손실
• 기본 복제본에 대한 네트워크 연결 상실
• 기본 복제본의 컴퓨팅 장치 장애
• 기본 복제본의 스토리지 장애

참고: 다중 AZ 배포에서 DB 인스턴스 조정 또는 OS 패치와 같은 시스템 업그레이드 작업을 하는 경우 가용성을 향상하기 위해 자동 장애 조치 전에 먼저 예비 복제본에 해당 작업이 적용됩니다. 따라서 자동 장애 조치를 완료하는 데 걸리는 시간 동안만 가용성에 영향을 주게 됩니다. Amazon RDS 다중 AZ 배포는 장시간 동작 쿼리, 교착 상태 또는 데이터베이스 손상 오류 같은 데이터베이스 동작에 대해서는 자동으로 장애 조치를 수행하지 않습니다.

예. Amazon RDS에서 자동 장애 조치가 발생했음을 알리는 DB 인스턴스 이벤트가 생성됩니다. Amazon RDS 콘솔의 "Events" 섹션을 클릭하거나 DescribeEvents API를 사용하여 DB 인스턴스와 관련된 이벤트 정보를 반환할 수 있습니다. 또한 Amazon RDS 이벤트 알림을 사용하면 특정 DB 이벤트가 발생할 때 알림을 받을 수 있습니다.

Amazon RDS를 통해 자동으로 장애 조치가 처리되므로 관리자 개입 없이 최대한 신속하게 데이터베이스 작업을 재개할 수 있습니다. 장애 조치 시, Amazon RDS는 DB 인스턴스의 정식 이름 레코드(CNAME)가 예비 복제본을 가리키도록 변경합니다. 그러면 이 예비 복제본이 승격되어 새 기본 복제본이 됩니다. 모범 사례에 따라 애플리케이션 계층에서 데이터베이스 연결을 다시 시도하는 것이 좋습니다.

기본 복제본에서 장애를 감지하고 예비 복제본에서 트랜잭션을 재개하는 데 걸리는 시간 간격으로 정의되는 장애 조치는 일반적으로 1~2분 내에 완료됩니다. 장애 조치 시간은 활발하게 사용되지 않는 대규모 트랜잭션의 복구 필요 여부에도 영향을 받습니다. 최상의 결과를 위해서는 다중 AZ와 함께 적당히 큰 인스턴스 유형을 사용하는 것이 좋습니다. 또한, 빠르고 예측 가능하며 일관된 처리량 성능을 위해 다중 AZ 인스턴스와 함께 프로비저닝된 IOPS를 사용하는 것이 좋습니다.

Amazon RDS는 다양한 장애 조건에 대해 사용자의 개입 없이 자동으로 장애 조치를 수행합니다. 또한 Amazon RDS는 인스턴스를 재시작할 때 장애 조치를 시작하는 옵션을 제공합니다. AWS Management Console을 사용하거나 RebootDBInstance API를 호출하여 이 기능에 액세스할 수 있습니다.

다중 AZ 배포를 사용할 경우, ‘Multi-AZ’ 파라미터를 true로 설정하면 됩니다. 예비 복제본, 동기 복제 및 장애 조치 생성은 모두 자동으로 처리됩니다. 즉, 예비 복제본이 배포되는 가용 영역을 선택하거나 사용 가능한 예비 복제본의 수를 변경할 수 없습니다(Amazon RDS는 기본 DB 인스턴스당 하나의 전용 예비 복제본을 프로비저닝함). 예비 복제본이 데이터베이스 읽기 작업을 허용하도록 설정할 수도 없습니다. 다중 AZ 구성에 대해 자세히 알아보십시오.

예. 예비 인스턴스는 기본 DB 인스턴스와 동일한 리전의 다른 가용 영역에 자동으로 프로비저닝됩니다.

예. AWS Management Console 또는 DescribeDBInstances API를 사용하여 현재 기본 인스턴스의 위치를 알 수 있습니다.

가용 영역은 같은 리전의 다른 가용 영역에 지연 시간이 짧은 네트워크 연결을 제공하도록 설계되었습니다. 또한 하나의 가용 영역에서 서비스 장애 발생 시, 애플리케이션이 회복력을 가질 수 있도록 여러 가용 영역 전체에 애플리케이션과 기타 AWS 리소스를 중복하여 저장할 수 있습니다. 다중 AZ 배포는 사용자의 관리 작업 없이 데이터베이스에서 이러한 요구를 해결합니다.

표준 배포를 단일 AZ 배포로 실행하든, 다중 AZ 배포로 실행하든 관계없이 동일한 방식으로 자동 백업과 DB 스냅샷 기능을 사용할 수 있습니다. 다중 AZ 배포를 실행할 경우 I/O가 기본 복제본에서 중단되지 않도록 자동 백업 및 DB 스냅샷이 예비 복제본에서 수행됩니다. 단일 또는 다중 AZ 배포의 백업 도중에 I/O 지연 시간(일반적으로 몇 분 덩인 지속)이 길어질 수 있습니다.

다중 AZ 배포를 사용할 경우 복원 작업(지정 시간 복구 또는 DB 스냅샷에서 복구) 실행도 표준 단일 AZ 배포와 동일하게 작동합니다. RestoreDBInstanceFromSnapshot 또는 RestoreDBInstanceToPointInTime API를 사용해 새로운 DB 인스턴스 배포를 만들 수 있습니다. 이 새 DB 인스턴스 배포는 표준 또는 다중 AZ가 될 수 있으며, 원본 백업이 표준 또는 다중 AZ 배포에서 실행되었는지는 관계없습니다.

읽기 전용 복제본은 지원되는 엔진에 내장된 복제 기능을 통해 단일 DB 인스턴스의 용량 제한을 탄력적으로 스케일 아웃하여 읽기 중심의 데이터베이스 워크로드를 손쉽게 처리하도록 지원합니다.

AWS Management Console을 몇 번 클릭하거나 CreateDBInstanceReadReplica API를 사용하여 읽기 전용 복제본을 생성할 수 있습니다. 읽기 전용 복제본이 생성되면 지원되는 엔진의 기본 비동기식 복제 기능을 사용하여 소스 DB 인스턴스에 대한 데이터베이스 업데이트가 복제됩니다. 해당 원본 DB 인스턴스에 대한 여러 읽기 전용 복제본을 만들어 애플리케이션의 읽기 트래픽을 분산할 수 있습니다.

읽기 전용 복제본은 지원되는 엔진에 내장된 복제 기능을 사용하므로 강점과 약점을 갖고 있습니다. 특히 소스 DB 인스턴스에 업데이트가 발생한 후 읽기 전용 복제본에 업데이트가 적용됩니다. 즉, 복제 지연 시간은 상당히 다를 수 있습니다. 읽기 전용 복제본을 다중 AZ 배포에 연결하여 다중 AZ 배포가 제공하는 향상된 데이터베이스 쓰기 가용성과 데이터 내구성 외에 읽기 크기 조정의 이점을 얻을 수 있습니다.

특정 소스 DB 인스턴스가 제대로 작동하기 위해 읽기 전용 복제본을 배포하는 위치는 다양합니다. 읽기 전용 복제본을 배포하는 일반적인 이유는 다음과 같습니다.

• 읽기 중심의 데이터베이스 워크로드를 위해 단일 DB 인스턴스의 컴퓨팅 파워 또는 I/O 용량을 확장합니다. 이 과도한 읽기 트래픽을 하나 이상의 읽기 전용 복제본으로 이동할 수 있습니다.
• 원본 DB 인스턴스를 사용할 수 없는 동안 읽기 트래픽을 처리합니다. 소스 DB 인스턴스가 I/O 요청을 처리하지 못할 경우(예: 백업 또는 예약된 유지 관리를 위한 I/O 중단) 읽기 트래픽을 읽기 전용 복제본으로 이동할 수 있습니다. 이 사용 사례의 경우 소스 DB 인스턴스를 사용할 수 없으므로 읽기 전용 복제본의 데이터가 ‘무효’일 수 있다는 점에 유의하세요.
• 비즈니스 보고 또는 데이터 웨어하우징 시나리오 기본 프로덕션 DB 인스턴스가 아니라 읽기 전용 복제본에 대해 비즈니스 보고 쿼리를 실행하려고 할 수 있습니다.
• 동일한 AWS 리전에 있거나 다른 리전에 있는 소스 DB 인스턴스의 재해 복구를 위해 읽기 전용 복제본을 사용할 수 있습니다.

예. 백업 보존 기간을 0이 아닌 값으로 설정하여 읽기 전용 복제본을 추가하기 전에 소스 DB 인스턴스에서 자동 백업을 활성화하세요. 읽기 전용 복제본이 작동하려면 백업이 활성화된 상태로 유지되어야 합니다.

Amazon Aurora: 모든 DB 클러스터

Amazon RDS for MySQL: 모든 DB 인스턴스가 읽기 전용 복제본의 생성을 지원합니다. 읽기 전용 복제본이 작동하려면 소스 DB 인스턴스에 자동 백업이 활성화된 상태로 유지되어야 합니다. 복제본에 대한 자동 백업은 MySQL 5.6 이상(5.5는 해당 안 됨)을 실행하는 Amazon RDS 읽기 전용 복제본에 대해서만 지원됩니다.

Amazon RDS for PostgreSQL: PostgreSQL 버전이 9.3.5 이상인 DB 인스턴스만 읽기 전용 복제본 생성을 지원합니다. Amazon RDS 읽기 전용 복제본을 활용하려면 9.3.5 이전 버전의 기존 PostgreSQL 인스턴스를 PostgreSQL 9.3.5 버전으로 업그레이드해야 합니다.

Amazon RDS for MariaDB: 모든 DB 인스턴스가 읽기 전용 복제본 생성을 지원합니다. 읽기 전용 복제본이 작동하려면 소스 DB 인스턴스에 자동 백업이 활성화된 상태로 유지되어야 합니다.

Amazon RDS for Oracle: Oracle Database Enterprise Edition에서 BYOL(기존 보유 라이선스 사용) 모델을 사용하고 Active Data Guard 옵션에 대한 라이선스를 보유한 Oracle 버전 12.1.0.2.v12 이상 및 모든 12.2 버전에 지원됩니다.

Amazon RDS for SQL Server: 기본 복제 기술이 SQL Server 버전 2016 및 2017용 Always On 가용성 그룹을 사용하는 경우 다중 AZ 구성의 엔터프라이즈 에디션에서 읽기 전용 복제본이 지원됩니다.

표준 CreateDBInstanceReadReplica API를 사용하거나 AWS Management Console에서 몇 단계를 수행하여 몇 분 만에 읽기 전용 복제본을 만들 수 있습니다. 읽기 전용 복제본을 만들 때 SourceDBInstanceIdentifier를 지정하여 읽기 전용 복제본을 확인할 수 있습니다. SourceDBInstanceIdentifier는 복제할 “소스” DB 인스턴스의 DB 인스턴스 식별자입니다. 표준 DB 인스턴스와 마찬가지로 가용 영역, DB 인스턴스 클래스 및 기본 유지 관리 기간을 지정할 수 있습니다. 엔진 버전(예: PostgreSQL 9.3.5)과 읽기 전용 복제본의 스토리지 할당은 소스 DB 인스턴스에서 상속됩니다. 

읽기 전용 복제본 생성을 시작하면 Amazon RDS가 소스 DB 인스턴스의 스냅샷을 만들고 복제를 시작합니다. 그 결과, 스냅샷을 찍는 동안 소스 DB 인스턴스에 가벼운 I/O 중단이 발생합니다. I/O 중단은 일반적으로 1분 정도입니다. 소스 DB 인스턴스가 다중 AZ 배포(다중 AZ 배포의 경우 스냅샷이 예비 복제본에서 생성됨)인 경우에는 발생하지 않습니다.

Amazon RDS는 현재 최적화가 이루어지고 있습니다(곧 릴리스될 예정). 여러 읽기 전용 복제본을 30분 내에 생성할 경우 모든 읽기 전용 복제본이 동일한 소스 스냅샷을 사용해 I/O 영향을 최소화합니다(각 읽기 전용 복제본이 생성된 후 “추적” 복제가 시작됨).

표준 DB 인스턴스에 연결할 때와 마찬가지로 DescribeDBInstance API 또는 AWS 관리 콘솔을 사용하여 읽기 전용 복제본의 엔드포인트를 검색하여 읽기 전용 복제본에 연결할 수 있습니다. 읽기 전용 복제본이 여러 개인 경우 애플리케이션이 읽기 전용 복제본에 읽기 트래픽을 분산하는 방법을 결정합니다.

Amazon RDS for MySQL, Amazon RDS for MariaDB, Amazon RDS for PostgreSQL을 사용하면 특정 소스 DB 인스턴스에 대한 읽기 전용 복제본을 최대 15개까지 생성할 수 있습니다. Amazon RDS for Oracle 및 Amazon RDS for SQL Server를 사용하면 특정 소스 DB 인스턴스에 대한 읽기 전용 복제본을 최대 5개까지 생성할 수 있습니다.

예. Amazon RDS(RDS for SQL Server 제외)는 리전 간 읽기 전용 복제본을 지원합니다. 데이터를 원본 DB 인스턴스에 쓰는 시점과 데이터가 읽기 복제본에서 사용 가능한 시점 사이의 시간은 두 리전 간의 네트워크 지연 시간에 따라 다릅니다.

아니요. Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle 및 SQL Server의 읽기 전용 복제본은 이러한 엔진의 기본 비동기식 복제를 사용하여 구현됩니다. Amazon Aurora는 다른 복제 메커니즘을 사용하지만, 여전히 비동기식입니다.

복제를 사용해 데이터베이스 쓰기 가용성을 높이고 최근 데이터베이스 업데이트를 다양한 장애 조건으로부터 보호하려면 DB 인스턴스를 다중 AZ 배포로 실행하는 것이 좋습니다. Amazon RDS 읽기 전용 복제본과 지원되는 엔진의 기본 비동기식 복제를 사용하면 데이터베이스 쓰기가 소스 DB 인스턴스에서 발생한 다음 읽기 전용 복제본에서 발생합니다. 이 복제 “지연 시간”은 상당히 다를 수 있습니다. 

반면 다중 AZ 배포에서 사용되는 복제는 동기식이므로 모든 데이터베이스 쓰기가 기본 복제본과 예비 복제본에서 동시에 이루어집니다. 이렇게 최신 데이터베이스 업데이트를 보호하여 장애 조치 시, 예비 복제본에서 최신 데이터베이스 업데이트를 사용할 수 있습니다. 

또한 다중 AZ 배포를 통해 복제가 완벽하게 관리됩니다. Amazon RDS는 자동으로 DB 인스턴스 장애 상태 또는 가용 영역 장애를 모니터링하고, 가동 중단이 발생하면 예비 복제본(Amazon Aurora에서는 읽기 전용 복제본)으로 자동 장애 조치를 수행합니다.

예. 다중 AZ DB 인스턴스는 읽기 전용 복제본과 다른 요구를 해결하므로 제품 배포 시 이 둘을 함께 사용하고 읽기 전용 복제본과 다중 AZ DB 인스턴스 배포를 연결하는 것이 좋습니다. “소스” 다중 AZ-DB 인스턴스는 향상된 쓰기 가용성과 데이터 내구성을 제공하며 연결된 읽기 전용 복제본은 읽기 트래픽 확장성을 향상합니다.

예. Amazon RDS for MySQL, MariaDB, PostgreSQL 및 Oracle을 사용하면 읽기 전용 복제본에서 다중 AZ 구성을 활성화하여 재해 복구를 지원하고 엔진 업그레이드에 따른 가동 중단을 최소화할 수 있습니다.

다중 AZ 장애 조치가 발생할 경우 장애 조치가 완료되면 연결된 사용 가능한 읽기 전용 복제본이 복제를 자동으로 재개합니다(새로 승격된 기본 복제본에서 업데이트를 가져옴).

Amazon Aurora, Amazon RDS for MySQL, Amazon RDS for MariaDB의 경우 읽기 전용 복제본의 계층을 3개 생성할 수 있습니다. 기존의 첫 번째 계층 읽기 전용 복제본으로부터 두 번째 계층 읽기 전용 복제본을 생성할 수 있으며, 두 번째 계층 읽기 전용 복제본으로부터 세 번째 계층 읽기 전용 복제본을 생성할 수 있습니다. 두 번째 계층 및 세 번째 계층 읽기 전용 복제본을 생성함으로써, 사용자의 애플리케이션 요구 사항에 따라 기본 데이터베이스 인스턴스에서 복제 로드 중 일부를 읽기 전용 복제본의 다른 계층으로 이동할 수 있습니다.

트랜잭션이 기본 복제본에서 첫 번째 계층 복제본으로 복제된 다음 두 번째 계층 복제본으로 복제될 때 발생하는 추가 복제 지연 시간으로 인해 두 번째 계층 읽기 전용 복제본에서 기본 복제본보다 더 오랜 지연이 발생할 수 있습니다. 마찬가지로, 세 번째 계층 복제본에서 두 번째 계층 읽기 전용 복제본보다 더 오랜 지연이 발생할 수 있습니다.

Amazon RDS for Oracle 및 Amazon RDS for SQL Server의 경우 읽기 전용 복제본의 읽기 전용 복제본 생성은 현재 지원되지 않습니다.

읽기 전용 복제본은 읽기 트래픽을 처리하도록 설계되었습니다. 그러나 고급 사용자가 읽기 전용 복제본에 대해 데이터 정의 언어(DDL) SQL 문을 작성하려는 경우가 있을 수 있습니다. 예를 들어, 동일한 색인을 해당 소스 DB 인스턴스에 추가하지 않고, 비즈니스 보고에 사용되는 읽기 전용 복제본에 데이터베이스 인덱스를 추가할 수 있습니다.

Amazon RDS for MySQL은 읽기 전용 복제본에 대해 DDL SQL 문을 허용하도록 구성할 수 있습니다. 특정 읽기 전용 복제본에 읽기 작업이 아닌 다른 작업을 활성화하려면 읽기 전용 복제본의 활성 DB 파라미터 그룹을 변경하여 ‘read_only’ 파라미터를 ‘0’으로 설정합니다.

Amazon RDS for PostgreSQL은 현재 읽기 전용 복제본에 대한 DDL SQL 문 실행을 지원하지 않습니다.

예. 자세한 내용은 Amazon RDS 사용 설명서를 참조하세요.

소스 DB 인스턴스 업데이트는 모든 관련 읽기 전용 복제본에 자동으로 복제됩니다. 그러나 지원되는 엔진의 비동기식 복제 기술을 사용하면 다양한 이유로 읽기 전용 복제본이 소스 DB 인스턴스보다 지연될 수 있습니다. 대표적인 이유는 다음과 같습니다.

• 소스 DB 인스턴스에 대한 쓰기 I/O 볼륨이 읽기 전용 복제본에 변경 내용이 적용될 수 있는 비율을 초과하는 경우(이 문제는 특히 읽기 전용 복제본의 컴퓨팅 파워가 소스 DB 인스턴스보다 낮은 경우에 발생할 수 있음)
• 소스 DB 인스턴스에 대한 복잡하거나 오랫동안 실행되는 트랜잭션이 읽기 전용 복제본에 대한 복제를 보류하는 경우
• 네트워크 파티션이나 소스 DB 인스턴스와 읽기 전용 복제본 간의 지연 시간

읽기 전용 복제본은 지원되는 엔진의 기본 복제 기능의 장점과 단점을 가지고 있습니다. 읽기 전용 복제본을 사용하는 경우는 읽기 전용 복제본과 소스 DB 인스턴스 사이에 지연이나 ‘불일치’가 발생할 수 있다는 점을 인식해야 합니다.

표준 DescribeDBInstances API를 사용하여 배포한 모든 DB 인스턴스의 목록(읽기 전용 복제본 포함)을 반환하거나 Amazon RDS 콘솔의 ‘인스턴스(Instances)’ 탭을 클릭하면 됩니다.

Amazon RDS를 사용하면 읽기 전용 복제본이 소스 DB 인스턴스보다 얼마나 지연되었는지 볼 수 있습니다. 읽기 전용 복제본이 프라이머리보다 지연된 시간(단위: 초)이 AWS Management Console 또는 Amazon CloudWatch API를 통해 사용 가능한 Amazon CloudWatch 지표(‘복제 지연’)로 게시됩니다.

Amazon RDS for MySQL의 경우 이 정보의 소스가 읽기 전용 복제본에 대해 표준 ‘Show Replica Status(복제본 상태 보기)’ MySQL 명령을 실행하여 표시된 소스와 동일합니다. Amazon RDS for PostgreSQL의 경우 소스 DB 인스턴스에서 pg_stat_replication 보기를 사용하여 복제 지표를 탐색할 수 있습니다.

Amazon RDS는 읽기 전용 복제본의 복제 상태를 모니터링하고 복제가 어떤 이유로든지 정지된 경우(예: 프라이머리 데이터베이스 인스턴스에 업데이트된 내용과 충돌되는 DML 쿼리가 복제본에서 실행되면 복제 오류가 발생할 수 있음) AWS Management Console의 ‘Replication State(복제 상태)’ 필드를 ‘Error(오류)’로 업데이트합니다. 사용자는 복제 오류(Replication Error) 필드를 확인하여 MySQL 엔진에서 보낸 관련 오류의 상세 정보를 검토하고 오류를 복구하기 위한 적절한 조치를 취할 수 있습니다. 복제 문제 해결에 대해 자세히 알아보려면 Amazon RDS for MySQL 또는 Amazon RDS for PostgreSQL의 사용 설명서에 있는 읽기 전용 복제본 문제 해결 섹션을 참조하세요. 

복제 문제가 해결되면 Replication State가 Replicating으로 변경됩니다.

복제가 제대로 작동하기 위해서는 읽기 전용 복제본이 해당 소스 DB 인스턴스와 동등하거나 그 이상의 컴퓨팅 파워 및 스토리지 리소스를 갖도록 하는 것이 좋습니다. 그렇지 않으면 복제 지연이 증가하거나 읽기 전용 복제본이 복제된 업데이트를 저장할 공간이 부족할 수 있습니다.

AWS Management Console에서 몇 단계를 수행하거나 DB 인스턴스 식별자를 DeleteDBInstance API에 전달하여 읽기 전용 복제본을 삭제할 수 있습니다. 

해당 소스 DB 인스턴스가 삭제된 후에도 Amazon Aurora 복제본은 활성 상태로 유지되어 읽기 트래픽을 계속 수신합니다. 클러스터의 복제본 하나가 새로운 기본 복제본으로 자동으로 승격되어 쓰기 트래픽을 수신하기 시작합니다.

해당 소스 DB 인스턴스가 삭제된 후에도 MySQL 또는 MariaDB용 Amazon RDS 읽기 전용 복제본은 활성 상태로 유지되어 읽기 트래픽을 계속 수신합니다. 소스 DB 인스턴스와 함께 읽기 전용 복제본을 삭제하려면 DeleteDBInstance API 또는 AWS Management Console을 사용하여 읽기 전용 복제본을 확실히 삭제해야 합니다.

읽기 전용 복제본이 있는 PostgreSQL DB 인스턴스용 Amazon RDS를 삭제하면 모든 읽기 전용 복제본이 독립 실행형 DB 인스턴스로 승격되고 읽기 및 쓰기 트래픽을 모두 수신할 수 있습니다. 새로 승격된 DB 인스턴스가 서로 독립적으로 작동합니다. 원본 소스 DB 인스턴스와 함께 이러한 DB 인스턴스를 삭제하려면 DeleteDBInstance API 또는 AWS Management Console을 사용하여 인스턴스를 확실히 삭제해야 합니다.

읽기 전용 복제본은 표준 DB 인스턴스와 동일한 요금이 청구됩니다. 표준 DB 인스턴스와 마찬가지로 읽기 전용 복제본의 ‘DB 인스턴스 시간’당 요금은 읽기 전용 복제본의 DB 인스턴스 클래스에 의해 결정됩니다. 최신 요금 정보는 요금 페이지를 참조하세요. 동일한 AWS 리전 내의 소스 DB 인스턴스와 읽기 전용 복제본 간에 데이터를 복제할 때 발생한 데이터 전송에는 요금이 부과되지 않습니다.

읽기 전용 복제본의 요금 청구는 복제본이 성공적으로 생성된 직후에 시작됩니다(상태가 ‘활성’으로 표시되는 경우). 사용자가 삭제 명령을 실행할 때까지 읽기 전용 복제본에는 표준 Amazon RDS DB 인스턴스 시간 요금이 계속 청구됩니다.

Amazon RDS용 향상된 모니터링은 Amazon RDS 인스턴스 상태에 대해 좀 더 세부적인 가시성을 제공합니다. Amazon RDS DB 인스턴스에 대한 ‘Enhanced Monitoring(향상된 모니터링)’ 옵션을 활성화하고 시간 단위를 설정하기만 하면, 향상된 모니터링에서 정의된 시간 단위에 따라 주요 운영 체제 지표를 수집하고 정보를 처리합니다.

데이터베이스 로드에 대해 진단 및 시각화를 심화하고 데이터 보존 기간을 늘리기 위해 성능 개선 도우미를 사용해 보세요.

Enhanced Monitoring은 CPU, 메모리, 파일 시스템, 디스크 I/O 등과 같은 Amazon RDS 인스턴스 시스템 수준의 지표를 캡처합니다. 지표의 전체 목록은 설명서에서 확인할 수 있습니다.

Enhanced Monitoring은 모든 Amazon RDS 데이터베이스 엔진을 지원합니다.

Enhanced Monitoring에서는 t1.micro와 m1.small을 제외한 모든 인스턴스 유형을 지원합니다. 이 소프트웨어는 약간의 CPU, 메모리 및 I/O를 사용합니다. 범용 모니터링을 위해서는 미디엄 규모 이상의 인스턴스에서 시간 단위를 크게 설정하는 것이 좋습니다. 비프로덕션 DB 인스턴스의 경우 Enhanced Monitoring이 ‘off’로 기본 설정되어 있습니다. 비활성 상태로 두거나 활성 상태가 될 때 시간 단위를 변경할 수 있습니다.

콘솔에서는 Amazon RDS DB 인스턴스에 대한 모든 시스템 지표와 프로세스 정보를 그래프 형식으로 볼 수 있습니다. 인스턴스별로 모니터링하려는 지표를 관리하고, 요구 사항에 따라 대시보드를 변경할 수 있습니다.

Amazon RDS 계정의 DB 인스턴스별로 시간 단위를 다르게 설정할 수 있습니다. 또한, Enhanced Monitoring을 활성화할 인스턴스를 선택할 수 있을 뿐 아니라 어떤 인스턴스든 언제든지 원할 때 시간 단위를 변경할 수 있습니다.

설정에 따라 최대 1초의 세부 수준으로 최대 1시간 전까지 모든 지표의 성능 값을 확인할 수 있습니다.

Amazon RDS Enhanced Monitoring의 지표는 CloudWatch Logs 계정으로 전송됩니다. CloudWatch에서 CloudWatch Logs의 지표 필터를 생성하고 CloudWatch 대시보드에서 그래프를 표시할 수 있습니다. 자세한 내용은 Amazon CloudWatch 페이지를 참조하세요.

Amazon RDS 콘솔 대시보드에서 제공하는 기록 데이터보다 오래된 데이터를 보려면 CloudWatch를 사용해야 합니다. CloudWatch에서 Amazon RDS 인스턴스를 모니터링하여 단일 위치의 전체 AWS 스택의 상태를 진단할 수 있습니다. 현재 CloudWatch에서는 최대 1분의 시간 단위를 지원하며, 1분 미만의 시간 단위에 대한 값은 평균으로 계산됩니다.

예. CloudWatch에서 경보를 생성하여 경보 상태가 변경될 때 알림을 전송하도록 할 수 있습니다. 경보는 지정한 기간 동안 단일 지표를 감시하고, 여러 기간에 걸쳐 지정된 임계값과 관련된 지표 값을 기준으로 하나 이상의 작업을 수행합니다. CloudWatch 경보에 대한 자세한 내용은 Amazon CloudWatch 개발자 안내서를 참조하세요.

A: Amazon RDS Enhanced Monitoring에서는 JSON 페이로드로 구성된 지표 세트를 제공하며, 페이로드는 CloudWatch Logs 계정으로 전송됩니다. JSON 페이로드는 Amazon RDS 인스턴스에 대해 마지막으로 구성된 시간 단위에 따라 전송됩니다.

서드 파티 대시보드 또는 애플리케이션을 통해 지표를 사용할 수 있는 방법에는 두 가지가 있습니다. 모니터링 도구는 CloudWatch Logs 구독을 사용해 지표에 대한 거의 실시간 피드를 설정할 수 있습니다. 또는 CloudWatch Logs의 필터를 사용해 지표를 CloudWatch에 연결하고 애플리케이션을 CloudWatch와 통합할 수 있습니다. 자세한 내용은 Amazon CloudWatch 설명서를 참조하세요.

Enhanced Monitoring에서는 JSON 페이로드를 CloudWatch Logs 계정으로 전송하므로, 다른 CloudWatch Logs 스트림과 마찬가지로 보존 기간을 제어할 수 있습니다. CloudWatch Logs의 Enhanced Monitoring에 구성된 기본 보존 기간은 30일입니다. 보존 기간 설정을 변경하는 방법에 대한 자세한 내용은 Amazon CloudWatch 개발자 안내서를 참조하세요.

지표가 CloudWatch Logs로 수집되므로, CloudWatch Logs 프리 티어를 초과하면 CloudWatch Logs 데이터 전송 및 스토리지 요금을 기준으로 요금이 부과됩니다. 요금 내역은 여기에서 확인할 수 있습니다. Amazon RDS 인스턴스에 대해 전송된 정보의 양은 Enhanced Monitoring 기능에 정의된 시간 단위에 정비례합니다. 관리자는 계정 내의 여러 인스턴스에 각기 다른 시간 단위를 설정하여 비용을 관리할 수 있습니다.

인스턴스에 대한 Enhanced Monitoring에 의해 CloudWatch Logs로 수집된 대략적인 데이터 볼륨은 다음과 같습니다.

Amazon RDS 프록시는 Amazon RDS의 프록시 기능으로, 완전관리형의 고가용성 데이터베이스 프록시입니다. RDS Proxy를 사용하면 애플리케이션의 확장성, 데이터베이스 오류에 대한 복원력 및 보안을 개선할 수 있습니다.

Amazon RDS 프록시는 Amazon RDS의 프록시 기능으로, 완전관리형의 고가용성이며 사용이 쉬운 데이터베이스 프록시입니다. 이 프록시는 다음과 같은 이점을 제공합니다. 1) 데이터베이스 연결을 풀링하고 공유하여 애플리케이션의 확장성을 개선할 수 있습니다. 2) 데이터베이스 장애 조치 시간을 66%까지 줄이고 장애 조치 중에 애플리케이션 연결을 보존하여 애플리케이션의 가용성을 개선할 수 있습니다. 3) 데이터베이스에 AWS IAM 인증을 필요에 따라 적용하고 AWS Secrets Manager에 보안 인증 정보를 안전하게 저장하여 애플리케이션 보안을 개선할 수 있습니다.

Amazon RDS 프록시를 사용할 경우 워크로드에 따라 쿼리 또는 트랜잭션 응답 시간에 평균 5밀리초의 네트워크 지연 시간이 추가됩니다. 애플리케이션이 5밀리초의 지연 시간을 허용할 수 없거나 연결 관리 및 RDS로 지원되는 기타 기능이 필요하지 않다면 애플리케이션에서 데이터베이스 엔드포인트에 직접 연결하는 것이 좋을 수 있습니다.

Amazon RDS 프록시를 사용하면 관계형 데이터베이스의 기능과 단순함을 활용하는 최신의 서버리스 애플리케이션을 구축할 수 있습니다. 첫째, RDS 프록시를 사용하면 데이터베이스 연결을 풀링하고 재사용하여 서버리스 애플리케이션을 효율적으로 조정할 수 있습니다. 둘째, RDS 프록시를 사용하면 데이터베이스 자격 증명을 Lambda 코드로 처리할 필요가 없습니다. Lambda 함수에 연결된 IAM 실행 역할을 RDS 프록시 및 데이터베이스 인증에 사용할 수 있습니다. 셋째, 새로운 인프라 또는 코드를 관리하지 않고도 관계형 데이터베이스로 지원되는 서버리스 애플리케이션의 모든 기능을 활용할 수 있습니다. RDS 프록시는 완전관리형이며 애플리케이션 수요에 따라 자동으로 용량이 조정됩니다.

RDS 프록시는 Amazon Aurora(MySQL 호환), Amazon Aurora(PostgreSQL 호환), Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for PostgreSQL 및 Amazon RDS for SQL Server에 사용할 수 있습니다. 지원되는 엔진 버전 목록은 Amazon Aurora 사용 설명서 또는 Amazon RDS 사용 설명서를 참조하세요.

Amazon RDS 콘솔에서 클릭 몇 번으로 Amazon RDS 데이터베이스에 대한 Amazon RDS 프록시를 활성화할 수 있습니다. RDS 프록시를 활성화한 다음 RDS 프록시에서 액세스할 VPC 및 서브넷을 지정할 수 있습니다. Lambda 사용자의 경우 Lambda 콘솔에서 클릭 몇 번으로 Amazon RDS 데이터베이스에 대한 Amazon RDS 프록시를 활성화하고 프록시에 액세스할 Lambda 함수를 설정할 수 있습니다.

예. Amazon RDS 프록시 API를 사용하여 프록시를 생성한 다음 대상 그룹을 정의하여 프록시를 특정 데이터베이스 인스턴스 또는 클러스터에 연결할 수 있습니다. 예:

aws rds create-db-proxy 
        --db-proxy-name '…' 
        --engine-family <mysql|postgresql>       
        --auth [{}, {}] 
        --role-arn '…'
        --subnet-ids {}
        --require-tls <true|false>
        --tags {}
aws rds register-db-proxy-targets 
        --target-group-name '…'
        --db-cluster-identifier  '…'
        --db-instance-identifier '…'

Trusted Language Extensions(TLE) for PostgreSQL을 사용하면 고성능 PostgreSQL 확장 프로그램을 구축하고 Amazon Aurora 및 Amazon RDS에서 안전하게 실행할 수 있습니다. 이를 통해 TLE는 출시 시간을 단축하고, 프로덕션 데이터베이스 워크로드에 사용할 사용자 지정 및 서드 파티 코드를 인증해야 하는 데이터베이스 관리자의 부담을 덜어줍니다. 확장이 요구 사항을 충족한다고 판단되는 즉시 사용을 시작할 수 있습니다. 독립 소프트웨어 개발 판매 회사(ISV)는 TLE를 사용하여 Aurora 및 Amazon RDS 실행 고객에게 새로운 PostgreSQL 확장 프로그램을 제공할 수 있습니다.

PostgreSQL 확장 프로그램은 고성능을 제공하기 위해 동일한 프로세스 공간에서 실행됩니다. 그러나 확장 프로그램에 소프트웨어 결함이 있는 경우 데이터베이스가 충돌할 수 있습니다.

TLE for PostgreSQL은 여러 계층의 보호를 통해 이 위험을 완화합니다. TLE는 시스템 리소스에 대한 액세스를 제한하도록 설계되었습니다. rds_superuser 역할은 특정 확장 프로그램을 설치할 수 있는 사용자를 결정할 수 있습니다. 그러나 이러한 변경 사항은 TLE API를 통해서만 수행될 수 있습니다. TLE는 확장 프로그램의 결함이 미치는 영향을 단일 데이터베이스 연결로 제한합니다. 이러한 보호 장치에 더해 TLE는 rds_superuser 역할의 DBA에게 세분화된 온라인 제어를 제공하도록 설계되었습니다. 이 DBA는 확장 프로그램을 설치할 수 있는 사용자를 제어할 수 있고 확장 프로그램의 실행을 위한 권한 모델을 생성할 수 있습니다.

충분한 권한이 있는 사용자만 TLE 확장 프로그램에서 ‘CREATE EXTENSION’ 명령을 사용하여 확장 프로그램을 실행하고 생성할 수 있습니다. 또한 DBA는 데이터베이스의 내부 동작을 수정하고 일반적으로 권한 상승이 요구되는 보다 정교한 확장 프로그램에 필요한 ‘PostgreSQL 후크’를 허용 목록에 추가할 수 있습니다.

TLE for PostgreSQL은 Amazon Aurora PostgreSQL 호환 버전과 Amazon RDS on PostgreSQL 버전 14.5 이상에서 사용할 수 있습니다. TLE는 PostgreSQL 확장 프로그램 자체로 구현되며 Aurora 및 Amazon RDS에서 지원되는 다른 확장 프로그램과 마찬가지로 rds_superuser 역할에서 활성화할 수 있습니다.

Amazon Aurora 및 Amazon RDS의 PostgreSQL 14.5 이상에서 TLE for PostgreSQL을 실행할 수 있습니다.  

TLE for PostgreSQL은 현재 AWS 중국 리전을 제외한 모든 AWS 리전과 AWS GovCloud 리전에서 사용할 수 있습니다.

TLE for PostgreSQL은 Aurora 및 Amazon RDS 고객에게 추가 비용 없이 제공됩니다.

Aurora 및 Amazon RDS는 85개가 넘는 엄선된 PostgreSQL 확장 프로그램 세트를 지원합니다. AWS는 AWS Shared Responsibility Model에 따라 이러한 각 확장 프로그램의 보안 위험을 관리합니다. TLE for PostgreSQL을 구현하는 확장 프로그램은 이 세트에 포함됩니다. 서드 파티 소스를 사용하여 작성하거나 서드 파티 소스에서 가져와서 TLE에 설치하는 확장 프로그램은 사용자 애플리케이션 코드의 일부로 간주됩니다. TLE 확장 프로그램을 사용하는 애플리케이션의 보안은 사용자의 책임입니다.

비트맵 압축 및 차등 개인 정보 보호(예: 개인의 개인 정보를 보호하는 공개 액세스 가능한 통계 쿼리)와 같은 개발자 함수를 구축할 수 있습니다.

TLE for PostgreSQL은 현재 JavaScript, PL/pgSQL, Perl 및 SQL을 지원합니다.

rds_superuser 역할이 TLE for PostgreSQL을 활성화하면, psql과 같은 모든 PostgreSQL 클라이언트에서 SQL CREATE EXTENSION 명령을 사용하여 TLE 확장 프로그램을 배포할 수 있습니다. 이 방법은 프로시저 언어(예: PL/pgSQL 또는 PL/Perl)로 작성된 사용자 정의 함수를 생성하는 방법과 유사합니다. 관리자는 TLE 확장 프로그램을 배포하고 특정 확장 프로그램을 사용할 권한이 있는 사용자를 제어할 수 있습니다.

TLE for PostgreSQL은 TLE API를 통해서만 PostgreSQL 데이터베이스에 액세스합니다. TLE가 지원하는 신뢰할 수 있는 언어에는 PostgreSQL 서버 프로그래밍 인터페이스(SPI)의 모든 함수가 포함되며 암호 확인 후크를 포함한 PostgreSQL 후크를 지원합니다.

TLE for PostgreSQL 프로젝트에 대해서는 공식 TLE GitHub 페이지에서 자세히 알아볼 수 있습니다.

Amazon RDS 블루/그린 배포는 Amazon Aurora MySQL 호환 에디션, Amazon Aurora PostgreSQL 호환 에디션, Amazon RDS for MySQL, Amazon RDS for MariaDB 및 Amazon RDS for PostgreSQL에서 사용할 수 있습니다. 

Amazon RDS 블루/그린 배포는 Amazon Aurora MySQL 호환 버전 5.6 이상, RDS for MySQL 버전 5.7 이상 및 버전 MariaDB 버전 10.2 이상의 RDS에서 사용할 수 있습니다. 블루/그린 배포는 Amazon Aurora PostgreSQL 호환 에디션과 Amazon RDS for PostgreSQL 버전 11.21 이상, 12.16 이상, 13.12 이상, 14.9 이상 및 15.4 이상에 대해서도 지원됩니다. Amazon Aurora 및 Amazon RDS 설명서에서 사용 가능한 버전에 대해 자세히 알아보세요. 

Amazon RDS 블루/그린 배포는 모든 AWS 리전과 AWS GovCloud 리전에서 사용할 수 있습니다.

Amazon RDS 블루/그린 배포를 사용하면 더 안전하고 단순하며 빠르게 데이터베이스를 변경할 수 있습니다. 블루/그린 배포는 메이저 또는 마이너 버전 데이터베이스 엔진 업그레이드, 운영 체제 업데이트, 논리적 복제를 중단하지 않는 그린 환경의 스키마 변경(예: 테이블 끝에 새 열 추가) 또는 데이터베이스 파라미터 설정 변경과 같은 사용 사례에 적합합니다. 블루/그린 배포를 사용하면 한 번의 전환으로 여러 데이터베이스를 동시에 업데이트할 수 있습니다. 이를 통해, 예측 가능한 짧은 가동 중지 시간으로 보안 패치를 최신 상태로 유지하고, 데이터베이스 성능을 개선하고, 최신 데이터베이스 기능에 액세스할 수 있습니다.

블루 인스턴스에서 워크로드를 실행할 때와 동일한 비용이 그린 인스턴스에 대해 발생합니다. 블루 및 그린 인스턴스에서 실행할 때의 비용에는 db.instances에 대한 현재 표준 요금, 스토리지 비용, 읽기/쓰기 I/O 비용 및 사용된 기능에 대한 비용(예: 백업 비용 및 Amazon RDS 성능 개선 도우미 비용)이 포함됩니다. 실질적으로 블루 및 그린 배포가 진행되는 동안 db.instance에서 워크로드를 실행할 때의 약 2배에 해당하는 비용이 발생합니다.

예제: us-east-1 AWS 리전에서 다중 AZ(MAZ) 구성으로 RDS for MySQL 5.7 데이터베이스를 2개의 r5.2xlarge DB 인스턴스(기본 데이터베이스 인스턴스와 읽기 전용 복제본)에서 실행하고 있습니다. 각 r5.2xlarge DB 인스턴스는 20GiB 범용 Amazon Elastic Block Storge(EBS)에 대해 구성되어 있습니다. Amazon RDS 블루/그린 배포를 사용하여 블루 인스턴스 토폴로지의 클론을 생성하고 15일(360시간) 동안 실행한 다음 성공적인 전환 후에 블루 인스턴스를 삭제합니다. 블루 인스턴스의 비용은 시간당 1.926 USD의 온디맨드 요금으로 15일간 1,387 USD입니다(인스턴스 + EBS 비용). 이 15일간 블루/그린 배포를 사용한 데 대한 총 비용은 2,774 USD입니다. 이는 해당 기간에 블루 인스턴스를 실행하는 비용의 2배입니다.

Amazon RDS 블루/그린 배포에서는 메이저 또는 마이너 버전 업그레이드, 스키마 변경, 인스턴스 크기 조정, 엔진 파라미터 변경 및 유지 관리 업데이트와 같은 데이터베이스 변경을 더 안전하고 더 간단하며 더 빠르게 수행할 수 있습니다.

Amazon RDS 블루/그린 배포에서 블루 환경은 현재 프로덕션 환경입니다. 그린 환경은 전환 후에 새로운 프로덕션 환경이 될 스테이징 환경입니다.

Amazon RDS 블루/그린 배포에서 전환이 시작되면, 전환이 완료될 때까지 블루 환경과 그린 환경 모두에 대한 쓰기가 차단됩니다. 전환 중에 스테이징 환경 또는 그린 환경은 프로덕션 시스템과 동기화하여 스테이징 환경과 프로덕션 환경의 데이터가 일치할 수 있도록 합니다. 프로덕션과 스테이징 환경이 완벽하게 동기화되면 블루/그린 배포는 새롭게 승격된 프로덕션 환경으로 트래픽을 리디렉션하여 스테이징 환경을 새 프로덕션 환경으로 승격합니다. 블루/그린 배포는 전환이 완료된 후 그린 환경에 대한 쓰기를 지원하여 전환 프로세스 중에 데이터 손실이 발생하지 않도록 합니다.

블루 환경이 자체 관리형 논리적 복제본 또는 구독자인 경우 전환이 차단됩니다. 먼저 블루 환경으로의 복제를 중단하고, 전환을 진행한 다음 복제를 재개하는 것이 좋습니다. 반대로 블루 환경이 자체 관리형 논리적 복제본이나 게시자의 소스인 경우에는 계속 전환할 수 있습니다. 하지만 전환 후 친환경 환경에서 복제하려면 자체 관리형 복제본을 업데이트해야 합니다.

Amazon RDS 블루/그린 배포는 이전 프로덕션 환경을 삭제하지 않습니다. 필요한 경우 추가 검증 및 성능/회귀 테스트를 위해 이전 환경에 액세스할 수 있습니다. 이전 프로덕션 환경이 더 이상 필요하지 않다면 삭제해도 됩니다. 이전 프로덕션 인스턴스에는 인스턴스를 삭제하기 전까지 표준 결제 요금이 적용됩니다.

Amazon RDS 블루 및 그린 배포의 전환 가드레일은 전환 전에 그린 환경이 캐치업될 때까지 블루 및 그린 환경에 대한 쓰기를 차단합니다. 블루 및 그린 배포는 블루 및 그린 환경에 있는 프라이머리 및 복제본의 상태 확인도 수행합니다. 또한 복제 상태 확인도 수행하는데, 예를 들어 복제가 중지되었는지, 오류가 있는지 여부를 확인합니다. 블루 환경과 그린 환경 사이에 오래 실행되는 트랜잭션이 있는 경우 이를 감지합니다. 사용자는 허용 가능한 최대 가동 중단 시간을 최소 30초로 지정할 수 있으며, 진행 중인 트랜잭션이 이 값을 초과할 경우 전환 제한 시간이 초과됩니다.

아니요. Amazon RDS 블루/그린 배포는 글로벌 데이터베이스, Amazon RDS 프록시, 크로스 리전 읽기 전용 복제본 또는 캐스케이드된 읽기 전용 복제본을 지원하지 않습니다.

아니요. 지금은 Amazon RDS 블루/그린 배포를 사용하여 변경 사항을 롤백할 수 없습니다.

MySQL은 데이터를 16KiB 페이지의 메모리로 내구성 높은 스토리지에 두 번 기록하는 방법으로 데이터 손실로부터 사용자를 보호합니다. 처음에 ‘이중 쓰기 버퍼’에 기록한 다음 테이블 스토리지에 기록합니다. Amazon RDS 최적화된 쓰기는 AWS Nitro System의 Torn Write Prevention 기능을 사용하여 한 번에 안정적이고 지속적으로 16KiB 데이터 페이지를 데이터 파일에 직접 기록합니다.

Amazon RDS 최적화된 쓰기는 MySQL 메이저 버전 8.0.30 이상에서 사용할 수 있습니다.

Amazon RDS Optimized Writes는 db.r6i 및 db.r5b 인스턴스에서 사용할 수 있습니다. AWS 중국 리전을 제외하고 이러한 인스턴스가 제공되는 모든 리전에서 사용할 수 있습니다.

아니요. Amazon Aurora MySQL 호환 버전에서는 이미 ‘이중 쓰기 버퍼’의 사용을 방지하고 있습니다. 대신, Amazon Aurora는 3개 가용 영역에 걸쳐 6가지 방법으로 데이터를 복제하고 쿼럼 기반 접근 방식을 사용하여 데이터를 내구성 있는 방식으로 쓰고 이후에 올바르게 읽습니다.

현재 이 초기 릴리스는 인스턴스 클래스가 최적화된 쓰기를 지원하더라도 Amazon RDS 최적화된 쓰기를 기존 데이터베이스 인스턴스에 사용하는 것을 지원하지 않습니다.

Amazon RDS 최적화된 쓰기는 RDS for MySQL 고객에게 추가 비용 없이 제공됩니다.

MySQL 및 MariaDB의 임시 객체를 쿼리 처리에 사용하는 워크로드의 경우 Amazon RDS Optimized Reads의 이점을 누릴 수 있습니다. Optimized Reads는 Amazon Elastic Block Store 볼륨 대신, 데이터베이스 인스턴스의 NVMe 기반 인스턴스 스토리지에 임시 객체를 배치합니다. 이렇게 하면 복잡한 쿼리의 처리 속도가 최대 2배 더 빨라집니다.

Amazon RDS 최적화된 읽기는 RDS for MySQL의 경우 MySQL 버전 8.0.28 이상, RDS for MariaDB의 경우 MariaDB 버전 10.4.25, 10.5.16, 10.6.7 이상에서 사용 가능합니다.

Amazon RDS 최적화된 읽기는 db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn, X2iedn 인스턴스가 제공되는 모든 리전에서 사용할 수 있습니다. 자세한 내용은 Amazon RDS DB 인스턴스 클래스 설명서를 참조하세요.

복잡한 쿼리 또는 범용 분석이 필요한 워크로드 또는 복잡한 그룹, 정렬, 해시 집계, 높은 로드 조인 및 공통 테이블 표현식(CTE)이 필요한 워크로드가 있는 경우 고객은 Amazon RDS 최적화된 읽기를 사용해야 합니다. 이러한 사용 사례에서는 임시 테이블이 생성되므로 최적화된 읽기를 통해 워크로드의 쿼리 처리 속도를 높일 수 있습니다.

예. 워크로드를 최적화된 읽기 지원 인스턴스로 이동하는 방법으로 Amazon RDS 최적화된 읽기를 사용하도록 기존 Amazon RDS 데이터베이스를 전환할 수 있습니다. 또한, Optimized Reads는 지원되는 모든 인스턴스 클래스에서 기본적으로 사용할 수 있습니다. db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn, X2iedn 인스턴스에서 워크로드를 실행하고 있다면 이미 Optimized Reads의 이점을 누리고 있는 것입니다.