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

41–50 of 59 posts

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

#41

Post by JCM9 »

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…

I hear you but how is this any different than any alternative approaches? I mean yes you could throw a server under your desk and it would be cheaper. Should you run a server in prod with sensitive workloads without all these extra security bells and whistles (on prem or in the cloud)? No. No you should not. Compared to alternative security appliances and offerings this is still a good deal.

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

#42

Post by gredrotino »

m1keil wrote: post #20
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…

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…

Have you checked out Cost Anomaly Detection[1]? It builds an ML model to alert on anomalous usage and resulting changes in billing.

[1] https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-...

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

#43

Post by Cthulhu_ »

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…

Managing and occasionally slashing costs is why AWS consultants can make really good money - if you're into this kinda thing, it's worthwhile learning how to analyze and optimize AWS bills.

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

#44

Post by Jensson »

JCM9 wrote: post #41
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…

I hear you but how is this any different than any alternative approaches? I mean yes you could throw a server under your desk and it would be cheaper. Should you run a server in prod with sensitive workloads without all these extra security bells and whistles (on prem or in the cloud)? No. No you should not. Compared to alternative security appliances and offerings this is still a good deal.

> Should you run a server in prod with sensitive workloads without all these extra security bells and whistles (on prem or in the cloud)? No. No you should not.

Why not? Have people forgotten how to run servers in the past decade?

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

#45

Post by Jensson »

marcinzm wrote: post #37
yrgulation wrote: post #25

AWS managed to make things so much easier and cheaper compared to “classic” hosting that you now need twice as many devops employees and spend 10x in bills. Fortunately tech people aren’t financially literate so amazon can keep on squeezing all the while using free software made by the very same people. Congrats.

I actually remember the old days and no bloody thank you. Sometimes you got arcana processes managed by barely technical sysadmins so it took you 5 months to get a VM and 2 months to reimage it if you broke it. Other times you got a free for all where every engineer configures an insecure never updated server that eventually gets hacked. Then you get paged at 2am when the thing explodes and get to spend two days rebu…

Depends on the skill of the employees. If you have mostly juniors and people who don't care then AWS is a godsend. If you mostly hire capable seniors to lead and ambitious juniors to follow then you can run things the old way just fine.

My first job had only incompetent seniors that I had to explain SQL query performance to etc. I left very quickly since I realized I wouldn't learn much there. I can see such places benefiting greatly from AWS services.

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

#46

Post by OJFord »

arinlen wrote: post #36
OJFord wrote: post #29

Earlier quoted context omitted.

> Fargate is a little expensive for what we are running Because of low usage? Lambda supports containers now (as of 2021 I think) so if you have a container to run (or something you could containerise) it's a relatively straightforward usage question which of Lambda/Fargate/EC2 makes sense on price. Lambda doesn't have to complicate comparison by being a completely different architecture/setup any more.

> Lambda supports containers now (...) The usecases for Fargate vs Lambda are not the same. For instance, Fargate is mainly intended for servers/long-running applications, whereas Lambdas have a hard runtime cap of 15min.

Why is that incompatible with it being a matter of usage, as I said?

Lambda makes sense when usage is a small fraction of the day; 'long-running applications' are not that.

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

#47

Post by bnchandrapal »

thedougd wrote: post #38
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 recommend AWS Control Tower for getting this all setup. It's also compatible with Terraform in more than one way.

Ahhh. AWS Control tower has not cost but it requires AWS Config to be enabled. Config is yet another AWS service that can get costly over time (if continuous monitoring of changes is enabled)

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

#48

Post by Jensson »

Cthulhu_ wrote: post #43
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…

Managing and occasionally slashing costs is why AWS consultants can make really good money - if you're into this kinda thing, it's worthwhile learning how to analyze and optimize AWS bills.

Well, before AWS big companies tended to have the same problem, but instead of paying for many AWS features they paid for a thousand different products and trying to make sense of all those bills for each product was hard. I know some people who worked as consultants to clean up all the services the company was paying for but didn't really need any longer, paying for around thousand different software products was the norm and not some unrealistically large number.

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

#49

Post by OJFord »

shitlord wrote: post #39
OJFord wrote: post #29

Earlier quoted context omitted.

> Fargate is a little expensive for what we are running Because of low usage? Lambda supports containers now (as of 2021 I think) so if you have a container to run (or something you could containerise) it's a relatively straightforward usage question which of Lambda/Fargate/EC2 makes sense on price. Lambda doesn't have to complicate comparison by being a completely different architecture/setup any more.

No, the cost of a Fargate vCPU is just higher compared to EC2. An EC2 t3.small instance costs about 2 cents/hour and a similar configuration on Fargate costs about 9 cents/hour. For m6i.large and c6i.large instances, the disparity isn't as bad but it's still 15%-20% more expensive. There are a few different reasons we're using Fargate. Like the other commenter mentioned, there's the lambda max run time. Our Fargate t…

Of course it is, if it were cheaper then it would always win over EC2 for container workloads.

This is why I said it's a matter of usage - it's worth paying more per unit time if it's running less and more sporadically making it cheaper over all.

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

#50

Post by marcinzm »

Jensson wrote: post #45
marcinzm wrote: post #37

Earlier quoted context omitted.

I actually remember the old days and no bloody thank you. Sometimes you got arcana processes managed by barely technical sysadmins so it took you 5 months to get a VM and 2 months to reimage it if you broke it. Other times you got a free for all where every engineer configures an insecure never updated server that eventually gets hacked. Then you get paged at 2am when the thing explodes and get to spend two days rebu…

Depends on the skill of the employees. If you have mostly juniors and people who don't care then AWS is a godsend. If you mostly hire capable seniors to lead and ambitious juniors to follow then you can run things the old way just fine. My first job had only incompetent seniors that I had to explain SQL query performance to etc. I left very quickly since I realized I wouldn't learn much there. I can see such places b…

>If you mostly hire capable seniors to lead and ambitious juniors to follow then you can run things the old way just fine.

Or you can run them even better on AWS assuming you had the same level of competence except in cloud deployments. Granted they'd probably pick a more specialized cloud platform than AWS for the specific problems and scale of the team.

Post reply on HN