It has according to this blog post: https://aws.amazon.com/blogs/aws/aurora-serverless-ga/

"The service currently has autoscaling cooldown periods of 1.5 minutes for scaling up and 5 minutes for scaling down"

From what I have read here / experienced personally, google scaling > amazon scaling > microsoft scaling and each one is an order of magnitude greater in performance (there is an article on microsoft functions vs Amazon lambda which gives you the idea and don't even get me started on google tech versus microsoft/amazon).

However, it is the opposite for sales/marketing/support apparently. It'll be interesting to see where the market goes towards in the future.

I think Azure is pretty damn good for certain things.

http://muratbuffalo.blogspot.com/2018/08/azure-cosmos-db.htm...

    google scaling > amazon scaling

???

I've read many comments here about how googles load balancers are way more reactive that amazons as amazons needs "warming" to get them ready. I've also heard great things about app engines dynamic scaling. Unfortunately, I cannot find any article purely related to it.

Here is the article about amazons functions being way more reactive than microsofts: https://news.ycombinator.com/item?id=16099729

Amazon employee here. I can confirm that ALB and NLB do not need prewarming for most customers.

If you are Epic Games running Fortnite on AWS, and you want to direct millions of player connections through a brand new, freshly provisioned load balancer then you should definitely talk to support to make sure the load balancer is prewarmed and ready for that level of traffic.

But 99.99% of websites and service won't need intervention or prewarming at the load balancer level because the load balancer can and will scale up far faster than your backend server provisioning and scaling, or your database will. You only need to worry about prewarming a load balancer in the very specific conditions where you are immediately redirecting millions of active connections over to a new load balancer, and frankly there are very few companies that have that problem.

Additionally even if you do have that problem Amazon gives you the tools to solve it without needing any manual prewarming. Any blue/green traffic switchover at massive scale should probably use a weighted Route 53 DNS record set. You wouldn't immediately cut 100% of your traffic over to a new load balancer, instead you should dial it up in percentage increments while testing and monitoring the new stack. ALB and NLB can autoscale up gracefully and automatically as you increase the DNS weight on the new DNS record.

Joke of the week.

You have to respect the reputation Google accumulated over the years. And no one will reveal anything to settle this debate.

My biggest concern is how long will it take to warm up from cold? But it's good knowing that it'll remain warm for 15 min.

It says 25 seconds on average.

The cold-to-warm state change sounds like it's something you would only ever want to do in batch jobs.

But I can see many situations where you have a DB that only needs to actually be awake for short periods of time throughout the day for batch jobs. And even more that only need the barest minimum capacity available 24/7 with large spikes for batch-based processing.

> But it's good knowing that it'll remain warm for 15 min.

Not sure what you're talking about. It's warm for as long as you want it to be. That's configurable. Read the post.