AWS Infra系高级证书知识点整理(3)——网络构建、网络工具篇 | 硅基生物的培养皿

type

status

date

slug

summary

tags

category

icon

password

⚠️

本文写作于 2025 年 6 月，截止到写作时间点为止，AWS考试体系高级部分分为SAP、DOP、ANS、SCS四部分。

本文将整理笔者自身备考除了MLS之外的高级考试过程中错过的题的关键点以及知识漏洞，供大家参考复习。

本文内容的正确性与非过时性都经过了Gemeni核查，但我无力随时更新这个总结，随着AWS技术本身的演进，其中的一些说法难免会和事实出现偏差，阅读时请注意这一点。

📝 网络构建

VPC

<SAP> 建立EIP的时候支持从机房直接拿现有的IP来用，叫做Bring Your Own IP(BYOIP)，它的好处是系统上云的时候能最小化一些依赖于IP地址的配置修改量，可以配合NLB->EC2一起使用实现API的IP固定

<ANS> NAT Gateway只支持IPv4，不支持IPv6，支持IPv6需要Egress-only Internet Gateway，并在路由表里建立::/0 -> [EIGW ID]的出站路由，这个路由表可以贴在私有子网上。EIGW是只允许出站的，保证了外部流量不可达，但是它和NAT的区别在它不提供地址转换，直接使用IPv6地址

<ANS> 如果在文件传输中设置了don't fragment（不分段），则MTU为9001的巨型帧无法通过公网（MTU为1500）或VPN（MTU为1500）传输

<SAP> 一个Subnet的CIDR一旦定下来就是不可变的

<SAP> 即便有EIP，没给路由表设定igw，一样流量不能出到公网

<SAP> 让机房走私网访问S3的架构是，建立一个私有VPC，让机房和它通过私有VIF直连，并且制作一个S3的interface型endpoint（Private Link）。问题点：如果使用公有VIF就会走公网，如果用gateway型endpoint就会用公有IP访问S3

<SAP> 两个VPC之间的通信，如果想让一个VPC1内的资源访问另一个VPC2里的服务（ELB）时走AWS内部网络的话，可以在VPC1里设置一个ELB的Interface型VPC Endpoint并且修改路由表，这相当于在VPC1里建立了一个ENI，并指定了一个指向ELB的DNS，要注意Interface型VPC Endpoint是收费的。

<DOP> 如果两个子网不位于同一个VPC中（比如在两个账户中），那么彼此是无法访问对面的资源的，可以靠Peering解决

<ANS> 在给EC2发送VPC流量镜像时，可以用NLB给EC2做负载均衡，因为流量是包括UDP的，因为它处理的是第四层流量，ALB不支持

<ANS> 当10.10.1.0/24的地址耗尽时，扩展方法是创建10.10.2.0/24，而不是直接修改原本的地址范围前缀，那样会导致整个网络infra重建

<ANS> VPC流日志可以获取IP流量信息，但是无法获取TCP段有效负载信息，因为那是第四层的，需要通过EC2流量镜像和第三方软件获取，转发到CW Logs

<ANS> 在使用VPC Traffic Mirroring时，可以将流量从eni引入到NLB，再引入到后面的EC2集群，实现监控软件的高可用。这种方法相比VPC流日志，可以检查流量的内容

<ANS> VPC流日志只记录网络层信息，不记录DNS查询等信息

<ANS> 接口S3终结点比网关型更贵

<ANS> Peering之后，如果两个VPC在同一个AZ，则传输费用免费

<ANS> 记录VPC Flow Log，使用CW并没有S3长期经济高效

<ANS> 使用IPAM可以建立顶级/VPC级/Subnet级IP地址池，配合CW来监控IP地址的耗尽情况

Transit Gateway

<SAP> AWS Transit Gateway是Region内服务，但支持Region间Peering连接

<SAP> 网速很慢且是小规模网络的情况下不要考虑TGW，因为运维成本高，使用RAM共享能和机房VPN联网的子网即可

<DOP> TGW也不支持重叠的CIDR

<ANS> 作为SaaS服务为了避免管理海量客户的IP地址，不用TGW，而是PrivateLink

<ANS> 让TGW连接的每个VPC中的EC2都能动态注册以接收多播的方法是，在TGW内创建IGMP多播域，将VPC和适用的子网和多播域关联，将多播发送者的网络接口注册到多播域，调整网络ACL允许UDP流量从源到所有接收者，并允许UDP流量发送到多播组地址

<ANS> 设备模式是要启动在共享服务VPC上的，而不是一般应用VPC

<ANS> 相比于多VPC之间Peering，使用TGW存在每个VPN连接50Gbps上限的突发性能瓶颈

<ANS> TGW网路管理器可以和EventBridge一起，在路由发生更改时发出通知

<ANS> 连接到TGW的VPN，比连接到VGW的VPN在跨大陆连接时性能更好，因为TGW走AWS骨干网，VGW的VPN走公网

<ANS> 做中央检查VPC时，建议和应用程序的路由表分开，给TGW建立两个路由表，这样两边不会搞混容易维护

Direct Connect

<SAP> Direct Connect Gateway按时间收费，VPC Peering不收时间费用

<ANS> 为了让混合网络支持IPv6，更新目前的VIF即可，重新创建VIF会影响基础设施

<ANS> 完全走私网访问S3的方式是通过DX的私有VIF进入VPC再走S3接口终结点，可以在VPC内部署HTTPS代理访问S3

<ANS> 配置主备模式的双DX连接，最好使用BGP社区而不是修改AS_PATH长度，仅仅配置AS_PATH不能实现故障转移，且混乱很难维护

<ANS> 将一个新账户的TGW与另一个账户的一个既有的DCGW关联的方式是，从新账户发出关联提案

<ANS> BGP会话需要打开端口179，如果被关闭，私有VIF的状态会变为DOWN，DX不可用

<ANS> Region2的VPC2通过TGW与Region1的TGW建立Peering后，流量将通过Region1的TGW转发到Region1的VPC1，然后通过Direct Connect连接到机房。因此，机房和Region2的VPC2可以间接联通。前提是需要在两个TGW的路由表中配置静态路由，将流量正确地指向Peering连接。

<ANS> 用于故障转移的双向传输检测（BFD）需要配置在机房端路由器的DC连接上与AWS端两方面

<ANS> BGP路由选择优先顺序：最长前缀匹配 > 直连BGP路由 > 静态路由 > VPN BGP路由

<ANS> 为DX提供加密的方法是，在DX上配置MACsec（第二层加密）

<ANS> DX上的BGP最多支持100条路由，如果超过，需要聚合路由

<ANS> MACSec的密钥一旦与连接关联则无法更换，需要取消关联后再关联新的密钥，可以使用KMS的用户管理密钥达到最大的安全性

<ANS> DX的PublicVIF需要在DX维护后更新AWS服务的IP地址列表，否则可能导致连接不上AWS服务

<ANS> 专有连接的带宽是无法提升的，只能重新建立连接

<ANS> Sitelink是启动在DXGW上的，保证多机房之间流量互通，走DXGW，启动SiteLink明确要求使用私有VIF

<ANS> 关于SiteLink，如果只是希望两个机房相互连接，则不需要使用DXGW，直接在两个VIF上开启即可，如果也需要访问AWS的VPC，则需要DXGW

VPN

<SAP> 从Site to Site VPN切换到DirectConnect时，如果想让停止服务时间最短，可以通过切换BGP优先度（AS PASH长度）的方法进行，让DirectConnect的优先度提高，等确认DirectConnect可用后，再停掉VPN线路。

<SAP> 跨区域VPN连接并不能彻底解决传输性能问题，因为毕竟要走公网，提升性能还是需要使用Direct Connect Gateway绕开公网

<SAP> 一个VPC只能有一个VGW，不存在给两个AZ都添加VGW实现高可用的做法

<ANS> GA加速并不是连接到VGW的Site2SIte VPN的标准选项，但是连接到TGW的VPN可以通过GA开启加速

<ANS> 在CGW到TGW的VPN连接中，可以创建第二条乃至更多条VPN隧道并启动等价多路径（ECMP）提升文件传输性能

<ANS> VPN的DPD是失效对等检测，用于超时后断开VPN隧道，超时的原因可能是密钥交换（IKE）会话终止，此时将DPD超时操作设置为重启即可

<ANS> VPN连接一个VPC后，是不可以直接访问和这个VPC进行Peering的其他VPC的

其他工具

<SAP> VPC终节点可减轻NAT网关巨大的数据传输成本，尤其是在大量数据传递到Kinesis的用例中

<SAP> NAT Gateway不支持IPv6，要是用Egress-Only igw让私有子网的流量通过IPv6出到公网

<DOP> NAT Gateway不能跨AZ部署，只能每个AZ一个

<ANS> 私有NAT网关能以最小的成本提供一个出口IP地址，NAT Instance的成本更高

<ANS> 使用S3终结点传输大量数据，比使用NAT便宜

<ANS> NAT Gateway会丢弃350秒以上的连接，并引发IdleTimeoutCount指标增加，需要在EC2上开启TCP keepalive

<SAP> PrivateLink是单AZ的，如果PrivateLink的链接对象是多AZ部署的NLB，则需要给每个AZ添加PrivateLink形成高可用架构

<ANS> PrivateLink endpoint如果连接的是一个ALB则如果两个子网IP重叠的话无法进行负载均衡和正确路由，需要使用NLB

<SAP> RAM可以直接共享TGW出去，可是在小流量的简单网络里，直接共享Subnet的做法成本更低

<ANS> 可以通过RAM启动组织内共享，共享管理账户里的防火墙规则给所有账户的多个VPC

📝 网络工具

Route53

<SAP> 当一个Region挂掉时，如果RTO要求时间不是秒切，而是有一两小时的时间，则可以用IaC做好代码现场部署在其他Region，而不是用Route53 DNS failover做故障转移，因为后者需要长期运行另一个备份系统，存在长期维护成本

<SAP> Global Accelerator一旦通过健康检查发现一个边缘节点不可用了，就会切到另一个节点进行通信，这缓解了在双活灾备架构上DNS因为缓存带来的切换不及时的问题

<SAP> Route53通过Resolver作为代理和Private hosted zone通信来获取VPC内机器的IP地址，在使用时要将VPC的enableDnsSupport和enableDnsHostnames属性设置有效

<SAP> 关于混合网络下的DNS查询，如果想从机房通过DNS找私有R53 hostzone定义的目标，则需要走inbound endpoint、反之走outbound endpoint，这是两种ENI，会将DNS查询流量转发到对面网络的DNS解析器

<SAP> Route 53 Outbound Endpoint可以被RAM共享到多个账户，可以将这个终结点配置在一个单独的账号下，让多账户下多VPC仅需一次配置都可以通过这个终结点找到本地机房的DNS Resolver

<SAP> 如何将账户A的R53私有hostzone与账户B的VPC关联？1. 创建授权，将账户A的私有hostzone与账户B的新VPC关联；2. 将账户B的新VPC与账户A的hostzone关联，删除账户A的关联认证

<DOP> 实现蓝绿部署转移流量时：1. 让R53使用加权路由转移流量 2. 使用第二个ALB 3. 使用同一个RDS

<DOP> 实现灾备转移流量到其他Region时：1. 让R53使用故障转移路由 2. 在另一个Region建立第二个ALB 3. 让RDS触发事件，令R53切换DB的DNS到备用Region，同时提升其为写节点

<DOP> 如果在两个Region里部署了环境，要求满足双主动故障转移的同时满足延迟最低，则可以在example.com上配置基于延迟的路由记录，记录名分别为us.example.com和eu.example.com，然后分别在这两个子域上设置故障转移路由，将自己区的ALB设置为主，另一区的ALB设置为辅

<ANS> 故障转移路由策略目的是提高可用性，对于可预见的UDP流量频繁丢包，使用延迟路由策略可以增加可靠性，或从网络层面优化，使用Global Accelerator

<ANS> 通过R53 DNS Resolver DNS Firewall阻止僵尸网络流量

<ANS> 如果希望在一个AWS账户的Route 53中管理父域，并在另一个AWS账户中添加子域，同时不想迁移父域到子账户，那么需要在父域的Route 53托管区中添加指向子域托管区的NS记录。然后，在新账户中创建子域的Route 53托管区，并为子域添加相应的主机记录

<ANS> DNS查找优先使用UDP，如果传输量过大，会改用TCP

<ANS> 对于出站终结点的解析规则，如果配置为.，则域中的规则走R53私有Zone否则走DC的解析器，如果配置为*，则将所有解析请求发送到DC的解析器

<ANS> 比如EFS挂载点DNS，是无法通过在EC2上部署BIND这样的服务进行DNS解析的，从而导致无法挂到EC2上，这种情况必须使用AWS的DNS解析

<ANS> 一个私有托管域可以与多个VPC关联，不能是不同Region里的VPC

<ANS> DNS防火墙可以配置故障开放或关闭，即在防火墙本身没有响应的时候，是否继续执行DNS解析，配置故障开放可以带来更高的可用性

<ANS> 可以在两个Region开两个NLB，让Route53通过延迟路由选择合适的节点，配合Global Accelerator，达到全球化的高性能访问

<ANS> Route53的故障检查的目标并不支持私有IP地址，因为这属于一项公共服务，只支持监控公有UP，替代方案是使用CW警报监控私有资源

<ANS> 使用DNSSec时，无论Route53位于哪里，都必须使用位于us-east-1区域的ECC_NIST_P256密钥规范创建的非对称CMK，使用它创建KSK

API Gateway

<SAP> API Gateway自带缓存功能，在增加Redis层之前，首先考虑这个简单的方法

<SAP> API Gateway提供两种主要端点类型：边缘优化和区域级。边缘优化端点通常更适合地理位置分散的客户端，因为它们利用CloudFront的全球边缘网络来减少延迟。然而，对于位于API Gateway相同AWS区域内的客户端，区域级端点通常提供更低的延迟和抖动，因为请求通过的AWS基础设施更少，避免了CloudFront边缘网络的开销。如果您打算在区域级API Gateway前面自行放置CloudFront，那么区域级端点也是推荐的选择。

<SAP> API Gateway的RestAPI可以和DynamoDB直接整合，HttpAPI可以通过Lambda函数和DynamoDB间接整合

<SAP> 允许CORS请求是在API Gateway上设置的

<SAP> API Gateway可以构建WebSocket API，用@connections命令获取callback信息

<DOP> API Gateway的两个API可以进行集成，通过映射模板对传入的参数进行修改，以适应两个不同版本的API

<SCS> 限制可以访问API Gateway的IP地址范围的方法 1. API Gateway 资源策略 2. 将WAF添加到API Gateway前面

CloudFront

<ANS> CloudFront不支持UDP流量，如果要为全球部署的UDP服务做加速，要用Global Accelerator，为每个区域配置端点组，把NLB注册上去

<ANS> CF->ALB->EC2全链路加密：使用ACM为CF创建证书让CF使用，更改默认行为将HTTP重定向到HTTPS；使用ACM为ALB创建证书让ALB使用，监听443端口，将CF源更改为HTTPS；从第三方购买证书让EC2使用

<ANS> 除了需要在ALB上启动粘性会话，还需要在CF分配的缓存行为中配置cookie转发

<ANS> 使用S3存储桶暴露网站，无法实现HTTPS，必须使用CF

<ANS> 当CF无法访问源时可能会返回502错误，可能是因为TLS访问失败

<ANS> 通过设置“匹配查看器”（Match Viewer）源站协议策略，CloudFront会根据用户请求的协议（HTTP或HTTPS）与源站通信。这意味着如果用户使用HTTPS访问CloudFront，CloudFront也会使用HTTPS访问源站。然而，如果用户使用HTTP访问CloudFront，CloudFront也会使用HTTP访问源站。若要强制CloudFront始终使用HTTPS与源站通信，无论用户请求的协议如何，都应选择“仅HTTPS”（HTTPS only）策略。这种区别对于确保端到端加密至关重要

<SAP> 为了防止CF后的ALB被直接攻击，除了只允许带有特定Header的请求访问ALB外，还可以将WAF关联到CF的Distribution上

<SAP> 防止绕过CF直接访问ALB的做法，需要在CF加自定义Header，之后一种做法是让ALB的路由判断是否有Header，也可以直接设置ELB的安全组，只允许从CF进来，另一种做法是让ALB前面的WAF自定义Web ACL，但是更推荐加在CF上

<SAP> 如果两个不同Region的S3 Bucket设置了相互备份，则在CF上配制成Origin Group即可，不需要使用其他方式做切换

<SAP> 当响应动态内容的ALB发生503时如果想显示一个错误页面，需要给CF设定一个由两个Origin组成的Origin Group，其中Secondary Origin指向S3存储桶中的错误页面，并且设置CF Distribution的Origin Failover。

<SAP> 除非遇到合规性要求或者故障转移需求，否则首选CF的多区域Origin对单区域里的ELB（除非ALB）进行加速，而不是在多区域里分别架设ELB，那样会造成很大的系统复杂性

<SAP> 需要在全世界公开动态内容时，只使用一个区域的ALB+全球CF是不能保证动态内容的容灾性的，此时无需部署第二个CF Distribution，而是把新Region里的ALB做成新的Origin，跟之前的Origin组成Origin Group，让Origin Group内形成主从关系达到高可用，这种方式管理成本更低

<SAP> 可以使用Lambda＠Edge指定对CF的访问找哪个区域（的Origin）的S3以降低访问S3的延迟

<SAP> 可以通过部署lambda@Edge处理用户给CF发的请求，进行一些预处理，比如把QueryString进行统一小写变换，以提高CF的URL缓存命中率

<SAP> 本地机房负载过大时，首先考虑静态文件上CF，这个见效快，后考虑上云上R53分流等

<SAP> 在CF中，虽然可以用User-Agent HTTP Header做判断提供不同的资源，但不推荐这么做，因为User-Agent的可能值太多了，基于它做缓存会增加访问后端的次数，合适的方法是用Lambda@Edge

<SCS> 任何知道有效时间范围内S3签名URL的人都能访问内容，而CF签名URL可以向经过身份验证和授权的用户提供内容

<SCS> 创建CF分配，创建新的缓存策略，其中包含授权标头的白名单，可以将标头转发到外部存储自定义源

<SCS> SecurityHeadersPolicy策略会给每个CF响应添加一个标头（X-Connect-Type-Options:nosniff），防止浏览器嗅探MIME类型

<SCS> CloudFront的地理限制功能能限制特定国家，使用WAF也可以但是贵

<SCS> CloudFront响应请求时可以通过Lambda@Edge添加标头给响应，让浏览器使用，防止XSS攻击等

ELB

<SAP> 只增加EC2的数量不增加AutoScaling组是会提高运维成本不会带来可靠性的

<SAP> 对于在更新应用程序时Auto Scaling组里异常停止而没有记录CW Logs的EC2，调查方法是暂时让Auto Scaling组缩容时不要Terminate机器，然后SSH进EC2查看问题日志。

<SAP> NLB使用流哈希算法（flow hash algorithm）来选择目标，以确保特定流量的会话粘性。ALB支持Round Robin、Least Outstanding Requests和Weighted Random算法。

<SAP> 可以使用NLB->ALB的方式在NLB上固定负载均衡器的IP地址，但是ALB看到的是NLB的IP地址

<SAP> 可以把Global Accelerator的endpoint指向ALB，这样就可以把Accelerator的固定IP提供给用户了，达到了间接提供ALB的固定IP的做法，还可以享受ALB的各种好处，比如可以使用WAF

<SAP> NACL提供了block掉除了UDP之外全部流量这样的功能，而此时不能选择WAF，因为NLB支持UDF，ALB不支持，而WAF只支持ALB

<SAP> ELB的Target可以跨Region，但前提是目标通过IP地址注册，并且负载均衡器所在的VPC与目标所在的VPC（无论是在同一区域还是不同区域）通过VPC对等连接、AWS Direct Connect或Site-to-Site VPN连接。

<SAP> 当被问设置最大最小机器数在哪里设置时不要选ELB，直接选Auto Scaling Group （虽说后者是前者的机能之一但是也选后者）

<SAP> 外部针对NLB的请求在传输层（Layer 4）进行简单转发，当启用客户端IP保留功能时，EC2实例可以看到请求者的原始IP地址。NLB可以提供固定IP地址，这对于需要特定IP加白名单的API非常方便。相比之下，ALB会终止客户端连接并向后端发起新连接，因此后端EC2看到的是ALB的IP地址，原始客户端IP通过X-Forwarded-For头部传递。因此，在需要后端直接看到原始客户端IP且需要固定IP的场景下，NLB是更合适的选择。

<SAP> Auto Scaling组可以根据属性（vCPU计数、内存、本地存储、突发性能等）选择合适的Instance Type进行扩机器，这种方式可以避免使用Spot Instance时获取不到机器

<SAP> 在改进既有方案时，导入AutoScaling时可以考虑用比一直在用的EC2更小的机器节约成本提高性价比

<SAP> 记录应用程序所有IP、连接类型、UA等信息，用ALB的Access Log存储到S3用Athena分析即可，而traffic mirroring是VPC级的功能，并且并不提供第七层的信息

<SAP> 在进行A/B测试时，通常建议在ALB上配置多个目标组并使用基于规则的路由（例如，基于路径或权重）来分流用户，以确保同一客户端始终访问新版本或旧版本，这得益于ALB的会话粘性或更细粒度的控制。虽然Route 53可以为多个ALB进行权重分流，但由于DNS缓存机制，它不能保证同一客户端在后续请求中始终被路由到相同的ALB，这可能不适用于需要会话一致性的A/B测试场景。

<SAP> Auto Scaling组默认只检查EC2状态。可以向Auto Scaling组中添加ELB的页面健康检查，在健康检查不合格时消除instance。然而，ELB默认只检查health页面，其他页面也有可能失败，所以可以针对适当的容易出错的页面进行健康检查。

<ANS> gRPC支持NLB和ALB，要根据具体场景选择，如根据路径选择目标的情况推荐ALB，需要吞吐量则选择NLB

<ANS> 在NLB上实现端到端加密的方式是：将监听协议和目标组协议都设置为TCP，在EC2上配置SSL证书，这样NLB就是一个透明代理了

<ANS> 希望NLB后面的流量只流经一个AZ，只有在故障时才流向另一个AZ的方式是，关闭NLB的跨区域负载均衡

<ANS> 当ALB把流量分散到本地和AWS混合云环境时，如果要启动会话粘性，则需要指定ip地址为目标类型，因为指定实例作为目标类型的话，本地机器无法被注册

<ANS> 追求高吞吐量和低延迟的时候，NLB是不错的选择，追求根据路径精细控制流量时，选择ALB

<ANS> 如果希望EC2来通过证书实施双向SSL身份验证（mTLS），需要使用NLB让流量穿透443端口发送给EC2，也可以在ALB层面进行mTLS，验证或将客户端证书链传递给后端EC2，因此并非必须使用NLB

<ANS> 在ALB上客户端的IP地址是在X-Forwarded-For标头中传递给后端的

<ANS> ALB可以开启前向保密（FS）,为每个会话生成随机密钥

<ANS> 虽然MQTT是第7层协议，但当其运行在TCP/UDP上时，必须使用NLB第4层负载均衡。只有在MQTT通过WebSocket实现时，才能使用ALB第7层负载均衡

<ANS> 连接带有防火墙功能的NAT机器，最好选择GWLB，这可以实现透明流量转发

WAF/Network Firewall

<SAP> 可以通过WAF给Data Firehose发消息的方式实时监控被WAF拒绝的流量，交给第三方应用审核

<SAP> WAF有防止SQL注入的规则集，可以把不符合SQL规则的请求的IP作为黑名单加入ALB的ACL来防止注入攻击，而不是用Lambda函数扫日志来构建IP黑名单加入ACL，后者是针对特定IP地址做block的，前者是针对SQL注入最省时省力的办法

<SAP> NLB上不能使用WAF

<SAP> 在WAF上使用基于速率的规则可以用来屏蔽频繁尝试访问失败的IP地址

<ANS> WAF只能和ALB关联，不能和NLB关联，因为NLB处理的是第四层的流量，不处理第七层

<SCS> 可以在CloudFront和ALB之间增加一层WAF，配置规则仅允许CF的流量传递进ALB，同时抵御常见的攻击

<SCS> 分析针对特定URL的攻击需要使用WAF传送日志到S3，而VPC流日志不支持HTTP层面的URL记录

<SAP> AWS Network Firewall是放在NAT和igw之间的防火墙，能通过包检测来阻断某些通信，基本构造是在【私网-公网（NAT）-IGW】架构的后两者之间增加一个子网来部署此工具，同时要把里层路由表的0.0.0.0/0指向上一层，它可以组合Transit Gateway在大规模网络中做检测专用VPC

<ANS> RAM可以把资源共享给单个账户或者整个OU，可以通过RAM启动组织内共享来共享网络防火墙规则

<ANS> Network Firewall的HOME_NET变量告诉防火墙哪些IP地址范围是受保护的内网地址

<SCS> WAF只能拦截外来流量，不能拦截从AWS发出的攻击，如果需要拦截这个方向的测试用攻击，需要Network Firewall

其他工具

<ANS> GA可以实现一分钟内故障转移到其他区域ALB，而Route53的效率达不到1分钟内

<ANS> 作为加速工具，单纯从速度来说GA比CF快

<ANS> ALB+Global Accelerator可以提供IP地址，所以可以用来配合防火墙限制出口IP，而ALB+CloudFront不提供IP地址，所以不能配合防火墙使用

<ANS> 自签名SSL/TLS证书可以导入AWS ACM。导入过程通常涉及生成私钥和证书（例如使用OpenSSL），然后通过AWS CLI或控制台进行导入。

<SAP> ACM的证书不能直接给EC2使用，EC2需要用第三方证书。AWS Nitro Enclaves除外。并且，由AWS Private CA（ACM的一项功能）颁发的私有证书可以用于EC2实例、容器或本地服务器。

<ANS> Reachability Analyzer只能分析VPC内的可达性，但是在分析跨TGW（跨Region）的路由时存在限制，这种情况要使用Network Manager Route Analyzer分析TGW的路由表