为简易网站选择AWS架构：三种方案选型咨询

我正在设计一个简易网站的架构，具体需求如下：

• 有一个搭配CSS样式和JavaScript的index.html页面
• 用户在页面表单提交邮箱后，会收到格式为/verify-email/{token}.html的验证链接
• 后端验证token通过后，将用户重定向至verified-email/thankyou.html

方案1：HTTP API Gateway + Lambda #

• .html、.css、.js文件及图片都存储在两个Lambda函数中
• index Lambda负责调用对应文件渲染index.html
• verify-email Lambda通过DynamoDB验证token后，调用对应文件渲染verified-email/thankyou.html

方案2a：CloudFront + S3 + Lambda@Edge #

• .html、.css、.js文件及图片均存储于S3桶内，index.html、verified-email/thankyou.html及对应资源都在该桶中
• 由Lambda@Edge函数处理token验证，验证通过后重定向至verified-email/thankyou.html

方案2b：CloudFront + S3 + HTTP API + Lambda #

• 基础逻辑与方案2a类似，区别在于给CloudFront配置了API Gateway作为第二个源站，token验证逻辑交由HTTP API + Lambda处理

针对这个简易网站，方案2b是最合适的选择，具体理由和选型核心考量点如下：

优先选择方案2b的原因 #

1. 静态资源管理更高效：静态文件（HTML、CSS、JS、图片）放在S3是最适配的方案，存储成本极低，更新时直接上传即可，不像方案1那样要把静态文件塞进Lambda，改个样式都得重新部署函数
2. 职责划分更清晰：静态内容由CloudFront+S3负责分发，token验证的业务逻辑交给HTTP API+Lambda，各模块独立运作，后续修改逻辑或更新静态资源互不影响，维护成本更低
3. 避开Lambda@Edge的限制：方案2a用Lambda@Edge处理验证，虽能在边缘节点执行，但它有运行时长限制，日志分散在各个边缘区域，排查问题难度大；方案2b的Lambda在AWS区域内运行，访问DynamoDB更稳定，权限配置也更常规
4. 扩展性更强：后续若需新增功能（如统计验证成功率、调整邮件模板），直接在HTTP API+Lambda链路扩展即可，无需改动静态资源的分发流程

选型时的核心考量因素 #

• 资源存储的成本与便捷性：S3存储静态资源成本远低于Lambda挂载资源，且更新操作简单；方案1把静态文件放在Lambda中，既浪费函数资源，又增加了部署复杂度
• 业务逻辑的复杂度：若验证逻辑极简单，方案2a可临时使用，但只要逻辑有变动（如添加token过期校验、记录验证日志），Lambda@Edge的修改成本远高于普通Lambda；方案1将静态资源与业务逻辑混在一起，后期维护难度极高
• 运维调试的成本：Lambda@Edge的日志分散在多个边缘区域，排查问题需跨区域检索；方案1的Lambda调试方便，但静态资源管理冗余；方案2b将静态资源与业务逻辑分离，各自调试运维都更简单
• 权限与稳定性：Lambda@Edge访问DynamoDB需配置跨区域权限，且边缘环境的网络稳定性不如区域内Lambda；方案2b的Lambda与DynamoDB在同一区域，延迟更低，权限配置也符合常规操作逻辑

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