AWS Cost Checklist — LeanerCloud

Section 1 of 7

Compute - EC2, ECS, Spot

Review on demand EC2 for stateless workloads - ones that hold no critical local state. Convert those to Spot, which is 60-70% cheaper, or to Lambda where the work is short and event-driven. Find EC2 instances paying full on demand rates that are covered by neither Spot, Savings Plans, nor Reserved Instances. Any instance running continuously is paying a premium it doesn't have to; cover it with a Compute Savings Plan or the appropriate RI. Pull CPU and memory usage over the last 30 days for each EC2 instance. Anything usually under 20-30% on both is over-provisioned; move it down one or two sizes and confirm nothing breaks. List every instance still on a previous-generation family - m4, c4, r4, and their siblings. Current-generation equivalents are faster, cheaper, and available right now; there's no good reason to stay on the old hardware. Check which x86 workloads have no hard dependency on Intel or AMD. Graviton is roughly 20% better on price/performance for the same workload; move anything portable and measure it. Identify t-family instances running at sustained high CPU over a rolling 2-week window. When a burstable instance earns and spends credits continuously, a fixed-size instance of equivalent capacity is almost always cheaper - check the CPU credit balance and cost side by side. Check every burstable instance for "unlimited" mode. In unlimited mode the instance draws on surplus credits and charges you for them quietly; if CPU is consistently high, either switch to a fixed-size instance or turn unlimited off. Look at standalone EC2 instances running long-lived services that have no strong reason to be on bare instances. Consolidating onto ECS or Fargate improves bin-packing and removes per-instance overhead you're paying whether the instance is busy or not. Review Fargate task definitions for vCPU and memory against actual CloudWatch usage. Fargate charges by what you declare, not what you use; trim each task definition to what the workload actually needs with a reasonable headroom margin. Identify EC2 instances in non-production environments that run around the clock. Scheduling them off on evenings and weekends - roughly 128 hours per week - cuts that bill by about 75% with no change to working hours.

Section 2 of 7

Storage - EBS, S3, EFS, snapshots

Compare each provisioned-IOPS (IO1/IO2) volume's actual IOPS and throughput against what it's provisioned for. Most sit far below the ceiling they pay for; move those to GP3, which includes 3,000 IOPS free and decouples IOPS from volume size. List every GP2 volume in your account and convert them to GP3. GP3 is cheaper per GB across the board and gives you 3,000 IOPS without having to oversize the volume to earn them, which is what GP2 requires. Find EBS volumes in the "available" state - not attached to any instance. You're paying for these in full whether anything is reading them or not; snapshot anything worth keeping and delete the volume. Check your snapshots and registered AMIs for the last time they were accessed or referenced. Anything no longer tied to a running instance or active deployment pipeline is probably orphaned; delete what you can't trace back to a purpose. Compare each volume's allocated size against the file system usage inside the instance. A volume at 500 GB with 80 GB in use is paying for 420 GB of nothing; resize the volume and file system to fit what's actually there. Use S3 Storage Lens or Storage Class Analysis to find buckets with large amounts of Standard-class objects that haven't been touched in weeks or months. Move infrequently accessed data to Intelligent-Tiering, Standard-IA, or Glacier depending on how often you realistically need it back. Check every S3 bucket used for logs, backups, or exports for a lifecycle policy. Without one, the bucket grows forever; add rules that transition to cheaper storage classes after a short period and expire objects after the longest window you actually need. Check what share of your EFS data is in the Standard tier versus Infrequent Access. Objects untouched for 30 days with no strict latency requirement are good candidates for IA; the price difference is significant and EFS can tier automatically with a lifecycle policy.

Section 3 of 7

Databases - RDS, Aurora, ElastiCache, OpenSearch

Pull CPU, memory, and connection metrics for each RDS and Aurora instance over the last 30 days. Instances consistently well below their headroom - low CPU, few connections, negligible memory pressure - are over-provisioned; move them down one or two sizes and verify application behavior. Check which RDS, ElastiCache, and OpenSearch instances are still on x86. Graviton equivalents are around 20% better on price/performance; the migration path is straightforward for most engines and the savings are immediate. For each Aurora cluster, work out what share of its cost is I/O. Above roughly 25%, I/O-Optimized is the cheaper mode; below it, standard is. Move each cluster to whichever side of that line it actually falls on, because the default is rarely the right one. Look at each Aurora Serverless v2 cluster's ACU usage over a few weeks. If it sits at a steady floor instead of scaling up and down, a right-sized provisioned instance of the same capacity is usually cheaper; Serverless only pays off for genuinely variable load. Look at RDS instances whose connection and query patterns are spiky or highly intermittent - dev tools, internal portals, batch pipelines that run once a day. Aurora Serverless v2 can scale to near-zero during idle periods and is often cheaper for anything that isn't continuously busy. Check every RDS and Aurora instance for connections and query activity over the last 30 days. Anything sitting near zero is a candidate to snapshot and delete, including instances still running for a product or customer that is gone. Check what engine version each RDS and Aurora instance is running. Older versions often can't use newer instance families or features with better price/performance; upgrading to a current supported version can unlock both. Check automated backup retention and manual snapshot counts for each database. Keeping 35 days of automated backups and dozens of manual snapshots for databases that have been replaced or shrunk is pure waste; set retention to what recovery actually requires and delete stranded manual snapshots. Review ElastiCache cluster memory and cache hit rate metrics. A cluster that's poorly used on memory, or whose hit rate wouldn't improve with more cache, is over-provisioned; size it down to where hits stay stable and memory headroom is reasonable. Identify ElastiCache clusters running Redis. Valkey is a drop-in compatible fork that AWS offers at a lower price; migrating is low-risk for most workloads and the savings are immediate. Check the CloudWatch Logs export configuration for each RDS instance. Exporting audit, error, and slow-query logs can generate large ingestion volumes; confirm you're only exporting log types you actually alert on or query, and that verbose logs aren't being shipped by default. Pull the Aurora I/O cost for clusters where it's a meaningful share of the bill, then look at the slow query log. A small number of full-table scans or missing indexes can account for a disproportionate share of read I/O; fixing the query often costs nothing and reduces storage charges more than changing the billing mode would. Check your OpenSearch domains for index age and query activity by index. If the last time anyone queried a 2-year-old index was also 2 years ago, those shards are using instance memory and storage for nothing; archive or delete old indices, then revisit whether the domain is still the right size for what remains.

Section 4 of 7

Networking

Map the traffic flow between your most data-heavy services and check whether they cross Availability Zones. AWS bills for cross-AZ data transfer both ways; services that talk constantly should be in the same AZ, or the transfer cost should be weighed against the availability benefit. Check whether any significant data flows cross region boundaries - replication, analytics pipelines, API calls between services in different regions. Cross-region transfer is expensive; check whether the traffic is intentional and whether consolidation or a closer deployment is feasible. Look at your NAT Gateway data-processing costs and identify what is flowing through it. Traffic to S3 or DynamoDB going via NAT is paying for processing that a gateway VPC endpoint would make free; check whether those endpoints exist and whether your route tables use them. Check the public IPv4 addresses across all your accounts and regions. AWS now charges per public IPv4 per hour whether the address is in use or not; release any that are unattached, and check whether services that need one genuinely can't use IPv6 or a load balancer instead.

Section 5 of 7

Monitoring and logs

Sort your CloudWatch log groups by ingested volume. For the largest, confirm the log level is right for production - debug left on is a common five-figure leak - and set retention to match what you actually query, rarely more than 30 to 90 days. Check where WAF and VPC flow logs are being delivered. Both can generate large volumes; ingesting them directly into CloudWatch Logs is far more expensive than routing to S3 with Athena on top. Move high-volume log sources to S3 and filter at the source where possible. Check the verbosity setting on active VPC flow logs. Full-verbosity logging captures every packet header and can generate substantial volume in busy VPCs; if you only need connectivity troubleshooting, sampling or filtering by action catches the important events at a fraction of the cost.

Section 6 of 7

Commitments - Reserved Instances and Savings Plans

Pull your compute spend and calculate what fraction of your on demand baseline is uncovered by any Savings Plan or RI. Any steady, predictable baseline that has run for more than a month and is still paying full on demand is leaving a 30-40% discount on the table; buy coverage for it. Check the expiration dates on every active RI and Savings Plan. Coverage that lapses goes straight back to full on demand pricing the day it expires; if renewals aren't in flight at least a few weeks out, start the process now. Review each RI for region, Availability Zone, and instance family match against your current deployments. RIs bought for a region you've moved out of, or for a family you've since rightsized away from, are wasted spend; sell them on the Marketplace or exchange them where possible. Check the usage rate on every active RI and Savings Plan. Commitments sitting below roughly 70% usage are costing you more in unused reservations than you're saving; understand why and either resize the commitment or redeploy workloads to consume it. Identify Convertible RIs tied to previous-generation instance families. Convertible RIs can be exchanged for current-generation equivalents without losing the remaining term; the newer families are faster and often cheaper per unit of compute. Measure actual Compute Savings Plan spend against what you've already committed. If your spend is consistently below your commitment, you're paying for coverage you can't use; if you're already above it, you have room to buy more at the discount rate.

Section 7 of 7

Serverless and the long tail

Check each Lambda function's configured memory against its actual peak usage in CloudWatch. Lambda charges by GB-second of memory times duration; a function allocated 1 GB that never uses more than 200 MB is paying several times more than necessary - find the right size by testing down incrementally. Check which Lambda functions are still on x86. Graviton (arm64) is available for Lambda and is better on price/performance for most general-purpose code; switching is a one-line config change and the savings are immediate for high-invocation functions. List every Lambda function with provisioned concurrency enabled and check its invoke rate and cold-start sensitivity. Provisioned concurrency is priced continuously whether the function is invoked or not; it only makes sense for strict latency requirements and genuinely high sustained load. Remove it from everything else. Check which dev and test environments have no automated shutdown. Environments left running continuously use the same compute and storage as production for workloads only needed during business hours; schedule them off or add stop automation keyed to inactivity. Run a resource sweep across every region, including ones you think aren't in use. POCs, one-off experiments, and forgotten stacks leave behind running instances, load balancers, databases, and NAT Gateways; a cross-region inventory pass often surfaces a non-trivial monthly charge from work nobody remembers starting.

The AWS cost reduction checklist