How to Reduce Your AWS EC2 Costs in 2025

Introduction

If you've ever opened your AWS bill and winced at the EC2 line item, you're not alone. EC2 costs can sneak up on you. Compute hours, storage, data transfer, licensing and more all add up. By default you pay the on-demand rate, but there are countless levers you can pull to pay 30–50% less.

In this post we'll first break down exactly how EC2 charges are calculated so you know where your dollars go. Then we'll walk through every way to pay less:

1. Purchase Side Optimizations – RIs, Savings Plans, Spot and more.
2. Utilization Optimizations – rightsizing, idle shutdowns, credit management.
3. EBS Storage Charges – understanding your volume & snapshot fees.
4. Networking & Data Transfer Optimizations – data transfer hotspots, EIPs, traffic locality.
5. Modern AWS & Third Party Tooling – AWS native checks and third party helpers.

Finally, we'll tie it all together with a simple, five step blueprint you can follow today to turn these tactics into real savings, manually or automated. Let's dive in.

How EC2 Charges Are Calculated

In order to understand how to reduce our EC2 costs, we'll need to understand the different ways AWS charges customers for EC2 instances.

Typical breakdown of monthly EC2 costs showing relative proportions of compute hours, storage, data transfer, and other charges.

Instance Selection & Compute Pricing

Your choice of instance family (M, C, R, etc.), generation (e.g., 7th-gen Intel Xeon or 8th-gen Graviton), and size (nano up to 24xlarge) is the single biggest driver of your EC2 on-demand rate:

• Compute hours (on-demand): By default you pay the published per second rate for your instance. This is your base rate before any discounts.
  
• Instance family, generation & size: Each family/gen/size has its own per second price. Size scaling means larger instances aren't always linear multiples of smaller ones.
  
• Price/perf: Newer generations deliver 15–40% better throughput at the same (or lower) cost.
  
• Architecture & region: Graviton (ARM) types often cost less per vCPU, and on-demand rates vary 5–10% by region.

For live prices, check the EC2 On-Demand Pricing and EC2 Instance Types pages.

Purchase Options

Reserved Instances

Reserved Instances let you commit to one- or three-year terms in exchange for a lower hourly rate.

RI class	Discount (up to)	Flexibility	Marketplace tradeable
Standard	72 %	Size flexible within the same family (fixed family / OS / tenancy / region)	Yes
Convertible	66 %	Exchange across families, OS, and tenancy	No

Pros:

• Highest long-term discounts (Standard).
  
• Convertible RIs allow family / OS swaps.
  
• Predictable budgeting; zonal RIs also reserve capacity.
  

Cons:

• Commitment is for the full term.
  
• Only Standard RIs can be resold on the RI Marketplace.
  

See the AWS EC2 Reserved Instances documentation for more information.

Savings Plans

Savings Plans let you commit to a set hourly spend over a one or three year term in exchange for automated discounts on your compute usage.

Plan type	Discount (up to)	Scope
EC2 Instance Savings Plan	72 %	Any size in one instance family, within a region
Compute Savings Plan	66 %	Any EC2, Fargate, or Lambda usage, any region

You still pay the committed $/hour even if your actual usage drops, so forecasting accuracy matters.

Pros:

• Up to 72% off with EC2 savings plans
• Covers multiple sizes of the same family in one region
  
• No need to match individual RIs—you get automatic coverage
  

Cons:

• You're on the hook for your committed spend, regardless of actual usage.
• You'll need accurate forecasting of your compute spend.
• You can't trade these: they cannot be resold on the AWS Marketplace.

See the AWS EC2 Savings Plans documentation for more information.

Spot Instances & EC2 Fleets

Spot Instances let you tap into AWS's unused EC2 capacity at up to 90% discount compared to on-demand, but can be interrupted with a ~2 minute warning.

EC2 Fleets (formerly Spot Fleet) let you define a target capacity across multiple instance types and AZs; AWS automatically launches and maintains that capacity with Spot (and optional on-demand) instances.

How it works:

1. Spot Instances: Request unused capacity at the current spot price—runs until capacity is needed back by AWS.
2. EC2 Fleets: Submit a fleet request (target capacity + instance mix); AWS allocates spot (and optionally on-demand) to meet it.

Pros:

• Massive discounts: up to ~90 % off on-demand
• Ideal for stateless, fault-tolerant workloads (batch, CI/CD, HPC)

Cons:

• Your instances can be reclaimed with ~2 min notice—your apps must tolerate interruptions.
• Your fleets need diversification and ongoing tuning.

Strategies:

• Capacity optimized: Use pools with the most spare capacity for fewer interruptions.
  
• Lowest price: Target the cheapest pools for maximum savings (higher interruption risk).

Use spot fleets to diversify across AZs and instance types for both cost and resilience.

See the AWS EC2 Spot Instances documentation for more information.

EBS Storage Charges

EBS volumes are a core part of most EC2 workloads and incur ongoing costs based on the type, size, and usage of your volumes and snapshots:

• Volume pricing: Charged in GB per month for gp2, gp3, io1/io2 (provisioned IOPS), st1 (throughput optimized HDD), and sc1 (cold HDD).
  
• Snapshot storage: Charged in GB per month for retained EBS snapshots, with lower cost options via the snapshot archive tier.
  
• Unavoidable baseline: Even stopped instances can incur EBS storage charges, so volume management is key to EC2 cost control.

Cost Optimization Deep Dive

We'll cover detailed EBS cost optimization strategies (rightsizing, lifecycle policies, GP3 tuning, archive transitions, orphan cleanup, etc.) in an upcoming deep dive post.

Networking & Data Transfers

Another unavoidable cost when running EC2 instances is networking. While straightforward, it can add up. Here are the key line items to watch.

Data Transfers

• Cross-AZ Data Transfer: Traffic between availability zones in the same region is charged at roughly $0.01/GB in and $0.01/GB out ($0.02/GB total). Prices can differ by region.
  
• Internet Egress: Public-internet outbound traffic beyond the free 100GB starts at about $0.09 / GB for the first 10 TB / month (tiered discounts beyond).
  
• Cross-Region Transfers: Data moving between regions (e.g., from us-east-1 to eu-west-1) typically runs $0.02–$0.09 / GB depending on source and destination.
  

For live rates see AWS EC2 On-Demand Pricing – Data Transfer section.

NAT Gateway (VPC Service)

NAT Gateway is $0.045 / GB processed + $0.045 / hour per gateway. Prices can vary by region.

We'll cover VPC networking services like NAT, Transit Gateway, VPN, etc., in a dedicated "Networking Services" deep dive.

Public IPv4 / Elastic IP charges

Since 1 February 2024 every public IPv4 address, attached or unattached, costs $0.005 per hour (~$3.60 per month).
IPv6 addresses remain free.The old "first EIP on a running instance is free" rule no longer exists, so reclaim any addresses you don't truly need.

See AWS Public IPv4 Address Pricing for details.

Dedicated Host Fees & BYOL Licensing

If you opt for Dedicated Hosts (physical servers dedicated to your account), two cost components apply:

Dedicated Host Hourly Rate

You pay for the entire physical host, billed per second (60 second minimum), based on instance family and region. This charge applies regardless of how many instances you run on the host.

For details, see the EC2 Dedicated Hosts Billing documentation.

Host-Based License Costs

License included AMIs (e.g., Windows Server, SQL Server) incur additional software fees on top of the host rate, typically charged per vCPU hour. (Oracle is BYOL only on EC2.)

If you Bring Your Own License (BYOL), you can avoid these uplift fees and pay only the Dedicated Host rate instead.

For details, see the EC2 Dedicated Hosts Pricing page.

Purchase Side Optimizations

These levers live at the top of your cost-cutting pyramid—big savings, but they require upfront commitments or configuration in AWS.

On-Demand → Reserved Instances

Reserved Instances let you pre-pay for capacity over one or three years in exchange for steep discounts on on-demand rates.

How to do it manually:

1. In cost explorer or the AWS CUR, calculate your average on-demand hours per instance family over the past 3–6 months.
   
2. Decide between Standard RIs (up to 72% off, fixed family/OS/region) or convertible RIs (up to ~60% off, can swap families/OS).
   
3. Choose scope: Regional RIs apply discounts across AZs; Zonal RIs also reserve capacity in one AZ.
   
4. Pick your payment option: all upfront (max discount), partial upfront (balance), or no upfront (cash-flow friendly).
   
5. In the AWS console go to EC2 → Savings → Reserved Instances, select your options and purchase.
   
6. Track RI utilization in cost explorer's "Coverage" report. Aim for ≥80% usage.

Caveats:

• Underutilized RIs still incur full charges.
  
• Standard RIs can be modified for size, scope, or AZ, but cannot change family/OS/tenancy; Convertible RIs allow those broader exchanges.
  
• You'll need to monitor and adjust across accounts.

See the AWS EC2 Reserved Instances documentation for more information.

EC2-Specific Savings Plans

Savings Plans simplify long term discounts by committing to a steady $/hour spend.

How to do it manually:

1. Use cost explorer to find your average EC2 $/hour over the last quarter.
   
2. Choose EC2-specific savings plans for up to 72% off across sizes and families in a region.
   
3. Pick a one year or three year term and payment option (all, partial, or no upfront).
   
4. In the AWS console go to Savings Plans → Create Savings Plan, enter your commitment and buy.
   
5. Monitor "Utilization" and "Coverage" reports, aim keep utilization above 80% and adjust next term as needed depending on your risk appetite.

Caveats:

• You're billed for your committed spend, even if you use less.
  
• There's no capacity reservation.
  
• Accurate forecasting is critical.

See the AWS EC2 Savings Plans documentation for guidance.

Spot Capacity & Diversification

Spot Instances let you bid on unused EC2 capacity for up to 90% off, but can be interrupted.

How to do it manually:

1. In the EC2 console choose "Request Spot Instances" when launching, or go to Spot Requests → Request Spot Instances.
   
2. Set your max price (or use the default current spot price).
   
3. For larger fleets, go to EC2 Fleets → Create Fleet, list 4–6 instance types across 2+ AZs.
   
4. Select allocation strategy: capacity-optimized (fewer interruptions) or lowest-price (max savings).
   
5. Implement interruption handling (e.g. automation or ASG mixed-instances) to replace lost capacity.

Caveats:

• Spot can be reclaimed with ~2 min notice—your apps must tolerate interruptions.
  
• Fleets need diversification and ongoing tuning.

See the AWS EC2 Spot Instances documentation for details.

Move to Newer Generations

Upgrading generations often means better price/performance at the same (or lower) cost.

How to do it manually:

1. Use compute optimizer or DescribeInstances + filtering to find instances >2 generations old.
   
2. Compare on-demand rates on the EC2 on-demand pricing page or via the pricing API.
   
3. Stop the old instance, change its type to the new generation in the console (or launch a new one from the same AMI).
   
4. Verify your workload runs correctly, then terminate the old instance.

Caveats:

• Ensure AMI compatibility (Arm vs x86).
  
• Performance gains vary by workload.

See the EC2 Instance Types page for generation specs.

New MSP / Reseller Sharing Rules (effective 1 June 2025)

AWS will block cross customer pooling of RIs and Savings Plans by resellers and MSPs.
Normal discount sharing within your own AWS Organization continues unchanged; the rule only blocks cross customer pooling by resellers/MSPs.
If you rely on a partner's shared pool, plan to purchase commitments in each end customer account before the cutoff date.

How to do it manually:

1. In Cost Explorer or your CUR, group RI/SP coverage by "Owner" vs "Usage" account.
   
2. Identify mismatches where an account is consuming a reservation it doesn't own.
   
3. Either share the reservation to the correct account or repurchase it in that account.
   
4. Tag accounts and set IAM guardrails so future purchases go to the right place.
   
5. Audit monthly to catch any drift.

Caveats:

• Sharing preferences only take effect on your month end bill, changes made mid month apply next cycle.
  
• Only the management account can toggle sharing; you'll need org-level permissions.
  
• Deactivating sharing can temporarily bump your bill if you haven't repurchased in each child account.

See the AWS RI & Savings Plans discount sharing docs for full details.

Dedicated-Host Reservations & BYOL

Dedicated Hosts give you physical server isolation plus license flexibility.

How to do it manually:

1. In the EC2 Console under "Dedicated Hosts", allocate hosts by family and count.
   
2. Choose a one year or three year reservation and payment option.
   
3. Launch or move your instances onto the dedicated hosts via the launch wizard.
   
4. For BYOL, pick AMIs that use your own Windows, SQL or Oracle licenses to avoid uplift fees.
   
5. Monitor host utilization and license usage in the Dedicated Hosts dashboard.

Caveats:

• You pay for the full host, even if you run few instances.
  
• Inefficient packing wastes capacity.

See the EC2 Dedicated Hosts pricing page for more details.

Utilization Optimizations

These optimizations reduce waste on instances you already run. No upfront commitments, just better tuning.

Rightsizing & Over Provision Detection

Rightsizing aligns your instance sizes with actual usage to avoid paying for idle capacity.

How to do it manually:

1. Open the AWS compute optimizer console and view your EC2 instance recommendations.
   
2. Identify instances where average (p95) CPU utilization is under 40% (and memory under 40% if you've installed the CloudWatch agent).
   
3. For each candidate, launch a test instance one size down (for example, m6g.large → m6g.medium) and run your workload.
   
4. If performance holds, update your auto scaling group or launch templates to the smaller size and terminate the old instance.

Caveats:

• Compute optimizer uses the last 14 days of metrics by default.
  
• You'll need the CloudWatch agent for memory metrics.
  
• Your workloads might have bursty spikes not captured in p95.

See AWS Compute Optimizer documentation.

Idle Instance Shutdown & Scheduling

Stopping instances when they're idle saves money on runtimes you don't need.

How to do it manually:

1. Tag non-production instances.
   
2. Deploy the AWS instance scheduler solution per the implementation guide.
   
3. In the scheduler's DynamoDB table, define your operating hours (e.g. Mon–Fri 08:00–18:00).
   
4. The scheduler automatically starts and stops tagged instances based on your defined windows.

Alternative: Use CloudWatch alarms (CPU < 5% AND NetworkIn+NetworkOut < 5% for 7 days) and an EventBridge rule to invoke a Lambda that stops the instance.
Alternative: Many customers now prefer the Systems Manager "Resource Scheduler" quick setup or EventBridge Scheduler because they avoid running a dedicated stack.

Caveats:

• You'll need to ensure critical batch jobs or stateful processes aren't disrupted.
  
• You'll still incur EBS storage fees for stopped instances.

See Instance Scheduler on AWS.

Burstable (T*) Credit Management

Burstable instances earn CPU credits when idle and spend them when they burst. Managing credits avoids throttling or surprise charges.

How to do it manually:

1. In CloudWatch, view the CPUCreditBalance metric for each t2, t3, or t4g* instance and alarm when credits run low.
2. Create a CloudWatch alarm when credit balance falls below a threshold (for example, 25% of the instance's max credits).
   
3. Decide whether to switch the instance to unlimited mode (which can incur surplus credit charges) or migrate to a fixed CPU instance.
   
4. Update the instance's credit specification in the EC2 console.

Caveats:

• You'll incur charges when credits are overspent in unlimited mode.
  
• Your CPU will be throttled once credits deplete in standard mode.
  
• Your credit patterns will vary by workload.

See Monitoring CPU credits for burstable instances.

Auto Scaling Group Tuning

Optimizing Auto Scaling Groups ensures you run just the right number of instances for your load.

How to do it manually:

1. In the EC2 console, navigate to auto scaling groups and review each group's min, desired, and max values.
   
2. Check CloudWatch metrics (CPU, network, request count) against current desired capacity.
   
3. Adjust min and desired to cover your baseline plus a safety buffer (for example, baseline x 1.2).
   
4. Enable scale in protection for critical instances and set an appropriate cooldown period.

Caveats:

• Your application might starve if the min setting is too low.
  
• You might see launch/terminate thrashing with short cooldowns.
  
• Your instance types will have varying warm up times.

See EC2 Auto Scaling Groups documentation.

Instance Hibernation for Dev/Test

Hibernation saves the in memory state of an instance to EBS so you can stop and resume without losing context.

How to do it manually:

1. When you hibernate an instance, any instance store volumes are lost.
   
2. Linux instances: hibernation is supported only when RAM ≤ 150 GiB.
   
3. Windows instances: hibernation is supported only when RAM ≤ 16 GiB.
   
4. Start the instance when needed; it will restore its previous RAM state.
   

Caveats:

• You'll incur storage costs when hibernation writes RAM to EBS.
  
• You'll need to check if your instance type and AMI support hibernation.
  
• You'll need to wait a few minutes for resume.

See Hibernate your Amazon EC2 instance.

Networking & Data Transfer Optimizations

These optimizations help you cut EC2 network fees and improve traffic locality without diving into full VPC services, which we'll do in a separate article.

Cross-AZ Data Transfer Hotspots

Data between AZs costs ~$0.02/GB, so high cross-AZ traffic can add up.

How to do it manually:

1. Enable VPC Flow Logs for your subnets or ENIs.
   
2. In cost explorer, filter costs by "Data Transfer" and group by source/destination AZ.
   
3. Identify instances or services moving large volumes across AZs.
   
4. Where possible, colocate related instances in the same AZ or use placement groups (see below).

Caveats:

• If you run instances in multiple AZs for redundancy or active-active setups, you'll incur cross-AZ transfer costs by design.
  
• Flow Logs incur CloudWatch or S3 charges.

See VPC Flow Logs for setup details.

Unused Elastic IPs

Elastic IPs attached to stopped or no instances incur ~$0.005/hour.

How to do it manually:

1. In the EC2 console, go to "Elastic IPs."
   
2. Filter for EIPs with "association: none" or attached to stopped instances.
   
3. Release any you don't need or reassign to active instances.

Caveats:

• You may want to reserve an EIP for failover, so double-check before releasing.
  

See Elastic IP Address pricing.

NAT Gateway vs NAT Instance & IPv6-Only VPCs

NAT Gateways are convenient but start at ~$0.045/GB + $0.045/hr, some regions are higher. NAT Instances trade bandwidth fees for instance hours. IPv6-only VPCs eliminate NAT.

How to do it manually:

1. Check your NAT Gateway data in Cost Explorer (filter by "NatGateway").
   
2. If data volumes are low, consider replacing NAT Gateway with an appropriately sized NAT instance (pick an instance class that matches your sustained throughput (e.g., t4g.small ~250 Mbps, c6g.large ~1 Gbps). Benchmark before cut over.
   
3. For new workloads that don't need IPv4, launch in an IPv6-only subnet to bypass NAT entirely.

Caveats:

• NAT instances require patching and high-availability setup (e.g., auto scaling).
  
• IPv6 adoption may require application changes.

See NAT Gateway pricing. We'll cover VPCs in more detail in an upcoming post.

Placement Groups & Traffic Locality

Placement Groups keep instances close together to reduce latency and cross-AZ charges. There are three modes:

• Cluster mode:
  Packs instances into a single rack in one AZ for the lowest network latency and highest throughput. Ideal for HPC, big data, or any workload that needs very fast instance to instance communication.

• Spread mode:
  Places each instance on distinct hardware racks, and can span multiple AZs. Best for small numbers of critical instances (up to 7 per group per AZ) that need isolation to minimize simultaneous failures.

• Partition mode:
  Divides a group into logical "partitions", each spread across racks in an AZ. You choose the number of partitions (up to 7 per AZ), and AWS ensures that instances in different partitions don't share rack infrastructure. Great for large distributed systems that need both performance and AZ level isolation.

Note on placement groups: A cluster placement group keeps instances in the same rack within a single AZ. Great for low latency, but it doesn't reduce cross-AZ data transfer fees. You avoid those charges simply by keeping communicating resources in the same AZ.

How to do it manually:

1. In EC2, create a placement group (cluster, spread, or partition).
   
2. Launch or move EC2 instances into that group via the launch wizard.
   
3. For cross-instance communication (e.g., HPC or high throughput apps), choose cluster mode; for high availability, use spread or partition.

Caveats:

• Cluster mode doesn't span AZs (only one AZ).
  
• Spread mode limits you to 7 instances per group.
  
• Misusing a PG can lead to launch failures if capacity is scarce.

See Placement Group documentation.

Modern AWS & Third Party Tooling

AWS Cost Optimization Hub

Cost Optimization Hub aggregates recommendations from Compute Optimizer, Trusted Advisor, and other sources.
Hub itself is free, but some advanced checks need a higher support tier.

See the Cost Optimization Hub User Guide.

AWS Trusted Advisor & Compute Optimizer

Trusted Advisor offers real-time checks for RI/SP coverage, idle instances, and low utilization, while Compute Optimizer provides rightsizing guidance based on actual usage patterns. Together they cover most utilization-driven savings without leaving the AWS console (Business/Enterprise support required for full access).

See Trusted Advisor Cost Optimization checks and Compute Optimizer documentation.

FinOps-Friendly OSS/SaaS

The third party ecosystem fills gaps around multi cloud visibility, detailed chargeback, and automated remediation:

• Karpenter: Dynamic node provisioning for Kubernetes clusters
• nOps: CI/CD–style cost and compliance guardrails
  
• CloudZero: Per-resource cost analytics
  
• CloudHealth: Enterprise FinOps workflows and reporting
  
• ParkMyCloud: Automated resource parking
  
• North: Specialized in RI/SP coverage analytics and marketplace optimization
  

Use these alongside AWS tools to round out your cost optimization strategy.

Step-by-Step Implementation Blueprint

Once you've armed yourself with the cost saving levers above, here's how to turn them into real, repeatable results:

1. Audit current usage & spend

   • Pull your cost and usage report (CUR) or cost explorer data.
     
   • Break out spend by instance family, purchasing option, and key metrics (CPU, storage, network).

2. Quantify potential savings per tactic

   • Map each optimization (rightsizing, RI/SP, spot, etc.) to $/month saved.
     
   • Prioritize by impact vs. effort, for example, start with orphaned volumes or idle instances.

3. Remediate with scripts or console changes

   • Run one off CLI commands or CloudFormation scripts to stop idle instances, resize volumes, purchase RIs, etc.
     
   • Coordinate with your DevOps team to apply changes in non-prod first, then prod.

4. Automate via your SaaS checks

   • Schedule regular scans (daily or weekly) for each rule (rightsizing, under utilized RIs, spot diversity, etc.).
     
   • Surface only the top priority recommendations in your dashboard or via alerts.

5. Monitor & iterate (the FinOps loop)

   • Track "actual savings realized" vs. "remaining opportunity".
     
   • Adjust thresholds, add new checks, and revisit your roadmap each quarter.

Pro tip: Prefer to skip the manual steps? Infralyst can assume a read only role in minutes, flag any oversized instances described in this guide, and drop a ready to merge Terraform pull request for the highest ROI fix. No scripts, spreadsheets, or console spelunking required.

Conclusion

EC2 costs aren't a mystery, they're a mix of compute hours, storage, networking, and a handful of addons. By systematically applying the purchase side discounts (RIs, Savings Plans, Spot) and utilization side tweaks (rightsizing, scheduling, credit management), then tackling storage and networking waste, you can routinely cut 30–50% off your bill.

Follow the five step blueprint above to audit, quantify, remediate, automate and iterate, whether you do it by hand or let Infralyst run the checks for you. Start today, and turn your next AWS invoice into a clear path of measurable savings.