[theshrike79]

Yep, most corporations have 2-3 _named_ account reps who are available on the company Slack and will visit your office 1-2 times a year to sync up that everything is working as it should.

And they're not just salespeople, they've actually said multiple times if a feature doesn't work for us without trying to hold it wrong in a dangerous (and expensive) way.

[JoshTriplett]

> they've actually said multiple times if a feature doesn't work for us without trying to hold it wrong in a dangerous (and expensive) way.

Can you give examples of this? I'd love to hear more about the kinds of guidance they can give.

[theshrike79]

We were building a matchmaking service for our mobile game and thought about using Amazon GameLift FlexMatch[0]. On the surface it would've worked.

BUT, it's _very_ highly geared towards fully-online games where everyone playing the game is connected to a server all the time. Our game was asynchronous PvP where the attacker was online, but the defender wasn't.

I had a 30 minute chat with them and they confirmed that it _could_ be made to work, but it'd be extremely janky and expensive in our use case.

We ended up building our own (or actually expanding our existing setup a bit).

--

We've also got pretty good estimates on how much something might cost: we have an application that needs a specific number of writes/reads with X amount of data per write, what would be the cost on different Amazon services.

Again they came back with numbers and with many services (DynamoDB especially) it would've been either impossible or prohibitively expensive. We ended up changing the application structure to do less IOPS + more aggressive caching and ended up using plain S3 as storage.

Without their consultation (And inside knowledge about AWS internal hard limits) we would've spent weeks building a solution that will eventually fail as the data stored per user goes up.

[0] https://docs.aws.amazon.com/gamelift/latest/flexmatchguide/m...