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.
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.
