Sequentur Blog
Helping you stay ahead of IT challenges
Real-world IT knowledge from engineers solving problems every day.
Practical IT knowledge for businesses that can’t afford downtime
Cloud cost management for small business: how to stop overpaying
Short answer: Most small businesses overpay for cloud by 20 to 40% without realizing it, and the waste is concentrated in five places: idle or oversized virtual machines (the #1 source by a wide margin), storage tier mismatches (expensive premium SSD holding files that never get accessed), forgotten dev/test resources (left running after a project ended), on-demand pricing for steady-state workloads that should be on reserved instances or savings plans, and unmonitored egress (data leaving the cloud at $0.05 to $0.09 per GB). A typical first-time cloud cost audit on a $1,500/month SMB cloud bill finds $300 to $600/month of recurring waste – money the business is paying every month for resources that are not delivering value. The good news: most of it is fixable in a single afternoon of cleanup, and the rest follows from setting up two or three monthly review habits that cost nothing to maintain.
This guide is written for businesses already in the cloud who want to stop overpaying. If you have not migrated yet and are still budgeting for the cloud bill, see how much does cloud migration cost for a small business instead – that covers what to expect upfront. This article covers what to do once the bills start arriving and you suspect they are higher than they should be.
Cloud cost waste at a glance
| Source of waste | % of typical SMB cloud bill | Effort to fix | One-line fix |
|---|---|---|---|
| Oversized or idle VMs | 15 to 30% | Low to medium | Right-size based on 30-day metrics, shut down unused VMs |
| Storage tier mismatches | 5 to 15% | Low | Move infrequently accessed data to cool/archive tiers |
| Forgotten dev/test resources | 3 to 10% | Very low | Audit, tag, schedule auto-shutdown, kill the orphans |
| On-demand pricing for steady-state workloads | 10 to 25% | Low (one-time commitment) | Buy reserved instances or savings plans for production VMs |
| Unmonitored egress | 1 to 8% | Medium | Identify the source, move it inside the cloud, or enable CDN |
| Premium-tier services nobody uses | 2 to 8% | Low | Audit subscriptions, downgrade or cancel unused services |
| Backup over-retention | 2 to 6% | Low | Right-size retention policies; archive old backups to cool tier |
| Always-on test environments | 3 to 12% | Very low | Auto-shutdown schedules (off at 7pm, on at 7am) |
Add these up and a typical SMB cloud bill carries 20 to 40% recoverable waste. Not all of it is worth chasing – the last 5% takes more time than it saves. But the first 15 to 30% is almost always fixable in a few hours of focused work, and the savings are recurring forever.
Why cloud bills creep up
Cloud bills do not arrive at the cost they will eventually settle at. They drift upward over months and years. Five forces drive the drift, and recognizing them is the first step to controlling them.
Provisioning is too easy
The friction to spin up a VM is one click. The friction to monitor whether it is being used is much higher. The default behavior in every SMB cloud environment is “create resources, forget about them.” Resources accumulate until somebody runs an audit.
Sizing decisions are made once and never revisited
When you stand up a new VM, you size it for what you expect the workload to need. Six months later, the actual workload is different – usually smaller than projected. The VM keeps running at the original size. Cloud vendors charge for capacity, not utilization. A 4-vCPU VM running at 8% CPU costs the same as a 4-vCPU VM running at 80%.
Dev and test environments outlive their projects
Somebody creates a dev environment for a project. The project ships. The dev environment keeps running. Six months later, nobody remembers what it was for, but turning it off feels risky because “what if we need it?” The cost is silent and recurring.
Vendor pricing changes faster than bills get reviewed
Cloud vendors change pricing tiers, introduce new instance families that are 20% cheaper than the old ones, and adjust reserved instance offerings. The savings only flow if somebody is reviewing the bill against current pricing. Most SMBs review their cloud bill once a year, if that.
Cost ownership is fuzzy
In a small business, “the cloud bill” often does not have a single owner. The MSP or IT lead manages the technical environment, but cost decisions (“should we keep this VM running?”) get deferred because nobody has explicit cost authority. The bill keeps growing because no individual feels responsible for shrinking it.
How to audit your cloud spend
Before you can optimize, you have to know where the money is going. A first-pass cloud cost audit takes two to four hours for a typical SMB environment and finds most of the waste.
Step 1: pull a 90-day cost breakdown
Both Azure and AWS provide free cost analysis tools (Azure Cost Management in the Azure portal, AWS Cost Explorer in the AWS console). Pull a 90-day breakdown grouped by:
- Service (Compute, Storage, Database, Networking, etc.)
- Resource group (Azure) or tag (AWS)
- Daily trend over the 90 days
You are looking for two patterns: services that are unexpectedly large (a $400/month line item nobody knew about), and trends that are climbing (a service that was $50/month six months ago is now $200/month and rising).
Step 2: list every running VM and its utilization
For every VM, record:
- Name and purpose (if you do not know what it is for, that is finding #1)
- Size (vCPU and RAM)
- Average and peak CPU utilization over the last 30 days
- Average and peak memory utilization
- Whether it runs 24/7 or has known idle periods
This list becomes the source of right-sizing decisions. A VM averaging 5% CPU is overprovisioned. A VM with named purpose “test environment for project that wrapped in 2024” is a deletion candidate.
In Azure, the Advisor tool flags underutilized VMs automatically. In AWS, Compute Optimizer does the same. Use them as a starting point, not a final answer – they are conservative and miss workloads with bursty usage patterns.
Step 3: list every storage account, disk, and database
For each:
- Total provisioned size
- Actual data size
- Storage tier (premium SSD, standard SSD, standard HDD, hot blob, cool blob, archive)
- Last access pattern (if available)
Common findings: premium SSD provisioned at 1 TB but actually using 200 GB (charged on provisioned size, not used); hot-tier blob storage holding files nobody has accessed in 18 months; orphaned managed disks attached to VMs that were deleted (Azure deletes the VM, leaves the disk).
Step 4: list every subscription and SaaS line item on the cloud bill
The cloud bill often includes more than infrastructure. Marketplace subscriptions, third-party services, premium support tiers, M365 add-ons that get billed through Azure. Each one needs a “do we still use this?” review.
Step 5: review tags and ownership
Every resource should be tagged with at least:
- Environment (production, staging, dev, test)
- Owner (which department or person is responsible)
- Cost center (which budget line this hits)
Resources without tags are the most likely waste candidates – if nobody owns them, nobody is checking whether they are still needed.
By the end of the audit, you should have three lists: delete or shut down (orphaned, idle, no clear purpose), right-size or downgrade (provisioned larger than needed), and commit (steady-state workloads that should be on reserved pricing instead of on-demand).
Right-sizing virtual machines
Right-sizing is the single highest-leverage cost optimization for most SMBs. Cloud vendors charge for capacity provisioned, not capacity used. A VM with 4 vCPU and 16 GB RAM running at 8% CPU and 25% memory is paying for capacity that is not delivering value.
What “right-sized” actually means
A VM is right-sized when:
- Average CPU utilization is 30 to 60%. Below 30% means oversized; above 70% leaves no headroom for spikes.
- Average memory utilization is 50 to 75%. Memory pressure shows up as performance issues; overprovisioned memory is silent waste.
- Peak utilization stays under 90% during normal business cycles.
- The VM family matches the workload (general purpose for mixed workloads, compute-optimized for CPU-heavy, memory-optimized for databases and caching).
How much you save by downsizing one tier
| Original size | Right-sized to | Typical monthly savings |
|---|---|---|
| Standard_D4s_v5 (4 vCPU, 16 GB) | Standard_D2s_v5 (2 vCPU, 8 GB) | $90 to $130/month per VM |
| Standard_D8s_v5 (8 vCPU, 32 GB) | Standard_D4s_v5 (4 vCPU, 16 GB) | $180 to $260/month per VM |
| Standard_E4s_v5 (memory-opt 4 vCPU, 32 GB) | Standard_D4s_v5 (general 4 vCPU, 16 GB) | $80 to $120/month per VM (if memory was overprovisioned) |
| Premium SSD 1 TB | Standard SSD 500 GB (right-sized) | $80 to $120/month per disk |
For a typical SMB running 4 to 8 VMs, the right-sizing pass commonly drops the compute bill by 25 to 40%. The work is one afternoon. The savings are recurring forever.
The right-sizing process
- Pick one VM at a time. Bulk right-sizing introduces correlated risk; do them sequentially.
- Take a baseline. Note current CPU/memory utilization, response times if the VM serves traffic, dependencies that hit it.
- Resize during a maintenance window. Both Azure and AWS allow VM resizing; the VM reboots during resize (1 to 5 minutes downtime).
- Monitor for 7 days. If utilization is now in the right range and no performance issues, the right-sizing held. If CPU spikes hit 100%, you went one tier too small – upsize.
- Document the decision. Tag the VM with current sizing rationale so the next audit knows what was deliberate.
Storage tier optimization
Cloud storage has multiple tiers at different price points. The single biggest storage cost mistake SMBs make is leaving everything in the default (hot) tier when most of the data is rarely accessed.
The four storage tiers that matter
| Tier | Price per GB/month | When to use |
|---|---|---|
| Hot / Standard | $0.018 to $0.025 | Active data accessed frequently |
| Cool / Infrequent Access | $0.010 to $0.015 | Data accessed once a month or less, retrieval cost on access |
| Archive / Glacier | $0.001 to $0.004 | Data accessed once a year or less, hours-to-retrieve |
| Premium SSD | $0.10 to $0.20 | High-IOPS workloads (databases, transaction logs) only |
Premium SSD is the largest single storage cost mistake on most SMB cloud bills. It is provisioned by default for many VM scenarios and never reviewed. A 500 GB premium SSD costs $50 to $100/month; the same data on standard SSD or in blob storage costs $5 to $15/month. If the workload does not need premium SSD’s IOPS, you are paying 5 to 10 times what you need to.
Storage audit questions
- Premium SSDs: What workload requires the IOPS? If the answer is “we did not check,” it is downgrade candidate.
- Hot blob storage: When was the data last accessed? Files older than 30 days with no access are cool-tier candidates. Files older than 1 year are archive-tier candidates.
- Backup vault retention: Are you retaining 365 daily backups? Most SMBs need 30 daily + 12 monthly + 7 yearly. Trim aggressively.
- Snapshots: Old VM snapshots accumulate quickly. Snapshots from 2023 still on the bill in 2026 are usually orphans.
A typical SMB storage audit recovers 10 to 25% of the storage bill – smaller than the compute right-sizing recovery, but it is one-time work that compounds month after month.
Reserved instances and savings plans
For workloads that run 24/7 (production VMs, always-on databases, persistent application servers), paying on-demand is paying a premium for flexibility you do not need. Cloud vendors offer reserved instances (Azure RI, AWS RI) and savings plans (Azure Savings Plans, AWS Savings Plans) that reduce the price by 20 to 50% in exchange for a one-year or three-year commitment.
When reserved pricing makes sense
- Workload runs 24/7 or close to it (more than 70% of the hours in a given month).
- You are confident the workload will keep running for at least the commitment period (1 year minimum, 3 years for the deepest discount).
- Sizing is stable (the VM is not getting right-sized down next quarter).
When reserved pricing does NOT make sense
- Burst workloads that run a few hours per day. On-demand is cheaper.
- Dev/test environments that should be on auto-shutdown schedules.
- Workloads under active right-sizing review. Commit AFTER right-sizing, not before.
How much it actually saves
| Commitment | Typical discount vs on-demand |
|---|---|
| 1-year reserved, no upfront | 20 to 35% |
| 1-year reserved, partial upfront | 25 to 40% |
| 3-year reserved, no upfront | 35 to 55% |
| 3-year reserved, all upfront | 45 to 60% |
For a 25-person SMB with $400 to $900/month of compute, right-sized first then committed to 1-year reserved pricing, the savings are $80 to $360/month. Three-year commitments lock in even deeper savings if the workload horizon is stable.
The mistake is committing too early. Right-size first, then commit. Buying a 3-year reservation on an oversized VM locks in the wrong cost for three years. Right-size, run for 30 days, validate the right size held, then buy the reservation.
Azure-specific: Hybrid Benefit
If you have existing Windows Server or SQL Server licenses with active Software Assurance, Azure Hybrid Benefit lets you bring those licenses to Azure VMs and Azure SQL, cutting compute cost by 30 to 50% on top of any reserved instance savings. Most SMB Azure environments leave Hybrid Benefit unclaimed because nobody set it during VM creation. It can be enabled retroactively in the Azure portal under each VM’s configuration. See Azure vs AWS for small business for the broader licensing trade-off.
Tagging and cost allocation
Tags are how you turn a single cloud bill into actionable cost data. Without tags, the bill is one number. With tags, it is “$420 for production, $80 for dev, $200 for the marketing team’s reporting environment, $150 unowned (investigate).”
The minimum tagging policy that works
- Environment: production, staging, dev, test
- Owner: department, team, or named individual
- Cost center: if you allocate IT cost across business units
- Project: for time-bound work that should be retired when the project wraps
That is four tags. Most SMBs do not need more than that. The temptation is to design a 12-tag policy that nobody actually applies; the working version is the smaller policy that gets applied to every resource.
How to enforce tagging without becoming a tag cop
- Enable tag inheritance at the resource group / subscription level. New resources inherit tags from their parent.
- Use Azure Policy or AWS Service Control Policies to require tags on resource creation. Resources without tags get rejected at creation, not after the bill arrives.
- Run a monthly “untagged resources” report. Anything that slipped through gets tagged or deleted in the monthly review.
Once tags are in place, the cost reports become useful. “Production cost grew 12% this month – which workload?” becomes answerable in 30 seconds instead of an investigation.
The auto-shutdown opportunity for dev/test
Dev and test environments that run 24/7 are the easiest waste to eliminate. Most SMBs use them 8 to 10 hours a day, 5 days a week – so they are running 168 hours a week but used 50. The other 118 hours are pure waste.
Auto-shutdown math
A development VM running 24/7 costs (hours per month) × (hourly rate). Switching to on-during-business-hours-only:
| Schedule | Hours/month | % of full month | Cost vs 24/7 |
|---|---|---|---|
| 24/7 (always on) | 730 hours | 100% | 100% |
| Weekdays 7am to 7pm | 260 hours | 36% | 36% |
| Weekdays 8am to 6pm | 220 hours | 30% | 30% |
| Weekdays 9am to 5pm | 176 hours | 24% | 24% |
A $200/month dev VM on auto-shutdown for nights and weekends drops to $50 to $70/month. For a typical SMB with 2 to 4 dev/test VMs, the auto-shutdown pass commonly saves $200 to $500/month.
How to set it up
- Azure: Auto-shutdown is built into VM configuration. Set “Auto-shutdown” to a daily time. Pair with Start/Stop VMs during off-hours for the boot side, or use Azure Automation for more complex schedules.
- AWS: Use Instance Scheduler (provided as a CloudFormation template) or Lambda functions triggered by EventBridge schedules to start and stop instances on a cron pattern.
The first time you set this up takes an hour. It runs forever afterward.
Egress: the line item that surprises everyone
Cloud egress (data leaving the cloud to the internet or across regions) is charged per GB, typically $0.05 to $0.09/GB after the first free 100 GB or so. For most SMBs egress is small. For workloads that push data outward, it can dominate the bill.
Common egress surprises
- VPN gateways pulling data from cloud back to on-prem for backup, sync, or hybrid identity.
- Cross-region replication for disaster recovery (charged as egress when crossing regions).
- CDN-style workloads without a CDN. Serving static files directly from blob storage when a CDN would deduplicate the egress.
- Large file downloads from cloud storage to office, especially for media-heavy workloads.
- Unintended sync clients pulling more than expected (a misconfigured backup tool re-downloading the entire dataset weekly).
How to find egress problems
Cost analysis tools break out egress as a separate line item. Look for the data-transfer-out cost. If it is over 10% of the cloud bill, investigate what is driving it. Common fixes:
- Add a CDN in front of static content (Azure Front Door, AWS CloudFront). CDN egress is cheaper than blob egress, and the CDN caches reduce the volume.
- Move the consumer into the cloud. If a workload is pulling data from the cloud to on-prem and processing it, sometimes the right answer is to move the processing into the cloud entirely.
- Audit backup tools. Misconfigured backup or sync clients are the single most common cause of unexplained egress spikes.
Monthly review habits that prevent drift
Optimizing once is not enough. Cloud environments drift. The point of cost management is not a one-time cleanup – it is a sustainable monthly cadence that keeps drift under control. The good news: the cadence does not have to be heavy.
The 15-minute monthly review
- Pull last month’s cost vs the prior 3 months. Up by more than 10%? Investigate.
- Pull the top 5 line items. Has anything new entered the top 5? What is it for?
- Pull untagged resources. Tag or delete.
- Review reserved instance utilization. RI not being fully used = paying for capacity nobody is consuming.
The quarterly deeper review
- Right-sizing pass. Re-run the VM utilization audit. Some VMs that were right-sized 3 months ago now run at lower utilization and can downsize again. Some workloads grew and need to upsize.
- Storage tier review. Move data that has aged into cooler tiers.
- Subscription audit. Cancel marketplace items that are not being used.
- Egress review. Is data transfer holding steady or growing? Investigate growth.
The annual reset
- Renegotiate reservations. As reservations expire, re-evaluate whether to renew at 1-year, commit to 3-year, or let the workload float on on-demand.
- Review the overall cloud architecture. Some workloads that started in IaaS may now have a managed-service equivalent that is 20 to 40% cheaper. See lift and shift vs re-platform vs re-architect for the strategy framework.
- Renegotiate enterprise agreements if you are at the spend tier where they apply (typically over $5,000/month for SMBs hitting cloud volume thresholds).
For the operational discipline that holds these reviews together, the same project-management spine applies as in the cloud migration checklist for small business – a defined cadence, a defined owner, and a defined rollback path when changes do not work.
Common cloud cost management mistakes
- Optimizing once and stopping. The first audit is the easy one. The drift starts the next day. Without a monthly cadence, you are back to the same waste in 6 months.
- Committing to reservations before right-sizing. Buying a 3-year reservation on an oversized VM locks the wrong cost in for 3 years. Right-size first, then commit.
- Treating cost optimization as a one-person project. Cost ownership is a team-and-process thing. The MSP or IT lead can do the audit; the business has to take ownership of “do we still need this dev environment?” Decisions like that cannot be delegated.
- Ignoring tagging. Without tags, the cost report is one number. With tags, it is actionable. A 30-minute setup of tags pays for itself the first time you investigate a cost spike.
- Auto-shutdown only for dev. Many production workloads also have idle periods (overnight batch jobs, business-hours-only apps). Audit whether all production VMs need 24/7 uptime, not just whether dev does.
- Premium SSD by default. Standard SSD is sufficient for most workloads at 5 to 10 times less cost. Premium SSD should be a deliberate choice for IOPS-heavy workloads, not a default.
- Not claiming Hybrid Benefit (Azure). If you have existing Windows Server or SQL Server licenses with Software Assurance, Hybrid Benefit cuts compute cost 30 to 50%. Many SMB tenants leave it unclaimed.
- Storage retention without expiry. Backup retention of “keep everything forever” is rarely required. Most SMBs need 30 daily + 12 monthly + 7 yearly. Trim retention policies aggressively.
- Ignoring egress. Treating it as “small” until a configuration change pushes it past 10% of the bill. Monitor it as a discrete line item, not part of “miscellaneous.”
- Doing it alone when the bill is large. A $500/month bill is right-sized by an internal IT person in an afternoon. A $5,000/month bill across multiple subscriptions, regions, and reserved instance positions benefits from a managed provider who runs cost optimizations as a recurring service. The math on the engagement fee versus the recurring waste makes the call.
How long does it take to recover the savings
| Effort | Typical SMB time investment | Typical savings on a $1,500/month bill |
|---|---|---|
| Initial cost audit | 4 to 8 hours | Identify $300 to $600/month of waste |
| Right-sizing pass (4-8 VMs) | 4 to 8 hours over 2 weeks | $150 to $400/month |
| Storage tier optimization | 2 to 4 hours | $30 to $150/month |
| Auto-shutdown for dev/test | 1 to 2 hours | $100 to $300/month |
| Reservation purchase (after right-sizing) | 1 hour | $80 to $300/month |
| Tagging policy + monthly review setup | 4 to 6 hours one-time, 15 min/month ongoing | Prevents drift; saves the next $200 to $500/month over 12 months |
Total typical first-pass savings on a $1,500/month bill: $300 to $600/month recurring. Time investment: roughly 2 working days spread over 2 to 3 weeks. The recovery is fast because the first 30% of waste is concentrated and obvious. The next 10 to 15% takes more work and benefits from professional tooling – the diminishing returns curve is real.
How Sequentur can help
If your cloud bill has been climbing and you want a second pair of eyes on what is driving it – or a recurring monthly review so it does not drift again – schedule a call.
Get the Best IT Support
Schedule a 15-minute call to see if we’re the right partner for your success.
Testimonials
What Our Clients Say
Here is why you are going to love working with Sequentur