Alibaba OSS Storage Class Cost Governance Sentinel

An Alibaba Cloud OSS lifecycle rule that is missing, misconfigured, or scoped to the wrong prefix lets objects sit on the expensive Standard storage class indefinitely instead of transitioning to Infrequent Access, Archive, or Cold Archive - a cost drift that is invisible until a monthly bill review. This blueprint lists objects on a schedule and alerts Slack with the exact keys, sizes, and ages of anything still on Standard well past a configured age threshold.

How it works

1. periodic_storage_class_check (io.kestra.plugin.core.trigger.Schedule) runs once a day, explicitly passing alibaba_region, bucket_name, object_prefix, max_object_age_days, and max_files_to_scan through its own inputs: block so the flow is self-contained when the trigger fires. Shipped disabled so a manual run can be verified first.
2. probe_list_objects (io.kestra.plugin.alibaba.oss.List) lists up to max_files_to_scan objects under object_prefix, capturing each object's key, size, lastModified, and storageClass.
3. evaluate_storage_class_drift (io.kestra.plugin.core.flow.If) branches on whether any returned object is still Standard class and older than max_object_age_days.
   • then (STORAGE_CLASS_DRIFT_DETECTED): alert_storage_class_drift reports every flagged object's key, size, and age to Slack.
   • else (HEALTHY): log_storage_class_healthy records the clean pass along with how many objects were scanned.
4. log_audit_complete always runs last, printing the total objects scanned regardless of which branch fired.
5. The errors block alerts Slack separately if the flow itself fails outright - a missing bucket or invalid credentials.

What you get

• A cost governance signal built on OSS's own storageClass and lastModified fields, not a separately-maintained spreadsheet of what should have transitioned by when.
• The exact key, size, and age of every drifted object in the Slack alert itself, so a lifecycle policy fix can be scoped precisely instead of guessing which prefix is affected.
• A worked example of io.kestra.plugin.alibaba.oss.List combined with jq's fromdateiso8601/now date-window pattern, reusing the same approach this repository's AWS Certificate Manager sentinel established, applied here to a completely different plugin with no prior blueprint coverage at all.

Who it's for

• Platform and FinOps teams running workloads on Alibaba Cloud who want to catch storage-class drift before it shows up as an unexplained cost increase.
• Teams who configured an OSS lifecycle rule once and have no ongoing way to verify it is still matching the objects it was meant to, especially after a prefix or naming convention changes.
• Anyone evaluating the Alibaba plugin who wants a worked example of its OSS List task used for governance monitoring rather than for basic data ingestion.

Why orchestrate this with Kestra

OSS lifecycle rules run silently and have no built-in "alert me if objects aren't transitioning as expected" primitive - a rule that stopped matching due to a prefix change produces no error, just a growing Standard-tier footprint. Kestra supplies the schedule, the HEALTHY/STORAGE_CLASS_DRIFT_DETECTED classification as a first-class branch, and an execution history showing exactly when drift was first detected and for which objects.

Prerequisites

• An Alibaba Cloud account with an OSS bucket containing objects (update alibaba_region, bucket_name, object_prefix).
• Alibaba Cloud AccessKey credentials with read access to the bucket - entirely read-only, cannot delete, copy, or modify any object.
• A Slack incoming webhook for alerts.

Local testing: Alibaba Cloud publishes its own lightweight, Ruby-based OSS-Emulator for testing and debugging against the same OSS APIs, and the List task's own endpointOverride and pathStyleAccess properties are explicitly documented as being "useful with custom endpoints such as a local emulator." Exact Docker packaging and current maintenance status of that emulator were not independently confirmed; a real Alibaba Cloud account remains the most complete way to exercise this blueprint.

Secrets

• ALIBABA_ACCESS_KEY_ID / ALIBABA_ACCESS_KEY_SECRET: credentials for io.kestra.plugin.alibaba.oss.List.
• SLACK_WEBHOOK_URL: Slack incoming webhook used by alert_storage_class_drift and the errors block.
• In Kestra OSS (no Enterprise secrets backend), secrets are supplied as environment variables prefixed SECRET_, base64-encoded - for example SECRET_ALIBABA_ACCESS_KEY_SECRET=$(echo -n '<your-secret-key>' | base64) - and read back in flows with {{ secret('NAME') }}.

Inputs

Input	Type	Default	Description
alibaba_region	STRING	cn-hangzhou	Alibaba Cloud region the OSS endpoint is derived from
bucket_name	STRING	REPLACE-WITH-YOUR-BUCKET-NAME	The target OSS bucket to audit
object_prefix	STRING	""	Optional key prefix to scope the audit
max_object_age_days	INT	90	Inactivity age threshold in days for Standard-tier objects
max_files_to_scan	INT	1000	Max objects returned by List (capped at 1000 limit)

Outputs

• outputs.probe_list_objects.objects (list): every scanned object's key, size, etag, lastModified, and storageClass (verified fields from the List task's own OssObject model).

Quick start

1. Identify a real OSS bucket with objects on the Standard storage class.
2. Add the ALIBABA_ACCESS_KEY_ID, ALIBABA_ACCESS_KEY_SECRET, and SLACK_WEBHOOK_URL secrets.
3. Run the flow manually and confirm log_storage_class_healthy fires if nothing is drifted.
4. Temporarily lower max_object_age_days below the real age of a known Standard-tier object, and re-run to confirm alert_storage_class_drift fires with the correct key and age.
5. Enable periodic_storage_class_check once you trust the check against your real bucket.

How to extend

• Loop over several bucket_name/object_prefix combinations with io.kestra.plugin.core.flow.Loop to audit multiple buckets or logical folders in one run.
• Lower max_object_age_days progressively and track the flagged count over several executions (via Kestra's own execution history) to see whether drift is growing or shrinking after a lifecycle policy fix.
• Add a remediation branch using io.kestra.plugin.alibaba.oss.Copy to re-upload a drifted object with an explicit storage class override, behind an explicit approval gate - deliberately kept out of this sentinel so the monitoring path never changes storage class on its own.

Pitfalls

• List caps results at maxFiles (hard limit 1000, default 25) - verified directly from the task's own Javadoc, which logs a warning when more objects match. A bucket or prefix with more objects than max_files_to_scan will only have its first page audited; this blueprint does not paginate beyond that cap.
• The regular-expression-based regexp filter is intentionally unused here - the task's own Javadoc notes it is time-boxed against catastrophic backtracking and limited to 256 characters, which is a safety feature worth knowing about if you extend this blueprint to filter by key pattern.
• This blueprint is UNTESTED against a live Alibaba Cloud account. The task class, its OssObject output fields (key, size, etag, lastModified, storageClass), and the OSS storage class names are taken verbatim from the plugin's own source - but no Kestra engine was run to execute this flow end to end.

Links

• Kestra Alibaba plugin documentation
• Alibaba Cloud OSS overview
• Kestra secrets (OSS vs Enterprise)