AWS makes it easy to start small and grow fast, and just as easy for costs to outpace the business. Test instances become a fleet, a proof-of-concept database runs for a year, and nobody knows who owns the largest line on the bill.
Cost optimization is a set of habits, not a one-off clean-up. This checklist runs from quick wins you can start this week to longer-term work that changes how your organization decides on cloud spend.
Step 1: Get visibility first
You cannot optimize what you cannot attribute. Before cutting anything, make sure spend can be traced to a team, service and environment.
- Define a tagging standard. Agree on a small set of required tags, such as
team,service,environmentandcost-center, and document the allowed values. - Activate cost allocation tags. Tags only appear in billing tools after you activate them in the Billing and Cost Management console. Activation is not retroactive, so do it early.
- Enforce tags in code. Apply tags through infrastructure as code and use tag policies in AWS Organizations or policy checks in CI to catch untagged resources.
- Set up AWS Budgets. Create budgets per account or per team with alerts at sensible thresholds, sent to the people who can act on them.
- Turn on Cost Anomaly Detection. It learns your normal spending patterns and alerts on unusual spikes.
- Export detailed billing data. Use Cost Explorer for day-to-day questions and the Cost and Usage Report (via AWS Data Exports) when you need line-item detail for dashboards or chargeback.
Step 2: Quick wins
Once you can see where money goes, some savings are almost free to capture.
Clean up idle and orphaned resources
- Unattached EBS volumes left behind after instances were terminated
- Old EBS snapshots and AMIs nobody will restore
- Idle load balancers, unused Elastic IP addresses and stopped instances with attached storage
Rightsize over-provisioned resources
Many resources are sized for a peak that never arrives. AWS Compute Optimizer analyzes utilization metrics and recommends better-fitting instance types for EC2, Auto Scaling groups, EBS volumes and Lambda functions.
- Review CPU and memory utilization over a representative period before downsizing. Memory metrics on EC2 require the CloudWatch agent.
- Consider newer instance generations and AWS Graviton (Arm-based) instances, which AWS positions as offering better price performance for many workloads. Test compatibility first.
- Migrate EBS
gp2volumes togp3, which lets you provision IOPS and throughput independently of size.
Schedule non-production environments
Development, QA and staging environments rarely need to run nights and weekends. The Instance Scheduler on AWS solution, simple Lambda functions, or scaling Auto Scaling groups and node groups to zero can all do this.
Step 3: Commit to what you use
After rightsizing, your steady-state usage is clearer. That is the right time to buy commitments, not before.
- Savings Plans offer lower prices in exchange for committing to a consistent amount of compute usage (measured in dollars per hour) over one or three years. Compute Savings Plans apply across EC2 instance families, Regions, Fargate and Lambda. EC2 Instance Savings Plans offer deeper discounts but are tied to an instance family in a Region.
- Reserved Instances remain relevant for services not covered by Savings Plans, such as Amazon RDS, ElastiCache, OpenSearch Service and Redshift.
Commit to a baseline you are confident will persist, not your current peak. Review coverage and utilization monthly in Cost Explorer, and layer additional commitments as usage grows.
Step 4: Use Spot and autoscaling where they fit
Spot Instances
Spot Instances use spare EC2 capacity at a steep discount compared to On-Demand, but AWS can reclaim them with a two-minute interruption notice. They suit workloads that tolerate interruption:
- CI/CD build runners and test jobs
- Batch processing, data pipelines and rendering
- Stateless web or worker tiers behind a load balancer, mixed with On-Demand capacity
- Kubernetes worker nodes for fault-tolerant pods
Diversify across several instance types and Availability Zones, and use capacity-optimized allocation to reduce interruptions. Keep stateful databases and single points of failure off Spot.
Autoscaling
Scale capacity with demand rather than provisioning for the peak around the clock. Use target tracking policies on EC2 Auto Scaling groups and ECS services, and in Kubernetes, pair the Horizontal Pod Autoscaler with a node autoscaler such as Karpenter or Cluster Autoscaler.
Step 5: Manage storage and data transfer
Storage lifecycle policies
- S3 lifecycle rules move objects to cheaper tiers (Standard-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive) as they age, and expire objects you no longer need.
- S3 Intelligent-Tiering moves objects between access tiers automatically when access patterns are unpredictable.
- Clean up incomplete multipart uploads and old object versions in versioned buckets.
- Use Amazon Data Lifecycle Manager to create and expire EBS snapshots on a schedule instead of letting them accumulate.
- Set retention periods on CloudWatch Logs groups. The default is to keep logs indefinitely.
Data transfer and NAT gateways
Data transfer is one of the least visible costs on an AWS bill. Common sources include:
- NAT gateways, which charge per hour and per gigabyte processed. Traffic from private subnets to S3 or DynamoDB is a frequent culprit. Gateway VPC endpoints for those two services carry no additional charge and keep that traffic off the NAT gateway.
- Cross-AZ traffic between services that chat heavily. Keep high-volume paths within one Availability Zone where your availability requirements allow.
- Internet egress, which a CDN such as CloudFront can reduce by caching content closer to users.
Step 6: Weigh managed-service trade-offs
Managed services such as RDS, Aurora, Fargate, and serverless options often cost more per unit of compute than running the equivalent yourself on EC2. They also remove patching, backups, failover and capacity planning from your team’s workload.
Compare total cost of ownership, including engineering time and operational risk, not just the line item. A high-volume, stable workload may be cheaper on provisioned capacity than on per-request pricing. Revisit the decision as usage changes.
Step 7: Make Kubernetes costs visible
On Amazon EKS, the AWS bill shows EC2 instances, not the teams or applications running on them. Without extra work, Kubernetes becomes a shared cost nobody owns.
- Enable split cost allocation data for Amazon EKS in the Cost and Usage Report to attribute costs to namespaces and pods.
- Use a tool such as OpenCost or Kubecost for in-cluster cost visibility by namespace, workload and label.
- Set resource requests based on observed usage. Inflated requests reserve capacity that is paid for but never used.
- Consolidate underused nodes with Karpenter’s consolidation features.
Step 8: Build a FinOps practice
Tools find savings. A practice keeps them. FinOps is the operating model that makes cloud cost a shared responsibility between engineering, finance and product. The FinOps Foundation describes it as an iterative cycle of three phases: Inform, Optimize and Operate.
- Shared ownership. Engineering teams own the cost of the services they run. Finance provides forecasting, budgeting and reporting. Neither can succeed alone.
- Showback or chargeback. Show each team its own spend, trends and unit costs, such as cost per customer or per transaction, so decisions are grounded in business value rather than raw totals.
- A regular cadence. Hold a monthly cost review covering anomalies, commitment coverage, rightsizing recommendations and upcoming architecture changes.
- Cost in the delivery pipeline. Tools such as Infracost can estimate the cost impact of infrastructure-as-code changes in pull requests, so engineers see cost before they merge.
Common pitfalls
- Buying commitments before rightsizing, which locks in waste for one to three years.
- Treating cost as a finance-only problem, when most cost decisions are made in code and architecture.
- One-off clean-ups without the tagging, budgets and reviews that stop waste returning.
For an example of how cost controls are built into a migration from day one, see our retail AWS cloud migration blueprint.
Get a second opinion on your AWS bill
Our cloud services team helps growing companies set up cost visibility, rightsize workloads and plan commitments, and our DevOps consulting team builds cost checks into your pipelines and platform. If your AWS bill is growing faster than your business, talk to us and we’ll help you find where to start.
