Amazon EC2 Pricing Explained: Complete Guide to AWS Costs

If you've ever been surprised by your EC2 bill, you're not alone. AWS EC2 pricing involves four distinct pricing models, over 750 instance types across seven families, and hidden costs that can add 30-50% to what you expected.

Here's the core problem: AWS documentation explains what each pricing model is, but nobody shows you what your actual bill will look like. That's the gap I'm filling in this guide.

You'll learn exactly how EC2 pricing works, see a complete real-world cost calculation (something no competitor provides), and walk away with a decision framework for choosing the most cost-effective option for your workload. I'll also cover the hidden costs that catch most teams off guard and the optimization strategies that can cut your EC2 spend significantly.

If you want to estimate costs for your specific setup, try the EC2 Pricing Calculator after reading this guide.

How EC2 Pricing Works: The Fundamentals

EC2 pricing isn't a fixed monthly fee. You pay for compute time consumed, measured in instance-hours or instance-seconds depending on your operating system. This consumption-based model means your bill fluctuates based on actual usage, which can be both a blessing and a challenge.

AWS offers four primary pricing models, each with different tradeoffs between cost savings and flexibility. Understanding these models is foundational to optimizing your EC2 spend.

The Four Pricing Models at a Glance

Here's a quick comparison to orient you before we dive deeper:

The key insight here is that higher discounts require less flexibility or commitment. Spot Instances offer the deepest discounts but can be interrupted with only two minutes notice. Savings Plans provide substantial savings with more predictability. On-Demand gives you complete control but at the highest price point.

Per-Second Billing Explained

Since late 2017, AWS has billed EC2 instances by the second (with a 60-second minimum) for most operating systems. This seemingly small change has significant implications for cost optimization.

Per-second billing means you don't pay for unused compute time beyond the first minute. Running an instance for 3 minutes and 15 seconds? You pay for exactly 195 seconds, not 4 full minutes. This makes quick batch jobs, CI/CD runners, and auto-scaling much more cost-efficient than the old per-hour model.

Now let's examine each pricing model in detail to understand when each makes sense.

EC2 Pricing Models Deep Dive

Choosing the right pricing model can mean the difference between paying full price and saving up to 90%. But the "best" model depends entirely on your workload characteristics. Let me break down each option so you can make an informed decision.

Before diving into details, here's a quick decision guide:

On-Demand Instances: Pay-As-You-Go Flexibility

On-Demand is the baseline pricing model. No commitments, no upfront payments, no risk of interruption. You launch an instance, use it as long as you need, and pay the posted hourly rate.

When On-Demand makes sense:

• Short-term workloads that can't be predicted in advance
• Sandbox and development environments with irregular usage
• Applications that cannot tolerate any interruption
• Prototyping and testing before committing to reserved capacity
• Burst capacity when Spot isn't available

The trade-off is simple: maximum flexibility comes at maximum cost. For steady-state workloads running 24/7, On-Demand pricing leaves significant money on the table.

Here's a practical guideline: if you're running workloads consistently for more than 1-2 months, you should be looking at commitment-based options.

Savings Plans: Up to 72% Off with Commitment

Savings Plans are AWS's newer commitment model, launched in 2019. They've largely replaced Reserved Instances as the recommended approach for most teams. Instead of committing to specific instance configurations, you commit to a certain dollar amount of compute usage per hour.

Compute Savings Plans (up to 66% discount):

• Most flexible option available
• Apply to any EC2 instance family, size, region, operating system, or tenancy
• Also cover AWS Fargate and Lambda usage
• Automatically apply to your highest-cost eligible usage first

EC2 Instance Savings Plans (up to 72% discount):

• Deeper discount than Compute Savings Plans
• Require commitment to a specific instance family in a chosen region
• Still flexible on size, OS, and tenancy within that family

Payment options affect your discount level:

• No Upfront: Pay nothing upfront, get discounted hourly rates
• Partial Upfront: Pay some upfront, get better hourly rates
• All Upfront: Pay everything upfront for the maximum discount

Application priority is important to understand: Savings Plans are applied automatically after Reserved Instances. Compute Savings Plans apply before EC2 Instance Savings Plans. AWS optimizes to give you the best savings automatically.

Critical note: Savings Plans cannot be cancelled during the 1 or 3-year term. If your usage drops or your architecture changes dramatically, you're still on the hook for that commitment. Model your usage carefully before purchasing.

Reserved Instances: The Legacy Commitment Option

Reserved Instances (RIs) predate Savings Plans and offer similar discounts (up to 72%). AWS now recommends Savings Plans for most new commitments because they offer comparable savings with more flexibility.

Standard Reserved Instances (up to 72% discount):

• Locked to specific instance type, region, and tenancy
• Can be modified within the same instance family (e.g., change AZ or size)
• Can be sold in the Reserved Instance Marketplace if no longer needed

Convertible Reserved Instances (up to 66% discount):

• Lower discount than Standard RIs
• Can be exchanged for different configurations (instance family, OS, tenancy)
• Cannot be sold in the Marketplace
• Useful when you know you need compute but aren't sure exactly what

When RIs still make sense:

• You have existing RI investments and want to maintain consistency
• You're absolutely certain about specific instance families for 1-3 years
• You want the option to sell unused capacity in the Marketplace (Standard only)

For most new commitments, I'd recommend starting with Compute Savings Plans. You get similar savings with significantly more flexibility to adapt as your architecture evolves.

Spot Instances: Up to 90% Savings for Flexible Workloads

Spot Instances tap into AWS's spare capacity at discounts of up to 90% compared to On-Demand. The catch? AWS can reclaim them with only two minutes notice when that capacity is needed elsewhere.

Interruption behavior options:

• Terminate (default): Instance is shut down and deleted
• Stop: Instance is stopped (EBS-backed only)
• Hibernate: Instance state is saved to EBS for faster restart

Billing rules favor you when AWS interrupts:

• If you stop or terminate a Spot Instance: You pay for seconds used
• If AWS interrupts your Spot Instance in the first hour: No charge
• If AWS interrupts after the first hour: You pay only for seconds used

Recommended allocation strategy: Use price-capacity-optimized when requesting Spot capacity through EC2 Fleet or Spot Fleet. This strategy identifies pools with the highest capacity availability and requests from the lowest-priced among them, optimizing for both cost and availability.

Best use cases for Spot:

• Batch processing and data analysis
• CI/CD build and test environments
• Containerized microservices with graceful handling
• Stateless web servers behind load balancers
• Machine learning training (with checkpointing)
• High-performance computing workloads

Spot isn't for every workload, but for fault-tolerant applications, it's effectively free money. The key is designing your application to handle interruptions gracefully.

Beyond the pricing model you choose, several other factors affect your EC2 bill.

What Determines Your EC2 Cost

Your EC2 bill isn't just determined by which pricing model you choose. Multiple factors compound to determine your final cost. Understanding these dimensions helps you make informed decisions about instance selection and architecture.

Instance Type and Size

The instance type you choose directly impacts price. Instances are priced based on their resource allocation:

• vCPUs: More cores = higher cost
• Memory: More RAM = higher cost
• Storage: Instance store capacity affects pricing
• Networking: Higher network performance costs more

Within an instance family, prices scale roughly linearly with size. A m6i.2xlarge costs approximately twice what a m6i.xlarge costs (with some minor variations).

The practical implication: Right-sizing isn't just about performance, it's about cost. An over-provisioned instance wastes money every hour it runs.

Operating System Licensing

Your operating system choice affects pricing significantly:

• Amazon Linux / Ubuntu: Lowest cost (no licensing fee)
• Windows Server: Includes OS licensing in the price
• RHEL: Per-vCPU-hour licensing model (changed July 1, 2024)
• SLES: Includes distribution licensing

For workloads that don't require Windows-specific features, running Linux can reduce your instance costs meaningfully. The difference compounds over time and scale.

AWS Region Selection

EC2 pricing varies by AWS region. Generally, US regions (particularly us-east-1) offer lower prices than regions in Europe, Asia, or South America. However, region selection involves tradeoffs:

• Latency: Users should be close to compute for responsive applications
• Compliance: Data residency requirements may mandate specific regions
• Service availability: Not all instance types are available in all regions

For workloads where latency and compliance aren't critical constraints, choosing a cost-effective region can provide meaningful savings.

Tenancy Options

EC2 offers three tenancy models with different cost implications:

• Shared tenancy (default): Standard pricing, instances share physical hosts
• Dedicated Instances: Additional $2/hour fee per region with active Dedicated Instances
• Dedicated Hosts: Separate hourly pricing, you control the entire physical server

Most workloads run fine on shared tenancy. Dedicated options exist for compliance requirements (like certain financial regulations), licensing constraints (like some Oracle licenses), or isolation requirements.

Beyond these obvious factors, several hidden costs can significantly inflate your EC2 bill.

Hidden Costs That Inflate Your EC2 Bill

This is where most teams get caught off guard. You estimate your EC2 costs based on instance pricing, deploy your workloads, and then discover your actual bill is 30-50% higher than expected. The culprit? Associated services and features that aren't included in the headline instance price.

Let me walk you through the most common hidden costs so you can budget accurately.

EBS Storage Volumes

EC2 instances need storage, and EBS volumes are billed separately from compute. Your EBS costs depend on:

• Volume type: gp3 (general purpose), io2 (provisioned IOPS), st1 (throughput), etc.
• Provisioned capacity: You pay for allocated storage, not just what you use
• Provisioned IOPS: For io1/io2 volumes, IOPS are charged separately
• Provisioned throughput: For gp3, throughput above baseline is extra

A typical production setup might have 100-500 GB of EBS per instance. This adds up quickly across a fleet. Use the EBS Pricing Calculator to estimate your storage costs accurately.

Data Transfer Charges

Data transfer is often the most surprising cost component:

• Data IN to EC2 from internet: Free
• Data OUT to internet: 100 GB/month free, then tiered pricing per GB
• Data between AZs: Charged in both directions
• Data between regions: Charged per GB

That "100 GB free" sounds generous until you're running a moderately popular web application. A typical 3-tier app serving images and content can easily push hundreds of gigabytes monthly.

Cost reduction strategies:

• Use CloudFront for static content delivery
• Implement VPC endpoints for AWS service traffic
• Minimize cross-AZ traffic where possible
• Monitor data transfer with VPC Flow Logs

Elastic IP Addresses

Here's one that catches many teams: all Elastic IP addresses are now charged, whether in use or idle. AWS made this change to encourage IPv4 address conservation.

If you have Elastic IPs allocated but not attached to running instances, you're paying for nothing. Audit your EIPs regularly and release any that aren't needed. You can clean up unused Elastic IPs across all regions to eliminate this waste.

T-Instance CPU Credits (Unlimited Mode)

T-series instances (T2, T3, T4g) are burstable, meaning they have a baseline CPU performance with the ability to burst higher when needed. In Unlimited mode (now the default for T3 and T4g), instances can burst beyond their accumulated credits, but you pay for those extra credits.

The credit costs add up:

• T4g: $0.04 per vCPU-hour for Linux
• T2/T3: $0.05 per vCPU-hour for Linux
• T2/T3 Windows: $0.096 per vCPU-hour

If your T-instance consistently uses more than its baseline, you might be better off with a larger T-instance or switching to an M-series instance that doesn't have the burst model.

Now let's put all these costs together in a real-world example.

Complete Cost Example: What EC2 Really Costs

This is the section no competitor provides: a complete, realistic cost breakdown showing what you'll actually pay for a typical workload. I'll walk through a 3-tier web application and show every line item.

Scenario: 3-Tier Web Application

Let's model a moderately sized web application with:

• Web tier: 2x t3.medium instances (behind Application Load Balancer)
• Application tier: 2x m6i.large instances
• Database: Amazon RDS (not calculated here, but referenced)
• Supporting infrastructure: Application Load Balancer, NAT Gateway, EBS volumes

This represents a common production architecture for a medium-traffic web application.

Line-Item Cost Breakdown

Here's what the monthly bill looks like at On-Demand rates (us-east-1, approximate pricing for illustration):

Compute Costs:

Storage Costs (EBS):

Network Costs:

Total Monthly On-Demand Cost: ~$341

Notice how the compute portion ($200.90) is only about 59% of the total bill. The remaining 41% comes from storage, load balancing, NAT Gateway, and data transfer, which is the "hidden cost" reality that most estimates miss.

Total Monthly Cost Comparison by Pricing Model

Now let's see how different pricing models affect the bottom line:

Key insight: Savings Plans can reduce your compute costs significantly, but they only affect the compute portion. The "other costs" remain constant. This is why your total savings percentage is lower than the headline discount, you're only discounting part of your bill.

With a clear understanding of total costs, let's determine which pricing model fits your workload.

Choosing the Right Pricing Model

Selecting a pricing model isn't about chasing the highest discount percentage. It's about matching the model to your workload characteristics. A 90% Spot discount means nothing if your application can't handle interruptions.

Here's my decision framework based on real-world experience.

Decision Framework by Workload Type

When to Combine Pricing Models

The most cost-effective approach for many organizations is a mixed strategy:

1. Baseline coverage with Savings Plans: Cover your steady-state minimum usage with a Compute Savings Plan. Aim for 70-80% coverage of your baseline.

2. Burst capacity with Spot: Use Spot Instances for variable demand above your baseline. Configure Auto Scaling with a mixed instances policy.

3. Fallback to On-Demand: When Spot capacity isn't available, automatically fall back to On-Demand for critical workloads.

This approach gives you committed discounts on predictable usage while maintaining flexibility for variable demand.

Savings Plans vs Reserved Instances: Which to Choose

AWS now recommends Savings Plans for new commitments, and I agree. Here's why:

Choose Savings Plans when:

• You want flexibility to change instance types or regions
• Your architecture might evolve over the commitment period
• You also use Fargate or Lambda (Compute Savings Plans cover these)
• You're making a new commitment (no existing RI investments)

Consider Reserved Instances when:

• You have existing RI investments and want consistency
• You want the option to sell unused capacity (Standard RIs only)
• You're absolutely locked into a specific instance family

For most teams, Compute Savings Plans provide the best balance of savings and flexibility.

Before committing to any pricing model, take advantage of EC2's Free Tier to test your setup.

EC2 Free Tier: What You Get in 2026

AWS offers free EC2 capacity for new accounts, but the offering changed in July 2025. Which Free Tier you get depends on when you created your account.

Accounts Created Before July 15, 2025

If your account predates July 2025, you have the traditional Free Tier:

• 750 hours/month of Linux t2.micro or t3.micro instances
• 750 hours/month of Windows t2.micro or t3.micro instances
• 30 GB of EBS storage (across Standard, gp2, gp3, st1, sc1)
• 12 months from account creation

The 750 hours is enough to run one instance continuously (730 hours/month) with some buffer. Or you can split it across multiple smaller instances.

New Accounts (After July 15, 2025)

Accounts created after July 15, 2025 get a different offer:

• $100 in AWS credits
• Valid for 6 months or until credits are exhausted
• More flexibility in how you spend (not limited to specific services)

This new model gives you more freedom to experiment with different instance types and services, but the credits expire faster.

Free Tier Eligible Instance Types

Beyond the basic t2.micro/t3.micro, several instance types are Free Tier eligible:

• t2.micro, t3.micro, t3.small
• t4g.micro, t4g.small (Graviton - ARM-based)
• c7i-flex.large, m7i-flex.large (newer flex instances)

The t4g instances are particularly interesting since they're Graviton-based, offering better price-performance for compatible workloads.

Track your Free Tier usage in the EC2 Dashboard's "EC2 Free Tier" box. Charges kick in immediately once you exceed the limits.

Once you've decided on a pricing model, the next choice is which instance type to use.

EC2 Instance Types and Pricing

AWS offers over 750 instance types across seven major families. This variety is powerful but can be overwhelming. Let me help you decode the options.

Understanding Instance Families

Each instance family is optimized for different workload characteristics:

General Purpose (T, M):

• Balanced compute, memory, and networking
• Best for: Web servers, code repositories, development environments
• T-series offers burstable performance (lower baseline, can burst higher)
• M-series offers consistent performance

Compute Optimized (C):

• High-performance processors
• Best for: Batch processing, gaming servers, scientific modeling, ML inference

Memory Optimized (R, X, U):

• Large memory-to-vCPU ratio
• Best for: In-memory databases, real-time analytics, caching

Storage Optimized (I, D, H):

• High sequential read/write to local storage
• Best for: NoSQL databases, data warehousing, distributed file systems

Accelerated Computing (P, G, F):

• Hardware accelerators (GPUs, FPGAs)
• Best for: Machine learning training, graphics rendering, video encoding

Instance Naming Convention Explained

EC2 instance names follow a consistent pattern: [Family][Generation][Capabilities].[Size]

Let me decode m6g.large:

• m: General Purpose family
• 6: 6th generation
• g: Graviton processor (ARM-based)
• large: Size (2 vCPU, 8 GB memory)

Common capability suffixes:

• a: AMD processors
• g: AWS Graviton (ARM)
• i: Intel processors
• d: NVMe instance store
• n: Network optimized
• flex: Flexible instances

Understanding this naming helps you quickly identify instance characteristics without looking up each one individually.

Graviton Instances: 20-40% Better Price-Performance

AWS Graviton processors (ARM-based) deserve special attention because they offer 20-40% better price-performance compared to equivalent x86 instances.

Graviton instance families:

• General Purpose: T4g, M6g, M7g
• Compute Optimized: C6g, C7g
• Memory Optimized: R6g, R7g

Migration considerations:

• Most modern languages and frameworks support ARM natively
• Containers generally transition with minimal changes
• Applications with C extensions may need recompilation
• Use multi-architecture container images to support both x86 and ARM64

Real-world example: Pix4D achieved 20% infrastructure cost reduction by migrating to Graviton. Similar results have been reported by Pinterest, SAP, and Sprinklr.

For new workloads, I recommend defaulting to Graviton unless you have a specific x86 requirement.

Let's explore strategies to further reduce EC2 costs.

EC2 Cost Optimization Strategies

Beyond choosing the right pricing model and instance type, several strategies can meaningfully reduce your EC2 spend.

Right-Sizing with AWS Compute Optimizer

Right-sizing means ensuring your instances are appropriately sized for actual workload requirements. AWS estimates that right-sizing can reduce costs by up to 25%.

AWS Compute Optimizer analyzes your instance utilization over a 14-day period and provides specific recommendations:

Finding classifications:

• Over-provisioned: Instance can be downsized while meeting performance requirements
• Under-provisioned: Instance needs more resources for optimal performance
• Optimized: Instance is appropriately sized

To get recommendations:

1. Opt in to AWS Compute Optimizer in the AWS Console
2. Wait at least 24 hours for metric collection
3. Review recommendations in the Compute Optimizer dashboard
4. Validate recommendations against your specific workload requirements

Compute Optimizer also provides Graviton migration recommendations, showing estimated savings and performance impact for switching processor architectures.

For detailed implementation guidance, see the AWS Compute Optimizer documentation.

Leveraging Auto Scaling

Auto Scaling automatically adjusts your instance count based on demand. This eliminates over-provisioning (paying for idle capacity) and ensures you have enough resources during peak times.

Cost optimization benefits:

• No instances running during zero-demand periods
• Automatic scale-out during traffic spikes
• Match capacity to actual demand, not peak estimates

Cost of Auto Scaling: The service itself is free. You pay only for the instances running and CloudWatch monitoring.

The key is setting appropriate scaling policies based on your workload patterns. Monitor your workload elasticity using Cost Explorer's hourly views to identify scaling opportunities.

Data Transfer Cost Reduction

Data transfer can be a significant cost driver. Here are proven strategies to reduce it:

Use VPC Endpoints for AWS service traffic: Instead of routing S3, DynamoDB, or other AWS service traffic through NAT Gateway (charged per GB), use VPC endpoints for direct, cheaper connectivity.

Deploy CloudFront for content delivery: Serving static assets through CloudFront is often cheaper than direct EC2 egress, plus you get better performance.

Minimize cross-AZ traffic: While multi-AZ deployment is important for availability, unnecessary cross-AZ data movement adds cost. Design your architecture to keep most traffic within a single AZ when possible.

Monitor with VPC Flow Logs: You can't optimize what you don't measure. Enable Flow Logs to understand your traffic patterns.

To track the impact of these optimizations, you'll need the right monitoring tools.

EC2 Cost Monitoring Tools

AWS provides several tools to help you monitor, analyze, and optimize EC2 costs. Here's what each offers and when to use them.

AWS Cost Explorer

Cost Explorer is your primary tool for understanding where your money goes.

Key capabilities:

• Visualize costs across hourly, daily, and monthly views
• Filter and group by service, instance type, region, tag, etc.
• Get Savings Plans and Reserved Instance recommendations
• Analyze workload elasticity patterns

Practical use: Start with Cost Explorer when investigating unexpected charges or planning commitments. The recommendations feature can identify optimal Savings Plan purchases based on your actual usage patterns.

AWS Compute Optimizer

Compute Optimizer focuses specifically on right-sizing recommendations.

What it analyzes:

• CPU utilization
• Memory utilization (requires CloudWatch agent)
• Network in/out
• Disk read/write operations

Unique value: Compute Optimizer provides specific instance recommendations with estimated monthly savings. It also flags Graviton migration opportunities with projected price-performance improvements.

Requirement: You must opt in to Compute Optimizer and enable Cost Explorer for savings calculations.

AWS Cost Optimization Hub

Cost Optimization Hub consolidates recommendations from multiple AWS services into a single dashboard.

Coverage:

• Over 15 recommendation types
• EC2 right-sizing
• Graviton migration
• Idle resource detection
• Savings Plans recommendations
• Cross-account visibility

Best for: Organizations with multiple AWS accounts who want a single pane of glass for cost optimization opportunities.

For more information, see the AWS Cost Optimization Hub page.

Let's address the most common questions about EC2 pricing.

Frequently Asked Questions

Why is my EC2 bill higher than the pricing calculator estimated?

The most common reason is hidden costs that aren't included in instance pricing: EBS volumes, data transfer, Elastic IPs, and load balancers. Always budget for these associated costs (typically 30-50% on top of compute). Our complete cost example above shows how these add up.

What is "EC2-Other" and why is it 30-50% of my bill?

"EC2-Other" is a billing category that includes EBS volumes, EBS snapshots, data transfer, Elastic IPs, and NAT Gateway charges. These are services associated with EC2 but billed separately. Review your Cost Explorer breakdown to see the specific components.

Do I get charged if my instance is stopped (not terminated)?

When you stop an instance, you stop paying for compute hours. However, you continue paying for EBS volumes attached to that instance. To eliminate all charges, you must terminate the instance and delete its volumes.

When should I use Reserved Instances vs Savings Plans?

For most new commitments, choose Savings Plans. They offer comparable discounts (up to 72%) with more flexibility. Use Reserved Instances only if you have existing RI investments, want to sell unused capacity in the Marketplace, or have very specific instance family requirements.

Are Graviton instances actually cheaper?

Yes. Graviton instances provide 20-40% better price-performance than comparable x86 instances. The instance price is lower, and you often need less capacity due to improved performance. The main consideration is ARM compatibility, most modern workloads work fine, but test your specific applications.

What's the fastest way to reduce EC2 costs by 30%?

Combine three strategies:

1. Right-sizing (10-25% potential savings): Use Compute Optimizer to identify over-provisioned instances
2. Savings Plans (up to 72% on compute): Purchase commitment coverage for your baseline usage
3. Graviton migration (20-40% better price-performance): Move compatible workloads to ARM instances

Executed together, these can easily achieve 30%+ savings without architectural changes.

Wrapping Up

EC2 pricing involves four models with savings up to 90% for the right workload, but the "right" model depends entirely on your specific requirements. Here's what to remember:

Key takeaways:

1. Hidden costs (EBS, data transfer, Elastic IPs, CPU credits) add 30-50% to instance-only estimates. Budget for them.
2. Savings Plans offer the best balance of savings and flexibility for most steady-state workloads.
3. Spot Instances provide up to 90% savings for fault-tolerant, interruptible workloads.
4. Graviton instances deliver 20-40% better price-performance. Default to them for new workloads.
5. Use AWS tools (Compute Optimizer, Cost Explorer) to continuously identify optimization opportunities.

Next steps: Estimate costs for your specific workload using the EC2 Pricing Calculator to compare all pricing models side by side.

For a broader perspective on proactive cost management, explore our Shift-Left FinOps guide to learn how to catch cost issues before they hit your bill.

What's your biggest EC2 pricing challenge? Drop a comment below, I'd love to hear what's working (or not) for your team.