AWS migration Acceleration programme It is our flagship programme for all sizes of migrations and modernization. It is the vehicle which we believe helps you digital transform, reduce the risk for your transformation and then also accelerate your transformation journey. My name is Fara Shafiq. I'm the worldwide head of product management for our cloud migrations and modernization business at AWS. Prior to a OB, SI spent 22 years in different industries. As a senior IT leader, I was a chief AI officer at Verizon, then Blue Cross Blue Shield before joining a O BS. And if you ask any IT leader about large scale projects, it could be migration could be implementation. One thing comes out very consistently and very common, which is whenever they do retrospectives, they'll always say, Oh yeah, we could have done this better. We could have spent more time in planning. We could have done some upfront diligence. We could have handled this better if we had brought in an expert partner. So retrospectives always happen And the example that I give is that you have to do better planning of Imagine if you're trying to build a house or you're trying to build a a multi story building. You do not go to a contractor and tell them, Hey, why don't you start building the foundation and then I'll tell you how many stories or how many floors to build? You have to share the plan. You have to build that out according to the plan. The second thing is, once you've built it, you can't just say, you know what? I actually don't like where this bathroom is and let me just change it and put it somewhere else. The analogy to IT. Infrastructure is actually very similar. Majority companies they've built and developed IT infrastructure, according to certain foundations and certain blueprints and certain plans. And then Chad GP D comes in and everything's out of the books, and now they're trying to figure out What do we do? How do we move fast? And the foundations are super strong, so you can't just rip them out and place it. So I think one of the biggest thing one of the biggest advantages that cloud offers is the flexibility is the power to do things very quickly, rapidly and not be held down to certain foundations. So map or migration acceleration programme is exactly that. It's a tried and tested vehicle that, in a very proven, structured way, helps you accelerate your transformer journey. And we've seen that happen across customers of every single size, every single industry, from every single geography, almost all the industry leaders that we talked to today they are either already invested significantly into the cloud or they have major plans to do so. And one of the things that I like is that you could be 100 year old company that is doing oil and gas research. And you're just as much interested in the cloud as a company like Airbnb or Pinterest that was born on the cloud and has plans to always be on the cloud. So irrespective of the side, the segment, the geography, you know, we see customers adopting the cloud, and the biggest reason is the flexibility among so many others. Now, one example that I typically give is is Disney. You know, Disney's been a fantastic entertainment provider for so many years. They're very big on producing original content. On top of that, they have the parks, which is a physical entertainment venue, and they last year launched Disney Plus, which was a new streaming service. And so for them, how do they bring in all these experiences together in a rapid, quick fire format? That was the key. And so they chose AWS to build Disney plus on top of their existing content capabilities and also made sure that it integrates with the overall experiencing that they provide in the parks as well. 11 logo that's not here is anthropic. So you know again, Just earlier this year, in February, open, AI released Chad GP T and just opened everyone to the art of possible of what Gen. AI could do. And we saw so many companies emerge in the space that are wholly focused on building LL, MS, generative AI and other solutions. And anthropic is one of them so anthropic they want to make sure that they use the most cost and performance efficient infrastructure for their training. You're talking a billion parameter Model being trained that requires intense compute, rapid testing, a lot of data crunching, and so by using AWS, Inferentia and trainium, the chip sets an infrastructure that is purposefully designed for large scale machine learning that are able to not only save cost but are able to deliver on the promise of opening AI to the broader world. And and and we're just amazed at the pace of innovation, Gardner predicted, uh, a couple of years back that in in 2023 we'll have 500 million new applications being built now. I wanted to use a another stat that would be forward looking, but I thought I share this stat because sometimes it's better to look on how we did anyone Guess how we're ending the year. 600,000,700 million, No guesses is still the lunch kicking in. All right, no worries. It's close to 900 million, which is twice, uh, more than expected and twice more than all the applications built in the last 40 years. We have solutions like AWS party rock. If you're not familiar, I definitely invite you to check that out. Party rock enables you to build AI applications in minutes without any code. You literally specify what do you want the app to do? Literally. Just write it in plain simple text. It converts it into an app so you can build an app in minutes. I did that over the weekend. Build five apps took me about 17 minutes. So again, highly recommend. If you don't know what I'm talking about, go search a party, rock. And so we do expect that the pace of innovation will continue to be dramatic. We believe that all the companies are going to be focused on building new and new solutions very rapidly. And it's not going to be about waiting and planning for months, months. It'll be about launching an application, testing it, getting the right feedback from customers and then adjusting it as you go along. So that really shifts the Model, uh, from a white, you know, previous standard waterfall type Model of development. And so this pace of innovation continues, and we see customers across many industries that are challenging the notion of how they operate and they're rethinking of their entire business models. One great example that I share is, uh, Unilever. So Unilever is more than, uh, century old. They have hundreds of popular household brands. They're headquartered in the United Kingdom, but operate in, uh, 95 different countries and have operations globally. So for Unilever, the big thing is how do they rapidly respond to changing market conditions, especially digital marketing thing like a shampoo brand. These campaigns are hyper local. They're not global, so you might be marketing a product in a certain location. And you cannot use that same campaign in a different location because of differences, sometimes in language and culture or sometimes the difference in just the new cycle. So even within a country you have different areas that you won't use the same campaign for. So for a company like Unilever that has hundreds of brands globally, this becomes a big, big challenge. So they migrated almost 500 different vet properties over to AWS in just under five months, and they were able to increase their speed and agility by 75%. And it allowed them to move a lot lot faster and launch digital marketing campaigns and new websites in under 24 hours. That meant if a new cycle came in that would be favourable to their product cycle, they'd be able to react very, very quickly instead of the weeks or the days that it took them before and different example is United Airlines. So United Airlines during the pandemic was struggling just like the broader aviation industry. There were days where United Airlines had more pilots than the number of passengers that they could fly. And it was it was really a big challenging time for them because you have all these investments on technology and it that were just not being utilised. And so for united they went very aggressive, very bold outcome focused goals that we not only want to reduce cost. We also want to automate, because if you cannot serve people physically due to covid requirements or other issues, how will we handle the support? How will you fix the issues? So they launched two initiatives. One was United Travel Ready Centre. If any of you has flown united recently, then you'll see the app automatically figures out all the right documentation and you know, supporting information that is required takes care of it. It makes flying much easier and seamless. So by switching over to AWS, United was able to automate 75% of their documentation and their en route to automate almost 90% of these workflows. Another big one was on ground equipment and support handling, so, you know, for to for an aircraft to be supported. You have a lot of equipment. You have a lot of ground staff. You have catering vehicles, you have maintenance. And so, by applying IoT Asset Tech real Time Analytics United was able to defer purchase on equipment, retire some of the equipment, buy some of the equipment, then optimise their supply chain. And it saved them $120 million in ground equipment. So real savings. Real dollars. But my favourite was that Linda JoJo, the chief customer officer for United, basically said, The big question for us is, What business are we really in? We're not an IT shop. We are here to serve our customers, which is to take them from point A to point B. And so it an IT infrastructure that's tens of thousands of people would be better supported by people that do that better. And so that's the philosophy that we take, like which, which business or what is your core strength and how can you double down on that? And United is a fantastic example of doing exactly that. And there are so many different reasons why customers, uh, chose to be on AWS and These are some of the few ones that consistently come up. Many customers have a singular focus on cost or a focus on cost. To begin with, they wanna see well, can someone else run the infrastructure better than them? And typically with the economies of scale that we have at AWS, it makes it a big, big equation. Others, like Unilever, for example. It was a big thing for them to be agile and to roll things out globally with the click of a button. Many customers talk about business continuity. Um, you know, there. There's been a lot of, uh, sort of challenging things going on in the global economy, and many customers talk to us now about resilience and business continuity. So, irrespective of what the business driver is, the good thing is that majority of the cases moving to the cloud remains one of the fastest and most economical ways for customers to achieve that. These days, a big business drivers is generative AI. Almost every single conversation that I have with customers these days either starts with generative AI or ends with generative AI, and we believe it's one of the most powerful tools that will reshape every single industry and segment that we can think of while it's still early. It's still being adopted, and it's still primarily focused on the consumers. We believe the enterprise side of generative AI is going to be a lot more powerful. So I don't know if you had a chance to catch Adam Sips Ski's keynote or doctor Matt Wood's session on ML and AI highly recommend. Check those out. Uh, this and we have a lot of exciting updates on how generative AI plays into our ecosystem. But at the core of generative AI is machine learning. And machine learning is very much entrenched into the Amazon DNA. Be it the thousands of products that are sold every minute on Amazon .com or the millions of packages that we process every single day globally, or the billions and billions of interactions that happen on Alexa uh, every week. Or the innovation that we're trying to bring in with Amazon Prime Air, with the focus on bringing in drone powered deliveries and you can go on and on so many different innovations and technologies that are being powered by machine learning and data at the core and So our our whole strategy is how can we help customers unlock the potential of generative AI? How do we make it easy to build? How do we make sure that the performance the cost is optimal? And the biggest thing is flexibility. I'm I'm indexing and over indexing on flexibility because I think that's gonna be a really, really critical element. We owe a lot to our customers that chose AWS and, you know, shut down their entire data centres to move to the infrastructure of AWS. And we started to understand Well, we've talked a lot about the benefits and the drivers, but what are they? Can we qualify and quantify them? And so we we did this research, uh, with thousands of customers and we find we found some really exciting results. Uh, on average, there was a 31% cost saving achieved by customers, uh, 62% better efficiency on the IT infrastructure side. That again means you're able to do more with the same IT infrastructure and same resources. And then my favourite was 75% increase in agility. The biggest thing here is that these are average numbers. In fact, we saw many customers that were doubling down and fully optimised with the right prescriptive guidance and structure. They were able to save upwards of 50% in cost, and some had seen almost a five X jump in agility. And the best part for me is these are not one off or sort of individual benefits. These are actually synergistic. That means you don't have to optimise cost because you know you can optimise all three of them. You can still save money while getting the benefits of agility while making sure that your IT infrastructure is more and more efficient. And so one key takeaway was that the benefits of moving to the cloud are real and significant, and we can easily qualify and quantify them. I wanna talk a little bit more about agility because that's, uh, a lot of customers. They see dollar values to start with the the hard savings and the hard dollars. But very quickly you see customers redeploying the savings into agility. In fact, one of the reasons why I believe Amazon, uh or AWS is a leader is because of agility. Agility means reacting faster and adopting to changing conditions faster. It's as simple as that. So again, think about Gen. AI. You know Gen. AI was launched in February. How many enterprises are able to fully capture the value from it or have a strong strategy in which they can utilise it? So any company that is more agile will be a factor of magnitude stronger, quicker, faster to react and respond. And so for Amazon, we not only have faster time to response, we have a lower, uh, failure rate, and then we also have a much better time to respond in case there there is a failure, and that's the reason why we are able to ship more than 10,000 plus releases every single day. And that's a big, big part of our equation. And these days you can't talk about these benefits without talking about sustainability. Sustainability has become front and centre. It is absolutely critical of many of our customers are now basing their entire decision on their strategy based on how sustainable it is, and so we want the cloud to be green. In fact, Amazon is one of the founding members of the 2019 climate pledge, which in which we promise to be carbon zero by 2040 not carbon neutral. That's a different thing, carbon zero. That requires a lot of dedication and focus on making sure that we can get to that stage and we do it by 33 primary main ways. One is our economies of scale. By having massive global infrastructure, we are able to operate at a much more efficient, much more highly utilised infrastructure that allows us to have a much, much lower not only carbon footprint but a better yield. The second thing is purpose built infrastructure, so chipsets like graviton, they are purpose built. They are designed to do certain things. If you want to do large scale machine learning Inferentia and training trainium chips, those are great because they will yield you the best results at the lowest possible cost. So purpose built infrastructure, architecture and guidance is another big one. And finally, it's it's all about renewables. We're very committed to making sure that we can utilise as much renewable energy and renewable sources in our supply chain, and the result is astonishing. We did this study with 451 research, and we found out that on a comparable IT infrastructure um, aws can operate the same infrastructure with an 88% lower carbon footprint. So quite amazing to see that. And we're very, very committed to making sure that we further our value there. So the biggest thing with agility is how do you move fast and how do you continue inventing? And no one gives a better tip than our CEO Andy Jesse the the The answer is quite simple. It's it really boils down to two things. If you want to innovate, you have to be able to try a lot of experiments, and you have to reduce the cost of experimentation. So, yeah, it's quite simple when you think about it, I'll I'll use my example from my previous life as an it leader. So if I'm a CIO O and I want to start a new machine learning project or try, you know, code Lama from Meta, which is an open source LLM, I'd have to in the previous role. First of all, buy hardware, understand exactly what hardware I need to buy. What's it gonna cost? Then? I need to figure out what software and operating system it has to run exactly. Understand what compatibility it's gonna have. I need to find exactly who's capable on the team that can actually do all of this. I gotta go talk to legal procurement, finance, accounting, billing. You can see where I'm going with this. That's why all these traditional companies struggle because every project becomes a six month, eight month, if not a multiyear long project. But in the world of AWS, if you want to try machine learning, it's literally as simple as a few clicks spinning up sagemaker spinning up Amazon bedrock, trying different things. In fact, many of our customers that experiment and innovate they're typically just using the free tier of AWS, so it's not even charged. And so you know, if you if it doesn't work, you literally just shut down the cluster, spin up another one, take the learnings and then start over. And that's the power of Cloud. That's what's revolutionised the IT industry. It's really these things. How do we get the cost to go so down? And you know, we have a very unique vantage point at AWS, especially from our migration acceleration programme. You know, we've migrated tens of thousands of customers at a large scale and hundreds of thousands at a smaller scale and we've learned a lot. We've learned a lot. We've packaged all those learnings and guidances into the programme, and today I'll share some of the the key learnings that if you really want to take away and make sure that your transformation projects are successful, make sure you have a tight pulse on these four. So number one is ensure you have strong executive sponsorship. It really needs to start from the top who are the right champions in your organisation. If I were to ask who's responsible for making sure that there's one standard architecture and you can't think of a name that's typically a red flag, we really wanna make sure that people have ownership and are getting the right support from leadership. The second one is bold and outcome focused. Goals need to be set by the way. This is where a lot of customers struggle because the difference is milestone and goals are different things. People say my goal is by two years I wanna exit out of my data centre or in six months I wanna go to Kubernetes for my application that does billing that is a technical milestone that is not a goal. So just when I said United Airlines, If cloud is driving business outcomes, your goals need to be business focused as well. So set goals that you can showcase into the organisation that they are driving meaningful results. If you're if you have a billing app, essentially say, in six months, I want to reduce the latency of the billing app or reduce the errors of the billing app. To do that, you'll have to set technical milestones, which means you have to maybe go to Kubernetes or apply machine learning. So that's the that's the difference. It's very critical. That's where a lot of customers just set technical goals and then they struggle. Why it's not generating business outcomes. So make sure that you drive strong business focus goals. The third thing is you have to build momentum early here. It's all about building the right muscle. We use a term called analysis paralysis, where a lot of customers just continue prepping and planning and preparing and discussing and actually not do stuff, whereas our approaches do fast learn even if you feel, take those learnings, take the feedback adjust and do it again. And by the time that you've done it, you know over 10 times you've ironed that out, you have a strong process, then you can apply it and scale it. And finally, it's take a portfolio driven approach. What that means is you don't have to boil the ocean. Not every application is the same. So some applications are going to drive much higher result for you. And maybe it's a core customer facing application. Maybe it's an application that does billing. Maybe it's an application that customers use for other reasons. So depending on what the portfolio is, you have to start with the key services. We'll talk about this just a bit more because this is again a critical one, especially if you're in large enterprise. So what we're suggesting here is that you have to use the full spectrum of available migration modernization patterns. A typical IT portfolio is made up of many different types of things. There's applications that have a high rate of change, they new applications or growth applications. They're typically customer facing and they're changing all the time. There are applications that are low rate of change, things like, for example, an SAP CRM solution that is a stable solution that typically is not going to change a lot over time. So understanding your IT portfolio and understanding where cloud fits best and what migration or modernization pattern to apply is really critical for the applications that are just low rate of change. We actually just recommend just lifting and shifting them, so you don't have to worry too much about the complexities or the failure. It's literally just lifting and shifting them. In fact, we have many tools that can automate that process. There are gonna be SAS alternatives Like again SAP. SAP is a great strategic partner for AWS, and running SAP on Prem versus On the Cloud is very similar. So sass is a great alternative to not only save costs but also get the agility. Then, as you get more and more on the cloud, you'll start realising there's a lot of call it tribal knowledge or a lot of architecture that really is not required. And so we believe 10% is just gonna be retirement. It's it's simplification of your code of your logic of your flows, and that generates a lot more benefit. And finally, for the most critical applications that are really differentiating that are your secret sauce. Those are the ones you want to put the most horsepower behind and make sure you modernise them so super critical to take a portfolio. Different approach. One great way to do that in a structured way is the AWS prescriptive guidance. So if this is not a resource that you don't know about, please uh, recommend you check it out. It's a combination of strategies, guides, different types of patterns because if you're going through some type of transformation, I guarantee some other company has also gone through a similar transformation. And so we've learned, and we've packaged many of these guidances into the A PG. So this is a great place to start if you want to know how to do a portfolio assessment, and then it's all about learning. As you go. Majority of the customers that start they start on the left side. They start with an on premises system that they just lift and shift, start seeing some benefits on the cloud. Then they start looking at scaling or introducing some type of right sizing or optimisation then they continue choosing the right pricing Model, so things like discount plans and Savings Plans. But eventually, as you start building the muscle and have more skill set, you want to go to the right and eventually go to the native services because that's where the cost is lost and your agility is going to be the highest. So what does it come down to? We've everything that I've discussed is part of our AWS migration, acceleration, programme, or map. It's a six pillar programme that allows you to benefit from everything that I mentioned in a structured, proven, crime tested way. The methodology covers the best practises tools, cover automation, frameworks, partners. We set a curated set of partners that will allow you to be more successful, that it's all of our professional services training as well as rich set of investments, and we use a very structured approach and map. We make sure that we do a deep discovery and assessment of the existing infrastructure, understand the dependencies between different applications, so you essentially get a scorecard of how your IT infrastructure is doing. Once the assessment is done, we move to mobilise mobilise is all about building the muscle so rapid proof of concepts. That's where you start thinking about detailed migration plans and detailed business cases. You set up a landing zone, which is a sandbox where you can really just play around with migrations, and then you actually migrate a few applications and so you learn during the process of what worked and what didn't work. And once you rinse and repeat, you can you can sort that out. Then you're ready for migrate and modernise, which is all about scale. So as you scale, you continue to operate, optimise and continue to modernise. So AWS uses the structured approach to just allow our customers to really not only derisk their transformation but also accelerate their transformation. And one great way that we offer as part of map is experience based acceleration. Think of this as a hands on immersive workshop where AWS brings in the right. Experts from AWS pairs it with the right experts from the customer and just gets in a room for for two days, three days talks about and knocks out the most difficult, complex challenges that our customers may be facing. So EB a is a great way for us to help our customers accelerate not only learning from the key, uh, experiences that we've gained but also just allows them to much quickly move to their transformation journey. So highly recommend you think about, uh, EBAS or experience of acceleration as a great tool. I'd love to know. Invite Sanjeev Lakshmanan, who's the vice president for monitoring cloud at Salesforce to talk about their journey. Chief, thank you for us. It's great to be here. It's my first reinvent as well, and it's good to be speaking here. My name is Sanjeev Lakshmanan and I'm a VP of engineering of monitoring cloud at Salesforce. I'm, uh, been with Salesforce for about eight years now. And, uh, I'm based out of the San Francisco Bay Area. I'm here to talk today about what we do at monitoring cloud in Salesforce. Why and how we migrated to AWS and how did AWS map help us along that journey? So let's get into it. So what do we do in monitoring cloud? Our vision is to build the best observability platform for Salesforce. We are an engineering organisation and we are the team that develops all the tooling for internal salesforce engineers to instrument their application for monitoring to debug issues and to fix them. And all this is so that Salesforce catches any availability issues before our customers experience them. We process and serve today more than a petabyte of data every single day. This includes telemetry data for logs, metrics, traces, events and all the metadata that is important in the monitoring context. We have our monitoring agents deployed across the entire Salesforce fleet. We also have an alerting engine that evaluates more than 200,000 alerts every minute. Thankfully, only a few of them fire and which is why Salesforce is highly available. But when they do fire, we have a routing layer that can route those notifications for alerts to multiple channels. And we built for salesforce use cases and for salesforce scale. As Salesforce grows, we develop new products. There are more services that are the backend for those products, and that brings more monitoring data to our absorb platform, and we need to scale out monitoring in order to meet the demand. When we have acquisitions, for example, we need to integrate their monitoring views into that of greater salesforce because, you know, they need to be able to Connect the dots across their salesforce integration points in terms of monitoring to be able to resolve incidents. We also drive the service, ownership, journey and availability reporting across the company. This is in order to create awareness about the importance of monitoring and availability, and we provide guidance and tooling for the entire company. You know, everybody is on a different maturity curve in terms of monitoring some teams that have been around for a long time. Services that have been around for a long time are probably very mature and, you know, they probably know exactly what to do, and they probably need little guidance from us. But there are other services that are new. There are teams that are new that are just starting out, and we provide common tooling and standardised framework for them to use. And the key here, across both these user groups is standardisation and consistency, because when everybody uses the same common tooling and framework to instrument their to monitoring, to develop their dashboards to set up their alerts, then when multiple engineers from different clouds in the company end up on an incident bridge, they're all talking the same language. It helps them resolve incidents faster and hence that helps improve availability. And that's basically the mission of monitoring cloud and Salesforce. We also built a monitoring portal, which provides comprehensive and intuitive visibility across the breadth of salesforce services. And again, you know, this is so that when engineers end up on an incident bridge and they need to debug issues, they don't have to scramble across five different portals. All the information that they need is in is in one place easy for them to access. And we just rolled out our APM set of tools and products. And it integrates views between metrics, tracers, events and all the context and provides a nice default dashboard when they land on the landing page from the alert. S3 years ago, we were running our observ platform almost entirely in first party data centres. We had hardware and capacity issues, especially to scale out. It was the early days of the pandemic and if you recall there were some supply chain hardware issues as well, that added to our problems. This is the time where basically, we are stressing on the importance of monitoring in the company and asking people to instrument more metrics and logs and traces. And when they started actually doing that and sending the data, we were like Wait, wait, wait, Hold on. We are not ready yet because we are not able to scale out. It was also hard to evolve the architecture and innovate because we were spending so much time in just staying afloat, so maintaining availability of our systems was very challenging. So when we are the team that's monitoring basically the eyes for salesforce internal engineers and we are not available, that's not a good place to be. So around the time that Salesforce broadly decided to deploy on Public cloud and on AWS, we wanted to migrate our observator platform to AWS as well. Salesforce has also built a trusted layer on top of public cloud called hyper force. And so we want to deploy the monitoring platform on hyper force on AWS to realise all the benefits listed here best in class architecture, modernise the infrastructure and systems be able to horizontally scale out when we get more monitoring traffic and finally and most important, is to improve the availability of our monitoring platform to 99.9. In comes the migration journey with AWS map. So the migration acceleration programme, as far as was saying, helps customers migrate to AWS and helps modernise the architecture. That's just perfect. That's exactly what we wanted to do. And this programme has five phases. The first one is asset inventory where we take stock of what parts of our application we want to migrate. What are the technical dependencies between those applications that also need to migrate along with us? For example? In our case, some of the security services that we depend on for authentication and authorization also had to move along with us because they need to be there. Before we did so that was part of the planning. Next step was develop the architecture for the migration. We had several applications which form the entire absorb platform for metrics, for logs, for tracers, for events. And, you know, we had to determine what parts that we can just lift and shift to make it easy because maybe they were already on the right architecture versus, you know, modernise and rewrite some parts of them. One example is our metrics platform was one big, monolithic cluster back in our first party data centres, essentially a single point of failure. If that went down, it was a monitoring blackout for the company. So when we moved to Public cloud on AWS, we basically shouted out those clusters. We also built a federation layer on top of the clusters so that all the queries get routed accordingly. And the user experience was pretty seamless, even though we had changed out the entire backend behind the scenes. We also tried to leverage AWS products, as opposed to running some of our own internal databases or open source technologies where it makes sense. And then we finally developed the migration plan, which included not just the technical aspects but milestones. We also wanted to do launch because monitoring is something that has to be available all the time, right? It's a little bit like electricity. You don't notice it when the lights turn on, but you do notice and have something to say when the lights don't turn on. So monitoring is a little bit like that, so we wanted to make sure that we launch in AWS. We do launch but also run the systems in paddle. And once we fix all the issues, tweak systems a little bit. Then we cut over the traffic from first party to AWS. And then while we were executing, one of the things that we did was stay up to date with any AWS innovations that were being released like maybe new instance types that were perhaps more performant and maybe more cost effective so that we can land on the right architecture. And once we launch, it doesn't end there. It actually begins there because, you know, we can do all the planning that we want once the scale really hits. Once we land on the target architecture, that's when we can monitor and tweak and optimise. And that's a continuous cycle, and we are still doing that. This is a large and complex migration, as you can imagine, a multiyear journey. But it was made really simple with the help of not only the amazing team that we have in monitoring cloud at Salesforce, but also with the amazing team that AWS map provided us with. We had a dedicated team of solution architects who had done multiple migrations as far as just spoke about. They knew the use cases. They knew multiple design patterns and they were able to advise us at every step of the way. We also had dedicated TAS technical account managers who were managing our accounts, and we had many of those managing resource limits, scale limits and managing our cases as well. And we had an account rep and a CSM who not only helped oversee the project but also organised events, volunteering events, you know in Salesforce style salesforce culture. And that was great to see. We finally migrated successfully well in advance of the original time that we anticipated to. There are two key outcomes as a result of migrating to AWS. Number one is developer productivity, and the second one is improved availability. Both of them are important. So we estimate that we roughly feed up 15% of engineering time for our engineers to focus on innovation or develop more features. Part of this is because we are not maintaining our own capacity anymore and battling all those challenges, and part of it was because we leveraged some AWS products instead of running our own services. One example is we used AWS, RDS and postgres, whereas in first party. We are running our own database instances. You know, it takes a lot of time for engineers to manage it, install it, upgrade it, fix it bug fixes, uh, tooling in order to deploy it all that is taken care of by RDS. Another example is we use AWS elastic cache sort of running our own Redis clusters. And that's been helpful as well in terms of developer productivity. And, you know, because we have improved availability with all the new architecture that we designed, all the monitoring systems are at least running at 99.9 availability. You know, it's a pretty large scale system, as I described earlier, so maintaining 99.9 plus availability is something for us to be proud of. We also have released our alerting engine in H mode high availability mode, which is now on a four lines architecture, and we want to continue our partnership with AWS in order to move all our systems to better than 99.9 availability. Finally, in terms of evolution with AWS, we want to continue to improve latency and availability, and we want to deploy the absorbability platform across multiple regions. There are some streaming use cases at Salesforce where they can benefit from real time and near real time alerts and insights. And finally, we want to continue to reduce the total cost to serve. We know that our salesforce grows. We will only get more data for monitoring and that we want the monitoring cost to scale sub linearly with the growth of the data. Hopefully that give you a good glimpse of what we do in Salesforce with monitoring cloud. Why and how we migrated our platform to AWS, you know, and how AWS map helped along that journey. There is a case study that we have published. It has more details. The link to the case study will be included in the debt that Farage shares later. And with that, that's all I had. Thanks everyone and over to you for us some Thanks And Chief. OK, so I see that people are getting ready for coffee now. Um, so we'll make this super quick. Um, if there's one takeaway that I want all of you to understand, it's actually two takeaways, not one. We, as AWS are super committed to removing barriers and removing the paid points from a digital transformation journey. And one great way that we do that is building a solid plan that is across people process governance, platform security operations. These are migration readiness assessments. They're all available for free. They're available on demand or as a resource that we can provide in a Federated / moderated way again. Highly recommend you check out and build a business case and assessment plan. Then there's things like migration, uh, application service. It's a free service that helps you literally automate majority of the migrations and applications. It's automated, reliable, flexible especially for, um, standard databases, standard storage services. So again, you know, automation, tooling, readiness assessment. All of these are applications, and these are just one of the many applications we have across the board, Uh, at every single place, be it our own services as AWS or be it the best in class partner services and tools that we make available. So again, I invite all of you to check those out. Finally, it's all about partners, uh, especially if you are in a niche domain or you're operating in an area that requires certain domain knowledge or expertise. Then partners are gonna be super key. Uh, to your successful transformation, we launched the AWS migration competency a few years back. We have more than 250 certified competency partners. That means that these are hand picked, curated, vetted partners that have already done certain level of migration. They already have people at the advanced skill level, so you can pick any partner from this list that meets your criteria. And you can be REST assured that they will have the right skill sets or the knowledge. OK, so where what does this boil down to? It's really two things. How do you start and where do you start? So the first thing would be a business case. Understand? What are your business drivers? The ones that I showed before, like understand, What's the main driver? Is it cost? Is it agility? Is it product innovation and then putting in some numbers in some RO I We actually have calculators that are made available online, a lot of different business case tools, so understanding the drivers, understanding business outcomes and certain timelines and milestones would be very critical again. Don't confuse goals and milestones, but you need both second thing is, just get a readiness assessment done for your organisation. The the outcome will be a matrix of capabilities both along a people process and technology point. And it will give you a strong current state of your organisation. So start there again. These are resources that are available online for free cell service or engage your AWS rep. And most of these are at no charge to customers. So please use these resources. You know, finally, reinvent is really a educational / learning conference more than anything. So I do invite all of you to check out the multitude of resources that we have available. I've listed the four that I thought would be most beneficial. So please check them out, including the Salesforce case study, which goes into a lot more detail on how a large, complex, innovative organisation like Salesforce, you know, benefited from that. And I always say this you know what stays? You know what what happens in Vegas stays in Vegas. That's the general rule. But feel free to learn more about this topic. Share this with customers, share it with partners. Thank you so much for spending your time with us. Really appreciate it. Sanjeev and I will be outside to take any questions. Thank you.