Amazon Bedrock 모델 수명 주기: 전환 이해

title: "Amazon Bedrock 모델 수명 주기: 전환 이해" slug: "understanding-amazon-bedrock-model-lifecycle" date: "2026-04-10" lang: "ko" source: "https://aws.amazon.com/blogs/machine-learning/understanding-amazon-bedrock-model-lifecycle/" category: "엔터프라이즈 AI" keywords:

Amazon Bedrock
모델 수명 주기
기반 모델
EOL 모델
레거시 모델
AWS AI
AI 애플리케이션 관리
모델 마이그레이션
확장 액세스
프로비저닝된 처리량
서비스 할당량
AI 개발 meta_description: "Amazon Bedrock의 모델 수명 주기(활성, 레거시, EOL 상태 포함)를 이해합니다. 모범 사례를 통해 마이그레이션을 계획하고, 전환을 관리하며, 지속적인 AI 애플리케이션 운영을 보장하는 방법을 알아보세요." image: "/images/articles/understanding-amazon-bedrock-model-lifecycle.png" image_alt: "Amazon Bedrock 모델의 세 가지 수명 주기 상태(활성, 레거시, EOL)를 보여주는 다이어그램." quality_score: 94 content_score: 93 seo_score: 95 companies:
AWS schema_type: "NewsArticle" reading_time: 4 faq:
question: "Amazon Bedrock 모델의 세 가지 주요 상태는 무엇이며, 각각 어떤 의미가 있습니까?" answer: "Amazon Bedrock 모델은 활성(Active), 레거시(Legacy), 지원 종료(EOL, End-of-Life)의 세 가지 중요한 수명 주기 상태를 거칩니다. '활성' 모델은 지속적인 유지 관리, 업데이트 및 버그 수정을 받으며, 추론, 사용자 지정(해당하는 경우) 및 할당량 증가를 위해 완벽하게 지원됩니다. 모델이 '레거시'로 전환되면, 더 새로운 버전이나 대안이 사용 가능하며, 고객은 마이그레이션을 계획하는 것이 좋습니다. 이 기간 동안 기존 사용자는 계속 사용할 수 있지만, 신규 액세스가 제한되거나 사용자 지정 기능이 제한될 수 있습니다. 'EOL' 상태는 모델이 모든 AWS 리전에서 완전히 액세스할 수 없게 됨을 의미하므로, 애플리케이션 중단을 피하기 위해 사전에 마이그레이션해야 합니다. 이러한 상태를 이해하는 것은 Amazon Bedrock에서 AI 애플리케이션을 효과적으로 관리하는 데 필수적입니다."
question: "'레거시' 상태는 Amazon Bedrock 사용자에게 어떤 영향을 미치며, 특히 '퍼블릭 확장 액세스(Public Extended Access)' 기간과 관련하여 어떤 영향을 미칩니까?" answer: "Amazon Bedrock 모델이 '레거시' 상태에 진입하면, 지원 종료(EOL) 날짜 최소 6개월 전에 사용자에게 통지가 제공되어 마이그레이션 계획을 위한 중요한 시간을 확보할 수 있습니다. 이 기간 동안 기존 고객은 일반적으로 모델을 계속 사용할 수 있지만, 신규 고객이나 비활성 계정은 액세스 제한에 직면할 수 있습니다. 2026년 2월 1일 이후 EOL 날짜를 가진 모델의 경우, '레거시' 상태에는 초기 최소 3개월의 레거시 기간 이후 최소 3개월 동안 지속되는 '퍼블릭 확장 액세스' 단계가 포함됩니다. 이 확장된 기간 동안 활성 사용자는 액세스를 유지하지만, 할당량 증가 요청은 승인되지 않을 수 있으며, 요금이 조정될 수 있습니다. 고객은 레거시 모델로부터의 원활한 전환을 위해 이러한 변경 사항에 대해 항상 통보받습니다."
question: "Amazon Bedrock 기반 모델이 지원 종료(EOL) 날짜에 도달하면 어떻게 됩니까?" answer: "지원 종료(EOL) 날짜에 도달하면, Amazon Bedrock 기반 모델은 대부분의 고객에게 모든 AWS 리전에서 완전히 액세스할 수 없게 됩니다. EOL 모델을 대상으로 하는 모든 API 요청은 실패하여, 여전히 해당 모델에 의존하는 애플리케이션은 작동하지 않게 됩니다. AWS는 애플리케이션을 자동으로 마이그레이션하지 않습니다. 고객은 EOL 날짜 이전에 대체 지원 모델을 사용하도록 애플리케이션 코드를 업데이트할 전적인 책임이 있습니다. 특정 고객과 공급자 사이에 계속 액세스하기 위한 특별한 협의가 있을 수 있지만, 이는 일반적으로 광범위한 사용자 기반에는 해당되지 않습니다. 따라서 선제적인 마이그레이션은 Amazon Bedrock에 구축된 AI 애플리케이션의 중단 없는 운영을 보장하기 위한 중요한 단계입니다."
question: "AWS는 Amazon Bedrock 모델 수명 주기 변경 사항을 사용자에게 어떻게 알립니까?" answer: "AWS는 Amazon Bedrock 모델 상태 변경, 특히 모델이 '레거시' 상태(EOL 6개월 전)로 전환될 때 고객에게 알리기 위해 다채널 통신 전략을 사용합니다. 알림은 이메일, AWS Health Dashboard 표시, Amazon Bedrock 콘솔 내 알림 형태로 전송됩니다. 모델 수명 주기 정보에 대한 프로그래밍 방식 액세스도 API를 통해 가능합니다. 이러한 중요한 업데이트를 수신하려면 고객은 루트 사용자 및 대체 연락처(운영, 보안, 결제)를 포함하여 계정 연락처 이메일 주소를 확인하고 구성해야 합니다. 또한 AWS User Notifications 콘솔을 통해 더 많은 수신자를 추가하거나 Slack 또는 이메일 배포 목록과 같은 다른 전달 채널을 구성하여 예정된 변경 사항에 대한 시기적절하고 포괄적인 인식을 보장할 수 있습니다."
question: "새로운 Amazon Bedrock 모델로 애플리케이션을 마이그레이션하기 위한 권장 전략 및 모범 사례는 무엇입니까?" answer: "새로운 Amazon Bedrock 모델로 애플리케이션을 마이그레이션하려면 선제적인 계획과 체계적인 접근 방식이 필요합니다. 모범 사례로는 모델이 '레거시' 상태에 진입하자마자 계획을 시작하는 것이 포함됩니다. 레거시 모델에 의존하는 모든 애플리케이션을 식별하고, 요청 패턴을 분석하며, 중요한 출력 동작을 이해하기 위한 '평가 단계'로 시작하십시오. 이어서 권장되는 대체 모델을 철저히 조사하고, 해당 기능, 차이점, 새로운 기능 및 리전 가용성을 평가하는 '조사 단계'를 진행하십시오. 애플리케이션 코드를 업데이트하고, 성능을 검증하며, 서비스 할당량이 새 모델로 예상되는 볼륨을 처리할 수 있는지 확인하는 것이 중요합니다. 이 체계적인 접근 방식은 중단을 최소화하면서 원활한 전환을 보장하며, 새로운 기반 모델의 향상된 기능을 활용합니다."
question: "Amazon Bedrock 모델의 확장 액세스 기간 동안 가격 책정 고려 사항이 있습니까?" answer: "예, Amazon Bedrock 모델의 확장 액세스 기간 동안 모델 공급업체가 가격을 조정할 수 있습니다. 그러나 AWS는 초기 레거시 발표 시점과 모든 후속 가격 변경이 발효되기 전에 고객에게 통지하여 투명성을 보장하고 예상치 못한 소급 인상을 방지합니다. 모델 공급업체와 직접 기존의 사설 가격 책정 계약을 맺고 있거나 프로비저닝된 처리량을 사용하는 고객은 확장 액세스 기간 동안 기존의 가격 책정 조건에 따라 계속 운영됩니다. 이 정책은 특정 재정적 협의나 전용 용량에 대한 투자를 한 고객을 보호하여, 모델이 지원 종료로 전환되더라도 예측 가능성과 안정성을 보장하도록 설계되었습니다."

AI 수명 주기 관리: Amazon Bedrock 모델 전환 탐색

인공지능의 빠른 발전은 기반 모델(FM)이 향상된 기능, 개선된 정확성 및 더 강력한 안전 기능으로 끊임없이 업데이트되고 있음을 의미합니다. Amazon Bedrock에서 AI 기반 애플리케이션을 구축하는 개발자와 기업에게 모델 수명 주기를 이해하고 관리하는 것은 지속적인 운영을 보장하고 최신 발전을 활용하는 데 가장 중요합니다. 선제적인 계획은 유익할 뿐만 아니라, 중단을 방지하고 AI 솔루션을 최전선에 유지하는 데 필수적입니다.

Amazon Bedrock은 정기적으로 새로운 FM 버전을 출시하며, 각 버전은 상당한 개선을 가져옵니다. Code Velocity 독자를 위해 맞춤화된 이 문서는 Amazon Bedrock 모델 수명 주기를 심층적으로 다루며, 다양한 상태, 새로운 확장 액세스 기능, 그리고 원활한 애플리케이션 마이그레이션을 위한 실용적인 전략을 설명합니다. 이러한 역동적인 변화를 이해함으로써 모델 전환을 자신감 있게 탐색하고 강력하며 고성능의 AI 애플리케이션을 유지할 수 있습니다.

Amazon Bedrock의 모델 수명 주기 상태 탐색

Amazon Bedrock에서 제공되는 모든 기반 모델은 활성(Active), 레거시(Legacy), 또는 지원 종료(EOL, End-of-Life)의 세 가지 명확한 수명 주기 상태 중 하나에 속합니다. 이 상태는 Amazon Bedrock 콘솔과 API 응답(예: GetFoundationModel 또는 ListFoundationModels 호출을 통해) 모두에서 확인할 수 있으며, 모델의 지원 수준, 가용성 및 예상 수명을 결정합니다. 각 상태를 이해하는 것은 효과적인 AI 애플리케이션 관리의 초석입니다.

각 상태가 의미하는 바는 다음과 같습니다.

상태	설명	주요 영향
활성(ACTIVE)	모델은 공급업체로부터 지속적인 유지 관리, 업데이트 및 버그 수정을 받습니다. 이는 현재 지원되는 FM의 세대를 나타냅니다.	API(InvokeModel, Converse)를 통한 추론, 사용자 지정(지원되는 경우), AWS Service Quotas를 통한 할당량 증가에 대한 완전한 지원.
레거시(LEGACY)	모델 공급업체가 모델을 전환했음을 알리며, 이는 결국 지원 중단을 의미합니다. 고객은 EOL 최소 6개월 전에 사전 통지를 받습니다.	기존 사용자는 계속 사용할 수 있지만, 신규 고객이나 비활성 계정의 경우 새 액세스가 제한될 수 있습니다. 새로운 프로비저닝된 처리량 생성은 불가능하며, 사용자 지정에 제한이 따를 수 있습니다. 2026년 2월 1일 이후 EOL 모델의 경우 '퍼블릭 확장 액세스' 단계가 포함됩니다.
지원 종료(EOL)	모델은 최종 단계에 도달했으며 완전히 액세스할 수 없습니다. 모든 지원이 중단되며, 더 이상 추론에 사용할 수 없습니다.	EOL 모델에 대한 API 요청은 실패합니다. EOL 날짜 이전에 고객의 선제적인 대체 모델 마이그레이션이 필요합니다. AWS에서 자동 마이그레이션은 발생하지 않습니다.

활성(Active) 모델은 지속적인 개발 및 프로덕션 워크로드의 핵심입니다. 이들은 완전히 지원되며, 모든 최신 개선 사항을 받으며, 새로운 배포에 권장되는 선택입니다.

레거시(Legacy) 상태는 계획을 위한 중요한 기간입니다. 이는 마이그레이션을 평가하고 준비하기 시작해야 한다는 명확한 신호 역할을 합니다. AWS는 고객이 레거시 모델이 EOL에 도달하기 전에 최소 6개월의 전환 계획 시간을 가질 수 있도록 보장하여, 새로운 솔루션을 테스트하고 구현할 충분한 시간을 제공합니다. 2026년 2월 1일 이후 EOL 날짜를 가진 모델의 경우, 레거시 기간 내에 **퍼블릭 확장 액세스(Public Extended Access)**라는 추가 단계가 도입됩니다. 레거시 상태에서 최소 3개월이 경과한 후, 모델은 이 확장 액세스 단계에 진입하여 활성 사용자가 EOL까지 최소 3개월 더 계속 사용할 수 있도록 합니다. 그러나 이 기간 동안 레거시 모델에 대한 할당량 증가 요청은 일반적으로 승인되지 않으므로, 이 단계에 진입하기 한참 전에 미래 용량 계획을 세우는 것이 중요합니다.

마지막으로, 지원 종료(EOL) 상태는 최종적입니다. 모델이 EOL에 도달하면 완전히 사용할 수 없게 됩니다. EOL 모델에 여전히 의존하는 애플리케이션은 즉시 실패하게 되므로, 이 날짜 이전에 마이그레이션을 완료하는 것이 절대적으로 필요합니다. AWS는 자동 마이그레이션을 제공하지 않으며, 애플리케이션 코드 업데이트에 대한 책임은 전적으로 고객에게 있습니다.

확장 액세스를 통한 전략적 마이그레이션 계획

Amazon Bedrock 모델 수명 주기의 효과적인 관리는 특히 레거시 상태 및 해당 확장 액세스 기능을 중심으로 한 전략적 마이그레이션 계획에 달려 있습니다. 구조화된 전환 타임라인(출시 후 최소 12개월 가용성 및 EOL 전 최소 6개월의 레거시 기간)은 기반 모델을 활용하는 기업에 예측 가능성을 제공하고 중단을 최소화하도록 설계되었습니다.

레거시 단계 동안, 새로운 퍼블릭 확장 액세스 기간은 활성 사용자에게 중요한 시간을 제공합니다. 이는 새로운 모델로의 점진적인 전환을 용이하게 하면서 지속적인 운영을 가능하게 합니다. 그러나 액세스는 유지되더라도, 레거시 모델의 경우 모델 단위별 새로운 프로비저닝된 처리량 생성이 불가능해지고, 확장 액세스 기간 동안 이러한 모델에 대한 할당량 증가 요청은 일반적으로 승인되지 않는다는 점에 유의하는 것이 중요합니다. 따라서 모델이 이 단계에 진입하기 훨씬 전에 용량 요구 사항을 정확하게 예측하는 것이 서비스 저하를 피하는 데 중요합니다.

가격 책정 고려 사항도 중요합니다. 모델 공급업체는 이 단계의 모델에 대한 가격을 조정할 수 있습니다. AWS는 투명성을 위해 노력하며, 예정된 가격 변경 사항은 초기 레거시 발표 시점과 변경 사항이 발효되기 전에 항상 전달되어 예상치 못한 비용 발생을 방지합니다. 기존의 사설 가격 책정 계약을 맺고 있거나 프로비저닝된 처리량을 사용하는 고객은 현재의 조건을 유지하여 기존 투자 및 계약상의 합의를 보호합니다. 레거시 상태에 대한 이러한 다층적인 접근 방식은 유연성을 제공하면서도 애플리케이션이 최신 완전 지원 모델의 혜택을 받도록 적시에 마이그레이션을 강력히 권장합니다. Bedrock에서 운영 비용과 성능을 최적화하려는 기업에게 이러한 미묘한 차이를 이해하는 것이 중요합니다. AI 비용 관리에 대한 더 많은 통찰력을 얻으려면, Amazon Bedrock 프로젝트를 통한 AI 비용 관리를 살펴보십시오.

원활한 전환 보장: 커뮤니케이션 및 모범 사례

레거시 Amazon Bedrock 모델에서 새 버전으로의 성공적인 마이그레이션은 시기적절한 커뮤니케이션과 계획 및 실행에 대한 체계적인 접근 방식에 크게 좌우됩니다. AWS는 고객이 임박한 모델 상태 변경에 대해 충분히 알 수 있도록 강력한 커뮤니케이션 프로세스를 사용합니다.

고객은 모델의 EOL 날짜 최소 6개월 전, 일반적으로 모델이 레거시 상태로 전환될 때 포괄적인 알림을 받습니다. 이러한 통신에는 지원이 중단될 모델, 중요한 날짜, 확장 액세스 가용성 및 정확한 EOL 날짜가 자세히 설명됩니다. 이러한 중요한 알림이 적절한 이해 관계자에게 도달하도록 AWS는 여러 채널을 활용합니다.

이메일 알림: 계정의 루트 사용자 이메일 및 지정된 대체 연락처(운영, 보안, 결제)로 전송됩니다.
AWS Health Dashboard: 모든 예정된 변경 사항 및 잠재적 영향에 대한 중앙 집중식 보기를 제공합니다.
Amazon Bedrock 콘솔 알림: 서비스 인터페이스 내에서 직접 알림이 제공됩니다.
프로그래밍 방식 API 액세스: 모델 수명 주기 상태를 자동 모니터링할 수 있습니다.

AWS 계정 페이지를 통해 AWS 계정 연락처 이메일 주소를 정기적으로 확인하고 구성하는 것이 필수적입니다. 또한 AWS User Notifications 콘솔을 사용하면 더 많은 수신자를 추가하거나 Slack 또는 내부 배포 목록과 같은 대체 전달 채널을 구성하여 중요한 정보가 누락되지 않도록 할 수 있습니다. health@aws.com에서 오는 이메일이 필터링되지 않도록 확인하는 것도 중요한 단계입니다.

마이그레이션 전략 및 모범 사례에 있어서는 조기 계획이 필수적입니다. 모델이 '레거시' 상태에 진입하자마자 마이그레이션 프로세스를 시작하십시오.

평가 단계: 레거시 모델에 대한 현재 의존성을 철저히 평가하십시오. 해당 모델에 의존하는 모든 애플리케이션, 워크플로 및 통합을 식별하십시오. 일반적인 요청 패턴, 성능 지표, 그리고 애플리케이션이 의존하는 특정 동작 또는 출력을 분석하십시오. 이 심층적인 이해가 마이그레이션의 기준선을 형성합니다.
조사 단계: Amazon Bedrock에서 사용 가능한 권장 대체 모델 또는 대체 FM을 조사하십시오. 해당 기능, 레거시 모델과의 차이점, 그리고 애플리케이션을 향상시킬 수 있는 새로운 기능을 이해하십시오. 지역 가용성 및 API 엔드포인트 또는 입력/출력 형식의 변경 사항에 세심한 주의를 기울이십시오.
테스트 및 검증: 전체 배포 전에 기존 데이터 및 사용 사례로 새 모델을 철저히 테스트하십시오. 평가 중에 설정된 벤치마크에 대해 성능, 정확성 및 안전성을 평가하십시오. 가능하다면 A/B 테스트를 수행하여 새 모델의 효율성을 레거시 모델과 비교하십시오.
코드 업데이트 및 통합: 새 모델을 통합하도록 애플리케이션 코드를 수정하십시오. 여기에는 API 호출, 프롬프트 엔지니어링 전략 또는 후처리 로직 업데이트가 포함될 수 있습니다. 인프라가 새 모델의 요구 사항을 처리할 수 있는지 확인하고, 서비스 할당량이 그에 따라 조정되었는지 확인하십시오.
점진적 출시 및 모니터링: 새 모델에 대한 단계별 출시 전략을 구현하십시오. 트래픽의 작은 비율 또는 중요하지 않은 애플리케이션으로 시작하여 노출을 점진적으로 늘리면서 성능, 오류율 및 사용자 피드백을 지속적으로 모니터링하십시오.

이러한 모범 사례를 준수함으로써 잠재적 중단을 최소화하고 AI 애플리케이션이 계속해서 가치를 제공하도록 보장하는 원활하고 통제된 전환을 용이하게 할 수 있습니다. AWS와 NVIDIA 간의 전략적 협력을 통해 AI 채택을 가속화하는 것과 같은 전략적 협력을 활용하는 것도 수명 주기 전반에 걸쳐 AI 채택을 가속화할 수 있습니다.

지속적인 AI 운영을 위한 선제적 관리

AI 모델의 역동적인 특성으로 인해 기반 모델 수명 주기는 개발자 환경에서 끊임없이 변화하는 요소입니다. Amazon Bedrock에서 구축하는 기업에게 이러한 전환을 이해하고 적극적으로 관리하는 것은 단순한 기술적 작업이 아니라 전략적 필수 사항입니다. 활성, 레거시 및 지원 종료 상태의 미묘한 차이를 파악하고 AWS가 제공하는 구조화된 통신 및 확장 액세스 기간을 활용함으로써 조직은 AI 애플리케이션이 탄력적이고, 고성능이며, 지속적으로 업데이트되도록 보장할 수 있습니다.

선제적인 평가, 세심한 계획, 엄격한 테스트는 성공적인 마이그레이션 전략의 기둥입니다. 이러한 모범 사례를 운영 프레임워크에 통합함으로써 위험을 완화하고 혁신을 수용하며 Amazon Bedrock에 대한 AI 투자가 중단 없이 지속적으로 비즈니스 가치를 제공하도록 보장할 수 있습니다. 빠르게 진화하는 AI 환경에서 모델 수명 주기 관리에서 앞서 나가는 것은 경쟁 우위를 유지하는 데 중요합니다.

원본 출처

https://aws.amazon.com/blogs/machine-learning/understanding-amazon-bedrock-model-lifecycle/

자주 묻는 질문

What are the three main states of an Amazon Bedrock model and what do they signify?

Amazon Bedrock models transition through three crucial lifecycle states: Active, Legacy, and End-of-Life (EOL). An 'Active' model receives continuous maintenance, updates, and bug fixes, and is fully supported for inference, customization (if applicable), and quota increases. When a model moves to 'Legacy,' it signifies that a newer version or alternative is available, and customers are advised to plan migration. During this period, existing users can continue, but new access might be restricted, and customization capabilities can be limited. The 'EOL' state means the model is completely inaccessible across all AWS Regions, requiring prior migration to avoid application disruption. Understanding these states is vital for managing AI applications effectively on Amazon Bedrock.

How does the 'Legacy' state impact Amazon Bedrock users, especially regarding the 'Public Extended Access' period?

When an Amazon Bedrock model enters the 'Legacy' state, users are given at least six months' notice before its End-of-Life (EOL) date, providing critical time for migration planning. During this period, existing customers can typically continue using the model, though new customers or inactive accounts might face access restrictions. For models with EOL dates after February 1, 2026, the 'Legacy' state includes a 'Public Extended Access' phase, lasting at least three months after an initial minimum of three months in Legacy. During this extended period, active users retain access, but quota increase requests may not be approved, and pricing might be adjusted. Customers are always notified of these changes to facilitate a smooth transition away from the legacy model.

What happens when an Amazon Bedrock foundation model reaches its End-of-Life (EOL) date?

Upon reaching its End-of-Life (EOL) date, an Amazon Bedrock foundation model becomes entirely inaccessible across all AWS Regions for most customers. Any API requests targeting an EOL model will fail, rendering applications that still rely on it non-functional. AWS does not automatically migrate applications; customers are solely responsible for updating their application code to use alternative, supported models *before* the EOL date. While special arrangements for continued access might exist between specific customers and providers, this is generally not the case for the broader user base. Proactive migration is therefore a critical step to ensure the uninterrupted operation of AI applications built on Amazon Bedrock.

How does AWS communicate changes in the Amazon Bedrock model lifecycle to its users?

AWS employs a multi-channel communication strategy to inform customers about Amazon Bedrock model state changes, particularly when a model transitions to 'Legacy' status (six months before EOL). Notifications are sent via email, displayed on the AWS Health Dashboard, and presented as alerts within the Amazon Bedrock console. Programmatic access to model lifecycle information is also available through the API. To ensure receipt of these critical updates, customers must verify and configure their account contact email addresses, including root user and alternate contacts (operations, security, billing). Additionally, the AWS User Notifications console allows for adding more recipients or delivery channels like Slack or email distribution lists, ensuring timely and comprehensive awareness of upcoming changes.

What are the recommended strategies and best practices for migrating applications to newer Amazon Bedrock models?

Migrating applications to newer Amazon Bedrock models requires proactive planning and a structured approach. Best practices include starting planning as soon as a model enters the 'Legacy' state. Begin with an 'Assessment Phase' to identify all applications dependent on the legacy model, analyze request patterns, and understand critical output behaviors. Follow this with a 'Research Phase' to thoroughly investigate the recommended replacement model, assessing its capabilities, differences, new features, and regional availability. It's crucial to update application code, validate performance, and confirm that service quotas can handle the expected volume with the new model. This systematic approach ensures a smooth transition with minimal disruption, leveraging the enhanced capabilities of newer foundation models.

Are there any pricing considerations during the extended access period for Amazon Bedrock models?

Yes, pricing may be adjusted by the model provider during the extended access period for Amazon Bedrock models. However, AWS ensures transparency by notifying customers in the initial legacy announcement and before any subsequent price changes take effect, preventing surprise retroactive increases. Customers with existing private pricing agreements directly with model providers or those utilizing provisioned throughput will continue operating under their established pricing terms throughout the extended access period. This policy is designed to protect those who have made specific financial arrangements or investments in dedicated capacity, ensuring predictability and stability despite the model's transition toward End-of-Life.