Cloud cost control checklist for small teams on AWS and Google Cloud

Cloud bills rarely explode because of one big decision. They grow through dozens of small ones: a test instance nobody stopped, a NAT gateway in a forgotten environment, logs kept forever, an object-storage bucket full of half-finished uploads. For a small team, finding out at the end of the month is the expensive part.

This checklist covers the controls a founder or small engineering team can put in place in an afternoon, using features that AWS and Google Cloud document today. Most of them cost nothing to enable. The goal is not to squeeze every rupee or dollar out of the bill, but to make sure surprises are caught within a day rather than a month.

A key point before you start: on the major clouds, a budget is an alarm, not a brake. Google's documentation says plainly that an alerts-only budget "doesn't automatically cap" usage or spending, and AWS warns that charges can continue to grow after a budget notification is sent. Plan for alerts plus action.

1. Set up alerts before anything else

On AWS

• Create a monthly cost budget for the whole account with notifications at, for example, 50%, 80% and 100% of the amount you expect to spend. AWS Budgets can alert on actual spend and on forecasted spend.
• Understand the delay. AWS states that Budgets information is updated up to three times a day, typically 8 to 12 hours apart, and that there can be a delay between incurring a charge and being notified. An actual-spend alert is sent once per budget period when it first crosses the threshold.
• Forecast alerts need history. AWS notes that it needs about five weeks of usage data to generate forecasts, so a brand-new account relies on actual-spend alerts at first.
• Turn on AWS Cost Anomaly Detection with an AWS-managed monitor for AWS services. It uses machine learning to flag unusual spending patterns, and AWS says you might start receiving alerts within 24 hours of creating a monitor. Choose individual alerts (through an Amazon SNS topic) if you want to hear about a spike the same day, rather than a daily or weekly summary.
• Send alerts somewhere people look. Budget alerts can go to up to 10 email addresses and one SNS topic per alert; SNS can forward to chat tools.

On Google Cloud

• Create a budget on the billing account. Default alert thresholds are 50%, 90% and 100% of the budget amount, calculated against actual spend.
• Use spend caps where they exist. Google Cloud now documents spend cap budgets for a limited set of services: the Gemini API, Gemini Enterprise Agent Platform (formerly Vertex AI), Cloud Run and Cloud Run functions. When the cap is reached, new usage of that service in that project is paused for the rest of the budget period unless you lift it. That is a real brake for AI and serverless experiments, but it does not cover everything else in the project.
• Automate a response for other services with programmatic budget notifications through Pub/Sub, for example to scale a service down or disable billing on a sandbox project.

2. Make every cost attributable

You cannot cut what you cannot see. Agree on a small, mandatory set of tags or labels and apply them through infrastructure-as-code so nobody has to remember them:

Tag key	Example values	Why
environment	production, staging, dev	Find non-production spend quickly
service	api, worker, marketing-site	Cost per component
owner	a team or person	Someone to ask before deleting
expires	a date, for temporary resources	Safe clean-up of experiments

On AWS, tags only appear in billing reports once you activate them as cost allocation tags in the Billing and Cost Management console. AWS says it can take up to 24 hours for new tag keys to appear for activation and up to another 24 hours to activate, so do this on day one. You can then create a Cost Anomaly Detection monitor per tag value, such as one per service.

The simplest structural control is separation: keep production, staging and experiments in separate accounts or projects, each with its own budget. Deleting an entire sandbox account or project is far safer than hunting for stray resources inside a shared one.

3. Hunt the usual leaks

These items appear on a lot of small-team bills. Check each one monthly:

• Idle compute. Development and staging instances running nights and weekends. Schedule them to stop, or move them to services that scale to zero.
• Public IPv4 addresses. AWS charges for every public IPv4 address, in use or idle; the VPC pricing page lists $0.005 per hour for both in US East (N. Virginia). That works out to about $3.65 per address over a 730-hour month, which adds up across load balancers, NAT gateways and forgotten Elastic IPs.
• NAT gateways. In the same Region, AWS lists a NAT gateway at $0.045 per hour plus $0.045 per GB processed. A NAT gateway in each of several non-production environments, or heavy traffic to AWS services through NAT instead of VPC endpoints, is a common surprise.
• Unattached storage and old snapshots. Volumes left behind after instances were terminated, and snapshots with no retention policy.
• Incomplete multipart uploads. Failed large uploads to S3 leave parts that are billed but invisible in normal listings. Add a lifecycle rule with AbortIncompleteMultipartUpload, for example after seven days, to every bucket.
• Logs kept forever. Set retention on log groups and buckets. Debug-level logging in production is both a cost and a privacy risk.
• Oversized databases. Managed databases are often provisioned for launch-day fears and never resized. Check CPU and memory use over a month before downsizing.
• Data transfer. Traffic between Regions, zones and out to the internet is billed separately from compute. Serve static assets through a CDN and keep chatty services in the same zone where resilience allows.

4. Add guardrails that act automatically

Alerts tell people; guardrails change things. Use them carefully, because a guardrail that stops production is an outage.

• AWS Budgets actions can apply an IAM policy or service control policy when a threshold is crossed, for example denying the creation of new resources in a sandbox account. AWS's own example is applying a custom IAM policy at 80% of a budget. AWS also warns that stopping an EC2 instance in an Auto Scaling group via a budget action is not effective on its own, because the group replaces the instance.
• Google Cloud spend caps for supported services, and Pub/Sub-driven automation for others.
• Quotas. Lower service quotas in sandbox accounts so an experiment cannot start hundreds of instances.
• Lifecycle rules on storage so data moves to cheaper classes and expires on schedule without anyone remembering.
• Infrastructure as code with review. Changes to instance sizes and new managed services go through pull requests, where cost is part of the review.

5. Review on a rhythm

Put a 30-minute cost review in the calendar each month. A simple agenda:

1. Compare this month's total with last month and with revenue or active customers.
2. Look at the top five services by cost and the top five by month-on-month growth.
3. Read every anomaly alert from the month and mark it as expected or not.
4. Check untagged spend; fix the tagging, not just the report.
5. Decide on one or two changes, assign an owner and a date.

Once usage is stable for a few months, look at commitment discounts such as AWS Savings Plans or committed-use discounts on Google Cloud. AWS Budgets can alert when Savings Plans or Reserved Instance utilisation drops, so you notice if a commitment stops matching reality.

The checklist

• Account-wide monthly budget with actual and forecast alerts.
• Cost Anomaly Detection (AWS) or equivalent, with same-day alerts to a shared channel.
• Spend caps on eligible Google Cloud services used for experiments.
• Separate accounts or projects for production and non-production, each with a budget.
• Mandatory tags activated as cost allocation tags.
• Non-production compute scheduled off or scaled to zero.
• Unused public IPv4 addresses, volumes and snapshots removed.
• NAT gateway use reviewed; VPC endpoints for heavy AWS-service traffic.
• Lifecycle rules on every bucket, including aborting incomplete multipart uploads.
• Log retention set everywhere.
• Monthly cost review with named owners for actions.

Summary

Cloud cost control for a small team is mostly about speed of feedback. Budgets and anomaly detection shrink the time between a mistake and its discovery; tags and separate accounts tell you where the money went; lifecycle rules, schedules and the occasional automated guardrail stop the most common leaks. Set these up once, review them monthly, and the bill becomes something you plan rather than something that happens to you.