Hacker News Reader

Comment by arinlen | Hacker News Reader

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

View on HN

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

The API gateway might not be necessary any more:

https://aws.amazon.com/blogs/aws/announcing-aws-lambda-funct...

aws pricing is literally a catalog. what and how much you buy is kind of the whole thing. a subset of the catalog is good.

aws core primitives are:

- flexible

- reliable

- robust

if your service succeeds, you will definitely want to move some components out of aws, but not all of it. aws can always remain the control plane.

if you don’t need what aws offers, don’t use it. they offer it at a price, and it is what it is. thanks to other providers, it likely will remain fair over time.

what i outlined was how to make aws cheap(er). it’s a simple strategy:

- use the primitives: s3, ec2, nvme, route53, lambda, apigateway

- avoid the services: rds and all the rest

- avoid heavy egress: use cloudflare workers and r2

scaling to zero means avoiding things like kms keys.

not sure where you got apigateway pricing from, it definitely scales to zero without fixed minimum cost.

lambda will always be the most reliable part of your stack. when you have enough traffic that it’s worth it, use ec2 instead and let lambda manage those machines.

I don't agree about avoiding the services. If you're mega successful down the line you can likely afford to do the migration when it's expensive, but the services are what save you_time_, and initially money too. I can spin up an RDS server that is secure and production ready in less than 5 minutes that quite frankly I don't need to touch for a very very long time. If we need more power, I can restart the instance with a bigger type, or if we've overspecced I can use a smaller one. Compared to running your own instances on ec2 there's a few hours of poking around to do things like password handling, backups, logs, not to mention you're now responsible for managing updates and the likes. It's a false economy to avoid them IMO.

That's not to say you should immediately pivot to all in AWS all the time but like any engineering be aware of the price you're paying to build Vs buy

definitely. some of the services are great. they are just a lot more expensive. in the context of making aws cheaper, avoiding services is the play.

> if your service succeeds, you will definitely want to move some components out of aws, but not all of it. aws can always remain the control plane.

Do you factor in the costs of dev time in a cross cloud environment at all? Nevermind all the AWS specific tooling and code you write, which needs to be thrown away and re-done to accomplish this?

Don't get me wrong, I love AWS when I'm not paying the bill, it makes my job of shipping features quickly so much easier. It's good and it works well. But it's a little crazy to think it's "cheap" and to ignore the costs of vendor lock in.

vendor lockin is fine. it’s like having a great employee, but not leveraging them fully because bus factor and cogs. you should be sad if a great employee leaves, or your vendor shuts down. choose both carefully, and trust them.

my only experience expanding out of aws is to cloudflare for egress. i’m sure it can be rough, but so can anything solved with dev time.

expanding out of aws with individual tightly scoped components should be easier than general cloud migration. just bandwidth egress. just cheaper cpus for background processing. just whatever.

keep the complicated stuff on main cloud where it belongs.

Do you factor programming language and library and operating system and cpu architecture into your vendor locking and specific tooling you need to write?

> 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 common task in my organization.

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

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

Reply on news.ycombinator.com