目录
文章目录
前言
Amazon Nitro System 从 2013 年开始秘密研发，2017 年正式发布，到 2021 年已经迭代到了第五代。
作为近年来市场火热的 DPU/IPU 先驱者，Amazon Nitro System 的诞生目的也被各界人士重新赋予了各种解读和含义。但正如 AWS 副总裁 Swami 所言：“在 AWS，我们 90% 到 95% 的新项目都是基于客户给我们的反馈，剩下 5% 也是从客户角度出发所做得创新尝试。”
作为 AWS 的老用户，笔者认为 Amazon Nitro System 诞生的 “因” 到底还是为了能够满足客户对 EC2 计算实例类型的多样化需求这个 First principle thinking（第一性原理）。而现在我们看到了 Amazon Nitro System 所带来的显着的性能提升和成本下降，只是 “因” 所造就的 “果” 而已。
所以本篇内容，希望能够从技术的角度回顾 Amazon Nitro System 的演进之路，回归当初的那个 “因”。
Amazon Nitro System Overview
Nitro System 这一新的架构使得 EC2 实例类型自 2017 年以来开始爆发式增长，目前已经达到 400 多种。从 2022 年开始，新的 M1、M2、M3、C1、C3、R3、I2 和 T1 等 EC2 实例类型都将基于 Nitro System 构建。例如：
- Amazon EC2 内存增强型实例，支持最大 24TiB 的内存规格，专为运行大型内存数据库而设计。
- Amazon EC2 计算优化型实例，支持最大 192 vGPU + 384GiB Memory，专为计算密集型工作负载而设计。
- Amazon EC2 计算加速型实例，支持最大 8 NVIDIA A100 Tensor Core GPU，600 GB/s NVSwitch，400 Gbps Bandwith ENA 和 EFA，转为 AI/ML 和 HPC 设计。
- 更多的 Amazon EC2 实例类型（https://aws.amazon.com/cn/ec2/instance-types/）
在 “后摩尔定律” 的时代大背景下，要想跟上业务需求的增速来持续推出规格更高的计算实例类型，显然不是一件容易的事情。一方面，要求云计算平台基础设施层的虚拟化技术能够做到 Near Bare-metal 的水平，甚至是提供更彻底的弹性裸金属实例服务；另一方面，常规的依靠摩尔定理进行纵向扩容和软件优化的技术手段已经难以为继，需要一种更具革命性的思路和形式。软硬件融合加速就是其中一种方式，将云平台基础设施层的系统组件尽可能的 Offloading（卸载）到专用硬件平台，释放珍贵的 Host CPU core，让服务器的资源更加极限的去支撑客户需求。
正如 Amzion Nitro System 首席工程师 Anthony Liguori 所说：“Nitro System 用于确保 EC2 计算实例能够将整个底层服务器资源完全开放给客户使用。”
基于这样的思路，Amazon Nitro System 开启了软硬件融合加速的商业化产品之路。
顾名思义，Amazon Nitro System 不仅仅是一个单一的专用硬件设备，而是一套完整的软硬件融合协同系统。由 Nitro Hypervisor、Nitro I/O Accelerator Cards、Nitro Security Chip 三大部分组成，今年又再继续加入了 Nitro Enclaves 和 NitroTPM（Coming soon in 2022）两大组成部分。彼此合作，又相互独立。
-
Nitro Hypervisor：是一个 Lightweight Hypervisor（轻量级虚拟机监控程序）只负责管理 CPU 和 Memory 的分配，几乎不占用 Host 资源，所有的服务器资源都可用来执行客户的工作负载。
-
Nitro Cards：是一系列用于 Offloading and Accelerated（卸载和加速）的协处理外设卡，承载网络、存储、安全及管理功能，使得网络和存储性能得到了极大提升，并且从硬件层提供天然的安全保障。
-
Nitro Security Chip：随着更多的功能被卸载到专用硬件设备上，Nitro Security Chip 提供了面向专用硬件设备及其固件的安全防护能力，包括限制云平台维护人员对设备的访问权限，消除人为的错误操作和恶意篡改。
-
Nitro Enclaves：为了进一步保障 EC2 用户的个人信息保护及数据安全，Nitro Enclaves 基于 Nitro Hypervisor 进一步提供了创建 CPU 和 Memory 完全隔离的计算环境的能力，以保护和安全地处理高度敏感的数据。
-
Nitro TPM（Trusted Platform Module，可信平台模块）：支持 TPM 2.0 标准，Nitro TPM 允许 EC2 实例生成、存储和使用密钥，继而支持通过 TPM 2.0 认证机制提供实例完整性的加密验证，能够有效地保护 EC2 实例，防止非法用户访问用户的个人隐私数据。
AWS EC2 的虚拟化技术演进之路
一直以来，虚拟化技术都是云计算的基石。通过虚拟化技术，将不可分割的硬件资源会抽象为可二次配置的逻辑单位，从而实现按需分配和共享现有的计算、存储和网络资源。
AWS 的虚拟化技术演进之路有一张广为人知的示意图，由 Brendan Gregg 于 2017 年所绘制，他在自己的博客中说明了 Nitro System 的来历和技术架构（https://www.brendangregg.com/blog/2017-11-29/aws-ec2-virtualization-2017.html）。
从图中我们可以看到，Brendan 把虚拟化的关键技术根据功能做了拆分并根据其重要程度进行排序，显然最重要的是 CPU 和 Memory，其次是 Network I/O，再来就是 Local Storage I/O 和 Remote Storage I/O，最后是 Motherboard（中断）和 Boot（主板）等。
Amazon EC2 实例从最早的采用了 Xen PV（Para-Virtualization，半虚拟化）到后来的 Xen HVM（Hardware-assisted virtualization，硬件辅助的全虚拟化），再逐步地加入 SR-IOV NIC 硬加速技术，并最终在 2017 年推出了软硬件融合的 Nitro System。
整个技术演进的脉络清晰明了，但我们不能停留于此，还需继续探索其背后的缘由。
Nitro Hypervisor
正如前面提到 AWS 自 2006 年成立并发布的第一个 EC2 实例类型 m1.small 采用了 Xen 虚拟化技术。首批 AWS 用户能以每小时 10 美分的价格获得一台相当于 1.7G 主频的 Intel Xeon CPU、1.75GiB Memory、160GB Disk 和 250Mb/s Bandwidth 的云主机。
Xen 虚拟化技术的诞生最早可以追溯到 1990 年，那年 Ian Pratt 和 Keir Fraser 创建了 XenServer 的初始代码工程。直到 2003 年发布了 Xen 1.0 版本，并成立 XenSource 公司。在那个 Intel 和 AMD 还没有推出 CPU 硬件虚拟化技术的年代，Xen 为了提升虚拟机的性能而选择了 PV（半虚拟化）的技术方向。
正如 Xen 之父 Ian Pratt 所言：“这个项目是由我本人和剑桥大学计算机科学实验室的一些学生共同做的。我们当时就意识到要想使得虚拟化的工作越来越好，必须需要得到硬件方面的帮助，而且要不断地改变 CPU，改变芯片组，以及改变一些 I/O 的装置，使得他们能够适应虚拟化的需要。”
在当年，以 Xen 为代表的 PV 虚拟化技术象征着能够拥有一台性能先进的虚拟机。所以很快的，基于 Xen 虚拟化技术的解决方案陆续被 RedHat、Novell 和 Sun 等的 Linux 发行版集成，作为默认的虚拟化解决方案。
- 2005 年，Xen 3.0.0 发布，该版本可以在 32 位服务器上运行，作为第一个支持 Intel VT-x 技术的 Hypervisor。从而使得 Xen 虚拟机可以运行完全没有被修改过的 GuestOS，该版本是 Xen 真正意义上可用的版本。
- 2006 年，RedHat 将 Xen 虚拟机作为企业版 RHEL 的默认特性。
- 2007 年，Novell 在推出的企业级 SLES（Suse Linux Enterprise Server）10 中添加了 Xen 虚拟化软件。
- 2007 年 6 月，RedHat 在所有平台和管理工具中包含了 Xen 虚拟化功能。
- 2007 年 10 月，Citrix 公司出资 5 亿美金收购了 XenSource，变成了 Xen 虚拟机项目的东家。之后推出了虚拟化产品 Citrix 交付中心。
而诞生于 2006 年的 AWS 自然也选择了 Xen 来作为 EC2 的虚拟化技术底层支撑，并在后来的十多年里，又陆续发布了 27 个基于 Xen 虚拟化技术的 EC2 实例。
Xen 实现了虚拟机的 CPU 和内存虚拟化，但是虚拟机的 I/O 功能，包括网络和存储等，还需要通过虚拟机中的一个 Front-end（前端模块）与 Domain 0 中的 Backend（后端模块）进行交互，并最终由 Domain 0 中的 Device drivers 实现。
这里的 Domain 0 是 Xen 的一个特权虚拟机（唯一运行在 Xen Hypervisor 之上的虚拟机），运行着被修改过的 Linux kernel，它拥有访问物理 I/O 资源的权限。Domain 0 需要在其它的业务虚拟机启动之前启动，并用于提供业务虚拟机的外设模拟仿真功能。
2013 年，AWS 采用 Xen PV 虚拟化技术的 cr1.8xlarge EC 实例的架构如下图所示。可以看见，Host（宿主机）上既要运行用户的业务虚拟机，还运行 Xen 的 Domain 0 管理虚拟机。业务虚拟机的本地存储、EBS Volume 和 VPC 网络访问都是通过 Domain 0 虚拟机来实现的。
显然，这样的 I/O 路径非常冗长，不可避免的降低了 I/O 性能，而且 Domain 0 还会和业务虚拟机抢占 Host 的 CPU/Memory/IO 资源，很难实现管理虚机和业务虚机之间的平衡，以及避免性能抖动。并且，随着业务需求的发展，对存储和网络的性能不断提出要求，这意味着 Host 需要预留更多 CPU core 来模拟这些外设，当规模大到一定程度，问题就会变得非常明显。
这些问题促使了 AWS 寻求新的方法来改进纯软件实现的虚拟机管理程序架构，探索更灵活可行的虚拟机管理手段。而探索的结果，正是 Amzon Nitro System。
Nitro System 采用了新型的 Nitro Hypervisor 来替代 AWS 早期采用的 Xen 虚拟化技术，其基于 KVM，运行于极简化定制的 Linux Kernel 中，作为一种 Lightweight Hypervisor 只负责管理 CPU 和 Memory 的分配，以及将 Nitro I/O Acceleration Cards 分配给计算实例，本身并不实现任何 I/O 虚拟化功能。因此，Nitro Hypervisor 能够具有 BareMetal-Like 的性能。
Amazon EC2 首席工程师 Anthony Liguori 表示：“Nitro 基于 Linux KVM 技术，但其本身并不包含通用型操作系统的 I/O 组件。Nitro Hypervisor 主要负责为 EC2 实例提供 CPU 与 Memory 的虚拟化隔离能力，Nitro Hypervisor 取消了主机系统的软件组件，从而为 EC2 实例提供更出色的性能一致性，同时提升宿主机可利用的计算与内存资源，使几乎所有服务器资源都可供客户直接使用。”
KVM（Kernel-based Virtual Machine，基于内核的虚拟机）于 2007 年 2 月 5 日被集成到 Linux Kernel 2.6.20 中，是现今最流行的虚拟化技术之一。KVM 的本质是一个嵌入到 Linux Kernel 中的虚拟化功能模块 kvm.ko（kvm-intel.ko/kvm-AMD.ko），该模块在利用 Linux Kernel 所提供的部分操作系统能力（e.g. 任务调度、内存管理、硬件设备交互）的基础上，再加入了 CPU 和 Memory 虚拟化的能力，使得 Linux Kernel 具备了成为 Hypervisor VMM 的条件。
KVM 最大的特点就是其本身只提供了 CPU 和 Memory 的虚拟化功能，而不能进行任何设备的模拟。所以，通常的 KVM 还必须借助于一个 VMM 来模拟出虚拟机所需要的虚拟设备（e.g. 网卡、显卡、存储控制器和硬盘），同时为 GuestOS 提供操作入口。最常见的，就是选择 QEMU（Quick Emulator）来作为补充。所以 KVM 社区在对 QEMU 进行稍加改造后，推出了 QEMU-KVM 分支发行版。
QEMU 是一款免费的、开源的、纯软件实现的、功能强大的 VMM，直至 2019 年 QEMU 4.0.0 发布并对外宣称几乎可以模拟所有的设备。但是，但由于这些模拟都是纯软件实现的，所以其性能低下。
而 Nitro System 与业界普遍采用的 QEMU-KVM 方案的最大区别之一，就是它没有使用 QEMU，而是将 QEMU 所提供的设备模拟功能 Offloading 到了 Nitro I/O Acceleration Cards 实现，进而为 Nitro EC2 实例提供了存储、网络、管理、监控以及安全能力。
但并不是说原生的 KVM 就具备了 Hardware Offloading 框架可以直接迁移，据笔者了解，里面必然会涉及到不小的适配性定制开发。所以 Nitro System 团队并没有一开始就从这方面入手，而是先陆续解决网络和存储的卸载加速之后，再来攻坚 Hypervisor 的难题。当然 AWS 最不缺的就是虚拟化领域的技术大牛，例如 James Hamilton，他是 AWS 副总裁及杰出工程师，是少有的被允许在个人博客中发表重大技术思路的工程师。在 James Hamilton 的个人博客中（https://perspectives.mvdirona.com/），我们可以翻阅大量与 Nitro System 相关的技术内幕。
回到主题，直到 2017 年 11 月，AWS 发布了 C5 实例类型，它首次使用基于 KVM 的 Nitro hypervisor 替换了 Xen。可以看见，在新的虚拟化架构中已经完全移除了 Xen Domain 0 管理虚拟机，极大的释放了 Host 资源。
另外值得注意的是，近年来尽管 IaaS 和 PaaS 等云服务已经非常完善，但在一些特定场景下（例如物理层面的完全独占隔离），用户依然对弹性裸金属云服务提出了诉求。
区别于传统的数据中心机房租赁，弹性裸金属云服务要求具备与常规云服务一般无异的敏捷开通、按需付费和成本效益特性。所以交付弹性裸金属云服务的技术困难在于：在不能够安装任何具有侵入性的云平台基础设施管理组件到裸金属服务器的前提之下，如何对裸金属服务器集群进行高效的资源池化管理？
从目前来看，只有将云平台基础设施管理组件卸载到专用硬件设备是一个较为可行的方案。在使用弹性裸金属服务的同时，还能继续使用比如 EBS、ELB 和 VPC 等基础云服务。在交付裸金属实例的过程中，以自动化的方式完成对服务器网络以及基于网络的共享存储的设置，并且支持裸金属实例的 Migration 等云主机特性。
所以，也是在 2017 年，AWS 同时发布了首个基于 Nitro System 的弹性裸金属实例类型 i3.metal。i3.metal 实例几乎没有 Host 性能开销，用户可以直接在服务器中运行任何期望的应用程序，例如：Xen、KVM、ESXi、容器、FireCracker 微虚机等等。
综上，在引入了 Nitro Hypervisor 并将更多的 I/O 外设卸载到 Nitro I/O Acceleration Cards 之后，Nitro System 重新构建了 AWS 云平台的基础设施层。将存储、网络和安全功能 Offloading 到专用的硬件所带来的最主要且直观的好处是 EC2 实例几乎可以为 GuestOS 提供 Host 所有的 CPU 和 Memory，在性能上也得到了巨大的提升（Bypass 了 Kernel 冗长的 I/O 路径），同时还能够支撑交付弹性裸金属服务。
正如 AWS 首席技术布道师 Jeff Bar 在一篇博客里写道：“有了 Nitro Hypervisior 的 EC2 实例跟裸金属服务器相比，性能只差了大约 1%，这一微小差别很难察觉出来。”
从下图的测试结果可以看出，使用了 Nitro Hypervisor 的 C5 实例相对与 i3.metal 裸金属实例只有一点极小的附加开销，而且性能非常平稳，能完全满足应用的 SLA 需求。Nitro Hypervisor 提供的虚拟化性能非常的接近裸设备。
Nitro Cards
Nitro Cards 具有以下 6 种类型，本质仍然是一张张 PCIe 外设卡，可以采用各种 Passthrough 技术接入到 Nitro 实例。Nitro Cards 作为 AWS 云平台基础设施的一部分，对用户而言是透明的。
- Nitro Controllere Card（管理）
- Nitro VPC Card（网络）
- Nitro EBS Card（远程存储）
- Nitro Instance Storage Card（本地存储）
- Nitro Security Chip Card（安全）
如此的，Nitro Hypervisor 和 Nitro Cards 的结合就能够 “组装” 出一台虚拟机所需要的所有计算机组成系统部件，将更多的服务器硬件设备资源应用于生产需求，并为客户提供更多可用计算实例类型，而不必再为一系列云平台基础设施（管理、监控、安全性、网络或存储 I/O）预留出 Host 计算资源。
Nitro Controller Card
Nitro System 作为一个系统，具有一个逻辑上集中的 Nitro Controller 作为中央管控角色。Nitro Controller Card 实现了 Accelerator Cards 协同控制能力，为每个不同类型的 Nitro EC2 实例加载相应的 Device Drivers 和 Control Plane Controllers。例如：
- 通过 Nitro VPC Card 提供 ENA Controller；
- 通过 Nitro EBS Card 提供 NVMe Controller；
- 通过 Nitro Security Chip 提供 Hardware Root Of Trust（硬件信任根），用于支持实例监控、计量和认证；
- 通过 Nitro Enclave 提供数据安全防护能力等等。
Nitro VPC Card
网络增强型的 EC2 实例是 Amazon Nitro System 技术团队最先选择的切入点，2013 年发布的 C3 首先采用了 SR-IOV Passthrough 技术。
SR-IOV（Single-Root I/O Virtualization，单根 I/O 虚拟化）是 PCI-SIG 推出的一项 PCIe 设备虚拟化技术标准，是一种基于物理硬件的虚拟化解决方案。SR-IOV 技术允许在虚拟机之间共享 PCIe 设备，同时通过 SR-IOV Passthrough 可以令 VF/PF Bypass Hypervisor 直接接入到虚拟机，有效的提高了物理 I/O 设备的性能与可扩展性。由于 SR-IOV 是基于硬件实现的，所以虚拟机获得与宿主机媲美的 I/O 性能。
如下图所示，在 Host 上增加了一块 SR-IOV NIC，EC2 实例的 VPC virtual interface 不再由 Xen Domain 0 提供，而是直接接入到 SR-IOV PF/VF。如果采用的是 Intel 82599 NIC，那么只需要在 EC2 实例中安装 ixgbe drivers，即可拥有最高 10Gbps 的网络吞吐量。
但是 SR-IOV 实际上也有着其局限性，存在 3 点主要问题：1）扩展性有限，只支持一定数量的 VFs；2）灵活性有限，不支持 Live Migration；3）计算能力有限，无法提供更多的高级网络虚拟化功能。
所以，在 SR-IOV 的理念基础上进行演进，Nitro System 团队在 2016 年发布了 ENA（Elastic Network Adapter）技术，并应用于 X1 实例类型，最大吞吐量可以到 25Gbps。ENA 正是 Nitro System 项目的一部分，基于 ENA 技术的 Nitro VPC Card 最初由以色列的 Annapurna Labs 公司开发的 ASIC 芯片加速卡支撑，是 Nitro System 第一款真正的专用硬件卡，并于 2015 年被 AWS 收购。
现在最新的 Nitro VPC Card 完全实现了 VPC Data Plane Offloading，Nitro 实例通过 ENA drivers 能够像 SR-IOV Passthrough 一般地 Bypass Kernel 直接与 Nitro VPC Card 进行数据传输，极大地提升了 I/O 效率。同时在 Nitro VPC Card 上的 ASIC 芯片还实现了多租户平台网络隔离、数据报文的封装/解封装、Security Group、QoS 和 Routing 等功能。
此外，Nitro VPC Card 还进一步实现了更丰富的网络加速特性。例如 EFA（Elastic Fabric Adapter）提供了 User Space Network Function（用户态网络功能），客户可以通过 EFA 来使用 OpenFabrics Alliance Libfabric SDK/API，如：MPI（消息传递接口）或 NCCL（NVIDIA 集体通信库）。
使用 EFA 和 Libfabric，User Space Applications 能够以 Bypass Linux Kernel 的方式进行 RDMA/RoCE 通信，与 Nitro EBS Card 提供的 NVMe-oF 能力结合，能够以更低的 CPU 使用率实现更高的性能。
另外，随着网络技术发展，从 2006 年的 1000M 时代、到 2012 的 10GB 时代、到 2016 年的 25GB 时代，再到今天的 100GB 时代。如果不能够将更广泛的网络虚拟化技术（e.g. VxLAN / GRE Overlay）卸载到专用硬件上处理，进而释放 Host CPU core，那么珍贵的 CPU core 基本无法处理除了网络流量之外的任何业务。
正如如 AWS 所介绍的：“新的 C5n EC2 实例是因为采用了第四代 Nitro VPC Card，才能够达到 100Gbps 的网络吞吐能力。”
Nitro EBS Card
存储增强型的 EC2 是 Amazon Nitro System 团队做出的第二个尝试，在 2015 年推出的 C4 实例类型引入了基于 NVMe SSD 的 EBS Volumes。
随着 AI 技术的发展步入了快车道。深度学习依赖海量的样本数据和强大的计算能力，也推动 HPC（高性能计算）的发展。高效的 AI 训练需要非常高的网络吞吐量和高速存储来处理大量的数据，大量的数据将会在计算节点、存储节点之间进行传送。
通常情况下，在低于 10% 链路带宽利用率的低负载流量环境中，突发流量引起的网络丢包率会接近 1%，而这 1% 的丢包率在 AI 运算系统中直接带来了接近 50% 算力损失。在分布式 AI 训练场景中，网络抖动和数据传输时延引起的网络重传会进一步降低网络的吞吐量，使模型训练的效率大大下降，甚至失败。
所以我们可以看见，近几年的高性能算力中心都在马不停蹄的陆续引入 RDMA/RoCE、NVMe/NVMe-oF、NVMe over RoCE 等新型技术。
在存储方面，相对于传统的 HDD（Hard Disk Drive，机械硬盘）磁盘存储介质，SSD（Solid-State Drive，固态硬盘）半导体存储介质带来了存储性能近 100 倍的提升。而基于 NVMe（Non-Volatile Memory express，非易失性内存主机控制器接口规范）标准的 SSD 能够在性能提升的同时在大幅的降低延迟。
所以在 2015 年发布了 NVMe SSD 标准之后，Nitro System 团队就立刻瞄准了这一方向。现在一块 NVMe SSD 的容量可以达到十几 TB，100 万的 IOPS 性能，同时有着微秒级的延迟。
虽然，当时出于对 NVMe 技术兼容性问题的考虑依旧保留了 Xen 虚拟化技术传统的 Forint-end/Back-end I/O 架构（直到 2017 年推出 Nitro Hypervisor 为止），但仍然按照专用硬件卸载的思路增加了一张同为 Annapurna Labs 公司开发的存储网络加速卡，它能将 Remote Storage 以 NMVe 协议呈现给 EC2 实例。
这一改进带来的好处就是进一步释放了 Host CPU core，以及实践了先进的 NVMe SSD 技术。
现在，最新的 Nitro EBS Card 可以完全实现了 EBS Data Plane Offloading，EC2 实例通过标准的 NVMe drivers 与它进行通信，并基于 NVMe-oF 协议进行数据传输，同时支持 EBS Volume Data 加密/解密、QoS、存储 I/O 加速等功能。不仅如此，Nitro EBS Cards 还在硬件层实现了 EC2 实例与存储 I/O 资源消耗之间的隔离，隔绝了不同租户之间的性能干扰。
Nitro Instance Storage Card
在到 2017 年发布的 i3 存储优化型 EC2 实例，针对性的解决了 EC2 实例本地存储的硬件加速需求。i3 实例类型基于以往的技术积累，将 SR-IOV 技术和 Local NVMe SSD drivers 进行了结合，实现了 Instance Storage Data Plane Offloading。
本地 NVMe 磁盘的性能优势毋庸赘言，在 IOPS 和延迟方面都有显著提升。结合 SR-IOV，使 NVMe SSD 直接被多个 Local EC2 实例使用。虚拟机只需要安装相应的 NVMe drivers 即可访问这些 SSD 磁盘，继而能够提供 300 万以上的 IOPS 性能。Nitro Instance Storage Card 还可以监控 Local SSD 的磨损情况。
Nitro Security Chip Card
区别于上述提到的 Nitro Cards，Nitro Security Chip Card 集成了 Nitro Security Chip，主要用于持续监控和保护 Server 的 Hardware 资源，并在每次启动 HostOS 时独立地验证 Firmware 的安全性，以确保没有任何被修改或以任何未经授权的方式更改。所以 Nitro Security Chip Card 所提供的功能并不会被 EC2 实例感知。
在生产环节中，各种设备的 Firmware 对整个系统的安全运行非常关键，为了正确管理这些 Firmware。Nitro Security Chip 一方面会追踪 Host 对各种 Firmware 的 I/O 操作，对 Firmware 的每个校验和（设备度量）都会遇存储在 Security Chip 中的验证值进行检查；另一方面还能管理这些 Firmware 的更新，这在普遍的标准服务器上是难以实现。
结尾
在云计算过去的十年里，我们发现越来越多的企业 CIO 在引入云计算服务的时候会更加理性和科学的进行成本核算，如何切实有效的交付高性价比的云服务产品比以往的任何时刻都要能够有效的构建出竞争壁垒。
令人敬佩的是，AWS 一直依赖都坚持着高性价比策略，目前统计已经连续降价了 70 多次。回顾 Nitro System 的技术演进之路，AWS 四年磨一剑的革命性技术创新来提升性价比的手段，与市场性质的价格战有着本质的不同。是一种更为朴实的、由技术革命所带来的降本和增效，无疑是其竞争壁垒中最坚实的一块砖石。
