AWS环境下Drupal 9解耦架构最佳实现方案咨询

最优解是基于现有EB环境原地切换为多容器Docker平台，同环境混合部署React前端与Drupal 9后端，全程不需要新建EB环境，现有AWS资源栈90%以上的配置可以直接复用，没有额外的环境运维成本：

• 平台原地切换：把当前跑Node.js服务的EB环境平台从单runtime平台切换为「Amazon Linux 2 下的多容器Docker（ECS集成）」平台，切换过程不会重建环境底层的网络、安全组、IAM权限配置，原有绑定的CloudFront源站规则、ElastiCache/RDS内网访问权限全部保留，不需要做额外的网络打通。
• 服务编排配置：在docker-compose.yml里定义两个服务：
  • 前端服务：用你原有Node.js镜像，承载React应用的静态资源托管/SSR逻辑
  • 后端服务：用官方Drupal 9 PHP-Apache镜像，承载内容管理、JSON:API/REST接口能力
    两个服务通过EB内置的本地Docker网络内网互通，流量不经过公网，延迟和安全性都有保障。
• 路径路由规则：在EB平台自带的Nginx反向代理层写转发规则，将/jsonapi/*、/api/*、/admin/*、/user/*等所有Drupal专属路径转发到后端Drupal容器，其余路径转发到前端React服务，对外只暴露EB原有访问入口，用户侧完全感知不到架构变化。
• 存量资源复用：Drupal 9容器直接内网连接现有RDS实例（提前在测试环境完成D7到D9的数据结构升级、兼容校验）、现有ElastiCache集群（配置Drupal 9的Redis缓存后端替换原有D7缓存逻辑），不需要新建数据库、缓存资源，只要确保EB实例所在安全组有RDS、ElastiCache的内网访问权限即可，和你之前D7单体时代的权限逻辑完全一致。
• 成本说明：整个方案不需要额外支付EB环境的基础费用，仅需要承担EC2实例上多运行一个Drupal容器的算力开销，绝大多数场景下原有D7单体使用的EC2实例规格足够同时承载两个服务，不需要额外升配。

不要选把Drupal部署到Lambda、或者单独开EC2搭Drupal的方案，运维复杂度和成本都比多容器方案高至少一个量级。

完全可行，但是要匹配合适的场景，避开平台限制：

• 运行时支持：Lambda@Edge目前已支持Node.js 18/20运行时，你可以用react-dom/server将轻量React组件编译为SSR逻辑，部署到Lambda@Edge后在CloudFront的边缘节点执行，直接拼接好组件HTML返回给用户，能大幅降低源站渲染压力。
• 接口调用最佳实践：
  • 不要每次触发Lambda都直接回源请求Drupal REST接口，会大幅提升边缘响应延迟。建议搭配CloudFront缓存策略，将Drupal的REST接口响应按路径、用户会话cookie做分层缓存，Lambda@Edge优先读取CloudFront缓存的接口数据做渲染，缓存命中场景下端到端延迟可以控制在50ms以内。
  • 涉及登录态的个性化内容场景，直接在Lambda@Edge中将用户的会话Cookie透传给Drupal后端即可，Drupal原生REST接口支持Cookie鉴权，不需要额外开发自定义签名逻辑。
  • 仅适合放导航栏、内容卡片、推荐位这类轻量、低算力开销的React组件，整页级别的React SSR逻辑不要放到Lambda@Edge——受限于平台的执行时长、内存上限（Viewer触发类函数最大执行时间5秒，内存最高10240MB，冷启动开销明显），重型渲染逻辑放在EB上的Node服务跑稳定性更高。
• 避坑提醒：Lambda@Edge函数必须部署在us-east-1区域才能同步到所有CloudFront边缘节点，函数运行日志会存在离用户最近的边缘节点对应区域的S3桶里，不要在EB或者Lambda主服务的默认日志路径排查问题。

内容的提问来源于stack exchange，提问作者JOINSO