Live data from Hacker News

AWS costs every programmer should know (2019)

david-codes.hatanian.com

71–80 of 163 posts

Re: AWS costs every programmer should know (2019)

#71
post #27
post #16

Earlier quoted context omitted.

Indeed, this is often the next step. The new architect must have lots of AWS certifications. With the new architeture, the long term cost savings will be exponential, compared to the current projected cost curve! This can optionally combine with the Kubernetes scenario.

> This can optionally combine with the Kubernetes scenario. Some people like to poke fun at the expense of kubernetes, but if they did any professional work, at the first failed deployment they would sell their firstborn to have something similar to kubernete's deployment rollback feature.

We don't use kubes. Deployments sometimes fail and we deploy the old versions easily. No firstborns sold.

I have used kubernetes blue/green deployments in an old job and it was beautiful. But to say kubernetes is that much better compared to rsyncing your executables to the server and restarting the service is plain wrong. It's a bit easier and a bit more declarative, sure, but manual rollbacks were a thing fifty years ago and still are.

Re: AWS costs every programmer should know (2019)

#72
post #14

Network Egress always gets a bad rap but recently it's the SSD cost on AWS/GCP that has me upset. IMO storage needs to take on some of network egress's heat :) $0.10 per GB-month for a basic SSD is outrageous compared to Hetzner et. al. a 4TB SSD for a month costs $400 on the big guys and like $50 on the commodity providers. It's not even a managed service!

EBS is a managed service with very high redundancy (3/5 copies of your data, I don't recall). Hetzner's SSD is just that, an SSD.

Re: AWS costs every programmer should know (2019)

#73

Earlier quoted context omitted.

If you’re building your own infrastructure in a data center then sure you absolutely want to test your redundancy. But with AWS it’s a checkbox. It’s transparent to you and your applications. The infrastructure to host in multiple AZs is already in place. The only real issue with MultiAZ is the failover in RDS depending on the database you use could be seconds or 10s of seconds.

Back in colo days, I saw a lot of post-mortems that read “the thing we thought was redundant wasn’t”, leading me to call them “redundant like an appendix [rather than like a kidney]”. We instituted quarterly “game day testing” where we forcibly turned off one of the redundant items in all of our systems. It took us about 6 such cycles before these tests didn’t turn up outages that were just waiting for us. Thinking b…

> Thinking back on those, it’s hard for me to believe that most cloud hosted companies are prepared by checking a box without actually testing.

We are talking about MultiAZ, Availability Zones. Not different regions. Setting up redundancy across regions is not easy. But for majority of the people using AWS a single region with MultiAZ is good enough.

Re: AWS costs every programmer should know (2019)

#74
Also should be included is license costs. It's easy to forget that special feature you are using in SQL Server or Oracle can increase you to a much higher license. Main areas for concern for license costs are DB and windows server.

Also DevOps people are not cheap. You need to factor in implementation and maintenance. I could be using that money on a bigger server with less complex infra.

Re: AWS costs every programmer should know (2019)

#75
post #70
post #47

Earlier quoted context omitted.

> Above free tier AWS Lambdas are terribly expensive when compared with EC2 alone. You're charged per RAM*time, you're charged per concurrent execution, and if your Lambda times out you have to pay for the re-execution. They are dirt cheap for many use-cases where you application only runs a few times a day/hour and you need ad-hoc scalable performance. For example processing/creation of csv-reports - which is a comm…

> They are dirt cheap for many use-cases where you application only runs a few times a day/hour and you need ad-hoc scalable performance. If your app consists of running a quick cron job a couple of times per day, you do not have much of an app to begin with. If you are already paying for EC2, running those short-lived cron jobs in any one of those instances already adds zero cost. The main beneficiary of AWS Lambdas…

> If you are already paying for EC2, running those short-lived cron jobs in any one of those instances already adds zero cost.

Now you have a scheduling/orchestration concern. Kubernetes was built to address that kind of concern. The thread is filled with people bemoaning the cost of running Kubernetes.

> The main beneficiary of AWS Lambdas is AWS itself. It charges a huge premium for what essentially amounts to spare cycles in its infrastructure, and in the process ties up clients to a proprietary solution.

And as a result, we (the customers) don't have to pay for infrastructure that would otherwise be idle. Why can't it be a win-win?

Re: AWS costs every programmer should know (2019)

#77
post #28

aws can be so cheap. aside from egress bandwidth, it’s pricing is fantastic. crazy aws cost is always gonna be a case of your holding it wrong. either intentionally because it’s more fun, or accidentally. how to use aws well and cheaply: - scale to zero whenever possible (lambda) - use minimal infrastructure (lambda managing ec2 with route53 health check) - don’t use rds (s3+dynamo ideally, sql on i4i nvme if you mus…

> scale to zero whenever possible (lambda) AWS pricing is great because you aren't price-gouged if you don't use it? And your statement isn't really true. If you use AWS Lambdas do implement something like an HTTP endpoint, you still need to pay for stuff like AWS KMS and API Gateway even if no client hits you with a request. - use minimal infra (lambda managing ec2 with route53 health check) Above free tier AWS Lamb…

> AWS pricing is great because you aren't price-gouged if you don't use it?

Precisely. If you spin up instances with a per-time cost and they aren't being used, then you are wasting those instances. The engineering to automatically scale down instances when they are not being used, and to scale up (vertically and/or horizontally) when needed, is non-trivial to do correctly and, quite frankly, is now undifferentiated heavy-lifting. Paying a higher price when the infrastructure is being used and then not paying when it is not being used can and does result in lower overall costs when correctly architected.

Personally speaking, my AWS bill last month for my serverless side-project was $2.74. Sure, this includes stuff in the free-forever tier. Does that really matter? Nobody rents servers out that cheaply.

> you still need to pay for stuff like AWS KMS and API Gateway even if no client hits you with a request.

For KMS, true, for API Gateway, wrong. API Gateway pricing is per-requests, not per-time. If there are no requests, there are no charges. In most cases, you don't really need to manage your own KMS keys; there is no added-value compared to using AWS-managed keys. Even if you do want to manage your own key, the pricing is a few bucks a month per key, including usage, unless your project is highly scaled up, in which case, you're in a completely different class of cost-optimization.

Re: AWS costs every programmer should know (2019)

#78
post #4

It's interesting how AWS can keep so high prices on these. But it's just the beginning, the real money comes from when they convince you to run over a dozen vms/containers (all needing storage etc of course). You need to be triply redundant on 3 availability zones, (3x) both with the RDS db cluster and app containers (2x) . And then have separate dev/staging/prod envs (3x). That's 18x. You can then get a pat on the h…

At scale, perhaps they are costly. But i just cannot imagine deploying a webapp without cloud services.

For the indie dev, cloud services have made side projects and experiments extremely cheap to spin up and scale.

Re: AWS costs every programmer should know (2019)

#80
post #63

Earlier quoted context omitted.

> The amount of app code to solve the same problems without them is orders of magnitude more plentiful and complex, which is why we avoid it. The amount of application code to write to a filesystem is... zero. The amount of application code required to setup a webserver in Java Spring is... zero. Not sure what Kinesis does, but the amount of application code required to connect to a database is zero (spring), to conn…

There will be substantial amounts of code you are writing to provision, set up, maintain, scale, and troubleshoot all of those things. Whether you call it app code or not, it's something that you (and your team) will be on the hook for building and maintaining over time. Getting your Java Spring web server to scale to thousands of concurrent instances will require a lot of undifferentiated work outside the scope of J…

What sort of application are you building where you need a thousand instances of a spring application?

Like even hosted on a low powered hardware, Java services can easily deal with order of 100 requests/second. This is home turf, this is what Java is really good at. That 100rps may be lowballing it. So you're what, processing 100k+ API requests per second? I can't imagine that would translate toward any less than a billion users.

At that point you are either making good headway toward becoming a new letter in the FAANG acronym and ought to have the budget to run your own data center, or your attention is better put toward optimizing your comically inefficient application.

Post reply on HN