Cloud Cost Optimization in Malaysia: A FinOps Primer for Enterprises

Cloud cost work fails for a predictable reason: it is attempted in the wrong order. Teams buy commitments before rightsizing, or launch a FinOps operating model before anyone can attribute a single line of spend to a team. Aqvantiq is a multi-cloud AI system integrator in Kuala Lumpur that runs cost reviews as part of every managed cloud retainer. This is the sequence we work, the thing that usually blocks each step, and the one cost lever that is genuinely specific to Malaysian workloads.

What order should you work cloud cost in?

Three phases, and they are not interchangeable: make spend visible, remove waste, then change the architecture. Most bills fall in phase two without anyone touching the design — untagged resources, oversized instances, non-production running at 3am, snapshots kept forever. Only after that do commitments and placement decisions make sense, because you finally have a baseline worth committing to.

The failure mode is doing phase three first. Re-platforming a workload to save money, before you know which workload is actually expensive, spends engineering time you cannot get back on a hypothesis.

Why do FinOps programs stall here specifically?

Because the operating model gets sold ahead of the prerequisites. Writing on FinOps in Malaysia on 20 June 2025, Alphaus argues that “most Malaysian financial institutions currently operate at the Early to Developing stages” of FinOps maturity — the author’s own characterisation, not a survey. It defines those stages as basic cost visibility, manual reporting and initial tagging strategies (Early), and formalised governance, regular reporting and basic cost allocation (Developing) — as against automated optimization, predictive forecasting and full chargeback models at the Advanced stage.

That is not a criticism, it is a starting position. It means the first deliverable of a Malaysian FinOps engagement is almost never a forecasting model. It is tagging that works, and a report somebody actually reads.

What are the six cost levers, and what blocks each one?

These are the levers in the order we normally work through them. The third column is the reason each one is still undone in most estates — and it is nearly always organizational, not technical.

Two of these deserve a warning label.

Log and metric retention is a cost centre disguised as good practice. Observability spend grows quietly, is defended on principle, and is almost never given a stated retention period. Set one deliberately, per signal, and revisit it when the bill moves.

Network path charges are the ones nobody graphs. NAT Gateway data processing, cross-availability-zone chatter between services that should have been co-located, and egress leaving through the wrong path are all invisible on a per-service cost view and obvious on a per-usage-type one.

Where does the money actually go on AWS?

Almost always compute you are not using, storage you never expired, and network paths nobody graphed. Worked in order:

1. Compute rightsizing and modern instance families. Match instance size to measured utilization, and move eligible workloads to current-generation and Graviton-based families.
2. Non-production schedules. Development and test environments do not need to run outside working hours. This is usually the fastest saving available and needs no design change.
3. Commitment cover. Savings Plans and Reserved Instances against a baseline you can actually forecast — after rightsizing, never before it.
4. Storage class and lifecycle. gp2 volumes moved to gp3, S3 lifecycle rules and Intelligent-Tiering applied, snapshot and log retention finally written down.
5. Network path and data transfer. NAT Gateway data processing, cross-AZ chatter, and egress through the wrong path.
6. Idle and orphaned resources. Unattached EBS volumes, unused Elastic IPs, load balancers with no targets, old AMIs and snapshots.
7. Region placement, once residency and latency have been checked — see below.

Is region placement really a cost lever in Malaysia?

Yes, and it is the one lever on this list that is genuinely local. AWS opened its Asia Pacific (Malaysia) Region, ap-southeast-5, with three Availability Zones on 21 August 2024. FinOps vendor usage.ai states that the region “offers EC2 pricing approximately 13% below ap-southeast-1 for the same instance types” (usage.ai, updated 29 July 2026).

Read that carefully before it goes anywhere near a business case. It is a compute figure, from a vendor blog, unsourced within the article itself. We publish it because it is the one dated, attributable number in this space that we can point at — not because it settles the question. Three things decide whether it survives contact with your own bill:

• Your service mix. If compute is most of your spend, the delta lands near the headline. If you are mostly managed services, data transfer and licences, it does not.
• Your existing commitments. Compute Savings Plans apply across regions; EC2 Instance Savings Plans and Reserved Instances are scoped. A stranded Singapore commitment can wipe out a year of savings.
• Cross-region chatter. Split one system across Malaysia and Singapore and you pay inter-region transfer on every hop, forever.

There is also a one-off cost to the move itself: data transfer out of the current region is a real bill that can eat a year of savings on a small estate. We model target-state cost against actual usage before recommending a region change, and treat the move as a migration in its own right — inventory, dependency map, wave plan, rehearsed cutover, rollback position. A region move is not a configuration change. The full trade-off table is in the AWS Malaysia guide, and the residency half of the decision is in the Malaysian cloud compliance guide.

What should a monthly cost review actually contain?

A review that produces decisions, not a chart. Six things, every month, each finding carrying an owner and an expected saving:

• Spend by service and by environment, compared with the previous month.
• Rightsizing candidates based on observed utilization, not on instance names.
• Commitment coverage and expiry dates, so discounts do not lapse unnoticed.
• Storage class and lifecycle rules, including snapshots nobody has deleted.
• Tagging quality, so cost can be attributed to a team or product at all.
• Log and metric retention.

The review is worthless if the findings are applied by hand. Rightsizing decisions, lifecycle rules and non-production schedules go into Terraform, so next quarter’s environment starts from the corrected baseline instead of drifting back to the old one within a release cycle. That is the same code path we build under DevOps as a Service, and the reason cost work and platform work belong in the same engagement rather than in two.

What we will not tell you

We do not publish a headline saving percentage. The honest number depends entirely on how your estate was built, and a percentage quoted before anyone has seen your Cost and Usage data is marketing. What you get is the breakdown before we start and the same breakdown after, from your own billing data.

We also will not sell you a FinOps operating model before you can attribute spend to a team. If tagging is broken, that is the project — everything else is downstream of it.

Cloud pricing and regional catalogues change constantly. Every figure above is dated and linked to its source so you can re-check it, and where a number is vendor-published rather than independently verified we have said so. Anything we could not source, we left out.

Want the same review run against your estate? Talk to us — send the shape of the bill and we will tell you which of the six levers is actually holding your money, including when the answer is that your bill is already reasonable. The design-side view is on cloud architecture, and ongoing reviews run under managed cloud services.