I'm a little bit disappointed by the solution of this article. They start with: "This stack was created out of frustration due to the fact that to this day the

I'm a little bit disappointed by the solution of this article. They start with: "This stack was created out of frustration due to the fact that to this day there's no easy way to have a full email server without the overhead of installing and configuring all servers needed to handle incoming and outgoing messages." Ok, so the point is that it is too complicated/frustrating to deploy an email server. But look at their solution in "what will deploy"... in the graph there are over 40 entities! In the following they list 13 different aws components needed. And all of that not even really doing the core feature of email sending/receiving that is provided by SES. Maybe you can deploy it with a single cloudformation recipe, but then it is so so many systems that you will have to watch and check for issues, quota, policies, usage billing and configuration. And you are not even in control, you have to go lick aws ass for easing the restrictions on the number of emails sent and to who. Plus there are probably a number of drawbacks and hidden limits that are not exposed to you by aws and that you will discover the hard way. For exemple, looking at the description I'm wondering, how do you do coherent backups at a random time? Knowing the quality of service of aws api, what do you do when there are random crash, network errors and co in the middle of the pipelines/lambdas? In my opinion this is a good exemple of an over-engineered solution.