EC2 Nitro 网络架构深入解析

EC2 Nitro 网络架构深入解析

关键字: [Amazon Web Services re:Invent 2024， 亚马逊云科技， Nitro， Network Packet Processing， Flow State Management， Queue Depth Configuration， Traffic Profile Analysis， Instance Performance Tuning]

导读

深入了解EC2实例上数据包的生命周期，并学习优化实例网络性能的关键策略，以满足您的工作负载需求。在本次讨论中，探索正在塑造EC2实例网络体验的前沿技术，并解锁全新的性能水平。了解亚马逊云科技如何将单个VPC扩展到前所未有的规模，并探索Nitro系统的创新，以实现不同类型应用的最佳性能。

演讲精华

以下是小编为您整理的本次演讲的精华。

视频以John Pangle和Scott Wayner欢迎与会者参加亚马逊云科技 re:Invent 2024大会的NET402会议而开始。他们对在活动首日就有如此多雄心勃勃的观众参加这个高级讲座表示热情洋溢。John介绍了自己，解释他的工作重点是实例网络，而Scott则与客户密切合作，以加速并实现Nitro的高性能吞吐量。

Scott通过提出一些贴近生活的场景，如汽车引擎警示灯亮起或某场地的队伍似乎停滞不前，来吸引观众的好奇心，探讨潜在的原因。他向观众保证，本次会议旨在提供对这些过程的洞见，使他们能够优化工作负载并充分利用Nitro的潜力。

为了了解观众的背景，Scott进行了一次举手投票，结果显示大部分与会者来自工程和规划岗位，少数来自运营部门，还有一些应用程序开发人员。他表示相信，本次会议将为所有与会者带来宝贵的收获，因为他们将深入探讨整个Nitro服务序列。

John接着解释，虽然Scott的工作重点是优化客户工作负载性能，但他的职责是在网络领域构建和交付新产品和创新，尤其是在数据平面方面，以不断提高网络性能和连接性。

John强调了EC2数据平面的重要性，它为数百万台服务器提供动力，每秒处理数百亿个数据包，运行着与会者所熟知和喜爱的应用程序，从亚马逊商店到Netflix等。然而，他承认对于某些客户来说，EC2数据平面可能是一个黑盒子。本次会议旨在提供技巧和窍门，帮助理解数据平面的工作原理，从而更好地优化工作负载。

John概述了会议议程，首先是数据包分析，以理解单个数据包如何流经EC2实例。虽然网络每秒支持数十亿个数据包，但他强调了理解单个数据包流的重要性。接下来，他们将进行单个流分析，以了解一旦建立连接后如何优化流。随后，他们将深入探讨多流分析，讨论实例如何处理多个流。最后，他们将提供额外的工具和技巧，帮助与会者了解如何优化延迟和CPU使用率，并总结出一个行动计划。

在深入技术细节之前，John介绍了Nitro的概念，这是一个涵盖网络、存储、块存储、本地存储、安全性和众多其他功能的芯片系统，为与会者所熟知和喜爱的功能提供支持。

John回顾了Nitro理念的起源，可追溯到2010年代初，当时亚马逊观察到一种新兴趋势:随着每一代服务器密度不断提高，可以在主机CPU上安装更多实例。然而，网络I/O、存储I/O和安全功能所占的比例也越来越大，因为客户对EC2实例的功能要求不断增加。这使得规划和预配置应用程序如何与网络和存储协作变得具有挑战性。

为此，亚马逊在2013年做出了一个大胆的决定，开始将其功能与增强型网络分离，从C3实例开始。这涉及将进程从服务器移出，转移到Nitro芯片上，将网络、存储和安全功能分离出来，只在主机上留下一个轻量级的虚拟机管理程序。

亚马逊并没有就此止步。在与C3迈出第一步后，他们与Annapurna合作，推出了多代Nitro。到目前为止，他们已经推出了五代Nitro，从C4开始，一直到Nitro V5、C7、G’n，以及更多即将推出的产品。在每一代中，亚马逊都在不断提高带宽、数据包速率和安全性能，自Nitro V3起，所有Nitro功能都添加了传输中加密。

John简要概述了本次会议将涵盖的内容，确保与会者了解会议的预期。首先，他们将讨论数据包分析，以了解单个数据包如何流经EC2。然后，他们将转向流分析，接着是多流分析。最后，他们将提供额外的工具和技巧，帮助与会者优化延迟和CPU使用率，并总结出一个行动计划。John将话筒交给Scott，开始数据包分析。

Scott解释，在这一部分，他们将关注单个数据包在应用程序、内核、驱动程序、Nitro和主机之间的流动过程。他介绍了一个处理堆栈的表示，该表示将贯穿整个演示，描绘了应用程序、内核、驱动程序、Nitro和Ethernet层，后者用于在计算主机之间移动数据包。Scott阐明，在堆栈表示中，分界线以上的所有内容都是实例，包括亚马逊不会触及的CPU，而Nitro是一张位于主机下方的卡，与作为Nitro一部分提供的驱动程序有明确的界限。

为了为讨论提供参考框架，Scott展示了VPC构造，其中一个客户端通过互联网网关进入VPC。他描绘了一个典型的VPC交互，其中有一个网关带有两个接口，可能是防火墙、路由器或代理类型的实例，代表外部子网。从那里，通信流向一个Web服务器，它是三层架构的前端。然后，Web服务器通过弹性网络接口与后面的应用服务器通信，可能代表使用弹性网络接口的业务逻辑层，最后到达数据库系统。

Scott承认有许多不同的方法来处理这个问题，但他使用这个作为参考点，为他们将要讨论的Nitro处理的特定元素提供上下文，重点关注从Web服务器发出并到达应用服务器的数据包，以及返回的数据包。

转向数据包处理，Scott介绍了一个参考数据包，由IP目标地址、IP源地址、协议、目标端口和源端口组成。他强调了解Nitro如何与亚马逊系统协作的重要性。

Scott逐步解释了这个过程，从应用程序创建一个数据包开始，比如向应用服务器发出curl命令。DNS解析提供目标IP地址，应用程序指定端口，如端口80或443。这在内核操作层和设备驱动程序中打开了一个TCP套接字，产生了一个5元组:源IP、目标IP、协议、源端口和目标端口。Scott强调记住5元组的重要性，因为它将在Nitro中处理数据包时发挥关键作用。

一旦数据包形成，操作系统就会做出路由决策，将其发送到特定设备，该设备在Nitro中映射到一个弹性网络接口(ENI)，这是弹性网络适配器的一部分。Nitro卡有ENI的表示，与内核操作系统中的设备相关联。

从那里，目标数据包将被处理，以确定将其放入哪个队列。Scott解释，ENI的发送和接收操作都有一组队列，有一个发送环和接收环，数据包被放置在其中并交给操作系统。在下面是网络接口，数据包将从那里发送到另一个计算实例。

重要的是，5元组哈希决定了队列分配和Nitro中相关联的处理器，这突出了5元组在理解数据包如何进入队列时的重要性。

一旦数据包进入Nitro，VPC就在Nitro卡中表示出来，包括子网和其他配置。对于首次看到的数据包，将采取几个步骤。首先，查阅与子网相关联的路由表，这是Nitro中配置的状态。在这种情况下，可能是一个本地路由，因为数据包只是发送到相邻的应用服务器。

其次，考虑与子网相关联的网络访问控制列表(ACL)，也在Nitro中配置。最后，评估定义数据包是否允许进出的安全组。

由于这是首次看到该数据包，因此需要在Nitro中构建状态。为了确定在VPC构造中将数据包发送到何处，即另一张Nitro卡在网络中的位置，将使用映射服务对IP地址执行查找。这将提供目标Nitro卡的位置，从而允许Nitro构建邻接关系并记住该状态，这对于后面的多流讨论将很重要。

此外，还采用了一种连接跟踪机制，称为合同，用于跟踪Web服务器和应用服务器之间的关系，在这一阶段，只看到了单向数据包。

最后，构建了一个流缓存，这是一种加速数据包通过Nitro的机制。目标是为首个发起的数据包构建这个Nitro状态。

对于第一个数据包，将采用处理路径，因为它以前从未被看到过，这导致最初的数据包每秒速率较低，因为需要进行状态设置处理。

数据包离开Web服务器并发送到应用服务器，应用服务器处理请求并发送回响应。当互反数据包进入Nitro卡时，连接跟踪已经建立，流缓存也已完成，从而允许加速此事务剩余数据包的处理，这被称为加速流。

数据包通过Nitro返回，与接收队列中的一个对齐并放置在接收环上，然后通过弹性网络接口交给操作系统的驱动程序。接收端的5元组哈希将数据包分配给接收队列，Scott指出John稍后将提供更多关于如何在队列上接收这些数据包的细节。

在此之后，Scott将交给John来讨论流量分析，因为他们现在已经完成了一次事务并进入了加速路径，这是理解系统性能的关键能力。

John解释说，一旦进入加速路径，Nitro所需的工作就会减少，从而提高了系统性能和能力。然而，了解单个流规范或实例在单个流中的能力是非常重要的。

从那里，John将涉及客户面临的常见挑战，如微突发，并提供管理它的技巧和工具。他还将讨论可能会中断连接或影响性能的流状态异常，以及鲸鱼流，这在TCP或UDP中很常见，但在其他边缘情况下也可能出现，需要更详细的考虑。

John首先讨论单个流规范。默认情况下，绝大多数流经EC2实例的流量都能够实现高达5Gbps的速度。这适用于从外部互联网进入EC2实例和反向的流量，以及任意两个可用区或区域之间的流量。此外，在单个可用区内也适用5Gbps的能力。亚马逊将此限制设置为5Gbps，以提供一致的体验，避免网络拥塞和热点，确保一致且高性能的体验。

除了默认的外部流之外，还有集群放置组流，它允许TCP达到10Gbps，UDP达到8Gbps。集群放置组是EC2实例的一种启动机制，将两个实例物理上紧密放置在一起，从而实现高达10Gbps的吞吐量。

此外，亚马逊最近推出了一种名为ENA Express的功能，它是对ENA(弹性网络适配器)的增强，使用SRD(高级拥塞控制算法)允许单个流达到25Gbps。与基于启动配置工作的外部流或集群放置组不同，ENA Express是一种实例级功能，需要在启动或修改EC2实例时进行配置。

为了理论上说明这一点，John展示了一个图表，其中x轴表示数据包大小，y轴表示实际带宽。绿线代表集群放置组流，黄线代表外部流或5Gbps流。如图所示，对于64、128字节范围内的较小数据包大小，流量会受到数据包/秒的限制。最终，随着数据包大小的增加，它们会受到比特/秒的限制，这取决于Nitro的能力、Nitro处理器代数和EC2实例规格。两种流类型都遵循类似的趋势线，最初受到数据包/秒的限制，直到受到比特/秒的限制。

为了在实践中演示这一点，John分享了在c5 large(Nitro v3)和c7i large(Nitro v4)上运行测试的结果，代表了多代改进。图表中的粉红色和红色线显示，采用较新Nitro代数的c7i能够比c5 large更早实现数据包/秒的能力。然而，两者都遵循了理论趋势线，最初受到数据包/秒的限制，随着数据包大小的增加而受到比特/秒的限制。

转而讨论微突发，John承认这可能是一个难以诊断的问题，特别是在EC2实例上，如果不了解它何时以及如何发生的话。他解释说，微突发是由于数据包到达的速度快于Nitro能够处理的速度而导致的，从而导致队列备份、延迟，最终导致数据包丢失，这将反映在指标中。

为了防止和管理微突发，John建议使用队列和内核中的拥塞控制，例如增加rxq深度以提供更大的缓冲区来在内存中保存更多数据包，尽管这可能会增加延迟。在发送端，Linux内核的流量控制功能，包括qdisc和公平队列，可用于限制整个系统吞吐量以及单个流或队列吞吐量。此外，在Nitro v4中，ENA Express功能通过拥塞控制算法有效地管理入站微突发。

John以c6i实例(16个CPU)为例，默认情况下支持与CPU数量相同的队列数，在某些加速实例上，默认支持高达32个队列。使用最新代数的Nitro驱动程序，txring深度支持512(带宽loq功能)，在rx端，默认值为1024。在任一情况下，队列深度和环深度都可以增加以容纳更多数据包，但在tx端，必须禁用宽loq功能，这是一种允许在报头中使用更多描述符或选项的功能。

发送端的流量控制功能允许限制从内核推送到网络堆栈的数据包数量。John分享了一个示例，其中在c7i large实例上运行了10秒的iperf测试，尝试使用10个流推送总计93Gbps的流量(每个流10Gbps)，但该实例无法处理这种吞吐量。通过启用流量控制、设置流量类别并启用公平队列，可以使用令牌桶对整个系统进行速率限制，并设置10个流量类别。可以将最大吞吐量设置为约10Gbps，将单个实例或流限制设置为1Gbps，从而有效地对整个系统进行速率限制，同时防止任何单个流超过1Gbps。

John还强调了2022年推出的ENA Express，它支持25Gbps的流吞吐量，并基于SRD(用于机器学习和HPC应用程序的弹性网络适配器中使用的协议)内置了拥塞控制功能。该拥塞控制功能已移植到基于TCP和UDP的应用程序中，允许更好地应对入站微突发，并通过直接在Nitro内的较低层执行拥塞控制来改善p99和尾部延迟。ENA Express支持Nitro v4及更高版本，是一种客户可选功能，并在本地区域内可用。

转而讨论流状态异常，John讨论了VPC突变，其中单个连接是基于Nitro状态建立的。如果ACL(访问控制列表)从更严格的状态更新为不太严格的状态，则可能会中断连接，因为ACL是无状态的，只允许单向流量。但是，如果ACL更改从不太严格变为更严格，然后再次变为不太严格，则数据包需要在处理路径中重新评估，但连接不会中断。

另一方面，安全组是有状态的，这意味着进入的数据包被允许出站，反之亦然，这取决于收到的第一个数据包。John举了一个例子，安全组允许任何源IP地址通过TCP协议访问特定的443端口范围。如果安全组从开放或未跟踪状态更改为跟踪状态，则新的安全组将被强制执行，并且数据包将被重新处理。但是，如果更改是从未跟踪的安全组变为更开放的状态，则现有连接状态将被维护。

John接着讨论了未跟踪连接，这是一个需要理解的重要概念。他举了一个安全组配置的例子，其中包括入站和出站规则，允许所有IP地址访问端口80(HTTP)，但只允许特定源IP地址访问端口22(SSH)。在这种情况下，端口80是未跟踪连接，而端口22是跟踪连接。ICMP始终是跟踪的。

未跟踪连接非常重要，因为它们允许应用程序更好地执行，而无需评估安全组。但是，这也存在权衡，因为安全组在其应用中非常重要和关键。在某些情况下，例如运行Scott在三层架构前端所描述的网络设备时，开放或未跟踪的连接允许Nitro尽可能多地工作，将处理推送到主机CPU和业务逻辑中，就像打开水坝的闸门一样。

最后，John谈到了驱动程序的最低要求。从Nitro v3过渡到Nitro v4时，需要满足ENA驱动程序的最低版本(2.2.2.9及更高版本)，才能利用加速路径。在Nitro v5上，这是必需的，而在Nitro

以下是详细叙述摘要的续篇:

John接着讨论了鲸鱼流，它涉及隧道协议，如GRE、IPsec或VXLAN。他举了一个例子，其中有源IP、目标IP、隧道和内部IP数据包及有效负载。尽管存在两个唯一的IP有效负载，但它们共享相同的3元组(协议、源端口、目标端口)。正如Scott之前强调的那样，流是基于5元组进行评估的，但在这种情况下，对于通用IP数据包，Nitro基于3元组流进行评估。尽管数据包具有唯一的IP有效负载，但外部IP隧道协议导致Nitro和ENA队列将它们视为单个流。

为了摆脱这种情况并单独处理流量，John建议使用基于UDP的封装协议，如VXLAN、GENEVE、GTP(在电信领域使用)或UDP上的MPLS。通过使用具有唯一隧道的UDP头，每个流被视为唯一的5元组，在Nitro上进行不同的哈希处理并进入不同的队列，从而实现更好的负载分布和提高性能。

Scott接着讨论了多流分析，强调了解当使用隧道机制时会发生什么的重要性，因为GRE、IPsec或隧道数据包将被视为单个流量，并在Nitro的特定队列中进行处理。

Scott引入了流熵的概念，指的是流量的多样性。他建议与会者了解自己的流量类型，确定流量是否具有足够的熵(是否存在单一热点流量或多个流量)，并为每种流量类型构建流量配置文件，包括每秒数据包数、每秒比特数和每秒连接数。有了这个流量配置文件，与会者就可以了解他们的流量在跨越Nitro时是否会遇到约束。

有了流量配置文件类型，与会者就可以选择合适的实例类型，考虑基线和突发规格、所需的Nitro性能以及所需的接口数量，因为安全组可以与这些接口相关联。

最后，Scott强调了调优和监控实例的重要性，包括驱动程序调优、使用eth工具指标，以及利用Cloud Watch代理获取更详细的指标，以及来自Cloud Watch的VPC指标。

John接着讨论了延迟优化和CPU管理。他承认虽然无法克服物理定律和光速的限制，但使用集群放置组(CPG)可以将实例尽可能靠近放置，减少实例之间的距离，从而实现最低可能的延迟。

应用程序堆栈中的其他功能包括DPDK(数据平面开发工具包)等驱动程序功能，它绕过主机内核，允许在用户空间进行数据包处理，从而减少开销并提高延迟。此外，使用UDP等协议而不是TCP可以减少TCP堆栈的开销。

在内核方面，John讨论了拉模式操作，其中主机CPU在一个紧密循环中不断从队列中拉取数据包，确保在接收数据包时立即将其拉取并处理到主机CPU中。他还提到了更高的C状态，其中像C6(较低功耗)这样的更深C状态需要额外的时间和延迟才能上升到C0(最低延迟)，这代表了功耗和主机CPU利用率之间的权衡。

如果不需要拉模式操作，可以使用中断。默认情况下，当数据包到达环并进入队列时，队列将调用网络API通知主机CPU有工作要做，并处理该数据包。中断会实时发生，因为数据包是在接收时发生的。

为了管理中断，John建议使用中断调制，将默认的20微秒减少到64微秒，用于TX与RX。虽然这可以减少延迟，但如果不断接收数据包，可能会减慢处理速度。为了达到平衡，亚马逊支持动态中断调制，旨在在接收大量数据包时增加中断，在数据包接收较少时减少中断，从而优化CPU利用率。

John接着讨论了队列管理，首先是接收端缩放(RSS)，它在所有实例上默认启用。但是，在某些情况下，使用单个队列和单个主机CPU进行网络I/O操作可能是所需要的。在这种情况下，所有数据包将在单个队列上接收，并在单个主机CPU上处理。

启用RSS后，数据包将使用哈希(如CRC32或Toeplitz哈希)跨可用队列分布，最多分布到主机CPU的数量。从Nitro v3开始，客户可以评估和操纵此哈希，以定义和分布数据包将落在何处，从而允许为特定工作负载应用程序使用特定队列。

除了RSS之外，亚马逊还提供了接收数据包转发(RPS)，这是一种内核操作，允许进一步将数据包分布到主机CPU上。在给出的示例中，RSS用于将数据包分布到8个队列和8个主机CPU，而RPS则允许将这些数据包进一步分布到剩余的8个CPU，从而实现更有效的负载分布。

John还介绍了ENA流量引导或5元组过滤，这是一项最近推出的只在Nitro v5上可用的功能。使用带有RPS和流量引导的C8g8x大型实例，他演示了如何将特定流量类型(如SSH流量到端口22、通用TCP流量和通用UDP流量)分配到特定队列，基于5元组。这允许基于5元组的角度分布负载，并且可以使用任意数量的过滤器，从单个5元组到5元组，提供了对流量流向哪个CPU和队列的精细控制。

规则的数量受主机实例上CPU的数量限制，因此在16个CPU的情况下，最多可以配置16个单独的规则来分发流量。

John接着讨论了监控，重点介绍了带宽入出超出允许的指标，以及合同允许超出和合同允许可用的指标，这些指标跟踪了各种流量击中EC2实例的状态。

在Nitro固件中，会计算并索引每个EC2实例的连接数，ENA驱动程序会跟踪并将其导出为指标。合同允许可用指标表示剩余的可用连接数，而合同允许超出指标则在可用连接用尽时开始索引上升的连接丢失情况。

为了解决连接耗尽问题，亚马逊在大约一年半前推出了可配置的空闲超时，允许将TCP可配置空闲超时从默认的5天减少到60秒。如果连接超时且在60秒内没有看到其他数据包，则该连接将过期，从而释放资源以建立新连接。此功能对于单流和双向UDP也受支持，超时可调整为180秒到60秒。

另一个与内存相关的方面是Scott之前提到的网络地址单元。在建立连接时，Nitro会调用映射服务来查找远程接口的位置。在VPC内部，Nitro会查找正在通信的实例的位置，但不会加载未通信实例的位置，从而优化内存使用，并允许VPC扩展到前所未有的规模。

默认情况下，亚马逊在VPC内支持128个网络地址单元，在私有VPC中可以增加到256个。此外，默认支持256，000个网络地址单元，可扩展至512，000个。

Scott接手提供了优化Nitro的行动计划。他强调了解流量类型、识别鲸鱼流量(IP、GRE或其他隧道)以及确定是否存在足够的流量熵(是否存在单一热点流量或多个流量)的重要性。

确定了流量类型后，与会者可以为每种类型构建流量配置文件，包括每秒数据包数、每秒比特数和每秒连接数。这个流量配置文件将有助于了解流量在跨越Nitro时是否会遇到任何约束。

有了流量配置文件，与会者就可以选择合适的实例类型，考虑基线和突发规格、所需的Nitro性能以及所需的接口数量。

最后，Scott强调了调优和监控实例的重要性，包括驱动程序调优、使用eth工具指标，以及利用Cloud Watch代理获取更详细的指标，以及来自Cloud Watch的VPC指标。

John总结时分享了各种资源，包括Nitro调优指南、ENA最佳实践、连接跟踪指南、网络地址单元信息、Cloud Watch功能、ENA Express详细信息、微突发故障排除和管理以及突发和基线带宽的网络规格。

他还强调了re:Invent 2024年与计算和网络相关的其他会议，届时杰出工程师和副总裁将讨论这些领域的最新创新和进展。

John感谢观众的时间，并要求他们填写调查问卷。

总之，这个视频深入探讨了Nitro网络架构，涵盖了数据包流、流量优化、多流处理、延迟和CPU优化、队列管理、监控以及有效利用Nitro的行动计划。演讲者分享了详细的技术见解、实际案例和最佳实践，为与会者提供了优化工作负载并最大限度提高EC2实例性能的知识和工具。

下面是一些演讲现场的精彩瞬间：

John Pangle，EC2的高级产品经理，在reInvent2024活动上介绍了自己和同事Scott Wayner。

亚马逊云科技推出了ENA Express，为基于Nitro的实例提供25千兆比特每秒的吞吐量和内置拥塞控制，从而提高应用程序性能并减少尾部延迟。

亚马逊云科技 re:Invent 2024演讲强调了理解VPC流量状态异常的重要性，例如VPC突变以及安全组和ACL的有状态/无状态行为，以确保网络连接不间断。

Nitro智能地处理带有隧道IP数据包的大流量，将它们视为单个3元组流量进行高效处理。

演讲者解释了实例聚合流量限制以及它如何影响网络性能，并提供了优化网络流量和监控指标的见解。

亚马逊云科技解释了动态中断调制的目的是在处理网络数据包时平衡延迟和CPU利用率，在流量较低时减少中断，但在流量较高时增加中断。

亚马逊云科技高管在re:Invent 2024上分享了计算和网络领域的最新进展。

总结

这场演讲深入探讨了亚马逊云科技 EC2 Nitro的复杂性，Nitro是一个涵盖了为EC2实例提供网络、存储、安全和其他功能的芯片系统的总称。它全面演示了单个数据包如何在EC2实例中流动，从应用层一直到Nitro卡，强调了各个阶段和相关的优化措施。

演讲者强调了解流量特征的重要性，包括数据包大小、流类型(TCP/UDP)和连接率，以选择合适的实例类型并相应地调整性能。他们讨论了管理微突发、流状态异常和鲸鱼流(隧道流量被视为单一流量)的技术，以优化吞吐量和延迟。

关键要点包括利用集群放置组、ENA Express、可配置的空闲超时和诸如RSS、RPS和ENA流导向等调优选项，有效地在队列和CPU之间分配负载。演讲者还强调了带宽允许和合同允许等监控工具，以获得性能瓶颈的可见性。

最终，这场演讲旨在为与会者提供一个行动计划，用于分析他们的工作负载、选择合适的实例，并微调配置，以充分发挥Nitro加速数据平面和优化网络性能的潜力。

亚马逊云科技（Amazon Web Services）是全球云计算的开创者和引领者。提供200多类广泛而深入的云服务，服务全球245个国家和地区的数百万客户。做为全球生成式AI前行者，亚马逊云科技正在携手广泛的客户和合作伙伴，缔造可见的商业价值 – 汇集全球40余款大模型，亚马逊云科技为10万家全球企业提供AI及机器学习服务，守护3/4中国企业出海。