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

AWS costs every programmer should know (2019)

david-codes.hatanian.com

Post reply on HN
Print view View original

21–30 of 163 posts

Re: AWS costs every programmer should know (2019)

#21

Post by nindalf »

bringthesaas wrote: post #13
thrtythreeforty wrote: post #3

The one AWS service that I pay for is S3 Glacier Deep Archive. It is very cheap insurance for knowing with virtual certainty that your data exists. Egress is expensive ($100/TB last I checked), but in the target use - backups of last resort - I will be very glad to pay that to have my data back. And if all goes right I'll never pay it. Personally I find ordinary S3 far too expensive to justify. Not so with Deep Archi…

Out of curiosity, what do you think a fair price for s3 would be? I haven't had a problem with the storage prices, just egress fees can add up (I don't work for aws or a cloud provider, just curious)

A competitor of AWS claimed that AWS' egress fees are excessive and by how much - https://blog.cloudflare.com/aws-egregious-egress/

As for a fair price, I think Cloudflare and BackBlaze provide S3 API compatible services with better pricing. Cloudflare doesn't charge for egress at all. This lends substance to their claim that AWS is overcharging for egress.

Re: AWS costs every programmer should know (2019)

#22

Post by DeathArrow »

>AWS represents the computing power of its machines in Elastic Compute Units, and 4 ECUs represent more or less the power of a modern CPU.

What does the author mean by the "power of modern CPU"? What which microarchitecture? Which generation? How many cores? In 2019 I had a Ryzen 9 3900X with 12 cores. Was that a modern CPU? How many Amazon ECU would that take to be equivalent?

It seems to me he assumed all the CPUs were equally powerful at the time he wrote the article.

Re: AWS costs every programmer should know (2019)

#23

Post by arinlen »

philliphaydon wrote: post #10
fulafel wrote: 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…

> 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. Why would you care about the redundancy on staging / dev? Just making up things to inflate AWS costs now.

> Why would you care about the redundancy on staging / dev?

If you deploy to multiple regions then it wouldn't make no sense at all to have a single preprod stage, specially to run integration tests.

Also, keep in mind that professional apps support localization, and localization has a significant afinity with regional deployments. I mean, if you support japanese and have a prod stage on Japan, would you think it was a good idea to run localization tests in a us deployment?

Re: AWS costs every programmer should know (2019)

#24

Post by boberoni »

The two data visualizations in the article are poorly designed.

They show line graphs where the X-axis is the type of EC2 instance and the Y-axis is the price. Firstly, the X-axis of any line graph should be time. Or perhaps some other variable that "progresses". It's bizarre to use a category to label the X-axis of a line graph. Secondly, the X-axis is not ordered alphabetically, but seemingly randomly.

I don't mean to be harsh, but a better data visualization would be a bar chart, not a line graph. Bar charts are better suited for categorical dimensions. Also, the type of EC2 instances should be grouped and/or sorted, but not randomized. This way, the information from the data visualization can be parsed more quickly and easily.

Re: AWS costs every programmer should know (2019)

#25

Post by philliphaydon »

arinlen wrote: post #23
philliphaydon wrote: post #10

Earlier quoted context omitted.

> 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. Why would you care about the redundancy on staging / dev? Just making up things to inflate AWS costs now.

> Why would you care about the redundancy on staging / dev? If you deploy to multiple regions then it wouldn't make no sense at all to have a single preprod stage, specially to run integration tests. Also, keep in mind that professional apps support localization, and localization has a significant afinity with regional deployments. I mean, if you support japanese and have a prod stage on Japan, would you think it was…

Currently have a deployment in Oregon and cloudfront servicing most of the world. With localisation. No need to deploy in Japan to support Japan. The only tricky one is China because of the firewall. Tho that hasn’t been an issue for the last few years as they haven’t been blocking cloudfront completely. (This has been running for 10 years in AWS without issue)

Re: AWS costs every programmer should know (2019)

#26

Post by nathants »

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 must)

- automate everything, and use the automation constantly.

- egress heavy components get pushed out to cloudflare. r2 is in public beta!

Re: AWS costs every programmer should know (2019)

#27

Post by arinlen »

fulafel wrote: post #16
blackoil wrote: post #11

Earlier quoted context omitted.

Hire a better engineer/architect.

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.

Re: AWS costs every programmer should know (2019)

#28

Post by arinlen »

nathants wrote: post #26

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 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.

- don’t use rds (s3+dynamo ideally, sql on i4i nvme if you must)

AWS pricing is great because you are not price gouged id you do not use them?

Re: AWS costs every programmer should know (2019)

#29

Post by arinlen »

philliphaydon wrote: post #25
arinlen wrote: post #23

Earlier quoted context omitted.

> Why would you care about the redundancy on staging / dev? If you deploy to multiple regions then it wouldn't make no sense at all to have a single preprod stage, specially to run integration tests. Also, keep in mind that professional apps support localization, and localization has a significant afinity with regional deployments. I mean, if you support japanese and have a prod stage on Japan, would you think it was…

Currently have a deployment in Oregon and cloudfront servicing most of the world. With localisation. No need to deploy in Japan to support Japan. The only tricky one is China because of the firewall. Tho that hasn’t been an issue for the last few years as they haven’t been blocking cloudfront completely. (This has been running for 10 years in AWS without issue)

> Currently have a deployment in Oregon and cloudfront servicing most of the world. With localisation.

So you're serving static assets through CloudFront with a single backing service. Congrats, you managed to have a service that doesn't offer regional services.

Also, you definitely don't support clients in China, or enjoy shooting yourself in the foot.

Most professional applications with a global deployment and paying customers don't have the benefit of uploading HTML and calling it done.

Re: AWS costs every programmer should know (2019)

#30

Post by dageshi »

arinlen wrote: post #23
philliphaydon wrote: post #10

Earlier quoted context omitted.

> 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. Why would you care about the redundancy on staging / dev? Just making up things to inflate AWS costs now.

> Why would you care about the redundancy on staging / dev? If you deploy to multiple regions then it wouldn't make no sense at all to have a single preprod stage, specially to run integration tests. Also, keep in mind that professional apps support localization, and localization has a significant afinity with regional deployments. I mean, if you support japanese and have a prod stage on Japan, would you think it was…

If you're deploying to multiple regions in aws then you'd presumably have to roll out the infrastructure for 3 regions yourself if you weren't? In which case I gotta assume using aws is probably a lot more straightforward straight off the bat than rolling your own solution in three different data centers?
Post reply on HN