AWS Hyperplane是AWS内部构建的网络功能虚拟化（NFV）平台，旨在支撑多个云网络服务，包括网络负载均衡器（NLB）、NAT网关、PrivateLink、Transit Gateway 等 。Hyperplane 于 2017 年在 re:Invent 大会上首次公开亮相，但早在 2015 年就已投入生产使用 。它作为 Amazon EC2 网络架构的一部分“嵌入”于底层网络中，为这些高级服务提供统一的分布式数据平面支持 。其设计目标是实现大规模、高吞吐、低延迟的网络包处理能力。例如，一个 NLB 实例可支撑每秒数百万次请求而保持极低延迟 。Hyperplane 通过提供单一静态IP（每可用区一个）来服务客户负载，实现对客户端透明的水平扩展能力 。为了避免成为系统瓶颈，Hyperplane 采用多租户共享集群架构：所有用户的实例共用一支 Hyperplane 节点池，但逻辑上又彼此隔离，呈现出类似独占设备的使用体验 。这种架构通常以单元化(cell-based)**方式跨多个可用区部署，既保证了弹性伸缩，又缩小了故障影响范围。高可靠性同样是 Hyperplane 的核心目标——系统高度冗余，默认假设节点随时可能失效并设计为持续“修复模式”运行，即不停监测和快速恢复故障** 。正因如此，当少数节点发生故障时，其余节点能够无缝接管流量，整个系统所承担的工作几乎不变，从而体现出一定的“反脆弱性” 。概括来说，Hyperplane 的架构追求在**大规模多租户环境下的稳定、弹性和高性能**：采用水平扩展的分布式节点池提供 Tb 级别的总吞吐容量，并通过冗余和容错设计来确保服务的持续可用 。
Hyperplane 将数据面（Data Plane）和控制面（Control Plane）**相分离，以提高系统可伸缩性和可靠性。这种划分类似于路由器领域的数据面/控制面分离思想：数据面由实际处理用户网络流量的分布式设备组成，控制面则负责管理配置和状态分发** 。在 Hyperplane 中，数据面是一组跨多个可用区部署的**Hyperplane节点**（本质上是高性能 EC2 实例），它们承担实际的包处理、NAT转换和负载转发等功能。控制面则是一组管理服务，负责维护所有用户的配置（如每个 NLB、NAT网关、PrivateLink端点的路由信息、规则等），并将这些配置下发同步到数据面节点 。
为避免控制面与庞大的数据面之间直接高频交互造成过载，Hyperplane 的控制面采用了一种静态稳定性（Static Stability）**策略来分发配置：以 pull 模式替代 push 模式** 。具体来说，控制面将用户配置更新集中写入 Amazon S3 上的配置文件，而不是每有改动就通过工作流推送给所有节点 。每个数据面节点则按照固定频率（每隔几秒）从 S3 拉取最新配置文件并加载，即使配置无变化也重复这一过程 。这样一来，即便某段时间有大量配置变更，节点的查询频率和处理模式也保持恒定，从而避免了峰值时期控制面推送风暴可能导致的过载 。这种**“恒定工作模式”确保了系统在任意时刻均以稳定速度执行相同的操作，消除了负载陡增时控制面、数据面的耦合振荡，提高了整体可靠性** 。从实现细节看，控制面将配置存储在分布式数据库（如 DynamoDB）中，并由后台任务汇总后写入 S3 文件 ；数据面节点定期下载S3文件并应用其中配置。由于节点始终处理最新配置，即使控制面本身发生故障，数据面也能在相当长时间内用**最后一次下发的配置独立运行**，从而具备静态稳定性和故障隔离能力 。
值得一提的是，Hyperplane 利用了 AWS Nitro 系统提供的先进网络能力来实现控制面与数据面的解耦和资源共享。Nitro 架构允许将弹性网络接口（ENI）跨账户附加到实例上，这正是 Hyperplane 将自身节点“插入”用户VPC的关键机制 。每当创建一个需要 Hyperplane 支持的资源（如NLB、NAT网关等），AWS 会在客户VPC中预置一个由服务账户拥有的 ENI，并将其附加到Hyperplane数据面实例上 。这样，该 ENI 就成为该资源在用户VPC内的锚点，承载着资源的流量出入。控制面负责在创建资源时设置好这些 ENI（包括安全组、子网等），数据面则在 ENI 附接后将其纳入自身管理范畴。AWS Nitro 系统提供了高速包处理和弹性网络适配的硬件加速能力（如专用的 Nitro Card），使 Hyperplane 节点能够以极高的包转发率处理流量，并确保跨账户 ENI 通信的安全隔离 。总之，Hyperplane 控制面通过 DynamoDB + S3 实现配置的可靠分发，数据面通过 跨账户ENI + Nitro加速 来高效接管用户流量，二者协同实现了大规模分布式网络功能的稳定运行 。
在 Hyperplane 的数据面内部，网络数据包按流（flow）进行处理，确保状态一致性和多租户隔离。对于负载均衡（如 NLB）场景，Hyperplane 需要跟踪每个 TCP/UDP 连接，以便将同一连接的所有数据包发送到正确的目标后端实例，并保证连接粘性。这要求 Hyperplane 在多节点分布式环境下实现连接状态的一致：AWS 工程团队为此设计了高效的分布式连接跟踪和一致性哈希算法，解决了在多节点间进行大规模连接管理的难题 。简而言之，当客户的一个负载均衡收到新连接时，Hyperplane 会使用哈希等策略将该流分配给某个具体的数据面节点处理，并在该节点上保存该连接的状态（如源地址、目的地址、端口等）。此后，该连接往返的所有数据包（无论入站还是出站）都会经由同一节点处理，从而保证了 NAT 转换或转发决策的一致性。这种“单流固定节点”的路由方式通过内部一致性协议或共享内存等机制实现，以避免多节点竞争处理同一流导致混乱 。AWS 相关专利（US 11115322）也描述了类似的 “有状态网络路由” 技术：拦截客户端与服务器之间的连接，将来自两端的包都定向到同一个目标网络设备处理 。这正是 Hyperplane 实现 TCP/UDP 流粘性的基础 。
对于 NAT 网关场景，数据面节点需要执行网络地址转换：将私有子网主机发出的流量源地址转换为 NAT 网关的弹性公网IP，并维护每个连接的映射表。当 Internet 返回流量时，再根据映射将目的地址翻译回原内网主机。Hyperplane 通过上述有状态路由机制保证了NAT映射的一致性：每个私网主机与外部目标的连接由某个节点专职处理并保存转换状态，回复流量会被自动导回该节点，从而正确应用NAT回写。由于 Hyperplane 在每个可用区的 NAT 网关都采用单一固定的弹性IP，而幕后实际由多台节点共同支撑，因此 AWS 会使用一种类似 Anycast 或客户端透明分流的技术，将发往该IP的流量在内部网络中分配给不同节点 。无论底层有多少节点，外部看起来 NAT 网关服务都通过一个IP对外提供，且能够水平扩展处理能力而无需更改IP 。这一模式同样应用于 NLB：NLB在每个AZ只有一个弹性网络接口及其静态IP，背后挂载了多个高性能 Hyperplane 节点，客户端始终命中静态IP，而 Hyperplane 会透明地在节点间分发负载 。
多租户隔离方面，Hyperplane 确保不同用户、不同资源的流量和状态彼此独立。虽然物理节点是共享的，但系统在软件层面对每个资源实例（每个NAT网关、每个NLB等）维护单独的路由和映射表。例如，Hyperplane 数据面会为每个 NLB 实例分配一个内部标识或独立的监听端口范围，以区分不同用户的连接，确保不会将 A 用户的流量错误地转发到 B 用户的后端 。另外，每个资源使用独立的 Hyperplane ENI 进入用户VPC，该 ENI 承载特定资源的IP和安全组配置，相当于为该资源划分出专用的网络接口上下文 。Hyperplane 节点在处理数据包时，会根据目的ENI或目标IP将其映射到对应的资源实例空间中，应用只属于该实例的NAT或转发规则。这保证了即使多个租户的流量在同一物理机器处理，也不会混淆或越权访问。
整体的数据包流程可以概括如下：当外部流量到达某服务（例如一个NLB的静态IP），首先经由 VPC Edge Router 查找路由，被引导至 Hyperplane 在该 AZ 内的 ENI；数据包进入某个 Hyperplane 节点，由其根据连接四元组确定属于哪个后端目标并转发。同时，该节点记录连接状态。当后端服务器回应时，返回包经由 VPC 路由再次到达 Hyperplane ENI，并由同一节点拦截，根据先前保存的状态将源/目的地址转换（NAT 的情形）或直接路由回客户端。整个过程中，Hyperplane 节点集群协同确保单连接单节点处理、有状态对称转发，从而实现了高性能且正确的 NAT/LB 数据面。如果某个节点故障，Hyperplane 控制面会察觉并将受影响的资源流量重新分配到其它节点，新连接会由健康节点接管。而已有故障节点上的连接可能中断，但对于许多幂等性通信，客户端重试即可由存活节点建立新连接服务。借助快速故障检测和冗余节点池，Hyperplane 最大程度减少了单点故障对用户流量的影响。
Hyperplane 的实现与底层 AWS Nitro 系统和 EC2 网络设施紧密结合。首先，每个 Hyperplane 数据面节点运行在 AWS EC2 实例之上（可能是经过优化的自有实例类型），利用 Nitro 提供的弹性裸机性能和虚拟化隔离。Nitro 架构允许 AWS 打破传统限制，实现跨账户附加 ENI这一关键能力 。例如，当用户在其VPC中创建一个 NAT Gateway 时，系统在用户VPC的选定子网中创建一个弹性网络接口（ENI），分配上私有IP和弹性IP，并跨账户附加到 AWS 管理的某台 Hyperplane 实例上 。从用户视角看，这个 ENI 就是 NAT Gateway 在该子网的“存在”，拥有自己的资源ID和安全组等；但实际上其背后挂载的是 Hyperplane 数据面。类似地，创建 NLB 时，每个可用区也会有一个 Hyperplane ENI（带有静态私有IP或弹性IP）附着到 Hyperplane 实例 。AWS Nitro 为这种 ENI 附加提供了底层支持，确保网络流量能够在用户VPC和Hyperplane实例之间高速、安全地传递。Nitro 卡承担了很多网络数据面的工作，例如包的虚拟交换、弹性队列等，使得 Hyperplane 实例无需过多占用主CPU就能处理海量流量。
与 EC2 实例的交互方面，Hyperplane 显得对用户几乎透明。客户部署在 EC2 上的应用若使用了这些网络服务（如通过 PrivateLink 访问一个 AWS托管服务，或通过 NAT网关访问公网），其数据包仍然从EC2出来后先经过VPC本地路由。如果目的地址匹配某个 Hyperplane ENI（例如属于 NAT Gateway 或 Interface Endpoint），Nitro/Ethernet层会将包直接送达附在该 ENI 上的 Hyperplane 实例，而不是发往某台客户实例 。由于 Hyperplane ENI 就在用户的二层网络中，数据包通过 AWS 内部网络即可抵达对应的 Hyperplane 节点，无需离开AWS物理基础设施。这种设计下，用户EC2实例无需感知 Hyperplane 的存在——它们只与 ENI 的 IP 通信，就如同与本地网关通信一般。但在幕后，EC2 实例的流量被 Nitro 系统重定向给了Hyperplane数据面进行处理。完成如地址转换、服务发现等功能后，再由 Hyperplane 将数据送至下一跳（可能是另一个VPC的ENI、AWS服务入口或Internet网关等）。举例来说，在 Lambda 函数通过 Hyperplane ENI 访问私有VPC资源的场景中，Lambda 执行环境位于服务VPC，通过 Hyperplane 隧道与客户VPC内的 ENI 建立通信 。整个过程利用 Nitro 的弹性网络能力，让多个 Lambda 执行环境共享少量 Hyperplane ENI 即可并发访问 VPC，显著降低了传统模式下每个函数创建ENI所带来的开销 。
综上，AWS Nitro 系统提供的高速网络I/O和安全隔离是 Hyperplane 实现的基石：Hyperplane 利用 Nitro 的硬件加速和轻量虚拟化，将自己的节点嵌入到用户的虚拟网络中，既保证了数据转发效率，又确保了与用户实例间的安全隔离。在用户看来，Hyperplane 只是以 ENI 形式存在的一种黑盒网络设备；而在 AWS 平台内部，它通过 Nitro 与 EC2 紧密协作，实现了云上前所未有的灵活网络功能即服务能力。
Network Load Balancer 是 Hyperplane 最早支持的服务之一。NLB 工作在OSI第四层，提供高吞吐、低延迟的流量分发能力，能够处理数百万TPS的连接请求。Hyperplane 为 NLB 提供了核心的数据转发平面：当用户创建一个 NLB 时，每个启用的可用区会分配一个由 Hyperplane 托管的弹性网络接口（拥有一个静态IP地址） 。所有发往该静态IP的流量会进入 Hyperplane 网络平面，由其在幕后路由到负载均衡器实际的后端目标。由于每个可用区的 NLB 节点只有一个固定IP，Hyperplane 必须在不改变客户端连接IP的情况下实现水平扩展。它通过将该 IP 映射到多个高性能节点实例来实现：对客户端而言，NLB 在一个AZ始终只有一个目标IP；但在 AWS 内部，多个 Hyperplane 节点共同对外服务这个 IP，客户端连接会被均衡地分布到这些节点上处理 。这一设计的直接好处是静态IP负载均衡：无论流量增长到多大，都无需在DNS中添加更多IP，NLB的IP不变，而 Hyperplane 可以动态增加节点来承载更多流量。NLB 因此非常适合需要硬编码IP或要求IP不变的场景 。
Hyperplane 赋予 NLB 卓越的可扩展性和性能。在流量模式变化时，Hyperplane 节点池能够快速弹性伸缩：NLB默认起步就有约 3 Gbps 的容量，并可根据需要每分钟增加 3 Gbps 吞吐 。这种弹性扩容完全由 Hyperplane 在后台完成，对用户透明且无需干预。此外，由于 Hyperplane 采用分布式设计，NLB 天然具备多可用区冗余。每个AZ的 Hyperplane ENI和节点集群相互独立，某一AZ故障并不影响其他AZ的NLB节点，确保负载均衡服务的高可用。Hyperplane 对连接的高效跟踪也使 NLB 能够稳定处理长连接和高并发。正如之前提及的，Hyperplane 使用一致性哈希等算法保证每条连接始终由同一节点处理 。这意味着即使 NLB 在内部是由许多节点支撑，也不会出现连接在节点间来回漂移的问题，保证了会话的一致性和高效性。Amazon Builders’ Library 专文指出，NLB 的实现正是建立在 Hyperplane 之上，Hyperplane 通过每秒轮询 S3 上的配置来获取最新的目标实例列表，实现了毫秒级别的配置同步和恒定性能 。同时，Hyperplane 多租户隔离的特点也应用于 NLB：每个 NLB 实例的流量在节点处理时都有独立的上下文，不同用户的NLB互不干扰 。
综上，借助 Hyperplane，NLB 实现了传统硬件负载均衡器难以企及的大规模弹性和高可用性。它能够在不更换IP的情况下自动扩展容量，在瞬息万变的流量条件下保持低延迟 。Hyperplane 的分布式冗余让 NLB 没有单一故障点：任一节点故障时，新连接会自动由集群中其它节点接管，已有连接的中断也能通过客户端重连很快恢复。可以说，Hyperplane 是 NLB 背后的“隐形引擎”，使得用户无需操心容量或可靠性问题，NLB 就能“开箱即用”地扩展到所需的规模 。
图 1：Hyperplane 在 AWS 内部实现 VPC 间的负载均衡/NAT 功能示意（以 Lambda 函数访问用户VPC资源为例）。左侧Lambda所属的AWS服务VPC通过Hyperplane隧道将流量传送到右侧客户VPC的Hyperplane ENI，再由Hyperplane节点进行NAT转换和路由，实现跨VPC的高速互通 。同理，NLB/NAT 网关等也是通过在每个VPC的每个AZ挂载一个Hyperplane ENI，由Hyperplane节点池承担实际数据转发来运作的。该机制保证了单一IP对外、幕后水平扩展和多租户隔离。
AWS PrivateLink 提供了一种在私有网络中访问 AWS托管服务或第三方服务的机制，使流量不经过公网即可在消费者VPC与服务提供方之间传输。Hyperplane 是实现 PrivateLink 的关键支撑技术：它扮演了 PrivateLink “底层载体”的角色。具体而言，当用户在其VPC中创建一个接口端点（Interface Endpoint）**来访问某AWS服务时，系统会在用户VPC里生成一个由 Hyperplane 托管的 ENI（它有一个来自该VPC子网的私有IP，通常还会在Route 53解析出对应的服务私有域名）。当用户的EC2实例向这个 AWS 服务的私有域名发起请求时，请求报文的目的IP即是上述 ENI 的私有地址，报文通过VPC子网路由直接来到 Hyperplane ENI。此时，Hyperplane 数据面发挥作用：它将用户报文封装后通过AWS内部网络转发给目标服务。AWS官方专利（US 11792041）详细描述了这一流程：Hyperplane 充当隧道中介，将用户VPC发出的原始数据包（目的地址是服务的公网IP，源是客户实例私有IP）进行封装，添加一个标识源VPC的头部，然后将封装包发送到服务端所在的节点处理** 。服务端（可能是AWS自身的服务入口，或对方VPC的NLB）收到并解封后，就能获取到原始请求并进行响应。响应报文再经由Hyperplane反向封装，送回客户VPC的接口端点ENI。这种机制实现了客户VPC与服务之间的**私有链接**：对用户而言，访问服务就像访问本地IP一样，而实际流量在 Hyperplane 的隧道中穿行，未经过Internet 。
借助 Hyperplane，PrivateLink 可以同时服务于众多租户和服务。每个客户VPC针对每个目标服务都会有独立的接口ENI和私有IP，Hyperplane 利用封装头中的 VPC标识和目的服务信息来区分不同客户/不同服务的流量 。因此，哪怕许多客户都访问同一AWS服务，流量在Hyperplane内部依然能够被正确隔离路由，不会混淆或越权。Hyperplane 的高带宽能力也保证了 PrivateLink 通道的性能：因为数据不绕经公网，而是走AWS内网，延迟和吞吐都很优良。此外，Hyperplane 提供的冗余让 PrivateLink 通常具有接近于底层网络的可用性——其 ENI 和节点在每个AZ都是冗余的，服务提供方那边也往往有NLB的冗余。因此，整个PrivateLink通信路径没有明显的单点故障。以访问 S3 接口端点为例，用户请求通过Hyperplane在AWS网络骨干上路由到S3服务的一组弹性网卡上（S3 每个AZ都有Hyperplane支持的服务网卡用于接收 PrivateLink 流量），确保即使S3某单台设备故障，其他设备也能及时接管。在私有链接建立过程中，Hyperplane 控制面和数据面协同还要完成服务发现和连接初始化：比如当接口端点建立时，会在Hyperplane系统中注册对应需要连接的服务目标。随后数据面才能识别封装包该送往哪。AWS Builders’ Library 中提到，Hyperplane 最初尝试过用事件驱动的方式将配置下发给节点处理PrivateLink等配置，但后来改为所有节点定期从S3拉取更新配置 。这也意味着，当用户创建或修改接口端点时，Hyperplane 控制面会将该变化写入配置文件，几秒钟内所有节点就会知道新的服务映射，从而可以开始转发流量 。通过这种方式，PrivateLink 可以在用户发起创建后非常快地生效，且后续配置变化也能一致传播。总的来说，Hyperplane 为 PrivateLink 提供了可靠的承载网络：它让私有连接无需客户操心底层隧道如何建立、维护，AWS 负责在Hyperplane层实现高扩展、透明的隧道路由。从网络角度看，Hyperplane 扮演了大规模多租户 VXLAN/Geneve 网关的角色，只不过其智能和能力远超传统网关，能够自动适应云环境的规模和动态变化。PrivateLink 因此成为跨VPC、跨账户访问服务的利器，而这背后正是 Hyperplane 技术的灵活运用。
Hyperplane 的通用网络虚拟化能力也被进一步应用在其它高级网络服务中，其中包括 AWS Transit Gateway (TGW) 和 Amazon VPC Lattice 等。Transit Gateway 是 2018 年推出的云中枢路由服务，允许在一个集中网关上实现多达成千上万个 VPC、本地VPN连接的互连。根据 AWS 介绍，Transit Gateway 完全构建在 Hyperplane 之上 。具体而言，每个 Transit Gateway 在区域内实际上由一组 Hyperplane 节点组成，这些节点类似一个高可用路由集群。每当有 VPC 或VPN附件接入 TGW，AWS 就会在该附件所在AZ将流量引导至 Hyperplane 节点进行转发。Transit Gateway 的路由表由控制面管理，但数据转发（包括封装/解封、路由查找）全部由 Hyperplane 数据面线速完成。这使 TGW 具备了惊人的扩展性：官方数据显示，每个 TGW 可支持高达 5000 个 VPC 连接和 10000 条路由 ；带宽方面，每个连接（例如 VPC 附件）可以使用高达 50 Gbps 的吞吐 。这些大规模能力的实现正是因为底层有 Hyperplane 提供弹性扩容。一方面，Hyperplane 节点可以根据流量自动增加，确保即使许多 VPC 同时大量通信，网关也不成为瓶颈；另一方面，Hyperplane 天生的多AZ冗余让 TGW 实现了高可用设计——每个连接可以跨多个AZ冗余通信路径。当某AZ的节点故障或网络不通时，TGW 会自动切换路径而用户无感知。值得注意的是，Transit Gateway 内部流量通常采用封装传输（类似第三层的GRE或VXLAN隧道），以在隔离不同VPC地址空间的同时实现转发。Hyperplane 节点负责对报文加解封装并查找下一跳路由，这与前述 PrivateLink 的封装思路如出一辙 。AWS一项专利（US 11770364）描述了“虚拟网络环境中的私网对等连接”方案，提到通过一个中心服务动态建立跨客户私有网络的端口和隧道，并进行路由信息交换 ——这正是 Transit Gateway 的工作原理摘要。这进一步印证了 Hyperplane 在 TGW 中的作用：Hyperplane 提供了一个可编程的分布式路由器平台，AWS 基于它实现了TGW丰富的路由和隔离特性。
Amazon VPC Lattice 是最近推出的新服务，定位于在应用层实现跨VPC、跨账户的服务间通信和发现。Lattice 提供了类似服务网格的功能，例如服务命名、流量路由、请求级别负载均衡和鉴权等，但却不要求用户部署传统服务网格代理。虽然 Lattice 的很多高级功能作用于应用七层，但它底层的跨网络流量转发依然离不开 Hyperplane。可以认为，Lattice 在许多方面融合了 PrivateLink 和内部负载均衡的技术：当一个客户端需要调用另一个VPC里的服务时，Lattice 会为这次调用在客户端VPC和服务VPC之间建立一条Hyperplane支持的路径。实际上，每个加入 Lattice 服务网络的VPC都会有一些隐含的 Hyperplane 组件：例如，一个所谓的 “目标导向器” 或 “服务入口” 将由 Hyperplane ENI 来承载，从而接受来自其他VPC的调用流量。由于 Lattice 允许不同账户的VPC无缝互通，它需要底层网络具有多租户隔离和大规模转发能力，这正是 Hyperplane 的强项。可以推测，当客户端向某个 Lattice 服务发起请求时，这请求可能被解析到本地的一个 Hyperplane ENI（类似 PrivateLink 接口端点的作用），然后 Hyperplane 将该请求封装并传输到目标服务所在VPC的 Hyperplane 节点，最后交付给服务实例。如果服务需要响应，同样路径返回。整个过程中，Lattice 会在应用层做一些策略控制（如流量分割、鉴权），但实际数据搬运仍由 Hyperplane 来完成。凭借 Hyperplane，Lattice 可以避免让用户自行配置复杂的VPC Peering或Service Mesh，大幅简化架构。尤其在大规模微服务场景下，使用 Lattice 意味着开发者不用关心网络细节，服务间通信的可靠性和吞吐由 AWS 的 Hyperplane 平台保证。Lattice 目前还处于推广初期，但从其设计初衷来看，很大程度上延续了 Hyperplane 平台的理念：即由 AWS 提供一个托管的、高度弹性的网络数据平面，让用户关注更高层的应用配置。这种理念下，无论是 Lattice 还是 TGW、PrivateLink，其底层实现都有异曲同工之妙。Hyperplane 在这些服务中所做的，都是将底层网络连接虚拟化、服务化：以软件定义的方式提供路由、交换、NAT、负载均衡等功能，并通过 AWS 的规模优势实现高性能和高可用。
综合上述场景可以看到，Hyperplane 技术大幅提升了 AWS 网络服务的高可用性、可扩展性和性能指标：
综上所述，AWS Hyperplane 通过创新的架构和实现，成为支撑 AWS 云上网络服务的“幕后英雄”。它像操作系统之于计算资源一样管理着网络资源，为负载均衡、NAT、私网连接等提供了统一的高可靠、高性能抽象。对用户而言，Hyperplane 是隐形的 —— 用户只看到稳定强大的云服务；但正是因为有 Hyperplane 的加持，这些云网络服务才能在大规模云环境下如同本地设备般运作，却又具有本地设备无法实现的弹性和易用性。
AWS 在开发 Hyperplane 技术过程中也申请了多项专利，公开了一些底层实现思路。以下选取几份与 Hyperplane 密切相关的专利，介绍其核心原理及其与 Hyperplane 系统的关系：
综上，这些专利涵盖了 Hyperplane 平台的诸多关键技术要点：有状态分布式转发、隧道封装、多租户路由集成以及跨网互联。它们共同支撑了 Hyperplane 的实现，使其成为 AWS 云中功能强大又稳定可靠的网络“大脑”。通过研读这些专利，我们可以更深入地理解 Hyperplane 在幕后所做的工作，以及 AWS 是如何通过创新来突破传统网络功能的限制，在云中打造如此大规模的虚拟网络设备。这些技术不仅确保了 AWS 当前网络服务的领先地位，也为未来更复杂的云联网服务打下了坚实基础。
参考资料：