Summary:
- AWS EC2 pricing underwent significant changes in 2025 and 2026, including GPU On-Demand price cuts of up to 45% and Capacity Block price increases averaging 15%, fundamentally reshaping cost optimization strategies.
- The five core EC2 pricing models (On-Demand, Savings Plans, Reserved Instances, Spot Instances, and Capacity Blocks for ML) each serve distinct workload patterns, with selection criteria depending on commitment flexibility, usage predictability, and interruption tolerance.
- Hidden costs including EBS volumes, operating system surcharges, elastic IP charges, and data transfer fees can inflate EC2 bills by 20-40% beyond base compute pricing if not proactively managed.
- A strategic combination of pricing models, such as Savings Plans for baseline capacity plus Spot Instances for burst workloads, typically yields 50-70% cost reduction compared to pure On-Demand usage.
If you provisioned a GPU-accelerated EC2 instance in May 2025 and checked your bill in February 2026, you might notice a confusing pattern. Your On-Demand P5 instances cost significantly less, yet your Capacity Block reservations for the same hardware jumped by 15%. This pricing divergence reflects AWS’s aggressive recalibration of EC2 pricing models, a shift that rewards engineers who understand the mechanics behind each option.
AWS EC2 pricing has never been a single number on a spreadsheet. It is a matrix of commitment levels, instance families, operating systems, and regional multipliers that determines whether your cloud infrastructure becomes a competitive advantage or a budget drain. This guide dissects each EC2 pricing plan with the technical depth required to architect cost-efficient systems while preparing you for the nuanced questions that surface in senior engineering interviews.
What changed in EC2 pricing for 2025 and 2026
AWS announced two watershed pricing adjustments that every cloud architect must internalize. In June 2025, On-Demand pricing for GPU-accelerated instances dropped dramatically. P4d instances saw reductions up to 33%, and P5 family instances (powered by NVIDIA H100 GPUs) dropped approximately 45%. This move democratized access to high-performance machine learning infrastructure that previously required enterprise-scale budgets.
The January 2026 adjustment introduced a counterbalancing force. Capacity Blocks for ML pricing increased by an average of 15% across GPU instance types, reflecting the scarcity premium AWS now charges for guaranteed GPU availability.
These changes create a strategic inflection point. Organizations running sustained ML training workloads now face a genuine decision matrix between cheaper On-Demand rates with no availability guarantees versus less expensive Capacity Blocks that ensure hardware access during peak demand periods. The free tier also evolved after July 2025, with AWS redesigning the free tier into a 6-month, credit-based “Free Plan” worth up to $200, and tightening restrictions on associated EBS storage and data transfer allowances. Understanding these shifts provides the foundation for evaluating each pricing model that follows.
On-Demand pricing mechanics
On-Demand instances represent the baseline pricing model where you pay for compute capacity by the second (with a 60-second minimum) without any upfront commitment. This model suits unpredictable workloads, development environments, and applications where the cost of over-provisioning Reserved Instances exceeds the premium paid for flexibility. AWS bills On-Demand usage based on three primary factors: the instance type (determining vCPU, memory, and accelerator configuration), the operating system, and the deployment region.
Per-second billing and operating system surcharges
The per-second billing granularity, introduced years ago but still misunderstood, applies to Linux, Windows, and Ubuntu instances. Commercial Linux distributions like Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES) maintain hourly billing minimums with per-second billing thereafter. Operating system fees add a fixed surcharge per instance-hour that compounds significantly at scale:
- Amazon Linux and Ubuntu: No additional OS fee beyond base instance pricing
- Windows Server: Adds $0.046 to $0.192 per hour depending on instance size
- RHEL: Adds $0.06 to $0.13 per hour with hourly billing minimum
- SLES: Adds $0.047 to $0.34 per hour with hourly billing minimum
For a fleet of 50 m6i.xlarge instances running Windows Server instead of Amazon Linux, the OS surcharge alone adds approximately $3,500 monthly. Senior engineers evaluating total cost of ownership must factor these fees into architecture decisions, particularly when containerization strategies could consolidate workloads onto fewer, larger Linux instances. The regional pricing variation discussed next further complicates these calculations.
Savings Plans versus Reserved Instances
Both Savings Plans and Reserved Instances offer significant discounts (up to 72%) compared to On-Demand pricing in exchange for commitment. They differ fundamentally in flexibility and application scope. Reserved Instances lock you into a specific instance type, operating system, tenancy, and region for a one or three-year term. Savings Plans instead commit you to a consistent hourly spend amount (measured in dollars per hour) that automatically applies to any eligible usage across instance families, regions, and even compute services.
Structural differences that matter
The decision between these models hinges on workload predictability and organizational agility requirements. Consider the following comparison across five critical dimensions:
| Dimension | Savings Plans | Reserved Instances |
|---|---|---|
| Commitment unit | Dollars per hour | Specific instance configuration |
| Flexibility | Applies across instance families, sizes, OS, tenancy, and regions | Locked to specific attributes (some convertible options available) |
| Maximum discount | Up to 72% (Compute Savings Plans) | Up to 72% (Standard 3-year all upfront) |
| Service scope | EC2, Fargate, Lambda (Compute Savings Plans) | EC2 only |
| Modification options | Cannot modify commitment amount | Convertible RIs allow attribute changes |
EC2 Instance Savings Plans offer slightly deeper discounts than Compute Savings Plans but restrict flexibility to a single instance family within a region. For organizations with stable, well-understood workloads running specific instance types, Reserved Instances may yield marginally better economics. Most engineering teams benefit from the operational simplicity of Savings Plans, which eliminate the capacity planning burden of matching reservations to actual usage patterns.
Spot Instances for interruptible workloads
Spot Instances provide access to spare EC2 capacity at discounts reaching 90% compared to On-Demand pricing. AWS can reclaim these instances with a two-minute warning when capacity demand increases. This model transforms cost optimization from a procurement exercise into an architectural discipline. Workloads must be designed for graceful interruption, checkpoint recovery, and distributed execution across multiple instance types and Availability Zones.
Spot pricing dynamics and best practices
Unlike the auction-based model AWS originally used, Spot pricing now fluctuates based on long-term supply and demand trends rather than real-time bidding. Prices remain stable for extended periods, making Spot viable for production workloads that tolerate interruption. Effective Spot strategies incorporate several architectural patterns:
- Instance diversification: Configure Spot Fleet or EC2 Auto Scaling to request capacity across 10-15 instance types with similar vCPU and memory ratios, reducing interruption probability
- Availability Zone spreading: Distribute requests across all AZs in a region since Spot capacity and pricing vary independently per AZ
- Checkpointing: Implement application-level state persistence at intervals shorter than the two-minute interruption notice
- Hybrid allocation: Combine Spot with On-Demand or Savings Plan capacity to maintain minimum baseline availability
Batch processing, CI/CD pipelines, stateless web tiers behind load balancers, and distributed training jobs represent ideal Spot candidates. Stateful databases, real-time trading systems, and single-instance applications without failover mechanisms should avoid Spot entirely. The capacity reservation model discussed next addresses scenarios requiring guaranteed availability without On-Demand pricing.
Capacity Blocks for ML workloads
Capacity Blocks represent AWS’s response to GPU scarcity in the machine learning infrastructure market. This model allows you to reserve GPU-accelerated instances (P5, P5e, P5en, P4d, Trn1, Trn2 families) for defined time blocks ranging from one day to six months, guaranteeing availability for scheduled training jobs or inference deployments. Unlike Reserved Instances, Capacity Blocks do not require one or three-year commitments, offering flexibility for project-based ML initiatives.
Post-2026 pricing landscape for GPU instances
The January 2026 price increases significantly altered the economics of Capacity Blocks. The following table illustrates regional pricing variations for P5 instances (8x NVIDIA H100 GPUs) comparing On-Demand rates after the June 2025 cuts against Capacity Block rates after the January 2026 increases:
| Region | P5.48xlarge On-Demand (per hour) | P5.48xlarge Capacity Block (per hour) | Capacity Block difference |
|---|---|---|---|
| US East (N. Virginia) | $55.04 | $31.46 | ~43% |
| US West (Oregon) | $55.04 | $31.46 | ~43% |
| EU (Frankfurt) | $63.30 | $31.46 | ~50% |
| Asia Pacific (Tokyo) | $68.99 | $31.46 | ~54% |
The premium for guaranteed GPU availability now ranges from 25% to 40% depending on region, reflecting both infrastructure costs and demand intensity. Organizations must evaluate whether their ML workloads justify this premium based on training job criticality, deadline sensitivity, and the operational cost of failed capacity acquisition. For exploratory research or flexible timelines, On-Demand GPU instances post-price-cut often provide better economics despite availability uncertainty.
Hidden costs that inflate EC2 bills
Base instance pricing represents only one component of total EC2 expenditure. Several auxiliary charges accumulate silently and can inflate monthly bills by 20-40% beyond compute costs alone. Senior engineers must architect systems with awareness of these cost vectors to avoid budget surprises and optimize holistically.
EBS volumes and storage pricing
Every EC2 instance requires root storage, typically provisioned as Elastic Block Store (EBS) volumes. The default gp3 volume type charges $0.08 per GB-month plus $0.005 per provisioned IOPS beyond the 3,000 baseline and $0.04 per provisioned MB/s beyond the 125 MB/s baseline. A seemingly modest 500 GB gp3 volume with 6,000 IOPS and 250 MB/s throughput costs approximately $60 monthly, independent of instance runtime. Orphaned EBS volumes from terminated instances continue billing until explicitly deleted.
Data transfer and networking fees
Data transfer pricing follows an asymmetric model that penalizes egress while allowing free ingress:
- Data transfer in: Free from the internet to EC2
- Data transfer out: First 100 GB free monthly, then $0.09 per GB (decreasing at higher tiers)
- Inter-AZ transfer: $0.01 per GB in each direction
- Inter-region transfer: $0.02 per GB (varies by region pair)
Applications serving large media files, distributing ML model artifacts, or replicating data across regions can incur transfer costs exceeding compute costs. Elastic IP addresses also generate charges of $0.005 per hour when allocated but not attached to a running instance. This is a common oversight in development environments with stopped instances.
Cost optimization strategies for mixed workloads
Effective EC2 cost management combines multiple pricing models into a layered strategy that matches commitment levels to workload characteristics. The optimal approach for most organizations follows a three-tier model that balances discount depth against operational flexibility.
The foundation layer uses Savings Plans or Reserved Instances to cover predictable baseline capacity, typically representing 60-70% of steady-state compute usage. This layer captures the deepest discounts for workloads with consistent, well-understood resource requirements.
The flexibility layer addresses variable demand using On-Demand instances for unpredictable spikes and Spot Instances for fault-tolerant batch processing. This layer accepts higher per-hour rates in exchange for the ability to scale without commitment penalties.
The specialized layer reserves Capacity Blocks for time-sensitive ML training jobs requiring guaranteed GPU access, accepting the availability premium for deadline-critical workloads.
Implementing this strategy requires robust monitoring through AWS Cost Explorer and AWS Compute Optimizer, which analyze historical usage patterns to recommend rightsizing opportunities and optimal Savings Plan commitment levels. The AWS Pricing Calculator enables scenario modeling before committing to reservations, while Cost and Usage Reports provide the granular data necessary for chargeback and cost allocation across teams.
Conclusion
AWS EC2 pricing demands architectural thinking rather than simple rate comparison. The 2025-2026 pricing shifts, particularly the GPU On-Demand reductions and Capacity Block increases, reward engineers who understand when guaranteed availability justifies premium pricing versus when flexible models provide better economics.
Mastering the trade-offs between Savings Plans and Reserved Instances, recognizing when Spot Instances transform cost structures without compromising reliability, and accounting for hidden costs in EBS, data transfer, and operating system fees separates competent cloud practitioners from those who treat infrastructure as a commodity.
The trajectory of EC2 pricing points toward increasing specialization, with distinct models optimized for general compute, GPU-accelerated ML, and edge deployments. Engineers who build cost awareness into their architectural decision-making process, rather than treating it as a finance team concern, will design systems that scale economically alongside their technical capabilities. Your next infrastructure decision should start with workload characterization that maps directly to the pricing model delivering optimal value.
