In the Reference Architecture, why is backend proxied from frontend?
I have few questions regarding reference architecture deployed - as I see, frontend and backend applications, represented as ECS tasks, are separated to the own target groups and own ALBs - so backend can be accessed directly only via frontend, and through frontend with /service/backend route. This pass-through route is actually route, that belongs to the frontend application, rather than to the public ALB, where frontend sits in. So: 1. Am I right, that traffic specifically for backend is being double-billed in fact (1st time - passed through public ALB, 2nd - through private ALB)? 1. In case, if it’s needed to expose backend, let’s say for specific types of devices (like mobile cell phones), isn’t that more cost-effective solution to deploy an additional security group for backend, and configure a listener rule, to process specific path /backend with that additional security group? Here meant, that this security group is attached to public ALB. 1. Are there really any security concerns of such approach as listed on #2, in comparing with proxying requests with frontend application, if we’re speaking about CIS-compliance?
The proxy feature of the frontend to the backend is merely an example of how to setup a traditional microservices architecture deployment where you have private service apps that are not meant to be directly exposed to the public. We've found that many customers have struggled to identify what's the best way to deploy such an architecture, including how to handle end to end encryption, and thus we have opted for the Reference Architecture to be set up in this way so that you have an example of how we would deploy such an architecture. This setup has no CIS implications. The CIS AWS Foundations benchmark (which we are targeting in the product) does not have any rules on how to lock down your app, so you would not be violating CIS if your backend app indeed needs to be public. Given that: 1. Yes you are correct that you would be double billed for this setup. 2. Yes this would be more cost effective, assuming that the backend service needs to be exposed to the public. 3. No concerns with the approach from a CIS perspective, if the backend service is intended to be consumed publicly.