Keeping Cloud Costs Sane When Your Team Is Small

A small team rarely overspends on cloud because of one big mistake. The bill grows from many small leftovers: a staging database nobody opened since spring, a load balancer for a prototype that was never launched, a storage bucket full of logs with no expiry date. Each one is cheap. Together they become a line item that surprises the founder at the end of the month.

This post is a practical routine for teams of two to twenty people. It assumes you run on a major provider such as AWS, Google Cloud or Azure, and the ideas apply to all of them. Names of settings differ, the habits do not. We will not quote price tables, because prices change. Check your provider's current pricing pages when you apply any of this.

Step 1: Make the bill visible to the people who cause it

You cannot reduce what you cannot see. Before changing anything, set up three things.

1. Billing alerts. Create a monthly budget with notifications at 50, 80 and 100 percent of the amount you are willing to spend. Send them to a shared channel or a group email, not one person's inbox. Providers include a budgeting tool for this at no charge or a small one.
2. Cost reports by service. Open the cost explorer in your provider's console and group by service. In most small setups, two or three services account for most of the spend. Those are your first targets.
3. Tags. Add at least these tags to every resource: project, env (prod, staging, dev) and owner. Then group cost by tag. Untagged spend is the first thing to hunt down, because nobody is responsible for it.

Enforce tagging early. If your infrastructure is defined in code (Terraform, Pulumi, CloudFormation), set default tags in one place so new resources inherit them. Retagging old resources by hand is dull work, so do it once and then prevent the problem.

Step 2: Find the waste that costs nothing to remove

Start with resources that are doing no work. Removing them carries almost no risk, as long as you check first.

• Stopped instances that still have attached disks. The machine is off, the disk still bills.
• Unattached volumes and old snapshots. These pile up after every instance replacement.
• Idle load balancers and NAT gateways. Some bill by the hour whether or not traffic flows.
• Unused static IP addresses. Many providers charge for addresses that are reserved but not attached.
• Old container images in the registry. Add a lifecycle rule that keeps the last 10 or 20 images per repository.
• Forgotten test environments. Look at the env tag and ask the owner if each one is still needed.

A safe process: before deleting anything, snapshot or tag it with delete-after: <date> two weeks ahead and announce it in the team channel. If nobody objects, remove it. A short grace period costs a little and prevents the one deletion that causes a bad afternoon.

Step 3: Match size to real use

Teams tend to choose instance sizes by guessing, then never revisit. After a few weeks of real traffic, check actual usage.

Look at CPU and memory over the past 30 days. If a server peaks at a small fraction of its capacity and never gets close to the limit, move down one size and watch for a week. Your provider's cost tools often include right-sizing suggestions based on this data. Treat them as a starting point, not an instruction: check the peak, not only the average, and check memory if your monitoring agent reports it, since CPU alone can mislead.

Take a snapshot before resizing a managed database, and do it in a maintenance window, since it can cause a short outage.

Step 4: Turn things off when nobody is using them

Non-production environments rarely need to run at 3 a.m. on a Sunday. If your team works in one or two time zones, a staging environment may be needed for around a third of the hours in a week.

Simple scheduling options:

• A scheduled function or provider scheduler that stops tagged instances in the evening and starts them in the morning.
• Scaling a staging container service down to zero tasks outside working hours.
• Short-lived preview environments created per pull request and destroyed when the branch merges.

Keep the schedule honest. If someone in another time zone needs staging at night, give them a documented way to start it, such as a chat command or a button in your CI tool. A schedule people fight against gets switched off, and then you have saved nothing.

Step 5: Fix storage and data transfer

Storage grows slowly and quietly, which is why it often becomes a large part of the bill.

• Lifecycle rules on object storage. Move old logs and backups to a cheaper storage class after 30 or 60 days, and delete them after the period you actually need. Decide the retention period with whoever handles legal or compliance questions, not alone.
• Log volume. Verbose debug logging in production can cost more in ingestion and storage than the application costs to run. Set production to a sensible level, and set a retention period on every log group. The default is often "never expire".
• Data transfer. Traffic leaving your provider's network, or crossing regions, is billed. Keep services that talk to each other in the same region, serve static files through a CDN, and avoid copying large datasets between regions without a reason.
• Backups. Keep enough to restore, not every version forever. Test a restore once a quarter, because a backup you have never restored is a guess.

Step 6: Build a monthly review habit

Cost control is a routine, not a project. Put a 30-minute review on the calendar at the same time each month, with one person responsible for running it. The agenda:

1. Compare this month with the last. Which service moved most?
2. Check the untagged spend. Assign owners.
3. List new resources created in the past month. Does each still have a purpose?
4. Review alerts that fired. Was the response quick enough?
5. Pick one saving to implement before the next review, and write it down.

One saving per month is enough. After a year, that is twelve fixes, and the bill reflects them.

FAQ

How much should a small team spend on cloud?

There is no standard figure. Set the budget from your revenue or runway and the needs of the product, then keep the trend steady unless usage grows. A rising bill with rising users is healthy. A rising bill with flat users is a leak.

Should we move to a cheaper provider?

Rarely as the first step. Migration costs engineering time and adds risk. Fix waste, right-size and schedule first. Reconsider the provider only if the architecture changes or the pricing model no longer fits your workload.

Talk to us

If your cloud setup has grown without a plan and you want a second pair of eyes, we can review it with you and suggest a sensible order of fixes. Email hello@risingstation.com or visit risingstation.com/contact-us.