Presented by

Want to appear here? Talk with us

Worried about unpredictable Bedrock costs?

We built a free calculator to help you understand and forecast your spend quickly.

With the AWS Bedrock Pricing Calculator, you can:

Heading to AWS re:Invent 2025?

Come meet us at Booth #633. To see whether a suite meeting with a Finout executive makes sense, book a short 15-minute call and we’ll take it from there.

Managing AWS costs can feel like watching money disappear while you sleep. Many teams run their development servers all day and night, use machines that are too big for their needs, and only find out about the damage when the bill shows up at the end of the month.

You can cut your AWS spending in half without breaking anything important. The article walks through seven common money problems that teams face with AWS and shows how to fix them with smart automation.

Real Numbers

One example shows a team spending $800 per month on a development environment that ran constantly with oversized machines. After automation, they spent $430 per month and stopped doing manual work.

The article includes code examples showing how to schedule Lambda functions to stop instances at 7 PM on weekdays and how to set up alarms that notify your team when CPU usage stays above 80% for ten minutes.

Read More

FOCUS 1.2 Schema on GA adds 14 columns including InvoiceId, CapacityReservationStatus, and SaaS-friendly pricing fields for standardized cost exports and easier invoice reconciliation.

Cost Efficiency Metric now available in Cost Optimization Hub provides a single, auto-calculated score combining rightsizing, idle cleanup, commitments, and migration savings. Updates daily with 90-day history, showing improvements within 24-48 hours. Pull via API to integrate into dashboards and track ROI across accounts.

RISP Group Sharing lets you control how Reserved Instances and Savings Plans discounts apply across account groups using Cost Categories. Choose Prioritized (leftovers share org-wide) or Restricted (benefits stay in-group) sharing modes to improve chargeback accuracy.

AWS Managed Monitors in Cost Anomaly Detection now auto-track linked accounts, tags, and cost categories. Create one monitor to automatically discover and learn patterns for up to 5,000 values—eliminating hundreds of manual monitors.

Read All AWS Updates

Serverless GPUs in Container Apps reach GA in more regions. Scale GPU inference and training workloads to zero to pay only when running—controlling expensive GPU costs without managing node pools.

Smart Tier account-level tiering (preview) automatically moves Blob Storage and ADLS data between hot/cool/archive tiers, reducing storage costs without manual lifecycle policies.

Read All Azure Updates

Cut Cloud Build costs for simple deploys — deploy source artifacts directly to Cloud Run. By bypassing Cloud Build for supported flows, teams can reduce CI/CD build time and the associated Cloud Build costs for simple deploys.

Read All GCP Updates

S3 storage classes show up on AWS tests. Most people just remember simple rules like "frequent access means Standard" or "once a month means Standard-Infrequent Access." This works for passing tests, but it does not explain why these rules exist.

This blog tries to answer the real questions. How much money do you actually save with different storage classes? Where do those monthly or quarterly rules come from? When do the savings beat the cost of moving data around?

The article uses interactive charts to break down costs. You can click on them to see how different factors change the total bill. The model uses three simple numbers: how many files you have, how big each file is, and how often you read them.

It also covers two other costs. First, moving files between storage classes costs money upfront, but lower monthly storage costs pay this back over time. Second, both Infrequent Access and Glacier charge you for minimum storage time. If you delete files too early, you still pay as if you kept them for the full period.

A wonderful interactive piece for those starting to know S3 and their costs.

Read More

We talk with Alfonso San Miguel — FinOps Author, Cloud Architect and trainer at Mastering in FinOps — about his real journey into the world of FinOps. Starting a new series of My FinOps Story videos!

Your cloud bill shows up every month with a big number at the bottom. But that number doesn't tell you what matters most: how much it costs to serve each customer, process each order, or handle each API call.

This gap between spending and value is a real problem for any company running on cloud infrastructure. FinOps solves this by treating cloud costs like any other cost of doing business.

Let's walk through a real example. Say you run a B2B software company and want to know your monthly cloud cost per active customer. First, define what counts as a business unit. For this example, an active customer is anyone who made at least one API call this month.

Second, add up all cloud costs for each customer. If you tagged your resources with customer IDs, you can write a SQL query against your billing data to sum up costs by customer.

Third, handle shared costs that can't be tagged to specific customers. Things like your Kubernetes control plane, shared databases, network gateways, and monitoring tools serve all customers.

Calculate the total cost of these shared resources. Pick a fair way to split them up, like the percentage of API calls each customer makes. If Customer A makes 10% of all API calls, they get 10% of the shared infrastructure costs.

Fourth, combine direct costs and allocated shared costs for each customer. You can do this with a Python script that merges your billing data with your business metrics. The script pulls active customer data from your internal API, calculates each customer's share of shared costs, and adds it to their direct costs. The output shows total cloud cost per customer.

Most companies can tell you their total cloud bill. Few can tell you how efficiently they're delivering value to each customer. Unit economics changes the conversation from "we spent too much on AWS" to "here's how we can serve customers more efficiently."

Read More

CDOps Tech just released an open-source tool that helps you find wasted money in your AWS cloud account.

You download the free tool from GitHub. Set up your AWS login details. Run one command. The tool scans your account and creates a report showing what you found and how much money you could save each month.

One company found 12 zombie resources costing them over 120 dollars per month. That's more than 1,500 dollars per year just disappearing for no reason.

You can scan one region or all regions at once. You can run it manually or set it up to check automatically every week. Some teams even add it to their regular code checks.

The tool needs special permission to look at your AWS account, but only permission to read and look, never to change or delete. The creators included the exact permission settings you need to copy and paste.

Everything is open source, which means you can read all the code yourself to make sure it's safe. Security experts already checked it and found no problems.

Read More

Carlos Alberto was working with a client managing multiple AWS accounts ran into a serious problem. People were changing production resources by hand instead of using CloudFormation. This meant the code no longer matched what was actually running.

Configuration drift can cause big headaches. Updates might fail to roll back. Different environments stop matching each other. Tracking changes becomes nearly impossible.

The solution uses AWS Config, EventBridge, and SNS to watch for drift across all accounts in real time. Here's how it works:

The system has two parts. A central "hub" account receives all drift alerts. Then "spoke" accounts run checks on their CloudFormation stacks every few hours.

When the spoke accounts find drift, they send details to the hub. The hub stores everything in DynamoDB and sends email alerts to the team.

The first test run checked 23 stacks and found 7 with drift problems. One API stack had three resources changed by hand. Someone switched the API Gateway from regional to edge mode. They also bumped Lambda memory from 128MB to 512MB and increased DynamoDB read capacity from 5 to 25 units.

The email alerts show exactly what changed. They list the expected values from CloudFormation and the actual values found in AWS. This makes it easy to spot what someone modified and decide whether to update the template or revert the changes.

The system keeps a complete history in DynamoDB with a 30-day automatic cleanup. Teams can query this history to spot patterns and see which accounts or resource types drift most often.

This automated approach catches manual changes quickly, helping teams keep their infrastructure code and actual resources in sync across all their AWS accounts.

Driving FOCUS

Christopher made a wonderful series of articles on multiple FinOps topics just when I started my journey in FinOps. Glad FOCUS has such amazing people involved.

Connect with the Professional of the Week

Use BLACKFRIDAY Code on Checkout for 25% DISCOUNT!

We’ve created Learn FinOps Weekly because we believe that hands on learning is the way to make real impact with IT Budgets.

With courses made by FinOps Professionals, well-known Authors in the industry.

Carefully curated with the FinOps Weekly Team to align with our actionable way of doing things.

Learn Actionable FinOps, together

See you all inside!