AWS
Microsoft Azure
Google Cloud
Key takeaways
1
AWS’s October 2025 announcement listed 19 services or capabilities moving to maintenance, four entering sunset, and one at end of support.
2
Maintenance does not mean immediate shutdown. Current customers can keep using affected services, but AWS does not plan to add functionality.
3
Sunset services require active migration planning because operations and support end on a published date.
4
Amazon FinSpace, Amazon Lookout for Equipment, AWS IoT Greengrass V1, and AWS Proton have an October 7, 2026 end-of-support date.
5
AWS announced GPU price reductions of up to 45% for P5, 26% for P5en, and 33% for P4d and P4de.
AWS made two changes in 2025 that deserve attention from platform, engineering, and FinOps teams. It changed the availability status of dozens of services and reduced pricing for selected NVIDIA GPU-powered Amazon EC2 instances.
These changes do not mean AWS suddenly shut down 24 services or made every GPU workload 45% cheaper.
In its October 2025 Service Availability Updates announcement, AWS listed 19 services or capabilities moving to maintenance, four entering sunset, and one that had reached end of support. Separately, AWS announced maximum price reductions of 45% for P5, 26% for P5en, and 33% for P4d and P4de instances running Amazon Linux.
For cloud teams, the practical response is to identify lifecycle exposure, prioritize workloads with real migration deadlines, and rebuild GPU cost and commitment models using current rates.
These changes do not mean AWS suddenly shut down 24 services or made every GPU workload 45% cheaper.
In its October 2025 Service Availability Updates announcement, AWS listed 19 services or capabilities moving to maintenance, four entering sunset, and one that had reached end of support. Separately, AWS announced maximum price reductions of 45% for P5, 26% for P5en, and 33% for P4d and P4de instances running Amazon Linux.
For cloud teams, the practical response is to identify lifecycle exposure, prioritize workloads with real migration deadlines, and rebuild GPU cost and commitment models using current rates.
What changed, who is affected, and what to do
| Area | What changed | Who should care | Immediate action |
|---|---|---|---|
| Maintenance services | 19 services or capabilities moved to maintenance in the October 2025 announcement | Platform and service owners | Inventory dependencies and identify alternatives |
| Sunset services | Four services received end-of-support paths | Engineering and application owners | Create dated migration projects |
| End of support | Mainframe Modernization App Testing became unavailable | Previous users | Confirm all dependencies are removed |
| GPU pricing | P4 and P5 family pricing was reduced | FinOps, AI, ML, infrastructure teams | Recalculate GPU economics |
| Commitments | Lower underlying rates change previous assumptions | FinOps and finance teams | Rebuild commitment models around stable demand |
What AWS lifecycle changes actually mean
AWS separates lifecycle changes into categories because each requires a different response.A service in maintenance is no longer available to new customers, while existing customers can continue using it. AWS says maintained services will continue to be operated and supported but will not receive new functionality.
AWS explains these conditions in its Services in Maintenance documentation and recommends that current customers evaluate available alternatives.
A service in sunset is more urgent. AWS publishes an end-of-support date and expects customers to migrate before that date. Its Services in Sunset guidance explains that sunset timelines are typically around 12 months.
A service that has reached end of support is no longer available.
The operational mistake is treating all three states the same.
Maintenance should trigger dependency documentation, alternative evaluation, and limits on new long-term use. Sunset should trigger a migration project with an owner, deadline, testing plan, and rollback strategy.
Which AWS services moved to maintenance?
AWS’s October 13, 2025 announcement identified 19 services or capabilities moving to maintenance. Existing customers can continue using them, but teams should avoid adding unnecessary long-term dependencies and identify alternatives.| Area | Key affected services | What teams should do |
|---|---|---|
| Development and modernization | CodeCatalyst, CodeGuru Reviewer, .NET Modernization Tools | Avoid new dependencies and evaluate replacements |
| Migration and mainframe | Application Discovery Service, Migration Hub, Mainframe Modernization Service | Review migration workflows and alternatives |
| Storage and data | Cloud Directory, Glacier legacy capabilities, S3 Object Lambda | Document dependencies and plan supported alternatives |
| IoT and edge | IoT SiteWise Monitor, SiteWise Edge Data Processing Pack, Snowball Edge variants | Review edge, monitoring, and transfer workflows |
| Operations | Systems Manager Change Manager, Incident Manager | Evaluate change-control and incident-response alternatives |
| Specialized services | Fraud Detector, HealthOmics Variant and Annotation Store, Thinkbox Deadline 10, WorkSpaces Web Access Client for PCoIP | Confirm ongoing need and identify a future replacement |
Which AWS services moved to maintenance?
AWS’s October 13, 2025 announcement said the following 19 services or capabilities would stop accepting new customers beginning November 7, 2025:Maintenance is not an instruction to remove a functioning workload immediately.
Instead, give the service an accountable owner, document where it is used, identify the preferred replacement, and review that decision periodically.
Because AWS can change a service’s lifecycle status after an initial announcement, teams should confirm the latest service-specific documentation before making migration or investment decisions.
Four services need migration before October 7, 2026
The four services AWS placed on sunset paths in its October 2025 announcement require a stronger response.Amazon FinSpace
Amazon FinSpace support ends October 7, 2026.AWS’s Amazon FinSpace end-of-support guide recommends reviewing Dataset Browser and Managed kdb Insights dependencies and transitioning required workflows to suitable AWS alternatives.
Inventory environments, datasets, notebooks, integrations, and Managed kdb resources. Export required data and validate replacement workflows before production cutover.
Amazon Lookout for Equipment
Amazon Lookout for Equipment also reaches end of support on October 7, 2026.In its Lookout for Equipment transition guidance, AWS identifies AWS IoT SiteWise and its anomaly-detection capabilities as an alternative for relevant predictive-maintenance use cases.
Inventory current models, integrations, inference workflows, and alerting dependencies. Compare outputs from the replacement system before shutting down the existing workflow.
AWS IoT Greengrass V1
AWS will end support for Greengrass V1 on October 7, 2026.The official Greengrass V1 to V2 migration guide tells existing customers to move workloads to AWS IoT Greengrass V2.
Identify every V1 core device, deployment, Lambda function, connector, and local resource dependency. Test V2 device behavior and fleet deployment before completing the cutover.
AWS Proton
AWS Proton support ends October 7, 2026.AWS’s Proton deprecation and migration guide notes that deployed infrastructure remains intact, but customers will lose access to AWS Proton itself after end of support.
Inventory environments, service templates, component templates, pipelines, and deployed resources. Validate that your selected CI/CD and infrastructure-management workflow can operate independently of Proton.
For all four services, discovery should cover every AWS account, Region, application, data dependency, automation workflow, and infrastructure-as-code repository.
Use a lifecycle decision matrix
A simple decision model keeps maintenance notices from becoming unnecessary emergencies while preventing sunset migrations from starting too late.| Lifecycle state | Decision | Evidence needed | Owner action |
|---|---|---|---|
| Active | Continue normally | Current architecture record | Monitor lifecycle changes |
| Maintenance | Continue and monitor | Dependency map and alternative | Avoid unnecessary expansion |
| Sunset | Start migration | Migration, testing, and rollback plan | Assign deadline and owner |
| End of support | Validate completion | Proof dependencies are removed | Close migration and clean up access |
For maintenance services, reassess the accepted risk at least twice a year.
For sunset services, work backward from the published end-of-support date and leave time for production testing, security review, rollback, and unexpected migration issues.
According to the official AWS GPU pricing announcement, new On-Demand pricing applied beginning June 1, 2025, while Savings Plan purchases reflected the changes after June 4.
AWS published the following maximum reductions:
For sunset services, work backward from the published end-of-support date and leave time for production testing, security review, rollback, and unexpected migration issues.
What the 2025 GPU price cuts actually mean
AWS announced NVIDIA GPU pricing changes on June 5, 2025.According to the official AWS GPU pricing announcement, new On-Demand pricing applied beginning June 1, 2025, while Savings Plan purchases reflected the changes after June 4.
AWS published the following maximum reductions:
P5: up to 45%
P5en: up to 26%
P4d and P4de: up to 33%
These maximum reductions apply to Amazon Linux. AWS states that reductions for other operating systems are slightly smaller.
That qualification matters.
A team should not apply 45% to its entire GPU bill and treat the result as its new forecast. Actual economics depend on the instance family, Region, operating system, purchasing model, payment option, workload profile, and current AWS pricing.
AWS later introduced one-year EC2 Instance Savings Plans for P5 and P5en in June 2025, which is another reason teams should model costs using current purchasing options rather than relying only on the original announcement.
Capture instance family, Region, operating system, hourly consumption, On-Demand spend, existing commitment coverage, and utilization.
This prevents the published maximum reduction from being applied to workloads that have different pricing conditions.
Separate stable production usage from experiments, temporary training jobs, launches, seasonal inference traffic, and capacity likely to move to newer accelerators.
AWS’s current Savings Plans documentation confirms that Savings Plans exchange lower rates for a specified hourly commitment lasting one or three years.
Also test what happens if the application changes instance family, Region, model architecture, or accelerator generation.
The cheapest theoretical hourly rate is not automatically the best financial decision.
AWS currently states that EC2 Instance Savings Plans can provide savings of up to 72% compared with On-Demand pricing, while offering less flexibility than Compute Savings Plans. The exact savings depend on the workload and plan configuration.
The important distinction is between rate savings and commitment risk.
A lower GPU rate can make a workload cheaper today without guaranteeing that the workload will still consume the same amount of compute one or three years from now.
Be especially conservative when a workload is being right-sized, migrating between GPU generations, moving between architectures, experiencing volatile demand, or still proving its long-term business value.
Commit around a defensible baseline rather than a temporary peak.
Your engineering and platform teams still need to identify maintained services, migrate sunset products, right-size infrastructure, and determine which workloads should exist long term.
We fit at the commitment layer after that work establishes a reasonably stable usage baseline.
Through our Flex Insured Commitment Program, we analyze eligible usage and manage approved Flex Commitments around actual consumption patterns. This is designed to help teams capture commitment-based savings while reducing exposure to demand changes.
Flex Insured Commitments provide cashback protection, helping teams secure the ~57% savings of a 3 year commitment with none of the commitment.
The result is a managed Savings Plans strategy that combines AWS commitment discounts with automation, flexibility, and protection as cloud environments evolve.
Our fee is based on realized savings rather than a separate platform fee, as explained in our pricing model.
The detailed coverage rules are available in our Flex Commitment eligibility guidance, while our cashback guidance explains when protection may apply.
AWS still controls its underlying commitment products, pricing, eligibility rules, and billing. We manage the optimization and protection layer for eligible Flex Commitments.
Pricing and lifecycle information is time-sensitive. AWS can change product availability, purchasing options, pricing, and migration guidance after publication. Before making a production migration or financial commitment, verify the applicable service page, Region, operating system, term, payment option, and current AWS rate.
That qualification matters.
A team should not apply 45% to its entire GPU bill and treat the result as its new forecast. Actual economics depend on the instance family, Region, operating system, purchasing model, payment option, workload profile, and current AWS pricing.
AWS later introduced one-year EC2 Instance Savings Plans for P5 and P5en in June 2025, which is another reason teams should model costs using current purchasing options rather than relying only on the original announcement.
How to reprice P4 and P5 GPU workloads
Do not begin by choosing a Savings Plan term. Begin with workload evidence.1. Export current GPU usage
Pull P4d, P4de, P5, and P5en usage from Cost Explorer, your Cost and Usage Report, or your FinOps platform.Capture instance family, Region, operating system, hourly consumption, On-Demand spend, existing commitment coverage, and utilization.
2. Segment the workload correctly
Separate usage by Region, operating system, and GPU family.This prevents the published maximum reduction from being applied to workloads that have different pricing conditions.
3. Find the stable demand floor
Determine the amount of GPU consumption that is genuinely predictable.Separate stable production usage from experiments, temporary training jobs, launches, seasonal inference traffic, and capacity likely to move to newer accelerators.
4. Compare purchasing options
Evaluate On-Demand pricing against the relevant EC2 Instance Savings Plans, Compute Savings Plans, Capacity Blocks, and architecture alternatives.AWS’s current Savings Plans documentation confirms that Savings Plans exchange lower rates for a specified hourly commitment lasting one or three years.
5. Model downside scenarios
Run the model again assuming usage falls by 10%, 25%, or 40%.Also test what happens if the application changes instance family, Region, model architecture, or accelerator generation.
The cheapest theoretical hourly rate is not automatically the best financial decision.
Lower GPU pricing does not eliminate commitment risk
AWS Savings Plans can materially reduce compute costs, but the discounted rate comes with an hourly spending commitment.AWS currently states that EC2 Instance Savings Plans can provide savings of up to 72% compared with On-Demand pricing, while offering less flexibility than Compute Savings Plans. The exact savings depend on the workload and plan configuration.
The important distinction is between rate savings and commitment risk.
A lower GPU rate can make a workload cheaper today without guaranteeing that the workload will still consume the same amount of compute one or three years from now.
Be especially conservative when a workload is being right-sized, migrating between GPU generations, moving between architectures, experiencing volatile demand, or still proving its long-term business value.
Commit around a defensible baseline rather than a temporary peak.
Where Usage.ai Adds Value
Lifecycle management and commitment management solve different problems.Your engineering and platform teams still need to identify maintained services, migrate sunset products, right-size infrastructure, and determine which workloads should exist long term.
We fit at the commitment layer after that work establishes a reasonably stable usage baseline.
Through our Flex Insured Commitment Program, we analyze eligible usage and manage approved Flex Commitments around actual consumption patterns. This is designed to help teams capture commitment-based savings while reducing exposure to demand changes.
Flex Insured Commitments provide cashback protection, helping teams secure the ~57% savings of a 3 year commitment with none of the commitment.
The result is a managed Savings Plans strategy that combines AWS commitment discounts with automation, flexibility, and protection as cloud environments evolve.
Our fee is based on realized savings rather than a separate platform fee, as explained in our pricing model.
The detailed coverage rules are available in our Flex Commitment eligibility guidance, while our cashback guidance explains when protection may apply.
AWS still controls its underlying commitment products, pricing, eligibility rules, and billing. We manage the optimization and protection layer for eligible Flex Commitments.
Sources and methodology
This guide is based primarily on AWS’s October 13, 2025 Service Availability Updates announcement, AWS’s maintenance and sunset lifecycle documentation, the June 5, 2025 NVIDIA GPU pricing announcement, and the current migration documentation for FinSpace, Lookout for Equipment, Greengrass V1, and Proton.Pricing and lifecycle information is time-sensitive. AWS can change product availability, purchasing options, pricing, and migration guidance after publication. Before making a production migration or financial commitment, verify the applicable service page, Region, operating system, term, payment option, and current AWS rate.
Frequently asked questions
Is AWS shutting down all 24 services from the October 2025 announcement?
No. AWS’s October announcement listed 19 services or capabilities moving to maintenance, four entering sunset, and AWS Mainframe Modernization App Testing as having reached end of support. Maintenance services remained usable by current customers.
Can existing customers continue using AWS services in maintenance?
Yes. AWS says existing customers can continue using maintained services, but new customers cannot onboard and AWS does not plan to add functionality. Existing users should identify alternatives and avoid unnecessary new long-term dependency.
Which AWS services need migration before October 7, 2026?
Amazon FinSpace, Amazon Lookout for Equipment, AWS IoT Greengrass V1, and AWS Proton are the four sunset services identified in the October 2025 announcement. Their current AWS guidance uses October 7, 2026 as the end-of-support date.
Did every AWS P4 and P5 GPU become 45% cheaper?
No. AWS announced maximum reductions of up to 45% for P5, 26% for P5en, and 33% for P4d and P4de. Those percentages apply to Amazon Linux, and AWS says reductions for other operating systems are slightly smaller.
What should FinOps teams do first?
Inventory lifecycle exposure and GPU usage at the same time. Create migration plans for sunset dependencies, document alternatives for maintained services, and recalculate GPU economics using current rates and a realistic stable-demand baseline before increasing commitment coverage.
Share
Facebook
X
LinkedIn
Reddit
