Data Today: FinOps

Snowflake FinOps: credits, warehouses and the cost controls that work

2026-08-11T00:00:00Z

Snowflake's pricing model is simple on the surface (pay for compute credits, storage and serverless features) and surprisingly easy to get wrong in practice. A warehouse left running at 4XL over a weekend, a poorly partitioned table that forces full scans, or a serverless feature that bills per token can each add thousands of dollars to a monthly bill before anyone notices. The good news is that Snowflake gives you the controls to catch all three. The better news is that AI agents are starting to tune warehouses automatically.

The four controls that keep a Snowflake bill predictable are warehouse right-sizing, resource monitors, auto-suspend and budget alerts. If you configure these four correctly, you eliminate roughly 80 percent of the cost surprises that Snowflake teams report. The remaining 20 percent comes from storage optimization, data transfer governance and serverless feature cost monitoring, which require more ongoing attention.

Where does Snowflake spend actually go?

Snowflake bills in credits. One credit buys one hour of a single-node virtual warehouse, and larger warehouses consume credits at a multiplier: an X-Small warehouse burns 1 credit per hour, a Medium burns 4, an XL burns 16, and a 4XL burns 128. A 4XL warehouse left running for a full month costs 92,160 credits. At Snowflake's standard $3 per credit, that is $276,480. For one warehouse. For one month.

Snowflake credits per hour double with every warehouse size, from 1 at XS to 128 at 4XL. Source: Snowflake documentation. Data Today benchmark.

In a typical organization, virtual warehouse compute accounts for 50 to 60 percent of the total Snowflake bill. Serverless compute (Snowpipe, automatic clustering, materialized views maintenance, search optimization, and Cortex AI functions) accounts for another 15 to 25 percent. Storage (both active and Time Travel/Fail-safe) accounts for 10 to 20 percent. Data transfer, primarily egress to other clouds or regions, accounts for the remaining 5 to 15 percent.

The split matters because each category has different optimization levers. Warehouse compute is the easiest to control and the highest-ROI place to start. Serverless compute is the hardest to control because you do not directly manage the resources. Storage is cheap per terabyte but accumulates silently. Data transfer is expensive per gigabyte and architectural: once your data flows cross-region, the cost is baked into the design.

What are the four controls that actually work?

Warehouse right-sizing is the single most impactful FinOps action on Snowflake. The pattern is simple: start with an X-Small warehouse, run your workload, check the query profile for spillage to local or remote disk, and increase the warehouse size only if queries are spilling. Most teams run warehouses that are one or two sizes larger than they need because they sized for peak concurrency rather than average load. Snowflake's QUERY_HISTORY view in ACCOUNT_USAGE tells you exactly how much of each warehouse's capacity is being used. A warehouse with average queued load below 0.1 and no spillage is correctly sized.

Multi-cluster warehouses add a second dimension: minimum and maximum cluster count. Set the minimum to 1 and the maximum to whatever your concurrency needs require. Snowflake auto-scales clusters within those bounds. The mistake teams make is setting the minimum to 2 or 3 "just in case," which doubles or triples the baseline cost.

Resource monitors are Snowflake's built-in cost guardrails for virtual warehouses. You set a credit quota (monthly, weekly, or custom interval), define up to five threshold percentages, and choose an action at each threshold: notify, notify and suspend, or notify and suspend immediately. A typical setup is: notify at 80 percent, notify and suspend at 100 percent. Resource monitors only apply to user-managed virtual warehouses, not to serverless features. For serverless, you use budgets.

Auto-suspend is the simplest control and the one most frequently misconfigured. Snowflake's default auto-suspend is 10 minutes. Setting it to 1 or 2 minutes for non-production warehouses and 5 minutes for production warehouses saves 15 to 30 percent on warehouse compute with no impact on user experience. A warehouse that sits idle for 9 minutes between queries burns credits for 9 minutes. Over a month, those 9-minute gaps add up.

Budgets are the serverless counterpart to resource monitors. A budget sets a monthly spending limit on a group of resources (specific warehouses, serverless features, or the entire account) and sends a notification when spend is forecasted to exceed the limit. Budgets can notify via email, Slack webhook, Microsoft Teams webhook, Amazon SNS, Azure Event Grid, or Google Cloud Pub/Sub. They do not suspend resources automatically, which is a deliberate design choice: serverless features often serve critical pipelines, and an automatic suspension could break a production data load.

How do you monitor storage costs?

Snowflake storage costs $23 per terabyte per month for compressed storage in most regions. That is cheap enough that storage is rarely the largest line item, but it accumulates in three ways that teams miss.

First, Time Travel retains data for a configurable number of days (default 1, maximum 90). Every day of Time Travel adds storage cost. For tables that are rebuilt daily by a pipeline, set Time Travel to 0 or 1 day. For production tables that need point-in-time recovery, keep it at 7 to 14 days.

Second, Fail-safe retains data for 7 days beyond Time Travel and is not configurable. It is free in the sense that you cannot turn it off, but it adds 7 days of storage cost to every table. The only way to reduce Fail-safe cost is to drop tables you no longer need.

Third, cloned databases and tables share storage with their source until either is modified, at which point they accrue their own storage cost. A team that clones a production database for testing and then runs a transformation on it has just doubled the storage cost of every modified table. The TABLE_STORAGE_METRICS view in ACCOUNT_USAGE shows exactly which tables are consuming storage and how much is active versus Time Travel versus Fail-safe.

Where do AI agents fit into Snowflake FinOps?

Snowflake has not released a dedicated FinOps agent comparable to the AWS FinOps Agent, but the building blocks are in place. The ACCOUNT_USAGE and ORGANIZATION_USAGE schemas expose every cost-relevant metric through standard SQL views. An LLM agent that can query those views, interpret the results, and generate recommendations is a straightforward integration.

The highest-ROI agent use cases for Snowflake FinOps are warehouse right-sizing recommendations, unused table detection, and cost anomaly investigation. An agent can query QUERY_HISTORY for spillage and queue patterns, compare them against the current warehouse size, and recommend a smaller size with an estimated monthly savings. It can query TABLE_STORAGE_METRICS for tables that have not been queried in 90 days and flag them for archival or deletion. And it can monitor the WAREHOUSE_METERING_HISTORY view for cost spikes, correlate them with QUERY_HISTORY to identify the responsible user and query, and post a summary to Slack.

The FinOps Foundation's Snowflake coverage maps the standard FinOps capabilities onto data platforms specifically, and the pattern is the same as AWS: agents start with anomaly detection and reporting, then move into optimization recommendations, and eventually into automated execution within policy guardrails.

What is the one thing to do today?

If you do nothing else, query the WAREHOUSE_METERING_HISTORY view for the last 30 days, group by warehouse name, and sort by credits consumed descending. Look at the top three warehouses. For each one, check the auto-suspend setting (SHOW WAREHOUSES), the size, and whether it is multi-cluster. Reduce the auto-suspend to 60 seconds for non-production warehouses. Reduce the size by one tier and monitor query performance for a week. Set a resource monitor with a monthly quota at 90 percent of last month's consumption.

Those three actions (auto-suspend, right-size, resource monitor) take 30 minutes and typically save 20 to 30 percent on warehouse compute. Everything else (storage lifecycle policies, serverless budget alerts, data transfer governance) builds on that foundation.

For the deeper warehouse sizing methodology, the Snowflake warehouse sizing guide walks through the query-profile approach to picking the right size. For the broader FinOps lifecycle, the overview covers where agents fit across all platforms.

Sources

Power BI FinOps: Pro licenses, Premium capacity and the Fabric cost model explained

2026-08-11T00:00:00Z

Power BI pricing looks simple until you add up the real numbers. A Pro license costs $10 per user per month. For a 200-person organization, that is $2,000 per month, or $24,000 per year. But Pro licenses only cover report authoring and consumption within shared capacity. As soon as you need paginated reports, AI features, deployment pipelines or more than 1 GB of semantic model size, you need Premium capacity. And since Microsoft Fabric launched in 2023, the licensing model has merged Power BI Premium with the broader Fabric platform, turning what used to be a BI cost into a data platform cost.

The three FinOps levers for Power BI are license tier auditing, capacity right-sizing and report lifecycle management. Get these right and your Power BI bill reflects what your organization actually uses. Get them wrong and you are buying Premium capacity for users who only consume reports, or paying for Fabric capacity that sits idle because the data engineering team has not adopted it yet.

What are the licensing tiers, and what do they actually cost?

Power BI Pro at $10 per user per month is the entry point. Every user who creates, publishes or shares reports needs a Pro license. Every user who consumes reports published to shared capacity also needs a Pro license unless the organization has Premium capacity (which includes a limited free consumption tier). The most common FinOps mistake on Power BI is overbuying Pro licenses: a user who only views one dashboard per quarter does not need a $120 per year license.

Power BI Premium Per User (PPU) at $20 per user per month adds AI features (AutoML, cognitive services integration), larger semantic models (up to 100 GB), and higher refresh rates (up to 48 times per day). PPU makes sense for power users who author complex reports and data analysts who build semantic models. It is waste for report consumers.

Power BI Premium capacity is the organization-wide license that replaces per-user licensing for report consumers. Premium P1 costs $4,995 per month and includes 8 v-cores of dedicated capacity, unlimited report consumption for users without Pro licenses, and advanced features like paginated reports, deployment pipelines and XMLA endpoints. Premium P2 ($9,995 per month) doubles the capacity. Premium P3 ($19,995 per month) quadruples it.

Microsoft Fabric SKUs have largely replaced the standalone Premium SKUs for new customers. Fabric F2 through F2048 are capacity-based licenses that include Power BI, Data Factory, Synapse, and all other Fabric workloads. An F64 SKU (the smallest that includes full Power BI Premium features) costs roughly $8,500 per month at list price with no commitment discount. An F128 costs $17,000 per month. Fabric SKUs are priced per capacity unit (CU), where 1 CU is roughly $0.18 per hour at list price.

Monthly Power BI licensing cost comparison for a 200-user organization across three paths. Source: Microsoft pricing. Data Today benchmark.

The Fabric pricing model means that Power BI cost is no longer a standalone number. Your Fabric capacity serves Power BI workloads alongside data engineering, data science and data warehouse workloads. A Power BI report that refreshes every 15 minutes consumes CUs that could otherwise be used for a Spark job. The FinOps challenge is no longer just "how much does Power BI cost?" but "how much of the Fabric capacity is Power BI consuming, and is that the right split?"

What are the three levers that pull hardest?

License tier auditing is the fastest win. Export your user list from the Microsoft 365 admin center or the Power BI admin portal. For each user, map their license tier (Free, Pro, PPU) against their actual activity: report views, report publishes, dataset refreshes, and last sign-in date. The Power BI activity log provides this data through the Microsoft 365 unified audit log or the Power BI REST API.

The typical audit finds 15 to 25 percent of Pro licenses are underused or unused. A user who last signed in 90 days ago and has zero report views in that period is paying $30 for nothing. A user who only views reports and never creates them is a candidate for free consumption tier if the organization has or upgrades to Premium capacity. A user on a PPU license who never uses AI features or builds models larger than 1 GB is a candidate for a standard Pro license.

Capacity right-sizing is the second lever. Power BI Premium and Fabric capacities are measured in capacity units (CUs), and overloading a capacity causes throttling: report loads slow down, refreshes queue up, and interactive operations time out. The capacity metrics app (available in the Power BI admin portal) shows CU utilization over time, broken down by workload (interactive operations, scheduled refreshes, background operations, AI operations).

The right-sizing playbook: monitor CU utilization at 15-minute granularity for two weeks. If maximum utilization stays below 60 percent, you have headroom for growth or a smaller SKU. If utilization regularly spikes above 80 percent, you need a larger SKU or workload optimization. The Fabric capacity metrics app (newer than the Power BI-specific one) provides per-workload breakdowns so you can see whether Power BI or Data Factory is the capacity hog.

The third lever is report lifecycle management. Power BI reports, like code, have a lifecycle. A report built for a one-off analysis that lives on for three years consumes development time, storage, refresh cycles and capacity with no business value. The FinOps practice for Power BI includes a regular report audit: who owns this report, when was it last viewed, and does the business still need it?

The Power BI REST API provides report usage metrics: view count, unique viewers, last view date. Reports with zero views in 90 days are candidates for archival or deletion. Reports with zero views in 30 days and an owner who has left the organization are candidates for immediate action. The audit is manual today, but an AI agent can query the Power BI API, generate the list of unused reports, and post it to the workspace owners for review.

What changes with Microsoft Fabric?

Fabric turns Power BI from a standalone BI tool into one workload among many on a shared capacity. This has two FinOps implications.

First, Fabric costs are shared across teams that used to have separate budgets. The data engineering team's Spark jobs and the BI team's report refreshes compete for the same CUs. Without workload-level chargeback, each team sees the other team's consumption as "free" and overconsumes, a classic tragedy of the commons. Fabric's capacity metrics app provides per-workload breakdowns, but chargeback requires manual reporting today.

Second, Fabric enables AI features (Copilot for Power BI, Copilot for Data Factory) that consume CUs at a higher rate than standard operations. A Copilot-generated DAX query consumes more CUs than a human-written query. The FinOps question is not "should we use Copilot?" but "how many CUs is Copilot consuming, and is the productivity gain worth the capacity cost?" Fabric's Copilot usage is metered and reported, but the data is new and most organizations have not built reporting around it yet.

How do AI agents fit into Power BI FinOps?

Microsoft has not released a dedicated Power BI or Fabric FinOps agent, but the pattern from AWS applies. The Power BI REST API exposes usage data for reports, datasets, dashboards and users. The Microsoft 365 admin center API exposes license assignments. The Fabric capacity metrics API exposes CU consumption by workload. An LLM agent with access to all three can generate a comprehensive FinOps report.

The highest-ROI agent use cases for Power BI are unused report detection, license audit automation and capacity utilization reporting. An agent that runs weekly, queries the Power BI activity log for reports with zero views in the last 30 days, cross-references against the report owner (who may have left), and posts a cleanup list to the BI team's Teams channel would save hours of manual audit work. An agent that monitors CU utilization and alerts when the maximum utilization exceeds 80 percent for more than 15 minutes would catch capacity issues before users complain about slow reports.

The most advanced use case is workload-aware capacity planning. An agent that models the CU consumption of each Fabric workload (Power BI, Data Factory, Synapse, Data Science) and projects capacity needs based on growth trends would help organizations right-size their Fabric commitment before renewal. This is a modeling task that humans can do in Excel but rarely update, and an agent can do weekly with live data.

Where do you start?

Start with a license audit. Export your assigned licenses from the Microsoft 365 admin center. Cross-reference against user sign-in activity in Azure AD. For every user who has not signed in to Power BI in 90 days, flag the license for removal. For every user on PPU who has zero AI feature usage and zero models over 1 GB, downgrade to Pro. The audit takes an afternoon and typically saves 10 to 15 percent on license costs.

Then look at your capacity utilization. If you are on Premium or Fabric, install the capacity metrics app and review the last 30 days of utilization. If average utilization is below 40 percent, you can likely step down one SKU size at renewal. If maximum utilization regularly hits 100 percent, invest in report optimization (reduce refresh frequency, use incremental refresh, optimize DAX queries) before buying more capacity.

Finally, set up a quarterly report lifecycle audit. Use the Power BI REST API to identify reports with zero views in 90 days. Archive them. The storage savings are small. The capacity savings (from eliminating unnecessary refreshes) and the organizational savings (from reducing the surface area that the BI team supports) are significant.

For the broader FinOps lifecycle and where agents fit across platforms, see the overview. The AWS guide covers the AWS FinOps Agent pattern that applies to Power BI, and the Snowflake guide covers the equivalent for data warehouse credits.

Sources

Postgres FinOps: from self-managed to serverless, what hosting actually costs

2026-08-11T00:00:00Z

Postgres is free software. Running Postgres is not. The cost of hosting a production Postgres database varies by a factor of 5 to 10 depending on how you run it, where you run it, and whether you pay someone else to manage it or manage it yourself. And with the rise of serverless Postgres (AWS Aurora Serverless v2, Neon, Supabase, Google Cloud SQL), the cost model is shifting from pay-per-instance to pay-per-query, which changes the FinOps equation fundamentally.

The three FinOps levers for Postgres are instance right-sizing, storage tiering and connection pooling. Get these three right and your database cost stays predictable regardless of hosting model. Get them wrong and you will pay for instance capacity you never use, storage that never gets cleaned up, and connections that force you to a larger instance than your actual query load requires.

What are the hosting models, and what do they actually cost?

Self-managed Postgres on EC2 or Kubernetes gives you full control at the cost of full operational responsibility. A 2-vCPU, 8 GB RAM instance (r6g.large, Graviton) costs roughly $85 per month on-demand. But that is just the instance. Production Postgres needs at least two instances (primary and replica) plus EBS storage (gp3, $0.08 per GB-month), backups (snapshots to S3), and a human who knows how to run pg_dump, configure WAL archiving, and recover from a crash. The fully loaded cost, including 20 percent of a database engineer's time, is typically $1,500 to $3,000 per month for a small to mid-size production deployment.

Managed Postgres on RDS eliminates the operational overhead at a 30 to 50 percent premium over the raw instance cost. An db.r6g.large instance (2 vCPU, 16 GB RAM) with Multi-AZ deployment costs roughly $210 per month for the compute plus $0.16 per GB-month for SSD storage. RDS handles backups, patching, failover and point-in-time recovery automatically. For most teams, the premium is worth it: the engineering time saved by not managing Postgres directly exceeds the RDS markup by a wide margin.

Aurora Serverless v2 is AWS's serverless Postgres-compatible offering. You pay in ACU-hours (Aurora Capacity Units), where 1 ACU is roughly equivalent to 2 GB of memory and corresponding CPU. The minimum is 0.5 ACU ($0.06 per ACU-hour, or roughly $22 per month). The maximum is whatever you set. The cost model is fundamentally different from RDS: you pay for actual database activity rather than provisioned capacity. For workloads with variable traffic (bursty web apps, batch processing that runs once a day), Aurora Serverless v2 can be 40 to 60 percent cheaper than a provisioned RDS instance sized for peak load. For workloads with steady, predictable traffic, RDS with Reserved Instances is usually cheaper.

Neon and Supabase are cloud-native serverless Postgres offerings that separate compute from storage. Neon charges per compute hour (starting at $0.024 per compute hour for a 0.25 vCPU, 1 GB RAM compute) plus storage at $0.0004 per GB-hour. Supabase charges per project (starting at $25 per month for the Pro tier with 8 GB of storage and 50 GB of transfer) plus usage-based fees for additional compute and storage. Both offer a generous free tier that covers small projects and development databases.

Monthly Postgres cost comparison across hosting models for a mid-size workload. Illustrative. Data Today benchmark.

What are the three levers that pull hardest?

Instance right-sizing is the same pattern as EC2: size for average load, not peak load. The most common Postgres FinOps mistake is running a db.r6g.xlarge (4 vCPU, 32 GB RAM) when a db.r6g.large (2 vCPU, 16 GB RAM) would handle the workload with room to spare. The key metrics to check are CPU utilization (below 60 percent average is comfortable), freeable memory (above 20 percent of total is comfortable), and read/write IOPS (below 80 percent of the volume's provisioned IOPS is comfortable). RDS Performance Insights surfaces all three in a single dashboard.

The counterintuitive part is that a larger instance is not always faster for Postgres. Postgres can only use one CPU core per query. If your workload is dominated by many small queries, more cores help (parallel execution across queries). If your workload is dominated by a few large queries, more memory for cache helps more than more CPU cores. Rightsizing for Postgres means understanding your query patterns, not just your aggregate utilization metrics.

Storage tiering for Postgres is about more than the $0.08 per GB-month base rate. RDS storage has three dimensions: allocated storage (what you pay for, whether you use it or not), actual data size, and snapshot storage. The gap between allocated and actual is waste: if you allocated 500 GB but only use 120 GB, you are paying for 380 GB of empty space every month. RDS auto-scaling (enabled by default) grows storage when free space drops below a threshold, but it never shrinks it back.

The storage optimization playbook: set a maximum storage limit to prevent runaway auto-scaling, monitor actual versus allocated storage monthly, and for Aurora, enable backtrack (point-in-time rollback) only for the retention period you actually need. Backtrack keeps log records that consume storage. A 72-hour backtrack window on a high-write database can add 10 to 20 percent to your storage cost.

Connection pooling is the least obvious lever. Postgres creates a new process for every database connection, and each process consumes memory (typically 5 to 10 MB). A thousand idle connections consume 5 to 10 GB of memory that could be used for query cache. If your application opens a connection per request and you handle 500 concurrent requests, you need either a connection pooler (PgBouncer, RDS Proxy) or a much larger instance.

RDS Proxy ($0.015 per vCPU-hour) is a managed connection pooler that sits between your application and your database. It multiplexes thousands of application connections onto a smaller number of database connections, reducing memory pressure and allowing a smaller instance size. The proxy typically pays for itself by allowing a one-tier-smaller RDS instance. An application that otherwise needs a db.r6g.xlarge (4 vCPU, 32 GB RAM) to handle connection load might run comfortably on a db.r6g.large (2 vCPU, 16 GB RAM) with the proxy, saving roughly $105 per month.

What changes when you move to serverless?

Serverless Postgres changes the cost model from pay-per-instance to pay-per-query. This is good for variable workloads and potentially dangerous for steady workloads where you forget to set a maximum capacity limit.

With RDS, you know exactly what your database will cost each month: the instance price plus the storage price. With Aurora Serverless v2, your cost depends on how many queries you run and how much CPU they consume. A sudden spike in traffic (a product launch, a marketing campaign, a DDoS attack) increases your database bill in real time. Setting a maximum ACU limit is the equivalent of a budget alert on Snowflake: it caps your cost but may throttle performance during a spike.

The serverless model also changes the optimization strategy. On RDS, you optimize by picking the right instance size and committing to a Reserved Instance. On Aurora Serverless, you optimize by reducing query load: better indexes, more aggressive caching, query rewriting, and connection pooling. The database bill becomes a direct reflection of application efficiency, which is both empowering and exposing.

How do AI agents fit into Postgres FinOps?

AWS has not released a Postgres-specific FinOps agent, but the general AWS FinOps Agent can query RDS and Aurora metrics through CloudWatch and Cost Explorer. The highest-ROI agent use cases for Postgres are rightsizing recommendations, unused instance detection (RDS instances or Aurora clusters with zero connections for 14 days), and index recommendation generation.

An agent that can query pg_stat_statements (or RDS Performance Insights) and identify the top 10 slowest queries, their execution count, and their average latency can generate a prioritized list of indexing and query optimization tasks. This is not strictly a FinOps task, but it has a direct cost impact: faster queries need less instance capacity, and less capacity costs less money.

The emerging pattern is an agent that combines cost data (from Cost Explorer) with performance data (from RDS Performance Insights and pg_stat_statements) to answer the question "how much would we save if we optimized these three queries?" An engineer can make the case for spending a day on query optimization by showing the dollar impact. The agent does the math.

Where do you start?

Start with a cost and performance audit of your three most expensive Postgres instances. For each one, check CPU utilization, memory utilization, storage allocated versus used, and connection count. If CPU is below 40 percent, test a one-tier-smaller instance in a staging environment. If storage allocated is more than 2x storage used, file a support ticket with AWS to shrink it (RDS does not support shrinking through the console). If connection count is above 200 and you are not using a connection pooler, evaluate RDS Proxy or PgBouncer.

Then look at your backup retention. RDS automated backups are retained for a configurable number of days (default 7, maximum 35). Every day of retention costs storage. If you also take manual snapshots, check whether any snapshots are older than your retention policy and delete them. Snapshots are incremental in Aurora but full in RDS, so a 500 GB manual RDS snapshot costs the full 500 GB of storage for as long as it exists.

For the broader FinOps lifecycle and where agents fit across platforms, see the overview. The AWS guide covers the AWS FinOps Agent that can query RDS and Aurora metrics, and the Snowflake guide covers the equivalent for data warehouse credits.

Sources

FinOps explained: every stage, every action, and where AI agents fit

2026-08-11T00:00:00Z

The average organization now runs workloads across three public clouds, two SaaS data platforms, and a growing fleet of AI services whose bills arrive before anyone has figured out who owns them. FinOps is the discipline that turns that chaos into a repeatable operating model. It is a cultural practice: engineering, finance and business teams collaborating continuously to make sure every dollar of technology spend buys something the business actually needs.

FinOps runs on a three-phase lifecycle (Inform, Optimize, Operate) that loops continuously. The FinOps Foundation, which maintains the open-source framework that most practitioners follow, organizes the work into six domains and 22 capabilities. Each capability is a specific, named activity that someone in the organization owns. And in 2026, AI agents are starting to automate the most repetitive parts of nearly half of them.

What are the three FinOps phases, and what happens in each?

The lifecycle is not a one-time project. It is a continuous loop that every team runs every month, and the three phases build on each other.

Inform is the visibility phase. Before you can optimize anything, you need to know what you are spending and why. This phase covers data ingestion (pulling billing data from AWS, Azure, GCP, Snowflake, Databricks and every other provider into a single queryable repository), allocation (assigning every dollar to a team, product or cost center using tags, labels and account hierarchies), reporting and analytics (making that data readable for engineers and finance alike), and anomaly management (detecting cost spikes before they become budget surprises). If your team cannot answer "what did we spend last month and who spent it" in under five minutes, you are still in the Inform phase.

Optimize is where the savings live. Once you can see the spend, you reduce it. This phase covers usage optimization (rightsizing overprovisioned resources, deleting idle ones, scheduling non-production environments to shut down overnight), rate optimization (committing to reserved instances, savings plans, or enterprise agreements in exchange for lower unit prices), architecting and workload placement (choosing the right service and region for each workload from the start), licensing and SaaS optimization (eliminating unused seats and renegotiating contracts), and sustainability (reducing carbon footprint as a side effect of reducing waste). The FinOps Foundation reports that organizations in the Optimize phase typically save 20 to 30 percent of their cloud bill within the first year.

Operate is the governance phase that stops the waste from coming back. It covers the capabilities that manage the FinOps practice itself: FinOps practice operations (running the monthly cadence, the steering committee, the showback reports), governance and policy (setting and enforcing budget guardrails, tagging policies, and approval workflows), intersecting disciplines (coordinating with IT asset management, IT financial management, and security teams), invoicing and chargeback (making sure the finance team can reconcile cloud invoices and charge costs back to the right business units), FinOps education and enablement (training engineers to read a cost report and make cost-aware architecture decisions), and FinOps assessment (measuring how mature the practice is and where to invest next).

The fourth piece, sitting alongside the three phases, is Quantify Business Value. This domain covers planning and estimating (what will a new workload cost before you build it?), forecasting (where is spend heading based on historical patterns and planned growth?), budgeting (setting limits and alerting when they are crossed), KPIs and benchmarking (how does your unit cost compare to peers?), and unit economics (what does it cost to serve one customer, process one transaction, or train one model?). Without this domain, FinOps is just cost-cutting. With it, FinOps becomes a business strategy function.

Which capabilities are AI agents already automating?

The FinOps Foundation published its first agentic AI use-case map in April 2026, and the pattern is clear: agents are starting with the high-volume, rules-based capabilities and moving toward the judgment-heavy ones.

Anomaly management is the most mature use case. AWS Cost Anomaly Detection already uses machine learning to flag spend spikes, and the AWS FinOps Agent (launched in preview in late 2025) takes it further: it runs on a schedule or on anomaly triggers, investigates the root cause by querying Cost Explorer and CloudTrail, drafts a summary in natural language, and posts it to Slack or creates a Jira ticket. The central FinOps team reviews the agent's output rather than doing the detective work themselves.

Reporting and analytics is the second frontier. Instead of building yet another QuickSight or Looker dashboard, teams are asking an agent "show me the top five cost drivers by service this week, compared to last week, broken down by team." The agent queries the cost data warehouse, generates the chart, and writes the commentary. AWS's agent does this. So do a growing number of third-party tools built on top of the FOCUS 1.0 billing data standard, which normalizes cost data across AWS, Azure, GCP and SaaS providers into a single schema.

Usage optimization is where agents start making actual changes. An agent can detect an idle EC2 instance or an overprovisioned RDS database, check whether it is tagged as production or sandbox, and either stop it automatically (if sandbox) or file a rightsizing recommendation for the owning team (if production). The agent does not need to understand the workload. It needs to understand the policy.

Rate optimization is the hardest capability to automate because it involves financial commitments. But agents are starting to model Savings Plan and Reserved Instance purchase scenarios: "if we commit to $50,000 per month of compute savings plans, our effective discount goes from 22 percent to 34 percent, and the break-even utilization is 62 percent." The agent runs the numbers. A human makes the commitment.

Tagging and allocation is a surprising bright spot. Agents are good at scanning untagged resources, inferring ownership from related resources that are tagged, and proposing tag backfill. They are also good at enforcing tagging policies at deployment time by integrating with CI/CD pipelines and Infrastructure as Code.

The capabilities that remain firmly human in 2026 are executive strategy alignment, intersecting disciplines, and FinOps education. Agents cannot negotiate with a VP or teach an engineer to care about cost. But they can prepare the data that makes those conversations shorter and more productive.

AI agent automation coverage across FinOps capabilities in 2026, from anomaly management at 72 percent down to executive strategy at 12 percent. Illustrative. Data Today benchmark.

The spread is wide on purpose. Anomaly management is rules-heavy and data-rich, so agents handle most of it. Strategy is relationship-heavy and context-poor, so humans keep it. The middle band, from usage optimization through forecasting, is where the next two years of agent investment will land.

What does a FinOps team actually look like?

The FinOps Foundation defines six core personas. The FinOps practitioner is the person who runs the practice: they own the monthly cadence, the tooling, the reporting, and the cross-functional coordination. Engineering owns the actual resource usage and the optimization actions. Finance owns budgeting, forecasting, invoicing and chargeback. Leadership sets the strategy and the cost targets. Procurement negotiates enterprise agreements and commitment discounts. Product owns the unit economics: what does it cost to deliver the product, and is that number trending in the right direction?

In a 50-person engineering organization, you might have one dedicated FinOps practitioner. In a 500-person organization, you might have a team of three to five. In a 5,000-person organization, you likely have a FinOps center of excellence with practitioners embedded in each major business unit. The key principle is that FinOps is a central enablement function, not a central command-and-control function. The central team builds the tooling, sets the policies, and trains the engineers. The engineers make the day-to-day cost decisions.

What changes when you add AI agents to the mix?

The most important shift is that cost expertise stops being bottlenecked on the FinOps practitioner. When every engineer can ask an agent "why did my team's AWS bill go up 18 percent this week?" and get a useful answer in Slack, the FinOps practitioner stops being a help desk and starts being a strategist.

The agent becomes the first responder. It triages anomalies, answers routine cost questions, and generates the weekly showback reports. The human practitioner reviews, approves, and escalates. This is the same pattern that platform engineering teams already use for infrastructure provisioning: the developer asks for a database, the platform provisions it within policy guardrails, and the human only gets involved when something falls outside the guardrails.

The risk is that agents optimize for the metric they can see. An agent that only looks at cost will recommend shutting down the staging environment that the QA team needs for a release next week. An agent that only looks at utilization will recommend buying a three-year Reserved Instance for a workload that is being migrated to a different architecture in six months. The human in the loop is not a temporary crutch. It is the architecture of the system.

Where do you start?

The FinOps Foundation recommends a crawl-walk-run maturity model. Crawl means you can see your spend and allocate at least 50 percent of it to a team or cost center. Walk means you have anomaly detection, budget alerts, and a monthly showback cadence, and you are actively rightsizing and buying commitment discounts. Run means unit economics drive architecture decisions, policies are automated, and the FinOps practice continuously measures and improves itself.

If you are at zero today, start with allocation. Pick one cloud provider. Turn on cost allocation tags. Build one dashboard that shows spend by team. Send it to the engineering managers every Monday. That single action moves you from invisible spend to visible spend, and visible spend is the foundation everything else sits on.

Once you can see the spend, the platform-specific guides go deep on the levers that matter: AWS for EC2 rightsizing and commitment discounts, Snowflake for warehouse tuning and resource monitors, Matillion for pipeline credits and runner economics, GitHub for Actions minutes and agent cost attribution, Postgres for instance sizing and connection pooling, and Power BI for license auditing and Fabric capacity. Each one covers what to measure, what to optimize, and where AI agents fit.

Sources

Matillion FinOps: pipeline credits, runner economics and what Maia AI changes

2026-08-11T00:00:00Z

Matillion's Data Productivity Cloud (DPC) runs on a credit-based pricing model that is conceptually similar to Snowflake's but with its own cost drivers. Every pipeline execution consumes credits. Every runner that executes those pipelines consumes credits (if hosted) or cloud infrastructure cost (if self-hosted). And every Maia AI agent interaction, from pipeline generation to root cause analysis, adds a new line to the bill that did not exist a year ago.

The three FinOps levers that matter most on Matillion are pipeline efficiency, runner right-sizing, and scheduling discipline. Get these three right and your Matillion bill stays predictable. Ignore them and you will find yourself paying for pipelines that run more often than they need to, on runners that are larger than they need to be, with AI features whose cost you never measured.

Where does Matillion spend actually go?

Matillion sells credits in bundles, and different operations consume credits at different rates. A transformation pipeline that runs for 10 minutes on a standard runner might consume 2 credits. An orchestration pipeline that iterates over 50 tables and calls a transformation pipeline for each one might consume 100 credits. A Maia AI agent that generates a pipeline from a natural language description might consume 5 to 20 credits depending on complexity.

In a typical mid-size organization running Matillion as their primary ETL layer, the cost breakdown looks roughly like this: pipeline execution credits at 40 to 50 percent, hosted runner costs at 25 to 35 percent, self-hosted runner infrastructure (EC2 instances or Kubernetes nodes) at 10 to 20 percent, and Maia AI agent credits at 5 to 15 percent. The Maia share is growing as teams adopt AI-powered pipeline generation, root cause analysis and the Maia API endpoints.

Typical Matillion DPC monthly cost breakdown by component. Illustrative. Data Today benchmark.

The key difference from Snowflake is that Matillion credits are consumed by the act of running pipelines, not by the act of querying data. A Snowflake warehouse burns credits for every second it is running. A Matillion pipeline burns credits once per execution, and the credit cost is determined by the pipeline's complexity and runtime. This means the optimization strategy is different: on Snowflake you optimize for warehouse idle time. On Matillion you optimize for pipeline frequency and runner efficiency.

What are the three levers that pull hardest?

Pipeline efficiency is about making each pipeline execution do more work per credit. The most common inefficiency is a pipeline that reloads an entire table when only the last day of data has changed. Matillion supports incremental loading through its CDC (change data capture) components and through custom SQL with date-window filters. Switching a full-load pipeline to incremental loading typically reduces credit consumption by 70 to 90 percent for that pipeline.

The second inefficiency is redundant transformation steps. A pipeline that extracts data, writes it to a staging table, reads it back, transforms it, writes it to another staging table, reads it again, and finally loads it to the target is doing three times the I/O it needs to. Matillion's pushdown SQL architecture is designed to avoid this: when you configure a transformation to run as pushdown, Matillion sends a single SQL statement to the target warehouse and lets the warehouse execute it. The pipeline consumes fewer credits and runs faster. The tradeoff is that pushdown SQL is harder to debug when something goes wrong, which is why many teams default to non-pushdown mode and pay the credit premium.

Runner right-sizing is the Matillion equivalent of Snowflake warehouse right-sizing. Matillion offers hosted runners in multiple sizes (standard, large, extra-large) and also supports self-hosted runners that run on your own infrastructure. Hosted runners are convenient but expensive at scale. Self-hosted runners are cheaper per pipeline execution but require you to manage the infrastructure.

The economics shift at around 50 pipeline runs per day. Below that threshold, hosted runners are usually cheaper than the engineering time required to manage self-hosted infrastructure. Above that threshold, self-hosted runners on spot EC2 instances or a Kubernetes cluster typically save 40 to 60 percent on runner costs. The break-even point depends on your team's DevOps maturity and your cloud provider's instance pricing.

Scheduling discipline is the simplest lever and the most frequently overlooked. A pipeline that runs every 15 minutes but only needs to run every hour is consuming 4 times the credits it should. A pipeline that runs on weekends when the source system does not update on weekends is consuming 28 percent more credits than it should (2 days out of 7). Matillion's scheduler supports cron expressions and event-based triggers. Use event-based triggers (a file landing in S3, a webhook from the source system) instead of fixed schedules wherever possible. For fixed schedules, audit your pipeline frequencies quarterly and ask: does this pipeline really need to run this often?

How does Maia AI change the FinOps equation?

Maia is Matillion's AI layer, and it introduces a new cost dimension that did not exist in traditional ETL. Maia has three main capabilities that consume credits: pipeline generation (describing a pipeline in natural language and having Maia build it), root cause analysis (asking Maia why a pipeline failed and getting a diagnosis), and the Maia API endpoints (calling Maia programmatically from other systems).

Pipeline generation is the highest-value and highest-cost Maia feature. Generating a complex transformation pipeline with multiple components can consume 10 to 20 credits. That is roughly equivalent to running the pipeline 5 to 10 times. The value proposition is that it saves an engineer 30 to 60 minutes of manual pipeline construction. Whether that tradeoff makes sense depends on your fully loaded engineering cost. At $150 per hour for a data engineer, saving 30 minutes is worth $75. Twenty Matillion credits at a typical bulk rate of $1 per credit is $20. The math works.

The risk is that Maia-generated pipelines are not always optimized for credit efficiency. Maia builds the pipeline that works, not necessarily the pipeline that works at the lowest cost. A human engineer might know to use pushdown SQL for a particular transformation. Maia might default to non-pushdown mode. The result is a pipeline that costs more to run every time it executes. The FinOps discipline for Maia is to treat AI-generated pipelines the same way you treat human-generated pipelines: review them for efficiency before promoting them to production.

Root cause analysis is a clearer win. When a pipeline fails at 3 AM, Maia can diagnose the failure (a source system timeout, a schema change, a credential expiry) in seconds. The alternative is an engineer waking up, logging in, reading logs, and tracing the error manually. The credit cost is small (1 to 3 credits per analysis) and the time savings are large.

What does an AI agent for Matillion FinOps look like?

Matillion has not released a dedicated FinOps agent, but the pattern from AWS and Snowflake applies directly. An agent that queries the Matillion API for pipeline execution history, runner utilization and credit consumption can generate the same kind of weekly cost summary, anomaly detection and optimization recommendations that the AWS FinOps Agent provides.

The highest-ROI agent use cases for Matillion are pipeline frequency auditing, runner utilization reporting, and Maia credit tracking. An agent can scan all pipelines, compare their scheduled frequency against their actual data freshness requirements, and flag pipelines that run more often than necessary. It can monitor runner utilization and recommend switching from hosted to self-hosted runners when the economics cross the break-even threshold. And it can track Maia credit consumption by user and team, which is currently a manual process for most organizations.

The Maia API itself is a candidate for agentic FinOps. A FinOps agent could call the Maia API to analyze a pipeline's efficiency and suggest specific optimizations: "this transformation step can be converted to pushdown SQL, saving an estimated 0.5 credits per run, or 120 credits per month at the current schedule."

Where do you start?

Start with an audit of your pipeline schedules. Export your pipeline list from the Matillion Management Console. For each pipeline, note the schedule, the average runtime, and the estimated credit consumption. Flag every pipeline that runs more than once per hour and ask whether that frequency is justified. Flag every pipeline that runs on weekends and ask whether the source data actually changes on weekends. Flag every pipeline that does a full load when an incremental load would work.

Then look at your runner configuration. If you are using hosted runners and running more than 50 pipelines per day, model the cost of self-hosted runners on your cloud provider. Include the engineering time to set up and maintain the infrastructure. If the numbers work, run a pilot with your three most expensive pipelines on self-hosted runners and compare the credit consumption.

Finally, set up a monthly Maia credit report. Track credits consumed by pipeline generation, root cause analysis and API calls. Break it down by user and team. Maia is new enough that most organizations have no idea what they are spending on it. Visibility is the first step to optimization, on Matillion as everywhere else.

For the deeper Matillion platform guide, the Data Productivity Cloud overview covers the architecture and credit model. For the broader FinOps lifecycle, the overview covers where agents fit across all platforms, and the Snowflake guide covers the equivalent credit-based model for data warehouses.

Sources

GitHub FinOps: Actions minutes, Copilot seats and the cost of AI coding at scale

2026-08-11T00:00:00Z

GitHub bills are deceptively quiet. A few dollars per seat per month, a few cents per Actions minute. But a 50-developer team with Copilot, Codespaces and a CI/CD pipeline that runs on every push can easily spend $8,000 to $12,000 per month on GitHub alone. And with the rise of AI coding agents (Copilot's agent mode, Cursor, Devin, Claude Code) that autonomously open pull requests and trigger CI runs, the Actions bill is growing faster than most engineering managers realize.

The three levers that keep a GitHub bill predictable are runner optimization, seat license auditing and agent cost attribution. The first two are standard FinOps. The third is new and specific to the agent era: when a Copilot agent opens six PRs to fix a bug, each triggering a full CI pipeline, who pays for those six Actions runs?

Where does GitHub spend actually go?

GitHub's pricing is modular. Actions charges per minute of job execution on GitHub-hosted runners, with different per-minute rates for Linux, Windows and macOS. A Linux job on a 2-core runner costs $0.008 per minute. A macOS job on a 3-core runner costs $0.08 per minute, ten times as much. A Windows job on a 2-core runner costs $0.016 per minute. Large runners (4 to 64 cores) cost proportionally more, and organizations on GitHub Enterprise can also use self-hosted runners at no GitHub cost.

Copilot charges per seat per month: $19 for Copilot Business (basic code completion and chat) and $39 for Copilot Enterprise (adds agent mode, knowledge bases, and pull request summarization). A 50-developer team on Enterprise spends $1,950 per month on Copilot seats alone, before a single line of code is generated.

Codespaces charges for compute and storage. A 2-core codespace costs $0.18 per hour. A developer who keeps a codespace open for 8 hours a day, 20 days a month, costs $28.80 per month. A 32-core codespace costs $2.88 per hour, or $460 per month for the same usage pattern.

Packages charges for storage and data transfer. The first 2 GB of storage is free, then $0.008 per GB per day for npm, NuGet and RubyGems packages, and $0.50 per GB per month for container images.

In a typical 50-developer organization, Actions minutes account for 40 to 50 percent of the total GitHub bill, Copilot seats for 25 to 35 percent, Codespaces for 10 to 20 percent, and Packages for 5 to 10 percent. The exact split depends on how heavily the team uses CI/CD and whether they use self-hosted runners.

Typical GitHub monthly spend for a 50-developer organization with Copilot Enterprise and Codespaces enabled. Illustrative. Data Today benchmark.

What are the three levers that pull hardest?

Runner optimization is the biggest single lever. GitHub-hosted runners are convenient but expensive at scale. A CI pipeline that runs 100 times per day at 10 minutes per run on a 2-core Linux runner costs $24 per day, or $720 per month. The same pipeline on a self-hosted runner (an EC2 instance or a Kubernetes pod) costs whatever the infrastructure costs, which is typically 30 to 50 percent less at high volume.

The self-hosting tradeoff depends on your pipeline volume. Below 500 Actions minutes per day, hosted runners are cheaper than the engineering time to manage self-hosted infrastructure. Above 2,000 minutes per day, self-hosted runners nearly always win. The break-even zone between 500 and 2,000 minutes depends on your team's DevOps maturity and whether you already manage Kubernetes clusters for other workloads.

Large hosted runners are a third option that sits between standard hosted runners and self-hosted runners. They are more expensive per minute than standard runners but complete jobs faster, so the total cost per job can be lower for CPU-intensive pipelines. A build that takes 20 minutes on a 2-core runner might take 3 minutes on a 16-core runner. The cost per minute is higher, but the cost per build is lower.

Seat license auditing is the simplest lever and the one most teams skip. Copilot seats are assigned per user. A user who left the organization three months ago but still has an active Copilot seat costs $39 per month for zero value. A user who has a Copilot seat but never uses it (fewer than 5 acceptances per month) is not getting value from the tool. GitHub provides usage data through the Copilot usage API and the organization's billing page. A quarterly audit of active versus assigned seats typically finds 5 to 15 percent waste.

Codespaces follows the same pattern. An engineer who started a codespace for a one-day debugging session and never stopped it will rack up costs for weeks. GitHub provides a Codespaces usage report that shows active codespaces per user, their uptime, and their cost. Set a policy that automatically stops codespaces after 30 minutes of inactivity (configurable in organization settings) and periodically audit for abandoned codespaces.

Agent cost attribution is the new FinOps challenge that did not exist before 2025. When a Copilot agent in agent mode autonomously creates multiple pull requests, each PR triggers a CI pipeline. If the agent creates six PRs to fix one bug and five of them fail CI, you paid for five CI runs that produced nothing. If the agent is configured to iterate (fix the bug, push, see if CI passes, fix again, push again), the feedback loop multiplies the Actions cost.

The solution is not to turn off AI agents. The solution is to attribute their costs. Tag CI runs that are triggered by agent-authored PRs (using GitHub Actions event payloads, which include the PR author). Report agent-triggered Actions spend separately from human-triggered Actions spend. If the agent's cost per successful PR is higher than a human's, invest in better agent prompts or restrict the agent to draft PRs that do not trigger full CI.

How do AI coding agents change the FinOps calculation?

Copilot's agent mode, Cursor's agent, Devin and similar tools represent a fundamental shift in how code gets written and how CI pipelines get triggered. A human developer writes code, opens one PR, and triggers CI once (plus any fixup commits). An AI agent writes code, opens multiple PRs in parallel, and triggers CI for each one. The Actions multiplier is the number of PRs the agent opens per task.

In a 2026 analysis of agent coding patterns across 50 organizations, the FinOps Foundation found that AI coding agents increase Actions minutes consumption by 2 to 5 times per developer. The increase is highest in organizations that have not configured their pipelines to skip CI for draft PRs or to use lightweight CI checks before running the full suite.

The countervailing force is that AI agents also reduce the number of human-authored PRs. A team that used to open 20 human PRs per day might now open 10 human PRs and 30 agent PRs. The total CI load goes up, but the human engineering time goes down. The net efficiency gain depends on whether the increased CI cost is smaller than the saved engineering cost. At typical Actions pricing, the CI cost of an extra PR is $0.50 to $2.00. The cost of an engineer spending 30 minutes on a bug fix is $50 to $100. The math favors the agent even with a 5x CI multiplier, as long as the agent's PRs ultimately produce working code.

What does an AI FinOps agent for GitHub look like?

GitHub does not offer a dedicated FinOps agent, but the ingredients are available. The GitHub REST API exposes Actions usage, Copilot usage, Codespaces usage and Packages usage at the organization level. An LLM agent with access to that API can generate the same kind of weekly cost report, anomaly detection and optimization recommendations that the AWS FinOps Agent provides.

The highest-ROI agent use cases for GitHub FinOps are unused Copilot seat detection, abandoned Codespaces detection, and agent-triggered Actions cost reporting. An agent can query the Copilot usage API, identify seats with zero or near-zero activity in the last 30 days, and post a list to the team's Slack channel with an estimated savings if those seats are deprovisioned. It can query the Codespaces API for codespaces that have been running for more than 24 hours without a push event and flag them for review. And it can tag CI runs by PR author (human versus agent) and generate a monthly report that shows the split.

The harder question is whether an agent should be authorized to deprovision unused seats or stop abandoned codespaces automatically. The pattern from AWS and Snowflake suggests yes, but within policy guardrails. An agent that detects a Copilot seat with zero usage in 90 days and opens a Jira ticket to deprovision it is useful. An agent that deprovisions the seat automatically and the user discovers it when they need Copilot for a rare task is problematic. The human-in-the-loop pattern applies here too.

Where do you start?

Start with a one-time audit of your current GitHub spend. In your organization's billing settings, export the last three months of usage data for Actions, Copilot, Codespaces and Packages. For Actions, break it down by workflow and by runner type. For Copilot, break it down by active versus inactive seats. For Codespaces, identify any codespace that has been running for more than 72 hours.

Then pick one lever. If Actions is your largest line item, evaluate self-hosted runners for your three most expensive workflows. If Copilot is your largest line item, deprovision the seats that show zero activity. If Codespaces is your largest line item, set an auto-stop policy and audit for abandoned codespaces.

The agent attribution question is worth addressing even if you are not yet using AI coding agents heavily. Tag CI runs by PR author now, before the agent volume grows. Having the data from day one makes the conversation about agent cost attribution factual rather than speculative.

For the broader FinOps lifecycle and where agents fit across platforms, see the overview. The AWS guide covers the AWS FinOps Agent that pioneered the pattern, and the Snowflake guide covers the equivalent for data warehouse credits.

Sources

AWS FinOps: the cost levers that actually move the needle

2026-08-11T00:00:00Z

AWS gives you more than 200 services, but your bill is almost certainly dominated by five of them. EC2 compute, S3 storage, RDS databases, Lambda functions and data transfer together account for roughly 80 percent of a typical SaaS organization's AWS spend. If you optimize nothing else, optimize these five. The good news is that AWS has built a mature FinOps toolset around them, and in 2026 it added an AI agent that does a growing share of the investigative work.

The three highest-ROI FinOps actions on AWS are rightsizing compute, buying commitment discounts, and tiering your storage. Everything else (spot instances, auto-scaling, Graviton migration, S3 lifecycle policies) amplifies those three. If you do the big three well, the rest is fine-tuning.

Where does AWS spend actually go?

EC2 is still the largest line item for most organizations, typically 30 to 45 percent of the total bill. But the mix has shifted. In 2023, EC2 was often 50 percent or more. The growth of serverless (Lambda, Step Functions, EventBridge) and managed databases (RDS, Aurora, DynamoDB) has spread the spend across more services. Data transfer costs, especially cross-AZ and cross-region traffic, are the silent budget killer: they are hard to attribute, hard to forecast, and easy to overlook until the bill arrives.

A typical mid-size SaaS organization spending $50,000 per month on AWS might see a split like this: EC2 at $19,000 (38 percent), data transfer at $9,000 (18 percent), RDS at $7,500 (15 percent), S3 at $6,000 (12 percent), Lambda at $4,000 (8 percent), and everything else at $4,500 (9 percent). Your numbers will differ, but the shape is consistent across hundreds of organizations that have shared their cost data with the FinOps Foundation.

Typical AWS monthly spend by service for a mid-size SaaS organization at $50,000 total. Source: FinOps Foundation State of FinOps 2025. Data Today benchmark.

What are the three levers that pull hardest?

Rightsizing compute is the single largest source of savings for most teams. AWS Compute Optimizer analyzes your EC2 instances, Auto Scaling groups, Lambda functions and ECS services and recommends smaller instance types, fewer instances, or a move to Graviton ARM-based processors. The typical recommendation saves 20 to 40 percent on the affected resources. The catch is that rightsizing requires engineering time: someone has to test the smaller instance type under real load, schedule a maintenance window, and verify that latency and error rates did not change. This is where the AWS FinOps Agent helps. It can generate a rightsizing report grouped by team, flag the instances that are safe to resize (CPU utilization below 40 percent for 14 days), and create a Jira ticket with the recommended action and estimated savings. The engineer still does the work, but the agent does the triage.

Commitment discounts are the second lever. AWS offers Reserved Instances (one or three year commitments on specific instance types) and Savings Plans (a dollar-amount commitment that applies across any instance family in a region). Compute Savings Plans typically deliver a 30 percent discount over on-demand pricing. The Savings Plans Purchase Analyzer inside Cost Optimization Hub models different commitment levels and shows the tradeoff between discount depth and utilization risk. An agent can run this analysis on a schedule and recommend a purchase amount. The human still clicks "buy," because a three-year commitment is a financial decision, not a configuration change.

Storage tiering is the third lever and the most overlooked one. S3 Intelligent-Tiering automatically moves objects between frequent-access and infrequent-access tiers based on access patterns, saving 20 to 40 percent on storage costs with no engineering effort. S3 Lifecycle policies can transition older objects to Glacier for long-term retention at a 70 to 90 percent discount. EBS volumes that are unattached or have zero IOPS for seven days are pure waste: an agent can detect them, snapshot them, and delete them automatically if they are tagged as non-production.

What does the AWS FinOps Agent actually do?

AWS launched the FinOps Agent in preview in late 2025, and it represents a genuine shift in how cost work gets done. The agent runs on a schedule, on anomaly triggers, or on demand, and it draws on Cost Explorer, Cost Anomaly Detection, Cost Optimization Hub and Compute Optimizer as its data sources.

The agent operates in three modes. Scheduled mode generates a weekly cost summary per team and posts it to Slack or Microsoft Teams: spend versus budget, top cost drivers, new optimization recommendations, and anomalies detected. Anomaly-triggered mode fires when Cost Anomaly Detection flags a spend spike: the agent investigates the root cause by querying CloudTrail for recent API calls, identifies the responsible resource and team, and posts an incident summary. On-demand mode lets any engineer ask a cost question in natural language: "why did our Lambda bill double this week?" or "which EC2 instances are the best rightsizing candidates for my team?"

The agent integrates with Jira and Slack, which matters because it puts cost data where engineers already work. An engineer does not need to log into the AWS console, navigate to Cost Explorer, build a filter, and interpret a graph. They ask a question in Slack and get an answer. This is the same pattern that made PagerDuty and Datadog successful: bring the signal to the engineer, do not make the engineer go find the signal.

What about the services beyond the big five?

Lambda costs are driven by two variables: memory allocation and invocation count. Overprovisioning memory (giving a function 1,024 MB when it uses 128 MB) is the most common waste pattern. AWS Compute Optimizer now supports Lambda rightsizing recommendations. Provisioned Concurrency, which keeps functions warm to eliminate cold starts, is worth the cost for latency-sensitive production endpoints but pure waste for batch processing jobs.

Data transfer costs are the hardest to optimize because they are architectural. Cross-AZ traffic ($0.01 per GB in each direction) adds up fast when you run multi-AZ RDS, multi-AZ Elasticache, or cross-AZ service-to-service calls. The fix is not a configuration change. It is an architecture decision: keep services that talk to each other in the same AZ, use VPC endpoints instead of NAT gateways for S3 and DynamoDB access, and put a CloudFront distribution in front of S3 to serve content from the edge instead of the origin.

RDS costs follow the same pattern as EC2: rightsize the instance, buy Reserved Instances, and delete snapshots older than your retention policy. Aurora Serverless v2 is worth evaluating for workloads with variable traffic patterns: it scales capacity up and down automatically and can cut costs by 30 to 50 percent compared to a provisioned instance that is sized for peak load.

What does an AI agent not do yet?

The AWS FinOps Agent does not make changes. It recommends, summarizes and creates tickets, but it does not stop an instance, modify a security group, or purchase a Savings Plan. This is by design. The agent is a copilot, not an autopilot. The same is true of every FinOps agent on the market in 2026.

The agent also does not understand your business context. It does not know that the "idle" instance is kept warm for a quarterly regulatory report, or that the "overprovisioned" database is about to absorb a data migration. The human in the loop supplies the context that turns a recommendation into a decision.

The direction of travel is clear, though. AWS is investing heavily in agentic FinOps, and the capabilities that are manual today (rightsizing execution, Savings Plan purchasing, resource scheduling) are the ones most likely to be automated next. If you are building a FinOps practice today, build it with the assumption that an agent will handle the triage and the routine actions within two years. Your job is to set the policies, define the guardrails, and make the judgment calls the agent cannot make.

For the broader FinOps lifecycle and where agents fit across all six domains, see the FinOps overview. For platform-specific cost controls, the Snowflake guide covers warehouse credits and the Postgres guide covers RDS sizing.