Raphael Gab-Momoh

Posted on Sep 17 Originally published at raphaelgmomoh.pages.dev

FinOps on Alibaba Cloud: Cost Visibility, Governance, and Optimization at Scale

#finops #alibabacloud #costoptimization #governance

Why FinOps Doesn't Change, Only the Tooling Does

FinOps as a discipline — the FOCUS principles of visibility, accountability, and optimization applied continuously rather than as a quarterly cost review — is provider-agnostic. What changes moving from Azure to Alibaba Cloud is purely which console, API, and pricing construct you're operating: BSS OpenAPI instead of Cost Management, Reserved Instances / Savings Plans with Alibaba's own discount curve, and Cloud Monitor + Resource Manager instead of Azure Monitor + Resource Graph.

The strategic framework — allocate, analyze, optimize, automate — carries over completely. This guide walks through actually running that loop on a real Alibaba Cloud account: pulling a real BSS OpenAPI cost report, finding real idle-instance candidates via Cloud Monitor, and enforcing tagging with a policy that genuinely denies untagged spend rather than just recommending it. The scripts are in the companion repo, runnable as-is.

Before the how, the what — three terms this guide leans on:

FinOps — the practice of treating cloud cost as an ongoing engineering concern rather than a once-a-quarter finance review. The core loop is allocate (know which team/project a cost belongs to), analyze (find waste and inefficiency), optimize (fix it), automate (stop needing a human to repeat the first three steps every month).
Reserved Instance / Savings Plan — a discount you get by committing to a certain amount of compute usage for 1-3 years upfront, in exchange for a lower rate than pay-as-you-go pricing. A Reserved Instance commits to a specific instance type; a Savings Plan commits to a spend level with more flexibility in what you run — the tradeoff is discount depth (RI) versus flexibility (Savings Plan).
Cost allocation tags — labels attached to a resource (like cost-center: platform-eng) that let a billing system attribute spend to a specific team, project, or environment. Without consistent tagging, a cost report can tell you the total bill but not whose spend it actually is — which is why untagged spend is effectively invisible spend, however large the bill is.

1. Cost Visibility: BSS OpenAPI and Cost Allocation Tags

Alibaba Cloud's Billing and Settlement Service (BSS) is the programmatic equivalent of the Azure Cost Management API.

aliyun bssopenapi DescribeInstanceBill \
  --BillingCycle 2026-09 \
  --ProductCode ecs \
  --Granularity MONTHLY

Cost allocation depends entirely on tagging discipline — exactly as it does in Azure. Enforce mandatory tags (cost-center, environment, owner, project) at resource creation via Resource Manager policies, not as a retroactive cleanup exercise:

resource "alicloud_resource_manager_policy" "require_tags" {
  policy_name     = "require-cost-center-tag"
  policy_document = jsonencode({
    Version = "1"
    Statement = [{
      Effect = "Deny"
      Action = "ecs:RunInstances"
      Resource = "*"
      Condition = {
        StringNotEqualsIfExists = {
          "aliyun:CostCenter" = "*"
        }
      }
    }]
  })
}

Untagged spend is invisible spend — no allocation model can retroactively assign cost to a resource nobody tagged, which is the single most common reason a FinOps practice stalls at the "visibility" stage on any cloud.

2. Commitment Discounts: RI and Savings Plans

Alibaba Cloud offers both Reserved Instances (capacity-and-instance-type specific, similar to Azure RIs) and Savings Plans (compute-family-flexible commitment, similar to Azure's Compute Savings Plans). The decision framework is identical to the one used on Azure:

Stable, predictable baseline workloads (the floor of your usage that never scales down) → Reserved Instances, 1- or 3-year term, for the deepest discount.
Workloads that shift shape (instance family/size changes over time) → Savings Plans, for commitment flexibility at a slightly lower discount than a matched RI.
Bursty, interruption-tolerant workloads → Spot Instances, layered on top of the committed baseline.

A mature commitment strategy typically lands around 60–70% of baseline compute on RIs/Savings Plans, leaving headroom for on-demand and Spot to absorb variability — over-committing past your true floor turns a cost-optimization tool into locked-in waste the moment a workload gets decommissioned.

3. Right-Sizing: Finding the Idle and the Oversized

aliyun cms DescribeMetricList \
  --Namespace acs_ecs_dashboard \
  --MetricName CPUUtilization \
  --Period 86400 \
  --StartTime "2026-08-01 00:00:00" \
  --EndTime "2026-09-01 00:00:00"

Pull 30 days of CPU/memory utilization per instance via Cloud Monitor, then flag anything sitting under ~15–20% average utilization as a right-sizing candidate — the exact same threshold-based triage used against Azure Advisor's underutilized VM recommendations. Automate the query and route results into a weekly report; a right-sizing exercise that requires someone to remember to run it manually decays within a quarter.

4. Automated Waste Elimination

The highest-leverage FinOps automation isn't dashboarding — it's automatically reclaiming known categories of waste:

Unattached OSS-backed disks past a grace period (mirrors orphaned Azure Managed Disks after VM deletion).
Idle SLB instances with zero backend targets for 14+ days.
Unused Elastic IPs billed whether attached or not.
Non-production environments left running outside business hours — schedule ECS start/stop via Cloud Assistant or a scheduled Function Compute job, the equivalent of Azure Automation start/stop schedules.

# Example: nightly stop of all dev-tagged instances outside business hours
aliyun ecs DescribeInstances --Tag.1.Key environment --Tag.1.Value dev \
  | jq -r '.Instances.Instance[].InstanceId' \
  | xargs -I{} aliyun ecs StopInstance --InstanceId {}

5. Governance: Budgets and Anomaly Alerts

aliyun bssopenapi CreateCostUnit --UnitName "platform-engineering"

Pair Resource Manager cost units (Alibaba's equivalent of Azure Management Groups for cost rollup) with budget alerts at 50/80/100% thresholds per business unit, and a day-over-day anomaly alert on total spend — the same layered-alert pattern that catches both slow budget creep and a sudden runaway resource (a misconfigured autoscaler, a forgotten Spot fleet) before it becomes a five-figure surprise at month-end.

6. The Reporting Cadence

A FinOps practice that only produces a report nobody reads is theater, not discipline. The cadence that actually changes behavior:

Weekly — automated right-sizing and idle-resource report to platform engineering.
Monthly — cost-per-business-unit review against budget, presented to engineering leads, not just finance.
Quarterly — commitment discount coverage review (RI/Savings Plan renewal, coverage ratio vs. actual usage).

Closing Thoughts

Nothing about FinOps fundamentally changes crossing from Azure to Alibaba Cloud — the same allocate → analyze → optimize → automate loop, the same tagging discipline, the same commitment-discount tradeoffs. What this exercise demonstrates is that cloud economics expertise is a transferable engineering discipline, not a certification tied to one provider's cost dashboard — which is precisely the kind of cross-cloud fluency that distinguishes a FinOps practitioner from someone who's simply memorized one vendor's pricing page.

GitHub Repository: finops-alibaba-cloud-lab — the cost-visibility, idle-detection, tag-enforcement, and automation scripts, ready to run.

FinOps · Alibaba Cloud · Cost Optimization · BSS OpenAPI · Reserved Instances · Governance

Originally published on my portfolio.

DEV Community