FinOps Inform

How software design drives cloud costs: a practical guide

Discover how thoughtful software design can significantly reduce your cloud costs from day one, maximizing savings and efficiency.

Kori August 9, 2026 · 14 min read

Treat cloud cost as a non-functional requirement and enforce it in your Infrastructure-as-Code from day one. That single discipline, applied consistently across Terraform and CloudFormation, is where the largest, most durable savings come from. Not reserved instances. Not discount negotiations. The AWS Well-Architected Framework's Cost Optimization pillar makes this explicit: architectural decisions about availability, data transfer, and resource placement create hidden costs that no post-deployment clean-up fully recovers. An empirical study of 2,289 IaC file diffs across 618 repositories confirmed the same pattern, identifying five cost-saving patterns and seven antipatterns that recur across production codebases. Koritsu AI applied this approach to a UK bidding platform and delivered a 52% cloud cost reduction.

Your immediate next step: run a scan for orphaned resources and untagged spend. Assign it to your platform or infrastructure team this week.

Treat cost as a first-class non-functional requirement in design docs and architecture reviews.
Enforce tagging and lifecycle policies in IaC modules, not as a post-deployment task.
Use the FinOps Foundation's crawl-walk-run model to sequence your programme.
Validate IaC cost controls with a linter (such as a Checkov extension) before every merge.

Pro Tip: Start with visibility, not cuts. You cannot prioritise what you cannot attribute. Tag enforcement and orphan removal in the first 30 days will reveal where 80% of your recoverable spend actually sits.

Key takeaways

Treating cloud cost as a non-functional requirement enforced in IaC, combined with CI linting and structured ownership, is the most reliable path to sustained cloud cost reduction for UK engineering teams.

Point	Details
Design is the root cause	Architecture and IaC choices drive billing; post-deployment fixes recover less than design-time controls.
20–35% is recoverable early	Structured programmes targeting orphans, tagging, and rightsizing recover 20–35% without reliability risk. (Tag enforcement and orphan removal commonly account for the majority of these early gains.)
CI linting stops regressions	Pre-merge Checkov-based rules catch cost antipatterns before they reach production and compound.
30/90/180-day sequencing	Start with visibility and orphan removal, then commitments, then architecture refactors requiring engineering effort.
Koritsu AI delivers verified savings	A UK bidding platform achieved a 52% cost reduction through IaC enforcement and architecture changes, verified via billing reconciliation.

How does software design map to cloud billing dimensions?

Every architecture decision you make maps to a billing line. The problem is that most teams only see the invoice, not the design choice that generated it. Understanding the cloud cost impact of software design means tracing each technical pattern back to the specific meter it drives.

Chatty microservices calling each other across Availability Zones generate cross-AZ data transfer charges that compound fast: even a modest 1 KB payload at 500 calls per second across AZs produces a significant volume of billable transfer each month.
Multi-AZ and cross-region replication doubles or triples storage costs and adds replication transfer charges on top; many teams enable it by default without modelling the steady-state cost.
Hot storage tiers retained indefinitely for data that is rarely accessed after 30 days are one of the most common sources of avoidable spend.
Always-on development and staging clusters running 24/7 consume compute budget equivalent to production, for a fraction of the utilisation.
High-cardinality observability (every request traced, every metric at 1-second resolution) is known to drive significant logging ingestion and retention costs that grow with traffic.

Some choices create long-tail costs that are genuinely hard to undo. Cross-region replication, once embedded in a data model, requires careful migration to remove. Vendor-managed services without clean export paths can lock spend into a tier permanently. The AWS Well-Architected Framework categorises these as high-risk architectural issues precisely because they compound over time. Understanding your cloud total cost of ownership requires mapping each design choice to the billing dimension it affects before the code ships.

Design choice	Billing dimension	Compounding risk
Cross-AZ microservice calls	Data transfer (per GB)	High: grows with request volume
Multi-region replication	Storage + replication transfer	High: permanent until re-architected
Hot storage for cold data	Storage tiering	Medium: recoverable with lifecycle rules
Always-on dev clusters	Compute (on-demand)	Low: recoverable with scheduling
High-cardinality metrics	Logging ingestion + retention	Medium: grows with traffic

What IaC patterns and antipatterns affect your cloud costs most?

The 2,289-diff IaC study is the most rigorous empirical catalogue available. It evaluated 828 commits and validated a Checkov-based linter against 182 active repositories. The five cost-saving patterns it identified are worth building into your module library now.

Five patterns to adopt:

Mandatory tagging modules that enforce owner, environment, and cost-centre tags at resource creation.
Preventative templates with storage lifecycle rules baked in, so objects move to cheaper tiers automatically.
Budget integration at the Terraform workspace level, alerting before thresholds are breached.
Rightsizing module defaults that set conservative instance sizes and require explicit overrides for larger types.
Automated environment lifecycle policies that terminate non-production resources on a schedule.

Seven antipatterns to remove:

Hardcoded large instance types with no autoscaling policy.
Storage resources with no lifecycle or expiry configuration.
Cross-AZ or cross-region replication enabled without a documented cost justification.
Resources deployed with no tags, making cost attribution impossible.
Public egress rules that allow unrestricted outbound data transfer.
Observability configurations retaining high-resolution data indefinitely.
Ephemeral environments with no automated teardown.

Antipattern	Root cause	Detection point	Cost risk
Hardcoded large instances	No rightsizing default	Pre-merge plan	High
No storage lifecycle	Missing module default	Pre-merge lint	Medium
Untagged resources	No tagging enforcement	Pre-merge lint	High
Unrestricted public egress	Permissive security default	Pre-apply policy	High
No environment teardown	Missing lifecycle policy	Post-apply drift	Medium

Pro Tip: When fixing antipatterns, add expiry tags rather than deleting resources immediately. This preserves safety while making the intent explicit and gives you an audit trail for the next billing cycle.

What IaC patterns and antipatterns affect your cloud costs most? — overview diagram

How do you automate detection and stop cost regressions in CI?

IaC cost issues are typically fixed reactively, after the invoice arrives. Adding real-time linting in pre-merge pipelines reduces that lag to zero and catches antipatterns before they reach production. The Checkov extension approach from the IaC study is directly applicable: write custom checks that fail a pull request when a resource lacks required tags, introduces a storage resource without a lifecycle block, or enables public egress without an explicit override.

Run checks at three points in the pipeline:

Pre-merge: lint the plan output for untagged resources, missing lifecycle rules, and large instance types introduced without justification.
Pre-apply: policy-as-code checks (Open Policy Agent or Sentinel) that block changes expanding egress or adding cross-region replication without a cost-impact note in the PR.
Post-apply: drift detection that alerts when actual resource state diverges from the declared configuration, catching manual changes that bypass IaC.

High-signal CI rules to implement first:

Fail on any resource missing mandatory cost-centre and owner tags.
Warn on storage resources with no lifecycle configuration.
Fail on instance types above a defined size threshold without an approved override label.
Warn on new cross-AZ or cross-region data transfer rules.

Treating cost as an operational metric rather than a lagging invoice signal is what makes these checks valuable. The trade-off is pipeline speed: pre-merge linting adds seconds, pre-apply policy checks add minutes. Start with the highest-signal rules and expand coverage incrementally.

Pro Tip: Gate on tag compliance from day one. It is the lowest-effort, highest-return CI rule you can ship, and it makes every subsequent cost investigation faster.

Which architecture and code changes cut cloud spend most reliably?

Designing cost as a non-functional requirement and enforcing it during design reduces total cost of ownership more effectively than post-deployment clean-ups. The fixes below are ordered by typical return on engineering effort.

Rightsizing and autoscaling (small effort, high impact): match instance size to actual p95 utilisation, not peak theoretical load. Add autoscaling policies to every stateless service. Typical savings: 20–35% of compute spend in environments without prior cost programmes.
Spot and interruptible capacity (small effort, high impact): use spot instances for batch workloads, CI runners, and stateless services with retry logic. Savings of 60–80% on eligible compute are achievable, though availability trade-offs require fault-tolerant design.
Storage tiering and lifecycle policies (small effort, medium impact): move objects to infrequent-access or archive tiers after 30–90 days. Apply deletion policies to logs and ephemeral artefacts.
Caching and request batching (medium effort, high impact): a well-placed cache reduces both compute and egress. Batching API calls cuts per-request charges and reduces cross-AZ transfer volume significantly.
Database query and index optimisation (medium effort, medium impact): unindexed queries drive CPU and I/O costs on managed database services. A single missing index on a high-frequency query can double RDS or Cloud SQL costs at scale.
Observability cardinality reduction (small effort, medium impact): reduce metric resolution for non-critical services, set retention policies, and sample traces rather than capturing every request. See the benefits of cost-aware observability for a practical approach.
Language and framework footprint (large effort, low-to-medium impact): heavy interpreted runtimes with large memory footprints cost more per request on serverless platforms. Migrating hot paths to leaner runtimes is a longer-term play, but worth modelling for high-volume services.

Deployment configuration and pricing model selection chosen early in design avoid suboptimal recurring costs that are expensive to unwind later. Model your workload shape before committing to on-demand pricing.

Pro Tip: Compute inefficiencies are the fastest win, but common compute inefficiency patterns often hide in services that look healthy on CPU dashboards. Check memory utilisation and network I/O, not just CPU.

How do you sustain savings through FinOps, ownership and governance?

Cloud cost is not a technology problem. It is a process problem. Technical fixes without ownership structures revert within two billing cycles as teams ship new features without cost constraints.

Concrete governance that holds:

Mandatory tagging enforced in IaC modules, with CI failures blocking untagged deploys.
Team-level budgets with visible burn-down dashboards, reviewed in monthly engineering meetings.
Cost estimates required in design documents and architecture review board submissions.
Quarterly rightsizing reviews and commitment plan assessments as standing agenda items.

Aligning engineering incentives matters as much as the tooling. Recognition for delivered savings, visible unit-economics metrics (cost per transaction, cost per active user), and team-level cost ownership shift the conversation from finance reporting to engineering accountability. FinOps unit economics create measurable KPIs that engineers can directly influence, unlike an aggregate monthly bill.

Pro Tip: Run a monthly orphaned resource sweep as a standing task. Untagged, unowned resources accumulate silently and are often the single largest source of recoverable spend in mature environments.

Process checklist for sustaining change:

Tag enforcement active in CI (week 1).
Orphaned resource sweep completed (month 1).
Team budgets configured with alerts at 80% and 100% of threshold (month 1).
Periodic rightsizing review scheduled (quarterly).
Commitment plan reviewed against actual utilisation (bi-annually).

How do you prioritise fixes by effort versus impact?

Sequencing matters. Establish attribution first, remove orphaned resources second, commit baseline load with reservations third, then tackle architecture changes that require refactoring. This order maximises early cash return and funds the engineering time needed for deeper work.

Fix	Engineering effort	Typical bill savings	Timeline
Tag enforcement + orphan removal	Small (1–5 days)	20–35%	30 days
Rightsizing + autoscaling	Small (2–5 days)	15%	30–60 days
Reserved/committed use	Small (1–2 days)	20%	60–90 days
Storage tiering + lifecycle	Small (2–4 days)	5–20%	30–60 days
Caching + batching	Medium (5 days)	10%	60 days
Architecture refactor (egress, AZ)	Large (20+ days)	15%	90–180 days

A suggested roadmap for mid-market and enterprise teams:

30 days: enable tagging enforcement in CI, complete orphaned resource sweep, configure team budgets, establish unit-economics baseline.
90 days: purchase reserved capacity for stable baseline workloads, implement storage lifecycle rules, add pre-merge cost linting to all IaC pipelines.
180 days: complete rightsizing across compute fleet, refactor highest-egress service interactions, measure realised savings against baseline and report unit economics.

Pro Tip: Use a cloud architecture cost review to validate your prioritisation before committing engineering time. A structured review surfaces the highest-return fixes in your specific environment, not just the generic ones.

Koritsu AI case study: 52% cost reduction for a UK bidding platform

A UK bidding platform engaged Koritsu AI to address escalating cloud spend that had grown faster than revenue. The programme combined IaC enforcement (mandatory tagging, lifecycle policies, environment scheduling) with architectural changes to reduce cross-AZ traffic and rightsize the compute fleet. Engineering effort across the programme was measured in weeks, not quarters. The result: a 52% reduction in cloud costs, verified through billing reconciliation and unit-economics comparison before and after each change batch.

The verification method matters as much as the result. Savings were confirmed by comparing billing line items before and after each change, not by estimating. Post-change monitoring tracked unit economics (cost per auction event) to confirm that savings held as traffic grew.

Business variance caveat: results depend on the starting state of your environment, workload shape, and existing commitment coverage. Environments with no prior cost programme tend to show the largest initial gains.

A practical checklist and CI rules you can ship today

30-day quick wins (owner: platform/infrastructure team):

Enable tag enforcement in CI; fail builds on missing owner and cost-centre tags.
Run an orphaned resource sweep; delete or schedule termination of unowned resources.
Configure budget alerts at 80% and 100% for each team or service.
Set storage lifecycle rules on all S3 buckets or equivalent blob storage.

90-day platform work (owner: platform engineering):

Integrate a Checkov-based cost linter into all Terraform and CloudFormation pipelines.
Add pre-apply policy checks blocking new cross-region replication without justification.
Purchase reserved or committed-use capacity for baseline compute workloads.
Implement autoscaling policies on all stateless services.

Ongoing governance (owner: engineering leads + FinOps):

Monthly orphaned resource sweep as a standing task.
Quarterly rightsizing review using actual p95 utilisation data.
Cost estimates required in all design documents before architecture review.
Bi-annual commitment plan review against utilisation trends.

CI rule pseudocode for Terraform pipelines:

FAIL if resource.tags["owner"] is missing
FAIL if resource.tags["cost-centre"] is missing
WARN if aws_s3_bucket has no lifecycle_rule block
FAIL if instance_type not in approved_sizes and no override label present
WARN if aws_db_instance has multi_az = true and environment = "dev"

Pro Tip: Test new CI rules in warn-only mode for one sprint before switching to fail. This surfaces false positives without blocking releases, and gives teams time to remediate existing violations before enforcement kicks in.

Verification and rollback: keep a tagged snapshot of the IaC state before each change batch. If a cost rule blocks a legitimate launch, the override label mechanism provides an escape hatch without disabling the rule globally. Review overrides monthly and remove them when the underlying issue is resolved.

What most engineering teams get wrong about cloud cost reduction

The instinct is to start with reserved instances or savings plans. Those are useful, but they lock spend into a pattern that may itself be inefficient. Committing to the wrong instance family at scale is expensive to unwind.

The more common blind spot is attribution. Teams cannot prioritise what they cannot attribute. Untagged resources, shared accounts with no allocation model, and services with no cost owner make every subsequent decision a guess. The first two weeks of any cost programme should be spent entirely on visibility: tagging, allocation, and mapping spend to services and teams.

Koritsu AI's platform surfaces architecture-level signals, not just billing anomalies. Kori, the AI agent, identifies which services are driving cost growth and why, connecting billing data to the IaC and deployment patterns that caused it. That combination of automated signal and engineering expertise is what turns a one-time clean-up into a sustained reduction. Clients who combine the platform with hands-on FinOps support consistently find savings that a dashboard alone would not surface.

Your cloud bill is an architecture problem Koritsu AI can fix

Most of the spend you are carrying right now is not in your discount tier. It is in how your services were built: the cross-AZ calls, the hot storage that never ages out, the dev clusters running at weekends, the services nobody owns. Koritsu AI finds those patterns and helps your engineering team fix them, combining continuous AI-driven analysis with hands-on FinOps expertise.

The engagement starts with a free assessment. Koritsu AI's platform maps your spend to the architectural decisions driving it, and Kori surfaces the highest-return fixes specific to your environment. You pay only from the savings actually realised, verified against your billing data. From there, an ongoing subscription keeps the platform running and the savings compounding. If you are ready to move from guessing to knowing, start with the free assessment and see what your architecture is actually costing you.

This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.

Sources

For each phase of your programme, the sources below provide the deepest authoritative guidance: