--- title: Thank You - CloudFront Breakthrough Webinar --- Revinate leaves their ELK stack behind to find huge gains with ChaosSearch -- Read More! [Revinate leaves their ELK stack behind to find huge gains with ChaosSearch -- Read More! ](https://www.chaossearch.io/resources/customer-stories/revinate) [![ChaosSearch](https://www.chaossearch.io/hubfs/2021%20Website/logo.svg) ](https://www.chaossearch.io/) ![Gartner Cool Vendor 2023](https://www.chaossearch.io/hubfs/C2020/Logos/Gartner%20Cool%20Vendor%202023.png) [![Start Free Trial](https://no-cache.hubspot.com/cta/default/4020721/a1eeee12-14a2-41d7-a38b-11e32980b916.png)](https://cta-redirect.hubspot.com/cta/redirect/4020721/a1eeee12-14a2-41d7-a38b-11e32980b916) # New CloudFront Breakthrough ## From Log Data to Business Insights in Minutes   ## Interested in scheduling a brief intro call to see how ChaosSearch can accelerate your analytics? Yes - show me the calendar! ## Future-Proof Your Analytics at Scale [![Get a Demo](https://no-cache.hubspot.com/cta/default/4020721/0ae4b1b0-9ec0-4169-80cc-64fda5fd56db.png)](https://cta-redirect.hubspot.com/cta/redirect/4020721/0ae4b1b0-9ec0-4169-80cc-64fda5fd56db) ©2024, ChaosSearch®, Inc. [Legal](https://www.chaossearch.io/legal) Elasticsearch, Logstash, and Kibana are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries. Elasticsearch B.V. and ChaosSearch®, Inc., are not affiliated. Equifax is a registered trademark of Equifax, Inc. Contact Us Phone: [(800) 216-0202](tel:+8002160202) Email: [teamchaos@chaossearch.io](mailto:teamchaos@chaossearch.io) Follow Us - - - - ```json { "@context" : "https://schema.org", "@type" : "VideoObject", "description" : "112019 CloudFront Breakthrough Webcast", "name" : "112019 CloudFront Breakthrough Webcast", "thumbnailUrl" : "https://i.vimeocdn.com/video/833220441_100x75.jpg?r=pad", "transcript" : "INTERVIEWER: Hello, and welcome to today's webcast, presented by Redmond Magazine and entitled New CloudFront Breakthrough, from Log Data to Business Insights in Minutes. We're quite excited to have you join us today. And we look forward to sharing the experiences and insights of our three great presenters. Before I introduce today's speakers, I have just a few housekeeping items to cover. We expect today's presentation to last about 30 minutes. We'll be addressing your questions and comments at the end of the presentation. And we encourage everyone to participate by submitting questions or comments during the course of the conversation using the Q&A panel. Note that the entire webcast is being recorded and will be archived for future viewing. We'll be sure to notify you when the replay is available. And now, I'd like to have each of today's presenters introduce themselves. AM, let's start with you. AM GROBELNY: Hey, I'm AM. I'm a Senior Partner Solutions Architect here at AWS working, specifically, with startups. Excited to be here. Thanks for having me. JIMMY MCDERMOTT: Hi, everyone. My name is Jimmy McDermott. I'm a CTO at Transeo, which is an educational technology company focused on compliance for school districts. And excited to talk about ChaosSearch. DAVE ARMLIN: Hi, everyone. I'm Dave Armlin, VP of Solutions Architecture and Customer Success at ChaosSearch. And I'm a longtime AWS user and looking forward to today's conversation. INTERVIEWER: Thanks, AM, Jimmy, and Dave. Today's agenda will be as shown here and includes an overview and update on the latest and greatest from CloudFront, the current trends and approaches to streamline access and visualize your data from CloudFront, and real life insights from the field from Jimmy. And finally, we'll address any questions that you may have. So now, without further ado, I'll turn things over to AM to start today's presentation. AM GROBELNY: Thank you so much. So I'd like to start out and give you an overview of what CloudFront is. I think we would also be remiss if we didn't cover AWS Edge Services in general. So if you've never used CloudFront before, these first few slides will be a really good intro for you, along with some of the technologies that sit alongside CloudFront to really help you utilize Edge Services with your applications running in AWS, and even on-prem as well. And then at the end of this, of my section, I'll have a little-- some architecture diagrams to show you how you can collect some logs, which will play into what you can do with ChaosSearch, and then also maybe a few tips on how to optimize your CloudFront distributions. So I'll kick off here with just highlighting five of these Edge Services that I think play really well together. The first two here, I won't speak as much in depth on this slide about, because we'll be spending most of my presentation on these two topics. But Amazon CloudFront really sits at the heart of Edge Services. Is our Content Delivery Network, or CDN. So if you have a globally distributed applications that you need to get all over the world, CloudFront is the way that you'll do that. I'll go more in-depth on some more slides coming up. But our next technology here is Lambda@Edge. And not to editorialize, but Lambda is probably one of my favorite services in general. And Lambda@Edge really gives you a really great way to run code on these points of presence throughout the distributed global network that AWS has set up. So instead of having to worry about provisioning out infrastructure to run at these Edge locations, instead, you can just write function codes to run on these points of presence. Makes it really simple to deploy out code. Next, we've got Shield, which Shield is a great way to mitigate DDoS attacks. So when you use Shield with CloudFront, there's protection against DDoS attacks, because you're distributing traffic across multiple points of presence. And you're also filtering requests through Shield. I'll say, when you use Shield Advanced, as well, it provides always on, flow-based monitoring of network traffic and active application monitoring. So you get near real-time notifications of suspected DDoS incidents. The next portion that also works really well with CloudFront is Web Application Firewall, or AWS WAF. This is more for filtering malicious requests. So you have things like SQL injection, cross site scripting, for example, that may try to be harmful to your services running. You can filter out at the actual point of presence location. That really helps to minimize the latency as well. And finally, there's Route 53, which Route 53 is our DNS service. It works well with CloudFront. CloudFront already has support for utilizing the lowest latency location automatically when you create a CloudFront distribution. For when your viewer actually requests content, it will automatically go to the closest location to that viewer. However, with route 53, you can create an alias record to your CloudFront distribution and use your own DNS names. So moving on, why I use CloudFront. And I think these two slide sum it up pretty well. You got application, compute layer, database, storage layers that your customers will be accessing, typically through some sort of application. This could be regional. This could be deployed on-prem, for example, as well. And you don't really have a way of keeping this in one area to mitigate risk and also to distribute it globally. What CloudFront gives you is the singular uniform layer sitting in front of this whole compute and application layer that you've got going. So you can actually utilize CloudFront with S3, with your on-prem servers, or EC2 servers, utilizing a DNS name. And let's take a look at some of the features for CloudFront. All right, so, as I stated up front, it's a global content delivery network. We'll see a slide coming up showing you kind of some of the locations across the globe that we've got. Those are always changing. But as I mentioned earlier, already integrated with WAF and Shield. And you can choose the more advanced settings if needed. And you can even put Lambda@Edge in front of viewer requests or origin requests, which we'll talk about in depth in the next slide. But how you actually utilize a CloudFront distribution is you can have assets stored in S3 buckets. You can have S3 buckets configured as websites. You can have servers in EC2 or on-prem that have DNS names that you can add as a distribution. You could even use CloudFront Origin Groups, which is using an origin failover to designate a primary origin for CloudFront plus a second origin that CloudFront will automatically switch to when the primary origin returns a specific HTTP status code, failure response, for example. In addition, there's built-in security features. So you can even configure CloudFront to have secure access to files. So you can use signed URLs or signed cookies when you're utilizing S3, for example. You can even create a special CloudFront user called an Origin Access Identity with S3. So that you can create a bucket that remains private and only give access to this CloudFront user to be able to access these assets stored in the S3 bucket. So no longer do you have to keep your CloudFront buckets public, which is an ongoing problem we see. Many, many of our customers want to reduce risk and mitigate that public bucket access control. I'll mention two here, we integrate CloudFront directly with the Amazon Certificate Manager. So you can actually have HTTPS communication with your CloudFront distribution for viewers. You can also configure CloudFront to have HTTPS for origin communication as well. So we'll go ahead and move to talk about Lambda@Edge. Which Lambda@Edge is a really great set of features that lets you run node or-- node.js or Python functions at the edge, on these points of presence. And you've got four areas where you can capture requests. You can actually go ahead and set functions to run when CloudFront receives a request from a viewer, when you forward that request onto the origin, when you receive a response from the origin, and before you return that response to the viewer. So you've got four separate events that you can hook your code to. And just some common examples of what people are using Lambda@Edge for, let's say, you need to inspect a cookie, and based on that cookie, rewrite a URL. So you can use this so that users can see different versions of a site, for A/B testing, for example. Or you can even check these cookies for different criteria. For example, retail website that's selling clothing, you want to use cookies to indicate which color a user chose for a jacket, the Lambda can actually change the request so that CloudFront will return the image of a jacket in that selected color instead. I'll just give you a quick insight into our different Edge locations. This map is current as of November 2019. It's always changing. We've got about 200 points of presence at the moment. Again, this will change based on when you're viewing this. But now, I want to show you some ways to collect logs. So the whole premise of this webinar is to actually collect logs and get some business insights into that. So one feature-- so I wanted to go over a few architecture diagrams of, actually, what CloudFront will look like in front of one of your origins that you choose, and how you could, actually, just enable logs, through your distribution, to automatically be placed into an S3 bucket. So I'll go ahead and advance the slide here, so that we can see what this all looks like. And as you are receiving requests from viewers, you'll have your DNS record, containing your own-- containing your own domain name that gets passed along to an Edge location automatically. Those requests that are coming in will actually generate access logs that you can then store in an S3 bucket, which plays really well into how you will then gain insight from ChaosSearch, which we'll hear more about from Dave later on. So several times in an hour, or once an hour, or so, CloudFront will deliver these access logs to whatever bucket you set up for that. But we also mentioned Lambda@Edge. And there's some blogs along with that as well. With Lambda@Edge, we're going to need a little bit more set up to collect logs. Lambda@Edge, when it runs and invokes your function, those logs will automatically get placed into a CloudWatch log group, which you'll then need to transition over into an S3 buck, perhaps the same S3 bucket where you're storing your CloudFront access logs. It's very simple to set this up. You'll just go ahead and create a Kinesis firehose data-- I'm sorry, this Kinesis data firehose data stream that will deliver the logs. And as part of the CloudWatch log subscription-- sorry, as part of CloudWatch logs, you'll have a subscription filter that you can set. And that will automatically pass along the log data into the data firehose, which will then deliver to S3. So you'll be able to aggregate all of your logs coming from either Lambda@Edge in one of these points of presence locations, and also your CloudFront distributions directly into one S3 bucket, if you so choose, could be multiple as S3 buckets. But that way, you're really set up to immediately start using ChaosSearch, then, to go ahead and gain insight into what your viewers are doing as they request content from your CloudFront distribution. I'll give you a few tips here to optimize your caching. So the best thing that you can do for performance and pricing is to avoid cache misses. So you really want to specify the longest practicable time to keep that cache around. And that's going to be up to your business requirements. Now, the maximum time frame that you can set is 100 years for this max age setting. Probably not many people are going to be able to meet that. But the higher that you can set this, the less cache misses that you'll have. And finally, these last three recommendations also have to do with avoiding cache misses. When you send over query parameters, another feature of CloudFront distribution that you can do, you can forward on query string values. If you make sure that, let's say, you're using this to change the language, so you have language is equal to EN in your query string, if those are always lowercase, you'll avoid cache misses, or if they're always uppercase. But if you start mixing the two, that will count as a cache miss. Also forwarding over only the cookies that you're going to need to use, that's a great tip to avoid cache misses, because you really open the door to more cache misses when you forward over things that you don't need to utilize. Same with request headers, if there are a large number of unique values on these requests headers, you're going to run into more and more cache misses. So with that being said, I'm going to turn things over to Dave to tell us, now that we've got our logs stored in an S3 bucket from CloudFront and from Lambda@Edge, what can we do with that for ChaosSearch? DAVE ARMLIN: Thanks, AM. We are continually excited to hear about the new services and how AWS enriches these services that allow people to build rich and secure global customer experiences. So hearing about CloudFront, Lambda@Edge, and all these great services, it makes us very excited for our customers and for us, as we're building on AWS. Now, by way of introduction, ChaosSearch search is a SaaS platform that allows you to do search and analytics on data directly out of your S3 bucket in a secure, highly scalable way from gigabytes of data to petabytes of data. And that data could be CloudFront logs, that we just heard about from AM, or any of the other logs from AWS services, or log data from your application itself being streamed into an S3 bucket. You can instantly get insight and value out of your data with ChaosSearch. Now, we're equally excited to be embracing the AWS open distro for Elasticsearch as well. And I wanted to make some comments about that. The open distro for Elasticsearch that AWS announced, we will be embedding the latest of that with the Kibana 7.2 interface and the great alerting and webhook functionality that comes with that, empowering some great integrations, including some integrations that we've done with CloudFront and dashboards and visualizations to empower CloudFront logging and visualization. Now, important note before I go ahead to talk more about CloudFront is while we do expose an Elasticsearch interface through Kibana and APIs, ChaosSearch is built upon patent pending technology. And there is no Elasticsearch to be seen under the covers. We use our own technology that we developed to allow for this great scalability and price performance of getting value out of data out of S3, and data that's in, essentially, an object store. So I just wanted to make that point. Now, moving ahead, moving ahead, AM described what the traditional architecture would look like to stream and get CloudFront logs into S3. And often, what that requires is some preprocessing with Lambda. And you will bring Amazon Kinesis into play to preprocess and get data into the S3 bucket. Just wanted to give folks a before and after. We greatly simplify what's required-- ChaosSearch, with ChaosSearch, if you can get the data to S3, ChaosSearch, then, can index and provide the ability to query and search on that data. So essentially, there are a variety of ways to get data from CloudFront into S3, and other AWS services, and/or your application logs, whether it be Fluend, or Logstash, or any of the other tools that might provide transport capabilities to get log and event data, or data in general to S3, ChaosSearch can then enable search and analytics on that data once it's in S3. So this greatly reduces the complexity and services that are required to harness value out of data in S3. Now, mentioned earlier, because we're embedding Kibana interface, you get all the great visualization, and dashboards, and capabilities of Kibana 7.2 from the AWS open distro. And here, I'm showing a dashboard that we've created for CloudFront that's served up out of this Kibana interface in the ChaosSearch. Once you log in, you'll see this interface that shows some of the great data that you can get from the CloudFront logs and all those wonderful Edge performance capabilities and security capabilities that AM described earlier. So to kind of cap off, ChaosSearch is enabling you to get value and quick insights directly out of your S3 bucket in a secure and scalable way. We're going to do now is hand over and introduce Jimmy McDermott, the CTO of Transeo, to talk about his journey into AWS and how AWS and ChaosSearch are kind of important pillars to their platform at Transeo. JIMMY MCDERMOTT: Thanks, Dave. My name is Jimmy McDermott. I'm the CTO here at Transeo. And I'm really excited to be talking about the transformative journey that we've been on with ChaosSearch to help us really better understand the data that we're intaking, as well as maintain compliance for ourselves and offer better value for our customers. So just to give some background on what Transeo does, we're an ed-tech compliance-focused solution where we basically allow school districts to track and manage their community service hours, as well as their career readiness initiatives, and then track and manage and report all of that data back up to the state and federal level. So that schools can maintain compliance with different regulations around graduation readiness for students. This allows them to keep their funding, and stay in compliance, and all sorts of fun stuff. So we take in a lot of different data from a lot of different data points in order to help students, and try and create value and provide value for those school districts, as well as the students who are working towards their goals. On top of that, we serve students from across the country. And every state has slightly, or even large, differences in their regulations. And so we have to maintain compliance for ourselves, as well, with our data, because we store this bulk data, both on the transactional side, for us, but also on the logging side, for all of our students. And most importantly, we have to retain that data and comply with this regulation called FERPA for long periods of time, often multiple years postgraduation, and be able to produce that data, as well as analysis of that data, at any time for the government, or for the school upon request. So simply removing that data, and kind of moving on with the system, and clearing up server space simply isn't an option postgraduation for us. So we started with our service on Heroku. And we were there for about a year and a half. And it served us very well while we were kind of getting things up and running. And then, we saw a pretty massive surge in what we were doing and the number of students that we began to serve. And so we started to look at some alternatives, because Heroku started to become more restrictive when it came to price, as well as flexibility around what we were doing. And we determined that moving to Amazon Web Services was the right decision for us. So we began that process about six months ago and wrapped it up about four months ago. So moved over our entire system to AWS. Probably, the biggest concern that we had when we were making that transition was putting together a plan for how we were going to retain all of our log data now that we were moving over to a completely separate system. We had kind of a disparate way of doing that previously. But we knew that moving over to Amazon would give us a fresh opportunity to really re-evaluate our processes around that and understand if we could do something better to both serve us internally, but also provide better value for our clients. So speaking towards that, I want to talk a little bit about what we previously looked like when we were on Heroku versus what we've enabled ourselves, and what ChaosSearch has enabled us to do, now that we've moved over to AWS, as well as brought in ChaosSearch to sit on top of our data buckets. So previously, we had absolutely no visibility into our logs. We were tracking everything and sending it over to a bucket. But we really had no way to actually track that information and pull actionable insight out of it. And on top of that, like I mentioned, we have pretty significant retention policies. And with our previous method of doing things, we had poor and no ability to actually retain those logs, since the ballooning cost of those logs was really becoming prohibitive for us. And so even prior to our decision to move away from Heroku to AWS, we were already beginning to investigate what we were going to have to do to bring in another service to start managing our log data and what that was going to do to our monthly costs. The analysis for the C-Suite level, so we both stored that data for the purpose of retention and for compliance, but also we can get some really valuable insight out of that, in terms of how students are using our platform. All of the data that gets sent at the log level is deanonymized, so we can feed it into lots of cool things to try and understand how students are interacting with the service that we provide. That was really complicated and pretty much impossible for anybody within, kind of, our executive suite, who wasn't down in the dirt with the tech to do previously. It was hard to put together dashboards, hard to actually pull any insights out of it. Now, it's really easy. We send the data right to S3. And we can put graphs right on top of it. And then super important, also, is the proactive security analysis. We've done a lot of really cool stuff now that we have all of our logs centralized and all kind of flowing into one place with ChaosSearch, where we're able to proactively search for potential security problems and try and fix them ahead of the curve, rather than being reactive to the problem. That's been really important for us, especially as we deal with the protected data class that is student information. And then now, things are a lot better for us. We have a much more predictable storage costs, because we're really just paying for the cost of S3. So we know pretty much exactly what each additional user is going to add to that cost, because everybody pretty much has a standard amount of data that they're pumping into that S3 bucket. Like I mentioned, we now have these beautiful and easy to understand dashboards that we can share with members of our team that really allow us to go deep onto data that we previously just didn't have access to. And what I'm really excited about is, many years down the road, when we have multiple years of data stacked up is being able to really understand how things have changed over time in usage patterns, so that we can pull historical references to try and help with present value. So that that'll be a really cool thing for us to be able to do in the future. And then, we can also ask any question about any user at this point. We were always able to do this on the transactional side of things, within the actual raw database, but being able to do it with a time based series of logs has been really impactful for us. And then like I mentioned, as long as S3 is standing, so are our logs, which is really, really important for us when it comes to unlimited retention, and then retaining it for as long as we need to be in compliance with FERPA. So all in all, we've been incredibly pleased and very happy with our transition to AWS with our logs. And of course, we are very happy with how things went on the server side as well. But the logging has truly been transformative, both from a business intelligence standpoint and from a technical standpoint. And ChaosSearch has played no small role in that. And we're really, really happy and very pleased to have partnered with them on the transition. DAVE ARMLIN: Super, Thanks, Jimmy. I appreciate it. And I guess one for you, as you delve into using ChaosSearch, and certainly, people can get value whether the CloudFront logs or application logs. How quick were you able to get insights? Do we live up to the title within minutes, or that initial ramp to using ChaosSearch? JIMMY MCDERMOTT: Definitely, absolutely, that's a great question. The hardest, the absolute hardest part for us was just getting the logs into S3. From there, ChaosSearch really took over. And we had, as a company, had a little bit of a learning curve switching from Heroku to AWS, where everything is managed to not so much. So as soon as we were able to get those logs into S3, everything from there was about as simple as it could have been and really instantaneous when it came to analyzing that data. DAVE ARMLIN: Super, that's great. Well, for those that are listening in, we have the dashboards and integrations. CloudFront is certainly a big part of value of the AWS services and the focus of today. But we invite folks to check out the product directly themselves. We have a free trial, if you go to chaossearch.io/freetrial or trial, you can check out for yourself. And look forward to that. So I think at this point, might be good to flip over to Q&A. INTERVIEWER: Yep, perfect, thanks, Dave. Thanks, Jimmy. And Thanks, AM. Fantastic work, and lots of great information, really appreciate it. So as Dave mentioned, we're going to jump, now, into the Q&A portion of today's presentation. Please continue to submit questions using the Q&A panel. And we do have a few that have come in over the course of the presentation. I'm going to pose the first one, actually, to you, AM. And the question from one of our attendees is how does CloudFront work with S3? And can you clarify whether CloudFront is a replacement for S3 or something else? AM GROBELNY: Sure, yeah, absolutely. It's a question that I get all the time when people first start working with CloudFront. They're very used to working with S3. S3 is, arguably, one of the easiest AWS services to use. You spin up a bucket, you start dropping bits into that bucket, essentially. And once you kind of go forward, you discover, oh, wow, I can actually serve up static assets, like images, from this, maybe JavaScript files, maybe CSS files, and then, maybe even uncover, oh, hey, I can actually configure this bucket to serve as a static website, additionally too. Now, S3 is a region-based service. So the buckets actually do get stored in one of the AWS regions. So what that means is that when I am utilizing an S3 bucket as a website, it's going-- when I receive a request to serve up assets or that website from this bucket, it's actually sending those assets back to the viewer from a region. And with CloudFront, that extends out these regions into these-- also provide caching and content inside of these points of presence that I mentioned earlier, the 200 points of presence around the globe. So instead of just being bound to that one region, which S3 is also multi-region AWS service, so you could, in fact, replicate two different regions in different buckets. But with CloudFront, that's all taken care of for you. It's pushed out to global locations that you configure. And you can continue storing these assets in one singular S3 bucket, or whatever your business requirements are around that. So it's really, it works in tandem with S3 as one of the origins that you can set for your CloudFront distribution. It's not a replacement. It just is a way to globally distribute things that you're storing in these S3 buckets. So hopefully that answers that question. DAVE ARMLIN: AM, this is Dave Armlin, that was very helpful. And to kind of bring it full circle into ChaosSearch, so in your presentation, checking off that bucket, or that checkbox relative to logging. As people hit those assets that are being cached out on the Edge with CloudFront, you can then harness value out of the log stream that comes into an S3 bucket to see what are the axis patterns at the Edge or other things that you might want to know about as this Edge service is providing value for the customers and user experience. So just wanted to kind of full circle. And I think that that's a great marriage between the two technologies. AM GROBELNY: Yeah, totally that's a really, really good point to hit home. So when you create a CloudFront distribution to globally distribute content, let's say, from an S3 bucket, not to confuse the subject matter here, but, yeah, you just click-- through the CLI, you can set up automatic logging from your CloudFront distribution. So every viewer request that comes in to one of your distributions then gets logged to an S3 bucket in those log files that I mentioned earlier. And yeah, turning on ChaosSearch and indexing that bucket where you're storing these CloudFront an access logs is a really easy way to get immediate insight into who are my viewers. What types of things are my viewers requesting? Anything that's captured in that log data, which a lot of information, a lot of data, would be easily traversable once you've actually loaded that access log bucket into ChaosSearch. INTERVIEWER: Hey, everyone. Sorry about that. We dropped our audio momentarily. I'm going to move on now to a couple of questions that have come in. Dave, there's actually two questions here. I'm going to compress them down into one for you. The questions, essentially, are how large is the index that's produced by ChaosSearch and do you need to keep the source data after the index is created in S3? DAVE ARMLIN: Super questions. In terms of the actual index size, the ChaosSearch index is actually a compressed index. So it's actually far smaller than the source data. It rivals gzip in its abilities to get smaller than source data. It can be up to one fifth the size of the source data. For example, in one test we did with elastic load balancer logs, 400 gigabytes of ELB logs reduced down to 80 gigs in our index. So it's much smaller than the index of the source data, that is. And we do not need to source data after the index has been created. So you can delete the source data. Or often, people will push it to Glacier via intelligent tiering or manually. So you don't need to keep the source data around. INTERVIEWER: Great, Thanks, Dave. Jimmy, there's a question here that's posed for you. The question is what are you not doing with Chaos that you're hoping to do in the future? JIMMY MCDERMOTT: Yeah, that's a great question. So we're not currently utilizing the alerting feature to its full capabilities. That's definitely something that is on our, kind of, roadmap as we continue going forward. We operate a very surgey service, in the sense that we'll see lots of requests come in at one time, because maybe an entire school district is logging in in the morning, or something like that. So we have very-- and, even to a degree, unpredictable surges. And so trying to analyze those logs to better understand what that's going to look like on any given day is really important for us. And so the alerting capabilities that comes with the Amazon open distro that ChaosSearch uses are super powerful. And we're planning on implementing that across our entire staff to help with better understanding those moments as the logs come in. INTERVIEWER: Great, thanks very much. So with that, although we do still have a few more questions queued up, but recognizing that we are past the 30 minute mark, we're going to wrap for today. AM, Jimmy, Dave, I really do appreciate your time today, great insights and a great conversation. I would like to reiterate Dave's invite to have everybody come to chaossearch.io, check out our free trial. Just five clicks and five minutes, and you'll be up and running. And you can kick the tires on ChaosSearch and test out some of the great features that we shared here today. So without further ado, thanks, everyone. And have a great rest of your day. ", "uploadDate" : "2021-03-25T17:21:50.000-04:00" } ```