빌드업웍스
Amazon Linux 2 지원이 끝난 서버, 무엇으로 옮겨야 합니까?
Amazon Linux 2의 표준 지원이 2026년 6월 30일에 끝난 뒤, 아직 그 운영체제로 서비스를 운영하는 회사에서 자주 받는 질문입니다. 서버가 멈추지 않으니 급하지 않다는 의견과 당장 옮겨야 한다는 의견이 엇갈리는 경우가 많습니다.
빌드업웍스 답변
빌드업웍스 엔지니어핵심 답변
Amazon Linux 2(AL2)는 2026년 6월 30일에 표준 지원이 끝났고 유료 연장 지원 프로그램도 없으며, AWS는 다음 버전을 기다리지 말고 Amazon Linux 2023(AL2023)으로 지금 옮기라고 안내합니다. 서버는 계속 동작하지만, AWS 안내대로 AL2에 오래 머무를수록 새로 발견되는 취약점에 노출되는 위험이 커집니다. AWS는 메이저 버전 사이의 제자리 업그레이드를 지원하지 않으므로, AL2023 새 인스턴스에 다시 구성해 검증한 뒤 전환하는 순서로 계획해야 합니다.
- AL2 표준 지원은 2026년 6월 30일에 끝났습니다
- AL2에는 유료 연장 지원이 없고, 대안은 AL2023 이전입니다
- AL2023도 2027년 7월부터 유지보수 단계에 들어갑니다
- 패키지 관리자·cron·Python 2·EPEL 의존부터 확인합니다
- 실행 중인 서버보다 시작 템플릿과 AMI를 먼저 바꿉니다
지금 상태 — 멈추지는 않지만 위험이 쌓입니다
Amazon Linux 2는 2026년 6월 30일에 표준 지원이 끝났습니다. 지원이 끝났다고 서버가 꺼지거나 접속이 막히지는 않습니다. 달라진 것은 표준 보안 업데이트가 더 이상 나오지 않는다는 점입니다. AWS는 AL2에 남아 있을수록 새로 발견되는 취약점이 패치되지 않아 위험이 커진다고 안내하고, 다음 버전을 기다리지 말고 지금 AL2023으로 옮기라고 권합니다.
AWS는 RHEL 7과 달리 AL2에는 유료 연장 지원(ELS) 프로그램이 없고, 종료일 이후 기간을 늘리는 예외나 추가 지원 선택지도 없다고 안내합니다. 그래서 대응은 「옮길지 말지」가 아니라 「어떤 서버를 어떤 순서로 옮길지」를 정하는 일입니다.
영향을 받는 서버를 찾는 방법은 어렵지 않습니다. EC2 콘솔에서 인스턴스의 AMI 이름과 플랫폼 정보를 확인하거나, 서버 안에서 /etc/os-release 파일을 열어 운영체제 이름과 버전을 봅니다. 여러 계정을 쓰고 있다면 계정마다 따로 확인해야 합니다.
AL2023으로 갈지, 다른 운영체제로 갈지
대부분의 경우 AL2023이 기본 선택입니다. 같은 AWS 배포판이라 EC2·컨테이너·관리 도구와의 연결이 그대로이고, AWS가 공식 후속 버전으로 안내하는 운영체제이기 때문입니다.
다만 AL2023의 지원 기간은 함께 알고 가야 합니다. 표준 지원은 2027년 6월 30일까지이고, 그 뒤 2029년 6월 30일까지는 보안 업데이트와 중요한 버그 수정만 제공되는 유지보수 단계입니다. 「곧 표준 지원이 끝나는 버전으로 옮겨도 되느냐」는 질문이 뒤따르는데, AWS는 미래 버전을 기다리지 말고 지금 AL2023으로 옮기라고 분명히 안내합니다. AL2023은 glibc·OpenSSL·OpenSSH·DNF 같은 핵심 패키지를 메이저 버전의 수명 동안 지원하고, 개별 패키지의 지원 상태는 dnf supportinfo 명령으로 확인할 수 있습니다.
AL2023으로 이전
- AWS 공식 후속 운영체제
- EC2·컨테이너 이미지·관리 도구와 연결이 그대로
- 2029년 6월 30일까지 보안 업데이트
- 패키지 이름과 설치 방식은 AL2와 다릅니다
다른 리눅스 배포판으로 이전
- 사내 표준이나 소프트웨어 공급사 요구가 있을 때 검토
- 패키지 체계까지 바뀌면 변경 폭이 더 커집니다
- 상용 배포판은 운영체제별 시간 단가가 따로 매겨집니다
- 지원 기간을 배포판마다 따로 확인해야 합니다
애플리케이션을 컨테이너로 옮길 계획이 이미 있다면, 이번 전환을 그 계기로 삼는 방법도 있습니다. 서버 운영체제에 대한 의존이 줄어 다음 지원 종료 때의 부담도 함께 줄어듭니다.
옮기기 전에 확인할 차이
AWS는 AL2023에서 달라진 점을 비교 문서로 공개하고 있습니다. 실무에서 전환을 막는 것은 대부분 다음 표의 항목입니다.
| 항목 | AL2 | AL2023 | 확인할 것 |
|---|---|---|---|
| 패키지 관리자 | YUM | DNF | 설치 스크립트·사용자 데이터 |
| 추가 패키지 | amazon-linux-extras | 제공하지 않음(버전별 이름의 패키지로 대체) | extras로 설치한 PHP·Nginx 등 |
| EPEL | EPEL7 패키지 다수 동작 | 바이너리 호환 EPEL 없음 | 대체 패키지 유무 |
| 예약 작업 | cron | cron 기본 미설치, systemd 타이머 | 배치·백업 스크립트 |
| Python | Python 2.7 포함 | Python 3로 대체 | 오래된 운영 스크립트 |
| 로그 | rsyslog | systemd journal | 로그 수집 에이전트 설정 |
AL2에서 쓰던 EPEL7 저장소는 2024년 6월 30일부터 유지보수가 끝나 보안 수정도 나오지 않습니다. EPEL에 기대던 패키지는 AL2023 기본 저장소에 같은 기능의 패키지가 있는지부터 찾습니다. AWS가 EPEL9 패키지를 AL2023용으로 빌드해 제공하는 SPAL(Supplementary Packages for Amazon Linux)도 있지만, AWS 지원 플랜의 대상이 아니고 취약점(CVE) 추적도 하지 않으므로 운영 서버의 핵심 의존성으로 두지 않는 편이 안전합니다.
하나 더 있습니다. AL2는 인스턴스를 시작할 때 보안 업데이트를 설치했지만, AL2023은 기본값으로 그렇게 하지 않습니다. 저장소 버전을 지정해 업데이트 시점을 통제하는 방식이라, 업데이트 정책을 따로 정해 두지 않으면 패치가 계속 밀릴 수 있습니다.
옮기는 순서 — 제자리 업그레이드는 지원되지 않습니다
AWS는 AL2에서 AL2023으로 가는 경우를 포함해 메이저 버전 사이의 제자리 업그레이드를 지원하지 않는다고 밝히고 있습니다. 운영 중인 서버의 운영체제만 바꾸는 공식 경로가 없으므로, 새 AL2023 인스턴스에 다시 구성하고 검증한 뒤 트래픽을 옮기는 방식으로 계획합니다.
- 대상 목록 만들기실행 중인 인스턴스뿐 아니라 AL2 기반 AMI, 시작 템플릿, 오토스케일링 그룹까지 계정별로 찾습니다.
- 의존성 정리설치 스크립트, extras·EPEL 패키지, cron 작업, Python 2 스크립트, 모니터링·보안 에이전트를 적습니다.
- AL2023에 다시 구성가능하면 손 작업 대신 스크립트나 코드로 구성해 다음 전환 때 다시 씁니다.
- 검증기능뿐 아니라 배치 실행, 로그 수집, 백업, 모니터링 경보까지 확인합니다.
- 전환과 되돌림 준비로드 밸런서나 DNS로 트래픽을 옮기고, 이전 서버는 안정이 확인될 때까지 지우지 않습니다.
AWS 이전 준비 문서는 cron 작업을 AL2에서 미리 systemd 타이머로 바꿔 두는 방법도 안내합니다. 이렇게 하면 전환 당일에 바꾸는 항목이 줄어듭니다.
빌드업웍스가 지원 종료 대상을 점검할 때 가장 먼저 보는 것은 실행 중인 서버보다 시작 템플릿과 AMI입니다. 실행 중인 서버를 모두 옮겨도 템플릿이 그대로면, 다음 확장 때 AL2 서버가 다시 만들어지기 때문입니다.
함께 하지 말아야 할 것
비용을 줄이려고 운영체제 전환과 Graviton(ARM) 전환을 한 번에 진행하는 경우가 있습니다. AWS의 Graviton 전환 안내는 필요한 업그레이드를 먼저 기존 x86 환경에서 끝내 한 번에 바뀌는 변수를 줄이라고 권합니다. 문제가 생겼을 때 원인을 운영체제와 아키텍처 중 어디에서 찾아야 할지 갈리지 않게 하려는 것입니다.
참고 자료
이어서 보기
AWS · 클라우드 자주 받는 질문
Graviton(ARM)으로 옮기기 전에 무엇을 확인해야 합니까?
Graviton 전환의 난이도는 무엇을 옮기느냐에 달려 있습니다. RDS·ElastiCache 같은 관리형 서비스는 지원되는 엔진 버전에서 Graviton 인스턴스 클래스로 바꾸는 일이 중심이고, EC2는 운영체제의 Graviton 지원, 컴파일된 바이너리와 컨테이너 이미지의 arm64 빌드, 모니터링·보안 에이전트의 arm64 지원을 먼저 확인해야 합니다. Windows는 Graviton 인스턴스에서 실행되지 않으며, 운영체제 업그레이드와 아키텍처 전환은 한 번에 섞지 않는 것이 원칙입니다.
답변 2026-10-22
AWS · 클라우드 자주 받는 질문
RDS 연장 지원 요금이 청구됐다면 무엇부터 해야 합니까?
RDS 연장 지원(Extended Support) 요금은 표준 지원이 끝난 메이저 버전을 계속 쓰면 다음 날부터 자동으로 붙고, 프로비저닝 인스턴스는 vCPU 시간 단위로 다중 AZ 대기 인스턴스와 읽기 복제본까지 과금됩니다. 요금을 멈추는 방법은 표준 지원 중인 버전으로 업그레이드하거나 해당 데이터베이스를 삭제하는 것뿐입니다. 지원 종료가 지난 인스턴스의 등록을 해제하면 자동 메이저 업그레이드가 일어나므로, 복원본에서 업그레이드를 검증한 뒤 블루/그린 배포로 전환하는 순서가 안전합니다.
답변 2026-10-22
함께 보면 좋은 자료AWS 지원 종료 기한과 대응 절차함께 보면 좋은 자료AWS 환경 무료 점검댓글
답변에 덧붙일 질문이나 경험을 남겨 주세요. 빌드업웍스가 확인한 뒤 게시합니다.
댓글을 불러오는 중입니다.
궁금한 점을 편하게 남겨 주세요
영업 연락은 드리지 않습니다. 빌드업웍스 엔지니어가 영업일 2~3일 안에 답변드리고, 카카오톡·텔레그램 채팅으로도 상담하실 수 있습니다.