Cloud Cost Is an Architecture Problem: Three Design Decisions That Actually Cut Spend

Why dashboards rarely cut spend on their own

Cost visibility tools answer the question "where did the money go?" They are good at it. They allocate spend to accounts and tags, flag idle resources, recommend smaller instances and track commitment coverage. That work is worth doing, and the FinOps Framework describes it well.

The limit is that a dashboard acts on resources, and the bill is mostly decided by architecture. An instance can be right-sized. The decision to run a fixed cluster around the clock for a workload that is busy six hours a day cannot be fixed from a dashboard. Committed-use discounts lower the unit price of whatever you already run. If the design is wasteful, the commitment locks the waste in for one to three years at a better rate.

Practitioners report the same plateau. The FinOps Foundation's State of FinOps 2026 survey found that workload optimization and waste reduction is still the top current priority. It also quotes mature teams saying they have "hit the 'big rocks' of waste" and now face many smaller opportunities that take more effort to capture. The report describes the discipline moving toward unit economics and toward influencing technology choices before they are made. In plain terms, it is moving toward architecture.

The major cloud providers say the same thing in their own guidance. The cost pillars of the AWS, Azure and Google Cloud Well-Architected frameworks all treat cost as a design property, not a billing exercise.

Decision 1: How capacity follows demand

The question: when demand drops, does your cost drop with it?

Many workloads are built with a fixed floor of capacity sized for peak load: always-on clusters, provisioned databases and over-sized message brokers. For the hours below peak, you are paying for headroom. AWS's cost guidance gives a simple example. Development and test environments used only during working hours could cut that compute cost by about 75% by stopping outside those hours (40 hours of use versus 168 hours in a week).

The architecture choices that decide this:

• Stateless services. Capacity can only scale in safely if instances hold no session or local state. Moving state into managed stores or caches is what makes elasticity possible.
• Queue-based load leveling. Putting a queue in front of bursty work lets a smaller pool of workers drain the backlog at a steady rate, instead of sizing for the burst.
• The right execution model for the load shape.
  • Spiky or intermittent load suits serverless functions, scale-to-zero containers or on-demand database capacity.
  • Steady, predictable load suits provisioned capacity with commitments.
  • Batch work suits interruptible or spot capacity, provided jobs can checkpoint.
• Schedules as code. Non-production environments should have shutdown schedules and expiry dates set when they are created, not added later.

The trade-off: elastic designs add cold-start latency, more moving parts and limits on concurrency. Do not use serverless everywhere. Match the execution model to the load profile you have measured, and write down why.

Decision 2: Where data lives and how far it travels

The question: how many times does each byte cross a billable boundary?

Compute is easy to see on a bill. Data movement is easy to miss until it becomes a top line item. Providers charge in different ways for:

• Traffic between availability zones.
• Traffic between regions.
• Traffic out to the internet.
• Traffic processed by NAT gateways and some load balancers.

See, for example, the data-transfer sections of AWS EC2 pricing and VPC pricing. Azure and Google Cloud publish equivalent pages. Rates differ by provider and region and change over time, so model them from the current price lists rather than rules of thumb.

Four patterns drive most avoidable transfer cost:

• Chatty services spread across zones. A request that calls eight internal services, each in a different zone, pays for cross-zone traffic several times. Zone-aware routing, or placing tightly coupled services together, reduces this. Keep the redundancy you need for availability.
• Private traffic routed through NAT. Workloads that reach the provider's own storage or APIs through a NAT gateway pay processing charges that private endpoints often avoid.
• Replication without a reason. Cross-region copies of every dataset, set up "for resilience," should be tied to a stated recovery objective. If the recovery plan does not need the copy, it is a cost without a benefit.
• Logging and observability volume. Debug-level logs shipped across regions and kept indefinitely can cost more than the application. Set retention and sampling by environment and by value.

Storage placement follows the same logic. Lifecycle policies that move ageing data to cheaper tiers belong in the platform templates, not in a clean-up ticket.

The trade-off: keeping data close to compute can work against resilience and data-residency requirements. Write the recovery and residency requirements down first, then design the minimum data movement that meets them.

Decision 3: How infrastructure is shared and measured

The question: can you state the cost of one unit of business output, such as one customer, transaction, case or report?

Tenancy decides both cost and whether you can measure it:

• Dedicated stacks per customer or business unit are simple to attribute and isolate. They multiply fixed overhead, and they tend to sprawl.
• Shared multi-tenant platforms spread fixed cost widely. Without deliberate design, they hide who is consuming what.

Either can be right. What goes wrong is choosing without a cost model and then trying to recover attribution from tags after the fact.

Design for measurement from the start:

• Use account, subscription or project boundaries as the main way to allocate cost. Tags supplement them. Tags applied by hand drift, while account boundaries do not.
• Emit usage measures from the application. Requests, tenants, jobs and records processed let shared costs be split by actual consumption.
• Standardize billing data. The FinOps Foundation's FOCUS specification, now at version 1.4, defines a common schema for cost and usage data across providers. That makes unit-cost reporting possible across clouds and SaaS.
• Give each team a unit-cost metric and a target, and show how it trends with each release. AWS's guidance calls this measuring "the business output of the workload and the costs associated with delivering it."

When a team can see that a design change moved cost per transaction from one figure to another, cost becomes an engineering conversation rather than a finance complaint.

Making cost part of the architecture process

Three lightweight practices make the decisions above stick:

1. A cost estimate at architecture review. Every significant design gets a rough monthly cost at expected and peak load, with assumptions listed. It does not need to be precise; it needs to be explicit.
2. Cost as a non-functional requirement. State a target unit cost next to the latency and availability targets, and test against it before and after launch.
3. A post-release check. Thirty days after a major change, compare actual spend and unit cost against the estimate, and record what you learned.

One of the FinOps Foundation's principles is that "everyone takes ownership for their technology usage," with engineers owning cost "from architecture design to ongoing operations." Architecture review is where that ownership starts.

Checklist: questions for your next architecture review

• What is the load profile (peak, trough, burstiness), and does the execution model match it?
• What does this workload cost at zero traffic? Can that floor be lowered?
• Are services stateless enough to scale in safely?
• Do non-production environments have shutdown schedules and expiry dates?
• How many billable boundaries (zone, region, NAT, internet) does a typical request cross?
• Is every cross-region copy tied to a stated recovery objective?
• What are log retention and sampling, per environment?
• How is cost allocated: by account or project boundary, by application-emitted usage, or by tags alone?
• What is the unit-cost metric, who owns it, and what is the target?
• Should any commitment wait until the design has stabilized?

Getting help

If your cloud bill has stopped responding to clean-up work and you want an architecture-level view of where the cost comes from, tell us about the workload. We will reply with a short scope and a timeline, or tell you plainly if we are not the right fit.

All insights