nOps 如何借助 Amazon Bedrock AgentCore 将 FinOps Agent 上线速度提升 75%

nOps 是一家由 AI 驱动的云优化解决方案提供商。该公司近期通过迁移至 Amazon Bedrock AgentCore，重新构想了其财务运营（FinOps）分析能力。Amazon Bedrock AgentCore 是一项可使用任意框架或模型，大规模构建、连接和优化 Agent 的服务。新的基础架构帮助 nOps 更好地服务于在 Amazon Web Services（AWS）、Google Cloud Platform（GCP）和 Microsoft Azure 上管理承诺优化的客户。通过持续优化 Reserved Instances 和 AWS Savings Plans 等承诺项目，nOps 帮助团队最大化节省、降低风险，并自动化消除手动 FinOps 带来的运维负担。目前，nOps 所支持客户的云支出管理规模已超过 40 亿美元。

本文将介绍 nOps 如何利用 Amazon Bedrock AgentCore、Databricks Lakehouse Metric Views、Databricks Lakebase、Amazon DynamoDB 和 Vercel，迁移其分析及 Agent 体验，以加快产品交付、提升响应质量并降低运维复杂度。

突破以 API 为中心基础设施的局限，扩展 FinOps AI

随着产品组合和客户群的扩大，基础设施、前端和后端团队需要在保持高可靠性和多租户隔离的同时，支持日益复杂的分析工作流。现有基础设施模式带来了阻力：

• 响应延迟与不一致： 基于 API 的数据访问产生了较长的上下文消息，增加延迟并降低响应一致性。
• 系统复杂性： 多个编排与可观测性层增加了系统复杂度。
• 创新阻力： 工程时间越来越多地消耗在基础设施维护上，而不是产品创新上。

“我们试图在并非为分析驱动型 Agent 而设计的基础设施之上构建先进 AI 能力，这使迭代变得缓慢、复杂，并且容易出现不准确的结果。”

— Jordan Stein

现有状态

在迁移前，我们在现有基础设施组件之上推出了 FinOps AI Agent Clara，其中包括 Kubernetes、Amazon Bedrock 模型调用、LangChain/LangGraph 编排，以及围绕 Web API 构建的工具封装层。

这让我们能够快速完成初始交付，但也暴露了结构性限制：

• 获取洞察的速度较慢： API 形式的数据和大型上下文窗口增加了单轮交互延迟。
• 运维开销： 多个并非为此专门构建的层级，使迭代和调试更加困难。
• 数据路径不匹配： Agent 的回答依赖 API 响应，而非专用的语义分析层。

为解决这些问题，我们转向以 Amazon Bedrock AgentCore 为运行时与编排中心、以 Databricks Metric Views 提供受治理的分析语义、以 Databricks Lakebase 保存持久应用状态的专用架构。我们选择 Bedrock AgentCore，是因为它提供托管 Agent 运行时、内置记忆和编排能力，同时允许自由使用任意框架或模型。借助这种自由度，我们基于 Strands 构建，并在不更换服务的情况下演进模型选择，使团队能够专注于领域逻辑而非基础设施。

解决方案概览

我们将新架构设计为能够随需求扩展、产出准确回答，并让开发者更快完成发布。

下图展示了基于 Amazon Bedrock AgentCore 构建的 nOps Clara 解决方案端到端架构：

图 1：Amazon Bedrock AgentCore 上 nOps Clara 解决方案的端到端架构

该解决方案包括：

1. 交互层： 由 Vercel 托管的 Next.js Web 应用，客户通过由流式 Server-Sent Events 支持的对话界面与 Clara 交互。
2. Agent 运行时层： Amazon Bedrock AgentCore 运行一个基于 Strands 的单 Agent，能够直接访问画布操作、查询执行、数据源发现和工作流编排工具，从而减轻多 Agent 路由开销。
3. 数据层： Databricks Lakehouse Metric Views 提供受治理的语义分析层；Databricks Lakebase（无服务器 PostgreSQL）存储会话、画布和小组件规格等持久应用状态。
4. 异步工作流层： 针对长时间运行的分析任务，使用 Amazon DynamoDB 作业跟踪、Amazon Simple Notification Service（Amazon SNS）与 Amazon Simple Queue Service（Amazon SQS）通知，以及 Amazon API Gateway WebSocket 推送的事件驱动执行路径，可实时更新 UI。

Web 应用

在交互层，客户通过由 Vercel 托管的 Web 应用使用 Clara。请求流经 Next.js Backend for Frontend（BFF），随后调用 Amazon Bedrock AgentCore。Clara 作为基于 Strands 的 Agent 运行时运行，支持流式响应和工具调用。用户可以手动调用与 Clara 通过 Strands 工具调用的相同工作流。 这是 Clara 的一项重要要求和基础构件，因为它要求 Agent 按照人类在产品需求规定下会采取的相同流程执行任务。

Amazon Bedrock AgentCore 后端

运行时作为 Docker 容器部署在 Amazon Bedrock AgentCore 上，完整基础设施，包括运行时、记忆、护栏、队列和工作函数，均在单个 AWS Cloud Development Kit（AWS CDK）堆栈中定义。Clara 使用单 Agent 架构，而非多 Agent 路由器：一个 Strands Agent 可直接访问以下工具：画布操作、查询执行、数据源发现和工作流编排。这避免了 Agent 之间交接导致的延迟和错误传播开销，同时使工具分发保持确定性。

流式传输是体验的核心。一个自定义合并层位于 Strands 异步流和 Server-Sent Event 输出之间，可在一次处理中完成三项工作：

1. 心跳机制在长时间工具执行期间保持连接存活。
2. 具备词边界感知刷出能力的文本缓冲区，将较小的模型增量合并为易读片段，以帮助防止用户界面（UI）闪烁。
3. 小组件轮询工作器将实时画布更新事件交错插入同一数据流中。

Clara 使用 AgentCore memory 的三种策略，即语义事实、用户偏好和画布摘要，因此它能够随着时间了解每位用户如何与其数据交互。偏好会影响布局选择、默认聚合方式和图表类型。事实会记录账户结构和成本分摊惯例等组织上下文。画布摘要会跨会话保留分析脉络，使用户能够从上次中断处继续，而无需重新说明上下文。会话按画布而非短暂的 HTTP 会话划分，因此对话上下文能够在浏览器刷新和重新连接后持续保留。

为实现租户隔离，Amazon Bedrock Guardrails 会在调用 Agent 前，对原始用户提示词执行独立预检查，以实施跨租户数据访问策略和提示词攻击检测。随后，租户策略层会清理出站流片段和小组件事件，在其到达前端前对内部标识符进行脱敏。

数据湖仓

在数据层，Clara 不再依赖通用产品 API 获取分析上下文。相反，它使用精选工具，针对由 Databricks Lakehouse Metric Views 支持的 Databricks SQL Warehouse 执行结构化查询语言（SQL）查询。这为度量和维度提供了受治理的语义层，提升了对话回答与仪表板输出之间的一致性。

示例

Metric Views 与原始 SQL 的对比（真实客户成本）

用户提问：“按账户显示我过去 30 天的真实 AWS 成本。”

原始 SQL Model Context Protocol（MCP）方法： 工具必须每次都针对各种 AWS 定价计划和基于承诺的折扣重新计算业务逻辑，然后在按账户分组之前，对这些值进行联接和规范化。

-- Raw SQL MCP approach
-- User asks: "True Customer Cost for last 30 days by account"
SELECT
    a.account_name,
    SUM(
        -- Base amortized cost
        COALESCE(c.amortized_cost, 0)
        -- Apply EDP discount
        - COALESCE(c.edp_discount_amount, 0)
        -- Apply PPA credits
        - COALESCE(c.ppa_credit_amount, 0)
        -- Add RI effective amortized component
        + COALESCE(c.ri_effective_cost, 0)
        -- Add Savings Plan effective amortized component
        + COALESCE(c.sp_effective_cost, 0)
    ) AS true_customer_cost
FROM raw_cost_and_usage c
JOIN account_dim a
    ON c.account_id = a.account_id
LEFT JOIN pricing_adjustments p
    ON c.account_id = p.account_id
    AND c.usage_day = p.usage_day
WHERE c.usage_day >= date_sub(current_date(), 30)
    AND c.usage_day < current_date()
    AND c.charge_type NOT IN ('Credit', 'Refund')
GROUP BY a.account_name
ORDER BY true_customer_cost DESC;

Metric View MCP 方法： 工具使用维度（account_name）和时间范围（过去 30 天），查询一个预定义度量，并利用详细注释和同义词，例如 true_customer_cost。

-- Metric View MCP approach
-- Same user ask, but financial logic is pre-modeled in metric view measure
SELECT
    account_name,
    SUM(true_customer_cost) AS true_customer_cost
FROM mv_true_customer_cost
WHERE usage_day >= date_sub(current_date(), 30)
    AND usage_day < current_date()
GROUP BY account_name
ORDER BY true_customer_cost DESC;

结果： 获得一个受治理的“真实客户成本”定义、更简单的 MCP 逻辑，以及聊天和仪表板之间一致的输出。

Metric View 度量在大语言模型（LLM）中的呈现方式

ID： true_customer_cost
显示名称： 真实客户成本
注释： 客户支出的真实成本，已计入积分、退款、承诺和折扣，例如 Enterprise Discount Program（EDP）和 Private Pricing Agreements（PPA）。

同义词： 用于 LLM 分析的自定义字段。我们将 Synonyms 用于键值对，以便向前端发送额外元数据。

状态层

在状态层，Databricks Lakebase（无服务器 PostgreSQL）存储持久化产品对象、会话、画布、小组件以及查询/图表规格，因此在聊天中生成的洞察可被提升为持久、可共享的分析工件。

分析工作流

对于长时间运行的分析工作流，我们引入了一条异步执行路径，使用工作流工作器、Amazon DynamoDB 作业跟踪、Amazon SNS 和 Amazon SQS 通知，以及 Amazon API Gateway WebSocket 推送。这样一来，Clara 可以在后台完成重度处理的同时提供响应迅速的用户交互，并实时更新 UI。

结果

这些组件共同构成了一个统一的托管架构，其中：

• Amazon Bedrock AgentCore 负责 Agent 运行时和编排。
• Databricks Lakehouse Metric Views 驱动受治理的分析查询。
• Lakebase 存储持久应用和仪表板状态。
• 异步工作流和 WebSockets 提供可扩展的实时用户体验（UX）。

成果

通过围绕 Amazon Bedrock AgentCore 和 Lakehouse 优先的分析模型重构 Clara，我们为 AI 驱动的 FinOps 工作流建立了更具可扩展性的基础。

开发速度

• 以单一托管服务替代自管 Amazon Elastic Kubernetes Service（Amazon EKS）堆栈后，产品上线时间减少 75%，从 10—12 个月缩短至 4 个月。
• 目前已有 4—6 个可投入生产的 Agent，在共享运行时上提供分析服务。

响应质量

• 正确性评分为 81.7%，较上一周期提高 145%；相比之下，v1 约为 65%。
• 有用性评分为 79.4%，较上一周期提高 138%。
• 采用 Amazon Bedrock AgentCore 和新的工具调用方法后，工具失败率从 7.49% 降至 0.92%。

运营效率

• Customer Success Managers 和 Solutions Architects 的手动分析耗时减少 75%，预计从 2 小时缩短到 30 分钟。
• 通过流式响应和基于推送的工作流完成机制，减少了客户成功、解决方案架构和客户经理团队的日常手动工作量。

基础设施简化

• 完全移除了 LangGraph/LangChain 编排层，改由 AgentCore runtime 和 AgentCore memory 以及内置请求路由和可观测性能力替代。这使工程团队能够专注于产品差异化。

结论

我们将 Clara 从一个分层、以 API 为中心的 AI 助手，转变为统一的、Agent 原生的分析系统。通过将 Amazon Bedrock AgentCore 与 Databricks Lakehouse Metric Views 和 Lakebase 相结合，我们创建了一种可复用模式，用于构建可在大规模场景下保持准确性、且无需沉重运维开销的企业 AI 分析体验。

如需了解有关构建 Agent 原生应用的更多信息，请访问 Amazon Bedrock AgentCore 文档。如需了解我们如何在生产环境中使用这些能力，请访问 nops.io。

---

关于作者

Jo

nOps, an AI-powered cloud optimization solution, recently reimagined its Financial Operations (FinOps) analytics capabilities by transitioning to Amazon Bedrock AgentCore. Amazon Bedrock AgentCore is a service to build, connect, and optimize agents at scale, with any framework or model. The new foundation helps nOps better serve customers managing commitment optimization across Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. Through continual optimization of commitments such as Reserved Instances and AWS Savings Plans, nOps helps teams maximize savings, reduce risk, and automate away the operational burden of manual FinOps. Today, nOps supports customers representing more than USD $4 billion in cloud spend under management.

In this post, we explain how nOps transitioned our analytics and agent experience to accelerate product delivery, improve response quality, and reduce operational complexity using Amazon Bedrock AgentCore, Databricks Lakehouse Metric Views, Databricks Lakebase, Amazon DynamoDB, and Vercel.

Scaling FinOps AI beyond the limits of API-centric infrastructure

As we expanded our product portfolio and customer base, the infrastructure, front-end, and back-end teams needed to support increasingly complex analytics workflows while maintaining high reliability and multi-tenant isolation. Existing infrastructure patterns introduced friction:

• Response latency and inconsistency: Long context messages from API-based data access increased latency and reduced response consistency.
• System complexity: Multiple orchestration and observability layers increased system complexity.
• Innovation drag: Engineering time was increasingly consumed by infrastructure maintenance rather than product innovation.

“We were attempting to build advanced AI capabilities on top of infrastructure that wasn’t designed for analytics-driven agents, which made iteration slow, complex, and prone to inaccuracies.”

— Jordan Stein

Current state

Before transitioning, we introduced Clara, our FinOps AI agent, on top of existing infrastructure components including Kubernetes, Amazon Bedrock model invocation, LangChain/LangGraph orchestration, and tool wrappers around web APIs.

This allowed rapid initial delivery, but it also revealed structural limits:

• Slower time to insight : API-shaped data and large context windows increased turn latency.
• Operational overhead : Multiple non-purpose-built layers made iteration and debugging harder.
• Data path mismatch : Agent answers were tied to API responses instead of a dedicated semantic analytics layer.

To address this, we shifted to a purpose-built architecture centered on Amazon Bedrock AgentCore for runtime/orchestration, Databricks Metric Views for governed analytics semantics, and Databricks Lakebase for durable application state. We chose Bedrock AgentCore for its managed agent runtime, built-in memory, and orchestration, along with the freedom to use any framework or model. With this freedom, we built on Strands and evolved our model choices without switching services, so the team could focus on domain logic rather than infrastructure.

Solution overview

We designed the new architecture to scale with demand, produce accurate answers, and allow developers to ship faster.

The following diagram illustrates the end-to-end architecture of the nOps Clara solution built on Amazon Bedrock AgentCore:

Figure 1: End-to-end architecture of the nOps Clara solution on Amazon Bedrock AgentCore

The solution consists of:

1. Interaction layer: A Vercel-hosted Next.js web application where customers interact with Clara through a conversational interface backed by streaming Server-Sent Events.
2. Agent runtime layer: Amazon Bedrock AgentCore running a single Strands-based agent with direct tool access for canvas operations, query execution, datasource discovery, and workflow orchestration, which alleviates multi-agent routing overhead.
3. Data layer: Databricks Lakehouse Metric Views providing a governed semantic analytics layer, with Databricks Lakebase (serverless PostgreSQL) storing durable application state such as sessions, canvases, and widget specifications.
4. Async workflow layer: An event-driven execution path using Amazon DynamoDB job tracking, Amazon Simple Notification Service (Amazon SNS) and Amazon Simple Queue Service (Amazon SQS) notifications, and Amazon API Gateway WebSocket push for long-running analytics tasks that update the UI in real time.

Web application

At the interaction layer, customers use Clara through a Vercel-hosted web application. Requests flow through a Next.js Backend for Frontend (BFF) that invokes Amazon Bedrock AgentCore. Clara runs as a Strands-based agent runtime that supports streaming responses and tool calling. Users can invoke the same workflows manually that Clara calls through Strands tools. This is an important requirement and building block for Clara because it requires the agent to perform tasks that follow the same procedures as a human would within the product requirements.

Amazon Bedrock AgentCore backend

The runtime is deployed as a Docker container on Amazon Bedrock AgentCore, with the full infrastructure (runtime, memory, guardrails, queues, and worker functions) defined in a single AWS Cloud Development Kit (AWS CDK) stack. Clara uses a single-agent architecture rather than a multi-agent router: one Strands Agent with direct access to the following tools: canvas operations, query execution, datasource discovery, and workflow orchestration. This avoids the latency and error-propagation overhead of agent-to-agent handoffs while keeping tool dispatch deterministic.

Streaming is central to the experience. A custom merge layer sits between the Strands async stream and the Server-Sent Event output, handling three concerns in one pass:

1. Heartbeats keep connections alive during long tool executions.
2. A text buffer with word-boundary-aware flushing coalesces small model deltas into readable chunks to help prevent user interface (UI) flicker.
3. A widget-poll worker interleaves real-time canvas update events into the same stream.

Clara uses AgentCore memory with three strategies (semantic facts, user preferences, and canvas summaries), so it learns how each user engages with their data over time. Preferences inform layout choices, default aggregations, and chart types. Facts capture organizational context such as account structures and cost allocation conventions. Canvas summaries preserve the analytical thread across sessions so users can pick up where they left off without re-explaining context. Sessions are scoped by canvas (not the ephemeral HTTP session), so conversation context persists across browser refreshes and reconnections.

For tenant isolation, Amazon Bedrock Guardrails runs as a standalone pre-check on the raw user prompt before the agent is invoked, enforcing cross-tenant data access policies and prompt-attack detection. A tenant policy layer then sanitizes outbound stream chunks and widget events, redacting internal identifiers before they reach the front end.

Data lakehouse

At the data layer, Clara no longer depends on generic product APIs for analytical context. Instead, it uses curated tools to execute Structured Query Language (SQL) against Databricks SQL Warehouse backed by Databricks Lakehouse Metric Views. This provides a governed semantic layer for measures and dimensions, improving consistency between conversational answers and dashboard outputs.

Example

Metric views compared to raw SQL (True Customer Cost)

User asks: “Show my true AWS Cost for the last 30 days by account.”

Raw SQL Model Context Protocol (MCP) approach: The tool must recalculate business logic every time across various AWS pricing programs and commitment-based discounts, then join and normalize those values before grouping by account.

-- Raw SQL MCP approach
-- User asks: "True Customer Cost for last 30 days by account"
SELECT
    a.account_name,
    SUM(
        -- Base amortized cost
        COALESCE(c.amortized_cost, 0)
        -- Apply EDP discount
        - COALESCE(c.edp_discount_amount, 0)
        -- Apply PPA credits
        - COALESCE(c.ppa_credit_amount, 0)
        -- Add RI effective amortized component
        + COALESCE(c.ri_effective_cost, 0)
        -- Add Savings Plan effective amortized component
        + COALESCE(c.sp_effective_cost, 0)
    ) AS true_customer_cost
FROM raw_cost_and_usage c
JOIN account_dim a
    ON c.account_id = a.account_id
LEFT JOIN pricing_adjustments p
    ON c.account_id = p.account_id
    AND c.usage_day = p.usage_day
WHERE c.usage_day >= date_sub(current_date(), 30)
    AND c.usage_day < current_date()
    AND c.charge_type NOT IN ('Credit', 'Refund')
GROUP BY a.account_name
ORDER BY true_customer_cost DESC;

Metric View MCP approach: The tool queries a predefined measure, utilizing detailed comments and synonyms, (for example, true_customer_cost) with a dimension (account_name) and a time range (last 30 days).

-- Metric View MCP approach
-- Same user ask, but financial logic is pre-modeled in metric view measure
SELECT
    account_name,
    SUM(true_customer_cost) AS true_customer_cost
FROM mv_true_customer_cost
WHERE usage_day >= date_sub(current_date(), 30)
    AND usage_day < current_date()
GROUP BY account_name
ORDER BY true_customer_cost DESC;

Result: One governed definition of True Customer Cost, simpler MCP logic, and consistent outputs across chat and dashboards.

How a Metric View measure appears to a large language model (LLM)

ID: true_customer_cost
Display Name: True Customer Cost
Comment: The true cost of a customer’s spend after taking credits, refunds, commitments, and discounts, such as Enterprise Discount Program (EDP) and Private Pricing Agreements (PPA).

Synonyms: Custom fields to be used for LLM analysis. We have co-opted Synonyms for use with key:value pairs to send additional metadata to the front end.

State layer

At the state layer, Databricks Lakebase (serverless PostgreSQL) stores durable product objects, sessions, canvases, widgets, and query/chart specifications, so insights generated in chat can be promoted into persistent, shareable analytics artifacts.

Analytics workflow

For long-running analytics workflows, we introduced an asynchronous execution path using workflow workers, Amazon DynamoDB job tracking, Amazon SNS and Amazon SQS notifications, and Amazon API Gateway WebSocket push. Clara can then provide responsive user interactions while heavy processing completes in the background and updates the UI in real time.

Result

Together, these components form a single, managed architecture where:

• Amazon Bedrock AgentCore runs agent runtime and orchestration.
• Databricks Lakehouse Metric Views drive governed analytics queries.
• Lakebase stores durable application and dashboard state.
• Async workflows and WebSockets provide scalable real-time user experience (UX).

Outcome

By restructuring Clara around Amazon Bedrock AgentCore and a Lakehouse-first analytics model, we established a more scalable foundation for AI-powered FinOps workflows.

Development velocity

• 75 percent reduction in time-to-production, from 10–12 months to 4 months after replacing a self-managed Amazon Elastic Kubernetes Service (Amazon EKS) stack with a single managed service.
• 4–6 production-ready agents now serving analytics across a shared runtime.

Response quality

• 81.7 percent Correctness score (up 145 percent over the previous period), compared to approximately 65 percent in v1.
• 79.4 percent Helpfulness score (up 138 percent over the previous period).
• Tool failure rate reduced from 7.49 percent to 0.92 percent after adopting Amazon Bedrock AgentCore with a new tool-calling method.

Operational efficiency

• 75 percent time reduction for manual analysis, from an estimated 2 hours to 30 minutes for Customer Success Managers and Solutions Architects.
• Reduced daily manual effort for customer success, solutions architecture, and account executive teams through streaming responses and push-based workflow completion.

Infrastructure simplification

• Removed the LangGraph/LangChain orchestration layer entirely, replaced by AgentCore runtime and AgentCore memory, along with built-in request routing and observability. This freed engineering teams to focus on product differentiation.

Conclusion

We transformed Clara from a layered, API-centric AI assistant into a unified, agent-native analytics system. By combining Amazon Bedrock AgentCore with Databricks Lakehouse Metric Views and Lakebase, we created a repeatable pattern for building enterprise AI analytics experiences that stay accurate at scale without heavy operational overhead.

To learn more about building agent-native applications, visit Amazon Bedrock AgentCore documentation. To see how we use these capabilities in production, visit nops.io.

---

About the authors

Jordan Stein

Jordan is Director of Product and Engineering at nOps, where he leads development of the company’s Platform and AI products. His work focuses on building multi-cloud capabilities that help organizations manage and optimize infrastructure across Amazon Web Services, Microsoft Azure, and Google Cloud Platform.

Benjamin White

Benjamin is a Software Engineer at nOps, where he develops AI-driven features that help customers make sense of their cloud costs. His background spans data workflows, media post-production, and building solutions for complex production environments.

Ren Liu

Ren is an Associate Solutions Architect at AWS in Seattle, specializes in cloud governance and real-time streaming data architecture. He supports independent software vendors (ISVs) in FinOps, cybersecurity, and healthcare to architect secure, scalable solutions powered by generative AI.

Aditi Gupta

Aditi is a Senior GenAI Specialist Solutions Architect at Amazon Web Services. She has 18+ experience in designing and developing highly scalable and reliable systems for many government agencies and large-scale enterprises. Her interests include Big Data, Artificial Intelligence and Machine Learning.