AWS re:Invent 2022 - Simplify your AWS cost estimation (COP205)

Aug 16, 2023

AWS re:Invent 2022 - Simplify your AWS cost estimation (COP205)

Take the guesswork out of planning with AWS: accurately evaluate the cost impact of your AWS workloads as you grow and save on AWS. Join this chalk talk to learn how you can plan for changes to your workload and simplify your cost estimate. Understand how modifications of your purchase commitments, resource usage, and commercial terms affect your future AWS spend.

Learn more about AWS re:Invent at https://go.aws/3ikK4dD.

Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4

ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.

AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

#reInvent2022 #AWSreInvent2022 #AWSEvents

Content

0.63 -> - Good afternoon.

3.75 -> Good to see you all.

5.1 -> My name is Bina Khimani and I am here to talk to you about

10.11 -> how you can simplify your cost estimation and forecasting.

15.33 -> I am here with Keith Jarrett.

17.7 -> He leads our go-to-market operations

20.91 -> and he will dive into details of all the tools

24.51 -> that can help you with this optimization and forecasting.

28.89 -> And we are here with our valued customer, Intuit.

32.79 -> Jason is from Intuit,

35.07 -> and Intuit has really done fantastic job

39.03 -> mastering how to plan, forecast

43.65 -> and really budget their spend and, you know,

46.65 -> optimize how they're making these investments.

49.62 -> And Jason is going to share the journey

52.59 -> on what they are doing, what tools, what business processes,

56.22 -> what cultural aspects they are working with

59.55 -> that help them get to a really good state.

63.42 -> So with that, we'll get started.

66.09 -> Thank you, Keith and Jason.

73.77 -> All right.

75.81 -> So...

79.68 -> Whether you are from finance, you are from IT,

83.13 -> you are from business development, you are from,

87.57 -> you know, building applications.

88.8 -> You're a builder, you are, you know, the budget owner

92.87 -> or the delivery manager who is worried about the cost

95.49 -> or owns the budget.

98.13 -> Regardless of your role,

99.9 -> I strongly believe that you will find this session useful

103.71 -> because we are going to talk about

106.71 -> not just how to build most optimally on AWS,

113.25 -> but really how do you think about cost governance,

118.35 -> how do you think about establishing the baseline,

123.93 -> planning your spend, and then really making sure

128.31 -> that you are comfortable letting your builders build

132.24 -> without worrying about the cost

134.19 -> because you established the right processes

137.13 -> and automated the governance

140.25 -> so that you are comfortable letting your builders build,

144.51 -> that, you know,

145.47 -> whenever they are building,

146.49 -> they're provisioning new services,

147.93 -> they're really going to not impact something

151.77 -> that gives you some kind of billing shock.

154.71 -> So that is the whole process.

157.17 -> And...

160.56 -> Whenever any of you are thinking

163.29 -> about bringing your new workloads to AWS

168.42 -> or you are thinking about building a new application on AWS,

172.59 -> or building some line of business on AWS,

177.33 -> lot of times the type of things

180.24 -> that you would think about is that,

183.097 -> "How do I really effectively plan my spend?

189.09 -> What is it going to really cost me?

192.69 -> Is it really cost-efficient for me

195.87 -> to run this certain workload on-prem or on AWS?

202.062 -> On AWS also, how do I make certain kind of commitments

207.99 -> like Savings Plan purchases or Reserved Instances

210.93 -> so that I am planning where I have maximum savings?"

218.28 -> Have you thought about,

220.837 -> "There are so much fluctuations in my business.

224.91 -> There are certain peak times

226.62 -> and there are certain off-peak times.

229.17 -> And how do I really forecast

231.45 -> so that I can purchase the right level of Savings Plan,

234.99 -> or I'm planning my budget

238.26 -> and purchasing the right level of services

240.36 -> so that there is no performance degradation

243.06 -> because of lack of resources.

244.74 -> At the same time, I'm optimizing my savings

248.67 -> and I'm planning and budgeting for the right spend."

254.94 -> Many times customers think about,

257.767 -> "I am bringing this brand new application

260.7 -> from on-prem to AWS.

264 -> What is going to be the total cost of ownership on AWS?

269.25 -> How do I build the business case

272.34 -> so that I can convince my leaders

276.18 -> that when we bring it to AWS,

278.52 -> this is how much savings we will see?"

281.4 -> Not only, how do I build the business case

285.69 -> and understand the total cost of ownership,

287.73 -> but I also think about,

291.36 -> that how do I continue to validate the business case,

295.23 -> that, you know, we started the migration,

297.72 -> now we are running two parallel environments,

299.85 -> now we are facing out this environment.

302.34 -> Are we really seeing the savings that we planned for?

307.02 -> So those are the type of questions

309.6 -> that our customers think about

311.61 -> when they think about planning and forecasting.

317.88 -> So...

321.18 -> One thing to think about, you know,

325.17 -> planning, forecasting, evaluating,

328.32 -> this is, you know, this is a continuous cycle.

333.39 -> It is not something that you do it one time

336.66 -> and you are done.

338.37 -> So think about this, that as you are bringing new workload,

344.58 -> there are two things going on.

345.99 -> One thing is that you are trying to figure out that-

350.376 -> Or you are building a new application on AWS,

352.223 -> you are thinking about what kind of services do I need?

356.317 -> "How much is it going to cost me?"

358.5 -> You are trying to understand the behavior

360.9 -> of your own applications and projects

363.42 -> and understand how different fluctuations,

367.59 -> how much workload, how many, you know,

371.43 -> EC2 instances, what kind, what type of S3 services,

374.58 -> what Lambda, these, that, what kind

376.23 -> of different services utilization do you anticipate

380.04 -> and how much it will cost you,

382.29 -> what kind of usage and what kind of discounts

384.93 -> and what kind of commitments,

386.19 -> and you're trying to figure this out.

389.04 -> At the same time, when you are forecasting this,

393.57 -> you are trying to do some kind of analysis, that

397.597 -> "What if I am, in addition to this organic growth,

401.1 -> I am also planning to build this new application?

403.35 -> How will that turn out?"

404.91 -> So as you are going through this,

407.52 -> you come up with a forecast,

410.7 -> and once through this (indistinct) process,

413.67 -> your forecast is something that you are settled on, that,

416.257 -> "Yes, this is exactly what I believe,

419.07 -> where we are likely to land with this certain margin."

422.55 -> Now that forecast becomes the budget.

425.94 -> This is the budget that you are setting for, you know,

428.64 -> specific workloads, specific environment, specific projects.

432.54 -> And now,

435.15 -> you make those purchases and now you are trying to make sure

440.49 -> that you are really following and meeting this budget

445.53 -> or not.

446.363 -> You're evaluating that we believe that this is the level of,

451.117 -> you know, usage for this particular replication environment,

455.55 -> anything,

456.48 -> and are the builders building within that budget

459.53 -> or are they breaking the budget?

462.66 -> Are there any unanticipated runaway workloads?

467.67 -> Some kind of long-running database query

470.13 -> or somebody deployed an EMR cluster

472.32 -> that nobody has put any application on, or the weekend,

476.1 -> and that's consuming your resources.

478.38 -> So there might be many unanticipated or unintended spend

483.93 -> that might cause you to break budget.

486.45 -> Or there might be, you know, builders just building

489.06 -> and you didn't, you know,

492.66 -> think about certain situations

494.34 -> that can cause you to break the budget.

496.98 -> So now the third phase is

499.08 -> that you are continuously evaluating

501.45 -> that whatever we budgeted, are we really meeting the budget?

505.347 -> Are we close to it?

506.817 -> Are we way below, way above,

508.98 -> and how are we going to plan around it?

511.32 -> So planning,

515.28 -> for whatever workloads that you need to handle on AWS,

518.46 -> and then forecasting and creating the budget

520.92 -> and then evaluating

522.03 -> that you are really meeting the budget or not.

524.34 -> These are the type

525.24 -> of business processes we are going to talk about today.

531.39 -> So where we are really headed is, first of all, you know,

535.62 -> cloud cost governance starts with baselining.

542.28 -> If you do not know, you know, what to anticipate,

546.36 -> you don't know what is the expected baseline,

549.33 -> then you don't know what budget to set.

553.02 -> You might have really good tools,

556.74 -> but you don't know where to set the threshold

559.62 -> for a specific application, project, environment.

562.2 -> You don't know,

563.28 -> what is the threshold I should be setting that,

565.357 -> you know, if it is close to 80% of that utilization,

568.98 -> then I should get the alert

570.69 -> or I should take automated action.

572.82 -> But where to set the threshold?

574.8 -> For that also you need to understand the baseline

577.83 -> of all these applications and environments.

581.16 -> Then, once you understand the baseline, you really need,

585.66 -> you know, the...

586.493 -> None of the applications you are handling are going

590.37 -> to be static.

591.93 -> They will have their own peaks and valleys,

593.7 -> they will have, you know, there will be new applications,

595.89 -> there will be new additions to environments,

597.75 -> there will be organic and inorganic growth.

600.45 -> You-

601.283 -> Some of you might be even acquiring some company

602.88 -> and bringing them over to AWS.

605.28 -> So there will be many variations.

606.96 -> So how do you really forecast the dynamic usage

611.64 -> and the changes related to that?

614.79 -> And what are the mechanisms and tools

618.33 -> that we can use for monitoring and evaluating this?

622.32 -> So those are some of the things that we'll dive into detail

626.67 -> and Intuit has put it all together

631.02 -> with help of the right business processes, tools

634.47 -> and evaluation mechanisms that we'll dive into, deep into

638.64 -> to understand how Intuit is doing all of this together.

643.77 -> So let's jump right in.

646.95 -> When we speak about planning, it's really...

653.88 -> You know,

654.713 -> thinking about how do we optimize your cloud operations.

660.06 -> Anybody who brings workload to AWS

662.43 -> or are building new workload on AWS,

665.16 -> this is the exact, you know, phase that, you know,

668.94 -> there is so much focus

670.32 -> on how do I bring it to AWS and make it work.

673.71 -> And sometimes there is lost sight

676.32 -> onto how do I really optimize my cloud operations

679.44 -> and financial operations

682.14 -> so that we can get best return on the investment.

686.82 -> You know, we can get the most value out of the cloud,

690.09 -> but as we see this, right?

692.433 -> That there is tremendous value.

693.99 -> We surveyed, you know,

695.28 -> Forrester surveyed 1500 or so customers

698.34 -> and they, you know, received the information

701.52 -> that 241% return on investment over three years.

706.08 -> That's very, very promising.

707.85 -> But this all starts with establishing the right guardrails,

711.84 -> right baseline and right mechanisms in place

716.25 -> so that you can automate this entire cloud governance.

720.84 -> It also brings 62% more productivity,

724.38 -> 57% decrease in downtime.

726.78 -> So overall the performance,

728.28 -> the productivity, the cost savings,

732.42 -> all of these are very promising.

734.34 -> But to get there, we need to have a discipline

738.57 -> in establishing the right cost guardrails.

743.7 -> Now, when we are planning for-

748.26 -> When we are planning for AWS for different type of workload,

753.57 -> the tools and processes are slightly different.

757.17 -> If you have decided to shut down a data center

759.99 -> and bring all your applications and servers to AWS,

763.47 -> it's slightly different

764.52 -> than you are building cloud native applications.

767.97 -> Now, when you are talking

770.01 -> about migrating applications or workloads,

774.39 -> there is a entire phase of data gathering.

777.18 -> You are thinking about, "What are the legacy applications

780.66 -> that I want to leave it here?"

783.06 -> And what are the applications, you know,

784.98 -> out of your entire stack of applications,

787.207 -> "What are the applications that I want to lift and shift?

791.37 -> What are the few applications that I want to modernize as I-

796.11 -> Bring it to cloud native services

798.33 -> as I am bringing it to AWS?"

800.94 -> So as you are doing this kind of planning

803.16 -> and you are kind of doing this analysis,

806.28 -> you are collecting all types of data

808.71 -> that help you get there.

810.39 -> Now you are creating not only the technical models, that,

815.557 -> "Hey, how I'm going to migrate certain applications,

818.85 -> what are the technical dependencies

821.73 -> doing the impact analysis,

823.23 -> that if I migrate this application,

824.91 -> what are the other things

826.32 -> that I have to migrate to make it work?"

828.6 -> You are going through a lot of architectural choices, that,

831.967 -> "How my landing zone is going to look like?

834.09 -> What is that blueprint for my landing zone

837.18 -> so that every time I bring the application,

839.1 -> it gets certain things by default?"

841.62 -> So you're thinking about this cloud architecture,

844.89 -> this is the exact time you should also think

847.71 -> about financial and cost and operational planning.

853.26 -> So it's really, really important to think about,

856.4 -> as you are bringing certain applications,

858.6 -> you know, you are going to deploy it,

861.69 -> maybe you're using AWS Control Tower.

863.61 -> At that time, what are the, you know,

867.18 -> what are the usage estimation you have?

871.8 -> What is the phase of migration?

874.98 -> What is the business case for migration

878.31 -> for certain applications?

880.92 -> Over what period of time you will see

883.53 -> what type of return on investment

885.45 -> when you bring these applications to AWS?

889.56 -> What is the total cost of ownership?

891.6 -> So all types of analysis.

893.4 -> And then again, thinking about,

895.13 -> as you deploy these applications

897 -> or migrate these applications to cloud,

900.18 -> are you putting the right-

904.14 -> Are you configuring AWS Budgets?

906.39 -> Are you putting the right cost guardrails in place?

909.12 -> Are you thinking about, automatically, you know,

911.91 -> configuring Cost Anomaly Detection?

913.98 -> So if there are runaway workloads,

916.17 -> then you have it automatically deployed

918.84 -> as a part of the landing zone.

920.43 -> So what are the cost control guardrails you are laying out?

924.48 -> This is the time to think about that.

926.64 -> At the same time, you know, overall,

929.85 -> you want to compare overall cost

932.223 -> that you will have for specific application or environment

936.72 -> as you bring to AWS, and you want to compare it,

939.48 -> with either you're bringing

940.65 -> from other cloud providers or on-prem,

943.17 -> how the cost is going to look like.

946.83 -> Many of you might be familiar with Migration Evaluator.

950.58 -> So when you are planning for bringing the new workload,

953.73 -> Migration Evaluator is a great place to start.

958.38 -> This is primarily focused

960.12 -> on really helping you make the decision.

965.04 -> And this is even before you, you know,

967.085 -> make certain purchases of AWS services that,

971.55 -> what is it that, you know, I want to bring over?

975.3 -> You want to discover all your applications.

977.34 -> It is very, very common

979.08 -> that many customers do not really have good inventory

982.92 -> of all their applications.

986.19 -> Many customers are still trying to figure out, you know,

989.58 -> there might be a lot of legacy code and people might have,

992.94 -> you know, moved in and out of the organization.

995.49 -> They're trying to figure out exactly, you know,

997.477 -> "If I move this, what else is gonna break?"

1000.14 -> So those kind of impact analysis.

1002.15 -> So there are just a lot of things you want to do.

1004.37 -> So you want to really discover your inventory,

1007.4 -> you want to determine the most cost-effective path

1011.6 -> to bring your workload to the cloud.

1014.6 -> You want to not only think

1016.76 -> about infrastructure spend savings

1019.67 -> that, "Hey, this is the service that if I use,

1022.61 -> or these are the applications,

1023.69 -> this is how much it will cost me and this is the best path."

1027.14 -> But also you are thinking about,

1028.707 -> "Hey, I made this purchase of Microsoft SQL licenses,

1032.87 -> or Windows licenses, or .NET licenses,

1035.54 -> and these, some of them are on-prem,

1037.13 -> some of them I can do, bring it over."

1040.19 -> Or, "Do I want license included versus BYOL,

1043.687 -> 'bring your own license'?"

1045.35 -> So those kind of analysis you are trying to do that,

1048.027 -> "Hey, how is the license cost impact for Microsoft workload

1052.31 -> when I'm making this decision

1054.14 -> to bring over certain application?"

1056 -> So again, Migration Evaluator will help you get there.

1060.08 -> So a lot of powerful tools here.

1064.01 -> It provides you the quick insight,

1065.96 -> it gives you the directional business case.

1068.33 -> This is very powerful,

1069.92 -> especially if you're trying to explain your own leadership

1074.12 -> on why certain workloads should move to AWS

1076.61 -> versus, you know,

1078.98 -> certain things you might want to leave on-prem.

1081.05 -> So it helps you build that business case,

1083.87 -> it gives you visibility

1085.61 -> into the overall total cost of ownership

1088.07 -> for running that particular application on AWS.

1093.86 -> Now,

1096.5 -> this is if you are building-

1099.11 -> If you are bringing the new workload from on-prem to AWS

1102.44 -> or other cloud to AWS.

1104.06 -> But what if you're building a brand new application on AWS?

1109.089 -> So you are trying to figure out that,

1110.517 -> "Hey, I want to build this application

1113.9 -> that's going to require X, Y, and Z services,

1117.17 -> how much it will cost me?"

1118.79 -> Different services have different units,

1121.16 -> they have different price points,

1122.9 -> and based on certain level of usage, it will,

1126.14 -> you know, cost you differently.

1128 -> So Pricing Calculator is another tool

1131 -> that supports over 150 AWS services

1134.27 -> and it has really good mechanism, like "group by feature"

1138.59 -> where you can group certain services together

1141.86 -> and see the overall cost, you can see it by region,

1144.56 -> you can slice and dice in many ways.

1148.37 -> Even if you are, you know, existing customer with almost,

1151.55 -> you know, most your applications here

1154.34 -> and you're trying to relaunch some brand new service

1157.19 -> in your, say, AWS Billing Conductor

1159.95 -> or some of these services,

1161.06 -> and you're trying to figure out that, you know,

1163.677 -> "Based on my own workload and my own consumption,

1167.12 -> if I start using this new service or set of services,

1170.51 -> how much it will cost me?"

1171.89 -> So AWS Pricing Calculator will help you plan your spend

1176.42 -> based on that.

1178.377 -> With that, we are going to jump into forecasting

1182.48 -> and this is where, you know,

1185.36 -> getting accuracy in the forecasting is the,

1187.893 -> really the essence of planning.

1190.4 -> I'm going to hand over to Keith to take it from here.

1193.22 -> Thank you.

1194.15 -> Thank you, Keith.

1198.59 -> - Okay, thank you, Bina.

1200.18 -> So we talked a little bit about

1201.44 -> how we're gonna establish our baseline cost with-

1204.32 -> Establish our plan, our business case

1206.57 -> with things like our Pricing Calculator

1208.73 -> and Migration Evaluator.

1209.99 -> I wanna quickly switch gears

1211.61 -> and talk about how we're going to better forecast

1215.75 -> in this dynamic variable cost world,

1217.52 -> because it can be a trick, right?

1220.07 -> Prediction can be hard, right?

1222.23 -> Especially if it's about the future, right?

1224.417 -> And I don't know if you guys have noticed,

1226.49 -> but there's a lot of adages or sayings out there

1229.16 -> about forecasting, all right?

1231.05 -> Like, "Forecasts are always wrong."

1233.18 -> How many people have heard that saying, all right?

1235.85 -> Grew up with that one, all right?

1237.71 -> So there's a kernel of truth with all those sayings.

1239.69 -> You know, they may be right, they may be wrong,

1241.16 -> but there's a kernel of truth, right?

1242.75 -> And while all forecasts are wrong,

1244.46 -> some forecasts are particularly useful, right?

1247.85 -> They're useful because they help us identify

1249.89 -> where the risks are to our business and to our plan, right?

1252.65 -> Where the opportunities are,

1254.39 -> maybe where we need to adjust our operations

1256.55 -> and our planning, all right?

1259.16 -> And ultimately where we may need

1260.6 -> to adjust our financial plans, our budgets.

1264.35 -> All right, so let's talk a little bit about this.

1266.12 -> But before we get into actual forecasting, all right?

1270.41 -> Is it critical that we understand, you know,

1273.14 -> where we are today, right?

1274.82 -> So building off of what Bina was talking about,

1277.04 -> it's essential for us to get a view

1278.72 -> into what our costs and usage are today.

1281.21 -> And tagging is a really critical piece to doing this well,

1285.437 -> all right?

1286.27 -> By employing a consistent tagging strategy

1288.74 -> across our business,

1289.88 -> we can get a better view into what those costs are

1293.3 -> by cost center or business unit,

1295.94 -> by application, by owner, all right?

1299.66 -> It can help us create those charge back

1301.4 -> and cost allocation reports.

1302.84 -> It's a critical piece, all right?

1304.94 -> And in addition to having that consistent tagging strategy,

1307.76 -> it really helps make sure

1309.14 -> we have a consistent account management strategy

1311.925 -> that goes along with that.

1314.87 -> All right, so AWS accounts aren't technically hierarchical,

1318.02 -> right?

1319.017 -> But customers are using AWS Organizations

1321.26 -> to create that logical grouping

1323.48 -> that can help make sense for your operations

1327.2 -> and your billing processes, right?

1329.93 -> So when we talk about those logical groupings

1333.05 -> or those organizational units or OUs, right?

1337.46 -> We see customers doing this in a way

1339.62 -> that really helps them start to make sense

1341.96 -> of their costs and usage, right?

1344.12 -> Not just mirroring how they're organized as a company,

1349.97 -> but thinking about identifying groups of individuals

1354.41 -> who should have consistent permissions, right?

1356.48 -> Or thinking about how we're gonna kind of group things

1358.82 -> in a way that maps back to our operations.

1360.59 -> So typically that means one of three things, right?

1363.56 -> One is environmental lifecycle account management structure

1366.62 -> where you're aligning your operations and your billing

1368.84 -> to be consistent

1369.673 -> with your application life cycle deployment.

1372.62 -> Two is product management or project management,

1376.37 -> account management structures where again,

1378.38 -> trying to operationalize and align your billing

1381.26 -> with either products or projects or programs.

1384.89 -> And then foundational groupings

1386.18 -> which could be things like security and compliance

1388.61 -> or shared infrastructure.

1389.99 -> But getting those things in place helps us

1392 -> when it comes time to make sure

1393.38 -> that we're not only monitoring

1395.69 -> how we're doing against our plan,

1397.52 -> but making sure that we're adhering to that plan

1399.8 -> as an organization.

1402.71 -> And when it comes to forecasting,

1404.78 -> we typically refer to two different methodologies.

1407.75 -> I'm gonna talk just briefly about that here, all right?

1410.9 -> We think about forecasting in two different ways,

1412.46 -> and oftentimes I think there's a lot of confusion

1414.2 -> around forecasting, and what we mean by forecasting,

1417.08 -> because I think sometimes we try and shove everything in

1420.47 -> to one type of methodology and it's just not fair, right?

1424.04 -> It's helpful to kind of bifurcate this and talk about

1426.44 -> which each of these individual components are.

1428.72 -> The first is trend-based

1430.82 -> and the second is driver-based forecasting.

1433.49 -> Trend-based is a good way for us

1434.99 -> to take a look at our existing workloads

1437.06 -> and what type of organic growth we can expect over time

1440.12 -> by looking at how our user base is growing

1443.93 -> and how it may impact demand

1445.4 -> for compute storage and networking resources, all right?

1450.68 -> But no matter how much we analyze that historical data

1454.16 -> or how much we deploy machine learning on that data,

1457.1 -> all right?

1457.933 -> No amount of machine learning is gonna tell us

1459.32 -> when we're gonna launch our next application, right?

1461.84 -> Or when we're planning for that next migration

1463.748 -> or when we're gonna acquire that company.

1466.25 -> And so for those types of business drivers,

1468.59 -> we need to couple that trend-based forecast

1471.23 -> with an understanding of what our company's planning to do

1474.74 -> and what type of resources they're planning to use

1476.39 -> before they actually do it.

1479.06 -> So before we talk

1479.96 -> about how we kind of marry those practices,

1483.26 -> because it is important

1484.093 -> to think about those types of methodologies

1486.05 -> as not just a need or a conversation, but an end,

1489.08 -> how we bring those two together in a unified way.

1492.86 -> But before we do that, it's important I think for us

1495.11 -> to talk a little bit of taxonomy and lexicon, right?

1498.02 -> And how we kind of refer to all the various factors

1501.11 -> and variables that are gonna impact your forecast, right?

1504.59 -> 'Cause there's a lot of idiosyncrasies

1506.27 -> that can impact your specific numbers

1507.86 -> and that's gonna be different

1508.693 -> for your company and your company, right?

1510.95 -> Everyone's gonna have a slightly different situation.

1512.72 -> So for us,

1513.8 -> we tend to bucket all those factors into four categories.

1517.49 -> The first we've talked about a little bit already,

1519.38 -> which is organic growth.

1521.21 -> Again, that's the type of growth of IT consumption

1525.98 -> that we can expect from just expanding our user base

1528.98 -> associated with our applications, right?

1531.62 -> As we continue to launch new features and new code, right?

1534.59 -> We expect our applications to continue to grow,

1537.74 -> and that's what we mean by organic growth.

1540.95 -> Second, we have what we call internal drivers.

1544.13 -> And our IT and product teams here are responsible

1547.43 -> for a lot of these drivers, right?

1550.31 -> Whether they can launch that new application, right?

1553.37 -> New environments, new migrations, all right?

1557.63 -> M&A activity.

1560.9 -> And then external drivers.

1563.99 -> External drivers could mean any sort of end user growth

1569.21 -> above and beyond what we'd expect from organic growth.

1575.03 -> So this could include sales and marketing campaigns, right?

1578.69 -> Free promotions, free trial promotions,

1581.99 -> could include seasonality and how that impacts our business.

1585.05 -> But again, is growth driven by end users above and beyond

1588.95 -> what we would expect with our organic growth.

1591.74 -> And while these first three drivers we can kind of associate

1594.68 -> with growth of our IT consumption, all right?

1599.54 -> Optimization is our opportunity

1601.88 -> to become more cost-efficient and drive our costs down

1605.15 -> even while that usage may be increasing, right?

1608.93 -> So doing things like rightsizing, using Savings Plan,

1612.71 -> platform commitments, right?

1614.78 -> Identifying idle resources, all that good stuff, right?

1617.75 -> Making sure that we're getting,

1619.13 -> stretching our dollars as far as possible

1620.84 -> even while our usage may be growing.

1625.28 -> So in practice, right?

1627.14 -> This is what we can visually expect, right?

1631.61 -> Where we start kind of stacking up these drivers

1634.19 -> on top of each other, all right?

1636.71 -> So for an example,

1637.85 -> in purple we have our trend-based forecast

1640.04 -> which shows this kind of organic growth increasing

1642.38 -> throughout the year.

1643.94 -> In yellow and red we see product-based demand drivers

1649.55 -> above and beyond that, all right?

1651.41 -> So again, in this type of environment,

1653.54 -> or this type of visualization as a product team,

1656.75 -> not only are we able to see

1658.34 -> kind of what our run rate should be

1660.47 -> for the year or month over month cost expectations,

1662.96 -> but allows us to break that down also

1665.87 -> by demand driver and by product, right?

1669.68 -> So we can start to make those adjustments,

1671.57 -> really kind of know where the sensitivity is

1672.94 -> in our forecast, all right?

1674.99 -> And either mitigate some of those risks

1676.94 -> or replant as needed.

1680.33 -> So when it comes to forecasting,

1683.3 -> it comes to trend-based forecasting, all right?

1686.884 -> AWS provides two great services here,

1688.97 -> both machine learning based.

1691.37 -> All right?

1692.203 -> The first is forecasting with Cost Explorer.

1694.76 -> So Cost Explorer is a powerful tool right out-of-the-box,

1697.49 -> accessible from the Cost Management console.

1701.27 -> And in addition to just kind of reporting

1703.28 -> and visualization capabilities,

1704.63 -> it allows us to take 12 months of historical data

1707.96 -> and project 12 months into the future

1709.97 -> with an 80% confidence interval.

1712.25 -> So that can be really helpful for business users,

1715.31 -> product owners, FinOps practitioners, all right?

1719.93 -> Operations teams,

1720.89 -> virtually like anybody within your company, all right?

1723.83 -> That can be a very helpful thing,

1725.39 -> particularly out-of-the-box.

1726.65 -> There's no setup required.

1728 -> Once you have enabled Cost Explorer,

1729.98 -> those forecasts become available.

1732.26 -> All right, a couple things to consider, however, all right?

1735.17 -> Today that forecast is limited to 12 months, all right?

1737.96 -> So if you need to forecast beyond that, we need to-

1741.746 -> You have to explore some other options, all right?

1743.99 -> Confidence interval is 80%, there's no customization there.

1750.29 -> And the other potential hang up here is,

1753.92 -> we'll provide those 80% forecast

1755.96 -> as long as there's enough data.

1757.22 -> So for-

1758.18 -> You know, one example here

1759.29 -> that kind of comes up somewhat frequently is

1760.97 -> if you have a new account

1761.803 -> that hasn't undergone a full billing cycle,

1763.85 -> that forecast won't be available,

1765.68 -> but will be available soon thereafter, all right?

1768.74 -> But again, out-of-the-box, really powerful tool.

1772.61 -> The second is AWS Forecast.

1774.71 -> AWS Forecast is a customizable,

1778.4 -> machine learning based forecast

1780.92 -> that allows you to train models

1782.72 -> and take advantage of up to a dozen different algorithms

1786.26 -> to set your forecast quickly, all right?

1790.43 -> And where we talked about with Cost Explorer,

1792.89 -> maybe something that could be applicable

1794.21 -> to really any user within your organization, all right?

1797 -> Forecast is a little bit more ideal

1798.89 -> for those data scientists or analysts,

1802.37 -> for engineers and sometimes operations teams.

1805.19 -> But it does give you a lot more customization potential,

1808.97 -> all right?

1809.803 -> You can extend your forecast beyond 12 months.

1812.72 -> One of the really compelling things here is also coupling

1815.42 -> or marrying your AWS data

1817.13 -> with other auxiliary data that you may have, all right?

1821.63 -> That could be like weather data or you know, you name it.

1824.72 -> So you could start understanding

1826.19 -> what other variables outside of your cost

1828.26 -> and users report are gonna be driving your forecast.

1832.28 -> So lots of customization and flexibility here.

1834.89 -> Some things to consider though, all right?

1837.65 -> Which is, there is a little bit more setup time required,

1840.17 -> all right?

1841.003 -> It does take some statistical

1841.85 -> or infrastructure baseline knowledge

1843.95 -> to get up and running, all right?

1845.48 -> We have to do some training of those models

1847.49 -> and potential maintenance of retraining those models.

1849.74 -> But again, can be a very powerful tool.

1852.77 -> The one other thing I'll call out with forecasts,

1856.1 -> right?

1856.933 -> Is not only getting an accurate forecast is important

1859.52 -> to our company, right?

1861.32 -> When it comes to having useful forecasts,

1863.96 -> one of the things we hear often is

1865.94 -> that forecast explainability is critical as well, right?

1870.32 -> Which is an understanding of like what those variables are

1872.603 -> that are driving the sensitivity of the model.

1875.18 -> Like understanding how things are calculated, right?

1877.76 -> And using those things to be able to adjust, all right?

1880.91 -> And with AWS Forecast, forecast explainability,

1884.96 -> we get those types of insights

1886.67 -> to kind of highlight where maybe price

1888.86 -> or weather or holiday data may be the kind of key drivers

1892.43 -> to some of that variability.

1895.31 -> Okay, so we talked a little bit

1896.51 -> about forecasting for organic growth, all right?

1901.28 -> Let's talk a little bit about nonorganic growth, all right?

1904.07 -> Those things that may be masked by

1907.64 -> when we limit ourselves just to kind of historic cost

1909.8 -> and issues data, all right?

1911.33 -> Because this type of process, right?

1915.44 -> It's just that, it's a process, right?

1917.773 -> I think when we think about forecasting, right?

1921.53 -> I wanna encourage us to think about this

1923.09 -> as not just a service-based solution, right?

1926.72 -> We gotta tackle it from an organization,

1929.21 -> from a people, process and technology perspective.

1931.58 -> And a lot of this process starts

1933.23 -> by looking at what metrics are gonna impact our business.

1936.92 -> And we've seen a lot of customers successful

1938.51 -> using a unit metric approach

1940.88 -> to start that type of non-organic growth forecast.

1945.35 -> A unit metric is any quantifiable base level item

1950.57 -> that is impactful for your business, right?

1952.73 -> This could be API calls, users or subscribers,

1957.02 -> it could be resource level, right?

1959.9 -> Number of instances you're running

1962 -> or average gigabytes or petabytes, exabytes, right?

1967.22 -> But what's important is

1968.48 -> that we look at what is most impactful to our applications

1971.87 -> or our business,

1973.13 -> and once we've identified what those units are,

1975.17 -> is understanding what those units are gonna cost us.

1978.29 -> What is the cost to deliver on average those instances

1981.89 -> or those gigabytes or support those users.

1985.43 -> All right?

1986.263 -> And once we've been able to do that,

1987.35 -> then comes the process of starting to collaboratively work

1991.07 -> across departments and teams, finance and procurement,

1995.75 -> all right?

1996.583 -> Sales and marketing, our product and engineering teams

2001.24 -> so that we're not just figuring out what the cost is,

2003.79 -> but anticipating what is coming up, right?

2007.24 -> What our pipeline looks

2008.83 -> that will affect these type of unit metrics

2011.11 -> over the course of the next month, quarter, and year.

2017.14 -> And so once we've gone through planning and forecasting,

2021.43 -> we come to our last phase of our planning cycle,

2024.04 -> which is evaluate, all right?

2025.3 -> Which is a step in the process

2027.1 -> where we kind of step back

2028.09 -> and evaluate how we've done with our forecast and our plans,

2031.84 -> where the variance is, where we need to make adjustments

2034.81 -> and build that into our next planning cycle.

2038.89 -> And at its core, there's two key components here.

2041.98 -> It's making sure

2042.813 -> that we're identifying our key metrics and indicators,

2047.62 -> and it's making sure

2048.88 -> we're using the right cost management tools,

2050.83 -> not only to monitor and track our progress,

2053.77 -> but also as Bina mentioned,

2055 -> is establishing the right guardrails to make sure

2057.013 -> that we're adhering as closely to those plans as possible.

2061 -> So, similar to our conversation with unit metrics, right?

2065.23 -> There is no end of the list of potential metrics

2068.56 -> that you can use

2069.393 -> to kind of monitor and track your performance here,

2072.7 -> all right?

2073.533 -> Again, cost per instance, cost per employee.

2075.82 -> Are we giving our employees the right access to resources

2078.28 -> to innovate for the long-term, all right?

2080.62 -> Cost per API call, cost per user.

2083.38 -> But what I want us to,

2084.247 -> and what I encourage customers oftentimes to do is,

2087.58 -> not just think about what those unit cost metrics look like,

2093.67 -> all right?

2094.57 -> It's helpful for us to think about these metrics

2096.34 -> in two different categories,

2097.84 -> those that are driving our costs

2099.61 -> and those that are driving value for our business,

2102.727 -> all right?

2103.72 -> So instead of thinking of just a cost per gig,

2107.77 -> cost per user, cost per ride, cost per host,

2111.55 -> cost per e-commerce transaction, cost per experiment,

2114.4 -> those things are gonna drive not just our cost line,

2117.07 -> but our top line as well, all right?

2119.65 -> And by doing that, when we start setting up metrics,

2122.41 -> both cost-based and value-based metrics, all right?

2125.95 -> If our-

2126.783 -> Every time our AWS bill fluctuates,

2130.09 -> we have the rationale right there

2131.65 -> to help us understand what's going on, right?

2133.147 -> And if our bill goes up,

2134.32 -> there's one of two things happening.

2135.61 -> One is that maybe we're falling down on cost efficiencies,

2139.57 -> all right?

2140.508 -> And that's a call to action for us

2141.341 -> to either review architectures

2144.01 -> or look at savings plans or rightsizing, all right?

2146.74 -> Undergoing a cost optimization exercise.

2150.13 -> The second explanation is, we're delivering more value,

2153.82 -> all right?

2154.653 -> We're adding users, we're launching new applications,

2157.807 -> all right?

2158.89 -> We're doing the things that we would hope to be doing.

2164.74 -> And by creating metrics

2165.91 -> that are both cost-based and value-based,

2168.58 -> it helps us quickly identify what's going on,

2171.22 -> where can we take action, all right?

2173.41 -> And where should we be celebrating.

2177.16 -> So I'm not gonna go too terribly deep

2179.29 -> into cost reporting tools

2180.67 -> 'cause I know there's a lot of great sessions this week

2182.23 -> that are gonna be diving deep here

2184.45 -> into cost reporting and allocation,

2187.18 -> but it is important to talk a little bit about this

2189.61 -> because it's such a critical part

2191.35 -> to our planning and forecasting process.

2194.32 -> And at a high level, you have three choices

2197.02 -> about how to implement the right tool for your business.

2200.53 -> The first is Cost Explorer.

2201.58 -> Again, we've talked a little bit about this,

2203.53 -> but powerful solution, built-in filters,

2207.13 -> visualize and track your cost

2209.02 -> on a monthly or daily level granularity.

2212.77 -> You can also enable hourly or resource level granularity,

2217.42 -> all right?

2218.253 -> Powerful tool.

2220.06 -> Second is, you can build your own dashboard, all right?

2222.88 -> Customers are using services

2224.11 -> like Customer Intelligence Dashboard,

2226 -> which is a templated dashboard built

2228.97 -> on top of AWS QuickSight,

2230.89 -> which allows more customization of those dashboards,

2235.09 -> custom metrics, again, similar to Forecast,

2237.88 -> you can marry AWS data with auxiliary data

2241.24 -> for kind of enhanced reporting and metric tracking.

2245.74 -> And then third is our partner network.

2247.33 -> We got a great cloud management tools partner competency

2252.79 -> which highlights a lot of great leading partners

2255.31 -> in this space that have been really successful

2256.84 -> helping customers manage their cost reporting needs.

2262.42 -> Okay.

2264.13 -> So now we've got our reporting tools selected, all right?

2267.46 -> We've got our plan in place,

2269.17 -> we've got our forecast in place, right?

2272.95 -> In addition just to monitoring how we're doing, it's-

2275.83 -> Again, it's critical for us to make sure

2278.5 -> how we as an organization are adhering to those plans,

2283.12 -> right?

2283.953 -> And one way to set that guardrail is AWS Budgets, all right?

2288.73 -> So I set my plan, I set my forecast,

2291.25 -> I take those numbers and I go to Budgets

2294.07 -> and I create a budget for that, all right?

2296.8 -> And AWS Budgets will allow us

2299.08 -> to send alerts to stakeholders across our organization

2302.53 -> when we're expected to exceed our threshold

2306.28 -> or when we actually do exceed that threshold,

2309.13 -> all right?

2309.963 -> And with budget actions,

2310.84 -> customers can configure specific actions

2313.3 -> so that when we do hit those thresholds,

2315.37 -> we have a mechanism in place to respond accordingly,

2319.42 -> all right?

2320.253 -> So with budget actions, it will take one of three actions,

2322.84 -> either on an automatic or a manual workflow approval basis,

2326.827 -> all right?

2328.148 -> The first is IAM actions where it takes an individual user

2331.18 -> and changes our permissions from "Admin" to "Read only",

2333.7 -> all right?

2334.533 -> Basically a way to say,

2335.439 -> "Hey, Keith, you know,

2336.272 -> you've already reached your budget for the month.

2337.72 -> Before we allow you to spend up additional resources,

2340.27 -> we just kind of wanna dig in

2341.83 -> and make sure this is still a good use case, right?

2344.08 -> Make sure that we know what's going on."

2346.36 -> The second is service control policies

2348.7 -> where we can do that type of control

2351.49 -> at the organizational unit level, all right?

2353.77 -> Again, so imagine a scenario

2355.51 -> where like our developer sandbox

2357.16 -> has collectively reached their budget for the month,

2359.38 -> be a way for us to control that spend.

2362.35 -> And then the third action that Budgets can take is

2365.47 -> to actually stop easy two or RDS instances, all right?

2369.31 -> Again, these can be done automatically

2371.2 -> or they can be done on a manual approval basis, right?

2373.57 -> So I definitely encourage folks

2375.07 -> to start small with this and experiment,

2377.26 -> start with a manual approach,

2378.34 -> but it can be a very powerful way

2380.5 -> to start establishing those automated mechanisms

2384.34 -> as a company to make sure we're staying on track

2387.04 -> as much as possible.

2390.25 -> So with Budgets,

2391.083 -> we just talked about how do we define a threshold

2393.76 -> where we want to be notified,

2395.77 -> we want our stakeholders to be notified, all right?

2399.61 -> But what happens when we have a spending surprise

2402.13 -> that's occurring below that threshold, all right?

2406.54 -> Still unexpected and unanticipated, unplanned for.

2410.26 -> Is that okay?

2411.25 -> It doesn't maybe break our budget, okay?

2414.79 -> The answer is, it kind of depends, right?

2416.47 -> We don't really know, all right?

2418.51 -> And we don't really know

2419.5 -> because it may be different for specific use cases

2422.56 -> or applications or companies, all right?

2424.27 -> We kind of gotta dig into it.

2425.44 -> But really that's the idea behind Cost Anomaly Detection.

2429.7 -> Cost Anomaly Detection

2430.72 -> will provide a contextualized alert

2433.09 -> based on your historical cost and usage patterns to say,

2436.277 -> "This looks kind of funny, you know, let's...

2439.12 -> You know, maybe time to go investigate it."

2441.7 -> All right?

2442.533 -> And what's helpful with Cost Anomaly Detection is,

2443.366 -> it'll provide those types of proactive alerts,

2446.95 -> but it'll also provide some root cause analysis

2448.96 -> for us to kind of figure out

2450.46 -> where we should start looking in our investigation, right?

2453.16 -> Where we should start our search.

2456.49 -> So again, two powerful tools that help us start tracking

2461.2 -> how we're going to keep our actuals

2463.45 -> as close to forecast as possible.

2467.32 -> All right?

2468.153 -> Because when we start seeing those two numbers diverge,

2470.23 -> right?

2471.063 -> Our forecasts and our actuals, right?

2473.5 -> Like we start-

2475.69 -> We need to start thinking about how we're gonna handle that.

2478.39 -> Again,

2479.89 -> one of the themes here is, this isn't just a service issue,

2482.47 -> this is an organizational challenge, a process challenge,

2485.26 -> right?

2486.093 -> So we need to start defining

2487.09 -> what that operational plan looks like, all right?

2491.56 -> When, you know,

2492.46 -> and I guess one place for us to start here,

2494.68 -> which is really helpful is,

2495.91 -> getting a steering committee together, all right?

2497.86 -> Monthly, quarterly, but helping us define

2499.81 -> what that standard operating procedure looks like

2502.15 -> and helping us review what the model should look like,

2506.53 -> where a forecast should be on a recurring basis.

2509.59 -> So again, that's finance, that's sale,

2512.47 -> it's marketing, it's product, it's engineering, right?

2514.69 -> Finance owns budget allocation,

2516.94 -> sales has their inputs and their account plans.

2519.58 -> We have marketing that owns their growth plans,

2522.46 -> product has their roadmaps, and they own the budget-

2525.67 -> Or the forecast accuracy, all right?

2530.2 -> And kind of going through this process,

2532.78 -> you start not just identifying,

2534.827 -> "Okay, what's our expectation for the future?"

2537.04 -> But how are we gonna respond

2539.14 -> when we start seeing these types of variations?

2542.47 -> And it's important

2543.43 -> that this isn't a finger-pointing exercise, right?

2547.15 -> This is a blameless exercise

2548.98 -> where we share a goal of getting our forecast

2551.17 -> as accurate as possible, all right?

2553.24 -> We're starting to identify,

2554.387 -> "Okay, when there's a variance, how are we gonna react?"

2556.57 -> All right?

2557.403 -> Who conducts the root cause analysis, who gets informed?

2560.56 -> All right?

2561.393 -> What's the SLA on that?

2562.96 -> How do I identify when we need to act

2565.39 -> or when we need to proactively solve issues

2568.42 -> from recurring in the future, all right?

2571.982 -> And so again, as an organization,

2574.06 -> once we start getting some of these practices,

2576.43 -> it's helpful for us to start small, learn, test,

2579.7 -> start with one product, one application, one team,

2582.91 -> all right?

2583.743 -> Test, experiment, learn, adjust,

2585.31 -> and then start including additional teams.

2587.95 -> Additional teams, all right?

2589.9 -> So with that, I wanna bring up Jason Rhoades from Intuit

2593.08 -> who's gonna talk to us

2594.1 -> about their experience in planning a forecast

2595.867 -> and the success that they've had

2598.09 -> in implementing their own processes.

2599.74 -> Jason?

2601.224 -> - All right.

2602.23 -> Thanks, Keith.

2603.693 -> Hey, everybody.

2606.88 -> I'm Jason Rhoades, I'm with Intuit.

2609.22 -> Hopefully most of you guys have heard of us.

2610.66 -> If not, hopefully heard of TurboTax, Credit Karma,

2613.63 -> QuickBooks, Mailchimp.

2615.76 -> These are products that help individuals

2617.77 -> and small businesses stay on top of their finances.

2621.613 -> Intuit's got about 15,000 employees.

2624.79 -> We did about 10 billion in revenue last year

2627.04 -> and we got about a hundred million customers

2628.48 -> around the world, to sort of give you a sense of our scale.

2632.62 -> And for the last several years, it's been my pleasure to,

2636.04 -> you know, lead the FinOps function there,

2637.9 -> at least the development arm of it.

2641.29 -> So just to take you

2642.16 -> through our cloud journey real quick here.

2643.72 -> We started our FinOps program about seven years ago.

2646.18 -> We actually had started migrating a little bit before that.

2650.65 -> We were in our own data centers prior to moving to AWS.

2654.19 -> And we actually started our program

2656.74 -> really just after re:Invent 2015.

2658.78 -> And shout out to LV Lee, who I think is back there,

2661.51 -> who was really the one who got us started.

2663.55 -> But so the first four years of our program was,

2667 -> we were forecasting for joint cloud

2669.31 -> and data center operations.

2671.5 -> So we fully allocated all of our data center costs.

2675.19 -> And so as our cloud started to grow our forecasting,

2678.79 -> meant including both the data center

2681.58 -> and the cloud components.

2685.21 -> But with the migration completed there in early 2020,

2688.75 -> we've been pure cloud for the past three or so years.

2691.9 -> And, you know, in that time we've gotten,

2693.88 -> we think pretty good at it.

2695.47 -> Our accuracy to forecast is generally within 3%,

2699.25 -> which I hear is a pretty good number.

2701.41 -> So I'll take you through a little bit how we do that.

2705.94 -> First thing real quick, one of the lessons

2707.62 -> that we learned through the migration was dealing

2710.95 -> with what we call the double bubble.

2712.99 -> The phenomenon here is

2713.92 -> that you can't really move your service

2716.02 -> or your application to the cloud

2717.34 -> until you've built up that infrastructure,

2719.29 -> but you also can't decommission whatever's serving it now,

2722.47 -> whether that's in the data center or another cloud

2724.9 -> until you have something to move to.

2726.16 -> So there's going to be a period of time

2728.11 -> where you're dealing with both sort of the old footprint

2730.9 -> and the new footprint simultaneously.

2733.03 -> And this is something that, again,

2734.77 -> about after four years of doing it,

2736 -> we got pretty good at handling.

2737.8 -> But for somebody, you know,

2739.06 -> who's maybe just starting their migration,

2740.65 -> starting their journey, this is something to be aware of.

2743.32 -> And there's things you can do to try to, you know,

2745.57 -> keep your compute scale as low as possible

2748.45 -> until you're really sort of flipped over to AWS.

2754.3 -> But this is something to look out for,

2755.47 -> and hopefully, you know, ideally,

2756.82 -> your cloud footprint is less expensive than your-

2759.97 -> Where you came from before and you start seeing the ROI

2763.93 -> before that migration completes.

2770.23 -> Oh, I clicked the wrong button, sorry.

2773.56 -> Okay, so this is just to get you started

2775.18 -> on how we do the forecasting.

2776.35 -> This is just a really simple sort of calendar

2778.66 -> that we adhere to.

2779.59 -> And I think this is helpful because it helps get everybody

2782.26 -> who's participating in the forecasting cycle in a rhythm.

2786.1 -> So everybody knows sort of what their due date is,

2788.89 -> when the cycles begin and end and things like that.

2790.84 -> And so for us it's based around our fiscal year,

2793.96 -> but your business may be a little bit different.

2795.49 -> You may have, you know,

2797.08 -> product release cycles that you sort of know in advance

2799.66 -> or other events that, you know,

2802.09 -> would influence the schedule that you would use to sort of,

2805.87 -> you know, have available forecasting windows

2808.36 -> when they have to be sort of locked in

2809.812 -> and secured for the coming period.

2814.12 -> But this is the one we go by.

2817.57 -> And there's one sort of like core principle

2819.94 -> that I can try to communicate to you

2821.74 -> that helps us be successful

2823.96 -> in achieving that really good adherence to our forecast.

2826.69 -> It's in the sort of distributed accountability

2829.84 -> and making sure that the right people

2831.85 -> or forecasting for the right segments of your cloud.

2834.73 -> And so it's sort of in this image here, there's our cloud,

2837.67 -> you know, sliced up into different colors,

2840.01 -> but the idea is like,

2841.69 -> the entirety of the cloud should be directly accountable to,

2845.387 -> you know, one of the groups inside your organization.

2847.78 -> There shouldn't be any leftover bucket of dollars

2850.15 -> that nobody knows, you know, who was responsible for that.

2854.59 -> And everything within that bucket, you know,

2856.48 -> should be clear and understood, and the parties

2859.21 -> that are sort of driving the cost should be the ones

2861.16 -> that are paying for it.

2862.96 -> And Intuit, we are companies divided

2865.09 -> into dozens of business segments

2866.92 -> and within each of those segments,

2868.15 -> there's dozens of development teams.

2869.68 -> So we have several hundred development teams, you know,

2872.62 -> well more than half of our 15,000 employees or engineers

2875.44 -> that are, you know,

2876.273 -> building and spending money in AWS every day.

2880.27 -> But generally, a single development team

2882.7 -> or group will only own one to four, what we call,

2885.49 -> you know, forecast units.

2886.54 -> You may use the term "application"

2889.33 -> or "service" or "product".

2890.62 -> There's all sorts of different terms

2891.88 -> that different companies use

2892.99 -> to describe sort of a purpose-bound collection

2896.65 -> of cloud resources.

2897.61 -> So, you know, application works.

2900.88 -> We invented a thing we call cloud budget,

2903.01 -> but generally most development teams aren't responsible

2907.27 -> for more than one to four of these things.

2908.68 -> And that's a pretty manageable number of things

2911.38 -> for them to keep track of and to have to worry about,

2914.47 -> you know, come forecast time.

2919.12 -> One of the things that we've sort of iterated on

2921.61 -> and learned a fair bit about

2923.17 -> as we establish these forecast units is,

2925.72 -> sort of the Goldilocks granularity approach.

2928.42 -> So there's pros and cons to slicing your cloud

2932.68 -> at sort of different levels of granularity.

2934.093 -> So, you know, if you go with a very fine grain approach,

2938.23 -> you have a really high level of traceability.

2939.82 -> If something's under or over,

2940.81 -> you're gonna know exactly where,

2942.37 -> why and where that came from,

2943.99 -> the development team responsible.

2946.21 -> But with that, there's a cost of, you know,

2949.27 -> effort in maintaining

2950.86 -> what would then be a large number of forecasts,

2953.56 -> and there's less flexibility there.

2955.06 -> If something is running a little hot,

2956.74 -> something else is running a little cold,

2958.57 -> there's no sort of fungibility

2960.01 -> to sort of average those things together

2962.14 -> if you're forecasting it to finer grain.

2964.75 -> If you're-

2965.583 -> You'll know you're forecasting it to coarser grain

2966.91 -> if you've got consistent, you know, overages or underages,

2970.87 -> which, you know...

2972.46 -> Where I come from, being under is good,

2973.84 -> but the finance folks prefer accuracy over being under.

2978.91 -> But if you can't tell where that came from,

2980.71 -> that's a indication that you probably are forecasting

2983.5 -> and reconciling at too coarse of a grain.

2985.6 -> So that would be an indication,

2986.567 -> "Hey, maybe we need to slice things a little finer

2989.65 -> so we can understand next time this happens, you know,

2992.38 -> what the root cause of it was and where we need to go to."

2997.12 -> A lot of the work that myself and my team does

3000.51 -> to enable this forecast accuracy is,

3003.42 -> it's really about the preparation.

3004.86 -> So back to, you know,

3006.18 -> everybody understanding sort of what their slice

3009.24 -> of the cloud looks like and what they're responsible for.

3013.53 -> It's an increasing amount of work

3015.3 -> in this sort of increasingly multi-tenant

3017.31 -> and shared technology world that we have today.

3020.04 -> So anybody who's using Kubernetes or Splunk or-

3025.234 -> That's the icon for Connect,

3027.39 -> Intuit happens to be sort of a marquee customer

3030.51 -> of the Connect and related call center services.

3034.17 -> These are technologies

3035.16 -> that sort of natively are black boxes where you may have,

3039.045 -> you know,

3039.878 -> 10 or 20 or 30 different parties using them at once.

3042.24 -> But in your cost and usage data,

3043.98 -> you're not gonna understand, you know,

3045.69 -> which party is responsible for what fraction of that spend.

3048.63 -> So a lot of the work that we do goes into,

3052.05 -> sort of, you know, understanding the nature

3054.45 -> and the mechanics of these systems,

3055.83 -> establishing feeds of additional telemetry data

3059.16 -> that we can use so that all the different parties

3062.25 -> that are using and consuming these shared technologies,

3065.46 -> each end up paying the appropriate,

3067.267 -> you know, share of that technology.

3069.87 -> So as their consumption of it increases,

3073.5 -> their cost increases, well.

3076.89 -> And so, you know, if you guys saw the number of variables

3081.81 -> that Keith was showing around,

3083.64 -> all the things that people have to consider, you know, it's-

3088.74 -> These development managers I think are the ones

3090.87 -> that probably naturally have the most

3094.56 -> of those sort of in mind.

3096.3 -> There's things like the optimization drivers

3098.13 -> they may not be aware of,

3099.03 -> especially if you're handling things

3100.59 -> like ROIs and Savings Plans at the center.

3102.93 -> So with giving them this good insight

3107.1 -> and helping inform them

3108.68 -> of things like the optimization drivers,

3110.79 -> it gives them a vital chance to get those things right.

3116.138 -> The other thing too around managing the changes,

3120.06 -> like we were talking about just before there is...

3124.5 -> You know, there's that forecasting cycle that's established

3127.35 -> and one of the-

3128.183 -> Like something we're doing constantly is implementing new,

3131.04 -> you know, chargebacks or allocations, rules changes,

3133.35 -> so that every group is paying, you know,

3135.21 -> the appropriate share of these different technologies.

3138 -> And that has to be done in concert with the forecast cycle.

3140.58 -> You can't just sort of change the way

3142.47 -> that you're distributing cost in the middle of a cycle

3145.71 -> when everybody's budgets have already been established.

3147.69 -> So, you know, combining the work that we do with the cycle.

3152.37 -> This is like sort of a typical cycle

3154.68 -> that would go through if somebody says,

3155.797 -> "Hey, there's this thing that's grown

3157.86 -> and it's shared and it's sort of material enough in cost

3161.85 -> now that we really ought to be allocating

3163.35 -> and distributing this cost differently."

3165.51 -> So, you know, we'll look at it,

3167.49 -> we'll make sure that it sort of meets all the criteria

3169.89 -> for a good chargeback, a good allocation, and if it does,

3173.73 -> then we'll go to work developing that chargeback.

3176.4 -> And if it's something simple

3177.3 -> that maybe just takes a sprint or two,

3179.31 -> if it's something big like our call center,

3181.05 -> that actually, I think, took us a couple months to get done.

3183.69 -> But the point is that, before that change to the way

3187.41 -> that we handle these shared costs can go into effect,

3190.77 -> we have to know and understand and have communicated

3193.5 -> what that's going to do to everybody's forecast.

3195.72 -> So there may be one group, the one who is,

3197.79 -> who's been paying that shared cost to date,

3200.1 -> whose costs are gonna go down, right?

3202.14 -> Because they're not really the ones using it,

3204.3 -> but the other groups

3205.133 -> who've been consuming that shared service all this time,

3207.72 -> their costs are gonna go up.

3209.19 -> And so there's sort of a net zero

3210.81 -> or zero sum kind of budget transfer that occurs

3214.32 -> so that the teams, again, that have been paying for it,

3217.68 -> their budget's gonna go down

3218.7 -> 'cause their costs are gonna go down.

3220.17 -> And then all of the groups that have been consuming it,

3223.02 -> their budget's going to go up

3224.97 -> to cover their future consumption of that shared service.

3228.09 -> So this is something that, again, that has to be done,

3230.22 -> this development work

3231.06 -> to make that allocation change has to be done

3233.25 -> in concert with the actual forecast process

3237.18 -> so that everybody's, you know, has the data that they need

3240.27 -> to construct that future forecast.

3244.26 -> Last thing here for me is around steerability.

3246.75 -> So, you know, a lot of achieving good forecast accuracy

3250.86 -> isn't really just the forecasting process.

3254.31 -> I think about it like, you know,

3255.42 -> if you're swinging a golf club,

3256.8 -> sort of like the fate of your shots, accuracy is sealed,

3259.83 -> you know, once it leaves the club face.

3261.39 -> But with forecasting, your fate isn't necessarily sealed,

3265.98 -> you know, once your forecast is locked in.

3267.96 -> The teams that are actually

3269.37 -> at the wheel of your cloud have steerability.

3272.4 -> So if things are starting to veer off,

3275.37 -> whether it's too hot or too cold,

3276.93 -> it's important to provide them

3278.19 -> with the insights and capabilities

3280.23 -> that they're gonna need to steer things back on course,

3282.84 -> right?

3283.673 -> Which you can't do with your golf ball.

3284.506 -> So a lot of the technologies that Keith talked about,

3287.67 -> like Budgets and Anomaly Detection are really key

3290.7 -> in helping make that happen.

3292.65 -> In Intuit,

3293.483 -> we've developed a suite of capabilities we call Cloud360,

3295.8 -> that are sort of aware

3297 -> of all of our custom business rules and logic,

3299.25 -> but they do a lot of the same things,

3300.84 -> so that as soon as a team is starting to veer off course,

3304.59 -> if they're in jeopardy, if not,

3306.03 -> adhering to the budget that they'd established,

3308.91 -> we let them know so that they can steer back on track.

3314.25 -> All right, and with that,

3315.54 -> I'm gonna head it back to Keith to wrap up.

3317.546 -> (applause)

3321.037 -> (indistinct)

3325.775 -> - All right, so we're coming up on time here.

3327.27 -> I know I'm standing between you guys and happy hour

3328.98 -> which is a dangerous place to be.

3330.18 -> So I don't wanna up here any longer

3331.71 -> than you guys want me to be up here.

3332.85 -> But there are a couple quick things

3334.11 -> I wanna touch on before we wrap up.

3337.5 -> And I think, for us,

3339.06 -> one of the things I wanna touch on real quick is,

3341.64 -> a forecast without a plan does not a forecast make, right?

3344.97 -> Consider it kinda where you are in your journey

3346.77 -> and as you establish that plan,

3348.66 -> think about some of the resources that are available

3350.49 -> to help make that business plan and set your baseline

3353.22 -> before jumping into some of the forecasting, all right?

3356.22 -> Consider your forecast

3357.66 -> not just a service or technology solution,

3360.36 -> but as Jason was talking about,

3362.16 -> how you're gonna involve all the right people

3363.87 -> within your organization and design a rhythm of business

3366.84 -> that's gonna work on a continuous basis for reevaluating.

3370.98 -> And again, a lot of great service here that can help,

3374.01 -> Cost Explorer, Budgets, Anomaly Detection,

3377.28 -> help get you started.

3378.33 -> Got a couple QR codes up here for some great resources.

3381.87 -> I'll leave us up here for a second,

3383.13 -> but there's a couple in particular

3384.87 -> that I think can be really helpful.

3386.1 -> We have a bunch of AWS Cloud Financial Management resources

3389.61 -> and a resource guide, first two.

3392.52 -> And then the third is our Cloud Financial Management blog

3395.58 -> which is a really helpful way

3397.38 -> to stay up to date with best practices and sharing,

3402.6 -> customer stories as well as launch information.

3406.32 -> So it's a good thing to benchmark or put your bookmark in.

3411.6 -> And then lastly, there's a lot of great sessions this week

3415.05 -> in the cloud financial management,

3417.03 -> cloud financial management domain,

3418.77 -> I could say that.

3421.32 -> So we have a lot of hands on exercises

3423.78 -> for those that really wanna kind of roll up your sleeve

3425.85 -> and get a little bit deeper.

3427.77 -> We got chalk talks to kind of be interactive

3430.62 -> and talk through some strategies,

3432.75 -> and we have more breakout sessions on the way.

3436.23 -> So lots of great content.

3437.46 -> Feel free to take a picture and save it.

3439.53 -> Otherwise, thank you all for being here today.

3442.29 -> I look forward to talking more.

3444.3 -> We'll be out in the hall for a few minutes

3445.53 -> if you guys do have additional questions

3447.12 -> that we can help answer for you.

3448.593 -> With that, thanks so much.

3450.511 -> (applause)

Source: https://www.youtube.com/watch?v=lGWyBdKeplQ