我们希望将.NET Core应用程序迁移到AWS。有关一些背景信息；目前，我们将应用程序托管在IIS背后的VM上，而IIS具有.NET Core Hosting模块，非常简单。我们的应用程序既是Intranet应用程序又是面向外部的应用程序的组合，没有任何应用程序具有很高的流量需求。
经过一些研究，似乎AWS ECS Fargate是一个不错的选择。计划是在此时对我们的应用程序进行Docker化并将其部署到ECS Fargate。
我的咨询主要是关于反向代理的话题。
目前，我已经在Application Load Balancer后的ECS Fargate上成功运行了Identityserver应用程序。 ALB执行TLS终止，并将流量转发到在http上的ECS Fargate下运行的容器。这是非常简单的设置，但是我担心我缺少一些东西，因为这实际上不是我的专业领域。
我的问题是，以上设置听起来是否足够？我当前的头痛是，是否值得在管道中添加Nginx（或类似的）反向代理？在这种情况下，据我了解，有两种情况：
-
保留ALB并添加另一个反向代理（例如Nginx）。 ALB仍然执行TLS终止并将流量转发到Nginx，后者又将流量转发到运行应用程序本身的容器。我也许看不到这样做的好处，但是我担心我可能是错的。我觉得这给设置增加了不必要的复杂性。
-
一起跳过ALB，并公开展示Nginx（或另一个反向代理）。 Nginx实例代表TLS终止，负载平衡等。尽管我可以看到在这种情况下进行更多控制的好处，但是再次看到-我们是一个小型团队，拥有有限的托管经验，因此额外的设置使我认为这不值得。
所以-我的主要问题是，原始场景在生产环境中听起来是否合理？当然，如果有人可以提供一些反馈意见，那么任何其他反馈意见也将受到高度赞赏。