If you’ve already met the AWS FinOps Agent, you know it can watch your Bedrock-powered cost graph, catch an anomaly, and answer “why did EC2 spend jump 40% last Tuesday” in plain English. Cool trick. Also useless if it only runs when someone remembers to poke it. This article covers the part nobody puts in the keynote demo: setting up AWS FinOps Agent scheduled workflows that run on their own, route findings to the humans and systems that need them, and trigger downstream automation without you babysitting a console.
Stop treating the agent like a chatbot you have to remember to open
A FinOps agent that only responds to typed questions is a nice search interface for Cost Explorer. The value shows up when it runs on a cadence, unprompted, and pushes findings into the tools your team already lives in. That means three things have to exist: a scheduler, a routing layer, and a downstream action path with an approval gate. We’re covering all three, plus how they chain into Savings Plans and Compute Optimizer automation to close the loop.
Scheduling the agent with EventBridge Scheduler
Skip cron-on-an-EC2-box and skip Lambda-with-a-CloudWatch-timer-that-someone-forgot-about. EventBridge Scheduler is built for exactly this: one-off or recurring invocations at scale, with built-in retry policies, dead-letter queues, and flexible time windows so you’re not slamming Bedrock at the exact same millisecond as every other job in the account.
A daily anomaly sweep plus a weekly deep-dive report is a common pattern. Here’s the daily sweep, invoking a Lambda that calls the agent’s InvokeAgent API with a standing prompt:
aws scheduler create-schedule \
--name "finops-agent-daily-anomaly-sweep" \
--schedule-expression "cron(0 13 * * ? *)" \
--schedule-expression-timezone "America/New_York" \
--flexible-time-window '{"Mode": "FLEXIBLE", "MaximumWindowInMinutes": 15}' \
--target '{
"Arn": "arn:aws:lambda:us-east-1:123456789012:function:invoke-finops-agent",
"RoleArn": "arn:aws:iam::123456789012:role/finops-scheduler-exec-role",
"Input": "{\"promptType\": \"anomaly_sweep\", \"lookbackHours\": 24}",
"RetryPolicy": {
"MaximumRetryAttempts": 2,
"MaximumEventAgeInSeconds": 3600
}
}'
For the customer-set cadence piece — weekly, biweekly, whatever the FinOps lead wants — spin up a second schedule with a rate() or different cron() expression and a different prompt payload (e.g., "promptType": "weekly_optimization_digest"). Keep schedules and prompts decoupled from the Lambda code; store the prompt template in Parameter Store so a cadence change is a one-line update, not a redeploy. This is the same building block AWS uses under the hood for EventBridge-driven automation generally — just applied to a Bedrock agent invocation instead of a batch job.
Routing findings: Slack, EventBridge custom events, and tickets
Once the agent produces a finding, it needs to land somewhere a human or a system will actually see it. Three destinations cover almost every real setup:
- Slack, for anomalies that need eyes today. Either AWS Chatbot wired to an SNS topic, or a direct incoming webhook from a Lambda function parsing the agent’s structured output.
- EventBridge custom events, for anything downstream automation needs to react to — this is the connective tissue for the closed loop described below.
- Jira or ServiceNow tickets, for anomalies over a dollar threshold that need an owner and an SLA, not just a Slack message that scrolls away.
Have the agent’s output Lambda publish a custom event rather than calling three separate APIs directly — it decouples “the agent found something” from “here’s what happens next,” which matters the day you add a fourth destination and don’t want to touch the agent’s invocation code at all.
{
"Source": "custom.finops-agent",
"DetailType": "CostAnomalyDetected",
"Detail": {
"severity": "high",
"service": "AmazonEC2",
"estimatedMonthlyImpact": 8400,
"rootCauseSummary": "Untagged Auto Scaling group scaled to 3x baseline in us-west-2",
"recommendationRefs": ["cost-optimization-hub:rec-88213"]
},
"EventBusName": "finops-events"
}
Then a rule pattern fans that event out — Slack for everything, a ticket only for the expensive stuff:
{
"source": ["custom.finops-agent"],
"detail-type": ["CostAnomalyDetected"],
"detail": {
"severity": ["high"],
"estimatedMonthlyImpact": [{ "numeric": [">=", 5000] }]
}
}
Point that rule at a Lambda target that calls your Jira REST API or ServiceNow Table API to open a ticket pre-filled with the agent’s root-cause summary and a link to the Cost Optimization Hub recommendation ID. A lower-severity rule with a broader match, no dollar filter, targets an SNS topic feeding Chatbot into #finops-alerts. Nobody’s paging on-call for a $40 anomaly, but everybody sees it in Slack.
Closing the loop: agent findings feeding real automation
This is the part that separates “we have a FinOps dashboard” from “we have continuous cost control.” The agent detects and recommends; downstream automation acts; the loop reports back on what happened. Three concrete wiring patterns:
1. Compute Optimizer recommendations flowing through the agent
When the FinOps Agent surfaces a rightsizing opportunity, it’s typically citing a Compute Optimizer finding underneath. Say a fleet of memory-bound R7g instances is sitting at 90%+ memory utilization and Compute Optimizer flags a migration to the newly GA’d EC2 R9g/R9gd Graviton5 instances. The agent’s weekly digest event carries that recommendation ID; an EventBridge rule matching recommendationRefs triggers a Lambda that applies a low-risk, pre-approved change (non-prod fleets) automatically via the Auto Scaling group’s launch template, while anything touching production queues into the ticketing path above for a human sign-off. Same closed loop, different blast radius, different approval gate.
2. Savings Plans purchase automation
The agent can flag sustained, steady-state usage still running on-demand — classic Savings Plans territory. Rather than manually running Savings Plans math every month, route that finding to a Lambda that calls the Savings Plans recommendation API, checks it against a spend-commitment ceiling you’ve set, and either auto-purchases below a threshold or drops a ticket for finance sign-off above it. This is where “appropriate approval gates” earns its keep — nobody wants an agent auto-committing to a three-year Savings Plan unsupervised.
3. Reporting back on outcome
A closed loop isn’t closed if nobody confirms the fix worked. Have whatever executed the action — the rightsizing Lambda, the Savings Plans purchase function — publish its own EventBridge event (ActionCompleted, with before/after cost deltas) back onto the same bus. Feed that into the agent’s next scheduled run as context, and the weekly digest can report “3 of 4 recommended actions completed, realized savings of $2,100/mo, 1 pending approval” instead of just listing recommendations nobody can tell got actioned. That feedback loop is what makes the next round of agent output trustworthy instead of noise.
A few things that will bite you if you skip them
- Idempotency keys on every downstream Lambda — EventBridge is at-least-once delivery, and a duplicated ticket or Savings Plans purchase call is not a fun incident to write up.
- Dead-letter queues on every EventBridge target, so a downed Slack webhook doesn’t silently swallow an event.
- Separate schedules per cadence rather than one giant Lambda with internal day-of-week logic — Scheduler’s built-in retry and monitoring beats debugging a monolith.
- Threshold tuning per environment — a $5,000 anomaly is noise in a $2M/month production account and a five-alarm fire in a $50K/month dev account.
None of this requires reinventing the agent itself. It requires treating it like any other production workload: scheduled, observable, wired into the systems your team already trusts, with clear approval gates on anything touching spend directly. The FinOps community circling this pattern at events like FinOps X and in coverage from FinOps Weekly keeps landing on the conclusion the FinOps Foundation has pushed for years — crawl-walk-run applies to automation as much as tagging discipline. Detection without action is a dashboard. Action without approval gates is a liability. Get both right and you’ve got a system that pays for itself every month, on a schedule, without anyone opening the console.
At Enkompass (enkompass.net), this is our home turf. We’ve clawed back six figures in annual spend for clients who thought their bill was “already optimized.” If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.