RDS MySQL 8.0 은 표준 지원이 끝나도 만들어집니다 — Extended Support 요금과 함께
RDS 인스턴스를 새로 만들기 전에, 로컬 개발 DB 에 맞춰 MySQL 8.0 을 고르려다 멈췄습니다. 8.0 의 표준 지원은 2026년 7월 31일에 끝났지만 CLI 로는 지금도 8.0 인스턴스가 만들어지고, 기본값 그대로면 Extended Support 에 자동으로 가입됩니다. 그 요금은 인스턴스 단가표에 보이지 않습니다.
제가 갖고 있던 통념은 «지원 종료일은 그 버전을 못 쓰게 되는 날»이었습니다. 실제로 그날은 요금 체계가 바뀌는 날이었고, 그 요금에 가입되는지는 CLI 와 콘솔에서 반대로 정해져 있었습니다.
근거는 AWS·MySQL 공식 문서, 2026-09-01 적용 공개 가격표, 개인 환경의 로컬 Docker 재현뿐이고, AWS 계정에서 직접 만들어 보지는 않았습니다.
MySQL 8.0 표준 지원 종료일은 «못 쓰게 되는 날»이 아니었습니다
RDS 문서의 MySQL 메이저 버전 달력에서 8.0 의 표준 지원 종료일은 2026년 7월 31일입니다. 다음 날부터 Extended Support 1·2년차 요금이, 2028년 8월 1일부터 3년차 요금이 붙고, Extended Support 도 2029년 7월 31일에 끝납니다. 8.4 의 표준 지원은 2029년 7월 31일까지입니다. 문서는 이 구간을 이렇게 설명합니다.
You can continue running a major version past its RDS end of standard support date for a fee.
표의 각주는 5.7 과 8.0 이 이제 Extended Support 로만 제공된다고 적습니다. 7월 31일은 8.0 이 멈춘 날이 아니라 같은 8.0 에 요금이 하나 더 붙기 시작한 날이고, 지금 새로 만드는 8.0 인스턴스는 처음부터 그 구간 안에 있습니다.
CLI 는 Extended Support 가입이 기본, 콘솔은 해제가 기본입니다
처음 확인한 곳은 로컬 AWS CLI(2.35.9)의 aws rds create-db-instance help 였습니다. API 를 호출하지 않아도 이 문단이 나옵니다.
--engine-lifecycle-support (string)
The life cycle type for this DB instance.
NOTE:
By default, this value is set to open-source-rds-extended-support
, which enrolls your DB instance into Amazon RDS Extended
Support. At the end of standard support, you can avoid charges
for Extended Support by setting the value to
open-source-rds-extended-support-disabled . In this case,
creating the DB instance will fail if the DB major version is
past its end of standard support date.옵션을 생략하면 가입입니다. 여기까지 읽고 저는 콘솔도 같을 거라고 생각했습니다. 기본값을 도구와 상관없는 성질처럼 읽었던 것인데, 반대였습니다.
If you use the console, you must select Enable RDS Extended Support. The setting isn't selected by default.
| 만드는 방법 | 가입을 정하는 자리 | 손대지 않으면 |
|---|---|---|
| AWS CLI | --engine-lifecycle-support |
가입 |
| RDS API | EngineLifecycleSupport |
가입 |
| 콘솔 | Enable RDS Extended Support 체크 | 해제 |
문서는 API 쪽 기본값이 CloudFormation 같은 자동화에서 표준 지원 종료일 뒤에도 데이터베이스를 계속 쓸 수 있게 해 준다고 설명합니다. 결과만 보면 API 는 멈추지 않는 쪽이, 콘솔은 요금이 붙지 않는 쪽이 기본입니다. 문서대로라면 콘솔에서 체크를 해제한 채로는 8.0 을 만들 수 없을 텐데, 화면에서 어떻게 막히는지는 확인하지 않았습니다.
이 선택은 나중에 되돌리는 종류도 아닙니다. 문서는 가입한 인스턴스가 그 수명 동안 영구히 가입 상태로 남는다고 적습니다. 요금이 실제로 붙는 것은 표준 지원이 끝난 버전을 돌리는 동안이지만, 가입 여부는 만드는 순간에 정해집니다.
Extended Support 요금은 인스턴스 단가를 보는 자리에 없습니다
서울 리전 db.t4g.medium(MySQL, Single-AZ)의 시간당 단가는 $0.102 입니다. Extended Support 요금은 이 자리에 보이지 않는데, 이유가 세 겹입니다.
첫째, 별도 항목입니다. 인스턴스·스토리지·백업·데이터 전송 요금에 더해 청구되고 예약 인스턴스 할인도 적용되지 않습니다. 둘째, 단위가 인스턴스-시간이 아니라 vCPU-시간입니다. 서울은 1·2년차 $0.120, 3년차 $0.240 이라 월 요금을 알려면 클래스의 vCPU 수를 따로 알아야 합니다.
셋째는 가격표를 기계로 거를 때 드러납니다. 서울 공개 가격표 CSV 에서 인스턴스 행의 Product Family 는 Database Instance 인데, Extended Support 행은 빈 문자열입니다. 이 열로 인스턴스 요금을 추리면 Extended Support 행은 소리 없이 빠지고, 걸러 낸 표만 보면 요금이 없다고 읽기 쉽습니다. 찾으려면 usageType 이 APN2-ExtendedSupport:Yr1-Yr2:MySQL8.0 처럼 ExtendedSupport 를 담은 행을 봐야 합니다.
비용을 계산해 보면 인스턴스가 쌀수록 배율이 커집니다
2026-09-01 적용 공개 가격표를 기준으로 월 730시간, Single-AZ, vCPU 2개로 계산했습니다. vCPU 는 두 클래스 모두 서울 가격표의 vCPU 열 기준이고, 괄호는 인스턴스 월 요금 대비 배율입니다.
| 리전 · 클래스 | 인스턴스 월 요금 | Extended Support 1·2년차 | 3년차 |
|---|---|---|---|
| 서울 db.t4g.medium | $74.46 | $175.20 (약 2.35배) | $350.40 (약 4.71배) |
| 서울 db.m7g.large | $171.11 | $175.20 (약 1.02배) | $350.40 (약 2.05배) |
| 버지니아 db.t4g.medium | $47.45 | $146.00 (약 3.08배) | $292.00 (약 6.15배) |
| 버지니아 db.m7g.large | $122.64 | $146.00 (약 1.19배) | $292.00 (약 2.38배) |
«작은 인스턴스일수록 배율이 커진다»로 읽기 쉽지만, 두 클래스는 vCPU 가 같아서 Extended Support 요금도 같습니다. 배율을 가른 것은 크기가 아니라 분모인 인스턴스 요금입니다. vCPU 당 단가가 싼 클래스일수록, 인스턴스 단가가 더 크게 낮은 버지니아일수록 같은 vCPU 요금이 무거워집니다. 3년차에는 단가가 두 배가 되고, Multi-AZ 로 두면 스탠바이도 과금 대상입니다.
끄는 선택은 «요금 없음»이 아니었습니다
그러면 open-source-rds-extended-support-disabled 를 적으면 끝일까요. 표준 지원이 이미 지난 메이저 버전이면 이 값으로는 생성이 항상 실패하니, 지금 8.0 에는 쓸 수 없습니다. 또 이 값으로 표준 지원 종료일을 맞은 인스턴스는 RDS 가 지원되는 엔진 버전으로 올립니다. 8.0 이었다면 8.4 로 올라갔고, 이 값으로 만든 8.4 도 2029년 7월 31일에 같은 차례를 맞습니다.
평소 RDS for MySQL 문서는 호환성 위험 때문에 메이저 업그레이드를 자동으로 적용하지 않는다고 적습니다. 그러니 끄는 것은 요금을 거절하는 선택이면서, 메이저 업그레이드의 시점을 RDS 에 넘기는 선택이기도 합니다.
그 시점은 공식 문서로 확인하지 못했습니다. 표현은 «표준 지원 종료일 당일 또는 직후»까지이고, 유지관리 창을 기다리는지, 사전 통지가 있는지, db-upgrade 유지관리 액션으로 먼저 보이는지는 적혀 있지 않습니다. 유지관리 문서의 «필수 적용일이 지난 강제 업그레이드는 선호 유지관리 창 밖에서도 적용될 수 있다»가 이 경우에 해당하는지도 적혀 있지 않습니다.
MySQL 8.4 로 간 데이터는 8.0 으로 돌아오지 않습니다
8.4 로 가는 문은 한 방향입니다. MySQL 8.4 매뉴얼은 in-place 다운그레이드를 같은 LTS 시리즈 안에서만 허용하고, 8.4 에서 8.0 으로는 논리 덤프·로드나 복제로만, 그것도 롤백 목적에 한해 지원합니다.
매뉴얼이 서버가 뜨지 않는다고 직접 쓰지는 않아서, 8.4.11 로 초기화한 볼륨을 로컬 Docker 의 mysql:8.0 이미지로 띄워 봤습니다. 기동 안내 줄과 마지막 종료 줄은 ... 로 줄였습니다.
== initialized by: 8.4.11
== started with image mysql:8.0 on the same volume; running=false exit=1
...
2026-09-11T14:03:58.172770Z 1 [ERROR] [MY-014061] [InnoDB] Invalid MySQL server downgrade: Cannot downgrade from 80411 to 80046. Downgrade is only permitted between patch releases.
mysqld: Can't open file: 'mysql.ibd' (errno: 0 - )
2026-09-11T14:03:58.611271Z 1 [ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
2026-09-11T14:03:58.611397Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2026-09-11T14:03:58.611419Z 0 [ERROR] [MY-010119] [Server] Aborting
...Cannot downgrade from 80411 to 80046 다음으로 데이터 딕셔너리 초기화가 실패하고, 컨테이너는 exit 1 로 끝났습니다.
한계도 적어 둡니다. 8.0 에서 올린 볼륨이 아니라 처음부터 8.4 로 초기화한 볼륨이고, RDS 가 아니라 로컬 MySQL 입니다. RDS for MySQL 문서에서 찾은 것은 업그레이드가 실패했을 때 원래 버전으로 되돌린다는 설명뿐이었습니다. 로컬에서도 8.4 가 한 번 초기화한 볼륨을 8.0 컨테이너가 물면 위 로그를 만나게 되니, 개발용 볼륨도 버전별로 나눠 두는 편이 낫겠다는 생각이 들었습니다.
RDS 인스턴스를 만들기 전에 확인하는 세 가지
버전을 볼 때 흔히 쓰는 describe-db-engine-versions 의 응답 형식에는 수명주기 필드가 없습니다. 날짜는 describe-db-major-engine-versions 의 SupportedEngineLifecycles 에, 가입 상태는 인스턴스의 EngineLifecycleSupport 에 있습니다.
# 메이저 버전별 표준 지원 · Extended Support 시작일과 종료일
aws rds describe-db-major-engine-versions --engine mysql \
--query 'DBMajorEngineVersions[].{v:MajorEngineVersion,lc:SupportedEngineLifecycles}'
# 이미 있는 인스턴스의 버전과 가입 상태
aws rds describe-db-instances \
--query 'DBInstances[].{id:DBInstanceIdentifier,ver:EngineVersion,lc:EngineLifecycleSupport}'세 번째는 습관입니다. 새로 만들 때 --engine-lifecycle-support 를 비워 두지 않고 두 값 중 하나를 적어 둡니다. 가입이면 표준 지원이 끝난 뒤 vCPU-시간 요금이, 해제면 그 시점의 메이저 업그레이드가 따라옵니다.
남는 것 — 기본값은 제가 고른 값이 아니었습니다
돌이켜 보면 틀릴 뻔한 자리는 두 군데였습니다. «지원 종료»를 «멈춤»으로 읽은 것과, CLI 도움말의 기본값을 콘솔에도 옮겨 놓은 것입니다. 둘 다 문서를 안 읽어서가 아니라, 한 곳에서 읽은 것을 다른 곳에서도 참이라고 여겨서 생긴 착각이었습니다.
요금도 숨겨져 있지는 않았습니다. 인스턴스 단가표, 인스턴스-시간 단위, Product Family 거르기라는 익숙한 찾는 방법 세 가지를 모두 비껴간 자리에 있었을 뿐입니다. 보이지 않는 것과 없는 것이 다르다는 말을 이번에는 숫자로 확인했습니다.
기본값은 누군가 미리 내려 둔 결정입니다. API 는 멈추지 않는 쪽을, 콘솔은 요금이 붙지 않는 쪽을 골라 두었고, 둘 다 그럴 만하지만 어느 쪽도 제 인스턴스를 보고 고른 것은 아닙니다. 끈 인스턴스가 정확히 언제 올라가는지처럼 문서가 말하지 않는 부분도 남아 있습니다. 그래서 앞으로는 인스턴스를 만들 때 그 한 줄을 비워 두지 않으려 합니다.
참고 문서
관련 글
EC2를 띄우기 전에 AWS CLI로 먼저 잰 것들 — 계획서가 틀려 있던 8가지
Coolify를 EC2에 올리기 전, 읽기 전용 describe만으로 계정을 먼저 쟀습니다. 계획서의 1순위 단계는 불필요했고, 정작 필수였던 것들은 계획서에 아예 없었습니다. 비용 0인 준비만 먼저 끝낸 과정을 정리했습니다.
EXPLAIN으로 읽는 쿼리 실행 계획 — 느린 쿼리 진단법 (5편)
EXPLAIN의 type이 ALL이면 무조건 나쁜 건가? rows는 정확한 숫자인가? 1-4편의 내부 구조 지식을 바탕으로, EXPLAIN 각 컬럼의 의미와 느린 쿼리를 진단하고 개선하는 실전 접근법을 정리합니다.
SSM 포트포워딩으로 배스천 없이 프라이빗 RDS 에 접속하기 — 세션 권한은 네트워크 권한이었습니다
SSM 포트포워딩은 대상 인스턴스에 인바운드 규칙도, 배스천도 없이 프라이빗 RDS 에 로컬 포트로 붙게 해 줍니다. 다만 IAM 은 목적지 host 를 조건으로 묻지 못해, 세션을 열 권한이 곧 그 인스턴스가 네트워크에서 닿는 모든 곳에 대한 접근이 됩니다.