导读

在本次会话中，探索Amazon Aurora和Amazon RDS的成本组成，并学习重要的最佳实践，这些实践可以帮助您提高关系型数据库工作负载的性能，同时降低各种成本组成部分的支出，如计算、存储、备份和I/O等。

演讲精华

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

在亚马逊云科技 re:Invent 2024活动上，亚马逊云科技高级数据库解决方案架构师Penn DeBusk和亚马逊云科技高级首席技术专家Tim进行了一场引人入胜的演讲，探讨如何提高Amazon Aurora和Amazon RDS的性能并降低成本。演讲者们承认与会者普遍面临着在Amazon RDS中优化性能和成本的挑战，为深入探讨量身定制的技巧和最佳实践奠定了基础。

Penn首先介绍了亚马逊云科技的全托管关系型数据库服务Amazon RDS，它支持Oracle、SQL Server和DB2等商业引擎，以及MySQL、PostgreSQL、MariaDB和独特的Amazon Aurora等开源引擎。他强调，Amazon Aurora是一种云原生数据库引擎，经过精心设计，能够提供与商业级企业数据库相媲美的企业级安全性、可用性和可靠性，同时具备开源数据库的简单性和经济性。这一创新产品使Amazon Aurora成为亚马逊云科技历史上增长最快的服务，数十万客户选择它作为关系型数据库解决方案。

深入探讨与Amazon RDS相关的成本维度，Penn阐明了构成总体支出的各个组成部分。计算和存储成本是每个RDS集群固有的，而备份、数据传输和IOPS(每秒输入/输出操作数)则构成大多数客户工作负载中常见的额外成本。此外，某些成本可能因特定应用程序用例和所使用的数据库功能而有所不同。

为了说明常见的客户挑战及其相应的解决方案，Penn介绍了一家名为“AnyCompany”的虚构公司。这个假设的客户旅程涵盖了Penn和他的团队在日常与客户互动中遇到的最普遍的问题。

AnyCompany是一家初创公司，利用生成式人工智能帮助电子商务卖家将每种产品转变为畅销商品。他们依赖Amazon EKS作为应用程序层，依赖Amazon RDS作为运营数据库层。作为一家快速成长且成功的初创公司，AnyCompany面临着在扩展过程中平衡成本和性能的挑战，这正是亚马逊云科技经常帮助客户解决的难题。

AnyCompany面临的第一个挑战是由于客户采用率提高导致CPU利用率增加，从而引发性能问题。最初，AnyCompany使用了r6g.xlarge实例类型，在客户采用率激增之前运行良好。但随后，CloudWatch中的CPU利用率指标偶尔会飙升至100%，对他们的解决方案的可靠性产生不利影响，并引发客户对于缓慢和超时的投诉。

面对选择合适RDS实例类型的困境(这是客户普遍面临的难题)，Penn和他的团队寻求一种兼顾性能和成本意识的解决方案。亚马逊云科技提供了多种选择，包括适用于较小或可变工作负载的可突发实例、适用于CPU密集型应用程序的通用实例、适用于内存密集型应用程序的内存优化实例，以及基于ARM架构的Graviton实例，后者与x86实例相比提供了更优的价格/性能比，适用于各种工作负载。

为确定最佳实例类型，AnyCompany利用了监控工具，如亚马逊云科技的主要监控和可观察服务Amazon CloudWatch，它可以基于多个实例级指标(如CPU、内存、网络和磁盘级利用率)进行监控、可视化和警报。对于更细粒度的操作系统级指标，包括Linux、大页面、交换活动和操作系统进程列表，RDS增强监控功能非常宝贵。此外，RDS Performance Insights成为深入数据库级监控的首选工具，包括可视化SQL语句和等待事件，支持所有Amazon RDS引擎。

RDS Performance Insights尤其受到众多客户的好评，因为它能够通过多种维度(如等待事件、SQL语句、应用程序、服务器等)对活动进行可视化、深入分析、切片和切块，从而有效高效地诊断甚至最复杂的数据库瓶颈。

许多客户(包括AnyCompany)发现CloudWatch和Performance Insights对于实例大小调整决策很有用，但由于需要管理数十、数百或数千个实例，他们表示需要更多自动化的大规模建议。为响应这一反馈，亚马逊云科技宣布了对Amazon RDS MySQL和Amazon RDS PostgreSQL的Amazon Compute Optimizer支持，使客户能够为他们的实例群识别合适的实例大小。

利用合适的工具和Amazon Compute Optimizer，AnyCompany解决了第一个挑战，将实例迁移到了基于更新的Graviton架构的r7g.xlarge实例。这一迁移实现了27%的价格/性能改进，为客户提供了更加稳定的工作负载，同时利用最新的Graviton创新以一种经济高效的方式提升性能。

第二个挑战出现时，负责查询数据库进行报告的内部客户(数据分析师)无意中导致了核心客户应用程序的性能下降。这种经典的“嘈杂邻居”情况(竞争工作负载在同一数据库资源上相互干扰)需要有效的隔离或管理策略。

传统方法是通过纵向扩展(将实例大小调整为更大)来解决，但Penn和他的团队提出了一种更灵活的解决方案:RDS Read Replicas。通过创建多达15个Read Replica(每个可能具有不同的大小)，AnyCompany可以消除嘈杂邻居问题，确保应用程序获得更高的吞吐量。

评估纵向和横向扩展的成本差异，Penn指出，将实例从r7g.xlarge纵向扩展到r7g.2xlarge会使AnyCompany的计算成本增加一倍。相反，他们选择了使用Read Replica进行横向扩展，采用较小的Read Replica实例r7g.large，以更加经济的方式有效解决了报告查询。

解决嘈杂邻居问题的另一种替代方案是使用Amazon ElastiCache缓存频繁访问的数据，如SQL结果集。这种方法可以提供更快的性能，在许多情况下成本也更低。然而，使用ElastiCache缓存频繁访问的结果集并不适用于所有用例和工作负载，尤其是那些涉及唯一、特定和动态过滤器的情况。

在AnyCompany的特定场景中，大多数报告查询都是动态和特定的，因此使用Read Replica卸载查询被证明是最佳解决方案，实现了核心面向客户的应用程序和API性能整体提升50%。

Penn探讨的第三个成本维度是存储。Amazon RDS提供了一系列EBS(Elastic Block Store)选项来满足不同的性能需求，包括将IOPS数量与分配的存储量挂钩的gp2，以及允许独立于存储大小分配IOPS和吞吐量的gp3。虽然gp2和gp3都最适合于开发、测试环境和中型工作负载，但对于需要一致低延迟的关键任务应用程序，io1和io2 Block Express则是不二之选，其中io2由于提供了更高的持久性、吞吐量和亚毫秒I/O延迟而被更加推荐。

将io2与io1进行对比，Penn强调，io2提供了99.999%的五个九的持久性，比io1高出100倍，并提供亚毫秒I/O延迟，是Amazon RDS中唯一一种提供如此低延迟的EBS选项。此外，io1和io2的定价相同，因此Penn建议从io1迁移到io2，以获得更好的性能和持久性，而无需承担额外成本，但前提是要在生产环境之外的预生产或非生产环境中彻底测试迁移。

AnyCompany还遇到了另一个与EBS I/O延迟相关的挑战。随着数据库的扩展，他们达到了EBS IOPS限制，导致I/O延迟从2毫秒飙升至500毫秒，这是一个巨大的性能打击。高I/O需求可能会导致I/O瓶颈和I/O延迟问题，需要采取解决措施。

AnyCompany的要求很明确:他们需要为关键任务应用程序提供亚毫秒I/O延迟。利用合适的监控工具，包括RDS Performance Insights的指标仪表板，Penn和他的团队轻松识别出了瓶颈，发现I/O操作数量和I/O延迟都在增加，达到了上述500毫秒的水平。

解决方案是存储调优，即从gp2迁移到io2 Block Express，为AnyCompany提供了所需的亚毫秒I/O延迟。通过使用监控、CloudWatch、Performance Insights和Compute Optimizer等工具，Penn和他的团队可以了解何时何地需要进行调整。

第四个挑战集中在内部客户(数据分析师)在只读副本上执行的慢速报告查询。这些复杂的SQL查询涉及多个连接、排序和分组操作，生成了大量临时对象。像Postgres这样的数据库系统试图在内存中执行操作以获得最佳性能，但在某些情况下，当内存不足以执行这些操作时，它们会将临时对象写入磁盘，在这种情况下是EBS，可能会增加延迟，尤其是对于大型数据集和复杂查询。

为了解决这个问题，Penn强烈推荐了一个名为RDS优化读取别名的功能。优化读取提供了本地快速NVMe SSD存储，专门用于存储临时对象，而不是将它们写入EBS。此功能需要支持本地NVMe SSD存储的实例，如r6g或r6id。在AnyCompany的情况下，通过使用优化读取，他们成功解决了这个问题。

一个成本示例说明，AnyCompany可以选择垂直扩展并将只读副本迁移到r6g.xlr实例，将计算成本增加一倍。然而，他们选择使用支持优化读取的最新Graviton代r6gd和较小的实例类型r6gd.large。这种方法提供了所需的性能，查询执行时间加快了2倍，而基础设施开支却没有显著增加。事实上，原始实例类型与基于优化读取的新实例类型之间的差异不到10%，但对于报告查询的性能提升了2倍。

Penn讨论的最后一个成本维度是备份。RDS提供两种类型的备份:自动备份和数据库快照。自动备份包括每日EBS快照和每5分钟存储在S3中的事务日志，提供了在保留期内(最长可达35天)的细粒度时间点恢复能力。另一方面，数据库快照可以随时创建并保留直到删除，为长期备份管理提供了更多控制。

AnyCompany面临的挑战是备份成本高昂。虽然他们有标准的一个月备份保留期，但更仔细地检查他们的要求发现，他们只需要一周内的数据可恢复，任何更旧的数据仅用于合规性查询，不需要可恢复性。

为了大幅降低备份成本，Penn提出了几种处理长期备份的经济高效方法。一种方法是使用快照导出到S3，可以是完全或部分导出，以Apache Parquet格式存储数据，由于其压缩性，非常适合使用Amazon Athena等工具进行存储和查询。另一种替代方案是使用逻辑备份，采用本地数据库工具，如Postgres的pg_dump或MySQL的mysqldump。

无论是快照导出到S3还是逻辑备份到Amazon S3，这些方法的好处在于数据存储在客户自己的存储桶中，客户可以完全控制存储类别。例如，客户可以将存储类别定义为S3 Standard(用于频繁访问的数据)、S3 Infrequent Access(用于不太频繁访问的数据)，甚至S3 Glacier Deep Archive，相比本地RDS备份(如自动备份和数据库快照)，客户对使用的S3存储类别没有控制权，提供了更大的灵活性。

采用这种经济高效的方法，AnyCompany成功大幅降低了备份成本。假设数据库大小为500 GB，每天EBS块变化为100 GB，原始备份成本使用30天自动备份将包括初始500 GB快照(免费，因为亚马逊云科技为数据库大小提供高达100%的免费备份存储空间)和代表每日块变化的增量快照。相比之下，经济高效的替代方案是使用一周的自动RDS备份，并使用S3快照导出方法存储剩余数据，从而将备份成本降低了30%，同时满足了合规性、访问和数据保留要求。

Penn停顿下来强调了可见性在解决性能和成本挑战中的重要性，将监控工具比作手电筒、雷达和放大镜，提供检测和洞察力。他重申，如果看不到性能或成本问题，就无法解决，从而凸显了CloudWatch、Performance Insights和Enhanced Monitoring等工具的价值，AnyCompany在整个旅程中都使用了这些工具。

然而，AnyCompany也对亚马逊云科技提供的传统监控工具提出了挑战，促使开发了一种新的解决方案。第一个挑战是，虽然Performance Insights对于深入诊断数据库很有用，但信息总是以实例级视图呈现，当管理数十或数百个实例时，很难看到全貌。

第二个挑战是性能数据、跟踪和日志分散在各种亚马逊云科技工具中，导致客户要求集中的遥测解决方案，以获得真正的单一窗口。

第三个挑战围绕着需要更好地理解应用程序上下文以及应用程序API和数据库性能之间的相关性。

为了响应这些反馈，Penn宣布了CloudWatch Database Insights，这是一种新的产品，将所有数据库监控整合到Amazon CloudWatch中的统一视图。使用CloudWatch Database Insights，客户可以通过特定标签或区域内的实例定义实例集群，并获得显示实例摘要的热图，使他们能够根据各种维度(如数据库负载、数据库警报和不同指标)来了解瓶颈。

CloudWatch Database Insights最初支持Amazon Aurora PostgreSQL和Amazon Aurora MySQL，后续将支持更多RDS引擎，引入了几项创新。客户可以在深入研究特定实例时关联所有跟踪、日志数据和等待事件，从而受益于全面开箱即用的本地集中遥测。

此外，对于熟悉CloudWatch Application Insights(应用程序性能监控解决方案)的客户，CloudWatch Database Insights现在可以提供每个数据库瓶颈的相关API调用的可见性，解决了更好地理解数据库性能与应用程序性能之间相关性的需求。

最后，对于习惯于在Performance Insights中分析有问题的SQL语句的客户，CloudWatch Database Insights提供了查看每个SQL指标和统计数据随时间变化趋势的能力，而不仅仅是在选定时间段内的聚合数字，为深入分析提供了更多见解。

Penn强调，利用最新的监控创新(如CloudWatch Database Insights)，可以实现更主动地解决性能和成本挑战，就像AnyCompany在整个旅程中所做的那样。

回顾AnyCompany在亚马逊云科技的旅程，Penn强调了以下里程碑:

1.           通过实例适当调整大小(特别是使用提供了改进的价格/性能的最新Graviton创新)来解决客户采用率增加导致的工作负载增加。

2.           通过将读取密集型查询卸载到只读副本，解决了报告查询干扰核心客户应用程序的“嘈杂邻居”问题，使两种工作负载都能顺利运行而不会相互干扰。

3.           通过存储适当调整大小(从gp2迁移到io2 Block Express)，实现了亚毫秒级I/O延迟，解决了高I/O延迟问题。

4.           通过迁移到RDS优化读取，解决了由复杂SQL语句生成临时对象导致的慢速报告查询问题，性能提高了2倍。

5.           通过采用成本高效的长期备份方法(如快照导出到S3)，将备份成本降低了30%，同时满足了合规性、访问和数据保留要求。

此时，Penn将演示权移交给Tim，他将讨论与Amazon Aurora相关但有所不同的旅程。

Tim首先重新介绍了AnyCompany的虚构初创公司，这次决定从Amazon Aurora开始他们的旅程，而不是Amazon RDS。他概述了Aurora，一个为云而构建的关系数据库管理系统，与MySQL和PostgreSQL完全兼容，吞吐量是标准MySQL的5倍，是PostgreSQL的3倍，并在存储层提供了弹性，这使其与RDS有所不同，在价格和性能方面也存在不同的权衡。

Tim澄清，虽然AnyCompany在这个虚构场景中选择从Aurora开始，但客户可以在他们认为合适的时候使用亚马逊云科技数据迁移服务或自己的工具在RDS和Aurora之间迁移。

认识到Aurora存储架构的重要性，Tim在探讨成本维度之前，将演示的重要部分专注于这一方面。Aurora将存储与头节点分离，存储层分布在多个可用区中，由许多存储节点组成。当发生写操作时，Aurora会在所有这些存储节点上创建6个副本，确保跨3个可用区的6路持久性，而客户只需为其中一个副本付费。

这种架构使Aurora能够承受整个可用区的存储节点和卷中一个额外存储节点的损失，而不会影响持久性或可用性，提供了开箱即用的弹性。

Tim随后将重点转移到存储成本方面。在Aurora中，客户需要为存储大小和IO(输入/输出操作)付费。存储大小按每GB-月计费，亚马逊云科技会根据需要自动扩展和缩减卷，允许客户在CloudWatch中监控Volume Bytes Used指标。客户还可以通过在PostgreSQL中运行VACUUM或配置auto-vacuum来控制存储大小。

关于IO，每个数据库页面读取操作在Aurora中都算作一次IO，无论使用哪种数据库引擎。对于写入操作，由于Aurora和数据库引擎的工作方式，它们是以4KB为单位构建的，并被拼接在一起，因为它们的大小可能会有所不同。IO按每100万次请求计费，客户可以进行的IO数量是可扩展的，只要他们能够通过实例驱动IO即可。

Tim随后举了一个成本示例，假设100GB的卷每天增长100MB，基础负载为每秒600次IO。在弗吉尼亚北部地区使用i6g.xlarge实例和按需定价，30天内实例成本约为370美元，基础负载的IO成本约为207美元，考虑到基础大小、增长和复杂的数学计算，存储成本约为每月300美元。

然而，当AnyCompany引入每秒15，000次IO的突发负载时，出现了挑战，导致额外的648美元IO成本，这是相当大且无法预测的。

为了解决这个挑战，Tim提出了缓存作为一种解决方案。通过扩大实例规模和增加缓存大小，可以减少需要通过的读取次数，从而潜在地降低IO成本并提高性能。然而，对于AnyCompany来说，考虑到它们的突发与常规IO之间的平衡，这种方法可能不是最佳解决方案。

相反，Tim建议使用Aurora I/O Optimize，这是一种定价选项，可以免除读写IO操作的费用。使用I/O Optimize，客户只需为数据库实例和存储付费，但费率不同，这样可以更容易预测成本，如果IO费用超过账单的25%，则可能节省高达40%的成本。此外，I/O Optimize还可以提高吞吐量，降低延迟，并从未来的性能优化中获益。

切换集群到I/O Optimize是一个单击操作，可以在不停机或故障转移的情况下启用或禁用，允许客户尝试并在需要时恢复。

重新审视之前的成本示例，使用I/O Optimize后，按不同费率计费的实例成本约为486美元，存储成本约为675美元，常规基础负载和突发IO不会产生额外费用，从而节省了28%的成本，同时提高了可预测性和性能。

第二个挑战涉及内部客户，如运行读取密集型报告作业的数据分析师，他们可能会影响node内部的缓冲池，从而影响公司主要收入来源的前端查询性能。

解决方案是为集群添加Read Replicas，它们共享相同的物理存储，并可以放置在不同的Availability Zones或打包到同一个区域中。通过将读取密集型查询卸载到Read Replicas，AnyCompany可以减少对前端查询的影响，同时提高整体性能并保持成本效益。

Tim强调，添加Read Replicas不会影响数据持久性，因为只有一个写入node负责以毫秒级延迟将所有副本保持最新，确保结果一致。此外，每个副本都可以作为故障转移目标，提高了弹性，同时允许客户在成本、性能和可用性之间进行权衡。

对于工作集很大的工作负载，如果之前的权衡可能无法经济实现，Tim介绍了Aurora PostgreSQL的Optimize Reads。类似于RDS功能，Optimize Reads利用node中的NVMe SSD来存储临时数据，而不是EBS，从而提高性能。

然而，Aurora PostgreSQL的Optimize Reads还包括Tiered Cache，它允许将缓冲池扩展到内存之外并存储在SSD上，从而为读取密集型查询提供高达8倍的性能改进。虽然不如内存快，但根据工作集的大小，使用更便宜的实例和Tiered Cache可能更具成本效益。

为了说明使用Optimized Reads的成本优势，Tim举了一个示例，AnyCompany将实例从R6G.XLARGE切换到支持230GB分层缓存的R6GD.XLARGE。要在不使用Optimized Reads的情况下获得相当于内存中缓存的数量，他们将需要一个I6G.12XLARGE实例，这将花费约5，830美元/月，而R6GD.XLARGE实例的成本为583美元/月，代表了90%的成本节省，同时可能提供可比的性能。

第三个挑战是开发人员需要使用生产数据进行测试，之前需要通过ETL作业复制生产数据，导致昂贵的全量数据复制。此外，当开发人员不使用系统时，它仍然处于空闲状态，浪费了资金，而且不频繁的刷新导致测试环境过时。

解决方案是使用Aurora的Fast Clones，这是一种虚拟副本机制，利用写时复制(copy-on-write)创建新卷而无需复制实际数据字节，使其成为一个快速且经济高效的过程。AnyCompany可以每天创建一个克隆，可能对数据进行匿名化处理，并将其视为一个可通过新数据库实例和卷访问的黄金镜像。

克隆只在对卷进行修改时产生存储成本，客户最多可以在一个家族中创建15个Fast Clones。这种方法解决了AnyCompany的存储成本问题，同时提供了新鲜的测试环境。

第四个挑战涉及测试环境的计算成本。AnyCompany需要为他们的测试提供良好的性能，同时避免在开发人员不使用系统时持续运行大型实例的开销。

解决方案是使用Aurora Serverless，这是一种按需、自动扩展实例大小的服务，根据指定的Aurora Capacity Unit (ACU)范围进行调整。客户只需为每秒使用的ACU付费，提供了细粒度的成本控制。

最近，Aurora Serverless获得了两项增强:能够扩展到256个ACU(之前限制的两倍)，以及在不使用时可以缩减到0并不收费的能力。

在一个成本示例中，假设有10名开发人员，100GB存储空间，变化率为10%，历史负载模式显示在一天的工作时间内，实例有一半时间处于空闲状态。使用Aurora Serverless并设置8个ACU的工作负载，与使用预配置的R6G.LARGE实例相比，计算成本降低了38%。此外，通过使用Fast Clones而不是完整卷复制，AnyCompany在存储成本上实现了90%的节省，从而获得了显著的节省，同时还能够缩减到0并扩展到256个ACU。

Tim随后讨论了Aurora内置的持续备份功能，它会持续地以增量方式写入S3，而不会影响数据库实例的性能。备份费用根据在指定的1到35天备份保留期内需要恢复所需的空间量计费，类似于RDS。客户还可以使用快照来实现超出备份保留期的长期数据保留。

备份的成本管理可以通过将快照导出到S3、使用本机数据库工具进行逻辑备份、调整保留期或通过VACUUM等操作减小卷大小来实现。由于客户只需为所使用的部分付费，因此减少使用量可以节省成本。

第五个挑战出现在AnyCompany在A区域和B区域扩展全球业务时。他们希望消除跨区域读取延迟，保持一致性，避免开发自己的软件解决方案，并实现全球弹性、低延迟读取和多区域部署的次线性成本。

解决方案是Aurora Global Database，它提供了低RPO灾难恢复、快速本地区域读取(如果配置)以及跨区域切换读取器以保持低延迟的能力，从而实现跟随太阳工作负载。

在这个示例中，Tim着重介绍了Aurora Global Database如何实现快速本地读取。从A区域的主集群开始，通过让Aurora Global Database从主区域的存储读取并写入辅助区域的存储来在B区域建立辅助集群，从而保持它们同步。

客户需要为复制到辅助区域的计算、存储和写入IO操作付费，而成本维度与之前讨论的相同，只是跨多个区域。通过设置Aurora Global Database，AnyCompany可以实现单位数毫秒级的本地读取延迟，创建主集群比辅助集群大的不对称集群以实现非线性成本平衡，并从全球灾难恢复功能中获益。

最后一个挑战是随着AnyCompany的增长，可能会达到128TB卷大小和最大HG 48XL实例大小的限制。他们需要一种方式来扩展超过128TB的存储，并且在不支付过多容量的情况下有效扩展超过单个写入实例的写入吞吐量。

解决方案是最近发布的Postgres Limitless Database。这个功能支持通过分片实现自动水平扩展，允许客户指定一个分片键，亚马逊云科技将根据数据库负载使用Serverless技术和ACU进行成本控制，将数据库拆分为多个部分，并调整这些部分的大小和数量。

Postgres Limitless Database提供了从客户角度看分布式Serverless、写入扩展和单一数据库端点，客户只需为所使用的部分付费。

总的来说，Tim强调了AnyCompany在使用Aurora过程中的以下几个关键点:

•              使用Aurora I/O Optimized节省了28%的成本，并提高了可预测性。

•              使用Optimize Reads功能，读取性能提高了8倍。

•              通过使用Fast Clones和Aurora Serverless，测试环境的存储成本降低了90%，计算成本也降低了。

•              借助Aurora Global Database，实现了本地低延迟读取和全球灾难恢复能力。

•              凭借Postgres Limitless Database，可以扩展到PB级别的卷和每秒百万次写入。

Tim强调，优化成本和性能是相辅相成的任务，应该同时进行，Aurora和RDS共享了诸如Performance Insights之类的工具，以帮助选择合适的工具。此外，Penn宣布的CloudWatch Database Insights可以洞察以前看不到的性能和成本瓶颈。

最后，Tim和Penn鼓励与会者利用从本次演讲中获得的见解，优化RDS或Aurora工作负载的价格和性能，并充分利用整个会议分享的各种工具和最佳实践。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。