我发现这个链接讨论了将静态数据和 Web api 分离到静态 s3 Web 服务器以及用于 api 和 ec2 Web 服务器的 bean stalk 应用程序来创建网站。 Charles 的回答是准确的，CORS 是解决两个域之间移动问题的方法。

如何同时使用S3作为静态网页和EC2作为REST API？ （AWS） https://stackoverflow.com/questions/17296940/how-to-use-s3-as-static-web-page-and-ec2-as-rest-api-for-it-together-aws

我的问题是你为什么要这样做？

我的一些想法是：

优点 - 我们使用 Node 作为 api 的 Web 服务器，这会减轻 Node 进程的负担。

就是这样。

不简单地使用 Bean Stalk 来完成这一切的缺点

CORS 增加了复杂性 更新软件比较复杂 看起来有点矫枉过正，除非你有大量我没有的静态数据

我是否还缺少另一个优势

将前端逻辑与后端逻辑分离并单独部署它们有很多优点。

代码分离

第一个重要原因是，以这种方式做事可以让您将业务逻辑（您的 API）与您的设计（您的前端）分开。

您可以将这两个项目保存在单独的 Git 存储库中。您可以让您的设计师根据需要向前端项目发送任意数量的更新，而无需打扰工程师。

在单个整体项目（例如，在 Elastic Beanstalk 上）中执行此操作几乎是不可能的，因为设计人员需要通过工程团队迭代他们的代码。

部署分离

网络服务器速度很慢。文件服务器（如 S3）速度很快。它们速度快的原因是没有运行任何“代码”来访问文件服务器上的文件——只是下载一个文件。

例如，如果您有一个由 EC2 实例提供服务的单一整体 Web 应用程序，这意味着要查看页面，您需要运行一些代码来生成该 HTML。

但是，如果您将前端代码部署到 S3，则 Web 浏览器可以直接下载该文件，速度要快得多。

PROTIP：您还可以将您的 S3 网站放在 CloudFront（CDN）后面，通过在世界各地的多个数据中心保留缓存副本来进一步加快您的网站速度。

更快的迭代

当您将项目分开并单独部署时，您可以更快地进行迭代。

假设您的前端团队在网站中发现了一个错误。他们可以轻松地修补/发布修复程序，而无需进行工程设计。

您的工程师也是如此 - 他们现在有更多时间专注于构建核心应用程序逻辑，并且可以部署修复程序而无需担心 UI 更改等。

更简单的产品逻辑

当您按照所描述的方式单独部署事物时，您还可以获得简化后端逻辑的好处。

通过让您的核心工程师只构建 API，而不用担心前端问题，您可以比其他方式更快地发布更新。