- 07 Oct, 2026
- 0 Comments
- 6 Mins Read
AWS Cost Optimisation for Small Teams: 10 Checks That Cut the Bill
Most small teams don’t overspend on AWS because they made one big mistake. They overspend because of dozens of small ones: a test server nobody switched off, snapshots from a project that ended last year, a database sized for a launch-day spike that never came. Each one is a few dollars a day. Together they quietly become a large share of the bill.
The good news is that AWS cost optimization doesn’t need a dedicated FinOps team. It needs a short list of checks done in the right order, and a habit of repeating them. This is the checklist we use when a client asks us why their AWS bill keeps growing.
Start with visibility: you can’t cut what you can’t see
1. Find out what actually drives the bill
Open AWS Cost Explorer and group the last three months of spend by service, then by usage type. In most small accounts, a handful of line items make up most of the total, usually EC2, RDS, data transfer, NAT Gateway, EBS storage and S3.
Write down your top five cost drivers. Everything else on this list should be prioritised against them. Saving 50% on a service that costs $10 a month is not worth an afternoon; saving 15% on your biggest line item usually is.
2. Tag resources so every dollar has an owner
Untagged resources are where waste hides. Agree on two or three tags, such as Project, Environment (prod, staging, dev) and Owner, and activate them as cost allocation tags in the Billing console so they appear in Cost Explorer.
Once costs are split by environment, many teams discover that development and test environments cost almost as much as production, which leads straight to the next checks.
Remove waste: the quickest savings
3. Delete idle and orphaned resources
These are the usual suspects in almost every account we review:
- Unattached EBS volumes left behind when an instance was terminated.
- Old EBS snapshots and AMIs from servers that no longer exist.
- Unused Elastic IP addresses and idle load balancers with no healthy targets.
- Forgotten test instances and databases, often in a region nobody normally looks at.
Check every region you have ever used, not just your main one. Before deleting anything that might matter, take a final snapshot or confirm with the owner, then remove it.
4. Switch off non-production outside working hours
A development server that runs 24/7 is billed for 168 hours a week. If your team only uses it during office hours on weekdays, it is busy for roughly 50 of those hours. Scheduling dev and test EC2 instances and RDS databases to stop in the evening and at weekends, using the AWS Instance Scheduler solution, Systems Manager automation or a simple Lambda function, cuts their compute cost by well over half.
5. Add lifecycle rules to S3 and logs
Storage grows silently. Set S3 lifecycle policies to move older objects to cheaper storage classes (such as S3 Standard-Infrequent Access or Glacier tiers) and to delete what you don’t need to keep. If access patterns are unpredictable, S3 Intelligent-Tiering moves objects between tiers for you.
Do the same for CloudWatch Logs: the default retention is “never expire”. Setting a sensible retention period, for example 30 or 90 days for application logs, stops you paying to store logs nobody will read.
Right-size what you keep
6. Match instance sizes to real usage
Teams usually pick instance sizes at launch and never revisit them. AWS Compute Optimizer analyses CloudWatch metrics and recommends smaller or different instance types for EC2, EBS volumes, Lambda functions and more. If an instance averages 10% CPU for weeks with no spikes, it is a strong candidate to drop one size.
Right-size in small steps, watch performance for a week, and keep a rollback plan. The aim is to remove headroom you never use, not to run production at the limit.
7. Move to newer, cheaper options
Some savings are close to free:
- gp2 to gp3 EBS volumes. gp3 has a lower price per GB, and AWS lets you change the volume type in place without detaching it.
- Current-generation instances. Newer instance families usually give more performance for the same or lower price than older ones.
- Graviton (Arm) instances. For workloads that run on Arm, such as many Linux, container, Java, Python and Node.js applications, AWS positions Graviton as offering better price-performance than comparable x86 instances. Test first, since some software and libraries need Arm builds.
8. Watch the hidden network charges
Data transfer is the line item that surprises people most. Common causes:
- NAT Gateway processing charges when private instances pull large amounts of data, for example from S3 or container registries. A VPC gateway endpoint for S3 (and for DynamoDB) lets that traffic bypass the NAT Gateway, and gateway endpoints have no hourly charge.
- Cross-Availability-Zone traffic between chatty services placed in different zones.
- Data transfer out to the internet, which a CDN such as Amazon CloudFront can often reduce by serving cached content closer to users.
Commit to what’s left, and keep it under control
9. Use Savings Plans or Reserved Instances for steady workloads
Once waste is gone and sizes are right, look at the usage that runs all the time. For that steady baseline, Compute Savings Plans or Reserved Instances (including RDS Reserved Instances for databases) trade a one- or three-year commitment for a significantly lower rate than On-Demand.
Commit only to your proven baseline, not your peak. Cost Explorer’s Savings Plans recommendations are a good starting point. For interruption-tolerant work such as batch jobs, CI runners or some analytics, Spot Instances can be much cheaper still.
The order matters: buying commitments before cleaning up locks in paying for waste.
10. Set budgets and anomaly alerts
Cost optimisation is not a one-off project. Create AWS Budgets with email alerts at, say, 80% and 100% of your monthly target, and turn on AWS Cost Anomaly Detection so an unexpected spike, such as a misconfigured job or a leaked access key mining crypto, is caught in days rather than at month end.
Then put a 30-minute cost review in the calendar every month. Look at the top five drivers again, check new untagged resources, and act on any Compute Optimizer recommendations.
A simple order of work
If you only have one afternoon, do it in this order:
- Cost Explorer: list the top five cost drivers.
- Delete orphaned volumes, snapshots, Elastic IPs and forgotten test resources.
- Schedule dev and test environments to stop out of hours.
- Set S3 lifecycle rules and CloudWatch Logs retention.
- Create a budget alert and turn on anomaly detection.
Right-sizing, gp3 and Graviton migrations, network fixes and Savings Plans come next, once you can see where the money goes.
How PITC Solutions can help
At PITC Solutions we design, migrate and tune AWS environments for businesses from startups to enterprises, and cost optimisation is part of every engagement. Our cloud architecture and cost optimisation consulting covers a full review of your account: cost drivers, idle resources, right-sizing, networking, storage and a commitment plan that fits how your workloads actually run.
If you’d rather build the skills in-house, our corporate cloud training and AWS Cloud Foundations course teach your team to design cost-aware architectures from day one.
Want to know how much of your AWS bill is waste? Book a free AWS cost review and we’ll walk through your top cost drivers with you and show you where the quickest savings are.
For more practical guides on cloud, databases and AI, browse our insights.