Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS GuardDuty – the Good, the Bad, and the Ugly

badshah.io

Post reply on HN
Print view View original

11–20 of 59 posts

Re: AWS GuardDuty – the Good, the Bad, and the Ugly

#11

Post by philliphaydon »

m1keil wrote: post #2

GuardDuty is another example of brilliance of AWS pricing scheme and how they manage to twist your hand to pay extra which can cost quite a lot in the end of the month. When comparing EC2 to servers, nobody adds the added premiums of the extras. Things like CloudTrail, Support, GuardDuty, CloudWatch. All of these things have a variable cost that grows with usage and very hard to predict ahead of time. Just last week…

Na. At some point you scale to the point that $400/m is peanuts for the benefits you get.

We used it at previous job and realised we were under constant attack and and it reduced our cou usage by 15% in reduced requests for the amount of traffic we were getting. No more random spikes.

Improved our overall security and ultimately reduced costs on the AWS bill.

But if you’re gonna switch it on and walk away then you’re not really using it.

Re: AWS GuardDuty – the Good, the Bad, and the Ugly

#12

Post by m1keil »

philliphaydon wrote: post #11
m1keil wrote: post #2

GuardDuty is another example of brilliance of AWS pricing scheme and how they manage to twist your hand to pay extra which can cost quite a lot in the end of the month. When comparing EC2 to servers, nobody adds the added premiums of the extras. Things like CloudTrail, Support, GuardDuty, CloudWatch. All of these things have a variable cost that grows with usage and very hard to predict ahead of time. Just last week…

Na. At some point you scale to the point that $400/m is peanuts for the benefits you get. We used it at previous job and realised we were under constant attack and and it reduced our cou usage by 15% in reduced requests for the amount of traffic we were getting. No more random spikes. Improved our overall security and ultimately reduced costs on the AWS bill. But if you’re gonna switch it on and walk away then you’re…

Yes of course, $400/month is peanuts so does $8000/month for certain companies.

The point is not the absolute sum but how easy is it to spike your bill by 30 times.

The way GD works, you are pretty much guaranteed to overpay for it sooner or later. If you can afford it.. great.

Re: AWS GuardDuty – the Good, the Bad, and the Ugly

#13

Post by solatic »

> Disable access to services in all non-active regions using SCPs.

This is key advice anyway. When setting up new AWS infrastructure for a new company, set up an AWS organization, and only enable us-east-1 (required for some global services like CloudFront) and maybe one additional region (if you don't want to put all your eggs in the us-east-1 basket). Don't enable additional regions that you don't need. Because most AWS APIs are regional, it makes finding aberrant infrastructure much, much easier, even if you're just combing through the console manually.

Re: AWS GuardDuty – the Good, the Bad, and the Ugly

#14

Post by fomine3 »

judge2020 wrote: post #3

> The Ugly > Cost can get sky-high Is there _any_ service on AWS where you feel like you're getting more value than the dollars you're paying with (other than IAM and Free tier services)? It's no secret that AWS is one of the most successful and profitable modern businesses, but perhaps there's a hidden offering that does something, does it well, and costs very little compared to the value it brings.

Route 53

Re: AWS GuardDuty – the Good, the Bad, and the Ugly

#15

Post by philliphaydon »

m1keil wrote: post #12
philliphaydon wrote: post #11

Earlier quoted context omitted.

Na. At some point you scale to the point that $400/m is peanuts for the benefits you get. We used it at previous job and realised we were under constant attack and and it reduced our cou usage by 15% in reduced requests for the amount of traffic we were getting. No more random spikes. Improved our overall security and ultimately reduced costs on the AWS bill. But if you’re gonna switch it on and walk away then you’re…

Yes of course, $400/month is peanuts so does $8000/month for certain companies. The point is not the absolute sum but how easy is it to spike your bill by 30 times. The way GD works, you are pretty much guaranteed to overpay for it sooner or later. If you can afford it.. great.

One thing that we noticed was after switching it on, the EC2 instances were being hit directly, so we moved those into a private security group only accessible to the load balancer. RDS got restricted. S3 buckets fixed. Coupled with AWF to block on inregular activity, resulted in GD bill going down, not up.

This is no different from programming. PHP has some awful code out in the wild, it doesn't mean PHP is shit just because people write bad code.

The issue with AWS is it's far too easy for people to just spin stuff up and it works and they don't look at what they are being billed for, don't analysis their infrastructure, don't optimize. They just throw servers, containers, etc up into the wild then when the bill comes:

"OH AWS BAD I got billed cos I just set it up and forgot about it, then when it worked they charged me for it, AWS is wrong, just go baremetal."

Re: AWS GuardDuty – the Good, the Bad, and the Ugly

#16

Post by didip »

solatic wrote: post #13

> Disable access to services in all non-active regions using SCPs. This is key advice anyway. When setting up new AWS infrastructure for a new company, set up an AWS organization, and only enable us-east-1 (required for some global services like CloudFront) and maybe one additional region (if you don't want to put all your eggs in the us-east-1 basket). Don't enable additional regions that you don't need. Because mos…

I would not start by default in us-east-1, unless you want chaos monkey as a feature.

Re: AWS GuardDuty – the Good, the Bad, and the Ugly

#17

Post by didip »

judge2020 wrote: post #3

> The Ugly > Cost can get sky-high Is there _any_ service on AWS where you feel like you're getting more value than the dollars you're paying with (other than IAM and Free tier services)? It's no secret that AWS is one of the most successful and profitable modern businesses, but perhaps there's a hidden offering that does something, does it well, and costs very little compared to the value it brings.

Just get the fundamentals:

- Some core databases.

- Compute in the form of EC2 or EKS with EBS.

- IAM roles.

- Secrets management.

- Load balancers.

- S3.

That’s basically it. Build the rest yourself, they tend to be cheaper.

Re: AWS GuardDuty – the Good, the Bad, and the Ugly

#18

Post by bnchandrapal »

philliphaydon wrote: post #15
m1keil wrote: post #12

Earlier quoted context omitted.

Yes of course, $400/month is peanuts so does $8000/month for certain companies. The point is not the absolute sum but how easy is it to spike your bill by 30 times. The way GD works, you are pretty much guaranteed to overpay for it sooner or later. If you can afford it.. great.

One thing that we noticed was after switching it on, the EC2 instances were being hit directly, so we moved those into a private security group only accessible to the load balancer. RDS got restricted. S3 buckets fixed. Coupled with AWF to block on inregular activity, resulted in GD bill going down, not up. This is no different from programming. PHP has some awful code out in the wild, it doesn't mean PHP is shit jus…

Out of curiosity, did you have any data lakes on S3? Did you find optimization techniques for the same?

Re: AWS GuardDuty – the Good, the Bad, and the Ugly

#19

Post by philliphaydon »

bnchandrapal wrote: post #18
philliphaydon wrote: post #15

Earlier quoted context omitted.

One thing that we noticed was after switching it on, the EC2 instances were being hit directly, so we moved those into a private security group only accessible to the load balancer. RDS got restricted. S3 buckets fixed. Coupled with AWF to block on inregular activity, resulted in GD bill going down, not up. This is no different from programming. PHP has some awful code out in the wild, it doesn't mean PHP is shit jus…

Out of curiosity, did you have any data lakes on S3? Did you find optimization techniques for the same?

Nope, but did realise we had some open buckets we didn't realise were open. Thankfully we didn't store sensitive information in there despite having 2PB of files in there.

Re: AWS GuardDuty – the Good, the Bad, and the Ugly

#20

Post by m1keil »

philliphaydon wrote: post #15
m1keil wrote: post #12

Earlier quoted context omitted.

Yes of course, $400/month is peanuts so does $8000/month for certain companies. The point is not the absolute sum but how easy is it to spike your bill by 30 times. The way GD works, you are pretty much guaranteed to overpay for it sooner or later. If you can afford it.. great.

One thing that we noticed was after switching it on, the EC2 instances were being hit directly, so we moved those into a private security group only accessible to the load balancer. RDS got restricted. S3 buckets fixed. Coupled with AWF to block on inregular activity, resulted in GD bill going down, not up. This is no different from programming. PHP has some awful code out in the wild, it doesn't mean PHP is shit jus…

I think it is similarly easy to spin it the other way around. "AWS is just selling you the gun and the bullets, you are the one who is shooting yourself in the foot".

I don't think I said AWS is shit or that GD is worthless, after all, I use both by choice. Yet, I do not think that AWS are blameless when it comes to certain decisions of how to bill, how to present data and how to document some of their features.

For example, in order to discover something is wrong with your GD billing, you must have CloudTrail in place, and the appropriate infrastructure to query it. And even tho AWS can easily alert you about weird trend in your API calls (like suspiciously high Describe*), they won't do it. They do it with Trusted Advisor when you have under-utilised EC2 instances (which requires Business+ support plan per account).

Someone mentioned in the thread the need for SCP in order to disable regions. Why should you have go all the route to SCP? Why can't we disable regions by click of a button under root account like it's possible for some of the latest regions?

Is something inherently wrong in it and pure evil? No. But I think the defaults can be better. I think AWS can improve their customer's default posture when it comes to Audit and Security without the need to have to decide between 10 different services with different billing plans and gotchas.

Post reply on HN