Amazon Web Services (AWS) is one of the most widely adopted cloud platforms in the industry, used by organisations of every size to run workloads ranging from small development environments to large-scale production systems. That popularity comes with a cost: without deliberate optimisation, AWS bills can grow significantly faster than the business value they deliver.
Cost optimisation is the discipline of achieving the required output at the lowest viable spend, using the right resources in the right configuration for each workload. In practice, it covers four broad areas:
- Cost-effective resources — selecting instance types and services that match workload requirements without over-provisioning.
- Matching supply with demand — scaling capacity up or down in response to actual load.
- Expenditure awareness — understanding where money is being spent and by whom.
- Optimising over time — continuously reviewing and improving cost posture as requirements change.
The eight techniques below map directly to these areas and are applicable to most AWS environments. They are not listed in order of priority — the right sequence depends on your specific workload and team maturity.
1. Attribute Provisioning
When you provision resources on AWS, it is easy to request more capacity than a workload actually needs. Attribute provisioning means continuously tuning the properties of your AWS managed services — compute, memory, storage, network throughput — so that they reflect current demand rather than a worst-case estimate made at launch time.
AWS exposes service attributes through the AWS Management Console, the AWS CLI, and the AWS SDKs. You can also pack multiple workloads onto a single resource to increase density and reduce idle capacity. Amazon CloudWatch is the primary tool for collecting and tracking the metrics you need to make informed provisioning decisions. Setting CloudWatch alarms on CPU, memory, and I/O utilisation gives you the data needed to right-provision resources proactively.
2. Right-Sizing
Right-sizing is the process of selecting the lowest-cost instance type or resource configuration that still meets the technical requirements of a workload. It is one of the highest-impact cost optimisation activities because many teams provision instances based on peak load projections or legacy assumptions rather than observed utilisation.
When conducting a right-sizing exercise, keep these principles in mind:
- Monitor end-user experience, not just infrastructure metrics. A downsized instance that causes latency regressions is not a successful optimisation.
- Weigh the cost of change against the savings. Some resizes require downtime or application restarts; factor that into your analysis.
- Choose an appropriate analysis window. Cover at least one full business cycle — daily, weekly, or monthly — to avoid optimising for an unrepresentative slice of traffic.
AWS services that support resizing include Amazon EC2 (compute), Amazon EBS (block storage volume types and sizes), and Amazon RDS (database instance classes). AWS also provides AWS Compute Optimizer, which analyses CloudWatch metrics and recommends right-sized instance types.
3. On-Demand Instances
On-demand instances let you pay for compute capacity by the hour or second with no long-term commitment. This flexibility makes them the right choice for:
- Short-term or unpredictable workloads where reserving capacity in advance would be wasteful.
- Development and testing environments where usage patterns are irregular.
- Applications being profiled before committing to a purchasing model.
On-demand is generally more expensive per unit of compute than Reserved or Spot instances, so it should be reserved for workloads that genuinely benefit from its flexibility. Once usage patterns become predictable, migrate those workloads to a more cost-effective purchasing option.
4. Spot Instances
AWS Spot instances provide access to spare EC2 compute capacity at a significantly reduced price compared to on-demand rates. The trade-off is that AWS can reclaim Spot instances with a two-minute warning when capacity is needed elsewhere, so workloads must be designed to tolerate interruption.
Spot instances are well suited to:
- Batch processing pipelines
- Scientific simulations and research workloads
- Image and video processing
- Financial modelling and analytics
- CI/CD test runners
- Big data processing with frameworks like Apache Spark or Hadoop
When using Spot instances, design for continuity: checkpoint progress regularly, use Spot Instance interruption notices to drain work gracefully, and diversify across multiple instance types and Availability Zones to reduce the probability of simultaneous reclamation. Mixing Spot and On-Demand capacity in an Auto Scaling group (using EC2 Fleet or Auto Scaling mixed instances policies) is a common production pattern.
5. Reserved Instances and Savings Plans
For predictable, steady-state workloads, committing to a one-year or three-year term in exchange for a discounted hourly rate is one of the most effective ways to reduce AWS spend. AWS offers two primary commitment models:
Reserved Instances (RIs)
- Standard Reserved Instances — provide a billing discount and optionally a capacity reservation when you specify an instance family, size, and Availability Zone. They offer the deepest discounts but the least flexibility.
- Convertible Reserved Instances — available on one-year or three-year terms; allow you to exchange the reservation for a different instance family, size, operating system, or tenancy during the term. Discounts are somewhat lower than Standard RIs but the flexibility is valuable as workloads evolve.
Savings Plans
AWS Savings Plans (Compute Savings Plans and EC2 Instance Savings Plans) offer a more flexible commitment model: you commit to a consistent amount of compute usage measured in dollars per hour, and the discount applies automatically across eligible services regardless of instance type, region, or operating system. For many teams, Savings Plans are simpler to manage than a portfolio of Reserved Instances.
6. Monitoring and Managed Services
Running and managing your own infrastructure on EC2 carries a hidden cost: the engineering time required to patch, scale, monitor, and maintain those servers. AWS managed services absorb much of that operational burden and often deliver lower cost per transaction at scale.
Examples include:
- Amazon RDS and Amazon Aurora — managed relational databases that handle patching, backups, and multi-AZ failover.
- Amazon DynamoDB — a fully managed NoSQL database with on-demand or provisioned capacity modes.
- AWS Lambda — serverless compute that charges only for the duration and memory of function invocations, eliminating idle compute costs.
- Amazon SQS, Amazon SNS, and Amazon SES — managed messaging and notification services that replace self-managed queues and email infrastructure.
Pair managed services with AWS Cost Explorer and AWS Budgets to track spending by service, team, or environment and receive alerts when costs exceed defined thresholds.
7. Optimise Data Transfer Costs
Data transfer is a frequently overlooked contributor to AWS costs. Charges apply for data leaving AWS to the internet, for cross-region transfers, and in some cases for cross-Availability-Zone traffic within a region. Strategies to minimise these costs include:
- Use Amazon CloudFront as a content delivery network (CDN) to cache and serve static and dynamic content close to end users. CloudFront’s data transfer pricing is lower than direct EC2-to-internet egress, and it reduces origin load.
- Colocate tightly coupled services in the same Availability Zone where possible to avoid cross-AZ data transfer charges.
- Use VPC endpoints for services such as S3 and DynamoDB to route traffic over the AWS backbone rather than over the public internet, which can eliminate some transfer charges.
- Compress data before transfer and use efficient serialisation formats to reduce the volume of data moving between services.
8. Turn Off or Schedule Unused Resources
One of the simplest and most impactful cost optimisation actions is stopping resources when they are not in use. Development, testing, and staging environments rarely need to run 24 hours a day, 7 days a week — yet many teams leave them running continuously.
Practical approaches include:
- Tag every resource with its environment (production, staging, dev) and owner so idle resources are easy to identify.
- Use AWS Instance Scheduler or Lambda-based automation to stop and start EC2 and RDS instances on a defined schedule — for example, running dev instances only during business hours on weekdays.
- Set idle timeouts for development databases and remove unused EBS volumes, unattached Elastic IPs, and idle load balancers — all of which accrue charges even when nothing is using them.
- Review and delete unused snapshots on a regular cadence; old EBS and RDS snapshots can accumulate significant storage costs over time.
Scheduling non-production resources to run only when needed can meaningfully reduce compute costs for those environments. The exact savings will depend on current utilisation patterns.
Bringing It All Together
AWS cost optimisation is not a one-time project — it is an ongoing engineering practice. Start by gaining visibility into where you are currently spending (Cost Explorer, AWS Cost and Usage Reports), then apply the techniques above in order of impact for your specific environment. Establish a regular review cadence — monthly at minimum — to catch cost regressions early and identify new optimisation opportunities as your architecture evolves.
Used together, these eight strategies can substantially reduce AWS spend without requiring a redesign of your core architecture. The biggest wins typically come from a combination of right-sizing, commitment-based pricing for stable workloads, and eliminating waste from resources left running unnecessarily.