This is a great example of how one can layer an application on top of HyperTrack location event streaming platform to do display useful data. Once you have integrated the mobile SDK and started generating location events, you can start creating applications just like this one to provide richer experiences.
It's very easy to incur high costs here. We implemented cost analysis dashboards that allow us to monitor costs per each event, device, with visibility into each AWS service we use, with charts showing historical data. Fiscal planning is now part of our architecture design and implementation.
Usage of AWS services is a conscious decision, absolutely. However, the product architecture that uses these AWS services is subject to careful review for design and functional components integrity. Any of these components must be replaceable as issues/bottlenecks are identified. For example, if AppSync is proven to have issues as the company scales further, AppSync can be replaced with self-hosted GraphQL clusters. Additionally, other components in the architecture can be similarly replaced.
There is a difference between what was then and what is today. The key difference is that the "serverless" term is massively overloaded here and once you dissect it you will see that it's a mix of multiple serverlessly managed services that we are able to take advantage of: Kinesis, DynamoDB streams, Kinesis Firehose, SNS, Lambda, Cloudwatch, and GraphQL/AppSync. Serverless computing came a long way.
Let me ask you this question differently: lets say you are exploring a new market opportunity for the an exciting product you want to build. Would you rather spend cycles building what AWS has done already and thus delay speed to market or would you rather use what has already been done by AWS managed services and build what nobody has done before? Surely, this architecture will evolve over time, but it will only evolve as the startup quickly discovers what the market needs.
AppSync does have limitations we have to contend with. Custom scalar types cannot be defined hence we are not able to define strictly typed GeoJSON objects. Apache VTL has its own learning curve; once you master it you can implement functionality without leaning on invoking lambda functions and avoid paying for their usage in high volume GraphQl call scenarios and access queried data faster.