Amazon EBS 提供以下卷类型，各种类型性能特点和价格不同，因此您可根据应用程序要求定制您所需的存储性能和相应成本。卷类型归入两大类别：
-
支持 SSD 的卷针对涉及小型 I/O 的频繁读/写操作的事务性工作负载进行了优化，其中管理性能属性为 IOPS
-
支持 HDD 的卷针对吞吐量 (以 MiB/s 为单位) 是优于 IOPS 的性能指标的大型流式处理工作负载进行了优化
下表列出了每个卷类型的使用案例和性能特点。
注意
EBS 卷类型性能的 AWS 更新可能不会立即在您的现有卷上生效。要查看较早卷上的全部性能，您需要先在其上执行 ModifyVolume 操作。有关更多信息，请参阅在 Linux 上修改 EBS 卷的大小、IOPS 或类型。
| 固态硬盘 (SSD) | 硬盘驱动器 (HDD) | |||
|---|---|---|---|---|
| 卷类型 | 通用型 SSD (gp2)* | 预配置 IOPS SSD (io1) | 吞吐优化 HDD (st1) | Cold HDD (sc1) |
| 描述 | 平衡价格和性能的通用 SSD 卷，可用于多种工作负载 | 最高性能 SSD 卷，可用于任务关键型低延迟或高吞吐量工作负载 | 为频繁访问的吞吐量密集型工作负载设计的低成本 HDD 卷 | 为不常访问的工作负载设计的最低成本 HDD 卷 |
| 使用案例 |
|
|
|
|
| API 名称 | gp2 | io1 | st1 | sc1 |
| 卷大小 | 1 GiB - 16 TiB | 4 GiB - 16 TiB | 500 GiB - 16 TiB | 500 GiB - 16 TiB |
| 最大IOPS**/卷 | 16,000*** | 64,000**** | 500 | 250 |
| 最大吞吐量/卷 | 250 MiB/s*** | 1,000 MiB/s† | 500 MiB/s | 250 MiB/s |
| 最大IOPS/实例†† | 80,000 | 80,000 | 80,000 | 80,000 |
| 最大吞吐量/实例†† | 1,750 MiB/s | 1,750 MiB/s | 1,750 MiB/s | 1,750 MiB/s |
| 管理性能属性 | IOPS | IOPS | MiB/s | MiB/s |
* 从控制台创建的 EBS 卷的默认卷类型是 gp2。使用不带卷类型参数的 CreateVolume API 创建的卷默认为 gp2 或 standard（视区域而定）：
-
standard：us-east-1、eu-west-1、eu-central-1、us-west-2、us-west-1、sa-east-1、ap-northeast-1、ap-northeast-2、ap-southeast-1、ap-southeast-2、ap-south-1、us-gov-west-1、cn-north-1 -
gp2：所有其他区域
**gp2/io1 基于 16 KiB I/O 大小，st1/sc1 基于 1 MiB I/O 大小
*** 通用型 SSD (gp2) 卷的吞吐量限制介于 128 MiB/s 和 250 之间，具体取决于卷大小。如果有突增积分可用，大于 170 GiB 但小于 334 GiB 的卷将提供 250 的最大吞吐量。334 GiB 及更大的卷将提供 250 的最大吞吐量（无论突增积分如何）。较早的 gp2 卷无法实现全部性能，除非在该卷上执行了 ModifyVolume 操作。有关更多信息，请参阅 Amazon EBS 弹性卷。
**** 在基于 Nitro 的实例上仅保证 64,000 最大 IOPS。其他实例保证性能最高为 32,000 IOPS。
† 在基于 Nitro 的实例上仅保证 1,000 MiB/s 最大吞吐量。其他实例保证最高为 500 MiB/s。较早的 io1 卷无法实现全部性能，除非在该卷上执行了 ModifyVolume 操作。有关更多信息，请参阅 Amazon EBS 弹性卷。
†† 要实现此吞吐量，您必须要有支持该吞吐量的实例。有关更多信息，请参阅Amazon EBS 优化的实例。
下表列出了上一代 EBS 卷类型。如果您需要比上一代卷更高的性能或性能一致性，建议您考虑使用通用型 SSD (gp2) 或其他最新卷类型。有关更多信息，请参阅上一代卷。
| 上一代卷 | |
|---|---|
| 卷类型 | EBS 磁介质 |
| 描述 | 上一代 HDD |
| 使用案例 | 数据不常访问的工作负载 |
| API 名称 | standard |
| 卷大小 | 1 GiB - 1 TiB |
| 最大IOPS/卷 | 40–200 |
| 最大吞吐量/卷 | 40–90 MiB/s |
| 最大IOPS/实例 | 80,000 |
| 最大吞吐量/实例 | 1,750 MiB/s |
| 管理性能属性 | IOPS |
注意
Linux AMIs 需要将 GPT 分区表和 GRUB 2 用于 2 TiB (2048 GiB) 或更大的引导卷。现在的许多 Linux AMIs 都使用 MBR 分区方案，此方案仅支持最高 2047 GiB 的引导卷。如果您的实例不通过 2 TiB 或更大的引导卷启动，您要使用的 AMI 会限制为 2047 GiB 引导卷大小。非引导卷对 Linux 实例没有这种限制。
有多种因素会影响 EBS 卷的性能，如实例配置、I/O 特性和工作负载需求。有关充分利用 EBS 卷的更多信息，请参阅 Linux 实例上的 Amazon EBS 卷性能。
有关这些卷类型的定价的更多信息，请参阅 Amazon EBS 定价。
通用型 SSD (gp2) 卷
通用型 SSD (gp2) 卷提供经济实惠的存储，是广泛工作负载的理想选择。这些卷可以提供几毫秒的延迟，能够突增至 3000 IOPS 并维持一段较长的时间。在最小 100 IOPS（以 33.33 GiB 及以下）和最大 16,000 IOPS（以 5334 GiB 及以上）之间，基准性能以每 GiB 卷大小 3 IOPS 的速度线性扩展。AWS 对 gp2 卷进行了设计，以在 99% 的时间内提供 90% 的预配置性能。gp2 卷的大小范围为 1 GiB 到 16 TiB。
I/O 积分和突增性能
gp2 卷的性能与卷大小关联，卷大小确定卷的基准性能水平以及积累 I/O 积分的速度；卷越大，基准性能级别就越高，I/O 积分积累速度也越快。I/O 积分表示您的gp2 卷在需求超过基准性能时可用来突增大量 I/O 的可用带宽。您的卷拥有的 I/O 点数越多，它在需要更高性能时可以超过其基准性能水平的突增时间就越长，表现也越好。下图显示 gp2 的突增存储桶行为。
每个卷都有 540 万 I/O 点的初始 I/O 积分余额，这足以维持 3000 IOPS 的最大突增性能 30 分钟。设计初始积分余额的目的是为引导卷提供快速初始启动循环，并为其他应用程序提供良好的引导过程。卷以每 GiB 卷大小 3 IOPS 的基准性能率的速度获得 I/O 积分。例如，一个 100 GiB 的gp2 卷具有 300 IOPS 的基准性能。
当卷的需求超出了基准性能 I/O 水平时，它会使用积分余额中的 I/O 积分突增到所需的性能水平，最大为 3000 IOPS。大于 1000 GiB 的卷的基准性能等于或大于最大突增性能，并且其 I/O 积分余额永远不会耗尽。如果卷在一秒内使用的 I/O 积分少于它所赚取的积分，未使用的 I/O 积分会加到 I/O 积分余额中。卷的最大 I/O 积分余额等于初始积分余额 (540 万 I/O 积分)。
注意
对于 1 TiB 或更大的卷，基准性能大于最大突增性能，因此 I/O 点数永远不会耗尽。如果卷附加到基于 Nitro 的实例，则报告的突发余额为 0%。对于非基于 Nitro 的实例，报告的突发余额为 100%。
下表列出了几种卷大小以及卷的相关基准性能 (也就是它积累 I/O 积分的速度)、在最大 3000 IOPS 时的突增持续时间 (从完整积分余额开始时) 以及卷重新填满空积分余额所需的秒数。
| 卷大小 (GiB) | 基准性能 (IOPS) | 提供持续的 3,000 IOPS 时的突增持续时间（秒） | 在未执行 IO 时填充空积分余额的秒数 |
|---|---|---|---|
| 1 | 100 | 1802 | 54000 |
| 100 | 300 | 2000 | 18000 |
| 250 | 750 | 2400 | 7200 |
| 334（最大吞吐量的最小大小） | 1002 | 2703 | 5389 |
| 500 | 1500 | 3600 | 3600 |
| 750 | 2250 | 7200 | 2400 |
| 1000 | 3000 | 不适用* | 不适用* |
| 5334（最大 IOPS 的最小大小） | 16,000 | 不适用* | 不适用* |
| 16384 (16 TiB，最大卷大小) | 16,000 | 不适用* | 不适用* |
* 突增和 I/O 积分仅与低于 1000 GiB 的卷有关，此时突增性能超出了基准性能。
卷的突增持续时间取决于卷的大小、所需的突增 IOPS 以及突增开始时的积分余额。如下面的等式所示：
(Credit balance)
Burst duration = ------------------------------------
(Burst IOPS) - 3(Volume size in GiB)如果我清空我的 I/O 积分余额，会发生什么情况？
如果您的 gp2 卷使用其所有 I/O 积分余额，则该卷的最大 IOPS 性能将保持在基准 IOPS 性能水平 (亦即您的卷获得积分的速率)，并且该卷的最大吞吐量将降低到最大 I/O 大小乘以基准 IOPS。吞吐量绝不会超过 250 MiB/s。当 I/O 需求下降到基准水平以下并且未使用的积分添加到 I/O 积分余额中时，该卷的最大 IOPS 性能会再次超出基准。例如，积分余额为空的 100 GiB gp2 卷具有 300 IOPS 的基准性能和 75 MiB/s 的吞吐量限制 (每秒 300 个 I/O 操作 * 每个 I/O 操作 256 KiB = 75 MiB/s)。卷越大，基准性能就越高，补充积分余额的速度也越快。有关如何测量 IOPS 的更多信息，请参阅 I/O 特征和监控。
如果您注意到卷性能常常受限于基准水平（由于空 I/O 积分余额），则应考虑使用较大的 gp2 卷（具有较高基准性能水平），或对需要大于 16,000 IOPS 的持续 IOPS 性能的工作负载改用 io1 卷。
有关使用 CloudWatch 指标和警报来监控突增存储桶余额的信息，请参阅监控 gp2、st1 和 sc1 卷的突增存储桶余额。
吞吐量性能
gp2 卷的吞吐量可以使用以下公式计算，吞吐量上限为 250 MiB/s：
Throughput in MiB/s = ((Volume size in GiB) × (IOPS per GiB) × (I/O size in KiB))假定 V = 卷大小，I = I/O 大小，R = I/O 速率，并且 T = 吞吐量，这可以简化为：
T = VIR实现最大吞吐量的最小卷大小可通过以下方式得出：
T
V = -----
I R
250 MiB/s
= ---------------------
(256 KiB)(3 IOPS/GiB)
[(250)(2^20)(Bytes)]/s
= ------------------------------------------
(256)(2^10)(Bytes)([3 IOP/s]/[(2^30)(Bytes)])
(250)(2^20)(2^30)(Bytes)
= ------------------------
(256)(2^10)(3)
= 357,913,941,333 Bytes
= 333⅓ GiB (334 GiB in practice because volumes are provisioned in whole gibibytes)预配置 IOPS SSD (io1) 卷
预配置 IOPS SSD (io1) 卷旨在满足 I/O 密集型工作负载（尤其是数据库工作负载）的需要，这些工作负载对存储性能和一致性非常敏感。与使用存储桶和积分模型计算性能的 gp2 不同，io1 卷允许您在创建卷时指定一致的 IOPS 速率，Amazon EBS 在指定年份的超过 99.9% 的时间里可提供 10% 以内的预配置 IOPS 性能。
io1 卷的大小范围是 4 GiB 到 16 TiB。您可以在基于 Nitro 的实例实例上为每个卷预置 100 IOPS 到 64,000 IOPS，并在其他实例上最多预置 32,000。预配置 IOPS 与请求的卷大小 (GiB) 的最大比率为 50:1。例如，100 GiB 卷可以预配置为最高 5,000 IOPS。在支持的实例类型上，任何大小为 1280 GiB 或更大的卷可以预配置为最大值 64,000 IOPS (50 × 1280 GiB = 64000)。
任何预配置了最高 32000 IOPS 的 io1 卷支持 256 KiB 的最大 I/O 大小，可以得到最高 500 MiB/s 的吞吐量。当 I/O 大小达到最大时，吞吐量也将达到峰值 2000 IOPS。任何预配置了超过 32000 IOPS（最高为上限 64000 IOPS）的卷支持 16 KiB 的最大 I/O 大小，可以得到最高 1000 MiB/s 的吞吐量。下图说明了这些性能特性：
您的每 I/O 延迟体验取决于预配置 IOPS 以及您的工作负载模式。要获得最佳的每 I/O 延迟体验，我们建议您将 IOPS 与 GiB 的比率预配置为大于 2:1。例如，2,000 IOPS 卷应该小于 1,000 GiB。
注意
2012 年以前创建的部分 AWS 账户可能可以访问 us-west-1 或 ap-northeast-1 中不支持 预配置 IOPS SSD (io1) 卷的可用区。如果您无法在其中一个区域中创建 io1 卷（或在其块储存设备映射中启动具有 io1 卷的实例），请尝试该区域中的其他可用区。您可以通过在某可用区创建 4 GiB io1 卷来验证该可用区是否支持 io1卷。
吞吐优化 HDD (st1) 卷
吞吐优化 HDD (st1) 卷提供低成本的磁性存储，该存储以吞吐量而不是 IOPS 定义性能。该卷类型是大型顺序工作负载 (如 Amazon EMR、ETL、数据仓库和日志处理) 的理想之选。不支持可启动的 st1 卷。
吞吐优化 HDD (st1) 卷虽然与 Cold HDD (sc1) 卷类似，但其设计用于支持频繁 访问的数据。
该卷类型针对涉及大型顺序 I/O 的工作负载进行了优化，建议具有执行少量随机 I/O 工作负载的客户使用 gp2。有关更多信息，请参阅HDD 上的小型读/写效率低下问题。
吞吐量积分和突增性能
与 gp2 类似，st1 使用突增存储桶模型提高性能。卷大小决定卷的基准吞吐量，即卷积累吞吐量积分的速度。卷大小还决定卷的突增吞吐量，即有积分可用时消耗积分的速度。较大的卷有较高的基准吞吐量和突增吞吐量。卷的积分越多，它以突增水平驱动 I/O 的时间就越长。
下图显示 st1 的突增存储桶行为。
st1 卷的可用吞吐量受吞吐量和吞吐量积分上限的限制，由以下公式表示：
(Volume size) x (Credit accumulation rate per TiB) = Throughput对于 1 TiB st1 卷，突增吞吐量限制为 250 MiB/s，存储桶以 40 MiB/s 的速度填充，最多可容纳 1 TiB 积分。
较大的卷会线性扩展这些限制，吞吐量上限为最大 500 MiB/s。在存储桶耗尽时，吞吐量会限制为基准速率，即每 TiB 40 MiB/s。
在从 0.5 到 16 TiB 的卷大小范围内，基准吞吐量从 20 到上限 500 MiB/s 变化，12.5 TiB 时达到上限，如下所示：
40 MiB/s
12.5 TiB x ---------- = 500 MiB/s
1 TiB 突增吞吐量从 125 MiB/s 到上限 500 MiB/s 变化，2 TiB 时达到上限，如下所示：
250 MiB/s
2 TiB x ---------- = 500 MiB/s
1 TiB 下表列出了 st1 基准和突增吞吐量值的完整范围：
| 卷大小 (TiB) | ST1 基准吞吐量 (MiB/s) | ST1 突增吞吐量 (MiB/s) |
|---|---|---|
| 0.5 | 20 | 125 |
| 1 | 40 | 250 |
| 2 | 80 | 500 |
| 3 | 120 | 500 |
| 4 | 160 | 500 |
| 5 | 200 | 500 |
| 6 | 240 | 500 |
| 7 | 280 | 500 |
| 8 | 320 | 500 |
| 9 | 360 | 500 |
| 10 | 400 | 500 |
| 11 | 440 | 500 |
| 12 | 480 | 500 |
| 12.5 | 500 | 500 |
| 13 | 500 | 500 |
| 14 | 500 | 500 |
| 15 | 500 | 500 |
| 16 | 500 | 500 |
下图绘制了表值：
注意
如果创建 吞吐优化 HDD (st1) 卷的快照，则在快照处理过程中，性能可能会降低，最坏情况下会降低到卷的基准值。
有关使用 CloudWatch 指标和警报来监控突增存储桶余额的信息，请参阅监控 gp2、st1 和 sc1 卷的突增存储桶余额。
Cold HDD (sc1) 卷
Cold HDD (sc1) 卷提供低成本的磁性存储，该存储以吞吐量而不是 IOPS 定义性能。sc1 的吞吐量限制比 st1 更低，是大型顺序冷数据工作负载的理想选择。如果您需要频繁访问数据并且希望节约成本，sc1 提供价格低廉的块存储。不支持可启动的 sc1 卷。
Cold HDD (sc1) 卷虽然与 吞吐优化 HDD (st1) 卷类似，但其设计用于支持不频繁 访问的数据。
注意
该卷类型针对涉及大型顺序 I/O 的工作负载进行了优化，建议具有执行少量随机 I/O 工作负载的客户使用 gp2。有关更多信息，请参阅HDD 上的小型读/写效率低下问题。
吞吐量积分和突增性能
与 gp2 类似，sc1 使用突增存储桶模型提高性能。卷大小决定卷的基准吞吐量，即卷积累吞吐量积分的速度。卷大小还决定卷的突增吞吐量，即有积分可用时消耗积分的速度。较大的卷有较高的基准吞吐量和突增吞吐量。卷的积分越多，它以突增水平驱动 I/O 的时间就越长。
sc1 卷的可用吞吐量受吞吐量和吞吐量积分上限的限制，由以下公式表示：
(Volume size) x (Credit accumulation rate per TiB) = Throughput对于 1 TiB sc1 卷，突增吞吐量限制为 80 MiB/s，存储桶以 12 MiB/s 的速度填充，最多可容纳 1 TiB 积分。
较大的卷会线性扩展这些限制，吞吐量上限为最大 250 MiB/s。在存储桶耗尽时，吞吐量会限制为基准速率，即每 TiB 12 MiB/s。
在从 0.5 到 16 TiB 的卷大小范围内，基准吞吐量从 6 MiB/s 到最大 192 MiB/s 变化，16 TiB 时达到上限，如下所示：
12 MiB/s
16 TiB x ---------- = 192 MiB/s
1 TiB 突增吞吐量从 40 MiB/s 到上限 250 MiB/s 变化，3.125 TiB 时达到上限，如下所示：
80 MiB/s
3.125 TiB x ----------- = 250 MiB/s
1 TiB 下表列出了 sc1 基准和突增吞吐量值的完整范围：
| 卷大小 (TiB) | SC1 基准吞吐量 (MiB/s) | SC1 突增吞吐量 (MiB/s) |
|---|---|---|
| 0.5 | 6 | 40 |
| 1 | 12 | 80 |
| 2 | 24 | 160 |
| 3 | 36 | 240 |
| 3.125 | 37.5 | 250 |
| 4 | 48 | 250 |
| 5 | 60 | 250 |
| 6 | 72 | 250 |
| 7 | 84 | 250 |
| 8 | 96 | 250 |
| 9 | 108 | 250 |
| 10 | 120 | 250 |
| 11 | 132 | 250 |
| 12 | 144 | 250 |
| 13 | 156 | 250 |
| 14 | 168 | 250 |
| 15 | 180 | 250 |
| 16 | 192 | 250 |
下图绘制了表值：
注意
如果创建 Cold HDD (sc1) 卷的快照，则在快照处理过程中，性能可能会降低，最坏情况下会降低到卷的基准值。
有关使用 CloudWatch 指标和警报来监控突增存储桶余额的信息，请参阅监控 gp2、st1 和 sc1 卷的突增存储桶余额。
磁介质 (standard)
磁介质卷由磁盘驱动器支持，适用于不经常访问数据的工作负载以及小型卷大小的低成本存储非常重要的场景。这些卷平均提供大约 100 IOPS，突增能力最大可达数百 IOPS，大小范围是 1 GiB 到 1 TiB。
注意
磁介质是上一代卷。对于新应用程序，我们建议使用较新的卷类型。有关更多信息，请参阅上一代卷。
有关使用 CloudWatch 指标和警报来监控突增存储桶余额的信息，请参阅监控 gp2、st1 和 sc1 卷的突增存储桶余额。
使用 HDD 卷时的性能注意事项
为了使用 HDD 卷获得最优的吞吐量结果，请根据以下注意事项计划您的工作负载。
吞吐优化 HDD 与Cold HDD
st1 和 sc1 存储桶大小因卷大小而异，满的存储桶包含充足的令牌用于完整卷扫描。不过，因为每实例和每卷的吞吐量限制，更大的 st1 和 sc1 卷需要更长的时间完成卷扫描。附加到较小实例的卷被限制在每实例吞吐量上，而不是 st1 或 sc1吞吐量限制。
st1 和 sc1 的设计都可以在 99% 的时间内提供 90% 的突增吞吐量性能一致性。不合规时间近似均匀分配，目标是达到 99% 的每小时预计总吞吐量。
下表列出了不同大小卷的理想扫描时间，假设存储桶是满的并且有充足的实例吞吐量。
一般来说，扫描时间可由此公式表示：
Volume size
------------- = Scan time
Throughput例如，考虑到性能一致性保证和其他优化，拥有 5 TiB 卷的 st1 客户预计在 2.91 到 3.27 小时内完成整卷扫描。
5 TiB 5 TiB
----------- = ------------------- = 10,486 s = 2.91 hours (optimal)
500 MiB/s 0.00047684 TiB/s
2.91 hours
2.91 hours + -------------- = 3.27 hours (minimum expected)
(0.90)(0.99) <-- From expected performance of 90% of burst 99% of the time同样，拥有 5 TiB 卷的 sc1 客户预计在 5.83 到 6.54 小时内完成整卷扫描。
5 TiB
------------------- = 20972 s = 5.83 hours (optimal)
0.000238418 TiB/s
5.83 hours
-------------- = 6.54 hours (minimum expected)
(0.90)(0.99)| 卷大小 (TiB) | 带突增的 ST1 扫描时间 (小时)* | 带突增的 SC1 扫描时间 (小时)* |
|---|---|---|
| 1 | 1.17 | 3.64 |
| 2 | 1.17 | 3.64 |
| 3 | 1.75 | 3.64 |
| 4 | 2.33 | 4.66 |
| 5 | 2.91 | 5.83 |
| 6 | 3.50 | 6.99 |
| 7 | 4.08 | 8.16 |
| 8 | 4.66 | 9.32 |
| 9 | 5.24 | 10.49 |
| 10 | 5.83 | 11.65 |
| 11 | 6.41 | 12.82 |
| 12 | 6.99 | 13.98 |
| 13 | 7.57 | 15.15 |
| 14 | 8.16 | 16.31 |
| 15 | 8.74 | 17.48 |
| 16 | 9.32 | 18.64 |
* 这些扫描时间在执行 1 MiB 顺序 I/O 时采取平均队列深度 (四舍五入到最近的整数) 四或更多。
因此，如果您有面向吞吐量的工作负载需要快速完成扫描 (最快 500 MiB/s) 或一天查询几个整卷，请使用 st1。如果您针对成本进行了优化，数据访问相对不频繁，而且不需要超过 250 MiB/s 的扫描性能，请使用 sc1。
HDD 上的小型读/写效率低下问题
st1 和 sc1 卷的性能模型针对顺序 I/O 进行了优化，支持高吞吐量工作负载，对具有混合 IOPS 和吞吐量的工作负载提供可接受的性能，不建议使用具有小型随机 I/O 的工作负载。
例如，1 MiB 或更小的 I/O 请求计为 1 MiB I/O 积分。但是，如果是顺序 I/O，则会合并为 1 MiB I/O 数据块，并且只计为 1 MiB I/O 积分。
每实例吞吐量限制
st1 和 sc1 卷的吞吐量始终由以下限制中较小的决定：
-
卷的吞吐量限制
-
实例的吞吐量限制
对于所有 Amazon EBS 卷，我们建议选择适当的 EBS 优化的 EC2 实例来避免网络瓶颈。有关更多信息，请参阅Amazon EBS 优化的实例。
监控 gp2、st1 和 sc1 卷的突增存储桶余额
您可以使用 Amazon CloudWatch 中提供的 EBS BurstBalance 指标来监控 gp2、st1 和 sc1 卷的突增存储桶水平。这个指标显示突增存储桶中剩余的 I/O 积分百分比（对于 gp2）或吞吐量积分（对于 st1 和 sc1）。有关 BurstBalance 指标以及与 I/O 相关的其他指标的更多信息，请参阅 I/O 特征和监控。CloudWatch 还允许您设置警报，以便在 BurstBalance值降到特定水平时通知您。有关更多信息，请参阅创建 Amazon CloudWatch 警报。
270
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
