在亚马逊云上设计架构良好的网络

在亚马逊云上设计架构良好的网络

关键字: [Amazon Web Services re:Invent 2024， 亚马逊云科技， Well-Architected Networks， Network Design， Vpc Connectivity， Traffic Inspection， Dns Configuration]

导读

通过学习如何在亚马逊云科技上设计架构良好的网络来提升您的亚马逊云科技网络专业知识。本课程首先讨论多可用区和多区域架构的权衡，以及如何构建Amazon虚拟私有云（VPC）。接下来，探讨连接多个VPC和本地数据中心时的设计挑战，随后讨论如何在亚马逊云科技上构建可扩展的DNS基础设施。最后，我们将考虑亚马逊云科技上的几种常见网络架构模式，如应用程序入口和出口。学完后，您将具备在亚马逊云科技上创建弹性、安全和可扩展网络基础设施所需的洞察力。

演讲精华

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

本次会议由Dmitri开场，他阐明亚马逊云科技的全球基础设施包括超过30个互连区域，每个区域至少包含3个可用区(AZ)。他强调，每个可用区至少有一个数据中心，这些数据中心的位置经过精心设计，能够实现低延迟的同步数据复制，并通过防止多个可用区同时受到影响来确保抗灾能力，从而避免因断电或自然灾害而导致的中断。

Dmitri解释说，Amazon Virtual Private Cloud (VPC)是亚马逊云科技上的主要网络构造，代表区域级别的隔离网络段。他表示，一个或多个IPv4或IPv6 CIDR块可以分配给一个VPC。他解释说，子网是可用区级别的构造，支持双栈子网(同时支持IPv4和IPv6)以及单栈子网(专用于其中一种协议)。

Dmitri的猫咪伙伴Well-Architected Cat首次亮相，提出了几点明智的建议:采用双栈方法，尽量减少跨可用区通信以降低延迟、成本和风险，在多账户设置中，使用可用区ID(例如us-east-1a、1b、1c)而不是可用区名称，因为后者在不同账户之间可能会有所不同。

在阐述VPC的互联网访问时，Dmitri解释说，Internet Gateway (IGW)构造可以实现与互联网之间的IPv4和IPv6通信。如果子网有指向IGW的默认路由，则该子网被视为公共子网。对于IPv6，无需额外配置，具有IPv6地址的实例可以通过IGW进行通信。但对于IPv4，需要一个弹性IP地址，使IGW能够执行从私有IPv4地址到公共弹性IP地址的源网络地址转换(SNAT)。

为了实现出站互联网连接，同时限制来自互联网的入站连接，Dmitri介绍了IPv4的私有子网概念。在这种情况下，NAT网关部署在公共子网中，为私有子网中的资源提供出站互联网访问。

Well-Architected Cat再次出现，提供了更多见解，建议在每个可用区部署NAT网关，尽可能使用私有子网并将大部分资源放置在其中，仅将公共子网用于面向互联网的负载均衡器或NAT网关，并利用VPC Block Public Access来提高合规性。

针对VPC内的IPv6主机需要与互联网上的IPv4主机通信的场景，Dmitri介绍了DNS64和NAT64机制。通过在子网级别启用DNS64，来自Route 53 Resolver的DNS解析将返回一个特殊的DNS64 IPv6地址，其中编码了IPv4地址。添加一条指向NAT网关的额外路由，用于这种特殊的DNS64流量，可以将IP地址转换回IPv4，从而实现VPC内IPv6主机与互联网上IPv4主机之间的连接。

Dmitri强调，为负载均衡器上的应用程序配置适当的健康检查非常重要，以准确评估其健康状况。此外，Route 53还会对负载均衡器节点本身执行健康检查，从而可以将不健康的节点从DNS解析中移除。

Dmitri赞扬了Amazon Application Recovery Controller (ARC)的优点，称其为亚马逊云科技上他最喜欢的网络功能。当检测到某个可用区的延迟升高或错误率增加时，ARC可以启动区域转移，将受影响的负载均衡器节点从DNS中移除，使该可用区暂时停止服务。Well-Architected Cat建议预先配置足够的容量，以应对区域转移期间的流量高峰，并定期测试此功能。

Dmitri还强调了亚马逊云科技最近支持的Zonal Auto Shift功能，使亚马逊云科技能够自动启动区域转移，以及新推出的ARC External Shift，适用于启用了跨区域负载均衡的Application Load Balancer (ALB)和Network Load Balancer (NLB)。

接下来，Andrew Gray这位首席解决方案架构师上台，阐述了在亚马逊云科技上连接VPC的各种方法。他首先介绍了VPC Subnet Sharing，这是一种允许中央网络团队在不同账户中设置和控制子网方面的构造，并授予其他账户在这些共享子网中部署资源的权限。但是，他警告说，这种方法会损害一些VPC隔离能力，并且需要确保在共享子网中部署的所有资源都受到亚马逊云科技服务的支持。

然后，Andrew讨论了VPC Peering，它建立了两个VPC之间的连接，实际上将它们绑定在一起。虽然在某些场景中很有用，但他指出了一些限制，例如每个VPC最多125个对等连接，以及对于对等VPC组大小的额外限制。VPC Peering建议用于需要最高带宽或最低延迟的场景，但牺牲了集中检查或防火墙等功能。

接下来，Andrew介绍了Transit Gateway，这是亚马逊云科技的云原生、高度冗余和可扩展的云路由器。Well-Architected Cat建议在每个VPC中的专用子网中部署Transit Gateway附件，并确保在所使用的每个可用区中都有附件，以避免跨可用区通信问题。

Cloud WAN是一项相对较新的服务，是Andrew接下来讨论的主题。他将Cloud WAN描述为多Transit Gateway场景的继任者，能够通过代码定义网络策略和段交互，实现自动化。Cloud WAN支持用于北南向(互联网)和东西向(VPC到VPC)流量检查的检查段，甚至可以跨多个区域。此外，亚马逊云科技最近宣布直接支持将Direct Connect连接到Cloud WAN，从而无需Transit Gateway作为中介。

Andrew接着介绍了另一项亚马逊云科技的新产品VPC Lattice。VPC Lattice允许客户端和服务器相互注册和认证，从而实现通信而无需额外的网络构造(如Transit Gateway)。Lattice非常适合HTTP、HTTPS和gRPC应用程序，现在还支持Service Network Endpoints，用于访问VPC Lattice网络的外部访问。

Andrew最后讨论了VPC Endpoints，它们可以实现与亚马逊云科技服务或其他VPC的直接连接，包括Interface Endpoints、Gateway Endpoints(用于S3和DynamoDB)以及新推出的Resource Endpoints(用于直接访问IP、DNS名称或RDS实例，无需负载均衡器)。

Dmitri接着继续演讲，深入探讨了亚马逊云科技上的域名系统(DNS)。他解释说，VPC内的实例默认使用Route 53 Resolver，这是一个高度可用和可扩展的DNS解析器，可通过VPC端点IP地址访问。要解析内部域名，可以创建私有托管区域并将其与VPC关联，使Route 53 Resolver能够从这些区域解析记录。

对于混合DNS解析(涉及本地或第三方DNS服务器)，Dmitri介绍了出站Route 53 Resolver端点和相关的解析器规则。这些规则指定了DNS查询应该转发到指定DNS服务器的域，从而实现跨IPv4和IPv6地址的混合解析。

要从本地DNS服务器反向解析到亚马逊云科技上的私有托管区域，可以使用入站解析器端点，并在DNS服务器上进行适当配置，将查询转发到亚马逊云科技。

Dmitri警告了一些反模式，例如使用DHCP选项覆盖默认DNS服务器，这可能导致跨可用区流量、延迟增加、风险和成本增加。他强烈建议使用默认的VPC和Route 53 Resolver配置。

另一个反模式是将DNS流量从共享服务VPC的出站解析器端点发送到入站解析器端点，这将导致跨可用区流量，并且所有经过解析器端点的DNS查询都会产生额外成本。

为了在整个组织和VPC中保持一致的DNS配置，Dmitri介绍了Amazon Route 53 Profiles。这些配置文件将私有托管区域、解析器规则、查询日志和DNS防火墙捆绑在一起，可以与组织中的每个VPC关联，确保任何更改都能一致传播。

Dmitri对DNS的关键建议包括:避免覆盖默认DNS服务器，利用解析器端点实现混合DNS解析并配置特定域的规则，以及利用Route 53 Profiles来维护一致的DNS配置。

转移到亚马逊云科技上的网络安全主题，Dmitri倡导采用分层方法。在VPC内部，可以使用安全组(分布式有状态防火墙，存在于大多数网络接口上)和网络ACL(子网之间的无状态防火墙)。他建议尽量减少使用网络ACL，因为它们的管理复杂且存在限制，而是广泛利用安全组。

在VPC边界，Dmitri介绍了添加额外防火墙的选项，可以是亚马逊云科技管理的Amazon Network Firewall，也可以是使用Gateway Load Balancer和Gateway Load Balancer端点部署的第三方防火墙。

对于Web应用程序，Dmitri建议使用Web Application Firewall (WAF)来防护常见的Web漏洞，如OWASP Top 10，并启用速率限制规则。他还提到了Amazon Shield的标准版和高级版，用于DDoS缓解。

为了在整个组织中管理安全配置，包括安全组、网络ACL、WAF Web ACL和网络防火墙策略，Dmitri强调使用Amazon Firewall Manager。

Dmitri专注于安全组交叉引用这一强大功能。他举例说明了一个三层应用程序，其中负载均衡器、应用程序实例和数据库层使用了独立的安全组。通过交叉引用这些安全组而不是使用IP地址，管理员无需在动态添加或删除实例或负载均衡器节点时更新安全组规则，从而简化了管理。

Dmitri还指出最近支持跨Transit Gateway的安全组交叉引用，进一步提高了其可扩展性。

转而讨论流量检查模式，Dmitri概述了典型的使用场景:VPC到VPC(东西向)检查、出口过滤和入口过滤。

对于东西向检查，Dmitri强调要考虑所需的安全结果和实际部署的配置，因为可能存在加密流量和动态IP地址。他建议在某些情况下评估安全组交叉引用和零信任方法，作为防火墙的替代或补充。

关于出口过滤，Dmitri强调需要考虑IPv4网络地址转换(NAT)和出口域过滤。NAT网关和亚马逊云科技网络防火墙等服务可以提供帮助，但这些组件的放置位置需要仔细考虑。

Dmitri介绍了两种出口过滤模型:集中式出口和分布式出口。在集中式出口模型中，专用出口VPC托管防火墙端点和NAT网关，通过Transit Gateway连接到其他VPC。虽然易于设置和管理，但这种方法会产生额外的Transit Gateway数据处理费用，并需要代理或NAT66解决方案来支持IPv6。

分布式出口模型则在每个工作负载VPC中部署防火墙端点和NAT网关，实现独立扩展并将影响范围限制在单个VPC内。这种方法对IPv6是原生支持的，但由于需要更多的防火墙端点和NAT网关，因此成本更高。

Dmitri认为入口过滤(管理从互联网安全访问应用程序)是最具争议的话题之一。

集中式入口模式涉及专用入口VPC托管防火墙、面向互联网的负载均衡器，以及可能的Web应用程序防火墙(WAF)。该入口VPC通过Transit Gateway或私有链路与工作负载VPC通信。虽然类似于传统数据中心DMZ方法并支持集中公共证书管理，但Dmitri指出了几个缺点:应用程序需求不同的应用程序被合并、可能需要进行TLS解密和重新加密以进行检查、工作负载VPC中需要额外的负载均衡器以支持自动扩展，且总体成本较高。

作为替代方案，Dmitri倡导分布式入口模式，其中每个工作负载VPC都有面向互联网的负载均衡器、WAF、额外的防火墙以提供分层保护、用于缓存和边缘保护的CloudFront，以及用于DDoS缓解的Amazon Shield。这种经济高效的方法将特定于应用程序的配置保持在一起，限制了错误配置的影响范围，并根据需要利用WAF、防火墙、CloudFront和Shield。但是，需要自动化来满足跨多个账户和VPC的合规性和治理要求。

Dmitri建议同时采用集中式和分布式出口方法，但对于IPv6，分布式出口更可取，以避免使用代理或NAT66解决方案。对于入口，他强烈推荐分布式方法，根据需要使用WAF、亚马逊云科技网络防火墙、CloudFront和Shield。

Radek Voornam是Harmo公司平台架构工程总监，他分享了ARM在亚马逊云科技上的网络之旅。一开始，ARM就认识到需要一个多区域、多账户的环境，并使用区域Transit Gateway构建了完全网状的骨干网络，确保了区域之间的最短路径。

随着ARM将更多工作负载迁移到云端，出现了对本地数据中心的依赖，促使他们通过多个终止在区域Transit Gateway中的站点到站点VPN建立了安全连接。然而，这在ARM的网络团队和云团队之间划分职责方面带来了挑战。

为解决这一问题，ARM将本地设备虚拟化并部署在云中，在这些虚拟设备与数据中心之间以及虚拟设备与Transit Gateway之间建立了站点到站点VPN。虽然可行，但这种方法在虚拟设备上引入了性能问题，需要一种解决方案来替换这两组VPN。

第一组VPN被Transit Gateway连接附件所取代，而第二组VPN最初被直接连接取代，用于数据传输。一年之内，ARM通过利用直接连接作为SD-WAN解决方案的基础进行了改进，该解决方案由合作伙伴提供。

解决了本地连接问题后，ARM将重点转移到其亚马逊云科技环境，并开始采用Cloud WAN，这是多Transit Gateway场景的自然继承者。Cloud WAN通过代码实现网络塑形，促进了自动化，ARM发现这一点非常有用。

Radek随后深入探讨了ARM的IPv4和IPv6地址规划。最初，对于IPv4，ARM的目标是在四个主要区域内运营，能够在每个区域内寻址超过100个VPC，同时在可用区之间保持高可用性。他们选择了一个/15 CIDR块，为每个区域分配四个/17块，进一步将每个/17划分为每个可用区-VPC 128个/24块，最后将每个/24划分为每个可用区两个/25块。

两年后，ARM对IPv6的需求发生了显著变化。他们现在瞄准16个区域，能够容纳4，000个VPC，并能够消耗每个区域内的所有可用区。因此，ARM从/42专门用于亚马逊云科技的块中获取了一个/25 IPv6块，将其切分为每个区域16个/36块。每个/36块进一步划分为每个账户4，000个/48块，每个/48块产生每个VPC 200个/56块，每个/56块提供每个子网200个/64块。

Radek强调，虽然IP寻址是一个方面，但ARM客户、合作伙伴和工程师使用的账户形状也是一个关键考虑因素。尽管每个项目都有独特的网络需求，但ARM开发了三种账户模式或“风格”，提供可重用的模板并满足运营需求。

第一种模式是来自ARM的完全可路由VPC，这是一种相对简单的配置。第二种模式涉及部分可路由VPC，具有两个播种器:一个来自ARM的小型完全可路由播种器和一个受亚马逊云科技配额限制的较大VPC范围播种器。这种模式适用于需要数千个网络接口的高性能计算工作负载。

第三种也是最有趣的模式，与ARM网络团队的设置类似。它包括一个专用于区域Transit Gateway的/17块，从中分配了一个/20块给项目Transit Gateway，允许项目团队根据需要进一步细分IP空间。这种模式包含两个账户:一个使用/20块的大型VPC，另一个使用三个/24块的VPC。此外，还有一个使用不同IP寻址方案的第三个账户，通过VPC对等连接进行对等。

认识到混合DNS的重要性，ARM遵循亚马逊云科技最佳实践，实施了入站和出站解析器端点以及Route 53规则。但ARM更进一步，允许用户根据需求塑造DNS。每当创建新的辐射账户时，所有Route 53规则都会与该账户共享。在每个账户内部，亚马逊云科技服务目录产品允许创建私有托管区域，这些区域会自动与中心账户关联，确保所有域(包括新创建的域)在所有辐射、亚马逊云科技和ARM的数据中心之间都可解析。

Radek还分享了ARM为满足特定需求而开发的自动化示例，这些需求无法直接由亚马逊云科技服务覆盖。在一个用例中，EC2实例需要在被销毁后保留其MAC地址。ARM的解决方案是创建一个独立的接口，该接口将自动与EC2实例分离和重新附加，利用自动扩展组实现自我修复功能，使用Lambda函数进行接口附加，并使用CodeDeploy进行软件部署。Radek强调，ARM的架构之旅是由明确的愿景、明确的计划和果断的决策所驱动的，呼应了古希腊哲学家伯里克利的话:“大成就需要大志向。”

Andrew Gray随后总结了作为亚马逊云科技网络架构师思考的关键原则。他强调了规划账户结构、VPC大小、IP寻址和跨VPC连接的重要性。他建议从业务需求出发，考虑安全性、合规性、成本和运营需求，并利用亚马逊云科技服务和合作伙伴解决方案来满足这些需求。他还强调了自动化和基础设施即代码的重要性，以实现一致性、可重复性和可审计性。

Andrew Gray强调了规划账户结构、VPC规模、IP寻址和跨VPC连接服务的重要性，确保它们不仅适合当前需求，而且能够满足未来增长。他以ARM的经历为例，说明需求可能会快速发展，需要有重新思考和相应调整计划的意愿。例如，ARM最初计划使用IPv4，目标是在4个主要区域内存在，每个区域超过100个VPC，跨2个可用区。他们选择了一个/15 CIDR块，为每个区域分配四个/17块，进一步将每个/17细分为每个AZ-VPC 128个/24块，最后将每个/24分为每个AZ两个/25块。然而，两年后，他们的IPv6需求发生了重大变化，目标是16个区域、4，000个VPC，并能够在每个区域内使用所有可用区。这导致他们从专门为亚马逊云科技分配的/42中获取一个/25 IPv6块，将其切分为每个区域16个/36块，进一步将每个/36划分为每个账户4，000个/48块，每个/48产生每个VPC 200个/56块，每个/56提供每个子网200个/64块。

Andrew建议尽可能避免IP地址重叠，并指出IPv6极大地简化了这一任务。他鼓励利用亚马逊云科技的工具，如基础设施性能工具，在设计多区域部署时了解并规划区域和可用区之间的延迟。

对于跨VPC连接，Andrew推荐Transit Gateway和Cloud WAN作为处理大部分连接需求的常见选择，同时保留私有链路、Lattice和Resource Endpoints等服务来解决特定的棘手问题。Well-Architected Cat建议在每个VPC中的专用子网内部署Transit Gateway附件，并确保在所使用的每个可用区中都存在附件，以避免跨可用区通信问题。

关于与本地数据中心的连接，Andrew强调明确定义并围绕期望进行设计的重要性，无论是由SLA要求、位置考虑还是其他因素驱动。他建议不要盲目追求最大的SLA，而是鼓励采取量身定制的周到方法来满足特定需求。例如，他提到亚马逊云科技提供了三个级别的Direct Connect弹性:开发和测试(单连接、单位置)、高(两个位置、每个方向单链路)和最大(多个位置、多个链路)，以满足不同的SLA需求。

在DNS领域，Andrew倡导使用Route 53 Resolver和VPC Resolver，利用Route 53 Profiles确保整个组织部署的一致性。他强调一致性的价值在于避免操作上的麻烦和混乱。

在安全方面，Andrew警告不要采用一刀切的方法，强调在规划安全策略之前需要了解具体的安全目标。他建议评估Dmitri提出的各种流量检查模式，并根据个人需求考虑集中式与分布式方法，用于出口和入口过滤。

Dmitri介绍了两种出口过滤模型:集中式出口和分布式出口。在集中式出口模型中，专用的出口VPC托管防火墙端点和NAT网关，通过Transit Gateway与其他VPC相连。虽然易于设置和管理，但这种方法会产生额外的Transit Gateway数据处理费用，并需要代理或NAT66解决方案来支持IPv6。分布式出口模型则涉及在每个工作负载VPC中部署防火墙端点和NAT网关，实现独立扩展并将影响范围限制在单个VPC内。这种方法对IPv6是原生的，但由于需要更多的防火墙端点和NAT网关，因此成本更高。

对于入口过滤，Dmitri强调了集中式入口模式，涉及专用的入口VPC托管防火墙、面向互联网的负载均衡器，以及可能的Web应用程序防火墙(WAF)。该入口VPC与工作负载VPC之间通过Transit Gateway或私有链路进行通信。虽然类似于本地DMZ方法并支持集中公共证书管理，但他指出了几个缺点，包括将不同需求的应用程序合并、可能需要TLS解密和重新加密以进行检查、在工作负载VPC中需要额外的负载均衡器以实现自动扩展，以及总体成本较高。

作为替代方案，Dmitri倡导分布式入口模式，其中每个工作负载VPC都有一个面向互联网的负载均衡器、WAF、额外的防火墙用于分层保护、CloudFront用于缓存和边缘保护，以及Amazon Shield用于DDoS缓解。这种经济高效的方法将特定于应用程序的配置保持在一起，限制了错误配置的影响范围，并根据需要利用WAF、防火墙、CloudFront和Shield。但是，需要自动化来满足跨多个账户和VPC的合规性和治理要求。

Dmitri建议同时采用集中式和分布式出口方法，对于IPv6而言，分布式出口更可取，以避免代理或NAT66解决方案。对于入口，他强烈推荐分布式方法，根据需要利用WAF、Amazon Network Firewall、CloudFront和Shield。

Andrew鼓励与会者探索后续的NET 301和NET 403会议，了解更多高级网络主题以及在亚马逊云科技上进行全球规模网络的见解。

在整个会议过程中，Dmitri和Andrew提供了从与亚马逊云科技客户合作的丰富经验中总结出的实用技巧和最佳实践。这些包括最小化跨可用区通信、在多账户设置中使用可用区ID而不是名称、优先使用私有子网托管大多数资源、利用VPC Block Public Access实现合规性、启用DNS64和NAT64实现IPv6-IPv4连接、定期测试区域转移、在专用子网中部署Transit Gateway附件，以及考虑在具有检查要求的多区域部署中使用Cloud WAN。

Well-Architected Cat这个经常出现的猫形伙伴在整个演示过程中添加了自己的见解和提醒，强化了最佳实践并突出了需要避免的潜在陷阱。

来自ARM的Radek Voornam分享了他们在亚马逊云科技上的网络之旅是如何由明确的愿景、明确的计划和果断的决策驱动的。ARM很早就认识到需要一个多区域、多账户环境，并使用区域Transit Gateway构建了完全网状的骨干网络，以确保区域之间的最短路径。

随着ARM将更多工作负载迁移到云端，他们通过多个Site-to-Site VPN与本地数据中心建立了安全连接，这些VPN终止于区域Transit Gateway。为了区分网络团队和云团队的职责，ARM将其本地设备虚拟化并部署到云中，在这些虚拟设备与数据中心之间建立Site-to-Site VPN，以及在这些虚拟设备与其Transit Gateway之间建立VPN。

虽然可行，但这种方法在虚拟设备上引入了性能问题，需要一种解决方案来替换这两组VPN。第一组被Transit Gateway Connect附件所取代，而第二组最初被Direct Connect取代，用于数据传输。一年内，ARM通过利用Direct Connect作为合作伙伴提供的SD-WAN解决方案的基础设施，进一步改进了这一点。

解决了与本地的连接后，ARM将重点转移到其亚马逊云科技环境，并开始采用Cloud WAN，这是多Transit Gateway场景的自然继承者，通过代码实现网络塑形并促进自动化。

ARM的IP寻址规划随着时间的推移发生了重大变化。最初针对IPv4，目标是4个主要区域，每个区域超过100个VPC，跨2个可用区，他们选择了一个/15 CIDR块，并进行了复杂的细分。两年后，他们的IPv6需求发生了巨大变化，目标是16个区域、4，000个VPC，并能够在每个区域内使用所有可用区，导致他们从专门为亚马逊云科技分配的/42中复杂地细分了一个/25 IPv6块。

ARM开发了三种账户模式或“风格”，提供可重用的模板，同时满足独特的项目需求:一个完全可路由的VPC、一个部分可路由的VPC(包含一个小型完全可路由的播种器和一个较大的VPC范围播种器)、以及一种模仿ARM网络团队设置的模式，其中为区域Transit Gateway专门分配了一个/17块，并为项目Transit Gateway分配了一个/20块。

对于混合DNS，ARM实现了入站和出站解析器端点和Route 53规则，同时还允许用户通过亚马逊云科技服务目录产品根据需求塑造DNS，该产品可自动将私有托管区域与中心账户关联。

ARM开发了自动化解决方案来满足亚马逊云科技服务无法直接覆盖的特定需求，例如在EC2实例被销毁后保留MAC地址，利用Auto Scaling Groups、Lambda函数和CodeDeploy。

总的来说，本次会议提供了一个全面而实用的指南，介绍了如何在亚马逊云科技上设计架构良好的网络，汲取了ARM的实际经验以及演讲者的集体专业知识。它强调了谨慎规划、遵循最佳实践、利用强大的亚马逊云科技网络服务和工具，以及愿意适应不断发展的需求，同时融入了具体的数据、数字和表述，丰富了整个叙述。

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

Dmitri，亚马逊云科技专业服务部门的一位高级云架构师，在演讲开始时进行了自我介绍。

云WAN通过定义网段网络策略，简化了跨区域通信，从而消除了单独管理路由表的需要。

Amazon VPC Lattice能够在VPC之间的资源之间实现安全通信，无需额外的网络构造，提供了隔离性和灵活性。

亚马逊云科技安全组允许应用程序层之间进行安全通信，无需处理IP地址，从而实现动态扩展而无需手动配置更改。

讨论了在云环境中实施东西向安全控制的注意事项和潜在方法，包括防火墙、安全组和零信任架构。

演讲者强调了对虚拟私有云(VPC)进行仔细规划和设计考虑的重要性，包括可用区、路由模式、IP地址分配和特定工作负载的要求等因素。

Dmitri讨论了各种流量检查模式，包括集中式与分布式方法，强调没有一刀切的解决方案，并建议在re:Invent上参加相关会议，了解高级设计和全球规模的网络。

总结

在这篇全面的叙述中，亚马逊云科技专家深入探讨了在亚马逊云科技云上设计良好架构的网络的复杂性。他们首先介绍了基本的网络构造，如VPC、子网和网关，强调了双栈方法的重要性以及最小化跨可用区通信。然后，讨论转向各种连接选项，包括VPC对等、Transit Gateway、Cloud WAN和VPC Lattice，每种选项都适用于不同的用例和拓扑结构。

专家们强调了适当的IPv4和IPv6规划的重要性，并分享了ARM的网络之旅的见解，突出了他们在IP寻址和账户结构模式方面的方法。他们还深入探讨了使用Route 53 Resolver进行混合DNS解析以及跨引用安全组进行可扩展规则管理的强大功能。

叙述接着探讨了流量检查模式，对比了集中式和分布式出口和入口过滤的方法。专家建议采用分布式入口过滤以实现成本效益和有限的影响范围，同时倡导使用Amazon Network Firewall、Web Application Firewall和Amazon Shield等服务采用分层安全方法。

最后，专家们强调了规划的重要性，包括账户和VPC结构、IP寻址、跨VPC连接、本地连接、DNS解析和安全考虑因素。他们鼓励与会者评估不同的流量检查模式，并参加后续会议以了解高级网络设计和全球规模网络概念。

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