Background

Spend efficiency¶

Spend efficiency means paying for what a workload needs and nothing it doesn't. In a cloud, every resource that exists is metered, so the decisions that shape the invoice are made every day by the people building and running workloads.

What the pillar covers¶

On a traditional platform, most spend happens up front: hardware is bought, and an idle virtual machine uses capacity that's already been paid for. In a cloud, spend follows use. An instance left running over a weekend, a volume nobody attached, a floating IP held "just in case": each one shows up on the next invoice. That makes waste visible, and it makes savings immediate.

Design principles¶

Principle	What it means in practice
Pay for what you use	Keep only the resources a workload needs today, and add more when it needs them
See where the spend goes	Organise projects so each team, environment or workload can be read on its own
Right-size	Run each instance at the size its load needs; see Performance efficiency
Delete what's idle	Remove instances, volumes, snapshots and floating IPs that nothing uses
Make short-lived things short-lived	Build temporary environments from code, use them, and delete them
Review regularly	Read usage and invoices, and look for what has grown or been forgotten
Weigh spend against the other pillars	Extra instances and a second region buy reliability; decide where that's worth it

Ephemeral and persistent resources¶

The biggest saving in a cloud is often not running something at all. That depends on separating what has to persist from what can be rebuilt.

	Ephemeral	Persistent
Examples	Test environments, build agents, instances behind a load balancer	Data volumes, databases, backups, object storage
Lifetime	Hours or days; deleted when the job is done	As long as the data is needed
How you get it back	Rebuild from code	Restore from a snapshot or backup
Where spend hides	Environments nobody deleted	Old snapshots and backups past their use

When instances can be rebuilt from code and their data lives on separate volumes, deleting an idle environment is safe. See Pets vs cattle.

What it looks like on Breqwatr Cloud¶

Billing is in CAD.
Usage is priced by resource. An instance is priced by its memory, with no charge for vCPUs; storage and floating IPs have rates of their own. Usage is measured by the hour. Resources marked as included carry no separate charge. The pricing page lists the rates.
Invoices are per project. Each billable project gets its own monthly invoice, issued on the first of the month for the month before. Separate projects for separate teams or environments give a separate invoice for each.
Usage is visible as it happens. Each project's usage page shows the current month's metered usage by resource type, and the billing overview projects the month's total from the current rate of use.
Quotas are set per region. Each project has its own quota in each region, which caps how much it can run there. A quota is a ceiling, not a charge: you're billed for what runs, not for unused quota.
Root volumes are deleted with their instance by default, so deleting an instance doesn't leave its disk behind. Data volumes, snapshots and floating IPs stay until you delete or release them.
An instance snapshot can keep a root volume. An instance snapshot of a volume-backed instance also snapshots its volumes, so after the instance is deleted its root volume can remain and keep being billed. It shows in the project's volume list as available. Delete the instance snapshot image, then the volume snapshots made with it, then the volume; see Instance snapshots and the root volume.
Windows Server images are available to every project, priced to include the licence. Other licensed operating systems, such as Red Hat Enterprise Linux, are quoted on request.

	Windows	Linux
Operating system licence	Windows Server images are priced to include the licence	Many distributions carry no licence charge; licensed ones, such as Red Hat Enterprise Linux, are quoted on request
Effect on right-sizing	The same principles apply: fewer, right-sized instances reduce both usage and licensing	The same principles apply

Impact¶

The invoice reflects what the workloads actually use.
Teams can see the spend of their own projects and act on it.
Savings come from routine habits, such as deleting what's idle and right-sizing, rather than one-off cuts.

Common anti-patterns¶

Forgotten environments: test or demo environments left running after the work ended.
Orphaned resources: volumes no longer attached to anything, floating IPs not associated with an instance, snapshots nobody will restore, and root volumes kept by an old instance snapshot.
Sized for the peak, all the time: paying every hour for capacity that's only needed at the busiest moments.
One project for everything: spend from every team and environment on one invoice, so nobody can tell which part grew.
Saving at reliability's expense without deciding to: removing the second instance or the backups to save money, without weighing what an outage would mean.