AWS re:Invent 2021 - Optimizing resource efficiency with AWS Compute Optimizer
AWS re:Invent 2021 - Optimizing resource efficiency with AWS Compute Optimizer
Over-provisioning resources can lead to unnecessary infrastructure costs, and under-provisioning resources can lead to poor application performance. In this session, learn how to use AWS Compute Optimizer to improve resource efficiency from a cost and performance standpoint across your Amazon EC2 instances, Auto Scaling groups, Amazon EBS volumes, and AWS Lambda functions. Also, learn how to identify and address the biggest cost reduction and performance bottleneck alleviation opportunities across your resources, empowering your engineering teams to spend less time optimizing existing usage and more time on feature development and operational improvements.
Learn more about re:Invent 2021 at https://bit.ly/3IvOLtK
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.
#AWS #AmazonWebServices #CloudComputing
Content
0.87 -> Hi, everyone.
1.703 -> Welcome to the Optimizing resource efficiency session.
4.78 -> I'm Marianna Tishchenko
5.97 -> and I'm a Senior Technical Product Manager
8.36 -> working out of our New York City office
10.23 -> and on Compute Optimizer.
13.571 -> I'm Letian Feng,
14.404 -> I'm the Principal Product Manager
16.161 -> working on Compute Optimizer.
18.04 -> This is actually my first re:Invent
19.64 -> and I'm really excited to be here.
20.78 -> Is this anybody else's first re:Invent?
22.74 -> Show of hands.
23.98 -> Okay, so quite a few new faces.
25.9 -> So welcome and welcome back
27.51 -> to those who've been here before.
29.13 -> I'm excited to walk you through what resource efficiency is,
32.71 -> how to optimize it and how Compute Optimizer
35.09 -> can help you do this across your workloads.
41.46 -> So here's a sneak peek into our agenda.
43.69 -> We'll start at a high level talking about
45.81 -> what resource efficiency is,
47.33 -> what rightsizing is,
48.87 -> and then we'll dive into Compute Optimizer,
51.43 -> including how it works,
53.19 -> and some new features that we launched,
55.64 -> one of which came out in August
57.35 -> and two of which we actually launched
58.75 -> just this week at re:Invent.
64.36 -> So let's talk about what resource optimization
66.61 -> is to level set.
68.32 -> So resource optimization involves
70.74 -> ensuring that your resources have the right configuration
73.71 -> based on your goals and best practices.
76.33 -> And there are two main types of resource level optimization,
80.19 -> each of which is important and contributes
82.14 -> to overall resource efficiency.
84.05 -> So the right resource configuration
86.06 -> will optimize for cost and performance.
92.12 -> So when I talk about cost, what do I mean?
94.28 -> I mean maximizing the value you derive from your spend
97.59 -> or minimizing the costs that you incur
100.29 -> to achieve your performance goals.
103.1 -> When I talk about performance optimization,
104.91 -> what I mean is ensuring that your workloads
107.26 -> aren't bottle-necked or at risk of being bottlenecks
109.75 -> so that your end users can have a good experience.
113.25 -> Compute Optimizer supports the first two
114.999 -> with resource right-sizing recommendations
117.93 -> and in the following slides,
119.02 -> we'll talk about how that is.
124.93 -> So let's talk about what rightsizing is first.
130.61 -> You can achieve resource efficiency
132.51 -> across both cost and performance through right-sizing
136.13 -> and we'll dive into what rightsizing is
138.31 -> and then that will tee up our conversation
140.23 -> about how Compute Optimizer can help you maximize cost
144.4 -> and performance efficiency through rightsizing.
150.72 -> So rightsizing is the process by which you configure
154.01 -> or reconfigure resources
155.95 -> to maximize savings while meeting performance requirements.
159.77 -> This means that rightsizing needs to consider
163 -> not only your current spend, the cost of your resources,
165.75 -> but also your workload needs historically
168.18 -> and in the future.
170.24 -> This is an important process for any organization,
172.56 -> especially growing organizations.
174.47 -> It can help you run your workloads more efficiently
177.23 -> so that you can scale faster.
183.71 -> And I won't downplay the fact that rightsizing
186.29 -> can be challenging.
188.3 -> Can you think of any workloads that may have had cost
191.7 -> or performance improvement opportunities
193.38 -> that you didn't take advantage of and why that might be?
198.021 -> Only a few reasons that I've heard.
200.58 -> Number one, it can take time to evaluate the resources
204.19 -> within a workload
205.06 -> and determine whether there is an opportunity
206.95 -> to reduce waste, recoup costs,
210.5 -> or if there's a potential resource bottleneck that's there.
214.29 -> Number two, AWS offers a vast library
217.29 -> of product, services, and features
219.94 -> and it may not be easy to,
222.69 -> without some significant expertise,
226.03 -> determine what is the right resource
227.73 -> to use for particular use case or workload.
231.62 -> Third, it can be difficult to understand
234.47 -> the estimated impact of a right sizing configuration change.
238.83 -> So it could be that you might recoup a lot of costs
243.21 -> and have a significant performance improvement opportunity
246.25 -> through a right-sizing activity
248.3 -> or it could be minimal
249.83 -> and maybe not worth the engineering bandwidth.
256.89 -> So this is where Compute Optimizer comes in.
259.88 -> So Compute Optimizer is
261.49 -> a right-sizing recommendation service,
263.95 -> and it delivers recommendations
265.6 -> across four resource types today.
267.69 -> So that's CC2 instances, auto scaling groups,
271.14 -> Lambda functions, and EBS volumes.
274.09 -> It analyzes the configuration of your current resources
277.54 -> as well as the utilization metrics
279.82 -> and generates recommendations
281.28 -> for more optimal configurations,
283.33 -> considering both cost and performance.
286.44 -> By default, the service is free,
288.13 -> and it analyzes the last 14 days of your CloudWatch metrics.
292.25 -> When you opt in to Compute Optimizer,
294.69 -> the service starts to evaluate your CloudWatch metrics
297.67 -> over the past 14 days,
299.43 -> and evaluate whether the resources are under provisioned,
302.77 -> over-provisioned, or optimized.
306.06 -> And depending on the findings,
307.67 -> specifically if it's over-provisioned or under provisioned,
310.72 -> Compute Optimizer will generate recommendations
313.59 -> at a resource level that tell you
315.65 -> what is a better option for that resource
318.43 -> from a cost and performance standpoint.
321.26 -> And then we take you to the console
324.35 -> where you can actually implement the change.
326.06 -> For example, the EC2 console.
331.8 -> So you might wonder why Compute Optimizer
334.134 -> is the right choice,
334.99 -> and we'll talk in more detail in the following section
338.06 -> about how Compute Optimizer works and give some examples,
340.89 -> but at a high level,
342.18 -> customers should use Compute Optimizer
344.83 -> to eliminate the challenges that I mentioned
347.12 -> associated with right-sizing.
349.34 -> It reduces the undifferentiated heavy lifting
351.88 -> that you need to do to maximize
353.26 -> your cost and performance efficiency.
359.36 -> So before handing it over to Letian to talk about
362.48 -> how Compute Optimizer works and give some examples,
364.94 -> I'll just highlight the benefits to keep in mind.
367.37 -> So, number one,
368.3 -> smart recommendations based on insights
370.66 -> generated by NL powered recommendation generation engine.
374.81 -> Two, continuous metrics analysis
377.49 -> and optimization recommendations.
379.22 -> So we refresh recommendations often,
381.59 -> so that you're able to have
382.58 -> up-to-date configuration recommendations.
386.06 -> Third, engineering time and bandwidth savings.
389.08 -> So engineers can spend less time
390.59 -> finding resource optimizations,
392.6 -> and more time on their core competencies,
394.47 -> like operational improvements and feature work.
398.64 -> Forth, reduce cognitive load and choosing
401.05 -> among a large library of resources.
403.59 -> Compute Optimizer does it for you,
405.07 -> so you can focus on the core competencies that I referenced.
408.78 -> And finally, central Cloud managers
410.95 -> can spend less time mining for savings opportunities
413.72 -> across an organization.
418.41 -> And with that, I'll hand it over to Letian.
422.35 -> Alright, thank you very much, Marianna.
424.72 -> So I'd like to talk a little bit
427.56 -> about how Computer Optimizer works.
429.22 -> So I'm going to talk about some high level concepts
432.537 -> and then I will actually do a demo
434.48 -> to show you recommendations in action.
437.07 -> So at a high level,
438.57 -> Compute Optimizer generates recommendations in three steps.
441.94 -> So first of all,
442.8 -> it analyzes whether your resource
445.79 -> meets the performance requirements of your workloads,
449.18 -> and by performance requirements,
451.26 -> I really mean that Compute Optimizer detects
453.93 -> whether your current resource is being throttled
456.97 -> on various limits, like CPU limits, memory limits,
460.39 -> network limits.
461.7 -> And if it's been throttled, then Compute Optimizer
464.693 -> will say your resource is under provision.
465.82 -> It will look for some bigger instances of our workload.
470.88 -> For other instances that the resources
473.53 -> are not being throttled,
475.02 -> then Compute Optimizer will actually look for
477.57 -> alternative resources that are actually smaller
480.31 -> than the current one.
481.78 -> And find out that if there is a smaller,
484.01 -> viable options that can also meet
486.1 -> the performance requirements of the workload.
488.14 -> And if so,
488.973 -> then it means that you have a cheaper option available
491.81 -> than your resources over provision.
493.73 -> Otherwise then if you're already using
495.74 -> the smallest options available,
498.44 -> then your resource is optimized.
500.69 -> So after doing all these kinds of analysis,
503.84 -> Compute Optimizer forms an opinion
506.05 -> about resource and tells you what the recommendation is.
509.07 -> Then together with the recommendation,
511.45 -> it gives you a couple of other additional informations.
514.93 -> Things like estimated monthly savings,
517.33 -> price difference, and projected utilization metrics
520.4 -> so that you can analyze these important formations
525.32 -> alongside which instances you should be using.
527.75 -> And these recommendations are refreshed daily.
533.81 -> So on one side,
535.42 -> having recommendations is very important
538.2 -> because that's the reason why you use Computer Optimizer,
540.86 -> but on the other side,
542.67 -> being able to easily access recommendation
544.87 -> is also equally important.
546.92 -> So let's talk about how you can interact
549.351 -> with Compute Optimizer.
551.12 -> So as a service, it goes without saying
554.96 -> that Compute Optimizer recommendations available
557.2 -> through the Computer Optimizer consoles and APIs,
559.96 -> but there are also a lot of other places
561.49 -> you can get these recommendations.
563.14 -> So let's just name a few.
565.17 -> So first of all, Compute Optimizer
567.37 -> is integrated with cost controller.
569.35 -> We have the right sizing recommendation tools.
571.11 -> If you go to cost controller console
573.16 -> on the left navigation there is a right-sizing item.
577.16 -> You click on the item,
578.12 -> these recommendations come from Compute Optimizer.
580.8 -> Secondly, you can go to EC2 console,
583.98 -> when you select the instance at the bottom,
586.21 -> you will see there's Compute Optimizer recommendation
588.43 -> tell you whether the instance is optimized or not.
590.91 -> So it allows you to actually look at the recommendations
593.99 -> while working on EC2 instances.
595.94 -> So that's a nice integration we have done,
598.08 -> and has been quite popular.
600.65 -> Third, Compute Optimizer also integrated
603.32 -> with database systems manager.
605.28 -> So you can have your operations data
607.49 -> and recommendations data side by side
610.1 -> in a systems manager explorer.
612.92 -> And then lastly,
614.12 -> we allowed you to export recommendations
617.6 -> as CSVs to S3 bucket.
619.53 -> So a lot of customers,
620.363 -> they may have like internal workflows
622.48 -> to draw dashboards,
623.92 -> like put things in database and run reports,
626.89 -> and exporting the recommendation to S3 bucket
629.711 -> is particularly useful features for that.
636.41 -> So for EC2 instances,
640.05 -> we look at metrics from four different dimensions.
643.84 -> The first one is CP utilization.
645.83 -> The second one is memory utilization.
647.39 -> For memory, the metrics not available by default.
651.89 -> So you will need to install cloud agent,
653.62 -> so that you can collect this memory metrics
656.153 -> and publish it to a special storage namespace.
660.791 -> And then the third one is network performance metrics.
662.59 -> For network, we analyze two types of metrics.
665.09 -> One is the bandwidth consumption
667.5 -> and then another one is the PPS, the packet per second.
670.01 -> So there are the separate limits and we analyze build.
673.45 -> And the last one is the storage.
675.2 -> So there are two types of storage.
677.14 -> One is the local storage,
679.343 -> the physical hard drives, SSDs, and HDD
682.704 -> attached the physically located instance.
684.85 -> And then there's also Amazon EBS volumes
686.86 -> that are remotely attached to the instance.
690.12 -> And we analyze the IOPS throughput information
693.97 -> of both EBS and local storage.
699.91 -> So here's here's example recommendation.
702.65 -> For example, you're using M5.2XLarge
705.17 -> that has eight vCPUs, 32 GIG of RAM,
708.97 -> and you pretty much have 40% CPU utilization during the day
712.47 -> and 10% CPU utilization during the night.
714.8 -> The memory is pretty much like 30%
716.98 -> and you have very low network and storage utilization.
723.34 -> So I receive a lot of questions asking like,
726.5 -> does Compute Optimizer analyze as maximum utilizations
729.67 -> or average utililizations.
731.91 -> We actually analyze the patterns of the utilization.
735.36 -> So for example,
736.193 -> if your workload is running 100% CPU during the day,
740.25 -> zero CPU during night, the average 50%,
743.24 -> but 50% is obviously not reflective
744.909 -> of the workload you're running, right?
747.56 -> Maybe a hundred is more effective,
749.25 -> but we kind of analyze the pattern to find out like,
754.68 -> what period of time are your workloads busy
757.41 -> and we'll try to size based on the busy period
761.85 -> to make sure that there's no additional performance risks
765.45 -> being introduced by these recommendations.
768.79 -> So for this particular examples, we have three options.
772.96 -> The first option is M5.xLarge,
775.47 -> which is one size smaller than the current one.
778.24 -> You have 4 vCPU's, you have 16 GIG of RAM,
781.36 -> you're going to say 50%
782.44 -> and your performance risks pretty low.
785.95 -> Your second option is actually using T3,
788.01 -> which is the burstable instance.
790.05 -> You can save a little bit more,
793 -> 57% based on demand price,
796.48 -> but there's a little bit of risk
797.88 -> because T instances is the CPU over supply instances.
803.275 -> And the third option is
804.15 -> you can actually reduce the number of vCPU's
805.93 -> by half, by the other half,
808.8 -> and you can save 67%,
810.89 -> and it carries some performance risks as well.
813.53 -> so let's actually look at what kind of recommendations
817.23 -> you will see in the console.
823.69 -> So this is the dashboard you're gonna see
828.035 -> when you first start up Compute Optimizer.
830.37 -> There's some new informations
831.357 -> and these are new launches.
833.629 -> We just announced early this weekend.
834.57 -> Marianna will talk about it
836.6 -> at the later part of presentation,
838.63 -> but the bottom parts analyzes EC2 instances,
842.71 -> auto scaling groups, EBS volumes, and Lambda functions.
845.21 -> So let's just look at an EC2 instance example.
849.5 -> So here, this one is a C5.2XLarge,
854.32 -> and you can actually see there are three options here.
858.44 -> How to interpret.
859.37 -> There are also a bunch of utilization graphs below
862.73 -> and how to interpret these.
863.98 -> So for example, the CPU utilization graph,
866.76 -> the blue line shows the current utilization,
869.81 -> which is around 20% on average
875.13 -> and then the time range is over past two weeks.
877.807 -> Then Compute Optimizer thinks,
880.3 -> tries to project the utilization on various options.
883.46 -> In this case, the option,
884.94 -> the first option is M5.XLarge,
887.25 -> and because it has less vCPUs,
891.36 -> the overall CPU utilization would actually increase
894.67 -> from about 20% to 40%,
896.56 -> which is still within the comfortable range
898.99 -> of what instance can handle.
901.01 -> Then in the memory utilization,
902.12 -> I have cloud agent installed on this.
904.4 -> It's about 81% currently
906.77 -> and M5.XLarge
907.84 -> had the same amount of memory as the C5.2XLarge.
911.61 -> So the memory utilization looks pretty good.
915.47 -> Then from network,
916.54 -> in a network out is pretty low.
919.74 -> There's no local storage in C5.
923.62 -> And then the EBS utilization is pretty low.
927.385 -> So conclusion is that here you can use the M5.XLarge,
930.61 -> saved you 43.5%, performance risk very low,
934.26 -> every month you expected to save a $106 per month.
939.22 -> That's inclusive of any save and spend accounts
944.51 -> you may have.
946.58 -> And you can actually look at which dimensions
948.54 -> are over-provisioned.
949.48 -> You can filter this.
951.09 -> It only shows you these dimensions can be reduced
954.8 -> whilst you maintaining your performance of the application.
959.39 -> So that's an example of EC2 instance recommendations.
965.21 -> Let's move on to look at other resource types.
978.6 -> So can we also analyze this resource EBS volumes,
984.71 -> and in particular we support SSD volumes here.
988.58 -> So there are four types of SSD volumes,
990.71 -> io1, io2, gp2, and gp3.
993.64 -> So the main things Compute Optimizer analyzes here
997.23 -> are mainly the throughput and IOPS.
1010.42 -> And here's example of the EBS volume.
1012.49 -> So currently you have a four terabytes size,
1015.87 -> EBS volume and provision 20k.
1018.43 -> Monthly cost is over a $1000.
1021.31 -> Utilization is pretty low around like 2700.
1024.697 -> And we will recommend you io1 and io2.
1026.957 -> io2 is actually the next generation of io1.
1031.15 -> We don't have storage space utilization metrics here,
1034.19 -> so we're not gonna touch the size of the volume.
1036.78 -> We're just going to change the provision IOPS.
1039.629 -> Because for EBS io2 volume,
1041.267 -> you pay for not only the storage size,
1044.16 -> but also for the provision IOPS.
1046.63 -> And by reducing provision IOPS,
1048.67 -> you can actually save about 35% of the cost.
1054.18 -> So that's kind of EBS example.
1058.94 -> And let's look at what it shows in the console.
1067.85 -> Yeah, so here you have io1, io2.
1072.55 -> 20k reduced to 10k.
1075.22 -> You have utilizations, there's this spike initially,
1078.78 -> but we consider it as kind of anomaly
1081.4 -> and we based our recommendations mainly
1084.27 -> on the utilizations afterwards.
1087.51 -> So you can see that it's around 27k
1090.66 -> and reducing ios by half.
1093.29 -> It's pretty comfortable with it.
1097.4 -> So I also hear a lot of questions about
1103.02 -> what is actually the difference between EBS metrics,
1106.129 -> we analyze the EBS recommendations versus the EBS metrics
1109.979 -> we analyze for EC2 recommendations.
1112.01 -> So on the EBS side and EC2 side,
1114.67 -> they're separate limits.
1116.293 -> It's on EC2 sides,
1118.06 -> it actually limits the total IOPS and EBS then
1123.36 -> was you can consume at the instance level,
1125.57 -> and the instance may be attached to
1126.66 -> one or two or 10 different EBS volumes.
1129.89 -> So when you aggregate these EBS metrics
1132.62 -> and then compare those with instance limits.
1135.87 -> So on EBS volume side,
1138.46 -> we only analyze the metrics for that particular volume.
1143.37 -> So, the recommendations may be slightly different
1146 -> because the type of metrics we analyze
1149.08 -> for EC2 recommendations,
1150.82 -> the EBS recommendations are different,
1152.25 -> and they're totally expected.
1163.135 -> Now let's look at some Lambda examples.
1165.86 -> So for Lambda functions,
1169 -> the idea of Lambda function recommendation is that
1172.91 -> if a Lambda functions you can configure
1174.54 -> how much memory you use for each invocation.
1179.58 -> So there are two types of Lambda functions broadly.
1183.4 -> One is kind of CPU intensive ones.
1187.42 -> So that for the CPU intensive ones,
1190.17 -> because the CPU,
1191.49 -> the allocated CPU resource is proportional
1193.39 -> to the allocated memory resource.
1195.36 -> So if your function is very CPU intensive,
1198.36 -> you can actually allocate more memory
1200.12 -> to get more CPU time slices,
1201.73 -> and you'll reduce your runtime,
1205.197 -> your execution duration.
1207.68 -> But the cost of the Lambda function
1209.86 -> is actually provisioned memory times the duration.
1213.81 -> Your function's going to run faster.
1215.36 -> Although your memory is larger,
1217.63 -> the product of these two values stays pretty constant.
1220.7 -> So you're actually not going to pay much,
1222.43 -> but you can actually get your function to run faster.
1225.21 -> On the other side,
1226.043 -> there's also functions that are not CPU intensive,
1230.13 -> another category.
1231.34 -> Then you provision,
1234 -> if you're overprovisioned in memory,
1235.37 -> you're not going to get any real benefit
1237.14 -> because you're just wasting these memories.
1239.41 -> So Compute Optimizer delivers recommendation
1241.57 -> for these two types of Lambda functions.
1244.25 -> So let's also look at how that works.
1259.09 -> Yeah, so this is a CPU intensive Lambda function.
1264.61 -> Configure memory is 128 megabytes.
1268.91 -> It's CPU intensive,
1270.46 -> which means that the execution duration here is 35 seconds.
1277.81 -> Give or take.
1279.97 -> Compute Optimizer recommends you to increase the memory size
1284.72 -> to about 160.
1286.12 -> Although the actual memory utilization is it's about 40,
1289.23 -> which is well below the value of provision.
1292.07 -> And yet we still recommend you to increase more memory,
1294.6 -> which just seems counter-intuitive.
1296.06 -> But actually, if you look at the projected duration,
1299.61 -> your function is going to run from 35 seconds
1302.86 -> to about 28 seconds, which is much faster.
1306.5 -> And overall the cost difference of making the change
1308.67 -> is plus minus 5%.
1310.2 -> So it's pretty much neutral.
1313.32 -> So by having a function run faster,
1317.66 -> you can actually get more performance
1320.675 -> with very minimal cost difference.
1323.03 -> So that's a CPU intensive function example.
1332.18 -> All right, so this is a memory example.
1336.63 -> Provision 256 megabytes of memory.
1339.93 -> You only used a very little of them,
1342.61 -> and it's not CPU intensive.
1343.81 -> We detected that.
1345.46 -> So if you reduce from 256 to 200 oi,
1349.8 -> your duration's not gonna change.
1351.31 -> So what happens?
1352.87 -> You have less memory,
1353.86 -> duration doesn't change.
1354.97 -> The overall cost is not going down.
1356.73 -> So here you're going to save
1360.09 -> about 20% on this function.
1362.19 -> So these are the types of memory functions
1364.54 -> that we support today.
1373.62 -> All right.
1374.5 -> So now we talk about different types of recommendations
1379.1 -> Compute Optimizer generates.
1380.77 -> Let's just quickly go through
1382.01 -> where Compute Optimizer is available.
1383.73 -> So Compute Optimizer is a regional service
1386.56 -> and it's available in 18 different regions,
1390.36 -> five in North America,
1391.39 -> five in Europe,
1392.223 -> seven in Asia Pacific,
1393.45 -> including two in China regions,
1395.9 -> then one in South America.
1397.33 -> And you can access it through
1399.49 -> the Compute Optimizer console, APIs,
1402.4 -> and through all the other channels
1404.56 -> that I just talked about in the previous slides.
1407.02 -> Now let me hand back to Marianna,
1409.46 -> and she will talk about some very exciting launch
1412.12 -> we just made earlier this week.
1420.73 -> All right.
1421.563 -> So we're excited to announce some new features
1423.25 -> to help you discover, review,
1425.31 -> and adopt Compute Optimizer recommendations more easily.
1431.16 -> So first I'd like to say that our roadmap
1432.87 -> is heavily influenced by your direct feedback.
1436.72 -> Specifically, we've heard the following tasks
1439.94 -> over the past several months are challenging.
1442.58 -> Number one, identifying which Graviton instances to use,
1446.74 -> two, identifying top savings
1449.19 -> and performance improvement opportunities
1451.38 -> across the account and resource types,
1454.65 -> three, ensuring that recommendations consider monthly
1458.08 -> and quarterly peaks versus just a 14 day look-back period.
1465.74 -> So we've heard that you'd like to more easily identify
1469.44 -> the Graviton resources you should use
1471.52 -> to maximize cost efficiency
1473.12 -> while meeting your workload performance requirements.
1475.8 -> So we listened and as of August this year,
1478.65 -> Compute Optimizer generates Graviton recommendations.
1482.7 -> Compute Optimizer now helps you understand
1484.9 -> the impact of migrating to Graviton-based instances
1487.96 -> by recommending up to three Graviton-based instances
1492.03 -> for your x86-based Linux instances.
1495.6 -> In the existing Compute Optimizer recommendations
1498.1 -> lists view for EC2 instances,
1500.29 -> you can specify that your preferred architecture
1502.74 -> is Graviton.
1504.39 -> And specifying Graviton as the preferred architecture
1507.34 -> then tells Compute Optimizer to show you recommendations
1510.5 -> for Graviton-based instance types where applicable.
1514.54 -> And alongside the recommendations,
1516.32 -> Compute Optimizer delivers projected price
1519.04 -> and hardware resource utilization information
1521.9 -> so that you can easily visualize
1523.98 -> the price and performance differences
1526.09 -> you can achieve if you were to migrate to Graviton.
1531.7 -> So here's a screenshot of the EC2 recommendations list view
1535.41 -> and above the recommendations,
1537.16 -> you can see a dropdown,
1538.83 -> that says CPU architecture preference.
1541.21 -> And in this case,
1542.043 -> Graviton has been selected as the preferred option.
1545.6 -> You can easily toggle between Graviton,
1548.14 -> between the two options,
1550.41 -> and you can compare the two architectural preferences
1553.43 -> to compare recommendations.
1558.22 -> Here's a screenshot of the detailed view,
1560.32 -> similar to what Letian was showing earlier,
1562.71 -> and you can choose your architecture preference
1564.47 -> here as well.
1565.65 -> And you can do this by toggling
1567.04 -> between the CPU architecture preferences
1568.95 -> at the top right of the screen
1570.79 -> and compare the recommendations for a specific resource.
1578.93 -> So you also told us that you'd like to more easily pinpoint
1582.31 -> your top savings and performance improvement opportunities
1585.3 -> across resources in a workload or account.
1588.77 -> And we listened to this feedback
1590.24 -> and now Compute Optimizer helps you quickly identify
1593.84 -> and prioritize top optimization opportunities
1595.878 -> through two new sets of dashboard level metrics.
1599.41 -> They are a savings opportunity
1601.16 -> and performance improvement opportunity.
1603.97 -> Savings opportunity metrics quantify the EC2, EBS,
1608.09 -> and Lambda monthly savings that you can achieve
1610.75 -> at the account level,
1611.97 -> the resource type level,
1613.47 -> and at the resource level,
1614.64 -> through adopting Compute Optimizer recommendations.
1617.98 -> You can use these metrics to prioritize
1620.46 -> and evaluate cost efficiency opportunities,
1623.13 -> as well as monitor cost efficiency over time.
1626.5 -> For performance improvement opportunity metrics,
1629.66 -> those quantify the percentage and count
1631.77 -> of under provisioned resources across your account,
1634.52 -> considering all resource types that we talked about earlier,
1638.22 -> and you can use these metrics similar
1639.62 -> to evaluate and prioritize opportunities
1642.22 -> that address resource bottleneck risk.
1648.48 -> So here's a screenshot that shows
1650.04 -> what the savings opportunity card
1651.37 -> in the dashboard looks like.
1652.76 -> Letian briefly showed during this demo.
1655.47 -> So crosses two key metrics at the account level,
1659.55 -> and their savings percentage and estimated monthly savings.
1663.8 -> So the percentage of savings you can achieve
1666.667 -> compared to your monthly cost.
1669.66 -> It further breaks down monthly savings by resource type.
1673.31 -> And this supports two main use cases.
1676.07 -> Number one, central infrastructure manager
1678.68 -> can easily identify which accounts
1681.01 -> in the organization have
1681.98 -> the highest potential savings opportunities
1684.38 -> so they can prioritize their engagements.
1687.09 -> Number two,
1687.93 -> an engineering owner can easily see which resource type
1691.38 -> has the largest savings
1692.87 -> to help prioritize the recommendation evaluation.
1696.86 -> Savings opportunity data considers
1699 -> both the cost of your existing resources,
1701.23 -> as well as your usage.
1702.66 -> And this data comes from Cost Explorer.
1704.55 -> So enablement of Cost Explore is required
1706.86 -> to see this data in the Compute Optimizer dashboard.
1714.36 -> Now this is a screenshot
1715.4 -> of performance improvement opportunity.
1717.46 -> So it comprises two key metrics,
1719.61 -> the account level,
1720.73 -> the under provisioned percentage,
1722.51 -> which is the percentage of resources
1724.657 -> the Compute Optimizer has found across your account
1727.17 -> to be under provisioned or at risk
1729.63 -> of not meeting performance requirements,
1732.84 -> and also underprovisioned count,
1734.53 -> which just gives you a sense of scale.
1736.25 -> So you might have two accounts
1737.62 -> that have similar underprovision percentage,
1739.82 -> but it might be a difference
1741.09 -> of a hundred resources versus two.
1743.46 -> So it helps you better understand that scale.
1746.35 -> And it further breaks down the count
1748.38 -> of under provisioned resources
1749.67 -> at a resource type level,
1751.41 -> and categorizes them based on performance risk.
1756.02 -> So Compute Optimizer actually calculates
1758.404 -> an individual performance risk score
1761.01 -> for each resource dimension.
1763.58 -> And it does that by looking at the proportion
1766.02 -> of time over the historical look-back period,
1768.26 -> that capacity might be constrained across its dimensions.
1772.87 -> Performance improvement opportunities
1775.184 -> supports two main use cases.
1776.33 -> Number one, engineering owner can see
1779.06 -> which resource type has the largest number
1781.92 -> of underprovisioned resources to help prioritize evaluation.
1785.47 -> And the second is engineering can see
1788.065 -> which resource across an entire account
1792.35 -> has the highest performance risk
1795.63 -> and prioritize our evaluation of that particular resource.
1798.55 -> So again, helps to reduce the cognitive load
1802.44 -> and the bandwidth required to identify
1805.04 -> where the top performance improvement opportunities are.
1813.19 -> And then the final launch that I'd like to talk about
1817.5 -> is enhanced infrastructure metrics.
1819.55 -> So you told us that you wanted Compute Optimizer
1822.39 -> to consider a longer look-back period
1824.27 -> so that the recommendations can consider monthly
1827.23 -> or quarterly peaks.
1829.34 -> And specifically for EC2 instances and auto scaling groups
1833.32 -> and we listened and on Monday Compute Optimizer
1836.02 -> introduced enhanced infrastructure metrics,
1838.32 -> which is a new paid feature in Compute Optimizer
1841.4 -> that you can activate to extend your look-back period
1843.86 -> from 14 days to three months.
1846.66 -> If you have monthly or quarterly usage patterns,
1849.105 -> the consideration of the three month look-back period
1851.79 -> can make your recommendations for EC2 instances
1854.76 -> and auto scaling groups, more accurate,
1856.96 -> and more representative of your workloads characteristics.
1861.1 -> This feature is inactive by default.
1863.47 -> So when the feature is inactive,
1865.02 -> that means that Compute Optimizer looks at the last 14 days
1868.6 -> of CloudWatch history in generating the recommendations.
1872.37 -> And in terms of how you can actually activate it,
1874.92 -> there are actually three levels that you can do it at.
1877.36 -> The first is at the resource level.
1879.03 -> So in the detailed view that Letian showed earlier,
1881.26 -> you can actually activate the feature
1882.83 -> for that particular resource.
1885.24 -> The second is at an account level.
1887.61 -> So as an account owner, in the accounts page,
1890.82 -> you can actually choose to activate the resource
1894.919 -> the feature across all the resources
1897.023 -> within that particular account for EC2.
1900.63 -> And then finally, as a management account owner,
1902.97 -> you can activate the feature across entire organization.
1912.35 -> So before concluding,
1913.94 -> just want to recap a couple of main points
1916.93 -> that if nothing else, you walk away from this with.
1920.66 -> So the first is rightsizing can help you save
1923.64 -> on resource costs and reduce performance bottleneck risk.
1928.06 -> And two, Compute Optimizer can help you quickly identify
1930.776 -> your top rightsizing opportunities,
1933.69 -> and estimated impact across EC2 instances,
1937.07 -> auto scaling groups, Lambda functions, and EBS volumes.
1941.34 -> This is a link to Compute Optimizer marketing page
1943.84 -> with more information and redirect links
1946.612 -> to our user guide and API reference docs,
1948.57 -> so and so forth.
1952.39 -> And before you go,
1953.75 -> I'd also like to share some upcoming sessions
1957.019 -> and resources specifically focused on cost optimization
1961.25 -> that you may find useful.
1964.32 -> So the first side of the page is online resources
1968.245 -> that you can access to number one,
1970.83 -> peer connect opportunities to connect with peers
1974.19 -> in the industry to talk about challenges
1977.3 -> and brainstorm solutions.
1978.89 -> Talk about innovative products together,
1981.456 -> and these happen regularly,
1982.94 -> and you can sign up and schedule your attendance.
1985.624 -> The second is we actually have
1987.51 -> a Cloud Financial Management Kiosk in the Expo Hall.
1990.44 -> So please take some time to talk to our experts there.
1994.15 -> And the final one is the Cloud Financial Management Blog.
1998.87 -> As far as relevant sessions to attend,
2000.61 -> we have one this evening and two on Friday.
2003.42 -> So the first is at 7:00 PM today,
2005.75 -> strategic IT planning and evaluation,
2008.59 -> and then the two tomorrow,
2009.6 -> eight ways to control and manage AWS costs,
2012.07 -> and quantify and maximize your cloud business value.
2017.77 -> So thank you so much for attending our session.
2019.939 -> This is great.
2021.09 -> We will actually conclude here
2023.45 -> and Letian and I will make ourselves available
2025.47 -> for questions on the floor
2027.29 -> before the next session comes in.
2029.71 -> We have some time here, so we'll stick around.
2033.41 -> Thank you.
2034.639 -> (audience applauding)
Source: https://www.youtube.com/watch?v=yt2rPJHrEeQ