Not to say that isn't a useful article on its own, but it's hard to draw too many meaningful conclusions for the rest of us when the first line of the AWS bullet points is "reach out to dedicated YC email".
I'm in a similar position and those credits would be lifechanging.
The grants start out small (I think the first one was $3k) -- but then once you spend 75% of them you can apply for the next round, which for me they gave me $17k out of a possible $30k based on previous usage. After I spent around $15k for that over the next year I applied again and got $100k.
Just one note though that I already had an MVP that I was running on GCP at the time I applied (but I was within the $300 free credits that I started with so I didn't pay out of pocket).
Also good PR.
I like Firebase, but the moment the utility runs out we're heading back to AWS.
Just from a technical perspective I'd advise to avoid the firebase databases like the plague.
I've built a prototype on top of it and it's fairly rudimentary but you can make it work. My biggest concern is that there are no case studies I can find of people using it past the prototype stage and how the pricing/scalability works out at that point.
Love to hear from anyone who has gone beyond the prototype phase.
It's not completely wrong, but incomplete.
So if you want to work on building your business and not debug cloud provider issues, avoid the new upstart.
If you just want to get started with GCP, you just sign in with your Google Account for $300 in credit. When you run out you can just start paying with a credit card.
AWS: makes me apply to a program to get credits and if I want to price out anything it's almost a full-blown research effort where I have to dig through documents and cross reference tables between different services and I still probably miss something important. Free tier is opaque enough to frustrate even "use it at small scale and see," because you still have to do the research to see if they are pulling a "your first hit is free but try to scale and WHAM." Oh, but they're customer obsessed, so after much begging and pleading they'll refund half of WHAM, one time.
If I punch in the services I want to use, I can quickly see how much they will cost, and it's easy. I recommend clicking "Advanced" inside services on the calculator if you want to be sure you're not going to run into an edge case that costs lots of money unexpectedly.
If you use any of the megaclouds without first understanding the price structure, good luck.
Personally, I think a lot of companies would be better off using DigitalOcean or some other medium-size cloud. The pricing is much simpler, and pretty much all medium-size clouds charge $0.02/GB for egress bandwidth, either globally or in the US, depending on the provider.
In contrast, the megaclouds make shocking amounts of money off of their extremely pricey egress bandwidth, among other highly profitable aspects of their business.
Even still, AWS is a solid cloud platform, and they really do seem customer obsessed compared to what I've seen happen on GCP.
That said, I'll grant you that AWS is not the only megacloud leveraging opaque cost structures. They just leverage them more.
AWS support is genuinely a cut above, though.
https://forums.aws.amazon.com/thread.jspa?threadID=249559
I use GCP now. I find their tooling and UX to be about 100% better and will not use AWS in the future if I can avoid it.
Can you provide an example of a service that the AWS calculator doesn't compute the correct price for?
I honestly can't remember ever being surprised by what things on AWS cost, and I don't think I'm that shockingly good at detecting hidden costs.
When I shared this anecdote at Re:Invent, the sentiment at the table was "lol that's cute, here's my story with an order of magnitude higher price tag." There were 5 or 6 of us, and my story was the smallest surprise cost except for one other person who was even greener than I was.
> Can you provide an example of a service that the AWS calculator doesn't compute the correct price for?
Can you tell me how I should have used AWS calculator to prevent my surprise charge? You can't, because AWS calculator assumes you know exactly what you're asking for, and the problem with opaque pricing structures is that you sometimes don't.
Other clouds tend to be much more upfront about "this will cost X," "this is costing X," "you're out of free tier," etc.
Apples and oranges.
It's really nice to hear from high-prestige companies about their experience because it gives outsiders a sense of what prestige might fix. If you're a small startup looking for help using AWS, finding someone to introduce you might really help! Not so much with GCP.
All in all, it had taken our incubator at least 1.5 years to get enrolled in AWS Activate, and 4 days in GCP for Startups.
When we applied for GCP for Startups, we were approved in a week, and were contacted right away by an account manager and a support engineer who offered us help with anything we needed. When we applied for Activate, it took a month with lots of followups, and being shuffled between 4 support team members who were communicating with the Activate team (there was no way to contact them directly).
It definitely felt like our business was important for GCP, and for AWS, it wasn't. It was an easy choice.
Google has never had a good reputation for Customer service, they believe they can solve all Customer Service with bots and Automation, this will ALWAYS lead to a lower level of customer service.
Amazon started in retail sales where customer service is king, so it naturally has batter customer service philosophy than Google.
Google has shown zero signs it even desires to have a customer service philosophy that is remotely similar to Amazon, or even Microsoft Software which is somewhere between Amazon and Google on the customer service scale
My point is that obviously AWS thinks that on average being in YC is going to result in more revenue for them and therefore they prioritize support for YC companies. As a non-YC company I won't get the same treatment which makes any conclusions from this article less useful.