🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Advanced multicloud cost reporting with FOCUS (COP419)
In this video, Justin Marks and Jason from AWS demonstrate advanced multi-cloud cost reporting using FOCUS (FinOps Open Cost and Usage Specification). They explain how FOCUS solves the complexity of normalizing cost data across multiple cloud providers and SaaS platforms. The session covers FOCUS 1.0 and newly launched 1.2 specifications, including 48+ standardized columns for consistent cost analysis. Through live Athena demos, they show how to create consolidated views joining AWS, Azure, and other provider data, calculate key metrics like effective cost and savings percentages using billed cost, list cost, contracted cost, and effective cost columns, and use advanced SQL techniques with JSON extract and regex patterns to analyze tag-based cost allocation across environments and applications. They also reference Cloud Intelligence Dashboards for visualization and provide practical query examples from the Cost and Usage Query Library.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
The Multi-Cloud Cost Reporting Challenge: A Common Journey
So I want to start by asking a question. Who here has the word FinOps in their title or job description officially? Raise your hands. We have about four or five hands, maybe ten. Probably about a quarter of the room or so. Who's in the second group where your title has absolutely nothing to do with FinOps and you've kind of accidentally stumbled into having to do cost allocation or cost reporting? Yes, my hand is up for this one. Awesome.
So I'm Justin Marks. I'm a Senior Technical Account Manager with AWS Support. This is Jason, Product Manager for AWS Cost and Usage Report and the FOCUS. We're going to talk to you today about advanced multi-cloud cost reporting with FOCUS. But before we get into the FOCUS topic, I want to take everybody back through probably a common scenario you've dealt with over your career of dealing with cost and usage data in the cloud.
You had a team who started using AWS and you had to figure out four things about cost and usage data. First, how you're going to collect that data by getting the reports turned on. Second, where you're going to deliver them. Third, you're going to have to figure out how to normalize it and get it into formats that the finance team cares about, and get it into formats that your engineering teams or the teams that want to visualize it need. Fourth, you're going to need to figure out how to analyze it. What tools are you going to use? Are you going to pick one off the shelf? Are you going to try to wing it with some of the native tooling depending on which cloud provider you're with?
Then you need to figure out how to derive insights out of that data and finally how to visualize it. Ultimately, folks end up building dashboards and trying to find ways to build reports for their executives on how this is going. But it doesn't stop there. It wouldn't be a multi-cloud conversation if it stopped there. So then you get another team who comes and says, "Hey, we use a SaaS platform, and this SaaS platform has costs and usage, and we need the data from there too. We'd like to integrate that into our reporting pipeline."
So you have to go figure out these four things for that provider too. And then when you know it, you hear about this other team that's running in another cloud, and now you've got to figure it out again. You can see where I'm going with this. Having to relearn these things every time you adopt a new provider or use a new SaaS platform can be hard.
Introducing FOCUS: The FinOps Open Cost and Usage Specification
Jason, what do we have to help folks manage this complexity? Sure. The thing is, practitioners spend countless hours every day to normalize the data. This is because different providers out there define the data differently, and we want to solve that problem for our customers and we want to solve it at the root. So organized by the FinOps Foundation under antitrust compliance, we worked with different field of practitioners from different industries and created this new open specification called FOCUS. FOCUS stands for FinOps Open Cost and Usage Specification. It provides consistent cost and usage data such as billing, pricing, and cost metrics.
Let me take you through a quick journey of how the FOCUS journey would look like when you start with FOCUS. When you start FOCUS, you will first get the data from your data generators. This can be your cloud providers, can be SaaS providers, or even your data center providers. FOCUS is an open specification anyone can create. As of today, the majority of the large cloud providers has adopted FOCUS, and we are seeing an increasing trend for the SaaS providers to adopt FOCUS. This will give you a universal view of your cloud cost and usage data across all your technology stack, not just limiting to cloud.
Once you get your data from your providers and you inject that data into your FinOps platforms, this can be Amazon Athena, which we will be demoing today, and you can query the data directly. You can also visualize your FOCUS data using Amazon QuickSight or even plug that data into Excel for different insights. Once you have the data injected into your FinOps data platforms, you can analyze the data for different use cases such as demonstrating your business value and finding optimization opportunities across the vendors that you have.
Assessing the Room's FOCUS Experience and Understanding the Specification
Now you understand how FOCUS looks like at a high level. So let us do a quick exercise. Justin, can you help us run a quick exercise to see where people are with the FOCUS journey? Yeah, we're just trying to see where folks are. I think I may have asked a couple of you outside, so I have a little bit of a sample to base this off of, but hands up if you've seen the FOCUS spec, like you've read some of the documentation out there. It's about half the room.
Okay, so for the folks with their hands down, you've now seen part of the FOCUS spec. It is a big document. It covers things like normative requirements, different columns, things about metadata and attributes for the cost of usage dataset.
This is an example of the Availability Zone column. You get a nice definition here that explains the intention. The bullet points call out that the first bullet point says it is a recommended column, which means it is not mandatory and may or may not be populated. That will be important later. It is type string, and things like that. So we can check this one off.
Everybody in this room has seen part of the FOCUS specification. Let's do a quick hands up if you have FOCUS reports created and you are playing around with that data today. A couple of hands up, so about half the room. How about if you have analyzed or visualized FOCUS data before, so it is not just there, you are actually using it and your teams are looking at it? Hands up if you have. Okay, and how about if you have joined AWS FOCUS data with other providers? Show of hands, who has pulled in multiple providers, including SaaS providers and other providers? Okay, we got four or five hands. Great. So we have a good understanding now of the experience with FOCUS in the room.
Creating FOCUS Reports with AWS Data Exports: From 1.0 to 1.2
Jason, do you want to talk to us about how, for the folks that have their hands down who have not created the reports yet, how they can create FOCUS for AWS? Sure. The AWS Data Exports platform is the centralized data hub for you to export all your FinOps related datasets. As of today, we support four different table types. The first one is AWS Cost and Usage Report 2.0, which is our native supported cost and usage data, and it provides the most granular AWS cost and usage data. The second is FOCUS. We currently support 1.0 and 1.2, which we just launched two weeks ago. The third is Cost Optimization Recommendations, which pulls the data from Cost Optimization Hub to help you identify cost optimization opportunities like right sizing or Savings Plan recommendations. And lastly, there is Carbon Emissions exports, which provides you the carbon footprint data associated with your database usage to help you better track your sustainability data.
Let us dive a little bit deeper into the FOCUS dataset with database columns. We launched FOCUS 1.0 last year during the re:Invent event, and FOCUS 1.0 includes 48 columns total: 43 columns from the FOCUS 1.0 specification itself, and we added 5 additional AWS columns. This helps customers better navigate AWS resources with FOCUS itself. There are 8 columns with conformance gaps, and we have published those in the conformance gap report, and we also did that in 1.2. As mentioned, FOCUS 1.2, which we just launched two weeks ago, is definitely encouraged for you to try this enhanced version of the FOCUS specification.
FOCUS 1.2 provides 14 new additional columns on top of FOCUS 1.0. It includes capabilities like Capacity Reservation ID and Status columns that help you better manage your capacity reservations by breaking down your capacity reservation use and unused status. It includes the Invoice ID column, which helps you better reconcile your cost and usage data with physical invoices. It also includes capabilities for SaaS providers to generate the FOCUS dataset due to the newly introduced Pricing Currency columns, which enable SaaS providers to integrate their pricing in terms of tokens and virtual currencies. It also added more granularity for SKU usage and SKU usage analysis, which includes your usage type and product attributes. And the last one is Account Structure Classification, which helps you identify whether your usage is coming from your management account or from a member account. One more thing not highlighted here is that FOCUS 1.2 also starts supporting hourly, daily, and monthly time granularity, whereas FOCUS 1.0 today only supports hourly.
Mapping CUR 2.0 to FOCUS: Understanding Column Relationships and New Capabilities
Okay, Justin, you gave a great presentation last year about CUR 2.0, and this year you are giving a presentation about FOCUS. What are the differences? Yeah, so who here feels comfortable with Cost and Usage Reports and has played around in CUR? All right, a couple more. I think it is valuable to just take a minute here and frame up some of the relations and stuff between the two datasets.
One of the most common questions I've received about FOCUS up to this point is whether these columns map to each other and how we map CUR values to FOCUS values. Here's a quick example with a non-exhaustive list of eight columns that I picked out that map one to one. These include things like your account information, the charge periods, service names, resource IDs, and tags. If you look at usage rows in CUR 2.0, they map directly to the values that you would see in FOCUS 1.0.
There are also columns like blended cost and line item type that are related, but the values aren't going to map one to one. Sometimes things will map, and sometimes there are requirements in FOCUS 1.0 for specific values that you're not going to see in CUR. They're related—one informs the other. The CUR 2.0 values inform what you see in FOCUS, but they're not going to map one to one.
There are also some net new columns that you get from adopting FOCUS. These include things like effective cost. If you've used net amortized view in Cost Explorer, we don't have a column in CUR today, but there are ways I'll show you in a few minutes how to get this value out of the cost and usage reports. Effective cost is essentially the net amortized cost from Cost Explorer, so if you adopt FOCUS, you can expect those values to align.
We also have things like service category. If you were using CUR to analyze all of your storage usage or all of your compute usage, you would have to build a big WHERE statement, add all the services, usage types, and so forth that you'd need to track there and report on. But you can use service category in FOCUS, and it's already categorized for you.
As Jason called out, we do ship five custom columns into our FOCUS reports via data exports. In the spec, they call out that any provider can prefix custom columns with an x underscore. These are valuable if you use some of these CUR 2.0 auto values. If you use cost categories today or if you're looking for operations or usage type, you can pull those values using these x_ columns. When you're joining these data sets from multiple providers, you're going to want to leave these out unless you want a bunch of nulls everywhere.
Building a Multi-Cloud Architecture: Setting Up Athena with Consolidated FOCUS Views
Before we get to the demo, I want to take a few minutes to talk about the architecture of what we're working with today. We have this FinOps account, which is where we're going to do all of our analysis. We're not going to run this in a master payer account because best practices say we shouldn't run anything there if we can help it. When you're trying to work with your AWS FOCUS data, we're going to pull that data across and replicate it from the bucket in your master payer account into the FinOps account for analysis.
Then you're going to tie AWS Glue together. Glue is going to crawl it and add it to the data catalog, and then we'll use Amazon Athena to query that data. If we were just doing AWS data today, this is where this architecture diagram would stop. But we want to show multiple clouds. Depending on your setup, you can use something like AWS Glue connectors to reach out to various data sources and pull other FOCUS data in and put it in an S3 bucket.
You can use AWS Lambda to go out and grab things from more custom places if needed. Some providers may provide options to push that FOCUS data into an S3 bucket. A couple of these examples are available, though your use case may differ depending on which one you choose. Essentially, the common thing is to get the data into S3. We're going to use Glue to do any transformations if needed and then do the cataloging so that it's ready to go.
Finally, to tie it all together, today we're using a consolidated view in Athena that unions all of this data together to give us one place to query. And it doesn't have to be Athena. You can visualize on top of this too. Athena can be a data source for services like Amazon Managed Grafana, Amazon QuickSight, or any other BI tools that can tie into Athena as a data source. Once you get this consolidated view, you can build whatever graphics and visualizations you need.
It doesn't need to be Athena. Customers regularly use Amazon Redshift here too. They may do scheduled data loads or run Lambda functions to get things loaded into Redshift, and then use things like the Redshift Query Editor v2.0 to query that data. Any visualization solutions like Grafana and QuickSight that can use Redshift as a data source would work just as well.
Let's see FOCUS in action. The first example in our demo will walk through the Athena setup. Quick spot check—can everybody see this? Is this big enough? Great, thumbs up.
We're here in our Athena console, and I'll give you a quick tour. We have a database set up specifically for FOCUS samples. We've pulled in a number of tables with example data that we've gathered from the Azure FinOps toolkit, from the FinOps Foundation, and from our FOCUS reports. We've built a consolidation view down here, which is what we're going to examine now.
This view is an example that I've borrowed from the Cloud Intelligence Dashboards. Hopefully you've heard of them before, but if you haven't, they're a solution available out there with a FOCUS dashboard. Inside their documentation, they have a published FOCUS consolidation view. This is the same approach they used to build their dashboards. We've borrowed some inspiration from them and tuned it as needed for the demo.
This line here is quite important. Remember how I called out the Availability Zone example from the spec? It's not a mandatory field, so it may not always be present. There are times when we use nulls to add these columns so the unions work. Our first query pulls in our FOCUS v1.0 report. We've selected just about every column except for the custom columns. One thing to call out is that our tags field is a map type. The other examples we had were in JSON, which would be difficult to work with. So we cast our tags to JSON and format them to keep things consistent, which isn't necessary but makes the demo easier.
We then do a UNION ALL where we pull in the Azure sample from the FinOps toolkit. You can see places like Availability Zone where we've added nulls because this sample dataset didn't even have that column, but for the union to work, we needed something there. There are also places where we've done some timestamp formatting for consistency, such as casting from ISO 8601 to something more friendly for us to work with.
Finally, we did one more UNION ALL with the FinOps Foundation sample. This includes sample data from multiple providers, and it's a very similar story—just dealing with some formatting for datetimes. For this one, we had to use COALESCE because some of the samples had null values, and multiplying or dividing by null doesn't work out very well. So we used COALESCE to replace any null values with zeros. That's it for this view. I can give you a quick preview of what we're dealing with here. This is just a quick sample of the first couple of columns, and it's everything we would have expected.
Understanding FOCUS Cost Columns: From Billed Cost to Savings Calculations
Let's go ahead and close out of this now that we've seen how to set this up. Jason, do you want to walk us through some of the cost columns and how to derive savings and how to think about how the different cost columns work?
Sure. As the person who manages cloud costs and usage data, you will likely be asked questions like how much we spent on the invoice last month, or how much our usage cost would be if we did not have any commitment purchases, or how much the amortized cost would be if we purchased everything upfront with savings plans. This can be explained with the FOCUS dataset via the four standardized cost columns today. Let me quickly show you that.
In the FOCUS dataset, you can sum up your billed cost, which is very simple as a billed cost, and this gives you the cost basis of your invoice. For running this query, you select the data and hit run, and this will give you the exact amount that matches your invoice. With FOCUS 1.2, the invoice ID columns allow you to add an invoice ID column that will show the invoice you have paid for each invoice ID. This helps you expand the first question: How much money have you spent with the invoice across different providers?
Now let me remove that and answer the second question: How much would we spend if we do not have any discounts or commitment purchases with the database? For this question, you can use the list cost column, which is equivalent to the on-demand cost shown in the dataset. This column shows your usage cost without any discounts and commitment purchases. For correlated content, you can use the contracted cost, which represents the cost with discounts but without commitment purchases.
Third, to answer the question of what my amortized cost would look like if I purchase everything upfront with the same spec, we introduce an effective cost column. This shows your amortized costs with all discounts and all commitment purchases and reduced rate impact. After knowing these three cost columns, you can do simple math by using your list cost minus your contracted cost. This tells you how much savings you have achieved on discounts. By using your contracted cost and subtracting your effective cost, you will know how much commitment purchase savings you have achieved with your account.
You can also calculate the percentage of savings by using your sum of list cost minus your sum of effective cost to get your total savings and dividing by the sum of list cost and multiplying by 100 to get the percentage discount. Here, we need to make an important note. In the FOCUS dataset, both usage records and purchase records are represented. In order to understand different hypothetical scenarios with discounts without commitment, you will need to apply one more filter called charge category, and you want to navigate to the usage record only. This is because in situations like when you have a savings plan purchase of $100, and if you have spent that $100 on your covered usages already, if you do not apply this filter, you will end up getting your list cost of $200. So when you do the analysis for usage, make sure you apply this filter to your records.
Let's run the query. You may notice that we have been highlighting subsections here. That is a way in Athena to run just sections of your query with other stuff further down. Just highlight everything that you want to run. In line 7, yes, contracted costs. There we go. Let's check if you all are focused and satisfied. If we make typos, please let us know. That is right. Let's run it again.
Perfect. This shows your usage record. If you do not have commitment purchases or discounts, you will end up paying for the same usage at $5,130, and with the discount it is going to be less. Your amortized cost is going to be $4,300. Your discount savings is $537, and you will also know your total savings discount of 16%. Let me hand over to Justin to do more advanced techniques for FOCUS queries. One thing you need to know is that the queries we are showing today, you can also run against the FOCUS 1.2 dataset. So it is backwards compatible.
Advanced FOCUS Queries: Calculating Effective Cost and Tracking Cross-Account Workload Distribution
Let's do a quick demo here of advertised costs and effective costs. We talked a little bit about how this is possible with CUR. I want to give you just a quick glance at what that would look like. If you're familiar with CUR 2.0, you'll know that this may be a little harder than it would be if you used FOCUS. So let's see, we want to grab billing start date. Let's grab the billing entity and the payer since we're doing a multi-cloud talk today. We'll add this amortized cost column, right? But that's not a column here.
If you've ever used the CUR query library, the Cost and Usage Query Library, hands up if you've ever heard of our library out there. We have this as part of Well Architected Labs, chock full of CUR and FOCUS queries if you're looking to get started with some of this analysis. One of the ones that we have in our library help section is how to calculate amortized cost with CUR. We've already done the hard work here, so I'm just going to borrow this so I don't have to take it all back out. We'll paste it in here. Then we're going to focus in on our sample data set, which has all this data from September. I'm going to borrow Jason's filter. Then we're going to see what our advertised costs look like in this payer that we're running it against.
I didn't add my table because I'm not working in the same space on this one since this is our FOCUS sample, so I'm going to grab it out of a different database. I did this earlier and I already used the FOCUS column when I shouldn't have. So you can see here that to get advertised costs, we had to copy and paste this nine-line case statement where we're evaluating different parts of the values here to determine what number we should use. For this payer account, we had 22,835 as amortized. But we said effective cost was net advertised, right? So how do we figure out net amortized?
We have to pull in those net fields, those net columns. Unfortunately for this demo account, there are no discounts, so a lot of those columns are null. We're using coalesce here to make sure that we handle those nulls correctly. If you've never used coalesce, I have another example in here and I'll show it the next time on the next query. We're just going to copy and paste this net advertised one over our advertised costs. What it should do is any place where there's a value in our related net columns, it will use those first, otherwise it will grab our non-advertised ones, so this should give us the same values. So this payer has 22,835. Great. So what would this look like if we were just using FOCUS today?
The same exact query in FOCUS is just selecting billing period start, provider name, billing account ID, and an effective cost instead of a nine-line case statement. We're going to grab this from our FOCUS Consolidated view that we set up earlier, which should give us not just this payer account. We need to sum this up. What we're getting now is not just our 22,835 here, right, the same value from this payer, but now we've pulled in our data from other providers and other accounts. That's one of the ways that you can save some time, not having to build out your own effective advertised net advertised cost field. Let's talk about the last example we have here where we've been tasked to figure out where workloads may be running across accounts and or providers. Let's say our boss has come to us and they've asked us to track down where our Foo and Bar applications are running and where they cross.
Let me show you an example of the data we're working with. They show up with a crude drawing that says, "Show me where production foo is 50% in one account and 50% in another account, and maybe where things span different providers as well." This is what we're working backwards from today.
The first thing we want to do is pull in our cost data to figure out where all of this is. This should give us a very similar view to what we saw in our effective cost calculation, but now we've brought in the account name so we can track down providers' account names and how much that effective cost was.
Now that we have that, we need to pull this across apps and environments. We had production and development. Where are we going to pull this from? Tags, exactly. So what do the tags look like? Let's query our tags column here. We're going to use distinct so that we can grab unique values and get an understanding of what we're working with.
You can see it's all JSON, which is great for the JSON format we used in the view. However, you can see that in some places we've used "env" for the environment key. Some other teams used "environment." Those teams sometimes don't follow the tags exactly as we hope. Then sometimes we have things like "application," and in other places we have "app" or something else. So we have to be able to deal with all of these different values.
How do we extract some of these values using Athena? I've come up with two different ways that I think we could work this. One is using JSON extract, and one is using regexp extract. Which one does anyone have a preference for? Hands up if you think we should do the JSON extract one first. How about the regexp one? Anybody interested to see the regexp one? We'll start with the JSON one.
The way JSON extract works is you follow this general pattern. You're going to call this function and run it over tags, and then you'd want to run this against the path. So if it's "env" for the key, that should work just fine. But like we saw, if we run this, it's only going to give us a subset of them. So we have a rough idea of what some of the environments are if they use the "env" key.
In this example, we used another coalesce here, which again will give us the first non-null value in a set of values that you feed it. You can use other ways to do this too, but we're going to stick with coalesce today where we can copy and paste this and grab "env," we'll grab capital "ENV," we'll grab "environment." This should give us an expanded list of values here using JSON extract. Again, this is going to be dependent on getting everything into a nice consistent JSON format. We can see here that we have a couple more values.
So what if we don't have everything in a nice pretty JSON format? Well, we can still use things like regex to run it over a string. JSON is also just a string, so it works just as fine for that. Same kind of syntax, where we're going to call regexp extract and run this against tags. I'm not going to type a regex pattern out in front of all of you. These are all going to be shared in the code examples at the end. Here are some examples of different ways that we can use regexp extract to get things like environment.
We're going to drop this here and talk through it real quick. We're going to run regexp extract against tags. This is our pattern. We're looking for any keys that have one of these four environment patterns, and then we're going to find anything that's after the space, colon, and double quotes, and we're going to grab that value. That's what this should do for us. Let's see what that looks like and see if it looks any different than our JSON extract.
You can see with our regexp pattern, we actually captured a little bit more values. So there's a little bit more flexibility here, and I think it's a lot nicer than having a coalesce with four or five different values in there. The other difference here is that you can see JSON extract wraps things in double quotes. The regexp, the way that I wrote it, won't wrap it.
So we got environment. Now that we have the environment data, we still need to extract the applications. Let's grab our pattern here for the application field. You can see I've accounted for capitalization changes. I've also accounted for some teams using different naming conventions like "project" and the FinOps team using their own "FinOps" tag. We've pulled in the data for all of these variations, and we'll extract the JSON results for now. This should give us a list of distinct combinations between environment and application.
Now we can see all the environment and application tag combinations in our focus data. This is how we're going to need to pull this data and join it with the cost data to start figuring out the distribution. We've figured out the costs and the extraction, and now we're going to join them together. We're going to try to figure out if the Foo app or whichever one of these apps is split fifty-fifty between accounts, sixty-forty across providers, or something like that.
The first thing we're going to do is take that initial query we wrote and wrap it in a WITH statement. This lets us take these results that we've been seeing throughout our queries and put them into a temporary table so we can do more work with them. You can see here we'll run this subsection again so everyone can see we've added effective cost into the mix. This should give us our provider, our account name, the environment and the app tags, and then the effective cost. You can see we have a couple of production apps here costing a few dollars in different places.
Now that we've wrapped that in the WITH statement, we can go ahead and run queries against this result set. What this is going to let us do is use window functions. If anyone's ever used a window function, we're going to add each total cost to the row for either that environment or that app so we can do more calculations. We're going to calculate some effective costs using the OVER clause, which is going to give us our window function. We're going to partition this by the regex environment tag, and this is going to give us a new column.
So what this is showing now is we have this last column that shows us the environment cost. If we scroll over here, this is saying our tag for non-production environments costs a total of seven thousand nine hundred thirty-eight dollars, which doesn't seem particularly interesting when it's the same as the effective cost. But as we scroll down and look at production, this shows us that our production environment costs us three hundred fourteen dollars. This lets us do calculations for how much this row aligns with its aggregate.
We're going to call this total and effective cost. Then what we'll do is add a second calculation because we're not doing this just for environments. We want to do this for both apps and environments. So we're going to add the app tag in here as well. This will show us our environment and application effective cost across the whole data set.
In this example, we now have some development data up here. We can see that development costs us about thirteen hundred ninety-one dollars a month for that particular month. This particular row, this particular app and environment tag combination, so "active bolt matrix" and dev, actually didn't cost us anything that month. But there will be examples further in the data set where that's not the same. These zeros aren't particularly helpful, so let's go ahead and filter those out.
We're going to take some effective cost that's greater than zero. Now this should give us the more interesting set to explore. So now we can see we have a couple of apps here. "Prod F" has had different costs in different accounts. The total cost for this app was about thirty-eight dollars. This is where we're going to do the math. We're going to take this row's effective cost and divide it by this combination's total cost to start figuring out where things are distributed. We're going to wrap everything in another WITH statement here. We have another WITH here, and we're going to call it percentages.
So we have our first query that we wrote , and we have the second one where we've added our window functions. We filtered out these zeros, and we're also going to filter down the production. We don't need to track anything other than production costs right now. We're going to filter out usage with no app tag because we saw a couple of those, so we don't need to see ones where there's no app tag. And finally, we're going to run one final query over all of that so that we only see what we need.
We're going to select things like provider name and account name. We still need to calculate the percentage, so what we're going to do here is take our sum effective costs for the row, which is here, and divide it by the aggregate like this window function for that function, and multiply by 100 to get the percentages. We're going to select what we need out of this set, which should give us provider name, the accounts, the environment, app, the cost, and then this split. The other piece here is we only want to see places where it's not 100 percent. If Foo and Dev only runs in one place, that's not interesting, so we're going to filter out places where this app or the percentage is less than 100. This should give us that report that we were chasing.
From here, what did I miss? Oh, I have two FROM statements. I copy and pasted it wrong. OK, and what this is showing us is we have two apps here, one called Foo and one called Databricks, that run in production. They're split across both providers and accounts, and we can track down that Prod Foo runs about 2.5 percent in this AWS account and runs about 50/50, or 50/46, across these two Microsoft accounts. And then finally for Databricks, we can see a similar distribution where it's about 99 percent in this one AWS account, and then there are some more codes out there that are tagged as Prod Databricks running elsewhere.
Taking Action with FOCUS: Visualization Tools, Resources, and Next Steps
So let's sweep back to the presentation. We finally want to talk about visualization real quick. We poked around in Athena, and looking at SQL results can be nice, but it's not as pretty as some of the graphs that I'm sure a lot of folks would like to have. I want to call out again the Cloud Intelligence Dashboards. That team has done wonderful work. It is an out-of-the-box solution visualizing on top of all the data that we presented to you today. It has the consolidation view, and they have integrations documented for how to pull in data from Azure, Google Cloud, and Oracle Cloud.
Today they support FOCUS 1.0, but they have plans to add 1.2 here soon since we just recently announced it about two to three weeks ago. So keep an eye on their changelogs for what's coming soon. Jason, let's wrap things up. Yeah, thanks, Justin. Cost allocation and cost attribution is always a very hard problem to solve in cloud cost management, especially in multi-cloud or SaaS vendors. Justin gave a good demo to solve that problem with the FOCUS dataset, and that dataset is also published in our query libraries that you can grab today.
Let's recap what we have learned since the question we asked in the beginning. Have you seen the FOCUS dataset? We have seen this all together. Have you analyzed the FOCUS dataset? We have done this all together. And have you joined the FOCUS dataset? In this practice, we joined the FOCUS dataset with other providers in Athena. What's remaining is to put FOCUS into action. After this section, we very much encourage you to create a FOCUS export from the database data export platform and visualize your FOCUS data and get your hands on with FOCUS. Yeah, and getting hands-on again, hopefully.
We can make this easy. We have a whole bunch of resources here that will link you out to the code examples that we had today, the Kerr query library where you can get started either with Kerr or Focus, the cloud intelligence dashboards, a whole other library of links if you feel like diving into cost allocation strategies on AWS, and then both mine and Jason's socials if you want to connect.
Of course, reinvent is all week. There are lots of other sessions focused on FinOps practitioners like yourself, whether it's AI for FinOps, FinOps for AI, unit cost, or cost allocation strategies, multi-tenant cost allocation strategies, a whole lot going on. So check these other sessions out. Come check out the Cloud Ops kiosk. We do have a kiosk in the AWS Village in the Venetian Expo where folks like myself and Jason will be hanging out to give one-on-one demos with swag and stickers. Feel free to come and say hello.
That's it. Thanks for your time today. I hope the rest of reinvent is awesome, and Jason and I will hang out for a couple of minutes if you have questions or want to come up and talk. I think we have a couple of stickers that we'd be more than happy to share with folks. Please complete the session survey in the AWS Events app. We are a data-driven company and we love all feedback. I hope everyone has a great rest of your week here.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)