Hey @dysbulic, I already replied on Discord but also replying here so the answer is searchable.
Using Web3.Storage actually seems like a very interesting idea, and based on their documentation, probably something that could work fairly easily, though it would need some changes to the Ceramic code for API auth.
The other component to consider would be the Ceramic state store, which, for the moment, can only be in AWS S3 or on the filesystem.
We have been discussing ways to make this more scalable, and keeping it in SQL definitely seems to be one possibility. This isn’t implemented yet but it’s coming up fairly soon on our roadmap.
w.r.t. cost, I would say we’re probably close to the number you quoted for GCP, considering 1 AWS ECS Fargate instance each for Ceramic and IPFS + S3 for storage, etc.
This is a difficult comparison to make well though - we’re using ECS Fargate but could be using cheaper EC2 instances, switch to Graviton processors, use the filesystem instead of S3, switch to SQL for the state store, etc.
There aren’t any canonical, optimized deployment models yet, so an apples-to-apples comparison of various deployment models across cloud providers isn’t quite feasible at the moment.
There are also a few other unknowns/variables to consider, e.g. IPFS bitswap can make a couple of orders of magnitude more “WANT” queries for data not locally available (and resulting in “DON’T HAVE” responses since individual nodes only pin the information they care about and not all the data on the network), which, if using something like S3 for IPFS storage, can increase the AWS bill.