AWS 15 AWS가 접은 서비스들 — App Runner·QLDB·Pinpoint·Kendra·CodeCommit

블로그 글을 따라 App Runner 로 컨테이너를 올리려고 콘솔을 열면 「새 고객을 받지 않는다」는 안내가 먼저 뜹니다. 2년 전 튜토리얼이 권하던 Cloud9 도, 사내 검색을 붙이라던 Kendra 도 마찬가지입니다. AWS 는 서비스를 계속 내놓지만 접기도 합니다. 접히는 서비스는 유지보수(새 고객 차단)·종료 예정(종료일 확정)·완전 종료(이미 꺼짐) 세 목록에 오릅니다. 2026-11-13 에 세 목록을 세어 보니 유지보수에 56개, 종료 예정에 16개, 완전 종료에 62개 서비스·기능이 올라 있었습니다.

이 편이 답하려는 질문은 하나입니다. 내가 쓰거나 쓰려는 서비스가 접히는 중이라면, 언제까지 쓸 수 있고 어디로 옮기나? 이 편은 열두 서비스를 지금 상태별로 묶어 봅니다. 이미 꺼진 넷, 새 고객만 막은 다섯, 한마디로 접혔다고 하기 어려운 둘, 그리고 접혔다가 돌아온 CodeCommit 입니다. 수명 단계 페이지는 리전을 나누지 않고 서비스 단위로 적습니다.

지도

내 서비스가 어디에 해당하는지는 세 목록 가운데 어디에 이름이 있는지로 갈립니다.

flowchart TD
    START["쓰는 중이거나<br/>쓰려는 서비스"] --> Q1{"수명 단계 세 목록에<br/>이름이 있나"}
    Q1 -- "없다" --> OK["그대로 쓴다"]
    Q1 -- "유지보수" --> Q2{"이미 쓰고 있는<br/>계정인가"}
    Q2 -- "그렇다" --> KEEP["계속 쓴다<br/>새 기능은 없다"]
    Q2 -- "아니다" --> ALT["AWS 가 권하는<br/>대안으로 시작한다"]
    Q1 -- "종료 예정" --> SUN["종료일 전에<br/>옮긴다"]
    Q1 -- "완전 종료" --> GONE["콘솔·리소스가 없다<br/>대안으로 다시 짓는다"]

유지보수 목록이면 이미 쓰는 계정은 그대로 두고, 새로 시작하는 사람만 대안으로 갑니다. 종료 예정 목록이면 날짜가 정해진 이사입니다. 완전 종료 목록이면 옮길 원본조차 남아 있지 않습니다.

1. 접는 데는 세 단계가 있다

「새 고객을 받지 않는다」와 「지원을 끝낸다」는 같은 말일까요? AWS 는 둘을 다른 단계로 둡니다(AWS Lifecycle Changes).

첫 단계는 유지보수(Maintenance)입니다. 새 고객은 들어올 수 없고, 이미 쓰던 고객은 계속 씁니다. AWS 는 운영과 지원을 이어 가지만 기능을 더하지 않습니다. 눈여겨볼 점은 이 단계에 끝나는 날이 적혀 있지 않다는 것입니다. 오래 머물 수도, 다음 단계로 넘어갈 수도, 드물게는 되돌아올 수도 있습니다(5절의 CodeCommit).

둘째 단계는 종료 예정(Sunset)입니다. 여기서부터 날짜가 붙습니다. 보통 발표 뒤 12개월이고, 그날 AWS 가 운영과 지원을 끝냅니다. 이미 쓰는 고객에게 하는 말도 「계속 써도 된다」에서 「옮길 계획을 세워라」로 바뀝니다.

마지막이 완전 종료(Full Shutdown)입니다. 서비스가 AWS 에서 빠져 어떤 형태로도 쓸 수 없습니다. 콘솔이 닫히고 그 안에 만들어 둔 리소스에도 닿을 수 없으니, 데이터를 꺼내는 일은 그 전에 끝냈어야 합니다.

이미 쓰는 사람에게 날짜가 생기는 것은 종료 예정부터입니다. 유지보수까지는 새로 들어가려는 사람만 막힙니다.

세 목록은 유지보수(Services in Maintenance), 종료 예정(Services in Sunset), 완전 종료(Services in Full Shutdown) 페이지가 정본입니다. 바뀔 때마다 찾아 들어가기 번거롭다면 수명 단계 문서의 RSS 피드를 구독해 둡니다. 서비스 하나가 통째로 접히지 않고 기능 하나만 접히는 일도 많아서(S3 Select, CloudTrail Lake, SageMaker AI 의 여러 기능 등이 유지보수 목록에 있습니다), 서비스 이름만 찾지 말고 쓰는 기능 이름까지 찾아봐야 합니다.

이 편 서비스들은 2024년 여름부터 차례로 새 고객을 막았고, 새 고객 차단에서 완전 종료까지는 대개 1~2년이 걸렸습니다.

이 편 서비스의 수명 단계 날짜 · 2026-11-13 확인
2024-07     CodeCommit 새 고객 차단
2024-07-25  Cloud9 유지보수(새 고객 차단)
2024-09-24  App Mesh 새 고객 차단
2025-05-20  IoT Events · Pinpoint 새 고객 차단
2025-07-31  QLDB 완전 종료
2025-11-07  Mainframe Modernization 관리형 런타임 유지보수
2025-11-12  Snowball Edge 완전 종료 목록 등재
2025-11-24  CodeCommit 정식 서비스로 복귀
2026-03-31  App Runner · IoT FleetWise 유지보수 발표
2026-04-30  App Runner · IoT FleetWise 새 고객 차단
            Q Developer IDE 플러그인 종료 예정 발표
2026-05-15  Q Developer IDE 플러그인 새 가입 차단
2026-05-20  IoT Events 완전 종료
2026-06-30  Kendra · Q Business 유지보수
            Mainframe Modernization 자체 관리형 유지보수
2026-07-30  Kendra 새 고객 차단
2026-09-30  App Mesh 완전 종료
2026-10-30  Pinpoint 완전 종료(참여 기능)
2026-12-31  Snowball 지원 종료(제품 페이지, 상업 리전. 완전 종료 목록 날짜와 다르다)
2027-04-30  Q Developer IDE 플러그인 · 유료 구독 지원 종료

IoT Events 는 1년, Pinpoint 는 1년 5개월, App Mesh 는 2년 만에 꺼졌습니다. 새 고객을 막는다는 소식이 들리면 그때부터 옮길 준비를 시작하는 편이 안전합니다.

2. 이미 꺼진 넷 — QLDB·App Mesh·IoT Events·Pinpoint

완전 종료된 서비스는 무슨 일을 하던 것이고, 그 일은 이제 어디서 할까요? 넷 다 대안이 「이름만 바뀐 같은 서비스」가 아니어서, 옮길 때 구성을 다시 설계해야 한다는 점이 같습니다.

QLDB(Quantum Ledger Database)는 원장 데이터베이스였습니다. 커밋된 모든 트랜잭션을 지울 수 없는 저널에 블록으로 쌓고, 블록끼리 암호 해시로 이어서 나중에 기록이 고쳐지지 않았음을 검증할 수 있게 했습니다. 송금 이력이나 차량 소유 이력처럼 「누가 언제 무엇을 바꿨는지」를 감사관에게 증명해야 하는 데이터를 담았습니다. 2025-07-31 에 완전 종료됐고, AWS 는 Aurora PostgreSQL(03-1편)로 옮기는 길을 안내했습니다. 다만 Aurora PostgreSQL 은 변경 이력을 불변으로 들고 있지 않습니다. 그래서 행이 바뀔 때마다 트리거로 감사용 테이블에 복사하고, PostgreSQL 의 감사 로그 확장인 pgAudit 의 로그를 CloudWatch Logs 로 내보내는 식으로 이력을 따로 만들어야 합니다(監査のユースケースで Amazon QLDB を Amazon Aurora PostgreSQL に置き換える, AWS 일본어 블로그. 2026-11-13 기준 영어 원문 주소는 데이터베이스 제품 페이지로 넘어갑니다).

App Mesh 는 서비스 메시였습니다. 마이크로서비스끼리 주고받는 호출의 라우팅·재시도·관측을 애플리케이션 코드 밖으로 빼서, 태스크마다 옆에 붙인 Envoy 프록시(사이드카 컨테이너)가 처리하게 하는 방식입니다. 2024-09-24 에 새 고객을 막고 2026-09-30 에 완전 종료됐습니다. ECS 를 쓰던 곳에는 ECS Service Connect 를 권합니다. 같은 Envoy 를 쓰지만 프록시를 AWS 가 관리해 사이드카를 직접 돌볼 일이 없습니다. EKS 를 쓰던 곳에는 VPC Lattice(04-1편)를 권합니다(Migrating from AWS App Mesh to Amazon ECS Service Connect · What Is AWS App Mesh?).

IoT Events 는 장비가 보내는 센서 값을 지켜보다가 「과열」「정상 복귀」 같은 상태 변화를 알아채고 동작을 일으키는 서비스였습니다. 상태와 전이 조건을 탐지기 모델(detector model)이라는 상태 기계로 정의해 두면, 장비마다 탐지기 인스턴스를 따로 띄워 상태를 추적할 수 있었습니다. 2025-05-20 에 새 고객을 막고 2026-05-20 에 완전 종료됐습니다. AWS 의 이전 안내는 서비스 하나가 아니라 부품 넷을 엮은 구성입니다.

• 장비 메시지는 IoT Core 규칙이 Kinesis Data Streams(07-3편)로 넘깁니다.
• 상태 전이 논리는 Lambda 함수가 맡습니다.
• 장비별 상태는 DynamoDB 에 둡니다.
• 타이머는 EventBridge 일정이 대신합니다.

AWS 스스로 이 구성을 운영용 대체품이 아니라 예시라고 적었으니, 상태 기계를 직접 짜고 지키는 일은 쓰는 사람 몫입니다(AWS IoT Events Developer Guide (PDF)).

Pinpoint 는 고객을 무리로 나누고 캠페인을 짜서 이메일·SMS·푸시를 보내는 마케팅 서비스였습니다. 2025-05-20 에 새 고객을 막고 2026-10-30 에 이 참여 기능(고객 목록·세그먼트·캠페인·여정·분석)이 꺼졌습니다. 메시지를 보내는 채널은 사정이 다릅니다. SMS·음성·푸시 채널은 2024년 3분기에 AWS End User Messaging 이라는 서비스로 떨어져 나와 계속 돕니다. Pinpoint API 로 보내던 발송은 둘로 갈립니다. 푸시·OTP(일회용 비밀번호)·전화번호 검증은 모든 계정에 남고, SMS·음성·이메일 발송은 2025-05-20 전에 가입한 기존 고객만 계속 쓸 수 있습니다. 새로 시작한다면 SMS·음성은 End User Messaging 에서, 이메일은 SES(07-1편)에서 바로 보냅니다. 캠페인 기능은 클라우드 고객센터 서비스인 Amazon Connect(14-1편)의 발신 캠페인으로 옮기라고 권합니다(Amazon Pinpoint end of support).

넷 다 대안으로 가면 서비스가 해 주던 일 하나를 직접 맡게 됩니다.

3. 새 고객만 막은 다섯 — App Runner·Cloud9·Kendra·IoT FleetWise·Mainframe Modernization

유지보수 단계 서비스를 이미 쓰고 있다면 계속 써도 될까요? 공식 답은 「된다」입니다. 다섯 모두 기존 고객은 그대로 쓰고, AWS 는 보안·가용성은 지키되 새 기능을 내지 않겠다고 적었습니다. 문제는 새로 시작하는 사람입니다.

App Runner 는 소스 저장소나 컨테이너 이미지를 연결해 두면 빌드·배포·확장을 알아서 하는 웹 애플리케이션 서비스입니다. 2026-03-31 에 유지보수를 발표하고 2026-04-30 부터 새 고객을 받지 않습니다(Services in Maintenance · AWS App Runner). 기존 고객은 새 서비스를 더 만드는 것까지 계속 됩니다. AWS 가 권하는 곳은 ECS Express Mode(01-2편)입니다. 이미지 하나와 IAM 역할 둘을 주면 Fargate 위의 ECS 서비스·ALB·오토스케일링을 내 계정에 만들어 주고, Express Mode 자체에는 추가 요금이 없습니다. 소스 코드로 배포하던 서비스라면 이미지를 굽는 빌드 단계를 먼저 붙여야 합니다. 자체 도메인을 쓰고 있었다면 AWS 는 Route 53 가중치 라우팅으로 두 서비스 사이에 트래픽을 조금씩 옮기라고 안내합니다(AWS App Runner availability change).

Cloud9 은 브라우저에서 여는 IDE 입니다. 편집기 뒤에 EC2 인스턴스 같은 계산 자원이 붙어 있어 터미널과 디버거까지 브라우저에서 씁니다. 2024-07-25 에 새 고객을 막았습니다. 대안은 둘입니다. 평소 쓰는 VS Code·IntelliJ 같은 IDE 에 AWS Toolkit 플러그인을 깔아 AWS 리소스를 다루거나, 콘솔에 붙은 무료 셸인 CloudShell(01-1편)을 씁니다. 옮긴 뒤에는 Cloud9 이 만들어 둔 EC2 인스턴스를 지워야 요금이 멈춥니다(How to migrate from AWS Cloud9 to AWS IDE Toolkits or AWS CloudShell).

Kendra 는 사내 문서 저장소 여러 곳을 색인에 모아 자연어 질문으로 찾게 해 주는 지능형 검색 서비스입니다. 2026-06-30 에 유지보수로 들어갔고 2026-07-30 부터 새 고객을 받지 않습니다. AWS 가 권하는 곳은 Bedrock 의 관리형 Knowledge Base 입니다. 문서를 잘라 임베딩하는 일과 벡터 저장소는 Bedrock 이 맡습니다. 찾은 문서로 답을 지어 주는 RetrieveAndGenerate API 도 기본으로 붙습니다. 대신 기본 제공 커넥터가 Kendra 의 32개 이상에서 7개로 줄고, 검색 방식은 키워드와 의미 검색을 섞는 하이브리드 하나뿐입니다(Amazon Kendra availability change). 관리형 Knowledge Base 는 2026-11-13 기준 서울에 없어서 도쿄 같은 다른 리전에 만들어야 합니다(12-1편).

IoT FleetWise 는 차량마다 다른 프로토콜로 나오는 저수준 신호를 사람이 읽는 값으로 풀고, 어떤 데이터를 언제 올릴지 캠페인으로 정해 클라우드로 모으는 차량 데이터 수집 서비스입니다. 2026-03-31 에 유지보수를 발표하고 2026-04-30 부터 새 고객을 받지 않습니다(Services in Maintenance · AWS IoT FleetWise). 대안으로 든 것은 서비스가 아니라 Guidance for Connected Mobility on AWS 라는 구성 안내와 예제 코드라서, 차량 데이터 플랫폼을 여러 서비스로 직접 조립해야 합니다(AWS IoT FleetWise availability change).

Mainframe Modernization 은 COBOL·PL/I 로 짠 메인프레임 애플리케이션을 AWS 로 옮기는 도구와 실행 환경입니다. 두 갈래가 차례로 닫혔습니다. AWS 가 런타임을 운영해 주던 관리형 런타임은 2025-11-07 에 새 고객을 막고 자체 관리형으로 가라고 했습니다. 그 자체 관리형도 2026-06-30 에 새 고객을 막았고, 이제는 솔루션 업체가 직접 내놓는 제품과 AWS Transform 을 보라고 합니다. AWS Transform 은 옛 코드를 새 언어와 플랫폼으로 옮기는 일을 AI 에이전트로 돕는 서비스입니다. 같은 서비스의 애플리케이션 테스트 기능은 2025-10-07 에 완전 종료됐습니다(AWS Mainframe Modernization availability change).

다섯 모두 이미 쓰는 고객은 급하지 않고, 갈 곳도 정해져 있습니다. 옮길 때 잃는 것만 서비스마다 다릅니다.

4. 한마디로 접혔다고 하기 어려운 둘 — Amazon Q·Snowball

「접혔다」고 한마디로 정리되지 않는 서비스는 어떻게 읽어야 할까요? Amazon Q 는 이름 하나 아래 갈래마다 상태가 다르고, Snowball 은 끝나는 날이 페이지마다 다릅니다.

Amazon Q 라는 이름 아래에는 갈래가 여럿 있습니다. 사내 데이터에 묻고 답하는 업무용 비서 Q Business 는 2026-06-30 에 유지보수로 들어갔습니다. AWS 는 그 뒤를 잇는 제품으로 Amazon Quick 을 권합니다. Quick 은 사내 문서·업무 도구·DB 를 한곳에 이어 묻고 답하고, 대시보드와 업무 자동화까지 붙인 업무용 AI 제품입니다(Amazon Q Business availability change). 개발자용 Q Developer 는 더 잘게 갈립니다. VS Code·JetBrains·Eclipse·Visual Studio 에 까는 IDE 플러그인은 2026-04-30 에 종료 예정 목록에 올라 2027-04-30 에 지원이 끝납니다(Services in Sunset). 공지에 따르면 유료 구독도 같은 날 끝나고, 2026-05-15 부터 새 가입을 막았습니다. 대안은 AWS 의 에이전트형 개발 환경 Kiro 입니다. 플러그인에 딸린 코드 변환(자바 버전 올리기·.NET 이식)도 같이 끝나며 AWS Transform 으로 넘어갑니다. 반면 AWS 콘솔·문서 사이트·콘솔 모바일 앱·Slack 과 Teams 안의 Q Developer 는 이번 종료와 상관없이 남습니다(Amazon Q Developer end-of-support announcement).

Snowball 은 갈래가 아니라 날짜가 엇갈립니다. Snowball 은 AWS 가 보내 주는 튼튼한 저장 장치에 데이터를 담아 택배로 돌려보내는 물리 이전 서비스입니다. 인터넷으로 보내는 것보다 빠르게 대량의 데이터를 옮기려고 쓰고, 계산 최적화 구성의 장비는 현장에서 엣지 컴퓨팅 작업을 돌리는 데도 씁니다. 지금은 새 고객이 Snow 계열 장비를 주문할 수 없습니다(AWS Snowball Edge availability change). 제품 페이지는 2026-12-31 에 상업 리전의 Snowball 장비 지원을 끝낸다고 적었는데(미국 정부용 GovCloud 등 일부 리전의 진행 중 작업은 예외), 완전 종료 목록에는 Snowball Edge 가 2025-11-12 로 올라 있습니다(AWS Snowball). 대안은 온라인이면 DataSync(작업 하나가 10 Gbps 회선을 다 쓸 수 있다고 적혀 있습니다), 현장 계산이면 Outposts 입니다. 둘은 14-2편에서 봅니다. 오프라인이면 내 저장 장치를 들고 AWS 시설에 가서 올리는 Data Transfer Terminal 이나 파트너 서비스가 있습니다. 다만 Data Transfer Terminal 은 미국·유럽 몇 도시와 도쿄·시드니에만 있어서, 장치를 들고 그 도시로 가야 합니다(2026-11-13 기준 서울은 없습니다, Data Transfer Terminal FAQs).

그래서 이 둘은 내가 쓰는 갈래와 날짜를 먼저 가려야 합니다.

5. 돌아온 하나 — CodeCommit

유지보수에 들어간 서비스가 되살아나는 일도 있을까요? CodeCommit 이 그 드문 예입니다.

CodeCommit 은 AWS 가 운영하는 사설 Git 저장소입니다. 2024년 7월 AWS 는 이 서비스의 비중을 줄이겠다며 새 고객을 막았고, 같은 무렵 Cloud9·CloudSearch·S3 Select 도 유지보수 목록에 올랐습니다. 그런데 2025-11-24 에 AWS 는 CodeCommit 을 정식 서비스로 되돌리고 새 고객을 다시 받기 시작했습니다. 공지에서 AWS 는 이전 결정이 고객에게 준 혼란을 인정하고, 이전을 계획하거나 진행한 고객에게 사과했습니다. 되돌린 까닭으로는 IAM 과 맞물린 권한·VPC 엔드포인트·CloudTrail 기록·CodePipeline 과 CodeBuild 연결을 들었습니다. 규제 업종이나 개발 인프라를 전부 AWS 경계 안에 두려는 팀에게 필요하다는 의견도 받았다고 적었습니다. 요금은 그대로입니다(The Future of AWS CodeCommit).

되살아났다고 해서 판단이 달라지지는 않습니다. 08편에서 본 대로 코드와 리뷰가 이미 GitHub 에 있다면 옮길 까닭이 없습니다. CodeCommit 은 소스까지 AWS 안에 둬야 하는 사정이 있을 때 고르는 저장소입니다. 큰 파일이 많은 저장소라면 한 가지를 더 봐야 합니다. 큰 파일을 저장소 밖에 따로 두는 Git 확장인 Git LFS(Large File Storage)는 복귀 공지에서 2026년 1분기 예정이었지만, 2026-11-13 기준 공식 문서에는 출시 기록이 없습니다. 사용자 안내서는 자주 바뀌는 큰 파일은 S3 에 두라고 권합니다(AWS CodeCommit 문서 이력 · What is AWS CodeCommit?).

다만 CodeCommit 이 돌아왔다고 다른 유지보수 서비스에 새로 들어가는 것은 맞지 않습니다. 열두 서비스 가운데 되돌아온 것은 하나뿐입니다.

이럴 땐 무엇

옮겨 갈 때 자주 붙는 서비스는 CloudWatch Logs(감사 로그를 모은다)·Route 53(옛 서비스에서 새 서비스로 트래픽을 넘긴다)·IAM(Express Mode 가 쓰는 역할)이고, 엮이는 방식은 이 시리즈 뒤쪽의 조합 편에서 풉니다.

한 장 요약

AWS 는 서비스를 유지보수·종료 예정·완전 종료 세 단계로 접고, 유지보수에는 끝나는 날이 없지만 새 고객은 들어올 수 없습니다. 이미 꺼진 QLDB·App Mesh·IoT Events·Pinpoint 는 대안이 같은 모양의 서비스가 아니어서, 감사 테이블·상태 기계 코드·채널별 서비스처럼 옮기면서 일을 더 떠안습니다. 새로 시작한다면 유지보수 목록에 오른 서비스는 피하고 AWS 가 권하는 대안으로 바로 가며, CodeCommit 처럼 돌아오는 일은 예외로 둡니다.

관련 항목

수명 단계가 바뀐 이 편의 서비스

AWS App Runner · AWS Cloud9 · Amazon QLDB · AWS App Mesh · Amazon Pinpoint · AWS Snowball · Amazon Kendra · Amazon Q · AWS IoT Events · AWS Mainframe Modernization · AWS IoT FleetWise · AWS CodeCommit

접힌 서비스의 일을 넘겨받은 곳

ECS Express Mode · ECS Service Connect · VPC Lattice · AWS CloudShell · AWS Toolkit · Amazon Bedrock · Bedrock Knowledge Bases · Amazon Quick · Kiro · AWS Transform · AWS End User Messaging · Amazon SES · Amazon Connect · AWS DataSync · AWS Outposts

대안 구성에 쓰이는 부품

Aurora PostgreSQL · pgAudit · 감사 테이블 · AWS IoT Core · Amazon Kinesis Data Streams · AWS Lambda · Amazon DynamoDB · Amazon EventBridge · Route 53 가중치 라우팅

접힌 서비스가 쓰던 개념

원장 데이터베이스 · 해시 체인 · 머클 트리 · 서비스 메시 · 사이드카 패턴 · Envoy · 상태 기계 · 검색 증강 생성 · 하이브리드 검색 · Git LFS

서비스가 접히는 일을 다루는 말

AWS 서비스 수명 단계 · 유지보수 모드 · 지원 종료 · 벤더 종속 · 마이그레이션 · RSS