请帮我看一下我画的 AWS 架构图

[Hamao]

背景：目前有开发了一个类似运维问答的 fastapi 应用 demo （调用 gpt/qwen ），目前被抓去画上云架构（有一张 SAA 的没什么用的证所以被喊去画）工作两年多没有接触过画架构图 AWS 能力大部分是在理论，没有设计 AWS 架构实践，且对前端部署 AWS 没有概念。

之前只做过 Glue Lambda 的开发，所以我选择用 Lambda 做无服务项目。对于其他的 CloudFront 等各种组件都是理论知识（考证考的）

我的思考是前后端分离的话：
无服务就静态前端内容走 CloudFront+S3 ，动态内容用 Lambda 拿
Monitor 那个是三选一这样？

谷歌后画出来这样一张图:
https://imgur.com/a/s3rd03L.png

希望大家能指点一下问题所在：
例如：
架构设计错误
哪里没必要 浪费钱了
哪里不安全

[lymanbernadette6]

没啥问题， 不过 WAF 不便宜

[flmn]

aws 的图，一般左右排布

[Hamao]

@flmn 了解 感谢 我改一下

[chesha1]

请问这种图是怎么画的，aws 提供类似的工具吗？

[hwcloudnative]

大概有多少台 EC2 节点？如果少的话还行，如果超过 10 台，建议用 EKS 吧，lambda 只适小应用，而且价格不一定比 EC2 便宜，EC2 可以用 Spot 实例，价格是 lambda 的十分之一，担心 Spot 中断影响业务的话，可以看下这个免费工具，自动处理 Spot 中断 https://www.cloudpilot.ai

[BeautifulSoap]

1. ApiGateway 内部就是 CloudFront ，所以没必要把它放 CF 后面搞套娃，再一个 ApiGateway 放 CF 后面会遇到证书等问题。ApiGateway 应该和 CloudFront 同级，用同样的 WAF

2. ApiGateway 不是在 VPC 里的，它和 CloudFront 一样运行在 AWS 网络里（毕竟内部就是 CF ）

3. DyanmoDB 也不是运行在 VPC 里的服务，和 CloudFront 一样运行在 AWS 网络里（应该放到 VPC 外部）

4. 看 lz 的意思是要把 lambda 放 private subnet 里，并且 private subent 里没有任何 nat gateway 之类的服务。这会有个如下几个问题：a. 服务端如果要和外部服务交互么。有的话需要添加 nat gateway 或者 private link 之类的 b. 因为 DynamoDB 不是运行在 VPC 里的服务，所以目前这个情况你的 lambda 将无法和 dynamodb 通信。要么在 vpc 内添加 dynamodb 用的 private link 要么通过 nat gateway 和 DynamoDB 交互（不推荐 natgateway ，走的是外部网络通信）

5. lmabda 是一个 api 一个 lambda 还是只有一个 lambda 。前者需要设置好 secruity group 防止耗尽 subnet 的 ip 资源。并且 lambda 需要注意冷启动问题

6. 监视等服务也都不在 vpc ，全移出去到 aws cloud 里

7. 看样子是通过 docker 镜像方式部署 lambda 并不是 zip ，你这镜像是要赛 aws ECR 里？最好也标明

7. deploy 通过 serverless cli 的话最好拎出来单独拎出来画箭头，别和 lambda 放一起

[Hamao]

@BeautifulSoap 哥，超级感谢你点出来的问题点。大致理解了，非常感谢！

[Hamao]

@hwcloudnative 感谢提醒，确实看上去 spot 也符合需求。只是现在这玩意也还没有到真正上线先画个图说明意图（不是最佳实践这样）

[Hamao]

@chesha1 这个 draw.io 真的好用 啥图都能画还是免费的，他有一个 AWS 分类的图标（三个版本非常全），然后像图中的其他图标 fastapi 之类的直接可以插入链接变成图

[BeautifulSoap]

@hwcloudnative 就实践来说，现在普通项目直接用 EC2 的已经比较少了。除非项目很大（需要一直启动非常多 EC2 来计算才行），这种用 AWS ECS+EC2 是最有性价比的。而且比起 EKS 我觉得不如考虑 AWS ECS+Fargate 。ECS 这东西是真的无脑简单，什么都不用管，没 k8s 知识都能直接上。而且可以根据需要在 EC2 后端和 Fargate 后端里切换。deploy 之类的也都是给你准备好了，纯无脑

再一个 Lambda 也适合大的项目，主要还是看具体的负载类型。对于那种流量一直恒定很高的还是 ECS 比较好，但对于流量有疏有密的情况，Lambda 成本有自己的优势。比如我参与的某个几十万用户的 Lambda+Nodejs 项目，Lambda 每个本月花费$100 都没有。另一个大的项目每个月 Lambda 费用也就$1000 刀（那个项目 kotlin 写的，本身硬件要求就高没办法）。而且各种实践证明，所有 aws 服务中最花钱的并不是计算部分，甚至都不是数据库，而是 CloudWatch （这个没经验的人是真的想不到的）。。。。。。每次项目想的是好好设计下日志，节省 CloudWatch 开支，结果每次都是 CloudWatch 费用占大头

[BeautifulSoap]

@Hamao 作为设计、代码、DevOps 全包的苦逼全干工程师，和 AWS 斗智斗勇了 N 年还是有一丁点经验的😎

[Mithril]

@chesha1 AWS 提供各种版本的图形资源，OP 说的 draw.io 是一个，也有 PPT 模板或者其它的东西，你可以下来自己画。

[basncy]

提一下红帽 ansible, 一把梭, 买几台 EC2 和快照, CDN.
重点是, 整个方案架构可以代码化, 做版本控制.

[yzbythesea]

lambda 不适合你的场景。那玩意最多跑 15 分钟，主要用于一次性跑且无状态的服务。你这个问与答多来几个回合 lambda 自己就被终止了。

[a134698815]

@BeautifulSoap cloudwatch datadog 啥的确实占大头。。。所以我们新架构换 eks, 然后用 grafana+loki ，应该能代替 cloudwatch 的支出吧

[gtx990]

大体思路没有问题
很多很多服务都是 CloudFront -> API GW -> Lambda -> DynamoDB 这个架构
Lambda 比很多人想象中的强大，1000TPS 不在话下
不过推荐加钱使用 Provisioned Concurrency 来缓解冷启动的问题
另外就是 API GW 挂在 CloudFront 后这个事情，首先这么做其实很常见，因为能解决前后端跨域的问题。但是 CF 其实只是一个转发的 proxy ，API GW 需要挂在公网，不开 authentication 的话，那 API GW 自己也要挂 WAF ，开的话，CF 和 API GW 之间需要加 lambda 。很多大公司会把鉴权放在这个 lambda 上，share 给所有 team 用。