AWS GuardDuty Reviews

We leverage the solution to block anything malicious since it's a threat detection service. GuardDuty allows us to monitor accounts in a much better way. The solution looks for any malicious activity that's going on and will notify you if anything is going on with your AWS accounts. It's not necessarily an IPS because it only alerts you about malicious activity.

The way it monitors accounts is definitely a very important feature. GuardDuty is a threat detection service. The solution looks for any kind of malicious activity or any unauthorized behavior that could breach some problems with accounts. GuardDuty does not just focus on AWS accounts but also on container applications and even Amazon S3 buckets. GuardDuty covers a range of different Amazon resources as part of the protection.

Because it's a threat detection service, they need to keep up with the various threat factors because new threat factors and attack factors come up all the time. Sometimes they may detect a certain behavior. But if that behavior morphs into something else, GuardDuty may not pick up on that specifically if something new comes up which hasn't been found or uncovered before. If Amazon doesn't update the service to reflect that or address that or factor that in, it may not detect the threat. The end user then is obviously at the mercy of whatever it flags. GuardDuty must ensure they cover everything, including the latest threats.

I have worked with AWS GuardDuty for close to four years. Our version is up-to-date.

There hasn't been a stability issue yet, so I rate the stability an eight out of ten.

With scalability, it helps to factor in additional resources and workloads. I'd rate the scalability an eight out of ten. About five users are using AWS GuardDuty. Only people who are monitoring threats are using the solution.

I rate the initial setup an eight out of ten. I think it's more on the easy side. Regarding steps taken for deployment, the first step was creating a cloud trail, like an AWS Cloud trail. The other step was setting up the VPC flow logs. The third step was setting up the DNS logs. If everything is in place, deploying the solution could take as little as half a day.

You'd need someone who manages the cloud infrastructure, and they'll have to do it because GuardDuty needs the cloud trail created along with the VPC logs and everything. 

Depending on the breadth of the infrastructure, you could have a small team of people maintaining the solution. The challenge would be that once you operationalize it, and if anything gets flagged or notified, you need people to be able to jump on it. Typically, if you have people in different time zones, a team would help. But this depends on the nature of what comes up in the notifications. 

When it comes to looking for threats and catching those early on so that it doesn't lead to something in terms of an incident or a breach, we see a critical ROI. The more and earlier they notify, the better and less painful it is to investigate and take care of things.

GuardDuty only enables accounts in regions where you have an active workload. If there are places where you don't have an active workload, you wouldn't even enable them. That's one area where they could allow you to cut down your cost. In terms of giving you flexibility, the pricing is good. If, for example, I feel that something doesn't need to be in a certain region, I won't enable it. It would help with that whole setup because that model helps save money.

I rate the solution a nine out of ten.

AWS initially interested me more from the architecture and direction perspective, rather than DevOps, for instance. I wanted to gain expertise in the wide range of services they offer, one of which is GuardDuty. It's not my main focus, but it's a good basic threat detection starting point. 

Whenever we need some kind of service for threat detection, we go to one of the many options in the vast AWS cloud portfolio. We pick GuardDuty to protect our endpoints, and it's a good first-line solution for quick deployment. 

Once we have experience using this AWS offering, we'll likely start looking deeper. We might then go to the marketplace to find another, potentially third-party solution. 

For AWS, there are other services online that I would go to and compare features with to determine the best option for my initial needs. The point is, once we need these kinds of services on a larger scale, we probably need a bigger partner or client-customer base to work with. 

From my perspective of educational purposes and cloud development approach, it's not there yet. I have some initial insights about helpful features in GuardDuty, but I don't yet have the clientele to apply them to large-scale infrastructure protection. That's where I would explore threat detection and endpoint protection further, especially since global threats.

For vulnerability checking, I have other integrations that help my development pipelines build securely. My images and code are typically scanned every time to ensure I'm not harboring internal vulnerabilities. 

However, protecting the external perimeter requires something bigger, and that's where Palo Alto Cortex XDR and similar products come in. Here, for threat detection, my browser has an add-on, which is truly helpful. Every time you access a page, it scans it immediately, flagging potential threats, even false positives, to alert you before you dive deeper into an unfamiliar site.

The problem of scale is very fundamental to me. Over the past five or ten years, since the emergence of cloud infrastructure and the proliferation of distributed software products, I've been focused on developing backends for various solutions. The rise of cyber threats prompted me to consider how to protect the endpoints exposed to clients. 

With numerous endpoints today, as we deploy every version of our software, often multiple times a day, ensuring that none of them becomes a target is crucial. For such large-scale infrastructure protection, my preference would be to explore another AWS offering. Specifically, if my deployment is in the Amazon cloud, I would turn to AWS Shield.

I started with AWS about six, maybe seven years ago.

I would rate the stability an eight out of ten. 

I would rate the scalability a nine out of ten. For me, it is one of the most scalable thing on the planet. 

The customer service and support are good. They need some room for improvement. There are so many people in support. Sometimes, I get someone who is helpful, and sometimes, they are not helpful. 

So, I don't expect too much from support. But AWS's support is doing the best they could. 

Neutral

I come from working with Microsoft products mainly. Like, starting from, like, desktop applications for office applications and stuff initially. And then, for the clients of the company, I was involved with different industrial kinds of things in, for instance, the Maritime business vertical. This is about shipping and a meter voltage, electrical stuff. So it's basically automation in some way. At the beginning of the century, we were basically doing this in production with Microsoft initially.

At one point in 2006, the cloud emerged. This marked a significant shift in infrastructure management, eliminating the need to purchase racks for data centers on-premises. Instead, we could simply order them from a cloud provider. This paradigm shift caught my attention, leading me to explore the possibilities.

That's why, at some point, I began with the initial cloud provider. Although I also considered others, the first one seemed like a pioneer. Its services evolved into small, versatile solutions for various needs. You don't necessarily have to be familiar with all the services; you can simply explore and find what you need. The landscape is dynamic – today, it looks one way, and next year, it might transform.

The beauty of it lies in its on-demand nature. Minimal installation is required, allowing me to experiment easily. I don't need to know everything upfront; I can go, try, and see what suits your requirements. The cloud provides a flexible and ever-changing environment that aligns with the needs as they evolve over time.

But insights come from looking at what the other vendors are fighting with, and this is where I'm so grateful for the expertise that I see for the future.

AWS is evolving rapidly. When you look at it over a year or the next, it's different because their deployments are constantly changing. AWS is agile, developing rapidly, and features are exchanged regularly. What you did last year might be entirely different today.

One of the advantages of cloud services is the ability to use them on demand. There's minimal installation involved; you can check the latest offerings and make new deployments while dismantling the previous ones. This approach keeps you ahead of potential services, showcasing the agility of AWS.

I prefer to have something on demand for myself. That's why I haven't been paying for GuardDuty specifically. AWS provides a wide range of offerings, especially in the security area. They have various services that integrate into a centralized Security Hub, offering insights into different aspects of security issues, especially in networking and the cloud.

The findings from GuardDuty would be integrated into the Security Hub service, incurring some small costs. I haven't delved into the specifics of these costs, but I know they are minimal. It's like flipping a switch – you integrate GuardDuty to report to the centralized hub, and if something needs attention, you check the GuardDuty findings.

This integration is part of the main central service for security, along with many others, perhaps five or ten. For example, one service scans files in your storage service. Different services may have various agents scanning for different things, like tokens or exposed personal data. It's a unique security issue.

Each service detects findings, and you can integrate them into the Security Hub to keep an eye on all aspects of security. GuardDuty is just one of them. Cost-wise, you pay for what you use, without the need to install or spin up servers. You simply tell the cloud that you want these services integrated for immediate on-demand use.

The pricing may be complex, based on dimensions like the number of findings and protections used. However, maintaining a smaller infrastructure results in fewer findings, reducing costs and eliminating the need for constant investments and running infrastructure all the time, essentially going serverless.

Overall, I would rate the solution a nine out of ten. It is evolving, and at the moment, I will just need it on a larger scale. Then, it will satisfy my demand, initially.  

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.

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.

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.

GuardDuty is predominantly used to find anomalies, particularly security anomalies when trying to probe a hosted public cloud service. For example, we work with Zuora, and have many public services running at AWS, and our concern is external parties. So, if a hacker or an attacker tries to probe our systems, Amazon GuardDuty tries to find anomalies or any vulnerabilities within our systems.

GuardDuty takes multiple sources of logs. In AWS, we have several logging services like AWS CloudTrail and VPC Flow Logs. VPC Flow Logs involve incoming and outgoing traffic from the internet, so if someone tries to get into a system or access one of our publicly hosted AWS, we are able to get that traffic via VPC Flow Logs. AWS CloudTrail is within the public cloud infrastructure, and AWS-specific API calls are involved. So, if someone tries to do some API activity specific to AWS within the infrastructure, this will be a source. These are multiple sources of logs that Amazon GuardDuty consumes as input to analyze the traffic for any security anomalies. So, based on these sources, the solution helps us report findings if security anomalies occur in our systems from the internet or within the cloud infra, cloud account, or AWS account.

AWS is account-specific, and last year, I believe AWS included something related to Kubernetes monitoring or Kubernetes Logs. So if we use EKS within the Kubernetes service and an anomaly occurs, some anomaly traffic is seen in the Kubernetes cluster, and it will be able to identify. That is a good feature they recently added in testable APIs.

Amazon GuardDuty could be better enriched in threat intelligence data. An internal AWS threat intelligence team works 24 hours to enrich customers. That service could be leveraged if there is any new attack, new security vulnerability, or exploitation. Day-to-day hackers find new vulnerabilities, so Amazon GuardDuty should be up to date and help customers find issues.

Kubernetes Logs was missing but is now included. The solution covers most incoming sources in an S3 bucket, storage level, public internet traffic, the cloud infrastructure, the AWS account, and multiple accounts in Kubernetes. So there aren't any missing pieces with Amazon GuardDuty, especially from a monitoring perspective.

Another valuable feature is the delegation service. Even if there are hundreds of accounts, some part of the account is for security, some for DevOps, and some for developers. Certain accounts are assigned within AWS. For example, for Amazon GuardDuty, a master account of the administrator assigns Amazon GuardDuty's administration and full access to our secure account. Once the delegation is done, we work with the tool, the findings, and what it reports to then validate the findings. So, in this situation case, AWS has efficient features.

We have been using this solution for three years. 

It is a stable solution, especially if you compare it to Azure or GCP, so we don't have any complaints about the stability. Other solutions have similar features, but we don't know how enriched those features are.

We have around five people on the security team, and it is very small. However, for large companies like Google or Microsoft that invest a large number of resources, they may have about 50 to 75 people on their team.

Another useful feature is the ability for Amazon GuardDuty to manage hundreds of accounts. There is usually a master account, and the remaining 99 accounts are member accounts. So if you push an order via the master account everything takes place in those 99 member accounts. Most companies don't want to give people access to the master account even to their operations, DevOps, infrastructure or development teams.

With Amazon GuardDuty, most of the tools have a delegation feature. So, from the master account, the administrator can delegate administrator access to a security account. So on our security team, we have our account in AWS, which is part of the master account. Under the master account, the administrator will give us access as a delegated administrator. Once the administrator delegates the security account, our five people team takes care of all the tasks around the solution. 

We have full access to configuring, monitoring and automation. The administrator can delegate the DevOps tool or service and the AWS office to the DevOps team account. So the DevOps team can take care of building automation, managing, and administering that particular service around the DevOps service. So, in this case, Amazon GuardDuty is delegated to our security account, and we manage it completely.

Scalability is good. Companies will usually run across multiple accounts in AWS, and their resources run about a hundred accounts. However, one of the past companies I absolved ran close to a thousand accounts, and in that situation, the Amazon GuardDuty scalability factor was important. 

Also, suppose a company is not leveraging AWS Organization which is very rare, AWS still provides risk APIs or their SD case, where a developer can write a script or automation to deploy seamlessly within a short time. Our security team predominantly uses Amazon GuardDuty. The cybersecurity team monitors the anomalies that occur using Amazon GuardDuty.

The technical support is great. I've contacted AWS support multiple times, and they've resolved the query. They have three technical support features, namely chat support, phone support, and web support, where we can raise a query, and they reply to us. Most of the time, we leverage the phone call feature, and once we input our concerns for the queries, they'll reach out to us over the phone and share a chime link screen sharing service. They try to understand our problems and the areas of concern and provide a solution.

The only concern is that it takes some time to assign someone when we reach out for technical support via phone service. It takes at least 45 minutes to get connected, and time is spent on hold waiting for someone to join from AWS.

Deployment does not take long if it is an account-specific or AWS organization level. My company has around a hundred AWS accounts, so deploying across a hundred AWS accounts was pretty easy. AWS also provides AWS Organization, where one account acts as a master, and the rest of the 19 accounts are member accounts under this master. So once you give an order to the master, you can invoke Amazon GuardDuty across all the accounts. So deployment is great, and we didn't face any big challenges.

I rate this solution an eight out of ten. Amazon GuardDuty is a very good service, and we are not planning to change it any time soon.

Regarding advice, it would be good to have data events for Amazon GuardDuty and Kubernetes for monitoring. Data events mean you have an S3 bucket for storing objects or files, and if someone tries to access or monitor those files, API calls will occur, and those transactions will be monitored. So until you enable the data event feature within the Amazon GuardDuty, if someone makes a call at the object or file level, it is something we might miss. Also, there are certain features that are not enabled by default on Amazon GuardDuty.

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.

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.