Serverless Aurora

Re:Serverless Aurora by oh_hello on Monday December 04, 2017 @04:14PM (#15847579)

The idea is exciting, but the pricing looks too high for side projects. The docs state "Aurora Serverless can scale from a minimum of 1 ACU to a maximum of 256 ACUs." Unless I'm reading this incorrectly, you are paying for 1 ACU 24 hours a day.

$0.06 * 24 * 365 = $525.60 per year.

This is more expensive than a low-end RDS instance. It's a shame, I immediately thought this would be the perfect solution for side projects and prototypes, but the pricing killed it.

[ Parent | on HN ]

Re:Serverless Aurora by jajern on Monday December 04, 2017 @04:34PM (#15847730)

You pay per second of usage and the ACU starts and shuts down automatically. If your DB is only actually accessed a occasionally then you are not paying for 24hrs of usage. I think the auto-scaling is the draw though, not necessarily the price. So you are only getting charged the the database is being accessed. I think the examples on the pricing page make it a little more clear.

[ Parent | on HN ]

Re:Serverless Aurora by jchanimal on Monday December 04, 2017 @05:27PM (#15848141)

FaunaDB Serverless Cloud has global ACID transactions with per-request pricing. You can optimize your queries for cost by looking at the response headers, or support your organization with an on-premise multitenant cluster. Learn more about pricing and features here https://fauna.com/serverless

[ Parent | on HN ]

Re:Serverless Aurora by k__ on Monday December 04, 2017 @05:25PM (#15848123)

Would be strange if it was otherwise.

The whole serverless stuff only pays if you have highly varying loads OR want to save of Ops staff.

[ Parent | on HN ]

Re:Serverless Aurora by Mizza on Monday December 04, 2017 @04:28PM (#15847682)

Although not applicable for all use cases, you can use static storage as an alternative for radical cost savings:

https://github.com/Miserlou/NoDB

https://github.com/Miserlou/zappa-django-utils#using-an-s3-b...

[ Parent | on HN ]

Re:Serverless Aurora by inopinatus on Monday December 04, 2017 @06:05PM (#15848419)

On the other hand, for the next step up, e.g. small production services with spiky workloads, it looks great, assuming I've read the product details correctly.

Case in point, I have one service that doesn't usually need a lot of DB grunt, but has occasionally spiky and unpredictable read-heavy data extractions. It runs happily on a multi-AZ pair of db.t2.small instances, for which we currently pay $0.104/hr (ap-southeast-2). Frankly it could mostly run on a db.t2.micro but we occasionally need the headroom of the bigger instance and the availability of multi-AZ. So when Serverless Aurora comes here it'd be a shoo-in, being both cheaper and more scaleable, and with more replicas to boot.

[ Parent | on HN ]

Re:Serverless Aurora by k__ on Monday December 04, 2017 @07:01PM (#15848714)

https://serverless.com/blog/ultimate-list-serverless-announc...

Here they write pay per second.

[ Parent | on HN ]

Re:Serverless Aurora by sjtgraham on Monday December 04, 2017 @04:31PM (#15847702)

I was about to say you don't get encryption at rest with a low-end instance, but that looks like it's no longer the case since this summer.

[ Parent | on HN ]

Re:Serverless Aurora by moduspol on Monday December 04, 2017 @04:34PM (#15847734)

Supposedly it turns off when you're not using it, so you'd need a small, consistent load all year to reach that price. And if that's the case, you'd just use a low-end RDS instance.

I think the value is in that you can build something quickly with no static instance cost that scales. You can (presumably) switch to normal instance-based RDS when your usage favors its pricing.

[ Parent | on HN ]

Re:Serverless Aurora by k__ on Monday December 04, 2017 @07:03PM (#15848723)

Yes, if it's not used, you don't pay.

So just a question of pricing your service on your end...

[ Parent | on HN ]

Re:Serverless Aurora by manigandham on Monday December 04, 2017 @07:49PM (#15848925)

The whole point is that it's not on 24/7 so that calculation doesnt apply. If you need it always on or don't have super spiky workloads, stick with the standard instances.

https://youtu.be/k9M7QinznHc?t=22m54s

[ Parent | on HN ]