Pay for the cloud you actually use

In most accounts we review, a few categories explain the bulk of the waste. Compute that is larger than it needs to be comes first, since sizes are chosen at launch and rarely revisited. Next are resources that nobody uses: disks left behind when a server was deleted, snapshots from years ago, load balancers pointing at nothing, test environments someone forgot. Then come storage kept in a premium tier when it is rarely read, and data transfer between regions or out to the internet, which is easy to overlook until it appears as a line item.

The audit starts by exporting the detailed billing data and matching it against the real inventory. We look at utilization over at least two weeks, so that a quiet Tuesday is not mistaken for the normal pattern. Each finding is listed with its monthly cost, the effort to fix it, and the risk of changing it. You choose what to act on, and we do the work in order of savings per hour of effort.

Expect the first round of quick wins within 2 to 4 weeks. Deeper changes, such as moving a workload to a different service or redesigning data storage, take longer and are priced separately once we know what they would save.

Providers offer lower prices if you commit to a steady level of usage for one or three years. This is worth doing for the part of your load that never drops, such as the production database. It is a mistake for anything you might change soon. We cover the stable base with commitments, leave the variable part on regular pricing, and revisit the mix every quarter so a past decision does not lock you into the wrong capacity.

Scheduling is simpler and often larger. A staging environment used from 8 in the morning to 6 in the evening on five days a week is idle for about two thirds of the hours in a month. Switching it off outside those hours cuts its cost accordingly, and the schedule is a few lines of code.

Total spend is a poor measure on its own, because growth should raise it. We therefore report unit cost: the cloud cost per order, per active user or per thousand requests. When the unit cost falls while the business grows, the optimization is working. When total cost rises and the unit cost holds, you are growing. This is the discipline described by the FinOps Foundation, and it gives finance and engineering one shared number to discuss.

Saving money must not break the rules that govern your data. A cheaper region outside the Kingdom may be off the table for personal data under PDPL or for regulated workloads under the cloud framework published by the Communications, Space and Technology Commission. We treat the allowed regions as a fixed constraint and optimize inside it, and we flag any saving that would require a residency decision from you.

In-Kingdom capacity is available from AWS, Google Cloud, Oracle, STC Cloud and Alibaba Cloud in Riyadh, with different prices and service lists. When a client's workload fits more than one, a price comparison for the specific services used is part of the work, and the result goes in writing.

We also warn against false savings. Deleting backups to cut storage cost, running production on undersized instances, or turning off monitoring to save a little each month all move cost into risk. Every recommendation we make includes what could go wrong and how we would detect it.