Amazon EC2: Complete Pricing and Cost Optimization Guide

If you are spending more than a few thousand dollars a month on AWS, EC2 is almost certainly one of the largest line items. It is also the most complex AWS service to optimize because the pricing model has five distinct purchase options, hundreds of instance types, and a cost structure that layers compute, storage, networking, and software separately. Getting each layer right at once is genuinely difficult.

This guide works through the EC2 pricing model from the ground up: what each purchase option costs and when it is the right choice, how instance families and sizes affect cost, where waste typically hides on EC2 bills, and the operational practices that keep costs from creeping upward over time. Everything here is based on AWS official documentation.

The Five EC2 Purchase Options

AWS offers five ways to pay for EC2 compute. They are not competing alternatives — most organizations use several simultaneously, matching each option to the workload it fits best.

On-Demand

On-Demand pricing means you pay for compute by the hour or second (minimum 60 seconds) with no upfront cost and no long-term commitment. You can launch and terminate instances at any time, and billing stops when the instance is stopped or terminated. Source: aws.amazon.com/ec2/pricing/on-demand/ DIRECT.

On-Demand is the most expensive way to run steady-state workloads and the correct way to run unpredictable or genuinely temporary ones. It is also the baseline from which all other pricing options are measured. A $0.192/hour on-demand m5.large is the comparison point for what Savings Plans and Reserved Instances save.

One thing to know: On-Demand Capacity Reservations let you reserve compute capacity in a specific Availability Zone without committing to a term-based pricing discount. You are charged the on-demand rate regardless of whether you use the capacity. Source: docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html. This is useful for workloads where capacity availability matters more than price, such as when launching large Spot Instance fleets or during known peak periods.

Savings Plans: the recommended default for steady workloads

AWS is explicit about this on their own Reserved Instances pricing page: ‘We recommend Savings Plans (over Reserved Instances). Like Reserved Instances, Savings Plans offer lower prices (up to 72% savings compared to On-Demand Instance pricing). In addition, Savings Plans offer you the flexibility to change your usage as your needs evolve.’ Source: aws.amazon.com/ec2/pricing/reserved-instances/pricing/ DIRECT QUOTE.

Savings Plans are a commitment to a minimum hourly spend amount (measured in $/hour) for a 1-year or 3-year term. Unlike Reserved Instances, you are not committing to a specific instance configuration. The discount applies automatically to eligible usage up to your committed amount, and any usage beyond the commitment runs at on-demand rates.

Two types exist. Compute Savings Plans provide the most flexibility and reduce costs by up to 66%. They automatically apply to EC2 instance usage regardless of instance family, size, AZ, region, OS, or tenancy, and also apply to Fargate and Lambda usage. Source: aws.amazon.com/savingsplans/compute-pricing/ DIRECT. EC2 Instance Savings Plans provide savings up to 72% in exchange for commitment to usage of individual instance families in a region. They offer less flexibility than Compute Savings Plans but a deeper discount on the committed family. Source: same.

The practical split: Compute Savings Plans for dynamic workloads where instance type, region, or workload destination (EC2 vs Fargate vs Lambda) may change. EC2 Instance Savings Plans for stable, single-family workloads where the deeper discount justifies the narrower commitment scope.

Also read: AWS Savings Plans vs Reserved Instances: which actually saves more in 2026

Reserved Instances

Reserved Instances provide a significant discount (up to 72%) compared to On-Demand pricing, and can be purchased for a 1-year or 3-year term. Source: aws.amazon.com/ec2/pricing/reserved-instances/ DIRECT. Unlike Savings Plans, RIs commit to a specific instance configuration. AWS billing automatically applies the RI discount when running instances match the RI’s attributes.

Two offering classes exist. Standard Reserved Instances offer up to 72% off and can be modified for AZ, instance size within family, and networking type. They can also be listed for sale on the Reserved Instance Marketplace if you no longer need them. Convertible Reserved Instances offer up to 66% off and can be exchanged for a different instance family, OS, or tenancy during the term. Source: aws.amazon.com/ec2/pricing/reserved-instances/ DIRECT.

Three payment options apply to both: All Upfront (deepest discount, pay in full at purchase), Partial Upfront (split between upfront and ongoing hourly), and No Upfront (no upfront payment, ongoing hourly rate). The discount difference between All Upfront and No Upfront on a given RI is typically 3-5 percentage points.

Given AWS’s own recommendation of Savings Plans over RIs, when should you still use RIs? When you need a capacity reservation in a specific Availability Zone (Savings Plans do not provide capacity reservations), when you have workloads with very stable, fixed instance configurations where the EC2 Instance Savings Plan discount is not sufficient, or when you specifically want access to the Reserved Instance Marketplace for potential resale.

Spot Instances

Spot Instances are spare EC2 capacity available at a discount of up to 90% compared to On-Demand pricing. Source: aws.amazon.com/ec2/spot/ DIRECT. Spot prices are set by EC2 and adjust gradually based on long-term trends in supply and demand. When EC2 needs the capacity back, your Spot Instance receives a 2-minute interruption notice before termination.

Spot is the right choice for workloads that are fault-tolerant and interruption-safe: batch processing, data pipeline jobs, CI/CD builds, machine learning training with checkpointing, and stateless web tiers with enough redundancy to absorb instance loss. For these workloads, the 60-90% discount versus on-demand typically dwarfs the operational cost of designing for interruption.

Spot is not appropriate for stateful workloads without external state management, databases without replica configurations, or any workload where mid-execution interruption would cause data loss or service outage. The interruption notice is 2 minutes, not 2 hours.

Dedicated Hosts

Dedicated Hosts are physical EC2 servers fully dedicated to your use. They allow you to use existing server-bound software licenses (per-socket, per-core, or per-VM) and can help with compliance requirements that prohibit multi-tenant infrastructure.

Dedicated Hosts are the most expensive compute option for most workloads, justified only when license compliance or regulatory requirements mandate single-tenant infrastructure. For workloads without those constraints, multi-tenant on-demand, Savings Plans, or Reserved Instances are always cheaper.

EC2 Instance Families: Choosing the Right Type

EC2 offers hundreds of instance types organized into families optimized for different workload characteristics. Choosing the wrong family — even with Savings Plans coverage — leaves money on the table because you are paying for capacity your workload does not use.

General purpose

M-family instances (m5, m6i, m6g, m7i, m7g) deliver a balanced CPU-to-memory ratio suitable for the broadest range of workloads: web servers, application servers, small databases, and development environments. M-series is often the right starting point when workload characteristics are not yet well understood.

T-family instances (t3, t3a, t4g) are burstable performance instances designed for workloads with variable CPU requirements. They earn CPU credits when running below their baseline CPU threshold and consume credits for burst activity above it. In Standard mode, a T instance that exhausts its credits is throttled to baseline CPU. In Unlimited mode, CPU credits can be borrowed against future earnings at a charge of $0.04/vCPU-hour for T4g Linux (source: aws.amazon.com/ec2/pricing/on-demand/ DIRECT). For workloads with unpredictable spikes where T instances run in Unlimited mode frequently, the credit charges can make the effective hourly cost higher than a larger M-family instance. Monitor CPU credit balance before committing to T-series instances in production.

Compute optimized

C-family instances (c5, c6i, c6g, c7g) are designed for compute-intensive workloads: high-performance web servers, CPU-bound application servers, scientific modeling, machine learning inference, and video encoding. C-family instances have a higher CPU-to-memory ratio than M-family, which makes them more efficient and cheaper per workload for CPU-bound applications that don’t need the full memory allocation of an M-family equivalent.

Memory optimized

R-family instances (r5, r6i, r6g, r7g) provide higher memory-to-CPU ratios for memory-intensive workloads: large in-memory databases (Redis, Memcached at scale), real-time big data analytics, and high-performance relational databases with large working sets. X-family instances extend further into the high-memory tier for SAP HANA, Apache Spark, and very large in-memory databases.

Storage optimized

I-family instances (i3, i3en, i4g) use NVMe SSD storage and are designed for high I/O workloads: NoSQL databases (Cassandra, MongoDB, DynamoDB at very high throughput), distributed file systems, and data warehousing with local storage requirements. D-family and H-family instances offer high magnetic disk capacity for sequential I/O workloads.

Graviton: the cost-performance case

AWS Graviton instances (identifiable by the ‘g’ suffix — m6g, c6g, r6g, m7g, etc.) run on ARM64 processors designed by AWS. For most workloads that have been validated on ARM64, Graviton instances deliver the same or better performance at a lower on-demand price than their x86 equivalents. The price difference is approximately 10-20% lower on-demand for equivalent performance, and Graviton instances are fully supported by Savings Plans.

The migration consideration: Graviton requires that your application runs on ARM64 architecture. Most modern language runtimes (Java, Python, Go, Node.js, .NET) run on ARM64 without code changes. Container images need to be built for ARM64. If your workload has been validated or migrated to ARM64, Graviton is almost always the cost-optimal choice within its family.

The EC2 Cost Components Beyond Compute

EC2 billing is not just the instance hourly rate. Several adjacent charges are commonly missed or misunderstood and can significantly inflate the actual cost versus what the compute rate alone suggests.

EBS storage

Every EC2 instance attaches EBS storage for its root volume and any additional data volumes. EBS is billed independently of the instance — when an instance is stopped, the instance compute charge stops but the EBS storage charge continues. When an instance is terminated, the root volume is deleted by default but attached data volumes are not. Unattached EBS volumes accumulate storage charges indefinitely until explicitly deleted.

EBS volume types have different pricing: gp3 (general-purpose SSD, current default) costs less per GB than gp2 and provides baseline 3,000 IOPS included in the per-GB price. io1 and io2 provision IOPS separately and carry an additional per-IOPS charge. For most workloads, migrating from gp2 to gp3 reduces storage costs without any performance change. Source: aws.amazon.com/ebs/pricing/.

EBS snapshots for backup are billed at a lower per-GB rate than live volumes, but they accumulate unless explicitly managed. Amazon Data Lifecycle Manager can automate snapshot creation and expiration on a schedule, preventing snapshot storage from growing unbounded.

Public IPv4 address charges

Beginning February 1, 2024, AWS charges $0.005 per hour for every public IPv4 address attached to a running EC2 instance, whether associated with an Elastic IP or assigned directly. For a fleet of 100 instances each with a public IPv4, that is $0.50/hour or approximately $365/month in IPv4 charges alone, separate from compute. Source: aws.amazon.com/vpc/pricing/ DIRECT.

The cost control lever: audit whether all public IPv4 addresses are actively required. Instances that only serve internal traffic do not need public IPs — they can route through a load balancer or NAT gateway for outbound internet access. Elastic IPs that are not attached to running instances carry a charge to discourage address hoarding ($0.005/hour per unattached Elastic IP). Source: same.

Data transfer

Data transfer out to the internet is charged beyond the first 100 GB/month free tier at rates starting at $0.09/GB for US East, decreasing with volume. Inter-region data transfer between EC2 instances carries charges at standard inter-region rates. Cross-AZ data transfer within a region is $0.01/GB in each direction. Source: aws.amazon.com/ec2/pricing/on-demand/ under Data Transfer.

For architectures with significant internal east-west traffic, AZ placement matters. Placing instances that communicate frequently in the same AZ eliminates cross-AZ transfer charges. For architectures with significant outbound internet traffic, CloudFront can reduce data transfer costs because CloudFront’s origin fetch rates are lower than direct EC2 internet egress.

Rightsizing: Matching Instance Size to Actual Workload

Rightsizing is the practice of ensuring the instance size you provision matches the actual CPU and memory requirements of the workload running on it. It is the highest-leverage optimization that does not require any architectural change — it simply means running the smallest instance that comfortably handles the workload.

AWS Compute Optimizer analyzes 14 days of CloudWatch metrics for EC2 instances and provides rightsizing recommendations. It identifies instances with consistently low CPU utilization (typically below 40% average) and recommends downsizing to a smaller instance or a different family that better matches the workload’s resource mix. Source: aws.amazon.com/compute-optimizer/.

The rightsizing analysis is not the same as acting on the recommendation. Compute Optimizer cannot know whether that spare CPU headroom is intentional (reserved for traffic spikes), architectural (the workload needs the memory of the larger instance even if CPU is underutilized), or genuinely wasteful. Every rightsizing recommendation requires a human judgment call on whether the spare capacity is purposeful.

The practical cadence: review Compute Optimizer recommendations quarterly. Filter for high-confidence recommendations where the instance has shown consistently low utilization for the full trailing 14 days without visible spikes. Test downsized instances in staging before applying to production. Build a rightsizing review into the standard FinOps quarterly cycle rather than treating it as a one-time exercise.

Also read: AWS Compute Savings Plans: the complete guide to EC2, Fargate, and Lambda commitment discounts

Waste: The EC2 Cost That Accumulates Without Anyone Noticing

Waste on EC2 is distinct from overprovisioning. Overprovisioned instances are running and doing something — just less than they should. Wasted resources are paying for nothing at all.

Idle and stopped instances

A stopped EC2 instance does not charge for compute — but it does charge for its attached EBS volumes, Elastic IPs, and any associated resources. More commonly, instances are left running at near-zero utilization rather than being stopped or terminated — developers spin up instances for a project, the project concludes, and the instances continue running on the AWS bill without anyone actively using them.

The detection mechanism: AWS Compute Optimizer’s idle instance recommendations identify instances with CPU utilization below 1% and network I/O below 5 MB over the trailing 14 days. These are genuinely idle resources. AWS Trusted Advisor’s Low Utilization Amazon EC2 Instances check provides similar detection available on Business Support+ and above.

Unattached EBS volumes

When an EC2 instance is terminated, its root volume may be deleted, but attached data volumes are not deleted by default. These volumes accrue storage charges indefinitely. In large AWS accounts with active development and frequent instance lifecycle changes, unattached EBS volumes can accumulate to meaningful monthly charges without any team actively noticing.

Audit: in the AWS EC2 console, filter volumes by state = available (not in-use). These are all unattached. Snapshot and delete any that are not needed. Set up lifecycle policies via Amazon Data Lifecycle Manager to prevent future accumulation in dev environments.

Unassociated Elastic IPs

An Elastic IP not associated with a running instance costs $0.005/hour — $3.65/month per address. Small per-address, but a large AWS account can accumulate dozens of unassociated Elastic IPs from past projects and migrations. Audit unassociated EIPs in each region and release those no longer needed.

Dev and test environments running 24/7

Development and test instances that run continuously during business hours and continue running overnight and on weekends are a common source of avoidable EC2 spend. An m5.large at $0.096/hour costs $69/month. Running only 8 hours per business day (roughly 43% utilization) cuts that to $30/month. Instance Scheduler (an AWS solution) or EC2 start/stop automations via Lambda and EventBridge can enforce schedules without manual intervention.

The Commitment Strategy: Sizing Savings Plans Correctly

The most important concept in EC2 commitment purchasing is sizing the commitment to the stable floor rather than the average or the peak. The stable floor is the minimum on-demand compute spend that will exist continuously regardless of how usage fluctuates. It is the baseline that never goes to zero.

To measure the stable floor: pull 60-90 days of EC2 on-demand spend data from Cost Explorer, broken down by day. The minimum daily on-demand spend across the entire observation window is your stable floor. A Savings Plan sized to that floor is fully utilized every day of the term. Any Savings Plan beyond the floor will have utilization gaps on days when usage drops to minimum.

Oversizing a Savings Plan is a meaningful mistake. A Savings Plan commitment runs for the full term whether or not you use the committed amount. If you commit $10/hour and your actual EC2 usage drops to $6/hour during a scaling-down or architecture-migration event, you are paying $10/hour and only using $6/hour of it. The unused $4/hour is sunk cost.

The conservative sizing principle: commit to the floor, not the average. Let everything above the floor run at on-demand or on Spot. Renew and expand the commitment at the next review cycle after the new usage floor has been established. This approach costs slightly more in the short term (some compute above the floor runs on-demand) but eliminates commitment risk entirely and produces better utilization metrics over the full term.

How Usage.ai Manages EC2 Savings Plans

The logic for EC2 commitment management is sound in theory but operationally difficult to execute manually. At scale — multiple AWS accounts, multiple regions, hundreds of instance types changing continuously — maintaining a manually calculated Savings Plan portfolio that stays sized to the actual floor without over- or under-committing is a full-time job.

Usage.ai handles this through continuous, automated analysis. The platform analyzes your actual EC2 on-demand spend daily, identifies the stable floor across your full account or organization, and sizes Compute Savings Plan recommendations accordingly. Because usage patterns change (new services launch, old services scale down, infrastructure migrates between regions), the recommendation refreshes on a 24-hour cycle rather than a quarterly review. AWS Cost Explorer refreshes Savings Plan recommendations every 72 hours or more — a 3-day lag. At $10,000/day in uncovered on-demand spend, that gap matters.

When Savings Plans are purchased through Usage.ai, they are covered by the buyback guarantee. If a Savings Plan commitment becomes partially stranded — because a workload is migrated, decommissioned, or moved to Spot — the unused commitment value is returned as cashback in real money. This changes the sizing decision from conservative to accurate: you can commit at the right level for your current workload rather than holding back because of uncertainty about future architecture changes.

$91M+ in savings delivered to 300+ enterprise customers across AWS, Azure, and GCP. Fee is a percentage of realized savings only. No savings, no fee. 30-minute setup, billing-layer access only.

Frequently Asked Questions

1. What is the cheapest way to run EC2 instances?

It depends on the workload. For interruptible, fault-tolerant workloads (batch jobs, data pipelines, CI/CD), Spot Instances provide up to 90% savings versus on-demand. For steady, continuously running workloads, Savings Plans (Compute Savings Plans up to 66%, EC2 Instance Savings Plans up to 72%) deliver the deepest discounts available on continuously running instances. AWS recommends Savings Plans over Reserved Instances as the default commitment instrument for most use cases. Source: aws.amazon.com/ec2/pricing/reserved-instances/pricing/ DIRECT.

 

2. What is the difference between Compute Savings Plans and EC2 Instance Savings Plans?

Compute Savings Plans apply automatically to EC2 usage regardless of instance family, size, Availability Zone, region, operating system, or tenancy, and also apply to Fargate and Lambda. They provide savings up to 66% off on-demand. EC2 Instance Savings Plans apply to a single instance family in a single region, regardless of AZ, size, OS, or tenancy within that family. They provide savings up to 72% off on-demand — a deeper discount in exchange for the narrower commitment scope. Source: aws.amazon.com/savingsplans/compute-pricing/ DIRECT.

 

3. When should I use Reserved Instances instead of Savings Plans?

Savings Plans are generally the recommended default per AWS’s own guidance. Reserved Instances remain the correct choice when: (1) you need a capacity reservation in a specific Availability Zone (Savings Plans do not provide capacity reservations, only pricing discounts), (2) you specifically need access to the Reserved Instance Marketplace to potentially sell unused capacity, or (3) you have workloads with very stable, fixed instance configurations where the Standard RI discount is slightly deeper than available Savings Plan rates.

 

4. How much do Spot Instances cost?

Spot Instances provide savings of up to 90% compared to on-demand pricing. Source: aws.amazon.com/ec2/spot/ DIRECT. The actual Spot price varies by instance type, region, and availability zone, and changes gradually based on supply and demand trends. Current Spot prices by instance type and region are published on the EC2 Spot pricing page, updated every 5 minutes. Spot Instances can be interrupted when EC2 needs the capacity back, with a 2-minute warning before termination.

 

5. Does stopping an EC2 instance stop all billing?

No. When an EC2 instance is stopped, the per-second compute billing stops. However, EBS volumes attached to the instance continue to be billed at standard EBS storage rates. Elastic IPs associated with the instance continue to be billed at the per-hour rate. Other associated resources (Elastic Load Balancers, NAT gateways) continue billing based on their own usage. Only terminating an instance fully stops the compute charge and (by default) removes the root EBS volume.

 

6. What are AWS Graviton instances and should I use them?

AWS Graviton instances run on ARM64 processors designed by AWS. They are identified by a ‘g’ suffix in the instance name (m7g, c7g, r7g, etc.). For workloads that have been validated on ARM64 — which includes most modern applications in Java, Python, Go, Node.js, .NET, and container-based workloads — Graviton instances typically deliver the same or better performance at approximately 10-20% lower on-demand cost than equivalent x86 instances. They are fully supported by Compute Savings Plans and EC2 Instance Savings Plans. The main consideration is validating that your application and any software dependencies compile and run correctly on ARM64 before migrating production workloads.