51–59 of 59 posts
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…
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…
The biggest “hidden” cost for me was Elastic Blockstore IO charges! It started adding up quite quickly and I realized I had to think twice about doing IO intensive calculations on EC2! I switched over to lightsail (obviously these are for personal projects).
Earlier quoted context omitted.
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?
“Fire all your ops people do the cloud” has made it so that organizations have forgotten how to run servers.
Working in infra but not at supermassive scale does really feel like the new COBOL programmer.
> 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.
VPC flow logs are odd, too: you actually don’t need to enable them for Guard Duty - one of its selling points is that you can globally enable it without the possibility of one of your organization’s accounts having it disabled due to accident or malice – but again, if your security policy requires this there’s no shortcut for any tool: you can get figures quickly before you run through the free tier and use those for your budgets.
The DNS logging points are handled by separate products: if you want those features, check out the Route 53 resolver logging and firewall docs:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/re...
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/re...
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…
Until you realize how much the alternatives cost. You think Palo Alto networks is cheap?
Earlier quoted context omitted.
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-...
These products have their place, but they don't make sense until you reach a certain size.
Earlier quoted context omitted.
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.
Fargate should allow users to specify their compute requirements beyond just vCPU count and GB memory.
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…