So as I dig into the Matrix reference server and how to implement it in AWS, I'm struck by the idea that I need to implement the Linux based server as is with containers in AWS is wrong. AWS has a rich suite of features that seem to be handled within the synapse application itself. My initial research shows that running your own home server in AWS could cost between $5 - $40 a month, which seems to be quite a lot to pay for owning your own data. So looking at this with my architect glasses on, it would seem we might be able to break this down into the composite services that can be handled by things like AWS SNS and AWS Lambda to turn things into a truly AWS native application that costs far less per month and can handle far more volume. This might be more work than I want to do to develop an application for Matrix, but it's something I think might be very valuable in the future. I mean, how many more people would be interested in hosting their own Matrix home server if we can get the cost down to to 1 - 2$ per month?

Break up the application into sub components. SNS topics and SQS queue's for listening and relaying messages. Lambda's for interpreting messages and saving to storage (S3 most likely). Authenticated CloudFront for outputting to clients and other servers. Lambdas for implementing the crypto and authentication/authorization. Default ports may need to be overridden in some cases. Chained Lambdas's are not out of the question, Step Functions maybe. But essentially, given my newbie understanding of Matrix to date, I think this is feasible.

The advantage to this architecture over just a container cluster is that the services are all on demand with no minimum charges. The container services, ECS/Fargate, require either minimum processing costs such as a one minute minimum charge for Fargate when the container is running, or classic ECS where you need to reserve VM's for the containers to run on. On demand can be potentially much, much cheaper.

This would also move the setup to something far more serverless, with just the Lambda's needing to be maintained, vastly increasing our security. Also a lot of the improved security of this architecture is due to the isolation of components. Each AWS component can be restricted with AWS IAM policies. Lambda's can have their dependencies reduced to just what they need for their particular role. Storage of chat data in S3 provides protections against SQL injection as S3 isn't really a database. We can even break up the plain text messages and encrypted messages into different buckets with different policies.

This also opens up some more possibilities to improve the security efficiently since we can use the AWS WAF with CloudFront (I know, the AWS WAF is crap compared to most commercial WAF's, but that doesn't make it useless). Yeah, I think I'll look into this instead of fixing the containerization of Synapse.

But later. For now I want app development, so I'll take the easy route and install synapse on a little EC2 instance locked down to my IP address so I can start working with the API.