关于三层架构，我们有很多想说的话：
（以下内容以下都在VPC中）

1. cloudfront做CDN加速
2. 网关规划
3. S3做静态网站托管
4. APIGateway作为统一网关入口+认证/限流
5. Lambda 作为传统后端，并发，底层架构
6. Redis缓存
7. DDB作为持久化存储
   

网络规划

出于HA的目的，我们用三个可用去来部署应用，由于VPC甚至子网的CIDR是不可变的，那么我们要前期规划好这个划分。

一般来讲我们是前后端分离的模式，所以在每个可用区会把前端，后端，数据库放在独立的子网里面，当然也需要预留一些IP地址的空间来应对后面的新需求，所以对于三个可用区而言要划分12个子网，当然如果再想预留一个AZ的空间也没关系，那就是一个VPC划分16个子网，现在用到9个，剩下7个用来应对以后不确定的业务需要。当然这个只是一个比较推荐的做法，可以根据业务需要做对应的调整。

认证以及流控

然后到后端，APIGateway提供了一系列的认证方式，包括Cognito集成Cognito用户池进行登录，也支持集成OIDC IDP使用JWT的认证，甚至也可以使用Lambda来做自定义的身份认证，访问需要授权的路由的时候会先进入到授权方的模块，然后再根据结果区访问目标的路由。
可以使用APIKEY做流量的的控制（header 中带api-key)。

后端应用

然后是后端，对于无服务而言我们后端一般都是Lambda，当然我们现在讨论的都在VPC的情况，这样lambda会在所在子网内生成一张网卡，所以效果是，公有的访问流量通过APIGateway转发到lambda，然后lambda使用VPC内的网卡来访问内网的数据库，比如redis，RDS，dynamoDB。

如果是传统后端上云，由于放在lambda上会更改项目代码，也可以选择部署到EC2上，然后使用NLB做负载均衡以及水平的弹性。这样的架构也可以使用VPC Link来集成到APIGatey中。

关于缓存：

1. 延迟加载：查询时候没有命中缓存，在DB中查到数据，再把这条写到缓存中。
2. 直写:写DB的时候直接更新缓存。
3. TTL: 空间有限，设置缓存过期时间，防止大量缓存过期，TTL尽可能的打散。

【1】https://docs.aws.amazon.com/zh_cn/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/single-page-application.html
【2】https://aws.amazon.com/cn/blogs/compute/understanding-vpc-links-in-amazon-api-gateway-private-integrations/
【3】https://aws.amazon.com/cn/caching/best-practices/