AWS 2022 re:Invent 观察 | 天下武功，唯快不破

引子

“天下武功，无坚不摧，唯快不破”，相信大家对星爷电影《功夫》中的这句话耳熟能详。实际上，“天下武功，唯快不破”最早出自古龙先生的著名武侠小说《小李飞刀》：“小李飞刀，例无虚发，只出一刀，无人能挡，只因天下武功无坚不摧，唯快不破。”

其意思是说，天下的众多武功里，只有“快”找不到克制它的方法。当武功的速度达到极致的时候，有时候不需要复杂招式，只是简单的一招就可以克敌。

2022年11月28日，一年一度的AWS re:Invent 2022 大会在美国内华达州拉斯维加斯拉开帷幕。据悉，本次大会吸引了约50000人现场参加，而线上参加的人数超过300000 人。这场为期五天的云计算盛会又给大家带来了很多新的惊喜。

在笔者看来，本次峰会有三大焦点主题，分别是 数据、性能和安全。AWS CEO Adam Selipsky的 Keynote 至少一半时间都在谈数据，包括数据的产生、数据的处理、数据的分析、数据的保护、数据的应用等。还有VP Swami Sivasubramanian的Keynote，几乎整个都在谈数据。而VP Peter DeSantis的Keynote则大部分时间在谈性能，包括更快的网络访问速度、更高的磁盘访问速度、更快的芯片运转速度、更快的函数启动速度等等。实际上纵观峰会，还有快速的产品发布速度、更快的数据流动速度、更快的创新速度等。

所有这些“快”，就像火箭高速发动机，将AWS推向了一个全新高度。如同“天下武功，唯快不破”中的“快”，“速度”也已成为AWS手中的一把最快的刀，披荆斩棘，势不可挡，奔向远方。下文，将选取本次峰会上众多发布之中笔者认为非常具有代表性的五个底层性能创新，来一一为您讲述AWS是如何将“快”做到极致的。

1. Lambda函数冷启动时间降低90%

2015年，AWS正式发布AWS Lambda，开创了无服务器计算时代。过去8年间，Lambda的功能一直在丰富和完善中。

Lambda具有独到的优势。在开发方面，它采用简单的编程模型，可方便地调用其它AWS服务；在运维方面，Lambda函数能快速响应不断变化的使用模式。因此，越来越多的用户喜欢它、使用它。在本次峰会上，AWS宣布，每个月有100万客户使用Lambda，每个月Lambda函数的调用量超过100亿次。

但是，过去，Lambda函数冷启动时间过长的问题一直在困扰着用户们。要理解这个问题的根因，需首先简单了解下其实现原理。

Lambda函数运行在微虚机（MicroVM）中。关于Firecracker，多年前笔者曾经写过一篇介绍性文章，容器在公有云上的落地姿势，您可以参考，请注意文中有些信息可能已经有些过时了。

AWS划分了一个池子，专门用于运行Lambda函数的微虚机。当用户部署函数时，函数代码要么被上传到S3中，要么将函数镜像上传到Amazon Elastic Container Registry（ECR）中。

当函数第一次被调用时，Lambda从S3或ECR中拉取代码，然后拉起一个Firecracker微虚机，并进行运行时和函数代码初始化。接着，代码被执行，并返回函数的输出。

接下来，Lambda 将使这个微虚机保持运行一段时间，因此后续请求都将由这个正在运行的容器来处理和执行。一段时间内没有函数调用的话，AWS将关闭此容器。当一个新事件出现时，Lambda 会启动一个新微虚机—这过程包括AWS为启动“微虚机”所做的一切，以及初始化你的代码。

这就是 AWS 启停其Lambda函数的基本方式。这种方法可提高AWS的基础设施的效率，大大降低客户的运行成本。

每个Lambda函数的生命周期包括三个过程：初始化（init）、调用（invoke）和关闭（shutdown）。所谓初始化过程，指的是第一次调用函数时所需要的执行和响应时间，包括下载代码、拉起微虚机、运行时初始化和函数初始化等环节所花的时间。后续调用过程则会比第一次初始化快得多，因为只包括函数执行环节。我们将函数的初始化过程称为“冷启动”。任何后续请求都将由正在运行的容器中已经包装好的函数处理，每次函数调用只需要一次所谓的“热启动”。

根据对生产Lambda工作负载的分析，冷启动通常发生在不到1%的调用中。冷启动的持续时间从不到100 毫秒到超过1秒不等。其中，Java语言编写的Lambda函数的冷启动时间最长，主要因为三个因素：一是JVM的启动时间，二是Java类的解压时间，三是Java类的初始化代码的执行时间。

Lambda函数冷启动时间过长会带来一系列问题，这也让Lambda函数启动性能优化成为近几年最热门的优化领域之一。特别是其最长的1秒时间，决定了Lambda函数可能很难用于对延时非常敏感的联机交易，这会大大压缩了Lambda的使用场景。为了克服这个问题，用户们甚至发明了非常规手段，比如每隔15分钟ping一次自己的函数，以确保它是活着的。

幸运的是，本次峰会上，AWS宣布了Lambda SnapStart新特性。为Java函数启用Lambda SnapStart，可以使其冷启动速度提高10倍。这是一次数量级级别的性能提升。

我们来看看该特性的实现原理。它利用了Firecracker的MicroVM Snapshot 功能。在函数冷启动或函数更新阶段或新版本创建时，函数会被启动运行并完成初始化，Lambda然后会为函数的内存和磁盘状态创建一个快照（Snapshot）并缓存下来。在冷启动过程中，通过恢复（Resume）快照，就可以让函数很快就绪。

只要快照存在，当函数被调用时，只需要恢复快照就可以了。而恢复快照比创建和初始化新的Lambda执行环境要快10倍，这就是为什么该特性虽小但效果这么明显的原因。

此优化使Lambda函数的调用时间更快且更可预测。实际上，该技术的背后还有三个创新点。一是采用一致性的快照技术，二是提升了快照处理的效率，三是预测性快照加载。这三大创新合并在一起，才带来数量级的性能提升。

本次峰会上，AWS推出了对使用 Amazon自己的JDK发行版Corretto (java11) 运行时的Lambda Java函数的支持，其他Java 框架的支持应该很快就会推出。

实际上，我们回头看的话，这功能实在太重要了，其实应该更早些推出才对，甚至在2014年宣布的时候就应该具备。

这个看起来小小的特性，也许能为Lambda巨大的改变，因为用户们太需要它了。他们在欢呼：“This is a great and long awaited change!”“Honestly, this is how Lambda should be, by default.”“其它Java版本、python和node.js什么时候开始支持呢？”

AWS的合作伙伴Micronaut迫不及待地使用“Hello World”Java程序做了对比测试。很显然，程序的启动速度得到了大幅提升。

在该功能所声称的性能提升得到充分的证实并在持续优化后，笔者甚至相信它将改变 Lambda 的扩展性在无服务器领域和整个行业中的认知，并将使得Lambda函数作为联机函数变成可能。甚至Serverless时代的真正到来会因此而大大加快！

2. 数据库TPS性能提升30%

现在AWS谈性能，已经无法不谈Nitro了。Peter DeSantis在其Keynote中一上来就说，自2014年以来推出的每一个的AWS EC2实例都在利用AWS Nitro这项技术，它对AWS产品和服务性能的提升居功至伟。

本次峰会上发布的最新版本 AWS Nitro v5，相比前一代v4，它具有两倍的计算能力、多出50%的内存带宽和两倍带宽的外围组件互连高速 (PCIe) 适配器，支持每秒60%的数据包 (PPS) 速率增加，数据包延迟减少30%，每瓦性能提高40%。

在2021年re:Invent峰会上，AWS发布了Nitro SSD。

这款AWS自研的SSD，具有更低延迟、更加可靠、数据自动加密等特点，它不仅帮助AWS实现了对SSD SLA的控制而且还大大降低了成本了。

Nitro SSD还有更多的价值。在2022年的re:Invent峰会上，AWS宣布基于Nitro SSD，AWS实现了TWP（Torn Write Prevention，撕裂写预防）功能，使得数据库的TPS性能提升了至少30%。

数据库是网站、APP等产品重要的底层核心支撑服务，其性能的重要性不言而喻。而TPS（Transactions per Second，每秒事务数）是数据库最核心的性能指标之一，TWP使得IO密集型的应用能从MySQL或MariaDB上获得更高的性能和更低的时延。

简单介绍下TWP产生的背景。通常数据库场景下，数据写入页大小（page size）是16KiB，而目前文件系统中常用的页大小都是4KiB。因此，数据库要将一个16KiB的数据写入磁盘，那在操作系统级别上需要写4个4KiB大小的数据块。在极端情况下（比如系统断电或操作系统宕机）可能无法保证这一操作的原子性，比如可能在写入4KiB 时发生了断电，此时只有一部分写是成功的，这样就产生了数据一致性问题。

为了解决这个问题，数据库实现上通常都会采用“双写缓冲区（Double Write Buffer，以下简称DWB）”的机制。如下图所示，当MySQL要写入16KiB数据的时候，数据首先被写入DWB缓冲区，然后分4次写入表空间。

显然，这种设计虽然保证了16KiB数据的写入可靠性和原子性，但是却带来了直接的性能损失和间接的成本增加。

得益于Nitro SSD对16KiB原子写的支持，TWP技术使得AWS数据库服务不再需要DWB缓存冲了，而只需要将文件系统的页大小直接修改为16KiB即可，数据库应用就可以原子性地一次性写入16KiB的数据。TWP可以确保数据库应用的16KiB数据在写入事务期间发生操作系统崩溃或断电时不会被撕毁。

使用TWP技术，在 EC2、EBS 和托管服务（如 Amazon RDS）上运行 MySQL 或 MariaDB 等关系数据库的客户可以关闭双写操作，从而在不影响工作负载弹性的情况下将数据库性能每秒事务数 (TPS) 加快多达 30%。

下图是在AWS r6i.16xlarge EC2实例上运行MySQL 8.0并使用简单OLTP负载的对比测试结果。在关闭DWB的情况下，其TPS在512个并发线程数时提升了2倍，而且随着线程数越多，提升效果越大。

数据库服务是云上最基础的服务之一。TWP这特性看起来也许不大起眼，但是却能带来如此高的性能提升，这让我们又一次见证了硬件创新的威力。

3. ENA网卡性能跃升5倍

在看具体内容之前，我们来看看过去16年中AWS EC2实例的网络带宽的提升曲线。这图非常直观、非常漂亮、非常震撼人心。re:Invent材料的视觉效果越来越好了。

AWS网络支持三种网卡，分别是ENI、ENA和EFA。

• ENI：Elastic Network Interface，弹性网络接口。ENI是一种逻辑网络设备，代表虚拟网卡，依赖Hypervisor通过网络虚拟化功能实现。

• ENA：Elastic Network Adaptor，弹性网络适配器，是一种通过SR-IOV（Single Root I/O Virtualizatio，单根I/O虚拟化）虚拟化技术实现的硬件网络设备。这是一种经过优化了的网络接口，能提供更高吞吐量和更好的每秒数据包 (PPS) 性能。

• EFA：Elastic Fabric Adapter，使用定制的操作系统旁路技术来增强实例间通信的性能。一开始EFA用在高性能计算场景中，使得客户能够在AWS上大规模运行需要高级别实例间通信的HPC应用程序，例如计算流体动力学、天气建模和油藏模拟。

三种网卡的特性对比：

需要注意的是，EFA因为采用了SRD协议，其最大单流带宽被提高到100Gbps。但EFA和ENA有些不一样，它没有采用标准TCP/IP协议栈，只能面向高性能计算场景。因此，很多用户早就在期盼着，若能将SRD用在ENA上，则能惠及更多用户的更多场景。

2022年的re:Invent峰会上，AWS 首次将SRD应用到ENA上，新推出了ENA Express。它具有三个特点：

• 简单：在网卡上通过简单配置或一次API调用来启用SRD即可；
• 透明：应用还是使用TCP/UDP协议，ENA Express自动检测通信双方EC2实例之间的兼容性，并在两通信实例均启用ENA Express 后建立SRD连接；
• 高效：能大幅提高EC2实例之间的单流带宽和降低网络流量尾部延迟。

SRD将使用ENA的EC2实例的最大单流带宽从5 Gbps增加到25 Gbps，足足提升了5倍。而且，它最多可将P99的延迟降低50%、将 P99.9 延迟降低85%。

那到底SRD有什么魔力能如此大幅提高网络传输性能呢？我们来看看SRD是什么、从何而来，又要到哪里去。

2020年，AWS发表了一篇论文《A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC》，对SRD进行了详细阐述（论文地址：https://assets.amazon.science/a6/34/41496f64421faafa1cbe301c007c/a-cloud-optimized-transport-protocol-for-elastic-and-scalable-hpc.pdf）

在论文摘要中作者写道：

“AWS重新审视了现有网络协议，以提供超级计算应用程序（supercomputing application）所需的持续低延迟，同时保持公共云的优势：可扩展性、按需获取弹性容量、性价比以及快速采用更新的CPU和GPU。

我们创造了一种新网络传输协议 - 可扩展的可靠数据报 (SRD)，旨在充分利用现代商业多租户数据中心网络的优势（具有大量网络路径），同时克服它们的局限性（负载不平衡和不相关流冲突时导致的延迟抖动）。

SRD不保留数据包顺序，而是通过尽可能多的网络路径发送数据包，同时避免过载路径。为了最大限度地减少抖动并确保对网络拥塞波动做出最快的响应，SRD在AWS定制的Nitro 网卡中实现。

SRD由EC2主机上的HPC/ML框架通过AWS弹性结构适配器（EFA）内核旁路接口（kernel-bypass interface）使用。”

关于SRD的详情，可阅读该论文，本文不再赘述。简单总结，SRD是一种基于以太网的传输协议，设计初衷是面向超算场景，要结合EFA才能使用。其主要特点包括：

• 乱序交付：SRD放宽了对按顺序传递数据包的要求，AWS在EFA用户空间软件堆栈中实现了数据包重排序处理引擎。
• 等价多路径路由（ECMP）:两个EFA实例之间可能有数百条路径，使用大型多路径网络的一致性流哈希的属性，以及SRD对网络状况的快速反应能力，找到消息的最有效路径。
• 快速的丢包响应：SRD对丢包的响应比任何高层级的协议都快得多。偶尔的数据包丢失是正常网络操作的一部分，这不是异常情况。

我们来通过TCP和SRD两种协议的对比来看看其优势。TCP的传统路由方式示意图：

丢包很大概率会引起TCP传输带宽的大幅下滑。

而SRD采用全路径传输方式：

这种情况下，丢包对带宽的影响非常小，除了短时间的小抖动，几乎没有影响。

“旧时王谢堂前燕，飞入寻常百姓家”。过去只能用于HPC集群中的SRD协议，如今应用到最为通用的ENA网卡中。就是它，让ENA网卡性能一下子跃升了5倍！

这种性能提升带来的好处是实实在在的。以AWS内存数据库服务Amazon ElastiCache为例，与普通ENA网络相比，ENA Express能够降低44%的尾部延迟，TCP最大单流带宽将增加4倍，从5Gbps增加到25Gbps。

4. EBS卷最大IOPS提升4倍

IOPS，每秒输入/输出操作（Input/Output Operations per Second）的缩写，是一个常用来表征存储设备性能的数字，数字越大表示存储的性能越好。

当AWS在2006年推出Amazon Elastic Compute Cloud (Amazon EC2) 时（Amazon EC2 Beta），m1.small 实例的本地磁盘存储容量只有微不足道的160 GiB。此存储与实例具有相同的生命周期，并且在实例崩溃或终止时消失。在EC2测试版和2008年推出Amazon EBS之间的两年时间里，这些早期卷能够提供平均约100 IOPS。

随着AWS的早期客户获得了EC2和EBS的使用经验，他们要求提供更高的I/O性能和灵活性。在2012 发布当时新的预配置 IOPS (PIOPS) 卷时，其IOPS达到了1000。多年来，随着客户群变得越来越多样化，AWS为EBS添加了新的功能和卷类型，同时也在提高性能、耐用性和可用性。

2014年，AWS推出Amazon Elastic Block Store通用型 (SSD) 卷类型，无论卷大小如何，它都能使每个卷的每秒 I/O 操作 (IOPS) 激增至3,000次。

2020年，AWS与SAP合作为SAP认证了Amazon EBS io2 卷。与Amazon EBS io1卷类型相比，io2卷的卷耐用性提高了100倍，IOPS与存储的比率提高了10倍。

下图是EBS家谱，从2008年的100 IOPS起点开始，到2012年单个PIOPS卷可以提供1000 IOPS，再到今天高端 io2 Block Express 卷可以提供高达 256,000 IOPS。

从曲线视角来看EBS I/O性能的持续14年的大幅提升历程：

从表的视角来仔细看：

在上面EBS卷家谱中，引起笔者最大兴趣的是2021年发布的Io2 Block Express类型，其最高IOPS和吞吐量比io2全都增加了3倍。这是一次多么大的性能跃升啊！

在2020年re:Invent峰会上，AWS宣布了io2 Block Express 提供预览版本，它被设计用于对IOPS和延迟有最高要求的最为关键的应用，比如Microsoft SQL Server, Oracle, SAP HANA等。

io2 Block Express 卷使用了多种Nitro系统组件，包括AWS Nitro SSD存储和用于EBS的Nitro卡。最大容量可达 64 TiB，并且提供高达 256,000 IOPS 和 99.999% 的耐用性和高达 4,000 MiB/s 的吞吐量。

2021年7月，io2 Block Express 卷正式发布。

2022年，AWS宣布将SRD应用于io2 EBS卷，这就是本章的主角io2 Block Express 卷。过去的一年中，AWS继续将SRD协议的覆盖面延伸到EBS上。甚至可以认为，io2 Block Express = io2 + SRD。

Io2 Block Express卷性能大幅提升，两种创新技术功不可没：一是在网络方面应用了可扩展可靠数据报 (SRD) 协议；二是在存储方面应用了AWS自研的Nitro SSD。因为这两种创新前文都提到过，这里就不再赘述了。

SRD协议有效改善了Amazon EBS块存储性能，减少90%的尾部延迟，并将吞吐量提升4倍。

Io2 Block Express卷使得客户们可以抛弃本地数据中心昂贵的SAN存储了。

AWS宣布从2023年初开始，所有新的Amazon EBS io2卷都将在SRD上运行。我们拭目以待！

5. Graviton全速冲刺云计算制高点

2022年re:Invent峰会上，AWS发布了Graviton3E芯片。

这是一款专用于高性能计算服务器的Graviton芯片，在HPC领域内常用的浮点计算和矢量计算上了针对性优化。与Graviton3相比，HPC性能提升了30%。

在笔者看来，AWS的Graviton芯片具有几个“快”特点。

一是发布速度快。2018年发布Graviton1，2019年发布Graviton2，2021年Graviton3。这速度刚刚的！

二是性能提升快。从服务器视角来看，基于Gravtion的服务器的架构有很多直接改进：每台服务器3颗Gravtion芯片，芯片密度虽然提升了50%，但服务器耗电量却和两路芯片服务器相当；而且全部芯片由Nitro统一管理，提升了安全性的同时，还节省了管理成本。

从芯片本身的性能来看，很难对三款芯片的性能直接进行对比。不妨换个视角，从采用了三种芯片的同样规格的EC2实例的性能和性价比上进行对比：

图上可以清楚地看出，每一代 Graviton的每单位容量成本的橙色条越来越短，而性能的黑色条越来越长。我们没有理由不相信这种趋势会在Graviton4上继续下去。

三是，AWS自己的服务向Graviton迁移的速度快。

除了计算、数据库、大数据分析服务外，AWS也把SageMaker服务也运行在Graviton上了。

四是用户的认可速度快。

Databricks CEO Ghodsi 提到：“越来越多的客户将Gravtion芯片带来的性价比提升视为免费的午餐。”

Gravtion实例在一些客户中变得如此受欢迎，以至于在某些地方，这种服务器有时候甚至会售罄。初创公司Honeycomb使用它从英特尔驱动的服务器切换到Graviton服务器所节省的资金来开发其它功能，而无需提高其价格。该公司的主要开发人员Liz Fong-Jones 说：“我们使用我们可以得到的所有Graviton 2和Graviton 3服务器，但在我们需要的一些可用性区域Graviton 3服务器却售罄了。”

五是用户向Graviton迁移的速度快。

这里举两个例子。

一个是Databricks，它的软件加快了开发机器学习模型的过程。其首席执行官Ali Ghodsi在最近的一次采访中表示：“自4月以来，当Databricks开始推广其在由第二代Graviton芯片提供支持的AWS云服务器上运行的软件时，其软件性能提高了20%，成本却降低了20%至40%。”

另一个是Snowflake。其产品高级副总裁Christian Kleinerman在一份电子邮件声明中表示，“与其他类型的服务器相比，在Graviton服务器上使用Snowflake的软件可以提高10%的速度。性能提升意味着Snowflake 客户不需要尽可能多地使用其软件，促使Snowflake在3月其收入将减少近1亿美元。同时该公司表示，随着客户利用较低的服务器成本并将更多数据放入Snowflake数据库，它希望弥补这一不足。”

Gravtion高速冲刺“抢占制高点”逻辑到底是什么呢？

从一代代产品发布，到一项项性能提升，到自身服务全面应用，到用户加速切换，Gravtion的一切动作都是那么快速。这背后，AWS的行为逻辑到底是什么呢？也许，Forrester Research高级云分析师Tracy Woo的一句话一语道破了天机：“Gravtion服务器芯片成为了AWS对抗追赶者的秘密武器，它是AWS要把他们和追赶者拉开差距而正在做的最重要的事情之一”。

数据分析初创公司Starburst Data的工程副总裁Ken Pickering表示，在Graviton服务器上运行的一个优势是，它们在并行化或同时处理多个不同的计算作业方面优于英特尔和AMD，这使得使用Graviton处理器的云服务器，耗电量更少、速度更快。

这种优势，也和很多客户反馈中得到了印证。 有客户通过租用Graviton服务器节省了10%到40%的计算成本。据一位直接了解相关数据的人士透露，Twitter、Snap、Adobe 和 SAP 都是Graviton服务器的客户，Graviton服务器在推出仅三年后就成为了一项收入达数十亿美元的业务。自从亚马逊在去年5月份推出更具成本效益的第三代Graviton芯片以来，竞争对手感受到了更大的追赶压力。

一方面，Graviton服务器的速度和效率为AWS客户节省了资金。另一方面，客户对此服务器的需求非常强大，亚马逊从中获得的收入也在飙升。据直接了解数据的人士表示，截至2021年秋，每年Graviton服务器收入有望超过50亿美元。这意味着继续高速增长的话，到2022年可能占AWS弹性计算云收入的10%以上。这位人士表示，EC2 收入约占 AWS 去年 620 亿美元收入的一半。（备注：AWS尚未披露 EC2 或 Graviton 的收入。）

写在最后

前文介绍的这些性能提升和优化，包括Lambda函数、ENA、EBS、TWP和Graviton，都发生在AWS云基础设施的最底层。它们也许不像全新发布的那些服务那么耀眼，但是，它们带来的效果却是最直接的、最实在的、最惠及大众的、最能帮客户省钱的。因为这些服务，是AWS数百万计的用户们最常使用的。

AWS的创新注重因地制宜。比如在SRD创新上，传统数据中心通常采用Spine-leaf网络架构，如下图所示。

而AWS数据中心网络采用改良版本的CLOS网络架构。

可以说，SRD是最适合AWS网络架构的网络协议。在这种网络拓扑之中，SRD软件在网络端点间提供多路径，减少拥塞并允许网络在硬件故障时自动修复，从而提高其网络的有效吞吐量，同时减少网络延迟。

AWS采用立体式全栈创新，系统地提升工程性能。基于各种黑科技，采用以芯片为代表的硬件、以Nitro为代表的网络、以SRD为代表的协议，为性能带来了成倍乃至数量级上的提升。

AWS注重一种协议、全面采用。SRD在全面支持ENA和EFA的基础上，增加了对EBS的覆盖支持，真正实现了“一种协议，全面采用”，最大化地发挥出价值。笔者预测，SRD必将成为AWS数据中心内主要的基础网络协议。

AWS自研芯片之战，已赢得累累战果。自研芯片为AWS带来了全面的专业性、高性能、创新速度和安全性。以创新速度提升为例，数据显示，自从Nitro在2017年发布以来，EC2实例类型从几十种一下子增长到五百多种。

AWS在底层创新的同时，还注重尽量不给用户带来额外改动成本。过去，SRD一直专注在HPC领域中，对TCP/IP的支持一直存疑。这一次非常关键的是，使用了SRD的ENA Express直接支持了TCP/IP和UDP，因此客户不需要修改任何的代码，就能直接利用SRD所带来的种种能力提升。

“快”是AWS身上一道最亮眼的标签，让AWS在短短十几年时间内就成为全球公共云霸主。AWS越来越像一位大侠，在内力越发深厚的同时，出招还更快、更准。“快”的背后，是AWS长远的眼光、准确的决策和坚决的执行力。

让这种底层创新和核心性能提升来得更多更猛烈一些吧！！

--- THE END 全文完 ---