AWS EC2 Pricing Guide: All 5 Models, Real Costs, and Hidden Fees

AWS EC2 pricing looks simple on the rate card and behaves very differently on the invoice. A t3.large is "$61 per month" right up until the EBS volumes, snapshots, data transfer, and NAT Gateway around it push the real figure past $150. That gap — between the number you estimated and the number finance asks you about — is what this guide is built to close. Every rate below is On-Demand, Linux, us-east-1, assuming a 730-hour month, verified August 2026. Last updated: August 2026.

What this guide covers:

• Real hourly and monthly rates for common instance types, not "contact sales" hand-waving
• All five purchase models compared: discount, commitment, flexibility, and interruption risk
• What the advertised "up to 72%" savings actually deliver in practice, with the source
• The hidden "EC2-Other" charges — and a worked example of the $61 instance that bills $150
• How to cut EC2 costs in ROI order, and why most savings recommendations never ship

AWS EC2 pricing at a glance

AWS EC2 pricing works like this: you pay per second (with a 60-second minimum) or per hour for compute capacity, and the rate depends on four variables — instance type, region, operating system, and purchase model. On-Demand is the list price; Savings Plans, Reserved Instances, Spot, and Dedicated Hosts discount it in exchange for commitment or interruption risk.

Here is what EC2 instance pricing looks like in practice — an EC2 pricing table for five common types. Rates are from the AWS On-Demand pricing page: On-Demand, Linux, us-east-1, 730-hour month, verified August 2026. To model a full architecture rather than a single instance, use the AWS Pricing Calculator.

Two caveats before you budget from this table. Region moves the number: the same instance can cost 15–25% more outside the big US regions. Operating system moves it more: Windows adds roughly 29% on the t3.large example, and commercial Linux or SQL Server licensing varies by instance size, so always price the exact configuration. And the compute rate is only part of the bill — storage, transfer, and networking charges land separately, which is where this guide ends up.

The 5 EC2 pricing models compared

Amazon EC2 pricing comes in five purchase models. They all run the same instances on the same hardware — what changes is what you promise AWS and what AWS promises you back.

How to read this: the discount column is the ceiling AWS advertises, not the number you should expect — the Savings Plans section below explains the gap. Pick the row that matches how predictable your workload is, not the row with the biggest percentage.

On-Demand Instances

On-Demand is the default: pay-as-you-go with no commitment. Billing is per second with a 60-second minimum for Linux, Windows, Windows with SQL Server, RHEL, and Ubuntu Pro; SLES still bills in full hours. You can start and stop instances at any time, and you stop paying for compute the moment an instance stops.

Per-second billing matters more than it sounds. Autoscaling groups that add capacity for a 20-minute traffic spike pay for 20 minutes, not a full hour; batch jobs that finish in 90 seconds pay for 90 seconds. If you run short-lived workloads, the effective rate of On-Demand is already lower than an hourly mental model suggests — which shrinks the real gap to commitment-based pricing.

Concrete EC2 instance pricing: a t3.large costs $0.0832/hr on Linux in us-east-1 — about $60.74 for a 730-hour month, verified August 2026. The operating system changes that materially. The same t3.large on Windows runs roughly a third more, because the Windows license is baked into the hourly rate. RHEL and SQL Server premiums vary by instance size and licensing terms, so price your exact configuration on the AWS rate card rather than applying a blanket percentage.

Pros: Maximum flexibility with zero commitment. Right for unpredictable workloads, short-term projects, spiky traffic, and anything you cannot forecast yet. Also the correct place to run a workload while you gather the utilization data that justifies a commitment.

Cons: The highest per-unit cost of the five models. A steady-state service that runs 24/7 on On-Demand pays list price for usage AWS would discount anywhere from roughly 30% to 70%, depending on term and payment option. On-Demand is a great starting point and an expensive place to stay.

Savings Plans: the 72% claim vs. the ~23% reality

Savings Plans discount your compute in exchange for committing to spend a fixed dollar amount per hour, every hour, for 1 or 3 years. AWS advertises savings of up to 72%. The advertised number is real — for a 3-year, all-upfront commitment on specific instance types. What organizations actually realize is a different figure.

Two Savings Plan types matter for EC2. Compute Savings Plans (up to 66% off) are the flexible option: the discount follows your usage across instance families, sizes, regions, operating systems, and tenancies, and also covers Fargate and Lambda. EC2 Instance Savings Plans (up to 72% off) are scoped to one instance family in one region and cover only EC2 — they do not apply to Fargate or Lambda. The extra 6 points of discount cost you nearly all of the flexibility.

Payment options tier the discount further: All Upfront (maximum discount), Partial Upfront, and No Upfront (smallest discount). Term length matters more than payment option — 3-year plans discount far deeper than 1-year plans.

Understand the mechanics before you size a commitment: the plan applies hour by hour, not averaged over the month. Commit to $10/hr of compute and run $6/hr overnight, and the remaining $4/hr of commitment for those hours is simply gone — unused hours never roll over. That is why the correct commitment target is your overnight-and-weekend floor, not your average.

The failure mode is overcommitment. A Savings Plan is a spend obligation, not a coupon: if your usage drops below the committed $/hr, you pay for the unused commitment anyway, and there is no marketplace to resell it. Commitments are fixed for 1–3 years while infrastructure drifts — teams migrate to Graviton, upgrade instance generations, containerize onto Fargate — and an EC2 Instance Savings Plan pinned to last year's instance family becomes a sunk cost watching the workload leave. That risk, and how to size around it, is covered in our guide to the downsides of EC2 Savings Plans.

Pros: Real discounts with automatic application to your highest-discount usage first. Compute Savings Plans in particular are the lowest-effort commitment instrument AWS sells.

Cons: No early exit and no resale. The gap between advertised and effective savings is wide, and closing it requires actively managing coverage — not just buying a plan once.

Reserved Instances

Reserved Instances (RIs) predate Savings Plans and commit to instance attributes — type, region, platform — rather than a dollar amount, for a 1-year or 3-year term. Reserved Instance pricing reaches up to 72% off for Standard RIs and 66% for Convertible RIs versus On-Demand, per the AWS RI pricing page.

Standard RIs carry the deeper discount and allow limited modifications after purchase: you can change the Availability Zone, shift sizes within the same instance family, and adjust networking type — but not the family or OS. Convertible RIs trade a few points of discount for the right to exchange into different instance types, operating systems, or tenancies during the term.

RIs keep two genuine advantages over Savings Plans. First, the RI Marketplace: if your needs change, you can resell unused Standard RIs to other AWS customers — the only commitment instrument AWS sells with an exit door. Second, capacity reservation: a zonal RI (scoped to a specific Availability Zone) reserves capacity, guaranteeing you can launch when that zone is tight. Savings Plans never reserve capacity themselves, though they can discount the On-Demand Capacity Reservations you pay for separately.

At scale, RI volume discounts stack on top: 5% once your upfront RI commitment in a region exceeds $500K, 10% beyond $4M.

Pros: Deep discounts, a resale market, and the only way to pair a discount with guaranteed capacity.

Cons: Tied to specific instance attributes, so they strand more easily than Compute Savings Plans when workloads change. Managing a fleet of RIs across accounts and regions is real operational work. For a decision framework, see our comparison of Savings Plans vs Reserved Instances.

Spot Instances

Spot Instances sell AWS's spare capacity at discounts that typically run 60–90% below On-Demand. There is no bidding war — that mechanism is long gone. Spot pricing adjusts gradually based on supply and demand for each instance type in each Availability Zone, and you simply pay the current price. The trade-off: AWS can reclaim a Spot Instance with 2 minutes of notice when it needs the capacity back.

Production Spot usage in 2026 is a solved pattern, not a gamble: diversify across many instance types and Availability Zones, let an allocation strategy pick the pools least likely to be reclaimed, and keep an On-Demand fallback in the same autoscaling group. The historical price data in the console shows how stable a given pool's pricing has been before you depend on it.

Pros: The cheapest compute AWS sells, by a wide margin. Excellent for interruption-tolerant work: batch processing, CI/CD runners, data pipelines, rendering, stateless services behind a load balancer with On-Demand fallback.

Cons: No availability guarantee. Databases, stateful services, and anything that cannot checkpoint and resume do not belong on Spot. Capacity varies by instance type, region, and time of day, so production Spot usage needs diversification across instance types and a graceful-interruption story.

Dedicated Hosts

Dedicated Hosts are the fifth model and the one most guides skip: you rent an entire physical server, billed per host rather than per instance, and run as many instances on it as the hardware supports.

Two situations justify the premium. Bring Your Own License (BYOL): per-socket and per-core licenses for Windows Server, SQL Server, and Oracle can be carried onto a Dedicated Host, which often beats paying AWS's license-included hourly rates — the visibility into physical cores exists precisely to satisfy those license terms. Compliance isolation: regulated workloads that must not share hardware with other tenants get single-tenant physical servers with host affinity controls.

Pricing follows the same commitment logic as the other models: On-Demand per-host rates, or up to 70% off with a 1- or 3-year Dedicated Host Reservation.

Pros: License cost recovery, hardware-level isolation, and per-core visibility for auditors.

Cons: You pay for the whole host whether you fill it or not, so utilization discipline matters more than in any other model. For everyone without BYOL or compliance drivers, the other four models are cheaper and simpler.

What about the EC2 Free Tier?

The Free Tier is not a pricing model — it is a trial budget, and it changed fundamentally on July 15, 2025. The old structure (750 free hours of a micro instance per month for 12 months) is gone; by 2026 it has expired for every remaining account. If you read a guide describing 750 free hours, it is out of date.

The current program, per the AWS Free Tier docs, is credit-based: new accounts get up to $200 in credits — $100 at signup plus up to $100 more for completing onboarding activities — valid for 6 months or until spent, whichever comes first. For EC2, the credit-eligible instance types are t3.micro, t3.small, t4g.micro, t4g.small, c7i-flex.large, and m7i-flex.large.

The warning that matters: there is no permanently free EC2. When the credits run out or the 6 months end, everything you left running reverts to On-Demand billing — including the EBS volumes and public IPv4 addresses attached to instances you forgot about. Treat the Free Tier as a $200 sandbox with an expiry date, and set a billing alarm on day one.

The hidden costs: what "EC2-Other" actually contains

Open AWS Cost Explorer and you will find your EC2 spend split in two: "EC2-Instances" (the EC2 pricing this guide has quoted so far) and a vaguer line called "EC2-Other". That second line is where estimates go to die. It bundles EBS storage, snapshots, data transfer, NAT Gateway charges, and idle public IPv4 addresses — and depending on architecture, it can add 30–60% or more on top of your instance spend. If your AWS EC2 cost keeps beating your estimates, this is almost always why.

The line items and their rates, from EBS pricing to snapshot pricing to NAT (us-east-1, verified August 2026):

Now the worked example from the intro. Take one production t3.large — a modest web service in a private subnet with a NAT Gateway for outbound traffic, 200 GB of gp3 storage, daily snapshots, and moderate traffic:

The compute rate — the number every pricing comparison obsesses over — is 40% of this bill. The exact split is architecture-dependent (a NAT Gateway amortized across twenty instances hurts far less than one dedicated to a single service), but the direction is universal: the instance rate is a floor, not an estimate.

One more trap: stopped is not free. Stopping an instance ends the compute charge and nothing else. In the example above, the stopped version of this instance still bills $34.65 a month — EBS, snapshots, and the public IPv4 keep the meter running until you delete them.

EC2 instance types and what they cost

EC2 instance pricing also depends on which of the hundreds of AWS instance types you pick. You do not need the full matrix — you need the family logic. One anchor rate per family (On-Demand, Linux, us-east-1, verified August 2026):

• T family (burstable general purpose): cheapest entry point — t3.micro at $0.0104/hr, t3.large at $0.0832/hr. CPU credits throttle sustained load.
• M family (general purpose): the balanced default — m7g.large at $0.0816/hr.
• C family (compute optimized): more CPU per dollar — c7g.large at $0.072/hr.
• R family (memory optimized): for databases and caches; expect a premium over the equivalent M size.
• I family (storage optimized): local NVMe for I/O-heavy databases and search.
• P / G / Inf (accelerated): GPU and ML silicon — g5.xlarge at $1.006/hr ($734/month). Note the June 2025 On-Demand price cuts: P4d/P4de dropped 33% and P5 dropped 44% (AWS's "up to 45%" headline referred to a P5 Savings Plan configuration), so any GPU quote older than that is wrong.

Graviton changes the math before any commitment does. AWS's ARM-based Graviton instances (the "g" in m7g, c7g, r7g) run 10–20% cheaper than comparable x86 instances — the m7g.large at $59.57/month undercuts the t3.large while outperforming it on sustained load. The sequencing rule that follows: evaluate Graviton before you buy an EC2 Instance Savings Plan or a Reserved Instance. Both are locked to an instance family, and a commitment pinned to x86 gets stranded the day you migrate. A Compute Savings Plan follows the workload across families, so it is the only commitment safe to buy pre-migration. Be honest about the migration cost too: most interpreted-language and JVM workloads move easily, but container images need ARM builds and anything with native dependencies needs compatibility testing — it is a project, not a checkbox.

For the full family-by-family breakdown, see our guide to EC2 instance types.

How to reduce EC2 costs

EC2 cost optimization, in ROI order — the order we apply it across the AWS accounts we manage, not the order AWS's marketing suggests:

• 1. Rightsizing. You pay for provisioned capacity, not utilization: an instance at 20% CPU bills exactly the same as one at 100%. Oversized instances — sized for a launch-day peak that never returned, then never revisited — are the most common EC2 waste we find. Glassity analyzes utilization continuously and delivers each rightsizing change as an infrastructure-as-code pull request your engineers review and merge.
• 2. Graviton migration. A 10–20% rate cut for compatible workloads, applied before any commitment locks you to the wrong architecture. Do it in the sequence described above.
• 3. Commitment coverage for the steady baseline. The metric that determines your realized savings is not which instrument you buy — it is coverage: the percentage of your stable compute usage running under a Savings Plan or RI discount. A perfectly chosen plan covering 30% of your baseline loses to a decent plan covering 85%. Measure coverage, commit to the floor you are confident in, and revisit quarterly.
• 4. Spot for interruption-tolerant work. Batch jobs, CI/CD, and stateless fleets at 60–90% off. The prerequisite is architecture that survives a 2-minute reclaim notice.
• 5. Schedule non-production. Dev and staging environments running 24/7 but used only 45 of the week's 168 hours burn the other 73% of their cost on empty hours. AWS Instance Scheduler or equivalent automation stops them nights and weekends.
• 6. Storage hygiene. Migrate gp2 volumes to gp3 (same performance floor, lower rate), delete orphaned volumes left behind by terminated instances, and put retention policies on snapshots — at $0.05/GB-month, an unbounded daily-snapshot policy quietly compounds. In the accounts we onboard, unattached volumes and expired-purpose snapshots are almost always present and almost never intentional.

These compound rather than compete. The effective strategy stacks them: rightsize and migrate to Graviton first so you commit to the correct baseline, cover that baseline with a Savings Plan or RIs, push interruption-tolerant work to Spot, schedule what does not need to run, and keep storage from silently accumulating. Buying a commitment on top of oversized x86 instances locks in the waste at a discount — order matters.

AWS's own Cost Optimization Hub will surface several of these opportunities. Its limitation is structural: it produces recommendations, and a recommendation is not a saving — which is the subject of the final section.

Why most EC2 savings never ship

Every tool in this space — Cost Optimization Hub, Compute Optimizer, every third-party dashboard — ends the same way: a list of recommendations. And that is where most EC2 savings die. Not because the recommendations are wrong, but because acting on one means an engineer edits Terraform, opens a pull request, waits for review, tests in staging, and merges — an engineer-hour cost that never appears in any tool's savings math and always loses to feature work in sprint planning.

The result is a backlog: rightsizing tickets that age out, gp2 volumes flagged three quarters ago, a Graviton migration that stays "on the roadmap". Meanwhile the console shortcut is worse than doing nothing — in an infrastructure-as-code environment, a change clicked into the console is drift, and the next terraform apply silently reverts it.

The economics of the backlog explain themselves. Each individual finding is small — a size reduction here, a volume type there — so no single one ever wins a prioritization meeting against a feature. Collectively they are a meaningful share of the bill. The failure is not knowledge; every team with Cost Explorer open knows roughly where the waste is. The failure is that nobody's job is to ship the fix.

This is the gap Glassity was built to close. Instead of adding another dashboard to the pile, Glassity detects the waste and opens the infrastructure-as-code pull request itself — the rightsized instance type, the gp3 migration, the schedule — against your repository. Your engineer reviews and merges through the same workflow as any other change; the fix becomes source of truth instead of drift. Dashboards tell you what to do. Automated cloud cost optimization does it, and leaves your team the ten-minute review instead of the two-week ticket. For how this fits into a broader operating model, see our take on proactive FinOps for cloud governance.

Glassity automates AWS cost optimization — delivering up to 50% savings on EC2 and 69% on RDS. You only pay 10% of what we actually save you. Book a free savings assessment.