AWS Cost Optimization: 20 Strategies for Enterprise Buyers in 2026

AWS remains the world's largest public cloud provider, and for most enterprises it is also their largest or second-largest cloud spend. The challenge with AWS cost optimisation at enterprise scale is not a shortage of strategies — AWS itself publishes extensive well-architected guidance on cost efficiency. The challenge is prioritisation: which strategies deliver the most impact for your specific workload profile and commercial position.

This article presents 20 AWS cost optimisation strategies organised by category, with a priority matrix to help you identify where to start. For the broader FinOps framework across all cloud providers, read our Cloud Cost Optimization Enterprise FinOps Guide.

AWS Cost Landscape for Enterprise Buyers

Before optimising, understand where your AWS spend is concentrated. For most enterprises, five service categories account for 75–85% of total AWS spend: EC2 compute (35–45%), RDS and managed databases (15–20%), S3 and other storage (10–15%), data transfer and egress (5–10%), and support and support-tier fees (3–5%). The remaining 15–25% covers dozens of other services.

This concentration means that optimisation initiatives targeting EC2 and RDS will deliver the majority of savings. Strategies targeting the long tail of services — while sometimes delivering meaningful savings in specific contexts — should generally wait until the high-impact categories are addressed.

Compute Cost Strategies (1–7)

// Strategy 01 Compute Savings Plans as Your Primary Commitment Vehicle

Compute Savings Plans are the most flexible commitment discount mechanism AWS offers — they apply to any EC2 instance type, family, region, or operating system in exchange for a committed $/hour spend over 1 or 3 years. They provide up to 66% discount versus on-demand pricing. For most enterprise workloads, Compute Savings Plans should be the first commitment purchase because their flexibility accommodates changes in instance type and region over the commitment period.

Target coverage: 70–75% of your predictable baseline compute spend with Compute Savings Plans. The remaining 25–30% stays on-demand to absorb peaks and provide flexibility for rightsizing without stranding commitments.

// Strategy 02 EC2 Instance Savings Plans for Stable, Instance-Specific Workloads

For workloads locked to specific instance families (typically large databases, SAP HANA, or specialised compute), EC2 Instance Savings Plans commit to a specific instance family in a specific region and provide up to 72% discount — slightly better than Compute Savings Plans. Use Instance Savings Plans as a complementary layer on top of Compute Savings Plans for your most stable, instance-specific workloads.

// Strategy 03 Systematic Rightsizing with Compute Optimizer

AWS Compute Optimizer analyses CloudWatch metrics to identify over-provisioned instances and recommends alternative instance types or sizes. It is free to use and covers EC2, ECS on Fargate, Lambda, and EBS volumes. Implement a monthly rightsizing sprint: review Compute Optimizer recommendations, have engineering owners validate the safety of each recommendation, and execute changes for approved instances within 30 days.

A common blockers to rightsizing is the absence of clear ownership. Without a named owner per instance, recommendations sit unactioned. Tagging every instance with an engineering team owner and distributing Compute Optimizer recommendations to owners directly is more effective than reviewing centrally.

// Strategy 04 Spot Instances for Fault-Tolerant Workloads

EC2 Spot Instances use AWS's spare compute capacity at discounts of 50–90% versus on-demand pricing. The trade-off is a 2-minute interruption notice when AWS needs the capacity back. This makes Spot appropriate for fault-tolerant workloads: batch processing, data analytics, CI/CD pipelines, containerised microservices with proper shutdown handling, rendering, and scientific computing.

Spot is not appropriate for stateful applications, databases, or any workload that cannot handle interruption. But for organisations with significant batch or analytics workloads — common in financial services, retail, and technology companies — Spot can generate $1M+ in annual savings with relatively modest engineering investment in interruption handling.

// Strategy 05 Graviton Migration for Applicable Workloads

AWS's Graviton3 and Graviton4 ARM-based processors offer 10–40% better price-performance than equivalent x86 instance types for many workloads. Graviton instances run Linux-based workloads and are particularly well-suited for containerised applications, web servers, databases (particularly PostgreSQL and MySQL), and Java applications. Before migrating production workloads, test application compatibility — most modern Linux applications are Graviton-compatible, but some dependencies may require updates.

// Strategy 06 Automated Non-Production Environment Scheduling

Development, test, and staging environments typically run 24/7 but are only used during business hours. Implementing automated start/stop schedules using AWS Instance Scheduler or similar tooling reduces non-production compute costs by 60–70%. For a typical enterprise with non-production environments representing 20–30% of EC2 spend, this translates to a 12–21% reduction in total EC2 costs with no impact on production availability.

// Strategy 07 Serverless Migration for Event-Driven Workloads

Lambda and Fargate eliminate the idle cost of perpetually running EC2 instances for workloads that are event-driven or intermittently utilised. API backends, data processing triggers, scheduled jobs, and webhook handlers are strong Lambda candidates. At enterprise scale, the economics of serverless versus persistent compute depend heavily on invocation volume — Lambda is not always cheaper than EC2 for high-throughput workloads, but for intermittent workloads the cost reduction can be 80%+.

Storage Cost Strategies (8–11)

// Strategy 08 S3 Intelligent-Tiering for Mixed-Access Data

S3 Intelligent-Tiering automatically moves objects between access tiers based on access patterns, eliminating the need to predict access frequency for lifecycle policy configuration. For mixed-access data (some objects frequently accessed, others rarely), Intelligent-Tiering typically reduces storage costs by 20–40% versus S3 Standard. The per-object monitoring cost is nominal at $0.0025 per 1,000 objects, making it appropriate for buckets with 10,000+ objects.

// Strategy 09 S3 Lifecycle Policies for Predictably Ageing Data

For data with predictable access patterns — application logs, backup files, audit data — S3 Lifecycle policies transition objects to cheaper storage classes (S3 Standard-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval) based on age. A typical lifecycle policy for log data: Standard for 30 days → Standard-IA for 30–90 days → Glacier Instant Retrieval for 90–365 days → Glacier Flexible Retrieval beyond 365 days. This can reduce storage costs for archival data by 70–85% versus keeping everything in Standard.

// Strategy 10 EBS Volume Right-Sizing and Type Optimisation

EBS (Elastic Block Store) volumes incur charges whether attached to running instances or not, and volumes are often over-provisioned to avoid disk-full events. Review EBS volume utilisation via CloudWatch — volumes at less than 50% utilisation for 30 days are candidates for reduction. Also review volume type: gp2 volumes can often be migrated to gp3 at no performance difference but with cost savings of 20%, and io1/io2 volumes should be reviewed to confirm whether the provisioned IOPS level is actually required.

// Strategy 11 S3 Request Cost Optimisation

For high-traffic applications, S3 request costs (per PUT, GET, and LIST operation) can be significant. Using S3 Transfer Acceleration where justified, CloudFront as a caching layer to reduce S3 GET requests, and batching small objects to reduce per-request overhead are the primary request cost reduction techniques. Review the S3 request costs in your Cost and Usage Report — for data-intensive applications, request costs can exceed storage costs.

Database Cost Strategies (12–14)

// Strategy 12 RDS Reserved Instances

RDS Reserved Instances provide 40–60% discounts on managed database costs for 1-year or 3-year commitments. Unlike EC2 instances, RDS workloads tend to be extremely stable — the database for a production application rarely changes instance type or region. This makes RDS RIs a high-confidence commitment with minimal risk of stranding. Purchase RDS RIs for any production database that has been running consistently for 90+ days.

// Strategy 13 Aurora Serverless v2 for Variable Database Workloads

Aurora Serverless v2 automatically scales compute capacity up and down in response to actual workload demand, billing only for the capacity used. For databases with significant day/night or weekday/weekend variation in load, Aurora Serverless v2 can reduce database costs by 30–50% versus provisioned Aurora with equivalent peak capacity. Development and staging databases are almost always better served by Aurora Serverless than provisioned instances.

// Strategy 14 RDS Storage Autoscaling and Type Review

RDS storage is charged per GB-month regardless of utilisation. Enabling RDS Storage Autoscaling eliminates the need to over-provision for future growth, but also review existing overprovisioned databases: a database provisioned at 5TB but using 1.2TB is paying for 3.8TB of unused storage. For databases where storage reduction is not straightforward, at least ensure you are on the most cost-effective storage type (gp3 for most workloads rather than io1).

Networking and Egress Strategies (15–17)

// Strategy 15 Data Transfer Architecture Review

AWS charges for data transferred out of AWS to the internet ($0.09/GB for the first 10TB/month, declining at volume) and for data transferred between regions (varies). These charges can represent 5–10% of total AWS spend for data-intensive applications. Review your architecture for high-egress patterns: are analytics workloads pulling large datasets from AWS to on-premise BI tools? Are multi-region applications replicating more data than necessary? Can CloudFront reduce origin data transfer by caching at the edge?

// Strategy 16 VPC Endpoint Adoption

NAT Gateway charges ($0.045/GB processed plus hourly fees) accumulate rapidly for workloads in private subnets that access AWS services. Using VPC Endpoints for S3 and DynamoDB — which route traffic through the AWS private network rather than through NAT Gateways — eliminates NAT Gateway processing charges for those services entirely. For applications with high S3 traffic from private subnets, VPC Endpoint adoption can reduce monthly networking costs by thousands of dollars.

// Strategy 17 Negotiate Egress Fee Waivers in EDP

AWS's Enterprise Discount Program is the commercial lever for addressing data transfer costs at scale. EDP negotiations can include reduced data transfer rates or data transfer fee caps as part of the overall package. For enterprises with $1M+ annual egress costs, negotiating egress terms within the EDP is one of the highest-value commercial levers available. Our guide to AWS EDP negotiation covers the tactics for including egress terms.

Commercial and Governance Strategies (18–20)

// Strategy 18 AWS Enterprise Discount Program Negotiation

The AWS Enterprise Discount Program (EDP) is a private pricing agreement that provides discounts across AWS services in exchange for a committed annual spend. EDP is available to enterprises with $1M+ annual spend and negotiated through the AWS account team. Initial EDP proposals typically offer 5–10% discount; well-prepared buyers with benchmarks and alternatives consistently achieve 12–20% or more.

Key EDP negotiation elements: discount tier and structure, commitment baseline and growth ramp, Marketplace inclusion (critical for large Marketplace buyers), support cost treatment, and how private pricing agreements for specific services interact with the EDP. Starting EDP negotiations 6–9 months before your current commitment expires maximises leverage. See our AWS EDP negotiation guide for the complete playbook.

// Strategy 19 AWS Support Tier Optimisation

AWS Enterprise Support pricing is a percentage of monthly AWS spend (with minimum charges). For large AWS spends, Enterprise Support is mandatory for technical account manager access and mission-critical response SLAs — but the support fee itself is negotiable within the EDP framework. We routinely negotiate Enterprise Support caps or reduced percentage rates as part of EDP discussions. For smaller AWS footprints, review whether Business Support is adequate versus the Enterprise tier premium.

// Strategy 20 Consolidated Billing and Savings Plan Sharing

AWS Savings Plans and Reserved Instances apply to the consolidated billing family when organisations use AWS Organizations. This means unused commitment capacity from one account can be applied to on-demand usage in another account within the organisation. Many enterprises have multiple AWS accounts (production, development, business units) but have not enabled consolidated billing, resulting in each account purchasing its own, sub-optimal commitments. Enabling consolidated billing and centralising commitment portfolio management in the master payer account is a zero-cost, high-impact optimisation.

Priority Matrix: Where to Start

Strategy	Effort	Typical Savings	Time to Value	Start Priority
Compute Savings Plans (#1)	Low	15–25% of EC2 spend	Immediate	Week 1
Non-Production Scheduling (#6)	Low	60–70% of non-prod EC2	1–2 weeks	Week 1–2
RDS Reserved Instances (#12)	Low	40–60% of RDS spend	Immediate	Week 2
Consolidated Billing (#20)	Low	Unlock existing savings	1 week	Week 1
Rightsizing via Compute Optimizer (#3)	Medium	8–15% of compute spend	4–8 weeks	Month 1
S3 Lifecycle and Intelligent Tiering (#8–9)	Low–Med	20–40% of S3 spend	2–4 weeks	Month 1
EDP Negotiation (#18)	High	8–20% of total AWS spend	3–6 months	Quarter 1
Spot Instances (#4)	High	50–90% of eligible compute	4–12 weeks	Quarter 1–2

Next Steps

The most effective AWS cost optimisation programmes combine quick wins (Savings Plans, non-production scheduling, consolidated billing) executed in the first 30 days with a structured programme of medium-term initiatives (rightsizing, storage optimisation, architectural improvements) and a parallel commercial negotiation track targeting EDP terms.

• Read the full Cloud FinOps Enterprise Guide for the complete framework
• See our dedicated AWS EDP Negotiation guide for the commercial strategy
• Explore Reserved Instances vs. Savings Plans to optimise your commitment strategy
• Review our $6M AWS savings case study for a real-world example
• Contact our AWS advisory team for an independent cost review