New to Kestra?
Use blueprints to kickstart your first workflows.
Watch AWS spend while the month runs. Query Cost Explorer daily, compare month-to-date vs the same window last month, and alert Slack when costs spike.
Cloud bills surprise people because spend is invisible between invoices: a runaway batch job, a leaked NAT Gateway, or a traffic spike can run for weeks before anyone sees a number. This blueprint checks the pace of spending while the month is still running. It queries the AWS Cost Explorer API for month-to-date UnblendedCost grouped by service, queries the identical day-range one month earlier for a like-for-like baseline, computes the percent change in Python, and lets an If task compare it against your threshold — over it, Slack gets the measured numbers and the top service with time left to react.
compute_windows (io.kestra.plugin.scripts.python.Script on the io.kestra.plugin.core.runner.Process runner) builds two windows: this month from the 1st through tomorrow (Cost Explorer's End is exclusive), and the same number of days starting at the 1st of the previous month. Comparing identical day-ranges avoids the classic mistake of judging a partial month against a full one.fetch_current_by_service (io.kestra.plugin.aws.cli.AwsCLI) runs aws ce get-cost-and-usage for the current window with --granularity DAILY --metrics UnblendedCost --group-by Type=DIMENSION,Key=SERVICE, emitting a flat [service, amount] list through stdOut.fetch_previous_by_service runs the identical query for the earlier window, producing the baseline in the same shape.compare_spend (Python) totals both payloads per service, rounds the month-to-date and baseline totals to cents, computes the percent change against a $0.01 floor — so brand-new spend against an empty baseline always trips the guard — and picks the leading service from the current window.check_spike (io.kestra.plugin.core.flow.If) compares pct_change with the spike_threshold_pct input. Over it, alert_spike posts both totals, the percent change, and the top service to Slack; under it, log_on_track keeps a quiet record so the execution history shows the month's trajectory.errors block alerts Slack when the guard itself fails, and a daily Schedule trigger (shipped disabled) drives the cadence once enabled.cost_summary JSON output (current cost, baseline, percent change, top service) for dashboards or downstream flows.Cost Explorer exposes the numbers, but an API nobody polls prevents nothing. Kestra provides the loop around it: a schedule, retries on flaky API calls, a Python step for the window arithmetic with no infrastructure of its own thanks to the Process runner, a branch that separates alerting from quiet record-keeping, and an execution history that becomes a day-by-day audit of the month. Plain cron scripts give you none of the observability, replay, or alert routing that orchestration adds around the same two CLI calls.
ce:GetCostAndUsage. Cost Explorer data can lag up to 24 hours, so very early-month runs compare against partially populated data.ce endpoint is only served from us-east-1 and us-west-2 — keep the aws_region input on one of those.AWS_ACCESS_KEY_ID: AWS access key with ce:GetCostAndUsage permission.AWS_SECRET_ACCESS_KEY: secret key matching the access key.SLACK_WEBHOOK_URL: Slack incoming webhook URL for spike and failure alerts.cost_summary (and the logs) to see your real month-to-date trajectory.spike_threshold_pct to a sensible margin above your normal month-over-month variance.disabled: false on the daily_cost_check trigger.compute_windows, or against a 30-day rolling window for always-on services.If on an absolute floor (for example, alert above $50 even when the percentage is calm) to catch slow, steady creep.--group-by Type=DIMENSION,Key=LINKED_ACCOUNT instead of SERVICE.then branch.get-cost-and-usage API reference