8月10日，AWS无预警放出NLB对SG的支持，这实际上带来了诸多功能性和安全性上的提升，我们将在本文中探讨一下NLB添加SG支持，可以带来的种种好处。

1. 通过SG，NLB可以直接进行流量过滤

没有SG支持之前，NLB会保留源IP并将流量分发到目标组，这意味着我们需要在目标组的SG上创建对应规则，来进行流量的过滤。当NLB的目标组数量有限，且业务不那么复杂时，我们还可以维护这些目标组的规则，但是当规模复杂度均上升时，目标组规则的可维护性就会降低。

通过SG，我们可以直接在NLB上过滤流量，集中实施访问控制策略。

2. 通过SG引用，精细化流量过滤

为NLB添加SG支持后，我们便可以在SG间引用NLB的SG，这样可以做到流量的精细化过滤，例如我们可以限制NLB的目标组中的EC2，只接收来自NLB的流量（这是一个典型的SG引用场景），通过SG引用，我们不用担心目标组弹性伸缩带来的规则维护成本。同时通过限制目标组仅接收来自NLB的流量，我们也可以保护目标组不受直接访问所带来的安全风险和负载均衡失效的问题。

3. K8s的场景

如果您使用Kubernetes，则可以通过使用Amazon Load Balancer Controller 2.6.0 或更高版本在NLB 上启用安全组。通过使用该控制器启用NLB 安全组，可以提高节点的安全性，因为可以通过引用NLB 安全组来简化入站规则。此外，这还可以改进扩展能力，因为该控制器会保持每个集群的安全组规则数量恒定。

我们已经了解了NLB添加SG支持的好处，那么接下来我们便实际操作一下，首先我们对于该feature创建前的NLB，如下图所示。

可以看到，既有的NLB是无法添加SG支持的，这就带来了该feature的要求即，新创建的带安全组的NLB，才能在后期调整SG。

所以我们开始一个新的NLB创建

可以看到在创建这个NLB时，我们挂上SG（实际上如果在这里不挂SG，就回到了之前的NLB）

经过等待，我们便有了一个带有SG功能的NLB。同时我们可以将流量慢慢过渡到这里来。

值得注意的是，对于PrivateLink的流量，默认情况下SG是过滤的，但是我们可以通过这里的Toggle进行选择。这让我想到了之前Internal NLB如何设计SG功能，便是通过PrivateLink为NLB添加SG功能，但是需要注意的是PrivateLink的性能是被限制了，它并没有获得NLB的高吞吐量的特性。那么，含有SG的NLB，其性能到底有多少损失呢？我们将在下一篇，对LB进行吞吐量测试，以确认这个功能所需要的性能开销到底有多少。

https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/

https://www.amazonaws.cn/new/2023/amazon-web-services-public-ipv4-address-charge/

这势必会给企业带来一笔隐形的开销，本文将带领大家来理解IPv4公共地址的种类，以及使用Public IP Insight来分析目前已有的IPv4地址，同时也会计算将来可能存在的开销。

首先来看一下费用到底要用多少

可以看到，从2024年2月开始，只要有用到公网IP的地方，就按一小时0.005刀收费，对应到中国区域是0.033元。

下面我们来讲一讲，公有IPv4地址的分类

1. EC2 Public IPv4地址

顾名思义，和EC2有关，当你开启了自动分配公网IP时，EC2启动后就会由AWS分配一个公网IP，这个IP并不属于你的账户，所以当EC2停止后，IP会被释放。在2024年2月之前，由于这些IP属于AWS且在生命周期中始终和EC2绑定，所以它是免费的，但是在2024年2月后，它将收费。

2. Elastic IP (IPv4)

EIP是我们主动向AWS申请（并且AWS给每个账户有默认配额，需要额外申请才能提升）的IP，在2024年2月之前，EIP申请后没有绑定到具体服务或者EC2的，即空闲的EIP是收费的，而当我们将EIP绑定到EC2或者服务后，EIP是免费的。此次收费策略的调整，则是无论EIP是否绑定服务，均按照统一价格进行收费。

3. 由各种服务管理的公共IPv4地址

这个分类的IP，是我们之前往往不重视的另外一部分，大家可以参考这个文档（最下面）来看，https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#pricing

例如我们的RDS开启了公网IP，那么这个IP就是由服务管理的公共IP地址，同类的场景也有MQ、RedShift，甚至于WorkSpaces，这些之前有AWS服务所创建的公共IPv4地址，将从2024年2月开始收费。

4. BYOIP

顾名思义，由你自己携带到AWS的IP段，是免费的。

接下来，我们便可以使用AWS 在IPAM中提供的最新功能，Public IP Insights来对我们现有的IP类型及数量进行分析。由于中国区并没有上线IPAM，但是上线了Public IP Insights（https://docs.amazonaws.cn/en_us/aws/latest/userguide/vpc.html可以看到IPAM中只有PIP Insights可用），所以我们通过以下路径访问中国区的Public IP Insights

https://cn-northwest-1.console.amazonaws.cn/ipam/home?region=cn-northwest-1

可以看到，我们目前在使用的公网IPv4地址有123个，我们简单做一个计算，123*0.033*730=2963元，即从明年2月开始，我们每个月将为IPv4地址付出约三千元（在此之前我们并没有闲置的EIP，并不需要为IPv4地址付费）。

那么如何做优化呢？

1. 使用IPv6

笔者也写了关于AWS IPv6网络的文章，可参考https://blog.sean.consulting/aws-ipv6-only-subnet-and-nat64/同时也有以下文章供大家参考

同时AWS官方也有一个参考架构的PDF帮助大家进行改造

https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/IPv6-reference-architectures-for-AWS-and-hybrid-networks-ra.pdf

2. 优化IPv4使用的最佳实践

这里就包含了关闭自动分配公网IP(ECS, RDS等等)，使用EC2 Instance Connect访问EC2，集成NAT GW和ELB来减少公共IP的使用等等，当然也包含了使用Global Accelerator，这些可以参考这篇文章，里面有更详细的解释。

https://aws.amazon.com/blogs/networking-and-content-delivery/identify-and-optimize-public-ipv4-address-usage-on-aws/

总结

随着IPv4采购价格的不断提升（或许也是利润率的下降），AWS终于把这一刀砍了下去，也说不定时开了个坏头，可以预见的是各大CSP都将跟进。

IPv4地址匮乏说了有十几年了，终于有服务商狠下心来动手了，笔者多次往返中美，可以看到移动网美国纯IPv6的覆盖率已经非常高了，希望我们已经赶了个晚集的IPv6可以更争气一些。

前者便是Route53 Resolver所提供的Log Query功能

https://www.amazonaws.cn/new/2021/amazon-route-53-resolver-supports-vpc-dns-query-logging-available-china-regions

需要注意的是直接访问IP由于没有DNS解析过程，所以并不会被记录下来。

而后者便是DNS Firewall功能

https://www.amazonaws.cn/new/2022/amazon-route-53-resolver-dns-firewall-is-now-available/

本文将创建VPC，并且创建实例进行Log Query以及DNS Firewall的初探。

创建VPC，我们使用最新的Console创建VPC，如下图

目前VPC创建的界面已经非常直观了，左边可以选择要创建的内容，例如几个公有子网，几个私有子网，几个NAT GW以及要不要创建VPC Endpoint，右侧则可以直观的看出，VPC创建后的拓扑。

在此我们简单创建一个拥有一个公有子网，并且有一个S3 Endpoint的VPC。

通过workflow，我们可以看到这个过程中实际执行了什么，并且生成了什么资源。

然后我们开启Route53 Resolver的Query Logging功能，这需要我们定位到Route 53这个服务中

我们配置Query Logging，并且将日志输出到CloudWatch Log Group中

最后我们得到了一个Query Logging配置

我们跳转到CloudWatch Logs服务，可以看到测试用的第一条Log已经正常写入

这是我们便可以在VPC中创建我们的EC2了。

我们创建EC2时，选择正确的IAM Profile，并且不添加Key，我们将使用EC2 Instance Connect来连接它。

接下来我们使用EC2 Instance Connect来连接Instance

用户名保留ec2-user

我们创建DNS Firewall Rule Group

在新增规则页面，我们添加一个domain list，并且当请求匹配时，我们返回NXDOMAIN

创建后，将Rule Group与VPC关联，这个步骤可能需要稍等一会儿。

绑定之后，实例并不是实时就被防护了，稍等一会儿我们就能得到下面这个结果。

可以看到DNS防火墙已经按照预期工作了，通过查看CloudWatch Log我们也得到了防火墙工作的证明。

总结

为了满足审计需要的R53 Query Logging，所产生的日志也可以存储到S3中（比CloudWatch Logs要便宜），它仅满足审计需要，常常要结合DNS Firewall对特定域名进行阻断。

门票的价格是1099美金，提前报名可以有300美金的折扣，笔者今年很早就联系了AWS中国的安全布道师Jason老师，希望能有一些Program来支持此次re:Inforce行程，无奈AWS反应比较慢，笔者就自行购入了门票并计划安排了行程。

笔者先行于5月31日由香港到了温哥华，并于3日到达了Los Angeles，实际上Los Angeles离Anaheim还有40~60分钟车程。

这次会议汇集了AWS的专家和行业领先的客户，以及AWS安全能力合作伙伴，包括CrowdStrike、Datadog、Palo Alto Networks、Snyk和Wiz​。

如果你有参与re:Invent的经验，会发现re:Inforce就是一个小规模的re:Invent，这两个会议都包含

Keynote，例如本次会议由AWS的CISO CJ Moses主持，这位大佬就是一个提词器狂魔，而且内容其实就那样吧。

Leadership sessions，其实就是由一些AWS专家来谈谈几个目前比较火的安全主题，具体可以参考

https://reinforce.awsevents.com/leadership-sessions/

Expo，这个就是传统保留项目了，上面有各种厂商和合作伙伴来推介他们的产品，并且你可以得到一些swags，同时也有AWS Builder Lounge及AWS安全产品团队和客户做一些交流，re:Inforce的Expo规模比re:Inforce要大非常多。

Breakout content，就是一些专项内容了，比较有趣的是Anaheim的会展中心会场有一个Stage，有点类似于reInvent的Content Hub，同一个空间里面有多个内容同时输出，但是不同的点是，re:Inforce的不同的Stage并不是overflow，而是一个需要你佩戴耳机才能听清speaker讲什么的空间，笔者听了多场breakout content，集中在网络、Nitro方面。

AWS Builder Labs，这种就是要有动手能力需要带你的笔记本了，往往这种Lab耗时比较久，在时间为王的这种会议上，对于笔者的吸引力并不大。

再回到流水账，6月12日周一，由Los Angeles的比佛利山附近出发，到Anaheim，不得不说，Anaheim由迪士尼乐园而出名，周围配套都是各式各样的酒店，这就有个小tips，会议主办方安排的协议酒店位置自然是最好的，但是一定要提前预定，名额有限。

是日拿了Badge，并且和Jason老师以及国内来的小伙伴汇合。傍晚去吃了眉州东坡，其实这也是一个有名的连锁饭店，出品比较正常。

6月13日，Keynote，不得不说re:Inforce路标还是准备的不够完备，会场并不大，但是有时候就走得找不到路了，另外bre:Inforce的饭是真简单，和其门票相比有点寒酸，下午茶歇也bb无力吐槽。

6月14日，中午去吃了In&Out。

下午听了Bedrock的一个breakout session，终于大概对AWS这个犹抱琵琶的产品有个基本的了解即

SageMaker是一个Tools，啥都能干，也可以用来做任何事情，但是本身面对的不是client，而Bedrock是一个裁剪并且包装的SageMaker，是个product，只有几个大模型，能做的事情也就是微调，给个界面，给个输出，是个产品化了的东西，上面除了AWS的大模型Titan以外，还有其他家的，Titan目前也不支持中文。

总结，如果不是AWS提供门票，路费也可以报销的话，更建议大家去re:Invent。

https://www.amazonaws.cn/new/2023/amazon-rds-multi-az-db-cluster-launch-for-china-regions/

本文简单对比一下两种多可用区部署的不同，更多的讨论我们将在之后的文章中进行。

在很长一段时间内，AWS的RDS服务，提供的托管的MySQL/PgSQL提供的是一种叫做多可用区数据库实例的部署方式，这通常由一个Primary和一个Standby Replica组成，简单的结构如下

这里由几个点需要注意，首先Primary负担所有的读取和写入请求，在不同AZ的Replica只是Standby，它只用来做FO，并不承担读取流量，即冷备。但你仍需要为它付额外的费用，在这种场景下如果你还需要一个Replica来offload 读取请求，则你需要创建Read Replica。

多可用区数据库实例的部署，FO的时间通常在60-120s左右，但是Standby的Repica是同步的。

需要注意的是，多可用区数据库实例对数据库实例的类型没有任何要求。

而自2021年11月推出，2022年GA，2023年引入中国区域的多可用区部署，被叫做多可用区数据库集群，由三个实例组成，Replication不同于多可用区数据库实例，不需要所有的节点都确认才能确认，只需要有一个Reader确认即可。其结构如下图。

多可用区数据库集群，Reader节点是热备，所以可以承担读取流量，并且FO的时间典型值会缩短到35s以下。

需要注意的是，多可用区数据库集群利用了具有实例存储的实例类型，实例存储用来存储事务，而EBS作为永久存储。

所以多可用区数据库集群和实例相比，有以下几个优势：

1. 更快的写入性能，这利用了事务日志实例存储

2. 更快的故障转移，35s对比于之前的60-120s

3. Reader节点可以承载读取流量

4. 两个Reader只需要一个确认即可确认，优化了Replication

但是我们同时要注意到多可用区数据库集群也有一些限制，具体可以参考

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html

其实在接下来的5月14日，亚马逊云科技中国区域紧跟着Global推出了Optimized Reads，即下面这个

https://aws.amazon.com/cn/blogs/china/introducing-optimized-reads-for-amazon-rds-for-postgresql/

相关的文章也可以参考

https://aws.amazon.com/cn/blogs/china/introducing-optimized-reads-for-amazon-rds-for-postgresql/

https://aws.amazon.com/about-aws/whats-new/2023/03/application-load-balancer-tls-1-3/

理论性能上可能有微小的变化，但是这种客户端为主的Feature，我们更多的是为了一个潜在的安全性和可能性，姑笔者结合ChatGPT生成以下如何修改ALB的Cipher Suite，一方面检验GPT4的ChatGPT在解答此类问题上是否有问题，一方面也帮助大家完成TLS1.3的开启。

修改AWS ALB的Cipher Suite主要涉及以下几个步骤：

1. 登录AWS管理控制台并导航至EC2控制台。

2. 在左侧导航栏中，点击“Load Balancers”进入负载均衡器管理界面。

3. 选择要修改的ALB，然后点击“Listeners”选项卡。

4. 选择使用的监听器（如HTTPS），点击“Edit”。

5. 在“Edit listener”窗口中，找到“Security Policy”选项。

6. 点击“Security Policy”旁边的下拉框，选择一个预定义的安全策略或创建一个自定义策略。预定义的安全策略包含一组AWS推荐的Cipher Suites，而自定义策略允许您指定特定的Cipher Suites。

7. 若要创建自定义策略，请在AWS Certificate Manager（ACM）中操作。转到ACM控制台，选择“Custom TLS policies”选项卡，然后点击“Create custom policy”。在此页面上，您可以指定自定义策略的名称、TLS版本以及所需的Cipher Suites。完成后，点击“Create”。

8. 返回“Edit listener”窗口，选择您刚刚创建的自定义安全策略。

9. 最后，点击“Save changes”以保存对监听器的更改。您的应用负载均衡器现在将使用所选的Cipher Suite处理传入的SSL/TLS连接。

通过上述步骤，您已成功修改了AWS ALB的Cipher Suite。这有助于提高您应用的安全性和性能。为了确保您的ALB始终符合最佳安全实践和行业标准，请定期检查并更新您的Cipher Suite。AWS会定期发布新的预定义安全策略，以便适应不断变化的加密环境。保持与最新安全标准的一致性可帮助防止潜在的安全威胁，并确保您的应用在加密和数据保护方面始终处于领先地位。

大概的步骤是没有问题的，但是需要说明的是从第六步开始就放飞自我了，一个很重要的知识点是

ALB并不支持自定义安全策略（Security Policy），但是它的前身，CLB是支持的。

这就更不用说之后的789三个步骤就是纯纯的杜撰。

我们看一个实际的截图如下。

其中以TLS13为构成的Security Policy提供了TLS1.3，而各个Security Policy的详细构成，可以参考这个文档。

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies

这里还有一个有趣的点，我们之前使用的Policy是

ELBSecurityPolicy-TLS-1-2-Ext-2018-06

它是一个TLS最低版本是1.2，但是提供更好兼容性的Policy，考虑继续保证兼容性，我们选择它对应的TLS1.3的Policy，然而TLS1.3却提供了两个Ext

ELBSecurityPolicy-TLS13-1-2-Ext1-2021-06

ELBSecurityPolicy-TLS13-1-2-Ext2-2021-06

通过对比，可以发现TLS1.2 Ext的TLS1.3版本实际上为TLS1.3 Ext2

最后补充一个知识，随着客户对安全传输的要求不断加强，以及各个安全指南认定TLS1.0/1.1为不安全，作为服务端，我们就需要分析Legacy站点的访问中有多少以TLS1.0/1.1发起的。这时对于ALB而言，我们便可以从访问日志中找到这个部分。以下是一个ALB访问日志的示例

h2 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
10.0.1.252:48160 10.0.0.66:9000 0.000 0.002 0.000 200 200 5 257
"GET https://10.0.2.105:773/ HTTP/2.0" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337327-72bd00b0343d75b906739c42" "-" "-"
1 2018-07-02T22:22:48.364000Z "redirect" "https://example.com:80/" "-" "10.0.0.66:9000" "200" "-" "-"

可以看到这个HTTP/2请求，使用了TLS1.2。而最简单的方式便是使用Athena对于存储在S3中的ALB访问日志做聚合，这样方便我们对Migration的影响做出一个基本的估计。

1. Mountpoint for Amazon S3（内测版）：Amazon S3 的开源文件客户端

2. 现已正式推出：AWS Data Exchange for Amazon S3

3. Amazon S3 多区域接入点现在支持跨多个 AWS 账户的复制数据集

4. 作为CloudFront 源的 S3 对象Lambda 接入点的别名

5. 简化本地网络的私有连接

6. Outposts 上的本地 Amazon S3 复制

7. Amazon OpenSearch 安全分析

笔者对第一项和第五项有一些兴趣，首先简单说一下第五项。

优化本地网络的私有连接，其实给本地网络提供了S3的私有DNS解析，而不需要更改应用中的S3端点。

现在我们看看第一项。

首先S3作为一个对象存储，自从其诞生之日起就有很多个S3 Mount的项目，将S3的Bucket映射成本地存储，大都设计成为兼容POSIX的大部分操作，这些项目简单罗列一下开源的有

https://github.com/s3fs-fuse/s3fs-fuse

https://github.com/kahing/goofys

而商业化的产品也有

https://objectivefs.com/

当然AWS官方的Storage Gateway也可以看作这其中的一种。

这些Mount的方案和EFS或者FSx不同，都是将S3的API兼容实现的，用起来非常方便，这次周年发布的Mountpoint for Amazon S3实际上也是类似的项目，但是它的应用场景更明确，所以在设计上不再尽力满足所有POSIX操作。需求越明确，实现成本和性能开销就越小，这可以从这篇DOC看出。

https://github.com/awslabs/mountpoint-s3/blob/main/doc/SEMANTICS.md

需要注意的是，目前Mountpoint还处在Alpha，还只支持Linux，操作上也只读取，接下来我们就按照官方的指南来实际操作一下。

本次使用了Amazon Linux 2023环境，目前官方尚未提供二进制包，所以以下过程都是为了编译。

sudo yum install git fuse fuse-devel cmake3 clang-devel
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
git clone --recurse-submodules https://github.com/awslabs/mountpoint-s3.git
cd mountpoint-s3
cargo build –release

要下载的依赖非常多，c6g.medium编译也使用了13分钟。

请请配置一个好的网络，或者在AWS EC2上完成这个实验。

接下来就比较简单了，配置凭据可以用credentials，自然也可以用IAM role。

mkdir ~/s3mpdemo
mount-s3 my-s3-bucket-name ~/s3mpdemo --endpoint-url https://s3.cn-northwest-1.amazonaws.com.cn --region cn-northwest-1

注意，因为我们这里使用的是中国区，所以需要加上endpoint参数。

执行后不会输出，但是已经可以看到它在后台运行，这时我们进入创建的目录就可以看到我们bucket下的文件了。

可以和console印证下。

事实上就目前mountpoint的完成度来看，已经符合我们之前使用的s3fs的场景，所以我们会直接将这个产品用于生产环境，这样可以获得更多的反馈。

实际上AWS的这个产品也采用了存储与计算分离的设计，本质上还是和MongoDB不同的，只是在API上做到了部分兼容，在此次Elastic Clusters发布前，DocumentDB Clusters和Aurora一致，都需要选择对应的实例类型，而这些实例类型就固定了一定的性能，关于选择实例类型的最佳实践可以参考

https://docs.aws.amazon.com/documentdb/latest/developerguide/best_practices.html#best_practices-instance_sizing

同时也可以使用这个第三方工具来进行计算https://sizing.cloudnativedb.com/

值得注意的一点是，DocDB和无Sharding的MongoDB一样（当然也可以说DocDB不支持Sharding），其写入节点只有一个，再组合固定的实例类型，这就导致了DocDB的写入性能存在瓶颈。

而今年的reInvent，AWS则推出了自己的Sharding方案，同时也消除了实例类型这个变量，同时冠以一个很模糊的名字DocumentDB Elastic Clusters，目前可用的区域有限，我们来初探一下。

关于今年reInvent，DocDB的发布，大家也可以观看DAT-219来获得更多的信息。

https://www.youtube.com/watch?v=Eg0tJEAZVhU

可以看到在Elastic Cluster GA的区域中，创建Cluster的过程的第一步就是让你选择Cluster的Type

接下来则是选择shard的数量，以及每个shard的vCPU容量，这里已经可以看出并不是instance-based的了，你无法选择shard的实例的类型。

实际上创建过程就结束了，这里消弭了很多复杂度。

我们结合The Register的文章再来理解一下，Elastic Cluster借助MongoDB sharding         API来创建分片的集合，让数据可以分布在多个shard里面，每个shard有其writer，这样实际上就扩展了读写的能力，而AWS在这个过程中实质上简化了集群的维护过程——如果你有MongoDB集群创建维护经验的话，你会清楚无Shard的MongoDB集群是简单的，但是一旦考虑Shard，那么集群的规模、node的升级维护都是一个非常棘手的问题，而AWS借助其控制平面来帮你处理这些所有的问题。这个思路我们也可以在今年发布的OpenSearch Serverless看出，两者都是极大程度上简化了集群的运维成本。

我们回到一个应用或者服务的实际的开发过程，这种简化了的Serverless服务，实际上提供了一种一开始就基于超大数量级开发的云应用可能。先前我们基于对数据库集群的维护的畏惧以及对够用就好的想法，导致了一开始选择了常规的数据库部署方式，等应用扩展到一定规模了，再来进行数据库的再设计，还增加了迁移的开销。实际上现代应用，或者基于云的现代应用再数据建模和数据库设计上已经有了充足的经验了，我们很乐意看到，All Serverless正在下沉到服务的基石——数据上。

近几周CHATGPT非常火，我们也不能免俗试试用CHATGPT来解答一下SAA问题，看看CHATGPT的思路准确不准确。

本次选择SAA的官方样题，链接如下

https://d1.awsstatic.com/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Sample-Questions.pdf

我们在此抽样一道题来做一下解答。

An application running on AWS uses an Amazon Aurora Multi-AZ DB cluster deployment for its database. When evaluating performance metrics, a solutions architect discovered that the database reads are causing high I/O and adding latency to the write requests against the database. What should the solutions architect do to separate the read requests from the write requests?

A) Enable read-through caching on the Aurora database.

B) Update the application to read from the Multi-AZ standby instance.

C) Create an Aurora replica and modify the application to use the appropriate endpoints.

D) Create a second Aurora database and link it to the primary database as a read replica.

先把题目直接抛给CHATGPT，得到以下内容

除了Global Database有点发散以外，其实它已经提出了Replica的方案，并且进一步提到可以使用Redis来offload request，当然现在Serverless当道，最后还提了一下Aurora Serverless（勉强算是一种提供任意规模性能方案

这时我们把选项给他，看他如何判断

Hmm，有点一言难尽，我们看看它对C是如何解释的

Option C) Create an Aurora replica and modify the application to use the appropriate endpoints is not correct because an Aurora replica refers to a read replica, not a separate DB cluster. To separate read requests from write requests, you need to create a separate Aurora DB cluster and link it to the primary cluster as a read replica.

其实这也可以看到CHATGPT的问题，虽然它的逻辑可能是自洽的，文字也很多，但是事实上它是不清楚的，我也看到很多朋友直接拿它来生成IAM Policy了，内容也是不完整。

总结一下，CHATGPT可以用来解决一些通用的问题（然而这些问题也是最不需要它来解决的问题），可能用来写文章比较合适。

本文所有资源都在ap-east-1 (HKG)区域创建。

一、创建VPC、子网、互联网网关（IGW）、仅出口网关（EIGW）、NAT网关以及路由表
1. 创建VPC

aws ec2 create-vpc --cidr-block 10.0.0.0/16 --amazon-provided-ipv6-cidr-block

记录返回的id，返回结果中表明IPv6地址块正在分配，这时我们可以describe一下

aws ec2 describe-vpcs --vpc-id vpc-0228200a8c51f2f75

便可以拿到我们已分配的IPv6地址块，"2406:da1e:55c:ee00::/56"
2. 创建子网    

2.1 创建双栈的子网

aws ec2 create-subnet --vpc-id vpc-0228200a8c51f2f75 --cidr-block 10.0.0.0/24 --ipv6-cidr-block 2406:da1e:55c:ee00::/64

2.2 创建IPv6 Only子网

aws ec2 create-subnet --vpc-id vpc-0228200a8c51f2f75 --ipv6-cidr-block 2406:da1e:55c:ee01::/64 --ipv6-native

我们可以看出来这两者的区别，如果不含ipv6-native参数，则必须包含—cidr-block来指定IPv6地址块。
3. 配置双栈子网为公有子网    3.1 创建互联网网关，这一步是为了将双栈子网配置为公有子网的前置工作

aws ec2 create-internet-gateway

3.2 将VPC与网关关联，这一步不会有返回

aws ec2 attach-internet-gateway --vpc-id vpc-0228200a8c51f2f75 --internet-gateway-id igw-0830a75ac7836b885

3.3 进一步创建公有子网的路由表，注意记录路由表的id

aws ec2 create-route-table --vpc-id vpc-0228200a8c51f2f75

3.4 由于这个公有子网是双栈的，所以我们需要在路由表中创建两条路由

aws ec2 create-route --route-table-id rtb-03e17b7efdde4b8c2 --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0830a75ac7836b885
aws ec2 create-route --route-table-id rtb-03e17b7efdde4b8c2 --destination-ipv6-cidr-block ::/0 --gateway-id igw-0830a75ac7836b885

3.5 我们将双栈子网与该路由表关联，这样该子网便配置为公有子网了。

aws ec2 associate-route-table --subnet-id subnet-0c778dcea7d948e01 --route-table-id rtb-03e17b7efdde4b8c2

4. 创建NAT网关，以用于之后NAT64的配置。    

4.1 首先需要创建一个IPv4 EIP

aws ec2 allocate-address

4.2 然后创建NAT网关

aws ec2 create-nat-gateway --allocation-id eipalloc-04558a754d4a94b77 --subnet-id subnet-0c778dcea7d948e01

4.3 NAT网关的创建需要一定的时间，我们可以用describe来确认

aws ec2 describe-nat-gateways --nat-gateway-ids nat-07acd181fb9959117

5 配置IPv6 Only子网为仅出口私有子网    

5.1 创建仅出口网关

aws ec2 create-egress-only-internet-gateway --vpc-id vpc-0228200a8c51f2f75

5.2 创建路由表（但是目前我们还不能创建IPv6 Only的路由表）

aws ec2 create-route-table --vpc-id vpc-0228200a8c51f2f75

5.3 在路由表中创建路由，将IPv6流量路由到仅出口网关

aws ec2 create-route --route-table-id rtb-01c06b0d23482d25c --destination-ipv6-cidr-block ::/0 --egress-only-internet-gateway-id eigw-00f2192f26d173465

5.4 最后将IPv6 Only子网和该路由表关联

aws ec2 associate-route-table --subnet-id subnet-01f2091f8d394166c --route-table-id rtb-01c06b0d23482d25c

6. 添加NAT64路由

该IPv6 Only子网就成功配置了IPv6仅出口私有子网，为了之后使用NAT64访问IPv4 Only资源，我们需要进一步添加路由到该路由表中。

aws ec2 create-route --route-table-id rtb-01c06b0d23482d25c --destination-ipv6-cidr-block 64:ff9b::/96 --nat-gateway-id nat-07acd181fb9959117

7. 对公有子网进行配置接下来我们对子网做配置，对于公有子网，我们打开自动分配IPv6、公有IPv4地址，并且打开资源名称

aws ec2 modify-subnet-attribute --subnet-id subnet-0c778dcea7d948e01 --assign-ipv6-address-on-creation
aws ec2 modify-subnet-attribute --subnet-id subnet-0c778dcea7d948e01 --map-public-ip-on-launch
aws ec2 modify-subnet-attribute --subnet-id subnet-0c778dcea7d948e01 --private-dns-hostname-type-on-launch resource-name
aws ec2 modify-subnet-attribute --subnet-id subnet-0c778dcea7d948e01 --enable-resource-name-dns-a-record-on-launch
aws ec2 modify-subnet-attribute --subnet-id subnet-0c778dcea7d948e01 --enable-resource-name-dns-aaaa-record-on-launch

8. 对于IPv6仅出口私有子网进行配置

我们打开DNS64

aws ec2 modify-subnet-attribute --subnet-id subnet-01f2091f8d394166c --enable-dns64

至此网络部分就配置完成了。
二、创建实例并测试

下面这个部分，我们将在公有子网和IPv6仅出口私有子网中，启动两个实例。

1. 公有子网实例（双栈）
1.1 创建密钥对

aws ec2 create-key-pair --key-name IPv6Demo --query "KeyMaterial" --output text > IPv6Demo.pem

1.2 创建安全组

aws ec2 create-security-group --group-name SSHAccess --description "Security group for SSH access" --vpc-id vpc-0228200a8c51f2f75

1.3 为它添加规则

aws ec2 authorize-security-group-ingress --group-id sg-03f4bc74bd9c97f62 --protocol tcp --port 22 --cidr 0.0.0.0/0

1.4 创建实例

aws ec2 run-instances --image-id ami-0f6b3e4242c6690f2 --count 1 --instance-type t4g.small --key-name IPv6Demo --security-group-ids sg-03f4bc74bd9c97f62 --subnet-id subnet-0c778dcea7d948e01

实例创建需要时间，稍等片刻，我们describe一下，拿到它的IPv4地址（以及IPv6地址）

aws ec2 describe-instances --instance-id i-0850f347a6c453e11

1.5 尝试登录

ssh ec2-user@18.xxx.42.221 -i IPv6Demo.pem

我们测试一下，

[ec2-user@i-0850f347a6c453e11 ~]$ ping -n ietf.org
PING ietf.org (50.223.129.194) 56(84) bytes of data.
64 bytes from 50.223.129.194: icmp_seq=1 ttl=38 time=157 ms
64 bytes from 50.223.129.194: icmp_seq=2 ttl=38 time=157 ms
64 bytes from 50.223.129.194: icmp_seq=3 ttl=38 time=157 ms
64 bytes from 50.223.129.194: icmp_seq=4 ttl=38 time=157 ms

可以看到正常返回这时我们尝试一下ping6

[ec2-user@i-0850f347a6c453e11 ~]$ ping6 -n ietf.org
PING ietf.org(2001:559:c4c7::100) 56 data bytes
64 bytes from 2001:559:c4c7::100: icmp_seq=1 ttl=43 time=160 ms
64 bytes from 2001:559:c4c7::100: icmp_seq=2 ttl=43 time=160 ms
64 bytes from 2001:559:c4c7::100: icmp_seq=3 ttl=43 time=160 ms
64 bytes from 2001:559:c4c7::100: icmp_seq=4 ttl=43 time=160 ms

可见ping6也是正常的

2. IPv6仅出口私有子网实例 (IPv6 Only)

2.1 创建安全组

aws ec2 create-security-group --group-name SSHAccessRestricted --description "Security group for SSH access from bastion" --vpc-id vpc-0228200a8c51f2f75

2.2 添加规则，为了简单起见，直接放行来自Bastion的所有流量

aws ec2 authorize-security-group-ingress --group-id sg-00b2064115792ce7e --protocol all --source-group sg-03f4bc74bd9c97f62

2.3 创建EC2

aws ec2 run-instances --image-id ami-0f6b3e4242c6690f2 --count 1 --instance-type t4g.small --key-name IPv6Demo --security-group-ids sg-00b2064115792ce7e --subnet-id subnet-01f2091f8d394166c

同样可以稍等片刻后，使用describe拿到IPv6地址

aws ec2 describe-instances --instance-id i-012b271b4229728a8

这时我们可以尝试先登录跳板机，然后用跳板机登录这台实例

ssh-add IPv6Demo.pem
ssh -A ec2-user@18.xxx.42.221
ssh ec2-user@2406:da1e:55c:ee01:c8f7:3b17:6323:1a16

可以正常登录了

[ec2-user@i-0850f347a6c453e11 ~]$ ssh ec2-user@2406:da1e:55c:ee01:c8f7:3b17:6323:1a16
Last login: Thu Sep 15 15:43:01 2022 from 2406:da1e:55c:ee00:aa20:xxxx:7174:8028
       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|
https://aws.amazon.com/amazon-linux-2/
3 package(s) needed for security, out of 10 available
Run "sudo yum update" to apply all updates.
[ec2-user@i-012b271b4229728a8 ~]$

这时我们首先确认IPv6互联网是通的

[ec2-user@i-012b271b4229728a8 ~]$ ping6 -n ietf.org
PING ietf.org(2001:559:c4c7::100) 56 data bytes
64 bytes from 2001:559:c4c7::100: icmp_seq=1 ttl=43 time=161 ms
64 bytes from 2001:559:c4c7::100: icmp_seq=2 ttl=43 time=161 ms
64 bytes from 2001:559:c4c7::100: icmp_seq=3 ttl=43 time=161 ms
64 bytes from 2001:559:c4c7::100: icmp_seq=4 ttl=43 time=161 ms

3. 测试由于目前金数据是IPv4 Only，正好可以用来模拟仅IPv6的EC2通过NAT64访问IPv4 Only互联网资源的情况。

3.1 我们确认解析

[ec2-user@i-012b271b4229728a8 ~]$ dig jinshuju.net AAAA
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> jinshuju.net AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15433
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;jinshuju.net.                  IN      AAAA
;; ANSWER SECTION:
jinshuju.net.           300     IN      AAAA    64:ff9b::3453:27fe
jinshuju.net.           300     IN      AAAA    64:ff9b::3453:b9a5
jinshuju.net.           300     IN      AAAA    64:ff9b::3453:c172
;; Query time: 150 msec
;; SERVER: fd00:ec2::253#53(fd00:ec2::253)
;; WHEN: Thu Sep 15 15:53:12 UTC 2022
;; MSG SIZE  rcvd: 125

可以看到，DNS64将无AAAA地址的A地址，转换为64:ff9b::/96的AAAA地址返回给客户端，这时我们curl一下

[ec2-user@i-012b271b4229728a8 ~]$ curl https://jinshuju.net/health-check -I
HTTP/2 200
date: Thu, 15 Sep 2022 15:54:48 GMT

可以看到正常返回。

3.2 Amazon Time Sync Service

[ec2-user@i-012b271b4229728a8 ~]$ chronyc sources -v
  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 169.254.169.123               3   4   377     9  +4315ns[+5194ns] +/-  379us
^- time.cloudflare.com           3   8   377     7  +3983us[+3983us] +/-   75ms
^- the.lonely.email              2   8   377     6   -100us[ -100us] +/-   29ms
^- time.cloudflare.com           3   8   377     6  +4079us[+4079us] +/-   76ms
^- ntp.xtom.com.hk               3   8   377     0    -90us[  -90us] +/- 3906us

比较奇怪的是只有IPv4，遂打开/etc/chrony.conf，确认默认情况下该配置默认就是IPv4，更改为IPv6端点

server fd00:ec2::123 prefer iburst minpoll 4 maxpoll 4

重启chronyd后得到想要的结果

[ec2-user@i-012b271b4229728a8 ~]$ sudo systemctl restart chronyd
[ec2-user@i-012b271b4229728a8 ~]$ chronyc sources -v
  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? fd00:ec2::123                 3   4     3     2    -11us[  -11us] +/-  432us
^? 64:ff9b::dfff:b902            1   6     7     0   +257us[ +257us] +/- 2289us
^? ntp.xtom.com.hk               3   6     3     2    +94us[  +94us] +/- 2866us
^? tanss.it-risch.de             2   6     3     2    +14ms[  +14ms] +/-  179ms
^? coffre.bitschine.fr           2   6     3     2    -20ms[  -20ms] +/-  128ms

3.3 Metadata service

[ec2-user@i-012b271b4229728a8 ~]$ curl http://169.254.169.254/latest/meta-data/ami-id
ami-0f6b3e4242c6690f2
[ec2-user@i-012b271b4229728a8 ~]$ curl http://[fd00:ec2::254]/latest/meta-data/ami-id
curl: (28) Failed to connect to fd00:ec2::254 port 80 after 130547 ms: Connection timed out

居然超时了，确认这里还需要进一步打开IPv6

aws ec2 modify-instance-metadata-options --instance-id i-012b271b4229728a8 --http-protocol-ipv6 enabled
[ec2-user@i-012b271b4229728a8 ~]$ curl http://[fd00:ec2::254]/latest/meta-data/ami-id
ami-0f6b3e4242c6690f2

正常了。

3.4 Amazon VPC DNS Service

[ec2-user@i-012b271b4229728a8 ~]$ cat /etc/resolv.conf
options timeout:2 attempts:5
; generated by /usr/sbin/dhclient-script
nameserver fd00:ec2::253
nameserver 10.0.0.2

注意事项

1. IPv6 Only的实例，究竟是不是没有IPv4？答案是有IPv4，如下

[ec2-user@i-012b271b4229728a8 ~]$ ifconfig
eth0: flags=4163  mtu 9001
        inet 169.254.229.223  netmask 255.255.255.255  broadcast 0.0.0.0
        inet6 fe80::405:44ff:fe0c:414c  prefixlen 64  scopeid 0x20
        inet6 2406:da1e:55c:ee01:c8f7:3b17:6323:1a16  prefixlen 128  scopeid 0x0
        ether 06:05:44:0c:41:4c  txqueuelen 1000  (Ethernet)
        RX packets 50762  bytes 67759873 (64.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5627  bytes 1098359 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 96  bytes 7520 (7.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 96  bytes 7520 (7.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

这也就是为什么NTP和Metadata Service可以正常工作的原因。

2. NAT64既可以使IPv6 Only的对象访问互联网资源，也可以访问VPC内的其他内网资源，比如原IPv4的RDS。
3. 补充资料，里面有更多场景的IPv6架构https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/IPv6-on-AWS.html
总结

AWS通过多年的布局，终于在2021 reInvent完善了对IPv6 Only的支持，同时我们也看到今年多个更新都为各个服务增加了IPv6支持。另外以上所有的步骤，均可以在亚马逊云科技中国区域实现。

TTS (Text-to-Speech)基本上是大厂的标配了，在公有云服务商层面，Azure的TTS最成熟且最丰富，Google和Amazon则是不相伯仲的一般。

Polly于2016年11月正式提供服务，并且于2018年9月发布了Polly的首个普通话支持，可以点击这个语音听一下这个感觉。

标准TTS-音频1音频：00:0000:02

可以明显感觉出来合成的味道很浓，而且字之间还有一些停顿，并不是很流畅。

2019年7月Polly增加了Neural TTS的支持，简单来说就是更自然更流畅了，但是NTTS并没有同时带入到普通话，直到标准普通话支持发布的4年后，即2022年8月，Polly终于增加了NTTS版本的普通话支持，可以点击这个语音听一下这个感觉。

NTTS-音频2音频：00:0000:02

不论语调如何，至少在连贯性上已经强于标准TTS。

然而Amazon的控制台是在是太过简陋了，如下图

即便是你点开Additional settings也没有多少选项可选，这时我们就可以使用SSML来丰富我们的用法。

Polly支持的SSML Tags可以参考这个文档

https://docs.aws.amazon.com/polly/latest/dg/supportedtags.html

我们试一个比较有趣的，例如下面这个例子

SSML我也粘在下面，

<speak>
     <lang xml:lang="cmn-CN">这里是肖恩咨询，向你问好。</lang>.
</speak>

英语NTTS-音频3音频：00:0000:03

需要注意的是NTTS的中文，lang code为cmn-CN，通过这个语音我们可以听出来美国人读中文的感觉。

还有一个比较有趣的例子是多音字的处理。

比如以下这个对联，我们先听一下NTTS不做任何修改直出的语音。

普通话NTTS-未修正音频：00:0000:04

显然有音不正确，这时候我们就需要对部分的读音进行微调。

<speak>
海水
<phoneme alphabet="x-amazon-pinyin" ph="chao2">朝</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="zhao1">朝</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="zhao1">朝</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="chao2">朝</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="zhao1">朝</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="chao2">朝</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="zhao1">朝</phoneme>
落，浮云
<phoneme alphabet="x-amazon-pinyin" ph="zhang3">长</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="chang2">长</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="chang2">长</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="zhang3">长</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="chang2">长</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="zhang3">长</phoneme>
<phoneme alphabet="x-amazon-pinyin" ph="chang2">长</phoneme>
消
</speak>

即单独标记每个字的拼音，这时我们就有如下语音。普通话NTTS-已修正音频：00:0000:05当然我搞了一个非常极端的例子，导致Polly完全无法正常阅读，正常情况下多音字一是可以在组合中发正常的音（可以听这个对联原始的语音，“朝落”两个字），二是也不存在这么多多音字的情况。以上简单试用了下Polly，不得不说Amazon在这方面积累还是不如Microsoft深厚，十分推荐大家试用以下Azure的TTShttps://azure.microsoft.com/en-us/services/cognitive-services/text-to-speech/#overview首先在语音上的选择就非常多

其次你也可以选择语音风格，例如聊天、冷静、悲伤等等

部分的Voice甚至提供了角色扮演的设置！

顺便一提这里的Pitch是Polly所不支持的一个SSML Tag

总结

Polly最直接的是可以给你的网站增加朗读功能，进而可以满足无障碍设计。

1. POST，可以让我们的管理员传入原始链接，希望的短链以及标识管理员的身份
2. GET，最终用户访问对应的短链接时，会返回给它302并且在Location Header里面包含原始链接

接下来将以最简单的方式构建这个系统，第一个部分是DyanmoDB。
1. 我们需要创建DynamoDB的表，

如上图所示，我们用URL-Shortener作为表名，使用shortKey作为短链接的自定义部分，其余的保持默认。2. 我们需要创建对应的Role，Service选择API Gateway

3. 简单起见，创建好这个Role后，我们为它添加一个in-line的Policy，来指定具体的DyanmoDB

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:UpdateItem"
            ],
            "Resource": "arn:aws-cn:dynamodb:cn-northwest-1:2313xxxx5197:table/URL-Shortener"
        }
    ]
}

接下来我们创建API。
1. 打开API Gateway，我们创建一个REST API，如下图，我们不需要Sample API

2. 以 https://sample.com/shortKey 为例，GET请求应该落在根路径上，诚然我们也可以将POST放在根路径上，但是此处我们出于安全考虑，随机生成一个路径，并且日后也可以单独对这个路径进行进一步鉴权。

3. 接下来，我们在这个新创建的路径下，创建Method

集成的类型为AWS的服务，区域在宁夏，服务为DynamoDB，注意服务访问DynamoDB的方法为POST，实际的Action为UpdateItem，这里的Execution Role就是我们在IAM创建的最小权限的Role。
4. 创建后的页面如下

5. 我们点击Integration Request，在最下面的Mapping Templates里面新增

{  "TableName": "URL-Shortener",
  "ConditionExpression": "attribute_not_exists(shortKey)",
  "Key": {
    "shortKey": {
      "S": $input.json('$.shortKey')
    }
  },
  "ExpressionAttributeNames": {
    "#l": "originalURL",
    "#o": "owner"
  },
  "ExpressionAttributeValues": {
    ":l": {
      "S": $input.json('$.originalURL')
    },
    ":o": {
      "S":  $input.json('$.owner')
    }
  },
  "UpdateExpression": "SET #l = :l, #o = :o",
  "ReturnValues": "ALL_NEW"
}

attribute_not_exists用来判断当前shortKey是否已经使用，其他的部分则是将请求的JSON映射后存入。
6. 创建好Request后，我们点开Integration Response，也创建一个映射

#set($DDBResponse = $input.path('$'))
{
    "shortKey": "$DDBResponse.Attributes.shortKey.S",
    "originalURL": "$DDBResponse.Attributes.originalURL.S",
    "owner": "$DDBResponse.Attributes.owner.S"
}

这个映射就比较简单，直接将DynamoDB的返回给客户即可。
7. 我们可以点击TEST，构造一个BODY测试一下

{
  "originalURL": "https://jinshuju.net",
  "owner": "Sean",
  "shortKey": "jsj"
}

可以看到已经提交成功，此时我们也可以在DynamoDB里面确认一下。

接下来我们制作用户访问对应的shortKey跳转的过程。1. 我们要在根路径下创建资源，注意此时需要资源路径为{shortKey}

2. 在这个资源下创建Method，GET

注意API GW调DynamoDB时为POST
3. 修改Integration Request的Mapping为下图

即从Path里提取shortKey，传给DynamoDB

{
  "Key": {
    "shortKey": {
      "S": "$input.params().path.shortKey"
    }
  },
  "TableName": "URL-Shortener"
}

4. 我们需要先在Method Response中，删除200，因为这里我们要返回302，所以我们删除后添加302，同时要添加Location头

5. 我们回到Integration Response，删除原来的200对应的Response，重新添加302，并且添加Mapping Template

#set($DDBResponse = $input.path('$'))
#if ($DDBResponse.toString().contains("Item"))
#set($context.responseOverride.header.Location = $DDBResponse.Item.originalURL.S)
#end

6.我们测试一下

后续

1. 你可以添加自定义域名，以真正实现短链接服务
2. 你可以在API GW前增加WAF

https://aws.amazon.com/about-aws/whats-new/2022/06/amazon-virtual-private-cloud-vpc-customer-managed-prefix-lists-additional-regions/

我们往前看，这个功能最开始是2020年6月29日在Global可用^注1，在今年（2022年）2月，AWS又添加了由AWS管理的CloudFront Global前缀列表^注2，以方便用户使用。一直到2022年6月30日，两年后，亚马逊云科技中国区域终于可以使用这个功能啦！

前缀列表是一组相同用途/属性IP的集合，可以用于安全组或者路由表，方便我们重用IP集合，或者简化配置。这种集合可以是多个办公室的出口IP集合，多个数据中心的IP集合等等。

前缀列表一个区域资源，目前分为两种，一种是由AWS管理的前缀列表，这些列表通常包含

1. 该区域的S3的IP范围；

2. 该区域的DyanmoDB的IP范围；

3. CloudFront Global的IP范围。

需要注意的是，由于前缀列表的区域资源属性，虽然CloudFront Global的IP范围在任何区域的前置列表内容都一致，但是其ARN却是不同的，这就意味着你不能跨区域使用前缀列表（会提示你所引用的其他区域的前缀列表不存在）。

第二种前缀列表是由客户管理的前缀列表，也是下文将示例的部分。

我们打开控制台，切换到VPC，可以看到左侧已经出现Managed Perfix Lists，点击后如下图

可以看到目前已经存在我们在上文中提到的三个由AWS管理的前缀列表，也需要注意的是这些前缀列表是北京区域的通用资源，由AWS所有，任何亚马逊云科技中国区域的账户下均存在这三个前缀列表。

这时我们点击Create prefix list，如下图（图中IP为示例IP）

这里展示了创建一个前缀列表的几个关键要素：

1. 名称

2. 最大条目，尤其是这个参数需要注意，前缀列表并不能帮你绕过安全组的规则配额限制，默认情况下，安全组允许最大60条规则，虽然你在一条规则中引用了前缀列表，但是该规则的实际计数并不是1，而是引用的前缀列表中指定的最大条目（也并非是实际数量），例如由AWS管理的CloudFront Global前缀列表，目前由44条规则构成，但是其最大条目为55条，即一个默认配额的安全组引用了CloudFront Global的前缀列表，用于自定义规则的剩余配额就只有5条了；另一个例子是如果这里你填了1000，而你又没有通过工单的方式调整安全组规则配额，则任何安全组都不能引用该前缀列表；

3. 前缀列表条目，这里可以添加最多不超过最大条目约定数量的IP地址。

创建后的前缀列表如下图所示

值得注意的是，Resize prefix list可以允许我们在创建后调整前缀列表的最大条目，调整不是立即生效的，它会检查调整后的前缀列表被安全组引用后，是否会超出安全组的规则配额，如果超过了调整将不会被应用。

最后我们展示一下前缀列表如何使用。

当我们在创建安全组规则时，来源或者目的就可以直接使用前缀列表，如上图。这里值得说明的是前缀列表只能用于安全组和路由表，不能用于NACL。

总结

前缀列表给了我们一个很方便的方式来管理组织常用的IP，它可以简化配置，减少错误配置的发生。但是在使用时仍有以下几个部分需要注意：

1. 前缀列表只是方便我们管理IP的集合，并不能绕过配额限制，前缀列表的最大条目数量会直接对应到安全组的规则数量；

2. 前缀列表只能用于安全组和路由表，不能用于NACL；

3. 前缀列表是区域性资源，不能跨区域引用（无论对于客户管理还是AWS管理的都一样）关于这个也有一个博客提供了解决方案，参见注3；

4. 前缀列表可以共享，这部分可以参考文档。

亚马逊云科技中国区域的前缀列表，同时还要注意：

1. 中国区域的由亚马逊云科技管理的CloudFront前缀列表，其IP集合仍为CloudFront Global，并不包含一些由CloudFront China所使用的IP，我们不能用其来构成使用CloudFront China的系统的安全组；

2. 鉴于1的问题，我也制作了以下两个命令，可以帮助你生成

a. CloudFront China的前缀列表

https://gist.github.com/cnluzhang/eb660a428d16e799c59f0fc531ae874e

b. CloudFront China & Global的前缀列表（需要注意此列表已经超过60条，请先联系支持团队提升你的安全组规则配额）

https://gist.github.com/cnluzhang/6f02b0ea2b833551cd038cb1d1767e78

注1：https://aws.amazon.com/about-aws/whats-new/2020/06/amazon-virtual-private-cloud-customers-use-prefix-lists-simplify-configuration-security-groups-route-tables/

注2：https://aws.amazon.com/about-aws/whats-new/2022/02/amazon-cloudfront-managed-prefix-list/

注3：https://aws.amazon.com/blogs/networking-and-content-delivery/automated-vpc-prefix-list-population-for-cross-region-and-in-region-security-group-referencing/

全球各地的客户--从政府和高度管制的行业到小型企业和初创企业--都把他们最敏感的数据和应用程序交给亚马逊云科技（AWS）。在AWS，保护客户工作负载的安全和机密，同时帮助他们满足隐私和数据主权的要求，是我们最优先的任务。我们在安全技术方面的投资和严格的运营实践，甚至可以满足并超越我们最苛刻的客户在机密计算和数据隐私方面的标准。多年来，我们在专门的技术和系统方面进行了许多长期投资，以满足我们客户在安全和保密性方面不断提高的要求。

在过去的一年里，业界及我们的客户对机密计算这个短语的越来越感兴趣。我们注意到，这个短语适用于解决非常不同问题的各种技术，导致人们对它的实际含义感到困惑。本着代表客户进行创新的使命，我们想为您提供我们对机密计算的看法。

在AWS，我们将机密计算定义为使用专门的硬件和相关的固件来保护客户的代码和数据在处理过程中不受外界访问。机密计算在安全和隐私层面有两个不同的维度。最重要的维度--我们最常听到的客户的主要关切--是保护客户的代码和数据不受底层云基础设施运营商的影响。第二个维度是客户能够将自己的工作负载划分为信任度较高和信任度较低的组件，或者设计一个系统，允许不信任或不能完全信任对方的各方建立密切合作的系统，同时保持各方代码和数据的保密性。

在这篇文章中，我将阐述AWS Nitro系统如何在本质上满足第一个维度的要求，向使用基于Nitro的Amazon EC2实例的客户提供这些保护，而不要求客户方进行任何代码或工作负载的修改。我还将阐述AWS Nitro Enclaves如何为客户提供一种方法，以使用熟悉的工具集和编程模型来满足第二个层面的要求。在我们讨论细节之前，让我们先详细了解一下Nitro系统。

什么是Nitro系统？

Nitro系统是所有现代亚马逊EC2实例的底层平台，是我们代表客户进行发明和创新，为他们的应用程序提供额外的保密性和隐私的一个很好的例子。十年来，我们一直通过将越来越多的虚拟化功能转移到专用硬件和固件上，来在重塑EC2虚拟化堆栈，而Nitro系统就是这种持续不断创新的结果。Nitro系统由三个主要部分组成：Nitro卡、Nitro安全芯片和Nitro管理程序(Hypervisor)。Nitro卡是具有计算能力的专用硬件组件，可执行I/O功能，如用于Amazon VPC的Nitro卡、用于EBS的Nitro卡，以及用于EC2实例存储的Nitro卡。

Nitro卡--由我们的内部芯片开发子公司Annapurna实验室设计、制造和测试--使我们能够将关键的虚拟化功能从运行EC2实例的EC2服务器--底层主机基础设施上移开。我们在设计Nitro系统时，使用了Nitro安全芯片这一基于硬件的信任根，使我们能够对系统进行加密测量和验证。这提供了比传统硬件或虚拟化系统所能达到的更高的信任度。Nitro管理程序是一个轻量级的管理程序，可以管理内存和CPU分配，并提供了几乎与裸机无异的性能（我们最近在AWS Nitro系统的裸机性能中与我们的裸机实例进行了比较）。

从Nitro的角度看机密计算

Nitro系统提供的保护主要有三种类型。前两种保护是机密计算的关键维度的基础--客户从云运营商和云系统软件获得的保护，第三种保护加强了第二维度--将客户的工作负载划分为更可信和不太可信的部分。

1. 来自云运营商的保护。

在AWS，我们设计我们的系统以确保客户之间以及客户和AWS之间的工作负载保密性。我们设计的Nitro系统没有运营商访问。有了Nitro系统，任何系统或个人都不能登录EC2服务器（底层主机基础设施）、读取EC2实例的内存、或访问实例存储或加密EBS卷上存储的任何数据。如果任何AWS运营商，包括那些拥有最高权限的操作者，需要对EC2服务器进行维护工作，他们只能通过使用一套严格限制的经过认证、授权和审计的管理API来实现。这些API都不具备访问EC2服务器上客户数据的能力。由于这些技术限制是内置于Nitro系统本身的，任何AWS运营商都无法绕过这些控制和保护措施。为了在内存接口层面对物理攻击提供额外的深纵深防御，我们在很多EC2实例上提供内存加密。目前，所有基于Graviton2的实例（T4g、M6g、C6g、C6gn、R6g、X2g）和基于Intel的M6i实例都默认启用了内存加密，这些实例具有全内存加密（TME）。即将推出的基于AMD Milan处理器的EC2平台将具有安全内存加密（SME）。

2. 来自AWS系统软件的保护。

Nitro系统的独特设计利用低级别的、基于硬件的内存隔离来消除对客户内存的直接访问，同时消除在裸机实例中对管理程序的需求。

· 对于虚拟化的EC2实例（如图1所示），Nitro管理程序与底层硬件虚拟化系统协调，以创建相互隔离的虚拟机，并与管理程序本身隔离。网络、存储、GPU和加速器访问使用SR-IOV，这项技术允许实例使用管理程序安全创建的直通连接与硬件设备直接互动。其他EC2功能，如实例快照和休眠，都是由采用端到端内存加密的专用代理来推动的，AWS运营商无法访问。

· 对于裸机EC2实例（如图2所示），EC2服务器上没有管理程序，客户可以获得对所有底层的专用和独占访问。裸机实例是为那些希望访问物理资源的客户设计的，这些应用可以利用低级别的硬件功能--如性能计数器和英特尔® VT--这些功能在虚拟化环境中并不总是可用或完全支持，同时也适用于打算直接在硬件上运行的应用，或在仅在非虚拟化环境中才提供的许可和支持。裸机实例具有与虚拟化实例相同的存储、网络和其他EC2功能，因为Nitro系统使用专用硬件和特制的系统固件，以隔离和独立的方式实现了通常由虚拟化层提供的所有系统功能。我们使用相同的技术来创建亚马逊EC2 Mac实例。由于Nitro系统在独立的总线上运行，我们可以将Nitro卡直接连接到苹果的Mac mini硬件上，而不需要进行任何其他硬件修改。

3. 保护敏感的计算和数据元素不受客户自己的操作员和软件的影响。

Nitro Enclaves提供了机密计算的第二个维度。Nitro Enclaves是一个经过加固和高度隔离的计算环境，从客户的EC2实例启动，并连接到客户的EC2实例。默认情况下，任何用户（甚至是root或管理员用户）或运行在客户EC2实例上的软件都不能对enclave进行交互式访问。Nitro Enclaves具有加密证明功能，允许客户验证所有部署在其enclave上的软件已经过验证并未被篡改过。Nitro enclave与普通的基于Nitro的EC2实例一样，具有来自云运营商的相同保护水平，但增加了客户将自己的系统划分为具有不同信任水平组件的能力。Nitro enclave提供了一种保护客户代码和数据中特别敏感的元素的手段，不仅可以防止AWS运营商，还可以防止客户自己的维护员和其他软件。由于Nitro Enclaves的主要目标是保护客户自己的用户和EC2实例上的软件，Nitro enclave认为EC2实例位于其信任边界之外。因此，Nitro enclave不与客户实例共享内存或CPU核心。为了显著减少攻击面，Nitro enclave没有IP网络，也不提供持久性存储。我们将Nitro Enclaves设计成一个所有开发人员都可以高度使用的平台，不需要具备高级密码学知识或CPU微架构专业知识，因此开发人员可以快速、轻松地构建处理敏感数据的应用程序。同时，我们专注于创造一个熟悉的开发体验，以便开发者在Nitro enclave中运行的可信代码，就像在任何Linux环境中编写代码一样容易。

总结

总而言之，Nitro系统在虚拟化和隔离方面的独特方法，使我们的客户能够在任何时候都保证敏感数据处理与AWS运营商和软件的安全和隔离。它提供了内在的、默认的、对系统软件和云运营商的防护满足了机密计算最重要的维度，同时它也通过Nitro Enclaves来提供对客户软件和操作员的防护。

机密计算，即通过在可信执行环境中进行计算来保护使用中的数据。

为什么需要机密计算 (Confidential Computing)

1. 静态和传输中的数据受到加密的保护，针对这两种状态的攻击比较有限，近年来针对使用中数据的攻击收到关注；

2. 越来越多的数据转到了云端，网络和物理层面的防护能力被大大的削弱了，针对云的攻击更多在于Hypervisor虚拟机逃逸、Docker容器逃逸、固件BUG或者内部威胁（比如雇员），原先的防护手段在处理敏感数据时就不再够用了；

3. 对数据处理者（PIPL受托处理者）的监管要求也越来越严，虽然数据控制者（PIPL处理者）仍对数据泄露负最终责任，但是数据处理者也需要承担责任；

4. 随着边缘计算、IoT和移动设备的兴起，越来越多的数据需要在本就不安全的远程处理，而且往往监管又要求存储在这些设备上的个人数据应当收到保护，并且其共享和处理过程也应当可以被观察和符合监管的要求。

可信执行环境(Trusted Execution Environment)

在机密计算中，未经授权的实体包含父实例的其他应用程序、OS、Hypervisor或者管理员、服务提供商、基础设施所有者或者任何其他对硬件有物理访问权的人。

可信执行环境，是一种为数据完整性、数据保密性、代码完整性提供一定程度保证的环境。可信执行环境往往是安全且隔离的，可以防止应用程序和数据在使用过程中收到未经授权的访问或修改。

数据的完整性是指数据在处理时防止未经授权的实体处理数据，或者由TEE之外的任何实体处理；数据的保密性是指数据在TEE中处理时，未经授权的实体不能查看数据；而代码的完整性是指TEE中的代码不能被未经授权的实体替换或者修改。这三个属性叠加在一起，不仅保证了数据的保密完整，而且也保证了进行的计算是正确的计算，所以我们也信任计算的结果。

除了以上保证以外，TEE通常也提供代码的保密性、认证启动、可编程、可恢复性、证明（包含远程证明，即通过第三方验证确保预定的二进制文件被执行）。

TEE的分类和演进

狭义上来说，可信执行环境是硬件辅助隔离执行环境的一种，其信任根（Root of Trust）需要防篡改的硬件，这与机密计算联盟对TEE的要求一致，即将基于软件信任根的TEE排除在外，专注于基于硬件的机密计算环境的安全保证。

从实现上来看，TEE可以分为基于Process (Intel SGX)、基于Device (ARM TrustZone和RISC-V Keystone)和基于VM (AMD SEV / Intel TDX / ARM CCA / AWS Nitro Enclaves)。

Intel SGX始于2015年，然而由于其过度复杂的安全计算抽象（在用户态划出Enclave），导致了硬件（微代码实现）和软件的复杂度（例如借助Occlum等LibOS）和极高的性能开销。2002年就被提出的ARM TrustZone则一开始就提供了独立完整的物理机抽象，Apple Secure Enclave也继承了这个思路。

针对于SGX和物理机抽象的漏洞频频被发现和利用，自2016年AMD SEV开始，主流TEE都不约而同地走向了VM实现，这就包含了2019年AWS Nitro Enclaves，2020年AMD SEV-SNP / Intel TDX和2021年ARM CCA。

回到云上，Azure的Confidential VMs with Application Enclaves和阿里云的安全增强型实例，一开始都选择了SGX的实现，但是我们也看到最近Azure的confidential VM (preview)和GCP的Confidential VM (GA)已经选择了SEV-SNP方向。而在阿里云上，基于第三代神龙架构的阿里云虚拟化Enclave在架构上则更类似于AWS Nitro Enclaves，都有无持久化存储、无交互和外部网络，仅依靠与vsock等特点，也可以与阿里云的KMS服务结合进行远程证明。

我们会在下一篇文章中，详细阐述AWS Nitro Enclaves。

机密计算的使用场景

1. 凭据的存储和处理

2. 公有云 – 机密计算使得更多的工作负载（对安全和合规由强要求）迁移到云上成为可能

3. 多方计算

4. 区块链

5. 移动和个人计算设备 – TEE可以证明个人信息没有离开这些设备

6. 边缘和IoT

7. 支付处理方面已经非常普遍-  芯片智能卡、隔离的数字键盘