RDS를 처음 배울 땐 "암호화 체크박스 켜고, 백업 보존 7일로 두고, CloudWatch 알람 몇 개 걸면 끝"이라고 생각하기 쉽다. 그런데 production에서 사고가 나는 지점은 정확히 그 빈틈에 있다. 2019년 7월 Capital One의 1억 600만 건 개인정보 유출은 RDS 자체의 결함이 아니라 메타데이터 인증·IAM 권한·S3 백업 노출이라는 운영 면의 빈틈에서 시작됐다. 오늘 다룰 주제 — 암호화, IAM DB 인증, 백업, 모니터링 — 은 모두 그런 사고를 막기 위해 RDS가 진화시켜온 운영 기능들이다.
DVA-C02에서 이 주제는 시나리오 단골이다. "비밀번호를 코드에 안 박고 싶다"고 하면 IAM 인증 또는 Secrets Manager, "5분 단위 복구가 필요하다"면 PITR, "쿼리가 느린 원인을 찾아야 한다"면 Performance Insights — 이런 1:1 매핑이 머릿속에 박혀 있어야 한다.
RDS의 저장 데이터 암호화는 AWS KMS(AWS Key Management Service)로 관리되는 키를 사용해 AES-256-XTS로 EBS 볼륨, 자동 백업, 읽기 전용 복제본, 스냅샷 전부를 암호화한다. 그런데 이상한 제약이 하나 있다: 이미 만들어진 RDS 인스턴스를 사후에 암호화로 바꿀 수 없다. 콘솔에도 그 옵션이 없다