AWS GuardDuty Reviews

I mainly use GuardDuty to check user responses, collect logs, and collect data on who logs in and out and their permission and authorization. 

Prior to using GuardDuty, we had multiple systems to collect data and put it in a centralized location so we could look into it. Now we don't need to do that anymore as GuardDuty does it for us.

The most valuable features are the single system for data collection and the alert mechanisms.

An improvement would be to have a mobile version where remote workers can log in and monitor and fix issues. In the next release, I'd like Amazon to add a pane to visualize all seven layers of security.

I've been using GuardDuty for two to three years.

GuardDuty's stability is really good - we never see outages or falls in networking or BPC connections.

GuardDuty is really scalable, which is helping us to upscale our environment to the cloud. I really appreciate the scalability measures that Amazon is providing to all its customers.

We've had enormous support from the Amazon support team.

Positive

Previously, I used GCT.

GuardDuty is set up through a one-touch system, so the process was simple.

We used the AWS team to do our workload, publishing, and so on, so it took about a quarter of the time it would have otherwise.

We use a pay-as-you-use license, which is competitively priced in the market.

I'd rate GuardDuty as nine out of ten.

We primarily used Amazon GuardDuty for threat detection because we have AWS accounts we wanted to monitor and we wanted a solution that could detect any kind of threat. We ended up leveraging the native tool of AWS which was Amazon GuardDuty, and we used it for monitoring our AWS accounts. It was used for looking for any kind of malicious activity, and any workloads that might have any malicious activity, and it was also used for reporting purposes. Amazon GuardDuty helped in our whole security incident response process. We were analyzing logs with it, for example, the event logs. We were reviewing any kind of potential risks that we might face and would need to accordingly take action on, through Amazon GuardDuty.

What we found most valuable in Amazon GuardDuty is its threat detection feature, especially because we were monitoring a huge number of AWS accounts, so we needed a solution that would monitor for any kind of malicious activity. The monitoring aspect of the solution was great because it gave us timely notifications if and when anything happened, and Amazon GuardDuty helped keep us on our toes to make sure we took action right away.

Some of the pain points in Amazon GuardDuty was the cost. When compared to some of the other services, depending on how many we had to monitor, if we had a huge range of accounts, as our accounts increased, we had a cost factor that came into play.

Sometimes there were issues, for example, with findings that came up, we wanted to add notes and there were issues back then where notes couldn't be entered properly. If we wanted to leave a note such as "Okay, we have assessed this and this is how we feel", or "This is a false positive", Amazon GuardDuty wasn't allowing us to do that. Even with the suppression of certain findings, there was some issue that we had faced at one time.

Those were some of the pain points of the solution.

I have four and a half years of experience with Amazon GuardDuty.

Amazon GuardDuty was fairly stable. Except for those few pain points, it was fairly stable because we were constantly checking for things that would come up and what it would flag, even when we had to reach out to Amazon support for certain things, they were fairly responsive. There wasn't any outage or any significant downtime while we were using Amazon GuardDuty. There might have been just a little bit of performance degradation, but it wasn't a complete "black hole".

Amazon GuardDuty is a scalable product. It manages to scale accounts. I don't recall the exact number of accounts, but my company definitely had way more accounts. Over time, Amazon GuardDuty matured as a product. In the beginning, it wasn't as scalable as you would expect, but over time, the way the product was improved, it was able to meet kind of any kind of scaling demands. The environment in my company was also growing and had more accounts getting added to it, so my company needed Amazon GuardDuty to accommodate everything, and in my experience, I have not faced any issues, even when I had a much larger coverage done. The product is designed to meet decent scaling demands, at least.

The technical support for Amazon GuardDuty was pretty responsive. Compared to many other vendors that I've used, AWS support, in terms of the SLA, has been fairly good about getting back on that. AWS claims to provide 24/7 access to customer service, so typically, whenever I've reached out, I've received a response fairly quickly. The support team acknowledges the request and will act on it. I've never had any trouble. I hardly remember ever escalating to the customer support manager, some specific, or some general support issue. There was rarely a case where an escalation had to happen, and for the most part, it was working out.

The initial setup for Amazon GuardDuty was straightforward. I don't remember it being complex at all. One had to sign in to the AWS Management Console, for example, my company had this audit account I would sign into, then I would navigate into the Amazon GuardDuty console, then I would just choose the account that I wanted to be added to as part of that, and then it will be managed and monitored by the Amazon GuardDuty admin account. I remember it being fairly straightforward. The setup wasn't difficult.

In terms of ROI from Amazon GuardDuty, we're getting threat detection or intelligent threat detection, and that's the key thing. As we are in a security environment, our customers are also demanding for better security posture. We can't put ROI quantitatively into words, but qualitatively, the ROI from Amazon GuardDuty goes towards improving our overall security posture. There's ROI from the solution because it would translate into the improvement in security posture which then translates into the trust we gain from our customers, so more customers would be interested and potentially get services or solutions from us, resulting in a win-win situation.

In terms of the costs associated with Amazon GuardDuty, it was $1 per GB from what I recall. Pricing was based on per gigabyte. For example, for the first five hundred gigabytes per month, it'll be $1 per GB, so it'll be $500. If your usage was greater, there's another bracket, for example, the next two thousand GB, then there's an add-on cost of 50 cents per GB. That's how Amazon GuardDuty pricing slowly goes up. I can't remember if there was any kind of additional cost apart from standard licensing for the solution. Nothing else that at least comes to mind.

What the service was charging was worth it. That was one good thing when using Amazon GuardDuty because my company could be in a certain tier for a certain period. My company wasn't under a licensing model where it could overestimate its usage and under-utilize its usage and pay much more. This was what made the pricing model for Amazon GuardDuty better.

I'm working with different solutions, and right now, I'm dealing with software composition analysis solutions, static application security testing tools, and even dynamic application security testing tools. I'm also working with API security or cloud security solutions. There's a range of tools I'm working with, including Amazon GuardDuty.

Ten to fifteen people use Amazon GuardDuty in my company. It's not a huge number of people, but there's a given number of people with access to the solution, who'll be able to go in and check. The users are mostly system administrators who can take action. My company goes by role-based access control in the environment, using the principle of least privilege in every case. It's to make sure whoever is given access is based on what he or she does, and based on user responsibilities. Access to Amazon GuardDuty is limited to a small group of people, or just certain users, specifically, people you'll reach out to if something happens, such as system administrators, IT administrators, and security administrators.

My advice to others looking into implementing Amazon GuardDuty is to try to add coverage over all your AWS accounts. I would recommend the solution for every AWS account that anyone owns or uses. It's best to get all your accounts centralized and added under the coverage of Amazon GuardDuty because you want to protect those accounts, check for any malicious activity, and add those accounts to continuous monitoring. Never skip out on anything. The solution also gives you one place where you can go in and find out how many AWS accounts you have, what kind of accounts you have, and whether you want to shut down accounts that are no longer in use. There's a lot of security that Amazon GuardDuty can provide, and it also helps in maintaining security hygiene.

I would rate Amazon GuardDuty eight out of ten because I did not face that many issues while using it, and if someone is leveraging AWS, then Amazon GuardDuty is one of the first solutions they should use.

My company has a partnership with AWS as it has a cloud offering that's based on AWS, though it's not a reseller of Amazon products.

It's a malware detection service. It's an intelligent malware and security event detection service from AWS.

The out-of-band malware detection from the EBS volumes. It's really cool. No agents or anything needed, it automatically finds and correlates based on malware.

Cost changes. It's very expensive. If you turn on every feature, it's more than most commercial vendors. For smaller orgs, that doesn't make sense.

I have been using it for two years now. It is an offering in the AWS. 

It is a stable product. 

My company have five to six admins using this solution. 

The initial setup was easy. It was a one-click deployment.

For smaller organizations, it is not expensive. 

If you have a large organization or already have similar tools, it might not be necessary. But for most, GuardDuty is the go-to.

For me, I still use GuardDuty. I see a lot of good correlations built up by AWS support.

Don't add all the features at once. Go step-by-step, or you'll end up with a very high cost and turn off the system.

It can get very expensive. If you turn on every feature, it can turn into hundreds of thousands of dollars.

Overall, I would rate the solution an eight out of ten. 

It helps us detect brute-force attacks based on machine learning. It alerts the security team for possible attacks as well.

The product detects 100% brute force attacks using all legitimate testing methods. It gives the exact source IP of the attacks.

The product's most valuable feature is intrusion detection.

For the next release, they could provide IPS features as well.

We have been using AWS GuardDuty for more than three years.

I rate the product's scalability a ten out of ten. It is a fully managed service. We use it extensively as a mandatory prerequisite for each account we create.

If you have an enterprise plan, they will provide the best support for the entire infrastructure within 30 minutes. For other business plans, they provide limited services.

The initial setup is simple and can be completed in a few minutes. We only have to enable the toggle to use it. I rate the process ten out of ten.

The product generates an ROI in terms of testing and detecting attacks. It informs the possibility of attacks as well.

The platform is inexpensive; It costs approximately $50 a month. However, its pricing is subjective based on the company's requirements. It can go from $10 to $30 to a maximum of $50.

I rate AWS GuardDuty an eight out of ten. It is the best detection system for the applications hosted on AWS.

Most of the time, Amazon GuardDuty is used to collect additional network login requirements, so it's basically in the compliance setting, particularly if you need to collect additional logs, or you need additional protection for your infrastructure in the cloud. Those are the areas where you can utilize Amazon GuardDuty and have it assist with compliance, as it's one of the authorized services for compliance, and it's more than likely the tool to use. For the most part, my organization uses the solution for additional protection within the cloud and also to assist with any additional login capabilities that you can't get through the other services. Amazon GuardDuty fills those gaps and helps facilitate a lot of gaps that you have.

What I like most about Amazon GuardDuty is that you can monitor your AWS accounts across, but you don't have to pay the additional cost. You can get all your CloudTrail VPC flow logs and DNS logs all in one, and then you get the monitoring with that. A lot of times, if you had a separate tool on-premise, you would have to set up your DNS logs, so usually, Amazon GuardDuty helps with all your additional networking requirements, so I utilize it for continuous monitoring because you can't detect anything if you're not monitoring, and the solution fills that gap. If you don't do anything else first, you can deploy your firewall, and then you've got your Route 53 DNS and DNSSEC, but then Amazon GuardDuty fills that, and then you have audit requirements in AU that says, "Hey, what are your additional logs?", so you can just say, "Hey, we utilize Amazon GuardDuty." You're getting your CloudTrail, your VPC flow logs, and all your DNS logs, and those are your additional logs right there, so the solution meets a lot of requirements. Now, everything comes with a cost, but I also like that the solution also provides threat response and remediation. It's a pretty good product. I've just used it more for log analysis and that's where the value is at, the niche value. Once you do threat detection, it goes into a lot of other integrations you need to implement, so threat detection is only good as the integration, as the user that knows the tools itself, and the architecture and how it's all set up and the rules that you set within that.

Improvement-wise, Amazon GuardDuty should have an overall dashboard analytics function so we could see what's in the current environment, and then in addition to that, provide best practices and recommendations, particularly to provide some type of observability, and then figure out the login side of it, based on our current environment, in terms of what we're not monitoring and what we should monitor. The solution should also give us a sample code configuration to implement that added feature or feature request.

What I'd like to see in the next release of Amazon GuardDuty are more security analytics, reporting, and monitoring. They should provide recommendations and additional options that answer questions such as "Hey, what can we see in our environment?", "What should we implement within the environment?", What's recommended?"

We know that cost will always be associated with that, but Amazon GuardDuty should show us the increased costs or decreased costs if we implement it or don't implement it, and that would be a good feature request, particularly with all products within AWS, just for cloud products in general because there are times features are implemented, but once they're deployed, they don't tell you about costs that would be generated along with those features. After features are deployed, there should a summary of the costs that would be generated, and projected based on current usage, so they would give us the option to figure out how long we're going to use those features and the option to keep those on or turn those off. If more services were like that, a lot more people would use those on the cloud.

I've used Amazon GuardDuty for a year, and I've used it with other organizations as well.

Amazon GuardDuty has wonderful stability. My organization is currently using it in the production environment and it works really well. A lot of companies I know are using it, and I've been a third-party assessor before, and the companies I know implement the solution along with Cloud Trail and CloudWatch to get that observability, and then if you decide to do threat response and you want to tag an MSSP provider, all you have to do is link into Amazon GuardDuty, and that's it, you're done. The solution has its pros and cons.

Amazon GuardDuty is a scalable solution. My organization didn't have a problem with adding users. What's been challenging is doing it through infrastructure as code, but just regular added users should be straightforward and easy to do.

I haven't had to use technical support for Amazon GuardDuty yet. Maybe somebody else used it for integration help, for example, to just try to make another integration work with it, but that's about it. A lot of times it would be "Hey, I don't understand that portion of the integration", so you've got to contact support and the code was messed up because a lot of times, in one development or one product, if the codebase is changed and it's not connecting, it could be a coding issue. Eighty percent of the time, you're changing a code issue in a pipeline, a code data integration, or an issue with the API. Most of the time that's the issue.

My organization decided to go with Amazon GuardDuty because most of the infrastructure resides in AWS, so it was just a lot easier for compliance purposes to go with that to get the additional observability for the additional logs that are required.

How easy the initial setup for Amazon GuardDuty all depends on the architecture. If you're deploying this right out of the box, it's easy. A lot of times you want to implement your firewalls and more complex requirements going forward and it just depends on where you set it up in your architecture. It could be more complex if you're dealing with certain requirements, but more than likely, it's self-explanatory. Sometimes, depending on the integrations you're using with the solution, the integrations can be always complex because you're trying to implement Amazon GuardDuty logs to Qualys, for example. The complexities occur during integration and that's usually true for most products.

I had to implement Amazon GuardDuty with Qualys, and the integration was painful because Qualys didn't accept it, but Amazon was right for it, but then the other provider makes it more challenging. Utilizing and using infrastructure as code is a whole challenge itself as well, so if you do it just regular based, you'll think you're okay, and my current organization has that problem because my organization wants to implement infrastructure as code and that's great, but if you see that you're having problems with the modules, then you shouldn't use infrastructure as code, but if that's what my organization wants to do, I just let the DevOps team deal with that. As long as the solution is deployed and I can get observability of the environment, that's all that matters to me.

I don't have all the details in terms of licensing for Amazon GuardDuty, but my organization does have a license set up for it.

I use the latest and greatest version of Amazon GuardDuty that's available on the market.

The number of users of Amazon GuardDuty in my organization is between one to ten. Per my boss, it's a maximum of ten.

My advice to someone who wants to use the solution for the first time is that you've got to establish your use case. What are you going to use it for? Focus on that area, and then I would also implement a proof of concept to make sure that it's set up in your staging environment where you can do all your testing and get all your test results. Depending on what you can implement, make sure your integrations work, and the other tools you have you should also integrate with Amazon GuardDuty in your testing, so when you go to production with it, you would understand the ROI for using the tool.

A lot of times, you always want to have a centralized view of everything in your environment. What you don't want is when you have to go to this tool and then go to that tool, and it's just so much. You already have to do MFA just to get into it, and then once you're in, you'd want to see your whole environment and just get all your touchpoints, so integration is the key component to test within Amazon GuardDuty.

I would rate Amazon GuardDuty seven out of ten because some of the integrations may not work well with it, and depending on the integration that you're working with, the security tools have a lot of requirements to implement. Integration support should be a little bit easier, and it just depends on whether you're doing infrastructure as code versus doing just regular batch scripting, or a formation template. The solution has pros and cons.

My organization is a customer of Amazon GuardDuty.

AWS GuardDuty is a monitoring solution. The product helps us in threat monitoring. It notifies us of illegitimate users or any other cyber attack scenarios.

The solution is easy to use. It is very tightly integrated. The insights provided by the tool are very informative. It is easy to work on the alerts created by the tool. It gives us more details on different scenarios. The product is doing well compared to other solutions.

It would be great if the solution had some automation capabilities. It should provide auto-remediation and threat handling with automation.

I have been using the solution since 2019.

I rate the product’s stability a nine out of ten.

I rate the tool’s scalability an eight out of ten. The product is scalable, but it needs a manual intervention. More than 100 people are using the solution in our organization.

The support is always great. The support team is pretty quick. Once we raise a concern, the team jumps into a call and resolves the issues. It hardly takes 15 to 20 minutes.

The initial setup is very simple.

We deployed the solution ourselves. We do not need help from a third-party vendor.

I rate the pricing a seven out of ten. The price of the solution is exactly right. It is neither high nor low. It is a pay-as-you-go model. The more number of accounts we integrate, the more the price will increase.

The product is unique to AWS. I would recommend the solution to others. Overall, I rate the product a ten out of ten.

We use AWS GuardDuty in our company to safeguard our deployment production.

One of the valuable features of the product is the protection of S3 data events, for which, if we use Lacework, then we have to turn it into CloudTrail and feed all the logs to Lacework, which are some steps done by default by AWS GuardDuty. Maybe I can take a step back since, in general, the ability of GuardDuty to natively look at AWS logs or functions and then give protection is something that we think is better than many others.

We currently find Lacework to be much better at detecting vulnerabilities than AWS GuardDuty. The engines of AWS GuardDuty have to be improved.

I have been using AWS GuardDuty for six months to a year. My company is a customer of the solution.

It's a pretty stable tool. Stability-wise, I rate the solution a nine or ten out of ten. I haven't seen it go down yet.

It is a highly scalable solution since it is a service by AWS. Scalability-wise, I rate the solution a ten out of ten.

In my department, three to four people use the solution.

We haven't used the support often, so I don't have an opinion.

Our company uses Lacework and AWS GuardDuty, and we conducted a comparison to decommission one of the aforementioned products.

Looking at Lacework might be helpful since it provides many other protections or functionalities we have seen lacking in AWS GuardDuty.

The initial setup of the solution was pretty simple.

The solution is deployed on the cloud.

On a scale of one to ten, where one is a high price, and ten is a low price, I rate the pricing a four or five, which is somewhere in the middle. I provided the rating for AWS GuardDutya as four or five out of ten because the pricing would have seemed pretty good if it had more functionalities. Right now, the protection engine isn't that perfect in AWS GuardDuty.

Considering our evaluation process, we think its Lacework is better because of the protection engine it provides.

Overall, I rate the solution a six out of ten.

Our primary use case was to monitor our assets and workloads for abnormal activity.

It kinda just gives us another layer of security. So it does provide some sort of comfort that we do have something that is monitoring for abnormal behavior. 

So it's different from just looking for known signatures. It looks at behaviors in the environment. So it's kinda like an alternative security vector, plus.

For me, the most valuable feature is the behavior analysis. It looks at security from a different perspective.

For me, I would say just the presentation of findings, like the dashboards and other stuff, could be improved a bit. So, the presentation of findings could be improved a bit.  

I have been using this solution for a year. 

I have never faced any issues. So, I would rate the stability an eight out of ten.

I would rate the scalability an eight out of ten. 

The initial setup was pretty straightforward.

We have seen an ROI. It has helped with some things.

Overall, I would rate the solution a seven out of ten.