AWS Cost Optimisation Strategies Explained: Reduce EC2, Data Transfer and Idle Spend

Simple explanation

AWS charges for what you provision and use. The problem is that “what you use” includes resources sitting idle, instances far too large for their actual load, data moving between services and regions, and logs written at full debug verbosity in production.

Cost optimisation comes down to three things:

• Removing waste. Stop or delete resources that are not earning their cost: idle instances, unattached storage, always-on dev environments, and forgotten snapshots.
• Matching resources to demand. Use smaller instances when workloads are light, scale automatically when they are not, and switch to event-driven patterns so you pay only for actual work.
• Choosing better pricing models. Commit to Savings Plans or Reserved Instances for predictable workloads, use Spot for fault-tolerant jobs, and use On-Demand only where flexibility is genuinely needed.

The result is a bill that reflects what your system actually does, not what you feared it might need.

How AWS cost optimisation works

Cost optimisation is not a one-time task. It works best as a repeating cycle:

1. Gain visibility. Use Cost Explorer to see where money is going by service, region, and tag. You cannot optimise what you cannot see.
2. Identify waste. Find idle instances, unattached EBS volumes, unused load balancers, and forgotten snapshots using Identifying Expensive Resources and Cleaning Up Unused Resources.
3. Rightsize. Compare instance metrics against instance capacity using Rightsizing Instances and AWS Compute Optimizer recommendations.
4. Choose the right pricing model. Commit to Savings Plans or Reserved Instances for steady-state workloads once usage patterns are well understood.
5. Redesign where architecture is the cost driver. Replace polling with event-driven patterns, move background jobs to Lambda, and colocate services to reduce inter-AZ traffic.
6. Monitor continuously. Set budgets and billing alerts so unexpected spending triggers a notification rather than a surprise at month-end.

When to use this

Cost optimisation is relevant at every stage, but the priorities shift depending on where you are:

• Early-stage startups. The fastest wins are right-sizing (do not default to m5.xlarge for every service) and scheduling non-production shutdowns. These require no architecture changes and can be done in an afternoon.
• Growing teams with always-on environments. Development and staging environments running 24/7 are often the largest single source of avoidable spend. Scheduling them to stop outside business hours cuts their compute cost by 65%+ with no impact on developer productivity.
• Production systems with predictable baseline usage. Once a workload’s resource requirements are stable and well understood, switching from On-Demand to Savings Plans or Reserved Instances provides a 20–60% discount with no change to the workload itself.
• Event-driven or bursty workloads. If your system has long idle periods between bursts of activity, a polling-based architecture wastes most of its compute budget on doing nothing. Event-driven patterns eliminate that idle cost entirely.
• Teams seeing unexplained networking, logging, or storage costs. Inter-AZ traffic, NAT Gateway data processing, CloudWatch Logs ingestion, and unmanaged EBS snapshots are the usual culprits when costs feel higher than expected.

Highest-impact AWS cost optimisation strategies

Right-size compute, storage, and databases

Right-sizing means choosing the smallest resource that meets your actual performance requirements, not what you might need under worst-case conditions.

The common objection is “I don’t want to run out of capacity.” The answer is to design for elasticity rather than permanent over-provisioning:

• Deploy a t3.medium, apply realistic load, and watch CPU and memory in CloudWatch
• If utilisation runs consistently above 70–80%, size up or add Auto Scaling
• If utilisation is consistently low, downsize. The difference between an m5.xlarge and a t3.medium is roughly $110/month per instance

For a deeper look at EC2 rightsizing options and storage volumes, see EC2 Cost Optimisation and Rightsizing Instances.

Stop, schedule, or delete idle resources

Idle resources are the most straightforward source of waste. Common examples:

• Development and staging environments running overnight and at weekends when nobody is using them
• EC2 instances that are stopped but have EBS volumes still attached (EBS charges persist even when the instance is off)
• Unattached Elastic IPs (charged at a flat rate when not associated with a running instance)
• Old snapshots and AMIs kept indefinitely with no retention policy
• Load balancers provisioned for a project that was cancelled

Development and staging environments deserve specific attention. If they run only during business hours (roughly 8 hours/day, 5 days/week), they are active for about 40 of 168 hours per week, or about 24% of the time. Scheduling them to shut down outside those hours cuts their compute cost by 76%. AWS Systems Manager, Lambda scheduled events, and AWS Instance Scheduler can all automate this without manual effort.

See Cleaning Up Unused Resources for a practical checklist of what to look for and how to remove it safely.

Choose the right pricing model

The four EC2 pricing models serve different workload types. Using the wrong model for a workload type is one of the most common sources of unnecessary AWS spend. See the full comparison table below for a side-by-side breakdown.

For predictable workloads that run continuously, Savings Plans and Reserved Instances provide meaningful discounts over On-Demand. For fault-tolerant workloads with flexible timing, Spot Instances for Cost Savings can reduce costs by up to 90%. See AWS Pricing Models for a full explanation of how each model works and when to buy it.

Prefer event-driven, serverless, and managed services where they reduce total cost

Event-driven over polling

Polling repeatedly checks for new data and wastes compute on doing nothing. An EC2 instance checking an S3 bucket every 10 seconds runs 24/7 and makes 8,640 API calls per day, even when there is nothing to process.

Replacing it with a Lambda function triggered by S3 event notifications means:

• Zero compute cost when no files arrive
• Execution within milliseconds of a file landing
• You pay for actual invocation duration, not idle time

The same logic applies to SQS, DynamoDB Streams, and EventBridge. See Event-Driven Systems in AWS for patterns and worked examples.

For a worked comparison of when Lambda, ECS, and EC2 each make sense financially, see Choosing Between Lambda, ECS and EC2.

Managed services vs self-managed

A common instinct is to self-manage infrastructure to save money: “RDS is expensive, I’ll run MySQL on EC2.” This reasoning usually fails when you include the full cost:

• An EC2 instance comparable in size to RDS, before any operational extras
• A second EC2 instance for high availability standby
• Engineering time to configure replication, backups, patching, and monitoring
• On-call responsibility when the database fails at 3am

RDS Multi-AZ includes the standby, automated backups, minor version patching, and built-in metrics. The RDS premium pays for that operational overhead. For most teams, managed services cost less in total once engineering time is counted.

For Lambda-specific cost management, see Lambda Cost Optimisation.

Reduce data transfer, NAT, and logging costs

Data transfer is the most commonly underestimated cost category. The pricing model is asymmetric and non-obvious:

• Into AWS (ingress): Generally free
• Out to the internet (egress): Charged per GB. See Network Egress Costs for current reference rates and reduction techniques
• Between regions: Charged per GB
• Between Availability Zones in the same region: Charged each way
• Within the same AZ: Free

NAT Gateway charges on two dimensions: an hourly rate plus a per-GB data processing charge. Applications that route frequent external API calls through a NAT Gateway accumulate data charges quickly. For AWS services specifically (S3, DynamoDB, and others), use VPC endpoints to bypass the NAT Gateway entirely and eliminate that per-GB cost.

CloudWatch Logs ingestion and storage also compounds at scale. Debug-level logging in production generating gigabytes per day adds up. Set log levels appropriately and configure log retention policies to expire old logs automatically rather than retaining them indefinitely.

For S3 storage cost control, including storage class selection and lifecycle policies, see S3 Cost Optimisation.

Use AWS cost tools before guessing

Before making changes, use AWS’s own tooling to identify where the money is actually going:

• Cost Explorer shows spend broken down by service, region, linked account, and resource tag. It is the starting point for any cost investigation. See Cost Explorer Reports.
• AWS Compute Optimizer analyses CloudWatch metrics and recommends downsized or differently configured instances for EC2, RDS, Lambda, and EBS. It shows what resources are over-provisioned based on actual usage history.
• Trusted Advisor flags idle load balancers, underutilised instances, and unattached EBS volumes. Available for basic checks without a support plan upgrade.
• Cost Anomaly Detection monitors spend patterns and alerts when a service’s cost deviates significantly from its baseline. It catches runaway costs before month-end.

Set budgets and billing alerts so you are notified when spending exceeds a threshold. A budget alert that fires at 80% of your monthly target costs nothing and prevents surprises.

Savings Plans vs Reserved Instances vs Spot vs On-Demand

For most production workloads, Compute Savings Plans are the default best choice for committed spend. They give meaningful discounts while remaining flexible as architectures evolve. Reserve Reserved Instances for workloads you are confident will run in the same configuration for years. Use Spot only for workloads specifically built to handle interruption (the build can restart, the batch job retries from a checkpoint). Use On-Demand for anything new or variable until you have enough usage data to commit confidently.

See AWS Pricing Models for a fuller explanation of each model’s mechanics and the purchase process.

What this looks like in practice

A two-person startup launches on AWS, moving fast. Every service runs on m5.xlarge instances: the web app, background worker, bastion host, staging environment, and development environment. All On-Demand, all running 24/7.

Six months later the bill is $3,200/month for roughly 200 users.

The audit reveals:

• The web app server averages 4% CPU utilisation. An m5.xlarge has 4 vCPUs and 16 GB RAM, massively oversized for this load.
• The development environment runs overnight and at weekends when nobody is using it.
• The staging environment gets used for a few hours per week at most.
• The background worker does 15 minutes of work per hour and sits idle the other 45.

Fixes applied:

• Web server downsized to t3.medium (roughly $30/month On-Demand), more than enough for 200 users with room to grow
• Dev and staging put on scheduled shutdowns outside business hours
• Background worker replaced with Lambda, paying only for the 15 minutes of execution time per hour, not the 45 minutes of idle time

Monthly bill: $3,200 down to under $400.

None of these changes required a full architectural redesign. They required measuring what was actually happening and acting on it.

Quick checklist

Use this as a starting point for a cost audit:

• Open Cost Explorer and identify your top three cost drivers by service
• Check Identifying Expensive Resources and Compute Optimizer for rightsizing recommendations
• Find and delete idle resources: unattached EBS volumes, unused Elastic IPs, forgotten load balancers, old snapshots
• Schedule non-production environments to shut down outside business hours
• Review rightsizing opportunities for instances with consistently low CPU utilisation
• Evaluate Savings Plans for any steady-state compute spend over $200/month
• Check whether Spot Instances are viable for batch jobs or CI/CD build agents
• Inspect NAT Gateway data charges and assess whether VPC endpoints would reduce them
• Review network egress costs and look for inter-AZ traffic and unexpected internet egress
• Check CloudWatch Logs retention policies and log verbosity in production
• Set a billing alert for 80% and 100% of your monthly budget target
• Schedule a monthly cost review. Costs drift upward quietly without regular attention.